Industrial Monitoring Pilots: How to Move From PoC to Operations
Industry Operations Note 6 of 6: from pilot to operations
The dashboard shows its first anomaly and the pilot starts to feel finished. Operations asks different questions: who reviews the alert, what inspection follows, and who keeps the sensors and the system healthy. When those answers are missing, technical validation ends and field work stays the same.
A 2019 ASME subcommittee white paper co-authored by NIST researchers puts the starting point at the use case: name the safety, environmental, cost, or operational improvement you are after, and record current maintenance practice and condition-monitoring readiness as a baseline. A pilot can then test whether a real maintenance decision changes, instead of stopping at a model score.
One sentence for the use case
Asset, condition change, and the decision the recipient will make: a workable use case names all three. A goal as broad as "detect equipment anomalies" cannot define the data you need or the point where the pilot is done. The sentence is complete when it says which signal change opens a field inspection and who opens it.
Safety stops and production changes stay where they were. A pilot alert is not a reason to bypass existing authority and approval.
Write down how the asset is managed today
Before the pilot, record current practice: when inspections happen, who responds to a failure, and where maintenance results are stored. The baseline is what separates a real change in work from the same work moved to another screen.
Check data readiness in the same pass. Are asset identifiers consistent? Can sensor position and operating context be retained? Can signals link to maintenance history? Where records are fragmented, decide what the pilot must clean up first.
Figure 1. An operating loop from the use case and baseline through data readiness, maintenance work, and review.
An alert needs a next action
Define the loop that starts when an alert arrives: an owner reviews the signal and operating state, opens a field inspection or work order when needed, and links the result back to the monitoring record.
Posting the alert to a chat channel is the start of the workflow, not the workflow. Name a backup owner, a way to find unhandled alerts, and the evidence that closes a field check.
The deployment decision is bigger than model metrics
Model metrics belong in the technical review; they do not settle deployment. Just as much depends on whether the owner can understand why an alert fired, handle it inside existing maintenance procedures, and notice a sensor or network problem.
Compare pilot alerts against actual field findings, and keep the false ones too: alerts caused by operating changes or sensor issues. That record is what justifies adjusting criteria and choosing the next scope.
The day after the pilot team leaves
Someone has to run the system once the pilot team steps away. Decide who watches sensor and gateway health, who manages user access, alert criteria, and processing versions, and who handles incidents and supplier contact. When a setting changes, record the reason, the approver, and the effective date.
A periodic review is not an alert count. Ask which alerts led to inspections and actions, whether operating conditions have drifted enough to revisit criteria, and whether data with no remaining purpose keeps accumulating.
A last check before handoff
- A one-sentence use case naming the asset, the condition change, and the field decision
- The current inspection and maintenance workflow, recorded as a baseline
- Records that keep asset identity, sensor position, and operating context attached
- A primary and a backup alert reviewer
- A path that links inspection and work-order results back to the signal
- Owners for system health, setting changes, and incident response
XyloZero facility monitoring connects edge collection to dashboards, alerts, and PLC or SCADA systems; the test is whether that path fits how the site actually runs maintenance.