Who this is for

Reliability engineers, maintenance managers and plant owners in South African manufacturing, mining and water who have been pitched a "predictive maintenance" or "Industry 4.0" vibration package — or tried one — and want to know why these projects so often end up as ignored dashboards.

The uncomfortable truth

Vibration analysis is one of the most mature and reliable predictive-maintenance techniques in existence. Bearings, imbalance, misalignment and looseness all announce themselves in the vibration signature weeks before failure. The physics is not in question.

And yet a large share of vibration-monitoring deployments quietly fail — the sensors get installed, the dashboard goes live, and eighteen months later nobody opens it and breakdowns are no lower than before. The failure is almost never the sensor. It's the way the project was scoped and run.

Decision rule: if a vendor leads with "how many sensors" before asking "which assets, and what decision will the data drive," they are selling hardware, not reliability. Walk the other way.

The five failure modes

1. Monitoring the wrong assets

The most common mistake is instrumenting whatever is easy to reach, or everything at once, instead of what matters. A vibration sensor on a non-critical fan that can be swapped in an hour returns almost nothing; the same spend on the main mill drive or a critical pump can save a shift of lost production. Condition monitoring only pays where the failure it prevents is expensive or dangerous.

2. Alarm flooding

Set thresholds wrong — or set them generically instead of per-machine — and the system cries wolf. After the tenth false alarm, people stop looking. Every alert that isn't actionable trains your team to ignore the next one, including the real one. Baselining each asset to its own normal behaviour is not optional; it's the difference between a tool and a nuisance.

3. No link to a maintenance action

A reading that doesn't trigger a decision is just data. Many projects stop at "we can see vibration trends" and never close the loop: who gets the alert, what do they do, and where is the work order? If an alarm doesn't become a planned intervention with an owner and a deadline, the programme has no effect on downtime — which is the only thing it was bought to change.

4. Ignoring South African site realities

A platform designed for a German factory makes assumptions that don't hold here. Load shedding kills cloud-only systems that don't buffer at the edge. Dust and heat shorten sensor life if the hardware isn't rated for it. And a system that needs a scarce, expensive vibration analyst to interpret every reading won't survive the first time that person leaves. The programme has to fit the site, the power, and the skills you actually have.

5. Buying sensors before defining the decision

The root cause behind the other four: starting from the technology instead of the decision. The right sequence is decision → data → sensor, not sensor → data → hope. Decide what you're trying to prevent and who will act on the warning, then work backwards to the minimum sensing that supports it.

How to scope one that actually works

  • Start from a criticality ranking. List rotating assets by what their failure costs you — lost production, safety, repair, lead time on spares. Instrument from the top down, only while the maths works.
  • Baseline every machine. Capture normal behaviour first, then set thresholds to that machine, not to a generic table.
  • Route alerts to a named person. Not a mailing list. One owner per asset, with an escalation path.
  • Close the loop into a work order. Every actionable alert becomes a planned job with an owner and a date — ideally integrated with your CMMS.
  • Design for the site. Edge buffering for load shedding, hardware rated for dust and heat, and trending simple enough that your existing team can act without a full-time analyst.
  • Start small, prove it, scale. A handful of critical machines that demonstrably avoid one breakdown will fund the rollout — and build the internal trust the programme needs.

What "good" looks like after 90 days

A working programme isn't measured in sensors installed; it's measured in breakdowns avoided and alarms acted on. Within about 90 days you should see: a short, trusted alert stream (not noise), at least one developing fault caught and planned out of a breakdown, and maintenance crews who open the dashboard because it has earned their attention. If instead you have a wall of red alarms nobody reads, the scoping was wrong — and adding more sensors will make it worse, not better.

This is exactly how we approach asset & condition monitoring at addanode: criticality first, decision-led, and built to survive South African conditions. It runs on the same addaNet platform as your OEE and energy data, so reliability sits in one picture instead of a silo.

Frequently asked questions

Is wireless vibration monitoring accurate enough, or do we need wired analysers?

For trend-based early warning on most plant assets, wireless sensors are more than accurate enough and far cheaper to deploy. For detailed root-cause diagnostics on the most critical machines, combine them with higher-rate measurement where it's justified. Match the tool to the decision, not the brochure.

Which assets should we monitor first?

Rank rotating equipment by the cost and risk of its failure — main drives, critical pumps, fans, compressors, gearboxes whose stoppage halts production or threatens safety. Instrument from the top of that list down, only while the payback holds.

How do we stop the system from flooding us with false alarms?

Baseline each machine to its own normal behaviour, set thresholds per asset rather than from a generic table, and route alerts to a named owner with an escalation path. An alert should mean "go look," never "ignore me."

Will it keep working through load shedding?

It should. Choose edge devices that buffer locally and sync when power and connectivity return, so you don't lose the record of what happened during an outage. Cloud-only systems with no edge buffering are a poor fit for South African sites.

Do we need a full-time vibration analyst to run it?

Not for a well-scoped programme. Automated baselining and trend alerting let your existing maintenance team act on clear warnings. Specialist analysis is reserved for the few critical machines and the occasional deep diagnosis — not every reading.