The 8D is a well-known problem-solving method used in production. The purpose of this technique is, to identify the root cause of the process deviation, then eliminating it, assuring a safe and stable process. An 8D report protects the customer, for receiving parts in the future with quality issues, assuring high-quality products.
An 8D Report is a very common tool in quality management because digging deep into one problem, always other details will come to light, like organizational, management, logistics, or other problems.
In most of the cases, the report is required by external customers in the case of the appearance of a complaint. However, it’s also recommended for internal complaints, when a problem occurs in production and the root cause can’t be easily identified. In this case, the customer with quality issues will be another department.
In this method exists 8 main steps, and these are the following:
D1 – Establishing Problem Solving Team
Task:
- Select team members
Action:
- Nominate members with appropriate skills based on the problem description
Target:
- The Team structure is confirmed and responsibilities among the team members are assigned
D2 – Problem Description
Key question: Has the fundamental (real) problem been identified and understood?
Task:
- Collect information, data, facts, and figures
- Describe the problem as accurately as possible giving quantitative details (facts, figures, dates, effect on the customer)
Action:
- Go to Gemba walk
- Get samples (good/ failed parts)
- Evaluate objective data
- Visualize facts (photos, drawings, sketches…)
- Analyze the object by involving specialists
- Timeline
- Describe flow characteristics (process flow, product life cycle, logistical flow, value stream)
- Analyze design & function, functional block diagram
- Answer the questions to collect all the required information (What? Where? When? Who? How many?)
Target:
- The precise description of the fundamental problem, based on facts only
Examples:
- Pareto analysis concerning all customers built up over time
- Number of rejected parts corresponding to the production period
- Specific events that occurred (shift change, maintenance/setting in manufacturing)
- Effect on the end customer (loss of some functions, complete product break-down)
D3 – Containment Actions
Key question: Has the customer been protected from using defective products?
Task:
- Determine the most suitable containment actions
Action:
- Safeguard the situation by containment actions, to prevent a reoccurrence of the problem at the customer
- Containment actions, therefore, serve only as a safeguard and often bear no relation to the cause of the problem
- Develop a schedule for implementing the containment actions
- Cost considerations should pay little or no part in the initial response
- Assess the effectiveness of the measures
Target:
- Support to the customer and implementation of containment actions as quickly as possible
- Containment actions must be replaced by corrective actions (D5-D6)
Examples:
- Customers to be informed about: production (follow-up shifts, other production lines/plants), warehouses, original equipment manufacturer, the end customer
- Containment actions are for example: sorting actions or warehouse blocking, build up for firewalls, fast design review by development, statistical analysis (plant, 0 km, field)
- Efficiency check by sorting of product lots with known defect rate, confirmation of the stability of this check over time (especially shift end in case of human visual control)
D4 – Cause and Effect Analysis
Key question:
- Has the Root Cause been established?
- Why did our processes not identify the defective part?
Task:
- Determine technical root cause (TRC) and managerial root cause (MRC)
Action:
- Identify relevant functions, cause and effect relationships and compare target and the actual state
- Derive all possible causes from these considerations
- Apply 5WHY questioning technique to determine and verify the casual functional relation (TRC)
- Provide a risk assessment which includes severity, probability, and estimation of its existent
- Identify the managerial root causes (MRC) which causes the technical root cause
Target:
- The technical and managerial root cause is confirmed
Examples:
- Reproduction of the incident can be validated, for example through simulation or testing
- Check if the defect was latent and could have been activated internally, or if external parameters are needed especially regarding customer interface
- The risk assessment includes the severity of the problem, the probability of occurring and detection, and on the potential extent of loss
Cause and Effect Analysis
- Search for the technical and managerial root cause (TRC, MRC)
- Analyze whether there are one or more root causes to be considered in connection with the problem
- The analysis must be supported by appropriate procedures and statistical evaluations (Process flow diagram, Cause-and-effect diagram, Pareto diagram, etc.)
- It must be possible to “switch” the problem on and off by “switching” the root cause on and off
- The root causes must be verified by means of appropriate experiments and test
- The root causes of a problem are always product- or process-related and can always be justified
- It is important not to accept an “overhasty solution” but instead to continue questioning: 5 WHY???
- If the root cause has genuinely been identified, it will be possible to “switch” the defect on and off by alternating use of defective and error-free components
D5 – Defining Corrective Actions and Proving Effectiveness
Key questions:
- Is the problem eradicated? (D5/D6)
- Can the problem be detected with certainty? (D5/D6)
Task:
- Develop and evaluate “optimum” corrective actions for technical and managerial root cause
Action:
- Define potential corrective actions to eliminate the root causes
- Consider all corrective actions that can eliminate the problem
- Perform theoretical and/or practical examination of the measures, in order to prove the effectiveness and prevent unexpected secondary effects – Don’t create new problems!
- Determine and confirm optimum corrective actions
- Determine and release an action plan with introduction timing and responsibilities
- Ask “Why is the defined measure effective?”
Target:
- Corrective Actions with effectiveness evidence are agreed
Examples (D5/D6):
- Photos, sketches, tests, simulations, etc.
- Firewalls do not catch defective parts anymore after implementation of corrective actions
- In case of defect types that cannot be erased completely, but are approved of in a specified extent, a specific action on a singular event is not requested
- A theoretical representation of the changed process sequence is possible using a flow chart
- The decision-making process can also be changed (rules for a strategic override, management release)
- While protecting the manufacturing flow via Poka-Yoke, it must be assessed whether test or controls have become redundant (for example, visual check, sensor control)
D6 – Implementing Corrective Actions & Tracking Effectiveness
Task:
- Implement an action plan to introduce corrective actions for technical and managerial root causes
Action:
- Implement previously selected Corrective Actions
- Validate effectiveness after implementing and ensure that there are no negative consequences, monitor process internally as well as the process at the customer
- Document results
- Decide about continuing containment actions internally and at the customer
Target:
- Corrective Actions with confirmed effectiveness are established
- Containment actions from D3 are removed
D7 – Establishing Preventive Actions
Key question: Is the problem eradicated (even somewhere else)?
Task:
- Establish preventive actions to avoid the occurrence of comparable problems in other business or production processes and products
Actions:
- Ensure there is no risk of reoccurrence by adapting the monitoring systems for the processes and all affected procedural guidelines (FMEA, Control Plan, drawings, inspection plans, procedures, test and work instructions, design rules, training)
Target:
- Updated standards (QM-systems, design rules, work instructions, etc.) are released
- Experiences are exchanged (Lessons Learned)
Examples:
- Failure Mode and Effect Analysis (FMEA), Fault Tree Analysis (FTA), Control Plan, drawings, development/design guidelines, test plans
- New knowledge should be readily stored in a Lessons Learned database
- Change/ adjustment of products/ processes in areas not directly affected
D8 – Final Meeting
Task:
- Conduct the final meeting of the 8D team
- All actions and their verification are finalized
Action:
- Conduct a critical 8D evaluation of all steps and actions during the concluding discussion
- Close officially the 8D report
- Combined efforts by the team are acknowledged by supervisors and praised accordingly
- Inform the customer of the conclusion and sent the 8D report, signed by those responsible
- Archive the completed 8D report
Target:
- 8D activities related to this problem are finally concluded
As support in your 8D journey, please feel free and download the template for 8D and a practical example of how this document really works:
REIV 