ERP projelerinde başarı, yazılımdan çok süreç modellemesiyle ilgilidir

Bir ERP/MRP/CRM dönüşüm projesine başlarken en sık karşılaşılan yanılgı, işin bir yazılım geliştirme projesi olduğunu düşünmektir. 25 yılı aşkın süredir kurumsal yazılım geliştirme ve implementasyon süreçlerinde edindiğim deneyim bana tam tersini gösterdi: bir ERP projesinin kaderi, kod yazılmaya başlamadan çok önce, süreçlerin nasıl anlaşıldığı ve modellendiği aşamasında belirleniyor.

Neden süreç modelleme ilk adım olmalı

Satın almadan üretim planlamasına, kalite yönetiminden stok ve depo operasyonlarına, satıştan finans ve muhasebeye kadar uzanan iş süreçleri kağıt üzerinde birbirinden bağımsız gibi görünse de, aslında sürekli veri alışverişi içinde çalışan tek bir bütündür. Bu süreçlerin gerçek işleyişi -yazılı prosedürler değil, fiilen nasıl yürütüldükleri- doğru anlaşılmadan tasarlanan bir modül, kısa vadede "çalışır" görünse bile üretim ortamında hızla kırılganlaşır: istisnai durumlar karşısında tıkanır, iş birimleri sistemi atlatan alternatif yollar bulmaya başlar ve zamanla veri bütünlüğü bozulur.

Süreç analizinde izlediğim yöntem

Bir modül tasarlamadan önce ilgili iş birimiyle oturup mevcut süreci uçtan uca gözlemlemek benim için vazgeçilmez bir adımdır. Bu görüşmelerde genellikle üç soruya odaklanırım:

• Süreç fiilen nasıl işliyor? Yazılı prosedürle fiili uygulama arasındaki fark genellikle en değerli bilgiyi taşır.
• İstisnalar ne sıklıkla ve nasıl yönetiliyor? "Normal" akış kadar, kuralın dışına çıkan durumların nasıl çözüldüğü de tasarımı şekillendirir.
• Bu süreç hangi diğer süreçlerle veri paylaşıyor? Bir modülü izole tasarlamak, entegrasyon aşamasında en pahalı hatalara yol açar.

Modülerlik ile bütünlük arasındaki denge

Kurumsal bir ERP/MRP/CRM yapısında her modülü tamamen bağımsız bir bileşen gibi tasarlamak cazip görünür; geliştirmesi ve testi kolaylaşır. Ama iş birimleri arasındaki veri akışı gerçekte bu kadar keskin sınırlarla ayrılmaz. Benim tercih ettiğim yaklaşım, modülleri bağımsız geliştirilebilir ama ortak bir veri modeli ve entegrasyon katmanı üzerinden konuşan bir yapıda kurgulamaktır. Böylece hem geliştirme ekibi paralel çalışabilir hem de veri bütünlüğü korunur; örneğin Logo/Netsis gibi mevcut kurumsal sistemlerle kurulan entegrasyonlarda bu prensip, sonradan yamanacak arayüzler yerine baştan tutarlı bir veri sözleşmesi kurmayı mümkün kılar.

Değişim yönetimi, teknik tasarım kadar önemli

Doğru modellenmiş bir süreç bile, o süreci kullanacak ekipler tarafından benimsenmezse hayata geçmez. Yeni bir modülü devreye alırken, iş birimlerini sürecin başından itibaren tasarıma dahil etmek; onların "bize dayatılan bir sistem" değil, "birlikte kurduğumuz bir sistem" hissetmesini sağlar. Bu, geçiş sürecindeki dirençleri büyük ölçüde azaltır.

Sık yapılan hatalar

• Süreç analizini yalnızca üst yönetimle yapmak; fiili işleyiş çoğu zaman sahada çalışanlarda görünür.
• İlk sürümde her şeyi kapsamaya çalışmak yerine, kritik süreçlerden başlayıp kademeli genişlemeyi tercih etmemek.
• Entegrasyon ve raporlama ihtiyaçlarını proje sonuna bırakmak; bu ihtiyaçlar veri modelini doğrudan etkiler.

Kademeli geçiş stratejisi

Kurumsal ölçekte bir ERP/MRP/CRM yapısını tek seferde tamamen değiştirmeye çalışmak, hem proje riskini hem de organizasyonel direnci gereksiz yere büyütür. Bunun yerine, en çok ağrı yaratan veya en yüksek katma değeri sağlayacak süreçten başlayıp, her aşamada mevcut sistemle yeni yapının bir arada, kontrollü şekilde çalışmasına izin veren bir geçiş planı kurmayı tercih ediyorum. Bu yaklaşım, bir sorun ortaya çıktığında etkisini sınırlı bir alanda tutar ve iş birimlerinin yeni yapıya adaptasyonunu kademeli olarak, güven inşa ederek gerçekleştirir.

Sonuç olarak, bir ERP dönüşümünün başarısı seçilen teknoloji ya da yazılan kod satırı sayısıyla değil, süreçlerin ne kadar doğru anlaşıldığı ve modellendiğiyle ölçülür. Teknoloji, doğru modellenmiş bir sürecin üzerine oturduğunda gerçek değerini üretir.

Başarılı ERP, yazılımdan çok süreçlerin doğru modellenmesiyle ilgilidir.