SAP implementasyon takvimi planlaması: kaçınılması gereken 5 hata

Bir SAP implementasyon takvimi, Discover aşamasından hypercare'e kadar uzanan, aşama aşama hazırlanmış plandır. Public cloud projelerinde, yüzlerce projeyi inceleyen bir SAP ürün uzmanı tipik canlıya geçişi beş ila yedi ay olarak veriyor. Private cloud ya da on-premise kurumsal programlar ise bir yıldan çok daha uzun sürüyor. Planınızın tutup tutmayacağı metodolojiden çok beş planlama hatasına bağlı: kapsam netleşmeden kilitlenen tarihler, geç başlayan veri taşıma, atlanan kalite kapıları, erken verilen eğitim ve yoğun sezona denk gelen canlıya geçişler. Bu rehber, plan hazırlayan ya da elindeki planı kurtarmaya çalışan program direktörleri ve sponsorlar için. Aşama tablosunu iskelet olarak kullanın, sonra beş hataya karşı sınayın. Gecikmenin her ek ayı, danışmanlık ücretlerinde 100.000 dolar veya daha fazlasına mal olabilir.

SAP projesi altı ay geride kalmış bir üretim şirketinin proje yöneticisiyle tanıştım. Planı sıkı sıkıya SAP Activate'in aşamalarına göre sıfırladıktan sonra kalan işi dört ayda bitirdiler. Onun sözleriyle: “Net aşamalar ve belirli çıktılar her şeyi değiştirdi. Sırada ne yapmamız gerektiğini her zaman tam olarak biliyorduk.”

Tutan takvimlerin üç ortak yanı var. Gerçekçi tamponlar. Kilitlenmeden önce doğrulanmış varsayımlar. Kesin duraklar olarak ele alınan kalite kapıları.

Aşımların çoğunu beş hata açıklıyor. Her biri öngörülebilir ve her birinin bir karşı önlemi var.

Hata 1: kapsam anlaşılmadan son tarih koymak

Bir keresinde yönetim kuruluna tamponsuz, dokuz aylık bir implementasyon sözü vermiş bir şirketle çalıştım. Veri taşıma beklenenden uzun sürünce son tarihi üç ay kaçırdılar ve yöneticiler ekibe olan güvenini yitirdi. Danışman olarak görüşümü sorduklarında takvimin fazla agresif olduğunu açıkça söyledim. Proje yöneticisi bunu kabul etmeye zorlanmıştı.

Çözüm: takvimi başlangıçta değil, Explore sonrasında kilitleyin ve bunu yönetim kuruluna en baştan söyleyin. Tedarikçi tahmininin üzerine yüzde 15-20 tampon ekleyin.

Hata 2: veri taşımayı geç başlayan bir iş akışı saymak

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

Çözüm: veri profillemeyi Realize'da değil, Discover'da başlatın. Entegrasyon testleri başlamadan önce Realize aşamasında tam bir deneme taşıması (mock migration) yapın. Deneme başarısız olursa düzeltmeye vaktiniz vardır. Bunu cutover sırasında öğrenirseniz yoktur. SAP veri taşımanın neden başarısız olduğunu anlattığım yazı, deneme döngüsünü ayrıntılı biçimde 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ü “hadi canlıya alalım” baskısı en çok orada zirve yapar. “Takvimde kalmak” için kalite kapılarını atlamak, ileride daha büyük gecikmelere yol açar.

Çözüm: ölçülebilir çıkış ölçütlerini proje başlatma belgesine yazın ve yönlendirme komitesinin bunları uygulatmasını sağlayın. Finans kapanış provası burada işe yarayan bir kapıdır. Finans ekibi bunu sorunsuz çalıştıramıyorsa sistem hazır değildir. 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

Tüm kullanıcılarını canlıya geçişten iki ay önce eğitmiş bir perakende şirketiyle çalıştım. Açılış gününe gelindiğinde herkes sistemi nasıl kullanacağını unutmuştu. Her iş istasyonuna “hatırlatma” iş yardımcıları vermek zorunda kaldık ve sahadaki desteği ikiye katladık. Eğitim harcamasının büyük kısmı boşa gitti.

Çözüm: eğitimi canlıya geçişten iki ila üç hafta önceye oturtun. Eğitmen olarak ileri düzey kullanıcıları (power user) görevlendirin, çünkü insanlar güvendikleri meslektaşlarından öğrenir. Hypercare sırasında tekrar oturumları planlayın. Tüm yaklaşım SAP eğitim stratejileri yazımda var.

Hata 5: canlıya geçişi yoğun iş döngülerine denk getirmek

