SAP implementasyon şablonları: aşama aşama rehber

SAP Activate, bir S/4HANA programındaki neredeyse her çıktı için bir şablon sunar. Bunları SAP Activate Roadmap Viewer içinde ve bulut programlarında SAP Cloud ALM'in içinde bulursunuz. Bulmak kolay. Zor olan, hangilerini ciddiye almanız gerektiğini bilmek.

Bu rehber, bir implementasyonu kuran program yöneticileri, PMO liderleri ve sponsorlar için. Her aşamada ısrarla istediğim şablonları kapsıyor, her biri için çalışan bir yerleşim gösteriyor ve ekiplerin nerede köşe kestiğini işaretliyor. Kickoff'a bir haftanız varsa önce kapsam belgesini ve paydaş matrisini yapın. Sonrasındaki her şey bu ikisine yaslanıyor.

Üretim, perakende ve finansal hizmetlerde çalıştığım ECC ve S/4HANA programlarında örüntü tutarlı. Şablonları izleyen ekipler sorunları daha erken yakalıyor. Şablonları isteğe bağlı evrak işi sayan ekipler, hiç yazıya dökmedikleri her kararın bir kapsam anlaşmazlığına dönüştüğünü proje ortasında öğreniyor.

Bu, onaylanmış görmeyi beklediğim set; 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	Finansman serbest bırakılmadan
Prepare	Paydaş matrisi	Program yöneticisi	Explore atölyeleri planlanmadan
Explore	Gereksinim ve fit-gap tablosu	Çözüm mimarı, süreç sahipleriyle birlikte	Realize başlamadan
Realize	Konfigürasyon günlüğü	Fonksiyonel liderler	Her transport QA'ya taşınmadan
Realize	Özel geliştirme kaydı	Geliştirme lideri	Herhangi bir nesnede geliştirme başlamadan
Realize	Test stratejisi	Test yöneticisi	Sistem entegrasyon testi başlamadan
Realize	Veri migrasyonu planı	Veri migrasyonu lideri	İlk mock load'dan önce
Deploy	Cutover planı	Cutover yöneticisi	Son dress rehearsal'dan önce
Deploy	Canlıya geçiş hazırlık değerlendirmesi	Program direktörü (sponsor imzalar)	Go/no-go toplantısından önce
Run	Hypercare destek modeli	Hizmet sunum lideri	Canlıya geçişten önce
Run	Performans izleme tablosu	Basis lideri	Canlıya geçişten önce

Activate altı aşamadan oluşur: Discover, Prepare, Explore, Realize, Deploy ve Run. SAP Best Practices içeriğini, yönlendirmeli konfigürasyonu ve çevik bir teslimat yaklaşımını birleştirir. Müşterilerin çoğunda Discover sözleşme imzalanmadan önce gerçekleşir; bu yüzden aşağıdaki şablonlar Prepare ile başlıyor.

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

Her şablon kendi kapısından önce onaylandı

Aşama sırası isteğe bağlı değil. Bir kısmını atlamaya çalışıp üç aylık işi yeniden yapan bir perakendeciyle çalıştım. Her kalite kapısı bir nedenle var.

Şablonları uyarlarken standart yapının yaklaşık %80'ini koruyun. Yalnızca bağlamınızı yansıtan kısımları değiştirin: sektör gereksinimleri, düzenleyici kontroller, bölgesel özellikler. Her şeyi yeniden yazmak amacı boşa çıkarır.

2026'da araçlarda ne değişti

Activate yapısı eskisiyle aynı. Etrafındaki araçlar ise ilerledi.

