SAP statement of work: इसमें क्या होना ज़रूरी है

SAP statement of work (SOW) वह contract document है जो बताता है कि partner क्या deliver करेगा, कितने effort से, किसके द्वारा, और उसमें बदलाव कैसे हो सकता है। इसमें scope, विस्तृत assumptions और exclusions, phase और role के हिसाब से effort, acceptance criteria के साथ deliverables, नामित resources और change control होना ज़रूरी है।

ज़्यादातर SOWs scope को ठीक-ठाक कवर कर लेते हैं। Clients अक्सर जो छोड़ देते हैं, वह है विस्तृत assumptions और exclusions, और वही हिस्सा तय करता है कि आप अंत में कितना भुगतान करेंगे।

यह लेख मेरी गाइड SAP implementation partner कैसे चुनें का हिस्सा है। SOW उस प्रक्रिया का आखिरी कदम है, SAP partner RFP और orals के बाद। Signature से पहले SOW review के एक ठोस उदाहरण के लिए ERP contract negotiation पर मेरी case study पढ़िए।

अच्छा SAP SOW programme के लिए एक operating manual की तरह पढ़ा जाता है। आपकी तरफ़ का कोई भी व्यक्ति उसे खोलकर तीन सवालों के जवाब दे सके: हमें क्या मिल रहा है, यह किस पर निर्भर है, और कुछ बदलने पर क्या होता है।

इसमें ये sections चाहिए, और कोई section न होने पर क्या गड़बड़ होती है:

Section	इसमें क्या लिखा होना चाहिए	कमज़ोर होने पर क्या होता है
Scope	Scope में शामिल processes, modules, company codes, plants, देश और users	हर workshop यह सवाल फिर खोल देता है कि क्या शामिल था
Assumptions	वे शर्तें जिन पर कीमत निर्भर है, हर एक के साथ गलत साबित होने का परिणाम	Partner ऐसे change requests उठाता है जिन्हें आप चुनौती नहीं दे सकते
Exclusions	Partner क्या नहीं करेगा, और उसकी जगह कौन करेगा	काम आपके और partner के बीच गिर जाता है, और कोई उसका मालिक नहीं होता
Approach और phases	तरीका, phase plan और quality gates	कोई तय बिंदु नहीं जहाँ phase पूरा माना जाए
Effort	Phase और role के हिसाब से अनुमानित effort	आप नहीं बता सकते कि burn rate प्लान के हिसाब से है या नहीं
Deliverables और acceptance	नामित documents और outputs, acceptance criteria, sign-off अवधि	अधूरे काम के invoices का भुगतान हो जाता है
Resources	नामित मुख्य लोग, भूमिकाएँ, allocation और substitution के नियम	Orals में जो टीम मिली, वह site पर काम करने वाली टीम नहीं होती
Client की ज़िम्मेदारियाँ	आपके लोगों को क्या देना है, और कब	आपकी तरफ़ से हुई देरी partner के change requests बन जाती है
Change control	बदलाव कैसे उठाया, आँका, priced और approve किया जाता है	Change requests कमाई की दूसरी line बन जाते हैं
Governance	Steering committee, reporting, escalation	समस्याएँ देर से सामने आती हैं, जब वे महँगी हो चुकी होती हैं

कीमतें माँगने से पहले scope खुद लिखिए, ताकि partners आपके scope की कीमत लगाएँ, अपने scope की नहीं।

यही वह section है जिसे clients अक्सर छोड़ देते हैं। इसके बिना कीमत ऐसी शर्तों पर टिकी होती है जिन्हें आपकी तरफ़ किसी ने न पढ़ा है, न माना है।

Assumption वह शर्त है जिस पर partner ने कीमत लगाई है। Exclusion वह काम है जिसकी partner ने कोई कीमत नहीं लगाई। दोनों इतने ठोस होने चाहिए कि कोई तीसरा पक्ष जाँच सके कि वे टिके या नहीं।

कौन सी assumptions लिखनी हैं

हर assumption का एक परिणाम होना चाहिए। “अगर यह गलत साबित होती है, तो बदलाव impact assessment के साथ change control से जाएगा” यह वाक्य assumption को सजावट से नियंत्रण में बदल देता है।

SAP SOW में ये श्रेणियाँ होनी चाहिए:

