I worked as a QA tecnician in an ecoat paint facility in Southwestern Ontario, part of my job is to write corrective action reports whenever customers request for it.
In one of my reports I wrote among others "operator error" as a root cause, our customer rejected the idea and ask me to find some other reason why the problem occurred.
My question is( for those quality people out there) is an "operator error" not a valid root cause in a 7-D format corretive action report?

While "operator error" is a common response, most companies (B3) are starting to recognize that there is usually some other cause. Can you ask "why" was there an operator error? Possible answers could be:
1. "new employee" - so root cause may be lack of training with the C/A on the training program, or needed better visual aids for a new operator. or,
2. Operator instructions were not clear. or,
3. Bad part placed with good parts? Why? Lack of errorproofing.

I think your customer just wants to make sure operators aren't getting blamed when there may be a "better" or quality "system" related root cause. If you can ask "why was there an operator error" - and not come up with an answer, you should still look into errorproofing as corrective action. That may satisfy the customer.

Your thoughts?

Laura

Operator Error is real. Show me someone who doesn't make errors and I'll show you someone who doesn't do anything. Inattentativeness, momentary lack of judgement, distraction and just plain stupid! We do everything we can to find a reason. It will never go away. Look at some of the posts mispelling.(mine too). While it may be considered minor and doesn't really matter, it reminds me that we are all human. One mistake of the key can create an order entry error. Customers who don't accept Operator Error as a valid reason are just bullies and enjoy the power trip. Inspection was developed for just that reason, and they make mistakes, too. So there!
energy

True. It is real. How you address the 'problem' is what is important. For example, operator error on the space shuttle systems assembly, etc. is not acceptable. For any reason. Would you accept Operator Error by a technician performing structural tests on an older aircraft as a vaild root cause for a crash of that airplane? I don't think the flying public would accept a finding which says "Well, there will always be operator errors... We can't prevent them entirely." Not even 1 is acceptable sometimes.

The first thing I want to know if I find operator error has been determined to be the 'root' cause for a nonconformance is has this happened before? Same operation? Same machine? Same shift? Same operator? Same part?

Recurrence of operator error is a sign that there is a deeper problem.

So - you're both right. But -- look closely at the entire context before you decide whether (or how much) operator error is an acceptable 'feature' of your business processes.

[This message has been edited by Marc Smith (edited 07 May 2001).]

Refusal by a supplier to accept "operator error" as a root cause to a CA is not new. I had a supplier tell me this seven years ago (a small company in Northern Michigan, as a matter of fact). Further, I'll admit to subscibing to this belief myself.

Like Laura, I believe that if operator error is defined as the root cause, it really defines a management problem. Either the operator wasn't properly trained, was promoted without appropriate skills, or the process was not sufficiently mistake proofed.

This is not to say that errors won't occur. But the role of manangement is to design processes and systems in such a way that the liklihood of errors is either minimized or the errors that could occur have insignificant impact on the product.

I guess my question for darwinbb is this: If operator error was defined as the root cause, then what was the action taken to correct it? If the action was a reprimand to the operator ("Don't do that again!"), then the CA fails on two counts. If the action taken was training, then the root cause was a training failure. If the action taken was an example of mistake proofing (a process design change that will ensure the error can't happen again), then I'd buy the operator error argument.

hey guys,
I'm not arguing with Laura M. We have history! I'm also not talking about the space shuttle. They triple, if not quadruple inspection points on all operations to prevent errors. I'm referring to the small shop making brackets for a wire harness for aircraft, maybe a small machine shop fabricating a fitting for an airhose on board a ship. They all are important, but the wild goose chase some of these big companies will send you on just to satisfy some 4,000 employee company's idea of cause and corrective action is not justified. They have the personnel who can spend a week looking for the boogie man, and he/she won't be missed. If it's the same part, same excuse, well look deeper. If it's not, do your best to find the cause and get on with life. I still think that most of this stuff is directed from the bully pulpit. Yup, this is energy working at home, so I crafted a similar user name. Can I use my user name on my home computer or am I commiting "Operator Error"?
energy

I am one of those that will not (under any circumstances) buy "operator error" as a root cause of a problem. It tells you nothing about the nature of the problem other than an operator was involved. Laura is correct in that you need to ask why (as many times as needed) to get to the root cause. Even in the second scenario that Dan cites if the correction was to mistake proof the process then the design of the process that allowed the operator to insert a part in bacwards (or whatever the problem) was the root cause.

Tradionally "operator error" has been the dumping ground for all sorts of problems that company managements did not want to accept the responsibility for because it was their systems that were at fault. I would say that most companies that I deal with will not accept "operator error" as a root cause.

Best Regards,

Jim Evans

Ok.... I guess I have to play devil's advocate here....

If we say that "operator error" is not an acceptable root cause, how much can we "mistake proof" the process before it becomes financially untenable?

Cheers!!!

Mike

If you don't care for the term "operator error", you really wouldn't enjoy "unknown".
We used it when there was no way to pin down the cause. Talking with all personnel in the loop, no legitimate cause could be determined. We had 15/18 operations where nicks and scratches could have ocurred. Nobody in the process could point to the cause. We used "unknown", with separating the parts with dividers to eliminate normal handling. That's alot more honest then blaming an Operator. If it's Operator Error, that's the cause. With 40 operators, and not always the same one responsible, it's hard to believe it's a training issue. You can say it, but that don't make it so. It also has to be mentioned that the company's PPM defects didn't even show on the customers' quarterly report. So the customer had to change to report to show units on the graph to a max of 10. Then we can see 5 pcs rejected out of thousands shipped. Think about it. 1500 pc order with one pc having blurred part marking. Another 2000 pc order with a scratch on it. This with an approved sampling plan for final inspection. The amount of time required and the futility of determining who, what and where, just doesn't "add value". Most importantly, the orders kept coming. It's not a perfect world and some customers that know you provide superior product are aware of it. Once more, Customers that demand full blown investigations in light of the conditions I mentioned, employ way too many Quality Geeks with not enough work to do. They are just feathering their nests and beating their inflated chests because as the Customer, they can. I want to add that the average cost per part is about $2 or $3 each, with the customer continuously trying to nickel and dime that cost down. Some parts aren't even a $1. Give me a break!

[This message has been edited by energy (edited 08 May 2001).]

Energy,

In your example, I don't know that the cause is unknown as much as the source. The cause is high potential for mishandling; your solution was appropriate for the problem.

I also sympathize with you regarding the PPM issue. In fact, it can be frustrating when customers issue CAR's over what seem to be petty issues.

There seem to be quite a few companies that issue CA's for every reject or concern regardless of the significance. When this approach is used, it diminishes the impact that a CA should have, the result generally being that root cause analysis suffers.

Personally, I think CA systems are one of the most misused systems in ISO and QS. I guess that's one reason they tend to be such a hot topic.

Back in the day of, MIl-Q, We used the term "random failure"
Has a nice ring to it. At times, no matter how hard you try you cannot determine the exact cause of the failure. But then agin this is not an acceptable answer either; is it?
CA is a vicious cycle, on the one hand I get a CA request from my counterpart at another company and complain about the paper work; I in turn receive defective product from a supplier to which I promptly request a CA.
And on and on.
We need to do a better job at addressing the CA system, maybe stand out side of the box and take another look.

Although it has been awhile (1992), the last time I used the term "operator error", I was called to G.M. Headquarters in Warren to "discuss" the response the the SQA. I still hurt!

At the very least respond, as said before, with something like "random occurance" and be prepared to back it up with data and further actions.

As to intentional "operator error", on some level I don't think we will ever be able to get rid of it, only reduce the occurance. There will always be disgruntaled people and they will even bypass the built in preventive measures and traceability to make their point.

It's our job to minimize these actions.

I think there is a bigger point here and that is to have an up-front relationship with the customer at all levels. There are many times I have visited a production line and because I had a relationship with the operators, they would call me over and point out a "possible situation" and then get rid of the product in question. No harm, no foul, until I got back to the plant.

ASD...

ASD...

Is the mean time between failures concept useful here? If we're going to realistically claim operator or, e.g., machine, error, and need data/statistics to back it up, does this work? Sort of a risk management spin on it? Root cause was error by Operator A. Is he within the lines on mean time between errors? Yes, then operator error acceptable as root cause; no, then investigate why his error rate is out of spec.

Or not...

Rex

Q rex:

I like the idea of using MTFB, but I see it being very difficult to quantify such subjective data as "operator error".

I see it as not very cost effective when you take into consideration the numerous studies that would have to be performed.

i.e. A study for each operator on each process, part, failure mode, gage used etc...

Any ideas on how it could be used in a cost effective manner and keep customers happy?

MHO
ASD...

Keep up the thought provoking posts!

OK - one client was in the process of "beating up" an operator when I arrived yesterday. Apparently a significant quantity of bad product was produced. This extremely dedicated, high attendence employee did not perform some quality checks. He noticed a problem, but "thought" they were OK. Unfortunately he took it upon himself to make that call.

However....this was the first run of a new product after qualification. The Quality Engineer did not "verify" that the instruction for a regular production run were understood. In my opinion, and what I told the owner, was that this was entirely a management issue. If the QE was not in the department during a start-up, looking at product himself, providing assistance if needed, then the operator was left on his own to make a decision. Could the operator have used better judgement? Of course, but root cause was not operator error.

I agree, you can errorproof yourself out of business, but not all errorproofing is expensive. Simple, visual controls usually work.

Originally posted by Dan Larsen:
Energy,
There seem to be quite a few companies that issue CA's for every reject or concern regardless of the significance. When this approach is used, it diminishes the impact that a CA should have, the result generally being that root cause analysis suffers.



I may be guilty of the same thing internally. We recently purchased a great CA program, and, to get people used to reporting problems I created a problem detail reporting form. So as not to slight anyone, I am currently entering all into the database. All the problems involve Customer Complaints, Supplier issues and internal data entry mistakes. Some personnel use this as a vehicle to beat up on a co-worker. My problem is that 80% of the problems involve data entry errors. These are definitely operator errors. One poor individual may process 200 orders per week, but every week I receive a report where something went wrong with the 1 or 2 orders that results in us having to provide free freight, discounts on the next order, credit memos, etc..These cost the company money. On the flip side the individual makes a lot of money for the company. I don't issue CAR's at this time because we are in the startup mode with this program. Is there a way to classify this type of problem other than "Operator Error". Actually, I call it order entry error, but it's the same thing. "Error". I know we have the option of determining the magnitude of what gets reported, but quite honestly, it makes up the bulk of the problems reported. Any ideas or suggestions from this talented group are always appreciated.


[This message has been edited by energy (edited 11 May 2001).]

thanks for the response, i wrote my corrective action report without using the phrase " operator error ", it seems to me that our customer requires an elaboration of the root cause. This suit the customer very well, now I learned my lessons ...... :)

