SAP नेगोशिएशन एडवाइज़र: आप जो चुकाते हैं उसे कैसे घटाएँ

SAP नेगोशिएशन एडवाइज़र आपके लाइसेंस, उपयोग और कॉन्ट्रैक्ट की शर्तों की समीक्षा करके पता लगाता है कि आप कहाँ ज़्यादा चुका रहे हैं और कहाँ जोखिम में हैं, फिर उसी सबूत के सहारे सौदा बदलवाता है। बचत ज़्यादातर सुधारों से आती है: ग़लत लाइसेंस टाइप पर रखे यूज़र, ऐसे मॉड्यूल जिन्हें कोई इस्तेमाल नहीं करता, इन्फ्रास्ट्रक्चर चार्ज जिन्हें किसी ने बेंचमार्क नहीं किया, सर्विस बंडल जिनकी किसी को ज़रूरत नहीं थी। यह गाइड उन CIO, CFO और प्रोक्योरमेंट लीड के लिए है जिनके सामने SAP का रिन्यूअल, ऑडिट या RISE या GROW का प्रस्ताव है। इसमें बताया गया है कि एडवाइज़र की स्वतंत्रता कैसे जाँचें, किन बातों पर सवाल उठाएँ, RISE और GROW की रणनीतियाँ क्या हैं, और रिन्यूअल की टाइमलाइन कैसी हो। कॉन्ट्रैक्ट की तारीख़ से छह से नौ महीने पहले शुरू कीजिए, और सबसे पहले एडवाइज़र के प्रोत्साहनों की जाँच कीजिए।

एक रिटेल क्लाइंट के पास 500 Professional सीट थीं, जबकि उपयोग के डेटा ने दिखाया कि 200 Limited सीट काफ़ी थीं। दायरा सुधारने से हर साल $1.2 मिलियन बचे। एक मैन्युफ़ैक्चरिंग क्लाइंट लगभग ऐसे MES बंडल के पैसे चुका ही रहा था जिसे वह कभी लागू करने वाला नहीं था, और उसने पहले साल के खर्च से $450K घटा दिए। एक GROW क्लाइंट ने बंडल के बेकार हिस्से हटाकर हर साल $280K से ज़्यादा घटाए।

इनमें से कोई भी ख़ास सौदा नहीं था। ये उन कॉन्ट्रैक्ट के सुधार थे जिन पर कभी उस रूप में दस्तख़त होने ही नहीं चाहिए थे।

SAP कॉन्ट्रैक्ट में ऐसी लागतें छिपी होती हैं जिन्हें ज़्यादातर लीगल टीमें नहीं पकड़तीं और जिन्हें उजागर करने का ज़्यादातर सिस्टम इंटीग्रेटर के पास कोई प्रोत्साहन नहीं होता। इंटीग्रेटर इम्प्लीमेंटेशन के घंटों से कमाते हैं। SAP के अकाउंट एग्ज़िक्यूटिव कॉन्ट्रैक्ट की वैल्यू से कमाते हैं। आपके कम चुकाने में किसी का फ़ायदा नहीं है।

कोई भी आपको SAP कॉन्ट्रैक्ट पर सलाह दे, उससे पहले तीन बातें पक्की कीजिए:

1. SAP पार्टनर से कोई आय या इम्प्लीमेंटेशन कमीशन नहीं
2. किसी भी SAP प्रोडक्ट पर रीसेलर संबंध नहीं
3. फ़ीस आपके नतीजे से जुड़ी हो, कॉन्ट्रैक्ट पर दस्तख़त होने से नहीं

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

तालिका दिखाती है कि लागत आम तौर पर कहाँ छिपती है और उसका क्या करना चाहिए।

