SAP implementasyon projesine doğru nasıl başlanır

Bir SAP implementasyonuna doğru başlamak için, kimse tek bir transaction'ı konfigüre etmeden önce beş şeyi netleştirin. Dağıtım modelini seçin. Kapsamı ve karar yetkilerini içeren bir proje başlatma belgesi imzalayın. Tasarım atölyelerine katılacak iş sahipleri atayın. Veri ve cutover çalışmalarına erken başlayın. Gerçek bir tampon payı olan bir takvim oluşturun. İlk ayda bunları doğru yaparsanız, pahalıya mal olan hataların çoğu hiç yaşanmaz.

Sistem doğru konfigüre edilirse SAP implementasyonunun sorunsuz ilerleyeceğini hep düşünürdüm. Blueprint, build, test, canlıya geçiş. Yıllarca bu zihinsel modeli izledim.

Orta Doğu, Güneydoğu Asya ve Avrupa'da 25 yıldır SAP dahil ERP implementasyonları yapıyorum. Ekipler SAP Activate'i adım adım izlediğinde bile projeler sorun yaşadı. Sorunlar neredeyse hiçbir zaman teknik değildi. Zayıf sahiplik. Kimsenin doğrulamadığı varsayımlar. Çok geç başlayan cutover planlaması. Bu çatlaklar başlangıçta zararsız görünür. Yayıldıktan sonra, erken görünürlüğün önleyebileceği şeyi geç dönemdeki çaba düzeltemez.

SAP implementasyonu, yazılım bileşeni olan bir iş değişim programıdır. İş akışları süreç tasarımı, konfigürasyon, veri taşıma, entegrasyon, test, eğitim ve değişim yönetimidir. Her birinin kendi takvimi, riskleri ve sahibi vardır.

Projeyi bir konfigürasyon çalışması olarak ele alan ekipler, konfigürasyon olmayan her şeyi yetersiz finanse eder. Zorlu canlıya geçişlerin en tutarlı nedeni budur.

Şimdi başlayan bir program için önce netleştirilmesi gereken bir iş akışı daha var: dağıtım modeli. S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) veya on-premise. Bu seçim, diğer tüm iş akışlarının nasıl yürüyeceğini belirler.

SAP Activate, SAP'nin teslimat metodudur. Altı fazı vardır ve her fazın sonunda kalite kapıları bulunur. Aşağıda her fazın ne için olduğunu ve kaçırılmasına izin vermeyeceğim noktayı görüyorsunuz.

Faz	Neler olur	Neyin doğru olduğundan emin olurum
Discover	İş gerekçesi, üst düzey kapsam, dağıtım modeli	İyimser olanı değil, gerçekçi bir maliyet ve takvim
Prepare	Yönetişim, proje başlatma belgesi, ekip, risk kaydı, ortamlar	Gerçek yetkiye sahip, adı belli karar vericiler
Explore	Fit-to-standard atölyeleri, boşluk kararları, tasarım onayı	Yalnızca BT değil, iş sahipleri de odada
Realize	Konfigürasyon, geliştirme, entegrasyon, sistem testi	Cutover planlaması şimdiden başlamış
Deploy	Kullanıcı kabul testi, veri yüklemeleri, eğitim, cutover	En az bir tam prova
Run	Canlıya geçiş, hypercare, destek ekibine devir	İlk ay sonu kapanışı boyunca kadrolu hypercare

En yaygın takvim hatası, yavaş ilerleyen bir Explore fazıdır. Realize fazını sıkıştırır, o da Deploy fazını sıkıştırır. Kullanıcı kabul testi (UAT) kısaltılır, veri provası atlanır ve tarih duyurulmuş olduğu için canlıya geçiş yine de gerçekleşir. Canlıya geçişten sonraki ilk 90 gün bunun bedelini öder.

1. 01Explore gecikirFit-to-standard ve tasarım onayı kayar
2. 02Realize sıkışırGeliştirme ve test için daha az zaman
3. 03Deploy sıkışırUAT, veri yüklemeleri ve eğitim için daha az zaman
4. 04Test kısaltılırUAT kısalır, veri provası atlanır
5. 05Duyurulan tarihte canlıya geçişÇünkü tarih duyurulmuştu

