Archive for the ‘Statistical Tools for Six Sigma’ Category

Six Sigma, Data Mining and Dead Customer Accounts

Monday, June 8th, 2009

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.

GD Star Rating
loading...

Thinking Outside the Box

Sunday, June 7th, 2009

The “P” in SPC stands for process, not product.

A common problem with SPC is that the world appears too complicated for a statistical approach to work. In complex electronics products, for example, circuit boards may have thousands of holes and microchips may have millions of transistors. Plotting control charts of each and every dimension is clearly not feasible. What can be done?

To answer this question, consider a simple product: the box in Figure 1. How many things could we measure on this box? It turns out, a great many. Length, width and height are obvious choices. But we could also measure the diagonals on all six sides, interior diagonals front-to-back and back-to-front, linear combinations of these measurements and a great many more. We could conceivably come up with dozens of measurements on this simple box.

But–and this is critical–we don’t need these measurements to control the box process. The “P” in SPC stands for process, not product. When we focus on the product, we lose sight of the fact that we’re not trying to control the product. Control of the box process may be a great deal more simple than controlling the product. And if we control the process properly, the product will take care of itself.

The statistical technique known as principle components analysis can help us determine just what is important and what is not. Most statistical software packages can perform PCA. To illustrate the approach, I measured an assortment of boxes (see figure 2). The measurements I obtained are shown (in inches) in Table 1.

When these data are crunched through PCA, we find that three principle components explain 99 percent of the variation in the data set: Component No. 1 explains 76.9 percent of the variation, component No. 2 explains 14.1 percent, and component No. 3 explains 8 percent. The PCA clearly shows that these three components are associated with A, B and C respectively. Thus, the “box process” can be characterized almost entirely by controlling these three characteristics. If we do that, the other dimensions will be OK, too.

When these data are crunched through PCA, we find that three principle components explain 99 percent of the variation in the data set: Component No. 1 explains 76.9 percent of the variation, component No. 2 explains 14.1 percent, and component No. 3 explains 8 percent. The PCA clearly shows that these three components are associated with A, B and C respectively. Thus, the “box process” can be characterized almost entirely by controlling these three characteristics. If we do that, the other dimensions will be OK, too.

An example of using this approach in the real world involves CNC machining. A defense plant machined parts for use in guided missiles. The parts were extremely complex, with thousands of holes, cutouts, etc. on each. However, when the data were analyzed using PCA, it was determined that four principle components accounted for nearly all of the process variation. Further study showed which measurements were correlated with each principle component.

From this, the engineers determined that, for all the apparent complexity, the machining process was, in fact, quite simple. The four principle components corresponded with the machining center’s four axes of movement: X, Y and Z movement of the bed, and the rotation of the table on which the parts were mounted. SPC could be accomplished by selecting those features most difficult to position in each axis of movement. Often, a single feature could measure more than one axis; for example, a hole furthest from the “home” position in both the X and Y axes. The result: One or two control charts suffice for the control of a process placing thousands of features.

Note that the features selected for SPC may be of little or no importance to the product itself. In fact, some parts were designed with “process control features” that were later removed from the part entirely. This makes sense when remembering that P stands for process, not product. If you keep that in mind, the complexity you face might just evaporate before your eyes.

GD Star Rating
loading...

Preventing Hospital Falls

Friday, June 5th, 2009

Hospital processes produce many things. Most of them are desirable outcomes, such as healthy newborn babies, new hip joints, cancer-free patients and blood flowing freely through once-blocked coronary arteries. In other words, happy, healthy and satisfied patients. These results are why health care professionals chose their field. They generate revenue that patients are happy to pay because the value they receive exceeds the cost.

But not all of the things hospitals produce are desirable. Hospitals also produce botched surgeries, surgical sponges sutured into patients, X-rays that must be taken repeatedly, falls, infections and many other unwelcome errors. These things also result from hospital processes, but because they are not part of the planned outcome, we tend to overlook the fact that they, too, are caused. Instead, many health care professionals look upon these poor results as unfortunate occurrences that appear without cause. Of course, they tend to accept these events as inevitable, which in turn assures continual recurrence.

