One sentence each: SCADA controls the process and shows it in real time, an MES walks the order across the shop floor and accounts for it, and ERP plans resources, orders material and issues the invoice. They overlap because all three can now record output — they differ in why they do it and at what time resolution. Below: the boundaries, a table of where functions overlap, and a practical answer to where to start in a twenty-machine plant.
Three systems in one table
| Criterion | SCADA | MES | ERP |
|---|---|---|---|
| Answers the question | What is the machine doing now? | How is the order going and why is it stopped? | Do we have material, people and money? |
| Time resolution | seconds and milliseconds | minutes and shifts | days and months |
| Main user | operator, maintenance | supervisor, production manager | planner, purchasing, finance |
| Data source | controllers and sensors | SCADA, controllers, operator | MES, warehouse, people |
| What you lose if it fails | control and visualisation | accounting and traceability | planning and settlement |
The ISA-95 levels
The ordering every vendor refers to comes from ISA-95. It has five levels:
- Level 0 — the physical process: motors, valves, sensors.
- Level 1 — direct control: PLCs, controllers, safety circuits.
- Level 2 — supervision: SCADA and HMI, alarms, trend archiving.
- Level 3 — manufacturing operations: orders, output accounting, quality, batch traceability, indicators. This is where an MES lives.
- Level 4 — enterprise planning: ERP, purchasing, finance, sales.
The model is useful not because it is true in every plant — it is not — but because it lets you name the boundary. When two vendors argue about who records scrap, the question is simply: at which level should that number be created, and who owns it?
What SCADA does
SCADA supervises the process: it collects signals from controllers, displays plant state, handles alarms, archives process trends and lets the operator change a setpoint. It works at second resolution and it is the only one of the three that actually influences the machine.
What SCADA usually does not do: it does not know the production order, how many parts were planned for the shift, and it neither accounts for material nor keeps product genealogy. A trend archive is not production history — you can reconstruct that a temperature dropped at 14:20, but not which batch it belonged to. Plenty of plants calculate OEE from SCADA data, and that is a sensible start as long as somebody owns the definitions described in our OEE guide.
What an MES does
An MES walks the order across the shop floor: it receives it from ERP, assigns it to resources, records output and scrap, collects downtime reasons, calculates indicators, handles quality checks and batch traceability, and returns the settlement to ERP. The resolution is minutes and shifts, and the user is the supervisor, not the control-room operator.
In practice, two very different things are sold under one name. The narrow one is production monitoring: output, downtime with reasons, scrap, OEE, andon, shift report — and that is all. The broad one adds scheduling, product genealogy, recipe management and workstation documentation. The price difference can be tenfold, so say plainly at the first meeting which of the two you need — we break the cost down in what a production monitoring system costs.
What ERP does
ERP plans and settles the business: orders, stock, purchasing, costs, HR, finance. It has a production module, and that is the source of most of the confusion — the module can issue an order and accept a completion report, but it usually accepts it once per shift and from a human hand.
That is enough to cost the order and not enough to run the floor. ERP will not notice twelve four-minute micro-stops, will not tell a material shortage from a breakdown, and will not report that the machine ran at 82% of its nominal rate. If your question is "what did this order cost us", ERP answers. If it is "why did it take six hours longer", it does not.
Where they overlap
| Function | Best placed in | Also capable | Watch out for |
|---|---|---|---|
| Output recording | MES | ERP (manual), SCADA (counter) | two sources of truth for one number |
| Downtime recording | MES | SCADA (alarms without reasons) | an alarm is not a downtime reason |
| OEE | MES | SCADA, spreadsheet | one set of definitions for the whole plant |
| Scheduling | ERP or APS | a broad MES | two schedules mean no schedule |
| Batch traceability | MES | ERP (at order level) | resolution: batch versus part |
| Stock and material | ERP | MES (line-side buffers) | duplicated stock levels |
The rule that saves the most trouble: every number has one owner. If output is created in the MES, ERP accepts it and does not allow manual correction; if it is created in ERP, there is no point calculating it a second time on the floor. Plants that try to keep both versions spend the first year after go-live reconciling the difference.
Where to start in a twenty-machine plant
- You have ERP and no idea where the machine hours go. Start with production monitoring on the bottleneck. Lowest cost, fastest effect, no interference with back-office processes.
- You have SCADA and spreadsheet reports. Do not buy a second visualisation. Add the order-accounting and downtime-reason layer on top of what you already collect.
- A customer requires batch traceability, or you get complaints you cannot reconstruct. This is the one case for going straight to a broad MES — genealogy cannot be added retrospectively.
- You have neither ERP nor monitoring. ERP first, then the floor. The other order ends with a system that measures production beautifully without anyone knowing whether it was needed.
In every variant the first step is the same workshop: agreeing planned time, nominal cycle, the stop threshold and the list of downtime reasons. Without it you are buying software rather than knowledge.
Integration: OPC UA and the responsibility boundary
The standard for moving data between the control layer and the production layer is OPC UA — vendor-independent, with an information model and security built in. With Simatic controllers it is used directly; older installations are connected through a gateway. Exchange with ERP normally runs over an API or an intermediate database, in agreed time windows.
The technical part is rarely the problem. The responsibility boundary is, so the contract should state four things: who owns each data field, which way each piece of information flows, what happens when the link is down for eight hours, and who pays for changes on the ERP side. Where the integration reaches the controllers, it makes sense to close it together with PLC, HMI and SCADA programming, while the data-collection layer is described on the production monitoring and OEE page.