Maliyetli hatalardan kaçınmak için en iyi SAP uygulama stratejileri

En iyi SAP uygulama stratejisi, işinize uyan ve ekibinizin sürdürebildiği stratejidir. Üç karara iner. Hangi dağıtım modeli: S/4HANA Cloud Public Edition (genellikle GROW with SAP üzerinden), Private Edition (genellikle RISE with SAP üzerinden) ya da on-premise. Hangi geçiş yolu: greenfield, brownfield ya da bluefield. Ve hangi devreye alım modeli: Big Bang, aşamalı ya da hibrit. Bu rehber, S/4HANA için bir yaklaşım seçen CIO'lara, program direktörlerine ve sponsorlara yönelik. Önce aşağıdaki beş soruyu yanıtlayın, dağıtım kararını ilk olarak verin, sonra diğer ikisini netleştirmek için karşılaştırma tablosunu ve karar ağacını kullanın.

Çalıştığım 21 programda örüntüler tutarlı. Strateji seçimi gerçek, ama kararın küçük yarısı o. Büyük yarısı, seçenekler tablosu rafa kalktıktan sonra ekibin 14 aylık icra boyunca disiplini koruyup koruyamayacağı.

Amaç, en hızlı ya da en ucuz seçeneği bulmak değil. Amaç, işletmeye uyan yaklaşımı bulmak: yapısına, kültürüne, temposuna, mevzuat profiline ve uzun vadeli hedeflerine uyanı.

Önce yanıtlanacak beş soru

1. Yapınız ne kadar karmaşık: tek tüzel kişilik, çok tüzel kişilik, çok ülkeli?
2. Ekiplerinizin uyum sağlamak için zamana mı ihtiyacı var, yoksa değişime şimdiden hazırlar mı?
3. Birkaç eski sistemden mi, tek bir ERP'den mi yoksa sıfırdan bir başlangıçtan mı geçiyorsunuz?
4. Şirket içi SAP uzmanlığınız var mı, yoksa ortaklara mı bağımlı olacaksınız?
5. Canlıya geçişte ne kadar aksamayı tolere edebilirsiniz?

Herkes için geçerli tek bir yanıt yok. Stratejiniz, başkasının başarı hikâyesini değil, sizin gerçekliğinizi yansıtmalı.

2023 ile 2026 arasında ne değişti

RISE ve GROW, S/4HANA'yı bulutta satın almanın standart yolları oldu. RISE with SAP; yazılımı (genellikle Private Edition), SAP tarafından işletilen altyapıyı ve teknik operasyonları, BTP kredilerini tek bir abonelikte birleştirir. GROW with SAP, standart süreçleri olan orta ölçekli şirketler için Public Edition'ı paketler. Geleneksel “önce lisans, sonra uygulama” modeli on-premise için hâlâ var, ama yeni görüşmelerin çoğu RISE ya da GROW ile başlıyor.

Clean core tavsiyeden mimariye dönüştü. Public Edition'da çekirdeği değiştiremezsiniz: uzantılar yayımlanmış API'leri kullanır, ya ABAP Cloud ile on-stack ya da SAP BTP üzerinde side-by-side. Private Edition ve on-premise'de hâlâ değiştirebilirsiniz, ama SAP'nin rehberliği değişikliği son çare sayar, çünkü her biri yükseltme işi ekler. Clean core deneyimi olmayan ortaklar ilk haftadan teknik borç yaratır.

