When to Initiate a CAR (Corrective Action Request)

[jacoblh]

Hello, I am curious when CAR's are necessary - is it at every fault/error?

For example, if my accounting process/procedure is that we send invoices to customers and a customer says "where is my invoice?" is that enough to initiate a CAR? This is assuming we missed sending one. What if their junk inbox happened to block us?

To be clear, this isn't something that happens often as not sending invoices would be detrimental but I have noticed it on occasion. I always assume we get sent to junk mail.

Thanks! Jacob

 

[Marc]

I am curious when CAR's are necessary - is it at every fault/error? <snip>

No. Just NO.

Are you specifically interested in the scenario you presented, or are you asking "in general"?

If "in general", there are quite a few existing discussions here both recent and over many years.

Including some interesting conversations, such as: How to deal with too many CARs (Corrective Action Requests), PARs (Preventive Action)

And check this: Corrective Action Requests - Tagged Discussions for some thoughts.

Always think about the specific scenario before you issue a Request for Corrective Action. If you don't, it will reduce the importance of corrective actions in your company (in part by alienating employees) and you could end up with hundreds of "non-essential" corrective actions which are not actually fully addressed.

In the scenario you mention, the first thing to do is find out why it happened, and if it happens often (recurrence). You can do this through during the audit by asking questions and looking at records. Discuss with the auditee. Get the facts during the audit.

As to emails, everyone should know that emails are not reliable at times. I guess you could put this in the "software validation" bucket. Have emails been sent and confirmed as received a few times? NOTE: From time to times email filters will put an email from a "valid" sender which is typically accepted into a spam folder. The only way to prevent this is to "white list" that sender, and even that isn't always a "guaranteed" solution. The best thing is to be on an email system which supports "Return Receipt" to indicate an email has not only been received, but also whether it has been read.

Personally I wouldn't consider your scenario as significant as long as your company is "understanding" with respect to a supplier not paying on time in such a case (their not receiving an emailed invoice). Yes, it is how much business is done today (invoice by email) and I'm not saying it's not appropriate. I'm only saying that the failure modes and effects of email must be understood.

 

[Golfman25]

Do not under any circumstances issue a CAR for every "error" or issue. You'll be that hated quality person.

When to do it:

1) Repeats over a short period of time. So if you're failing to send an invoice every week, then something's wrong.

2) Major problems -- things that cause significant disruption and lots of money.

For CAR's less is actually more. Good luck.

 

[Big Jim]

The 2015 standard provides some clarity here.

10.2 is titled nonconformity and corrective action hearlding that both topics are covered here.

10.2.1 treats handling nonconformities

10.21a specifically treats initial handling with "take action to correct . . . " and "deal with the consequences"

10.2.1b tells you to "evaluate the need for action to eliminate the causes(s) of the nonconformity . . . "

The "evaluate the need" makes it optional at your discretion.

As with the other posters I feel it was always this way, but it is certainly clearer now.

 

[Marc]

<snip> I feel it was always this way... <snip>

I agree 100%.

 

[Jen Kirley]

Welcome to the Cove!

There is an expectation that the corrective action process also be risk based.

For that reason, and because writing a CAR for everything really can wear people out - and we don't want that! - I agree that not everything needs a sledge hammer approach when a fly swatter will do.

That said, we do want to avoid the "death by a thousand cuts" problem that can drain us of time resources. So it seems worthwhile to elevate repeat issues that do need action, in order to prevent recurrence.

An Environmental Engineer I used to work with developed a method to manage such things, and allowed me to share the concept. I put an NC Tracking Log in the Looking For Excel Template for Tracking & Trending Rejections thread.

 

[jacoblh]

Thanks everyone! You relieved so much stress this morning.

What a great resource!

Jacob