Tools and methods for managing deviations

A structured approach to deviations management requires the right methods and tools. These methods help bring clarity to the process and ensure that deviations are handled in a way that both solves problems and prevents future deviations.

Deviation management in the manufacturing industry is a crucial process for ensuring product quality, reducing operational disruptions and improving production flows. The process ranges from identifying and reporting deviations to conducting root cause analysis, implementing actions and validating the results. This often requires collaboration between different functions of the company, such as production, process engineers, quality department, maintenance and sometimes even suppliers and customers.

The article below describes different tools and methods for deviation management.

Tools and methods

There are various tools for deviation management, each of which plays a role in the process. The tools are often used in a logical order to ensure a systematic and efficient problem-solving process. Below is a description of these tools, their purpose and how they fit together in the process, from the identification of the problem to the implementation of long-term actions.

(P)FMEA

FMEA is a common tool used to assess potential failures and their consequences, both for products and processes. The tool helps to rank risks by assessing the severity, likelihood and detectability of the failure, which depending on the requirement standard leads to a so-called Risk Priority Number (RPN) or Action Priority (AP). Understanding early in the deviation management how the process requirements were handled and risk assessed is important, as this approach potentially led to the deviation.

Fishbone diagram (Ishikawa diagram)

A fishbone diagram is a visual tool used to structure possible causes of a problem into categories. It resembles a skeleton of a fish, where the main problem is the 'head of the fish' and categories such as 'People', 'Machines', 'Methods', 'Materials', 'Environment' and 'Measurement' are the 'legs of the fish'. Each category is populated with possible causes, providing a detailed overview of possible sources of error.

Fault Tree Analysis (FTA)

FTA is a structured and visual tool for analyzing potential faults in complex systems. It is used to identify combinations of events that could lead to a critical system failure. FTA creates a logic map in the form of a 'fault tree' where different failure causes are broken down into sub-events that contribute to the main problem.

5 Why (5Whys)

5 Whys is a simple but powerful tool for root cause analysis. It is typically used at the beginning of a deviation management, or most effectively for each suspected cause from the Ishikawa diagram, to quickly identify the root cause of a problem. By repeatedly asking "Why?" about an error, one gets deeper into the problem until the real cause is revealed.

Methods

There are of course many different ways to solve anomalies and different methods to do so. To name a few that are generally found for it, PDCA (Plan-Do-Check-Act), 8D method (Eight Disciplines Problem Solving), CAPA (Corrective and Preventive Action), Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control) are some. You are probably more or less familiar with all or some of them.

Regardless of the name, the overall purpose is largely the same; to identify a deviation, understand its cause, implement actions, and to validate that the actions are effective before closing the case.

Depending on the requirements and complexity, there is the possibility to adapt the own methodology to one's own business. No company benefits from overworking its methodology, while all companies need to assess and implement an adequate methodology that not only meets requirements, but also maximizes the value of the work.

The 8D methodology

An 8D methodology speaks for itself. It involves 8 defined steps to maximize the value of each identified deviation in a structured way. Each company can adapt this methodology to the steps and tools that are sufficient for its own business, and perhaps gradually reinforce the work with more and more steps and better utilization of the tools. At AM System, we will try to explain the different parts and their purpose, from our perspective. Here we think that you as a reader should be aware that it may differ slightly depending on customer requirements and so on what is solved & defined in which step.

Do you want to read more about how you can work with 8D in AM System?

D0/D1- Create the team and describe the problem.

Often, different roles that are included are defined in the company's procedures, so the basis should be found there. Based on that, the people who will be co-responsible for the task are specified, as well as who is driving the case.

The problem is of course initially described with relevant product & process data. That is, article number, name, batch number, date and perhaps shift or time. Everything that traces the occasion to a specific situation.

Basically, you usually proceed by asking yourself the questions;

• What - What happened when the anomaly was discovered?
• Why - Why is there an anomaly?
• Who - Who discovered the deviation?
• Where - Where was the deviation detected?
• When - When was the anomaly detected?
• How - How was the deviation detected?

A clear problem description is crucial to correctly direct the analysis, so create a simple and clear structure to effectively collect all relevant data at the beginning. Facilitate focus where it happens, when it happens.

D2 - Similar products & processes

In order to have as comprehensive a risk picture as possible for D3, it can be interesting to immediately make an initial analysis of whether the error can occur on similar products and similar processes and where products with a risk of similar errors may be. This could be in the company's own warehouse, at the customer's site, or on the way to the customer.

D3 - Initial analysis

