SAP क्लीन कोर रणनीति: इसका मतलब क्या है और इसे कैसे लागू करें

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

मैंने ऐसी कंपनियाँ देखी हैं जिन्होंने S/4HANA प्रोग्राम शुरू होने से पहले क्लीन कोर के सिद्धांत लागू करके अपग्रेड की टाइमलाइन 40% घटा ली। एक कंज़्यूमर गुड्स कंपनी ने पुराने प्राइसिंग लॉजिक की जगह कोर के बाहर बना एक मॉड्यूलर Fiori ऐप लगा दिया, और उसके अपग्रेड से वह लॉजिक टूटना बंद हो गया।

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

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

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

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

SAP की अपनी गाइडेंस है कि हर यूज़ केस के हिसाब से चुनें, और BTP को पहले रखें। मेरे अनुभव में कोड कहाँ चलता है, यह उतना मायने नहीं रखता जितना यह कि ज़रूरत को कोड की ज़रूरत है भी या नहीं।

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

SAP क्लीन कोर को पाँच मार्गदर्शक सिद्धांतों के इर्द-गिर्द रखता है। इस लेख के पिछले संस्करण में अलग शीर्षक थे। ये वे हैं जो SAP इस्तेमाल करता है, और हर एक में मैं सबसे पहले क्या देखता हूँ:

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

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

अगस्त 2025 में SAP ने अपने पहले के तीन-स्तरीय एक्सटेंसिबिलिटी मॉडल की जगह क्लीन कोर लेवल की अवधारणा लागू की। हर एक्सटेंशन को इस आधार पर आँका जाता है कि वह कैसे बना है, कोर से कितना अलग है और उसे कितनी आसानी से अपग्रेड किया जा सकता है।

लेवल	SAP का विवरण	आपके अपग्रेड के लिए इसका मतलब
A	SAP Build से एक्सटेंड करें। सिर्फ़ सार्वजनिक रूप से रिलीज़ किए गए, स्थिर इंटरफ़ेस, on-stack ABAP Cloud के साथ या BTP पर side-by-side	सबसे कम जोखिम। SAP इन इंटरफ़ेस के पीछे स्टेबिलिटी कॉन्ट्रैक्ट रखता है
B	SAP के क्लासिक API और टेक्नोलॉजी भी इस्तेमाल करता है	आम तौर पर अपग्रेड में स्थिर, पर क्लाउड डेवलपमेंट मॉडल से बाहर
C	SAP के आंतरिक ऑब्जेक्ट्स तक पहुँचता है	आंशिक रूप से अनुरूप। हर अपग्रेड पर जाँच ज़रूरी, SAP आंतरिक ऑब्जेक्ट्स के लिए चेंजलॉग की योजना बना रहा है
D	अनुशंसित नहीं: मॉडिफ़िकेशन, SAP टेबल में लिखना, implicit एन्हांसमेंट, स्पष्ट रूप से अनुशंसित न किए गए ऑब्जेक्ट्स	वह तकनीकी कर्ज़ जिसे सबसे पहले हटाना है

यह पुरानी “क्लीन है या नहीं” वाली बहस से कहीं ज़्यादा काम का है। इससे आप हर ऑब्जेक्ट के लिए लक्ष्य तय कर सकते हैं। हर चीज़ का लेवल A तक पहुँचना ज़रूरी नहीं। अपग्रेड से पहले अपने लेवल D के ऑब्जेक्ट्स को B या C तक ले आना भी जोखिम में असली कमी है।

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

यह क्या इस्तेमाल करता हैलेवल Aसिर्फ़ सार्वजनिक रूप से रिलीज़ किए गए स्थिर इंटरफ़ेसलेवल BSAP के क्लासिक API भीलेवल CSAP के आंतरिक ऑब्जेक्ट्सलेवल Dमॉडिफ़िकेशन, SAP टेबल में लिखना, implicit एन्हांसमेंट

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

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

स्रोत: SAP क्लीन कोर लेवल अवधारणा, SAP News, अगस्त 2025

अगर आप अगले महीने मुझसे अपने सिस्टम का असेसमेंट करवाएँ, तो मैं इसी क्रम में चलूँगा।

