What Should an SAP S/4HANA Cloud Discovery Assessment Deliver?
Written by Scheer Nederland specialists. Updated 8 September 2026.
A discovery assessment for SAP S/4HANA Cloud, Public Edition should deliver a decision you can defend, not a brochure. When it ends you should be able to state in writing which business outcomes the ERP serves and who owns them, which end-to-end processes go live first, what stays out of scope, where the standard fits and where it does not, which integrations and countries are in play, and what the phased route to production looks like. If any of that is still open, the assessment has not finished its work.
Business outcomes and named owners
A business outcome is a measurable change in how the company operates: shorter order-to-cash handling, one view of margin, an entity that can report on its own. The assessment turns each outcome into a process scope and an owner, because a scope item without an owner has nobody to decide on it once design workshops start. An outcome stated only as "modernise the ERP" cannot be tested against a solution. Ask for the register as a table: outcome, process, accountable person. Aligning management, process owners, key users and IT early is one of the ingredients Scheer points to for a successful SaaS ERP implementation.
Current landscape and end-to-end processes
The current landscape is the set of applications, integrations and manual workarounds that carry the business today. The assessment records what runs where, what data each system owns and which handovers are manual, because those handovers are where a new design either simplifies the business or repeats its history.
Scheer works from end-to-end processes rather than modules: order-to-cash, source-to-pay, plan-to-produce, design-to-operate, record-to-report and hire-to-retire. Functionality in SAP S/4HANA Cloud, Public Edition is activated through scope items assembled into a working end-to-end process, so describe the process first and the scope items second, as the process-led transition approach sets out.
Scope now, scope later
Scope now is what a first go-live must support; scope later is what the business expands into once people are working in the system. Splitting the two is the most useful decision an assessment makes, because the solution can be extended step by step rather than in one large release.
Decision guidance: place a process in "now" when a go-live without it would stop the business from invoicing, buying, producing or closing the books. Place it in "later" when a documented interim way of working is acceptable for a defined period. Write that interim way of working down; an undocumented "we will handle it manually" is a risk, not a plan.
Fit-to-Standard and the clean core
Fit-to-Standard is the method in which the standard process is shown in the system and the business decides whether it can adopt it as is. It should produce fits, non-fits, and a named route for every non-fit: adopt the standard, change the business practice, resolve it through configuration, resolve it on the platform, or place it out of scope. Non-fits recorded without a route reappear later as unplanned work.
The clean core keeps that discipline valuable. Because the solution receives updates on SAP's release cycle, keeping extensions outside the core protects your ability to take those updates. An assessment that proposes to solve many non-fits with deep modifications is telling you something about product fit, and that deserves attention before anything is signed.
Integrations, countries and entities
Integrations and SAP BTP
Integration scope is the list of systems and services that must exchange data with the ERP, each with a direction, a trigger and an owner. Scheer builds these on the SAP Business Technology Platform, including Two-Tier ERP scenarios alongside an existing SAP ECC or SAP S/4HANA environment. Interfaces discovered after the design phase are a common source of unplanned effort.
Countries and legal entities
Country and entity scope drives localisation, reporting and rollout sequence. Record which countries and legal entities use the ERP now and which follow later: a template built for one country and rolled out afterwards is a different design from one built for several at once. SAP's Digital Discovery Assessment tool, used in Scheer's Discovery Assessment, asks this alongside functionality and integrations.
Data, testing, authorisations and change
These four workstreams decide whether a correct configuration is usable on day one. The assessment names who cleans which master data objects, who writes and runs test cases, which roles and authorisations are needed, and who prepares the users. These are business responsibilities, not partner deliverables, and naming them early is what makes the plan realistic. Scheer's implementation approach based on SAP Activate treats data management, testing, integration, extensibility, solution adoption and analytics as explicit components; expect the output to line up with them.
A phased roadmap
The roadmap is the final deliverable: ordered phases, each with a scope, the dependencies it clears and the decisions it needs from the business. It follows the SAP Activate phases of Prepare, Explore, Realize, Deploy and Run, and shows where the release cycle and the three-system landscape affect your sequence. A roadmap with dates but no dependency logic is a wish list.
Deliverables checklist
- Outcome register: outcomes, target processes, named owners.
- Landscape map: applications, data ownership, interfaces, manual handovers.
- End-to-end process scope per stream, expressed as scope items.
- Scope split into now and later, with reasoning and any interim way of working.
- Fit-to-Standard result: fits, non-fits, and a route per non-fit.
- Clean core position: what is configured, what is extended, and where extensions live.
- Integration register: system, direction, trigger, owner, platform.
- Country and entity scope with rollout sequence.
- Data, testing, authorisation and change effort with named business owners.
- Phased roadmap with dependencies, decision points and open risks.
- An explicit statement of what was not assessed.
Frequently asked questions
- How does a discovery assessment differ from a fit-gap analysis?
A fit-gap analysis compares requirements against a solution and produces a gap list. A discovery assessment does that and settles the questions around it: which outcomes the ERP serves, which integrations and countries are in scope, and what the phased route to production is. The gap list is one input to it.
- What should we prepare before the assessment starts?
Bring a systems and interface overview, a description of your main end-to-end processes, your legal entity and country structure, the owner of each process, and the reason you are considering a move now. Preparation lets the workshops start on your situation instead of on basic facts.
- What happens when a required process does not fit the standard?
Every non-fit gets a named route: adopt the standard, change the business practice, resolve it through configuration, resolve it on the SAP Business Technology Platform, or place it out of scope with an interim way of working. An unrouted non-fit becomes unplanned work during realisation.
- Who from our organisation should take part?
Process owners for each end-to-end stream, finance, IT for the landscape and integrations, and a decision maker who can settle scope questions in the room. Key users add the operational detail senior stakeholders often miss. Scheer runs the assessment as interactive workshops, so participation determines the quality of the result.
Scheer Netherlands has focused on SAP SaaS ERP since 2012 and on SAP S/4HANA Cloud, Public Edition since 2017, as an SAP Expert Partner. More about Scheer Netherlands.
