SAP बिज़नेस केस टेम्पलेट: बिना देरी के अप्रूवल पाएँ

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

मैंने मंज़ूरियाँ हफ़्तों, कभी-कभी महीनों तक खिंचती देखी हैं, जबकि आइडिया ठोस था। मुझे एक S/4HANA माइग्रेशन याद है जिसकी पहली पिच नाकाम रही। प्रपोज़ल सिस्टम आर्किटेक्चर डायग्राम से भरा था और ऑपरेशनल फ़ायदों पर लगभग कुछ नहीं था। हमने उसे दोबारा लिखा। शुरुआत शिपिंग में देरी घटाने, इन्वेंटरी की लागत कम करने और टीम के डिलीवर करने के तरीक़े से की। CFO ने एक ही मीटिंग में उसे मंज़ूर कर दिया।

टेम्पलेट से पहले एक बात और। आपका इम्प्लीमेंटेशन पार्टनर आपका बिज़नेस केस न लिखे। उसका इन्सेंटिव प्रोग्राम शुरू करवाना है। आपका इन्सेंटिव उसे पूरा करना है। इसी तरह $40 मिलियन के प्रोग्राम चुपचाप $90 मिलियन के हो जाते हैं।

एग्ज़ीक्यूटिव समरी ही फ़ैसला करती है

इसे एक पेज में रखिए। हो सकता है एग्ज़ीक्यूटिव इसके अलावा कुछ और न पढ़ें।

समस्या से शुरू कीजिए, आँकड़ों में। प्रपोज़ल को एक-दो वाक्यों में बताइए, बिना किसी तकनीकी ब्योरे के। फिर आँकड़ों के साथ मुख्य फ़ायदे दीजिए, एक सीधी टाइमलाइन, कुल निवेश और प्रमुख जोखिम उनके समाधान के साथ।

जिन कंपनियों को मैंने पहले सपोर्ट किया, उनमें से एक में समरी की शुरुआत “technical objects” और “Embedded HANA” जैसे शब्दों से होती थी। CFO ने पहले पैराग्राफ़ के बाद ही उसे नीचे रख दिया। हमने उसे दोबारा लिखा, ताकि वह “इन्वेंटरी घटाकर सालाना $2.5 मिलियन की बचत” और “ऑर्डर प्रोसेसिंग 40% तेज़” से शुरू हो। उसी CFO ने पूरा पेज पढ़ा और उसी हफ़्ते प्रोजेक्ट मंज़ूर कर दिया।

समरी तैयार होने पर किसी ऐसे व्यक्ति को दीजिए जो प्रोजेक्ट से बाहर है। अगर वह आपको इसे दोबारा समझा सके, तो समरी काम करती है।

तीन पाठकों के लिए लिखिए

सबके लिए एक ही वर्ज़न काम नहीं करता। मैंने मज़बूत प्रपोज़ल इसलिए दम तोड़ते देखे हैं क्योंकि वे ग़लत पाठक के लिए लिखे गए थे।

CFO और बोर्डITबिज़नेस यूज़र्स

वे क्या देखते हैंCFO और बोर्डऐसे आँकड़े जो बिना नोट्स के दोहराए जा सकेंITमौजूदा सिस्टम के मुक़ाबले इंटीग्रेशन का स्कोपबिज़नेस यूज़र्सउनके हफ़्ते की टास्क-दर-टास्क तस्वीर

उन्हें क्या देंCFO और बोर्डसालाना बचत और पेबैक, जोखिम साफ़ शब्दों मेंITgo-live के बाद का सपोर्ट मॉडलबिज़नेस यूज़र्सपहले और बाद की तस्वीर, ट्रेनिंग के समय का ईमानदार अंदाज़ा

उन्हें क्या भरोसा दिलाता हैCFO और बोर्डआशावाद से ज़्यादा साफ़गोईITसबूत कि आप जानते हैं ऐसे प्रोजेक्ट कहाँ चूकेबिज़नेस यूज़र्सहर अतिरिक्त क्लिक के बारे में ईमानदारी

