Predictive maintenance without the hype: start with failure history, not neural networks

Equipment manufacturers and industrial companies often start the conversation about predictive maintenance something like this: "We want a system that predicts when a machine will break down before it actually does." That desire makes sense - unplanned downtime is expensive. But the next question I ask usually stops the conversation: "Do you have a recorded failure history from the last three years?"

Most of the time - not in a usable form. Sometimes - nowhere at all.

What predictive maintenance actually is

Predictive maintenance is not neural network magic that "senses" equipment. It is statistics. The same point - that starting with an honest inventory of what you have beats chasing algorithms - applies across industrial data work. A system observes equipment over time and finds patterns that precede failure. For that to work, three things are needed:

• history: enough recorded events - normal operation and failures;
• signals: measurable parameters that change before a failure;
• a connection: an understanding of which changes in signals precede which failures.

Without history there is no way to train a model - even a simple one. Without signals there is no data to monitor. Without understanding the connection it is impossible to tell random noise from a real early warning.

Why you start with the repair log

The cheapest and most valuable data source for predictive maintenance is the repair log. What broke, when, on which equipment, how long it took to fix.

If that log has been kept carefully for even a few years, you can extract from it:

• which components fail most often;
• at what operating conditions or time of year failures cluster;
• what an average failure of each type actually costs;
• where the highest downtime risk is concentrated in money terms.

That is already analytics. It can already be used to make decisions: where to adjust maintenance schedules, where to keep spare parts, where to direct engineering attention. No neural networks required.

The cost of downtime as a starting point

Before investing in monitoring systems and algorithms, you need to know where the money is. I suggest starting with a simple calculation:

• Which piece of equipment costs the most when it fails? Count: repair cost, production losses during downtime, secondary consequences.
• How often does it fail?
• Is it possible to detect an approaching failure through any measurable parameters?

If a machine fails once every five years and downtime costs a modest sum - a complex predictive monitoring system will not pay off. If it fails three times a year and each time means significant losses - investing in data collection and monitoring is justified.

A sensible sequence of steps

Instead of immediately buying sensors and building ML models, I recommend a shorter path:

1. Get the repair logs in order - if they do not exist, start keeping them right now.
2. Analyse the history: find the most expensive and most frequent failures.
3. For the top five problem components - investigate whether there are already measurable parameters that change before failure.
4. If the parameters exist - set up simple threshold alerts. Not a neural network, but it works.
5. Accumulate data. Only when you have enough history, consider more sophisticated algorithms.

This path is less exciting than "let's buy a machine learning platform." But it starts producing results in months, not in two years.

A simple readiness test

Before moving toward predictive analytics, I check a few things:

• Is there a documented failure history for at least two years on key equipment?
• Has the real cost of downtime been calculated for each critical machine?
• Is there at least one engineer who understands the failure physics of this equipment?
• Who will act when the system issues a warning?

That last question is one of the most important. A predictive system without an operational response process is an expensive sensor whose signals nobody reads.