Don't forget the operating supervisors in the brainstorming, if you have a system where "others" beside the maintenance geeks can fill in a request, you run the risk of having the code "other" being abused...

Steven,

"You have mail"

quote:

Originally posted by svanels:
... you run the risk of having the code "other" being abused...

Should the "other" or miscellaneous" code always be included in the pick list?

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?

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.