मांग पूर्वानुमान

रसोइया हर सुबह एक ही सवाल का जवाब देता है: कितना और क्या तैयार करना है। खरीदार — उससे जुड़ा सवाल: कितना और क्या ऑर्डर करना है। आम तौर पर दोनों याददाश्त से जवाब देते हैं।

एडमिन पैनल → इन्वेंटरी → “पूर्वानुमान” टैब खोलें (admin.cenaly.com/inventory)। यह टैब बिक्री इतिहास लेता है और उसे तीन ठोस चीज़ों में बदल देता है। स्क्रीन पर क्रम तात्कालिकता के हिसाब से है: सबसे ऊपर वह, जो दिन खत्म होने से पहले खत्म हो सकता है, नीचे — तैयारी की योजना, और उससे नीचे — आपूर्तिकर्ता के लिए ऑर्डर का ड्राफ़्ट। अगर कोई जोखिम वाला आइटम नहीं है, तो ऊपरी ब्लॉक बिल्कुल नहीं दिखेगा। सबसे नीचे, सिकुड़ी हुई मदद के रूप में “व्यंजनों के अनुसार पूर्वानुमान” तालिका है — जब तक किसी आंकड़े को जाँचना न चाहें, उसे देखने की ज़रूरत नहीं।

AWS ब्रांड्स पर उपलब्ध (cenaly.com, cenaly.com और अन्य), cenaly.ru पर नहीं। प्लेटफ़ॉर्म का विश्लेषणात्मक आधार, जो पूर्वानुमान के लिए बिक्री इतिहास की गणना करता है, रूसी परिपथ में स्थापित नहीं है। वहाँ “पूर्वानुमान” टैब खुलता तो है, लेकिन हमेशा “मांग का पूर्वानुमान लगाने के लिए अभी ऑर्डर का इतिहास कम है” दिखाता है — चाहे असल में कितनी भी बिक्री जमा हो चुकी हो।

पूर्वानुमान कैसे निकाला जाता है#

ठीक दो आँकड़े, दोनों रसोइये को ज़ुबानी समझाए जा सकने वाले:

इस व्यंजन की इस सप्ताह के इस दिन आम तौर पर कितनी बिक्री होती है। इतिहास की विंडो — 8 सप्ताह (56 दिन)। बिंदु अनुमान — माध्यिका, औसत नहीं: आठ मंगलवार, जिनमें से एक 40 लोगों के जन्मदिन का दिन था, औसत के हिसाब से हर सप्ताह “40 के लिए तैयार करो” कहेंगे, जबकि माध्यिका उस मंगलवार को नज़रअंदाज़ कर देती है। संदर्भ तालिका “व्यंजनों के अनुसार पूर्वानुमान” में संख्या के बगल में अवलोकनों का ईमानदार फैलाव (न्यूनतम–अधिकतम), नमूने में कितने अवलोकन हैं और पीक — दिन के उस हिस्से की सबसे बड़ी बिक्री हिस्सेदारी — दिखाया जाता है। टैब के हेडर में गणना का आधार लिखा होता है: “56 दिनों के उसी सप्ताह-दिन की माध्यिका · इतिहास के N कार्यदिवस”।
यह मांग दिन के भीतर कैसे बँटी है — दिन के हिस्सों के अनुसार हिस्सेदारी: सुबह (6–11), दोपहर (11–16), शाम (16–23), रात (23–6)। सीमाएँ सभी प्रतिष्ठानों के लिए एक जैसी हैं, और प्रोफ़ाइल सभी इतिहास-दिनों के आधार पर एक साथ निकाली जाती है, मंगलवारों के लिए अलग से नहीं।

अवलोकन किसे माना जाए, यह भी सोच-समझकर तय किया गया है: रद्द किए गए ऑर्डर इतिहास में नहीं जाते; आज का बिना बंद हुआ दिन नमूने में नहीं आता; व्यंजन की पहली बिक्री से पहले के दिन शून्य नहीं गिने जाते (नई डिश को उन हफ़्तों के लिए “शून्य बिक्री” नहीं मिलती जब वह मेन्यू में ही नहीं थी); “बिना बिक्री वाला दिन” और “वह दिन जब प्रतिष्ठान बंद था” अलग-अलग हैं। दिन की गणना शाखा के समय क्षेत्र में होती है। गणना में शाखा के कारोबार के हिसाब से टॉप-500 आइटम लिए जाते हैं — मेन्यू की लंबी पूँछ काट दी जाती है।

