SAP प्रोजेक्ट बजट से ऊपर क्यों जाते हैं और इसे कैसे रोकें

SAP प्रोजेक्ट ज़्यादातर इसलिए बजट से ऊपर जाते हैं क्योंकि कंपनियाँ शुरुआत में लागत कम रखने की कोशिश करती हैं, फिर Explore चरण में झटका खाती हैं, जब Fit-to-Standard वर्कशॉप असली scope दिखाती हैं। जिन प्रोग्रामों की मैंने समीक्षा की है, उनमें 40 से 60 प्रतिशत के overrun आम हैं।

संक्षिप्त उत्तर: SAP बजट तब overrun होता है जब वह scope जानने से पहले तय कर दिया गया हो, और जब उस scope पर क्लाइंट के बजाय vendor का नियंत्रण हो। Explore चरण के दौरान WRICEF की संख्या पर नज़र रखें, scope का स्वामित्व खुद लें और 10 से 20 प्रतिशत contingency अपनी तरफ़ रखें।

सर्वे के औसत ज़्यादा शांत दिखते हैं। Panorama Consulting की 2026 ERP Report में पाया गया कि एक चौथाई से ज़्यादा संगठन अपने ERP बजट से ऊपर गए, और अतिरिक्त तकनीकी ज़रूरतें इसका मुख्य कारण थीं। सर्वे के औसत और जो प्रोग्राम आखिरकार किसी सलाहकार के सामने पहुँचते हैं, वे दो अलग समूह हैं, इसलिए दूसरे के लिए योजना बनाएँ।

40-60%

बजट overrun जो मैं समीक्षा किए जाने वाले SAP प्रोग्रामों में अक्सर देखता हूँ

स्रोत: Noel D'Costa, प्रकाशित अवलोकन

यह लेख overrun के बारे में है, शुरुआती आँकड़े के बारे में नहीं। कंपनी के आकार के हिसाब से लागत के दायरे, पैसा कहाँ जाता है, डे रेट और बजट फ़ॉर्मूले के लिए मेरी गाइड SAP implementation की लागत कितनी है पढ़ें।

जिन 21 SAP प्रोग्रामों का मैंने नेतृत्व किया है या जिन्हें बचाया है, उनमें वही कारण बार-बार लौटते हैं। इनमें से ज़्यादातर कॉन्ट्रैक्ट साइन होने से पहले ही दिख जाते हैं।

1. बजट कम रखा जाता है, फिर Explore असली scope दिखाता है

यह सबसे आम कारण है जो मैं देखता हूँ। कंपनियाँ शुरुआत में लागत कम रखने की कोशिश करती हैं, अक्सर इसलिए कि business case को ऐसा आँकड़ा चाहिए जिसे बोर्ड मंज़ूर करे। फिर Explore चरण आता है।

SAP Activate में Explore वह चरण है जहाँ Fit-to-Standard वर्कशॉप SAP की स्टैंडर्ड प्रक्रियाओं को इस बात से परखती हैं कि व्यवसाय असल में कैसे काम करता है (SAP Learning)। वहाँ मिली हर कमी एक backlog आइटम बन जाती है: एक report, एक interface, एक conversion, एक enhancement, एक form या एक workflow। इनमें से कोई भी मूल कीमत में नहीं था।

बजट इसलिए गलत नहीं था कि किसी ने हिसाब में गलती की। वह इसलिए गलत था कि उसे scope के अस्तित्व में आने से पहले तय कर दिया गया था। अगर हो सके, तो अंतिम आँकड़े को मंज़ूरी देने से पहले एक छोटा Fit-to-Standard आकलन करा लें।

2. Vendor scope को नियंत्रित करता है

साइन करने से पहले लागत की जो सबसे बड़ी गलती मैं देखता हूँ, वह है vendor को scope पर नियंत्रण करने देना। जब system integrator scope लिखता है, तो scope वह बताता है जो integrator डिलीवर करने की योजना बना रहा है, वह नहीं जो व्यवसाय को चाहिए।

