ISA-95 Explained: A Practical Guide to ERP and MES Integration

ISA-95 explained: models, levels, use cases and implementation guide

Manufacturing teams rarely struggle because they lack systems. They struggle because each system was bought, configured or inherited for a different purpose.

ERP tracks orders, inventory and finance. MES tracks production execution. SCADA and HMI track the process in real time. PLCs and DCSs control machines and lines. Quality, maintenance, warehouse and laboratory systems add their own data models on top. None of that is unusual. The real problem is that these systems usually describe the same factory in different ways.

That is where ISA-95 matters.

ISA-95 is not just another automation standard to mention in architecture slides. It gives manufacturers a shared model for defining how enterprise systems and control systems relate to each other, what information should move between them, and how to describe equipment, materials, personnel and production activities in a way that reduces ambiguity. In practice, it helps teams stop building custom one-off integrations for every plant, every vendor and every programme.

If you work in industrial automation, manufacturing IT, digital transformation or plant systems architecture, ISA-95 is one of those standards worth understanding properly. Not because you will quote every clause, but because many integration decisions become clearer once you have its mental model in place.

What ISA-95 is, in plain terms

ISA-95 is an international standard for integrating enterprise and control systems in manufacturing. It is also aligned with IEC 62264, which is the international framework used to structure the same problem space.

At a practical level, ISA-95 helps answer questions such as:

Which business activities belong in ERP and which belong closer to production?
What should a plant system report to the business, and how often?
How should production capability, schedule, material usage and performance be represented?
How do we model equipment and operations in a way that is consistent across plants and vendors?

Without a standard model, every integration becomes an interpretation exercise. One plant’s “line” is another plant’s “area”. One MES vendor’s “operation” is another vendor’s “work centre step”. One ERP implementation assumes batch completion at shift end, while the plant needs near-real-time reporting at order phase level. These differences sound small until they start breaking planning accuracy, traceability or OEE reporting.

ISA-95 provides structure for that mess.

Why ISA-95 became important

Manufacturing systems evolved in layers, but not always in a coordinated way.

Business systems were designed for planning, procurement, costing and customer commitments. Control systems were designed for deterministic operation, safety and process control. Manufacturing operations sat in the middle, often managed by plant-specific software, spreadsheets or vendor tools. Over time, companies tried to connect all of this.

The first wave of integration was mostly bespoke. Point-to-point connectors, flat files, database scripts and middleware bridges were common. They worked, until scale entered the picture. Then the same problems appeared again:

inconsistent naming across plants
duplicated master data
unclear ownership of process logic
schedule changes that did not map cleanly to actual production states
quality and genealogy data trapped in line systems
maintenance and operations using different asset structures
reporting that looked precise but was semantically inconsistent

ISA-95 emerged as a way to bring discipline to that interface between enterprise and plant operations.

What matters here is not the standard as paperwork. What matters is the separation of concerns it introduces. That separation is still useful even in modern architectures built with APIs, event brokers, cloud platforms and industrial data hubs.

The ISA-95 level model

The best-known part of ISA-95 is the hierarchical level model. It is often shown as a pyramid, though that visual can be oversimplified if people start treating it as a rigid technology stack. Still, it remains useful as a decision model.

ISA-95 level 0 to level 4

Level 0: The physical process

This is where the actual production happens. Material is transformed physically or chemically. Machines move, valves open, conveyors run, products are assembled, mixed, heated, packed or tested.

Level 0 is not software. It is the process itself.

Level 1: Sensing and manipulating the process

This includes sensors, actuators, drives and instrumentation that interact directly with the physical process. Temperature transmitters, pressure sensors, motor starters, valve positioners and barcode readers all sit close to this level.

Level 1 tells the system what is happening and enables direct action on the process.

Level 2: Monitoring and supervisory control

This is where PLCs, DCSs, SCADA systems and HMIs are commonly placed. These systems coordinate control logic, supervisory monitoring, alarms, recipes at certain scopes, and operator interaction.

Level 2 is concerned with running the process reliably and safely in real time.

Level 3: Manufacturing operations management

This is the layer most often associated with MES or MOM. It manages production operations, quality operations, maintenance operations and inventory operations within the manufacturing context.

Typical Level 3 responsibilities include:

