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

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

सफ़ाई माइग्रेशन से पहले क्यों होनी चाहिए, बाद में नहीं

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

बिना साफ़ किया डेटा आम तौर पर रुकी हुई सिस्टम परियोजनाओं का एक बार-बार सामने आने वाला कारण है, और हमने इसे बाक़ी कारणों के साथ ERP परियोजनाएँ क्यों विफल होती हैं और अपनी परियोजना को सफल कैसे बनाएँ में समझाया है। व्यावहारिक निष्कर्ष यह है कि सफ़ाई तब सबसे सस्ती होती है जब डेटा एक स्थिर फ़ाइल में पड़ा हो, और तब सबसे महँगी जब वह एक चालू सिस्टम में रहने लगे।

लगभग हर शीट में मौजूद पाँच ख़ामियाँ

ये कोई अनोखी ग़लतियाँ नहीं हैं; ये एक ऐसे टूल का स्वाभाविक नतीजा हैं जो हर चीज़ की इजाज़त देता है। इनमें से ज़्यादातर आपको अपनी ही फ़ाइल में मिलेंगी:

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

एकमात्र नियम: सेल के बाहर का हर अर्थ एक फ़ील्ड बनना चाहिए

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

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

Origami का नज़रिया

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

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

सफ़ाई का एक व्यावहारिक क्रम

हर फ़ाइल को पूरी तरह साफ़ करना कभी न ख़त्म होने वाली परियोजना है। ऐसे क्रम में काम करें जो कुछ ही दिनों में आपको ले जाने लायक़ कुछ दे दे:

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

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

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

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

स्रोत