Hershey, SAP R/3, Siebel ve Manugistics sistemini Temmuz 1999'da, planlanandan üç ay geç ve doğrudan Cadılar Bayramı sipariş sezonunun içinde canlıya aldı. CEO'su analistlere, sorunların Hershey'nin 100 milyon dolarlık Cadılar Bayramı siparişini teslim etmesini engelleyeceğini söyledi. Ders ortada ve hâlâ göz ardı ediliyor.

Çözüm: etkilenen her iş birimi için, ay sonu ve çeyrek sonu kapanışı 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. Yoğun sezonda başarısız bir canlıya geçiş edilemez.

SAP Activate, eski ASAP metodolojisinin yerini aldı. Altı aşaması, bulut ya da on-premise, her S/4HANA planının iskeletidir. Aşağıdaki süreler bir kurumsal program için planlamaya başlangıç noktalarıdır, söz değildir.

1. 1Discover2 ila 4 hafta. Çıkış: imzalı kapsam ve başarı ölçütleri
2. 2Prepare3 ila 6 hafta. Çıkış: onaylı proje başlatma belgesi, yazılı kaynak taahhütleri
3. 3Explore4 ila 8 hafta. Çıkış: sahipleri belli boşluk kararları, kilitlenen takvim
4. 4Realize8 ila 16 hafta. Çıkış: deneme taşıması geçti, entegrasyon testleri kapandı
5. 5Deploy2 ila 4 hafta. Çıkış: UAT onayı, kapanış provası, go/no-go
6. 6Run4 ila 8 hafta hypercare. Çıkış: açık hatalar eşiğin altında, destek devri imzalı

Aşama	Tipik süre	Neler olur	Devam etmeden önce çıkış kapısı
Discover	2-4 hafta	İş gerekçesi, kapsam, dağıtım seçimi (public cloud, private cloud veya on-premise)	İmzalı kapsam ve ölçülebilir başarı ölçütleri
Prepare	3-6 hafta	Ekibin sürece dahil edilmesi, yönetişim, sistem ortamı, temel plan, risk kaydı	Proje başlatma belgesi onaylı, her modül için isimle belirlenmiş karar vericiler, yazılı kaynak taahhütleri
Explore	4-8 hafta	Fit-to-Standard çalıştayları, boşluk kaydı, RICEFW envanteri (raporlar, arayüzler, dönüşümler, geliştirmeler, formlar, iş akışları)	Boşluk kararları sahipleriyle kayıt altında; takvim kilitli
Realize	8-16 hafta	Konfigürasyon, geliştirme, birim ve entegrasyon testleri, deneme taşımaları	Deneme taşıması geçti; entegrasyon testleri kapandı
Deploy	2-4 hafta	Kullanıcı kabul testi, cutover provası, son kullanıcı eğitimi, son yükleme	UAT onayı, kapanış provası geçti, go/no-go
Run	4-8 hafta hypercare	Sahada destek, günlük önceliklendirme, destek ekibine devir	Açık hatalar kararlaştırılan eşiğin altında; destek geçişi imzalı

Zamanın gerçekte nereye gittiği

Discover aşamasına acele edilir. Ekipler kapsamı anlamadan bir son tarih belirler ve ölçülebilir başarı ölçütlerini atlar. “Ay sonu kapanışını üç gün kısaltmak” gibi hedeflere ihtiyacınız var.

Prepare teknik gecikmelerin başladığı yerdir. RISE with SAP'te altyapıyı SAP sağlar. On-premise'de müşteri ve iş ortağı kurar ve buradaki kayma zincirleme yayılır. Kaynak taahhütlerini yazılı alın. Sözlü uygunluk buharlaşır.

Explore kayıt tutmanın önem kazandığı aşamadır. Karar ve sahibi yazıya geçirilmediyse altı ay sonra kimse iadelerin neden belirli bir şekilde işlendiğini hatırlamaz. Ekipler ayrıca boşluk sayısını hafife alır.

Realize en uzun aşamadır ve aşımların çoğu burada ortaya çıkar; genellikle Explore iyimser bir boşluk listesi üretmiş olduğu için. İlk deneme taşımanız başarısız olacak. Başarısızlığın üretimde değil, testte yaşanmasını istersiniz. Sürekli 60 saatlik haftalar hatalara ve personel kaybına yol açar.

Deploy için kesin adımları, saatleri ve sahipleri içeren bir cutover planı gerekir. “Veriyi taşı” bir adım değildir.

Run aşaması, kritik sorunlar önemsiz sorunların arkasında beklediğinde ters gider. Geliş sırasına göre değil iş etkisine göre önceliklendirin ve her düzeltmeyi yazın. Destek ekibiniz aynı sorunla yeniden karşılaşacak.

