इन्वेंटरी रीऑर्डर सुझाव ऐप: Min/Max से ड्राफ्ट ऑर्डर तक

यह ऐप क्या हल करता है (और क्या नहीं)

स्टोर चलाना अक्सर दो महंगे गलतियों के बीच झूलना होता है: फास्ट-मूवर्स का आउट होना (खोए हुए बिक्री, नाराज़ ग्राहक) या बहुत ज़्यादा खरीद लेना (धीमी स्टॉक में पूंजी फँस जाना)। रोज़ाना समस्या यह नहीं है “क्या हमारे पास इन्वेंटरी है?” बल्कि “अगला क्या खरीदें और कितना?”, बिना घंटे बिताए स्प्रेडशीट गणना में।

Min/Max सेटअप उस निर्णय को सरल रखता है। हर SKU के लिए आप दो संख्याएँ स्टोर करते हैं:

• Min: वह सबसे कम स्तर जिस पर आप पहुंचने के बाद ही पुनः-आदेश करना चाहते हैं।
• Max: वह स्तर जो आप पुनः-आदेश के समय भरना चाहते हैं।

यदि किसी SKU की उपलब्धता 6 यूनिट है, Min 10 है, और Max 25 है, तो सुझाव 19 होगा। आप स्मृति से अनुमान नहीं लगा रहे — आप एक स्पष्ट नियम का उपयोग कर रहे हैं जो सप्ताह-दर-सप्ताह स्थिर रहता है।

एक inventory reorder suggestions ऐप आपके वर्तमान ऑन-हैंड काउंट्स (और विकल्प के रूप में जो पहले से ऑर्डर पर है) लेता है, उन Min/Max नियमों को प्रति SKU लागू करता है, और एक ड्राफ्ट खरीद सूची बनाता है। वह ड्राफ्ट मुख्य आउटपुट है: एक संक्षिप्त, समीक्षा योग्य सूची जो यह बताती है “हमें क्या ऑर्डर करना चाहिए और कितनी मात्रा?” इससे पहले कि कोई सप्लायर पोर्टल खोले या किसी रिप को ईमेल करे।

यह ऐप स्वतः खरीदारी नहीं करता — और यह महत्वपूर्ण है क्योंकि वास्तविक खरीद में अपवाद होते हैं: सप्लायर स्टॉक में नहीं है, केस पैक आकार राउंडिंग ज़रूरी है, मौसमी आइटम को छोड़ना चाहिए, या कोई प्रोमो आ रहा है। ऐप सुझाव तेजी से जनरेट करे, फिर एक मानव को लाइनों को अप्रूव, एडिट या हटाने दे।

यह उपकरण आमतौर पर स्टोर मैनेजर, ऑपरेशंस लीड और खरीद स्टाफ द्वारा इस्तेमाल होता है। छोटे टीमों के लिए भी यह उपयोगी है जहाँ एक व्यक्ति कई हैट पहनता है और सिर्फ़ एक भरोसेमंद शुरुआती बिंदु चाहता है।

हर SKU के लिए स्टोर करने के लिए डेटा

अच्छे सुझाव उबाऊ, लगातार SKU डेटा से शुरू होते हैं। अगर बेसिक्स गन्दा हैं, तो आपका ड्राफ्ट खरीद सूची यादृच्छिक लगेगी और लोग इसका भरोसा बंद कर देंगे।

किसी SKU रिकॉर्ड का “आकृति” समय के साथ एक सी बनी रहे, इसका लक्ष्य रखें, भले ही आपकी प्रक्रिया बदल जाए।

कोर SKU फ़ील्ड (कम से कम जो काम करते हैं)

दिन एक पर उपयोगी रहने के लिए आपको चाहिए:

