Why do organizations implementing EAM always put failure codes in last phase?

 Publicado el 22 de agosto de 2018

John Reeve

Perhaps the mindset is to put the hard stuff off until later. Or worse yet, maybe there is
a general lack of knowledge surrounding this subject and best practice. There is a chance
that this -- loading of failure codes -- may never happen. If/when it does happen, it could
be years later. This “lost moment in time” is lost failure data never to be
recovered. Although it is possible to read through long descriptions (hoping that
technician entered meaningful text) that process could take 1-3 man-months to
retrofit. Consequence: Without actionable failure data it is impossible to extract Pareto
style analytic using failure analytics.

How can this outcome be avoided? Answer: Recognize that this is a complex process,
meaning a combined effort involving software/data, process/procedure and
roles/responsibilities. Consider the following 10 points:

1. Find a reliability leader versed in EAM functionality. The software go-live by itself
does not deliver reliability.
2. Clearly identify the end-game, and from that, a long range plan. This should be
converted to a resource-leveled schedule containing numerous business
improvement initiatives as related to asset management. The EAM schedule is
separate document.
3. Consider new gatekeeper role to validate work order imitation data accuracy, and,
use this same role on back-end where actuals and failure codes are
entered. Precision reporting requires precision data.
4. Another best practice would be to create a mock-up of a failure analytic at least
on paper early on, and then identify input requirements. This should be done
 early-on in the implementation. At least you would know what input fields are
missing, what processes need to be written, and what roles need to be clarified. If
you don’t know where you are going, then a rework situation will likely be
encountered whereby codes are gleaned from text (containing actions
performed)..
5. The asset stakeholders (asset managers, maintenance managers, reliability
engineer, planner/scheduler, HSE manager) should become CRL accredited for
building an asset management system with emphasis on reliability, such as
offered by ReliabilityWeb. It’s hard to communicate without a common language.
6. Be sure you are clear on the language of RCM which is “failure mode”. Be sure you
are capturing these 3 pieces: failed component, component problem and cause
code.
7. Be careful not to build a monster in terms of failure code structures. The end result
could be too onerous to maintain/update as failure coding design never really
ends. Perform usability tests, such as, “will the working level be able to
intelligently click their way to the right answer?”.
8. Seek a “middle ground” design. It’s just not possible to perform root cause analysis
(RCA) on every breakdown. On the other hand, it’s not very useful to say
Mechanical problem, Electrical problem, or Other. Talk with the Reliability
Engineer and find out what his needs are if he plans to ever extract meaningful
information from the EAM. And most importantly, talk with the maintenance
supervisors, and working level, to make sure they are comfortable providing this
level of detail.
9. Get a Reliability Team in place. Train them to run the failure analytic and use this
data to perform chronic failure analysis. Conduct monthly meetings; manage by
exception.
10. Use multi-dimensional approach to “closing the loop”, such as RCA, chronic failure
analysis, defect elimination, and work order feedback. These actions support
continuous refinement of the maintenance tactics support best-in-class reliability.