A CMMS organizes information and work; it does not automatically make that information reliable. If a pump appears under three names, repairs are recorded against an entire line, and closure notes only say “done,” analysis has little value. The problem may be software, but also entry rules, asset structure or work processes. Test those hypotheses before buying another platform.
Choose one concrete operational question
Start with a question such as: which assets on this line cause the most repeated downtime? Check whether the data can actually answer it. You need the correct asset, a distinction between downtime and repair, relevant hours and a defined defect. If these fields are unavailable or inconsistent, build a focused improvement rather than indiscriminately cleaning the whole database.
| Field | Before | After |
|---|---|---|
| Asset | Workshop pump / P12 / line 2 | Unique ID P-012; parent line 2; matching field identifier. |
| Failure | Broken | Loss of flow; observed seal leak; cause unconfirmed. |
| Work performed | Repaired | Seal replaced, part reference, time and recommissioning test recorded. |
| Time | One undefined duration | Separate downtime and labour hours. |
A master-data checklist
- One stable identifier per asset, with a usable hierarchy and duplicate rules.
- Parts lists linked to the correct equipment and checked against the installed configuration.
- Failure codes simple enough to use while separating symptom, mode and confirmed cause.
- Defined closure fields, a distinction between zero, unknown and not applicable, and sample checks.
- An owner for each rule and a process to change records without creating competing versions.
Do not turn a hypothesis into a root cause
“Defective bearing” may describe a part, not why it degraded. Leave an unknown cause unknown until validated. A code dictionary and entry examples reduce differing interpretations across teams. ISO 14224 provides a reliability-data framework for specific sectors; respect that scope rather than presenting it as a general requirement for every plant.
What to fix before deploying AI
AI can group text or identify patterns, but cannot make inconsistent history accurate. Before a pilot, define the question, an expert-validated reference sample and unacceptable errors. Control access and confidentiality. Compare results against a simple analysis, then verify recommendations; no automated suggestion should independently change a safety rule or critical plan.
Begin with one asset family and review a work-order sample with users. Correct the rules that block decisions, train the team and check the same type of record again. Success means better decisions and actual use of data, not the number of mandatory fields added.