When to Integrate IoT with MES, ERP and CMMS, and When Alerts Should Become Work Orders
DBR77 Team · Published
Integrate IoT with your CMMS first, once machine states and stop reasons have been stable for a few weeks, then with MES, and with ERP last. An alert should become a work order only when it needs parts or planning, keeps repeating, or takes longer than a time limit you set; everything else stays a quick task on the shift.
Integrate too early and you copy unreliable data into three systems. Integrate too late and maintenance keeps retyping stops by hand. Below: the order that usually works, what to keep apart, and the work order rules.
Where IoT sits next to MES, ERP and CMMS
The ISA-95 standard is a useful map. It splits a plant into levels by the activities done at each one. Level 3 covers manufacturing operations, where MES and similar systems manage production. Level 4 covers running the business, where ERP sits. ISA-95 primarily deals with the interface between levels 3 and 4.
Machines, PLCs and sensors sit below, at levels 0 to 2. IoT reads them and turns raw signals into events: running, stopped, a stop reason, a count. In most plants the CMMS sits at the operations level next to MES, where maintenance work is planned. IoT feeds trusted events upward; it does not replace the systems above it.
Why waiting a few weeks pays off
The first weeks of IoT on a line are noisy. Reason lists change and thresholds are tuned. Connect ERP in week two and every correction must be fixed twice. Our article on the first 30 days of IoT in a brownfield factory describes that settling period.
A line is ready to integrate when these conditions hold:
- Production and maintenance use the same definitions of running, stopped and planned stop.
- The reason list has not changed for two to three weeks.
- "Unknown" is small, for example below 10% of downtime minutes.
- Every alert has an owner and a time to acknowledge.
- IT/OT has agreed the interface and security model, usually with reference to ISA/IEC 62443.
The integration order that usually works
Start with the CMMS. It removes the most manual work for the fewest fields: machine, fault, time and owner. MES comes next. Counts and live OEE from IoT can replace manual entries per order once they match what the line really produced. ERP comes last. It needs aggregated, closed records, and those only exist once the line data has settled.
| System | What IoT sends | When to integrate | Typical trigger |
|---|---|---|---|
| CMMS | Fault events, run hours, cycle counts, condition values | First, once alert routes and reasons are stable | Stop over a time limit, repeat fault, counter reaches a service interval |
| MES | Machine states, good and scrap counts, stop reasons, live OEE | Second, after IoT counts match the line's real output | Order start and end, changeover, count per order |
| HSE | Near-miss events from cameras or sensors | When the safety team has defined categories | Person in a restricted zone, guard opened while running |
| ERP | Aggregated output, asset hours, consumption | Last, after MES or CMMS hold the closed record | Order or shift closure, monthly asset costing |
See an alert turn into a work order
In a 30-minute online demo we show how a machine stop is captured, routed to an owner and, when the rules say so, opened as a work order.
What to integrate and what to keep separate
A useful split:
- Integrate one asset list. The machine ID must be the same in IoT, CMMS and MES.
- Integrate work order creation and closure. When a work order closes, the downtime record in IoT should carry its number.
- Integrate counts per order with MES, once they are trusted.
- Keep raw signals at the edge. High-frequency current or vibration values stay in IoT; ERP gets only aggregates.
- Keep micro-stops and reason picking in IoT. They change often and should not wait for an ERP release.
Use open interfaces. OPC UA and MQTT cover the machine side; REST APIs usually cover the business side. McKinsey advises companies to specify interoperability as a buying criterion. Our integrations page lists the connectors we support.
When an alert should become a work order
Vorne notes that minor stops typically last a minute or two and are cleared without maintenance personnel. Turning each into a CMMS record buries planners in tickets.
An alert should open a work order when at least one of these is true:
- It needs parts or materials that have to be ordered or picked.
- It needs planning: a shutdown window, a contractor, a permit or a second shift.
- It repeats. For example, the same fault three times in seven days on one machine.
- It takes longer than a set limit, for example a stop over 20 minutes.
- It needs a formal record for safety, quality or an audit.
Everything else stays a quick task on the shift: logged, owned, timed and closed in IoT. Illustrative example: on a typical two-shift packaging line, a jam cleared in three minutes is a quick task. If the same jam comes back four times in one shift, it becomes a single work order to inspect the guide rails. Write the limits down with maintenance and review them monthly.
How this works in DBR77 IIoT and IRIS
In DBR77 IIoT, every alert becomes a task with an owner, and the response is time-stamped. On one corrugated-packaging line, that rule plus live status and reason capture cut average response time to a stop from 24 to 9 minutes. Why machine alerts fail on the shop floor explains what happens without that structure.
In DBR77 IRIS, a machine or camera event lands in the same data model as everything else. From there it can open a CMMS work order, log an HSE near-miss or feed OEE, without a separate interface for each.
Clean states and counts can also feed a digital twin of the line to test changes before they reach the floor. How signals then change priorities and plans is covered in From visibility to closed-loop response.
FAQ
Finance wants ERP data first. Should we start there?
Usually not. ERP needs closed records, which are reliable only after the line data has settled. Give finance a weekly export from IoT in the meantime.
Do we need an MES before we start with IoT?
No. Many mid-size plants start with IoT on one line and the CMMS they already have. IoT can supply live OEE and stop reasons until an MES is in place.
How do we stop the CMMS from filling up with tickets?
Use the work order rules above and review them monthly with maintenance. If planners close many work orders as "no action needed", the limits are too low.
Which interfaces are needed?
OPC UA, Modbus or MQTT on the machine side and standard APIs on the business side. Security reviews usually refer to ISA/IEC 62443, and processing can stay on site.
Conclusion
Pick the line whose reason list has stayed the same longest and connect it to the CMMS with only four fields: machine, fault, time and owner. Before the first work order goes through, agree the limits with maintenance in writing, for example a stop over 20 minutes or the same fault three times in seven days. After a month, count how many work orders planners closed as "no action needed" and adjust the limits from there.
Map your integration order in one call
Bring your system list: CMMS, MES, ERP. In 30 minutes we sketch which data goes where, in what order, and which alert rules to start with.
Sources
- ISA, ISA-95 Standard: Enterprise-Control System Integration
- ISA, ISA/IEC 62443 series of standards
- OPC Foundation, OPC Unified Architecture, 2008
- OASIS, MQTT Version 5.0, 2019
- McKinsey & Company, IoT value set to accelerate through 2030, 2021
- Vorne, The Six Big Losses
- DBR77 IIoT pilot data, corrugated-packaging line (client anonymous), 2026