कमियाँ बाद में change requests के रूप में सामने आती हैं, और हर change request की कीमत वही vendor तय करता है। Scope खुद लिखें, या implementation से स्वतंत्र किसी व्यक्ति से उसे अपने साथ लिखवाएँ।

3. लागत नियंत्रण के बिना scope में बदलाव

एक रिटेल चेन ने $5M का बजट बनाया और $12.3M पर खत्म किया। कमज़ोर requirements gathering के कारण scope लगातार बदलता रहा। बीच में उसे पता चला कि उसकी inventory प्रक्रियाएँ SAP की स्टैंडर्ड कार्यक्षमता से मेल नहीं खातीं, और इसके बाद भारी customisation हुआ।

उसने अपने पुराने सिस्टम से data migration को भी कम आँका था। Design के दौरान प्रक्रियाओं को स्टैंडर्ड के अनुरूप करना कहीं सस्ता पड़ता।

4. शीर्ष प्रबंधन के दबाव में तय टाइमलाइन

एक वैश्विक मैन्युफ़ैक्चरिंग प्रोग्राम बजट से 143% ऊपर गया ($5.8M की योजना के मुकाबले $14M) और 11 महीने देर से लॉन्च हुआ। कारण: शीर्ष प्रबंधन का अवास्तविक टाइमलाइन दबाव, कम स्टाफ़ वाली आंतरिक टीम, एक साथ बहुत सारे मॉड्यूल, और इंडस्ट्री विशेषज्ञता के बिना सबसे सस्ता पार्टनर।

सस्ता अपने आप बेहतर नहीं होता। एक क्लाइंट जिसने सबसे सस्ता implementation विकल्प चुना, उसे उन समस्याओं को ठीक करने में 30% ज़्यादा खर्च करना पड़ा जिनसे ज़्यादा अनुभवी टीम बच जाती।

5. पार्ट-टाइम आंतरिक लोग

जो प्रोग्राम समर्पित process owners के बजाय पार्ट-टाइम प्रतिनिधि लगाते हैं, वे हर फ़ैसले पर दिन गँवाते हैं। उस वैश्विक मैन्युफ़ैक्चरिंग प्रोग्राम की कम स्टाफ़ वाली आंतरिक टीम ही उसके 11 महीने देर से चलने के कारणों में से एक थी।

आपके सबसे अच्छे लोग महीनों तक आधे या उससे ज़्यादा समय प्रोग्राम में लगे रहेंगे। न उनका समय और न go-live के आसपास की सुस्ती किसी vendor कोटेशन में दिखती है।

6. देर से पता चला डेटा

Pre-production में पता चलने वाली डेटा समस्याएँ सबसे महँगी होती हैं। Profiling requirements के साथ-साथ चलनी चाहिए, configuration के बाद नहीं। लाइव सिस्टम के दबाव में तीन महीने की सफ़ाई, overrun वाले प्रोग्रामों में लगातार cost-of-delay की सबसे बड़ी मदों में होती है।

मैं इस विषय पर अपने YouTube चैनल के एक वीडियो में भी बात करता हूँ (अंग्रेज़ी में)।

सबसे साफ़ शुरुआती चेतावनी संकेत खुद Explore चरण है। WRICEF की संख्या पर नज़र रखें: reports, interfaces, conversions, enhancements, forms और workflows। अगर यह सूची हर वर्कशॉप के साथ बढ़ती रहे, तो बजट पहले ही scope से पीछे है।

नीचे दिया हर संकेत ऊपर के किसी एक कारण की ओर इशारा करता है। इनमें से ज़्यादातर को साप्ताहिक प्रोग्राम समीक्षा में जाँचा जा सकता है।

