SAP proje kapsamı şablonu: neyi tanımlamalı, neyi dışarıda bırakmalı

Bir SAP proje kapsamı şablonu, programın neyi teslim edeceğini, bilerek neyi teslim etmeyeceğini, her parçanın sahibinin kim olduğunu ve kapsamın nasıl değişebileceğini tanımlar. Aşağıdaki dokuz bölüm bunların hepsini karşılıyor. En önemli iki bölüm, ekiplerin atladığı iki bölüm: açık hariç tutmalar ve veri taşıma kapsamı. Şablonu konfigürasyon başlamadan önce doldurun ve sponsor ile süreç sahiplerine imzalatın.

Bazen ekipler kapsam şablonunu doldurur ve yola devam eder. Bu kısım kolay gelir. Haftalar sonra, tasarım ya da yapılandırma sırasında biri “kapsamda olduğu varsayılan” bir süreci fark eder. Konuşma gerginleşir. Kimse yazmamıştır. Kimse bilerek dışarıda bırakmamıştır. Bunu çok sık gördüm. Başlangıçta denetlenmemiş birkaç varsayım, projeyi sessizce haftalarca rotasından saptırır.

Kapsam belgesinin görevi, odada söylenenleri kaydetmek değildir. Konfigürasyon, geri alınması pahalı varsayımları kilitlemeden önce netliği zorunlu kılmaktır.

Dokuz bölüm şunlar, her birinin neye yanıt vermesi gerektiğiyle birlikte.

1. Hedefler

Bu iş neden yapılıyor ve bittiğinde iş birimi ne görecek? Her hedefi ölçülebilir bir sonuca bağlayın: ay sonu kapanışını üç gün kısaltmak, üç şirket arasındaki elle mutabakatları ortadan kaldırmak, tüm tesislerde stokta tek bir görünüm. Muğlak hedefler muğlak başarı kriterleri üretir ve anlaşmazlık kullanıcı kabul testinde (UAT) ortaya çıkar.

2. Kapsam tanımı

Modüller, tüzel kişilikler, tesisler, ülkeler, diller, entegrasyonlar ve dağıtım modeli. Somut olun. “Finans” bir kapsam değildir. “BAE tüzel kişiliği için S/4HANA Cloud Private Edition üzerinde ticari borçları, ticari alacakları, defteri kebiri ve masraf yeri muhasebesini kapsayan Finansal Muhasebe ve Kontrol (FI/CO)” bir kapsamdır.

3. Hariç tutulanlar

Çoğu kapsam şablonu burada başarısız olur. Bir şey hariç diye yazılmamışsa, biri onu dahil sayacaktır. İsmen yazılması gereken hariç tutmalar:

1. Sonraki aşamaya bırakılan ülkeler ya da tüzel kişilikler.
2. Şimdilik olduğu gibi bırakılan eski (legacy) entegrasyonlar.
3. Tanımlı bir kesim tarihinden önceki geçmiş veriler.
4. Canlıya geçiş sonrası iyileştirme listesine kaydırılan raporlar.
5. Hukuki teyit beklenirken ertelenen mevzuat gereksinimleri.

Her hariç tutmaya, varsa, kaydırıldığı aşamayı yazın. İmzalı bir hariç tutma, iki haftalık tartışmayı kısa bir konuşmaya çevirir.

4. Veri taşıma kapsamı

Sürekli rastlanan bir kör nokta. Üç soruyu yazılı olarak yanıtlayın:

1. Ne taşınıyor? Yalnızca açık kalemler mi, geçmiş de mi? Tüm müşteriler ve satıcılar mı, yoksa aktif olanlar mı? Her tesisin malzemeleri mi, yoksa yalnızca canlıya geçen tüzel kişilikler mi?
2. Kesim kuralları neler? Açık satın alma, satış ve iş emirleri için geçerlilik tarihi ve cutover anında süren kalemlere ne olacağı.
3. Bunun yerine ne arşivleniyor? Geçmiş veriler için yasal saklama kuralları ve eski sistemin ne kadar süre okunabilir kalacağı.

Burada belgelenmemiş varsayımlar, yapılandırma sırasında anlaşmazlığa dönüşür. SAP veri taşıma projelerinin neden başarısız olduğunu anlattığım yazım planlamayı ayrıntılı ele alıyor.

5. İşlevsel olmayan kapsam

Bunlar planlama aşamasında unutulur ve testin sonlarında engel olarak karşınıza çıkar. Kapsama alın:

1. Kullanılabilirlik ve bakım penceresi. RISE kapsamında sözleşmenizdeki kullanılabilirlik koşullarına atıf yapın.
2. Ay sonu kapanışı gibi yoğun yükte performans.
3. Denetim kaydı: hangi işlemler ve kayıtlar ne kadar süre saklanacak.
4. Role göre güvenlik ve erişim kontrolü.
5. Raporlama gecikmesi: gerçek zamanlı, gerçek zamana yakın ya da günlük.

