Ask any MES consultant what actually blows up a rollout schedule, and it’s rarely the connectivity, the OEE calculations, or the electronic work instructions. It’s a spreadsheet argument in week three about whether “Line 2” or “Cell 2B” is the right level to track downtime against. That argument, multiplied across equipment, materials, and routings, is what turns a planned go-live into a cutover weekend nobody wants to repeat.
Master data modeling is not a preamble to the real work of MES implementation. It is the real work. Configuration, integration, and reporting all sit on top of it, and if the hierarchy underneath is wrong, everything you build afterward inherits that flaw. This is worth treating as its own discrete skill — a workshop with a method, not a checkbox on a project plan.
Why this keeps happening in 2026
A lot of plants are re-doing this work right now, whether they intend to or not. Composable MES platforms are pulling functionality apart into modules that each need their own data contracts. Long-running Plex and Opcenter (and similar legacy MES) environments are being re-platformed or consolidated as companies rationalize their software footprint. In both cases, teams inherit years of accumulated shortcuts, workarounds, and tribal naming conventions baked into the old system’s master data — and the temptation is to just migrate it forward as-is. That’s usually a mistake. A migration project is the best opportunity you’ll get to fix a hierarchy that was never right in the first place, and skipping that opportunity guarantees you’ll be having the same “what level is a line” argument again in a few years.
The ISA-95 distinction almost nobody actually implements
ISA-95 gives you a clean equipment hierarchy on paper: enterprise, site, area, process cell, unit, and below that, equipment module and control module. It’s a good mental model. It is also not a data model you can drop directly into your MES, and that mismatch is where most teams quietly go wrong.
The distinction that gets lost is between the physical equipment hierarchy (what’s actually bolted to the floor) and the functional/process hierarchy (how work actually flows and gets scheduled). ISA-95 assumes you’ll model both and relate them. In practice, most teams build one hierarchy, call it done, and then discover mid-project that scheduling needs a grouping that doesn’t match how maintenance or quality wants to track the same assets. A line might be one physical unit for scheduling purposes but need to be split into three trackable cells for downtime and quality reporting. If you never modeled that distinction explicitly, you end up bolting on parallel structures later — which is exactly the kind of rework that eats a cutover weekend.
The practical question: how granular should equipment levels go?
There’s no universal answer, but there is a defensible way to decide, level by level:
- Line level is right when your business questions are about throughput, schedule adherence, and overall capacity — the questions a plant manager or scheduler asks. If nobody downstream needs to know which specific station caused a stoppage, don’t model it.
- Cell or workstation level is right when you need to attribute downtime, scrap, or cycle time to a specific point in the process — the level a controls engineer or quality engineer actually acts on. This is usually where OEE calculations should live, because line-level OEE numbers tend to hide the actual constraint.
- Asset/component level (a specific motor, a specific tool, a specific PLC-addressable device) is right only when you have a genuine downstream consumer of that granularity — condition monitoring, spare parts management, or a maintenance system that needs to tie failure history to a serial number. Modeling to this level “just in case” is one of the most common sources of master-data bloat, because every asset you model needs to be maintained forever.
A useful test: for every level you’re considering, name the specific report, dashboard, or downstream system that consumes data at that granularity. If you can’t name one, don’t build the level. You can always add granularity later; collapsing an over-built hierarchy after go-live is much harder, because by then transactional data has already been recorded against it.
Material, BOM, and routing: the three legs of the same stool
Equipment hierarchy gets the attention, but material master and routing design fail for the same underlying reason: nobody separates what’s engineering truth from what’s execution truth. Your ERP’s bill of material tells you what parts theoretically go into a product. Your MES routing tells you the actual sequence of operations, at which equipment, with which work instructions and quality checks, that a real order follows on the floor. These are related but not identical, and treating the ERP BOM as if it’s automatically your MES routing is a classic failure mode — especially where alternate routings, rework loops, or engineering changes exist and the ERP was never designed to represent them cleanly.
The workshop discipline here is to walk a handful of representative products — not every SKU, but a deliberately chosen sample that includes your simplest product, your most complex product, and anything with a known rework or alternate-routing pattern — through the full hierarchy together: which material, on which equipment, in which sequence, producing which genealogy record. Doing this on a whiteboard with production, quality, and IT in the room, before anyone opens the configuration tool, surfaces the disagreements while they’re cheap to resolve.
A worksheet you can actually run
For each candidate hierarchy level or material relationship, force the group to answer four questions in writing:
- Who consumes data at this level, and for what decision?
- What breaks in reporting or scheduling if we don’t model it?
- What already exists in ERP or the legacy MES at this level, and does it agree with what we’re proposing?
- Who owns this record going forward — who updates it when a line gets reconfigured or a routing changes?
That last question is the one teams skip most often, and it’s the one that causes hierarchies to rot within a year of go-live. Master data isn’t a one-time deliverable; it’s a governed asset. If nobody owns the update process, the hierarchy you spent weeks getting right on paper will drift from the physical floor within a few quarters, and the next “cutover weekend” will be a self-inflicted one.
The payoff for doing this first
None of this is glamorous work, and it doesn’t show up in a demo. But every downstream capability — genealogy, OEE, scheduling, quality holds, integration with ERP and historian systems — is only as trustworthy as the hierarchy it’s built on. Teams that treat the master data workshop as a real design exercise, with named decision-makers and a documented rationale for every level of granularity, tend to have boring, uneventful cutovers. Teams that skip it are the ones still arguing about what a “line” is six months after go-live, usually while standing in front of a dashboard nobody trusts.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
