SAP क्वालिटी गेट्स: इन्हें कैसे सेट करें और ये कहाँ फेल होते हैं

क्वालिटी गेट प्रोजेक्ट के चरणों के बीच का एक औपचारिक चेकपॉइंट है। आगे बढ़ने से पहले टीम को दिखाना होता है कि तय किए गए क्राइटेरिया पूरे हुए हैं। पास हुए, तो आगे बढ़ें। फेल हुए, तो पहले समस्याएँ ठीक करें। SAP प्रोग्राम में गेट SAP Activate के चरण-परिवर्तन पर होते हैं, और हर गेट का एक नामित ओनर होता है जिसके पास “अभी तैयार नहीं” कहने का अधिकार है।

सिंगापुर की एक बड़ी कंज़्यूमर गुड्स कंपनी SAP को ग्लोबली रोल आउट कर रही थी। डेडलाइन पकड़ने के लिए टीम ने टेस्टिंग जल्दबाज़ी में निपटा दी। यह पूरा हादसा मैंने अपनी आँखों से देखा। यूज़र टेस्टिंग मुश्किल से हुई, फिर भी एक्ज़ीक्यूटिव लॉन्च पर अड़े रहे। कुछ ही दिनों में समस्याएँ सामने आ गईं: छूटे हुए सेटअप, टूटे हुए वर्कफ़्लो, पूरी तरह गलत डेटा। go-live के बाद हफ़्तों चली अफ़रा-तफ़री उन समस्याओं की वजह से थी जो go-live से पहले ही दिख रही थीं। किसी ने रुककर जाँच नहीं की।

मैं क्वालिटी गेट रिव्यू कभी नहीं छोड़ता। कोई शॉर्टकट नहीं, कोई रबर स्टैंप नहीं। शुरुआत में इसमें ज़्यादा समय लगता है, पर बाद में महीनों की सफ़ाई बच जाती है।

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

इस अधिकार के बिना रिव्यू रबर स्टैंप बन जाते हैं। और रबर-स्टैंप गेट न होने से भी बदतर हैं, क्योंकि वे झूठा भरोसा पैदा करते हैं। एक रिटेल क्लाइंट के “रिव्यू” लगभग रबर स्टैंप ही थे। छह महीने बाद वे शेड्यूल से बुरी तरह पीछे थे, क्योंकि जिन समस्याओं को उन रिव्यू में पकड़ा जाना चाहिए था, उन्हें किसी ने सुलझाया ही नहीं था।

SAP Activate के छह चरण हैं: Discover, Prepare, Explore, Realize, Deploy और Run। हर चरण-परिवर्तन एक स्वाभाविक गेट है। हर गेट पर मैं यह जाँच देखना चाहता हूँ।

चरण का गेट	क्वालिटी फ़ोकस	देखने लायक सबूत	कब पास होगा
Discover	बिज़नेस केस, एक्ज़ीक्यूटिव सहमति	बिज़नेस केस, हाई-लेवल रोडमैप	बिज़नेस केस पर साइन हो चुका है, स्पॉन्सर प्रतिबद्ध है
Prepare	गवर्नेंस, टीम, जोखिम	चार्टर, गवर्नेंस मॉडल, रिस्क रजिस्टर	चार्टर मंज़ूर है, रिस्क ओनर तय हैं, टीम ऑनबोर्ड हो चुकी है
Explore	Fit-to-Standard, डिज़ाइन, इंटीग्रेशन अप्रोच	Fit-gap फ़ैसले, प्रोसेस डिज़ाइन, इंटीग्रेशन आर्किटेक्चर	प्रोसेस ओनर ने साइन-ऑफ किया है; हर गैप पर फ़ैसला हो चुका है
Realize	कॉन्फ़िगरेशन, इंटीग्रेशन टेस्टिंग	टेस्ट एक्ज़ीक्यूशन रिपोर्ट, डिफ़ेक्ट लॉग	टेस्ट थ्रेशोल्ड पूरे हैं, क्रिटिकल डिफ़ेक्ट बंद हैं
Deploy	डेटा, ट्रेनिंग, कटओवर की तैयारी	माइग्रेशन रिकंसिलिएशन, ट्रेनिंग रिकॉर्ड, कटओवर प्लान	ड्रेस रिहर्सल हो चुका है, रोलबैक प्लान पर सहमति है
Run	स्टेबिलाइज़ेशन और हैंडओवर	इंसीडेंट लॉग, परफ़ॉर्मेंस रिपोर्ट	इंसीडेंट तय सीमा के भीतर हैं, सपोर्ट हैंडओवर पर साइन हो चुका है