• एक SKU पहचानकर्ता (वह कोड जिसे आप स्कैन या टाइप करते हैं) और एक छोटा नाम जिसे लोग पहचानते हों
• माप की इकाई (each, bottle, box, kg) ताकि काउंट्स और ऑर्डर एक ही मायने रखें
• स्थिति (active/inactive) ताकि डिसकॉन्टिन्यूड आइटम बार-बार न दिखें
• Min और Max स्तर (और वैकल्पिक रूप से एक अलग reorder point)
• नोट्स और “last updated” जानकारी (टाइमस्टैम्प और/या किसने अपडेट किया)

Min और Max गार्डरेल हैं। एक अलग reorder point वैकल्पिक है, पर उपयोगी होता है जब आप लंबे लीड टाइम या अस्थिर सप्लाई के कारण Min से पहले ही reorder करना चाहें।

उपलब्धता और ऑर्डरिंग डिटेल्स (जो गणना को वास्तविक बनाते हैं)

ये विवरण “कितना खरीदना है” को “आप वास्तव में कितना ऑर्डर कर सकते हैं” में बदल देते हैं:

• ऑन-हैंड मात्रा, स्पष्ट स्रोत के साथ (अभी मैन्युअल काउंट, बाद में सिंक संभव)
• प्रिफर्ड सप्लायर (या प्राइमरी वेंडर)
• पैक साइज (case quantity) ताकि आप वैध मल्टीपल्स में ऑर्डर करें
• लीड टाइम (दिन)
• मिनिमम ऑर्डर मात्रा (MOQ)

यह स्पष्ट रखें कि “on hand” कहाँ से आता है। अगर आप मैन्युअल एंट्री से शुरू करते हैं, तो आख़िरी काउंट डेट स्टोर करें। बाद में अगर आप POS या वेयरहाउस टूल से सिंक करेंगे तो आख़िरी सिंक टाइम भी स्टोर करें। यह एक विवरण बहुत सारे “इसने यह क्यों सुझाया?” सवालों का जवाब देता है।

Min/Max सुझाव कैसे गणना किए जाते हैं

Min/Max एक सरल नियम है: आप तभी ही reorder करते हैं जब स्टॉक कम हो, और आप इतना ऑर्डर करते हैं कि स्टॉक एक सुरक्षित स्तर तक लौट आये। परिणाम एक ड्राफ्ट सूची है जो समझने और ऑडिट करने में आसान है।

1) आप कब reorder ट्रिगर करते हैं?

एक ट्रिगर चुनें और उसे लगातार रखें। सबसे सामान्य है:

• यदि On Hand Min के बराबर या उससे कम है (कभी-कभी इसे reorder point कहा जाता है), तो आइटम योग्य माना जाता है।
• यदि On Hand Min से ऊपर है, तो सुझाव शून्य है और आइटम ड्राफ्ट सूची में नहीं आता।

यह उन सुझावों से बचाता है जो पहले से स्वस्थ आइटम्स के लिए शोर पैदा करते हैं।

2) आप कितनी मात्रा सुझाते हैं?

एक बार आइटम योग्य हो जाने पर, आधार विचार है “Max तक ऑर्डर करें।” सरल सूत्र है:

base_suggested = max - on_hand
suggested = max(0, base_suggested)

उदाहरण: Min = 10, Max = 40, On Hand = 14.

• On Hand (14) Min (10) से ऊपर है, इसलिए suggested = 0।

अगर On Hand 8 हो गया:

• base_suggested = 40 - 8 = 32
• suggested = 32

ड्राफ्ट को वास्तविक बनाते हुए सरल समायोजन

बेस गणना के बाद, कुछ छोटे नियम जोड़ें ताकि खरीद वास्तविक दुनिया के अनुरूप हो:

• Case pack rounding: अगर आपको 12 के पैक में ही खरीदना है, तो 32 को 36 पर राउंड करें।
• MOQ: अगर MOQ 50 है, तो 36 को 50 पर बढ़ा दें।
• नेवर सजेस्ट नेगेटिव्स: अगर On Hand 55 है और Max 40 है, तो बेस -15 आता है, पर सुझाव 0 होना चाहिए।
• वैकल्पिक कैप: अगर आप बड़े ऑर्डर्स से बचना चाहते हैं तो अधिकतम ऑर्डर मात्रा पर कैप लगाएं।