कोई मशीन लर्निंग नहीं — और यह एक फ़ैसला है, कमी नहीं। एक से दस शाखाओं वाले प्रतिष्ठान का इतिहास दशकों में नहीं, हफ़्तों में नापा जाता है, और उसमें आउटलायर आर-पार दिख जाते हैं: बारिश, पड़ोस में कॉन्सर्ट, एक उदार टेबल। ऐसे डेटा पर मॉडल शोर के हिसाब से ढल जाते हैं और ऐसे पक्के आँकड़े देते हैं जिन पर भरोसा नहीं किया जा सकता।

सप्ताह के किसी एक दिन के तीन से कम अवलोकन — संख्या नहीं आएगी। तालिका में अंक की जगह डैश रहेगा, और अवलोकन कॉलम में “कम” का निशान। ऐसा व्यंजन तैयारी की योजना और खरीद में बिल्कुल नहीं आएगा। जिस पूर्वानुमान पर भरोसा न किया जा सके, वह न होने से बुरा है: उसी के हिसाब से तैयारी और खरीद होती है।

ऊपर का टॉगल चुनता है कि पूर्वानुमान किस दिन के लिए बनाना है — आज या कल।

तैयारी की योजना#

व्यंजनों का पूर्वानुमान टेक-कार्ड के ज़रिए सामान और अर्ध-तैयार उत्पादों की ज़रूरत में बदल जाता है। यह विस्तार मौजूदा टेक-कार्ड के हिसाब से होता है, टैब खोलने के समय — अगर शेफ ने सुबह रेसिपी बदली, तो योजना उसे ध्यान में रखेगी (बगल की विंडो में किया गया बदलाव पेज रीफ़्रेश करने पर उठा लिया जाएगा)।

नेस्टेड अर्ध-तैयार उत्पाद गहराई तक खुलते हैं: अगर सॉस बुलियन से बनता है, और बुलियन भी अर्ध-तैयार उत्पाद है, तो योजना में दोनों आएँगे — वरना रसोइये को सॉस बनाने कहा जाता बिना यह बताए कि उसके लिए बुलियन नहीं है। नेस्टिंग की गहराई पाँच स्तरों तक सीमित है (और एक-दूसरे को गोल-गोल संदर्भित करने वाली रेसिपियों से सुरक्षित है): जो इससे गहरा है, वह कच्चा माल माना जाता है और तैयारी की योजना में नहीं, खरीद में जाता है।

योजना की तालिका:

कॉलम	क्या दर्शाता है
सामान का नाम	वह अर्ध-तैयार उत्पाद जिसे बनाना है
शेष	कितना पहले से है
चाहिए	दिन के पूर्वानुमान के अनुसार कुल ज़रूरत
बनाना है	कमी — असल में कितना पकाना/काटना है
कब तक	वह घंटा जब तक शेष पूरा नहीं पड़ेगा

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

अर्ध-तैयार उत्पाद का शेष एक बार खर्च होता है: अगर वही बुलियन सॉस में भी जाता है और सूप में भी, तो सीधा-सादा हिसाब शेष को दो बार लगा देता और खरीद में कच्चा माल कम पड़ जाता।

“शिफ्ट बोर्ड पर” बटन योजना को कार्यों की चेकलिस्ट में बदल देता है — देखें शिफ्ट के कार्यों का बोर्ड। एक साझा कार्य बनता है “तैयारी की योजना — <तारीख़>”, और हर तैयारी उसका उप-कार्य बन जाती है जिसमें मात्रा और घंटा सीधे शीर्षक में होता है (“डेमीग्लास सॉस — 11:00 तक 16 पीस”); साझा कार्य तभी बंद किया जा सकता है जब सभी उप-कार्य बंद हों। दोबारा दबाने से डुप्लिकेट नहीं बनते: अगर उस तारीख़ की योजना पहले से बोर्ड पर है, तो बटन यही बताएगा।

बिना टेक-कार्ड वाले व्यंजन योजना में नहीं आते और एक अलग चेतावनी में गिनाए जाते हैं (20 नाम तक): उनके बारे में पूर्वानुमान कुछ नहीं कह सकता, और यह बात ज़ुबानी कह देना बेहतर है कि ऑर्डर पूरा है — ऐसा दिखाने से।

