SAP प्रोजेक्ट रिस्क असेसमेंट: व्यावहारिक तरीक़ा

SAP प्रोजेक्ट रिस्क असेसमेंट उन चीज़ों की सूची है जो प्रोग्राम को पटरी से उतार सकती हैं, और हर जोखिम को संभावना और असर के हिसाब से स्कोर करती है। हर जोखिम का एक नामित ओनर होता है, उसके होने से पहले ही एक प्रतिक्रिया तय होती है, और सूची की समीक्षा हर हफ़्ते होती है। जो जोखिम SAP प्रोग्रामों को डुबोते हैं, वे शायद ही कभी चौंकाने वाले होते हैं: डेटा माइग्रेशन, इंटीग्रेशन, लोगों की उपलब्धता, स्कोप का भटकना और अडॉप्शन। यह गाइड उन प्रोग्राम मैनेजरों और स्पॉन्सर्स के लिए है जिन्हें ऐसा रिस्क रजिस्टर चाहिए जो फ़ैसले बदले, फ़ोल्डर में पड़ा न रहे। इसमें एक स्कोर किया हुआ मैट्रिक्स है, रजिस्टर टेम्पलेट है, तीन सार्वजनिक विफलताएँ उदाहरण के तौर पर हैं, और वे जोखिम हैं जो RISE with SAP और clean core जोड़ते हैं। शुरुआत इससे कीजिए कि आपके पास जो जोखिम पहले से हैं, उनमें से हर एक के सामने एक नामित ओनर लगाइए।

ज़्यादातर SAP रिस्क असेसमेंट पहली स्टीयरिंग कमेटी से पहले बनते हैं, एक बार देखे जाते हैं, और फिर कभी छुए नहीं जाते। यह रिस्क मैनेजमेंट नहीं है। यह सिर्फ़ एक दस्तावेज़ है।

मैंने ऐसे जोखिम देखे हैं जिन्हें शुरू में उठाना बहुत असुविधाजनक लगा, इसलिए उन्हें दबा दिया गया। वह चुप्पी लगभग हमेशा आगे जाकर ज़्यादा महँगी पड़ती है। Materials Management की एक छोटी इंटीग्रेशन समस्या से शुरू होकर अचानक फ़ाइनेंस रुक जाता है। टेस्टिंग में ठीक दिखी रिपोर्ट सिस्टम अपडेट के बाद टूट जाती है। मैंने ऐसा एक से ज़्यादा बार होते देखा है।

जोखिम चौंकाने वाले नहीं थे। वे दर्ज थे। किसी ने उन पर कार्रवाई नहीं की।

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

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

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

समयसीमा। ब्लूप्रिंट देर से आता है तो टेस्टिंग दब जाती है, पर go-live की तारीख़ वही रहती है। UAT, ट्रेनिंग और डेटा तैयारी जल्दबाज़ी में होती है। यही पैटर्न लगभग हर उस प्रोग्राम में दिखता है जो कोई फ़ेज़ गेट चूकता है और आगे की योजना नहीं हिलाता।

अडॉप्शन। लोग उसे ठुकराते हैं जिसे वे समझते नहीं। कमज़ोर या देर से हुई ट्रेनिंग वर्कअराउंड पैदा करती है, वर्कअराउंड डेटा बिगाड़ते हैं, और चेंज मैनेजमेंट की विफलता का दोष सिस्टम पर आ जाता है।

ये केस सार्वजनिक हैं और अच्छी तरह दर्ज हैं। ये पैटर्न हर पैमाने पर दोहराए जाते हैं।

Lidl: सात साल में लगभग €500 मिलियन

