SAP प्रोजेक्ट प्लानिंग और कंट्रोल: प्रोजेक्ट को पटरी पर रखें

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

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

छठे महीने तक आधा प्रोजेक्ट शेड्यूल से पीछे था और हम अपनी ही गलतियों के पीछे दौड़ रहे थे। सबसे बुरी बात यह थी कि किसी ने इसे आते नहीं देखा।

यह प्लानिंग की समस्या नहीं थी। यह कंट्रोल की समस्या थी। न रिसोर्स का असली आवंटन था, न जोखिम घटाने का ठीक इंतज़ाम, न एस्केलेशन का कोई रास्ता। प्लान एक बार बना और फिर बैठकों के चक्कर में छोड़ दिया गया।

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

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

1. 01प्रगति ट्रैक करेंवर्क पैकेज के हिसाब से असल बनाम प्लान
2. 02अंतर सामने लाएँकोई भी टास्क तीन दिन लेट हो
3. 03डिपेंडेंसी जाँचेंयह फिसला तो कौन अटकेगा
4. 04एस्केलेट करेंपहले से तय रास्ते पर
5. 05बदलावों का आकलन करेंपहले समय, लागत और रिसोर्स
6. 06री-बेसलाइन करेंऔपचारिक बदलाव के बाद ही

हर हफ़्ते, नामित ज़िम्मेदारों के साथ

कंट्रोल न हो तो यह सब टूटता है:

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

ये सार्वजनिक मामले हैं, क्लाइंट की कहानियाँ नहीं। इनके मूल कारण वही हैं जो मैं सलाहकार के काम में बार-बार देखता हूँ।

Lidl: लगभग सात साल और अनुमानित €500 मिलियन, फिर प्रोजेक्ट बंद

Lidl ने 2011 में SAP Retail पर अपना eLWIS प्रोजेक्ट शुरू किया। उसकी इन्वेंटरी वैल्यूएशन की पद्धति SAP के मानक मॉडल से अलग थी, और Lidl ने पद्धति बदलने के बजाय सॉफ़्टवेयर को ढालना चुना। 2018 तक सिस्टम ऑस्ट्रिया, नॉर्दर्न आयरलैंड और अमेरिका में live था, पर बोर्ड इस नतीजे पर पहुँचा कि मूल लक्ष्य वाजिब लागत पर हासिल नहीं हो सकते। Lidl ने प्रोजेक्ट रोक दिया और अपने इन-हाउस सिस्टम का विकास फिर शुरू किया। ट्रेड प्रेस ने खर्च का अनुमान लगभग €500 मिलियन लगाया, और IT बोर्ड सदस्य 2017 में ही जा चुके थे। Heise ने यह फ़ैसला रिपोर्ट किया जुलाई 2018 में। सबक: पुरानी पद्धति को बचाने के लिए सालों तक कस्टमाइज़ेशन करना कंट्रोल की विफलता है, सॉफ़्टवेयर की नहीं।

Hershey: लगभग $100 मिलियन के हैलोवीन ऑर्डर नहीं पहुँचे

Hershey का नया SAP, Siebel और Manugistics सिस्टम अप्रैल 1999 में live होना तय था, जो कन्फ़ेक्शनरी के लिए शांत महीना है। यह तीन महीने खिसककर जुलाई में live हुआ, ठीक तब जब हैलोवीन के ऑर्डर आने शुरू हुए। ऑर्डर सिस्टम से वेयरहाउस तक पहुँच नहीं पा रहे थे। CEO ने एनालिस्टों से कहा कि इन समस्याओं की वजह से Hershey हैलोवीन के लिए लगभग $100 मिलियन का माल नहीं पहुँचा पाएगा, और तीसरी तिमाही की बिक्री 12.4% गिरी। CIO मैगज़ीन का ब्योरा असली विफलता की वजह टाइमिंग को ठहराता है। पीक सीज़न को बचाने वाला शेड्यूल कंट्रोल एक अलग go-live तारीख़ के लिए मजबूर करता।

Revlon: एक प्लांट में बाधा और कंट्रोल में मटीरियल वीकनेस