आपूर्तिकर्ता को ऑर्डर का ड्राफ़्ट#

योजना के नीचे चुने गए कवरेज क्षितिज के लिए खरीद का ड्राफ़्ट है (फ़ील्ड “कवरेज, दिन”: आम तौर पर डिलीवरी अवधि प्लस भंडार; डिफ़ॉल्ट रूप से 3 दिन, 1 से 30 तक मान्य)।

हर सामान के लिए दो मान निकाले जाते हैं, और बड़ा वाला लिया जाता है:

क्षितिज के लिए पूर्वानुमान के अनुसार ज़रूरत में से मौजूदा शेष घटाया गया;
लक्ष्य शेष तक पूर्ति (और अगर सामान के लिए यह तय नहीं है — तो ऑर्डर बिंदु तक) — सामान्य गोदाम तर्क।

बड़ा क्यों, न कि एक के बजाय दूसरा: सुरक्षा भंडार को कल के दोगुनी भीड़ वाले शुक्रवार का पता नहीं; और पूर्वानुमान को उन सामानों का पता नहीं जो टेक-कार्ड में बिल्कुल शामिल नहीं हैं (पैकेजिंग, उपभोग्य सामग्री) — उनके लिए गोदाम मानदंड ही एकमात्र आधार है। दूसरे नियम से सूची में आई पंक्तियों पर “ऑर्डर बिंदु के अनुसार” का निशान लगा है। ध्यान दें: नियम लक्ष्य शेष को देखता है, इसलिए ड्राफ़्ट में वह सामान भी आ जाएगा जो अभी ऑर्डर बिंदु से ऊपर है, पर लक्ष्य से नीचे — “ऑर्डर करना है” टैब ऐसा सामान अभी नहीं दिखाता।

पूर्वानुमान के अनुसार केवल अंतिम सामग्री खरीदी जाती है: अर्ध-तैयार उत्पाद पूर्वानुमान के अनुसार आपूर्तिकर्ता के ऑर्डर में नहीं जाते (उन्हें तैयारी की योजना के अनुसार बनाया जाता है) — वे ड्राफ़्ट में गोदाम मानदंड से ही आ सकते हैं।

अगर सामान के लिए पैकेजिंग की गुणजता तय है, तो मात्रा उस तक ऊपर की ओर पूर्णांकित की जाती है। पंक्तियाँ आपूर्तिकर्ताओं के अनुसार समूहित हैं (बिना नियुक्त आपूर्तिकर्ता वाला सामान — अलग समूह में), और बटन हर आपूर्तिकर्ता के लिए अपना ऑर्डर बनाता है — आगे ये गोदाम अनुभाग से सामान्य खरीद हैं।

“19:00 तक खत्म हो जाएगा”#

टैब का सबसे ऊपरी ब्लॉक — दिन के अंत तक खत्म होने का जोखिम: यानी जो अभी जल रहा है। यह मौजूदा शेष की तुलना दिन के बचे घंटों के अपेक्षित खर्च से करता है, जो दिन के हिस्सों की प्रोफ़ाइल से निकाला जाता है, और वह घंटा बताता है जब शेष शून्य हो जाएगा। अगर घंटा तय नहीं हो पाता, तो पंक्ति ईमानदारी से कहती है “दिन के अंत तक नहीं बचेगा”, बिना गढ़े हुए समय के।

ब्लॉक केवल आज के लिए निकाला जाता है: “कल” पर स्विच करने पर यह गायब हो जाता है — कल के लिए “19:00 तक खत्म हो जाएगा” का जोखिम नहीं होता।

आज की गति का सुधार: अगर दोपहर तक सामान्य से ज़्यादा खर्च हो चुका है, तो बाकी दिन का अनुमान उसी अनुपात में बढ़ जाता है, और पंक्ति में “दिन की गति ×1.4” जैसा निशान दिखता है। गति वास्तविक बिक्री से निकाली जाती है (उसमें राइट-ऑफ़, खराबी और स्टाफ़ का भोजन शामिल नहीं हैं) और सबसे जोखिम भरी लगभग दस-बारह पंक्तियों के लिए मापी जाती है — बाकी सामान्य प्रोफ़ाइल से निकाले जाते हैं। गुणांक ×0.5…×2 की सीमा में बँधा है — “आज भीड़ है” का सुधार चाहिए, पर एक ही बिल से भविष्यवाणी नहीं। अगर गति मापने के लिए कुछ भी नहीं है, तो टैब ईमानदारी से कहेगा कि सप्ताह के दिन की सामान्य प्रोफ़ाइल ली गई है।

