Predictive Maintenance for Small Operations: Start with the Failure You Can See

A generator that runs hot. A cold room that drifts out of range. A pump that starts to vibrate. A vehicle that returns with the same repair note.

Those are sensible places to ask whether predictive maintenance could help. You do not need a factory full of sensors to begin. You need one costly or risky failure, a sign that appears before it, and someone who can act when the sign changes.

My rule is simple: start with the failure you can see, not the software you can buy.

Start with the failure, not the sensor

Predictive maintenance sounds like a technology purchase. In a small operation, it should begin as a decision about risk.

Ask three questions:

• Which failure interrupts work, spoils stock, delays service or creates a safety concern?
• What changes before the failure: temperature, vibration, pressure, runtime, sound, current draw, leakage or a repeated inspection finding?
• What would the team do if it received a credible warning two hours, one day or one week early?

The third question is the one people skip. An alert has no value if it arrives in a WhatsApp group nobody owns, uses a measure nobody trusts, or gives the technician no time or authority to act. “The pump may fail soon” is not a maintenance decision. “Inspect the pump before tomorrow’s first production run” is closer to one.

Give the first trial a boundary. “The machine is unreliable” is too broad. “The generator overheats after extended operation under load” is testable. “The cold room loses temperature overnight” is another. Choose one asset, one failure mode and one observable signal.

What predictive maintenance actually adds

Routine inspection asks, “What condition is this asset in today?” Preventive maintenance asks, “What should we service by the calendar or operating hours?” Predictive maintenance adds a third question: “Is the condition changing in a way that makes a known failure more likely?”

That change can be detected by a person, a handheld instrument or a fixed sensor. A technician may note a new bearing noise. A mechanic may measure vibration. A cold-room operator may record the temperature at the same times each day. A small fleet may combine mileage, repeated repair notes and inspection findings.

The practical target is not a perfect forecast of the exact failure date. It is enough warning to choose a safer and cheaper intervention: inspect, clean, lubricate, adjust, reduce load, order a part, schedule downtime or replace the component. A sensor is one method, not the definition of the work.

The minimum sequence for a useful trial

1. Define the failure in plain language

Write one sentence that includes the asset, symptom, operating context and consequence. For example: “The water pump loses pressure during the afternoon shift, forcing a service interruption.” Or: “The generator temperature rises abnormally after two hours above its normal load.” These examples scope a trial; they are not diagnoses of a particular machine.

Record what counts as a failure, an early warning and a nuisance. If a technician uses “noise”, “rough”, “hot” and “weak” interchangeably, the history will be difficult to compare. Agree a small vocabulary before buying equipment.

2. Collect consistent records

Begin with the records already within reach. A spreadsheet, paper inspection sheet or simple form can work if the same fields are completed every time.

Record the asset and component, date and time, operating hours, load or working conditions, measurement and method, symptom or failure, action taken, person responsible, downtime, direct cost and the test that confirmed the result after repair.

Free-text notes still have value. “Belt slipped; reduced power; tension adjusted” says more than “serviced”. Standard terms make patterns easier to find. The source book’s discussion of maintenance history also points to a common constraint: records may be incomplete, abbreviated, held in different media or entered without a reliable failure cause.

Do not backfill precision that nobody observed. If the exact temperature was not measured, write “temperature felt high during inspection” rather than inventing a number. Honest uncertainty is more useful than a neat false history.

3. Set a baseline

A baseline is a picture of normal operation under stated conditions. It might include a temperature range, vibration reading, pressure, runtime, sound description or number of starts before the equipment settles.

The conditions matter. A pump under full load should not be compared blindly with the same pump idling. A generator’s temperature depends on load, ambient conditions, ventilation and maintenance state. A vehicle’s mileage and route affect wear. Record the context beside the number.

You may have to begin with a short observation period. Call it a provisional baseline. If the asset runs irregularly or the failure is rare, the first phase may be disciplined inspection rather than automated prediction.

4. Choose an alert that leads to action

The alert should answer four questions: what changed, how serious is it, who receives it and what must happen next?

It might mean “inspect before the next shift”, “check the filter today”, “reduce the load and call the technician”, or “stop the asset because the condition is unsafe”. These actions are different. Do not collapse them into one red light.

Set the first threshold with the person who will respond. A low threshold may create many warnings and little trust. A high threshold may miss the time available to act. You are choosing a working compromise, not discovering a universal number.

5. Test the alert against real work

Run the alert in the background before allowing it to change the maintenance schedule. Compare it with inspection findings, breakdowns and repair notes:

• Did the warning appear before a confirmed failure?
• How much useful lead time did it provide?
• How often did it warn when no fault was found?
• How often did the asset fail without a warning?
• Could the team complete the recommended action in time?

This is where a promising dashboard meets a dirty workshop floor. The technician may find that a temperature rise came from a blocked air path, a changed load or a faulty sensor rather than the component you expected. The alert has still taught you something, but it is not ready to run unattended.

6. Review false alarms and misses

False alarms spend attention, interrupt work and teach people to ignore the next warning. Missed failures are more serious: they create the impression that monitoring can replace inspection when it cannot.

After each intervention, classify the warning as a useful hit, false alarm, missed warning or unresolved case. Look for causes: a sensor moved, a reading was taken under different conditions, the threshold was too sensitive, the failure definition was vague, or the response was delayed.

Keep the review small enough to happen. A monthly conversation around one asset may be more valuable than a quarterly meeting about a dashboard nobody uses.

When a small operation should stop

Predictive maintenance is not a badge of maturity. Stop or postpone the trial when:

• there is too little history to distinguish a change from normal variation;
• sensors are unreliable, badly placed, not calibrated or regularly disconnected;
• no named person has the time, authority, parts or access needed to respond;
• operating conditions change so much that one baseline misleads;
• the failure is cheaper and safer to replace than to monitor; or
• the consequence is safety-critical and the alert has not been validated.

In those cases, improve the basics: identify the asset, standardise inspection notes, record runtime and failures, keep critical spares visible, and assign a response owner. That is not a failed predictive-maintenance project. It is the preparation that makes a later trial credible.

A one-page readiness check

Before spending on sensors or software, write down:

1. Asset and failure: what fails, how often, and with what consequence?
2. Observable signs: what can a person or instrument measure before failure?
3. Record quality: do the last repair and inspection notes identify the asset, condition, action and outcome?
4. Baseline: under what load, time and environment will “normal” be defined?
5. Alert: what action will follow, and how much lead time is useful?
6. Owner: who reviews the warning and who can authorise the work?
7. Test: how will you compare warnings with confirmed findings and missed failures?
8. Stop rule: what evidence would make you pause or abandon the trial?

If the answers are clear, run a narrow pilot. Monitor one failure on one class of asset. If the answers are vague, spend the next maintenance cycle improving the record and inspection routine first.

The strongest small-operation maintenance system is not the one with the most sensors. It is the one that turns a visible change into a timely, owned and technically sound decision. Start there.