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

Scope Creep Nedir?

Her toplantıda yeni bir “küçük istek” gelebilir – asıl tehlike budur

Scope creep (kapsam şişmesi), bir projenin baslangicta tanimlanmis sınırlarinin kontrolsüz şekilde genişlemesidir. Bu genişleme, resmi bir degisiklik süreci izlenmeden, “küçük istekler” veya “hızlı eklemeler” adıyla gerçeklesir.

ERP projelerinde scope creep özellikle tehlikelidir çünkü:

• Karmaşıklik çarpanı: ERP sistemleri birbiriyle entegre modüllerden oluşur. Bir module eklenen özellik, diğer modülleri de etkiler.
• Çok paydaşh yapı: Finans, üretim, satış, IK, IT… her departmanın farklı öncelikleri vardır.
• Uzun proje süresi: 6-18 aylık projelerde, is gereksinimleri doğal olarak değişir.
• Yüksek beklenti: “ERP her şeyi çözecek” algısı, sınır tanimayan taleplere yol açar.

Scope Creep Neden Oluşur?

Yetersiz analiz, kapsam sismesinin en büyük tetikleyicisidir

Scope creep’in kokleri genellikle proje başlamadan önce ekilir. İşte en yaygın nedenler:

1. Yetersiz Gereksinim Analizi

Baslangicta yeterince derine inilmezse, geliştirme asamasında “aslında biz bunu da istiyorduk” cümleleri başlar. Analiz aşamasının kisaltilmesi, uzun vadede daha maliyetlidir.

2. Belirsiz Kapsam Dokumani

Kapsam dokumani (Scope Statement / SOW) muglak ifadeler içeriyorsa, yoruma açık kalır. “Raporlama modülü” yazmak yetmez; hangi raporlar, hangi filtreler, hangi formatlar açıkca tanımlanmalıdır.

3. Zayıf Degisiklik Yönetimi

Resmi bir degisiklik talep süreci (Change Request Process) yoksa veya uygulanmiyorsa, her istek doğrudan geliştirme ekibine ulaşır.

4. Paydaş Baskısı

Üst yönetim veya güçlü departman müdürlerinden gelen “acil” istekler, normal süreci bypass eder. “CEO istedi, hemen yapılacak” sendrromu.

5. Gold Plating

Proje ekibinin, kullanıcı istemeden “bonus” özellikler eklemesi. “Su dashboard’u da yapalım, çok hosuna gider” yaklaşimi, kapsamı sessizce büyütür.

6. Iteratif Süreçlerde Disiplin Eksikliği

Ağıle/Scrum metodolojilerinde, her sprint’e yeni hikaye eklenmesi doğal kabul edilir. Ancak product backlog disiplini olmadan bu, kontrolsüz büyümeye dönüşür.

Erken Uyarı İşaretleri

Scope creep’i erken yakalamak, müdahale şansını arttırır. Su işaretlere dikkat edin:

Proje Seviyesinde

• Sprint veya faz tamamlanma oranlarında düşüş
• Tahmin edilen efor ile gerçeklesen efor arasında büyüyen fark
• Sürekli ertelenen teslim tarihleri
• Artan toplantı sayısı ve süresi
• “Bunu da ekleyelim” ile başlayan cumleler

Ekip Seviyesinde

• Geliştiricilerin “hangi versiyon geçerli?” diye sorması
• Test senaryolarının sürekli güncellenmesi
• Belgelerin gerçekle uyuşmazlığı
• Ekip motivasyonunda düşüş, tukenmislik belirtileri

Paydaş Seviyesinde

• Farklı paydaşlardan celisen istekler
• Önceliklerin sürekli degismesi
• “Demo’da gördüğümüz X özelliğini de istiyoruz” talepleri
• Steering Committee toplantılarında gerginlik

Adım Adım Önleme Stratejileri

Kapsam kontrolü, proje başlamadan önce başlar

Scope creep’i önlemek için sistematik bir yaklaşim gerekir. İşte adım adım strateji:

Adım 1: Sağlam Kapsam Dokumani Oluşturun

Proje başlangıcında detaylı bir kapsam dokumani (Scope Statement) hazırlayın:

• Dahil olanlar: Projede yer alacak modüller, özellikler, entegrasyonlar
• Hariç olanlar: Açıkca kapsam dışında bırakılan 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: Degisiklik Talep Süreci Tanimlayin

