SAP implementasyon şablonları: aşamalara göre SAP Activate seti

SAP Activate şablonları, SAP'nin bir S/4HANA programının her aşaması için yayımladığı implementasyon şablonları ve hızlandırıcılardır; Prepare'deki kapsam belgesinden Deploy'daki cutover planına kadar. Bunları SAP Activate Roadmap Viewer'da, bulut programlarında ise SAP Cloud ALM'de bulursunuz.

Kısa cevap: hepsine ihtiyacınız yok. Her birinin adı belli bir sahibi ve bir onay noktası olan yaklaşık bir düzine şablona ihtiyacınız var ve SAP'nin standart yapısının yaklaşık yüzde 80'ini korumalısınız. Aşağıdaki tablo, yönettiğim ya da kurtardığım 21 SAP programında ısrarla istediğim settir.

Şablonları bulmak kolaydır. Hangilerini ciddiye alacağınızı bilmek zor kısımdır.

Bu, onaylanmış görmeyi beklediğim SAP implementasyon şablon setidir; her birinin sahibi ve geçmesi gereken nokta ile birlikte.

Aşama	Şablon	Sahibi	Şundan önce onaylanır
Prepare	Proje kapsam belgesi	Program yöneticisi (sponsor onaylar)	Explore başlamadan
Prepare	İş gerekçesi	CFO veya iş sahibi	Bütçe serbest bırakılmadan
Prepare	Paydaş matrisi	Program yöneticisi	Explore çalıştayları planlanmadan
Explore	Gereksinimler ve fit-gap tablosu	Tasarım otoritesi (iş ve BT)	Realize başlamadan
Realize	Konfigürasyon kaydı	Fonksiyonel liderler	Her transport QA'ya geçmeden
Realize	Özel geliştirme kaydı	Geliştirme lideri	Herhangi bir nesnenin geliştirilmesi başlamadan
Realize	Test stratejisi	Test yöneticisi	Sistem entegrasyon testi başlamadan
Realize	Veri taşıma planı	Veri taşıma lideri	İlk deneme yüklemesinden
Deploy	Cutover planı	Cutover yöneticisi	Son genel provadan
Deploy	Canlıya geçiş hazırlık kontrol listesi	Program direktörü (sponsor imzalar)	Go/no-go toplantısından
Deploy	Hypercare destek modeli	Hizmet teslim lideri	Canlıya geçişten
Run	Performans izleme tablosu	Basis lideri	Canlıya geçişten

SAP Activate'in altı aşaması vardır: Discover, Prepare, Explore, Realize, Deploy ve Run. SAP Best Practices içeriğini, bir metodolojiyi ve rehberli konfigürasyonu bir araya getirir. Discover bağlayıcı olmayan araştırma aşamasıdır; bu yüzden çoğu müşteri için sözleşme imzalanmadan önce biter ve aşağıdaki şablonlar Prepare'de başlar.

1. 01DiscoverGenellikle sözleşme imzalanmadan önce
2. 02PrepareKapsam belgesi, iş gerekçesi, paydaş matrisi
3. 03ExploreGereksinimler ve fit-gap tablosu
4. 04RealizeKonfigürasyon kaydı, geliştirme kaydı, test stratejisi, taşıma planı
5. 05DeployCutover planı, canlıya geçiş hazırlığı, hypercare
6. 06RunPerformans izleme

Her şablon kendi kapısından önce onaylanır

Roadmap Viewer'da her yol haritası aşamalara, çıktılara ve görevlere ayrılır. Şablonlar hızlandırıcı olarak dosyalanır: ihtiyaç duyan göreve bağlı nasıl yapılır kılavuzları, örnek belgeler ve kontrol listeleri. Aşamaya, iş akışına veya hızlandırıcıya göre filtreleyebilirsiniz; bir aşamanın SAP Activate çıktılarını toplamanın en hızlı yolu budur.

Şablonları uyarlarken standart yapının yaklaşık yüzde 80'ini koruyun. Yalnızca bağlamınızı yansıtanı değiştirin: sektör gereksinimleri, mevzuat kontrolleri, bölgesel özellikler. Her şeyi yeniden yazmak, onları kullanma nedenini çöpe atmaktır.

Araçlarda ne değişti

Aşama yapısı aynı. Çevresindeki araçlar değişti.

