Document control error - Root cause fix - Employee error

J

just67horns

Hi,
I have a very consciencious Document control manager who is trying to help me get our TS certification. He admittedly made a big mistake and we are trying to fix it at the root.
Anyone with advice would be appreciated.
We put our job packages out to the floor, consisting of a router, print, and BOM, and sometime other docs.

My doc control manager stapled the wrong print to one package. Production scrapped hardware doing this, and I have initiated corrective action.
Now, maybe the draftsman who printed that print may have printed the wrong print (with a very similar part#), but, the doc control manager didn't catch it, the production people didn't catch it, until it was too late.

The error was human, but can anyone help on identifying the correct root cause and assisting with a fix at that level.
We're discussing methods of more document checks, etc, or bar codes on the prints to verify the correct print, but we're currently open to input. Please comment. Thanks in advance:bonk:
 
D

ddunn

How about a simple document list as part of the package (I assume from your question that you do not have an MRP system with routers, BOMs and links to documents).

Then all that use the package could verify its contents prior to use.

I have seen documents get switched to the wrong package on the production floor.
 

Wes Bucey

Prophet of Profit
just66horns said:
Hi,
I have a very consciencious Document control manager who is trying to help me get our TS certification. He admittedly made a big mistake and we are trying to fix it at the root.
Anyone with advice would be appreciated.
We put our job packages out to the floor, consisting of a router, print, and BOM, and sometime other docs.

My doc control manager stapled the wrong print to one package. Production scrapped hardware doing this, and I have initiated corrective action.
Now, maybe the draftsman who printed that print may have printed the wrong print (with a very similar part#), but, the doc control manager didn't catch it, the production people didn't catch it, until it was too late.

The error was human, but can anyone help on identifying the correct root cause and assisting with a fix at that level.
We're discussing methods of more document checks, etc, or bar codes on the prints to verify the correct print, but we're currently open to input. Please comment. Thanks in advance:bonk:
IMO, you have two questions here:
  1. What is the root cause of the error (not the intervening events which allowed the wrong drawing to pass through)?
  2. What are some mistake proofing ideas to eliminate or reduce the probability of the event recurring?
Introducing mistake proofing prior to determining the root cause is like putting Band Aids on broken windows when the cause is a kid shooting pigeons on the window sill with a BB gun.

I would guess it was a pretty good bet that the guy who generated the wrong print is the one who can tell you about PROCESS circumstances which allowed him to generate the wrong drawing. Perhaps HIS instruction included the wrong part number? Could everything be traceable to a dyslexic customer who read the wrong number when making a verbal order?

In the"quality business" we often talk about multiple questions (5 Whys, etc.) in the problem solving process, but the real truth is we have to ask at each "discovery" of a cause, whether we can change a process to PREVENT recurrence, rather than whether we have to change our DETECTION methods to prevent the nonconformance from reaching the next step in a process. Given my "druthers" - I'd rather PREVENT the recurrence and save the cost of scrapping or repairing detected nonconformance. If you think about it that way, it really does make more sense to spend the upfront time, energy, and cost to find the real root cause and prevent it than finding a way to catch a mistake and redo it.
 

CarolX

Trusted Information Resource
just66horns said:
I have a very consciencious Document control manager who is trying to help me get our TS certification. He admittedly made a big mistake and we are trying to fix it at the root.

Is your system really broke???? Or did someone just make a mistake? Never forget, we are humans and prone to making mistakes. If it is an isolated case, leave it at that, an anomoly.
 

AndyN

Moved On
Absolutely!!

CarolX said:
Is your system really broke???? Or did someone just make a mistake? Never forget, we are humans and prone to making mistakes. If it is an isolated case, leave it at that, an anomoly.
Carol's got it in one - why root cause an issue that doesn't need it?:nope: It's obviously not a systemmic issue - you corrected it!:yes: Tell the auditor to get over it and the shock will ensure your document guy is reminded in future:yes:

Andy
 

Wes Bucey

Prophet of Profit
AndyN said:
Carol's got it in one - why root cause an issue that doesn't need it?:nope: It's obviously not a systemmic issue - you corrected it!:yes: Tell the auditor to get over it and the shock will ensure your document guy is reminded in future:yes:

Andy
Was it a mental lapse? The nonconformance was "repaired" - no corrective action is listed. If it were my shop, I'd want to know where the PROCESS broke down. I don't want to count on detection to prevent nonconformances from reaching a customer. What happens when the employee who had the lapse transfers to another department? (All his fear and extra attention to double-checking before he passes work on to the next step in a process leaves with him.)

:nope: I can't accept the concept of blaming "operator error" when there are still so many possibilities for PROCESS (systemic) error.
 

AndyN

Moved On
In the grand scheme of things.............

I rather doubt if any organization's management are going to expend resources trying to root cause why someone got a print wrong. If we knew more about the company, we'd probably find out that they have 'bigger fish to fry' which the company should be paying attention to. Let's face it, document control issues (like this) aren't fun, exciting or of significance to management, Sure, some products were scrapped, but where does that figure in the grand picture of all the challenges we all work with daily??

I'd rather help the business get better for the customer/stakeholders sake, than go chasing after a simple error, found by some external auditor, that's all...............:yes:

Andy
 
D

Dean Frederickson

We are trying to get our internal c.a.r. started. Over the course of the last 9 months I have written up a variety of C.A.R.'s. We have quite a few that are operator error such as putting wrong p.n. tag on a part, or operator failing to put a cap on the end of the tube. Root cause would be human error. How do you write up a long term corrective action for these types of human errors?
 

Wes Bucey

Prophet of Profit
As I wrote in post #6 above
Was it a mental lapse? The nonconformance was "repaired" - no corrective action is listed. If it were my shop, I'd want to know where the PROCESS broke down. I don't want to count on detection to prevent nonconformances from reaching a customer. What happens when the employee who had the lapse transfers to another department? (All his fear and extra attention to double-checking before he passes work on to the next step in a process leaves with him.)

:nope: I can't accept the concept of blaming "operator error" when there are still so many possibilities for PROCESS (systemic) error.
Almost all of us who have had the opportunity to experience Deming's Red Bead experiment are gnashing our teeth at your comment, Dean. Almost always, an in-depth analysis of so-called "operator error" will disclose a systemic flaw that almost guaranteed operators woud make errors.

I strongly suggest you re-examine the errors with an intent to discover the true root cause instead of stopping once you identify an operator who made the error.

Some blatant examples I have seen:
  1. Employees left out components because they had no drawing and checklist showing the most efficient order of assembling components.
  2. Employees overtightened fasteners because they had no torque wrench and had never been given info about consequences for the product when overtightening.
  3. Employees used micrometers as nutcrackers for macademia nuts because they had never been trained on care of instruments.
"Wrong P/N on tag" - Is operator dyslexic? Was the document where he copied number from legible? Was it sabotage? Where did he get the wrong number from?
 

Jim Wynne

Leader
Admin
Employees used micrometers as nutcrackers for macademia nuts because they had never been trained on care of instruments.

Suggestions for improvement:
  • Supply all employees with ample quantities of pistachios--macadamias are too expensive and hard to crack.
  • Advise employees that calipers, not micrometers should be used as nutcrackers.
  • Advise employees that micrometers are sensitive instruments, and when not being used for measurement, they should be used as c-clamps.
 
Top Bottom