PFMEA (Process FMEA - Potential Causes and Failure) - Operator's Role

[MasterBB]

Potential cause of failure is defined as an indication of how the failure occur.

Should you avoid mentioning the operator or is it a common practice that some include the operator within this Column (Potential Causes of Failure)?

Examples: A. Operator error; inadequate operator quidelines specified.
B. Operator does not properly assemble part x into Y.
C. Don't mention the operator.

What do you think?
Do you include the operator as seen in A&B?
Or you would rephrase it otherwise & not mention the operator.

Looking for some best practices on the subject.

What do you think?

Thanks in advance

 

[Duke Okes]

Re: PFMEA (Potential Causes/Failure) - Operator's Role

A. Operator error; inadequate operator quidelines specified.
B. Operator does not properly assemble part x into Y.
C. Don't mention the operator.

"A" is not actually an operator error. if they followed inadequate guidelines it would be an error of the person who developed the guideline.

"B" might be operator, but it depends on why s/he improperly assembled the parts. For example, could it be because a part was incorrectly presented to the operator by the supplier (e.g., packaged in wrong orientation).

So I would tend to leave the operator out, and just mention the error that might occur. However, remember that pFMEAs normally assume that all previous process steps were done correctly, so "A" typically would not be listed, while "B" would, but generically (improperly assembled), since cause of improper assembly would be unknown until root cause analysis was conducted.

 

[erozas2003]

The main objective of PFMEA is to identify failure modes and the potential causes, and then evaluate risks. In my experience is a good practice to document operator failures as operator error, then the other indicators of PFMEA (severity of failure, occurrence and current controls) will lead you to the operations that need to be improved.
I heard in the past that we cannot fix operator errors, but we should fix the system to avoid that the operator make mistakes, we need to make error proof process, PFMEA is an excellent tool to assess your process and implement improvements.
Regarding the options A, B or C... I think that you need help of a crossfunctional team that includes operators; they really know what problems may occur on each single step of the process. If you are making PFMEA in the office or just not including operators, you will not see all potential failure modes

Regards.
Lalo
Sorry for my english translation, i do my best.

“Intellectual growth should commence at birth and cease only at death” A. Einstein

 

[sitapaty]

Potential cause of failure is defined as an indication of how the failure occur.

Should you avoid mentioning the operator or is it a common practice that some include the operator within this Column (Potential Causes of Failure)?

Examples: A. Operator error; inadequate operator quidelines specified.
B. Operator does not properly assemble part x into Y.
C. Don't mention the operator.

What do you think?
Do you include the operator as seen in A&B?
Or you would rephrase it otherwise & not mention the operator.

Looking for some best practices on the subject.

What do you think?

Thanks in advance

You cannot mention the operator's fault in the cause colomn.You have to assign a properly trained operator for the job.Even otherwise you have to assume that you have assigned a good operator.
Untrained operator is again an NC against the organization.In FMEA you have to assume the earlier operations are satisfactory although it is not always true.
Sitapaty

 

[Hipolit]

Looking at the evolution of the PFMEA in my present job I must say that the more mature analyze is the less “operator failure” you will see in the cause of the failure column. The question is why the operator made a mistake that led to occurrence of failure. In my opinion 80% of statements “operators failure” are not depth enough, take a while to look at the workstation ergonomics, presentation and flow of material. Good practice from my side, go to shop floor and X-ray the particular process/machine/workstation, tray to work yourself as an operator and then you have the best opportunity to avoid the pencil-pushing blind cups (as once Dirty Harry saidJ

 

[Hipolit]

Sadly life is brutal and no matcher how you will secure the process (ergonomics, material presentation) people tend to make mistakes is just in ours nature. Keep them trained, obeying wisely written standards and highly motivated and this should help Personally I tried to avoid putting “operator failure” as common cause of potential failure. As an example think of a situation as bellow: 8D report for a customer complaint ends up in cause: operator failure, corrective action: training or additional training of assembly staff, the question is: how on earth you can ensure that after the training operator will not repeat the same or similar mistake?

 

[Miner]

A generic operator error is too general. Get specific and use details such as installed upside down, reversed, etc. This will encourage recommended actions to error proof or mistake proof rather than to train or create job aids.

 

[Hipolit]

Question remains, why did the operator put the part in the wrong position. Training was inaccurate, part geometry makes it difficult or maybe there’s not enough guiding in assembly fixture itself? As a helping device to determined what was the initial rout cause we can use 5why or fishbone diagram.

 

[sitapaty]

Question remains, why did the operator put the part in the wrong position. Training was inaccurate, part geometry makes it difficult or maybe there’s not enough guiding in assembly fixture itself? As a helping device to determined what was the initial rout cause we can use 5why or fishbone diagram.

Both Dr.Deming and Dr.Juran have said that human error is a cause for about 20% of rejections.The rest is 'Management Inefficiency'
-sitapaty

 

[Bev D]

Question remains, why did the operator put the part in the wrong position.

I beleive that is Miner's point. Remember that in a PFMEA we don't necessarily need to go to root - root -root cause in the form. only enough level of detail to capture the causal system and enable preventive action. Also remember that not all items on an FMEA require or need action. if the severity and occurrence are low enough - compared to other items - then we may elect to leave the item alone, at least for a while. If we were to get to all of the possible final root causes of every potential failure mode we would never release anything...

The OP's question was if we thought operator actions should be included in a PFMEA. *I* do include them as they are real causes of failures. I use the tyupe of language Miner has advocated to capture the action without casting aspersions on the competancy of the operator. This follows modern thought and practices of 'mistake-proofing'.