Wait wait!

I need help.... I mean with NCR stuff. We recently had a customer send back a couple of bad parts. They don't seem to want to tell us how many bad ones they found. We 100% sorted 50000 (small) pieces and found one with the problems they were talking about. We can find no reasonable explanation. They aren't returning the parts, which makes me think that it isn't a very serious problem. However, they do want an 8-D filled out. I really don't feel that 'unknown' is a very good answer, but I got nothing else. Perhaps energy has a witty answer for me.... :p

Fire Girl;
1 in 50000 looks like 20ppm. You may be the victim of a six sigma guru that wants to know why you cannot meet their requirement.
Thus, the request for an 8-D. And you are right "Unknown" would not be "good enough".
I went through the same thing with DCX. We had 2 parts failed in 47500 for the year which put us right on the edge for being an acceptable supplier.
Answering all the questions on their 7 step was very important for our continued business.

How many more parts do you need to understand the problem? (Not meant to be smart a$$) 2/50,000 can be significant.
We had a part that was used 6/car. Similiar PPM's were cited by the supplier. But with 6 per car, the ppm is 120 ppm at the vehicle level. How many more in stock to sort? If you can't root cause what you got, how will more parts help?

I'd sort 100% for awhile, and brainstorm potential cause. Don't forget to update the FMEA!

FG,

They sent 2, you found 1. You have a problem that needs to be considered. The next time you may receive the whole shipment back.

What is your PPM with the customer?

ASD...

Sometimes it is difficult trying to get more info from a customer.

While your company is seeing what it feels is a small percentage of bad parts, you have to concede that the customer is king.

Get some people together and brainstorm this problem. Make sure to include some from the production end. They might be able to bring you some information as to if they've seen anything, were there process or equipment changes? Can you identify where in the run the defect happened or became apparent? Are the defects all in the same place, recurring regularly (even if it's one time a day on the last part or whatever)?

I believe that occasionally you will come up with a problem that you cannot find a cause for. BUT...it is usually because of our limitations be they training, inexperience, lack of documentation etc. Everything in life has a cause, or many contributing factors. It is our jobs to identify them, or to define how far is far enough, when does it become unprofitable to continue to search.

Good luck, I am sure that if you don't panic you can work through this.

Fire Girl,
I don't have a witty retort, but I liked Sam's "random" failure/nonconformance or "isolated incident with low probability of re-ocurrence". They appear to just want an answer. As the customer they always have the option of not accepting your reply. If the interest appears to minimal, as you describe, you probably won't hear from them until the next snafu. But, as the current occupant of the bully pulpit, they may want more. Maybe the CAR person's dog got run over by a car or his wife left him, in which case, you're in what we call Dog Doody City.
energy

Excellent discussion folks:

Where would "Operator Aptitude/Attitude" fit - as an acceptable contributing cause? Reasonable source for variation?

Regards
Jim

Ok. These mangled parts don't really look like something our tool could have done, so we really are baffled. The reason we would like to see all the bad parts is to see if there is perhaps some type of extra little telltale mark that maybe we didn't notice on the others. The one part out of 50000 is what we had in stock, they have more parts on site. The press stamps these parts off like 90, if it miss-hits 3 or 4 times, the operator is not likely to notice this. Usually the operator is running a few presses at once and checking his or her parts every 15 minutes or so in small bins before they are emptied into big bins. We have never seen this problem before. We are not QS 9000 certified although we do comply with many parts of the standard. Our customer is not either and they don't understand any of the paper work. They are getting the heat from their customer and they don't really know what to do. Looks like gravity is to blame again!! S@*t really does flow downhill. Damn physics!

A machine that "Miss- hits 3 or 4 times" while running 90 can"t be operator error can it? - Only if you take the stand that the error of not catching it during the process is due to operator fatigue.

Thinking I'd investigate "WHY is the machine miss-hitting?" Speed? Material? tooling?

Then again I have had parts returned here that were dropped out of our packaging after shipment from our dock & ran over by a truck. Our customers sitll ask us to investigate how "we" did it.

Regards
Jim

[This message has been edited by Jim Biz (edited 16 May 2001).]