1. SAP Cloud ALM, bulut programlarında şablonları barındırıyor. SAP'nin Solution Manager halefi; SAP Enterprise Support ile ve RISE with SAP gibi bulut aboneliklerinde dahil geliyor. Kapsam belirleme, gereksinimler, test planları ve cutover görevleri, aralarında izlenebilirlikle birlikte burada durabilir. Solution Manager 7.2 standart bakımdan 2027 sonunda çıkıyor, bazı işlevler için uzatılmış bakım 2030'a kadar sürüyor; yani mevcut on-premise ortamların önünde on yıl değil, birkaç yıl var.
2. Joule artık metodoloji araçlarının içinde. SAP, Joule'u 2025'te Activate Roadmap Viewer'da ve SAP Cloud ALM'de kullanıma sundu; böylece ekip yol haritasından görev rehberliği isteyebilir ya da içerik taslağı hazırlatabilir. İlk taslağı hızlandırıyor. Fit-gap'i imzalayan kişinin yerini tutmuyor.
3. Clean Core artık seviyeli bir tasarım kuralı. SAP, Ağustos 2025'te üç kademeli genişletilebilirlik modelinin yerine A'dan D'ye dört Clean Core seviyesi getirdi. Seviye A yalnızca yayımlanmış API'leri kullanır; ya SAP BTP üzerinde ya da sistem içinde ABAP Cloud ile. Seviye D hiç temiz değil. Fit-gap şablonunun, her boşluğun nereye düşeceğini gösteren bir sütuna ihtiyacı var.
4. Public edition fit-gap'i daraltıyor. SAP artık S/4HANA Cloud Public Edition'ı SAP Cloud ERP adıyla pazarlıyor ve orta ölçekli şirketlere SAP GROW olarak satıyor. Aynı altı aşama daha hafif çıktılarla geçerli ve yalnızca yayımlanmış API'lerle genişletmeye izin veriliyor; dolayısıyla "boşluk" sütununun olası yanıtları daha az.

Bu temeli atlayan projeler bedelini Explore ve Realize'da öder.

Proje kapsam şablonu

Projenin neleri içerdiğini ve neleri içermediğini tanımlar. Biri üç ay sonra kapsam eklemeye kalktığında (ve kalkacak), başvuru noktası bu belgedir. SAP proje şartnamesi (project charter) bunun üstünde durur ve yönetişim ayrıntılarını taşır.

Bölüm	Ayrıntılar
Başlık, sponsor, PM	SAP S/4HANA Finance implementasyonu; CFO; adı belli kıdemli proje yöneticisi
Arka plan	Mevcut durum ve değişimin nedeni
Hedefler	Kapanış döngüsünü 14 günden 5'e indirmek; elle yapılan mutabakatları ortadan kaldırmak
Kapsam içi	FI/CO, MM/SD entegrasyonu, veri migrasyonu, UAT, canlıya geçiş
Kapsam dışı	İK modülleri, eski raporların migrasyonu, ERP dışındaki üçüncü taraf entegrasyonları
Varsayımlar	Üst düzey sponsor aylık SteerCo için hazır; test verileri 6. haftaya kadar mutabık
Kısıtlar	Sabit canlıya geçiş tarihi; konfigürasyon için yalnızca iç kaynaklar
Çıktılar	Konfigüre edilmiş sistem, test planları, cutover planı, eğitim materyalleri
Zaman çizelgesi	Prepare: 1-4. haftalar; Explore: 5-10. haftalar; Realize: 11-26. haftalar
Onay	Explore başlamadan önce proje sponsorunun ve PMO'nun onayı gerekir

İş gerekçesi şablonu

Maliyet-fayda analizini finans ekibinin okuyabileceği bir biçimde ilerletir. Bu yapıyı kullanarak müşterilerimin ilk başvuruda program onayı aldığı oldu, çünkü rakamlar net ve varsayımlar yazılı.

Bağlı kaldığım bir kural: işi teslim edecek sistem entegratörü bu belgeyi yazmamalı. Onların teşviki başlamak. Sizinki bitirmek. SAP iş gerekçesi şablonum fayda modeline daha derin giriyor.

