Environmental, Health & Safety, Quality Management

NCR, RNC, CAR, CAPA, MOC, CI, ECN, Risk….

It gets confusing…  They all have a place and purpose and, sometimes they overlap. How frustrating is that???  Is it a Corrective Action Report, a Management of Change, or an Engineering Change…. maybe I need to complete a Document Change Request…? Do you really need to issue an NCR for each CAR? How bout an ECN for a MOC? The key, folks is to identify a SCOPE for each tool(NCR, CAR, DCR, MOC, etc…). Once you have a scope, identify methods for accounting for root cause*. If you can handle both of these, you’re well on your way to a compliant system, regardless the standard.  Knowing who requires a root cause is crucial.  ISO 9001 8.7 Control of Nonconformities, controls just that “nonconformity(s)”.  A nonconformity does not necessarily require addressing the root cause.  If we jump ahead in the standard to clause 10.2 Nonconformity and corrective action, sort of a continuation on 8.7.  10.2.1, we see that it states:
10.2.1 When a nonconformity occurs, including any arising from complaints, the organization shall: a) react to the nonconformity and, as applicable: 1) take action to control and correct it; 2) deal with the consequences;
However letter b) gives us more definition of EXACTLY what makes this a Corrective Action (RCA required).
b) evaluate the need for action to eliminate the cause(s) of the nonconformity, in order that it does not recur or occur elsewhere, by: 1) reviewing and analysing the nonconformity;    2) determining the causes of the nonconformity;    3) determining if similar nonconformities exist, or could potentially occur;
and then letters c) – f) detail more documentation requirements for a Corrective Action…. such as the ensuring the fix was effective and making required changes to the QMS.

Root Cause Analysis anyone????  This is more important than you might think!

Essentially we wind up diving into the world of Quality Forms and those that require Root Cause Analysis vs. those that don’t.  Clause 10.2 of course has requirements for “Documented Information” in 10.2.2.  We need to determine what requires Root Cause Analysis.  That’s the million dollar question.  The standard gives us some good clues and advice here.  Soooo…. if Root Cause Analysis is required and clause 10.2 is invoked for lack of a better word, we MUST:
  1. Document the nature of the nonconformity(s) and any actions taken…  Nonconformity(s)is plural.  So, Trend Analysis is immediately a key for conducting Root Cause Analysis.
  2. Make changes to the quality management system… this makes total sense, no one should change procedures or specifications for fun, we do it because a problem (actual or potential) was identified, and to mitigate that RISK (oh yea, CAR’s are your best friend for Risk Based Thinking folks) we make a change to some part of the Quality Management System.  So, issue a Corrective Action Report and account for the nonconformity, the risk, and the root cause.
  3. Implement any action needed… Standard production line defects “nonconformity(s)” don’t require any implementation.  Implementation is required for a complex solution.  Now if we have a complex solution, we must also have a nonconformity that poses a RISK to the QMS or business in some way.  We don’t implement anything complex without knowing the ROOT CAUSE, otherwise it’s almost blindly throwing at the dart board.

Let’s break it all down in more detail here.

Most companies have multiple processes to address various issues including Nonconformity, Corrective Action (internal and external), Management of Change, and even OHS/EHS Corrective Actions.  These may have multiple inputs from customer complaints, production identified nonconformity(s), QC Labs and QC checks, shipping, continual improvement initiatives, Internal Audit, Management Review, etc…  ITS A BIG LIST.  Keeping these straight can be tough. As a general rule, the purpose and scope of these processes must be defined in such as way it is clearly understood if and when a person might be required to file Multiple Actions/Forms.  In addition, where capable, the process should not overlap.  Such an example is a Corrective Action.  By definition, the Corrective Action fully encapsulates the requirements of tracking nonconformity(s) and therefore it is unnecessary to create both a nonconformity report and a corrective action report.  Of course, if your procedure calls for it, don’t break procedure on my account.  I would suggest a Corrective Action Report to change the procedure.

Change Management

When a change management process is introduced, it’s important to identify the purpose and scope.  For example, is this internal Continual Improvement (preventative action) based on the assessment of risk?  Or is this change management in regard to a product design during or even after the completion of a design and development process?  The difficulty comes when there is a nonconformity and NOT a risk that the change management action is issued.  A change management action always results in a change to the QMS, such as a revision to a work instruction, or change in suppliers for a product, etc… when a management of change action is issued in response to a nonconformity the action meets the requirements for corrective actions.  The key difference between Management of Change and Corrective Action is that a CAR has a requirement to identify a root cause and mitigate that cause and further evaluate the effectiveness of the preventative measure.

Risks and Opportunities

Risks and Opportunities is another fun area to address. First, we need to set the record straight.  Risk and Opportunities are like heads and tails of a coin.  Any, ANY opportunity worth pursuing has a risk of failure or trouble in some way.  Let’s look at a common example.  If my wife and I get a babysitter for the night. AWESOME opportunity?  YES!  However, driving on the road presents a risk, a 16 year old watching our three kids, there is a risk.  You get the idea. I conduct 2nd and 3rd party audits as a part of my function with Texas Quality Assurance and as a contractor for 3rd Party Registrars of course.  I’m the youngest auditor I’ve met, and all the more senior folks like the “Risk Register”.  Some folks can make a good use (beyond compliance requirements) of such a register.  Personally, I’m not a fan (since risk and opportunity are of course heads and tails of the same coin).  I like the idea of a couple tools or so.  For one, each time you implement a new process or an annual review, create or update a FMEA.  Make sure you’ve got good controls for those top level issues, and check to make sure the ones from last year worked.  Second thing, INSIDE you CAR or CAPA or MOC (with Root Cause accounted for) include the (S)Severity, (O)Occurrence, and (D)Detection for each CAR BEFORE and AFTER corrective action.  If needed to review on a large, how easy would it be to create a FMEA for each class of grouping of CAR.  Last thing, and this topic deserves its own blog post.  Risks and Opportunities are darned near the same thing, let’s just say it, they are the same thing.  You can track opportunities separately.  But wasn’t EVERY single CAR a preventive Opportunity if you’d caught it ahead of time?  What about that new client you’re going after, building up infrastructure for?  Great opportunity, until they don’t provide the PO’s.  Then, you took a huge risk. If thought out and measured against existing people, process, and business requirements, simple additions or changes to either the corrective action or management of change process can resolve these potential conflicts and mitigate the risk of not identifying and treating the root cause of nonconformity(s). Texas Quality Assurance: www.TexasQA.com | Tel: (281)756-7316 LinkedIn | Facebook | Instagram | Twitter | GETTR | YouTube – Products and Services: | QMS Software | Consultation | FQM | Auditing #QualityMatters podcast is streaming on: iTunes | Spotify | Google | Audible | Stitcher | TuneIn