सीधे कंटेंट पर जाएँ

ERP इम्प्लीमेंटेशन KPI: 30 मेट्रिक जो सच में मायने रखते हैं

मैं जो 30 ERP इम्प्लीमेंटेशन KPI ट्रैक करता हूँ, डिलीवरी और go-live के बाद में बँटे हुए, फ़ॉर्मूलों, थ्रेशोल्ड और रिव्यू के समय के साथ। एक क्लाइंट ने 73 ‘छोटे’ बदलाव जोड़े और पाँच महीने गँवा दिए; स्कोप चेंज KPI इसी को रोकने के लिए हैं।

शाम के समय शहर की ओर खुलने वाली खिड़की के पास ऑफ़िस में लैपटॉप पर काम करते Noel D'Costa
विषय-सूची
  1. प्रोजेक्ट के दौरान (KPI 1 से 15)
  2. Go-live के बाद (KPI 16 से 30)
  3. फ़ॉर्मूले के साथ पाँच KPI
  4. कौन क्या रिव्यू करता है, और कब
  5. क्लाउड प्रोग्राम के लिए KPI
  6. Clean core लेवल का मिश्रण
  7. एक्सटेंशन की जगह तय होना
  8. SAP के साथ संबंध की सेहत
  9. KPI रिपोर्टिंग में AI कहाँ काम आता है
  10. एडॉप्शन की समस्या
  11. अक्सर पूछे जाने वाले सवाल

ERP इम्प्लीमेंटेशन के जो KPI मायने रखते हैं, वे गिने-चुने हैं। डिलीवरी के दौरान उनका रिव्यू हर हफ़्ते होता है और hypercare में हर दिन, और हर KPI का एक नामित ओनर होता है: शेड्यूल का पालन, कॉस्ट वेरिएंस, स्कोप चेंज, टेस्ट पास रेट, डेटा माइग्रेशन की सटीकता और सबसे ऊपर, यूज़र एडॉप्शन। नीचे वे 30 KPI हैं जो मैं इस्तेमाल करता हूँ, डिलीवरी और go-live के बाद में बँटे हुए, फ़ॉर्मूलों के साथ और उन थ्रेशोल्ड के साथ जो कार्रवाई शुरू करवानी चाहिए।

यह प्रोग्राम डायरेक्टर, PMO लीड और स्पॉन्सर के लिए है, जिन्हें ऐसा स्टीयरिंग पैक चाहिए जो समस्याएँ हफ़्ते 8 में पकड़े, महीने 18 में नहीं।

एक क्लाइंट ने एक बार SAP प्रोजेक्ट में 73 “छोटे” बदलाव जोड़ दिए। अकेले कोई भी बदलाव बड़ा नहीं लगा। साथ मिलकर उन्होंने पाँच महीने की देरी कर दी। स्कोप चेंज की संख्या किसी ने ट्रैक नहीं की थी। (अगर यह जाना-पहचाना लगता है, तो SAP प्रोजेक्ट में स्कोप क्रीप से बचने की मेरी गाइड में नियंत्रण के तरीके हैं।)

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

ये असामान्य विफलताएँ नहीं हैं। ऐसा तब होता है जब टीमें ग़लत चीज़ें ट्रैक करती हैं, या कुछ भी नहीं।