detailed production scheduling or dispatching
electronic work instructions
WIP tracking
batch or lot genealogy
quality checks and holds
performance tracking
labour tracking
production declarations
resource status management

This is the most contested layer in many programmes because vendors overlap, and companies often have half-built capabilities spread across MES, custom apps, historian layers, quality tools and spreadsheets.

Level 4: Business planning and logistics

This is where ERP typically operates. Order management, procurement, high-level production planning, finance, enterprise inventory and broader supply chain processes are usually here.

Level 4 is not meant to manage machine states in real time. It is meant to manage the business of manufacturing.

The point of the level model is not hierarchy for its own sake

A common misunderstanding is to use ISA-95 levels as if they mandate a single monolithic stack or prohibit modern architectures. They do not.

The value of the level model is this: it helps decide where a function belongs and what timescale it operates on.

For example:

A PLC should not be waiting on ERP to decide whether a conveyor can run.
ERP should not be calculating second-by-second machine states.
An MES should not replace core financial inventory valuation logic.
A cloud dashboard can consume Level 2 and Level 3 data, but that does not mean cloud systems should directly own control functions.

That sounds obvious, but projects often blur these lines under pressure. Once that happens, responsibility becomes unclear. You see duplicate business rules, conflicting production counts, and operational decisions delayed by enterprise workflows that were never designed for plant realities.

The four operations models inside ISA-95

ISA-95 goes beyond levels. One of its more useful contributions is the operations model at Level 3. Instead of treating MES as one vague middle layer, it breaks manufacturing operations into four domains:

production operations management
maintenance operations management
quality operations management
inventory operations management

This is important because real factories do not run on production execution alone.

A line can be on schedule and still fail because maintenance status is wrong. A batch can be completed and still blocked because quality disposition is pending. Inventory can exist physically and still be unavailable because the system has not reconciled status, location or lot attributes.

Production operations management

This covers dispatching, execution, tracking, resource allocation and performance reporting. It is what most people mean when they casually say MES.

Maintenance operations management

This covers managing equipment capability, maintenance requests, work coordination and plant-level maintenance status in the context of operations.

The distinction matters. Enterprise EAM may own master maintenance plans, budgets and asset lifecycle records. But plant operations still need real-time maintenance status to know whether a line, vessel or machine can be scheduled.

Quality operations management

This covers inspections, testing, non-conformance handling, quality results and release or hold decisions tied to production.

If quality exists only as a post-production reporting layer, traceability suffers. ISA-95 treats quality as part of operational management, not just downstream analysis.

Inventory operations management

This covers material movement, status, location, lot handling and inventory visibility within manufacturing operations.

This is where many ERP–MES integrations become awkward. ERP may own inventory financially, but the plant often needs finer operational states than ERP can manage cleanly in real time.

The core information models that make ISA-95 useful

Standards become practical when they give you useful nouns, not just theory. ISA-95 does that by defining models for the things manufacturers keep arguing about in workshops.

Equipment model

ISA-95 describes equipment in a hierarchy such as:

enterprise
site
area
work centre
work unit

The exact mapping depends on the process and plant design, but the point is to create a consistent structure.

This matters more than it first appears. If one team maps a packaging line as a work centre and another maps it as an area, your reporting, scheduling logic and interface design can drift fast. At multi-site level, that becomes costly.

The equipment model also helps when integrating MES, historian, quality and maintenance systems. If each system identifies assets differently, even basic reporting becomes a reconciliation problem.

Material model

The standard supports definitions for materials, material lots, sublots, classes and related properties.

This is essential in environments where traceability matters: pharmaceuticals, food and beverage, chemicals, automotive and electronics, among others.

The real issue is not just naming material. It is maintaining the relationship between what was planned, what was consumed, what was produced and what is still in process. ISA-95 provides a structure for handling that more coherently.

Personnel model

People are resources too, and manufacturing systems often handle them badly. ISA-95 includes personnel capabilities and classes because production execution may depend on qualifications, certification, shift availability or authorisation.

This tends to be neglected in early architecture designs. Later, teams realise that a process step cannot legally or operationally proceed unless a trained operator, quality approver or maintenance technician is available. By then, the system model is usually too narrow.

Process segment and operations definition concepts

