SAP इम्प्लीमेंटेशन प्रोजेक्ट की शुरुआत सही तरीके से कैसे करें

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

मैं हमेशा मानता था कि सिस्टम सही कॉन्फ़िगर हो, तो SAP इम्प्लीमेंटेशन ठीक चलेगा। ब्लूप्रिंट, बिल्ड, टेस्ट, go-live। सालों तक मेरा यही मानसिक मॉडल रहा।

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

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

जो टीमें इसे सिर्फ़ कॉन्फ़िगरेशन का काम मान लेती हैं, वे कॉन्फ़िगरेशन के अलावा हर चीज़ के लिए कम बजट रखती हैं। मुश्किल go-live की सबसे आम वजह मुझे यही दिखती है।

आज शुरू होने वाले प्रोग्राम के लिए एक और वर्कस्ट्रीम है जिसे सबसे पहले तय करना होगा: डिप्लॉयमेंट मॉडल। S/4HANA Cloud Public Edition (GROW with SAP), Private Edition (RISE with SAP) या on-premise। यही फ़ैसला तय करता है कि बाकी हर वर्कस्ट्रीम कैसे चलेगा।

SAP Activate, SAP की डिलीवरी मेथड है। इसमें छह चरण हैं और हर चरण के अंत में क्वालिटी गेट होते हैं। नीचे हर चरण का मकसद है, और वह बात जिसे मैं फिसलने नहीं देता।

चरण	क्या होता है	मैं किस बात को सही रखता हूँ
Discover	बिज़नेस केस, हाई-लेवल स्कोप, डिप्लॉयमेंट मॉडल	आशावादी नहीं, यथार्थवादी लागत और टाइमलाइन
Prepare	गवर्नेंस, चार्टर, टीम, रिस्क रजिस्टर, एनवायरनमेंट	असली अधिकार वाले नामित निर्णयकर्ता
Explore	Fit-to-standard वर्कशॉप, गैप पर फ़ैसले, डिज़ाइन साइन-ऑफ़	कमरे में बिज़नेस ओनर हों, सिर्फ़ IT नहीं
Realize	कॉन्फ़िगरेशन, डेवलपमेंट, इंटीग्रेशन, सिस्टम टेस्टिंग	कटओवर प्लानिंग पहले से चल रही हो
Deploy	यूज़र एक्सेप्टेंस टेस्टिंग, डेटा लोड, ट्रेनिंग, कटओवर	कम से कम एक पूरी ड्रेस रिहर्सल
Run	Go-live, hypercare, सपोर्ट को हैंडओवर	पहले मंथ-एंड क्लोज़ तक hypercare में स्टाफ़ मौजूद

शेड्यूल की सबसे आम चूक है धीमा Explore। वह Realize को दबा देता है, और Realize Deploy को दबा देता है। यूज़र एक्सेप्टेंस टेस्टिंग (UAT) छोटी कर दी जाती है, डेटा रिहर्सल छोड़ दी जाती है, और go-live फिर भी हो जाता है क्योंकि तारीख़ का ऐलान हो चुका होता है। इसकी कीमत go-live के बाद के पहले 90 दिन चुकाते हैं।

1. 01Explore देर से चलता हैFit-to-standard और डिज़ाइन साइन-ऑफ़ खिसकते हैं
2. 02Realize दब जाता हैबनाने और टेस्ट करने का समय कम पड़ता है
3. 03Deploy दब जाता हैUAT, डेटा लोड और ट्रेनिंग के लिए कम समय बचता है
4. 04टेस्टिंग में कटौती होती हैUAT छोटी होती है, डेटा रिहर्सल छूट जाती है
5. 05घोषित तारीख़ पर go-liveक्योंकि तारीख़ का ऐलान हो चुका था

कीमत hypercare में, पहले 90 दिनों में चुकानी पड़ती है

1. बिज़नेस के बिना डिज़ाइन साइन-ऑफ़

Explore एक डिज़ाइन तैयार करता है। उसकी गुणवत्ता इस पर टिकी है कि जिन प्रोसेस ओनर्स ने उसे साइन किया, उन्होंने समझा भी था कि वे क्या साइन कर रहे हैं। जब वर्कशॉप में सिर्फ़ IT और कंसल्टेंट आते हैं, तो डिज़ाइन तकनीकी रूप से सही होकर भी उन लोगों को अजनबी लग सकता है जो उसे इस्तेमाल करेंगे। तब UAT जाँच की जगह खोज-बीन बन जाती है।

एक सीधी परख: साइन-ऑफ़ के तीन महीने बाद किसी प्रोसेस ओनर से कहिए कि वह बताए कि go-live के बाद पर्चेज़ ऑर्डर कैसे चलेगा। अगर वह नहीं बता पाता, तो साइन-ऑफ़ असली नहीं था।

