SAP और AI डिलीवरी के लिए सात कंसल्टिंग फ़्रेमवर्क

जब कोई SAP या AI प्रोग्राम अटकता है, तो कारण आम तौर पर ढाँचागत होता है, और सात सरल फ़्रेमवर्क उसे ढूँढ निकालते हैं। मौजूदा स्थिति का नक़्शा बनाइए। RACI से तय कीजिए कि कौन किस बात का फ़ैसला करेगा। काम को बिज़नेस कैपेबिलिटी से जोड़िए। पाँच क्यों से रूट कॉज़ खोजिए। MoSCoW से आवश्यकताओं को रैंक कीजिए। जोखिमों को इस आधार पर रैंक कीजिए कि प्रोग्राम को असल में कौन-सा रोक सकता है। हर चरण के बाद असली पोस्ट-मॉर्टम चलाइए। यह गाइड SAP और AI डिलीवरी पर काम कर रहे प्रोग्राम मैनेजरों, कंसल्टेंट्स और स्पॉन्सर्स के लिए है। नीचे की तालिका से शुरू करें: अपना लक्षण ढूँढें और पहले उससे मेल खाता फ़्रेमवर्क इस्तेमाल करें।

क़तर की एक मध्यम आकार की मीडिया कंपनी कई क्षेत्रों में SAP रोल आउट कर रही थी। पहले चरण में फ़ाइनेंस और प्रोक्योरमेंट का go-live था। वह अपनी रिपोर्टिंग में AI फ़ोरकास्टिंग मॉडल भी चाहती थी।

छठे हफ़्ते तक देरी रेंगकर आने लगी थी। बिज़नेस यूज़र कहते थे कि उन्होंने आवश्यकताओं पर साइन-ऑफ़ कर दिया है, फिर भी उन्हें समझ नहीं आ रहा था कि उन्हें मिलने क्या वाला है। AI के यूज़ केस प्रस्तावित हो चुके थे, और कोई यह नहीं बता पा रहा था कि डेटा का मालिक कौन है या आउटपुट का इस्तेमाल कैसे होगा। लोग मीटिंग में देर से आ रहे थे, या आ ही नहीं रहे थे।

वह बीच का दौर था। इसे नाकामी कहने के लिए बहुत जल्दी, और यह दिखावा करने के लिए बहुत देर कि सब अपने आप ठीक हो जाएगा।

हमने फ़्रेमवर्क क़दम-दर-क़दम लागू किए। शुरू में सब कुछ सबको पसंद नहीं आया। कुछ सेशन चुप-चुप रहे। कुछ पटरी से उतर गए। लेकिन ढाँचे ने काम आसान कर दिया: टीम ने गोल-गोल घूमना बंद कर दिया, बैकलॉग सँभालने लायक़ हो गया और AI के यूज़ केस को असली मालिक मिल गए। प्रोजेक्ट योजना से आठ हफ़्ते देर से go-live हुआ। बिल्कुल सही नहीं। पर पूरा हुआ, और दूसरा चरण बेहतर ज़मीन पर, कम अनजानी बातों के साथ शुरू हुआ।

मैंने 23 साल की डिलीवरी में खाड़ी देशों, यूरोप और उससे आगे SAP, Oracle और AI प्रोग्राम पर इन सातों के अलग-अलग रूप इस्तेमाल किए हैं। कोई भी अनोखा नहीं है। सब काम करते हैं, बशर्ते आप उन्हें दस्तावेज़ी कवायद की तरह नहीं, अनुशासन के साथ लागू करें।

लक्षण के हिसाब से फ़्रेमवर्क चुनें:

आपको जो लक्षण दिख रहा है	फ़्रेमवर्क	इससे क्या मिलता है	आम तौर पर कितनी मेहनत
यूज़र ने आवश्यकताओं पर साइन-ऑफ़ कर दिया पर अब भी उलझन में हैं	1. मौजूदा स्थिति की मैपिंग	आज काम असल में कैसे होता है, इसका साझा नक़्शा	3 से 5 दिन के वर्कशॉप
फ़ैसले एक मीटिंग से दूसरी मीटिंग में उछलते रहते हैं	2. अहम फ़ैसलों पर RACI	20 से 30 बड़े फ़ैसलों के नामित मालिक	एक वर्कशॉप, फिर अमल करवाना
स्पॉन्सर "IT प्रोजेक्ट" से कट गए हैं	3. कैपेबिलिटी मैपिंग	बिज़नेस कैपेबिलिटी के रूप में रिपोर्ट की गई प्रगति	fit-to-standard का हिस्सा
एक ही तरह का डिफ़ेक्ट बार-बार लौटता है	4. पाँच क्यों	ऐसा रूट कॉज़ जिसे आप बदल सकें	हर समस्या पर एक फ़ैसिलिटेट किया गया सेशन
हर चीज़ हाई प्रायोरिटी मार्क है	5. MoSCoW	रैंक किया हुआ स्कोप, वास्तविक Must Have सूची के साथ	बिज़नेस और IT का एक संयुक्त सेशन
रिस्क लॉग ठीक दिखता है पर टीम तनाव में है	6. जोखिम रैंकिंग	प्रोग्राम रोकने वाले और सिर्फ़ परेशान करने वाले जोखिमों की अलग सूचियाँ	हर हफ़्ते 30 मिनट की समीक्षा
वही ग़लतियाँ चरण-दर-चरण दोहराई जाती हैं	7. पोस्ट-मॉर्टम	मालिकों के साथ तीन से पाँच बदलाव	हर चरण के बाद आधा दिन

प्रोग्राम की शुरुआत में सबसे आम ग़लती यह है कि जो मौजूद है उसे दस्तावेज़ में उतारे बिना सीधे समाधान पर कूद जाते हैं। प्रोसेस के दस्तावेज़ आम तौर पर पुराने होते हैं। लोग बताते हैं कि काम कैसे होना चाहिए, कैसे होता है यह नहीं। इन दोनों के बीच की खाई में ही इम्प्लीमेंटेशन की समस्याएँ रहती हैं।

काम की मौजूदा स्थिति का नक़्शा बनाने में उन लोगों के साथ तीन से पाँच दिन के वर्कशॉप लगते हैं जो काम करते हैं, उनके साथ नहीं जो उन्हें मैनेज करते हैं। इसमें क्रम से प्रोसेस के क़दम, हर क़दम पर इस्तेमाल होने वाले सिस्टम, हाथ से किए जाने वाले दख़ल और वर्कअराउंड, और विभागों के बीच डेटा का प्रवाह आते हैं।

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

क़तर में मौजूदा स्थिति का नक़्शा दस्तावेज़ों से नहीं, यूज़र के साथ वर्कशॉप से बना। साइन-ऑफ़ हो चुकी आवश्यकताओं को लेकर उलझन वहीं से छँटने लगी।

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

फ़ैसले का अधिकार वह ढाँचागत तत्व है जो SAP और AI प्रोजेक्ट में सबसे ज़्यादा ग़ायब मिलता है। हर किसी की एक राय होती है। अंतिम फ़ैसला कौन करेगा, यह किसी को नहीं पता। फ़ैसले अगली मीटिंग में चले जाते हैं, जो उन्हें स्टीयरिंग कमेटी पर टाल देती है, जो उन्हें वापस वर्किंग ग्रुप के पास भेज देती है।

RACI मैट्रिक्स (Responsible, Accountable, Consulted, Informed) हर फ़ैसले और डिलिवरेबल को एक मालिक देता है। एक व्यक्ति Accountable होता है और वही Responsible भी हो सकता है, या काम सौंप सकता है। Consulted लोग अपनी राय देते हैं। Informed लोगों को नतीजा बताया जाता है।

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

लागू किए बिना RACI सजावट है। नाम उन लोगों के होने चाहिए जिनके पास असली अधिकार है। जवाबदेही किसी नामित व्यक्ति की जगह पद के नाम को सौंप देना इस बातचीत से बचने का तरीक़ा है कि जोखिम का मालिक कौन है।

SAP और AI प्रोग्राम बहुत सारी तकनीकी गतिविधि पैदा करते हैं जो बिज़नेस को दिखती नहीं। जो बनाया जा रहा है और जो नतीजा उसे देना चाहिए, इन दोनों के बीच की कड़ी अमूर्त हो जाती है। स्पॉन्सर दूर हो जाते हैं, और जो देरी असल में बिज़नेस के फ़ैसलों की वजह से होती है, उसका दोष "IT प्रोजेक्ट" पर चला जाता है।

