Satın alma sorumlusu her hafta aynı tabloya bakar: hangi üründen ne kadar sipariş verilecek. Genelde cevap raftaki miktara, biraz da hafızaya dayanır — "geçen ay bu kadar sattık, yine o kadar alalım." Bir hafta stok elde kalır, bir hafta müşteri "elimizde yok" cevabıyla karşılaşır. İkisi de aynı kaynaktan gelir: sipariş miktarı, veriden değil sezgiden çıkıyordur.
Bu yazı, stok ve satın alma kararının sezgiden veriye nasıl taşındığını; yeniden sipariş noktası ve talep tahmininin ERP'de somut olarak nasıl çalıştığını anlatıyor.
Sipariş miktarı kararı neden hâlâ tecrübeye kalıyor?
Çoğu işletmede stok siparişi üç kaynaktan birinden çıkar: satın alma sorumlusunun tecrübesi, geçen yılın aynı dönemi veya tedarikçinin "şu kadar alırsan indirim yaparım" teklifi. Üçü de bir noktaya kadar işe yarar, ama hiçbiri talebin gerçekte nasıl değiştiğini ölçmez.
Sonuç iki uçta görülür:
- Fazla stok, nakdi depoda bekletir; özellikle hızlı bozulan veya modası geçen üründe doğrudan zarara döner.
- Stok tükenmesi, satışı kaçırmakla kalmaz — sürekli tekrarlarsa müşteri başka bir tedarikçiye yönelir.
İkisi arasındaki denge, elle takip edilebilecek kadar basit değil. Yüzlerce stok kartı, farklı tedarik süreleri ve mevsimsel dalgalanma bir arada olduğunda, tecrübeyle karar vermek gitgide daha büyük bir risk taşır.
Yeniden sipariş noktası nedir, nasıl hesaplanır?
Yeniden sipariş noktası (ROP), bir ürünün stok seviyesi hangi eşiğin altına düştüğünde yeni sipariş açılması gerektiğini gösteren basit bir kuraldır. Temel mantık şudur:
Yeniden sipariş noktası = (günlük ortalama tüketim × tedarik süresi) + emniyet stoku
Üç bileşen de işletmeye göre değişir:
| Bileşen | Ne anlama gelir |
|---|---|
| Günlük ortalama tüketim | Ürünün son dönemdeki gerçek satış/kullanım hızı |
| Tedarik süresi | Sipariş verildikten sonra malın depoya girmesine kadar geçen süre |
| Emniyet stoku | Tedarik süresindeki gecikme veya talepteki ani artışa karşı tampon miktar |
Formül kâğıt üzerinde basit görünür, ama elle ve Excel'de tutmak zorlaşır: her ürünün tüketim hızı zamanla değişir, tedarikçi bazen geç teslim eder, sezon geldiğinde talep sıçrar. Yüzden fazla stok kartı olan bir işletmede bu hesabı elle güncel tutmak pratikte imkânsızlaşır — formül doğru olsa da girdiler güncellenmediği için sonuç yanlış çıkar.
Basit bir örnekle: günlük ortalama satışı 20 adet olan bir üründe tedarik süresi 10 gün, emniyet stoku 50 adet olarak belirlenmişse, yeniden sipariş noktası (20 × 10) + 50 = 250 adet çıkar. Stok bu seviyeye düştüğü an yeni sipariş açılmazsa, tedarik süresi boyunca stok tükenme riski doğar. Sorun şu ki bu üç girdi de sabit değildir; tedarik süresi tedarikçiye göre değişir, günlük satış sezona göre dalgalanır. Hesabı bir kere yapıp kâğıda yazmak, altı ay sonra yanlış bir eşiğe göre karar vermek demektir.
Talep tahmini için hangi veriler işe yarar?
Yeniden sipariş noktası statik bir eşikse, talep tahmini o eşiği sürekli güncel tutan katmandır. İşe yarayan veri kaynağı üç yerden gelir:
- Geçmiş satış hareketi. Aylık değil, günlük/haftalık kırılımda — hangi gün, hangi miktar, hangi kanaldan (mağaza, e-ticaret, bayi) satıldığı.
- Mevsimsellik ve tekrarlayan döngü. Bazı ürünler yılın belirli aylarında, bazı haftanın belirli günlerinde daha çok hareket eder; bu döngü tek bir ortalamayla gizlenir.
- Tedarik tarafındaki değişkenlik. Aynı tedarikçinin teslim süresi her siparişte aynı çıkmaz; bu değişkenliğin geçmişi, emniyet stokunun ne kadar olması gerektiğini gösterir.
Bu üç veri kaynağı ayrı sistemlerde (satış, depo, satın alma) tutulduğu sürece bir araya getirilmesi zahmetli kalır ve genelde ay sonunda, geç kalınmış bir raporla yapılır. ERP'nin buradaki katkısı, üç veriyi aynı kayıt üzerinde tutup hesaplamayı sürekli, otomatik çalıştırmaktır — ay sonunu beklemeden.
Sabit formül her ürün için neden yetmez?
Yeniden sipariş noktası formülü doğru bir başlangıçtır, ama tek başına yeterli değildir; çünkü her ürün aynı davranışı göstermez. Talebi düzenli bir üründe sabit ortalama işe yarar. Talebi düzensiz, sezona bağlı veya yeni piyasaya çıkmış bir üründe sabit ortalama yanıltır — ya gereğinden fazla, ya da yetersiz sipariş önerir.
Burada devreye giren yaklaşım, ürünleri talep davranışına göre ayrıştırmaktır: düzenli tüketilen ürün basit ortalamayla, dalgalı talep gösteren ürün son dönemin ağırlıklı hareketiyle, yeni ürün ise benzer kategorideki emsal ürünün geçmişiyle değerlendirilir. Bu ayrım elle yapılmaz — yüzlerce kalemi tek tek sınıflandırmak zaman alır ve sürekli güncellenmesi gerekir. Sistemin her stok kartı için hangi hesap yönteminin daha isabetli çalıştığını kendiliğinden takip etmesi, satın alma sorumlusunun elindeki tek bir öneri listesine dönüşür: hangi üründen, ne zaman, ne kadar sipariş verilmeli.
Talep tahmini kurmak için ne kadar geçmiş veri gerekir?
Kısa cevap: mümkün olduğu kadar çok, ama en az bir tam sezon döngüsü. Üç ay gibi kısa bir pencere genel eğilimi gösterir ama mevsimsellik yakalanamaz — yaz aylarında yoğunlaşan bir ürün, kış verisiyle bakıldığında "durgun ürün" gibi görünür. Yeni açılan bir işletmede veya yeni ürün grubunda bu geçmiş yoksa, benzer kategorideki emsal ürünün hareketi başlangıç noktası olarak kullanılır ve gerçek satış verisi biriktikçe hesap kendi kendine düzelir.
Geçmiş veri ne kadar dağınık tutulmuşsa (kâğıt fiş, ayrı Excel dosyaları, farklı şube kayıtları) başlangıç o kadar zahmetli olur. Satış ve stok hareketinin baştan itibaren tek bir sistemde, tutarlı biçimde kayıt altına alınması, talep tahmininin ne zaman devreye alınabileceğini de belirler.
Birasyo'da bu süreç nasıl kurulur?
Birasyo ERP'de talep tahmini ve yeniden sipariş noktası, ayrı bir raporlama aracı değil, Stok Yönetimi modülünün günlük işleyişinin bir parçasıdır:
- Her stok kartı için sistem, geçmiş satış/tüketim hareketini otomatik izler; günlük ortalama ve mevsimsel sapma ayrı ayrı hesaba katılır.
- Tedarikçi bazında gerçekleşen teslim süreleri kayıt altına alınır; "vaat edilen" değil "gerçekleşen" süre, emniyet stoku hesabına girer.
- Stok seviyesi yeniden sipariş noktasının altına düştüğünde, satın alma ekranına otomatik bir sipariş önerisi düşer — miktar ve tedarikçi bilgisiyle birlikte.
- Öneri otomatik sipariş açmaz; satın alma sorumlusu tek ekrandan onaylar, değiştirir veya erteler. Karar insanda kalır, hesaplama sistemde.
- Bu öneriler Satınalma modülündeki onay zincirine bağlanır; sipariş önerisinden onaya, onaydan siparişe geçiş aynı akış içinde ilerler.
Sonuç, ay sonunda çıkarılan bir analiz raporu değil, her gün güncellenen ve doğrudan satın alma ekranına düşen bir çalışma listesidir.
Hangi işletmeler bu otomasyondan öncelikli fayda görür?
Yeniden sipariş noktası otomasyonu her işletmeye aynı ölçüde katkı sağlamaz. Etkisi en belirgin olduğu profil şudur:
- Stok kartı sayısı yüksek olan işletmeler — elle takip yapılabilecek sınırın ötesine geçildiğinde.
- Talebi mevsimsel veya kampanya bağımlı dalgalanan işletmeler — sabit ortalamanın en çok yanıldığı yer.
- Tedarik süresi uzun veya değişken olan işletmeler — ithal hammadde veya uzak tedarikçiyle çalışan üretim ve ticaret firmaları.
- Birden fazla depo/şube arasında stok dengelemesi gereken işletmeler — tek merkezden görünürlük olmadan bu denge elle kurulamaz.
Tek ürün grubu, tek tedarikçi ve durağan talebi olan küçük ölçekli bir işletmede fayda daha sınırlı kalır; bu durumda basit bir minimum/maksimum stok kuralı çoğu zaman yeterlidir.
Özet
Stok ve satın alma kararı, tecrübeye ve sabit ortalamalara dayandığı sürece iki uçtan birine savrulur: fazla stok veya stok tükenmesi. Yeniden sipariş noktası (günlük tüketim × tedarik süresi + emniyet stoku) bu kararı sayısal bir eşiğe bağlar, ama tek başına yeterli değildir — çünkü her ürünün talep davranışı farklıdır. ERP'nin katkısı, geçmiş satış hareketini, mevsimselliği ve gerçekleşen tedarik sürelerini aynı kayıt üzerinde tutup bu eşiği sürekli güncel tutmaktır. Karar satın alma sorumlusunda kalır; hesaplama ve öneri sistemden gelir.
Stok kartlarınızın hangi kısmının hâlâ tecrübeyle sipariş edildiğini görmek isterseniz demo talebi üzerinden bir görüşme planlayabiliriz.
İlgili yazılar:
Bu yazıyı LinkedIn'de paylaşın
Başlık, özet ve hashtagler panoya kopyalanır, LinkedIn paylaş penceresi açılır — yapıştırın (Cmd/Ctrl+V) ve gönderin.
