Typically in service operations design is not addressed. However, IMHO many service organizations do, in fact, design their services. Hospitals are, I believe, an example, where treatment and reaction plans are 'designed'.

A hypothetical company sells extended warranties. Contracts come from stores such as Walmart which sell appliances and such. The company selling the extended service contracts does not actually do any service - actual repair/replacement is contracted out. As I interpret their business system, they design the extended warranty (service) contracts they sell.

How would you address the design issue in a company such as this?

A quick answer:

Design of a Service is the development process where a customer's needs are translated into a proposal, quote, tender, contract or contract change proposal to fully meet the customer's requirement. The design specification include as a minimum the requirement for:
a. a structure for management/supervision;
b. a structure for quality;
c. a structure for performance of tasks to deliver a defined "service";
d. the provision for customer feedback, quality control and assurance;
e. the identification of needed human and material resources, and
f. the costing of those resources

I'll send you a cleansed example procedure for design in the Service sector.

Cheers.

------------------

From: ISO Standards Discussion
Date: Mon, 28 Feb 2000 12:32:35 -0600
Subject: Re: Q: Design: Widgit vs. Service /Smith/Humphries

From: Edwin Humphries

Marc,

In the same way that service organisations design their services, manufacturing operations design their processes, and project organisations design the project plans.

By the logic you're suggesting, we should apply design control to process and project design.

As a service provider myself, I find the (regrettably frequent) suggestion (often by certifiers/registrars) that organisations like me should use design control in development of services rather ludicrous. It's relatively hard (although possible) to apply it to chemical products, but at least there's a real product development process in place there. Not so for a service.

Best Regards
Edwin Humphries

I understand where Mr.Humphries is coming from, but I think that, as ISO implementers, service providers will have to really think through how design control applies to them. I don't mean to dream up something, but I think the challenge is to look at the service provided and think about how that service "came to be". The methodology for the "came to be" could be design control. I agree with Barb that this will be a very interesting element for service providers to implement.

One area which is a hot potato in Australia at present is the 'Aged Care Industry' accreditation. Perhaps it is possible to design the service provided in these institutions on a 'case by case' basis or even generically.

From: ISO Standards Discussion
Date: Fri, 3 Mar 2000 15:07:09 -0600
Subject: Re: Design: Widgit vs. Service /../Humphries/Naish/Scalies

From: Charley Scalies

> From: PNaish
SNIP
> As a service provider we do have design. We have some standard off the
> shelf designs that is standard training packages...
> Then we have custom services which are determined with our clients as to
> what they want and a time frame. We have found it very beneficial to
> maintain this system so that both we and are clients are happy when the
> project is over.

If the "new ISO9000" has any benefits at all, I think one might be that it could help people look at the intent of the requirements and not just at the words, thereby allowing them to take and use what benefits their particular application.

I repeatedly stress to my customers (almost to the point where some of them threaten to toss me out if they hear it again) that if they are unable to tell me what the purpose of every requirement is, in terms of what is it expected to accomplish, i.e., what "good" is it?, then they really don't understand the requirement. BTW, applying that same concept to every procedure you write can be a superb and relatively painless way to identify and establish the functional objectives the new ISO9000 talks about. "Why am I doing this?" How will I know (measure) if it worked or not?"

What you have seen from some of the comments on this topic is the "baggage" we all have - our paradigms. They continue to get in our way. The best I have ever been able to do is to be aware of the ones I have and then smack my own hand, hard, whenever I catch myself being warped by them.

Charley Scalies

From: ISO Standards Discussion
Date: Fri, 3 Mar 2000 15:14:54 -0600
Subject: Re: Design: Widgit vs. Service /../Humphries/Naish/Hitchcock

From: Al Hitchcock

I have employed ISO-9001 4.4 in numerous organizations both in retail and service environments using the design and development model that the standard provides. This is where you make your home run. One thing that always bugged me was companies that do design development work, either tangible or intangible product design and somehow think that they are excluded from the standard. They exclude 4.4 from their quality system. Junk in - junk out. If you design it. Control it. ISO is very simply put as communications within an organization. Why wouldn't you want your designers/engineers talking to your suppliers/ customers/ manufacturers/ and installers/servicing dept as part of a formal process and include them in design reviews. This stuff is fundamental and makes business sense whether your designing services for clients or hardware. 4.4 is the ISO home run in my opinion and I've seen it do wonderful things improving product/service quality. If you do this... do that 4.4.

