ISO 9001:2015 Clause 8.7 Control of Nonconforming Outputs

[Kirby]

I tried to start a new thread, I guess I haven't figured out how - pretty sure it's operator error, not a site nonconformity?! I found some info regarding this subject in some very old posts, but not specifically addressing some of what follows.

I'm working with a small company with an existing QMS that was established by a free-lance consultant (friend of the GMs) from a canned template set. The company gained AS9100 certification a few months prior to my coming onboard. They brought me in to help to manage and improve the QMS, primarily through tailoring the system as appropriate to the organization, as much of their "documented information" is not appropriate to this organization and, in fact, two years after inception, a significant portion has never been used and do not have promise to bring value in the future.
My current challenge is trying to make the NC / CAR processes and supporting forms more suitable and useful. It is my understanding that 8.7 Control of Nonconforming Outputs is directed at products and service and that 10.2 Nonconformity and Corrective Action is more about internal issues related to nonconformance of the system. I realize that many issues relating to 8.7 may result in CA, and conversely, not all system issues would require CA. I think I'd like to combine the two into one process and one report with options. It would start with a register to record all issues, then a choice (check box, etc.) if action is required, then a choice to conduct "Corrections" for less complex, infrequent occurrences, and close-out. Then for more complex issues a choice would be to identify the issue as needing a CAR. I'm pretty sure I could create a procedure that would cover the AS requirements for both clauses while not creating a "monster" process that takes more effort with which to comply than the benefit gained. Any thoughts?
One more sort of related issue - How many folks have a procedure (SOP/Documented Process , etc) specifically for Root Cause Analysis? Seems to me this would be part of the CA process?
Any thoughts that you have would be appreciated.

 

[Mike S.]

Hi Kirby,

A couple suggestions/comments: Use paragraphs! It's really hard to read all that in one paragraph.

Try to ask a specific question or questions.

It's always good not to create "monster" process that takes more effort with which to comply than the benefit gained. Do what works well for you and your team. Invite input from the users.

I have never written a formal documented procedure for root cause analysis as in "you must do this and this and this" but I do perform training on the subject and provide support materials for people to use.

I hope this helps.

 

[John Broomfield]

Competent facilitation of the team investigating and removing the root causes of problems (both proactively and reactively) is far more important that any documented procedure or instruction.

The key is leadership welcoming the reporting of anticipated and past problems to initiate the investigation to detect and remove the root causes from the system.

 

[Kirby]

Competent facilitation of the team investigating and removing the root causes of problems (both proactively and reactively) is far more important that any documented procedure or instruction.

The key is leadership welcoming the reporting of anticipated and past problems to initiate the investigation to detect and remove the root causes from the system.

Of course you are correct John, and my goal would be create a process that would foment competent facilitation of the team investigating and removing the root causes of problems (both proactively and reactively), I'm just trying to find the best approach to do that.

I'm trying to develop improvements that will be beneficial to the company to follow a NC / CA approach that will actually be effective in removing the root causes of problems when conducted, and appropriate to the company with respect to resources and business model. The reality is, as I see it, the path to that goal includes documented procedure or instruction.

In addition, these documents are important at audit time. I've always tried to avoid creating / maintaining documentation that exists simply for audits sake, where the effort to maintain outweighs the real benefit in day-to-day activities. I really believe in the benefit of an AS9100 QMS when it's understood, practiced, improved, and ingrained into the culture over time. Some of the current documented processes here are resource intensive and not germane to the company's business model, they exist in the system in the current form only because they were part of the canned program that was used to establish the QMS. I've never met the responsible "consultant", and I don't assign any blame to him, I guess he was effective is getting the company certified in a short time, and unfortunately (or not?) I think that was the objective from management rather than implementing a system that works not only at audit time. I'm trying to make needed practical incremental improvements while ensuring continued compliance with the standard.

Thanks to you and John S. for your input. After 20+ years as an ISO and AS Q Manager I'm still trying to develop a better understanding of the standards. (Slow learner!) My current role is more admin than managerial, and was created specifically to aid the novice Q Manager in AS related documentation and auditing. It is very different than most of my career where I not only had responsibility but also authority and included all of the day-to-day activities of a Q Manager . I think this role has allowed me to spend more time reading, understanding, and researching "best practices" for specific issues.

 

[Tagin]

I realize that many issues relating to 8.7 may result in CA, and conversely, not all system issues would require CA. I think I'd like to combine the two into one process and one report with options. It would start with a register to record all issues, then a choice (check box, etc.) if action is required, then a choice to conduct "Corrections" for less complex, infrequent occurrences, and close-out. Then for more complex issues a choice would be to identify the issue as needing a CAR. I'm pretty sure I could create a procedure that would cover the AS requirements for both clauses while not creating a "monster" process that takes more effort with which to comply than the benefit gained. Any thoughts?

It seems like that could work.

One more sort of related issue - How many folks have a procedure (SOP/Documented Process , etc) specifically for Root Cause Analysis? Seems to me this would be part of the CA process?

Hard to see the benefit of this unless it is structured as somewhat loose guidance. That is, to provide guidance on the different acceptable RCA methods for your org, the steps involved, when each method might be used, pitfalls to look out for, etc. Anything too rigid seems like it would be counterproductive.