1. संगठनात्मक scope। Company codes, plants, sales organisations, देशों और legal entities की संख्या जिन्हें कीमत कवर करती है।
2. Process scope। Scope में शामिल business processes, नाम के साथ, और वे SAP standard processes जिन्हें partner चाहता है कि आप अपनाएँ।
3. WRICEF की मात्रा। Workflows, reports, interfaces, conversions, enhancements और forms की संख्या, जटिलता के हिसाब से। Explore phase में यह list बढ़ने पर बजट पर चोट पड़ती है, इसलिए baseline गिनती contract में होनी चाहिए।
4. Data। माइग्रेट होने वाले data objects, history की मात्रा, mock loads की संख्या, और data की सफ़ाई कौन करेगा।
5. Integrations। हर interface नाम के साथ, दूसरी तरफ़ का system और उस system में बदलाव कौन करेगा।
6. Testing। Test cycles की संख्या, scripts कौन लिखेगा, कौन चलाएगा और defects कौन ठीक करेगा।
7. Client की उपलब्धता। आपके कौन से लोग चाहिए, उनके कितने समय के लिए, और फ़ैसले कितनी जल्दी होने चाहिए।
8. Environments और licences। Systems, tools और access कौन देगा, और कब तक।
9. Location और भाषा। टीम कहाँ काम करेगी, onshore और offshore का अनुपात, travel, और documents और training की भाषाएँ।
10. Training और hypercare। Training model, कितने trainers को training दी जाएगी, और hypercare की अवधि और exit criteria।

बजट के लिए WRICEF baseline सबसे ज़्यादा मायने रखता है। SAP की अपनी course material Explore phase को एक fit-to-standard analysis बताती है, जहाँ approved delta requirements को Realize phase के लिए product backlog में जोड़ा जाता है (SAP Learning)। हर approved delta नया WRICEF effort बन सकता है, इसलिए बढ़त मापने के लिए आपको शुरुआती गिनती चाहिए।

कौन से exclusions लिखने हैं

Exclusions में यह लिखा होना चाहिए कि उसकी जगह काम कौन करेगा। बिना मालिक के “Excluded” एक ऐसी खाली जगह है जो cutover के दौरान मिलने का इंतज़ार कर रही है।

आम श्रेणियाँ ये हैं:

1. Legacy systems में data cleansing और enrichment, जो अक्सर client का काम होता है।
2. Third-party और legacy systems में बदलाव, जो किसी interface की दूसरी तरफ़ हैं।
3. Software licences और subscriptions, जो SAP के साथ आपके contract में होते हैं, SOW में नहीं।
4. Infrastructure और hosting, जब तक partner साफ़ तौर पर उन्हें नहीं चला रहा।
5. End-user training देना, जहाँ partner सिर्फ़ आपके trainers को training देता है।
6. Organisational change management, जो list में लिखे से आगे है।
7. Security, roles और authorisation design, अगर उसका मालिक कोई और पक्ष है।
8. Performance, penetration और regression testing, जो नामित cycles से बाहर है।
9. देश, entities या localisations, जो संगठनात्मक scope में नहीं हैं।
10. Hypercare के बाद application support, जो एक अलग contract है।

दोनों lists को अपने programme director के साथ आमने-सामने रखकर पढ़िए। जो चीज़ किसी भी list में नहीं है, वहीं से change request आएगा।

SAP implementation के लिए जिस commercial model की मैं सलाह देता हूँ, वह है time and materials, जिसमें effort तय और मापा हुआ हो। इसका मतलब है कि phase और role के हिसाब से अनुमानित effort contract में लिखा होता है, ताकि आप हर महीने वास्तविक effort को उसके सामने track कर सकें।

Board को fixed price ज़्यादा सुरक्षित दिखता है। व्यवहार में कीमत तभी तक fixed रहती है जब तक हर assumption टिकी रहे, और SAP programme Explore के अंत तक उनमें से ज़्यादातर को परख लेता है। SAP implementation cost पर मेरे notes बताते हैं कि fixed-price phase कब फिर भी समझदारी हो सकता है।

SOW में दोनों models की तुलना इस तरह है:

तुलना का बिंदु	Fixed price	तय effort के साथ time and materials
Contract क्या तय करता है	कीमत, जब तक assumptions टिकी रहें	Rates, और phase और role के हिसाब से अनुमानित effort
जोखिम कहाँ है	Partner उसकी कीमत contingency के रूप में जोड़ता है	आपके पास, लेकिन हर महीने दिखता हुआ
जब scope बदलता है	हर बदलाव एक negotiation बन जाता है	Effort बदलता है, और आप उसे अनुमान के सामने देखते हैं
आप क्या track कर सकते हैं	Milestones और change requests	प्लान के सामने वास्तविक effort, phase और role के हिसाब से
आपकी रक्षा क्या करता है	कसी हुई assumptions और exclusions	कसी हुई assumptions, exclusions और effort reporting

तय effort time and materials को खुले cheque से नियंत्रित बजट में बदल देता है। अनुमान को phases और roles की एक table के रूप में, person days में, माँगिए, और उस table के सामने मासिक reporting को contract की बाध्यता बनाइए।

Rates को effort में छिपने मत दीजिए। SAP projects के लिए resource allocation planning पर मेरी गाइड की मदद से role mix को market rates के सामने जाँचिए।

शुरुआत में ज़्यादा senior दिनों और बाद में ज़्यादा junior दिनों वाला प्लान आम है। उल्टे प्लान के लिए स्पष्टीकरण चाहिए।

Deliverable एक नामित output है जिसके पूरा होने की परिभाषा तय हो। “Design support” कोई deliverable नहीं है। Record to report के लिए एक signed solution design document, जिसकी तय criteria के सामने समीक्षा हुई हो, deliverable है।

Acceptance को quality gates से जोड़िए

SAP Activate छह phases में चलता है: Discover, Prepare, Explore, Realize, Deploy और Run। SAP हर phase के बाद औपचारिक quality gates बताता है, जो project के आगे बढ़ने से पहले जाँचते हैं कि phase के deliverables पूरे हैं (SAP Learning)।

SOW में उन gates का इस्तेमाल कीजिए। हर gate पर देय deliverables, acceptance criteria और समीक्षा के लिए आपके पास कितने दिन हैं, यह list कीजिए। भुगतान को calendar से नहीं, accepted deliverables से जोड़िए।

आपकी तरफ़ किसी को उन documents को परख पाना चाहिए। यह उन तीन मौकों में से एक है जहाँ मैं independent consultant को लाने की सलाह देता हूँ: contracting के दौरान, design के लिए, और partner के deliverables के आकलन के लिए। SAP partner बनाम independent consultant पर मेरा लेख बताता है कि दोनों भूमिकाएँ साथ कैसे काम करती हैं।

लोगों के नाम लिखिए, और उन्हें जाँचिए

प्रस्तावित resources की कमज़ोर गुणवत्ता उन दो चीज़ों में से एक है जो मुझे किसी bid से पीछे हटा देती हैं। दूसरी है ऐसा partner जो architecture और प्लान नहीं समझा सकता।

SOW में solution architect, programme manager और हर functional और technical lead का नाम होना चाहिए। उनका allocation, replacements का interview लेने का आपका अधिकार, और हर substitution के लिए आपकी approval लिखिए। ERP contract negotiation पर case study नामित resource clause को व्यवहार में दिखाती है।

CV की बात मान लेने के बजाय certifications जाँचिए। SAP certification badges Credly के ज़रिए जारी करता है, जो real-time verification की सुविधा देता है (SAP Learning)। SAP की stay certified प्रक्रिया के तहत, अगर धारक अनिवार्य assessment छोड़ देता है तो certification समाप्त हो जाता है (SAP Learning)।

यह clause जितना दिखता है उससे ज़्यादा मायने रखता है। मैंने एक programme के दौरान partner बदला है, और वजह यह थी कि partner अच्छी गुणवत्ता के resources नहीं दे पाया। Project के बीच में SAP partner बदलने पर मेरी गाइड बताती है कि वहाँ पहुँचने से पहले क्या सुरक्षित करना है।

Change control वह जगह है जहाँ कमज़ोर SOW महँगा पड़ता है। अगर assumptions अस्पष्ट हैं, तो लगभग किसी भी चीज़ को बदलाव साबित किया जा सकता है।

काम करने लायक change control section में ये तत्व चाहिए:

1. एक trigger। बदलाव तभी होता है जब कोई assumption टूटे, कोई exclusion scope में लाया जाए या आप कुछ नया माँगें।
2. एक impact assessment। Scope, role के हिसाब से effort, timeline और लागत, लिखित में, काम शुरू होने से पहले।
3. एक rate card। बदलावों की कीमत contract rates पर लगती है, जब तक तय न हो, जल्दी के लिए कोई premium नहीं।
4. Approval का स्तर। आपकी तरफ़ कौन किस मूल्य तक के बदलाव approve कर सकता है, और एक तय सीमा से ऊपर CFO।
5. एक log। हर बदलाव, approved हो या rejected, चलते कुल योग के साथ steering committee को report किया जाए।
6. Baseline से जुड़ाव। नए WRICEF objects को assumptions में लिखी गिनती के सामने मापा जाता है।

Partner जायज़ बदलाव भी उठाएगा। SAP programmes में ऐसी चीज़ें सामने आती हैं जो contract signature के समय किसी को पता नहीं थीं। लक्ष्य यह है कि पैसा खर्च होने से पहले हर बदलाव दिखे, उसकी कीमत लगे और वह approve हो।

जिन 21 SAP programmes का मैंने नेतृत्व किया है या जिन्हें संकट से निकाला है, उनमें सबसे बड़ी गलती जो मैं देखता हूँ, वह है शुरुआत में ठीक से planning न करना। SOW वह जगह है जहाँ वह planning बाध्यकारी बनती है, और विवादित change requests के मुकाबले उस पर लगाया गया समय सस्ता है।

ठोस अगला कदम: आपके सामने जो SOW है, उसकी हर assumption और exclusion को एक page पर list कीजिए। हर एक के आगे लिखिए कि गलत साबित होने पर क्या होगा और भुगतान कौन करेगा। अगर आप वह column नहीं भर सकते, तो SOW sign करने के लिए तैयार नहीं है।

अगर आप signature से पहले किसी SAP statement of work पर independent नज़र चाहते हैं, तो मैं contracting के दौरान clients की इसमें मदद करता हूँ। आप यहाँ मुझसे संपर्क कर सकते हैं।

SAP statement of work में क्या शामिल होना चाहिए?

Scope, विस्तृत assumptions, exclusions, approach और phases, phase और role के हिसाब से अनुमानित effort, acceptance criteria के साथ deliverables, नामित resources, client की ज़िम्मेदारियाँ, change control और governance। जो हिस्सा सबसे ज़्यादा कमज़ोर छोड़ा जाता है, वह है assumptions और exclusions, और वही हिस्सा अंतिम लागत तय करता है।

SAP SOW में assumptions और exclusions में क्या अंतर है?

Assumption वह शर्त है जिस पर partner ने कीमत लगाई, जैसे company codes या WRICEF objects की संख्या। Exclusion वह काम है जिसकी partner ने कोई कीमत नहीं लगाई, जैसे legacy data cleansing। हर assumption में लिखा हो कि गलत साबित होने पर क्या होगा, और हर exclusion में यह नाम हो कि उसकी जगह काम कौन करेगा।

SAP implementation के लिए fixed price बेहतर है या time and materials?

मेरी सलाह है time and materials, जिसमें effort तय और मापा हुआ हो: phase और role के हिसाब से अनुमानित effort contract में लिखा हो और हर महीने track हो। Fixed price तभी तक टिकता है जब तक हर assumption टिकी रहे, और SAP programme Explore phase के दौरान ज़्यादातर assumptions को परख लेता है।

SAP deliverables के लिए acceptance criteria कैसे तय करें?

हर deliverable का नाम लिखिए, बताइए कि पूरा होना कैसा दिखता है, और अपनी टीम के लिए समीक्षा की अवधि तय कीजिए। उन्हें हर phase के अंत में SAP Activate quality gates से जोड़िए, और भुगतान तभी कीजिए जब deliverable accept हो जाए।

क्या SAP SOW में consultants के नाम होने चाहिए?

हाँ, मुख्य भूमिकाओं के लिए: solution architect, programme manager और functional और technical leads। उनका allocation, replacements का interview लेने का आपका अधिकार और किसी भी substitution के लिए आपकी approval जोड़िए। CV पर भरोसा करने के बजाय Credly पर SAP badges के ज़रिए certifications verify कीजिए।

SAP statement of work किसे लिखना चाहिए?

Draft partner बनाता है, लेकिन scope और assumptions आपकी तरफ़ से आने चाहिए। Market में जाने से पहले अपना scope लिखिए, और signature से पहले partner से स्वतंत्र किसी व्यक्ति से assumptions, exclusions और deliverables की समीक्षा करवाइए।