ISA-95 Explained: The Grammar of Industrial Integration

Francisco Requena Alcaraz

Many factories are highly connected and poorly integrated at the same time.

PLCs transmit signals to historians. MES platforms exchange production orders with ERP. Quality systems receive inspection results. Maintenance teams work through CMMS or EAM applications. Business intelligence platforms consolidate plant KPIs, while cloud services ingest increasing volumes of operational data.

From an infrastructure perspective, the factory appears connected.

Yet the same organisation may still struggle to answer basic operational questions:

  • Which production order was active when a deviation occurred?
  • Which material lot, recipe version, equipment condition and operator qualification were involved?
  • Was the reported quantity produced, accepted, rejected, reworked or transferred?
  • Does the asset identifier in the maintenance system represent the same physical equipment modelled in MES?
  • What does “production complete” mean in ERP, MES and on the shopfloor?

These are not primarily connectivity problems. They are problems of shared operational meaning.

This is where ISA-95 becomes valuable—not as an automation pyramid used to decorate architecture presentations, but as a common industrial grammar for defining how enterprise planning and manufacturing operations interact.

Connectivity Transfers Data; Integration Preserves Meaning

Industrial integration is frequently approached as a technical exercise:

  • define an API;
  • map the required fields;
  • configure middleware;
  • connect the applications;
  • confirm that the transaction reaches its destination.

This work is necessary, but it is not sufficient.

A technically successful interface can transfer the wrong meaning with complete reliability.

An ERP system may release a production order containing a material number, planned quantity and required completion date. MES may receive the message and create an executable order. However, the transaction alone does not answer several operational questions:

  • Which production route applies?
  • Which equipment is authorised and capable of executing the order?
  • Which recipe, specification or work-instruction version is valid?
  • Which personnel qualifications are required?
  • What constitutes an acceptable unit?
  • How must scrap, rework and process deviations be recorded?
  • Which event confirms that production has genuinely finished?

When these definitions remain unresolved, integration teams compensate through local mappings, spreadsheets, hard-coded logic, manual corrections and plant-specific interpretations. The interface may operate successfully, while the underlying operating model becomes increasingly fragile.

ISA-95 helps organisations address this problem by providing a structured language for the boundary between business planning and manufacturing operations.

Its value lies not merely in moving information, but in clarifying what the information represents, who owns it and which operational decision it supports.

ISA-95 Is More Than an Automation Pyramid

ISA-95 is often introduced through its familiar functional hierarchy:

  • Levels 0–2 represent the physical process, sensing, monitoring and control.
  • Level 3 represents manufacturing operations management.
  • Level 4 represents business planning and logistics.

The model remains useful, but reducing ISA-95 to this diagram understates its significance.

Its deeper contribution is that it forces an organisation to clarify three fundamental issues:

  1. Which responsibilities belong to each operational domain?
  2. Which information must move between those responsibilities?
  3. How should personnel, equipment, materials and production activities be represented consistently?

The standard does not prescribe a specific software product, vendor or rigid technical architecture. Nor does it require every responsibility to reside in a single application.

Instead, it provides conceptual boundaries and information models that help organisations identify overlap, ambiguity, duplication and missing accountability.

This distinction is important. ISA-95 is not a vendor blueprint. It is a framework for reasoning about industrial operations.

MES/MOM as the Domain of Accountable Execution

ERP is generally responsible for enterprise-level planning and business commitments. It manages areas such as customer demand, purchasing, inventory valuation, financial control and high-level production planning.

Control systems operate closer to the physical process. PLCs, DCS platforms, SCADA systems and machine controllers regulate equipment and processes, frequently responding within milliseconds or seconds.

MES/MOM occupies the operational domain between these environments.

This is where business commitments are converted into executable work—and where actual production becomes controlled, contextualised and auditable operational evidence.

Typical Level 3 responsibilities include:

  • detailed production dispatching;
  • resource allocation;
  • execution control;
  • recipe and specification enforcement;
  • material consumption and tracking;
  • genealogy and traceability;
  • personnel and equipment status;
  • quality operations;
  • maintenance coordination;
  • performance analysis;
  • production confirmation and reporting.