2. गवर्नेंस जो सिर्फ़ काग़ज़ पर है

जब गवर्नेंस लागू नहीं की जाती, तो स्कोप अनौपचारिक रूप से बढ़ता जाता है और फ़ैसले टलते रहते हैं। अच्छी गवर्नेंस का मतलब है: एक नामित एग्ज़ीक्यूटिव स्पॉन्सर, तय निर्णय-अधिकारों वाली स्टीयरिंग कमेटी, एक प्रोजेक्ट मैनेजर जो फ़ेज़ गेट पर अड़ सके, और नामित अप्रूवर वाली चेंज कंट्रोल प्रक्रिया।

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

3. कटओवर की देर से प्लानिंग

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

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

4. इंटीग्रेशन टेस्टिंग का कट जाना

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

यूनिट टेस्ट सिर्फ़ यह साबित करते हैं कि एक ट्रांज़ैक्शन अकेले चलता है। go-live के बाद जो नुकसान करती हैं, वे गड़बड़ियाँ तब दिखती हैं जब पूरी प्रोसेस मॉड्यूल के आर-पार चलती है। पर्चेज़ ऑर्डर के स्टेटस की वजह से अटकी गुड्स रिसीट। अकाउंट डिटरमिनेशन न मिलने से रुका बिलिंग रन। पूरी चेन टेस्ट करें, order to cash और procure to pay, और उन्हें UAT से पहले के आख़िरी हफ़्तों तक खिसकने न दें।

5. डेटा माइग्रेशन का कम आकलन

सोर्स डेटा लगभग हमेशा पहले आकलन से ख़राब निकलता है। फ़ील्ड मैपिंग जो सीधी दिखती है, लोड में फ़ेल हो जाती है। रिकॉर्ड की गिनती में निष्क्रिय डेटा भी शामिल होता है। क्लीनिंग के नियमों के लिए बिज़नेस फ़ैसले चाहिए, और उनमें समय लगता है।

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

6. चेंज मैनेजमेंट को वैकल्पिक मान लेना

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

भारी कस्टमाइज़ेशन भी इसी श्रेणी में आता है। मैंने एक क्लाइंट के साथ काम किया जिसने सिस्टम का 60 प्रतिशत से ज़्यादा हिस्सा कस्टमाइज़ कर दिया था। बाद में उन्हें अपग्रेड करने में दिक्कत हुई और वेंडर का सपोर्ट भी गया।

ऊपर की बुनियादी बातें नहीं बदली हैं। आज किसी प्रोग्राम की शुरुआत में तीन चीज़ें तय होनी चाहिए।

सबसे पहले डिप्लॉयमेंट मॉडल। Public Edition में कस्टमाइज़ेशन के विकल्प सबसे सीमित होते हैं और सिस्टम SAP चलाता है। RISE के तहत Private Edition ज़्यादा गुंजाइश देता है और इन्फ्रास्ट्रक्चर SAP चलाता है। On-premise में सबसे ज़्यादा नियंत्रण और सबसे ज़्यादा ज़िम्मेदारी है। इसे Discover में तय करें। जो प्रोग्राम इसे टालते हैं, वे Explore इसी पर बहस करने में गँवा देते हैं।

Clean core चार्टर का हिस्सा होना चाहिए। Public Edition में एक्सटेंशन सिर्फ़ released interfaces से हो सकते हैं, इसलिए वह clean core को तकनीकी रूप से लागू करवाता है। Private Edition और on-premise में ऐसा नहीं होता, इसलिए यह गवर्नेंस का फ़ैसला बन जाता है। SAP अब एक्सटेंशन को लेवल A (सिर्फ़ released API) से लेकर लेवल D (मॉडिफ़िकेशन) तक वर्गीकृत करता है, जैसा उसके अगस्त 2025 के clean core अपडेट में बताया गया है। चार्टर में लक्ष्य लेवल और अप्रूवल फ़ोरम लिख दें, वरना पार्टनर मॉडिफ़िकेशन की ओर ही चले जाएँगे।

AI टूलिंग पहले दिन से मेथड का हिस्सा हो। Joule, SAP Activate Roadmap Viewer के अंदर उपलब्ध है। कंसल्टेंट्स के लिए Joule कॉन्फ़िगरेशन के सवालों के जवाब देता है, और डेवलपर्स के लिए Joule ABAP Cloud कोड बनाता है। ये ड्राफ़्टिंग और बिल्ड के कामों को तेज़ कर सकते हैं। ये बिज़नेस फ़ैसलों, डेटा के काम या चेंज की मेहनत को ख़त्म नहीं करते। अपने पार्टनर से पूछिए कि वे इन्हें कहाँ इस्तेमाल करते हैं और योजना में यह कैसे दिखता है।

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

