Failure coding in a CMMS is the practice of closing every corrective work order with a short, three-part pick-list, problem, cause, and remedy chosen from a controlled list instead of typed as free text. Coding turns a pile of repair notes into countable data you can sort, rank, and trend, which is the only way failure history ever answers a question.
Most plants already have a CMMS. Far fewer get analyzable data out of it, and the reason is almost always the close-out step: technicians type “fixed it” into a notes box and move on. This guide is about the workflow side of failure codes, how to design the pick-lists, how to make technicians actually use them, and how the coded data feeds Pareto charts, MTBF and PM decisions. (For the master list of code values themselves, that is a separate exercise; here the focus is configuring and using them inside the system.)
What is failure coding in a CMMS?
Failure coding is structured data capture at work-order close-out. When a technician finishes a corrective job, the CMMS presents three linked drop-downs: what was wrong (the problem or failure mode), why it happened (the cause), and what they did about it (the remedy or action). Each field is a controlled list, so every job on that asset class describes itself in the same vocabulary. Six months later you can ask “how many bearing failures on the fillers, and what caused them?” and get a number instead of a reading assignment.
The structure mirrors the reliability-data standard the process industries use. ISO 14224 draws a strict line between the failure mode (the observed effect, such as external leakage), the failure mechanism (the physical process, such as corrosion), and the failure cause (the root condition, such as wrong material). Conflating those three is the single most common data-quality error in maintenance records, and a well-built pick-list is what keeps them separate at the point of entry.
Why not just use free-text notes?
Because free text does not aggregate. Ten technicians describe the same bearing failure ten ways, “brg gone,” “bearing seized,” “replaced brng,” “noise then failure”, and no report can group them. The information is in there, but it is trapped in prose. A Pareto chart of failure causes needs a field it can count; a paragraph is not that field. Free text is valuable as a supplement, for the story and the detail, but it cannot be the primary record if you ever want to analyze failures.
How do you build the failure-code pick-lists?
Build the lists per asset class, keep them short, and align the structure to ISO 14224 so the data means the same thing everywhere. Here is the sequence that produces lists technicians will actually use.
- Anchor the codes to the asset hierarchy. Codes hang off equipment classes, not individual machines. A pump class shares one problem/cause/remedy set; a conveyor class has its own. Get the asset hierarchy right first, because the codes inherit from it.
- Reuse a standard mode list, do not invent one. Start from ISO 14224 failure modes for that equipment class and trim to what your plant actually sees. A reusable failure mode library per asset class is exactly this list, maintained in one place and pushed into the CMMS.
- Separate problem, cause, and remedy into three fields. Do not collapse them into one “failure code.” The mode (what you observed), the cause (why), and the action (what you did) are different questions, and keeping them apart is what lets you later ask which causes drive the most downtime.
- Keep each list to a screen, roughly 8 to 15 values. A drop-down with 60 entries gets scrolled past; technicians pick “other” and the data dies. Cover the common cases, add one “other, see notes” escape valve, and review what lands in “other” to grow the list deliberately.
- Make the fields required on corrective close-out only. Force coding when a machine actually failed; do not force it on inspections or planned PMs, where it is noise. A required field at the right moment gets filled; a required field everywhere gets gamed.
- Pilot on one asset class, then roll out. Prove the lists on your worst-actor line for a month, fix the values that confuse people, and only then extend to the rest of the plant. Codes designed in a conference room and deployed everywhere at once are how you get 40% “other.”
How short should the pick-lists be?
Short enough that a technician on a phone at 2 a.m. picks the right value in a few seconds without scrolling. The failure of most coding schemes is over-engineering: someone imports a 200-line taxonomy, technicians cannot find their case, and they default to “other” or the first entry. A list of 8–15 clear, plant-specific values beats an exhaustive standard nobody navigates. Depth can live in the free-text notes that ride alongside the codes, the codes carry the countable summary, the notes carry the story.
Watch the “other” rate as your health metric. If more than roughly one in ten close-outs lands in “other,” the list is missing a common value or the wording is off. Review those entries quarterly and promote recurring ones into named codes. A coding scheme is a living thing, not a one-time import.
How do you get technicians to actually code failures?
The pick-lists are the easy part; getting honest, consistent entries is the real work, and it is a people problem more than a software one. Three things move the needle. First, close the loop visibly: show technicians the Pareto chart their codes produced and the PM change it drove, so the two clicks at close-out feel connected to something instead of feeding a black hole. People code carefully when they see the data used.
Second, make the fields fast and phone-friendly. If coding a job means scrolling three sixty-item lists on a cracked screen in a cold room, it will be gamed. Short lists, sensible defaults, and a mobile close-out that takes seconds are what keep the data clean. Third, review and coach on the codes, not just the repairs, a supervisor who spots a mis-coded job and corrects it in the moment teaches the vocabulary faster than any training deck. This is the same operator-ownership mindset behind total productive maintenance: the people closest to the equipment own the data about it.
What does good failure coding let you do?
Once close-outs are coded, the reporting side comes almost free. You can rank failure modes by frequency or by downtime on a Pareto chart compute MTBF and failure rate per mode instead of per asset, and see whether a countermeasure worked by watching that mode's count fall. The coded history is what turns a reactive maintenance shop into one that hunts causes, the core move of a real reliability program. It also feeds the CMMS dashboards leadership actually reads. And it is the labeled history that any predictive maintenance effort needs: a model that flags an impending bearing failure is only useful if past bearing failures were coded consistently enough to learn from. Sloppy codes cap how far your analytics can ever go.
What the numbers say
- The reliability-data standard ISO 14224 was written to make failure and maintenance data comparable across operators, and it defines the exact separation your pick-lists should enforce, failure mode versus failure mechanism versus failure cause (ISO 14224:2016, Collection and exchange of reliability and maintenance data for equipment). Aligning your codes to it means your history can be pooled and benchmarked rather than stranded.
- Better failure data is also cheaper failure data: the U.S. Department of Energy’s FEMP O&M guidance, maintained by PNNL, finds condition-driven programs save 8–12% over preventive-only maintenance and can beat reactive operation by 30–40% (PNNL, O&M Best Practices: Maintenance Approaches). Those programs only work if the failure history under them is coded and trustworthy.
Failure coding is a small habit with outsized leverage: three drop-downs at close-out, chosen from short lists aligned to ISO 14224, are the difference between a CMMS full of stories and a CMMS full of answers. Get the lists short, keep problem-cause-remedy separate, and require them only where a failure actually happened. That clean history is what feeds every reliability metric worth tracking, and getting floor-level data trustworthy enough to trend is exactly the problem in the CLS case study. Start from the fundamentals in what a CMMS is if you are building this from scratch.