NegzelNegzel
Bize Ulaşın
Merkezi veri çekirdeği çevresinde yükselen soyut SAP S/4HANA bulut mimarisi

01SAP DÖNÜŞÜMÜ

SAP S/4HANA Danışmanlık

Doğru S/4HANA Dağıtım Modelini Birlikte Seçelim

Hedefiniz bulut ya da kurum içi olsun, SAP S/4HANA geçişini takvimi, bütçesi ve başarı ölçütleri baştan belli bir iş programı olarak yönetiyoruz.

Projenizi konuşalımModelleri inceleyin

MODEL 01 · DÖNÜŞÜM

SAP S/4HANA Dönüşüm

Mevcut ECC sisteminden SAP S/4HANA’ya geçişte yaklaşım kararı, teknik hazırlık ve proje yürütümü.

SAP S/4HANA’ya geçen kurumların büyük bölümü sıfırdan kurulum yapmıyor; yıllardır işleyen, özelleştirilmiş ve veri geçmişi dolu bir SAP ECC sistemini taşıyor. Projenin asıl konusu bu yüzden yeni sistemin kendisi değil, eskisinden ne kadarının geleceğidir.

Bu kararın üç yolu var: Brownfield (SAP’nin adlandırmasıyla System Conversion), Greenfield (New Implementation) ve Selective (Selective Data Transition). Her yol farklı bir süre, maliyet ve risk taşır; yanlış seçim projeyi gereksiz uzatır ya da yıllarca sürüklenecek teknik borcu yeni sisteme taşır. Kararı SAP Readiness Check çıktısı, özel kod envanteri ve süreç haritasıyla birlikte veriyor, ardından hazırlıktan canlıya geçişe kadar projeyi uçtan uca yürütüyoruz.

Üç yolda da hedef SAP S/4HANA’dır: kurum içinde ya da SAP S/4HANA Cloud Private Edition (yeni adıyla: SAP Cloud ERP Private) olarak. SAP S/4HANA Cloud Public Edition’a (yeni adıyla: SAP Cloud ERP) ise yalnız Greenfield ile geçilir.

Nereden başlanır?

Her dönüşüm mevcut sistemin ölçülmesiyle başlar: SAP Readiness Check raporu, sadeleştirme kalemi taraması ve özel kod envanteri. Bu üç çıktı olmadan verilen süre ve bütçe rakamları tahminden ibarettir.

Tek karar, üç yol

Hedef aynı; taşınan veri, değişen süreç ve proje süresi yaklaşıma göre baştan sona farklılaşır.

SAP ECC 6.0Mevcut sistem ve veri geçmişi
  1. BrownfieldSystem ConversionSistem yerinde dönüşür; veri yerinde kalır
  2. GreenfieldNew ImplementationSıfırdan kurulum; ana veri ve bakiye gelir
  3. SelectiveSelective Data TransitionSeçilen şirket kodları ve dönemler taşınır
SAP S/4HANAKurum içi ya da Private Edition

Yolu belirleyen: veri geçmişi, süreç değişimi, takvim

Mevcut sistemden ne kadarı gelecek?

Yol kararı verilmeden takvim ve bütçe konuşmak, projenin ilerleyen aylarında kapsam tartışmasına dönüşür.

  1. ECCS/4HANAtüm veri ve yapılandırma

    Yaklaşım 01

    BrownfieldSystem Conversion

    Mevcut sistem yerinde dönüştürülür. SUM; sürüm yükseltmesini, veritabanı SAP HANA değilse DMO ile veritabanı geçişini ve yeni veri modeline dönüşümü tek süreçte yürütür.

    • Tarihsel veri, açık kalemler ve belge numaraları yerinde kalır
    • Organizasyon yapısı ve şirket kodları korunur
    • Kullanıcı tarafında değişim yükü en düşük yol
    • Kullanılmayan özel kod da beraberinde gelir; kod temizliği bu yüzden dönüşümden önce yapılır
    • Süreç iyileştirmesi ayrı bir çalışma olarak planlanır

    Uygun olduğu durum: Süreçlerinden memnun, veri geçmişini korumak isteyen ve 2027 takvimi sıkışmış kurumlar.

  2. ECCS/4HANAyalnız ana veri ve açık bakiye

    Yaklaşım 02

    GreenfieldNew Implementation

    Sistem SAP’nin standart süreç içerikleriyle sıfırdan kurulur. Eski yapılandırma devralınmaz; yalnız ihtiyaç duyulan ana veri ve açık bakiyeler taşınır.

    • Yıllar içinde biriken gereksiz özelleştirmelerden arınma
    • Standart süreçlere ve temiz bir veri modeline geçiş
    • Clean core ilkesini baştan kurma imkânı
    • Tarihsel veri yeni sisteme gelmez; arşivde ya da salt okunur bırakılan eski sistemde tutulur
    • Değişim yönetimi ve eğitim yükü en yüksek yol

    Uygun olduğu durum: Süreçlerini yeniden tasarlamak isteyen, birleşme ya da bölünme yaşamış ya da mevcut sistemi aşırı karmaşıklaşmış kurumlar.

  3. S/4HANAseçilen şirket kodları ve dönemler

    Yaklaşım 03

    SelectiveSelective Data Transition

    İki yolun ortası. Hangi şirket kodlarının, süreçlerin ve kaç yıllık verinin taşınacağı tek tek seçilir; uzman araç ve yöntem gerektirdiği için ayrı bir çalışma çerçevesinde yürütülür.

    • Kritik veri taşınır, gereksiz olan geride kalır
    • Şirket kodu bazında aşamalı canlıya geçiş mümkün
    • Süreç iyileştirmesi ile veri sürekliliği bir arada
    • Planlama ve analiz en titiz çalışmayı ister
    • Uzman araç ve hizmet maliyeti projeye eklenir

    Uygun olduğu durum: Çok şirketli, çok ülkeli yapılar; bazı birimleri sadeleştirip bazılarını olduğu gibi taşımak isteyen gruplar.

