SAP projeleri neden bütçeyi aşar ve bu nasıl durdurulur

SAP projeleri çoğunlukla şirketler başlangıçta maliyeti düşük tutmaya çalıştığı ve ardından Fit-to-Standard çalıştaylarının gerçek kapsamı gösterdiği Explore aşamasında darbeyi yediği için bütçeyi aşar. İncelediğim programlarda yüzde 40 ile 60 arası aşımlar yaygındır.

Kısa cevap: bir SAP bütçesi, kapsamı kimse bilmeden belirlendiğinde ve bu kapsamı müşteri yerine tedarikçi kontrol ettiğinde aşılır. Explore aşamasında WRICEF sayısını izleyin, kapsamın sahibi siz olun ve yüzde 10 ile 20 yedek payı kendi tarafınızda tutun.

Anket ortalamaları daha sakin görünür. Panorama Consulting'in 2026 ERP Raporu, kuruluşların dörtte birinden fazlasının ERP bütçesini aştığını ve başlıca nedenin ek teknoloji ihtiyaçları olduğunu ortaya koydu. Anket ortalamaları ile sonunda bir danışmanın önüne gelen programlar farklı popülasyonlardır; bu yüzden ikincisine göre plan yapın.

40-60%

incelediğim SAP programlarında sıkça gördüğüm bütçe aşımı

Kaynak: Noel D'Costa, yayımlanmış gözlem

Bu yazı başlangıç rakamıyla değil, aşımla ilgili. Şirket büyüklüğüne göre maliyet aralıkları, paranın nereye gittiği, günlük ücretler ve bir bütçe formülü için SAP uygulamasının ne kadar tuttuğuna dair rehberimi okuyun.

Yönettiğim ya da kurtardığım 21 SAP programında aynı nedenler tekrar tekrar karşıma çıkıyor. Bunların çoğu sözleşme imzalanmadan önce görülebilir.

1. Bütçe düşük belirlenir, sonra Explore gerçek kapsamı gösterir

Gördüğüm en yaygın neden bu. Şirketler başlangıçta maliyeti düşük tutmaya çalışır; çoğu zaman iş gerekçesinin yönetim kurulunun onaylayacağı bir rakama ihtiyacı olduğu için. Sonra Explore aşaması gelir.

SAP Activate'te Explore, Fit-to-Standard çalıştaylarının SAP'nin standart süreçlerini işletmenin gerçekte nasıl çalıştığıyla karşılaştırdığı aşamadır (SAP Learning). Orada bulunan her boşluk bir backlog öğesine dönüşür: bir rapor, bir arayüz, bir dönüşüm, bir geliştirme, bir form veya bir iş akışı. Bunların hiçbiri ilk fiyatta yoktu.

Bütçe biri hesap hatası yaptığı için yanlış değildi. Kapsam henüz oluşmadan belirlendiği için yanlıştı. Mümkünse nihai rakamı onaylamadan önce kısa bir Fit-to-Standard değerlendirmesi yaptırın.

2. Kapsamı tedarikçi kontrol eder

İmzadan önce gördüğüm en büyük maliyet hatası, kapsamın kontrolünü tedarikçiye bırakmaktır. Kapsamı sistem entegratörü yazdığında, kapsam işletmenin neye ihtiyaç duyduğunu değil, entegratörün neyi teslim etmeyi planladığını anlatır.

Boşluklar daha sonra değişiklik talepleri olarak ortaya çıkar ve her değişiklik talebini aynı tedarikçi fiyatlandırır. Kapsamı kendiniz yazın ya da uygulamadan bağımsız birinin sizinle birlikte yazmasını sağlayın.

3. Maliyet kontrolü olmadan kapsam değişiklikleri

Bir perakende zinciri 5 milyon $ bütçe ayırdı ve 12,3 milyon $ ile bitirdi. Zayıf gereksinim toplama sürekli kapsam değişikliklerine yol açtı. Yolun yarısında şirket, stok süreçlerinin SAP'nin standart işlevselliğiyle örtüşmediğini fark etti ve ardından kapsamlı bir özelleştirme geldi.

Eski sistemlerinden veri taşımayı da hafife almıştı. Süreçleri tasarım aşamasında standarda uyarlamak çok daha ucuz olurdu.

4. Yönetici baskısıyla belirlenen takvimler