Lidl ने 2011 में SAP for Retail पर अपना eLWIS प्रोजेक्ट शुरू किया, कुछ छोटे देशों में go-live किया, और 2018 में लगभग €500 मिलियन की रिपोर्टेड लागत पर उसे छोड़ दिया। व्यापक रूप से बताया गया एक कारण: Lidl इन्वेंटरी का मूल्यांकन ख़रीद मूल्य पर करता था, जबकि SAP का स्टैंडर्ड रिटेल मॉडल रिटेल मूल्य इस्तेमाल करता है। Lidl ने अपनी प्रथा बदलने के बजाय कस्टमाइज़ किया, और कंपनी ने कहा कि मूल लक्ष्य वाजिब प्रयास में हासिल नहीं हो सकते थे।

सबक: आपके डेटा मॉडल और SAP के स्टैंडर्ड के बीच का बेमेल पहले हफ़्ते का जोखिम है, पाँचवें साल की खोज नहीं।

HP: लगभग $400 मिलियन का खोया राजस्व

2004 में HP ने अपने सर्वर बिज़नेस का एक हिस्सा एक समेकित SAP-आधारित ऑर्डर और सप्लाई चेन सिस्टम पर माइग्रेट किया। लेगेसी फ़्रंट एंड और SAP के बीच ऑर्डर गिर जाते थे और उन पर मैन्युअल काम करना पड़ता था, और बैकलॉग दोगुना हो गया। HP के CEO ने कहा कि समस्याओं की वजह से सर्वर और स्टोरेज ग्रुप को लगभग $400 मिलियन का राजस्व और $275 मिलियन का ऑपरेटिंग प्रॉफ़िट गँवाना पड़ा, और $120 मिलियन का बैकलॉग रह गया। HP के CIO ने बाद में कहा कि टीम ने तीन हफ़्ते की रुकावट की योजना बनाई थी और उसे चार से छह हफ़्ते के लिए कंटिजेंसी रखनी चाहिए थी।

सबक: कंटिजेंसी का आकार औसत कटओवर के हिसाब से नहीं, ख़राब कटओवर के हिसाब से रखिए, और स्विच करने से पहले इन्वेंटरी या चैनल बफ़र बनाइए।

Nike: $100 मिलियन से ज़्यादा की खोई बिक्री

2000 में Nike ने अपने SAP ERP प्रोग्राम से पहले i2 डिमांड-प्लानिंग सॉफ़्टवेयर go-live किया। सॉफ़्टवेयर को Nike के लेगेसी सिस्टम के साथ चलाने के लिए भारी कस्टमाइज़ किया गया था, वह धीमा चलता था और प्रोडक्ट वॉल्यूम के नीचे क्रैश हो जाता था। उसने कुछ जूतों के ऑर्डर ज़रूरत से ज़्यादा और कुछ के बहुत कम दिए। Nike को $100 मिलियन से ज़्यादा की बिक्री का नुक़सान हुआ और उसका शेयर लगभग 20% गिरा। Nike ने बाद में अल्प और मध्यम अवधि की प्लानिंग SAP में ले ली।

सबक: जब तक इंटीग्रेशन प्रोडक्शन वॉल्यूम पर असली डेटा के साथ चल न चुका हो, मानकर मत चलिए कि वह काम करता है।

मान्यताओं पर बना असेसमेंट न होने से भी बुरा है, क्योंकि वह झूठा भरोसा पैदा करता है। छह इनपुट मायने रखते हैं:

1. स्कोप दस्तावेज़ीकरण: चार्टर, अप्रूव्ड स्कोप और साइन की हुई रिक्वायरमेंट। अगर ये नहीं हैं, तो स्कोप जोखिम पहले से ऊँचा है।
2. संसाधन प्रतिबद्धताएँ: विभाग प्रमुखों की लिखित प्रतिबद्धताएँ, अहम भूमिकाओं के लिए स्किल्स मैट्रिक्स, और हर मुख्य पद के लिए एक नामित बैकअप।
3. बजट और टाइमलाइन: कंटिजेंसी के साथ अप्रूव्ड बजट, और तुलनीय प्रोग्रामों के सामने जाँची गई टाइमलाइन। पूरे रोलआउट के लिए छह महीने और न्यूनतम फ़ंडिंग ऐसा जोखिम है जिसे अभी उठाना चाहिए।
4. वेंडर प्रतिबद्धताएँ: सर्विस लेवल और पेनल्टी वाले कॉन्ट्रैक्ट। RISE पर, SAP की ज़िम्मेदारियाँ और एस्केलेशन का रास्ता।
5. तकनीकी लैंडस्केप: लेगेसी संगतता, डेटा माइग्रेशन की जटिलता, डिप्लॉयमेंट मॉडल और किसी भी कस्टम काम के लिए clean-core योजना।
6. पिछले प्रोजेक्ट के लॉग: पहले के SAP या ERP प्रोग्रामों के रिस्क रजिस्टर, इश्यू लॉग और पोस्ट-मॉर्टम। ज़्यादातर जोखिम नए नहीं होते।

हर जोखिम को संभावना और असर पर 1 से 5 तक स्कोर कीजिए और गुणा कीजिए। नीचे का उदाहरण S/4HANA प्रोग्राम के लिए एक सामान्य शुरुआती बिंदु है; आपके स्कोर अलग होंगे।

जोखिम	संभावना (1-5)	असर (1-5)	स्कोर	प्राथमिकता
डेटा माइग्रेशन की विफलता	4	5	20	उच्च
इंटीग्रेशन में देरी	4	4	16	उच्च
संसाधनों की कमी	4	4	16	उच्च
बजट ओवररन	3	5	15	मध्यम
कोर में कस्टम कोड जो अपग्रेड रोकता है	3	5	15	मध्यम
स्कोप क्रीप	4	3	12	मध्यम
टेस्ट कवरेज की कमियाँ	3	4	12	मध्यम
पीक लोड में परफ़ॉर्मेंस	3	4	12	मध्यम
अनुपालन की कमियाँ	2	5	10	मध्यम
SAP में एस्केलेशन का कोई रास्ता नहीं (RISE)	2	5	10	मध्यम
यूज़र अडॉप्शन कम	3	3	9	मध्यम
सब्सक्रिप्शन या लाइसेंस लागत का जोखिम	2	4	8	मध्यम
KPI ट्रैक नहीं हो रहे	3	2	6	निम्न

16 और उससे ऊपर के स्कोर पर नामित ओनर और तुरंत कार्रवाई चाहिए। 8 से 15 के स्कोर पर निगरानी और तय एस्केलेशन ट्रिगर चाहिए। 8 से नीचे वाले को रजिस्टर में रखिए, उस पर प्राथमिकता का समय मत लगाइए। स्कोर शुरुआती बिंदु हैं, फ़ैसला नहीं: 10 पर स्कोर किया गया अनुपालन जोखिम नियंत्रित उद्योग में 25 हो सकता है।

अकेला स्कोर कुछ नहीं बदलता। हर जोखिम के लिए ये फ़ील्ड भरे होने चाहिए।

फ़ील्ड	क्या लिखें	उदाहरण
जोखिम	घटना, एक वाक्य में	मॉक लोड 2 से पहले वेंडर मास्टर डेटा साफ़ नहीं हुआ है
ओनर	एक नामित व्यक्ति	अकाउंट्स पेएबल लीड
स्कोर	संभावना × असर	4 × 5 = 20
ट्रिगर	वह मापने योग्य बिंदु जहाँ आप कार्रवाई करते हैं	मॉक 1 एक्सट्रैक्ट में डुप्लिकेट दर 5% से ऊपर
प्रतिक्रिया	बचना, घटाना, ट्रांसफ़र करना या स्वीकार करना, कार्रवाई के साथ	घटाना: तीन हफ़्ते के लिए दो AP एनालिस्ट सफ़ाई पर
अगली समीक्षा	तारीख़	अगले सोमवार की रिस्क समीक्षा
स्थिति	खुला, कार्रवाई में, बंद	कार्रवाई में

