title: "Predictive maintenance for a mid-market AU manufacturer" dek: "A 2025 deployment on 47 production-line assets that flagged 19 failure-onset events before downtime. Unplanned downtime fell 62%." sector: "Industrial & Logistics" client: "Mid-market AU manufacturer · 3 plants · 47 critical assets" engagement: "Audit → Pilot → Practice Retainer" duration: "22 weeks" year: "2025" outcome: "Unplanned downtime: -62% · 19 failure-onset events caught before failure · A$2.7M downtime avoided" solution: "Sensor-stream anomaly model + maintenance-history context retrieval + on-call alerts with maintenance-team override." timeSaved: "~340 hours/year of unplanned downtime avoided · A$1.40 per asset-day monitored" visual: "none" cardFigure: "gauge" timeMetric: "341 hrs" timeMetricLabel: "downtime avoided / yr" costMetric: "A$1.40" costMetricLabel: "per asset-day" speedMetric: "62%" speedMetricLabel: "less unplanned downtime" publishedAt: "2025-08-21" keywords:
- predictive maintenance AI
- manufacturing AI Australia
- industrial IoT
- asset performance monitoring
The problem
A mid-market AU manufacturer — three plants, around 380 production staff, 47 production-line assets the COO classified as "critical" (meaning a failure stops a production line) — was running reactive maintenance on most of those assets. Sensor data was being collected by the asset-management system but not analysed. The maintenance team responded to failures, then scheduled root-cause analyses, then planned the next round of preventive work based on the analyses they had time to write up.
The COO had measured 547 hours of unplanned downtime in FY24. At a contribution-margin loaded cost of ~A$4,950 per hour, that was ~A$2.7M in lost production. He wanted that number down. He'd already paid for the sensors. What he didn't have was anyone who could turn the sensor data into actionable signal.
What we did
Four weeks of scoping (we walked every asset and read every preventive-maintenance manual), thirteen weeks of build, four weeks of staged pilot at one plant, one week of rollout to the other two. The deployed system:
- Streamed sensor data from the existing asset-management platform into our analysis pipeline (running in the firm's Azure tenancy)
- Trained a per-asset anomaly model on the prior 18 months of sensor + maintenance-event history
- Retrieved relevant maintenance-history context when an anomaly was flagged — "this asset showed similar vibration drift before the 2024 Q2 bearing failure"
- Pushed alerts to the maintenance team's on-call rotation through Teams with severity-tiered routing
- Required a human acknowledgement and routing decision for every alert — the system did not autonomously create work orders
- Logged every alert, every acknowledgement, every action and every outcome for trend monitoring
The system did not perform any maintenance. It did not auto-create work orders. The decision authority on every alert remained with the maintenance team. This was an explicit governance position: maintenance decisions are professional judgements made by qualified engineers.
The outcome — at 8 months across all 3 plants
| Before (FY24 baseline) | After (8 months in production) | |
|---|---|---|
| Unplanned downtime hours (rolling 12-month) | 547 | ~206 (-62%) |
| Failure-onset events flagged before failure | 0 | 19 (over 8 months) |
| Of those 19: confirmed by maintenance team | n/a | 17 (89% precision) |
| False alerts (alert, no action needed, no failure occurred) | n/a | 31 (2.5/week across portfolio) |
| Avoided downtime (annualised, at A$4,950/hr) | n/a | ~A$1.7M (run-rate) |
| Maintenance team time on alert triage | n/a | ~6 hrs/week (small relative to downtime savings) |
| Cost per asset-day monitored (model + infra) | n/a | A$1.40 |
The 17 confirmed failure-onset events are the metric the COO most often cites. Each one is a production line that didn't stop. Several were major-component failures (a bearing, a hydraulic pump, a conveyor motor) that would have taken days of repair if they had run to failure.
Sensors had been there for years. What you gave us was a maintenance team that gets warned in time. That's it. That's the engagement.
— Chief Operating Officer, mid-market AU manufacturer
What we'd do differently
Tier the asset coverage. We brought all 47 critical assets online together. Higher-failure-rate assets needed shorter alert thresholds, lower-failure assets needed longer. We retuned per-asset in month four. Should have done so in week six.
Embed with the on-call team for the first month. The maintenance team had alert-fatigue concerns from prior monitoring deployments. We didn't sit with the on-call team enough in week one. Trust on the alerts took longer to build than necessary.
What we didn't do
We didn't create any work order. We didn't perform any maintenance. We didn't replace the asset-management platform. We didn't ingest data from any system outside the existing sensor stack.
The system is a recommender. The maintenance team is the decider. That distinction was the binding governance constraint and it shaped every architectural choice.