ERP कॉन्ट्रैक्ट नेगोशिएशन: MENA के CFO ने बचाए $850K

ERP इम्प्लीमेंटेशन कॉन्ट्रैक्ट बजट की रक्षा तभी करता है जब उसकी बनावट सही हो: ठोस डिलीवरेबल, नामित रिसोर्स, स्वीकृत आउटपुट से जुड़े माइलस्टोन, सीमित हाइपरकेयर और नियंत्रित चेंज ऑर्डर। यह केस स्टडी दिखाती है कि MENA की एक मध्यम आकार की मैन्युफ़ैक्चरिंग कंपनी के CFO ने स्टेटमेंट ऑफ़ वर्क (SOW) को खोलकर देखने और साइन करने से पहले कॉन्ट्रैक्ट दोबारा लिखवाने से किकऑफ़ से पहले ही $850,000 कैसे बचाए, और स्कोप में कोई कटौती भी नहीं हुई। यह उन CFO, फ़ाइनेंस डायरेक्टर और प्रोक्योरमेंट लीड के लिए है जो ERP या SAP इम्प्लीमेंटेशन कॉन्ट्रैक्ट पर साइन करने वाले हैं। अंत के पास दी गई साइन करने से पहले की चेकलिस्ट को अपने प्रस्ताव पर आज़माइए।

CFO ने मुझे 120 पन्नों का प्रस्ताव थमाया। उन्होंने कहा कि यह ठोस लगता है, पर कुछ खटक रहा है। वे सही थे।

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

उन्होंने जो महसूस किया था पर पकड़ नहीं पा रहे थे, वह मैं देख पा रहा था। उन्हें बजट और लक्ष्य मालूम थे। उनकी टीम सक्षम थी, पर इस स्तर का डिलीवरी SOW उसने पहले कभी नहीं परखा था, और वेंडर पहले ही साइन करवाने की ओर बढ़ रहा था।

तीन हफ़्ते के काम के बाद कॉन्ट्रैक्ट बुनियादी तौर पर अलग था, और प्रोजेक्ट किकऑफ़ से पहले ही $850,000 हल्का हो चुका था।

$850Kकिकऑफ़ से पहले बचे

1. स्कोप रैशनलाइज़ेशनफुलाए गए घंटे घटाए गए, दोहराई गई ट्रेनिंग और टेस्टिंग हटाई गई, टेस्ट साइकल चार से घटाकर दो और कंटिंजेंसी किए गए$340K
2. रोल और रेट का पुनर्आवंटनसीनियर और जूनियर का संतुलन नियंत्रित हुआ, डॉक्यूमेंटेशन और बेसिक टेस्टिंग इंटरनल स्टाफ़ के पास आई$310K
3. कॉन्ट्रैक्ट बदलावडिलीवरेबल पर आधारित भुगतान, खर्च की सीमा, सीमित हाइपरकेयर, चेंज ऑर्डर पर CFO की मंज़ूरी$200K

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

मैंने SOW को छह श्रेणियों में बाँटा: कॉन्फ़िगरेशन, डेटा माइग्रेशन, इंटीग्रेशन, टेस्टिंग, ट्रेनिंग और PMO। इस तरह बाँटते ही खामियाँ आसानी से दिखने लगीं।

1. अस्पष्ट डिलीवरेबल। "स्टैंडर्ड इंटीग्रेशन", पर न सिस्टम के नाम, न डेटा की मात्रा, न जटिलता। कॉन्फ़िगरेशन घंटों में बताया गया था, बिज़नेस प्रोसेस से उसका कोई जुड़ाव नहीं। "वर्कशॉप में तय किया जाएगा" पूरे दस्तावेज़ में बिखरा था, और हर एक आगे का एक चेंज ऑर्डर था।
2. रिसोर्स पिरामिडिंग। प्रस्ताव में सीनियर कंसल्टेंट सीनियर डे रेट पर नामित थे। कॉन्ट्रैक्ट साइन होते ही सीनियर लोग ग़ायब होने लगते हैं और जूनियर उसी रेट पर काम करते हैं। मैंने यह लगभग हर प्रोग्राम में देखा है। नामित रिसोर्स की क्लॉज़ के बिना कोई सुरक्षा नहीं होती।
3. दोहराई गई बिलिंग। UAT में ट्रेनिंग, और फिर हाइपरकेयर में दोबारा। टेस्टिंग में डेटा जाँच, और फिर कटओवर पर दोबारा। नॉलेज ट्रांसफ़र फ़ंक्शनल और PMO स्ट्रीम में बँटकर दो बार बिल हुआ। अकेले-अकेले छोटे ओवरलैप, पर मिलकर ओवररन की गंभीर वजह।
4. फ़िक्स्ड फ़ी का भ्रम। पेश तो फ़िक्स्ड प्राइस के रूप में किया गया, पर "फ़िक्स्ड" तभी टिकता है जब हर धारणा लॉक हो। ये वाक्यांश ऊपर की संख्या को स्थिर रखते हैं और आगे बिलिंग का दरवाज़ा खोले रखते हैं।
5. कमज़ोर माइलस्टोन। भुगतान कैलेंडर की तारीख़ों से बँधे थे, जैसे "सितंबर तक डिज़ाइन पूरा", पर "पूरा" की कोई परिभाषा नहीं, कोई एक्सेप्टेंस क्राइटेरिया नहीं, और अधूरे काम के इनवॉइस रोकने का कोई तरीक़ा नहीं।
6. प्लेसहोल्डर घंटे। "ज़रूरत के हिसाब से इस्तेमाल के लिए" रखी बफ़र लाइनें, बिना किसी औचित्य के। ये रोज़मर्रा के कामों पर तेज़ी से खर्च हो जाती हैं और चेंज रिक्वेस्ट बनकर लौटती हैं।

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

