How To Do Effective 8 Discipline(8D) Problem Solving

The problem is not the problem. The problem is your attitude about the problem-Captain Jack Sparrow

The purpose of this article is to explain how each of the 8 steps can be done effectively whilst involving the right cross functional teams all through the 8D (8 Discipline) problem solving cycle. 8D problem solving methodology is a scientific way of thinking the purpose of which is to prevent the recurrence of the problem due to the same root-cause by eliminating the true root-cause.?The root-causes don’t materialize. Instead they exist in organizations ?like ticking timebombs if they are not designed out from the processes & products. It’s super important to follow these 8 disciplines for an effective 8D problem solving cycle. The underlying ?thinking behind 8D problem solving is the PDCA (Plan, Do, Check & Act) thinking. The 8D problem solving methodology was developed by Ford Motor Company. Let’s start with the first discipline of forming a team. ?

1D: Form a team

Even before ?forming the right team , it’s important that a stopping culture is developed within the organization within which when a problem happens the ideal behavior expected from the operators is to immediately stop the production line and highlight the problem (Abnormality) to the Team Leader. The purpose of this practice is to ensure that known facts from Gemba (Source of real work) which are related to the problem are preserved. These known facts are critically important to brushing away any assumptions on the problem and formulating an accurate & detailed problem definition only based on absolute known facts from Gemba. This stopping culture also makes the root-cause investigation effective & efficient. Once the problem (Abnormality) is highlighted to the Team Leader, it then becomes TL’s responsibility to immediately assemble the right team required to define the problem as soon as possible with a sense of urgency. For the most part operator & Team Leader can define the problem without the help of SMEs (Subject Matter Experts) because the problem is defined at the POD (Point Of Discovery) which is the downstream operation where the problem is observed by the operator. The right team should be assembled at Gemba where they can go see the actual problem for themselves (Genchi Genbutsu) before defining the problem.

2D: Define & describe the problem

Once the right team is assembled by the TL, an accurate & detailed problem statement should be formulated by the team. The problem should be defined at the POD (Point Of Discovery) which is the downstream operation where the problem is observed by the operator. The purpose of defining this way is to ensure that problem is defined only based on known facts from Gemba without any assumptions. Another important thing that should be done before defining the problem is to see if the problem observed can be broken down to the prioritized problem based on for example safety, financial impact, shift, location of the defect, type of the defect and any other appropriate factors. If this is the case data should be collected for a period long enough to break down the problem to the prioritized problem. If the problem can be broken down to the prioritized problem, the problem definition should be for the prioritized problem. The purpose behind breaking down to the prioritized problem well enough is to minimize the chance of having to deal with multiple root causes. If the problem cannot be broken down to the prioritized problem, then the problem definition should be for the problem observed. Depending on the situation, the problem is defined in terms of 5Ws & 2Hs as follows.

5Ws

?1.?????Who found the problem-This is the person who discovered/saw the problem at first on the production line. Most of the time, this person is the operator working on the production line. Putting down the name of the operator on the flipchart rather than just mentioning operator shows that the organization doesn’t have a blame culture and congratulates people for highlighting problems/abnormalities.

?2.?????What was found-This is where the problem observed is mentioned specifically based on facts from Gemba (Source of real work).

?3.?????Where was the problem found-This is where the specific location of the problem is mentioned. Don’t be too broad on the location.

?4.??????When was the problem found- This refers to for example the shift & the time when the problem happened.

?5.?????Why is it a problem-This refers to why it’s a problem from the customer’s perspective. The customer could be internal or external. For example it could be a problem due to product quality being affected and/or DIFOT (Delivery In Full & On Time being affected) due to unplanned downtime caused by the problem which could be a mechanical breakdown.

2Hs

?1.?????How was the problem found-This refers to the event during which the problem was observed by the person who found it. For example it could be that the problem was found during a routine test done on the production line.

?2.?????How often-This refers to the number of times the problem has happened in the past. For example, how many times the problem has happened over the last shift, week, month or year. It’s important not to spend too much time determining the frequency of occurrence of the problem. Just make do with the data already available. If there’s no data collected, ask the operators how often the problem has happened. It makes sense to be roughly right rather than precisely wrong. The goal of problem-solving is to prevent the recurrence of the problem due to the same root-cause by eliminating the true root-cause.

