01 / Inside the engagement
Situation
Factory dashboards used hand-set thresholds nobody could defend, and existing alerts had missed a real event. Operators either drowned in false alarms or missed the ones that mattered.
Before
- Sensor signals
- Hand-set thresholds
- Factory alerts
After
- Sensor history
- Validated statistical limits
- Reusable alerting
Simplified workflow. The case text describes the contribution, delivery stage and evidence.
Explore the full conceptual diagram
02 / Inside the engagement
What UTIS did
- Our business analyst ran structured sessions with operators and area managers to define the thresholds the business could stand behind.
- Our data engineer analyzed weeks of sensor and failure-window history, derived statistical process-control limits validated with a data scientist, and built a reusable, config-driven alerting engine covering five sensor types.
- Designed the engine for reuse across factories through configuration, with rollout staged after validation.
03 / Inside the engagement
Results
- During development, the alerting flagged out-of-spec readings that led engineers to an out-of-tolerance machine, stopped for inspection before it produced scrap.
- Business case: ~25% fewer false alerts and 8–10 operator hours a week (projected), and unplanned breakdown hours converted into scheduled maintenance (target).
Why it matters to you
Operator input and statistical validation give an alerting threshold an explainable basis. One incident demonstrated the alerting during development; reduced false alerts and operator effort remain projected benefits to validate through rollout.
Stack
How we measured it: one observed incident; the savings are projections from the agreed business case.