Updating to ISO 9001:2008 - I need to add section 7.3 Design and Development

[AndyN]

From what I was told, we have always been the engineering and design for our customers, but our customers have always headed the design process, taking full accountability. We were walking a fine line by excluding it from our original certification, but now we have customers that are requiring us to be certified with section 7.3.

The simple question you have to answer is "can we make a change to a product spec without anyone else's approval?"

If the answer is 'yes', then you are product design responsible. If the answer is 'no', then the customer owns the design. You may be a significant input to the process, but it's not your process.

Now, in terms of ISO certification, if you answered 'no', then all you may need to do is describe how you act on and interface to customers' design processes. But this shouldn't be under 7.3 of ISO 9001, since you aren't responsible, try 7.1 and 7.2.

If you decided you are design responsible, it's not just having a policy and procedures you need for certification, as I said. You'll have to demonstrate all the requirements of design control have been implemented. No evidence = non-compliance in most cases.

 

[John Martinez]

The simple question you have to answer is "can we make a change to a product spec without anyone else's approval?"

If the answer is 'yes', then you are product design responsible. If the answer is 'no', then the customer owns the design. You may be a significant input to the process, but it's not your process.

Now, in terms of ISO certification, if you answered 'no', then all you may need to do is describe how you act on and interface to customers' design processes. But this shouldn't be under 7.3 of ISO 9001, since you aren't responsible, try 7.1 and 7.2.

If you decided you are design responsible, it's not just having a policy and procedures you need for certification, as I said. You'll have to demonstrate all the requirements of design control have been implemented. No evidence = non-compliance in most cases.

If you decided you are design responsible, it's not just having a policy and procedures you need for certification, as I said. You'll have to demonstrate all the requirements of design control have been implemented. No evidence = non-compliance in most cases.

I agree with Andy but would ask why is your customer now requiring you to include 7.3 in your certification?

I would also caution that you do not have to either implement or take exception to ALL of 7.3. For instance if you client does the design portion and you do the validation, then neither is 7.3 all applicable or all excludable.

To your original question, nothing in 7.3 of ISO 9001:2008 requires a procedure. If your management system requires one, then you will need to implement one.

In addition, not to add to your worries, but besides implemented, depending upon what your internal audit procedure states, you may have to internal audit it as well.

If you could postpone your audit, I would.

 

[DrM2u]

Are you saying that I do not have to have procedures to reference 7.3?! Where would I find this in writing. Inevitably I will write procedures, because we do meet all of the documentation requirements, but if I could get away from having to have the procedures completed by audit time, this could allow me to focus on more important items.

I would like to thank everyone for there input!!

Read clause 7.3 and you will not find any sentence that includes 'the organization shall prepare documented procedures' or anyhting along these lines. The ISO 9001 requires only (6) procedures, the rest are up to the organization as deemed necessary:
Document control (4.2.3)
Record control (4.2.4)
Internal audit (8.2.2)
Nonconforming product (8.3)
Corrective action (8.5.2)
Preventive action (8.5.3)
(the last two are often combined into one)

I am not a big fan of procedures because they can constrain processes and improvement. The intent of documentation (unless required) is to compensate for the lack of knowledge necessary to perform a task or more (process). Always make sure that the PROCESS is compliant with the requirements and have the documentation (if any) match and follow the process. Do not let documentation drive the process or a few years from now you'll hear 'we've always done it this way' instead of a good reason for having and following certain processes.

 

[Stijloor]

<snip>I am not a big fan of procedures because they can constrain processes and improvement. The intent of documentation (unless required) is to compensate for the lack of knowledge necessary to perform a task or more (process). Always make sure that the PROCESS is compliant with the requirements and have the documentation (if any) match and follow the process. Do not let documentation drive the process or a few years from now you'll hear 'we've always done it this way' instead of a good reason for having and following certain processes.

Well........

Here is my view. The purpose of process documentation (in whatever form) is to:

1. Ensure consistency of practice
2. Preserve knowledge

Whether people like it or not, running a company on tribal knowledge and memory is extremely dangerous.

A well-defined and documented process is easier to control and improve than a process supported by 5 memorized recipes....

Regretfully, documentation is often used to support a stupid bureaucracy, and that is I believe your concern as well.

Stijloor.

 

[DrM2u]

Well........


Here is my view. The purpose of process documentation (in whatever form) is to:

1. Ensure consistency of practice
2. Preserve knowledge

This is why I am proposing that documentation follows the process ... to preserve knowledge and serve as a reference (compensate for lack of knowledge) when needed to preserve consistency of practice. We are on the same page on this ... I think.

Regretfully, documentation is often used to support a stupid bureaucracy, and that is I believe your concern as well.

Indeed ... I have seen too many companies with thick binders full of procedures and instructions that do nothing but collect dust and make changes & improvements difficult to implement.

 

[Stijloor]

Thanks! Yes, we are on the same page.

A question to ask relative to documentation is:

What information do our employees need to perform their job

• Safely
• Effectively
• Efficiently

Then, only then we look at what the standard requires and possibly customers and statutory and regulatory requirements.

Organizations get too wrapped up in the requirements initially and ignoring what the folks in the trenches need.

The employees ("user community") are often ignored as information is produced. As a result we see multi-page docs and instructions that put you to sleep or are hard to interpret.

User-friendliness comes to mind.

Sorry for my rant.


Stijloor.

 

[TBDQM]

I agree with Andy but would ask why is your customer now requiring you to include 7.3 in your certification?

If you could postpone your audit, I would.

It is a new customer that we are now doing business for....
I really wish I could postpone the audit but apparently it has been postponed two many times already. I appreciate everyone's feedback, I have gotten more information here than 3 days of googling!

 

[Stijloor]

It is a new customer that we are now doing business for....
I really wish I could postpone the audit but apparently it has been postponed two many times already. I appreciate everyone's feedback, I have gotten more information here than 3 days of googling!

Don't postpone the audit. Just provide your customer with a detailed action plan showing how and by when you will have a complete design and development process in place. I would not risk getting dinged with a major nonconformity because of a sloppy D&D process. At the next surveillance audit you could then expand the scope of the QMS to include the D&D process.

Stijloor.

 

[Colin]

Sorry to be pedantic on this issue but a few posters have said 'you don't need a procedure for design' - well, you certainly don't need a documented procedure but you need control over the process. There will almost certainly be a procedure for conducting design already. Whether this aligns with the requirements of clause 7.3 is another matter.

The other problem I foresee is that if the present method of controlling designs does not comply with 7.3, there is unlikely to be sufficient time to build satisfactory evidence to demonstrate that the design process is in control. In other words, what are you going to show the auditor when s/he asks for the evidence?

 

[artorius22]

I am faced with the carnage of a company converting from QS to TS with no changes other than renumbering. Unfortunately the system has grown to 30 procedures, 70 or 80 work instructions, and several hundred forms. My current task has reduced this monstrosity by 65%