Permissible Exclusions in Section 7 - Design control requirements - No design

Hi guys,
This is the first time I start a new topic, although I´ve been following all discussions particularly in the ISO 9X forum, where I´m more interested.
I would like to hear from you on the permissible exclusions (clause 1.2 of ISO/DIS 9000:2000, particularly where design/development is concerned.
To my knowledge, many companies registered to IS0 9002:1994 in order to avoid compliance with the requirements of design/development of IS0 9001:1994. In situations where IS0 9001 was not a contractual requirement, it was reasonable to understand that companies would opt towards IS0 9002.

When IS0 9002 is removed those companies will have to comply with IS0 9001, which includes requirements for design/development.
My questions are:

Will these companies be able to justify exclusion of design/development requirements?

Let us now imagine a company registered to IS0 9002 in Brazil, subsidiary of a large multinational group, manufacturing products with the technology obtained from a non registered American manufacturer from the same group. It´s reasonable to expect that as years went by, the brazilian subsidiary has also adapted and even made some minor developments on similar products, more adequate to the brazilian market and conditions. This situation has been happening with products in the market for years.

How will such situation be handled by the registrars?

In a recent article for Quality Digest, it is stated that “The intention is primarily to allow exclusion of design control requirements where there are no design activities”. I hope that is right.

What are your views?

[Marc]

I'm going to first point you to this discussion thread: Design - Widget vs. Service Organization Product

There will be much debate about this. I do not agree wholly with “The intention is primarily to allow exclusion of design control requirements where there are no design activities”. I believe that just about every company does some type of design - even service organizations. The problem is many people don't associate the word design with anything except 'widget' design. But, as the other thread points out there are aspects of what a service company does which are clearly design (in my opinion).

This, by the way, was recently e-mailed to me: I am presently adapting the design aspect of ISO to programme development. However, the resulting detail it requires the programme co-ordinator to think about makes them very reluctant to embrace the concept. Imagine asking them

What is the purpose of your programme
What are the input to your programme
Why did you select these inputs
How do you know they are valid inputs
How do you assess the need to change the inputs
How do you know the programme works

A secondary thought here - you can exclude many aspects of a business from the defined registration scope. Many want to make thisw a 'moral' issue as much as anything else. I remain non-judgmental - if you want to exclude something from your registration scope that's your business. Your customers requiring registration will make the decision on whether what is in the scope is sufficient or not. I have seen companies exclude specific production lines from their registratyion scope. I'm not saying this is a good idea, but I refuse to moralize on this one.

Marc,
I didn´t refer to the other forum because I thought the discussion on that topic was more related to service organisations. I am concerned about all manufacturing organisations that are certified to ISO 9002,and are actually making product development to different and variable extents. It will be very difficult for registrars to define the starting point from which the design/development requirements of the Standard need to be applied. Therefore, as You said, maybe the best thing to do is to let certified customers decide about the issue.
But, let´s imagine that we have customers certified to ISO 9002 who want to start working towards the new Standard. How should we handle this matter? Maybe the best for the time being is wait until things get more clear. Don´t you think so?

[Marc]

It will be very difficult for registrars to define the starting point from which the design/development requirements of the Standard need to be applied.

Registrars don't. You do. You determine / identify what you do, when you start, etc. remember, each project will differ somewhat.

I think you're taking this a bit too hard. You look at your organization and the interfaces you have. You look at section 7 and (in addition) you see what you do and do not do. Maybe you just get prints and build to them. just as with ISO9002 you justify what you do and do not do.

But, let´s imagine that we have customers certified to ISO 9002 who want to start working towards the new Standard.

I worked with a company in the fall - winter 1998-99. They registered to the 1994 version in June 1999. But - the quality manual I wrote for them was to the draft of the time. Yup - they'll have to upgrade the manual a bit, but for all intents and purposes they are compliant to ISO9001:2000. And 2 of my current clients are working on the year 2000 version.

I don't believe there's too awful much clarity to come. As I have looked thru the proposed changes I simply don't see that big a change all in all. My opinion of the doomsayers is that they compare top the Y2K doomsayers: Instead of a lot of "You wait and see!" you're getting "But it might radically change!" and "It's so drastic changing will be a serious problem." I'm sorry, I don't buy it.

My opinion? Don't be afraid. Start upgrades now.

I' going to write a manual based on DIS for a 9001:1994 certification, but I'm not sure the registar is going to like it, I've been told that many registars until now recommend to mantain 9001:1994 structure, and add in a separate section the new requirements of DIS... I don't agree with this, but I don't know what to do.......
What's your opinion about that?

[Marc]

Originally posted by Frankie:

I' going to write a manual based on DIS for a 9001:1994 certification, but I'm not sure the registar is going to like it, I've been told that many registars until now recommend to mantain 9001:1994 structure, and add in a separate section the new requirements of DIS... I don't agree with this, but I don't know what to do.......
What's your opinion about that?

My opinion is make a matrix. I doubt a registrar cares how you structure your documentation. What they do want is a clear way to see where you meet the spec.

A number of my clients have kept their existing documentation structures and those structures were in place well before ISO9000 was a part of their 'plan'.

See Doc_map_B.pdf and Doc_Matrix.pdf in This Directory

The question is, if you decide to have a separate quality manual (which most companies do), how do you structure that. My current clients are structuring their systems manual after the 2000 DIS - which I suggest is appropriate.

Do what you want - the registrar doesn't care.

[Francesco]

Marc is right, the matrix is a good idea, expecially for small organizations. I've done it for my last client, It's very similar to the example Doc_Matrix.pdf,in addiction it includes the distribution list: doing this way you can remove from all the procedures that matrix, and in case of add/remove someone from the distribution list of one or more procedures, you are not compelled to make a revision of every document, but only of the main matrix.

Returning to the registars, don't care them, Frankie, simply meet the requirements and go straight your way.

Frankie,
I´m also working on a matrix for the System Quality Manual. And to get my work done more quickly, I downloaded document hb150 from Standards Australia. It costs something like US$ 17.00, I think, but I found it very useful, because it shows very clearly all the changes between the 1994 and the 2000 versions.Take a look at it. May be you´ll find it useful too.