Üretim ve Ticareti Tek ERP Çatısında Birleştirmek: Teknik Değil, Siyasi Bir Sorun

Kayseri’deki 285 çalışanlı bir otomotiv yedek parça üreticisiyle çalışmaya başladığımda şirket iki ayrı yazılımla idare ediyordu: fabrika tarafı üretime özgü bir takip programı kullanıyor, ticaret birimi ise siparişlerini ve stok hareketlerini ayrı bir muhasebe yazılımında yönetiyordu. İki sistem arasında veri alışverişi Excel dosyalarıyla sağlanıyor, her ay sonu muhasebe müdürü bu dosyaları elle birleştirerek konsolide raporu hazırlıyordu. İlk toplantıda genel müdür bana ‘tek bir sistem kuralım, her şey bağlansın’ dedi. Ben de dahil olduğumdaki neredeyse herkes bu talebin teknik bir proje olduğunu düşünüyordu. Yanılıyorduk. Projenin gerçek zorluğu yazılım mimarisinde değil, üretim müdürü ile satış direktörünün öncelik çatışmasında yatıyordu ve bu çatışma çözülmeden hiçbir ERP kurulumu kalıcı sonuç veremiyor.Tek ERP mimarisi kurmak için en yaygın gerekçe şudur: veriler tek yerde, raporlar tutarlı, hata riski düşük. Bu gerekçe doğrudur — ama yalnızca bir koşulda gerçekleşir: iki operasyonel dünya, yani üretim ve ticaret, aynı veri tanımlarını kullanmayı önceden kabul etmişse. Kayseri vakasında fabrika, stok birimini kilogram cinsinden tutuyordu; ticaret birimi ise müşterilere adet bazında fiyat veriyordu. Sistem kurulmadan önce bu dönüşüm kuralı yazılı hâle getirilmeli, her iki tarafın imzaladığı bir süreç belgesiyle sabitlenmeliydi. Oysa proje başladığında bu kural hâlâ ‘üretim biliyor, satış biliyor, sistem de bilir’ varsayımıyla bırakılmıştı. Sistem tabii ki bilmiyordu. Ve ilk fatura kesildiğinde üretim ile satış birbirini suçlamaya başladı. Yazılım hata raporlamaya devam etti, danışmanlar hafta sonları sahada çalıştı; ama asıl sorun hiçbir zaman kod satırlarında değildi.Bu noktada tezimi açıkça söylemek gerekiyor: üretim ve ticaret operasyonlarını tek ERP mimarisinde birleştirmenin önündeki en büyük engel teknik entegrasyon değil, organizasyonel öncelik çatışmasıdır. Ve bu çatışmayı proje başlamadan çözmek, yazılım seçiminden çok daha kritik bir karardır. Danışmanlar genellikle ihtiyaç analizi toplantılarını yazılım özellik listesi hazırlamak için kullanır; oysa o toplantılarda asıl sorulması gereken soru şudur: ‘Sipariş girişi ile üretim planı çakıştığında kimin kararı geçer?’ Bu soruya net yanıt verilemiyorsa proje bedelini yazılım öder, ama faturayı şirket keser. Kayseri vakasında bu soruyu dördüncü haftada sorduk; proje 14 ay sonra canlıya geçti, ilk sekiz aylık gecikmenin neredeyse tamamı bu tanımsız kararın peşinde harcandı.Teknik tarafta ise gerçekten çözülmesi gereken iki entegrasyon noktası vardı. Birincisi, üretim emirleri (work order) ile satış siparişleri (sales order) arasındaki tetikleme akışıydı. Üretime özgü programlar genellikle kapasite bazlı planlama yapar; ERP’nin ticaret modülü ise tarihe ve müşteriye bağlı teslim takvimi üretir. Bu iki zaman çizelgesi aynı veri tabanında buluştuğunda hangi kural önce çalışır sorusu belgelenmemişse sistem her ikisini de çalıştırıp tutarsız sonuç üretir. Kayseri’de çözüm, satış siparişinin belirli bir eşiğin üzerindeki kapasite tüketimi gerektirdiğinde üretim onayı bekletilmesi kuralıydı; bu kural ERP iş akışına (workflow) işlenince çakışmalar ortadan kalktı. İkincisi, maliyet muhasebesi entegrasyonuydu: fabrika maliyeti standart maliyet yöntemiyle hesaplanırken ticaret birimi gerçekleşen maliyete göre fiyatlandırma yapıyordu. İki yöntem aynı modulde yan yana durduğunda dönem sonu kapanışları tutarsız sonuç veriyordu. Bu sorunu çözmek için aylık maliyet uzlaştırma sürecini ERP içinde bir kontrol adımına dönüştürdük; muhasebe müdürü artık Excel değil, sistemin kendi raporunu kapanış belgesi olarak kullanıyor.Kullanıcı alışkanlıkları meselesini ayrı bir başlık olarak ele almak gerekiyor, çünkü çoğu ERP projesi bu noktada sessizce çöküyor. Kayseri fabrikasında vardiya ustabaşları üretim takibini kağıt formlarla yürütüyordu; fabrika müdürü bu formlara güveniyordu çünkü ‘kağıt yalan söylemez’ diyordu. Sisteme geçişte ilk üç hafta boyunca kağıt formlar ve sistem paralel çalıştı. Bu paralel süreç yönetici için güvence, kullanıcı için ise ek iş yükü anlamına geliyordu. Ancak 8 haftalık paralel çalışma sonrasında fabrika müdürü kağıt formu bırakmaya razı oldu, çünkü sistem onun aradığı vardiya verimliliği raporunu artık otomatik üretiyordu. Buradaki ders şudur: sistemi kullanıcıya sevdirmenin yolu kendi alışkanlığını daha hızlı yapabilmesini sağlamaktır; alışkanlığı tamamen terk ettirmeye çalışmak değil. Yönetim beklentilerini karşılamak ise başka bir denge gerektiriyordu: genel müdür tek konsolide rapor istiyordu, satış direktörü anlık stok görünürlüğü, üretim müdürü ise kapasite yük grafiği. Bu üç talep tek raporla karşılanamaz; ama doğru rol bazlı gösterge paneli tasarımıyla her biri birbirinden bağımsız olarak tatmin edilebilir. Bunu başarmak için teknik beceri değil, kullanıcıyla oturup ‘bugün hangi soruya cevap arıyorsunuz?’ diye sormak gerekiyor.Maliyet ve proje yönetimi perspektifinden bakıldığında, tek ERP mimarisinin toplam sahip olma maliyeti (TCO) iki ayrı sistemin bakım ve entegrasyon maliyetinden çoğunlukla düşük çıkıyor. Kayseri vakasında iki ayrı yazılım lisansı, iki ayrı bakım sözleşmesi ve bir teknik personelin yalnızca bu iki sistem arasındaki veri aktarımını yönetmek için harcadığı süre hesaplandığında yıllık toplam maliyet ciddi bir rakama ulaşıyordu. Tek ERP geçişi sonrasında bu maliyet birinci yılda %46 oranında düştü; ancak bu kazanım ikinci yıldan itibaren gerçekleşti çünkü birinci yıl proje ve eğitim maliyetleri devreye girdi. ROI hesabını yaparken birinci yılı kırmızı kabul etmek ve kazanımı ikinci yıldan ölçmek, proje gerekçesini yönetim kuruluna anlatmanın en dürüst yoludur. Bu gerçeği baştan söylemeyen danışman, birinci yıl sonunda güvenilirliğini yitirir.Herhangi bir üretim ve ticaret şirketine tek ERP mimarisi önerisi götürüyorsanız, yazılım demosundan önce yapmanız gereken üç şey var. Birinci adım: üretim ve ticaret biriminin aynı masada oturduğu yarım günlük bir süreç haritalama seansı yapın ve ‘sipariş geldiğinde ne olur?’ sorusunu adım adım takip edin — her adımda kimin karar verdiğini yazın. İkinci adım: veri tanımlarındaki farklılıkları listeleyin; ölçü birimi, ürün kodu, fiyatlandırma yöntemi gibi temel alanlarda iki tarafın farklı çalışıp çalışmadığını sorun ve her farklılık için yazılı uzlaşma protokolü hazırlayın. Üçüncü adım: proje bütçesinin en az %25’ini yazılım lisansı değil, eğitim ve paralel çalışma dönemine ayırın. Bu üç adımı atlamış hiçbir ERP projesinin sahada başarılı sonuç verdiğini görmedim. Kayseri fabrikasında bunları sırayla uyguladık; sistem bugün çalışıyor ve muhasebe müdürü artık hafta sonları Excel açmıyor. Bu küçük bir ayrıntı gibi görünebilir — ama onun için kesinlikle değil.