ISA-95 also introduces ways to represent operations definitions and process segments. These help model how work is supposed to happen, independently of a single control vendor or site-specific implementation.

That makes a difference in standardisation programmes. If a company wants comparable execution logic across plants, it needs a common operational language above individual machine code and below enterprise planning abstractions.

The ERP–MES boundary: where most practical questions sit

When people ask about ISA-95, they are often really asking a narrower question: what should ERP do, and what should MES do?

There is no perfect universal split, but ISA-95 gives a disciplined way to think about it.

ERP usually owns

customer orders
procurement
supply planning
enterprise inventory policies
finance and costing
master data with enterprise scope
high-level production planning

MES or MOM usually owns

detailed production dispatching
execution status on the shop floor
WIP visibility
electronic records of actual production activity
local resource coordination
operational quality and genealogy
manufacturing response to schedule changes

The trade-off is straightforward. ERP gives enterprise consistency. MES gives production realism.

If ERP tries to run the plant at too fine a level, the business system becomes slow, brittle and dependent on edge conditions it was not designed for. If MES grows without clear boundaries, it starts duplicating business logic, master data and reporting functions that belong elsewhere.

That is why ISA-95 remains relevant even when companies move towards composable platforms. The standard does not force a product choice. It forces clarity about responsibility.

Common information exchanges defined by ISA-95

At a high level, ISA-95 structures information exchanges such as:

production capability
production schedule
production performance
product definition
resource information
material and inventory status

In practice, these exchanges answer operational questions like:

What can this site produce today?
Which order or batch should run next?
What actually happened during execution?
Which material lots were used?
Which equipment, people and tools were available?
Did the produced material meet release conditions?

This is where many integration projects either succeed or become endless exception handling exercises.

For example, an ERP system may send a planned order and expected quantity. The MES then breaks that into executable work, allocates resources and tracks actual progress. It sends back performance, consumption, completion and exception data. That sounds clean, but details matter:

At what granularity is the order reported back?
Do partial completions update ERP immediately or at shift end?
How are rework, scrap and by-products handled?
What happens if the physical batch deviates from planned lot structure?
Is genealogy recorded in MES, LIMS, historian or a separate traceability platform?

ISA-95 does not make these choices for you. It gives a model so those choices are explicit and consistent.

ISA-95 and MES: helpful, but not identical

A lot of market messaging casually equates ISA-95 with MES. That is too narrow.

ISA-95 is broader than an MES product category. It is a standard for enterprise-control integration and manufacturing operations models. An MES platform may implement parts of ISA-95, align loosely with it, or market against it without fully supporting its information structures.

That distinction matters when evaluating vendors.

A system can claim ISA-95 alignment because it uses the level model in marketing diagrams. That does not mean it supports disciplined equipment modelling, proper operations definitions or structured ERP interfaces. The safer approach is to ask more specific questions:

Which ISA-95 models are implemented natively?
How is equipment hierarchy represented?
How are materials, lots and genealogy modelled?
What standard interface objects exist for ERP integration?
Can the system distinguish planned, dispatched, executed and confirmed states?
How much customisation is needed to fit the plant model?

For most teams, vendor alignment to ISA-95 is useful only if it reduces custom mapping effort.

ISA-95 and IEC 62264

ISA-95 and IEC 62264 are closely related. In many practical discussions, especially outside the US, teams refer more often to IEC 62264. For most architecture conversations, the concepts are effectively treated together.

What matters is that both point towards standardised models for manufacturing operations and enterprise integration. If you are working in a global company, it is sensible to recognise both names because procurement teams, consultants, automation vendors and standards specialists may use either depending on context.

Where ISA-95 fits with OPC UA, PackML and other standards

This is another area where confusion is common. ISA-95 is not competing with every other industrial standard. It solves a different problem.

ISA-95 vs OPC UA

OPC UA is primarily about interoperable communication and information modelling across industrial systems. ISA-95 is about the business-to-manufacturing integration model and operational structure.

A simple way to think about it:

ISA-95 helps define what information should exist and how responsibilities are separated.
OPC UA can help with how systems expose and exchange that information in an interoperable way.

There is complementarity here, not duplication.

ISA-95 vs PackML

PackML focuses more on machine states, modes and packaging machine interoperability. It is useful at a more machine- and line-oriented level.

