अवधारणा का प्रमाण: एमएल कार्यान्वयन को कैसे सत्यापित करें वर्थ कैंडल है

हाल ही में, एक आरामदायक चैट रूम में, शैतानवादियों की तारीख ने सवाल उठाया कि आंतरिक मशीन सीखने की परियोजनाओं को कैसे "ठीक से" बेचना है। यह पता चला है कि हम में से कई लोग अपनी गतिविधियों की आर्थिक व्यवहार्यता के बारे में बहुत ही चिंतित हैं। इस बीच, परियोजना लाभप्रदता का न्यूनतम मूल्यांकन करने के लिए, किसी भी एमबीए की आवश्यकता नहीं है - एक संक्षिप्त लेख (पाठ के 10 पृष्ठ, के-के-के) में मैं आपको बताऊंगा कि आरओआई क्या है, आंतरिक परियोजना के लिए इसका मूल्यांकन कैसे करें, यह किस भूमिका निभाता है अवधारणा का सबूत, और क्यों वास्तविक जीवन में सब कुछ गलत हो सकता है। हम एक कॉल सेंटर के लिए समयबद्धन को स्वचालित करने के लिए एक काल्पनिक परियोजना के चारों ओर यह करेंगे। बिल्ली के लिए आपका स्वागत है!

हमारी काल्पनिक परियोजना

कॉल सेंटर में 100 ऑपरेटर हैं। वे एक फ्लोटिंग शेड्यूल पर काम करते हैं, 8 या 12 घंटे की शिफ्ट में काम करने के लिए। शिफ्ट अलग-अलग समय पर शुरू होती है और इस तरह से व्यवस्थित की जाती है कि पीक आवर्स में कई लोगों की निगरानी हो सके और रात में और वीकेंड पर ठंडी तादाद में लोगों की संख्या कम हो। शेड्यूल की योजना कॉल सेंटर सुपरवाइजर द्वारा डार्क फ्राइडे शाम को, अगले सप्ताह के लिए लोड की योजना बनाकर की जा रही है।

कॉल सेंटर ऑपरेटर के 8 घंटे के दिन की लागत कंपनी को 2,000 रूबल है। यदि हम मानते हैं कि एक वर्ष में 250 कार्य दिवस हैं, तो कॉल सेंटर की लागत 100 2.000 250 = 50 प्रति वर्ष है। यदि हम समय-निर्धारण को स्वचालित करते हैं, तो हम प्रति घंटे लोड की भविष्यवाणी कर सकते हैं और पूर्वानुमान भार के आधार पर ड्यूटी ऑपरेटरों की संख्या में भिन्नता के लिए बदलाव की व्यवस्था कर सकते हैं। यदि हमारे पूर्वानुमान और पारियों की व्यवस्था पर्यवेक्षक के पूर्वानुमान और व्यवस्था से कम से कम 10% बेहतर है, तो हम 5 मिलियन रूबल की बचत करेंगे। प्रति वर्ष। अगर हम वास्तव में 10% सुधार का प्रबंधन करते हैं, तो परियोजना निश्चित रूप से बंद हो जाएगी। या नहीं? .. आइए विचार करें कि इस तरह के निर्णय कैसे करें।

ROI के अनुसार

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

आरओआई (निवेश पर वापसी) परियोजना लाभ का एक संकेतक है जो खर्च किए गए निवेश के लिए आय के अनुपात के बराबर है। आरओआई <100% का मतलब है कि परियोजना बंद का भुगतान नहीं करेगी।

परियोजना के लिए पहला खर्च तुरंत शुरू होता है - लोहे और लाइसेंस की खरीद, सिस्टम के विकास और इसके कार्यान्वयन के लिए। इसे पूंजीगत व्यय कहा जाता है। परियोजना के जीवन के दौरान, इसे लागत भी वहन करना पड़ता है - समान हार्डवेयर और लाइसेंस किराए पर लेना, सिस्टम की संचालन क्षमता का समर्थन करना और, कभी-कभी, ऑपरेटरों का काम। इसे ऑपरेटिंग खर्च कहा जाता है।