जहाँ हो सके, लागत को असली शब्दों में रखिए। “उच्च जोखिम” धुंधला है। “UAT में एक हफ़्ते की देरी टीम के समय में लगभग छह अंकों की रकम लागत लाती है और go-live को तीन हफ़्ते आगे धकेल सकती है” ध्यान खींचता है।

कस्टम कोड अपने आप में एक जोखिम श्रेणी है। S/4HANA Cloud Public Edition में कोर में कस्टम कोड संभव नहीं है। एक्सटेंशन SAP BTP, released API या key-user टूल से होते हैं। प्राइवेट क्लाउड और on-premise पर आप अब भी कोर को बदल सकते हैं, और जो पार्टनर ऐसा करने के आदी हैं वे करेंगे। वह टेक्निकल डेट पहले बड़े अपग्रेड पर सामने आता है। ट्रैक कीजिए कि पहचानी गई कितनी कस्टमाइज़ेशन के लिए clean-core तरीक़ा तय हो चुका है, पार्टनर का BTP एक्सटेंशन अनुभव जाँचिए, और Explore के अंत तक एक रिव्यू फ़ोरम खड़ा कर दीजिए।

RISE बदल देता है कि उपलब्धता किसकी है। SAP इन्फ्रास्ट्रक्चर चलाता है, इसलिए जोखिम “हमारी टीम उपलब्धता की मालिक है” से खिसककर “SAP इसका मालिक है और कुछ फ़ेल होने पर हमें उस तक पहुँचने का तेज़ रास्ता चाहिए” पर आ जाता है। SAP के नामित संपर्क, एस्केलेशन का रास्ता और सर्विस लेवल, और go-live से पहले तय हुई इन्सिडेंट योजना दर्ज कीजिए। इनके बिना, जो समस्याएँ SAP के पास जानी चाहिए, वे प्रोजेक्ट टीम के भीतर बहुत देर तक पड़ी रहती हैं।

AI काग़ज़ी काम में मदद करता है, फ़ैसले में नहीं। SAP Cloud ALM में Joule-आधारित असिस्टेंट और Microsoft Copilot जैसे टूल स्टेटस रिपोर्ट, डिफ़ेक्ट लॉग और मिनट्स से रजिस्टर एंट्री और स्टीयरिंग पैक के ड्राफ़्ट बना सकते हैं। इससे साफ़ सोर्स डेटा वाले प्रोग्रामों में रजिस्टर का रखरखाव तेज़ होता है। यह उन जोखिमों को ढूँढता है जो डेटा में पहले से दिख रहे हैं। यह तय नहीं करता कि किन जोखिमों पर कार्रवाई होनी चाहिए, ओनर्स से कार्रवाई नहीं करवाता, और वे जोखिम एस्केलेट नहीं करता जिन्हें नेतृत्व अनदेखा करना पसंद करेगा।

1. पाँचों श्रेणियों में जोखिम पहचानिए। IT, बिज़नेस और वेंडर्स के साथ वर्कशॉप चलाइए; हर एक को अलग जोखिम दिखते हैं। RISE पर कम से कम एक वर्कशॉप में SAP के संपर्कों को शामिल कीजिए। जो जोखिम टीमें अक्सर चूक जाती हैं: IT और बिज़नेस का अलग-अलग उम्मीद रखना, बाहरी इंटीग्रेशन का ठीक से परिभाषित न होना, UAT ओनर्स का उपलब्ध न होना, और अनौपचारिक स्कोप बदलाव।
2. हर जोखिम को स्कोर कीजिए संभावना और असर पर, जहाँ संभव हो असली संख्याओं के साथ।
3. हर जोखिम का एक ओनर तय कीजिए। एक व्यक्ति, टीम नहीं। ओनर नहीं, तो ट्रैकिंग नहीं, समाधान नहीं।
4. जोखिम आने से पहले प्रतिक्रिया तय कीजिए। टालना, घटाना, ट्रांसफ़र करना या स्वीकार करना। “निगरानी करो और जवाब दो” कोई योजना नहीं है। यह एक टाला हुआ फ़ैसला है।
5. हर हफ़्ते समीक्षा कीजिए। खुले जोखिम जाँचिए, नए जोड़िए, जहाँ हालात बदले वहाँ दोबारा स्कोर कीजिए और जो ट्रिगर के क़रीब हो उसे एस्केलेट कीजिए। शीर्ष जोखिम स्टीयरिंग कमेटी में रंग के बजाय प्रस्तावित फ़ैसले के साथ ले जाइए।