The quality profession’s major contribution to the world is the ability to scientifically investigate process variation. This helps people see which outcomes, pleasant and unpleasant, are created by the system itself, and which are created by factors outside the system. Armed with this knowledge, workers can determine which action will most likely improve the process. Improvement can be an increase in the desired outcome, a decrease in undesired outcomes, improved efficiency or any combination of these. The approach is generic. It can–and has been–applied to improving health care processes. Let’s look at an example.

Falls. As I waited outside my father’s hospital room for him to finish dressing to come home, I heard a noise. The sound was distinctive: a body hitting the hard floor. I rushed in, a nurse close at my heels. My father’s elderly roommate lay on the floor, embarrassed as he tried to stand. The nurse and I helped him to his feet.

“I’m OK,” he assured us. “I leaned on the table, but it rolled and I fell.” He pointed to the small cabinet between the two beds. The nurse nodded as she guided him to the chair.

“That happens all the time,” the nurse responded. “They should replace those darned tables. They’re on rollers to make it easier to move them for patient access and cleaning of the room, but they cause a lot of accidents.”

Luckily, only the gentleman’s pride was hurt. But as I continued to wait for my father, I took note of the fact that the nurse continued with her rounds. If she ever reported the event, it was long after it occurred. Chances are it was never reported.

Later that day, I phoned the hospital and asked if they kept data on falls. “Of course,” I was told. “Hospitals re-cord everything.”

Not quite everything, I thought to myself as I recalled the event earlier that day. Probably anything that caused an injury. Only part of the story, but worth looking at in any event. The hospital faxed me the data on falls (see Table 1).

All organizations keep such data. However, it’s in a form that’s seldom used. The data contains information, but not in a format that people can easily interpret. To help us glean some knowledge from this data, let’s consider three statistical process control tools: the histogram, run chart and control chart.

A histogram shows the empirical distribution of the falls data. It would show that the number of falls reported each month varies from zero to six, with four falls per month being the most common. The number of falls appears to be fairly consistent; no months contain a great number of falls.

Where the histogram is a snapshot, the run chart is a movie. In Figure 1 we see the falls data stretched out over time. Applying statistical tests produces no significant data patterns. The run chart helps put the data in a context, which helps prevent misconceptions caused by looking only at a portion of the data.

While run charts allow us to examine patterns, they are less helpful in analyzing outliers or freak values. Control charts provide control limits that help do this. Creating a control chart of the falls data requires first determining the number of patient care days (PCDs) for the hospital each month. After all, one way to reduce falls to zero is to admit no patients! The U chart in Figure 2 shows reported falls per 100 PCDs. It also includes a centerline showing the process average and an upper control limit on the number of falls per 1,000 PCDs. Note that the UCL rises and falls as the number of PCDs changes.

The control chart shows that the rate of falls is “in control.” This means that if nothing is done each month, the hospital can expect to average about two serious falls per 100 PCDs. Some months no people will fall and hurt themselves, other months a half-dozen or more injuries might occur. That is, unless someone takes the time to look into the reasons why people fall. When management decides to do that, a whole host of techniques can be brought to bear on the problem, such as cause-and-effect diagrams and Pareto analysis.

And maybe, just maybe, those darned tables will be replaced!

GD Star Rating
loading...

When in Doubt, Get the X-Chart Out!

Thursday, May 7th, 2009

Phil looked at the data Joan had just handed him.  Joan was a recent graduate of an SPC seminar the company had sponsored for administrative personnel and, since Phil had been the Quality Engineer who taught the classes, it was only natural that she would seek his help.  She was trying her best to follow Phil’s advice of applying what she had learned to something important to her.

“The numbers are the percentage of invoices sent out that contain errors.”  Joan explained.

