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

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

प्रतिरोध ज़िद नहीं, जोखिम का हिसाब है

पहले सप्ताह में सबसे पहले आपका सामना टीम की हिचकिचाहट से होता है। आम ग़लती यह है कि मालिक उस हिचकिचाहट को बदलाव का विरोध या आलस समझ लेता है और उसका जवाब दबाव से देता है। आम तौर पर यह दोनों में से कुछ नहीं होता।

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

यह तब और बढ़ जाती है जब पुरानी फ़ाइल का मालिक कोई ऐसा व्यक्ति हो जिसकी कंपनी में हैसियत उसी फ़ाइल को जानने पर बनी हो। जो किसी फ़ाइल का एकमात्र संदर्भ रहा हो, उसे डर हो सकता है कि सिस्टम उसकी भूमिका को बेकार कर देगा। उस डर को नज़रअंदाज़ करने से वह मिटता नहीं; वह दब कर भीतर चला जाता है। उससे सीधे निपटना बेहतर काम करता है: उस व्यक्ति को नई व्यवस्था में अपने क्षेत्र की डेटा गुणवत्ता के मालिक के रूप में एक घोषित भूमिका दें, ताकि वह फ़ाइल के रखवाले से डेटा के ही संदर्भ में बदल जाए।

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

पुरानी फ़ाइल की ओर चुपचाप वापसी

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

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

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

वे कमियाँ जो स्थानांतरण के बाद सामने आती हैं, पहले नहीं

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

इस चरण में आम तौर पर जो सामने आता है:

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

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

एक बार दिया गया प्रशिक्षण काफ़ी नहीं है

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

जो विकल्प काम करता है वह तीन सिद्धांतों पर टिका है:

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

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

Origami का नज़रिया

हम लॉन्च के दिन को परियोजना का अंत नहीं, उसका मध्य बिंदु मानते हैं। कोई सिस्टम कंपनी में सिर्फ़ काम करने से नहीं जमता; वह तब जमता है जब वह दिन का काम निपटाने का सबसे छोटा रास्ता बन जाता है। हर वह दिन जब पुराना रास्ता नए से तेज़ बना रहता है, एक ऐसा दिन है जो चुपचाप परियोजना के ख़िलाफ़ काम कर रहा है।

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

तीस दिन की योजना

यह एक ऐसी योजना है जिसे आप लिखे अनुसार चला सकते हैं, और इसकी सबसे अहम विशेषता यह है कि हर चरण का एक घोषित अंत है:

  • दिन 1-7: सीमित समानांतर संचालन। काम सिस्टम और पुरानी फ़ाइल दोनों में केवल एक कारण से दर्ज किया जाता है — तुलना। सप्ताह के अंत में एक छोटा नमूना लें, दोनों आँकड़ों की तुलना करें, और हर अंतर को उसके आकार से नहीं बल्कि उसके कारण से दर्ज करें।
  • दिन 8: पुरानी फ़ाइल केवल-पढ़ने योग्य हो जाती है। यह योजना का सबसे महत्वपूर्ण कदम है। फ़ाइल देखने के लिए उपलब्ध रहती है और कोई उसमें नहीं लिखता। बिना घोषित समापन तिथि के समानांतर संचालन अनिश्चित काल तक चलता रहता है, और यह हमेशा पुरानी फ़ाइल की जीत के साथ ख़त्म होता है क्योंकि वह आसान है।
  • दिन 8-14: दूसरा प्रशिक्षण और कमियों को बंद करना। हर टीम के लिए उन सवालों पर एक छोटा सत्र जो वास्तव में उठे, और कमियों की सूची के शीर्ष पाँच बिंदुओं को बंद करना।
  • दिन 15-21: उपयोग मापें। देखें कि कौन वास्तव में सिस्टम इस्तेमाल कर रहा है और कौन नहीं, और देर से दर्ज हुए हर लेन-देन के लिए पूछें कि क्यों। जो आप सीखते हैं वह रास्ते की स्पष्टता के बारे में एक संकेत है, व्यक्तिगत अनुशासन के बारे में नहीं।
  • दिन 22-30: स्थिर करें और समीक्षा करें। बाक़ी टिप्पणियाँ बंद करें, केवल सिस्टम से पहली मासिक रिपोर्ट तैयार करें, और टीम प्रमुखों के साथ आधा घंटा बैठकर पहचानें कि अब भी सिस्टम के बाहर क्या हो रहा है और क्यों।

सफलता का ईमानदार पैमाना सर्वेक्षण में टीम की संतुष्टि या इस्तेमाल हो रही स्क्रीनों की संख्या नहीं है। यह एक अकेला क्षण है: कोई बिना कहे पुरानी फ़ाइल खोलना बंद कर देता है। उस समय सिस्टम वह परियोजना नहीं रह जाता जिसे आप संभाल रहे हैं — वह कंपनी के काम करने का तरीका बन जाता है।

शृंखला का समापन

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

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

स्रोत