This does not mean that every factory requires one monolithic MES platform performing all these functions. Responsibilities may be distributed across MES, QMS, LIMS, WMS, CMMS/EAM, advanced planning applications and specialised shopfloor systems.

The decisive question is not whether a particular product carries the MES label.

The decisive question is whether Level 3 responsibilities are explicitly assigned, operationally governed, consistently modelled and integrated around the real production process.

The Boundary Between Planning and Execution

One of the most important contributions of ISA-95 is the distinction between what the enterprise intends to happen and what manufacturing must actually execute.

ERP may express a business requirement such as:

Produce 10,000 units of product X before Friday.

Operations must translate that commitment into a much richer execution context:

  • which line will produce the order;
  • which sequence will be followed;
  • which material lots are available and approved;
  • which tooling, recipes and specifications are valid;
  • whether the equipment is available and capable;
  • whether appropriately qualified personnel are present;
  • how quality controls will be performed;
  • how deviations and exceptions will be managed;
  • how actual production, scrap, rework and losses will be reported.

This translation cannot be reduced to transmitting an order number to a machine.

It requires an operational model connecting production requirements to resources, constraints, standards and execution events.

MES/MOM creates value when it performs this translation consistently and captures the as-built evidence required by production, quality, maintenance, logistics and finance.

Without this capability, factories often depend on informal coordination through phone calls, whiteboards, spreadsheets, local knowledge and individual experience. Such mechanisms may keep production moving, but they do not create scalable operational control. They also make accountability, traceability and continuous improvement dependent on people rather than on a governed operating system.

A Practical Example: When “Quantity Produced” Has Five Meanings

Consider a packaging line scheduled to produce 20,000 units.

At the end of the shift:

  • the machine counter shows 20,450 cycles;
  • the operator reports 19,900 units;
  • the quality system records 19,720 accepted units;
  • the warehouse receives 19,600 units;
  • ERP receives a confirmation for 20,000 units.

Each number may be legitimate within its own context.

The machine counter may include test cycles and empty packages. The operator may exclude start-up losses. Quality may hold units pending inspection. The warehouse may record only completed pallets. ERP may receive the planned quantity because confirmation remains manual.

The problem is not simply inaccurate data. The deeper problem is that different systems are representing different operational events under similar or identical labels.

An ISA-95-based approach requires the organisation to distinguish the events explicitly:

  • What quantity was started?
  • What quantity was processed?
  • What quantity was physically completed?
  • What quantity was accepted?
  • What quantity was rejected or scrapped?
  • What quantity entered rework?
  • What quantity was transferred to inventory?
  • What quantity was financially confirmed?

Once these meanings are explicit, integration becomes more than field mapping. It becomes the governed exchange of operational facts.

This requires more than a data model. Each definition needs an accountable owner, an agreed source of truth, rules for exception handling and controlled procedures for changing the definition.

Without that governance, identical terminology may continue to conceal different operational realities.

Why ISA-95 Matters for Operational Excellence

Operational Excellence depends on the ability to identify losses, understand causes, prioritise action and verify results.

This becomes difficult when systems disagree about how operations are structured or how events are defined.

For example:

  • OEE becomes unreliable when equipment states and planned-time definitions are inconsistent.
  • A downtime Pareto becomes misleading when reason codes are applied to different asset structures or operational events.
  • Traceability becomes incomplete when material identifiers change between ERP, MES, WMS and quality applications.
  • Cost-per-unit analysis becomes distorted when production, scrap and rework quantities are calculated differently.
  • Maintenance prioritisation becomes less effective when the asset hierarchy in EAM does not align with the production model used by MES.
  • Process-mining results become questionable when event timestamps, case identifiers and completion criteria are not semantically consistent.

The causal chain is important.

Inconsistent operational definitions create unreliable facts. Unreliable facts weaken diagnosis. Weak diagnosis produces poor prioritisation and inconsistent decisions.

