İçeriğe geç

SAP ECC'den S/4HANA'ya Geçiş Rehberi: 5 Kritik Aşama

Sahada öğrenilen gerçekler: hangi adımı atlarsanız projeniz nasıl raydan çıkar, nerede zaman ve bütçe kaybedilir.

Mustafa Önder Mustafa Önder  ·  6 Haziran 2026  ·  10 dk okuma

İçindekiler

  1. Neden S/4HANA? Gerçek Motivasyon
  2. Aşama 1 — Hazırlık ve Fizibilite
  3. Aşama 2 — Custom Code Analizi
  4. Aşama 3 — Veri Modeli Değişiklikleri
  5. Aşama 4 — Test Stratejisi
  6. Aşama 5 — Go-Live ve Stabilizasyon
  7. Sonuç ve Öneriler

SAP, 2027 yılında ECC için ana akım bakım desteğini sonlandırıyor. Bu tarih bir dönem kapanışından çok daha fazlası: ECC üzerinde kalan her kurum, gelecekteki SAP inovasyonlarına (yapay zeka, embedded analytics, Joule) erişimini kesiyor. S/4HANA geçişi artık bir tercih değil, zamanlanmış bir zorunluluk.

Ama bu geçişi başarıyla tamamlamak için "basit bir upgrade" beklentisiyle girmek en yaygın ve en pahalı hata. Bu rehberde 10+ yıllık saha tecrübemle geçişin 5 kritik aşamasını, atlanan adımların nasıl sonuçlandığını ve doğru yapıldığında nasıl görünmesi gerektiğini anlatıyorum.

Neden S/4HANA? Gerçek Motivasyon

Çoğu kurum S/4HANA geçişini zorlamak için "destek sonu" baskısını öne sürer. Bu doğrudur ama tek başına yeterli bir motivasyon değildir. Geçiş projesini yalnızca destek sonu kaygısıyla başlatan kurumlar genellikle şunu yapar: mevcut ECC süreçlerini olduğu gibi S/4HANA'ya taşır (brownfield), ve yıllarca biriken teknik borçlarını yeni sistemle birlikte de taşırlar.

Gerçek motivasyon şunlar olmalı:

  • Embedded Analytics: Ayrı BW/BI sistemine gerek kalmadan ACDOCA, MATDOC gibi tablolar üzerinde anlık raporlama.
  • Fiori UX: Kullanıcıların sahada mobil cihazdan da rahatça kullanabileceği modern arayüzler.
  • Simplified Data Model: Aggregate tablolarının kaldırılması performans artışı sağlar, ama bu yeni raporlama mantığı gerektirir.
  • Joule & AI: SAP'nin gelecekteki yapay zeka katmanı yalnızca S/4HANA üzerinde çalışacak.

Bu faydaları gerçekten elde etmek için geçiş stratejisinin baştan net belirlenmesi şart.

Aşama 1 — Hazırlık ve Fizibilite

Projeye başlamadan yapılması gereken en kritik adım: SAP Readiness Check raporunu çalıştırmak. Bu araç, mevcut ECC sisteminizi tarayarak S/4HANA uyumluluğunu analiz eder ve size şu soruların cevaplarını verir:

  • Kaç adet custom program Simplification List'teki değişimlerden etkileniyor?
  • Hangi SAP add-on'ları veya iş ortağı ürünleri henüz S/4HANA sertifikalı değil?
  • Business Functions veya Industry Solutions içinde uyumsuzluk var mı?

Greenfield mi, Brownfield mi?

Brownfield (System Conversion): Mevcut ECC sistemi doğrudan S/4HANA'ya dönüştürülür. Tüm tarihsel veriler ve özelleştirmeler korunur. Daha hızlı ve ucuzdur ama teknik borçları da taşır.

Greenfield (New Implementation): Temiz bir S/4HANA kurulumu yapılır, süreçler en baştan tasarlanır. Daha uzun ve maliyetlidir ama gerçek bir dönüşüm fırsatı sunar.

