Most Quality people I know hear the same things over and over again.
"Management isn't engaged." "Management wonders why we even have quality." "CAPAs are boring and take up too much time." "We get no benefit from CAPA, it's just an exercise in paperwork."
We all know that upper management thrives on making money. As it should. It's chief concern is to keep the lights on, the wheels turning, and the product moving out the door. Nothing - I mean NOTHING - irks a company President more than having to stall things to deal with CAPA and Complaint investigations. It's a time consuming chore that nets the company nothing in the long run, right?
On the other hand, we all know that Quality Assurance (QA) and Regulatory Affairs (RA) make sure that systems and processes are put into place to not only ensure that things are right every time, but also that everyone is doing things in a standard approach to try and eliminate mistakes, reduce risk, and keep people as productive as they can be, with the least amount of distractions from audit findings. QA and RA are fundamental aspects of continuous improvement, but upper management still struggles to see why these rules, processes and procedures are so important.
What's missing here is QA and RA putting quality into terms the "bean counters" understand. Here's a piece of advice that'll help you turn a relatively uninvolved and uninterested executive management team into your strongest proponents of CAPA, Complaints and the QMS in general.
HOW TO EQUATE MONEY TO YOUR QUALITY SYSTEM
I helped a company put in a new eQMS system. The first module was Complaints. As we were talking about putting this module in place, one of the stakeholders told me that the number one issue was already known - Design Controls. The Complaints department was getting pounded every week by issues stemming from design problems.
My question was, "Why hasn't anyone told upper management about this?"
The response shocked me. Not only did upper management not care, they were used to counting Regulatory and Quality as General Administration (meaning pure expense.) The amount of revenue derived from the sales of the product had nothing to do with the problems being found with the product. There was nothing to make the upper management realize that they were putting product out too fast.
The design team was rushing through designs just to get the sales and had no realization that the company was losing tons of money due to returns, complaints, CAPA investigations, rework, etc. No one had ever shown them that these expenses were a direct result of the failure of the design team to ensure all aspects met requirements before shipping.
ENTER COST OF POOR QUALITY (COPQ)
As a nonstandard part of the eQMS system we were putting into place, I made mention that it should be a fairly easy and inexpensive thing to allow the final complaint to include adding the cost of resources needed to resolve any issues due to design failure.
“Why?” They asked.
Answer: to track all the costs associated with poor design and rushed release. This way, whenever a complaint has been resolved, there is an "accounting" of the amount of real dollars that were lost (replacement product, lost revenues, resource time spent on the issue rather than doing their jobs) while investigating and resolving the issue.
Once the real, comprehensive costs of resolving an issue were known and accounted for, this number could be applied backwards to the Design Control department. A Cost of Poor Quality Report could be generated and reported up to executive management that explained the difference between the COGS (manufacturing cost to produce a good) and the unintended cost of poor quality - namely fixing all failures and adding the associative costs of fixing them to the unit cost of the product. This additive cost would invariably bring down the profit margin and definitely get their attention, I told them.
The Quality Manager's eyes grew wide. He realized full well how valuable a tool such as this was. Actually reporting a cost associated with fixing complaints and CAPAs to executive management would allow them, for the first time, to understand what the cost of poor design controls meant to their bottom line and profits.
Once this cost was known and shown, executive management was aghast at the amount of money that was literally being thrown away each month due to poor engineering, rushed engineering, poor design controls, poor Design of Experiments, etc. In fact, the mere mention that their profit margin was being cut down and that the cost of the investigations was not going to be put towards a general admin account but counted towards the manufacturing cost got their strict attention.
Within a few days, news of the COPQ report had raced through the company. People were literally relieved to hear that executive management was now going to drive COPQ down by enforcing all the Quality and Design systems needed to ensure product "never came back with problems again." Unfortunately, this also meant that releases had to be delayed, not as many new products were going out the door as often as before, and sales started sagging somewhat.
But what came about as a result was: less complaints, less reworks, less replacements, and less COST.
Less cost meant less people having to replace, rework, and investigate issues. More people were freed up to do other things, like, do what they were hired to do - meaning productivity started going up. Over time, I showed them that less poor quality directly equates to more reliability. More reliability equates to less mistakes. Less mistakes leads to less audit findings. Less audit findings means more productivity. More productivity invariably leads to more profitability.
Bottom line was.....the bottom line. COPQ is a great - and sometimes seldomly used - tool that can be a formidable ally to Quality and Regulatory in getting upper management engaged and supportive of the processes necessary for a concurrently profitable and lean organization. The two actually CAN live side by side in harmony. Quality and Management just need to learn to talk the same language for this to work well.
COPQ is that common language.