SAP Clean Core रणनीति: इसका मतलब, लेवल A से D और गवर्नेंस

SAP clean core का मतलब है अपने S/4HANA सिस्टम को उतना ही SAP standard के क़रीब रखना जितना आपका बिज़नेस अनुमति देता है। आप जो भी जोड़ते हैं, वह उन इंटरफ़ेस के ज़रिए बनता है जिन्हें SAP ने released किया है और स्थिर रखने का वादा किया है, ताकि अपग्रेड उसे तोड़ न दें।

छोटा जवाब: clean core एक अनुशासन है कि आप SAP को कैसे बढ़ाते हैं और उसका गवर्नेंस कैसे करते हैं। कस्टम लॉजिक on-stack ABAP Cloud के साथ या side-by-side SAP BTP पर जाता है, और SAP हर एक्सटेंशन को लेवल A (सबसे साफ़) से लेवल D (हटाने लायक़ मॉडिफ़िकेशन) तक ग्रेड करता है। फ़ायदा है तेज़ अपग्रेड: मैंने कंपनियों को इसी तरीक़े से अपग्रेड का समय 40% घटाते देखा है।

अगर आपका सिस्टम SAP standard ऑब्जेक्ट्स में किए गए मॉडिफ़िकेशन से भरा है, तो हर रिलीज़ एक regression प्रोजेक्ट बन जाती है। अगर आपका कस्टम लॉजिक released इंटरफ़ेस के पीछे है, तो अपग्रेड रोज़मर्रा का मेंटेनेंस बन जाते हैं।

मैंने कंपनियों को clean core के सिद्धांत अपनाकर अपग्रेड का समय 40% घटाते देखा है। उन्होंने कस्टमाइज़ेशन को न्यूनतम रखा और जो रखा, उसका ठीक से गवर्नेंस किया।

2024 में एक यूरोपीय कंज़्यूमर गुड्स कंपनी ने अपने पुराने प्राइसिंग लॉजिक को SAP BTP पर, कोर के बाहर बने एक मॉड्यूलर Fiori ऐप से बदल दिया। इससे उस लॉजिक के लिए regression testing पूरी तरह ख़त्म हो गई।

clean core वाले ERP को भी आप कस्टमाइज़ कर सकते हैं। शर्त यह है कि कस्टमाइज़ेशन उन इंटरफ़ेस का इस्तेमाल करे जिन्हें SAP ने released किया है और स्थिर रखने का वादा किया है। SAP इसके दो तरीक़े देता है:

• On-stack, ABAP Cloud के साथ। एक्सटेंशन S/4HANA के अंदर चलते हैं, लेकिन सिर्फ़ released API और extension points का इस्तेमाल करते हैं।
• Side-by-side, SAP BTP पर। एक्सटेंशन अलग ऐप्लिकेशन के रूप में चलते हैं और API या events के ज़रिए S/4HANA से बात करते हैं।

SAP अपने तरीक़े को BTP-first बताता है, जिसमें हर use case के हिसाब से चुनाव होता है। मेरे अनुभव में यह कम मायने रखता है कि कोड कहाँ चलता है। ज़्यादा मायने यह रखता है कि उस ज़रूरत के लिए कोड चाहिए भी या नहीं।

"गंदा" कोर हर उस व्यक्ति को जाना-पहचाना लगेगा जिसने ECC चलाया है: बदले हुए standard प्रोग्राम, Z-टेबल जिनमें सीधे लिखा जाता है, इंटरफ़ेस जो SAP के अंदरूनी हिस्से पढ़ते हैं, implicit enhancements जिन्हें किसी ने डॉक्यूमेंट नहीं किया। जब यह सब बना, तब इसमें कुछ ग़लत नहीं था। बस यह ऐसे सिस्टम के लिए नहीं बना था जो हर एक-दो साल में अपग्रेड होता है।

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

SAP clean core को पाँच मार्गदर्शक सिद्धांतों के इर्द-गिर्द रखता है। SAP हर सिद्धांत को ऐसे समझाता है, और मैं सबसे पहले यह देखता हूँ:

