Ask an MES admin whether their plant follows ISA-95, and nearly all of them will say yes. Ask them to draw the equipment hierarchy their system actually enforces — enterprise, site, area, work center, work unit — and a surprising number will hesitate, then draw something that doesn’t match what’s configured in the software, which itself doesn’t match the P&ID, which doesn’t match how the org chart assigns responsibility. Nobody lied. They just never built the model. They configured a system that references ISA-95 terminology without doing the modeling work the standard actually requires.
This is the quiet failure mode behind a lot of disappointing MES rollouts: OEE numbers that won’t roll up from line to area to site, genealogy queries that dead-end at a work center because a step happened at a work unit nobody defined, work orders dispatched to a resource that doesn’t correspond to anything on the floor. None of that is a software bug. It’s a modeling gap, and it’s almost always present before the first tag ever gets mapped.
What the hierarchy actually is
ISA-95 (formally ANSI/ISA-95, the standard for enterprise-control system integration) defines a physical asset model in Part 2 and elaborates the object model in Part 3. The core idea is a strict containment hierarchy:
- Enterprise — the company itself.
- Site — a physical plant or facility.
- Area — a functional or physical section of the site (a process area, a building, a department).
- Work Center — a grouping of equipment that performs a production function — think a packaging line or a fill-finish suite.
- Work Unit — the actual piece of equipment or resource that does the work: a specific filler, a specific reactor, a specific robot cell.
Each level exists so that data generated at the bottom can be aggregated meaningfully at every level above it, and so that instructions issued at the top (a work order, a schedule) can be decomposed correctly down to the equipment that has to execute it. That’s the entire point of the hierarchy. It’s not a filing system for asset names — it’s the backbone that makes rollup and decomposition mathematically consistent.
When people say “OEE doesn’t roll up,” what they usually mean is: downtime was logged against a work center, but production counts were logged against a work unit underneath a different work center, and the aggregation query has no consistent parent-child path to reconcile them. That’s not an OEE tool problem. That’s a hierarchy that was never actually built — it was implied, informally, by whoever happened to configure each module.
Why teams skip it
Nobody sits down and decides to skip the equipment model. It gets skipped by accretion. A controls engineer names PLC tags based on drawing numbers. A production scheduler sets up “lines” in the ERP based on how shifts are staffed. An MES integrator configures work centers based on what’s convenient for the first use case — usually OEE or downtime tracking — without asking whether that structure will still make sense once genealogy, quality holds, and materials consumption get added later. Each decision is locally reasonable. None of them were checked against a single, deliberately built hierarchy document. A year in, three systems have three incompatible views of “what a line is,” and someone gets asked to explain why site-level OEE doesn’t match the sum of the area-level numbers. It never will, because there’s no single tree they’re both walking.
This is also why the current wave of interest in AI copilots and agentic automation on the shop floor is quietly surfacing the same old problem. An AI agent that’s supposed to reason about “why is Line 3 down” or auto-generate a root-cause summary across a work center depends entirely on a clean, consistent equipment context to reason over. If the underlying model is inconsistent, the agent doesn’t fail loudly — it produces a plausible-sounding answer built on a broken join. Edge historians layered on top of a shaky hierarchy have the same issue: beautiful time-series data, tagged against equipment nodes that don’t nest correctly, which means every rollup built on top inherits the error silently.
Building the hierarchy from a real P&ID and org chart
You don’t need new software to fix this. You need a worksheet, a P&ID, an org chart, and a room with the right people — controls, production supervision, quality, and whoever owns the MES configuration.
Work through it in this order, not the other way around:
1. Start from the site, not the equipment
Write down the site boundary first. If the plant has multiple legal entities or reporting sites feeding one enterprise system, resolve that now — it determines how far up your rollups can legitimately go.
2. Define areas by process flow, not by department
Areas should map to how material physically moves — mixing, filling, packaging, warehousing — because that’s what genealogy and OEE aggregation actually depend on. Org-chart departments are a trap here; a department can span two process areas, and if you model areas around reporting lines instead of material flow, genealogy traceability breaks the first time material crosses a departmental boundary mid-process.
3. Walk the P&ID to find real work centers
A work center is a grouping of equipment that together performs one production step and can be scheduled as a unit. On the P&ID, this usually corresponds to a skid, a line segment between buffer points, or a cell boundary. The test: could you issue one work order against this grouping and have it make sense to a supervisor? If the answer requires splitting the group, you’ve found two work centers, not one.
4. Push equipment identity down to the work unit only where individual identity matters
Not everything needs to be its own work unit. A work unit should exist where you need to track that specific asset’s state, performance, or genealogy contribution independently — a specific filler head, a specific reactor vessel with its own batch history. If you’ll never query “show me every batch that touched Reactor 2 specifically,” you may not need Reactor 2 modeled separately from its work center. Over-modeling is a real cost too: it creates configuration and maintenance burden with no reporting payoff.
5. Cross-check against the org chart last, not first
Once the physical hierarchy is drawn, map responsibility and shift ownership onto it. This tells you who signs off on data at each level, but it should never dictate the boundaries themselves.
The tell-tale downstream symptoms
If you’re troubleshooting an existing MES rather than starting fresh, these symptoms almost always trace back to hierarchy modeling, not configuration bugs:
- OEE won’t aggregate cleanly across shifts or lines — usually two work centers are modeled at inconsistent levels of granularity, so weighted averages don’t mean what they appear to mean.
- Genealogy traces dead-end mid-process — a transformation happened at a work unit that was never defined, so the system has no node to attach the event to.
- Work orders route to the wrong resource — the work order was written against a work center, but dispatch logic actually needs a work unit, and the mapping between them was never made explicit.
Each of these is fixable, but retrofitting a hierarchy after a year of production data has accumulated against the wrong structure is a genuinely painful, multi-team reconciliation effort — far more painful than the modeling session would have been before go-live. That asymmetry is the whole argument for doing this work up front. It’s a whiteboard exercise before configuration, or a data-migration project after it. Those are not the same size of task.
The standard itself hasn’t changed and doesn’t need to. ISA-95 Part 2 and Part 3 have been stable reference points for a long time. What’s changed is that AI-driven tools and edge analytics are now sitting directly on top of whatever hierarchy already exists, with far less human judgment in the loop to catch a broken rollup before it turns into a confident-sounding wrong answer. That’s the real reason this unglamorous modeling step deserves fresh attention now — not because the standard is new, but because the cost of skipping it just went up.
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.
