Preparing SAP/MES Scoping: Questions to Resolve Before the Project

Summary

A definition of SAP/MES scope should not be an extended kick-off meeting. This is the stage where the organization decides what the project really needs to transform, what it needs to secure, what it needs to rule out, and how the value will be measured. In industrial environments, this clarification is critical because an implicit decision can block a line, degrade traceability or create a long-term operating debt.

The scoping must move beyond a catalogue of functions. It must produce actionable decisions: scope, process, data, ERP/MES/OT architecture, governance, risk, resources, testing, change, cutover, support and indicators.

Good scoping does not slow down the project. It prevents launching a design on weak assumptions, and then discovering in testing that real cases have never been discussed.

Clarify the problem before choosing the solution

SAP/MES projects sometimes start with an already implicitly chosen solution: a new MES, SAP DM, an SAP upgrade, shop floor automation, a performance cockpit. The risk is to try to justify the solution rather than to qualify the problem.

The scoping must explain the pain points: lack of visibility, inventory errors, fragile traceability, duplicate data entry, unreliable MRP, delays, scraps, stops, paper, non-conformities, slow release, dependence on Excel. Each pain point must be linked to a measurable impact or avoided risk.

Define an unambiguous ERP/MES/OT border

The boundary between SAP, MES, supervisory control systems, equipment and reporting is often one of the most consequential decisions. It conditions the interfaces, the master data, the level of detail, the operator screens, the application maintenance and the support.

It is necessary to decide where orders, operations, instructions, process parameters, quality controls, consumptions, confirmations, stops, statuses, labels, batches and KPIs are managed. An unclear boundary creates double data entry and recurring debates throughout the project.

Identify the processes and exceptions required for go-live

Scoping workshops often capture nominal flows. However, projects fail on exceptions: component shortage, batch blocked, partial return, consumption correction, change of quality status, unavailable interface, order cancellation, stopped equipment, recovery after incident, urgent shipment.

A definition of the robust scope requires a mapping of critical scenarios and exception scenarios. This makes it possible to size the design, testing, training and hypercare.

Treat data as a condition of commitment

An SAP/MES project is dependent on materials, bills of materials, routings, versions, work centres, resources, batches, equipment, quality plans, units, locations and MRP rules. If this data is unstable, the target system will not create value.

The scoping must assess the quality of the data not as an overall percentage, but by impact on the flows. It must also specify the responsibilities: who corrects, who validates, who maintains, who controls and with what frequency.

Building governance before difficult decisions

Complex decisions will appear: standard or specific, central or local, SAP or MES, automated or manual, pilot or rollout, quality priority or productivity, quick win or foundation. If governance is not defined, these decisions will be delayed or politicized.

The scoping must specify the bodies, decision criteria, decision fees, the RACI, the decision register, risk management and escalation mechanisms.

Defining the expected evidence, not just deliverables

A blueprint, a flow matrix or a backlog is not enough. The scoping must define what evidence will be expected at each milestone: tested scenarios, validated data, trained roles, supervised interfaces, ready support, measured KPIs, documented workarounds.

This changes the project posture: we no longer only seek to produce documents, but to demonstrate an operational capacity.

Decision matrix

This grid can serve as a support for a definition of SAP/MES executive scope.

Anonymised case study

In a definition of MES scope, the initial need was formulated as a request for real-time production tracking. The analysis showed that priority was not the real-time screen, but the reliability of the reporting model: sometimes incomplete orders, non-standardised downtime causes, inconsistent units and lack of rule on post-reporting corrections. The roadmap was reoriented: stabilise data, harmonise causes, define ERP/MES rules, and then only deploy dashboards.

Executive questions

• Does the project respond to a priority industrial problem or a desire for general modernization?
• Are SAP/MES/OT borders explicit enough to avoid duplicates?
• Have shop floor exceptions been identified before design?
• Is data readiness a blocking milestone or an annex site?
• Are the value criteria, go/no-go and hypercare output defined as soon as the scope is defined?

Operational checklist

• Formalize pain points and expected benefits with baseline.
• Map ERP, MES, equipment, reporting and truth sources.
• List nominal scenarios, exceptions and cases of recovery.
• Evaluate critical data, ownership and remediation effort.
• Define governance, decision criteria, testing strategy and hypercare plan.

Conclusion

An effective SAP/MES scoping creates speed because it reduces ambiguities. It turns intentions into decisions, pain points into scenarios, risks into action plans and digital investments into value roadmap. This is the least expensive time to question the status quo.