Dış Cephe Kaplama Üreticilerinde ERP: Proje Mantığını Muhasebe Mantığıyla Aynı Platformda Yönetmek

Dış cephe kaplama sektöründe ERP hakkındaki en yaygın yanılgı şudur: bu yazılımı kurunca sipariş takibi düzelir, stok karmaşası çözülür, raporlar kendiliğinden gelir. Ankara’da cam ve kompozit panel üreten, 168 çalışanı olan bir üretici geçen yıl böyle düşünerek bir ERP projesi başlattı. Yedi ay sonra sistem kullanımdaydı — ama muhasebeci hâlâ ek dosyalar tutuyordu, üretim müdürü proje maliyetlerini ayrı bir tabloda izliyordu ve genel müdür ‘sistem bize ne verdi?’ sorusunu sormaya başlamıştı. Sorun yazılımda değildi. Sorun, proje bazlı üretim mantığı ile standart ERP’nin varsaydığı stok ve maliyet mantığı arasındaki derin yapısal gerilimde yatıyordu. Bu gerilimi çözmeden satın alınan her ERP, eninde sonunda pahalı bir Excel yedeğine dönüşüyor.Dış cephe kaplama üretimi, tekstil veya gıda üretiminden çok farklı bir mantıkla işler. Tekstil fabrikası belli SKU’lar üretir; aynı iplik, aynı tezgah, aynı beden aralığı. ERP bu yapıya son derece uygundur: ürün ağaçları (BOM) sabittir, stok rotasyonu tahmin edilebilirdir, maliyetler birim bazında hesaplanır. Dış cephe kaplama üreticisinde ise her proje farklıdır. İstanbul’daki bir rezidans projesi için kesilen alüminyum kompozit panel boyutları, üç ay sonra Ankara’daki hastane projesi için tamamen değişir. Her siparişin ayrı renk kodu, ayrı profil kalınlığı, ayrı bağlantı detayı vardır. Bu durumda ERP’nin standart stok modülü ne yapar? Gerçekte var olmayan bir ‘standart ürün’ kurgusu üzerinden çalışmaya zorlanır — ya da proje bazlı BOM yönetimi için kapsamlı bir özelleştirme yapılması gerekir. Bu özelleştirmeyi baştan planlamayan projelerin büyük çoğunluğu, canlıya geçtikten sonra üretim takibini yine eski yöntemlerle yapmaya devam eder.ERP’nin dış cephe üreticisine gerçek anlamda değer kattığı alan üretim takibi değil, finansal konsolidasyondur. Bir yapı şirketi aynı anda birden fazla inşaat projesine kaplama tedarik ediyorsa — ki Türkiye’nin hızlı büyüyen konut ve ticari gayrimenkul piyasasında bu durum kaçınılmaz — hangi projenin karlı, hangisinin zarar ettiğini izlemek kritik bir yönetim sorununa dönüşür. Proje bazlı kâr-zarar takibi, satın alma emirlerinin proje koduna bağlanması, hakediş ile fiili maliyet karşılaştırması — bunların tamamı iyi yapılandırılmış bir ERP’de mümkündür. Eskişehir’de alüminyum profil ve cam cephe sistemi üreten orta ölçekli bir firma bu modeli kurduğunda, daha önce muhasebecinin aylık kapanış sırasında 9 ila 11 gün harcadığı proje bazlı maliyet raporlaması 4 güne inmiş; üstelik raporlar daha güvenilir hale gelmiştir. Kazanım yazılımdan değil, sürecin doğru tasarlanmasından geliyordu.Peki proje bazlı maliyet takibini ERP’ye taşımak neden bu kadar zorlu? Cevap, inşaat ve üretim sektörlerinin iç içe geçtiği bu niş alanda süreç standardizasyonunun son derece düşük olmasıdır. Çoğu dış cephe kaplama üreticisi, sipariş kabulünden kesim planına, kesim planından sevkiyata uzanan iş akışını patron veya satış müdürünün hafızasında tutar. Bir ERP danışmanı sahaya indiğinde ne görür? Sisteme girilmesi gereken ‘süreç’ henüz kağıt üzerinde bile yazmamaktadır. Bu durumda ERP uygulamasına başlamak, temeli olmayan bir binaya duvar örmek gibidir. Ankara’daki firmanın yaşadığı da buydu: veri girişi başlamıştı ama hangi verinin, kimin tarafından, hangi adımda sisteme işleneceği netleştirilmemişti. Geçiş dönemi 7 hafta sürdü — ama bu 7 haftanın büyük bölümü süreç tartışmasıyla geçti, yazılım konfigürasyonuyla değil. Süreci önce belgelemek, sonra ERP seçmek bu zaman ve enerji kaybını yarı yarıya azaltırdı.Bir karar yöneticisinin sormaya başlaması gereken sorular şunlardır: Birinci adım, proje bazlı maliyet hesabını bugün nasıl yapıyorsunuz — ve bu hesabın doğruluk oranı ne? Eğer yanıt ‘muhasebeci ve proje müdürü ayrı ayrı hesaplıyor, sonra karşılaştırıyoruz’ ise ERP öncesinde bir iç veri standardizasyon çalışmasına ihtiyaç var demektir. İkinci adım, hangi bilginin sisteme gerçek zamanlı girmesi gerektiğini — ve hangisinin periyodik toplu girişle idare edebildiğini — net biçimde ayırt etmektir. Dış cephe üreticilerinde kesim emirleri her gün değişebilir; ama genel muhasebe işlemleri haftalık toplu girişe dayanabilir. Bu ayrımı yapmadan ‘her şeyi anlık sisteme girelim’ yaklaşımı sahada dirençle karşılaşır ve kullanıcılar bir süre sonra sistemi devre dışı bırakmaya başlar. Üçüncü adım, yazılım seçimini bu iki sorunun yanıtına göre yapmaktır — özelleştirme kapasitesi yüksek ama maliyeti ağır bir çözüm mü, yoksa proje modülü güçlü, kurulum süresi daha kısa bir sektörel çözüm mü? Bu soruları sormadan yapılan yazılım demoları ise her zaman ikna edici görünür — çünkü demo, sizin gerçek sürecinizi değil, yazılımın en iyi çalıştığı senaryoyu gösterir.Bazı yöneticiler bu noktada haklı bir itirazı dile getirir: 168 çalışanlı bir firmada tam kapsamlı ERP kurmak zorunlu mu? İyi yapılandırılmış Excel tabloları ve muhasebe yazılımının proje modülü aynı işi görmez mi? Bu sorunun doğru yanıtı, firmanın büyüme hızına ve proje karmaşıklığına bağlıdır. Aynı anda 3 ila 5 büyük inşaat projesine tedarik yapan bir firma, Excel ile idare edebilir — yönetim kapasitesi zorlanır ama sürdürülebilirdir. Ama proje sayısı 8’e ya da 12’ye çıktığında ve projeler farklı şehirlerdeki müteahhitlerle yürütüldüğünde, muhasebecinin proje bazlı takibi elle tutması fiilen imkânsızlaşır; hata oranı yükselir, nakit akış tahminleri tutarsızlaşır. ERP’nin gerçek değeri, bu eşik geçildikten sonra kendini gösterir — eşik geçilmeden yapılan ERP yatırımı ise maliyeti haklılaştırmakta güçlük çeker.Ankara’daki o firma bugün hâlâ muhasebecisinin ek dosyalarına güveniyor. Sorun sistemin yetersizliği değil; sistemin üzerine kurulduğu süreç mimarisinin eksikliğiydi. Dış cephe kaplama sektöründe bir ERP projesi başlatmadan önce kendinize şu soruyu sorun: ‘Bugün proje bazlı maliyeti doğru hesaplayabildiğimizi kanıtlayabilir miyiz?’ Eğer yanıt ‘hayır’ veya ’emin değiliz’ ise ERP o sorunun cevabı değildir — ön koşuludur. ERP projesine başlamak için süreci önce kağıda dökün; sonra yazılım, o kağıdı ölçeklendirir.