ERP’de Kapsam Sismesi (Scope Creep) Nasil Engellenir? (2026)

Scope Creep Nedir?

Her toplantıda masaya yeni bir “küçük istek” gelir; asıl tehlike de tam olarak buradadır

Scope creep, yani kapsam şişmesi, bir projenin başında çizilmiş sınırların kimse fark etmeden dışına taşmasıdır. Bu büyüme genellikle resmi bir değişiklik sürecinden geçmez; “küçük bir istek” ya da “hızlıca ekleyiverelim” kılığında sızar.

ERP projelerinde bu durum ayrı bir tehlike taşır. Nedeni şu:

• Karmaşıklık çarpanı: ERP sistemleri birbirine bağlı modüllerden oluşur. Bir modüle eklediğiniz özellik, çoğu zaman ummadığınız başka bir modülü de etkiler.
• Çok paydaşlı yapı: Finans, üretim, satış, İK, IT… her departmanın kendi önceliği, kendi acil işi vardır.
• Uzun proje süresi: 6-18 ay süren bir projede iş gereksinimleri zaten kendiliğinden değişir.
• Yüksek beklenti: “ERP her şeyi çözer” algısı, sınır tanımayan taleplerin kapısını aralar.

Scope Creep Neden Oluşur?

Kapsam şişmesinin en büyük tetikleyicisi çoğu zaman yetersiz analizdir

Scope creep’in tohumları çoğunlukla proje daha başlamadan atılır. En sık karşılaştığım nedenler şunlar:

1. Yetersiz Gereksinim Analizi

Başta yeterince derine inilmezse, geliştirme aşamasında “aslında biz bunu da istiyorduk” cümleleri peş peşe gelmeye başlar. Analiz aşamasını kısa kesmek kısa vadede zaman kazandırır gibi görünür, uzun vadede daha pahalıya patlar.

2. Belirsiz Kapsam Dokümanı

Kapsam dokümanı (Scope Statement / SOW) muğlak ifadelerle doluysa, herkes kendi anladığını okur. “Raporlama modülü” yazmak hiçbir şey söylemez; hangi raporlar, hangi filtreler, hangi formatlar açıkça yazılmalıdır.

3. Zayıf Değişiklik Yönetimi

Ortada işleyen bir değişiklik talep süreci (Change Request Process) yoksa ya da kâğıt üstünde kalıyorsa, her istek doğrudan geliştirme ekibinin kucağına düşer.

4. Paydaş Baskısı

Üst yönetimden ya da güçlü bir departman müdüründen gelen “acil” istekler normal süreci es geçer. Klasik “CEO istedi, hemen yapılacak” sendromu.

5. Gold Plating

Proje ekibinin, kimse istemeden “bonus” özellikler eklemesi. “Şu dashboard’u da yapalım, çok hoşlarına gider” yaklaşımı kapsamı sessiz sedasız büyütür.

6. İteratif Süreçlerde Disiplin Eksikliği

Agile/Scrum tarafında her sprint’e yeni hikaye eklemek doğal karşılanır. Ama product backlog disiplini yoksa bu doğallık, kısa sürede kontrolden çıkmış bir büyümeye döner.

Erken Uyarı İşaretleri

Scope creep’i erken yakalarsanız müdahale şansınız çok daha yüksek olur. Şu işaretlere dikkat edin:

Proje Seviyesinde

• Sprint veya faz tamamlanma oranlarında düşüş
• Tahmin edilen efor ile gerçekleşen efor arasında giderek açılan makas
• Sürekli ertelenen teslim tarihleri
• Toplantı sayısının ve süresinin artması
• “Bunu da ekleyelim” ile başlayan cümleler

Ekip Seviyesinde

• Geliştiricilerin “hangi versiyon geçerli?” diye sorması
• Test senaryolarının bir türlü sabitlenememesi, sürekli güncellenmesi
• Belgelerin sahadaki gerçekle uyuşmaması
• Ekip motivasyonunda düşüş, tükenmişlik belirtileri

Paydaş Seviyesinde

• Farklı paydaşlardan gelen çelişen istekler
• Önceliklerin sürekli değişmesi
• “Demo’da gördüğümüz X özelliğini de istiyoruz” talepleri
• Steering Committee toplantılarında yükselen gerginlik

Adım Adım Önleme Stratejileri

Kapsam kontrolü proje başlamadan, daha planlama masasında başlar

Scope creep’i önlemenin sihirli tek bir kuralı yok; sistematik bir yaklaşım gerekiyor. Adım adım gidelim:

Adım 1: Sağlam Kapsam Dokümanı Oluşturun

Proje başlangıcında detaylı bir kapsam dokümanı (Scope Statement) hazırlayın. İçinde şunlar mutlaka olsun:

• Dahil olanlar: Projede yer alacak modüller, özellikler, entegrasyonlar
• Hariç olanlar: Açıkça kapsam dışında bıraktığınız maddeler
• Varsayımlar: Projenin dayandığı varsayımlar
• Kısıtlar: Bütçe, zaman, kaynak sınırları
• Kabul kriterleri: Başarı nasıl ölçülecek?

Adım 2: Değişiklik Talep Süreci Tanımlayın

Her değişiklik isteği için resmi bir süreç kurun:

