Design - Widget vs. Service Organization Product

Marc

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

Marc

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

Marc

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

barb butrym

Quite Involved in Discussions
#16
my humble opinion, such as it is:

the rewrite (2000) is done nicely, ending the argument. if you do parts of design & it applies you say so...when parts don't apply then say not applicable. I always did this...but before it was decide 9001/or 9002...now its piece by piece and all are9001. I personally like it.

some service industries are design some are not..(training is..IMHO) When ever you need to determine the customer requirement and determine how you will meet it, a review of ibputs/outputs and validation has tooccur....when you change what you do as a result you need to control it...contract review drives it...as does industry need. You never loose sight of the product. Design by another name is still design. Obviously teh controls are light years apart from one service to another......but they still are controlled. VAriations of the norm, are still variations and must meet certain validation/input/output reviews. What do you call them? whatever you call them, they need to be documented. If you document your system properly you can call them"looney toon reviews" for all I care as long as you do them....and they meet the requirements.
 
Thread starter Similar threads Forum Replies Date
Marc Design - Widget vs. Service - Exclusion? In Service operation design not addressed Design and Development of Products and Processes 26
DuncanGibbons Section 8.3 relevant for design organisations AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
P DFMEA - Machinery Design Best Practices FMEA and Control Plans 0
R Is a FAIR required on parts that we design? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C Stress / Challenge Conditions for Design Verification Testing to Reduce Sample Size 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 11
J Significant change related to design and intended use EU Medical Device Regulations 3
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
U NOC - What is considered a "design change" EU Medical Device Regulations 5
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 9
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 5
K Joint approval between OEM and Manufacturer on Design Documents ISO 13485:2016 - Medical Device Quality Management Systems 4
M API 4F/7K/8C Design Package Validation Oil and Gas Industry Standards and Regulations 2
A Design History File - Not ready to share the design drawings or Bill of Material US Food and Drug Administration (FDA) 2
W Need for current design or process control FMEA and Control Plans 2
A What is the difference between Design Process, Process Design and Design Control? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
D Test summary report example for design validation wanted - ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
B Why the Greek god Hephaestus should have done a design FMEA (DFMEA) on his giant robot APQP and PPAP 1
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Qualification and Validation (including 21 CFR Part 11) 5
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
A Sample Agreement available for Outsourcing Medical Device Design activity? ISO 13485:2016 - Medical Device Quality Management Systems 1
DuncanGibbons How is the arrangement between Design and Production organisation envisaged? EASA and JAA Aviation Standards and Requirements 4
L Design & Development of a SERVICE Service Industry Specific Topics 13
C Documentation for items used for Design Verification 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Design verification driven by new equipment. How is this different than process validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A AS9102B - 3.6 Design Characteristics and form 3 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
P Design FMEA - Detection Rating criteria ISO 14971 - Medical Device Risk Management 3
U Medical Device Design finalization testing ISO 13485:2016 - Medical Device Quality Management Systems 2
S MDR Delay - MDD design Change? (before new MDR DOA) EU Medical Device Regulations 8
J Iterative design and production for custom made products ISO 13485:2016 - Medical Device Quality Management Systems 3
T Design Input detail & specificity ISO 13485:2016 - Medical Device Quality Management Systems 4
J Design file for pre-existing products - Inputs and Outputs ISO 13485:2016 - Medical Device Quality Management Systems 5
D Design Transfer Template capturing Customer Specific Requirements Other Medical Device Related Standards 3
T Design Control Procedures later in the Development Process ISO 13485:2016 - Medical Device Quality Management Systems 6
M Looking for a Presentation on Design for Excellence (DfX) Manufacturing and Related Processes 2
K Old medical devices -> 7.3.7. Design and development validation ISO 13485:2016 - Medical Device Quality Management Systems 1
R Design and Manufacture Guidelines for Surface Mount Technology Misc. Quality Assurance and Business Systems Related Topics 9
optomist1 Design Exclusion, but now we might have an outsourced Product Design ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
Q Relabeler for patent expired product - design control responsibilities? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
B Supplier of design and manufacture process ISO 13485:2016 - Medical Device Quality Management Systems 10
I Does anybody use Detection in medical device Design FMEA? ISO 14971 - Medical Device Risk Management 18

Similar threads

Top Bottom