Bir ERP projesi geciktiğinde ilk suçlanan genellikle yazılım olur. Oysa geciken projelere sonradan bakıldığında, sorunun kaynağı neredeyse hiçbir zaman "ürün yetersizdi" değildir. Aynı yedi neden dönüp dolaşıp karşımıza çıkar — ve yedisi de projenin ilk haftalarında alınacak kararlarla yönetilebilir.
1. Kapsam hiçbir zaman yazıya dökülmedi
En yaygın neden bu. Taraflar toplantıda anlaşır, herkes farklı bir şey anladığını aylar sonra fark eder. "Stok takibi olacak" cümlesi bir tarafta parti-lot izlenebilirliği, diğer tarafta basit adet sayımı anlamına gelir.
Panzehiri basit ama disiplin ister: ne yapılacağı kadar ne yapılmayacağı da yazılır. Kapsam belgesinde "bu sürümde yapılmayacaklar" başlığı olmayan proje, kapsamı kontrol edemez.
2. Veri kalitesi projenin ortasında fark edildi
Ürün kartlarının yarısı mükerrer, cari hesaplarda aynı firma üç farklı adla kayıtlı, birimler tutarsız. Bunlar eski sistemde sorun yaratmıyordu çünkü insanlar telafi ediyordu. Yeni sistemde otomasyon devreye girince telafi eden insan kalmıyor ve veri kalitesi bir anda görünür oluyor.
Veri temizliği projenin başında yapılmalı, göç sırasında değil. Prova göçü ve rakamsal mutabakat bu yüzden vazgeçilmezdir: kirliliği canlıya geçmeden görürsünüz.
3. Karar verecek kişi projede yok
Analiz toplantılarına katılan ekip, "bu konuda karar veremem, sormam lazım" dediğinde proje durur. Her sorunun bir üst mercie gitmesi, iki haftalık bir analizi iki aya çıkarır.
Projenin başında karar verme yetkisi olan bir sahip atanmalı ve bu kişinin haftada belirli bir zamanı projeye ayrılmalıdır. Yetkisi olmayan bir proje ekibi, en iyi ihtimalle öneri üretir.
4. Süre baştan gerçekçi değildi
"Üç haftada canlıya geçelim" cümlesi, projenin başında verilmiş bir gecikme sözüdür. Gerçekçi olmayan takvim yalnızca gecikmeye değil, kalite düşüşüne de yol açar: test atlanır, eğitim kısaltılır, veri kontrolü yapılmaz.
Kapsam belgesi çıkmadan süre taahhüdü vermemek, iki taraf için de koruyucudur.
5. Kullanıcılar süreci ilk kez canlıda gördü
Eğitim, canlıya geçişten bir gün önce yapılan iki saatlik bir sunum değildir. Kullanıcı kendi verisiyle, kendi işini sistemde yapmadan öğrenmez.
En verimli zamanlama: test ortamı hazır olduğunda ve canlıya geçişten bir iki hafta önce. Çok erken verilen eğitim unutulur, çok geç verilen panik yaratır.
6. Geliştirme, standardı denemeden başladı
Bir ihtiyaç standart üründe yüzde seksen karşılanıyorsa, kalan yüzde yirmi için geliştirme yapmak çoğu zaman yanlış karardır. Geliştirme yalnızca maliyet değil; test yükü, bakım yükü ve sürüm yükseltme riski demektir.
Kuralımız şu: önce süreci standarda uydurmayı deneriz. Geliştirme, gerçekten gerekli olduğunda yapılır ve çekirdek koda dokunmadan, ayrı modül olarak yazılır.
7. Her şey aynı gün canlıya alınmak istendi
Tüm modülleri tek seferde açmak, tüm riskleri de aynı güne toplamak demektir. Bir sorun çıktığında hangi modülden kaynaklandığını anlamak zorlaşır, ekip aynı anda altı yeni ekranla boğuşur.
Aşamalı geçiş riski dağıtır: önce muhasebe ve stok, sonra satış, sonra üretim. Her aşama kendi kabul testiyle kapanır ve ekip bir sonrakine hazır hale gelir.
Özet
Bu yedi maddenin hiçbiri teknik değil. Hepsi proje yönetimi kararı — ve hepsi projenin ilk haftalarında alınıyor. Bir ERP projesinin kaderi, çoğunlukla ilk kod yazılmadan önce belirleniyor.
Kendi projenizde bu maddelerden hangileri size tanıdık geldiyse, konuşmaya oradan başlayabiliriz.