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?

I'm going to first point you to this discussion thread: Design - Widget vs. Service Organization Product (http://Elsmar.com/Forums/showthread.php?t=2691)

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?

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?

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 (http://Elsmar.com/pdf_files/)

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.

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.

From: ISO Standards Discussion
Date: Thu, 10 Aug 2000 11:12:01 -0500
Subject: Re: Permissible Exclusions /../Trudeau/Arbuckle/Salinger

From: rudy.salinger dowcorning.com

Although ISO 9001:2000 would say "purchasing" cannot be excluded from the Quality System scope, it should be possible to address this requirement with minimal effort. The process which you would have to "establish, document, implement, and maintain" might be as simple as a statement in the top level documentation (Quality Manual) that "no materials or services that affect product quality are purchased. All other purchases are at the discretion of the employee requiring them." But you will have to be sure the exclusion of "services" as well as materials is valid, otherwise you will indeed have to put up a process.

The justification for this approach is the statement in ISO 9001:2000 that "The type and extent of control shall be dependent upon the effect on subsequent realization processes and their output."

This is my opinion, but it should be verified with the firm's registrar.

Rudy Salinger

> From: "Donald Arbuckle"
> Let me see if I understand this...

> If my company does not purchase anything (all parts, equipment, facilities,
> etc. are provided by the customer) other than laser paper for office use,
> pens/pencils, etc, then in order to meet the requirements of the standard
> and become compliant/registered, I must still establish, document, implement
> and maintain a purchasing process?? Doesn't this conflict with the
> requirements in 4.1 a), "identify the processes needed for the quality
> management system"?
> [I have other examples, but all reflect the same point...]

> I look forward to the technical specification that makes this perfectly clear...

>> From: "Trudeau, Pat"
>> John:
>> I have talked to a TAG team member personally about this and the only
>> exclusions are servicing and design. The team is in process of writing a technical
>> specification on the permissible exclusions right now that will make everything
>> crystal clear. You can also call ASQ directly and talk to Patty Kopp in standards
>> who will verify this.

**************************

From: ISO Standards Discussion
Date: Thu, 10 Aug 2000 11:13:45 -0500
Subject: Re: Permissible Exclusions /../Trudeau/Hartman

From: dhartman

Pat Trudeau stated, "I have talked to a TAG team member personally about this and the only exclusions are servicing and design."

In fact at this year's ASQ Annual Quality Congress Charles Cianfrani stated that the reason that 7.6 Control of Measuring and Monitoring Devices was placed in Section 7 was to allow service organizations the ability to take exception to it (since Section 7 is the only section where exceptions can be taken).

This would lead me to believe that it was "intended" (at least by some members of the TAG) to allow for exceptions to be taken to any/all portions of Section 7.0, as appropriate for your organization.

David Hartman

***************************

From: ISO Standards Discussion
Date: Thu, 10 Aug 2000 11:28:58 -0500
Subject: Re: Permissible Exclusions /../Arbuckle/Kozenko

From: Write9000

Don Arbuckle writes:
> If my company does not purchase anything (all parts, equipment, facilities,
> etc. are provided by the customer) other than laser paper for office use,
> pens/pencils, etc, then in order to meet the requirements of the standard
> and become compliant/registered, I must still establish, document, implement
> and maintain a purchasing process?? Doesn't this conflict with the
> requirements in 4.1 a), "identify the processes needed for the quality
> management system"?

Don and List:

I'm not saying "do this or else" because it's not appropriate for every firm, but here's a case where the answer to your inquiry is "Yep, you need Purchasing Procedures in all cases..."

I stayed late one evening (when my kids were young, no less ;o) to manually "baby-sit" the high-speed copy machine while we (as in, me and the machine ;o) ran 20 copies of a report due to the client, earlier that morning.

INDIRECTLY, the purchase of a bargain brand of copier paper had resulted in a mechanical incompatibility. Or in other words, the cheap paper didn't work worth a squat in the high speed copier.

The administrator who bought the paper thought he was doing great things because he saved the company a boatload of money. He wasn't reprimanded too much, because his intentions were sincere and there were no written procedures for purchasing. (Sincerity didn't matter, but the lack of Procedures did.)

Now, some firms can quickly attack the "Direct" impact on quality factors and stop there, and everything is fine. For those firms (and per your Post question), no Purchasing procedure would be required.

There might be other firms where a similar "quality attack" needs to happen on "Indirect" and perhaps even "Consequential" impacts on quality (especially Human Resources decisions and policies) because the more visionary your quality thinking becomes, the more apt you are to include these latter two in the root cause analysis of today's quality problems and in the justification for Preventive Actions against tomorrow's.

David M. Kozenko

****************************

From: ISO Standards Discussion
Date: Thu, 10 Aug 2000 11:31:23 -0500
Subject: Re: Permissible Exclusions /../Arbuckle/Miller

From: Ray.Miller (Ray)

All modern quality systems require procedures for documentation, training, purchasing, and contract review. If your employment agency or creative trade genuinely purchases no supplies or any materials, your H.R. process is therefor your purchasing process. If you contract your labor, your contract review procedures are your purchasing procedures.

