SAP स्टेकहोल्डर मैनेजमेंट: टकराव शुरू होने से पहले ही रोकें

SAP स्टेकहोल्डर मैनेजमेंट तय करता है कि प्रोग्राम समय पर पूरा होगा या अपनी आख़िरी तिमाही बहस में गुज़ारेगा। यह चार आदतों पर आकर टिकता है। पहचानिए कि कौन मायने रखता है और हर समूह को किस बात की परवाह है। लिखिए कि किसे क्या तय करने का अधिकार है। SAP Activate के फ़ेज़ से मेल खाती कम्युनिकेशन कैडेंस चलाइए। हर अहम फ़ैसले को उसके विकल्पों के साथ दर्ज कीजिए। यह गाइड S/4HANA प्रोग्राम के प्रोग्राम डायरेक्टर, PMO और एक्ज़ीक्यूटिव स्पॉन्सर के लिए है। पहली वर्कशॉप से पहले अपना एंगेजमेंट प्लान बनाने के लिए नीचे दी गई रोल टेबल और फ़ेज़-दर-फ़ेज़ कैडेंस का इस्तेमाल कीजिए।

मैंने एक बार एक SAP रोलआउट पर काम किया जहाँ IT सिस्टम पर कड़े कंट्रोल चाहता था और फ़ाइनेंस को ज़्यादा लचक चाहिए थी। जब तक हम आए, दोनों टीमों ने बात करना बंद कर दिया था। फ़ाइनेंस झुँझलाया हुआ था। IT रक्षात्मक। लीडरशिप जानना चाहती थी कि कोई आपस में बात क्यों नहीं कर रहा।

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

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

SAP प्रोग्राम में हर किसी की चिंताएँ और प्रभाव एक जैसे नहीं होते। सबको एक ही दर्शक मानेंगे तो अप्रासंगिक अपडेट भेजेंगे और असली जोखिम चूक जाएँगे।

भूमिका	उन्हें किस बात की परवाह है	उन्हें कैसे जोड़ें
एक्ज़ीक्यूटिव स्पॉन्सर (CEO, COO, ग्रुप CFO)	रिटर्न, बिज़नेस जोखिम, प्रोग्राम की साख	सीधा, नियमित, संक्षिप्त
स्टीयरिंग कमेटी (CIO, CFO, बिज़नेस यूनिट प्रमुख)	टाइमलाइन, बजट, स्कोप	फ़ैसलों वाली संरचित स्टीयरिंग समीक्षाएँ
फ़ाइनेंस लीडरशिप (CFO, कंट्रोलर)	रेवेन्यू रिकग्निशन, रिपोर्टिंग की विश्वसनीयता, कंट्रोल	डिज़ाइन में शुरू से शामिल करना; FI/CO स्कोप पर साइन-ऑफ़
ऑपरेशंस और बिज़नेस लीड	प्रोसेस की निरंतरता, ट्रेनिंग, इस्तेमाल में आसानी	डिज़ाइन वर्कशॉप; यूज़र एक्सेप्टेंस टेस्टिंग (UAT) की ज़िम्मेदारी
IT लीडरशिप (CIO, आर्किटेक्चर प्रमुख)	आर्किटेक्चर, सिक्योरिटी, इंटीग्रेशन, सपोर्ट	तकनीकी डिज़ाइन पर साइन-ऑफ़
बिज़नेस प्रोसेस ओनर	प्रोसेस की सटीकता, अपवाद, एज केस	डिज़ाइन वर्कशॉप की अगुवाई; कॉन्फ़िगरेशन पर साइन-ऑफ़
एंड यूज़र	सीखने की चुनौती, रोज़ का काम, नौकरी में बदलाव	ट्रेनिंग और चेंज मैनेजमेंट
सिस्टम इंटीग्रेटर (SI)	डिलिवरी स्कोप, चेंज रिक्वेस्ट, रिसोर्सिंग	औपचारिक गवर्नेंस और स्कोप दस्तावेज़
HR और चेंज मैनेजमेंट	लोगों पर असर, भूमिकाओं में बदलाव, संवाद	डिलिवरी के समानांतर एक वर्कस्ट्रीम