Phil nodded his head and took a graphic out of his desk drawer and showed it to Joan (figure 1).  “Remember this?” He asked.

“Sure,”  Joan replied.  “It’s the decision tree for finding out which control chart to use.”

Control chart decision tree

Control chart decision tree

Phil smiled and nodded.  He liked teaching and found it especially rewarding when bright students like Joan were able to apply what they had learned.

“But it doesn’t work for my data.”  Joan went on.

Phil’s smile faded.  “What do you mean it doesn’t work?  It has to work.”  He turned the paper towards her.  “Here, let me show you.”

He placed his finger on the dot at the left of the chart.  “Are we dealing with measurements or counts?”  He asked.

“Counts.”  Joan responded confidently.  “They count the number of invoices with errors.”

Phil ran his finger along the line labeled count until it reached the next dot.  “Okay, are we counting pieces or units, or are we counting occurrences?”

“Pieces or units.  They count invoices, which are pieces of paper.”

“And the last question is:  does the sample size stay the same, or does it vary?”

“It varies.  Every month a different number of invoices are processed.”  Joan said.

“Then the correct chart is the P chart.”  Phil said, tapping his finger on the graphic with an air of finality.

“Right.  That’s what I came up with.”  Joan said.  “But it doesn’t work.”

Phil looked perplexed.  “Of course it works.  Maybe you’re having trouble because it’s your first real control chart.  I’ll help you construct it.  Where are the data?”

Joan pointed to the sheet of paper she’d brought him.

“No, I need the raw data.  All this shows is the percentages computed from the raw data.”  Phil said.

Table 2

Table 2

“That’s the problem, I don’t have it.”  Joan explained.  “All the sales offices send me are the percentages.  They don’t even keep the raw numbers.”

***

The problem is common.  The solution is, of course, to collect data in the proper format.  However, this may mean starting from scratch, changing habits firmly rooted in past behavior, expensive training, etc.  And it may take months to get enough data to establish valid control limits.  These obstacles are often enough to cause people to abandon control charts entirely.  Is there nothing Phil and Joan can do?

Fortunately, there is a solution: the X-chart, also known as the individuals chart or X and Moving Range chart.  Of course, the X-chart chart is recommended when plotting measurement data from “subgroups” of size 1.  But it is much more versatile.  The X-chart  is the Swiss Army Knife of control charts.  It can be shown that under the assumptions of statistical control and constant sample size, the central limit theorem can be used to show that the other control charts are mathematically related to the X-chart.  Better still, under conditions frequently encountered in practice, X-charts can be used to plot percentages, ratios, counts, and other non-measurement data even when the assumptions are only approximately met.

Real-World Example

Assume that Joan has the number of invoices and errors shown in Table 1.

Table 1

Table 1

Figures 2 and 3 show, respectively, the p-chart and the x-chart for these data.  The x-chart was created by using the percentages as if they were measurements.  It is obvious that the conclusions are the same with either chart: the process is in statistical control.  Table 2 shows that the numbers calculated from the data are close too.

P-Chart

P-Chart

In other words, if all that are available are the percentages, the X-chart provides an excellent approximation to the P-chart.  The same conclusion applies to data for the np chart, c chart, u chart, sigma chart, etc.  In all of these cases, and more, the Swiss Army Knife of control charts gets the process operator focused on data. One could even argue that the simplicity of using a single chart instead of several charts outweighs the mathematical advantages in many cases.  So when in doubt, get the x-chart out.

GD Star Rating
loading...

Statistics—The Good, the Bad and the Ugly

Friday, April 3rd, 2009

The quality and process improvement professions tend to rely heavily on statistical information. The very science of quality control can be said to have begun with Walter A. Shewhart’s development of the control chart and discovery of the concepts of special cause and common cause variation. And where would Six Sigma be without statistics? But few would argue with the statement that there is a downside, and a dark side, to statistics. I’ll present a few examples of good, bad, and ugly uses of statistics.

The Good