The concept of a viable enterprise without a purchasing system is perhaps attractive, but will never actually work in the real world. The money leaves somewhere, somehow, and somebody gets it. Where does it go? How much? How often? With purchasing controls, you can answer all these questions.

--Ray

From: ISO Standards Discussion
Date: Tue, 15 Aug 2000 09:13:30 -0500
Subject: Re: Permissible Exclusions /../Salinger/Arbuckle

From: "Donald Arbuckle"

Perhaps in my attempt to be clever (and somewhat facetious) my point got missed. I'll be more direct.

I cannot believe that the writers of the standard are truly saying that only Design and Servicing are permissible exclusions. If so, then why not say that, rather than leaving permissible exclusions open all of section 7. Mr. Hartman's post seems to support the idea that any part of section 7 can be excluded. That also appears to be the meaning of the statement in 1.2 Permissible Exclusions that reads, "These exclusions are limited to those requirements within clause 7..." I am in great disbelief that they meant anything other than what they said.

That said, if we "address" a requirement by stating in the Quality Manual that we do not do that work, isn't that the same as saying it under "permissible exclusions"? If not, what's the difference? If so, what's the beef?

Bottom line ... I have no question about the meaning of the Permissible Exclusions clause. It says that if a requirement in clause 7 is not applicable and does not affect the organization's ability to provide conforming product, then it does not have to be addressed further. It is excluded from the QMS.

Oh, by the way, I do have clients who have been successfully registered who do not do purchasing, others that do no packaging, others that do no inspections, and the list goes on. Each one has been registered without incident or question because of the nature of the organization's product, and/or customer requirements and/or applicable regulatory requirements. For real!

This should start a lively discussion...

Donald A. Arbuckle

*************************

From: ISO Standards Discussion
Date: Tue, 15 Aug 2000 09:39:08 -0500
Subject: Re: Permissible Exclusions /../Trudeau/Robinson

From: Ralph Robinson
>
> Pat Trudeau stated, "I have talked to a TAG team member personally
> about this and the only exclusions are servicing and design."
>

A recent discussion with our Manager, Regulatory and Quality Systems, and her subsequent enquiry of our ISO registrar has yielded quite a different scenario.

