SAP implementasyon takvimi: aşama süreleri ve 5 hata

Deneyimime göre bir SAP implementasyonu GROW with SAP'de 6 ila 9 ay, RISE with SAP'de 9 ila 18 ay sürer. SAP ECC'den çıkış, brownfield dönüşümünde ya da seçici veri geçişinde 12 ila 18 ay, greenfield implementasyonda ise 18 ila 24 ay sürer.

Kısa cevap: tarihi kickoff'ta değil Explore'un sonunda kesinleştirin ve tedarikçi tahminine yüzde 15 ila 20 tampon ekleyin. Veri çalışmasına Discover'da başlayın, çünkü veri taşıma implementasyon eforunun yüzde 30 ila 40'ını alır. Her ek gecikme ayı yalnızca danışmanlık ücretlerinde en az altı haneli bir maliyet demektir.

Bu rehber, plan hazırlayan ya da bir planı kurtarmaya çalışan program direktörleri ve sponsorlar için. Konusu nasıl yapıldığı değil, ne kadar sürdüğü: her aşamanın ne yaptığını ve kimin yaptığını öğrenmek için adım adım SAP implementasyonu rehberimi okuyun.

2024'te Avrupa'da bir üretim programında, SAP projesi takvimin altı ay gerisinde kalan bir proje yöneticisiyle tanıştım. Projeyi sıkı biçimde SAP Activate aşamalarına göre yeniden kurduktan sonra kalan işi dört ayda bitirdiler.

Onun sözleriyle: "Belirli çıktıları olan net aşamalar her şeyi değiştirdi. Sırada ne yapmamız gerektiğini her zaman tam olarak biliyorduk."

Dağıtım modeli, SAP implementasyon takvimini diğer tüm seçimlerden daha fazla değiştirir. Planlamada esas aldığım aralıklar şunlardır:

Başlangıç noktası ve hedef	Tipik süre	Hızı ne belirler
GROW with SAP (SAP Cloud ERP, genel sürüm)	6 ila 9 ay	Yalnızca standart süreçler; yayımlanmış API'ler üzerinde uzantılar
RISE with SAP (SAP Cloud ERP Private)	9 ila 18 ay	Kapsam, uzantı sayısı, veri hacmi
ECC brownfield dönüşümü	12 ila 18 ay	Özel kod, basitleştirme kalemleri, testler
ECC'den greenfield implementasyon	18 ila 24 ay	Süreçlerin yeniden tasarımı, kullanıcılar üzerindeki değişim yükü
Seçici veri geçişi	12 ila 18 ay	Veri kapsamının belirlenmesi ve uzman araçlar

Karşılaştırma için: yüzlerce genel sürüm projesini inceleyen bir SAP ürün uzmanı, tipik canlıya geçişi beş ila yedi ay olarak veriyor. SAP'nin 2026 başında sunduğu GROW Fast teklifi, sabit kapsamla iki ila dört ayı hedefliyor. Ben GROW programlarını 6 ila 9 ay olarak planlıyorum, çünkü veri, kararlar ve eğitim, yazılımın almadığı zamanı alır.

RISE'da altyapıyı SAP yönetir; bu da Prepare'deki işin bir kısmını ortadan kaldırır. Veri, test ya da değişim eforunu ortadan kaldırmaz. ECC'den S/4HANA'ya geçiş rehberi brownfield, greenfield ve seçici arasında nasıl seçim yapılacağını açıklıyor.

Seyahat ve masraf ürünü SAP Concur, kendi projesi olan ayrı bir bulut ürünüdür. Onu S/4HANA aşama planının içinde değil, S/4HANA finansla kendi entegrasyonu olan ayrı bir iş akışı olarak planlayın.

Bütçeler ve tarihler nerede kırılır

Gördüğüm en büyük hata, başlangıçta düzgün planlama yapmamak. Tarihler ve bütçeler Explore'da aşılıyor: iş akışları, raporlar, arayüzler, dönüşümler, geliştirmeler ve formlar (WRICEF) listesi büyüyor ve kapsamı müşteri değil tedarikçi kontrol ediyor.

