İnşaat Sektöründe ERP: Şantiyeyi Veri Kaynağı Olarak Tanımlamazsanız Sistem Kağıt Üzerinde Kalır

İnşaat firmalarının ERP kurulumunda en sık yaptığı hata, sistemi muhasebe departmanından başlatıp şantiyeyi kenarda bırakmaktır. Bu yaklaşım kısa vadede anlaşılır görünüyor: muhasebe bölümü sistemi en çok talep eden, en hazır kullanıcı profili. Ancak inşaatta asıl maliyet ve asıl belirsizlik muhasebe masasında değil, şantiye zeminine sinen o günlük akışta yatıyor — malzeme girişi, işçilik kaydı, alt taşeron hakediş belgesi, proje değişikliği talepleri. Bu akışı sisteme dahil etmeden kurulan ERP, sonunda pahalı bir genel muhasebe programına dönüşüyor. Orta ölçekli bir inşaat şirketinin bu döngüden çıkabilmesi için şantiyeyi veri kaynağı olarak tanımlaması, muhasebe modülünü ise bu kaynağın çıktılarını derleyen son katman olarak konumlandırması gerekiyor. Bu basit ama sektörde pek uygulanmayan bir tersine önceliklendirme.İnşaat sektörü ERP’e neden bu denli güçlük çekiyor sorusunun yanıtı, proje bazlı iş yapışının standart ERP modellerine özgün biçimde direnmesinde yatıyor. Çoğu ERP paketi tekrarlayan üretim veya ticaret süreçleri için tasarlanmıştır: stok giriş-çıkış döngüsü, standart ürün maliyeti, sabit müşteri fiyatı. İnşaatta ise her proje kendi maliyet ağacını, kendi alt taşeron yapısını ve kendine özgü sözleşme koşullarını taşıyor. Aynı firmada eş zamanlı yürüyen üç proje, hem farklı inşaat tekniklerini hem farklı malzeme tedarik koşullarını hem de farklı müşteri hak ediş takvimlerini barındırıyor. Bu çeşitliliği standart bir muhasebe modülünün üretim koduyla yönetmeye çalışmak, doldurulmayan alanlar, elle düzeltilen raporlar ve nihayetinde kullanıcının sistemden vazgeçip Excel’e dönmesiyle sonuçlanıyor. 2007 başında Ankara merkezli, 312 çalışanı ve eş zamanlı sekiz aktif şantiyesi olan bir yapı firmasında tam olarak bu tablo vardı: ERP sistemi kurulmuştu ama şantiye kayıtları hâlâ klasörde tutuluyordu.Bu firmanın temel sorunu, ERP içinde proje bazlı maliyet merkezi yapısının hiç kurulmamış olmasıydı. Muhasebede tüm projeler tek bir hesap koduna işleniyor, şantiye malzeme siparişleri genel satın alma akışına dahil ediliyor, alt taşeron ödemeleri ise ayrı bir kasa defterinde izleniyordu. Hakediş süreci bu kopukluğun en ağrılı noktasıydı: müteahhit firmaya kesilen hakediş tutarı muhasebede görünüyor, ancak o hakedişe karşılık yapılan işin fiziksel ilerlemeyle örtüşüp örtüşmediğini kimse sistemden doğrudan okuyamıyordu. Proje müdürü sahada ayrı takip tutuyor, muhasebe müdürü merkezde ayrı takip tutuyor, genel müdür ise iki tarafı uzlaştırmak için ayın sonunda birkaç saat ayırıyordu. ERP sistemi bu enerjiyi azaltmak için alınmıştı; azaltmamıştı. Teşhis basitti: sistem yanlış kurulmamış, yanlış önceliklendirilmişti.Asıl dönüşüm, ERP modülleri içinde her aktif proje için ayrı bir maliyet merkezi (cost center) tanımlanmasıyla başladı. Bu adım teknik olarak küçük, yönetsel olarak büyük bir değişimdi. Çünkü bundan böyle satın alma siparişinin proje kodunu taşıması zorunlu hale geldi; proje kodu olmayan hiçbir satınalma onaylanamadı. Şantiye şefine bu ilişkiyi her sipariş talebinde uygulatmak altı haftalık bir alışkanlık dönüşümü gerektirdi. Ama o altı hafta geçtikten sonra merkez muhasebesi, hangi projenin ne kadar malzeme tükettiğini gerçek zamanlı değil ama en geç iki iş günü içinde ERP üzerinden görebilir hale geldi. Alt taşeron hakediş belgesi de aynı proje koduna bağlandı; böylece hakediş onay sürecine girmeden önce proje müdürünün bütçeyle karşılaştırma yapması zorunlu kılındı. Sistem değişmemişti; ama şantiyenin sisteme veri beslemesi için net bir kural seti kurulmuştu.Kullanıcı alışkanlıkları meselesini küçümsemek bu tür projelerin en sık yaptığı hatadır. İnşaat şirketlerinde şantiye şefleri ve proje müdürleri teknolojiyle değil, saha gerçekleriyle büyümüş insanlardır. ERP’yi bir zorunluluk olarak görmelerini sağlamanın yolu, sistemi onlara karşı değil onlar için çalışır hale getirmektir. Bu firmada proje müdürlerine ERP üzerinden anlık bütçe-gerçekleşme raporu erişimi tanındı; daha önce bu raporu muhasebeden iki haftada bir talep etmek zorunda kalıyorlardı. Kendi projelerini yakından izleyebildiklerini gördüklerinde sistemin kullanım oranı, serbest tahminen, aylık aktif kullanıcı sayısı bakımından ilk altı ayda yaklaşık iki katına çıktı. Sayıyı abartmıyorum: o dönemde bu tür bir iyileşmeyi sistematik biçimde ölçen araçlar yoktu, şantiye ortamında anket yapılmıyordu. Ama ERP günlük oturum kayıtları üretim tarihini belgeliyor ve artış görülüyordu. Teknoloji çekicinin rolünü üstlenince direnç azalıyor.Bu deneyimden çıkan somut uygulama çerçevesini üç adımda özetleyebilirim. Birinci adım: ERP’ye başlamadan önce her aktif ve planlanmış proje için maliyet merkezi kodlama yapısını kağıt üzerinde tanımla. Bu yapıyı muhasebeci değil, proje müdürleri ve satın alma sorumlusuyla birlikte oluştur; çünkü saha gerçeğini onlar biliyor. İkinci adım: Satınalma onay akışını proje kodu zorunluluğuyla kilitle. Bir sipariş formu proje kodsuz sisteme giremiyorsa, veri disiplinini kurallar değil yazılım koruyor. Üçüncü adım: Hakediş belgelerini ERP üzerinden onay akışına dahil et ve her hakediş öncesinde proje müdürünün bütçe-gerçekleşme karşılaştırmasını onaylamasını zorunlu kıl. Bu üç adım mükemmel bir sistemi değil, çalışır bir sistemi garanti ediyor; inşaat sektörü için bu ayrım hayatidir. Türkiye’de 2007 itibarıyla ERP projelerinin büyük bölümü birinci adımı atlamıştır — kurulum yapılmış, maliyet yapısı kurulmamış.Ankara’daki o firmaya dönersek: proje bazlı maliyet merkezi sistemi oturduğunda, muhasebe müdürünün her ay sonu harcadığı o birleştirme saatleri 11 aya yayılan bir süreçte kademeli olarak azaldı. Tam ortadan kalkmadı çünkü şantiye kaydı hâlâ zaman zaman gecikmeli giriliyor, bazı alt taşeron belgeleri sisteme girmeden ödeme kuyruğuna alınıyordu. Mükemmel değildi; ama yönetilebilirdi. İnşaat sektöründe ERP projesinin başarısını ölçmek için soracağınız soru şudur: Genel müdür, proje maliyet durumunu sistemden mi okuyor, yoksa hâlâ telefon açıyor mu? Eğer telefon açıyorsa, sistem kurulmuştur ama gerçek anlamda benimsenmemiştir. Bu soruyu projeye başlamadan sormak, bitmesinden sonra sormaktan her zaman daha az maliyetlidir.