With the aim of gaining an initial understanding of the nature and origin of the deviation, it is common in this step to understand where the failure would have been identified. It could be, for example;

• In the production process and a specific operation
• Already at the supplier
• On the final product
• Before delivery (internal/external)

If you can already have an idea of why the error was not detected in the way the process intended, there are direct lessons to be learned from it.

D4 - Short-term / urgent actions

Short-term urgent actions are taken to quickly get an idea of the spread of the error, confirm which volumes are OK, as well as to put in place clear and robust controls that ensure during the course of the investigation that a repeated error does not slip through. These measures should be in place and documented usually within 24h.

For these measures, it is important that several functions in the company can easily collaborate to locate suspicious material, develop a clear instruction for the control, check the volumes that are suspected and make sure to introduce an extra control if production / operations need to continue.

Activities that create value in this step are easy communication between internal and perhaps external functions, clarity and competence to be able to create and follow instructions, handling of suspicious or incorrect material and being able to quickly confirm what is ok or not. Here, expressions such as positive breakpoint can be mentioned. It can be a date, time, batch number or, preferably, a delivery note number if it is delivered externally.

D5 - Rotor axis analysis

The root cause analysis aims to identify as efficiently as possible the real reason(s) why the problem both occurred and was not detected. In this step, it is advantageous to work cross-functionally, as a process is often planned, executed and followed up by many different functions. These may include process and production engineering, management, maintenance engineers, operators, quality engineers, etc.

With data from risk assessments (FMEA), the team can quickly understand why the process is controlled the way it is and how. Risks have become the process control and the operators' instructions, which should have been followed by functions with proper training, etc.

In the root cause analysis, it can be useful to structure the work by using the tools described earlier. One of the most widely used tools to identify potential causes of a deviation is the Ishikawa diagram, also known as the fishbone diagram. By systematically mapping possible sources of error into categories, it helps the team visualize complex causal relationships.

Working with Ishikawa requires the team to be open and responsive to different perspectives. Each function or department contributes by suggesting possible causes, which are then discussed and evaluated. An important part of the process is to try to disprove the suggested causes by using data, results from previous analyses and experience. Causes that cannot be disproved are subject to deeper investigation through further data collection, experimentation or testing.

An interesting aspect of Ishikawa diagrams is their wide range of application. Although it is particularly popular in the manufacturing industry, it is also used in other industries to improve processes, reduce lead times and increase customer satisfaction. Its simplicity and visual structure make it one of the most useful tools for identifying both direct and underlying causes of problems.

Thus, at the end of the day, one or more potential causes remain. Depending on the complexity of the processes or the level of assurance sought, the next step may include an FTA analysis. In short, it involves the team questioning the remaining causes in a way that identifies how the remaining causes may interact to lead to the original problem.

More about Fault Tree Analysis (FTA)

In a Fault Tree Analysis (FTA ), the team works backwards from the defined fault, called the top event, and breaks it down into possible causes in a structured way. These causes are placed in a hierarchical scheme where each level represents possible sources of failure or combinations of events that may have contributed to the problem.

What makes FTA unique is the use of logic gates such as 'AND' and 'OR' to show how multiple causes must occur simultaneously or individually to trigger the main problem. Causes identified in an Ishikawa diagram can now be analyzed more deeply to understand their dependencies and interactions. For example, a finding from the Ishikawa diagram such as 'Lack of operator training' and 'Faulty machine maintenance' can be shown in the FTA analysis as two separate events that need to occur simultaneously to create a specific fault.

This structured decomposition helps the team to find hidden failures that may have been overlooked in previous analysis steps. It also allows to clearly see which factors are critical to prevent the problem from occurring again. Using FTA as a complement to the Ishikawa diagram ensures that both single causes and combined failure chains are analyzed to eliminate the most critical risks.

Once the team has identified the remaining possible causes from the Ishikawa diagram and mapped their potential interaction through the FTA analysis, the next step is often to conduct a deeper root cause analysis using the 5 Whys method. This tool is used to break down each remaining cause to its true root cause by asking the question "Why?" repeatedly, usually five times or more if necessary.

More about 5 Whys

Although the FTA and the Ishikawa diagram have provided a structured overview of possible causes and their relationships, some causes may still be too general or unclear. By using 5 Whys for each remaining cause, the team can dig deeper to understand why a specific failure occurred. This is particularly useful when there are human factors, maintenance procedures, or operational processes involved - areas where causes often require deeper analysis.

Example:

If one of the identified causes from the FTA analysis is "Lack of operator training", the team can use the 5 Whys to understand why this problem occurred:

1. Why? Operators did not follow the correct procedure.
2. Why? They had not received sufficient training on the new process.
3. Why? No training plan had been implemented after the process change.
4. Why? The division of responsibilities between production and the training department was unclear.
5. Why? No procedures for training follow-up were defined.

Link to previous tools:

From Ishikawa: Lack of operator training was identified under the category "People".

From FTA: Lack of training was logically linked to the fact that "Improper machine maintenance" can happen at the same time, leading to machine stops.

With 5 Why: The real root cause was discovered as "Lack of training follow-up", which can now be addressed by a long-term solution.

5 Why thus ensures that the analysis does not stop at symptoms but reaches the real root cause. This makes it easier to identify effective corrective and preventive actions, which strengthens the whole deviation management process. If a clear answer cannot be established by 5 Why, additional data may need to be collected or more analytical tools used to reach deeper insights.

D6 - Corrective actions

The basis for planning and executing the right corrective actions lies in how well the root cause analysis worked. Actions have by far the best impact over time if they are focused on the real causes of the problem. Of course, depending on the area in which the causes are identified, efforts from different parts of the business will be responsible for carrying out the actions. The root cause analysis and defined actions should be documented in 8Dn within 10 days.

The team creates a clear action plan in D6, where at least one action per identified cause should be included. It is common here to discuss in terms of "Occurance" and "Detection", i.e. actions that both prevent the failure from occurring and/or ensure that it is detected if it occurs.

Actions are planned and executed by the respective responsible function and in the execution it includes both doing the actual task, as well as creating the conditions and communicating the change to the functions it affects. Changes in production often mean updated routines and instructions for employees, who then need education and training. As a basis for these changes, the PFMEA and Control Plans will have been updated, which ensures that lessons learned from the deviation are logged and systematized, thus more likely to be used in the development of similar processes / products in the future.

It is valuable that the work in D6 has a simple and clear structure around who does what and until when, and that it can be easily overseen by the person leading the work.

D7 - Validation of implemented measures

In this step, it must be ensured that the measures introduced work as intended. Validation can of course be done in different ways, based on different data or inputs. In D4, extra controls were created directly in the process, or in the processes, in which the error was identified or risked being present. If you have had an extra control during the 8D work, where errors are still detected, that log can serve as a good input in the validation. From the time the long-term solution has been implemented, no more errors of the error type should be found. The time the process should run or the number of produced items in the process that need to be manufactured varies of course between different operations. The purpose is still the same, to statistically ensure that the process is stable and no longer risks producing the error.

It is valuable to be able to make data-driven decisions based on facts, which means that logging data from the outcome is of great value to those who will validate the measures. Similarly, it is important that there are agreed people/functions to do so based on agreed deadlines. The more data and visual feedback, perhaps in the form of pictures and videos, that can be collected as evidence, the more confident you can be in your decision, as well as demonstrating the progress of the work. Both for those who are involved now, or who in the future will need to go back to the case to understand certain elements.

D8 - Lessons learned, celebrate & close

The purpose of the last step of an 8D is to summarize outcomes, confirm that everything that was agreed to be done is done, as well as to celebrate the completed task with the team. While the latter may sound strange, it is important to actively encourage positive feedback and celebration as a group and as individuals.

As part of the lessons learned in this step, there is value in knowing about and confirming that the lessons learned by the company through the current case have been systematized and included. Examples include updated PFMEA/risk assessments, instructions and procedures, competence updates, basic documentation such as drawings or measurement methods. Customer or supplier relationships have also changed.

Summarizing deviation management - keep in mind that

Structured deviation management is about more than just solving problems - it is a structured way to create long-term value for both the individual and the company. By gathering the right skills early on, the team gains a common focus, creating a clear plan for identifying, analyzing and addressing deviations.

The work is not only reactive but also proactive, as potential problems in similar products and processes are investigated to minimize future risks. If the right root causes are identified through effective tools such as Ishikawa charts and 5-Why, actions can be planned and implemented that actually make a difference.

For the individual, this means a structured way of working where everyone can contribute their expertise, creating a strong problem-solving culture and opportunities for professional development, from something that is actually a problem.

For the company, it leads to sustainable improvements and continuous updating of processes and procedures. It's not just about solving today's problems, but also about learning from them to improve in the future.

At the end of the process, both the individual and the company have evolved - and those successes, along with a stronger team and an improved quality culture, are certainly cause for celebration.

Deviation management according to or in line with the 8D approach is therefore more than a methodology and approach - it is an investment in quality, cooperation and future competitiveness.