शुरुआती किन मामलों को हैंडल करें

खराब डेटा खराब सुझाव बनाता है, इसलिए इन स्थितियों को स्पष्ट करें:

• Discontinued SKUs: हमेशा सुझाव 0 दें, भले ही स्टॉक कम हो।
• Negative inventory: इसे रेड फ्लैग मानें; गणना करें, पर समीक्षा के लिए चेतावनी दिखाएँ।
• Missing Min/Max: अनुमान न लगाएं। सुझाव 0 रखें और SKU को “needs setup” के रूप में चिह्नित करें।

यूज़र फ्लो: इन्वेंटरी काउंट से ड्राफ्ट खरीद सूची तक

सर्वोत्तम फ्लो वही है जो आपकी टीम वास्तव में उपयोग करे। इसे सरल रखें: जो आपके पास है उसे रिकॉर्ड करें, फिर सुझाव जनरेट करें। अतिरिक्त सुविधाएँ (लेबल, डैशबोर्ड, एनालिटिक्स) बाद में आ सकती हैं।

एक सामान्य सेशन कुछ यूँ दिखता है: उपयोगकर्ता त्वरित काउंट करता है, एक लोकेशन चुनता है (यदि ज़रूरी हो), प्रति SKU काउंट दर्ज करता है, सेव करता है, फिर एक बटन दबाकर ड्राफ्ट खरीद सूची बनाता है। बायर उस ड्राफ्ट की समीक्षा करता है और किसी भी चीज़ को अप्रूव करने से पहले एडजस्ट करता है।

स्क्रीन को शांत रखने के लिए एक व्यावहारिक फ़िल्टर जोड़ें: केवल Min से नीचे वाले SKU दिखाएँ, या सभी SKU स्पष्ट स्थिति के साथ दिखाएँ। “सिर्फ़ नीचे Min” व्यस्त दिनों में तेज़ होता है। “सभी दिखाएँ” तब मदद करता है जब आप सुनिश्चित करना चाहते हैं कि कुछ छूट न गया हो।

एक सरल फ्लो जो अधिकांश छोटे टीमों के लिए काम करता है:

• ऑन-हैंड काउंट दर्ज या इम्पोर्ट करें
• सुझाव जनरेट करें
• ड्राफ्ट सूची की समीक्षा करें (केवल नीचे min या सभी स्थिति के साथ)
• सुझाई गई मात्राओं को एडिट करें और नोट्स जोड़ें
• ड्राफ्ट को अप्रूव करें और खरीद के लिए एक्सपोर्ट/शेयर करें

ओवरराइड्स महत्वपूर्ण हैं क्योंकि वास्तविकता जटिल है। कोई बायर प्रोमो के लिए अतिरिक्त ऑर्डर कर सकता है, या नकद कठिनाई के कारण कम कर सकता है, या सप्लायर देरी में हो सकता है। सुझावित मात्रा को एक शुरुआती बिंदु मानें, नियम नहीं।

कुछ छोटे कंट्रोल्स बहुत निराशा रोकते हैं:

• मैनुअल ओवरराइड मात्रा (और किसने बदला)
• “होल्ड” फ़्लैग ताकि फिलहाल किसी आइटम का रीऑर्डर रोका जा सके
• वैकल्पिक कारण फ़ील्ड (seasonal, vendor issue, clearance)

अंततः, ड्राफ्ट जनरेट होने पर एक स्नैपशॉट सहेजें: टाइमस्टैम्प, उपयोग किए गए ऑन-हैंड काउंट्स, उस क्षण के min/max मान, और ओवरराइड्स से पहले की सुझाई गई मात्राएँ। जब कोई पूछे “हमने यह 24 क्यों ऑर्डर किया?”, आप ड्राफ्ट खोल कर वही इनपुट देख सकेंगे जिसने इसे उत्पन्न किया था।

