Gıda Lojistiğinde SCM Projesi: 30 Bin Ürün ve 2.000 Noktayı Yönetmek

Gıda dağıtımında bir SCM projesi başlatmadan önce şu soruyu sormak gerekiyor: Kaç ürün kodunuz var — ve bunların kaçını gerçekten doğru tanımlayabiliyorsunuz? Bu soruyu 2005 yılının sonlarında, Ankara merkezli büyük ölçekli bir gıda dağıtım ve catering firmasında projeye başlarken sordum. Yanıt şaşırtıcıydı: sistemde kayıtlı 30.000’i aşkın ürün kodu vardı ama bunların önemli bir kısmı mükerrer girişlerden, yanlış tanımlanmış varyantlardan ya da uzun süredir raftan kalkmış kalemlerden oluşuyordu. Firma, günde ortalama 2.000 farklı teslimat noktasına dağıtım yapıyordu; hastaneler, okullar, toplu yemek sözleşmeli kurumlar, otel mutfakları. SCM yazılımı satın alınmış, kurulum tarihi belirlenmiş, proje ekibi toplanmıştı. Eksik olan tek şey temeldi.Bu makalede savunduğum tez şu: Gıda lojistiğinde SCM projelerinin büyük çoğunluğu, yazılım yetersizliğinden değil veri düzensizliği ve süreç belirsizliğinden tökezler. Yazılım seçimi doğru bile olsa, ürün master verisi temizlenmeden ve teslimat süreçleri net tanımlanmadan sisteme geçiş yapmak, eski karmaşayı yeni bir arayüzle yeniden üretmekten ibarettir. Bu, sektörde sık karşılaştığım ama nadiren açıkça konuşulan bir gerçek.Projenin ilk aşamasında yaptığımız iş teknik kurulum değil, veri denetimiydi. 30.000 ürün kodunu teker teker incelemek yerine, operasyon müdürüyle birlikte kuru gıda, soğuk zincir gerektiren ürünler ve temizlik-sarf malzemeleri olmak üç ana kategori belirledik. Bu sınıflandırma bile başlı başına küçük bir devrimdi; çünkü firma o güne kadar bütün ürünleri tek bir listede, aynı öncelik ve işlem mantığıyla yönetiyordu. Oysa soğuk zincirde taşınan bir süt ürünü ile kuru bir bakliyat aynı stok yönetimi mantığına tabi tutulamaz. Raf ömrü, depolama koşulu, araç tipi, teslimat önceliği hepsi farklılaşıyor. Bunu kağıt üzerinde söylemek kolay; ürün master verisini bu mantıkla yeniden yapılandırmak ise 6 haftayı buluyor.Teslimat noktalarındaki tablo da benzer bir karmaşıklık taşıyordu. 2.000 aktif teslimat adresi arasında adres bilgisi eksik ya da hatalı olan noktaların oranı, ilk kontrolde göründüğünden çok daha yüksekti. Bir kısmı kapanmış kurumları, bir kısmı farklı isimler altında mükerrer girilmiş adresleri temsil ediyordu. Satış ekibi bu bilgileri yıllardır kağıt sipariş formlarıyla veya telefon teyidiyle yönetiyordu; sistem yalnızca faturayı kesmek için kullanılıyordu, lojistik planlamayı yönlendirmek için değil. SCM’nin asıl değeri tam burada çıkıyor: rota optimizasyonu ve teslimat planlaması ancak temiz adres verisiyle çalışır. Kirli veriyle hesaplanan en iyi rota, gerçekte yanlış bir rotadır.Entegrasyon cephesinde ise farklı bir baskıyla karşılaştık. Firmanın muhasebe yazılımı ve depo yönetim sistemi ayrı platformlarda çalışıyordu; aralarında doğrudan bir veri akışı yoktu. SCM sistemi devreye girince bu iki platform arasında köprü kurmak gerekti. O dönemde bu tür entegrasyonlar genellikle ODBC bağlantısı ya da düzenli aralıklarla çalışan dosya aktarımıyla sağlanıyordu. Gerçek zamanlı veri akışı değil; gecelik veya saatlik toplu aktarım. Bu sınırı önceden kabul edip proje planına yansıtmazsanız, kullanıcılar SCM ekranında gördükleri stok rakamının muhasebedeki rakamla neden farklı olduğunu sormaya başlar — ve bu soruya tatmin edici bir yanıt vermekte güçlük çekersiniz. Benzer bir durumu Konya’daki bir gıda toptancısı projesinde de yaşadık; entegrasyon gecikmesi yüzünden sipariş onaylama süreçleri ilk iki ayda neredeyse felç oldu.Kullanıcı alışkanlıkları meselesine ayrıca değinmek gerekiyor. 312 kişilik operasyon ekibinin büyük çoğunluğu, günlük iş akışını telefon ve kağıt formları üzerinden yürütüyordu. SCM sistemi onlara hem bilgisayar başında vakit geçirmeyi hem de iş süreçlerini yeniden öğrenmeyi zorunlu kılıyordu. Bu değişime direncin en yoğun yaşandığı kesim, paradoks biçimde, en deneyimli saha çalışanlarıydı. Sistemi en az bilen kişi değil, eski yönteme en çok güvenen kişi değişime en güçlü direnci gösteriyor. Eğitim planlaması ve süreç geçiş takvimi bu gerçeği görmezden gelirse proje teknik olarak tamamlanmış ama operasyonel olarak benimsenmemiş kalır; bu durum lojistik sektöründe beklenenden çok daha sık yaşanır.Yönetim beklentileri konusunda da projenin başında net bir çerçeve çizmek gerekiyordu. Üst yönetim SCM projesinden iki şey bekliyordu: teslimat maliyetlerinde düşüş ve müşteri şikayetlerinde azalma. Bu ölçülebilir hedefler doğruydu ama beklenen sonucun hangi zaman diliminde gerçekleşeceği konusunda gerçekçi olmak gerekiyordu. Veri temizliği ve kullanıcı adaptasyonu tamamlanmadan rota optimizasyonundan anlamlı bir tasarruf beklemek erkendir. Bu projedeki deneyimimiz şunu gösterdi: sistemin fiilen devreye girmesinden itibaren ölçülebilir fayda ortaya çıkması yaklaşık 11 ay sürdü. İlk 4-5 ayda görünen şey verimlilik değil, görünürlüktür; hangi araç nerededir, hangi teslimat gecikmiştir, hangi ürünün stok devri yavaştır. Bu görünürlük başlı başına değerlidir ama maliyet tablosuna yansıması zaman alır.Benzer bir SCM projesine hazırlanan gıda dağıtım veya catering firması için ilk üç adımı net söyleyebilirim. Birincisi, yazılım satın almadan önce ürün master verinizi denetleyin; mükerrer kodları, tanımsız varyantları ve raftan kalkmış kalemleri temizlemeden sisteme geçmeyin. İkincisi, teslimat noktası veritabanınızı coğrafi olarak doğrulayın; adres hatası olan her satır rota hesaplamasını bozar. Üçüncüsü, mevcut yazılımlarınızla entegrasyon yöntemini ve sınırını en başta belgeleyin; gerçek zamanlı mı, toplu aktarım mı, hangi aralıkla — bu soruların yanıtı proje başlamadan netleşmeli. Ankara’daki o gıda dağıtım firması bu adımları sabırla attı ve 11 ay sonra rota başına düşen ortalama teslimat maliyetinde görünür bir iyileşme elde etti. Sabırsız davrananlar ise sistemi açık tutup eski kağıt formlarını da sürdürmeye devam etti — ki bu, iki dünyada birden yaşamanın en yorucu halidir.