Re: How to categorize Minor, Major or Observation for Internal Audit NCR?
What you need to know about any NC is whether or not it's an outlier or part of a larger, systemic issue. For example, an internal auditor might find an instance of nonconforming material not being properly identified as such. This is evidence of a systemic breakdown, but not proof. Evidence should lead to further investigation. How that further investigation happens (what triggers it and who does it) is what should be in question here, not how a given NC is characterized or named.
Roxanne's company seems to have developed a system that works, but that doesn't mean that simply characterizing NCs as major or minor is the solution. There has to be a system in place for reviewing NCs in order to rationally determine how to proceed. I favor a system in which internal auditors report their findings and management decides what to do, if anything, about them. This doesn't mean that some other process won't work, though.
I think that one good reason to avoid the major/minor thing is that we should avoid designing IA processes that mimic CB audits.
I believe we've had this discussion before but as I have donned my ISO 9001/14001 auditing hat again to help a site out - not a Corporate gal for the next few hours at least
- I'm going to jump in with my thoughts.
Why differentiate? Because of the value-added approach to problem-solving.
In my production experience, we treat a "minor" with a correction. We log it. We acknowledge it. But it's a small little hiccup in the grand scheme of things. Root cause analysis is NOT required for a hiccup. We simply wish to get rid of the annoyance....I mean, nonconformance.
I guess this would be aligned with the "observation". However, observation implies "Hey, we found something, but you don't necessarily need to do anything about." And that, to be honest, is typically unacceptable within my organization. An observation says that there is some nonconformance against requirements, does it not?
A major, on the other hand, is big issue. It implies high (potential of) risk and/or loss. It is a systematic issue and we want to get rid of it for our own sanity and the health of the management system.
An Opportunity for Improvement is for those cases where requirements are conformed to, however there is the potential to improve the process/practice/results. It is optional to implement.
When we do system audits in my company, we may note "minors" on individual processes, and we inform the area before we leave of the situation. However, at each team caucus meeting - held at the end of each day - we discuss what was found and if there are multiple minors against a particular requirement (e.g., lots of documents found to be out-of-date, unapproved but used, etc.), we'll issue a major against document control.
To summarize, why classify Minor or Major?...to ensure we take a value-added approach to treating the nonconformance.
It works for us.
Whether or not it works for others....well, I did have the local ASQ chapter president ask me to speak at a meeting on our method...
Why differentiate? Because of the value-added approach to problem-solving.
In my production experience, we treat a "minor" with a correction. We log it. We acknowledge it. But it's a small little hiccup in the grand scheme of things. Root cause analysis is NOT required for a hiccup. We simply wish to get rid of the annoyance....I mean, nonconformance.
I guess this would be aligned with the "observation". However, observation implies "Hey, we found something, but you don't necessarily need to do anything about." And that, to be honest, is typically unacceptable within my organization. An observation says that there is some nonconformance against requirements, does it not?
A major, on the other hand, is big issue. It implies high (potential of) risk and/or loss. It is a systematic issue and we want to get rid of it for our own sanity and the health of the management system.
An Opportunity for Improvement is for those cases where requirements are conformed to, however there is the potential to improve the process/practice/results. It is optional to implement.
When we do system audits in my company, we may note "minors" on individual processes, and we inform the area before we leave of the situation. However, at each team caucus meeting - held at the end of each day - we discuss what was found and if there are multiple minors against a particular requirement (e.g., lots of documents found to be out-of-date, unapproved but used, etc.), we'll issue a major against document control.
To summarize, why classify Minor or Major?...to ensure we take a value-added approach to treating the nonconformance.
It works for us.
Whether or not it works for others....well, I did have the local ASQ chapter president ask me to speak at a meeting on our method...
Roxanne's company seems to have developed a system that works, but that doesn't mean that simply characterizing NCs as major or minor is the solution. There has to be a system in place for reviewing NCs in order to rationally determine how to proceed. I favor a system in which internal auditors report their findings and management decides what to do, if anything, about them. This doesn't mean that some other process won't work, though.
I think that one good reason to avoid the major/minor thing is that we should avoid designing IA processes that mimic CB audits.
Your two cents also happen to coincide with mine: Why bother to classify them? It is not required, and the main thing is that proper action is taken.