1. Bulut programlarında şablonların yeri SAP Cloud ALM'dir. Müşterilere SAP Enterprise Support ile sağlanır ve RISE with SAP gibi SAP bulut abonelikleriyle birlikte gelir. Solution Manager 7.2, 2027 sonuna kadar ana akım bakıma, seçili fonksiyonlar için de 2030'a kadar uzatılmış bakıma sahiptir.
2. Joule metodoloji araçlarının içinde. SAP, 2025'te Joule'u Roadmap Viewer'a ve SAP Cloud ALM'ye ekledi; böylece bir ekip görev rehberliği veya ilk taslak isteyebilir. Joule, fit-gap'i imzalayan kişinin yerini almaz.
3. Clean Core'un artık seviyeleri var. SAP, Ağustos 2025'te A'dan D'ye dört Clean Core seviyesi tanıttı; A seviyesi yalnızca yayımlanmış API'leri kullanır, D seviyesi ise temiz değildir. Fit-gap tablonuzda her boşluğun nereye düşeceğini gösteren bir sütun olmalıdır.

Bu hazırlığı atlayan projeler bedelini Explore ve Realize'da öder. Bu üç belge, ekiplerin konfigürasyona daha hızlı geçmek için atladığı belgelerdir.

Proje kapsam belgesi

Programın neyi içerdiğini ve neyi içermediğini tanımlar. Üç ay sonra biri kapsam eklemeye çalıştığında (ve çalışacaktır) referans noktası budur.

Beklediğim bölümler:

1. Başlık, sponsor ve program yöneticisi.
2. Arka plan: mevcut durum ve değişikliğin nedeni.
3. Sayılarla hedefler, örneğin "kapanış döngüsünü 14 günden 5 güne indirmek".
4. Kapsam dahilindekiler, modül ve sürece göre (FI/CO, MM/SD entegrasyonu, veri taşıma, UAT, canlıya geçiş).
5. Kapsam dışındakiler, kapsam kadar açık yazılmış şekilde (İK, eski raporların taşınması, ERP dışı entegrasyonlar).
6. Varsayımlar ve kısıtlar, örneğin sponsorun aylık yönlendirme komitesine katılabilmesi ve sabit bir canlıya geçiş tarihi.
7. Aşamalara göre zaman çizelgesi; Explore başlamadan sponsor ve PMO onayıyla.

Zaman çizelgesini gerçekçi olanla karşılaştırın. Benim deneyimime göre GROW programları 6 ila 9 ay, RISE 9 ila 18 ay, brownfield dönüşümler 12 ila 18 ay, greenfield ise 18 ila 24 ay sürer; SAP implementasyon zaman çizelgesi rehberim bunu aşama aşama ayrıştırır.

İş gerekçesi şablonu

Maliyet-fayda analizini finans ekibinin okuyabileceği bir formatta ortaya koyar. Bu yapıyı kullanarak program onayını ilk başvuruda alan müşterilerim oldu; çünkü rakamlar nettir ve varsayımlar yazılıdır.

Yapı:

1. Sahibi ve özet: neden şimdi, ne değişiyor, ne aynı kalıyor.
2. Problem tanımı: kapanış döngüsünün süresi, manuel geçici çözümler, sistemin yaşı.
3. Önerilen yaklaşım: greenfield, brownfield veya seçici; kapsam özetiyle.
4. Sayısallaştırılmış faydalar: kapanıştan kazanılan günler, FTE zamanı, hata oranları, denetim riski.
5. Maliyet ve finansman: implementasyon, lisans veya abonelik, iç kaynak zamanı, yedek bütçe.
6. Olasılık ve etkisiyle birlikte en önemli üç risk.
7. Öneri: devam, koşullu devam veya erteleme.

Bağlı kaldığım bir kural var: işi yapacak sistem entegratörü bu belgeyi yazmamalıdır. Onun teşviki başlamaktır. Sizinki bitirmektir; SAP iş gerekçesi şablonum fayda modelini daha derinlemesine ele alır.

Paydaş matrisi

İmplementasyondan etkilenen herkesi, etkilerini ve onlarla nasıl iletişim kuracağınızı haritalar. Kimin haftalık güncellemeye, kimin canlıya geçişten önce bir uyarıya ihtiyacı olduğunu gösterir.

