excellent video! you've explained this very well.

Thank you! 🙏

It depends on the problem. Maybe the headlight is the only problem. Other times, it is the headlight and the fuse, which means both must be fixed in order for the problem to be solved.

@@user-ww2wr6ku5x You are talking cause and effect, in the case of the headlight and the fuse, if the fuse is blown but the headlight is still operational, either the headlight amperage is too high for that fuse, or the fuse amperage is too low for that headlight, if the fuse blows because the headlight shorts out, the problem is not with the fuse, that is what the fuse is supposed to do, (blow when there is an above set load) then the problem is the headlight, and a root cause analysis should be conducted on why the lamp is shorting out.

Agreed, but if I fix the light and replace the fuse - is it possible for the exact same failure to occur in the future? If yes, we haven’t gotten to the root cause. We’ve fixed the problem but when you get to the root cause, you will never have another situation where the fuse and headlight are defective. Example: I implement a process that triggers a reminder to replace fuse and headlight proactively. In operations, this is Total Productive Maintenance (TPM). All you need to do is track when the fuse and light fails and replace ahead of failure duration. Then update your calendar to remind you to change for the next duration. Now the root cause has been resolved with a simple process that prevents the failure from occurring.

You got it! Love reading this. I can tell you put some thought into this and remained open minded. That to me is a key attribute in this field…being open minded to new thoughts and ideas. Thank you for this! 🙏

Thank you! Feel free to share if you’d like. Here is the link: kzfaq.info/get/bejne/nJaEdqpyrdbLc6c.html

Thank you!

Thank you!

Thank you!🙏

The ship losing power would have a root cause and the lack adequate dolphins would have a root cause - but I’d examine these as two different problems that resulted in the collapse of the bridge. The problem statement would not be: the bridge collapsed. The bridge collapsing is a symptom that resulted from a lack of adequate dolphins and the ship losing power. I’d look at these as two different problem statements. Again, this is just the method I’ve been taught and that always works for me. It forces me to think deeper about the problem and separate the symptoms from the actual problem. Of course in the actual problem statement, I’d include metrics. For example, the bridge dolphins are not suitable for ships of size/weight.

Appreciate your support! The appreciation keeps me going!

You’re very welcome!

Awesome! Thank you so much for the feedback.

🙏

Awesome feedback! Thank you and congratulations! 🙏

You’re welcome. Thank you for watching.

Thank you!

🙏

Great speaking with you two today. I hope I provided enough value to supercharge your venture. Let me know if I can help further. 🙏

@@learnkaizen It was massively appreciated and super helpful! Thank you so much!

👍

Well said! 🙌

This sounds like a great opportunity for Kaizen. I'm in the middle of creating an incredible video Kaizen Course that will be available by the end of December 2021. In the meantime - check out this video I made on Kaizen...should help but let me know if you need more help...thanks for the comment and subscribing! kzfaq.info/get/bejne/n82Jq92e1suVcWQ.html

@@learnkaizen you have no idea how important this channel is right now I really hope all QA supervisors out there finds this channel. I’m in the customer service industry and just got promoted to a QA supervisor role and this is all new to me. I just find it (for now) difficult how to even detect if it’s just a symptom/cause or the root cause 😆 I’ll check the Kaizen video. God bless you and stay safe! P.S the customer service industry is so busy since the pandemic because people now do most of their business at home calling their providers for their telephone bill, shopping issue with Amazon and now to their crypto investments. Good time to explore root cause analysis and Kaizen this modern time to address all different kinds of issues.

Thank you! Sincerely appreciate the positive feedback. My channel is small but the people that are subscribed seem to really need this information. For that reason, I’ll keep putting out content. Thanks again! 🙏