According to our Registrar, _all_ of Section 7 of ISO 9001:2000 is
subject to exclusion if your organization can show that those elements
do not exist. Based on this information I'd say that the following could
potentially be excluded in a ISO 9001:2000 registration:
1. Customer-Related Processes (highly unlikely as everyone has
customers)
2. Design and Development (definitely possible)
3. Purchasing (highly unlikely, but possible)
4. Production and Service Operations (VERY doubtful for production
operations, but possible for service operations)
5. Control of Measuring and Monitoring Devices (same as #4)

If you look at the possibilities realistically, then the person Pat Trudeau talked to might be, in fact, correct, even though the possibility to exclude something might actually exist.

I think one of the key elements that we all need before we can make educated assessments of how this new standard will impact our organizations is the final Transition Guideline document. Hopefully that will answer some of our questions. Failing that, I hope that ISO 9004:2000 provides some clarity.

Ralph E. Robinson

> From: rudy.salinger dowcorning.com
> Although ISO 9001:2000 would say "purchasing" cannot be excluded from the
> Quality System scope, it should be possible to address this requirement with
> minimal effort. The process which you would have to "establish, document,
> implement, and maintain" might be as simple as a statement in the top level
> documentation (Quality Manual) that "no materials or services that affect
> product quality are purchased. All other purchases are at the discretion of
> the employee requiring them." But you will have to be sure the exclusion of
> "services" as well as materials is valid, otherwise you will indeed have to
> put up a process.
> The justification for this approach is the statement in ISO 9001:2000 that
> "The type and extent of control shall be dependent upon the effect on
> subsequent realization processes and their output."
> This is my opinion, but it should be verified with the firm's registrar.
>

****************************

From: ISO Standards Discussion
Date: Tue, 15 Aug 2000 09:13:47 -0500
Subject: Re: Permissible Exclusions /../Arbuckle/Kozenko/Hankwitz

From: "Hankwitz, John"

David M. Kozenko makes a good point. But beware of over doing things. Does a procedure REALLY need to be written as a result of this incident? I would think normal day-to-day feedback would be adequate.

I heard that one company actually wrote procedures for making coffee, and posted them by each coffee maker. The logic was that visiting customers were provided coffee on occasion, and they wanted to make sure they wouldn't get a nonconforming mouthful. Good Grief!

Most often, a basic "New Employee Training" program will take care of most of these petty situations. Reserve procedure writing for those things that can't be effectively handled through training.

John Hankwitz

> David M. Kozenko writes:
> I'm not saying "do this or else" because it's not appropriate
> for every firm, but here's a case where the answer to your
> inquiry is "Yep, you need Purchasing Procedures in all cases..."
>
> I stayed late one evening (when my kids were young, no less
> ;o) to manually "baby-sit" the high-speed copy machine
> while we (as in, me and the machine ;o) ran 20 copies of a
> report due to the client, earlier that morning.
> (snip)

****************************

From: ISO Standards Discussion
Date: Tue, 15 Aug 2000 09:34:23 -0500
Subject: Re: Permissible Exclusions /../Arbuckle/Schoffman

From: ASchoffm

<< From: "Donald Arbuckle"
Let me see if I understand this... If my company does not purchase anything (all parts, equipment, facilities, etc. are provided by the customer) other than laser paper for office use, pens/pencils, etc, then in order to meet the requirements of the standard and become compliant/registered, I must still establish, document, implement and maintain a purchasing process?? Doesn't this conflict with the requirements in 4.1 a), "identify the processes needed for the quality management system"? >>

Don, I believe you have hit on the weakness of the Permissible Exclusions clause. I believe the real intent was to differentiate 9001:2000 from the 9002:1994 standard which permitted companies with design systems that affect quality to obtain certification to an ISO standard (9002) without including their design function.

As in the past, where a clause does not apply to a particular organization, they can exclude it by simply stating that it does not apply to them. The registration auditor determines whether this is valid. This is especially true in service organizations where calibration of test equipment, packaging and delivery, servicing, etc. will not apply.

It seems to me, therefore, that there should have been no permissible exclusion clause at all - just the general rule that if a functions affects the quality process, it must be included in the quality system. If not, as in your example, a simple statement to that effect would be sufficient.

Alan Schoffman

From: ISO 9000 Standards Discussion
Date: Tue, 31 Oct 2000 11:01:58 -0600
Subject: Re: Q: Permissible Exclusions ISO9000:2000 /Reid/Monnich/Trudeau

From: "Trudeau, Pat"

According to ISO/TC 176/SC 2/N 485 (if this version dated 26 April 2000 is still current) Section 3.3 Permissable Exclusions paragraph 3 states "The fact that a specific activity (such as Design and Development, or Purchasing) is outsourced, or carried out by a different entity, is not in itself adequate justification for the exclusion of that activity from the QMS. Overall responsibility for and/or coordination of that activity, may remain with the organization."

PAT

**************************************

From: ISO 9000 Standards Discussion
Date: Tue, 31 Oct 2000 11:06:31 -0600
Subject: Re: Q: Permissible Exclusions ISO9000:2000 /../Scalies/Deibler

From: Bill Deibler

If development groups are required to be a part of registration, a significant number of companies will refuse to comply.

For example, many high-tech company ISO registrations are for ISO 9002:1994. These companies have been resistant to pursuing ISO 9001, and have opted for other models for quality to support their engineering practices (for example, software engineering and the CMM).

There is a MUCH greater commitment when a company applies design control in an engineering department. This is quite demanding Charley. I have been doing ISO implementations in a variety of industries since 1989, and I have found 9001 in software and systems providers to be the most challenging. 900X has always made sense to manufacturing folks, but has required a lot of interpretation in other disciplines (software and 9000-3 for example).

I think this can of worms is a huge one. I can't imagine a registrar turning away business because some multinational, multibillion dollar firm carves design out of the scope of registration. I can't imagine that accreditation bodies or forums would be so foolish as to push this policy.

This is a debate that has only begun. There will be tremendous resistance in many companies that are 9002 registered and had no intention of pursuing 9001 (even though they have R&D and/or Engineering functions).

There are many, many, many companies in the Silicon Valley and US that have gone the 9002 route and DELIBERATELY avoided 9001. Do you think that the registrars/accreditation bodies will choose to hold a gun to the head of these guys? This is certainly the current position from the RAB....but I honestly don't think they realize what fight they are about to get into.

It truly will be interesting.......and I think the user community will have a few things to say to those issuing guidance on this subject. I can hear the ringing in my ears...

my 2 cents.

Bill

From: ISO 9000 Standards Discussion
Date: Wed, 1 Nov 2000 14:59:21 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/Trudeau/Paten

From: Mike Paten

I totally concur with Pat's comments on this issue:

>From: "Trudeau, Pat"
>
> According to ISO/TC 176/SC 2/N 485 (if this version dated 26
> April 2000 is still current) Section 3.3 Permissable Exclusions
> paragraph 3 states "The fact that a specific activity (such as
> Design and Development, or Purchasing) is outsourced, or carried
> out by a different entity, is not in itself adequate
> justification for the exclusion of that activity from the QMS.
> Overall responsibility for and/or coordination of that activity,
> may remain with the organization."

The key issue (to me) is the degree to which the function is "integrated" with your quality system. If the function you desire to "exclude" is inseparable - then you clearly have to include it. Factors that make it difficult to separate functions that are physically or organizationally "housed" together include:

1) the same process inputs (equipment, people, materials, processes) are shared by the function under review and the function you wish to exclude - how do you properly control and manage shared resources?

2) Critical "interfaces" associated with the excluded function are not documented because they are performed by the same person in the included function to whom the documents would go - does it make sense to document interfaces with yourself?

