SAP uygulaması için proje başlatma belgesi nasıl hazırlanır

SAP uygulaması proje başlatma belgesi, programı resmen yetkilendiren kısa bir belgedir. Programın neyi teslim edeceğini, neyi etmeyeceğini, kimin karar vereceğini, başarının nasıl ölçüleceğini ve bunun ne zamana kadar olacağını yazılı olarak netleştirir. Satıcı iş tanımı belgeleri imzalanmadan önce yazın, sahipliğini müşteri sponsoruna verin ve bir tartışmayı bitirecek kadar somut tutun. Bölüm bölüm bir taslak aşağıda.

Ekipler SAP kick-off toplantılarına özgüvenle girer. Sonra rollerin belirsiz tanımlandığını, kapsam sınırları üzerinde hiç anlaşılmadığını ve başarının neye benzediğini kimsenin söyleyemediğini görür. Başlatma belgesi bunu önlemelidir. Çoğu önlemez, çünkü işi sabitlemek için değil, bir yönetişim gereksinimini karşılamak için yazılır.

Temiz görünen ama gerçek planlara bağlanmayan başlatma belgeleri gördüm. İşe yarayan sürüm, taslak aşamasında insanların tartıştığı sürümdür. Dürüst olduğunu böyle anlarsınız.

Her büyük SAP programında üç belge birbirine karışır. Hepsi farklı bir iş görür.

Belge	Amaç	Hazırlayan	Zamanlama
Proje teklifi	Projenin neden yapılması gerektiğini gerekçelendirir	İş sponsoru	Onaydan önce
Proje başlatma belgesi	Projeyi yetkilendirir; kapsamı, hedefleri, adı belli sahipleri ve yönetişimi belirler	Sponsor, program yöneticisiyle birlikte	Başlatma aşamasında
Proje planı	İşin nasıl yapılacağını tanımlar: görevler, kaynaklar, bağımlılıklar	Program yöneticisi	Başlatma belgesi onaylandıktan sonra

Başlatma belgesi yönetişim belgesidir. Çizgileri o çizer. S/4HANA programınız birkaç modüle, ülkeye ve satıcıya yayılıyorsa, insanlar kendi varsayımlarını yapmaya başlamadan önce nelerin dahil olduğuna karar verdiğiniz yer başlatma belgesidir.

Bir iş sonucuna bağlı hedefler

“Sistem modernizasyonu” değil. Her hedefin bir sayısı olmalı. Test şu: vizyonu bir yönetim kurulu üyesine slayt kullanmadan 30 saniyede anlatabiliyor musunuz?

Herkesin canlıya geçişi kutladığı, iki ay sonra ise kimsenin vaat edilen değerin sağlanıp sağlanmadığını söyleyemediği SAP programlarında çalıştım. Bir üretim müşterisi 4 milyon doların üzerinde harcadı ve hiçbir getiri gösteremedi. CFO metrik istedi. Kimsede yoktu ve bu, bir sonraki fonlama turunu geciktirdi.

Bunu, desteklediğim bir perakende müşterisiyle karşılaştırın. Başlatma belgesinde ilk günden tanımlı KPI'lar vardı. Sipariş işleme maliyetlerinde yüzde 32'lik bir düşüş gösterdiler ve ikinci faz hemen onaylandı.

Açık dışlamalarla kapsam

Bu, en çok gözden kaçan bölümdür. Ekipler ayrıntılı kapsam içi listeleri yazar, dışlamaları dışarıda bırakır; tartışmaların çıktığı yer de tam olarak orasıdır.

SAP devreye alımını bu şekilde odakta tutan bir sağlık hizmetleri şirketiyle çalıştım. Pazarlama başkanı, kullanıcı kabul testi (UAT) sırasında kampanya takibi için analitik eklemek istedi. Başlatma belgesinde buna yer yoktu ve yönlendirme komitesi bunu hemen işaretledi. Bu tek karar 850.000 dolar tasarruf sağladı ve altı haftalık bir gecikmeyi önledi.

Departmanlar değil, adı belli kişiler