1. पता कीजिए कि क्या इस्तेमाल होता है। SAP Readiness Check चलाइए, जो आपके मेंटेनेंस एग्रीमेंट के साथ आता है, और अपने कस्टम कोड का यूसेज डेटा जुटाइए। एक प्रोग्राम में smartShift से किए गए विश्लेषण ने हमें 18,000 कस्टम ऑब्जेक्ट्स से 3,200 पर पहुँचा दिया। बाक़ी में से ज़्यादातर बस इस्तेमाल ही नहीं होते थे।
2. जो बचे उसे लेवल A से D में बाँटिए। ABAP test cockpit कोड-स्तर की जाँच के लिए SAP का टूल है। RISE के तहत, RISE with SAP Methodology डैशबोर्ड क्लीन कोर अपनाने की रिपोर्ट देता है।
3. ऑब्जेक्ट-दर-ऑब्जेक्ट फ़ैसला कीजिए। उसे रिटायर कीजिए, रिलीज़ किए गए इंटरफ़ेस पर ले जाइए, BTP पर दोबारा बनाइए या दर्ज किए गए कारण के साथ रहने दीजिए। उस कोड से शुरू कीजिए जो हर दिन चलता है। एक क्षेत्रीय टीम की साल में दो बार इस्तेमाल होने वाली रिपोर्ट इंतज़ार कर सकती है।
4. बिज़नेस को कमरे में बिठाइए। जिस फ़ाइनेंस लीड के साथ मैंने काम किया, वे अपना नया Fiori ऐप तभी समझ पाए जब 45 मिनट का वॉकथ्रू हुआ। उस सेशन ने UAT में दो हफ़्ते की आपसी खींचतान बचा ली।
5. “हमारा प्रोसेस अलग है” को चुनौती दीजिए। एक सेल्स टीम की वर्कशॉप में “अनोखा” प्रोसेस 80% फ़ालतू पुराने एडमिन काम का निकला। वर्कअराउंड हटते ही स्टैंडर्ड SAP ने उनका कस्टमर अनुभव बेहतर कर दिया।
6. डेटा का काम जल्दी शुरू कीजिए। एक रिटेल क्लाइंट के पास छाँटने के लिए 15,000 से ज़्यादा कस्टम फ़ील्ड थे। मेरे अनुभव में डेटा माइग्रेशन इम्प्लीमेंटेशन के 30 से 40% प्रयास में खप जाता है, और ज़्यादातर प्लान इसी हिस्से को कम आँकते हैं। क्यों, यह मैंने SAP डेटा माइग्रेशन क्यों फ़ेल होता है में बताया है।
7. go-live से पहले गवर्नेंस तय कीजिए। हर नए एक्सटेंशन की समीक्षा डिज़ाइन अथॉरिटी करे। पहले मेरा डिफ़ॉल्ट सवाल होता था “यह BTP पर क्यों नहीं रह सकता?” आज मैं पूछूँगा “यह लेवल A क्यों नहीं हो सकता, और नहीं हो सकता तो हम कौन-सा लेवल स्वीकार कर रहे हैं और क्यों?”

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

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

क्या RISE with SAP के तहत क्लीन कोर अनिवार्य है? सब पर लागू होने वाले नियम के रूप में नहीं। S/4HANA Cloud Public Edition में आप सिर्फ़ रिलीज़ किए गए इंटरफ़ेस से एक्सटेंड कर सकते हैं, इसलिए सिस्टम खुद इसे लागू करता है। Private Edition और on-premise में आप अब भी कोर को मॉडिफ़ाई कर सकते हैं। वहाँ क्लीन कोर गवर्नेंस का चुनाव है, और SAP इसे RISE मेथडोलॉजी डैशबोर्ड से ट्रैक करता है। अगर कोई SI कहे कि यह कॉन्ट्रैक्ट की शर्त है, तो उससे वह क्लॉज़ दिखाने को कहिए।