व्यवहार में Explore, Realize और Deploy में सबसे ज़्यादा जोखिम होता है। इन तीनों में से किसी गेट से बिना पकड़ी निकल गई समस्या go-live के बाद सामने आए, तो सबसे महँगी पड़ती है।

1. 01Discoverबिज़नेस केस पर साइन, स्पॉन्सर प्रतिबद्ध
2. 02Prepareचार्टर मंज़ूर, रिस्क ओनर तय
3. 03Exploreहर गैप पर फ़ैसला
4. 04Realizeटेस्ट थ्रेशोल्ड पूरे, क्रिटिकल डिफ़ेक्ट बंद
5. 05Deployड्रेस रिहर्सल पूरा, रोलबैक पर सहमति
6. 06Runइंसीडेंट सीमा में, हैंडओवर पर साइन

हर गेट पर एक ओनर का साइन, जिसके पास “अभी तैयार नहीं” कहने का अधिकार हो

कॉन्फ़िगरेशन शुरू होने से पहले हर गेट के एंट्री और एग्ज़िट क्राइटेरिया प्रोजेक्ट चार्टर में लिख दें। डेडलाइन के दबाव में लिखे गए क्राइटेरिया वह बताते हैं जो टीम फ़िलहाल दिखा सकती है, वह नहीं जो प्रोजेक्ट को चाहिए। एक क्लाइंट ने “समय बचाने” के लिए चरणों को मिलाने की कोशिश की। नतीजा यह हुआ कि हफ़्तों का काम दोबारा करना पड़ा।

ऐसे क्राइटेरिया जिनका जवाब हाँ या ना में आए

“टेस्टिंग पूरी” कोई क्राइटेरिया नहीं है। इससे बहस शुरू होती है। एक रिटेल क्लाइंट के गेट में बस लिखा था “UAT पूरा हुआ”। आधी टीम ने इसका मतलब समझा कि सारे टेस्ट चल चुके हैं। बाकी आधी ने समझा कि सारे डिफ़ेक्ट ठीक हो चुके हैं।

“95% टेस्ट केस एक्ज़ीक्यूट हुए, सभी प्रायोरिटी 1 डिफ़ेक्ट सुलझ गए, और पाँच दिन से पुराना कोई प्रायोरिटी 2 डिफ़ेक्ट खुला नहीं है” क्राइटेरिया है। इससे जवाब निकलता है।

एक मैन्युफ़ैक्चरिंग क्लाइंट के गेट इसलिए फेल हुए कि क्राइटेरिया बहुत अस्पष्ट थे। किसी को पता ही नहीं था कि वे वाकई पास हुए या नहीं। जब क्राइटेरिया मापने योग्य थ्रेशोल्ड में बदले, तो चरण-परिवर्तन पर होने वाली बहसें बंद हो गईं।

देरी करने का अधिकार रखने वाला एक ओनर

हर गेट का एक नामित ओनर होना चाहिए जो प्रोजेक्ट में देरी कर सके। एक व्यक्ति, कमेटी नहीं। मैंने एक प्रोजेक्ट को इसलिए डूबते देखा कि टीम के तैयार न होने पर भी अगला चरण रोकने की ताकत किसी के पास नहीं थी।

उलटा भी काम करता है। एक रिटेल क्लाइंट ने एक सीनियर डायरेक्टर को गेट ओनर बनाया। जब वे कहते थे “तैयार नहीं”, तो सब सुनते थे। यह अधिकार चार्टर में लिखें।

दबाव आने से पहले एक्ज़ीक्यूटिव का समर्थन

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

सिस्टम ऑफ़ रिकॉर्ड से आने वाला सबूत

गेट के फ़ैसलों को सबूत चाहिए: टेस्ट एक्ज़ीक्यूशन रिपोर्ट, डिफ़ेक्ट लॉग, प्रोसेस साइन-ऑफ, माइग्रेशन रिकंसिलिएशन। इसे टूल से निकालें, इस आधार पर नहीं कि लोग क्या कहते हैं कि काम हो गया। मेरे एक क्लाइंट को Solution Manager की रिपोर्ट से पता चला कि उसके 40% “पूरे हुए” टेस्ट केस कभी एक्ज़ीक्यूट ही नहीं हुए थे। यह बात गेट से पहले पकड़ में आ गई, बाद में नहीं।