Aşamalı bir dördüncü seçenek

  • Üç yolun yanında aşamalı bir seçenek de var: SAP Central Finance ile grubun finans kayıtları önce tek bir SAP S/4HANA sisteminde toplanır, şirketler kendi ERP’lerinde çalışmaya devam eder.

Dönüşüm süreci: dört aşama

Seçilen yoldan bağımsız olarak her dönüşüm aynı dört aşamadan geçer; değişen, aşamaların ağırlığı ve süresidir.

  1. Aşama 01

    Değerlendirme

    Mevcut sistemin ölçüldüğü ve yolun belirlendiği aşama.

    • SAP Readiness Check analizi
    • Sadeleştirme kalemi taraması
    • Özel kod ve add-on envanteri
    • Yol kararı ve iş gerekçesi

  2. Aşama 02

    Planlama

    Kapsamın, ekiplerin ve risklerin netleştiği aşama.

    • Proje planı ve kilometre taşları
    • Kaynak ve rol planı
    • Risk analizi ve kesinti stratejisi
    • Test ve eğitim yaklaşımı

  3. Aşama 03

    Dönüşüm

    Teknik ve fonksiyonel işin yürütüldüğü en yoğun aşama.

    • CVI ve özel kod düzeltmeleri
    • SUM ve DMO prova çalıştırmaları
    • Veri taşıma ve mutabakat
    • Entegrasyon ve kabul testleri

  4. Aşama 04

    Canlıya geçiş

    Kesimin yapıldığı ve sistemin rutine oturduğu aşama.

    • Cutover planının yürütülmesi
    • Son kullanıcı eğitimleri
    • Yoğun destek (hypercare) dönemi
    • AMS destek modeline devir

Örnek takvim: Brownfield (12 ay)

Kritik yol CVI ve özel kod düzeltmesinden geçer: ikisi bitmeden üretim kopyasıyla yapılan prova dönüşümü anlamlı sonuç vermez.

  1. Readiness Check ve SI-Check1-2. ay
  2. CVI: iş ortağına geçiş2-6. ay · kritik yol
  3. Özel kod düzeltmesi3-7. ay · kritik yol
  4. Sandbox dönüşümü4-5. ay · kesinti süresi ilk kez ölçülür
  5. DEV ve QAS dönüşümü6-8. ay
  6. Test döngüleri (SIT, UAT)8-10. ay
  7. Prova dönüşümleri8-11. ay · üretim kopyasıyla, en az iki tam prova
  8. Canlıya geçiş ve hypercare12. ay
  1. CVI ve özel kod kapanır, provalar başlar (7. ay)
  2. Canlıya geçiş (11. ay)

Örnek takvimdir; süre veri hacmine, özel kod büyüklüğüne ve entegrasyonlara göre değişir.

Örnek takvim: Greenfield (18 ay)

Ağırlık teknik dönüşümde değil, süreç tasarımı ve kullanıcı adaptasyonunda. Veri hazırlığı erken başlar; taşınacak ana verinin temizliği projenin en uzun kuyruğudur.

  1. Keşif ve hedef tasarım1-4. ay
  2. Fit-to-Standard atölyeleri3-8. ay
  3. Veri hazırlığı ve temizlik4-12. ay · kritik yol
  4. Yapılandırma ve geliştirme6-13. ay
  5. Veri yükleme provaları10-15. ay
  6. Test döngüleri (SIT, UAT)12-17. ay
  7. Eğitim ve kullanıcı adaptasyonu13-18. ay
  8. Canlıya geçiş ve hypercare17-18. ay
  1. Hedef süreç tasarımı onaylanır (4. ay)
  2. Fit-to-Standard çıktıları kapanır (8. ay)
  3. İlk tam veri yükleme provası (13. ay)
  4. Canlıya geçiş (17. ay)

Örnek takvimdir; SAP tek dalgalı Greenfield için 15-21 ay gösterge süre veriyor.

Brownfield’dan önce kapanan sekiz başlık