There’s no shortage of words describing the benefits to be derived from using statistics. Statistical texts describe the advantages of using statistical methods at great length; I’ve contributed a page or two myself. Statistics can force us to look at data and facts, rather than relying on opinions and letting strong personalities force their beliefs on others. Statistical thinking uses data to separate variation from special causes and variation from common causes, thereby aiding decision making and learning. Statistics help us test our beliefs and to learn from experience. Statistics are the bridge between raw data and knowledge and understanding. They provide the means by which we can test our theoretical models of reality and learn from them. When statistical analysis fails to confirm our initial hypothesis we are forced to re-evaluate the hypothesis, which leads to improved understanding. Even if statistical analysis confirms our beliefs, we gain insight through the rigor it provides.

Statistical analysis is especially useful when we are faced with complex situations that challenge human understanding. Even two-dimensional problems can become too complex to understand completely without statistical tools. Response surface analysis tells us about optimum process settings, and explains what will happen if the settings are not precisely controlled. Problems of higher dimension are often beyond us unless we break out our statistical tool kit to study the situation. For example, it helps the call center manager understand how contact resolution, waiting time, agent professionalism, and the phone menu combine to create customers who return to buy more, or customers who abandon you and tell their friends to stay away.
Graphics are a useful and necessary tool, but statistics can often enhance our graphical analysis. For example, if a bar chart is created for some metric, there will almost certainly be bars of different heights. But it takes statistics to tell us if the differences are meaningful or merely misleading. Sometimes the graphics are actually graphs of statistics. These uses, and many, many others, are examples of good statistics.

The Bad

Statistics are numbers. Numbers can not provide a complete picture of anything. They are an abstraction of reality and, because of this, they are not the reality itself. No amount of measurement and quantification can capture any real thing to any significant degree. People often forget this simple fact and begin to think of customers and employees as revenue or cost sources, complaints, or something other than the complete human beings that they are. In this sense, anything that uses numbers represents a potential barrier to understanding the reality being studied.

Statistics are worse than raw numbers. They reduce the numbers themselves into a smaller quantity of numbers. A mean (or any other statistic) is a single number that may represent thousands of individual measurements. There is no possible way that statistics can fail to lose some of the information contained in the original measurements.

Statistics trap us into analysis paralysis. No amount of statistical analysis can ever produce certainty. There is always a probability that our conclusions will be incorrect. This is unavoidable, but some people have real problems dealing with it. Instead of accepting the uncertainty and acting anyway, they gather more data or apply more analysis to the data they already have. I’ve seen Six Sigma Black Belts who can’t be pried out of the Analyze phase with a crowbar.

Statistics are confusing. The aim may be to use statistics to clarify, but many people find statistics to be very confusing. Even technically adept scientists and engineers sometimes have difficulty. For example, try explaining what it means to have a range chart that shows statistical control to a layperson. “The process variability is consistent” doesn’t immediately make sense to most people. More complicated methods require intensive study and a good deal of hands-on experience to understand.

Statistics are often used without graphics. The first three rules of data analysis may be:

  1. Plot the data
  2. Plot the data
  3. Plot the data

but take a look at nearly any scientific paper and you’re likely to find the results of statistical analysis presented in tables and words rather than in charts. Presenting the results of statistical analysis in numbers rather than in pictures is bad practice.

The Ugly

“There are three kinds of lies: lies, damned lies, and statistics.”

The statement, attributed to Benjamin Disraeli, refers to the persuasive power of numbers, the use of statistics to bolster weak arguments, and the tendency of people to disparage statistics that do not support their positions. The deliberate misuse of statistics is an ugly fact of life. One can pick up a newspaper on any given day and find ugly statistical abuse. But it goes beyond attempting to deceive others. People have a tendency to overlook or ignore statistics that contradict their own beliefs, even when there is no one but themselves involved. Statistics are often used by data bullies to pummel their opposition. And statistical experts often aren’t.

Your Input

Do you have examples or stories of good, bad, and ugly statistical usage? I’d really like to hear about them. Please provide your comments.

