The reason the dictionary definition of problem solving as the process of finding solutions to difficult or complex issues is appealing to consultants and continuous improvement professionals is because it has the word process in the definition. Problem solving is just that, a process. Just like any process it is a group of logical, sequential steps that need to be followed in order to come to a conclusion.
Sounds simple enough but for some reason we get lost using this simple concept at all levels of the organization in any business and every industry. We, as teachers, consultants, managers and executives seem to always botch this elementary process. Now it is understood that problems can be simple or complex, but the approach and process are the same. The only difference is the tool being used or misused in a lot of cases. In this section, we will discuss some of the different tools and their ideal applications. We will also discuss how they can be applied appropriately and some of the mistakes that are commonly made when applying these tools.
So let’s ask ourselves first what is the right problem solving method to use when we have a problem within an organization? Well, since we are asking questions what caused the need to solve a problem? Is it a missed METRIC, crisis, accident, poor customer satisfaction, etc.? Does solving this problem have a benefit that can be realized? Can you measure this realization? Where can you collect the information from? If you can collect information is it repeatable, reproducible, reliable and relevant? If you notice I just asked quite a few questions and we haven’t even started solving a problem yet, which brings me to the very first step in solving a problem. No matter which tool you are going to use, with any method. It is your problem statement.
You cannot even imagine how many times I have been in a room with many very intelligent individuals at all levels of the organization and have struggled to come up with a clear and true problem statement. There are many reasons why this happens. Maybe because often smart people know the answer so we think, which becomes a part of the statement. Sometimes it is hard to associate the problem with a measure, which brings me to another point if you cannot measure it you cannot show improvement. If it is not measurable by any means then you more than likely shouldn’t be solving this problem because you cannot tie its impact to the customer or the organization. So in saying that, let’s take a look at the elements of a sound problem statement.
Wow, looking at it there is a lot to a problem statement hence the difficulty sometimes in writing a proper one. So we have a problem statement what’s next?
So you have identified your project. You have a solid problem statement with a defined measurable so it’s time to assemble your team. This sounds simple enough right? Too often when putting together a team charter we only include those who were close to the problem. When in fact we should include everyone that is involved in the process. Below is an example of a process map (swim lane) used to show labor times in operations for an actuation shop. As you can see there are other groups that are linked to the process. Ensure you include someone from each functional group.
The team charter should always in include the following.
So you have assembled the team. You have a defined measurable problem statement and you understand the impact to the business and the customer. So it’s time to find the root cause to the problem and mistake proof it (Poka Yoke).
The question comes up what tool should we use to solve the problem? This is an area where we tend to get lost and often lazy. Quiet often when I review an A3 or Root Cause Analysis (RCA) and the only tools used repeatedly are a fishbone and 5 why (which will be defined and described). These are great tools but are used in particular instances. You put a lot of thought and effort already to get the team organized and set up. So it makes sense to put the extra thought in using the appropriate tool. It’s like pushing really hard in practice and not giving it your all during the game. So don’t loose track and follow the steps. First we have to understand the data that is front of us and then we can select the correct tool.
Before we select a tool we need to understand what type of data we are collecting. There are two types of date attribute and variable.
Below is an example to help you better understand.
Once you understand the type of information you have available it will assist you in selecting the tool that you may apply to find the root cause and correct the problem. So let look at some different tools that we can apply.
Selecting the tool based on availability of data is where we often get lost. Use the slide above for reference.
Often called “Ishikawa diagrams” or “fish-bone diagrams” are useful for categorizing ideas. This tool could be used to group ideas generated during brainstorming and guide the group as to areas that should be considered.
In our example, the effect we are investigating is ‘late bids 50% of the time’, which is noted in the box on the right side of the diagram.
Potential causes have been brainstormed and recorded in the most applicable category, separated as different legs, or ‘bones’, on the diagram. Each of the diagram legs may in turn have multiple legs that sub-divide even further. The category labels noted are typical, but may vary slightly from team to team.
As with brainstorming, nominal group technique can be utilized to determine the group’s recommended priority for more investigation. Ideally the team would have some data that could support this group opinion. In this example the team has down-selected to two potential causes. This is a great tool but should not be used to solve every problem. Also I often see fish bone’s (when organizations use the original TPS 4M method) missing two bones measurement and environment. These are very important factors that can help you identify the root cause and should never be left out.
This is a great simple tool to help us ask questions. I do see this tool misused quite a bit. This is not to be used for complex problems. Five-why diagrams are a visual representation of that thinking. Using one of the primary potential causes identified in the earlier cause and effect diagram, the team uses a questioning strategy to drive deeper toward potential root causes. In this example they begin with the question of “Why are bids only late at month end?” and continues asking why until they reach an answer outside their control.
The questioning strategy can, and often needs to, go beyond five levels. It may also split into multiple answers that creates multiple questioning trees. It is also possible that a stopping point will occur before five whys are reached. Any of these scenarios is acceptable as long as the result is a controllable potential cause that the team can investigate and correct.
One of these shows the interrelationships and logical hierarchy of many conditions or potential causes. Some simple fault tree methods look for specific actions and conditions occurring at the same point in time that may be causing a failure when they interact.
Note that the very first split in the fault tree is between the measurement system and the data that indicates a problem. In this example the measurement system was validated and ruled out as a contributing cause of variation.
As each layer of the tree is built, data must be presented that validates any conclusion. Unlike brainstorming, this technique is designed to organize the results of analysis that are proven through data and testing.
You will also notice that several of the trees point back to the same issue of end-of-month load, which has been found to be related to an inadequately scheduled shared resource at an earlier process.
These are often used for specific failure events, like accidents, so that contributing events can be organized in sequence. In this example, the investigating team found a series of actions preceded an accidental collision of a forklift with a maintenance technician who was on a ladder doing repairs.
Each of the preceding events can be investigated and its particular contributing conditions documented. These, in turn, can be investigated further until controllable conditions and actions are found. Human factors conditions such as ‘didn’t follow instruction’ must be investigated until the system or process failure that allowed the human failure is identified.
If a human factor failure has the potential impact of contributing to an accident or product reject, the process and system should be mistake-proofed to mitigate the potential for the failure.
Events trees are very useful to get a good picture of the system as a whole. It is also a good chance to get the entire team involved to gather their input.
Convergent problem solving is designed to quickly eliminate potential causes based on logical splits of data. If you were asked to guess a card chosen at random from a deck of 52 playing cards, could you do it in six questions? Yes, if you employed a strategy to eliminate 50% of the options with each question. Convergent problems solving employs the same strategy. Shainin Red X is a widely used convergent problem solving methodology.
The second principle of convergent methods recognizes that all inputs are not equal contributors to the primary failure. Focusing efforts on identifying the controllable condition with the greatest influence on the failure will most quickly produce a solution that prevents recurrence of the failure.
So remember these are tools not methodologies. A methodology would be Lean, Six Sigma, Operational Excellence, Theory of Constraints, etc. (which I will surely cover in detail in another post to explain benefits and opportunities) It is always a good idea to be familiar with as many tools as possible. This will allow you to be flexible in your approach to finding the root cause. The key is to know your source of data, type of data, and to use the correct tool relating to the data you have available.
So you have identified the root cause of your problem. Now it is time to take action. It is important that everyone understands that the opportunity lies in the broken process. It is not people that creates a defect it is a process. In saying that how do we fix a process? Well first we need to find a solution to the problem. Then verify that solution!
Once a root cause candidate is identified it must be tested. Testing means that you can reproduce the failure by introducing the suspected cause and eliminate the failure by removing the cause. In much the same way as a light is controlled by a switch you should be able to ‘turn the problem on and off’ if you have truly found the primary root cause condition.
Once the root cause has been validated the problem solving team is ready to identify potential mistake proofing solutions that will control or eliminate it.
To develop a mistake proofing mindset we must understand the difference between errors and defects. Defects are results, errors are the cause of these results. In our example, slipping is the error, the injury he sustained is the result or the defect.
To take full advantage of mistake proofing, strive for prevention at the source, rather than defect detection. Prevention focuses on eliminating variation of the inputs and in the process that would cause the defect. We must implement control in the process to eliminate the error which causes the defect.
Detection focuses on output inspection to identify the defect after it has already been created. The result is rework or scrap of the outputs if there is a defect.
When developing mistake proofing solutions, involve the employees who actually perform the work. Not only will they have valuable input that could result in a robust mistake proofing solution, their involvement is likely to ensure that the solution is supported by team members.
We always strive for solutions that result in the complete elimination of the error. When that is not possible we resort to less effective, but still viable, mistake proofing options. The Value Driven Approach uses a three-tier methodology to describe mistake proofing based upon its effectiveness.
Level one mistake proofing prevents an error from occurring. In the example shown, it is impossible for the bus to enter the path of the train because the bridge provides a level one mistake proof against collision. In our work place, this may be a fixture that is modified to prevent a part from being loaded incorrectly or software that will not allow the next screen to load until all necessary information is complete in the first screen.
Level two mistake proofing solutions detect the error during the process and alerts the process of the potential for an escape. The railroad signal and crossing arm alerts of the coming train and creates a barrier. The vehicle could go around or ignore the alarm, so this mistake proof does not guarantee a defect will be prevented. Personal protection equipment that guards against injury is an example of this as well.
Level three mistake proofing informs that an error is possible or detects an error after it is produced but before it escapes to the customer. The railroad crossing sign is posted, but it is possible for the sign to go unnoticed and an accident to occur. Standard work may instruct the employee to check a product or service before moving it to the next operation but it does not guarantee that an error will not be produced.
Mistake proofing solutions should be validated ensuring that it controls the error and does not cause other problems or errors in the process.
After mistake proofing the process we then need to ensure that our mistake proof works. There are many ways that we can do this. This is a whole other topic in itself. Setting up a system to understand when your processes fail and how to visually see the fundamental breakdown of that process is imperative. It is key that we continuously monitor the changes that we make to our processes and tie them to METRICS so we can measure improvement.