We all have the image in our heads of what a reliability engineer does right?
They perform criticality analyses, set off reliability programs such as RCM, provide a mentoring hand with technicians and other people within the company, and they analyse issues that are brought to them by management. (Often they also seem to get sidelined into data management issues)
We all know this, most of us practice it. The problem is that it is almost entirely ineffectual.
What I have seen so many times is the reliability engineer, or the entire reliability department, walled off from the rest of the organization providing leadership from an ivory tower. They start to get far too focused on critical assets - and this moves them even farther away from operations.
My view of reliability engineers is totally different.
Should they have a separate department? I think there are strong cases for it a lot of the time. Particularly where there is a need to establish a consistent approach across the organization.
But not always. Not if your company is relatively small, or if your approach to reliability is nascent.
Regardless of where they sit their roles should include part of the above - but they also need to be operationally focused.
The best structures I have seen with Reliability engineers is when they are joined at the hip with the maintenance planners.
The planner informs them of the issues, the RE then analyses, discusses with others, resolves the issues and then works with the planner to get the solutions into day to day operations.
I wrote some pretty intense role descriptions for this role a while ago - and it was a pretty new view at the time. Some of the main points are below. (A function not a role, there are not many people I know who can adequately do all of the below.)
1. Daily liaison with planners and schedulers to uncover problems, plan implementation of solutions and touch base about near term plans and performance requirements.
2. Drive the RCM/PM strategy program through knowledge transfer, mentoring, auditing, and work flow measurement. (Huge call for metrics here)
3. Tell the story of the achievements to date. And tell it regularly - to anybody who will listen. RE's are not just doers - they are agents for change. (Bit thats another post)
4. Facilitate RCA studies as required, provide the base for knowledge transfer related to causal mapping and other problem resolution techniques.
5. Long term planning for asset refurbishment and replacement.
6. Studying data to determine where the issues lie in present performance. (Do not get caught up in the differences between maintenance and reliability engineering. Again - another post)
With a focus like this. RE's are able to be part of the team making the money, instead of seen as one of the overheads costing money. They will also get a focus not only on critical assets, which is important, but also on how to generate short and medium term cashable results.
And that generates acceptance, respect, a position as a trusted advisor and the ability to get stuff done.
The most common complaint of reliability engineers? The work doesn't get implemented.
The most common complaint of their "customers" in operations? Great documents and reports - but nothing ever happens!
The observation of "nothing ever happens", is a product of not fostering a collaborative environment and giving the end users and major stakeholders and opportunity to have a say in the development of often complicated, failure laden initiatives.
ReplyDeleteI have often, and successfully started most effort in a manufacturing setting by first having an audience with the operations operators and maintenance groups by soliciting their input and building and fleshing out the initiative/plan around their provided value added suggestions in a spirit of partnership.
With everyone having skin/interest in the game, one would be suprise at the level of cooperation that is achieved.
In addition to the roles described above, I would like to mention that 'RE' should also closely interact with the design team. This will lead to proactive reliability models rather than reactive reliability models.
ReplyDelete- Balaji Kannan
Hi Madhu,
ReplyDeleteI agree fully. WHen it is possible to create links with the design engineering people that can only benefit.
However the thrust of the post was to make sure that the impacts of our work are visible to the people who decide where to spend capital.
If we continue to work on invisible and intangible areas such as risk mitigation then our case starts to sound like "we haven't had a terrorist attack since 9/11" and it all becomes invisible effort.
If we want support, and we all need management support, then we need to have a visible impact in areas that they pay close attention to.
Daryl...
I certainly agree with connotation of these thoughts also.
ReplyDeleteWe have "Reliability Engineers" imbedded in our centralized maintenance department with our planners... they are in continuous contact with production coordinators... and they are directly supervising a small group of specialists (3-6) in their respective areas.
What this effectively means to us... is that as the RE is expected to put together a formal report identifying the path forward and gain mutual agreement from all on the correct path forward... and he has a small team of specialists to execute this plan and handle all the day to day things that come up along the way.
It is refreshing to see some comments from others about the value of having the RE's directly involved. From our perspectives, we think this adds much more value to our plant.
Hi Daryl,
ReplyDeleteI certainly agree with your post and the comments above.
The only thing that might be in addition to your list is the "ability to speak to (and therefore influence) senior management in their language" ie dollars and cents.
Your point (3) implies this - but if their audience is technical - they are (as you have said previously) preaching to the converted.
In my opinion the reliability engineer needs to describe his activities and achievements in financial terms.
For what it is worth, six sigma training (well, certainly the training I completed) helps with this aspect.
"Six sigma and reliability engineering" is probably worth a blog post on its own!