Bölüm	Ayrıntılar
Sahibi ve özet	CFO veya program direktörü; neden şimdi, ne değişiyor, ne aynı kalıyor
Sorun tanımı	Somut operasyonel sorunlar (kapanış döngüsünün uzunluğu, elle yapılan çözümler, sistem yaşı)
Önerilen yaklaşım	Greenfield / brownfield / selective, kapsam özetiyle
Faydalar	Sayısallaştırılmış: kapanış döngüsünden kazanılan günler, FTE tasarrufu, hata oranında azalma, denetim riskinde azalma
Maliyet ve finansman	Implementasyon, lisans veya abonelik, iç kaynak süresi, beklenmedik durum payı; bütçe kaynağı
Riskler	İlk üç risk, olasılık ve etkisiyle
Öneri	Devam / koşullu devam / erteleme, gerekçesiyle

Paydaş belirleme matrisi

Implementasyondan etkilenen herkesi ve etki düzeylerini haritalar. Kimin haftalık güncelleme alması, kimin yalnızca canlıya geçişten önce haberdar edilmesi gerektiğini bir bakışta söyler.

Paydaş	Rol	İlgi alanı	Etki	Katılım
Grup CFO'su	Üst düzey sponsor	Program yatırım getirisi, finans kapanışının iyileştirilmesi	Yüksek	Aylık SteerCo, haftalık yazılı güncelleme
BT Direktörü	Teknik sahip	Sistem kararlılığı, entegrasyon, güvenlik	Yüksek	Haftalık program kurulu, Realize sırasında günlük
Finans Direktörü	Kilit süreç sahibi	FI/CO tasarımı, kapanış süreci	Yüksek	Explore'da atölyeler, UAT onayı
Fabrika Müdürleri	Etkilenen kullanıcılar	MM/PP süreç değişiklikleri	Orta	Aylık değişim iletişimi, UAT katılımı
Son kullanıcılar (AP/AR)	Operatörler	İşlem düzeyindeki değişiklikler	Düşük	Eğitim, hypercare desteği
İç Denetim	Yönetişim	İzlenebilirlik, kontroller, uyumluluk	Orta	Kalite kapılarında çıktı incelemeleri

Aynı matrisi, bölümlere göre üst düzey gereksinimleri toplayan Prepare atölyelerini planlamak için kullanın. Bu gereksinimleri Explore'da kullanacağınız biçimde (REQ-001 ve devamı) numaralandırın; böylece hiçbir şey sonradan yeniden numaralandırılmaz ve ilk talebe kadar izlenebilirlik korunur.

Explore, implementasyonun şekil aldığı yer. Bu şablonlar, SAP'nin kutudan çıktığı gibi yaptığı ile iş biriminin ihtiyacı arasındaki farkı ortaya çıkarır.

Gereksinim eşleme ve fit-gap şablonu

Gereksinim eşleme, iş ihtiyaçlarını bölüme göre toplar ve her birini bir sistem bileşenine ve bir test senaryosuna kadar izler. Bunu atlayıp sonunda kimsenin kullanmadığı sistemlerle kalan şirketler gördüm; çünkü geliştirme, iş biriminin söylediklerine değil danışmanların varsaydıklarına dayanıyordu.

Fit-gap analizi ise standart SAP'nin her ihtiyacı nerede karşıladığını, nerede karşılamadığını gösterir. Müşterilerimin çoğu için gerçek bir göz açıcı. Bir ekibin pahalı özel kod yerine standart işlevselliği kullanabileceğini fark ettiği anı izlemeyi seviyorum.

İkisini de çözüm yolu için bir sütunla tek bir tabloda tutuyorum. S/4HANA'da her boşluğun açık bir yanıtı olmalı: standart konfigürasyon, key user uzantısı, sistem içinde geliştirici uzantısı veya SAP BTP üzerinde yan yana (side-by-side) uzantı. SAP koduna klasik modifikasyonlar en pahalı yanıttır ve adı belli bir onaylayıcı gerektirmelidir.