#KPIक्या मापता हैक्यों मायने रखता है
1शेड्यूल पालनटास्क का वास्तविक बनाम योजना के अनुसार पूरा होनाफैलती देरी का पहला संकेत
2कॉस्ट वेरिएंसचरण के हिसाब से वास्तविक खर्च बनाम बजटओवररन को जमा होने से पहले पकड़ता है
3स्कोप चेंज की संख्यामंज़ूर बदलावों की संख्या और असरबेकाबू बदलाव ओवररन की सबसे आम वजह है
4रिसोर्स उपयोगकाम किए गए घंटे बनाम योजना के घंटे, वर्कलोड का संतुलनज़्यादा बोझ वाले लोग थक जाते हैं या प्रोजेक्ट के बीच में छोड़ देते हैं
5यूज़र एडॉप्शन दरटारगेट यूज़र में से कितने सिस्टम सक्रिय रूप से इस्तेमाल कर रहे हैंअकेला पैमाना जो बताता है कि सिस्टम बिज़नेस के लिए काम कर रहा है
6ट्रेनिंग की प्रभावशीलताअसेसमेंट स्कोर, कितने यूज़र की ट्रेनिंग हुईgo-live से पहले ही एडॉप्शन की विफलता का अंदाज़ा देता है
7डेटा माइग्रेशन की सटीकतासाफ़ माइग्रेट हुए रिकॉर्ड का हिस्सा, एरर रेटनए सिस्टम में ख़राब डेटा साफ़ करने में महीनों लगते हैं
8टेस्ट एनवायरनमेंट डाउनटाइमटेस्ट सिस्टम में अनियोजित डाउनटाइम के घंटेटेस्ट में अस्थिरता go-live पर अस्थिरता की भविष्यवाणी करती है
9एंगेजमेंट स्कोरसर्वे के नतीजे, अहम सत्रों में उपस्थितिविरोध खुलकर सामने आने से पहले की शुरुआती चेतावनी
10रिस्क समाधान दरसमय पर बंद हुए खुले रिस्क का हिस्सासिर्फ़ पहचान नहीं, रिस्क बंद होने को मापें
11पार्टनर प्रदर्शनडिलीवरेबल की गुणवत्ता, माइलस्टोन पूरे होने की दरजो पार्टनर शुरू के डिलीवरेबल चूकते हैं, वे लगभग हमेशा बाद के भी चूकते हैं
12टेस्टिंग पास रेटपहली बार में पास होने वाले टेस्ट केस का हिस्साSIT में 85% से नीचे का मतलब आम तौर पर व्यवस्थागत समस्याएँ हैं, बिखरे हुए बग नहीं
13चेंज रिक्वेस्ट टर्नअराउंडरिक्वेस्ट से फ़ैसले तक के दिनलंबी कतारें गवर्नेंस की विफलता का संकेत हैं
14बजट बर्न रेटकुल बजट के मुकाबले खर्च, पूरे हुए काम के संदर्भ मेंदिखाता है कि पैसा और प्रगति साथ चल रहे हैं या नहीं
15कॉन्फ़िगरेशन प्रगतियोजना के कॉन्फ़िगरेशन आइटम में से पूरे हुए का हिस्सायहाँ की देरी टेस्टिंग और ट्रेनिंग को आगे धकेल देती है
#KPIक्या मापता हैथ्रेशोल्ड या टिप्पणी
16सिस्टम उपलब्धताgo-live के बाद अपटाइम99.9% से ऊपर अच्छा है, 99% से नीचे यह यूज़र के भरोसे की समस्या बन जाता है
17रिपोर्ट और डैशबोर्ड की गतिलोड टाइम, रिफ़्रेश रेटअगर मैनेजर Excel में एक्सपोर्ट कर रहे हैं, तो सिस्टम काम नहीं दे रहा
18कर्मचारी की उत्पादकताgo-live से पहले की बेसलाइन के मुकाबले टास्क का समयअप्रूवल ऑटोमेट करने वाले एक डिस्ट्रीब्यूशन क्लाइंट ने go-live के बाद रोज़ 25% ज़्यादा ट्रांज़ैक्शन प्रोसेस किए
19फ़र्स्ट कॉन्टैक्ट रिज़ॉल्यूशनपहले संपर्क में सुलझे टिकटhypercare कितना कारगर है, यह मापता है
20सपोर्ट टिकट की संख्याखुले टिकट, औसत समाधान समयदिन 30 के आसपास उछाल आम तौर पर ट्रेनिंग की कमी बताता है, सिस्टम के बग नहीं
21प्रोसेस साइकिल टाइमऑर्डर प्रोसेसिंग, इनवॉइस अप्रूवल, क्लोज़ साइकिलवह नतीजा जिसकी एग्ज़ीक्यूटिव को सच में परवाह होती है
22इन्वेंट्री सटीकताफ़िज़िकल बनाम सिस्टम की गिनतीgo-live के बाद डेटा क्वालिटी का सबसे साफ़ दिखने वाला संकेतक
23ऑर्डर फ़ुलफ़िलमेंट रेटनए सिस्टम में समय पर पूरे हुए ऑर्डरसीधा ऑपरेशनल असर
24रेवेन्यू एट्रिब्यूशननई क्षमताओं से जुड़े रेवेन्यू में बदलावबिज़नेस केस का लंबे समय का सबूत
25कंप्लायंस पालनऑडिट के निष्कर्ष, नियामक मुद्देफ़ाइनेंस, फ़ार्मा और नियंत्रित सेक्टर में सबसे ज़्यादा मायने रखता है
26फ़ोरकास्ट सटीकताफ़ोरकास्ट बनाम वास्तविक मांगदिखाता है कि प्लानिंग इस्तेमाल हो रही है और उस पर भरोसा किया जा रहा है
27यूज़र संतुष्टियूज़ेबिलिटी सर्वे, की-यूज़र NPSजिन यूज़र को सिस्टम से चिढ़ है, वे वर्कअराउंड बना लेते हैं
28प्रोसेस दक्षताबेसलाइन के मुकाबले प्रति प्रोसेस समय और लागतबोर्ड के सामने निवेश को सही ठहराता है
29हासिल बचतबिज़नेस केस के मुकाबले वास्तविक बचतCFO 6 और 12 महीने पर पूछेंगे
30निवेश पर रिटर्नशुद्ध लाभ को कुल लागत से भाग देनाआम तौर पर 12 और 24 महीने पर मापा जाता है

