SAP इम्प्लीमेंटेशन में स्कोप क्रीप से कैसे बचें

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

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

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

ये अपवाद नहीं हैं। SAP प्रोग्राम के नाकाम होने का यही सबसे आम तरीका है।

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

मैंने एक रिटेल क्लाइंट के साथ काम किया जहाँ हमने साफ़ शुरुआत की थी: कोर Finance और बेसिक Materials Management। छह महीने बाद CMO को कस्टमर एनालिटिक्स चाहिए था। फिर COO को एडवांस्ड वेयरहाउस फ़ंक्शन चाहिए थे। मूल नौ महीने की समय-सीमा ख़तरे में थी। मैंने ज़ोर देकर मना किया और दोनों अनुरोध ठुकरा दिए। यह अनुशासन ही असल काम है।

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

एक मैन्युफ़ैक्चरिंग क्लाइंट ने 10 कस्टम रिपोर्ट से शुरुआत की और 47 पर पहुँचा, और हर रिपोर्ट ने डिज़ाइन, बिल्ड और टेस्ट का समय बढ़ाया। अकेले रिपोर्टिंग वर्कस्ट्रीम बजट से 200% ऊपर चली गई।

200%

स्कोप के भटकाव से कस्टम रिपोर्ट 10 से 47 होने के बाद रिपोर्टिंग वर्कस्ट्रीम के बजट में ओवररन

स्रोत: मैन्युफ़ैक्चरिंग क्लाइंट का प्रोग्राम

चेतावनी के संकेत

ये वे संकेत हैं जिन पर मैं नज़र रखता हूँ, और हर एक का जवाब:

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

सब कुछ आपस में जुड़ा है

SAP सब कुछ आपस में बाँध देता है। फ़ाइनेंस सप्लाई चेन को प्रभावित करता है। HR पेरोल को छूता है। सेल्स इन्वेंटरी से जुड़ा है। एक बदलाव दस चीज़ें तोड़ सकता है।

एक क्लाइंट ने अपनी पर्चेज़ ऑर्डर प्रक्रिया में एक अकेला फ़ील्ड जोड़ा। वह मामूली लगता था। उसने तीन इंटरफ़ेस तोड़ दिए और विभागों भर में रिपोर्ट दोबारा लिखनी पड़ीं। एक और क्लाइंट ने अपनी प्राइसिंग प्रक्रिया में “छोटा-सा बदलाव” माँगा, जिसके लिए पूरे प्राइसिंग ढाँचे को दोबारा कॉन्फ़िगर करना पड़ा: तीन हफ़्ते का काम और $40,000 की कंसल्टिंग फ़ीस, एक छोटे-से बदलाव के लिए।

दशक में एक बार वाला दबाव

ज़्यादातर कंपनियाँ हर 10 से 15 साल में एक बार SAP लागू करती हैं। हर विभाग जानता है कि उसे एक दशक तक दूसरा मौका नहीं मिलेगा। कोई “फ़ेज़ 2” नहीं सुनना चाहता, जिसका ज़्यादातर संगठनों में मतलब होता है कभी नहीं। इसलिए सब कुछ मौजूदा प्रोजेक्ट में ठूँस दिया जाता है, और स्कोप की सूची इच्छाओं की सूची बन जाती है।

Clean Core से क्या बदलता है

Clean Core कस्टमाइज़ेशन पर तकनीकी ब्रेक लगाता है। S/4HANA Cloud Public Edition में कोर में बदलाव करना संभव नहीं है: एक्सटेंशन रिलीज़्ड API के रास्ते जाते हैं, on-stack या SAP BTP पर side-by-side। Private Edition और on-premise में बदलाव अब भी संभव है, लेकिन SAP का मार्गदर्शन इसे आख़िरी उपाय मानता है क्योंकि हर बदलाव अपग्रेड का काम बढ़ाता है।

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