CFO और बोर्ड को ऐसे आँकड़े चाहिए जो वे बिना नोट्स के दोहरा सकें: “सालाना $2 मिलियन की बचत, 18 महीने में पेबैक।” वे जोखिम साफ़ शब्दों में चाहते हैं। इस श्रोता के साथ आशावाद से ज़्यादा साफ़गोई काम करती है।

IT को मौजूदा सिस्टम के मुक़ाबले इंटीग्रेशन का स्कोप चाहिए, go-live के बाद का सपोर्ट मॉडल चाहिए, और इस बात का सबूत कि आप जानते हैं ऐसे प्रोजेक्ट पहले कहाँ चूके हैं।

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

एक बार एक CFO ने मीटिंग के बीच ही बिज़नेस केस ख़ारिज कर दिया, क्योंकि उसमें उनके किसी सवाल का जवाब नहीं था। हमने उसे तीन सेक्शन में दोबारा बनाया, हर श्रोता के लिए एक, और हर सेक्शन को मापने योग्य KPI से जोड़ा। तकनीकी योजना कभी नहीं बदली। बस उसे कहने का तरीक़ा बदला।

ये वे सात सेक्शन हैं जो मैं इसी क्रम में इस्तेमाल करता हूँ। मुझे एक मैन्युफ़ैक्चरिंग कंपनी याद है जिसके CFO को लागत का ब्योरा पेज 23 पर दबा मिला, जबकि CIO को तकनीकी जोखिम मिले ही नहीं। मंज़ूरी छह महीने खिसक गई। ढाँचेदार वर्ज़न के साथ मंज़ूरी दो हफ़्ते में हो गई, जबकि कंटेंट लगभग वही था।

सेक्शन	उसमें क्या होना चाहिए
एग्ज़ीक्यूटिव समरी	आँकड़ों में समस्या, प्रपोज़ल, फ़ायदे, कुल निवेश, टाइमलाइन, शीर्ष जोखिम
मौजूदा स्थिति	पेन पॉइंट, आज उनकी लागत, और कुछ न करने की लागत
प्रस्तावित तरीक़ा	स्कोप, मॉड्यूल, डिप्लॉयमेंट मॉडल (RISE, GROW या on-premise), मुख्य इंटीग्रेशन
वित्तीय केस	पाँच साल की लागत और फ़ायदे, ROI, पेबैक, बड़े प्रोग्राम के लिए NPV
इम्प्लीमेंटेशन प्लान	चरण, माइलस्टोन, टीम, निर्भरताएँ
जोखिम	ओनर और समाधान के साथ ख़ास जोखिम
गवर्नेंस	स्पॉन्सर, स्टीयरिंग कमेटी, चेंज कंट्रोल, एक्सटेंशन मंज़ूरी के नियम

आर्किटेक्चर डायग्राम और कॉन्फ़िगरेशन का ब्योरा ऐपेंडिक्स में रखिए।

वे लागतें जो फ़ाइनेंस डायरेक्टर ढूँढता है

अधूरी लागतें कमज़ोर फ़ायदों से ज़्यादा बिज़नेस केस मारती हैं। इन सबको शामिल कीजिए:

1. सॉफ़्टवेयर: on-premise के लिए लाइसेंस और सालाना सपोर्ट, या RISE और GROW के लिए सब्सक्रिप्शन।
2. इम्प्लीमेंटेशन पार्टनर की फ़ीस।
3. इन्फ्रास्ट्रक्चर, अगर आप ख़ुद चलाते हैं; RISE में SAP इसे सब्सक्रिप्शन के भीतर चलाता है।
4. इंटरनल स्टाफ़ का समय। यह वही लाइन है जो सबसे ज़्यादा छूटती है।
5. ट्रेनिंग और चेंज मैनेजमेंट।
6. डेटा माइग्रेशन और डेटा क्लीनिंग।
7. आवर्ती सपोर्ट। On-premise SAP Enterprise Support लंबे समय से लाइसेंस मूल्य का लगभग 22% सालाना रहा है। RISE और GROW के लिए अनुबंध के हर साल का सब्सक्रिप्शन दिखाइए।
8. go-live के बाद hypercare।

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

