Root cause identification in 6 sigma project
Six Sigma – iSixSigma › Forums › Old Forums › General › Root cause identification in 6 sigma project
- This topic has 14 replies, 9 voices, and was last updated 13 years, 2 months ago by
Obiwan.
-
AuthorPosts
-
February 22, 2009 at 12:10 pm #51891
Prabhu shankarParticipant@Prabhu-shankarInclude @Prabhu-shankar in your post and this person will
be notified via email.Hi
In a 6 sigma project, how to conclude whether an identified root cause is a real root cause or some other cause is still available or to be further anlayzed?0February 22, 2009 at 1:32 pm #181560Customer issue: When is a root cause a real root cause and do I stop finding root causes
Conclusion: Keeping identifying root causes and removing the causes until the project objective has been meet. If you decide to make further improvements beyond the project goal, create a new six sigma project.
Example
Set Six Sigma Project Objective: Suppose a test of a specific CTQ output on an electronic devices has a Cpk = 0.5. Your six sigma project goal is Cpk =>1.0.
Root Cause Identified: Your team identify a root cause. The upper test limit, (UTL) was entered incorrectly into the automated test system. You make the correction, and you measure Cpk. With the new UTL the Cpk = 0.7.
Meeting the Project Objective: The project objective has not been met. Clearly, there is another root cause causing such a low Cpk value. Since the project goals have not been met you need to find another root cause, and make the needed correction.
Stop: When the project goals have been met the project is completed.0February 22, 2009 at 2:44 pm #181561you may like to see the combined effect of factors. the best i would suggest you to
step 1: identify possible factors (use fish bone diagram / failue modes in system / process)
step 2: analyse vital factors and find root cause (use annova, 2 sample t, chi-sqr test depending upon data type and then 5 Why analysis)
step 3: collect data on all vital factors & response and coduct Regression. if r-sqr and r-sqr (adj) more than 64% or 80% depending on your sector benchmark, it means the combined effect of selected factors / root cause are sufficient and explain the variation in the system.
Note : ur vital factors may even be one and if r-sqr value less than 64% you may have missed some vital factor or root cause.
step 4: implement improvement plan and post that check your process has improved to the level of your pjt tgt / expectations or not.
If not, then start again from step 1. you may have missed some factor or data collected during regression was not true representation of actual process variation.
Hope this helps :-D
Ashky
0February 22, 2009 at 3:20 pm #181564
ValleeParticipant@HF-Chris-ValleeInclude @HF-Chris-Vallee in your post and this person will
be notified via email.Rick,In your example you just fixed the error someone made in entering the UTL. What caused the UTL To get entered incorrectly and why was it not caught until it was too late? This will happen again here or if a system problem somewhere else. HF Chris Vallee
0February 22, 2009 at 3:41 pm #181566
ValleeParticipant@HF-Chris-ValleeInclude @HF-Chris-Vallee in your post and this person will
be notified via email.Prabhu,First off are you working on a project or a paper? I like to know the agenda behind the question. To be upfront, RCA is the area I work in now. With the agendas out of the way. You can’t stop at the symptom level and apply corrective actions there. While Rick’s post was accurate about meeting the objective of your project, putting a band-aide on the error/symptom level just delays the forthcoming failure that will show up again.Also just because a group agrees on the problem and gets a feel good feeling using some of the tools mentioned in the other post for RCA, does not make it accurate.. you have to have the right people ask the right questions and avoid bias as much as possible. You have to truly understand What happened and that is done by observing… then you can look for the root causes.
0February 24, 2009 at 6:03 pm #181646HF Chris VAllee,
Customer Issue: A permanent corrective action was not provided.
Comments: You make an excellent point. I provided the containment action but not a permanent corrective action — for example either a sign-off procedure by another individual to validate the entry or some other procedure is needed to prevent the error from happening again.
On the other hand, my purpose was to illustrate when you stop looking for more root causes. Notice that I stopped looking with a Cpk =1.0. I am sure that you agree when I say, a process with a Cpk = 1.0 is not a very good process.
0February 24, 2009 at 7:05 pm #181649
ValleeParticipant@HF-Chris-ValleeInclude @HF-Chris-Vallee in your post and this person will
be notified via email.Rick,I understand that you were setting up the mechanics for when to stop root cause analysis; however, many people do stop at the error level of root cause which is why it is temporarily controlled or contained. In my world containment is a band-aide. Stopping the root cause search at the containment is not smart and allows people to speedily go for the quick fix. Interim corrective actions are fine until the root causes are found.This leads into another issue of projects that are initially signed off because of the containment fix and the gains never materialize. In all honesty the CPK numbers were not an issue to me because I felt that your example stopped at the error level anyway. Setting you objective is a whole other issue.HF Chris Vallee
0February 25, 2009 at 3:26 am #181664
SeverinoParticipant@Jsev607Include @Jsev607 in your post and this person will
be notified via email.Some questions that may help identify the root cause:
Have I identified the fundamental breakdown of a process or system that created the issue?
If I turn my “root cause” on does my problem appear?
If I turn my “root cause” off does my problem go away?
Do the observed phenomena contradict my root cause?
The list above is by no means exhaustive, but they have proven very useful to me when solving problems.0February 25, 2009 at 11:08 am #181669I have excellent slides but I will never exchange with anybody because of lack of appreciation,respect and feedback!
Good Luck0February 25, 2009 at 3:16 pm #181684Causality is hard to prove unless you try out improvements on the root causes you identified, and see if your process performance improves. If it doesn’t keep looking for root causes. If it does, close the project, but monitor the results and conduct periodic audits to make sure the problem doesn’t come back. If it does, you have to keep looking for root causes.
0February 25, 2009 at 7:37 pm #181698Just apply 5WHYs!
0February 25, 2009 at 8:23 pm #181700HF Chris Vallee,
I agree with you 100%. Stopping at a containment action (unless the containment and permanent corrective actions are the same) does not prevent the root cause from re-occurring. Yet, both containment and permanent corrective actions are needed. The band-aide stops the boat from sinking; giving time to implement a permanent corrective action. The containment action is particularly important to stop defects from leaking out to the customer either external or internal customers.
Just to keep a bit of continuity between discussions: I made the assumption that the root cause for the wrong upper test limit would be found and fixed. Given that assumption, the question that I then answered was the following: Having resolved the root cause of the wrong upper test limit, a necessary step, is the resolution of that root cause sufficient to stop looking for new root causes.
One More Point: The results for a root cause search are presented in an 8D reports. Within that report, I see two other steps that are often dropped: First is the confirmation of the solution once it is fully implemented into production. I have seen software, permanent corrective actions, that appeared to work fine but after full implementation a bug was found. Also, the preventive action step is often dropped. What a waste for some one else to solve the same problem on a similar product 6 months later.
My thanks for making me think deeper.
0February 25, 2009 at 8:56 pm #181702
ValleeParticipant@HF-Chris-ValleeInclude @HF-Chris-Vallee in your post and this person will
be notified via email.Thanks Rick
0February 28, 2009 at 11:42 am #181813
EK.Prabhu ShankarParticipant@EK.Prabhu-ShankarInclude @EK.Prabhu-Shankar in your post and this person will
be notified via email.Well said Ashky, thanks for your feedback.
0February 28, 2009 at 2:57 pm #181822Rick
I read your entire exchange with HF and noticed that I still believe that there is one thing missing. You made no mention of ongoing control of the situation. A project is not complete just because you were able to establish the goals of the project. Those goals must continue to be met on an ongoing basis, thus control into the future is equally (I could argue that is is MORE) important than just meeting the goals.
Otherwise, I substantially agree with you and HF’s string of posts.
Obiwan0 -
AuthorPosts
The forum ‘General’ is closed to new topics and replies.