इनके बारे में लोग सबसे ज़्यादा पूछते हैं।

  1. शेड्यूल परफ़ॉर्मेंस इंडेक्स (SPI) = अर्न्ड वैल्यू ÷ प्लांड वैल्यू। 1.0 से ऊपर का मतलब शेड्यूल से आगे, 1.0 का मतलब समय पर, 1.0 से नीचे का मतलब देरी।
  2. कॉस्ट परफ़ॉर्मेंस इंडेक्स (CPI) = अर्न्ड वैल्यू ÷ वास्तविक लागत। 1.0 से ऊपर कुशल है, 1.0 से नीचे बजट से ज़्यादा।
  3. स्कोप चेंज प्रतिशत = (मंज़ूर बदलाव ÷ शुरुआती स्कोप आइटम) × 100। 10% से कम का असर न्यूनतम है, 20% से ऊपर का असर ऊँचा।
  4. यूज़र एडॉप्शन दर = (सक्रिय यूज़र ÷ टारगेट यूज़र) × 100। पहले 90 दिनों में 80% से ऊपर मज़बूत है, 60% से नीचे दख़ल की ज़रूरत है।
  5. डेटा माइग्रेशन सटीकता = (माइग्रेट हुए साफ़ रिकॉर्ड ÷ कोशिश किए गए रिकॉर्ड) × 100। go-live से पहले 98% से ऊपर हो, 95% से नीचे हो तो कटओवर टाल देना चाहिए।

SPI और CPI अर्न्ड वैल्यू मैनेजमेंट से आते हैं। ये तभी काम करते हैं जब “अर्न्ड वैल्यू” ईमानदारी से मापी जाए: तीन हफ़्ते से 90% पूरा बताया जा रहा टास्क अपनी वैल्यू का 90% नहीं होता।

रिव्यू की लय के बिना KPI सजावट भर हैं। यह वह कैडेंस है जो बनानी चाहिए।

हर KPI सेट का रिव्यू कब होता हैडिलीवरी में हर हफ़्ते, go-live के तुरंत बाद हर दिन। महीने में एक बार की समीक्षा तब देरी पकड़ती है जब वह ढाँचे में बैठ चुकी होती है।
  1. डिलीवरी के दौरानसाप्ताहिक प्रोग्राम बोर्डशेड्यूल, कॉस्ट, रिस्क, टेस्ट पास रेट, स्कोप चेंज। गेट वाले KPI SteerCo को जाते हैं
  2. दिन 1-30रोज़ाना hypercare रिव्यूउपलब्धता, टिकट की संख्या, विभाग के हिसाब से एडॉप्शन
  3. दिन 90 तकसाप्ताहिक एडॉप्शन रिव्यूएडॉप्शन, प्रोसेस साइकिल टाइम, टिकट की श्रेणियाँ
  4. महीने 6 और 12स्पॉन्सर और CFO रिव्यूउत्पादकता, हासिल बचत, ROI
