SAP प्रोजेक्ट स्कोप टेम्पलेट: क्या तय करें और क्या बाहर रखें

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

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

स्कोप दस्तावेज़ का काम यह दर्ज करना नहीं है कि कमरे में लोगों ने क्या कहा। उसका काम है कॉन्फ़िगरेशन से पहले ही स्पष्टता लाना, इससे पहले कि कॉन्फ़िगरेशन उन धारणाओं को पक्का कर दे जिन्हें पलटना महँगा पड़ता है।

ये नौ सेक्शन हैं, और हर एक को किस सवाल का जवाब देना है।

1. उद्देश्य

यह काम क्यों किया जा रहा है, और पूरा होने पर बिज़नेस को क्या दिखेगा? हर उद्देश्य को नापे जा सकने वाले नतीजे से जोड़िए: month-end close तीन दिन कम करना, तीन एंटिटी में मैन्युअल रिकंसिलिएशन ख़त्म करना, सभी प्लांट में इन्वेंटरी का एक ही व्यू। अस्पष्ट उद्देश्यों से अस्पष्ट सफलता के मानदंड बनते हैं, और असहमति यूज़र एक्सेप्टेंस टेस्टिंग (UAT) में सामने आती है।

2. स्कोप की परिभाषा

मॉड्यूल, लीगल एंटिटी, प्लांट, देश, भाषाएँ, इंटीग्रेशन और डिप्लॉयमेंट मॉडल। ठोस रहिए। “फ़ाइनेंस” स्कोप नहीं है। “S/4HANA Cloud Private Edition पर UAE की लीगल एंटिटी के लिए फ़ाइनेंशियल अकाउंटिंग और कंट्रोलिंग (FI/CO), जिसमें पेएबल्स, रिसीवेबल्स, जनरल लेजर और कॉस्ट सेंटर अकाउंटिंग शामिल हैं” स्कोप है।

3. स्कोप से बाहर की चीज़ें

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

1. बाद के फ़ेज़ के लिए टाले गए देश या एंटिटी।
2. लीगेसी इंटीग्रेशन, जिन्हें फ़िलहाल जैसे हैं वैसे ही रखा गया है।
3. तय कटऑफ़ तारीख़ से पहले का ऐतिहासिक डेटा।
4. वे रिपोर्ट जो go-live के बाद की एन्हांसमेंट लिस्ट में डाल दी गईं।
5. कानूनी पुष्टि के इंतज़ार में टाली गई रेगुलेटरी ज़रूरतें।

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

4. डेटा माइग्रेशन का स्कोप

यह लगातार नज़रअंदाज़ होने वाला हिस्सा है। तीन सवालों के जवाब लिखित में दीजिए:

1. क्या जाएगा? सिर्फ़ ओपन आइटम, या हिस्ट्री भी? सभी कस्टमर और वेंडर, या सिर्फ़ सक्रिय वाले? हर प्लांट के मटीरियल, या सिर्फ़ go-live वाली एंटिटी के?
2. कटऑफ़ के नियम क्या हैं? ओपन परचेज़, सेल्स और वर्क ऑर्डर के लिए as-of तारीख़, और कटओवर के समय जो आइटम प्रक्रिया में हैं उनका क्या होगा।
3. इसके बजाय क्या आर्काइव होगा? हिस्ट्री के लिए क़ानूनी रिटेंशन के नियम, और लीगेसी सिस्टम कितने समय तक पढ़ने लायक रहेगा।

यहाँ जिन धारणाओं को दर्ज नहीं किया जाता, वे बिल्ड के दौरान विवाद बन जाती हैं। प्लानिंग पर मेरा लेख SAP डेटा माइग्रेशन क्यों फ़ेल होता है विस्तार से बताता है।

5. नॉन-फ़ंक्शनल स्कोप

प्लानिंग में ये छूट जाते हैं और टेस्टिंग के आख़िर में रुकावट बनकर सामने आते हैं। इन्हें स्कोप में रखिए:

1. उपलब्धता और मेंटेनेंस विंडो। RISE में अपने कॉन्ट्रैक्ट की उपलब्धता की शर्तों का हवाला दीजिए।
2. पीक लोड पर परफ़ॉर्मेंस, जैसे month-end close।
3. ऑडिट लॉगिंग: किन ट्रांज़ैक्शन की, और लॉग कितने समय तक रखे जाएँगे।
4. रोल के हिसाब से सुरक्षा और एक्सेस कंट्रोल।
5. रिपोर्टिंग लेटेंसी: रियल टाइम, नियर रियल टाइम या रोज़ाना।

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

6. भूमिकाएँ और ज़िम्मेदारियाँ

हर वर्कस्ट्रीम में एक कंसल्टेंट लीड और फ़ैसले का अधिकार रखने वाला एक बिज़नेस काउंटरपार्ट चाहिए, दोनों नाम के साथ। सबसे ज़्यादा जो कमी मुझे दिखती है वह UAT की ओनरशिप में है: कौन साइन-ऑफ़ कर सकता है कि कोई प्रक्रिया टेस्ट होकर स्वीकार हो चुकी है? यह बिल्ड शुरू होने से पहले तय कीजिए, go-live से दो हफ़्ते पहले नहीं।

7. चेंज कंट्रोल

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

8. एक्सटेंशन के नियम

कस्टम डेवलपमेंट को मंज़ूरी कैसे मिलेगी। SAP अब एक्सटेंशन को लेवल A (सिर्फ़ released API) से लेकर लेवल D (कोर में बदलाव) तक वर्गीकृत करता है (SAP News, अगस्त 2025)। GROW के तहत Public Edition पर सिस्टम सिर्फ़ released इंटरफ़ेस की इजाज़त देता है। RISE के तहत Private Edition और on-premise में कोर में अब भी बदलाव किया जा सकता है, इसलिए स्कोप में लक्ष्य लेवल और अपवादों को मंज़ूरी देने वाले का नाम लिखा होना चाहिए। मेरी क्लीन कोर गाइड इन लेवल को समझाती है।

9. धारणाएँ और सीमाएँ

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

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

कुछ भी मंज़ूर करने से पहले हर माँग को वर्गीकृत कीजिए:

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

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

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

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

चेंज फ़्रीज़ के बाद नई माँगें go-live के बाद के बैकलॉग में जाती हैं

एनालिटिक्स वह जगह है जहाँ स्कोप की बातचीत गर्म हो जाती है। रिपोर्ट सबको चाहिए, पर कितनी, यह कोई नहीं बताता।

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

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

स्कोप की समीक्षा हर SAP Activate फ़ेज़ गेट पर और हर मंज़ूर बदलाव के बाद कीजिए, वर्ज़न नंबर और बदलावों की सूची के साथ। स्कोप का हवाला प्रोजेक्ट चार्टर में होना चाहिए, ताकि दोनों दस्तावेज़ एक ही कहानी कहें।

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

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

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

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

SAP प्रोजेक्ट में डेटा माइग्रेशन का स्कोप क्या होता है?

यह तय करना कि कौन सा डेटा SAP में जाएगा और किन नियमों से: कौन से ऑब्जेक्ट (कस्टमर, वेंडर, मटीरियल, ओपन ऑर्डर, हिस्ट्री), कटऑफ़ तारीख़ें, और क्या माइग्रेट करने के बजाय आर्काइव होगा। इसी से मेहनत और टाइमलाइन तय होती है, और यही तय करता है कि लीगेसी सिस्टम कितने समय तक एक्सेस के लिए खुले रखने होंगे।

SAP प्रोजेक्ट में नॉन-फ़ंक्शनल स्कोप क्या है?

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

स्कोप में कस्टमाइज़ेशन को कैसे सँभालें?

हर माँग को ज़रूरी, महत्वपूर्ण या गैर-ज़रूरी में बाँटिए। हर मंज़ूर माँग के लिए दर्ज कीजिए कि ज़रूरत क्या है, स्टैंडर्ड SAP उसे क्यों पूरा नहीं करता, कितनी मेहनत लगेगी, टेस्टिंग पर क्या असर होगा, मेंटेनेंस की लागत क्या है और एक्सटेंशन का तरीक़ा क्या होगा। Private Edition और on-premise में लक्ष्य क्लीन कोर लेवल और अपवादों को मंज़ूरी देने वाले का नाम लिखिए।

SAP प्रोजेक्ट स्कोप की समीक्षा कब होनी चाहिए?

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