Cross-Dock Depo Yapılarında ERP Tasarımı: Stok Mantığını Neden Baştan Kurmanız Gerekiyor?

Bir deponun içinden mal geçiyorsa, o malı stoklamıyorsunuz demektir. Bu cümle basit görünüyor; ama ERP kurulum projelerinde tam bu noktada en çok yanlış yapılıyor. Cross-dock yapısı, yani malın depo rafına kaldırılmadan doğrudan gelen araçtan giden araca aktarıldığı model, yazılım tarafında çoğunlukla ‘stok girişi yapılır, anında stok çıkışı yapılır’ biçiminde kurgulanıyor. Bu kurgu teknik olarak çalışıyor, ama işletmeye hiçbir şey söylemiyor. Hangi sipariş hangi sevkiyatla eşleşti, hangi tedarikçi aracı kaç dakika bekledi, hangi ürün lot’u hangi müşteriye gitti — bunların hiçbiri bu kurgudan çıkmıyor. Tez şu: cross-dock ERP tasarımı, standart depo mantığının daha hızlı bir versiyonu değildir; sevkiyat eşleştirme ve iş emri yönetimi ekseninde sıfırdan kurulması gereken ayrı bir veri akışıdır. Bunu klasik stok modülüyle yamamaya çalışmak projeyi baştan yanlış kurmaktır.Cross-dock yöntemi lojistik ve perakende dağıtımında onlarca yıldır kullanılıyor; ama Türkiye’deki yapı malzemeleri ve inşaat sektörü bu modeli kendi koşullarıyla biçimlendiriyor. Çimento, demir, seramik veya alçıpan gibi ürünlerde tedarikçi araçları sıklıkla fabrikadan doğrudan bölge deposuna geliyor. Mal oraya kaldırılmıyor — aynı gün ya da ertesi gün şantiyeye veya bayi deposuna aktarılıyor. Bu süreç görünürde hızlı. Ama ERP tarafında bakıldığında ‘giren-çıkan’ kaydından ibaret kalıyor; hangi projeye, hangi siparişe, hangi araç hareketiyle bağlı olduğu kaybolup gidiyor. Stok modülü bu bağlantıyı kurmak için tasarlanmamış. Stok modülü ‘ne kadar var?’ sorusunu yanıtlar; cross-dock ise ‘nereye gidiyor ve ne zaman’ sorusunu yanıtlamak zorundadır. Bu iki soru birbirinden çok farklı bir veri mimarisi gerektiriyor.Ankara’da yapı malzemeleri dağıtımı yapan, 284 çalışanı olan orta ölçekli bir distribütörde bu sorunu yakından gördüm — bu anonim bir vaka, firmanın gerçek adını paylaşmıyorum. Firma iki büyük çimento tedarikçisinden günde ortalama 6 ile 9 araç alıyordu; bu araçlar depo sahasına giriyor, yükün bir kısmı iniyordu, geri kalan kısmı ise o gün hareket edecek müşteri araçlarına yükleniyordu. ERP’de kayıt şöyle yapılıyordu: tam giriş, tam çıkış. Sonuç: stok hiçbir zaman gerçek durumu yansıtmıyordu. Ay sonunda yapılan sayımda sistemdeki rakamla fiziksel rakam arasında %57’lik bir fark çıkıyordu — bu farkın büyük bölümü kayıp değil, geçişte olan maldı; ama sistem bunu göremiyordu. Muhasebe bu farkı kapamak için manuel düzeltme girişi yapıyordu. Her ay, her seferinde, aynı işi tekrar tekrar.Doğru ERP tasarımı bu firmada şu üç adımla kuruldu. Birinci adım, cross-dock hareketini stok hareketi olarak değil, sevkiyat eşleştirme (transfer order) olarak tanımlamaktı. Tedarikçi aracının içindeki mal, sisteme girmeden önce müşteri siparişine veya proje koduna atandı. Giriş kaydı ancak bu atama tamamlandıktan sonra oluştu. İkinci adım, depo sahasına araç kabul terminali olarak çalışacak bir bilgisayar istasyonu kurmaktı — 2006 koşullarında bu yerel ağa bağlı masaüstü bir bilgisayardı; web tabanlı erişim henüz bu firmada yoktu. Depo görevlisi araç plakasını ve beklenen yükü bu ekrandan sisteme bildirdi; böylece ERP, araç sahada beklerken eşleştirme sürecine başlayabildi. Üçüncü adım, çıkış kaydının araç kapı çıkışıyla eşzamanlı üretilmesi için basit bir onay akışı oluşturmaktı. Bu üç adım birlikte çalışınca stok farkı bir sonraki ay %57’den %8’e düştü. Kalan %8 gerçek sayım farklarıydı.Bu tasarımın işe yarayıp yaramayacağı büyük ölçüde ERP’nin iş emri veya transfer belgesi üretip üretemediğine bağlıdır. Bazı yerli ERP ürünleri 2006 itibarıyla bu işlevselliği modül olarak sunuyordu; ama konfigürasyon gerektiriyordu ve standart stok akışıyla çakışma riski vardı. SAP veya daha kapsamlı uluslararası sistemler bu ayrımı daha temiz yapabiliyordu, ancak KOBİ bütçesiyle bu sistemlere girmek çoğu zaman mümkün değildi. Pratik seçenek şuydu: kullandığınız ERP’nin depo hareketleri veya irsaliye modülündeki belge tiplerini cross-dock mantığına göre yeniden tanımlamak. Bu yeniden tanımlama bazen haftalarca süren bir konfigürasyon ve test sürecini gerektiriyordu; ama sonuç, üzerine üç ay daha yama yapılmış standart bir kurulumdan çok daha temizdi. Entegrasyon noktası olarak baktığınızda, muhasebe modülüyle bağlantı da bu tanımlamadan beslendiğinde maliyet takibi ilk kez gerçeği yansıtmaya başlıyordu.Şunu da açıkça söylemek gerekiyor: bu tasarım her cross-dock yapısında aynı sonucu vermez. Eğer mal akışı tam anlamıyla çapraz değilse — yani bazı ürünler rafta kalıyor, bazıları geçiyorsa — hibrit bir durum söz konusu ve bu hibridin ERP’de doğru ayrıştırılması çok daha zor. Karma depolarda cross-dock ile geleneksel stok hareketi aynı modülde yönetilmeye çalışıldığında kullanıcılar hangi belge tipini kullanacağını şaşırıyor ve çoğu zaman her ikisini de karıştırıyor. Bu karışıklık aylarca sürebiliyor. O zaman tek yol, iki hareketi fiziksel olarak da birbirinden ayrıştırmak — farklı depo bölgesi, farklı belge tipi, farklı onay akışı. Fiziksel ayırım olmadan yazılımda ayırım sürdürülemiyor.Cross-dock için ERP tasarlarken kendinize şu soruyu sorun: bu yazılım ‘kaç birim var?’ sorusunu mu çözüyor, yoksa ‘hangi sipariş hangi araçla buluştu?’ sorusunu mu? Eğer ikincisini yanıtlayamıyorsa, stok kayıtları her ay düzeltilmek zorunda kalacak ve muhasebe gerçeği geç öğrenmeye devam edecek. Tasarım kararını bu soruya göre verin; yazılımın mevcut konfigürasyonunu değil, işletmenin ihtiyacını esas alın.