मैंने जितने भी ERP प्रोग्राम चलाए हैं, उन सबमें डेटा माइग्रेशन ही वह वर्कस्ट्रीम रहा है जिसे हर बार सबसे कम आँका गया। वेंडर डेटा के काम के लिए तीन महीने का स्कोप बनाता है। असल में छह से नौ महीने लगते हैं। कटओवर तक आधी टीम डुप्लिकेट से जूझ रही होती है और स्टीयरिंग कमेटी पूछ रही होती है कि किसी ने यह बात पहले क्यों नहीं उठाई।
मैंने यह एस्टिमेटर इसलिए बनाया कि यह बातचीत कुछ महीने पहले शुरू हो जाए। यह काम का आकार डेटा ऑब्जेक्ट, वॉल्यूम और टारगेट ERP के हिसाब से निकालता है, और आपको पर्सन-डे का अनुमान, लागत का दायरा और सुझाया गया माइग्रेशन तरीका देता है। यह वेंडर-निरपेक्ष है और SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite तथा Microsoft Dynamics 365 और AX पर लागू होता है।
नतीजा एक दायरे के रूप में आता है, एक अकेले आँकड़े के रूप में नहीं, क्योंकि सच्चाई भी एक दायरा ही है। नंबर को सबसे ज़्यादा हिलाने वाली चीज़ें हैं डेटा की क्वालिटी, सोर्स सिस्टम की संख्या और यह कि आप कितनी हिस्ट्री साथ ले जाना चाहते हैं।
अपना टारगेट ERP चुनिए। स्कोप में आने वाले डेटा ऑब्जेक्ट जोड़िए और हर एक के लिए अपेक्षित रिकॉर्ड वॉल्यूम डालिए। डेटा क्वालिटी का फ़्लैग ईमानदारी से सेट कीजिए। एस्टिमेटर ऑब्जेक्ट के हिसाब से प्रयास, कुल पर्सन-डे का दायरा, लागत का दायरा और सुझाया गया तरीका (Migration Cockpit, LSMW, कस्टम ETL या हाइब्रिड) लौटाता है।
सब कुछ आपके ब्राउज़र में चलता है। कहीं कुछ भेजा नहीं जाता। कुछ स्टोर नहीं होता। नतीजे को अपनी मान्यताओं पर परखने के लिए इनपुट जितनी बार चाहें बदलिए।
- कस्टमर मास्टर: सोल्ड-टू, शिप-टू, पेयर, बिल-टू संबंध, पार्टनर फ़ंक्शन
- वेंडर मास्टर: सप्लायर रिकॉर्ड, पेमेंट टर्म्स, विदहोल्डिंग टैक्स, बैंक विवरण
- मटेरियल मास्टर: बेसिक डेटा, प्लांट व्यू, सेल्स व्यू, MRP, अकाउंटिंग और कॉस्टिंग
- GL अकाउंट और चार्ट ऑफ़ अकाउंट्स: प्राइमरी और सेकेंडरी कॉस्ट, हायरार्की
- कॉस्ट सेंटर, प्रॉफ़िट सेंटर, इंटरनल ऑर्डर: कंट्रोलिंग मास्टर डेटा
- ओपन परचेज़ ऑर्डर: हेडर, आइटम, शेड्यूल लाइन, अकाउंट असाइनमेंट
- ओपन सेल्स ऑर्डर: हेडर, आइटम, कंडीशन, पार्टनर डेटा
- ओपन इनवॉइस (AP और AR): असाइनमेंट और क्लियरिंग नियमों के साथ ओपन आइटम
- इन्वेंटरी बैलेंस: स्टोरेज लोकेशन, बैच और स्पेशल स्टॉक के हिसाब से
- ऐतिहासिक वित्तीय ट्रांज़ैक्शन: पोस्टिंग, बैलेंस, साल के अंत का कैरी-फ़ॉरवर्ड
- एसेट मास्टर और डेप्रिसिएशन हिस्ट्री: एसेट क्लास और डेप्रिसिएशन एरिया के हिसाब से
- HR मास्टर डेटा: कर्मचारी, ऑर्ग यूनिट, पोज़ीशन, जहाँ SuccessFactors या HCM स्कोप में हो
अपने माइग्रेशन का विवरण दर्ज करें
* वाले फ़ील्ड भरना ज़रूरी है।
पैटर्न हमेशा एक जैसा रहता है। डिस्कवरी वर्कशॉप में होती है, जिनमें सिस्टम ओनर मौजूद होते हैं। वे कहते हैं कि डेटा “मोटे तौर पर साफ़” है। एस्टिमेट इसी बात पर बन जाता है। बिज़नेस केस में नंबर जाने से पहले कोई एक भी प्रोफ़ाइलिंग क्वेरी नहीं चलाता।
एक मैन्युफ़ैक्चरिंग क्लाइंट ने मुझसे कहा कि उनके पार्ट नंबर स्टैंडर्ड हैं। हमने डेटा निकाला तो 12 अलग-अलग फ़ॉर्मेट सक्रिय इस्तेमाल में मिले। एक और प्रोग्राम में कस्टमर नोट्स का सिस्टम ऑफ़ रिकॉर्ड एक कस्टम फ़ील्ड निकला जिसे किसी ने डॉक्यूमेंट नहीं किया था, और मैपिंग में वह छूट गया तो तीन साल की हिस्ट्री गायब हो गई। एक फ़ाइनेंस माइग्रेशन में, लेगेसी चार्ट ऑफ़ अकाउंट्स को समझने वाला अकेला व्यक्ति पाँच साल पहले रिटायर हो चुका था।
महँगा पल वह होता है जब ये दिक्कतें कटओवर रिहर्सल के दौरान मिलती हैं, प्लानिंग में नहीं। डिस्कवरी के दूसरे हफ़्ते में मिला डेटा क्वालिटी का फ़िक्स दिनों में निपट जाता है। वही फ़िक्स तीसरे मॉक कटओवर में मिले तो प्रोग्राम को हफ़्तों की कीमत चुकानी पड़ती है, कभी-कभी एक तिमाही की। तब तक तारीखें सार्वजनिक हो चुकी होती हैं, चेंज नेटवर्क जुट चुका होता है, और go-live टालना बोर्ड की बातचीत बन जाता है।
सही कदम है एस्टिमेट पर दस्तख़त से पहले डेटा की प्रोफ़ाइलिंग करना। सोर्स पर असली क्वेरी चलाइए। डुप्लिकेट गिनिए। नल गिनिए। वे रिकॉर्ड गिनिए जो आज आपके टारगेट सिस्टम के अनिवार्य फ़ील्ड नियमों पर फ़ेल होते हैं। एस्टिमेटर मानकर चलता है कि आप यह करेंगे। डेटा क्वालिटी का फ़्लैग ईमानदारी से सेट करने पर लागत का दायरा तेज़ी से चौड़ा हो जाता है।
सही तरीका टारगेट ERP, डेटा वॉल्यूम और इस पर निर्भर करता है कि आपको कितने सोर्स सिस्टम एक में समेटने हैं। नीचे मोटे तौर पर वह है जिसे मैं अपनाता हूँ, प्रयास सबसे सरल विकल्प के सापेक्ष।
| तरीका | किसके लिए सबसे अच्छा | प्रयास गुणक | टूल्स |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | ग्रीनफ़ील्ड S/4HANA, स्टैंडर्ड ऑब्जेक्ट, मध्यम वॉल्यूम | 1.0× | LTMC, LTMOM, SAP के दिए टेम्पलेट |
| LSMW | ECC, लेगेसी माइग्रेशन, वे प्रोग्राम जो अभी पुराने रिलीज़ पर हैं | 1.2× | LSMW, रिकॉर्ड किए BDC सेशन |
| SAP BTP / Integration Suite के ज़रिए कस्टम ETL | ज़्यादा वॉल्यूम, जटिल ट्रांसफ़ॉर्मेशन, कई सोर्स का कंसोलिडेशन | 2.0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| हाइब्रिड (Cockpit + ETL) | ब्राउनफ़ील्ड S/4HANA कन्वर्ज़न और सिलेक्टिव माइग्रेशन | 1.5× | मास्टर डेटा के लिए Cockpit, ट्रांज़ैक्शनल हिस्ट्री के लिए ETL |
| Oracle-नेटिव | Oracle Fusion Cloud और EBS टारगेट | 1.3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Dynamics 365 F&O और AX टारगेट | 1.3× | DMF एंटिटी, Azure Data Factory |
कस्टम ETL सबसे लचीला है और सबसे महँगा भी। आपको इसकी ज़रूरत है या नहीं, इसकी ईमानदार कसौटी यह है कि क्या आपका सोर्स डेटा टारगेट के स्टैंडर्ड नियमों को ऐसे तरीकों से तोड़ता है जिन्हें कोई टेम्पलेट रिकॉर्ड-दर-रिकॉर्ड लॉजिक के बिना ठीक नहीं कर सकता। अगर जवाब ना है, तो डिलीवर किए गए टूल्स के साथ ही रहिए।
- SAP S/4HANA (ग्रीनफ़ील्ड, ब्राउनफ़ील्ड, सिलेक्टिव)
- SAP ECC (पैरेलल लैंडस्केप और देर से होने वाले माइग्रेशन के लिए अब भी प्रासंगिक)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- प्रोग्राम मैनेजर जो SI के कोई नंबर देने से पहले डेटा वर्कस्ट्रीम का आकार तय कर रहे हैं।
- डेटा माइग्रेशन लीड जो अपने अंदरूनी एस्टिमेट को एक स्वतंत्र बेसलाइन पर परख रहे हैं।
- CIO और CFO जो कई मिलियन डॉलर के इम्प्लीमेंटेशन बजट में डेटा की लाइन को जाँच रहे हैं।
- स्वतंत्र सलाहकार जो प्रपोज़ल या एश्योरेंस रिव्यू में ऐसे नंबर तैयार करते हैं जिनका बचाव किया जा सके।
- इन-हाउस ERP टीमें जो अलग स्कोपिंग एंगेजमेंट पर खर्च किए बिना बिज़नेस केस बना रही हैं।
- ऐसा नंबर जिसका बचाव हो सके, जल्दी। एक अकेले अंदाज़े की जगह ऑब्जेक्ट-दर-ऑब्जेक्ट पर्सन-डे एस्टिमेट।
- वेंडर-निरपेक्ष। SAP, Oracle और Microsoft प्रोग्राम के पैटर्न पर बना, किसी एक वेंडर की प्लेबुक से नहीं।
- तरीके की सिफ़ारिश। बताता है कि Migration Cockpit, LSMW, कस्टम ETL या हाइब्रिड में से सही शुरुआती बिंदु कौन-सा है।
- वॉल्यूम और क्वालिटी का ध्यान रखता है। डेटा क्वालिटी गिरने पर लागत का दायरा चौड़ा होता है, जैसा असली प्रोग्राम में होता है।
- मुफ़्त, सिर्फ़ ब्राउज़र में, साइन-अप नहीं। कुछ भी आपकी मशीन से बाहर नहीं जाता। जितनी बार चाहें रीफ़्रेश करके दोबारा शुरू कीजिए।
इस टूल के डेटा माइग्रेशन एस्टिमेट कितने सटीक हैं?
ये नंबर उन पैटर्न को दर्शाते हैं जो मैंने पिछले 25 साल में SAP, Oracle और Dynamics प्रोग्राम में देखे हैं। इन्हें प्लानिंग की बातचीत का आधार बनाने के लिए तैयार किया गया है, आपके असली डेटा पर प्रोफ़ाइलिंग की जगह लेने के लिए नहीं।
सटीकता को सबसे ज़्यादा प्रभावित करने वाली बात यह है कि आपने सोर्स पर प्रोफ़ाइलिंग क्वेरी चलाई हैं या नहीं। डेटा क्वालिटी के ईमानदार फ़्लैग पर बना लागत का दायरा टिकता है। वर्कशॉप के आशावाद पर बना दायरा नहीं टिकता। एस्टिमेटर के नतीजे को SI से बातचीत के लिए बेसलाइन नंबर बनाइए। अगर उनका एस्टिमेट काफ़ी कम है, तो पूछिए कि वे डेटा क्वालिटी की कौन-सी मान्यता ले रहे हैं और उसे कैसे जाँचा है।
क्या मुझे ऐतिहासिक वित्तीय ट्रांज़ैक्शन माइग्रेट करने चाहिए या सिर्फ़ ओपन आइटम?
ज़्यादातर प्रोग्राम में सही जवाब है ओपन आइटम और ओपनिंग बैलेंस, जबकि हिस्ट्री को लेगेसी सिस्टम में रीड-ओनली आर्काइव या रिपोर्टिंग लेयर के ज़रिए पढ़ने लायक रखा जाए। पूरी ट्रांज़ैक्शनल हिस्ट्री माइग्रेट करने से प्रयास कई गुना बढ़ता है, रिकंसिलिएशन धीमा होता है, और उसकी लागत शायद ही वसूल होती है।
अपवाद हैं विनियमित उद्योग, जहाँ वैधानिक रिटेंशन की वजह से हिस्ट्री का सिस्टम ऑफ़ रिकॉर्ड में रहना ज़रूरी है, या वे कारोबार जहाँ नए सिस्टम में साल-दर-साल की तुलना सचमुच संचालन की ज़रूरत है। दोनों स्थितियों में एस्टिमेटर का ऐतिहासिक डेटा वाला प्रयास गुणक ज़्यादा भारी काम को दर्शाता है।
यह टूल कौन-सा माइग्रेशन तरीका सुझाता है?
यह टारगेट ERP, ऑब्जेक्ट सेट और वॉल्यूम के आधार पर शुरुआती बिंदु चुनता है। स्टैंडर्ड ऑब्जेक्ट वाला ग्रीनफ़ील्ड S/4HANA आमतौर पर Migration Cockpit पर पहुँचता है। ब्राउनफ़ील्ड कन्वर्ज़न और सिलेक्टिव माइग्रेशन हाइब्रिड की ओर झुकते हैं। ज़्यादा वॉल्यूम, कई सोर्स सिस्टम या भारी ट्रांसफ़ॉर्मेशन होने पर सिफ़ारिश BTP पर कस्टम ETL की ओर, या Oracle और Microsoft की तरफ़ किसी बराबर के प्लेटफ़ॉर्म की ओर चली जाती है।
सिफ़ारिश एक शुरुआती बिंदु है। असली फ़ैसला आपके डेटा के सैंपल पर प्रूफ़-ऑफ़-कॉन्सेप्ट के बाद होता है, किसी कैलकुलेटर से नहीं। नतीजे को वह कार्यकारी परिकल्पना मानिए जिसे आप उस अभ्यास में अपने साथ ले जाते हैं।
क्या मैं प्लान को एक्सपोर्ट करके अपनी टीम के साथ साझा कर सकता हूँ?
कैलकुलेटर पूरी तरह ब्राउज़र में चलता है। आप नतीजे का स्क्रीनशॉट ले सकते हैं, या ऑब्जेक्ट-वार नंबर अपनी प्लानिंग स्प्रेडशीट में कॉपी कर सकते हैं। कोई अकाउंट नहीं है, PDF में एक्सपोर्ट करने का कोई फ़्लो नहीं है, और सर्वर पर कुछ स्टोर नहीं होता। यह जानबूझकर किया गया है। अगर आप नंबरों पर गहराई से बात करना चाहते हैं, तो 30 मिनट की कॉल बुक करें और स्क्रीनशॉट साथ लाएँ।
क्या यह कॉन्फ़िगरेशन और सिक्योरिटी जैसे नॉन-मास्टर डेटा को भी कवर करता है?
नहीं। एस्टिमेटर सिर्फ़ मास्टर डेटा और ट्रांज़ैक्शनल डेटा का स्कोप तय करता है। कॉन्फ़िगरेशन डेटा, सिक्योरिटी रोल, कस्टम डेवलपमेंट और इंटीग्रेशन ऑब्जेक्ट अलग वर्कस्ट्रीम में आते हैं, जिनके अपने प्रयास के कारक होते हैं, और उन्हें डेटा की लाइन में नहीं मिलाना चाहिए। सबको एक ही नंबर में डाल देना उन कारणों में से एक है जिनसे डेटा माइग्रेशन के एस्टिमेट प्लानिंग के चरण में ही बिगड़ जाते हैं।
यह मल्टी-रीजन और मल्टी-एंटिटी रोलआउट को कैसे संभालता है?
एस्टिमेटर एक अकेले माइग्रेशन इवेंट का आकार तय करता है। मल्टी-रीजन रोलआउट के लिए इसे हर वेव के लिए एक बार चलाइए और वेव जोड़ लीजिए, साथ में उन टेम्पलेट, मैपिंग और टूलिंग के लिए कटौती का एक कारक रखिए जिन्हें आप पहली वेव के बाद दोबारा इस्तेमाल करते हैं। मेरे अनुभव में दूसरी वेव की लागत पहली की लगभग 60 से 70 प्रतिशत होती है, तीसरी घटकर लगभग 50 प्रतिशत पर आती है, और वहाँ से स्थिर हो जाती है। स्थानीय वैधानिक डेटा ऑब्जेक्ट (टैक्स, पेरोल, बैंकिंग) आमतौर पर वह हिस्सा होते हैं जो साफ़ तरीके से दोबारा इस्तेमाल नहीं होता।
क्या यह टूल ECC से S/4HANA ब्राउनफ़ील्ड कन्वर्ज़न के लिए काम करता है?
हाँ, और यह उन ऑब्जेक्ट के कम प्रयास के लिए समायोजन करता है जो इन-प्लेस कन्वर्ट होते हैं, बनाम उनके लिए जिन्हें दोबारा मैपिंग चाहिए। ब्राउनफ़ील्ड कन्वर्ज़न में डेटा का प्रयास आमतौर पर बराबर के ग्रीनफ़ील्ड माइग्रेशन का 40 से 60 प्रतिशत बैठता है, क्योंकि कस्टमर, वेंडर, मटेरियल और चार्ट-ऑफ़-अकाउंट्स के ढाँचे बिना दोबारा एक्सट्रैक्ट किए आगे चले जाते हैं। बड़ा काम आमतौर पर बिज़नेस पार्टनर कन्वर्ज़न और ऐतिहासिक पोस्टिंग पर नए GL का असर होता है।
क्या यह कैलकुलेटर मुफ़्त है?
हाँ। न साइन-अप, न ईमेल गेट, न भुगतान। गणना आपके ब्राउज़र में चलती है और कुछ भी स्टोर या कहीं भेजा नहीं जाता। नंबर मिलने के बाद अगर आप डेटा माइग्रेशन का केस बनाने में मदद चाहते हैं, तो 30 मिनट की कॉल बुक करें।