SAP इम्प्लीमेंटेशन टेम्पलेट: फ़ेज़-दर-फ़ेज़ गाइड

SAP Activate, S/4HANA प्रोग्राम की लगभग हर डिलीवरेबल के लिए एक टेम्पलेट देता है। आप इन्हें SAP Activate Roadmap Viewer में पाएँगे, और क्लाउड प्रोग्राम में SAP Cloud ALM के भीतर। इन्हें ढूँढ़ना आसान है। मुश्किल यह जानना है कि किन्हें गंभीरता से लेना है।

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

मैन्युफ़ैक्चरिंग, रिटेल और फ़ाइनेंशियल सर्विसेज़ में मैंने जितने ECC और S/4HANA प्रोग्राम पर काम किया है, उन सबमें पैटर्न एक जैसा है। जो टीमें टेम्पलेट फ़ॉलो करती हैं, वे समस्याएँ पहले पकड़ लेती हैं। जो टीमें इन्हें वैकल्पिक कागज़ी काम मानती हैं, उन्हें प्रोजेक्ट के बीच में पता चलता है कि जो भी फ़ैसला उन्होंने लिखा नहीं था, वह स्कोप के विवाद में बदल चुका है।

यह वह सेट है जिसके साइन-ऑफ़ की मैं उम्मीद करता हूँ, साथ में हर टेम्पलेट का मालिक और वह पड़ाव जिसे उसे पार करना होता है।

फ़ेज़	टेम्पलेट	मालिक	इससे पहले साइन-ऑफ़ ज़रूरी
Prepare	प्रोजेक्ट स्कोपिंग डॉक्यूमेंट	प्रोग्राम मैनेजर (स्पॉन्सर मंज़ूरी देता है)	Explore शुरू होने से पहले
Prepare	बिज़नेस केस	CFO या बिज़नेस ओनर	फ़ंडिंग जारी होने से पहले
Prepare	स्टेकहोल्डर मैट्रिक्स	प्रोग्राम मैनेजर	Explore वर्कशॉप बुक होने से पहले
Explore	रिक्वायरमेंट और fit-gap शीट	प्रोसेस ओनर के साथ सॉल्यूशन आर्किटेक्ट	Realize शुरू होने से पहले
Realize	कॉन्फ़िगरेशन लॉग	फ़ंक्शनल लीड	हर ट्रांसपोर्ट के QA में जाने से पहले
Realize	कस्टम डेवलपमेंट रजिस्टर	डेवलपमेंट लीड	किसी भी ऑब्जेक्ट पर बिल्ड शुरू होने से पहले
Realize	टेस्ट स्ट्रैटेजी	टेस्ट मैनेजर	सिस्टम इंटीग्रेशन टेस्टिंग शुरू होने से पहले
Realize	डेटा माइग्रेशन प्लान	डेटा माइग्रेशन लीड	पहले मॉक लोड से पहले
Deploy	कटओवर प्लान	कटओवर मैनेजर	फ़ाइनल ड्रेस रिहर्सल से पहले
Deploy	go-live रेडीनेस असेसमेंट	प्रोग्राम डायरेक्टर (स्पॉन्सर साइन करता है)	Go/no-go मीटिंग से पहले
Run	Hypercare सपोर्ट मॉडल	सर्विस डिलीवरी लीड	go-live से पहले
Run	परफ़ॉर्मेंस मॉनिटरिंग शीट	Basis लीड	go-live से पहले

Activate के छह फ़ेज़ हैं: Discover, Prepare, Explore, Realize, Deploy और Run। यह SAP Best Practices कंटेंट, गाइडेड कॉन्फ़िगरेशन और एजाइल डिलीवरी अप्रोच को जोड़ता है। ज़्यादातर ग्राहकों के लिए Discover कॉन्ट्रैक्ट साइन होने से पहले हो जाता है, इसलिए नीचे के टेम्पलेट Prepare से शुरू होते हैं।

