Every MES project kicks off with a kickoff meeting, and every kickoff meeting has a slide with the ISA-95 pyramid on it. Enterprise on top, control systems on the bottom, MES in the middle. Everyone nods. Then the team spends a week building an equipment hierarchy in a spreadsheet, imports it into the platform’s configuration tool, and never looks at it again until something breaks in production eighteen months later.
That’s not a software problem. It’s a modeling problem. ISA-95 (formally ANSI/ISA-95, aligned with IEC 62264) gives you the vocabulary and the relationships—Part 2 defines the object models, Part 3 defines the activity models that operate on them—but it doesn’t tell you how granular your equipment hierarchy should be for your plant, or where your material model should split. Those are judgment calls, and they’re the ones that determine whether your MES stays useful or turns into a maintenance burden.
Start with what the hierarchy is actually for
The Part 2 equipment hierarchy exists to answer three questions repeatedly, for the life of the system: where did this happen, what ran through it, and who or what did it. Every level you add should make one of those questions easier to answer. Every level you skip should be a level you’ve deliberately decided doesn’t need its own identity in the model.
The standard hierarchy runs enterprise, site, area, process cell (or production line), unit, and equipment module, with work centers and work units as the ISA-95 activity-model equivalents used in Part 3 scheduling and performance objects. That’s a lot of resolution, and the first mistake most teams make is treating all six levels as mandatory. They’re not. ISA-95 explicitly allows you to collapse levels that don’t add distinguishing information in your plant.
The granularity question, answered by a rule instead of a guess
Here’s the practical test: model a level of equipment separately only if you need to collect data, track state, or attribute quality/genealogy at that level independently of its parent. If your line has four machines but you only ever report OEE and downtime at the line level, you don’t need machine-level equipment modules yet—you need a line-level unit and you can add child equipment modules later without breaking anything upstream, because the hierarchy is meant to be extensible downward.
Go the other direction and the failure mode is just as common: teams build equipment modules down to individual sensors or actuators because that’s what the SCADA tag list looks like. That’s a control-system decomposition, not a manufacturing operations decomposition. ISA-95 equipment modules should map to something a production supervisor would recognize and reference on the floor—a filler, a labeler, an oven zone—not to I/O points. If your hierarchy has more nodes than your operators have names for things, you’ve over-built it.
Material class vs. material definition: where teams actually get stuck
This is the single most common conceptual trip-up in Part 2 modeling. A material class is a category—raw resin, corrugate, a family of fasteners, “12oz PET bottle.” A material definition is a specific, orderable, trackable thing within that class—a specific resin grade from a specific supplier with a specific spec sheet, or a specific SKU of bottle. Material lots and sublots are instances of a material definition that exist in physical reality on a specific date, in a specific location, with specific genealogy.
The mistake is building material definitions that are really material classes in disguise—say, defining “Steel Coil” as a material definition when the plant actually runs a dozen distinct gauges and alloys through the same equipment, each with different process parameters. Six months later, someone needs to attach different acceptable-range specs to each gauge, and the model can’t support it without a rework. Conversely, some teams define a material definition for every supplier lot number, which turns the material master into a lot table and makes the ERP integration (material definitions typically sync from or to your ERP material master) unmanageable.
The right split mirrors how your quality and process engineers actually think about substitutability: if two materials can be used interchangeably in a work instruction without a process change, they belong in the same material definition with lot-level tracking underneath. If swapping them changes a recipe parameter or a spec limit, they’re different material definitions, possibly under the same material class.
Personnel and segment models: where the standard goes thin
Part 2 gives you a personnel model—person, person class, qualifications—and most implementations use maybe a third of it. That’s usually fine; the personnel model earns its keep mainly where you have hard qualification gating (certified welders, forklift licenses, line-specific training sign-offs) that needs to block a work order from starting. If your plant’s labor rules are simple, don’t over-model this. Where teams get burned is the opposite: building elaborate personnel hierarchies with shift, crew, and role objects nobody in HR or payroll systems asked for, duplicating data that already lives cleanly in a workforce management system and now has to be kept in sync by hand.
The segment models—process segment in Part 2, operations segment and its scheduling equivalents in Part 3—are where a lot of Part 3 adoption stalls, and it’s worth naming why. A process segment is meant to be a reusable, ISA-88-flavored building block: a chunk of work with defined equipment, material, and personnel requirements that gets assembled into a full production or process definition. In practice, most MES teams model segments once, as a mirror of a single product’s routing, and never reuse them, which means they’ve built routing steps with extra ceremony rather than actually getting the reuse and standardization the model is supposed to deliver. If you’re not going to reuse segments across products or lines, don’t force the abstraction—model the routing directly and revisit segmentation once you have two or three genuinely similar product families to standardize.
B2MML is a wire format, not a design spec
B2MML (Business To Manufacturing Markup Language) is the XML schema implementation of the ISA-95 object models, and it’s worth understanding the distinction: B2MML doesn’t tell you how granular your equipment hierarchy should be, it just gives you a standard way to serialize whatever hierarchy you’ve already designed so ERP, MES, and scheduling systems can exchange it without custom mapping for every integration. Teams sometimes back into their data model by looking at what B2MML’s schema elements support, which gets the sequence backwards. Design the hierarchy against your actual operational questions first; use B2MML (or your platform’s native equivalent) as the transport once the model is right.
A practical build order
If you’re starting from scratch or rebuilding, work in this order rather than trying to fill in the whole pyramid at once:
- Map your physical areas and process cells/lines first—this rarely changes and gives you stable anchors.
- Add units and equipment modules only where you need independent state or data collection, using the “would a supervisor name this” test.
- Build material classes around interchangeability, not around supplier catalogs.
- Add personnel qualification objects only where they gate work orders, not as an HR mirror.
- Leave process segments alone until you have a genuine reuse case across two or more products.
The hierarchy you ship in week one of an MES project is never the final hierarchy—it can’t be, because you don’t yet know what week fifty-two’s reporting requirements will look like. What you’re actually deciding in week one is how expensive it will be to change your mind later. Build to the granularity your operational questions require today, structure material and personnel objects around real distinctions rather than convenient ones, and leave yourself room underneath each node to add detail without restructuring the tree above it. That’s the whole discipline. The standard just gives you the nouns.
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.