कबKPIरिव्यू कौन करता हैकिस फ़ैसले में काम आता है
डिलीवरी के दौरान हर हफ़्तेशेड्यूल पालन, कॉस्ट वेरिएंस, रिस्क समाधान, टेस्ट पास रेट, स्कोप चेंज की संख्याप्रोग्राम बोर्डदोबारा प्लान करना, एस्केलेट करना या स्कोप रोकना
हर फ़ेज़ गेट परकॉन्फ़िगरेशन प्रगति, ट्रेनिंग की प्रभावशीलता, डेटा माइग्रेशन की सटीकता, पार्टनर प्रदर्शनस्टीयरिंग कमेटीपास, शर्तों के साथ पास या रोक
go-live के बाद पहले 30 दिन हर दिनउपलब्धता, टिकट की संख्या और रुझान, विभाग के हिसाब से एडॉप्शनHypercare लीडफ़्लोर सपोर्ट और फ़िक्स कहाँ भेजने हैं
दिन 90 तक हर हफ़्तेएडॉप्शन, प्रोसेस साइकिल टाइम, टिकट की श्रेणियाँप्रोग्राम बोर्डरिफ़्रेशर ट्रेनिंग, कॉन्फ़िगरेशन के सुधार
6 और 12 महीने परउत्पादकता, हासिल बचत, ROI, संतुष्टिस्पॉन्सर और CFOबिज़नेस केस का साइन-ऑफ़, फ़ेज़ 2 का स्कोप

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

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

एक क्लाइंट ने 73 ‘छोटे’ बदलाव जोड़ दिए। उसके बाद आई पाँच महीने की देरी में छोटा कुछ नहीं था। स्कोप चेंज KPI इसी पैटर्न को अदृश्य होने से पहले रोकने के लिए हैं।

RISE with SAP और SAP GROW प्रोग्राम में गवर्नेंस के ऐसे सवाल जुड़ते हैं जिन्हें पुरानी सूची नहीं छूती। तीन अतिरिक्त पैमाने मदद करते हैं।

Clean core लेवल का मिश्रण

SAP अब एक्सटेंशन को चार clean core लेवल में ग्रेड करता है, A से D तक। लेवल A सिर्फ़ released API इस्तेमाल करता है, लेवल D clean नहीं है। हर लेवल पर एक्सटेंशन का हिस्सा ट्रैक करें, उन ABAP test cockpit जाँचों से जिनकी SAP सिफ़ारिश करता है।

Public edition में डिज़ाइन से ही सब कुछ लेवल A है। Private edition और on-premise में लेवल C या D का कोई भी एक्सटेंशन ऐसा कर्ज़ है जो अगले अपग्रेड पर सामने आएगा। Realize के दौरान हर हफ़्ते नए एक्सटेंशन अनुरोधों को इसी कसौटी पर जाँचें, और लेवल C या D की हर मंज़ूरी के लिए किसी को जवाबदेह बनाएँ।

एक्सटेंशन की जगह तय होना

फ़ॉर्मूला: (तय लेवल और जगह वाले एक्सटेंशन ÷ बैकलॉग के कुल एक्सटेंशन) × 100। Explore के अंत तक लक्ष्य 100% है। जिस एक्सटेंशन की जगह अब तक किसी ने तय नहीं की, वही डेडलाइन के दबाव में पुराने ढर्रे का मॉडिफ़िकेशन बन जाता है।

SAP के साथ संबंध की सेहत

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

AI मेट्रिक के आसपास के रिपोर्टिंग काम में उपयोगी है। वह रिव्यू की जगह नहीं लेता।

  1. SAP Cloud ALM के साथ Joule। SAP ने Cloud ALM में Joule जोड़ा है, इसलिए टीमें हर स्टेटस एक्सट्रैक्ट हाथ से बनाने की जगह प्रोजेक्ट और ऑपरेशन के डेटा से साधारण भाषा में सवाल पूछ सकती हैं।
  2. Power BI में Copilot। नीचे के डैशबोर्ड से स्टीयरिंग पैक के लिए विवरण का ड्राफ़्ट तैयार करता है। डेटा मॉडल साफ़ हो तो सबसे अच्छा चलता है।
  3. एनोमली डिटेक्शन। Power BI, Tableau और SAP Analytics Cloud ऐसे KPI को चिह्नित कर सकते हैं जो अपने सामान्य पैटर्न से भटकते हैं। रिसोर्स उपयोग, टिकट की संख्या और स्कोप चेंज रेट पर यह काम का है। ऊँचे प्राकृतिक उतार-चढ़ाव वाले मेट्रिक, जैसे रोज़ के ऑर्डर की गिनती, पर नहीं।

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

सबसे ज़्यादा असर वाला KPI यूज़र एडॉप्शन है, और ज़्यादातर टीमें इसे सबसे आख़िर में मापती हैं।

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

