ISA-95 Information Models: Materials, Equipment, Personnel and Process Segments

Francisco Requena Alcaraz

Factories do not suffer from a lack of data.

They suffer from data whose meaning changes from one system to another.

ERP may identify a material through an item code and commercial unit of measure. MES may require a production-specific material definition. Maintenance may structure equipment around functional locations and maintainable assets. Production may refer to the same resource by a local name. Quality may associate results with a lot, while operations think in terms of orders, shifts, lines and process steps.

Each system may be internally correct and still fail to support a coherent operational decision.

This is why industrial integration becomes difficult long before an interface is technically built.

ISA-95 information models matter because they provide a disciplined way to represent the principal resources and activities of manufacturing operations: materials, equipment, personnel and process segments.

Their value does not lie merely in standardized terminology. Their value lies in preserving operational meaning as information moves between planning, execution and physical production.

Integration Fails When Systems Exchange Values but Not Meaning

Many integration projects begin as field-mapping exercises.

An ERP field is connected to an MES field. A machine signal is associated with a production order. A quality result is attached to a batch. A maintenance event is linked to an equipment identifier.

The interface may function technically.

Operational questions nevertheless emerge:

  • Which material definition governs production execution?
  • Does “equipment” refer to a line, cell, machine, functional location or maintainable component?
  • Which personnel capability is required for the activity?
  • Which authorization is required to release or approve the work?
  • What is the actual unit of operational work being scheduled, executed and reported?
  • Which system owns the definition when two records disagree?

When these questions are not resolved consistently, integration becomes a chain of local interpretations.

Data moves, but meaning is reconstructed manually by planners, operators, technicians, engineers and quality specialists.

ISA-95 helps structure the concepts and relationships required to prevent that loss of meaning.

The objective is not to force every system to use an identical internal model. ERP, MES, QMS, EAM and automation platforms have different responsibilities. The objective is to ensure that information retains a coherent operational interpretation as it passes between them.

Materials Are More Than Item Codes

In many ERP systems, a material is represented primarily as a business object:

  • item number;
  • description;
  • unit of measure;
  • valuation class;
  • procurement type;
  • inventory status.

These attributes are important, but they are often insufficient for production execution.

Operations may also need to know:

  • which material class is permitted for the process;
  • which lot or sublot was physically consumed;
  • which substitute material is authorized;
  • which properties affect processing;
  • which quantity was issued, consumed, scrapped, returned or produced;
  • which genealogy relationships must be preserved;
  • whether the physical material corresponds to its digital status;
  • whether the material is released, blocked, quarantined or conditionally approved.

A robust material model therefore needs to distinguish among several related concepts:

  • material definition: what the material is;
  • material class: the category to which it belongs;
  • material lot or sublot: the specific physical identity;
  • material properties: the characteristics relevant to execution;
  • material quantity: the amount in a defined unit;
  • actual material consumption or production: what physically occurred.

This distinction is critical in traceability, recipe control, quality management and regulated production.

A production order may request a defined material, but the execution question is more demanding:

Did the correct physical lot, with the required status and properties, reach the correct operation at the correct time?

A system may report consumption accurately from a transactional perspective and still fail to prove that the correct material was used.

Equipment Must Represent Identity, Hierarchy and Capability

Equipment is frequently modelled differently by different functions.

Maintenance may organize assets around functional locations, systems and maintainable units.

Production may think in lines, cells, stations and machines.

Engineering may use design tags, technical structures and equipment specifications.

MES may require a hierarchy that supports scheduling, dispatching, data collection, genealogy and performance analysis.

These views overlap, but they are not identical.

The mistake is to assume that one hierarchy can be copied mechanically into every system.

A useful equipment model should distinguish among:

  • equipment class: a category of resources with similar characteristics;
  • equipment instance: the specific physical resource;
  • equipment hierarchy: the structural relationship among sites, areas, lines, cells and units;
  • equipment capability: what the resource is able to perform;
  • equipment state and availability: whether it can perform the activity now;
  • actual equipment used: which resource executed the work.

This model should support questions such as:

  • Where can this activity be performed?
  • Which capability is required?
  • Which equipment instances provide that capability?
  • Is the resource available and suitable for the current product and process?
  • Which level should receive production-performance data?
  • Which maintainable asset should receive failure and intervention history?
  • Which equipment relationship is relevant to genealogy or quality?

A press may simultaneously be:

  • a maintainable asset;
  • part of a production cell;
  • a capacity resource for scheduling;
  • a source of process parameters;
  • a contributor to product genealogy.

These views must be related without being treated as interchangeable.

Manufacturing does not schedule physical assets merely because they exist. It schedules resources that can provide the required capability under the necessary operating conditions.

Personnel Models Must Describe More Than Identity

Many systems represent personnel primarily through names, employee numbers, departments or shift assignments.

Operational execution requires more.

A person may be available but not qualified. Qualified but not currently certified. Certified but not authorized for a particular activity. Authorized for one product family but not another. Assigned to a shift but unavailable during the required execution window.

