The Frustrations of Reliability: From Strategy to Synergy with Bob Latino and Ken Latino
Welcome Bob and Ken Latino to the Podcast. Bob has been to this Podcast before discussing defect elimination and is an author involved with RCA and other reliability items. Briefly, Ken, can you introduce yourself.
I worked with Bob and my other brother at our family businesses called Reliability Centre for about 15 years. I later left for a small start up called Meridian being involved in reliability softwares. I also worked as a reliability manager at a Paper Mill for 10 years then went to GE. Presently doing consulting work Prelical.
In this episode we covered:
- There is a lot of frustration in reliability. Where do you see it comin from?
- What do you think reliability means to any plant manager or operations manager out there?
- How do we break this cycle of frustrations?
There is a lot of frustration in reliability. Where do you see it comin from?
Everybody in the industry wants reliability but a lot of people do not understand what it takes to move from a reactive culture to being proactive.
When reliability is successful nothing happens in terms of breakdowns hence it is difficult to recognize the efforts of the department.
It doesn’t matter which industry it is. It has always been about organisational culture.
It comes down to the decision making skills of the workforce. If you give the team bad tools they will make bad decisions. With good tools they will make good decisions. Every outcome stems from someone triggering it or taking inappropriate action.
Sometimes you set up RCM and after a month of practice it fails. We have to ask if we communicated the right expectations upfront; what it takes and how long it takes to get the results, the right culture.
I do not blame as much the people that do bad RCAs as much as the people that accept them because they are condoning it. The people in charge are considering the practices as routines to just get the minimum requirements.
Is the level of frustration similar for both the tradesman in maintenance and those in management?
It’s a different frustration for the line worker because they communicate potential points of breakdowns before they happen with no response from upper management. I believe the management hardly understands because they believe they have people for all departments who are supposed to respond to failures.
Earlier in the 1970s reliability was not being practised because so many people were focused on fixing failures and no resources were left for preventing them. Reliability was being considered subordinate to maintenance and that is one of the frustrations.
The job descriptions of those intended to support reliability maintenance such as planners are not clear even to superior staff. It becomes frustrating because they are meant to work for the same organisation.
Organisations adopted the idea of reliability by merely changing the title from Maintenance Engineer to Reliability Engineer without actually changing the function. This brings failure to the execution of reliability.
What is reliability?
It is the equipment, process, and human reliability with an emphasis on the human reliability side. Having the greatest tools does not help if you do not have the right mindsets to prevent failures. It is similar to safety when you communicate that you want zero harm and so people fail to report injuries to not mess the metric.
What do you think reliability means to any plant manager or operations manager out there?
They would say, “my equipment doesn’t fail.”
Is it realistic?
No.
Most managers measure reliability by MTBF.
It is a terrible metric. It is important to trend it but it is not proper to make decisions solely on it.
The frustration then comes from the way we measure reliability. Managers assume that we will not have failures. Failures will still occur but it is a matter of how often. Are we eliminating certain types of failures?
From an FMEA curve standpoint people may start reporting the small issues rather than the more severe ones. You find that you are tracking it at risk level rather than at the consequence level.
Often people do not even know what failures are, much less what reliability is.
While working at the hospital, people rated fall with harm and without harm differently enough to not treat them with the same seriousness. The conditions for fall still existed but we didn’t have the right drivers to help us assess the near misses.
You have to have a certain group looking at potential breakdowns as you have others focused on the present ones.
How do we start reducing these frustrations?
Pick the smaller subgroups of equipment. Pick the critical equipment and apply the reliability principles. Having the subgroups brings success to build on. You also have to tell people what you are doing to make your successes visible.
You have to pick small areas to work on and communicate the right expectations upfront.
You have to be consistent in your reliability practices because it is very easy to fail if you are not. A lot of frustrations also stem from high turnover rates that prevents consistency. The remaining people do not have the right systems to sustain reliability.
You have to have the right systems that support skill transfer such as refresher training, and processes to institutionalise the practices rather than base it on one champion.
For a tool like RCA, you have to ensure that the newcomers understand perceptions from the more experienced team members on how systems work and people think. Otherwise they will slip back to their reactive culture.
How do we break this cycle of frustrations?
- Start small
- Build on success
- Educate
- Teach people how to make a proper business case.
There are several easy wins in highly reactive environments that can be pursued.
Find the best way to communicate what you do and your achievements. Reliability engineers can take sales and marketing courses.
- Show your people that they have value by listening to them.
- Proactively utilise RCA even without a breakdown to eliminate defects that hinder great performance
Why arent many reliability people not doing these things?
The first question they need to ask is on practicality. Ask the people if the initiative is practical.
Eruditio Links:
Bob Latino and Ken Latino Links:
- Bob Latino LinkedIn
- Ken Latino LinkedIn
- Prelical.com
- Root Cause Analysis: Improving Performance for Bottom-Line Results, Fifth Edition 5th Edition
Rooted In Reliability podcast is a proud member of Reliability.fm network. We encourage you to please rate and review this podcast on iTunes and Stitcher. It ensures the podcast stays relevant and is easy to find by like-minded professionals. It is only with your ratings and reviews that the Rooted In Reliability podcast can continue to grow. Thank you for providing the small but critical support for the Rooted In Reliability podcast!
Thx for publishing Fred, and to James as well for providing Ken and I the opportunity to express our perspectives.
We hope they are of value to your followers, and as always we’re open to any questions from anyone.
thanks for sharing these excellent views and perspectives! I’d like to make a quick comment. I may be wrong. feel free to correct me if needed.
one argument says, “Organisations adopted the idea of reliability by merely changing the title from Maintenance Engineer to Reliability Engineer without actually changing the function. This brings failure to the execution of reliability.”
my understanding is that, in theory, maintenance brings no changes to reliability. reliability performance of systems do degrade with time, or it doesn’t even meet requirements in the first place. a maintenance engineer should be able to do nothing about it. it is the role of a reliability engineer to identify issues, assess problems, and then lead to appropriate action items.
a maintenance engineer may share with a reliability engineer in functions of issue identification and corrective/mitigation/preventive actions. however, reliability assessment, quantitatively in particular, is no function of maintenance. it’s a key value of reliability engineers.