पहले क्या माइग्रेट करें? डेटा माइग्रेशन का ऐसा क्रम जो कारोबार को चलता रखे

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

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

एक ही बार में सब कुछ ले जाना क्यों काम नहीं करता

यह सोच समझ में आती है: सप्ताहांत में सब कुछ ले जाओ, रविवार को नए सिस्टम पर काम शुरू करो, बस हो गया। यह परिदृश्य आम तौर पर तीन ऐसे कारणों से विफल होता है जिनका सिस्टम की गुणवत्ता से कोई लेना-देना नहीं है।

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

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

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

लेन-देन से पहले मास्टर डेटा: वह नियम जिस पर पूरा क्रम टिका है

आपका डेटा दो तरह का होता है। मास्टर डेटा: ग्राहक, आपूर्तिकर्ता, आइटम या सेवाएँ, कर्मचारी, खातों का चार्ट। और लेन-देन डेटा: इनवॉइस, ऑर्डर, खरीद आदेश, स्टॉक की आवाजाही, प्राप्तियाँ।

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

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

व्यवहार में क्रम इस तरह चलता है:

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

ऐतिहासिक आर्काइव: वह सवाल जो आपके हफ़्ते बचाता है

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

अगर जवाब है हमें इसकी ज़रूरत चीज़ें देखने के लिए या किसी कानूनी समीक्षा के लिए है, तो आर्काइव जैसा है वैसा ही यह काम पहले से कर रहा है — अपने मूल प्रारूप में, एक ज्ञात और खोजने योग्य जगह पर सुरक्षित। आपका कानूनी दायित्व इनवॉइस और रिकॉर्ड को सुरक्षित रखना और माँगे जाने पर उन्हें प्रस्तुत कर पाना है, जैसा कि ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA) ने निर्धारित किया है, न कि यह कि वे सब खास तौर पर नए सिस्टम के भीतर ही हों।

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

कामकाजी नियम: वह इतिहास ले जाइए जिस पर आप कोई निर्णय लेंगे, और बाकी को आर्काइव के रूप में रखिए। आर्काइव के माइग्रेशन को लाइव होने की पूर्व-शर्त मत बनाइए — यह बाद में बिना दबाव के किया जा सकता है, जबकि लाइव होना अनिश्चित काल तक टाला नहीं जा सकता।

समानांतर संचालन: ज़रूरी, और खुला छोड़ने पर खतरनाक

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

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

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

Origami का दृष्टिकोण

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

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

वह संकेत जो बताता है कि बदलाव सफल रहा

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

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

आगे के भागों में

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

स्रोत

• ज़कात, कर और सीमा शुल्क प्राधिकरण (ZATCA) — ई-इनवॉइसिंग की आवश्यकताएँ तथा इनवॉइस और दस्तावेज़ों को सुरक्षित रखना और प्रस्तुत करना।
• सऊदी डेटा और कृत्रिम बुद्धिमत्ता प्राधिकरण (SDAIA) — व्यक्तिगत डेटा संरक्षण कानून (PDPL) और स्थानांतरण तथा भंडारण के दौरान व्यक्तिगत डेटा के प्रबंधन पर नियंत्रण।
• मानव संसाधन और सामाजिक विकास मंत्रालय — कर्मचारियों के रिकॉर्ड और डेटा को सुरक्षित रखने की आवश्यकताएँ।
• वाणिज्य मंत्रालय — प्रतिष्ठानों की वाणिज्यिक बहियों और रिकॉर्ड को नियंत्रित करने वाले प्रावधान।
• राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) — डेटा सुरक्षा और बैकअप से संबंधित नियंत्रण।