I’m looking for interpretation on this clause. I inherited the administration of the quality system, and I have been very hesitant to make major changes.

With this clause, the original author of our system wrote it to only address changes made during the development process. Once the product was “launched”, any changes made to the product or process were covered under the QS-9000 clause 4.9.5. From my research, I have come to believe that the clause is intended to address any changes made during the life of a product whether it is in development or in production for 5 years.

I am hoping the gurus here can confirm my interpretation or help me understand it further. Thanks for your help. In a small company like mine, where I am the only quality system person, I appreciate the chance to ask these questions of other professionals.

Dear Chris,

My interpretation is a little different. I use the clause for managing changes to the project (design input etc.) during the design process.

I prefer to consider any changes to a product, which has been already manufactured, as new design and development projects. Such a change does require all the elements desribed in 7.3 9k2k - i.e. input, output, planning, validation, verification etc.

MHO,

Anton

Reading this post made me wonder... Technically, from a 9k2k (or 9k1994) standpoint, does every small change to a poduct (as Anton says "any changes to a product, which has been already manufactured" or as Chris said "any changes made to the product or process") require a formal design documentation (records) of input, output, planning, validation, verification etc.? ANY changes to product or process???

How far do you Cove folks carry this?

I suppose a product *can* be changed without affecting the design or process. If you for instance replace a component in a machine with something from another supplier that has exactly the same specification, the end result would at least theoretically remain the same.

In reality, though...: Look out, because you never know. I have been run over by this particular truck, and it hurts. A seemingly innocent change may in fact change the end product.

A validation may still be appropriate, but ISO9k2k says "as appropriate" here.

/Claes

Mike,

Why not the design documentation? that does not mean that all the documentation developed during the initial product design process should be re-written.
If you make changes to product you must have reasons to do so and you must have some requirements determining the changes. Do use them as design input and make reference to existing product documents.

Verification may anyway be applicable (as Claes says).

If the changes are as minor as (Claes's example) changing a supplier of a part of the final product you may as well not consider this as a change. Of cource, only in the case:
- you are sure that this change will not significantly affect the end-product
- the new supplier is approved or complies to existing requirements and may be approved
- you design documents do not specify ALL the parts and ALL their suppliers which can be used for manufacture and therefore do not require change verification by chaniging a supplier.

... a bit messy I guess....

Resume:
- IMHO it is good to consider any significant design change to an existing product as a full scope design project
- paper flood can easily be avoided through references to old design documents, defining change input and output (as design input, output) and leaving alone changes not affecting the final product.

Anton

I would think that any change to the product is a design change, and as such must be considered by suitable technically qualified personnel for the implications of the change. This need not be beurocratic, a simple drawing change may suffice.

Just another point of view. I don't think this applies to changes during the design process. In design the design evolves and is reviewed, verified and validated before being "launched" until the launch all "changes" are covered by the design control process as a whole.

Again IMHO this clause just reflects the fact that the standard tries to catch all and uses safety nets like the "design changes" clause to say: "Oh and by the way if you change a design that has been through the design control process ... manage it in the same way as you did the first time."

Yes Paul - I think you are right.