Corrective Action Process Review - Reducing the scope of our NRS

[dominick]

I am currently reviewing our nonconformance reporting system (NRS)and believe our current system allows us to document a wide variety of issues (over 70 reason codes). Our system struggles under this deluge of info. and our resources cannot adequately address all these issues.

I am looking to reduce the scope of our NRS and was hoping for some advice on where to start. What considerations should factor in to the decision-making process when trying to scale down the number of issues we should be looking at as part of our corrective action process.

 

[Marc]

You're saying you are 'coding' defect classes, correct? And you have identified 70 categories (classes) of defects?

 

[dominick]

That is correct. These 70 classification codes are grouped under headings that include Packaging, Material, Documentation, Communications, Delevery, etc. The system provides evidence that we cannot effectively address all these issues and my team is looking to restrict the number of instances that can warrant a CAR. But we need to be careful we don't ignore fundamental signals that our system is not healthy. I am looking for thoughts we need to consider before defining what justifies a CAR. Thanks

 

[Kevin Mader]

Hey Dominick,

You may want to try the old "80/20" rule. What you want to find are the Vital Few in the Trivial Many. As your program becomes more stable, you may elect to reintroduce some of those you may have been on the fence about removing. Your goal is to increase the efficiency, so your steps towards making it more user friendly should work out.

Additionally, when should a CAR be issued? Many folks don't know the answer, so when in doubt, issue a CAR (in reality as Barb B. says; train, train, train!). This is bad practice. It gives the program a bad taste. Pretty soon, no one reports trouble, because CARs they issued, some for good reason, some not, have gone unanswered for months! Why bother? The system bogs down because there are many useless CARs in the system, no hope for improvement. Again, the Vital Few need consideration. I would also say that "System Knowledge" needs to be taught (my own opinion here).

An example: a CAR is issued by an inside sales associate because someone called up, upset that a product they bought was missing a key piece of hardware. The system that produced the problem operates at 99.98% efficient. Was this a bonified reason to issue the CAR? Things to consider: Severity of the problem, Occurrence of the problem, point of Detection. Looks familiar? It is part of the FMEA risk rating system. Develop an RPN (risk priority number) and address those that require addressing. Again, the 80/20 rule applies. An organization has limited resources, and chasing a shadow won't get it done, only worse!

I inherited a CAR program that had issued 367 CARs in a 6 month period. I went through them all, classified them, and came to the conclusion only about 12 required corrective action. Needless to say, no one was filling out the CARs before, but they fill them out now. They only get them when they are needed.

I'll be out your neck of the woods most of next week, so let's meet at Honey Girls for lunch if you like.

Regards,

Kevin

[This message has been edited by Kevin Mader (edited 10 February 2000).]

 

[Marloun]

Same problem we are seeing in our plant, Dominick. We have a lot of rejection modes here and it has been standardized already that we require a CAR in every valid rejection seen, specially if the reject was found during QA inspection. What we are currently doing is to segregate the more-serious ones (problems which are most likely to become a customer complaint) from the not-so-serious ones. We only give a disposition on the affected materials for the not-so-serious problems, while the more-serious ones will have to require a corrective and/or preventive action.

Rgds,
Marloun

 

[Johnny Joe]

Hello to kevin and others.

I bumped into your forum while deleting old bookmarks off my browser. The caymen cove link still worked after 3 years!

More to topic. I took an interest in two things. #1. Dominic wants to get his data in a fine detail of 70 "things". To me he should keep after them. In any factory that i admire, i really marvel at their attention to detail. That is because they have gotten the easy 80% and were on the last 20%. To get the last 20% you really need detail from all areas, the more the better. Can you imagine the level of detail that is needed when you are working on the last 5% of your i- If you find a way to deal with the data please get back to me........which leads me to #2 which is Kevin's point about inheriting a +350 CAR back log (sounds like maintenance work order system). What's wrong with the +350 Car backlog is our inabilty to digest the data. I have seen the same thing in safety programs that want employees to report even potential hazards (ie air hose are similar in color to the floor. tripping hazard......i don't think the color is the problem). But aside from the pile of work, people....real live employees were reporting stuff. The problem was in what they were told to report or the resources allocated to handle the information or nobody knew what to expect. Maybe that situation arose because people thought the QA dept was a combination maintenance/IT dept!

I think Dominic's solution may lie in relaying the workforce that the CARS are only information on how the systems are working. You can't address all them unless you are "super dept" but you can use them to focus on the critical 12. Ask Kevin the impact of those 12 CARS he distilled from over 350. I would guess pretty good.

Maybe a suggestion: in the paper work it would be clearer if the 70 "things" there were put on say five sheets with only 10 - 15 codes. The writer might have to chose but would be much happier with a clearer and perhaps more specific paper. They could also be dept, site or even classification specific.

Education and delivering a clear understanding that the QA program collects data, analyses it and issues reports on the performance of "systems." It usually doesn't have the stuff to fix them. If these two things are up front I think you will be able to handle all the data.

Greg Jobe

[This message has been edited by Marc Smith (edited 16 February 2000).]

 

[Kevin Mader]

Greg,

A nice job of explaining! Your suggestion to compile the data to make it more meaningful is a good one. Working on a QS is never ending. Each NC should be reviewed for its merit and dealt with in a way to make the QS more effective. By itself, it may be meaningless. Get a pile of "hose in the aisleway" notes, you might just want to investigate.

I am glad the shortcut to the Cove still worked. I am impressed with the popularity of Marc's growing creation!

Regards,

Kevin