चेतावनी संकेत	आम तौर पर इसका क्या मतलब है	क्या करें
Explore के दौरान WRICEF की संख्या बढ़ रही है	असली scope कीमत लगाए गए scope से बड़ा है	Explore के अंत में, Realize शुरू होने से पहले, बजट का baseline दोबारा तय करें
कमियाँ डिफ़ॉल्ट रूप से "बना दो" कहकर बंद की जा रही हैं	स्टैंडर्ड प्रक्रियाओं को चुनौती नहीं दी जा रही	business owner से हर कमी को स्टैंडर्ड के मुकाबले सही ठहराने को कहें
Scope दस्तावेज़ system integrator ने ड्राफ़्ट किए हैं	Vendor नियंत्रित करता है कि किसकी कीमत लगेगी	Scope का स्वामित्व लें और किसी स्वतंत्र व्यक्ति के साथ उसकी समीक्षा करें
Change requests की समीक्षा मासिक होती है या उनकी कीमत नहीं लगती	छोटे बदलाव बिना दिखे जमा होते जाते हैं	हर change request की कीमत लगाएँ और हर हफ़्ते समीक्षा करें
Explore के अंत तक data profiling शुरू नहीं हुई	डेटा समस्याएँ टेस्टिंग या cutover में सामने आएँगी	Profiling अभी शुरू करें, requirements के साथ-साथ
Key users अब भी पार्ट-टाइम हैं	फ़ैसले धीमे होते हैं और दोबारा काम बढ़ता है	उनके रोज़ के काम के लिए backfill करें या टाइमलाइन खिसकाएँ

इनमें से हर एक ऊपर के किसी कारण को संबोधित करता है। कहानियाँ उन प्रोग्रामों से हैं जिन पर मैंने काम किया या जिनकी समीक्षा की।

1. Scope के मालिक बनें। इसे क्लाइंट की तरफ़ से लिखें, Explore के अंत में फ़्रीज़ करें और बाद के हर बदलाव को कीमत वाला फ़ैसला मानें, वर्कशॉप का नोट नहीं।
2. स्टैंडर्ड प्रक्रियाएँ अपनाएँ। हर customisation की कीमत दो बार चुकानी पड़ती है: बनाने में, फिर हर upgrade पर। एक मैन्युफ़ैक्चरिंग क्लाइंट ने customise करने के बजाय अपनी प्रक्रियाओं को SAP स्टैंडर्ड के अनुरूप ढालकर $800K से ज़्यादा बचाए। कुछ विभागों के लिए यह तकलीफ़देह था, लेकिन वित्तीय अंतर बहुत बड़ा था।
3. Rollout को चरणों में करें। एक रिटेल क्लाइंट ने सब कुछ एक साथ करने के बजाय अपने rollout को 18 महीनों में तीन चरणों में बाँटकर $1.2M बचाए। शुरुआती निवेश 40% घटा, और चरण 1 की सीख ने बाद के चरणों को तेज़ बनाया।
4. कम डे रेट के लिए नहीं, विशेषज्ञता के लिए भुगतान करें। एक केमिकल कंपनी क्लाइंट ने सामान्य SAP पार्टनर से इंडस्ट्री विशेषज्ञ की ओर रुख किया और ऊँचे hourly रेट के बावजूद कुल मिलाकर 20% कम खर्च किया। विशेषज्ञों ने तेज़ी से काम किया और कम गलतियाँ कीं।
5. Contingency अपनी तरफ़ रखें। बजट के ऊपर 10 से 20 प्रतिशत रखें, जो केवल नाम से पहचाने गए जोखिमों के लिए जारी हो। पार्टनर की कीमत के अंदर की contingency पार्टनर की प्राथमिकताओं पर खर्च होती है।
6. Change requests की हर हफ़्ते समीक्षा करें। हर एक की मंज़ूरी से पहले बजट और शेड्यूल पर उसके असर की कीमत लगाएँ, महीने के अंत में नहीं।
7. Regression testing को automate करें। Tricentis Tosca या SAP के अपने test automation जैसे टूल किसी भी ऐसे प्रोग्राम में अपनी लागत वसूल कर लेते हैं जिसमें दो से ज़्यादा टेस्ट साइकिल चलती हैं, और go-live के बाद हर upgrade एक और साइकिल है।