GD Star Rating
loading...

Does Normality Really Matter in ANOVA?

Tuesday, March 31st, 2009

I had a spirited discussion with a statistician earlier today on the subject of the normality assumption for one-way ANOVA. In the end, we both agreed that normality of the response variable doesn’t usually matter much, despite the fact that it is an assumption that is usually tested. The truth is, it takes a pretty radical departure from normality to make much of a difference in the p-value. And this departure has to be a particular kind of departure, namely skewness. Tails that are heavier or lighter than normal don’t make much difference if symmetry is maintained.

But I teach my students to test normality anyway. For one thing, many of my students go on to take certification exams or are enrolled in college courses. Since normality is one of the underlying assumptions of the F-test, it is technically a requirement and therefore one must teach it. However, after teaching that normality should be tested, I tell my students that departures from normality can often be handled by ignoring them, if they are not too great.

One thing I hadn’t considered was that I have been doing normality testing for all of the responses grouped together. My friend pointed out that if the treatment groups had different means this approach would result in failing the normality test, even though the within-treatment distribution might be normal. Fair enough, but we are proceeding on a null hypothesis that the treatment means are equal. Still, I’ll concede her this point and from here forward I’ll teach that when testing the normality of responses, one should look at the treatments separately.

Of course, normality of the residuals is another matter entirely. Here we do require normality and we treat departures from normality as a signal that our model needs to be improved. But when it comes to the normality of the responses, you can usually ignore it (in the real Six Sigma world,) or just remember it until you pass that exam.

GD Star Rating
loading...

Measurement Error Kills Macho B

Tuesday, March 31st, 2009

If you live in Arizona, you’ve probably heard of Macho B. Macho B was believed to be the last surviving jaguar in North America. Southern Arizona is at the extreme northern boundary of the jaguar’s range and it was believed that no jaguars remained north of the United States border with Mexico. However, a snare set for a research tracking project tracking the movements of mountain lions and bears accidentally snared Macho B. Now one might wonder why officials didn’t simply let Macho B go, but that’s another story (and a long one.)

Macho B

It came to pass that Macho B ended up at the Phoenix Zoo. While there, zoo veterinarians tested him for kidney failures via a blood test. The test was positive and Macho B was euthanized. However, a pathologist at the University of Arizona’s Veterinary diagnostic Laboratory reviewed the tissue sample and concluded that Macho B’s test results could have actually indicated dehydration. The pathologist, Sharon Dial, said it is unproven dogma among some medical experts that blood levels alone can be used to “make a definitive statement that this animal will not survive.” Dial disagreed. “…I can say by looking at the kidneys that there is no structural reason why he would not have [survived]…For a supposed 15 year old cat, he had damned good looking kidneys.”

So, was Macho B doomed to a slow death due to kidney failure? Or did he have kidneys any 15 year old jaguar could be proud of? It’s a question of measurement variation, specifically reproducibility error. In Six Sigma work we are faced with such questions every day. So are others, although they may not know it until it’s too late to matter.

<strong>Macho B Update</strong>

PHOENIX – The Arizona Game and Fish Department yesterday formally placed one of its employees on administrative leave with pay as a result of an interim finding in the department’s ongoing internal administrative investigation into the events surrounding last year’s capture of the jaguar known as Macho B. The department took this action based on statements made by the employee during the course of the internal investigation, bringing about a need to consider taking administrative action to resolve concerns raised by the statements.

Under state personnel rules, placing an employee on paid administrative leave relieves the employee of duties, pending a determination on what final administrative action may be taken.

Department officials said the employee’s statements were related to the employee’s actions taken several weeks after the capture, recapture and euthanization of Macho B. The department continues to maintain that it did not direct any department employee to capture a jaguar, and that the department’s actions related to the capture were lawful.

Department officials added that the Game and Fish internal investigation cannot be considered completed until the department has an opportunity to review whatever findings may come out of a concurrent federal investigation being conducted by the U.S. Fish & Wildlife Service.

