SAP ECC से S/4HANA माइग्रेशन: मिडिल ईस्ट रिटेल केस स्टडी

यह मेरी सबसे पसंदीदा केस स्टडी है। फ़ैशन और कंज़्यूमर गुड्स का एक जाना-माना मिडिल ईस्ट रिटेलर SAP ECC 6.0 से S/4HANA पर गया। उसके लगभग 18,000 कर्मचारी थे, सात देशों में 1,200 से ज़्यादा आउटलेट थे और ई-कॉमर्स चैनल बढ़ रहा था। वह सालों से ECC चला रहा था, और उसके सिस्टम ऑब्जेक्ट के 44 प्रतिशत कस्टमाइज़ किए जा चुके थे। हमने चुनिंदा री-डिज़ाइन के साथ ब्राउनफ़ील्ड कन्वर्ज़न चुना। मंथ-एंड क्लोज़ वीकेंड तक खिंचने के बजाय लंच से पहले पूरा होने लगा, और कस्टम कोड लगभग आधा घट गया।

अगर आप बहुत कस्टमाइज़ किया हुआ ECC सिस्टम चलाते हैं और सोच रहे हैं कि उसमें से कितना आगे ले जाएँ, तो एक प्रोग्राम ने इस सवाल का जवाब इस तरह दिया।

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

मुझे एक सेशन याद है जिसमें सप्लाई चेन टीम थोड़ा हँसी जब उसने माना कि उसकी दर्जनों "क्रिटिकल" रिपोर्टें अब मुश्किल से छुई जाती हैं। उन्हें हटा देना व्यावहारिक भी था और अजीब ढंग से राहत देने वाला भी।

ट्रिगर ECC के मेनस्ट्रीम मेंटेनेंस का अंत था। एन्हांसमेंट पैकेज 6 से 8 पर SAP ERP 6.0 2027 के अंत में मेनस्ट्रीम मेंटेनेंस से बाहर हो जाता है (SAP News)। असली वजहें गहरी थीं। फ़ाइनेंस हर मंथ-एंड पर हाथ से एक्सट्रैक्ट चलाता था। स्टोर को स्टॉक की ऐसी विज़िबिलिटी चाहिए थी जो रात के बैच जॉब नहीं दे सकते थे। IT की ज़्यादातर मेहनत कस्टम कोड को ज़िंदा रखने में जा रही थी।

SAP Readiness Check ने वही पक्का किया जिसका हमें शक था: एक बहुत कस्टमाइज़ किया हुआ सिस्टम, जिसके आगे काफ़ी रेमेडिएशन का काम था। Simplification Item List ने दिखाया कि स्टैंडर्ड S/4HANA कहाँ पहले से वही कर देता है जो कस्टम ECC कोड कर रहा था। फ़ाइनेंस ने पाया कि सालों से सँभाली जा रही कुछ कस्टम रिपोर्टें अब ग़ैर-ज़रूरी थीं। उस मीटिंग में राहत साफ़ दिखी।

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

सीधा कन्वर्ज़नचुनिंदा री-डिज़ाइन के साथ ब्राउनफ़ील्डपूरा ग्रीनफ़ील्ड री-बिल्ड

रखी गई कॉन्फ़िगरेशनसीधा कन्वर्ज़नपूरी की पूरी, समस्याओं समेतचुनिंदा री-डिज़ाइन के साथ ब्राउनफ़ील्डजो ठोस थीपूरा ग्रीनफ़ील्ड री-बिल्डकुछ नहीं, एक दशक का काम फेंक दिया गया

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

इसका मतलबसीधा कन्वर्ज़नसमस्याएँ S/4HANA में चली जाती हैंचुनिंदा री-डिज़ाइन के साथ ब्राउनफ़ील्डजिसे साफ़ करना है उसे साफ़ करें, सिर्फ़ जो टूटा है उसे दोबारा बनाएँपूरा ग्रीनफ़ील्ड री-बिल्डहर चलता हुआ प्रोसेस शून्य से दोबारा बनाया गया

चुनौती	हमने क्या किया
44 प्रतिशत कस्टमाइज़ किए ऑब्जेक्ट	बिज़नेस और IT ने हर ऑब्जेक्ट पर मिलकर टैग लगाया: हटाएँ, बदलें या री-फ़िट करें; हर चरण के लिए क्वालिटी गेट
नाज़ुक इंटीग्रेशन	POS, WMS, फ़ाइनेंस, HR और वेंडर पोर्टल को कवर करने वाला रिग्रेशन प्लान; पॉइंट-टू-पॉइंट लिंक SAP Integration Suite पैटर्न पर ले गए
डेटा क्वालिटी	हर फ़ंक्शन के डेटा स्टीवर्ड, SLA के साथ; रोज़ डिफ़ेक्ट ट्रैकिंग; QA से पहले सफ़ाई पूरी
कई देशों में अपनाया जाना	भूमिका के हिसाब से जॉब गाइड, go-live के पास फ़्लोर-वॉक, असली काम से जुड़ी ट्रेनिंग