Takvimin üç ay gerisinde kalmış ve 2 milyon dolarlık bütçe aşımıyla karşı karşıya olan bir sağlık hizmeti sağlayıcısıyla çalıştım. SAP Activate'in Fit-to-Standard çalıştaylarıyla planı sıfırladık. Ekip, sıfır özelleştirmeyle çalıştırabileceği 28 finans ve tedarik zinciri süreci buldu. Proje yöneticisinin sözleriyle: “SAP'nin zaten hazır sunduğu şeyleri tasarlayarak aylar harcadık.” Altı hafta içinde takvime geri döndüler ve zamanında canlıya geçtiler.

Standart SAP süreçlerinin ihtiyaçlarının yüzde 70'ini karşıladığını fark eden bir perakende şirketiyle çalıştım. Sistemi çalışırken görene kadar kapsamlı özelleştirmeler planlıyordu.

Clean Core bunu keskinleştirir. S/4HANA Cloud Public Edition'da standart süreçler tek seçenektir; uzantılar SAP BTP üzerinde ya da yayımlanmış API'lerde durur. Private cloud ve on-premise'de hâlâ değişiklik yapabilirsiniz, ancak SAP'nin Clean Core rehberi aynı yöne iter. Her boşluk, maliyeti olan bir BTP uzantısı kararı gerektirdiğinde özelleştirme konuşması daha dürüst hale gelir.

Dağıtım modeli takvimi diğer tüm seçimlerden daha fazla değiştirir.

1. Public cloud (GROW with SAP, S/4HANA Cloud Public Edition, artık SAP Cloud ERP adıyla satılıyor). Yüzlerce projeyi inceleyen bir SAP ürün uzmanı tipik canlıya geçişi beş ila yedi ay olarak veriyor. SAP'nin 2026 başında kullanıma sunduğu GROW Fast teklifi, sabit kapsamda iki ila dört ayı hedefliyor. Büyük public cloud projeleri 12 ay veya daha uzun sürüyor.
2. Private cloud (RISE with SAP, artık SAP Cloud ERP Private) ve on-premise. Kurumsal kapsam tipik olarak 12-24 ay sürer. RISE'ta altyapıyı SAP işletir ve bu, Prepare aşamasındaki işin bir kısmını ortadan kaldırır. Veri, test ve değişim çabasını ortadan kaldırmaz.

Sektör de kendi gecikmesini ekler. Tam bir S/4HANA kurumsal programı için tipik aralıklar şunlar:

Sektör	Planlama aralığı	Süreyi uzatan etkenler
Üretim	14-20 ay	Ürün ağacı (BOM) ve rota kalitesi, MRP ayarı, kalite yönetimi (QM) gereksinimleri
Perakende ve tüketim malları	12-18 ay	POS entegrasyonu, ana veri hacmi, yoğun sezon pencereleri
İlaç	16-22 ay	GxP doğrulaması, parti izlenebilirliği, serileştirme
Enerji ve su hizmetleri	15-20 ay	Cihaz yönetimi, faturalama tarife yapıları, GIS ve SCADA entegrasyonu
Kamu sektörü	18-24 ay	Fon muhasebesi, ihale mevzuatı, onay yükü, veri yerelliği
Otomotiv	16-22 ay	Tam zamanında tedarik zinciri, mühendislik değişikliği kontrolü
Havacılık ve savunma	20-26 ay	Devlet raporlaması, program muhasebesi, güvenli tedarik zincirleri
Petrol ve gaz	18-24 ay	Ortak girişim muhasebesi, varlık yoğun operasyonlar
Finansal hizmetler	14-20 ay	Görevler ayrılığı rol tasarımı, düzenleyici doğrulama

Yapay zeka araçlarının neyi değiştirdiği, neyi değiştirmediği

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

İkisi de tek tek danışmanlara ve geliştiricilere yardımcı oluyor. İkisi de çalıştayların, kararların, veri temizliğinin ya da kullanıcı kabulünün ne kadar süreceğini değiştirmiyor. Planı bunlarla birlikte yapın, ancak kendi ekibiniz etkiyi ölçene kadar plandan hafta eksiltmeyin.

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

1. Geç kapsam değişiklikleri. Kapsamı Explore sonunda kilitleyin. Bundan sonra bir değişiklik kontrol kurulu, takvim ve bütçe etkisi eklenmiş her değişikliği onaylasın.
2. Veri kalitesi. Çoğu şirket planlama sırasında veri değerlendirmesini atlar. Şimdi bir tane başlatın. Kötü veri, başarısız deneme taşımalarının en tutarlı nedenidir.
3. Kaynak darboğazları. Departman başkanlarından isimle belirlenmiş kişiler ve tarihler 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 makama taşıyın. Kararların aylık toplantıları beklemesine izin vermeyin.
5. Geç değişim yönetimi. Son kullanıcılarla konuşmaya canlıya geçişten iki hafta önce değil, Prepare aşamasında başlayın.