After the problem is defined in detail & accurately the following question needs to be answered by every member of the team that was formed to define the problem.

Q: Do we all agree that the problem is defined only based on absolute known facts from Gemba and not based on assumptions?

If the answer to the question is YES only we can move onto the 3rd step of the problem solving cycle. If not we need to revisit the problem definition & further investigate facts.

??3D: Implement & verify interim containment actions

The purpose of the 3rd discipline is to isolate the problem from the internal/external customer until the best permanent counter-measure/s are implemented & both the process and results(effectiveness of permanent counter-measure/s) are validated. It’s important to remember that this step doesn’t technically solve the problem.

Before implementing containment action, we need to assess if the risk of not containing the problem is acceptable. If the risk is not acceptable, containment action should be implemented immediately. The next question is how to contain if we decide to do so. It’s important to assess whether containment is required only on the production line where the problem was observed or on all similar lines. The purpose of containment is two fold. The containment actions remove the defects which already exist in the system and should also prevent defects from passing on to the customer until permanent corrective actions are implemented & validated. What type of containment actions should be implemented depends on the goal of containment. For example if it’s a critical defect for the customer and therefore no defects should be passed onto the customer it makes sense to do 100% inspection of all products made before shipping to the customer. Then it’s important to implement the best containment to prevent the future defects from passing onto the customer. An equally important step in implementing containment is to validate if the containment is effective and working so that the defect is detected before it can pass on to the customer. Sometimes if the defective product is already in the market, a product recall may be necessary. Once the best interim-containment action is agreed upon, it’s important to decide the person responsible for doing containment, how often it should be done, how to sustain & for how long it should be done. ?

It’s the best practice that the interim containment action should be in place until the permanent corrective actions are implemented & validated. It’s also my observation that sometimes there’s a tendency not to remove the interim containment action even after the permanent corrective actions are implemented & validated. Another commonly observed practice is that after implementing interim containment actions they become the permanent corrective actions with no further effort being made to investigate the true root-cause.

Now that interim containment is implemented & validated, the next discipline is determine & verify?root-cause/s.

4D: ?Determine, identify & verify root-causes

Before proceeding with the 4th discipline it’s important to ensure that the right cross functional team is involved in the root-cause investigation. Before the true root-cause is investigated an important step has to be performed. We need to first get to the Point Of Occurrence (POO) of the prioritized problem starting from the Point Of Discovery(POD).?The Point of Occurrence is the upstream process where the problem actually occurs in the process. In more specific terms it’s the step in the standardized work or the process step performed by the machine that fails to cause the actual problem. We need to go to Gemba & go back upstream starting from the Point Of Discovery observing process by process looking for the Point of Occurrence where the problem actually occurs. Once you find and confirm the POO for the prioritized problem then we need to start asking why starting from the POO until the root-cause is found. The best practice here is to see if you can get to the root-cause with a simple 5Why analysis by starting to ask why from the POO. Consider doing a fishbone only if the root-cause cannot be found from a simple 5 Why analysis. If it’s decided to do a fishbone, the fishbone should be done at the POO. ?A structured brainstorming session should be done with the right team to identify all high level potential causes under Man, Method, Material and Machine(4Ms). Once the potential high level causes are identified, the ones that can be ruled out based on further investigation should be ruled out. Then the 5 why should be performed on the remaining high level cause/s that have been validated to be true. After doing the 5Why analysis, the therefore test should be done to establish the logical relationship between cause & effect.

?Once the true root-cause is found, the next step is to validate/prove the root-cause. The definitive test for validating the root-cause is to see if we can turn the problem on and off by introducing the root-cause and by removing the root-cause respectively. If the identified root-cause passes both turn on and turn off tests the root-cause is validated and we know that we have found the true root-cause. It’s important to note that if the problem is not broken down well enough to the prioritized problem there’s a high chance that you will end up with multiple root-causes. If you are having multiple root-causes, it’s worthwhile going back and seeing if the problem is broken down well enough.

?Once the true root-cause is found, we move on to the next discipline which is select & verify permanent corrective actions.

?5D: ?Select & verify permanent corrective actions

