Written by Let’s talk about Quality Assurance (QA) in manufacturing for a bit…
Typically… QA methodologies are looked upon and executed as a mechanism intended to control the actions/output of folks who work on the shop floor in order to heighten the quality of goods they produce. True, at it’s core, this is exactly what a QA program is supposed to do. Improve quality. Instead of focusing on the outcome, I’d like to look at the inputs (variables) that produce it. Actually, more accurately, I want to look at a specific input I’ve often found to typically be completely left out of the equation. Namely, consistent input from the shop floor.
Having spent a lot of time working on shop floors, I can tell you that it’s pretty easy to (in some cases accurately) feel somewhat disenfranchised from the QA process. It’s almost as though you’re a part of a machine being operated by the “powers that be” who manage Operations from afar.
As though you’re just floating along, waiting for the next employee meeting to find out how sales of the products you assemble, fabricate, etc. have moved the corporate needle.
You know… meetings where they cover things like:
- How are our Sales compared to this time last year?
- How big a piece of the pie are labor and materials?
- What’s our scrap rate?
- What’s our quarter by quarter EBITA for the current and previous Fiscal Years?
- What are our returns as a percent of Sales?
As a member of management, I’d like to know the answers to these questions. It’s highly likely they have a direct impact on my day-to-day activities. As a member of the pool of people working on a shop floor… I’m not sure what’s more shocking. That you think I know or care what EBITA is, or that you haven’t noticed my eyes glossing over as you talk about things I may or may not have any interest in. Frankly, I’m more concerned about the amount of my lunch time that you’re using up. Sure, those anti-fatigue floor mats are great and all, but I’ve been standing on them for several hours now. I’m officially fatigued and hungry.
I’m well aware that there are a likely to be some shop floor folks that do closely follow their company’s KPIs. I’m just saying that, from my experience, they’re the exception, not the rule. Point being… that last metric (returns as a percent of Sales) is usually about as close to a metric on their impact from the end customer’s perspective as can be found. Does that strike anybody else as being pretty silly?
The folks that are closest to the very thing that keeps a company’s doors open (i.e. the products if sells) are commonly kept on a need-to-know basis regarding the actual fruits of their labor. If Quality levels don’t drop below a certain threshold, the people making the product are left alone. If Quality levels surpass a certain threshold, the people making the product will probably be told a month later at the next employee meeting. Probably.
The big question is…
“Why isn’t feedback on customer returns or external QA metrics, a normal part of the conversation with those that work on the shop floor?”
Think about it… The competitive nature of nearly every industry has made internal QA teams/processes a necessity. It’s no longer a question of “if we need a QA program” it’s a question of “what should our QA program look like?”. Everybody’s got something. That something typically includes at least a few people with Engineering Degrees analyzing data, doing time-studies, creating reports, taking measurements for an ongoing series of capability studies, etc.. They’re really REALLY good at responding. Being reactionary. The typical down-side of this fire-fighting mode being, by the time they’ve discovered a problem, bad product has already been produced. It’s not until there’s some big initiative (perhaps a Kaizen Event or 6σ Project) that happens after loads of data has been analyzed and several people’s time has been spent, that changes are made and there’s an actual chance to get out of fire-fighting mode. You know… improving things… pro-actively.
If only there was a way to significantly change the tone of the conversation. If only there were a group of people who knew the inner workings of the processes used to produce products like the back of their hands. AND… if only there was a way to show them not only internal QA metrics, but external QA metrics as well… in real-time! …
If you’ve read this far, you know that “those people” who know these processes like the back of their hands, are the shop floor folks. If a machine makes a “weird sound”, they’ll recognize it. They’ll probably know why and how to fix it as well. If something is running hot, they’ll notice it before anybody else. If processes aren’t occurring as they’ve been designed to, they probably have a really good idea as to why.
If you’ve read anything else I’ve written, you know that there’s usually a Salesforce related solution at the end of the rainbow.
Companies that use Salesforce to track/manage external customer concerns know the power of the Service Cloud. One of Salesforce’s primary strengths is its ability to make related information easily accessible in a highly controlled environment. Want Customer Service to get a Dashboard showing all open Cases more than two weeks old? They know that’s easy to do. Want QA Techs to get the same information but have access to more granular details if needed. They know that’s not a problem. Want your shop floor folks to receive an extremely high level overview of QA issues reported by customers? They know this is really SIMPLE.
That said, please don’t think I’m saying that pulling the shop floor into the QA conversation happens without a little effort and proper planning. There are a few things you’ll need to do ahead of time.
- Work with Operations to determine the level of detail you’d like the shop floor to have access to.
- This is paramount. You NEED support and input from all stakeholder. There’s no better way to shoot an initiative in the foot than to piss off the stakeholders.
- Figure out the best way/frequency to distribute information to the shop floor. While real-time is the “shoot for the sky” frequency, baby steps might be a good idea at the onset of things.
- Print-outs handed out during a daily huddle?
- A daily/week email sent to supervisors?
- However you decide to start is fine. If this if you biggest hurdle, you’re in good shape!
- Train people on what it is they’ll be receiving. Be open about what they will and will not have access to.
- Tell them WHY they’re being given access to this information and what you hope the outcome will be. This is a GREAT opportunity to improve team morale. “We value your input.” “We think you can help make a difference.” These phrases can mean the world to somebody. Especially if they actually see their input turned into actions!
Everybody’s got a QA process of some sort in place. Everybody knows that a well planned and executed improvement project can lessen the number of fires your QA team(s) spend their days putting out. Why is it that so few realize the regular, ongoing inclusion of those maintaining the tribal knowledge of those that bury their hands three knuckles deep into their production processes every day, represents a hugely powerful and often untapped addition to their CI initiatives?
Have thoughts on the topic? Struggling to get something like this implemented where you work? Please leave your questions/comments below or post them on Twitter.
Thanks for your time!