In most references describing the process of good problem solving, the first real step is to explain what actually is the problem.
It is easy to get tripped up at this stage and describe the problem in terms of the desired target, or in terms of “lack of” a specific countermeasure. That, of course, skips over the whole point of gaining a deep understanding of the situation before moving too far into intestigating causes.
I heard a great way to frame that first bit of description tonight from Richard.
“What is the evidence of a problem?”
That word, “evidence” does a much better job of conveying the point that this should be a description of the things that are observed, heard, felt, etc. rather than any kind of analysis.
In many cases a “big problem” is actually evidence of many small ones. “Too much inventory” is one of those. So is “defect rates” or any other aggregated measure. If you are running KPIs you probably know that, because they aggregate so much, they are often relatively insensitive until things are so far into the hole that it is a mess to untangle. Better to instrument your processes at much finer levels and get “evidence” in real time.
Hi, Mark. I’m just coming off a week long study of TWI Problem Solving in San Diego. (Yes, it was very nice in San Diego. I especially enjoyed the morning runs in Presidio Park.) It was a small group and very different from the other train-the-trainer sessions for TWI “J” programs. Most of the time we were studying the mechanics of how to deliver Problem Solving training but many times we were thrown into the role of learning just how DO you solve problems. Having done quite a bit of shop floor problem solving over the years I really enjoyed being pushed out of the comfort zone and into a different learning process.
We all know that the only sure way a team leader can get a smooth running department is to follow a good pattern of problem solving. Otherwise, he or she is only a “trouble shooter” dealing with one emergency after another and never quite getting them solved.
One problem we reviewed involved a heat treat process in which parts began to fail a hardness test. The supervisor reasoned that the best way to deal with the problem was to slow down the conveyor and give the parts a little more time to reach hardness. “Natural variation,” you know. By leaving parts in the furnace longer, they began to pass the hardness test. Problem solved!
Unfortunately, with cycle time increased, capacity decreased and the piece part bonus for team members decreased. An escalation and intervention was required which concluded that calibration of the temperature controls was not done correctly and the actual temperature in the oven was not what was displayed on the temperature gauge.
The supervisor decided the problem was “failing hardness test” when it really was “not reaching hardness in the usual time.” Failing hardness test was evidence of the problem, not the problem.
So this pattern, what’s the problem, what’s the evidence of the problem, is really useful in sorting out symptoms from problems.
When care is taken in stating the problem and its evidence, it then becomes much easier to develop the “chain of causation” that produced the evidence. What directly caused the failure of parts to achieve hardness? What was the indirect cause? In other words, what caused the direct cause.
This, of course, is 5 Whys.
By only looking at the evidence of a problem as the problem itself, the supervisor had “shot the trouble” but didn’t solve the problem.