1. स्कोप को साफ़ एक्सक्लूज़न के साथ परिभाषित करें। जो स्कोप से बाहर है उसे उतनी ही सावधानी से दर्ज करें जितना जो अंदर है, और दोनों पर साइन-ऑफ़ लें। बहस वहीं से शुरू होती है जहाँ अस्पष्टता है।
2. नतीजों वाला औपचारिक चेंज कंट्रोल चलाएँ। हर बदलाव के साथ लागत, समय और गुणवत्ता पर इम्पैक्ट असेसमेंट होना चाहिए, जो मंज़ूरी देने वाले को दिखे।
3. हर स्टीयरिंग मीटिंग में स्कोप की सीमाएँ बताएँ। स्कोप की स्थिति एक सरल लाल, पीले, हरे व्यू में दिखाएँ। बहुत-सा भटकाव ग़लतफ़हमी से होता है।
4. स्कोप मैनेजमेंट प्लान लिखें। तय करें कि बदलावों का आकलन, मंज़ूरी, एस्केलेशन और ट्रैकिंग कैसे होगा, ताकि हर वर्कस्ट्रीम उन्हें एक ही तरीके से संभाले। मेरा SAP प्रोजेक्ट स्कोप टेम्प्लेट शुरुआती ढाँचा देता है।
5. MoSCoW से प्राथमिकता तय करें। ज़रूर चाहिए (Must have), होना चाहिए (Should have), हो सके तो (Could have), इस बार नहीं (Won't have this time)। Must have की सूची छोटी रखने के लिए पूरा ज़ोर लगाइए।
6. हर फ़ैसले का वर्ज़न कंट्रोल रखें। हर मंज़ूर बदलाव बेसलाइन को अपडेट करता है। हर अस्वीकृत बदलाव कारण के साथ दर्ज होता है।
7. ट्रेड-ऑफ़ ज़रूरी करें। नई ज़रूरत आए तो कुछ और बाहर जाए। जब Must-have की कोई कीमत चुकानी पड़ती है, तो वे जल्दी ही वैकल्पिक बन जाते हैं।

तीन तकनीकें, जो मैंने इस्तेमाल की हैं, इन्हें टिकाऊ बनाती हैं।

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

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

बदलाव की लागत दिखाइए। डिज़ाइन के दौरान किसी बदलाव की कीमत $5,000 हो सकती है। वही बदलाव टेस्टिंग में $50,000 का पड़ सकता है। इसका एक सीधा-सा चार्ट लोगों के सामने रख दीजिए, तो बेपरवाह अनुरोधों की रफ़्तार धीमी हो जाती है।

ये अमेरिकी बाज़ार में S/4HANA प्रोग्राम के लिए बदलाव की लागत की सांकेतिक रेंज हैं। ये जटिलता और पार्टनर के हिसाब से बदलती हैं। इन्हें आधार-बिंदु की तरह इस्तेमाल कीजिए, कोटेशन की तरह नहीं।

फ़ेज़	छोटे बदलाव की सामान्य लागत	मध्यम बदलाव की सामान्य लागत
Explore (डिज़ाइन)	$2K से $10K	$10K से $30K
Early Realize	$5K से $20K	$20K से $80K
Mid-Realize (बिल्ड)	$15K से $50K	$50K से $200K
Late Realize (टेस्ट)	$30K से $100K	$100K से $400K
Deploy और cutover	$80K से $300K	$300K से $1M+
Hypercare (go-live के बाद)	$150K से $500K	$500K से $2M+

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

वे कॉन्ट्रैक्ट क्लॉज़ जो मायने रखते हैं

अस्पष्ट कॉन्ट्रैक्ट महँगी समस्याएँ पैदा करते हैं। मैंने एक क्लाइंट को ऐसा कॉन्ट्रैक्ट साइन करते देखा है जिसमें बस इतना लिखा था: “S/4HANA लागू करना”। पार्टनर ने बाद में दावा किया कि कुछ ख़ास प्रोसेस ऐड-ऑन हैं जिनके लिए अतिरिक्त फ़ीस लगेगी, और क्लाइंट को दोगुना चुकाना पड़ा। ये क्लॉज़ ऐसा होने से रोकते हैं:

क्लॉज़	उद्देश्य
साफ़ एक्सक्लूज़न के साथ स्कोप	तय करता है कि फ़िक्स्ड प्राइस में क्या आता है और ऐड-ऑन को लेकर अस्पष्टता हटाता है
आम बदलावों के लिए पहले से तय दरें	दबाव आने से पहले रिपोर्ट, इंटरफ़ेस और कॉन्फ़िगरेशन बदलावों की कीमतें पक्की कर देता है
कंसल्टेंट की निरंतरता	नए कंसल्टेंट को तय हो चुके फ़ैसले दोबारा खोलने और स्कोप बढ़ाने से रोकती है
दोनों पक्षों में मंज़ूरी का अधिकार	जूनियर कंसल्टेंट को ऐसे फ़ीचर का वादा करने से रोकता है जिन्हें किसी ने अधिकृत नहीं किया
माइलस्टोन-आधारित बिलिंग	भुगतान को बीते समय से नहीं, साइन-ऑफ़ हुए डिलिवरेबल से जोड़ती है
हर डिलिवरेबल के लिए स्वीकृति मानदंड	बहस शुरू होने से पहले तय कर देते हैं कि “पूरा” का मतलब क्या है
Clean Core एक्सटेंशन क्लॉज़	एक्सटेंशन के लिए रिलीज़्ड API या SAP BTP का इस्तेमाल ज़रूरी करता है; पहले बड़े अपग्रेड पर दोबारा काम बचाता है

ERP कॉन्ट्रैक्ट नेगोशिएशन पर मेरे नोट्स बताते हैं कि इन क्लॉज़ पर सहमति कैसे बनाई जाए।

चेंज कंट्रोल बोर्ड

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

1. 01अनुरोध उठाया गयालिखित में, चाय पर नहीं
2. 02इम्पैक्ट असेसमेंटकिसी के मंज़ूर करने से पहले समय, लागत और गुणवत्ता
3. 03ट्रेड-ऑफ़ तयजगह बनाने के लिए कुछ और बाहर जाता है
4. 04चेंज बोर्ड का फ़ैसलामेज़ पर बिज़नेस, प्रोजेक्ट और फ़ाइनेंस
5. 05बेसलाइन अपडेटअस्वीकृत बदलाव कारण के साथ दर्ज

स्कोप सिर्फ़ बोर्ड के रास्ते से बदलता है

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

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

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

जब कोई जायज़ बदलाव आए, तो दो सवाल पूछिए। काम करने वाला सबसे छोटा हल क्या है? और माँगने वाले से: जगह बनाने के लिए आप क्या हटाने को तैयार हैं? जब अनुरोध की कोई कीमत चुकानी पड़ती है, तो जल्दबाज़ी तेज़ी से घट जाती है।

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

AI अब काग़ज़ी काम में मदद करता है। Microsoft Copilot जैसे असिस्टेंट चेंज रिक्वेस्ट के लंबे थ्रेड को बोर्ड के लिए फ़ैसले-लायक छोटे ब्रीफ़ में समेट देते हैं, और SAP Cloud ALM ज़रूरतों, बदलावों और टेस्ट को आपस में जोड़े रखता है ताकि किसी बदलाव का असर ढूँढना आसान हो। AI दिखा सकता है कि कोई बदलाव 14 क्षेत्रों को छूता है। वह COO से यह नहीं कह सकता कि उनके अनुरोध का मतलब है कि CFO का अनुरोध नहीं हो पाएगा। वह बातचीत अब भी आपकी ही है।

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

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

दोनों में से कोई तरीका जटिल नहीं है। दोनों को अनुशासन और नेतृत्व के समर्थन की ज़रूरत है। किसी भी स्कोप प्रक्रिया की परीक्षा उस दिन होती है जब COO “बस एक छोटा-सा बदलाव” लेकर प्रोजेक्ट रूम में आ जाएँ। इसे उसी दिन के लिए बनाइए।

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

समय-सीमा, बजट या संसाधनों में तालमेल वाले बदलाव किए बिना ज़रूरतों का धीरे-धीरे, बेकाबू बढ़ते जाना। SAP में यह आमतौर पर छोटे जोड़ से शुरू होता है: अतिरिक्त रिपोर्ट, अतिरिक्त फ़ील्ड, “बस एक छोटा-सा वर्कफ़्लो बदलाव”। हर एक मामूली लगता है। सब मिलकर महीनों जोड़ देते हैं।

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

SAP प्रोजेक्ट में स्कोप क्रीप की सबसे आम वजहें क्या हैं?

तीन वजहें लगातार सामने आती हैं: शुरुआती ज़रूरतों का अस्पष्ट होना, जिससे कुछ भी स्कोप के अंदर बताया जा सकता है; औपचारिक चेंज कंट्रोल का न होना, जिससे हर स्तर पर बदलाव घुस आते हैं; और दशक में एक बार वाली मानसिकता, जिसमें हर विभाग सालों की समस्याएँ इसी प्रोजेक्ट में सुलझाने की कोशिश करता है।

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

Clean Core स्कोप क्रीप के जोखिम को कैसे बदलता है?

यह एक तकनीकी ब्रेक जोड़ता है। S/4HANA Cloud Public Edition में कोर में बदलाव नहीं किया जा सकता, इसलिए हर कमी अपनी डिज़ाइन, बिल्ड और टेस्ट लागत वाला एक एक्सटेंशन बन जाती है। Private Edition और on-premise में बदलाव संभव है लेकिन अपग्रेड का काम बढ़ाता है, इसलिए SAP का मार्गदर्शन इसे हतोत्साहित करता है।

फ़ैसला करने का अधिकार रखने वाले एक आर्किटेक्ट के साथ एक एक्सटेंशन रिव्यू फ़ोरम कई अनुरोधों को बेसलाइन में आने से पहले ही रोक देता है। उस फ़ोरम के बिना on-premise प्रोग्राम पुरानी आदतों में लौट जाते हैं।

स्कोप क्रीप और गोल्ड-प्लेटिंग में क्या फ़र्क़ है?

स्कोप क्रीप बिज़नेस की तरफ़ से आता है: जो तय हुआ था उससे आगे के अनुरोध। गोल्ड-प्लेटिंग डिलीवरी टीम की तरफ़ से आती है: ऐसी जटिलता जो किसी ने माँगी ही नहीं थी।

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

ऐसा चेंज कंट्रोल प्रोसेस कैसे बनाएँ जो सच में काम करे?

तीन तत्व। हर अनुरोध के साथ समय-सीमा, बजट और संसाधनों पर इम्पैक्ट असेसमेंट हो। अप्रूवल बोर्ड में इन तीनों में से हर एक की परवाह करने वाला कोई हो, सिर्फ़ बिज़नेस लीड नहीं, जो सब कुछ मंज़ूर कर देंगे। और हर जोड़ के लिए ट्रेड-ऑफ़ ज़रूरी हो: कुछ और बाहर जाए।

अकेला यह आख़िरी नियम उन अनुरोधों को छाँट देता है जो सच में अहम नहीं हैं।

क्या स्कोप क्रीप से पूरी तरह बचा जा सकता है?

नहीं। कुछ महीनों से लंबे किसी भी प्रोग्राम में कारोबारी हालात बदलते हैं, नियम बदलते हैं और डिज़ाइन में कमियाँ सामने आती हैं।

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

लंबे SAP प्रोग्राम में स्कोप फ़्रीज़ को संभालने का सबसे अच्छा तरीका क्या है?

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

जब फ़्रीज़ के बाद हर बदलाव को CEO को निजी तौर पर मंज़ूर करना पड़ता है, तो सूची बहुत छोटी रहती है।