1. 01Discoverआम तौर पर कॉन्ट्रैक्ट साइन होने से पहले
2. 02Prepareस्कोपिंग डॉक्यूमेंट, बिज़नेस केस, स्टेकहोल्डर मैट्रिक्स
3. 03Exploreरिक्वायरमेंट और fit-gap शीट
4. 04Realizeकॉन्फ़िग लॉग, डेव रजिस्टर, टेस्ट स्ट्रैटेजी, माइग्रेशन प्लान
5. 05Deployकटओवर प्लान, go-live रेडीनेस
6. 06RunHypercare मॉडल, परफ़ॉर्मेंस मॉनिटरिंग

हर टेम्पलेट अपने गेट से पहले साइन-ऑफ़

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

टेम्पलेट अपनाते समय स्टैंडर्ड ढाँचे का करीब 80% रखें। सिर्फ़ वही बदलें जो आपके संदर्भ को दिखाता है: इंडस्ट्री की ज़रूरतें, रेगुलेटरी कंट्रोल, क्षेत्रीय बारीकियाँ। सब कुछ दोबारा लिख देने से मक़सद ही खत्म हो जाता है।

2026 में टूलिंग में क्या बदला

Activate का ढाँचा वही है जो पहले था। उसके आसपास की टूलिंग आगे बढ़ गई है।

1. क्लाउड प्रोग्राम में टेम्पलेट SAP Cloud ALM में रहते हैं। यह Solution Manager की जगह लेने वाला SAP का टूल है, और SAP Enterprise Support के साथ तथा RISE with SAP जैसे क्लाउड सब्सक्रिप्शन के साथ शामिल है। स्कोपिंग, रिक्वायरमेंट, टेस्ट प्लान और कटओवर टास्क वहाँ रह सकते हैं, और उनके बीच ट्रेसेबिलिटी बनी रहती है। Solution Manager 7.2 2027 के अंत में मेनस्ट्रीम मेंटेनेंस से बाहर हो जाता है, और कुछ फ़ंक्शन के लिए एक्सटेंडेड मेंटेनेंस 2030 तक है, इसलिए मौजूदा ऑन-प्रिमाइस लैंडस्केप के पास कुछ साल हैं, एक दशक नहीं।
2. Joule अब मेथडोलॉजी टूलिंग के भीतर है। SAP ने 2025 में Joule को Activate Roadmap Viewer और SAP Cloud ALM में उपलब्ध कराया, इसलिए टीम रोडमैप से टास्क की गाइडेंस माँग सकती है या कंटेंट का ड्राफ़्ट बनवा सकती है। इससे पहला ड्राफ़्ट तेज़ बनता है। यह fit-gap पर साइन करने वाले व्यक्ति की जगह नहीं लेता।
3. Clean core अब लेवल वाला डिज़ाइन नियम है। अगस्त 2025 में SAP ने अपने तीन-टियर एक्सटेंसिबिलिटी मॉडल की जगह चार clean core लेवल दिए, A से D। Level A सिर्फ़ रिलीज़्ड API इस्तेमाल करता है, या तो SAP BTP पर या सिस्टम के भीतर ABAP Cloud के साथ। Level D बिल्कुल clean नहीं है। Fit-gap टेम्पलेट में एक कॉलम चाहिए जो बताए कि हर gap कहाँ उतरेगा।
4. पब्लिक एडिशन fit-gap को संकरा कर देता है। SAP अब S/4HANA Cloud Public Edition को SAP Cloud ERP के नाम से बेचता है, और मिड-साइज़ कंपनियों को SAP GROW के रूप में। वही छह फ़ेज़ लागू होते हैं, हल्के आर्टिफ़ैक्ट के साथ, और सिर्फ़ रिलीज़्ड-API एक्सटेंशन की इजाज़त है, इसलिए “gap” कॉलम के संभावित जवाब कम होते हैं।

जो प्रोजेक्ट यह बुनियादी काम छोड़ देते हैं, वे इसकी कीमत Explore और Realize में चुकाते हैं।

प्रोजेक्ट स्कोपिंग टेम्पलेट

तय करता है कि प्रोजेक्ट में क्या शामिल है और क्या नहीं। जब कोई तीन महीने बाद स्कोप बढ़ाने की कोशिश करे (और करेगा), तो यही दस्तावेज़ संदर्भ बिंदु होता है। SAP प्रोजेक्ट चार्टर इसके ऊपर बैठता है और गवर्नेंस का ब्योरा रखता है।