A mature personnel model should distinguish among:

  • identity: who the person is;
  • role: the responsibility performed in the process;
  • qualification: the capability demonstrated;
  • certification: formal evidence that a qualification has been achieved;
  • authorization: permission to perform or approve a specific activity;
  • availability: whether the person can support the work at the required time;
  • actual participation: who performed, reviewed or approved the activity.

This matters in production, maintenance, laboratory work, quality inspection, setup, changeover and regulated operations.

Consider a manual inspection step.

MES may record that an operator completed the inspection. However, if the system cannot determine whether that operator held the required qualification and authorization at the time of execution, the record may be complete without being compliant.

The same principle applies to maintenance.

A work order may be assigned to a technician, but the actual execution constraint may be the availability of a person with electrical authorization, confined-space certification or specialist diagnostic competence.

Personnel information becomes operationally valuable when it represents what people are capable and permitted to do, not merely where they sit in the organization.

Process Segments Describe Executable Operational Work

The process segment is one of the most useful and frequently misunderstood concepts in ISA-95.

A process segment describes a defined unit of operational work and the resources, parameters and conditions associated with performing it.

Depending on the required level of abstraction, it may represent activities such as:

  • preparation;
  • setup;
  • processing;
  • inspection;
  • transfer;
  • packaging;
  • cleaning;
  • changeover.

A process segment can connect:

  • the work to be performed;
  • the required material class or property;
  • the required equipment capability;
  • the required personnel capability;
  • expected duration;
  • process parameters;
  • quality requirements;
  • production rules;
  • expected outputs;
  • required execution evidence.

This creates a bridge between high-level production demand and executable shop-floor activity.

ERP may release a production order for a defined quantity of finished product. MES/MOM must interpret that request as operational work.

That interpretation may involve several activities, each with different resource requirements, sequence dependencies, limits and evidence.

Without an explicit model of operational work, execution logic is often hidden inside:

  • screens;
  • interfaces;
  • workflow configuration;
  • equipment-specific code;
  • custom scripts;
  • local work instructions.

The implementation may function, but the operating model remains implicit.

This becomes expensive when the organization introduces a new product, machine, routing or control requirement. The change requires technical modification in multiple places because the process structure was never represented clearly.

A process-segment model makes the work, its requirements and its dependencies visible.

Required Resources and Actual Resources Must Be Distinguished

Materials, equipment, personnel and process segments should not be treated as independent master-data lists.

Their value emerges through relationships.

A process segment may require:

  • a material from an approved class;
  • an equipment capability;
  • a qualified and authorized role;
  • defined process limits;
  • a specified output;
  • required quality evidence.

These are requirements.

When the operation is executed, those requirements are connected to actual resources and actual results:

  • the material lot consumed;
  • the specific equipment used;
  • the operator or technician who performed the activity;
  • the recorded process values;
  • the quantity produced;
  • the quality evidence captured;
  • the actual duration and outcome.

This distinction between what should have happened and what actually happened is fundamental.

It enables the organization to compare:

  • required material with consumed material;
  • required capability with actual equipment used;
  • required qualification with actual personnel assigned;
  • expected parameters with actual values;
  • expected output with actual performance.

That comparison supports:

  • traceability;
  • conformance verification;
  • quality investigation;
  • performance analysis;
  • costing;
  • regulatory evidence;
  • continuous improvement;
  • maintenance and reliability learning.

It also creates the context required for advanced analytics and industrial AI.

A model cannot explain a quality deviation reliably if it sees only sensor values. It also needs to know:

  • which material lot was used;
  • which machine performed the work;
  • which process segment was active;
  • which recipe or parameter set applied;
  • which operator qualification was required;
  • which actual conditions were recorded.

Analytics without operational context may identify correlation while failing to explain relevance.

How This Fits into MES/MOM Architecture

ISA-95 information models help connect business planning with manufacturing execution without collapsing the responsibilities of each layer.

ERP typically manages business-level objects such as:

  • demand;
  • production orders;
  • material definitions;
  • inventory;
  • procurement;
  • cost.

MES/MOM manages the operational context required to execute and record manufacturing work, including:

  • dispatching;
  • resource allocation;
  • work instructions;
  • production execution;
  • genealogy;
  • consumption;
  • quality evidence;
  • performance response.

SCADA, PLCs, DCSs and machines provide physical-state and process-signal information.

The information model helps these layers exchange coherent information while retaining their respective purposes.

A simplified sequence may be:

  1. ERP sends a production request.
  2. MES/MOM interprets the request through process definitions and resource requirements.
  3. Materials, equipment and personnel are selected or assigned.
  4. The shop floor executes the work.
  5. Actual resource use, process values, genealogy, performance and quality results are recorded.
  6. Confirmed production and inventory transactions are returned to ERP.

The architecture becomes more stable when each layer performs its intended function and exchanges clearly defined information.

Problems emerge when ERP structures are copied into MES without validation against shop-floor reality, or when machine tags are treated as though they already contain business and operational meaning.

