ERP-Köksel Nedenlerin Yarattığı Sorun
Neden bu kadar çok kurum rastgele ortaya çıkan mimarileri bulaşıyor?Yıllar önce,en büyük ERP tedarikçilerinden birinin kıdemli bir üst düzey yöneticisi bana,iş süreçlerinin bir ERP sistemi içinde otomatik hale getirmenin onların üzerine “beton dökmeye” benzediğini söylemişti.Bu,bir süreç borcu örneğidir ve otomasyon bir süreci öyle bir hale getirir ki daha ileriki zamanlarda iyileştirilmesi çok zor olur.Örneğin,”tek bir ERP oluşumu”,daha basittir ve merkezi olarak yönetilmesi de genelllikle daha az maliyetlidir ancak local iş birimlerinin küresel standartların katılığıyla uğraşması gerekir.Aynı zamanda ,farklı iş döngüleri ve olgunluk aşamalarını yansıtan uzak iş hatları ya da bölgelerin,merkezdeki ERP yönetim değişikliğinin ritmine ayak uydurma zorunluluğu da söz konusudur.
Bunun ille de kötü bir şey olması gerekmez;değişen iş gereksinimlerine karşılık verme ihtiyacını destekleyecek kadar hızlı olduğu sürece,sabit bir ritim faydalıdır.Ancak ritim çok ağır olduğunda (iki yıl kadar uzun süren ERP ‘yi kullanıma alma döngüleri gördüm),herkes kurumsal çapta değişiklik yönetiminin ve sürekli iyileştirmenin en düşük ortak paydasına bağlı kalır.Bu,münferit iş birimlerinin ve değer zincirlerinin esnekliğini sınırlayan bir prangaya dönüşebilir.
Ayrıca ekosisteme entegre edilen her ayrı uygulamanın ya da uzantının kendisine ait yama değişimi,geliştirme,güncelleme,sürüm yükseltme,mimari değişiklik,araç ve veritabanına uyumluluk meseleri,veri modeli değişiklikleri vs döngüler olduğunu ve bunların da COST ekosistemi değişiklik yönetimiyle senkronize olması gerektiğini düşünün.Bu unsurlar arasındaki kesişimler ,birbirinden bağımsız olarak sistem üzerinden değişim yaratan ve küresel sonuçları olan sorunlu fay hatları “ gerilim noktaları” dır.Bunların toplamı ,bütün sistemin esnekliğine direnç gösteren,transfer noktalarında yüksek bakım maliyetlerine ve veri bütünlüğü zorluklarına neden olan ve genel olarak bütün sistemin çevikliğini engelleyen bir yara dokusu gibi davranır.
Yine de,farklı iş birimlerinin gereksinimlerine bağlı olarak COST ekosistemine dışarıdan daha fazla bileşen eklemek yönünde doğal bir eğitim vardır.Ancak aynı zamanda bu sayısı düşük tutmak için kurumsal düzeyde kayda değer bir çaba da söz konusudur.Harvard Business Review’da yayınlanan “ Exploring the Duality between Product and Organizational Architectures” başlıklı makalede,yazarlar “rastgele seçilen bir öğede değişiklik yapıldığında ortalama olarak etkilenebilecek sistem öğelerinin yüzdesini ölçen” yayılma maliyeti tarif ediyor.”Örneğin,eğer bir sistemin her biri bağımsız olarak değiştirilme potansiyeline sahip 100 öğesi varsa,yüzde 50 yayılma maliyeti,tek bir öğede yapılan değişiklikten öğelerin yarısının etkileneceğini anlamına gelir (bu demektir ki risk ve test yapma miktarı öğe sayısı arttıkça üssel olarak artabilir.)Daha düşük bir yayılma maliyetiyle, daha az gecikme ve ağır bir sürüm yönetimi sürecine daha az ihtiyaç duyan modüler bir sistemdir.Sıkı bir şekilde birleştirilmiş mimarileriyle yüzde 50 ya da daha yüksek oranda yayılma maliyeti yaygınken,daha gevşek bir şekilde birbirine ilişmiş ortamlarda bu oran yüzde 10’dur.
Yüksek yaygınlaştırma maliyetlerine sahip karmaşık COST ekosistemlerinde değişim ve sürüm yönetimi ,kaosu hafifletmek açısından gerekli bir güvenlik mekanizması,kurumsal çeviklik açısından ise acımasız ve sinir bozucu bir bariyer süreç iyileştirme ve inovasyon gemisinin arkasından sürüklenen bir çapa gibi davranan uzun ve kaotik test döngüleri gibi davranır.ERP sistemleri için planlı sürüm döngüleri yaygın olarak altı ay ila iki sene arasında sürer.Bu sadece kaizen ekiplerini engelleyip heveslerini kaçırmakla kalmaz,aynı zamanda Yalın düşünmeyle ulaşmayı umduğumuz yinelemeli deney ruhunu da engeller.Daha kötüsü ,ekiplere iyileştirme çabalarını desteklemek için değişikliğin zamanında yapılamayacağı söylendiğinde ,hızlı geçici çözümler arayışına girip “yaramazlık”yapabilir ve birbirinden yalıtık iyileştirmelerle uzun vadeli etkileri olan çok fazla teknik borç yarabilirler.