Bir risk değerlendirme matrisi, bu listeyi yönlendirme komitesinin puanlayabileceği bir şeye dönüştürür.

Araçlar konusunda: SAP Cloud ALM, SAP'nin implementasyon yönetimi için öne çıkardığı platformdur. SAP Solution Manager 7.2'nin standart bakımı 2027 sonunda sona eriyor; Business Suite uzatılmış bakımını alan müşteriler için seçili işlevlerde uzatılmış bakım 2030'a kadar sürüyor. SAP Best Practices Explorer 2023'te kullanımdan kaldırıldı; süreç içeriği artık SAP Signavio Process Navigator'da yer alıyor.

2026'da bir SAP implementasyonu ne kadar sürer?

Dağıtım modeline, kapsama ve sektöre bağlı. Yüzlerce projeyi inceleyen bir SAP ürün uzmanı S/4HANA Cloud Public Edition için beş ila yedi ay, SAP'nin sabit kapsamlı GROW Fast teklifi için iki ila dört ay veriyor. RISE with SAP private cloud ya da on-premise üzerindeki kurumsal programlar genellikle 12 ila 24 ay sürer. Kamu sektörü ve havacılık programları sık sık 20 ayı aşar.

RISE with SAP takvimi nasıl etkiler?

RISE, altyapı sorumluluğunu SAP'ye devrederek Prepare aşamasındaki işin bir kısmını ortadan kaldırır. Zamanın çoğunun gittiği veri taşıma, test, eğitim ve karar alma süreçlerini kısaltmaz. Clean Core disiplini, özel geliştirmeyi başlamadan durdurursa Realize aşamasını kısaltabilir.

Bir SAP implementasyonu için kilometre taşı planını nasıl hazırlarım?

Altı SAP Activate aşamasıyla başlayın ve her kapı için ölçülebilir çıkış ölçütleri yazın. Her aşamadaki kritik yol faaliyetlerini ve bağımlılıkları belirleyin. Kapıları kesin duraklar olarak ele alın, planı haftalık olarak takip edin ve SAP Cloud ALM'de yönetin.

SAP implementasyon süresini hangi etkenler belirler?

En büyükleri kapsam (modüller, tüzel kişilikler, entegrasyonlar), özelleştirme hacmi, veri kalitesi, kullanıcı sayısı ve coğrafya, karar hızı ve düzenleyici doğrulamadır. Dağıtım modeli bunların hepsinin üstünde durur. Kapsam ve süreçler sınırlı olduğu için public cloud en hızlısıdır. Yoğun özelleştirmeli on-premise en yavaşıdır.

Bir SAP implementasyonunu nasıl hızlandırabilirim?

Fit-to-Standard'ı titizlikle yürütün, çünkü kaçındığınız her özelleştirme haftalar kazandırır. Veri temizliğine Discover aşamasında başlayın. İş tarafı kaynaklarını yarı zamanlı ödünç almak yerine tam zamanlı görevlendirin. Konfigürasyon başlamadan önce onay akışlarını belirleyin ve cutover planını Realize sonrasında değil, Realize sırasında hazırlayın.

SAP için big bang mi, aşamalı devreye alma mı seçmeliyim?

Big bang her şeyi aynı anda canlıya alır. Toplamda daha hızlıdır ve daha risklidir; daha küçük kapsama ya da güçlü değişim yönetimine sahip kuruluşlara uyar. Aşamalı devreye alma modül, lokasyon veya iş birimi bazında ilerler. Riski daha düşüktür ve daha uzun sürer; büyük, çok tüzel kişilikli gruplara uyar. Birçok orta ölçekli program hibrit yol izler: çekirdek finans tek seferde, operasyonlar aşamalı.

SAP projelerinde gecikmenin en yaygın nedenleri nelerdir?

Kontrolsüz değişiklik talepleri, veri kalitesi sürprizleri, geç değişim yönetimi, üçüncü taraf entegrasyon hataları, proje ortasında kilit kişilerin kaybı ve yönlendirme komitesinin yavaş kararları. Ekipleri en çok şaşırtan veri kalitesidir. Herkes eski verinin temiz olduğunu varsayar. Neredeyse hiç temiz değildir.

SAP canlıya geçişinden sonra ne olur?

Hypercare başlar: dört ila sekiz hafta sahada destek, günlük sorun önceliklendirme ve performans izleme. Ardından sistem bir uygulama destek ekibine ya da kurum içi bir mükemmeliyet merkezine geçer. İlk geliştirme sürümünüzü canlıya geçişten üç ila altı ay sonrasına planlayın.