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

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

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

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

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

दस्तावेज़	मक़सद	कौन बनाता है	कब
प्रोजेक्ट प्रपोज़ल	यह तर्क देना कि प्रोजेक्ट क्यों होना चाहिए	बिज़नेस स्पॉन्सर	मंज़ूरी से पहले
प्रोजेक्ट चार्टर	प्रोजेक्ट को मंज़ूरी देना, स्कोप, उद्देश्य, नामित ज़िम्मेदार लोग और गवर्नेंस तय करना	स्पॉन्सर, प्रोग्राम मैनेजर के साथ	शुरुआत में
प्रोजेक्ट प्लान	यह तय करना कि काम कैसे होगा: टास्क, संसाधन, निर्भरताएँ	प्रोग्राम मैनेजर	चार्टर की मंज़ूरी के बाद

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

बिज़नेस नतीजे से जुड़े उद्देश्य

“सिस्टम का आधुनिकीकरण” नहीं। हर उद्देश्य के साथ एक आँकड़ा चाहिए। कसौटी यह है: क्या आप बिना स्लाइड के 30 सेकंड में बोर्ड के किसी सदस्य को विज़न समझा सकते हैं?

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

इसके उलट एक रिटेल क्लाइंट को देखिए जिसे मैंने सपोर्ट किया था। उसके चार्टर में पहले दिन से KPI तय थे। ऑर्डर प्रोसेसिंग लागत में 32 प्रतिशत की गिरावट दिखी, और फ़ेज़ 2 तुरंत मंज़ूर हो गया।

स्कोप, और स्कोप से बाहर की साफ़ सूची

यह सबसे ज़्यादा अनदेखा किया जाने वाला सेक्शन है। टीमें स्कोप के अंदर की चीज़ों की विस्तृत सूची लिखती हैं और बाहर की चीज़ें छोड़ देती हैं, जबकि बहसें ठीक वहीं होती हैं।

मैंने एक हेल्थकेयर कंपनी के साथ काम किया जिसने अपना SAP रोलआउट इसी तरह केंद्रित रखा। मार्केटिंग हेड यूज़र एक्सेप्टेंस टेस्टिंग (UAT) के दौरान कैंपेन ट्रैकिंग के लिए एनालिटिक्स जोड़ना चाहते थे। चार्टर में इसके लिए जगह नहीं थी, और स्टीयरिंग कमेटी ने इसे तुरंत पकड़ लिया। उस एक फ़ैसले से $850,000 बचे और छह हफ़्ते की देरी टल गई।

विभाग नहीं, नामित लोग

“फ़ाइनेंस टीम: रिपोर्टिंग पर इनपुट देती है” किसी को जवाबदेह नहीं बनाता। “फ़ाइनेंस लीड, [नाम]: रिपोर्टिंग की ज़रूरतें तय करते हैं, FI/CO कॉन्फ़िगरेशन साइन-ऑफ़ करते हैं, डेटा माइग्रेशन की तैयारी मंज़ूर करते हैं” बनाता है।

कमिटमेंट के रूप में माइलस्टोन

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

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

बजट, जोखिम और निर्भरताएँ

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

मैं इसी ढाँचे से शुरू करूँगा। हर सेक्शन एक पन्ने में या उससे कम में समा जाना चाहिए।

