Lean Six Sigma for Business Improvement

Prevention not as tough as it seems

noreply@blogger.com (Quality Management Systems Solutions) — Wed, 15 Sep 2010 04:12:00 +0000

Often times, we ask our clients what their proactive or preventative activity is. Most of the time, we get a blank stare. Others provide a list of risks, but no real activity geared towards mitigating those risks.

In the past, we would push the use of Process Failure Modes and Effects Analysis (PFMEA) as a method to achieve a prevention or risk mitigation plan. PFMEA is an excellent tool for doing just that, in addition to tying those risks in with the current issues, to figure out what is most important to be worked on. You can learn more about PFMEA's through our training material.

However, we are taking a step back, instead of jumping right into an FMEA approach. There are easier steps that should be taken first.

First, gather up the stakeholders, customers, and process experts, and facilitate a group discussion on what things could potentially cause problems in the near future. This is essentially a brainstorming exercise. If you get stuck, you could look to the Cause and Effect Diagram approach, and talk about the People, Machines, Processes, Environment, and Materials, and how they can bring about new problems. Once a list of risks are generated, the team should try and informally rank them, and develop an action plan for the top 1-3 issues only. Any more than 3, and you shouldn't be surprised when nothing gets done. Another rule of thumb we like to hold to: no more than one action per person at a time. Again, any more than that, and your asking for those items to be deprioritized, so that nothing gets completed.

After the list of risks are identified, the group should look at the list, and decide if they covered most of the risks or not. If they feel they did, and the list is manageable, then setting up a regular cadence to review these items is probably sufficient. If the team feels that there are other risks out there, then it may require additional sessions. Here is where the FMEA approach can help. It is an effective tool because it walks systematically through the process under evaluation, and forces the team to review the ways each process can fail to meet its intended output. This makes it less likely that an issue will "slip through the cracks". Again, after the list is expanded to include these additional risks, the list can be re-prioritized (this time more formally using Nominal Group Techniques, multi-voting, etc).

Finally, if the list identifies many additional issues, and the team is having a hard time prioritizing the top risks, a formal PFMEA may be needed, to iron out the details, and provide a more objective assessment of which risks are the highest ones needing an action. This is also useful if the team feels the risks are not fully captured, and the formal FMEA approach would bring these risks to the surface.

Again, the key to all of this is to align the complexity of the process to the complexity of your risk assessment. If you have a simple process, a simple approach may be sufficient. If your process is complicated and risks are high, then a more formal risk assessment may be needed. We recommend starting small, and expanding as the list of risks expands and gets more complicated.

When you jump right into a formal FMEA event, and want to spend hours of a team's time and energy, it's often difficult to justify the need to go through that much detail of a process. However, when you start small, it's easier to later justify the need to dig deeper, and get more formal with your risk analysis, once the team sees how much risk is out there that is not being managed.

The key to success is that the risks are added into a regular review or cadence process, preferably the same place where the regular activities are being reviewed. For example, if you have a staff meeting, devote 5 minutes to risk actions. If you have a program review, add 2 slides to discuss risks and actions taken on those items. Maybe start by looking at your personal life. Do you own a house? What actions do you need to complete to prevent a major issue at home? Are you keeping up with your vehicle maintenance? Are you anticipating and planning for upcoming or suprise bills?

The only way you can move away from a "firefighting" mentality is to allocate some of your time working on actions that are proactive or preventative in nature, otherwise you will continue to react to everything that comes along. Discussing the risks, assigning actions, and reviewing those actions are the key steps to make that transition happen. Just get started doing something, then worry about whether it is the biggest risk later on...

Don't "check the box" with soft improvement tools

noreply@blogger.com (Quality Management Systems Solutions) — Thu, 07 Jan 2010 05:11:00 +0000

We recently were reminded of a problem that comes up every so often in regards to process improvement tools. The "check the box" mentality.

You train, teach and mentor individuals on which tools to use, and when they finally decide to use the right tool at the right time, they try to shortcut the process just to get it completed, missing the entire purpose of the tool!

Let's use the fishbone diagram. Our clients will identify the need for a fishbone or maybe we'll have to suggest it. Instead of gaining the benefits of the team discussion and brainstorming, someone sits down at their desk and starts to fill out the diagram.