SAP implementasyon maliyet dökümüm bunun nasıl yüzde 50'lik bir aşıma dönüşebileceğini gösteriyor. Ayakta kalan takvimlerin üç ortak noktası var: gerçekçi tamponlar, kesinleştirmeden önce doğrulanmış varsayımlar ve kesin durma noktası olarak ele alınan kalite kapıları.

Aşımların çoğu beş hatadan kaynaklanır. Her biri öngörülebilirdir ve her birinin bir karşı önlemi vardır.

Hata 1: kapsam anlaşılmadan son tarih belirlemek

2023'te Körfez bölgesinde (GCC) bir perakende programında müşteri, yönetim kuruluna tamponsuz dokuz aylık bir implementasyon sözü verdi. Veri taşıma beklenenden uzun sürünce son tarihi üç ay kaçırdılar ve yöneticiler ekibe olan güvenlerini yitirdi. Onlara açıkça söyledim: o takvim fazla iddialıydı.

Çözüm: takvimi kickoff'ta değil Explore'dan sonra kesinleştirin ve bunu yönetim kuruluna en baştan söyleyin. Tedarikçi tahminine yüzde 15 ila 20 tampon ekleyin.

Hata 2: veri taşımayı geç başlayan bir iş akışı olarak görmek

Çoğu ekip veri taşıma liderini geç atar ve işe yetersiz kaynak ayırır. İlk veri değerlendirmeleri sorunu neredeyse her zaman olduğundan küçük gösterir ve ardından canlı sistem baskısı altında üç aylık bir temizlik gelir.

Çözüm: veri profillemeye Realize'da değil Discover'da başlayın. Entegrasyon testleri başlamadan önce Realize'da tam bir deneme taşıması yapın. SAP veri taşımanın neden başarısız olduğunu anlatan yazım deneme döngüsünü ayrıntılı ele alıyor.

Hata 3: takvim baskısı altında kalite kapılarını atlamak

Realize ile Deploy arasındaki kapı, ekiplerin en sık atladığı kapıdır, çünkü "hemen canlıya geçelim" baskısı orada zirveye çıkar. "Takvimde kalmak" için kalite kapılarını atlamak sonra daha büyük gecikmelere yol açar.

Çözüm: ölçülebilir çıkış kriterlerini proje tüzüğüne yazın ve bunları yönlendirme komitesinin uygulamasını sağlayın. Her programda hazırlık kapısı olarak üç günlük bir kapanış provası kullanırım. Kapı tasarımı hakkında daha fazlası SAP kalite kapıları rehberimde.

Hata 4: kullanıcıları canlıya geçişten iki ay önce eğitmek

2024'te Körfez bölgesinde (GCC) bir perakende programında müşteri tüm kullanıcılarını canlıya geçişten iki ay önce eğitti. Açılış gününe gelindiğinde çoğu sistemi nasıl kullanacağını unutmuştu. Her iş istasyonuna iş yardımcıları koyduk ve sahadaki desteği iki katına çıkardık.

Çözüm: eğitimi canlıya geçişten iki ila üç hafta önceye yerleştirin ve kilit kullanıcıları eğitmen olarak kullanın, çünkü insanlar güvendikleri meslektaşlarından öğrenir. SAP eğitim stratejileri yazım yaklaşımın tamamını içeriyor.

Hata 5: canlıya geçişi iş döngüsünün zirvesine denk getirmek

Hershey, SAP R/3, Siebel ve Manugistics sistemiyle Temmuz 1999'da, plandan üç ay geç ve doğrudan Cadılar Bayramı sipariş sezonunun içine canlıya geçti. CEO'su analistlere, sorunların Hershey'nin 100 milyon dolarlık Cadılar Bayramı siparişini teslim etmesini engelleyeceğini söyledi.

Çözüm: etkilenen her iş birimi için ay sonu ve çeyrek sonu kapanışları dahil yoğun dönemleri haritalandırın. Altı haftalık bir kayma anlamına gelse bile düşük hacimli bir pencerede canlıya geçin. Kayma telafi edilebilir, ama yoğun sezonda başarısız bir canlıya geçiş telafi edilemez.