सिद्धांत	SAP का मतलब	मैं सबसे पहले क्या जाँचता हूँ
प्रोसेस	जितना हो सके SAP के standard प्रोसेस के क़रीब रहना	कौन से प्रोसेस वेरिएंट सिर्फ़ इसलिए हैं क्योंकि "हम हमेशा से ऐसा ही करते आए हैं"
एक्सटेंसिबिलिटी	released API के ज़रिए कोर से अलग एक्सटेंशन, और कौन सा विकल्प इस्तेमाल हो इस पर गवर्नेंस	कितना कस्टम कोड है, उसमें से कितना इस्तेमाल होता है और वह किस लेवल पर है
डेटा	साफ़, नियमों के मुताबिक़ डेटा और एक तय गवर्नेंस मॉडल	डुप्लिकेट और अधूरा मास्टर डेटा, ऐसे कस्टम फ़ील्ड जिन्हें कोई समझा नहीं सकता
इंटीग्रेशन	सपोर्टेड टेक्नोलॉजी पर बने मानकीकृत, सुरक्षित कनेक्शन	Point-to-point इंटरफ़ेस जो सीधे टेबल पढ़ते हैं
ऑपरेशंस	गवर्नेंस, लोग, प्रोसेस और टूल जो बाक़ी चारों को अपनी जगह बनाए रखते हैं	एक्सटेंशन को कौन मंज़ूरी देता है, और अगला मॉडिफ़िकेशन किससे रुकता है

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

अगस्त 2025 में SAP ने अपने पुराने तीन-tier एक्सटेंसिबिलिटी मॉडल की जगह clean core level concept लागू किया। हर एक्सटेंशन को इस आधार पर रेट किया जाता है कि वह कैसे बना है, कोर से कितना अलग है और अपग्रेड में कितनी सुरक्षा से टिकता है। अगर आप SAP का पुराना मटीरियल पढ़ें जिसमें tiers की बात हो, तो उसकी जगह अब यही है।

लेवल Aलेवल Bलेवल Cलेवल D

क्या इस्तेमाल करता हैलेवल Aसिर्फ़ सार्वजनिक रूप से released, स्थिर इंटरफ़ेसलेवल Bसाथ में SAP के classic APIलेवल CSAP के अंदरूनी ऑब्जेक्टलेवल Dमॉडिफ़िकेशन, SAP टेबल में लिखना, implicit enhancements

अपग्रेड जोखिमलेवल Aसबसे कम, stability contracts के साथलेवल Bआमतौर पर अपग्रेड में स्थिरलेवल Cहर अपग्रेड पर जाँच ज़रूरीलेवल Dसबसे ज़्यादा

क्या तय करेंलेवल Aहर नई चीज़ के लिए डिफ़ॉल्टलेवल Bस्वीकार करें, कारण दर्ज करकेलेवल Cकारण के साथ स्वीकार करें, हर अपग्रेड पर दोबारा जाँचेंलेवल Dपहले हटाएँ, या B या C पर ले जाएँ

स्रोत: SAP clean core level concept, SAP News, अगस्त 2025

लेवल A सिर्फ़ सार्वजनिक रूप से released इंटरफ़ेस इस्तेमाल करता है जिनके साथ stability contracts हैं, और ये SAP Build, ABAP Cloud या BTP से बनते हैं। लेवल B इसमें SAP के classic API जोड़ता है। लेवल C SAP के अंदरूनी ऑब्जेक्ट को छूता है, और SAP इनके लिए एक changelog की योजना बना रहा है ताकि अपग्रेड प्लानिंग में मदद मिले।

लेवल D में मॉडिफ़िकेशन, SAP टेबल में लिखना, implicit enhancements और ऐसी दूसरी तकनीकें आती हैं जिनकी SAP सलाह नहीं देता। यह पुरानी "साफ़ है या नहीं" वाली बहस से ज़्यादा काम का है, क्योंकि इससे आप हर ऑब्जेक्ट के लिए एक लक्ष्य तय कर सकते हैं। अपग्रेड से पहले अपने लेवल D ऑब्जेक्ट को B या C पर ले जाना ही जोखिम में असली कमी है।

ABAP Cloud, SAP का cloud-ready ABAP डेवलपमेंट मॉडल है। डेवलपर "ABAP for Cloud Development" भाषा वर्शन का इस्तेमाल करते हैं और सिर्फ़ released ऑब्जेक्ट, public API और extension points पर ही निर्माण कर सकते हैं। इसकी शुरुआत SAP BTP ABAP environment में हुई थी और अब यह S/4HANA के हर एडिशन में उपलब्ध है (SAP ABAP Cloud FAQ)।