सेक्शन	ब्योरा
टाइटल, स्पॉन्सर, PM	SAP S/4HANA Finance इम्प्लीमेंटेशन; CFO; नामित सीनियर PM
पृष्ठभूमि	मौजूदा स्थिति और बदलाव की वजह
उद्देश्य	क्लोज़ साइकल 14 दिन से घटाकर 5 करना; मैन्युअल रिकंसिलिएशन खत्म करना
स्कोप में	FI/CO, MM/SD इंटीग्रेशन, डेटा माइग्रेशन, UAT, go-live
स्कोप से बाहर	HR मॉड्यूल, पुरानी रिपोर्ट का माइग्रेशन, ERP से आगे के थर्ड-पार्टी इंटीग्रेशन
मान्यताएँ	एग्ज़िक्यूटिव स्पॉन्सर मासिक SteerCo के लिए उपलब्ध; टेस्ट डेटा पर हफ़्ता 6 तक सहमति
बाधाएँ	तय go-live तारीख़; कॉन्फ़िगरेशन के लिए सिर्फ़ आंतरिक संसाधन
डिलीवरेबल	कॉन्फ़िगर किया गया सिस्टम, टेस्ट प्लान, कटओवर प्लान, ट्रेनिंग सामग्री
टाइमलाइन	Prepare: हफ़्ते 1-4; Explore: हफ़्ते 5-10; Realize: हफ़्ते 11-26
मंज़ूरी	Explore शुरू होने से पहले प्रोजेक्ट स्पॉन्सर और PMO का साइन-ऑफ़ ज़रूरी

बिज़नेस केस टेम्पलेट

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

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

सेक्शन	ब्योरा
मालिक और सारांश	CFO या प्रोग्राम डायरेक्टर; अभी क्यों, क्या बदलता है, क्या वैसा ही रहता है
समस्या का विवरण	ख़ास ऑपरेशनल दिक्कतें (क्लोज़ साइकल की लंबाई, मैन्युअल वर्कअराउंड, सिस्टम की उम्र)
प्रस्तावित अप्रोच	Greenfield / brownfield / selective, स्कोप के सारांश के साथ
लाभ	मात्रात्मक: क्लोज़ साइकल के कम हुए दिन, FTE बचत, एरर रेट में कमी, ऑडिट जोखिम में कमी
लागत और फ़ंडिंग	इम्प्लीमेंटेशन, लाइसेंस या सब्सक्रिप्शन, आंतरिक संसाधनों का समय, कंटिंजेंसी; बजट का स्रोत
जोखिम	शीर्ष तीन, संभावना और असर के साथ
सिफ़ारिश	आगे बढ़ें / शर्तों के साथ आगे बढ़ें / टालें, कारण के साथ

स्टेकहोल्डर आइडेंटिफ़िकेशन मैट्रिक्स

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

स्टेकहोल्डर	भूमिका	रुचि	प्रभाव	एंगेजमेंट
ग्रुप CFO	एग्ज़िक्यूटिव स्पॉन्सर	प्रोग्राम का ROI, फ़ाइनेंस क्लोज़ में सुधार	उच्च	मासिक SteerCo, साप्ताहिक लिखित अपडेट
IT डायरेक्टर	टेक्निकल ओनर	सिस्टम की स्थिरता, इंटीग्रेशन, सिक्योरिटी	उच्च	साप्ताहिक प्रोग्राम बोर्ड, Realize में रोज़ाना
फ़ाइनेंस डायरेक्टर	मुख्य प्रोसेस ओनर	FI/CO डिज़ाइन, क्लोज़ प्रोसेस	उच्च	Explore में वर्कशॉप, UAT साइन-ऑफ़
प्लांट मैनेजर	प्रभावित यूज़र	MM/PP प्रोसेस में बदलाव	मध्यम	मासिक चेंज कम्युनिकेशन, UAT में भागीदारी
एंड यूज़र (AP/AR)	ऑपरेटर	ट्रांज़ैक्शन स्तर के बदलाव	कम	ट्रेनिंग, hypercare सपोर्ट
इंटरनल ऑडिट	गवर्नेंस	ट्रेसेबिलिटी, कंट्रोल, कंप्लायंस	मध्यम	क्वालिटी गेट पर आर्टिफ़ैक्ट की समीक्षा

