Yüzlerce ürünün her biri için 'ne zaman, ne kadar sipariş edeyim' kararı — stoksuz kalma ile depo şişme arasında denge (literatürde (s,S) politikası).
Kısaca
Tanıdık geliyor mu?
- 'Bu ürün ne zaman bitti' diye soruyorsun, kesin cevap yok — sayım yapılınca farkına varılıyor
- Bazı ürünler depoda 6-12 ay duruyor; nakit oraya bağlı, vade ödemesi sıkıştırıyor
- Ayda 3-8 kez 'müşteri istedi ama stoksuzdu' kaybı yaşıyorsun; bazıları geri gelmiyor
- Acil sipariş için tedarikçiye ek nakliye veya prim ödüyorsun — bütçenin dışında çıkıyor
- Tedarikçi minimum sipariş miktarı yüksek; küçük talep için zorunlu olarak çok alıyorsun
- Sezona girerken hangi üründen ne kadar tutmalı sorusu sezgiye, geçen yılki bozuk veriye dayanıyor
- Son kullanma tarihi yaklaşan ürün indirimle veya zararına satılıyor — fire oranı %3-8 civarı
Niye önemli?
Nasıl çözülür?
Teknik derinlik
Nasıl çözülür?
Teknik derinlikTek satırla: Her ürün için iki rakam belirle — düşüş seviyesi (stok bu rakama düşünce sipariş ver) ve doldurma seviyesi (siparişle stok bu rakama çıksın). Talep ne kadar dalgalı ve tedarikçi ne kadar yavaşsa düşüş seviyesini o kadar yükseğe çek; aksi takdirde stoksuz kalırsın.
Yazılımın yaptığı iş şu: senin kafanda 50 ürün için kurabildiğin “ne zaman, ne kadar” kararını, 5.000 ürün için saniyelerde kurar ve her gün otomatik günceller. Üç aşama hâlinde anlatalım:
1. Önce veriyi toplar. Her ürün için geçmiş 6-12 aylık satış verisi, tedarikçi teslim süresi (lead time) ve teslim süresindeki değişkenlik, tedarikçinin minimum sipariş miktarı (MOQ) ve fiyat skalası, ürünün son kullanma tarihi varsa raf ömrü, depo alanı kısıtı, hizmet düzeyi hedefi (örnek %95 — yüz müşterinin doksan beşi istediğini bulsun). Bu veri ya kasa-sipariş sisteminden otomatik gelir, ya da bir kez doğru tabloya girilir.
2. Her ürün için sipariş politikasını çıkarır. Yazılım her gün her ürüne ayrı bakmaz — bunun matematik olarak gereksiz olduğu biliniyor. Onun yerine operasyon araştırması (matematik ve bilgisayarla iş kararı veren disiplin) alanından gelen envanter modellemesiyle her ürün için iki sayı hesaplar: s (sipariş noktası — stoğun bu seviyeye düştüğünde sipariş ver) ve S (sipariş üst sınırı — bu seviyeye kadar doldur). Sayılar talep değişkenliğini, teslim süresini ve istediğin hizmet düzeyini birlikte gözeterek bulunur. Talep hızı, teslim süresi veya tedarikçi şartları değişince yazılım iki sayıyı otomatik günceller.
3. Sipariş listesi her sabah masaya düşer. Yazılım o sabah hangi ürünleri sipariş etmen gerektiğini, hangi tedarikçiden, ne miktarda diye gösterir. Sen “evet, gönder” diyorsun, sistem tedarikçiye iletip teslimat takibine geçiyor. Tedarikçi geç kalırsa veya MOQ değişirse yazılım otomatik uyarır.
Sipariş kararını ortadan kaldırmaz; 50 üründe kafadan yaptığın işi 5.000 ürüne ölçekleyen ve unutmayan bir hesap makinesi gibi düşün. Karar yine senin, ama elinde her zaman her ürün için güncel bir tablo var.
Alternatifler
Hesap tablosu + sezgi
ÜcretsizÜcretsiz
Kim için: 10-100 SKU, sabit talep, uzun raf ömrü
- + Sıfır maliyet
- + Esnek — sezgisel ayar kolay
- + Yatırım kararı gerekmez
- − 100'ün üstü SKU için kalitesi hızla düşer
- − Talep değişkenliği ve teslim süresi belirsizliği hesaba katılmıyor
- − Sezon değişiminde tepki gecikir
- − Hangi ürünün ne kadar bağlı nakdi olduğu izlenmiyor
Yerel ERP envanter modülü
Kurumsal8.000–30.000 TRY kurulum + aylık 2.000–6.000 TRY (TR pazar gözlemi)
Kim için: 100-1.000 SKU, sabit tedarikçi portföyü
- + Türkçe arayüz ve destek
- + Muhasebe ve fatura ile entegre
- + Otomatik sipariş noktası uyarısı genelde var
- − Talep tahmini genelde 'son ay × 1,1' düzeyinde basit
- − Hizmet düzeyi / güvenlik stoku hesabı arka planda yok ya da çok basit
- − Çok kademeli (depo + mağaza) optimizasyonu zayıf
Uluslararası uzmanlaşmış stok ve tedarik yazılımı
Kurumsal5–25 EUR/SKU/ay abonelik veya 30.000–200.000 EUR yıllık lisans
Kim için: 1.000-50.000 SKU, çoklu depo, talep tahminli planlama gerekli
- + Olgun: istatistiksel talep tahmini, çok kademeli optimizasyon, alarm sistemi tam destekli
- + Tedarikçi entegrasyonu (EDI, API) hazır
- + Sezon ve trend ayrımı yapabiliyor
- − Yüksek lisans + danışmanlık maliyeti
- − Kurulum 3-6 ay
- − Türkçe destek sınırlı olabilir
Açık kaynak çözücü ile özel yazılım
Açık KaynakLisans ücretsiz; geliştirme 8-16 hafta kendi ekibinle veya 200.000-800.000 TRY danışmanlık
Kim için: İçinde veri bilimi ekibi olan zincir veya özel iş modeli olan e-ticaret
- + Lisans maliyeti yok
- + Tam özelleştirme — kendi kategori yapına göre
- + Buluta veya kendi sunucuna kurulabilir
- − İçeride veri ve operasyon araştırması kapasitesi şart
- − Sürekli bakım gerekir — her tedarikçi değişikliğine dikkat
- − Talep tahmini ve stok politikası iki ayrı uzmanlık alanı; ekip kurmak pahalı
Tavsiye
Çözüm görüşmesinde sor
- Talep tahmini hangi modele dayanıyor — basit ortalama mı, mevsimsel ayrıştırma mı, makine öğrenmesi mi? Hangi ölçekte hangisi devreye giriyor?
- Tedarikçi teslim süresi belirsizliği güvenlik stoku hesabına nasıl giriyor? Hizmet düzeyi hedefini her ürün için ayrı belirleyebiliyor muyuz?
- Minimum sipariş miktarı (MOQ), parti büyüklüğü ve kademeli fiyat indirimi destekleniyor mu?
- Çok kademeli optimizasyon (depo + birden çok mağaza ya da depo + e-ticaret) sistemde nasıl modelleniyor?
- Sezon başlangıcında yeni ürünler için 'tarihi olmadan' tahmin nasıl yapılıyor? Benzer ürün eşleştirme var mı?
- Son kullanma tarihi yaklaşan ürünler için otomatik aksiyon önerisi (indirim, transfer, sipariş kesme) sistem üzerinden mi geliyor?
- Pilot dönemini nasıl kurguluyorsunuz — kaç SKU, kaç hafta, başarılı sayılma kriteri nedir?
- Bizimle çalışmayı bırakırsak ürün, tedarikçi ve geçmiş hareket verisini nasıl alırız? Standart format export var mı?
Teknik detay
Editör notu
Bu problem halk dilinde “stok yenileme”, “sipariş yönetimi” veya “rafa ne zaman koyacağız” diye anılır. Akademik literatürde adı Inventory Replenishment / (s,S) Policy — Türkçesi “sipariş noktası — sipariş üst sınırı politikası”. 1950’lerden beri operasyon araştırmasının en köklü konularından biri. Bunu bilmeden bir yazılım firmasıyla görüşmeye gidersen, sana satılmaya çalışılan “stok yönetim modülü"nün gerçekten istatistiksel talep tahminine ve güvenlik stoku hesabına dayanıp dayanmadığını test edemezsin.
Sektörde en sık atlanan nokta: çoğu yazılım “stok takibi yapar” diyerek reklam verir ama altında sadece fiziksel sayım + uyarı eşiği mantığıyla çalışır — yani “stok 10 birimin altına düşerse uyar” tipi sabit eşik. Bu yaklaşım talep değişkenliği düşükken makul; ama talep dalgalı veya teslim süresi belirsizse hızla kalitesini kaybeder. Demo gösteriminde mutlaka 20 farklı SKU + her birinin farklı talep değişkenliği + farklı tedarikçi teslim süresi olduğu küçük bir örnek üzerinden “her ürünün sipariş noktasını nasıl belirliyorsunuz” diye sor.
Adım adım yol — KOBİ için
Aşama 1 — Önce ölç, sonra plan. En az 12 hafta boyunca dört şeyi bir tabloya kaydet:
- Her SKU için günlük/haftalık satış adedi (kasa sisteminden veya manuel sayım)
- Her tedarikçi için sipariş-teslimat süresi (kaç gün, ne kadar değişkenlik)
- Stoksuz kalma sayısı ve nedeni (yanlış tahmin, geç tedarikçi, ani kampanya)
- Depoda 90+ gün duran ürün listesi ve bağlı nakit
Bu veri olmadan hangi yazılımın hangi sonucu vereceğini hesaplayamazsın.
Aşama 2 — Ürün ABC analizi yap. Toplam cironun yaklaşık %80’i SKU’ların yaklaşık %20’sinden geliyor (A grubu). Bu A grubu ürünler için sıkı stok politikası gerekli; B grubu için orta sıkılık; C grubu için basit politika yeterli. Bu sınıflandırmayı önce sen yap, sonra yazılıma anlat — yazılımın otomatik yapması iyi ama senin operasyonel bakışın eklendiğinde sonuç daha iyi.
Aşama 3 — Pilot dönem. A grubundan 30-50 SKU ile başla, 8-12 hafta sürsün. Başarı kriterin önceden yazılı olsun: örnek “90 günde A grubunda stoksuz kalma %50 düşmeli, ortalama envanter %15 azalmalı.” Hedef tutmazsa pilot iptal — sözleşmede bu hak açıkça yazılı olmalı.
Aşama 4 — Yaygınlaştırma. Pilot başarılıysa tüm SKU yelpazesine 2-4 ay içinde yay. Operasyon ekibi eğitimi 1-2 hafta sürer; tedarikçi entegrasyonu (EDI veya API) genelde 4-8 hafta sürer.
Riskler — ne yanlış gidebilir
- Veri kalitesizliği. Geçmiş satış verisinde stoksuz kalma dönemleri varsa, talep tahmini düşük çıkıyor — yazılım yine az sipariş veriyor, kısır döngü oluşuyor. Geçmiş veride stoksuz kalma dönemlerini “düzeltme” gerekir; iyi bir yazılım bunu kendisi yapar.
- Operasyon ekibinin direnci. “Bilgisayar 50 birim sipariş ver diyor ama benim sezgim 20 yeter” tarzı tepki yaygın. Pilot dönemde ekiple birlikte sonuçları gözden geçir; yazılım neye dayandığını şeffaf göstermeli.
- Tedarikçi tepkisi. Daha sık ama daha küçük sipariş verirken tedarikçi MOQ veya nakliye fiyatı ile direnç gösterebilir. Tedarikçi anlaşmasını yeniden gözden geçirmek pilot kapsamına girmeli.
- Tek tedarikçiye bağımlılık. Stok geçmişi ve tedarikçi verisini kendi özel biçiminde tutan yazılımdan, yıllar sonra çıkmak zor. Sözleşmede “verimizi standart açık formatlarda (CSV gibi) istediğimiz zaman alma hakkımız var” maddesi yazılı olsun.
İlgili acı ders (yayına geçince linkli olur): “5.000 SKU’lu bir perakendecide 14 ayda terk edilen stok yazılımı — neyi atladılar”.
Çözüm yöntemine teknik bakış
Bu bölüm, yazılım ekibiyle veya danışmanla konuşurken ihtiyaç duyacağın temel bilgileri tutar. Operasyon ekibinin günlük ekranında göreceği şey değil — perde arkasında olan iş.
Stok yenileme problemi için kullanılan ana yaklaşımlar:
| Yaklaşım | Türkçe adı | Tipik kullanım | Veri ihtiyacı | Karar mantığı |
|---|---|---|---|---|
| EOQ formülü | Ekonomik sipariş miktarı | Sabit talep, tek ürün | Düşük | Tek formül, anlık hesap |
| (s,S) politikası | Sipariş noktası — sipariş üst sınırı | Değişken talep, çok ürün | Orta | Olasılıksal model + güvenlik stoku |
| (R,Q) politikası | Sabit aralık — sabit miktar | Sabit aralıklı sipariş günleri | Orta | Periyodik gözden geçirme |
| Newsvendor / tek dönem | Tek dönem stok | Bozulan ürün, sezonluk | Orta | Talep dağılımı + maliyet oranları |
| Çok kademeli MIP | Çok kademeli optimizasyon | Depo + mağaza ağı | Yüksek | Tam ağ optimizasyonu |
Pratik öneri: 500 SKU’nun altında ve sabit tedarikçi şartlarında (s,S) veya (R,Q) yeterli. 1.000+ SKU veya çok kademeli ağda ticari demand planning + çok kademeli optimizasyon tercih edilir. Bozulan ürün için Newsvendor varyantları kullanılır.
Hedef fonksiyonu seçimi çözümün biçimini değiştirir:
- Toplam stok tutma maliyeti: “Bağlı nakit en az olsun” — nakit sıkıntısı yaşayan işletme için
- Hizmet düzeyi (örnek %95 doluluk): “Müşteri stoksuz dönmesin” — pazar payı odaklı işletme için
- Beklenen kâr (kayıp satış + fire dahil): “Toplam kâr en yüksek olsun” — fiyat marjı yüksek perakende için
- Maliyetli stoksuz kalma + maliyetli fire dengesi: “Bozulan ürün stratejisi” — taze gıda, ilaç gibi raf ömürlü ürün için
Çoğu pratik vakada bu dördünün ağırlıklı bir karışımı kullanılır.
Akademik kaynaklar
Sayfanın sources bölümünde listelidir. Türkçe akademik çalışmalar için: YÖK Tez Merkezi’nde “stok yönetimi” anahtar kelimesiyle 400+ tez bulunur — özellikle endüstri mühendisliği ve işletme yüksek lisans tezleri Türk perakende pratiğine yakındır. Envanter yönetimi alanı operasyon araştırmasının en eski (1950’lerden başlar) ve hâlâ aktif konularından biri.
Kaynaklar
- Silver, E. A., Pyke, D. F. ve Thomas, D. J. (2017). Inventory and Production Management in Supply Chains (4. baskı). CRC Press. Alanın standart ders kitabı.
- Zipkin, P. H. (2000). Foundations of Inventory Management. McGraw-Hill. Tek dönemli ve çok dönemli stok modellerinin matematiksel referansı.
- Nahmias, S. ve Olsen, T. L. (2015). Production and Operations Analysis (7. baskı). Waveland Press. KOBİ uygulamalarına yakın anlatım.
- YÖK Tez Merkezi — anahtar kelime: ‘stok yönetimi’, ’envanter politikası’, ‘sipariş noktası’ — TR akademisinden 400+ tez. tez.yok.gov.tr
Sözlük
- EOQ
- Bir ürünün tedarikçiye verilecek en ekonomik sipariş miktarını veren klasik envanter formülü.
- Güvenlik Stoku
- Talep ve teslim süresi belirsizliğine karşı tutulan ek stok — beklenmedik dalgalanmada stoksuz kalmayı önler.
- MIP
- Karar değişkenlerinin bir kısmının tam sayı (örn. 'kaç kamyon', 'kaç vardiya') olduğu optimizasyon türü.
Benzer problemler
Aynı Tedarikçiden Onlarca SKU Geliyor — Hangi SKU'yu Hangi Sıklıkta Sipariş Edeyim ki Kamyon ve Stok Maliyeti Birlikte Minimum Olsun?
Aynı tedarikçiden 50-500 SKU alan KOBİ toptancı, ithalatçı veya üretici için sayfa — tipik olarak 3-15 ana tedarikçiyle çalışırsın. Her hafta aynı soru: bu tedarikçiden bugün hangi ürünler sipariş edilsin, hangileri gelecek haftaya kalsın? Her ürün için ayrı sipariş tetiklenirse aynı tedarikçiye haftada üç kamyon, üç gümrük dosyası çıkar; oysa bir kamyon, bir gümrük, bir hazırlık masrafı doğru gruplamayla tek seferde paylaşılır. Manuel planlama 50 SKU'yu aşınca dağılır: bazı haftalar yarım kamyon, bazı haftalar üst üste üç sipariş — sabit masraflar birim başına %5-15 ürün maliyeti olarak geri döner.
Hangi Ürünü Hangi Rafa Koysam, İşçi Siparişi Hangi Rota Üzerinden Toplasın?
Bir e-ticaret deposunda ya da omnichannel perakende dağıtım merkezinde 15.000-200.000 ürün kodu (SKU) stoklanır ve günde 2K-30K sipariş hattı toplanır. Bir toplayıcı işçi sipariş başına 200-800 m yürür, günde toplam 15-30 km mesafe kat eder. Bu yürümenin %50-70'i değer-katmayan zamandır. İki bağlı karar verilmelidir: (a) **raf yerleşimi (slotting)** — hangi SKU hangi rafa, hangi yüksekliğe stoklanır; sipariş sıklığı, eş-sipariş örüntüsü ve ergonomik yük dikkate alınarak; (b) **toplama rotası (picking)** — bir sipariş listesi için işçinin koridor sırası ve seçtiği rota kuralı (S-şekli, dönüş, orta-nokta, en-büyük-boşluk, birleşik). Eklenti kararlar: birden çok siparişi tek turda toplama (batch picking), depoyu bölgelere ayırma (zone picking), aktarma noktası ile birleştirme (sort-merge). Her iki karar birlikte çözüldüğünde işçi başına yürüme mesafesi %25-40 azalabilir.
Hangi Ürünü Listeye Koyayım, Hangi Rafı Hangisine Vereyim?
30-200 mağazalı perakende KOBİ ya da 500-5.000 SKU'lu e-ticaret operatörü için yazıldı. Her ay 'hangi ürün rafta kalacak, hangisine ne kadar yer vereceğiz, yeni gelen tedarikçiye yer açmak için hangisini çıkaracağız' kararıyla yüzleşiyorsanız buradasınız. Sezgisel listeleme ve elle planogram, kategori marjının önemli bir kısmını sessizce eritir: çok satanın rafı dar kalır, atıl SKU yer işgal eder, ikame etkisi (müşteri aradığını bulamayınca rakibe gitmesi) ölçülemez. Mağaza-kategori bazlı sistematik bir karar süreci, 50M TRY cirolu bir kategoride yıllık 2-6M TRY marj farkı yaratır.