Wow! Been in manufacturing for 25 years an this is the best and uncomplicated video for root cause I've ever seen! Great job at explaining and defining the process!!! 👏👏👏
Thanks for sharing this video! Solving the root cause problem it's indeed the only way to prevent recurrence! It applies not only in business but on day to day life too!
"When?" also includes the LATER issue, "When did the problem happen?" and "Where?" includes the LATER issue of "Where did the problem occur?" BTW, I'm in the UK, but I always use the Washington Monument example when training 5Y.
"Preventive Action" is NOT the same as a tough Corrective Action. It typically comes from risk analysis or FMEA, and implements action to prevent a problem from ever occurring in the first place. Then you have "Correction" (the knee-jerk inspection/repair kludge) and "Permanent" (the systematic resolution of this kind of problem on this kind of process, or similar processes).
Thanks Brion for a very informative video, I have a question about the process time duration, How long should the team run RCA (or 8D) to make the entire process efficient?
Hi Rex, just seeing your comment. If you're asking about how long it takes to complete an 8D, then I would say it depends on the complexity of the problem, and how much time the team commits to the 8D. It can take as short as a couple days, or as long as 6-9 months, and even in some cases, longer than a year. Is that the question you had?
Rex The major problem is where people try to solve the entire issue in a single session without straying from the meeting room. They make educated guesses with 5Y and/or Ishikawa fishbone, but then never go out and visit the processes to verify their RCA. I call this crystal-ball RCA. Now a line inspection may reveal the issue. When I was quality manager of a UK company that owned a Chinese factory, there was an issue that should never, ever have escaped to the customer in the first place, because it could never have passed final test. The Chinese company were all ready to fire the tester, but I urged for more patience. I watched her for a day, and got a QC technician watch her during the night shift. Then I watched her the next day, and then it happened. She was looking into a piece of equipment with a visual hood. I saw that the testing had to be repeated due to an error due to poor contact... and while she was doing that, another unit slipped past on the conveyor belt, unseen and untested. I asked the Production Manager if he could slow the line down... you can guess his response. So I looked at the maximum time taken under all possible circumstances for a retest after a fail (any more than one retest was put aside for re-inspection) this was done by an interview with the inspector, who took me through the process, and we role-played it. So somehow, I had to slow the line down at one end while keeping the main line speed the same. I tried three tie-wraps loosely around the end of the line. It made the units "bobble" a bit before moving past the end-of-line inspection station. However, after a quick simulation and review, this would sometimes mean that one unit would bang into another on the line, and this was not good. One tie-wrap was not sufficient. So two tie-wraps it was. All I had to do was add an instruction to the work procedure was for the inspector to check the condition of the tie-wraps at the end of the shift and replace them if necessary. We videoed the operator for several weeks, and checked on fast-forward. The units got close together, but never collided, and the operator never missed a unit. The problem did not recur. That 8D took us about two months. I would say that was a good average. But a really complex 8D with a very technical product... the sky is the limit. In aerospace and defence, it could be six months to eighteen months.
Hello Brian, I have a question about the definition about the core of the problem to work. Normally the leadership and manager have some idea about where that accident come from and they trying to transfer the problem to other department . How to convince them to be impartial on it?
The department experiencing the problem should own and kickoff the project or investigation. They should invite the department they think is causing it, but not try to pass off the problem to them. I've seen that happen a lot, and if the other department doesn't think they caused it, then nothing happens, and the problem keeps recurring. If they realize that it will keep happening If you can help the manager and leadership consider how other departments or suppliers could have caused the issue, that seems to work well, and they'll be more interested in withholding judgment. Over time, they will start to understand through experience that their initial thoughts are not always correct, and they should let the data and process speak for themselves. Does that help?
I do understand what you have explained and agree with it. The idea is great and honestly I have never thought about that perspective. As they are the team where the problems,in general, happens certainly they will be more 'flexible' when there are a small chance to input the origin of the problem is at other hands... but when the process begins they will see where the problems are: Communication's failure! Thank you.
Wt? No!!! Difference is, SixSigma is a Methodology Approach to Determine Statistical Processes Capability. Lean also uses a Methodology Approach to eliminate Waste Within Your Organization.
Both Lean and Six Sigma utilize root cause analysis techniques. Six Sigma uses process capability analysis, but it's not always used in a DMAIC project, only when there is continuous data and defined customer specifications. If not, Six Sigma can still be used to reduce variation, errors or process time. Is there something in the training that compared Lean and Six Sigma related to your comment?
Wouldn't be the most interesting question why the engineering team didn't had the manufacturing process in mind up front? Without answering this question you can only solve the immediate problem, but not future ones. Could be just a mistake, then that's fine, but could also be that there is no communication/feedback process or information/people sharing between engineering and manufacturing. Or that there weren't appropriate testing procedures.Or that information was missing because of illness and people didn't shared knowledge enough before the illness (truck score bad). Or something completely else. It's a bit funny that this happens exactly when in the example there are less than 5 whys asked. (Isn't it the main principle?)
Yes, you can go even deeper into the questioning. I typically stop when we get outside of an area of control (getting into other departments or outside of the company). Some questions don't need 5 why's, some problems require more than 5, so it depends on the complexity of the problem statement.
All credibility is diminished by using that old urban myth about the Washington monument. Do your research. This NEVER happened. Also, Whys does not have an apostrophe, so an F for punctuation as well.
To convey a concept like 5 Why's, although not 100% accurate to the true story, it does a good job, so I will continue to use it. Here is an article about some of the differences from the real story, with links to actual newspaper articles that it did happen. thekaizone.com/2014/08/5-whys-folklore-the-truth-behind-a-monumental-mystery/ Here is another article I found in 2 minutes of research, that talks about the same problem: www.newspapers.com/article/the-miami-herald-lincoln-and-jefferson-m/140061415/ I'll give you an F for your research skills and your attitude
Easy to understand and I truly enjoy your clear voice with no background music. Thank you!
Thank you for the kind words
Wow! Been in manufacturing for 25 years an this is the best and uncomplicated video for root cause I've ever seen! Great job at explaining and defining the process!!! 👏👏👏
Wow, thanks for the kind words!
This was very concise and informative. I was instantly able to apply what you taught to a current project!
Thank you so much, that was my hope in uploading this video!
Hi Brion, just want to say thanks so much for sharing this webinar video! Really helps me and my team in doing the RCA!
Thanks for the kind words. Glad it was helpful!
It is great improvement EHS course helps to do accident investigation with effectiveness
Thanks for sharing this video! Solving the root cause problem it's indeed the only way to prevent recurrence! It applies not only in business but on day to day life too!
Root cause analysis is often biased and flawed. So without the base, the temple which is built upon is a hoax.
Great teaching there
Thank you!
Hi,Brion. Great video! Thank you for sharing the course video, it's really help me in doing the RSA.
Thanks for watching!
Thank you. I will share this video to my team for review of RCA topic.
I love consulting subject yeah
Great Video! I learned a lot, thanks for posting.
This is a very useful video - thanks
Glad it was helpful, thank you!
Great material mate!
Very good video. Thanks for sharing!
Very helpful and informative video. Kudos to the great work and efforts you poured...Thank you !!!
Thank you, glad you enjoyed!
Great ovrview, thanks for posting this!
Thanks Brion!
"When?" also includes the LATER issue, "When did the problem happen?" and "Where?" includes the LATER issue of "Where did the problem occur?"
BTW, I'm in the UK, but I always use the Washington Monument example when training 5Y.
VERY GOOD
Great Video; Good examples.
Great overview!
"Preventive Action" is NOT the same as a tough Corrective Action. It typically comes from risk analysis or FMEA, and implements action to prevent a problem from ever occurring in the first place. Then you have "Correction" (the knee-jerk inspection/repair kludge) and "Permanent" (the systematic resolution of this kind of problem on this kind of process, or similar processes).
I'm in the nuclear power business, our terminology is the same as yours.
Much prefer your definitions
Wonderful!
Thanks for sharing very informative for school assignments and work assignments.
Good job
Thanks Brion for a very informative video, I have a question about the process time duration, How long should the team run RCA (or 8D) to make the entire process efficient?
Hi Rex, just seeing your comment. If you're asking about how long it takes to complete an 8D, then I would say it depends on the complexity of the problem, and how much time the team commits to the 8D. It can take as short as a couple days, or as long as 6-9 months, and even in some cases, longer than a year. Is that the question you had?
Rex The major problem is where people try to solve the entire issue in a single session without straying from the meeting room. They make educated guesses with 5Y and/or Ishikawa fishbone, but then never go out and visit the processes to verify their RCA. I call this crystal-ball RCA.
Now a line inspection may reveal the issue. When I was quality manager of a UK company that owned a Chinese factory, there was an issue that should never, ever have escaped to the customer in the first place, because it could never have passed final test.
The Chinese company were all ready to fire the tester, but I urged for more patience. I watched her for a day, and got a QC technician watch her during the night shift. Then I watched her the next day, and then it happened. She was looking into a piece of equipment with a visual hood. I saw that the testing had to be repeated due to an error due to poor contact... and while she was doing that, another unit slipped past on the conveyor belt, unseen and untested.
I asked the Production Manager if he could slow the line down... you can guess his response. So I looked at the maximum time taken under all possible circumstances for a retest after a fail (any more than one retest was put aside for re-inspection) this was done by an interview with the inspector, who took me through the process, and we role-played it. So somehow, I had to slow the line down at one end while keeping the main line speed the same.
I tried three tie-wraps loosely around the end of the line. It made the units "bobble" a bit before moving past the end-of-line inspection station. However, after a quick simulation and review, this would sometimes mean that one unit would bang into another on the line, and this was not good. One tie-wrap was not sufficient. So two tie-wraps it was. All I had to do was add an instruction to the work procedure was for the inspector to check the condition of the tie-wraps at the end of the shift and replace them if necessary. We videoed the operator for several weeks, and checked on fast-forward. The units got close together, but never collided, and the operator never missed a unit. The problem did not recur.
That 8D took us about two months. I would say that was a good average. But a really complex 8D with a very technical product... the sky is the limit. In aerospace and defence, it could be six months to eighteen months.
@@Dragonblaster1perfect clarification on the query...
I have a small question. department didn't complete their project on time can u tell me who will be the Competitors this. its ll be useful for me
I'm not sure if I understand the question. You're asking about the 2nd example, correct? Not sure what the "competitors" you are referring to...
my question how to view in this prblm the competitors ?@@brionhurley
you're just reading the slides , what a great video !!!
Thank you for sharing this sir. Is any file that we can get by mail?🙏🙏🙏
You can access a watermark version of the slides here: www.biz-pi.com/product/root-cause-analysis-course/
Hello Brian, I have a question about the definition about the core of the problem to work. Normally the leadership and manager have some idea about where that accident come from and they trying to transfer the problem to other department . How to convince them to be impartial on it?
The department experiencing the problem should own and kickoff the project or investigation. They should invite the department they think is causing it, but not try to pass off the problem to them. I've seen that happen a lot, and if the other department doesn't think they caused it, then nothing happens, and the problem keeps recurring. If they realize that it will keep happening
If you can help the manager and leadership consider how other departments or suppliers could have caused the issue, that seems to work well, and they'll be more interested in withholding judgment.
Over time, they will start to understand through experience that their initial thoughts are not always correct, and they should let the data and process speak for themselves. Does that help?
I do understand what you have explained and agree with it. The idea is great and honestly I have never thought about that perspective. As they are the team where the problems,in general, happens certainly they will be more 'flexible' when there are a small chance to input the origin of the problem is at other hands... but when the process begins they will see where the problems are: Communication's failure!
Thank you.
Thank you so much
Wt? No!!! Difference is,
SixSigma is a Methodology Approach to Determine Statistical Processes Capability. Lean also uses a Methodology Approach to eliminate Waste Within Your Organization.
Both Lean and Six Sigma utilize root cause analysis techniques. Six Sigma uses process capability analysis, but it's not always used in a DMAIC project, only when there is continuous data and defined customer specifications. If not, Six Sigma can still be used to reduce variation, errors or process time.
Is there something in the training that compared Lean and Six Sigma related to your comment?
hello can i have this as my basis for my report
Can you elaborate? What would you like to have? You are free to reference it or link to it if that's what you mean
Thanks sir
Thank u.
thanks
Wouldn't be the most interesting question why the engineering team didn't had the manufacturing process in mind up front? Without answering this question you can only solve the immediate problem, but not future ones. Could be just a mistake, then that's fine, but could also be that there is no communication/feedback process or information/people sharing between engineering and manufacturing. Or that there weren't appropriate testing procedures.Or that information was missing because of illness and people didn't shared knowledge enough before the illness (truck score bad). Or something completely else. It's a bit funny that this happens exactly when in the example there are less than 5 whys asked. (Isn't it the main principle?)
Yes, you can go even deeper into the questioning. I typically stop when we get outside of an area of control (getting into other departments or outside of the company).
Some questions don't need 5 why's, some problems require more than 5, so it depends on the complexity of the problem statement.
Who is here after their boss asked them to do RCA for particular messed up by you ? :D
Haha
there is no time to implement all that, there is no willingness to participate on that, there is just a need to meet production-daily quota.
Sadly, this is the response from most managers. Not enough time to fix it, but apparently plenty of time to react to the problems when they occur.
All credibility is diminished by using that old urban myth about the Washington monument. Do your research. This NEVER happened. Also, Whys does not have an apostrophe, so an F for punctuation as well.
To convey a concept like 5 Why's, although not 100% accurate to the true story, it does a good job, so I will continue to use it. Here is an article about some of the differences from the real story, with links to actual newspaper articles that it did happen.
thekaizone.com/2014/08/5-whys-folklore-the-truth-behind-a-monumental-mystery/
Here is another article I found in 2 minutes of research, that talks about the same problem: www.newspapers.com/article/the-miami-herald-lincoln-and-jefferson-m/140061415/
I'll give you an F for your research skills and your attitude
Fish bone ko Hindi me
fish bone should be called Ishicowaw diagram in honour of the man who inventerd it (Sorry for bad spelling)
Yes, Ishikawa is the original name for it. I use fishbone diagram or cause and effect diagram because it's easier for people to remember