एमएल परियोजनाओं, एक नियम के रूप में, "तात्कालिक राजस्व" नहीं है। परियोजना राजस्व केवल काम कर रहे हैं, अर्थात् समय में। उदाहरण के लिए, हमारे कॉल सेंटर के मामले में, ऑपरेटरों के लिए लागत बचत के रूप में राजस्व बनता है। यदि परियोजना की परिचालन लागत राजस्व से अधिक है, तो परियोजना कभी भी भुगतान नहीं करेगी।

परियोजना की शुरुआत में "तत्काल" पूंजीगत व्यय के कारण, आरओआई उस समय पर निर्भर करेगा जिस समय हम लाभप्रदता का मूल्यांकन करते हैं। आमतौर पर, या तो वर्ष, नियोजन क्षितिज या सिस्टम के जीवनकाल का उपयोग ROI की गणना के लिए किया जाता है। वर्ष के साथ सब कुछ स्पष्ट है - यह समझने का एक आसान तरीका है कि परियोजना एक वर्ष में भुगतान करेगी या नहीं। नियोजन क्षितिज वह समय अंतराल है जिस पर कंपनी की रणनीति की योजना बनाई जाती है और बजट तैयार किया जाता है। छोटी और गतिशील कंपनियों में, क्षितिज शायद ही कभी एक वर्ष से अधिक हो, बड़े और स्थिर लोगों में यह तीन से दस साल तक हो सकता है।

नियोजन के सुदूर क्षितिज पर, आप किसी भी कबाड़ को पुनः प्राप्त कर सकते हैं, लेकिन आम जीवन को सिस्टम के जीवन काल द्वारा संरक्षित किया जाता है। आमतौर पर, कुछ वर्षों के बाद, सिस्टम व्यवसाय की आवश्यकताओं को पूरा करना बंद कर देता है, और इसे या तो एक नए के साथ बदल दिया जाता है, फेंक दिया जाता है, या (सबसे अधिक बार) अनन्त समर्थन पर सड़ने के लिए छोड़ दिया जाता है। व्यापार के तेजी से विकास के साथ, प्रणाली हमेशा छह महीने तक नहीं रह सकती है, एक स्थिर बाजार में सिस्टम 3-5 वर्षों में संशोधनों के बिना अप्रचलित हो जाता है, और बहुत ही रूढ़िवादी वातावरण में केवल एक रूढ़िवादी बॉक्स 10 से अधिक जीवित रह सकता है। छूट दरों, मूल्यह्रास और अन्य लेखांकन जादू को पेशेवर फाइनेंसरों के लिए छोड़ दिया जाएगा।

इस प्रकार, आरओआई की गणना निम्नलिखित सूत्र के अनुसार की जाती है:

$$

