SAP इम्प्लीमेंटेशन टाइमलाइन की प्लानिंग: बचने लायक 5 गलतियाँ

SAP इम्प्लीमेंटेशन टाइमलाइन, Discover से हाइपरकेयर तक का फ़ेज़-दर-फ़ेज़ प्लान होती है। public cloud प्रोजेक्ट के लिए, सैकड़ों प्रोजेक्ट की समीक्षा करने वाले एक SAP प्रोडक्ट एक्सपर्ट के मुताबिक़ सामान्य go-live पाँच से सात महीने में होता है। private cloud या on-premise पर एंटरप्राइज़ प्रोग्राम में एक साल से काफ़ी ज़्यादा लगता है। आपका प्लान टिकेगा या नहीं, यह पद्धति से कम और पाँच प्लानिंग गलतियों से ज़्यादा तय होता है: स्कोप से पहले लॉक की गई तारीखें, देर से शुरू हुआ डेटा माइग्रेशन, छोड़े गए क्वालिटी गेट, बहुत जल्दी दी गई ट्रेनिंग और peak season में go-live। यह गाइड उन प्रोग्राम डायरेक्टरों और स्पॉन्सरों के लिए है जो प्लान बना रहे हैं या किसी बिगड़े हुए प्लान को बचा रहे हैं। फ़ेज़ टेबल को अपना ढाँचा बनाइए, फिर उसे इन पाँच गलतियों की कसौटी पर परखिए। देरी का हर अतिरिक्त महीना कंसल्टिंग फ़ीस में $100,000 या उससे ज़्यादा जोड़ सकता है।

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

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

ज़्यादातर ओवररन पाँच गलतियों से होते हैं। हर गलती का पहले से अंदाज़ा लग सकता है और हर एक का इलाज मौजूद है।

गलती 1: स्कोप समझे बिना डेडलाइन तय करना

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

इसका हल: टाइमलाइन Explore के बाद लॉक कीजिए, kickoff पर नहीं, और यह बात बोर्ड को शुरू में ही बता दीजिए। वेंडर के अनुमान के ऊपर 15-20% बफ़र रखिए।

गलती 2: डेटा माइग्रेशन को ऐसा वर्कस्ट्रीम मानना जो देर से शुरू होता है

ज़्यादातर टीमें डेटा माइग्रेशन लीड की नियुक्ति देर से करती हैं और इस काम पर कम संसाधन लगाती हैं। शुरुआती डेटा असेसमेंट लगभग हमेशा समस्या को कम करके आँकते हैं। इसके बाद लाइव सिस्टम के दबाव में तीन महीने की सफ़ाई चलती है।

इसका हल: डेटा प्रोफ़ाइलिंग Discover में शुरू कीजिए, Realize में नहीं। इंटीग्रेशन टेस्टिंग शुरू होने से पहले Realize में पूरा मॉक माइग्रेशन चलाइए। मॉक फ़ेल हो जाए, तो ठीक करने का समय आपके पास रहता है। कटओवर पर पता चले, तो नहीं रहता। मेरा लेख SAP डेटा माइग्रेशन क्यों फ़ेल होता है मॉक साइकल को विस्तार से समझाता है।

गलती 3: शेड्यूल के दबाव में क्वालिटी गेट छोड़ देना

Realize और Deploy के बीच का गेट वही है जिसे टीमें सबसे ज़्यादा छोड़ती हैं, क्योंकि “बस go-live कर दो” का दबाव वहीं सबसे ज़्यादा होता है। “शेड्यूल पर बने रहने” के लिए क्वालिटी गेट छोड़ने से बाद में और बड़ी देरी होती है।

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

गलती 4: go-live से दो महीने पहले यूज़र्स को ट्रेनिंग देना

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

इसका हल: ट्रेनिंग go-live से दो से तीन हफ़्ते पहले रखिए। पावर यूज़र्स को ट्रेनर बनाइए, क्योंकि लोग उन्हीं सहकर्मियों से सीखते हैं जिन पर उन्हें भरोसा होता है। रिफ़्रेशर सेशन हाइपरकेयर के दौरान रखिए। पूरा तरीक़ा मेरे SAP ट्रेनिंग रणनीतियों वाले लेख में है।

