Müşteri arar: "Siparişim ne durumda?" Cevap genelde birkaç telefon sonra bulunur — depoya sorulur, üretime sorulur, sevkiyata bakılır. Bu üç dakikalık arama, sipariş durumunun tek yerde tutulmadığının işaretidir.
Sipariş alınmadan önceki aşamayı yöneten katman CRM'dir; devir noktasını burada anlattık.
Sipariş takibinin temeli, siparişin hangi aşamada olduğunun net tanımlanmasıdır. Aşamalar işletmeye göre değişir ama tipik zincir şudur:
| Aşama | Ne anlama gelir | Kim günceller |
|---|---|---|
| Teklif | Fiyat verildi, onay bekleniyor | Satış |
| Onaylandı | Müşteri kabul etti, iş başlayabilir | Satış |
| Planlandı | Üretim veya tedarik programına alındı | Planlama |
| Üretimde / Tedarikte | İş emri açık veya satın alma siparişi verildi | Üretim / satın alma |
| Hazır | Mal hazır, sevkiyat bekliyor | Depo |
| Sevk edildi | İrsaliye kesildi, yola çıktı | Sevkiyat |
| Faturalandı | Fatura kesildi, cariye işlendi | Muhasebe |
| Kapandı | Teslim ve tahsilat tamamlandı | Sistem |
Aşamaları çok detaylandırmak yaygın bir hatadır. On beş aşamalı bir akışta kimse durumu güncel tutmaz; sekiz-on aşama çoğu işletme için yeterlidir. Kural şu: bir aşama ancak farklı bir kişi veya bölüm sorumluysa ayrı olmalıdır.
Müşteriye tarih verirken en yaygın yaklaşım tecrübeye dayalı tahmindir. Sorun, tahminin kapasiteyi görmemesidir: aynı hafta için üç müşteriye söz verilmiş olabilir ve bu ancak teslim haftası fark edilir.
Hangi hafta ne kadar iş yüklü — yeni sipariş bu tabloya eklenerek değerlendirilmeli. Kapasite görünmüyorsa verilen tarih temenniden ibarettir.
Üretim tarihi, malzemenin geleceği tarihten önce olamaz. MRP bu geri hesabı otomatik yapar; elle yapıldığında tedarik süresi genelde iyimser tahmin edilir.
Termin sistemde tutulmazsa gecikme de ölçülemez. "Zamanında teslim oranı" ancak söz verilen tarih kayıtlıysa hesaplanabilir.
Termin ile gerçekleşen teslim arasındaki fark dönemsel raporlanmalı. Sürekli geciken ürün grubu varsa sorun tahminde değil süreçtedir.
Sipariş 100 adet, elde 60 adet var. Kısmi sevkiyat yapılırsa siparişin 60 adedi kapanır, 40 adedi açık kalır. Bu bakiye takip edilmezse iki sorun çıkar: müşteri kalanı bekler ama sistemde iz yoktur; ya da kalan ikinci kez üretilir.
Doğru kurgu, sipariş satırı bazında sevk edilen ve kalan miktarın ayrı tutulmasıdır. Faturalama da bu bakiyeye göre yapılır — sevk edilmemiş miktar faturalanmaz.
Sipariş durumunu müşterinin kendisinin görebilmesi, gelen "ne durumda" telefonlarını belirgin biçimde azaltır. Bayi veya kurumsal müşterilerle çalışıyorsanız portal üzerinden durum paylaşımı yaygın bir çözümdür.
Görünürlük iki taraflı fayda sağlar ama bir şartla: durum bilgisi güncel olmalıdır. Yanlış "hazır" bilgisi, hiç bilgi vermemekten daha çok güven kaybettirir. Portal açmadan önce iç güncelleme disiplininin oturduğundan emin olun.
Tüm aşamaları birden devreye almaya çalışmayın. En kritik iki aşamayla başlayın — genelde onaylandı ve sevk edildi. Bu ikisi bile "sipariş ne durumda" sorusunun büyük kısmını cevaplar. Ara aşamalar, ekip alıştıkça eklenir. Bu başlangıcı bir e-tabloyla yapacaksanız sütunların nasıl kurulacağını ücretsiz sipariş takibi rehberimizde adım adım anlattık.
Sipariş takibi tek başına durmaz; stok, üretim ve belge süreçleriyle birlikte kurulur. Tüm başlıkları dijitalleşme rehberinde topladık.
Genelde gerekmez. Sipariş takibi ön muhasebe veya ERP'nin parçasıdır; ayrı bir program kullanmak sipariş, stok ve cari verisinin ayrışmasına yol açar. Önemli olan siparişin stok ve faturayla aynı sistemde bağlantılı olmasıdır.
Sekiz-on aşama çoğu işletme için yeterlidir. Kural şudur: bir aşama ancak farklı bir kişi veya bölüm sorumluysa ayrı olmalı. Çok detaylı akışlarda kimse durumu güncel tutmaz ve sistem gerçeği yansıtmaz hale gelir.
Sipariş satırı bazında sevk edilen ve kalan miktar ayrı tutulmalıdır. Böylece siparişin ne kadarının kapandığı, ne kadarının açık olduğu görünür; faturalama da sevk edilen miktara göre yapılır.
Kapasite ve malzeme durumuna göre. Kapasite görünmeden verilen tarih tahmindir; aynı haftaya birden fazla söz verilmiş olabilir. Malzeme tarafında ise üretim tarihi, malzemenin geleceği tarihten önce olamaz — bu geri hesabı MRP otomatik yapar.
Söz verilen termin tarihi sistemde kayıtlıysa, gerçekleşen teslim tarihiyle karşılaştırılır. Termin kaydedilmiyorsa bu oran hesaplanamaz — ölçmek isteyen işletmenin ilk yapması gereken şey terminleri kayda geçirmektir.
Gelen "ne durumda" sorularını azaltır ve güven verir; ancak durum bilgisinin güncel olması şarttır. Yanlış bilgi hiç bilgi vermemekten daha çok zarar verir. Portal açmadan önce iç güncelleme disiplininin oturduğundan emin olun.
Teklif, onay, üretim, sevkiyat ve fatura aynı zincirde tutulduğunda "ne durumda" sorusu telefonla değil ekrandan cevaplanır.