Information about events related to Macho B can be found here.

<strong>Game and Fish dismisses employee involved in jaguar capture</strong>

March 19, 2010

HOENIX – The Arizona Game and Fish Department today dismissed one of its employees as a result of the department’s ongoing internal administrative investigation into the events surrounding last year’s capture of the jaguar known as Macho B.

Dismissed was Thornton W. Smith, 40, a wildlife technician for 12 years with the department and one of the field biologists involved in the placement and monitoring of traps used in a black bear and mountain lion research project that resulted in the initial capture of Macho B.

The department dismissed Smith based on the employee’s own interview statements made during the course of the internal investigation. The statements related to Smith’s conduct that occurred several weeks after the capture, recapture and euthanizing of Macho B.

Smith’s statements and further investigation confirmed that he did not comply with verbal and written directions issued by supervisors and that he admitted to knowingly misleading federal investigators regarding facts surrounding the original capture of Macho B.

The department’s official letter that documents the grounds for dismissal was delivered to Smith earlier today.

GD Star Rating
loading...

What the Heck is Multicollinearity?

Friday, March 6th, 2009

A Master Black Belt was perplexed by the software’s correlation and regression analysis output. The results were pure nonsense. In addition to regression coefficients that were negative when common sense told him they should be positive (and vice versa), some of the correlation coefficients were large, while the corresponding regression coefficient p-values were insignificant. What the heck was going on?

The problem with the Master Black Belt’s data was multicollinearity, a condition that’s encountered more often as Six Sigma practitioners move from engineering and manufacturing data to customer survey data.

Multicollinearity refers to linear intercorrelation among variables. Simply put, if nominally “different” measures actually quantify the same phenomenon to a significant degree–i.e., the variables are accorded different names and perhaps employ different numeric measurement scales but correlate highly with each other–they’re redundant.

Multicollinearity isn’t well understood by the applied statistics community. Re–searchers at Arizona State University found widespread misunderstanding of multicollinearity and other regression analysis concepts among graduate students who had taken, on average, five graduate and undergraduate statistics courses. I’ll try to explain multicollinearity by using a simple, everyday metaphor: a table.

Consider the photograph of a table shown in figure 1. This is a finely built table I purchased at Wal-Mart for only $99 (chairs were included). In my metaphor, the table is a model. The legs of the table represent x variables, or predictors. The top represents the y variable, the predicted variable. My intent is to build a table where the top is well supported by the legs, i.e., the predictions are well explained by the predictors.

The table legs are placed at 90° to each other. This angle provides maximum support for the top. In statistics, when two variables are uncorrelated with each other, they’re said to be orthogonal, or at 90° to one another. If you create a scatter diagram of two uncorrelated variables and draw best-fit lines, you get something that looks like figure 2: The lines are at 90° to one another.

Consider the two x variables to be the legs of the table, the circle to be the table top and the dots to be objects on the table’s surface. You can see that the x variables do a good job of “supporting” the y variable. If you add a few dots anywhere within the circle they’re unlikely to make the table tip over. In other words, the model is stable.

What if the table wasn’t built with the legs at 90°? Clearly, it wouldn’t be as stable. The statistical equivalent to this poorly designed table is shown in figure 3. The lines no longer cross each other at 90° because the two x’s are correlated with one another. There are areas within the circle (i.e., our y model and the equivalent of the table top) that aren’t well explained by the model. If we take additional samples and get y’s in either of these regions, the coefficients of the model will change drastically, i.e., the model, like the table, will be unstable. This is the multicollinearity problem in a nutshell.

Using our table metaphor, we can see that regression models are more stable when the x’s used to predict the y are uncorrelated with one another. If the x’s are correlated, there are a number of statistical techniques that can be used to address the problem. When many x’s are involved, I like to use principal components analysis, which replaces many correlated variables with a smaller number of uncorrelated factors. This not only overcomes the problem of multicollinearity, it usually also makes the model easier to understand and use.

