How to address risks and opportunities in IATF 16949:2016

Since 2016, when the last update of IATF 16949 occurred, the concept of risks and opportunities in this automotive standard has been brought into the forefront of process approach/quality planning and control. The standard requires an organization to identify and control the risks by deploying preventive actions, to take advantage of opportunities that can arise from the organization’s context in a controlled way (by mitigating the associated risks), and to link several risks to contingency plans (in fact, to deploy contingency plans for them). It appears to be clear, but how we can implement this in a practical way?

The hands-on approach based only on standard explanation is not enough, so here is a bit more about how to implement related requirements and how to address IATF 16949 risks and opportunities.

What do the IATF 16949:2016 requirements actually specify?

There are multiple requirements related to risks and opportunities, starting from clause 4.4.1, where the organization is required to determine the processes needed to address risks and opportunities that are determined and transferred as a responsibility of top management, as per the 5.1.2 requirement. In requirements starting from 6.1, it is requested to determine the risks and opportunities needed to be taken into account, to plan actions to address those identified risks and opportunities, and to evaluate their effectiveness.

By also taking into consideration the requirements from clause 4.1, where it is required to analyze the internal and external issues concerning the organization, and clause 4.2, where it is required to determine the needs and expectations of interested parties, we will have to take into account the risks related to:

  • internal and external identified issued
  • risks related to satisfying interested parties’ requests
  • lessons learned from product recalls
  • product audits
  • field returns and repairs
  • complaints
  • scrap
  • rework

For more about the context of the organization, read the article How to define the context of the organization in IATF 16949:2016.


Why is a contingency plan needed in IATF 16949?

All the risks mentioned above have to be considered during development and establishment of the contingency plan – see the 6.1.2.3 IATF requirement. The main goal is to ensure the uninterrupted delivery of parts to customers in the case of special situations.

Nonconformities and actions management process

Requirement 6.1.2.1 defines clearly what we have to do to establish a process for handling nonconformities:

  • Determine potential nonconformities and their causes.
  • Analyze the potential nonconformities in order to decide if we will establish preventive actions.
  • If we decide to implement actions, we will need to establish the actions and check their effectiveness (see PDCA cycle). This requirement is referred to in section 9.1.3.

The actions (including data regarding the results of implementation) have to be stored as documented information and transferred as lessons learned for similar processes (to prevent the occurrence of a nonconformity in similar processes). Also, requirement 9.1.3.1 demands us to use data to measure trends and establish actions based on such trends (it is about prioritization). Do not forget that the effectiveness of actions taken to address risks and opportunities has to be presented as an input for the management review (see requirement 9.3.2.- e, about the effectiveness of actions taken to address risks and opportunities).

Learn more about management review in the article How to implement management review according to IATF 16949.

How can you implement the requirements?

Here is a model for how to implement the requirements:

IATF 16949 risks and opportunities: How to address them

By using this model, you will start to identify the risks. Then you will analyze each identified risk:

  • determine the potential effect on customers (external, internal)
  • assess the severity of the effect – here it is recommended to use a numeric scale (for example: 1 – negligible effect, 5 – effect related to safety and regulations violations)
  • based on the history (or general experience, if historical data are missing) assign a probability of occurrence; here it is also recommended to use a numeric scale (for example: 1 – almost impossible, 5 – for sure it will be happening)
  • calculate a level, by multiplying severity by occurrence
  • assign a classification to the risk (for example: class A – high risk level, class B – average risk level, class c – low risk level)
  • decide for each defined class whether it is necessary to act or not

What do we have to do?

When the risk is related to issues defined in the IATF 16949 contingency plan, then you must document contingency plans for that risk. Extend this approach for the risks with high risk levels, and define contingency plans for them, also. Plan preventive actions, follow their implementation, and check their effectiveness based on the PDCA cycle.

In the end, do not forget to update the risk level (keep a history for all risk levels and the reason for their changes). And finally, consider implementing your system in a lean way – keep everything simple and clear, document clearly the rules you want to implement, use digital tools to share data and information for all employees, and follow the principle of “one click of distance between the employee and the information.”

To see how does this risk process fit into the overall IATF 16949 implementation process download this free IATF 16949:2016 Implementation Diagram.

Advisera Alexandru Tudose
Author
Alexandru Tudose
Alexandru Tudose is a senior automotive industry specialist, combining expertise in IATF 16949 and related tools with engineering and digital tools development to drive continual improvement over first- and second-tier automotive suppliers. He is accustomed to working in multidisciplinary environments across IT, automation, quality, engineering, and project management disciplines. Alexandru has been an Intranet Portals developer enthusiast since 2002, and continually updates the implementation as technology changes.