Sistemde sipariş var, tedarikçide söz var, sahada malzeme yok. Aradaki boşluk çoğu şirkette hiç yönetilmiyor.
Sipariş verildikten sonra kimse bakmıyor
Satın alma sürecinde en çok emek talep, teklif ve onaya harcanıyor. Sipariş verildiğinde iş bitmiş sayılıyor.
Halbuki sipariş bir taahhüt, teslimat değil. Aradaki süre boyunca kimsenin sahibi olmadığı bir alan oluşuyor.
Somut hali şöyle işliyor. Sipariş veriliyor, sistemde “açık” görünüyor. İki hafta sonra saha arıyor: malzeme nerede? Satın almacı tedarikçiyi arıyor, “yarın çıkıyor” cevabını alıyor. Bir hafta sonra aynı konuşma tekrarlanıyor. Üçüncü haftada malzeme geliyor ya da gelmiyor.
Bu süreçte hiçbir kayıt oluşmuyor. Ne gecikmenin kaç gün olduğu, ne tedarikçinin kaç kez söz verip tutmadığı, ne de sahanın kaç kez sorduğu.
Açık sipariş listesi neden ölüyor
Her sistemde bir açık sipariş listesi var. Çoğunda kimse ona bakmıyor ve sebepleri belli.
Kapanması gereken siparişler kapanmıyor. Tedarikçi kalan miktarı göndermeyecek ama sipariş eksik miktarla kapatılmadığı için listede duruyor. Aylar sonra listenin yarısı bu tür ölü kayıtlardan oluşuyor ve liste kullanılamaz hale geliyor.
Termin tarihi yok ya da gerçekçi değil. Sipariş verilirken bir tarih yazılıyor ama bu tarih genelde ihtiyaç tarihi, tedarikçinin verdiği söz değil. İkisi karışınca gecikme ölçülemiyor.
Gecikme uyarısı yok. Liste var ama kimse her gün açıp bakmıyor. Gecikmiş sipariş kendini göstermiyorsa liste pasif bir arşiv oluyor.
Kısmi teslimat izlenmiyor. 100 sipariş edilmiş, 60 gelmiş. Kalan 40 için sipariş hâlâ açık ama “ne kadar bekliyor” bilgisi elle takip ediliyor ve unutuluyor.
Termin tarihi ile ihtiyaç tarihi ayrı şeyler
Bu ayrım yapılmadığında takip anlamsızlaşıyor ve çok az şirket bunu ayırıyor.
İhtiyaç tarihi talep sahibinden geliyor: malzemeye ne zaman ihtiyaç var. Bu tarih talebin içinde duruyor.
Termin tarihi tedarikçiden geliyor: ne zaman teslim edeceğini söylüyor. Bu tarih siparişin içinde duruyor.
İkisi aynı olmak zorunda değil ve genelde olmuyor. Tedarikçi ihtiyaç tarihinden sonrasını söylüyorsa bu bir risk ve sipariş verilirken görülmesi gerekiyor. Sipariş verildikten sonra fark edilen bir tarih uyuşmazlığı, artık bir sorun.
Gecikme de bu iki tarihe göre farklı ölçülüyor. Tedarikçi kendi verdiği termini tutmadıysa bu bir tedarikçi performans sorunu. Termin ihtiyaç tarihinden sonraysa ama tutulduysa bu bir planlama sorunu. İkisi ayrı ayrı ele alınmalı, çünkü çözümleri farklı.
Listeyi canlı tutan düzen
İşleyen kurgularda birkaç ortak nokta var.
Termin tarihi siparişte zorunlu alan. Tedarikçi tarih vermediyse sipariş tam değil.
Gecikmiş siparişler kendini gösteriyor. Termin geçtiği anda sipariş listede ayrışıyor; kimsenin filtre kurmasına gerek kalmıyor.
Talep sahibi kendi siparişini görebiliyor. “Malzemem nerede” telefonu, cevabın ekranda olmasıyla kesiliyor. Bu madde küçük duruyor ama satın almacının gününün önemli bir kısmını geri veriyor.
Kısmi teslimat sipariş üzerinde izleniyor. Gelen ve kalan miktar otomatik güncelleniyor, elle takip edilmiyor.
Sipariş kapatma ayrı bir işlem olarak var. Tedarikçi kalanı göndermeyecekse sipariş eksik miktarla kapatılıyor ve kalan ihtiyaç için yeni bir talep açılıyor. Kapatma yetkisi tanımlı olmalı, yoksa ya hiç kapatılmıyor ya da gerçekten bekleyen siparişler kapatılıyor.
Ve gecikmeler tedarikçiye yazılıyor. Kayıt tutulmayan gecikme, bir sonraki teklif değerlendirmesinde yok sayılıyor.
Gecikmenin tedarikçi seçimine dönmesi
Açık sipariş takibinin asıl kazancı burada ortaya çıkıyor ve genelde geç fark ediliyor.
En ucuz teklifi veren tedarikçi, siparişlerini ortalama on gün geç teslim ediyorsa bu bir maliyet. Duran üretim, boş bekleyen ekip, acil alıma kaçılan kalemler. Hiçbiri teklif fiyatında görünmüyor.
Bu maliyeti görünür kılan tek şey gecikme kaydı. Zamanında teslim oranı tedarikçi bazında izleniyorsa, bir sonraki teklif değerlendirmesinde fiyatın yanına konabiliyor.
Kayıt yoksa değerlendirme satın almacının hafızasına kalıyor ve o hafıza hem eksik hem de kişi ayrıldığında şirketten çıkıyor.
Açık sipariş listesinde 900 satır vardı, 60’ı gerçekti
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Listenin nasıl öldüğünü gösteren bir örnek.
Bir beyaz eşya yan sanayi firmasında açık sipariş listesi 900 satırdı. Satın alma müdürü listeye bakmayı bırakmıştı, çünkü içinde ne olduğunu bilmiyordu.
Liste tarandığında şu çıktı. 410 satır, teslimatı tamamlanmış ama kapatılmamış siparişlerdi; kalan miktar sıfırdı ama kayıt açık duruyordu. 290 satır, tedarikçinin göndermeyeceği kalanlardı; iptal edilmesi gerekiyordu, kimse iptal etmemişti. 140 satır ise iki yıldan eskiydi ve karşılığında zaten alım yapılmıştı.
Gerçekten bekleyen sipariş sayısı 60 civarındaydı.
Bunun görünen maliyeti şuydu: bir kalem gecikince kimse fark etmiyordu, çünkü gecikmiş satırlar 840 ölü kaydın arasında kayboluyordu. Saha “malzeme nerede” diye aradığında satın almacı listeye değil tedarikçiye bakıyordu.
Temizlikten sonra iki kural konuldu. Teslimatı tamamlanan sipariş otomatik kapanıyor. Ve kalan miktarı gelmeyecek siparişler için kapatma, tanımlı bir yetkiyle yapılan ayrı bir işlem oldu.
Liste 60 satıra indi ve satın alma müdürü her sabah ona bakmaya başladı. Değişen şey sistemin özelliği değil, listenin okunabilir olmasıydı.
Codigno tarafında
Sipariş yönetimi tarafında sipariş onaylanan teklife bağlı olarak açılıyor, veriler yeniden girilmiyor. Kalem bazlı parametreler tutuluyor ve teslimata açma ile kapatma ayrı bir işlem olarak duruyor.
Bir talepten birden çok sipariş çıkabiliyor; geriye dönük izleme talep edenden tedarikçiye kadar korunuyor.
Teslim alım tarafında parçalı ve toleranslı teslim alım destekleniyor, yani eksik gelen miktar siparişte bekleyen olarak kalıyor ve elle takip edilmiyor.
Tedarikçi değerlendirme kayıtları süreçte yer alıyor: tedarikçi performans değerlendirme. Zincirin bütünü: satın alma yönetimi rehberi.
Açık siparişin nerede olduğu malzeme kartındaki kaynak izleme ekranından okunuyor: onayda bekleyen talep, satın almada bekleyen, onayda bekleyen sipariş, sipariş verilmiş, bekleyen sevk, teslim alınan ve bütçe miktarı proje proje ayrı duruyor. Teslimat bekleyenler ayrı bir ekran olarak da açılıyor, yani “hangi sipariş yolda” sorusu bir rapor beklemeden cevaplanıyor.
Sık sorulan sorular
Termin tarihi ile ihtiyaç tarihi neden ayrı tutulmalı?
Gecikmenin kaynağını ayırt edebilmek için. Tedarikçi kendi verdiği termini tutmadıysa bu performans sorunu; termin baştan ihtiyaç tarihinden sonraysa bu planlama sorunu.
Açık siparişler ne zaman kapatılmalı?
Kalan miktar gelmeyecekse hemen. Açık bırakılan ölü kayıtlar listeyi kullanılamaz hale getiriyor ve gerçekten bekleyen siparişler arada kayboluyor.
Sipariş kapatma yetkisi kimde olmalı?
Sınırlı tutulması gerekiyor. Herkesin kapatabildiği bir yapıda bekleyen siparişler yanlışlıkla kapanıyor; kimsenin kapatamadığı yapıda ise liste şişiyor.
Talep sahibi siparişin durumunu görebilmeli mi?
Görebilmesi, satın alma ekibine gelen takip telefonlarını doğrudan azaltıyor. Bu, sürecin en düşük maliyetli iyileştirmelerinden biri.
Gecikmeleri tedarikçiye nasıl yansıtmalı?
Zamanında teslim oranı olarak kaydedip teklif değerlendirmesinde fiyatın yanında göstererek. Sözleşmede gecikme yaptırımı varsa dayanağı da bu kayıt oluyor.
Kısmi teslimatta sipariş açık mı kalmalı?
Kalan gelecekse açık kalmalı ve bekleyen miktar görünmeli. Gelmeyecekse eksik miktarla kapatılıp kalan ihtiyaç için yeni talep açılmalı.
Açık sipariş listenizin kaçı gerçekten bekliyor? Aylık sipariş sayınızı ve listenizdeki en eski açık siparişin tarihini paylaşın; termin takibinin sizde nasıl kurulacağını gösterelim.
