A note for program directors and enterprise architects.
Most people reading this have seen a selection go wrong. The proposal was clean, the references answered the phone, and the price was competitive. Then the build started, and the system that took shape did not match the design documents. Some key consultants named in the proposal rotated off earlier than expected. The estimate turned out to assume conditions that did not hold in your landscape.
That outcome often gets blamed on a poor partner. More often, however, it is preprogrammed into how the RFP was written. The document evaluates firms based on a description of a system that does not exist yet. We don’t know yet what we don’t know. It is often written in broad strokes, which gives rise to grey areas and misunderstandings. The partner may have perfectly followed the RFP, but the expectations of the customer are that much more in the periphery, which is “obvious.” It usually is not. The gap shows up during the build phase, when countless surprises and arguments surface, and changing course is expensive. That is when the dreaded words “Change Requests” often surface.
This guide covers what to put in an S/4HANA RFP and, where it matters, what the document cannot settle on its own. The focus is on the parts of a selection that consistently cause trouble.
Decide the transformation approach before anything else
Before you write a single requirement, decide the migration approach. It governs every section that follows.
Greenfield, brownfield, and bluefield are different programs with different risk profiles, timelines, and skill requirements. A pure brownfield conversion carries your custom code, historical data, and accumulated configuration into S/4HANA. That lowers business disruption but carries forward technical debt. A greenfield build gives you a clean process design and a clean core, at the cost of a heavier change effort. Bluefield sits between the two and gives you the benefits of each, but it is not as easy to scope because the value depends on more detailed transparency.
If you have already made this decision, state it and the reasoning. If you have not, say so and ask each vendor to recommend an approach with the tradeoffs spelled out for your situation in the RFP. The quality of that recommendation is one of the better early signals you will get. A firm that recommends brownfield for every client, or greenfield for every client, is describing their delivery model rather than your situation. (For a closer look at how to weigh these paths, see SAP S/4HANA Migration Strategy: Beyond Greenfield vs. Brownfield.)
Being specific on scope saves millions
Scope ambiguity is where overruns start. A firm that cannot price your scope cleanly will either underbid to win or pad the estimate to cover the unknowns. You pay for both.
Be specific about the dimensions that actually move cost and risk.
Make it absolutely clear what processes need to be implemented. This is where we have seen that fuzziness leads to significant expenses down the road.
Clean core and extensibility. Say how custom code will be handled. Ask each vendor how they will assess your existing Z-code, what they expect to retire, and how new extensions will be built, in-app/ABAP versus side-by-side on BTP or other mechanisms. A firm with a real position will have a method for this. If you’re working within a RISE with SAP contract, ask specifically how the vendor applies SAP’s own clean core methodology to your environment rather than treating it as a slide in the deck.
Integration. Name the integration points and the middleware. SAP PI/PO is near the end of mainstream maintenance, so if you are still on it, the RFP should ask how the vendor handles the move to Integration Suite. List the non-SAP systems that must connect and the protocols involved. Most scope disputes in these programs trace back to integration behavior that nobody modeled at selection.
Data migration. State your position on historical data, since carrying years of it is a common and avoidable cost driver. Ask about the migration and archiving approach, reconciliation, and how many mock loads and cutover rehearsals are included. The number they commit to tells you how seriously they take the riskiest chapter of the program.
Functional and geographic scope. Separate must-have capabilities from enhancements, and call out bespoke development. Specify locations, languages, rollout sequence, and which entities go first. A firm with strong single-region delivery may not have the model for a phased multi-country rollout. Ask directly.
Name the team and control the substitution
The most consistent complaint in SAP delivery is that the people who sold the work are not the people who did it. Senior consultants close; junior staff deliver. This is even more prevalent today as there is a severe shortage of SAP talent in the industry. The RFP should state that you want to see who will actually deliver.
Specify how scope expansion would work
Ask each finalist to model a scope expansion and explain the effect on cost and timeline. The specificity of the answer tells you sometimes more than the base proposal.
A firm that says it would need to assess that is telling you the estimate was not built on your environment. A firm that can name which modules carry the risk, which integrations are sensitive to change, and which roles would extend has worked through your configuration rather than templating a response. Pair this with a requirement that vendors disclose the risks they see in your landscape and how they would handle each. The firm that raises real problems in the proposal is showing you who arrives in week twelve.
The limit the RFP cannot pass
A good RFP improves your odds. It does not remove the core problem, which is that every firm you evaluate is describing a system that does not exist. You are committing to a multi-year program based on an account of what the system will do, and the distance between that account and the running system usually appears during the build, when the schedule has no slack and rework is expensive. The traditional sequence, months of design before configuration begins, is what makes that distance costly.
This is the gap LeapGreat closes, and it can even help you generate a detailed RFP.
LeapGreat runs a high-speed 3-week Phase 0, resulting in an RFP:
1st Week rapid assessment, 2nd Week S/4 System Build based on the assessment. 3rd Week Digital Twin of your future with full interactivity
This culminates in what we call a DAY 1 Dress Rehearsal to capture feedback.
Then we generate a very detailed RFP for your situation. Ready to start? Get started here.
Rather than committing to a multi-year scope on paper, you enter the build holding a working baseline, evidence of where your environment diverges from the standard, and estimates grounded in what the system actually requires. Your system integrator still runs the implementation. The difference is that the program is governable from the start, and the surprises that normally surface late have already surfaced.
This approach can save literally millions due to RFP ambiguity.
Contact Us
If you’re preparing an S/4HANA RFP and want a working baseline before you commit to a multi-year scope, visit leapgreat.com or go straight to Get Started to submit your project details and hear back from the team.
