Posts Tagged ‘Process-Capability’

How To Calculate Process Yields

Thursday, July 2nd, 2009

Unit yields are a misunderstood tradition.

Sam handed Peter a computer printout and asked, “If the yields are so high, why is my efficiency so low?”

Peter studied the report for a moment and then nodded. “Let me show you what’s going on,” he said as he picked up a marker and drew a diagram (see Figure 1).

Figure 1: Process with 10 Steps


“This process has 10 separate steps,” Peter began. “Each step has a yield of about 90 percent. This is the unit yield for that process step.”

“Right,” Sam interjected. “And all of them are about 90 percent, so the average yield for the whole process should be about 90 percent.”

“Yes, but that isn’t the number you need if you’re trying to determine the final yield for the process,” Peter responded. “Final yield is the proportion of defect-free units out of the final process step relative to what you started with at the first process step.”

Sam nodded. “Yeah, but even though the average yield is nearly 90 percent, our final yield is nowhere near that high.”

Peter turned back to the board. “Here’s a mathematical model of what happens when all process steps have the same unit yield.” He wrote an equation:

Yoverall = (Ystep)number of steps

“The unit yield at every step is about 0.9, but you have to multiply the step unit yields together to get the final unit yield. You can’t just average them,” Peter explained. “Think of a simple two-stage process. You start 100 units at the first step and 90 pass. These 90 start the second step and 90 percent of them pass, leaving 81. The average unit yield is 90 percent, but the final unit yield is only 81 percent.”

“So for our 10-step process,” Sam began.

Peter punched his calculator keys. “0.9 raised to the 10th power is about 0.35. So 35 percent is your predicted final yield.”

“And that’s pretty close to what we’re getting,” Sam said.

Peter knew that misunderstandings on yields lead to a variety of poor management decisions. He was pleased that Sam had asked for clarification. But, Peter knew, Sam still didn’t know the whole picture. Six sigma requires an entirely different mental model of yields.

“That’s not all,” Peter said. “So far we’ve been talking about unit yields. That’s the customary way of doing it around here, but there’s a better way.”

“Unit yields often have very little to do with costs,” Peter continued. “Who knows how we got those 350 good units? Maybe they were reworked several times. There can be a lot of cost hidden in the numbers. If you want an accurate picture of process performance, use rolled throughput yields.”

Peter sketched another picture on the board (see Figure 2).

Figure 2: Unit Yields vs. Rolled-Throughput Yield

“Let’s assume that we have two lines making the same product. If we only look at unit yields, they look much different. One process has a 50-percent yield, the other a 90-percent yield. But assume that each unit had 10 critical-to-quality characteristics. If we look at characteristics, we see that both have produced five defects in 100 defect opportunities. In terms of the ability to produce defect-free quality characteristics, they’re actually the same.”

“So if it costs $100 to fix a defect, the two processes have about the same rework cost, even though the unit yields would make the first process look a lot better,” Sam replied, nodding.

“This is exactly why we use rolled throughput yields in six sigma,” Peter responded. “They correlate much more closely with labor, cycle time, rework costs and other important management metrics.”

Sam frowned. “That means that our efficiency reports are worse than useless–they’re misleading!”

Peter smiled.

“Thanks, Peter!” Sam exclaimed. “I think you’re just the man to head a project to fix them!”

Yields: A Glossary

Yield, First-time Yield (unit-based)–the number of units that pass a particular inspection compared to the total number of units that pass through that point in the process.

Final Yield (unit-based)–the number of units that pass the last step in a series of steps in a process compared to the number of units the entire process started with.

Throughput Yield (defect-based)–the probability that all defect opportunities produced at a particular step in the process will conform to their respective performance standards.

Rolled Throughput Yield (defect-based)–the probability of being able to pass a unit of product or service through the entire process defect-free.