There is a tool called the 5 whys which does exactly that, I just recently started learning about Lean, and six sigma, and have discovered that many of the tools, or terms, are of things I discovered and learned over the years, some are just logic based and just basic common sense, but you would be surprised at how much some basic common sense can be missing in the business establishment, things like takt time, and balancing flow, for example, I was doing this, before I knew there was a "science" behind them, and finding root cause, at a young age I was a diagnostic technician (trouble shooting) you learn real quick to find the root cause, because you can replace all the burnt out components, and instantly have them fry again as soon as you power up. what is great about these tools, is that seek to use them to get people on the same page, I have noticed that peoples emotions, ego's and hunches dictate many decisions made in a company, the tools in LSS help make choices based on reality, and get people on the same page.

Very well stated! Thank you. 🙏

🙏

I am making a project regarding Lateral Violence/Bullying with an emphasis on Conflict Resolution Strategies. I am utilizing the RCA with ADKAR. Your video is quite informative! Thank you for sharing!!! ✨

Continue driving to root cause.

Thank you!

Thank you for watching!

Many times I see folks use causes as root causes. For example: suppose we have a transactional process like: DSO (days sales outstanding) that always exceeds standard, well this is a complex problem because there are many inputs to DSO. However, each one of those inputs needs to examined to address the root cause of each input. If I simply stated that the RC of DSO is Accounts Rec. are late (an input to DSO), is this really the root cause? No, because we don’t know the countermeasure. We’d need to dive deeper on the AR process which may lead to several other causes (not RC)…the root cause should always be addressed at the process level. Another example: suppose we have a process that applies glue and sticks two widgets together. The process parameters are angle of glue applicator, speed of dispense and pressure of widgets to adhere to glue. Suppose the widgets weren’t sticking together…would the root cause be angle, speed and pressure? No. We need to dive into each input to see which one causes the failure. Suppose we find that it’s the pressure that caused the failure- here I can agree that this is the root cause but we can’t simply fix the pressure and go on with life because it will happen again..why? Because we haven’t address the problem at the process level. We’d need to implement hourly pressure checks or a gauge that alarms of the pressure is too low. Then we can say we’ve implemented a solution that addresses the root cause at the process level. Having worked in automotive, aerospace, biotch, discrete manufacturing, Fortune 500, etc, I’ve e countered some complex problems but I always drive to root cause at the process level. No disrespect and I appreciate your comment…if what you’re doing works and you solve problems which NEVER resurface, then that’s awesome! Who am I to tell you different.

After watching the video I agree there should be one root cause. Thank you!

Thanks for watching! 🙏

George Cucchi Great points! Thank you for commenting 🙏. This can be a touchy topic for some folks in the improvement world. Believe it or not - the example of the fire is one I see often and from some experienced professionals in my field (whom I respect). Again, I appreciate you taking the time to comment. Hope to see more of your comments on future videos. If you haven’t subscribed, it’d mean a ton to me if you’d consider it. Take care!

Right the heat from the stove that is ON causes the bag to burn however the root cause the very basic cause how did the 2 come together to cause the heat to burn the bag by the 3rd and final cause....a preventable cause one we can TURN ON AND OFF...we always know the heat will cause the bag to burn) the 3rd and MAIN root cause is that the stove was on and someone set a bag on the stove. You can turn this situation on and off.....bag on hot stove = burn bag off hot stove = no burn....root cause a bag placed on a hot stove = burn

Here are a few that you can Google: DMAIC, A3, 5P, 7-STEP, 8D…they all follow similar formats…DMAICis probably the most in depth…hope this helps. 🙏

@@learnkaizen thank you!

It’s used to solve a specific problem. You’re referring to a created problem. This is where we are meeting our goals but need to stretch to new targets so we create the problem by strategically moving the target and planning Kaizen events to achieve new target. Hope this helps! Appreciate the question.

@@learnkaizen thank you very much!

Agreed. Most problems don't have flat bars - I was using this as an example. However, you may have bars that are very close...In this example, I'm illustrating that these are all causes...to delays but not root causes. We'd need to dig deeper to understand the true root cause of each bar.