कैपेबिलिटी मैपिंग सिस्टम के फ़ंक्शन को बिज़नेस कैपेबिलिटी से जोड़ती है: संगठन को क्या कर पाना चाहिए। यह ट्रैक करने के बजाय कि परचेज़ ऑर्डर वर्कफ़्लो कॉन्फ़िगर हुआ या नहीं, आप ट्रैक करते हैं कि क्या संगठन सप्लायर इनवॉइस को मिलने के तीन दिन के भीतर प्रोसेस कर सकता है। कॉन्फ़िगरेशन साधन है। कैपेबिलिटी नतीजा है।

SAP Activate में यह Explore के fit-to-standard वर्कशॉप से जुड़ता है। स्कोप का हर प्रोसेस एक कैपेबिलिटी है, और SAP के स्टैंडर्ड और ज़रूरी कैपेबिलिटी के बीच का हर अंतर एक फ़ैसला है: स्टैंडर्ड स्वीकार करें, कोई वेरिएंट कॉन्फ़िगर करें या एक्सटेंड करें। बातचीत को कैपेबिलिटी के स्तर पर रखने से बिल्ड के दौरान बिज़नेस का ध्यान बना रहता है, और वे कैपेबिलिटी भी सामने आ जाती हैं जिन्हें सब स्कोप में मानकर चल रहे थे पर किसी ने पुष्टि नहीं की थी।

जब एक ही तरह की समस्या स्प्रिंट या चरणों में बार-बार दिखती है, तो हर बार उसे पैच करने से कुछ नहीं होता। कारण ऊपर कहीं बैठा है।

पाँच क्यों रूट कॉज़ का सबसे सरल औज़ार है। पूछिए कि समस्या क्यों हुई, फिर पूछिए कि वह क्यों हुआ, तब तक जब तक कोई ऐसी चीज़ न मिल जाए जिसे आप बदल सकें। पाँच दौर में आम तौर पर असली कारण मिल जाता है। दो दौर में आम तौर पर लक्षण पर ही रुक जाते हैं।

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

1. 01ट्रायल लोड की त्रुटियाँलक्षण
2. 02फ़ील्ड मैपिंग ग़लतलोड क्यों फ़ेल हुआ?
3. 03स्पेसिफ़िकेशन की समीक्षा नहीं हुईमैपिंग ग़लत क्यों थी?
4. 04ओनर का नाम देर से तय हुआस्पेसिफ़िकेशन की समीक्षा क्यों नहीं हुई?
5. 05योजना में निर्भरता छूट गईओनर देर से क्यों तय हुआ?

रूट कॉज़ गवर्नेंस का फ़ैसला है, डेटा की मरम्मत नहीं

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

SAP और AI के हर स्कोप विमर्श में सर्वसम्मति का एक जाल होता है। कोई समझौते नहीं करना चाहता, इसलिए सब कुछ हाई प्रायोरिटी बन जाता है। जब सब कुछ हाई प्रायोरिटी हो, तो कुछ भी नहीं होता, और बिल्ड टीम सब कुछ करने की कोशिश करती है।

