A production efficiency number lands in a weekly review. Someone questions whether it reflects actual output or scheduled output. Someone else wonders whether quality holds are included. A third person pulls a different figure from a different screen. The meeting moves on without resolution, and the number gets used anyway.
This is not a technology failure. It is a record-structure failure. The KPI was aggregated before the underlying records were reconciled, and no one had defined whose version of the fact was authoritative. Fixing that requires understanding what makes a manufacturing record trustworthy in the first place.
What a Trusted Manufacturing Record Actually Is
A manufacturing record is trusted when it can be traced back to the event that created it, when its meaning is unambiguous to every function that uses it, and when it has a defined owner responsible for its accuracy. Those three conditions are independent. A record can be traceable but ambiguous. It can have a clear owner but no link to the originating event. It can be precise in one system and contradicted by another.
NIST's Advanced Manufacturing Data Infrastructure and Analytics program describes the goal as trusted, understandable, and reproducible information workflows across manufacturing enterprises and supply chains. Each of those words carries weight. Trusted means the record reflects what actually happened. Understandable means every function reading it interprets it the same way. Reproducible means the same query run twice returns the same answer.
NIST's supply chain traceability work states that individual traceability records should be structured to support supply chain risk management decisions, including procurement requirements and regulatory obligations, and that data must be presented so that multiple organizational functions, including engineering, legal, and operational teams, can interpret and apply it. The same logic applies inside a manufacturing operation. A record that only production can read is not a decision-support record. It is a departmental log.
Where Manufacturing Records Come From and Why That Matters
Planning systems, execution systems, and quality systems each generate records from different events at different points in the operating flow. A quality management system (QMS) records inspection results, holds, dispositions, and nonconformances. A warehouse management system (WMS) records physical inventory movements and confirmed receipts. Each of these is a source of events, not a source of governed measures.
The distinction matters. An event is a timestamped fact: a job completed at 14:32, producing 47 units, with 3 held for inspection. A governed measure is a derived number: the shift's yield rate, the week's on-time completion percentage, the month's first-pass quality rate. The governed measure is only as reliable as the events beneath it, and those events come from systems that do not automatically agree.
In a design where a planning system holds a scheduled quantity and an execution system holds a completed quantity, those two numbers may describe different things. The planning number reflects what was scheduled. A KPI that combines them without labeling which is which may conflate two distinct facts.
The Reconciliation Problem
Reconciliation is the work of confirming that records from different systems describe the same event in compatible terms before combining them into a measure. It requires four things to be defined: time, unit, location, and status.
Time alignment asks whether two records refer to the same period. A production count reported at shift end and a quality hold recorded the following morning may both belong to the same job, but if the reporting cutoff differs between systems, they will appear in different periods. Unit alignment asks whether the quantities are expressed in the same terms. An execution system may report in pieces; a planning system may schedule in cases. A WMS may receive in pallets. Location alignment asks whether the records refer to the same physical or logical point in the process. Work-in-process inventory at a work center is not the same as finished goods inventory at a staging location, even if both carry the same part number. Status alignment asks whether the records reflect the same state of completion.
A job marked "complete" in an execution system may still be under quality review in a QMS. Counting it as finished output before the hold is resolved overstates available inventory.
None of these alignments happen automatically when systems are connected. Integration moves data across a boundary; it does not resolve semantic differences. A record that arrives in a data platform from three systems is still three records until someone has defined the rules that make them one.
When Aggregation Runs Ahead of Reconciliation
The practical consequence of aggregating before reconciling is that a KPI can be precise and wrong at the same time. It will be internally consistent within the logic of the reporting tool, but it will not reflect operating reality because the inputs were not comparable.
NIST's supply chain traceability work states that aligning to this principle, structuring records to support decisions rather than accumulating data, shifts the focus from data hoarding to targeted intelligence. A yield KPI needs to specify which operations are included, which quality dispositions count as failures, which time boundary applies, and which location is in scope. Those definitions belong in the record structure, not in a footnote to the dashboard.
Limitations of This Framework
The reconciliation rules must be maintained as processes change. When a new work center is added, when a quality hold category is renamed, or when a supplier changes a unit of measure, the reconciliation logic needs to be updated. If it is not, the KPI will silently drift from reality without triggering an error.
Ownership is also a governance question, not a system question. A system can enforce a rule, but it cannot decide who is accountable for keeping the rule current. That decision belongs to the people running the operation. Assigning a record to a system without assigning a human owner for its accuracy leaves the record without a path to correction when something changes.
Finally, reconciliation takes time and effort. The right response is not to reconcile everything before acting on anything. It is to know which records feed which decisions, reconcile those specifically, and be explicit about which measures are still unreconciled estimates.
Applying This Before Your Next KPI Review
The following checks are professional judgment derived from the principles above. They are not a guarantee of any specific outcome, and some questions are ones only your team can answer based on your actual system design.
-
Identify the source event for each input. For every number that feeds the KPI, ask which system generated the underlying event and what that system was recording at the time. If you cannot name the source event, the KPI has no traceable foundation. Does each contributing system record a timestamped event, or does it hold a running total that gets overwritten?
-
Verify alignment across time, unit, location, and status before combining records. A mismatch in any one of these means the KPI may be combining unlike things. Are your execution and planning systems using the same shift cutoff? Do your QMS hold statuses feed the same period as your completion counts? Do your systems express quantities in the same unit, and do they refer to the same physical or logical point in the process?
-
Separate planned quantities from reported quantities. If the KPI blends scheduled quantities with reported quantities, separate them before drawing a conclusion. Planned and actual are both useful; combined without labeling, they describe neither the plan nor the result accurately.
-
Name a human owner for each source record. For each record type feeding the KPI, identify who is responsible for its accuracy and who has authority to correct it. A record without a named owner has no path to correction when a process changes or a system is reconfigured.
-
Write down the reconciliation rule explicitly. Document how records from different systems are combined into the measure. If the rule exists only inside a reporting tool's configuration, it is invisible to the people who need to validate it and will not survive a system upgrade or a process change.
These checks do not require a new system. They require a decision about what each record means, who owns it, and what rules govern its use. Technology can enforce those decisions and move data across boundaries more reliably, but the decisions themselves are operating design work that precedes any system choice.