Maliyet hypercare döneminde, ilk 90 günde ortaya çıkar

1. İş tarafı olmadan tasarım onayı

Explore bir tasarım üretir. Tasarımın kalitesi, onu imzalayan süreç sahiplerinin neyi imzaladığını anlayıp anlamadığına bağlıdır. Atölyelere yalnızca BT ve danışmanlar katıldığında tasarım teknik olarak doğru olabilir, yine de onu kullanacak insanlar için tanınmaz olabilir. UAT o zaman doğrulama olmaktan çıkıp keşfe dönüşür.

Basit bir test: onaydan üç ay sonra bir süreç sahibinden, canlıya geçişten sonra bir satın alma siparişinin nasıl işleyeceğini size anlatmasını isteyin. Anlatamıyorsa onay gerçek değildi.

2. Yalnızca kâğıt üzerinde var olan yönetişim

Uygulanmayan bir yönetişim varsa kapsam gayriresmî biçimde büyür ve kararlar ertelenir. İyi yönetişim; adı belli bir üst düzey sponsor, karar yetkileri tanımlı bir yönlendirme komitesi, bir faz kapısını tutabilen bir proje yöneticisi ve onaylayanı belli bir değişiklik kontrol süreci demektir.

Projelerimin çoğunda CFO proje şampiyonu rolünü üstlendi. Departmanlar bir süreç üzerinde anlaşamadığında son kararı o verdi. Bu, sorunlar çözümsüz kaldığında yaşanan haftalarca gecikmeyi önledi. SAP yönlendirme komiteleri rehberim bunun nasıl kurulacağını anlatıyor.

3. Geç başlayan cutover planlaması

Cutover, programın operasyonel açıdan en karmaşık parçasıdır. Canlıya geçişten birkaç hafta önce başlatılan bir plan prova edilmez, bağımlılıkları kaçırır ve gerçek bir geri dönüş noktasına sahip olmaz.

Cutover planlamasına Realize fazında başlayın. Sırayı belgeleyin, en az bir tam prova yapın ve geri dönüş ölçütlerini önceden kararlaştırın. Cutover kararlarının baskı altında, yirmi saattir uyanık olan insanlar tarafından, önceden anlaşılmış hiçbir ölçüt olmadan verilmesi, canlıya geçiş sonrası felaketlerin başladığı yerdir.

4. Sıkıştırılan entegrasyon testi

Dürüst olmak gerekirse, eskiden testin bir kontrol listesindeki görevden ibaret olduğunu düşünürdüm. Sistemi konfigüre et, birkaç test senaryosu çalıştır, devam et. Sonra bir projenin, satın alma onaylarının finans kayıtlarını nasıl etkilediğini kimse kontrol etmediği için çöktüğünü gördüm. O an SAP testine bakışımı değiştirdi.

Birim testleri bir transaction'ın tek başına çalıştığını kanıtlar. Canlıya geçişten sonra can yakan hatalar, tam bir süreç modüller arasında çalıştığında ortaya çıkar. Satın alma siparişi statüsünün engellediği bir mal girişi. Eksik hesap belirlemenin durdurduğu bir faturalama çalıştırması. Siparişten tahsilata ve satın almadan ödemeye kadar tam zincirleri test edin ve bunların UAT öncesindeki son haftalara kaymasına izin vermeyin.

5. Hafife alınan veri taşıma

Kaynak veri neredeyse her zaman ilk değerlendirmenin gösterdiğinden daha kötüdür. Basit görünen alan eşlemeleri yükleme sırasında başarısız olur. Kayıt sayıları pasif verileri de içerir. Temizleme kuralları iş kararları gerektirir ve bunlar zaman alır.

Bir üretim şirketi, taşıma sırasında binlerce mükerrer müşteri kaydı keşfetti ve bunları düzeltmek için canlıya geçişi üç hafta ertelemek zorunda kaldı. Baştan ek yükleme döngüleri planlayın. SAP veri taşıma neden başarısız olur başlıklı makalem ayrıntılara giriyor.

6. İsteğe bağlı sayılan değişim yönetimi