Her grup için rolü, ilgiyi, etkiyi ve iletişim biçimini kaydedin. Tipik bir set: sponsor olarak CFO (aylık yönlendirme komitesi), teknik sahip olarak BT direktörü, kilit süreç sahibi olarak finans direktörü, etkilenen kullanıcılar olarak fabrika müdürleri ile borç ve alacak hesapları kullanıcıları, kalite kapılarında da iç denetim.

Üst düzey gereksinimleri toplayan Prepare çalıştaylarını planlamak için aynı matrisi kullanın. Onları şimdiden Explore'da kullanacağınız formatta numaralandırın (REQ-001 vb.); böylece ilk talebe kadar giden iz kaybolmaz.

Explore, tasarımın SAP Best Practices'e karşı Fit-to-Standard çalıştaylarında sabitlendiği yerdir. SAP bütçelerinin aşıldığı yer de burasıdır; çünkü WRICEF sayısı (iş akışları, raporlar, arayüzler, dönüşümler, geliştirmeler ve formlar) burada büyür.

Aşama sırasının kaymasına izin vermeyin. 2023'te bir Avrupa perakende projesinde müşteri Explore'u atlamaya çalıştı ve üç ayı eksik gereksinimlere göre geliştirme yaparak geçirdi. SAP implementasyon maliyeti dökümüm, bu tür yeniden çalışmanın nasıl bütçeye dönüştüğünü gösterir.

Gereksinimler ve fit-gap tablosu

Gereksinim eşleştirme, her iş ihtiyacını bir sistem bileşenine ve bir test senaryosuna bağlar. Ardından fit-gap analizi, standart SAP'nin ihtiyacı nerede karşıladığını ve nerede karşılamadığını gösterir.

İkisini, çözüm yolu için bir sütun içeren tek bir tabloda tutarım. S/4HANA'da her boşluğun açık bir cevabı olmalıdır: standart konfigürasyon, anahtar kullanıcı uzantısı, sistem içinde geliştirici uzantısı ya da SAP BTP üzerinde side-by-side uzantı.

Gereksinim ID	Gereksinim	SAP bileşeni	Fit / gap	Çözüm yolu	Test ref.
REQ-001	Otomatik ay sonu kapanış kayıtları	FI-GL dönem sonu kapanışı	Fit	Yinelenen belge konfigürasyonu	TC-001
REQ-002	Mobilde satın alma siparişi onayı	MM satın alma, Fiori onay uygulaması	S/4HANA'da fit	Standart uygulama ve iş akışı konfigürasyonu	TC-003
REQ-003	Şirketler arası faturalama otomasyonu	SD faturalama, FI entegrasyonu	Fit	Şirketler arası faturalama konfigürasyonu	TC-010
REQ-004	Gizlilik kuralları için veri arşivleme	Information Lifecycle Management	Gap	ILM politika konfigürasyonu	TC-025
REQ-005	Gerçek zamanlı masraf yeri raporlaması	CO, gömülü analitik veya SAC	Gap	Gömülü analitik veya SAC canlı bağlantısı	TC-030
REQ-006	Tedarikçi self servis portalı	SAP Ariba veya tedarikçi portalı	Gap	Ariba entegrasyonu	TC-020

Paranın tasarruf edildiği yer burasıdır. 2023'te bir Avrupa üretim şirketinin ECC'den S/4HANA'ya taşınmasında fit-gap çalıştayları planlanan geliştirmeleri yüzde 35 azalttı ve tasarruf altı haneli rakamlara ulaştı.

Tablonun işlemesini iki kural sağlar. Kapsamı tedarikçi kontrol etmemelidir; çünkü geliştirme olarak işaretlediği her boşluk onun için faturalanabilir iştir. Clean Core kararlarının sahibi iş ve BT'den oluşan bir tasarım otoritesidir ve SAP kodundaki değişiklikler adı belli bir onaylayıcı gerektirir; SAP Clean Core stratejim seviyeleri açıklar.

Bu, geliştirme aşamasıdır. Bu şablonlar her konfigürasyon kararının, her geliştirmenin ve her test sonucunun denetim izidir.

Konfigürasyon kaydı

Her sistem değişikliğini kaydeder: kimin yaptığını, neden yaptığını ve hangi transport ile taşındığını. Daha sonra bir şey bozulduğunda sorunu günler yerine dakikalar içinde izlersiniz.

Her kayıtta şunlar olmalıdır:

