SAP डेटा माइग्रेशन फ़ेल क्यों होता है और इसे कैसे ठीक करें

SAP डेटा माइग्रेशन सबसे ज़्यादा एक ही वजह से फ़ेल होता है: प्लान इस पर बना होता है कि बिज़नेस को अपना डेटा कैसा दिखता लगता है, इस पर नहीं कि एक्सट्रैक्ट क्या दिखाता है। यह गाइड S/4HANA प्रोग्राम पर काम कर रहे प्रोग्राम डायरेक्टर, डेटा लीड और फ़ाइनेंस लीडर के लिए है। इसमें बताया गया है कि माइग्रेशन क्यों टूटते हैं, ज़्यादातर कटओवर नाकामियों के पीछे की पाँच गलतियाँ क्या हैं, कॉपी करने लायक मॉक-लोड प्लान कैसा हो और 2026 में कौन-सा SAP टूल किस काम के लिए ठीक है। इस हफ़्ते आप एक ही काम करें, तो अपने कस्टमर, वेंडर और मटेरियल मास्टर का पूरा एक्सट्रैक्ट लीजिए और रिकॉर्ड खुद गिनिए।

एक मैन्युफ़ैक्चरिंग कंपनी ने अपने SAP इम्प्लीमेंटेशन पर 18 महीने और $4.5 मिलियन लगाए। लॉन्च का दिन आया। सब घबराए हुए थे, पर उत्साहित भी। फिर डेटा माइग्रेशन फ़ेल हो गया।

कुछ भी ठीक से नहीं चला। कस्टमर डेटा ग़ायब था। इन्वेंटरी के आँकड़े गलत थे। अकाउंटिंग बही बंद नहीं कर पाई। CEO आगबबूला थे।

यह सॉफ़्टवेयर की गलती नहीं थी और इम्प्लीमेंटेशन टीम की भी नहीं। नाकामी उस फ़ासले में थी जो बिज़नेस को अपना डेटा जैसा लगता था और वह असल में जैसा था, उसके बीच था।

SAP का डेटा मॉडल कोई फ़्लैट इम्पोर्ट नहीं है। रिकॉर्ड एक-दूसरे पर निर्भर होते हैं। मटेरियल मास्टर में एक सामान्य रिकॉर्ड (MARA), प्लांट डेटा (MARC), वैल्यूएशन डेटा (MBEW) और, जहाँ MRP एरिया इस्तेमाल होते हैं, वहाँ MRP एरिया डेटा (MDMA) होता है। निर्भर व्यू के बिना सिर्फ़ हेडर लोड कर दें, तो मटेरियल मौजूद तो रहता है, पर किसी ट्रांज़ैक्शन में इस्तेमाल नहीं हो सकता।

S/4HANA अपना एक नियम जोड़ता है। कस्टमर और सप्लायर बिज़नेस पार्टनर होते हैं। पुराना कस्टमर कस्टमर रोल वाला बिज़नेस पार्टनर बनता है, और वेंडर सप्लायर रोल वाला। क्रेडिट लिमिट, बैंक विवरण और टैक्स नंबर उसी बिज़नेस पार्टनर से जुड़े होते हैं। जिस रिकॉर्ड को पुराना सिस्टम खामियों के साथ बर्दाश्त कर लेता था, वह यहाँ वैलिडेशन में फ़ेल हो जाएगा।

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

बिज़नेस का अनुमानपूरा एक्सट्रैक्ट

स्कोप में मटेरियल रिकॉर्ड500,000+450,000 · +900%

बिज़नेस का अनुमान50,000

पूरा एक्सट्रैक्ट500,000

• हर वेरिएंट और प्लांट-विशिष्ट रिकॉर्ड गिना गया
• अनुमान पर बना प्लान इसके सामने नहीं टिकता

यह डेटा माइग्रेशन की समस्या नहीं थी। यह स्कोपिंग की समस्या थी जो माइग्रेशन की समस्या बन गई।

प्रोजेक्ट की शुरुआत में होने वाला डेटा क्वालिटी असेसमेंट आम तौर पर डेटा का वर्णन होता है, उसकी जाँच नहीं। फ़ाइनेंस डायरेक्टर कहते हैं कि वेंडर मास्टर ठीक से मेंटेन है। वेयरहाउस मैनेजर कहते हैं कि मटेरियल ज़्यादातर साफ़ हैं। ये धारणाएँ हैं।

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

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

1. माइग्रेशन को देर से होने वाला तकनीकी काम मानना