बड़े पैमाने पर कस्टम कोड

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

इंटीग्रेशन

ECC पॉइंट-ऑफ़-सेल (POS) सिस्टम, वेयरहाउस मैनेजमेंट सिस्टम (WMS), फ़ाइनेंस, HR और कई वेंडर पोर्टल से जुड़ा था। हमने इन सबके पार एक रिग्रेशन प्लान बनाया और हर अहम कॉन्फ़िगरेशन बदलाव के बाद टेस्ट किया, सिर्फ़ अंत में नहीं। रात के बैच जॉब S/4HANA में तेज़ी से पूरे होने थे, वरना वेयरहाउस की सुबह की रिपोर्टें तैयार नहीं होतीं।

डेटा क्वालिटी

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

अपनाया जाना

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

SAP Activate पर चरणबद्ध डिलीवरी। पहले कोर फ़ाइनेंस और सप्लाई चेन गए, HR और वेंडर पोर्टल बाद में, ताकि सपोर्ट टीमों पर कभी ज़्यादा बोझ न पड़े। हर एनवायरनमेंट का एक ही काम था। सैंडबॉक्स ने रास्ते को वैलिडेट किया और स्कोप लॉक किया। डेवलपमेंट ने ट्रांसपोर्ट को पुख़्ता किया। QA ने असली बिज़नेस वॉल्यूम चलाए और जॉब ट्यून किए। प्री-प्रोडक्शन असली ड्रेस रिहर्सल था। डिप्लॉयमेंट की तारीख़ें रिटेल के पीक और लो सीज़न से मिलाई गईं।

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

cutover रिहर्सल। हर टास्क को समय से नापा गया, छाँटा या मिलाया गया। अकेले ड्राई रन ने वे घंटे बचाए जो कोई स्प्रेडशीट कभी नहीं दिखाती। रिकवरी प्लान एक पन्ने के हैंडआउट पर थे, और लोगों ने कहा कि उस सीधी सूची ने किसी भी डैशबोर्ड से ज़्यादा तनाव घटाया। व्यापक रोलआउट से पहले एक स्टोर पायलट ने POS और WMS की स्थिरता साबित की।

Hypercare। IT और बिज़नेस के लिए साझा वॉर रूम, साफ़ SLA और रोज़ के एक्शन लॉग। वीकेंड शिफ़्ट बारी-बारी से लगाई गईं और सपोर्ट हैंडओवर मिनट-दर-मिनट स्क्रिप्ट किए गए। लोगों को आम तौर पर आँकड़े याद रहते हैं। मुझे सबसे ज़्यादा पहली शांत रात याद है।

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

कस्टम कोड। लगभग आधा घट गया, जिससे लंबे समय का सपोर्ट बोझ और हर भावी अपग्रेड पर रिग्रेशन का जोखिम घटा।

रिपोर्टिंग और यूज़र अनुभव। स्टोर मैनेजर पुरानी ट्रांज़ैक्शन स्क्रीन से SAP Fiori ऐप पर आ गए। ट्रेनिंग का समय घटा क्योंकि ऐप वैसे चलते थे जैसी लोगों को उम्मीद थी। एक मैनेजर ने इसे "ताज़गी भरा" कहा।

इंटीग्रेशन। POS, WMS और फ़ाइनेंस के कनेक्शन ज़्यादा स्थिर हो गए, और रात के जॉब जल्दी पूरे होने लगे।

सब कुछ बराबर नहीं उतरा। कुछ टीमों ने बेहतर रिपोर्टें मौजूद होने पर भी पुरानी रिपोर्टें पकड़े रखीं। कुछ को लगा कि वर्कशॉप बहुत लंबे थे और रिहर्सल दोहराव भरे। बाद में देखें तो वही क़दम हमारा सुरक्षा-जाल थे।

