IATF 16949:2016 Clause 8.3.6.1 Design and development changes

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 certification 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 development, 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 prohibit 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 additional 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. 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 requirements 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 documentation 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 documentation 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 bottlenecks in the design change loop and only present the design authorities with changes that require their expert judgement. Make sure your process for design and development changes follow appropriate steps of define plan, have inputs and outputs, verify and validate to the extent necessary to meet customer requirements and control product, quality and business risks. Changes may come from internal, customer or regulatory sources. Get all requests for product or manufacturing process design changes in writing from your customer. Impact of the change must be evaluated on – materials used; design process; manufacturing process; characteristics and use of developed product; regulatory compliance; cost; etc.

Clause 8.3.6.1 Design and development changes

In addition to the requirement given in ISO 9001:2015 clause 8.3.6 Design and Development changes, clause 8.3.6.1 requires that organization evaluates all design changes after initial product approval, including those proposed by the organization or its suppliers for potential impact on fit, form, function, performance, and/or durability. These changes are to be validated against customer requirements and approved internally, prior to production implementation. If required by the customer, the organization must obtain documented approval, or a documented waiver, from the customer prior to production implementation. For products with embedded software, the organization must document the revision level of software and hardware as part of the change control

Please click here for ISO 9001:2015 clause 8.3.6 Design and Development changes

This clause pertains to the control and management of changes that occur during the design and development stages of automotive products and processes. Compliance with Clause 8.3.6.1 aimed to ensure that any design and development changes in the automotive industry were well-controlled, properly assessed, and did not compromise product safety, quality, or customer requirements. It helped automotive companies maintain consistency and integrity throughout the product development lifecycle. Let’s explore the key aspects of this clause:

  1. Change Control Process: Automotive companies were required to have a formal change control process in place to manage design and development changes effectively. This process needed to be documented and established to ensure that any modifications made during the design and development stages were carefully evaluated and controlled.
  2. Impact Assessment: When a change was proposed, the organization had to conduct a comprehensive impact assessment to understand the potential consequences of the change. This assessment involved evaluating the impact on product functionality, safety, quality, compliance with requirements, and customer-specific requirements.
  3. Authorization and Approval: The change control process needed to define the appropriate level of authorization and approval required for various types of changes. Depending on the nature and magnitude of the change, relevant personnel, including engineering, quality, and management representatives, needed to approve and authorize the change.
  4. Verification and Validation: Before implementing the change, the organization was required to verify and validate the changes. This step involved testing and validating the changes to ensure they did not adversely affect the product’s performance, safety, or quality.
  5. Documentation: All design and development changes, along with their associated impact assessments, authorizations, and verifications, needed to be thoroughly documented. Proper documentation allowed for traceability, transparency, and effective communication across the organization.
  6. Communication: The change control process required clear and effective communication throughout the organization. Relevant stakeholders needed to be informed of the change, its implications, and any actions they needed to take as a result.
  7. Risk Management: The change control process should incorporate risk management principles. Potential risks arising from the changes should be identified, evaluated, and appropriate actions taken to mitigate or control these risks.
  8. Training: If the design and development changes impacted the skills or knowledge required by employees, the organization had to ensure that affected personnel received the necessary training to adapt to the changes.

Identification of design changes
All design changes are 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 processs 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 screening 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). 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:

  • Identify the product of which the design is to be changed.
  • State the nature of the proposed change.
  • Identify the principal requirements, specifications, drawings, or other design documents that are affected by the change.
  • State the reasons for the change either directly or by reference to failure reports, nonconformity reports, customer requests, or other sources.
  • Provide for the results of the evaluation, review, and decision to be recorded.

Documenting design changes
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:

  • 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.
  • 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.
  • 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 experimentation and testing, the results for such activities should be documented to form part of the change documentation.

Review and approval of design changes

All design changes to be reviewed and approved by authorized personnel before their implementation including changes to proprietary designs. The organization are to address the impact of a design change on the systems 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 providing 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:

  • To validate the reason for change
  • To determine whether the proposed change is feasible
  • To judge whether the change is desirable
  • To determine the effects on performance, costs, and time-scales
  • To determine the impact of the change on other designs with which it interfaces and in which it is used
  • To examine the documentation affected by the change and consequently program their revision
  • 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:

  • Whether to accept or reject the change
  • 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 process. 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 supporting handbooks and manuals. So, deciding when to incorporate the changes is a very important consideration.

Evaluating all design changes

