How to read a fixed-scope ERP offer
Packaged Cloud ERP implementations — small, medium, large — are how the midmarket buys now. The package is not the risk. The risk is signing one you cannot read.
The question
When a partner offers you a fixed-scope, fixed-price Cloud ERP implementation, what must the offer disclose for its certainty to be real — and which questions separate an honest package from a teaser?
Why packages are winning — and why that is fine
SAP itself packages midmarket Cloud ERP through partner-delivered offerings built on a pre-defined minimum viable scope, and the logic is sound: Public Cloud's fit-to-standard discipline means the standard is the product, so a package is not a discount trick — it is the honest form of the deployment. The economics behind partner-packaged delivery are examined in why SAP sells the midmarket through partners. This page is that article's twin: having read the partner's incentives, now read the partner's package.
The five scope dimensions a serious offer defines
A fixed-scope offer is only as fixed as its dimensions. Whatever the package is called, insist that it states, in writing, its position on all five:
- Processes: which pre-configured end-to-end processes are activated — by name and count, not "core finance and logistics".
- Organisation: how many company codes, plants, countries and languages the initial rollout covers — and what a second country costs in principle.
- Integrations: which standard APIs and pre-built integrations are included, and what happens to everything else on your interface list.
- Data: which migration objects are in scope, how many test loads are included, and — critically — who cleanses the data before it arrives.
- Enablement: how many fit-to-standard workshops, key-user training days and hypercare weeks the package contains, and what your own team is expected to staff.
An offer that leaves any dimension implicit has not fixed its scope — it has deferred the argument to month seven, when your negotiating position is gone.
The exclusions list is the integrity test
Paradoxically, the most trustworthy part of a packaged offer is the list of what is not included. A serious package names its boundaries up front: custom development beyond released extensibility, data cleansing of the legacy estate, legacy decommissioning, organisational redesign beyond role mapping, third-party integrations beyond the listed APIs. Every one of those is legitimate additional work — the question is only whether you learn that before signature or after. If the offer has no exclusions list, write one yourself and ask the partner to sign it; the reaction tells you everything.
Change orders: the mechanism matters more than the price
Fixed scope plus real life equals change orders — that is arithmetic, not cynicism. What you can negotiate up front is the mechanism: who may raise a change, who prices it, what turnaround the pricing has, and which register keeps deviations visible to your steering committee (the governance discipline described in transformation governance). The "minimum viable scope" decision itself is a business decision, and it belongs to you: a package may propose the minimum, but only you can decide it is viable.
Monday-morning questions
- Can we state, from the offer document alone, our package's position on all five scope dimensions?
- Which of our differentiating processes fall outside the packaged scope — and who decided that?
- What does the change-order mechanism look like on paper — and who on our side owns the deviation register?
- Have we compared at least two packaged offers on scope definitions, not just on the number at the bottom?
- What does the package assume about our team's availability — and is that assumption staffed?
Where this sits in the decision chain
Read this alongside partner economics (who is selling the package and why), RISE vs GROW (which commercial construct it lives in), and the licensing decision (what the subscription underneath actually contains). The disciplined path from first conversation to a package decision is the two-week discovery.
Sources
- SAP — Launching SAP GROW Fast for the midmarket (the packaged, partner-delivered minimum-viable-scope model)
- SAP — the PartnerEdge Sell track
Editorial standard: vendor facts, inference and point of view kept separate; no implementation partner is named or recommended, and no prices appear here by design. Published 2026-08-05 · By Andreas BORN.