पावर-इंटरेस्ट ग्रिड बताता है कि मेहनत कहाँ लगानी है। CIO, CFO और स्पॉन्सर दोनों पैमानों पर ऊपर हैं: वे बदलावों को मंज़ूरी देते हैं, go-live टाल सकते हैं और लोगों का आवंटन करते हैं, और अगर वे दूर हो जाएँ तो प्रोग्राम को मिला संरक्षण हट जाता है। प्रोसेस ओनर, कंट्रोलर और आर्किटेक्ट की दिलचस्पी ज़्यादा होती है और औपचारिक ताक़त कम, पर बिज़नेस असल में कैसे चलता है, इसकी उनकी समझ उन्हें डिज़ाइन में ज़रूरी बना देती है। बोर्ड के सदस्यों और प्रोग्राम से बाहर के एक्ज़ीक्यूटिव को मील के पत्थरों पर ब्रीफ़िंग चाहिए, साप्ताहिक अपडेट नहीं। एंड यूज़र के पास प्रभाव कम है और उन पर असर सबसे ज़्यादा पड़ता है: go-live पर उनकी सहमति तय करती है कि सिस्टम व्यवहार में चलेगा या नहीं।

नतीजे पर उनका प्रभावज़्यादामध्यमकम

• बोर्ड, बाहर के एक्ज़ीक्यूटिव

• स्पॉन्सर, CFO, CIO

• प्रोसेस ओनर
• कंट्रोलर, आर्किटेक्ट

• एंड यूज़र

कममध्यमज़्यादाप्रोग्राम उन पर कितना असर डालता है

सबसे असरदार जुड़ाव वह है जो किसी की शिकायत आने से पहले हो जाता है। किक-ऑफ़ पर तीन चीज़ें पक्की कर लीजिए।

फ़ैसले के अधिकार

स्कोप में बदलाव को मंज़ूरी कौन दे सकता है? UAT पर साइन-ऑफ़ कौन करता है? go-live में देरी का मामला स्टीयरिंग कमेटी तक कौन ले जा सकता है? इसे लिखिए, इस पर दस्तख़त करवाइए और प्रोजेक्ट चार्टर में डालिए। प्रोजेक्ट के बीच में जब किसी फ़ैसले पर विवाद हो, तब आप इसी दस्तावेज़ की ओर इशारा करते हैं।

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

कम्युनिकेशन कैडेंस

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

स्कोप बेसलाइन

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

प्रोग्राम जैसे-जैसे SAP Activate के फ़ेज़ से गुज़रता है, जुड़ाव की ज़रूरतें बदलती हैं। जो Explore में चलता है, वह Deploy में नहीं चलता। इसे अपने एंगेजमेंट प्लान की रीढ़ बनाइए:

फ़ेज़	जुड़ाव का फ़ोकस	कैडेंस	कौन अगुवाई करता है
Discover और Prepare	रोल मैप, गवर्नेंस ढाँचा, स्पॉन्सर ब्रीफ़िंग, फ़ाइनेंस, ऑपरेशंस और IT के साथ पहले अलाइनमेंट सेशन	शुरुआत में स्पॉन्सर ब्रीफ़; स्टीयरिंग की स्थापना	प्रोग्राम डायरेक्टर
Explore	बिज़नेस लीड और प्रोसेस ओनर के साथ Fit-to-Standard वर्कशॉप; साइन-ऑफ़ से पहले fit-gap फ़ैसलों की समीक्षा	साप्ताहिक वर्किंग सेशन; फ़ेज़ के अंत में स्टीयरिंग	सॉल्यूशन आर्किटेक्ट और प्रोसेस ओनर
Realize	UAT की तैयारी; टेस्टिंग के लिए बिज़नेस लीड का समय सुरक्षित रखना; डिफ़ेक्ट और डेटा माइग्रेशन की स्थिति	स्टीयरिंग हर दो हफ़्ते में; वर्कस्ट्रीम लीड हर हफ़्ते	प्रोग्राम मैनेजर
Deploy	कटओवर की तैयारी, कटओवर शुरू होने से पहले तय किए गए go/no-go मानदंड	रोज़ाना कटओवर स्टैंड-अप; एक्ज़ीक्यूटिव go/no-go ब्रीफ़	बिज़नेस ऑपरेशंस लीड, सहयोग में IT और SI
Run	हाइपरकेयर कम्युनिकेशन, इश्यू चैनल, स्टेबलाइज़ेशन समीक्षाएँ	दो हफ़्ते रोज़, फिर साप्ताहिक; 30, 60 और 90 दिन पर समीक्षाएँ	सपोर्ट लीड और प्रोसेस ओनर