Tavsiyem: Eğer mevcut ECC sisteminiz yoğun özelleştirilmişse ve süreçlerinizi yeniden tasarlamak istiyorsanız Greenfield tercih edin. Acil destek sonu nedeniyle geçmek zorundaysanız Brownfield daha pratik olabilir — ancak teknik borçlarınızı en az ikiye katlayarak taşırsınız.

Aşama 2 — Custom Code Analizi ve Adaptasyonu

Türkiye'deki SAP kurulumlarının büyük çoğunluğunda, yıllar içinde yazılmış yüzlerce hatta binlerce "Z" program bulunur. Bu programların S/4HANA ile uyumluluğunu sağlamak, geçiş projesinin en uzun süren ve en fazla kaynak tüketen aşamasıdır. Kod düzeltmeleri sırasında modern ABAP söz dizimine geçmek, aynı eforla teknik borcu da azaltmanın en pratik yoludur.

Adım 1 — Dead Code Temizliği (SCMON)

İlk adım, hiç çalışmayan programları kapsam dışına almaktır. ABAP Call Monitor (SCMON) ile son 12-18 aydaki program çalıştırma logları analiz edilir. Deneyimlerimize göre kurumların Z kodlarının %25-40'ı artık hiç kullanılmıyor. Bu programları migration kapsamına dahil etmek hem zaman hem para kaybıdır.

Adım 2 — ATC S/4HANA Readiness Kontrolü

ABAP Test Cockpit'in S/4HANA Readiness Check varyantı çalıştırılır. Bu kontrol üç kategori hata üretir:

  • Kırmızı (Blocker): Go-live öncesi mutlaka düzeltilmesi gereken hatalar. Örneğin kaldırılan tablolara (BSIS, BSAS) doğrudan erişim.
  • Sarı (Warning): Çalışır ama performans veya uyumluluk riski taşır. Örneğin SELECT * kullanımı, INNER JOIN olmadan büyük tablolara erişim.
  • Mavi (Info): Değişen davranışlar hakkında bilgilendirme. Hemen düzeltme gerekmez.

Adım 3 — Remediation (Kod Düzeltme)

Kırmızı ve sarı bulgular öncelik sırasıyla düzeltilir. Eclipse ADT (ABAP Development Tools) üzerindeki Quick Fix özellikleri toplu düzeltmeler için kullanılır. Karmaşık tablo değişimlerinde (örneğin MSEG → MATDOC migrasyonu) kapsam analizi ayrıca yapılmalıdır: bazı durumlarda BAPI/FM kullanımına geçmek doğrudan tablo erişiminden daha güvenlidir.

Aşama 3 — Kritik Veri Modeli Değişiklikleri

S/4HANA'nın en büyük farkı veri modelindedir. HANA in-memory veritabanının gücünden yararlanmak için SAP, aggregate tabloların çoğunu kaldırmış ve verileri tek, merkezi tablolarda toplamıştır. Bu değişiklikleri anlamadan yazılan yeni raporlar ciddi performans sorunlarına yol açar.

Muhasebe: ACDOCA (Universal Journal)

ECC'de muhasebe verileri onlarca farklı tabloya dağılmıştı (BKPF, BSEG, BSIS, BSAS, FAGLFLEXA, GLT0...). S/4HANA ile birlikte bu tabloların hepsi ACDOCA altında birleştirildi. Sonuç: tek bir SELECT ile hem FI hem CO hem de Segment Reporting verilerine erişilebiliyor.

