Data Analytics
Manufacturing Data Interoperability: ERP to Shop Floor
Published September 11th, 2026
Manufacturing data interoperability is the ability of ERP, production scheduling, machine monitoring, work-in-process, and analytics systems to exchange data that people and software can interpret consistently. When those systems do not connect, planners work from stale information, operators repeat data entry, and leaders cannot trust the relationship between the schedule and actual production.
The problem is rarely a lack of data. A modern plant may already have order records in an ERP, schedules in a planning tool, machine states in a monitoring system, and job updates in a shop-floor application. The problem is that each system may use different names, identifiers, timestamps, units, and definitions for the same work. Interoperability turns those disconnected records into a usable feedback loop.
What is manufacturing data interoperability?
Manufacturing data interoperability is the structured exchange of manufacturing information across systems, vendors, and operational layers so that data retains its meaning, context, timing, and ownership. It connects business events such as orders and due dates with operational events such as machine status, quantities, labor, downtime, and completion.
For example, an ERP may identify a production order by one number while a machine monitoring system uses a work-center identifier and a shop-floor operator records a status code. Interoperability does not mean copying every field into every system. It means defining how the systems relate, which system owns each value, and how changes move safely between them.
Why is ERP and shop-floor integration difficult?
ERP and shop-floor integration is difficult because the systems answer different questions at different points in the manufacturing process. The ERP plans and records business commitments. The shop floor reports what is physically happening. A scheduling system converts demand and capacity into a sequence of work. Analytics combines those signals, but cannot correct inconsistent source data on its own.
- Different levels of detail: An ERP may manage a work order while the shop floor records each operation, setup, run, quantity, and downtime event.
- Different timing: Orders may be updated in batches, while machine status changes continuously or whenever an event occurs.
- Inconsistent master data: A work center, part, employee, or routing may have different names or codes in different systems.
- Legacy equipment: Older machines may not expose data through a modern interface, requiring an adapter, gateway, manual entry, or carefully scoped file exchange.
- Unclear ownership: Two systems may both try to update the same due date, completion quantity, or status without a defined source of truth.
- Operational context gaps: A raw alarm or state change does not explain whether a job was waiting for material, in setup, blocked by quality, or intentionally paused.
NIST describes factory-floor machines as historically isolated islands of automation and documented a pilot that connected CNC production information to an ERP subsystem through OPC. The lesson is practical: successful integration starts with a defined business use case and a clear translation between machine events and enterprise information, not with a promise to connect everything at once.
Which data should flow between ERP, scheduling, machines, WIP, and analytics?
The best integration scope follows decisions, not system boundaries. Start with the events that change the schedule, the delivery promise, the cost record, or the next action on the shop floor. A useful data contract can be organized into five connected groups.
| Data group | Typical source | Examples | Operational use |
|---|---|---|---|
| Demand and orders | ERP | Customer order, item, quantity, due date, priority | Plan and promise work |
| Planning and capacity | Scheduling system | Routing, sequence, constraints, planned start and finish | Build a feasible schedule |
| Machine and labor events | Machine monitoring and operators | Run, idle, alarm, setup, downtime reason, labor activity | Compare plan with reality |
| WIP and completion | Shop-floor data collection | Operation started, quantity complete, scrap, hold, move | Advance work and update status |
| Performance and analysis | Analytics layer | Throughput, utilization, cycle time, variance, on-time status | Find causes and improve decisions |
Keep the first version narrow enough to test. For many discrete manufacturers, a high-value starting loop is order and routing data from the ERP into scheduling, planned work into the shop floor, actual starts and completions back into scheduling, and summarized progress back into the ERP. Analytics can then compare planned and actual performance without becoming the owner of operational transactions.
Which standards support manufacturing interoperability?
Standards solve different parts of the interoperability problem. A standard may define a vocabulary, an information model, a message transport, a device interface, or a boundary between business and control functions. No single protocol replaces data governance and mapping.
ISA-95 and IEC 62264
The ISA-95 framework, also known as IEC 62264, describes the relationship between enterprise functions and manufacturing control functions. The International Society of Automation explains that its models and terminology help define information exchanged between level 3 manufacturing operations and level 4 business systems. Use ISA-95 as a reference for boundaries, objects, responsibilities, and terminology before choosing an implementation mechanism.
OPC UA
OPC UA is a platform-independent architecture for industrial communication. The OPC Foundation describes capabilities including information modeling, subscriptions, events, security, and communication from machine to enterprise. It can be a strong fit when equipment and applications need a common way to expose structured operational information across vendors and operating systems.
MTConnect
MTConnect provides a domain model and vocabulary for manufacturing equipment. NIST’s Smart Manufacturing Systems Test Bed documentation describes how MTConnect can provide structured, contextualized equipment data through an adapter and agent model. It is especially relevant when a manufacturer needs consistent machine data for monitoring, analysis, or downstream applications.
MQTT
MQTT is a lightweight publish and subscribe messaging protocol. OASIS describes it as a transport designed for machine-to-machine and Internet of Things environments, including constrained devices and variable network conditions. MQTT can move events efficiently, but the payload still needs a defined schema, identity rules, timestamps, and governance before ERP or analytics users can rely on it.
In practice, a manufacturer may use more than one standard. For example, an equipment adapter can expose semantically organized data through MTConnect or OPC UA, an integration service can apply business mapping, and an event transport can distribute selected updates. Treat the standards as building blocks, not as a substitute for an integration design.
Talk with JobPack about connecting your ERP and shop floor data
How do you create a manufacturing data governance model?
Manufacturing data governance makes interoperability durable. It defines who owns a value, how it is named, how it is validated, who can change it, and how its history is retained. Governance should be operational enough for planners, operators, quality teams, IT, and finance to use, not a document that only an integration team can read.
- Assign system ownership: Decide which system is authoritative for orders, routings, schedules, machine states, quantities, downtime reasons, and quality holds.
- Define shared identifiers: Map part numbers, work orders, operations, work centers, resources, and employees across systems using stable keys.
- Standardize meaning: Document status values, units, time zones, reason codes, and the difference between planned, started, completed, scrapped, and held.
- Set data-quality rules: Reject or quarantine records with missing identifiers, impossible timestamps, invalid units, or quantities that do not reconcile.
- Control changes: Version mappings and code lists, record who approved changes, and test the effect on schedules, reports, and historical data.
- Protect access: Separate read, write, and administrative permissions, especially where machine or production data crosses IT and operational technology boundaries.
A useful governance test is whether a planner and an operator would interpret the same production event the same way. If they would not, adding another connector will only move the ambiguity faster.
What should a practical implementation plan include?
A practical manufacturing interoperability project creates a small, testable feedback loop before expanding to every system and machine. The following sequence limits risk while producing a useful operational result.
- Choose one decision: Start with a measurable decision such as updating a schedule when a machine finishes early or identifying work that is at risk of missing its due date.
- Map the current flow: Document where the order, routing, schedule, machine event, operator update, and completion record originate and where each one is consumed.
- Define the minimum data contract: Specify required fields, identifiers, status values, units, timestamps, delivery method, error handling, and ownership.
- Connect a representative slice: Use a limited set of orders, work centers, machines, or operations that includes both modern and legacy conditions where possible.
- Reconcile plan and actual: Compare planned start, actual start, planned quantity, actual quantity, planned completion, and actual completion. Investigate mismatches rather than hiding them.
- Test failure modes: Disconnect a source, send a duplicate event, delay a message, change a master-data code, and process a late correction. Confirm that the receiving systems fail safely.
- Measure operational value: Track data completeness, latency, reconciliation errors, schedule response time, manual touches, and the number of decisions supported by current data.
- Expand by use case: Add new machines, plants, analytics, or ERP transactions only after the original loop has an owner and a support process.
Integration is not finished when a message reaches its destination. It is finished when the receiving team can act on the message, the result can be traced, and an error has a known owner.
How does JobPack connect ERP and shop-floor information?
JobPack is built around the gap between enterprise planning and shop-floor execution. Its platform combines production scheduling, WIP booking, machine monitoring, analytics, and document or NC program management so manufacturers can connect planned work with actual operating conditions.
That architecture supports a feedback loop rather than a one-way export. ERP information can establish the demand and order context. A visual production schedule can account for capacity and constraints. Shop-floor data collection and machine monitoring can report progress, status, and events. Analytics can then help teams compare planned and actual performance and decide what needs attention.
The right integration boundary depends on the manufacturer’s ERP, equipment, workflows, and data-quality starting point. JobPack’s ERP integration experience is valuable in that discovery process because the objective is not to replace every system. It is to connect the systems that need to work together while preserving clear ownership and a usable experience for the people running production.
Manufacturers evaluating that approach can review production scheduling software, real-time machine monitoring, shop-floor data collection, and manufacturing data analytics. For a broader explanation of system roles, see ERP vs. MES vs. APS in manufacturing.
Frequently Asked Questions
What is the difference between data integration and data interoperability?
Data integration connects systems, while data interoperability means the connected systems can exchange and use information with its intended meaning. An interface may transfer a value successfully but still fail to interoperate if the receiving system cannot interpret the identifier, unit, status, timestamp, or business context.
Is ISA-95 a software integration protocol?
No. ISA-95 is a standard framework for modeling enterprise and manufacturing operations information, responsibilities, and interfaces. It can guide the design of an integration, but it does not replace an API, message broker, file exchange, OPC UA connection, or other transport mechanism.
Should manufacturers use OPC UA or MQTT?
OPC UA and MQTT address different needs and can be used together. OPC UA provides industrial information modeling and services, while MQTT provides lightweight publish and subscribe message transport. The right choice depends on the equipment, required semantics, network conditions, security design, and receiving applications.
How can a manufacturer connect legacy machines?
Start by identifying the machine’s available interfaces, controller data, and safe collection method. An adapter, gateway, file exchange, or operator workflow may be appropriate depending on the equipment. The integration should define which events are reliable enough for scheduling or analytics and how missing or delayed data is handled.
What is the first step in an ERP and shop-floor integration project?
Choose one operational decision and map the minimum data needed to make it. Then assign system ownership, define shared identifiers and status meanings, connect a representative slice, and reconcile planned versus actual results. A small feedback loop is easier to test and improve than a broad, undefined integration program.
