Satisfying the ISO 9001:2008 7.3.5 Design & Development Verification requirement

[smryan]

Hi all. Long time.....

I am revamping our D&D documentation to match existing process. For satisfying the ISO 9001:2008 7.3.5 Design & Development Verification requirement I am wondering how an Auditor would feel about something worded somewhat like this:

Dimensional verification occurs periodically through the process. Passing marks are not documented unless specifically requested by the customer. Failing marks and resulting actions are handled & recorded through our existing Non-Conforming procedure.​

We build capacitors. Tiny. Big. Largest one in regular production is 35 lbs. They need to fit in their spots, but tolerances are relatively large in most cases.

 

[Jen Kirley]

Re: 7.3.5 Design & Development Verification

Since 7.3.5 is about design verification, I wonder if you want to describe in-process inspections. Design & development verification involves inspection and testing, even customer approval of prototype as needed, before production begins.

That said, I am wondering what is the purpose of doing dimensional checks if no data is taken except for failures. Besides the obvious (finding failures and stopping a process that is producing them) would you also be interested in being able to note process drift before it falls off a cliff into nonconformance?

 

[somashekar]

All that you have made in your design reviews and recorded, when translated into the design output, which each fits into the other to realise your design (ON PAPER OR ON COMPUTER) before you take them to make and validate.

If you have a documented procedure, you can state your method how you perform this verification.

 

[smryan]

Re: 7.3.5 Design & Development Verification

Since 7.3.5 is about design verification, I wonder if you want to describe in-process inspections. Design & development verification involves inspection and testing, even customer approval of prototype as needed, before production begins.

That said, I am wondering what is the purpose of doing dimensional checks if no data is taken except for failures. Besides the obvious (finding failures and stopping a process that is producing them) would you also be interested in being able to note process drift before it falls off a cliff into nonconformance?

In D&D we are pretty much talking about prototypes - there is no drift of note in the making of 2 or 3 parts. The issue is does the output match the input. The electrical / performance data is recorded. The fit/dimensional data is not - unless it is OOT and needs to be fixed. Our prototypes are made in the same facility by the same people using the same processes as would be used should the part go into production. Thus the "in process" reference.

 

[smryan]

All that you have made in your design reviews and recorded, when translated into the design output, which each fits into the other to realise your design (ON PAPER OR ON COMPUTER) before you take them to make and validate.

If you have a documented procedure, you can state your method how you perform this verification.

So am I getting this correct - Verification applies ONLY to DOCUMENTS? Because in my little world the output of the whole D&D Process is a part - so I took Verification as applying to that output - meaning the part is to be verified to the drawings/specs.

Now I feel confused.

 

[somashekar]

meaning the part is to be verified to the drawings/specs.

+ the check if your part also performs as desired in your input in the VALIDATION.

 

[smryan]

+ the check if your part also performs as desired in your input in the VALIDATION.

Hmmm. And in our little world the Validation is "does the part function as intended in the customer's application" - which requires the customer's feedback.

 

[somashekar]

Hmmm. And in our little world the Validation is "does the part function as intended in the customer's application" - which requires the customer's feedback.

Validation needs to be performed. Where and who does this is your operational convenience.
You can validate parts, sub-assemblies and further the product.

 

[Mikishots]

Hi all. Long time.....

I am revamping our D&D documentation to match existing process. For satisfying the ISO 9001:2008 7.3.5 Design & Development Verification requirement I am wondering how an Auditor would feel about something worded somewhat like this:

Dimensional verification occurs periodically through the process. Passing marks are not documented unless specifically requested by the customer. Failing marks and resulting actions are handled & recorded through our existing Non-Conforming procedure.
​

We build capacitors. Tiny. Big. Largest one in regular production is 35 lbs. They need to fit in their spots, but tolerances are relatively large in most cases.

As an auditor, I can say this: the subclause is asking that you check your design first on paper (software, etc...you get my point) to make sure it's on track and will be able to meet the design inputs you compiled through 7.3.2. The external customer may have specified their requirements for design verification through contract, so it's up to you to decide if this is the case or not.

It can be very expensive to validate a design (see 7.3.6) if you haven't verifieid it on paper first; make sure that the business case is still present and strong before you even bother proceeding to the validation stage.

Carry out your verification according to your design plan (7.3.1) to prove that outputs meet the input requirements. You can do this through calculations, simulations or a simple review/comparison between inputs and outputs. This verification doesn't happen one time - it happens during each stage of design.

You have to keep records.

 

[smryan]

Thanks, Mikkishots, I think this helps. Clearly - in spite of some on-site trainings - there is some terminology that has yet to be cleared up. I'll fix that!

So - a related question.... if one engineer sends an email to another saying "check this drawing" and the other, after verification, emails back and says "Good job!" - is that sufficient "documentation"?