Most industrial maintenance still runs on a calendar, not on evidence. A pump gets serviced every six months whether it needs it or not, because the alternative, waiting for it to fail, is worse. This is the default operating model across asset-heavy industries: a compromise between the cost of unnecessary maintenance and the cost of unplanned failure. Neither number is small. Unplanned downtime routinely costs manufacturers far more than the maintenance budget that would have prevented it, and calendar-based servicing wastes a meaningful share of that same budget on equipment that did not need attention yet.
The industry has known about the alternative, usually called condition-based or predictive maintenance, for at least two decades. What has changed recently is not the idea. It is the cost of collecting, storing and interpreting the data that makes the idea work. Sensors are cheaper than they were ten years ago. Storage is close to free. The bottleneck has moved from collecting data to interpreting it, and that is where most industrial organisations are still stuck.
Why maintenance schedules lag behind reality
Calendar-based maintenance survives for a simple reason: it is legible. A maintenance manager can defend a schedule to a plant director in one sentence. "Every service is serviced every six months" requires no further explanation. Condition-based maintenance, done properly, requires a different kind of confidence, confidence that the data pipeline feeding the decision is complete, current and correctly interpreted. Most plants do not have that confidence, and they are right not to have it, because most plants have not built the systems that would earn it.
The gap is rarely about sensors. Most industrial equipment built in the last fifteen years already has some form of instrumentation, vibration sensors, temperature probes, current draw monitors. The gap is what happens to that data after it leaves the sensor. In a typical plant, vibration data lives in one system, maintenance history lives in a different one, often a spreadsheet, and production schedules live in a third. No single person has a complete view of an asset's condition, its maintenance record and the production pressure it is currently under, all at once. Decisions get made on partial information because partial information is what is actually available at the moment a decision has to be made.
This is not a technology failure in the sense that the required technology does not exist. It is an integration failure. The individual systems work. They were simply never built to talk to each other, because they were bought at different times, from different vendors, to solve different narrow problems.
What "asset intelligence" actually means
The term gets used loosely, often as a synonym for "we installed sensors" or "we have a dashboard." Neither is sufficient on its own. A dashboard that shows current vibration readings is useful, but it still requires a human to notice the reading, understand what it means in context, and decide whether it warrants action. That is monitoring, not intelligence. Monitoring tells you what is happening right now. Intelligence tells you what is likely to happen next, and what to do about it before it does.
A working definition: asset intelligence is the layer that connects sensor data, maintenance history and operational context into a single, current picture of an asset's condition, and then converts that picture into a specific, actionable recommendation, not just an alert. The distinction between an alert and a recommendation matters more than it sounds. An alert says a value crossed a threshold. A recommendation says what that crossing means for this specific asset, given its maintenance history and current production load, and what should happen in response, and by when.
Built well, this layer does three things a spreadsheet and a set of dashboards cannot do on their own. First, it draws together data from systems that were never designed to share it, joining vibration readings to maintenance logs to production schedules without requiring a person to manually cross-reference three different tools. Second, it establishes a baseline for what normal looks like for a specific asset, in its specific operating context, rather than applying a generic threshold that may be wrong for that particular machine's age, load profile or installation. Third, it prioritises. Not every anomaly is worth an engineer's attention today. A working system tells you which five anomalies out of five hundred are worth looking at this week, and why.
The three ways these projects fail
Asset intelligence initiatives are not new, and not every one of them succeeds. The failure modes are consistent enough to be worth naming plainly, because most of them are avoidable with the right sequencing.
Data fragmentation gets treated as a data problem instead of an organisational one. A team will spend months building a technically elegant pipeline that joins OT (operational technology) data with IT systems, only to discover that the maintenance team keeps its most valuable information, informal notes about which machines are temperamental, in a paper logbook that never made it into the project scope. The technical integration was successful. The organisational integration was not.
Alert fatigue kills adoption faster than any technical shortfall. A system tuned to be cautious will flag too much, and a maintenance team that gets fifty alerts a day for a plant that used to generate five will stop reading them within a month. This is not a failure of the maintenance team's discipline. It is a predictable response to a system that has not done the work of prioritisation. The fix is not more alerts with more detail. It is fewer alerts with higher confidence.
The system gets built by people who never have to act on its recommendations. A data science team can build a technically sound anomaly detection model and hand it to a maintenance department that was never consulted on what a useful recommendation would actually look like in the middle of a shift. The model might be statistically correct and still be operationally useless, because it was not built with the constraints of the people who have to act on it in mind, constraints like how much lead time is realistic for scheduling a repair, or which failures are tolerable versus which ones stop a production line entirely.
What earlier intervention actually looks like
Consider a generic but representative scenario. A rotating piece of equipment, a compressor or a large motor, begins showing a gradual increase in vibration amplitude at a specific frequency associated with bearing wear. On a calendar-based schedule, this asset gets inspected in four months regardless of what the vibration data shows today. On a threshold-based alert system, the vibration eventually crosses a fixed limit and triggers a warning, by which point the bearing may already be close to failure.
A working asset intelligence layer does something different. It recognises that this specific asset's vibration signature has been drifting for three weeks, cross-references that drift against the asset's maintenance history to confirm the bearing was last replaced eighteen months ago, near the expected midpoint of its service life for this duty cycle, and checks the production schedule to identify the next planned downtime window in which a repair could be made without disrupting output. It then generates a specific recommendation: inspect this bearing within the next two weeks, ideally during the planned maintenance window six days from now, because the trend suggests failure risk becomes material within four to six weeks if left unaddressed.
The difference is not just earlier warning. It is a warning that arrives with enough context to act on efficiently, scheduled against a real production window rather than forcing an unplanned stoppage, and specific enough that a maintenance engineer does not have to do their own investigation before deciding what to do.
From predictive to prescriptive
The natural next step, and the direction most serious asset intelligence work is heading, is the shift from predictive to prescriptive systems. A predictive system tells you something is likely to fail. A prescriptive system tells you what to do about it, accounting for constraints a maintenance manager would otherwise have to weigh manually: available spare parts inventory, technician scheduling, the cost of a planned intervention versus the cost of the failure it prevents, and the knock-on effect on other equipment sharing the same maintenance window.
This requires the intelligence layer to understand more than the asset in isolation. It needs a working model of the maintenance organisation's actual constraints, not an idealised version of them. A recommendation that assumes unlimited technician availability is not more useful than no recommendation at all, if the plant only has two qualified technicians for that equipment type and both are already committed elsewhere that week.
Getting to this point is not primarily a modelling challenge. It is an integration and trust-building challenge. Maintenance teams that have been burned by noisy alert systems in the past are, reasonably, slow to hand over scheduling decisions to a system they do not yet trust. Trust gets built the same way it always does: a system that is right more often than a human's gut instinct, transparent about its own confidence level, and honest when it does not have enough information to make a strong recommendation.
Getting started without boiling the ocean
The organisations that succeed at this rarely start with a plant-wide rollout. They start with a small number of asset classes, often the ones where unplanned failure is most expensive or most disruptive to production, and build the integration properly for that narrow scope before expanding. A compressor fleet with a well-understood failure history is a better starting point than an attempt to instrument every asset in a facility simultaneously, because a narrow scope makes it possible to get the data integration genuinely right, rather than superficially connected across too many systems at once.
This matters because the credibility of the entire initiative rests on the first few recommendations being correct. A maintenance team that has been asked to trust a new system will form a lasting opinion based on its first handful of interactions with it. If the first recommendation is wrong, or arrives without enough context to act on confidently, the system has to work much harder to earn a second chance than it would have needed to earn the first one. Starting narrow, and getting that narrow scope right before expanding, is not caution for its own sake. It is the fastest actual path to broad adoption, because broad adoption depends on trust that has to be earned in a small, controlled setting first.
The organisations that get this wrong tend to make the opposite mistake: an ambitious, plant-wide pilot announced with real fanfare, covering asset types with inconsistent data quality and maintenance history, producing a mix of genuinely useful and clearly wrong recommendations in the first month. The technology in that scenario might be no worse than in the narrow, successful version. But the trust deficit created by an early, visible miss is difficult to recover from, and it is avoidable simply by choosing where to start more deliberately.
What this means for the next few years
The technology required to do this well already exists. What most industrial organisations are missing is not a more sophisticated algorithm. It is the unglamorous integration work: joining systems that were never designed to talk to each other, establishing asset-specific baselines instead of generic thresholds, and building recommendations around the real operational constraints of the people who have to act on them.
The organisations that get this right first will not necessarily be the ones with the most advanced sensors. They will be the ones willing to do the integration work that connects what they already have into a single, trustworthy picture, and then have the discipline to build a system that earns adoption by being right, consistently, rather than being impressive in a demo.