Jim,
Aptitude is a training issue. Attitude is a human resource issue. Either way, according to the majority who have responded in this forum feel that, "employee" anything is not a good enough response. There has to be an underlying reason for the unacceptable event. To say the employee made a mistake, you ask why? I'm an idiot. Why? I quit school in the second grade. Why? Because I felt like it. Why? I could learn more by setting ants on fire with a magnifying glass. Why? Mind your own business. 5 whys and you dare not report any one of them as a reason for the N/C. Employee error is the cause. I stand in the minority. How about "Employee error" and now he/she doesn't work here anymore. These customer quality geeks may still insist that there must have been more that could have been done by the company to prevent this hapless individual from botching the job. A pox on them all!!

energy
I don't disagree at all the "human factor" is certainly error prone - but unless I mis-read the thread :) fire girl has been informed of a "Problem/event" she hasn't seen before so I guess I'm trying to point to the fact that "Something" other than the operator has changed?

Regards
Jim

So, what can we do to eliminate this assinine method of communication?

I have a thought,IMO. Maybe someone would care to expand on it.

1- Have a minimum of three suppliers for each type of product at all times.
2- Do away with the external PA/CA process.
3- Develop a rating system based on 100% defect free product delivered 100% on time.
4- Provide this information to the supplier with the understanding that when a pre-determined level is reached, all future orders are stopped; without further notice.
5- Re-instatement can oocur only when the supplier agrees to pay for all costs associated with the delivery of defective parts or because of late delivery.

Item #2 is what we are trying to achieve. Afterall, we are all suppliers and we are all customers.
The present PA/CA system does not work, it's broke and cannot be fixed. Some other process is required that allows us to express our disdain for defectve product, without having to spend wastre hours trying to explain to someone, in writing, why we screwed up.

Well any way I feel better. I can get back to completing this 7D.

Originally posted by Jim Biz:
Excellent discussion folks:

Where would "Operator Aptitude/Attitude" fit - as an acceptable contributing cause? Reasonable source for variation?

Regards
Jim
Jim,
My last post was to address this statement, not Fire Girl's dilemma. She's between a rock and a hard place because of a over bearing customer that's enjoying the "power trip".

Let me elaborate.

This part is new to this customer. We used to make this part for another customer. They never complained but that doesn't mean there weren't any bad parts. We are still trying to get PPAP approval from this new customer. They have had the documents for almost a year and they called last week and said our Certified Lab's certification expired! So we had to re-submit some stuff again!!

Yes something has happened. Looking at the tool, there do not seem to be any problems with it. I still feel this could be an operator error. Chances are those few bad parts were made close together. The operator is supposed to be checking his/her parts before dumping them in bulk bins.

I really think that freakish things sometimes happen and you aren't always going to have an explanation. Maybe on the space shuttle, yes, where there is a monitoring system for the effectiveness of the toilet flushing.

I just think, humans built the dies, humans repair the dies and machines, humans run the parts and humans check the parts- you're just asking for trouble with a set-up like that. After all, we're not perfect, are we?

Just this gal's humble opinion.

:confused:

Originally posted by Fire Girl:
Let me elaborate....
keep the fires out, girl!
energy

This message has been edited by energy (edited 17 May 2001).

Darwin, when you answered your Root Cause as operator error, did you verify?

When defining and verifying root causes one or more causes can be considered the root cause depending on the problem description.

Keep asking the question "what caused that" as many times until the TRUE root cause is established.

I agree with you that operator error could have been one of the causes but not the true root cause.

"What caused the operator error?"

Time to get this fired up again.

We have recently started to issue SCAR's to suppliers who have sent us incorrect material. Very expensive material. $5K Pumps, a Pressure switch with the incorrect Calibration range, highly polished sanitary manifolds and items that are required for timely delivery of our product to our Customer. Three of four have responded with "order entry error" as their root cause. Preventive Action was to "check more closely". One of them is an ISO Certified Supplier. Now, as we look back at some of the posts in this thread, I'm supposed to demand further action on their unacceptable root causes. I accept their order entry reason as acceptable. 75% of our reported customer complaints is for the exact same thing. 4 different Sales people. There is nothing wrong with the product. Does an outside auditor have the authority to tell me that our Corrective Action System is ineffective because I don't go after our Suppliers in a more agressive manner? Also understand, in this type of business, these suppliers are selected because they are the best in the business and reputable in their fields. We cannot afford to alienate them by tracking down what was obviously a human error. The product is superior and usually goes through without a glitch. I just believe that an error of this type requires no more than just documenting it and look for trends of this type of excuse from the same Supplier on future transactions. Okay. Fire away!:bonk: :ko: :smokin:

I don't know if my opinion will help. I would say no, they don't have the authority. I would take a very similar approach energy. Talk to the supplier, keep them informed of any identified trends, etc.. To go after them more aggressively would make you look like one of the B3 - they still haven't beat all of us into submission!