?Just like the previous step, it’s important to ensure that the right cross functional team is involved in selecting & verifying the permanent corrective actions. In this step, we do a structured brainstorming session with the right team to identify and list as many possible permanent corrective actions as possible which address the root-cause. The purpose of the brainstorming session is to get people to be thinking critically & be innovative in proposing permanent corrective actions which address the root-cause. It’s the best practice list low cost simple error-proof (Poka-Yoke) corrective actions first which can eliminate the root-cause and prevent the problem from recurring. If the root-cause cannot be eliminated, the next type of corrective actions to think would be the ones that can prevent the root-causes from causing the problem. If this cannot be done think of immediate detection of problems through self-inspection by the machine leading to automatic stopping of the machine as soon as the defect is detected which is called JIDOKA (In-station quality) in Toyota Production System. If this is not worth doing because the cost involved is not benefit justified, think of other corrective actions that can significantly reduce the occurrence of the problem.

Once the list of permanent corrective actions are listed the next step is to identify a set of criteria against which each corrective action should be rated based on a rating scale of 1-10 or 1-5. The wider the rating scale, the more the granularity is in rating corrective actions. Some of the commonly used criteria to rate corrective actions are effectiveness, flexibility, safety, quality impact, impact on other processes, cost and effort. There should be flexibility in choosing the right rating criteria which should be selected and agreed upon by the team before rating the proposed corrective actions. ?After the rating exercise, the corrective action/s with the highest overall rating/s are selected as the best permanent corrective action/s. Afterwards the best permanent corrective action/s should be verified through a planned trial. During the trial phase, usually there will be multiple PDCA(Plan, DO, Check & Act) cycles as we learn from each cycle to improve the selected permanent corrective action/s. Practice of the four steps of Toyota improvement KATA & coaching KATA are valuable in guiding the thinking through these PDCA cycles.

?6D: Implement & validate permanent corrective actions

Once the best permanent corrective action/s, are selected and verified through a trial, the next discipline is to actually implement & validate permanent corrective actions. Before implementing permanent corrective actions it’s important to have a detailed implementation action plan done with 3Ws (What, Who & When). Once the detailed action plan is completed & agreed, the next step is to implement the action plan. An important ideal behavior in implementing the action plan is to involve & engage the operator who found the problem and highlighted to the Team Leader. This ?engagement helps operator feel inspired. After the implementation of the action plan the next step is to monitor the results and the new process at Gemba for a long enough period to validate the effectiveness of the permanent corrective action/s implemented. How long is long enough has to be agreed by the cross functional team.

Once the effectiveness is validated and the permanent corrective action/s implemented have either eliminated the problem or significantly reduced the occurrence of the problem, the next step is to share & standardize the successful permanent corrective action/s to prevent similar occurrences.

?7D: Prevent similar occurrences

Just like all the other steps, the first thing is to form the right team to perform the 7th discipline.

Once the right team is formed, the next step is to have a discussion within the team and identify the similar areas of other production lines where the successful permanent corrective action/s can be shared & standardized (Yokoten). Then there should be a detailed action plan with responsibilities and expected completion dates to rollout the successful permanent corrective action/s ?. It’s not uncommon in a production environment to have slight differences between the production lines even when they are similar for the most part. In such circumstances, the production lines might have to be modified to implement the successful permanent corrective action/s.

After the successful permanent corrective action/s are rolled out to similar areas, we can move onto the last discipline of problem solving.

8D: Congratulate your team

Once the 8D problem solving cycle is completed it’s important to congratulate & recognize the cross functional team involved in solving the problem. One of the many ways of doing is to visually display the completed 8D problem solving A3 document with the photos of the people involved. It’s important to display this in a place where operators & leaders can see so that leaders during their Leadership Gemba walks can go and congratulate the people involved.

?In terms of managing the total 8D problem solving process, it’s best to have the Team Leader facilitating the 8D problem solving cycle as it’s Team Leaders’ responsibility to solve problems with operators because Team Leaders own the production lines and therefore they need to take the ownership of the problems on the line. Problem solving should be an important part of the Leader Standard Work(LSW) of the Team Leaders which is an important element of Lean Leadership. This also gives the opportunity for Team Leaders to coach operators for development as people development is an important responsibility within the role of Team Leaders.

?

?

?