Normalized Yield (defect-based)–the geometric average throughput yield one would expect at any given step in the process. Analogous to the “typical” yield. For a k -step process, the normalized yield would be the kth root of the rolled throughput yield. A note of caution: This metric can be misleading if the throughput yields of the process steps vary a great deal.

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 Is Primarily a Management Program

Friday, May 15th, 2009

Six Sigma is such a drastic extension of the old idea of statistical control as to be an entirely different subject.

In the 1970s, Motorola learned about quality the hard way–by being consistently beaten in the competitive marketplace. When a Japanese firm took over a Motorola factory that manufactured television sets in the United States, it promptly set about making drastic operational changes. Under Japanese management, the factory was soon producing TV sets with 1/20th the number of defects they had produced under Motorola management. Eventually, even Motorola’s own executives publicly admitted “our quality stinks.” Finally, Motorola decided to take quality seriously. Then-Motorola CEO Bob Galvin started the company on the quality path and became a business icon largely as a result of what he accomplished in quality at Motorola.

In accepting the first ever Malcolm Baldrige National Quality Award at the White House in 1988, Bob Galvin briefly described the company’s turnaround. He said it involved something called Six Sigma. Among the attendees was a contingent of Baldrige judges and examiners, including me. I assumed that I knew precisely what Galvin was talking about when he used the term Six Sigma. I believed that he was speaking of statistical process control, process capability and meeting requirements, the sorts of things that quality engineers had advocated for years.

At that time, there was a consensus among quality engineers and statisticians that process capability was, roughly, “plus or minus three sigma.” A process controlled at this level would produce a small percentage of defective items, but the percentage was thought to be acceptable. In the 1980s, U.S. automotive companies tightened up the definition to mean plus or minus four sigma, which brought the defect rate down to a few parts per thousand. Galvin’s reference to Six Sigma, I thought, was a minor modification of a tried-and-true statistical approach, which could be entirely described by the illustration shown in Figure 1.

Figure 1

Figure 1

I was wrong.

Galvin was describing something entirely new. Six Sigma is such a drastic extension of the old idea of statistical control as to be an entirely different subject. The statistical difference alone is staggering. A Six Sigma process will produce failures at a parts-per-million or even parts-per-billion level. This contrasts with the old three sigma process that produces parts-per-thousand or even parts-per-hundred (percent) failures. This difference of three to seven orders of magnitude is profound. In science, a difference in scale of this magnitude qualifies a subject as a new science, as when one goes from the study of molecular biology to the study of botany.

In short, Six Sigma is not just a modification of the old engineering idea of three sigma quality levels; it is an entirely new way to manage an organization. Motorola’s senior executives extended the idea far beyond manufacturing. Six Sigma became a way of doing things throughout the entire organization. This task is vastly more difficult than simply improving the control of a machining or assembly process. It requires nothing short of a transformation in the way an organization perceives its environment and its role in that environment.

Six Sigma is not primarily a technical program; it’s a management program. Any organization that fails to keep this foremost in mind is doomed to fail in becoming a world-class organization.

Let’s take a closer look at how Six Sigma works at one company that understands this.

At General Electric, Jack Welch asks each employee to become a “quality lunatic.” In mid-1998–three years after starting its push for Six Sigma–GE was running at a sigma level of three to four, according to a 1998 Business Week article. The gap between that and the Six Sigma level costs the company between $8 billion and $12 billion a year in inefficiencies and lost productivity.

Welch launched the effort in late 1995 with 200 projects and intensive training programs, moved to 3,000 projects and more training in 1996, and undertook 6,000 projects and still more training in 1997. The initiative has been a stunning success, delivering far more benefits than first envisioned by Welch, according to Business Week. In 1997, Six Sigma delivered $320 million in productivity gains and profits, more than double Welch’s original goal of $150 million.

“Six Sigma has spread like wildfire across the company, and it is transforming everything we do,” boasted Welch.

And transformation is what Six Sigma is all about.

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