FMCG ERP रिकवरी: SAP Analytics Cloud से एकीकृत रिपोर्टिंग

यह केस स्टडी उन CFO और IT लीडर्स के लिए है जो एक से ज़्यादा ERP चलाते हैं और नंबरों का एक सेट नहीं पा रहे। छोटा सार यह है: सिंगापुर के Oracle और UK के SAP के बीच अटका हुआ क्रॉस-बॉर्डर रिपोर्टिंग प्रोजेक्ट छह महीने में पटरी पर लौट आया। पाँच चीज़ों ने यह किया। असली अधिकार वाला एक छोटा स्टीयरिंग ग्रुप। स्कोप को उन रिपोर्टों तक काटना जो फ़ैसले चलाती हैं। दोनों सिस्टम में तय की गई परिभाषाएँ। एक ही रिपोर्टिंग लेयर के तौर पर SAP Analytics Cloud। और क्लासरूम ट्रेनिंग की जगह लोकल चैंपियन। अगर आप भी इसी हालत में हैं, तो टूल की बहस से नहीं, गवर्नेंस और परिभाषाओं से शुरू कीजिए।

कहानी सिंगापुर में मुख्यालय वाले एक जाने-माने FMCG ग्रुप के अटके हुए ERP एनालिटिक्स प्रोजेक्ट से शुरू होती है। ग्रुप के पास UK के एक एनर्जी ड्रिंक्स कारोबार में 26% हिस्सेदारी थी। अल्पांश हिस्सेदारी के बावजूद मैनेजमेंट का नियंत्रण सिंगापुर में था, इसलिए एशिया की बोर्डरूम रणनीति यूरोप की रोज़ की रिपोर्टिंग और प्लानिंग को तय करती थी।

टेक्नोलॉजी ने इसे और मुश्किल बना दिया। सिंगापुर में Oracle ERP चलता था। UK में SAP ERP। दोनों अलग-अलग काम करते थे, और साथ मिलकर उन्होंने ऐसी रिपोर्टिंग समस्या खड़ी कर दी जो पहले ही महीनों की मेहनत खा चुकी थी।

नंबर शायद ही कभी मेल खाते थे। रिकंसिलिएशन दिनों तक खिंचते थे। बुनियादी रेवेन्यू का आँकड़ा भी इस पर निर्भर करता था कि आपने कौन-सा सिस्टम देखा।

रिकवरी एंगेजमेंट के छह महीनों के भीतर, जो पहल नाकाम दिखती थी वह एक क्रॉस-बॉर्डर रिपोर्टिंग मॉडल बन गई जिस पर फ़ाइनेंस और ऑपरेशंस, दोनों भरोसा करते थे।

रिकवरी से पहलेरीलॉन्च पर

गवर्नेंसरिकवरी से पहलेबड़ा स्टीयरिंग ग्रुप, फ़ैसले टलते रहतेरीलॉन्च परसिर्फ़ असली फ़ैसला लेने वाले, फ़ैसला मीटिंग में ही

स्कोपरिकवरी से पहलेमाँगों से भरा व्हाइटबोर्डरीलॉन्च परवे रिपोर्ट जो फ़ैसले चलाती हैं

परिभाषाएँरिकवरी से पहलेएक ही लेबल, हर ERP में अलग मतलबरीलॉन्च पररेवेन्यू, कॉस्ट और मार्जिन पर सहमति

रिपोर्टिंगरिकवरी से पहलेExcel रिकंसिलिएशन जिसमें दिन लगते थेरीलॉन्च परSAP Analytics Cloud के एक मॉडल में Oracle और SAP का डेटा

एडॉप्शनरिकवरी से पहलेक्लासरूम ट्रेनिंग, फिर वापस Excelरीलॉन्च परलोकल चैंपियन, एक-एक टीम करके

तालिका शुरुआती स्थिति और हर समस्या के समाधान का सार देती है।