ISA-95 sits at a broader manufacturing operations and enterprise integration level. If you are designing a packaging architecture, PackML may shape machine behaviour and line integration, while ISA-95 shapes how those assets and their production context integrate into MES and ERP.

ISA-95 vs ISA-88

ISA-88 is more associated with batch control and procedural models. ISA-95 is more about enterprise-control integration and operations management.

In process industries, both often matter. ISA-88 can help define how a batch process is controlled. ISA-95 can help define how that process is scheduled, tracked, reported and integrated with business systems.

Where ISA-95 works well

ISA-95 is especially useful when the organisation has one or more of these conditions:

Multi-plant operations

A single-site factory can survive with informal integration for longer than people expect. A ten-site network usually cannot. Once you need comparable reporting, shared templates and repeatable deployments, inconsistent semantics start hurting.

MES or MOM standardisation programmes

If the company is standardising manufacturing operations across sites, ISA-95 provides a neutral framework to structure the target state.

ERP modernisation with plant integration

ERP transformations often underestimate plant integration complexity. ISA-95 helps keep the ERP scope realistic and defines cleaner interaction points with execution systems.

Regulated or traceability-heavy industries

Where genealogy, auditability and material status are important, the ISA-95 model gives a better foundation than ad hoc interfaces.

Hybrid IT-OT architecture work

If teams are trying to align enterprise architects, plant engineers, system integrators and operations leaders, ISA-95 provides a common reference model. That alone can reduce project friction.

Where ISA-95 does not solve everything

It is worth being clear about the limits.

ISA-95 does not automatically fix poor master data.

It does not remove the need for governance.

It does not settle every product ownership debate between ERP, MES, historian, data platform and quality systems.

It does not design your integration patterns for you.

It also does not guarantee a good outcome if the plant operates in ways the business is unwilling to model honestly. Many integration failures are not technical. They come from forcing neat digital workflows onto messy operational realities without resolving the process issues first.

That sounds reasonable in architecture reviews, but it breaks down during implementation. Teams assume the standard will eliminate ambiguity. In reality, it reduces ambiguity only if the organisation is prepared to make explicit decisions.

Typical ISA-95 implementation mistakes

Most failures do not come from misunderstanding the definition of Level 3. They come from using ISA-95 too superficially.

Treating the levels as a network design

The levels are a functional model, not a rule that every data flow must pass serially from one layer to the next. Modern systems can exchange data across domains safely and sensibly. The question is not whether a cloud app can read machine data. The question is which function it should own.

Skipping information modelling

Some programmes say they are following ISA-95 but never standardise equipment, material, personnel or operations definitions. They integrate transactions without aligning meaning. That creates technical connectivity without semantic consistency.

Using MES as a dumping ground

When ownership is unclear, every unresolved requirement gets assigned to MES. Soon the MES is expected to become scheduler, workflow engine, reporting hub, maintenance cockpit, quality platform and integration middleware at the same time.

That usually leads to customisation debt.

Ignoring plant variation

Global templates are useful, but factories differ in process, maturity, automation depth and regulatory needs. ISA-95 can support standardisation, but only if the model allows controlled local variation.

Overdesigning before proving value

Some teams spend months perfecting a canonical model for every plant object before solving a single operational problem. Standards are useful when they enable decisions, not when they become a documentation programme detached from delivery.

A practical way to use ISA-95 in real projects

For most organisations, the best use of ISA-95 is not to implement the whole standard in one go. It is to use it as an architecture and governance tool.

Start with the operating problem

Do not begin with the standard document. Begin with the business and plant problem.

Examples:

production schedules are not reflecting actual plant constraints
genealogy is incomplete across lines
ERP inventory does not match plant reality
site-to-site performance reporting is inconsistent
a new MES is being rolled out without a clear integration model

The standard becomes useful when it is tied to a real failure or decision.

Map current systems to ISA-95 responsibilities

List the current systems and map what each one actually owns today. Not what the vendor brochure says. What it owns in production.

This exercise usually reveals duplicated ownership quickly:

two systems managing dispatch lists
three systems holding equipment hierarchies
conflicting material status definitions
ERP and MES both calculating completion differently

That is where architecture work becomes concrete.

Define the enterprise–operations boundary

