7.2.1 (d) - "Any additional requirements determined by the organisation"

[gpainter]

First time I noticed this. My take a typo, the d) determined should be required. Meaning thet you as an expert in your field will most likely have some requirements to add.

 

[M Greenaway]

gp

Now that does make sense.

LRQA's explanation was, like many others given in this thread, what we all know to be an important factor in our business, yet fails to actually explain the text as written, as it is totally inexplicable.

It still makes me laugh....

 

[s_warin]

7.2.1 Determination of requirement related to the product

You have to read this clause from "The organization shall determine till d) ....." as a sentence.

a) requirement specified by the customer, including the requirements for delivery and post-delivery activities,
(You hired a hotel room specified no bed in this room. You like sleep on the floor.)

b) requirements not stated by the customer but necessary for specified or intended used, where known,
(The air condition or heater for the room.)

c) statutory and regulatory requirments related to the product, and
(the room has to be such width and height and stairway for emergency case.)

d) any additional requirements determined by the organization.
(the manager of this hotel give a plate of seasonal fruits to the guest.)

In the subclause d) the organization add the requirement to the product (the room).

 

[atreyu915]

Re: 7.2.1 Determination of requirement related to the product

I realize this is a pretty old post..but i've spent a great deal of time recently reviewing threads associated with the ISO 9001 standard as I work to align/transition our current QMS (NQA-1:1994) with the 9001 standard, and this is one clause I'm having a great deal of difficulty with...

You have to read this clause from "The organization shall determine till d) ....." as a sentence.

a) requirement specified by the customer, including the requirements for delivery and post-delivery activities,
(You hired a hotel room specified no bed in this room. You like sleep on the floor.)

b) requirements not stated by the customer but necessary for specified or intended used, where known,
(The air condition or heater for the room.)

c) statutory and regulatory requirments related to the product, and
(the room has to be such width and height and stairway for emergency case.)

d) any additional requirements determined by the organization.
(the manager of this hotel give a plate of seasonal fruits to the guest.)

In the subclause d) the organization add the requirement to the product (the room).

So, how do I illustrate that my organization does this? I'm quoting this post because it was the most informative (IMHO)
I'm using a flow chart approach and have outlined my overall process map and supporting processes, and my current line of thinking is that I can now reference these individual maps under this clause? Am I way off in my thinking?

 

[Jim Wynne]

Re: 7.2.1 Determination of requirement related to the product

I realize this is a pretty old post..but i've spent a great deal of time recently reviewing threads associated with the ISO 9001 standard as I work to align/transition our current QMS (NQA-1:1994) with the 9001 standard, and this is one clause I'm having a great deal of difficulty with...




So, how do I illustrate that my organization does this? I'm quoting this post because it was the most informative (IMHO)
I'm using a flow chart approach and have outlined my overall process map and supporting processes, and my current line of thinking is that I can now reference these individual maps under this clause? Am I way off in my thinking?

Don't worry about putting things under clauses. The poorly-worded requirement in question means that in addition to requirements explicitly described in the standard, you need to "determine" whether there are any requirements not prescribed by the standard that are necessary to building a quality system. No clause references required.

 

[Stijloor]

Re: 7.2.1 Determination of requirement related to the product

I realize this is a pretty old post..but i've spent a great deal of time recently reviewing threads associated with the ISO 9001 standard as I work to align/transition our current QMS (NQA-1:1994) with the 9001 standard, and this is one clause I'm having a great deal of difficulty with...

So, how do I illustrate that my organization does this? I'm quoting this post because it was the most informative (IMHO)
I'm using a flow chart approach and have outlined my overall process map and supporting processes, and my current line of thinking is that I can now reference these individual maps under this clause? Am I way off in my thinking?

Not that difficult:

• You determine the requirements (Use P.O., contract, verbal, etc.)
• You review the requirements (Do we understand it? Can we do it?)
• You maintain records {Records of the results of the review and actions arising from the review shall be maintained (see 4.2.4).}

Documents describing the process? That's entirely up to you. Whatever works best for your company.

Stijloor.

 

[Paul Simpson]

Re: 7.2.1 (d) - Another stupid clause ?

Like Jim said.

Have a look at what your organization does.

Look at what is required and IF:

• everything the customer tells you they want,
• all you know about how it is going to be used and
• all the legal requirements for the product are defined and understood

then d does not apply.

If however you have a company policy to wrap the product in pink bows then you have a requirement that comes under d.