ROI, पेबैक और वे फ़ायदे जिन पर CFO भरोसा करेगा

ROI यानी शुद्ध फ़ायदे को कुल निवेश से भाग देना। पाँच साल के $3.5 मिलियन के फ़ायदे और $2 मिलियन की लागत का मतलब है $1.5 मिलियन का शुद्ध फ़ायदा, यानी 75%।

पेबैक यानी निवेश को सालाना शुद्ध कैश फ़ायदे से भाग देना। $1.2 मिलियन का प्रोजेक्ट जो सालाना $400,000 लौटाता है, तीन साल में पेबैक देता है।

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

फ़ायदों को गणना दिखाकर आँकिए:

• इन्वेंटरी: $10 मिलियन का स्टॉक, 15% घटाया, 20% कैरिंग कॉस्ट पर, सालाना $300,000 बचाता है।
• प्रोसेस का समय: रोज़ 200 बार चलने वाला 45 मिनट का काम, 15 मिनट में, $30 प्रति घंटे पर, 250 कार्य-दिवसों में सालाना लगभग $750,000 बचाता है।

रैंप-अप दिखाइए। go-live के बाद पहले साल के फ़ायदे आमतौर पर स्थिर अवस्था से कम होते हैं। जिन फ़ायदों को आप आँक नहीं सकते, उन्हें अलग सूची में रखिए, ताकि वे आँके हुए फ़ायदों को कमज़ोर न करें।

संयमित रहिए। मैंने कारोबारों को मुश्किल SAP प्रोजेक्ट की मंज़ूरी इसलिए पाते देखा है कि वे लागत पर बेरहमी से ईमानदार और फ़ायदों पर संयमित थे। एक मैन्युफ़ैक्चरिंग क्लाइंट ने अपने S/4HANA प्रोजेक्ट के लिए पहले 30% ROI दिखाया। चुनौती मिलने पर उसने केस को ज़्यादा यथार्थवादी 18% पर संशोधित किया। CFO को यह साफ़गोई पसंद आई और उन्होंने मंज़ूरी दे दी।

सब्सक्रिप्शन लाइसेंस और सपोर्ट की जगह लेता है। RISE और GROW सब्सक्रिप्शन हैं, इसलिए पहले साल की लागत on-premise लाइसेंस ख़रीदने से कम पड़ती है। पाँच साल का कुल ख़र्च यूज़र्स, स्कोप और अवधि पर निर्भर करता है। पहला, तीसरा और पाँचवाँ साल साथ-साथ दिखाइए।

बदलाव सिर्फ़ कैश में नहीं, अकाउंटिंग में भी होता है। IFRS के तहत क्लाउड कॉन्ट्रैक्ट अक्सर आपको सॉफ़्टवेयर तक पहुँच देता है, ऐसा सॉफ़्टवेयर एसेट नहीं जिस पर आपका नियंत्रण हो। ऐसे में IFRS Interpretations Committee के 2021 एजेंडा निर्णय का मतलब है कि कॉन्फ़िगरेशन और कस्टमाइज़ेशन की लागत आमतौर पर सेवाएँ मिलने के साथ ख़र्च मानी जाती है, पूँजीकृत नहीं। इससे प्रोग्राम की लागत का बड़ा हिस्सा बैलेंस शीट से इनकम स्टेटमेंट में जा सकता है। वित्तीय केस बोर्ड के पास जाने से पहले अपने RISE या GROW कॉन्ट्रैक्ट के ट्रीटमेंट पर अपने ऑडिटर्स से सहमति कर लीजिए।

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