1. गेट्स को चरण-परिवर्तन से जोड़ें। SAP Activate के लिए कम से कम Prepare, Explore, Realize और Deploy के बाद। एक एनर्जी क्लाइंट ने बीच-बीच में मनमाने चेकपॉइंट बना दिए और सब गड़बड़ हो गया।
2. कॉन्फ़िगरेशन शुरू होने से पहले एंट्री और एग्ज़िट क्राइटेरिया तय करें। टेस्ट कवरेज, डिफ़ेक्ट थ्रेशोल्ड और साइन करने वाले प्रोसेस ओनर पर सहमति बनाएँ। इन्हें चार्टर में डालें और स्पॉन्सर के दस्तख़त लें।
3. गेट्स को बफ़र के साथ शेड्यूल करें। हर गेट को सिर्फ़ माइलस्टोन नहीं, कैलेंडर में एक एक्टिविटी की तरह रखें। मेरे एक रिटेल क्लाइंट ने हर गेट से पहले पूरा एक हफ़्ता सिर्फ़ सफ़ाई के लिए रखा था।
4. ऐसे रिव्यूअर चुनें जो फ़ैसला ले सकें। बिज़नेस लीड प्रोसेस पर साइन करते हैं। टेक्निकल लीड कॉन्फ़िगरेशन और इंटीग्रेशन पर साइन करते हैं। कंसल्टेंट कभी बिज़नेस की ओर से साइन नहीं करते।
5. सबूत एक ही जगह रखें। छह महीने बाद कोई ऑडिटर पूछेगा कि डेटा माइग्रेशन पर किसने साइन किया था। जवाब ढूँढने में मिनट लगने चाहिए।
6. नतीजे सबको दिखाएँ। एक क्लाइंट ने अपना गेट डैशबोर्ड प्रोजेक्ट रूम की दीवार पर लगा दिया था। उसे अनदेखा करना नामुमकिन था।

सबसे अहम दो गेट्स के लिए एग्ज़िट क्राइटेरिया के उदाहरण

Realize गेट:

1. टेस्ट एक्ज़ीक्यूशन तय थ्रेशोल्ड पर या उससे ऊपर, और नतीजे टेस्ट टूल में सुरक्षित।
2. कोई प्रायोरिटी 1 डिफ़ेक्ट खुला नहीं; प्रायोरिटी 2 डिफ़ेक्ट तय आयु-सीमा के भीतर।
3. हर क्रिटिकल प्रोसेस पर उसके नामित प्रोसेस ओनर का साइन-ऑफ।
4. इंटीग्रेशन टेस्ट पूरी प्रोसेस चेन पर चले हों, नतीजे दस्तावेज़ में दर्ज हों।
5. हर कस्टम डेवलपमेंट प्रोग्राम के Clean Core नियमों के अनुसार मंज़ूर हो।

Deploy गेट:

1. डेटा माइग्रेशन का ड्रेस रिहर्सल पूरा हो और रिकंसिलिएशन पर डेटा लीड का साइन हो।
2. भूमिका के अनुसार ट्रेनिंग पूरी होने की दर तय थ्रेशोल्ड पर या उससे ऊपर हो।
3. कटओवर प्लान का रिहर्सल हुआ हो, टाइमिंग और go/no-go फ़ैसले के बिंदुओं के साथ।
4. रोलबैक प्लान दस्तावेज़ में दर्ज और टेस्ट किया हुआ हो।
5. हाइपरकेयर टीम नामित हो, और एस्केलेशन पाथ तथा सेवेरिटी की परिभाषाओं पर सहमति हो।

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

दो बातों ने मौजूदा प्रोग्राम में मेरे गेट डिज़ाइन करने का तरीका बदल दिया है।

Clean Core अब गेट का क्राइटेरिया है। SAP एक्सटेंशन को लेवल A (सिर्फ़ रिलीज़्ड इंटरफ़ेस) से लेकर लेवल D (मॉडिफ़िकेशन और सीधे टेबल में लिखना) तक वर्गीकृत करता है। Explore गेट पर हर गैप पर फ़ैसला होना चाहिए: कॉन्फ़िगर करें, रिलीज़्ड-API एक्सटेंशन के रूप में बनाएँ, या अस्वीकार करें। Realize गेट पर जाँचें कि कोई नया लेवल D ऑब्जेक्ट चुपके से न घुस गया हो। Public Edition इसे तकनीकी रूप से लागू करता है। Private Edition और on-premise ऐसा नहीं करते, इसलिए वहाँ इसे लागू करने वाला गेट ही है।

