प्रभावी SAP प्रोजेक्ट स्टीयरिंग कमेटी कैसे बनाएँ

SAP प्रोजेक्ट स्टीयरिंग कमेटी एग्ज़िक्यूटिव्स का वह छोटा समूह है जो वे फ़ैसले करता है जो प्रोजेक्ट टीम नहीं कर सकती: बजट, स्कोप में बदलाव, विभागों के बीच टकराव और आख़िरी go/no-go। यह तब काम करती है जब सदस्यों के पास असली अधिकार हो, वे इतनी बार मिलें कि फ़ैसला मीटिंग में ही हो जाए, और तैयारी को कैलेंडर के बजाय सबूत के आधार पर परखें। यह गाइड उन स्पॉन्सर और प्रोग्राम डायरेक्टरों के लिए है जो कमेटी बना रहे हैं या ऐसी कमेटी को ठीक कर रहे हैं जो स्टेटस रिपोर्ट की श्रोता बनकर रह गई है। इसमें कमेटी को क्या तय करना चाहिए, प्रोजेक्ट के आकार के हिसाब से सदस्य, फ़ैसले कैसे होने चाहिए, go/no-go चेकलिस्ट, और RISE with SAP तथा AI टूल क्या बदलते हैं, यह सब शामिल है।

मैंने कमज़ोर स्टीयरिंग कमेटी के साथ कोई SAP प्रोजेक्ट कामयाब होते नहीं देखा। मुश्किल फ़ैसले कमेटी में ही होते हैं। या तो वे उसी वक़्त हो जाते हैं, या जमा होते रहते हैं और cutover पर फट पड़ते हैं।

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

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

एक कमेटी ने नेतृत्व किया। दूसरी मीटिंगों में बैठी रही।

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

काम	अच्छा क्या दिखता है	कमज़ोर क्या दिखता है
बड़े फ़ैसले	मामला देखती है और मौके पर फ़ैसला करती है	“चलिए इस पर अलग से बात कर लेते हैं”; मुद्दा अगले महीने लौट आता है
रुकावटें	HR टेस्टिंग में देरी कर रहा है? चेयर सीधे विभाग प्रमुख को फ़ोन करता है	समस्या मान लेती है और लॉग कर देती है
स्कोप	हर चेंज रिक्वेस्ट को प्लान के सामने तौलती है	जो सबसे ज़ोर से एस्केलेट हो, उसी पर मुहर लगा देती है
जोखिम	किसी वेंडर को जूझता देखती है और देरी आने से पहले बैकअप तैयार कर लेती है	इंतज़ार करती है कि शायद अपने आप सुलझ जाए
बजट	तीन महीने बढ़ाने के लिए अतिरिक्त $2M मंज़ूर करती है क्योंकि व्यवधान की कीमत ज़्यादा होती	इसे अगले महीने पर टाल देती है
Go/no-go	टेस्टिंग पूरी न होने पर go-live छह हफ़्ते टाल देती है और अपनी बात पर टिकी रहती है	go-live मंज़ूर कर देती है क्योंकि तारीख कैलेंडर में है

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

सदस्य बहुत ज़्यादा हों तो कमेटी फ़ैसला नहीं कर पाती। बहुत कम हों तो ज़रूरी आवाज़ें छूट जाती हैं।

प्रोजेक्ट का आकार	बजट और स्कोप	सदस्य	मीटिंग में कौन होना चाहिए
छोटा	$0.5M से कम, एक विभाग, 6 महीने से कम	3 से 5	विभाग प्रमुख, IT लीड, फ़ाइनेंस प्रतिनिधि
मिड-मार्केट	$0.5M से $5M, कई विभाग, 6 से 18 महीने	5 से 8	प्रभावित विभागों के बिज़नेस लीड, IT नेतृत्व, फ़ाइनेंस
एंटरप्राइज़	$5M से ज़्यादा, पूरे उद्यम में, 18 महीने या अधिक	8 से 12	फ़ाइनेंस, HR, ऑपरेशंस और IT के C-level; प्रोग्राम मैनेजर; चेंज लीड

जो नियम मैं लागू करता हूँ: उन लोगों को शामिल कीजिए जिनके पास फ़ैसले का असली अधिकार हो। मैंने ऐसी कमेटियाँ नाकाम होते देखी हैं जिनमें वरिष्ठ पदनाम वाले लोग किसी और से पूछे बिना कुछ मंज़ूर नहीं कर सकते थे। अगर CFO नहीं आ सकते, तो ऐसे व्यक्ति को भेजिए जिसके पास फ़ैसला करने का असली अधिकार हो, रिपोर्ट लेकर लौटने का नहीं।

