SaaS इम्प्लीमेंटेशन के दूसरे हफ़्ते की गुरुवार दोपहर है। आप प्रोजेक्ट मैनेजर हैं, डिलीवरी लीड दिन खत्म होने तक एक साफ़-सुथरा स्टेटस डेक मांग रहा है, और कस्टमर सक्सेस मैनेजर को कल की स्टीयरिंग मीटिंग से पहले डिपेंडेंसी अपडेट चाहिए। टीम एक फ़ैसले पर अटकी हुई है। क्या आप रिश्ते को बचाने के लिए मैनुअली अपडेट मांगते रहेंगे, या रुककर उस ऑपरेटिंग सिस्टम को ठीक करेंगे जिसकी वजह से बार-बार काम दोहराना पड़ता है? हर बार जब आप पहला ऑप्शन चुनते हैं, तो लागत बढ़ती जाती है। लोग हफ़्ते में 12 घंटे टूल्स से डेटा निकालने, अलग-अलग नोटों में तालमेल बिठाने और एक ही रिस्क को तीन जगहों पर दोबारा लिखने में बर्बाद कर देते हैं। मामले तब ऊपर तक पहुँचते हैं जब बहुत देर हो चुकी होती है, क्योंकि कोई भी पैटर्न को समय रहते नहीं देख पाता। यह कोर्स इस बर्बादी को रोकने के लिए ज़रूरी समझ और तरीके विकसित करता है। आप ऑपरेशनल बर्बादी की पहचान करेंगे, ऐसे AI सपोर्ट पैटर्न चुनेंगे जो आपके गवर्नेंस के हिसाब से हों, ‘ह्यूमन-इन-द-लूप’ ऑपरेटिंग मॉडल डिज़ाइन करेंगे, और ऑप्स ऑप्टिमाइज़ेशन बैकलॉग चलाएंगे जो टूल के इस्तेमाल के बजाय बचाए गए समय और फ़ैसले की क्वालिटी को मापता है।
टाइमलाइन पढ़ने से पहले, अंदाज़ा लगाइए कि असल में यह साइकल कहाँ टूटता है और सबसे ज़्यादा दोबारा काम कहाँ करना पड़ता है।
मुश्किल हिस्सा रिपोर्टिंग मीटिंग नहीं है, बल्कि उससे जुड़ा छिपा हुआ काम है। एक कोऑर्डिनेटर टिकटिंग सिस्टम से स्प्रेडशीट एक्सपोर्ट करता है। एक लीड चैट से नोट्स कॉपी करता है। कोई स्लाइड अपडेट करता है, फिर कोई स्टेकहोल्डर किसी नंबर पर सवाल उठाता है, इसलिए टीम को डेटा फिर से निकालना पड़ता है। जब सब लोग स्टेटस को बेहतर बनाने में लगे होते हैं, तो टीमों के बीच की निर्भरता (dependency) छूट जाती है। क्योंकि यह निर्भरता स्टेटस की जानकारी से जुड़ी नहीं होती, इसलिए बात को ऊपर तक पहुँचाने (escalation) का इंतज़ार स्टीयरिंग मीटिंग तक किया जाता है, तब तक विकल्प बहुत कम रह जाते हैं। ऑपरेशनल दिक्कत को मापा जा सकता है। डेटा मिलाने (reconciliation) में लगने वाला समय, डुप्लिकेट एंट्री और देर से संकेत मिलने जैसी चीज़ें ओवरटाइम, काम के हस्तांतरण में चूक और कमज़ोर अनुमानों के रूप में सामने आती हैं।
जब कोई टीम कहती है कि उन्हें प्रोजेक्ट ऑपरेशन में AI चाहिए, तो आमतौर पर उनका मतलब होता है कि वे कम रुकावटें चाहते हैं। AI मदद कर सकता है, लेकिन तभी जब आप उसकी क्षमता को उस समस्या से मिलाएँ जो आप देख रहे हैं।
प्रोजेक्ट ऑपरेशन में AI का योगदान आमतौर पर पाँच तरह से होता है।
एक आम गलती यह होती है कि सबसे ज़्यादा दिखने वाले आउटपुट, यानी स्टेटस डेक को तो ऑटोमेट कर दिया जाता है, लेकिन इनपुट को अव्यवस्थित छोड़ दिया जाता है। यह कुशल लगता है क्योंकि आउटपुट तेज़ी से मिल जाता है, लेकिन इससे गलत डेटा सिस्टम में आ जाता है और ऐसी गलत जानकारी बनती है जो सही लगती है। एक सुरक्षित नियम यह है कि जो भी चीज़ कमिटमेंट, बजट या बाहरी मैसेजिंग को बदलती है, उसे इंसानों के हाथ में ही रहने दिया जाए। AI फ़ैसले के लिए तैयारी कर सकता है, लेकिन फ़ैसला खुद नहीं ले सकता।
इस तुलना का इस्तेमाल करके ऐसे यूज़ केस चुनें जो वैल्यू और फ़ेलियर मोड पर आधारित हों, न कि सिर्फ़ नई चीज़ होने की वजह से।
जब किसी काम (use case) की वैल्यू ज़्यादा हो, लेकिन गलत होने पर नुकसान भी बड़ा हो, तो आप उसे ‘फ़ैसला लेने में मदद’ (decision support) के तौर पर देखते हैं। आप वेरिफ़िकेशन के स्टेप्स बनाते हैं, सोर्स सिस्टम तक ट्रेस करने की सुविधा रखते हैं, और AI ने जो बनाया उसका रिकॉर्ड (log) रखते हैं। जब नुकसान कम हो, जैसे कि इंटरनल नोट्स बनाना, तो आप ज़्यादा ऑटोमेशन की इजाज़त दे सकते हैं और गवर्नेंस को एक्सेस कंट्रोल और डेटा हैंडलिंग पर केंद्रित कर सकते हैं।
ह्यूमन-इन-द-लूप ऑपरेटिंग मॉडल फ़ैसला लेने की प्रक्रिया से फ़ैसले की तैयारी को अलग करता है। फ़ैसले की तैयारी का मतलब है सिग्नल इकट्ठा करना, उन्हें व्यवस्थित करना और विकल्प पेश करना। फ़ैसला लेने का मतलब है प्रोजेक्ट को किसी दिशा में आगे बढ़ाना, जोखिम उठाना या किसी स्टेकहोल्डर से किए गए वादे को बताना।
रिस्क अलर्ट (जोखिम की चेतावनी) का उदाहरण लें। AI समस्याओं के ट्रेंड को स्कैन कर सकता है और रिस्क रजिस्टर में एक नई एंट्री बना सकता है, जिसमें सुझाए गए Probability (संभावना), Impact (असर) और प्रस्तावित Risk Owner (जोखिम के लिए ज़िम्मेदार व्यक्ति) शामिल हों। इसके बाद कोई व्यक्ति सोर्स की जाँच करता है, रेटिंग में बदलाव करता है और तय करता है कि क्या जोखिम ‘एस्केलेशन थ्रेशोल्ड’ (बड़ी कार्रवाई की सीमा) को पार करता है। यह थ्रेशोल्ड पहले से तय ट्रिगर होता है, जैसे कि किसी खास डॉलर राशि से ज़्यादा का असर, तय दिनों से ज़्यादा की देरी (माइलस्टोन का छूटना), या कोई ऐसा जोखिम जो कॉन्ट्रैक्ट के तहत किए गए वादे पर असर डाले। ऑडिट ट्रेल इसलिए ज़रूरी है क्योंकि आपको यह बताना पड़ सकता है कि किसने, कब और किस सबूत के आधार पर क्या मंज़ूरी दी।
हर गतिविधि के लिए, उसके नतीजों और मंज़ूरी की ज़रूरत के आधार पर ऑटोमेशन का लेवल चुनें।