Presales — RFP Template
A no‑nonsense structure for discovery and vendor responses.
RFP Template — Presales Deliverable
Cover Page
Title: Request for Proposal – [Project Name]
Customer: [Insert Customer Name]
Vendor: [Insert Vendor / Issuer]
Date: [dd/mm/yyyy]
Reference: [Unique RFP ID]
Instruction: Keep it professional: customer logo, project title, confidentiality note.
1. Introduction & Background
Purpose of this RFP: State why the RFP is being issued.
Introduce the customer and industry.
Provide context (current IT, current problems).
Link to business drivers (growth, compliance, efficiency, cost).
Example (Coffee Producer):
Global Coffee Producers Ltd. operates in 15 countries with SAP ECC 6.0 as its ERP backbone. With market expansion and stricter EU sustainability reporting, the existing system no longer meets business needs. This RFP invites vendors to propose solutions for migration to SAP S/4HANA.
Tip: Keep factual. Avoid marketing fluff.
2. Project Objectives
Define what the business wants to achieve.
Business objectives: measurable outcomes (shorter order cycles, fewer duplicates, lower costs).
Technical objectives: system migration, data governance, new integration layer.
Strategic alignment: how this project supports long-term business goals.
Method: Use SAP Value Management framing: Driver → Capability → Outcome.
3. Scope of Work
In Scope
- Core processes (e.g. O2C, P2P, Finance).
- Systems/modules (e.g. S/4HANA, MDG, BTP, SAC).
- Deliverables (config, integration, training, reporting).
Out of Scope
- Legacy decommissioning.
- End-user UI redesign.
- Full historical data migration (if not required).
Boundaries
- Vendor responsibility vs customer responsibility.
- Explicit assumptions (e.g. “customer provides clean data”).
Methods:
- Fit-to-Standard (SAP Activate): stress use of standard processes first.
- Domain-Driven Design: split domains clearly (Sales, Logistics, Finance).
4. Requirements
Break down requirements by category:
- Functional: process coverage, master data, reporting.
- Technical: S/4 migration, APIs, Event Mesh, integration flows.
- Compliance: industry-specific, regional regulations.
Method: Use MoSCoW prioritization (Must, Should, Could, Won’t).
5. Boundaries & Assumptions
Document explicit assumptions.
What is assumed about data, systems, people.
What customer will provide.
Example:
- Only active data migrated.
- Customer SMEs available for workshops.
- Distributor API documentation will be delivered.
Tip: Explicit assumptions = fewer disputes later.
6. Risks & Challenges
Identify key risks upfront.
Template table:
| Risk | Impact | Probability | Mitigation | Responsibility |
|---|
Methods:
- Use TOGAF risk matrix (probability × impact).
- Categorize: technical / organizational / compliance.
7. Solution Options (Decision Logic)
Show customer you are not pushing one option blindly.
| Option | Logic | Benefits | Limitations | Fit |
|---|---|---|---|---|
| Lift & Shift | Quick migration | Fast go-live | Keeps technical debt | ✗ |
| Hybrid | Partial move to S/4 | Lower risk | Higher integration overhead | △ |
| Full S/4 + MDG + BTP | Standardization, governance, modern integration | Long-term value | Higher upfront cost | ✓ |
Tip: This section demonstrates transparency and builds trust.
8. Vendor Response Instructions
Vendors must provide:
- Solution architecture and roadmap.
- Fit/Gap analysis.
- Implementation methodology (SAP Activate, Agile/Hybrid).
- Risk and mitigation approach.
- Proposed team roles + certifications.
- Effort & cost estimate.
- References (similar projects).
Tip: Give them tables/templates to fill → easier to compare.
9. Evaluation Criteria
Define how proposals will be scored.
Typical model:
- Solution Fit — 30%
- Methodology & Roadmap — 20%
- Team Expertise — 20%
- Risk Management — 15%
- Commercials — 15%
Method: Weighted scoring model. Publish it in the RFP.
10. Decision Log
Record key project decisions so far.
# Topic Decision Status Notes
Tip: Keeps transparency and avoids “we never agreed that” moments.
11. Time & Cost
Implementation Timeline
Vendors must provide roadmap aligned to SAP Activate phases.
| Phase | Duration | Deliverables | Dependencies |
|---|
Effort Estimation
Request split by role (Architect, Functional, Integration, ABAP).
| Role | Days | Notes |
|---|
Cost Estimate
Vendors must show pricing model (T&M / Fixed / Hybrid).
| Item | Model | Estimate | Assumptions |
|---|
Tip: Require assumptions for every cost figure. Prevents later “out-of-scope” claims.
12. Next Steps
Define key dates:
- Questions deadline
- Proposal submission deadline
- Vendor presentations
- Final decision
Tip: Keep timelines realistic but firm.
13. Appendices
- Current system landscape diagram
- Target architecture vision
- Fit/Gap template
- Glossary (SAP + industry terms)
- Reference methods (SAP Activate, DDD, TOGAF)
Recommendation
1. Before the Meeting
I write down:
- What is the client’s real problem?
- What do I think is true (but must check)?
- What do I not know yet?
- What is the minimum scope that still gives value?
- How ready is the client (old ECC, S/4, API, cloud)?
👉 If I cannot explain these points in short, I do not understand the case.
2. How I Argue
- I speak about results, not only tools. Example: not “Use Event Mesh,” but “This reduces downtime.”
- I compare options. Example: “IDoc works, but it has weak monitoring. API gives better error handling.”
- I admit trade-offs. Example: “Kafka gives speed, but also cost and complexity.”
- I ask back questions. Example: “Why do you want real-time — is it speed, scale, or just trend?”
👉 Good presales = clear trade-offs, no magic promises.
3. When They Push Back
- Stay calm.
- Use numbers, not adjectives — “Saves 2 FTE,” not “more efficient.”
- Mention risks first — “Yes, master data quality is a risk. That’s why we add cleansing workshops.”
- Never overpromise — better: “This needs PoC.”
- Handle scope creep — “That is possible, but let’s put it in phase 2.”
4. How I Choose Options
API vs IDoc vs Event
- API → synchronous, need instant answer.
- IDoc → legacy, batch, async is fine.
- Event → real-time async, many consumers.
Standard Config vs ABAP
- Standard first.
- ABAP only if real value is bigger than cost.
PoC vs Rollout
- PoC for new tech, high risk.
- Rollout when solution is proven.
5. Risks and Boundaries
- Risks: dirty data, weak legacy, missing client people.
- Boundaries: what is not included — “We do not clean data.” “UI redesign is excluded.”
- Mitigation: workshops, pilots, phased rollout.
👉 Clear limits build more trust than overselling.
6. Questions I Always Ask
- What is the most critical process?
- Where is the main pain: speed, cost, risk?
- What does success look like for you?
- What if you do nothing?
- How do we measure success (time, money, people)?
7. My Sources
- SAP Activate → project method.
- SAP Value Management → how to talk about benefits.
- Domain-Driven Design → split systems into domains.
- Event Mesh docs → async integration.
- TOGAF → risk management.
8. My Rules
- Never oversell.
- Always show value.
- Use diagrams, not long text.
- Be the first to name the risk.
- Always close with a next step.