AI केस में तभी आए जब अनुमान वर्कफ़्लो के स्तर पर हों। Joule और दूसरे AI फ़ीचर ख़ास कामों में समय बचा सकते हैं। हर AI फ़ायदे को एक नामित वर्कफ़्लो, यूज़र्स की संख्या और ऐसी अडॉप्शन दर से जोड़िए जिसका आप बचाव कर सकें। CFO हर हफ़्ते “AI पूरे कारोबार को बदल देगा” वाली पिचें देखते हैं और उन्हें बहुत हल्के में लेते हैं।

कुछ न करने की लागत छोड़ देना। अगर मौजूदा सिस्टम की वजह से सालाना $500,000 का रीवर्क हो रहा है, तो वह केस में आना चाहिए। कभी-कभी वह SAP निवेश से भी बड़ा होता है।

रुकावट को नज़रअंदाज़ करना। ट्रेनिंग का समय, कटओवर डाउनटाइम और go-live के बाद का धीमा पहला महीना, ये सब रिटर्न घटाते हैं।

धुंधले जोखिम। “डेटा की समस्याएँ” कोई जोखिम नहीं है। “मास्टर डेटा का मेल न खाना, जिससे पहले 30 दिनों में इनवॉइस रिजेक्ट हों” जोखिम है।

बिना ब्योरे की एक अकेली go-live तारीख़। देरी आमतौर पर हैंडऑफ़ में शुरू होती है: रिक्वायरमेंट से कॉन्फ़िगरेशन, टेस्टिंग से साइन-ऑफ़, ट्रेनिंग से रेडीनेस। इन्हें दिखाइए।

कंपनी के आकार को नज़रअंदाज़ करना। एक प्रोजेक्ट में, जिस पर मैंने काम किया, एक छोटे डिस्ट्रीब्यूटर ने किसी बड़ी कॉर्पोरेशन की गवर्नेंस प्रक्रिया की नक़ल कर ली। साप्ताहिक स्टीयरिंग मीटिंग घंटों की उत्पादकता खा गईं, जब तक प्रक्रिया छोटी नहीं की गई। 200 से कम स्टाफ़ वाली कंपनी के लिए 8 से 10 पेज काफ़ी हैं। एंटरप्राइज़ पूरा वित्तीय मॉडल और विस्तृत गवर्नेंस सेक्शन उम्मीद करते हैं।

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

SAP बिज़नेस केस में क्या होना चाहिए?

सात सेक्शन: एग्ज़ीक्यूटिव समरी, मौजूदा स्थिति और कुछ न करने की लागत, प्रस्तावित तरीक़ा और डिप्लॉयमेंट मॉडल, ROI और पेबैक के साथ पाँच साल का वित्तीय केस, इम्प्लीमेंटेशन प्लान, ओनर के साथ ख़ास जोखिम, और गवर्नेंस मॉडल। तकनीकी ब्योरा ऐपेंडिक्स में रखिए।

SAP बिज़नेस केस ख़ारिज क्यों होते हैं?

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

SAP इम्प्लीमेंटेशन का ROI कैसे निकालते हैं?

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

RISE with SAP बिज़नेस केस को कैसे बदलता है?

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

SAP बिज़नेस केस कितना लंबा होना चाहिए?

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

SAP बिज़नेस केस में कुछ न करने की लागत क्या होती है?

वह जो कारोबार मौजूदा सिस्टम पर बने रहकर लगातार खोता रहता है: मैन्युअल जुगाड़, रीकन्सिलिएशन की मेहनत, रिपोर्टिंग में देरी, पुराने सिस्टम का सपोर्ट और अविश्वसनीय डेटा पर लिए गए फ़ैसले। अगर आप ECC पर हैं, तो 2027 के बाद एक्सटेंडेड मेंटेनेंस की लागत भी जोड़िए।