SAP implementation RFP: what to ask and how to score

An SAP implementation RFP should ask partners for evidence, not promises: references from similar projects, CVs of the people they will staff, and an architecture and plan for your scope. Score the bids on weights you fix before they arrive, then use orals to check that the delivery team can explain the plan.

Short answer: the RFP is a test of the people and the plan, not of the methodology slides.

This article covers the request for proposal (RFP) stage of the decision only. The full selection process, from long list to contract, is in my guide on how to choose an SAP implementation partner.

Across the 21 SAP programmes I have led or rescued, the biggest mistake I see is not planning properly at the start. An SAP RFP sent before you know your own scope invites every partner to fill the gaps with its own assumptions. Then you cannot compare the bids, because each one prices a different programme.

So the order matters. Define your scope, your processes in and out, your entities and countries, your integrations and your data, then write the RFP around it.

The scope also protects the budget later. Budgets get hit in the SAP Activate Explore phase, where SAP's method runs fit-to-standard workshops and logs gaps in the backlog.

That is where the WRICEF list (workflows, reports, interfaces, conversions, enhancements and forms) grows, and every new object is cost. An RFP built on your scope gives you a baseline to measure that growth against.

Send the RFP to a shortlist of at least three partners.

Build the long list from SAP Partner Finder, where SAP shows the competencies partners hold under SAP PartnerEdge, each in three tiers: essential, advanced and expert. A badge earns a place on the list. It does not earn the contract.

The whole selection takes about 12 weeks end to end.

How the SAP RFP stage runs

1. 01

   Scope

   Write the scope, processes, entities, integrations and data yourself before any partner sees it.

2. 02

   RFP

   Send one pack to a shortlist of at least three partners, with the scoring weights already fixed.

3. 03

   Written bids

   Score each bid against the weights, and flag any generic answer.

4. 04

   Orals

   Ask the proposed delivery team to explain the architecture and plan in person.

5. 05

   References

   Call references on projects like yours and ask about the partner's experience on them.

6. 06

   Contract

   Carry the effort, named people and assumptions from the winning bid into the statement of work.

An SAP RFP has two halves: what you give the partners and what you ask them to send back.

What you give the partners

Give every partner the same pack at the same time. The better the pack, the more specific the answers:

1. Background and objectives. Why you are implementing SAP, what the business must be able to do afterwards, and the dates that matter.
2. Scope. Processes in and out, entities, countries, users by group, and the SAP products you expect to use.
3. Integrations and data. The systems SAP must connect to, the data objects to migrate and what you know about their quality.
4. Your own team. Who you can put on the programme, for how much of their time, and which roles you expect the partner to fill.
5. The response format. A fixed structure and a page limit, so you can compare like for like.
6. The evaluation criteria and weights. Tell partners how they will be scored. It makes them answer the questions that count.
7. The timetable. Deadline for questions, deadline for bids, the orals dates and the decision date.

What you ask partners for

Most SAP RFPs ask partners to describe themselves, and partners are very good at that. Ask instead for things you can check:

1. References from similar projects. Same SAP products, similar scale, similar industry, with a contact you can call.
2. The named delivery team. CVs, the role each person will play, the share of their time on your programme and their availability for your dates.
3. Certifications you can verify. SAP issues certifications as digital badges that allow real-time verification. Ask for the badge links of the named people, not a certificate count for the firm.
4. The architecture and plan. A high-level design for your scope, and a plan by SAP Activate phase with the milestones and dependencies.
5. Effort by phase and role. Estimated days for each role in each phase, not just a total price.
6. Assumptions and exclusions in detail. Everything the price depends on, and everything it does not cover.
7. The commercial model and rate card. Rates by role and delivery location, travel and expenses, and how changes will be priced.
8. How they will control scope growth in Explore. Their method for handling new WRICEF objects, and who approves them.

On the commercial model, I recommend time and materials with the effort quantified. The estimated effort by phase and role goes into the contract, so you can track actual effort against it every month. Asking for it in the RFP is what makes that possible later.

On rates, do not anchor partners with a number. Ask for their rate card and compare it with the ranges in my guide to resource allocation planning for SAP projects.

Assumptions and exclusions are what clients most often leave out of a statement of work. If the RFP asks for them in detail, you have them before you negotiate. My guide to the SAP statement of work shows how they carry into the contract.

Fix the weights before the bids arrive, and do not change them after you have read the responses. Changing the weights later is how a favourite gets chosen and justified afterwards.

When I help a client choose a partner, client references carry the most weight. Two things make me walk away from a bid whatever its total: weak quality in the proposed resources, and a partner that cannot explain the architecture and the plan. The scoring should reflect both.

The table below is an example weighting built on those priorities. Adjust the percentages to your programme, but keep references first and keep the two walk-away tests.