1. 01पहचानेंपाँचों श्रेणियाँ
2. 02स्कोर करेंसंभावना × असर, 1 से 5
3. 03ओनर तय करेंएक व्यक्ति, टीम नहीं
4. 04प्रतिक्रिया तय करेंटालें, घटाएँ, ट्रांसफ़र करें या स्वीकार करें
5. 05हर हफ़्ते समीक्षा करेंदोबारा स्कोर करें, ट्रिगर के पास एस्केलेट करें

16 या उससे ऊपर: इसी हफ़्ते नामित ओनर और कार्रवाई

SAP प्रोजेक्ट में रिस्क असेसमेंट क्या है?

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

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

स्कोप, संसाधन, तकनीकी, समयसीमा और अडॉप्शन में जोखिम सूचीबद्ध कीजिए, साथ में clean core और RISE पर SAP में एस्केलेशन। हर एक को संभावना और असर पर 1 से 5 तक स्कोर कीजिए और गुणा कीजिए। 16 और उससे ऊपर को उच्च, 8 से 15 को मध्यम और 8 से नीचे को निम्न मानिए। हर मध्यम और उच्च जोखिम को एक ओनर और एक मापने योग्य ट्रिगर दीजिए, जैसे “अगर हफ़्ता 16 तक UAT पूर्णता 80% से नीचे है, तो go-live तारीख़ की समीक्षा होगी”। हर हफ़्ते और हर फ़ेज़ गेट पर दोबारा स्कोर कीजिए।

SAP इम्प्लीमेंटेशन में सबसे आम जोखिम कौन-से हैं?

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

SAP प्रोजेक्ट के दौरान रिस्क असेसमेंट कब करना चाहिए?

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

SAP प्रोग्राम में जोखिमों का ओनर कौन होना चाहिए?

वह व्यक्ति जो उन पर कार्रवाई कर सके। डेटा माइग्रेशन जोखिम का ओनर डेटा लीड है, इंटीग्रेशन जोखिम का टेक्निकल आर्किटेक्ट, अडॉप्शन जोखिम का चेंज लीड, और clean-core जोखिम का सॉल्यूशन आर्किटेक्ट। RISE पर SAP में एस्केलेशन के रास्ते का ओनर CIO या प्रोग्राम डायरेक्टर है। प्रोग्राम मैनेजर रजिस्टर की सेहत ट्रैक करता है, पर हर जोखिम का ओनर नहीं होता।

ERP रिस्क असेसमेंट छोड़ देने पर क्या होता है?

बड़े पैमाने पर Lidl जैसे मामले होते हैं, जिसने लगभग €500 मिलियन के बाद 2018 में अपना SAP रिटेल प्रोजेक्ट छोड़ दिया। या HP, जिसके 2004 के SAP ऑर्डर सिस्टम माइग्रेशन से उसके सर्वर ग्रुप को लगभग $400 मिलियन का राजस्व गँवाना पड़ा। छोटे पैमाने पर तंत्र वही है: डेटा मॉडल का बेमेल देर से पकड़ा जाना, इंटीग्रेशन का प्रोडक्शन वॉल्यूम पर फ़ेल होना, और कमज़ोर ट्रेनिंग से अडॉप्शन की विफलता। जोखिम समस्या बनने से पहले ही पहचाने जा सकते थे।