Küresel bir üretim programı bütçeyi %143 aştı (planlanan 5,8 milyon $'a karşı 14 milyon $) ve 11 ay gecikmeyle canlıya geçti. Nedenleri: yöneticilerin gerçekçi olmayan takvim baskısı, yetersiz kadrolu bir iç ekip, aynı anda çok fazla modül ve sektör uzmanlığı olmayan en düşük maliyetli iş ortağı.

Daha ucuz otomatik olarak daha iyi değildir. En düşük maliyetli uygulama seçeneğini tercih eden bir müşteri, daha deneyimli bir ekibin önleyeceği sorunları düzeltmek için sonunda %30 daha fazla harcadı.

5. Yarı zamanlı iç kadro

Özel süreç sahipleri yerine yarı zamanlı temsilciler atayan programlar her kararda günler kaybeder. O küresel üretim programındaki yetersiz kadrolu iç ekip, programın 11 ay gecikmesinin nedenlerinden biriydi.

En iyi çalışanlarınız aylar boyunca zamanlarının yarısını veya daha fazlasını programa ayıracak. Ne onların zamanı ne de canlıya geçiş civarındaki yavaşlama bir tedarikçi teklifinde görünür.

6. Geç fark edilen veri sorunları

Üretim öncesi ortamda fark edilen veri sorunları en pahalı türdür. Profilleme konfigürasyondan sonra değil, gereksinimlerle birlikte yürütülmelidir. Canlı sistem baskısı altında üç aylık temizlik, aşım yaşayan programlarda tutarlı biçimde en büyük gecikme maliyeti kalemi oluyor.

Bu konuyu YouTube kanalımdaki bir videoda da ele alıyorum (İngilizce).

En net erken uyarı işareti Explore aşamasının kendisidir. WRICEF sayısını izleyin: raporlar, arayüzler, dönüşümler, geliştirmeler, formlar ve iş akışları. Bu liste çalıştaydan çalıştaya büyümeye devam ediyorsa bütçe zaten kapsamın gerisinde kalmıştır.

Aşağıdaki işaretlerin her biri yukarıdaki nedenlerden birine işaret ediyor. Çoğu haftalık bir program incelemesinde kontrol edilebilir.

Uyarı işareti	Genellikle ne anlama gelir	Ne yapılmalı
WRICEF sayısı Explore boyunca büyüyor	Gerçek kapsam, fiyatlanan kapsamdan büyük	Explore sonunda, Realize başlamadan önce bütçenin temel çizgisini yeniden belirleyin
Boşluklar varsayılan olarak "geliştirelim" ile kapatılıyor	Standart süreçler sorgulanmıyor	İş sahibinden her boşluğu standarda göre gerekçelendirmesini isteyin
Kapsam belgelerinin taslağını sistem entegratörü hazırlıyor	Neyin fiyatlanacağını tedarikçi belirliyor	Kapsamın sahipliğini üstlenin ve bağımsız biriyle birlikte gözden geçirin
Değişiklik talepleri aylık inceleniyor ya da fiyatlanmıyor	Küçük değişiklikler fark edilmeden birikiyor	Her değişiklik talebini fiyatlandırın ve haftalık olarak gözden geçirin
Explore sonunda veri profilleme başlamamış	Veri sorunları testte veya cutover'da ortaya çıkacak	Profillemeye şimdi, gereksinimlerle birlikte başlayın
Kilit kullanıcılar hâlâ yarı zamanlı	Kararlar yavaşlıyor ve yeniden çalışma artıyor	Günlük işlerini başkasına devredin ya da takvimi kaydırın

Bunların her biri yukarıdaki nedenlerden birini ele alıyor. Hikâyeler, çalıştığım ya da incelediğim programlardan.

1. Kapsamın sahibi olun. Kapsamı müşteri tarafında yazın, Explore sonunda dondurun ve sonraki her değişikliği bir çalıştay notu olarak değil, fiyatlanmış bir karar olarak ele alın.
2. Standart süreçleri benimseyin. Her özelleştirmenin bedeli iki kez ödenir: geliştirirken ve sonra her yükseltmede. Bir üretim müşterisi, özelleştirmek yerine süreçlerini SAP standartlarına uyarlayarak 800 bin $'dan fazla tasarruf etti. Bazı departmanlar için sancılı oldu ama finansal fark çok büyüktü.
3. Yaygınlaştırmayı aşamalara bölün. Bir perakende müşterisi, her şeyi aynı anda yapmak yerine yaygınlaştırmayı 18 aya yayılan üç aşamaya bölerek 1,2 milyon $ tasarruf etti. İlk yatırım %40 düştü ve 1. aşamadan çıkarılan dersler sonraki aşamaları hızlandırdı.
4. Düşük günlük ücrete değil, uzmanlığa ödeme yapın. Kimya sektöründen bir müşteri, genel bir SAP iş ortağından sektör uzmanı bir firmaya geçti ve daha yüksek saatlik ücretlere rağmen toplamda %20 daha az harcadı. Uzmanlar daha hızlı çalıştı ve daha az hata yaptı.
5. Yedek payı kendi tarafınızda tutun. Bütçenin üzerine yüzde 10 ile 20 ayırın ve yalnızca adı konmuş riskler karşılığında serbest bırakın. İş ortağının fiyatı içindeki yedek pay, iş ortağının önceliklerine harcanır.
6. Değişiklik taleplerini haftalık gözden geçirin. Her birini ay sonunda değil, onaylanmadan önce bütçe ve takvim etkisi açısından fiyatlandırın.
7. Regresyon testlerini otomatikleştirin. Tricentis Tosca veya SAP'nin kendi test otomasyonu gibi araçlar, ikiden fazla test döngüsü olan her programda kendini amorti eder; canlıya geçişten sonraki her yükseltme de bir döngü daha demektir.

Ticari taraf için SAP lisans pazarlığı kontrol listem ve CFO'lar için sözleşme maliyet incelemem, imzalamadan önce nelerde ısrar etmeniz gerektiğini anlatıyor.

Abonelik modeli harcamayı sermaye harcamasından işletme giderine kaydırır. Aşım riskini ortadan kaldırmaz ama riskin nerede durduğunu değiştirir.

GROW with SAP, yalnızca yayımlanmış arayüzler üzerinden genişletmeye izin veren S/4HANA Cloud Public Edition üzerinde çalışır. Bu, WRICEF listesinin ne kadar büyüyebileceğini sınırlar ve GROW programları çoğunlukla yaklaşık 6 ile 9 ay sürer. Bedeli, SAP'yi alışılmadık süreçlere uyarlamada daha az özgürlüktür.

RISE with SAP, çekirdeği hâlâ değiştirebildiğiniz S/4HANA Cloud Private Edition üzerinde çalışır. Orada Clean Core teknik bir sınır değil bir yönetişim kararıdır; dolayısıyla Explore aşaması riski on-premise ile aynıdır. RISE programları genellikle 9 ile 18 ay sürer ve çok yıllık abonelik süresinin iş gerekçesinde görünür olması gerekir.

Yapay zeka yeni bir bütçe kalemidir, şimdiden cebe koyulacak bir tasarruf değil. Bazı Joule yetenekleri SAP bulut abonelikleriyle birlikte gelirken premium yapay zeka yetenekleri ayrıca fiyatlandırılır. Yapay zeka tasarrufu vaat eden her iş ortağı ücret tablosunun arkasındaki verimlilik varsayımını isteyin.

Bu, büyük bir programın gelir tablosuna nasıl yansıyacağı açısından önemlidir. UFRS'ye ve US GAAP'e göre kontrol ettiğiniz bir varlığı oluşturmanın maliyetleri aktifleştirilebilir; işletme, eğitim ve hazırlık maliyetleri aktifleştirilemez. Bulut, bütçenin büyük bir dilimi için cevabı değiştirir.

Maliyet unsuru	On-premise lisans	Bulut aboneliği (RISE / GROW)
Lisans veya abonelik ücretleri	Maddi olmayan duran varlık olarak aktifleştirin	Süre boyunca gider yazın (hizmet sözleşmesi)
Konfigürasyon ve geliştirme hizmetleri	Doğrudan ilişkilendirilebiliyorsa aktifleştirin	UFRS: kontrol ettiğiniz ayrı bir varlık oluşturmadıkça çoğunlukla gider yazılır. US GAAP: uygulama maliyetlerini aktifleştirin ve barındırma süresi boyunca itfa edin
Geliştirmede iç işgücü	Doğrudan ilişkilendirilebiliyorsa aktifleştirin	Yukarıdakiyle aynı ayrım
Eğitim ve değişim yönetimi	Gider	Gider
Veri temizliği	Gider	Gider
Elinizde kalan veri dönüştürme araçları	Yeniden kullanılabiliyorsa aktifleştirin	Duruma göre değerlendirin
Hypercare ve destek	Gider	Gider

UFRS pozisyonu, IFRS Interpretations Committee'nin bulut bilişim düzenlemelerindeki konfigürasyon ve özelleştirme maliyetlerine ilişkin 2021 tarihli gündem kararından gelir. US GAAP pozisyonu ASU 2018-15'ten gelir. Özellikle UFRS'de, on-premise aktifleştirmesini varsayan bir RISE iş gerekçesi ilk yıl kârını önemli ölçüde olduğundan yüksek gösterebilir.

Ne kadarını koruyacağınızı dokümantasyon belirler. Bir üretim müşterisi, danışman faaliyetlerini yaklaşımını savunabilecek kadar titizlikle kayıt altına aldığı için doğru aktifleştirmeyle cari yıl giderlerinde 2,3 milyon $ tasarruf etti. Başka bir müşteri ise aktifleştirme kararlarını belgeleyemediği için sancılı bir yeniden düzenleme ile karşılaştı.

Denetçiler büyük aktifleştirilmiş projelere dikkatle bakar. Politikayı yıl sonunda değil, program başlamadan önce onlarla netleştirin.

Aşım yaşayan programların çoğunda bir planlama hatası yoktu. Planlama aşamasında bir dürüstlük hatası vardı. Uygun yedek paya sahip gerçekçi bir planı onaylayan CFO, hiç yedek payı olmayan iyimser bir planı onaylayandan daha az harcar.

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 uygulamaları neden bütçeyi aşar?

Çoğunlukla bütçe başlangıçta düşük tutulduğu, ardından Explore aşaması gerçek kapsamı gösterdiği için. Fit-to-Standard çalıştayları boşlukları hiç fiyatlanmamış raporlara, arayüzlere, dönüşümlere, geliştirmelere, formlara ve iş akışlarına dönüştürür. Tedarikçinin kontrol ettiği kapsam, yarı zamanlı iç ekipler ve geç yapılan veri çalışması durumu kötüleştirir.

SAP projeleri genellikle bütçeyi ne kadar aşar?

İncelediğim programlarda yüzde 40 ile 60 arası aşımlar yaygındır. Panorama Consulting'in 2026 anketi, kuruluşların dörtte birinden fazlasının ERP bütçesini aştığını ortaya koydu. Bir danışmana ulaşan programlar genellikle bu popülasyonun sorunlu kuyruğunu oluşturur.

SAP bütçe aşımının erken uyarı işaretleri nelerdir?

En net işaret, Explore aşaması boyunca büyümeye devam eden bir WRICEF sayısıdır. Diğerleri; tedarikçinin taslağını hazırladığı kapsam belgeleri, haftalık fiyatlanmayan değişiklik talepleri, henüz başlamamış veri profilleme ve hâlâ yarı zamanlı çalışan kilit kullanıcılardır. Liste büyüdüyse Explore sonunda bütçenin temel çizgisini yeniden belirleyin.

Bir SAP projesinde kapsam kayması nasıl durdurulur?

Kapsamı sistem entegratörüne yazdırmak yerine müşteri tarafında sahiplenin. Explore sonunda dondurun, her boşluğu standart SAP'ye göre sorgulayın ve her değişiklik talebini onaylamadan önce fiyatlandırın. Değişiklik taleplerini ay sonunda değil, haftalık olarak gözden geçirin.

RISE with SAP bütçe aşımı riskini azaltır mı?

Tek başına azaltmaz. RISE, çekirdeğin hâlâ değiştirilebildiği Private Edition üzerinde çalışır; bu yüzden Explore aşaması riski on-premise ile aynıdır. Public Edition üzerindeki GROW with SAP, genişletmeleri yayımlanmış arayüzlerle sınırlar ve bu da kapsamın ne kadar büyüyebileceğini daraltır.

RISE with SAP uygulama maliyetleri aktifleştirilebilir mi?

Kısmen, ve bu muhasebe çerçevenize bağlıdır. Aboneliğin kendisi normalde gider yazılır. UFRS'ye göre bir SaaS düzenlemesindeki konfigürasyon ve özelleştirme hizmetleri de, kontrol ettiğiniz ayrı bir varlık oluşturmadıkça çoğunlukla gider yazılır; US GAAP'e (ASU 2018-15) göre ise uygulama maliyetleri aktifleştirilir ve barındırma süresi boyunca itfa edilir.