S/4HANA माइग्रेशन partner कैसे चुनें

SAP ECC से S/4HANA माइग्रेशन partner चुनने के लिए, SAP के partner designations से एक लंबी list बनाइए, फिर दो चीज़ों पर फ़ैसला कीजिए: आपके जैसे माइग्रेशन के references और आपके business के लिए partner का high-level डिज़ाइन। जिस भी partner के जवाब generic हों, उससे दूर रहिए, और scope का नियंत्रण खुद अपने पास रखिए।

छोटा जवाब: badge किसी partner को आपकी list में पहुँचाता है। References और डिज़ाइन उसे contract दिलाते हैं।

यह लेख मेरी ECC से S/4HANA माइग्रेशन गाइड का एक हिस्सा है, जो रास्तों, समय-सीमाओं और डेडलाइन को कवर करती है। यहाँ मैं सिर्फ partner के फ़ैसले की बात करता हूँ। यही वह फ़ैसला है जो आगे की ज़्यादातर चीज़ों को आकार देता है, क्योंकि जो partner आप चुनते हैं, वही रास्ता, प्लान और scope प्रस्तावित करेगा।

माइग्रेशन partner, implementation partner जैसी खरीद नहीं है। Brownfield conversion पर आप तकनीकी conversion का हुनर, custom code remediation, data preparation और ऐसा cutover खरीद रहे हैं जो पहली बार में काम करे। Greenfield पर आप process design भी खरीद रहे हैं।

ज़्यादातर selection प्रक्रियाएँ यह चूक जाती हैं। वे day rates और methodology slides की तुलना करती हैं, जबकि असली काम कुछ ऐसी जगहों पर है जिन्हें slides शायद ही दिखाती हैं:

1. Custom code. मेरे अनुभव में यह माइग्रेशन का वह चरण है जो सबसे ज़्यादा बार overrun होता है, और वह छिपी लागत जिसे कंपनियाँ सबसे ज़्यादा भूलती हैं।
2. डेटा. जिन प्रोग्राम्स को मैंने देखा है, उनमें data migration में 30 से 40 प्रतिशत प्रयास लगता है।
3. Cutover. Brownfield पर मैं असली cutover से पहले तीन mock conversions की योजना बनाता हूँ, और मैंने downtime एक weekend से लेकर एक हफ़्ते तक देखा है।
4. डिज़ाइन. पहले महीनों में partner जो डिज़ाइन फ़ैसले प्रस्तावित करता है, वे सालों तक आपकी लागत तय करते हैं।

इसलिए सवाल यह नहीं है कि "सबसे अच्छा partner कौन है"। सवाल यह है कि कौन सा partner सबूत के साथ दिखा सकता है कि वह आपके सिस्टम के लिए इन चार क्षेत्रों को कैसे संभालेगा।

SAP अपना partner programme, SAP PartnerEdge, एक competency framework पर चलाता है। 2022 में जब SAP ने इसे शुरू किया, तो उसने सात competencies तय कीं, हर एक के तीन tiers के साथ: essential, advanced और expert, और हर competency के अंदर product या process स्तर पर specialisations। Partners इन्हें expert knowledge, customer success और दक्षता के आधार पर हासिल करते हैं।

ये designations SAP Partner Finder में दिखते हैं, जहाँ आप partners को search और filter कर सकते हैं। PartnerEdge के जनवरी 2025 के update में SAP ने कहा कि partner levels तय करने में अब expertise की भूमिका और भी मज़बूत है।

RISE with SAP के लिए एक अलग recognition है। जून 2024 में शुरू हुई RISE with SAP Validated Partner recognition के लिए कई competencies का expert level चाहिए। इनमें RISE with SAP S/4HANA Cloud Private Edition, SAP Business Technology Platform और SAP Business Process Transformation शामिल हैं।

इस recognition का SAP का जुलाई 2025 का विवरण delivery पक्ष जोड़ता है। यह delivery teams में RISE with SAP Methodology, मुख्य भूमिकाओं में certified लोग, और SAP Cloud ALM में दर्ज clean core quality gates माँगता है।

हर संकेत आपको क्या बताता है और क्या नहीं बताता, वह यह है:

संकेत	यह क्या पुष्टि करता है	यह क्या पुष्टि नहीं करता
Competency tier (essential, advanced, expert)	Firm के पास वह ज्ञान, delivered projects और customer results हैं जिन्हें SAP उस क्षेत्र में मापता है	कि आपके प्रोग्राम के लिए प्रस्तावित लोगों ने वह काम किया था
Specialisation	किसी खास SAP product या process में उपलब्धि	आपकी industry या आपके तरह के माइग्रेशन में गहराई
RISE with SAP Validated Partner	Expert competencies, RISE methodology और SAP Cloud ALM में clean core gates	कि partner आपके custom code, आपके डेटा या आपके finance close को समझता है
SAP Partner Finder में listing	Firm दिखने वाले designations के साथ एक registered SAP partner है	Fit के बारे में कुछ भी

Badges को filter की तरह इस्तेमाल कीजिए। जिस partner के पास कोई प्रासंगिक competency नहीं है, उसे बड़े माइग्रेशन की list में नहीं होना चाहिए। हर badge वाले partner को भी नीचे के दो tests पास करने होंगे।

मैं partner का फ़ैसला कैसे चलाऊँगा

1. 01

   Assess

   Market में जाने से पहले SAP Readiness Check चलाइए और custom code और डेटा का आकार आँकिए।

2. 02

   Scope अपने हाथ में

   Scope और वे फ़ैसले लिखिए जो आप चाहते हैं, ताकि partners आपके तथ्यों पर जवाब दें।

3. 03

   लंबी list

   प्रासंगिक competencies वाली firms ढूँढने के लिए SAP designations और Partner Finder का इस्तेमाल कीजिए।

4. 04

   Test

   References जाँचिए और shortlist के हर partner से high-level डिज़ाइन माँगिए।

5. 05

   Contract

   भुगतान और scope के बदलावों को उस डिज़ाइन से जोड़िए जिसे आपने परखा।

जब मैं partner के फ़ैसले पर सलाह देता हूँ, तो मेरे लिए दो चीज़ें फ़ैसला करती हैं: references और partner का high-level डिज़ाइन। Proposal में बाकी सब सहायक सामग्री है।

आपके जैसे माइग्रेशन के references

Reference तभी काम का है जब वह आपकी स्थिति से मेल खाता हो। किसी दूसरी industry के greenfield का reference एक brownfield manufacturer को बहुत कम बताता है।

ऐसे references माँगिए जो तीन चीज़ों पर मेल खाते हों, फिर उन्हें खुद call कीजिए:

1. रास्ता. Brownfield, greenfield या selective, वही जो आपका है।
2. पैमाना. Entities, देशों और custom objects की मिलती-जुलती संख्या।
3. लोग. Reference से पूछिए कि काम का नेतृत्व किसने किया, फिर जाँचिए कि क्या वही लोग आपके proposal में हैं।

Call पर पूछिए कि शुरुआत में और अंत में custom code की गिनती कितनी थी, कितने mock conversions चले और cutover पर क्या गलत हुआ। जो reference इन सवालों का जवाब नहीं दे सकता, वह काम के पर्याप्त करीब नहीं था।

आपके business के लिए उनका high-level डिज़ाइन

दूसरा test यह है कि sign करने से पहले shortlist के हर partner से अपने target S/4HANA सिस्टम का high-level डिज़ाइन माँगिए। उन्हें अपने Readiness Check के नतीजे और अपना लिखा scope दीजिए, फिर पूछिए कि वे आपकी प्रक्रियाओं, आपके custom code और आपके डेटा को कैसे संभालेंगे।

एक अच्छा high-level डिज़ाइन आपकी entities, आपकी महत्वपूर्ण प्रक्रियाओं और मायने रखने वाले custom objects के नाम लेता है। वह बताता है कि वे क्या हटाएँगे, क्या रखेंगे और क्यों। वह दिखाता है कि वे data loads और cutover की संरचना कैसे करेंगे।

यहीं आप यह भी देखते हैं कि partner clean core रख सकता है या नहीं। Customisations को न्यूनतम रखा जाना चाहिए और उन पर अच्छी governance होनी चाहिए। अगर डिज़ाइन SAP को आपके पुराने सिस्टम की तरह चलाने की कोशिश करता है, तो यही वह आदत है जो हर भविष्य के upgrade की लागत बढ़ाती है।

जिस खतरे के संकेत पर मैं पीछे हट जाता हूँ, वह है generic जानकारी। ऐसी pitch, या आपके सवालों के ऐसे जवाब, जो आपके business के हिसाब से नहीं हैं।

आप इसे पहचान लेंगे। Proposal methodology को विस्तार से बताता है और आपकी कंपनी को एक पैराग्राफ़ में। आपके custom code के सवालों पर "accelerators" के बारे में जवाब मिलता है।

प्लान में वही चरण और अवधियाँ होती हैं जो आपने पिछले महीने किसी दूसरी firm के deck में देखी थीं।

Generic जवाबों का मतलब दो में से एक चीज़ होता है। या तो partner ने आपको समझने का काम नहीं किया है, या वह sign होने के बाद तक ऐसा करने का इरादा नहीं रखता। दोनों ही हालात में असली डिज़ाइन Explore के दौरान आपके बजट पर होगा।

Test सीधा है। हर जवाब लीजिए और अपनी कंपनी के नाम की जगह किसी प्रतिस्पर्धी का नाम रखिए। अगर वह फिर भी सही पढ़ा जाता है, तो वह आपके लिए नहीं लिखा गया था।

माइग्रेशन बजट की ज़्यादातर समस्याओं के पीछे जो जड़ मैं देखता हूँ, वह है scope पर vendors का नियंत्रण होने देना। बजट Explore चरण में चोट खाते हैं, जब WRICEF objects (workflows, reports, interfaces, conversions, enhancements और forms) बढ़ते हैं। जो partner scope लिखता है, वही change requests भी लिखता है।

यह बुरी नीयत की बात नहीं है। Partner का commercial incentive शुरू करना है, और जब काम मिले तो उसे जोड़ना। आपका incentive उस संख्या के भीतर पूरा करना है जो आपने बोर्ड को दी थी।

ये अलग-अलग काम हैं, और scope उस पक्ष के पास होना चाहिए जो पैसा देता है।

व्यवहार में scope की ownership को चार तरीकों से अपनी तरफ़ रखिए:

1. Market में जाने से पहले scope लिखिए. इसे अपने Readiness Check और अपने custom code विश्लेषण पर आधारित कीजिए, partner की discovery workshop पर नहीं।
2. एक design authority बनाइए. Business और IT साथ मिलकर, हर नए WRICEF object को मंज़ूर या नामंज़ूर करने के अधिकार के साथ।
3. WRICEF list का baseline बनाइए. Contract sign होते समय objects गिनिए और हर steering committee में गिनती report कीजिए।
4. Contract को उस डिज़ाइन से जोड़िए जिसे आपने परखा. उस डिज़ाइन के मुकाबले बदलाव change control से गुज़रते हैं, एक कारण और एक लागत के साथ।

फिर भी overruns की योजना बनाइए। मैं 10 से 20 प्रतिशत की contingency रखूँगा, और याद रखिए कि services प्रोग्राम की कुल लागत का 35 से 50 प्रतिशत होती हैं। S/4HANA माइग्रेशन cost पर मेरी गाइड दिखाती है कि रास्ते के हिसाब से संख्या को क्या तय करता है, और ERP contract negotiation पर मेरे notes commercial शर्तों को कवर करते हैं।

इस पर मेरा जवाब छोटा है: यह references पर निर्भर करता है।

जिस global SI के पास आपकी industry में कोई मिलता-जुलता brownfield reference नहीं है, वह उस boutique से कमज़ोर विकल्प है जिसने तीन किए हैं। जिस boutique के पास आपके पैमाने का कोई reference नहीं है, वह उस SI से कमज़ोर विकल्प है जिसके पास है। Firm का आकार आपको bench की गहराई और पहुँच के बारे में बताता है, और references बताते हैं कि क्या वे लोग आपका माइग्रेशन कर सकते हैं।

मैंने अमेरिका में tier के हिसाब से SAP implementation partners पर अलग से लिखा है, कि हर tier किसमें अच्छा है और कहाँ वह अक्सर विफल होता है। मैं यहाँ वे lists नहीं दोहराऊँगा, और मैं partners की ranking नहीं करता। समझौतों को समझने के लिए उस लेख का इस्तेमाल कीजिए, फिर आपकी shortlist पर जो भी हो, उस पर ऊपर के दो tests चलाइए।

आकार पर एक और बात। कई बड़े प्रोग्राम एक से ज़्यादा partner इस्तेमाल करते हैं, उदाहरण के लिए मूल माइग्रेशन के लिए एक prime और selective data transition या custom code के लिए एक विशेषज्ञ। यह तब काम करता है जब scope आपके पास हो और integration के लिए एक partner जवाबदेह हो।

एक भी request for proposal भेजने से पहले assessment चलाइए। एक SAP Readiness Check और माइग्रेशन assessment आपको custom code, डेटा और simplification के वे तथ्य देता है जिन पर partners को जवाब देना चाहिए। इसके बिना हर partner खाली जगह अपनी मान्यताओं से भरता है, और आप जवाबों की तुलना नहीं कर सकते।

अगर आप पहले ही sign कर चुके हैं और प्रोग्राम खिसक रहा है, तो सवाल अलग हैं। SAP program recovery पर मेरी गाइड बताती है कि पहले क्या जाँचना है।

जिन 21 SAP प्रोग्राम्स का मैंने नेतृत्व किया है या जिन्हें संकट से निकाला है, उनमें सबसे बड़ी गलती जो मैं देखता हूँ वह है शुरुआत में ठीक से योजना न बनाना। Partner का चुनाव वहीं है जहाँ से वह योजना शुरू होती है। अगर आप किसी shortlist या proposal पर एक स्वतंत्र राय चाहते हैं, तो मैं संगठनों की इसमें मदद करता हूँ, और आप यहाँ मुझसे संपर्क कर सकते हैं।

मैं SAP S/4HANA माइग्रेशन partner कैसे चुनूँ?

प्रासंगिक expertise वाले partners की एक लंबी list बनाने के लिए SAP की competencies और Partner Finder का इस्तेमाल कीजिए। फिर आपके जैसे माइग्रेशन के references और आपके business के लिए हर partner के high-level डिज़ाइन पर फ़ैसला कीजिए। जिन partners के जवाब generic हों, उनसे दूर रहिए, और scope की ownership अपने पास रखिए।

RISE with SAP Validated Partner क्या है?

यह एक recognition है जिसे SAP ने 2024 में उन partners के लिए शुरू किया जो बड़े और जटिल cloud ERP प्रोजेक्ट्स deliver करते हैं। Validated partners के पास कई SAP competencies का expert level होता है, जिसमें RISE with SAP S/4HANA Cloud Private Edition शामिल है। SAP, RISE with SAP Methodology, मुख्य भूमिकाओं में certified लोग और SAP Cloud ALM में दर्ज clean core quality gates की भी अपेक्षा करता है।

S/4HANA माइग्रेशन के लिए बड़ा SI लूँ या boutique?

यह references पर निर्भर करता है। वह firm चुनिए जिसके लोगों ने आपके जैसा माइग्रेशन किया है, उसी रास्ते पर, मिलते-जुलते पैमाने पर और मिलती-जुलती industry में। Firm का आकार आपको bench की गहराई और पहुँच के बारे में बताता है, इस बारे में नहीं कि टीम आपका माइग्रेशन कर सकती है या नहीं।

Sign करने से पहले मुझे SAP partner से कौन से सवाल पूछने चाहिए?

मिलते-जुलते माइग्रेशन के references माँगिए और उन्हें खुद call कीजिए। अपने Readiness Check के नतीजों और अपने scope के आधार पर अपने target सिस्टम का high-level डिज़ाइन माँगिए। पूछिए कि वे custom code का आकार कैसे आँकेंगे और कैसे घटाएँगे, कितने mock conversions की योजना है और आपके प्रोग्राम में ठीक-ठीक कौन होगा।

SAP implementation partner चुनते समय खतरे के संकेत क्या हैं?

मुख्य संकेत generic जानकारी है: ऐसी pitch या जवाब जो किसी भी कंपनी पर लागू हो सकते हैं। दूसरे संकेत हैं ऐसा प्लान जो हर दूसरे प्लान जैसा दिखता है, custom code और डेटा पर गोलमोल जवाब, और ऐसा partner जो sign होने के बाद अपनी discovery workshop में scope तय करना चाहता है।

क्या SAP expert partner badge सफल माइग्रेशन की गारंटी देता है?

नहीं। SAP के competency tiers firm के स्तर पर ज्ञान, delivered projects और customer results की पुष्टि करते हैं। वे यह पुष्टि नहीं करते कि आपके प्रोग्राम के लिए प्रस्तावित लोगों ने वह काम किया था, या कि partner आपके custom code और डेटा को समझता है।

Badges से filter कीजिए, फिर references और डिज़ाइन को परखिए।