S/4HANA Cloud आपको एक्सटेंशन के तीन रास्ते देता है। Key user extensibility, SAP कोड को छुए बिना फ़ील्ड, लॉजिक और UI के आसान बदलाव संभालती है। ABAP Cloud के साथ developer extensibility कसकर जुड़े लॉजिक को संभालती है, और SAP BTP पर side-by-side एक्सटेंशन वह सब संभालते हैं जिसे अलग रहना चाहिए।

एडिशन तय करता है कि आपके पास कितने विकल्प हैं:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition और on-premise
ABAP डेवलपमेंट	सिर्फ़ ABAP Cloud, रिलीज़ 2208 से नए ग्राहकों के लिए अनिवार्य	2022 से ABAP Cloud की सिफ़ारिश; classic ABAP अब भी अनुमत
SAP कोड में बदलाव	संभव नहीं	संभव, लेकिन ये लेवल D हैं
Key user और BTP side-by-side एक्सटेंशन	उपलब्ध	उपलब्ध
clean core कौन लागू करता है	सिस्टम	आपका गवर्नेंस

Private Edition ग्राहकों के लिए मेरा नियम: हर नई चीज़ के लिए ऐसा मानिए जैसे यह Public Edition हो। Classic ABAP की अनुमति है, लेकिन आज जोड़ा गया हर classic ऑब्जेक्ट एक ऐसा फ़ैसला है जिसका बचाव किसी को अगले अपग्रेड पर करना पड़ेगा।

clean core के फ़ैसले बिज़नेस और IT से बनी एक design authority के हाथ में होने चाहिए। अकेला IT हर उस चीज़ को मंज़ूरी दे देगा जो तकनीकी रूप से संभव है। अकेला बिज़नेस अपना पुराना प्रोसेस वापस माँगेगा।

मैं इसे ऐसे सेट करूँगा:

1. सदस्य तय करें। हर बड़े क्षेत्र के बिज़नेस प्रोसेस ओनर, साथ में solution architect और lead developer। बिज़नेस ओनर तय करते हैं कि ज़रूरत असली है या नहीं, और IT तय करता है कि उसे कैसे बनाया जाए।
2. बिल्ड शुरू होने से पहले प्राथमिकता का क्रम तय करें। पहले standard प्रोसेस, फिर key user extensibility, फिर ABAP Cloud या BTP पर लेवल A। लेवल B या C के लिए लिखित कारण चाहिए, और लेवल D के लिए एग्ज़िट प्लान।
3. हर एक्सटेंशन अनुरोध के साथ एक ओनर और बिज़नेस कारण हो। ओनर नहीं, तो बिल्ड नहीं। फ़ैसला और स्वीकार किया गया लेवल एक ही रजिस्टर में दर्ज हो।
4. Transports से पहले एक तकनीकी गेट लगाएँ। ABAP test cockpit के clean core चेक तय समय पर चलाएँ, और नया लेवल D कोड प्रोडक्शन तक पहुँचने से पहले रोक दें।
5. हर अपग्रेड से पहले रजिस्टर की समीक्षा करें। जो अब कोई इस्तेमाल नहीं करता उसे हटाएँ, और जो अब ऊँचे लेवल तक पहुँच सकता है उसे वहाँ ले जाएँ।

उस मेज़ पर पहले सवाल होता था "यह BTP पर क्यों नहीं रह सकता?" आज मैं पूछूँगा "यह लेवल A क्यों नहीं हो सकता?" अगर नहीं हो सकता, तो अगला सवाल है कि आप कौन सा लेवल स्वीकार कर रहे हैं और क्यों।

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

clean core तकनीकी समस्या बाद में है, पहले यह चेंज मैनेजमेंट की समस्या है। हर कस्टम ऑब्जेक्ट इसलिए मौजूद है क्योंकि किसी ने उसे माँगा था। उसे हटाने का मतलब है उस व्यक्ति को यह भरोसा दिलाना कि standard प्रोसेस काफ़ी अच्छा है।