$$ROI = \ frac {ऑपरेटिंग राजस्व \ LIFE} {{पूंजी व्यय + परिचालन व्यय \ _ LIFE}$$

अवधारणा का प्रमाण

हम यह भी कैसे जान सकते हैं कि एक नए कार्यान्वयन से आंकड़ा 10% बढ़ जाएगा?

सबसे पहले, हम इस संख्या को यादृच्छिक रूप से चुन सकते हैं, निकटतम आगम से हिला सकते हैं। यह अक्सर काम करता है, लेकिन कम अक्सर आपदा की ओर नहीं जाता है। इस तरह के वैंगिंग को सार्वजनिक रूप से प्रोत्साहित नहीं किया जाता है, फिर भी, बुजुर्ग यह समझते हैं कि कई सफल निर्णय वास्तव में, "हाथ से" लिए गए थे।

दूसरे, हम पिछले कार्यान्वयन के अनुभव पर भरोसा कर सकते हैं। उदाहरण के लिए, हम एक पंक्ति में पांचवें कॉल सेंटर में स्वचालन शुरू करते हैं, इससे पहले हमने 7-10% के परिणाम देखे, हम जानते हैं और सभी सामान्य समस्याओं को हल कर सकते हैं, और ऐसा लगता है कि कुछ भी हमें निराश नहीं करना चाहिए। हमने जितने अधिक क्रियान्वयन किए, हमारे पूर्वानुमान उतने ही सटीक हैं, और परिणाम में आदर्श से विभिन्न विचलन के प्रभाव को हम बेहतर समझते हैं।

यहां तक ​​कि एक एकल कार्यान्वयन के अनुभव के साथ, चुइका की तुलना में बहुत अधिक सार्थक पूर्वानुमान बनाया जा सकता है। इसका एक साहसिक परिणाम है - ऐसा लगता है कि एक भी अधूरा क्रियान्वयन हमें चुयका के सामने एक बड़ी शुरुआत देगा। इसलिए हम प्रूफ ऑफ कॉन्सेप्ट, या पीओसी के विचार में आते हैं।

एक परिकल्पना के प्रदर्शन की पुष्टि करने या उसे बाधित करने के साथ-साथ इसकी प्रभावशीलता का मूल्यांकन करने के लिए PoC की आवश्यकता होती है। पीओसी का पूर्ण रूप से कार्यान्वयन नहीं होता है, जिसका अर्थ है कि इसे जल्दी और सस्ते में किया जा सकता है। डेटा साइंस प्रोजेक्ट्स में तेजी लाने के तरीके क्या हैं?

1. डेटा को मैन्युअल रूप से लेने के लिए, गंदे, सीधे उन जगहों से जहां विश्लेषण करना सबसे आसान है। भले ही यह स्रोत उत्पादन के लिए स्वीकार्य नहीं है, लेकिन यह महत्वपूर्ण नहीं है।
2. बेस लाइन के रूप में सबसे अधिक गूंगा ह्यूरिस्टिक्स का उपयोग करें। उदाहरण के लिए, अगले दिन के पूर्वानुमान के लिए आधार रेखा आज के लिए भार है। यहां तक ​​कि कूलर - पिछले 5-7-30 दिनों में औसत भार। आप आश्चर्यचकित होंगे, लेकिन इस तरह के एक अनुमान को हमेशा पार नहीं किया जा सकता है।
3. वापस परीक्षण के साथ गुणवत्ता का आकलन करें - लंबे समय तक चलने वाले नए प्रयोग न करें। सभी डेटा इतिहास में पहले से ही हैं, हम इस पर प्रभाव का मूल्यांकन करेंगे।
4. पुन: प्रयोज्य कोड बनाने का प्रयास न करें। PoC के बाद सभी कोड को बाल्टी में डाल दिया जाएगा। हम इसे हर सुबह कोड पर बैठने से पहले दोहराते हैं।
5. एक शांत मॉडल बनाने की कोशिश मत करो। खुद को कठिन समय सीमा निर्धारित करें - प्रति मॉडल एक से तीन दिन। ऐसी अवधि के लिए, यह एक जटिल कार्यान्वयन में "खुदाई" करने के लिए काम नहीं करेगा, लेकिन यह कई सरल विकल्पों के माध्यम से जाना होगा। इन विकल्पों के लिए, एक विश्वसनीय कम अनुमान प्राप्त किया जाता है।
6. आक्रामक रूप से एक रेक की तलाश करें, सभी हास्यास्पद स्थानों पर कदम रखें, खतरनाक विचारों का परीक्षण करें। पीओसी चरण में हम जितना अधिक रेक एकत्र करेंगे, उत्पादन विकास के दौरान उतना कम जोखिम होगा।

PoC चरणों

पीओसी की अवधि आमतौर पर एक सप्ताह से लेकर कुछ महीनों तक होती है। यह कार्य एक व्यक्ति द्वारा किया जाएगा जो शैतान की तारीख का नेतृत्व करेगा। पीओसी का संचालन करने के लिए भी व्यापार ग्राहक का बहुत ध्यान रखने की आवश्यकता होती है - PoC की शुरुआत में बात करना और अंत में परिणामों को समझना। कुल मिलाकर, PoC हमें अग्रणी DS के दो महीने के काम और कई दिनों के व्यवसाय ग्राहकों के काम का खर्च देगा। यहां पहला संकेतक है - अगर ग्राहक को पीओसी के लिए समय नहीं मिला, तो एक बड़ी परियोजना का परिणाम वास्तव में मांग में नहीं होगा।

तो, कदम।

1. विशिष्ट व्यावसायिक आवश्यकताओं के लिए विशलिस्ट और बज़ वर्ड से जाएं। यह एक पारंपरिक व्यवसाय विश्लेषण कार्य है, लेकिन डीएस के लिए इसे स्वयं करना बहुत ही उचित है। इसलिए वह ग्राहक की जरूरतों को अधिक सटीक रूप से समझ सकता है और दूसरे चरण को पूरा कर सकता है ...
2. एक प्रयोग तैयार करें। सही शब्दांकन किसी प्रोजेक्ट की सफलता की कुंजी है। डीएस को यह निर्धारित करना चाहिए कि व्यावसायिक प्रक्रिया में एक स्वचालित निर्णय कहां किया जाता है, इनपुट पर क्या जानकारी उपलब्ध है, आउटपुट पर क्या अपेक्षित है, किस तरह के मशीन लर्निंग कार्य को कम किया जा सकता है, प्रशिक्षण और उत्पादन के दौरान कौन से डेटा की आवश्यकता होगी, किस तकनीकी और व्यावसायिक मैट्रिक्स का उपयोग करना है। सफलता का आकलन।
3. डेटा के साथ सौदा। डीएस को समझना चाहिए कि आम तौर पर हमारे पास कौन सा डेटा उपलब्ध है। उनकी सक्रिय रचना, संपूर्णता, इतिहास की गहराई, संगति का मूल्यांकन करना। जल्दी से मैन्युअल रूप से एक मॉडल बनाने और एक परिकल्पना का परीक्षण करने के लिए पर्याप्त डेटासेट को इकट्ठा करें। यह तुरंत महसूस करना अच्छा होगा कि क्या उत्पादन में डेटा ट्रेन में उपलब्ध है और हम यहां एकत्र किए गए से अलग होंगे।
4. इंजीनियर एक मॉडल का निर्माण और निर्माण करता है। युवा नाखूनों से युवा व्यंग्यकार केवल मॉडल (यूरोप) के बारे में सोचते हैं, इसलिए टिप्पणियां बहुत कम होती हैं।
5. मॉडल की गुणवत्ता को रेट करें। सही ढंग से क्रॉस-वैलिडेशन का संचालन करें, तकनीकी और व्यावसायिक मैट्रिक्स की गणना करें, साथ ही साथ उन सीमाओं का आकलन करें जिनसे वे उत्पादन में उतार-चढ़ाव कर सकते हैं। यह सब डीएस को भी करना चाहिए।
6. परिणामी ROI का मूल्यांकन करें - यह सब इसके लिए है। मूल्यांकन के लिए, आप ग्राहक के प्रतिनिधियों और किसी ऐसे व्यक्ति को आकर्षित कर सकते हैं, जो जानता है कि जुर्माना कैसे किया जाता है। मॉडल।

आइए हमारे काल्पनिक प्रोजेक्ट के आधार पर एक काल्पनिक PoC करें।

चरण 1. कार्य के लिए "विशलिस्ट" स्थानांतरित करें

यहाँ विशलिस्ट का शब्दांकन है:
ऐसा लगता है कि यदि हम समय-निर्धारण को स्वचालित करते हैं, तो हम न केवल योजना बनाने में समय बचाएंगे, बल्कि यह भी सीखेंगे कि भार के आधार पर बदलावों की संख्या को कैसे अलग किया जाए।

इसका वास्तव में क्या मतलब है?

एक ऐसी प्रणाली बनाना आवश्यक है, जो शिफ्ट्स और कॉल के इतिहास के अनुसार, अगली अवधि के लिए लोड की भविष्यवाणी करेगा, साथ ही इस तरह से शिफ्टों को प्रभावी ढंग से लोड का उपयोग करने की व्यवस्था करेगा।

लोड फोरकास्ट फोरकास्ट का पूर्वानुमान, प्रति टाइम स्लाइस हिट की संख्या में त्रुटि है।
लोड उपयोग क्षमता मेट्रिक - प्रतीक्षा समय का 95 वाँ प्रतिशत।
आर्थिक मीट्रिक - लेखांकन अवधि के लिए पारियों की संख्या।

कार्य दो में गिर गया - लोड की भविष्यवाणी कैसे करें, और पाली की व्यवस्था कैसे करें।

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

दूसरे, हम प्रति अवधि में बदलाव की संख्या को कम करना चाहते हैं ताकि स्वीकार्य सीमा के भीतर प्रतीक्षा समय के 95 वें प्रतिशत को बनाए रखा जा सके, जबकि लोड की भविष्यवाणी की जाएगी।

चरण 2. प्रयोग का निरूपण

टास्क 1. लोड की भविष्यवाणी

सप्ताह 1 के शुक्रवार को, हम सप्ताह के प्रत्येक घंटे पर कॉल की संख्या की भविष्यवाणी करना चाहते हैं। पूर्वानुमान का परिणाम 168 नंबर होगा - अगले सप्ताह के प्रत्येक घंटे के लिए एक नंबर।
एक सप्ताह के अंतराल पर काम करना होगा ताकि ऑपरेटरों को समय पर समायोजित करने का समय मिल सके।

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

हम समस्या को कम करने के लिए प्रतिगमन करते हैं। इतिहास में प्रत्येक घंटे के लिए, हम एक फीचर वेक्टर का निर्माण करेंगे और उस समय उस पर लोड की भविष्यवाणी करेंगे। सफलता मीट्रिक को MAPE होने दें (या WAPE, हम इसका पता लगा लेंगे)। अस्थायी डेटा पर क्रॉस सत्यापन "माथे" संभव नहीं है - हम भविष्य में देखेंगे। सामान्य तरीका यह है कि कहानी को साप्ताहिक पारी (चार सप्ताह?) के साथ सिलवटों में तोड़ दिया जाए, और पिछले सप्ताह को नियंत्रण के रूप में माना जाए। सफलता की कसौटी अगर हमारी WAPE (या कौन है?) को उचित सीमाओं के भीतर रखा जा सकता है। जैसे-जैसे प्रयोग आगे बढ़ता है, उचित सीमाओं पर सोचें।

कार्य 2. पारियों की व्यवस्था

पूर्वानुमानित भार के अनुसार, हम इसे पाली के साथ कवर करना चाहते हैं ताकि पारियों की संख्या कम से कम हो, और गुणवत्ता संकेतक स्वीकार्य स्तर पर रहें।
फिलहाल, हम कैलेंडर पर ऑपरेटरों की व्यवस्था नहीं करते हैं, हम केवल यह निर्धारित करते हैं कि किस दिन कितनी शिफ्ट लगाई जाए और किस ओवरलैप के साथ।

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

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

स्टेज 3. हम उपलब्ध आंकड़ों का अध्ययन करते हैं

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

अब हम कॉल सेंटर के पर्यवेक्षक के पास जाते हैं और कई वर्षों के लिए सभी ऑपरेटरों के शेड्यूल को बढ़ाने के लिए कहते हैं। पर्यवेक्षक हमसे एक-दो बार पूछेगा, पीला पड़ जाएगा, एक वैलिडिक्लिक पी लेगा - और एक दो दिनों में संलग्न एक्सेल के साथ सैकड़ों पत्र हमारे मेलबॉक्स को भेज दिए जाएंगे। हमें बदलाव के साथ एक बड़ी तालिका में यह सब लाने के लिए एक और तीन दिन बिताने होंगे। बदलने के लिए, हम तारीख, प्रारंभ समय, अवधि और ऑपरेटर आईडी जानेंगे।

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

कुल मिलाकर, हमारे पास तीन टैबलेट में तीन एंटिटीज हैं:

• कॉल सेंटर पर कॉल करें - नंबर, दिनांक और समय, अवधि, ग्राहक और ऑपरेटर पहचानकर्ता।
• ऑपरेटर शिफ्ट - संख्या, तिथि, प्रारंभ समय, अवधि, ऑपरेटर पहचानकर्ता।
• लोड की मैक्रो प्रवृत्ति - तिथि, सक्रिय ग्राहकों की संख्या

चरण 4. संकेत उत्पन्न करें और मॉडल को प्रशिक्षित करें

जैसा कि आपको याद है, अपघटन के बाद का कार्य दो में गिर गया। दूसरा भाग, पारियों की व्यवस्था के बारे में, अब हम स्पर्श नहीं करेंगे - मशीन लर्निंग की कोई आवश्यकता नहीं है। पहले भाग के बारे में बात करते हैं - लोड पूर्वानुमान।

हमने प्रयोग को एक प्रतिगमन कार्य के रूप में तैयार किया - "इतिहास में प्रत्येक घंटे के लिए हम एक फीचर वेक्टर का निर्माण करेंगे और एक घंटे में लोड की भविष्यवाणी करेंगे।" चलो प्रशिक्षण नमूना इकट्ठा करते हैं। नमूने में पंक्ति कैलेंडर घंटे होगी। प्रत्येक घंटे एक लक्ष्य से मेल खाती है - उस घंटे के हिट की संख्या।

अब आइए विचार करें कि हम किन संकेतों का उपयोग कर सकते हैं।

1. शुरुआत के लिए, आइए अपने डेटा की कैलेंडर प्रकृति का लाभ उठाएं। सप्ताह के दिन, घंटे, महीने के दिन के संकेत जोड़ें। उन्हें छल्ले में बंद किया जा सकता है।
2. ऐसे दिनों में और ऐसे घंटों में प्रति घंटे कॉल की संख्या जोड़ें। आप अंतिम सप्ताह में हिट्स की संख्या ले सकते हैं, साथ ही महीने और वर्ष के लिए औसत भी।
3. हम सप्ताह के ठीक एक ही दिन और उसी दिन हिट की संख्या जोड़ते हैं।
4. एकत्रीकरण विंडो को व्यापक रूप से लें - सप्ताह के इस दिन और दिन के इस समय हिट की औसत संख्या जोड़ें।
5. चलो लोड प्रवृत्ति को तुरंत कॉल की संख्या को सामान्य करने का प्रयास करें। हम सामान्यीकृत और कच्चे मूल्यों पर दोनों का परीक्षण करेंगे।
6. मौसमी जोड़ें - प्रति वर्ष हिट्स की संख्या, लोड की प्रवृत्ति के लिए सामान्यीकृत।
7. बस मामले में, हम लोड के रुझान के बारे में कच्चा डेटा भी जोड़ते हैं। और हम वर्तमान क्षण और "स्थानांतरित" मान दोनों पर मान लेंगे - एक सप्ताह पहले, एक महीने पहले।

हम न केवल "सामान्य" RMSE त्रुटि फ़ंक्शन का प्रयास करेंगे, बल्कि WAP - यह समस्या के उद्देश्य के लिए अधिक उपयुक्त है। सत्यापन के लिए, हम सामान्य K- गुना क्रॉस-सत्यापन का उपयोग करने में सक्षम नहीं होंगे - भविष्य में देखने का मौका होगा। इसलिए, हम नेस्टेड फोल्ड्स विभाजन का उपयोग करेंगे, और परीक्षण फोल्ड के आकार को ठीक से कहेंगे, ठीक 4 सप्ताह। और सिलवटों की सीमाएं सोमवार आधी रात को निर्धारित की जाएंगी।

PoC के लिए हम दो मॉडल आज़माएंगे - L1 नियमितीकरण वाला एक रैखिक और लकड़ी का सबसे प्रिय टुकड़ा। एक रेखीय मॉडल के लिए, संकेतों को मानकीकृत (और लघुगणक जहां आवश्यक हो) करना न भूलें और लकड़ी के एक टुकड़े के लिए, नियमित रूप से पैरामीटर को अधिक आक्रामक तरीके से हटा दें।

चरण 5 और 6. हम मॉडल की गुणवत्ता और आर्थिक प्रभाव का मूल्यांकन करेंगे।

इसलिए, सभी तैयारियां पूरी कर ली गई हैं, और हम अंततः PoC के सबसे दिलचस्प हिस्से पर आगे बढ़ सकते हैं - परिणामों का विश्लेषण करना और निर्णय लेना।
दुर्भाग्य से, वास्तविक डेटा के बिना, पूरा उदाहरण सट्टा था, इसलिए परिणाम उंगली से बाहर चूसा जाएगा। इसलिए शर्मिंदा होने के लिए नहीं, मैंने गेर कोइल की पुस्तक "कॉल सेंटर ऑप्टिमाइजेशन" के क्रम में आंकड़े ले लिए (मुझे गलती से यह लेख ¯\_(ツ)_/¯ ) लिखते हुए मिला। वहाँ की तस्वीर एक लोड पूर्वानुमान का एक उदाहरण है।

शुरू करने के लिए, हम WAPE = 14% के साथ प्रति घंटा लोड की भविष्यवाणी करने में सक्षम थे। 43% घंटों में 10% से कम की त्रुटियों को प्राप्त करना संभव था, 70% घंटों में 20% से कम।
सामान्य तौर पर, यह बहुत अच्छा है - हम दैनिक उतार-चढ़ाव, साप्ताहिक चक्र और मध्यम अवधि के रुझानों को बहुत सटीक रूप से पकड़ते हैं। हम केवल यादृच्छिक उतार-चढ़ाव पर जलते हैं, और, सबसे अधिक संभावना है, हम उनसे बचने में सक्षम नहीं होंगे।

लोड के अनुसार, हम आसानी से उन ऑपरेटरों की संख्या की गणना कर सकते हैं जो किसी निश्चित समय पर शिफ्ट में होनी चाहिए। हमने एक लालची गैर-इष्टतम शिफ्ट शेड्यूलर एल्गोरिथ्म लिखा और गणना की कि हम पूर्वानुमान भार पर 10% पारियों को बचाने में सक्षम हैं। यह पता चला कि अगर, 12-घंटे की शिफ्ट के अलावा, हम 8-घंटे की शिफ्ट शुरू करते हैं और स्मार्ट तरीके से उन्हें दैनिक रूप से व्यवस्थित करते हैं, तो हम एक और 5% बचा सकते हैं।

हम संकेतक को पैसे में अनुवाद करते हैं। कॉल सेंटर के वार्षिक रखरखाव की वर्तमान लागत प्रति वर्ष 50 मिलियन रूबल है। हमारे प्रयोग से पता चला कि हम इस राशि को 15% तक कम कर सकते हैं, जिससे प्रति वर्ष 7.5 मिलियन रूबल तक की बचत होगी, और पूरे जीवन समय के लिए - 22.5 मिलियन रूबल तक।

यह एक बहुत अच्छा प्रभाव है, और मैं बस PoC को सफल के रूप में पहचानना चाहता हूं। हालांकि, हम, अदरक और विश्लेषण करें कि क्या गलत हो सकता है।

आर्थिक लाभ को प्रभावित करने वाले जोखिम

कर्मचारियों की संख्या में कमी के कारण हमें सकारात्मक प्रभाव मिला। हम पारियों की संख्या को कम करके कर्मचारियों की संख्या को कम करने में सक्षम थे। हम अनुमानित भार के अनुसार उनके पुनर्वितरण के कारण पारियों की संख्या को कम करने में सक्षम थे। हम ऐतिहासिक डेटा के आधार पर सिमुलेशन का उपयोग करके लोड की भविष्यवाणी करने में सक्षम थे।

सबसे पहले, यदि हमारे कॉल सेंटर में परिवर्तन करने वाले उत्पादों का उपयोग करने के पैटर्न में परिवर्तन होता है, तो ऐतिहासिक डेटा प्रासंगिकता खो देगा। यह संभावना है कि अगले तीन वर्षों में पैटर्न नहीं बदलेगा। अपने जीवन के पाठ्यक्रम में मॉडल के आगे के प्रशिक्षण और सुधार की लागतों को रखना आवश्यक है।

दूसरे, हमने लोड का सही अनुमान लगाया, लेकिन, फिर भी, 30% मामलों में हम 20% से अधिक गलतियाँ करते हैं।यह पता चल सकता है कि भीड़ के समय ऐसी कोई त्रुटि प्रतीक्षा समय में अस्वीकार्य वृद्धि की ओर ले जाती है। पर्यवेक्षक जोखिमों को कवर करने के लिए बदलाव करने का फैसला करेंगे।

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

, "" . , .
, .

,

PoC , .

-, . , CRM. , . , . , . , CRM -. , , .

-, , , , . , , — , . , , . - — .

-, — , , . , , - . , . - - , !.. , . , — 2-5 , 3-5 .

, .

20 . . .

— 5 CRM, 40 , 5 , 10 , 5 , 3120,5 , 23 . 65 , 24 . — 1,3 + 0,48 3 .

— 10 + 60 + 10 + 20 + 10 + 3121 + 53 = 110 51 , 2,2 + 1,02 .

— . 20 + 80 + 20 + 40 + 10 + 3122 + 55 = 170 97 , 3,4 + 1,94 .

, 40% , .

ROI

15% , 22,5 , 7,5 . 1,3 + 0,48 , +6,2 (+377% ROI) +21 (+1160% ROI) . .

, , . , 50% , 10%- , 5% . 2,5% — 7,5% 15% . 3,75 , 11,25 . .

— 2,2 1,02 . +55% ROI , +252% . , .

20%- . 5% , 2,5% , 1,25 , 3,75 . , . , 3 +17% ROI. , . , 20%- .

3,4 . ROI +121% . 3 +108% ROI "" .

, , ROI +55% +252% , , . , .

		Income	देव	Support	ROI 1	ROI 3
Optim	Optim	7,5	1,3	0,5	+4x	+11x
Optim	Real	7,5	2,2	1,0	+2x	+6x
Optim	Pessim	7,5	3,4	1,9	+85%	+3x
Real	Optim	3,75	1,3	0,5	+155%	+5
Real	Real	3,75	2,2	1,0	+48%	+2,5
Real	Pessim	3,75	3,4	1,9	-7%	+112%
Pessim	Optim	1,25	1,3	0,5	-14%	+108%
Pessim	Real	1,25	2,2	1,0	-50%	+17%
Pessim	Pessim	1,25	3,4	1,9	-69%	-29%

PS

PoC, , ? , ...

-, , WFM, WorkForce Management. , — , . - , , . $1000 $2500. WFM , . , WFM -. , ?

, — , . DS', . . , . , . .

, . "" 7,5%, 37,5 . . . — ROI. — . ROI 26,66 , 53 . ROI 27 .

.
-, . - - . .
-, . , . .

— .

निष्कर्ष

1. WFM -. , - . WFM — .
2. — .
3. , , ? , PoC'.
4. PoC' , ?
5. — - .