SAP implementation RFP: क्या माँगें और कैसे score करें

SAP implementation RFP में partners से वादे नहीं, सबूत माँगिए: मिलते-जुलते projects के references, वे जिन लोगों को लगाएँगे उनके CVs, और आपके scope के लिए architecture और प्लान। Bids को उन वज़नों पर score कीजिए जो आपने उनके आने से पहले तय किए हों, फिर orals से जाँचिए कि delivery टीम प्लान समझा सकती है।

छोटा जवाब: RFP लोगों और प्लान की परीक्षा है, methodology slides की नहीं।

यह लेख सिर्फ़ फ़ैसले के request for proposal (RFP) चरण को कवर करता है। लंबी list से contract तक की पूरी selection प्रक्रिया मेरी गाइड SAP implementation partner कैसे चुनें में है।

जिन 21 SAP programmes का मैंने नेतृत्व किया है या जिन्हें संकट से निकाला है, उनमें सबसे बड़ी गलती जो मैं देखता हूँ, वह है शुरुआत में ठीक से planning न करना। अपना scope जाने बिना भेजा गया SAP RFP हर partner को न्योता देता है कि वह खाली जगहें अपनी assumptions से भरे। फिर आप bids की तुलना नहीं कर पाते, क्योंकि हर bid एक अलग programme की कीमत लगाती है।

इसलिए क्रम मायने रखता है। अपना scope तय कीजिए, कौन से processes अंदर हैं और कौन से बाहर, आपकी entities और देश, आपके integrations और आपका data, फिर उसी के इर्द-गिर्द RFP लिखिए।

Scope बाद में बजट की भी रक्षा करता है। बजट पर चोट SAP Activate के Explore phase में पड़ती है, जहाँ SAP का तरीका fit-to-standard workshops चलाता है और gaps को backlog में दर्ज करता है।

वहीं WRICEF list (workflows, reports, interfaces, conversions, enhancements और forms) बढ़ती है, और हर नया object लागत है। आपके scope पर बना RFP आपको एक baseline देता है जिसके सामने उस बढ़त को मापा जा सके।

RFP कम से कम तीन partners की shortlist को भेजिए।

लंबी list SAP Partner Finder से बनाइए, जहाँ SAP दिखाता है कि partners के पास SAP PartnerEdge के तहत कौन सी competencies हैं, हर एक तीन tiers में: essential, advanced और expert। Badge list में जगह दिलाता है। Contract नहीं दिलाता।

पूरा selection शुरू से अंत तक लगभग 12 हफ़्ते लेता है।

SAP RFP चरण कैसे चलता है

1. 01

   Scope

   किसी भी partner के देखने से पहले scope, processes, entities, integrations और data खुद लिखिए।

2. 02

   RFP

   कम से कम तीन partners की shortlist को एक ही pack भेजिए, scoring के वज़न पहले से तय।

3. 03

   लिखित bids

   हर bid को वज़नों के सामने score कीजिए, और हर generic जवाब को चिह्नित कीजिए।

4. 04

   Orals

   प्रस्तावित delivery टीम से architecture और प्लान आमने-सामने समझाने को कहिए।

5. 05

   References

   आपके जैसे projects के references को call कीजिए और उन पर partner के अनुभव के बारे में पूछिए।

6. 06

   Contract

   जीतने वाली bid का effort, नामित लोग और assumptions statement of work में ले जाइए।

SAP RFP के दो हिस्से होते हैं: आप partners को क्या देते हैं और आप उनसे क्या वापस माँगते हैं।

आप partners को क्या देते हैं

हर partner को एक ही pack, एक ही समय पर दीजिए। Pack जितना अच्छा, जवाब उतने ठोस:

1. पृष्ठभूमि और उद्देश्य। आप SAP क्यों लागू कर रहे हैं, उसके बाद business को क्या कर पाना चाहिए, और कौन सी तारीखें मायने रखती हैं।
2. Scope। अंदर और बाहर के processes, entities, देश, समूह के हिसाब से users, और वे SAP products जिनका आप इस्तेमाल करना चाहते हैं।
3. Integrations और data। वे systems जिनसे SAP को जुड़ना है, माइग्रेट होने वाले data objects और उनकी गुणवत्ता के बारे में आप क्या जानते हैं।
4. आपकी अपनी टीम। आप programme पर किसे लगा सकते हैं, उनके कितने समय के लिए, और आप partner से कौन से roles भरने की उम्मीद करते हैं।
5. Response format। एक तय ढाँचा और page limit, ताकि आप बराबर की तुलना कर सकें।
6. Evaluation criteria और वज़न। Partners को बताइए कि उन्हें कैसे score किया जाएगा। इससे वे उन सवालों का जवाब देते हैं जो मायने रखते हैं।
7. Timetable। सवालों की deadline, bids की deadline, orals की तारीखें और फ़ैसले की तारीख।