Revlon ने फ़रवरी 2018 में ऑक्सफ़ोर्ड, नॉर्थ कैरोलिना के प्लांट में, जो उसकी सबसे बड़ी मैन्युफ़ैक्चरिंग साइट है, SAP चालू किया। सर्विस में आई बाधाओं ने मैन्युफ़ैक्चरिंग और अमेरिका के बड़े रिटेलरों को होने वाले शिपमेंट को प्रभावित किया। मार्च 2019 में Revlon ने रोलआउट से जुड़ी इंटर्नल कंट्रोल में एक मटीरियल वीकनेस का खुलासा किया, जिसमें उसने प्रभावी निरंतर जोखिम आकलन के न होने और प्रभावित ऑपरेशनों में प्रशिक्षित लोगों की कमी का हवाला दिया। निवेशकों ने मुकदमा किया। TechTarget ने मुकदमे को कवर किया, जिसमें दावा था कि लगभग $64 मिलियन के शिपमेंट पूरे नहीं हुए।

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

वर्क ब्रेकडाउन स्ट्रक्चर

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

मूल्य दस्तावेज़ में नहीं है। यह उस बातचीत को मजबूर करता है कि क्या होना है, कौन करेगा और वह किस पर निर्भर है। प्रोजेक्ट को डिपेंडेंसी ही मारती हैं। डेटा माइग्रेशन में देरी इंटीग्रेशन टेस्टिंग को रोकती है, जो UAT को रोकती है, जो कटओवर की खिड़की को सिकोड़ती है। WBS उस कड़ी को दिखाई देने लायक बना देता है।

शेड्यूल मैनेजमेंट

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

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

go-live की टाइमिंग को अलग फ़ैसले की तरह लीजिए। पीक बिज़नेस अवधि में कभी go-live न करें। Hershey का सबक हर कंपनी पर लागू होता है।

बजट कंट्रोल

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

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

जोखिम प्रबंधन

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

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

संवाद और एस्केलेशन

एक्ज़ीक्यूटिव को हेडलाइन चाहिए। डिलीवरी टीमों को ब्योरा चाहिए। प्रोजेक्ट मैनेजरों को वेरिएंस का डेटा चाहिए। सबके लिए एक ही अपडेट किसी के काम नहीं आता।

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

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

ऑन-प्रिमाइस प्लेबुक RISE with SAP में बिना बदलाव के नहीं चलती। तीन चीज़ें अलग हैं।

RISE बदलता है कि आप किसे एस्केलेट करते हैं

RISE with SAP के तहत SAP इन्फ्रास्ट्रक्चर और तकनीकी संचालन चलाता है और एक कस्टमर सक्सेस टीम देता है जो एडॉप्शन ट्रैक करती है। आपके कंट्रोल स्ट्रक्चर में उन्हें शामिल होना चाहिए। प्लैटफ़ॉर्म के मुद्दों (सिस्टम परफ़ॉर्मेंस, हाइपरस्केलर रीजन, SAP सर्विस लेवल) के लिए प्रोग्राम मैनेजर के पास SAP तक एस्केलेशन का एक दस्तावेज़ी रास्ता होना चाहिए जो इम्प्लीमेंटेशन पार्टनर से होकर न गुज़रे। ज़रूरत पड़ने से पहले इसे लिख लीजिए।

Clean Core स्कोप कंट्रोल को तकनीकी सहारा देता है

अब हर गैप पर एक फ़ैसला चाहिए: उसे कॉन्फ़िगर करें, रिलीज़्ड API के ज़रिए एक्सटेंड करें (ABAP Cloud के साथ on-stack या SAP BTP पर side-by-side), या अस्वीकार करें। S/4HANA Cloud Public Edition में कोर को बदलना विकल्प ही नहीं है। प्राइवेट एडिशन और ऑन-प्रिमाइस में यह संभव है, पर SAP की clean-core गाइडेंस इसे आख़िरी उपाय मानती है, क्योंकि हर बदलाव अपग्रेड का काम बढ़ाता है।

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

AI रिपोर्ट के ड्राफ़्ट बनाता है, फ़ैसले लोग लेते हैं

AI अब कंट्रोल के कागज़ी काम में मदद करता है। SAP Cloud ALM, SAP का एप्लिकेशन लाइफ़साइकिल टूल, प्रोजेक्ट टास्क, रिक्वायरमेंट और टेस्ट स्टेटस रखता है और वर्कशॉप ट्रांसक्रिप्ट से रिक्वायरमेंट के ड्राफ़्ट बना सकता है। Microsoft Copilot डैशबोर्ड और स्टेटस रिपोर्ट से स्टीयरिंग पैक के लिए वेरिएंस सारांश के ड्राफ़्ट बनाता है। Power BI या SAP Analytics Cloud में एनोमली डिटेक्शन उन KPI को चिह्नित करता है जो अपने सामान्य पैटर्न से हट जाते हैं। यह रिसोर्स उपयोग, चेंज रिक्वेस्ट की संख्या और सपोर्ट टिकट के लिए उपयोगी है, उन मेट्रिक के लिए कम जो स्वाभाविक रूप से ऊपर-नीचे होते हैं।

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