ISA-95 does not solve these problems automatically. It provides a disciplined framework for exposing and resolving them.

Its value is therefore operational, not merely architectural. A common model reduces the time spent reconciling systems and increases the time available to improve the process itself.

Common ISA-95 Anti-Patterns

Treating the levels as rigid software boxes

Modern industrial platforms often support functions across several traditional levels. Edge services, cloud platforms and integrated operations applications may cross conventional architectural boundaries.

The objective is not to force each application into a single box. The objective is to make responsibilities, decision rights and information ownership explicit.

Copying the ERP hierarchy directly into MES

An enterprise hierarchy designed for accounting or financial reporting may not represent how production is physically executed.

A cost centre is not necessarily a production line. A financial asset is not always equivalent to a maintainable asset. A material master may lack the operational characteristics required for execution.

The production and equipment models must therefore be validated at the gemba, against actual workflows, physical constraints and operating responsibilities.

Adopting standard terminology without standardising meaning

Renaming fields does not create operational standardisation.

Terms such as complete, available, consumed, released and scrapped must be defined against observable events and governed business rules. Otherwise, ISA-95 terminology becomes another semantic layer placed over unresolved local ambiguity.

Designing integration only between IT systems

Production, quality, maintenance, logistics and industrial engineering must participate in integration design because they understand the operational events represented by the data.

IT can establish transport, security and technical reliability. It cannot independently determine the operational meaning of production completion, material consumption, equipment availability or quality acceptance.

Assuming that connection automatically creates value

The number of interfaces is not a reliable measure of integration maturity.

Integration creates value only when shared information improves execution, coordination, control or decision-making. An interface that does not support a defined operational decision may increase complexity without improving performance.

Before Implementing or Extending This Capability

An organisation should verify whether:

  • the responsibilities of ERP, MES/MOM, SCADA, CMMS/EAM, QMS and WMS are explicitly defined;
  • the plant has agreed production, equipment and asset hierarchies;
  • materials, personnel, equipment and process definitions have accountable owners;
  • decision rights are clear when systems or functions disagree;
  • production orders can be translated into executable operational instructions;
  • actual production events are defined consistently across applications;
  • scrap, rework, hold, consumption, completion and transfer have unambiguous meanings;
  • the architecture reflects real shopfloor workflows rather than only corporate reporting structures;
  • production, maintenance, quality, logistics and industrial engineering participate in integration governance;
  • master-data changes, interface failures, manual overrides and local exceptions are controlled;
  • semantic validation is included in interface testing, rather than testing only message delivery;
  • each exchanged data element supports a defined operational or business decision.

A weakness in any of these areas should not automatically lead to another technology acquisition. It may indicate a more fundamental problem involving governance, process discipline, accountability or operating-model design.

The Real Value of a Common Industrial Grammar

ISA-95 will not stabilise an incapable process. It will not improve poor reason-code discipline. It will not correct unreliable master data or create ownership where none exists. It will not make an MES implementation successful by itself.

What it can do is make hidden assumptions visible.

It enables production and IT to discuss the same operating model. It helps ERP and MES teams define their boundaries. It allows maintenance, quality and logistics information to be connected to production context. It helps organisations move from isolated interfaces towards a coherent operational architecture.

Most importantly, it changes the integration question.

Instead of asking only, “Can these systems exchange data?”, the organisation begins to ask:

  • Do they represent the same operational event?
  • Is the information associated with the correct production and asset context?
  • Is its owner accountable for its quality and definition?
  • Does the receiving system know what decision or action should follow?

A connected factory exchanges data.

An integrated factory shares operational meaning and converts that meaning into consistent execution.

This is the enduring relevance of ISA-95. Industrial transformation depends not merely on moving information between applications, but on establishing a common grammar through which systems, processes and people understand what that information represents—and what accountable decision must follow.

#ISA95 #OperationalExcellence #MES #SmartFactory #ManufacturingExcellence #IndustrialAutomation #AssetManagement #IndustrialMaintenance #ProcessMining #DigitalTransformation