Key points
- Record problem, cause and action as three separate fields, plus the failed component, instead of one combined breakdown code.
- Build the list from your own closed work orders, not from a generic catalogue, and keep each picklist short enough to read on a phone.
- The cause is chosen when the job is closed, by the person who did the repair, and "cause unknown" is an honest answer that beats a guess.
- Review the codes monthly: a growing "other" share, a code nobody uses or one code covering half the jobs means the list needs fixing.
What a breakdown code is, and why one code is not enough
Every breakdown work order already carries a description. The trouble is that free text cannot be counted. One technician writes "bearing gone", another writes "brg replaced, noisy", a third writes "motor issue". All three may be the same failure, and no report will ever group them. A breakdown code fixes that by forcing a choice from a fixed list, so you can ask "how many bearing failures did line 2 have this quarter" and get a real answer.
The most common mistake is a single code field with entries like "electrical", "mechanical", "hydraulic" and "other". That list mixes up what was seen, where it was and why it happened, and it is too coarse to act on. Knowing that a machine had many "mechanical" breakdowns tells you nothing about what to change. Split the information into separate fields, each answering one question.
| Field | Question it answers | Who fills it in, and when |
|---|---|---|
| Problem (symptom) | What did someone notice? | Operator or requester, when the breakdown is reported |
| Component | Which part of the machine failed? | Technician, during or after the repair |
| Cause | Why did it fail? | Technician, when closing the work order |
| Action | What was done to restore it? | Technician, when closing the work order |
How to build the list, step by step
Do not start from a generic catalogue of hundreds of codes downloaded from somewhere. Nobody scrolls through a long list on a phone with greasy gloves; they pick the first plausible entry or "other". Start from what actually breaks in your plant.
- Pull your closed breakdown work orders for the last year, or as far back as you have them, and read the free text descriptions. This is tedious, and it is the most valuable hour you will spend on the whole exercise.
- Group the descriptions into piles for each field: what was seen, which part failed, why, and what was done. Write the pile names in the words your technicians use, not textbook terms.
- Split by equipment class. A forklift, a chiller and a CNC machine do not share components. Keep one short component list per class, so a technician on a forklift never sees "compressor valve".
- Keep cause and action lists shared across classes where possible. Causes such as wear, lack of lubrication, contamination or operating error apply to most equipment, and a shared list lets you compare causes across the whole site.
- Trim each picklist until it fits on one phone screen without scrolling. If you cannot, the list is too detailed or the equipment class is too broad.
- Test it on old jobs. Take a handful of past work orders and code them with the new list together with two technicians. Wherever you argue about which code fits, the definitions need work.
- Write a one line definition for every code and make it visible where the code is chosen. "Wear: normal deterioration over time with correct use and maintenance" stops wear being used for everything.
An example code set for a pump class
The table below is an example to show the shape of a workable list, not a recommended standard. Your own list should come from your own work orders.
| Problem | Component | Cause | Action |
|---|---|---|---|
| Leaking | Mechanical seal | Wear | Replaced |
| Noise or vibration | Bearing | Lack of lubrication | Repaired |
| Low flow or pressure | Impeller | Contamination or foreign object | Cleaned |
| Overheating | Coupling or alignment | Installation or alignment error | Adjusted or realigned |
| Will not start | Motor or electrical supply | Operating error | Reset or restarted |
| Trips or stops | Controls or sensor | Cause unknown | Inspected, no fault found |
Read across a row and you get a sentence: "leaking, mechanical seal, wear, replaced". The columns are independent, though. A noisy bearing can be caused by lack of lubrication, contamination or misalignment, and the action can be anything from greasing to replacement. That independence is the whole point: it lets you count bearing failures and, separately, see what keeps causing them.
The rules that keep the codes honest
A code list fails quietly. Nobody complains; the data just slowly turns into noise. These rules are where most of the value sits, and most of them are things people learn the hard way.
- Never ask for the cause when the breakdown is reported. The operator does not know it yet, and an early guess tends to stick. Ask for the symptom at the start and the cause at close.
- Allow "cause unknown" and count it. If the form forces a cause, a tired technician will pick "wear" because it blames nobody. An honest unknown tells you where root cause analysis is needed; a fake wear tells you nothing.
- Keep "operating error" neutral. If picking it gets an operator into trouble, technicians will stop picking it to protect colleagues. Treat it as a signal about training, guarding or design, not about a person.
- Separate "no fault found" from a repair. Repeated no fault found jobs on one machine are a story of their own: an intermittent fault, a sensor, or an operator who needs a better instruction.
- Do not change the meaning of a code once it is in use. If you split "bearing" into "motor bearing" and "pump bearing", create two new codes and retire the old one. Otherwise last year's numbers and this year's numbers measure different things and the trend is meaningless.
- Do not let "other" become a hiding place. Keep it, because forcing a wrong code is worse, but make a short free text note mandatory whenever it is picked. Those notes are where your next new code comes from.
- Code each failure, not each visit. If a technician comes back three times for the same leak, that should be one breakdown with three visits, or three linked work orders, not three separate failures that inflate the count.
A worked example: what the codes reveal
This is an illustrative example, not a real plant. Imagine a site with several identical transfer pumps. Before coding, the breakdown log simply says the pumps "break down a lot", and the usual response is to keep spare pumps on the shelf.
After a few months of coding, the team filters breakdowns by the pump class and sorts by component. Mechanical seals stand out. Filtering seal failures by cause, most are coded "wear", but a note in several "other" entries mentions the pumps running dry when the supply tank empties. Running a pump dry is not normal wear; it destroys seals quickly. The team adds a "dry running" cause code, recodes the recent jobs with a technician, and the picture changes: the problem is not the seal, it is the missing low level cutout on the tank.
Notice what made this work: separate component and cause fields, a mandatory note on "other", and someone reading those notes. With a single "mechanical" code, the same data would only have confirmed that pumps break down a lot.
Checking every month that the codes still work
Set aside a short review each month, ideally with one or two technicians in the room. You are not reviewing the failures yet; you are reviewing whether the codes describe them well. Look for these signs:
- "Other" is growing. Read the notes and turn recurring ones into new codes.
- One code covers a large share of jobs. It is probably too broad. Split it, using new codes as described above.
- Some codes are never used. Retire them so the picklists stay short.
- The first entry in a list is picked suspiciously often. That usually means people are not reading the list. Reorder it or shorten it.
- "Cause unknown" keeps appearing on the same machine. That machine is your next candidate for a proper root cause analysis.
Once the codes are stable, the breakdown report becomes a short list of decisions: change a lubrication interval, add a check to an inspection, fix a design flaw, train a shift. If you run breakdowns in Solmex, the breakdown records and reports are where you would set up these fields and filter by component and cause. The method works the same in any system, including a well kept spreadsheet.