Production performance tracking starts with a reliable event and state model. Before assigning percentages to machines, agree on what counts as operating time, planned downtime and good production. If different people interpret the same input differently, a dashboard will not resolve the disagreement; it will simply turn it into numbers.
Choose dependable first measurements
Machine state, total count, good count and product or recipe identity can be useful initial inputs. Do not assume they are available from the PLC. Confirm them using documentation and field observation. A running bit may mean the machine is energised or cycling empty rather than producing a saleable unit.
Shift schedules and planned production periods also affect interpretation. A machine switched off outside scheduled production should not automatically become a production loss. Keep plan changes and exceptions traceable so later corrections to a reporting period can be explained.
Agree on a state model
| State | Meaning | Context needed |
|---|---|---|
| Producing | Processing under a defined condition | Product, recipe and count |
| Waiting | Ready but not producing | Material or operator reason |
| Fault | Stopped because of a defined failure | Fault and maintenance context |
| Unknown | Insufficient trustworthy information | Gap or signal-quality issue |
Define precedence when multiple signals are active. Specify whether transition time comes from the PLC or from the collector detecting a change. That difference affects the precision of calculated intervals. Filtering short transitions should be documented consistently across screens and reports.
Illustrative pilot
Start with one machine and one product group. Compare a shift of automatic event records with operator observations. Mark planned breaks, product changes, short waits and faults. The outcome is validation of the data model, not an unsupported claim of productivity improvement.
Test counters that reset at shift boundaries or machine restart. Naively subtracting readings can produce negative or excessive production. If product changes alter the expected cycle time, one fixed target cannot describe all production fairly.
Avoid misleading conclusions
High utilisation is not always a desirable outcome: it may include defective or unnecessary production. Low utilisation may reflect planned maintenance or limited demand. Show product, shift and planning context alongside the measure. A percentage alone rarely explains the reason for a difference.
Do not convert a network outage into downtime. Report unknown duration separately and show which data supports the calculation. Estimated reasons should remain distinct from confirmed reasons. Late data may require recalculation under an explicit update policy.
Decide whether to expand
Before extending the pilot, agree on the signal dictionary, transitions, operator-confirmation method and missing-data policy. Combined indicators such as OEE become useful after their inputs are dependable. The owner of the data model and its change process should also be clear.
A new recipe or PLC program change can otherwise alter meaning while the software continues to show plausible results. Include integration checks in the maintenance process, retain the assumptions used by reports and make it possible to trace a summary back to events. Those practices make performance tracking an explainable operating tool rather than a collection of disconnected scores.
Validate a shift before designing a scorecard
Create an illustrative timeline with the production team. Include scheduled production, a planned break, a material wait, a fault and an interval where data is missing. Ask an operator and a supervisor to classify the same timeline independently. Disagreement reveals an unresolved definition that should be settled before the application turns the events into a performance number.
Keep both the original observations and the interpretation. A fault signal can be recorded automatically while its operational reason is confirmed later. The person making a correction should provide enough context to explain it. Replacing the original event without a trace makes it difficult to distinguish a better explanation from an accidental change to evidence. The reporting model needs to show which values remain provisional.
Use counts carefully around shift and product boundaries. If a counter is read before a break and again after a recipe change, its difference may span more than one relevant production condition. The source may provide the events needed to split the interval; otherwise the report must acknowledge the uncertainty. Do not allocate counts with unjustified precision simply to fill every cell in a table.
Choose acceptance evidence that supports daily use
A practical pilot can evaluate coverage, traceability and consistency before claiming an improvement in output. Coverage asks how much of the intended period has dependable data. Traceability asks whether a displayed interval can be followed back to its source. Consistency asks whether the agreed definitions produce the same result in a manual example and in the application.
Include a deliberate counter reset, a duplicate event and an event arriving late. Observe whether the period totals change appropriately and whether the reason is visible. Test the operator correction process with ordinary user permissions, including a person who should not be allowed to change the selected equipment. A polished report is not ready for operational use if anyone can silently rewrite its inputs.
After acceptance, compare periods only with their product mix, schedules and operating conditions available. A pilot may make an existing loss visible without itself reducing that loss. Improvement requires an operating response and a comparison that accounts for other changes. When discussing a performance-monitoring project, bring a sample shift plan, the available machine signals and the decisions made at the daily review. They provide a more useful starting point than a request for a single percentage for every machine.