दो फ़ेज़ सबसे ज़्यादा परेशानी देते हैं। Explore में कमरे में ग़लत लोग हों, तो फ़ैसले Realize में, कॉन्फ़िगरेशन शुरू होने के बाद, दोबारा खुल जाते हैं। Realize में UAT ओनर का उपलब्ध न होना या तैयार न होना एक आम पैटर्न है। इसे प्लान में Explore के दौरान ही ठीक कीजिए, टेस्टिंग शुरू होने से दो हफ़्ते पहले नहीं।

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

1. एक्सटेंशन रिव्यू फ़ोरम। हर गैप पर एक फ़ैसला चाहिए: उसे कॉन्फ़िगर करें, जारी किए गए API के ज़रिए एक्सटेंड करें (ABAP Cloud के साथ on-stack या SAP BTP पर side-by-side), या ठुकरा दें। S/4HANA Cloud Public Edition में कोर में बदलाव संभव नहीं है। Private Edition में संभव है, पर हर बदलाव अपग्रेड का काम बढ़ाता है। स्टीयरिंग के नीचे एक छोटा फ़ोरम, जिसमें एक आर्किटेक्ट को फ़ैसले का अधिकार हो, हर कस्टमाइज़ेशन बहस को स्टीयरिंग तक पहुँचने से रोकता है। इसे छोड़ दिया तो टेक्निकल डेट पहले बड़े अपग्रेड पर सामने आता है।
2. SAP के साथ कस्टमर सक्सेस कैडेंस। SAP की टीम अडॉप्शन, BTP के इस्तेमाल और रोडमैप पर जुड़ती है। यह इम्प्लीमेंटेशन गवर्नेंस के समानांतर चलता है और go-live के बाद भी जारी रहता है। इसे अलग चलाने के बजाय अपनी गवर्नेंस में समेट लीजिए।
3. SAP तक एस्केलेशन का रास्ता। जब प्लेटफ़ॉर्म स्तर पर कुछ फ़ेल हो, तो CIO को पता होना चाहिए कि SAP में किसे फ़ोन करना है, सिर्फ़ पार्टनर में नहीं। साइन करने से पहले संपर्क और सर्विस लेवल पक्के कर लीजिए।

Public Edition पर GROW with SAP प्रोग्राम को यही तीनों चीज़ें हल्के रूप में चाहिए: कम एक्सटेंशन फ़ैसले, क्योंकि एक्सटेंड करने की गुंजाइश ही कम है; ज़्यादा मानकीकृत सक्सेस कैडेंस; और एस्केलेशन, जो आमतौर पर पहले पार्टनर के ज़रिए चलता है। ऑन-प्रेमिस प्रोग्राम पारंपरिक मॉडल पर ही रहते हैं, जिसमें SAP भागीदार नहीं, एक वेंडर होता है।

AI टूल जुड़ाव के काग़ज़ी काम में मदद करते हैं, रिश्तों में नहीं।

मीटिंग की समरी सबसे साफ़ जीत है। Microsoft Copilot रिकॉर्ड की गई स्टीयरिंग मीटिंग को ऐसे ड्राफ़्ट मिनट्स में बदल देता है जिन्हें लंबा लिखने के बजाय बस थोड़ा देखना पड़ता है। वह जो फ़ैसले पकड़ता है, वे आमतौर पर सही होते हैं, क्योंकि वह याददाश्त से नहीं, ट्रांसक्रिप्ट से काम करता है।

डिसीज़न लॉग दूसरे नंबर पर आते हैं। Confluence के AI फ़ीचर, जो अब Atlassian के Rovo ब्रांड के तहत हैं, टेम्पलेट बना लेने के बाद मीटिंग नोट्स को संरचित डिसीज़न-लॉग एंट्री में बदल सकते हैं।