बचत तीन क्षेत्रों से आई:

क्षेत्र	बचत	कैसे
स्कोप रैशनलाइज़ेशन	$340,000	फुलाए गए कॉन्फ़िगरेशन घंटे घटाए; दोहराई गई ट्रेनिंग और टेस्टिंग हटाई; टेस्टिंग चार साइकल से घटाकर दो और कंटिंजेंसी की
रोल और रेट का पुनर्आवंटन	$310,000	सीनियर और जूनियर का संतुलन नियंत्रित किया; नामित रिसोर्स की सुरक्षा के तहत इंटरनल स्टाफ़ ने डॉक्यूमेंटेशन और बेसिक टेस्टिंग संभाली
कॉन्ट्रैक्ट बदलाव	$200,000	भुगतान डिलीवरेबल से जोड़े; यात्रा और खर्च की सीमा, पूर्व-मंज़ूरी के साथ; हाइपरकेयर समय-सीमा में बाँधा और KPI पर आधारित एग्ज़िट रखा; चेंज ऑर्डर पर CFO की मंज़ूरी के साथ गवर्नेंस

क्लाइंट के अपने टूल और मानकों का इस्तेमाल करके वेंडर का डेटा माइग्रेशन प्रयास करीब एक तिहाई घट गया, और इंटरनल रूप से चलाए गए मॉडल से बाहरी ट्रेनिंग के घंटे लगभग आधे रह गए। इनमें से किसी ने भी स्कोप या फ़ंक्शनैलिटी नहीं घटाई। प्रोजेक्ट योजना की तारीख़ पर शुरू हुआ, और पहली तिमाही में कोई चेंज ऑर्डर नहीं आया। आम तौर पर तब तक मुट्ठी भर तो CFO की मेज़ पर पहुँच चुके होते।

छह क्लॉज़ ने व्यावहारिक फ़र्क डाला:

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

पूरी नेगोशिएशन के लिए SAP नेगोशिएशन सलाहकारों और SAP लाइसेंस नेगोशिएशन पर मेरे नोट्स सौदे के सॉफ़्टवेयर वाले हिस्से को कवर करते हैं।

फ़ाइनेंस टीमें अक्सर ERP डिलीवरी को IT प्रोजेक्ट मानती हैं और बजट मंज़ूर होते ही पीछे हट जाती हैं। ओवररन इसी से जमा होते हैं।

कॉन्ट्रैक्ट एक वित्तीय उपकरण है। माइलस्टोन कैश फ़्लो तय करते हैं। रिसोर्स क्लॉज़ लागत तय करती हैं। चेंज ऑर्डर प्रक्रिया एक्सपोज़र तय करती है। अगर साइन करने से पहले फ़ाइनेंस इनकी समीक्षा नहीं करता, तो व्यावसायिक अनुभव वाला कोई और नहीं करता।

तीन कमियाँ बार-बार सामने आती हैं:

1. फ़िक्स्ड फ़ी का मिथक। CFO ऐसी रकम मंज़ूर कर देते हैं जो सीमित दिखती है, पर अगर धारणाएँ अस्पष्ट छोड़ी गईं तो स्कोप फ़िक्स्ड नहीं होता। स्कोप वेंडर की वर्कशॉप में बढ़ता है, और उसका बिल बनता है।
2. देरी की लागत का कोई मॉडल नहीं। देरी सिर्फ़ कंसल्टिंग के अतिरिक्त हफ़्ते नहीं जोड़ती: वह इंटरनल समय भी जोड़ती है और फ़ायदे आगे खिसका देती है। ज़्यादातर बजट प्रोजेक्ट की लागत की योजना बनाते हैं और ओवररन के हर हफ़्ते की लागत का मॉडल कभी नहीं बनाते।
3. व्यावसायिक कौशल के बिना इंटरनल PMO। शेड्यूलिंग और रिपोर्टिंग मौजूद होती है; व्यावसायिक पलटवार नहीं। वेंडर के प्रोजेक्ट मैनेजर जानते हैं कि कॉन्ट्रैक्ट की शर्तों को अपने पक्ष में कैसे चलाया जाए, और क्लाइंट की तरफ़ उतना ही कुशल कोई न हो तो क्लाइंट ज़मीन छोड़ देता है। SAP बजट क्यों ओवररन होते हैं पर मेरी गाइड दिखाती है कि यह एक्सपोज़र आम तौर पर कहाँ लागत में बदलता है।

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

साइन करने से पहले किसी भी ERP इम्प्लीमेंटेशन प्रस्ताव पर यह चलाइए:

1. क्या SOW वर्कस्ट्रीम (कॉन्फ़िगरेशन, डेटा, इंटीग्रेशन, टेस्टिंग, ट्रेनिंग, PMO) के हिसाब से बँटा है और हर एक का प्रयास दिया गया है?
2. क्या हर इंटीग्रेशन में सिस्टम, डेटा की मात्रा और जटिलता का नाम है?
3. क्या हर "वर्कशॉप में तय किया जाएगा" वाली धारणा बंद की जा चुकी है या साफ़ तौर पर बाहर रखी गई है?
4. क्या प्रमुख कंसल्टेंट नामित हैं, बदलाव की मंज़ूरी और रेट समायोजन के साथ?
5. क्या हर भुगतान माइलस्टोन एक डिलीवरेबल से जुड़ा है, एक्सेप्टेंस क्राइटेरिया और क्लाइंट की साइन-ऑफ़ के साथ?
6. क्या इम्पैक्ट स्टेटमेंट, सीमित रेट और CFO की मंज़ूरी वाली चेंज ऑर्डर प्रक्रिया है?
7. क्या हाइपरकेयर वस्तुनिष्ठ एग्ज़िट क्राइटेरिया के साथ समय-सीमा में बँधा है?
8. क्या यात्रा और खर्च की सीमा तय है, और क्या बिल किए गए घंटों पर आपके पास ऑडिट अधिकार हैं?
9. क्या वह काम वेंडर के स्कोप से बाहर है जो आपकी अपनी टीम कर सकती है (इंटरनल टूल से डेटा माइग्रेशन, डॉक्यूमेंटेशन, बेसिक टेस्टिंग, ट्रेनिंग)?

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

उन्होंने नतीजा अपने बोर्ड के साथ साझा किया। बचत सुर्खी थी। ज़्यादा अहम नतीजा एक ऐसा कॉन्ट्रैक्ट और एक ऐसा प्रोजेक्ट था जिसे कंपनी शुरुआत से ही नियंत्रित कर सकती थी।

ERP कॉन्ट्रैक्ट में रिसोर्स पिरामिडिंग क्या है और इसे कैसे रोकें?

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

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

ERP बिलिंग माइलस्टोन कैसे बनाने चाहिए?

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

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

ERP इम्प्लीमेंटेशन कॉन्ट्रैक्ट में फ़िक्स्ड फ़ी का जाल क्या है?

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

साइन करने से पहले धारणाएँ बंद कीजिए, बहिष्करण साफ़ सूचीबद्ध कीजिए, चेंज ऑर्डर के रेट की सीमा तय कीजिए और फ़िक्स्ड फ़ी का हर दावा लाइन-दर-लाइन परखिए।

ERP कॉन्ट्रैक्ट में हाइपरकेयर की परिभाषा कैसी होनी चाहिए?

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

इससे हाइपरकेयर एक समय-सीमा वाला सुरक्षा जाल बन जाता है, जिसमें हैंडओवर की शर्तें साफ़ होती हैं।

ERP इम्प्लीमेंटेशन कॉन्ट्रैक्ट साइन करने से पहले CFO को क्या देखना चाहिए?

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

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

फ़िक्स्ड-प्राइस कॉन्ट्रैक्ट में भी ERP चेंज ऑर्डर क्यों आते रहते हैं?

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

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