GD Star Rating
loading...

Virtual DOE, Data Mining and Artificial Neural Networks

Friday, March 6th, 2009

A key feature of Six Sigma is the integrated use of design of experiments and robust design of product and process. Experiments are an important part of this; they serve both to find the most robust design settings and to verify that the designs are, in fact, robust.

As beneficial and productive as experiments can be, the process of conducting them has its drawbacks. The workplace — be it a factory, a retail establishment or an office — revolves around a routine. The routine is the “real work” that must be done to generate the sales that, in turn, produce the revenues which keep the enterprise in existence. Experimenting, by its very nature, means disrupting the routine. Important things are changed to determine what effect they have on various important metrics. Often, these effects are unpleasant; that’s why they weren’t changed in the first place. The routine was established to steer a comfortable course that avoids the disruption and waste that results from making changes.

Unless we change, however, we can never improve. Six Sigma generates as much improvement by changing things as it does by reducing variability. It’s part of the Six Sigma paradox, which states that to reduce variability in products and processes, we must encourage variability and experimentation.

It’s possible to conduct “virtual” experiments using existing data and artificial neural network (neural net) software.   Neural nets are a class of very powerful, general-purpose tools readily applied to prediction, classification and clustering. They have a proven track record in many data mining and decision-support applications. Neural nets have been applied across a broad range of industries, from predicting financial series to diagnosing medical conditions, from identifying fraudulent credit card transactions to predicting failure rates of engines.

Neural networks use a computer to model the neural connections in human brains. When used in well-defined domains, their ability to generalize and learn from data mimics our ability to learn from experience. However, there is a drawback. Unlike a well-planned and executed DOE, a neural network doesn’t provide an explicit mathematical model of the process. For the most part, neural networks must be approached as black boxes with mysterious internal workings, much like the human brain itself.

All companies record important information. Such data represents potential value to the Six Sigma team. It contains information that can be used to evaluate process performance. If the data include information on process settings, for example, they may be matched up to identify possible cause-and-effect relationships and point the direction for improvement. The activity of sifting through a database for useful information is known as data mining. The process works as follows:

1.Create a detailed inventory of data available throughout the organization. The information systems department may already have compiled this information.

2.Determine the variables that apply to the process being improved and for which historical data exist.

3.Using a subset of the data, train the neural net to recognize relationships between patterns in the independent variables and patterns in the dependent variables.

4.Validate and test the neural net’s predictive capacity with the remaining data.

5.Perform experimental designs as you would on a real process. However, instead of making changes to the actual process, make changes to the “virtual process” as represented by the neural net.

6.Once the sequential application of designed experiments has been completed using the neural net model, use the settings from the neural net as a starting point for conducting experiments on the actual process. If the experiment results confirm the results from the neural net, you can reduce sample sizes and move quickly along the path discovered by the virtual DOE  process.

The entire virtual experimentation process helps answer the question, “Where are we?” It’s important to recognize that neural net experiments aren’t the same as live experiments; they are only simulations. However, the cost of doing them is minimal compared with experiments in the real world and the process of identifying input and output variables. Moreover, the process of deciding at which levels to test these variables will bear fruit when the team moves on to the real thing. Virtual experiments allow a great deal more “what if” analysis, which may stimulate creative thinking from team members.

This article is based on an excerpt from The Complete Guide to Six Sigma, Quality Publishing LLC, scheduled for publication summer 1999. Copyright � 1999 by Quality America LLC. The article first appeared at www.qualityamerica.com . Reprinted by permission.

GD Star Rating
loading...

SPC vs. Knowledge

Friday, March 6th, 2009

Have you ever asked yourself just what control limits actually measure? Oh sure, there are the standard statistical answers: central tendency, process dispersion, capability and so on. But what do control limits measure fundamentally?

The answer is ignorance.

Ignorance is really the only reason we need SPC, or any statistics for that matter. Statistics help us quantify unexplained variation. If we possessed complete understanding of a process or other phenomenon, we wouldn’t need statistics at all; we’d know what the result would be.