Brownfield’ı geciktiren genellikle SUM çalıştırmasının kendisi değil, öncesindeki hazırlıktır. Başlıkların bir kısmı aracı teknik olarak durdurur, bir kısmı durdurmaz; atlanan her başlık prova dönüşümlerinde geri gelir.

  1. SAP Readiness Check

    Mevcut sistemin SAP S/4HANA’ya hazırlık raporu: etkilenen işlevler, özel kod hacmi, veri büyüklüğü ve add-on uyumu. Projenin planı bu rapordan kurulur.

    Önerilir

  2. Sadeleştirme kalemi kontrolü (SI-Check)

    SUM içinde iki kez çalışır: süreç başında ve kesintiden hemen önce. Dönüş kodu 7 olan bulgular onaylanarak muaf tutulabilir; 8 ve üzeri çözülmeden kesinti aşamasına geçilmez (SAP Notu 2399707).

    Zorunlu

  3. CVI: iş ortağına geçiş

    Müşteri ve tedarikçi ana verisi iş ortağı (Business Partner) modeline taşınır; dönüşümün ön koşuludur (SAP Notu 2265093). Sahadaki deneyimimizde projelerin en çok zaman kaybettiği başlık budur.

    Zorunlu · SUM öncesi

  4. Özel kod analizi (ATC)

    ABAP Test Cockpit Z-kodun uyumunu tarar; SUM’ı durdurmaz. Asıl kazanç elemededir: kullanılmayan geliştirmeleri emekliye ayırmak düzeltilecek kodu küçültür.

    Önerilir

  5. Veri hacmi ve arşivleme

    Eski belgelerin arşivlenmesi ve teknik tabloların temizlenmesi dönüşüm süresini, kesinti penceresini ve bulut ortamındaki depolama maliyetini düşürür.

    Önerilir

  6. Add-on ve üçüncü taraf uyumu

    Her add-on’ın hedef sürümde dönüşüm yolu olmalı; desteklenenler SAP Notu 2214409’da. Yolu olmayan tek bir add-on dönüşümü durdurur.

    Zorunlu

  7. Maintenance Planner

    Bileşenleri, add-on’ları ve iş fonksiyonlarını denetler; uyumlu yol yoksa dönüşüme izin vermez, varsa hedef sürümün stack dosyasını üretir.

    Zorunlu

  8. SUM ve DMO çalıştırması

    Sürüm yükseltmesi, veritabanı geçişi ve SAP S/4HANA veri modeline dönüşüm tek süreçte yürür. Üretimden önce en az iki tam prova yapıyoruz; kesinti süresi ancak provada ölçülerek öngörülebilir olur.

    Zorunlu

Temizliği kalıcı kılmak

  • CVI için temizlenen iş ortağı verisi canlıdan sonra kendiliğinden temiz kalmaz. SAP MDG merkezi sürecini canlıdan önce ya da canlıyla birlikte açmak SAP’nin önerisidir; yeni ve değişen kayıt bundan sonra onaydan geçmeden dağıtılmaz.

ECC bakım takvimi

Dönüşüm kararını erteleyen kurumlar için asıl kısıt bütçe değil takvimdir; ortalama geçişin bir buçuk yıl sürdüğü düşünülürse karar penceresi göründüğünden dardır.

  1. EHP 5 ve altı: ana bakım bittiMüşteriye özel bakıma geçti
  2. EHP 6-8: ana bakımın sonuSAP ERP 6.0 için standart bakım
  3. Uzatılmış bakımın sonuÜcretli; bakım tabanına iki puan ek
  4. Transition option sonuSeçili büyük RISE müşterileri, 2031-2033
  5. S/4HANA bakım taahhüdüEn az bir sürüm 2040’a kadar bakımda

2030 sonrasında ECC

  • SAP ERP, private edition, transition option yalnız en büyük ve en karmaşık RISE with SAP müşterileri içindir: sistemin 2030 sonundan önce SAP HANA üzerindeki SAP ERP, private edition’a taşınması, en az 2 TB büyüklük ve max success plan şarttır.
  • SAP’nin Ekim 2026 açıklamasına göre üçüncü taraf veritabanında çalışan SAP Business Suite 7 sistemlerinde veritabanına özel destek 2030 sonunda bitiyor; bu tarihten sonra bu sistemlerden yalnız Greenfield ile geçilebilecek.

Dönüşümün somut karşılığı

SAP S/4HANA’ya geçiş günlük işleyişte dört şeyi değiştirir.

  • Tek muhasebe tablosu

    Genel muhasebe, kâr merkezi, duran varlık, malzeme defteri ve maliyet muhasebesi kalemleri Universal Journal’da (ACDOCA) tek tabloda buluşur; defterler arası mutabakat ihtiyacı azalır.

  • Anlık raporlama

    Raporlar toplam tablolarından değil işlem verisinin kendisinden okunur; gece toplu işini beklemeden güncel veriyle rapor alınır.

  • Rol tabanlı SAP Fiori

    Kullanıcı işlem kodu ezberlemek yerine iş rolüne tanımlı uygulamalarla çalışır; onay akışları standart olarak gelir.

  • Küçülen veri ayak izi

    Toplam ve indeks tablolarının kalkmasıyla veri hacmi daralır; bulut ortamında bu doğrudan bir maliyet kalemidir.

MODEL 02 · PUBLIC EDITION

SAP S/4HANA Cloud Public Edition

Standart süreçlerle hızlı, öngörülebilir ve SAP’nin işlettiği bulut ERP modeli.

SAP S/4HANA Cloud Public Edition (SAP Cloud ERP), SAP’nin işlettiği, birçok müşterinin aynı sistemi paylaştığı (multi-tenant) bir bulut ERP’sidir ve abonelikle lisanslanır. Bütün müşteriler aynı yazılım sürümünü ortak bir altyapı üzerinde kullanır; her müşterinin verisi ve yapılandırması kendi ortamında ayrı durur.

Sistem SAP Best Practices ile önceden yapılandırılmış süreçlerle gelir; işletmeler uzun analiz ve tasarım aşamalarına girmeden, kanıtlanmış süreçlerle canlıya geçer. Altyapıyı, yedeklemeyi, güvenlik yamalarını ve yılda iki kez (Şubat ve Ağustos) gelen sürümleri SAP yürütür; yapılandırma ve sürüm testi müşteridedir. Altyapı sağlayıcısını SAP belirler, veri merkezi bölgesini müşteri seçer.

Modelin taşıyıcı ilkesi Fit-to-Standard’dır: süreç sisteme uyarlanır, sistem sürece göre yeniden yazılmaz. Özel ihtiyaçlar çekirdeğe dokunmadan genişletme katmanında karşılanır; bu yüzden her sürümden sonra yeniden düzeltilmesi gereken bir özel kod yığını oluşmaz.