1. Talep formu: Kim, ne, neden istiyor?
2. Etki analizi: Bütçe, takvim, kaynak ve risk etkileri
3. Onay mekanizması: Kim onaylıyor? (Örneğin belirli bir eşiğin üstünde Steering Committee)
4. Dokümantasyon: Onaylanan değişiklik kapsam dokümanına işlenir
5. İletişim: Tüm paydaşlara bildirim yapılır

Adım 3: Kapsam İzlenebilirlik Matrisi (RTM) Kullanın

Requirements Traceability Matrix (RTM), her gereksinimin kaynağını, durumunu ve ilişkili işleri tek yerde takip etmenizi sağlar. Bu sayede şu soruların yanıtı hep elinizin altında olur:

• Hangi gereksinim hangi paydaştan geldi?
• Gereksinim onaylandı mı, geliştirildi mi, test edildi mi?
• Yeni eklenen maddelerin etkisi ne oldu?

Adım 4: Düzenli Kapsam İnceleme Toplantıları

Haftalık ya da iki haftalık kapsam inceleme toplantıları düzenleyin. Bu toplantılarda:

• Yeni gelen talepler gözden geçirilir
• Mevcut kapsamla karşılaştırılır
• Önceliklendirme yapılır (MoSCoW: Must, Should, Could, Won’t)
• Alınan kararlar kayıt altına alınır

Adım 5: “Hayır” Demek İçin Yetkilendirme

Proje yöneticisine ve ekip liderlerine kapsam dışı talepleri reddetme yetkisi verin. Bu yetkinin arkasında üst yönetim durmuyorsa, ilk baskıda çöker.

Adım 6: Faz 2 Listesi Oluşturun

Kapsama alamadığınız ama gerçekten değerli bulduğunuz istekler için bir “Faz 2” ya da “Gelecek Sürüm” listesi tutun. Bu basit alışkanlık:

• Paydaşların sesinin duyulduğunu hissetmesini sağlar
• İyi fikirlerin kaybolup gitmesini önler
• Mevcut kapsamı korur

Scope Creep Yönetiminde En Sık Yapılan 7 Hata

1. “Küçük Bir Şey” Diye Kabul Etmek

“5 dakikalık iş” diye kabul edilen bir değişiklik, testi, dokümantasyonu ve entegrasyonuyla birlikte saatlere yayılır. Hiçbir değişikliği baştan “küçük” saymayın.

2. Sözlü Anlaşmalarla Yetinmek

“Toplantıda konuştuk, herkes anladı” kesinlikle yetmez. Her karar yazıya geçmeli, imza ya da e-posta ile onaylanmalıdır.

3. Değişiklik Sürecini Bypass Etmek

Üst yönetim ya da “önemli” bir paydaş için istisna yapmak, sürecin tamamını zayıflatır. Kural herkese aynı şekilde işlemeli.

4. Etki Analizini Atlamak

Bir değişikliğin sadece geliştirme eforunu değil; test, eğitim, dokümantasyon ve destek tarafındaki etkisini de hesaba katın.

5. Gold Plating’e Göz Yummak

Ekibin “bonus” özellik eklemesine göz yummak, hem kaynağı boşa harcar hem de kullanıcının beklentisini gereksiz yere yükseltir.

6. Kapsam Baseline’i Güncellememek

Onaylanan değişiklikler kapsam dokümanına yansıtılmazsa, “orijinal kapsam” ile “güncel kapsam” arasında herkesin kafası karışır.

7. Paydaşları Karar Sürecine Dahil Etmemek

Değişiklik kararlarını yalnızca proje ekibi alırsa paydaş direnci büyür. Trade-off kararlarında iş birimlerini de masaya oturtun.

Disiplinli bir süreç, bu hataların çoğunu baştan önler

Scope Creep Önleme Kontrol Listesi

Scope Creep Başladıysa: Kurtarma Planı

Geç kaldığınızı düşünseniz bile durumu kontrol altına almak hâlâ mümkün

Proje çoktan scope creep’in etkisine girdiyse panik yapmak yerine sistematik bir kurtarma uygulayın:

Adım 1: Durumu Kabul Edin

Scope creep’i görmezden gelmek sorunu yalnızca büyütür. Mevcut durumu nesnel biçimde değerlendirin ve paydaşlarla açıkça paylaşın.

Adım 2: Kapsamı Yeniden Belgeleyin

Orijinal kapsam ile bugünkü kapsam arasındaki farkı çıkarın. Sonradan eklenen tüm maddeleri tek tek listeleyin.

Adım 3: Önceliklendirme Yapın

Her maddeyi MoSCoW yöntemiyle sınıflandırın:

• Must: Mutlaka olmalı, sistemin çalışması için zorunlu
• Should: Olması gerekir, önemli ama zorunlu değil
• Could: Olsa iyi olur, kaynak kalırsa
• Won’t: Bu fazda olmayacak, Faz 2’ye ertelendi

Adım 4: Paydaş Onayı Alın

Revize edilmiş kapsamı Steering Committee’ye götürün. Trade-off’ları hiç dolandırmadan söyleyin: “X özelliğini eklersek proje Y’de değil, Z tarihinde biter.”

Adım 5: Baseline’i Güncelleyin

Onaylanan yeni kapsamı resmi baseline olarak kaydedin. Bütçeyi ve takvimi buna göre revize edin.

Adım 6: Süreçleri Sıkılaştırın

Aynı çukura tekrar düşmemek için değişiklik yönetimi sürecinizi baştan gözden geçirip güçlendirin.

Sıkça Sorulan Sorular (SSS)