Predictive Maintenance: What Vendors Won't Tell You

Supervised machine learning models - the type used in most predictive maintenance applications - require historical examples of the event they are trying to predict. For bearing failure prediction, the model needs sensor readings (vibration, temperature, current) from hundreds of historical bearing failures, labelled with the failure type and timing. Without this labelled dataset, the model cannot learn to distinguish pre-failure signatures from normal operational variation.

Most manufacturers do not have this data in structured form. They have maintenance work orders in a CMMS, written in free text by technicians who did not know they were creating training data. Converting those work orders into structured failure labels - with asset ID, failure mode, failure date, and the sensor readings that preceded it - is a data engineering and data quality task that typically takes 3–6 months before model training can begin.

Vendors demonstrate PdM on assets with well-documented failure histories because the demo is designed to show the model working, not to show the implementation effort. The gap between a successful demonstration and a production deployment is the labelled data problem - and it is the most common reason PdM pilots fail to scale.

Predicting a failure is only useful if a work order gets created, the right parts are pre-positioned, and the maintenance technician receives the alert in a system they already use. Without CMMS integration, a PdM alert is a number on a screen that requires a human to notice it, interpret it, decide it is credible, and manually create a work order. In a busy plant, that human step is where most PdM value is lost.

A PdM prediction that triggers an automatic work order in the CMMS - with the right failure code, asset history, and recommended parts - closes the loop from insight to action. That integration is not straightforward. Most CMMS systems have different data models, different APIs, and different criticality classification schemes. Building the integration is an engineering task that vendors routinely underscope in their implementation proposals.

The rule of thumb is: if the PdM implementation does not include CMMS integration in scope, the operational value is at risk. The prediction may be accurate. The response may still be manual, slow, and inconsistent.

The most common asset selection mistake in PdM programmes is selecting assets based on sensor availability or equipment complexity rather than maintenance cost history and failure consequence. Vendors tend to pitch on the assets that are most instrumented - because those are the easiest to demonstrate. Operations teams are drawn to the most sophisticated equipment - because those seem most worthy of AI investment.

The correct starting point is a maintenance cost analysis. Which assets have generated the most unplanned downtime over the past 24 months? Which failures have caused the longest production stops? Which assets have the highest maintenance cost per unit of output? Those are your first targets - regardless of how many sensors they currently have.

Starting with high-cost, high-frequency failures means the ROI is measurable within 12 months. Starting with complex, low-frequency failures means you may spend 18 months building a model that has never seen enough failure events to be reliable. Asset selection is not a technical decision - it is a business prioritisation decision, and it should be made from maintenance cost data, not engineering instinct.