Bluefield is regularly asked by clients to undertake defect elimination projects (see our case studies here and here). We’ve learned that it’s vitally important to be able to classify and analyse failures by aligning them to failure modes. To do this requires not only the consequence and cause, but to zero in on the specific part that’s failed, and in our experience this information is rarely available.
If you don’t have the ability to tie a failure code to a specific part on an asset, your reliability engineers will have a major data analysis task in front of them. You can increase their efficiency by implementing a master data structure that facilitates faster analysis.
At some sites, the master data structure is a variation of this:
>> Fleet type
When reliability engineers interrogate the CMMS to eliminate defects, they might drill down by cost, work order frequency, repair labour or machine downtime.
If your master data is like the structure above, the drill down probably stops at the minor system. Your reliability engineer might have hundreds of work orders in this “bucket”. According to their drill down, it might be the biggest impact on this asset class, and therefore deserves further attention.
But what do they do now?
What if, for example, your minor system is just a bucket called “hydraulic system”? How many components and failure modes might be contained within that bucket?
Your reliability engineer must now spend countless hours reviewing each work order in the bucket to further classify the failure. They might have to develop their own coding system to help drill down on the problematic components and failure modes.
This time impost on your team severely limits their effectiveness. Instead of investigating and eliminating one problem per day, they might be down to eliminating one problem per week.
What if the master data structure facilitated faster analysis? What if you implemented a structure more like:
>> Fleet type
>>>>>>>>Part (even better if it extends to this level)
Yes, of course it's more work to implement up front, but what are the benefits?
Firstly, your reliability engineers can now quickly drill down to the part contributing to the issue. The time spent quarantining hundreds of work orders reduces to a handful to confirm the failure mode under investigation.
Secondly, your reliability engineers can now have an informed discussion with your OEMs, sharing part level detail and ensuring the OEM’s continuous improvement program incorporates the field problems you are experiencing.
There is even more value if your work order close-out process retains and analyses failed parts, and assigns damage codes to the failure mode recorded. This adds another level of detail to the reliability engineer’s analysis. Consider how powerful your discussion with OEM’s would be if you said “we have twenty failures of this bracket due to cracking at an average life of 5200 hours”. Repeat this process five times per week and your scheduled OEM meeting suddenly becomes highly focussed on data-driven defect elimination.
Implementing a master data structure to the minor system level doesn’t have to be painful. You don’t have to reinvent any wheels. There is a very simple way to speed it up.
Go ask your OEMs.
What data structure do they use? Is it published in the public domain? Is the coding structure shown in the equipment parts books? Can you implement one OEM’s existing structure across your fleet?
Your master data structure greatly impacts the efficiency of your reliability engineering program. Give your team the best chance for success. Look at your data structure. Can you improve asset and business performance by improving your master data structure?