What is predictive maintenance?

Predictive maintenance uses sensor data and failure history to estimate when a machine is likely to fail, so it can be serviced before it stops rather than on a fixed calendar.

The promise is obvious and the requirement is not: you need examples of things going wrong. That single fact decides whether a predictive maintenance project is feasible, and it is usually discovered after the sensors have been bought.

The three maintenance strategies, and where this one fits

Reactive — fix it when it breaks. Cheapest until the breakage is expensive or unsafe.
Preventive — service on a schedule, by hours run or calendar. Simple, well understood, and it systematically over-services reliable machines while still missing early failures.
Predictive — service when the condition indicates. Better in principle, and it needs data that preventive maintenance never required.

Most operations should be honest that preventive is the right answer for most of the fleet. Predictive earns its cost on the small number of assets where unplanned downtime is expensive, safety-critical, or blocks a whole line.

You need failure history, not just sensors

A model that predicts failure has to learn what the run-up to failure looks like. That means labelled examples: this machine, these readings, and then it failed on this date for this reason.

Most companies have the opposite. Years of sensor readings and a maintenance log that says "repaired" with no cause, no timestamp precision and no link to the readings. Sensor data without failure history supports anomaly detection, not prediction — you can flag "this is not normal" but not "this bearing has roughly three weeks left".

That distinction is worth insisting on with suppliers, because anomaly detection is frequently sold as predictive maintenance and it answers a much weaker question.

How much data, and how long

The uncomfortable arithmetic: you need multiple examples of each failure mode you want to predict. If a specific failure happens twice a year, two years of history gives you four examples — not enough for a model to generalise from.

Practical routes when history is thin: start with anomaly detection and let it accumulate labelled events for a year, pool data across identical machines to multiply examples, or begin with the failure modes that occur most often rather than the ones that hurt most. The instinct is to attack the catastrophic rare failure first; the data almost never supports it.

What it takes to act on the prediction

A prediction is worthless unless it changes what someone does. That means the alert must reach the planner with enough lead time to order the part and schedule the window — and the required lead time is a business fact you can state before any model exists.

If a part takes six weeks to arrive and your model can only see two weeks ahead, the prediction cannot be acted on and the project fails regardless of accuracy. Ask this question first; it disqualifies more projects than data quality does.

What it costs, and the Flanders note

At Crux Digits: a €2,500 audit establishes whether your failure history supports prediction at all, and states plainly when the honest answer is anomaly detection or better preventive scheduling. A €20,000 proof of concept runs four to six weeks on your historical data, and production starts from €50,000.

For Flemish operations: this is a topic where the Belgian market is proportionally as active as the Dutch one, and we work across both. The technical requirements are identical; only the maintenance-planning conventions differ.