Process Auditing Clause 7.3 Design and Development

[kgott]

One of our business units does design and design verification for pressure equipment (boilers etc,) for its external clients.

Before I arrived, their certification was in jeopardy. My instructions have been to work with them to get them back on track and keep the certification.

However, I want to do more than that, I want to help them get real benefit out of 9001 so they?ll see real benefit in it and achieve more than just re-certification.

The CB has indicated they will be focusing on ?Design and Design Verification? (Section 7.3) at the next audit. It has been decided that I will do an audit focusing on Section 7.3, design and development so we can iron most of the problems out before the CB comes in the first quarter of 2013.

Auditing is my weakest link and I know that process auditing will be more beneficial for them than clause auditing so I?m going to have a go at it for the first time. I really want to get this as right as I possibly can because I want to provide these people with good useable information and build/retain my own creditability.

The procedures this business unit uses are a combination of highly detailed work instructions, some work flow process description and regurgitation of 9001 so in my view, they are of somewhat limited usefulness in terms of auditing the process.

Is it possible to audit S.7.3 using the process approach and if so could I please have some ideas on the sorts of questions I need to think about and ask?

The truth is I?m feeling a bit under the pump with this.
Thanks k

 

[harry]

Nothing beats having an intimate knowledge of the process you are going to audit. In the absence, a good understanding aided by good guidelines helps - Auditing the Design and Development Process

 

[John Broomfield]

kgott,

You could practice auditing any process that is meant to add value to information.

As well as following APG advice also remember to audit design change control when dealing with nonconforming product (design changes: include "use as is" and repair dispositions unless approved repair specifications apply).

The design process also result in documented information such as: "as-builts", user manual, labeling, packaging and maintenance manuals.

Leave configuration management for another day.

Best wishes,

John

 

[Marcelo]

Any clause of a process-based standard can be audited using the process approach.

For some ideas, generally this means auditing focusing in the following questions, deriving more related questions as the audit progress:

What are you trying to do?

How do you make it happen?

How do you know it?s right?

How do you know it?s the best way of doing it?

How do you know it?s the right thing to do?

