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

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

फ़ाइलों की संख्या बढ़ती ही क्यों है

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

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

तीन सवाल जो असली सिस्टम को सामने लाते हैं

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

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

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

सूची आमतौर पर क्या सामने लाती है

सूची सिर्फ़ एक फ़ेहरिस्त नहीं देती; वह उन समस्याओं को भी समझाती है जिनके साथ आप बिना किसी ज्ञात वजह के जी रहे थे। चार बार-बार मिलने वाली बातें:

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

Origami का नज़रिया

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

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

नतीजा: एक पन्ने की सूची

जो सूची एक पन्ना भी न दे, उस पर भरोसा नहीं किया जा सकता। नतीजे को एक ही तालिका बनाएँ जो एक पन्ने से लंबी न हो, और हर अहम फ़ाइल के लिए सिर्फ़ चार कॉलम हों:

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

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

आने वाले भागों में

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

स्रोत