विषय-सूची
स्ट्रक्चर्ड थिंकिंग वह तरीक़ा है जिससे एक कंसल्टेंट क्लाइंट की धुँधली, उलझी समस्या से ऐसी सिफ़ारिश तक पहुँचता है जिसे कमरे में बैठे लोग समझ भी सकें और उस पर सवाल भी उठा सकें। आप फ़ैसले को फ़्रेम करते हैं, समस्या को ऐसे हिस्सों में बाँटते हैं जो आपस में टकराते नहीं, सबसे संभावित जवाब को पहले परखते हैं, और फिर नतीजों को एक साफ़ सिफ़ारिश में समेट देते हैं।
यह लेख उन कंसल्टेंट और एनालिस्ट के लिए है जो दबाव में भी यही काम दोहराने लायक़ तरीक़े से करना चाहते हैं। इसमें वे चार टूल हैं जिन पर मैं भरोसा करता हूँ, एक पन्ने की वर्कशीट जो आप अपने अगले इंगेजमेंट में इस्तेमाल कर सकते हैं, और यह कि AI ने इस हुनर में क्या बदला है।
मैंने लोगों को क्लाइंट मीटिंग में जम जाते देखा है। इसलिए नहीं कि उनके पास विचार नहीं थे। इसलिए कि उन्हें पता नहीं था कि शुरू कहाँ से करें।
माहौल जाना-पहचाना है। एक जटिल समस्या, वरिष्ठ लोगों से भरा कमरा, धुँधला स्कोप और स्पष्टता की उम्मीद। बिना स्ट्रक्चर वाला जवाब यह होता है कि बोलना शुरू कर दो और उम्मीद रखो कि जवाब निकल आएगा। कभी निकल भी आता है। ज़्यादातर बार आप बीस मिनट गोल-गोल घूमते रहते हैं और कोई संतुष्ट होकर नहीं उठता।
यह किसी अस्पष्ट समस्या को उसके हिस्सों में बाँटने, हर हिस्से पर क्रम से काम करने और नतीजों को वापस जोड़कर एक सिफ़ारिश बनाने का अभ्यास है।
यह टेम्पलेट भरकर उसे एनालिसिस कह देना नहीं है। यह किसी ऐसी समस्या पर फ़्रेमवर्क ज़बरदस्ती थोपना भी नहीं है जिस पर वह फ़िट नहीं बैठता। जो कंसल्टेंट हर स्थिति पर 2x2 मैट्रिक्स लगा देता है, वह पैटर्न मिला रहा है, सोच नहीं रहा।
आप दरअसल कुछ क्षमताएँ विकसित कर रहे हैं:
- असली समस्या को पहचानना, जो अक्सर पेश की गई समस्या से अलग होती है
- उसे ऐसे हिस्सों में बाँटना जिनका अलग-अलग विश्लेषण हो सके
- यह जानना कि कौन-सी जानकारी मायने रखती है और कौन-सी नहीं
- जो मिले, उससे एक सुसंगत तर्क खड़ा करना
- कमरे में तनाव हो तब भी उसे साफ़ शब्दों में कह पाना
ये क्षमताएँ विकसित होने तक फ़्रेमवर्क सहारे का काम करते हैं। अगर आप पूरा टूलकिट चाहते हैं, तो आम फ़्रेमवर्क मैंने सरल भाषा में कंसल्टिंग फ़्रेमवर्क में कवर किए हैं।
फ़्रेमिंग सवाल
किसी भी फ़्रेमवर्क से पहले एक सवाल पूछिए। कौन-सा फ़ैसला लेना है, और कौन-सी जानकारी उस फ़ैसले को बदल देगी?
एनालिसिस की गुणवत्ता के लिए यह किसी भी स्ट्रक्चरल टूल से ज़्यादा काम करता है। यह आउटपुट को लेकर स्पष्टता मजबूर करता है और आपको ऐसे सवाल पर बारीकी से काम करने से रोकता है जिसका जवाब किसी को चाहिए ही नहीं था। HBR ने सालों पहले Are You Solving the Right Problem? में यही बात रखी थी: ज़्यादातर बेकार गई मेहनत एक ख़राब ढंग से परिभाषित समस्या से शुरू होती है।
SAP के संदर्भ में “इस संगठन के लिए कौन-सा डिप्लॉयमेंट मॉडल ठीक बैठता है” एक फ़ैसला है। “S/4HANA क्या है” एक विवरण है। पहले के लिए एनालिसिस चाहिए। दूसरे के लिए डॉक्यूमेंटेशन। आप कौन-सा काम कर रहे हैं, यह जानना ही तय करता है कि आपका हफ़्ता कैसे जाएगा।
MECE
MECE का मतलब है Mutually Exclusive, Collectively Exhaustive। जब आप किसी समस्या को हिस्सों में बाँटते हैं, तो हर हिस्सा अलग होना चाहिए (कोई ओवरलैप नहीं) और सब मिलकर पूरी समस्या को कवर करें (कोई ख़ाली जगह नहीं)।
ओवरलैप करने वाली श्रेणियाँ दोहरी गिनती करती हैं। ख़ाली जगहों में चीज़ें छूट जाती हैं। ज़्यादातर कंसल्टेंट इस शब्द को जानते हैं। गिने-चुने इसे सख़्ती से लागू करते हैं।
दो परीक्षण इसे ईमानदार रखते हैं। पहला, क्या कोई मद एक साथ दो शाखाओं में आ सकती है? तो शाखाएँ ओवरलैप कर रही हैं। दूसरा, अगर हर शाखा का जवाब मिल जाए, तो क्या केंद्रीय सवाल का जवाब भी मिल जाएगा? नहीं, तो कहीं ख़ाली जगह है। परफ़ेक्ट MECE बहुत कम मिलता है। असली बात यह है कि आप हर बार ये दोनों सवाल पूछें।
इश्यू ट्री
इश्यू ट्री में केंद्रीय सवाल जड़ में होता है और उप-सवाल शाखाओं पर। हर शाखा का विश्लेषण अलग से किया जा सकता है।
मान लीजिए सवाल है “इस SAP go-live का ख़र्च योजना से 40% ज़्यादा क्यों हुआ?” पहला बँटवारा हो सकता है: स्कोप में बदलाव, रिसोर्स लागत, टाइमलाइन का खिंचना और बिना योजना के सुधार का काम। स्कोप में बदलाव आगे बँटता है: औपचारिक चेंज रिक्वेस्ट, अनौपचारिक जोड़ और देर से सामने आई कमियाँ। हर लीफ़ को मापा जा सकता है।
इश्यू ट्री की असली क़ीमत इंगेजमेंट की शुरुआत में है, जब आपने कोई एनालिसिस शुरू ही नहीं किया होता। ये आपको एक शाखा पर तीन हफ़्ते लगाने से रोकते हैं, जबकि दूसरी शाखा को छुआ तक नहीं गया होता।
हाइपोथीसिस-ड्रिवन एनालिसिस
सारा डेटा जमा करके फिर नतीजे पर पहुँचने के बजाय, आप सबसे संभावित जवाब से शुरू करते हैं और उसे परखते हैं। स्ट्रैटेजी फ़र्मों ने अपनी साख इसी तरीक़े पर बनाई है।
सीमित समय और जटिल समस्या में हर चीज़ का पूरा विश्लेषण संभव नहीं होता। अच्छी हाइपोथीसिस बताती है कि पहले क्या देखना है। अगर वह टिकती है, तो आपके पास जवाब है। अगर टूटती है, तो जिस सबूत ने उसे तोड़ा, वह अक्सर किसी काम की दिशा दिखा देता है।
यह वही तरीक़ा भी है जिसका सबसे ज़्यादा ग़लत इस्तेमाल होता है। कंसल्टेंट एक हाइपोथीसिस बना लेते हैं और फिर सिर्फ़ वही सबूत खोजते हैं जो उसे सही ठहराए। पूछिए कि कौन-सा सबूत आपको ग़लत साबित कर देगा, और सबसे पहले वही खोजिए।
यह वह क्रम है जो मैं किसी नए कंसल्टेंट को उसके पहले डायग्नोस्टिक से पहले थमाता। एक भी स्प्रेडशीट खोलने से पहले इसे भर लीजिए।
- फ़्रेम करेंफ़ैसला, एक वाक्य में
- बाँटेंतीन से पाँच MECE सवाल
- हाइपोथीसिस बनाएँहर शाखा के लिए एक पंक्ति
- ग़लत साबित करेंवह सबूत जो आपको ग़लत साबित कर दे
- टेस्ट करेंहर शाखा के नतीजे, स्रोतों के साथ
- सिंथेसिस करेंपहले सिफ़ारिश, फिर उसका आधार
- प्रेशर-टेस्ट करेंकमरे में आपत्ति उठने से पहले ही उसका जवाब तैयार
ऐसी सिफ़ारिश जो स्टीयरिंग कमेटी में टिके
| कदम | जवाब देने वाला सवाल | आउटपुट | कौन साइन-ऑफ़ करता है |
|---|---|---|---|
| 1. फ़्रेम करें | क्लाइंट को कौन-सा फ़ैसला लेना है, और कब तक? | एक वाक्य | क्लाइंट स्पॉन्सर |
| 2. बाँटें | वे कौन-से तीन से पाँच सवाल हैं जिनके जवाब एक साथ मिलकर उस फ़ैसले को तय कर देते हैं? | पहले स्तर का इश्यू ट्री, MECE की कसौटी पर परखा हुआ | इंगेजमेंट लीड |
| 3. हाइपोथीसिस बनाएँ | मैं अभी क्या मानता हूँ कि जवाब क्या है, और क्यों? | हर शाखा के लिए एक पंक्ति की हाइपोथीसिस | इंगेजमेंट लीड |
| 4. ग़लत साबित करें | कौन-सा सबूत दिखाएगा कि हर हाइपोथीसिस ग़लत है? | डेटा रिक्वेस्ट की सूची, प्राथमिकता के क्रम में | क्लाइंट के डेटा ओनर इसे देने के लिए सहमत हों |
| 5. टेस्ट करें | सबूत क्या कहता है? | हर शाखा के नतीजे, स्रोतों के साथ | टीम में शाखाओं के ओनर |
| 6. सिंथेसिस करें | तो क्लाइंट को क्या करना चाहिए? | पहले सिफ़ारिश, फिर सहायक बिंदु | इंगेजमेंट लीड |
| 7. प्रेशर-टेस्ट करें | कमरे में कौन असहमत होगा, और किस बात पर? | आपत्तियाँ और उनके जवाब, तैयार | ऐसा सहकर्मी जो इस काम में शामिल नहीं था |
सातवाँ कदम वही है जिसे लोग छोड़ देते हैं। यही कदम तय करता है कि सिफ़ारिश स्टीयरिंग कमेटी में टिकेगी या नहीं।
एक SAP ग्राहक, एक बड़ा मैन्युफ़ैक्चरिंग ग्रुप, भारी कस्टमाइज़ेशन वाला ECC लैंडस्केप चला रहा था। IT लीड ने साफ़ कहा: “हमें ऑपरेटिंग लागत घटानी है, लेकिन हम कुछ भी टूटने का जोखिम नहीं उठा सकते।”
सहज प्रवृत्ति यह होती है कि बचत के आइडिया गिनाना शुरू कर दिया जाए। इससे आपको एक लंबी सूची मिलती है, बहुत से घबराए हुए लोग और कोई प्राथमिकता नहीं।
हमने लागत विश्लेषण को तीन शाखाओं में बाँटा: एप्लिकेशन मेंटेनेंस, इंफ्रास्ट्रक्चर और लाइसेंसिंग। फिर हमने उसके ऊपर कस्टम कोड का विश्लेषण जोड़ा। कितने मॉडिफ़िकेशन असल में इस्तेमाल हो रहे थे? आधे से ज़्यादा नहीं हो रहे थे। फ़ालतू इंटरफ़ेस, बिना इस्तेमाल के कस्टम रिपोर्ट, एक-दूसरे पर चढ़े वर्कफ़्लो।
इस तरह स्ट्रक्चर करने से हम ऐसी बचत की ओर इशारा कर पाए जो सुरक्षित लगती थी, जैसे बिना इस्तेमाल के कस्टम ऑब्जेक्ट को आर्काइव करना और डेवलपमेंट एनवायरनमेंट को एक में समेटना। इस स्पष्टता से आपसी खींचतान घटी और भरोसा बना। ट्री के बिना यह कटौतियों की ऐसी सूची होती जिस पर कोई दस्तख़त नहीं करना चाहता।
यही तरीक़ा और धुँधले ब्रीफ़ पर भी काम करता है। एक एंटरप्राइज़ सॉफ़्टवेयर वेंडर ने एक बार हमसे सऊदी मिड-मार्केट के लिए “क्षेत्रीय लॉन्च स्ट्रैटेजी” माँगी। हमने काम को तीन हिस्सों में बाँटा: बाज़ार की माँग, प्रतिस्पर्धी स्थिति और पार्टनर की तैयारी। पार्टनर की तैयारी के नीचे हमें पता चला कि उनके रीसेलर नेटवर्क के पास SAP S/4HANA Cloud का अनुभव बहुत कम था। बाज़ार कितना भी आकर्षक दिखता, यह रुकावट अमल को ठप कर देती, और स्ट्रक्चर ने इसे कैंपेन का बजट ख़र्च होने से पहले ही सामने ला दिया।
स्ट्रक्चर सोचने की जगह नहीं लेता। वह सोच को तेज़ और समझाने योग्य बनाता है। जो कंसल्टेंट दबाव में किसी धुँधली समस्या को साफ़ स्ट्रक्चर में बाँट सकता है, वह उस कंसल्टेंट से ज़्यादा क़ीमती है जो सवाल तय हो जाने के बाद उनके जवाब दे सकता है।
फ़्रेमवर्क नहीं बदले। दो दूसरी चीज़ें बदलीं।
पहला ड्राफ़्ट अब सस्ता हो गया है। Joule, ChatGPT और Claude सेकंडों में इश्यू ट्री या हाइपोथीसिस ट्री बना देते हैं। जो जूनियर कंसल्टेंट पहले ड्राफ़्ट पर पूरी शाम लगाते थे, वे अब उसे आधे मिनट में बना लेते हैं और शाम उस काम में लगाते हैं जो मॉडल नहीं कर सकता: यह परखना कि स्ट्रक्चर समस्या पर फ़िट बैठता है या नहीं, यह ढूँढना कि उसने क्या छोड़ दिया, और प्रॉम्प्ट में छिपी मान्यताओं को चुनौती देना।
जजमेंट की क़ीमत बढ़ गई है। जब हर कोई MECE ब्रेकडाउन बना सकता है, तब सवाल यह नहीं रह जाता कि “क्या आपने समस्या को बाँटा।” सवाल यह बन जाता है कि “क्या आपने ध्यान दिया कि क्लाइंट की बताई समस्या असल में कोई और समस्या है, और क्या आपने वह मान्यता पकड़ी जिसे मॉडल ने डिफ़ॉल्ट रूप से मान लिया था।” जिन कंसल्टेंट ने असली इंगेजमेंट पर अपना जजमेंट बनाया है, उनकी बढ़त अब 2024 से ज़्यादा चौड़ी है।
यानी हुनर की जगह बदल गई है। अब सवाल यह नहीं है कि “क्या आप इश्यू ट्री बना सकते हैं।” सवाल यह है कि “क्या आप भाँप सकते हैं कि AI का बनाया ट्री कब ग़लत है, और क्लाइंट के कमरे में उसे ठीक कर सकते हैं।”
अगर आप समझना चाहते हैं कि इससे आपके अपने करियर पर क्या असर पड़ता है, तो SAPopedia के करियर पाथ कंसल्टिंग ट्रैक का नक़्शा देते हैं, और ERPCV करियर पैक आपको CV पर सिर्फ़ फ़्रेमवर्क गिनाने के बजाय इस तरह का जजमेंट दिखाने में मदद करता है।
समाधान से शुरू करना। समस्या फ़्रेम होने से पहले ही क्लाइंट या कंसल्टेंट के मन में जवाब तैयार होता है। एनालिसिस पुष्टि करने की कवायद बन जाता है।
ज़रूरत से ज़्यादा स्ट्रक्चर। कुछ सरल समस्याएँ सीधे जवाब की हक़दार हैं, MECE ब्रेकडाउन की नहीं। यह जानना कि स्ट्रक्चर कब नहीं लगाना है, उतना ही मायने रखता है जितना यह जानना कि कैसे लगाना है।
ग़लत गहराई तक बाँटना। जो ट्री बहुत जल्दी बहुत गहरे चले जाते हैं, वे ठहराव पैदा करते हैं। जो उथले रह जाते हैं, वे ऐसी सिफ़ारिशें देते हैं जिन पर कोई अमल नहीं कर सकता। गहराई को फ़ैसले और उपलब्ध समय के हिसाब से रखिए।
सिंथेसिस के बिना एनालिसिस। एक सख़्त ट्री जो डेटा के ढेर पर ख़त्म होता है। स्ट्रक्चर सोचने में मदद करता है। सिफ़ारिश जजमेंट से निकलती है।
संवाद के स्ट्रक्चर को सोच के स्ट्रक्चर से गड़बड़ा देना। Barbara Minto के Pyramid Principle की तरह निष्कर्ष पहले रखना संवाद की एक तकनीक है। इससे यह पता नहीं चलता कि नीचे की सोच सही थी या नहीं। ख़राब एनालिसिस को अच्छे ढंग से पेश करने पर भी वह ख़राब एनालिसिस ही रहता है।
यह एक हुनर है, जन्मजात गुण नहीं। यह अभ्यास से आता है।
क्लाइंट के साथ हर अहम बातचीत के बाद लिख डालिए: समस्या जैसी आप समझे, आपका बँटवारा, आपकी हाइपोथीसिस और वह सबूत जो उसे परखेगा। यह किसी भी डेटा को देखने से पहले कीजिए। लिखने से जो स्पष्टता आती है, वह सिर्फ़ मन में सोचने से नहीं आती।
सिर्फ़ एनालिसिस नहीं, सिंथेसिस का भी अभ्यास कीजिए। सबूतों के ढेर से एक ऐसी सिफ़ारिश निकालना जिसका बचाव किया जा सके, काम का कठिन आधा हिस्सा है। ज़्यादातर जूनियर कंसल्टेंट एनालिसिस में ठीक-ठाक होते हैं और सिंथेसिस में कच्चे। अगला प्रमोशन इसी फ़ासले में बैठा है, और बज़वर्ड हटा दिए जाएँ तो कंसल्टेंट असल में क्या करते हैं इसका बड़ा हिस्सा यही है।
कंसल्टिंग में स्ट्रक्चर्ड थिंकिंग क्या है?
यह किसी जटिल, अस्पष्ट समस्या को हिस्सों में बाँटना, हर हिस्से पर क्रम से काम करना और नतीजों को मिलाकर एक साफ़ सिफ़ारिश बनाना है। इससे कठिन समस्याएँ सुलझाने लायक़ बन जाती हैं और तर्क दिखाई देने लगता है, ताकि क्लाइंट निष्कर्ष को आँख मूँदकर मानने के बजाय उसे समझ और परख सके।
मुख्य टूल हैं फ़्रेमिंग सवाल, इश्यू ट्री, MECE और हाइपोथीसिस-ड्रिवन एनालिसिस। इनमें से कोई भी जजमेंट की जगह नहीं लेता।
MECE का क्या मतलब है और इसका इस्तेमाल कैसे होता है?
Mutually Exclusive, Collectively Exhaustive। ब्रेकडाउन के हिस्से एक-दूसरे पर चढ़ने नहीं चाहिए, और सब मिलकर पूरी समस्या को कवर करें।
ओवरलैप की जाँच: क्या कोई मद दो शाखाओं में आ सकती है? ख़ाली जगह की जाँच: अगर हर शाखा का जवाब मिल जाए, तो क्या केंद्रीय सवाल का जवाब मिल जाएगा? इसे इश्यू ट्री बनाते समय लागू कीजिए। तैयार एनालिसिस पर लागू करना आमतौर पर बहुत देर हो चुकी होती है।
हाइपोथीसिस-ड्रिवन एनालिसिस कैसे काम करता है?
आप शुरुआत में ही सबसे संभावित जवाब बता देते हैं, उन सबूतों की सूची बनाते हैं जो उसे पुष्ट या ख़ारिज करेंगे, फिर जाकर उसे परखते हैं। यह पहले सब कुछ जमा करने से तेज़ है, क्योंकि यह बताता है कि कहाँ देखना है।
जोखिम कन्फ़र्मेशन बायस का है। पहले वह सबूत खोजिए जो आपको ग़लत साबित कर सकता है।
कंसल्टिंग की समस्या को सही ढंग से फ़्रेम कैसे करें?
पूछिए कि कौन-सा फ़ैसला लेना है और कौन-सी जानकारी उसे बदल देगी। फिर क्लाइंट की समस्या-कथन को मानने से पहले उसे परखिए।
जो क्लाइंट पूछता है कि “कौन-सा SAP मॉड्यूल सबसे पहले लागू करें?”, वह असल में यह तय कर रहा हो सकता है कि “क्या SAP प्रोग्राम शुरू करने का यह सही समय है भी?” बताए गए सवाल का जवाब देना, बिना फ़्रेमिंग परखे, ऐसा एनालिसिस देता है जो तकनीकी रूप से सही और व्यावसायिक रूप से ग़लत होता है।
कंसल्टिंग में एनालिसिस और सिंथेसिस में क्या फ़र्क़ है?
एनालिसिस किसी समस्या या डेटासेट को हिस्सों में बाँटकर उन्हें समझता है। सिंथेसिस नतीजों को मिलाकर एक सिफ़ारिश बनाता है।
डिलिवरेबल की सबसे आम नाकामी यह है कि एनालिसिस भरपूर होता है और सिंथेसिस नहीं: क्लाइंट को नतीजों का ढेर मिलता है, पर उस सवाल का जवाब नहीं जिसके लिए उसने आपको बुलाया था। निष्कर्ष पहले लिखने से सिंथेसिस होना मजबूर हो जाता है।
ERP इम्प्लीमेंटेशन में स्ट्रक्चर्ड थिंकिंग कैसे लागू होती है?
प्रोग्राम की शुरुआत में यह टीमों को असली समस्या समझे बिना कॉन्फ़िगर करने से रोकती है। जो संगठन कहता है “हमें SAP चाहिए”, उसे पहले कोई प्रोसेस या डेटा की समस्या ठीक करनी पड़ सकती है, जिसे SAP सिर्फ़ और ज़्यादा दिखाएगा।
फ़िट-गैप के काम में, बिज़नेस प्रोसेस का MECE ब्रेकडाउन यह पक्का करता है कि हर प्रोसेस पर विचार हो, सिर्फ़ वे नहीं जो वर्कशॉप में उठे। किसी परेशान go-live के बाद, फ़ैसले को फ़्रेम करना (स्थिर करें, रिकवर करें या बदलें) और मुख्य कारण पर एक हाइपोथीसिस परखना, लक्षणों की सूची बनाने से तेज़ी से एक बचाव-योग्य सिफ़ारिश तक पहुँचाता है।
लेखक
Noel D'Costa
कंसल्टेंट असल में क्या करते हैं: एक व्यावहारिक नज़रिया
कंसल्टेंट ऐसा क्या करता है जो आपकी टीम नहीं कर सकती? ईमानदार जवाब: जो चीज़ें टूटनी नहीं चाहिए थीं उन्हें ठीक करना, वे सवाल पूछना जो पहले ही पूछे जाने चाहिए थे, और जब अंदरूनी टीम की क्षमता चुक जाए तब क्षमता जोड़ना।
कंसल्टिंग में सफल होने के लिए इंजीनियरों को कौन-से स्किल चाहिए
इंजीनियर कंसल्टिंग में शायद ही कभी तकनीकी वजहों से फ़ेल होते हैं। कौन-से स्किल तय करते हैं कि करियर किसका बनेगा, उनका अभ्यास कैसे करें, और AI टूल्स ने नए कंसल्टेंट्स के लिए क्या बदला है।
SAP और AI डिलीवरी के लिए सात कंसल्टिंग फ़्रेमवर्क
SAP और AI प्रोग्राम ज़्यादातर ढाँचागत कारणों से अटकते हैं: स्कोप पर कभी सहमति नहीं बनी, फ़ैसले का अधिकार कभी साफ़ नहीं हुआ, प्राथमिकताएँ कभी रैंक नहीं हुईं। सात सरल फ़्रेमवर्क इन समस्याओं को शुरू में ही दिखा देते हैं।
SAP परफ़ॉर्मेंस टेस्टिंग: IT लीडर को क्या जानना ज़रूरी है
SAP में परफ़ॉर्मेंस की समस्याएँ लगभग हमेशा पहले से भाँपी जा सकती हैं और लगभग हमेशा go-live के बाद पकड़ में आती हैं। डिज़ाइन से ही टेस्ट कीजिए, और पहले रन से पहले तय किए गए मानदंडों के सामने।
अगला कदम
क्या आप अभी कोई ERP प्रोग्राम चला रहे हैं?
अगर यह लेख किसी ऐसे प्रोग्राम से जुड़ा है जिसमें आप अभी काम कर रहे हैं, तो 30 मिनट की बातचीत अक्सर एक और हफ़्ते के अंदरूनी विश्लेषण से ज़्यादा आगे ले जाती है।