Sistemin kusursuz çalıştığı, buna rağmen kullanıcıların eski süreçlere sarıldığı projeler gördüm. Zor insanlar oldukları için değil, kimse onlara geçişi anlatmadığı için. Değişim yönetimi kesildiğinde ilk haftada geçici çözümler ortaya çıkar, kalıcı hale gelir ve destek talepleri aylarca yüksek kalır.

Ağır özelleştirme de aynı kategoridedir. Bir keresinde sistemin yüzde 60'ından fazlasını özelleştiren bir müşteriyle çalıştım. Sonradan yükseltme yapmakta zorlandılar ve satıcı desteğini kaybettiler.

Yukarıdaki temel ilkeler değişmedi. Bugün bir programın başında üç şeyin netleştirilmesi gerekiyor.

Önce dağıtım modeli gelir. Public Edition en dar özelleştirme seçeneklerini sunar ve sistemi SAP işletir. RISE kapsamındaki Private Edition daha fazla alan tanır ve altyapıyı SAP işletir. On-premise en fazla kontrolü ve en fazla sorumluluğu verir. Bunu Discover fazında kararlaştırın. Kararı erteleyen programlar Explore fazını bunu tartışarak geçirir.

Clean Core proje başlatma belgesinde yer almalı. Public Edition uzantılara yalnızca yayımlanmış arayüzler üzerinden izin verir, dolayısıyla Clean Core'u teknik olarak zorunlu kılar. Private Edition ve on-premise bunu yapmaz, bu yüzden konu bir yönetişim kararına dönüşür. SAP artık uzantıları A seviyesinden (yalnızca yayımlanmış API'ler) D seviyesine (modifikasyonlar) kadar sınıflandırıyor; ayrıntılar Ağustos 2025 Clean Core güncellemesinde yer alıyor. Hedef seviyeyi ve onay forumunu proje başlatma belgesine yazın; yoksa iş ortakları varsayılan olarak modifikasyonlara yönelir.

Yapay zeka araçları ilk günden metodun içinde olmalı. Joule, SAP Activate Roadmap Viewer içinde kullanılabiliyor. Danışmanlar için Joule konfigürasyon sorularını yanıtlıyor, geliştiriciler için Joule ise ABAP Cloud kodu üretiyor. Bunlar taslak hazırlama ve build görevlerini hızlandırabilir. İş kararlarını, veri çalışmasını ya da değişim eforunu ortadan kaldırmazlar. İş ortağınıza bunları nerede kullandıklarını ve bunun planda nasıl göründüğünü sorun.

Yaklaşım; risk toleransınıza, karmaşıklığınıza ve değişim kapasitenize uygun olmalıdır. Yaygın seçenekler şunlardır.

Yaklaşım	Ne anlama gelir	En uygun olduğu durum
Big bang	Tüm modüller ve şirketler birlikte canlıya geçer	Standart kapsamı olan, daha yüksek canlıya geçiş riskini göze alan küçük kuruluşlar
Modül bazında aşamalı	Önce finans, sonra tedarik zinciri, sonra İK	Birbirine az bağımlı modüller; ekibin fazlar arasında öğrenmesini sağlar
Ülke veya şirket bazında aşamalı	Bir şablon önce tek bir şirkette canlıya geçer, sonra yaygınlaştırılır	Küresel şablonu olan gruplar
Brownfield dönüşüm	Mevcut ECC, S/4HANA'ya dönüştürülür	Süreçleri oturmuş, olgun bir ECC
Greenfield	Yeni bir S/4HANA implementasyonu	SAP dışı eski sistemler veya yoğun teknik borcu olan ECC
Seçici veri geçişi	Seçilen şirketler veya veriler yeniden tasarlanmış bir sisteme taşınır	Birleşmeler, ayrılmalar (carve-out), kısmi yeniden kullanım

Altı aydan kısa sürede canlıya geçen küçük rollout'lar gördüm. Kararlar zamanında alınmadığı için iki yıl süren projeler de gördüm. İlk implementasyon ile şablon rollout'u arasında kararsızsanız, implementasyon ve rollout karşılaştırma rehberim ikisini karşılaştırıyor.

Bunu ilk ayda, konfigürasyon başlamadan önce kullanın. Her maddenin müşteri tarafında bir sahibi vardır.

