How to tell whether predictive maintenance pays off for a small industrial business

Predictive maintenance can help detect signs of deterioration before equipment fails and make it possible to plan interventions with more information than a fixed schedule provides. But the fact that a technology can anticipate anomalies does not mean it is cost-effective for every machine or company. For a small industrial business, the question is whether the value of incidents that could be prevented or managed better justifies the full cost of implementing and sustaining the system.

The sources describe technologies such as sensors, data analysis and integration with maintenance tools, as well as potential benefits for equipment availability. However, they do not provide a quantified, verifiable financial case that would make it possible to attribute a specific saving to a small business. The assessment must therefore be based on plant data, and benefits should be treated as hypotheses until they are measured.

1. Start with the equipment whose failure matters most

There is no need to assess the entire plant at the outset. It makes sense to prioritize assets whose downtime has a significant effect on production, quality or process continuity. It may also be useful to consider whether equipment has no backup, whether a failure forces other operations to stop, or whether breakdowns usually take a long time to diagnose.

Selection should be based on maintenance and production records, not just on the perception that a machine is important. One piece of equipment may fail frequently but have a limited impact; another may break down rarely yet cause a costly interruption. The analysis should distinguish between these cases.

2. Build a baseline of breakdowns and downtime

Before estimating savings, collect a representative period of information about the selected assets. At a minimum, record:

• Number and type of breakdowns, with known causes where documented.
• Downtime hours and the duration of interventions.
• Internal labor and external services used.
• Spare parts, consumables and other expenses directly associated with the incidents.
• Affected production, delays or rework that can be attributed to the incident and are recorded.

The quality of this baseline affects the calculation. If the company cannot identify when downtime began, what caused it or what costs it generated, the potential benefit will be difficult to verify. In that case, improving record-keeping may be a practical first step before adding sensors or platforms.

3. Calculate the full cost of an incident

The cost of a breakdown is not limited to spare parts and technician hours. Depending on how the plant operates and what data is available, it may include labor, parts, external assistance, lost production, overtime, delays, and rejected or reprocessed product. Count only items attributable to the incident, and avoid counting the same effect twice.

For example, if lost production has already been valued in an internal calculation that includes certain operating costs, those same items should not be added again separately without checking. If it is not possible to assign a reliable monetary value to a consequence, it is better to record it as an operational impact rather than present it as confirmed financial savings.

One simple way to organize the analysis is to calculate, for each asset or group of assets:

Historical incident cost = sum of documented breakdown and downtime costs over the period selected.

The period must be representative enough of operations and the frequency of failures. The historical figure serves as a reference: on its own, it does not show how much of that cost predictive maintenance would have prevented.

4. Count all system costs

Comparing the cost of sensors with the cost of a breakdown gives an incomplete picture. The assessment should account for the total cost of implementation and operation, including the items applicable to the chosen solution:

• Sensors, devices and their installation.
• Connectivity, networks and data storage, if required.
• Software licenses or services.
• Integration with existing systems, such as maintenance management or production tools.
• Configuration, commissioning and equipment adaptation.
• Staff training and the time spent reviewing alerts and planning interventions.
• Maintenance, replacement or calibration of system components, and ongoing support.

Integration deserves special attention when older machinery and new systems coexist. A solution that works technically may require adjustments, internal work or additional services that were not included in the initial price. Ask for the scope and recurring costs to be itemized separately from installation costs so they can be compared.

5. Compare scenarios, not promises of savings

A system may detect an anomaly and still fail to prevent downtime: perhaps the alert arrives too late, the diagnosis is not confirmed, spare parts are unavailable or the intervention cannot be scheduled in time. Alerts may also occur without resulting in a breakdown. Therefore, an alert should not automatically be equated with a failure prevented.

Prepare cautious scenarios with explicit assumptions about which incidents could be detected, how much time there would be to act, and what proportion of historical costs could actually be avoided or reduced. These assumptions are not results: they must be verified during the test. There is no universal savings percentage that applies to every small business, machine and process.

To structure the decision, you can use these metrics:

If you estimate a return, make the calculation and time horizon explicit. A common formula is (measured attributable benefit − system costs) ÷ initial investment. The result depends on what is counted as a benefit and a cost; therefore, it cannot be compared across companies if different criteria are used. When the attributable benefit has not yet been measured, it is more rigorous to present scenarios than to claim a confirmed return.

6. Test on a small scale and measure at the plant itself

A pilot test involving a few critical assets makes it possible to check whether the data are useful for decision-making and whether the maintenance team can turn alerts into timely interventions. Before starting, define which equipment will participate, how long the assessment will last, which indicators will be measured and who will validate the alerts. As far as possible, keep the same recording criteria as in the baseline.

At the end, compare the results with the reference period and document both what improved and the costs and limitations observed. The test may also reveal whether historical data are missing, connectivity is insufficient or integrating the solution requires more work than expected. If the period does not include enough incidents to assess performance, the result should be considered inconclusive, not proof of savings or failure.

The decision depends on the asset and the quality of the evidence

Predictive maintenance pays off when the value the company can substantiate with data—through failures prevented or more effective management of interventions—exceeds the total cost of implementing and operating the solution under reasonable assumptions. This conclusion cannot be reached through a technology demonstration or a sales estimate alone.

For a small business, the analysis can start with a few machines, reliable records and a test using indicators agreed in advance. This means the decision to expand, adjust or abandon the initiative is based on results observed at the plant itself, without assuming savings that have not yet been demonstrated.