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 RAP’ta Yan Etkiler(Side Effects) Nelerdir?
SAP RAP'ta yan etkiler, veri modelinin veya kullanıcı arayüzünün bir bölümündeki değişikliklerin diğer bölümleri nasıl etkilediğini...
SAP Entegrasyonu Nedir? Çeşitler, Faydalar ve Hazır Paketler
SAP entegrasyonu nedir? SAP entegrasyonu; SAP sistemi ile üçüncü taraf uygulamalar, bulut platformları veya şirket içi çözümler arasında...
EWM ile Sayım Sürecinde Fark Kaydı Kontrolü
EWM sayım uyarlamaları kullanılarak sayım sonrasında istenilen kullanıcıların fark kaydı atması engellenebilir. Hatalı/istenmeyen fark...
SAP Integration Advisor Nedir? Faydaları Nelerdir?
SAP Integration Advisor Nedir?SAP Integration Advisor (IA), SAP sistemlerinin diğer uygulamalar ve hizmetlerle entegrasyon sürecini basitleştirmek...
SAP MII Enerji İzleme ve Analiz Nedir?
Bir ürünün en büyük maliyetlerinden biri üretim aşamasında harcanan enerji maliyetidir. İşletmeler, rekabet gücünü korumak ve için...
SAP TM ile Stratejik Navlun Yönetimi ve Tedariği Nedir?
Giriş Günümüz küresel ekonomisinde, şirketlerin rekabetçi kalabilmek için her maliyet kalemini dikkatle yönetmesi şart. Bu kalemler...
SAP Signavio Nedir?
Kötü yönetilen iş süreçleri, şirketlerin kayıplara uğramasına, müşteri ve çalışan kaybetmesine neden olmaktadır. Bu sebeple,...
e-Faturada İstisna Kodları Nelerdir?
İstisna/Muafiyet Kodu, faturanın vergisiz olma durumunu tanımlamak için kullanılan kodlardır. Aşağıdaki tablodan faturanızın durumuna...
SAP Fiori Uygulamalarında Güvenlik Yönetimi
Bu blog gönderimizde kullanıcıların SAP Fiori uygulamalarında güvenliği nasıl sağladığını ele alacağız.SAP Fiori Nedir?SAP Fiori, SAP...
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.