मरम्मत या पुनर्निर्माण: एक एआई सिस्टम के पूरा होने के पाँच संकेत

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

इसलिए निर्णय टाल दिया जाता है। पुनर्निर्माण महंगा और व्यवधानपूर्ण लगता है; जारी रखना मुफ़्त लगता है। यह मुफ़्त नहीं है और एक नेता का यहाँ का काम उस पल को पहचानना है जब जारी रखने की लागत प्रतिस्थापन से अधिक हो जाती है।

पाँच संकेत

ये वे हैं जो उद्योगों और सिस्टम प्रकारों के बीच स्थिरता रखते हैं। कोई भी अकेला संकेत पर्याप्त है, तीन मिलकर आपके लिए निर्णय पहले से ही ले लिया जाता है।

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

जो एक संकेत नहीं है

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

मायने रखने वाला भेद एक खराब प्रदर्शन वाले सिस्टम और एक महंगे बदलाव करने वाले सिस्टम के बीच है। पहला ठीक किया जा सकता है। दूसरा एक संरचनात्मक निष्कर्ष है और कोई मात्रा इसे उलटने के लिए पैचिंग नहीं कर सकती।

कीमत का आकलन करें जो आप बनाए रखते हैं, न कि बस पुनर्निर्माण

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

पुनर्निर्माण को स्लाइस में करें, डेटा रखें

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

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