Section 1
Start from the decision, not the sensor
The right first question is which recurring decision is made too late or on a guess. When to service the compressor. Whether the batch is within tolerance. Which vehicle needs attention this week. Whether the site is being used at the hours you assumed. Work backwards to the minimum measurement that would inform it. Often it is one variable, sampled less often than anyone proposed, from a subset of assets. The opposite approach, instrument everything and find insights later, produces a large data bill and a dashboard that gets opened during the vendor's quarterly review. Scoping this like a product, with a stated outcome, is the discipline in [AI Automation in Product Development: From Idea to Launch](/blog/ai-automation-in-product-development-from-idea-to-launch).
Section 2
How predictive maintenance actually works
The mechanism is less exotic than the term. Equipment usually degrades before it fails, and the degradation shows up in signals a person cannot monitor continuously: vibration rising slightly, temperature drifting, a motor drawing more current for the same work, a cycle taking a few seconds longer. A model learns the normal range for that asset and flags departures. That is the whole idea. It works when three conditions hold: the failure is preceded by a measurable change, you have history including actual failures, and there is time between the signal and the breakdown to act. When any condition fails, you are better served by scheduled maintenance. A component that fails without warning cannot be predicted by more sensors, and no amount of modelling changes that.
Section 3
Alert fatigue is the main failure mode
Connected systems die from too many notifications, not too few. Once staff learn that most alerts are noise, they stop reading all of them, including the one that mattered. Design against it deliberately. Every alert needs a named recipient, a defined action, and a stated consequence for ignoring it. If nobody can say what a person should do when it fires, delete the alert. Suppress known-benign patterns explicitly, the door held open during a delivery, the spike during a wash cycle. Tier the alerts, with a small number that can wake someone at night and the rest in a morning summary. Review the log monthly and retire rules that only produced noise. The factory-scale version of this problem is examined in [Manufacturing: Smart Factories and AI Automation](/blog/manufacturing-smart-factories-and-ai-automation).
Section 4
The physical realities that break the data
Sensor data degrades in ways software data does not. Sensors drift out of calibration slowly and keep reporting confidently. Batteries fail. A unit gets knocked and now reads the wrong thing. Connectivity gaps produce missing periods that a model may interpret as stability. The consequence is a system that appears to be working while quietly measuring something else. Guard against it with a calibration schedule, a reference sensor where accuracy matters, and an automatic check for readings that are suspiciously constant, since a stuck sensor looks like a very well-behaved asset. Also decide upfront what happens when data is missing. A rule that only acts on present readings will silently stop protecting an asset the moment its sensor goes quiet.
Section 5
Security, and who owns the data
Connected devices expand the number of ways into your network, and they are typically the least maintained computers a business owns. Default passwords, firmware nobody updates, and a vendor with remote access are the standard starting position. Minimum controls: change every default credential, put devices on a separate network segment from business systems, know which vendors hold remote access and remove the ones you do not need, and set a policy for firmware updates with someone accountable for it. Then settle ownership contractually before purchase. Who owns the readings from your equipment. Can you export the full history. Does it remain accessible if you change vendor. Many device contracts quietly place your operational history in a platform you cannot take with you.
Section 6
Measure the outcome, not the connection
Devices deployed and data points collected are metrics that describe the purchase, not the benefit. Measure unplanned downtime hours, emergency versus planned maintenance ratio, mean time between failures, spoilage or waste volume, energy per unit of output, and technician hours per asset. These are the numbers that were supposed to change. Add two health checks on the system itself: the proportion of alerts that led to a real action, and the proportion of assets currently reporting valid data. If the first is low, you are training staff to ignore the system. If the second is drifting down, the estate is decaying and the dashboard will not show it. Turning either finding into something a board acts on is a communication task, covered in [Using AI and Data Analytics to Enhance Storytelling](/blog/using-ai-and-data-analytics-to-enhance-storytelling).