Any body could help answer my questions??

Is it proper to list operator mistake like "operator didn't follow the procedure" as the potential cause(s) / Mechanism(s) of failure?
If so, the what kind of recommended action can put whereas the potential of failure mode have high RPN? :thanks:


Regards,
Ceplox

Any body could help answer my questions??

Is it proper to list operator mistake like "operator didn't follow the procedure" as the potential cause(s) / Mechanism(s) of failure?
If so, the what kind of recommended action can put whereas the potential of failure mode have high RPN? :thanks:


Regards,
Ceplox


There are times when Operator error probably was the root cause, but it is not so common. The problem is so many people just stop there, and never find the system root cause. For example did the operator have the required skills, knowledge, etc? Did we communicate the right way to do it? Explore the other options first.

If I write a number incorrectly, that might be an example of an operator error.

Let's say that we did communicate the right way to do it to the operators, then the problem still happen, in my opinion it is pretty difficult to define the recommended action. Any suggestions? :frust:

Let's say that we did communicate the right way to do it to the operators, then the problem still happen, in my opinion it is pretty difficult to define the recommended action. Any suggestions? :frust:

Investigation should include discussing with the operator. Did he know the right way, but chose to do it the wrong way? That is not an "error." That was intentional. Did he think his way was better? Was he lazy? What was his reason. Investigate it.

Many kind of thank you. :)

Well said hjilling. We (Hope most of us) do it often. But there are cases, where operator do 99 numbers correctly and number wrongly. What would you suggest on that?

I strongly say all the problems need to be jolted down.
here we go....
Have a brain storming session, include operator,inspector,shift engineer,if possible manager aswell... make a note of all the possible reasons which may have lead to this problem..after its done eliminate the ones which may not have lead to this problem and then surely you will land up in having one major reason for the issue..and 99.99% of the times you find that there will be a loop hole in the system itself, I mean to say procedure not well defined, incapable operator working on the job, tools or fixtures not okay....and so on.... there should be a fool proof system or procedure or fixture...there should be room for the operator to assume things and work, everything should be crisp and clear....

Let's say that we did communicate the right way to do it to the operators, then the problem still happen, in my opinion it is pretty difficult to define the recommended action. Any suggestions? :confused:

How would you really know that you did communicate this to the operator? Wouldn't this fall under "training" instead of "operator error?"

Because if you have explained (trained) this to the operator, just maybe the operator didn't understand, or the point wasn't conveyed in such a way that the operator understood. There could be some other underlying issues involved.

This would require a more in-depth analysis (RCA). My point here is, that there could be more issues at hand then what your initial investigation has revealed.

That is what I wa strying to tell...99.99% of times no doubt there is a loop hole in the system itself, it may be procedure,incapable operator on job,fixture....and so on... need to have a fool proof system....
do a 5Why Analysis...and identify the cause, have a robust corrective action and your problem is solved....

That is what I wa strying to tell...99.99% of times no doubt there is a loop hole in the system itself, it may be procedure,incapable operator on job,fixture....and so on... need to have a fool proof system....
do a 5Why Analysis...and identify the cause, have a robust corrective action and your problem is solved....

Then I agree with your assessment. :thanx:

Well said hjilling. We (Hope most of us) do it often. But there are cases, where operator do 99 numbers correctly and number wrongly. What would you suggest on that?


If he is a good operator, and knws how to write the number correctly, and usually does (99 times out of a 100), then maybe it is an "operator error." Training will not eliminate that. If however, he does it more frequently, then maybe carelessness, not checking work, etc. might be the root cause.

This kind of situation cannot be helped with training. Mistake proofing might work.

Let's say that we did communicate the right way to do it to the operators, then the problem still happen, in my opinion it is pretty difficult to define the recommended action. Any suggestions? :frust:


It would be difficult to define the recommended action, because you have not determined the root cause. You would only be guessing to the solution.

That is the whole point of the corrective action process. Deterrmine the root cause first, then determine the actions needed to eliminate the cause.

Here's the bugaboo - Any time an operator is involved in your process, there will be an "error" at some point in time. While "Zero defects" is a wonderful goal, it just ain't gonna happen in the manufacturing world without major capital invested. FMEAs can become very cluttered when Potential Causes come down to "Operator error" but it is inherent to any process that has operator involvement. While the automotive world doesn't like to see "Operator error" as a potential cause, the fact remains that it is an issue. Rectifying that is a management decision ($$) and there are times where the cost to "fix" the issue just can't be justified. You can do all the Root Cause Analysis you want, but at the end of the day you still have an operator that can bypass whatever you have set up in your process and it IS a Potential Cause.

Sorry, my day went down the shi$$er early today on just this type of issue. TGIF:bonk:

I can't add much to Bill's reply, because he pretty much nails it. Speaking from a customer perspective, I like to see that for any given operation, the reasonable potential failure modes have been considered. In the brainstorming that should be a part of the PFMEA process, all sorts of things might be considered, and some of them will be discarded as just too unlikely to bother with. A swarm of locusts might engulf the line and disrupt operations, but probably not. On the other hand, as Bill so perceptively points out, human participation always allows for human error, and some times it does cause defects. This is not to say that we shouldn't take a deeper view and make sure that there isn't something upstream that can cause the error, but in the end, we're left with humans being human sometimes.

