बिक्री का इतिहास साफ़ करें, सादे moving average से फ़ोरकास्ट करें, WAPE और bias से error नापें, और उसे रीऑर्डर पॉइंट व सेफ़्टी स्टॉक में बदलें। एक SKU का पूरा हिसाब, हफ़्ते की 30 मिनट की रूटीन, और मशीन लर्निंग कब काम की।
Author
Anichur Rahaman
तीन दुकानों वाले एक होमवेयर कारोबार की सबसे ज़्यादा बिकने वाली केतली हर शेल्फ़ से ग़ायब है। शुक्रवार की सुबह मालिक दुकान पहुँचता है तो एक ग्राहक डिस्प्ले वाला पीस माँग रहा है, और supplier कहता है कि अगली खेप आने में दो हफ़्ते लगेंगे। उधर पिछले अक्टूबर से गोदाम के कोने में 140 कैंडल होल्डरों का एक डिब्बा पड़ा है, जिसे कोई नहीं पूछता।
इसमें किसी की लापरवाही नहीं है। केतली का रीऑर्डर लेवल महीनों पहले अंदाज़े से तय हुआ था, जब वह हफ़्ते में 30 बिकती थी। अब 50 बिकती है, और हिसाब किसी ने दोबारा नहीं लगाया। (यह एक काल्पनिक दृश्य है, कोई असली दुकान नहीं।)
इसे सुधारने के लिए data साइंस टीम की ज़रूरत नहीं। ज़रूरत है साफ़ बिक्री-इतिहास की, एक-दो आसान फ़ॉर्मूलों की, और उन प्रोडक्ट्स पर ध्यान देने की आदत की जो सचमुच मायने रखते हैं। ज़्यादातर फ़ायदा चंद आदतों से आता है, पेचीदा मॉडल से नहीं।
इस लेख में एक ही उदाहरण के सहारे पूरा सफ़र देखेंगे, जिसका SKU केतली की तरह हफ़्ते में 50 बिकता है: इतिहास साफ़ करना, moving average से forecast, error नापना, forecast को भरोसेमंद reorder point में बदलना, और तय करना कि किस SKU को कितना समय देना चाहिए। उदाहरण के सारे आँकड़े काल्पनिक हैं।
आपका system बिक्री दर्ज करता है। Forecast आपको डिमांड का करना है: अगर शेल्फ़ कभी ख़ाली न होता और कुछ असामान्य न होता, तो ग्राहक कितना ख़रीदते।
दोनों में फ़र्क़ लोगों की सोच से कहीं बड़ा है। कोई आइटम तीन दिन stock में न रहे, तो उन दिनों की बिक्री ज़ीरो दिखती है, और सीधा-सादा forecast इसे कमज़ोर डिमांड मान लेता है। नतीजा: अगला order छोटा, और आइटम फिर ख़त्म। यह चक्र चुपचाप आपके सबसे चलते हुए प्रोडक्ट्स की रेंज घटाता जाता है।
किसी भी फ़ॉर्मूले से पहले, हर अहम SKU के पिछले 8 से 12 हफ़्तों के data पर दस मिनट दीजिए। चार चीज़ें देखें:
नीचे आठ हफ़्तों का एक काल्पनिक SKU है। दूसरे हफ़्ते में 10 यूनिट का एक बार का बल्क order था, और चौथे हफ़्ते में आइटम एक दिन stock में नहीं था (सामान्य दैनिक रफ़्तार 50 ÷ 7 के हिसाब से क़रीब 7 यूनिट की बिक्री गई)।
| हफ़्ता | दर्ज बिक्री | समायोजन | साफ़ की गई डिमांड |
|---|---|---|---|
| 1 | 44 | 0 | 44 |
| 2 | 71 | −10 (बल्क order) | 61 |
| 3 | 52 | 0 | 52 |
| 4 | 31 | +7 (एक दिन stock नहीं) | 38 |
| 5 | 55 | 0 | 55 |
| 6 | 49 | 0 | 49 |
| 7 | 63 | 0 | 63 |
| 8 | 38 | 0 | 38 |
साफ़ किया गया कुल 400 यूनिट है, यानी औसत डिमांड 50 यूनिट प्रति हफ़्ता। कच्चा कुल 403 था, लगभग वही, लेकिन हफ़्तेवार तस्वीर दो जगह बिगड़ी हुई थी। बिगाड़ कितना है, यह product पर निर्भर करता है, और कम बिकने वाले SKU में यही पूरा नतीजा पलट सकता है।
सादा औसत मानकर चलता है कि अगला हफ़्ता पिछले कुछ हफ़्तों जैसा ही होगा। दो patterns इस मान्यता को तोड़ देते हैं।
Trend यानी महीनों में बिक्री का धीरे-धीरे चढ़ना या गिरना। अगर कोई product तीन महीने से हर महीने 5% बढ़ रहा है, तो पिछले आठ हफ़्तों का औसत हमेशा हक़ीक़त से पीछे रहेगा।
Seasonality यानी बार-बार लौटने वाला pattern: सर्दी के jackets, स्कूल खुलने से पहले कॉपी-किताबें, दिवाली या ईद की ख़रीदारी, मानसून, शादियों का सीज़न। इसे सँभालने का सबसे आसान तरीक़ा है seasonal index: किसी महीने की औसत बिक्री को सभी महीनों के औसत से भाग देना। दिसंबर का index 1.4 हो, तो दिसंबर में आम महीने से 40% ज़्यादा बिकता है। अपने base forecast को index से गुणा करें।
सीज़नैलिटी का भरोसेमंद अंदाज़ा लगाने के लिए कम से कम दो साल का इतिहास चाहिए। इससे कम हो, तो पिछले साल के उसी दौर को मोटा संकेत मानें, जानी-पहचानी तारीख़ों का कैलेंडर साथ रखें, और इस पर ज़रूरत से ज़्यादा भरोसा न करें।
स्थिर SKU के लिए moving average को हराना मुश्किल है: अगले हफ़्ते का forecast पिछले चार हफ़्तों का औसत। इसे समझाना आसान है, हाथ से जाँचना आसान है, और यह इतना धीमे प्रतिक्रिया देता है कि data के उतार-चढ़ाव के पीछे नहीं भागता। अगर exponential smoothing और trend-seasonality जोड़ने वाले दूसरे तरीक़े सीखने हैं, तो मुफ़्त किताब Forecasting: Principles and Practice अच्छा अगला क़दम है।
किसी भी तरीक़े को परखने का सही रास्ता है backtest: मान लीजिए आज बीता हुआ कल है, जिन हफ़्तों का नतीजा आपको पता है उनका forecast कीजिए, फिर मिलाकर देखिए। ऊपर के साफ़ data पर चार हफ़्तों का moving average हफ़्ता 5 से 8 का forecast इस तरह देता है:
| हफ़्ता | फ़ोरकास्ट (पिछले 4 हफ़्तों का औसत) | असल | error (असल − फ़ोरकास्ट) | निरपेक्ष error |
|---|---|---|---|---|
| 5 | 48.75 | 55 | +6.25 | 6.25 |
| 6 | 51.50 | 49 | −2.50 | 2.50 |
| 7 | 48.50 | 63 | +14.50 | 14.50 |
| 8 | 51.25 | 38 | −13.25 | 13.25 |
| कुल | 200.00 | 205 | +5.00 | 36.50 |
दो आँकड़े बता देते हैं कि forecast काम का है या नहीं।
WAPE (weighted absolute percentage error) यानी कुल निरपेक्ष error को कुल असल डिमांड से भाग देना। टेबल से: 36.5 ÷ 205 = 17.8%। यह ज़्यादा बिकने वाले आइटम को ज़्यादा वज़न देता है, और जब कुछ हफ़्ते कमज़ोर हों तब भी सही तस्वीर दिखाता है, जो सादा MAPE नहीं दिखा पाता।
Bias यानी कुल forecast घटा कुल असल, फिर कुल असल से भाग: (200 − 205) ÷ 205 = −2.4%। नेगेटिव bias का मतलब है कि आप कम आँक रहे हैं। अगर कई हफ़्तों तक bias एक ही तरफ़ टिका रहे, तो यह सुधारने का संकेत है, क्योंकि इसका मतलब है कि हर order लगातार एक ही दिशा में ग़लत है, या तो छोटा या बड़ा।
दोनों को हर SKU या कैटेगरी के लिए ट्रैक करें, पूरे स्टोर के लिए एक आँकड़ा नहीं। पूरे स्टोर का अच्छा आँकड़ा दर्जन भर ऐसे product छिपा सकता है जो हमेशा ग़लत रहते हैं। सबके लिए एक ही लक्ष्य नहीं होता: स्थिर रोज़मर्रा के आइटम में WAPE 10% से नीचे जा सकता है, जबकि फ़ैशन आइटम 40% पर भी सही सेफ़्टी stock के साथ ठीक सँभल सकता है।
Forecast बताता है कि कितना बिकेगा। Reorder point बताता है कि order कब देना है। नियम सीधा है:
Reorder point = lead time demand + safety stock
Lead time demand यानी साप्ताहिक औसत डिमांड को supplier के lead time से गुणा। हमारा SKU हफ़्ते में 50 बिकता है और supplier को 2 हफ़्ते लगते हैं, इसलिए lead time demand 50 × 2 = 100 यूनिट।
Safety stock उन हफ़्तों का बफ़र है जब बिक्री औसत से ऊपर जाती है। आम फ़ॉर्मूला:
Safety stock = z × σ × √L
हमारे साफ़ इतिहास में औसत 50 से विचलन हैं −6, +11, +2, −12, +5, −1, +13, −12। इनके वर्गों का जोड़ 644 है, और 644 ÷ 7 = 92, इसलिए σ = √92 ≈ 9.6 यूनिट। 95% service level और L = 2 हफ़्ते पर:
1.65 × 9.6 × √2 = 1.65 × 9.6 × 1.414 ≈ 22 यूनिट
Reorder point = 100 + 22 = 122 यूनिट। जब बिक्री के लिए उपलब्ध stock (on hand, जोड़ on order, घटा ग्राहकों के लिए reserved) 122 पर आ जाए, तब order दें।
यहाँ service level का मतलब है एक replenishment चक्र को stockout के बिना पार करने की संभावना। हर अतिरिक्त point पिछले से ज़्यादा महँगा पड़ता है।
| Service level | z | Safety stock | Reorder point |
|---|---|---|---|
| 90% | 1.28 | 17 | 117 |
| 95% | 1.65 | 22 | 122 |
| 99% | 2.33 | 32 | 132 |
95% से 99% पर जाने में 10 यूनिट बढ़ती हैं, यानी बफ़र 45% बड़ा, और stockout की आशंका लगभग हर 20 चक्र में एक बार से घटकर लगभग हर 100 चक्र में एक बार रह जाती है। सबसे अहम product के लिए यह सस्ता बीमा है। धीमे और भारी-भरकम आइटम के लिए नहीं।
यह फ़ॉर्मूला मानकर चलता है कि supplier भरोसेमंद है। अगर lead time भी ऊपर-नीचे होता है, तो विस्तृत फ़ॉर्मूला इस्तेमाल करें: z × √(L × σ² + d² × σL²), जहाँ d प्रति हफ़्ते की औसत डिमांड है और σL lead time का standard deviation (हफ़्तों में)। व्यवहार में इसका मतलब: delivery का असल समय दर्ज करते रहें, और अनियमित supplier के लिए बड़ा बफ़र रखें।
Reorder point बताता है कि order कब देना है। कितना देना है, यह target level से तय होता है: इतना order दें कि आपकी stock position (on hand, जोड़ on order, घटा reserved) वापस उस लेवल तक पहुँच जाए। हफ़्ते की समीक्षा के लिए काम चलाऊ टार्गेट है: lead time demand, जोड़ एक और हफ़्ते की demand, जोड़ safety stock: 50 × 3 + 22 = 172 यूनिट। जाँच के दिन position 118 हो, तो order 172 − 118 = 54 यूनिट का बनता है।
फिर supplier की शर्तें लगाएँ। न्यूनतम order 60 यूनिट हो, या माल 12 के carton में आता हो, तो 54 दोनों हालत में बढ़कर 60 हो जाता है। फ़्लोचार्ट में पूरा साप्ताहिक फ़ैसला है, data की उस जाँच समेत जो stockout वाले हफ़्ते को अगले हफ़्ते का order छोटा करने से रोकती है।
हर SKU को बराबर ध्यान नहीं दिया जा सकता। दो झटपट वर्गीकरण तय कर देते हैं कि मेहनत कहाँ लगे।
ABC प्रोडक्ट्स को value के हिसाब से क्रम में रखता है। चलन के मुताबिक़ A वे शीर्ष product हैं जो लगभग 80% revenue लाते हैं, B अगले 15%, और C आख़िरी 5%। XYZ उन्हें predictability के हिसाब से रखता है, coefficient of variation (σ ÷ औसत डिमांड) से। आम सीमाएँ: X यानी 0.5 से नीचे, Y यानी 0.5 से 1.0, Z यानी 1.0 से ऊपर। इन्हें अपने कारोबार के हिसाब से बदल लें।
हमारे उदाहरण वाले SKU का मान 9.6 ÷ 50 = 0.19 है, इसलिए यह X है। अगर यह टॉप सेलर भी है, तो यह AX है: automatic reorder point और साप्ताहिक review का आदर्श उम्मीदवार।
लेबल से ज़्यादा अहम आदत है: CZ आइटम को आपके हफ़्ते का एक घंटा भी नहीं मिलना चाहिए, और AZ आइटम को कभी अकेले formula के भरोसे नहीं छोड़ना चाहिए।
Machine learning models कुछ ही हालात में फ़ायदा देते हैं:
कुछ सौ SKU और पतले इतिहास वाली दुकान के लिए ये ठीक नहीं बैठते, जहाँ data ठीक से साफ़ किया हुआ moving average अक्सर उतना ही accurate होता है और उस पर भरोसा करना कहीं आसान। जो model आप ख़रीदार को समझा नहीं सकते, उसे ख़रीदार अपने फ़ैसले से पलट देगा।
तरीक़ा कोई भी चुनें, कसौटी एक ही रखें: अपने backtest पर उसे एक सादी baseline से भिड़ाएँ। अगर वह WAPE में moving average को साफ़ अंतर से नहीं हराता, तो moving average ही रखें। कुछ भी जटिल अपनाने से पहले बुनियाद पक्की करें: सटीक stock गिनती, हर stock movement का रिकॉर्ड और साफ़ बिक्री-इतिहास। यह सब एक जगह रखने वाला software, जैसे StoreConsole का inventory module, सफ़ाई वाले काम को काफ़ी कम हाथ का काम बना देता है। यह छोटा टूर हर SKU के low-stock alerts और forecast का आधार बनने वाली movement history दिखाता है।
Forecasting तभी फ़ायदा देती है जब वह आदत बन जाए। सेटअप हो जाने के बाद यह routine आधे घंटे में निपट जाती है।
हर तिमाही ABC/XYZ classes दोबारा देखें, seasonal indexes अपडेट करें, और ताज़ा σ और नापे गए lead times से safety stock नए सिरे से निकालें।
अब वापस केतली पर। Reorder point 122 और ऊपर वाली साप्ताहिक routine के साथ order तब चला जाता है जब available stock 122 छूता है, यानी शेल्फ़ पर अभी क़रीब ढाई हफ़्ते की बिक्री का माल बचा होता है। कैंडल होल्डर CZ आइटम हैं, इसलिए उन्हें गोदाम का कोना नहीं, हर तिमाही एक हाँ-ना का फ़ैसला मिलता है। शुक्रवार को हैरानियाँ अब भी आएँगी, पर यह वाली नहीं।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
