ERP projelerinin gecikmesi neredeyse bir klişe hâline geldi. Yaygın açıklama genelde teknik olur: yazılım yetersiz kaldı, danışman deneyimsizdi, entegrasyon beklenenden zor çıktı. Sahada gördüğümüz tablo ise farklı. Gecikmenin büyük bölümü, yazılım yazılmaya başlamadan çok önce, süreçlerin yeterince netleşmemiş olmasından kaynaklanıyor.
Gecikme aslında nerede başlar
Bir ERP kurulumu, kurumun kendi işleyişini yazıya dökmesini gerektirir. Çoğu kurumda bu, ilk kez o proje sırasında yapılır. Yıllardır "herkesin bildiği" ama hiçbir yerde tanımlı olmayan kurallar, ancak bir ekrana dönüştürülmeye çalışılınca görünür olur.
Bu noktada iki şey aynı anda ortaya çıkar: departmanların aynı süreci farklı anlattığı ve bazı kararların aslında kişiye bağlı olduğu. Proje takvimi ise genellikle bu keşif yapılmadan önce verilmiştir.
Analiz aşamasında sorulması gereken sorular
Deneyimimize göre aşağıdaki sorular erken sorulduğunda, projenin ilerleyen aylarındaki sürprizlerin önemli kısmı ortadan kalkıyor:
- Bu kararı kim veriyor? Onay zincirindeki her adımın bir sahibi olmalı. "Duruma göre değişir" cevabı, ileride bir iş akışı kurgusunun çökeceği yerdir.
- Hangi veriye bakarak veriyor? Karar bir rapora dayanıyorsa o rapor sistemde üretilebilir olmalı. Excel'de elle düzeltilen bir veriye dayanıyorsa, önce o düzeltmenin ne olduğunu anlamak gerekir.
- İstisna ne sıklıkta yaşanıyor? Ayda bir yaşanan bir istisna için özel geliştirme yapmak, projeyi hem pahalılaştırır hem geciktirir. Bunu erken ölçmek gerekir.
- Bu adım gerçekten gerekli mi? Dijitalleştirme, mevcut süreci olduğu gibi ekrana taşımak değildir. Kâğıt üzerinde anlamlı olan bazı kontroller, sistemde gereksiz hâle gelir.
Kapsam kayması nasıl yönetilir
Kapsamın büyümesi kötü bir şey değil; yönetilmemesi kötü. Analiz ilerledikçe yeni ihtiyaçların çıkması normaldir, çünkü kurum kendi süreçlerini o sırada daha net görmeye başlar.
Burada işe yarayan yöntem, yeni her talebi "şimdi mi, ilk sürümden sonra mı" sorusuyla karşılamaktır. Talebi reddetmek yerine sıraya koymak, hem ekibin motivasyonunu korur hem takvimi ayakta tutar. Canlıya geçmemiş bir sistem kimseye fayda üretmez; eksiği olan ama çalışan bir sistem üretir.
Veri göçü hafife alınıyor
Projelerde en sık hafife alınan kalem veri göçüdür. Eski sistemden gelen veri çoğu zaman tutarsızdır: aynı müşteri üç farklı isimle kayıtlıdır, stok kodları dönem dönem değişmiştir, bakiyeler elle düzeltilmiştir.
Bu temizlik işi teknik bir iş gibi görünse de aslında iş birimlerinin kararına ihtiyaç duyar. Hangi kaydın doğru olduğunu yazılımcı bilemez. Bu nedenle veri göçünü projenin sonuna bırakmak yerine, analizle paralel başlatmak gerekir.
Pratik bir kontrol listesi
- Takvimi keşif çalışması bitmeden vermeyin.
- Her süreç için tek bir karar verici belirleyin.
- İstisnaları sayıyla ölçün, hislerle değil.
- Veri temizliğini birinci günden başlatın.
- İlk sürümü küçük tutun, canlıya erken çıkın.
- Kullanıcı eğitimini teslim anına değil, geliştirme sürecine yayın.
ERP projeleri karmaşıktır, ama öngörülemez değildir. Gecikmenin büyük bölümü, cevaplanmamış soruların faturasıdır. Bu soruları erken sormak, projenin en ucuz aşamasında sormak demektir.