इसी मैट्रिक्स से उन Prepare वर्कशॉप की योजना बनाएँ जो विभाग के हिसाब से हाई-लेवल रिक्वायरमेंट इकट्ठा करती हैं। उन रिक्वायरमेंट को उसी फ़ॉर्मैट में नंबर दें जो आप Explore में इस्तेमाल करेंगे (REQ-001 वग़ैरह), ताकि बाद में कुछ भी दोबारा नंबर न करना पड़े और मूल माँग तक का ट्रेस बचा रहे।

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

रिक्वायरमेंट मैपिंग और fit-gap टेम्पलेट

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

फिर fit-gap विश्लेषण दिखाता है कि स्टैंडर्ड SAP हर ज़रूरत को कहाँ पूरा करता है और कहाँ नहीं। मेरे ज़्यादातर क्लाइंट के लिए यह आँखें खोलने वाला होता है। मुझे वह पल देखना पसंद है जब टीम को समझ आता है कि महँगे कस्टम कोड की जगह वह स्टैंडर्ड फ़ंक्शनैलिटी इस्तेमाल कर सकती है।

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

Req ID	रिक्वायरमेंट	SAP कॉम्पोनेंट	Fit / Gap	समाधान का रास्ता	टेस्ट रेफ़
REQ-001	महीने के अंत के जर्नल का ऑटोमेटेड क्लोज़	FI-GL, पीरियड-एंड क्लोज़िंग	Fit	रिकरिंग डॉक्यूमेंट टेम्पलेट कॉन्फ़िगर करें	TC-001
REQ-002	Fiori के ज़रिए पर्चेज़ ऑर्डर अप्रूवल	MM पर्चेज़िंग, Fiori अप्रूवल ऐप	Gap (ECC में नहीं)	स्टैंडर्ड S/4HANA ऐप और वर्कफ़्लो कॉन्फ़िगरेशन	TC-003
REQ-003	इंटरकंपनी बिलिंग ऑटोमेशन	SD बिलिंग, FI इंटीग्रेशन	Gap	इंटरकंपनी बिलिंग कॉन्फ़िगरेशन	TC-010
REQ-004	बैच जॉब मॉनिटरिंग	Application Jobs ऐप	Fit	स्टैंडर्ड ऐप	TC-015
REQ-005	सप्लायर सेल्फ़-सर्विस पोर्टल	SAP Ariba या सप्लायर पोर्टल	Gap	Ariba इंटीग्रेशन	TC-020
REQ-006	GDPR के अनुरूप डेटा आर्काइविंग	ILM, डेटा आर्काइविंग	Gap	ILM पॉलिसी कॉन्फ़िगरेशन	TC-025
REQ-007	रियल-टाइम कॉस्ट सेंटर रिपोर्टिंग	CO, embedded analytics या SAC	Gap	Embedded analytics या SAC लाइव कनेक्शन	TC-030
REQ-008	एक साथ 500 यूज़र का सपोर्ट	HANA साइज़िंग	Gap (300 पर टेस्ट हुआ)	साइज़िंग की समीक्षा और इन्फ्रास्ट्रक्चर अपग्रेड	TC-035

यह बिल्ड का फ़ेज़ है। ये टेम्पलेट हर कॉन्फ़िगरेशन फ़ैसले, हर डेवलपमेंट और हर टेस्ट नतीजे का ऑडिट ट्रेल हैं।

कॉन्फ़िगरेशन ट्रैकिंग टेम्पलेट

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

1. कॉन्फ़िगरेशन ID और मॉड्यूल: [जैसे MM-CONF-001, MM]
2. IMG पाथ और कॉन्फ़िगरेशन ऑब्जेक्ट: [जैसे Table T161, PO डॉक्यूमेंट टाइप]
3. उद्देश्य और प्रभावित बिज़नेस प्रोसेस
4. किसने कॉन्फ़िगर किया और तारीख़
5. ट्रांसपोर्ट रिक्वेस्ट नंबर: [जैसे DEVK900123]
6. मुख्य वैल्यू: पहले और बाद में
7. जुड़े हुए टेस्ट केस
8. वैलिडेशन और मंज़ूरी की स्थिति

