ISA-95 explained for manufacturers: system boundaries, levels and data flow

ISA-95 is a family of standards used to describe the boundary and information exchange between enterprise systems and manufacturing operations systems. In practical terms, the ERP layer expresses what the business wants to make, buy, sell and account for; the MES or manufacturing operations management layer turns that business intent into executable factory work; the control layer supervises and controls machines, lines and processes. ISA-95 is not a software product. Its value is a shared language for deciding which system owns which information and how that information should move between layers.

For manufacturers, this matters because many digital transformation projects fail before the technology is the real problem. The plant may have an ERP, several line HMIs, PLCs, spreadsheets, a quality database, a maintenance tool and a warehouse system. Each can be useful on its own. Trouble starts when a production order, material lot, equipment status or quality result means something different in each place. ISA-95 gives operations, IT and business teams a way to draw the boundary before they automate the interface.

This article explains ISA-95 for decision makers and practitioners. It does not reproduce the standard. It focuses on the questions that usually matter inside a plant: why the ERP to MES boundary exists, how the level model should be read, what belongs to manufacturing operations management, where SCADA fits, and what mistakes to avoid when using ISA-95 as a project reference.

The problem ISA-95 tries to solve

A production order has several lives. In the commercial system it may begin as customer demand, promised date, margin and inventory commitment. In production planning it becomes a requirement for capacity, materials and sequence. On the shop floor it becomes a shift plan, a line setup, operator instructions, material issue, in-process checks, downtime records and final confirmation. In quality it may become sample results, holds, rework or release decisions. In maintenance it may depend on asset availability.

Without a common model, every interface becomes a local translation exercise. One project team maps product codes by hand. Another exports a spreadsheet. A third asks operators to retype actual quantities into the ERP at the end of the shift. These workarounds may be acceptable for a short period, but they create fragile operations. They also make later analytics unreliable because the data has lost its manufacturing context.

The public ISA committee page for ISA95 describes the work as defining the interface between control functions and enterprise functions, initially between levels 3 and 4 of the Purdue Reference Model, with a goal of reducing risk, cost and errors in implementation. For a manufacturer, the important takeaway is not the diagram itself. The takeaway is that enterprise decisions and control decisions need an agreed interface, not a blurred overlap.

Reading the ISA-95 levels without overcomplicating them

ISA-95 is commonly explained with a level model. The levels are useful, but they should not be treated as a rigid organization chart. A single software suite may cover multiple functions. A plant may have custom tools that do not fit a vendor category neatly. The real question is functional responsibility.

Level 4 is the enterprise and business planning domain. It includes functions such as ERP, finance, sales order management, purchasing, long-range planning and business-level inventory policy. These systems usually work at the time scale of days, weeks and accounting periods.

Level 3 is the manufacturing operations management domain. This is where MES and MOM functions usually sit. It includes detailed scheduling, dispatching work, tracking execution, managing production resources, collecting operational data, connecting quality operations, tracking material use, supporting maintenance coordination and analyzing performance in production context. These activities often operate at the time scale of shifts, orders, batches and work centers.

Levels 2, 1 and 0 cover supervision, control and the physical process. SCADA, HMI, PLCs, sensors, drives, instruments and actuators live close to these levels. The time scale can be seconds or milliseconds. The data is often signal-rich but not automatically business-aware.

The levels help teams avoid two common extremes. One extreme is pushing every shop-floor detail into the ERP. The other is expecting SCADA or PLC data to replace production management. ISA-95 encourages a middle layer where manufacturing context is managed deliberately.

ERP, MES, MOM and SCADA in plain language

ERP is the business system of record for many enterprise processes. It knows commercial demand, purchasing, financial postings, high-level inventory, product master data and planning assumptions. It is strong at consistency across the company. It is usually not designed to manage every minute-by-minute event on a production line.

MES is a common software category within the broader manufacturing operations management space. It helps execute production orders, manage work instructions, collect production actuals, connect materials to orders, support traceability, capture downtime, record checks and return confirmations. MOM is a broader functional term. It includes production operations, quality operations, inventory operations and maintenance operations in the manufacturing context.

SCADA supervises and visualizes the process. It can collect alarms, machine states, temperatures, pressures, speeds, counters and operator interactions. PLCs and controllers act even closer to the equipment. These systems are essential, but their data often needs context. A machine count becomes much more valuable when it is tied to an order, product, material lot, shift and quality status.

The distinction is not about making systems isolated. It is about connecting them without confusing their responsibilities. The ERP does not need every sensor value. The PLC does not decide customer priority. The MES or MOM layer links production work with operational evidence.

The four manufacturing operations areas

A useful way to apply ISA-95 is to look at the main operations areas at level 3. NIST's page for the MESA MOM/CMM assessment tool states that the tool is based on level 3 ISA-95 Part 1 MOM processes and defines evaluation criteria across production operations management, quality operations management, inventory operations management and maintenance operations management.

Production operations management covers the execution of work: detailed scheduling, dispatching, instructions, progress, actual quantities and performance analysis. Quality operations management covers inspection plans, sample results, holds, deviations, approvals and release decisions. Inventory operations management covers the movement and use of materials in production, including the status and availability of lots near the line. Maintenance operations management connects asset condition and work status to production execution.

For a manufacturer, this four-area view is a practical check against narrow MES thinking. If a plant treats MES only as an electronic production declaration screen, it may miss the quality, material and maintenance context that explains why the plan succeeded or failed. Conversely, trying to put all four areas into one large project without process discipline can overwhelm the organization. The better approach is to map the areas, define ownership, then implement in manageable slices.

A worked example: one production order through the layers