चेयर प्रोजेक्ट स्पॉन्सर होना चाहिए, आम तौर पर कोई C-level एग्ज़िक्यूटिव जो दूसरे एग्ज़िक्यूटिव्स को जवाबदेह ठहरा सके। कमेटी की अध्यक्षता करने वाला मिड-लेवल मैनेजर CFO को ओवररूल नहीं कर सकता, और स्कोप या बजट पर टकराव सामने आने पर यह अधिकार मायने रखता है।

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

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

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

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

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

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

कमेटी को सिस्टम दिखाइए। एक फ़ार्मास्यूटिकल क्लाइंट की कमेटी ने “दिन की एक झलक” परिदृश्य से गुज़रकर देखा। उसे समझ आया कि मंज़ूर डिज़ाइन से स्टाफ़ को एक आम प्रक्रिया के लिए पाँच अलग स्क्रीन इस्तेमाल करनी पड़ेंगी। उसने तुरंत रीडिज़ाइन का आदेश दिया।

राजनीति के लिए योजना बनाइए। सबसे आम नाकामी अयोग्यता नहीं है। वह विभागों का अपना इलाका बचाना और साल-अंत के काम की वजह से टीमों का टेस्टिंग टालना है। एक प्रोजेक्ट में HR साल-अंत के कामों में व्यस्त होने की वजह से पेरोल टेस्टिंग टालता रहा। कमेटी ने काम की प्राथमिकताएँ दोबारा तय कीं और बैकअप टेस्टर लगाए, और प्रोजेक्ट महीनों खिसकने के बजाय पटरी पर रहा।

बड़े गेट पर स्वतंत्र जाँच कीजिए। एक मैन्युफ़ैक्चरिंग क्लाइंट ने go-live मंज़ूर करने से पहले बाहरी समीक्षकों से अपनी तैयारी का मूल्यांकन करवाया। समीक्षा में कई गंभीर समस्याएँ मिलीं जिन्हें प्रोजेक्ट टीम ने नज़रअंदाज़ किया था या हल्का करके आँका था। मेरी SAP क्वालिटी गेट की गाइड दिखाती है कि ऐसे चेकपॉइंट कैसे बनाए जाएँ।

go-live मंज़ूर करने का आधार कैलेंडर का दबाव नहीं होना चाहिए। वोट से पहले कमेटी को इनमें से हर बिंदु पर सबूत दिखना चाहिए:

1. इंटीग्रेशन और यूज़र एक्सेप्टेंस टेस्टिंग पूरी, कोई क्रिटिकल डिफ़ेक्ट खुला नहीं
2. आख़िरी मॉक डेटा माइग्रेशन रिकॉन्साइल हुआ और फ़ाइनेंस ने साइन किया
3. cutover रिहर्सल तय विंडो के भीतर पूरा हुआ
4. की-यूज़र ट्रेन्ड, फ़्लोर सपोर्ट और जॉब एड तैयार
5. हर प्रोसेस ओनर की ओर से बिज़नेस रेडीनेस लिखित में पुष्ट
6. रोलबैक प्लान टेस्ट हुआ और सहमत
7. हाइपरकेयर टीम, एस्केलेशन पाथ और पहले क्लोज़ का सपोर्ट तैयार

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

RISE, SAP को गवर्नेंस मॉडल में ले आता है। RISE with SAP पर SAP इंफ्रास्ट्रक्चर और तकनीकी ऑपरेशंस चलाता है। SAP के RISE roles and responsibilities दस्तावेज़ में ग्राहक SAP Cloud Architect Advisor, Client Delivery Manager या SAP के प्राइवेट क्लाउड कस्टमर सेंटर के साथ काम करते हैं। परफ़ॉर्मेंस, उपलब्धता या सर्विस लेवल जैसे प्लेटफ़ॉर्म मुद्दों के लिए कमेटी को उन कॉन्टैक्ट तक एक ऐसा रास्ता चाहिए जो इम्प्लीमेंटेशन पार्टनर से होकर न गुज़रे। उन्हें स्थायी सदस्य के रूप में नहीं, संबंधित एजेंडा बिंदुओं के लिए बुलाइए।

