No Formal Design Process - Audit Finding - Help with Section 7.3 of ISO 9001:2008

[JaneB]

Depends upon the tribe and quality of the knowledge..........The Inuit have designed and built a pretty successful boat (qajaq or kayak) for a long, long time without a documented process

But y'all surely aren't claiming the Inuit are certified to ISO 9001, are you? Which I just somehow think Sidney was referring to.

What is needed here I think is better info from the OP as to what the specific finding of the auditor was and what it actually said. Otherwise there is some risk of fiercely arguing over theoretical points (I do concede yours, Randy), based on inadequate info, which while interesting and entertaining may not be particularly enlightening to the OP..

 

[smryan]

Depends upon the tribe and quality of the knowledge..........The Inuit have designed and built a pretty successful boat (qajaq or kayak) for a long, long time without a documented process

I concur with Randy here. My company was sucessfully designing and making product long before the ISO cert. When they went for the ISO cert the choice was made to document everything - mostly to have easy evidence to point to for the auditor. Not a "have to", but as headache avoidance. Certain documentation, like the design process, have been rather vague out of necessity.

As the company grows, new engineers are added, and a new product line has developed, the need for detailed documented procedure has been a necessity to make sure that all the appropriate documentation gets done... makes it easier for someone who wasn't born in the tribe to have some written directions. Now that we are considering the TS16949 cert the existing process needs to become much more structured than it is. The documentation is in place, but the detail needs to be amped up considerably.

 

[KENWALTON123]

All, thanks for your feedback.
To clarify, we have controls in place for design and meet all requirements of NBIC and ASME, but I assume the auditor was looking for "The Book" of how we get from point A to point C. Maybe I'm mistaken, but from my conservation with the auditor this is what I believe he was looking for. I was hoping to determine how others prove they comply with section 7.3, how do you document this?

 

[Jim Wynne]

All, thanks for your feedback.
To clarify, we have controls in place for design and meet all requirements of NBIC and ASME, but I assume the auditor was looking for "The Book" of how we get from point A to point C. Maybe I'm mistaken, but from my conservation with the auditor this is what I believe he was looking for. I was hoping to determine how others prove they comply with section 7.3, how do you document this?

As Randy and others have pointed out, there is no explicit "shall" with regard to having a documented system. In terms of practicality, however, I don't know how you would fully control a design process without documentation. You may have discovered why documentation makes sense. If you couldn't demonstrate control to the auditor--show him that your system has requirements that control the effectiveness of the process--you're left with saying, "Trust me, it works," which an auditor is unlikely to accept as evidence.

On the other hand, if you can demonstrate that the designers understand the requirements and follow a standard process, the auditor would be wrong if he insisted on documentation.

 

[Sidney Vianna]

The Inuit have designed and built a pretty successful boat (qajaq or kayak) for a long, long time without a documented process

So did the vikings. But I don't see any business consultant guru promoting the tribal knowledge approach to running an organization.

 

[JaneB]

As Randy and others have pointed out, there is no explicit "shall" with regard to having a documented system. In terms of practicality, however, I don't know how you would fully control a design process without documentation. You may have discovered why documentation makes sense. If you couldn't demonstrate control to the auditor--show him that your system has requirements that control the effectiveness of the process--you're left with saying, "Trust me, it works," which an auditor is unlikely to accept as evidence.

On the other hand, if you can demonstrate that the designers understand the requirements and follow a standard process, the auditor would be wrong if he insisted on documentation.

Jim has captured the key points here. And reading that along with the excellent example smryan gives, should get you thinking.

If your process isn't clearly defined at the moment (and it sounds like it might not have been if you couldn't convince the auditor), it won't be robust enough to cope with stresses, including growth - eg, in size, products etc.

But if it is clearly defined, and your auditor is saying no, I want to see a written procedure, he's wrong. There is no requirement for a documented procedure in 9001.

That said - one way of approaching it, if you decide some documentation is necessary, is via a flow diagram, just setting out the main steps, decision points, and capturing what records are generated at which points (a good way to make sure you meet the requirements for records). A one-pager for example.

Finally - remember the purpose of having requirements in the first place! Because it's good practice, fosters a consistent approach, and enables both identification of problem points and improvement.

 

[Big Jim]

A good design checklist helps too.

 

[Randy]

So did the vikings. But I don't see any business consultant guru promoting the tribal knowledge approach to running an organization.

So that means it can't be done?

 

[JoCam]

Hi KENWALTON, does this help?

Jo

 

[Sidney Vianna]

So that means it can't be done?

Sure it can be done. Tribal knowledge brought us to where we are today. We can also (attempt to) treat brain cancer with a bloodletting procedure.

Evolution is not compulsory.