कोर बैंकिंग अपग्रेड का छठा हफ़्ता चल रहा है, तभी वेंडर एक इनवॉइस भेजता है जो अनुमान से 30 प्रतिशत ज़्यादा है। आपके फाइनेंस पार्टनर बताते हैं कि अगर अभी कुछ नहीं बदला गया, तो ‘टाइम-एंड-मटीरियल्स’ (T&M) कॉन्ट्रैक्ट तिमाही बजट की सीमा पार कर जाएगा। प्रोक्योरमेंट टीम का कहना है कि ‘स्टेटमेंट ऑफ़ वर्क’ (SOW) इतना अस्पष्ट है कि घंटों पर सवाल नहीं उठाया जा सकता। लीगल टीम का कहना है कि बिना तय ‘एक्सेप्टेंस क्राइटेरिया’ (स्वीकृति के मापदंड) के, कॉन्ट्रैक्ट की भाषा से कोई खास फ़ायदा नहीं मिलता। वेंडर का कहना है कि अतिरिक्त काम तो पहले से ही शामिल माना गया था। आप पेमेंट करने, काम रोकने या मामला ऊपर तक ले जाने के बीच फँसे हुए हैं, और हर दिन इंतज़ार करने से बिल योग्य समय (billable time) बढ़ता है और अगला माइलस्टोन पीछे छूट जाता है। यह कोर्स आपको ऐसी समझ और तरीके देगा जिनसे आप इस जाल में फँसने से बच सकेंगे। इसमें ‘मेक-ऑर-बाय’ (खुद बनाना या खरीदना) का फ़ैसला, जोखिम के बँटवारे के आधार पर कॉन्ट्रैक्ट चुनना, मापने योग्य ‘एक्सेप्टेंस क्राइटेरिया’ के साथ बेहतर SOW बनाना, और ऑडिट की सुविधा बनाए रखते हुए AI की मदद से परफ़ॉर्मेंस को ड्राफ़्ट, मॉनिटर और प्रमाणित करने के तरीके शामिल हैं।
इम्प्लीमेंटेशन के बाद की समीक्षा में, विफलता इस बात में नहीं है कि वेंडर ने खराब काम किया। विफलता इस बात में है कि कोई यह साबित नहीं कर सकता कि ‘अच्छा काम’ किसे कहते हैं। SOW में अपस्ट्रीम और डाउनस्ट्रीम सिस्टम के लिए इंटरफ़ेस अपडेट देने की बात तो है, लेकिन इसमें इंटरफ़ेस, मैसेज फ़ॉर्मेट, एनवायरनमेंट या ‘काम पूरा हो गया’ किसे माना जाएगा, इसकी कोई सूची नहीं है। यह कॉन्ट्रैक्ट टाइम-एंड-मटीरियल्स या T&M है, जिसका मतलब है कि आप किसी तय नतीजे के बजाय मेहनत और खर्चों के लिए पेमेंट करते हैं। जब ज़रूरतें अनिश्चित हों तो यह तरीका सही हो सकता है, लेकिन इसका मतलब यह भी है कि अगर आप स्कोप, मंज़ूरी और स्वीकृति को कंट्रोल नहीं करते हैं, तो अस्पष्टता बिल योग्य घंटों में बदल जाती है।
टाइमलाइन देखने से पहले, यह अनुमान लगाएँ कि पहला विवाद कहाँ होगा: इनवॉइस, बदलाव के अनुरोध (change request) या माइलस्टोन की स्वीकृति में।
ओवररन (बजट या समय से ज़्यादा काम) आमतौर पर एक वाजिब लगने वाले स्पष्टीकरण से शुरू होता है। वेंडर पूछता है कि क्या लोन ओरिजिनेशन फ़ीड में ‘एज केस’ (खास या दुर्लभ स्थितियाँ) शामिल हैं। बिज़नेस कहता है, हाँ, बिल्कुल। फ़िक्स्ड-प्राइस कॉन्ट्रैक्ट में, उस ‘हाँ’ के बाद काम शुरू होने से पहले स्कोप पर चर्चा होती है। T&M (टाइम एंड मटीरियल) कॉन्ट्रैक्ट में, टीम अक्सर इसे सामान्य प्रगति मानती है और वेंडर घंटे रिकॉर्ड करना शुरू कर देता है। तीसरे हफ़्ते तक, वेंडर ऐसे ‘चेंज रिक्वेस्ट’ (बदलाव के अनुरोध) भेजता है जो बदलाव के बजाय नई खोज जैसे लगते हैं, और इंटरनल स्टेकहोल्डर उन पर साइन कर देते हैं क्योंकि काम ज़रूरी लगता है। पाँचवें हफ़्ते तक, टेस्टिंग डेटा तैयार न होने के कारण एक माइलस्टोन छूट जाता है, और वेंडर इंतज़ार के समय का भी बिल बनाता है क्योंकि कॉन्ट्रैक्ट में खरीदार की निर्भरता और ‘स्टॉप-द-क्लॉक’ (समय रोकने के) नियम तय नहीं थे। PM (प्रोजेक्ट मैनेजर) की आम गलती यह होती है कि वे SOW, एक्सेप्टेंस क्राइटेरिया और अप्रूवल ट्रेल की ओर इशारा करने के बजाय निष्पक्षता (fairness) की बात करते हैं। ऑडिट में निष्पक्षता नहीं टिकती, सबूत टिकते हैं।
जब आपको परेशानी महसूस होती है, तो मन करता है कि कोई AI टूल खरीद लें और उम्मीद करें कि वह अपने-आप समस्याओं को पकड़ लेगा। ज़्यादा भरोसेमंद तरीका यह है कि वेंडर और कॉन्ट्रैक्ट लाइफ़साइकल में यह पता लगाया जाए कि फ़ैसले कहाँ लिए जाते हैं और यह तय किया जाए कि AI का कौन सा आउटपुट उन फ़ैसलों को बदल सकता है। AI दस्तावेज़ों को पढ़ने और उनकी तुलना करने, ज़िम्मेदारियों को समझने, छूटी हुई शर्तों को चिह्नित करने और परफ़ॉर्मेंस सिग्नल की निगरानी करने में आपकी मदद कर सकता है। यह कॉन्ट्रैक्ट में काम पूरा होने की परिभाषा (definition of done) की जगह नहीं ले सकता और न ही अप्रूवल पर साइन कर सकता है।
लाइफ़साइकल के हर चरण को उस तरह के AI आउटपुट से जोड़ें जो लागत बढ़ने (cost creep) या विवाद के जोखिम को कम कर सके।
इनटेक (शुरुआती चरण) में, AI ज़रूरतों को स्टैंडर्डाइज़ कर सकता है और बिखरे हुए रिक्वेस्ट ईमेल को स्कोप और सीमाओं के एक स्ट्रक्चर्ड ड्राफ़्ट में बदल सकता है। डिलिजेंस (जांच-पड़ताल) में, यह वेंडर के जवाबों का सारांश बना सकता है और चेकलिस्ट के आधार पर कमियों को उजागर कर सकता है, लेकिन चेकलिस्ट के लिए अभी भी मालिकों की ज़रूरत होती है। ड्राफ़्टिंग में, यह क्लॉज़ और एक्सेप्टेंस क्राइटेरिया के विकल्प सुझा सकता है, फिर भी कानूनी टीम को भाषा को मंज़ूरी देनी होती है और प्रोक्योरमेंट टीम को कमर्शियल शर्तों को अलाइन करना होता है। मॉनिटरिंग में, यह साइन किए गए कॉन्ट्रैक्ट से डिलिवरेबल्स, ड्यू डेट्स और मंज़ूरी की ज़रूरतों को निकालकर एक ट्रैकर में डाल सकता है, और फिर इनवॉइस की तुलना टाइमशीट के नियमों और माइलस्टोन के सबूतों से कर सकता है। रिन्यूअल में, यह बार-बार होने वाले विवादों को सामने ला सकता है और यह बता सकता है कि आपने कितनी बार री-वर्क या इंतज़ार के समय के लिए भुगतान किया है। इसका सीधा सा नियम है। AI का इस्तेमाल वहाँ करें जहाँ पढ़ने, तुलना करने, जानकारी निकालने या विसंगति का पता लगाने में रुकावट आती हो। जोखिम उठाने की क्षमता तय करने या साइन-ऑफ़ की जगह लेने के लिए AI का इस्तेमाल न करें।
बैंकिंग में, वेंडर और कॉन्ट्रैक्ट मैनेजमेंट भी एक कंट्रोल सिस्टम है। इसमें थर्ड-पार्टी रिस्क मैनेजमेंट या TPRM की ज़रूरतें, डेटा रेजिडेंसी की सीमाएँ, ऑडिट ट्रेल की ज़रूरतें और मॉडल रिस्क मैनेजमेंट या MRM (अगर AI मॉडल फ़ैसलों को प्रभावित करते हैं) शामिल होते हैं। ये सीमाएँ AI के इस्तेमाल को रोकती नहीं हैं। ये तय करती हैं कि क्या करने की इजाज़त है, क्या रिकॉर्ड किया जाना चाहिए, और किन चीज़ों की समीक्षा इंसानों द्वारा की जानी चाहिए।
प्रोक्योरमेंट या कॉन्ट्रैक्ट वर्कफ़्लो में किसी भी AI को लागू करने से पहले यह तय करें कि आपका प्रोजेक्ट मुख्य कंट्रोल सेटिंग्स में कहाँ फिट बैठता है।