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

En iyi SAP uygulama stratejisi, işletmenize uyan ve ekibinizin sürdürebileceği stratejidir. Üç karara indirgenir. Hangi dağıtım modeli: S/4HANA Cloud Public Edition (genellikle GROW with SAP üzerinden), Private Edition (genellikle RISE with SAP üzerinden) veya on-premise. Hangi göç yolu: greenfield, brownfield veya bluefield. Ve hangi geçiş modeli: Big Bang, aşamalı veya hibrit. Bu rehber, S/4HANA için yaklaşım seçen CIO'lar, program direktörleri ve sponsorlar için. Aşağıdaki beş soruyu yanıtlayın, önce dağıtım kararını verin, ardından diğer ikisini netleştirmek için karşılaştırma tablosunu ve karar ağacını kullanın.

Üzerinde çalıştığım 21 programda örüntüler tutarlı. Strateji seçimi gerçek bir karar, ama kararın küçük yarısı. Büyük yarısı, seçenek tablosu rafa kaldırıldıktan sonra ekibin 14 aylık uygulama boyunca disiplini koruyup koruyamayacağıdır.

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

Önce yanıtlanması gereken beş soru

1. Yapınız ne kadar karmaşık: tek şirket, çok şirket, çok ülke?
2. Ekiplerinizin uyum sağlamak için zamana mı ihtiyacı var, yoksa değişime şimdi hazırlar mı?
3. Birkaç eski sistemden mi, tek bir ERP'den mi geçiyorsunuz, yoksa sıfırdan mı başlıyorsunuz?
4. Şirket içinde SAP uzmanlığınız var mı, yoksa iş ortaklarına mı bağımlı olacaksınız?
5. Canlıya geçişte ne kadar aksamaya tahammül edebilirsiniz?

Evrensel bir cevap yok. Stratejiniz başkasının başarı hikâyesini değil, sizin gerçekliğinizi yansıtmalı.

2023 ile 2026 arasında neler 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ı ve BTP kredilerini tek bir abonelikte toplar. GROW with SAP, standart süreçlere sahip orta ölçekli şirketler için Public Edition'ı paketler. Önce lisans alıp sonra uygulama yapan geleneksel model on-premise için hâlâ var, ama yeni görüşmelerin çoğu RISE veya GROW ile başlıyor.

Clean Core bir tavsiye olmaktan çıkıp mimariye dönüştü. Public Edition'da çekirdeği değiştiremezsiniz: uzantılar, ya ABAP Cloud ile on-stack ya da SAP BTP üzerinde side-by-side olarak yayımlanmış API'leri kullanır. Private Edition'da ve on-premise'de hâlâ değiştirebilirsiniz, ama SAP'nin yönergeleri değişikliği son çare olarak görür, çünkü her değişiklik yükseltme işini artırır. Clean Core deneyimi olmayan iş ortakları ilk haftadan teknik borç yaratır.