लागत का कारण	यह कहाँ छिपता है	क्या करें
यूज़र टाइप का ग़लत असाइनमेंट	Professional लाइसेंस जॉब टाइटल के आधार पर दिए गए, सिस्टम की गतिविधि के आधार पर नहीं	क्लासिफ़िकेशन रिपोर्ट चलाइए; ट्रांज़ैक्शन को लाइसेंस टाइप से मैप कीजिए
BOM में शेल्फ़वेयर	लाइसेंस वाले मॉड्यूल जिनका उपयोग शून्य या लगभग शून्य है	उपयोग का ऑडिट कीजिए; रिन्यूअल पर हटाइए या टालिए
डिजिटल एक्सेस	थर्ड-पार्टी सिस्टम जो SAP डॉक्यूमेंट बनाते हैं	इंटीग्रेशन मैप कीजिए; कॉन्ट्रैक्ट में डॉक्यूमेंट वॉल्यूम तय कीजिए
कीमत में बढ़ोतरी	बिना सीमा के रिन्यूअल पर बढ़ोतरी	सालाना बढ़ोतरी पर सीमा लगाइए या पूरी अवधि के लिए रेट लॉक कीजिए
समाप्त हो जाने वाली बंडल सर्विसेज़	इम्प्लीमेंटेशन के घंटे, BTP क्रेडिट, ट्रेनिंग बजट	दस्तख़त के समय ही उनके इस्तेमाल का शेड्यूल बनाइए
इन्फ्रास्ट्रक्चर चार्ज (RISE)	होस्टिंग की लागत जिसकी बाज़ार दरों से तुलना नहीं हुई	तुलनीय क्लाउड वर्कलोड से बेंचमार्क कीजिए
ज़रूरत से ज़्यादा बंडल सपोर्ट	प्रीमियम टियर जो ऐसी सर्विसेज़ कवर करते हैं जिन्हें आप कभी ट्रिगर नहीं करते	अपनी इंसिडेंट हिस्ट्री के सामने लाइन-आइटम समीक्षा
बेकार पड़े on-premise लाइसेंस	उन मॉड्यूल का पूरा मेंटेनेंस जिन्हें आपने इस्तेमाल करना बंद कर दिया	पात्र होने पर बाँटने या ख़त्म करने के लिए SAP की 2026 की प्रतिबद्धताओं का उपयोग कीजिए

आख़िरी पंक्ति नई है। 10 जुलाई 2026 से, यूरोपीय आयोग के सामने SAP की मेंटेनेंस प्रतिबद्धताएँ on-premise ग्राहकों को लैंडस्केप बाँटने, हर इंस्टॉलेशन के लिए अलग सपोर्ट चुनने और तय मामलों में बेकार पड़े लाइसेंस बिना री-डिस्काउंटिंग के ख़त्म करने देती हैं। मेरी SAP लाइसेंस नेगोशिएशन गाइड इसका ब्योरा समझाती है।

बिल ऑफ़ मटीरियल्स (BOM) में हर लाइसेंस वाला मॉड्यूल और सर्विस दर्ज होती है। ज़्यादातर संगठन इसे मूल बिक्री प्रक्रिया से विरासत में पा लेते हैं और कभी इस पर सवाल नहीं उठाते।

हर लाइन पर सवाल उठाइए। पूछिए कि हर मॉड्यूल को कितने यूज़र सक्रिय रूप से इस्तेमाल करते हैं, और अगर वह चला जाए तो ऑपरेशन पर क्या असर होगा। हैरानी की बात है कि कई लाइनें इस सवाल से यह जवाब लेकर बच निकलती हैं कि “हमें असल में पक्का पता नहीं कि हमें इसकी ज़रूरत है।” मैंने एक मैन्युफ़ैक्चरर के साथ काम किया जिसने फ़ंक्शनल अलाइनमेंट सेशन के बाद 15% मॉड्यूल हटा दिए, और क्या रहेगा यह तय करने के लिए असली उपयोग के पैटर्न इस्तेमाल किए।

बंडल के जाल पर नज़र रखिए। बंडल यूनिट प्राइस घटाते हैं, पर जब उनमें ऐसे हिस्से शामिल हों जिन्हें आप दो-तीन साल तक इस्तेमाल नहीं करेंगे, तो कुल खर्च बढ़ा देते हैं। GROW पैकेज में अक्सर एनालिटिक्स टूल या लाइन-ऑफ़-बिज़नेस एप्लिकेशन होते हैं जो पहली तैनाती में नहीं हैं।

रिन्यूअल से पहले इंटीग्रेशन मैप कीजिए। SAP डॉक्यूमेंट बनाने वाला हर सिस्टम (CRM, MES, मोबाइल ऐप, मिडलवेयर) डिजिटल एक्सेस में गिना जा सकता है। SAP आपके इंटीग्रेशन की सूची आपके लिए नहीं बनाएगा। पहले अपना नक़्शा ख़ुद बनाइए।

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

RISE with SAP

