Ask ten MES vendors if their product is “ISA-95 compliant” and nine will say yes without blinking. Ask them which part of ISA-95 they mean, and the conversation slows down considerably. That gap is not an accident. ISA-95 is a multi-part standard, and the part everyone has actually seen — the pyramid with Level 0 through Level 4 — is Part 1. It’s the easiest part to draw on a whiteboard and the least specific about what your software actually has to do. Part 3, the detailed activity models for manufacturing operations management, is where the standard gets real. And it’s the part almost nobody in a sales cycle has read past the table of contents.
This matters more this year because RFPs are full of composable MES architectures and AI-augmented modules, and “ISA-95 compliant” has become a checkbox rather than a claim anyone verifies. If you’re evaluating a system, you need to know the difference between a vendor citing the standard and a vendor having implemented it.
What Part 1 actually promises (and what it doesn’t)
ISA-95 Part 1 gives you the functional hierarchy: enterprise planning at the top, MES/MOM functions in the middle, and control systems at the bottom. It defines the boundary between business systems (ERP) and plant floor systems, and it names the categories of information that flow across that boundary — production schedules, production performance, material use, and so on. It’s a reference model, not an implementation spec. A vendor who says their MES “sits at Level 3 and integrates with Level 4 ERP” is describing an architecture position, not a set of behaviors. That’s a true and useful statement, but it’s also the lowest bar in the entire standard. Almost any MES on the market clears it.
What Part 3 actually requires
Part 3 breaks manufacturing operations management into detailed activity models, organized around four operational domains — production, maintenance, quality, and inventory — each decomposed into activities that must interact through defined information flows. The standard groups these into what practitioners generally refer to as eight operations activity categories:
- Resource management — tracking and allocating personnel, equipment, and material resources against defined capability
- Definition management — maintaining the master data for products, processes, and specifications that other activities consume
- Detailed scheduling — sequencing operations against resource and material constraints at the execution level, not the planning level
- Dispatching — releasing work orders and instructions to resources in real time, and reacting when conditions change
- Execution management — managing the actual work in progress, tracking status against the dispatched instruction
- Data collection — capturing actuals from equipment, personnel, and material use as work happens
- Tracking — maintaining genealogy and history, tying collected data back to specific lots, orders, or units
- Performance analysis — turning collected and tracked data into KPIs, variance analysis, and comparisons against plan
The point of Part 3 isn’t the list itself — it’s that each of these activities has defined inputs, outputs, and information flows to the others. Dispatching depends on detailed scheduling output. Performance analysis depends on data collection and tracking being wired together correctly. A system that does resource management and data collection but has no real detailed scheduling activity, and no defined flow connecting scheduling to dispatching, is not implementing the Part 3 model — it’s implementing pieces of it, disconnected.
Where the gap actually shows up
In practice, most commercial MES platforms implement execution management, data collection, and tracking reasonably well — that’s the core of “recording what happened on the floor,” and it’s also the easiest thing to demo. Detailed scheduling and dispatching are where implementations get thin. Plenty of systems have a work-order list and a sequence field, and call that scheduling. Real detailed scheduling, per the Part 3 model, accounts for resource capability, material availability, and constraint-based sequencing, and it produces an output that dispatching actually consumes and reacts to. If your “schedule” is a static list a supervisor manually reorders every shift, you have a manual process wearing a Part 3 label.
A checklist for reading the claim against your configuration
When a vendor or your own MES admin team says the system is ISA-95 compliant, push past the pyramid diagram and ask to walk the activity model against actual configuration. A few concrete questions do most of the work:
- Can you show me the configured object or module that performs detailed scheduling, and what constraints it actually evaluates?
- When a schedule changes, what system-level event fires into dispatching — is there an actual information flow, or does a person manually re-enter data?
- Is resource management tracking capability (skills, certifications, equipment states) or just availability (busy/free)? Part 3 expects the former.
- Does performance analysis pull from the same tracked genealogy data collection produces, or is it a separate reporting layer built on a different data path?
- Ask for the specific Part 3 activity names in the sales deck. If the material only shows the Part 1 pyramid, that’s informative on its own.
None of this means a vendor is misrepresenting anything on purpose. “ISA-95 compliant” is a loosely policed phrase, and most people using it — including plenty of experienced MES architects — mean “aligned with the general model,” not “every Part 3 activity flow is fully instantiated.” That’s a legitimate and common posture. The problem is only when a buyer hears “compliant” and assumes full activity-model coverage, then discovers during integration that detailed scheduling doesn’t actually exist as a distinct function, or that dispatching is really just execution management with a different label on the UI.
Why this matters more with composable architectures
Composable MES pitches — swap in a scheduling module here, a quality module there — make this worse before it makes it better. When functionality is split across separate vendors or microservices, the Part 3 information flows between activities become integration work, not built-in behavior. A composable stack can absolutely implement the full Part 3 model, but only if someone has explicitly designed the flows between, say, the scheduling service and the dispatching service. That’s an architecture decision your team has to verify, not a property that comes for free because each component individually claims ISA-95 alignment.
The standard was written to give manufacturers a common vocabulary for operations management activities, not a marketing badge. Reading past Part 1 costs you an afternoon with the standard’s activity diagrams. It’s a good afternoon to spend before you sign anything that says “ISA-95 compliant” in the executive summary and nothing more specific anywhere else.
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.
