SAP प्रोजेक्ट के लिए रिसोर्स एलोकेशन प्लानिंग

SAP प्रोजेक्ट के लिए रिसोर्स एलोकेशन प्लानिंग का मतलब है यह तय करना कि आपको कौन-से रोल चाहिए, किस SAP Activate फ़ेज़ में, हफ़्ते के कितने घंटे के लिए, और फिर हर हफ़्ते जाँचना कि हक़ीक़त अब भी प्लान से मेल खाती है या नहीं। सामान्य हेडकाउंट नहीं, रोल के हिसाब से स्टाफ़ कीजिए। प्लान को फ़ेज़ के कर्व के आकार में ढालिए: Explore में फ़ंक्शनल लोग, Realize में टेक्निकल लोग, Deploy में डेटा, Basis और चेंज। लाइन मैनेजरों से उपलब्धता लिखित में पक्की कीजिए। यह गाइड उन प्रोग्राम डायरेक्टर, PMO और CIO के लिए है जो S/4HANA रिसोर्स प्लान बना रहे हैं या बिगड़े प्लान को बचा रहे हैं। नीचे की FTE तालिकाओं और डे-रेट रेंज को शुरुआती आधार की तरह इस्तेमाल कीजिए।

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

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

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

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

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

प्लान तब बिगड़ते हैं जब प्लानर सामान्य IT रोल इस्तेमाल करता है। SAP को ख़ास फ़ंक्शनल और टेक्निकल विशेषज्ञता चाहिए। S/4HANA प्रोग्राम का मानक सेट:

प्रोग्राम लीडरशिप। प्रोग्राम मैनेजर, PMO लीड और सॉल्यूशन आर्किटेक्ट। आर्किटेक्ट मॉड्यूल के आर-पार डिज़ाइन की संगति के लिए ज़िम्मेदार है।

फ़ंक्शनल कंसल्टेंट। स्कोप के हर मॉड्यूल के लिए एक लीड: Financial Accounting (FI), Controlling (CO), Materials Management (MM), Sales and Distribution (SD), Production Planning (PP), Extended Warehouse Management (EWM), और जहाँ स्कोप में हों वहाँ Human Capital Management (HCM), Plant Maintenance (PM) और Project System (PS)। अगर आप अभी क्लासिक Warehouse Management (WM) चला रहे हैं, तो उससे आगे बढ़ने की योजना बनाइए: S/4HANA on-premise पर उसके कंपैटिबिलिटी-पैक के उपयोग-अधिकार 2025 के अंत में समाप्त हो गए।

टेक्निकल कंसल्टेंट। रिपोर्ट, इंटरफ़ेस, कन्वर्ज़न, एनहांसमेंट, फ़ॉर्म और वर्कफ़्लो (RICEFW) के लिए, और released API या SAP BTP पर clean-core एक्सटेंशन के लिए ABAP डेवलपर। SAP Integration Suite (Cloud Integration, पहले CPI), जहाँ अब भी चल रहा हो वहाँ SAP Process Orchestration, और किसी भी थर्ड-पार्टी मिडलवेयर के लिए इंटीग्रेशन विशेषज्ञ।

प्लेटफ़ॉर्म। HANA, कर्नल पैच, ट्रांसपोर्ट, सिस्टम कॉपी और परफ़ॉर्मेंस ट्यूनिंग के लिए Basis कंसल्टेंट। रोल डिज़ाइन, segregation of duties विश्लेषण और जहाँ स्कोप में हो वहाँ SAP GRC Access Control के लिए सिक्योरिटी कंसल्टेंट।

डेटा। SAP S/4HANA Migration Cockpit के “Migrate Your Data” ऐप (पुराना LTMC ट्रांज़ैक्शन deprecated है), कस्टम ऑब्जेक्ट के लिए Migration Object Modeler और जटिल ट्रांसफ़ॉर्मेशन के लिए SAP Data Services इस्तेमाल करने वाले माइग्रेशन विशेषज्ञ। मेरी गाइड SAP डेटा माइग्रेशन क्यों फ़ेल होता है बताती है कि इस टीम को ज़्यादातर प्लान की सोच से पहले क्यों शुरू होना चाहिए।