1. लागत का ढाँचा अलग-अलग कीजिए। RISE सॉफ़्टवेयर, इन्फ्रास्ट्रक्चर, टेक्निकल ऑपरेशन और कुछ सर्विसेज़ को एक सब्सक्रिप्शन में बंडल करता है, जिसकी कीमत Full Use Equivalents (FUE) में तय होती है। SAP एक ही संख्या पेश करता है, इसलिए ब्रेकडाउन माँगिए। सबसे ज़्यादा चुनौती देने लायक हिस्सा इन्फ्रास्ट्रक्चर है। मेरे एक क्लाइंट ने सिर्फ़ इन्फ्रास्ट्रक्चर चार्ज को चुनौती देकर और अपने असली क्लाउड उपयोग से मिलान करके लागत 22% घटा दी। हमने उसके सौदे की तुलना उसके उद्योग के दूसरे सौदों से की और ज़ोर से पीछे धकेला।
2. अपनी क्लीन कोर प्रतिबद्धता का इस्तेमाल कीजिए। SAP चाहता है कि ग्राहक क्लीन कोर पर रहें। अगर आप न्यूनतम कस्टमाइज़ेशन का वादा करते हैं, तो इम्प्लीमेंटेशन के दायरे, BTP खपत के अनुमान और सपोर्ट टियर पर आपकी स्थिति विश्वसनीय बनती है। private cloud पर क्लीन कोर ऐसा चुनाव है जिसे SAP प्रोत्साहित करता है, कॉन्ट्रैक्ट का नियम नहीं, और ठीक इसी वजह से आपकी प्रतिबद्धता की क़ीमत है।
3. बढ़ोतरी को कैलेंडर से नहीं, उपयोग से जोड़िए। SAP आम तौर पर अपनाने की स्थिति से बेपरवाह होकर कॉन्ट्रैक्ट के वर्षों में कीमत की सीढ़ियाँ बना देता है। ऐसे ट्रिगर पर मोलभाव कीजिए जो सक्रिय यूज़र, FUE खपत या पूरे हुए रोलआउट से जुड़े हों। अगर आपका रोलआउट खिसकता है, तो कीमत फिर भी तय समय पर नहीं बढ़नी चाहिए।
4. डिजिटल एक्सेस को परिभाषित कीजिए। RISE डिजिटल एक्सेस का जोखिम ख़त्म नहीं करता। जो इंटीग्रेशन परिदृश्य कवर हैं, उनके वॉल्यूम और मापने का तरीक़ा नाम लेकर लिखिए। “बाद में तय होगा” जैसी धाराएँ ऑडिट का जोखिम पैदा करती हैं।
5. एग्ज़िट और रैंप-डाउन की शर्तें बनाइए। दस्तख़त से पहले तय कर लीजिए कि डेटा किस फ़ॉर्मेट में लौटेगा, समाप्ति के बाद एक्सेस के चार्ज क्या होंगे और आपके BTP टेनेंट के कॉन्फ़िगरेशन का क्या होगा।

GROW with SAP

1. पैकेज के दायरे की चीर-फाड़ कीजिए। GROW पैकेज स्टैंडर्ड प्रक्रियाओं के लिए पहले से कॉन्फ़िगर होते हैं। आपकी तैनाती से बाहर के मॉड्यूल कॉन्ट्रैक्ट की वैल्यू बढ़ाते हैं, पर डिलीवरी में कुछ नहीं जोड़ते। ऊपर वाले GROW क्लाइंट ने पहले असली उपयोग के परिदृश्य मैप किए और फिर हर साल $280K से ज़्यादा घटाए।
2. विचलनों का गवर्नेंस कीजिए। GROW public cloud पर चलता है, जहाँ कोर में कस्टम कोड संभव नहीं और एक्सटेंशन SAP BTP से होकर जाते हैं। तय कीजिए कि क्या विचलन माना जाएगा, उसे कौन मंज़ूर करेगा और एक्सटेंशन के काम की कीमत कैसे तय होगी।
3. डेटा रेज़िडेंसी पक्की कीजिए। GROW हाइपरस्केलर इन्फ्रास्ट्रक्चर पर मल्टी-टेनेंट चलता है। रेज़िडेंसी का रीजन तय कीजिए, सीमा-पार रूटिंग पर रोक लगाइए और बैकअप के गवर्नेंस को परिभाषित कीजिए। स्टैंडर्ड शर्तें आपकी ज़रूरतें कवर न करें, ऐसा हो सकता है।
4. दस्तख़त से पहले रिन्यूअल की कीमत पर सीमा लगाइए। जब तक आप बहु-वर्षीय कीमत लॉक न करें, सालाना 5 से 7 प्रतिशत की बढ़ोतरी आम है। मेरे एक क्लाइंट की क्लाउड फ़ीस कमज़ोर बढ़ोतरी-धाराओं की वजह से चार साल में दोगुनी हो गई। हमने रिन्यूअल पर असली उपयोग से जुड़ी सीमित बढ़ोतरी के साथ इसे ठीक किया।
5. BOM को लीवर की तरह इस्तेमाल कीजिए। अवधि के लिए आपके तैनाती रोडमैप से बाहर की हर लाइन पर मोलभाव हो सकता है। उसे हटाइए, और अगर SAP डिस्काउंट पर अड़े तो उसे रियायत के तौर पर बचाकर रखिए।

