Get the Flash Player to see this player.
Kaizen means “improvement” in Japanese. In Japan businesses view Kaizen as a way to engage everyone in improvement without spending much money. Improvements are usually small, and overall improvement is gradual. Americans have little patience for such an approach. This podcast describes the American version of Japan’s successful approach to improving products and processes.
There are a lot of reasons that Six Sigma projects fail but they do not have to IF you can stick to the roadmap. I have done lots of projects most very successful but some have failed. In every case we stepped off of the tried and true path to success, the DMAIC roadmap. As simple and easy as these five steps seem to be, you will many times find them difficult to complete. But if that is happening, my advice to you is to “stay on the path”. Don’t skip a single step. If you stay on the path, you will find success.
So what are the five steps of this DMAIC roadmap? They are Define the issue, Measure the current state, Analyze and identify opportunities, Improve by implementing the best opportunities, and Control the new process to maintain the gains. You start every project at Define working your way through each step until you have put in place Controls to maintain your gains. What many of us do without thinking is we see a problem (Define)and go solve (improve) it. Most of the times you will find that within a year or maybe even a month or week the problem is back. What went wrong? We missed the other steps of the DMAIC roadmap. So let me spend some time talking about each step.
The objective of Define is to define the issue (problem) and the real NEED to improve it. I call this need “the burning platform”. It can not be a nice thing to do, it has to be something that will have an impact on the bottom line of the company.
The second part of the define objective is to get alignment and commitment to solve this issue from the project sponsor and the project team. It also includes the team member’s supervision. We need them committed so they will not pull the team member for priorities lower than this project.
The objective of Measure is to go as a team, to where this process is physically and factually understand the existing process. This means collect facts and data not opinions. Everyone has an opinion but few have the facts to back up the opinion. I am not discounting opinions because most folks down in the trenches (and that is where you have to go) are the experts and have excellent idea of what is happening. The thing they lack is the data to prove it. So we listen to them carefully and then collect the data to prove what is happening. Note I said happening, that is not always what the expert says. But with the facts and data we can now go back to the expert and see if they now agree with what we found. Usually they do and are surprised by the findings.
The second part of the Measure objective is to then compile that data you have collected into a characterization of the current state of the process (the baseline for your project). This will show how bad things are or are not. Most of the time things will be worse than they first thought. In some cases, you may find that things are not bad at all. Then you need to explain your results to the sponsor and if the sponsor agrees close the project. You see sometimes even sponsors opinion of what is wrong is not backed by facts and data. So when you collect them it becomes obvious that this was not an issue.
The objective of Analyze is to take the current state data and analyze it to determine the root causes of the issue. These root causes become opportunities to improve. Measure data shows you the “surface effects” or “pain” the company feels but not usually the deeper root of the issue. Because of that, you will usually find that you need to collect more data related to the measure data that validates the teams opinion of what is causing the current state issue to exist. So here in Analyze we have to take a “Deep Dive” into areas that measure pointed out as really needing improvement.
The objective of Improve is to develop and implement the best plan for improvement of the opportunities (root causes) identified in the Analyze step. There are two key phrases in this objective. “Develop the best plan” and “implement the best plan”. Develop takes some brainstorming and then some experimenting to validate that what you came up with would work. Second in develop is a plan. In the plan you will need several options so that when the time comes for getting an OK to implement it is not one or done (no action taken). Give the sponsor options to choose from but pick your best set and pitch it to them with a why it is best (remember facts and data).
The second key phrase is “implement the best plan. Whatever is picked, you need to create a detailed implementation plan. Create a time line and stick to it.
Note: this is the most forgotten step. The objective of Control is to develop and implement the best controls to maintain the gains that the new process is producing. With anything new, things never work perfect. When things go wrong, as they will, you need a plan/ controls that will guide everyone as to what to do. If you do not do this when things go wrong, those involved will revert back to what they know and have done for years. A control plan can be as simple as a log of what happened, or as complex as a statistical control chart. What ever it is it needs to help the people working the new process continue to follow it.
There is a second part to control that has nothing to do with control but has everything to do with recognition. People on and off the team have worked very hard during the project to solve the issue and to keep things going while the team has worked to solve the issue. There needs to be a celebration and rewards for everyone involved to celebrate the success and their contribution to the solution. In today’s business world, we are faster to tell folks what is wrong than what is right so make sure you celebrate your success.
This is just a quick look at the DMAIC process and has not even address questions that should be answered in each step. My plan is to write five more articles each one addressing one of the steps in the DMAIC process in more detail. If you don’t see them at this blog, you will find them at the Six Sigma Knowledge Center.
Peter Bersbach
Six Sigma Master Black Belt
Bersbach Consulting LLC
(520) 829-0090
Have you attributed your results to the right base data?
|
||||||||||||||||
A Black Belt steps up to the plate with Six Sigma confidence.
 |