My humble opinion and experience.

From: ISO Standards Discussion
Date: Mon, 6 Mar 2000 08:45:09 -0600
Subject: Re: Design: Widgit vs. Service /../Naish/Hitchcock/Kozenko

> 4.4 is the ISO home run in my opinion and I've seen it do wonderful
> things improving product/service quality.

Applause to Al for this statement (and, for those of you who don't know the game of baseball, a "home run" is a good thing <g> ).

I was involved with an engineering outfit that performed every one of the 4.4 requirements, whenever it responded to a publicly issued Request for Proposal. In effect, that firm's Proposal was a custom designed service package. Because of "old school" thinking regarding 4.4 applying only to manufactured products, only ohhhh, one out of ten people at that firm could follow my thinking. So I'm pleased to see this list come up with so many favorable applications for the 4.4 requirements, especially as it pertains to professional services as the "product."

David Kozenko

From: ISO Standards Discussion
Date: Fri, 10 Mar 2000 10:33:16 -0600
Subject: Re: Design: Widgit vs. Service /../Naish/Humphries/Naish

From: PNaish

Edwin,

Sorry if you took the response personally. I had originally thought of putting some examples from past experience but remembered the email about keeping it short. But I will risk that for examples at this time. I had a client who did work for a company who sold to one of the big three. They were being pushed to go QS. The irony was the big three company would not give them the criteria for critical dimensions nor the expected Cpk they were to measure. And it was not the middle company that was the problem because one of their engineers had left the middle company and gone to my client. In addition neither the middle company nor the big three company would provide workmanship criteria and yet they would not accept the criteria that was an industry accepted standard for that industry (plastics injection molding). They would arbitrarily decide they did not like the looks of it. We finally had to sit down and start having meetings to get the criteria established and then both agree to use it.

Another more current example is a client in Texas (cable assembly). They have QS clients also. They are currently experiencing the same problems with a company that sells to two of the big three. They do not get acceptance criteria in advance. So they have started monthly and in the early implementation stages weekly "design criteria" meeting with the customers to get what they need.

Too bad these companies can not rely on their QS9001 customers to do what they are asking of the supplier!!!!

Phyllis

From: ISO Standards Discussion
Date: Mon, 20 Mar 2000 08:08:24 -0600
Subject: Re: Q: Design: Widgit vs. Service /../Humphries/Naish/Humphries

From: Edwin Humphries

Phyllis

> From: PNaish
>
> I find it interesting that some people can see how the standard pertains to
> others but never to themselves. A shortsidedness that seems to prevail in
> some mind sets that force quality systems on their suppliers but can't
> manage them for their own business.

While sometimes I may disagree with you, I don't think I've ever been condescending. Let me assure you, my shortsidedness is entirely physical, and I have forced quality on nobody. Ever.

I have, in fact, struggled on behalf of my clients to make quality relevant, effective and simple, without being simplistic.

> As a service provider we do have design. We have some standard off the
> shelf designs that is standard training packages that we consistently
> review at least once a quarter to determine if they can be improved using
> feedback from our clients.

As a (hypothetical) manufacturer, I may also have a process, and this process must be designed. I do not, however, choose to gain ISO certification for the design of my process. I also have (regardless of my industry) a management system, which also must be designed; however, I do not choose to become certified to develop my own management system.

It is therefore not simply having a design component in what I do that determines whether I have ISO9001 or 9002 certification. Let's look at what ISO says about the applicability of 9001:

* "ISO9001-1994 should be selected and used when the need is to demonstrate the supplier's capability to control the processes for design as well as production of conforming product. ... ISO9001-1994: for use when conformance to specified requirements is to be assured by the supplier during design, development, production, installation, and servicing." (ISO9000.1)

* This International Standard specifies quality-system requirements for use where a supplier's capability to design and supply conforming product needs to be demonstrated. (ISO9001)

There are two issues clearly identified:

1. Is there a product? Products are defines as "commodities offered for sale; the amount of an artifact that has been produced by someone or some process." I don't consider what I, personally, offer as either a commodity or an artifact.

2. More importantly, is there is a need to demonstrate control over the design process? For most service companies, the clear answer is a resounding NO. The agonising is almost invariably internal to the organisation itself, and few clients are concerned. In fact, I would suggest that most clients, whether having a repair done on their car or seeking someone's assistance with a business plan, would consider there to be any design in the activity at all.

> Then we have custom services which are determined with our clients as to
> what they want and a time frame.
>
> We have found it very beneficial to maintain this system so that both we
> and are clients are happy when the project is over.

I'm happy for you, but are you sure you do all of the following:

* Design and development planning?
* Organizational and technical interfaces?
* Design input?
* Design output?
* Design review?
* Design verification?
* Design validation?
* Design changes?

Personally, I doubt it.

For most service companies, interpretation of ISO 9000 is quite a challenge, as it wasn't written with them in mind. Most of the people I hear suggesting that Design Control has strong relevance to a service industry are either consultants or certifiers/registrars. That would seem more than a little self serving.

Let's not make things even more difficult for service companies than they already are, by forcing most of them as a square peg into the round hole of Design Control.

Best Regards
Edwin Humphries

From: ISO Standards Discussion
Date: Tue, 21 Mar 2000 07:50:15 -0600
Subject: Re: Design: Widgit vs. Service /../Naish/Humphries/Naish

From: PNaish

Edwin,

As a matter of fact we do! first let me say there are only 3 people currently in our company but we have had others at remote location on staff that were involved. We now only subcontract to them rather than maintain staff. That said:

* Design and development planning?
I do most of the initial development of what I think we need to do for a new software product to meet our customer's needs based on my discussion with them. The same holds true for training programs and implementation. I usually do it in a note pad that is then placed in a file during the development stage. For our contracts I generate a formal contract with what can be expected and what the deliverables are from both sides and a time line. Most clients want this to justify their budgets anyway. I have found it helpful when a management rep leaves and the new one doesn't have the same understanding of the process or like recently happened the Management rep got a new boss and he needed the contract with the plan to let his new boss know what to expect when.

* Organizational and technical interfaces?
This is easy with us being so small. From the start of a project a project leader is assigned to the company. That person is responsible for all communications with the company and all messages are directed to that person.

For new software that will be used for more than one client we have one of the 2 programmers (not I) assigned to the project and he does all the tracking of feedback. They have a software program they use to collect data for the next revision. Which also takes me to the next step.

* Design input?
For the software we listen to the client for the most part and I use my previous years of experience at companies like Intel for what management has asked for in addition to what I collected so I could make educated decisions on our suppliers and processes.

* Design output?
For training and implementation the output is defined in the contract up front. For the software the output is defined by the wants and needs of the clients and our own input. For standard training programs like internal auditor we review the training manuals after each class against the feedback sheet we have the class fill out regarding the materials used. We also take into consideration changes in interpretations and make sure the class is upgraded as needed. We also include standard changes such as the 2000 change which we are in the planning and evaluation stage of right now. We will not start until the official release as 1994 changed a couple of key items from the last drafts.

* Design review?
Periodically on the software I review what the status is. As a new report is generated from the software I am given the report and see if it will meet the input as I understand it from the client and as I have asked. I may mark it up or may agree with it. The programmers keep a binder with all my input on the reports. (I think it is a CYA as much as anything that I have approved something in case I forget later). For implementation projects I review status with clients at least once a month sometimes more during the early documentation stages. I keep an excel spread sheet which gives a score for each of the stages against each of the deliverables. When we get to 100% we know we are ready for an audit. The clients love it because they can track their progress in a % of completion.

* Design verification?
This is easy on the software. They let me try to break it and use it. I make notes or they watch and make notes which go into the note book for changes they need to make to meet our original criteria plus any that were added along the line. We occasionally ask the client what they think of this or that or what or how they want to see something so that it is added to the final verification stage.

The implementation verification is also done but is not so obvious. We do an independent pre assessment audit. That is the person who did the implementation gets another staff person or a subcontractor to do the preassessment. We also call this our final inspection.

* Design validation?
For the software we beta test with at least 2 of the clients who are asking for the software or the software changes. We prefer to have more and are always open to anyone who wants to beta test. The validation of the implementation is whether or no the company passes their audit. Not exactly our validation but we consider it valid. We check to see if any of the non conformances are repeats of previous ones from other companies and try to implement changes so the next client does not have the same problem. However, we can not keep company employees from making or using uncontrolled copies of documents no matter how hard we try and how hard we emphasize it. That is the only one we still get from time to time that is a consistent repeat.

Design changes?
If we need to make a change we always contact the client and see what they want to do. Even with schedule changes we work through email and faxes to document what is changing. This works from them to us as well. We may enhance a software program but we still contact them to see if it is a problem during the design phases. Many of our upgrades have come from clients who want to make this change or have that report. We store the upgrades until we feel there is enough or until one client feels they can't live without the change and then we make the change. They usually are one of our validation sites plus we have a few select other that we pick on.

Is our system unnecessary? Maybe. Does it work for us? You bet. Do we do it because of ISO? No because we are not registered. We do it because it makes good business sense and has meant that our clients are much happier with the products and services since they are defined up front for them.

We even have an "OOPS!" process for out of process /service meaning this is our non conforming procedure. And we have a corrective and preventive action procedure so we don't make the same mistake more than once if we can help it.

I am not saying that every company that is service oriented has to do design. The question is whether it is beneficial to the client or customer? If you feel you don't need it and the customer or client is happy with out it fine. If you find that there are problems on both sides with what you have agreed upon and what is expected maybe you should at least consider beefing up contract review.

It works wonderfully for us and it makes for happy clients. And that is how our business is spread is from our happy clients.

Phyllis

From: ISO Standards Discussion
Date: Wed, 22 Mar 2000 07:34:59 -0600
Subject: Re: Design: Widgit vs. Service /../Humphries/Naish/Arbuckle

From: Don Arbuckle

re: design for service companies

I have to go along with Phyllis. Depending on the service (product) provided there can be a very definite design process.

We are also ISO 9001 compliant (having found no business case for registration) and find the controls to be very helpful internally and our customers (especially the service clients) can see exactly how the standard fits the service industry. I have assisted over two dozen service agencies achieve ISO 9000 compliance/registration including both ISO 9001 and ISO 9002. In each case we look to see if the service they provide is unique, or industry driven. When industry driven, then rarely is there a discussion about including design in the scope of the implementation...it is not there! On the other hand, if the processes they follow are unique, because the service they provide is unique, then controlling the design process is not only included in the implementation, but is a business requirement.

Don Arbuckle

From: ISO Standards Discussion
Date: Wed, 22 Mar 2000 08:30:04 -0600
Subject: Re: Design: Widgit vs. Service /../Naish/Arbuckle/Kozenko

From: Write9000

> I have to go along with Phyllis. Depending on the service (product)
> provided there can be a very definite design process.

I really liked Phyllis' post, and it's supported by (somewhat) objective evidence:

The 1999 Survey of ISO9000 users available off a home-page link at www.qualitydigest.com states that companies that attempted to exceed the minimum Standard requirements reported a more favorable return on investment.

It's so easy to find a list of reasons not to apply 4.4 Design Review. Apparently, it's costly too!

David M. Kozenko

Design in ISO9001 - R U Confounded? (http://Elsmar.com/Forums/showthread.php?t=609) is from an 'earlier time' yet has some good insights.

This is an old thread I thought worthy of resurrecting. The evolution of what constitutes 'Design' has been significant.

Any new comments?

My opinion is that there is absolutely no company who is exempt from Design.

All processes must be designed. Therefore, the design of the process is subject to the same rules. However, getting most folks to buy into this philosophy is an uphill battle.

Typically, when working with a client - I do not force them to consider this until after I can prove to them that we have just gone through the design aspects of a process. For instance, I recently worked with a distribution facility where we set up operations. I had them go through all of the planning aspects, FMEA, verification of processes, validation at the point of receiving, etc.......
After setting up operations, we did a gap analysis against the standard. . . Their first statement was that they did not do design. However, I asked them to humor me and lets go through the requirements and compare to our actions during set up of operations. In the end - - they agreed that they are not exempt from design since they did indeed design all of their processes.

We found that soft services also applied here, since we designed the processes by which they would hire people and then assess competencies, etc. . . Information Services is also an often overlooked area here. It is often the backbone of the systems - - but the design phase of the technology is not disciplined or documented - - - huge missed opportunity.

Just my own philosophy - - -but it has worked well for me. :)

Typically in service operations design is not addressed. However, IMHO many service organizations do, in fact, design their services. Hospitals are, I believe, an example, where treatment and reaction plans are 'designed'.

A hypothetical company sells extended warranties. Contracts come from stores such as Walmart which sell appliances and such. The company selling the extended service contracts does not actually do any service - actual repair/replacement is contracted out. As I interpret their business system, they design the extended warranty (service) contracts they sell.

How would you address the design issue in a company such as this?

Most service organizations do design.
Taking Marc’s example (in broad outline – any more detail costs money!).
1. The company offering a service to Wal-mart looks at the input – something from the customer that says what they want to achieve from the service (typically in terms of a service offering they want to put before their end customer).
2. They then prepare a design brief, assign responsibilities to their design team (Finance people mainly to investigate the cost of capital, statisticians to look at reliability data for the white goods covered within the scope, marketing people to look at how they plan to present the service to the public etc.).
3. Each team member goes away, does their “design” and produce their bit of the output.
4. The next stage is for the team to come back with their outline proposal which the design leader pulls into a concerted presentation to (for example) the senior management team for a Design Verification (or review).
5. With a service the first validation is normally a trial marketing of the service in a limited area (perhaps a few stores) the results of which are compared with the customer requirements and decision taken as to whether to go back to the drawing board.

JMHO

I work for a Heat Treating company and I have had this discussion with our Corporate Quality Manager. He insists that we do not do design. I say we do.

We are certifying to ISO9001:2000 this October and have plans on certifying to TS next year.

Ts does not let us get away with the design exclusion. Even though we are a service company we are defined as "Manufacturing" by the auto industry. I believe that if we "design" a heat treating process we fall under design in the standard.

Has anyone contacted IATF or any of the other "Experts" on this?

Mike W

:bonk:

I work for a Heat Treating company and I have had this discussion with our Corporate Quality Manager. He insists that we do not do design. I say we do.

We are certifying to ISO9001:2000 this October and have plans on certifying to TS next year.

Ts does not let us get away with the design exclusion. Even though we are a service company we are defined as "Manufacturing" by the auto industry. I believe that if we "design" a heat treating process we fall under design in the standard.

Has anyone contacted IATF or any of the other "Experts" on this?

Mike W

:bonk:
TS16949 states types of design responsibility: product and process.
I suggest you are not product design responsible, but are process design responsible. See TS 7.3.1 this would be an exclusion for product design, but 7.3.2.2, and 7.3.3.2 are manufacturing process designs which are not exclusions.

I work for a Heat Treating company and I have had this discussion with our Corporate Quality Manager. He insists that we do not do design. I say we do.

Ts does not let us get away with the design exclusion. Even though we are a service company we are defined as "Manufacturing" by the auto industry. I believe that if we "design" a heat treating process we fall under design in the standard.
If nothing else, the 2000 version requires process design. This is where you are 'caught'... In QS and now TS process design has always been part of the show - APQP.

But I look beyond that and away from automotive (this being the ISO 9K forum). For example, I worked with an insurance company which sold what we all know as "extended" warranties. Staples was (is?) one of their MANY clients (think Sears). Staples contracted with them to structure, provide and administrate the warranties. My client did all the 'work', including arranging for repairs, etc., while Staples does the selling, initial fee collection and such. Basically my past client is contacted by a company and my client designs an extended warranty program down to, and including, designing data transfers - tape, internet, realtime or whatever the company's capabilities are. To me this is design. They have a template they use for new clients (MS Project) and the plan includes what, in manufacturing, would be known as verification and validation (e.g.: test data transfer runs including importing that data into my client's master database).

