
यह एक केस स्टडी है कि मध्य पूर्व की एक मझोले आकार की डिफ़ेंस मैन्युफ़ैक्चरर कंपनी ने अपने कस्टमर इन्फ़ॉर्मेशन सिस्टम को कैसे ठीक किया। कस्टमर डेटा तीन जगह रहता था, कोटेशन असंगत प्राइसिंग के साथ बाहर जाते थे और मंज़ूरियाँ ईमेल में खो जाती थीं। समाधान यह रहा: Microsoft Dynamics में एक ही कस्टमर रिकॉर्ड, Experlogix CPQ में नियम-आधारित कोटेशन, और मंज़ूर कोटेशन का SAP Cloud Integration के ज़रिए SAP Sales and Distribution (SD) में अपने-आप पहुँचना। कोटेशन टर्नअराउंड औसतन 35% घटा। यह उन सेल्स ऑपरेशंस, IT और फ़ाइनेंस लीडर्स के लिए लिखा गया है जिनकी मैन्युफ़ैक्चरिंग कंपनियों में सेल्स साइकल लंबे, कॉन्फ़िगर किए जा सकने वाले और कंप्लायंस से भरे होते हैं। रोलआउट का क्रम और अंत की सीख वे हिस्से हैं जिन्हें आप दोबारा इस्तेमाल कर सकते हैं।
जब डिफ़ेंस टीमें कस्टमर इन्फ़ॉर्मेशन सिस्टम माँगती हैं, तो उनका मतलब आम तौर पर CRM से ज़्यादा होता है। वे ढाँचा चाहती हैं: ऐसी जगह जहाँ लंबे सेल्स साइकल, कंप्लायंस से भरे वर्कफ़्लो और बदलते फ़ैसला लेने वालों के समूहों के बीच जटिल फ़ैसले संदर्भ के साथ एक जगह रहें।
एक डिफ़ेंस कंपनी में डिजिटल ट्रांसफ़ॉर्मेशन डायरेक्टर के तौर पर मुझसे ठीक यही हल करने को कहा गया। समस्या मेहनत की कमी की नहीं थी। लोग काम कर रहे थे। दिक़्क़त यह थी कि उस मेहनत का कोई ठिकाना नहीं था। न कोई साझा प्लैटफ़ॉर्म, न विज़िबिलिटी, और जो बेचा जा रहा था और जो प्लान हो रहा था, उनके बीच कोई तालमेल नहीं।
मध्य पूर्व की एक मझोले आकार की डिफ़ेंस मैन्युफ़ैक्चरर कंपनी। वह पर्दे के पीछे काम करती थी: कोई सार्वजनिक ब्रांड नहीं, और दिखना उसका मक़सद नहीं था। उसके कंपोनेंट मिलिट्री एविएशन और सुरक्षित संचार में इस्तेमाल होते थे।
हर बिक्री एक विस्तृत रास्ते से गुज़रती थी: इंजीनियरिंग रिव्यू, कंप्लायंस चेक, आंतरिक मंज़ूरियाँ, वर्ज़न-नियंत्रित कोटेशन। उसमें अफ़रातफ़री नहीं थी, पर वह भारी था।
कस्टमर इन्फ़ॉर्मेशन सिस्टम बिखर रहे थे। सेल्स एक प्लैटफ़ॉर्म इस्तेमाल करता था। सपोर्ट दूसरा। ऑपरेशंस स्प्रेडशीट, ऑफ़लाइन फ़ोल्डर और ऐसे दस्तावेज़ों से काम करता था जो किसी के खोलने से पहले ही पुराने हो चुके होते थे।
क्या टूटा हुआ था और उसकी क्या क़ीमत थी:
| क्या टूटा हुआ था | असर |
|---|---|
| अवसरों के प्रवाह या फ़ैसला लेने वालों की विज़िबिलिटी के लिए कोई CRM नहीं | हर डील कहाँ खड़ी है, इसकी कोई साझा तस्वीर नहीं |
| प्राइसिंग हाथ से संभाली जाती थी, कोई एकसमान रिकॉर्ड नहीं | कोटेशन पुराने या आपस में टकराते नंबरों के साथ बाहर जाते थे |
| मंज़ूरियाँ ईमेल से होती थीं, अक्सर खो जाती या देर से मिलती थीं | कंप्लायंस ऑडिट ट्रेल अधूरे थे |
| कस्टमर रिकॉर्ड अलग-अलग सिस्टम में दोहराए गए थे, ब्योरे थोड़े-थोड़े अलग | कोई नहीं बता सकता था कि कौन-सा वर्ज़न सही है |
काग़ज़ पर सब कुछ व्यवस्थित दिखता था। लेकिन एक कोटेशन को बनने से डिलीवरी तक फ़ॉलो करें, तो सब बिखर जाता था। साफ़ मालिक के बिना मंज़ूरियाँ अटक जाती थीं। प्राइसिंग इस पर निर्भर थी कि कोटेशन किसने जमा किया। कोटेशन ईमेल थ्रेड में दबे रहते थे। टीमें एक-दूसरे से वही सवाल बार-बार पूछती थीं। इनमें से कोई भी नाटकीय नाकामी नहीं थी, लेकिन महीनों में छोटी-छोटी देरियाँ जुड़ती गईं, और लंबे सेल्स साइकल वाले कारोबार के लिए खोई हुई गति उससे ज़्यादा मायने रखती थी जितना ज़्यादातर लोग समझते थे।
लक्ष्य सब कुछ बदल देना नहीं था। लक्ष्य था रुकावट घटाना, बिना किसी चीज़ को इस्तेमाल में और मुश्किल बनाए: सिस्टम को ऐसा बनाना कि वे टीमों के पहले से चल रहे काम को दर्शाएँ, लोगों को सख़्त प्रोसेस में धकेलना नहीं।
कोई भी कॉन्फ़िगरेशन छूने से पहले मैंने टीमों के साथ समय बिताया। मैंने देखा कि काम कैप्चर से डिलीवरी तक कैसे चलता है, टूल कहाँ आड़े आते हैं, और लोगों ने डेटा पर भरोसा कहाँ करना छोड़ दिया था।
उन सत्रों से तीन प्राथमिकताएँ निकलीं:
- एक साझा कस्टमर रिकॉर्ड, जो सेल्स, सपोर्ट और ऑपरेशंस को एक ही फ़ॉर्मैट में दिखे। समानांतर वर्ज़न अब नहीं।
- संरचित कोटेशन, जो कॉन्फ़िगरेशन और प्राइसिंग के एकसमान नियमों पर चले, व्यक्तिगत आदतों और पुराने टेम्पलेट पर नहीं।
- जुड़ा हुआ ऑर्डर एक्ज़ीक्यूशन, जिसमें मंज़ूर कोटेशन से SAP SD तक साफ़ हैंडऑफ़ हो और हाथ से दोबारा एंट्री न हो।
| सिस्टम | उसने क्या हल किया |
|---|---|
| Microsoft Dynamics CRM | एक कस्टमर रिकॉर्ड, जो सेल्स गतिविधि और अवसरों से जुड़ा है |
| Experlogix Configure Price Quote (CPQ) | प्रोडक्ट कॉन्फ़िगरेशन के नियम, प्राइसिंग लॉजिक, कोटेशन वर्ज़न |
| SAP Sales and Distribution (SD) | ऑर्डर एक्ज़ीक्यूशन और फ़ुलफ़िलमेंट |
| SAP Cloud Integration (CPI) | CPQ और CRM को SAP SD से जोड़ने वाली इंटीग्रेशन लेयर |
नींव के रूप में Microsoft Dynamics। हमें ऐसी एक जगह चाहिए थी जहाँ कस्टमर की जानकारी सही हो और पूरे संदर्भ में दिखे। Dynamics ने हमें डेटा की उलझन सुलझाने की शुरुआत करने की जगह दी। प्लैटफ़ॉर्म से जान-पहचान ने मदद की, और Outlook और Teams के साथ उसके मेल ने भी। इसमें लोगों को शुरू से सीखना नहीं पड़ा; बस उसे कारोबार के काम करने के तरीक़े के हिसाब से ढालना पड़ा। जब टीमों ने सभी फ़ंक्शन में एक ही डेटा एक ही फ़ॉर्मैट में देखा, तो भरोसा बनने लगा।
कॉन्फ़िगरेशन और प्राइसिंग के लिए Experlogix CPQ। पहले कोटेशन बहुत अलग-अलग तरीक़ों से बनते थे। लोग याददाश्त और हाथ से किए गए बदलावों पर निर्भर थे। हमने Experlogix में प्रोडक्ट कॉम्बिनेशन के तय नियम, कॉन्फ़िगरेशन से जुड़ी प्राइसिंग, और डील के प्रकार व वैल्यू के हिसाब से मंज़ूरी का रूट सेट किया। शुरू में यह बंदिश जैसा लगा, और कुछ लोगों ने यह कहने में संकोच नहीं किया, लेकिन इसने अस्पष्टता हटा दी। इंजीनियरिंग को साफ़-सुथरे कोटेशन मिलने लगे, और सेल्स ने पिछली डील्स की याद के भरोसे क़ीमतें बदलना बंद कर दिया।
SAP CPI के ज़रिए SAP SD। ऑर्डर के लिए SAP SD पहले से इस्तेमाल में था। कमी हैंडऑफ़ में थी: मंज़ूर कोटेशन को अब भी हाथ से SAP में दोबारा भरना पड़ता था। हमने दोनों को SAP CPI से जोड़ा, ताकि मंज़ूर कोटेशन सीधे SAP में ऑर्डर बनकर पहुँचें और Dynamics व SAP के बीच कस्टमर और ऑर्डर डेटा सिंक में रहे। जहाँ सीमाएँ आईं, वहाँ हमने कस्टम लॉजिक जोड़ा। हर मामले में वह सुघड़ नहीं था, पर काम करता था।
- कस्टमर रिकॉर्डMicrosoft Dynamics, हर टीम के लिए एक ही वर्ज़न
- कॉन्फ़िगर और प्राइसकॉम्बिनेशन और प्राइसिंग के लिए Experlogix CPQ के नियम
- मंज़ूरीडील के प्रकार और वैल्यू के हिसाब से रूट
- ऑर्डर बनानाSAP CPI मंज़ूर कोटेशन को SAP SD में पहुँचाता है
- फ़ुलफ़िलमेंटSAP SD, कस्टमर डेटा सिंक में रखते हुए
दोबारा एंट्री नहीं, और मंज़ूरी से ऑर्डर तक ऑडिट ट्रेल
रोलआउट क़रीब छह से आठ महीनों में चरणों में हुआ। कुछ नाटकीय नहीं: परत-दर-परत बदलाव, हर क़दम पर जाँचे हुए।
- पायलट। यूज़र का एक छोटा समूह और CRM व CPQ पर केंद्रित ख़ास परिदृश्य। हमने एज केस टेस्ट किए, कमियाँ सामने लाईं और बड़े पैमाने पर जाने से पहले बदलाव किए।
- डेटा साफ़ करना। Dynamics में जाने से पहले कस्टमर रिकॉर्ड को एक जगह लाया गया और डुप्लिकेट हटाए गए, और कंप्लायंस दस्तावेज़ सही अवसरों से जोड़े गए। इसमें कॉन्फ़िगरेशन से ज़्यादा समय लगा।
- विभागों में विस्तार। पायलट के वर्कफ़्लो निखर जाने के बाद यह समाधान सेल्स, सपोर्ट और ऑपरेशंस तक गया।
- बीच में SAP SD का इंटीग्रेशन। CPQ से SAP का इंटीग्रेशन तब लाइव हुआ जब ऊपर के सिस्टम स्थिर हो चुके थे, ताकि शुरुआती समस्याएँ ऑर्डर तक न फैलें।
सुरक्षा और कंप्लायंस पहले दिन से डिज़ाइन में रखे गए। डिफ़ेंस क्लाइंट के लिए ऑडिट ट्रेल की अखंडता और रोल-आधारित एक्सेस वैकल्पिक नहीं होते। हमने एक्सेस रोल साफ़ तय किए और मंज़ूरी के ट्रेल ट्रैक किए। डेटा रेज़िडेंसी शुरू में ही तय हो गई: डिफ़ेंस सेक्टर के नियमों के अनुरूप सारा डेटा UAE के भीतर रहा। इससे शुरुआत में हमारी रफ़्तार थोड़ी धीमी हुई, और बाद में इसी ने ज़्यादा गंभीर समस्याओं को रोका।
ट्रेनिंग व्यावहारिक थी: छोटे सत्र, लक्षित सामग्री, लाइव डेमो और हाउ-टू वीडियो, जो एक सत्र में निपटाने के बजाय हफ़्तों और महीनों तक चलते रहे। शुरुआत में एडॉप्शन पूरा नहीं था। लगातार सपोर्ट और दिखते फ़ायदों ने शुरुआती हिचकिचाहट को दूर किया। मोड़ तब आया जब टीमों ने टूल को असली हालात में इस्तेमाल किया और पाया कि उन्हें जो डेटा वापस मिला वह सही था।
| नतीजा | क्या बदला |
|---|---|
| कोटेशन टर्नअराउंड समय | औसतन 35% कम; कई डील में घंटे बचे और जटिल डील में कई दिन |
| कॉन्फ़िगरेशन की सटीकता | वैलिडेशन नियमों ने ग़लतियों को इंजीनियरिंग तक पहुँचने से पहले रोका |
| ऑडिट की तैयारी | कंप्लायंस चेक के लिए अब आख़िरी वक़्त की हड़बड़ी नहीं करनी पड़ती थी |
| टीमों के बीच तालमेल | सेल्स, सपोर्ट और ऑपरेशंस एक ही कस्टमर रिकॉर्ड से काम करते थे |
35% की यह कमी पहले हफ़्ते में नहीं आई। शुरुआती साइकल में स्पष्टीकरण और सुधार चलते रहे। जब प्रोडक्ट नियम और प्राइसिंग लॉजिक एकसमान हो गए, तो कोटेशन बनाना तेज़ हुआ। सेल्स प्रतिनिधि अब मंज़ूरियों के पीछे नहीं भागते थे और न दोबारा इस्तेमाल हुए टेम्पलेट ठीक करते थे। वे क़दम सिस्टम संभालता था।
कस्टमर इन्फ़ॉर्मेशन सिस्टम तभी क़ीमत पैदा करते हैं जब वे हिचकिचाहट घटाते हैं। जब टीमों ने एक-दूसरे के डेटा पर शक करना बंद कर दिया, तो रफ़्तार और आत्मविश्वास साथ आ गए।
तालमेल टेक्नोलॉजी से ज़्यादा मायने रखता है। तकनीकी बिल्ड आसान हिस्सा था। टीमों को एक ही सच्चे स्रोत पर भरोसा करने और अपने-अपने रिकॉर्ड रखना बंद करने के लिए तैयार करना मुश्किल था। इसका मतलब था लोगों पर निर्भर होने को कहने से पहले उन्हें दिखाना कि डेटा भरोसेमंद है।
इंटीग्रेशन के ब्योरे फ़ीचर से ज़्यादा मायने रखते हैं। CPQ से SAP SD का इंटीग्रेशन ही था जिसने पूरे सिस्टम को क़ीमती बनाया। अलग से CRM और अलग से कोटेशन, हाथ से ऑर्डर एंट्री के साथ, दोनों थोड़ा-थोड़ा काम आते। रुकावट उन दोनों के बीच के जोड़ पर ही ख़त्म हुई।
सपोर्ट और ट्रेनिंग इसे टिकाऊ बनाते हैं। तैनात करके छोड़ देना डिलीवरी नहीं है। ट्रेनिंग go-live के बाद भी हफ़्तों और महीनों तक चली, और यही दौर तय करता है कि एडॉप्शन जम जाता है या बिखर जाता है।
आर्किटेक्चर आज भी टिकता है: कस्टमर रिकॉर्ड के लिए CRM, संरचित कोटेशन के लिए CPQ, ऑर्डर एक्ज़ीक्यूशन के लिए ERP इंटीग्रेशन। यही काम आज शुरू होता तो तीन चीज़ें बदल जातीं।
इंटीग्रेशन प्लैटफ़ॉर्म। SAP CPI अब SAP Integration Suite के भीतर की Cloud Integration क्षमता है, जिसके साथ API मैनेजमेंट, इवेंट-आधारित इंटीग्रेशन और पहले से बना इंटीग्रेशन कंटेंट भी है। Dynamics से CPQ से SAP SD तक का फ़्लो आज डिज़ाइन में कम समय लेता। इस प्लैटफ़ॉर्म की जानकारी मेरी SAP Cloud Integration गाइड में है।
SAP का अपना CRM शॉर्टलिस्ट में होता। SAP SD बैक एंड वाली किसी नई एंगेजमेंट में SAP Sales Cloud की, जिसमें अब Joule शामिल है, Microsoft Dynamics से तुलना होनी चाहिए। यहाँ Dynamics सही चुनाव था क्योंकि टीम उससे पहले से परिचित थी। जवाब अब भी क्षमता और इंटीग्रेशन की पसंद पर निर्भर करता है, लेकिन SAP का अपना विकल्प अब पहले से ज़्यादा भरोसेमंद दावेदार है। विकल्पों की जानकारी SAP के लिए CRM सिस्टम की मेरी तुलना में है।
अमेरिकी फ़ेडरल दायरे के लिए अलग होस्टिंग मॉडल चाहिए। इस क्लाइंट को इसकी ज़रूरत नहीं थी, लेकिन अमेरिकी फ़ेडरल ऑपरेशंस वाली डिफ़ेंस कंपनी SAP National Security Services (SAP NS2) को देखेगी। 2025 में उसे S/4HANA Cloud Private Edition और SAP BTP को FedRAMP+ Impact Level 5 पर चलाने की अनंतिम मंज़ूरी मिली, जिसमें ऑपरेशन सिर्फ़ अमेरिका में होते हैं।
डिफ़ेंस की अपनी ज़रूरतें (ऑडिट ट्रेल, रोल-आधारित एक्सेस, कोटेशन पर वर्ज़न कंट्रोल, डेटा रेज़िडेंसी) प्लैटफ़ॉर्म की पीढ़ी चाहे जो हो, लागू रहती हैं। कंप्लायंस की व्यापक तस्वीर के लिए सार्वजनिक क्षेत्र में SAP कंप्लायंस पर मेरी गाइड देखिए।
दूसरे CRM प्लैटफ़ॉर्म की जगह Microsoft Dynamics क्यों चुना गया?
वह लीड से अवसर और बिक्री के बाद की एंगेजमेंट तक पूरे कस्टमर लाइफ़साइकल को संभाल सकता था, और डिफ़ेंस बिक्री के लंबे, जटिल डील साइकल को भी। Outlook और Teams के साथ उसके मेल ने एडॉप्शन में मदद की, और टीम की जान-पहचान ने रुकावट और घटा दी।
एक्सेस कंट्रोल, ऑडिट लॉगिंग, लचीलापन और आगे बढ़ने की गुंजाइश, कंप्लायंस से भरे क्लाइंट के लिए ये दूसरे निर्णायक कारण थे।
Experlogix CPQ की क्या भूमिका रही, और CPQ की ज़रूरत ही क्यों पड़ी?
डिफ़ेंस प्रोडक्ट के कॉन्फ़िगरेशन नियम जटिल होते हैं। प्राइस लिस्ट प्रोडक्ट वेरिएंट, कंप्लायंस ज़रूरतों और ग्राहक-विशेष शर्तों के आपसी असर को पकड़ नहीं सकती। CPQ के बिना हर कोटेशन इस पर निर्भर था कि उसे बनाने वाला नियम जानता है या नहीं।
Experlogix ने ये नियम कोटेशन टूल में डाल दिए। सेल्स प्रतिनिधि को कोटेशन बनाते समय ही वैलिडेशन फ़ीडबैक मिलता था, दिनों बाद इंजीनियरिंग से सुधार नहीं। ग़लतियाँ ऊपर की ओर खिसक गईं, जहाँ उन्हें ठीक करना सस्ता है।
SAP SD को CRM और CPQ से कैसे जोड़ा गया?
SAP CPI ने मिडलवेयर का काम किया। Experlogix में मंज़ूर कोटेशन एक फ़्लो शुरू करता था, जो SAP SD में सही लाइन आइटम, प्राइसिंग और कस्टमर डेटा के साथ ऑर्डर बना देता था। CPI ने Dynamics और SAP के बीच कस्टमर और ऑर्डर डेटा भी सिंक में रखा, और बेमेल डेटा रोकने के लिए वैलिडेशन नियम भी लगाए।
पहले कोई हर मंज़ूर कोटेशन को हाथ से SAP में कॉपी करता था। इसे ऑटोमेट करने से दोबारा एंट्री की ग़लतियाँ ख़त्म हुईं और मंज़ूरी से ऑर्डर तक साफ़ ऑडिट ट्रेल बना।
इम्प्लीमेंटेशन के दौरान सबसे बड़ी चुनौतियाँ क्या थीं?
सबसे पहले डेटा क्वालिटी। कस्टमर डेटा विभागों में असंगत था, डुप्लिकेट और ख़ाली फ़ील्ड के साथ, और Dynamics को सच्चा स्रोत बनाने से पहले उसे साफ़ करना पड़ा।
दूसरे नंबर पर इंटीग्रेशन मैपिंग थी, ख़ासकर तीन सिस्टम में प्रोडक्ट कॉन्फ़िगरेशन और प्राइसिंग की। तीसरी चुनौती सेल्स, इंजीनियरिंग, IT और फ़ाइनेंस को एक साथ लाना थी, ख़ासकर तब जब प्रोसेस के कुछ हिस्सों की मिल्कियत बदली।
सुरक्षा और कंप्लायंस कैसे संभाले गए?
इन्हें पहले दिन से डिज़ाइन में रखा गया। हर कंपोनेंट को आंतरिक सुरक्षा नीतियों और राष्ट्रीय नियमों पर खरा उतरना था। रोल-आधारित एक्सेस तय करता था कि कौन किन रिकॉर्ड को देख और बदल सकता है। पूरे ऑडिट ट्रेल कोटेशन, मंज़ूरियों और डेटा बदलावों को कवर करते थे। डिफ़ेंस सेक्टर के नियमों के अनुरूप सारा डेटा UAE में रहा।
क्योंकि डिज़ाइन उन्हीं ज़रूरतों से शुरू हुआ, इसलिए कंप्लायंस रिव्यू आने तक डेटा पहले से सही शक्ल में था।
रोलआउट में कितना समय लगा?
क़रीब छह से आठ महीने, चरणों में। शुरुआत CRM और CPQ पर केंद्रित पायलट से हुई, फ़ीडबैक के बाद विभागों में विस्तार हुआ, और ऊपर के सिस्टम स्थिर होने पर बीच में SAP SD इंटीग्रेशन जोड़ा गया। ट्रेनिंग, सपोर्ट और ट्यूनिंग पूरे समय चलते रहे।
क्या यह मॉडल दूसरी डिफ़ेंस या मैन्युफ़ैक्चरिंग कंपनियों पर लागू हो सकता है?
हाँ, जहाँ भी सेल्स साइकल लंबे हों, प्रोडक्ट कॉन्फ़िगर किए जा सकते हों और कंप्लायंस दस्तावेज़ ज़रूरी हों: एयरोस्पेस, इंडस्ट्रियल इक्विपमेंट और कोई भी कारोबार जहाँ कोटेशन बाहर जाने से पहले इंजीनियरिंग की वैलिडेशन माँगता हो।
ख़ास टूल इंटीग्रेशन के लॉजिक से कम मायने रखते हैं। मंज़ूर कोटेशन को बिना दोबारा एंट्री के ERP में बहना चाहिए, और कस्टमर रिकॉर्ड एक ही सच्चा स्रोत होना चाहिए।
अगला कदम
क्या आप अभी कोई ERP प्रोग्राम चला रहे हैं?
अगर यह लेख किसी ऐसे प्रोग्राम से जुड़ा है जिसमें आप अभी काम कर रहे हैं, तो 30 मिनट की बातचीत अक्सर एक और हफ़्ते के अंदरूनी विश्लेषण से ज़्यादा आगे ले जाती है।