energy, I was told once (by whom, I can't remember) that "human error" can never be classified as a root cause. If someone does err, then the organization should not have let that occur. The root cause may be insufficient error-proofing, but not human error. Ahh talk from the ivy tower!:eek:

In the real world, just as you and Stew indicated, human error does occur. As far as auditors, I think it would depend on the “magnitude of the problems and commensurate with the risks encountered”. I might question things if either as you stated there were trends, or if the problem would result in catastrophe.

:thedeal:

Originally posted by energy
75% of our reported customer complaints is for the exact same thing. 4 different Sales people....You are right, energy, there are a lot of data entry errors out there. I think that it is appropriate to accept that, at least in the beginning.

But, I also get tired of our sales dept. using data entry errors as an excuse after we have identified it as the cause of "75%" of the complaints. Accept it as the cause, then keep an eye on future performance (both for your internal and your customer corrective actions). You and I both know that there is a reason that internal data entry errors are so high, it's just identifying whether it's commitment, training or communications. But, sometimes I think it is better to let them off the hook with data entry error and let them figure it out and fix it internally without dragging their dirty laundry out in public. It will make them feel better to think that they've found and fixed the problem without having you ram the answers down their throat.

Energy

Sounds like you have justified your reasons for accepting the CAR and it sounds like a good rationale.

As a suggestion do you think it might be a better idea not to issue CAR's on every single instance of incorrect supply, but to monitor your suppliers performance and then perhaps issue a CAR based on their performance over a period of time ?

Hope im not rambling here.

Ive seen similar kinds of things with internal CAR's that are issued for every single problem that arises. The trouble with this is that the department responsible (or acused) sees each instance as an isolated occurance, and subsequently puts in a trite CAR response. Wouldnt the CAR request carry much more clout if we could demonstrate that the problem was continual ?

Just thinking aloud.

Originally posted by M Greenaway
Energy

As a suggestion do you think it might be a better idea not to issue CAR's on every single instance of incorrect supply, but to monitor your suppliers performance and then perhaps issue a CAR based on their performance over a period of time ?
Wouldnt the CAR request carry much more clout if we could demonstrate that the problem was continual ?M.,

I haven't issued our first CAR, yet. We've identified approx. 45 Reports for several issues. We began issuing SCAR's to start our tracking of Supplier performance. So far, there are only 6. I intend to issue a CAR to Sales and Shipping with attached Pareto Charts, compliments of our Harrington Software, for all the problems reported so far. So, ineffectiveness of the CAR's is not an issue. There have been no single supplier with two SCAR's, so that the "clout" idea is also N/A. My concern is with this human error thing. You cannot foolproof a keyboard, as we all know. My concern is with an external auditor looking at the data base and seeing "order entry", "overlooked", "missed it", "my mistake" as responses from the people that the problem report went to for an explanation. These reports are for the reason of determining the application of Corrective Action through the use of CAR's. On the surface, we look like a bunch of ----ups, but compared to the amount of product that goes out the door successfully, the problems are in the 3% range. Well, off to the hospital to visit an ailing in-law. I just needed as break. See you all Monday!:bigwave:
:ko: :smokin:

In the "real world" I think human error can be a valid cause on a CAR. After all, IMHO the person who says it cannot be a valid cause just made a human error himself/herself! Yes, like anything else it can be abused and overused as a "cop-out" instead of looking deeper and finding the "real" cause, but not always.

The reason I use the "real-world" remark is that sometimes it is just not practical from a cost/benefit standpoint to implement "error-proofing" for a rare mistake. If it is life and death, sure the cost/benefit analysis is much different than for a $1 part used in an application where life-and-death is not an issue. For example, I once transposed a number on an instruction sheet that caused several thousand dollars worth of product to be made into scrap. No matter how many times I asked "why" it always came down to me making a mistake and not catching it on my "double check" of my work. It happened maybe once in a few hundred jobs like it that I had done. All of the "mistake proofing" I could envision would cost way too much to implement relative to the risk involved. I just goofed.

If an auditor says that operator error is unacceptable, maybe you can prove the point to him (if he's not the customer but rather your ISO auditor, and you feel safe doing it because he/she is not a jerk). Go over all of his/her memos, documents, etc. and find a typo or other goof (90% of the time you can). Ask him/her how that could happen -- you are the customer and you found an error, you want a CAR. Let him/her realize on their own that it was an "operator error" that the cost/benefit analysis suggests is not worth adding layers of "mistake-proofing" for. But, alas, I guess that's probably fantasy, not "real-world", huh?

Mike S.:bonk:

I'm having a difficult time with this one. I do not accept a human error on internal CA and I wouldn't report an external CA with human error as root cause. Although I agree it happens, human error isn't a valid reason IMO.
I report it as lack of mistake profing - upon review found that any further actions were not required/cost effective. It's worked for me.

Robert Nelms at Failsafe (www.failsafe-network.com) proposes that ALL root cause is attributable to human error and if you go down the line far enough you could make the case that Adam and Eve started it all. The basis for this is that only humans can interact with their surroundings and so all inanimate objects (machines, etc.) are a result of what the human has done. (This is not a literal recitation of what he has said, but in my own words as my understanding of what he said).

And since all root cause is human in nature, you should establish the first human interface with the problem and deal with the thoughts and motivations of that person. Why did he act the way he did? What was going on in his mind when he performed that act? And then you examine the way the business operates that has contributed to that action.
But recognize that it is a human that has acted and created the nonconformance. Root cause every time. So forget Root Cause and go after the "latent" causes. The hidden ones.

Big apologies to Mr. Nelms if this is not a correct interpretation. You are all invited to check out this website and read for yourself. I can't say that I agree 100% with everything he's got there (it gets pretty philosophical and too touchy-feely for my tastes) , but some of it makes sense.

Originally posted by Randy Stewart
I'm having a difficult time with this one. I do not accept a human error on internal CA and I wouldn't report an external CA with human error as root cause. Although I agree it happens, human error isn't a valid reason IMO.
I report it as lack of mistake profing - upon review found that any further actions were not required/cost effective. It's worked for me.

As you can see in your response for the word "proofing", a human error was made. Failure to use spellcheck? :vfunny: Intentional? Great weather, eh?

Anyway, I like the idea. Put the blame on something like "no mistake proofing" and move on with the "Further actions were not........" decision. Good suggestion.

I'm having a difficult time with this one. I do not accept a human error on internal CA and I wouldn't report an external CA with human error as root cause. Although I agree it happens, human error isn't a valid reason IMO. That's what I do too, and I don't have a hard time with it. Besides, most of the time you *can* find a root cause for human error: Insufficient training is probably the most common one. On the other hand: Who is responsible for poor training...? another human... Ouch!

/Claes

Let's see,

Each supplier has a rate of 25 PPM. How many parts go into the vehicle?

With all those suppliers, what would we multiply it by?

Let's say 200 suppliers, in total they have a PPM rate rate of 200.

Sorry, 200 X 25 = 5,000 ppm

A failure rate of whatever the yearly sales are divided by the

Great weather, eh?
Remember where I'm from, I would't get that stab at irony!!!!:D

Al, what are you responding too? Is that another stab at irony??

Randy,

No, I never use irony, I use Scarcasm. (hahahahahahah)

Whatever, Randy I sure hope I can meet you at the tutorial. I really want to meet at least someone fom the cove!

There are alot of people here that do what they want to do but I am looking forward to at least meeting a few of you.

When at work I am a son of a female dog, but socially I'm pretty mellow, just don't offer me a drink, Please!!!!!!!!!!!!1

Al Dyer

Lucinda is probably correct in that all errors are caused by a human somewhere along the line, but human error cannot be a statement of root cause.

As Lucinda states, having found the person responsible she would then determine the situation that caused the human to have made the error - i.e. she would then determine the root cause.

It would be impossible to take corrective action against a stated root cause of human error because it could mean anything. A root cause has to state specifically what circumstance caused the error (undoubtedly human). This could be anything from environmental conditions, to training, motivation, alchohol abuse, humour bypass surgery, etc, etc.

Okay guys and gals, if you won't accept "human error" then help me with this one from several years back...

I am highly trained -- ****, I invented the process and have trained others to do it. I am highly motivated, an Engineer with the title of Department Supervisor who is pushing hard for a promotion at an upcoming review. I'm somewhat of a perfectionist when it comes to this task, always double-checking my work. I understand the importance of the task, how it fits in with the whole, etc. I have performed this task for 2 years without a mistake - probably 300 or more "performances" without an error. Now, on an otherwise normal day, I perform this task and in doing so I transpose a number in my instruction to the manufacturing area, and I don't "see" it on my double-check, resulting in several thousand dollars loss of material and a late shipment to the customer.

What do I say if I can't say "human error"? "There was a lack of mistake proofing but it is not cost-effective to take further actions"? Will that really work? I'm serious -- no irony or sarcasm or anything else here. What would ya'll say on this one?

Mike S.

Why was the error caused ?

I have performed this task for 2 years without a mistake - probably 300 or more "performances" without an error. Wow, Mike... I have to congratulate you on that track record. What really amazes me is that you didn't make more mistakes than that. Ok, so you made a mistake... That is no big deal, it's only human.

This is a big deal: Your little mishap resulted in several thousand dollars loss of material and a late shipment to the customer. That sounds pretty serious in any buissness. What if you ( God forbid ) make more mistakes? Is there really no cost-effective way to safeguard the process better? There may be a way that cost you nothing... How hard did you look? I don't think it's fair to assume that you will make no mistakes at all. *We all do*.

This, in my mind is not a human error. It sounds like a process without safeguards.

/Claes

I agree, the operator is rarely in error. An operator is resposnible for the work they produce and therefore to allow non-conforming product out of the organisation suggests they need to be addressed in terms of the 'Escape Point' . With regards the root cause of failure you are correct in that you must look at how could the operator make the error - remember that corrective actions should only be rlevant to the magniture of the concern and therefore it should always be economic to introduce a permanent corrective action to prevent re-occurence.

The big test on the effectiveness of this is ofcourse the verification and validation of the corrective action. No matter the expense of the PCA you must be able to validate its effectiveness i.e. turn to concern on and off by the removal of the PCA. In this way you know you have addressed to root cause.

In conclusion I woudl say human error is an acceptable escape point but not root cause.

Originally posted by Mike S.
I have performed this task for 2 years without a mistake - probably 300 or more "performances" without an error. Now, on an otherwise normal day, I perform this task and in doing so I transpose a number in my instruction to the manufacturing area, and I don't "see" it on my double-check, resulting in several thousand dollars loss of material and a late shipment to the customer.

I'm gonna go out on a limb here, but my investigation would probably read pretty much like you wrote it up. I would stress the point that this was an isolated incident.

Even tho this incident cost several thousand dollars, you need to weigh several thousand against your annual sales. Your actions could consist of explaining to the person who made the mistake what kind of costs a simple error incurrs. Then I would document that no further actions would be taken and justify that by dollars it would take to re-vamp the system to mistake proof it. I would include something to the effect that we would monitor the system for recurrences of this problem, and that further corrective actions could be implemented if the error was found to be increasingly committed.

The standard only says that you need to apply corrective actions appropriate to the effects of the nonconformity. Don't fall into the trap of believing that every issue needs an expensive corrective action. You can mistake proof and correct yourself right out of business. I don't care what anybody says, we are here to make money. We believe that the easiest way to do that is to give the customer what he wants, but there are times when something will go wrong. Get over it and move on.

I would include something to the effect that we would monitor the system for recurrences of this problem

I don't think we could say it better than that.
At first glimps several thousands of dollars will open your eyes, however, in the big picture (>300 successful evolutions) there is no comparision.
Companies don't have unlimited budgets and need to place their resources in the proper areas. By chasing the 1 and 2 instances it wastes people, money, and time. These few instances must be proved out over time as SteelMaiden mentioned.

Originally posted by M Greenaway
Why was the error caused ?

______________________________________

I assume this was written with tongue firmly in cheek?

Anyway, I appreciate the ideas from everyone. I picked this example because it is a real world happening from my personal past (~ 8 years ago) and "human error" with very low chance of repeat was how I left it with my boss - the President. Thankfully, I did not have to eat my words.

As a postscript, since the time this happened computers and software have come quite far and I found a way to use them to aid in this process to help reduce the probabability of error further -- not in direct response to another error but in the spirit of "continuous improvement" and considering the substantial increase in that business. Additionally, the company grew to the point that another capable person could be hired to work the same shift which allowed the prospect of a second person to efficiently "double check" work in near real-time. In other words, as soon as it did become economically feasible to add more "mistake-proofing" I did so.

However, I fully expect that sometime in the future I will see another case (from my company or a supplier) of what I would consider legitimate human error or the occurrence of a random, highly improbable and unpredictable event that could not be economically "error-proofed", so knowing how to respond in an acceptable way is valuable to me. Just as, despite incredible odds against it, people win the lottery every day, some people also "lose" in equally improbable events.

How about this one: Responding to a false-alarm fire alarm, the fire company unknowingly goes to the wrong company on a Sunday morning. In the wrong company, a lone machinist, the best in the company, is working on a super-hot job for a customer and he is oblivious to what is going on with the fire alarm across the street. Just as he is making a critical small adjustment to the machine, three firemen burst thru the door, scaring the daylights out of the machinist who jerks the adjustment wheel so far that the product is ruined. The job is a day late and the customer has to provide more raw material. The customer wants a CAR completed. So what are the odds of that? How do you economically "mistake-proof" that? "Why was the error caused"? For me, Steel and Stew make sense saying, respectively, "there are times when something will go wrong. Get over it and move on" and "companies don't have unlimited budgets and need to place their resources in the proper areas. By chasing the 1 and 2 instances it wastes people, money, and time". But I am still open to reading other opinions.

Mike S.

Companies don't have unlimited budgets and need to place their resources in the proper areas. By chasing the 1 and 2 instances it wastes people, money, and time. These few instances must be proved out over time as SteelMaiden mentioned. Agreed... Always aim your resources towards the worst problems first.... and if this is not one of them: Just put it behind you. ( I actually read this one as a biggie. Obviously it was not ).

/Claes

Ok.... I guess I have to play devil's advocate here....

If we say that "operator error" is not an acceptable root cause, how much can we "mistake proof" the process before it becomes financially untenable?

Cheers!!!

Mike
Why keep it to “operator error”? Even better, make it more general and call it all “human error” after all humans designed the product and processes and without “humans” there will be no errors. Call it all “human error” and move on to work on more important things.

On a serious note:
Looking at the Ishikawa tool, for example, will lead to look at other causes under the “operator” leg. If you accept “operator error” you will have to accept “equipment”, “materials” and/or “equipment” without further explanation as root causes.

If you are really looking to prevent nonconformances you will accept “human errors” as a root cause very rarely. As a QIP trainer the first thing we teach is to remove the operator from the equation. Bring the operator back into consideration only after all the other possible causes have been considered.

If you are really looking to prevent nonconformances you will accept “human errors” as a root cause very rarely.

Rarely, yes. But not "never". :yes:

Human error is not a suitable root cause in my view, because one needs to focus on what to do to avoid repeating the error. The result of that focus is (should be) the true root cause.

I've attached a paper on this subject (http://elsmar.com/Forums/showthread.php?t=12122) in The Reading Room. It covers various aspects of error, as in not following procedures.

I would say "yes" if that operator had been thoroughly trained, acknowledged the training, all the right equipment and instructions, then still did not follow the instructions. if the corrective action included either dismissal, or re-assignment.
We have had such occurrences where people just refused to do their job no matter what, but rarely.

Ralph and Jennifer,

So, in the scenerio I outlined in post #49, what would you put down as the root cause?

Regardless of anything I may have otherwise contributed on this topic, it occurred to me today that our focus on the term "error" puts undue emphasis on a continual or repeating nonconformance by a human as a voluntary act rather than considering a one-time or otherwise extremely rare accidental or involuntary act by the individual.

I heard a long radio commercial on a drive earlier today by a jewelry chain specializing in diamonds in which they discussed the combined experience and expertise of their own diamond cutters. As I drove, I thought, "Yeah! What happens if the guy has an involuntary muscle spasm just as he brings the mallet down onto the chisel? What good is all that experience? Time to rethink the plans for the remains of the diamond!"

The root cause of the nonconformance [diversion from the planned outcome] is probably not attributable to management planning or employee training. IS IT FAIR TO LABEL THE EVENT OPERATOR "ERROR?"

Excluding events beyond human control, I can see that there are situations where "Operator Error" could be a root cause. But only after the question "why?" is raised a few times. I would not accept "Human Error" as a first response. Too many times, "Human Error" is used just to get the corrective action request "out of our hair" and then on to the next one....
I believe that errors occur because of the action or inaction of people, but it may not be the person we first think of.

Stijloor.

Mike, I once knew a very smart plant manager who ruined a copper billet on a drilling tool because he made an error--that one time he failed to check the material (those billets looked alike after the exterior machining, yet some were cast and others were forged, and these each had their own hole patterns.) and the error cost several thousand dollars. He had done this task many times and this was the first time the error happened on this part.

I had been pressing for material identification for some time, but was always met with "I don't want to bureaucratize (sp?) the quality system."

As is human nature, after that event the top management dreamed up the idea of identifying this material. (The practice didn't extend to the rest of the round stock, but that probably came as they went through the ISO registration process) They just used printed sheets of paper saying "Cast" or "Forged" and taped them on the billets' protective cover.

My point is that an effort to mistake-proof is rightly made using the cost of getting it wrong as an argument. I understand your point about transposing a couple of numbers. I do it all the time. You say your error cost thousands. I don't remember reading how often you do this activity, and how much time would have been needed to bring someone else to glance at your work...if that would have been cost effective over time.

Would it have helped to have to write down the number somewhere?

Are other people having this problem too--how might you learn if they are?

Are these two numbers always so nearly alike? If so, can one of them be changed to a different number?

Such questions are the kinds to ask to see if something can in fact be avoided. Sometimes, I'll grant you, we just make a mistake. That's true, yes. I make mistakes all the time...:rolleyes: My worry with saying "Yes you can use human error as root cause is that it will become low hanging fruit and the needed effort to tighten the process or discipline will not be invested in.

I rather equate the term with "Needs more training." I cringe when I see that put down as a root cause, because although sometimes it really is true, based on my background I am convinced it's used far more often than what is appropriate.

I hope I answered that okay.

What happens if the guy has an involuntary muscle spasm just as he brings the mallet down onto the chisel? What good is all that experience? Time to rethink the plans for the remains of the diamond!"[/I][/COLOR]

The root cause of the nonconformance [diversion from the planned outcome] is probably not attributable to management planning or employee training. IS IT FAIR TO LABEL THE EVENT OPERATOR "ERROR?"

Interesting example, Wes.

Well, the human was at fault. By definition he could not control this particular happening, but it was a human fault (or should we say frailty?) that caused the defect.

If you wanna be extreme about RCA, I guess you could say that God or “the Big Bang” is the root cause of everything! But from a practical sense that does us no good.

In my example, yes, I could have gone on and said the root cause was no automated system or extra staff was available to check my calculations or the (transposed) number that I had written down on the shop instruction. But in reality, at that time it was not practical (economically feasible) for the company to do that, so what do I do as a corrective action? What good does it do us to have perfect quality if we lose money and go out of business?

In the “real world” we all deal with risk/benefit situations and sometimes we assume some risk and probability bites us and an error occurs. IMO sometimes that error is reasonably called a human error that could not have been economically or practically prevented. Yes, if you use “human error” for more than, say, a few percent of your root causes, you’re very likely missing some other things that should be addressed. But I have yet to see a persuasive and practical argument that says human error is never an acceptable root cause. JMO

In my example, yes, I could have gone on and said the root cause was no automated system or extra staff was available to check my calculations or the (transposed) number that I had written down on the shop instruction. But in reality, at that time it was not practical (economically feasible) for the company to do that, so what do I do as a corrective action? What good does it do us to have perfect quality if we lose money and go out of business? Please forgive me for jumping in.

My next question is, what is used to write your shop orders? Is it all handwritten on a photocopied Word document, or do you use some software?

If it's routinely handwritten on a word document, how often is this done? If these are stored as some kind of job record for each customer, how is that done?

If calculations are being done, are they so complex that a spreadsheet can't do the math for you? Who can do them when you're not there--how can you tell if the math is being done right by another person?

The place where I am going is this: if the job order is manually written down it might be useful to make a printed copy with a spreadsheet template. By automating the process in this way three things are done:

1. The math is consistent and less mysterious for a substitute
2. The job order can be more easily read by the operator
3. The spreadsheet can easily be saved as a record of the job (as a web page if you want to be able to prove the formula or enything else was never changed).

Would this kind of solution be suitable?

Access can also be programmed to do formulas, but I do not understand how to do that. It's something I want to learn.

As an MR I audit my organization's different departments.
Each time when I audit I found that she fills operator's error..........warned the oerator is the corrective action.
Now my question is how to deal with this situation. I want to deal with it since this kind of root cause & corrective actions are not acceptable to external auditors.
:thanks:

As an MR I audit my organization's different departments.
Each time when I audit I found that she fills operator's error..........warned the oerator is the corrective action.
Now my question is how to deal with this situation. I want to deal with it since this kind of root cause & corrective actions are not acceptable to external auditors.
:thanks:This is time for the auditor to help the process owner understand what's going on by using the 5-why method. It also helps to fill in some blanks to "connect some dots" like:

1. Where did the error occur?
2. Is the error being made by the same person? If so, what percentage of the time?
3. Is the type of error being made in other processes? If so, how much of the time and by which people mosat often?
4. Is the operator truly qualified? That is, is literacy a problem or is the operator perhaps working in the wrong job?
5. Does the procedure, as it is written make sense in the same way to everyone? Does it pass the "straight face test" or do people feel it is too restrictive for some reason? And if that's the case, who are they and what do they feel should be different?

In my view it's okay for the auditor to help people work through this process. It is not taking control; it is facilitating. The auditor can take notes and present them to the process owner for determining the next steps for an adequate solution.

Very often the person closest to a problem will be the last to recognize there is a problem. Such a person really needs some facilitation. I choose not to use the word "intervention" because it implies that person is deficient somehow. That is not guaranteed; it is simply a fact that we can use an outsider's help to recognize an opportunity.

Unless we manage to do that somehow we can expect repeats of the same problem and a continued loss of profits while that happens.

:2cents:

While we all know that occasional human error is unavoidable, calling it the root cause of a problem is saying that your organization doesn't embrace continuous improvement, error proofing, etc. Corrective actions are to correct systems, and human error is not part of any system I've heard of. The more we react to "human error" the more robust our process becomes - and the less temptations we will have to stop at "human error" when writing future corrective actions.

Corrective actions are to correct systems, and human error is not part of any system I've heard of.

Welcome to the Cove, Fred. :D

I think that in an ideal system there would be no human error, but how many are ideal? I certainly agree that all potential causes should be eliminated before ascribing anything to human error, but there are times when that's exactly what it boils down to, and there's no getting around it in some cases. Furthermore, I firmly believe that people must be allowed to make mistakes, because mistakes are a prime source of learning and improvement.

Like Laura, I believe that if operator error is defined as the root cause, it really defines a management problem. Either the operator wasn't properly trained, was promoted without appropriate skills, or the process was not sufficiently mistake proofed.
:2cents:
1. There is no such thing as "Mistake Proof"!
2. Operator Error is real!
3. If you think numbers 1 and or 2 are wrong, your wrong. ;)

1. "Mistake Proof" or a favorite saying of others, "Idiot Proof". This is a fable and impossible to obtain even on the simplest of processes. Example: Forming Staples and or Paper Clips.

2. Human Error is a fact of life and is impossible to remove from processes due to the necessity of required human interaction.

We create, therefore we error!

Disclaimer:
This is my opinion and only my opinion, this doesn't mean all other opinion's do not apply, except for my opinion. :lmao:

Please forgive me for jumping in.


If it's routinely handwritten on a word document, how often is this done?

If calculations are being done, are they so complex that a spreadsheet can't do the math for you? Who can do them when you're not there--how can you tell if the math is being done right by another person?

Would this kind of solution be suitable?

Access can also be programmed to do formulas, but I do not understand how to do that. It's something I want to learn.

Jennifer,

Post #55 might answer a few of your questions. See, this event that I described happened in ~ 1994!

Also, just because "human error" is listed as a root cause, it does not preclude performing CA that goes beyond doing nothing. It may well include automation, computers, double-checks by others, etc. And it eventually did for me.

This is what I have a problem with too. A machine produces 7,600 stampings an hour. We ship 9,000,000 parts in one year. The customer finds one bad part and returns it with a DMR and Vendor Corrective Action Request. This part costs a very small fraction of a cent. I refused to fill out the VCAR and said that our company considered this acceptable fallout. How do you determine good quality practices from nonsense?

Doug

Jennifer,

Post #55 might answer a few of your questions. See, this event that I described happened in ~ 1994!

Also, just because "human error" is listed as a root cause, it does not preclude performing CA that goes beyond doing nothing. It may well include automation, computers, double-checks by others, etc. And it eventually did for me.We can parse this subject all day, but if automation was done that reduced errors, arguably root cause was not the errors--instead it was the underlying reason why people were making the errors. The error is the symptom.

When I submit a SCAR to a supplier I generally state in my correspondence that Human Error is not an appropriate response.
I think that many suppliers use Human Error response to complete the paperwork and get the customer off of their back. This “corrective action paperwork” is just paperwork.
Yes a human may have made an error, yes this may have been 1 out of 9,000,000. If there is no action to be taken that is OK, just please explain to me on the corrective action paperwork why it is not needed. This may help me to properly understand your process.
But in looking beyond “human Error”, the supplier might just ask themselves some basic (dumb what ifs), and find a simple solution to eliminate the nonconformance from recurring.


Phil

Yes a human may have made an error, yes this may have been 1 out of 9,000,000. If there is no action to be taken that is OK, just please explain to me on the corrective action paperwork why it is not needed. This may help me to properly understand your process.


I want to understand this, because I've been faced with this situation as a supplier. It seems to me--and please correct me if I'm wrong--that you have a CA system that demands answers from suppliers even when obvious outliers are involved, regardless of the cause. What improves as a result? Why not just pick up the phone and say, "We got a bad one and thought you'd like to know about it"?

Jim,
My response of 1 in 9,000,000 was picking examples that were already used. I used this as if the customer has received a CA with this type of example. The customer may be working from a procedure that dictates a CA be issued for any defect found, or by a new QA person trying to make their mark.
For what ever reason this needs to be an interactive communication between the customer and supplier.
I recently rejected a CA from a supplier that was going to add inspection process to solve a problem of a Human miss-marking a wire assembly. I though OK, but how about the possibility of segregating the like assemblies to avoid cross contamination (there are about 20 different configurations of this assembly). The supplier evaluated the suggestion and was able to implement the suggestion, SCAR now closed.
Phil

Welcome to the Cove, Fred. :D

I think that in an ideal system there would be no human error, but how many are ideal? I certainly agree that all potential causes should be eliminated before ascribing anything to human error, but there are times when that's exactly what it boils down to, and there's no getting around it in some cases. Furthermore, I firmly believe that people must be allowed to make mistakes, because mistakes are a prime source of learning and improvement.

Thanks, Jim. I think you and I fundamentally agree. My perspective is influenced by past experiences with managers who are too quick to end their root-cause analysis with "operator error" when there seem to be clear opportunities for error proofing and process improvement that would at least lessen the chances of the operator error. Your belief that people need to be allowed to make mistakes is certainly valid. I just hope everyone who makes mistakes actually does see it as an opportunity for learning and improvement.

When I submit a SCAR to a supplier I generally state in my correspondence that Human Error is not an appropriate response.
I think that many suppliers use Human Error response to complete the paperwork and get the customer off of their back. This “corrective action paperwork” is just paperwork. Phil

I allow error as a cause with the supportign investagtion that demosntrates that it was indeed an error and not a result process variation. Only with strong objective evidence will I allow "discipline of the operator" as a corrective action. I rarely allow "retrained the operator" as a corrective action. This only works when the opertor intentionally does something that turns out to be wrong. in this case the operator usually thinks they are doing the right thing and education as to why their action caused a defect can and will improve the situation. If the operator is willfully doing something wrong then disciplinary action is warranted - but this is rare overall.

Human error is frequently the cause of many defects (defects come from either human erorr or variation of processes, raw materials, etc.)

true human error - as opposed to an intentional action that was well intentioned but misguided - is almost impossible to directly affect - even with training and education because the error isn't intentional.

I DO require that corrective action be taken for the error: either the conditions that contribute to making the error (workplace organization, environmental conditions, working too fast) or to mistake proof against the error.

Unlike a previous poster, I have found many situations are well suited to simple and cheap mistake proofing that do eliminate or significantly reduce the error occurence. (of course very few mistake proofing schemes are effective against willful actions)

I am also very cognizant of the difference between the isolated one time occurence and the repeated error. A muscle spasm is one thing, a part that that can easily be assembled in the incorrect orientation and is frequently mis-asembled is another. and the severity of the defect must be taken into account. Occassionally my organization or my suppliers will expereince a series a isolated errors that cause different defects. If this level is unacceptably high or the severity of the defect types is high, I will look for corrective action that addresses detection of these defects so that I or my customers don't suffer...

Since many of us agree that a Corrective Action is sometimes not truely cost effective or sometimes just an exchange of paperwork to meet compliance, why can't we come up with some form of Notice of Defect (N.O.D) whereby the vendor acknowledges the defect but both parties agree that a full blown investigation and process change is not in the best financial interest of either company.

(How is that for a run on sentence? :))

Since many of us agree that a Corrective Action is sometimes not truely cost effective or sometimes just an exchange of paperwork to meet compliance, why can't we come up with some form of Notice of Defect (N.O.D) whereby the vendor acknowledges the defect but both parties agree that a full blown investigation and process change is not in the best financial interest of either company.

(How is that for a run on sentence? :))