“Finans ekibi: raporlamaya girdi sağlar” ifadesi kimseyi sorumlu kılmaz. “Finans lideri, [isim]: raporlama gereksinimlerini tanımlar, FI/CO konfigürasyonunu onaylar, veri taşıma hazırlığına onay verir” ifadesi kılar.

Taahhüt olarak kilometre taşları

Bir perakende müşterisi canlıya geçişini dört ay erteledi. İlk gecikme, gereksinim toplamada yaşanan ve kimsenin takvime eklemediği üç haftalık bir kaymaydı. Bunu sonraki aşamalarda telafi edebileceklerini varsaydılar. Bunun yerine 1,8 milyon dolar aşım harcadılar.

Tersi de geçerli. Bir üretim projesinde ekip yayımlanmış plana bağlı kaldı. Veri taşıma ekibi bir gecikmeyi bildirdiğinde, yönlendirme komitesi personel desteğini hemen onayladı; çünkü başlatma belgesi kilometre taşını görünür kılmıştı. Bu karar hem zamandan hem de 600.000 dolardan tasarruf sağladı.

Bütçe, riskler ve bağımlılıklar

Üst düzey bir bütçe, programı raydan çıkarabilecek üç dört risk ve aynı insanlar ile aynı paraya talip olan diğer programlar. Bir perakende müşterisi hiç canlıya geçmeyen bir uygulamaya 3,2 milyon dolar harcadı. Finans yeniden tasarımı ile SAP projesi aynı kaynaklar ve aynı bütçe penceresiyle paralel yürüdü; iki başlatma belgesinden hiçbiri diğerinden söz etmiyordu. Yönetim bunu çok geç fark etti.

Başlangıç noktası olarak kullanacağım yapı bu. Her bölüm bir sayfaya ya da daha azına sığmalı.

1. Amaç ve arka plan: neden şimdi, neyin bozuk olduğu, hiçbir şey yapmazsanız ne olacağı.
2. Hedefler ve başarı ölçütleri: her hedef için bir başlangıç değeri, bir hedef değer ve bir tarih.
3. Kapsam: kapsama giren modüller, süreçler, tüzel kişilikler, ülkeler, lokasyonlar, entegrasyonlar ve veriler.
4. Kapsam dışı: kapsam kadar özenle yazılır; dışarıda bırakılan her kalemin ertelendiği faz belirtilir.
5. Dağıtım modeli ve uzantı kuralları: S/4HANA Cloud Public Edition, RISE kapsamında Private Edition ya da on-premise ve özel geliştirmenin nasıl onaylanacağı.
6. Yönetişim: sponsor, yönlendirme komitesi, tasarım otoritesi, değişiklik kontrolü, eskalasyon yolu; hepsi adı belli kişilerle.
7. Roller ve sorumluluklar: her süreç alanı, veri, test, değişiklik ve cutover için adı belli kişiler.
8. Kilometre taşları: tarihleri ve geçiş kriterleriyle faz kapıları. Kalite kapıları rehberimde örnekler var.
9. Bütçe ve ihtiyat payı: toplam zarf, ihtiyat payı ve onu kimin serbest bırakabileceği.
10. Riskler, varsayımlar ve bağımlılıklar: paralel programlar ve mevzuat son tarihleri dahil.
11. Uyumluluk gereksinimleri: örneğin ABD sağlık sektöründe HIPAA, ilaç sektöründe GxP, ABD'de borsaya kote şirketler için SOX.
12. Onay: sponsor ve iş liderleri, sürüm numarası ve tarihle.

1. 01İşi bilen insanlara sorunSponsorlar, iş liderleri ve son kullanıcılar
2. 02Olmazsa olmazı, olsa iyi olandan ayırınCanlıya geçiş, faz 2 ya da bu projede değil
3. 03Bir şablonla başlayınSonra entegrasyon, veri ve uyumluluğu ekleyin
4. 04Tartışmaları bitirecek kadar somut olunHer hedefin karşılandığını kanıtlayabilir misiniz?
5. 05Gerçek onay alınBölüm bölüm okunmuş, sorgulanmış ve kabul edilmiş

Üçüncü ayda kapsam tartışıldığında işaret edebileceğiniz bir başlatma belgesi

1. İşi bilen insanlara sorun

