Featured Product
This Week in Quality Digest Live
Six Sigma Features
Anthony Chirico
Be deliberate about the sample size you use
Jody Muelaner
A model for complex measurements
Scott A. Hindle
Avoid the unnecessary waste of being misled
Eric Stoop
Five steps to create momentum and lasting value
Minitab Inc.
Passing the three FDA stage goals

More Features

Six Sigma News
The FDA wants medical device manufactures to succeed, new technologies in supply chain managment
Provides accurate visual representations of the plan-do-study-act cycle
SQCpack and GAGEpack offer a comprehensive approach to improving product quality and consistency
Customized visual dashboards by Visual Workplace help measure performance
Helps manufacturers by focusing on problems and problem resolution in real time
Ask questions, exchange ideas and best practices, share product tips, discuss challenges in quality improvement initiatives
Says capitalization gives false impression that Six Sigma is more significant than other methodologies
His influence on the methodology can’t be denied

More News

Douglas C. Fair

Six Sigma

Top 10 SPC Mistakes, Part 2

Including the big enchilada, managerial indifference

Published: Tuesday, April 17, 2018 - 11:02

Here’s a quick rundown of what we covered in part one of our list of top 10 mistakes to avoid when using statistical process control (SPC): training everyone, charting everything, segregating control charts from manufacturing, “pinching” the SPC coordinator, and using SPC because it’s a “good thing to do.” Let’s continue with our list.

You: Wait, I thought you were done. There are more? OK, let’s do this thing.

Me: Yeah, there are more. Five more, actually. We’re getting to the really meaty stuff. Stay with me. But remember (disclaimer time again), please do take the right steps that all the experts in all the books discuss, and don’t commit the mistakes I’ll be listing here.

So, let’s continue on with our list. Here are mistakes numbers five through one.

5. Using SPC as a data collection exercise

I frequently encounter SPC systems that work sort of like this:
• Throughout a shift, an operator periodically takes measurements from some parts. She writes them down on a piece of paper.
• At the end of the shift (or the week), an administrative support person collects the papers from the operators.
• The next day or week, the support person takes the papers and enters the numbers that had been written down into some sort of spreadsheet software.
• Control charts are printed out and then placed into company mail and delivered to a process engineer, who typically exclaims, “Wow, we had something go out of control last week.”

I hope you can see just how absurd this “system” is. If not, here it is in a nutshell: SPC is meant to be used on the shop floor, in real time, by operators whose tasks include collecting data and responding immediately to out-of-control situations. The words “immediately” and “in real time” are especially important.

Using SPC as described above is beyond comprehension to me. It’s little more than an expensive and extravagantly ineffective exercise in data collection. And no matter how many times I hear a manager defend it, it’s just not SPC.

An unwanted side effect of this futile exercise is that operators tend to believe that “it’s someone else’s responsibility” to create charts, generate information, and indicate when some sort of action is needed. Nothing could be further from the truth.

When properly used, SPC instantly informs operators of out-of-control situations, allowing immediate reaction to the indicated process change. What I mean by that is, the information needed to control the process is available at the time the process events occur, and when the people who are best equipped to manage the process—the operators—need it.

So why go through this costly data collection exercise, rather than use SPC properly? In many cases, the answer is, “To create the charts that our customers want.” Oops. If there is a week’s delay in creating control charts, problem shipments are likely on the truck to the customers or have arrived in their plants already. Creating charts after-the-fact is too little, and way too late, to help ensure the quality of a customer’s shipment. Keep SPC on the shop floor in the hands of operators, and react in real time to issues identified by those statistical tools.

4. Providing minimal or no infrastructure and support

I have encountered numerous SPC implementations in which operators had no idea what was expected of them or the system, much less how to interpret plot points on a control chart. At one large consumer product manufacturer, the infrastructure was present (i.e., computers, software, gauges), but the operators weren’t trained in SPC or on how to interact with the system. Engineers on the shop floor were also puzzled, and neither camp understood the statistical analyses that their software performed. With virtually no support, the result was a lot of eye-rolling, a lack of interest, and little use of the “system.” Why, then, did they even put SPC on the shop floor? “Because our customer said we had to,” was the response from the company’s IT staff. In this case, the infrastructure was present, but support was virtually nonexistent, making for a lousy SPC system.