माइग्रेशन SAP Activate के हर फ़ेज़ का हिस्सा है। Explore स्कोप तय करता है: ऑब्जेक्ट, सोर्स सिस्टम, वॉल्यूम और क्वालिटी। Realize टेम्पलेट बनाता है और मॉक लोड चलाता है। Deploy फ़ाइनल रिहर्सल और कटओवर लोड चलाता है। Run लाइव डेटा पर पहली अवधि के क्लोज़ का रिकंसिलिएशन करता है।

जो प्रोजेक्ट माइग्रेशन का काम Deploy में शुरू करते हैं, वे उसे महीनों देर से शुरू करते हैं। जो क्वालिटी की समस्याएँ Realize में सुलझ जानी चाहिए थीं, वे कटओवर से कुछ हफ़्ते पहले पहले मॉक में सामने आती हैं। मेरी SAP टाइमलाइन प्लानिंग गाइड दिखाती है कि पूरे प्लान में माइग्रेशन कहाँ बैठता है।

2. बिज़नेस की भागीदारी बहुत कम

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

जो प्रोग्राम माइग्रेशन में सिर्फ़ तकनीकी लोग लगाते हैं और बिज़नेस को अंत में साइन-ऑफ़ भर मानते हैं, वे ऐसा डेटा बनाते हैं जो लोड तो हो जाता है। कारोबारी नज़र से वह गलत होता है।

3. बहुत कम मॉक लोड प्लान करना

ठीक से चलाए गए SAP डेटा माइग्रेशन में कटओवर से पहले कम से कम तीन मॉक लोड चाहिए, और जटिल प्रोग्राम में ज़्यादा। जो प्रोजेक्ट एक या दो प्लान करते हैं, वे साफ़ डेटा और साफ़ मैपिंग की उम्मीद पर चल रहे हैं। ऐसा कम ही होता है। ज़्यादा साइकल किसी बिगड़े माइग्रेशन की निशानी नहीं हैं। वे ठीक से प्लान किए गए माइग्रेशन की निशानी हैं।

4. ट्रायल लोड का रिकंसिलिएशन न करना

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

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

5. ऐसा कटओवर लोड जो रिहर्सल से अलग हो

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

सबसे कम परखा हुआ हिस्सा आम तौर पर डेल्टा होता है। फ़ाइनल मॉक और कटओवर के बीच बिज़नेस वेंडर जोड़ता रहता है, ऑर्डर बदलता रहता है और स्टॉक हिलाता रहता है। डेटा फ़्रीज़ की तारीख़ तय कीजिए और डेल्टा लोड का रिहर्सल फ़ाइनल मॉक के हिस्से के रूप में कीजिए।

इस साइकल ढाँचे को शुरुआती बिंदु मानिए। हर साइकल का एक उद्देश्य और एक एग्ज़िट क्राइटेरिया होता है, और रिकंसिलिएशन पर साइन-ऑफ़ होने तक वह पूरा नहीं माना जाता।

साइकल	उद्देश्य	एग्ज़िट क्राइटेरिया	ज़िम्मेदार
मॉक 1	स्ट्रक्चर: हर ऑब्जेक्ट निर्भरता के क्रम में लोड हो	हर ऑब्जेक्ट के लिए मैपिंग की कमियाँ और फ़ॉर्मेट की त्रुटियाँ दर्ज	डेटा माइग्रेशन लीड
मॉक 2	क्वालिटी: मैपिंग के फ़िक्स परखें और डेटा की समस्याएँ उजागर करें	हर ऑब्जेक्ट पर त्रुटि दर घट रही हो और सफ़ाई के फ़ैसले दर्ज हों	डेटा स्टीवर्ड
मॉक 3	बिज़नेस नियम: अपवाद और किनारे के मामले	स्टीवर्ड हर डोमेन में रिकंसाइल किया गया सैंपल स्वीकार करें	डेटा स्टीवर्ड
मॉक 4	पूरे प्रोडक्शन आकार पर वॉल्यूम और टाइमिंग	पूरा लोड कटओवर विंडो के भीतर पूरा हो	कटओवर मैनेजर
फ़ाइनल रिहर्सल	कटओवर का ड्रेस रिहर्सल, डेल्टा और फ़्रीज़ समेत	गिनती और वित्तीय कुल रिकंसाइल होकर साइन-ऑफ़	फ़ाइनेंशियल कंट्रोलर और डेटा लीड

उस प्लान के आसपास पाँच चीज़ें फ़र्क़ डालती हैं:

1. Prepare में पूरा एक्सट्रैक्ट। सब कुछ, सैंपल नहीं। संपूर्णता, सटीकता, एकरूपता और डुप्लिकेट की प्रोफ़ाइलिंग कीजिए, फिर नतीजों से सफ़ाई और टाइमलाइन का आकार तय कीजिए।
2. ऑब्जेक्ट-दर-ऑब्जेक्ट मैपिंग। हर ऑब्जेक्ट (बिज़नेस पार्टनर, मटेरियल, ओपन परचेज़ और सेल्स ऑर्डर, ओपन आइटम, स्टॉक, फ़िक्स्ड एसेट) के लिए सोर्स-से-टारगेट फ़ील्ड, ट्रांसफ़ॉर्मेशन नियम, वैलिडेशन जाँचें और अपवाद के नियम दर्ज कीजिए।
3. नामित डेटा स्टीवर्ड। कस्टमर और वेंडर का वित्तीय डेटा फ़ाइनेंस के पास है। मटेरियल मास्टर प्रोक्योरमेंट के पास। स्टॉक वेयरहाउस के पास। हर स्टीवर्ड हर साइकल के बाद अपने डोमेन पर साइन-ऑफ़ करता है।
4. रिकंसिलिएशन पहले से तय। पहले मॉक से पहले ही तय कर लीजिए कि कौन-सी गिनती और कुल यह साबित करेंगे कि लोड सही है, ताकि कटओवर पर कोई इस पर बहस न करे।
5. लिखित कटओवर क्रम। फ़्रीज़, एक्सट्रैक्ट, ट्रांसफ़ॉर्म, लोड, वैलिडेट, बिज़नेस साइन-ऑफ़, go/no-go। वही क्रम जो फ़ाइनल रिहर्सल में था।

नए S/4HANA इम्प्लीमेंटेशन के लिए SAP S/4HANA Migration Cockpit शुरुआती लोड के लिए SAP का अनुशंसित टूल है। S/4HANA 2020 से यह Fiori ऐप Migrate Your Data के रूप में चलता है। ट्रांज़ैक्शन LTMC डिप्रिकेटेड है, और मौजूदा LTMC प्रोजेक्ट सिर्फ़ देखे जा सकते हैं। ऐप दो तरीक़े देता है: स्टेजिंग टेबल से डेटा माइग्रेट करना (जो फ़ाइलों से या आपके अपने टूल्स से भरी जाती हैं) और किसी SAP सोर्स सिस्टम से सीधे डेटा माइग्रेट करना। on-premise और private cloud की टीमें स्टैंडर्ड ऑब्जेक्ट में बदलाव करने या अपने ऑब्जेक्ट बनाने के लिए ट्रांज़ैक्शन LTMOM, यानी माइग्रेशन ऑब्जेक्ट मॉडलर, इस्तेमाल करती हैं। कॉकपिट शुरुआती लोड के लिए बना है, आवर्ती इंटरफ़ेस या मास चेंज के लिए नहीं।

SAP Data Services SAP का ETL प्लेटफ़ॉर्म है। इसे तब इस्तेमाल कीजिए जब वॉल्यूम बहुत ज़्यादा हों, ट्रांसफ़ॉर्मेशन लॉजिक भारी हो, कई सोर्स सिस्टम हों, या आप ऐसा दोबारा इस्तेमाल होने वाला डेटा क्वालिटी फ़्रेमवर्क चाहते हों जो प्रोजेक्ट के बाद भी चले।

थर्ड-पार्टी ETL टूल्स जैसे Informatica, Talend या Microsoft SSIS वहाँ ठीक बैठते हैं जहाँ संगठन के पास पहले से वे हों और उन्हें चलाने के स्किल भी।

SAP Datasphere, जो अब SAP Business Data Cloud का हिस्सा है, माइग्रेशन टूल नहीं है। उसकी जगह go-live के बाद की एनालिटिक्स लेयर है। यह तब मायने रखता है जब आप इतिहास को पुराने सिस्टम में छोड़ दें और फिर भी उस पर रिपोर्ट करनी हो।

ज़्यादातर स्टैंडर्ड इम्प्लीमेंटेशन में Migration Cockpit अधिकांश ऑब्जेक्ट सँभाल लेता है। भारी वॉल्यूम, बहुत कस्टमाइज़ किए गए पुराने सिस्टम या असामान्य सोर्स स्ट्रक्चर में आम तौर पर उसके साथ Data Services या कोई ETL टूल चाहिए। ECC से कन्वर्ज़न एक अलग कवायद है, जो मेरी ECC से S/4HANA माइग्रेशन गाइड में है।