Evaluating all design changes after initial product approval is a crucial practice in the automotive industry to ensure that any modifications or updates made to the product design do not compromise its fit, form, function, performance, and durability. This evaluation process helps to maintain the integrity and quality of the product throughout its lifecycle. Let’s explore the key aspects of this practice:

  1. Post-Approval Design Change Evaluation: After the initial product approval, the organization establishes a systematic process to review and evaluate all proposed design changes. This evaluation includes changes proposed by the organization itself or by its suppliers.
  2. Impact Assessment: The primary purpose of this evaluation is to assess the potential impact of the design changes on various aspects of the product, such as fit (how components and parts come together), form (the physical appearance and layout), function (how the product operates and performs its intended tasks), performance (the product’s ability to meet specifications and requirements), and durability (the product’s lifespan and resistance to wear and tear).
  3. Cross-Functional Review: The evaluation process involves a cross-functional team that includes representatives from engineering, quality assurance, manufacturing, and other relevant departments. This team collectively reviews and analyzes the proposed changes to gain a comprehensive understanding of their implications.
  4. Risk Analysis: The team identifies potential risks associated with the design changes. These risks can include safety concerns, negative impacts on performance or reliability, non-compliance with regulatory requirements, and adverse effects on customer satisfaction.
  5. Validation and Testing: Depending on the complexity and significance of the design changes, the organization may conduct validation and testing to verify the impact on fit, form, function, performance, and durability. Testing may involve simulations, prototypes, or actual product testing, as appropriate.
  6. Supplier Involvement: If the design changes are proposed by suppliers, the organization collaborates closely with them during the evaluation process. The organization may require suppliers to provide relevant data, testing results, and other supporting information to assess the changes adequately.
  7. Documentation and Traceability: The entire evaluation process is thoroughly documented, providing a clear record of the design change assessments and the actions taken. Proper documentation ensures traceability and transparency in case of future reference or audits.
  8. Continuous Improvement: The evaluation process is not a one-time activity but a part of the organization’s continuous improvement efforts. Feedback from the evaluation process is used to enhance design, development, and change management processes for the future.

By conducting thorough evaluations of design changes after initial product approval, automotive organizations can ensure that any modifications are well-controlled and do not compromise the product’s performance, safety, and customer satisfaction.

Validated against customer requirements

Validating design and development changes against customer requirements and obtaining internal approval before implementing them into production is a fundamental practice in the automotive industry. This process ensures that any modifications made to the product design are in line with customer expectations and internal quality standards. Let’s delve into the key steps involved in this validation and approval process:

  1. Customer Requirement Validation: Before proceeding with any design and development changes, the automotive organization must thoroughly validate the changes against the specific requirements and expectations of their customers. This involves a detailed analysis of customer feedback, specifications, and any other relevant inputs to ensure that the proposed changes align with customer needs.
  2. Design Verification: Once the design changes have been proposed, the organization conducts design verification activities to confirm that the modified design meets the established requirements. This can include simulations, testing, prototyping, and other validation methods to ensure that the proposed changes will function as intended.
  3. Internal Review and Approval: After successful validation against customer requirements and design verification, the proposed changes are subjected to an internal review process. This review involves cross-functional teams, including engineering, quality assurance, manufacturing, and other relevant stakeholders. The purpose is to ensure that the changes are feasible, compliant with standards, and align with the organization’s strategic objectives.
  4. Risk Assessment: During the internal review, the organization also performs a comprehensive risk assessment. This helps identify potential risks associated with the design and development changes. Risks related to safety, quality, compliance, and customer satisfaction are considered, and appropriate actions are taken to mitigate or control these risks.
  5. Approval and Authorization: Once the design changes have successfully passed the internal review and risk assessment, they require formal approval and authorization. The designated personnel, which may include engineering managers, quality managers, and senior leadership, provide the necessary approvals to move forward with the changes.
  6. Documentation and Record Keeping: Throughout the entire process, the organization maintains meticulous documentation of all activities related to the design and development changes. This includes customer requirement validation results, design verification reports, internal review records, and approval documentation. Proper documentation ensures traceability and compliance with quality standards.
  7. Communication: Effective communication is essential during this process. The outcome of the validation and approval process, as well as any necessary changes or instructions, is communicated to all relevant departments and stakeholders involved in the production process.

By validating design and development changes against customer requirements and gaining internal approval, automotive organizations ensure that only authorized and well-vetted modifications are implemented into production. This helps maintain product quality, customer satisfaction, and adherence to i IATF 16949:2016.