1. Konfigürasyon ID'si ve modül (örneğin MM-CONF-001).
2. Konfigürasyon yolu ve değiştirilen nesne.
3. Etkilenen iş süreci ve nedeni.
4. Kimin, ne zaman konfigüre ettiği.
5. Transport talep numarası.
6. Önceki ve sonraki temel değerler.
7. Bağlı test senaryoları ve onay durumu.

Özel geliştirme kaydı

Her özel nesne, kimse kod yazmadan önce bir satır alır: ID, açıklama, geliştirici rolü, efor, durum ve uzantı türü. Clean Core'un uygulandığı yer uzantı türü sütunudur.

2024'te bir Avrupa perakende S/4HANA implementasyonunda bu kayıt planlanan özel kodu yüzde 30 azalttı. Standart SAP'nin gayet iyi çalışacağı yerleri gösterdi.

Test stratejisi

Tüm testleri tek bir yerde toplar: kimin neyi, ne zaman, hangi ortamda ve hangi standarda göre test ettiği.

1. Kapsam: kapsamdaki modüllerde fonksiyonel, entegrasyon, regresyon, performans testleri ve UAT.
2. Ortamlar: geliştirme, QA, UAT ve canlı öncesi.
3. Araçlar: SAP Cloud ALM'de veya mevcut aracınızda test yönetimi; otomasyon ve performans araçları adıyla belirtilmiş.
4. Önem derecesi ve önceliği triyajda belirlenen hata yaşam döngüsü.
5. Çıkış kriterleri: tüm kritik hatalar kapatılmış, UAT onaylanmış, önceden üzerinde anlaşılmış bir regresyon başarı oranı.

SAP Activate, Realize'ı entegrasyon testi ve kullanıcı kabul testiyle bitirir. Çıkış kriterlerini sonuçlar geldiğinde değil, testler başlamadan önce yazın.

Veri taşıma planı

Veri taşıma, size zarar verme olasılığı en yüksek iş akışıdır. Plan; kapsamı (iş ortakları, malzemeler, açık kalemler, bakiyeler), kaynak sistemleri, eşleştirme kurallarını, araçları (SAP S/4HANA Migration Cockpit), deneme yüklemelerini, doğrulamayı ve geri almayı kapsar.

Doğrulama, ekiplerin en az planladığı kısımdır: ilk deneme yüklemesinden önce kayıt sayılarında, örneklemede ve bakiye mutabakatında anlaşın.

SAP Activate'te Deploy; canlı ortamın kurulumunu, cutover'ı, canlıya geçişi ve hypercare'i kapsar. Bu şablonlar kaotik bir hafta sonunu yönetilen bir olaya dönüştürür.

SAP cutover planı şablonu

Cutover planı kesinti penceresini saat saat haritalar. Her görevin bir sahibi, bir başlangıç saati ve bir bağımlılığı vardır. Kimse gece 2'de ne yapacağını düşünerek ortada beklememelidir.

Görev listesini yazmadan önce dört konuda anlaşın: pencere (örneğin cuma 22:00'den cumartesi 06:00'ya), geri alma tetikleyicisi, eski sistemin ne kadar hızlı yeniden devreye alınabileceği ve yeni sistemin çalıştığını kanıtlayan smoke testleri. Ardından sıra:

Adım	Görev	Sahibi	Başlangıç	Durum
1	Eski sistemi dondurun (kayıt yok)	Basis	22:00	Bekliyor
2	Son veri çekimi ve mutabakat	Veri taşıma lideri	22:30	Bekliyor
3	Canlı ortama taşıma yüklemesi	Veri taşıma lideri	23:00	Bekliyor
4	Kalan transportların içe alınması	Basis	00:30	Bekliyor
5	Arayüzlerin ve ağ yönlendirmesinin geçişi	Entegrasyon lideri	01:30	Bekliyor
6	Smoke testi: FI kaydı, mal girişi, satış siparişi	QA lideri	02:00	Bekliyor
7	İş tarafının onayı ve go/no-go	Program direktörü	03:00	Bekliyor
8	Sistemi iş kullanıcılarına açın	Basis	06:00	Bekliyor

Canlıya geçiş hazırlık kontrol listesi

Geçişe gerçekten hazır olup olmadığınıza karar verir. Her madde kanıtla birlikte evet ya da hayır olarak cevaplanır.