1. Üst düzey sponsor: dağıtım modeli gerekçeleriyle birlikte kararlaştırılıp kaydedilmiş.
2. Program direktörü: kapsamı, açık kapsam dışı maddeleri, başarı ölçütlerini, karar yetkilerini ve değişiklik kontrolünü içeren proje başlatma belgesi imzalanmış. Sözlü kapsam anlaşmaları buharlaşır. Proje başlatma belgesi rehberimde bir şablon var.
3. İş liderleri: her alan için adı belli bir süreç sahibi; atölyelere katılabilmeleri için gerçekten zaman ayrılmış.
4. Çözüm mimarı: Clean Core hedefi ve uzantı onay forumu üzerinde anlaşılmış.
5. Veri lideri: veri profilleme, tasarım onayından sonra değil, Prepare fazında başlamış.
6. Cutover lideri: Realize fazında atanmış, planda prova tarihi şimdiden var.
7. Test yöneticisi: onaylardan finans kayıtlarına kadar tam süreç zinciri test senaryoları listelenmiş.
8. CFO: takvim benzer programlarla karşılaştırılarak kontrol edilmiş; yavaş bir Explore ve ek veri döngüleri için tampon bırakılmış. Her şeyin yolunda gideceğini varsayan bir plan, plan değildir.

SAP implementasyon projesi nedir?

Bir işletmenin operasyonlarını yürütmek için SAP yazılımını devreye alan programdır. Süreç tasarımı, konfigürasyon, veri taşıma, entegrasyon, test, eğitim ve değişim yönetimini kapsar ve genellikle SAP Activate ile yürütülür. Efor; şirket, ülke ve modül sayısına ve mevcut verinizin durumuna göre çok büyük farklılık gösterir.

SAP implementasyonunun fazları nelerdir?

SAP Activate'in altı fazı vardır: Discover, Prepare, Explore, Realize, Deploy ve Run. Discover iş gerekçesini ve kapsamı belirler. Prepare yönetişimi ve ekibi kurar. Explore fit-to-standard atölyelerini yürütür ve tasarımı onaylar. Realize geliştirme ve test yapar. Deploy; UAT, veri yüklemeleri, eğitim ve cutover'ı kapsar. Run, canlıya geçiş ve hypercare'dir. Her faz bir kalite kapısıyla biter.

Bir SAP implementasyonu ne kadar sürer?

Kapsama ve kararların ne kadar hızlı alındığına bağlıdır. Altı aydan kısa sürede canlıya geçen küçük rollout'lar gördüm; kararlar zamanında alınmadığı için iki yıl uzayan projeler de. Gecikmenin en yaygın nedeni, kendinden sonraki her şeyi sıkıştıran yavaş bir Explore fazıdır.

SAP implementasyonlarının başarısız olmasının en yaygın nedenleri nelerdir?

Gerçek iş katılımı olmadan onaylanan tasarım, uygulanmayan yönetişim, geç başlayan cutover planlaması, sıkıştırılan entegrasyon testi, hafife alınan veri taşıma ve kısıtlanan değişim yönetimi. Altısı da genellikle erken görünür ve o noktada düzeltmesi ucuzdur.

Bir SAP proje başlatma belgesinde neler olmalı?

Ölçülebilir sonuçlara bağlı hedefler, modül, şirket, ülke ve entegrasyona göre kapsam, açık kapsam dışı maddeler, isimleriyle karar yetkileri, yönetişim ve eskalasyon, başarı ölçütleri, değişiklik kontrolü, ana kilometre taşları ve temel varsayımlar. Bulut programı için dağıtım modelini ve Clean Core yaklaşımını ekleyin. Konfigürasyon başlamadan önce sponsora ve iş liderlerine imzalatın.

SAP canlıya geçişinden sonra hypercare nedir?

Hypercare, canlıya geçişten sonraki yoğun destek dönemidir ve genellikle 30 ila 90 gün sürer. Proje ekibi ve iş birimi sorunları gidermek ve operasyonları stabilize etmek için yan yana çalışır. En az bir tam iş döngüsü boyunca, ilk ay sonu kapanışı dahil, kadrolu tutun; çünkü birçok sorun ilk kez o zaman ortaya çıkar.