By that I mean - can you draw a division between what needs to follow all the ISO steps and what can be done in the Chief Engineer's office at 7:00 at night on a piece of graph paper?

This is killing us. We just don't have the resources to make project out of every modification.

Can I define when the system needs to be used?

For example:
1) a distributor calls and asks to get a valve with SAE threads rather than the standard NPT. All we are changing is the threads - the working parts and all the materials remain exactly the same.
2) A customer calls and says - here's our idea, design us a valve that will do it.

Clearly case 2 would require a whole soup to nuts process... but what of case 1? If we follow the extended process it'll take days, where if we handle it more sensibly, the parts can be made and shipped in a day and we will still end up with the stuff needed in the QMS (drawings, specs, etc).

Can someone give me an example of how to draw the line that will pass and ISO auditor's muster?

What you describe in example 1 is a design change. Subject of a sub-paragraph in clause 7.3 of ISO 9001. 7.3.7 Control of design and development changes
Design and development changes shall be identified and records maintained. The changes shall be reviewed, verified and validated, as appropriate, and approved before implementation. The review of design and development changes shall include evaluation of the effect of the changes on constituent parts and product already delivered.

Records of the results of the review of changes and any necessary actions shall be maintained (see 4.2.4).

What you describe in example 1 is a design change. Subject of a sub-paragraph in clause 7.3 of ISO 9001.

So even if a new part number results it can still be considered a design change?

If it's a new item, then it needs to follow all of 7.0, Product Realization.

There is no easy way out... bottom line, changing threads changes functionality/appicability of that item. What if you shipped the new valve by mistake as the old one? Would it fit?

However, you don't have to reinvent the wheel from scratch, use what you have to start with.

If you have a system, it needs to be followed. That's the point of having one in the first place. You can't "draw the line" on when to use it, and when not to.

If you have a system, it needs to be followed. That's the point of having one in the first place. You can't "draw the line" on when to use it, and when not to.


But I can change the system.

Scott, when I first read your post it occured to me that you were talking pre eBOM. In other words before the design is locked into the Engineered Bill of Materials (aka "as designed").

I believe you are talking about design changes to an already designed and configured part. In this case you have to bite the bullet and process the change through your internal CCB.

Bob

What you describe in example 1 is a design change. Subject of a sub-paragraph in clause 7.3 of ISO 9001.

I think a reasonable argument could be made that this is a configuration change, and not a design change. Scott is looking for a bright line, and if there is one the dividing line is drawn in terms of function, I think.

I think a reasonable argument could be made that this is a configuration change, and not a design change. Scott is looking for a bright line, and if there is one the dividing line is drawn in terms of function, I think.As usual, you dissected the issue at hand in a paragraph, or less. In my opinion, a configuration change should be treated as a design change in the context of ISO 9001. The typical protocol of CCB's (Configuration Change Board) follows pretty much the requirements of ISO 9001 7.3.7.

Actually, a suggestion for the ISO 9001:2015 revision should be to revise that sub-paragraph of the Standard to state Design and Configuration changes.

But I can change the system.

Yes. You most definitely can.

And should when necessary.

The real question then becomes: how can we meet the requirements without tying ourselves in knots and making things far too difficult (and therefore perhaps uneconomic)?

Putting a different thread on a valve is a change, and doesn't need a whole other interation of the design process.

I've also seen where an organization states that anything less than (for example) 10 hours of an engineer's work doesn't require the whole 9 yards of D & D planning etc.

As, usual, you dissected the issue at hand in a paragraph, or less. In my opinion, a configuration change should be treated as a design change in the context of ISO 9001. The typical protocol of CCB's (Configuration Change Board) follows pretty much the requirements of ISO 9001 7.3.7.

Actually, a suggestion for the ISO 9001:2015 revision should be to revise that sub-paragraph of the Standard to state Design and Configuration changes.

This is probably another one of those things that's the same, but called by different names. Whether configuration or design is at issue, records need to be kept, and the approach is similar. What needs to happen in Scott's case, it seems, is for his documentation to allow for a simplified process when a ground-up design isn't involved.

The real question then becomes: how can we meet the requirements without tying ourselves in knots and making things far too difficult (and therefore perhaps uneconomic)?


That's exaclty it... we might do 5 "configuration changes" a day because we pride ourselves on being flexible. But if we have to use the whole D&D process for those we may as well surrender our ISO9001 registration right now becuase we'll never conform.

Thank you all for your help.

If you go the two path route, I advise making it very clear in the procedures, when the "short" route can and cannot be taken. My view is that, by proceduralizing the decision, you are doing the planning work up front in the procedure instead of doing it as part of each project.
When people ask for two paths, I always ask: What will you remove/do differently in the second path?", I then ask: "why don't we do use that method all the time?" - Often people talk themselves out of path two or we find a good improvement to our system.

BTW: I have three paths defined in one area.

If you go the two path route, I advise making it very clear in the procedures, when the "short" route can and cannot be taken. My view is that, by proceduralizing the decision, you are doing the planning work up front in the procedure instead of doing it as part of each project.
When people ask for two paths, I always ask: What will you remove/do differently in the second path?", I then ask: "why don't we do use that method all the time?" - Often people talk themselves out of path two or we find a good improvement to our system.

BTW: I have three paths defined in one area.


That's exaclty what I'm working on today. Re-doing the procedure to draw a bright line (as Jim said) between when it's a "change" and when it's a "project".

A friend of mine is manufacturing office chairs and often they are getting requests from customers for changes from simple things like fabric in the upholstery to a different type, to PVC and/or leather and to critical items like the chair base, the roller/castor's, etc.

They called it 'customization' and it is provided for in their procedures. The simple items like fabric and upholstery changes will need the production head's approval whereas, for critical components, the customer can only choose from a list of pre-approved alternatives. Anything outside this list will need special consideration and approval from both the R&D and production head.

Hi ScottK,
just my modest point of view as I was a designer some time ago.
I suppose You can said that case 1 is a customization but You have no evidence You don't need to follow every steps (opinion is not an evidence). the history is full of customization that fails into the field:(
anyway once I was in the same situation but we have worked on the design plan side. Let me explain with an example.
You are designing a valve, don't think at it as one valve but as a family of valves. Therefore You shall consider during the design phase all the possible variation like threads. You write an DFMEA considering all the "variation" and find which are the most critical combination of them, you can perform then tests etc. After You have to analyse your production line vs valve family. At the end it will be the design/process documentation that states which "customizations" have been already cosidered/analyzed/proven, which are not but require some short tests, and which have to be "full validated".

Another point is this makes sense if we are talking about very small production. If we are talking a customization for one million of valve, well it wiser to follow/check every step respect to the "master" valve design development.