Agree what Level 4 owns, what Level 3 owns, and which events or states cross between them. The aim is not theoretical purity. The aim is stable interfaces and clear accountability.

Standardise key master structures

If you do only a few things from ISA-95, standardise these well:

equipment hierarchy
material and lot structures
production status definitions
resource capability definitions
schedule and performance message semantics

These are the foundations for cleaner integration and more trustworthy reporting.

Use the standard to reduce custom interfaces

Where possible, design integration patterns around repeatable information objects rather than plant-specific scripts. At scale, this matters more than elegant middleware diagrams.

Keep governance alive after go-live

ISA-95 is not a one-time project asset. It needs ownership. Plants change, lines are rebuilt, products evolve, and acquisitions introduce new system landscapes. Without governance, the model decays and local exceptions pile up.

A simple example: discrete manufacturing

Take an automotive components plant.

ERP releases planned production orders based on customer demand and material availability. MES receives those orders, sequences them based on line capability, tooling status and WIP conditions, then dispatches work to specific resources. PLCs and line systems execute machine-level logic and collect cycle data. Quality checks happen in line and at defined stations. MES records actual production counts, scrap, rework and genealogy, then reports confirmed completions and material consumption back to ERP.

Without ISA-95, each of these hand-offs can be designed differently by site, integrator or vendor team. The result is a patchwork landscape where global reporting requires constant mapping.

With ISA-95 as the reference model, the company can define:

what an order means at enterprise level versus operations level
how line resources are structured
how actual production is reported
where genealogy lives
how quality status affects inventory state
which system is authoritative for each resource and event

The technology stack can still vary. The model remains stable.

Another example: process manufacturing

Consider a specialty chemicals plant.

ERP handles demand, procurement and high-level batch planning. A Level 3 operations system manages detailed campaign scheduling, material staging, operator instructions, batch record coordination and quality status. Control systems run the process according to recipe and process constraints. Laboratory results and in-process quality checks affect release decisions. Material lots and intermediate states need traceability across vessels, transfers and packaging.

Here the value of ISA-95 is not just ERP–MES messaging. It is the ability to represent material classes, equipment structure, operations definitions and production performance in a way that does not collapse into site-specific jargon.

ISA-95 in modern digital manufacturing architectures

A fair question is whether ISA-95 still matters when factories are moving towards IIoT platforms, unified namespaces, event-driven architectures and cloud analytics.

Yes, but with one important nuance.

The standard matters less as a rigid stack diagram and more as a semantic and responsibility model.

Modern architectures often flatten technical connectivity. Data may stream directly from Level 2 systems to cloud platforms. Operational events may feed AI models, data lakes or event brokers in near real time. That is fine. The old assumption that every layer must communicate only with the adjacent one is too restrictive for many modern use cases.

What still matters is:

who owns the meaning of the data
who owns the operational decision
at what timescale that decision must happen
which system is the source of truth for a given object or event

ISA-95 remains useful precisely because modern architectures have more paths, more platforms and more chances for semantic confusion.

Should every manufacturer adopt ISA-95 formally?

Not necessarily in a formal certification-style sense.

A small single-site manufacturer with limited automation and a simple ERP may not need a broad ISA-95 programme. But even there, the standard’s thinking can help avoid poor system boundaries.

For larger manufacturers, regulated environments, multi-site operations and any serious MES/MOM initiative, ISA-95 is usually worth adopting at least as a reference architecture and integration vocabulary.

That is often enough to create value:

fewer one-off integrations
clearer ownership boundaries
better master data structure
more consistent reporting
smoother scale-out across plants

Conclusion

ISA-95 is useful because manufacturing integration fails less from missing APIs and more from missing agreement.

The standard gives manufacturers a practical way to define that agreement: what each system is responsible for, how operations should be modelled, and what information should move across the enterprise–plant boundary. That does not remove complexity, but it does make the complexity manageable.

For technology leaders, the real value of ISA-95 is not compliance language. It is architectural discipline.

When ERP, MES and control systems each do the job they are meant to do, plants run with fewer workarounds, reporting becomes more trustworthy, and scaling across sites becomes less painful. That is why ISA-95 still earns a place in serious manufacturing architecture conversations. (Generated Image 1: Create a clean professional flow diagram for a tec…) (Generated Image 1: Create a clean professional diagram for a WordPres…)