The Top 10 SPC Mistakes: Part 2

Me: Okay, so we’ve begun our Top 10 SPC Mistakes list with numbers 10 and 9: “Train everyone” and “Chart everything.” What did we learn?
You: Who? Me? I was told there would be no tests.
Me: Well, okay. Fair enough. I’ll pitch in. We learned that training everyone on SPC is a mistake. It can be expensive, and some folks just won’t be using it, so why spend the money on them to learn about it? And we learned that the folks who do get trained on SPC tend to want to use their new-found knowledge to chart everything. Don’t let them. It makes SPC look like a bad management decision; save the charting for where SPC is needed.
And remember, please do take the right steps that all the experts in all the books discuss, but again (don’t you just love disclaimers?) please don’t commit the mistakes I’ll be listing in this blog series.
So, let’s continue on with our Top 10 Mistakes to avoid when using are numbers 8 and 7.
8. Segregate control charts from manufacturing
One particularly interesting (though very ineffective) SPC implementation I witnessed involved an SPC coordinator who used paper charts for their system. Because of his interest in having a centralized area for data viewing, the coordinator found a rarely used conference room with lots of blank wall square footage. During my visit, the coordinator unlocked the door and ushered me into what he proudly called the “SPC room.”
I was amazed as I walked into a large conference room in which the walls were covered top-to-bottom with control charts. “This is where we keep our SPC data,” he stated. Innumerable control charts, neatly arranged, covered the walls. With eyes wide, I blurted, “So, how are these charts used?” His answer: “Well, when the engineers want to look at some data, they come in here.” But no one else was in the room. And, before we entered, the room was locked and the lights were off. And he had the key.
Operators and their machines were located quite a distance from the SPC room. The physical segregation of control charts from operators and their machines clearly indicated that SPC wasn’t being used as a process control tool, not by machine operators at least. In fact, I’d be willing to bet that their SPC “system” wasn’t used by anyone but this coordinator. The SPC room only proved that the coordinator could connect dots on a piece of paper. That’s snarky, I know. But the bottom line is that their “SPC room” wasn’t used by anyone. The perception by others in the plant, apparently, was that SPC was a waste of time. Given the scenario, it’s hard for me to disagree.
So, how should SPC have been used? The main point of this particular Top 10 item is that SPC tools should be used by machine operators and therefore should be easily accessible by them. Period. This precludes control chart placement anywhere but within close proximity to operators and the machines they run.
If considered carefully, the useful life of a control chart is measured in minutes (yes, you read that right…minutes, not days or even hours). Therefore, control charts that are physically removed from the shop floor are virtually useless to operators. I can’t state this strongly enough: Shop floor operators are the essential ingredient in any successful SPC deployment. Without operators’ direct involvement with easily accessible SPC tools, your SPC dollars will probably go to waste.
7. “Pinching” the SPC coordinator
So, let’s talk about the guy or gal in charge of SPC efforts at a given company…some call them “SPC leads,” others “SPC coordinators.” Whatever you choose to call them, these people are sometimes caught or “pinched” between two opposing forces: their job description and the competing agendas of other organizations.
Take Bob, for example. Bob was hired as an SPC shop floor leader. His job was to work on the shop floor—specifically, to implement SPC and oversee its success. In the beginning, Bob found his SPC coordinator position challenging and interesting. It wasn’t long, though, before he started uncovering some bad news. It seemed as though the company didn’t want process control and other quality-related issues on the shop floor. Meanwhile, Bob had actually uncovered quality issues that had been ignored or swept under the rug for years.
Bob began to get SPC implemented at this organization, but not without resistance from production managers. They didn’t want operators to waste valuable work time putting dots on a chart. It didn’t take long for Bob to realize that he was going up against a culture that valued production over product quality. Then, when Bob showed interest in purchasing SPC software to make shop floor SPC use easier, the IT staff suddenly had other, more urgent priorities.
Likewise, engineering and maintenance managers gave him the cold shoulder. They didn’t want Bob’s bad news concerning equipment problems, maintenance issues, and Band-Aid fixes to reach upper management’s ears. Bob’s important work was opposing the “get it out the door” production philosophy. Bob was caught between his job responsibilities and the interests of other corporate entities and disciplines. Eventually, and understandably, Bob became bitterly frustrated. Unable to reconcile the facts that his intentions were good and that no one really wanted him around, Bob quit.
Bob’s unfortunate circumstance was partially the result of a lack of mid-level functional coordination, coupled with a lack of solid leadership at the top. The not-so-uncommon belief that Bob’s SPC implementation was in direct conflict with the plant’s production-focused marching orders doomed this important SPC work.
Join me next time for more of this list of Top 10 Mistakes to avoid when using SPC…for numbers 6 and 5: “Use SPC because it’s a ‘good thing to do’” and “Using SPC as a data collection exercise.” ‘Til then.

Douglas C. Fair
By Douglas C. Fair
Chief Operating Officer
See Full Bio


Never miss a post. Sign up to receive a weekly roundup of the latest Quality Check blogs.

Take the Next Steps