कस्टम डेवलपमेंट रजिस्टर

कोड लिखने से पहले हर कस्टम ऑब्जेक्ट को एक पंक्ति मिलती है। मेरे एक क्लाइंट ने अपना कस्टम कोड 30% घटा दिया, क्योंकि रजिस्टर ने दिखा दिया कि स्टैंडर्ड SAP कहाँ बिल्कुल ठीक चलेगा।

Dev ID	ऑब्जेक्ट	विवरण	डेवलपर	एफ़र्ट (घंटे)	स्थिति	एक्सटेंशन का प्रकार
CD-001	Fiori टाइल: कॉस्ट सेंटर ओवरव्यू	फ़ाइनेंस के लिए रियल-टाइम CO रिपोर्टिंग टाइल	Fiori डेवलपर	12	पूरा	डेवलपर एक्सटेंशन
CD-002	इंटरकंपनी बिलिंग रिपोर्ट	IC रिकंसिलिएशन के लिए रिपोर्ट	ABAP डेवलपर	20	जारी	डेवलपर एक्सटेंशन
CD-004	वेंडर पेमेंट स्टेटस ऐप	AP पेमेंट पूछताछ के लिए Fiori ऐप	BTP डेवलपर	10	QA लंबित	BTP पर साइड-बाय-साइड
CD-005	गुड्स रिसीट नोटिफ़िकेशन	गुड्स रिसीट पोस्टिंग पर ईमेल ट्रिगर	इंटीग्रेशन डेवलपर	24	योजनाबद्ध	इवेंट-आधारित, BTP पर

टेस्टिंग स्ट्रैटेजी टेम्पलेट

सभी टेस्टिंग प्लान एक जगह रखता है: कौन क्या टेस्ट करता है, कब, किस एनवायरनमेंट में, और किस मानक पर।

सेक्शन	ब्योरा
स्कोप	फ़ंक्शनल, इंटीग्रेशन, रिग्रेशन, परफ़ॉर्मेंस, स्कोप के सभी मॉड्यूल में UAT (पेनेट्रेशन टेस्टिंग InfoSec के पास रहती है)
एनवायरनमेंट	DEV, QA, UAT (प्री-प्रोडक्शन), फ़ाइनल वैलिडेशन के लिए स्टेजिंग
टूल	SAP Cloud ALM या Jira/Xray में टेस्ट मैनेजमेंट; Tricentis Tosca या उसी जैसे टूल से ऑटोमेशन; JMeter या LoadRunner से परफ़ॉर्मेंस
डिफ़ेक्ट लाइफ़साइकल	New, In progress, Resolved, Verified, Closed; ट्राइएज पर सीवियरिटी और प्रायोरिटी तय होती हैं
एग्ज़िट क्राइटेरिया	सभी क्रिटिकल डिफ़ेक्ट बंद; UAT साइन-ऑफ़ मिला; रिग्रेशन पास रेट कम से कम 95%; परफ़ॉर्मेंस बेंचमार्क पूरे

डेटा माइग्रेशन प्लानिंग टेम्पलेट

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

सेक्शन	ब्योरा
स्कोप	कस्टमर मास्टर, वेंडर मास्टर, ओपन आइटम, मटीरियल मास्टर, स्टॉक बैलेंस, कॉस्ट सेंटर हायरार्की
सोर्स सिस्टम	ECC 6.0 EHP 7 (प्राइमरी); पुराना HR सिस्टम (कर्मचारी कॉस्ट सेंटर असाइनमेंट)
टारगेट सिस्टम	S/4HANA (मौजूदा रिलीज़)
मैपिंग और नियम	कस्टमर और वेंडर Business Partner में; कॉस्ट सेंटर नई हायरार्की में; अमान्य बैंक विवरण हटाएँ; डुप्लिकेट मर्ज करें
माइग्रेशन टूल	SAP S/4HANA Migration Cockpit (प्राइमरी); कस्टम ऑब्जेक्ट के लिए Migration Object Modeler; प्री-प्रोसेसिंग के लिए स्क्रिप्ट
लोड स्ट्रैटेजी	QA पर मॉक लोड; डेल्टा माइग्रेशन और रिकंसिलिएशन; प्रोडक्शन कटओवर
वैलिडेशन अप्रोच	सोर्स से टारगेट तक रिकॉर्ड काउंट; 10% रैंडम सैंपलिंग; बैलेंस रिकंसिलिएशन रिपोर्ट
रोलबैक प्लान	कटओवर से पहले का बैकअप; पुराना सिस्टम 48 घंटे स्टैंडबाय पर