एक सरल डेटाबेस संरचना जो लचीली रहे

एक अच्छा reorder ऐप भरोसेमंद छोटी तालिकाओं से शुरू होता है। लक्ष्‍य परफेक्ट ERP नहीं है, बल्कि एक साफ़ बेस है जो सप्लायर्स, लोकेशन्स, या स्मार्ट नियम जोड़ने पर बढ़ सके।

शुरू करने के लिए कोर टेबल्स

एक एकल स्टोर के लिए, “आइटम क्या है” को “आपके पास क्या है” और “आप कैसे रीऑर्डर करते हैं” से अलग रखें:

• SKUs: प्रति आइटम एक पंक्ति (SKU कोड, नाम, यूनिट, कैटेगरी, active/inactive)
• Suppliers: सप्लायर नाम और संपर्क विवरण (और यदि आप ट्रैक करते हैं तो शर्तें जैसे लीड टाइम)
• Reorder settings: प्रति SKU min, max, reorder point, प्रिफर्ड सप्लायर, पैक साइज
• Inventory levels: प्रति SKU वर्तमान ऑन-हैंड (बाद में, प्रति लोकेशन) और आख़िरी काउंट डेट
• Draft orders: एक हेडर (सप्लायर, स्टेटस, बनाया किसने) और लाइंस (SKU, सुझाई गई qty, अंतिम qty)

यह लचीला रहता है क्योंकि आप रीऑर्डर नियम बदल सकते हैं बिना SKU लिस्ट को फिर से लिखे, और आप ड्राफ्ट ऑर्डर्स को सुझाव बनाम अप्रूव्ड रिकॉर्ड के रूप में रख सकते हैं।

अगर आज आपके पास केवल एक स्टोर है तो लोकेशन्स पर ओवरबिल्ड न करें। हर SKU के लिए इन्वेंटरी एक एकल संख्या के रूप में रखें। जब आप दूसरा स्टोर या वेयरहाउस जोड़ें, तो एक Locations तालिका जोड़ें और Inventory levels को प्रति SKU प्रति लोकेशन की पंक्ति में बदल दें।

गार्डरेल्स, भूमिकाएँ और एक्सपोर्ट्स

छोटी वैलिडेशन नियम बुरे इनपुट को बुरे ऑर्डर्स में बदलने से रोकते हैं। जैसे कि: min को max से कम होना चाहिए, reorder points नकारात्मक नहीं हो सकते, और pack size शून्य नहीं होना चाहिए। तय करें कि जब सेटिंग्स गायब हों तो क्या होगा: सुझाव रोका जाए, या SKU को "needs setup" के रूप में चिह्नित किया जाए।

भूमिकाएँ तब मदद करती हैं जब कई लोग स्टॉक गिनते हैं और नियम बदलते हैं:

• Viewer: SKUs और ड्राफ्ट ऑर्डर्स देख सकता है
• Editor: काउंट्स और reorder सेटिंग्स अपडेट कर सकता है
• Approver: मात्राओं को अंतिम रूप दे सकता है और ड्राफ्ट ऑर्डर को अप्रूव कर सकता है

यह तय करें कि आप ऑर्डर्स कैसे भेजेंगे। भले ही बाद में आप खरीद को ऑटोमेट करें, अधिकांश टीमें पहले सरल एक्सपोर्ट से शुरू करती हैं: CSV डाउनलोड या सप्लायर-रेडी लिस्ट जिसे ड्राफ्ट स्क्रीन से कॉपी किया जा सके।

स्टेप-बाय-स्टेप: ऐप स्क्रीन और लॉजिक बनाना

दो सरल सूचियों से शुरू करें: आपकी SKU कैटलॉग और आपके सप्लायर्स। हर SKU के पास एक नाम होना चाहिए जिसे लोग रोज़ पहचानें, एक डिफ़ॉल्ट सप्लायर, और एक खरीद इकाई (each, case, carton)। इसे व्यावहारिक रखें—यह वह सूची है जिसे आपकी टीम हर दिन सर्च करेगी।