यह बातचीत तब बेहतर चलती है जब बिज़नेस नया प्रोसेस काम करते हुए देखता है, उस पर बनी कोई स्लाइड नहीं। यह तब भी बेहतर चलती है जब आप इस दावे को परखते हैं कि कोई प्रोसेस अनोखा है, क्योंकि अक्सर वह होता नहीं (नीचे स्टेप 4 और 5 देखें)।

स्किल्स उतनी ही ज़रूरी हैं जितने टूल। जिस ABAP टीम ने ABAP Cloud या BTP पर काम नहीं किया, वह सीखते समय प्रोग्राम को धीमा करेगी। जिस एक मैन्युफ़ैक्चरर के साथ मैंने काम किया, उसने अपना S/4HANA प्रोजेक्ट शुरू होने से पहले तीन महीने का आंतरिक BTP प्रोग्राम चलाया, और बिल्ड के दौरान कम सरप्राइज़ के रूप में इसका फ़ायदा मिला।

clean core कंप्लायंस यह है कि आपका सिस्टम पाँचों सिद्धांतों पर SAP के मानदंडों को कितना पूरा करता है। आँकड़ों के बिना आप इसे मैनेज नहीं कर सकते, और SAP आपको ये आँकड़े पाने की तीन जगहें देता है।

1. ABAP test cockpit। कोड-स्तर की जाँच के लिए SAP का टूल। यह दिखाता है कि कौन से कस्टम ऑब्जेक्ट unreleased ऑब्जेक्ट, मॉडिफ़िकेशन या टेबल तक सीधी पहुँच का इस्तेमाल करते हैं।
2. SAP Readiness Check। यह आपके maintenance agreement के साथ आता है और कमिट करने से पहले दिखाता है कि S/4HANA पर जाने से क्या-क्या प्रभावित होगा।
3. RISE with SAP Methodology dashboard, जिसे clean core dashboard भी कहते हैं। यह SAP Cloud ALM में चलता है। इसका सिस्टम व्यू आपका S/4HANA वर्शन जाँचता है, पुष्टि करता है कि डेटा कलेक्शन टूल चालू हैं और अपग्रेड से पहले एक्सटेंशन की समीक्षा करता है, जबकि इसका ऑपरेशंस व्यू ऑपरेशनल KPI ट्रैक करता है।

हर महीने design authority के सामने मैं जो आँकड़े रखूँगा, वे सीधे हैं। हर लेवल पर कितने कस्टम ऑब्जेक्ट हैं, और क्या लेवल D घट रहा है? कितने अपवाद खुले हैं, और क्या हर एक का कोई ओनर है?

अगर आप मुझसे अगले महीने अपने सिस्टम का आकलन करने को कहें, तो मैं यह क्रम अपनाऊँगा।

1. पता करें कि क्या इस्तेमाल हो रहा है। SAP Readiness Check चलाएँ और अपने कस्टम कोड का usage डेटा इकट्ठा करें। एक प्रोग्राम में smartShift के साथ विश्लेषण ने हमें 18,000 कस्टम ऑब्जेक्ट से 3,200 पर ला दिया, क्योंकि बाक़ी में से ज़्यादातर का इस्तेमाल ही नहीं होता था।
2. जो बचे, उसे लेवल A से D में बाँटें। कोड के लिए ABAP test cockpit का इस्तेमाल करें। अगर आप RISE पर हैं, तो वहाँ से आगे clean core dashboard इसे ट्रैक करता है।
3. हर ऑब्जेक्ट पर अलग से फ़ैसला करें। उसे हटाएँ, released इंटरफ़ेस पर ले जाएँ, BTP पर दोबारा बनाएँ या डॉक्यूमेंटेड कारण के साथ रखें। रोज़ चलने वाले कोड से शुरू करें, क्योंकि जो रिपोर्ट एक रीजनल टीम साल में दो बार इस्तेमाल करती है, वह इंतज़ार कर सकती है।
4. बिज़नेस को कमरे में लाएँ। जिस एक फ़ाइनेंस लीड के साथ मैंने काम किया, उन्हें अपना नया Fiori ऐप 45 मिनट के walkthrough के बाद ही समझ आया। उस एक सेशन ने UAT में दो हफ़्ते की आगे-पीछे की बातचीत बचा दी।
5. "हमारा प्रोसेस अलग है" को चुनौती दें। 2023 में एक यूरोपीय इंडस्ट्रियल कंपनी की सेल्स टीम के साथ वर्कशॉप में, "अनोखा" प्रोसेस 80% फ़ालतू पुराना एडमिन काम निकला। workarounds हटते ही standard SAP ने उनके ग्राहकों का अनुभव बेहतर कर दिया।
6. डेटा का काम जल्दी शुरू करें। 2024 में जिस GCC रिटेल क्लाइंट के साथ मैंने काम किया, उसके पास छाँटने के लिए 15,000 से ज़्यादा कस्टम फ़ील्ड थे। मेरे अनुभव में data migration, implementation के कुल प्रयास का 30 से 40% लेता है, और मेरी SAP implementation cost गाइड दिखाती है कि बजट में यह कहाँ आता है।
7. Go-live से पहले गवर्नेंस तय करें। ऊपर बताई गई design authority बनाइए और हर नए एक्सटेंशन के लिए उसे ही एकमात्र रास्ता बनाइए।