1. मक़सद और पृष्ठभूमि: अभी क्यों, क्या टूटा हुआ है, कुछ न करने पर क्या होगा।
2. उद्देश्य और सफलता के पैमाने: हर उद्देश्य के साथ बेसलाइन, टारगेट और तारीख़।
3. स्कोप: स्कोप में आने वाले मॉड्यूल, प्रोसेस, लीगल एंटिटी, देश, साइट, इंटीग्रेशन और डेटा।
4. स्कोप से बाहर: इसे उतनी ही सावधानी से लिखिए जितनी सावधानी से स्कोप, और हर बाहर रखी गई चीज़ के साथ वह फ़ेज़ लिखिए जिसमें उसे टाला गया है।
5. डिप्लॉयमेंट मॉडल और एक्सटेंशन के नियम: S/4HANA Cloud Public Edition, RISE के तहत Private Edition, या ऑन-प्रेमिस, और कस्टम डेवलपमेंट कैसे मंज़ूर होगा।
6. गवर्नेंस: स्पॉन्सर, स्टीयरिंग कमेटी, डिज़ाइन अथॉरिटी, चेंज कंट्रोल, एस्केलेशन पथ, सब नामित लोगों के साथ।
7. भूमिकाएँ और जवाबदेही: हर प्रोसेस एरिया, डेटा, टेस्टिंग, चेंज और कटओवर के लिए नामित व्यक्ति।
8. माइलस्टोन: तारीख़ों और पास होने की शर्तों के साथ फ़ेज़ गेट। मेरी क्वालिटी गेट्स गाइड में उदाहरण हैं।
9. बजट और कंटिन्जेंसी: कुल राशि, कंटिन्जेंसी, और उसे जारी करने का अधिकार किसके पास है।
10. जोखिम, मान्यताएँ और निर्भरताएँ: समानांतर प्रोग्राम और नियामक डेडलाइन समेत।
11. कंप्लायंस की ज़रूरतें: जैसे अमेरिकी हेल्थकेयर में HIPAA, फ़ार्मा में GxP, अमेरिका में लिस्टेड कंपनियों के लिए SOX।
12. साइन-ऑफ़: स्पॉन्सर और बिज़नेस लीड, वर्शन नंबर और तारीख़ के साथ।

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

ऐसा चार्टर जिसकी ओर आप तीसरे महीने में तब इशारा कर सकें जब स्कोप पर विवाद हो

1. काम जानने वाले लोगों से पूछिए

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

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

2. स्कोप लिखने से पहले ज़रूरी और अच्छा-होता-तो चीज़ें अलग कीजिए

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

3. टेम्पलेट से शुरू कीजिए, फिर SAP की ख़ास बातें जोड़िए

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

4. इतना ठोस लिखिए कि बहस सुलझ सके

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

5. असली साइन-ऑफ़ लीजिए

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

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

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

RISE with SAP (Private Edition) पर गवर्नेंस सेक्शन में दो चीज़ें जोड़िए। पहली, clean core अप्रूवल फ़ोरम। SAP अब एक्सटेंशन को लेवल A (सिर्फ़ रिलीज़्ड API) से लेकर लेवल D (मॉडिफ़िकेशन) तक वर्गीकृत करता है (SAP News, अगस्त 2025)। Private Edition अब भी कोर को मॉडिफ़ाई करने देता है, इसलिए यह फ़ोरम ही टेक्निकल डेट जमा होने से रोकता है। दूसरी, SAP तक एस्केलेशन पथ। RISE के तहत इंफ़्रास्ट्रक्चर और टेक्निकल ऑपरेशंस SAP चलाता है। जब प्लेटफ़ॉर्म लेवल पर कुछ फ़ेल हो, तो CIO को पता होना चाहिए कि SAP में किसे फ़ोन करना है, सिर्फ़ पार्टनर में नहीं।

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

AI टूल इंटरव्यू नोट्स से पहला ड्राफ़्ट तेज़ी से बना सकते हैं। पर चार्टर का राजनीतिक काम वे नहीं कर सकते, यानी स्पॉन्सर्स से यह सहमति बनवाना कि कौन-सी चीज़ किसकी ज़िम्मेदारी है।

SAP इम्प्लीमेंटेशन में प्रोजेक्ट चार्टर क्या होता है?

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

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

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

प्रोजेक्ट चार्टर और प्रोजेक्ट प्लान में क्या फ़र्क़ है?

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

SAP प्रोजेक्ट चार्टर कौन लिखे?

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

RISE with SAP प्रोजेक्ट चार्टर को कैसे बदलता है?

एक clean core अप्रूवल फ़ोरम जोड़िए जो तय करे कि कौन-से एक्सटेंशन किस स्तर पर मंज़ूर हैं। प्लेटफ़ॉर्म की समस्याओं के लिए SAP तक एस्केलेशन पथ जोड़िए, क्योंकि RISE के तहत इंफ़्रास्ट्रक्चर SAP चलाता है। GROW with SAP पर चार्टर हल्का होता है, क्योंकि Public Edition तकनीकी रूप से clean core लागू करता है।

क्या इम्प्लीमेंटेशन के दौरान प्रोजेक्ट चार्टर बदल सकता है?

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