Uzun Süreli ERP Projelerinde Danışmanlık Sürekliliği Nasıl Sağlanır?

Danışman değişince proje dağılıyor diye düşünürüz. Ama sahada gördüğüm tablo tam tersi: danışman değişmeden de projeler sessiz sedasız çöküyor. Eskişehir’de otomotiv yan sanayii üreten, 312 çalışanlı bir imalat firmasında 16 ay süren ERP projesi bu durumun en net örneği. Proje boyunca aynı danışman yerinde kaldı. Kimse ayrılmadı. Ama 14. ayda finans modülü yeniden yazılmak zorunda kalındı; çünkü birinci ayda alınan bir tasarım kararı — muhasebe hesap planının mevcut yapıya oturtulması — sonraki hiçbir belgeye yansımamıştı. O karar zihinlerde yaşadı, dosyalarda değil. Sorun danışman değil, yapıydı.Buradan çıkan tez basit ama rahatsız edici: ERP projelerinde danışmanlık sürekliliği bir kaynak meselesi değil, bir yapı meselesidir. Doğru kişiyi uzun süre tutmak yeterli değil; bilgiyi kişiden bağımsız hale getiren bir çalışma protokolü olmadan, en istikrarlı ekip bile kırılgandır. Türkiye’deki uzun soluklu ERP projelerinde bu yapının kurulmadığını saha deneyimlerim tekrar tekrar gösteriyor. Patron, ‘danışman ayrılmasın’ diyor. Danışman ayrılmıyor. Proje yine de bilgi kırığına uğruyor. Çünkü bilgi transferi bir etkinlik değil, her hafta gerçekleşmesi gereken bir alışkanlıktır.Peki bu yapıyı nasıl kurarsınız? İlk koşul, projeye başlamadan önce ‘bilgi sahipliği haritası’ çıkarmaktır. Her kritik tasarım kararı için şu üç sorunun yanıtı kayıt altında olmalı: Bu kararı kim aldı, hangi iş gereksiniminden dolayı alındı ve hangi alternatifler elendi? Eskişehir vakasında bu soruların yanıtları 16 ay boyunca kimsenin aklına gelmedi. Sonunda geldi — finans modülü yeniden yazılırken. O ana kadar dört farklı saha toplantısı yapılmış, iki ilerleme raporu üst yönetime sunulmuştu. Ama hiçbirinde ‘bu kararın gerekçesi neydi?’ sorusu sorulmamıştı. Proje ilerlerken kararların gerekçeleri silinip gidiyor; sadece sonuçlar kalıyor. Sonuç ise bağlamından koparılınca anlamsızlaşıyor.İkinci koşul, haftalık bilgi transferi rutini. Bunu toplantıyla karıştırmayın. İlerleme toplantısı ‘ne yaptık’ sorusunu yanıtlar; bilgi transferi rutini ‘ne öğrendik ve nereye yazdık’ sorusunu yanıtlar. Aradaki fark küçük görünür, ama pratikte devasa. Bir Ankara inşaat firmasında gördüğüm örüntü şuydu: proje ekibi cuma günleri bir saat toplanıyor, o haftanın kararlarını ve gerekçelerini yapılandırılmış bir şablona işliyordu. 11 aylık proje boyunca bu rutin 44 hafta tutarlı biçimde yürütüldü. Danışman 7. ayda değişti. Gelen yeni danışman iki haftada hız kazandı; çünkü önceki 6 aya ait kararların tamamı belgeliydi. Bu, istisnai bir disiplin gerektiriyordu — ama o disiplin proje liderinin ‘bu toplantı zorunlu’ demesiyle kuruldu. Sistem karmaşık değildi; sadece tutarlıydı.Üçüncü koşul, müşteri tarafında teknik bir muhatap yetiştirmektir. Türkiye KOBİ pratiğinde bu kural en sık ihlal edilen kuraldır. Patron, ERP projesini danışmanla yönetmeye çalışır; iç ekipten kimseyi teknik konularda büyütmez. Muhasebe müdürü ‘o işler danışmanın’ der. BT sorumlusu — varsa — altyapıyla ilgilenir, süreç tasarımına girmez. Bu boşluk, danışman çekildiğinde ya da değiştiğinde ortaya çıkar: sistemin içini gerçekten bilen tek kişi artık o firmada yoktur. Çözüm, projenin ilk 60 günü içinde müşteri tarafından bir ‘proje sahipliği koordinatörü’ atamaktır. Bu kişi danışmanlık yapmaz; ama her kritik oturumda bulunur, her kararı anlar, sorular sorar. 8-12 ayın sonunda o firma için ERP’yi en iyi anlayan kişi haline gelir. Bu yatırımın bedeli düşük, getirisi yüksektir.Burada bir sınırı açıkça belirtmek gerekiyor: bu üç koşul, kapsamı ve süresi belli projelerde işe yarar. Kapsam değişikliğinin (scope creep) yoğun olduğu, yönetim kararlarının proje ortasında sık sık döndüğü ortamlarda hiçbir bilgi transfer protokolü sizi kurtarmaz. Çünkü belgelediğiniz bilgi haftadan haftaya geçersizleşiyor. Böyle bir projede önce yönetim kararlılığını sağlamak, kapsam değişikliklerini resmi bir onay sürecine bağlamak gerekir. Bilgi transferi yapısı ancak o zemin oturduktan sonra anlam kazanır. Bunu atlayıp doğrudan belgeleme süreçlerine geçenler, değişen kararları temiz tutamazlar — bu boş bir çabadır.Eskişehir’deki o otomotiv firması sonunda sistemi çalışır hale getirdi. Finans modülü yeniden yazıldı, bu süreç 14 ek hafta ve ciddi bir maliyet getirdi. Projeyi yönetenler bu maliyeti ‘teknik aksaklık’ olarak değerlendirdi. Ben danışman gözüyle farklı görüyorum: bu, bir yapı eksikliğinin faturasıydı. Uzun süreli ERP projelerinde sürekliliği güvence altına almak isteyenler şu soruyla başlasın: ‘Danışmanımız yarın ayrılırsa, hangi bilgiyi kaybederiz?’ Eğer bu soruya somut bir yanıt veremiyorsanız, projeniz hâlâ kişiye bağlı çalışıyor demektir. Ve o kişi bugün orada olsa bile bu kırılganlık sizi bekliyor.