
विषय-सूची
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 महीने पर मापा जाता है |
इनके बारे में लोग सबसे ज़्यादा पूछते हैं।
- शेड्यूल परफ़ॉर्मेंस इंडेक्स (SPI) = अर्न्ड वैल्यू ÷ प्लांड वैल्यू। 1.0 से ऊपर का मतलब शेड्यूल से आगे, 1.0 का मतलब समय पर, 1.0 से नीचे का मतलब देरी।
- कॉस्ट परफ़ॉर्मेंस इंडेक्स (CPI) = अर्न्ड वैल्यू ÷ वास्तविक लागत। 1.0 से ऊपर कुशल है, 1.0 से नीचे बजट से ज़्यादा।
- स्कोप चेंज प्रतिशत = (मंज़ूर बदलाव ÷ शुरुआती स्कोप आइटम) × 100। 10% से कम का असर न्यूनतम है, 20% से ऊपर का असर ऊँचा।
- यूज़र एडॉप्शन दर = (सक्रिय यूज़र ÷ टारगेट यूज़र) × 100। पहले 90 दिनों में 80% से ऊपर मज़बूत है, 60% से नीचे दख़ल की ज़रूरत है।
- डेटा माइग्रेशन सटीकता = (माइग्रेट हुए साफ़ रिकॉर्ड ÷ कोशिश किए गए रिकॉर्ड) × 100। go-live से पहले 98% से ऊपर हो, 95% से नीचे हो तो कटओवर टाल देना चाहिए।
SPI और CPI अर्न्ड वैल्यू मैनेजमेंट से आते हैं। ये तभी काम करते हैं जब “अर्न्ड वैल्यू” ईमानदारी से मापी जाए: तीन हफ़्ते से 90% पूरा बताया जा रहा टास्क अपनी वैल्यू का 90% नहीं होता।
रिव्यू की लय के बिना KPI सजावट भर हैं। यह वह कैडेंस है जो बनानी चाहिए।
- डिलीवरी के दौरानसाप्ताहिक प्रोग्राम बोर्डशेड्यूल, कॉस्ट, रिस्क, टेस्ट पास रेट, स्कोप चेंज। गेट वाले KPI SteerCo को जाते हैं
- दिन 1-30रोज़ाना hypercare रिव्यूउपलब्धता, टिकट की संख्या, विभाग के हिसाब से एडॉप्शन
- दिन 90 तकसाप्ताहिक एडॉप्शन रिव्यूएडॉप्शन, प्रोसेस साइकिल टाइम, टिकट की श्रेणियाँ
- महीने 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 मेट्रिक के आसपास के रिपोर्टिंग काम में उपयोगी है। वह रिव्यू की जगह नहीं लेता।
- SAP Cloud ALM के साथ Joule। SAP ने Cloud ALM में Joule जोड़ा है, इसलिए टीमें हर स्टेटस एक्सट्रैक्ट हाथ से बनाने की जगह प्रोजेक्ट और ऑपरेशन के डेटा से साधारण भाषा में सवाल पूछ सकती हैं।
- Power BI में Copilot। नीचे के डैशबोर्ड से स्टीयरिंग पैक के लिए विवरण का ड्राफ़्ट तैयार करता है। डेटा मॉडल साफ़ हो तो सबसे अच्छा चलता है।
- एनोमली डिटेक्शन। 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 के बाद का सपोर्ट खर्च बढ़ा देता है।
हर हफ़्ते कॉस्ट वेरिएंस ट्रैक करना और औपचारिक स्कोप कंट्रोल पहली वजह सँभालते हैं। डेटा क्वालिटी का शुरुआती आकलन दूसरी सँभालता है। यथार्थवादी वॉल्यूम के साथ शुरुआती इंटीग्रेशन टेस्टिंग तीसरी सँभालती है। शुरू से चेंज मैनेजमेंट चौथी सँभालता है।
अगला कदम
क्या आप अभी कोई ERP प्रोग्राम चला रहे हैं?
अगर यह लेख किसी ऐसे प्रोग्राम से जुड़ा है जिसमें आप अभी काम कर रहे हैं, तो 30 मिनट की बातचीत अक्सर एक और हफ़्ते के अंदरूनी विश्लेषण से ज़्यादा आगे ले जाती है।




