Monitoring deployments fail in recognisable ways, and the diagnosis determines the fix.
Measuring before cleaning
The symptom: confident findings that surprise everyone who works on the floor.
The cause: clock drift, batch scanning, open tasks, stale master data.
The correction: data quality first, always, with the exclusion rules documented and the anomaly rate reported alongside every figure.
Reporting with no changes
The symptom: a dashboard, a monthly report, and an operation that runs exactly as before.
The cause: the programme was scoped as reporting, with no owner able to change anything.
The correction: one finding, one owner, one date, re-measured. Report the change, not the analysis.
Leading with individual measurement
The symptom: resistance, degraded scan discipline, exception reporting falling.
The cause: the programme was read as aimed at people, correctly.
The correction: aggregate by default, fix a process problem visibly first, consult, and write down the purpose limitation.
Buying before knowing
The symptom: a platform scoped to a vendor's capability, covering questions you did not have.
The correction: join and analyse what exists, identify the specific gaps, then procure against them.
Substituting monitoring for the physical fix
The symptom: proximity detection in an aisle that should have a barrier.
The correction: report monitoring as a supplement with the primary control and a date named, or the interim measure becomes permanent.
Optimising a non-constraint
The symptom: a stage improves and throughput does not.
The correction: identify the constraint first, and expect no gain from anything else.
Targets before understanding variation
The symptom: gaming, and a rise in exceptions or injuries alongside the improvement.
The correction: establish the normal range before setting any expectation, and apply the safe-method test to any rate target.
Purpose drift
The symptom: safety data appearing in a performance conversation.
The consequence: under-reporting of the safety events the data existed to find.
The correction: enforce the limitation architecturally — separate streams, logged access — rather than by policy, and decide the first hard case in advance.
No owner
The symptom: the project ended, the pipeline broke, the numbers are now a year stale and still quoted.
The correction: a named owner with allocated time, and a data quality measure reported monthly so decay is visible before it is total.
The common thread
Every one of these is a case of measuring the deployment rather than the operation.
Sensors installed, dashboards built, data points collected — all rise while waiting time, travel and exception rates stay exactly where they were.
Reporting the operational measures from the first week is the single most effective preventive step, because it makes the difference visible while there is still time to correct it.
Diagnosing a stalled programme
Most stalls have one of a small number of causes.
No owner with operational authority. Re-establish sponsorship inside operations.
Measured on activity, so nobody noticed nothing changed. Change the reporting to the operational measures.
Data quality never addressed, so findings are disputed. Fix it and publish the quality measures.
Started with individual measurement, so cooperation degraded. Aggregate, consult, and fix something visible.
Bought before analysing, so the tool answers questions nobody had.
Diagnose before proposing more tooling, since a platform purchased to restart a stalled programme usually stalls with it.
The recovery move
For a programme that has deployed sensors and changed nothing.
Publish the operational baseline: waiting by stage, travel per line, exception rate by origin.
Pick the largest single loss and fix it, visibly, with the floor involved.
Re-measure and report, including if it did not work.
Publish the purpose limitation and enforce it, which addresses the cooperation problem in the same move.
One quarter of work, and it converts a data collection exercise into a programme.