SAP Cloud ALM डिफ़ॉल्ट टूल है। यह SAP Enterprise Support, cloud edition वाले SAP cloud सब्सक्रिप्शन में शामिल है, और on-premise ग्राहकों के लिए SAP Enterprise Support में भी (SAP Support)। यह fit-to-standard, टास्क असाइनमेंट, टेस्ट ऑर्केस्ट्रेशन और ट्रेसेबिलिटी को कवर करता है। SAP Solution Manager 7.2 का मेनस्ट्रीम मेंटेनेंस 2027 के अंत में समाप्त होता है, और SAP उससे पहले Cloud ALM पर जाने की सलाह देता है (SAP Support)। अगर आप Solution Manager पर प्रोग्राम के बीच में हैं, तो वहीं पूरा करें। नए प्रोग्राम Cloud ALM के आसपास प्लान करें।

गेट मैनेज करने के टूल

टूल से ज़्यादा अनुशासन मायने रखता है। एक रिटेल क्लाइंट ने SharePoint पर एक साफ़-सुथरी गेट प्रक्रिया बनाई, जो मध्यम आकार के इम्प्लीमेंटेशन में बढ़िया चली। मैंने पूरे Solution Manager सेटअप पर भी गेट फेल होते देखे हैं, क्योंकि टीम समानांतर स्प्रेडशीट चलाती रही।

टूल	गेट मैनेजमेंट में भूमिका	किसके लिए सबसे अच्छा
SAP Cloud ALM	Fit-to-standard, टास्क, टेस्ट, ट्रेसेबिलिटी	नए S/4HANA प्रोग्राम, cloud या on-premise
SAP Solution Manager 7.2	प्रोजेक्ट ट्रैकिंग, टेस्ट और डिफ़ेक्ट मैनेजमेंट	वे प्रोग्राम जो पहले से इस पर चल रहे हैं
Jira और Confluence	टास्क, डिफ़ेक्ट, गेट क्राइटेरिया और सबूत	वे टीमें जो पहले से Atlassian टूल इस्तेमाल करती हैं
Tricentis Tosca	टेस्ट ऑटोमेशन और कवरेज रिपोर्टिंग	भारी टेस्ट ऑटोमेशन वाले प्रोग्राम
ServiceNow	अप्रूवल वर्कफ़्लो और ऑडिट ट्रेल	वे कंपनियाँ जो पहले से ServiceNow चला रही हैं

आप जो भी चुनें, वही सच का इकलौता स्रोत होना चाहिए। समानांतर स्प्रेडशीट हमेशा वही वर्ज़न दिखाती है जो टीम दिखाना चाहती है। SAP टेस्टिंग और वैलिडेशन टूल की मेरी तुलना में टेस्ट वाले पक्ष पर और गहराई से बात की गई है।

शेड्यूल के दबाव में छोड़ दिए जाते हैं। प्रोजेक्ट पिछड़ने लगें, तो सबसे पहले गेट ही कटते हैं। एक प्रोजेक्ट में रिव्यू रबर स्टैंप बन गए, और go-live दुःस्वप्न निकला: सिस्टम क्रैश हुए, ऑर्डर अटक गए, और पूरा रोलबैक करना पड़ा। जो तीन हफ़्ते उन्होंने “बचाए”, उनकी कीमत तीन महीने की रिकवरी से चुकानी पड़ी।

अस्पष्ट क्राइटेरिया। यह ऊपर बताया जा चुका है। अगर किसी क्राइटेरिया की व्याख्या करनी पड़े, तो वह बस बातचीत शुरू करने का बहाना है।

जिन रिव्यूअर के पास समय नहीं। जब मुख्य रिव्यूअर कई प्रोजेक्ट में बँटे हों, तो रिव्यू खानापूर्ति बन जाते हैं। मध्यम आकार के प्रोग्राम में Realize गेट रिव्यू कम से कम आधे दिन का होना चाहिए, और सबूत पहले से पढ़े हुए।

संस्कृति। जिन टीमों को माइलस्टोन भागदौड़ में निपटाने की आदत है, वे गेट से बचने के रास्ते खोजती हैं। यह तब बदलता है जब कोई एक्ज़ीक्यूटिव किकऑफ़ पर कहता है कि गेट अनिवार्य हैं, और फिर देरी कराने वाले पहले गेट को ओवररूल करने से मना करके यह साबित करता है।

तीन आँकड़े जो बताते हैं कि गेट काम करते हैं या नहीं