गलती 5: peak बिज़नेस साइकल में go-live शेड्यूल करना

Hershey ने जुलाई 1999 में अपने SAP R/3, Siebel और Manugistics सिस्टम पर go-live किया। यह योजना से तीन महीने देर से हुआ और सीधे Halloween के ऑर्डर सीज़न में जा पड़ा। उसके CEO ने विश्लेषकों से कहा कि इन समस्याओं की वजह से Hershey $100 मिलियन के Halloween ऑर्डर डिलीवर नहीं कर पाएगी। सबक साफ़ है, फिर भी आज तक अनदेखा किया जाता है।

इसका हल: असर में आने वाली हर बिज़नेस यूनिट के peak साइकल, यानी month-end और quarter-end क्लोज़ समेत, मैप कीजिए। कम वॉल्यूम वाली विंडो में go-live कीजिए, भले ही इसके लिए छह हफ़्ते खिसकाना पड़े। यह खिसकाव सँभाला जा सकता है। peak सीज़न में नाकाम go-live नहीं सँभलता।

SAP Activate ने पुरानी ASAP पद्धति की जगह ली। इसके छह फ़ेज़ किसी भी S/4HANA प्लान का ढाँचा हैं, चाहे cloud हो या on-premise। नीचे दी गई अवधियाँ एंटरप्राइज़ प्रोग्राम के लिए प्लानिंग की शुरुआती बिंदु हैं, वादे नहीं।

1. 1Discover2 से 4 सप्ताह। Exit: साइन-ऑफ़ हुआ स्कोप और सफलता के क्राइटेरिया
2. 2Prepare3 से 6 सप्ताह। Exit: चार्टर मंज़ूर, संसाधन लिखित में
3. 3Explore4 से 8 सप्ताह। Exit: गैप के फ़ैसलों के मालिक तय, टाइमलाइन लॉक
4. 4Realize8 से 16 सप्ताह। Exit: मॉक माइग्रेशन पास, इंटीग्रेशन टेस्ट बंद
5. 5Deploy2 से 4 सप्ताह। Exit: UAT साइन-ऑफ़, क्लोज़ रिहर्सल, go/no-go
6. 6Run4 से 8 सप्ताह का हाइपरकेयर। Exit: डिफ़ेक्ट सीमा से नीचे, सपोर्ट साइन-ऑफ़

फ़ेज़	सामान्य अवधि	क्या होता है	आगे बढ़ने से पहले एग्ज़िट गेट
Discover	2-4 सप्ताह	बिज़नेस केस, स्कोप, डिप्लॉयमेंट का चुनाव (public cloud, private cloud या on-premise)	साइन-ऑफ़ हुआ स्कोप और नापे जा सकने वाले सफलता के क्राइटेरिया
Prepare	3-6 सप्ताह	टीम ऑनबोर्डिंग, गवर्नेंस, सिस्टम लैंडस्केप, बेसलाइन प्लान, रिस्क रजिस्टर	चार्टर मंज़ूर, हर मॉड्यूल के लिए नामित फ़ैसला लेने वाले, संसाधनों की लिखित प्रतिबद्धता
Explore	4-8 सप्ताह	Fit-to-Standard वर्कशॉप, गैप लॉग, RICEFW इन्वेंटरी (रिपोर्ट, इंटरफ़ेस, कन्वर्ज़न, एन्हांसमेंट, फ़ॉर्म, वर्कफ़्लो)	गैप के फ़ैसले मालिकों के साथ दर्ज, टाइमलाइन लॉक
Realize	8-16 सप्ताह	कॉन्फ़िगरेशन, डेवलपमेंट, यूनिट और इंटीग्रेशन टेस्टिंग, मॉक माइग्रेशन	मॉक माइग्रेशन पास, इंटीग्रेशन टेस्ट बंद
Deploy	2-4 सप्ताह	यूज़र एक्सेप्टेंस टेस्टिंग, कटओवर रिहर्सल, एंड-यूज़र ट्रेनिंग, फ़ाइनल लोड	UAT साइन-ऑफ़, क्लोज़ रिहर्सल पास, go/no-go
Run	4-8 सप्ताह का हाइपरकेयर	फ़्लोर सपोर्ट, रोज़ की ट्राइएज, सपोर्ट को हैंडओवर	खुले डिफ़ेक्ट तय सीमा से नीचे, सपोर्ट ट्रांज़िशन पर साइन-ऑफ़