Yapay zeka teslimat araçlarına geldi. SAP Joule for Consultants (Mayıs 2025'ten beri genel kullanımda) konfigürasyon sorularını SAP'nin kendi içeriğinden yanıtlar. SAP Cloud ALM, fit-to-standard atölye transkriptlerinden gereksinim taslağı hazırlayabilir. SAP Build Code (Mart 2024'ten beri genel kullanımda) Java ve JavaScript uzantıları üretmek için Joule'u kullanır; geliştiriciler için Joule ise 2024 sonundan itibaren ABAP kodu üretimi ve açıklaması ekledi. Bunların hiçbiri stratejik seçimi değiştirmez. Hangi seçimi yaparsanız yapın, onun içindeki maliyeti ve süreyi değiştirir.

Stratejilerin başarılı ya da başarısız olduğu yerler

İcra, seçimden daha önemli. Hangi yaklaşım seçilmiş olursa olsun dört başarısızlık örüntüsü ortaya çıkar.

1. Kaybolan üst yönetim katılımı. Bir banka için yapılan bir S/4HANA uygulamasında CEO her önemli toplantıya geldi, iyi sorular sordu ve ekibin arkasında durdu. Zamanında bitti ve planlanandan az harcadı. Bir mağaza zincirinin yöneticileri kick-off'tan sonra her şeyi devretti. Kimse karar veremediği için proje aylarca durdu.
2. BT işi olarak ele alınan veri taşıma. Bir müşteri ürün ana verisinin “yeterince temiz” olduğunda ısrar etti. İlk gün, deposuna üç yıl önce üretimden kaldırılmış ürünler için siparişler geldi. Temizlik haftalar sürdü ve ona büyük bir müşteriye mal oldu. Veri taşımanın iş tarafında bir sahibi olmalı.
3. Atlanan ya da aceleye getirilen eğitim. SAP devreye alımından iki hafta sonra bir ofisi ziyaret ettim. Muhasebe ekibinin monitörlerinin her yerinde temel işler için hatırlatma notları yapışıktı; bir günlük eğitim almışlardı. Müdürleri bana “Sadece ayakta kalmaya çalışıyoruz” dedi. O şirket ilk yıl destek için fazladan 200.000 dolar harcadı.
4. Sistemin etrafından dolaşan insanlar. Eğitimin yeterli olduğunu düşünen bir fabrikayla çalıştım. İşçiler yeni sisteme güvenmedi ve elektronik tablolara geri döndü. Bunu canlıya geçişten sonra düzeltmek pahalıydı. Değişim yönetimi; iletişim, katılım ve işin içindeki şampiyonlar demektir, eğitim bunun yalnızca bir parçasıdır.

İki ana devreye alım modeli

Big Bang

• Her şey tek bir cutover'da canlıya geçer
• Standartlaşmış süreçlere giden en hızlı yol
• Daha düşük başlangıç maliyeti, daha yüksek ilk gün riski
• Sıkı prova ve temiz veri gerektirir

Aşamalı

• Modül, bölge ya da fonksiyon bazında dalgalar halinde canlıya geçiş
• Dalgalar arasında rotayı düzeltmek için daha fazla alan
• Daha uzun destek maliyeti, bakımı yapılacak daha fazla entegrasyon
• Sürekli disiplin ve yönetişim gerektirir

Big Bang

Bir keresinde, her şeyin tek bir hafta sonunda geçtiği bir üretim firmasının SAP canlıya geçişinin parçası oldum. Finans, satın alma, satış ve üretim Pazartesi sabahı hep birlikte canlıya girdi. Yoğundu ama netlik çok güçlüydü. Herkes birlikte hareket etti; hangi sisteme ya da hangi veriye güvenileceği konusunda hiçbir karışıklık yoktu.

Bunu çalıştıran şey: ekip cutover'ı birkaç kez prova etti, veriyi haftalar öncesinden temizledi ve kullanıcıları gerçek test senaryolarıyla eğitti. Avantajı daha hızlı uyum ve daha hızlı getiri. Dezavantajı hata payının olmaması. İlk gün satış siparişlerinde bir fiyatlandırma sorunu çıktığında, her bölgeyi vurdu.

Şu durumlarda işe yarar: süreçler standartlaşmışsa, ekipler hazırsa ve liderlik kapsam konusunda çizgiyi koruyacaksa.

Aşamalı

Bir perakende zinciriyle yaptığımız başka bir projede aşamalı gittik: önce finans, İK ve satın alma, sonra lojistik ve satış noktası. Bir yıldan uzun sürdü ama ekiplere nefes aldırdı. İK ekibi, diğer herkesi eğitmeden önce ilk ayını iş akışlarını çözmekle geçirdi. Bu, Big Bang'de mümkün olmazdı.

Takas, daha uzun bir destek dönemi ve canlı ile henüz canlı olmayan sistemler arasında akan veriye ekstra özen gerekmesi.

Şu durumlarda işe yarar: kuruluş büyük ya da dağınıksa, süreçler bölgeye göre değişiyorsa ya da liderlik rotayı düzeltmek için alan istiyorsa.

Hibrit

Bazen yanıt ikisidir.

Birlikte çalıştığım, Birleşik Krallık'taki bir tüketici elektroniği distribütörü finans ve satın almayı hızla canlıya almak istiyordu. Çok fazla bağımlılık yüzünden deposu hazır değildi. Bu yüzden önce finans ve satın alma, ardından lojistik ve depolama canlıya geçti. Bir alanda Big Bang, diğerinde aşamalı.

Hibrit koordinasyon işi ekler. Satın alma SAP'deyse ve satış değilse, aralarındaki veri senkronizasyonu dikkatli bir tasarım gerektirir ve yönetişim baştan sona keskin kalmalıdır.

Şu durumlarda işe yarar: iş birimleri farklı hızlarda ilerliyorsa, bazı departmanlar daha hızlı geçmek zorundaysa ya da mevsimsel zirveler belirli canlıya geçiş tarihlerini dışarıda bırakıyorsa.

Üçünün karşılaştırması:

Ölçüt	Big Bang	Aşamalı	Hibrit
Zaman çizelgesi	En kısa: her şey bir arada	Daha uzun: dalgalara yayılır	Orta: bazı alanlar hızlı, diğerleri daha yavaş
İş kesintisi	Canlıya geçişte sorun çıkarsa yüksek	Daha düşük: değişim kademeli	İlk dalga için yüksek, sonrası için daha düşük
Risk	Sorunlar tüm işi vurur	Sorunlar bir faz içinde kalır	Big Bang kısımlarında yoğunlaşır
Maliyet	Daha düşük başlangıç, pahalı hatalar	Daha yüksek toplam, daha az acil durum	Arada; koordinasyon belirsiz unsurdur
Veri taşıma	Tek pencere; eksiksiz olmalı	Bölünmüş yüklemeler, faz başına daha az	Canlı ve henüz canlı olmayan sistemler arasındaki arayüzler zor kısımdır
Kullanıcı benimsemesi	Zor: değişim bir gecede	Daha kolay: kademeli maruz kalma	İlk dalga öncülük eder; sonraki dalgalar onlardan öğrenir
En uygun olduğu durum	Daha küçük kuruluşlar, standart süreçler, yüksek hazırlık	Süreçleri değişen büyük, dağınık işletmeler	Bazı birimlerin hazır, diğerlerinin hazır olmadığı çok birimli kuruluşlar

Decide

Hangi geçiş yolu sizin durumunuza uyuyor?

Eski ortam parçalı ve süreçleri yeniden tasarlamak istiyorsunuz

→Greenfield

Süreçler sağlam, ECC kararlı, geçmiş korunmalı

→Brownfield

Çok tüzel kişilikli, kısmi yeniden kullanım ve seçici veri istiyorsunuz

→Bluefield

Greenfield: sıfırdan başlamak

Bu yaklaşımı, satın almalarla hızla büyümüş ve sistemleri parçalı olan bir perakende şirketinin projesinde gördüm. Temiz başladık ve S/4HANA üzerinde birleşik süreçler tasarladık. Kendi yöntemlerine alışmış ekipler önce direndi. Sonuç, bölgeler arasında daha fazla tutarlılık, daha temiz raporlama ve birbiriyle konuşan sistemler oldu.

Şu durumlarda kullanın: eski sistemler temiz taşınamayacak kadar parçalı ya da özelleştirilmişse ve işletme eski alışkanlıkları dijitalleştirmek yerine nasıl çalıştığını yeniden düşünmek istiyorsa.

Brownfield: dönüştür ve yükselt

Daha önceki projelerimden birinde, bir üretim şirketiyle, brownfield doğru karardı. Müşteri ECC sistemini ağır biçimde özelleştirmişti ve baştan başlamak çok riskli görünüyordu. S/4HANA'ya teknik dönüşüme odaklandık. Kullanıcılar daha hızlı alıştı ve daha erken canlıya geçtik, ama yeniden tasarlanması gereken hantal iş akışlarını da yanımızda taşıdık.

Şu durumlarda kullanın: mevcut süreçler sağlam ve belgelenmişse, işlem geçmişi denetim ya da uyumluluk için önemliyse, bütçe ya da zaman kısıtlıysa ve kuruluş yeniden yapılanmıyorsa.

Bluefield: seçici geçiş

Bluefield (seçici veri geçişi) her şeyi değil, belirli şirket kodlarını, iş birimlerini ya da tarih aralıklarını taşır. Birleşme ya da ayrılma operasyonlarıyla şekillenmiş işletmelere ve kimsenin ihtiyaç duymadığı yılların verisini taşıyan sistemlere uygundur. Tutmayı seçtiğiniz kısımlar için greenfield tarzı süreç özgürlüğünü, brownfield tarzı süreklilikle birlikte alırsınız. ECC'den S/4HANA'ya geçiş rehberim üç yolu ve zaman çizelgelerini daha derinlemesine ele alıyor.

2018'de devreye alım modeli ve geçiş yolu stratejinin tamamıydı. 2026'da bir üçüncü karar var ve diğer ikisini sınırlıyor: S/4HANA'nın hangi sürümünü çalıştırdığınız ve onu nasıl satın aldığınız.

1. 03Devreye alım modeliBig Bang, aşamalı ya da hibrit, ne kadar kesintiyi karşılayabileceğinize göre belirlenir
2. 02Geçiş yoluGreenfield, brownfield ya da bluefield, sürümün desteklediği çerçevede
3. 01Dağıtım modeliPublic Edition, Private Edition ya da on-premise. Önce bunu belirleyin

S/4HANA Cloud Public Edition (genellikle GROW with SAP üzerinden satın alınır, SAP tarafından SAP Cloud ERP olarak pazarlanır). Çok kiracılı SaaS, SAP'nin standart süreçleri, altı ayda bir yükseltme, çekirdek değişikliği yok. Yalnızca greenfield. Değere en hızlı ulaşım, en az esneklik. SAP standardını benimsemeye istekli orta ölçekli şirketler için en iyisi. Süreçleriniz önemli ölçüde sapma gerektiriyorsa yanlış yanıttır.

S/4HANA Cloud Private Edition (genellikle RISE with SAP üzerinden satın alınır). Tek kiracılı, SAP tarafından işletilen altyapı, iki yılda bir yeni sürüm ve yedi yıllık ana akım bakım, yapılandırma ve genişletme için daha fazla alan. Brownfield, greenfield ve seçici geçişleri destekler. Çoğu büyük kurumsal program için varsayılan.

S/4HANA on-premise. Altyapıyı siz ya da hyperscaler'ınız işletir. En fazla genişletilebilirlik ve kontrol, en yavaş yükseltme temposu. Clean core önerilir ama zorunlu kılınmaz. Katı veri yerleşimi gereksinimlerine ve güçlü şirket içi Basis ekiplerine sahip kuruluşlara uygundur. SAP'nin yeni yetenekleri giderek daha çok önce bulut sürümlerine geliyor.

Devreye alım modeli ve geçiş yolu daha sonra seçtiğiniz sürümün içinde yer alır. Public Edition projesi tanım gereği greenfield'dır. Ağır biçimde özelleştirilmiş bir ECC sistemini dönüştüren Private Edition programı genellikle brownfield ya da bluefield'dır ve ölçekte genellikle aşamalıdır. RISE ve GROW'un ticari tarafı için GROW with SAP ve RISE with SAP sayfalarıma bakın.

Bir perşembe sabahıydı, bir tasarım atölyesinin ortasında. BT lideri SAP'nin standart sipariş-tahsilat sürecini göstermeyi yeni bitirmişti. Satıştan biri şöyle dedi: “Evet ama biz böyle yapmıyoruz.” Oda sessizleşti. O an hemen her projede yaşanır.

Fit-to-standard

Standart SAP'de kalmak uygulama süresini ve uzun vadeli bakımı azaltır. Yükseltmeler, var olmayan özel mantığı bozamaz. Üzerinde çalıştığım bir perakende projesinde fit-to-standard, müşterinin altı aydan kısa sürede canlıya geçmesine yardımcı oldu: daha az hareketli parça, daha az gidiş geliş, gelecekteki yükseltmeler için daha temiz bir sistem.

Pratik kural: yalnızca mevzuat gerektiriyorsa ya da süreç size gerçek bir rekabet avantajı sağlıyorsa özelleştirin. “Hep böyle yaptık” diye asla.

Uygulamada clean core

Her ortaktan yayımlanmış API'ler ya da SAP BTP üzerinde geliştirdiği uzantılara örnekler isteyin. Yanıt belirsizse bunu bir kırmızı bayrak sayın. Bulut programına on-premise alışkanlıkları getiren ortaklar ilk sprint'ten itibaren teknik borç biriktirir.

Kodun kaçınılmaz olduğu durumlar

Bazı özel geliştirmeler gerekli. SAP Build Code ve geliştiriciler için Joule gibi yapay zeka araçları onu yazmanın maliyetini düşürür. Sürdürmenin maliyetini düşürmez.

Kimsenin belgelemediği özel mantık, kimsenin dokunmak istemediği mantığa dönüşür ve bu sonraki her değişikliği geciktirir. Hiçbir yapay zeka aracı bunu çözmez. Belgeleme disiplini çözer. Özelleştirmek zorundaysanız baştan belgeleyin, yayımlanmış API'ler ya da BTP üzerinde geliştirin ve çekirdekten izole tutun. Temiz özelleştirmenin geri kazanabileceğiniz gerçek bir maliyeti var. Temiz olmayan özelleştirmenin ödemeye devam ettiğiniz bir maliyeti var.

Bunlar, 2026'da S/4HANA için ABD pazarında gördüğüm toplam program maliyeti aralıkları. Kapsama, karmaşıklığa, sektöre, ortağa ve sürüme göre değişirler. Bunları bütçe planlaması için referans noktası olarak kullanın, teklif olarak değil.

Strateji ve kapsam	Tipik toplam program maliyeti
Orta pazar brownfield, aşamalı	5 ila 15 milyon $
Orta pazar greenfield, Big Bang	8 ila 20 milyon $
Orta pazar GROW with SAP (abonelik ve teslimat)	2 ila 6 milyon $
Kurumsal brownfield, aşamalı	25 ila 80 milyon $
Kurumsal greenfield, Big Bang	35 ila 120 milyon $
Kurumsal RISE with SAP (abonelik ve teslimat)	20 ila 80 milyon $
Küresel çok bölgeli, herhangi bir kombinasyon	100 ila 300 milyon $ ve üzeri

Dağıtım modeli, en sık hafife alınan maliyet değişkenidir. RISE ve GROW abonelikleri, çok yıllık taahhüt toplandığında on-premise lisanslardan daha ucuz değildir. Değerleri, kayan altyapı sorumluluğunda, daha hızlı değere ulaşımda ve öngörülebilir abonelik maliyetlerinde yatar. RISE ya da GROW lehine argüman nadiren toplam maliyettir. İşletim modelidir.

SAP uygulama stratejisi nedir?

Bir şirketin SAP'yi devreye almak için kullandığı yaklaşımdır: kapsam, yöntem, dağıtım modeli, geçiş yolu, devreye alım modeli ve zaman çizelgesi. 2026'daki ana seçimler dağıtım modeli (Public Edition, Private Edition ya da on-premise), geçiş yolu (greenfield, brownfield ya da bluefield) ve devreye alım modeli (Big Bang, aşamalı ya da hibrit).

Önemli olan, bu kombinasyonun kuruluşun hazırlığına, süreç karmaşıklığına, mevzuat profiline ve kesintiye toleransına uyup uymadığıdır.

Big Bang uygulaması ne zaman işe yarar?

Süreçler zaten standartlaşmışsa, kullanıcılar iyi eğitilmişse, veri taşımadan önce temizlenmişse ve liderlik kapsamı koruyacaksa. Bunlardan herhangi biri eksikse, özellikle temiz veri ve kullanıcı hazırlığı, bu bir kumardır.

Canlıya geçişteki sorunlar her şeyi aynı anda vurur. Hazırlıkla bu yönetilebilir. Hazırlık olmadan bir krizdir.

Greenfield ve brownfield SAP uygulaması arasındaki fark nedir?

Greenfield yeni bir sistemle başlar; eski konfigürasyondan hiçbir şey taşınmaz. Süreçleri SAP'nin standardı etrafında sıfırdan tasarlarsınız. Brownfield mevcut sistemi dönüştürür, işlem geçmişini ve konfigürasyonu korur.

Greenfield başlangıçta daha pahalıdır ve daha temiz, geleceğe daha hazır bir sistem üretir. Brownfield daha hızlı ve daha az kesintilidir ama geçici çözümleri ve özel kodu da taşır. Bluefield orta yoldur: seçtiğiniz tüzel kişiliklerin ve verilerin seçici geçişi.

RISE with SAP ile GROW with SAP arasındaki fark nedir?

RISE with SAP, büyük kuruluşlar için SAP'nin abonelik teklifidir; genellikle S/4HANA Cloud Private Edition üzerine kuruludur ve SAP tarafından işletilen altyapıyı ve teknik operasyonları tek bir sözleşmede sunar. ABD pazarında teslimat dahil tipik olarak 20 ila 80 milyon dolarlık toplam programlar görüyorum.

GROW with SAP orta ölçekli şirketlere yöneliktir ve SAP'nin standart süreçleriyle S/4HANA Cloud Public Edition üzerinde çalışır. Teslimat dahil tipik olarak 2 ila 6 milyon dolar görüyorum.

Aralarında şirket büyüklüğü ve süreçlerinizin SAP standardından ne kadar ayrışması gerektiği karar verir.

SAP'de fit-to-standard nedir ve neden artık daha önemli?

Fit-to-standard, SAP'yi bugün çalıştığınız şekle uydurmak için özelleştirmek yerine süreçlerinizi SAP'nin standart işlevselliğine uyarlamak demektir. Uygulamayı kısaltır, bakımı azaltır ve yükseltmeleri temizler.

Clean core nedeniyle artık daha önemli. Public Edition'da çekirdek değişikliği hiç mümkün değil. Private Edition ve on-premise'de her değişiklik yükseltme işi ekler. Sorulacak soru, standart SAP'nin karşılayamadığı gerçek bir iş nedeninin olup olmadığı ve varsa ortağınızın uzantıyı yayımlanmış API'ler ya da SAP BTP üzerinde geliştirip geliştiremeyeceğidir.

SAP Activate metodolojisinin aşamaları nelerdir?

SAP Activate altı aşamadan oluşur. Discover (SAP'nin tekliflerini ve iş gerekçesini keşfetme), ardından dört çekirdek teslimat aşaması: Prepare (planlama, yönetişim, ekibi kurma), Explore (fit-to-standard atölyeleri ve backlog), Realize (sprint'lerde konfigüre etme, genişletme, test etme) ve Deploy (cutover, canlıya geçiş ve hypercare). Run, canlıya geçiş sonrası operasyonları kapsar.

Projelerin çoğu zamanı Realize'da kaybeder; özellikle test sırasında veri kalitesi sorunları ortaya çıktığında ya da özelleştirme kapsamı büyüdüğünde. Realize boyunca sıkı bir kapsam referans çizgisi, zamanında canlıya geçen projeleri savrulanlardan ayırır.

SAP uygulamaları neden başarısız olur?

Başarısızlıkların çoğunu dört neden açıklar: kick-off'tan sonra kaybolan üst yönetim katılımı, BT işi olarak ele alınan veri taşıma, eğitim kılavuzlarıyla sınırlı kalan değişim yönetimi ve ilk yükseltmede ortaya çıkan teknik borç yaratan, clean core deneyimi olmayan ortaklar.

Teknoloji nadiren başarısız olur. Programlar, kararlar alınmadığında, kirli veri yeni sisteme ulaştığında, kullanıcılar geçici çözümler bulduğunda ya da özelleştirmeler yeniden yazılmak zorunda kaldığında başarısız olur. Strateji önemlidir. İcra disiplini daha da önemlidir.