Drew Soignier is Vice President of Product Development for Uptake with 20+ years of experience in sales, marketing, and product management. Robert J. Latino is CEO of Reliability Center, Inc. and has been facilitating RCA & FMEA analyses with his clientele around the world for over 36 years. Sebastian Traeger is the Managing Director of Reliability Center, Inc. and brings a background in technology, business and executive leadership to RCI. During the Q&A portion of the webinar, “Time for Change! The Digital Revolution in Reliability and Maintenance" the three men discussed how root cause analysis software can be integrated into current systems and programs.
PS: How much time does it take to get started with EasyRCA?
ST: It does not take long at all to get started. I think the most complicated part would be scheduling a call with Drew and I to think through how it can work best with your organization. But from an implementation perspective, we put it together, we try to make everything easy with EasyRCA. And included in that is the onboarding.
We have a 30-day plan to get your entire team onboarded, complete with online and in-person training. We even set aside what we call an RCA guru to coach you through your first RCAs. From go to being proficient in the system, we'd say it's no more than 30 days and often a lot faster than that.
PS: Some of the operator and maintenance technician notes in our EAM work orders are wildly inconsistent. They have misspellings and abbreviations. Can you get at this work order data, and if so, is it of any value?
DS: The answer to that is yes. We have a couple of different techniques, especially leveraging natural language processing and data science to go after extracting that data from not only the transactions and the work orders themselves, but also the notes and the other information that may come from the EAM, CMMS, or any of its supporting systems.
PS: How are you seeing people use or leverage the EasyRCA templates in the field? Can you give some examples of that?
BL: The templates are really external experiences. The danger always is that when you have templates, people will just use those and they don't use the knowledge of their team. When you're in a team, and this is just my personal opinion, you should exhaust the knowledge of the team first and then act on the templates to see an external thing that you may not have learned about.
I think it was Eli Goldratt who wrote "The Goal." He says, an expert is not somebody who gives you the right answer. It's somebody who asks you the right questions. If you're given the answer, then you haven't really learned the derivation of where it came from. You can end up with templates just being a pick list, as opposed to thinking about it. I want to be able to have a starting point. I think that that's what the templates bring to the table.
ST: I think there are just three use cases of templates. Number one use case of a template is, “I'm new at doing RCAs and I feel overwhelmed. I don't actually know how to walk through the logic.” A template can be a great show-and-tell. I can look at something and suddenly it's demystified a little bit.
I think also, as Bob mentioned, it's that knowledge share. You want to make sure all that information is collected. And then, third, if you've got a similar problem happening on a repeated basis, you want to make sure that you have the ability to just very quickly put in the data that you've already seen and then see where it might be the same or it might be different from a past situation.
BL: When you're looking at the Baby Boomers coming through, and this is a pet peeve of mine, we're not collecting how those people solved problems. They're retiring, and everything about their skill sets, about how they solve stuff, is going with them. This is the type of system that can capture that knowledge down to the cause-and-effect relationships and the reasoning of how they did it. From a corporate institutional knowledge standpoint, it's extremely important to get what those people know before they go.
PS: If I already have RCM software, why would I also need RCA software?
BL: The purpose and intent of RCM is proactive, in that I'm designing a customized, predictive, preventive system to be able to capture failure quicker so that I don't have catastrophes.
When you're looking at RCA, of all the risks identified in RCM, one of them has materialized. And now we have to understand the details about how that failure came to be. We had all of these systems in place, so how did it slip through the systems that we have?
RCM tends to deal with the physical science side of failure, and then we put in the preventive and predictive stuff. But when you're getting into RCA, at least holistic RCA the way that I see it, the physics of the failure is just the beginning. It’s the meat of understanding how things went wrong.