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. And there is a chance that the loading of failure codes may never happen. If it does happen, it could be years later. This delayed setup is a lost opportunity meaning the failure history was never properly recorded in validated fields — and likely never to be recovered.
Consequence: Without actionable failure data it is impossible to perform failure analysis 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:
- Find a reliability leader versed in EAM functionality. Get him/her involved in the EAM implementation/upgrade, or, post go-live. The software roll-out by itself does not deliver reliability.
- Clearly identify the end-game for reliability excellence, and from that, a long range plan. This should be converted to a resource-leveled schedule containing all business improvement initiatives as related to asset management. The EAM schedule is separate document.
- 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.
- 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. 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 additional effort will be required to recover this data by reviewing actions performed (in text fields)….which could take months.
- The asset stakeholders (asset managers, maintenance managers, reliability engineer, planner/scheduler, HSE manager) should become CRL, CMRP 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.
- Be sure you are clear on the language of RCM which is “failure mode”. This is defined in 3 pieces: failed component, component problem and cause code.
- 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?”.
- 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.
- 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.
- Use multi-dimensional approach to “closing the loop”, such as RCA, chronic failure analysis, defect elimination, and work order feedback. This holistic approach supports continuous refinement of tactics which, in turn, enhances reliability.
Note: Any organization that postpones activating failure codes and capturing the failure mode will most likely be operating in reactive mode, at higher risk, and, at a higher O&M cost due to their lack of formal failure analysis.
There is a book on this subject which provides a detailed explanation of how to implement this design: Failure Modes to Failure Codes.
-John Reeve, Author, CRL, CMMS Champion