SAP WM’den Embedded EWM’e geçiş, salt teknik bir sistem güncellemesi değil; depo süreçlerinin yeniden tasarımını gerektiren stratejik bir migration projesidir. SAP’nin Migration Cockpit’i 34 ayrı migration nesnesiyle bu geçişi yapılandırılmış şekilde desteklese de yaşanılan en yaygın hatalar hazırlık aşamasında yapılan yatay görüş eksikliklerinden kaynaklanır. Bu rehberde migration aşamalarını, sık yapılan hataları, customizing taşıma stratejilerini ve cutover yönetimini adım adım açıklıyoruz.
İçindekiler
Bir WM-EWM migration projesine başlamadan önce mevcut sistemin derinlemesine analiz edilmesi gerekir. Bu aşamayı atlamak veya üzeysel geçmek, sonraki aşamalarda ciddi zaman ve maliyet kayıplarına yol açar.
İncelenmesi gereken başlıca alanlar:
MDP Group olarak, bu analiz aşamasında özellikle Z kodlarının tespiti ve EWM’deki standart karşılıklarının belirlenmesi kritik öneme sahiptir. Her Z kod, ya EWM standardına taşınabilir ya da yeniden geliştirilmesi gerekir.
WM’den EWM’ye geçişte iki temel yaklaşım mevcuttur:
Greenfield (Yeniden Kurulum): S/4HANA EWM tamamen sıfırdan konfigüre edilir. WM customizing’i aktarılmaz; süreçler EWM best practice üzerinden yeniden tasarımlanır. Uzun vadede daha temiz bir sistem sağlar, ancak daha fazla proje süresi ve kaynak gerektirir.
Brownfield (Dönüşüm): Mevcut ECC/WM sistemi S/4HANA’ya dönüştürülür. WM customizing’inin bir kısmı otomatik olarak taşınabilir, ancak EWM’ye özgü yeni yapılandırmalar yine de manuel olarak tamamlanmak zorundadır. Özellikle storage type → warehouse process type ve transfer order → warehouse task dönüşümleri dikkat ister.
Hangi yaklaşımın doğru olduğuna karar verirken WM ve EWM arasındaki yapısal farkları doğru analiz etmek, yaklaşım seçiminizi netletirecektir.
SAP, WM’den EWM’ye geçişi Migration Cockpit (transaction LTMC/LTMOM) aracıyla desteklemektedir. Bu araç, 34 farklı migration nesnesi üzerinden yapılandırılmış veri taşıma işlemlerini yönetir.
En kritik migration nesneleri:
Statik Master Data:
Transaksiyonel Veri:
Önemli uyarı: Migration Cockpit verileri şablonlar (Excel/CSV) üzerinden yüklemenize olanak tanır, ancak veri kalitesi son derece kritiktir. Yükleme öncesinde mutlaka veri temizleme (data cleansing) yapılmalıdır.
WM customizing’inin EWM’ye taşınması bire bir karşılık bulmaz. Yapısal farklılıklar nedeniyle şu dönüşümler el ile yapılmalıdır:
WM Movement Type → EWM Warehouse Process Type WM’deki hareket tipleri (201, 261, 311 vb.) EWM’de warehouse process type’a karşılık gelir. Ancak iş akışı mantığı farklıdır; EWM’de outbound delivery order, inbound delivery order ve warehouse task ayrı nesnelerdir.
WM Storage Type → EWM Storage Type + Storage Section + Storage Bin Type EWM’nin depo yapısı WM’ye göre daha granüler bir hiyerarşi kullanır. Mevcut WM depo yapısınızı EWM’ye taşırken bu yapıyı doğru modellemeniz gerekir.
WM Putaway/Stock Removal Strategy → EWM Putaway/Stock Removal Strategy WM’deki strateji kodları EWM’de search sequence ve storage section indicator ile yapılandırılır. EWM lisans ve konfigürasyon kararınızı bu taşıma stratejisini doğrudan etkiler.
Hata 1: Warehouse Product Master eksik veya yanlış doldurulmak EWM’de her malzeme için Warehouse Product Master (WPM) oluşturulmalıdır. WPM olmadan putaway ve stock removal stratejileri çalışmaz. WM’de bu bilgiler Material Master WM view üzerinde tutulurken EWM’de ayrı bir nesneye taşınmıştır.
Önlem: Migration öncesinde tüm aktif malzemeler için WPM verilerini hazırlayın ve Migration Cockpit şablonuna yükleyin.
Hata 2: Açık Transfer Emirlerini göz ardı etmek Cutover sırasında WM’de açık kalan Transfer Emirleri EWM’ye otomatik geçmez. Bu belgelerin manuelde tamamlanması veya iptal edilerek EWM’de yeniden oluşturulması gerekir.
Önlem: Cutover öncesi freeze window belirleyin; transfer emirlerini sıfırlamadan cutover’a geçmeyin.
Hata 3: RF/Barkod terminal konfigürasyonunu son dakikaya bırakmak EWM’nin RF Framework’ü WM transaction kodlarından farklıdır. Terminallerin yeni EWM işlem akışlarına göre yeniden konfigüre edilmesi, test edilmesi ve kullanıcıların eğitilmesi gerekir.
Önlem: RF/terminal testlerini en az 6 hafta önce başlatın. Pilot depoda tam kapsamlı kullanıcı testi yapın.
Hata 4: Stok mutabakatını atlamak Migration sonrasında WM ve EWM stokları arasındaki uyumu doğrulamak şarttır. Bin bazında stok karşılaştırma raporları çalıştırılmadan go-live’a geçilmemelidir.
Başarılı bir cutover, haftalarca önce başlayan hazırlığın ürünüdrü. Aşağıda önerilen cutover planını görüyorsunuz:
Cutover -2 Hafta:
Cutover -48 Saat:
Cutover Günü:
Go-Live Sonrası İlk 48 Saat:
Migration’a başlamadan önce EWM’nin desteklediği otomasyon senaryolarını göz önünde bulundurarak Embedded mi yoksa Decentralized EWM mi kullanacağınıza karar verin. Bu iki model arasındaki seçim, migration planınızın tamamını şekillendirmektedir.
Migration Cockpit zorunlu değildir; ancak 34 migration nesnesini şablonlar üzerinden yönetmek, hata olasılığını azaltır ve izlenebilirlik sağlar. Özellikle stok ve bin verilerinin yüklenmesi için Migration Cockpit kullanımı şiddetle tavsiye edilir.
Hayır. WM üzerindeki özel ABAP geliştirmeleri EWM’ye doğrudan taşınamaz. Her Z kodun EWM’deki standart karşılığı analiz edilmeli; standart karşılık yoksa EWM BAdI’ları veya Business Add-In’ler kullanılarak yeniden geliştirilmelidir.
Orta karmaşıklıkta bir WM-EWM migration projesi (2-5 depo, sınırlı Z kod) genellikle 4-6 ay sürer. Yüksek hacimli, çok tesisli ve kapsamlı özel geliştirmeli projelerde bu süre 9-12 aya uzayabilir.
SAP WM’den Embedded EWM’ye geçiş; doğru planlama, kapsamlı veri hazırlığı ve test etme disiplini gerektiren çok aşamalı bir projedir. Migration Cockpit ve 34 migration nesnesi güçlü bir altyapı sunar; ancak bu altyapının doğru kullanımı için deneyimli bir ekip şarttır.
MDP Group olarak WM-EWM migration projelerinde edinilmiş deneyimimizle projenizin hazırlık, tasarım ve cutover aşamalarında yanınızda olmaya hazırız.
SAP Help Portal – Extended Warehouse Management for S/4HANA MDP Group – SAP WM mi, EWM mi? Doğru Depo Çözümünü Seçmek MDP Group – SAP EWM ve TM’de Lisans Kararı
SAP EWM Danışmanı
SAP ECC Desteğinin Sonlanması ve SAP HANA’ya Geçişin Önemi
SAP, küresel iş dünyasının vazgeçilmez teknolojik çözümleri arasında yer alıyor. Özellikle, SAP ECC (Enterprise Central Component) uzun...
SAP Cloud Connector’da High Availability: Master & Shadow Yapısı
SAP Cloud Connector, SAP BTP ile on-prem sistemler arasında güvenli bir bağlantı kurar. Ancak, Cloud Connector’ün tek bir noktada...
SAP AIF Nedir? SAP Application Interface Framework Rehberi
SAP AIF (Application Interface Framework), SAP sistemlerindeki entegrasyonları merkezi olarak izlemeyi, hataları iş kullanıcısı düzeyinde...
Depo Lojistiği Nedir?
Depo lojistiği, bir deponun günlük operasyonlarının yönetimidir. Etkili bir şekilde yönetildiği takdirde bir şirketin depo süreçlerini...
SAP AI Core Nedir? Özellikleri ve Avantajları
SAP AI Core, işletmelerin makine öğrenimi (ML) modellerini geliştirmesine, yönetmesine ve dağıtmasına olanak tanıyan bulut tabanlı bir...
SAP E-Fatura Çözümleri Nedir?
Giriş E-Fatura ve SAP e-Fatura çözümleri, işletmelerin fatura süreçlerini Gelir İdaresi Başkanlığı (GİB) standartlarına uygun şekilde...
KOBİ'ler Neden E-Dönüşüm Sürecine Geçmelidir?
KOBİ'ler e-Dönüşüm sürecine geçmelidir çünkü e-Dönüşüme geçen KOBİ'ler belgelerini daha hızlı işliyor, daha az hatayla...
Donanım Varlık Yönetimi (HAM) Nedir? Kapsamlı Rehber
BT Varlık Yönetimi (ITAM) Nedir? BT Varlık Yönetimi (IT Asset Management), organizasyonların sahip olduğu BT varlıklarının...
SAP GTS Nedir?
Günümüzde, değişen ticaret düzenlemeleri, yasal uyumluluk, dış politikalar ve özel kurallar gibi faktörler ithalat ve ihracat alanında...
Mailiniz başarıyla gönderilmiştir en kısa sürede sizinle iletişime geçilecektir.
Mesajınız ulaştırılamadı! Lütfen daha sonra tekrar deneyin.