3) Responsibilities and authorities assigned to the excluded function are integral to operations of the included functions - in other words - how much control does the excluded function have over the included functions?

Usually when functions are "housed" together everything gets a little "fuzzy" because there is really only one system at work.; it is for this reason that ISO registrations are usually for an entire facility (versus one or more functions or product lines) - and auditors recognize that even with satellite facilities do the same work - the "system" in place at one facility is often quite different than the system at another facility (even if documented policy/procedures are identical, the degree of implementation and the level of management commitment may differ significantly).

For all these reasons, a company should look to include within the scope of their registration all functions performed at a particular facility. Besides - is it really that much harder to include design? I don't think so.

Mike Paten

From: ISO 9000 Standards Discussion
Date: Thu, 2 Nov 2000 16:00:38 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Deibler/Pfrang/Deibler

From: Bill Deibler

Doug,

RAB has been pressured by industry in the past, and by the same companies I'm talking about. There was an initiative to cut down on the number and breadth of ISO 900X registration assessments that was spearheaded by HP.

There are companies that see ISO registration as a burden and that believe that it doesn't add value. There have been companies that have gone on the record wishing that the registration scheme would disappear. Companies like HP and Motorola have been very outspoken in their criticism of registration schemes.

Do these companies believe in quality? Certainly they do.

Here's the issue, and it's very straightforward. Do companies want to expend funds for additional scope of registration. I believe that they'll see this as extortion on the part of the registration industry. This in turn reflects poorly on the standard. It shouldn't but it does.

Just because a company pursues 9002 versus 9001: 1994 doesn't mean that they're against quality and having a defined set of engineering practices. In many cases they see 9001 registration as burdensome overhead and they don't envision a return on investment. It's not the standard that's the problem as far as they're concerned...it's the lack of value in pursuing registration.

There is a Motorola way, and there is an HP way. Both companies have a number of R&D organizations that are best in class, IMHO.

Let me put another point forward that is ancient history, but relevant. RAB and ANSI put together a committee back in the early 1990s to define and develop a "US version of TickIT". The committee was called SQSR (software quality system registration). The idea was to have a US scheme as an alternative to the UK scheme. That way it would be open to US accredited registrars and would open up the market for the scheme. Unlike the UK scheme, this would not be a mandatory program. The idea was, if there was a market for this scheme, US companies would seek it out.

I was the editor for the SQSR guide, and was very involved in the proposed program. Interestingly enough, there was tremendous resistance in the US software industry to the idea of an alternative/additional program. The feeling was that this would end up being a great burden on the US software industry. Many many arguments were made (some were quite irrelevant and illogical, and some were thoughtful) in opposition to this proposed program.

The resistance to this program was spearheaded by HP. They lobbied hard against it and made their position clear to ANSI and RAB. After public forum to discuss the issues, the proposed program was shelved by ANSI.

So....things happen. Industry will react if and when they see something coming that they believe will cause them undue burden.

There are a lot of sleeping giants....if they choose to wake up, they can make a lot of noise.

now i'm at 4 cents.

deibs

From: ISO 9000 Standards Discussion
Date: Thu, 2 Nov 2000 16:08:36 -0600
Subject: Re: Q: Permissible Exclusions ISO9000:2000 /../Scalies/Deibler/Hartman

From: dhartman

Bill Deibler wrote,
> If development groups are required to be a part of
> registration, a significant number of companies will refuse to
> comply.

My experience is that if there is adamant refusal, then the requirements have probably been wrongly interpreted and/or presented.

I would question how any design function can continually be successful at creating designs that meet the customer's requirements without the following activities taking place:

1. Fulling understanding the customer's requirements;

2. Further defining those requirements into specific design requirements;

3. Documenting the design in some format (e.g. On paper; computer 2D; computer 3D; computer program, etc.)

4. Having even cursory (and perhaps impromtue) discussions within the design function and/or with other functions such as manufacturing, purchasing, suppliers, etc. related to the practicality of the design (at various stages);

5. Comparing the design capability to the customers requested requirements;

6. Verifying that the resultant product meets the customer's requirements (ISO doesn't state that this can't be performed by a function other than those responsible for the design activity);

7. Tracking changes to ensure that we understand why changes were made, to ensure that they were effective, and that changes aren't made on a whim (refer to the history of the original Henry Ford Motor Company), and that all of the appropriate personnel have the latest revisions available (i.e. manufacturing, support functions, customer, etc.).

Additionally, my experience is that there really is NO difference in the design functions between developing hardware or software. Afterall the software code must be assessed to verify if it is in the proper form (e.g. Fortran, C++, DOS, etc.), does it/will it perform the functions required, etc. In fact discussions related to the efficiency of the code (its complexity) typically take place (the customer may want, and is willing to pay for, a Yugo; not a Rolls-Royce with all the bells and whistles).

And if these activities are taking place, then compliance to ISO 9001 consists of documenting (in a simplistic, non-detailed, format such as flowcharts) those activities. Remember ISO 9001 allows you to determine the level of detail, based on the knowledge, experience and training necessary for those responsible for performing the tasks.