आप partners से क्या माँगते हैं

ज़्यादातर SAP RFPs partners से अपने बारे में बताने को कहते हैं, और partners इसमें बहुत अच्छे होते हैं। इसके बजाय ऐसी चीज़ें माँगिए जिन्हें आप जाँच सकें:

1. मिलते-जुलते projects के references। वही SAP products, मिलता-जुलता पैमाना, मिलती-जुलती industry, और एक contact जिसे आप call कर सकें।
2. नामित delivery टीम। CVs, हर व्यक्ति की भूमिका, आपके programme पर उनके समय का हिस्सा और आपकी तारीखों पर उनकी उपलब्धता।
3. ऐसे certifications जिन्हें आप verify कर सकें। SAP certifications को digital badges के रूप में जारी करता है जिनसे real-time verification हो सकता है। Firm के certificates की गिनती नहीं, नामित लोगों के badge links माँगिए।
4. Architecture और प्लान। आपके scope के लिए एक high-level design, और SAP Activate phase के हिसाब से milestones और dependencies वाला प्लान।
5. Phase और role के हिसाब से effort। हर phase में हर role के अनुमानित दिन, सिर्फ़ कुल कीमत नहीं।
6. विस्तृत assumptions और exclusions। हर वह चीज़ जिस पर कीमत निर्भर है, और हर वह चीज़ जिसे वह कवर नहीं करती।
7. Commercial model और rate card। Role और delivery location के हिसाब से rates, travel और expenses, और changes की कीमत कैसे लगेगी।
8. Explore में scope बढ़ने को वे कैसे नियंत्रित करेंगे। नए WRICEF objects को संभालने का उनका तरीका, और उन्हें कौन approve करता है।

Commercial model पर मेरी सलाह है time and materials, जिसमें effort तय और मापा हुआ हो। Phase और role के हिसाब से अनुमानित effort contract में जाता है, ताकि आप हर महीने वास्तविक effort को उसके सामने track कर सकें। RFP में इसे माँगना ही बाद में इसे संभव बनाता है।

Rates पर partners को कोई number देकर प्रभावित मत कीजिए। उनका rate card माँगिए और उसकी तुलना SAP projects के लिए resource allocation planning पर मेरी गाइड की ranges से कीजिए।

Assumptions और exclusions वह हिस्सा हैं जिसे clients statement of work में सबसे ज़्यादा छोड़ देते हैं। अगर RFP उन्हें विस्तार से माँगता है, तो negotiation से पहले ही वे आपके पास होते हैं। SAP statement of work पर मेरी गाइड दिखाती है कि वे contract में कैसे जाते हैं।

Bids आने से पहले वज़न तय कीजिए, और responses पढ़ने के बाद उन्हें मत बदलिए। बाद में वज़न बदलना ही वह तरीका है जिससे किसी पसंदीदा को चुना जाता है और बाद में सही ठहराया जाता है।

जब मैं किसी client को partner चुनने में मदद करता हूँ, तो client references को सबसे ज़्यादा वज़न मिलता है। दो चीज़ें मुझे किसी bid से पीछे हटा देती हैं, उसका कुल score चाहे जो हो: प्रस्तावित resources की कमज़ोर गुणवत्ता, और ऐसा partner जो architecture और प्लान नहीं समझा सकता। Scoring में दोनों दिखने चाहिए।

नीचे की table उन्हीं प्राथमिकताओं पर बना एक उदाहरण वज़न है। Percentages को अपने programme के हिसाब से बदलिए, लेकिन references को पहले रखिए और पीछे हटने वाली दोनों जाँचें बनाए रखिए।