Bunlar özellik değil. Sistemin karşılaması gereken kısıtlar. Kapsamda yoksa kimse bunlara göre tasarım yapmaz.

6. Roller ve sorumluluklar

Her iş kolunun bir danışman lideri ve karar yetkisi olan bir iş tarafı muhatabı olmalı, ikisi de isimle belirlenmiş. En sık gördüğüm boşluk UAT sahipliği: bir sürecin test edildiğini ve kabul edildiğini kim imzalayabilir? Bunu yapılandırma başlamadan önce kararlaştırın, canlıya geçişten iki hafta önce değil.

7. Değişiklik kontrolü

“Değişiklikler resmi onay gerektirir” demek yetmez. Belirli bir süreç gerekir: neyin değişiklik talebini tetiklediği, zaman ve bütçe üzerindeki etkiyi kimin değerlendirdiği, kimin onayladığı ve neyin kaydedildiği. Bu olmadan “şunu da ekleyebilir miyiz?” sorusu “bunun dahil olduğunu düşünmüştük” cümlesine, ardından da kimsenin planlamadığı üç haftalık bir uzatmaya dönüşür.

8. Genişletme kuralları

Özel geliştirmenin nasıl onaylanacağı. SAP artık genişletmeleri A seviyesinden (yalnızca yayımlanmış API'ler) D seviyesine (çekirdekte değişiklik) kadar sınıflandırıyor (SAP News, Ağustos 2025). GROW kapsamındaki Public Edition'da sistem yalnızca yayımlanmış arayüzlere izin verir. RISE kapsamındaki Private Edition'da ve on-premise'de çekirdek hâlâ değiştirilebilir. Bu yüzden kapsam, hedef seviyeyi ve istisnaları kimin onayladığını belirtmeli. Clean core rehberim seviyeleri açıklıyor.

9. Varsayımlar ve kısıtlar

Kapsamın dayandığı varsayımları listeleyin ki birinin bunları kontrol etmesi gereksin. Sonra kısıtları yazın: canlıya geçiş tarihini sabitleyen mevzuat son tarihleri, bütçe tavanları, yalnızca yarı zamanlı çalışan kişiler ve eski sistemlerin kapatılma tarihleri.

Özelleştirme, ortaya çıkması en uzun süren kapsam kayması biçimidir. Onaylanan bir özel rapor beşe çıkar. Bir iş akışı istisnası, sonrasındaki her talebin emsali olur.

Hiçbir şeyi onaylamadan önce her talebi sınıflandırın:

Kategori	Test	Ne yapmalı
Kritik	Süreç, bu olmadan hukuken ya da operasyonel olarak işleyemez	Onaylayın, yükseltmeye dayanıklı en ucuz genişletmeyle
Önemli, ama kritik değil	Verimliliği artırır ama engelleyici değildir	Yalnızca net bir maliyet-fayda gerekçesiyle onaylayın
Gereksiz	Bir tercih ya da eski sistemin işleyişinin kopyası	İtiraz edin, ardından reddedin ya da erteleyin

Gereksiz özelleştirmelerin çoğu, SAP süreci destekleyemediği için değil, birileri çalışma biçimini değiştirmek istemediği için var. Üstelik geliştirme maliyeti yalnızca başlangıç. Her özel nesne, var olduğu sürece test, eğitim, dokümantasyon ve yükseltme işi ekler.

Bir değişiklik dondurma tarihi belirleyin. Bir tarih seçin, genellikle canlıya geçişten dört ila altı hafta önce. Bu tarihten sonra o sürüm için yeni talep kabul edilmez. Sonrasındaki her şey canlıya geçiş sonrası listesine gider. Dondurmanın arkasında yönlendirme komitesinin imzası olmalı. Yalnızca proje yöneticisinin duyurduğu bir tarih, bir bölüm başkanı ilk kez zorladığında çiğnenir.

1. 01Talep açıldıNeyin değişiklik sayıldığı baştan tanımlanır
2. 02SınıflandırıldıKritik, önemli ya da gereksiz
3. 03Etki değerlendirildiZaman ve bütçe, adı belli bir değerlendirici tarafından
4. 04KararAdı belli bir onaylayıcı onaylar, reddeder ya da erteler
5. 05Kapsam sürümlendiYeni sürüm numarası ve nelerin değiştiğinin listesi

Değişiklik dondurmadan sonra yeni talepler canlıya geçiş sonrası listesine gider

Kapsam konuşmalarının en çok kızıştığı yer analitiktir. Herkes rapor ister, kimse kaç tane olduğunu söylemez.

Tasarım sırasında sabit bir rapor listesinde anlaşın. İnsanlara ihtiyaç duyduklarını sorun, isteyebileceklerini değil. Her raporu standart SAP çıktısı ya da özel geliştirme olarak işaretleyin ve listeyi kapsamın geri kalanıyla birlikte imzalatın. Standart raporlar, özel olanların maliyetinin çok küçük bir kısmına mal olur. Aynı anda her raporun veri kaynaklarını belirleyin: üç sistemden veri çeken bir rapor, aslında bir entegrasyon gereksinimidir. Panolar ve planlama kapsamdaysa, SAP Analytics Cloud rehberim önce nelerin netleştirilmesi gerektiğini anlatıyor.

Hata	Neye yol açar	Nasıl önlenir
Hedefler ölçülebilir değil	“Çalışıyor”un ne demek olduğu üzerine UAT anlaşmazlıkları	Başlangıçta ölçülebilir sonuçlar belirleyin
Hariç tutulanlar yazılmamış	Onaysız içeri alınan iş	Kapsam dışı olanları isimle listeleyin
Veri taşıma kapsamı belirsiz	Yanlış hacimler, kayan cutover, yeniden çalışma	Neyin taşınacağını, kesim tarihlerini ve arşivlemeyi tanımlayın
İşlevsel olmayan gereksinimler eksik	Canlıya geçişte denetim ve performans sorunları	Kullanılabilirlik, performans, kayıt tutma ve güvenliği kapsama alın
UAT sahipleri belli değil	Test uzar, kimse imzalayamaz	Yetkisi olan kişileri isimle belirleyin
Değişiklik kontrolü yok	Gayriresmî eklemeler, sıkışan testler	Değişiklik sürecini kapsama yazın
İmza yok	Kapsam sonradan, hesap verebilirlik olmadan sorgulanır	Sponsor ve süreç sahipleri imzalar
Analitik sonraya bırakılmış	Canlıya geçişten iki hafta önce rapor talepleri	Rapor listesini tasarım sırasında kararlaştırın
Dağıtım modeli ya da genişletme kuralları açık	Tartışma yapılandırma aşamasına sarkar	Kapsam imzalanmadan önce ikisine de karar verin

Kapsamı her SAP Activate aşama kapısında ve onaylanan her değişiklikten sonra, bir sürüm numarası ve nelerin değiştiğinin listesiyle gözden geçirin. Kapsam, proje başlatma belgesine atıfla bağlı olmalı ki iki belge de aynı hikâyeyi anlatsın.

Bir SAP proje kapsamı şablonunda neler olmalı?

Dokuz bölüm: ölçülebilir sonuçlarla hedefler, kapsam tanımı (modüller, tüzel kişilikler, ülkeler, entegrasyonlar, dağıtım modeli), açık hariç tutmalar, veri taşıma kapsamı, işlevsel olmayan gereksinimler, adı belli roller, değişiklik kontrolü, genişletme kuralları ve kısıtlarla birlikte varsayımlar. En sık eksik olan bölüm hariç tutmalardır.

SAP projelerinde kapsam kayması nasıl önlenir?

Hariç tutulanları açıkça yazın, her değişikliği etki değerlendirmesi ve adı belli bir onaylayıcıyla resmi bir talepten geçirin, özelleştirmeleri onaylamadan önce sınıflandırın ve canlıya geçişten dört ila altı hafta önce imzalı bir değişiklik dondurma tarihi belirleyin. Amaç her değişikliği reddetmek değil. Değişikliği görünür, değerlendirilmiş ve yetkilendirilmiş kılmak.

Bir SAP projesinde veri taşıma kapsamı nedir?

Hangi verinin SAP'ye hangi kurallarla taşınacağının tanımı: hangi nesneler (müşteriler, satıcılar, malzemeler, açık siparişler, geçmiş), kesim tarihleri ve taşımak yerine nelerin arşivleneceği. Eforu ve takvimi belirler, ayrıca eski sistemlerin ne kadar süre erişilebilir kalması gerektiğine karar verir.

SAP projelerinde işlevsel olmayan kapsam nedir?

Sistemin desteklediği süreçlerin aksine, karşılaması gereken kısıtlar: kullanılabilirlik, yoğun yükte performans, denetim kaydı, güvenlik ve erişim kontrolü ile raporlama gecikmesi. Çoğu zaman kapsam dışı bırakılır, sonra testte fark edilir. Düzenlemeye tabi sektörlerde denetim kaydı yasal bir yükümlülüktür.

Özelleştirmeler kapsamda nasıl ele alınmalı?

Her talebi kritik, önemli ya da gereksiz olarak sınıflandırın. Onaylanan her biri için gereksinimi, standart SAP'nin bunu neden karşılamadığını, eforu, test etkisini, bakım maliyetini ve genişletme yaklaşımını kaydedin. Private Edition'da ve on-premise'de hedef clean core seviyesini ve istisnaları kimin onayladığını belirtin.

SAP proje kapsamı ne zaman gözden geçirilmeli?

Her SAP Activate aşama kapısında, onaylanan her değişiklik talebinden sonra ve bütçe, kaynak ya da takvim değiştiğinde. Her sürümü tarih, sürüm numarası ve nelerin değiştiğinin özetiyle saklayın. Bu geçmiş, kapsam sonradan sorgulandığında ekibi korur.