समय असल में जाता कहाँ है

Discover में जल्दबाज़ी हो जाती है। टीमें स्कोप समझने से पहले डेडलाइन तय कर देती हैं और नापे जा सकने वाले सफलता के क्राइटेरिया छोड़ देती हैं। आपको “month-end close तीन दिन घटाना” जैसे लक्ष्य चाहिए।

Prepare में तकनीकी देरी की शुरुआत होती है। RISE with SAP पर इन्फ़्रास्ट्रक्चर SAP देता है। on-premise में क्लाइंट और पार्टनर उसे खुद बनाते हैं, और यहाँ की चूक आगे तक फैलती है। संसाधनों की प्रतिबद्धता लिखित में लीजिए। ज़बानी उपलब्धता हवा हो जाती है।

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

Realize सबसे लंबा फ़ेज़ है और ज़्यादातर ओवररन यहीं आते हैं, आम तौर पर इसलिए कि Explore ने गैप की आशावादी सूची दी थी। आपका पहला मॉक माइग्रेशन फ़ेल होगा। आपको वह टेस्टिंग में फ़ेल चाहिए, प्रोडक्शन में नहीं। लगातार 60-घंटे के हफ़्ते गलतियों और लोगों के नौकरी छोड़ने की वजह बनते हैं।

Deploy के लिए ऐसा कटओवर प्लान चाहिए जिसमें सटीक कदम, समय और ज़िम्मेदार लोग हों। “डेटा माइग्रेट करो” कोई कदम नहीं है।

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

मैंने एक हेल्थकेयर प्रोवाइडर के साथ काम किया जो शेड्यूल से तीन महीने पीछे था और जिस पर $2 मिलियन का बजट ओवररन मँडरा रहा था। हमने SAP Activate की Fit-to-Standard वर्कशॉप से रीसेट किया। टीम को 28 फ़ाइनेंस और सप्लाई चेन प्रोसेस मिले जिन्हें बिना किसी कस्टमाइज़ेशन के चलाया जा सकता था। उनके प्रोजेक्ट मैनेजर के शब्द थे: “हमने महीनों उन चीज़ों को डिज़ाइन करने में गँवाए जो SAP में पहले से बनी हुई थीं।” वे छह हफ़्ते में शेड्यूल पर लौट आए और समय पर go-live किया।

मैंने एक रिटेल कंपनी के साथ काम किया जिसने पाया कि उसकी 70% ज़रूरतें स्टैंडर्ड SAP प्रोसेस से पूरी हो जाती हैं। वह बड़े पैमाने पर कस्टमाइज़ेशन की योजना बना रही थी, जब तक उसने सिस्टम को चलते नहीं देखा।

क्लीन कोर इसे और धार देता है। S/4HANA Cloud Public Edition में स्टैंडर्ड प्रोसेस ही एकमात्र विकल्प हैं और एक्सटेंशन SAP BTP या रिलीज़ किए गए API पर रहते हैं। private cloud और on-premise में आप अब भी बदलाव कर सकते हैं, पर SAP की क्लीन कोर गाइडेंस भी उसी दिशा में धकेलती है। जब हर गैप के लिए BTP एक्सटेंशन का फ़ैसला करना पड़े और उसके साथ लागत जुड़ी हो, तो कस्टमाइज़ेशन की बातचीत ज़्यादा ईमानदार हो जाती है।

टाइमलाइन पर डिप्लॉयमेंट मॉडल का असर किसी भी दूसरे चुनाव से ज़्यादा पड़ता है।

