Key takeaways
In a typical plant the OEE system watches the line and the CMMS watches the asset. Both see "downtime," but each sees a different version of it. The OEE side captures every stop above some threshold. The maintenance side only captures the ones that became work orders. The gap between those two numbers, usually 20% to 40% of total downtime, is where small recurring losses live. Those small losses are also where most of the achievable improvement sits.
The reason the gap exists is not that one team is doing the wrong work. It is that the two systems have no shared definition of "this stop needs a work order." The operator decides, the supervisor decides, sometimes nobody decides, and the rules drift line by line. A maintenance operating model is the set of explicit rules that turn each OEE event into a binary outcome: a work order opens, or it does not.
An OEE system without a clean loss-class taxonomy is just an aggregate timer. The operating model starts by collapsing every stop into a stable set of classes, usually seven to ten. Common ones: changeover, micro-stop, minor mechanical, electrical/sensor, material starvation, quality reject, planned overrun, operator-driven. The exact list is less important than that the same list is used everywhere, every shift, every line. The piece on manufacturing KPIs covers the underlying KPI families this taxonomy plugs into.
Each class needs a rule: at what duration or frequency does this event become a work order? The thresholds are almost always wrong on day one and get tuned in weeks two through six. What matters is that the rule exists and is visible. Examples of typical first thresholds:
Cluster threshold rules ("3 times in 8 hours") tend to catch the small recurring losses that single-event thresholds miss. They are the single highest-yield rule type to add.
Every loss class has one named owner, not a department. Minor mechanical and electrical go to the maintenance manager. Changeover and operator-driven go to the production manager. Material starvation goes to the planner. Quality reject goes to the quality manager. The owner does not necessarily perform the fix, but they own the trend and the threshold. When a class is overshooting, the owner moves first.
The most important and most-skipped rule. When an OEE event auto-opens a work order, two things must happen the same minute: the maintenance technician sees the work order on a mobile device, and the OEE record is linked to the work order so closure flows back. Without that two-way link, the operating model degenerates into "OEE creates noise, CMMS ignores it" within a quarter. A field-ready CMMS on the technician's phone is what makes this work. The article on work order management systems goes deeper on the moving parts.
Because cluster thresholds catch the same fault firing three times before anyone would have noticed it, the small recurring losses, the ones currently invisible, start showing up on the maintenance backlog with a real fix path. Most plants find that this category alone often accounts for a large share, frequently 15-25%, of unplanned downtime once exposed. See the deeper treatment in our root cause analysis in manufacturing article.
When every relevant OEE event becomes a work order, the CMMS finally sees the full population of failures. MTBF and MTTR start reflecting reality instead of the subset that operators or supervisors decided to escalate. The downstream effect is that preventive maintenance schedules can be tuned against real failure data instead of vendor recommendations.
Because the OEE event and the work order share an ID, the production manager and the maintenance manager are looking at the same row. The morning meeting goes from "whose number is right" to "which loss class moved last week." That single change is the operational unlock most mid-market plants are after when they buy an OEE system, and it almost never comes from the OEE software alone.
A common mistake is shipping 30 trigger rules at go-live. Half are wrong, all of them create noise, the maintenance team disables the integration in week three. Start with five or six rules. Add one per week based on what is being missed.
If the work order closes but the OEE event stays "open" in the loss register, the OEE numbers and the CMMS numbers drift apart again, sometimes within weeks. Closure has to flow both ways. This is where many bolted-together OEE-plus-CMMS stacks fail in practice.
If a class fires a work order but no named owner watches the trend, the work order gets done, the loss recurs, and nothing changes. The named owner is what turns volume into improvement.
The operating model above can be implemented on any well-instrumented stack, but the practical reason mid-market plants struggle to make it work is that an OEE tool and a separate CMMS rarely share a clean event/work-order link. Fabrico was built around this exact handoff: every OEE event lives in the same database as the work orders, the asset hierarchy and the loss taxonomy, so the trigger rules and closure paths exist by default rather than as a custom integration. If you want to see how a unified model looks against your own line data, book a demo and we will walk through it.
No, but the closure-path problem is hard to solve cleanly across two separate systems. Plants on split stacks usually need a middleware layer or a manual reconciliation step that erodes within a quarter. A unified platform removes that risk.
Five or six. The temptation is to define every rule on day one; the reality is that most rules need 4-6 weeks of real data before the threshold is right. A small starting set tuned over the first quarter beats a complete set deployed cold.
Operationally, the plant manager. The maintenance manager and production manager each own classes. Without a single plant-level owner of the model itself, the thresholds drift, the named owners rotate without handoff, and the model decays.
Very little at first. The operator still logs stops the same way. What changes is that the system now decides whether each stop becomes a work order, so the operator does not have to make that judgement call shift by shift. Over time the operator sees fewer recurring small losses because the trigger rules catch them earlier.
Two numbers: the share of unplanned downtime that has a linked work order (target: above 80% within 90 days), and the rolling count of work orders generated by cluster-threshold rules (should stay non-zero, if it goes to zero, the rules are no longer catching anything new).
Connexion
Blog