सबक	क्या हुआ	अगली बार मैं क्या करता
जल्दी तालमेल बिठाएँ	एक वर्कशॉप में स्टोर मैनेजरों ने कहा कि उनकी रिपोर्टिंग की ज़रूरतें फ़ाइनेंस से बहुत अलग हैं। यह जल्दी सामने आ गया और हमने समायोजन कर लिया; बाद में यह cutover पर फट पड़ता	डिज़ाइन शुरू होने से पहले तालमेल के संरचित सेशन रखता
कोड की समीक्षा पहले दिन से शुरू करें	कई ऑब्जेक्ट go-live के पास दबाव में दोबारा बनाने पड़े	हटाने, बदलने या री-फ़िट करने के फ़ैसले किकऑफ़ से ही लेता
डेटा को बिज़नेस का काम बनाएँ	डुप्लिकेट वेंडर रिकॉर्ड ने टेस्टिंग धीमी की	पहले ही हफ़्ते में SLA के साथ फ़ंक्शन-स्तर के डेटा स्टीवर्ड तय करता
जितना ज़रूरी लगे उससे ज़्यादा रिहर्सल करें	एक ड्राई रन में POS और WMS के बीच ऐसे सीक्वेंसिंग टकराव मिले जिनका किसी को अंदाज़ा नहीं था	अतिरिक्त रिहर्सल की योजना बनाता; go-live से पहले का आख़िरी रिहर्सल उबाऊ लगना चाहिए

अगर यही प्रोग्राम आज शुरू होता, तो तीन चीज़ें बदलतीं। इस स्थिति में ज़्यादातर कंपनियाँ अब ऑन-प्रिमाइस पर रुकने के बजाय RISE with SAP के तहत S/4HANA Cloud Private Edition को देखतीं। हटाने, बदलने या री-फ़िट करने के फ़ैसले SAP के क्लीन कोर लेवल A से D के सामने तौले जाते। बदलाव और डिप्लॉयमेंट की ट्रैकिंग SAP Cloud ALM में चलती, क्योंकि Solution Manager 7.2 2027 के अंत में मेनस्ट्रीम मेंटेनेंस से बाहर हो जाता है। डेटा स्टीवर्ड, रिहर्सल, साझा वॉर रूम और दो पन्नों की गाइड, सब बिल्कुल वैसे ही रहते। लोगों वाले पक्ष के लिए मेरी SAP ट्रेनिंग रणनीतियों की गाइड देखें।

कंपनियाँ SAP ECC से S/4HANA पर क्यों जाती हैं?

ट्रिगर 2027 में ECC के मेनस्ट्रीम मेंटेनेंस का अंत है। ज़्यादा मज़बूत वजहें ऑपरेशनल हैं: रियल-टाइम रिपोर्टिंग, तेज़ क्लोज़ और कस्टम कोड और नाज़ुक इंटीग्रेशन को ज़िंदा रखने में कम मेहनत। इस मामले में बिज़नेस को लाइव रिटेल एनालिटिक्स और छोटा मंथ-एंड क्लोज़ चाहिए था।

इस मामले में SAP Readiness Check ने क्या दिखाया?

इसने पक्का किया कि 44 प्रतिशत ऑब्जेक्ट कस्टमाइज़ किए गए थे और कई सालों से इस्तेमाल नहीं हुए थे। इससे कस्टम कोड के काम की संरचना बदल गई: पहले हटाएँ, जहाँ हो सके स्टैंडर्ड से बदलें, और री-फ़िट सिर्फ़ उसे करें जिसका असली बिज़नेस मूल्य था। Simplification Item List ने वे रिपोर्टें भी दिखाईं जिन्हें स्टैंडर्ड S/4HANA ने ग़ैर-ज़रूरी बना दिया था।

चुनिंदा री-डिज़ाइन के साथ ब्राउनफ़ील्ड क्यों चुना?

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

डेटा की सफ़ाई बहुत देर से करें तो क्या होता है?

टेस्टिंग खिंचती है, रिहर्सल फ़ेल होते हैं और go-live खिसक जाता है। यहाँ डुप्लिकेट वेंडर रिकॉर्ड और पुराने मास्टर डेटा ने टेस्टिंग में हफ़्तों की रुकावट पैदा की। समाधान हर फ़ंक्शन में SLA वाले डेटा स्टीवर्ड थे, और सफ़ाई को प्रोग्राम की सेहत के पैमाने के रूप में ट्रैक किया गया।

माइग्रेशन के दौरान इंटीग्रेशन कैसे सँभाले गए?

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

S/4HANA go-live के बाद अच्छा hypercare कैसा दिखता है?

IT और बिज़नेस के लिए साझा वॉर रूम, साफ़ SLA, रोज़ के एक्शन लॉग, और समस्याएँ बैकलॉग में पार्क होने के बजाय जल्दी बंद। भूमिका आधारित गाइड और फ़्लोर-वॉक औपचारिक ट्रेनिंग से तेज़ी से सपोर्ट कॉल घटाते हैं। वीकेंड शिफ़्ट बारी-बारी से लगाएँ और हैंडओवर स्क्रिप्ट करें ताकि टीम थककर चूर न हो।