अगला, SKU रिकॉर्ड में reorder settings जोड़ें। Min और Max मूल हैं, पर आप बेहतर सुझाव तब पाएँगे जब आप पैक साइज और लीड टाइम भी स्टोर करेंगे। अगर आप एक ही आइटम दो सप्लायर्स से खरीदते हैं, तो एक को डिफ़ॉल्ट चुनें और ड्राफ्ट ऑर्डर पर बाद में बदलने की अनुमति दें।

इन्वेंटरी काउंट्स के लिए एक तेज़ स्क्रीन बनाएं जो परफ़ेक्शन से अधिक गति को प्राथमिकता दे। एक त्वरित एडिट ग्रिड अच्छी तरह काम करता है: आइल या कैटेगरी से फ़िल्टर करें, गिनी हुई मात्रा टाइप करें, और सेव करें।

अधिकांश टीमों को इन कोर स्क्रीन की ज़रूरत होगी:

• SKU सूची और SKU डिटेल्स (Min, Max, पैक साइज, लीड टाइम सहित)
• सप्लायर सूची और सप्लायर डिटेल्स
• इन्वेंटरी काउंट एंट्री (ग्रिड + फ़िल्टर)
• रीऑर्डर सुझाव (रिजल्ट टेबल + सरल क्रियाएं)
• ड्राफ्ट खरीद आदेश (एडिटेबल लाइंस + अप्रूवल)

फिर सुझाव लॉजिक लागू करें: प्रति SKU, on_hand (और वैकल्पिक रूप से on_order) की तुलना करें आपके रीऑर्डर नियमों से, सुझाई गई मात्रा की गणना करें ताकि Max के निकट पहुँचा जा सके, और पैक साइज राउंडिंग लागू करें ताकि आप 13 यूनिट का सुझाव न दिखाएँ जब सप्लायर केवल 12 के केस बेचता हो।

समीक्षा के लिए एक ड्राफ्ट ऑर्डर जनरेट करें और उसे एक दस्तावेज़ की तरह ट्रीट करें—Draft, Approved, Sent जैसे स्टेटस रखें। जब कोई यूज़र एक ड्राफ्ट बनाता है, सुझाव लाइनों को सप्लायर के हिसाब से ग्रुप कर के ऑर्डर लाइनों में कॉपी करें, फिर लोगों को मात्राएँ एडिट करने, सप्लायर बदलने, या आइटम हटाने दें।

अंत में साफ़ आउटपुट स्टेप रखें। कुछ टीमें ड्राफ्ट प्रिंट कर के मैन्युअली ऑर्डर देती हैं। अन्य एक फ़ाइल एक्सपोर्ट करते हैं। किसी भी स्थिति में, जो कुछ अप्रूव हुआ उसे सेव करें ताकि आप बाद में “सुझाया गया बनाम ऑर्डर्ड” की तुलना कर सकें और अपने नियमों को वास्तविक सबूत के साथ बेहतर बनाएं।

सामान्य गलतियाँ जो सुझाव अविश्वसनीय बनाती हैं

रीऑर्डर गणित सरल है। भरोसा तब टूटता है जब सेटअप गन्दा होता है। ज्यादातर समस्याएँ तब दिखती हैं जब ड्राफ्ट सूची “अजीब” लगती है, भले ही सूत्र सही हो।

क्लासिक समस्या है मिक्स्ड यूनिट्स। आप "each" गिनती करते हैं, पर आप कैस में ऑर्डर करते हैं, या आप रिसीव करते हैं पैक्स में। अगर किसी SKU की यूनिट अस्पष्ट है, तो ऐप 24 का सुझाव दे सकता है जबकि आप 24 केस चाहते थे। प्रति SKU एक बेस यूनिट चुनें (अक्सर “each”) और एक कन्वरजन स्टोर करें जैसे "1 case = 24 each" ताकि अंतिम ऑर्डर मात्रा सही ढंग से ट्रांसलेट हो।