Kimler için uygun?

Standart süreçlerle çalışmaya hazır, az özel geliştirmeye ihtiyaç duyan şirketler ve sıfırdan kurulan yapılar. SAP, GROW with SAP (yeni adıyla: SAP GROW) paketini orta ölçeğe konumluyor; Public Edition’da büyük, çok ülkeli projeler de yürüyor. Bu sürüme geçiş yalnız Greenfield ile yapılır.

Ortak kod tabanı, ayrı veri alanları

Aynı SAP sürümü bütün müşterilerde çalışır; özelleştirme genişletme katmanına taşınır, çekirdek temiz kalır.

  1. 01

    Müşteri ortamları

    • Her müşterinin verisi kendi ortamında
    • Yapılandırma müşteriye özgü
  2. 02

    Tek ortak kod tabanı

    • Bütün müşterilerde aynı sürüm
    • Şubat ve Ağustos’ta büyük sürüm
  3. 03

    Genişletme katmanı

    • Anahtar kullanıcı araçları
    • ABAP Cloud (üç sistemli yapı)
    • SAP BTP’de yan yana uygulama
  4. 04

    Altyapı ve işletim: SAP

    • Barındırma, yedek ve güvenlik yamaları
    • Bölgeyi müşteri, altyapıyı SAP seçer
  • Planlı sürümlerYılda iki büyük sürüm (Şubat, Ağustos), arada aylık düzeltme paketleri; büyük sürümden önce dört haftalık test süresi.
  • Hızlı devreye almaSAP’ye göre projelerin çoğu 5-7 ayda canlıya geçer; kapsamı sabit SAP GROW Fast projelerinde 2-4 ay.
  • Öngörülebilir maliyetAbonelik modeli; kurum içi kuruluma göre düşük başlangıç yatırımı.
  • SAP’nin işlettiği altyapıBarındırma, yedekleme, güvenlik yamaları ve olağanüstü durum yönetimi SAP’de.
  • Hazır süreçler ve yerelleştirmeSAP Best Practices ile yapılandırılmış süreçler; SAP, 60 ülke ve bölge için hazır yerelleştirme sunar.
  • Üç yolla genişletmeAnahtar kullanıcı araçları, ABAP Cloud ile geliştirici genişletmesi (üç sistemli yapıda) ve SAP BTP’de yan yana uygulama.

Tek platformda uçtan uca süreçler

Public Edition, finanstan üretime aynı veri modeli üzerinde çalışan bütünleşik bir süreç kümesidir.

  • Finansal yönetim

    Genel muhasebe, dönem sonu kapanış, masraf yeri ve kâr merkezi muhasebesi, duran varlık muhasebesi ve grup raporlaması.

  • Satış

    Sipariş yönetimi, fiyatlandırma, teslimat ve faturalama.

  • Tedarik ve satın alma

    Talepten satın alma siparişine, fatura işlemeden stok ve depo yönetimine.

  • Üretim ve varlık yönetimi

    Üretim planlama, MRP ve kalite yönetimi; bakım yönetimi varlık yönetimi altında.

  • İnsan kaynakları

    Public Edition bir İK çözümü değildir; çalışan verileri SAP SuccessFactors Employee Central’dan SAP Master Data Integration ile aktarılır.

  • Sürdürülebilirlik

    Karbon muhasebesi için SAP Green Ledger, ürün ayak izi için SAP Sustainability Footprint Management ile entegre çalışır; ikisi de ayrı ürünlerdir.

GROW WITH SAP

Orta ölçek için hızlandırılmış giriş paketi

GROW with SAP (SAP GROW), Public Edition’a geçişi paketlenmiş bir programa dönüştürür. SAP’ye göre teknik canlıya geçiş dört ile altı hafta içinde olabilir; süreçlerin iş tarafında canlıya alınması kapsama ve veri hazırlığına göre daha uzun sürer. SAP, 2026 başında kapsamı önceden tanımlı SAP GROW Fast yaklaşımını duyurdu ve bu projelerde uygulama maliyetinin klasik ERP projelerine göre yüzde 40’a kadar düştüğünü söylüyor.

  • Hızlandırılmış SAP ActivateKanıtlanmış uygulama çerçevesi; öngörülebilir bir canlıya geçiş takvimi.
  • Hazır süreç içerikleriSektörler için önceden yapılandırılmış iş senaryoları ve örnek veri.
  • SAP BTP ve öğrenme kaynaklarıGenişletme için SAP BTP ve SAP Build; anahtar kullanıcı ve ekip için öğrenme kaynakları ve topluluk.

Örnek takvim: Public Edition’da Greenfield (6 ay)

Tek ülkede, orta kapsamlı bir kurulum için örnek takvim. Analiz aşaması kısadır; tartışma sürecin nasıl kodlanacağı değil, standart sürecin nerede uymadığı üzerinden yürür.

  1. Keşif ve hazırlık1. ay · Discover, Prepare: kapsam, ekip, deneme sistemi
  2. Fit-to-Standard atölyeleri2-3. ay · Explore: fark listesi, genişletme ihtiyacı
  3. Yapılandırma, entegrasyon ve test3-5. ay · Realize: veri yükleme provaları
  4. Canlıya geçiş ve hypercare6. ay · Deploy (hypercare dahil), ardından Run: AMS’ye devir
  1. Kapsam ve proje planı onaylanır (1. ay)
  2. Fark listesi kapanır (3. ay)
  3. Canlıya geçiş (5. ay)

