Tag Archives: defects
Process Capability: Is Your Process Up To The Task?
Posted on28. Apr, 2009 by carolesf.
Process Capability
is a measure of how well your process performs — that is, the proportion of in-specification items that is produced by the process — when it is in statistical control.
Note that this is not a measure of your process’s actual current performance on producing items in-spec. (That’s batch performance.) It is possible that your process may not be in statistical control at present, and therefore the state of current production is not necessarily relevant.
So to understand the concept of Process Capability, we need to recall what “in control” means in a statistical sense. Statistical Process Control (SPC) refers to the use of statistics to monitor the variability of a manufacturing process. The idea is to maintain control of the process such that some large proportion of items produced by that process are within design specifications. Note that SPC makes no reference as to whether or not the design is a good one; a poorly-designed product will perform suboptimally no matter how well the manufacturing process sticks to the design parameters. So Statistical Process Control does not necessarily ensure customer satisfaction or product reliability.
However, let’s assume for the moment that the design is a robust one and the in-spec product will meet the customer’s needs. So minimizing manufacturing defects is a definite must. We do this using the tools of Statistical Process Control. The most basic of these is called, naturally, the Control Chart.
Control Charts use statistical tools (based on sampling of items produced) to monitor both the central tendency of the manufacturing process, and its deviations away from the center. The idea is to flag variations in production that may lead to items being rejected at the end of the manufacturing process.
The manufacturing process is said to be “in control” (statistically speaking) when variation among items produced stays within the control limits. An item falling outside the control limits, or a series of increasing or decreasing data points, should be investigated to see if there is a special or common cause that is driving these variations.
Special cause, common cause, what’s all that?
Say you are baking several batches of cookies. Every batch is slightly different. Some cookies are thinner, some are thicker, some are more done, some are less done. However, as long as they are not charred briquettes, your spouse will eat them (in-spec).
Now the first batch is perfect golden brown. On the second batch, your best friend calls you on the phone just before the timer goes off. You don’t hear it. You forget about the cookies. Briquette city. Out of spec. This represents a special cause. Your friend called; that’s not likely to happen every time you make cookies.
So you throw that burned batch away and start over. Your spouse likes the cookies so well that the next week you make some more. And the week after that, and the week after that. Your process seems in control.
On the fourth week, however, you start to notice that the cookies are seeming less and less done when the timer goes off. Downright raw; out of spec. You investigate; by putting in an oven thermometer in, you discover that your oven is not heating up as well as it used to do. This is a common cause. Until you get your oven repaired, none of your cookies will be baked in-spec. (Unless your spouse likes to eat raw cookie dough.) Your process is out of control.
Now that we understand in control, let’s revisit: Process Capability is a measure of your process’s potential to produce items in-spec, assuming that your process is in control.
Welcome back to Lean Six Sigma Source! Thanks for your continued support.
Continue Reading
Fishbone Diagram: Root Out Those Causes
Posted on28. Apr, 2009 by carolesf.
The Fishbone Diagram
, also called the Ishikawa Diagram, was developed by quality management pioneer Kaoru Ishikawa. It is also sometimes referred to as the Cause-&-Effect Diagram — because that’s what it focuses on.
This is a tool used in brainstorming sessions during a Lean Six Sigma project. It can be used in either the Analyze or Improve phase of the DMAIC problem-solving framework.
Why is it called the “Fishbone” Diagram? Well, take a look. Could it be called anything else?
The parts of the fishbone diagram are:
- The head of the fish contains the Effect, or Outcome, of a process.
- Horizontal branches contain Causes. (Note the arrows, which indicate the causal relationship.)
- These are usually divided into 4 – 6 standard categories, depending on the type of business and process under study.
- For Manufacturing, a common list of categories is: People, Materials, Methods, and Machinery / Equipment.
- For Service, the list might look like: People, Policies, Procedures, and Machinery / Equipment.
- Personally, I like to add the categories of Environment and Measurement as well, bringing the total count up to 6.
- The fact is, you should not feel bound by any particular list of categories. Use what works for your company.
- Sub-branches contain contributing reasons for each Cause.
What to put on the branches? Well, here’s where brainstorming comes in. To help guide your team’s brainstorming efforts, you can use the “5 Why’s” approach. With the 5 Why’s, you keep on asking “Why” until you either identify the root cause, or run screaming out of the room. (Just kidding.) Usually, it takes only 5 Why’s — or fewer — to get to the root cause of a particular problem.
If you have (or ever had) small children, you are familiar with this approach; you just didn’t know that’s what it was.
“Mommy, why do I have to wear my seatbelt?” (The first Why.)
“Because that’s the rule.”
“Why is it the rule?” (The second Why.)
“Because I want you to be safe.”
“But why do I need to be safe?” (The third Why.)
“Because I don’t want you to be hurt if we ever have a car accident.”
“Why don’t you want me to be hurt?” (The fourth Why.)
“Because I love you!” (Ah-hah! Root cause, and we didn’t even get to the 5th Why.) (Note, also, the desire at this point to run screaming from the room.)
Now, having gone through that process for every possible factor contributing to the presence of defects, we can map them onto the fishbone diagram. This provides an excellent visual aid to avoid leaping to premature conclusions, and to make sure no key factors are missed.
The Fishbone diagram may seem simple, but putting it into practice can be harder than you might think.
- It’s important to get the right team members / stakeholders into the brainstorming session.
- It’s also important to manage the group dynamics, so that by the end of the process, all team members have taken ownership of the entire diagram. You don’t want people remembering which idea was whose.
- You may wish to break up the brainstorming activity into more than one session with a break in between. The break can enable some good ideas or missed factors to bubble up to the surface of participants’ minds, which can help the later sub-sessions be more productive.
In short, the Fishbone diagram can be a useful process improvement tool, helping teams to look beyond the obvious answers to the root causes of defects.












