- 1Mağazaların Hissederek Sipariş Vermesini Sağlayan Yalan
- 2Bir E-ticaret Stok Tahmininin Gerçekten İhtiyaç Duyduğu Beş Girdi
- 3Yeniden Sipariş Noktası Matematiği, Adım Adım Açıklanıyor
- 4E-ticaret Stok Tahmini Nerede Tahmin Edilebilir Şekilde Başarısız Olur
- 5Asimetri: stok tükenmesi ve aşırı stok aynı maliyete sahip değil
- 6Yeni SKU'nun soğuk başlangıç sorunu
- 7Promosyon çarpıtma tuzağı
- 8Önce Hesap Tablosu — ve Hesap Tablosu Durduğunda
- 9Bir Tahmin Bir Satın Alma Programıdır — Bu da Onu Bir Nakit Programı Yapar
- 10On SKU ile Başlayın
Tahmin yapmak geleceği öngörmek değildir. Belirli bir programa ve ölçülmüş bir tampona göre, tedarikçinize ne zaman para göndereceğinize karar vermektir — ki bu çok daha kolay bir sorundur.
E-postanız, şimdiye kadarki en iyi ayınızın üçüncü haftasında geliyor: "Merhaba — Sage rengindeki 20 oz'luk ürünü sipariş etmeye çalışıyorum ve stokta olmadığını söylüyor. Ne zaman tekrar gelecek?" Kontrol ediyorsunuz. Sadece Sage rengi değil. En çok satan ürününüz altı varyanttan dördünde tükenmiş, tedarikçinizin teslim süresi 35 gün ve iki hafta önce vermeniz gereken sipariş hala taslak halinde. Bu arada, garajın köşesinde, Ocak ayında kesin bir başarı gibi görünen renk seçeneğinin paleti Mart ayından beri hareket etmemiş.
Daha önce de bu durumu yaşadınız. Geçen sefer, stok tahminine ciddiyetle yaklaşacağınıza yemin etmiştiniz — ve sonra bulduğunuz e-ticaret stok tahmin içeriği, talep algılama algoritmaları, makine öğrenimi, olasılıksal modeller hakkında konuşuyordu. 40 SKU'nuz ve bir hesap tablonuz var. Bu yüzden sekmeyi kapattınız ve hislere göre sipariş vermeye geri döndünüz.
Bu yazının dayandığı yeniden çerçeveleme: stoklarınızın tükenmeye devam etmesinin nedeni eksik algoritmalarla ilgili değil. Yeniden siparişin, bir sayı söylediğinde değil, fark ettiğinizde gerçekleşmesidir. Bunu düzeltmek, zaten sahip olduğunuz beş girdi ve kağıt üzerinde yapabileceğiniz aritmetik gerektirir.
Mağazaların Hissederek Sipariş Vermesini Sağlayan Yalan
Çoğu DTC operatörünü durduran inanç: "Gerçek tahmin veri bilimi gerektirir ve benim talebim zaten bunun için çok öngörülemez."
Her iki taraf da yanlış. Tahminin veri bilimi versiyonu, on binlerce SKU'su olan ve %1'lik bir doğruluk artışının milyonlarca değer olduğu işletmeler içindir. 40 veya 400 SKU'da, gelişmiş model ve basit model neredeyse aynı satın alma siparişlerini üretir — çünkü sizin ölçeğinizde, size zarar veren hatalar modelleme hataları değildir. Bunlar süreç hatalarıdır: bu ay kimse hızı kontrol etmedi, kimse tedarikçinin geçen sefer iki hafta geciktiğini yazmadı.
Ve "çok öngörülemez" ifadesi, bir tahminin ne işe yaradığını karıştırıyor. Mart ayında tam olarak 187 adet satacağınızı tahmin etmeye çalışmıyorsunuz. Tek bir operasyonel soruyu yanıtlıyorsunuz: bir sonraki sevkiyat gelmeden tükenmemek için ne zaman ve ne kadar yeniden sipariş vermeliyim — ihtiyacım olmayan stokla nakitimi gömmek zorunda kalmadan? Bu soru, öngörülebilirlik için tampon, matematiğin bir parçası olduğu için çok fazla öngörülemezliğe tolerans gösterir.
Bir E-ticaret Stok Tahmininin Gerçekten İhtiyaç Duyduğu Beş Girdi
Çalışan bir DTC tahminindeki her şey, SKU başına beş sayıdan gelir; hepsi satış raporundan ve son birkaç satın alma siparişinizden elde edilebilir.
1. SKU başına geçmiş satış hızı. Geçmiş bir pencere üzerinden ortalama günlük satılan birimler — hızlı ürünler için 30 gün, daha yavaş olanlar için 90 gün, böylece tek bir iyi hafta ortalamayı bozmaz. Bu, tahminin motorudur ve SKU başına olmalıdır, ürün başına değil. "Bardağın günde 12 sattığı" bilgisi, Sage 6 ve Mustard 1 satıyorsa işe yaramaz.
2. Mevsimsellik çarpanı. Her ayın satışlarını ortalama ayınıza bölün: Kasım 1.8, Şubat 0.7 olabilir. Çarpanı, sipariş ettiğiniz dönem değil, envanterin aslında satacağı döneme uygulayın — stokların Kasım ayında gelmesi için Ekim ayında verilen bir satın alma siparişi, Kasım ayının sayısını alır.
3. Tedarikçi teslim süresi — ve değişkenliği. Teklifteki sayı değil. Son birkaç siparişinizden, PO gönderiminden satılabilir stoğa kadar geçen fiili günler: 32, 29, 41, 35. Ortalama, yeniden sipariş noktasını belirler. Yayılım — o 41 — güvenlik stoğunuzu belirler.
4. MOQ ve sipariş kısıtlamaları. Minimum sipariş miktarları, koli boyutları ve fiyat indirimleri, ne zaman yeniden sipariş vereceğinizi değiştirmez, ancak ne kadar sipariş vereceğinizin tabanını belirler — bu da nakit için büyük ölçüde önemlidir, ileride göreceğimiz gibi.
5. Planlanmış promosyonlar. Bir satış, kasıtlı olarak planladığınız taleptir. Geçen yıl Kara Cuma paketinin normal hızın 3 katı satış yapması durumunda, bu ani artış açık bir satır olarak tahmine dahil edilir — ve sonrasında geçmiş hızdan çıkarılır (aşağıda kendi bölümü olan bir tuzak).
Tam liste bu. Beceri matematiksel değil — bu beş sayıyı her seferinde tahmin etmek yerine güncel tutmaktır.
Yeniden Sipariş Noktası Matematiği, Adım Adım Açıklanıyor
İşte kurgusal yuvarlak sayılarla aritmetik: Sage'deki en çok satan bardağınız.
- Son 90 günlük hız: 6 birim/gün
- En yoğun son 30 günlük dönem: 8 birim/gün
- Tedarikçi teslim süresi: Ortalama 30 gün, en kötü durumda 40 gün
- MOQ: 500 birim
Adım bir: teslim süresi talebi. Bir sonraki sevkiyatı beklerken hayatta kalmak için yeterli stoğa ihtiyacınız var: 6 birim/gün × 30 gün = 180 birim. Hiçbir şeyin değişmediği bir dünyada bu, minimum yeniden sipariş noktasıdır.
Adım iki: güvenlik stoğu. O dünyanın hiçbir yanı gerçek değil, bu yüzden bir tampon ekliyorsunuz. Basit, savunulabilir bir formül: en kötü durum teslim süresi boyunca en kötü durum talebi eksi ortalama durum.
(8 birim/gün × 40 gün) − (6 birim/gün × 30 gün) = 320 − 180 = 140 birim güvenlik stoğu
Adım üç: yeniden sipariş noktası. 180 + 140 = 320 birim. Sage'in eldeki artı siparişteki sayısı 320'ye düştüğünde, PO'yu gönderirsiniz. Düşük hissettiğinde değil — 320'de.
Stok güvenliği hakkında iki şey, hesaplamadaki en çok yanlış anlaşılan sayı. Birincisi, neyi dengelediği konusunda hassas olun: ortalama değerin size yalan söylediği iki yol — ortalamanın üzerinde talep ve tedarikçinin ortalamanın altında kalması. Bu belirsiz bir "olur da lazım olur" dolgusu değil; sizin SKU'nuzun talep yayılımı ve sizin tedarikçinizin geçmiş performansına göre boyutlandırılır, bu yüzden 3 numaralı girdi teklif yerine geçmişi sordu.
İkincisi, stok güvenliği bir komut değil, bir ayardır. Formül muhafazakardır — kötü talebin ve kötü teslim süresinin aynı anda gerçekleştiğini varsayar. Yavaş hareket eden bir ürün için veya nakit sıkıntısı varken, bunu küçültebilir ve daha fazla stok tükenmesi riski kabul edebilirsiniz. Önemli olan, bunun bir kaza sonucu değil, sayılarla verilmiş bir karar haline gelmesidir.
Dördüncü adım: ne kadar sipariş verileceği. Yeniden sipariş noktası ne zaman olduğunu söyler; sipariş miktarı ayrı bir karardır. Temiz bir başlangıç kuralı: hedef kapsama pencerenizi sipariş edin — diyelim ki, beklenen hızın 60-90 günü, mevsimselliğe göre ayarlanmış — sonra minimum sipariş miktarına (MOQ) veya bir sonraki koli paketine yuvarlayın. Sage için 1.5 katı sezona girerken: 6 × 1.5 × 60 gün = 540 adet, bu da zaten 500 MOQ'yu karşılıyor. Günde 1 adet satan yavaş hareket eden bir ürün için, aynı MOQ 500 günlük stok anlamına gelir — MOQ'yu müzakere etme, varyantları birleştirme veya SKU'nun varlığını sorgulama anı.
[RESİM: Yeniden sipariş noktası hakkında basit diyagram — 320 birimlik yeniden sipariş eşiğini kesen aşağı doğru eğimli stok çizgisi, sipariş verildi, stok güvenlik bandının 140 birimine yaklaşırken geliyor]
E-ticaret Stok Tahmini Nerede Tahmin Edilebilir Şekilde Başarısız Olur
Matematik kolay kısımdır. Bu üç arıza modu, gerçek mağazaların zarar gördüğü yerlerdir.
Asimetri: stok tükenmesi ve aşırı stok aynı maliyete sahip değil
Stok tükenmesinin görünür maliyeti, aradaki boşluk sırasında kaçırılan satışlardır. Gizli maliyet daha kötüdür: durdurduğunuz reklam kampanyaları (yeniden başladıklarında daha yüksek bir CPA ile yeniden öğrenirsiniz), yeniden siparişleri olmadığı için ayrılan aboneler, satacak hiçbir şeyiniz olmadığında gelen ilk kez alışveriş yapanlar ve listeleme ölü kaldığı sürece düşen organik sıralamalar. DTC markalarının üzerine kurulduğu türden, her zaman yenilenebilir bir ürün için — üç haftalık bir stok tükenmesi, yeniden stoklamadan sonra aylarca hızı bastırabilir.
Fazla stokun maliyeti taşıma maliyetidir: kilitlenmiş nakit, depolama, nihai indirim. Acı verici, ancak kademeli ve genellikle kurtarılabilir — ürün son kullanma tarihi geçmezse, tarihli değilse veya modası geçmezse.
Yani doğru eğilim ürün tipine bağlıdır. Her zaman yenilenebilir çekirdek SKU'lar için, fazla stoğa doğru eğilin — cömert stok güvenliği, erken yeniden siparişler — çünkü stok tükenmesi pahalı kuyruktur. Mevsimsel, moda veya çabuk bozulan SKU'lar için, tersini yapın: satılmayan stok sadece nakdi bağlamakla kalmaz, tasfiyeye dönüşür, bu yüzden az siparişler tamponlardan daha iyidir. Her iki ürün tipi için de tek bir eğilim kullanmak, mağazaların aynı anda kazanan üründen mahrum kalıp kaybeden üründe boğulmasına neden olur — bu gönderinin başındaki garaj senaryosu.
Yeni SKU'nun soğuk başlangıç sorunu
Yeni bir SKU'nun sonradan gelen bir ivmesi yoktur, bu nedenle tahmin motoru boştur. Yanlış kesinlikle yanıltmayın. Daha önce başlattığınız en benzer SKU'nun lansman eğrisini ödünç alın, dürüst beklentinizle ölçeklendirin ve - bu eyleme geçirilebilir kısım - ilk PO'yu ucuza yanlış yapacak şekilde boyutlandırın. Hızlı yeniden sipariş tetikleyicili daha küçük bir ilk sipariş, kendinden emin bir konteynerden daha iyidir. Henüz tahmin yapmıyorsunuz; veri satın alıyorsunuz. İkinci PO'yu dört ila altı haftalık gerçek satışlara yerleştirmek, cesaretin başarısızlığı değil, plandır.
Promosyon çarpıtma tuzağı
İki haftalık bir indirim yaparsınız. İşe yarar - 3 kat hız. Altı hafta sonra, son ortalamanız hala o iki haftadan şişmiş durumda, yeniden sipariş noktalarınızın hepsi çok yüksek ve indirimle ürettiğiniz talebe göre tüm katalogda fazla sipariş vermek üzeresiniz.
Düzeltme mekaniktir: promosyon dönemlerini satış verilerinizde etiketleyin ve bu pencereler hariç tutularak temel hızı hesaplayın. Promosyonlar, girdi #5'in dediği gibi tahmine girer - açık, planlanmış talep olarak - asla son ortalama aracılığıyla sessizce değil. Tuzak tersine de işler: stok tükenmesi dönemi ortalamanızı aşağı çeker, size az önce yetersiz aldığınızı kanıtladığı SKU'nun daha azını sipariş etmenizi söyler. Bu pencereleri de hariç tutun; boş raftan elde edilen sıfır satış talep verisi değildir.
Önce Hesap Tablosu — ve Hesap Tablosu Durduğunda
Yukarıdaki her şey tek bir e-tabloda çalışır: SKU başına bir satır, beş girdi için sütunlar, yeniden sipariş noktası ve sipariş miktarı için formüller ve hızları güncellediğiniz ve eşiğini aşanları kontrol ettiğiniz haftalık 30 dakikalık bir inceleme. Birkaç yüz SKU'ya ve bitmiş ürüne kadar tek kanallı bir mağaza için, e-tablo gerçekten doğru araçtır - bütçe tavizi değil. İçindeki her sayıyı anlayacaksınız, ki bu çoğu yazılım uygulamasının başardığından daha fazladır.
E-tablo, tanınabilir belirtilerde dürüst olmaktan çıkar: ikinci bir satış kanalı, eksiltemediği paketler ve kitler, birden fazla depo veya bir 3PL veya haftalık incelemenin artık gerçekleşmediği bir SKU sayısı - güncel olmayan bir tahmin, yalnızca biçimlendirilmiş içgüdüsel bir histir. O noktada, canlı satış verilerini okuyan yeniden sipariş mantığına, yenileme uygulaması sınıfında ve üstünde istersiniz. O manzarayı, sıralamaya göre değil, operasyonel şekle göre, Shopify ve WooCommerce için en iyi envanter yönetimi yazılımı hakkındaki dürüst kılavuzumuzda haritaladık.
Bir Tahmin Bir Satın Alma Programıdır — Bu da Onu Bir Nakit Programı Yapar
Bir yeniden çerçeveleme daha, çünkü bunu işinizin geri kalanıyla ilişkilendirir: belirlediğiniz her yeniden sipariş noktası, üzerinde yaklaşık bir tarih olan gelecekteki bir ödemedir. Ağustos ortasında 320 birimi geçen Sage, Ağustos ortasında bir tedarikçi ödemesidir. Tamamlanmış bir tahmin, takvim boyunca aşağı doğru okunduğunda, mağazanızın en büyük tekrarlayan nakit çıkışlarının bir programıdır.
Bu önemlidir çünkü envanter ağırlıklı mağazalar nadiren kârsızlıktan ölürler — ince bir haftada büyük bir siparişin gelmesiyle ölürler. Tahmininizin sipariş tarihlerini 13 haftalık nakit akışı tahminine dahil etmek, "yeniden sipariş vermeliyiz" ifadesini "yeniden siparişi vadesinde perşembe günü ödeyebiliriz" ifadesine dönüştürür. Ve sipariş matematiği yalnızca birim ekonominiz kadar iyidir: eğer birim başına maliyetiniz belirsizse, sipariş miktarı kararlarınız da onunla birlikte belirsizleşir — Shopify satıcıları için satılan malın maliyeti rehberimiz bu sayıyı sağlamlaştırmayı kapsar.
On SKU ile Başlayın
Bu hafta 400 satırlık modeli oluşturmayın. En yüksek devirli on SKU'nuzu — gelirinizin çoğu, stok tükenme riskinizin tamamı — alın ve yöntemi yalnızca onlar üzerinde uygulayın: geçmiş devri çekin, son birkaç siparişinizden gerçek teslim sürelerini not alın, yeniden sipariş noktasını hesaplayın ve haftalık 30 dakikalık incelemeyi takvime ekleyin. Bu yazının başındaki tumbler e-postası daha iyi içgüdülerle önlenmez. Bir sayıyla — 320 — ve onu kontrol etme alışkanlığıyla önlenir.
On SKU, beş girdi, bir formül. DTC ölçeğinde envanter tahmini budur — ve birimler planlandıktan sonra, aynı disiplinin para tarafı (satılan malın maliyeti, nakit zamanlaması, raftakilerle eşleşen defterler) e-ticaret muhasebesi tam rehberimizde ele alınmaktadır.
