What equipment maintenance software has to do

Any product can store a list of equipment. Six behaviours decide whether that list turns into a maintenance history you can act on, and only some products have all six.

1. Work attaches to the equipment, not the building

If jobs are filed against a location, you can never answer a question about a machine. The path from standing in front of equipment to opening its job has to be one action, which in practice means scanning a code.

2. Readings are stored as numbers and trended

A pressure or a temperature recorded during a check is only worth taking if you can see it next to the last twelve. If readings go into a free text note, they are decoration.

3. Schedules can run on meters as well as dates

"Every 2,000 running hours or twelve months, whichever comes first" is how most plant should be maintained. Products that only count days will over-service the quiet machines and under-service the busy ones.

4. The manual and the drawing live on the asset

Documents in a shared folder are not found by somebody standing in a plant room. Attached to the asset and reachable by scanning the code, they are read, and the time saved shows up in repair times within a quarter.

5. Removal is a state, not a delete

Equipment that is taken out has to be marked as removed with a date. Deleting it takes the history with it and leaves old work orders pointing at nothing.

6. History is answerable without an export

Pick one machine and ask three questions: how many times has it failed in two years, what was actually wrong each time, and what has it cost. If answering needs a spreadsheet, the record is not doing its job.

The demo test

Ask the vendor to scan a code, complete a check with a reading, then show you that reading next to the previous five and the failure history underneath. Five minutes, and it tells you more than any feature list.