:tg:It was "silentrunning".......

:tg:It was "silentrunning".......

"With a deafening silence"..........if at all you are able to hear it .....no no ....Better listen it. ;)

Since many of us agree that a Corrective Action is sometimes not truely cost effective or sometimes just an exchange of paperwork to meet compliance, why can't we come up with some form of Notice of Defect (N.O.D) whereby the vendor acknowledges the defect but both parties agree that a full blown investigation and process change is not in the best financial interest of either company.



This would never work!!!
It makes to much sense. :lmao:

I have to agree that operator error is not a valid root cause, although the operator may be at fault. As stated above, people make errors regardless of training or experience. When presented with any problem, a solution is the required action. Naturally, the solution should incorporate corrective measures if the problem should ever arise again so that the problem can be handled more efficiently, but more importantly preventative at its core. Root cause analysis is merely a method employed to target the problem at which to aim your solution. My opinion is that too much emphasis is being placed on the root cause when its the solution that is most important.

I have to agree that operator error is not a valid root cause, although the operator may be at fault. As stated above, people make errors regardless of training or experience. When presented with any problem, a solution is the required action. Naturally, the solution should incorporate corrective measures if the problem should ever arise again so that the problem can be handled more efficiently, but more importantly preventative at its core. Root cause analysis is merely a method employed to target the problem at which to aim your solution. My opinion is that too much emphasis is being placed on the root cause when its the solution that is most important.

