Scope a shop-floor data pilot around one production decision
For operations leaders, IT teams and integration owners · Plan implementation
TL;DR — what you’ll learn
- Choose the operational decision before choosing sensors, screens or dashboards.
- Capture the minimum events and identities needed to support that decision.
- Pilot one line or routing in shadow mode, with missing and corrected events visible.
- Measure decision usefulness, completeness and operator effort before expanding instrumentation.
A factory installs machine monitoring and receives detailed running/stopped signals. The planner still cannot tell which job needs intervention before the next operation because the signals are not connected to job identity, quality status or the handover queue.
Shop-floor data collection should begin with a bounded question. For this pilot: can the supervisor identify jobs that are ready for the next operation but waiting for an owned action? Equipment state can contribute, but it is not automatically the answer.
Define the decision and the event set
Choose one routing with a known handover delay. The supervisor needs job/operation identity, quantity and unit, readiness state, ready time, next-operation start time and the owner of any exception. If quality release is required, use its approved state rather than inferring readiness from machine completion.
At the 10:00 review in this illustrative shift, the records show:
| Job | Ready for next operation | Next operation starts | Observed wait |
|---|---|---|---|
| J31 | 09:05 | 09:40 | 35 minutes |
| J32 | 09:20 | 09:30 | 10 minutes |
| J33 | Ready event missing | 09:50 | Unknown |
| J34 | 09:10 | Not started at 10:00 | 50 minutes elapsed; still waiting |
The two completed ready/start pairs have a mean wait of (35 + 10) / 2 = 22.5 minutes. That is a completed-wait measure, not the state of the current queue. J34 has already waited 50 minutes and needs a current owner/action; its eventual completed wait is still unknown. Do not give it zero wait or omit it from the active queue.
Readiness timestamps are present for 3/4 jobs, or 75%. Completed ready/start pairs cover 2/4, or 50%, but J34's missing start is an observed open state, whereas J33's missing ready event is a data defect. Keep those reasons separate. J33's wait is unknown, not zero.
The sample does not establish a target or cause. J34 might be waiting for an operator, tool or priority decision. The supervisor needs the reason and owner to choose an intervention.
A missing event is a decision input
Scroll horizontally to explore the full diagram, or open the text version below.
Read the complete workflow as text
- Named production decision and owner → Capture minimum identified events
- Capture minimum identified events → Complete and consistent evidence?
- Complete and consistent evidence? → No: Visible data exception with owner
- Complete and consistent evidence? → Yes: Supervisor reviews queue and chooses action
- Visible data exception with owner → Correct and reconcile source events
- Correct and reconcile source events → Capture minimum identified events
- Supervisor reviews queue and chooses action → Measure usefulness and capture effort
Prefer the least burdensome reliable capture
An operator confirmation may establish readiness more accurately than a machine signal that only indicates cycle completion. Barcode scanning can add job identity. A read-only equipment interface can contribute timestamps when engineering confirms the signal's meaning and limitations.
Compare these choices on evidence quality and capture effort. A paper or existing ERP event may be sufficient for the first baseline. Do not deploy sensors broadly until the team can show which missing fact changes the decision.
NIST's OT guidance treats performance, reliability and safety as important context for connected operational systems. Review any equipment interface with the plant's authorised engineering/security owners. NIST OT security guidance.
Make the data contract explicit
Required fields include event ID, job, operation, quantity/unit, event time with time zone, capture time, source, applicable state and correction relationship. Preserve the original timestamp and a later correction rather than overwriting the history. Distinguish a missing event from a confirmed zero quantity.
Production defines what ready means. Quality supplies any required release status. The supervisor owns the queue decision. IT owns data transport and monitoring; engineering approves equipment connectivity. A model-generated reason can be a suggestion, but it is not an observed fact until reviewed under the agreed process.
If a device clock drifts, the apparent wait can become negative. Flag the inconsistency and investigate the clock/source before calculating performance. If job identity is missing, retain the event in an exception queue rather than assigning it to whichever job happens to be scheduled.
Run the pilot alongside the existing decision
Bound the work to one line or routing and the stated handover question. Integrate only the approved ERP/job records, operator capture and any reviewed read-only signal needed. Exclude machine-control changes, worker scoring and broad predictive-maintenance claims.
Baseline decision latency, event completeness, reconciliation gaps and capture effort across representative shifts. Track elapsed open waits at a stated review time separately from completed waits, so excluding long-running open cases cannot make the queue appear faster. Have the supervisor record whether the proposed queue led to a useful action and what evidence was missing. A faster refresh rate is not a business improvement if the queue remains untrustworthy.
Test J31/J32/J33/J34 with an outage, missing identity, incorrect count, delayed quality status, duplicate event and timestamp correction. Acceptance requires incomplete records to remain visible, corrected waits to be explainable and each queue item to reach an accountable owner. Verify against independent observation or approved records, not just another chart using the same feed.
Agree operating targets after the baseline and shadow period. On outage, use the approved manual record and handover process. Reconcile queued events before resuming; preserve unresolved cases instead of filling gaps with estimated facts presented as observations.
AI may help group reviewed reasons or summarise the queue. It should earn its place only if it improves the chosen decision and exposes its uncertainty. The first useful result may be a reliable event join and a simple exception list.
A shop-floor data pilot is successful when the supervisor can act on a trustworthy answer to one operational question. That evidence provides a sound basis for the next investment.
- Name the production decision and the person who will use it.
- Collect the minimum event set and measure both completeness and effort.
- Shadow the decision through missing and corrected records before adding more equipment or analytics.
Discuss this pilot with NextEdge Labs using the routing, current data sources and the decision that still depends on manual investigation.
Scope this automation around your operation
Tell us your current systems, transaction volume and the exception you need to resolve. We can discuss a focused first release, its review controls and how to measure the result.
Sources and further reading
Sources checked 15 October 2026. Worked examples and workflow diagrams are original illustrations, not reported client results.