1. Public cloud (GROW with SAP, S/4HANA Cloud Public Edition, जो अब SAP Cloud ERP के नाम से बिकता है)। सैकड़ों प्रोजेक्ट की समीक्षा करने वाले एक SAP प्रोडक्ट एक्सपर्ट के मुताबिक़ सामान्य go-live पाँच से सात महीने में होता है। 2026 की शुरुआत में लॉन्च हुई SAP की GROW Fast पेशकश तय स्कोप पर दो से चार महीने का लक्ष्य रखती है। बड़े public cloud प्रोजेक्ट 12 महीने या उससे ज़्यादा चलते हैं।
2. Private cloud (RISE with SAP, अब SAP Cloud ERP Private) और on-premise। एंटरप्राइज़ स्कोप में आम तौर पर 12-24 महीने लगते हैं। RISE पर इन्फ़्रास्ट्रक्चर SAP चलाता है, जिससे Prepare का कुछ काम घट जाता है। डेटा, टेस्टिंग और चेंज का काम फिर भी घटता नहीं।

इंडस्ट्री अपना अलग बोझ जोड़ती है। ये पूरे S/4HANA एंटरप्राइज़ प्रोग्राम की सामान्य रेंज हैं:

इंडस्ट्री	प्लानिंग रेंज	समय किससे बढ़ता है
मैन्युफ़ैक्चरिंग	14-20 महीने	BOM और राउटिंग की क्वालिटी, MRP ट्यूनिंग, QM की ज़रूरतें
रिटेल और कंज़्यूमर गुड्स	12-18 महीने	POS इंटीग्रेशन, मास्टर डेटा का वॉल्यूम, peak सीज़न की विंडो
फ़ार्मास्यूटिकल्स	16-22 महीने	GxP वैलिडेशन, बैच ट्रेसेबिलिटी, सीरियलाइज़ेशन
यूटिलिटीज़	15-20 महीने	डिवाइस मैनेजमेंट, बिलिंग रेट स्ट्रक्चर, GIS और SCADA इंटीग्रेशन
सार्वजनिक क्षेत्र	18-24 महीने	फ़ंड अकाउंटिंग, ख़रीद के नियम, अनुमोदन का बोझ, डेटा रेज़िडेंसी
ऑटोमोटिव	16-22 महीने	जस्ट-इन-टाइम सप्लाई चेन, इंजीनियरिंग चेंज कंट्रोल
एयरोस्पेस और डिफ़ेंस	20-26 महीने	सरकारी रिपोर्टिंग, प्रोग्राम अकाउंटिंग, सुरक्षित सप्लाई चेन
ऑयल और गैस	18-24 महीने	जॉइंट वेंचर अकाउंटिंग, एसेट-भारी ऑपरेशन
फ़ाइनेंशियल सर्विसेज़	14-20 महीने	सेग्रिगेशन ऑफ़ ड्यूटीज़ रोल डिज़ाइन, नियामकीय वैलिडेशन

AI टूल्स क्या बदलते हैं और क्या नहीं

SAP Joule for Consultants 2025 में सामान्य रूप से उपलब्ध हुआ। यह SAP के अपने नॉलेज बेस, SAP Notes समेत, से कॉन्फ़िगरेशन के सवालों के जवाब देता है और ABAP कोड समझाता है। SAP Build Code मार्च 2024 से सामान्य रूप से उपलब्ध है और Joule के साथ SAP BTP पर Java और JavaScript एक्सटेंशन कोड बनाता है।

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

ये वे जोखिम हैं जिन्हें मैं हफ़्ते के प्रोग्राम एजेंडा में रखता हूँ। इनमें से कोई भी महीने की स्टीयरिंग कमेटी के लिए छोड़ दिया जाए, तो तारीखें खिसकने लगती हैं।

1. स्कोप में देर से बदलाव। स्कोप Explore के अंत में लॉक कीजिए। उसके बाद हर बदलाव को चेंज कंट्रोल बोर्ड मंज़ूर करे, टाइमलाइन और बजट पर उसके असर के साथ।
2. डेटा क्वालिटी। ज़्यादातर कंपनियाँ प्लानिंग के दौरान डेटा असेसमेंट छोड़ देती हैं। अभी शुरू कीजिए। ख़राब डेटा, मॉक माइग्रेशन फ़ेल होने की सबसे लगातार वजह है।
3. संसाधनों की अड़चनें। विभाग प्रमुखों से नामित लोगों और तारीखों की लिखित प्रतिबद्धता लीजिए। हर अहम भूमिका के लिए एक बैकअप तैयार कीजिए।
4. फ़ैसलों में देरी। स्कोप के मतभेद 48 घंटे के भीतर एस्केलेट कीजिए। फ़ैसलों को महीने की समीक्षा तक कतार में मत पड़े रहने दीजिए।
5. चेंज मैनेजमेंट देर से शुरू करना। एंड यूज़र्स से बात Prepare में शुरू कीजिए, go-live से दो हफ़्ते पहले नहीं।