Could not DISagree more...

Root cause should not be confused with solution. Root Cause isolates the cause of the problem, so we can determine the most effective solution(s). Unless I understand the cause, I may not identify the best solution. How would I even recognize the best solution if I don't know the cause, unless it is patently obvious. And, if it is patently obvious, why am I filling out a form?

So yes, ultimately, the solution is more important than the root cause, but the root cause points to the right solution. Without that, I have seen too many examples where the actions taken were ineffective, or where 10 actions where taken (carpet-bombing) in the hope some of them would be effective.

I recommend precise, surgical corrective actions based on understanding the causes. Don't forget however, that the amount of time invested in this exercise, should be proportionate to the level of risks involved. It would appear, on that point we would in fact agree.
Yes, people make errors sometimes

I have to agree that operator error is not a valid root cause, although the operator may be at fault. As stated above, people make errors regardless of training or experience. When presented with any problem, a solution is the required action. Naturally, the solution should incorporate corrective measures if the problem should ever arise again so that the problem can be handled more efficiently, but more importantly preventative at its core. Root cause analysis is merely a method employed to target the problem at which to aim your solution. My opinion is that too much emphasis is being placed on the root cause when its the solution that is most important.

I would add that we never use the words "operator's fault". After all this is a search for root cause not root blame and words do hurt.
further more true errors (unintentional actions like picking up the wrong screw as opposed to knowing it's the wrong screw and picking it up anyway because the operator doesn't think it will matter) are not truly the operator's fault. we all do things unintentionally. and error proofing is a recognition that we can't fundamentally change this behavior for any period of time.

