शुक्रवार रात को एक SaaS रोलआउट लाइव होता है। शनिवार सुबह तक, कस्टमर लॉग-इन नहीं कर पाते, सपोर्ट क्यू (support queue) बढ़ जाती है, और वेंडर का स्टेटस पेज ‘आंशिक रुकावट’ (partial outage) दिखाता है। स्पॉन्सर पूछता है कि रिस्क मैनेजमेंट ने इसे क्यों नहीं पकड़ा।
रिस्क रजिस्टर को अपडेट करने से पहले, आपको एक मुश्किल सवाल का जवाब देना होगा। क्या कोई ऐसा असली रिस्क सिग्नल था जिस पर आप कार्रवाई कर सकते थे, या आप बाद में मिली जानकारी के आधार पर दूसरों पर दोष मढ़ रहे हैं? यह लेसन एक ऐसा तरीका बनाता है जिससे पता चलने वाले सिग्नलों को असली सरप्राइज़ से अलग किया जा सके, मिली जानकारी को क्लासिफ़ाई किया जा सके, और यह तय किया जा सके कि AI कहाँ मदद कर सकता है, बिना AI को फ़ैसला लेने वाला बनाए।
शुरुआत करने के लिए, घटना को एक टाइमलाइन के तौर पर देखें, न कि किसी नतीजे के तौर पर। तय करें कि उस समय क्या जानकारी मौजूद थी, किसके पास थी, और एक समझदार प्रोजेक्ट मैनेजर उसका इस्तेमाल करके क्या कर सकता था।
एक आम गलती यह है कि हर बुरे नतीजे को ‘पहले से पता होने वाला’ (predictable) मान लिया जाता है। इससे ज़िम्मेदारी का एहसास तो होता है, लेकिन टीमें कम महत्व वाले जोखिमों (risks) के बारे में बहुत ज़्यादा डॉक्यूमेंटेशन करने लगती हैं और उन ज़रूरी संकेतों को नज़रअंदाज़ कर देती हैं जो असल में मायने रखते हैं।
आउटेज (सेवा में रुकावट) के दौरान, चार अलग-अलग तरह की बातें अक्सर आपस में मिल जाती हैं, और अगर आप नियम लागू नहीं करते हैं तो AI के आउटपुट में भी वे मिल जाएँगी।
जोखिम (Risk) भविष्य की एक ऐसी अनिश्चित घटना है जो अगर होती है, तो लक्ष्यों पर असर डालती है। उदाहरण: लॉन्च वीकेंड के दौरान ज़्यादा लोड होने पर वेंडर की ऑथेंटिकेशन सर्विस की रेट लिमिट।
समस्या (Issue) एक मौजूदा दिक्कत है जो पहले ही हो चुकी है। उदाहरण: अभी लॉग-इन करने पर यूज़र्स को 500 एरर मिल रहे हैं।
मान्यता (Assumption) वह बात है जिसे आप प्लानिंग के लिए सच मान रहे हैं, लेकिन हो सकता है कि वह गलत हो। उदाहरण: वेंडर पूरे क्वार्टर के दौरान मौजूदा कैपेसिटी लेवल बनाए रखेगा।
निर्भरता (Dependency) कोई बाहरी चीज़ या शर्त है जिसकी आपके प्रोजेक्ट को ज़रूरत है। उदाहरण: आपके कटओवर से पहले वेंडर का तय मेंटेनेंस का काम पूरा हो जाना।
अनुमान लगाने वाला सवाल: आउटेज के दौरान किस गलत वर्गीकरण (misclassification) की वजह से एस्केलेशन (मामले को उच्च स्तर पर ले जाने) में सबसे ज़्यादा देरी होती है?
अब इन लेबल्स को लागू करने का अभ्यास करें, क्योंकि आपकी गवर्नेंस प्रक्रिया प्राथमिकता तय करने से पहले सही और एक जैसे वर्गीकरण पर निर्भर करती है।
हर चीज़ को रिस्क के तौर पर दर्ज करना गलत सोच है, क्योंकि इससे विकल्प खुले रहते हैं। नतीजा यह होता है कि असली मुद्दों पर कोई ज़िम्मेदारी नहीं लेता और उन्हें हल नहीं किया जाता, साथ ही मान्यताओं (assumptions) की कभी पुष्टि नहीं हो पाती।
अगर आपकी रिस्क मैनेजमेंट प्रक्रिया को ऑडिट में पास होना है, तो आप चैट थ्रेड में मौजूद अनौपचारिक (informal) लिस्ट पर निर्भर नहीं रह सकते। आपको ऐसे आर्टिफैक्ट्स की ज़रूरत है जो लगातार एक जैसी सोच और फ़ैसलों का इतिहास दिखा सकें।
रिस्क टैक्सोनॉमी कैटेगरीज़ का एक व्यवस्थित सेट है जिसका इस्तेमाल रिस्क को ग्रुप करने के लिए किया जाता है, ताकि सभी प्रोजेक्ट्स में रिपोर्टिंग एक जैसी रहे। इससे वह समस्या कम हो जाती है जहाँ एक PM ‘वेंडर रिस्क’ लिखता है और दूसरा ‘थर्ड-पार्टी रिलायबिलिटी’ (विश्वसनीयता), जिससे ट्रेंड्स का पता नहीं चल पाता।
रिस्क रजिस्टर पहचाने गए रिस्क और उनके मैनेजमेंट डेटा की एक नियंत्रित लिस्ट होती है। गवर्नेंस आमतौर पर कुछ खास फ़ील्ड्स की उम्मीद करती है, जैसे Risk ID, Risk Statement, Cause, Event, Impact, Probability, Impact Score, Exposure, Risk Owner, Response Strategy, Response Actions, Target Date, Status, Triggers, और Last Reviewed। ऑडिट ट्रेल से यह पता चलता है कि क्या बदला, कब बदला और उसे किसने मंज़ूरी दी।
अनुमान लगाने वाला सवाल: रजिस्टर का कौन सा फ़ील्ड न होने पर यह साबित करना सबसे मुश्किल हो जाता है कि आपने रिस्क को सिर्फ़ रिकॉर्ड नहीं किया, बल्कि उसे मैनेज भी किया?
तुलना करें कि एक अनौपचारिक लिस्ट क्या साबित नहीं कर सकती और एक नियंत्रित रजिस्टर क्या साबित कर सकता है।