I work for a Heat Treating company and I have had this discussion with our Corporate Quality Manager. He insists that we do not do design. I say we do.

We are certifying to ISO9001:2000 this October and have plans on certifying to TS next year.

Ts does not let us get away with the design exclusion. Even though we are a service company we are defined as "Manufacturing" by the auto industry. I believe that if we "design" a heat treating process we fall under design in the standard.

Has anyone contacted IATF or any of the other "Experts" on this?

Mike W

:bonk:

thought provoking thread!

Now Suppose there is a change in product specifications, as a CA / PA. Due to new advancements, tightening Pollution control norms... or what ever. Six sigma necessitating narrower controls, aided by plc's....

that it needs a change. Will it not go as per clause 7.3 of ISO9K2K as, very well illustrated, in a post earlier?

I don't appreciate/ understand why do quality-management-system responsible operators ( all hierarchical levels) shirk/ get scared of 7.3 while their customer focus is reportedly always at a high ebb? The balancing act demands achieving process-comprension capability maturity?

My opinion is that there is absolutely no company who is exempt from Design.
All processes must be designed. Therefore, the design of the process is subject to the same rules. However, getting most folks to buy into this philosophy is an uphill battle.


Because I have created an Inspection Process, does that make me a designer? Because the Shop Foreman has developed a Material Handling Process, is he/she a designer? Everybody knows what "Design" is. You face an uphill battle because you are making your own rules. Sorry, but every time I see this argument, I want to scream. If what you say was true, there would have never been an option in the old or new ISO Standard to exclude it. :agree: :smokin:

