Your ERP is not losing this comparison. It is not entered in it.
An ERP plans, costs and settles. An MES records what the machines did. Almost every plant that asks us this question ends up with both, so the useful question is not which one: it is where the boundary between them sits.
An ERP on its own is enough when
- Output is declared per order or per shift, and nobody needs to know what happened inside it.
- Stops are rare, long and already recorded by maintenance.
- The questions the plant asks are about cost, stock and delivery, not about why a line ran short.
Add an MES beneath it when
- The question is why a line ran short on Tuesday, and the ERP holds one number for the shift.
- Someone keys the floor’s sheets into the ERP every morning.
- Stops, reasons and rejects need to be recorded by machine, as they happen.
Most plants run both: the ERP plans and settles, the MES records execution and posts the results back.
The same five questions, asked of both.
Every row describes what each system does, not which one wins. Read them as a map of the boundary rather than as a scorecard.
| ERP | VZIAM | |
|---|---|---|
| What it is for | Planning, costing and settling: orders, materials, labour and the ledger. | Recording execution: machine states, stops, reasons and units produced. |
| The grain of the record | One posting per run or per shift, which is the right grain for costing. | Every state change on the machine, which is the grain a stop analysis needs. |
| Where the data comes from | Transactions entered by people, or interfaces from systems fed by people. | Machine controllers, plus operator declarations for reasons and rejects. |
| When it is available | Once the posting is made, which is usually at the end of a run or a shift. | As the shift runs, with the ERP posting following as work is declared. |
| How they work together | Holds the plan, the materials and the cost of what was made. | Pulls the orders down, posts the results back, and keeps the detail underneath them. |
The cost is in the gap, not in either system.
What follows is what happens when an ERP is asked to cover the floor because nothing else does.
A day’s worth of detail for a minute’s worth of question
An ERP records a shift’s output as a posting. Asking it why a line ran short on Tuesday means asking a system that holds one number per shift a question about four hundred events, and it does not have them because it was never meant to.
Somebody keys the floor into the plan
The connection between what was made and what the ERP believes was made is usually a person with a stack of sheets. Until they have finished, the planning system is describing a factory that does not exist; afterwards it describes one that existed yesterday.
Shop floor screens bolted onto a planning system
Custom ERP transactions built to capture downtime tend to be slow, generic and disliked, because the system underneath them is transactional rather than continuous. The declarations then arrive late and rounded, which is the outcome the project was meant to prevent.
The other comparisons.
Plan the change before it reaches the line.
Request a demo and an engineer looks at how your production runs today, shows how the software would fit around it, and where a pilot on one line would start.
01Pick a time
Choose a slot in the calendar, and note what you make and what reads your machines today.
02Screen shared with an engineer
A video call with someone who builds the software, in English or French.
03What would connect
For each machine, its path: native (OPC UA, MQTT or HTTP push), through a gateway, or nothing to build.