Deploy वह फ़ेज़ है जब आप go-live करते हैं। ये टेम्पलेट अफ़रा-तफ़री वाले वीकेंड को एक संभाले हुए आयोजन में बदल देते हैं।

कटओवर प्लानिंग टेम्पलेट

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

टास्क की सूची लिखने से पहले चार चीज़ें तय करें: विंडो (जैसे शुक्रवार 22:00 से शनिवार 06:00), रोलबैक का ट्रिगर, पुराना सिस्टम कितनी तेज़ी से दोबारा चालू हो सकता है, और वे स्मोक टेस्ट जो साबित करें कि नया सिस्टम काम करता है। फिर टास्क का क्रम:

चरण	विवरण	मालिक	शुरू होने का समय	स्थिति
1	ECC सिस्टम फ़्रीज़ करें (कोई पोस्टिंग नहीं)	Basis	22:00	लंबित
2	फ़ाइनल डेटा एक्सट्रैक्ट और रिकंसिलिएशन	डेटा माइग्रेशन लीड	22:30	लंबित
3	प्रोडक्शन माइग्रेशन लोड चलाएँ	DBA	23:00	लंबित
4	बचे हुए ट्रांसपोर्ट प्रोडक्शन में इम्पोर्ट करें	Basis	00:30	लंबित
5	DNS और लोड बैलेंसर को S/4HANA पर स्विच करें	नेटवर्क	01:30	लंबित
6	स्मोक टेस्ट: FI पोस्टिंग, गुड्स रिसीट, सेल्स ऑर्डर	QA लीड	02:00	लंबित
7	बिज़नेस की पुष्टि और go/no-go फ़ैसला	प्रोग्राम डायरेक्टर	03:00	लंबित
8	बिज़नेस यूज़र के लिए सिस्टम खोलें	Basis	06:00	लंबित

Go-live रेडीनेस असेसमेंट

तय करता है कि आप सच में स्विच के लिए तैयार हैं या नहीं। मेरे कुछ क्लाइंट ने इसी असेसमेंट के आधार पर go-live टाला, और बाद में उन्होंने मुझे धन्यवाद दिया।

क्षेत्र	जाँच (हर एक का जवाब हाँ या नहीं, सबूत के साथ)
फ़ंक्शनल	मुख्य प्रोसेस टेस्ट हो चुके हैं; क्रॉस-मॉड्यूल परिदृश्य पूरे; खुले P1/P2 डिफ़ेक्ट की सूची बनी है; की-यूज़र तैयारी की पुष्टि करते हैं
डेटा	मास्टर डेटा लोड पूरे; ट्रांज़ैक्शन डेटा वैलिडेट हुआ; रिकंसिलिएशन रिपोर्ट मंज़ूर; पुराने सिस्टम का फ़्रीज़ पक्का
टेक्निकल	कटओवर प्लान मंज़ूर; ट्रांसपोर्ट प्रोडक्शन में; बैच जॉब शेड्यूल; मॉनिटरिंग कॉन्फ़िगर
लोग	ट्रेनिंग कवरेज %; एक्सेस रोल वैलिडेट हुए; hypercare टीम तैनात; सपोर्ट प्लान बता दिया गया
फ़ैसला	क्रिटिकल जोखिम और उनके उपाय सूचीबद्ध; Go / No-go / शर्तों के साथ; नाम, भूमिका और तारीख़ के साथ मंज़ूर

go-live के बाद काम का स्वरूप बदल जाता है। ये टेम्पलेट सिस्टम और टीम को hypercare से होकर सामान्य स्थिति तक ले जाते हैं।

पोस्ट-इम्प्लीमेंटेशन सपोर्ट टेम्पलेट