Eski tablolar "Compatibility View" olarak hâlâ var ama bu view'lar arkada ACDOCA'yı sorgular — yani performans avantajı yoktur. Yeni geliştirmelerin doğrudan ACDOCA (veya üzerine inşa edilmiş CDS View'lar) üzerinden yazılması şart. Bu konuyu ACDOCA ile finansal raporlama rehberinde kod örnekleriyle ayrıntılı ele aldım.

Lojistik: MATDOC (Material Document)

MKPF ve MSEG tablolarının yerini MATDOC tablosu aldı. Malzeme hareketi sorgularında bu değişim özellikle toplu raporlarda belirgin performans artışı sağlar. Öte yandan, MATDOC'a doğrudan SELECT yazmak yerine BAPI_GOODSMVT_* ve ilgili FM'lerin kullanılması SAP'nin önerisidir.

İnsan Kaynakları: SuccessFactors Entegrasyonu

S/4HANA on-premise ile gelen HCM modülü işlevsel olarak dondurulmuştur. Uzun vadeli strateji, SuccessFactors ile entegrasyon veya geçiştir. Türkiye'de SGK ve bordro entegrasyonları burada özel bir zorluk yaratır — bu alanı ayrıca planlamak gerekir.

Aşama 4 — Test Stratejisi

Geçiş projelerinde testin en sık ihmal edilen boyutu regresyon testidir. "Custom kodları düzelttik, çalışıyor" demek yetmez; iş süreçlerinin uçtan uca doğru çalıştığının doğrulanması gerekir.

Önerilen Test Katmanları

  • Unit Test (ABAP Unit): Düzeltilen Z kodların birim testi. Özellikle ACDOCA ve MATDOC'a geçilen raporlarda sonuçların ECC ile karşılaştırılması.
  • Integration Test: Kritik iş süreçlerinin (sipariş → sevkiyat → fatura döngüsü gibi) S/4HANA üzerinde eksiksiz çalıştığının teyidi.
  • Performance Test: Büyük hacimli sorgular için HANA Studio veya SAP HANA Cockpit üzerinde execution plan analizi. "Çalışıyor" ile "üretimde 100k satırda da çalışıyor" farklı şeylerdir.
  • UAT (User Acceptance Test): Anahtar kullanıcıların kendi iş süreçlerini test etmesi. Bu adım çoğu projede zaman baskısıyla atlanır ve go-live sonrası en büyük sorunların kaynağı olur.

Aşama 5 — Go-Live ve Stabilizasyon

Go-live haftası en kritik dönemdir. Sahada yaşanan en yaygın sorunlar:

  • Açık dönem verileri: Geçiş sırasında yarım kalan belgeler (açık siparişler, onay bekleyen faturalar) özel migration nesneleri gerektirir.
  • Eski raporlar hâlâ kullanılıyor: Kullanıcılar alışkanlıkla eski Z raporları çalıştırır. Bu raporlar S/4HANA'da daha yavaş çalışabilir veya hatalı sonuç üretebilir.
  • Hypercare eksikliği: Go-live sonrası minimum 4-6 hafta yoğun destek (hypercare) şart. Teknik ekip bu süreçte erişilebilir olmalı.

Go-live tarihi için öneri: mali yıl başlangıcı veya düşük iş yükü dönemi. Perakende sektöründe yoğun sezon (Kasım-Ocak) içinde go-live yapmak ciddi risk taşır.

Sonuç: Hazır Mısınız?

S/4HANA geçişi, doğru planlandığında hem teknik borçlarınızı temizleme hem de iş süreçlerinizi modernize etme fırsatıdır. Yanlış planlandığında ise bütçe aşımı, uzayan proje süreleri ve go-live sonrası kriz anlamına gelir.

Projenize nerede olduğunuzdan bağımsız olarak atmanız gereken ilk adım nettir: SAP Readiness Check çalıştırın ve sonuçları teknik bir gözle okuyun. Bu rapor olmadan yapılacak her plan tahmine dayanır.

10+ yıldır perakende, üretim ve enerji sektörlerinde S/4HANA projelerinde SAP geliştirme ve teknik danışmanlık hizmeti veriyorum. Readiness Check sonuçlarınızı birlikte değerlendirmek veya Custom Code analizinizi planlamak için benimle iletişime geçebilirsiniz.

S/4HANA geçiş projeniz için teknik danışmanlık alın.

Ücretsiz Ön Değerlendirme
← Blog'a Dön

İletişim

Projeleriniz için bizimle iletişime geçin.