Örnek takvimdir. SAP’ye göre Public Edition projelerinin çoğu 5-7 ay sürüyor; süre şirket kodu sayısına, entegrasyonlara ve veri kalitesine göre değişir.

Dört aşamada Public Edition

  1. Aşama 01

    Keşif ve hazırlık

    Kapsamın ve ekiplerin netleştiği, sistemin açıldığı kısa aşama.

    • İş gereksinimlerinin toplanması
    • SAP Best Practices kapsamıyla ön eşleştirme
    • Deneme sisteminin açılması
    • Proje planı, ekip ve karar düzeni

  2. Aşama 02

    Fit-to-Standard

    Standart sürecin canlı gösterildiği, farkların yazıldığı aşama.

    • Süreç bazlı atölyeler
    • Fark listesi ve çözüm kararları
    • Genişletme ihtiyaçlarının tespiti
    • Entegrasyon ve veri kapsamının tanımı

  3. Aşama 03

    Yapılandırma ve test

    Kararların sisteme işlendiği ve doğrulandığı aşama.

    • Fit-to-Standard yapılandırması
    • SAP BTP uzantıları ve entegrasyonlar
    • Veri taşıma provaları ve mutabakat
    • Birim, entegrasyon ve kabul testleri

  4. Aşama 04

    Canlıya geçiş

    Kesimin yürütüldüğü ve sistemin rutine oturduğu aşama.

    • Son veri aktarımı ve cutover
    • Son kullanıcı eğitimleri
    • Yoğun destek (hypercare)
    • AMS destek modeline devir

Yılda iki sürüm: 2026 takvimi

Public Edition’da güncelleme bir proje değil, takvimi önceden belli bir rutindir. Sürüm önce test sistemine iner, kurum regresyon testini dört haftalık pencerede yapar, ardından geliştirme ve üretim sistemleri güncellenir.

  1. 2602 sürümüTest 17-18 Ocak, üretim 14-15 Şubat
  2. 2608 sürümüTest 18-19 Temmuz, üretim 15-16 Ağustos
  3. Düzeltme paketleri (HFC)Yıl boyunca · ayda bir; bir haftalık ön izlemenin ardından
  1. 2602 üretimde (1.45. ay)
  2. 2608 üretimde (7.45. ay)

Sıradaki 2702 sürümü için planlanan tarihler: test sistemleri 16-17 Ocak 2027, geliştirme ve üretim sistemleri 13-14 Şubat 2027. Tarihler SAP’nin yayımladığı takvimden; SAP planı değiştirebilir.

MODEL 03 · PRIVATE EDITION

SAP S/4HANA Cloud Private Edition

RISE with SAP

Yazılımı, altyapıyı, süreç analizini ve geçiş hizmetlerini tek sözleşmede birleştiren bulut dönüşüm programı.

RISE with SAP; lisansı, barındırmayı, bakımı, süreç analizi araçlarını ve geçiş hizmetlerini tek bir abonelik taahhüdünde toplayan satın alma ve dönüşüm modelidir. Merkezinde SAP S/4HANA Cloud Private Edition (SAP Cloud ERP Private) durur: yalnız kuruma ayrılmış (single-tenant) bir sistem.

SAP’nin 2025’te yenilediği RISE with SAP paketi çekirdeğin yanında SAP Signavio ve SAP LeanIX yeteneklerini, SAP Build’i, SAP HANA Cloud’u, SAP Master Data Governance’ı ve SAP Business Network Supplier Portal’ı içerir; paket içeriği sözleşmeye göre değişir. Sistem SAP veri merkezinde, AWS, Microsoft Azure ya da Google Cloud üzerinde veya müşteri veri merkezi seçeneğinde çalışır ve her durumda SAP tarafından işletilir.

SAP ECC için ana bakımın 2027 sonunda bitmesi bu kararı çoğu kurum için takvimi belli bir gündem maddesine dönüştürdü. Hazırlık analizinden hedef mimariye, geçişten canlı sonrası iyileştirmeye kadar programın her adımında yer alıyoruz.

Kimler için uygun?

Mevcut ECC yatırımını ve özel geliştirmelerini korumak isteyen, ancak altyapı işletimini kendi üzerinde taşımak istemeyen orta ve büyük ölçekli kurumlar. Lisans, altyapı ve bakım kalemlerini tek bütçe başlığında toplamak isteyen şirketler için de uygundur.

Tek sözleşme, dört bileşen

ERP çekirdeği, genişletme platformu, süreç analizi ve tedarik ağı; altında tercih edilen altyapı.

  1. 01

    SAP S/4HANA Cloud Private Edition

    • Kuruma ayrılmış ERP çekirdeği (single‑tenant)
    • Klasik ABAP ve sektör süreçleri
  2. 02

    Paketteki yetenekler

    • SAP BTP: SAP Build, SAP HANA Cloud
    • SAP Signavio ve SAP LeanIX
    • SAP Business Network Supplier Portal
  3. 03

    Altyapı seçimi: SAP işletir

    • SAP veri merkezi
    • AWS, Microsoft Azure, Google Cloud
    • Müşteri veri merkezi

Sözleşmenin içindeki dört bileşen

Her bileşen ayrı bir yetenek alanını karşılar; birlikte ERP çekirdeğinden tedarik ağına uzanan bütünlüklü bir yapı kurarlar.

  • SAP S/4HANA Cloud Private Edition

    Programın ERP çekirdeği. Kuruma ayrılmış yapısı sayesinde klasik ABAP geliştirmeleri ve sektöre özgü süreç tasarımı korunabilir.

    • Kuruma ayrılmış ortam
    • Özel geliştirmelerin taşınabilmesi
    • Yükseltme zamanını müşteri belirler
    • Yerel yasal uyum paketleri

  • SAP Signavio

    Süreçleri varsayımla değil, sistemdeki gerçek işlem verisiyle ölçer; dönüşüm öncesi darboğazları, sonrasında iyileşmeyi görünür kılar.

    • Süreç madenciliği ve akış analizi
    • Sektörel karşılaştırma verileri
    • Standarttan sapmaların tespiti
    • Geçiş sonrası süreç izleme

  • SAP BTP

    Çekirdeği temiz tutmanın yolu. Özel ihtiyaçlar ERP’nin içine gömülmek yerine platformda ayrı bir katmanda geliştirilir.

    • Yan yana uygulama geliştirme
    • SAP Build ile düşük kodlu çözümler
    • SAP HANA Cloud ile veri katmanı
    • SAP Master Data Governance ile ana veri

  • SAP Business Network

    Tedarikçi ve ticaret ortaklarıyla kurulan dijital bağlantı katmanı; belge alışverişini standarda oturtur.

    • Tedarikçi portalı ve sipariş akışı
    • Elektronik belge alışverişi
    • Sipariş ve fatura durumunun izlenmesi
    • Ağ üzerinde ortak veri modeli

ALTYAPI SEÇİMİ

Altyapı kararı kurumda kalır

Seçim; mevcut bulut stratejisi, veri yerleşimi gereksinimleri, bölgesel erişim ve maliyet modeli birlikte değerlendirilerek yapılır. Hangi altyapı seçilirse seçilsin sistemi SAP işletir; bu değerlendirmeyi bağımsız biçimde yürütüyoruz.

  • Amazon Web ServicesGeniş bölge ağı ve olgun servis portföyü; iş yüklerini AWS’de çalıştıran kurumlar için tek sağlayıcıda toplanma.
  • Microsoft AzureMicrosoft ortamında çalışan kurumlar için doğal seçenek. Entra ID ile tek oturum açma SAP Cloud Identity Services üzerinden kurulur ve altyapıdan bağımsızdır.
  • Google CloudVeri ve analitik ağırlıklı kurumlar için. SAP Business Data Cloud Connect for BigQuery, SAP verisini ERP’nin çalıştığı altyapıdan bağımsız olarak BigQuery’ye bağlar.
  • SAP veri merkezleriTek muhatap tercih edildiğinde; altyapı ve uygulama işletimi aynı çatı altında.
  • Müşteri veri merkeziVeri yerleşimi zorunluluğu olan kurumlar için; sistem Dell, HPE ya da Lenovo donanımıyla kurumun kendi veri merkezinde çalışır.
  • Tek bütçe kalemiLisans, altyapı, bakım ve temel hizmetler tek sözleşmede toplanır.
  • 2027 takvimine hazırlıkECC ana bakımının bitişinden önce planlı ve kontrollü geçiş.
  • Ölçülebilir süreçlerSAP Signavio ile darboğazlar gerçek veriyle tespit edilir, iyileşme izlenir.
  • Planlı yenilikİki yılda bir ana sürüm, arada altı ayda bir özellik paketi; yükseltmeyi müşteri planlar, teknik işi SAP yapar ve yılda bir yükseltme talep edilebilir.
  • Güvenlik ve uyumSertifikasyon, erişim yönetimi ve veri koruma altyapı katmanında karşılanır.
  • Esnek ölçeklemeKullanıcı sayısı, kapsam ve kapasite iş büyümesine göre ayarlanır.

SAP Activate ile 12 aylık örnek geçiş

Orta ölçekli bir RISE with SAP geçişi için örnek plan. Her aşama bir aşama sonu kontrolüyle (quality gate) kapanır; bazı işler önceki aşamada hazırlanır, örneğin cutover Realize’da planlanır ve Deploy’da yürütülür.

  1. Hazırlık ve değerlendirme1-3. ay · Discover, Prepare: Readiness Check, altyapı ve geçiş yolu kararı
  2. Analiz ve hedef tasarım3-6. ay · Explore: Fit-to-Standard, fark listesi, SAP BTP mimarisi
  3. Gerçekleştirme ve test5-10. ay · Realize: dönüşüm provaları, veri, entegrasyon, kabul testi
  4. Canlıya geçiş ve hypercare10-12. ay · Deploy (hypercare dahil), ardından Run: AMS’ye devir
  1. Readiness Check ve geçiş yolu kararı (3. ay)
  2. Hedef tasarım onayı (6. ay)
  3. Kabul testleri biter (9. ay)
  4. Hypercare kapanır, AMS’ye devir (12. ay)

Örnek takvimdir; süre kapsama, şirket kodu sayısına ve seçilen geçiş yoluna göre değişir.

SAP Activate’in altı aşaması, dört adımda

  1. Aşama 01

    Hazırlık ve değerlendirme

    Mevcut durumun sayıya döküldüğü ve kararların verildiği aşama.

    • SAP Readiness Check analizi
    • Özel kod ve add-on envanteri
    • Arayüz ve entegrasyon haritası
    • Altyapı ve geçiş yolu kararı
    • Yol haritası, ekip ve bütçe planı

  2. Aşama 02

    Analiz ve hedef tasarım

    Standardın nerede yeteceğinin, nerede yetmeyeceğinin belirlendiği aşama.

    • Fit-to-Standard atölyeleri
    • Fark listesi ve çözüm kararları
    • Veri taşıma stratejisi
    • Entegrasyon ve SAP BTP mimarisi
    • İletişim ve eğitim planı

  3. Aşama 03

    Gerçekleştirme ve test

    Tasarımın çalışan sisteme dönüştüğü, projenin en yoğun aşaması.

    • Yapılandırma ve geliştirme döngüleri
    • Veri taşıma provaları ve mutabakat
    • SAP BTP uzantılarının geliştirilmesi
    • Entegrasyon ve kullanıcı kabul testleri
    • Kesim planı ve son kullanıcı eğitimleri

  4. Aşama 04

    Canlıya geçiş ve iyileştirme

    Kesimin yürütüldüğü ve sistemin işletme rutinine oturduğu aşama.

    • Cutover ve canlıya geçiş
    • Yoğun destek (hypercare)
    • Performans ve iş yükü izleme
    • SAP Signavio ile süreç ölçümü
    • AMS destek modeline devir

KARŞILAŞTIRMALAR

Modeller ve yollar yan yana

Public, Private ve kurum içi

Barındırma, güncelleme ve sorumluluk dağılımı üç modelde farklılaşır.

ÖlçütPublicSAP S/4HANA Cloud Public EditionPrivateSAP S/4HANA Cloud Private EditionKurum içiSAP S/4HANA (kurum içi)
DağıtımPaylaşımlı; herkes aynı sürümdeKuruma ayrılmış sistemKurumun kendi sistemi
BarındırmaSAP işletir; altyapıyı SAP, bölgeyi müşteri seçerSAP işletir; SAP veri merkezi, AWS, Azure, Google Cloud ya da müşteri veri merkeziKurumun veri merkezi ya da kendi IaaS sözleşmesiyle bir hyperscaler
ÖzelleştirmeAnahtar kullanıcı araçları, ABAP Cloud (üç sistemli yapıda) ve SAP BTP’de yan yana genişletmeAynı yollar artı klasik ABAP geliştirmesi; clean core önerilirTam; klasik ABAP dahil, clean core önerilir
GüncellemeYılda iki büyük sürüm (Şubat, Ağustos), arada aylık düzeltme paketleri; takvimi SAP belirlerZamanı müşteri seçer, teknik yükseltmeyi SAP yapar; ana bakımda kalmak için en az yedi yılda birYükseltme kararı ve zamanı kurumda; her sürüme yedi yıl ana bakım
Geçiş yoluYalnız GreenfieldBrownfield, Greenfield ya da SelectiveBrownfield, Greenfield ya da Selective
Uygulama süresiSAP’ye göre çoğu proje 5-7 ay; GROW Fast ile 2-4 ayYola göre 12-21 ay (SAP gösterge süreleri)Yola göre 12-21 ay (SAP gösterge süreleri)
Ticari modelAbonelik (GROW with SAP)Abonelik (RISE with SAP)Yazılım lisansı ve SAP bakım sözleşmesi
Yapay zekâBulut sürümüyle gelirBulut sürümüyle gelirSeçili senaryolara buluta geçiş taahhüdüyle erişilir
SorumlulukAltyapı, işletim ve sürümler SAP’de; yapılandırma ve sürüm testi müşterideAltyapı ve teknik işletim SAP’de; uygulama yönetimi müşteride ya da iş ortağındaAltyapı, işletim ve uygulama yönetimi kurumda ya da iş ortağında
Uygun profilStandart süreçlerle çalışmaya hazır şirketler; GROW orta ölçeğe konumlanırDerin özelleştirmesi ya da sektöre özgü süreçleri olan, çoğu ECC’den gelen şirketlerAltyapıyı kendi işletmek zorunda olan ya da veri yerleşimi kısıtı taşıyan kurumlar

Brownfield, Greenfield ve Selective

Karar tek ölçüte göre değil, bu başlıkların kurumunuzdaki ağırlığına göre verilir.

ÖlçütSystem ConversionBrownfieldNew ImplementationGreenfieldSelective Data TransitionSelective
Tarihsel veriTamamı taşınırTaşınmaz, arşivde kalırSeçilen kapsam kadar
Süreç değişimiSınırlı; iyileştirme ayrıca planlanırKapsamlı; standarda geçişSeçmeli; birim bazında
Tipik süre12-15 ay15-21 ay (tek dalga)12-18 ay
Kesinti penceresiUzun; veri hacmine bağlıKısa; son veri yüklemesiKısa; aşamalı yapılabilir
Özel kodDüzeltilerek taşınırYeniden değerlendirilirSeçilen kapsamla taşınır
Değişim yönetimi yüküDüşükYüksekOrta
Tipik profilSüreçleri oturmuş, veri geçmişini korumak isteyen şirketSüreçlerini yeniden tasarlayan, birleşme ya da bölünme yaşamış şirketBazı birimlerini sadeleştirip bazılarını olduğu gibi taşımak isteyen çok şirketli grup

Süreler SAP’nin yayımladığı gösterge aralıklardır (2024).

Tipik süre aralıkları

Her yolda süre, SAP’nin verdiği alt ve üst sınır arasında değişir.

  1. Brownfield12-15 ay
  2. Greenfield15-21 ay · tek dalga
  3. Selective12-18 ay
  1. ASUG araştırmasında ortalama geçiş: 1,5 yıl (18. ay)

Aralıklar SAP’nin planlama rehberinden (2024). ASUG’un 2025 araştırmasında ortalama geçiş bir buçuk yıl sürüyor; Horváth’ın 2025 araştırmasına göre projeler planlanandan ortalama yüzde 30 uzun sürüyor.

BAŞLAYALIM

Hangi model size uygun? Birlikte değerlendirelim.

Mevcut SAP ortamınızı, özel geliştirme yükünüzü ve regülasyon gereksinimlerinizi inceleyip size uygun dağıtım modelini ve geçiş yol haritasını çıkaralım.

Değerlendirme talep edin

ÖNCE SONUÇ

İş sonuçları

  1. 01

    Net hedef mimari

    SAP S/4HANA Cloud’un Public ve Private sürümlerini iş süreçleri, entegrasyon ve işletim gereksinimleriyle karşılaştıran karar zemini.

  2. 02

    Kontrollü geçiş

    Veri, geliştirme, test, eğitim ve cutover iş paketlerini tek yol haritasında yöneten uygulanabilir program.

  3. 03

    Sürdürülebilir çekirdek

    Clean-core prensipleriyle değişime açık, teknik borcu kontrol altında ve ölçülebilir SAP platformu.

ODAK

Neyi çözüyoruz?

  1. Belirsiz dönüşüm kapsamı

    Mevcut ECC veya S/4HANA yapısındaki süreç, geliştirme, veri ve entegrasyon bağımlılıklarını görünür hâle getiririz.

  2. Yanlış bulut seçimi

    Standartlaşma isteği ile esneklik ihtiyacını dengeleyerek Public ya da Private sürüm kararını kanıta dayandırırız.

  3. Canlı sonrası kırılganlık

    İşletim modeli, destek, izleme ve sürekli iyileştirme düzenini proje kapanmadan önce tasarlarız.

YÖNTEM

Nasıl çalışıyoruz?

  1. 01

    Keşfet

    SAP Activate’in Discover ve Prepare aşamaları: SAP Readiness Check, sadeleştirme kalemi taraması, özel kod ve add-on envanteriyle mevcut sistemi ölçer, süreçleri ve darboğazları ortak oturumlarla çıkarır, bulut modelini ve geçiş yolunu bu ölçüme göre seçeriz.

  2. 02

    Karar ver

    Explore: kapsamı ve kesinti stratejisini; Public sürümde Fit-to-Standard atölyelerinin fark listesini somut karar kayıtlarına bağlarız.

  3. 03

    Uygula

    Realize: CVI ve özel kod düzeltmesini, SUM ve DMO provalarını, veri taşıma ve mutabakatı, entegrasyon ve kabul testlerini tek teslimat planında yönetiriz.

  4. 04

    Güvenceye al

    Deploy ve Run: cutover’ı yürütür, hypercare döneminde sistemi yakından izler, yeni çekirdeği AMS destek modeline ve iyileştirme backlog’una devrederiz.

MERAK EDİLENLER

Sık sorulan sorular

SAP S/4HANA Cloud Public Edition ile Private Edition arasında nasıl karar verilir?

Kararı süreçlerin standarda uyumu, özel geliştirme ihtiyacı, entegrasyon yoğunluğu, regülasyonlar, güncelleme modeli ve işletim sorumlulukları üzerinden veririz. Tek bir doğru yerine kurumunuza uygun bir hedef model oluştururuz.

Mevcut geliştirmelerimizin tamamı taşınır mı?

Hayır. Kullanım, iş değeri ve standarda dönüş olanağı analiz edilir; gereksiz kod emekliye ayrılır, gerekli farklılaşmalar clean-core prensipleriyle yeniden konumlandırılır.

Canlıya geçiş riski nasıl azaltılır?

Tekrarlı veri geçişleri, uçtan uca testler, cutover provası, net geri dönüş ölçütleri ve görev bazlı hypercare planı aynı program içinde yürütülür.

ECC bakımı ne zaman bitiyor?

SAP ERP 6.0’da EHP 6, 7 ve 8 için ana bakım 31 Aralık 2027’de bitiyor; ücretli uzatılmış bakım 31 Aralık 2030’a kadar alınabilir. Uzatılmış bakım alınmazsa ya da bittiğinde sistem müşteriye özel bakıma geçer. EHP 5 ve altında ana bakım 31 Aralık 2025’te bitti. SAP, en az bir S/4HANA sürümünü 2040’a kadar bakımda tutmayı taahhüt ediyor.

Bütün şirketlerimizi aynı anda taşımadan ortak finans raporu alabilir miyiz?

Evet, SAP Central Finance ile. Şirketler mevcut SAP ERP, S/4HANA ya da SAP dışı sistemlerinde çalışmaya devam eder; FI ve CO kayıtları ortak ana veriye eşlenerek tek bir S/4HANA sistemine çoğaltılır. e-Defter’in kaynak sistemden mi merkezden mi alınacağı proje başında belirlenir.

SAP S/4HANA’ya geçmeden önce SAP MDG şart mı?

Hayır. Dönüşüm SAP MDG istemez; müşteri ve tedarikçinin iş ortağına taşınmasını (CVI) ister ve SAP Notu 2265093’e göre CVI tamamlanmamış sistemi kabul etmez. SAP, MDG konsolidasyonunu hazırlıkta tekrarsız bir ana veri havuzu için, merkezi süreci de canlıdan önce ya da canlıyla birlikte temizliği korumak için öneriyor. MDG ayrı lisanslanır.

BÜTÜN YOLCULUK

Diğer uzmanlık alanları

Hızlı erişim

SAP modül danışmanlığı

Finanstan üretime, entegrasyondan veriye kadar SAP modüllerinde danışmanlık veriyoruz.

Doğru danışmanı mı arıyorsunuz?Uzman SAP Danışmanı Bul
Finans8
İnsan kaynakları3
Lojistik11
Üretim7
Proje ve mühendislik2
Platform ve geliştirme4
Entegrasyon2
Veri ve kontrol3