चेंज। चेंज लीड, ट्रेनिंग लीड और बिज़नेस रेडीनेस ओनर। आमतौर पर इनकी कमी रहती है, क्योंकि ज़रूरत Deploy में ही दिखती है।

क्लाइंट की तरफ़। बिज़नेस एनालिस्ट (हर बड़े मॉड्यूल के लिए एक), प्रोसेस ओनर (हर प्रोसेस डोमेन के लिए एक) और UAT के लिए ऑपरेशंस से लिए गए टेस्टर।

इन्हें आपस में बदले जा सकने वाले स्लॉट मानना प्लानिंग की सबसे आम ग़लती है। सीनियर FI कंसल्टेंट SD डिज़ाइन सेशन नहीं चला सकता। जूनियर ABAP डेवलपर इंटीग्रेशन का आर्किटेक्चर नहीं बना सकता। रोल-दर-रोल ज़िम्मेदारियों के लिए मेरी ज़रूरी SAP इम्प्लीमेंटेशन टीम रोल की सूची देखिए।

रिसोर्स की माँग एक-सी नहीं रहती। Activate के फ़ेज़ अनुमान-योग्य कर्व बनाते हैं जिन्हें एक-सा एलोकेशन पकड़ नहीं पाता।

Prepare (आमतौर पर हफ़्ते 1 से 4)। हल्का। प्रोग्राम मैनेजर, आर्किटेक्ट और स्कोपिंग के लिए हर मॉड्यूल का एक लीड। बिज़नेस यूज़र स्कोप की पुष्टि करते हैं। Basis और सिक्योरिटी एनवायरनमेंट सेट-अप शुरू करते हैं।

Explore (आमतौर पर महीने 2 से 5)। फ़ंक्शनल कंसल्टेंट और बिज़नेस यूज़र पर भारी, जहाँ डिज़ाइन वर्कशॉप शेड्यूल तय करती हैं। डिज़ाइन फ़ैसले होने तक ABAP और इंटीग्रेशन हल्के रहते हैं। Basis सैंडबॉक्स और क्वालिटी सिस्टम तैयार करता है।

Realize (आमतौर पर महीने 5 से 12)। टेक्निकल लोगों पर भारी: कॉन्फ़िगरेशन, बिल्ड, यूनिट और इंटीग्रेशन टेस्टिंग। ABAP का लोड चरम पर होता है। बिज़नेस यूज़र टेस्ट साइकल में जुड़ते हैं। डेटा टीम माइग्रेशन ऑब्जेक्ट बनाती है और ड्राई रन चलाती है।

Deploy (आमतौर पर महीने 12 से 14)। डेटा माइग्रेशन, Basis, सिक्योरिटी, चेंज और ट्रेनिंग पर भारी। UAT बिज़नेस की क्षमता खा जाता है। कटओवर रिहर्सल के लिए एक जगह बैठी टीमें चाहिए। हाइपरकेयर की प्लानिंग शुरू होती है।

Run (महीने 14 से; हाइपरकेयर आमतौर पर 30 से 90 दिन)। छोटी कोर टीम और भारी सपोर्ट कवरेज। Basis और एप्लिकेशन मैनेजमेंट बढ़ते हैं और कंसल्टेंट घटते हैं।

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

1. Prepareक़रीब 11 FTEहफ़्ते 1 से 4। लीड स्कोप तय करते हैं, Basis सेट-अप करता है
2. Exploreक़रीब 36 FTEमहीने 2 से 5। फ़ंक्शनल लोग और बिज़नेस यूज़र
3. Realizeक़रीब 56 FTE, यही चरम हैमहीने 5 से 12। बिल्ड, और ABAP का लोड चरम पर
4. Deployक़रीब 42 FTEमहीने 12 से 14। डेटा, Basis, सिक्योरिटी, चेंज
5. Runक़रीब 12 FTEमहीने 14 से। हाइपरकेयर आमतौर पर 30 से 90 दिन

