I remember the first predictive maintenance project I led. We'd installed vibration sensors on a dozen critical pumps at a chemical plant. The vendor's machine learning model promised to flag bearing failures two weeks before they happened. I believed it. So did the plant manager. Six months later, the maintenance team had muted every alert and one pump seized so badly it took the line down for three days.
The problem wasn't the algorithm. It was plenty accurate on the vendor's test data. The issue was our data. The sensors picked up normal operating noise, harmonics from nearby motors, even the rumble of trucks backing up to the loading dock. The model had never seen those patterns, so it treated them as anomalies. We averaged forty false positives a day. The technicians started ignoring alerts by week two. They called it the crying wolf system.
That failure taught me that predictive maintenance is less about machine learning and more about data engineering and human behavior. You can't just drop a model onto a factory floor. You have to spend weeks collecting baseline data under real conditions. Not the clean data from the pilot cell, but the messy, noisy, shift-change, door-open, forklift-vibrating data that actually happens. We eventually rebuilt the model using three months of labeled data from the maintenance logs, not just the sensor stream.
We also learned to involve the maintenance techs from day one. In the first attempt, they weren't consulted. They didn't trust a black box telling them to replace a bearing. The second time, we sat with them and asked what early signs they looked for: temperature rise, a change in sound, a slight increase in amp draw. That domain knowledge became features in the model. The result was an alert that said check pump 4, bearing temperature trending up 12 degrees over 48 hours, vibration pattern matches previous failure from March instead of anomaly detected. Credibility went way up.
The cost side matters too. Every false positive isn't just noise; it's labor hours and lost trust. I now tell clients to calculate the cost of a false alarm before they calculate the cost of downtime. If a technician spends twenty minutes walking to a pump to find nothing wrong, and that happens ten times a day, you've burned half a shift. The model has to be tuned so the first alert is rare enough to be taken seriously.
We ended up with a system that gave us about a week's warning on most bearing failures and maybe a day on seal leaks. Not the two weeks the vendor promised, but it was real. The maintenance team actually used it because it stopped lying to them. Last I heard, they'd caught three failures early and avoided one unplanned shutdown.
If there's one thing I'd tell someone starting out with predictive maintenance, it's this: the algorithm is the easy part. The hard part is earning the trust of the people who have to act on the predictions. Spend your time there.