Her degisiklik isteği için resmi bir süreç oluşturun:

1. Talep formu: Kim, ne, neden istiyor?
2. Etki analizi: Bütçe, takvim, kaynak, risk etkileri
3. Onay mekanizmesi: Kim onaylıyor? (Temsili: belirli eşik üstu Steering Committee)
4. Dokümantasyon: Onaylanan degisiklik kapsam dokümanına eklenir
5. İ̇letişim: Tüm paydaşlara bildirim

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

Requirements Traceability Matrix, her gereksinimin kaynağını, durumunu ve ilişkili çalışmaları takip eder. Bu matris sayesinde:

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

Adım 4: Düzenli Kapsam Inceleme Toplantıları

Haftalık veya iki haftalık kapsam inceleme toplantıları düzenly in:

• Yeni gelen talepler gözden geçirilir
• Mevcut kapsam ile karşılaştırılır
• Önceliklendirme yapılır (MoSCoW: Must, Should, Could, Won’t)
• Kararlar kayıt altına alinir

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

Proje yöneticisine ve ekip liderlerine kapsam disi talepleri reddetme yetkisi verin. Bu yetki, üst yönetim tarafından desteklenmelidir.

Adım 6: Faz 2 Listesi Oluşturun

Kapsama alınmayan ancak değerli gorulen istekler için “Faz 2” veya “Gelecek Sürüm” listesi tutun. Bu yaklaşim:

• Paydaşların sesini duyulmus hissetmesini sağlar
• Iyi fikirlerin kaybolmasını önler
• Mevcut kapsamı korur

Scope Creep Yönetiminde En Sik Yapılan 7 Hata

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

“5 dakikalık is” diye kabul edilen değişiklikler, test, dokümantasyon ve entegrasyon ile saatlere dönüşür. Hiçbir degisiklik “küçük” kabul edilmemelidir.

2. Sözlü Anlaşmalarla Yetinmek

“Toplantıda konustuk, herkes anladi” yetmez. Her karar yazılı kayıt altına alinmali, imza/e-posta onayı alınmalıdır.

3. Degisiklik Sürecini Bypass Etmek

Üst yönetim veya “önemli” paydaşlar için istisna yapmak, sürecin tümünü zayıflatır. Kural herkese eşit uygulanmalıdır.

4. Etki Analizini Atlamak

Değişikliğin sadece geliştirme eforunuu değil; test, eğitim, dokümantasyon, destek etkilerini de hesaplayın.

5. Gold Plating’e Göz Yummak

Ekibin “bonus” özellik eklemesine izin vermek, hem kaynagi harcar hem kullanıcının beklentisini yükseltir.

6. Kapsam Baseline’i Güncellememek

Onaylanan değişiklikler, kapsam dokümanına yansitilmalidir. Aksi halde “orijinal kapsam” ile “güncel kapsam” arasında belirsizlik oluşur.

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

Degisiklik kararlarını sadece proje ekibi alirsa, paydaş direnci artar. Trade-off kararlarında is birimlerini de masaya oturtun.

Disiplinli süreç yönetimi hataları önler

Scope Creep Önleme Kontrol Listesi

Scope Creep Basladiysa: Kurtarma Planı

Geç kalmış olsanız bile, kontrol altına almak mümkündür

Eğer proje zaten scope creep’in etkisindeyse, panik yerine sistematik kurtarma uygulayın:

Adım 1: Durumu Kabul Edin

Scope creep’i görmezden gelmek sorunu büyütür. Mevcut durumu nesnel olarak değerlendirin ve paydaşlarla paylaşın.

Adım 2: Kapsamı Yeniden Belgeleyin

Orijinal kapsam ile su anki kapsam arasındaki farkı çıkartın. Tüm eklenen maddeleri listeleyin.

Adım 3: Önceliklendirme Yapın

MoSCoW metoduyla her maddeyi sınıflandırın:

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

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

Revize edilmiş kapsamı Steering Committee’ye sunun. Trade-off’ları açıkca belirtin: “X özelliğini eklersek, Y tarihinde değil Z tarihinde biter.”

Adım 5: Baseline’i Güncelleyin

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

Adım 6: Süreçlerri Sikrlastirin

Aynı duruma tekrar dusulmemesi için degisiklik yönetimi sürecini gucfrlendirin.

Sikca Sorulan Sorular (SSS)