Hi, the 5 Whys should be used in conjunction with the Fishbone...so you'd complete your fishbone and use the 5 Why to test your assumptions. 5 Whys is widely misused and misunderstood, so don't feel too bad if you're struggling with this tool...please keep asking me questions If I have failed to explain it well..appreciate your support!

@@learnkaizen thanks if I have more questions I will reach out to you. Keep teaching.

To fix the root cause, you have to fix the process…the lack of staff is the root cause that can be fixed by creating a process that staffs during peak travel. I suppose I could have gone one step deeper: “why is there a lack of staff” - “because the current process doesn’t account for staffing during peak travel” - the countermeasure would be to create/update process to staff based on travel demand. How do you know when you’ve reached the root cause? I believe I talked about this in the video but it’s been a while since I’ve watched this video…I’ll explain it here though: you know you’ve reached the root cause of a problem when you can turn the mechanism that caused the problem on and off…sometimes the root cause is really expensive to countermeasure so in instances like these, you may opt for less expensive options….which doesn’t address the underlying process of the problem…example: “we ship the incorrect qty to customer” - why? “Final person in process miss counted” why? “Process allows human error” - c/m implement camera system that counts parts and gives green light when correct and then prints label - if count incorrect, red light and no label” This will count the parts and prevent printing of shipping label if the count is off. However, this might cost too much for the business - especially if it’s only happened once- but there can be many variables impacting a business decision. So, the business may decide to add two counters or maybe a less expensive scale… Hope this helps.

@@learnkaizen you have no idea how much this helps ! Thanks a Lot !

🙏

Agreed!

Tankler Gaming appreciate the love. I learned everything I know while working for a Japanese automotive company. We manufactured electronic control units (ECU) for Honda. Also did some electronically actuated parts but that phased out. Bad processes can certainly cause headaches but again, gotta stick to my guns on this one.(ONE ROOT CAUSE)....Don’t get me wrong - the countermeasure for the root cause my be too much money for the company to implement (seen this before)...so you have to adjust. Usually when I get called into find a solution to a problem, others have worked that issue for a while. I’ve yet to encounter a problem that didn’t have a single ROOT CAUSE! Again, not talking causes because I get it...there can be a sequence of causes. A design issue is a different beast and I feel your pain. Typically a design issue was allowed to escape design and enter the manufacturing world because the communication between design and manufacturing aren’t happening...I’ve seen this so many times. If the consumer receives a defective product, manufacturing has to deal with the RCA and countermeasure and all too often, this defect doesn’t get fed to Design. If the customer won’t correct the issue with design, then they have to manufacture around design issues. I’ve never had to deal with this myself so, unfortunately, I can’t offer much up...What I can say is that if you can convey how much money it’s costing them - they may be more likely to listen. My 2 cents.

I’ve never run across books that have case studies. I’m sure there are some out there (maybe) most books only share theory…and don’t show how it all fits together. I share one of my case studies in the Kaizen Expert Masterclass (with RCA)…I plan adding a few more case studies from my own experience but when I do, I’ll separate the 2 courses. So, there will be a Kaizen Expert Masterclass and a RCA Masterclass.Both stand alone courses. Right now, you get both with lifetime updates for one price…no pressure, just throwing it out there.

@@learnkaizen Not a problem. I understand you. I am a small content creator myself on other platform, my stuff is not monetized right now so I totally understand 😊 I will analyze if I need to buy a course/program just for understanding deep and it meets my professional goals, I will buy your masterclass 🙂

Working on a RCA/Problem Solving Course that will be available in a few months. It will. compliment the Kaizen Expert Masterclass...you can check it out here: www.learnkaizen.com Thanks for your support!

