The Top 10 SPC Mistakes

Last month’s column, “The Top 10 SPC Mistakes,” outlined five mistakes to avoid when building a successful statistical process control (SPC) system. Here they are:

10. Training everyone
  9. Charting everything
  8. Segregating control charts from manufacturing
  7. “Pinching” the SPC coordinator
  6. Using SPC because it’s a “good thing to do.”

Now, here are the remaining five SPC mistakes:

5. Using SPC as a data collection exercise
I frequently encounter SPC systems that look like this: Throughout a shift, an operator periodically takes measurements from some parts. He 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, opens some spreadsheet software and enters the numbers that had been written down. 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, dear reader, that you can visualize the absurdity of this “system.” If not, here it is: 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.

The use of SPC as described above is beyond comprehension to me. Using SPC in this way is 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 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 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. That is, the information needed to control the process is available at the time that process events occur, and when critical information is made available to the ones who are best equipped to manage the process—the operators.

So why go through this costly data collection exercise instead of using SPC properly? In many cases, the answer to this question 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 customer or have arrived in its plant already. Creating charts after-the-fact is too little and certainly 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/support
I have encountered numerous SPC implementations where the operator 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 (computers, software, gages, etc.), 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 serious lack of interest and very 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 gruff response from the company’s information technology expert. 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, pencil and hand-created control charts. In fact, these expenses 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 worker’s 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 simple paper and pencil to a full-blown, automated and computerized system. Computerization requires hardware (shop floor computers, connections, gages, databases and the like). 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 have seen include a jack-of-all-trades—a support person whose knowledge encompasses most or all of these areas of expertise. Lastly (and most importantly), management must honestly support SPC efforts as well. 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 archaic phrases best uttered by theory-X managers from a bygone era. Archaic? Outmoded? You bet. Alive and well? Unfortunately, yes. These phrases reveal a manager’s production-biased psychology and reveal 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—let’s call him 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, so its customers have plenty of vendor options.

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, excruciatingly painful: choose the decision best for the long term, instead of 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.

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

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. That’s why they are called 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 system thrives by initiating it and driving it through the operations group. Otherwise, the SPC system needs could be considered little more than an afterthought.

1. Managerial indifference
This is the Big Kahuna 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 SPC system had tremendous buy-in and support from virtually everyone in the plant. It was very 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 gave an excited 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.”

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 had the plant managers becoming statistical experts and leading 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 engineering, problem-solving 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.

So, what’s the point?
SPC is a wonderful tool for improving processes, reducing costs and focusing process improvement efforts. However, whether support-specific, managerially based or just an oversight of an important detail, there are 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.

About The Author