चुनौती	असर	SAP Analytics Cloud से समाधान
दो ERP: सिंगापुर में Oracle, UK में SAP	नंबर मेल नहीं खाते थे; रिकंसिलिएशन में दिन लगते थे	दोनों एक ही रिपोर्टिंग मॉडल में जुड़ गए
सीमा पार रिपोर्टिंग की मिल्कियत साफ़ नहीं	एशिया की रणनीति यूरोप के ऑपरेशनल डेटा से टकराती थी	मानक KPI का मतलब था कि दोनों एंटिटी एक ही मेट्रिक रिपोर्ट करती थीं
धीमी रेवेन्यू रिपोर्टिंग	स्रोत सिस्टम के हिसाब से आँकड़े अलग होते थे, जिससे फ़ैसले देर से होते थे	एकीकृत प्लानिंग और रिपोर्टिंग ने साइकल छोटा किया
प्लानिंग में बेमेल	सिंगापुर रणनीति तय करता था; UK अलग मान्यताओं पर अमल करता था	साझा प्लानिंग मॉडल ने दोनों कारोबारों को एक लाइन में ला दिया

दो ERP में रिपोर्टिंग

सिंगापुर में Oracle और UK में SAP के साथ रिपोर्टिंग ऐसी लगती थी जैसे दो अलग कारोबार चल रहे हों। फ़ाइनेंस हर सिस्टम से वही मेट्रिक निकालता और अलग जवाब पाता। एक मंथली रिव्यू में सिंगापुर ने रेवेन्यू का एक आँकड़ा रखा और UK ने उसे तुरंत दूसरे आँकड़े से चुनौती दे दी। बहस रिव्यू से ज़्यादा लंबी चली।

लोग Excel पर लौट आए क्योंकि वह ज़्यादा सुरक्षित लगता था: घंटों एक्सपोर्ट करना, रिकंसाइल करना और सच का अपना वर्ज़न बनाना। यह थोड़े समय के लिए चला और ग्रुप रिपोर्टिंग में पुरानी देरी पैदा कर गया। इस पैटर्न को मेरा लेख CFO अब भी Excel की तरफ़ क्यों भागते हैं ज़्यादा व्यापक रूप से समझाता है।

मंथ-एंड कंसॉलिडेशन

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

ऑपरेशनल रिपोर्टिंग

समस्याएँ फ़ाइनेंस से आगे जाती थीं। Oracle शिपमेंट ट्रैक करता था, SAP स्टॉक, और कोई एक स्रोत नहीं था। एक वेयरहाउस मैनेजर ने मुझे बताया कि एक ही हफ़्ते में उसे स्टॉक की तीन अलग रिपोर्टें मिलीं, तीनों में बैलेंस अलग-अलग। यह कहते हुए वह हँस रहा था, पर इससे असली फ़ैसले धीमे पड़ रहे थे। रीप्लेनिशमेंट पिछड़ता था, और शिपिंग की देरियाँ समझाना और मुश्किल था क्योंकि ऑपरेशंस को डैशबोर्ड पर भरोसा नहीं था।

टूल की बहस

रिपोर्टिंग टूल चुनना अपने आप में एक प्रोजेक्ट बन गया। कुछ मैनेजरों को Power BI की लागत पसंद थी; कुछ SAP के लंबे रोडमैप की वजह से उसके पक्ष में थे। मैं एक वर्कशॉप में बैठा जहाँ आधा समय रिपोर्टिंग की ज़रूरतों के बजाय “SAC क्यों, Power BI क्यों नहीं” पर चला गया। यह बहस महीनों चली और गति खा गई।

यूज़र का प्रतिरोध

पहले डैशबोर्ड लाइव होने के बाद भी एडॉप्शन कम रहा। मुझे याद है, फ़ाइनेंस की एक मीटिंग में मैंने किसी को डैशबोर्ड खोलते, उस पर नज़र डालते, बंद करते और अपनी Excel शीट पर लौटते देखा। किसी ने सवाल नहीं उठाया। लोग उसी पर भरोसा करते थे जो वे जानते थे, और डैशबोर्ड ने अभी वह भरोसा कमाया नहीं था।

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

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

ऐसा संवाद जो प्रासंगिक लगे। पहले के अपडेट सामान्य थे, इसलिए फ़ाइनेंस, ऑपरेशंस और IT, हर एक ने अलग मतलब निकाला। हमने अपडेट को हर टीम के हिसाब से ढाल दिया: फ़ाइनेंस के लिए रिपोर्टिंग टाइमलाइन, ऑपरेशंस के लिए लॉजिस्टिक्स प्रोसेस के बदलाव, IT के लिए तकनीकी रोडमैप। लोग बेहतर सवाल पूछने लगे क्योंकि अपडेट उनकी भाषा में बोलते थे।

