How To Count Opportunity For Defects

Six Sigma – iSixSigma Forums Old Forums General How To Count Opportunity For Defects

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #31462

    Houston Mcfadzean

    I was wondering if anyone could help me to establish how to count the opportunities for defects in an assembly scenario. I dont know whether to count the number of things that must go right, or the number of things that can go wrong? It would be great if someone could help shed some light on the situation for me.
    Thanks, Houston



    Hmmmm, I do not know what you are producing, neither do I know how your assembly process is structured. So the explanation is quite general, but hopefully useful to you.
    Well, an opportunity can be considered as something a customer expects to be OK, but which might not be.
    E.g. Somebody that buys a mobile phone expects it to be functioning properly, but it might not be. So every mobile phone assembled is an opportunity.
    STEP 1: Count the results of your process
    Now the important part: a DEFECT is something completely different than a CAUSE OF DEFECT.
    – A defect is a case where the end-result is not as expected
    – The cause of a defect is WHY the end-result is not as expected
    E.g. a customer regards a non-functioning mobile phone as a defect, and does not care if this wether this is because of a non-functioning LCD-display or because a chip was not fitted right or …
    => STEP 2: Count the DEFECTS (faulty results) of your process
    At this point you are tracking enough variables to start looking at the performance of the process. And you might decide that it not performing well enough (=> too many defects).
    Ofcourse, to lower the number of defects (which is normally the objective of the exercise), you’ll need to find out what is causing the defects so you can take the necessary corrective actions. This is where it becomes useful to track things like ‘faulty LCD-display’, ‘Bad fitted chip’, …. An easy method to do this is by a simple checklist listing a number of causes. You’ll probably will already have some idea about possible causes (maybe do a Brainstorm and/or use a Fishbone to identify possible causes), so drafting this checklist can be easy, but be open for the fact you might learn new things along the way, so make sure people have the option to mark ‘Cause unknown’ or something similar.
    Analyze the results of this exercise to find out what are the main causes (Pareto is useful for this, but other techniques such as Correlation etc can also be applicable, depends on the situation).
    E.g. You find that 65% of defects are caused by ‘Bad fitted chips’, 25% are caused by ‘Faulty LCD’ and 10% by unknown causes. I would suggest to first concentrate on the bad fitted chips.
    => STEP 3: Identify possible causes and count them and analyze cause-effect relationships
    And here comes the fun part, because we are going to repeat the 3 steps to learn more about what is going wrong.
    => STEP 1: Count the number of opportunities (=> Chips fitted, well, you are already counting these (e.g. 3 chips per mobile => opportunities ‘Bad fit’= 3 times opportunities ‘non-functioning mobile phone’), so no extra work here)
    => STEP 2: Count the number of defects (=> Faulty LCD-Displays, this one you are also already counting, again no extra work).
    => STEP 3: Identify possible causes (of Faulty LCD-Displays) and count those. Brainstorm, Fishbone, checklist (again leave room for discovery of unknown causes) whatever…. and analyze and iterate again.
    The tricky part is to know when to continue and when to stop iterating thru the three steps. At some point you will detect a ROOT-CAUSE => this is the point where you know enough to prevent something from happening and thereby eliminating a (large) chunck of the original (customer perspective) defect.
    Why is this the tricky part? Well, some people tend to over-simplify and stop before they find a root-cause (therby taking the wrong corrective actions, sometimes causing more harm than good), others suffer from ‘analysis-paralysis’, they want to keep going until they have analyzed the whole world and everything on it.
    So before every iteration you should ask yourself if it worthwhile to dig further. DOE (Design of Experiments) is a technique that can help to make this decision.
    E.g. After a few iterations, you suspect that the pressure-setting on the chip-fitting machine is causing the bad fit which is causing the non-working mobile. So, set up some experiments where you use different pressure-settings and see what effect this produces on your measurements.
    Always keep in mind that some causes by themselves are quite innocent, but that a combination of them might make things go awfully wrong, i.e. the root-cause is not one specific item, but a combination of things. DOE (and ANOVA analysis techniques) can help you here also to design experiments to analyze the effect of combinations of adjustments.
    => STEP 4: Identify possible root-causes and solutions
    If the experiments produce no (significant) effect on the original defect-count, chances are you have not found a root-cause, so keep on looking. If the effects are significant => Yiha a root-cause has been found. Doing the experiments, you will also have identified better settings, so now implement them into your process.
    It is important to implement improvements as soon as possible after you identify them, even if not all defects have disappeared (‘zero-defects’ is seldom achieved by changing one thing). Why is this important? To show the improvement-approach works, to create goodwill, to recognize the team that did it and keep them stimulated, ….
    => STEP 5: Implement corrective actions
    After the identification of a root-cause and implementing the right corrective actions, have another look at your original defect-count.
     – If you are satisfied with the new level, continue to monitor it and when necessary repeat the search for the root-causes.
    – If you are still not satisfied, well … keep on investigating and improving.
    Hope this shed some light on it.



    Oops, just noticed that in the middle of my text I used the wrong example.
    So……. let’s think of the answer as the end-product of a process.
    You, by posing the question, expect useful answers => every answer produced is an opportunity.
    If my answer is not useful to you => well that is a defective answer.
    So …… why is it not useful? (checklist time)
    – Wrong language 0%
    – Confusing 100%
    – Other 0%
    Why is it confusing?
    – Mixing Examples 100%
    – Other 0%
    Why were examples mixed?
    – Chaotic work-environment 35%
    – No revision before submitting 60%
    – Not enough sleep 5%
    Why no revision?
    – Chaotic work-method 100%
    Why chaotic workenvironment?
    – Chaotic work-method 100%
    Hey, think I found a root-cause.
    Let’s move to a less chaotic work-environment to type this post and see what happens.


    Chip Hewette

    First, link your quest to external customer requirements.  Then, think through observed customer-described nonconformances such as customer returns…what reasons exist for customers to return?  Can you pareto these reasons?
    Second, consider a fault tree.  Can you logically describe likely failures?
    Third, consider a formal FMEA.  Will this identify likely failures?
    These tools may expand your list of things that can go wrong.
    Now, think through the number of opportunities, keeping in mind that some failures cannot occur downstream of earlier failures.  Don’t double count the opportunities.
    I cannot see the logic of only counting things that must go right.  Mathematically this would understate the area of opportunity.  Logically it would seem that all activities must go right to make the assembly.


    Rajeev Chadha

    If you are working on an assembly line where only attribute data ( and large related to asthetics of the product) is of concern, you can count the number of value adding unit processes to get a fairly good idea about the opportunities for defects.



    Hello Houston,
    Just count the number of parts and the number of steps involves in that assembly line and that will be your opportunities for Errors.
    I hope it helps.



    The first thing is to understand the difference between a DEFECT and and a DEFECTIVE.
    A simple explanation is that a circuit board can have 100 DEFECTS making it DEFECTIVE.  However, this same circuit board can have 2 DEFECTS also making it DEFECTIVE.
    So on your production line, you need to focus on the product you are producing.  Your assembly line will not have any defects, yet the product or products being made on your line may become defective (because of defects). 
    Simply count the number of things that can go wrong with your product.  You will then arrive at your OFD (opportunity for defects).



    Opportunities are the things that must go right not the things that can go wrong.
    Creative minds can make the things that can go wrong almost infinite.
    The definition flows from the process map and only value added things count.



    You say – “I cannot see the logic of only counting things that must go right”. Then you answer your own question.
    Who teaches this stuff of counting all the things that can go wrong? They don’t have a clue.
    It is things gone wrong divided by the number of things that must go right times one million.



    Opportunities are the things that must go right not the things that can go wrong. Interesting comment that I don’t totally disagree with.  However, saying something MUST go right is pretty common sensical to me.  And saying that a creative mind can make the things that can go wrong almost infinite is somewhat inaccurate.  Take a circuit board, for simplicity’s sake, let’s assume there are 5 discrete components on it.  I would take the 5 parts x 2 solder connections per part to arrive at 10 OFD.  Then add the circuit board and I would say this whole “product” has 11 OFD’s.  Where it gets tricky is if one part is missing altogether.  Do you count this as 1 defect or 2 defects?  This is where I would classify the defect according to the failure mode.  If I were looking at component DPM, I would say it was one defect.  If I were looking at solder DPM I would say it was 0 DPM (assuming there was solder on the pads).Determining OFD’s is not rocket science, but you can’t assume a simple process map identifying your VA processes is going to give you what you are looking for…  It is more involved than that.



    I agree. Separate the issues.
    Count opportunities – things that must go right. In your example it would be sixteen, eleven. 6 for your components being right. qo for your connections being right. This is the denominator times the number of units produced.
    Count defects – what was the mistake? Your example is one defect – component is missing. Can’t be bad connection if the component is not there. You make this part clear for all of the reasons in your original post. The sum of all these mistakes is the numerator.
    Separate the issues and keep it simple. It definitely is not rocket science (rocket science is not rocket science either by the way).
    All of this other nonsense on here is the reason why this valuable management tools has been made meaningless. One count for every piece of material (or work if it is a service) purchased from a supplier, one count for every VALUE ADDED transformation of the product or service you do. So simple.



    Stan, Ron,
    I am in a similiar situation.
    I can see 5 chips (10 pads) + 1 pcb as being 16 opportunities for defects, however, what about adding a BGA 48 pin?
    Following the same logic, this would add 49->65 OFD
    On BGAs, I have seen missing ball joints, bad solder connection (1 ball), or bridging.
    Do you guys feel adding in all 48 solder connections to be resonable/justifiable?

Viewing 12 posts - 1 through 12 (of 12 total)

The forum ‘General’ is closed to new topics and replies.