Want to be Compliant? Know Your Technology!

Do you spend too much time writing CAPAs and nonconformance reports?  Do your operators take too many shortcuts?  Do batch sheet errors take up your whole day?

If so, count yourself in good company.  Many companies are in the same boat (the one on the left).  The next question is, what are you going to do about it?

If you’re like most, you will send the perceived perpetrators to endless hours of retraining.  Maybe the big boss will make long winded speeches.  Or, worst of all, you’ll bring in expensive consultants, who will tell you that your quality system SOPs are all noncompliant and need to be rewritten.

All of these are wrong.  Let me tell you why by citing a very common example (the details are fictional, but it really did happen – many times). 

I was helping a company by providing regulatory support in their change control review board.  The engineering manager was explaining a new project that they wanted to install.  I said that I didn’t see how it could work.  Let’s just assume for the sake of privacy that they wanted to make water run up hill.

At first no one noticed my comment.  I repeated it, louder.  This time they noticed:  “What?” they said, moderately annoyed that the hired regulatory gun would be holding up the technical part of the meeting.

“You’re trying to get water to run up hill,” I said.  “It won’t work.”  Nobody believed me until I diagramed it on the white board.  One of the junior engineers compounded their embarrassment by trying to refute my logic.  Fortunately the engineering manager saw the problem and cut him off.  The technical part of the meeting was amputated, and Engineering called a disorderly retreat.

Please understand.  I don’t claim to be a technical genius.  I guess I’m ok.  Years of working in manufacturing and product development were worth something.  But, there’s no way that a regulatory consultant should be catching these kinds of technical impossibilities in a change control meeting.

The good news in this particular story is that the project got corrected before it was installed.  The bad news is that in far too many cases the technical problems don’t get caught until they’ve been installed; maybe not until they’ve run for a few years.  The tragic news is that I’ve seen this happen so many times I can’t count them.

Many technical problems are latent.  They may show up only as the result of a confluence of disparate events in some small percentage of batches.  They may only broaden the variability of a process; causing the tail of product spec distribution to sneak outside the spec range; again in only a small percentage of the batches.

Another reason these problems don’t surface immediately is that operators are really good at making processes work.  They find work-arounds.  They find a way to get the job done, especially when management wants to get product out the door.

However, there’s only so much operations can do.  Eventually the problems manifest themselves, maybe in some kind of quality inspection, or maybe the number and magnitude of the work-arounds become too obvious for anyone to ignore.  But usually it’s because scrap and rework rates creep up to levels that become visible to upper management.

Management then declares that all these “regulatory” problems need to get fixed.  Compliance goals get set.  The Quality department is charged with getting all these issues cleared up.

Of course that never happens.  Quality does its duty and charges the enemy.  They fire CAPAs and OOSs at the problems, but success is elusive. 

The Root Cause Analyses usually end on the manufacturing floor with some unsuspecting operator doing a perp walk to the training room.  The operator simply got caught trying to bend an SOP to make an incapable process work, a practice learned from years of precedent.  In fact the real cause is that the company doesn’t understand their manufacturing process.

The company doesn’t know how its equipment operates.  It doesn’t know the Critical Process Parameters and Acceptable Ranges of its processes.  It doesn’t know the variability of its processes.

The result is that the lives of everyone associated with manufacturing becomes a nightmare of OOSs, nonconformances, deviations, CAPAs, and missed shipments.

What appears to management to be a compliance problem is in reality a technical knowledge gap.  The regulatory issues are a symptom of the more fundamental problem, a lack of understanding of the manufacturing process.

Every manufacturing operation needs good engineers and good process development scientists.  It also needs to give them time to do their job.  These people need to be able to push back when necessary, and say that the company doesn’t know enough about the process.

In summary:

• If you’re having regulatory problems, ask yourself if you truly understand your technology.  Have you truly characterized your manufacturing processes?
• If you want to be compliant, know your technology; especially if your goal is to make a profit.  Compliance is easy if you truly understand your technology.
• If you’re thinking about acquiring a company, make sure that the company understands their technology well enough to translate it into a smooth manufacturing process.

Of course, a better manufacturing process will produce less scrap, less rework, and fewer missed shipments, thus saving money.  But possibly even more important in a regulated environment, you will have fewer OOSs, nonconformances, deviations, and CAPAs to write up, thus saving even bigger money.