You don't have to do anything more than make sure people are aware of the "pink bow" requirements and follow them.

 

[Peter Fraser]

Re: 7.2.1 (d) - Another stupid clause ?

Paul

Shame on you(!) - and you an English Agony Aunt as well... First of all, any sentence with a bulleted list must make grammatical and logical sense when it is read with each bullet point on its own. This is a good test of any document or report.

The problem with 7.2.1 (d) is that you cannot change tense in mid-sentence: "The organization shall determine any additional requirements determined by the organization" is saying that you must do something you have already done. Don't try to justify it(!) - it is badly written and confusing, and if a Scot just across the border cannot understand it, how on earth does it translate for those for whom English is not their first language?

 

[Jim Wynne]

Re: 7.2.1 (d) - Another stupid clause ?

Paul

Shame on you(!) - and you an English Agony Aunt as well... First of all, any sentence with a bulleted list must make grammatical and logical sense when it is read with each bullet point on its own. This is a good test of any document or report.

The problem with 7.2.1 (d) is that you cannot change tense in mid-sentence: "The organization shall determine any additional requirements determined by the organization" is saying that you must do something you have already done. Don't try to justify it(!) - it is badly written and confusing, and if a Scot just across the border cannot understand it, how on earth does it translate for those for whom English is not their first language?

While I share your disdain for the sloppy English, and can't understand why it hasn't been corrected, we humans have the ability to reason our way around such things. Anyone who deals with computer programming becomes more acutely aware of this ability of ours. Back in the day when computers could only read data files sequentially (the records had to be read one at a time in order to find the relevant ones), the program logic went something like,

1. Open the file
2. Read a record
3. Do some processing
4. Read the next record
5. Go to #3

This is an oversimplification, but the problem was that if you asked the computer to do step #2, and there were no more records to be read, the computer wouldn't know what to do and the program would terminate with an ABEND (abnormal ending) message. In order to avoid this, you would have to insert a new step #2 to tell the computer to check first to see if there were any records left, and what to do if there weren't. It goes something like this:

1. Open the file
2. Are there any records to read?
2a. If "no" go to #6
3. Read a record
4. Do some processing
5. Go to #2
6. End Program

Note that a 2b "If yes" step was unnecessary because if the answer wasn't "no" the program would automatically skip to the next line. If you follow the simple logic, you'll also see why flowcharting of these things was helpful.

Anyway, my point is that we should be able to look at such illogical constructions as in the ISO clause and use context and experience to understand what was meant by them. There's no reason that we should act like inanimate computers and just stop dead when we encounter them. This illustrates one of the great powers of the Cove as well: if we do get confused, there's a big community of experienced people here to help us avoid the dreaded ABEND message.

 

[Peter Fraser]

Re: 7.2.1 (d) - Another stupid clause ?

While I share your disdain for the sloppy English, and can't understand why it hasn't been corrected, we humans have the ability to reason our way around such things. Anyone who deals with computer programming becomes more acutely aware of this ability of ours. Back in the day when computers could only read data files sequentially (the records had to be read one at a time in order to find the relevant ones), the program logic went something like,

1. Open the file
2. Read a record
3. Do some processing
4. Read the next record
5. Go to #3

This is an oversimplification, but the problem was that if you asked the computer to do step #2, and there were no more records to be read, the computer wouldn't know what to do and the program would terminate with an ABEND (abnormal ending) message. In order to avoid this, you would have to insert a new step #2 to tell the computer to check first to see if there were any records left, and what to do if there weren't. It goes something like this:

1. Open the file
2. Are there any records to read?
2a. If "no" go to #6
3. Read a record
4. Do some processing
5. Go to #2
6. End Program

Note that a 2b "If no" step was unnecessary because if the answer wasn't "no" the program would automatically skip to the next line. If you follow the simple logic, you'll also see why flowcharting of these things was helpful.

Anyway, my point is that we should be able to look at such illogical constructions as in the ISO clause and use context and experience to understand what was meant by them. There's no reason that we should act like inanimate computers and just stop dead when we encounter them. This illustrates one of the great powers of the Cove as well: if we do get confused, there's a big community of experienced people here to help us avoid the dreaded ABEND message.

Jim

Thanks for reminding me of my programming life last century! I understand the example, but we shouldn't really need to rely on the Cove to try to justify or explain what is shoddy in the first place - better to build in quality at the outset rather than inspecting and fixing faults after they get through the system?