Posts Tagged ‘quality profession’

What is a Black Belt?

Monday, August 17th, 2009

Who are they and what do they do?

I‘m often asked about the term “black belt” as it relates to six sigma. What, precisely, is a black belt? Where did the term originate? For that matter, where did the term “six sigma” originate? And, while we’re on the subject, what’s a green belt or master black belt?

Let’s start with the term “six sigma.” In a conversation with Ed Bales of Motorola University, I learned that Motorola coined the term in 1986. As those who have worked in quality for a while know, this term has statistical roots in the technique known as process capability analysis. Prior to the Japanese industrial invasion of U.S. markets, quality practitioners were happy with three sigma quality, which translates to about three errors or defects per 1,000 items for processes in a state of statistical control. Motorola discovered that its processes weren’t in statistical control–estimates based on field failure data indicated that Motorola’s processes apparently drifted by an average of 1.5 standard deviations. In a conversation with ex-Motorola trainer Mikel Harry, I learned that he considers the Cpk index–which measures short-term process variability under statistical control–worthless. Harry prefers the Ppk index, which measures actual performance rather than process capability. (Note that many experts, including me, disagree strongly with Harry on this issue.) In any case, before computing expected process failures, Motorola adds this 1.5 standard deviation. Thus, when we hear that a six sigma process will produce 3.4 parts-per-million (PPM) failures, we find that this PPM corresponds to the area in the tail beyond 4.5 standard deviations above the mean for a normal distribution.

Motorola also adopted the terms “black belt” and “green belt.” For my book The Six Sigma Handbook, I did extensive research into what employers expect of people with these titles. Here is a summary of these various responsibilities:

  • Master black belt–This is the highest level of technical and organizational proficiency. Because master black belts train black belts, they must know everything the black belts know, as well as understand the mathematical theory on which the statistical methods are based. Masters must be able to assist black belts in applying the methods correctly in unusual situations. Whenever possible, statistical training should be conducted only by master black belts. If it’s necessary for black belts and green belts to provide training, they should only do so under the guidance of master black belts. Because of the nature of the master’s duties, communications and teaching skills should be judged as important as technical competence in selecting candidates.
  • Black belt–Candidates for technical leader (black belt) status are technically oriented individuals held in high regard by their peers. They should be actively involved in the organizational change and development process. Candidates may come from a wide range of disciplines and need not be formally trained statisticians or engineers. However, because they are expected to master a wide variety of technical tools in a relatively short period of time, technical leader candidates will probably possess a background in college-level mathematics, the basic tool of quantitative analysis. College-level course work in statistical methods should be a prerequisite.

Six sigma technical leaders work to extract actionable knowledge from an organization’s information warehouse. Successful candidates should understand one or more operating systems, spreadsheets, database managers, presentation programs and word processors. As part of their training they will be required to become proficient in the use of one or more advanced statistical analysis software packages.

  • Green belt –Green belts are six sigma team leaders capable of forming and facilitating six sigma teams and managing six sigma projects from concept to completion. Typically, green-belt training consists of five days of classroom training and is conducted in conjunction with six sigma team projects. Training covers facilitation techniques and meeting management, project management, quality management tools, quality control tools, problem solving, and exploratory data analysis. Usually, six sigma black belts help green belts choose their projects prior to the training, attend training with their green belts and assist them with their projects after the training.

Although the martial arts terms described above are common, they are by no means universal. Companies and consulting firms often create their own titles to describe the work done by these technical leaders.

GD Star Rating
loading...

Process Capability-in English

Tuesday, June 9th, 2009

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.

GD Star Rating
loading...

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...

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...

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...