Gereksinim No	Gereksinim	SAP bileşeni	Fit / Gap	Çözüm yolu	Test ref.
REQ-001	Otomatik ay sonu kapanış yevmiyeleri	FI-GL, dönem sonu kapanışı	Fit	Yinelenen belge şablonlarını yapılandırın	TC-001
REQ-002	Fiori ile satın alma siparişi onayı	MM satın alma, Fiori onay uygulaması	Gap (ECC'de yok)	Standart S/4HANA uygulaması ve iş akışı konfigürasyonu	TC-003
REQ-003	Şirketlerarası faturalama otomasyonu	SD faturalama, FI entegrasyonu	Gap	Şirketlerarası faturalama konfigürasyonu	TC-010
REQ-004	Batch job izleme	Application Jobs uygulaması	Fit	Standart uygulama	TC-015
REQ-005	Tedarikçi self servis portalı	SAP Ariba veya tedarikçi portalı	Gap	Ariba entegrasyonu	TC-020
REQ-006	GDPR uyumlu veri arşivleme	ILM, veri arşivleme	Gap	ILM politikası konfigürasyonu	TC-025
REQ-007	Gerçek zamanlı maliyet merkezi raporlaması	CO, gömülü analitik veya SAC	Gap	Gömülü analitik veya SAC canlı bağlantısı	TC-030
REQ-008	500 eşzamanlı kullanıcıyı destekleme	HANA boyutlandırma	Gap (300 test edildi)	Boyutlandırma gözden geçirme ve altyapı artırımı	TC-035

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

Konfigürasyon takip şablonu

Her sistem değişikliğini kaydeder: kim yaptı, neden, hangi transport'ta gitti. Sonradan bir şey bozulduğunda sorunu günler değil dakikalar içinde izlersiniz.

1. Konfigürasyon kimliği ve modül: [örn. MM-CONF-001, MM]
2. IMG yolu ve konfigürasyon nesnesi: [örn. T161 tablosu, satın alma siparişi belge türleri]
3. Amaç ve etkilenen iş süreci
4. Yapılandıran kişi ve tarih
5. Transport talebi numarası: [örn. DEVK900123]
6. Anahtar değerler: önce ve sonra
7. Bağlı test senaryoları
8. Doğrulama ve onay durumu

Özel geliştirme kaydı

Her özel nesne, biri kod yazmadan önce bir satır alır. Müşterilerimden biri özel kodunu %30 azalttı, çünkü kayıt standart SAP'nin nerede gayet iyi çalışacağını gösterdi.

Geliştirme No	Nesne	Açıklama	Geliştirici	Efor (saat)	Durum	Uzantı türü
CD-001	Fiori kutucuğu: maliyet merkezi özeti	Finans için gerçek zamanlı CO raporlama kutucuğu	Fiori geliştiricisi	12	Tamamlandı	Geliştirici uzantısı
CD-002	Şirketlerarası faturalama raporu	Şirketlerarası mutabakat için rapor	ABAP geliştiricisi	20	Devam ediyor	Geliştirici uzantısı
CD-004	Tedarikçi ödeme durumu uygulaması	AP ödeme sorguları için Fiori uygulaması	BTP geliştiricisi	10	QA bekliyor	BTP'de yan yana (side-by-side)
CD-005	Mal girişi bildirimi	Mal girişi kaydında e-posta tetikleyicisi	Entegrasyon geliştiricisi	24	Planlandı	Olay tabanlı, BTP'de

Test stratejisi şablonu

Tüm test planlarını tek yerde toplar: kim neyi, ne zaman, hangi ortamda ve hangi standartta test eder.

Bölüm	Ayrıntılar
Kapsam	Kapsamdaki modüllerde fonksiyonel, entegrasyon, regresyon, performans, UAT (sızma testi bilgi güvenliği ekibinde)
Ortamlar	DEV, QA, UAT (canlı öncesi), son doğrulama için staging
Araçlar	SAP Cloud ALM veya Jira/Xray ile test yönetimi; Tricentis Tosca veya benzeriyle otomasyon; JMeter veya LoadRunner ile performans
Hata yaşam döngüsü	Yeni, Devam ediyor, Çözüldü, Doğrulandı, Kapatıldı; önem derecesi ve öncelik triyaj sırasında belirlenir
Çıkış kriterleri	Tüm kritik hatalar kapatıldı; UAT onayı alındı; regresyon başarı oranı en az %95; performans hedefleri karşılandı

Veri migrasyonu planlama şablonu

Veri migrasyonu size en çok zarar verme olasılığı olan iş akışı. Bu şablon onu, veri kalitesi sorunlarını cutover sırasında değil öncesinde ortaya çıkaran adımlara böler. Veri migrasyonu hata örüntüleri yazısı, atlandığında nelerin ters gittiğini anlatıyor.

Bölüm	Ayrıntılar
Kapsam	Müşteri ana verisi, tedarikçi ana verisi, açık kalemler, malzeme ana verisi, stok bakiyeleri, maliyet merkezi hiyerarşileri
Kaynak sistemler	ECC 6.0 EHP 7 (birincil); eski İK sistemi (çalışan maliyet merkezi atamaları)
Hedef sistem	S/4HANA (güncel sürüm)
Eşleme ve kurallar	Müşteriler ve tedarikçiler Business Partner'a; maliyet merkezleri yeni hiyerarşiye; geçersiz banka bilgileri kaldırılır; tekrarlayan kayıtlar birleştirilir
Migrasyon araçları	SAP S/4HANA Migration Cockpit (birincil); özel nesneler için Migration Object Modeler; ön işleme için betikler
Yükleme stratejisi	QA'da mock load; delta migrasyon ve mutabakat; canlı ortam cutover'ı
Doğrulama yaklaşımı	Kaynaktan hedefe kayıt sayıları; %10 rastgele örnekleme; bakiye mutabakat raporları
Geri alma planı	Cutover öncesi yedek; eski sistem 48 saat hazır bekletilir

Deploy aşaması canlıya geçtiğiniz yer. Bu şablonlar kaotik bir hafta sonunu yönetilen bir olaya çevirir.

Cutover planlama şablonu

Kesinti penceresini saat saat haritalar. Her görev, her sahip, her başlangıç saati. Ekibiniz gece 02:00'de ne yapacağını merak ederek ortada durmamalı.

Görev listesini yazmadan önce dört şeyde anlaşın: pencere (örneğin Cuma 22:00 ile Cumartesi 06:00 arası), geri alma tetikleyicisi, eski sistemin ne kadar hızlı yeniden etkinleştirilebileceği ve yeni sistemin çalıştığını kanıtlayan smoke testler. Ardından görev sırası:

Adım	Açıklama	Sahibi	Başlangıç saati	Durum
1	ECC sistemini dondurun (kayıt yok)	Basis	22:00	Bekliyor
2	Son veri çıkarımı ve mutabakat	Veri migrasyonu lideri	22:30	Bekliyor
3	Canlı migrasyon yüklemesini çalıştırın	DBA	23:00	Bekliyor
4	Kalan transportları canlı ortama aktarın	Basis	00:30	Bekliyor
5	DNS ve yük dengeleyiciyi S/4HANA'ya geçirin	Ağ	01:30	Bekliyor
6	Smoke test: FI kaydı, mal girişi, satış siparişi	QA lideri	02:00	Bekliyor
7	İş birimi onayı ve go/no-go kararı	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 değerlendirmesi

Gerçekten geçişe hazır olup olmadığınıza karar verir. Müşterilerimin bu değerlendirmeye dayanarak canlıya geçişi ertelediği oldu ve sonradan bana teşekkür ettiler.

Alan	Kontroller (her biri kanıtıyla birlikte evet ya da hayır yanıtlanır)
Fonksiyonel	Kilit süreçler test edildi; modüller arası senaryolar tamamlandı; açık P1/P2 hataları listelendi; kilit kullanıcılar hazır olduğunu onaylıyor
Veri	Ana veri yüklemeleri tamam; işlem verileri doğrulandı; mutabakat raporları onaylandı; eski sistemin dondurulması teyit edildi
Teknik	Cutover planı onaylandı; transportlar canlı ortamda; batch job'lar zamanlandı; izleme yapılandırıldı
İnsan	Eğitim kapsama yüzdesi; erişim rolleri doğrulandı; hypercare ekibi görevlendirildi; destek planı duyuruldu
Karar	Kritik riskler ve azaltma önlemleri listelendi; Go / No-go / Koşullu; ad, rol ve tarihle onaylandı

Canlıya geçişten sonra işin şekli değişir. Bu şablonlar sistemi ve ekibi hypercare boyunca ve kararlı duruma taşır.

Implementasyon sonrası destek şablonu

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

Bölüm	Ayrıntılar
Hypercare süresi	Canlıya geçişten sonraki 1-4. haftalar: 7/24 kapsama
Destek kanalları	ServiceNow olay kuyruğu (birincil); özel sohbet kanalı; P1 sorunları için telefon köprüsü
Destek kademeleri	1: servis masası (parolalar, gezinme, bilinen sorunlar); 2: fonksiyonel danışmanlar (süreç soruları, küçük konfigürasyon); 3: Basis ve geliştirme (sistem hataları, performans, arayüzler)
SLA'lar (yanıt / çözüm)	Kritik 15 dk / 2 sa; Yüksek 30 dk / 4 sa; Orta 4 sa / 1 gün; Düşük 1 gün / 3 gün
İzleme	SAP Cloud ALM veya Solution Manager; günlük hata günlüğü incelemesi
Çıkış kriterleri	Açık P1/P2 sorunu yok; tüm olaylar belgelendi; nihai devir onayı

Performans izleme şablonu

Sistem sağlığını gün be gün izlemenizi ve kullanıcılar şikâyet etmeden yavaşlamaları fark etmenizi sağlar. Yakın zamanda bir şirkete bu yolla, ay sonu kapanışında sistemlerini çökertecek bir veritabanı sorununu yakalamada yardım ettim.

Metrik	Hedef	Araç	Alarm eşiği	Sahibi
Diyalog yanıt süresi (95. yüzdelik)	1 saniyenin altında	ST03 / SAP Cloud ALM	2 saniye	Basis ekibi
Arka plan işi tamamlanması	Plana göre %100	SM37 / Application Jobs	Herhangi bir başarısız iş	Operasyon lideri
Veritabanı sorgu süresi	200 ms altında	SAP HANA cockpit	500 ms	DBA
Sistem erişilebilirliği	%99,5'in üzerinde	SAP Cloud ALM	%99'un altında	Altyapı
Arayüz hata oranı	%1'in altında	SAP Integration Suite izleme	%2	Middleware lideri
Giriş başarı oranı	%98'in üzerinde	Güvenlik denetim günlüğü	%95'in altında	Güvenlik lideri
Ay sonu kapanış işi çalışma süresi	Kararlaştırılan pencere içinde	İş zamanlayıcı	Referans değerin %30 üzerinde	Finans operasyonları

Kalite kapıları, bir aşamadaki sorunun bir sonrakinde pahalı yeniden işe dönüşmesini engeller. SAP kalite kapıları rehberim bunların nasıl kurulacağını anlatıyor. Burada neden önemli olduklarını yazıyorum.

Canlıya geçişten önceki üst yönetim onayı göz boyama olmamalı. Çalıştığım bir projede CEO, canlıya geçiş incelemesinde finans ekibinin çalışmasını aksatacak büyük bir sorunu yakaladı.

Her kapıda geçti/kaldı kriterleri belirleyin. "Regresyon testlerinin %95'i geçmeli." "Tüm FI entegrasyon senaryoları yeşil." Bunun gibi kriterler, iş birimi kaliteden bağımsız olarak belirli bir tarihte canlıya geçmek istediğinde çizgiyi korumanız için savunulabilir bir dayanak verir.

Projelerimden birinde, entegrasyon testlerinin yalnızca %75'i geçtiğinde kalite kapısı bizi durdurdu. Aceleyle ilerlemek yerine önce sorunları düzelttik. Bu, müşteriye canlıya geçişten sonraki acil düzeltmelerde yaklaşık €100.000 tasarruf sağladı.

Sponsorun tek bir telefonla geçersiz kılabildiği kapı, kapı değildir. İhtiyaç duymadan önce kimin muafiyet verebileceğini yazın.

SAP Activate metodolojisi nedir?

SAP Activate, SAP'nin S/4HANA ve diğer bulut ürünleri için implementasyon metodolojisidir. Altı aşamada ilerler (Discover, Prepare, Explore, Realize, Deploy, Run) ve SAP Best Practices içeriğini, yönlendirmeli konfigürasyonu ve çevik teslimatı birleştirir.

Her dağıtım senaryosunun görev listeleri ve çıktı şablonları SAP Activate Roadmap Viewer'da yayımlanır.

Hangi SAP Activate aşamasının şablonları en önemlidir?

Prepare. Kapsam belgesi, iş gerekçesi ve paydaş matrisi sonraki her kararın temelini atar ve ekiplerin konfigürasyona daha hızlı geçmek için atladığı şablonlar da bunlardır. Bu kestirme, Realize'daki kapsam anlaşmazlıklarının en yaygın nedenidir.

İkinci sırada Explore gelir. Fit-gap ve gereksinim eşleme belgelerindeki boşluklar, aylar sonra UAT hataları olarak ortaya çıkar; o zaman düzeltmek, Explore'un 3. haftasında düzeltmekten çok daha pahalıya gelir.

SAP Activate şablonlarını özelleştirebilir miyim?

Evet. Standart yapının yaklaşık %80'ini koruyun ve yalnızca bağlamınıza özgü olanı değiştirin: ilaç sektörü doğrulaması, kamu sektörü satın alma kuralları, SOX kontrolleri. Bunları Deploy'da değil, Prepare'in başında ekleyin.

Kalite kapısı yapısını, aşama sırasını veya zorunlu çıktıları (kapsam belgesi, iş gerekçesi, canlıya geçiş hazırlık değerlendirmesi) özelleştirmeyin.

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

Evet. Temel fark Explore'da. Brownfield dönüşüm mevcut konfigürasyonu taşır; dolayısıyla fit-gap neyin değişmesi gerektiğine, standart S/4HANA'nın artık hangi özel kodun yerini alabileceğine ve dönüşümden önce hangi veri temizliğinin gerektiğine odaklanır. Greenfield program SAP Best Practices ile başlar ve hangi standart süreçlerin uyduğunu doğrular.

Cutover planı da farklıdır. Brownfield sistem dönüşümü, tam veri migrasyonlu bir greenfield canlıya geçişten farklı bir sıra izler.

Cutover planı ne kadar ayrıntılı olmalı?

En az saat saat, kesinti penceresi için bundan da sıkı. Her görevin bir başlangıç saati, bir sahibi ve bir bağımlılığı olmalı.

Geri alma kriterlerini cutover başlamadan önce kararlaştırın: hangi koşullar eski sisteme dönüşü tetikler, bu kararı kim verir ve saat kaça kadar. Önceden kararlaştırılmış kriterler olmadan gece 4'te verilen geri alma kararları, canlıya geçiş sonrası felaketlerin başladığı yerdir.