To systematize any change and ensure its long-term viability, there must be investments in support and infrastructure. Whether it’s a new accounting system or shop floor SPC, the same holds true. This doesn’t necessarily translate into pouring a huge budget into an SPC system; some superb SPC systems I have encountered were inexpensive, relying on paper and hand-created control charts.

https://www.infinityqs.com/InfinityQS/media/assets/images/blogs/2018%20blog%20images/March%202018/factory-datacheck_350.jpg

In fact, expenses like these were the extent of one company’s “hard” investment in its SPC system. Its “soft” investment was engineering and quality support on the shop floor combined with excellent, periodic SPC training. Regardless of a company’s budgetary situation, an SPC system must have a means of ongoing support and an infrastructure with which to interact. An SPC system’s infrastructure equates to the tools that are placed in a workers’ hands, as well as the support that’s placed in their heads.

So what tools should shop floor workers be given to maximize the effectiveness of an SPC system? From an infrastructure standpoint, it can be anything from a simple spreadsheet to a full-blown, automated and computerized system. Computerization requires hardware (e.g., shop floor computers, connections, gauges, databases). What’s placed in the operators’ hands is the easy part; the hard part is what’s placed in their heads. For example, in addition to the requisite statistical knowledge, operators must know how to navigate the software and understand the basics of a personal computer.

Shop floor personnel must also be supported from a technical standpoint. This technical support should include at least computer and process engineering expertise coupled with statistical support in the form of training. Don’t assume that these areas of expertise require an individual for each. Most implementations I’ve seen include a jack-of-all-trades—a support person whose knowledge encompasses most or all of these areas of expertise. Finally (and most important), management also must honestly support SPC efforts. Without management interest and support, those infrastructure and support expenses could quickly go to waste.

3. Making production a priority over quality

The statements, “Just ship it!” “Get it out the door!” or my personal favorite, “Let the customer worry about it!” seem to be outdated phrases uttered during a bygone era. Archaic? You bet. Alive and well?  Unfortunately, yes. These phrases reveal a manager’s production-biased psychology and that product quality isn’t nearly as important as some short-term reward. In this case, management believes that the long-term consequence of losing a customer is less serious than the short-term benefit of getting product shipped out the door.

Recently, a quality engineer and SPC system administrator I know named Bob admitted to me that control charts and quality data had revealed known problems with a customer’s order. When he informed his management staff of the situation, they instructed him to ship the order anyway. The end of the quarter was up, and Bob knew that the large shipment meant management would exceed sales goals, allowing them to reap a fat quarterly bonus. While acknowledging the shipment’s quality problems, management admitted that “the customer can always send it back if they find problems.”

Needless to say, the quality engineer was furious. “So the SPC system tells us we have problems, and we just ignore it? Why are we even using SPC?” In fact, why have a quality system? Good questions, especially considering that there’s no shortage of competitors in Bob’s company’s business space. Making production a priority over quality can put a stake through the heart of any SPC initiative. Just ask Bob. What to do? The answer is obvious to most, and to many managers it’s excruciatingly painful: choose the decision best for the long term rather than the short term.

A great example of not making production a priority over quality is demonstrated by a plant manager named George. When quality data intimated that there could be big problems with a shipment, George held a crucial shipment rather than risking shutting down a customer’s equipment with poor quality product. The result? Short-term customer unhappiness coupled with long-term customer loyalty. Additionally, George won the respect of his employees and further emphasized the critical need for high-quality products supported by the use of SPC. Lesson learned.

2. Using SPC without operations backing

SPC is used to improve product and process quality. It’s a manufacturing tool used by operators for the primary benefit of operations. Yes, engineers, managers, quality assurance personnel, Six Sigma specialists, and others benefit from the use of SPC, too. But boiled down to its essence, SPC is primarily a tool used for manufacturing, and the most successful SPC implementations I have seen are driven by operations, not quality assurance or some other support organization. The most successful SPC implementations are those that are conceived, driven, and supported by the operations group.

https://www.infinityqs.com/getmedia/f63ba019-9d22-44ff-a8b3-d5e74a81c2a2/experts_checking_info_350.aspx?width=350&height=233

