Critical Component of the CMMS: The Repair Work Order

Critical Component of the CMMS: The Repair Work Order
Christopher Winston


The better and more consistently recording of repair activities is done, the greater potential for yielding greater and more specific information about an operation
From the very start, the implementation of a computerized maintenance management system (CMMS) is a long and arduous process. One of the largest concerns is how to effectively get the correct data into the system in the first place, and then, how to get useful information out.
What follows can provide a method to get better data into the CMMS with every work repair request. The yield is more and better data for analysis, which is the all important question in the long-term successful evaluation of the implementation—is this information tool providing useful information?
There is no replacement for a good, integrated implementation plan that covers the setup of the database, training, data design and collection, etc. Consider this as an enhancement to be added to the existing plan.
Repair data
Basic repair data fields come in four categories:
• Origination
• Planning
• Scheduling
• Results
Origination data includes the emergency flag, the original observer of the problem and how the person can be reached, the equipment experiencing the problem, and a problem description. This data must be obtained to effectively get labor and materials assigned to the job.
Although it is most important to get all data consistently and correctly into each field, most problems occur at work order origination and multiply as the work order is processed. See accompanying section "Work Order Data Fields."
The two most important fields at the origination of a repair are the equipment number and the problem description. The equipment number is needed to get the person to the correct equipment, as well as to insure charges are posted back to that piece of equipment for historical detail as well as summary analysis of its department, process, unit, etc.
The importance of the problem description cannot be understated. Whenever a CMMS is implemented, every person who may originate a work order should be trained to call in (type in, write in, etc.) the problem description. This should include what was observed that prompted the call. Sample bad problem descriptions:
• "It’s not working" or "It’s down."
• "It’s broken."
• "It sounds like it is going to fail."
Bad problem descriptions do not provide enough descriptive data and they lead to bad descriptive results such as:
• "It’s working" or "It’s up."
• "It’s fixed."
• "Sounds OK to me, just a little noisier than normal."
If the historical records within the system contain descriptions similar to these, plan to retrain everyone immediately and include a sample of these records to show how useful (or not) they are for historical analysis.
More effective descriptions would be based on what the observer/originator of the problem sensed:
• Saw a leak
• Heard excessive gear grinding or a pop in the disconnect panel
• Smelled something unusual burning
• Felt excessive vibration at normal run speed
• Tasted like there was too much syrup, but the controls indicate the proper mix
These are oversimplified examples, but a trained mechanic can identify a starting point and promote a response that is more descriptive of the cause. For historical purposes, this can be invaluable in looking at repetitive problems and working toward engineering them out of existence.
Using a basic repair order
Better understanding of why proper problem descriptions should be used is probably the biggest and most inexpensive way to make a major leap in repair data capture.
A basic repair work order has room for free form text, but also specific codes that can be selected to help sanitize what is reported about the work, specifically to enhance analysis, expedite reporting, and, at the same time, not overburden the mechanic with paperwork.
Results data should at a minimum include the skill/trade that completed the work, work time, a work description (what was done), materials used and/or costs, a cause code, downtime, and an assessment of the repair.
The skill should have an associated wage (or wage plus burden) rate so that hours may be converted to costs for charging back to each piece of equipment, and the associated grouping codes (department, unit, etc.), when combined with the work time. The work description should explain the action taken on what part of the equipment