सीधे कंटेंट पर जाएँ

चेंज मैनेजमेंट प्लान: विरोध शुरू होने से पहले ही उसे सुलझाएँ

ERP प्रोग्राम में विरोध ट्रेनिंग शुरू होने से बहुत पहले पनपने लगता है। चेंज मैनेजमेंट प्लान में क्या होना चाहिए, हर हिस्सा किसका है, और विरोध के शुरुआती संकेत कैसे पहचानें।

चेंज मैनेजमेंट के बारे में कैप्शन के बगल में स्टिकी नोट्स, जिन पर बदलाव का समय लिखा है
विषय-सूची
  1. प्लान में क्या-क्या होना चाहिए
  2. कम्युनिकेशन: मात्रा से ज़्यादा स्पष्टता
  3. प्रभाव की मैपिंग
  4. ट्रेनिंग और एडॉप्शन
  5. go-live से पहले तय करने वाले एडॉप्शन KPI
  6. डिजिटल एडॉप्शन टूल
  7. बीच रास्ते में विरोध को संभालना
  8. अक्सर पूछे जाने वाले सवाल

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

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

यह आम तौर पर कुछ पहचानी हुई जगहों से शुरू होता है:

  1. शुरुआती डिज़ाइन से बाहर रखे गए की यूज़र।
  2. डिपार्टमेंट हेड, जिन्हें ऐसे असर का पता चलता है जिन पर किसी ने उनसे बात नहीं की।
  3. अस्पष्ट कम्युनिकेशन, जो लोगों को शक करने का मौक़ा देता है।
  4. पिछले असफल प्रोजेक्ट, जो अंदर ही अंदर अविश्वास छोड़ गए।

ये ढाँचे की समस्याएँ हैं, सिर्फ़ कम्युनिकेशन की नहीं। अगर स्टीयरिंग कमेटी निष्क्रिय है, तो अड़चनें आएँगी। अगर प्रोजेक्ट चार्टर में एडॉप्शन का कोई ज़िक्र नहीं है, तो एक ज़रिया आप पहले ही खो चुके हैं।

चेंज का काम प्रोग्राम में कहाँ बैठता हैट्रेनिंग छह में से चौथा चरण है। जो चेंज मैनेजमेंट वहाँ से शुरू होता है, वह पहले ही देर कर चुका है।
  1. मोबिलाइज़ेशनप्रभाव का नक्शा बनाएँ और अनौपचारिक इतिहास जुटाएँ
  2. डिज़ाइनएडॉप्शन KPI तय करें, पावर यूज़र सह-लेखक बनें
  3. टेस्टिंगबिज़नेस यूज़र अपने प्रोसेस खुद टेस्ट करें
  4. ट्रेनिंगभूमिका के हिसाब से, असली डेटा पर, ऐसे समय पर जब लोग आ सकें
  5. Go-live गेटएडॉप्शन की सीमाएँ, सिर्फ़ फ़ंक्शनल साइन-ऑफ़ नहीं
  6. पहले 90 दिनलॉगिन, एरर, टिकट और वर्कअराउंड पर नज़र रखें

वर्कअराउंड आदत बनने से पहले पकड़े जाते हैं

चेंज प्लान कम्युनिकेशन का कैलेंडर नहीं है। ये सात घटक हैं और हर एक का ओनर कौन होना चाहिए।

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

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

मुझे एक रोलआउट याद है जिसमें हमने सब कुछ समय पर बताया, फिर भी कोई यह नहीं समझा पा रहा था कि प्रोसेस क्यों बदल रहा है। हमारे पास मात्रा थी, स्पष्टता नहीं।

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

फ़ीडबैक की जगह बनाएँ। सिर्फ़ बाहर की ओर जाने वाला कम्युनिकेशन आधा प्लान है। मैंने एक ऐसी टीम के साथ काम किया है जहाँ हर हफ़्ते की Q&A कॉल का असर किसी भी ईमेल से ज़्यादा था। जो सुनें, उसे रिस्क रजिस्टर से जोड़ें, ताकि कमज़ोर कड़ियाँ सबके सामने आने से पहले ही दिख जाएँ।

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

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

हर व्यक्ति के लिए तीन बातें दर्ज करें: बदलाव का उस पर कितना असर पड़ता है, आज वह कहाँ खड़ा है (समर्थक, तटस्थ या विरोधी), और दूसरों पर उसका कितना प्रभाव है। जिस विरोधी मिडिल मैनेजर के पीछे उसकी पूरी टीम चलती है, वह किसी अकेले विरोधी यूज़र से ज़्यादा मायने रखता है।

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

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

जो काम करता है:

  1. भूमिका के हिसाब से कंटेंट। हर समूह को वही सिखाएँ जो उसके अपने काम के लिए चाहिए, सिस्टम का टूर नहीं।
  2. असली डेटा पर अभ्यास। बिज़नेस का अपना डेटा और ट्रांज़ैक्शन इस्तेमाल करें, डेमो परिदृश्य नहीं।
  3. पावर यूज़र ट्रेनर के रूप में। लोग उन सहकर्मियों से बेहतर सीखते हैं जिन पर वे भरोसा करते हैं। पावर यूज़र को सिर्फ़ टेस्टर नहीं, डिज़ाइन के सह-लेखक मानें।
  4. ट्रेनिंग सही समय पर। जिस फ़ाइनेंस टीम के साथ मैंने काम किया, वह सत्र छोड़ती रही क्योंकि वे गलत समय पर रखे गए थे। समय बदलते ही बात बन गई।
  5. go-live के बाद सपोर्ट। आत्मविश्वास go-live के बाद गिरता है, पहले नहीं। हाइपरकेयर में ऐसे लोग लगाएँ जो असली सवालों के जवाब जल्दी दे सकें।

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