clean-core फ़ोरम कमेटी के नीचे होना चाहिए। RISE प्रोग्राम में एक डिज़ाइन अथॉरिटी बनाइए जो clean-core सिद्धांतों के हिसाब से कस्टमाइज़ेशन रिक्वेस्ट मंज़ूर या अस्वीकार करे। वह कमेटी को तभी एस्केलेट करे जब कोई बिज़नेस-क्रिटिकल रिक्वेस्ट अटक जाए। इस परत के बिना हर कस्टमाइज़ेशन कमेटी की लड़ाई बन जाता है। ऑन-प्रेम में पारंपरिक मॉडल ही लागू रहता है और SAP एक वेंडर है, भागीदार नहीं।

1. स्टीयरिंग कमेटीस्पॉन्सर की अध्यक्षता में। बजट, स्कोप, टकराव, go/no-go
   SAP डिलीवरी कॉन्टैक्टप्लेटफ़ॉर्म मुद्दों के लिए बुलाए जाते हैं, पार्टनर के ज़रिए नहीं

• प्रोग्राम मैनेजमेंट ऑफ़िसरोज़ का क्रियान्वयन, रिस्क लॉग, समन्वय
• Clean-core डिज़ाइन अथॉरिटीकस्टमाइज़ेशन पर फ़ैसला, सिर्फ़ अटकी क्रिटिकल रिक्वेस्ट एस्केलेट करती है

AI कागज़ी काम में समय बचाता है। Microsoft 365 Copilot रिकॉर्ड की गई मीटिंग से मिनट्स का ड्राफ़्ट बनाता है। काम शुरू से लिखने की जगह ड्राफ़्ट की समीक्षा बन जाता है, और फ़ैसले ट्रांसक्रिप्ट से आते हैं। टेम्पलेट बन जाने के बाद Atlassian का Rovo मीटिंग नोट्स को स्ट्रक्चर्ड डिसीज़न-लॉग एंट्री में बदल सकता है। SAP Cloud ALM में Joule-आधारित असिस्टेंट स्कोप रिक्वेस्ट के लिए पहला इम्पैक्ट असेसमेंट ड्राफ़्ट कर सकते हैं, ताकि कमेटी टालने के बजाय मीटिंग में ही फ़ैसला कर सके।

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

SAP प्रोजेक्ट में स्टीयरिंग कमेटी की भूमिका क्या है?

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

SAP स्टीयरिंग कमेटी में कितने लोग होने चाहिए?

छोटे, एक विभाग वाले प्रोजेक्ट के लिए तीन से पाँच; मिड-मार्केट के लिए पाँच से आठ; एंटरप्राइज़ प्रोग्राम के लिए आठ से बारह। आम नाकामी बहुत ज़्यादा लोग होना है: 20 लोगों की कमेटी प्रेज़ेंटेशन की श्रोता बन जाती है। हर सदस्य के पास किसी न किसी चीज़ पर फ़ैसले का असली अधिकार होना चाहिए। RISE पर, SAP के डिलीवरी कॉन्टैक्ट को स्थायी सदस्य के रूप में नहीं, प्लेटफ़ॉर्म मुद्दों के लिए बुलाइए।

RISE with SAP स्टीयरिंग कमेटी को कैसे बदलता है?

SAP इंफ्रास्ट्रक्चर और तकनीकी ऑपरेशंस के लिए डिलीवरी भागीदार बन जाता है, इसलिए कमेटी को SAP के तय कॉन्टैक्ट तक सीधा रास्ता चाहिए जो इम्प्लीमेंटेशन पार्टनर से होकर न गुज़रे। उसके नीचे कस्टमाइज़ेशन रिक्वेस्ट संभालने के लिए एक clean-core डिज़ाइन अथॉरिटी भी चाहिए, जिसमें सिर्फ़ अटकी हुई बिज़नेस-क्रिटिकल रिक्वेस्ट ऊपर जाएँ। ऑन-प्रेम में SAP वेंडर ही रहता है।

स्टीयरिंग कमेटी और PMO में क्या फ़र्क है?

प्रोजेक्ट मैनेजमेंट ऑफ़िस रोज़ का क्रियान्वयन चलाता है: टास्क, रिस्क लॉग और वर्कस्ट्रीम के बीच समन्वय। स्टीयरिंग कमेटी वे फ़ैसले करती है जो PMO नहीं कर सकता: बजट में फेरबदल, स्कोप में बदलाव और go/no-go। बड़े संगठनों में पोर्टफ़ोलियो-स्तर की कमेटी कई प्रोजेक्ट के ऊपर बैठती है और उनके बीच संसाधन बाँटती है।

स्टीयरिंग कमेटी के एजेंडा में क्या होना चाहिए?

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

स्टीयरिंग कमेटी को go-live कब टालना चाहिए?

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