Min और Max भी अनुमान की तरह सेट हो जाते हैं। अगर आप बिक्री गति और सप्लायर लीड टाइम को नज़रअंदाज़ करते हैं, तो नियम साफ़ दिखेंगे पर असली जिंदगी में फेल होंगे। धीमी-चलने वाले आइटम का high max कैश बाँध देता है, जबकि तेज़ मूवर्स का low min स्टॉकआउट बनाता है।

अन्य सामान्य गलतियाँ:

• लोकेशन्स को ट्रैक न करना (बैक रूम बनाम शेल्फ, स्टोर A बनाम स्टोर B), फिर आश्चर्य करना कि ऑन-हैंड कभी मैच क्यों नहीं करता
• कोई भी मिन/मैक्स एडिट कर सकता है बिना बेसिक अप्रूवल प्रोसेस के
• पिछले मानों को ओवरराइट कर देना ताकि आप यह नहीं बता सकें कि पिछला ऑर्डर क्यों हुआ
• डैमेज्ड, रिज़र्व्ड, या इन-ट्रांज़िट स्टॉक को उपलब्ध मान लेना
• कुछ दिनों पुरानी गिनतियाँ इस्तेमाल करना और फिर सुझाव को दोष देना

एक साधारण परिदृश्य: आप कॉफी पॉड्स बेचते हैं। शेल्फ पर 6 बॉक्स दिखते हैं, बैक रूम में 18 हैं, और दूसरे स्टोर में 12 हैं। अगर आप केवल एक "on hand" संख्या ट्रैक करते हैं, कोई 6 गिनता है और सिस्टम सुझाव देता है, जबकि वास्तविकता में आपके पास 36 हैं। लोकेशन फ़ील्ड्स यह समस्या जल्दी ठीक कर देते हैं।

ड्राफ्ट सूची पर भरोसा करने से पहले त्वरित जाँचें

एक Min/Max सिस्टम सरल है, पर ड्राफ्ट सूची उतनी ही अच्छी है जितना उसके पीछे का डेटा। किसी भी चीज़ को सप्लायर को भेजने से पहले एक मिनट में उन शांत त्रुटियों की जाँच करें जो सुझावों को आत्मविश्वास भरा पर गलत बना सकती हैं।

सेटअप से शुरू करें: हर रीऑर्डरेबल SKU के लिए मिन, मैक्स और सही पैक साइज चाहिए। अगर इनमें से कोई गायब है, ऐप को SKU को फ़्लैग करना चाहिए और उसे स्किप करना चाहिए या "needs setup" दिखाना चाहिए। एक खाली फ़ील्ड चुपचाप एक बड़ा ऑर्डर या कोई ऑर्डर नहीं दोनों पैदा कर सकती है।

फिर ऑन-हैंड मात्राओं की संज्ञान लें। नेगेटिव स्टॉक होता है (रिटर्न देर से प्रोसेस, रिसीविंग पोस्ट नहीं हुआ, यूनिट मिक्स-अप), पर यह दुर्लभ होना चाहिए। अगर आप किसी धीमे आइटम के लिए -12 देखते हैं, तो सुझाव को "जांच करें" मानें, न कि "खरीदें"। एक री-काउंट या त्वरित ट्रांज़ेक्शन रिव्यू बाद में बड़ी समस्या सुलझाने से सस्ता है।

एक छोटा चेकलिस्ट जो अधिकांश समस्याएँ पकड़ लेता है:

• सेटअप: हर रीऑर्डरेबल SKU के लिए मिन, मैक्स, पैक साइज, और सप्लायर भरा हुआ
• मात्राएँ: ऑन-हैंड तर्कसंगत दिखें (500 के बजाय 50 जैसे स्पष्ट टाइपो न हो)
• पैकेजिंग: सुझाव केस पैक्स पर राउंड होते हैं और MOQ का सम्मान करते हैं
• नीति: सब जानते हों कि आप Max तक ऑर्डर कर रहे हैं या कोई अधिक संरक्षित लक्ष्य अपनाया गया है
• ट्रेसबिलिटी: एडिट्स दिखाएँ कि किसने और कब बदला