Criterion	Example weight	What a high score looks like	Walk-away signal
References	30%	Similar projects, reachable contacts, references who confirm the partner's role	No reference on a comparable project, or references the partner will not let you call
Resource quality	25%	Named people with relevant CVs, verifiable certifications and confirmed availability	Unnamed roles, thin CVs, or key people "subject to availability"
Architecture and plan	25%	A design for your scope and a phase plan with milestones, dependencies and risks	A generic plan, or a design they cannot explain in orals
Commercial	10%	Effort by phase and role, clear rates, detailed assumptions and exclusions	One total price with no effort behind it
Approach	10%	A clear method for scope control, testing, data and knowledge transfer	Methodology slides with nothing specific to you

Score each criterion on a simple scale, such as 1 to 5, with a written reason. Each evaluator scores alone first, then the panel compares.

Treat the two walk-away signals as gates, not as points. A bid with strong commercials cannot buy back a weak team. Commercial carries a low weight on purpose: day rate is a small variable next to effort and rework.

The written bid shows what the bid team can write. The orals show whether the people who will do the work understand it.

Ask for the people who will actually staff your programme, by name. The solution architect, the programme manager and the leads for your largest workstreams should be in the room. If the partner brings a different team, note it in the score.

Then ask them to explain the architecture and the plan for your scope, without the slides if you can. Good questions to use:

1. Walk us through the design for our two most complex processes. Listen for your process names, your entities and your systems.
2. What happens in Explore if the WRICEF list grows by a third? Listen for a method, a decision forum and a cost conversation.
3. Which assumptions in your bid carry the most risk? A partner that knows its plan can name them at once.
4. Who on this team has done this before, and where? Then check the answer in the reference calls.
5. What do you need from our team, and when? A real plan has client dependencies with dates.

A partner that cannot explain its architecture and plan in the room will not deliver it on site. That is the second reason I walk away from a bid.

I have changed a partner during a programme because it could not provide quality resources. The availability of good people is the thing to test hardest before you sign.

Reference calls

Reference calls are important, and they are often run as a formality. Run them properly. What I ask references about is their experience with the partner on projects similar to yours.

Before the call, map the reference to your own programme: same products, similar scale, similar industry. If the match is weak, ask the partner for another.

On the call, ask who from the partner led the work, what it did well and where it struggled. Then ask whether those people are in your bid.

How to spot generic answers

Generic answers are the red flag in any SAP RFP. A response that could be sent to any company was written for any company.

The quickest test is to replace your company's name in an answer with a competitor's. If the answer still reads correctly, it was not written for you. My guide to choosing an S/4HANA migration partner covers that test for migrations in more detail.

In an RFP response, generic answers usually show up in these places:

1. The scope section repeats your RFP back to you. It adds no view on what is hard about your programme.
2. The plan uses round durations for every phase. Nothing in it depends on your entities, data or integrations.
3. Questions about your processes get answers about accelerators. The tool is named, the use of it for you is not.
4. Risks are industry-wide. "Data quality" and "change resistance" appear, and nothing specific to your systems does.
5. The team section lists roles, not people. That is usually the same problem as weak resources, in different words.

Score a generic answer low even when it is well written.

Assessing the partner's documents is also where an independent view helps. An advisor who is not bidding can test the design and the effort estimates, and later the deliverables. The trade-offs are covered in my comparison of an SAP partner versus an independent consultant.

Write your scope down before anything else. One page per process area, listing what is in, what is out, the entities and the systems it touches. Without it, every number in the bids rests on the partner's assumptions.

For partner names by tier, see my guide to SAP implementation partners in the USA by tier.

If you want an independent view on an RFP, the scoring or the bids you have received, I help organisations with this. You can contact me here.

What should an SAP implementation RFP include?

Give partners your background and objectives, your scope, your integrations and data, the team you can provide, a fixed response format, the evaluation criteria and the timetable. Ask them for references on similar projects and the named delivery team with CVs. Ask for an architecture and plan by SAP Activate phase, effort by phase and role, and detailed assumptions and exclusions.

How do you score SAP implementation partner bids?

Fix weighted criteria before the bids arrive: references, resource quality, architecture and plan, commercial and approach. Each evaluator scores alone on a simple scale with a written reason, then the panel compares. Treat weak resources and a plan the partner cannot explain as reasons to reject a bid, whatever its total score.

How many partners should receive an SAP RFP?

At least three. Build the long list from SAP Partner Finder and SAP's competency tiers, then shortlist the partners with relevant references.

How long does SAP partner selection take?

About 12 weeks end to end, from long list to contract. The RFP itself is only part of that. Orals, reference calls and turning the winning bid into a statement of work take most of the time.

Should an SAP RFP ask for fixed price or time and materials?

I recommend time and materials with the effort quantified. Ask every partner for estimated effort by phase and role, and write it into the contract so you can track actual effort against it. A single total price with no effort behind it cannot be compared or tracked.

What are the red flags in an SAP partner proposal?

Generic answers that could apply to any company, a team section with roles but no named people, a plan with the same durations you saw elsewhere, and an architecture the partner cannot explain in orals. A partner that will not let you call its references is another warning sign.