A tag may represent a physical signal. It does not automatically explain the production context in which that signal was generated.

A Practical Industrial Example

Consider a factory introducing a new product variant on an existing assembly line.

ERP contains the new material code and production order.

At first sight, the line appears capable of producing the product.

During implementation, however, several missing operational definitions emerge:

  • the product requires a specific component revision;
  • only two stations have the necessary tooling;
  • operators need an updated qualification;
  • a torque operation requires different limits;
  • the quality check must capture an additional measurement;
  • the packaging activity requires a different label rule;
  • the new variant may require a different sequence under certain conditions.

If MES receives only the material code and order quantity, the missing logic must be introduced through local configuration, custom screens, manual instructions or interface-specific rules.

The result may work technically, but the operating model becomes fragmented and difficult to govern.

A stronger model would define:

  • the material and its relevant properties;
  • the required equipment capability;
  • the applicable personnel qualification;
  • the process segments;
  • the operating parameters;
  • the quality evidence;
  • the actual resources and values recorded during execution.

The product introduction then becomes a governed change to the operating model rather than a collection of disconnected technical patches.

Governance Is as Important as the Model

A technically correct information model will deteriorate without governance.

Each information domain requires clear ownership.

The organization should define:

  • who owns material definitions and properties;
  • who owns equipment structures and capabilities;
  • who owns personnel qualifications and authorizations;
  • who owns process definitions and resource requirements;
  • how identifiers are created and retired;
  • how versions and effective dates are managed;
  • how changes are synchronized across systems;
  • how semantic conflicts are resolved;
  • how the model is validated against physical operations.

Cross-functional governance is especially important because these domains span ERP, MES, QMS, EAM, engineering and automation.

No single system owner can define operational meaning independently.

The model must be validated with the functions that use and create the information:

  • production;
  • maintenance;
  • quality;
  • logistics;
  • industrial engineering;
  • automation;
  • IT.

Validation at the gemba is essential.

A hierarchy or resource definition may appear logical in a design workshop and still fail to represent how work is scheduled, executed, maintained or investigated.

Typical Mistakes

One common mistake is treating ISA-95 as an IT documentation exercise.

Architects create models that are technically elegant but insufficiently validated with production, maintenance, quality, logistics and industrial engineering.

Another mistake is copying existing master data without questioning its operational meaning.

A third is attempting to model every possible detail before identifying which decisions the information must support.

The opposite error also occurs: definitions are made so generic that they carry no useful operational context.

Other recurring weaknesses include:

  • unclear ownership;
  • inconsistent identifiers;
  • ungoverned local extensions;
  • duplicated definitions;
  • missing version control;
  • confusion between resource class and resource instance;
  • failure to distinguish required resources from actual resources;
  • excessive custom logic hidden in interfaces and screens.

The objective is not to build the most complex model possible.

It is to establish enough structure to support reliable execution, integration, evidence and change.

Before Implementing This Capability, Check Whether…

  • your material model connects business identity with physical lot, status, properties and operational use;
  • your equipment model represents hierarchy, capability, availability and maintainable identity;
  • personnel information includes the qualifications, certifications and authorizations relevant to execution;
  • process segments represent executable operational work rather than merely reproducing ERP routing steps;
  • required resources can be compared with actual resources used;
  • quality and production evidence can be associated with the correct process context;
  • ownership exists for each information domain;
  • identifiers, versions and changes are governed across systems;
  • the model has been validated with shop-floor users;
  • integration mappings preserve meaning rather than merely transferring values;
  • the structure can support future products, equipment and process changes without excessive local customization.

The Key Takeaway

ISA-95 information models are not valuable merely because they standardize vocabulary.

They are valuable because they help industrial organizations preserve operational meaning across planning, execution and evidence.

Materials define what is required and what was actually used.

Equipment defines which capability is needed and which physical resource performed the work.

Personnel defines which competence and authorization are required and who actually participated.

Process segments define the operational work, its resource requirements and its expected results.

Together, these models allow MES/MOM to translate production demand into executable activity and to reconstruct what actually occurred.

An integrated factory is not simply one in which systems exchange data.

It is one in which the meaning of the production requirement remains intact from planning through execution and recorded evidence.

Without that semantic continuity, an organization may integrate many systems and still struggle to answer a basic operational question:

What exactly happened, with which resources, under which conditions, and against which production requirement?

Questions for Reflection

  1. Do ERP, MES, maintenance and quality use consistent operational meanings for materials, equipment and personnel capabilities?
  2. Is MES execution logic represented through explicit process and resource models, or is it hidden inside screens, interfaces and local customization?
  3. Can your systems distinguish clearly between required resources and the actual resources used?
  4. Could your current information model reconstruct a production or quality incident without relying on spreadsheets, email and personal interpretation?
  5. Who is accountable for preserving semantic consistency when master data or production processes change?

#ISA95 #MES #MOM #SmartManufacturing #ManufacturingOperations #IndustrialIntegration #OperationalExcellence #SmartFactory #ManufacturingData #IndustrialAI #DigitalTransformation