A customer is promised a ship date from the ERP system. Meanwhile, a machine on the floor goes down, a job is held, or a lot moves to a different step. If that change never reaches planning, the promise rests on a schedule that no longer matches the plant. This guide asks which production facts need to cross from shop-floor systems into ERP, planning, quality, inventory and customer-commitment work, and which responsibilities should stay with plant specialists.
The retained evidence is research from the National Institute of Standards and Technology (NIST), most of it from the 1990s plus one 2016 journal paper. It covers information exchange between business and shop-floor applications.
The problem: facts that never leave the shop floor
In a NIST paper on reactive scheduling, Frank Riddick describes individual manufacturing applications that become "islands of information" within an enterprise. He adds that important information then sits isolated because the applications cannot exchange it with one another.
The same paper describes how this plays out in scheduling. Once a schedule is in operation, events often happen which may "break" the optimization. Production then continues inefficiently. According to the paper, scheduling applications typically can produce schedules that account for such events, but usually there is no mechanism for communicating the information about those events back to them.
A 2016 paper in NIST's Journal of Research addresses the same theme. It says that lack of integration between these systems (PLM, SCM, ERP, MES and devices) in operating factories often results in suboptimal benefits. One example it gives is that essential data have to be estimated because dated equipment cannot supply them.
For a manufacturer, this can show up as duplicate entry, manual reconciliation and commitments made on stale information. Whether those symptoms appear in your plant is something to check in your own records.
Causes and constraints
Two constraints shape the answer. The first is that several systems hold overlapping information. The NIST journal paper says resource management functions in ERP, MES, PLM and a digital manufacturing tool overlap. It says ERP and MES manage resource information related to the factory operation including real-time status, and that this resource information needs synchronization. For inventory, it says inventory information needs to be synchronized between ERP and supply chain management systems.
The second constraint is that standards do not settle the question. The same paper reports that existing standards support integration where software functions overlap, but these standards do not fully cover the functions and are not necessarily mutually compatible.
The rest of your own constraints (data ownership, permissions, integration capacity, and the capacity of the plant to absorb change) are specific to your operation. They decide how much of the following can be done at once.
Which production facts should cross
The NIST reactive scheduling work offers a concrete, if dated, starting model. It tracks shop floor status through four entity types: loads, resources, buffers, and materials. A load is a group of parts being transformed into finished products. The paper says a load's attributes include a unique identifier, the planned start and due date, the related product, the current job step, the starting number of pieces, and its processing state. A load's status shows whether it has started a job step, has been held or interrupted because of a production problem, or has completed all processing.
For resources (machines, operators, tools and fixtures), the paper lists states such as available, busy, in preventive maintenance, broken, undergoing setup or tear down, or not scheduled that shift. It also notes that these four entities are a minimal set. They are not intended to exhaustively describe all aspects of factory operations, only to give a common model sufficient to communicate important production events to the scheduler.
The exchange mechanism is the status message. In the paper, such messages carry the information needed to create, modify or destroy a factory entity, and each one associates it with a particular factory entity and defines a new state. A related NIST report, IMES II, was written to specify the information required for the exchange of information between shop floor scheduling and shop floor data collection applications.
This supports a practical reading for executives. The facts worth moving upward are identified, stateful events: which job, on which resource, in which state, and when. Raw machine signals are a different matter. Whether any given signal should reach ERP is a design decision, not something these sources settle.
Approaches to compare
The sources describe a shared information model and an overlap-handling option. They do not rank them.
A defined, shared information model. In the NIST reactive scheduling paper, Riddick says integrating manufacturing applications requires a more flexible and cost-effective integration approach. NIST's Systems Integration for Manufacturing Applications program aimed to develop potential information exchange and interface protocol standard solutions for manufacturing integration. In a response to an industry request for information, NIST staff proposed a partitioning of MES by categories of data related to MES versus actions on that data, with a suggested componentization of interfaces. The lesson for a buyer is to agree on which entities and states are exchanged before choosing how they are carried.
Consolidating or layering overlapping functions. The 2016 NIST journal paper lists production planning as an area where both MES and DM have a function to make a production plan. The paper also says that resource management functions overlap across several applications, including ERP, MES and PLM. For that planning overlap, the paper states that production planning functions should be consolidated. It also offers an alternative: DM can be configured as an advanced planning system that provides necessary modifications to the MES plan. For an owner, this is a reminder to decide where planning authority lives before adding connections.
Targeted integration versus custom point-to-point work. The Riddick paper notes that many businesses have attempted to overcome this problem by implementing custom, point-to-point integration solutions. Weigh any targeted integration you consider against that history by asking what it would cost to maintain and how many other applications it would need to work with.
The brief also named extending existing systems, leaving the platform unchanged, reporting or portal patterns, and governed Software implementation. The retained research does not evaluate those, so the choice among them depends on a local assessment of your stack and your own error and rework history.
Tradeoffs
A minimal shared model keeps the exchange small, but it leaves out detail. The NIST paper itself says its entity set is not intended to exhaustively describe all aspects of factory operations. Each fact added to the exchange needs an owner, a definition and support.
Weigh that against the effort of agreeing on a shared model, and ask how much effort a single pairing of systems would take in your environment.
The 2016 paper's example of estimated data from dated equipment shows where accuracy can fail at the source. The value of any feed depends on the accuracy of the data behind it, so the people who rely on an estimated number should know it is an estimate.
Architecture work is also iterative and has limits. NIST's earlier Manufacturing Systems Integration report describes a testbed architecture and says it briefly describes the initial implementation of the architecture and limitations found along the way. Expect your first design to need revision.
One evidence caveat applies to all of this: the reactive scheduling prototypes ran against a simulation of a shop floor instead of a real shop floor. Treat them as a model for the information, not as proof of results in a live plant.
Next steps and reader application
Use these steps to apply the lesson. They are recommendations, not findings from the sources.
- Separate four kinds of information. List what is a business transaction (orders, receipts, invoices), what is production execution (job and resource status), what is telemetry (raw signals and readings), and what is real-time control. For each telemetry item, decide explicitly whether it should inform ERP and planning.
- Define each fact before connecting it. For every fact you want to cross, write down its identifier, how it is timestamped, what each state means (for example, what "held" or "complete" means for a job), how a missed or delayed message is buffered, and how the receiving system acknowledges it. The NIST entity and status-message model shows the level of precision involved.
- Tie each fact to a decision. Ask which promise, plan, quality release or inventory movement changes when this fact changes, and who acts on it. Drop facts that nobody acts on.
- Check the overlaps. For resources, inventory and production planning, name the system that holds authority and the one that receives updates.
- Settle the boundary conditions with plant specialists. Latency needs, safety implications, availability expectations and what happens when a link is offline are matters for plant engineering, equipment manufacturers, controls integrators and cybersecurity specialists. Confirm who fills each of those roles. Ask them to define the interfaces through which business systems read from the control layer, and keep changes to control behavior with them.
- Start with one narrow flow. Pick one product line or one class of order, and test whether the shared facts improve the accuracy of customer commitments before extending the model.
The answer to the opening question is therefore a short list. Move identified, stateful production events that planning, quality, inventory and commitments act on. Leave real-time control, safety and equipment behavior with the specialists who own them.
