SAP इम्प्लीमेंटेशन टीम के ज़रूरी रोल और ज़िम्मेदारियाँ

SAP इम्प्लीमेंटेशन को आठ रोल चाहिए, जिनमें से हर एक का नामित और समर्पित ओनर हो: एग्ज़िक्यूटिव स्पॉन्सर, प्रोजेक्ट मैनेजर, फ़ंक्शनल लीड, IT लीड, डेटा माइग्रेशन लीड, चेंज मैनेजमेंट लीड, इम्प्लीमेंटेशन पार्टनर और एक स्वतंत्र प्रोग्राम एडवाइज़र। RISE with SAP में SAP के अपने डिलीवरी संपर्क भी जुड़ जाते हैं और clean core का स्वामित्व साफ़ तौर पर तय करना पड़ता है। यह गाइड उन स्पॉन्सर और प्रोग्राम डायरेक्टर के लिए है जो टीम बना रहे हैं या बिगड़ी टीम को सुधार रहे हैं। इसमें बताया गया है कि हर रोल किसका मालिक है, उसके बिना क्या टूटता है, कंपनी के आकार के हिसाब से टीम साइज़ क्या हो, और go-live से पहले सेंटर ऑफ़ एक्सीलेंस (CoE) कैसे बनाएँ। सबसे पहले देखें कि आठ में से कौन-सा रोल ऐसे व्यक्ति के पास है जिसकी अपनी रोज़ की नौकरी भी है। वही आपका सबसे बड़ा जोखिम है।

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

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

हर SAP इम्प्लीमेंटेशन में ये रोल भरे होने चाहिए। टाइटल से ज़्यादा मायने जवाबदेही के हैं।

1. एग्ज़िक्यूटिव स्पॉन्सरफ़ैसले, फ़ंडिंग, एस्केलेशन
   ERP प्रोग्राम एडवाइज़रस्वतंत्र निगरानी, जोखिम, एग्ज़िक्यूटिव अलाइनमेंट
2. प्रोजेक्ट मैनेजरसमय-सीमा, बजट, तालमेल

• फ़ंक्शनल लीड और SMEप्रोसेस डिज़ाइन, मॉड्यूल कॉन्फ़िगरेशन
• IT लीड और टीमइंटीग्रेशन, डेवलपमेंट, सुरक्षा
• डेटा माइग्रेशन लीडडेटा गुणवत्ता, लोड का क्रम, कटओवर
• चेंज मैनेजमेंट लीडट्रेनिंग, अपनाना, संवाद
• इम्प्लीमेंटेशन पार्टनरआर्किटेक्चर, इंटीग्रेशन डिज़ाइन, डिलीवरी

रोल	मुख्य जवाबदेही	इसके बिना क्या टूटता है
एग्ज़िक्यूटिव स्पॉन्सर	रणनीतिक फ़ैसले, फ़ंडिंग, एस्केलेशन का अधिकार	भटकाव, स्कोप की लड़ाइयाँ, कोई गतिरोध नहीं तोड़ता
प्रोजेक्ट मैनेजर	समय-सीमा, बजट, टीमों के बीच तालमेल	देरी, अनसुलझी रुकावटें, लागत में बढ़ोतरी
फ़ंक्शनल लीड और SME	बिज़नेस प्रोसेस डिज़ाइन, मॉड्यूल कॉन्फ़िगरेशन	गलत कॉन्फ़िगरेशन, go-live के बाद वर्कअराउंड
IT लीड और टीम	इंटीग्रेशन, डेवलपमेंट, सुरक्षा, परफ़ॉर्मेंस	टेक्निकल डेट, टूटे इंटरफ़ेस, अस्थिरता
डेटा माइग्रेशन लीड	डेटा गुणवत्ता, लोड का क्रम, कटओवर की सटीकता	बेकार डेटा, फेल हुआ go-live, महीनों की सफ़ाई
चेंज मैनेजमेंट लीड	ट्रेनिंग, अपनाना, संवाद	यूज़र का विरोध, समानांतर स्प्रेडशीट
इम्प्लीमेंटेशन पार्टनर	आर्किटेक्चर, इंटीग्रेशन डिज़ाइन, डिलीवरी	ज़रूरत से ज़्यादा बनाना, इंटीग्रेशन की नाकामियाँ
ERP प्रोग्राम एडवाइज़र	स्वतंत्र निगरानी, जोखिम, एग्ज़िक्यूटिव अलाइनमेंट	अलग-थलग लिए गए फ़ैसले, टाली जा सकने वाली गलतियाँ

