Everyone in this industry has seen the ISA-95 pyramid. Level 4 on top, ERP, business planning. Level 3 in the middle, MES, manufacturing operations management. Level 0 through 2 at the bottom, the actual equipment and control systems. It’s a fine picture for a slide deck. It has taught an entire generation of manufacturing engineers almost nothing about how to actually structure their data.
That’s the uncomfortable truth behind a lot of MES pain. Teams absorb the layer diagram, nod along, and then go build work order tables, routing tables, and production reporting screens completely ad hoc — because nobody ever showed them the object model that ISA-95 Part 2 and Part 3 actually define underneath that picture. Then, six months into a rollout, they hit a wall: the ERP says a job should take a certain amount of time with a certain crew, the shop floor reports something else entirely, and there’s no clean way to compare the two, because the two were never modeled as comparable things in the first place.
The distinction that does all the work
ISA-95 Part 2 splits manufacturing operations information into two fundamentally different categories: operations definition and operations response. Get this one distinction into your head correctly and half of the “pyramid” stuff starts making sense as something more than an org chart.
Operations definition is the “what should happen” side. It’s the template — the recipe, the routing, the standard. It answers: given this product, what process segments are required, what personnel classes and equipment classes are needed, what material specifications apply, and how long should each step reasonably take. Operations definitions are relatively stable. You write them once and reuse them across many production runs.
Operations response is the “what actually happened” side. It’s the record of a specific execution — this shift, this operator, this machine, this lot of material, starting at this timestamp and ending at that one, consuming these actual quantities and producing that actual yield. Operations responses are generated fresh every time, tied to one specific instance of production.
Most homegrown MES data models collapse these two things into one flat “work order” table with a status field. That collapse is the root cause of an enormous share of the genealogy gaps and OEE reporting headaches that plague mid-market plants. You cannot cleanly compare planned to actual if planned and actual live in the same row of the same table, overwritten as the job progresses.
The four resource models Part 2 gives you
Underneath both definition and response, ISA-95 Part 2 defines four resource categories that show up again and again: personnel, equipment, material, and process segment. Each one has a capability side and an actual side, which mirrors the definition/response split at the resource level.
- Personnel — capability is “which qualified operator classes can run this segment” (a certification, a skill class); actual is “which specific person ran it, on this shift.”
- Equipment — capability is “which equipment class or which specific asset is qualified for this segment” (rated capacity, tooling, calibration status); actual is “which specific piece of equipment executed it, and for how long.”
- Material — capability is a material specification or bill of material entry; actual is a specific lot or serial number consumed or produced, with real quantities.
- Process segment — capability is the standard step definition (nominal duration, required resources); actual is the segment as it actually executed, with real start/end times and real resource ties.
Part 3 then wraps these into the higher-level manufacturing operations management activities — scheduling, dispatching, execution management, tracking — but the resource model underneath doesn’t change. It’s the same personnel/equipment/material/segment structure, just orchestrated.
One work order, walked through the model
Take a plausible work order: produce a batch of a coated metal part, routed through cutting, coating, and inspection.
The operations definition, generated from the ERP’s production order and the engineering routing, says: process segment “Coating” requires equipment class “Coating Line B or equivalent,” personnel class “Certified Coating Operator,” material spec “Substrate Grade 4, min 2mm,” and a standard duration of, say, forty minutes per hundred units. This is the plan. It exists before a single unit moves.
Now the job actually runs. The operations response for that same segment records: Coating Line B, Operator ID 4417, lot number CG-2291 of the actual substrate consumed, an actual start time, an actual end time, and an actual output quantity plus scrap. None of that data has anywhere to live if your schema only has one “work order” record with a routing step and a status flag. You either lose it, cram it into a free-text comment field, or bolt it onto a downstream report that nobody trusts because it was reconstructed after the fact from timestamps in three different systems.
This is exactly where genealogy tracing breaks. Genealogy is fundamentally a question about operations response — which specific lot, on which specific equipment, run by which specific person, produced which specific output. If your system only ever stored the definition side (the routing) and treated the response side as a status update, you have no real genealogy. You have a plan with a checkbox.
It’s also where OEE math quietly goes wrong. Availability, performance, and quality are all comparisons between definition (planned cycle time, planned run time) and response (actual cycle time, actual downtime, actual scrap). If those two things aren’t distinct objects with a clean relationship, your OEE numbers are being computed against whatever was overwritten last, not against a real baseline.
Why this matters more right now
A lot of plants are mid-evaluation on MES right now, particularly in the mid-market, where composable and modular MOM platforms are being pitched hard as lighter-weight alternatives to the traditional monolithic suites. That’s a reasonable direction to explore. But re-platforming means re-modeling, and teams that skip straight to configuring screens without first drawing out their own definition/response object model tend to reproduce the exact same ad hoc structure in a new tool with a nicer UI. The tool changes. The underlying schema sin doesn’t.
A diagnostic worth running on your own system
Before you touch a vendor’s configuration screen, take one real work order and ask, for each process segment: where does the plan live, where does the actual result live, and are those genuinely two different records with a foreign key between them, or is it one record that gets overwritten? If you can’t answer that cleanly for personnel, equipment, and material, you’ve found where your genealogy and OEE numbers are lying to you. That’s not a reporting bug. It’s a schema decision made too early, and it’s worth fixing before you build one more dashboard on top of it.
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.
