Ankara’da endüstriyel otomasyon ekipmanı satan ve sahaya servis veren 312 çalışanlı bir firmayı düşünün. Satış ekibi teklif kesiyor, servis ekibi sahaya çıkıyor, satın alma yedek parça sipariş ediyor ve muhasebe ay sonunda bunları tek tek kayıt altına almaya çalışıyor. Her departman kendi Excel dosyasında çalışıyor, veri aktarımı e-posta yoluyla geliyor ve herhangi bir projenin gerçek maliyetini sormak, muhasebecinin iki saatlik bir araştırmasını gerektiriyor. Bu tablo, Türkiye’deki onlarca mühendislik ve teknik servis firmasında standart bir sahne. Peki ERP kurulumu bu sahneyi gerçekten değiştirir mi? Yanıt, soruyu kimin sorduğuna bağlı.Bu makaledeki tez şudur: Hizmet ve mühendislik şirketlerinde ERP projelerinin büyük çoğunluğu yazılım seçimi yanlış yapıldığı için değil, proje bazlı maliyeti finans kesimine bağlayan süreç mimarisi kurulmadan yazılım kurulduğu için başarısız sonuç veriyor. Yazılımı kurmak kolay; hangi işin hangi maliyet merkezine nasıl işleneceğini, servis kaydının nasıl bir finansal belgeye dönüşeceğini ve teklif aşamasındaki kalemlerin satın alma siparişiyle nasıl eşleşeceğini tanımlamak zor. Bir ERP paketi bu soruları sizin için yanıtlamaz; yalnızca yanıtları kayıt altına alır.Mühendislik ve teknik servis firmalarının kendine özgü bir veri akışı yapısı var. Klasik ticaret şirketlerinde süreç lineer: sipariş gelir, stok çıkışı olur, fatura kesilir. Hizmet ve mühendislik şirketlerinde ise aynı iş için birden fazla mali iz var: proje sözleşmesi, hakedişler, yedek parça sarfiyatı, iş gücü saati ve saha ekibinin harcamaları. Bu izlerin hepsi aynı projeye bağlanmadığı sürece muhasebe, aylık bazda gerçek karlılığı göremez. Uygulamada sıkça karşılaşılan tablo şu: satış modülünde proje sözleşmesi var, satın alma modülünde ilgili siparişler var, servis modülünde servis emirleri var; ama bunlar birbirinden bağımsız kayıtlar olarak duruyor. Entegrasyonu sağlamak, kullanıcı eğitiminden çok iş sürecinin yeniden tanımlanmasını gerektiriyor. Entrika burada: çoğu firma bu yeniden tasarımı ERP projesinin başında değil, canlıya geçtikten sonra fark ediyor.Satın alma modülü, hizmet firmalarında en sık hafife alınan bileşendir. Ticaret firmasında satın alma net: mal gelir, depo girer, fatura eşleşir. Mühendislik firmasında aynı parça bazen doğrudan sahaya gider, bazen stoğa alınır, bazen müşterinin makinesine takılır ve hakedişe yansır. Bu üç senaryo, ERP’de farklı akışlar gerektirir; ama kurulum ekibi genellikle hepsini tek bir ‘satın alma siparişi’ akışıyla çözmeye çalışır. Sonuç: kullanıcılar sistemi devre dışı bırakıp tanıdık Excel’e geri döner. Bir Bursa makine imalat firmasında, kurulumdan 11 ay sonra servis ekibinin hâlâ ayrı bir Excel tablosu tuttuğunu gördüm; sebebini soran proje yöneticisine verdikleri yanıt net ve acı vericiydı: ‘Sistem bizim işimize göre değil, muhasemenin işine göre kurulmuş.’ Bu cümle, çoğu ERP projesinin özet belgesi sayılabilir.Satış tarafında benzer bir gerilim var. Mühendislik firmalarında satış süreci uzun ve teknik: teklif hazırlamak bazen haftalar sürer, değişiklik emirleri sözleşmeyi kökten değiştirebilir ve fiyatlama mühendislik hesaplamalarına dayanır. CRM modülü veya satış teklif yönetimi, bu teknik derinliği desteklemek zorunda. Buna karşın kurulum ekipleri genellikle satış modülünü standart ticari teklif akışıyla kuruyor; mühendislik revizyonlarını, alternatif kalem gruplarını ve müşteri özel iskonto kademelerini tanımlamak için ek özelleştirme gerekiyor. Özelleştirme maliyeti yükseliyor; yönetim bütçeyi kısıyor ve sonuç olarak satış ekibi sisteme veri girmeden başka bir yol buluyor. 2012 itibarıyla yerli ERP çözümlerinin bir kısmı bu konuda gerçek adımlar attı; proje bazlı teklif ve değişiklik emri yönetimi artık modüler olarak geliyor. Ama bir modülün var olması ile sahada çalışması arasında hâlâ ciddi bir mesafe var.Servis yönetimi, tüm bu zincirin en kritik halkası ve en az olgunlaşmış modülü. Saha teknisyeni iş emri açıyor, parça kullanıyor, saat giriyor ve iş kapanıyor. Bu adımların her biri bir maliyet üretiyor; bu maliyetlerin projeye veya müşteriye bağlanabilmesi için servis modülünün hem stokla hem de proje muhasebesiyle konuşması gerekiyor. Türkiye’deki teknik servis firmalarında bu entegrasyon, ERP projesinin en sık atlandığı veya sonraki aşamaya bırakıldığı noktadır. Pratik neden anlaşılabilir: saha ekibi sisteme veri girecek düzeyde bilgisayar kullanımına alışkın olmayabiliyor, servis lokasyonlarında bağlantı sorunlu olabiliyor ve servis iş emri ile fatura arasındaki süreç müşteriye göre farklılaşabiliyor. Bu karmaşıklığı yönetmek yerine, kurulum ekipleri zaman zaman ‘servis modülünü ikinci fazda ekleriz’ kararı alıyor. İkinci faz ise genellikle bir sonraki bütçe dönemine, oradan da belirsiz bir geleceğe kayıyor.Tüm bu tablonun pratik çıktısı şu: hizmet ve mühendislik şirketlerinde ERP projesine başlamadan önce yönetim ekibinin yanıtlaması gereken birkaç kritik soru var. Hangi bilgi, hangi departmanda üretilip hangi departmana akacak? Proje maliyeti nasıl tanımlanıyor ve bu tanım muhasebe, proje yönetimi ile satın alma arasında tutarlı mı? Servis iş emri ile müşteri faturası arasındaki süreç adımları belgelenmiş mi? Bu soruların yanıtı belgede yoksa, yazılım kurulumuna geçmek erken. Bir ERP paketi, tanımlanmamış süreci otomatize edemez; yalnızca karmaşıklığı daha pahalı bir zemine taşır. Ankara’daki o otomasyon firması, doğru soruları öne aldığında süreç mimarisini altı haftada kurdu ve ERP kurulumunu üç ayda tamamladı. Aynı büyüklükteki rakip firma süreci atlayıp yazılıma girdi ve on dört ay sonra hâlâ canlıya geçemedi. Fark yazılımda değil, başlangıç noktasındaydı.