(those are from the best book on quality standards process auditing, IMHO, Hoyle's ISO 9000:2000: Auditing Using the Process Approach)

 

[somashekar]

Is it possible to audit S.7.3 using the process approach and if so could I please have some ideas on the sorts of questions I need to think about and ask?

Get a complete grip of all the design plan and design inputs that has been considered in a project and make a check if any statutory and regulatory inputs are included (since you mention pressure equipment)
A drill down in the audit into how design inputs were collected, agreed and freezed before next steps brings all the inputs to the platform (perhaps including cost). An other question to ask is if the design review / verification / validation activities made any changes to the design plan / design inputs or brought in new inputs.
In the audit of all other design and development activities where the main task is to bring out design outputs that meets the input requirements.... ask.
Show me how which design input is met and who approves it.
It may sound simple, but let us know that the design inputs are broader and outputs may be several much beyond what can be expected in input. The design and development expertise must be in a position to link, relate, explain and approve all the outputs to the several inputs. (A sound knowledge of the design and development in question with the auditor helps in this)
So we see that the D&D steps which replicates a PDCA can be audited by coming back to the Plan (design plan / input) several times and at several stages, to see how design outputs meets input requirements.

 

[kgott]

Nothing beats having an intimate knowledge of the process you are going to audit. In the absence, a good understanding aided by good guidelines helps - Auditing the Design and Development Process

I agree with you Harry but I am not all familiar with the process and the documentation runs to 11 pages and says very little that is useful.

 

[Colin]

When I conduct audits on a design department I select a couple of recently finished projects (depends upon time and the size/complexity of the projects) and follow them as they pass through the design process.

You can either start at the beginning and work through or start at the end and work back (at least that way you know the job has been completed).

So if start at the beginning I want to know things like 'what did the customer ask for? was there a specification or performance criteria quoted, etc (by the way, you may have to go to sales for this information).

How did they plan the design and was it agreed with the customer - was any slippage allowed for?

How are the design inputs stipulated and is there evidence that any applicable statutory and regulatory requirements have been included?

And so on .. in other words, I will work my way through the design process, using 7.3 and a real project looking for evidence but also interfacing with other departments such as sales, purchasing, production, testing, etc as required.

There are also other potential clauses such as customer satisfaction, nonconformance, document control, records, etc that you will pick up along the way. e.g. when you look at the drawings, check their revision status and make a note of it. When you look at the test results, make sure they were using the same version.

 

[qusys]

One of our business units does design and design verification for pressure equipment (boilers etc,) for its external clients.

Before I arrived, their certification was in jeopardy. My instructions have been to work with them to get them back on track and keep the certification.

However, I want to do more than that, I want to help them get real benefit out of 9001 so they?ll see real benefit in it and achieve more than just re-certification.

The CB has indicated they will be focusing on ?Design and Design Verification? (Section 7.3) at the next audit. It has been decided that I will do an audit focusing on Section 7.3, design and development so we can iron most of the problems out before the CB comes in the first quarter of 2013.

Auditing is my weakest link and I know that process auditing will be more beneficial for them than clause auditing so I?m going to have a go at it for the first time. I really want to get this as right as I possibly can because I want to provide these people with good useable information and build/retain my own creditability.

The procedures this business unit uses are a combination of highly detailed work instructions, some work flow process description and regurgitation of 9001 so in my view, they are of somewhat limited usefulness in terms of auditing the process.

Is it possible to audit S.7.3 using the process approach and if so could I please have some ideas on the sorts of questions I need to think about and ask?

The truth is I?m feeling a bit under the pump with this.
Thanks k

Use process approach asking for the inputs/outputs of the process, how the process is measured, with what procedures and how, which kind of skills/competence is required, how the personnel react in case of problems etc...
Ask for the records produced by the process and if they met requirments.Undestand links with other QMS processes and verify if there are shortcomes . Check at efficiency and effectiveness of the processe as well as at the continual improvement. This from general standopoint, you can also investigate the application of the process to a specified example or product ( for instance, one as new product introduction and one as mature).

 

[Mikishots]

One of our business units does design and design verification for pressure equipment (boilers etc,) for its external clients.

Before I arrived, their certification was in jeopardy. My instructions have been to work with them to get them back on track and keep the certification.

However, I want to do more than that, I want to help them get real benefit out of 9001 so they’ll see real benefit in it and achieve more than just re-certification.

The CB has indicated they will be focusing on “Design and Design Verification” (Section 7.3) at the next audit. It has been decided that I will do an audit focusing on Section 7.3, design and development so we can iron most of the problems out before the CB comes in the first quarter of 2013.

Auditing is my weakest link and I know that process auditing will be more beneficial for them than clause auditing so I’m going to have a go at it for the first time. I really want to get this as right as I possibly can because I want to provide these people with good useable information and build/retain my own creditability.

The procedures this business unit uses are a combination of highly detailed work instructions, some work flow process description and regurgitation of 9001 so in my view, they are of somewhat limited usefulness in terms of auditing the process.

Is it possible to audit S.7.3 using the process approach and if so could I please have some ideas on the sorts of questions I need to think about and ask?

The truth is I’m feeling a bit under the pump with this.
Thanks k

Process approach for D&D? Absolutely. Here's how I do it:

I start with a turtle (gahh...run!) and map out what's coming into the process and what's going out from it.

Example

Inputs:
Effect on WIP
Safety and regulatory requirements
Effects on constituent parts and systems
Existing design
Impact, cost, manufacturability, inspectability
Inputs from key development team members as required (procurement, order handling, planning, tech writers etc).
Inputs directly from customer.

Outputs:
Design drawings, specs, substantiations
Tech manual changes if needed. Service bulletin requests if needed.
Inspection plans
ID of key characteristics critical for product acceptance
Test reports
Records of reviews

I make sure that the processes that feed into D&D are defined and that the owners of those processes are aware of the requirements set out in the D&D process. Same goes for the output processes. The biggest thing is to find out how the process determines effectiveness; how is it determined when things are going sideways? What does the process say to do about it when it happens? If it has already happened and a fix was offered, did it work? Why or why not?

Short, but at least it might give you some ideas.

 

[kgott]

Right; I've made a mistake I shouldn't have made.

I went through the business unit procedure for how they control jobs (designing pressure equipment) and identified questions I should ask for each stage of the process, mostly relating to evidence to establish how well the practice matches the theory. (procedure) (Despite wanting to do a process audit I think I have actually done a procedure audit.)

Trouble is; I have made the basic mistake of not comparing the requirements of the procedure with the requirements of S.7, Product Realisation.

This means that I did not ask for or sight evidence of the relevant sections of S.7 being completed.

My question is; how do I account for this in my audit report?

I must admit I have also become a little confused about clause 7 being about the design and development of the business unit service and the fact that their service is design and verification of design.

thanks