Yapay zeka, uygulama araçlarına girdi. SAP Joule for Consultants (Mayıs 2025'ten beri genel kullanımda) yapılandırma sorularını SAP'nin kendi içeriğinden yanıtlar. SAP Cloud ALM, Fit-to-Standard çalıştaylarının dökümlerinden gereksinim taslakları hazırlayabilir. SAP Build Code (Mart 2024'ten beri genel kullanımda) Java ve JavaScript uzantıları üretmek için Joule'ü kullanır, Joule for developers ise 2024 sonundan itibaren ABAP kodu üretme ve açıklama özelliği ekledi. Bunların hiçbiri stratejik seçimi değiştirmez. Hangi seçimi yaparsanız yapın, o seçimin içindeki maliyeti ve süreyi değiştirir.

Stratejiler nerede başarılı olur, nerede başarısız olur

Uygulama, seçimden daha önemlidir. Hangi yaklaşım seçilirse seçilsin dört başarısızlık örüntüsü ortaya çıkar.

1. Kaybolan üst yönetim katılımı. Bir bankadaki S/4HANA uygulamasında CEO her önemli toplantıya geldi, iyi sorular sordu ve ekibin arkasında durdu. Proje zamanında bitti ve planlanandan az harcadı. Bir mağaza zincirinin yöneticileri ise açılış toplantısından sonra her şeyi devretti. Proje aylarca durdu, çünkü kimse karar veremiyordu.
2. Bir BT görevi olarak görülen veri göçü. Bir müşteri, ürün ana verilerinin “yeterince temiz” olduğunda ısrar etti. İlk gün deposu, üç yıl önce üretimden kaldırılmış ürünler için sipariş aldı. Temizlik haftalar sürdü ve şirkete büyük bir müşterisine mal oldu. Veri göçünün iş tarafında bir sahibi olmalı.
3. Atlanan ya da aceleye getirilen eğitim. SAP'nin devreye alınmasından iki hafta sonra bir ofisi ziyaret ettim. Muhasebe ekibinin monitörleri, temel işlemler için hatırlatma notlarıyla doluydu; bir günlük eğitim almışlardı. Yöneticileri 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 çalışanlar. Eğitimin yeterli olduğunu düşünen bir fabrikayla çalıştım. İşçiler yeni sisteme güvenmedi ve tablolara geri döndü. Bunu canlıya geçişten sonra düzeltmek pahalıya mal oldu. Değişim yönetimi; iletişim, katılım ve işletme içindeki gönüllü elçilerdir, eğitim bunun yalnızca bir parçasıdır.

İki ana geçiş modeli

Big Bang

1. 01Her şey tek bir cutover ile canlıya geçer
2. 02Standart süreçlere giden en hızlı yol
3. 03Başlangıç maliyeti düşük, ilk gün riski yüksek
4. 04Sıkı provalar ve temiz veri gerektirir

Aşamalı

1. 01Modül, bölge veya fonksiyona göre dalgalar hâlinde canlıya geçiş
2. 02Dalgalar arasında rotayı düzeltmek için daha fazla alan
3. 03Daha uzun destek maliyeti, bakımı gereken daha fazla entegrasyon
4. 04Sürekli disiplin ve yönetişim gerektirir

Big Bang

Bir keresinde bir üretim firmasının, her şeyin tek bir hafta sonunda geçiş yaptığı SAP canlıya geçişinde yer aldım. Finans, satın alma, satış ve üretim pazartesi sabahı hep birlikte canlıya geçti. Yoğundu, ama netlik çok güçlüydü. Herkes birlikte hareket etti; hangi sisteme ya da hangi veriye güvenileceği konusunda kafa karışıklığı yoktu.

İşe yaramasını sağlayan şey: ekip cutover'ı birkaç kez prova etti, verileri haftalar öncesinden temizledi ve kullanıcıları gerçek test senaryolarıyla eğitti. Artısı daha hızlı uyum ve daha hızlı getiridir. Eksisi hataya hiç pay olmamasıdır. İlk gün bir fiyatlandırma sorunu satış siparişlerini etkilediğinde, her bölgeyi etkiledi.

İşe yaradığı durum: süreçler standart, ekipler hazır ve yönetim kapsamı sıkı tutacaksa.

Aşamalı

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

Bedeli daha uzun bir destek dönemidir; canlıdaki sistemlerle henüz canlıya geçmemiş sistemler arasında akan veri de ekstra özen ister.

İşe yaradığı durum: kuruluş büyük ya da dağınıksa, süreçler bölgeye göre farklıysa veya yönetim rotayı düzeltmek için alan istiyorsa.

Hibrit

Bazen cevap ikisi birden.

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

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

İşe yaradığı durum: iş birimleri farklı hızlarda ilerliyorsa, bazı departmanların daha hızlı gitmesi gerekiyorsa veya sezonluk yoğunluklar bazı canlıya geçiş tarihlerini dışarıda bırakıyorsa.

Üçü şöyle karşılaştırılır:

Kriter	Big Bang	Aşamalı	Hibrit
Süre	En kısa: her şey bir anda	Daha uzun: dalgalara yayılır	Orta: bazı alanlar hızlı, diğerleri daha yavaş
İşletmede aksama	Canlıya geçişte sorun olursa yüksek	Daha düşük: değişim kademeli	İlk dalgada yüksek, sonra daha düşük
Risk	Sorunlar tüm işletmeyi vurur	Sorunlar bir aşamanın içinde kalır	Big Bang yapılan bölümlerde yoğunlaşır
Maliyet	Başta düşük, hatalar pahalı	Toplamda yüksek, daha az acil durum	Arada; koordinasyon belirsiz unsurdur
Veri göçü	Tek pencere; eksiksiz olmalı	Bölünmüş yüklemeler, aşama başına daha az	Canlıdaki ve canlı öncesi sistemler arasındaki arayüzler işin zor kısmıdır
Kullanıcı benimsemesi	Zor: değişim bir gecede	Daha kolay: kademeli tanışma	İlk dalga öncüdür; sonraki dalgalar onlardan öğrenir
En uygun olduğu yer	Daha küçük kuruluşlar, standart süreçler, yüksek hazırlık	Çeşitli süreçlere sahip büyük, dağınık şirketler	Bazı birimleri hazır, bazıları hazır olmayan çok birimli kuruluşlar

Decide

Durumunuza hangi göç yolu uyar?

→Greenfield

Eski sistemler dağınık ve süreçleri yeniden tasarlamak istiyorsunuz

→Brownfield

Süreçler sağlam, ECC istikrarlı, geçmiş veriler kalmalı

→Bluefield

Çok şirketli yapı, kısmi yeniden kullanım ve seçici veri isteniyor

Greenfield: sıfırdan başlamak

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

Ne zaman kullanılır: eski sistemler temiz bir şekilde taşınamayacak kadar dağınık 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ürmek ve yükseltmek

Bir üretim şirketiyle yaptığım eski projelerimden birinde brownfield doğru karardı. Müşteri ECC sistemini yoğun biçimde özelleştirmişti ve baştan başlamak fazla 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.

Ne zaman kullanılır: mevcut süreçler sağlam ve belgelenmişse, işlem geçmişi denetim veya uyum açısından ö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 veya tarih aralıklarını taşır. Birleşme ya da bölünmelerle şekillenmiş işletmelere veya kimsenin ihtiyaç duymadığı yılların verisini taşıyan sistemlere uygundur. Korumayı seçtiğiniz bölümler için greenfield tarzı süreç özgürlüğünü brownfield tarzı süreklilikle birlikte elde edersiniz. ECC'den S/4HANA'ya göç rehberim üç yolu ve sürelerini daha ayrıntılı ele alıyor.

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

1. 03Geçiş modeliBig Bang, aşamalı veya hibrit, ne kadar aksamayı kaldırabileceğinize göre belirlenir
2. 02Göç yoluGreenfield, brownfield veya bluefield, sürümün desteklediği sınırlar içinde
3. 01Dağıtım modeliPublic Edition, Private Edition veya on-premise. Önce buna karar verin

S/4HANA Cloud Public Edition (genellikle GROW with SAP üzerinden satın alınır ve SAP tarafından SAP Cloud ERP olarak pazarlanır). Çok kiracılı SaaS, SAP'nin standart süreçleri, altı ayda bir yükseltme, çekirdekte değişiklik yok. Yalnızca greenfield. Değere en hızlı ulaşma, en az esneklik. Standart SAP'yi benimsemeye istekli orta ölçekli şirketler için en iyisi. Süreçlerinizin ciddi sapmalara ihtiyacı varsa yanlış cevaptı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ı, yedi yıllık ana bakımla iki yılda bir yeni sürüm ve yapılandırma ile genişletme için daha fazla alan. Brownfield, greenfield ve seçici geçişleri destekler. Büyük kurumsal programların çoğu için varsayılan seçenek.

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

Geçiş modeli ve göç yolu daha sonra seçtiğiniz sürümün içine yerleşir. Public Edition projesi tanımı gereği greenfield'dır. Yoğun biçimde özelleştirilmiş bir ECC sistemini dönüştüren bir Private Edition programı genellikle brownfield veya bluefield olur ve büyük ölçekte genellikle aşamalı ilerler. 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 çalıştayının ortasındaydık. BT lideri SAP'nin standart order-to-cash sürecini göstermeyi yeni bitirmişti. Satıştan biri “Evet ama biz bunu böyle yapmıyoruz” dedi. Odaya sessizlik çöktü. Bu an neredeyse 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. Ç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 gidip gelme, gelecekteki yükseltmeler için daha temiz bir sistem.

Pratik kural: yalnızca mevzuat gerektirdiğinde ya da süreç size gerçek bir rekabet avantajı sağladığında özelleştirin. Asla “hep böyle yaptık” diye değil.

Uygulamada Clean Core

Her iş ortağından, yayımlanmış API'ler veya SAP BTP üzerinde geliştirdiği uzantı örnekleri isteyin. Cevap belirsizse bunu bir uyarı işareti sayın. On-premise alışkanlıklarını bir bulut programına taşıyan iş ortakları ilk sprintten itibaren teknik borç biriktirir.

Kodun kaçınılmaz olduğu durumlar

Bir miktar özel geliştirme gereklidir. SAP Build Code ve Joule for developers gibi yapay zeka araçları onu yazmanın maliyetini düşürür. Bakımının maliyetini düşürmez.

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

Bunlar 2026'da S/4HANA için gördüğüm toplam program maliyeti aralıkları. Rakamı stratejiden çok daha fazla şirket büyüklüğü ve kapsam belirler. Bunları teklif olarak değil, bütçe planlamasında dayanak noktası olarak kullanın; tam döküm için 2026 SAP uygulama maliyet aralıklarıma bakın.

Şirket büyüklüğü	Tipik toplam program maliyeti
Küçük (200 çalışanın altı)	80 bin ile 500 bin dolar
Orta ölçek (200 ile 1.000 çalışan)	500 bin ile 2 milyon dolar
Büyük kurumsal (1.000 ile 10.000 çalışan)	2 milyon ile 10 milyon doların üzeri
Küresel grup (10.000+ çalışan)	10 milyon ile 50 milyon doların üzeri

Strateji sizi bir aralığın içinde hareket ettirir, aralıklar arasında değil. Greenfield başlangıçta brownfield'dan daha pahalıdır, Big Bang ise daha düşük başlangıç maliyetini ilk gündeki daha yüksek riskle takas eder. Üzerine yüzde 10 ila 20 arasında yedek pay ayırın ve uygulama hizmetlerinin toplamın yüzde 35 ila 50'sini oluşturmasını bekleyin.

Dağıtım modeli, en sık hafife alınan maliyet değişkenidir. Çok yıllık taahhüt toplandığında RISE ve GROW abonelikleri on-premise lisanslardan daha ucuz değildir. Değerleri, altyapı sorumluluğunun devredilmesinde, değere daha hızlı ulaşmada ve öngörülebilir abonelik maliyetlerindedir. RISE veya GROW'un gerekçesi nadiren toplam maliyettir. Gerekçe işletim modelidir.

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

SAP uygulama stratejisi nedir?

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

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

Big Bang uygulaması ne zaman işe yarar?

Süreçler zaten standartlaştırılmışsa, kullanıcılar iyi eğitilmişse, veriler göçten önce temizlenmişse ve yönetim kapsamı sıkı tutacaksa. Bunlardan herhangi biri, özellikle temiz veri ve kullanıcı hazırlığı olmadan, 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, hiçbir eski yapılandırma taşınmadan yeni bir sistemle başlar. Süreçleri SAP standardı etrafında sıfırdan tasarlarsınız. Brownfield, işlem geçmişini ve yapılandırmayı koruyarak mevcut sistemi dönüştürür.

Greenfield başlangıçta daha pahalıdır ve daha temiz, geleceğe daha hazır bir sistem ortaya çıkarır. Brownfield daha hızlı ve daha az sarsıcıdır, ama geçici çözümleri ve özel kodu ileriye taşır. Bluefield orta yoldur: seçtiğiniz şirketlerin ve verilerin seçici olarak taşınması.

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

RISE with SAP, SAP'nin büyük şirketler için 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 toplar. Uygulama dahil, 9 ila 18 ay içinde büyük bir şirket için genellikle 2 milyon ile 10 milyon doların üzeri, küresel bir grup için 10 milyon ile 50 milyon doların üzeri arasında toplam program maliyetleri görüyorum.

GROW with SAP orta ölçekli şirketleri hedefler ve SAP'nin standart süreçleriyle S/4HANA Cloud Public Edition üzerinde çalışır. Orta ölçekli bir şirket için, uygulama dahil ve yaklaşık 6 ila 9 ay içinde genellikle 500 bin ile 2 milyon dolar arası görüyorum.

İkisi arasındaki seçimi şirket büyüklüğü ve süreçlerinizin SAP standardından ne kadar farklılaşması gerektiği belirler.

SAP'de Fit-to-Standard nedir ve neden şimdi daha önemli?

Fit-to-Standard, SAP'yi bugün nasıl çalıştığınıza göre ö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 yüzünden şimdi daha önemli. Public Edition'da çekirdek değişikliği hiç mümkün değil. Private Edition'da ve on-premise'de her değişiklik yükseltme işini artırır. Sorulacak soru, standart SAP'nin karşılayamayacağı gerçek bir iş gerekçesi olup olmadığı ve varsa iş ortağınızın uzantıyı yayımlanmış API'ler veya 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şfetmek), ardından dört temel uygulama aşaması: Prepare (planlama, yönetişim, ekibin kurulması), Explore (Fit-to-Standard çalıştayları ve iş listesi), Realize (sprintler hâlinde yapılandırma, genişletme, test) ve Deploy (cutover, canlıya geçiş ve hypercare). Run, canlıya geçiş sonrasındaki operasyonları kapsar.

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

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

Başarısızlıkların çoğunu dört neden açıklar: açılış toplantısından sonra kaybolan üst yönetim katılımı, bir BT görevi olarak görülen veri göçü, eğitim kılavuzlarıyla sınırlı kalan değişim yönetimi ve ilk yükseltmede ortaya çıkan teknik borcu yaratan, Clean Core deneyimi olmayan iş ortakları.

Teknoloji nadiren başarısız olur. Programlar, kararlar verilmediğinde, kirli veri yeni sisteme ulaştığında, kullanıcılar geçici çözümler bulduğunda veya özelleştirmelerin yeniden yapılması gerektiğinde başarısız olur. Strateji önemlidir. Uygulama disiplini daha önemlidir.