Yes - the definition of design is 'evolving'.

Yes - the definition of design is 'evolving'.

Why do you think that is? I mean, some people just start creating the concept that ALL processes should be included in Design? What's the advantage? Make it harder to get registered? The ultimate conceptual design was when you decided to go into business. We should have to justify our "design" of everything we created to make our business profitable? If anything, it's proprietary. It's your idea and your niche. I've always thought that there are groups out there that start these radical ways of thinking to try to impress the rest of us morons who eventually bear the brunt of their "brainstorms". ;)

Posted by Marc - 2 Days Ago at 03:56 AM
If nothing else, the 2000 version requires process design. This is where you are 'caught'... In QS and now TS process design has always been part of the show - APQP.
But I look beyond that and away from automotive (this being the ISO 9K forum).

I can understand where 'process design' would be a product for a 'service provision,' but I am having a hard time distinguishing where 'process design' ends and 'control of production provision' (7.5.1) begins for a manufacturer.

Here again I think the vocabulary of 9000 fails me in regards to the reading of 9001. In 7.3.1 the "organization shall plan and control the design and development of product." 9000 defines product as "a result of a process," but then defines Design and Development as "a set of processes that transforms requirements into specified characteristics or into specidfication of a product, process or system."

By that definition then the development of the Quality Management System itself would need to comply with 7.3.