"I worked on that last night, and finished it, then emailed it to everyone. Now which tool do we need to do next?"

Process Improvement tools, like fishbone diagrams, are not the end result. The purpose of the tool is to provide a framework in order for the process of evaluation to take place. When we perform a fishbone diagram, we are actually doing many different things without realizing it:

1) we gather up the right resources from cross-functional areas
2) we clearly define the problem statement (often overlooked)
3) we openly talk about problems and variables that cause the problem we are trying to solve
4) we brainstorm why it could be happening (without fear or insults) using commonly used categories (Man, Method, Material, Machine, etc)
5) we generate a very thorough list of potential variables to go investigate

The REAL output of a fishbone diagram comes down to two main things:

1) a plan to go investigate some of the most likely variables
2) an opportunity to interact with a diverse group of stakeholders in the problem, get to know them, and see their unique perspectives and hear how that problem impacts them

Notice we didn't mention a nice looking fishbone diagram with a fish outline around it, with color-coded labels for each category.

Even if NOTHING is done after the fishbone diagram meeting, there still was value in creating the fishbone. Most likely, you will have actions that come out of the effort, but don't overlook the PROCESS that took place to create it, which is where much of the value came from.

We use the fishbone diagram as an example, but it applies to many of the tools, especially ones we consider "soft" (little to no data analysis involved).

The inspiration for this article came from a group we worked with that was trying to quickly complete a Current State Value Stream Map (VSM) because they were running out of time before the scheduled Future State Mapping event. This event had a hard date due to individuals who were flying in from out of town. The team was suggesting that they could quickly draft the Current state map on their own, then have the actual owners of the proceses review it right before the next event, then jump into developing the Future State.

We politely reiterated that the completion of the current state map is not the end result. It is the PROCESS of developing the current state map where the value is created. The most important part is the time spent with a concurrent group of people defining the process, talking about the issues, understanding that the process is broken, and hopefully building relationships with these other stakeholders. Those relationships are really the key to the VSM. Now when future issues come up, they can be avoided or better anticipated, since the perspective of others are now better understood, and they can include or discuss the impact with them BEFORE a change or issue occurs.

For example, during the VSM, you might discover that leaving off the account number on a form causes 10 minutes of work for a later process run by Judy, who was at the event. After the event, you run into an account number that looks unfamiliar. You call Judy and discuss, and she recommends you return the form to the owner before processing it. You've saved yourself time processing it, and cut the wait time from when you completed the form, until she would find the error, and have also given instant feedback to the form originator that there was an error. You also saved Judy time reviewing the document to find the error. Obviously, you would want to permanently resolve this issue. However, this probably was not even a major issue that came out of the event, yet the benefits are already being seen because of the VSM event. If you and Judy had not gone through the VSM process, you would have never been able to anticipate those kinds of issues.

Spending time in an event will also give people a chance to think clearly about how they do work. It will also allow them time to digest the fact that the process is indeed broken, and that they will have to change the process in order to make it better, especially if their process is the one causing the most problems. If you speed through this process, you'll miss the entire change management process, and you won't have the commitment you need going forward.

We also see people get wrapped up over the format of the template. On an FMEA, they argue over the title of a column (Key Product Characteristic or Critical to Quality), or whether the Severity ranking is a 6 or a 7. The FMEA creates a nice spreadsheet for prioritizing the effort, but the value lies in the concurrent discussion between all stakeholders. After the event, the individuals in the event are much more likely to think differently, and talk directly to each other about other issues they encounter, than they were before the event. The FMEA was just a process developed that forced this group collaboration to take place.

In a perfect world, all processes would be linked together where this communication and discussion was happening constantly between all stakeholders, but we know that's not realistic. Companies get siloed away from each other via departments and budgets and physical locations. These soft tools are necessary to bring thsse groups back together, even if for just a day or two.

The tools that are more about the process, rather than the actual end result include: FMEAs, 5 Whys, Affinity Diagrams, Force Field Analysis, Process Flow Diagrams, Value Stream Maps, and Fishbone (Cause and Effect) Diagrams. This doesn't really apply to the "hard" analysis tools like control charts, histograms, statistical analysis, etc. Those can be performed by an individual without a team, as long as the results are shared and digested as a team.