वाणिज्यिक पक्ष के लिए, मेरी SAP लाइसेंस negotiation चेकलिस्ट और CFOs के लिए कॉन्ट्रैक्ट लागत समीक्षा बताती हैं कि साइन करने से पहले किन बातों पर ज़ोर देना है।

Subscription मॉडल खर्च को capital से operating expense में ले जाता है। यह overrun का जोखिम हटाता नहीं, लेकिन जोखिम की जगह बदल देता है।

GROW with SAP, S/4HANA Cloud Public Edition पर चलता है, जो केवल released interfaces के ज़रिए extensions की अनुमति देता है। इससे WRICEF सूची के बढ़ने की सीमा तय होती है, और GROW प्रोग्राम अक्सर लगभग 6 से 9 महीने लेते हैं। बदले में असामान्य प्रक्रियाओं के अनुसार SAP को ढालने की आज़ादी कम होती है।

RISE with SAP, S/4HANA Cloud Private Edition पर चलता है, जहाँ आप अब भी core में बदलाव कर सकते हैं। वहाँ Clean Core एक governance फ़ैसला है, तकनीकी सीमा नहीं, इसलिए Explore चरण का जोखिम on-premise जैसा ही है। RISE प्रोग्राम आम तौर पर 9 से 18 महीने लेते हैं, और बहु-वर्षीय subscription term business case में दिखनी चाहिए।

AI बजट की एक नई मद है, पहले से गिनी जाने वाली बचत नहीं। Joule की कुछ क्षमताएँ SAP cloud subscriptions के साथ आती हैं, जबकि premium AI क्षमताओं की कीमत अलग लगती है। AI से बचत का दावा करने वाले किसी भी पार्टनर रेट कार्ड के पीछे की productivity धारणा माँगें।

यह इस बात के लिए मायने रखता है कि एक बड़ा प्रोग्राम income statement पर कैसे असर डालता है। IFRS और US GAAP के तहत, ऐसी संपत्ति बनाने की लागत capitalise की जा सकती है जिस पर आपका नियंत्रण हो; संचालन, ट्रेनिंग और तैयारी की लागत नहीं। Cloud बजट के एक बड़े हिस्से के लिए जवाब बदल देता है।

लागत का तत्व	On-premise लाइसेंस	Cloud subscription (RISE / GROW)
लाइसेंस या subscription फ़ीस	अमूर्त संपत्ति के रूप में capitalise करें	Term के दौरान expense करें (सेवा अनुबंध)
Configuration और build सेवाएँ	सीधे जुड़ी हों तो capitalise करें	IFRS: अक्सर expense, जब तक वे आपके नियंत्रण वाली अलग संपत्ति न बनाएँ। US GAAP: implementation लागत capitalise करें और hosting term में amortise करें
Build पर आंतरिक श्रम	सीधे जुड़ा हो तो capitalise करें	ऊपर जैसा ही बँटवारा
ट्रेनिंग और change management	Expense	Expense
डेटा की सफ़ाई	Expense	Expense
डेटा conversion टूल जो आप रखते हैं	दोबारा इस्तेमाल लायक हों तो capitalise करें	हर मामले का अलग आकलन करें
Hypercare और सपोर्ट	Expense	Expense

IFRS की स्थिति IFRS Interpretations Committee के cloud computing व्यवस्थाओं में configuration और customisation लागत पर 2021 के agenda decision से आती है। US GAAP की स्थिति ASU 2018-15 से आती है। खासकर IFRS के तहत, जो RISE business case on-premise जैसा capitalisation मानकर चलता है, वह पहले साल के मुनाफ़े को काफ़ी बढ़ा-चढ़ाकर दिखा सकता है।

Documentation तय करता है कि आप कितना रख पाते हैं। एक मैन्युफ़ैक्चरिंग क्लाइंट ने सही ढंग से capitalise करके चालू वर्ष के खर्च में $2.3M बचाए, क्योंकि उसने कंसल्टेंट गतिविधियों को इतनी बारीकी से ट्रैक किया था कि अपने तरीके का बचाव कर सके। एक दूसरे क्लाइंट को तकलीफ़देह restatement झेलना पड़ा क्योंकि वह अपने capitalisation फ़ैसलों को प्रमाणित नहीं कर सका।

