Problem Solving Tools

Lean manufacturing has a unique way of solving problems. It does not just look at the effect of the problem and try to cover it with a Band-Aid. Rather, the root cause of the problem is identified and the root cause, as well as all contributing factors, is eliminated from the system, process, or infrastructure to permanently solve the problems.

It is very clear now that we must find out the root causes of the problems before we think about rectifying them in lean manufacturing environments. So, how should we do this? What are the tools available to perform these tasks? Let's look at what problem solving is about. We'll begin by asking the question: "What is a problem?" A good definition of a problem is a variation from a recognized standard. In other words, you need to know how things should be before you can recognize a possible cause for them not being that way. After a problem has been recognized, a formal problem-solving process should be applied.

High performance work teams typically use four problem-solving tools:

• 1. Plan, Do, Check, Act (PDCA)
• 2. 5-Why Analysis
• 3. Ishakawa (Fishbone) Diagram
• 4. Simplified Failure Modes and Effects Analysis (SFMEA)

Plan, Do, Check, Act (PDCA)

The Deming PDCA cycle provides effective guidelines for successful problem solving. The cycle,

a. Plan

• Clearly Define the Problem (P1)
• Collect Evidence of Problem (P2)
• Identification of Impacts or Opportunities (P3)
• Measurement of Problem (P4)
• Measure(s) of Effectiveness (P5)

b. Do

• Generate Possible Causes (D1)
• Broke-Need-Fixing Causes Identified, Worked On (D2)
• Write Action Plan for Cause Remedies (D3)
• Write Experimental Test Plan (D4)
• Resources Identified (D5)
• Revised PDCA Timetable (D6)
• Management Team Review/Approval (D7)

c. Check

• Carry out Action Plan (C1)
• Carry out Experimental Test Plan (C2)
• Analyse Data from Experimental or Action Plan (C3)
• Decisions-Back to Do Stage or Proceed (C4)
• Implementation Plan to Make Change Permanent (C5)
• Force Field on Implementation (C6)
• Management Team Review/Approval (C7)

d. Act

• Carry out Implementation Plan (A1)
• Post-Measure of Effectiveness (A2)
• Analysed Results vs. Team Objectives (A3)
• Team Feedback Gathered (A4)
• Management Team Close-out Meeting (A5)

5-Why Problem Solving

When you have a problem, go to the place where the problem occurred and ask the question "Why" five times. In this way, you will find the root causes of the problem and you can start treating them and rectifying the problem.

5-Why analysis is a technique that doesn't involve data segmentation, hypothesis testing, regression, or other advanced statistical tools, and in many cases can be completed without a data collection plan. By repeatedly asking the question "Why" at least five times, you can peel away the layers of symptoms which can lead to the root cause of a problem.

Ishikawa Diagram

In some cases, a problem can be due to more than one root cause or may have multiple forcing functions that either singularly, or in combination, will result in the problem. The 5-Why process may not provide the ability to address these more complex problems. The pictorial representation of this root cause analysis can be achieved using an Ishikawa or Cause and Effect Diagram. Because of its shape, this process is also called a Fishbone Diagram. This helps people communicate the root cause and the potential contributing factors and/or forcing function in a simple, straightforward graphic format. This method is very clear way of representing the relationship between the root cause of the problem and all the possible factors that may be associated with the problem.

Simplified Failure Modes and Effects Analysis

Simplified Failure Modes and Effects Analysis (SFMEA) is a top-down method of analysing a design and is widely used in industry. In the U.S., automotive companies such as Chrysler, Ford and General Motors require that this type of analysis be carried out. There are many different company and industry standards, but one of the most widely used is the Automotive Industry Action Group (AIAG). Using this standard, you start by considering each component or functional block in the system and how it can fail, referred to as failure modes. You then determine the effect of each failure mode, and the severity on the function of the system. Then you determine the likelihood of occurrence and of detecting the failure. The procedure is to calculate the Risk Priority Number, or RPN, using the formula:

RPN = Severity × Occurrence × Detection

The second stage is to consider corrective actions which can reduce the severity or occurrence or increase detection. Typically, you start with the higher RPN values, which indicate the most severe problems, and work downwards. The RPN is then recalculated after the corrective actions have been determined. The intention is to get the RPN to the lowest value.