SAP Activate altı aşamadan oluşur ve bu aşamalar bulutta ya da on-premise, her S/4HANA planının iskeletidir. Aşağıdaki süreler tek bir program için planlama başlangıç noktalarıdır, söz değildir.

1. 1Discover2 ila 4 hafta. Çıkış: imzalı kapsam ve başarı kriterleri
2. 2Prepare3 ila 6 hafta. Çıkış: tüzük onaylı, kaynaklar yazılı
3. 3Explore4 ila 8 hafta. Çıkış: açık kararlarının sahipleri belli, takvim kesin
4. 4Realize8 ila 16 hafta. Çıkış: deneme taşıması başarılı, entegrasyon testleri kapandı
5. 5Deploy2 ila 4 hafta. Çıkış: UAT onayı, kapanış provası, go/no-go
6. 6Run4 ila 8 hafta hypercare. Çıkış: hatalar eşiğin altında, destek devri imzalı

Her plana başladığım aşama tablosu budur:

Aşama	Tipik süre	Ne olur	İlerlemeden önceki çıkış kapısı
Discover	2 ila 4 hafta	İş gerekçesi, kapsam, dağıtım modeli seçimi (genel bulut, özel bulut ya da on-premise)	İmzalı kapsam ve ölçülebilir başarı kriterleri
Prepare	3 ila 6 hafta	Ekibin işe alıştırılması, yönetişim, sistem ortamı, temel plan, risk kaydı	Tüzük onaylı, modül başına isimleri belli karar vericiler, yazılı kaynak taahhütleri
Explore	4 ila 8 hafta	Fit-to-Standard atölyeleri, açık kaydı, WRICEF envanteri	Açık kararları sahipleriyle kayıt altında; takvim kesinleşti
Realize	8 ila 16 hafta	Konfigürasyon, geliştirme, birim ve entegrasyon testleri, deneme taşımaları	Deneme taşıması başarılı; entegrasyon testleri kapandı
Deploy	2 ila 4 hafta	Kullanıcı kabul testi, cutover provası, son kullanıcı eğitimi, son yükleme	UAT onayı, kapanış provası geçildi, go/no-go
Run	4 ila 8 hafta hypercare	Sahada destek, günlük önceliklendirme, desteğe devir	Açık hatalar üzerinde anlaşılan eşiğin altında; destek devri imzalandı

Zaman gerçekte nereye gidiyor

Discover aceleye getirilir. Ekipler kapsamı anlamadan bir son tarih belirler ve "ay sonu kapanışını üç gün kısaltmak" gibi ölçülebilir başarı kriterlerini atlar.

On-premise'de teknik gecikmeler Prepare'de başlar, çünkü altyapıyı müşteri ve iş ortağı kurar. Kaynak taahhütlerini yazılı alın. Sözlü müsaitlik buharlaşır.

Explore, kayıt tutmanın önem kazandığı yerdir. Karar ve sahibi yazıya geçirilmediyse altı ay sonra kimse iadelerin neden belirli bir şekilde işlendiğini hatırlamaz.

Realize en uzun aşamadır ve aşımların çoğu buraya düşer; genellikle Explore iyimser bir açık listesi ürettiği için. İlk deneme taşımanız başarısız olacak ve bunun üretimde değil testte başarısız olması gerekiyor.

Deploy, kesin adımları, saatleri ve sorumluları olan bir cutover planı ister. "Verileri taşı" bir adım değildir.

2023'te ABD'de bir sağlık programında müşteri takvimin üç ay gerisindeydi ve 2 milyon dolarlık bir bütçe aşımıyla karşı karşıyaydı. Projeyi SAP Activate'in Fit-to-Standard atölyeleriyle yeniden kurduk. Ekip, sıfır özelleştirmeyle yürütebileceği 28 süreç buldu.