पैकेजिंग नियमों पर विशेष ध्यान दें। अगर आपका सप्लायर 24 के केस में बेचता है और ड्राफ्ट 13 सुझाता है, सिस्टम को आपकी नीति के अनुसार समायोजित करना चाहिए (अक्सर स्टॉकआउट से बचने के लिए ऊपर की ओर राउंड)। MOQ के लिए भी वही विचार लागू है: मूल सुझाव और समायोजित सुझाव दोनों दिखाएँ ताकि समीक्षक समझ सके क्या बदला।

यह भी फ़ैसला कर लें कि आपकी टीम के लिए "काफ़ी अच्छा" क्या मतलब है। Max तक ऑर्डर करना आक्रामक है और कैश बाँध सकता है। एक ज़्यादा सतर्क लक्ष्य (उदा., केवल टॉप मूवर्स के लिए Max तक ऑर्डर करें, और धीमे आइटम्स के लिए मध्यवर्ती लक्ष्य) Overstock घटा सकता है जब तक आप सिस्टम पर भरोसा नहीं बना लेते।

अंत में, ऑडिट ट्रेल रखें। हर लाइन पर एक सरल “Last changed by” और “Last changed at” भरोसा बनाता है और बाद में विवाद सुलझाने में मदद करता है।

उदाहरण: एक छोटे स्टोर के लिए साप्ताहिक रीऑर्डर

कल्पना कीजिए एक छोटे पड़ोसी शॉप की जो 30 SKUs रखती है। मालिक हर सोमवार सुबह फ़िजिकल काउंट करता है और चाहता है कि एक इन्वेंटरी reorder suggestions ऐप एक ड्राफ्ट खरीद सूची बनाए जिसे वह जल्दी से सैनीटी-चेक कर सके।

वे दो सप्लायर्स से खरीदते हैं: Supplier A (snacks और drinks) और Supplier B (household basics)।

तीन SKUs और सुझाव गणित

SKU 1: Sparkling Water 12-pack (Supplier A)

On hand: 8 packs. Min: 10. Max: 30. Pack size: 6.

क्योंकि 8 Min (10) से कम है, ऐप बताता है कि Max तक ऑर्डर करें।

Max तक पहुँचने के लिए जरूरत = 30 - 8 = 22 packs.

Pack size (6) पर राउंड करने पर 22 बनता है 24.

सुझावित ऑर्डर: 24 packs.

SKU 2: Potato Chips (Supplier A)

On hand: 14 bags. Min: 12. Max: 36. Pack size: 12.

क्योंकि 14 Min से ऊपर है, सुझाव 0 है। यद्यपि यह Max तक नहीं है, पर यह इस सप्ताह पुनः-पूर्ति की ज़रूरत नहीं दिखाता।

SKU 3: Dish Soap 500 ml (Supplier B)

On hand: 3 bottles. Min: 6. Max: 18. Pack size: 6.

क्योंकि 3 Min से नीचे है, Max तक ऑर्डर करें।

Max तक पहुँचने के लिए जरूरत = 18 - 3 = 15 bottles.

Pack size (6) पर राउंड करने पर 15 बनता है 18.

सुझावित ऑर्डर: 18 bottles.

बायर समायोजन (बजट और आम समझ)

ड्राफ्ट सूची एक प्रारम्भिक बिंदु है, कमांड नहीं। इस सप्ताह मालिक का बजट तंग है और उन्हें पता है कि बारिश होने पर स्पार्कलिंग वाटर की बिक्री धीमी हो जाती है।