Bir şey yazmadan önce sponsorlar, iş liderleri ve son kullanıcılarla oturun. Neyin bozuk olduğunu ve daha önce nelerin denendiğini sorun. Bir keresinde, üretim sahasının neye ihtiyacı olduğunu bildiğini varsaydığı için bir SAP uygulamasına 1,8 milyon dolar boşa harcayan bir üretim müşterisiyle çalıştım. Altı ay sonra gerçek iş akışı sorunlarının ele alınmadığını fark etti.

Üzerinde çalıştığım bir finans dönüşümünde BT, verimlilik sorunlarını çözmek için SAP'yi devreye almayı planlıyordu. Finansla yapılan görüşmeler asıl sorunun düşük veri kalitesi olduğunu gösterdi. Sormasaydık, yanlış sorunu düzeltmek için milyonlar harcayacaktık.

2. Kapsamı yazmadan önce olmazsa olmazı, olsa iyi olandan ayırın

Her girdiyi şu üç sınıftan birine koyun: canlıya geçiş için gerekli, faz 2 ya da bu projede değil. Profesyonel hizmetler alanındaki bir müşterim, gereksinimler üç farklı yerde durduğu ve projenin aylar sonrasında sürekli “yeniden keşfedildiği” için bütçeyi yüzde 40 aştı. Kapsam şablonu rehberim bu adımda yardımcı olur.

3. Bir şablonla başlayın, sonra SAP'ye özgü konuları ekleyin

Genel bir şablon, SAP programlarını pahalı kılan şeyleri kaçırır: entegrasyon noktaları, veri taşıma ve veri temizliğinin sahipliği, modül varsayımları, uyumluluk gereksinimleri ve özel geliştirme kuralları. Veri temizliğinden hiç söz etmeyen genel bir başlatma belgesiyle başlayan bir SAP projesini duydum. Altı ay sonra eski verilerin darmadağın olduğu ortaya çıktı; bu da 750.000 dolar ve üç ay ekledi.

4. Tartışmaları bitirecek kadar somut olun

Başlatma belgesinde “envanter yönetimini modernize edin” yazan, Singapur'daki bir perakende müşterisi için uygulamayı ben yürüttüm. Ekibin yarısı bunun daha hızlı işlem anlamına geldiğini düşündü. Diğer yarısı tahmine odaklandı. Sonuç: 1,8 milyon dolar harcandı ve başarının neye benzediği konusunda hiçbir uzlaşma yoktu. Her hedef için sorun: bunun tamamlandığını kanıtlayabilir miyim?

5. Gerçek onay alın

Belge, onu imzalayan insanlar okuyup sorguladıklarında ve taahhütlerini kabul ettiklerinde tamamdır. Sponsoru ve iş liderlerini bölüm bölüm gezdirin. Perakende müşterilerinin başlatma belgesi üzerinde uzlaşmak için tam üç gün harcadığını gördüm. Bu, sonrasında aylarca süren tartışmalardan ve kapsam değişikliklerinden kurtardı.

Hata	Neye yol açar	Bunun yerine ne yapmalı
Belirsiz hedefler (“verimliliği artırın”)	Ekipler farklı yönlere çeker	Her hedefe bir sayı koyun
Dışlama yok	Kapsam sessizce büyür	Kapsam dışı listesini kapsam kadar özenle yazın
Sahipler yalnızca unvan ya da departmanla adlandırılmış	Kararlar ertelenir	Kişilerin adını yazın
Başarı ölçütü yok	Canlıya geçiş kutlanır, değer hiç gösterilmez	KPI'ları kick-off'tan önce tanımlayın
Paralel programlar haritalanmamış	Kaynak ve bütçe çakışmaları	Bağımlılıkları her iki başlatma belgesine de kaydedin
Başlatma belgesini uygulama ortağı yazmış	Kapsam, ortağın teslim etmek istediğini yansıtır	Sahibi müşteri olsun; ortak ayrıntıyı katkı olarak versin

Son noktada kararlıyım. Uygulama ortağınız başlatma belgenizi yazmamalı. Onun teşviki projeyi başlatmak. Sizinki projeyi kapsamlandırmak.