Appreciate your perspective and candid, respectful response. I really hate this topic because it can distract from the goal which is to ultimately resolve issues. So, if you’re able to resolve issues and that leads you to two root causes - who am I to argue? I’ve just never encountered this in my 25 years of working in this field - from Japanese automotive (Honda - electronics) to aerospace (Rolls-Royce - airplane engines) to (now) Fortune 500 corporate (Danaher - shifting between chemical manufacturing 20% of the time and transactional processes 80% of the time). In the situations you mentioned about multiple things happening at once, this is similar to a DOE situation where multiple levers have to pulled at exactly the right time and distance for the defect to occur...so theoretically multiple RC seems possible....My angle is that multiple causes happened and may need to be remedied but only one ROOT cause. That root cause will be process related. Now, again, this is a touchy topic and one that distracts many so I don’t want to argue semantics. I’ll simply say that when you’re considering causes or root causes, please consider the process as a possible root cause and update the process as one of the countermeasures. In the Japanese world I worked in - the process was always the RC....if we had to design a fixture with proximity sensors to CM product leaving the building without a screw assembled (which happened) - one may think that the RC is “screw missing” and the CM is “design fixture with proximity switches to detect screw missing” but I’d ask my folks to go one step deeper....we’ve fixed the problem with a fixture but why didn’t have this fixture in the first place? The answer is we didn’t consider that a possible defect when designing the manufacturing process, why did’n’t we consider it a possible defect? We didn’t see it in the PFMEA (process failure modes and effects analysis)...CM: add this defect with countermeasure to the PFMEA and readjust the RPN (Risk Priority Number) -- now when a new line is being developed, this risk with CM will be on the PFMEA so new lines will have this fixture with proximity sensors.....and that would be the root cause and c/m. I know we could probably go back and forth and I respect your knowledge on this subject. I appreciate your support on this channel and hope you consider subscribing. - even if we disagree on this particular subject. Always appreciate a good challenge! 😄

@@learnkaizen thanks for taking the time for such an elaborate reply. Fully agree that we shouldn’t make it a semantic discussion - we should be solving problems and improving performance. I think what I see is more of a ‘keep an eye on alternative solutions’ than an actual second root cause. I agree that there’s usually (maybe even always) only one root cause when a problem suddenly shows up. Fixing it will eliminate the problem. It’s more that I don’t want to limit the analysis to try and only find the ‘new’ deviation that leads to that root cause - in many cases your analysis will show another way to prevent the problem, some of which might actually be cheaper/more effective: new insights into your process, basically (which might not have been viable before, because of different initial design choices or changes in technology). Anyway, thanks again. I subscribed and will be watching more of your videos: it’s always good to see others’ views on ‘our topic’. I also recently started a similar journey you’re on - I’ve been in de CI field for years already, but started a YT channel on it last summer. Far from your following or content base, but I’d be honored if you’d take a look and let me know what you think.

@@TomMentink awesome...thank you...subbed to your channel! Keep up the great work.

@@TomMentink I hear you on finding alternative solutions. I think what we find is yes, there might be one root cause in this static process. Root cause analysis is best for situations where you need to find the SOMETHING that has changed in an otherwise good setting/process/design. If you have flexibility of maybe changing processes or equipment lines or teams, then your RCA just sorta floats new options your way, you’ve just gotta judge the way to maneuver into a better scenario.

Thank you

@@learnkaizen are you on LinkedIn?

Can you give me an example? (But I’m sure the answer is yes)…I’ve given this a lot of thought recently with the boarder crises. We keep hearing this term “root cause” which is being used to describe what we need to focus on in order to fix the problem. It’s clear someone has been briefed on the term without fully understanding the root cause analysis and countermeasure relationship - not to mention the fact that some root causes are too expensive to implement but we have something else…the correction action. The corrective action is used to “stop the bleeding” …for example: i keep hearing the root cause of the boarder crises is social unrest, poverty and dangerous living conditions in the countries that people are fleeing…so to fix the root cause the countermeasure is what? To fix the social unrest, poverty and dangerous living conditions of those countries. How? This is a countermeasure that has the right heart but won’t work in the near term….so a corrective action is needed to get people to stop fleeing their country or to prevent them from crossing the boarder….I know this is a touchy subject and I have no political agenda. I simply hate seeing bad things happen to people who just want to live in peace…and the videos I’ve seen of children being dropped over the wall or lying lifeless on the ground is truly tragic and needs corrective actions to prevent this from continuing…a long term countermeasure plan is fine - i.e.: dealing with the social-economic issues in the regions people are fleeing…that’s the long term plan…the short term - corrective actions - must be implemented soon or this issue is not ever going to end and more kids will be hurt and/or separated from their parents….sad! Sorry if this hit some touchy points but it answers your question (I think) and is a social issue I’ve given a lot of thought to given the fact I’ve heard the term “Root Cause” used so much by the US-VP. Hope this answer helps!

