Operasyonel Çeşitlilik Arttıkça ERP Proje Yönetimi Nasıl Değişir?

Ankara’da yaklaşık 284 çalışanı olan orta ölçekli bir inşaat firmasını düşünün. Konut projeleri yapıyor, ticari yapı inşa ediyor, ayrıca bazı projelerde alt taşeron koordinasyonunu üstleniyor. Muhasebe departmanı her proje için ayrı ayrı hakediş takibi yapıyor, satın alma birimi malzeme siparişlerini proje bazlı fakat merkezi olmayan bir şekilde yönetiyor, insan kaynakları ise sahaya giden işçilerle ofis kadrosunu tek bir Excel tablosunda tutmaya çalışıyor. Bu firma ERP almaya karar veriyor. İlk toplantıda herkes mutlu: yazılım firması çözümün her şeyi kapsayacağını söylüyor, yönetim kurulu da sonunda ‘sistemi’ kuracaklarını düşünüyor. Dokuz ay sonra proje yarıda kalıyor. Yazılım çalışıyor, ama hiçbir bölüm aynı şekilde kullanmıyor. Sorun yazılımda değil, şirkette neyin standartlaştırılacağına dair hiçbir kararın alınmamış olmasında yatıyor.Burada savunduğum tez şu: operasyonel çeşitlilik yüksek olan firmalarda ERP projesinin başarısızlığı çoğunlukla teknik bir problem değildir. Asıl problem, üst yönetimin yazılımı bir ‘karar aracı’ olarak değil, ‘sorunların kendiliğinden çözüleceği bir platform’ olarak görmesidir. Yazılım ne kadar güçlü olursa olsun, standartlaştırılmamış süreçleri otomatik olarak düzeltemez; aksine, mevcut karmaşayı daha hızlı döndürmeye başlar.Operasyonel çeşitlilik kavramını biraz açmak gerekiyor. Bir şirket birden fazla iş kolu, farklı maliyet yapıları, ayrı satış kanalları veya farklı coğrafyalarda çalışan ekipleri yönetiyorsa, bu çeşitlilik demektir. İnşaat sektöründe bu durum çok belirgin: konut projesi ile ticari yapı projesi, maliyet muhasebesinden hakediş döngüsüne kadar birbirinden farklı süreçler gerektirir. Aynı ERP modülünün her ikisine de ‘aynı konfigürasyonla’ hizmet etmesini beklemek gerçekçi değildir. Oysa Türkiye’deki birçok orta ölçekli firma bu hatayı yapıyor: önce tek bir lisans alıyor, ardından her departmanın kendi ihtiyacını aynı kutuya sığdırmasını bekliyor. Sonuç genellikle, sistemi ciddiye alan iki-üç departman ile geri kalanın eski Excel alışkanlıklarına geri döndüğü yarım kalmış bir kurulum oluyor.Peki operasyonel çeşitlilik arttığında proje yönetimi nasıl farklılaşmalı? İlk ve en kritik adım, ihtiyaç analizi aşamasında ‘ne istiyorsunuz’ sorusunu sormak yerine ‘hangi süreçleriniz tüm iş kollarında aynı işliyor’ sorusunu sormaktır. Bu soru çoğu zaman rahatsız edici bir sessizlik doğurur, çünkü cevap genellikle ‘pek azı’ şeklinde çıkar. Ama bu sessizlik değerlidir: projenin gerçek kapsamını ortaya koyar. Ankara’daki inşaat firmasında muhasebe müdürü her proje için ayrı maliyet merkezi istiyor, satın alma sorumlusu malzeme kodlarının tüm projelerde aynı olmasını talep ediyor, şantiye şefi ise işçi devamsızlık takibini sistemin dışında tutmak istiyor. Bu üç istek birbiriyle çelişmiyor, ama birleşik bir konfigürasyon kararı gerektiriyor. Danışman bu kararı veremez; sadece yönetimin önüne çerçevelenmiş bir seçenek masası koyabilir.İkinci önemli fark, kullanıcı alışkanlıkları meselesidir. Operasyonel çeşitlilik az olan firmalarda — diyelim ki yalnızca konut projesi yapan, 60-70 kişilik bir yapı şirketi — ERP uyumu nispeten hızlı sağlanır çünkü herkes benzer işler yapıyor ve ‘sisteme’ adapte olmak için ortak bir referans noktası var. Ama 284 çalışanlı, üç farklı iş kolu yürüten bir firmada her grubun kendi iş mantığı var. Muhasebeci hakediş tablosunu biliyor ama proje bazlı stok takibini kavramıyor. Satın alma, fiyat onay sürecini ERP üzerinden değil telefon ve e-posta ile yürütmeye alışık. Bu durumda eğitim programını tek tip tutmak, kullanıcıları sisteme değil sistemi insanlara uydurmaya çalışmak anlamına gelir. Saha deneyimim gösteriyor ki bu firmalar için en işe yarayan yaklaşım, her iş kolunun kendi ‘süper kullanıcısını’ (power user) yetiştirmek ve bu kişiyi hem teknik kaynak hem de değişim yöneticisi olarak konumlandırmaktır.Entegrasyon noktaları meselesine gelince: operasyonel çeşitlilik arttıkça veri akışındaki kopmalar da artar. İnşaat sektöründe en yaygın sorun, sahadan gelen günlük iş-güç bilgisinin muhasebedeki bordro verileriyle örtüşmemesidir. Şantiye şefi kağıt formlarla devam takibi yapıyor, İK bu kağıtları haftanın sonunda sisteme giriyor, muhasebe ise bu verilerden hakedişi hesaplamaya çalışıyor. ERP kurulduktan sonra bu üç katmanın veriyi farklı anlarda, farklı terminolojiyle girmesi entegrasyon hatalarına yol açıyor. Bir projede bu tür tutarsızlıkların bir çeyreklik dönemde toplam hakediş tutarının yaklaşık yüzde 7’si kadar fark yarattığını gördüm — küçük görünen bu oran, büyük projelerde ciddi anlaşmazlıklara dönüşüyor. Çözüm, entegrasyon noktalarını projenin başında değil, ihtiyaç analizi sırasında haritalamak ve her noktayı ‘kim, ne zaman, hangi formatta giriyor’ üçlüsüyle tanımlamaktır.Yönetim beklentileri konusu ise genellikle en az konuşulan, en çok hasar veren faktördür. Üst yönetim ERP projesini çoğunlukla ‘sistemi alıp kurarız, raporlar otomatik gelir’ şeklinde tahayyül eder. Oysa operasyonel çeşitlilik yüksek bir firmada ERP, çalışan bir fabrika gibi değil, titiz bir arşiv gibi işler: ne kadar doğru veri girerseniz, o kadar doğru sonuç alırsınız. Yönetim kurulu süreç kararlarına dahil edilmediğinde — proje yalnızca BT sorumlusuna ve dış danışmana bırakıldığında — iki sorun neredeyse kaçınılmaz olarak ortaya çıkıyor. Birincisi, konfigürasyon kararlarında kurum içi yetki savaşları başlıyor. İkincisi, proje bitiş tarihine yaklaştıkça ‘beklenmedik özelleştirme talepleri’ yağmur gibi geliyor ve hem bütçe hem süre eriyor. Bu nedenle ERP danışmanının en kritik görevi teknik değil, yöneticileri doğru soruların önüne çekecek bir fasilitasyon yapısı kurmaktır.Ankara’daki inşaat firması örneğine geri dönelim. O firma projeyi başlatmadan önce şu üç soruyu sormamıştı: Hangi süreçlerimizi tüm iş kollarında tek tip yürütmek istiyoruz? Veriyi kim, hangi noktada, hangi sorumlulukla giriyor? Üst yönetim hangi konfigürasyon kararlarında bizzat yer alacak? Bu soruların cevapları olmadan yapılan her ERP kurulumu, karmaşıklık arttıkça daha büyük bir gürültüyle tökezlemeye mahkumdur. Operasyonel çeşitliliğin getirdiği gerçek güçlük yazılımı seçmek değil, önce şirketi tanımaktır. Yazılım o tanımın ardından gelir.