How to handle operator involvement in the non conformance

[GoSpeedRacer]

Hello fellow med. device makers.

I am looking for input and ideas regarding how to incorporate operators in the WIP, non-conformance process.

So as it goes right now, if our QC inspector finds a non-conformance he will write up a Non conforming Material Report (NCMR) and the case goes to MRB. If the MRB dispositions it to Rework, the part or assembly is (usually) giving to the operator to fix their work.
But for cases where it is Use As Is, (or scrap) or the guy that messed up is out of the office), the offending operator might not find out that they messed up.

Management wants to tighten this up by having every NCMR go to the perpetrator for signature. Also every error needs to be written up. (i.e forgot to inital and date an entry overwrite on a product log. This way they are made aware of their error and by signing the NCMR form, the operator feels a tad more "sting".

Our QC inspector feels this will make him out to be a "bad cop" as he will have to kind of "rub the offending operators nose" in every misdeed, making for more of an strained relationship. (folks may be less likely to communicate freely). He thinks it should be handled more informally so that minor issues can just be talked over, while significant quality lapses could be written up.
I think that some of the "bad cop" persona is part of the job of a QC inspector but also, one does not have to belittle of harass folks in order to do the QC job.

I also think that collecting data even on minor issues is important as it offers a chance to talk to folks before a big issues crops up. However, if we get too persnickety, some NCMR's will not be written up because the QC inspector will just fix the paperwork error himself to speed up the process (and save him from having to deal with a seemingly benign issue)
So, any ideas for a suitable compromise?

How do y'all deal with this?

Best regards

Rx

 

[Golfman25]

I think you have to determine whether the errors are:

a) systematic,
b) based on operator competence,
c) or carelessness

I would attack them in order:
If systematic, then get the operator to help revise the system to reduce the problems.

If competence is an issue, get them competent.

If it is carelessness, then make them aware.

What you want to avoid is this:
YouTube

 

[RoxaneB]

I think you have to determine whether the errors are:

a) systematic,
b) based on operator competence,
c) or carelessness

I would attack them in order:
If systematic, then get the operator to help revise the system to reduce the problems.

If competence is an issue, get them competent.

If it is carelessness, then make them aware.

To build upon Golfman's post, I'd also consider the risk(s) associated with the nonconformance and the value associated with the actions needed.

Low risk and little value in chasing someone down immediately for a signature, as an example, log it and deal with it at a more suitable time. High risk and the issue needs to be addressed ASAP, then loop the appropriate people in immediately.

I'd also consider sharing the results of the nonconformances, by team or area (not by individual if at all possible). Healthy competition can be helpful at addressing what might simply laziness or can identify some serious gaps in the system.

 

[Eredhel]

I like your hesitation btw. I know of a shop that would do an NCR tag for a machinist's scrap, have a meeting with that machinist about it, and then have a daily meeting about scrap and bring up that scrap in front of everyone. We definitely want people to know what happened so adjustments can be made but a healthy balance is important too.

 

[QuinnM]

Hi Rx,

If an operator error, the operator’s manager should perform re-training. This result should be documented in the NCMR before the NCMR is approved. Two concerns. The training should be documented. The training could be documented in the NCMR, or the formal training process. Agree, try to avoid “rubbing the operators nose” because they will / should feel open to express / expose issues when they come up. Not every issue is an NCMR. If I make a mistake it is corrected and documented, sometimes with an NCMR.

Quinn

 

[RoxaneB]

If an operator error, the operator’s manager should perform re-training. This result should be documented in the NCMR before the NCMR is approved. Two concerns. The training should be documented. The training could be documented in the NCMR, or the formal training process. Agree, try to avoid “rubbing the operators nose” because they will / should feel open to express / expose issues when they come up. Not every issue is an NCMR. If I make a mistake it is corrected and documented, sometimes with an NCMR.

I'm going to disagree here - not every operator error requires retraining. People have bad days and there are times we make mistakes simply because our heads are not truly at work. Re-training could result in a more frustrated employee who ends up becoming dis-engaged.

The other possibility involves understanding what is truly meant by "operator error." It is possible that the operator has a better process/method to perform the task, but the technology is not yet set up to align with that process/method. In this case, there is the possibility that the standard process (and associated technology) needs to be revised.

I know we sometimes roll our eyes at the philosophy that "it's never operator error" even though there are instances when we believe it truly is, however, this doesn't mean that we should simply stop at "operator error" when investigating the real reason behind the nonconformance.

I'm also a bit confused by your response. In one paragraph you say that the training should be documented in the nonconformance report, but then you say that not every issue warrants a nonconformance report. Please don't misunderstand me - I fully support the approach that not every nonconformance requires a nonconformance report; if it did, we'd be bogged down in paperwork! But I think you should explain your statement to the original poster. The approach I take to determine if a report is needed involves the use of triggers and statistics, but your reasoning may be different and I think it would be interesting to learn the logic behind it.