Usually our measure of ignorance extends as far as the resolution of our measuring system. If I measured a 1-inch part cut on a precision lathe using a tape measure, the control chart would show a boring series of 1s. But if I measured the same part with an indicating micrometer, I’d get interesting patterns of variation. Interesting in the sense that I could learn something from them. Interesting because there is ignorance. Measurable, quantifiable ignorance.

At what point have we learned “enough” so that we can (or should) stop using statistics? The answer is based on two concerns. First, there is our species’ fundamental thirst for knowledge for its own sake, which prevents us from ever learning enough. Thus we have physicists pursuing ever smaller variances in their measurements. Second, for quality professionals, our thirst for knowledge often is overridden by economics. We usually stop pursuing knowledge when it is no longer economical to do so.

Control charts help us decide when we have reached that point. An operational control chart used on-line helps the process operator decide when knowledge can be obtained economically. Shewhart found, through trial and error for the most part, that it was relatively easy to identify a single important source of variation if a data point varied from the process mean by more than three sigma. This assumes that the investigation takes place quickly, rather than after the trail has cooled.

However, Deming discovered that off-line study of the control charts, often by teams, also proved economical. Off-line analysis looks at more subtle patterns   between the control limits. With both on-line and off-line analysis, we try to reduce our ignorance of the process.

If the on-line investigation reveals the special cause of the variation, then the control limits usually are not adjusted. This is because we already know what the process is capable of doing, and the special cause was, well, special. For example, a wave solder process might produce excessive defects due to a contaminated batch of solder. In such a case, we wouldn’t change the process.

On the other hand, when off-line study teaches us something new, we usually use the knowledge to improve the process permanently, e.g., by computing a new set of control limits. Using the same example, we may learn that changing the wave-solder preheat temperature results in fewer defects, and consequently we write the new knowledge into the process control plan.

When we change the control limits based on the new process, we are saying, in effect, “I have learned something new about this operation.” If the control limits go from 100 defective solder joints per million to 75, we are saying that we formerly understood enough to explain all but 100 parts-per-million defects, but can now explain all but 75. Our goal is, in a sense, the same as the physicist chasing quarks and muons: perfect understanding. If we achieve it, we know what it takes to have zero defects.

What does this mean to those of us working in the quality field? Quite simply, that quality represents the quest for new knowledge. We can only improve quality if we know more about the process under improvement than we do now. Of course, knowledge in and of itself offers little value in the working world–we need to use the knowledge to make it valuable. People who work on quality improvement must have the opportunity to act on what they learn.

Few things are more frustrating than studying a process, making an exhilarating breakthrough, then discovering that implementing the improvement requires an endless cycle of approvals, budget changes and overcoming administrative barriers. If  organizations are going to do SPC, then they should do it right: Set up the mechanism for changing the process ahead of time.

Reprinted with permission from Actionline. © 1997 Automotive Industry Action Group. All rights reserved.

GD Star Rating
loading...

Get Certified!

Be trained by Thomas Pyzdek

Black Belt

Green Belt

Learn More!

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 Links
Good books on Six Sigma and other topics

What is Six Sigma?

By Thomas Pyzdek, Author of The Six Sigma Handbook

For Motorola, the originator of Six Sigma, the answer to the question "Why Six Sigma?" was simple: survival. Motorola came to Six Sigma because it was being consistently beaten in the competitive marketplace by foreign firms that were able to produce higher quality products at a lower cost. When a Japanese firm took over a Motorola factory that manufactured Quasar television sets in the United States in the 1970s, they promptly set about making drastic changes in the way the factory operated. Under Japanese management, the factory was soon producing TV sets with 1/20th the number of defects they had produced under Motorola management. They did this using the same workforce, technology, and designs, making it clear that the problem was Motorola's management. Eventually, even Motorola's own executives had to admit "our quality stinks." Read More...