एडॉप्शन की सीमाएँ अपने क्वालिटी गेट्स में रखें। ‘सिस्टम काम करता है’ फ़ंक्शनल साइन-ऑफ़ है। ‘यूज़र इसमें काम करने के लिए तैयार हैं’ एक अलग साइन-ऑफ़ है, और ज़्यादातर प्रोग्राम सिर्फ़ पहला माँगते हैं। मेरी SAP ट्रेनिंग रणनीतियों की गाइड ट्रेनिंग प्लान पर और गहराई से जाती है।

go-live से पहले तय करने वाले एडॉप्शन KPI

इन्हें डिज़ाइन के दौरान तय करें, ताकि नापने के लिए एक बेसलाइन मौजूद रहे:

  1. पहले 90 दिनों में यूज़र समूह के हिसाब से लॉगिन दर।
  2. अहम ट्रांज़ैक्शन में एरर दर, लेगेसी बेसलाइन के मुक़ाबले।
  3. वॉल्यूम और श्रेणी के हिसाब से सपोर्ट टिकट।
  4. वर्कअराउंड कितनी बार हो रहे हैं: स्प्रेडशीट में एक्सपोर्ट, समानांतर रिकॉर्ड, सिस्टम के बाहर मैन्युअल अप्रूवल।
  5. छोटे पल्स सर्वे में मैनेजरों का बताया आत्मविश्वास।

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

डिजिटल एडॉप्शन टूल

SAP ने सितंबर 2024 में WalkMe का अधिग्रहण पूरा किया, लगभग 1.5 अरब डॉलर की इक्विटी वैल्यू पर। SAP ने उस समय कहा था कि WalkMe की AI क्षमताएँ वर्कफ़्लो भर में Joule को संदर्भ समझने वाली मदद देंगी। यानी अब SAP के पास अलग-अलग ताक़त वाले दो एडॉप्शन टूल हैं:

  • SAP Enable Now स्ट्रक्चर्ड ट्रेनिंग कंटेंट के लिए ठीक बैठता है: किसी प्रोसेस को एक बार रिकॉर्ड करें और उससे डॉक्यूमेंटेशन, सिमुलेशन और टेस्ट स्क्रिप्ट बनाएँ।
  • WalkMe इस्तेमाल के क्षण में एप्लिकेशन के भीतर गाइडेंस के लिए ठीक बैठता है, और यह SAP तथा गैर-SAP एप्लिकेशन, दोनों में चल सकता है।

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

मुझे एक रोलआउट याद है जिसमें हमने सब कुछ समय पर बताया, फिर भी कोई यह नहीं समझा पा रहा था कि प्रोसेस क्यों बदल रहा है। हमारे पास मात्रा थी, स्पष्टता नहीं।

अच्छी तैयारी के बाद भी नई अड़चनें आती हैं। उन्हें ज़रूरत से ज़्यादा काबू करने की कोशिश आम तौर पर उलटी पड़ती है। मक़सद उन्हें जल्दी देख लेना है।

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

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

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

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

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

चेंज मैनेजमेंट के 5 C कौन-से हैं?

इसके कई संस्करण हैं। मैं जो इस्तेमाल करता हूँ वह यह है: स्पष्टता (clarity: लोग जानते हैं कि उनके लिए क्या बदल रहा है), एकरूपता (consistency: लीडर एक ही बात कहते हैं), प्रतिबद्धता (commitment: स्पॉन्सर नज़र आता रहता है), कम्युनिकेशन (communication: प्रासंगिक, समय पर और दोतरफ़ा) और क्षमता (capability: ट्रेनिंग, सपोर्ट और ढलने का समय)। इनमें से कोई एक भी न हो तो लोग पुरानी आदतों पर लौट जाते हैं।

चेंज मैनेजमेंट के 7 R कौन-से हैं?

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

ऑर्गेनाइज़ेशनल और टेक्निकल चेंज मैनेजमेंट में क्या अंतर है?

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

WalkMe इस्तेमाल करूँ या SAP Enable Now?

अक्सर दोनों। go-live से पहले स्ट्रक्चर्ड ट्रेनिंग कंटेंट बनाने में SAP Enable Now ज़्यादा मज़बूत है। go-live के बाद एप्लिकेशन के भीतर गाइडेंस के लिए WalkMe बेहतर है, ख़ासकर जब यूज़र SAP और दूसरे एप्लिकेशन के बीच आते-जाते हों। चूँकि दोनों SAP के हैं, इन्हें साथ रखकर परखें। Whatfix मुख्य स्वतंत्र विकल्प है।

ERP प्रोजेक्ट में चेंज मैनेजमेंट कब शुरू होना चाहिए?

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

Noel D'Costa

लेखक

Noel D'Costa

एविएशन, सरकार, फ़ाइनेंस, रिटेल और मैन्युफ़ैक्चरिंग में SAP और Oracle ERP प्रोग्राम पर 25 साल। पृष्ठभूमि फ़ाइनेंस की है। मैं लीडरशिप टीमों की मदद करता हूँ: ट्रांसफ़ॉर्मेशन का स्कोप ईमानदारी से तय करने में, मुश्किल में फँसे प्रोग्राम को वापस पटरी पर लाने में, और ऐसे सिस्टम बनाने में जो प्रोडक्शन के पहले साल में टिके रहें।

अगला कदम

क्या आप अभी कोई ERP प्रोग्राम चला रहे हैं?

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