Me: So far, we’ve covered four common mistakes made during statistical process control (SPC) implementations: training everyone, charting everything, segregating control charts from manufacturing, and “pinching” the SPC coordinator. Just the tip of the iceberg for SPC implementation no-nos. If I had to pinpoint any themes thus far, I’d have to say a few things come to mind: do things that help your operators…and try to do things for the right reasons. Make sense? Let’s continue with our list.
You: You mean there’s more? Okay, I’m interested. Let’s do this.
Me: Great! Glad you’re on board. But remember (disclaimer time), 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 in this blog and the rest of the series.
So, let’s continue on with our list of
Top 10 Mistakes to avoid when using SPC...here are numbers 6 and 5.
6. Using SPC because it’s a “good thing to do”
Don’t get me wrong, SPC really
is a good thing to do. I’ve built my career around helping organizations use statistical methods in their manufacturing facilities around the globe. And there’s nothing quite like the feeling I get when a client calls and excitedly says, “I can’t believe what we’ve learned and how much we’ve improved! I can’t believe how much money we’ve saved!” Those conversations are always gratifying and they make everyone involved feel good.
However, if the reason for implementing SPC is because it’s “inherently good,” then that’s not enough. The motive lacks substance. It isn’t a compelling business reason for using statistical methods.
A solid business rationale for driving quality throughout a company is what results in successful SPC implementations. The most successful SPC systems I have encountered are those that began with a strong leader saying something like, “I’ve had it with our quality problems. We’re going to turn this plant around.”
A great example is Chris M, a manufacturing pro I’ve known for years. Chris is a plant manager with a large folding-carton manufacturer with plants throughout the world. He was tasked with turning around the corporation’s worst plant with the lowest quality levels. Why? Because their biggest customers told them they had a choice: “Improve product quality or lose our contracts.” Millions of dollars were at stake. If that happened, the plant would be shut down, jobs would be lost, and reputations ruined.
Chris immediately installed an SPC system throughout the plant. The results were nothing short of stunning. Within a few months, defect levels dropped to just a handful in a million, costs dramatically improved, and productivity rebounded. In less than a year, Chris’s plant surpassed the quality levels of all other plants in the corporation. The customers threatening to pull work were soon giving the plant their highest vendor quality ratings—a rarity in their industry—and awarding them new contracts.
Just a couple of months into the SPC implementation stage, one of those customers sent a letter stating, “We’re not sure what you’re doing, but please keep doing it.” The “it” was the transformative use of SPC. When asked what his secret was, Chris humbly replied, “We just used SPC in the way it was meant to be used. SPC was the primary reason for the incredible turnaround of this plant.” They went from worst to first in less than a year, because of a compelling, motivating rationale for using SPC in the first place. Since then, Chris has transformed the quality levels in two more plants in their corporation by using SPC with vigor, motivation, and a business reason for doing so.
My point in sharing this story is that there are many, many ways to encourage the failure of an SPC implementation…you don’t have to be one of them.
So, we’re officially half-way through our
Top 10 List. Things are heating up. Let’s forge onward to the top 5…
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. 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, 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 that 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.
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 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 that the process events occur, and when critical information is made available to the people who are best equipped to manage the process—the operators.
So why go through this costly data collection exercise, rather than use 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 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.
We’ve got some momentum now. Join me next time for more of this list of
Top 10 Mistakes to avoid when using SPC…for numbers 4 and 3: “Providing minimal or no infrastructure/support” and “Making production a priority over quality.” ‘Til then.
Read the other blogs in this series:
The Top 10 SPC Mistakes: Part 1
The Top 10 SPC Mistakes: Part 2
The Top 10 SPC Mistakes: Part 4
The Top 10 SPC Mistakes: Part 5