एग्ज़िक्यूटिव स्पॉन्सर

स्पॉन्सर स्टीयरिंग डेक पर लिखा एक नाम नहीं है। वह वे फ़ैसले लेता है जो कोई और नहीं ले सकता: बजट, स्कोप में बदलाव, विभागों में संसाधनों की प्रतिबद्धता। जब यह रोल सिर्फ़ औपचारिक होता है, तो प्रोजेक्ट भटक जाते हैं।

मैंने एक ऐसी कंपनी के साथ काम किया जिसने यह रोल छोड़ दिया था। प्रोजेक्ट भटकता रहा। न फ़ैसले, न प्रगति, पैसा पानी में।

असरदार स्पॉन्सर हाइपरकेयर तक साथ रहते हैं। वे go-live के बाद भी मासिक स्टीयरिंग सत्रों में आते हैं और छोटे फ़ैसले लेते हैं जो हफ़्तों से अटकी चीज़ें खोल देते हैं। उस मंच को कैसे ढालें, यह मेरी SAP स्टीयरिंग कमेटी बनाने की गाइड में है।

प्रोजेक्ट मैनेजर

PM रोज़ का काम चलाता है: समय-सीमा, रिस्क लॉग, तालमेल, अपडेट। बड़े SAP प्रोग्राम में यह उस व्यक्ति के लिए फ़ुल-टाइम रोल है जो पहले यह कर चुका हो।

मैंने देखा कि एक क्लाइंट ने इम्प्लीमेंटेशन के बीच में अपना लीड डेवलपर खो दिया। बदली ढूँढने की भागदौड़ में पूरा प्रोजेक्ट हफ़्तों रुका रहा।

उल्टी समस्या भी उतनी ही नुकसानदेह है। मैंने एक ऐसी कंपनी के साथ काम किया जिसकी टीम में 30 से ज़्यादा लोग थे। किसी को नहीं पता था कि फ़ैसले का मालिक कौन है। छोटे-से बदलाव के लिए पाँच मीटिंग चाहिए होती थीं। सिर्फ़ संवाद के बोझ से समय-सीमा 12 महीने से खिंचकर 18 महीने हो गई।

फ़ंक्शनल लीड और विषय विशेषज्ञ (SME)

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

मैंने एक मैन्युफ़ैक्चरिंग क्लाइंट के साथ काम किया जिसकी टीम इसलिए बेहतरीन रही कि उसके फ़ंक्शनल लीड ने प्रोसेस डिज़ाइन करने से पहले फ़ैक्टरी फ़्लोर पर समय बिताया।

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

IT लीड और टीम

IT टीम तकनीकी बुनियाद की मालिक है: डेवलपमेंट, Basis, सुरक्षा, इंटीग्रेशन और परफ़ॉर्मेंस। S/4HANA पर clean-core अनुशासन भी उसी का है, यानी कस्टम कोड को कोर से बाहर रखना।

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

डेटा माइग्रेशन लीड

यह रोल देर से सौंपा जाता है और इसे कम संसाधन मिलते हैं। जब तक डेटा की समस्याएँ सामने आती हैं, प्रोग्राम पर पहले से शेड्यूल का दबाव होता है।

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

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

चेंज मैनेजमेंट लीड

यह सबसे लगातार कम संसाधन पाने वाला रोल है। मैंने करोड़ों डॉलर के सिस्टम बेकार पड़े देखे हैं, क्योंकि कोई अपने काम का तरीक़ा बदलना नहीं चाहता था।

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

एक रिटेल क्लाइंट इसलिए सफल रहा कि उसने नए सिस्टम को लेकर अपने कैशियर की चिंताएँ सुनीं और अपना तरीक़ा बदला।

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

ERP प्रोग्राम एडवाइज़र

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

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

मुसीबत को जल्दी पहचानना दूसरा आधा हिस्सा है। एक बार मैंने एक क्लाइंट की डेटा टीम में एक अहम स्किल गैप पहचाना, जो go-live को टालने से तीन महीने पहले का था। हमने उसे संकट बनने से पहले ठीक कर लिया।