एक मैन्युफ़ैक्चरिंग क्लाइंट तीन साल के ऐसे समझौते में बँध गया जिसमें बंडल किए गए सर्विस लेवल थे, जिनकी उसे ज़रूरत नहीं थी। किसी के समझने से पहले $400,000 फुँक गए। पूरी तरह टाला जा सकता था।

हर सर्विसेज़ कॉन्ट्रैक्ट में चार चीज़ें होनी चाहिए:

1. स्किल बदलने की मंज़ूरी। वेंडर go-live के बाद वरिष्ठ लोगों को हटा लेते हैं। प्रमुख टीम सदस्यों को बदलने से पहले अपनी मंज़ूरी अनिवार्य कीजिए।
2. रैंप-डाउन के अधिकार। अगर go-live खिसकता है या आप रोलआउट को चरणों में बाँटते हैं, तो आपको बिना जुर्माने के कॉन्ट्रैक्ट किए गए घंटे घटाने का अधिकार चाहिए।
3. नॉलेज ट्रांसफ़र एक डिलीवरेबल के रूप में। ट्रेनिंग नॉलेज ट्रांसफ़र नहीं है। रनबुक, शैडोइंग की अवधि और आपके टीम लीड का साइन-ऑफ़ तय कीजिए।
4. परिणामों वाली परफ़ॉर्मेंस की शर्तें। अकेला रिस्पॉन्स टाइम बहुत कम मायने रखता है। समाधान के समय तय कीजिए और उनसे सर्विस क्रेडिट जोड़िए।

हर प्राइसिंग मॉडल के अपने जाल हैं।

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

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

मैंने एक ऐसे क्लाइंट के साथ काम किया जो मानता था कि उसका SAP सौदा ठीक है, जब तक हमने बेंचमार्किंग रिपोर्ट नहीं निकाली। वह मिलती-जुलती कंपनियों से 30% ज़्यादा चुका रहा था। हम वह डेटा लेकर SAP के पास लौटे और दोबारा मोलभाव किया, और क्लाइंट कहीं बेहतर सौदे के साथ वहाँ से निकला।

बेंचमार्क “यह हमारी स्टैंडर्ड कीमत है” वाली दलील बंद कर देते हैं। वे नतीजे की गारंटी नहीं देते, पर बातचीत बदल देते हैं।

1. नौ महीने पहले: उपयोग, क्लासिफ़िकेशन और इंटीग्रेशन का डेटा निकालिए; BOM की समीक्षा शुरू कीजिए
2. सात महीने पहले: बेंचमार्क करवाइए; SAP की 2026 की मेंटेनेंस प्रतिबद्धताओं के तहत पात्रता जाँचिए
3. छह महीने पहले: अपनी लक्षित स्थिति और पीछे हटने के बिंदु अंदर ही तय कीजिए; CFO को ब्रीफ़ कीजिए
4. चार से पाँच महीने पहले: SAP के साथ बातचीत सबूतों के साथ शुरू कीजिए, राय के साथ नहीं
5. तीन महीने पहले: शर्तों पर मोलभाव कीजिए (सीमाएँ, स्केलिंग, डिजिटल एक्सेस, एग्ज़िट, सर्विसेज़)
6. दस्तख़त से पहले: तय हुई हर बात के सामने अंतिम ऑर्डर फ़ॉर्म की लाइन-आइटम समीक्षा