Proje yöneticilerinin sözleriyle: "SAP'nin zaten hazır sunduğu şeyleri tasarlamakla aylarımızı boşa harcamışız." Altı hafta içinde takvime geri döndüler.

2024'te Avrupa'da bir perakende programında müşteri, ihtiyaçlarının yüzde 70'inin standart SAP süreçleriyle karşılandığını fark etti. Sistemi çalışırken görene kadar kapsamlı özelleştirmeler planlıyordu.

Clean core bunu daha da keskinleştiriyor. Genel sürümde tek seçenek standart süreçlerdir ve uzantılar SAP BTP'de ya da yayımlanmış API'lerde yer alır. Özel sürümde ve on-premise'de hâlâ modifikasyon yapabilirsiniz, ama her açık için maliyeti belli bir uzantı kararı gerektiğinde özelleştirme konuşması daha dürüst hâle gelir.

Sektör kendi yükünü ekler. Bu aralıklar çok lokasyonlu, eksiksiz bir kurumsal S/4HANA programını kapsar; bu yüzden 9 ila 18 ay süren tek bir RISE dağıtımından daha uzundur:

Sektör	Planlama aralığı	Süreyi ne uzatır
Üretim	14 ila 20 ay	Ürün ağacı ve rota kalitesi, MRP ayarı, QM gereksinimleri
Perakende ve tüketim ürünleri	12 ila 18 ay	POS entegrasyonu, ana veri hacmi, yoğun sezon pencereleri
İlaç	16 ila 22 ay	GxP validasyonu, parti izlenebilirliği, serileştirme
Kamu hizmetleri (enerji ve su)	15 ila 20 ay	Sayaç yönetimi, faturalama tarife yapıları, GIS ve SCADA entegrasyonu
Kamu sektörü	18 ila 24 ay	Fon muhasebesi, satın alma mevzuatı, onay yükü, veri yerelliği
Otomotiv	16 ila 22 ay	Tam zamanında tedarik zinciri, mühendislik değişiklik kontrolü
Havacılık ve savunma	20 ila 26 ay	Devlete raporlama, program muhasebesi, güvenli tedarik zincirleri
Petrol ve gaz	18 ila 24 ay	Ortak girişim muhasebesi, varlık yoğun operasyonlar
Finansal hizmetler	14 ila 20 ay	Görevler ayrılığına dayalı rol tasarımı, düzenleyici validasyon

Yapay zeka araçları neyi değiştiriyor, neyi değiştirmiyor

SAP Joule for Consultants 2025'te genel kullanıma açıldı. SAP Notes dahil SAP'nin kendi bilgi tabanından konfigürasyon sorularını yanıtlıyor ve ABAP kodunu açıklıyor. Mart 2024'ten beri genel kullanıma açık olan SAP Build Code, Joule ile SAP BTP üzerinde Java ve JavaScript uzantı kodu üretiyor.

İkisi de tek tek danışmanlara ve geliştiricilere yardımcı oluyor. Hiçbiri atölyelerin, kararların, veri temizliğinin ya da kullanıcı kabulünün ne kadar sürdüğünü değiştirmiyor. Planınızı bunları hesaba katarak yapın, ama kendi ekibiniz etkiyi ölçene kadar plandan hafta düşmeyin.

Haftalık program gündemine koyduğum riskler bunlardır. Aylık yönlendirme komitesine bırakılırsa her biri tarihleri kaydırır.

1. Geç kapsam değişiklikleri. Kapsamı Explore'un sonunda kesinleştirin. Bundan sonra bir değişiklik kontrol kurulu, her değişikliği takvim ve bütçe etkisi eklenmiş olarak onaylar.
2. Veri kalitesi. Şirketlerin çoğu planlama sırasında veri değerlendirmesini atlar. Kötü veri, başarısız deneme taşımalarının en tutarlı nedenidir.
3. Kaynak darboğazları. Bölüm başkanlarından isimleri ve tarihleri belli kişiler için yazılı taahhüt alın. Her kritik rol için bir yedek yetiştirin.
4. Karar gecikmeleri. Kapsam anlaşmazlıklarını 48 saat içinde üst kademeye taşıyın. Kararların aylık gözden geçirmeleri beklemesine izin vermeyin.
5. Geç değişim yönetimi. Son kullanıcılarla canlıya geçişten iki hafta önce değil, Prepare'de konuşmaya başlayın.