लगातार इमरजेंसी। जब टीम हमेशा आग बुझा रही हो, तो प्लान हक़ीक़त की भविष्यवाणी करना बंद कर चुका है। किसी एक की ग़ैरहाज़िरी इतनी ताक़तवर नहीं होनी चाहिए कि पूरा वर्कस्ट्रीम पटरी से उतर जाए।

बिज़नेस यूज़र तब ग़ायब हो जाते हैं जब आपको उनकी ज़रूरत होती है। बिज़नेस यूज़र के उपलब्ध न होने से डिज़ाइन सेशन और UAT अटक जाते हैं। यह देरी के सबसे आम स्रोतों में से एक है। वजह लगभग हमेशा एक ही होती है: समय की प्रतिबद्धता मान ली गई थी, औपचारिक रूप से ली नहीं गई थी। जब प्रतिबद्धता औपचारिक नहीं होती, तो हर बार ऑपरेशंस का दबाव जीतता है।

टेक्निकल लोग बहुत पतले फैले हैं। Gerald Weinberg के सॉफ़्टवेयर मैनेजमेंट पर काम का अनुमान था कि तीन प्रोजेक्ट में बँटा व्यक्ति अपनी कुल क्षमता का क़रीब 60% ही दे पाता है, बाक़ी स्विचिंग में चला जाता है। American Psychological Association का टास्क-स्विचिंग शोध का सार उसी दर्जे का नुक़सान बताता है: टास्क बदलने से आने वाले छोटे मानसिक अवरोध उत्पादक समय का 40% तक खा सकते हैं। प्लान कुशल दिखता है। आउटपुट नहीं।

क्रिटिकल पाथ हर हफ़्ते बदलता है। लगातार फेरबदल, देर से शुरू होने वाले वर्कस्ट्रीम और हर हफ़्ते की बदलती प्राथमिकताएँ आमतौर पर अस्पष्ट स्कोप या ग़लत क्रम में रखी निर्भरताओं की ओर इशारा करती हैं। रिसोर्स प्लान ठीक करने से पहले स्कोप ठीक कीजिए।

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

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

उसे फ़ेज़ के हिसाब से ढालिए। ABAP डेवलपर का लोड Explore में Realize से अलग होता है। बिज़नेस यूज़र का लोड डिज़ाइन के लिए Explore में और UAT के लिए Deploy में चरम पर होता है। एक-सा एलोकेशन काग़ज़ पर संतुलित दिखता है और ज़मीन पर फ़ेल होता है।

निर्भरताओं को साफ़ मैप कीजिए। डेटा माइग्रेशन इंटीग्रेशन टेस्टिंग को फ़ीड करता है, वह UAT को, और UAT कटओवर को चलाता है। हर निर्भरता को एक ओनर, एक तारीख़ और एक फ़्लैग दीजिए, ताकि खिसकाव उसी दिन दिख जाए।

बिज़नेस यूज़र का समय स्टीयरिंग के स्तर पर सुरक्षित कीजिए। उनके रोज़ के काम जारी रहते हैं। हफ़्ते के घंटों पर उनके मैनेजमेंट की स्पष्ट मंज़ूरी के बिना, ऑपरेशंस का दबाव आते ही वे प्रोजेक्ट छोड़ देंगे। यह समय विभाग प्रमुखों से प्रोजेक्ट मैनेजर को नहीं, स्पॉन्सर को माँगना चाहिए।

प्लान हर हफ़्ते अपडेट कीजिए। दो हफ़्ते से अछूता प्लान शायद ग़लत है। वास्तविक बनाम नियोजित उपयोग को ट्रैक कीजिए। लगातार दो हफ़्ते 120% पर रहने वाले व्यक्ति का मतलब है कि या तो वह ओवरलोड है या प्लान ग़लत है।