Compliance to ISO is NOT about writing War and Peace, nor is it rocket science.

KISS!

David Hartman

*********************************

From: ISO 9000 Standards Discussion
Date: Thu, 2 Nov 2000 16:14:23 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Deibler/Vianna

From: "Vianna, Sidney"

Bill, long time, no seeing. You might be correct that many organizations might refrain from adopting the ISO 9001 model, in it's entirety, if forced to. Time will tell. I hope that they would see the light.

The reality is that too many quality problems are originated or induced for weak design control processes. If organizations are serious about customer satisfaction and product quality, they have to control their design process. I personally do not see anything in subclause 7.3 of FDIS ISO 9001:2000 that would be so overwhelming for organizations to perform.

Unfortunately, many organizations have misconceptions that, if they structure their design process, they will be too slow or bureaucratic to develop a new concept into a commercial viable product. If this happens, is simply because of self inflicted archaic practices.

Time to market is a key aspect for high-tech organizations, very prevalent in Silicon Valley, like you mentioned and I am also very familiar with. However, compliance with ISO 9001 should not slow the design development process, unduly. I have personal experience with many high tech companies, as well, and would like to mention, for example, one prestigious computer manufacturer that I am familiar with. When I first started to assess that organization, a laptop computer life cycle (from market introduction to obsolence) was about 9 months. Now, it is probably down to 4-5 months. This means that they have to be continuously developing the next generation of their computers, and again, they have to bring it to market in a very abbreviated time. They have never complained about ISO 9001 slowing their development process. Actually, the opposite happened. When they started implementing gates, verification and validation points in their processes, they caught many potential problems that, if left in the design, could have meant tremendous losses, because of potential safety problems and huge recalls.

Traditionally, there is a lot of resistance to implementation of ISO 9001 in Engineering functions because they believe that their creativity will be stifled, their freedom will be taken away, etc . . .But these are the same folks that work under the concept that Design change requests (DCRs), Engineering Change orders (ECOs) and similar tools should be used to fix the bugs of underdeveloped design packages. Many organizations operate under this illusion that it is "part of doing business" for design packages to be released for manufacturing, with known bugs in it, and it is natural that Engineering will fix them through these ECOs and DCR's. Let me tell you this:

ECO's and DCR's should only be used (in a perfect world) to enhance the design package, not to fix it. Unfortunately, again, many organizations do not realize the costs and consequences to allow a weak design development process to generate flawed design packages being released for manufacturing. Too bad.

Your comment about your doubts if Registrars and Accreditation Agencies will really crack down on this loophole. That will definitely be interesting to see. If the Accreditors (RAB, RvA, UKAS, etc . . .)do not take a really firm stance on this, I do not see how this aspect will be enforced.

I have been following this thread, and like many other people have pointed out, ISO is working on a document (ISO/TC 176/SC 2/N254) that will assist on the application and exclusion determination. Let's remember, though, that, for the time being, this document is not being evoked by the Accreditors. Let's wait and see how the guidance contained in that document make it's way in the third-party management certification business.

Best Regards

Sidney Vianna

*************************

From: ISO 9000 Standards Discussion
Date: Thu, 2 Nov 2000 16:16:05 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Scalies/Andrews/Scalies

From: "Charley Scalies"

> Charley,
> What if the certified firm has NO control over what the outputs
> of the design facility are? What if the design facility is
> operated as a separate organization - not just physically but
> organizationally as well? What is the case with your
> example?

That is almost precisely the case here. The design facility is the "parent" if you will, though there really is only one corporate entity/profit center. The design arm has little or no sales of its own. I was initially surprised that their registrar would have ever allowed them to limit the scope of their registration under such circumstances but they did.

Charley