आठ रोल का मॉडल अब भी सही है। 2026 में तीन चीज़ों को उसमें जोड़ना पड़ता है।

RISE पर SAP के अपने डिलीवरी संपर्क

RISE with SAP प्राइवेट क्लाउड पर SAP इंफ़्रास्ट्रक्चर और तकनीकी संचालन चलाता है। उसका रोल्स एंड रेस्पॉन्सिबिलिटीज़ दस्तावेज़ बताता है कि ग्राहक SAP Cloud Architect Advisor, Client Delivery Manager या SAP की प्राइवेट क्लाउड कस्टमर सेंटर टीम के साथ सेवाएँ तय करते हैं। SAP जिसे भी असाइन करे, उसे पार्टनर टीम के बगल में अपने रोस्टर में रखें, और अपनी तरफ़ से उस रिश्ते के मालिक का नाम तय करें। ऑन-प्रेमाइस में SAP सॉफ़्टवेयर वेंडर होता है और यह लागू नहीं होता।

Clean-core और एक्सटेंशन का स्वामित्व

S/4HANA Cloud Public Edition पर clean core डिज़ाइन से ही लागू है: एक्सटेंशन released API, की-यूज़र टूल या SAP BTP से होते हैं। प्राइवेट क्लाउड और ऑन-प्रेमाइस पर बदलाव अब भी संभव हैं, पर हर एक अपग्रेड को मुश्किल बनाता है। उस रेखा का मालिक कोई होना चाहिए।

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

AI उत्पादकता बदलता है, जवाबदेही नहीं

SAP Joule for Consultants (2025 से सामान्य रूप से उपलब्ध) कॉन्फ़िगरेशन के सवालों के जवाब SAP के अपने नॉलेज बेस से देता है और ABAP कोड समझाता है। SAP Build Code SAP BTP पर Java और JavaScript एक्सटेंशन कोड बनाता है। Microsoft Copilot स्टीयरिंग कमेटी के ब्रीफ़ और स्टेटस रिपोर्ट का ड्राफ़्ट बनाता है।

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

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

तालिका कंपनी के पैमाने के हिसाब से हर रोल का आम साइज़ दिखाती है। इसे शुरुआती बिंदु मानें और स्कोप और भौगोलिक स्थिति के अनुसार बदलें। SAP से बाहर यही सवाल देखना हो तो मेरी ERP इम्प्लीमेंटेशन टीम गाइड देखें।

रोल	छोटा उद्यम	मिड-मार्केट	बड़ा उद्यम
एग्ज़िक्यूटिव स्पॉन्सर	सीनियर डायरेक्टर	CIO या CFO	C-सूट, स्टीयरिंग कमेटी के साथ
प्रोजेक्ट मैनेजर	1 फ़ुल-टाइम	1-2 फ़ुल-टाइम	प्रोग्राम मैनेजर और वर्कस्ट्रीम PM
फ़ंक्शनल लीड	प्रति मॉड्यूल 1-2	हर मॉड्यूल के लिए समर्पित	हर मॉड्यूल में कई
IT टीम	2-3 (साझा)	4-6 (समर्पित)	8+ विशेषज्ञ
डेटा माइग्रेशन	1 लीड	1 लीड और एनालिस्ट	समर्पित वर्कस्ट्रीम
चेंज मैनेजमेंट	कम से कम 1	कम से कम 2	3-5 समर्पित
Clean-core या BTP एक्सटेंशन लीड	सॉल्यूशन आर्किटेक्ट	सॉल्यूशन आर्किटेक्ट	समर्पित रोल
SAP संपर्क (RISE)	नामित संपर्क	नामित संपर्क	नामित संपर्क, तिमाही समीक्षा के साथ
इम्प्लीमेंटेशन पार्टनर	5-10 कंसल्टेंट	15-25 कंसल्टेंट	30+, प्रोग्राम डायरेक्टर के साथ

तकनीकी हुनर से सिस्टम बनता है। इमोशनल इंटेलिजेंस तय करती है कि लोग उसे इस्तेमाल करेंगे या नहीं।

