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.
If recording downtime, it must be defined and all personnel
must be familiar with how it is charged and used. The most
common discrepancy comes when a machine is out of service for
a maintenance reason during a nonoperating shift for that piece
of equipment. Is it down?
Get materials costs
Materials used and their costs are helpful for keeping inventory
up to date and charging materials to each piece of equipment.
Having the material identified by its tracking number in
the inventory control system (whether or not this is a module
in the CMMS) is essential for documenting proper part usage
and tracking and bill of material building. This is one of
the first areas of potential interface when the nonproduct
material is maintained by an organization/system outside of
maintenance.
This type of interface would allow documentation of the part
number, and then the cost could be brought over from the parts
inventory control system if it is not in the CMMS.
This cost is especially important in light of the fact that
many materials costs can exceed labor costs significantly,
and both are necessary to properly assess the maintenance requirements
and history of a given piece of equipment.
Assess the repair, use codes
Although additional comments about a job may not be entered,
it is a good idea to get the mechanic’s assessment of the repair
at least to the point where the repair is identified as "temporary" or
not. A temporary repair is most often done to get the operation
through the shift, and subsequently a relatively permanent
repair is completed at a more convenient time.
For each repair, an assessment should be provided by the
mechanic. This comment may indicate the repair was temporary,
and if so, it should be followed by a recommendation indicating
what needs to be done to make it more permanent.
Last, and not least, is some type of repair cause code. The
reason a code is used instead of a description is to begin
to categorize the repairs for easier analysis. Once statistical
analysis is completed, the more significant individual items
can be further analyzed by review and evaluation of their details.
Codes in the CMMS represent a great potential advantage for
accelerating recording of repairs, as well as their analysis,
but can be extremely dangerous if overused. There should not
be so many code fields, and/or codes per field, that it requires
a separate page to list the possibilities, and someone must
read through them for each repair.
For example, a CMMS may contain fields for problem, failure,
cause, root cause, solution, or action verb/noun combinations,
etc. For each field, there may be 40 or 50 possibilities, and
probably more. This just makes it take longer to complete the
work order and often leads to more specific codes being added,
thus making the recording process even more complicated.
An important aspect to documenting work is simplifying the
process. Use codes that are broad in nature, and relevant to
the process environment wherever possible. An invaluable source
of these codes is a review of historical activities that probably
exist on manual records. Causes can be derived from work descriptions
entered even if they are only to categorize parts problems
from electrical, leaks, adjustments, etc.
Multi-line work order
The basic work order example is considered the workhorse
for capturing planned and unplanned work, and provides areas
to document extensions when the work is carried over for virtually
any reason (scheduling, availability of materials, etc.).
A multi-line work order that mechanics would have at the
beginning of their shift is typically used to capture work
that is often unplanned and would be completed during the shift.
Items carried over are typically referenced from here and transferred
to the basic work order form for future execution.
The better and more consistently recording of repair activities
is done, the greater potential for yielding greater and more
specific information about the operation, in both qualitative
and quantitative terms. The more quickly this can be done,
the sooner actual activities will be reported into the CMMS,
and a useful history will be built that can be more easily
analyzed through statistical methods.
WORK ORDER DATA FIELDS
- Machine
- Problem description
- Emergency flag (Yes/No)
- Skill/trade
- Work (done) description
- Parts requested
- Wrench or work time
- Action codes (problem, cause, downtime,
failure mode, solution, reason not done, etc.)
- Downtime
- Repair assessment (i.e., temporary?)
- Originator. requester
- Job number
- Budget/actual cost
- Multiple authorizations
- Job status
- Parts/material usage
- Project number
- Safety/special requirements (JSA, scaffold,
formed pit, etc.)
- Permits (hot work, confined space entry,
etc.)
|