Please help me understand?!

Thanks,
Doug

Overlap - But still interesting... See Design - Widget vs. Service Organization Product (http://Elsmar.com/Forums/showthread.php?t=2691)

I can understand where 'process design' would be a product for a 'service provision,' but I am having a hard time distinguishing where 'process design' ends and 'control of production provision' (7.5.1) begins for a manufacturer.

Here again I think the vocabulary of 9000 fails me in regards to the reading of 9001. In 7.3.1 the "organization shall plan and control the design and development of product." 9000 defines product as "a result of a process," but then defines Design and Development as "a set of processes that transforms requirements into specified characteristics or into specidfication of a product, process or system."

By that definition then the development of the Quality Management System itself would need to comply with 7.3.

Please help me understand?!

Thanks,
Doug

Same here Doug. Try this one:

A term in a definition or note which is defined elsewhere in this clause is indicated by boldface followed by its entry number in parentheses. Such a boldface term may be replaced in the definition by its complete definition. For example:

product (3.4.2) is defined as “result of a process (3.4.1)”;

process is defined as “set of interrelated or interacting activities which transforms inputs into outputs”.

If the term “process” is replaced by its definition, as follows:

product then becomes “result of a set of interrelated or interacting activities which transforms inputs into outputs”.

So if we replace terms in the ISO 9001 7.3.1 clause, which says:
The organization shall plan and control the design and development of product.

with definitions in ISO 9000:2005:
design and development
set of processes that transforms requirements into specified characteristics or into the specification of a product…

We can also say that ISO 9001 7.3.1 requires us to:

Plan and control the set of interrelated or interacting activities which transforms inputs into outputs that transforms requirements into specified characteristics or into the specification of a result of a process.

The result will have a colorful meaning, isn't it?:bigwave:

All the more for people whose vernacular is other than English.

tony s