Perakende Gıda Lojistiğinde Depo, Finans ve Dağıtım Entegrasyonu: Yazılım Değil Veri Sahipliği Sorunu

Ankara’nın kuzey sanayi bölgesinde, 284 çalışanıyla faaliyet gösteren orta ölçekli bir gıda dağıtım şirketini düşünün. Şirket; market zincirlerine, toplu tüketim noktalarına ve catering firmalarına günlük soğutmalı ve kuru gıda dağıtımı yapıyor. Muhasebe ayrı bir yazılım üzerinde çalışıyor, depo hareketleri başka bir programda tutuluyor, araç-rota takibi ise yöneticilerin elindeki Excel tablolarına dayanıyor. Sabah deposundan çıkan ürün ile akşam muhasebeye giren fatura arasında geçen sürede ne kadar kayıp olduğunu kimse tam olarak bilmiyor. Aylık kapanışlar üç ila dört günü buluyor çünkü her birim kendi kayıtlarını kendi mantığıyla tutuyor ve mutabakat neredeyse elle yapılıyor. Bu tablo Türkiye’deki çoğu orta ölçekli gıda dağıtıcısına tanıdık gelecektir. Mesele bir yazılım eksikliği değil; veri sahipliğinin kime ait olduğunun baştan netleştirilmemesidir.Bu bağlamda öne sürdüğüm tez şudur: Depo, finans ve dağıtım entegrasyonunda asıl kırılma noktası teknik mimari değil, hangi verinin nerede ve kimin tarafından üretileceğinin proje başlamadan belirlenmesidir. Sistem satın alındıktan sonra bu soru yanıtsız kalırsa en iyi yazılım bile bölünmüş kayıt kültürünü pekiştirmekten öteye geçemez. Türkiye’de bu sektörde yürütülen pek çok ERP projesinin ilk yılda fiilen kullanılmayan modüllerle sonuçlanmasının ardında bu belirsizlik yatıyor. Yazılım firmaları entegrasyonu teknik bir bağlantı sorunu olarak sunar; oysa saha gerçeği çok daha karmaşık bir organizasyonel meseleye işaret eder.Gıda dağıtımında entegrasyon üç farklı operasyon akışını kapsamak zorundadır: depo giriş-çıkış hareketleri, faturalama ve tahsilat döngüsü ile araç-rota-teslimat takibi. Bu üç akış ayrı sistemlerde yaşadığında her birimi kendi verisiyle kendi kararını vermek durumunda kalır. Depo sorumlusu stoğu programından kontrol eder; muhasebe sorumlusu faturayı kendi yazılımından keser; saha satış temsilcisi ise ertesi sabah ofise gelip teslimat bilgisini sözlü aktarır ya da el yazılı bir formla teslim eder. Bu üç noktadan üretilen veriyi birleştirmeye çalışmak, ancak ay sonunda raporlama aşamasında anlam kazanır — ve bu noktada zaten iş işten geçmiştir. Hata düzeltme maliyeti, hata önleme maliyetinin birkaç katına ulaşır. Yukarıda bahsettiğim Ankara şirketinde yapılan iç inceleme, teslimat başına fatura hatasının tüm sevkiyatların yaklaşık %57’sinde en az bir kayıt uyumsuzluğuna yol açtığını ortaya koydu; bu uyumsuzlukların büyük bölümü miktar farkı veya ürün kodu yanlışlığından kaynaklanıyordu.Finans ve muhasebe ayağında en kritik sorun iki başlık altında toplanır: tahsilat takibi ve stok maliyeti hesabı. Gıda dağıtımcıları müşterilerine genellikle 7 ila 30 gün arasında değişen vade tanır; bu vadeler ürün kategorisine ve müşteri büyüklüğüne göre farklılaşır. Muhasebe yazılımı bu vadeleri takip edebilir; ancak teslimatın gerçekleşip gerçekleşmediğini, iadeli mal olup olmadığını veya müşterinin parsiyel ödeme yapıp yapmadığını ancak depo ve satış verisinin muhasebe sistemine işlenmesiyle anlayabilir. Entegre olmayan ortamda bu bilgi e-posta veya telefon görüşmesiyle aktarılır; aktarım gecikir, eksik kalır ya da yanlış yorumlanır. Stok maliyeti hesabında da benzer bir sorun yaşanır: depodan çıkan ürünün hangi alış fiyatıyla maliyetleneceği, FIFO veya ağırlıklı ortalama yöntemlerinden hangisinin kullanıldığı soru işareti olmaya devam eder. Bu belirsizlik kâr-zarar tablosuna hatalı yansır ve yönetim kararlarını kirli veriyle besler.Dağıtım ayağı ise entegrasyonun en ihmal edilen kısmıdır. Araç çıkışından önce hazırlanan yükleme listesi ile müşterinin teslim aldığı ürün miktarı her zaman örtüşmez; gıda sektöründe kısmi iade, hasar bildirimi veya müşteri tarafından reddedilen ürün oldukça sık karşılaşılan durumlardır. Bu farkların aynı gün muhasebaya ve depoya yansıması, söz konusu dönemde çoğu orta ölçekli dağıtıcı için mümkün değildi. Saha temsilcisi akşam ofise döndüğünde elindeki teslimat formunu teslim ediyordu; form ertesi sabah veri girişi personeli tarafından sisteme işleniyordu. Bu gecikme birkaç iş günü boyunca stok bakiyelerini ve alacak kayıtlarını yanlış gösteriyordu. Bir İzmir catering tedarikçisindeki benzer bir projede ölçtüğümüz sonuç şuydu: iade ve fark kayıtlarının gerçek zamana göre ortalama 2,4 iş günü gecikmeli sisteme girdiği durumlarda, aylık tahsilat tahminlerindeki sapma gerçek rakamdan %73 oranına kadar uzanabiliyordu — bu kendi başına yönetim raporlamasını işlevsiz kılacak düzeyde bir rakamdır.Bu noktada karşı argümanı da masaya koymalıyım: entegre bir yazılım satın almak tek başına bu sorunları çözmez. Türkiye’de bazı dağıtım şirketleri ERP kurulumu yapıp birkaç ay sonra sistemin yalnızca muhasebe modülünde çalışır hale geldiğini gördü; depo ve dağıtım modülleri ise ya hiç devreye alınmadı ya da veriler elle girilmeye devam etti. Bunun nedeni teknik bir başarısızlık değildi. Veri girişinin kime ait olduğu baştan netleştirilmemişti: depocu veriyi kim girecek, saha temsilcisi teslimatı sisteme kim kaydedecek, iade formu nasıl işlenecek? Bu soruların yanıtı yazılım kurulumundan önce iş süreçleri düzeyinde belirlenmeli ve her birimi bağlayan bir veri akış haritası oluşturulmalıydı. Yazılım ancak bu haritanın üzerine oturduğunda işe yarıyor.Pazartesi sabahı ne yapılmalı sorusuna somut bir yanıt vermek gerekirse üç adımı öncelikli tutarım. İlk adım: sisteme dokunmadan önce bir teslimat döngüsünü başından sonuna kağıt üzerinde izleyin — sipariş alındığından tahsilat kapandığına kadar verinin hangi birimden hangi birime geçtiğini, her geçişte kimin sorumlu olduğunu ve gecikme ya da kayıp hangi noktada başladığını belirleyin. İkinci adım: muhasebe ve depo arasındaki veri senkronizasyonunu dosya aktarımı yöntemiyle bile olsa günlük yapın; elle mutabakat alışkanlığını kırmak için önce frekansı artırmak gerekiyor. Üçüncü adım: dağıtım iadelerini aynı gün kayıt altına alacak bir form ve sorumluluk protokolü belirleyin — saha temsilcisinin imzaladığı, müşteri kaşesiyle onaylanan bir kağıt form bile sisteme gecikmeli giren veriyi daha güvenilir kılar. Bu üç adım herhangi bir yazılım yatırımı gerektirmez; ancak yazılım yatırımının gerçekten işe yaraması için zemin hazırlar.Entegrasyon projelerinde en büyük zararı veren yanılgı, yazılımın kurulmasıyla işin bittiğini düşünmektir. Depodaki o yükleme listesi hâlâ el yazısıyla dolduruluyor, muhasebede ay kapanışı hâlâ üç günü buluyor ve saha temsilcisi hâlâ teslimat bilgisini sözlü aktarıyorsa sistem kurulu ama işlemiyor demektir. Ankara’daki o şirkette bu üç adımı uyguladıktan altı hafta sonra aylık kapanış süresi üç günden tam bir güne indi; teslimat başına kayıt uyumsuzluğu ise belirgin biçimde azaldı. Teknoloji burada araçtır — ama davranış dönüşmeden araç çalışmaz.