पूर्वानुमान दिखने के लिए क्या चाहिए#

चाहिए	किसलिए	इसके बिना
AWS कॉन्टूर पर ब्रांड (`cenaly.com`, `cenaly.com`…)	बिक्री इतिहास सर्वर का विश्लेषणात्मक डेटाबेस निकालता है, और वह केवल वहीं चालू है	`cenaly.ru` पर टैब हमेशा लिखता है “अभी ऑर्डर का इतिहास कम है” — संदेश इतिहास के बारे में है, पर कारण दूसरा है: वहाँ इसे निकालने का साधन नहीं है
बिक्री इतिहास	सप्ताह के दिन के अनुसार माध्यिका निकालने के लिए	“पूर्वानुमान लगाने के लिए अभी ऑर्डर का इतिहास कम है”
इतिहास में ≥ 3 एक जैसे सप्ताह के दिन	नमूने के रूप में गिनने के लिए	तालिका में व्यंजन पर “कम” का निशान लगा है और वह योजनाओं में नहीं जाता
व्यंजनों के टेक-कार्ड	पूर्वानुमान को सामान में बदलने के लिए	व्यंजन “टेक-कार्ड के बिना” चेतावनी में आ जाएगा
ताज़ा शेष	कमी और जोखिम निकालने के लिए	जब तक शेष लोड नहीं होते, टैब कुछ नहीं दिखाएगा

इतिहास का एग्रीगेट सर्वर पर लगभग हर आधे घंटे में दोबारा निकाला जाता है (और केवल उन खातों के लिए जो अभी काम कर रहे हैं); टेक-कार्ड का विस्तार और शेष की कटौती टैब खुलने के समय, मौजूदा डेटा से निकाले जाते हैं।

अक्सर पूछे जाने वाले प्रश्न#

आधे व्यंजनों पर “कम” का निशान क्यों लगा है?#

क्योंकि इन व्यंजनों के इतिहास में सप्ताह के इस दिन तीन से कम बिक्री है — जैसे कोई व्यंजन दो हफ़्ते पहले मेन्यू में आया। जब पर्याप्त अवलोकन हो जाएँगे, संख्या खुद दिखने लगेगी; तब तक व्यंजन न तैयारी की योजना में शामिल होता है, न खरीद में।

औसत के बजाय माध्यिका क्यों ली जाती है?#

माध्यिका असंगत मानों के प्रति स्थिर रहती है। 40 लोगों का एक बैंक्वेट औसत को इतना खिसका देता है कि प्रतिष्ठान हफ़्तों तक ज़्यादा तैयारी करता रहता है। इंटरफ़ेस में औसत दिखाया ही नहीं जाता — केवल माध्यिका, प्रसार और अवलोकनों की संख्या।

क्या पूर्वानुमान मौसम, त्योहार, फ़ुटबॉल को ध्यान में रखता है?#

नहीं। उसे केवल सप्ताह का दिन और दिन का समय पता है। त्योहार वाला हफ़्ता और पड़ोस का मैच आज भी मैनेजर के दिमाग में रहता है — और यह ऐसे मॉडल से ज़्यादा ईमानदार है जो दिखावा करे कि उसने इन्हें ध्यान में रखा।

क्या एक हफ़्ते आगे का पूर्वानुमान बनाया जा सकता है?#

टैब आज और कल दिखाता है। खरीद के लिए क्षितिज अलग से तय होता है — “कवरेज, दिन” फ़ील्ड से: एक दिन का पूर्वानुमान उससे गुणा किया जाता है।

क्या खरीद का ड्राफ़्ट तुरंत आपूर्तिकर्ता को ऑर्डर भेज देता है?#

नहीं। यह बिल्कुल ड्राफ़्ट है: ज़रूरत से ज़्यादा पंक्तियाँ आप चेकबॉक्स से हटाते हैं और उसके बाद ही बनाने पर क्लिक करते हैं — “गोदाम” अनुभाग के सामान्य खरीद ड्राफ़्ट बनते हैं, हर आपूर्तिकर्ता के लिए एक। मात्राएँ बने हुए ऑर्डर में ही ठीक की जाती हैं, वहीं जहाँ आम तौर पर।