Explore में रिक्वायरमेंट का ड्राफ़्ट बनाने में मदद मिलती है। SAP Cloud ALM, Fit-to-Standard वर्कशॉप के ट्रांसक्रिप्ट से रिक्वायरमेंट का ड्राफ़्ट बना सकता है। फिर भी हर पंक्ति को जाँचने के लिए एक व्यक्ति चाहिए।

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

SAP के विरोध का लगभग हमेशा कोई तर्कसंगत आधार होता है। पीछे हटने वाला व्यक्ति आमतौर पर कुछ बचा रहा होता है: पुराने सिस्टम की किसी कमी को ढकने वाला वर्कअराउंड, कोई मैनुअल जाँच जो स्टैंडर्ड प्रोसेस में दिखती नहीं, या इस बात की चिंता कि उसकी टीम यह बदलाव सँभाल पाएगी या नहीं। प्रतिक्रिया देने से पहले वह आधार खोजिए। असल चिंता को सुलझाइए, और विरोध आमतौर पर बिना टकराव के चला जाता है।

“हमें यह कस्टमाइज़ेशन चाहिए”

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

“हम go-live के लिए तैयार नहीं हैं”

इसे गंभीरता से लीजिए। जब कोई बिज़नेस लीड कहता है कि वह तैयार नहीं है, तो आमतौर पर उसके पास कारण होता है: डेटा की गुणवत्ता, अधूरी ट्रेनिंग, बिना टेस्ट किया हुआ प्रोसेस। ख़ास चिंता खोजिए। अगर वह जायज़ है, तो go-live टलना चाहिए। अगर वह सबूत की नहीं, घबराहट की बात है, तो उसका जवाब केंद्रित तैयारी से दीजिए, नई तारीख़ से नहीं।

सबसे आम रूप: UAT में ऐसी समस्याएँ सामने आईं जो अभी ठीक नहीं हुईं। आगे बढ़ते रहने से समस्या UAT से प्रोडक्शन में पहुँच जाती है। दो हफ़्ते की देरी की क़ीमत आमतौर पर उस हाइपरकेयर अवधि से बहुत कम होती है जो go-live से पहले से ज्ञात समस्याओं पर निकल जाती है।

“हमें इस बदलाव के बारे में किसी ने बताया नहीं”

यह संवाद की विफलता है। व्यक्ति डिस्ट्रीब्यूशन लिस्ट में था पर डिज़ाइन सेशन में नहीं, या बदलाव किसी ऐसे दस्तावेज़ में पड़ा रहा जिसे उसने कभी पढ़ा ही नहीं। इस पर बहस मत कीजिए कि किसने क्या बताया। माफ़ी माँगिए, उन्हें बदलाव समझाइए, उन्हें उनके क्षेत्र की आगामी डिज़ाइन समीक्षाओं में जोड़िए और एंगेजमेंट प्लान की कमी दूर कीजिए।

जब कोई टकराव वर्किंग लेवल से बड़ा हो जाए, तब तीन बातें मायने रखती हैं।

इसे गवर्नेंस के भीतर रखिए। सिस्टम एक्सेस पर फ़ाइनेंस और IT का विवाद स्टीयरिंग का मामला है, ऐसा नहीं कि जो ज़्यादा अड़ा रहे वह अनौपचारिक रूप से सुलझा ले। संरचनात्मक टकराव का अनौपचारिक समाधान नाराज़गी और दोबारा खुले फ़ैसले पैदा करता है।

इसे बिज़नेस की भाषा में रखिए। फ़ाइनेंस और IT का एक्सेस कंट्रोल पर बहस करना राजनीति है। फ़ाइनेंस और IT का सिक्योरिटी जोखिम को ऑपरेशनल लागत के सामने रखकर पेश करना एक बिज़नेस फ़ैसला है, और स्टीयरिंग उसे ले सकती है। एक को दूसरे में बदलना प्रोग्राम मैनेजर का काम है, या SI लीड का, कॉन्ट्रैक्ट के हिसाब से।

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

अगर प्रोग्राम मैनेजर का इनबॉक्स अर्जेंट एस्केलेशन से भरा है, तो प्लान काम नहीं कर रहा। स्वस्थ प्रोग्राम संरचित फ़ैसलों पर चलते हैं, रोज़ की आग बुझाने पर नहीं।

