I do not know of a good listing for failure codes, but would be very interested in a listing also.

Do you not think that the majority of codes...at least a good portion of the codes...would come from a FMEA of all your most critical assets? I am trying to kick off development (should read re-development) of our failure and cause codes for our equipment in the near future. One of my primary goals is to have a set of fault codes that are the same as the alarms the operators call maintenance for...or plant vocabulary may be a better way to describe it. An operator will call and say that a piece of equipment or system had a "cycle time out" or "drive fault such and such". Our goal is to enable the history to be built around how we communicate the faults. Once an operator calls with the fault or alarm that was triggered by the control system, we respond to the call, troubleshoot and repair. The Maintenance technician will then enter which alarm was triggered by the system, enter the cause code for that alarm, enter the action code for what action was taken to return to normal operating state, and then fill out a text field for the corrective actions which include: what troubleshooting steps he has taken, what caused the failure to occur (to the best of his ability) and what in his opinion needs to happen to avoid this problem re-occurring in the future. This, in our opinion, results in a history being generated that is quite useful for triggering reliability analysis and for future reference if this fault occurs in the future with someone that may not be as familiar with the system. If a technician responds to a call for "x" alarm and has difficulty troubleshooting, then he may query the work order history for that fault and be able to see what has occurred in the past and what was done to correct the problem in the past.

Of course there are many fault codes for failures that do not result in an alarm being generated and a listing would be interesting to review.
We currently use RFO codes but feel the list needs to expand.

May I suggest a good old fashioned brainstorming session with your subject matter experts: the maintenance supervisor(s), Maintenance technicians and Planner. Make the list yours, not only with failure codes, but corrective action codes.

I consulted for a major drug manufacturer, and they had quite a list of failure codes they used in the Maximo CMMS. Allows some good analysis to take place (FRACAS).


When expanding the list make sure that it does not get that long that different users describe a the same failure by two different codes because they are so many that more than one seems to define the failure.

I like the idea of the brainstorming, get the planners, supervisors and the most experienced of the technicians of each crew/trade. Then re-check to avoid duplicate codes.
You should apply the kiss (keep it simple not stupid) principle by putting you in the place of the guy punching in the data.
In that case I pretend to be laziest, meanest, dumbest (with a real bad day) SOB on the plant.
What would he do if the code he has to type is contained in a nice dropdown list with 120 entries? Big Grin

I would classify only the 10 most frequent options with the option other cause/failure/problem
"Other" is fine, so long as the comments section tells you what the "Other" is. If that particular failure mode becomes cronic, it's time to add it to the drop down list.

As for the meanest, laziest, dumbest SOB in the plant, it's time for an attitude adjustment and an explanation of the finer points of failure anaysis. Hard to trend a vague reference to other. Don't be afraid to create THE list you need for your facility. KISS is a good rule of thumb I like to apply, but if you don't manage the business, the business will manage you! That is paramount.
As for the meanest, laziest, dumbest SOB in the plant, it's time for an attitude adjustment...

Disciplinary action would have an adverse effect Big Grin , I will explain my point.

When you want to test the funcionality of something you do not need someone with a degree in Rocket Science a good guinea pig will do.

When we wanted to test a new software (years ago) we called in one of the employees called Shirley (administation type, not very technical, I would say a little clumsy, but her attitude was the key factor Big Grin).
Warning this is not a gender attack

If it survived the test we could stamp on it: Approved and Tested under Extreme Conditions
Where others Mad would have thrown the computer out of the window long time ago, she would go ahead and screw up even more!! Big Grin

There have been undocumented rumours that she was able to conduct psychokinesis, like crashing a hard drive of a computer just by looking at it.
The bottom line, she could surface problems you would not imagine, just by doing everthing that is "verboten" in her inguinity, like pulling out the electricity to boost things up.
Her best quality still is showing up at the right moments when the engineers are pulling out each others hair during discussions/meetings and cool down the situation with coffee, thee, ice or a smile, and protect here (female) boss from the younger (iresponsible ?) engineers. Big Grin
Just an opinion, but I think you have to think "Who is making the request?" In our case it will be mostly operators, not trades people making the request. The list they should choose from would be less detailed like the list Bryan Weir had supplied [modified to your own industry]This would be called "Problem Codes"[The problem that was found]. After the work is completed on the WO there is a place to have the "Failure Code"[The actual failure that occured]. This is where the trades person would have the input on what actually failed, This list would be a more detailed list to the specific equipment that they have worked on. Does anyone else share my veiw on this or if you disagree, I would like to hear why. Regards
Fergy Smiler
Yes, I fully agree with you Fergy. As I said in my own report ...

The complexity of the codes will be dependent on the know-how of the system users. For example, if unskilled operators are using the codes to report equipment problems they will have to be of a general nature.

If it is deemed appropriate problem codes can be targeted towards operators with more complex failure codes on specific plant for trained maintenance personnel.
Many MP2 users populate the Safety Notes field with their RFOs and Solutions. This data then prints on the Work Order – maintenance personnel simply circle the RFO and Solution pair before data input eliminating guessing at these codes.

I have developed a Crystal Report which produces an Excel file of RFO and Solution sets for each piece of equipment. This file can be imported into your equipment module.

You can email me for an example df@flemingtechnical.com

Reason for outage, or RFO codes, are very beneficial because they help you quickly identify the cause of equipment problems without reading through numerous comments on closed work orders.

I suggest the following in developing your codes- run a work order history report, by equipment type. With the data from these work orders and your experience, make a list of the reasons why the equipment may fail, and then develop corresponding codes. You may need to abbreviate, as you only have 8 characters for the code. Make the codes as simple as possible. Explain them to your maintenance staff and post them in locations where work orders are written.

It may take a while for the codes to be used. Be patient- your effort will pay off!
Originally posted by Porter Claytor CPMM:
I would be happy to send anyone a copy of my list - eamil me porter@cnsassociates.net
Datastream consultant for many years

I would be very appreciative to have your list. Knowing a specialist and how they work with CMMS is certainly a benefit to me.
my email addie is:
Hope to hear from you

cheers and advanced thanks