RISE with SAP'de (Private Edition), yönetişim bölümüne iki şey ekleyin. Birincisi, bir clean core onay forumu. SAP artık uzantıları A düzeyinden (yalnızca yayımlanmış API'ler) D düzeyine (değişiklikler) kadar sınıflandırıyor (SAP News, Ağustos 2025). Private Edition çekirdeği değiştirmenize hâlâ izin verir; dolayısıyla teknik borcun birikmesini engelleyen şey bu forumdur. İkincisi, SAP'ye giden bir eskalasyon yolu. RISE kapsamında altyapıyı ve teknik operasyonları SAP yürütür. CIO'nun, yalnızca ortakta değil, platform düzeyinde bir şey bozulduğunda SAP'de kimi arayacağını bilmesi gerekir.

GROW with SAP'de (Public Edition), başlatma belgesi küçülür. Uzantılar yayımlanmış arayüzlerle sınırlıdır; yani platform clean core'u sizin yerinize uygular ve entegrasyon seçenekleri daha dardır. Vizyon, başarı ölçütleri, adı belli sahipler ve dışlamalar yine de aynı derecede önemlidir.

Yapay zeka araçları görüşme notlarını daha hızlı bir ilk taslağa dönüştürebilir. Başlatma belgesinin siyasi işini yapamazlar; yani sponsorları neye sahip olduklarında anlaştırmayı.

SAP uygulamasında proje başlatma belgesi nedir?

SAP programını resmen yetkilendiren belge. Kapsamı ve dışarıda kalanları belirler, sponsoru ve sorumlu kişileri adlandırır, başarı ölçütlerini tanımlar, kilometre taşlarını ve yönetişimi belirler ve başlıca riskleri listeler. Yararlı bir başlatma belgesi, kapsam ya da sahiplik konusundaki bir anlaşmazlığı çözecek kadar somuttur.

Bir SAP proje başlatma belgesi neleri içermelidir?

Amaç, ölçülebilir hedefler, kapsam, açık dışlamalar, dağıtım modeli ve uzantı kuralları, adı belli kişilerle yönetişim, roller, geçiş kriterleriyle kilometre taşları, bütçe ve ihtiyat payı, riskler ve bağımlılıklar, uyumluluk gereksinimleri ve onay. Yukarıdaki taslak her bölümü gösteriyor.

Proje başlatma belgesi ile proje planı arasındaki fark nedir?

Başlatma belgesi yetkilendirir ve tanımlar: kapsam, sponsor, yönetişim ve üst düzey kilometre taşları. Plan uygular: görevler, bağımlılıklar, kaynaklar ve sıralama. Başlatma belgesi olmayan bir plan savrulur, çünkü kapsam üzerinde hiç anlaşılmamıştır. Planın her taahhüdü başlatma belgesine kadar izlenebilmelidir.

SAP proje başlatma belgesini kim yazmalı?

Sahibi müşteri sponsorudur, taslağı program yöneticisi hazırlar; ayrıntıyı finans, BT ve operasyon liderleri sağlar. Uygulama ortağının yazmasına izin vermemenizi öneririm. Onun teşviki projeyi başlatmaktır, sizi ihtiyacınız olmayan kapsamdan korumak değil.

RISE with SAP proje başlatma belgesini nasıl değiştirir?

Hangi uzantılara hangi düzeyde izin verileceğine karar veren bir clean core onay forumu ekleyin. Platform sorunları için SAP'ye giden bir eskalasyon yolu da ekleyin, çünkü RISE kapsamında altyapıyı SAP yürütür. GROW with SAP'de başlatma belgesi daha hafiftir, çünkü Public Edition clean core'u teknik olarak zorunlu kılar.

Proje başlatma belgesi uygulama sırasında değişebilir mi?

Evet, değişiklik kontrolü yoluyla. Başlatma belgesini bir referans çizgisi olarak ele alın. Kapsam, sponsor, bütçe ya da önemli bir kilometre taşı değiştiğinde; sürüm numarası, neyin neden değiştiğine dair bir not ve yeni bir onayla güncelleyin. Proje savrulduğunda sessizce yeniden düzenlenmesine izin vermeyin.