Automotive Quality Systems Handbook Episode 8 pot

l Test procedures to be produced which describe how the tests specified in the test specification are to be conducted together with the tools and test equipment to be used and the data to be recorded l All measuring equipment to be within calibration during the tests l The test sample to have successfully passed all planned in-process and assembly inspections and tests prior to commencing qualification tests l The configuration of the product in terms of its design standard, deviations, non- conformities, and design changes to be recorded prior to and subsequent to the tests l Test reviews to be held before tests commence to ensure that the product, facilities, tools, documentation, and personnel are in a state of operational readiness for ver- ification l Test activities to be conducted in accordance with the prescribed specifications, plans, and procedures l The results of all tests and the conditions under which they were obtained to be recorded l Deviations to be recorded, remedial action taken, and the product subject to re-ver- ification prior to continuing with the tests l Test reviews to be performed following qualification tests to confirm that sufficient objective evidence has been obtained to demonstrate that the product fulfills the requirements of the test specification Recording results (4.4.8.2) The standard requires validation results to be recorded and design failures to be docu- mented in the validation records . This requirement was addressed above under Procedures for controlling qualification tests and demonstrations and needs no further discussion. Addressing design failure (4.4.8.2) The standard requires the corrective and preventive action procedures to be followed in addressing design failures . Design control 267 auto204.qxd 10/04/00 21:33 Page 267 Preventive action cannot be taken on a failure that has occurred (see ISO 8402) except on other future designs. What is intended is that remedial action is taken to correct the design fault and corrective action taken to prevent the same failure arising again either in the same design or in other designs. Prototype program (4.4.8.3) Prototype program standards (4.4.8.3) The standard requires the supplier to have a prototype program when required by the customer and to use the same subcontractors, tooling, and processes as will be used in production . There will be situations where the customer requires a prototype program but when no such requirement has been stated it does not mean you should not produce prototypes. Prototypes will not normally be required when the design is similar to a previously proven design or standard or the design is so simple that sufficient evidence can be obtained during the production trial run. Many different types of models may be needed to aid product development, test theo- ries, experiment with solutions, etc. However, when the design is complete, prototype models representative in all their physical and functional characteristics to the produc- tion models may need to be produced. When building prototypes, the same materials, locations, subcontractors, tooling, and processes should be used as will be used in production, so as to minimize the variation. Tracking performance testing (4.4.8.3) The standard requires all performance testing activities to be monitored for timely com- pletion and conformance to requirements . As part of the verification plan discussed previously, you should include an activity plan that lists all the planned activities in the sequence they are to be conducted and use this plan to progressively record completion and conformance. The activity plan should make provision for planned and actual dates for each activity and for recording recov- ery plans when the program does not proceed exactly as planned. It is also good practice to conduct test reviews before and after each series of tests so that corrective measures can be taken before continuing with abortive tests (see also under Design val- idation ). 268 Design control auto204.qxd 10/04/00 21:33 Page 268 Subcontracting design services (4.4.8.3) The standard requires the supplier to provide technical leadership while services are sub- contracted . Where you do not posses the necessary facilities for building prototypes or conducting design verification and validation, these activities may be subcontracted. However, ISO/TS 16949 requires that you exercise technical leadership in such matters. This means that you need to enter into a formal contract with the subcontractor, apply the controls you established to meet clause 4.6, and manage the test program. You should require the subcontractor to submit test plans and procedures for your approval prior to commencement of the test unless you are providing this information yourself. You need to be confident that the tests will produce valid data so the test set-up, test equipment, test environment, and monitoring methods need to be periodically reviewed. You should have a representative present during test and retain authority for starting and stopping the test. Design changes and modifications (4.4.9) This clause covers two different requirements, involving two quite different control processes. Design changes are simply changes to the design and can occur at any stage in the design process from the stage at which the requirement is agreed to the final cer- tification that the design is proven. Modifications are changes made to products to incorporate design changes and occur only after the first prototype is built. During devel- opment, design changes that affect the prototype are usually incorporated by rework or rebuild and are not classified as modifications. Following design certification, i.e. when all design verification has been completed and the product launched into production, changes to the product to incorporate design changes are classed as modifications. You need to control design changes to permit desirable changes to be made and to pro- hibit undesirable changes from being made. Change control during the design process is a good method of controlling costs and time-scales because once the design process has commenced every change will cost time and effort to address. This will cause delays while the necessary changes are implemented and provides an opportunity for addi- tional errors to creep into the design. If its not broke dont fix it! is a good maxim to adopt during design. In other words, dont change the design unless it already fails to meet the requirements. Designers are creative people who love to add the latest devices and the latest technologies, to stretch performance, and to go on enhancing the design regardless of the time-scales or costs. One reason for controlling design changes is to restrain the otherwise limitless creativity of designers in order to keep the design within the budget and time-scale. Design control 269 auto204.qxd 10/04/00 21:33 Page 269 The imposition of change control is often a difficult concept for designers to accept. They would prefer change control to commence after they have completed their design rather than before they have started. They may argue that until they have finished there is no design to control. They would be mistaken. Designs proceed through a number of stages (as described previously under Design reviews ). Once the design requirements have been agreed, any changes in the requirements should be subject to formal procedures. When a particular design solution is complete and has been found to meet the require- ments at a design review, it should be brought under change control . Between the design reviews the designers should be given complete freedom to derive solutions to the requirements. Between the design reviews there should be no change control on incomplete solutions. Design changes will result in changes to documentation but not all design documenta- tion changes are design changes. This is why design change control should be treated separately from document control. You may need to correct errors in the design docu- mentation and none of these may materially affect the product. The mechanisms you employ for such changes should be different from those you employ to make changes that do affect the design. By keeping the two types of change separate you avoid bottle- necks in the design change loop and only present the design authorities with changes that require their expert judgement. The sequence of the requirements in this clause is not necessarily the sequence in which the activities will need to be carried out. You may find therefore a little repetition in the following sections. Identification of design changes (4.4.9.1) The standard requires all design changes to be identified before their implementation (including changes to proprietary designs). At each design review a design baseline should be established which identifies the design documentation that has been approved. The baseline should be recorded and change control procedures employed to deal with any changes. These change proce- dures should provide a means for formally requesting or proposing changes to the design. The most effective method is by use of a Design Change Form constructed to collect all the data needed by the approval authorities. For complex designs you may prefer to separate proposals from instructions and have one form for proposing design changes and another form for promulgating design changes after approval. You will need a central registry to collect all proposed changes and provide a means for screen- ing those that are not suitable to go before the review board (either because they duplicate proposals already made or because they may not satisfy certain acceptance criteria which you have prescribed). 270 Design control auto204.qxd 10/04/00 21:33 Page 270 On receipt, the change proposals should be identified with a unique number that can be used on all related documentation that is subsequently produced. The change proposal needs to: l Identify the product of which the design is to be changed. l State the nature of the proposed change. l Identify the principal requirements, specifications, drawings, or other design docu- ments that are affected by the change. l State the reasons for the change either directly or by reference to failure reports, nonconformity reports, customer requests, or other sources. l Provide for the results of the evaluation, review, and decision to be recorded. Identification of modifications (4.4.9.1) The standard requires all design modifications to be identified, before their implemen- tation (including changes to proprietary designs). As modifications are changes to products resulting from design changes, the identity of modifications needs to be visible on the product that has been modified. If the issue sta- tus of the product specification changes, you will need a means of determining whether the product should also be changed. Not all changes to design documentation are design changes which result in product changes and not all product changes are modi- fications. (Nonconformities may be accepted which change the product but not the design.) Changes to the drawings or specifications that do not affect the form, fit, or function of the product are usually called alterations and those that affect form, fit, or function are modifications. Alterations should come under document control where- as design changes should come under configuration control. You will therefore need a mechanism for relating the modification status of products to the corresponding draw- ings and specifications. Following commencement of production the first design change to be incorporated into the product will usually be denoted by a number, such as Mod 1, for hardware and by Version or Release number for software. The practices for software differ in that versions can be incremented by points such as 1.1, 1.2, etc., where the sec- ond digit denotes a minor change and the first digit a major change. This modification notation relates to the product, whereas issue notation relates to the documentation that describes the product. You will need a modification procedure that describes the nota- tion to be used for hardware and software. Design control 271 auto204.qxd 10/04/00 21:33 Page 271 Within the design documentation you will need to provide for the attachment of modi- fication plates on which to denote the modification status of the product. Documenting design changes (4.4.9.1) The standard requires all design changes to be documented before their implementation (including changes to proprietary designs) The documentation for design changes should comprise the change proposal, the results of the evaluation, the instructions for change and traceability in the changed documents to the source and nature of the change. You will therefore need: l A Change Request Form, which contains the reason for change and the results of the evaluation. This was described previously as it is used to initiate the change and obtain approval before being implemented. l A Change Notice, which provides instructions defining what has to be changed. This is issued following approval of the change as instructions to the owners of the various documents that are affected by the change. l A Change Record, which describes what has been changed. This usually forms part of the document that has been changed and can be either in the form of a box at the side of the sheet (as with drawings) or in the form of a table on a separate sheet (as with specifications). Where the evaluation of the change requires further design work and possibly experi- mentation and testing, the results for such activities should be documented to form part of the change documentation. Documenting modifications (4.4.9.1) The standard requires all design modifications to be documented before their imple- mentation (including changes to proprietary designs). Prior to commencement of production, design changes do not require any modification documentation, the design changes being incorporated in prototypes by rework or rebuild. However, when product is in production, instructions will need to be provided so that the modification can be embodied in the product. These modification instruc- tions should detail: l Which products are affected, by part number and serial number 272 Design control auto204.qxd 10/04/00 21:33 Page 272 l The new parts that are required l The work to be carried out to remove obsolete items and fit new items or the work to be carried out to salvage existing items and render them suitable for modification l The markings to be applied to the product and its modification label l The tests and inspections to be performed to verify that the product is serviceable l The records to be produced as evidence that the modification has been embodied (see also clause 4.5.2.2 of ISO/TS 16949) Modification instructions should be produced after approval for the change has been granted and should be submitted to the change control board or design authority for approval before release. Review and approval of design changes (4.4.9.1 and 4.4.9.2) The standard requires all design changes to be reviewed and approved by authorized personnel before their implementation (including changes to proprietary designs). The standard also requires the supplier to address the impact of a design change on the sys- tems in which the product is used, the customer assembly process, and other related products and systems . Following the commencement of design you will need to set up a change control board or panel comprising those personnel responsible for funding the design, administering the contract, and accepting the product. All change proposals should be submitted to such a body for evaluation and subsequent approval or disapproval before the changes are implemented. Such a mechanism will give you control of all design changes. By pro- viding a two-tier system you can also submit all design documentation changes through such a body. They can filter the alterations from the modifications, the minor changes from the major changes. Remember that by controlling change you control cost so it is a vital organ of the business and should be run efficiently. The requirement for changes to be approved before their implementation emphasizes the importance of this control mechanism. The change proposals need to be evaluated: l To validate the reason for change l To determine whether the proposed change is feasible Design control 273 auto204.qxd 10/04/00 21:33 Page 273 l To judge whether the change is desirable l To determine the effects on performance, costs, and time-scales l To determine the impact of the change on other designs with which it interfaces and in which it is used l To examine the documentation affected by the change and consequently program their revision l To determine the stage at which the change should be embodied The evaluation may need to be carried out by a review team, by subcontractors, or by the original proposer; however, regardless of who carries out the evaluation, the results should be presented to the change control board for a decision. During development there are two decisions the board will need to make: l Whether to accept or reject the change l When to implement the change in the design documentation If the board accepts the change, the changes to the design documentation can either be submitted to the change control board or processed through your document control pro- cedures. During development it is a common practice to accumulate design changes for incorporation into the design when design proving has been completed. If there are many of these changes a two or three stage process of incorporation may be desirable. In the event that the development model is deliverable to the customer or, as in the case of one-off systems, the changes need to be incorporated into the design before delivery, acceptance may take place against drawings and specifications extended by change notes. However, unless the change notes accurately reflect the final design configuration, the integrity of any certification of the product against a proven design cannot be assured. There is also a temptation to cut costs by not incorporating latent design changes. This may well avert delayed delivery but will have severe consequences should modifications be necessary later or should the changes affect the integrity of the sup- porting handbooks and manuals. So, deciding when to incorporate the changes is a very important consideration. Review and approval of modifications (4.4.9.1) The standard requires all design modifications reviewed and approved by authorized personnel before their implementation (including changes to proprietary designs) . 274 Design control auto204.qxd 10/04/00 21:33 Page 274 During production the change control board will need to make four decisions: l Whether to accept or reject the change l When to implement the change in the design documentation l When to implement the modification in new product l What to do with existing product in production, in store, and in service The decision to implement the modification will depend on when the design documen- tation will be changed, when new parts and modification instructions are available. The modification instructions can either be submitted to the change control board or through your document control procedures. The primary concern of the change control board is not so much the detail of the change but its effects, its costs, and the logistics in its embodiment. If the design change has been made for safety or environmental reasons you may need to recall product in order to embody the modification. Your modification procedures need to provide for all such cases. In some cases the need for a design change may be recognized during production tests or installation and in order to define the changes required you may wish to carry out trial modifications or experiments. Any changes to the product during production should be carried out under controlled conditions, hence the requirement that approval of mod- ifications be given before their implementation. To allow such activities as trial modifications and experiments to proceed you will need a means of controlling these events. If the modification can be removed in a way that will render the production item in no way degraded, you can impose simple controls for the removal of the modifica- tion. If the item will be rendered unserviceable by removing the modification, alternative means may need to be determined, otherwise you will sacrifice the product. It is for this reason that organizations provide development models on which to try out modifications. Design control 275 auto204.qxd 10/04/00 21:33 Page 275 Task list This list is not an exhaustive task list for all design activities. It represents a sample of design control tasks that you may need to carry out. Many tasks may not be applicable for simple designs so you should be selective. They reflect one interpretation of the requirements in the standard. 1 Identify the types of products and services that the organization designs. 2 Determine the processes by which customer requirements or market needs are trans- lated into a set of specifications for a particular product or service. 3 Analyze these processes and identify the discrete tasks that are performed. 4 Prepare procedures to control these tasks and the interfaces between them. 5 Prepare or select guides and standards which assist designers to select proven tech- nologies, parts, materials, methods, etc. 6 Qualify your design staff in the appropriate skills. 7 Prepare procedures for the conduct of design verification activities. 8 Prepare procedures for the preparation and maintenance of design and develop- ment plans. 9 Determine a methodology for identifying and specifying the documentation require- ments for design activities, covering system design, hardware design, software design, service design, etc. 10 Determine a methodology for design and development which integrates the major design tasks from the feasibility phase to the production phase. 11 Prepare procedures for creating speciality plans covering reliability, safety, environ- mental engineering, etc. 12 Prepare standard requirements for subcontracted design activities which specify the documentation requirements. 13 Establish a mechanism of reviewing progress through the design and development process for in-house designs and subcontracted designs. 14 Create a procedure for controlling the allocation of work packages to various design groups and to subcontractors. 15 Produce procedures and standards governing the specification of development requirements for components of the design. 16 Produce procedures and standards governing technical interface specifications, their preparation, promulgation, and maintenance. 276 Design control auto204.qxd 10/04/00 21:33 Page 276 [...]... filing, masters, copies, drafts, custom binders l Document storage, libraries, and archive, who controls, location, loan arrangements l Document retention and obsolescence auto205.qxd 10/04/00 21:33 Page 288 288 Document and data control Control of external documents (4.5.1) The standard requires the supplier to establish and maintain documented procedures to control documents of external origin such as standards... to be taken, removal of obsolete documents becomes more difficult However, providing you have a 1 Further discussion on electronic documentation systems can be found in the ISO 9000 Quality System Development Handbook by David Hoyle (Butterworth-Heinemann, 19 98) auto205.qxd 10/04/00 21:33 Page 296 296 Document and data control means of distinguishing controlled and uncontrolled documents you should... 10/07/00 16:44 Page 282 282 Document and data control POLICY MANUAL CONTROL PROCEDURES SYSTEM MANUAL POLICIES AND PRACTICES OPERATING PROCEDURES STANDARDS NATIONAL STANDARDS GUIDES SPECIFICATIONS INSTRUCTION MANUALS DATA SHEETS PLANS REFERENCE DOCUMENTS DERIVED DOCUMENTS RECORDS REPORTS INTERNATIONAL STANDARDS INDUSTRY STANDARDS DRAWINGS INSTRUCTIONS Figure 5.1 Relationship between quality system documents... prescriptive but not descriptive The descriptive documents are covered by clause 4.16 on quality records The term document should be taken to include data or any information that is recorded and stored either on paper or magnetic media in a database or on disk It may be CONTINUOUS IMPROVEMENT (4.1.1.4) QUALITY POLICY (4.1.1) QUALITY SYSTEM (4.2) CONTRACT REVIEW (4.3) DESIGN CONTROL (4.4) PURCHASING (4.6) PROCESS... KEEP? ISSUE Yes INDEX IDENTIFY USE QUALITY SYSTEM (4.2) DESIGN CONTROL (4.4) PURCHASING (4.6) PROCESS CONTROL (4.9) INSPECTION AND TEST (4.10) INSPECTION, MEASURING, AND TEST EQUIPMENT (4.11) SERVICING (4.19) Figure 5.4 Clause relationships with the document control element MODIFICATION RECORDS (4.16) auto205.qxd 10/04/00 21:33 Page 285 Document and data control 285 both an audio and visual record... all controls under clause 4.5, the provisions of clause 4.16 relating to the identification, access, filing, and storage of quality records are equally appropriate to documents in general and should be applied although it is not mandatory auto205.qxd 10/07/00 16:44 Page 286 286 Document and data control Document control process The principal elements of document control are illustrated in Figure 5.5... changes J Do incorporate all design changes before any product is delivered auto205.qxd 10/04/00 21:33 Page 281 Chapter 5 Document and data control Scope of requirements Document and data control is one of the most important aspects of the quality system Although not the only aspect of the quality system, documentation is the foundation stone The requirements for document and data control can be confusing... users This is particularly true of quality system documents One finds that only the managers hold copies of the quality manual In some firms all the managers reside in the same building, even along the same corridor, and it is in such circumstances that one invariably finds that these copies have not been maintained It is therefore impractical to have all the copies of the quality manual in one place Distribute... data is information and documents are recorded information perhaps this clause should have been headed Information control There is often confusion also between quality system documents and quality documents and between technical documents and quality documents There is no doubt that all documents, data, and records should be controlled but the types of control will vary depending on the type of document... to those documents that are essential to the achievement and demonstration of quality The requirement can be quite onerous because it requires that every document has an associated governing procedure So if you include memoranda in your system, you will need a procedure to control them The way out of this maze is to use the quality system to define the documents that need to be controlled l Ensure that . abortive tests (see also under Design val- idation ). 2 68 Design control auto204.qxd 10/04/00 21:33 Page 2 68 Subcontracting design services (4.4 .8. 3) The standard requires the supplier to provide. delivered. 280 Design control auto204.qxd 10/04/00 21:33 Page 280 Chapter 5 Document and data control Scope of requirements Document and data control is one of the most important aspects of the quality. Information control . There is often confusion also between quality system documents and quality documents and between technical documents and quality documents. There is no doubt that all documents,