1. Fonksiyonel: kilit süreçler ve modüller arası senaryolar test edilmiş, açık P1 ve P2 hataları listelenmiş, anahtar kullanıcılar hazır olduklarını teyit ediyor.
2. Veri: ana veriler ve işlem verileri yüklenmiş ve mutabık kılınmış, mutabakat raporları onaylanmış, eski sistemin dondurulması teyit edilmiş.
3. Finans: dönem sonu kapanış konfigürasyonu her şirket kodu ve tüzel kişilik için test edilmiş.
4. Teknik: cutover planı onaylanmış, transportlar canlı ortamda, arka plan işleri zamanlanmış, izleme yapılandırılmış.
5. İnsanlar: eğitim kapsamı, erişim rolleri doğrulanmış, hypercare ekibi kurulmuş.
6. Karar: kritik riskler ve önlemler, go / no-go / koşullu; ad, rol ve tarihle onaylanmış.

Finans satırının orada bir nedeni var. 2024'te GCC'deki bir perakende programında canlıya geçiş incelemesi, canlıya geçişten iki gün önce 25 tüzel kişiliğin tamamında bir finansal kapanış konfigürasyon sorununu yakaladı; bu sorun altı haneli bir kurtarma maliyetine yol açacaktı.

Bu değerlendirmeyi iki programda iki haftalık bir erteleme önermek için kullandım. Değerlendirmenin amacı budur.

Hypercare destek modeli

Lansmandan sonra sorunları nasıl ele alacağınızı düzenler. Bu model olmadan her sorun P1 olur.

1. Hypercare süresi ve kapsamı, örneğin uzatılmış çalışma saatleriyle dört hafta.
2. Destek kanalları: olay kuyruğu, bir sohbet kanalı ve P1'ler için bir telefon köprüsü.
3. Destek kademeleri: hizmet masası, fonksiyonel danışmanlar, ardından Basis ve geliştirme.
4. Önem derecesine göre yanıt ve çözüm süreleri.
5. Çıkış kriterleri: açık P1 veya P2 sorunu olmaması ve destek organizasyonuna imzalı bir devir.

Run, canlı sistemin desteklenmesi ve yönetimidir. Çoğu ekibin çok erken bıraktığı şablon, performansı izleyen şablondur.

Performans izleme tablosu

Sistem sağlığını gün gün izler; böylece yavaşlamaları kullanıcılar şikâyet etmeden fark edersiniz. 2024'te bir Avrupa finansal hizmetler programında, hypercare'in 3. haftasında, ay sonu kapanışı sırasında sistemi çökertecek bir veritabanı sorununu yakaladı.

İzlediğim metrikler, her biri bir hedef, bir uyarı eşiği ve bir sahiple:

1. Diyalog yanıt süresi (95. yüzdelik): hedef 1 saniyenin altı, uyarı 2 saniyede, Basis.
2. Arka plan işleri: yüzde 100'ü zamanında tamamlanır, her hatada uyarı, operasyon lideri.
3. Veritabanı sorgu süresi: hedef 200 ms'nin altı, uyarı 500 ms'de, veritabanı yöneticisi.
4. Arayüz hata oranı: yüzde 1'in altı, uyarı yüzde 2'de, entegrasyon lideri.
5. Ay sonu kapanış işlerinin çalışma süresi: üzerinde anlaşılan pencere içinde, uyarı temel değerin yüzde 30 üzerinde, finans operasyonları.

SAP Activate, kalite kapılarını aşama yol haritalarına yerleştirir ve her aşama için kontrol noktaları içerir. SAP kalite kapıları rehberim bunların nasıl kurulacağını anlatır; burada neden dişli olmaları gerektiğini anlatıyorum.

Her kapıda geçme ve kalma kriterleri belirleyin. "Regresyon testlerinin yüzde 95'i geçer." "Tüm FI entegrasyon senaryoları yeşil." Bu tür kriterler, iş tarafı kaliteden bağımsız olarak belirli bir tarihte canlıya geçmek istediğinde çizgiyi korumanızı sağlar.

2024'te bir Avrupa üretim programındaki kalite kapısı, entegrasyon testi başarı oranı yüzde 74'teyken bizi durdurdu. Bekledik, sorunları düzelttik ve iki hafta sonra canlıya geçtik. Canlıya geçişten sonraki ilk ayda destek talepleri, benzer programlarda genellikle görülenin yarısı kadardı.

Yönetim onayı da göstermelik bir imza olmamalıdır; yukarıdaki GCC perakende finansal kapanış sorunu tam olarak o incelemede yakalandı. Sponsorun tek bir telefonla geçersiz kılabildiği bir kapı, kapı değildir. Kapıdan kimin muafiyet verebileceğini, buna ihtiyaç duymadan önce yazın.

Bu şablonların etrafındaki sürecin tamamı için adım adım SAP implementasyon rehberime bakın.

Bu rehber, iş gerekçesinden canlıya geçişe kadar her konuya bağlantı veren SAP uygulama rehberimin bir parçasıdır.

SAP Activate şablonlarını nereden indirebilirim?

me.sap.com/roadmapviewer adresindeki SAP Activate Roadmap Viewer'dan. Dağıtım türünüzün yol haritasını açın, ardından her görevin şablonlarını, kılavuzlarını ve kontrol listelerini görmek için aşamaya veya hızlandırıcıya göre filtreleyin.

Bulut programlarında aynı içerik SAP Cloud ALM'de de bulunur; orada görevler ve çıktılar proje kapsamında takip edilebilir.

SAP Activate'in her aşamadaki çıktıları nelerdir?

Prepare kapsamı, planı, yönetişimi ve iş gerekçesini sağlar. Explore, Fit-to-Standard sonuçlarını, gereksinim ve fit-gap iş listesini ve çözüm tasarımını sağlar. Realize, entegrasyon testi ve kullanıcı kabul testi dahil olmak üzere konfigüre edilmiş ve test edilmiş sistemi sağlar.

Deploy cutover'ı, canlıya geçişi ve hypercare'i sağlar. Run, canlı sistemin desteklenmesini ve iyileştirilmesini kapsar.

En önemli şablonlar hangi SAP Activate aşamasındadır?

Prepare. Kapsam belgesi, iş gerekçesi ve paydaş matrisi sonraki her kararı belirler ve ekiplerin konfigürasyona daha hızlı geçmek için atladığı belgeler de bunlardır.

Explore hemen ardından gelir; çünkü fit-gap tablosu WRICEF sayısını belirler ve bütçeler orada aşılır.

SAP Activate şablonları özelleştirilebilir mi?

Evet. Standart yapının yaklaşık yüzde 80'ini koruyun ve yalnızca size özgü olanı değiştirin: ilaç sektöründe doğrulama kuralları, kamu sektöründe satın alma, SOX kontrolleri. Bu değişiklikleri Deploy'da değil, Prepare'in başında yapın.

Aşama sırasını, kalite kapılarını veya canlıya geçiş hazırlık değerlendirmesini özelleştirerek ortadan kaldırmayın.

Bir SAP cutover planı şablonu neleri içermelidir?

Kesinti penceresi için, her görevin sahibi, başlangıç saati ve bağımlılığıyla birlikte zamanlanmış bir görev listesi. Görev listesinden önce pencere, geri alma tetikleyicisi, eski sistemi yeniden devreye almak için gereken süre ve smoke testleri üzerinde anlaşın.

Cutover başlamadan önce geri alma kararını kimin, en geç saat kaçta vereceği konusunda anlaşın. Üzerinde anlaşılmış kriterler olmadan sabah 4'te verilen geri alma kararları, canlıya geçiş sonrası sorunların başladığı yerdir.

SAP canlıya geçiş hazırlık kontrol listesinde neler bulunur?

Fonksiyonel, veri, finans, teknik ve insan hazırlığı; her biri kanıtla evet ya da hayır olarak cevaplanır. Buna ek olarak adlar ve tarihlerle kayda geçmiş bir go / no-go kararı.

Canlıya geçişten önce dönem sonu kapanış konfigürasyonunu her tüzel kişilik için test edin. Sizi altı haneli bir kurtarma maliyetinden kurtarma olasılığı en yüksek kontrol budur.

SAP Activate şablonları greenfield ve brownfield için işe yarar mı?

Evet. Fark esas olarak Explore'dadır. Brownfield dönüşüm mevcut konfigürasyonu taşır; bu yüzden fit-gap, neyin değişmesi gerektiğine ve standart S/4HANA'nın artık hangi özel kodun yerini alabileceğine odaklanır. Greenfield bir program ise SAP Best Practices'ten başlar.

Cutover planı da farklıdır; çünkü bir sistem dönüşümü, greenfield veri yüklemesinden farklı bir teknik sırayı izler.