एक रिस्क असेसमेंट मैट्रिक्स इस सूची को ऐसी चीज़ बना देता है जिसे स्टीयरिंग कमेटी स्कोर कर सके।

टूलिंग पर: SAP Cloud ALM, इम्प्लीमेंटेशन मैनेजमेंट के लिए SAP का मुख्य प्लेटफ़ॉर्म है। SAP Solution Manager 7.2 की मेनस्ट्रीम मेंटेनेंस 2027 के अंत में ख़त्म होती है। जो ग्राहक Business Suite की एक्सटेंडेड मेंटेनेंस लेते हैं, उनके लिए चुनिंदा फ़ंक्शन की एक्सटेंडेड मेंटेनेंस 2030 तक चलती है। SAP Best Practices Explorer 2023 में रिटायर हो गया। प्रोसेस कंटेंट अब SAP Signavio Process Navigator में है।

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

यह डिप्लॉयमेंट मॉडल, स्कोप और इंडस्ट्री पर निर्भर करता है। सैकड़ों प्रोजेक्ट की समीक्षा करने वाले एक SAP प्रोडक्ट एक्सपर्ट के मुताबिक़ S/4HANA Cloud Public Edition में पाँच से सात महीने लगते हैं, और SAP की तय-स्कोप वाली GROW Fast पेशकश में दो से चार। RISE with SAP private cloud या on-premise पर एंटरप्राइज़ प्रोग्राम में आम तौर पर 12 से 24 महीने लगते हैं। सार्वजनिक क्षेत्र और एयरोस्पेस के प्रोग्राम अक्सर 20 महीने से आगे निकल जाते हैं।

RISE with SAP टाइमलाइन को कैसे प्रभावित करता है?

RISE इन्फ़्रास्ट्रक्चर की ज़िम्मेदारी SAP पर डाल देता है, जिससे Prepare फ़ेज़ का कुछ काम घट जाता है। यह डेटा माइग्रेशन, टेस्टिंग, ट्रेनिंग और फ़ैसले लेने का समय नहीं घटाता, जबकि ज़्यादातर समय वहीं जाता है। क्लीन कोर का अनुशासन Realize को छोटा कर सकता है, अगर वह कस्टम डेवलपमेंट को शुरू होने से पहले ही रोक दे।

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

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

SAP इम्प्लीमेंटेशन के समय को कौन-से कारक प्रभावित करते हैं?

सबसे बड़े कारक हैं स्कोप (मॉड्यूल, एंटिटी, इंटीग्रेशन), कस्टमाइज़ेशन की मात्रा, डेटा क्वालिटी, यूज़र्स की संख्या और भूगोल, फ़ैसलों की रफ़्तार और नियामकीय वैलिडेशन। डिप्लॉयमेंट मॉडल इन सबके ऊपर बैठता है। public cloud सबसे तेज़ है क्योंकि वहाँ स्कोप और प्रोसेस सीमित रहते हैं। भारी कस्टमाइज़ेशन वाला on-premise सबसे धीमा है।

SAP इम्प्लीमेंटेशन को तेज़ कैसे करें?

Fit-to-Standard सख़्ती से चलाइए, क्योंकि आप जो भी कस्टमाइज़ेशन टाल देते हैं, उससे हफ़्ते बचते हैं। डेटा क्लीनिंग Discover में शुरू कीजिए। बिज़नेस के लोगों को पार्ट-टाइम उधार लेने के बजाय फ़ुल-टाइम दीजिए। कॉन्फ़िगरेशन शुरू होने से पहले अनुमोदन के रास्ते तय कर लीजिए और कटओवर प्लान Realize के बाद नहीं, Realize के दौरान तैयार कीजिए।

SAP रोलआउट बिग बैंग रखें या चरणबद्ध?

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

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

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

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

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