A CMMS with real failure coding, not a notes field.
SMMS (Smart Maintenance Management System) is a CMMS that captures failure mode, cause, and detection method as governed vocabulary selections enforced at work-order closeout — not free text. Every coded failure traces back to the ISO 14224 Annex B reference vocabulary, so your failure history is countable from day one.
Why free-text failure data fails
A comment field is easy to fill in and impossible to analyze at scale. "Pump acting up again" and "bearing noise, replaced seal" describe two different technicians' writing styles more than they describe two different failures — a spreadsheet full of free text cannot answer "how many bearing failures did we have this quarter" or feed an MTBF calculation without a human re-reading every row by hand. Reliability and quality standards bodies (including ISO 14224) exist specifically because structured, comparable failure vocabularies are what make failure data usable for anything beyond a single work order's history.
How failure coding works in SMMS
A technician closing a corrective work order on a governed asset type fills in four coded fields — no free-text failure description is treated as the record of what happened.
Failure mode
What happened — selected from the seeded ISO 14224 Annex B vocabulary (e.g. "Bearing Failure", "Overheating").
Failure mechanism
How it happened physically — fatigue, wear, corrosion, fouling. A governed picklist, not a text field.
Failure cause
The underlying reason — lubrication, misalignment, contamination, installation error.
Detection method
How it was found — operational observation, vibration analysis, scheduled inspection, continuous monitoring.
Each field is a foreign key into a governed reference table (write-REVOKEd from the application role — only a migration can add or edit a code), and the relationship from the work order's failure-data record to those tables is RESTRICT, not SET NULL. A governed closeout will not save without resolving to real, coded values.
How coded data feeds MTBF/MTTR and RCFA
Because every closeout resolves to the same governed vocabulary, an asset's failure history is directly countable: how many times did this pump class fail on "Bearing Failure" in the last year, and what was the mean time between those events? Coded failures are also the entry point into SMMS's RCFA workspace — a recurring coded failure mode is exactly the pattern an investigation should be opened against, and the investigation links back to the coded records that triggered it rather than starting from a blank page.
What's configurable per tenant vs. governed globally
The ISO 14224 Annex B failure-coding vocabulary itself (failure mechanisms, causes, detection methods, consequence categories) is governed reference data — the same across every tenant, seeded by migration, not editable by any tenant admin. What each tenant configures is which asset classes and work-order types require coded closeout, and how the seeded equipment-class taxonomy extends to their specific fleet. That split is deliberate: the vocabulary that makes data comparable stays fixed; the scope of where it's enforced is yours to set.
A coded closeout, start to finish
A technician at Meridian Fabrication Works (a synthetic demo tenant) closes a corrective work order on Conveyor 12 after a jam. The closeout form requires: failure mode ("Blockage/Plugging"), mechanism ("Flow restriction"), cause ("Material buildup"), and detection method ("Pressure differential monitoring") — each picked from the governed list, not typed. The work order cannot close without all four resolving to real reference rows. Six months later, a reliability engineer filters Conveyor 12's failure history by mode and sees three "Blockage/Plugging" events in the same quarter — a pattern a paragraph of free-text notes across three separate work orders would never have surfaced without someone reading all three by hand.
Limitations
- There is no automatic re-classification of legacy free-text failure history — if your prior CMMS recorded failures as notes, that text imports as notes; it does not retroactively become coded data without a human review pass.
- Table B.15 failure-mode codes ship via a dedicated seeding step, not the base migration alone — confirm with your implementation contact that the seeding step has run for your tenant before relying on the full B.15 code set.
- Legacy failure-code migration is generic CSV/Excel import with downloadable templates — there is no vendor-specific certified importer for any particular legacy CMMS.
Frequently asked questions
What is failure coding in a CMMS?
Failure coding is capturing what broke, why, and how it was found using a fixed, governed vocabulary instead of a free-text field — so failure history can be counted, compared, and analyzed later (for MTBF/MTTR, root cause analysis, or spend patterns) instead of read one work order at a time.
How is this different from just writing notes on a work order?
Notes are still there for context, but the failure mode, mechanism, cause, and detection method are separate, governed selections enforced by foreign-key constraints at closeout — a technician cannot save a governed closeout without picking real, coded values. Free text can say anything; coded data can be counted.
Do I have to build my own failure-code list?
No. The ISO 14224 Annex B vocabulary (82 rows across four tables) ships seeded by database migration before your tenant records its first work order. You extend it for equipment-specific failure modes as needed; you are not starting from a blank list.
Can I still track failure data if my team does not know ISO 14224?
Yes — the picklists use plain-language failure-mode names ("Bearing Failure," "Seal Leakage," "Overheating") that a technician recognizes without knowing the standard behind them. The ISO 14224 structure is what makes the data comparable across sites and time; your team doesn’t need to learn the standard to use it correctly.
Can I export failure code history?
Yes — failure data exports through the same reporting surfaces as the rest of your work order history: CSV/Excel/PDF export and the REST API, so it can feed an external BI tool or a reliability analysis spreadsheet.
See the standard behind the codes
See structured failure coding on your own fleet.
Request a demo and we'll walk through closeout coding on a tenant shaped like your assets — or take the free RMI QuickScan first to see where your failure data practice stands today.