When the Spreadsheet Is the System of Record
Operating visibility breaks down in a specific way. Someone pulls numbers from the ERP (Enterprise Resource Planning system). Someone else pulls from the shop floor report. A third version lives in the spreadsheet the operations manager actually uses. By the time the three versions agree, the decision window may have closed.
This is not a reporting problem. It is a data ownership and integration problem that reporting is being asked to solve.
NIST describes turning manufacturing data into meaningful intelligence as difficult, with a robust data infrastructure as the necessary foundation for building on advanced and emerging technologies. The gap is structural. Data exists across systems.
Where the Relevant Facts Originate
Operating data does not live in one place. A manufacturing execution system (MES) tracks production status and routing. A warehouse management system (WMS) manages inventory positions and movements. A quality management system (QMS) captures holds, defects, and inspection results. Data also moves through APIs, flat files, and purpose-built data platforms.
Each system carries its own ownership, access controls, and update cadence. Inventory positions in the WMS may lag actual counts. A quality hold may not surface in fulfillment logic until a shipment is already short.
When no governed connection exists between systems, a person fills the gap.
How Facts Cross System Boundaries
Data crosses system boundaries through one of three mechanisms: a direct API connection, a file-based transfer, or a data platform that consolidates records from multiple sources.
A direct API connection can move a record from one system to another in near real time. A file-based transfer moves data on a schedule, which introduces latency.
Microsoft Dynamics 365 Business Central, for example, provides Power BI reports, ad-hoc analysis on lists, and built-in manufacturing analytics tools covering utilization, capacity, production time, scrap, and cost variance. That capability works within the boundary of what Business Central holds.
The Production performance Power BI content for Dynamics 365 Finance and Operations uses aggregate measurements staged in an Entity store, a SQL Server database optimized for analytics. That architecture works within the Finance and Operations boundary.
Both examples illustrate the same principle. A system's built-in analytics answer questions about data that system owns. Cross-system questions require a governed connection.
Where Governed Data Connections Apply
Each describes a condition where the relevant facts may span more than one system boundary.
When the same concept, such as inventory quantity or order status, can originate in the ERP, the WMS, or a spreadsheet, no single version is authoritative without a governed rule that says which one is.
Without a defined reconciliation rule, two systems can each report a valid number that still disagrees with the other.
In each case, the use case is not satisfied by adding a report. It is satisfied by defining ownership, connection, and cadence at the boundary where the gap exists.
What a Governed Implementation Plan Requires
The reader decision here is concrete: which requirements belong in a governed implementation plan?
A governed plan addresses these requirements:
Record ownership. For each operating domain, demand, orders, production, materials, inventory, quality, capacity, shipping, and exceptions, identify which system holds the authoritative record. Ambiguity here is the root cause of reconciliation work.
Integration boundary definition. For each cross-system question, define how data moves: API, file, or data platform. Document the update cadence and the latency each method introduces.
Transformation and reconciliation logic. When the same concept, such as order status or inventory quantity, is represented differently across systems, the plan must define how those representations are reconciled.
Data quality checks. NIST's AMDIA program focuses on data collection, transformation, traceability, and interoperability as the foundation for trusted analytics. A governed plan defines what a valid record looks like at each boundary and what happens when a record fails that check.
Access and permissions. Each system boundary carries its own access controls. A governed plan defines who can read, write, and publish data at each layer.
Latency and freshness requirements. Different decisions tolerate different data ages. A daily production summary can use yesterday's data. An exception alert cannot. The plan must match the data delivery cadence to the decision it supports.
What This Does Not Resolve
It does not select the implementation approach.
NIST notes that technologies are seldom one-size-fits-all solutions and that research into manufacturing data and the role of humans in the process is needed to effectively adopt and integrate solutions into existing operations. That observation applies directly here.
The requirements belong in the plan first. The implementation follows from them.