Rather
frequently, companies – notably management – demand swift action when facing a
problem. Well, there is nothing wrong with a bias for action but what often
results is “cutting corners” in the rank and file. Finding the best solutions
starts with having a structured approach to problem solving.
Root cause
analysis is a fact-based methodology. Many of the problem solving tools are
similar. 5Whys, Ishikawa Fish-bones, 8Ds for automotive, A3 for Lean, PDCA,
DMAIC for Six sigma….All “logically” based fact systems and follow how the
basic "instinctive" brain works, you set a goal, brain storm ideas,
evaluate it, you do it, and see whether it works. The difference is the level
of complexity. This is why PDCA is a cycle, in every turn you can understand
different parts of the problem. The more complicated the problem or the
improvement, the more you need to repeat the cycle.
Step 1:
Stabilize the Process
When impactful
problems manifest, they cause immediate pain and noise within the organization,
which then causes great pressure to “do something” in response. The correct
action here is stabilization. Stabilizing a system does not mean getting it
working properly. Instead, the goal is to get the system to work at the best
function it is currently capable of.
Another goal of
stabilization is to keep the problem contained, i.e. to keep the problem from
getting worse, or at least minimize its rate of degradation. Proper
stabilization happens within the existing operating patterns, meaning a known
activity that the team has documented and practiced. Stabilization is not the
place for innovation or extensive analysis. The phrase “I have an idea… we
could try” often signals problematic departure from stabilization activities.
Brainstorming has its place in problem resolution, but not in the stabilization
phase. Stabilize first!
Step 2:
Identify the Root Cause
Often a problem
is hard because we are unsure what we are being asked, or asking ourselves, to
do. Poorly defined problems rarely lead to quick “ah-has!” Spending time to
understand the problem is a neglected part of the problem solving process.
Typically, there are many strategies for demystification.
Asking why 5
times: “the 5 Whys”, is a simple but powerful tool to use with any problem
solving activity. It’s a technique to help you get past the symptoms of a
problem, and to find its root causes. Simply ask the question “why” up to five
times.
Taiichi
Ohno gave this example about a machine that stopped working (Ohno 1988, p. 17):
1. Why did the machine stop?
There was an overload and the fuse blew.
2. Why was there an overload?
The bearing was not sufficiently lubricated.
3. Why was it not lubricated?
The lubrication pump vs not pumping sufficiently.
4. Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling.
5. Why was the shaft worn out?
There was no strainer attached and metal scarps got in.
Without repeatedly asking why, we would likely replace the fuse or pump and the
failure would recur. Keep asking why until the root cause is reached and
eliminated.
Step 3:
Explore Countermeasures
Unlike many
mathematical problems, which allow for only one answer, complex problems have
many possible solutions. So don’t jump to the conclusion that one particular
solution is the only solution. Take the time to identify and consider as many
ideas as possible. This is perhaps the most creative step in the problem
solving process. Do not judge the quality of your solutions, even the crazy
ones, until you exhaust the brainstorming process. Then, select an approach,
preferably one that focuses on process improvement and that is financially
feasible, has the best chance of being implemented and will have a high impact
on the problem.
Take the time
to do a test run on the solution. Make individual responsibilities clear and
establish a daily schedule for the improvement plan. Notify anybody who might
be affected by your changes before you begin implementation.
Step 4:
Implement Solutions and Monitor
Now you are
ready to implement the proposed solution and measure the results. How well have
you done? Is the problem subsiding? Do you see any improvement? Are there any
assumptions that need to be modified? Check whether your solution produced the
desired effect.
If the results
are satisfactory, the change achieved the stated goal. Amazing! You can now
move directly to step 5.
If the results
are not satisfactory, the change represented an improvement but did not meet
the stated goal. Incremental progress is still progress, so it may make sense
to move to Step 5 and start another improvement cycle to try more solutions. It
also may be the case that there is a way to amplify the change you implemented
to get more of the results you seek. In that case, make some slight adjustments
and gather more data.
If the change
did not achieve improvement, then in this case, you have a couple of things to
think about. First, if there were other proposed solutions, you might implement
one of them and then measure again. Another thing to consider is that perhaps
you did not find the root cause of the problem after all and need to go back to
Step 2.
Step 5:
Standardize and Control
In order for
improvements to last, they must be standardized and repeatable. Once you see
that the solution is working, take action to maintain the gain. Standardize the
solution so that you can prevent the very improvements you worked so hard to
accomplish from being neglected or replaced over time with past practices.
Gather data until the benefits stabilize.
Standardizing
work is crucial to PDCA because it creates a baseline for improvement. When you
make improvements to a process, it’s essential to document the new standard
work in order to sustain the improvements and create a new baseline. Standard
work also reduces variability in processes and promotes discipline, which is
essential for continuous improvement efforts to take root. After you confirm
that you achieved your desired effect, communicate the improvement.
Of all things needed to foster a problem solving culture, training is the most important, allowing and expecting associates to be systematic. Socratic questioning works best! The reason is simple: the problem is usually smarter than us and will always win over shortcuts.