लॉन्च के बाद आप समस्याओं को कैसे संभालते हैं, इसे व्यवस्थित करता है। इसके बिना हर समस्या P1 बन जाती है।

सेक्शन	ब्योरा
Hypercare विंडो	go-live के बाद हफ़्ते 1-4: 24/7 कवरेज
सपोर्ट चैनल	ServiceNow इंसिडेंट क्यू (प्राइमरी); समर्पित चैट चैनल; P1 समस्याओं के लिए फ़ोन ब्रिज
सपोर्ट टियर	1: सर्विस डेस्क (पासवर्ड, नेविगेशन, ज्ञात समस्याएँ); 2: फ़ंक्शनल कंसल्टेंट (प्रोसेस के सवाल, छोटे कॉन्फ़िग बदलाव); 3: Basis और डेवलपमेंट (सिस्टम एरर, परफ़ॉर्मेंस, इंटरफ़ेस)
SLA (रिस्पॉन्स / रिज़ॉल्यूशन)	Critical 15 मिनट / 2 घंटे; High 30 मिनट / 4 घंटे; Medium 4 घंटे / 1 दिन; Low 1 दिन / 3 दिन
मॉनिटरिंग	SAP Cloud ALM या Solution Manager; रोज़ाना एरर लॉग की समीक्षा
एग्ज़िट क्राइटेरिया	कोई खुला P1/P2 मुद्दा नहीं; सभी इंसिडेंट दर्ज; अंतिम हैंडओवर साइन-ऑफ़

परफ़ॉर्मेंस मॉनिटरिंग टेम्पलेट

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

मेट्रिक	लक्ष्य	टूल	अलर्ट सीमा	मालिक
डायलॉग रिस्पॉन्स टाइम (95वाँ परसेंटाइल)	1 सेकंड से कम	ST03 / SAP Cloud ALM	2 सेकंड	Basis टीम
बैकग्राउंड जॉब पूरा होना	शेड्यूल के अनुसार 100%	SM37 / Application Jobs	कोई भी फ़ेल हुआ जॉब	Ops लीड
डेटाबेस क्वेरी टाइम	200ms से कम	SAP HANA cockpit	500ms	DBA
सिस्टम उपलब्धता	99.5% से ज़्यादा	SAP Cloud ALM	99% से कम	इन्फ्रास्ट्रक्चर
इंटरफ़ेस एरर रेट	1% से कम	SAP Integration Suite मॉनिटरिंग	2%	मिडलवेयर लीड
लॉगिन सफलता दर	98% से ज़्यादा	सिक्योरिटी ऑडिट लॉग	95% से कम	सिक्योरिटी लीड
महीने के अंत के क्लोज़ जॉब का रनटाइम	तय विंडो के भीतर	जॉब शेड्यूलर	बेसलाइन से 30% ऊपर	फ़ाइनेंस ऑप्स

क्वालिटी गेट एक फ़ेज़ की समस्या को अगले फ़ेज़ के महँगे रीवर्क में बदलने से रोकते हैं। मेरी SAP क्वालिटी गेट गाइड बताती है कि इन्हें कैसे सेट करें। यहाँ यह है कि ये क्यों मायने रखते हैं।

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

हर गेट पर पास/फ़ेल की कसौटी तय करें। “95% रिग्रेशन टेस्ट पास होने चाहिए।” “FI के सभी इंटीग्रेशन परिदृश्य हरे हैं।” ऐसी कसौटियाँ आपको वह ठोस आधार देती हैं जिस पर आप तब अड़े रह सकते हैं जब बिज़नेस क्वालिटी की परवाह किए बिना किसी तारीख़ पर लॉन्च करना चाहे।

मेरे एक प्रोजेक्ट में क्वालिटी गेट ने हमें तब रोका जब सिर्फ़ 75% इंटीग्रेशन टेस्ट पास हुए थे। हमने जल्दबाज़ी करने की जगह पहले समस्याएँ ठीक कीं। इससे क्लाइंट के लॉन्च के बाद के इमरजेंसी फ़िक्स में करीब €100,000 बचे।

जिस गेट को स्पॉन्सर एक फ़ोन कॉल से पलट सकता हो, वह गेट नहीं है। ज़रूरत पड़ने से पहले लिख लें कि उसे कौन माफ़ कर सकता है।

