Short answer
Predictive maintenance needs four things at once: an expensive failure, something observable that changes beforehand, a history of past failures to learn from, and a named person who can act. In LYVIA’s own engagements small manufacturers typically have the first and lack the third — client observation, not a published benchmark. When you have no failure history, instrument the machine and run condition-based thresholds first — that captures most of the value, costs far less, and builds the dataset a model would need later. Start with one machine you can name.
The four conditions, all required
This is a use case where the qualifying questions matter more than the technology, because failing any one of them makes the rest irrelevant.
- The failure is expensive. Not annoying — expensive. A stopped line, a missed shipment, a scrapped batch, an emergency callout at weekend rates. If a machine can be swapped out in twenty minutes with a spare, prediction has nothing to save.
- Something observable changes first. Vibration, temperature, current draw, pressure, cycle time, sound. Failures that arrive without warning — a component that simply snaps — cannot be predicted by watching, however good the model.
- You have a record of past failures. With dates, and ideally with what was found afterwards. This is the condition LYVIA sees fail most often, and the one vendors are quietest about.
- Someone can act on a warning. A named person with the authority to schedule an intervention and the parts to do it. A warning that arrives where nobody can act on it is a source of stress, not of savings.
Where predictive sits on the ladder
Maintenance strategies form a ladder, and the industry conversation tends to jump from the bottom rung to the top. In LYVIA’s own engagements the two in the middle are where most small manufacturers belong.
| Strategy | Trigger | What it needs | Main weakness |
|---|---|---|---|
| Reactive | It broke. | Nothing. | Every failure is an emergency, at emergency prices. |
| Preventive | A schedule. | A calendar and a parts budget. | Replaces parts with life left, and still misses early failures. |
| Condition-based | A measured threshold is crossed. | Sensors and a sensible threshold. No model. | Thresholds need tuning, and warn later than a model would. |
| Predictive | A model recognizes a degradation pattern. | All of the above, plus failure history to learn from. | Cold start: no history, no model. Highest cost to run. |
Read that table as a sequence rather than a menu. Each rung requires the one below it, and skipping to the top is how projects stall — you arrive at the model and discover you have neither the sensors nor the history it assumes.
The failure-history problem
A predictive model learns what degradation looks like by seeing examples of it. A machine that has failed twice in five years provides two examples. That is not a training set, and no amount of sensor data changes it — you have abundant data about the machine working normally and almost none about it failing.
This is why demonstrations are usually run on rotating machinery: bearings and motors have well-studied degradation signatures and public datasets behind them. Your specific press, oven or packing line has neither. Vendors who gloss over this are selling you a model that will be trained, in practice, on your first year of readings — which means the honest description of year one is data collection.
A direct question worth asking any vendor: what will this predict in month one, and what is it learning from? If the answer involves a general model transferred from other customers’ machines, ask what makes those machines comparable to yours.
What instrumenting actually involves
The sensor is rarely the expensive part. What costs is everything around it.
Getting the reading off the machine and somewhere useful means either the equipment already exposes data — increasingly common on recent machines, rare on older ones — or adding hardware, which may mean electrical work and a safety review. Then the readings need somewhere to live at a resolution fine enough to be useful later, which is a small ongoing storage cost and a real integration decision. Then somebody has to notice when the sensor itself stops reporting, because a silent sensor looks exactly like a healthy machine.
If the same sensors are also meant to reduce consumption rather than prevent a failure, that is a separate project with its own arithmetic — see AI for energy optimization. None of this is exotic, and all of it belongs in the business case. The lines usually missing are integration, storage and the maintenance of the monitoring system itself — the same infrastructure arithmetic set out in our guide to AI infrastructure.
The step LYVIA usually recommends instead
Condition-based monitoring is the rung that gets skipped, and on LYVIA’s own engagements it is usually the right answer — client observation rather than a published finding. You instrument the machine, you set a threshold with your maintenance engineer, and you alert when it is crossed. No model, no training data, no cold start.
It warns later than a good predictive model would, and for many machines later is still early enough. It costs a fraction as much, it works from day one, and — the part that matters strategically — it builds exactly the dataset a predictive model would need. You are not choosing against prediction; you are paying for its prerequisite while getting value in the meantime.
For an agency to recommend the cheaper option is unusual, so the reasoning is worth stating plainly: the failure mode LYVIA sees most often on these engagements is a predictive project that stalls at the data stage and leaves the client with sensors, an invoice, and no alerting. The intermediate step cannot fail that way.
The alert nobody owns
The technical failure modes of these systems are well documented. The organizational one is more common and less discussed: alerts arrive somewhere with no owner, a few of them turn out to be nothing, and within a month the team has learned to dismiss them.
Once that happens it is very hard to undo, because the next genuine warning arrives into a culture that has already decided the system cries wolf. Two things prevent it. First, a named recipient who can schedule an intervention — not a group address. Second, thresholds set deliberately conservative at the start, so the early alerts are few and mostly real. A system that warns rarely and correctly earns trust; one that warns often and vaguely spends it.
Building the case honestly
The business case rests on a number LYVIA rarely finds already calculated: what an hour of downtime on this specific machine actually costs. Not the plant average — this machine, including idle labor, late delivery consequences, and any scrapped work in progress.
Against that, put the full cost: hardware, installation, integration, storage, and the ongoing attention the system needs. Then be honest about the third term, which is how much earlier you will actually know. If a threshold alert gives you three days of warning and a model would give you five, the model is only worth the difference if two extra days change what you can do.
That arithmetic is the same one used for any automation decision, and it is worked through in our guide to measuring the ROI of automation.
A sensible first machine
Pick one machine, by name. It should be the one whose failure hurts most, that already has some history of failing, and that someone in the building genuinely understands. Instrument it, set thresholds with that person, and route alerts to them by name.
Run it for long enough to see whether the alerts were useful and whether anything was missed. If the answers are good, you now have both a working system and the beginnings of the dataset that makes prediction possible. If they are not, you have spent a small amount and learned that this equipment does not signal before it fails — which is worth knowing before instrumenting the rest of the floor.
If the four conditions do not hold, the cross-industry use cases in our list of use cases that survive the pilot are a better place to spend the same budget.
Frequently asked questions
What does predictive maintenance actually require?
Four things at once: equipment whose failure is expensive enough to justify the work, sensors measuring something that changes before the failure, a record of past failures to learn from, and someone able to act on a warning. In LYVIA's own engagements with companies this size, most have the first condition and lack at least one of the other three — an observation from client work rather than a published benchmark. The gap is almost always the failure history — you cannot learn to predict an event you have never recorded.
How is it different from preventive maintenance?
Preventive maintenance services equipment on a schedule, which means replacing parts that still had life and occasionally missing a failure that arrived early. Predictive maintenance services it when the equipment shows signs of degrading. Between the two sits condition-based monitoring, which triggers on a threshold rather than a model — and across LYVIA's own engagements that middle option captures most of the benefit for a fraction of the cost — a pattern from client work, not a published figure.
Why is failure history the blocker?
A model learns the shape of a degradation by seeing examples of it. A machine that has failed twice in five years gives you two examples, which is not a training set. This is the cold-start problem, and it is why vendors demonstrate on rotating machinery with abundant public data. The honest starting point when you have no history is to instrument first, record for a period, and treat the prediction as a second phase.
What does it cost to instrument a machine?
Enough variation that a single figure would mislead — it depends on whether the machine already exposes data, what you are measuring, and whether an electrician has to be involved. The more useful framing is that the sensor is usually the smallest line. Integration, the historian that stores the readings, and the maintenance of both cost more over time than the hardware, and they are the lines most often left out of the business case.
Who should receive the alert?
A named person who can schedule an intervention, not a shared inbox. An alert nobody owns becomes noise within weeks, and once a team learns to ignore the system it does not start trusting it again. This matters more than model accuracy: a slightly worse model with a clear owner outperforms a better one whose warnings arrive in a channel nobody reads.
When is it genuinely not worth it?
When failure is cheap or fast to recover from, when a machine is redundant, when it is old enough that the plan is to replace it, or when nothing observable changes before it fails. As a working rule from LYVIA's own engagements rather than a published benchmark, if you cannot name the specific machine and state roughly what an hour of its downtime costs, the project is not ready — and that conversation is worth having before any sensor is bought.
If you can name the machine and roughly what its downtime costs, that is enough to work out whether this is worth doing — and whether the answer is the cheaper middle step. Book a call.