इस विषय पर लगभग हर बातचीत में तीन सवाल आते हैं।

क्या RISE with SAP में clean core अनिवार्य है?

सामान्य नियम के रूप में नहीं। Public Edition में सिस्टम इसे लागू करता है, जबकि Private Edition और on-premise में आप अब भी कोर को बदल सकते हैं।

वहाँ clean core गवर्नेंस का चुनाव है, जिसे SAP RISE methodology dashboard के ज़रिए ट्रैक करता है। अगर कोई SI आपसे कहे कि यह कॉन्ट्रैक्ट की शर्त है, तो उससे वह क्लॉज़ दिखाने को कहें।

ECC पर मेरे पास कितना समय है?

Enhancement packages 6 से 8 वाले SAP ERP 6.0 के लिए mainstream maintenance 31 दिसंबर 2027 को ख़त्म होता है। वैकल्पिक extended maintenance अतिरिक्त लागत पर 31 दिसंबर 2030 तक चलता है।

उसके बाद SAP ERP, private edition, transition option 2031 से 2033 तक कवर करता है। यह सिर्फ़ उन बड़े सिस्टम पर लागू होता है जो 2030 के अंत से पहले ही SAP HANA पर SAP ERP, private edition में जा चुके हों।

2033 को एक अपवाद वाला रास्ता मानिए, प्लानिंग की तारीख़ नहीं। मेरी ECC से S/4HANA migration गाइड रास्ते के विकल्पों को कवर करती है।

क्या AI के लिए clean core मायने रखता है?

हाँ। SAP standard पर बने रहने से AI और Joule बेहतर काम करते हैं, और भारी बदलाव वाले प्रोसेस में ही इन्हें अपनाना सबसे मुश्किल होता है।

SAP अपने AI फ़ीचर, Joule समेत, अपने standard प्रोसेस और डेटा मॉडल पर बनाता है। Joule for developers, released API पर ABAP Cloud कोड जनरेट करता है। cloud, AI और clean core एक साथ कैसे बैठते हैं, यह मैंने ERP modernisation में समझाया है।

जो टीमें clean core को छोड़ देती हैं, वे काम से बचती नहीं हैं। वे उसे टाल देती हैं, और वह अटके हुए अपग्रेड, regression testing के लंबे दौर और ऐसे कस्टम कोड के रूप में लौटता है जिसे कोई नहीं समझता।

S/4HANA या RISE कॉन्ट्रैक्ट पर साइन करने से पहले अपने SI से कहिए कि वह आपके मौजूदा कस्टम कोड को लेवल A से D में बाँटकर दिखाए। अगर वह ऐसा नहीं कर पाता, तो इससे आपको उसके अनुमान के बारे में कुछ पता चलता है। कॉल बुक करें और हम आपकी स्थिति पर साथ में नज़र डाल सकते हैं।

SAP में clean core क्या है?

clean core का मतलब है S/4HANA को SAP standard के क़रीब रखना और एक्सटेंशन सिर्फ़ उन इंटरफ़ेस के ज़रिए बनाना जिन्हें SAP ने released किया है और स्थिर रखने का वादा किया है। एक्सटेंशन या तो on-stack ABAP Cloud के साथ चलते हैं या side-by-side SAP BTP पर। मक़सद यह है कि अपग्रेड आपके कस्टम लॉजिक को न तोड़ें।