ECC पर मेरे पास कितना समय है? SAP ERP 6.0 के enhancement package 6 से 8 के लिए मेनस्ट्रीम मेंटेनेंस 31 दिसंबर 2027 को ख़त्म होती है। वैकल्पिक एक्सटेंडेड मेंटेनेंस अतिरिक्त लागत पर 31 दिसंबर 2030 तक चलती है, और SAP चाहता है कि ग्राहक उसे Q3 2027 तक ऑर्डर कर दें। पहले के enhancement package की मेनस्ट्रीम मेंटेनेंस 2025 के अंत में ही ख़त्म हो गई थी। 2030 के बाद SAP ERP, private edition, transition option 2031 से 2033 को कवर करता है। यह सिर्फ़ उन बड़े सिस्टम पर लागू होता है जो 2030 के अंत से पहले SAP HANA पर SAP ERP, private edition में जा चुके हों, और सिर्फ़ SAP के max success plan के साथ। 2033 को अपवाद वाला रास्ता मानिए, प्लानिंग की तारीख़ नहीं। रास्ते के विकल्प मेरी ECC से S/4HANA माइग्रेशन गाइड में हैं।

क्या क्लीन कोर AI के लिए मायने रखता है? SAP अपने AI फ़ीचर, Joule समेत, अपने स्टैंडर्ड प्रोसेस और डेटा मॉडल के ऊपर बनाता है। Joule for developers रिलीज़ किए गए API के हिसाब से ABAP Cloud कोड बनाता है। मेरी कामकाजी राय सीधी है: आपके प्रोसेस और डेटा जितने स्टैंडर्ड के क़रीब होंगे, उन फ़ीचर्स को काम का बनाने के लिए उतना ही कम बदलाव करना पड़ेगा। भारी मॉडिफ़ाई किए गए प्रोसेस में AI फ़ीचर अपनाना सबसे मुश्किल होता है।

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

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

SAP क्लीन कोर क्या है?

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

SAP क्लीन कोर के पाँच आयाम क्या हैं?

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

SAP क्लीन कोर के लेवल A, B, C और D क्या हैं?

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

क्या RISE with SAP के साथ क्लीन कोर अनिवार्य है?

सब पर लागू होने वाले नियम के रूप में नहीं। S/4HANA Cloud Public Edition सिर्फ़ रिलीज़ किए गए इंटरफ़ेस से एक्सटेंशन की इजाज़त देता है, इसलिए वह क्लीन कोर को तकनीकी रूप से लागू करता है। Private Edition में आप अब भी कोर को मॉडिफ़ाई कर सकते हैं, इसलिए क्लीन कोर गवर्नेंस का फ़ैसला है। SAP क्लीन कोर अपनाने की रिपोर्ट RISE with SAP Methodology डैशबोर्ड से देता है।

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

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

मैं अपने SAP सिस्टम की क्लीन कोर तैयारी का असेसमेंट कैसे करूँ?

SAP Readiness Check और अपने कस्टम कोड के यूसेज डेटा से शुरू कीजिए। जो अब भी इस्तेमाल होता है उसे लेवल A से D में बाँटिए, कोड-स्तर की जाँच के लिए ABAP test cockpit का इस्तेमाल करते हुए। फिर हर ऑब्जेक्ट के लिए तय कीजिए कि उसे रिटायर करना है, रिलीज़ किए गए इंटरफ़ेस पर ले जाना है, SAP BTP पर दोबारा बनाना है या दर्ज किए गए कारण के साथ रखना है। प्रोसेस और डेटा की समीक्षा साथ-साथ कीजिए, क्योंकि कोड के होने की वजह अक्सर वही समझाते हैं।

क्लीन कोर रणनीति में SAP BTP की भूमिका क्या है?

SAP BTP वह जगह है जहाँ side-by-side एक्सटेंशन चलते हैं। BTP पर एप्लिकेशन API और इवेंट के ज़रिए S/4HANA से जुड़ते हैं, इसलिए कोर को छुआ नहीं जाता। SAP BTP-first तरीक़े की सलाह देता है, और जहाँ लॉजिक को डेटा या ट्रांज़ैक्शन के क़रीब रहना हो वहाँ on-stack ABAP Cloud एक्सटेंशन की।