Practical Problem Solving
There is no other business tool more important than problem solving. Despite this, there are very few organisations that really takes it seriously and build a culture of solving problems. Problem solving is the key to both improved results and higher engagement of employees.
Practical problem solving (PPS) is perhaps the single most important tool we have at our disposal. This is the one skill, along with standardized work that Toyota invests the most time and effort in when it comes to developing it’s people. Without these two skills there can be no Continous Improvement, no elimination of waste and no reduction in quality problems. There are a variety of methods and concepts in problem solving, but we like the most practical problem solving. Not only because it gives quick results and that Toyota uses it but also because it is simple, logical and really requires no additional structure of the company (unlike more advanced methods such as six sigma). PPS is something everyone should do as part of their daily work. From the CEO down to the shop floor.
PDCA
PDCA (Plan Do Check Act), is central to Lean and the problem-solving mindset. It is the basis of all work carried out. PDCA’s strength comes from its simplicity, whether in problem solving, project management or just general planning.
PDCA is the basis for the practical problem solving we teach. It is also the foundation of project planning and general planning in order to achieve a time-efficient process. PDCA teaches us to make well informed, fact based, decisions and implement quickly - a very central concept for Lean. below we will focus on the PDCA from a problem-solving perspective but as you can read in the Lean leadership and decisions sections you will see that PDCA is applied everywhere.
We usually divide the problem solving process in 7 steps (you can see them in the picture above). Sometimes you can even add a step 0 where we prepare the problem solution. Let's take a closer look at how we get through the different steps when we solve a problem
The problem solving process
Define the problem
The first step is to define what the problem really is. We can not do anything until we know that. Sometimes it is called Gap Analysis, which is not entirely wrong, it's about finding a quantifiable gap. A quantifiable gap in turn requires a standard or target. Otherwise, we have nothing to compare against. If there is no standard then introducing this is the first step of a solution. At times just this is sufficient to resolve the issue. We need to gather as much information as we can about the problem at this stage. The better the data is the easier it will be to quantify the problem. Try to specify the problem in a SMART way (Specific, Measurable, Action-oriented, Realistic and Time bound).
Stakeholder analysis
-
Break down the problem
For us statistics geeks, this is the most enjoyable step in solving the problem. We start by finding the point of cause - where the problem originates from. Here we typically apply the questions of “5W2H” – Where? When? What? Who? Which? How? How many? You will note that when we break down the problem, we do not ask “Why?”. Typical issues here are What shift? Which product? Which machine? What day? What temperature? How much for what? Which types a problem? Was in the process? Was in the machine? Was in business? Repeat on all factories? etc. Sometimes more advanced tools (you can read about it in the DMAIC process) for statistical analysis are required, but you’ll be able to tackle 80% of your problems with those questions and a spread sheet. Once we arrived at a very specific and SMART problem we need to set an equally specific and SMART goal for our problem. You see that we are only now setting a target for ourselves. We can only do this when we have broken the problem down.
Measure and standardise
Before we are done, there are a few things left to do. First, measure and monitor the KPIs to ensure we’ve stopped the problem. We usually test by removing the action and see if the problem occurs again. Important that we control by following both process and KPI. It works like the last step to reflect and standardise. First and foremost, are all standards updated to reflect our improvements? Once that's done, we ask ourselves if there are any similar product or process that can take advantage of what we have learned. Can we replicate the solution? The last thing we do is to celebrate our success and think about the next problem to tackle.
To make life easier, we have of course added a few templates for this. You can find them here below. There are two templates, one simple and one advanced. The simple are usually found in all breast or back pockets of Toyota to fast pick up and structure a problem. The more sophisticated picked up when the problem requires.
Idntifying direct causes
The most common tool used to define direct causes is an “Ishikawa” or “Fish bone” diagram. We use it to think through the possible causes. Sometimes we do it as a brainstorming exercise on the place where the problem happens sometimes we ask someone in the group sit down and make a proposal which we then discuss in a group. The key in this step is not to rule out possible causes. When we are satisfied with our first draft we start verifying any possible direct cause using facts. A bit of a warning. It is often here that we jump to what we believe is the right solution immediately. Again and again. And the problem will not disappear. Weird?! When we have found our direct causes based on the facts we move on to the next step.
5 Why analysis
Here’s how we at reLean think about 5 why analysis. It is also how we were educated on the topic at Toyota;
1. Define the problem (if possible, ask yourself where the problem occurs)
2. Identify direct causes (Make a proper Ishikawa if needed)
3. Ask the question why for every direct cause. Evaluate each why a new Ishikawa, or think at least that any why can branch out in response in Man, Machine, Material, Method (and environment & management whether to be picky)
4. Evaluate each option that appeared in your logic trees with facts (or common sense, depending on how advanced the problem is)
5. Iterate the process for each step the deeper you go (5 whys can be anywhere between 2 to 15 why)
6. When you find the root cause of your problem, ask yourself if you've found the short term (removing the problem for good) or long term (see to that similar problems do not happen again) solution to the root cause of the problem. Both need to be identified and remedied.
Be smart when you make your 5 whys analysis and do not create the entire tree without first verifying the facts of each step and close non-relevant paths directly. "Employee mistake" or similar statements are not acceptable root causes. Never. The principle of the 5 whys is really very simple but it’s still a challenging thing to do. 5 Why is about the art of breaking down a symptom of the real problem - the root cause - by asking questions. Sounds simple in theory, but verifying a root cause or discarding others is a hard thing to do. As humans we are pre-programmed to jumps to conclusions instead of verifying the facts.
Some tips
Test your why trees to wait for the tree and ask the question "therefore" in the other direction.
Continue asking “why” until you can not ask "why" anymore. When the answer that comes back illogical we stop.
Find both solutions. There are always both short-term and long-term responses to each root cause. Sometimes they are the same, but they are there.
-
Structure - Problem solving is about structure, ensure that you have a structured template to work on your 5 why analysis.
Develop and implement countermeasures
When we have identified our Root Cause it's time to develop some kind of solution to eliminate or mitigate them. There are always two solutions to every problem. A short-term and a long term solution. Examples of short-term solutions are a jig or poka yoke that makes us unable to assemble two things the wrong way around. The short-term measures ensure that a problem does not continue and we can take away our containment without any risk to the customer. The long-term measures, however often point back to our sourcing, product design, development processes or our management methodology. Here we need to strengthen our processes and methods so that we do not repeat the same error as the just solved. This solves the real root cause that builds up the company in the long term. Now we create clear plans and responsibility for all the actions and rapidly implement all the measures.
Protect the costumer and contain the problem
Once we figured out what the problem is, we sometimes need to put containment in place to stop the problem from affecting our customers. If we put it in place then one of our goals with the problem solution will be to remove the containment again. Far too many times the problem solution stops at this stage which results in layer upon layer of manual inspections so as not to "leak" through problems instead of actually solving them.
Identifying root- causes
There are several ways to carry this out, the most common tend to be 5 why, as described below. You can also use the factor analysis for more math problem formulations. Whatever the method, it is important to be methodical and stick to the facts. Causes can easily turn into excuses and then you will have to start over. If it happens it is usually because it is not factual.
Logic trees and hypothesis trees
Structure is among the most important thing in leadership as it is in problem solving. It helps us to structure thoughts, ideas, communication and strategies. It allows us to ensure that we think of everything and not miss anything. It allows us to easily involve others in our thoughts and use the forces of teamwork.
A great way to structure things are using logic and hypothesis trees. Building these are one of the first things you learn at top consulting firms such as McKinsey & Company. The structure of the different tree types themselves are the same, but the use is slightly different between logic and hypothesis tree. The easiest way to explain it is using an example. We can solve the problem in two ways depending on the conditions we have:
Logic-driven. Logic-driven problem solving is like a math problem. Each part of the problem is divided into sub-sections which in turn are divided into further parts. We think of all possible options. In this way we create a holistic tree that cover all the possible problem causes.
Hypothesis-driven. Hypothesis-driven problem solving is different in that we have an idea of what the solution might be. We add branches on the tree in the same way as in logic-driven problem solving, but instead of taking all the solutions we say what we most probably think the problem is (as we verify the hypothesis and move on, or starts).
Problem: I’m 5 kilograms overweight (un-Lean) and my wife (and thus me) want them to disappear for the summer.
A logic-driven tree had explored all the possible reasons that I weigh 5 kg too much and started asking the question "how do I lose 5 kg for the summer?". We had explored all the possibilities and then tried to verify which ones will actually have an effect.
A Hypothesis Tree would rather attack the challenge of a hypothesis; "The only long-term healthy way to lose 5 kg for the summer is to eat healthily and exercise more". Since this had been broken up into a couple of categories that I suspect applying myself had meant "stop eating unnecessary snacks on the sofa", "max one after work per week" and "running at least 3 times a week."
There we have the difference between logic and hypothesis tree. Use our template and create your own logic and hypothesis trees.
Statistical tools
There are several advanced statistical tools that are frequently used in 6 sigma processes, but we also use as needed. It is unnecessary to boil the ocean for a cup of tea and use them all the time as they are time consuming and advanced tools, but when they are really needed to break down a problem, they are really good!
Regression Analysis
Regression analysis is an important tool in Six Sigma's DMAIC process, but also widely used in quality engineering. The aim of regression analysis is to interpret a number of data points to identify trends or patterns. For the more advanced applications an app called minitab is widely used but in most cases it is sufficient to open excel and plot two values against each other in a common chart. It usually goes a long way in helping us to draw conclusions.
Process capability index
According to all the mechanical and quality technical standards a process should be Capable, repeatable and reliable. It simply means that the machine should be capable to do the right thing, having the ability to always produce the same outcome and be so reliable that it can do it all the time. The Process capability index is a tool used to assess how capable a process is. Process capability index is a widely used tool in fields such as Six Sigma and quality control.
SIPOC
SIPOC is a structured way of describing an end-to-end process in a simple and comprehensive way. SIPOC stands for Supplier, Input, high-level Process, Outputs and Customers. SIPOC is an important part of the DMAIC process in the world of six sigma.
7QC tools
Within the area of you often hear people refer to the 7 Quality Tools, which are used to identify and classify quality problems. These tools are very useful and strongly connected with practical problem solving, especially when we break down the problem according 5W2H.
Pareto - An excellent tool to prioritise issues and actions
Histogram - Applicable when working on tolerance problems, process capability etc.
Control charts (SPS) - Applicable to more advanced problems where we want to identify a process outside its operating limits or tolerances
Regressionsanalys - Often more useful that we thing. Great tool to identify trends or behaviours of two or more parameters
Grafer - Data can be visualised in many ways. It's important to be able to work with many types of graphs that can help us identify patterns, deviations, trends and gaps
Fish bone analysis - Also known as "Ishikawa" is a cause and effect analys that allows us to structure potential problem causes
Check sheets - A simple way of recording information, it gives us a vast amount of information on a problem and it can easily be presented in various ways