How is it that SPC can fail in the hands of one department, but given the same company, the same plant, and the same employees, thrive when driven by another department? The answer usually involves political power. Departments such as quality assurance (QA), human resources, and engineering exist primarily to support manufacturing—hence, their designation as support departments. However, the primary reason for a plant’s existence is its ability to make things. Right or wrong, many companies treat support departments as an afterthought. The cold reality is that, in tight budgetary times, if QA and operations are competing for a resource, the latter will typically gain the resource at the expense of the former, but not the other way around. Why? Because you must be able to make something before you can support its manufacture. Manufacturing comes first and with it, the political power that operations groups enjoy.

The bottom line is that companies must ensure that their SPC systems thrive by initiating it and driving it through the operations group. Otherwise, the system’s needs could be considered little more than an afterthought.

1. Managerial indifference

This is the big enchilada of SPC mistakes and the single largest killer of SPC systems. The easiest, simplest way to kill all enthusiasm for SPC is for managers to ignore it. Treat SPC with indifference, and the system will die a quick, agonizing death.

My best example is that of a small pharmaceutical packaging plant. The original plant manager installed an SPC system that was run and supported by machine operators who cross-trained in different technical disciplines, then trained the other operators. Being run by operators, this system had tremendous buy-in and support from virtually everyone in the plant. It was successful in improving manufacturing performance.

Then the original plant manager took a transfer. In his place came a different plant manager, Joe, who was less than enthralled with SPC. Joe had different priorities and thought SPC was a waste of time. I sat in on one of his first weekly management meetings. One of the operators excitedly gave a report concerning the improvement of processes and the interesting information they had learned that week from their use of SPC. As the operator went through his discussion, I looked at Joe. He was yawning and cleaning his fingernails with a pocket knife. I knew it was over. He was sending a clear message to everyone: “I’m bored, and I’m not interested.”

https://www.infinityqs.com/InfinityQS/media/assets/images/blogs/2018%20blog%20images/March%202018/factory_quality_350.jpg

To their credit, the operators persisted and continued their weekly SPC presentations. Soon, though, Joe took control of the agenda and pushed the SPC presentations to the end of the meeting. Conveniently, Joe would let the meeting drag on and call “time” just before the SPC presentations, effectively silencing the operators.

Needless to say, SPC died a quick and silent death. No memos were sent. Joe never ordered a “cease and desist” regarding SPC activities. Instead, he put the kibosh on an entire plant’s SPC efforts and killed them off with his indifferent attitude and emphasis on his “more important” agenda items.

What to do differently? Several incredibly successful SPC systems that I have encountered were ones in which the plant managers became statistical experts and led the push to install an SPC system. Those same plant managers required daily review meetings to summarize the previous day’s control charts, problems, alarms, and process capability indices. One plant manager went so far as to personally oversee the SPC shop floor implementation. He used each morning’s SPC information to focus on engineering, problem-solve, and support efforts throughout the plant. Not surprisingly, those plants made amazing strides in product and process quality in a very short period of time. Their efforts are examples of the antithesis of managerial indifference. By driving SPC through their plants and supporting its use, each plant was able to save millions of dollars over several years, while expanding their customer base, manufacturing operations, and profitability.

In closing

Thanks for joining me for this list of top 10 mistakes to avoid when using SPC. It’s a wonderful tool for improving processes, reducing costs, and focusing your process improvement efforts. However, whether support-specific, managerially-based, or just an oversight of an important detail, there are many, many (many) ways of bungling an SPC system. I’ve highlighted some of the biggest SPC mistakes that I have seen and the ugly results that are the consequences of those blunders. By avoiding these 10 mistakes, organizations can sidestep critical problems that could be devastating to any SPC initiative, giving hard-earned budgetary dollars the highest probability of positively affecting a plant’s quality system. 

Discuss

About The Author

Douglas C. Fair’s picture

Douglas C. Fair

A quality professional with 30 years’ experience in manufacturing, analytics, and statistical applications, Douglas C. Fair serves as chief operating officer for InfinityQS. Fair’s career began at Boeing Aerospace, and he worked as a quality systems consultant before joining InfinityQS in 1997. Fair earned a bachelor’s degree in industrial statistics from the University of Tennessee, and a Six Sigma Black Belt from the University of Wisconsin. He’s a regular contributor to various quality magazines and has co-authored two books on industrial statistics: Innovative Control Charting (ASQ Quality Press, 1998), and Quality Management in Health Care (Jones and Bartlett Publishing, 2004).

Comments

another big mistake

Charting outputs of the process rather than inputs.  Doing so just creates "inspection with control charts" as opposed to SPC.