What preventive maintenance software has to do

Every maintenance product can store a preventive schedule and generate jobs from it. That is table stakes and it is not what decides whether your programme stays on track. Six behaviours do, and only some products have them.

1. Schedules on hours and cycles, not only dates

"Every 2,000 running hours or twelve months, whichever comes first" is how most plant should be maintained. If the product can only count days, you will over-service the quiet equipment and under-service the busy equipment, permanently.

2. Late work stated in real terms

Not a red dot. "Five months late" and "two days late" have to look different, or people learn to ignore the colour. This is the single feature most closely tied to whether a schedule stays honest.

3. Assignment to a team, not a person

A schedule tied to one named technician creates a single point of failure and a resentment problem. Drawing from a pool spreads the work and the knowledge, and the round survives somebody leaving.

4. Estimates that come from the actual runs

The product should tell you how long this job really takes, from the last twenty times it was done, and plan with that number. Planning with somebody’s guess from 2019 is why the week falls apart on Wednesday.

5. A failed step raises tracked work by itself

The point of an inspection is what happens next. If closing the loop requires somebody to notice a finding and type a second job, the loop will not close reliably.

6. Escalation that reaches somebody who can act

An alert to the person who already knows the job is late achieves nothing. It has to reach somebody who can move resources, and it has to name what is late and where.

What to test in the demo

Ask the vendor to make a schedule that fires on running hours, then to show you the screen a supervisor opens on Monday morning, then to fail a step and show you what happens on its own. Fifteen minutes, and it tells you more than the feature list.