BLOG
SAP Migrasyon Kokpiti İçin Ana Veri Hazırlığı
SAP S/4HANA Migrasyon Kokpiti aslında uslu bir araçtır. Temiz veri verirseniz yükler. ECC’den S/4HANA’ya geçişte ekiplerin anlattığı sıkıntıların çoğu — simülasyondaki hata listesi, üçüncü ve dördüncü yükleme turu, iki haftaya yayılan prova — araçtan değil, araca verilen veriden çıkar.
Bu yazı, Migrasyon Kokpiti için veri hazırlığını — ilk staging tablosu dolmadan önce yapılan ana veri işini — anlatıyor: “Migrasyon Kokpiti’ne hazır” ifadesinin somut karşılığı ve yüklemeyi tekrar turuna sokmadan simülasyondan geçiren uygulamalar. Veri borcunun neden biriktiği ve çalışmanın ne zaman başlaması gerektiği gibi program düzeyindeki sorular için ECC’den S/4HANA’ya veri geçişi rehberimize bakın. Burada son kilometreye odaklanıyoruz.
Migrasyon Kokpiti yüklemeleri neden başarısız olur
Kokpit veriyi girişte üç noktada denetler: staging tabloları doldurulurken yapı kontrolü, simülasyonda iş kuralları, gerçek yüklemede bir kez daha. Hatalar satır bazında döner; bu iyi bir şeydir, ama kötü bir extract’in tek bir net sorun yerine binlerce mesajlık bir tablo üretmesinin de sebebidir.
Hata biçimleri her projede aynıdır:
- Kaynakta opsiyonel, hedefte zorunlu. ECC ayarları hiç istemediği için on beş yıldır boş bırakılan bir alanı hedef model zorunlu tutuyordur.
- Karşılığı olmayan değerler. Ülke, bölge, vergi kategorisi, ölçü birimi, dil anahtarı… Eski client’ta geçerliyken hedefin kontrol tablolarında bulunmayan, ama ana verinin hâlâ referans verdiği kodlar.
- Format kayması. Tek dosyada üç ayrı tarih formatı, yanlış ondalık ayıracı, Excel’den geçerken baştaki sıfırları silinen hesap numaraları.
- Bağımlılık ihlalleri. Henüz yüklenmemiş bir nesneye referans veren kayıt.
- Mükerrer kayıtlar. Hedefte aynı anahtara düşen iki kaynak satır ya da adı biraz farklı yazıldığı için “yeni” görünen, aslında zaten var olan kayıt.
Bunların hiçbiri Kokpit’in hatası değil ve hiçbirini bulmak için Kokpit’e ihtiyaç yok. Hepsi extract’in içinde, sizin tarafınızda, ortada bir staging tablosu olmadan haftalar önce tespit edilebilir. Asıl mesele de zamanlama: aynı hata hazırlık aşamasında dakikalar, simülasyonda saatler, canlı geçiş provasında ise iş birimiyle pazarlık gerektiren günler demektir.
“Migrasyon Kokpiti’ne hazır” ne demek
Üç özellik ve dosyanın üçüne birden sahip olması gerekiyor.
Doğru yapı
Her migrasyon nesnesi kendi şablon yapılarıyla gelir ve şablon burada sözleşme yerine geçer. Güncel sürümlerde müşteri ve satıcı için bunlar CUSTOMER_2 ve VENDOR_2 şablon kuşaklarıdır.
En çok tekrar işi önleyen ayrım şu: şablonun içindeki sayfalar birer şablon yapısıdır, ECC tablosu değildir. Müşteri verisi KNA1, KNB1 ve KNVV’den çıkar; S_CUST_GEN, S_CUST_COMPANY, S_CUST_SALES_DATA, S_CUST_BANK_DATA ve S_CUST_TAXNUMBERS gibi yapılara girer. İki ayrışma birbiriyle ilişkilidir ama kaydı aynı yerlerden bölmez. Bazı yapı adları da adaşlarına fazla benzeyerek işi zorlaştırır — banka şablonundaki S_BNKA ile ECC’deki BNKA gibi. Birebir kolon kopyalamaya davet eder, sonra şablonun eklediği veya çıkardığı alanlarda takılırsınız.
Şablonu hedef sistemden, hedef sürümde indirin; alan listesini ve zorunluluk işaretlerini oradan okuyun ve spesifikasyon olarak onu kabul edin. Alan listeleri sürümler arasında değişir; önceki projeden kalma bir şablon kanıt sayılmaz.
Özel alanlar varsayılana bırakılamaz, karar ister. Extract’teki her Z alanı ya bilinçli olarak bir hedef alana eşleştirilmeli, ya bir uzantı olarak taşınmalı ya da kapsam dışı bırakılmalıdır; “Z alanlarına sonra bakarız” demek, bir yükleme turunu baştan almanın en bilinen yoludur.
Doğru değerler
Kodlu her alanın hedef client’ta karşılığının bulunması gerekir. Hata listesinin kayda değer bir kısmı buradan gelir, çünkü ayarları ve ana veriyi genelde farklı kişiler farklı takvimlerle taşır. Ayarlar önce gider ve tamam görünür; ayarların dışarıda bıraktığı kodlara referans veren ana veri ise yükleme çalışana kadar kimsenin bulgusu değildir.
Doğru sıra
Bağımlılıklar tercih değil, kısıttır ve üç katmanda birikir:
- Temel — banka ana verisi ve GL hesapları (GL için işletme hesap planı ile şirket kodunun hazır olması gerekir).
- Organizasyonel — masraf yerleri ve kâr merkezleri; altlarındaki GL ile şirket koduna bağımlıdır.
- Ana veri — sabit kıymetler, müşteri ve satıcı kayıtları, ürünler; her biri alttaki iki katmana referans verir.
Sonuç teorik değil, çok somuttur: banka ana verisinden önce müşteri yüklerseniz Kokpit satırları “Bank key does not exist” diyerek geri çevirir. Nesne sırasını daha hiçbir şey inşa etmeden belirleyin; yolun yarısında fark edilen yükleme sırası, baştan alınacak bir yükleme sırasıdır.
Sürümünüze ait nesne bazlı şablon ve ön koşul detayları SAP Help Portal’da. Aşağıdaki bölümler bu bilgiyle ne yapacağınızla ilgili.
Örneklemi değil, verinin tamamını analiz edin
Test yüklemeleri seçilmiş küçük örneklerle yapılır ve seçilmiş örnekler uslu durur. Ülke alanı boş iki bin kayıt da, vergi numarası alanına telefon yazılmış 1998 tarihli satıcı da tam extract’in içindedir. Tek bir eşleştirme kuralı yazmadan önce satırların yüzde yüzü üzerinde alan bazında tamlık, geçerlilik ve teklik analizi yapın; çıkan hata sayısını da baz olarak kaydedin — düzeltmeleri ölçebileceğiniz bir sayıya ihtiyacınız olacak.
Ekipler bu adımı yavaş olacağı varsayımıyla atlar. Olması gerekmez. S4Ready yüklenen extract’leri nesne bazında — Banka, Müşteri, Satıcı, GL Hesabı, Masraf Yeri, Kâr Merkezi, Sabit Kıymet ve Ürün — toplu iş olarak analiz eder; 100.000 satırlık müşteri ve satıcı setleri kolon bazlı işleme sayesinde dakikalar içinde analiz edilip doğrulanır.
Veriyi ECC’den çıkarmak ise ayrı bir iştir. S4Ready, RFC üzerinden çalışan bir Windows masaüstü Agent’ı ile nesne bazında kaynak tabloları okur — banka için BNKA ve ayar tabloları, müşteri için KNA1/KNB1/KNVV, satıcı için LFA1/LFB1/LFM1 — ve yükleme için manifest’iyle birlikte paketler. Çıkarma işlemi her şeyi çekmek yerine gerçekten kapsamdaki şirket kodları ve organizasyon birimleriyle sınırlanır; aynı çalıştırma S/4HANA hedefine bağlanıp referans verisini de çekebilir — “kodlu her değeri hedefe karşı kontrol edin” ilkesini, hedef daha tek bir satır görmeden çalıştırabileceğiniz bir işe dönüştüren şey budur. Basis tarafının kuruluma izin verdiği yönteme göre seçenekleri SAP ECC veri çıkarma rehberinde bulabilirsiniz.
Eşleştirmeden sonra değil, önce hedef kurallarıyla doğrulayın
Alışılmış sıra önce eşleştirip sonra hedefin sonucu geri çevirdiğini görmektir. Bunu tersine çevirin. Hedefin kurallarını kaynak veri üzerinde çalıştırın ki eşleştirme kararları, simülasyonda sınanacak bir varsayım olarak değil, hata listesi elinizdeyken verilsin.
Bunun aylar süren bir projede ayakta kalması için kuralların da birkaç özelliği olmalı:
- Katalogda dursun, script’in içine gömülmesin. Bir vergi alanının Türkiye’de neden farklı davrandığını bilen fonksiyonel danışman kuralı okuyabilmeli ve gerekiyorsa itiraz edebilmeli.
- Önem derecesi taşısın. Bloklayan hata ile uyarı ayrı konuşmalardır; ikisini karıştıran hata listesini kimse ayıklamaz.
- Tekrar çalıştırılabilsin. İki çalıştırma arasındaki fark, bir veri iş paketinin elindeki tek dürüst ilerleme göstergesidir.
S4Ready tam bu yüzden yaklaşık 150 doğrulama kuralını nesne bazında ayrılmış YAML kataloglarında tutar: kural okunabilir ve diff’lenebilir olur, arkeoloji gerektirmez. Her kural bir önem derecesi, uygulandığı alanlar, ürettiği mesaj ve gerektiğinde grid’in uygulayabileceği bir düzeltme önerisi taşır. Kurallar hedefin gerçekten kontrol ettiği ayrıntı seviyesinde çalışır: BANK_COUNTRY_MANDATORY her banka kaydında geçerli bir ISO 3166-1 alpha-2 ülke kodu arar, BANK_IBAN_COUNTRY_MATCH ise IBAN’ın ilk iki karakterinin bu ülkeyle tutarlı olmasını kontrol eder — yani boş-değil kontrolünden geçip yüklemede patlayan türden bir iç tutarsızlığı.
Eşleştirme de bununla birlikte yürür: ECC alanları Migrasyon Kokpiti şablonlarına otomatik olarak bağlanır, özel Z alanları ise sessizce dışarıda kalmak yerine açık bir Map, Extend veya Drop kararı için önünüze gelir.
Tekilleştirmeyi kanıtla yapın, tek tuşla değil
Tekilleştirme, geçişin politik olarak zorlaştığı yerdir: iki müşteriyi birleştirmek, arkasında kredi yönetimi, açık kalemler ve raporlama geçmişi olan bir iş kararıdır. “412 mükerrer çift bulundu, birleştir” diyen bir araç AR sorumlusuyla yapılan ilk toplantıdan sağ çıkmaz; çıkmaması da doğrudur.
Ayakta kalan yaklaşım iki katmanlıdır:
- Tartışmasız durumlar için deterministik anahtarlar — aynı vergi numarası ve ülke, normalize edilmiş ad ile posta kodunun birebir eşleşmesi. Bunlar toplantı gerektirmeden karara bağlanır.
- Geri kalan için olasılıksal eşleştirme: her biri skoru üreten alan bazlı kanıtı taşıyan, puanlanmış aday kümeler.
İnceleyen kişi böylece çiftlerle değil kümelerle çalışır ve kararını kanıt önündeyken verir. S4Ready iki katmanı da uygular ve kümeleri biri karar verene kadar beklemede bırakır; otomatik birleştirme yoktur. Her çiftin eşleşme olasılığını, eşleşme ağırlığını ve hangi sinyallerin katkı verdiğini gösteren bir açıklama kartı vardır; bu kart dosya olarak dışa aktarılıp kararın ekine konabilir. İncelenmemiş kümeler dışa aktarımı bloklar — böylece “mükerrerlere sonra döneriz” sessizce “mükerrerleri de yükledik”e dönüşemez.
Tekilleştirmenin çıktısı yalnızca mükerrerlerinden arınmış bir dosya değildir. Hangi birleştirmenin kim tarafından, neye dayanarak kararlaştırıldığının kaydıdır — altı ay sonra denetim sorusunu cevaplayan da odur.
Düzeltmeleri yeni bir extract’i atlatacak şekilde yönetin
Ana veri temizliği, teknikte tıkanmadan çok önce süreçte tıkanır. Kaçınılması gereken alışkanlık e-postayla dolaşan Excel’dir: XLSX_v14_final içindeki düzeltmelerin geçmişi, sahibi ve yeniden doğrulama yolu yoktur; taze bir extract geldiği anda da hepsi uçar ve iş baştan yapılır.
Bunun yerine ayakta kalan yapı:
- Düzeltmeler kaynağın üzerine yazılmak yerine yama olarak tutulur; uygulandığında yeni bir veri seti sürümü oluşur ve kaynak olduğu gibi kalır. Böylece yeni bir extract geldiğinde aynı kararlar yeniden verilmez, yeniden uygulanır.
- Sistematik sorunlar için toplu uygulama. Üç bin satırdaki tek bir ülke kodu düzeltmesi üç bin karar değil, tek karardır.
- Hücre bazında denetim izi — ne değişti, kim değiştirdi, ne zaman.
- Sonda, adı belli bir kişinin geçtiği bir kapı.
S4Ready’de bunun karşılığı Quick Fix Grid: doğrulama geri bildirimi hatalı satırın yanında durur, düzeltme hücre hücre ya da bir alanın tamamında birden uygulanır, her düzenleme uygulanana kadar beklemedeki bir yama olarak tutulur ve hücre bazında geçmiş korunur.
Onay iki katmanlıdır — Genel ve Şirket Kodu — böylece veriyi global sahiplenen kişi ile belirli bir şirket kodunda sahiplenen kişi ayrı ayrı imzalar; kaydı hazırlayan kişi kendi işini onaylayamaz. Onaylar imzaladıkları içeriğe sabitlenir; sonradan yapılan bir düzenleme onayı sessizce devralmaz, geçersiz kılar.
Kapının kendisi bir mod kararıdır ve kurulum başına değil, proje başına verilir. Aynı akış hem keşif ile temizlik sürerken onay kapılarını esnek bırakan Pilot modda, hem de prova ve üretim yüklemeleri için bu kapıları zorunlu kılan Governed modda çalışır. Governed modda onay kapıları geçilmeden dışa aktarım bloke kalır. Canlı geçiş gecesindeki acil durumlar için bir geçiş hakkı vardır, ama gerekçe kaydı ister ve denetim izine onay olarak değil, istisna olarak düşer. Fark tam olarak buradadır: kapıyı akış zorunlu kılar, etrafından dolaşmak ise iz bırakır.
Kokpit’in beklediği formatta dışa aktarın
Son kilometre mekaniktir ve yine de ters gider. Adı değişmiş bir sayfa, eksik başlık satırı, yeri değişmiş bir kolon, seri numarasına dönüşmüş tarihler, Excel hesap numarasını sayı sandığı için kaybolan baştaki sıfırlar.
Dosyayı elle Excel düzenleyerek değil, şablon sözleşmesinden üretin ve kanıtı veriyle birlikte taşıyın. S4Ready, Migrasyon Kokpiti paketlerini CSV veya Excel 2003 XML olarak dışa aktarır; paketin içinde veri dosyasından fazlası vardır: nesneyi, şablonu, kaynak sürümü ve onayları kaydeden bir README; sağlama dosyası; manifest; eşleştirme spesifikasyonu olan nesnelerde eşleştirme notları; bu extract’i üreten kayıt bazlı kararlar ile mükerrer kararlarının dökümü. README üretilemiyorsa dışa aktarım iptal edilir — izi sürülemeyen bir paket çıkmaz.
Bunun önemi tek bir anda ortaya çıkar ve doğaçlama için kötü bir andır: canlı geçiş provasında biri “bu dosyanın hangi sürümü onaylanmıştı?” diye sorduğunda cevabın paketin içinde olması gerekir.
Uygulayabileceğiniz veri hazırlığı sırası
- Nesne bazında veri setlerinin tamamını çıkarın. Örneklem değil.
- Tamlık, geçerlilik ve teklik analizi yapın. Baz hata sayısını kaydedin.
- Migrasyon nesnesi şablonlarını hedef sistemden, hedef sürümde indirin. Alan listelerini ve zorunlulukları önceki projeye göre değil, bu indirmeye göre doğrulayın.
- Kaynağı hedef kurallarıyla doğrulayın. Bloklayan hatalara göre sıralayın.
- Tekilleştirmeyi kanıtla yapın. Kümeler için iş birimi kararlarını alın ve kaydedin.
- Düzeltmeleri yönetilen bir grid’de yapın. Yeniden doğrulayın. Hata sayısının düşüşünü izleyin.
- Onaylayın — önce genel sahip, sonra şirket kodu sahibi.
- Paketi dışa aktarın, staging’i doldurun, simülasyonu çalıştırın.
- Simülasyondan çıkan hataları 4. adıma geri besleyin.
4 ile 7 arası bir döngüdür ve bu döngüyü erken ve sık çalıştırmak yöntemin kendisidir. Hedef, 9. adımın daha önce görmediğiniz hiçbir şey bulmamasıdır.
S4Ready bu akışın neresinde
S4Ready tam olarak bu aralık için yapıldı: extract sonrası, Kokpit öncesi. Yukarıdaki sekiz nesnede eski ana veriyi analiz eder, doğrular, otomatik onarır ve tekilleştirir; düzeltmeleri iki katmanlı onaya sahip yönetilen bir grid üzerinden geçirir; Migrasyon Kokpiti’ne hazır paketleri kanıtlarıyla birlikte dışa aktarır. Kurulum, kendi altyapınızda ya da özel bulutunuzda çalışan müşteri yönetimli bir sunucu olarak yapılır — bu iş yükü için önemlidir, çünkü banka bilgisi, vergi numarası ve kişisel veri tam da ana verinin içindedir ve burada kurumunuzun dışına çıkmaz. Arayüz İngilizce, Almanca, İspanyolca, İtalyanca ve Türkçe kullanılabilir. Ayrıntılar için ürün dokümantasyonuna ve ana veri geçişi iyi uygulamalar rehberine bakabilirsiniz.
Canlı geçiş için veri iş paketini planlıyorsanız S4Ready hazırlık akışının nasıl kurgulandığını inceleyin ya da tüm sırayı sentetik veriyle ücretsiz demoda baştan sona çalıştırın — kurulum yok, üretim sistemi yok.
