A lot of predictive maintenance initiatives start with a vendor conversation about anomaly-detection algorithms and end, a year later, with a dashboard nobody trusts and a maintenance team that's gone back to run-to-failure or fixed-interval schedules. The algorithm is rarely why these programs stall. The reasons are almost always upstream of the model: instrumentation that doesn't actually see the failure modes that matter, data that isn't clean or labeled enough to train or validate anything against, and a maintenance organization that was never brought into the decision loop.
Instrumentation decides what's even possible
A predictive model can only detect what its sensors are physically capable of observing. Bearing wear shows up in vibration and acoustic signatures; motor winding degradation shows up in current draw and thermal signatures; a pump cavitating shows up in pressure and flow anomalies. Picking the wrong sensor modality — or the right modality at too low a sampling rate or too coarse a resolution — means the model is trying to predict a failure it structurally cannot see coming, no matter how sophisticated the analysis layer is.
This is why the instrumentation plan has to start from a specific list of failure modes the program is trying to catch, ranked by cost and frequency, rather than from "let's put sensors on the equipment and see what we learn." Vague instrumentation produces vague data, and vague data produces a model that's technically running but not actionable.
Data quality is the real bottleneck, and failures are rare by definition
The uncomfortable statistical reality of predictive maintenance is that the event you're trying to predict — an actual failure — is rare. Most of the historical data from any piece of equipment is "normal operation," and the positive examples (labeled failures, with enough lead time before the failure to be useful) are often sparse, inconsistently logged, or missing entirely if the equipment hasn't failed enough times yet to build a real training set.
That reality pushes most credible programs toward anomaly detection and degradation-trend modeling against a healthy baseline, rather than toward a supervised classifier trained on labeled failure events — at least until enough real failure data accumulates to make supervised approaches viable. Programs that skip straight to "train a failure classifier" on six months of mostly-normal data tend to produce models that either flag everything or nothing, and either way lose the maintenance team's trust within a few false alarms.
What tends to go wrong with historical data specifically
- Maintenance logs record what was fixed, not when the underlying problem started — so failure timestamps are often much later than the true onset
- Sensor data and maintenance records live in separate systems with no reliable way to join them by asset and time
- Equipment gets swapped, repaired, or reconfigured without the change being reflected in the data, silently breaking the continuity a trend model depends on
Build vs. buy for the modeling layer
Once there's a real, clean data pipeline, the model itself is a smaller decision than it first appears. Off-the-shelf industrial anomaly-detection platforms can get a program running faster and are often the right call when the failure modes are common and well-studied (bearing wear, motor imbalance). Custom modeling earns its cost when the equipment, failure modes, or operating conditions are specific enough that a generic platform's assumptions don't hold — which is common in process-specific or custom-built industrial equipment. Either way, the model is only as good as the pipeline feeding it, which is the part that's actually hard to get right and the part most programs underinvest in.
Practical takeaway: the first six months should not touch prediction
The programs that actually make it past year one tend to spend their first phase on ingestion and baseline health data, not prediction: get sensors reliably reporting, get that data landing in a system maintenance teams can already query and trust for basic health monitoring, and let the organization build confidence in the pipeline before any model output starts influencing maintenance decisions. Prediction added on top of a shaky pipeline just automates distrust faster. This is also where organizational buy-in gets built — a maintenance team that's been looking at real dashboards of real equipment health for a few months is far more receptive to a predictive alert than one that's asked to trust a black box on day one.
We typically scope these programs starting with the sensing and data-pipeline layer — see our embedded hardware work for the instrumentation side and our AI & intelligence work for where the modeling layer fits once the data foundation is solid.