Çikolata Lojistiğinde ERP: Paketleme Varyantları Stok Modülünü Değil, Maliyet Görünürlüğünü Çözer

Şunu sormak gerekiyor: Bir gıda üreticisi ERP kuruyor, stok modülü canlıya alınıyor, raporlar ekranda görünmeye başlıyor — peki yöneticinin masasına gelen rakamlar neden hâlâ tutmuyor? Konya’daki orta ölçekli bir çikolata ve şekerleme üreticisinde tam da bu soruyla karşılaştım. Firma, 312 çalışanıyla hem iç piyasaya hem Orta Doğu ve Kuzey Afrika pazarlarına ürün gönderiyordu; aynı çikolata tableti Türkiye’de ayrı bir ambalajla, ihracat kanalında farklı gramaj ve dil kombinasyonlarıyla raflara giriyordu. Proje başladığında herkes ‘stok takibi artık düzgün olacak’ diyordu. Ama asıl sorun stok takibi değildi. Asıl sorun yeniden paketleme operasyonunun ne kadara mal olduğunun hiç bilinmemesiydi.ERP projelerinde gıda sektörünün kendine özgü bir karmaşıklığı var: ürün, fabrikadan çıktığı haliyle müşteriye ulaşmıyor. Özellikle çikolata gibi mevsimsel, hediye paketi varyantları yüksek ve ihracat kanalında etiket değişikliği zorunlu olan ürünlerde bu mesafe çok daha uzun. Temel ürün —diyelim ki 100 gramlık sütlü çikolata tableti— depoya giriyor, bir süre sonra oradaki bir operasyon ekibi onu Ramazan özel kutusuna, Bayram sepetine veya ihracat karton kolisine yeniden düzenlemiş oluyor. Bu operasyon için sarf edilen ambalaj malzemesi, insan gücü ve depo alanı maliyeti sisteme girilmiyor; sadece ‘depo içi transfer’ olarak geçiştiriliyor. Sonuç: ürün maliyeti ile satış fiyatı arasındaki marj hesabı sürekli yanıltıcı çıkıyor. Yönetici ekranındaki ‘kârlı görünen’ bir ihracat siparişi, yeniden paketleme dahil edilince zarar yazıyor.Bu firma için asıl kırılma noktası, ERP’nin stok modülünü canlıya almadan önce yeniden paketleme operasyonunu bir ‘iş emri’ (work order) mantığıyla tanımlamak oldu. Yani sistem şunu sormalıydı: Bu ambalaj dönüşümü için hangi girdiler tüketildi, kaç adam-saat harcandı, hangi hammadde kalemi stoktan düştü? Bunu yapmadan önce operasyonun kendi içinde standart bir akışı yoktu; her sipariş farklı bir yöntemle işleniyordu. Deneyimli bir depo sorumlusu neyin nereye gittiğini kafasında taşıyor, ama bu bilgi hiçbir yerde yazılı değildi. ERP burada ‘sistemi otomatize etmek’ için değil, önce bu bilgiyi yüzeye çıkarmak için bir araç oldu. Modeli kağıt üzerinde yazdık, tartıştık, bölüm müdürleriyle defalarca gözden geçirdik; sonra sisteme girdik.Uluslararası raporlama meselesi ise projenin ikinci büyük gerilimine neden oldu. Firmanın Körfez bölgesindeki distribütörleri, her ay ürün bazında satış raporu istiyordu; üstelik bu raporların Euro ve Dolar bazında iki ayrı versiyonu gerekiyordu. O dönemde bu talep Excel üzerinden karşılanıyordu: muhasebe birimi kuru elle giriyor, satış ekibi tabloya aktarıyor, genel müdür imzalıyor, e-posta ile gönderiliyordu. Haftalık ortalama üç saat salt bu işe ayrılıyordu. ERP kurulduktan sonra döviz çevirimi otomatik hale geldi, ürün bazında raporlar parametrik biçimde alınabilir oldu. Ama burada da kritik bir soru vardı: Sistemdeki ürün kodları distribütörlerin kullandığı kodlarla uyuşuyor muydu? Hayır, uyuşmuyordu. Üç ay boyunca paralel çalışma yaptık; iki tarafın kodlama mantığını eşleştirdik ve ancak ondan sonra raporlama otomasyonu gerçek değer üretmeye başladı. Bu eşleştirme adımı proje planında yoktu; sahadaki ilk görüşmede ortaya çıktı.Türkiye’deki gıda üreticilerinin büyük çoğunluğu —özellikle paketleme çeşitliliği yüksek olanlar— ERP projesine ‘stoku takip edeceğiz’ motivasyonuyla başlar. Bu motivasyon yanlış değil, ama yetersiz. Asıl kazanım stok takibinden değil, stok hareketinin arkasındaki maliyet mantığının görünür hale gelmesinden geliyor. Konyalı bu firma, yeniden paketleme iş emirlerini sisteme entegre ettiğinde, Ramazan özel kutusunun gerçek birim maliyetinin standart tabletten %53 daha yüksek olduğunu ilk kez rakamla gördü. Bu rakamı o ana kadar kimse bilmiyordu; ‘zaten pahalı oluyor’ diye sezgiyle biliniyor ama fiyatlamaya yansıtılmıyordu. Artık distribütöre teklif verirken farklı bir masaya oturuyorlardı. Bunun yanı sıra e-Beyanname entegrasyonu için de altyapı hazırlandı; gümrük ve vergi işlemleri için gereken kalem bazlı veriler ERP’den doğrudan beslenebilir hale geldi. Küçük ama işlevsel bir adım; 2006 Türkiye’sinde gıda ihracatçıları için hâlâ değerli olan bir kolaylık.Peki bu proje kolay mıydı? Hayır. En büyük direnci beklenmedik bir yerden aldık: satış ekibinden. Satış ekibi, ihracat fiyat tekliflerini her zaman kendi Excel tablolarında hazırlıyordu; bu tablolarda bazı marjlar kasıtlı olarak farklı tutuluyordu — ‘müşteri bazında inisiyatif’ denilen şey. ERP sistemi merkezi bir fiyat mantığı getirince bu esneklik daraldı. İki ay boyunca ‘sistem yanlış çalışıyor’ şikayetleri aldık; ama incelediğimizde sistemin doğru çalıştığını, sadece önceki alışkanlıkla örtüşmediğini görüyorduk. Bu gerilim, projenin teknik değil organizasyonel bir mesele olduğunu bir kez daha hatırlattı. ERP bir muhasebe aracı olarak görüldüğünde satış ekibi onu dışarıdan izliyor; karar aracı olarak konumlandırıldığında ise masaya oturuyorlar — ama bu oturuş her zaman kolay başlamıyor.Çikolata lojistiğinde ERP uygulayacak bir yöneticiye şunu söyleyebilirim: Projeye başlamadan önce şu üç sorunun yanıtını kağıda dökün. Birincisi, yeniden paketleme operasyonunuz var mı ve bu operasyonun iş emri mantığında tanımlanmış bir akışı var mı? Yoksa önce bu akışı kağıda yazın, sisteme sonra girin. İkincisi, uluslararası raporlama için distribütör veya alıcınızın kullandığı ürün kodlama mantığı sizinkiyle örtüşüyor mu? Örtüşmüyorsa bu eşleştirmeyi proje planına bir adım olarak ekleyin; aksi takdirde canlıya geçişten üç ay sonra ‘raporlar tutmuyor’ sorunuyla uğraşırsınız. Üçüncüsü, satış ekibinin fiyatlama inisiyatifini nasıl yönettiğini ve ERP’nin bu inisiyatifi nasıl etkileyeceğini baştan konuşun. Bu konuşma yapılmadan geçilen proje, teknik açıdan başarılı ama organizasyonel açıdan sahipsiz kalır. Konya’daki o depo sorumlusunun kafasındaki bilgi değerliydi — sadece orada kalmaması gerekiyordu.