Project के बीच में अपना SAP implementation partner कैसे बदलें

Project के बीच में अपना SAP implementation partner बदलने के लिए पहले पक्का कीजिए कि समस्या partner ही है, फिर उन्हें बताने से पहले हर document, design, code का हर हिस्सा और system access सुरक्षित कीजिए। उसके बाद ही नया partner चुनिए और overlap के साथ एक planned handover चलाइए।

छोटा जवाब: तब बदलिए जब partner आपको अच्छी गुणवत्ता के लोग न दे सके और इसे ठीक भी न कर सके। उन समस्याओं से बचने के लिए मत बदलिए जो आपकी तरफ़ हैं, क्योंकि नया partner उन्हें विरासत में पाता है।

यह लेख मेरी गाइड SAP implementation partner कैसे चुनें का हिस्सा है। वह गाइड शुरुआत में partner चुनने को कवर करती है। यह लेख बताता है कि जब आपका चुना हुआ partner ठीक से काम नहीं कर रहा हो, तब क्या करें।

मैंने एक programme के दौरान partner बदला है। वजह resources की गुणवत्ता थी: जब programme को ज़रूरत थी, तब partner अच्छी गुणवत्ता के लोग नहीं दे पाया।

यही वह संकेत है जिसे मैं सबसे पहले रखूँगा। कोई programme एक खराब phase, चूकी हुई तारीख या कमज़ोर design से उबर सकता है। उस partner से उबरना मुश्किल होता है जो काम पर सक्षम लोग नहीं लगा सकता।

ये वे संकेत हैं जिन पर कार्रवाई करनी चाहिए, लगभग उसी क्रम में जिसमें मैं उन्हें वज़न दूँगा:

1. Site पर लोगों की कमज़ोर गुणवत्ता। काम deliver करने वाले consultants वे लोग नहीं हैं जो आपको दिखाए गए थे, या वे अपने ही क्षेत्र के बुनियादी सवालों का जवाब नहीं दे पाते।
2. लोगों को बदलने में बार-बार नाकामी। कोई छोड़ता है और उसकी जगह आने वाले को हफ़्तों लगते हैं, या वह कम अनुभवी आता है।
3. कोई architecture और प्लान नहीं समझा सकता। Partner के lead से target design और go-live तक का रास्ता समझाने को कहिए। अगर वे नहीं समझा पाते, तो delivery को कोई नहीं चला रहा।
4. ऐसे deliverables जो समीक्षा में नहीं टिकते। Designs, test scripts और build documents जो कमज़ोर हैं, किसी दूसरे client से copy किए गए हैं या हैं ही नहीं।
5. खास समस्याओं के generic जवाब। वही खतरे का संकेत जो selection के समय था: ऐसे जवाब जो किसी भी कंपनी पर लागू हो सकते हैं।

देर से चलता phase, Explore में overrun या तनाव भरी steering committee, अपने आप में बदलने की वजहें नहीं हैं।

किसी को बदलने से पहले पता कीजिए कि क्या सच में partner ही कारण है। SAP programme recovery पर मेरी गाइड वे तीन जाँचें बताती है जो मैं सबसे पहले करता हूँ: programme की स्थिति, design और system में असल में क्या deploy है।

यह जाँच अक्सर दिखाती है कि समस्या साझा है। Explore में WRICEF list (workflows, reports, interfaces, conversions, enhancements और forms) बढ़ने के साथ बजट पर चोट पड़ती है। अगर आपने scope का नियंत्रण partner को दे दिया, या आपके key users को कभी programme के लिए छोड़ा ही नहीं गया, तो नया partner उसी गड्ढे में उतरता है।

इसलिए ईमानदारी से दो सवाल पूछिए:

1. क्या इसी partner की एक मज़बूत टीम इसे ठीक कर देगी? अगर हाँ, और partner वह टीम जल्दी दे सकता है, तो लोगों का बदलाव काफ़ी हो सकता है।
2. क्या किसी दूसरे partner को भी यही समस्याएँ झेलनी पड़ेंगी? अगर हाँ, तो पहले अपनी तरफ़ scope, फ़ैसले और governance ठीक कीजिए।

अगर पहले सवाल का जवाब नहीं है, क्योंकि partner को लोग नहीं मिल रहे, तो आपको अपना जवाब मिल गया। अच्छी गुणवत्ता के लोगों की उपलब्धता contract में संशोधन से ठीक होने वाली चीज़ नहीं है।

यही वह हिस्सा है जिसमें ज़्यादातर clients गलती करते हैं। वे फ़ैसला घोषित कर देते हैं, और उसके साथ ही उनकी मोलभाव की ताकत चली जाती है।

जाने वाले partner के पास वह ज्ञान है जो उसे बदलने के लिए आपको चाहिए। जब तक वह ज्ञान आपके हाथ में न आ जाए, फ़ैसले को एक छोटे समूह तक सीमित रखिए: sponsor, CFO, programme director और आपके legal या procurement lead।

अपने मौजूदा contract से शुरू कीजिए। Termination clause, notice period, deliverables का स्वामित्व और knowledge transfer या exit assistance से जुड़ी हर चीज़ पढ़िए। अगर आपका statement of work exit पर चुप है, तो SAP statement of work में क्या होना ज़रूरी है पर मेरा लेख बताता है कि अगले में क्या लिखना है।

यह है वह जो सुरक्षित करना है, और यह आम तौर पर कहाँ रहता है:

क्या सुरक्षित करें	यह क्यों मायने रखता है	इसे कहाँ होना चाहिए	इसकी रक्षा कैसे करें
Signed designs और फ़ैसले	नया partner फिर से शुरू करने के बजाय उन पर आगे build करता है	आपकी document repository या SAP Cloud ALM	Sign-off records के साथ नवीनतम approved versions की copy अभी लीजिए
WRICEF list और specifications	Scope baseline और build backlog	SAP Cloud ALM या आपकी अपनी repository	हर object के status के साथ list export कीजिए
Custom code और configuration	अब तक हुआ असली काम	आपके development और test systems	पक्का कीजिए कि सब कुछ आपके systems में है, partner की machines पर नहीं
Test scripts और results	असल में क्या काम करता है, इसका सबूत	आपका test tool या SAP Cloud ALM	Scripts, results और खुले defects export कीजिए
Data migration का काम	Mappings, cleansing rules, load programs	Shared drives और आपके systems	Data टीम से mapping documents और load programs इकट्ठा कीजिए
System और SAP support access	आपके landscape और आपके SAP support account पर नियंत्रण	आपके systems और SAP for Me	Partner के हर user की list बनाइए, उसी दिन हटाने के लिए तैयार
खुले issues और जोखिम	अगली टीम को सबसे पहले क्या उठाना है	RAID log और status reports	RAID log की तारीख वाली copy लीजिए

Project content अपने tools में रखिए

सबसे साफ़ सुरक्षा ढाँचागत है। किसी भी programme के पहले दिन से programme के documents, requirements और test evidence उन tools में रखिए जो आपके अपने हैं।

यहाँ SAP Cloud ALM मदद करता है। SAP के Cloud ALM FAQ के अनुसार, SAP Enterprise Support वाले customers, या RISE with SAP वाले customers, बिना अतिरिक्त fee के अपना tenant माँग सकते हैं, हर customer number पर एक। अगर project documentation आपके tenant में है, तो partner के जाने पर भी वह आपके पास रहता है।

घोषणा वाले दिन के लिए access का बदलाव तय कीजिए

Partner के consultants के पास अक्सर आपके SAP support account पर S-user IDs होते हैं, साथ ही आपके systems में user accounts भी। S-user IDs SAP for Me में आपके अपने administrators नियंत्रित करते हैं।

SAP की user management help कहती है कि छोड़कर गए users के IDs delete करने की ज़िम्मेदारी customer administrators की है। वह यह भी कहती है कि खास functions वाले IDs, जैसे software recipient या technical contact, तब तक delete नहीं हो सकते जब तक SAP वह function किसी और को transfer न कर दे। अभी पता कीजिए कि partner के कौन से users के पास ये functions हैं, और पहले उन्हें अपने लोगों को सौंपिए।

जब सामग्री सुरक्षित हो जाए और नया partner चुन लिया जाए, तब जाने वाले partner को बताइए। यह लिखित में, contract के अनुसार कीजिए, और उसी meeting में exit plan पर सहमति बनाइए।

Handover इस क्रम में सबसे अच्छा चलता है:

Programme के बीच में SAP partner बदलना

1. 01

   सुरक्षित करें

   किसी को बताने से पहले documents, designs, code, access और RAID log आपके हाथ में।

2. 02

   चुनें

   मिलते-जुलते projects के references और orals में असली टीम, तय effort के साथ।

3. 03

   Overlap

   जाने वाले और आने वाले leads व्यवस्थित knowledge transfer पर साथ-साथ काम करते हैं।

4. 04

   Re-validate

   नया partner designs, build और tests की समीक्षा उसके सामने करता है जो deploy है।

5. 05

   Re-baseline

   सबूत के आधार पर एक नया प्लान, अगला phase शुरू होने से पहले sign-off।

नया partner ठीक से चुनिए

जल्दबाज़ी का लालच होता है, क्योंकि जब तक आप चुनते हैं, programme पैसा खाता रहता है। मेरे अनुभव में पूरा selection लगभग 12 हफ़्ते लेता है, shortlist में कम से कम तीन partners के साथ। दबाव में होने वाला replacement तेज़ चल सकता है, लेकिन वे कदम मत छोड़िए जो आपकी रक्षा करते हैं।

जब मैं किसी client के लिए partner चुनता हूँ, तो client references को सबसे ज़्यादा वज़न देता हूँ। Reference calls पर मैं खरीदार के जैसे projects पर partner के अनुभव के बारे में पूछता हूँ। Programme के बीच में, इसका मतलब है references से किसी दूसरी firm का शुरू किया हुआ काम संभालने के बारे में पूछना।

दो चीज़ें मुझे किसी bid से पीछे हटा देती हैं: प्रस्तावित resources की कमज़ोर गुणवत्ता, और ऐसा partner जो architecture और प्लान नहीं समझा सकता। जब बदलाव resources की गुणवत्ता की वजह से हुआ हो, तो दोनों जाँचें ढीली नहीं, और कड़ी कीजिए।

Candidates से उनके प्रस्तावित लोगों के certification badges माँगिए। SAP अपने certification badges Credly पर जारी करता है, जैसा उसका digital badges help page बताता है। Badge पुष्टि करता है कि exam पास हुआ, इसलिए अनुभव references के ज़रिए भी जाँचिए।

SAP implementation RFP लिखने और tier के हिसाब से SAP implementation partners पर मेरी गाइड selection का बाकी हिस्सा कवर करती हैं।

नए partner के साथ contract अलग तरीके से कीजिए

जिस commercial model की मैं सलाह देता हूँ, वह है time and materials, जिसमें effort तय और मापा हुआ हो। Contract में phase और role के हिसाब से अनुमानित effort लिखा होता है, ताकि आप हर महीने वास्तविक effort को उसके सामने track कर सकें।

Statement of work में विस्तृत assumptions और exclusions भी चाहिए। Clients अक्सर इन्हें छोड़ देते हैं, और takeover में ये और भी ज़्यादा मायने रखते हैं, क्योंकि नया partner विरासत में मिली समस्याओं को exclude करना चाहेगा।

Contract में मुख्य लोगों के नाम भी लिखिए। ERP contract negotiation पर मेरे notes नामित resource clause को समझाते हैं और बताते हैं कि यह signature के बाद senior लोगों के गायब होने को क्यों रोकता है।

Overlap, फिर re-validate

एक ऐसी अवधि तय कीजिए जिसमें जाने वाले और आने वाले leads साथ काम करें। जाने वाली टीम हर design area, हर खुले defect और हर आधे बने object को समझाती है, और आने वाली टीम सवाल पूछती है।

फिर नए partner को मौजूदा काम को re-validate करने दीजिए। उम्मीद रखिए कि उन्हें gaps मिलेंगे, और यह भी कि उनमें से कुछ findings ज़्यादा effort के लिए मोलभाव की स्थिति होंगी। यहीं जाने वाले partner के deliverables पर independent राय काम की होती है।

Takeover को उस SAP Activate phase से जोड़िए जिसमें आप हैं। SAP छह phases बताता है: Discover, Prepare, Explore, Realize, Deploy और Run (SAP Activate)।

Explore के दौरान बदलाव की लागत ज़्यादातर design rework होती है। Realize के दौरान बदलाव में build और test rework की लागत भी जुड़ती है, क्योंकि code को पूरा करने से पहले उसे समझना पड़ता है।

कोई भी बदलाव मुफ़्त नहीं होता। मैं इस पर कोई number नहीं लगाऊँगा, क्योंकि यह phase, deliver हुए काम की गुणवत्ता और जाने वाला partner कितना सहयोग करता है, इस पर निर्भर करता है।

इन लागतों के लिए बजट रखिए:

1. Overlap। Handover के दौरान आप दो टीमों को भुगतान करते हैं।
2. Re-validation और rework। नया partner designs, configuration और code जाँचता है, और उसमें से कुछ फिर से किया जाता है।
3. Contract से exit। Notice periods, termination की शर्तें और चल रहे काम का कोई भुगतान, जैसा आपका contract तय करता है।
4. Selection का effort। RFP, orals और reference calls पर आपकी अपनी टीम का समय।
5. आपके लोगों का समय। Key users वे workshops और testing दोहराते हैं जिन्हें वे पूरा समझ रहे थे।
6. देरी। देरी का हर हफ़्ता पुराने systems, और आपकी internal टीम, को और लंबा चलाता है।

इन्हें टिके रहने की लागत से तौलिए। जो partner programme को staff नहीं कर सकता, वह programme के कठिन होने के साथ सस्ता नहीं होता, और Realize, testing और cutover पहले के कामों से कठिन होते हैं।

मैं clients को तीन मौकों पर independent consultant लाने की सलाह देता हूँ: contracting का चरण, design, और partner के documents और deliverables का आकलन। Partner का बदलाव तीनों को एक साथ छूता है।

नया partner rework की कीमत लगाए, उससे पहले एक independent reviewer आपको बता सकता है कि जाने वाले partner के deliverables असल में कितने काम के हैं। वह आने वाले partner के contract और design पर उसकी राय भी जाँच सकता है। SAP partner बनाम independent consultant पर मेरा लेख बताता है कि कौन क्या करता है।

इसी हफ़्ते पता कीजिए कि आपके signed designs, WRICEF list, test evidence और custom code असल में कहाँ रहते हैं, और हर एक का access कौन नियंत्रित करता है। आप बदलने की सोच रहे हों या नहीं, यह कीजिए। अगर इसमें से कुछ भी सिर्फ़ आपके partner के पास है, तो उसकी एक copy अपने systems में ले जाइए।

अगर आप partner बदलने पर विचार कर रहे हैं और deliverables या contract पर independent राय चाहते हैं, तो आप यहाँ मुझसे बात कर सकते हैं।

क्या project के बीच में SAP implementation partner बदला जा सकता है?

हाँ। पहले अपने contract की termination, notice और deliverable के स्वामित्व की शर्तें जाँचिए। फ़ैसला घोषित करने से पहले designs, code, test evidence और system access सुरक्षित कीजिए, फिर overlap की अवधि के साथ एक planned handover चलाइए।

SAP implementation partner कब बदलना चाहिए?

तब बदलिए जब partner अच्छी गुणवत्ता के लोग न दे सके और इसे ठीक भी न कर सके, या जब उसके leads architecture और प्लान न समझा सकें। सिर्फ़ इसलिए मत बदलिए कि कोई phase देर से चला। पहले कारण पहचानिए, क्योंकि scope के नियंत्रण या आपके अपने फ़ैसलों से जुड़ी समस्याएँ नए partner तक आपके साथ जाएँगी।

Contract खत्म करने से पहले SAP partner से क्या लेना चाहिए?

Signed designs और फ़ैसलों के records, और हर object के status के साथ WRICEF list। आपके अपने systems में custom code और configuration, test scripts और results, data migration mappings और RAID log। अपने systems और अपने SAP support account में partner के हर user की list भी बनाइए, ताकि उसी दिन access हटाया जा सके।

Project के बीच में SAP partner बदलने में कितनी लागत आती है?

कोई standard आँकड़ा नहीं है। दोनों टीमों के overlap, re-validation और rework, contract exit की शर्तों, अपने selection के effort और देरी के लिए बजट रखिए। Phase जितना बाद का, rework उतना ज़्यादा, क्योंकि code और tests को पूरा करने से पहले उन्हें समझना पड़ता है।

SAP implementation partner को बदलने में कितना समय लगता है?

मेरे अनुभव में पूरा partner selection लगभग 12 हफ़्ते लेता है, shortlist में कम से कम तीन partners के साथ। दबाव में होने वाला replacement तेज़ चल सकता है, लेकिन reference calls और असली टीम के साथ orals बनाए रखिए।

SAP implementation के documents और code का मालिक कौन होता है?

यह आपका contract तय करता है, इसलिए deliverable के स्वामित्व वाला clause जाँचिए। व्यवहार में, documents को अपनी repository या SAP Cloud ALM tenant में, और code और configuration को partner के servers के बजाय अपने SAP systems में रखकर अपनी रक्षा कीजिए।