MoSCoW (Must have, Should have, Could have, Won't have this time) चुनाव करने को मजबूर करता है। Must Have वह न्यूनतम है जो go-live के लिए चाहिए। Should Have अहम है पर रुकावट नहीं। Could Have तब वांछनीय है जब समय और बजट इजाज़त दें। Won't Have को साफ़ तौर पर आगे के लिए टाल दिया जाता है।

अनुशासन Must Have की रेखा में है। MoSCoW अभ्यास के पहले दौर में आम तौर पर Must Have में बहुत ज़्यादा चीज़ें चली जाती हैं। Agile Business Consortium का DSDM मार्गदर्शन, जहाँ से MoSCoW आया है, Must Have पर मेहनत की सीमा 60% रखता है और चेताता है कि इससे ऊपर जाने पर डिलीवरी ख़तरे में पड़ जाती है। पहले दौर की सूची और वास्तविक सूची के बीच का अंतर ज़्यादातर बिना परखी मान्यताओं का होता है।

MoSCoW बिज़नेस और टेक्नोलॉजी को एक ही कमरे में बिठाकर चलाएँ। अलग-अलग चलाने पर IT की Must Have सूची और बिज़नेस की Must Have सूची आपस में मेल नहीं खातीं, और कॉन्फ़िगरेशन शुरू होने तक कोई उन्हें मिलाता नहीं।

ज़्यादातर रिस्क रजिस्टर लंबी सूचियाँ होते हैं जिन्हें संभावना और असर के हिसाब से स्कोर किया जाता है, महीने में एक बार देखा जाता है, और RAG स्टेटस शायद ही कभी हिलते हैं। वे जोखिम दर्ज करते हैं, कार्रवाई को आगे नहीं बढ़ाते।

उन जोखिमों को अलग कीजिए जो प्रोग्राम रोक सकते हैं और उन्हें जो उसे मुश्किल बनाते हैं। पहले समूह को मालिक, रिस्पॉन्स प्लान और हर हफ़्ते की विज़िबिलिटी चाहिए। दूसरे को निगरानी चाहिए।

क़तर में रिस्क लॉग काग़ज़ पर ठीक दिखता था, पर सब बेचैन थे। हर हफ़्ते देखा जाने वाला, महीने में एक बार नहीं, एक तेज़ रिस्क-इम्पैक्ट मैट्रिक्स असली चिंताओं को बाहर ले आया।

जो रजिस्टर ठीक दिखे जबकि टीम तनाव में हो, वह लगभग हमेशा कुछ छिपा रहा होता है। रजिस्टर सच नहीं है; उसके आसपास की बातचीत सच है। "मद 14 का स्टेटस क्या है?" से ज़्यादा "कल रात किस बात ने आपकी नींद उड़ाई?" पूछने वाली साप्ताहिक समीक्षा सामने लाती है। स्कोरिंग और मालिकाना हक़ का टेम्पलेट मेरे SAP रिस्क असेसमेंट मैट्रिक्स में है।

किसी चरण या go-live के बाद का पोस्ट-मॉर्टम अगले चरण में वही ग़लतियाँ दोहराए जाने से रोकता है। शेड्यूल पर दबाव हो तो सबसे पहले यही कटता है।

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

आम विफलता सफ़ाई देने की कवायद है, जहाँ टीमें फ़ैसलों को परखने के बजाय उनका बचाव करती हैं। इसे आगे की ओर देखने वाला रखिए। सवाल यह नहीं कि छठे हफ़्ते की देरी किसने की। सवाल यह है कि अगले चरण में उन्हें रोकने के लिए कौन-सा ढाँचागत बदलाव चाहिए।

क़तर में पोस्ट-मॉर्टम go-live के ठीक बाद हुआ और दोष पर नहीं, कार्रवाई पर केंद्रित रहा। दूसरा चरण बेहतर ज़मीन पर शुरू होने की यह एक बड़ी वजह है।

फ़्रेमवर्क नहीं बदले हैं। उन्हें लागू करने का तरीक़ा तीन तरह से बदला है।

ड्राफ़्ट बनाना तेज़ हुआ; सुनना नहीं। AI टूल अब वर्कशॉप के ट्रांसक्रिप्ट और प्रोसेस दस्तावेज़ों से मिनटों में पहला नक़्शा बना देते हैं, और SAP Cloud ALM fit-to-standard ट्रांसक्रिप्ट से आवश्यकताओं का ड्राफ़्ट बना सकता है। वर्कशॉप में उतना ही समय लगता है जितना हमेशा लगता था, क्योंकि सुनना ही असली बात है। ड्राफ़्टिंग में जो समय बचे, उसे लोगों के साथ नक़्शे को चुनौती देने में लगाना चाहिए।

RACI के ड्राफ़्ट तैयार मिलते हैं, कठिन हिस्सा बना रहता है। कोई सामान्य उद्देश्य वाला AI असिस्टेंट चार्टर और वर्क पैकेज की सूची से एक मिनट में RACI बना देगा। अनुशासन अब बातचीत की ओर खिसकता है: हर ख़ाने के लिए अधिकार और एस्केलेशन पर असली बातचीत चाहिए। ड्राफ़्ट बनाने में जो समय बचे, उसे उन्हीं कठिन बातचीतों में लगाना चाहिए।

AI के कमरे में होने से MoSCoW और कठिन हो जाता है। आवश्यकताओं की AI रैंकिंग सुनने में तर्कसंगत, सलीक़ेदार और स्थानीय राजनीति के बारे में अक्सर ग़लत होती है। जो कंसल्टेंट उसे बिना चुनौती दिए मान लेते हैं, वे कोरी शीट से शुरू करने वालों से बुरी प्राथमिकता सूचियाँ बनाते हैं। AI के ड्राफ़्ट को शुरुआती बिंदु मानें, जवाब कभी नहीं।

इन फ़्रेमवर्क के ऊपर की परख अब पहले से ज़्यादा क़ीमती है, कम नहीं। अगर आप कंसल्टेंट के तौर पर ये हुनर बना रहे हैं, तो SAPopedia के करियर पाथ बताते हैं कि SAP करियर के हर चरण पर कौन-से हुनर मायने रखते हैं।

कंसल्टिंग फ़्रेमवर्क क्या हैं और SAP प्रोजेक्ट इनका इस्तेमाल क्यों करते हैं?

ये विश्लेषण, फ़ैसलों और समस्या-समाधान के संरचित तरीक़े हैं। SAP और AI प्रोग्राम में ये बिज़नेस लीड, आर्किटेक्ट, प्रोजेक्ट मैनेजर, इंटीग्रेटर और स्पॉन्सर को एक साझा तरीक़ा देते हैं।

इसके बिना हर समूह अपने ही मानसिक मॉडल पर लौट जाता है: प्रोसेस के नतीजे, आर्किटेक्चर, या टाइमलाइन और संसाधन। मौजूदा स्थिति की मैपिंग, RACI और MoSCoW जैसे फ़्रेमवर्क असहमति को साफ़ और सुलझने लायक़ बना देते हैं। SAP Activate ख़ुद चरणों, गेट और डिलिवरेबल का एक फ़्रेमवर्क है; ये सात उसके भीतर काम करते हैं और उन ढाँचागत और मानवीय मुद्दों से निपटते हैं जिन्हें अकेली कार्यपद्धति नहीं सुलझाती।

SAP इम्प्लीमेंटेशन में मौजूदा स्थिति की मैपिंग कैसे काम करती है?

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

यह SAP Activate के Explore चरण के fit-to-standard वर्कशॉप को जानकारी देती है, जहाँ मौजूदा स्थिति वह बेसलाइन बन जाती है जिसकी तुलना SAP के स्टैंडर्ड प्रोसेस से की जाती है। उन वर्कशॉप के शुरू होने से पहले इसे पूरा कर लें, वरना आपका गैप विश्लेषण मान्यताओं पर टिका रहेगा।

MoSCoW प्राथमिकता क्या है और SAP प्रोग्राम में इसका इस्तेमाल कब होता है?

MoSCoW आवश्यकताओं को Must have, Should have, Could have और Won't have this time में छाँटता है। Must Have go-live के लिए न्यूनतम हैं; Won't Have को साफ़ तौर पर बाहर रखा जाता है ताकि वे वापस न घुस आएँ।

यह Explore में सबसे ज़्यादा काम आता है, जब fit-gap के नतीजे एक्सटेंशन के फ़ैसले तय करते हैं, और Realize में, जब डिफ़ेक्ट और एन्हांसमेंट बिल्ड के समय के लिए होड़ करते हैं। आम समस्या पहले दौर में बहुत ज़्यादा Must Have की है। DSDM सुझाता है कि Must Have पर मेहनत 60% से ज़्यादा न हो; हर एक को चुनौती देने वाला फ़ैसिलिटेटर, बिज़नेस और IT को एक ही सेशन में रखकर, आपको वहाँ पहुँचा देता है।

SAP प्रोजेक्ट में असरदार रिस्क समीक्षा कैसे चलाएँ?

बातचीत की तरह, स्टेटस अपडेट की तरह नहीं। रजिस्टर पर जाने से पहले "इस हफ़्ते आपकी सबसे बड़ी चिंता क्या है जो रजिस्टर में नहीं है?" जैसे खुले सवालों से शुरू करें।

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

SAP go-live के बाद उपयोगी पोस्ट-मॉर्टम कैसा होता है?

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

यह दर्ज करें कि आप क्या हासिल करने निकले थे, क्या हासिल किया, क्या चला और क्या नहीं। "हमारे पास संसाधन कम थे" जैसी ऊपरी व्याख्याओं से नीचे जाएँ: संसाधन योजना ग़लत थी, स्कोप ग़लत था, या एस्केलेशन का रास्ता टूटा था? अंत तीन से पाँच बदलावों पर करें, हर एक के साथ मालिक और तारीख़।

SAP माहौल में AI इम्प्लीमेंटेशन में कंसल्टिंग फ़्रेमवर्क कैसे मदद करते हैं?

AI प्रोजेक्ट उन्हीं ढाँचागत कारणों से फ़ेल होते हैं जिनसे SAP प्रोजेक्ट, और कुछ अपने भी: बिना मालिक का डेटा, अपरिभाषित सफलता के पैमाने और आउटपुट पर अमल करने की कोई तय प्रक्रिया न होना।

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