Should ISO 9004 Become a Requirements Standard?

Should ISO 9004 become a requirements standard?

  • Yes

    Votes: 1 10.0%
  • No

    Votes: 9 90.0%

  • Total voters
    10
  • Poll closed .

John C. Abnet

Teacher, sensei, kennari
Leader
Super Moderator
In my experiences, the "problem" is not so much with the standard, but with the understanding of intent. I often hear comments which sound similar to the discourse I hear surrounding a different topic/context. It is often perceived that CERTIFICATION to a given standard is intended to come to the rescue and "do something" for the individual beyond the framework established. In fact, the CERTIFICATION has little to do with it. It is, instead, a strategic approach, a supporting top management, and an implementation/execution done in a manner that provides real benefit for the organization and its customers.

9001 (i.e. ANY governing standards) is simply a framework of parameters. In no place does it dictate HOW. If individual ORGANIZATIONS approach the framework set forth by the standard strategically with intent of ....
1- Establishing compliance in a manner which is BENEFICIAL to the organization, ...and...
2- In a manner to ensure SUSTAINABILITY as the work force evolves....

...then the organization relies on the QMS (as intended) instead of dreading the QMS (as is often the case).

Considering the generic approach and application of ISO 9001, (which my experience has shown to be a proper approach considering the broad spectrum of those seeking certification), organizations often "forget" (?) that certification to the standard does not prevent them from going far beyond what is necessary for certification, and all the way to using the QMS framework to add additional requirements/direction to actually benefit the organization (novel idea ;)
It shocks me how many organizations manage just those things identified in the standard by their "QMS", but then have equally (more?) activities to the organization that simply "exist" fragmented and lost, outside any formal framework.

The goal is for an organization's team to scream NO if portions of the QMS are threatened to be removed and/or circumvented, because the teams have "grown up" on the benefits the aspects of a well developed QMS provide.

"We" can change standards as often as we like (as in the example given by @Sidney Vianna above), but regardless of how they look or what they are called, they are only as good as the understanding and will of the top management of the organizations deciding to implement.

Be well.
 

Paul Simpson

Trusted Information Resource
That was quite a delayed response, Paul, I'm curious what prompted it?
Just catching up, Mike. I've been a little busy on other things! ;)

Disappointed with some of the slating of TC 176 SC2 in the thread on the potential revision of ISO 9001, BTW. Ah, well, unless you visit regularly it is difficult to correct misinterpretations.
 

Sidney Vianna

Post Responsibly
Leader
Admin
Really, Jim? Perhaps you could start with describing them?
I am no Jim, but I made clear my opinion about the biggest mistake ever done by the TC 176 in this post concerning the direction they took ISO 9001 towards. Every CB and their brother now use the word ASSURANCE. Assurance of a supplier's ability to consistently fulfill orders cannot be achieved via undefined, subjective, wishywashy "requirements". Major blunder in my assessment, and, unrecoverable.

While we are at it, you can also address Interesting Discussion - ISO 9001:2024 - What should be changed in the next Edition of ISO 9001? - REVISION CANCELLED May 2021
 

Big Jim

Admin
Really, Jim? Perhaps you could start with describing them?

OK, let's start with element 8.7.1 a-c where it is evident that the proof reader wasn't very alert. "The organization shall deal with nonconforming outputs in one or more of the following ways: c) informing the customer

Do you think for a minute a customer would be content if you notified him that you shipped some bad product and told him I hope you enjoy it because the standard doesn't require me to do anything else but notify you? But that is clearly what the standard says even though it is in conflict with the rest of the standard and common sense.

How about 9.3.2 f & 9.3.3 a about management review where identical wording is used for the last input and the first output? "opportunities for improvement" Isn't that a bit confusing? Aren't inputs and outputs supposed to be different?

The list of inputs 9.3.2 dealing with performance and effectiveness could be clearer. Some seem to be redundant or at best overlapping. The lack of clarity could make one think that the committee members couldn't agree so they compromised and left the ambiguity for the readers to deal with.

9.1.3 Analysis and evaluation was clearer in the 2008 version before they removed part of the opening lines into the list. It appears that they could not easily determine how to add risk to it.

9.1.1, 7.4, and 6.2.2 look like prescriptive lists when prior to this version prescriptive details were avoided, leaving it up to the organization to determine how they would meet any of the shalls. What really is irksome about these prescriptive lists is how elementary they are. Do they think they are addressing 2nd graders? 7.4 is the worst of the batch. Do you really need to think through how you are going to communicate before you communicate? What to communicate? When to communicate? With whom to communicate? How to communicate? Who communicates? All of that is so basic it doesn't need a list of "how to".