जो सिस्टम तकनीकी रूप से चलता है पर व्यवहार में बायपास हो जाता है, उसने कुछ नहीं दिया। चेंज मैनेजमेंट की रिसर्च भी यही कहती है: Prosci के लंबे समय से चल रहे अध्ययनों में पाया गया कि बेहतरीन चेंज मैनेजमेंट वाले प्रोजेक्ट कमज़ोर चेंज मैनेजमेंट वालों की तुलना में अपने उद्देश्य पूरे करने की सात गुना ज़्यादा संभावना रखते हैं।

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

सबसे अहम ERP इम्प्लीमेंटेशन KPI कौन सा है?

यूज़र एडॉप्शन दर। तकनीकी रूप से सफल इम्प्लीमेंटेशन, जिसे कोई इस्तेमाल न करे, बिज़नेस को कोई मूल्य नहीं देता। बाकी KPI (शेड्यूल, बजट, टेस्टिंग) एडॉप्शन की शर्तों की रक्षा करते हैं। एडॉप्शन बताता है कि वह हुआ या नहीं।

इसे go-live के बाद पहले हफ़्ते से, विभाग के हिसाब से ट्रैक करें। किसी एक टीम में कम एडॉप्शन आम तौर पर ट्रेनिंग की कमी या प्रोसेस डिज़ाइन की समस्या की ओर इशारा करता है, जिसे आप hypercare में अब भी ठीक कर सकते हैं।

ERP इम्प्लीमेंटेशन KPI का रिव्यू कितनी बार होना चाहिए?

शेड्यूल, कॉस्ट और रिस्क का रिव्यू डिलीवरी के दौरान हर हफ़्ते हो, स्टीयरिंग कमेटी में महीने में एक बार नहीं। फ़ेज़-गेट KPI का रिव्यू हर गेट पर। ऑपरेशनल KPI का रिव्यू go-live के बाद पहले 30 दिन हर दिन, फिर दिन 90 तक हर हफ़्ते।

SAP UAT के लिए स्वस्थ टेस्टिंग पास रेट कितना है?

सिस्टम इंटीग्रेशन टेस्टिंग में पहली बार में 85% से ऊपर पास होना स्वस्थ है। उससे नीचे का मतलब आम तौर पर बिखरे हुए बग नहीं, बल्कि प्रोसेस डिज़ाइन की कमियाँ या कॉन्फ़िगरेशन की गलतियाँ होता है।

अगर आप 85% से नीचे UAT में जाते हैं, तो रुकिए और जड़ की वजह ठीक कीजिए। जो SIT से छूटा, उसे UAT लगभग कभी साफ़ नहीं करती।

ERP प्रोजेक्ट में 20% से ऊपर के स्कोप चेंज प्रतिशत का क्या मतलब है?

प्रोजेक्ट को बीच रास्ते में दोबारा डिज़ाइन किया जा रहा है। ओवररन और देरी की संभावना बढ़ जाती है।

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

RISE with SAP प्रोग्राम के लिए कौन से KPI ख़ास हैं?

मानक 30 के ऊपर तीन: आपके एक्सटेंशन का clean core लेवल मिश्रण (A से D), तय लेवल और जगह वाले एक्सटेंशन का हिस्सा, और SAP के साथ संबंध की सेहत का तिमाही रिव्यू (एस्केलेशन, सर्विस लेवल, SAP के सक्सेस रिव्यू की गुणवत्ता)।

ERP इम्प्लीमेंटेशन पर ROI की गणना कैसे करें?

ROI = (शुद्ध लाभ ÷ कुल निवेश) × 100। शुद्ध लाभ वह मापने योग्य बचत और रेवेन्यू बढ़त है जो सिस्टम की वजह से हुई, घटाकर नए एनवायरनमेंट की चलाने की लागत। कुल निवेश में सॉफ़्टवेयर, इम्प्लीमेंटेशन, आंतरिक समय, ट्रेनिंग, डेटा माइग्रेशन और चालू सपोर्ट आते हैं।

रूढ़िवादी रहिए। पूरा लाभ शायद ही पहले साल में आता है। एक रैंप-अप मॉडल बनाइए: पहले साल में स्थिर अवस्था के लाभ का 50%, दूसरे साल में 80%, और तीसरे साल से 100%।

ERP इम्प्लीमेंटेशन के बजट ओवररन की मुख्य वजहें क्या हैं?

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

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

Noel D'Costa

लेखक

Noel D'Costa

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

अगला कदम

क्या आप अभी कोई ERP प्रोग्राम चला रहे हैं?

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