Why was there a lack of focus? What in the process allows this? Can a poka yoke be installed to prevent the failure?

You should be putting preventative measures in place….a FMEA (Failure odes and effect analysis) can help with that.

Much like fluctuations in demand within a manufacturing environment - we can rotate our workforce to where the customer demand is the highest - without hiring more employees. We can mimic the same behavior in the airport example. I hope I read your question correctly…if not please keep asking questions. Happy to help with a better explanation. Thank you for the question and support here on the channel! 🙏

5 whys is just a reference. You might find your RC after 3 whys or more than 10 whys.

💯

Appreciate the comment. I’ve come to the conclusion that it is absolutely semantics. I’m sure if you and I were together discussing this face to face, we’d agree on the direction, wording and learn we’re saying the same thing. Thanks again for the comment.

I'd like to agree with @henriquepaula9086 here and I'd like to respectfully disagree with @learnkaizen's response. In my view @learnkaizen's response saying that it's just semantics is a cop out, because it doesn't present a counterpoint to finding multiple root causes in Oil & Gas, petrochemical etc. Let's take the example of @learnkaizen's analysis of the airline delay. The 3 equal time delays triggers are not framed as the root cause(s) they are framed as 3 separate "problems" which contribute equally to the delay. First you need to define the problem, but the problem was defined: Flight delay and 3 equal delay problems were identified. He then dismissed the baggage delay & food delay issues without proper deep dive, says that the root cause is "Insufficient staffing to handle seasonal travel", the solution is to "increase staffing during seasonal travel" and the proof is that you can turn it on and off... But what is the cause of insufficient staffing to handle seasonal travel? Money, process, allocated space by the airport, etc? However, this does nothing for baggage handling delays or food supply delays, which if no solution is found for these, would STILL result in flight delays. i.e. Problem is flight delay. In this case there MAY be 3 root causes for the flight delay: Insufficient check-in staffing during seasonal travel, insufficient maintenance on baggage delivery infrastructure and poor food preparation processes in the airline kitchen, for example. The last two are NOT related to "Insufficient check-in staffing during seasonal travel" so this cannot be the root cause for ALL defined delays. There MAY be one root cause that has NOT been identified in this video: "Insufficient funding of multiple airline processes at this airport".... However, we can't know this without firstly a deep dive into all 3 delay types, and then a FURTHER deep dive into those underlying causes. IMO, this was NOT a good example showing only one root cause.

Thank you for the comment. Just to be transparent, this isn’t an argument…it comes from my experience…I learned this from Japanese teachers and over 20 years of RCA (and complex problems) - I haven’t encountered a problem that couldn’t be driven down to one root cause. I’m speaking from what experts taught me and through my own work in various industries - from automotive to aerospace to biotech. Having said this, do what works for you. I’m not the end all be all voice on RCA…I just do what’s worked for me (and what experts taught me)…and I share what’s worked here on KZfaq to help people who are willing to hear…I’m always open to learn myself.

@@learnkaizen I understand but I’m genuinely interested to understand what the single root cause could be in that final case (the airline not departing on time). It seems like each sub-problem would have its own root cause?

Lol…nah..it’s a worth suggestion... I could just say I’m old…🤣

I won’t attempt to dive into the root cause but I will admit, you’re not the only person who has told me this.

@@learnkaizen lolol