1. 9उपयोग और इंटीग्रेशन का डेटा निकालिएक्लासिफ़िकेशन रिपोर्ट, BOM की समीक्षा
2. 7बेंचमार्क करवाइए2026 की मेंटेनेंस प्रतिबद्धताएँ जाँचिए
3. 6लक्ष्य और पीछे हटने के बिंदु तय कीजिएCFO को ब्रीफ़ कीजिए
4. 4-5SAP के साथ बातचीत शुरू कीजिएसबूत, राय नहीं
5. 3शर्तों पर मोलभाव कीजिएसीमाएँ, स्केलिंग, डिजिटल एक्सेस, एग्ज़िट। दस्तख़त से पहले लाइन-आइटम समीक्षा

90 दिन पर शुरू करना देर है। सबूत जुटाने में महीने लगते हैं। कॉन्ट्रैक्ट की व्यापक तस्वीर के लिए मेरी CFO के लिए ERP कॉन्ट्रैक्ट नेगोशिएशन गाइड देखिए।

SAP नेगोशिएशन एडवाइज़र असल में क्या करता है?

वह लाइसेंस के उपयोग का विश्लेषण करके ग़लत असाइन किए यूज़र टाइप ढूँढता है और BOM में बेकार पड़े मॉड्यूल का ऑडिट करता है। वह डिजिटल एक्सेस के जोखिम का नक़्शा बनाता है, आपकी कीमतों को तुलनीय संगठनों से बेंचमार्क करता है, और ऐसी शर्तें गढ़ता है जो रिन्यूअल और ऑडिट में आपकी रक्षा करें। सामान्य प्रोक्योरमेंट कंसल्टेंट से फ़र्क़ SAP की ख़ास जानकारी का है। सिस्टम इंटीग्रेटर से फ़र्क़ प्रोत्साहन का है: इंटीग्रेटर घंटों से कमाता है, लागत पर केंद्रित एडवाइज़र तब कमाता है जब आपका बिल घटता है।

कंपनियाँ SAP लाइसेंस पर ज़्यादा क्यों चुकाती हैं?

तीन कारण। Professional लाइसेंस सिस्टम की गतिविधि के बजाय जॉब टाइटल के आधार पर दिए जाते हैं। BOM वह दर्शाता है जो SAP ने बेचा, वह नहीं जो बिज़नेस इस्तेमाल करता है, और मॉड्यूल हटाने का सवाल किसी की ज़िम्मेदारी नहीं होता। और ज़्यादातर संगठनों को पता नहीं होता कि उनके कौन से इंटीग्रेशन डिजिटल एक्सेस में गिने जाते हैं। इनमें से हर एक हर रिन्यूअल पर तब तक बढ़ता जाता है जब तक कोई जाँचता नहीं।

RISE with SAP के सबसे अहम नेगोशिएशन बिंदु कौन से हैं?

पाँच क्षेत्र संख्या को हिलाते हैं। इन्फ्रास्ट्रक्चर चार्ज, जिन्हें बाज़ार दरों से बेंचमार्क करना चाहिए। समाप्ति-तारीख़ वाले बंडल क्रेडिट और सर्विसेज़, जिनका शेड्यूल दस्तख़त के समय बनना चाहिए। सालाना कीमत की बढ़ोतरी, जिस पर सीमा लगनी चाहिए। डिजिटल एक्सेस का दायरा, जिसे भविष्य के ऑडिट पर छोड़ने के बजाय परिभाषित करना चाहिए। और एग्ज़िट की शर्तें, जो डेटा फ़ॉर्मेट, समाप्ति के बाद के एक्सेस और BTP टेनेंट की पोर्टेबिलिटी को कवर करें।

BOM विश्लेषण SAP कॉन्ट्रैक्ट की लागत कैसे घटाता है?

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

SAP सर्विस एग्रीमेंट में ख़तरे की घंटियाँ कौन सी हैं?

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

SAP लाइसेंसिंग एग्रीमेंट की समीक्षा कितनी बार होनी चाहिए?

कम से कम साल में एक बार और हर रिन्यूअल से पहले। सालाना समीक्षा यूज़र के खिसकाव और नए इंटीग्रेशन को पकड़ती है; 90 दिन की लॉगिन रिपोर्ट इसका ज़्यादातर हिस्सा ढूँढ लेती है। रिन्यूअल की समीक्षा समाप्ति से छह से नौ महीने पहले शुरू होनी चाहिए। अतिरिक्त समीक्षा तब कीजिए जब हेडकाउंट में बड़ा बदलाव हो, कोई बड़ा इंटीग्रेशन जुड़े या हटे, डिप्लॉयमेंट मॉडल बदले, या SAP ऑडिट की घोषणा करे।