Bottom line: The process improvement tool is not usually the end result. The process to get there is where most of the value is created and discovered, so don't try and shortcut the process just to "check the box".

A new spin (literally) on an old quality tool

noreply@blogger.com (Quality Management Systems Solutions) — Sat, 21 Nov 2009 22:55:00 +0000

I love the Pareto chart. It's one of the simplest quality tools, yet one of the most powerful, and underused tools out there. It's so easy to get buried down into an issue, and forget that it's not the one that should be focused on.

However, when I recently presented a Pareto chart to a Senior VP of an organization we are working with, I noticed everyone in the room had tilted their head to the side, in order to read what each category said underneath each bar.

It quickly occurred to me that anytime you present a Pareto chart with more than a couple words per category, you should flip your Pareto chart on its side, so that the categories are easily legible, and you don't give your customer a sore neck (since you're already a pain in their neck as it is!)

Have any other helpful tips? Let us know...

Interpreting Minitab's Gage R&R Chart

noreply@blogger.com (Quality Management Systems Solutions) — Fri, 26 Sep 2008 22:37:00 +0000

Minitab provides a great Gage R&R six-pack chart, when performing a Gage study. However, there is some confusion and a lack of knowledge on how to interpret each chart, in order to better understand the validity of your measurement system.

In this article, we will look at two different examples, one for measuring TAB WIDTH (poor results), and the other measuring CAP BOW (good results)

Components of Variation

The first chart (upper left corner) is your breakdown of variation, into Part, Repeatability, and Reproducibility. There are three comparisons made from these results: % of overall variation (StudyVar), % of Tolerance (Spec Limit width, if entered into report), and % of Contribution.

The first place I look is the R&R variation as a % of Tolerance (blue). Others use '% of StudyVar' (green) or '% of Contribution' (orange) This provides me with a quick assessment of the measurement system. If that number is greater than 30%, then I have a problem with my system. I would then look at whether the repeatability or reproducibility % was greater, in order to determine what I need to improve. If the % is less than 10%, then I have an adequate measurement system. In the examples above, the far left group of charts shows a blue bar above the 50% mark. The good chart below that shows a very small blue bar, which means the measurement system takes up very little variation, compared to the spec limits of the item being measured.