What process did you have implemented to make sure you got to work on time? If you don’t have a process set up, that is the root cause. If you had a process set up and you still set your alarm clock incorrectly, you made a defect. The cause of not showing up on time was because you made a defect. The defect existed because you didn’t have a robust process implemented with proper Poka Yoke mechanisms preventing the AM/PM mistake. That’s the root cause…know how I know? Because if I implement an alarm clock that sets automatically based on location…blah, blah, blah. Now I’ve countermeasure’d the root cause of waking up late due to the defect. Working 14 hrs the day before is not a root cause - it’s a cause for being tired but you need to consider the timeline of events. Your alarm not going off due to the process allowing you to make the defect - was the breakdown in the process (assuming you have a documented process for waking up). Everything you mentioned about HR, work life balance etc. are all separate causes or symptoms with separate root causes and countermeasures. This is a common mistake I see when people try to remedy every problem because of one mistake. In your example, you went from being tired to alarm clock to HR and work life balance and workforce labor laws!!! That’s a lot of problems that need respective attention but shouldn’t fall under the same umbrella as the alarm clock defect. I see this all the time - it’s a matter of continuing to challenge the problem until you’ve reached the mechanism that can turn each problem on and off at will. Then move to the next issue until you reach the root cause at the process level. So, I’ll stick to my original thoughts. I can work through the problem with you on paper if you’d like. Let me know and we’ll work out the schedules.

@@learnkaizen 1st of all ... Thanks for your time and prompt response 2. I am not a specialist in this .. but I feel that the linear 5 why thinking .. most likely leads to a fake cause .. I like your statement of turning on and off.. In my example.. turn the root cause of the alarm on and off.. 100 times.. you will not show on time .. because there were other causes .. That is why they used to ask .. What relevant happen just before ? And Was it enough to lead to what happened?? If you hit someone by your car.. We can spend 100 days talking about Training Defensive driving Car status Sleep apnea Braking system Bla bla bla.. While there was another fact that should have been considered in parallel. There were oil on the road !!!! I know it is another problem .. but it happened in the same time and had severe impact on the case.. I can not just ignore it and focus on the other line only .. In life.. problems happens simultaneously... and their line of cause and effect intersects.. And even if we considered that missing a process or procedure to ensure correct execution of something.. Even this .. i can challenge by taking it up in an infinite line !! Why there was not a procedure?🙄🤔 To be honest... Sometimes I feel that this whole RCA was over thought about.. until it became useless..

@khaledyehiahasan4729 I appreciate your comment and respect your input and thoughts. You sound quite knowledgeable about the subject matter and you’re spot on about the 5 Whys. The 5 whys generally get misused as a stand alone tool. While it’s good for questioning issues on the fly- the data you receive is generally qualitative and qualitative data can be difficult to remedy. We need quantitative data. That’s why I always utilize an Ishikawa (Fishbone) or affinity first! This allows me to pull information from the experts (the people who work at the process everyday) they are closest to the process and problem Leading them through the Fishbone process - documenting all the possible causes…then we prioritize those possible causes based and start collecting qualitative data…for example: suppose a bolt was loose on a widget. The Fishbone process led us to the machine-torque driver out of spec. Then we verify the actual torque driver readings (quantitative) compared to the spec. We find that it’s out of spec because the calibration is out of date and the it’s set to the wrong setting. Some may consider this 2 root causes but my opinion is that these are these are two causes from which we can derive 2 - 5 whys. Tool was used out of calibration. Why: operator didn’t verify calibration prior to using. Why, process does not indicate visual calibration date check prior to use. Countermeasure: implement process to check calibration sticker prior to using. Next 5 WHY: out of spec - why: torque was used on another machine requiring torque adjustment and not verified when returned/prior to use. Why: process does not require verification of torque prior to use. Countermeasure - update process to verify torque setting prior to use These are just quick examples so don’t beat me up too bad - the real take away is to use something like the Fishbone before the 5 Why…that’s the proper way.