And I do agree that without understanding root cause you don't know which solution will work. going into a corrective action with a solution in mind and disregard for root cause is called guessing.

I would add that we never use the words "operator's fault". After all this is a search for root cause not root blame and words do hurt.
further more true errors (unintentional actions like picking up the wrong screw as opposed to knowing it's the wrong screw and picking it up anyway because the operator doesn't think it will matter) are not truly the operator's fault. we all do things unintentionally. and error proofing is a recognition that we can't fundamentally change this behavior for any period of time.


You can bet I'm going to plagiarize that!:agree1:

I have read an article about Toyota a long time ago, where it was written something like: the root cause is never an "employee mistake", but a system that allows him to perform something incorrectly. We must "correct" the system (poka-yokes), not the person.

I have read an article about Toyota a long time ago, where it was written something like: the root cause is never an "employee mistake", but a system that allows him to perform something incorrectly. We must "correct" the system (poka-yokes), not the person.

In most cases, that is correct. Therefore, it is better to begin with the system. Sometimes, once in a while, it really might be operator error. Then, you should use that root cause. But, always begin with the system.

I have read an article about Toyota a long time ago, where it was written something like: the root cause is never an "employee mistake", but a system that allows him to perform something incorrectly. We must "correct" the system (poka-yokes), not the person.