मैंने एक मैन्युफ़ैक्चरिंग कंपनी के साथ काम किया जहाँ वेयरहाउस मैनेजर मीटिंग में मुस्कुराता था, पर पर्दे के पीछे प्रोजेक्ट को कमज़ोर करता था। एक समझदार चेंज मैनेजर ने संकेत जल्दी भाँप लिए और उसे समर्थक बना लिया। go-live पर यह पता चलता तो इसे ठीक करना कहीं ज़्यादा मुश्किल होता।

एक क्लाइंट का प्रोजेक्ट मैनेजर तकनीकी रूप से शानदार था, पर अपना संदेश ढाल नहीं पाता था। CFO को वेयरहाउस स्टाफ़ से अलग तरह का संवाद चाहिए। नतीजा पूरे संगठन में कम स्वीकार्यता और एक कष्टदायक go-live रहा।

“कर्मचारी या कंसल्टेंट?” का जवाब लगभग हमेशा होता है: दोनों।

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

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

कंसल्टेंट पैटर्न पहचानने का अनुभव लाते हैं। मैंने एक क्लाइंट के लिए एक कंसल्टेंट बुलाया, जिसने फ़ौरन एक ऐसा डेटा माइग्रेशन तरीक़ा पहचाना जो उनका go-live गिरा देता।

कंसल्टेंट के साथ जोखिम ज्ञान के हस्तांतरण का है। अगर अंदर किसी ने सिस्टम नहीं सीखा, तो लॉन्च के बहुत बाद तक कंसल्टिंग फ़ीस चलती रहती है।

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

1. सॉफ़्टवेयर चुनने से पहले टीम बनाएँ। एक क्लाइंट ने ऐसे मॉड्यूल खरीद लिए जिन्हें उसकी टीम संभाल नहीं सकती थी, और छह महीने अफ़रा-तफ़री रही।
2. लोगों को पूरी तरह समर्पित करें। पार्ट-टाइम का मतलब है कि दबाव आने पर रोज़ की नौकरी जीतती है। मैंने क्रिटिकल कॉन्फ़िगरेशन को हफ़्तों इसलिए रुका देखा है कि कोई बहुत व्यस्त था।
3. जहाँ संभव हो, एक जगह बैठाएँ। एक मैन्युफ़ैक्चरिंग क्लाइंट ने अपनी टीम को हफ़्ते में तीन दिन एक कमरे में बिठाकर हफ़्तों की आगे-पीछे की बातचीत बचा ली।
4. एस्केलेशन के रास्ते शुरू में तय करें। एक रिटेल क्लाइंट के पास एक पन्ने का दस्तावेज़ था जो ठीक-ठीक दिखाता था कि फ़ैसले ऊपर कैसे जाते हैं। इससे अनगिनत देरियाँ बचीं।
5. फ़ैसले उनकी वजह के साथ लिखें। मैंने एक कंपनी के साथ काम किया जो दर्ज करती थी कि उसने क्या तय किया और क्यों। इससे तब अंतहीन दोहराव बचा जब प्रोजेक्ट के बीच में नए एग्ज़िक्यूटिव आए।
6. रास्ते में मील के पत्थर मनाएँ। एक मैन्युफ़ैक्चरिंग क्लाइंट मासिक सराहना आयोजन करता था। छोटी बात है, पर 18 महीने के थका देने वाले इम्प्लीमेंटेशन में उसने हौसला बनाए रखा।

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

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

इम्प्लीमेंटेशन के पहले महीनों से जिन CoE रोल की योजना बनानी है, वे ये हैं।

CoE रोल	मुख्य ज़िम्मेदारी
CoE डायरेक्टर	SAP रणनीति, बिज़नेस लक्ष्यों से अलाइनमेंट, CoE का संचालन
सॉल्यूशन आर्किटेक्ट	आर्किटेक्चर, इंटीग्रेशन डिज़ाइन, clean-core गवर्नेंस
Clean-core या BTP एक्सटेंशन लीड	एक्सटेंशन कैटलॉग, अपग्रेड के असर का विश्लेषण
फ़ंक्शनल कंसल्टेंट	मॉड्यूल ऑप्टिमाइज़ेशन, प्रोसेस सुधार
टेक्निकल कंसल्टेंट	डेवलपमेंट, Basis, परफ़ॉर्मेंस, सुरक्षा
चेंज और ट्रेनिंग लीड	अपनाना, ट्रेनिंग, क्षमता में बढ़ोतरी
डेटा गवर्नेंस लीड	मास्टर डेटा की गुणवत्ता और मानक
इंटीग्रेशन लीड	मिडलवेयर, API, सिस्टमों के बीच डेटा फ़्लो
सपोर्ट लीड	समस्या समाधान, निरंतर सुधार
SAP रिलेशनशिप ओनर (RISE)	SAP को एस्केलेशन, सर्विस रिव्यू, रोडमैप अलाइनमेंट

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