लोकल चैंपियन। अकेली ट्रेनिंग काम नहीं आई थी: लोग सत्र में बैठते और अगली सुबह फिर Excel पर लौट जाते। बदलाव लोकल चैंपियन से आया, यानी वे सहकर्मी जिनकी अपनी टीमों में पहले से साख थी, जो डैशबोर्ड अनौपचारिक ढंग से अपने शब्दों में समझाते थे। मैं ऐसे ही एक सत्र में बैठा और फ़र्क़ चौंकाने वाला था। लोगों ने वे सवाल पूछे जो वे क्लास में कभी नहीं पूछते। एडॉप्शन एक-एक टीम करके बेहतर हुआ।

तालिका बताती है कि क्या बदला और वह क्यों काम आया।

फ़ोकस क्षेत्र	क्या बदला	असर
गवर्नेंस रीसेट	स्टीयरिंग ग्रुप को असली फ़ैसला लेने वालों तक छोटा किया; छोटे, धारदार सत्र	फ़ैसले मीटिंग में ही हुए; एस्केलेशन तेज़ी से आगे बढ़े
स्कोप पर नियंत्रण	रिक्वायरमेंट को उस रिपोर्टिंग तक छाँटा जो फ़ैसले चलाती है	कम बहस, साफ़ डेटा मॉडल, कम बदलते लक्ष्य
हर टीम के हिसाब से संवाद	फ़ाइनेंस, ऑपरेशंस और IT के लिए अलग अपडेट	हर टीम ने समझा कि उसके लिए क्या मायने रखता है; भरोसा लौटा
लोकल चैंपियन	औपचारिक क्लास के बजाय छोटे समूहों में पीयर कोचिंग	एडॉप्शन टीम-दर-टीम बेहतर हुआ; Excel पर निर्भरता घटी

जब टूल का चुनाव आख़िरकार निपटा, तो SAC जीता, कुछ हद तक इसलिए कि वह भारी कस्टम काम के बिना Oracle और SAP का डेटा एक मॉडल में ला सकता था। इससे चर्चा की गरमी कुछ कम हुई। रिपोर्टों में बदलाव पुराने एक्सपोर्ट साइकल से कहीं तेज़ी से दिखने लगे। एक फ़ाइनेंशियल कंट्रोलर ने कहा कि यह पहली बार था जब उन्हें दिन शुरू करने के लिए रातों-रात के डेटा रिफ़्रेश का इंतज़ार नहीं करना पड़ा।

फ़ाइनेंस मैनेजर ने जब पहली बार Oracle और SAP का डेटा एक डैशबोर्ड में साथ-साथ देखा, तो जैसे सिर से बोझ उतर गया। उसी पल ने बहस ख़त्म कर दी।

SAC ने सिर्फ़ फ़ाइनेंस को ही कवर नहीं किया। ऑपरेशंस लॉजिस्टिक्स और वेयरहाउसिंग का व्यू चाहता था, और HR वर्कफ़ोर्स प्लानिंग। प्लानिंग, रिपोर्टिंग और विज़ुअलाइज़ेशन एक ही प्लैटफ़ॉर्म पर होने से फ़र्क़ पड़ा: तात्कालिक जुगाड़ की जगह लंबे समय की नींव बनी। पहले से बने टेम्पलेट से टीम को शुरुआती बढ़त मिली, भले ही कुछ आम किस्म के लगे हों, और उस पहली डिलीवरी की रफ़्तार ने महीनों की देरी के बाद भरोसा लौटाया।

अगर आप इस डिज़ाइन की नक़ल करने की सोच रहे हैं, तो एक तकनीकी बात। SAC लाइव डेटा कनेक्शन SAP स्रोतों तक सीमित हैं, जैसे SAP HANA, BW, S/4HANA, BPC embedded, BusinessObjects यूनिवर्स और SAP Datasphere। Oracle ERP जैसा गैर-SAP डेटा आम तौर पर इंपोर्ट कनेक्शन, यूनिवर्स या बीच की डेटा लेयर के ज़रिए आता है। यह आर्किटेक्चर जल्दी तय कर लें, क्योंकि इसी से तय होता है कि हर तरफ़ के नंबर कितने ताज़ा हो सकते हैं।

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

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

रीलॉन्च छह महीने के भीतर पूरा हो गया। पहली बार Oracle और SAP का डेटा SAC के अंदर एक ही मॉडल में था। रिकंसिलिएशन की बहसें घटीं, और एग्ज़ीक्यूटिव Excel फ़ाइलों के घूमने का इंतज़ार किए बिना नंबर देखने लगे।

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

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

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

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

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