|||||
|
The theory of constraints helps pick winning projects.
 |
||||||
|
Six Sigma teaches us to view everything as a process. We should take an objective look at the system, measure the values, form a model, enact changes on the process, and observe the effects of these changes. However, we sometimes want to measure objectively something that is intrinsically subjective, the opinions of people. These fall under the category of what I like to call “Human Metrics.” Some common examples of these metrics are customer satisfaction, perception of quality, and ease of use. How do we accurately measure these values?
Surveys are regularly used as the catchall for human metrics. This has several flaws, though. First, people are not consistent graders, and a 7/10 for one person may be an 8/10 for another. Ultimately, though, this is not a problem because it represents the same sort of variation you will see in any measurement. The second problem is self-selection of responders. This is well documented, and can create extreme disparities between real and actual numbers. A good example of this can be found with call-in surveys. In many cases, only those with a chip on their shoulder will be compelled to call, creating a clearly biased sample. To counter this, sometimes incentives are offered to get a higher response rate, but this brings us to the third problem with surveys, non-response. Where some people may choose to simply not respond to a survey, others will purposely subvert the survey itself by ignoring the questions and answering in some sort of pattern. This is common with incentives, like contests for surveys, because it is so easy to simply hit the number one repeatedly without hearing the questions being asked. It can be hard to pick out this group, and one can only hope that over the long term the collective contributions of these unresponders will balance each other out.
How do you deal with these problems? A common solution is to try to address and eliminate the issues inherent to surveys. Select the sample by hand, normalize the scores across respondents, and remove surveys with obvious patterns or very unusual scoring habits. Ultimately though, even if these methods were perfect at eliminating their respective flaws, you would still be left with the fact that people are bad judges of their own opinions. Thus, you cannot use the responses to predict future behavior. This brings us to the best method for retrieving human metrics, using a proxy.
Measurement by proxy is a method that has existed for millennia. If you know the angle of the sun, you can measure the height of a flagpole by measuring the length of its shadow. You can apply this to human metrics and find values from behaviors that reflect certain opinions. Often, these are the values you care about most. Repeat sales, for example, is a good measurement of customer satisfaction. However, while repeat sales a metric that you can find using existing data, some require testing. For example, if you want a metric for ease of use, then you can look at the time taken to use the product. To test this, one might take a group of people with little or no familiarity with a product and ask them to use it. The time taken does not exactly demonstrate ease of use, but the two are related enough to make this a reasonable proxy in certain situations.
That is not to say that surveys cannot be useful, or don’t have a place. Simply put, they are very easy to implement, and consistent surveys allow the tracking of trends in user opinions. Additionally, measurement by proxy is far from perfect. Other factors in your system can seep into your measurement and taint the values. For example, the number of repeat sales may be artificially increased by having a product with a short lifespan. Naturally, the short lifespan is bad for customer satisfaction, but the proxy would insist otherwise.
In conclusion, as a Six Sigma expert, you should look to be quantitative in your assessment of systems. Human metrics are no exception to this rule. You cannot abandon the Six Sigma philosophy just because “Everyone is different.” Instead, look to measure how they are different.
Unit yields are a misunderstood tradition.
 |