उन्होंने Sparkling Water को 24 packs से घटाकर 18 packs कर दिया (जो अभी भी 6 के गुणक में है)। चिप्स 0 पर रहे। डिश सोप 18 पर रहा क्योंकि यह नियमित बिकने वाला आइटम है और वर्तमान में रिस्की दिखता है।

यह समीक्षा-और-ट्वीक्स चरण ही कारण है कि ड्राफ्ट अक्सर ऑटो-भेजने से अधिक उपयोगी होता है।

क्लीन ड्राफ्ट खरीद सूची (सप्लायर के हिसाब से समूहित)

Supplier A

• Sparkling Water 12-pack: 18 packs (24 से समायोजित)
• Potato Chips: 0

Supplier B

• Dish Soap 500 ml: 18 bottles

केवल 30 SKUs के साथ यह साप्ताहिक लूप लगभग 10 मिनट ले सकता है: काउंट, सुझावों की समीक्षा, कुछ एडिट्स, फिर प्रत्येक सप्लायर के लिए समूहित ड्राफ्ट शेयर करना।

अगले कदम: छोटा लॉन्च करें, फिर नियम सुधारें

सबसे तेज़ तरीका मूल्य प्राप्त करने का है संकुचित शुरुआत करना। एक स्टोर (या एक लोकेशन) और एक सप्लायर समूह चुनें जिनके SKU गिनने में आसान हों। आप साफ़, समीक्षा किए हुए ड्राफ्ट सूची से अधिक सीखेंगे बनिस्बत यह कोशिश करने के कि पहले दिन हर एज केस कवर किये जाएँ।

जल्दी तय कर लें कि आप ऑन-हैंड काउंट्स कैसे पकड़ेंगे। मैन्युअल एंट्री पहले ठीक है, बशर्ते यह लगातार हो। एक सरल नियम जैसे "काउंट्स हर गुरुवार ऑर्डर करने से पहले अपडेट होते हैं" एक जटिल सेटअप से बेहतर है जिसे कोई भरोसा नहीं करता।

एक व्यावहारिक रोलआउट योजना:

• 20-50 SKUs के साथ शुरू करें जो गिनने में आसान हों और राजस्व के लिए महत्वपूर्ण हों
• 2-3 साइकिल के लिए एक मैनेजर के साथ ड्राफ्ट सूची की समीक्षा करें इससे पहले कि आप इससे ऑर्डर प्लेस करें
• प्रति SKU एक छोटा नोट फील्ड रखें (उदा.: “seasonal” या “case pack is 12”)
• पहली समूह स्थिर महसूस होने पर ही अगले सप्लायर पर विस्तार करें

जब बेसिक्स काम करने लगें, तो धीरे-धीरे गणित सुधारेँ। दो उन्नयन जो जल्दी फायदा देते हैं: औसत मांग अनुमान (जैसे "पिछले 4 सप्ताह की औसत साप्ताहिक बिक्री") और लीड टाइम के आधार पर थोड़ा सुरक्षा स्टॉक। अगर किसी सप्लायर का लीड टाइम 10 दिन है, तो reorder point को अतिरिक्त एक सप्ताह की मांग से बढ़ाना देरी से बचा सकता है।

नियमों को ईमानदार रखने के लिए तालिका बनाएं। साप्ताहिक रूप से सुझाए गए ऑर्डर की समीक्षा करें और स्पष्ट मिसेस ठीक करें। मासिक रूप से min/max मान समायोजित करें, टॉप मूवर्स और सबसे बड़े Overstock जोखिमों पर ध्यान केंद्रित करें।

अगर आप इसे नो-कोड इन्वेंटरी ऐप के रूप में बना रहे हैं, AppMaster (appmaster.io) एक विकल्प है जो वर्कफ़्लो में फिट बैठता है: SKUs और सप्लायर्स को डेटाबेस में मॉडल करें, मिन/मैक्स लॉजिक को विज़ुअल प्रोसेस में डालें, और ऐसा ड्राफ्ट ऑर्डर जनरेट करें जिसे स्टाफ समीक्षा और अप्रूव कर सके।