Continued from the Permissible Exclusions (http://Elsmar.com/ubb/Forum15/HTML/000076.html) thread.
*************************

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:52:14 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Gleason

From: Carla Gleason tycoelectronics.com

Bob George wrote:

> Plans are to move our Field Service group, R&D or Design group
> to a temporary location in the interim. This could be as many
> as thirty or as few as six. ... Is there some flexibility in a
> registrars judgement regarding a location separation like this,
> or will our company be summarily required to seek an additional
> certification for this temporary office site?

When I worked for a registrar, our policy was that the scope of registration could be written around any clearly definable business group or function. It could be a corporate support function (e.g. an international corporate purchasing group for purchasing services), an entire large or small business, or a large multi-site corporate division. The key requirements were the ability to clearly define a scope of registration around the functions performed as desired by the client, not the addresses. The same has been true for the registrar for my current employer. We had included a leased warehouse site 13 miles down the road (our "13 mile aisle") for several years until a newer warehouse was built across the street. The warehouse move was invisible in our scope of registration, as the business address was always the main site. Only the registrar's internal documents had to be changed. Your relocation should be similar. Depending on how your scope was written, you may have to revise that, but the same certificate should do.

Carla Gleason

****************************

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:52:36 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Andrews /Scalies/Andrews

From: eandrews usffiltration.com

Charley wrote (in part);
> I was initially surprised that their registrar would have
> ever allowed them to limit the scope of their registration
> under such circumstances but they did.

Charley,
I have seen numerous examples of companies that performed design but elected to keep it outside the scope of their registration. Back in 1994 when I questioned this with one of my clients, we ended up contacting a major registrar (who shall remain nameless...suffice it to say that they were located across the 'big pond'). We talked to the individual that headed up their registration services at the time. He explicitly stated that the 4.4 requirement only applied to companies that sold design as a separate product (i.e. architectural firms). I did not see the logic with his statement and did not agree; however, that was the "out" that the client was looking for to exclude the design requirements.

Fortunately, after MUCH persuasion, I was able to convince the client to go for the 9001.

I never have understood why organizations that do design would wish to omit the function from their quality management systems. After all the old saying...stuff in stuff out is painfully true.

Ethan Andrews

***********************

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:52:52 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Pfrang/Deibler/Eugenia

From: Eugenia_Dolan.YEA yaskawa.com

Another perspective-

Motorola being against ISO 9k is ancient history (6 or 7 years old). Motorola was very supportive of the rewrite and sat on the TC 176 and Z1 committees and participated in the ISO 9k 2000 rewrite. In fact the VP of Corp Quality at Motorola was an active member (about 4 years ago). In addition Motorola corporate QA members on the VP's staff were also members. I am not sure about recent history as to whether they are still active members.

Regards,
Dolan

***********************

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:54:08 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Kozenko

From: Write9000

> Plans are

Those are the two most important words in your question. I'd like to believe that any Registrar worth its "salt" would accept the move you described, provided you can evidence "quality planning" as part of the overall plan. If your certification is based on "processes" and not on "location" then you need to plan and control those processes when you do whatever moving is required.

Your job in executing the quality planning for the move is to see to it that the existing certification stretches like silly putty but still covers the processes.

I'm also an avid fan of the "single certificate" approach (versus multiple certificates), just so you know.

David M. Kozenko

More thoughts:
****************

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:55:22 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Hankwitz

From: "Hankwitz, John"

Bob,

Your quality system has been registered to ISO 9001. It doesn't mention departments, job functions, or brick and mortar. There should be no effect on your registration.

However, make sure you have put together a quality plan for your expansion. How will you make sure your customers will continue receiving good product while you are in transition?

John Hankwitz

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:55:30 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Andrews

From: eandrews usffiltration.com

Bob,
Will the relocated group(s) still have access to the present QMS documentation (procedures, work instructions, etc.)? If they will then I don't see any problem with them being contained under the present QMS system "umbrella". Your registrar may wish to list the off-site addresses separately in their audit reports (for clarity), but I don't think that separate registrations are necessary.

Ethan Andrews

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:55:38 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Paten

From: Mike Paten

George,

It's completely up to your registrar - the fine print in your contract with your registrar requires you to advise them when significant changes to your system occur. Whether (or not) you will need to be "recertified" will be determined by the impact of the reorganization on your quality system - if your system changes significantly - you will need a complete system audit.

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:55:59 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Scalies

From: "Charley Scalies"

The system in place at the location, not the location, is the governing factor. Assuming your system remains essentially unaffected, then you may/should be facing nothing more than an amendment the scope of your current certificate and not a new certificate. Undoubtedly your registrar will want to visit and audit the activities at the new locations.

Charley Scalies

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:56:22 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Summerfield

From: George Summerfield

Hi Bob:

This is only my opinion, but... if your people are going to perform the same duties (and processes and procedures) that they did before the move, but in the new location(s) - no problem. Just make sure that you fill the new gaps with procedures for communication and co-ordination with the satellite offices, and notify your consultant and registrar about the move(s). How can any business-minded body have a problem with growth?

George

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:56:11 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Monnich/George/Monnich

From: "Herbert C. Monnich, Jr."

Ask your registrar. There are a large number of variables. Is the temporary area next door, 2 blocks away, 200 miles away or in another area of the country. Your QMS needs to address any problems that you might anticipate, if any. Your registrar only needs to make sure that your QMS is being followed.

Herbert Monnich

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:56:53 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /Peracchio/Hartman

From: dhartman phdinc.com

Darlene, I believe that you've answered your own question in that you stated that
> In general, we are... developing a product to match a
> competitor's.

The key word in your quote is "developing". ISO/DIS 9001:2000 (sorry I don't have the FDIS yet) section 7.3 is titled "Design and/or Development", and I believe that you'll find that the controls defined are applicable to "developing a product to match a competitor's".

Regarding handling reluctant organizations: I recommend approaching the organization by recognizing the positive attributes of what they are doing, commending them for the informal processes/methods that they have in-place, and educating them on the benefits of documenting those processes in manner that is not too specific to impact their "creativity", but yet could benefit someone "new" to the organization. I would recommend the use of flowcharts, videos, (be creative, for processes do NOT have to be verbiage). In-fact our company HAD so much verbiage at one time that virtually none of it was being used (it was too confusing, and in a fast-paced production environment no one has the TIME to spend reading text).

Remember: You attracted more flies with honey, than with
vinegar.

David Hartman

**********

From: ISO 9000 Standards Discussion
Date: Fri, 3 Nov 2000 12:57:05 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /Peracchio/Summerfield

From: George Summerfield

Hi Darlene:

First, let me start by saying that you cannot and should not try to exclude Design Control; especially when you clearly have a R&D department and perform the function. As for the problem you are having - try the approach that I used last year...

We have the largest R&D department I've ever seen; especially since this is a scientific R&D facility. Having said that, I have found that if what you are trying to do is standardize processes so that they are repeatable, conduct business to make money, or do anything else that a scientist considers "nos" (noise as opposed to signal) to their particular study/project - then all that you are doing is wasting their valuable time. They only panic and look for the business-minded people when funding starts to disappear from their project before they have found a solution. I had a wonderful time just trying to get scientists to listen to me when I was trying to sell them on the benefits of process management; but finally I figured out an angle. Whether or not you agree with what I say here is irrelevant; the point is that it worked ;-)

I managed to get an assembly of scientists and engineers at the facility together and speak to them about how the Business environment - after many decades of doing things wrong - turned around and took a lesson from Science, in order to make business work properly. After all, the fathers of quality were scientists - Dr Deming and Dr Juran were scientists in their own right. Anyway, I drew a line down the center of a board and compared "Scientific Research" to "Business Process". Here's how they equate:

Business / Scientific

Control Input = Control Test Subjects: if you don't control the subject of your study then your entire research is invalid. Control Process = Control Research Process: do this with documented procedures; because if you cannot show that the research is repeatable then it will not stand up to scrutiny in the scientific community when you publish your paper. Calibration of Test Equipment = Validation of their research data. They'll especially like this! Control Output = Controls required on your newly developed substance for storage, handling, etc, etc. Customer Service = Their concern for who will use the result of their research, how, and why.

Its very easy to draw the appropriate lines for the scientists and engineers to see where the elements of ISO9000 are based upon what is already being done in the R&D environment. Unfortunately, the scientist will say that this is what they are doing all of the time anyway. Response: "Yes sir/ma'am; and now we just want to write it down so that new personnel coming in will be able to work-in smoothly and follow your existing processes without incurring too much error into your already stable processes. This records keeping stuff will also make it much easier for you to access any proof that you require for your studies later."

In preparation for this, have an internal letter of agreement handy for them to sign to close the deal after the presentation. This is required because scientists quickly forget what they agreed to, very soon after delving back into their project/study. Thereafter, you have the signed agreement to waive, when necessary, as you deal with their subordinates to work the plan. IMHO - DO NOT go back to bother the head scientist unless you really, REALLY have to. Just let the improvement in the way that things work sink in through the process of osmosis for them. Ask them how things are working out over coffee; that sort of thing.

Best of luck...

George

At http://Elsmar.com/pdf_files/ - Look for Permissible_Exclusions.txt

From: ISO 9000 Standards Discussion
Date: Mon, 13 Nov 2000 12:25:17 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /Reid/Scalies/Marr

From: Jeremy Marr morcan.com

> . . . . Their registrar is now saying that with the
> introduction of the new standard, they "must" include design
> control. Certainly, their registrar can refuse to recertify
> them unless they include design control. But will all
> registrars be so demanding? I am somewhat interested to see
> where this will all end up. . . .
>
> Charley Scalies

ISO have clarified what they consider to be permissible exclusions in a document entitled (Draft) Guidance on ISO 9001:2000 clause 1.2 "Application". This can be found on the ISO web page (through the red banner marked ISO 9000 Revisions - Updated transition guidance- and under New Supporting Documents).

In that document they provide examples of what they regard as permissible. One of the examples relates to an organization who chose 9002 even though they designed product. In the example, the registrar was one of the not so demanding ones and did not require them to include the design process - but the organization chose to include it anyway "because it does in fact carry out this activity and the activity does affect its ability to meet customer requirements. Also, it wants to be able to claim conformity with ISO 9001:2000, and the exclusion of the design and development activity would not allow it to do so. "

So who is going to police that one?

Jeremy Marr

From: ISO 9000 Standards Discussion
Date: Mon, 20 Nov 2000 13:36:30 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 .../Scalies/Russell/Deibler

From: Bill Deibler

> From: "J.P. Russell"
>
> FYI
> In an attempt to limit confusion, the word SCOPE is used to
> identify the location, facility, product and services under
> the Quality Management System. An organization cannot exclude
> clauses of ISO 9001:2000 by a scope statement. It was never
> intended that organizations could decide to exclude, for
> example, design as part of a scope statement. The word
> APPLICATION is used when discussing the tailoring or
> identification of clauses that will be excluded from the
> organizations Quality Management System. The starting point
> for registering to ISO 9001:2000 is that all clauses apply
> unless the organization has provided sufficient justification
> to their registrar organization.
>
>JP Russell

List Members,

In another attempt to limit the confusion, I passed along JPR's response to my business partner, Bob Bamford, and he felt it worthwhile to weigh in. His response follows:

BACKGROUND
----------
ISO/FDIS 9001 Clause 1 is titled "SCOPE". Clause 1.1 is titled "General". Clause 1.2 is titled "APPLICATION".

"Scope" is short hand for "scope of application" so (once again) ISO shoots itself in the foot by tossing terms around.

Clause 1 contains legitimate scope information in both paragraphs 1.1 and 1.2. In the last two paragraphs, 1.2 also defines the requirements for claiming conformity with the standard. This arguably has nothing to do with scope of application of the standard, but the information it contains is necessary because of the elimination of 9002 and 9003.

Clause 4.2.2 states that the quality manual includes "the scope of the quality system, including details of and justification for any exclusions (see 1.2)".

In addition, the registration process refers to the scope of the registration and the scope statement on the registration certificate. The registrar requires that the scope statement unambiguously communicate to any potential customer what was assessed (e.g., processes, products, services, locations) and found to be operating in compliance with the requirements of ISO 9001, ISO 9002, or ISO 9003.

THE PROBLEM
-----------
It appears that JPR is mixing paragraphs 1.2 and 4.2.2 in ISO 9001 and an element of the registration process.

The SCOPE statement in the quality manual will (as required by clause 1.2) define the exclusions. This would, presumably, be carried forward onto the registration certificate - if the organization chooses to become registered, which is not required to claim conformity with the standard.

If the organization chooses to seek registration, the scope statement will define the scope of the assessment and, by omission, those functions and requirements which have been excluded.

In light of these statements in ISO 9001, I'm not sure what JPR means by "exclude clauses of ISO 9001:2000 BY a scope statement".

THE LARGER PROBLEM
------------------
I suspect the heart of the "confusion" is related to the currently unanswered question of whether ISO intends to continue to allow Design to be omitted in organizations that have both design and manufacturing (e.g., equivalent to ISO 9002).

Whilst some are taking the ivory tower, philosophically-justified position that such an exclusion violates the integrity of the standard, the reality is that, in many cases, once a product is established and proven, customers care most about the manufacturing process. There are exceptions, like software product, for which manufacture and engineering cannot be considered as separate, significant processes as they relate to product quality.

One constraint imposed on the revision was to make the transition "easy" and "not require the rewriting of an organization's quality system documentation" [see ISO/TC176/SC 2/N 415, Section 1.5]. It appears that requiring organizations to add the design function if they have it, does not seem to be a defensible or intended position. It will make organizations think twice about registration.

Imposing the "all-or-nothing" requirement would raise two significant obstacles to the use of the standard. First, it would move ISO 9001 out of alignment with the regulated products directives of the European Union, which currently accept ISO 9002. If ISO decides to go the all-or-nothing route, I wonder if registrars will offer an alternative service verifying compliance with enough of ISO 9001 to satisfy the directives, even if the subset is not enough to satisfy elevated requirements for claiming conformance to the standards.

Secondly, the "all-or-nothing" interpretation prevents phased implementations, in which a progressive organization achieves compliance - and registration - as a pilot, pioneer, or prototype for a larger organization. The pioneer might be hardware engineering in an organization that includes software engineering, manufacturing in an organization that includes engineering, or telephone customer support in an organization that includes engineering and manufacturing.

Resolving the "scope" problem requires that ISO define "organization" in the context of exclusion.

Fortunately, the transition rules of the International Accreditation Forum (IAF) provide three years for registrars and industry to sort this out. Unfortunately, it has to be sorted out.

best,
Bill

************************

From: ISO 9000 Standards Discussion <jennejohnn@uwstout.edu>
Date: Mon, 20 Nov 2000 13:39:04 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Reid/Pfrang /Goetzinger

From: Tom Goetzinger <gotoms@yahoo.com>

Doug Pfang said, in part:
>"The answer is, "because that isn't what the company has chosen
> to do, it isn't what the company is willing to pay for, and it
> isn't the registrar's right to dictate the scope of the
> company's registration."
>
> Consider:
> What if the company had centralized manufacturing at
> one location, but had distributed design work at ten
> different locations (maybe even in different
> countries). Do you think the registrar should have
> the right to refuse to registrar the one manufacturing
> location unless the company agrees to pay the
> registrar to certify all eleven locations? I sure
> don't."

Guess we disagreee on that. As in any Buyer - Seller relationship, with appropriate notice, either party can choose not to continue the relationship. I think that might be a shortcoming of the 2000 version; at least with the 1994 version, it was obvious if your design function was certified or not. Suspect there will be all kinds of shanigans to try to convince registrars that they don't need to control the design function but they should be ISO 9001 certified. Hopefully, it won't be allowed.

Tom Goetzinger

Hi,

My company is a shared service centre. We only process transactions. Therefore we do not purchase anything for our processing. All information is provided by customers.

We only purchase desktops and laptops, stationery etc for our analysts. Will this make us included purchasing clause.