तरीका	इसका मतलब	किसके लिए सबसे उपयुक्त
Big bang	सभी मॉड्यूल और एंटिटी एक साथ go-live करते हैं	स्टैंडर्ड स्कोप वाली छोटी कंपनियाँ, जो ऊँचा go-live जोखिम स्वीकार करती हैं
मॉड्यूल के अनुसार चरणबद्ध	पहले फ़ाइनेंस, फिर सप्लाई चेन, फिर HR	कम आपसी निर्भरता वाले मॉड्यूल; टीम को चरणों के बीच सीखने का मौका मिलता है
देश या एंटिटी के अनुसार चरणबद्ध	एक टेम्पलेट पहले एक एंटिटी में go-live करता है, फिर रोलआउट होता है	ग्लोबल टेम्पलेट वाले ग्रुप
Brownfield कन्वर्ज़न	मौजूदा ECC को S/4HANA में बदलना	स्थिर प्रक्रियाओं वाला परिपक्व ECC
Greenfield	नया S/4HANA इम्प्लीमेंटेशन	गैर-SAP लेगेसी, या भारी तकनीकी कर्ज़ वाला ECC
Selective data transition	चुनी हुई एंटिटी या डेटा को नए डिज़ाइन वाले सिस्टम में ले जाना	मर्जर, कार्व-आउट, आंशिक पुन: उपयोग

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

इसे पहले महीने में, कॉन्फ़िगरेशन शुरू होने से पहले इस्तेमाल करें। हर आइटम का क्लाइंट की ओर से एक ओनर है।

1. एग्ज़ीक्यूटिव स्पॉन्सर: डिप्लॉयमेंट मॉडल तय हो और कारणों के साथ दर्ज हो।
2. प्रोग्राम डायरेक्टर: चार्टर साइन हो, जिसमें स्कोप, स्पष्ट बहिष्करण, सफलता के मानदंड, निर्णय के अधिकार और चेंज कंट्रोल शामिल हों। मौखिक स्कोप समझौते हवा हो जाते हैं। मेरी प्रोजेक्ट चार्टर गाइड में एक टेम्पलेट है।
3. बिज़नेस लीड: हर क्षेत्र के लिए एक नामित प्रोसेस ओनर, जिसे वर्कशॉप में आने के लिए सच में समय दिया गया हो।
4. सॉल्यूशन आर्किटेक्ट: clean core का लक्ष्य और एक्सटेंशन अप्रूवल फ़ोरम तय हो।
5. डेटा लीड: डेटा प्रोफ़ाइलिंग Prepare में शुरू हो, डिज़ाइन साइन-ऑफ़ के बाद नहीं।
6. कटओवर लीड: Realize में नामित हो, और योजना में रिहर्सल की तारीख़ पहले से हो।
7. टेस्ट मैनेजर: पूरी प्रोसेस-चेन के टेस्ट सिनेरियो सूचीबद्ध हों, जिनमें अनुमोदन से लेकर फ़ाइनेंस पोस्टिंग तक शामिल हों।
8. CFO: टाइमलाइन की तुलना मिलते-जुलते प्रोग्राम से की गई हो, और धीमे Explore तथा अतिरिक्त डेटा साइकिल के लिए कंटिन्जेंसी रखी गई हो। जो योजना मानकर चलती है कि सब कुछ ठीक होगा, वह योजना नहीं है।

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

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

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

SAP Activate में छह चरण हैं: Discover, Prepare, Explore, Realize, Deploy और Run। Discover बिज़नेस केस और स्कोप तय करता है। Prepare गवर्नेंस और टीम खड़ी करता है। Explore fit-to-standard वर्कशॉप चलाता है और डिज़ाइन की पुष्टि करता है। Realize बनाता और टेस्ट करता है। Deploy में UAT, डेटा लोड, ट्रेनिंग और कटओवर आते हैं। Run यानी go-live और hypercare। हर चरण एक क्वालिटी गेट पर ख़त्म होता है।

SAP इम्प्लीमेंटेशन में कितना समय लगता है?

यह स्कोप पर और फ़ैसले कितनी तेज़ी से होते हैं, इस पर निर्भर करता है। मैंने छोटे रोलआउट छह महीने से कम में go-live करते देखे हैं, और ऐसे प्रोजेक्ट भी जो दो साल तक खिंचे क्योंकि फ़ैसले समय पर नहीं हुए। देरी की सबसे आम वजह धीमा Explore चरण है, जो उसके बाद की हर चीज़ को दबा देता है।

SAP इम्प्लीमेंटेशन फ़ेल होने की सबसे आम वजहें क्या हैं?

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

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

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

SAP go-live के बाद hypercare क्या होता है?

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