Document approval by the customer

When required by the customer, the organization must obtain documented approval or a documented waiver before implementing any changes in the production of the product. This process ensures that the customer is aware of and agrees to the proposed changes, whether they are related to design, materials, processes, or any other aspect of the product. This practice is vital for maintaining transparency, customer satisfaction, and adherence to customer-specific requirements. Let’s delve into the key aspects of this requirement:

  1. Customer Requirements and Agreements: The organization must thoroughly understand the customer’s specific requirements and agreements related to the production of the product. These requirements may include specifications, quality standards, delivery schedules, and any other conditions that the organization must fulfill.
  2. Proposed Changes: If the organization identifies the need for changes in the production process, product design, materials, or any other aspect that could affect the final product, they must document these proposed changes.
  3. Impact Assessment: Before seeking customer approval, the organization should conduct a comprehensive impact assessment of the proposed changes. This assessment evaluates how the changes may affect the product’s quality, functionality, performance, safety, and compliance with customer requirements.
  4. Documented Approval or Waiver: Depending on the nature of the changes and the customer’s requirements, the organization must either obtain documented approval or a documented waiver from the customer. The customer’s approval confirms that they are aware of the changes and agree to them. A waiver, on the other hand, indicates that the customer has been informed of the changes but has chosen not to approve them.
  5. Effective Communication: Effective communication is key throughout this process. The organization should clearly explain the proposed changes to the customer, along with the potential impacts and benefits. Any concerns or questions raised by the customer should be addressed promptly.
  6. Record Keeping: The organization should maintain meticulous records of all communications with the customer regarding the proposed changes. This includes the documentation of customer approval, waivers, or any other relevant correspondence.
  7. Timely Actions: It’s essential for the organization to obtain customer approval or waivers in a timely manner. Delays in seeking approval could lead to production bottlenecks or disruptions.
  8. Regulatory Compliance: In some cases, the organization may need to consider regulatory requirements that govern changes to specific products or industries. Compliance with such regulations is critical and may also require customer approval.

By obtaining documented approval or waivers from the customer prior to production implementation, the organization demonstrates its commitment to meeting customer requirements and ensures a clear understanding between both parties. This practice helps build trust, maintain customer satisfaction, and fosters a positive relationship with the customer, which is essential for long-term business success.

Embedded software

or products with embedded software, documenting the revision level of both the software and hardware is a critical part of design change control in the automotive industry. This documentation ensures that the software and hardware versions used in the design and development process are accurately tracked and controlled. It helps maintain consistency, traceability, and quality throughout the product lifecycle. Let’s explore the key aspects of this practice:

  1. Embedded Software and Hardware Identification: The organization must establish a systematic method for identifying and labeling the embedded software and hardware used in the product’s design. This identification should include unique version numbers or revision codes that distinguish one version from another.
  2. Change Management Process: The organization should have a well-defined change management process that covers both software and hardware revisions. This process outlines how changes to the software and hardware are proposed, reviewed, and implemented throughout the design and development stages.
  3. Version Control: The software and hardware versions must be carefully managed using version control mechanisms. Version control systems help track changes, maintain historical records, and prevent conflicting revisions.
  4. Traceability: Documentation should provide full traceability between the design changes, the associated software and hardware revisions, and the reasons for these changes. This traceability allows for a clear understanding of how different versions of the software and hardware evolve over time.
  5. Impact Assessment: Before implementing any design changes that involve software or hardware revisions, the organization should conduct a thorough impact assessment. This assessment evaluates the potential implications of the changes on the product’s performance, safety, and compliance with customer requirements.
  6. Validation and Testing: For products with embedded software, validating the changes is critical. The organization must ensure that any changes to the software or hardware do not introduce defects or negatively impact the product’s functionality. Validation may involve testing the software, performing regression tests, and ensuring that the new hardware functions as intended.
  7. Configuration Management: Configuration management is essential for products with embedded software. It ensures that the correct software and hardware versions are deployed during production and that any updates or changes are controlled and well-documented.
  8. Approval and Authorization: Similar to other design changes, software and hardware revisions require proper approval and authorization before implementation. The designated personnel responsible for managing changes in the organization must review and approve the changes.

By documenting the revision level of embedded software and hardware as part of the design change control process, automotive organizations can effectively manage the complexities associated with software-driven products. This practice aligns with industry standards and best practices, ensuring that the product’s quality and compliance are upheld.

Leave a Reply