ऑडिटर बड़े capitalised प्रोजेक्ट्स को कड़ी नज़र से देखते हैं। प्रोग्राम शुरू होने से पहले उनके साथ नीति तय करें, साल के अंत में नहीं।

ज़्यादातर overrun वाले प्रोग्रामों में planning की विफलता नहीं थी। उनमें planning के चरण में ईमानदारी की विफलता थी। जो CFO उचित contingency के साथ यथार्थवादी योजना मंज़ूर करता है, वह उस CFO से कम खर्च करता है जो बिना contingency के उम्मीदों भरी योजना मंज़ूर करता है।

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

SAP implementation बजट से ऊपर क्यों जाते हैं?

ज़्यादातर इसलिए कि शुरुआत में बजट कम रखा जाता है, फिर Explore चरण असली scope दिखाता है। Fit-to-Standard वर्कशॉप कमियों को ऐसे reports, interfaces, conversions, enhancements, forms और workflows में बदल देती हैं जिनकी कभी कीमत नहीं लगी थी। Vendor के नियंत्रण वाला scope, पार्ट-टाइम आंतरिक टीमें और देर से हुआ डेटा का काम इसे और बिगाड़ते हैं।

SAP प्रोजेक्ट आम तौर पर बजट से कितना ऊपर जाते हैं?

जिन प्रोग्रामों की मैंने समीक्षा की है, उनमें 40 से 60 प्रतिशत के overrun आम हैं। Panorama Consulting के 2026 सर्वे में पाया गया कि एक चौथाई से ज़्यादा संगठन अपने ERP बजट से ऊपर गए। जो प्रोग्राम किसी सलाहकार तक पहुँचते हैं, वे अक्सर उस समूह का परेशानी वाला सिरा होते हैं।

SAP बजट overrun के शुरुआती चेतावनी संकेत क्या हैं?

सबसे साफ़ संकेत है WRICEF की संख्या जो Explore चरण के दौरान बढ़ती रहती है। दूसरे संकेत हैं vendor के ड्राफ़्ट किए scope दस्तावेज़, change requests जिनकी हर हफ़्ते कीमत नहीं लगती, data profiling जो अभी शुरू नहीं हुई और key users जो अब भी पार्ट-टाइम काम कर रहे हैं। अगर सूची बढ़ गई है, तो Explore के अंत में बजट का baseline दोबारा तय करें।

SAP प्रोजेक्ट में scope creep को कैसे रोकें?

System integrator को scope लिखने देने के बजाय क्लाइंट की तरफ़ से उसके मालिक बनें। Explore के अंत में उसे फ़्रीज़ करें, हर कमी को स्टैंडर्ड SAP के मुकाबले चुनौती दें और हर change request को मंज़ूर करने से पहले उसकी कीमत लगाएँ। Change requests की हर हफ़्ते समीक्षा करें, महीने के अंत में नहीं।

क्या RISE with SAP बजट से ऊपर जाने का जोखिम कम करता है?

अपने आप नहीं। RISE, Private Edition पर चलता है, जहाँ core में अब भी बदलाव किया जा सकता है, इसलिए Explore चरण का जोखिम on-premise जैसा ही है। Public Edition पर GROW with SAP extensions को released interfaces तक सीमित करता है, जिससे scope के बढ़ने की गुंजाइश घटती है।

क्या RISE with SAP implementation लागत capitalise की जा सकती है?

आंशिक रूप से, और यह आपके accounting framework पर निर्भर करता है। Subscription खुद आम तौर पर expense होता है। IFRS के तहत SaaS व्यवस्था में configuration और customisation सेवाएँ भी अक्सर expense होती हैं, जब तक वे आपके नियंत्रण वाली अलग संपत्ति न बनाएँ; US GAAP (ASU 2018-15) के तहत implementation लागत capitalise की जाती है और hosting term में amortise की जाती है।