Pazar Lideri Şirketlerde ERP Projesinin Organizasyonel Etkileri

Pazar liderliği, ERP projesinin önündeki en büyük engel olabilir. Bu cümleyi ilk duyduğunuzda mantıksız gelir: kaynak sorunu yok, yönetim desteği var, kurumsal hafıza güçlü. Ama sahada tekrar tekrar gördüğüm tablo tam tersidir. Pazar liderliği, kurumda ‘biz zaten doğru yapıyoruz’ kültürünü besler; bu kültür mevcut süreçlerin ERP’ye uyum sağlamadan ERP’yi kendine uydurmaya çalışmasına zemin hazırlar. Sonuç: milyonlarca TL harcanan bir proje, eski alışkanlıkları dijital formatta tekrar üretmekten öteye geçemiyor. Peki sorun gerçekten teknik mi, yoksa organizasyonel mi? Bu soruyu yanlış yanıtlayan her proje yöneticisi, müşteriye de yanlış bir süreç vadediyor.ERP tartışmalarında iki karşıt kamp her zaman vardır. Birinci kamp şunu savunur: ERP bir araçtır; işini doğru tanımla, doğru yapılandır, gerisi otomatikleşir. İkinci kamp ise şunu söyler: ERP sadece teknik bir kurulum değil, organizasyonun kendini yeniden tanımlamasıdır; bu yeniden tanımlamayı atladığında yazılım çöp üretir, hızlıca. Her iki görüş de kısmen doğru. Birincisi pratikte sık tercih edilir çünkü daha hızlı ve görünürde daha az riskli görünür. İkincisi ise gerçek değer üretmenin koşulunu söyler ama zamanla ve dirençle öder. Gerilim burada başlar: hızla teslim edilmesi beklenen bir proje ile organizasyonu gerçekten değiştirme hedefi arasındaki açı. Bu açı pazar lideri şirketlerde daha da geniştir çünkü o şirketin yöneticileri, mevcut işleyişin sonuçlarını görerek büyümüşlerdir ve bu işleyişe güvenleri derindir.Ankara’da otomotiv yedek parça distribütörlüğü yapan, yaklaşık 284 çalışanlı bir şirketi ele alalım. Temsili bir senaryo olarak sunuyorum; ama benzer dinamikleri birden fazla benzer vakada gözlemledim. Şirket, alanında bölgesel lider konumunda; bayi ağı güçlü, stok çeşitliliği rakiplerinin üç katı. ERP projesine karar verildiğinde genel müdür şunu söylüyor: ‘Zaten iyi çalışıyoruz, sadece raporlamayı düzeltelim.’ Bu cümle projenin çöküşünü önceden haber verir. Çünkü ‘sadece raporlamayı düzelt’ talebi, satın alma, stok ve muhasebe süreçlerinin olduğu gibi kalmasını, üstüne bir raporlama katmanı eklenmesini istemek anlamına gelir. Oysa ERP bu süreçleri entegre ederek değer üretir; entegrasyon ise süreçlerin yeniden tanımlanmasını zorunlu kılar. Tanım değişmezse entegrasyon yüzeysel kalır, raporlar da tutarsız veriden beslenmeye devam eder.Organizasyonel direncin en somut biçimi şudur: ERP projesinin veri girişi standartlarını değiştirdiği her noktada, o noktadan sorumlu kişi ya önceki alışkanlığını korumak için sistemi devre dışı bırakmanın yolunu arar ya da yöneticisine baskı uygular. Ankara’daki bu vakada satın alma birimi, yıllardır kendi Excel tablolarıyla yönettiği sipariş sürecini ERP’nin stok modülüne taşımayı altı hafta boyunca aktif biçimde direnerek geciktirdi. Birimin amiri teknik yetersizliği öne sürdü; gerçek neden ise o tablolardaki görünürlüğü kaybetmek istememesiydi. Bu tür direncin toplam proje süresine etkisi küçümsenmez: Türkiye’de orta ölçekli bir distribütör için standart bir ERP kurulumu 8 ila 14 ay arasında tamamlanırken, organizasyonel direncin yönetilmediği projelerde bu süre doğrusal uzamaz, sıçramalar yapar. Danışman firma günlük harcamaya devam eder, şirket iç motivasyonunu kaybeder, proje sponsoru yavaş yavaş destekten çekilir.Hangi koşulda hangi yaklaşım geçerli? Pazar liderliği yüksek ama süreç olgunluğu düşük olan şirketlerde, yani işler iyi gittiği için süreçler hiç yazılmamış olan organizasyonlarda, ERP kurulumu her zaman süreç tanımlamayla başlamalıdır. Bu bir ön proje değil, projenin kendisidir. Eğer proje yöneticisi bu aşamayı ‘zaten biliyoruz’ diyerek atlıyorsa, sonraki aylarda aynı soruları daha pahalı bir ortamda yeniden soracaktır. Öte yandan süreç olgunluğu görece yüksek olan şirketlerde, örneğin ISO 9001 belgelendirmesini gerçekten uygulamış ve prosedürlerini yaşayan belgelere dönüştürmüş bir imalat firmasında, ERP kurulumu çok daha az organizasyonel travmayla ilerler. Dolayısıyla proje başında sorulması gereken soru ‘hangi yazılımı alalım’ değil, ‘mevcut süreçlerimizi ne kadar net tanımladık ve bu tanımları kaç kişi gerçekten biliyor’ olmalıdır. Bu sorunun cevabı projenin süresini, maliyetini ve başarı olasılığını belirler.Bu tavsiyenin geçerli olmadığı bir durum da var: kriz anında aceleyle kurulan ERP projeleri. Bazı şirketler banka kredi koşulu olarak ya da bir ortaklık görüşmesinde kurumsal görünmek amacıyla ERP’ye hızla geçmek zorunda kalır. Bu koşulda süreç olgunlaştırma lüksü yoktur; önce temel finans ve stok modülleri devreye alınır, organizasyonel dönüşüm ikinci aşamaya bırakılır. Türkiye’deki KOBİ gerçeğinde bu senaryo sandığınızdan sık yaşanır; döviz bazlı yazılım lisansı ve danışmanlık maliyetleri projeyi ikiye bölmeyi ekonomik açıdan da anlamlı kılar. Ama bu durumda bile bir not düşülmelidir: ikinci aşamayı ertelemek ertelemektir, iptal etmek değil. ‘Sistem kuruldu, bitti’ denen anda organizasyonel dönüşüm defteri kapanır ve ERP pahalı bir veri giriş aracına dönüşür.Peki pazar lideri bir şirketin genel müdürü olarak ne yaparsınız? Projeye başlamadan önce kendi yönetim ekibinize şu soruyu sorun: ‘Hangi sürecimizi bugün tam olarak tarif edebiliriz ve tarifi kim onaylar?’ Eğer bu soruya net yanıtlar alamıyorsanız, ERP satın alma kararını birkaç ay erteleyin ve o süreyi süreç dokümantasyonuna ayırın. Bu öneriye çoğu zaman ‘zaman kayıplarız’ denir. Aslında tam tersine, bu hazırlığı yapan şirketler ERP kurulumunu hem daha kısa sürede hem de daha az danışman desteğiyle tamamlar. Ankara’daki otomotiv distribütörü söz konusu hazırlığı yapmadı; projenin ilk sekiz ayında toplam danışmanlık maliyetinin yaklaşık %57’si süreç tartışmalarına, kimin neyi nasıl yaptığını anlamaya harcandı. Bu maliyet, üç aylık bir iç süreç çalışmasıyla büyük ölçüde önlenebilirdi. Pazar liderliği sizi rakiplerinizden ileride tutar; ama aynı pazar liderliği, değişime direncin gerekçesine de dönüşebilir. Bu ikisini birbirinden ayırt eden yönetici, ERP projesinden gerçek değer çıkaranın kendisidir.