Araçlar tarafında SAP Cloud ALM, SAP'nin implementasyon yönetimi platformudur. SAP Solution Manager 7.2'nin standart bakımı 2027 sonunda bitiyor; seçili işlevler için uzatılmış bakım 2030'a kadar sürüyor. SAP Best Practices Explorer 2023'te kullanımdan kaldırıldı ve süreç içeriği artık SAP Signavio Process Navigator'da yer alıyor.

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

Bir SAP S/4HANA implementasyonu ne kadar sürer?

Deneyimime göre GROW with SAP'de (genel sürüm) 6 ila 9 ay, RISE with SAP'de (özel sürüm) 9 ila 18 ay. ECC'den başlayarak brownfield dönüşümü ya da seçici veri geçişi 12 ila 18 ay, greenfield implementasyon ise 18 ila 24 ay sürer.

Her SAP Activate aşaması ne kadar sürer?

Planlama başlangıcı olarak: Discover 2 ila 4 hafta, Prepare 3 ila 6 hafta, Explore 4 ila 8 hafta, Realize 8 ila 16 hafta, Deploy 2 ila 4 hafta ve Run 4 ila 8 hafta hypercare. Büyük programlarda en çok Realize uzar.

RISE with SAP takvimi nasıl etkiler?

RISE altyapı sorumluluğunu SAP'ye devreder; bu da Prepare aşamasındaki işin bir kısmını ortadan kaldırır. Zamanın çoğunun gittiği veri taşımayı, testleri, eğitimi ya da karar alma sürecini kısaltmaz. Clean core disiplini, özel geliştirmeyi başlamadan durdurursa Realize'ı kısaltabilir.

Bir SAP implementasyon takvimine ne kadar tampon eklenmeli?

Tedarikçi tahminine yüzde 15 ila 20 tampon ekleyin. Kapsam ve açıklar bilindiğinde, yani Explore'un sonunda tarihi kesinleştirin ve bunu kickoff'tan önce yönetim kuruluna söyleyin.

Bir SAP implementasyon takvimini nasıl kısaltabilirim?

Fit-to-Standard'ı titizlikle yürütün, çünkü kaçındığınız her özelleştirme haftalar kazandırır. Veri temizliğine Discover'da başlayın ve iş birimlerinden kaynakları yarı zamanlı ödünç almak yerine tam zamanlı tahsis edin. Cutover planını Realize'dan sonra değil, Realize sırasında hazırlayın.

Big bang mi yoksa aşamalı SAP devreye alma mı seçmeliyim?

Big bang her şeyi aynı anda canlıya alır. Toplamda daha hızlı ve daha risklidir; daha küçük kapsamlara ya da güçlü değişim yönetimi olan kuruluşlara uyar. Aşamalı devreye alma modül, lokasyon ya da iş birimi bazında ilerler; daha az risklidir, daha uzun sürer ve çok şirketli büyük gruplara uyar.

SAP projelerindeki gecikmelerin en yaygın nedenleri nelerdir?

Kontrolsüz değişiklik talepleri, veri kalitesinde sürprizler, geç değişim yönetimi, üçüncü taraf entegrasyon hataları, proje ortasında kilit kişilerin kaybı ve yavaş yönlendirme komitesi kararları. Ekiplerin çoğunu şaşırtan veri kalitesidir. Herkes eski verilerin temiz olduğunu varsayar ve neredeyse hiçbir zaman öyle değildir.

SAP canlıya geçişinden sonra hypercare ne kadar sürer?

Dört ila sekiz hafta hypercare planlayın: sahada destek, günlük sorun önceliklendirme ve performans izleme. Bundan sonra sistem bir uygulama destek ekibine ya da dahili bir mükemmeliyet merkezine geçer.