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

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#11
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
 
Elsmar Forum Sponsor

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#12
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
 

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#13
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
 

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#14
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
 

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#15
Permissible Exclusions II (Son Of...)

Continued from the Permissible Exclusions 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
 

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#16
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
 

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#18
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
 

Marc

Hunkered Down for the Duration with a Mask on...
Staff member
Admin
#19
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 <[email protected]>
Date: Mon, 20 Nov 2000 13:39:04 -0600
Subject: Re: Permissible Exclusions ISO9000:2000 /../Reid/Pfrang /Goetzinger

From: Tom Goetzinger <[email protected]>

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
 
A

Amber Usman

#20
purchasing clause exclusion

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.
 
Thread starter Similar threads Forum Replies Date
N Permissible Exclusions for QM ISO9001:2008 Audit and Consultancy Services Company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
C Permissible ISO 9001 Exclusions/Omissions for the Service Industry ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
R ISO 9001:2008 Permissible Exclusions ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 36
A Permissible exclusions in ISO 9001:2008? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
K Permissible Exclusions - ISO 9001 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 158
D Permissible Exclusions - How is 6.2.2.1 Product design skills being handled Design and Development of Products and Processes 24
J Subcontracted Services - Permissible Exclusions Service Industry Specific Topics 9
Marc Definition MPEE - Maximum Permissible Error for Length Measurement Definitions, Acronyms, Abbreviations and Interpretations Listed Alphabetically 0
M What is the maximum permissible period of delaying the validation of equipment? Other Medical Device Regulations World-Wide 4
Y No permissible error statement on the thermometer calibration report General Measurement Device and Calibration Topics 7
B Permissible Exclusion for Clause 7.5.2 in a Real Estate Company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
J IEC60825 - Laser Safety - Calculating Maximum Permissible Exposure Correctly Other ISO and International Standards and European Regulations 1
D What is the difference between Tolerance and Permissible Error General Measurement Device and Calibration Topics 5
T Are Form Taps permissible to use? Manufacturing and Related Processes 3
D How to compute the Permissible Errors for Class 2 Weighing Scale General Measurement Device and Calibration Topics 2
S How to define Permissible Error for Measurement and Test Equipment? Measurement Uncertainty (MU) 3
M Permissible Authorities of CB (Certification Body) Auditors General Auditing Discussions 3
J Blueprint Note: Rectangular Distribution is Permissible - Concentricity of Two Holes Capability, Accuracy and Stability - Processes, Machines, etc. 5
N ASME B89.1.13 question regarding Resolution and Maximum Permissible Error General Measurement Device and Calibration Topics 3
P Design & Development in Food and Beverage Services - Permissible exclusion or not? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 13
S Is this exclusion Permissible by the standard - Company Divisional Differences ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
M Maximum Permissible Error for Monitoring and Measurement Devices General Measurement Device and Calibration Topics 19
S EN AS 9100 Permissible Exclusion and Provision - Aerospace design and development Design and Development of Products and Processes 4
J Is it permissible to use data from calibrations as part of a gage R&R? Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 2
Q ISO 9001 - Reseller Exclusions ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
F AS9120B - Exclusions AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
B Exclusions or justification for non-applicability of IEC standards Reliability Analysis - Predictions, Testing and Standards 1
B ISO 13485 exemption and/or exclusions ISO 13485:2016 - Medical Device Quality Management Systems 5
M Eligibility for certification to IATF 16949 - Exclusions IATF 16949 - Automotive Quality Systems Standard 1
C ISO13485 exclusions for design and automation company ISO 13485:2016 - Medical Device Quality Management Systems 2
K ISO 9001 2015 Exclusions - Product Design is purchased. ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
M AS9100D - Updating Scope Exclusions AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 9
R Exclusions to ISO 9001:2015 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C TS 16949 Exclusions outside of clause 7.3 IATF 16949 - Automotive Quality Systems Standard 6
M Exclusions clause 7.3 - Our organization doesn?t design products - ISO/TS 16949 IATF 16949 - Automotive Quality Systems Standard 6
I AS9100 - What QMS Exclusions are allowed? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 9
S How to document "Exclusions" in the Quality Manual AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 26
M TS16949 Exclusions - Design & Development is carried out by our parent company IATF 16949 - Automotive Quality Systems Standard 14
B TS16949 - 7.3 Design and Development Exclusions for a Service Company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
x-files [Exclusions] 7.3 Design and development vs. Thermal Powerplant ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
A Quality Manual Statements - ISO 9001:2008 Design and Development Exclusions Design and Development of Products and Processes 6
A ISO 9001 Certificate with EXCLUSIONS Statement Design and Development of Products and Processes 7
T Need Exclusions to be shown in ISO 9001 Certificate ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 8
J ISO13485 Clause exclusions for a Medical Software Company ISO 13485:2016 - Medical Device Quality Management Systems 9
A ISO 13485 Section 7.3 Design & Development Exclusions ISO 13485:2016 - Medical Device Quality Management Systems 7
S ISO 9001 Clause 7 Exclusions and Justifications for a Business ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 16
L ISO 9001 Registration of 1 Plant in a Company - Exclusions ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
B Question about Design Exclusions - Clause 7.3 of ISO 9001 ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 10
D Quality System Manual - Exclusions from ISO 13485 Clause 7.5 ISO 13485:2016 - Medical Device Quality Management Systems 4
W ISO 9001:2008 Clause 7.3 Design and Development Exclusions Question ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5

Similar threads

Top Bottom