The following example is hypothetical. It is not a claim about Tuna Project operations, any customer deployment or any specific plant result. It simply shows how the ISA-95 way of thinking structures information flow.

Assume an ERP releases a production order for 1,000 units of Product A with a requested completion date of Friday. The ERP sends the order number, product code, requested quantity, due date and planned bill of materials. It does not send every control parameter for the line, and it does not decide the exact minute when a specific operator starts the job.

The MES receives the order and creates a detailed plan for Line 2 on the 08:00 to 16:00 shift. Before dispatching the work, it checks whether the approved recipe is available, whether the required material lots are staged, whether the line is available and whether the operator qualifications are acceptable for that operation. These checks are operational decisions, not accounting decisions.

During production, the control layer records machine states, counts, alarms and process values. SCADA shows operators what is happening. The MES links relevant events to the production order. At the end of the shift, the MES records 970 units produced, 955 accepted, 15 on quality hold and 30 scrapped. It also records that two material lots were consumed, one quality test was repeated and a 42-minute equipment stoppage occurred.

The ERP does not need every second of signal history. It needs the summarized business impact: accepted quantity, inventory movement, consumed materials and order status. Quality may keep the 15 units on hold until a release decision is made. Maintenance may use the stoppage data for asset analysis. This separation preserves detail where it is useful and avoids overloading the wrong system.

Where ISA-95 helps in real projects

ISA-95 is most useful when teams use it before writing the interface specification. It helps them ask basic but often neglected questions. What is the source system for equipment master data? Where does a material lot become available for production? Who owns the production order status after dispatch? Which system records a quality hold? Which system can change a downtime reason after supervisor review? What happens when ERP quantity and MES quantity disagree?

These questions are not glamorous, but they decide whether a digital project scales. When they are unanswered, integrations become a chain of exceptions. When they are answered, the technology choices become easier. An API, message broker, edge gateway, database view or file interface can all work in different contexts. ISA-95 does not force a specific integration technology. It forces the team to keep business meaning and control responsibility clear.

It also helps with vendor discussions. Instead of asking only whether a system is ISA-95 compliant, manufacturers can ask which ISA-95 objects, processes and boundaries the supplier supports, how master data is synchronized, how exceptions are handled, and which system remains the record of truth after a transaction fails. That is a more useful conversation than a checkbox.

Common misunderstandings

The first misunderstanding is that ISA-95 is the same thing as MES. MES is a software category. ISA-95 is a reference framework for enterprise-control integration and manufacturing operations concepts. A plant can use ISA-95 to define an ERP to quality interface, a warehouse to production interface or a maintenance to operations boundary even before selecting a new MES.

The second misunderstanding is that the level model is a network security drawing. Security architecture is critical, and industrial networks often use zones and conduits. However, ISA-95's primary value in this discussion is functional and informational. A level 3 function is not defined only by where a server sits. It is defined by the operational responsibility it performs.

The third misunderstanding is that more data automatically means better decisions. A historian or SCADA system may store millions of time-series points. If those points are not tied to order, product, batch, material and quality context, they may not answer production management questions. ISA-95 pushes teams to keep context attached to the data.

The fourth misunderstanding is that the ERP should be the master of all manufacturing detail. ERP discipline is valuable, but forcing real-time or high-frequency operational events into a business system can create latency, manual work and data noise. The better design is usually to summarize and synchronize the right information at the right level.

Limits of ISA-95

ISA-95 does not choose a vendor, write a data governance policy or clean up poor master data. If product codes are inconsistent, equipment names change between systems, operators enter free-text downtime reasons and material lots are not reliably scanned, a reference model will not magically fix reporting. Process ownership and data discipline are still required.

The framework also needs interpretation by industry. Batch process, discrete assembly, food processing, metals, packaging and pharmaceuticals can all use ISA-95 ideas, but they do not apply every concept in the same way. Regulated sectors may have additional validation, audit trail or documentation requirements that are outside the scope of a general explanatory article and must be verified separately for the specific jurisdiction and process.

Finally, ISA-95 should not be used as a reason to freeze architecture. Modern plants may use cloud systems, edge computing, OPC UA, MQTT, data lakes and analytics platforms. These can fit with ISA-95 thinking if responsibility and context remain clear. The standard gives a boundary model, not a ban on modern patterns.

A practical checklist for manufacturers

A first ISA-95 review can be simple. Start with one product family, one line or one recurring integration problem. Then ask:

1. Which system owns the production order before release, after dispatch and after completion?
2. Which system is the record of truth for equipment, personnel, material lot, quality result and downtime reason?
3. Are production, quality, inventory and maintenance operations considered separately at level 3?
4. Does ERP receive the right summary actuals, or is it overloaded with shop-floor detail?
5. Are machine signals connected to order, product, material and shift context?
6. Is exception handling defined when one system rejects or changes a transaction?
7. Can a pilot scope prove the boundary without trying to transform the entire plant at once?

If the team cannot answer these questions, the project is not ready for a large integration build. If the answers are clear, ISA-95 becomes a practical guide rather than an abstract diagram.

Conclusion

ISA-95 helps manufacturers separate business planning, manufacturing operations and control responsibilities while still allowing those systems to work together. It gives teams a vocabulary for the ERP to MES boundary, the role of MOM, and the limits of SCADA-only production visibility. Used well, it reduces ambiguity before technology is selected and makes integration conversations more concrete.

The most useful starting point is not a claim of compliance. It is a responsibility map. Identify the decisions, the data owners, the systems of record and the interfaces that matter for a real production flow. Once those are visible, ISA-95 can support a more stable path from machine signals to production decisions and from production results back to enterprise planning.

Related reading

• What is MES? Scope, data and responsibilities in manufacturing execution
• MES vs ERP: which system owns which decision?