सक्रिय डिलीवरी में चल रहे प्रोग्राम के लिए यह न्यूनतम लय है। अगर कोई भी पंक्ति गायब है, तो और कुछ करने से पहले उसे जोड़िए।

कंट्रोल	न्यूनतम अभ्यास	ज़िम्मेदार	आवृत्ति
वर्क ब्रेकडाउन स्ट्रक्चर	हर टास्क का एक ज़िम्मेदार, एक ड्यू डेट और उसकी डिपेंडेंसी	PMO लीड	हर हफ़्ते अपडेट
शेड्यूल रिव्यू	तीन दिन से ज़्यादा लेट हर टास्क को चिह्नित करें; क्रिटिकल पाथ जाँचें	प्रोग्राम मैनेजर	साप्ताहिक
बजट ट्रैकिंग	वर्क पैकेज के हिसाब से प्लान के मुकाबले असल खर्च	प्रोग्राम फ़ाइनेंस लीड	साप्ताहिक, रिपोर्ट मासिक
रिस्क रिव्यू	हर सक्रिय जोखिम का एक ज़िम्मेदार, एक ट्रिगर और एक रिस्पॉन्स	वर्कस्ट्रीम लीड	साप्ताहिक
चेंज कंट्रोल	मंज़ूरी से पहले समय, लागत और रिसोर्स पर इम्पैक्ट आकलन	चेंज बोर्ड चेयर	साप्ताहिक या अनुरोध आने पर
एक्सटेंशन रिव्यू (RISE और GROW)	हर गैप के लिए कॉन्फ़िगर, एक्सटेंड या अस्वीकार का फ़ैसला	सॉल्यूशन आर्किटेक्ट	हर दो हफ़्ते में
स्टीयरिंग कमेटी	स्टेटस नहीं, फ़ैसले; पेपर पहले से भेजे जाएँ	एक्ज़ीक्यूटिव स्पॉन्सर	हर दो हफ़्ते में; कटओवर और हाइपरकेयर में साप्ताहिक

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

प्रोजेक्ट प्लानिंग और प्रोजेक्ट कंट्रोल में क्या अंतर है?

प्लानिंग रोडमैप तैयार करती है: स्कोप, टाइमलाइन, बजट, रिसोर्स और जोखिम। यह शुरुआत में दिशा तय करती है।

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

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

प्रोजेक्ट प्लान होने के बावजूद SAP प्रोजेक्ट फेल क्यों होते हैं?

क्योंकि प्लान पर कोई काम नहीं करता। डिपेंडेंसी ट्रैक नहीं होतीं, इसलिए एक वर्कस्ट्रीम की देरी चुपचाप दूसरे को रोक देती है। रिस्क लॉग तिमाही में अपडेट होते हैं। स्कोप बदलाव अनौपचारिक रूप से मंज़ूर हो जाते हैं। स्टीयरिंग कमेटी महीने में एक बार मिलती है और माइलस्टोन के ऐसे सारांश देखती है जो ज़मीन पर हो रही चीज़ों को छिपा लेते हैं।

Lidl, Hershey और Revlon सबके पास प्लान थे। जो नहीं था, वह था सक्रिय कंट्रोल: ईमानदार ट्रैकिंग, जल्दी एस्केलेशन और चेतावनी के संकेत दिखने पर असली कार्रवाई।

लंबे SAP प्रोग्राम में स्कोप क्रीप को कैसे सँभालूँ?

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

सबसे असरदार नियम: कोई भी जोड़ किसी और चीज़ को हटाकर ही आए। यह एक बंदिश बिज़नेस लीड को ईमानदारी से प्राथमिकता तय करने पर मजबूर करती है।

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

वर्क ब्रेकडाउन स्ट्रक्चर क्या है और SAP के लिए यह क्यों मायने रखता है?

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

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

RISE with SAP प्रोजेक्ट प्लानिंग और कंट्रोल को कैसे बदलता है?

SAP डिलीवरी में भागीदार बन जाता है। वह इन्फ्रास्ट्रक्चर और तकनीकी संचालन चलाता है, और उसकी कस्टमर सक्सेस टीम एडॉप्शन और वैल्यू पर अपनी कैडेंस चलाती है।

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

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

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

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