U
Umut Gürkan
Misafir
Misafir
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.
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
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.
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
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.
Migration Hazırlık: WM Sistemini Tanımak
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:
- Warehouse Number yapısı: Mevcut depo sayısı, storage type, storage section ve bin yapılandırmaları
- Transfer Order hacmi: Aylık/haftalık ortalama TO sayısı ve pik dönemleri
- Özel geliştirmeler (Z kodu): WM üzerinde yazılmış özel raporlar, user-exit’ler, BAdI kullanımları
- Entegrasyon noktaları: WM ile haberleşen WMS, MES, barkod okuyucu sistemleri
- RF/barkod terminali kullanımı: Mevcut terminal sayısı, kullanılan işlem kodları
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.
Migration Yaklaşımını Seçmek: Brownfield mi, Greenfield mi?
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
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
doğru analiz etmek, yaklaşım seçiminizi netletirecektir.SAP Migration Cockpit ile 34 Migration Nesnesi
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:
- Warehouse Structure (Depo Yapısı): Warehouse number, storage type, storage section, storage bin tanımları
- Warehouse Product (Ambar Malzeme Masterı): Her malzeme için EWM-spesifik alanlar; putaway/stock removal stratejileri, handling unit tipi
- Storage Bin Master: Bin özellikleri, maksimum ağırlık/hacim, erişülebilirlik durumu
Transaksiyonel Veri:
- Open Transfer Orders: Cutover anında tamamlanmamış WM transfer emirleri; bunların EWM warehouse task’a dönüştürülmesi gerekir
- Stock Data: Bin bazında stok bilgileri, batch ve serial number bilgileri dahil
- Open Inbound/Outbound Deliveries: Açık teslimat belgelerinin EWM’ye aktarımı
Ö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.
Customizing Taşıma Stratejisi
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.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
bu taşıma stratejisini doğrudan etkiler.Yaygın Migration Hataları ve Önlemleri
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.
Cutover Yönetimi: Migration Günü Planı
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:
- Son veri temizleme (data cleansing) tamamlanır
- Migration Cockpit test yüklemeleri (en az 3 tam test) tamamlanır
- Cutover süre planlayıcısı (runbook) hazırlanır ve onaylanır
Cutover -48 Saat:
- WM’de yeni işlem gişi durdurulur (freeze)
- Açık transfer emirleri tamamlanır veya iptal edilir
- Son stok sayimi yapılır ve IM/WM mutabakatı sağlanır
Cutover Günü:
- Migration Cockpit ile master data yüklemesi: warehouse structure, storage bins, warehouse products
- Stok verisi yüklemesi (bin bazında)
- Stok mutabakat raporları çalıştırılması
- Smoke test: EWM üzerinden örnek inbound ve outbound işlemleri
- RF terminallerin son kontrolü
- Go/No-go karar toplantısı
Go-Live Sonrası İlk 48 Saat:
- Yoğun izleme: warehouse task hata logları, tamamlanma oranları
- Anahtar kullanıcı sahada; key user desteği aktif
- Günlük stok mutabakatı kontrolü
Deployment Model Seçimini Migration Öncesi Netleştirin
Migration’a başlamadan önce
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
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.Sıkça Sorulan Sorular (SSS)
Migration Cockpit kullanmak zorunlu mu, yoksa manuel konfigürasyonla da gelinebilir mi?
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.
WM Z kodları EWM’ye otomatik taşınabilir mi?
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.
Migration süresi ne kadar sürer?
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.
Sonuç: Hazırlık Kalitesi Migration Başarısını Belirler
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.
Referanslar
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.