Bir şantiyede fazlası duruyor, diğeri aynı malzemeyi satın alıyor. İkisi de doğru davranıyor, çünkü ikisi de diğerini görmüyor.
Görünmeyen stok, gereksiz alım
Çok lokasyonlu çalışan her işletmede aynı tablo var.
Merkez depo, üç şantiye deposu, bir de yedek parça deposu. Malzeme sürekli bunlar arasında dolaşıyor. Bir şantiye kapanırken malzemesi başka bir şantiyeye gidiyor, üretimden artan hammadde merkeze dönüyor.
Bu hareketlerin bir kısmı kaydediliyor, çoğu kaydedilmiyor. Kamyon gidiyor, kayıt gitmiyor.
Sonuçlar üç yerde birden çıkıyor.
Malzeme “kayboldu” görünüyor. Aslında kaybolmadı, başka bir şantiyede duruyor ama sistemde ilk depoda görünüyor.
Aynı malzeme yeniden alınıyor. B şantiyesi ihtiyaç duyduğu kalemin A şantiyesinde durduğunu görmüyor ve satın alma talebi açıyor.
Ve sayım tutmuyor. Bir depoda eksik, diğerinde fazla çıkıyor, toplam doğru ama hiçbir depo kaydı güvenilir değil.
Neden kaydedilmiyor
Sebepler işin akışından geliyor, ihmalden değil.
Transfer genelde acil bir ihtiyaçla oluyor. “Sende var mı, gönder” telefonuyla başlıyor. Kamyon çıkıyor, kayıt sonraya kalıyor ve sonra unutuluyor.
İkincisi, transferin iki ayrı işlem olarak kurgulanmış olması. Gönderen depo çıkış yapıyor, alan depo giriş yapıyor. Aradaki sürede malzeme hiçbir yerde görünmüyor. Alan taraf girişi yapmadıysa malzeme sistemden tamamen kayboluyor.
Üçüncüsü, kaydı yapacak kişinin elinde araç olmaması. Şantiye deposunda bilgisayar yoksa kayıt merkeze telefonla bildiriliyor ve arada eksiliyor.
Dördüncüsü, transferin bir onaya bağlanmış olması. Onay bekleyen bir transfer, malzeme çoktan gitmişken sistemde beklemeye devam ediyor.
Yoldaki malzeme
Doğru kurgunun temel farkı burada: transfer tek bir hareket olarak tutuluyor ve malzemenin “yolda” olduğu bir durum bulunuyor.
Gönderen depodan çıkış yapıldığı anda malzeme o depodan düşüyor ama alan depoya henüz girmiyor. Yolda görünüyor.
Alan depo teslim aldığında kabul ediyor ve malzeme oraya giriyor.
Bu üç durumun olması iki şey sağlıyor. Malzeme hiçbir anda kaybolmuyor. Ve eksik ya da hasarlı gelen transferler görünür oluyor: gönderilen 100, teslim alınan 92 ise fark kayda geçiyor.
İkinci nokta çoğu şirkette hiç yönetilmiyor. Depolar arası transferde eksik çıkan malzeme, tedarikçiden eksik gelen malzemeden çok daha az sorgulanıyor.
Talep açmadan önce diğer depoya bakmak
Transferin satın almayı doğrudan etkilediği yer burası.
Talep açılırken diğer lokasyonlardaki stok görünüyorsa, satın alma hiç başlamıyor. Talep bir transfer talebine dönüşüyor.
Bunun işlemesi için iki şart var.
Birincisi, stok kaydının güvenilir olması. Diğer depoda göründüğü halde gerçekte olmayan malzeme, transfer talebi açtırıp sonra hayal kırıklığı üretiyor. Bir kez bunu yaşayan kullanıcı bir daha bakmıyor.
İkincisi, transferin satın almadan hızlı olması. Aynı şehirdeki iki depo arasında transfer bir günse mantıklı. İki farklı şehirdeki şantiyeler arasında nakliye üç gün ve maliyetliyse, yerel tedarikçiden almak daha ucuz olabiliyor.
Yani transfer her zaman doğru cevap değil. Doğru olan, kararın verilebilmesi için bilginin görünür olması.
e-İrsaliye tarafı
Kendi şubeleriniz ve depolarınız arasındaki sevkiyat da sevk irsaliyesi yükümlülüğü kapsamında. Aynı vergi kimlik numarası altındaki transferlerde de belge düzenlenmesi gerekiyor.
Bu, uygulamada en sık atlanan durum. “Kendi malımı kendi depoma gönderiyorum” düşüncesiyle belge düzenlenmiyor.
e-İrsaliye kapsamındaki mükellefler için bu yükümlülük elektronik ortamda sürüyor. Depolar arası malzeme hareketi yoğun olan işletmelerde bu tek başına ciddi bir belge hacmi yaratıyor.
Bunun operasyonel sonucu şu: transfer kaydı ile belge üretimi aynı adımda olmalı. Ayrı yürütüldüğünde ya belge unutuluyor ya da kayıt.
Kapsam ve teknik ayrıntılar için güncel düzenlemeye ya da entegratörünüze bakmanız gerekiyor.
Bir şantiyede fazla kalıp paneli, diğerinde satın alma
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Görünürlüğün tek başına ne kazandırdığını gösteren bir örnek.
Bir inşaat firması aynı dönemde iki şantiye yürütüyordu. Birinci şantiyede kaba yapı bitmiş, kalıp panelleri boşa çıkmıştı. İkinci şantiye ise kaba yapıya yeni başlıyordu.
İkinci şantiyenin şefi panel talebi açtı. Merkez satın alma talebi karşıladı ve kiralama yoluna gitti.
Aynı hafta birinci şantiyeden merkeze soruldu: bu paneller ne olacak, yer kaplıyor.
İki bilgi aynı firmada, aynı hafta, iki ayrı yerde duruyordu ve bir araya gelmedi. Bir tarafta ihtiyaç, diğer tarafta atıl malzeme.
Bunun sebebi ilgisizlik değildi. Birinci şantiyenin malzemesi sistemde kayıtlı değildi, çünkü şantiye deposu takip edilmiyordu; malzeme merkezden çıktığında doğrudan gider yazılmıştı. İkinci şantiye şefinin bakabileceği bir yer yoktu.
Değişen şey, şantiye depolarının da birer lokasyon olarak tanımlanması oldu. Malzeme merkezden çıkarken gider yazılmıyor, şantiye deposuna giriyor.
Talep açma ekranında diğer lokasyonların stoğu görünür hale geldiğinde ilk üç ayda dört transfer yapıldı ve bunların üçü satın alma talebi olarak açılmıştı.
Bir uyarı da eklemek gerekiyor: transfer her zaman ucuz değil. İki şantiye arasındaki mesafe uzunsa nakliye, yerel alımdan pahalıya gelebiliyor. Sistem kararı vermiyor, kararı verilebilir hale getiriyor.
Codigno tarafında
Depo ve stok yönetimi tarafında çok lokasyonlu stok, depo rezervasyonu, masraf merkezi bağı ve gelişmiş depo yetkileri bulunuyor.
Alternatif malzeme birimi tanımlanabiliyor; farklı birimlerle takip edilen depolar arasında transfer doğru dönüşüyor.
Talep tarafında farklı lokasyonlardan gelen ihtiyaçlar ortak bir havuzda toplanıyor. Aynı malzemenin farklı lokasyonlardaki talepleri yan yana görülüyor; transfer kararının çıktığı yer burası.
Şantiye tarafı: şantiyede malzeme talebi. Zincirin bütünü: satın alma yönetimi rehberi.
Malzeme kartındaki kaynak izleme ekranı proje proje şu kolonları ayrı ayrı veriyor: onayda bekleyen talep, satın almada bekleyen, onayda bekleyen sipariş, sipariş verilmiş, bekleyen sevk, teslim alınan ve bütçe miktarı. Yani “sipariş verildi ama gelmedi” miktarı stoktan ayrı ve açıkça görünüyor; bir depo kendi ihtiyacını istemeden önce yoldakini görebiliyor. Teslimat bekleyenler ayrı bir ekran olarak da duruyor.
Sık sorulan sorular
Transfer neden tek hareket olarak kaydedilmeli?
Ayrı çıkış ve ayrı giriş kaydedildiğinde malzeme aradaki sürede hiçbir yerde görünmüyor. Alan taraf girişi yapmazsa malzeme sistemden tamamen kayboluyor.
Yolda görünen malzeme neden gerekli?
Hem malzemenin kaybolmasını engelliyor hem de eksik ya da hasarlı gelen transferlerin görünmesini sağlıyor.
Transfer onaya bağlanmalı mı?
Ağır bir onay süreci transferi yavaşlatıyor ve malzeme onay beklerken çoktan gitmiş oluyor. Yaygın kurgu, transferin kayda bağlı olması ama akışı durdurmaması.
Talep açılırken diğer depoların stoğu görünmeli mi?
Görünmesi gereksiz alımı doğrudan azaltıyor. Ancak stok kaydının güvenilir olması şart; yanlış bilgiye dayanan transfer talebi, kullanıcının bir daha bakmamasına yol açıyor.
Şubeler arası transferde e-irsaliye gerekiyor mu?
Aynı vergi kimlik numarası altındaki depolar ve şubeler arası sevkiyatlar da sevk irsaliyesi yükümlülüğü kapsamında. Kendi durumunuz için güncel düzenlemeye ya da entegratörünüze bakmanız gerekiyor.
Transferde eksik çıkan malzeme nasıl kaydedilmeli?
Tedarikçiden eksik gelen malzemeyle aynı mantıkla: gönderilen ve teslim alınan miktar ayrı ayrı tutulup fark kayda geçirilerek.
Bir şantiyede fazlası duran malzemeyi diğeri görebiliyor mu? Depo ve şantiye sayınızı, aylık transfer hacminizi paylaşın; transfer ve stok görünürlüğünün sizde nasıl kurulacağını gösterelim.
