Many predictive-maintenance projects stall because they begin as a plant-wide programme. A small plant does not need that. It needs a short, bounded start that either shows value on a few machines or shows clearly why not. This is a plan for the first six weeks.
Before week 1: pick three to five machines
Choose by consequences, not by technology. Good candidates:
- Stop the whole line when they fail, and have no spare machine next to them.
- Take long to repair or wait long for a part.
- Have failed before, so there is history to compare with and people who know the symptoms.
- Show their condition in measurable signals: rotating equipment (pumps, motors, compressors, fans, conveyor drives) and thermal equipment (ovens, heaters, heat exchangers) are the usual start.
Avoid starting with a machine that fails rarely and unpredictably, or one with no connection to any controller or sensor. You can add those later.
Write down the success criteria first
Agree with maintenance and management, in writing, what "it worked" means. For example:
- The maintenance team reviews every alert and marks it useful or not.
- At least a defined share of alerts are judged useful, and the false alarms are analysed, not ignored.
- At least one real finding, or a documented reason why none appeared in the period.
- The data from the chosen machines is available most of the time.
Without this, a pilot ends in opinions.
What data you probably already have
You rarely need to start with new sensors. Check what exists:
- PLC and SCADA tags: temperatures, pressures, flows, states.
- Drive data: motor current, speed, torque from frequency converters.
- Maintenance history: repairs, causes, parts used, dates.
- Operator knowledge: "that pump gets noisy before it fails".
Add sensors only where an important signal is missing. For rotating machines this is most often vibration on the bearing housings.
Week by week
Week 1: connect and look. Connect the data sources, then check quality: timestamps, gaps, units, plausible ranges. Fix the boring problems now; they will otherwise look like machine faults later.
Week 2: baseline. Record how the machine behaves in normal operation across its usual loads and conditions. "Normal" for a pump at half load is different from full load, so compare like with like.
Weeks 3 and 4: thresholds and trends. Set limits and trend alerts. Review every alert with the maintenance team. Expect noise at first and tune it down; a system that cries wolf is switched off within a month.
Weeks 5 and 6: close the loop. Turn alerts into work orders with a checklist, assign an owner and follow what happens: was the fault found, what was done, what did it cost. Then compare with your success criteria.
Common pitfalls
- Alert fatigue. Fewer, better alerts beat many weak ones.
- No owner. Every alert needs a person who decides what to do.
- No process behind the alert. If an alert does not lead to a work order and a decision about a part, nothing changes.
- Expecting prediction from nothing. A model needs signal. Some failures, such as sudden electrical faults, give little or no warning. A good pilot is honest about that.
- Dirty data. A sensor wired to the wrong machine will teach you nothing.
After week six
You should have a clear answer for each machine: the signals gave useful warning, or they did not, and why. If they did, extend to the next group of machines and connect the work orders to the system your team already uses. If they did not, you spent six weeks and a small budget to find out instead of a year.
Our own pilot follows this shape: five to seven weeks on three to five of your critical machines, with success criteria agreed before we start.