Here's the bugaboo - Any time an operator is involved in your process, there will be an "error" at some point in time. While "Zero defects" is a wonderful goal, it just ain't gonna happen in the manufacturing world without major capital invested. FMEAs can become very cluttered when Potential Causes come down to "Operator error" but it is inherent to any process that has operator involvement. While the automotive world doesn't like to see "Operator error" as a potential cause, the fact remains that it is an issue. Rectifying that is a management decision ($$) and there are times where the cost to "fix" the issue just can't be justified. You can do all the Root Cause Analysis you want, but at the end of the day you still have an operator that can bypass whatever you have set up in your process and it IS a Potential Cause.

Sorry, my day went down the shi$$er early today on just this type of issue. TGIF:bonk:

Bill,

Totally agree with you. Human will make mistake definitely. If the potential root cause is "operator mistake", we can consider some "error- proof" methods to prevent from happening or some detective actions to limit the loss as much as possible.

Without being guilty of a rush to judgement myself (easy to do when the symptoms seem to match a common disease), let me try to add some perspective here.

Experience often follows Occam's Razor which says that management is ultimately responsible for the work instruction, the work conditions, the operator training, the tools and instruments used, and the quality and sufficiency of the raw materials. The operator has such a small area of responsibility there is an overwhelming probability the plans , etc. of management will yield the real root cause of a nonconformity (i.e. the glitch in the system which gave the operator an opportunity to create a nonconforming part, record, or service.)

Is there a possibility operators may transpose numbers or misread gages? Has management tested eyesight? tested for dyslexia?

Possibiity operators are tired and have mental lapses?
Has management provided adequate breaks? Do hungry workers get enough pay to buy food to have sufficient energy to get through the day?

Angry employee sabotage production? Was he angry BEFORE hiring? Is sabotage retaliation for abuse or exploitation by manager or coworkers??

Bottom line: Rarely is the REAL root cause limited to "operator error."

Wes has asked the questions I was about to ask. :applause: And I bet he was waiting for me to chime in...

Step 1. Was it intentional? And if so, why? Does the operator think there's a better way? Or something is missing that he needs? Get the details.

Step 2. If it wasn't intentional but the errors repeat, ask why. Some people have trouble following spoken instructions. Others have trouble following written instructions. Sometimes the instructions, if written by an engineer, are hard for almost anyone else to understand.

I have a paper on this subject here: http://elsmar.com/Forums/showthread.php?t=12122

People with these conditions (and there are namy others) are more likely to be diagnosed in Western countries than Eastern countries, but I suspect the conditions are still there and causing problems somewhere. If the worker is otherwise valuable, the effort to correct these problems may be worthwhile.

I hope this helps!

My thought here:

Given the idea that 94% of the issues within a system are management controllable (W. Edwards Deming), it seems to be supported by many of the posts here. Equally true, 6% of the time, issues are attributable to the individual. Some of these issues may be from a willful disregard of standing policies and practices. Other times, the individual is not aware of the departure, as noted by the references to mental health conditions an individual might have. Physical issues may also manifest themselves negatively.

In short, I agree that in some instances, operator error may be at the root of the issue. I will also add that employee sabotage doesn’t fit my definition of an operator error as this is a willful disregard to policy, practice and values.

Good thoughts folks!

Kevin

Nice to see you post, Kevin. Re: sabotage - unless you do in-depth root cause investigation and analysis, how will you know sabotage from mental illness?

Nice to see you post, Kevin. Re: sabotage - unless you do in-depth root cause investigation and analysis, how will you know sabotage from mental illness?

Or that sabotage isn't the result of mental illness? Or vice-versa. Or...
"Human error" shouldn't be construed as being limited to only the random, "oh, shite!" variety. Think of it as something a human does that causes a nonconforming condition. The various varieties may be dealt with separately, all under the big "human error" tent.

A friendly word of advice: It's probably best to not include references to mentally ill employees in FMEA documents sent to customers, even though it might serve the purpose of limiting the number and duration of customer visits to your facility.

All of the discussion regarding determining root cause of operator is nice to see, particularly if it gets management and engineering to acept the fact that all humans makes errors. (or erros as I just mistyped it - have fun with that one guys!)

The science of mistake proofing is directed, primarily, not at the root cause of errors, but at preventing the error from becoming a defect. It is notoriously difficult to controil errors by training, education, discipline, etc.

Let me give a generic example:

If two similar bolts are present at a workstation, no matter how well you train the operator or label the parts or 5S the workstation the operator is still vulnerable to picking up the wrong bolt. (You could move the different bolts to different workstations, but some assemblies don't lend themselves to this and there is still some residual prossibility of an error if you are short on headcount one day and need to combine operations, OR if material handling delivers the wrong parts to the wrong workstation...) If you mistake proof the bolt or fastener style and geometry, such that the wrong bolt simply cannot be installed even if the operator mistakenly picks it up, then you have mistaked proofed against the OUTCOME of the error. This is far easier to control than going after the cause. It is also 'harder' work for the engineer and supervisor... The operator can of course deliberately overcome this but then we don't have an error -we have a deliberate action which is much rarer than errors and requires management intervention...

I recommend: "Make No Mistake!: An Outcome-Based Approach to Mistake-Proofing" by C. Martin Hinckley. It drones on a bit and has some extraneous fluff, but it has some great examples of msitake proofing for the resutl of hte error and not the root cuase of the error.