मानदंड	उदाहरण वज़न	ऊँचा score कैसा दिखता है	पीछे हटने का संकेत
References	30%	मिलते-जुलते projects, पहुँच में contacts, references जो partner की भूमिका की पुष्टि करें	किसी तुलनीय project का reference नहीं, या ऐसे references जिन्हें partner आपको call नहीं करने देगा
Resources की गुणवत्ता	25%	प्रासंगिक CVs, verify होने वाले certifications और पक्की उपलब्धता वाले नामित लोग	बिना नाम के roles, कमज़ोर CVs, या मुख्य लोग “उपलब्धता के अधीन”
Architecture और प्लान	25%	आपके scope के लिए design और milestones, dependencies और जोखिमों वाला phase plan	Generic प्लान, या ऐसा design जिसे वे orals में नहीं समझा सकते
Commercial	10%	Phase और role के हिसाब से effort, साफ़ rates, विस्तृत assumptions और exclusions	एक कुल कीमत जिसके पीछे कोई effort नहीं
Approach	10%	Scope control, testing, data और knowledge transfer का साफ़ तरीका	Methodology slides जिनमें आपके लिए कुछ खास नहीं

हर मानदंड को एक सरल पैमाने पर score कीजिए, जैसे 1 से 5, लिखित कारण के साथ। हर evaluator पहले अकेले score करता है, फिर panel तुलना करता है।

पीछे हटने के दोनों संकेतों को gates मानिए, points नहीं। मज़बूत commercials वाली bid कमज़ोर टीम की भरपाई नहीं कर सकती। Commercial का वज़न जानबूझकर कम है: effort और rework के सामने day rate एक छोटा variable है।

लिखित bid दिखाती है कि bid टीम क्या लिख सकती है। Orals दिखाते हैं कि जो लोग काम करेंगे, वे उसे समझते हैं या नहीं।

उन लोगों को नाम से बुलाइए जो सच में आपके programme पर काम करेंगे। Solution architect, programme manager और आपके सबसे बड़े workstreams के leads कमरे में होने चाहिए। अगर partner कोई दूसरी टीम लाता है, तो इसे score में दर्ज कीजिए।

फिर उनसे आपके scope के लिए architecture और प्लान समझाने को कहिए, हो सके तो बिना slides के। काम के सवाल:

1. हमारे दो सबसे जटिल processes का design समझाइए। सुनिए कि क्या आपके process के नाम, आपकी entities और आपके systems आते हैं।
2. अगर Explore में WRICEF list एक-तिहाई बढ़ जाए तो क्या होगा? एक तरीका, फ़ैसले का एक मंच और लागत पर बातचीत सुनिए।
3. आपकी bid की कौन सी assumptions सबसे ज़्यादा जोखिम रखती हैं? जो partner अपना प्लान जानता है, वह उन्हें तुरंत बता सकता है।
4. इस टीम में किसने यह पहले किया है, और कहाँ? फिर reference calls में जवाब जाँचिए।
5. आपको हमारी टीम से क्या चाहिए, और कब? असली प्लान में तारीखों के साथ client dependencies होती हैं।

जो partner कमरे में अपना architecture और प्लान नहीं समझा सकता, वह उसे site पर deliver नहीं करेगा। यही दूसरी वजह है जिससे मैं किसी bid से पीछे हटता हूँ।

मैंने एक programme के दौरान partner बदला है, क्योंकि वह अच्छी गुणवत्ता के resources नहीं दे पाया। अच्छे लोगों की उपलब्धता वह चीज़ है जिसे sign करने से पहले सबसे कड़ाई से परखना चाहिए।

Reference calls

Reference calls अहम हैं, और अक्सर उन्हें औपचारिकता की तरह निपटा दिया जाता है। उन्हें ठीक से कीजिए। References से मैं आपके जैसे projects पर partner के साथ उनके अनुभव के बारे में पूछता हूँ।

Call से पहले reference को अपने programme से मिलाइए: वही products, मिलता-जुलता पैमाना, मिलती-जुलती industry। अगर मेल कमज़ोर है, तो partner से दूसरा reference माँगिए।

Call पर पूछिए कि partner की तरफ़ से काम का नेतृत्व किसने किया, उसने क्या अच्छा किया और कहाँ मुश्किल हुई। फिर पूछिए कि क्या वही लोग आपकी bid में हैं।

Generic जवाब कैसे पहचानें

किसी भी SAP RFP में generic जवाब खतरे का संकेत हैं। जो response किसी भी कंपनी को भेजा जा सकता है, वह किसी भी कंपनी के लिए लिखा गया था।

सबसे तेज़ जाँच यह है कि किसी जवाब में अपनी कंपनी का नाम हटाकर किसी competitor का नाम लगा दीजिए। अगर जवाब तब भी सही पढ़ा जाए, तो वह आपके लिए नहीं लिखा गया था। S/4HANA माइग्रेशन partner चुनने पर मेरी गाइड माइग्रेशन के लिए इस जाँच को और विस्तार से कवर करती है।

RFP response में generic जवाब आम तौर पर इन जगहों पर दिखते हैं:

1. Scope वाला हिस्सा आपका RFP ही आपको वापस सुनाता है। उसमें इस पर कोई राय नहीं होती कि आपके programme में मुश्किल क्या है।
2. प्लान हर phase के लिए गोल अवधियाँ इस्तेमाल करता है। उसमें कुछ भी आपकी entities, data या integrations पर निर्भर नहीं होता।
3. आपके processes के बारे में सवालों के जवाब accelerators के बारे में आते हैं। Tool का नाम होता है, आपके लिए उसके इस्तेमाल का नहीं।
4. जोखिम पूरी industry के होते हैं। “Data quality” और “change resistance” दिखते हैं, और आपके systems से जुड़ा कुछ खास नहीं दिखता।
5. टीम वाले हिस्से में लोग नहीं, roles लिखे होते हैं। यह आम तौर पर कमज़ोर resources वाली ही समस्या है, दूसरे शब्दों में।

Generic जवाब को कम score दीजिए, भले ही वह अच्छी तरह लिखा गया हो।

Partner के documents का आकलन भी वह जगह है जहाँ independent राय मदद करती है। जो advisor bid नहीं कर रहा, वह design और effort के अनुमानों को परख सकता है, और बाद में deliverables को भी। इसके फ़ायदे-नुकसान SAP partner बनाम independent consultant की मेरी तुलना में हैं।

सबसे पहले अपना scope लिखिए। हर process area के लिए एक page, जिसमें लिखा हो कि क्या अंदर है, क्या बाहर है, कौन सी entities हैं और वह किन systems को छूता है। इसके बिना, bids का हर number partner की assumptions पर टिका होता है।

Tier के हिसाब से partners के नामों के लिए मेरी गाइड USA में SAP implementation partners, tier के हिसाब से देखिए।

अगर आप किसी RFP, scoring या मिली हुई bids पर independent राय चाहते हैं, तो मैं organisations की इसमें मदद करता हूँ। आप यहाँ मुझसे संपर्क कर सकते हैं।

SAP implementation RFP में क्या शामिल होना चाहिए?

Partners को अपनी पृष्ठभूमि और उद्देश्य, अपना scope, अपने integrations और data, जो टीम आप दे सकते हैं, एक तय response format, evaluation criteria और timetable दीजिए। उनसे मिलते-जुलते projects के references और CVs के साथ नामित delivery टीम माँगिए। SAP Activate phase के हिसाब से architecture और प्लान, phase और role के हिसाब से effort, और विस्तृत assumptions और exclusions माँगिए।

SAP implementation partner bids को कैसे score करें?

Bids आने से पहले weighted मानदंड तय कीजिए: references, resources की गुणवत्ता, architecture और प्लान, commercial और approach। हर evaluator एक सरल पैमाने पर, लिखित कारण के साथ, अकेले score करता है, फिर panel तुलना करता है। कमज़ोर resources और ऐसे प्लान को जिसे partner समझा न सके, bid को खारिज करने की वजह मानिए, कुल score चाहे जो हो।

SAP RFP कितने partners को भेजना चाहिए?

कम से कम तीन। SAP Partner Finder और SAP के competency tiers से लंबी list बनाइए, फिर प्रासंगिक references वाले partners को shortlist कीजिए।

SAP partner selection में कितना समय लगता है?

लंबी list से contract तक, शुरू से अंत तक लगभग 12 हफ़्ते। RFP खुद उसका सिर्फ़ एक हिस्सा है। Orals, reference calls और जीतने वाली bid को statement of work में बदलने में ज़्यादातर समय जाता है।

SAP RFP में fixed price माँगें या time and materials?

मेरी सलाह है time and materials, जिसमें effort तय और मापा हुआ हो। हर partner से phase और role के हिसाब से अनुमानित effort माँगिए, और उसे contract में लिखिए ताकि आप वास्तविक effort को उसके सामने track कर सकें। जिस एक कुल कीमत के पीछे कोई effort न हो, उसकी न तुलना हो सकती है न tracking।

SAP partner proposal में खतरे के संकेत क्या हैं?

ऐसे generic जवाब जो किसी भी कंपनी पर लागू हो सकें, ऐसा टीम section जिसमें roles हों पर नामित लोग नहीं, ऐसा प्लान जिसमें वही अवधियाँ हों जो आपने कहीं और देखीं, और ऐसा architecture जिसे partner orals में नहीं समझा सकता। जो partner आपको अपने references को call नहीं करने देता, वह एक और चेतावनी का संकेत है।