Predictive Maintenance and the Documented Maintenance Interval

MarketJoy's recent piece on AI in manufacturing operations lists IoT-based predictive maintenance among the developments it expects to shape the next phase, alongside autonomous production planning, digital twins and AI-equipped collaborative robots. The same article argues that AI has moved out of experimental trials and into routine work across planning, purchasing, logistics, engineering and delivery. Of the developments on that list, predictive maintenance is the closest to existing plant practice, because it builds on equipment data that plants with modern controls already collect. For a regulated manufacturer, it also runs straight into a document that a predictive tool has to fit around: the preventive maintenance schedule.

The maintenance interval is a quality commitment

In a medical device plant, maintenance intervals are written requirements. ISO 13485 requires a manufacturer to document its maintenance activities, including how often they are performed, when the maintenance or the lack of it can affect product quality. It also requires records of that maintenance. Food manufacturers and contract manufacturers working under customer quality agreements often carry similar commitments in their food safety plans and equipment programs. Someone set each of those intervals, often from the equipment maker's recommendation plus some margin, and an auditor will compare the work orders against them.

Predictive maintenance changes the basis for those intervals. A vibration model on a filling line motor may report that the bearing is healthy and the quarterly service can wait six weeks. A thermal model on a sealing press may report that the heater is degrading and should be serviced now, two months early. Both recommendations are useful. If the first one is acted on without a documented change, the plant ends up with a missed PM on a quality-affecting asset and a technician's note saying the software showed the bearing was fine.

Early calls and deferrals need different rules

I think the two directions should be governed separately. Pulling maintenance forward is mainly a production planning problem. It takes a line down when the schedule did not expect it, and with the supply pressures MarketJoy describes (rising transport costs, supplier shortages and new trade laws), an unplanned stop can push out orders that are already tight. That calls for a fast path between the maintenance planner and production scheduling, with a named owner who decides whether to run to the end of the shift or stop now. It rarely needs quality approval, because servicing equipment early does not breach a documented interval.

Deferring maintenance is where the quality system has to be involved. If a model's recommendation is going to be allowed to stretch an interval, the interval itself has to change through change control, with evidence behind it. That evidence is the model's track record on that asset class, meaning how its predictions compared with the condition technicians found when they opened the equipment up. A sensible approach is to run the model in parallel with the existing schedule for a defined period, record its prediction at every scheduled PM, and compare each prediction against the as-found condition. Once the comparison supports it, quality can approve a revised maintenance requirement that allows condition-based deferral within a stated limit, such as a maximum extension beyond the original interval, and only for named assets.

What the work order has to show

When an auditor pulls a deferred work order, the record should answer a few questions without anyone reconstructing them from memory. It should show what the model recommended and what data it was looking at, which version of the model made the call, and who accepted the recommendation under which approved procedure. If the asset later fails or contributes to a nonconformance, the investigation will need the same information. So will whoever decides whether the deferral limit should be tightened.

That means the predictive tool and the maintenance management system have to be connected, so the recommendation lands on the work order as part of the record with the model version attached. A screenshot pasted into an email, or a dashboard that only shows the asset's current state, leaves nothing for an auditor to review six months later. A maintenance system will typically have fields for a deferral reason and an approver. Whether yours can also hold the model output and version is worth checking early, because that is usually where the integration effort lands.

The technicians matter here too. People who have serviced a press on a fixed schedule for years have good reasons to doubt a model that tells them to skip it. Their as-found observations are the data that will validate or disqualify the model, so the parallel run gives them a direct role in deciding whether it earns the right to defer anything. Having them record as-found condition consistently, in structured fields that can be compared against predictions, is one of the most useful things a plant can do before it buys a predictive tool.

Next steps