Postponing MES comes back as ERP development
MES is more than the layer where OEE is calculated. Using an aluminum aging oven, I explain why managing shop floor complexity in MES and sending ERP a summary protects the standard.
Do you need MES? My answer is yes. You need MES even just to keep the ERP lean and to collect the information you need from the shop floor correctly. MES is more than the layer where OEE is calculated. Over the coming weeks I will try to unpack this in a few posts with different examples. This is the first.
A project that starts with clean core
Let’s say we are building a project on SAP Public Cloud. The process starts with a clean core approach: the core will not be touched, standard processes will be used, and any development that is needed will be done at permitted extension points or as a side-by-side application.
On paper, that is a very sound decision. But the further you go into the details of the shop floor, the more the picture changes. Almost every manufacturing process, by its nature, carries its own operational complexity. The standard production confirmation does not carry that complexity, and it was not designed to. MES, postponed to a “later phase” for cost reasons, comes back after a while as development cost inside the ERP.
Let me explain this with a scenario.
An aging oven
Aluminum parts are loaded into an oven for artificial aging. Several products with the same recipe go into the same charge and are held in the oven for hours at around 175 °C, then taken out and sent to hardness testing. Aging determines the final strength of the part; if the temperature or the time falls short, the part does not harden enough.
For the ERP, this much looks simple: one production order, one operation, one confirmation. But most of what matters on the shop floor does not fit into that single line:
- Which product was placed in which zone of the oven?
- In what order did they go in, and how long did they stay?
- How did the temperature of each zone behave over that time?
- How much energy did this charge use, and how should that energy be allocated to the products?
These are not questions of curiosity. A quality problem can come from uneven heat distribution inside the oven or from the zone the product was in. If you do not know the zone, you cannot know the problem.
Where should this complexity be managed?
Let’s look at what it takes if you try to do it inside the ERP. You need to model the oven’s zones somehow, link every product to a zone and a loading time, store and chart the zone temperature data somewhere, and design a screen where the operator scans barcodes at the oven. None of this is standard. Each one is a development, and each development is one more piece to test at the next release upgrade. The harder you try to do it without compromising clean core, the more the project grows with side-by-side applications. Without noticing, you have started writing an MES next to the ERP; it just isn’t called MES.
The better approach is to manage this operational complexity in MES and send the ERP the results that matter for production, consumption, quality and cost.
What stays in MES, what goes to ERP
What the ERP needs is usually summary information tied to cost. When MES packages that information into a compact summary and sends it to the ERP, it helps protect the standard. For the same oven, what each side sees looks roughly like this:
| Detail that stays in MES | Summary sent to ERP |
|---|---|
| Charge number, barcode of every product going into the oven | Production confirmation: production order, quantity completed |
| Each product’s zone and position inside the oven | — |
| Loading order, entry and exit times | Operation duration |
| Second-by-second temperature curves per zone | — |
| Hardness measurements, with the product and zone measured | Quality result: accepted and rejected quantity, rejection reason |
| Energy used over the charge (kWh) | Energy cost per unit |
| Material batches used | Goods issue per batch |
The right column is what the ERP can take in through its standard processes. The left column is detail the ERP never needs to see, but which is essential for running the shop floor.
A quality problem
You see the difference best when there is a problem. Say four of the twelve parts from a charge fail the hardness test.
In the ERP, what you see is this: production order 4711, 12 pieces produced, 4 rejected, reason code “low hardness”. A correct and sufficient record. Cost is calculated, the rejected quantity is taken out of stock, and a rework order is opened if needed.
In MES, what you see is this: all four failed parts were in zone three. That zone’s temperature ran about 15 °C below target for roughly two hours in the middle of the charge, and the parts in that zone were under-aged. The other zones were on target. The problem is not in the recipe or the material, but in one zone of the oven. The maintenance team checks the heating element, and that zone is monitored in the following charges.
To do this analysis in the ERP, you would have had to move all of the detail above into the ERP. Yet all the ERP needs from this analysis is the result: how many pieces, for what reason, at what cost.
“We can do it inside the ERP”
This objection comes up in every project, and technically it is usually true. It can be done. But the question to ask is not whether it can be done, but who will pay for it, and for how long.
Every shop-floor-specific development ties the ERP to the pace of the shop floor. When a new zone sensor is added to the oven, when a new line is set up, when a field changes on the operator screen, the ERP project is reopened. The testing load grows with every release upgrade. And the shop floor user is left with ERP screens, an interface that is not suited to working with gloves on at the oven.
MES exists precisely for this variability. Every change on the shop floor is handled there, and the format of the summary sent to the ERP does not change. The core stays clean because the data reaching the core is already clean.
Conclusion
Clean core looks like an ERP decision, but it is really an architectural decision. If you want to keep the core clean, the shop floor’s complexity needs somewhere to go. That place is MES.
I described a similar situation on the inventory side in my post on MRP and inventory accuracy (in Turkish): getting the right consumption into the ERP also depends on keeping the right records on the shop floor. In the next posts I will continue with other manufacturing scenarios.