इन्हें ट्रैक करें और देखें कि गेट प्रोजेक्ट की रक्षा कर रहे हैं या सिर्फ़ रक्षा करते दिखते हैं।

1. डिफ़ेक्ट लीकेज: गेट के बाद मिले उन डिफ़ेक्ट का हिस्सा, जिन्हें गेट को पकड़ लेना चाहिए था।
2. पहली बार में पास होने की दर: अगर हर गेट पहली बार में ही पास हो जाता है, तो क्राइटेरिया में शायद दम नहीं है।
3. go-live इंसीडेंट: पहले 30 दिनों में हाई-प्रायोरिटी इंसीडेंट, Deploy गेट पर सीधा फ़ैसला होते हैं।

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

SAP प्रोजेक्ट में क्वालिटी गेट क्या होता है?

प्रोजेक्ट के चरणों के बीच का एक औपचारिक चेकपॉइंट। आगे बढ़ने से पहले टीम को दिखाना होता है कि तय और मापने योग्य क्राइटेरिया पूरे हुए हैं। हर गेट का एक नामित ओनर होता है जिसके पास प्रोजेक्ट में देरी करने का अधिकार है। SAP Activate में गेट चरण-परिवर्तन पर होते हैं, खासकर Explore, Realize और Deploy के बाद।

SAP Activate में क्वालिटी गेट्स कौन से हैं?

SAP Activate में छह चरण हैं (Discover, Prepare, Explore, Realize, Deploy और Run), और हर चरण-परिवर्तन एक गेट है। Discover बिज़नेस केस जाँचता है। Prepare गवर्नेंस और चार्टर जाँचता है। Explore डिज़ाइन साइन-ऑफ और गैप के फ़ैसले जाँचता है। Realize टेस्ट के नतीजे और डिफ़ेक्ट जाँचता है। Deploy डेटा, ट्रेनिंग और कटओवर की तैयारी जाँचता है। Run स्टेबिलाइज़ेशन और हैंडओवर जाँचता है।

SAP क्वालिटी गेट के क्राइटेरिया में क्या होना चाहिए?

ऐसे क्राइटेरिया जिनका जवाब हाँ या ना में आए। Realize के लिए: टेस्ट एक्ज़ीक्यूशन थ्रेशोल्ड, प्रायोरिटी के अनुसार खुले डिफ़ेक्ट, प्रोसेस ओनर के साइन-ऑफ और इंटीग्रेशन टेस्ट के नतीजे। Deploy के लिए: माइग्रेशन रिकंसिलिएशन, भूमिका के अनुसार ट्रेनिंग पूरी होना, रिहर्सल किया हुआ कटओवर प्लान, टेस्ट किया हुआ रोलबैक प्लान और स्टाफ़ वाली हाइपरकेयर टीम। हर क्राइटेरिया का एक ओनर होना चाहिए जो उसका सबूत तैयार करे।

SAP इम्प्लीमेंटेशन में क्वालिटी गेट्स क्यों फेल होते हैं?

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

SAP क्वालिटी गेट्स मैनेज करने के लिए कौन सा टूल इस्तेमाल करना चाहिए?

नए प्रोग्राम के लिए SAP Cloud ALM। यह SAP cloud सब्सक्रिप्शन और Enterprise Support के साथ शामिल है, और fit-to-standard, टेस्टिंग और ट्रेसेबिलिटी को सपोर्ट करता है। SAP Solution Manager 7.2 2027 के अंत में मेनस्ट्रीम मेंटेनेंस से बाहर हो जाता है। जिन कंपनियों में Jira, Tricentis Tosca और ServiceNow पहले से चल रहे हैं, वहाँ वे भी अच्छा काम करते हैं। नियम एक ही है: सच का एक ही स्रोत।

अंतिम क्वालिटी गेट पर go-live की तैयारी कैसे परखें?

सबूत के साथ पाँच चीज़ें जाँचें: डेटा माइग्रेशन का रिहर्सल और रिकंसिलिएशन हो चुका है, हर भूमिका की ट्रेनिंग पूरी है, कटओवर प्लान का go/no-go बिंदुओं के साथ रिहर्सल हो चुका है, रोलबैक प्लान टेस्ट हो चुका है, और हाइपरकेयर में स्टाफ़ और एस्केलेशन पाथ तय हैं। इनमें से कुछ भी फेल हो और बिज़नेस फिर भी आगे बढ़ना चाहे, तो उसे साइन किए हुए बिज़नेस फ़ैसले के रूप में दर्ज करें।