There is a significant difference in the Toyota Way of thinking about the cause of mistakes. The conventional thinking is that "People make mistakes", and "If people paid attention they would not make so many mistakes". This thinking tends toward identifying the cause of mistake as 'human error', while the Toyota Way start with the assumption that an error is a failure of system and methods that are used to perform the work. Quite simply error occur because the current method allows them!!

This difference in thinking shifts the responsibility for errors from people to method, and also shifts the blame for mistakes from people to systems. When people are spared from the blame game, they are free to focus on creating more effective systems and actually solving problems, rather than defending and shielding their own skins. It is common within Toyota for a manager to appologise to a worker when an error occurs, because management bears the responsibility for creating a weak system!

Toyota way philosophy considers 'The operator' as the most important asset and showing 'Operator mistake' as the root cause of a problem is a taboo. Toyota also profess to 'Focus on the work, not on the operator'. In short, their emphasis is on making the system which leaves no room for operator error.

(Reference: THE TOYOTA WAY by Jeffery K.Liker & David Meier)

Umang :D

Very interesting discussion going on here. I have dealt with this issue for many years, I mean a lot of them. The fact of the matter is that it has become a crutch for many of those assigned the responsibility of investigating these CARs. It is, and should continue to be a step along the way of determining the root cause but not a stand alone, because it can always have a reason why there was operator error. I will tell you another crutch in this area and that is "Trend Analysis". This is given in many cases when the investigator doesn't feel there is enough data to make an immediate decision as to root cause. Well, how much is enough? Again, used way too much in situations like this.

I have and will continue to accept operator error as a resopnse if and only if the individual can provide the road map that lead them to this conclusion and that map has key factors identified and evidence of investigation. I can't accept it as being a scape goat or one answer fit's all. To many times I have found that if I do true verification of supplier corrective actions I find that these roads where not traveled due to other constraints (time, resources, etc..) if that is the case the CA answer is not helpfull in resolving the root cause. jmho

Since many of us agree that a Corrective Action is sometimes not truely cost effective or sometimes just an exchange of paperwork to meet compliance, why can't we come up with some form of Notice of Defect (N.O.D) whereby the vendor acknowledges the defect but both parties agree that a full blown investigation and process change is not in the best financial interest of either company.

(How is that for a run on sentence? :))

Usually I mine this resource to gather insight rather than offer input (being long in tooth to manufacturing but new to Elsmar Cove and quality assurance).
In reference to post #80 Silentrunning, we actually use a “Notification of Discrepancy” that has two choices that can be checked. One requires a CA and the other that is simply a notification. We do track these just in case a supplier tends to be a “repeat” offender.:agree1:

Operator Error is one of the most over used root cause categories, usually because the corrective action is a no-brainer....retrain. When trending, if one of your largest root cause categories is Operator Error, an auditor may challenge your conclusion....or even worse....question the competence of your people. I experienced this during an FDA audit....if they see that you're constantly retraining your employees (especially the same ones) it will only lead to more questions. I would recommend taking the time to understand why an operator error occurred....was it because the SOP was poorly written or the training the person received lacking, etc.

Umang is spot-on! WTG:applause:

There may be isolated errors - but of course, we should be striving to design systems that do not allow errors to happen in the first place. While this is not always possible, it is certainly something to strive for. Retraining may or may not work; there is always the chance that an employee didn't understand or is not suited for the job. If retraining doesn't work, that's an indication that management has designed a system that will cause people to fail - whether it be that process, or the process for placing people into the jobs! (HR won't like that, I'm sure!)

Nothing frustrates me more than seeing a response to corrective actions "Spoke to operator" over and over again. Well a lot of "spokes" means something else is wrong and putting notes in people's files and belittling them will not solve the problem.

Mistake-proofing processes does not have to be expensive -

Those are the :2cents: from Penny :bigwave:

I have and have had several customers who will not accept "operator error" or "will retrain" as a response. There logic is simple and yet useful if you follow it to the root cause.
"operator error" - Why? Using the five why concept (more less than 5 is acceptable) as it drives towards the real cause of a problem. The biggest road block I find here is "we were short of time or people and they were filling in". Finding: Management commitment to resources to meet my (customer) requirements. I am not saying that there is not operator error associated to problems I am suggesting that it is a contributing cause not a root cause.
"will re-train" - Weren't they trained and found competent to do the job before they worked, processed or shipped my product? Finding; Training.
I am not saying these are never acceptable response but they should not be the first. There should be evidence that they problem had been evaluated, analyzed, communicated and corrected. Find that evidence and you will be doing customer, supplier and yourself a value added activity.

My opinion.

I think to first proclaim that operator error is never an acceptable response, every process should be able to be certified operator proof. Just go right down the process flow and show how it is impossible for an operator to influence each and every characteristic. Then, you are good. That likely means eliminating the operator altogether, perhaps an acceptable corrective action. :rolleyes:

No matter how well you write the work instructions, not matter how many times you validate the training, humans have the ability to be distracted or lose focus. When that occurs, errors can happen. This is partly the cause of 100% inspection not being 100% effective. Not every process can physically be poke-a-yoked to the true definition, anyway. A fully poke-a-yoked process is nice work if you can get it. (And be sure to check your poke-a-yokes to be sure that they are still working...oh, wait...can you do a poke-a-yoke to prevent someone from forgetting to check the poke-a-yokes? That will keep you awake tonight...) Saying that operator error is never a root cause is just as sloppy of an analysis as using operator error for every root cause.

Sorry for not trotting up the high road. Just keepin' it real. :cool: