SAP veri taşıma neden başarısız olur ve nasıl düzeltilir

SAP veri taşıma, her şeyden çok tek bir nedenle başarısız olur: plan, bir ayıklamanın gösterdiğine değil, işletmenin verisinin nasıl göründüğünü düşündüğüne göre kurulur. Bu rehber, bir S/4HANA programındaki program direktörleri, veri liderleri ve finans liderleri için. Taşımaların neden bozulduğunu, cutover hatalarının çoğunun ardındaki beş hatayı, kopyalayabileceğiniz bir deneme yükleme planını ve 2026'da hangi SAP aracının hangi işe uyduğunu ele alıyor. Bu hafta tek bir şey yapacaksanız, müşteri, tedarikçi ve malzeme ana verilerinizin tam bir ayıklamasını alın ve kayıtları kendiniz sayın.

Bir üretim şirketi SAP implementasyonuna 18 ay ve 4,5 milyon dolar harcadı. Canlıya geçiş günü geldi. Herkes gergin ama heyecanlıydı. Sonra veri taşıma başarısız oldu.

Hiçbir şey düzgün çalışmadı. Müşteri verileri eksikti. Envanter rakamları yanlıştı. Muhasebe defterleri kapatamadı. CEO öfkeliydi.

Suç yazılımda değildi, implementasyon ekibinde de. Hata, işletmenin verisinin nasıl göründüğünü düşündüğü ile gerçekte nasıl göründüğü arasındaki boşluktaydı.

SAP'nin veri modeli düz bir içe aktarma değildir. Kayıtlar birbirine bağlıdır. Bir malzeme ana kaydı genel bir kayıt (MARA), tesis verisi (MARC), değerleme verisi (MBEW) ve MRP alanları kullanılıyorsa MRP alanı verisi (MDMA) içerir. Başlığı bağımlı görünümler olmadan yüklerseniz malzeme vardır ama hiçbir işlemde kullanılamaz.

S/4HANA kendi kuralını getiriyor. Müşteriler ve tedarikçiler iş ortaklarıdır (business partner). Eski bir müşteri, müşteri rolüne sahip bir business partner'a, bir tedarikçi ise tedarikçi rolüne sahip bir business partner'a dönüşür. Kredi limitleri, banka bilgileri ve vergi numaraları bu business partner'a bağlanır. Eski bir sistemin boşluklarla hoş gördüğü bir kayıt burada doğrulamadan geçemez.

Sonra hacim var. Çoğu şirket gerçekte ne kadar verisi olduğuna şaşırır. Bir müşteri yaklaşık 50.000 malzeme kaydı olduğunu düşünüyordu. Tüm varyantlar ve tesise özel kayıtlar sayıldığında rakam 500.000'e yakındı. İlk rakama göre boyutlandırılmış bir plan ikincisinden sağ çıkamaz.

İşletmenin tahminiTam ayıklama

Kapsamdaki malzeme kayıtları500,000+450,000 · +900%

İşletmenin tahmini50,000

Tam ayıklama500,000

• Her varyant ve tesise özel kayıt sayıldı
• Tahmine göre boyutlandırılmış bir plan buna dayanamaz

Bu bir veri taşıma sorunu değildi. Veri taşıma sorununa dönüşen bir kapsam sorunuydu.

Projenin başındaki veri kalitesi değerlendirmesi genellikle verinin bir incelemesi değil, bir tarifidir. Finans direktörü tedarikçi ana verisinin iyi bakımlı olduğunu söyler. Depo müdürü malzemelerin çoğunlukla temiz olduğunu söyler. Bunlar izlenimdir.

İlk ayıklama size gerçeği söyler. Yıllar önce temizlenmesi gereken ama temizlenmemiş tedarikçiler. Çok önce üretimden kalkmış ama hiç devre dışı bırakılmamış malzemeler. Ülke kodları tutarsız müşteri adresleri. Elektronik transferle ödenen tedarikçilerde eksik banka bilgileri.

Bunların her biri teknik bir düzeltme değil, bir iş kararı gerektirir. İki mükerrer tedarikçiden hangisinin doğru olduğunu yalnızca borç hesapları söyleyebilir. Hangi eskimiş malzemelerin bloke edileceğini ve hangilerinin geride bırakılacağını yalnızca satın alma söyleyebilir. Bu kararlar zaman alır ve veriyi bilen insanları gerektirir. Değerlendirme gerçek bir ayıklamaya dayanmıyorsa plan, veriyle karşılaşınca ayakta kalamayacak varsayımlar üzerine kurulmuştur. Ücretsiz veri taşıma tahmin aracım, gerçek sayılara sahip olduğunuzda eforu boyutlandırmaya yardımcı olur.

1. Taşımayı geç gelen teknik bir iş saymak

Taşıma her SAP Activate aşamasında yer almalı. Explore kapsamı tanımlar: nesneler, kaynak sistemler, hacimler ve kalite. Realize şablonları oluşturur ve deneme yüklemelerini çalıştırır. Deploy son provayı ve cutover yüklemesini yürütür. Run, ilk dönem kapanışının canlı veriyle mutabakatını yapar.

Taşıma işine Deploy'da başlayan projeler aylarca geç başlıyor demektir. Realize'da çözülmesi gereken kalite sorunları, cutover'dan haftalar önce ilk denemede ortaya çıkar. SAP takvim planlaması rehberim taşımanın genel planda nerede durduğunu gösteriyor.

2. İş tarafının çok az katılımı

Taşıma uygulamada teknik, karar almada ise bir iş faaliyetidir. BT mükerrer tedarikçilerin listesini üretemez. Hangi müşteri hesaplarının aktif olarak taşınacağı, hangilerinin geçmiş olarak kalacağı bir finans kararıdır. Eskimiş malzeme temizliği satın alma, depo ve ürün yönetimini gerektirir.

Taşımayı yalnızca teknik kişilerle donatan ve iş tarafını sonda bir imza olarak gören programlar, yüklenen bir veri üretir. Ticari açıdan yanlıştır.

3. Çok az deneme yüklemesi planlamak

İyi yürütülen bir SAP veri taşıma, cutover'dan önce en az üç deneme yüklemesi gerektirir; karmaşık programlar daha fazlasını. Bir ya da iki yükleme planlayan projeler temiz veri ve temiz eşleme için plan yapıyor demektir. Bu senaryo nadirdir. Daha fazla döngü, sorunlu bir taşımanın değil, düzgün planlanmış bir taşımanın işaretidir.

4. Deneme yüklemelerinin mutabakatını yapmamak

Hatasız biten bir yükleme işi doğrulama değildir. Doğrulama, yüklenenle beklenenin karşılaştırılmasıdır: kayıt sayıları, mali toplamlar, açık kalem bakiyeleri. Ardından bir süreç smoke testi verinin işlemlerde çalıştığını doğrular.

Mutabakatı yapılmamış bir deneme yüklemesi yine de zamana mal olur. Ortaya çıkardığı boşluk bir sonraki denemede hâlâ oradadır; yalnızca artık nedenine kadar izini sürmek daha zordur. Her yüklemenin mutabakatını, bir sonrakine başlamadan önce yapın.

5. Provalardan farklı bir cutover yüklemesi

Cutover taşıması son denemeyi birebir tekrarlamalı: aynı ayıklama betikleri, dönüştürme mantığı, yükleme sırası, kontroller ve zamanlama. Cutover'da yapılan her değişiklik, programın en yüksek baskılı noktasında test edilmemiş risktir.

En az test edilen parça genellikle delta'dır. Son deneme ile cutover arasında işletme tedarikçi eklemeye, sipariş değiştirmeye ve stok hareket ettirmeye devam eder. Veri dondurma tarihini tanımlayın ve delta yüklemesini son denemenin bir parçası olarak prova edin.

Bu döngü yapısını başlangıç noktası olarak kullanın. Her döngünün bir hedefi ve bir çıkış ölçütü vardır ve mutabakat imzalanana kadar tamamlanmış sayılmaz.

Döngü	Hedef	Çıkış ölçütü	Sahibi
Deneme 1	Yapı: her nesne bağımlılık sırasıyla yüklenir	Nesne bazında eşleme boşlukları ve format hataları kaydedilir	Veri taşıma lideri
Deneme 2	Kalite: eşleme düzeltmelerini sınayın ve veri sorunlarını ortaya çıkarın	Nesne bazında hata oranı düşüyor; temizlik kararları kaydedildi	Veri sorumluları
Deneme 3	İş kuralları: istisnalar ve uç durumlar	Sorumlular her alanda mutabakatı yapılmış bir örneği kabul eder	Veri sorumluları
Deneme 4	Tam üretim boyutunda hacim ve zamanlama	Tam yükleme cutover penceresi içinde tamamlanır	Cutover yöneticisi
Son prova	Delta ve dondurma dahil cutover'ın kostümlü provası	Sayılar ve mali toplamların mutabakatı yapıldı ve imzalandı	Mali kontrolör ve veri lideri

Bu planın etrafında farkı beş şey yaratır:

1. Prepare aşamasında tam bir ayıklama. Tamamı, örnek değil. Eksiksizliği, doğruluğu, tutarlılığı ve mükerrerleri profilleyin, ardından temizliğin ve takvimin boyutunu sonuçlardan belirleyin.
2. Nesne nesne eşleme. Her nesne için (business partner'lar, malzemeler, açık satın alma ve satış siparişleri, açık kalemler, stok, sabit kıymetler) kaynaktan hedefe alanları, dönüştürme kurallarını, doğrulama kontrollerini ve istisna kurallarını belgeleyin.
3. İsimle belirlenmiş veri sorumluları. Finans, müşteri ve tedarikçi finansal verisinin sahibidir. Satın alma, malzeme ana verisinin sahibidir. Depo, stokun sahibidir. Her sorumlu, her döngüden sonra kendi alanını imzalar.
4. Baştan tanımlanmış mutabakat. Bir yüklemenin doğru olduğunu hangi sayıların ve toplamların kanıtladığı konusunda ilk denemeden önce anlaşın, böylece cutover'da kimse bunu tartışmaz.
5. Yazılı bir cutover sırası. Dondurma, ayıklama, dönüştürme, yükleme, doğrulama, iş tarafı onayı, go/no-go. Son provayla aynı sıra.

Yeni bir S/4HANA implementasyonunda ilk yükleme için SAP'nin önerdiği araç şudur: SAP S/4HANA Migration Cockpit. S/4HANA 2020'den beri Fiori uygulaması Migrate Your Data olarak çalışır. LTMC işlem kodu kullanımdan kaldırılmıştır ve mevcut LTMC projeleri yalnızca görüntülenebilir. Uygulama iki yaklaşım sunar: hazırlık tabloları (staging tables) kullanarak veri taşımak (dosyalardan ya da kendi araçlarınızdan doldurulur) ve veriyi doğrudan bir SAP kaynak sisteminden taşımak. On-premise ve private cloud ekipleri standart nesneleri ayarlamak ya da kendi nesnelerini kurmak için taşıma nesnesi modelleyicisi olan LTMOM işlem kodunu kullanır. Cockpit ilk yüklemeler için tasarlanmıştır; yinelenen arayüzler ya da toplu değişiklikler için değil.

SAP Data Services, SAP'nin ETL platformudur. Yüksek hacimler, ağır dönüştürme mantığı, birden fazla kaynak sistem için ya da projeden uzun yaşayacak yeniden kullanılabilir bir veri kalitesi çerçevesi istediğinizde kullanın.

Üçüncü taraf ETL araçları (Informatica, Talend ya da Microsoft SSIS gibi), kuruluşun bunlara zaten sahip olduğu ve becerilerinin bulunduğu yerlerde mantıklıdır.

SAP Datasphere, artık SAP Business Data Cloud'un parçası, bir taşıma aracı değildir. Yeri, canlıya geçişten sonraki analitik katmandır. Geçmişi eski sistemde bırakıp yine de bunun üzerinde raporlama yapmanız gerekiyorsa önem kazanır.

Çoğu standart implementasyonda Migration Cockpit nesnelerin çoğunu karşılar. Yüksek hacimler, yoğun biçimde özelleştirilmiş eski sistemler ya da alışılmadık kaynak yapıları genellikle yanında Data Services ya da bir ETL aracı gerektirir. ECC'den dönüşümler farklı bir çalışmadır; ECC'den S/4HANA'ya geçiş rehberimde ele alıyorum.

SAP veri taşıma nedir?

SAP veri taşıma, bir implementasyon ya da dönüşümün parçası olarak eski sistemlerden veriyi ayıklamak, SAP'nin yapılarına ve kurallarına uyacak şekilde dönüştürmek ve SAP'ye yüklemektir. Tipik nesneler business partner'lar (müşteriler ve tedarikçiler), tesis verisiyle malzemeler, açık satın alma ve satış siparişleri, stok bakiyeleri, mali açık kalemler ve sabit kıymetlerdir. Zordur, çünkü SAP, eski sistemlerin çoğu zaman uygulamadığı bağımlılıkları ve doğrulama kurallarını zorunlu kılar.

SAP veri taşımada temel yaklaşımlar nelerdir?

Yeni bir implementasyon (greenfield), seçilmiş ana verileri ve açık kalemleri yeni bir S/4HANA sistemine yükler, geçmişi eski sistemde ya da bir arşivde bırakır. Bir sistem dönüşümü (brownfield) mevcut bir ECC sistemini ve geçmişini yerinde dönüştürür. Seçici veri geçişi ikisinin arasında durur ve seçilmiş şirket kodlarını, nesneleri ya da zaman dilimlerini taşır. Doğru seçim veri kalitesine, geçmiş gereksinimlerine ve eski sürecin ne kadarını korumak istediğinize bağlıdır.

SAP Migration Cockpit nedir ve ne zaman kullanılmalı?

SAP S/4HANA Migration Cockpit, S/4HANA'ya ilk veri yüklemesi için tüm sürümlerde SAP'nin önerdiği araçtır. S/4HANA 2020'den beri Fiori uygulaması Migrate Your Data olarak çalışır; LTMC işlem kodu kullanımdan kaldırılmıştır. Önceden tanımlı taşıma nesneleri sunar, veriyi kaydetmeden önce doğrular ve hataları alan düzeyinde raporlar. Standart nesneler için normal hacimlerde kullanın. Hacimler, dönüştürme mantığı ya da kaynak yapılar şablonların karşıladığının ötesine geçtiğinde SAP Data Services ya da başka bir ETL aracı ekleyin.

Bir SAP veri taşıma planı kaç deneme yüklemesi öngörmeli?

En az üç, sonuncusu tam bir cutover provası olacak şekilde. Karmaşık programlar daha fazlasını gerektirir. Tipik bir planda birincisi yapısal eşleme boşluklarını bulur. İkincisi düzeltmeleri sınar ve veri kalitesi sorunlarını ortaya çıkarır. Üçüncüsü iş kuralları ve uç durumlar üzerinde çalışır. Son çalıştırma cutover'ı birebir tekrarlar ve mutabakatı canlıya geçiş gününün temel çizgisi olur.

Müşterileri ve tedarikçileri SAP S/4HANA'ya nasıl taşırsınız?

Business partner olarak. S/4HANA'da müşteri ve tedarikçi ana verisi, müşteri ve tedarikçi rolleri eklenmiş business partner üzerinden yönetilir. Yeni bir implementasyonda Migration Cockpit bunları business partner nesneleri üzerinden yükler. ECC'den dönüşümde müşteri-tedarikçi entegrasyonunun dönüşümün kendisinden önce kurulup çalıştırılması gerekir.

SAP veri taşıma cutover'da neden başarısız olur?

Cutover hatalarının çoğuna beş örüntü yol açar. Çok az deneme yüklemesi. Uçtan uca hiç test edilmemiş bir cutover sırası. Son denemeden sonra eski sistemde değişiklikler ve test edilmemiş bir delta yüklemesi. Açık bırakılan mutabakat boşlukları. Bir örnekleme kontrolüne dayanan iş tarafı onayı. “İlk 1.000 kayıt iyi görünüyordu” doğrulama değildir. Canlıya geçiş, mutabakatı yapılmış sayılar ve toplamlar ister.