Most MES projects fail at the floor
The pattern we keep inheriting: a customer bought an MES, configured it, integrated it with their ERP, and three months later the operators are running the line on paper because the MES screens are slower than what they replaced. This isn't an MES product problem — it's a deployment problem, and it's the same one across SAP ME, Siemens Opcenter, Rockwell FactoryTalk, Aveva, and the open-source equivalents.Below is the framing we use to make MES projects stick.
The minimum viable MES, in scope
- Work order management — what's the line supposed to be making, in what order, with what specs.
- Production execution — track what was actually made, by whom, on what equipment, with what materials.
- Quality data capture — link inspection results to the production record.
- Genealogy / traceability — given a finished good, reconstruct what went into it.
- Performance / OEE — uptime, speed, quality losses.
Anything beyond that is scope creep on the first deployment. We've seen MES projects collapse because the first phase tried to include scheduling optimisation, advanced statistical process control, and full integration with maintenance — at the same time. Pick the minimum viable and ship it.
Integration depth, not breadth
A shallow MES that knows only "operator scanned the part" is little better than a spreadsheet. A useful MES needs to read the line:- Equipment status from the PLC — running, fault, idle, planned downtime
- Cycle counts from station counters
- Process variables from SCADA — temperatures, pressures, dwell times
- Operator interactions from HMIs — accept, reject, override
The integration with one PLC + one SCADA system, done well, beats six "integrations" that just write log entries when the operator pushes a button.
The pattern: OPC UA from the PLC / SCADA → MES integration layer → MES core. Not MES talking directly to PLCs.
Operator UI is half the battle
The operator's MES screen has to be faster than the alternative they were using. If logging a part takes more clicks than a paper tally, the paper wins.What works:
- Auto-populate everything possible from PLC data — operator confirms, doesn't enter
- Barcode / RFID for any identification step — never type a serial number
- One screen per task. Don't make operators navigate.
- Failure modes (rejects, rework, scrap) get one click each, not a dropdown menu
- The screen is glanceable from 1 m away
Sit with operators for half a day before designing screens. The two-hour observation always reshapes the design.
Architecture: avoid the integration spaghetti
A fresh MES deployment looks tidy on day one and tangled by month six unless the integration architecture is principled. Patterns that hold up:- One canonical event bus — Kafka, NATS, or even MQTT. All systems publish events; subscribers consume.
- One source-of-truth per entity — work orders live in MES, not ERP and MES with sync. ERP gets read-only views.
- Event sourcing for production records — the history of events is the truth; aggregations are derived. Auditable, replayable.
- Schema versioning from day one — even before you think you need it.
The deployment that survives
- One pilot line for 3 months before scaling
- Operator training that includes the failure modes ("if the MES is down, do this")
- Offline mode — operator can keep working through a 2-hour MES outage
- Reports for plant management within the first week — they have to see value early
- A named owner on the customer side who's responsible for the MES post-handover
One thing we'd never repeat
Customising an MES product to match the customer's existing paper process. The right approach is the inverse: simplify the process to match good MES practice. Customising to fit a bad process embeds the bad process forever.What MES are you running? And — for greenfield projects — has anyone shipped a working open-source-only MES stack at industrial grade?