SAP Activate मेथडोलॉजी क्या है?

SAP Activate, S/4HANA और SAP के दूसरे क्लाउड प्रोडक्ट के लिए SAP की इम्प्लीमेंटेशन मेथडोलॉजी है। यह छह फ़ेज़ में चलती है (Discover, Prepare, Explore, Realize, Deploy, Run) और SAP Best Practices कंटेंट, गाइडेड कॉन्फ़िगरेशन और एजाइल डिलीवरी को जोड़ती है।

हर डिप्लॉयमेंट परिदृश्य के टास्क लिस्ट और डिलीवरेबल टेम्पलेट SAP Activate Roadmap Viewer में प्रकाशित हैं।

SAP Activate के किस फ़ेज़ के टेम्पलेट सबसे अहम हैं?

Prepare। स्कोपिंग डॉक्यूमेंट, बिज़नेस केस और स्टेकहोल्डर मैट्रिक्स आगे के हर फ़ैसले की बुनियाद रखते हैं, और यही वे हैं जिन्हें टीमें कॉन्फ़िगरेशन पर जल्दी पहुँचने के लिए छोड़ देती हैं। वह शॉर्टकट Realize में स्कोप के विवादों का सबसे आम कारण है।

Explore दूसरे नंबर पर है। fit-gap और रिक्वायरमेंट मैपिंग दस्तावेज़ों की कमियाँ महीनों बाद UAT के डिफ़ेक्ट के रूप में सामने आती हैं, जब उन्हें ठीक करना Explore के तीसरे हफ़्ते की तुलना में कहीं ज़्यादा महँगा पड़ता है।

क्या SAP Activate के टेम्पलेट कस्टमाइज़ किए जा सकते हैं?

हाँ। स्टैंडर्ड ढाँचे का करीब 80% रखें और सिर्फ़ वही बदलें जो आपके संदर्भ के लिए ख़ास है: फ़ार्मास्यूटिकल वैलिडेशन, पब्लिक सेक्टर की प्रोक्योरमेंट के नियम, SOX कंट्रोल। इन्हें Prepare की शुरुआत में जोड़ें, Deploy में नहीं।

क्वालिटी गेट का ढाँचा, फ़ेज़ का क्रम या अनिवार्य आर्टिफ़ैक्ट (स्कोपिंग डॉक्यूमेंट, बिज़नेस केस, go-live रेडीनेस असेसमेंट) कस्टमाइज़ न करें।

क्या SAP Activate के टेम्पलेट greenfield और brownfield दोनों के लिए चलते हैं?

हाँ। मुख्य फ़र्क Explore में है। Brownfield कन्वर्ज़न मौजूदा कॉन्फ़िगरेशन को आगे ले जाता है, इसलिए fit-gap इस पर केंद्रित होता है कि क्या बदलना है, कौन-सा कस्टम कोड अब स्टैंडर्ड S/4HANA बदल सकता है, और कन्वर्ज़न से पहले कौन-सा डेटा क्लीनअप चाहिए। Greenfield प्रोग्राम SAP Best Practices से शुरू होता है और पुष्टि करता है कि कौन-से स्टैंडर्ड प्रोसेस फ़िट होते हैं।

कटओवर प्लान भी अलग होता है। Brownfield सिस्टम कन्वर्ज़न का क्रम, पूरे डेटा माइग्रेशन वाले greenfield go-live से अलग चलता है।

कटओवर प्लान कितना विस्तृत होना चाहिए?

कम से कम घंटे-दर-घंटे, और ब्लैकआउट विंडो के लिए उससे भी बारीक। हर टास्क को एक शुरू होने का समय, एक मालिक और एक डिपेंडेंसी चाहिए।

कटओवर शुरू होने से पहले रोलबैक की कसौटी तय कर लें: कौन-सी स्थितियाँ पुराने सिस्टम पर लौटने की वजह बनेंगी, यह फ़ैसला कौन लेगा, और किस समय तक। सुबह 4 बजे बिना पहले से तय कसौटी के लिए गए रोलबैक के फ़ैसले वहीं हैं जहाँ go-live के बाद की तबाही शुरू होती है।