यही काम आज शुरू होता तो तीन चीज़ें बदल जातीं।

SAC और स्रोतों के बीच एक डेटा लेयर होती। SAP Datasphere, जो अब SAP Business Data Cloud का हिस्सा है, SAP और गैर-SAP स्रोतों तक फ़ेडरेटेड एक्सेस देता है, ऊपर एक सिमैंटिक मॉडल के साथ। इस जैसे दो-ERP मामले में Oracle और SAP डेटा को उसी लेयर में हार्मोनाइज़ करना, हर SAC स्टोरी के अंदर करने से ज़्यादा साफ़-सुथरा है। इससे SAC को हार्मोनाइज़ किए गए मॉडल से लाइव कनेक्शन भी मिलता है।

सामान्य भाषा के सवाल कुछ डैशबोर्ड बिल्ड की जगह ले लेते। SAC का नैचुरल-लैंग्वेज क्वेरी और Joule फ़ाइनेंस को, मसलन, तिमाही का क्षेत्र-वार रेवेन्यू, सिंगापुर बनाम UK, पूछने देते हैं। पहले कोई स्टोरी बनानी नहीं पड़ती। डेटा हार्मोनाइज़ होने के बाद इससे काम तेज़ होता है। यह परिभाषाओं की खाई नहीं भरता।

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

गवर्नेंस रीसेट, स्कोप का अनुशासन, लोकल चैंपियन और हर टीम के हिसाब से संवाद, ये नहीं बदलते। ये पैटर्न टेक्नोलॉजी चाहे जो हो, टिके रहते हैं। दो ERP से एक जैसे नंबर रिपोर्ट करवाने का इंसानी काम ऑटोमेट नहीं होता। SAC के बारे में और जानने के लिए मेरी SAP Analytics Cloud गाइड देखिए।

इस FMCG ग्रुप का ERP रिपोर्टिंग प्रोजेक्ट क्यों अटका?

सिंगापुर Oracle चलाता था और UK SAP, और हर महीने फ़ाइनेंस नंबरों को हाथ से जोड़ता था। इसमें दिन लगते थे और नतीजे पर कोई पूरी तरह भरोसा नहीं करता था। जब सिंगापुर एक आँकड़ा रखता और UK उसे दूसरे से चुनौती देता, तो रिव्यू अटक जाते थे। स्टीयरिंग ग्रुप भी बहुत बड़ा था, इसलिए कोई फ़ैसला नहीं लेता था। लागत बढ़ी, भरोसा फिसला और प्रोजेक्ट भटक गया।

रिकवरी की दिशा किस बात से बदली?

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

SAP Analytics Cloud ने Oracle और SAP, दोनों को कैसे संभाला?

SAC ने Oracle और SAP का डेटा एक रिपोर्टिंग मॉडल में ला दिया, इसलिए दोनों हाथ से बनी रिकंसिलिएशन फ़ाइलों के बिना एक ही डैशबोर्ड में साथ-साथ दिखे। दोनों सिस्टम का एक ही व्यू में दिखना वही पल था जिसने टूल की बहस ख़त्म की। ध्यान रहे कि SAC के लाइव कनेक्शन सिर्फ़ SAP स्रोतों को सपोर्ट करते हैं; Oracle डेटा आम तौर पर इंपोर्ट कनेक्शन, BusinessObjects यूनिवर्स या SAP Datasphere जैसी डेटा लेयर के ज़रिए आता है।

शुरू में यूज़र ने डैशबोर्ड का विरोध क्यों किया?

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

ERP रिपोर्टिंग की कामयाब रिकवरी कैसी दिखती है?

यह शायद ही कभी एक चीज़ होती है। यहाँ यह गवर्नेंस रीसेट, स्कोप में कटौती, तय की गई परिभाषाएँ, हर टीम के हिसाब से संवाद और पीयर चैंपियन का एक साथ काम करना था। SAC इसलिए काम आया कि उसने भारी कस्टम काम के बिना दोनों ERP को एक मॉडल में ला दिया, लेकिन अकेली टेक्नोलॉजी प्रोजेक्ट को नहीं बचाती। छह महीने बाद, जो लोग इसके ढहने का इंतज़ार कर रहे थे, वे ख़ुद बनाए डैशबोर्ड पेश कर रहे थे।