अच्छे संकेत: स्टीयरिंग मीटिंग फ़ैसले देती हैं, टालमटोल नहीं; बिज़नेस लीड बिना पीछे पड़े वर्कशॉप और UAT में आते हैं; स्कोप बदलाव चेंज प्रोसेस से आते हैं; go-live के बाद की समस्याएँ तय चैनलों से आती हैं; डिसीज़न लॉग अप-टू-डेट है और स्टीयरिंग में उसका हवाला दिया जाता है।

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

चेतावनी के संकेत दिखें तो मौजूदा प्लान पर और ज़ोर मत लगाइए। पता कीजिए कि कौन-सा हिस्सा फ़ेल हो रहा है (कैडेंस, अधिकार, संवाद या दस्तावेज़ीकरण) और उसी को ठीक कीजिए। और ज़्यादा ईमेल और और ज़्यादा मीटिंग इसे बदतर बनाती हैं। स्टीयरिंग कमेटी के बारे में मेरी गाइड असरदार SAP स्टीयरिंग कमेटी कैसे बनाएँ देखिए, और go-live के लोगों वाले पक्ष के लिए SAP चेंज मैनेजमेंट पर मेरे नोट्स।

SAP इम्प्लीमेंटेशन में स्टेकहोल्डर मैनेजमेंट क्या है?

यह उस संरचित काम का नाम है जिसमें पहचाना जाता है कि प्रोग्राम पर किसका प्रभाव या दिलचस्पी है, उनकी चिंताएँ समझी जाती हैं, संवाद और फ़ैसले लेने की व्यवस्था बनाई जाती है, और उन्हें किक-ऑफ़ से हाइपरकेयर तक जोड़े रखा जाता है।

SAP एक साथ फ़ाइनेंस, HR, प्रोक्योरमेंट, ऑपरेशंस और IT को छूता है, और हर एक की प्राथमिकताएँ और प्रभाव अलग हैं। सबको एक ही दर्शक मानकर चलने से सामान्य अपडेट बनते हैं और वे चिंताएँ छूट जाती हैं जो विरोध की जड़ होती हैं। SAP Activate इसे हर फ़ेज़ में शामिल करता है: Explore की वर्कशॉप, Realize में UAT की ज़िम्मेदारी और Deploy में रेडीनेस समीक्षाएँ, सब तैयार बिज़नेस प्रतिभागियों पर निर्भर हैं।

SAP प्रोजेक्ट के लिए रोल मैप कैसे बनाएँ?

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

मैप को अप-टू-डेट रखिए। लोग भूमिकाएँ बदलते हैं, प्रोग्राम के दिखने के साथ प्रभाव बदलता है, और स्कोप बढ़ने पर नए प्रतिभागी जुड़ते हैं।

SAP एंगेजमेंट प्लान में क्या होना चाहिए?

एक रोल रजिस्टर (नाम, फ़ंक्शन, प्रभाव, दिलचस्पी, मुख्य चिंताएँ), एक कम्युनिकेशन प्लान (हर समूह के लिए चैनल, आवृत्ति और सामग्री), स्कोप बदलावों, डिज़ाइन फ़ैसलों और go-live की तैयारी के लिए फ़ैसले के अधिकार, हर Activate फ़ेज़ की गतिविधियाँ, विवादित फ़ैसलों के लिए एस्केलेशन का रास्ता, और चिंताओं को औपचारिक रूप से उठाने का तरीक़ा।

इसे हर फ़ेज़ गेट पर अपडेट कीजिए। इसे इतने अच्छे से दर्ज कीजिए कि टीम इसे चला सके और हर बातचीत प्रोग्राम मैनेजर को ख़ुद न सँभालनी पड़े, क्योंकि तीस नामित प्रतिभागियों के बाद यह तरीक़ा नहीं चलता।

बिज़नेस लीड के SAP-विरोध को कैसे सँभालें?

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

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

SAP प्रोग्राम में फ़ाइनेंस और IT के टकराव को कैसे सँभालें?

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

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

RISE with SAP स्टेकहोल्डर मैनेजमेंट को कैसे बदलता है?

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