4.4.1 goes into a lot of detail about what to do with your processes but doesn't do anything to define what they mean by a process. Sure, there is a definition in ISO 9000:2015, but it so broad that it is useless. "Set of interrelated or interacting activities that use inputs to deliver an intended result" There are a bunch of notes below the definition that still don't do much to show what a process really is. From 8.5.1f it looks like they are talking about manufacturing processes that require validation (often called "special" processes. For the uninitiated it would be easy to use that loose definition and create a long list of processes that you need to sort out. For 4.4.1 aerospace sort of sorted it out in AS9101 which provides instructions for performing aerospace audits. Guidance from some of the certification bodies indicates that what they are after are your business processes. Still others try to define them as core processes. Until ISO does a better job of defining what they mean by processes in 4.4.1 confusion will still reign.

Is that enough? Those are the ones that most easily come to mind when I read the standard. I'm sure there are more. Sidney mentioned one.
 

Paul Simpson

Trusted Information Resource
I am no Jim, but I made clear my opinion about the biggest mistake ever done by the TC 176 in this post concerning the direction they took ISO 9001 towards. Every CB and their brother now use the word ASSURANCE. Assurance of a supplier's ability to consistently fulfill orders cannot be achieved via undefined, subjective, wishywashy "requirements". Major blunder in my assessment, and, unrecoverable.

While we are at it, you can also address Interesting Discussion - ISO 9001:2024 - What should be changed in the next Edition of ISO 9001? - REVISION CANCELLED May 2021
I'll have a think about replying to your linked post, Sidney. At this stage I'll just say that 'ISO' doesn't have any say in the decisions of an individual TC (or SC), it is the participating National Standards Bodies (NSBs) who take all the decisions. So If there has been a change in direction then it is because the SC2 members voted for that.

I probably won't reply to the second linked thread as that is the thread I alluded to where there are a lot of misunderstandings and misrepresentation - too much to deal with in just one post.
 

Paul Simpson

Trusted Information Resource
OK, let's start with element 8.7.1 a-c where it is evident that the proof reader wasn't very alert. "The organization shall deal with nonconforming outputs in one or more of the following ways: c) informing the customer

Do you think for a minute a customer would be content if you notified him that you shipped some bad product and told him I hope you enjoy it because the standard doesn't require me to do anything else but notify you? But that is clearly what the standard says even though it is in conflict with the rest of the standard and common sense.
If you believe that all clause 8.7.1 requires is (for example) to notify a customer then I can't help you. Nonconforming product leads into corrective action and there are further requirements there to take action to control or correct the nonconformity and to deal with the consequences (10.2.1 a and b).

How about 9.3.2 f & 9.3.3 a about management review where identical wording is used for the last input and the first output? "opportunities for improvement" Isn't that a bit confusing? Aren't inputs and outputs supposed to be different?

The list of inputs 9.3.2 dealing with performance and effectiveness could be clearer. Some seem to be redundant or at best overlapping. The lack of clarity could make one think that the committee members couldn't agree so they compromised and left the ambiguity for the readers to deal with.
9.3.2 deals with inputs and 9.3.3 deals with outputs so the 'duplication' is there to encourage the organisation's top management to bring a (long) list of potential improvements to the review and to produce a resulting plan with (probably) a shorter list of improvements that they can actually provide the resources for.

9.1.3 Analysis and evaluation was clearer in the 2008 version before they removed part of the opening lines into the list. It appears that they could not easily determine how to add risk to it. [/QUOTE] To save me having to trawl through old copies of the standard perhaps you can quote the change or explain why you think the current requirement is not clear?

9.1.1, 7.4, and 6.2.2 look like prescriptive lists when prior to this version prescriptive details were avoided, leaving it up to the organization to determine how they would meet any of the shalls. What really is irksome about these prescriptive lists is how elementary they are. Do they think they are addressing 2nd graders? 7.4 is the worst of the batch. Do you really need to think through how you are going to communicate before you communicate? What to communicate? When to communicate? With whom to communicate? How to communicate? Who communicates? All of that is so basic it doesn't need a list of "how to".
They are lists but they are not prescriptive, they leave it open to the organisation to decide how it will satisfy the requirements. Additionally, these requirements come from Annex SL and cannot be changed by TC 176 SC2. If there any suggestions as to how they can be improved for quality I'll happily listen to them.

4.4.1 goes into a lot of detail about what to do with your processes but doesn't do anything to define what they mean by a process. Sure, there is a definition in ISO 9000:2015, but it so broad that it is useless. "Set of interrelated or interacting activities that use inputs to deliver an intended result" There are a bunch of notes below the definition that still don't do much to show what a process really is. From 8.5.1f it looks like they are talking about manufacturing processes that require validation (often called "special" processes. For the uninitiated it would be easy to use that loose definition and create a long list of processes that you need to sort out. For 4.4.1 aerospace sort of sorted it out in AS9101 which provides instructions for performing aerospace audits. Guidance from some of the certification bodies indicates that what they are after are your business processes. Still others try to define them as core processes. Until ISO does a better job of defining what they mean by processes in 4.4.1 confusion will still reign.
I don't share your confusion. Over many years the definition of and examples for 'process' has been covered here and elsewhere. Quality professionals and auditors should be competent in business and technical areas to determine processes. I'm not particularly familiar with aerospace requirements. Again if there is any particular guidance that can be applied to the wider scope that ISO 9001 covers, I'm listening.

Is that enough? Those are the ones that most easily come to mind when I read the standard. I'm sure there are more. Sidney mentioned one.
No, Jim, not enough by any means. Sidney's post was about the scope of application, not an ISO 9001 requirement.
 

Big Jim

Admin
Paul, how you have failed here is the ability to put yourself in the shoes of the user of the standard. I know that Sidney points out that the user is the customer of the certified supplier, and that is true, but the company is also a user. The company getting certified should not need someone to "fill in the blanks" so the standard can be understood.

I clearly understand that notifying the customer of nonconforming material is not enough, but the standard clearly states otherwise and it shows the writers were not paying attention and it could cause confusion to users. If you can't see the inadequacy of that then I can't help you either.

If the three prescriptive lists, which are so simplistic that they should not be included, were locked in from the High Level Outline, then shame on the writers of the High Level Outline for being so condescending. They expect readers to understand concepts that are not clearly understood and then toss in something that looks like it was aimed at 2nd graders isn't very consistent.

The writers need to get out of their ivory tower and visit the real world. I hope you don't decide to join them up there in their lugubrious lethargy and lose touch with all of the users of the standard.
 
Top Bottom