एक क्लाइंट ने अपने CoE बजट का 10% लगातार सीखने में लगाया। तीन साल बाद वह ऐसे नए फ़ीचर लागू कर रहा था जिन्हें उसके प्रतिस्पर्धी छू भी नहीं सकते थे। काम करता हुआ CoE ऐसा दिखता है।

योजना ठोस दिखने पर भी SAP इम्प्लीमेंटेशन टीमें फेल क्यों होती हैं?

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

किसी भी SAP इम्प्लीमेंटेशन में कौन-से रोल अनिवार्य हैं?

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

RISE with SAP के लिए टीम के डिज़ाइन में क्या बदलता है?

SAP इंफ़्रास्ट्रक्चर और तकनीकी संचालन चलाता है, इसलिए आप SAP के असाइन किए संपर्कों के साथ काम करते हैं, जैसे Client Delivery Manager या Cloud Architect Advisor। उन्हें रोस्टर में रखें और अपनी तरफ़ से रिश्ते का ओनर तय करें। Clean-core का स्वामित्व भी साफ़ होना चाहिए: बड़े प्रोग्राम में एक समर्पित आर्किटेक्ट, या मिड-मार्केट में सॉल्यूशन आर्किटेक्ट।

SAP प्रोजेक्ट टीम में कर्मचारी रखें या कंसल्टेंट?

दोनों। कर्मचारी वह बिज़नेस संदर्भ लाते हैं जिसे कंसल्टेंट जल्दी नहीं दोहरा सकते। कंसल्टेंट इम्प्लीमेंटेशन के पैटर्न पहचानने का वह अनुभव लाते हैं जो कर्मचारियों में आम तौर पर नहीं होता। हर कंसल्टेंट को एक आंतरिक समकक्ष के साथ जोड़ें, जो go-live के बाद उस क्षेत्र का मालिक होगा, ताकि कंसल्टेंट के जाने के बाद भी ज्ञान टिके। जो कंपनियाँ यह छोड़ देती हैं, वे अक्सर वह सपोर्ट सालों तक खरीदती रहती हैं जो उन्हें खुद संभालना चाहिए था।

SAP CoE बनाना कब शुरू करना चाहिए?

इम्प्लीमेंटेशन के दौरान, आदर्श रूप से पहले महीनों से। आपके सबसे अच्छे CoE सदस्य आम तौर पर आपके सबसे मज़बूत इम्प्लीमेंटेशन योगदानकर्ता होते हैं, और अगर आप go-live तक रुके, तो उनकी पहचान होने से पहले ही वे आगे बढ़ चुके होते हैं। एक मैन्युफ़ैक्चरिंग क्लाइंट ने इंतज़ार किया और go-live के तीन महीने बाद अपने मुख्य कॉन्फ़िगरेशन विशेषज्ञ खो दिए, और जो बना था उसे बनाए रखना किसी को नहीं आता था।

2026 में AI SAP टीम के डिज़ाइन को कैसे बदलता है?

SAP Joule for Consultants, SAP Build Code और Microsoft Copilot जैसे टूल वर्कफ़्लो-भारी रोल की उत्पादकता बढ़ाते हैं, बशर्ते लोग उन्हें लगातार इस्तेमाल करें। इन टूल्स से पहले उसी स्कोप को जितनी टीम चाहिए थी, अब टीम कुछ छोटी है, पर नाटकीय रूप से नहीं। टूल्स को रोल की परिभाषा में शामिल करें, और जवाबदेही इंसानों के पास रखें: AI ड्राफ़्ट तेज़ बनाता है, ड्राफ़्ट में क्या लिखा है, उसकी ज़िम्मेदारी अब भी इंसान की है।