Here is the criteria for determining if your measurement system is adequate, using the different % calculations in Minitab (taken from AIAG guidelines for the gage R&R table

% of Tolerance Result	Conclusion
Less than 10%	ACCEPTABLE – No action required
Between 10% and 30%	MARGINAL – If Ppk is less than 1.67, then improve measurement process until % of Tolerance is less than 10%, otherwise, no action is required
Greater than 30%	UNACCEPTABLE - Must improve measurement process so % of Tolerance is less than 10%, or less than 30% with Ppk greater than 1.67

If the system is unacceptable, look at the 'Repeat' and 'Reprod' groups, to see where the majority of the variation is coming from. In the bad example, most of the variation is coming from Reproducibility (Operator), rather than Repeatability. This will be evident on the other charts as well, so make sure your conclusions match all the charts.

Range Chart by Operator
The next chart, the R chart (middle left), shows the repeatability and reproducibility variation
If your R chart is in control (almost all data points inside the control limits), then that is a good sign. If it is out of control (points outside control limits), then there is no consistency to the measurement system.

Xbar Chart by Operator
The X-bar chart (bottom left) shows the part variation, using the measurement system R chart from above, for the limits. If you have a good measurement system, then this chart should be out of control (all points outside the control limits). This means that the part variation is easy to detect, despite the variation in the measurement system. If the chart shows data points within control, then your measurement system is making it difficult to measure part to part differences.

Variation by Part Sample
The next chart (top right) shows the individual readings of each part. In an ideal chart, the variation in the parts should be large, in comparison to the variation in the readings around the average for each part. This means that the parts are quite different from one another, while the measurement is taking readings very close to the part average. If the individual points are spread out from each other on each sample, then it means the measurement system is having a hard time picking up whether the variation is coming from the part or the measurement system itself.

Overall Average by Operator
The next chart (middle right) shows the differences between operators using their overall average reading. A good measurement system would not allow operators to cause a difference in the readings, so you are looking for a straight line, which means that across all parts, the operators averaged close to the same readings. If there is one operator with an average higher or lower than the others, then it confirms that they have an influence on the final measurement, and therefore the measurement system is inadequate.

Operator*Sample Interaction
The last chart (bottom right) shows the interaction plots for operator by parts. You are looking for parallel lines, which means there are no interactions. Interactions would mean that certain parts were measured differently (with either more or less variation) by certain operators. This is another sign of a poor measurement system.

For more information about these charts, view a sample summary from Minitab

Does bottled water actually taste better? Attribute Agreement Analysis

noreply@blogger.com (Quality Management Systems Solutions) — Thu, 05 Jun 2008 22:21:00 +0000

In order to answer this question, we setup an experiment to see if people could tell the difference between four different types of water (Filtered Tap Water, Fiji^©, Zephyrhills^© and a generic brand purchased at 7-11^©).

Fiji^©

Zephyrhills^©

7-11^© Generic

Filtered Tap Water

Each person was given a sample of the four waters at the beginning of the test, and told which one was which, so they knew how each water tasted. At any time during the test, they were allowed to go back to the samples and re-taste them.

After tasting each sample, they were given 12 unmarked cups of water, and asked to select the correct water based upon its taste and smell. Each of the four water brands were provided three times in the study (12 cups total, see image below).

	12	11	10	9	8	7
	1	2	3	4	5	6

The correct answer, along with the answer for each of the three testers are displayed below in Table 1.

Table 1. Correct and Chosen Answers for Water Test

Cup #	Actual	Tester #1	Tester #2	Tester #3	% Correct
1	Generic	Generic	Tap	Fiji	33%
2	Tap	Zephyrhills	Generic	Tap	33%
3	Fiji	Fiji	Fiji	Generic	67%
4	Zephyrhills	Fiji	Fiji	Generic	0%
5	Fiji	Tap	Tap	Zephyrhills	0%
6	Tap	Zephyrhills	Zephyrhills	Tap	33%
7	Generic	Fiji	Fiji	Zephyrhills	0%
8	Zephyrhills	Tap	Generic	Fiji	0%
9	Tap	Tap	Tap	Zephyrhills	67%
10	Generic	Generic	Generic	Generic	100%
11	Fiji	Generic	Zephyrhills	Zephyrhills	0%
12	Zephyrhills	Fiji	Fiji	Zephyrhills	33%
Overall		42% (4)	33% (3)	42% (4)	8% (1)

Having each brand show up more than once allows us to test how repeatable each tester is. In other words, if one tester correctly chooses the Fiji water the first time, but chooses it incorrectly the other two times, then it shows that the first selection may have been more of a lucky guess, rather than strong evidence that the tester could differentiate between the water.

In order to apply statistical analysis to this experiment, we used Minitab's Attribute Agreement Analysis test. For those of you not familiar with this technique, it is a method for determining how well different people can select the correct answer from a list of choices.

Here is the Minitab Analysis of the results, summarized to highlight the key points


Attribute Agreement Analysis for Tester1, Tester2, Tester3 
 
Each Appraiser vs Standard 

Assessment Agreement

Appraiser  # Inspected  # Matched  Percent     95 % CI
Tester1             12          4    33.33  (9.92, 65.11)
Tester2             12          3    25.00  (5.49, 57.19)
Tester3             12          4    33.33  (9.92, 65.11)

# Matched: Appraiser's assessment across trials
agrees with the known standard.




Fleiss' Kappa Statistics

Appraiser  Response         Kappa  SE Kappa         Z  P(vs > 0)
Tester1    Fiji         -0.008403  0.288675  -0.02911     0.5116
Generic       0.555556  0.288675   1.92450     0.0271
Tap           0.111111  0.288675   0.38490     0.3502
Zephyrhills  -0.263158  0.288675  -0.91161     0.8190
Overall       0.106977  0.167447   0.63887     0.2615
Tester2    Fiji         -0.008403  0.288675  -0.02911     0.5116
Generic       0.111111  0.288675   0.38490     0.3502
Tap           0.111111  0.288675   0.38490     0.3502
Zephyrhills  -0.263158  0.288675  -0.91161     0.8190
Overall      -0.004651  0.167447  -0.02778     0.5111
Tester3    Fiji         -0.263158  0.288675  -0.91161     0.8190
Generic       0.111111  0.288675   0.38490     0.3502
Tap           0.747368  0.288675   2.58896     0.0048
Zephyrhills  -0.125000  0.288675  -0.43301     0.6675
Overall       0.098592  0.168671   0.58452     0.2794


Between Appraisers 


Assessment Agreement

# Inspected  # Matched  Percent     95 % CI
12          1     8.33  (0.21, 38.48)

# Matched: All appraisers' assessments agree with each other.


Fleiss' Kappa Statistics

Response         Kappa  SE Kappa         Z  P(vs > 0)
Fiji          0.169231  0.166667   1.01538     0.1550
Generic       0.111111  0.166667   0.66667     0.2525
Tap           0.035714  0.166667   0.21429     0.4152
Zephyrhills  -0.037037  0.166667  -0.22222     0.5879
Overall       0.072165  0.096424   0.74841     0.2271


All Appraisers vs Standard 

Assessment Agreement

# Inspected  # Matched  Percent     95 % CI
         12          1     8.33  (0.21, 38.48)

# Matched: All appraisers' assessments
agree with the known standard.


Fleiss' Kappa Statistics

Response         Kappa  SE Kappa         Z  P(vs > 0)
Fiji         -0.093322  0.166667  -0.55993     0.7122
Generic       0.259259  0.166667   1.55556     0.0599
Tap           0.323197  0.166667   1.93918     0.0262
Zephyrhills  -0.217105  0.166667  -1.30263     0.9036
Overall       0.066972  0.096912   0.69106     0.2448

* NOTE * Single trial within each appraiser. No percentage of 
assessment agreement within appraiser is plotted.

To summarize the analysis above, the numbers in bold are the Kappa values. A kappa value greater than 0.7 is considered acceptable, meaning that our testers are able to adequately select that brand from the rest of them. As you can see, there are no brands with kappa values greater than 0.7, therefore we conclude that with an overall kappa value of 0.067, the testers are not able to determine a difference between the brands of water. In fact, since some of the values were close to zero, it means that they could have done just as well if they guessed (random chance), than actually tasting the water and making a selection. The brands highlighted in red were actually below zero, which means that they were worse than random chance, so the testers would have done better by simply guessing. Bottom line: Stop buying bottled water, just reuse your water bottles by filling them up with filtered tap water (not recommended for long term use). Not only will it help your own pocketbook, but you'll help the environment, by preventing the creation of new bottles and reduce the transportation costs associated with getting the bottles to your local store.

Conclusion: So how is this study applicable to your company? Most processes collect some kind of data, and typically there are codes that get assigned to designate the type of transaction, type of defect, or some other reason. Without validating the ability of the people to correctly classify these codes into the right buckets, there is a possibility that the codes are being incorrectly used, and people are misinformed on what is really going on in the process.

Let's say you are collecting data on reasons for late payments from your customers. You generate a report that shows the Top 5 reasons for late payments.

Reason	Percentage
Missing Paperwork	33%
Problem with Service Provided	25%
No Reason Provided by Customer	18%
Wrong Information on Invoice	13%
Wrong Amount on Invoice	5%

Naturally, you would start working on the "Missing Paperwork" category, but you are assuming that you have a good measurement system that is correctly coding these late payments into the correct defect code. The only way to know is by performing an Attribute Agreement Analysis. If it does not pass (poor Kappa values), then you must conclude that the defect codes are not accurate, and must be further clarified in order to get a "true" picture of which issue to focus on.

Let's assume that your coding criteria is clarified for your people, and the data is cleaned up with this criteria. Now let's look at the Top 5 issues...

Reason	Percentage
Wrong Information on Invoice	42%
Missing Paperwork	23%
Problem with Service Provided	15%
No Reason Provided by Customer	12%
Wrong Amount on Invoice	5%

As you can see, the order of reasons has changed after the criteria was improved, so now I can correctly go out and investigate why there is "Wrong Information on Invoice" instead of the previous problem of "Missing Paperwork"

Attribute Agreement Analysis allows you to have confidence that your attribute (coding, pass/fail) data is accurate, so you make good decisions and prioritize your efforts in the right direction.