SAP clean core के पाँच सिद्धांत क्या हैं?

SAP के clean core के पाँच मार्गदर्शक सिद्धांत हैं: प्रोसेस, एक्सटेंसिबिलिटी, डेटा, इंटीग्रेशन और ऑपरेशंस। प्रोसेस standard के क़रीब रहते हैं, एक्सटेंशन released API इस्तेमाल करते हैं और डेटा एक गवर्नेंस मॉडल के तहत साफ़ रखा जाता है। इंटीग्रेशन सपोर्टेड टेक्नोलॉजी इस्तेमाल करते हैं, और ऑपरेशंस में वह गवर्नेंस, लोग और टूल आते हैं जो बाक़ी चारों को अपनी जगह बनाए रखते हैं।

SAP clean core लेवल A, B, C और D क्या हैं?

अगस्त 2025 से SAP एक्सटेंशन को चार लेवल में बाँटता है। लेवल A सिर्फ़ सार्वजनिक रूप से released, स्थिर इंटरफ़ेस इस्तेमाल करता है, लेवल B classic SAP API भी इस्तेमाल करता है, और लेवल C SAP के अंदरूनी ऑब्जेक्ट तक पहुँचता है। लेवल D में मॉडिफ़िकेशन, SAP टेबल में लिखना और implicit enhancements आते हैं, और इसमें अपग्रेड का जोखिम सबसे ज़्यादा है।

क्या RISE with SAP के लिए clean core अनिवार्य है?

सामान्य नियम के रूप में नहीं। S/4HANA Cloud Public Edition में सिर्फ़ ABAP Cloud और released इंटरफ़ेस की अनुमति है, इसलिए यह तकनीकी रूप से clean core लागू करता है। Private Edition में आप अब भी कोर को बदल सकते हैं, इसलिए वहाँ clean core गवर्नेंस का फ़ैसला है जिसे SAP, RISE with SAP Methodology dashboard के ज़रिए ट्रैक करता है।

ABAP Cloud क्या है?

ABAP Cloud, SAP का cloud-ready ABAP डेवलपमेंट मॉडल है। इसमें सिर्फ़ released ऑब्जेक्ट, public API और extension points की अनुमति है, जिससे कस्टम कोड अपग्रेड में स्थिर रहता है। यह रिलीज़ 2208 से नए ग्राहकों के लिए S/4HANA Cloud Public Edition में अनिवार्य है, और 2022 से Private Edition और on-premise में इसकी सिफ़ारिश की जाती है।

clean core को कैसे मापें?

कोड-स्तर की जाँच के लिए ABAP test cockpit का इस्तेमाल करें और कस्टम ऑब्जेक्ट को लेवल A से D में बाँटें। RISE ग्राहक SAP Cloud ALM में RISE with SAP Methodology dashboard, जिसे clean core dashboard भी कहते हैं, में adoption ट्रैक कर सकते हैं। मैं हर लेवल पर ऑब्जेक्ट की संख्या, लेवल D का रुझान और ओनर वाले खुले अपवादों की संख्या ट्रैक करता हूँ।

SAP clean core गवर्नेंस किसके हाथ में होना चाहिए?

हर clean core फ़ैसला बिज़नेस और IT से बनी एक design authority के हाथ में होना चाहिए। बिज़नेस प्रोसेस ओनर तय करते हैं कि ज़रूरत असली है या नहीं, और IT तय करता है कि उसे कैसे और किस लेवल पर बनाया जाए। हर अपवाद एक ओनर के साथ दर्ज होता है और हर अपग्रेड से पहले उसकी समीक्षा होती है।

SAP ECC का सपोर्ट कब ख़त्म होता है?

Enhancement packages 6 से 8 वाले SAP ERP 6.0 के लिए mainstream maintenance 31 दिसंबर 2027 को ख़त्म होता है, और वैकल्पिक extended maintenance अतिरिक्त लागत पर 31 दिसंबर 2030 तक चलता है। SAP ERP, private edition, transition option 2033 तक सिर्फ़ उन योग्य बड़े सिस्टम के लिए है जो 2030 के अंत से पहले SAP HANA पर SAP ERP, private edition में जा चुके हों।