SAP डेटा माइग्रेशन क्या है?

SAP डेटा माइग्रेशन का मतलब है इम्प्लीमेंटेशन या कन्वर्ज़न के हिस्से के रूप में पुराने सिस्टम से डेटा निकालना, उसे SAP के ढाँचों और नियमों के अनुकूल बनाना और SAP में लोड करना। आम ऑब्जेक्ट हैं बिज़नेस पार्टनर (कस्टमर और सप्लायर), प्लांट डेटा के साथ मटेरियल, ओपन परचेज़ और सेल्स ऑर्डर, स्टॉक बैलेंस, वित्तीय ओपन आइटम और फ़िक्स्ड एसेट। यह मुश्किल इसलिए है कि SAP निर्भरताएँ और वैलिडेशन नियम लागू करता है, जो पुराने सिस्टम अक्सर नहीं करते थे।

SAP डेटा माइग्रेशन के मुख्य तरीक़े क्या हैं?

नया इम्प्लीमेंटेशन (greenfield) चुने हुए मास्टर डेटा और ओपन आइटम को नए S/4HANA सिस्टम में लोड करता है और इतिहास पुराने सिस्टम या आर्काइव में छोड़ देता है। सिस्टम कन्वर्ज़न (brownfield) मौजूदा ECC सिस्टम और उसके इतिहास को वहीं का वहीं कन्वर्ट करता है। Selective data transition दोनों के बीच बैठता है, और चुनी हुई कंपनी कोड, ऑब्जेक्ट या समय-खंड ले जाता है। सही चुनाव डेटा क्वालिटी, इतिहास की ज़रूरत और पुराने प्रोसेस में से आप कितना रखना चाहते हैं, इस पर निर्भर करता है।

SAP Migration Cockpit क्या है और इसे कब इस्तेमाल करना चाहिए?

SAP S/4HANA Migration Cockpit सभी एडिशन में S/4HANA में शुरुआती डेटा लोड के लिए SAP का अनुशंसित टूल है। S/4HANA 2020 से यह Fiori ऐप Migrate Your Data के रूप में चलता है। ट्रांज़ैक्शन LTMC डिप्रिकेटेड है। यह पहले से परिभाषित माइग्रेशन ऑब्जेक्ट देता है, पोस्ट करने से पहले डेटा वैलिडेट करता है और त्रुटियाँ फ़ील्ड स्तर पर रिपोर्ट करता है। स्टैंडर्ड ऑब्जेक्ट और सामान्य वॉल्यूम के लिए इसे इस्तेमाल कीजिए। जब वॉल्यूम, ट्रांसफ़ॉर्मेशन लॉजिक या सोर्स स्ट्रक्चर टेम्पलेट की क्षमता से आगे निकल जाएँ, तो SAP Data Services या कोई दूसरा ETL टूल जोड़िए।

SAP डेटा माइग्रेशन में कितने मॉक लोड प्लान करने चाहिए?

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

S/4HANA में कस्टमर और वेंडर कैसे माइग्रेट करें?

बिज़नेस पार्टनर के रूप में। S/4HANA में कस्टमर और सप्लायर का मास्टर डेटा बिज़नेस पार्टनर के ज़रिए मेंटेन होता है, जिससे कस्टमर और सप्लायर रोल जुड़े होते हैं। नए इम्प्लीमेंटेशन में Migration Cockpit उन्हें अपने बिज़नेस पार्टनर ऑब्जेक्ट से लोड करता है। ECC से कन्वर्ज़न में कन्वर्ज़न से पहले customer-vendor integration सेट करना और चलाना पड़ता है।

कटओवर पर SAP डेटा माइग्रेशन फ़ेल होने की वजह क्या होती है?

पाँच पैटर्न ज़्यादातर कटओवर नाकामियों की वजह बनते हैं। बहुत कम मॉक लोड। ऐसा कटओवर क्रम जिसे शुरू से अंत तक कभी परखा नहीं गया। फ़ाइनल मॉक के बाद पुराने सिस्टम में बदलाव, और बिना परखा डेल्टा लोड। खुले छोड़े गए रिकंसिलिएशन के फ़ासले। स्पॉट चेक पर आधारित बिज़नेस साइन-ऑफ़। “पहले 1,000 रिकॉर्ड ठीक दिखे” वैलिडेशन नहीं है। go-live के लिए रिकंसाइल की गई गिनती और कुल चाहिए।