9.5 Root Cause Analysis - Ishikawa Diagrams

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

9 hours 3 minutes
Video Transcription
Hi, guys. Welcome to analyze phase root cause analysis. Ishikawa or fish Bone diagrams. I'm Catherine MacGyver. And today you're going to get an awareness of how a fishbone diagram is used for root cause analysis.
So if you remember from her previous module are five wise, we were looking at different ways that we can tease out the underlying cause when we see symptoms within our processes.
So a fishbone diagram is called a fishbone diagram
because it looks like a fish.
I'm gonna go with you guys. I'm creative liberty because I have never really quite seen it. But I'm told that this is what a fish looks like If you were to look at a fish so I tend to call them issue kala diagrams because Dr Issue cow was actually the man who designed this tool and put it into circulation
for us as a quality tool. Soon, Dr Ishikawa was
during that same era of Dr Duran and Dr Demi. But
fishbone diagram so ah, couple of things that are really helpful about fishbone diagrams is they have set categories. So you have the five m's and an e that are related to your problems. So the categories for official diagram our material,
which is going to be your suppliers, your raw materials machine. So anything that you have an instrument or a machine for,
man, that's gonna be your human element. Measurement is actually a new one. That's very interesting for us, because the question is now is it really a problem? Or is the problem because of the way that we measure it, environmental
and then method, which is the actually how we do our process. So the way that you do a fishbone diagram is you have a blank template such as this one here,
um, and you have your brain storming or your process group with your sneeze, go through each of these categories to come up with what could be causes for the problem, as from the problem statement on your charter that are related to these categories.
So, for example, if we were talking about
the problem statement from our charter about, um, the complaints, the complaints from our orders on our weekend shifts at our flagship stop store, we would say that there's probably not any material,
I'll reason. But there may be a machine reason we might not be entering our orders correctly. Man tends to be the default. We like to just throw everything and there is a human error. This is really ought to be very
judiciously used. So, like your business, non value. Add when you're defining value. You don't want to just say everything is human error eso another way that when when we're looking back at my flagship pizza problem is measurement. Maybe. How we're measuring client satisfaction is where the actual cause of the problem is
Maybe there's something that's going on like the temperature is too high or the temperature is too low. Or maybe there's humidity, which is causing some weird technical glitch. And it's saying pepperoni pizza when I order cheese pizza. These are all sorts of things that you want to tease out.
You're probably going to see a lot in method, which for the pizza example, which is how we actually do the work, What are those activities and tests?
That's our process. So
to do a fishbone, get your group together. Um, not going to be a stand up huddle like you could do for the five Wise and brainstorm through with these categories
Once you are done with these categories, you're then going to want to prioritize the items within the category so you can do this in a couple of different ways. You can vote on this idea of multi voting will show up in Greenbelt on how do we determine magnitude of problems?
You can just count the number of ideas. So if it's you and me and another person, and we all say that under the machine category, there's something tricky in the cash register that's going to be three towards cash register, you want to use
these categories that you identify as inputs into your hypothesis development. So when we talk about root cause, really trying to get down to your exes,
these air where you're going to tease out the exes so that you can move into not this next module, the module after, which is about hypothesis development, which will help give us a baseline for proposing and testing our solutions.
So when we think about Fishburne diagram, these are best for manufacturing. So any of those material processes and the reason wise, if you think about it in a transactional environment,
environments probably not gonna matter a machine may or may not because you can make an argument about business applications. Measurement
may or may not. But really, the categories don't necessarily align with quite a few of our industry working environments now, which is why this is a second tray, so five wise is still the first choice. Fishbone diagrams are considered the second choice, and this doesn't get to the level of
depth and specificity that you will see in a five. Why? Because really, you're looking at superficial ideas and not going
deeper into what could be causing that next level. So that's a fishbone diagram. Our next module up is going to be the last of the root cause. Analysis tools were going to be going over affinity diagrams.
Up Next