|||||
|
Statistical probability should be used only when we lack knowledge of the situation and cannot obtain it at a reasonable cost.
I recently attended a presentation using a control chart. The control chart showed a process in statistical control at about an 8-percent reject rate. The presenter noted that the process was stable and went on with her presentation. I barely avoided shouting that, while stability is nice, an 8-percent reject rate is not acceptable. The 8-percent level represents a certain amount of ignorance about the process; a level I find unacceptable. The problem is that the presenter didn’t think of it that way at all. To her, 8 percent represented a considerable accomplishment.
This blog is for those of you who, like me, want to scream that, as long as improvement is economically justified, “It’s never good enough!” I will present a way of measuring ignorance; a simple-to-compute statistic which highlights the fact that there is always something to learn about how to improve a given process.
First, let’s take a look at the philosophy that underlies statistics. In his book, The Art of Thinking, philosopher Leonard Peikoff wrote, “Statistics are applicable only when: 1. You are unavoidably ignorant about a given concrete; 2. Some action is necessary and cannot be deferred.”
In other words, if you’re trying to determine a course of action, your best bet is to acquire knowledge, not to blindly use statistics to guide you. While it’s true that we don’t want to tamper with a stable process, it’s also true that we don’t want to settle for anything other than the best level of quality we can provide. Control charts guide us away from tampering, but they don’t tell us how we can improve the process. Only new knowledge can do that.
Statistical probability should be used only when we lack knowledge of the situation and cannot obtain it at a reasonable cost. If we have direct knowledge about a situation, or can get it through a bit of research or by consulting someone who has it, then we should not blindly follow the statistical probabilities. In other words, if you know something about the situation, you should act on what you know.
Statistics are an expression of ignorance. They should only be used when ignorance is unavoidable, i.e., when knowledge is absent and unobtainable. Statistics are not knowledge. They are a calculation that permits action in the face of ignorance. This is the critical point missed by the presenter. She assumed that if she simply stated the level of ignorance, further improvement was not necessary.
Properly used, statistics measure ignorance or, conversely, knowledge. For example, assume that you want to buy a new piece of production machinery. Think of the important variables in the process as a list of 100 items, all of them unknown. You begin by creating a list of those items you believe to be important and prepare a plan to control as many of these items as possible. Let’s say you start with 75 items. Assuming that every item on your list is actually an important variable, these 75 items are special causes–things that affect your process and must be controlled. The remaining 25 items are common causes of variation, unknown to you but also important causes of process variability even though any one of these causes will have only a small effect.
From this starting point, you conduct a process capability study and, using statistics, quantify your knowledge as explaining all but +/-0.003″ of variation in the process. There are some out-of-control data points. After investigating these, you identify five more important variables. The process stabilizes, i.e., all of the remaining points on the control chart fall within the control limits.
Let’s assume that the control limits for the X-chart are now +/-0.002″. In philosophical terms, this means that you acquired +/-0.001″ of new knowledge, but +/-0.002″ of ignorance still remains. As time goes by and you learn more, the control limits will measure the amount of your learning. If in a year the control limits are at +/-0.001″, then you’ve learned enough to reduce the process variation by 50 percent.
As soon as you acquire this knowledge, the previous statistics become irrelevant. Gaining knowledge is the equivalent of converting special causes into common causes. This is like discovering more and more items on the list of things that cause your process to vary. You may never discover every item on the list, but with statistics to help you keep score, it’s fun to try. One way to make it even more fun is to plot a “knowledge chart.” Here’s how it works:
Record the process standard deviation from your most recent process control chart, for example, S0 = 10.
For each subsequent complete control chart, compute the process standard deviation, for example, s1 = 9.
Compute your relative knowledge,
k, as K=100% x (S0-S1)/S0
For our example, K= 100% x (10-9)/10 = 10%
As you reduce your ignorance to zero, the knowledge measure will go to 100 percent. It’s a fun way to keep track of your quality progress!
To many quality engineers and managers, process capability is a jumbled confusion of ideas expressed in jargon that only the anointed can understand.
Imagine the following scene. The boss rushes into the quality director’s office. He’s obviously distraught.
(Boss enters, walking quickly from stage right.)
Boss: “Jane, we’ve got a serious problem. Our biggest customer just called. Their assembly line is shut down because the last batch of XYZ-50’s that we shipped won’t fit into their assembly fixtures. What happened?”
(Jane, sitting at her desk, puts down her pen and looks up at her boss. She shakes her head in dismay.)
Jane: “I knew this would happen sooner or later, boss. The problem is that our customer requires us to provide a Cpk of 1.33 or higher. But the formula they make us use assumes normality, and the XYZ-50 has a skewed distribution. If we center the process to maximize Cpk, then the tail area extends beyond the specification limit .”
(Boss exits, stage right, shaking his head and wearing a puzzled expression.)
I fear that when the quality profession talks about process capability, this is how we sound to others. To many quality engineers and managers, process capability is a jumbled confusion of ideas expressed in jargon that only the anointed can understand. Let me try to clear the air on the subject.
Process capability is about one thing, and one thing only: quality. It answers the simple question, “Can you meet my requirements?” Ideally the customer would like a simple answer, yes or no. Unfortunately, this is not possible due to one or more of the following:
Inspection is not perfect; even 100-percent inspection won’t guarantee 100-percent quality. Explaining this becomes complicated.
All processes vary, and the variation must be analyzed using statistical methods that always predict at least an occasional failure. The statistics virtually always get complicated.
Measurement isn’t perfect, so even if a process did have zero variation, our measurements would still vary. This means that we might accidentally ship a defective item even if we measure it carefully. Not only that, our measurements of a particular item might be somewhat different from our customer’s measurements. Explaining how two trained people using the same type of instruments can check the same item and get different results can get complicated.
We or our customer might not properly understand the requirements. Human communication is always complicated.
Yet it’s really not complicated at all. In fact, the customer’s question can be answered easily, and the answer is: no. For all of the reasons listed, and many more, we cannot guarantee that we will always deliver a product or service that meets the customer’s requirements as understood by the customer.
So, now what? The best approach is also the most radical: Be honest. Tell customers about how many items they are likely to receive, on average, that will not meet the requirements. This cuts right to the heart of the matter. It tells customers what they want to know. It works for variables data and attributes data. If control charts are being used, the estimate can be obtained directly from the process average (for attributes data) or the process average and standard deviation (for variables data). The count can be adjusted to include sorting operations, inspection error, measurement error and all of the other factors that influence what the customer receives.
If our process is extremely good, we can tell the customer that, while we can’t guarantee perfection, we can provide quality in the near-perfect range. One good way of quantifying this is to use parts-per-million quality statements. For example: “Our return rate on this item is three returns per million items in service per year.” Most people can easily understand this statement. A customer ordering up to several thousand items will probably, and accurately, interpret this to mean “zero defects.”
If our process is less capable, stating the expected number of defective items that the customer will receive might result in a shock to both the employees and the customer. This may provide the incentive needed to improve quality.
High-volume production is another area where stating process capability as expected defectives can provide insights. A defect rate of 1/10 percent sounds pretty good. But a can line may produce in excess of 1,000 cans per minute, so a reject rate of 1/10 percent would result in the production of 1,440 defective cans per day. If the defect is major, say a leaking can that could damage many cases of product in a warehouse or truck, even a defective rate of one in a million might not be acceptable; it would result in several serious problems each week. For such processes, parts per billion quality may be required.
If a process is not in statistical control for unknown reasons, there is no way to state the process capability with any degree of precision. The best option is to tell the customer what the expected defectives will be (based on the historical data) and hope for the best.
The key to good customer relations is clear communication. The easiest way to get the point across is to tell the customer what level of product or service quality to expect, using plain language.
The quality profession must focus on things done right.
In the February issue of Quality Digest, Joseph M. Juran pointed out that quality needs to “scale up” if it is to remain a viable force in the next century. In other words, quality must spread beyond its traditional manufacturing base.
A major opportunity to do just that now exists, as Six Sigma enjoys a resurgence of interest among quality professionals and “data mining” is the hot topic among information systems professionals. Six Sigma involves getting 10-fold improvements in quality very quickly; data mining uses the corporate data warehouse, the institutional “memory,” to obtain information that can help improve business performance.
The two approaches complement each other, but have differences as well. Data mining is a vaguely defined approach for extracting information from large amounts of data. This contrasts with the usual small data set analysis performed by quality engineers and statisticians. Data mining also tends to use automatic or semiautomatic means to explore and analyze the data. Again, this contrasts with traditional hands-on quality applications, such as control charts maintained by machine operators. Data mining for quality corresponds more closely with what Taguchi described as “off line” quality analysis. The idea is to tap into the vast warehouses of quality data kept by most businesses to find hidden treasures. The discovered patterns, combined with business process know-how, help find ways to do things better.
Data-mining techniques tend to be more advanced than simple SPC tools. Online analytic processing and data mining complement one another. Online analytic processing is a presentation tool that facilitates ad hoc knowledge discovery, usually from large databases. Whereas data mining often requires a high level of technical training in computers and statistical analysis, OLAP can be applied by just about anyone with a minimal amount of training.
Despite these differences, both data mining and OLAP belong in the quality professional’s tool kit. Many quality tools, such as histograms, Pareto diagrams and scatter plots, already fit under the information systems banner of OLAP. Advanced quality and reliability analysis methods, such as design of experiments and survival analysis, fit nicely under the data mining heading. Quality professionals should take advantage of the opportunity to share ideas with their colleagues in the information systems area.
Example: A bank wants to know more about its customers. It will start by studying how long customers stay with the bank. This is a first step in learning how to provide services that will keep customers longer.
This should be considered a quality study. The quality profession tends to focus too much on things gone wrong in identifying failures, then looking for ways to fail less. An alternative is to examine things done right, then look for new ways to do things that customers will like even better. This proactive, positive approach is a key to quality scale-up and a ticket into an organization’s mainstream operations.
This bank’s baseline study can also be viewed in the traditional failure-focused sense of quality. If customer attrition is viewed as “failure,” a host of quality techniques can be used on the problem at once. In particular, reliability engineering methods would seem to apply. If we look at creating a new account as a “birth” and losing an account as a “death,” the problem becomes a classic birth-and-death process perfectly suited to reliability analysis. Rather than using a traditional reliability engineering method like Weibull analysis, the following example uses a method from health care known as Kaplan-Meier survival analysis.
Survival analysis studies the time to occurrence of a critical event, such as a death or, in our case, a terminated customer account. The time until the customer leaves is the survival time. Kaplan-Meier analysis allows analysis of accounts opened by customers at any time during the period studied and can include accounts that remain open when the analysis is conducted. Accounts that remain open are known as censored because the actual time at which the critical event (closing the account) occurs is unknown or hidden from us.
Table 1 shows the first few database records (customer names are coded for confidentiality.) The database of 20,000+ records is large by traditional quality standards, but tiny by data-mining standards. The bank manager wishes to evaluate customer accounts’ lifespan. She also suspects that customers who use the bank’s Web banking service are more loyal. Figure 1 shows the survival chart for that data set.
The information confirms the branch manager’s suspicion: Web users clearly stick around much longer than nonusers. However, the chart doesn’t tell us why they do. For example, Web users may be more sophisticated and better able to use the bank’s services without “hand holding.” Or there may be demographic differences between Web and non-Web users. The data was also stratified by the customer’s city, revealing many more interesting patterns and raising more questions.
An obvious question is what the bank might do to improve the overall retention rate; after all, nearly 70 percent of the customers left within 1,400 days of opening their account and, from a quality viewpoint, what “defect” could possibly be more serious than a customer leaving your business?
Quality and reliability professionals already have a full arsenal of tools and techniques for extracting information from data and knowledge from information. Long before information systems became popular, data helped guide continuous improvement and corrective action. Today, organizations are having an extremely difficult time finding qualified people to help them deal with the deluge of information. It’s time we let people in the nontraditional areas of the organization know that they have an underutilized resource right under their noses: the quality and reliability professional.
Be trained by Thomas Pyzdek
Black Belt
Green Belt
Resources for Six Sigma |
|
Introduction to Six Sigma |
Six Sigma Projects |
Six Sigma Tools |
Six Sigma Statistics |
Six Sigma Videos (Requires QuickTime) |
Leading Six Sigma |
Healthcare Quality |
Process Excellence Podcasts |
Other Useful LinksGood books on Six Sigma and other topics |
|
|
|