ये शुरुआती आधार के तौर पर इस्तेमाल करने के लिए संकेतात्मक हेडकाउंट और रेट रेंज हैं। इंडस्ट्री, स्कोप, भौगोलिक क्षेत्र और पार्टनर इन्हें खिसकाते हैं। तालिकाओं को समझदारी की जाँच की तरह इस्तेमाल कीजिए, कोटेशन की तरह नहीं।

मिड-मार्केट ब्राउनफ़ील्ड ($5 मिलियन से $15 मिलियन, क़रीब 12 महीने)

सामान्य स्कोप: एक लीगल एंटिटी या छोटा ग्रुप, तीन या चार मॉड्यूल (आमतौर पर FI, CO, MM, SD), मानक प्रोसेस और सीमित कस्टम डेवलपमेंट।

वर्कस्ट्रीम	Prepare	Explore	Realize	Deploy	Run
प्रोग्राम मैनेजर	1	1	1	1	0.5
सॉल्यूशन आर्किटेक्ट	1	1	1	0.5	0
फ़ंक्शनल कंसल्टेंट (FI/CO, MM, SD और एक अतिरिक्त)	1	4	4	2	1
ABAP और टेक्निकल	0	1	3	1	0.5
इंटीग्रेशन	0	0.5	2	1	0.5
Basis	0.5	0.5	1	2	1
सिक्योरिटी और ऑथराइज़ेशन	0	0.5	1	1.5	0.5
डेटा माइग्रेशन	0	1	2	3	0
टेस्टिंग लीड	0	0.5	1	1	0
चेंज और ट्रेनिंग	0.5	1	1	2	0.5
क्लाइंट बिज़नेस एनालिस्ट	1	4	3	2	1
चरम कुल FTE	5	14	20	17	5

एंटरप्राइज़ ब्राउनफ़ील्ड ($30 मिलियन से $80 मिलियन, 15 से 18 महीने)

सामान्य स्कोप: कई एंटिटी, छह से नौ मॉड्यूल, जटिल इंटीग्रेशन, ठीक-ठाक कस्टम डेवलपमेंट और कई देशों में रोलआउट।

वर्कस्ट्रीम	Prepare	Explore	Realize	Deploy	Run
प्रोग्राम मैनेजर और PMO	2	2	3	3	1
सॉल्यूशन आर्किटेक्ट (लीड और मॉड्यूल)	2	3	3	1.5	0.5
फ़ंक्शनल कंसल्टेंट (स्कोप के सभी मॉड्यूल)	2	10	12	5	2
ABAP और टेक्निकल	0	3	8	3	1
इंटीग्रेशन और मिडलवेयर	0.5	2	5	2	1
Fiori और UI5	0	1	3	1	0.5
Basis	1	1	2	4	2
सिक्योरिटी और GRC	0.5	1.5	2	3	1
डेटा माइग्रेशन	0	2	5	6	0.5
टेस्टिंग	0.5	1	3	4	0
चेंज और ट्रेनिंग	1	2	3	5	1
क्लाइंट बिज़नेस एनालिस्ट	2	8	7	5	2
चरम कुल FTE	11	36	56	42	12

रोल और क्षेत्र के हिसाब से डे रेट (2024 से 2025)

ये पार्टनर द्वारा बिल किए गए प्रति विशेषज्ञ रेट हैं, सैलरी नहीं। प्रोग्राम का ब्लेंडेड रेट आमतौर पर ऑनशोर सीनियर रेट से 30 से 50% कम आता है, क्योंकि ज़्यादातर प्रोग्राम ऑनशोर आर्किटेक्ट को ऑफ़शोर डिलीवरी के साथ मिलाते हैं।

रोल	ऑनशोर US/UK/DE	GCC (UAE/KSA)	नियरशोर (LatAm/EE)	ऑफ़शोर (भारत)
सॉल्यूशन आर्किटेक्ट (सीनियर)	$2,000 से $3,500	$1,500 से $2,500	$900 से $1,500	$500 से $1,000
फ़ंक्शनल कंसल्टेंट (सीनियर)	$1,500 से $2,800	$1,200 से $2,000	$700 से $1,400	$300 से $700
फ़ंक्शनल कंसल्टेंट (मिड)	$1,000 से $1,800	$800 से $1,400	$500 से $900	$200 से $500
ABAP और टेक्निकल (सीनियर)	$1,400 से $2,500	$1,000 से $1,800	$600 से $1,200	$300 से $700
इंटीग्रेशन विशेषज्ञ	$1,500 से $2,800	$1,100 से $1,900	$700 से $1,300	$350 से $800
Basis	$1,400 से $2,200	$1,000 से $1,800	$600 से $1,100	$300 से $700
सिक्योरिटी और GRC	$1,500 से $2,500	$1,100 से $1,900	$700 से $1,300	$350 से $800
डेटा माइग्रेशन	$1,300 से $2,200	$1,000 से $1,700	$600 से $1,100	$300 से $700
चेंज और ट्रेनिंग लीड	$1,200 से $2,000	$900 से $1,500	$500 से $1,000	$250 से $600
जूनियर कंसल्टेंट (कोई भी रोल)	$800 से $1,400	$500 से $900	$400 से $700	$150 से $350

ऑनशोर, नियरशोर और ऑफ़शोर का बँटवारा

ज़्यादातर SAP प्रोग्राम अलग-अलग क्षेत्रों को मिलाते हैं। यह लागत बनाम रफ़्तार का फ़ैसला है, हाँ या ना का नहीं।

US के निजी क्षेत्र के प्रोग्राम आमतौर पर FTE के हिसाब से 30 से 60% ऑनशोर चलते हैं। ऑनशोर आर्किटेक्चर, चेंज, बिज़नेस एनालिसिस और सीनियर फ़ंक्शनल रोल में केंद्रित रहता है, जहाँ बिज़नेस से नज़दीकी मायने रखती है। ऑफ़शोर ABAP, इंटीग्रेशन बिल्ड और डेटा माइग्रेशन के अमल में केंद्रित रहता है, जहाँ काम को स्पेसिफ़ाई करना आसान होता है। US फ़ेडरल प्रोग्राम अक्सर वर्कलोड के हिसाब से US-person की पाबंदियों के साथ पूरी तरह ऑनशोर होते हैं।

GCC प्रोग्राम आमतौर पर 60 से 70% ऑनशोर चलते हैं, क्योंकि स्थानीय भर्ती के नियम और अरबी भाषा की ज़रूरतें हिस्सेदारी ऊपर धकेलती हैं। ऑफ़शोर काम टाइम-ज़ोन के ओवरलैप के लिए दक्षिण एशियाई केंद्रों की ओर झुकता है। यूरोपीय प्रोग्राम अलग-अलग होते हैं: मैन्युफ़ैक्चरिंग अक्सर क़रीब 50% ऑनशोर चलती है, जबकि सरकारी क्षेत्र और नियमन वाली इंडस्ट्री डेटा रेज़िडेंसी की वजह से इससे ऊपर जाती हैं।

एक आम ग़लती सिर्फ़ लागत के लिए बँटवारे को ऑप्टिमाइज़ करना है। 80% ऑफ़शोर और 20% ऑनशोर आर्किटेक्ट वाली टीम स्प्रेडशीट पर सस्ती दिखती है। छिपी लागतें हैं रोज़ का हैंडऑफ़ साइकल और बिज़नेस संदर्भ के बिना धीमी डिज़ाइन वर्कशॉप। सबसे सस्ती टीम शायद ही सबसे सस्ता प्रोग्राम देती है। पार्टनर की तुलना करते समय मेरी गाइड टियर के हिसाब से SAP इम्प्लीमेंटेशन पार्टनर बताती है कि रेट और टीम का आकार उनके बीच कैसे अलग होता है।

एक बार बनाकर कभी दोबारा न परखा गया प्लान, प्लान नहीं है। उसकी हर मान्यता को एक परिकल्पना मानिए, जिसे एक्ज़ीक्यूशन के पहले हफ़्ते में परखना है, और उसके बाद हर हफ़्ते।

SAP प्रोजेक्ट में रिसोर्स एलोकेशन प्लानिंग क्या है, और यह क्यों मायने रखती है?

यह तय करना है कि प्रोजेक्ट को कौन-से लोग चाहिए, कब और उनके समय का कितना हिस्सा, और फिर ट्रैक करना कि वह हक़ीक़त से मेल खाता है या नहीं।

SAP प्रोजेक्ट ख़ास व्यक्तियों पर टिके होते हैं: FI/CO लीड जो आपका चार्ट ऑफ़ अकाउंट्स समझता है, माइग्रेशन विशेषज्ञ जो आपका लेगसी डेटा जानता है, चेंज लीड जिसके बिज़नेस में रिश्ते हैं। सही वक़्त पर वे उपलब्ध न हों, तो काम रुक जाता है या ग़लत हो जाता है। देरी के कई मामले, जो तकनीकी दिखते हैं, असल में रिसोर्स की समस्याएँ होते हैं।

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

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

शुरू की छोटी कमियाँ बाद में बड़ी देरी बन जाती हैं। असर दिखने तक सुधार की लागत जल्दी ठीक करने की लागत से कई गुना हो चुकी होती है।

जब बिज़नेस यूज़र के पास रोज़ का काम है, तो उन्हें SAP प्रोजेक्ट के लिए कैसे प्रतिबद्ध करवाएँ?

प्रोजेक्ट शुरू होने से पहले उनके लाइन मैनेजर से लिखित प्रतिबद्धता लीजिए: हफ़्ते के घंटे, किन फ़ेज़ में उनकी सबसे ज़्यादा ज़रूरत है और उपलब्धता बदलने पर कौन-सी मंज़ूरी चाहिए।

उनकी उपस्थिति को किसी भी दूसरे रिसोर्स की तरह ट्रैक कीजिए। जब वह घटे, तो स्टीयरिंग स्तर पर एस्केलेट कीजिए। प्रतिबद्धता विभाग प्रमुख लागू करवा सकते हैं; प्रोजेक्ट टीम नहीं।

प्रोजेक्ट के बीच में कोई अहम व्यक्ति चला जाए तो क्या करें?

पहले ही सिंगल पॉइंट ऑफ़ फ़ेल्योर से बचिए: हर क्रिटिकल वर्कस्ट्रीम को कम से कम एक और व्यक्ति इतना समझे कि उसे चलाए रख सके।

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

रिसोर्स की समस्या कब एस्केलेट करनी चाहिए?

जितना आरामदेह लगे उससे पहले। तब एस्केलेट कीजिए जब नामित निर्भरता ओनर एक हफ़्ते से ज़्यादा उपलब्ध न रहा हो, कोई बिज़नेस यूज़र बार-बार सेशन छोड़ रहा हो, कोई टेक्निकल रिसोर्स लगातार दो हफ़्ते 120% उपयोग से ऊपर चल रहा हो, या कोई वर्कस्ट्रीम टाले गए रिसोर्सिंग फ़ैसले की वजह से अटका हो।

बहुत जल्दी एस्केलेट करने की क़ीमत एक असहज बातचीत है। बहुत देर से एस्केलेट करने की क़ीमत हफ़्तों की देरी है।

कई प्रोजेक्ट में साझा रिसोर्स को कैसे संभालें?

मानकर चलिए कि दबाव आने पर साझा लोग किसी और चीज़ को प्राथमिकता देंगे। उनके प्राथमिक मैनेजर के साथ हफ़्ते के ख़ास घंटे तय कीजिए, उन पर निर्भर काम में बफ़र रखिए और जब तक आपके पास फ़ॉलबैक न हो, उन्हें अपने क्रिटिकल पाथ से बाहर रखिए।

साझा बिज़नेस यूज़र के लिए अनुरोध स्पॉन्सर की तरफ़ से आना चाहिए। प्रोजेक्ट मैनेजर विभाग प्रमुख से समय माँगे तो वह हर बार ऑपरेशंस की प्राथमिकताओं से हार जाएगा।