Büyük sistem geçişlerinin kırılma noktası genellikle teknoloji değildir. IT ile iş birimlerinin farklı dilleri konuşmasıdır.
Sistem doğru kurulur, benimsenmez. Kullanıcı eski yöntemine döner, paralel Excel dosyaları yeniden doğar ve proje teknik olarak tamamlanmış, operasyonel olarak yarım kalmış olur.
Bu işte çok sayıda iş biriminin eş zamanlı çalıştığı bir S/4HANA geçişi vardı.
Takvim, teknik bir sorundan değil, karar hızından kayar
ERP projelerinde gecikmelerin büyük kısmı kod yazma süresinden değil, karar bekleme süresinden birikir.
Bir iş birimi teknik toplantının izleyicisi konumundaysa, kendisine gösterilen tasarımı ancak test aşamasında anlar. O noktada verilen geri bildirim ise değişiklik talebine dönüşür ve takvimi ikinci kez açar.
Aynı şey kullanıcı adaptasyonu için de geçerlidir. Adaptasyon geçiş sonrasına bırakıldığında, canlıya alma günü destek talebi patlar.
Odak metriği proje takvim uyumu ve manuel iş yükü olarak belirlendi.
Ne yaptık
IT ile iş birimleri arasında köprü kurduk. Proje yöneticisi olarak iş birimini teknik toplantının izleyicisi değil karar vericisi yaptık. Bir tasarım kararının sahibi iş birimiyse, o kararın sonucunu da savunur.
Süreç analizi, test ve adaptasyonu tek plana topladık. Üç iş akışı ayrı takvimlerde yürütüldüğünde birbirini bekler. Tek plan altında toplandığında bağımlılıklar önceden görünür.
Kullanıcı adaptasyonunu projenin içine yaydık. Eğitim, canlıya almadan önceki son haftaya sıkıştırılmadı. Kullanıcı, kendi süreçlerinin tasarımına katıldığı için sistemi ilk gün tanıyarak karşıladı.
Sonuç
Geçiş planlanan takvime %95 uyumla tamamlandı. Manuel veri işleme %50 azaldı. Raporlama hızı 3 katına çıktı.
Son iki rakam geçişin sadece zamanında değil, amacına uygun tamamlandığını gösterir. Takvimi tutturup fayda üretmeyen bir ERP projesi, başarılı sayılmaz.
Yöntem notu: ERP geçişinde takvimi koruyan üç karar
Büyük sistem geçişlerinde takvim, teknik gecikmelerden çok karar gecikmelerinden kayar. Üç karar bu riski doğrudan azaltır.
Karar sahibini plana yazın. Her tasarım kararının kime ait olduğu ve ne kadar sürede verileceği proje planında yer almalıdır. Kararın kimde olduğu belirsizse, o karar bir sonraki yönlendirme toplantısına ertelenir ve iki hafta kaybedilir.
İş birimini karar verici yapın. İzleyici konumundaki iş birimi, tasarımı ancak test aşamasında anlar. O aşamada gelen geri bildirim değişiklik talebine dönüşür ve takvimi ikinci kez açar.
Adaptasyonu tasarıma yayın. Eğitim canlıya alma öncesindeki son haftaya sıkıştırıldığında geçiş günü destek talebi patlar ve ekip yeni sistemi bir engel olarak hatırlar.
Takvim uyumunu tek başına ölçmek yeterli değildir
Bir ERP projesi zamanında bitip fayda üretmeyebilir. Bu yüzden takvim uyumu tek başına bir başarı ölçütü değildir.
Bu işte üç rakam birlikte izlendi: takvim uyumu %95, manuel veri işlemede %50 azalma ve raporlama hızında 3 kat artış. Son iki rakam, geçişin sadece zamanında değil amacına uygun tamamlandığını gösterir.
Geçiş projelerinde fayda metrikleri başlangıçta tanımlanmadığında, proje sonunda tartışılan tek konu takvim ve bütçe olur.
Bu tablo size tanıdık geliyorsa
Büyük bir sistem geçişimiz var ve takvimin tutacağına kimse inanmıyor.
Bu inançsızlık genellikle haklıdır ve sebebi teknik ekip değildir. Karar mekanizmasının proje planına bağlanmamış olmasıdır.
Sizin değiştirmek istediğiniz rakam ne? İşin mutfağına girip 11 günde sorunu tespit ediyor, 4, 8 ve 12 haftalık hedefler koyuyor, insanı, süreci ve teknolojiyi o hedefe koşturan sistemi kuruyoruz. Hedefe ulaşınca sistemi ekibinize devredip çıkıyoruz. İlk oturum 60 ila 90 dakika sürüyor ve ücretsiz. hello@elevens.group · +90 216 706 07 50 · elevens.group
