"चलो ट्रांज़िशन के लिए दो हफ़्ते और दे देते हैं।" अगर आपने किसी सॉफ्टवेयर रोलआउट के दौरान यह वाक्य कभी कहा है, तो अंजाम आप जानते हैं: वे दो हफ़्ते दो महीने बन जाते हैं, और नया टूल कभी पूरी तरह चल ही नहीं पाता। मैंने करीब दस साल IT मैनेजर के तौर पर कंपनी के अंदर के सॉफ्टवेयर बनाए, और यही एक वाक्य — नीयत सबसे अच्छी होने के बावजूद — मेरे ज़्यादातर नाकाम रोलआउट के पीछे था।
छोटा जवाब
अपनी टीम से नया सॉफ्टवेयर कैसे अपनवाएँ? उन्हें शुरू से जोड़िए, समझ में आने वाला टूल चुनिए, असली काम पर ट्रेनिंग दीजिए, और शुरुआती जीत का जश्न मनाइए। किताबी जवाब यही है, और यह गलत भी नहीं है। सॉफ्टवेयर अपनाना जितना टूल का मामला है, उतना ही चेंज मैनेजमेंट का।
पर अकेली किताब कभी काफ़ी नहीं पड़ी। असल में जो काम आया वह इससे आसान था, और काफ़ी ज़्यादा असहज:
हमने पुराना सिस्टम हटा दिया।
जब भी हम नया सॉफ्टवेयर लाते या कोई प्रोसेस बदलते, पुराना रास्ता हम टेबल से हटा देते थे। स्प्रेडशीट लॉक कर दी, पुराना फ़ॉर्म बंद कर दिया। लोग दो हफ़्ते बड़बड़ाते, फिर अपना लेते। और जब हर प्रोसेस नए टूल से चलने लगा, तभी हम ढेर सारा मैनुअल काम ऑटोमेट कर पाए — क्योंकि प्रोसेस चलाने का इकलौता रास्ता वह सॉफ्टवेयर था जो हमारे हाथ में था।
पहले मैं आम तरीका बताऊँगा, क्योंकि उसकी ज़रूरत आपको फिर भी पड़ेगी। उसके बाद कटओवर वाली तकनीक पर आऊँगा, यह भी कि उसे ऐसे कैसे करें कि टीम आपसे नफ़रत न करने लगे।
टीमें नया सॉफ्टवेयर क्यों नहीं अपनातीं
मामला लगभग कभी सॉफ्टवेयर का नहीं होता।
लक्षण। कंपनी के सॉफ्टवेयर रोलआउट करते हुए दस साल में मुझे शायद ही कोई ऐसा यूज़र मिला जिसने नए टूल पर तकनीकी वजहों से एतराज़ किया हो। जो बार-बार मिला, वह था बदलाव का सीधा-सादा डर।
असली वजह। पुरानी स्प्रेडशीट भले धीमी हो और कॉपी-पेस्ट के सहारे टिकी हो, पर वह उनकी है। उन्हें पता है कि क्या कहाँ रखा है, वे उस पर तेज़ हैं। नया टूल, चाहे साफ़ तौर पर बेहतर हो, उन्हें दो हफ़्ते के लिए धीमा और नाकाबिल महसूस कराता है — और उस एहसास के लिए कोई अपनी मर्ज़ी से तैयार नहीं होता। McKinsey का बहुत उद्धृत अनुमान कहता है कि करीब 70% चेंज प्रोग्राम अपने लक्ष्य से चूक जाते हैं, और आम वजह होती है उन लोगों का विरोध जिन्हें उस बदलाव के साथ जीना है। हाल के जितने भी वर्कप्लेस सर्वे मैंने देखे, सब किसी न किसी रूप में यही कहते हैं: कर्मचारी पहले ही टूल्स के बोझ तले दबे महसूस करते हैं, और मान लेते हैं कि हर नए टूल का मतलब उनके लिए और काम है।
हल सॉफ्टवेयर में नहीं है — हल यह है कि रोलआउट को वही मानिए जो वह असल में है: एक चेंज मैनेजमेंट प्रोजेक्ट, जिसमें संयोग से टेक्नोलॉजी भी शामिल है। नीचे की हर बात इसी से निकलती है।
आम तरीका (यह पहले कीजिए)
आम सलाह आम इसलिए है क्योंकि वह काम करती है। इसे छोड़ दीजिए, तो कटओवर का कोई नुस्ख़ा आपको नहीं बचाएगा।
1. टीम को शुरू से जोड़िए
जो लोग रोज़ इस टूल में रहेंगे, उन्हें इसे गढ़ने में मदद करनी चाहिए। आगे चलकर सबसे ज़्यादा इस्तेमाल करने वाले दो-तीन लोगों को बनाने की प्रक्रिया में लाइए, उन्हें प्रोटोटाइप दिखाइए, चीज़ें तोड़ने दीजिए। जिन यूज़र्स ने टूल को आकार देने में मदद की, वे बाद में उसका बचाव करते हैं — और वही अपने आसपास के बाकी लोगों को सिखाते भी हैं।
यहीं अपना सॉफ्टवेयर खुद बनाना बाज़ार से तैयार टूल खरीदने पर भारी पड़ता है। जब कोई बदलाव माँगता है और उसी हफ़्ते उसे लाइव देखता है, तो उसे लगने लगता है कि टूल उसका अपना है। वेंडर का "यह रोडमैप में है" कहना ठीक इसका उल्टा करता है।
2. समझ में आने वाला टूल चुनिए
हर फालतू क्लिक आपको अपनाने की दर में नुकसान देता है। अगर रोज़ के सबसे बुनियादी काम के लिए भी टूल को मैनुअल चाहिए, तो रोलआउट पहले ही मुश्किल में है। मेरा पैमाना हमेशा सीधा रहा: नया यूज़र मुख्य काम पहली ही कोशिश में, बिना मदद के पूरा कर ले। अगर नहीं कर पाता, तो ट्रेनिंग ठीक करने से पहले टूल ठीक कीजिए।
3. फीचर्स नहीं, असली काम पर ट्रेनिंग दीजिए
सेटिंग्स पेज की सैर में किसी की दिलचस्पी नहीं होती। हर टीम को उनके असली काम पर ट्रेनिंग दीजिए: "ग्राहक की शिकायत ऐसे दर्ज होती है," "परचेज़ ऑर्डर ऐसे अप्रूव होता है।" असली डेटा और असली अपवाद मामले लीजिए। किसी के सचमुच के मंगलवार पर बना 30 मिनट का सेशन, सिस्टम के हर फीचर पर चलने वाले दो घंटे से बेहतर है।
4. शुरुआती जीत का जश्न मनाइए
वह पहला मौका खोजिए जहाँ नया टूल साफ़ तौर पर पुराने तरीके से आगे निकला — वह रिपोर्ट जिसमें पहले चार घंटे लगते थे और अब दस मिनट लगते हैं, इस तरह की कोई चीज़। सबको बताइए, और उसमें शामिल लोगों का नाम लीजिए। शुरुआती जीत बीच में अटके लोगों को सबूत देती है कि हिलना सुरक्षित है, और लीडरशिप को प्रोजेक्ट का साथ देते रहने की वजह देती है।
वह तकनीक जो सचमुच काम आई: पुराना सिस्टम हटा दीजिए
दस साल के रोलआउट ने मुझे एक असहज बात सिखाई: आप ऊपर के चारों कदम सही कर सकते हैं और फिर भी रोलआउट को मरते देख सकते हैं। सिर्फ़ एक वजह से।
लक्षण। जब भी हमने "ट्रांज़िशन पीरियड के दौरान" नया टूल पुराने के साथ-साथ चलाया, हर बार एक ही बात हुई: पहले हफ़्ते इस्तेमाल उछला, फिर सीधे पुरानी स्प्रेडशीट में वापस बह गया।
असली वजह। जब तक पुराना रास्ता मौजूद है, लोग पुराना रास्ता ही इस्तेमाल करते रहेंगे। ट्रांज़िशन पीरियड अपने आप कभी खत्म नहीं होता। मर्ज़ी पर छोड़ा गया अपनाना दरअसल एक धीमी "ना" है।
हल यह था कि समानांतर सिस्टम चलाना बंद कर दिया जाए। कटओवर वाले दिन पुरानी स्प्रेडशीट सिर्फ़-पढ़ने के मोड में चली गई और पुराना फ़ॉर्म हट गया। नया सॉफ्टवेयर काम पूरा करने का इकलौता रास्ता बन गया।
और हर बार यही हुआ: बदलें या न बदलें वाली बहस बस खत्म हो गई, और वही ऊर्जा सीधे नया टूल सीखने में लग गई। वे अटपटे दो हफ़्ते सचमुच पूरे हुए, क्योंकि पूरी टीम उनसे एक साथ गुज़री, बजाय उन्हें अनिश्चित काल तक टालने के। असली दिक्कतें कुछ ही दिनों में सामने आ गईं, क्योंकि सबको वे एक साथ मिलीं, और हमने उन्हें तब ठीक किया जब ध्यान अब भी बना हुआ था। और सारा डेटा आख़िरकार एक जगह रहने लगा।
यह दफ़्तर के सॉफ्टवेयर पर लागू की गई "नावें जला दो" वाली बात है। कहते हैं कि कोर्तेस ने अपने जहाज़ डुबा दिए थे ताकि पीछे लौटने का रास्ता ही न बचे। आपको इतना नाटकीय कुछ नहीं चाहिए — स्प्रेडशीट को सिर्फ़-पढ़ने के मोड में डाल देना ही काफ़ी है।
ऑटोमेशन वाला फ़ायदा
यही वह हिस्सा है जिसे अपनाने पर लिखे ज़्यादातर लेख छोड़ देते हैं, और हमारे लिए सबसे बड़ा फ़ायदा यही था।
जब कोई प्रोसेस चलाने का इकलौता रास्ता नया सॉफ्टवेयर रह गया, तो उस प्रोसेस का हर कदम एक सिस्टम को दिखने लगा — यानी हम उसे आख़िरकार ऑटोमेट कर सके। अप्रूवल खुद-ब-खुद आगे बढ़ने लगे। साप्ताहिक रिपोर्ट किसी की शुक्रवार की दोपहर खाना बंद कर बैठीं। पहले यह कुछ भी मुमकिन नहीं था, क्योंकि हर प्रोसेस का आधा हिस्सा इनबॉक्स और निजी स्प्रेडशीट में बिखरा रहता था, जहाँ किसी सिस्टम की नज़र नहीं पहुँचती थी।
अपनाना हमारे लिए कभी मंज़िल नहीं था। वह शर्त थी। असली फ़ायदा उसके बाद दिखता है, जब पूरी प्रोसेस एक ऐसे सिस्टम के भीतर बैठ जाती है जो सचमुच आपके नियंत्रण में है।
टीम को थकाए बिना ज़बरदस्ती कटओवर कैसे करें
साफ़ कर दूँ: पुराना सिस्टम हटाना चेंज मैनेजमेंट का काम छोड़ देने का बहाना नहीं है। उल्टे यह दाँव बढ़ा देता है, इसलिए तैयारी कमज़ोर नहीं, बेहतर होनी चाहिए। कुछ बार गलती करने के बाद हम इस तरीके पर टिके।
- जब तक नया टूल सचमुच तैयार न हो, कुछ मत छीनिए। आधे-अधूरे टूल पर ज़बरदस्ती कटओवर ऐसा भरोसा जलाता है जो आसानी से वापस नहीं मिलता। कुछ भी लॉक करने से पहले मुख्य काम मज़बूत होना चाहिए और असली यूज़र्स के साथ टेस्ट किया हुआ होना चाहिए।
- तारीख हफ़्तों पहले बताइए, और दोहराते रहिए। "15 तारीख को पुराना ट्रैकर सिर्फ़-पढ़ने के मोड में चला जाएगा।" कोई चौंकाने वाली बात नहीं। लोगों को डर चौंकने से लगता है; तारीख वह चीज़ है जिसकी वे तैयारी कर सकते हैं।
- डेटा खुद माइग्रेट कीजिए। यूज़र्स से उनके अपने रिकॉर्ड कभी मत ले जाने को कहिए। अगर पहले ही दिन उनका इतिहास नए सिस्टम में मौजूद है, तो सबसे बड़ा तार्किक एतराज़ आपने खुद हटा दिया।
- पुराना सिस्टम लॉक कीजिए, डिलीट मत कीजिए। यह जानकर लोग निश्चिंत होते हैं कि कुछ खोया नहीं, और इस बीच आपके पास ऑडिट ट्रेल भी बना रहता है।
- पहले हफ़्ते सपोर्ट में ज़रूरत से ज़्यादा लोग लगाइए। ऑफिस आवर्स, एक अलग चैट चैनल, कोई जो सचमुच फ्लोर पर घूम रहा हो। ज़्यादातर विरोध तब पिघल जाता है जब मदद पाँच मिनट के अंदर पहुँच जाती है।
- अपनी बात पर टिके रहिए। कोई न कोई "बस एक अपवाद" ज़रूर माँगेगा। वही पहला अपवाद नया पुराना सिस्टम बन जाता है। जवाब एक नरम पर पक्की "ना" होना चाहिए, साथ में उस असली कमी का असली हल जिसकी वजह से माँग उठी।
- लोग जो बताएँ, उसे तेज़ी से और दिखने वाले तरीके से ठीक कीजिए। कटओवर का पहला हफ़्ता ईमानदार फ़ीडबैक की बाढ़ लाता है। कुछ ही दिनों में सुधार लाइव करना ही शक करने वालों को अपनी तरफ़ करता है।
इसमें AgentUI कहाँ आता है
ज़बरदस्ती कटओवर तभी चलता है जब नया टूल सचमुच बेहतर हो, और जब आप उसे उतनी तेज़ी से सुधार सकें जितनी तेज़ी से फ़ीडबैक आता है। यही सबसे कठिन हिस्सा है — और ठीक यहीं AgentUI काम आता है।
AgentUI से बिज़नेस टीमें AI के साथ अपने हिसाब का सॉफ्टवेयर बना सकती हैं — पहला चलने वाला वर्ज़न करीब 30 मिनट में, और फिर यूज़र्स की प्रतिक्रिया के साथ उसे सुधारते रहना। यह रफ़्तार अपनाने का पूरा गणित बदल देती है: जब कोई सोमवार को कोई कमी बताता है और बुधवार तक उसे ठीक हुआ देखता है, तो टूल किसी भी ट्रेनिंग सेशन से तेज़ भरोसा कमा लेता है। AgentUI के साथ पहले दिन से व्यक्तिगत ऑनबोर्डिंग भी मिलती है — असली इंसानों की एक टीम जो रोलआउट की योजना बनाने और आपका डेटा माइग्रेट करने में मदद करती है, ताकि बदलाव का बोझ अकेले आप पर न रहे।
अपनी प्रक्रियाओं को एक ही प्लेटफ़ॉर्म पर लाना ही ऑटोमेशन वाला फ़ायदा भी खोलता है। जब काम बिखरी हुई स्प्रेडशीट्स की जगह एक नियंत्रित सिस्टम से बहने लगता है, तभी दोहराव वाले हिस्से आख़िरकार ऑटोमेट हो पाते हैं।
अक्सर पूछे जाने वाले सवाल
क्या यूज़र्स को ज़बरदस्ती बदलवाना मनोबल के लिए बुरा नहीं है?
मेरे अनुभव में, तय तारीख वाले साफ़ कटओवर से ज़्यादा बुरा मनोबल के लिए अनिश्चित खिंचाव होता है। मनोबल असल में तब टूटता है जब लोगों को ऐसे टूल पर धकेल दिया जाए जो चलता ही नहीं, न सपोर्ट हो और न कोई सुनने वाला। अगर टूल तैयार है, सपोर्ट मौजूद है, और फ़ीडबैक से दिखने वाले सुधार होते हैं, तो ज़्यादातर टीमों को राहत महसूस होती है — फ़ैसला हो गया, और सब एक साथ आगे बढ़ गए।
अगर मेरी टीम सचमुच नए टूल में अपना काम नहीं कर पा रही तो?
तो आपने कटओवर बहुत जल्दी कर दिया। एक्सेस वापस दीजिए, अपने पायलट यूज़र्स के साथ कमियाँ ठीक कीजिए, और नई तारीख तय कीजिए। तकनीक यह है कि "नया सिस्टम तैयार हो जाने पर पुराना हटा दीजिए," न कि "पुराना हटा दीजिए और भगवान भरोसे छोड़ दीजिए।"
पुराना और नया सिस्टम कितने समय साथ-साथ चलने चाहिए?
हो सके तो कुछ दिन। समानांतर चलने की छोटी खिड़की सिर्फ़ डेटा जाँचने के लिए रखिए, उसकी खत्म होने की तारीख सबको बता दीजिए, और उस पर टिके रहिए। जो समानांतर दौर आरामदायक हो जाता है, वह अक्सर स्थायी बन जाता है।
कैसे नापूँ कि अपनाना सचमुच हुआ या नहीं?
तीन चीज़ें देखिए: सक्रिय इस्तेमाल (क्या सभी इच्छित यूज़र्स हर हफ़्ते टूल में हैं?), प्रोसेस का पूरा होना (क्या काम शुरू से आख़िर तक इसी से बह रहा है?), और छिपे हुए सिस्टम (क्या चुपचाप नई स्प्रेडशीट्स फिर उग रही हैं?)। यही तीसरी चीज़ वह शुरुआती चेतावनी है जिसे जाँचना ज़्यादातर टीमें भूल जाती हैं।
जिस सॉफ्टवेयर पर स्विच करना बने, उसे बनाने में कितना वक़्त लगता है?
AgentUI के साथ पहला चलने वाला वर्ज़न आमतौर पर करीब 30 मिनट में बनता है, और प्रोडक्शन के लिए तैयार सॉफ्टवेयर करीब एक हफ़्ते में। इसमें आपके पायलट यूज़र्स के साथ वे दौर भी शामिल हैं जो भरोसे के साथ कटओवर करना मुमकिन बनाते हैं।
क्या आप ऐसा सॉफ्टवेयर बनाने के लिए तैयार हैं जिसे आपकी टीम सचमुच इस्तेमाल करे, और स्प्रेडशीट को हमेशा के लिए विदा कर दे?
AgentUI मुफ़्त आज़माएँ — मिनटों में अपनी टीम का पहला सॉफ्टवेयर बनाइए।