Home > Gemba Coach> What Does Problem-Solving Look Like? Part 2 of 2

What Does Problem-Solving Look Like? Part 2 of 2

11/18/2009
Permalink   |   1 Comment   |   Post a Comment   |  
  |   RSS

Dear Gemba Coach:

Thank you for explaining the different types of problem-solving that distinguishes lean. But how can I tell that we really are learning the best way to deal with problems? What are the signs of progress when it comes to problem solving?

Good question - and thank you for your willingness to embrace your problems! Beyond distinguishing various kinds of problems, is there anything specific to lean in the way problems are addressed? I believe there is. Here is a quick list:

1. Look for leadership: to a large extent, lean systems are on-the-job training systems. You can tell that you are tackling problems properly when people are taking ownership of their problems. There should be daily training of operators about standards through "stop the line and confirm every problem;" and second, there should be constant training of management about problem solving. Consequently, for every problem the first question will be: who needs to learn to solve this kind of problem right now? And then: whom can we develop by giving them this problem to solve?

2. Visualize the problem: this is unique to the lean approach. Before attempting to resolve the problem, the lean technique is to make the process visible (in real, material terms on the Gemba) so that the problem will be revealed when it appears. Properly done, the visualization should highlight the gap between the standard and the actual conditions.

3. Try things out right away: experimenting is not about solving the problem quickly but about understanding it better through trying out ideas quickly. Just as with visualization, there is a unique lean skill in knowing how to try ideas safely and without cost (for a short period of time, with mock-ups, etc.). The key to trying things out is to do it with frontline employees because they know more about the real situation than any manager ever will.

4. Involve all stakeholders: this does not mean that every one's wishes will be granted. But it does mean that everyone involved will have his or her opinion heard. If we can't deliver on what they'd like, we need at the very least to explain why and how.

5. Check rigorously before you draw conclusions: a sign of true lean problem solving is the creation of an indicator that measures how well the subject of the test is affected by quick experiments. Checking is planned in the early steps of PDCA and carried all the way through to the final conclusions.

6. Generalize by transferring the analysis method rather than the solution: in this, lean practice differs considerably from the usual spreading of "best practice." Because the lean approach requires a more detailed understanding of problems and problem solving it is quite commonly acknowledged that a solution that works in one set of conditions might not work in another (certainly adopting Toyota's solutions hasn't done many companies much good). The trick is to spread the analysis method. Experience shows that if people with a similar problem attack it following problem-solving steps which have worked elsewhere, they will come up with their own variation of a generic solution - and make it work profitably and sustainably.

When I first started studying lean initiatives 15 years ago, the veterans used to tell me that problems were great opportunities for improvement. I remember thinking cynically "come on, who in his right mind would believe such blatant company propaganda?" But I’ve come to share the same sentiment. Problems are improvement opportunities because they are occasions to learn about our own processes. Lean is a system to empower people by teaching them how to solve their own problems on the job and, in doing so, develop sounder judgment and better decision-making. The issue is not to "solve" problems every day by making them disappear, but to become more proficient at solving more difficult and more detailed problems every day.

1 Comments | Post a Comment
Olivier Fichet December 8, 2009
Much to support Michael Ballé’s coaching, I would like to first caricature problem-solving versus firefighting, and test elaboration on the methodology for problem solving deployment. Those appear to be key for changing the organization approach to problems, and pick its benefits in form of an uninterrupted flow of transformation steps, reflected in the improvement of Cost, Quality and Delivery indicators.
In my experience as well, almost everyone consider themselves as “problem solver”. Hence the importance of the clarification of problem solving definition as M. Ballé did. And a consequence: there are, “problem-solvers”, and “fire-fighters”. The concern about the later is the fact that after killing the effect of an issue, who is investigating to identify what lit the fire? Hence the type of root cause analysis reports that say, for example for an assembly with the wrong part: “Operator picked the wrong part. Operators have been notified; a sign has been placed at the work station to make instruction visual”. It’s a caricature. In our pressured environment, a few managers might be satisfied with disappearance of the problem (workaround) when Lean is in favour of PDCA measures. The consequence is that if symptoms disappear, problems remain.
Therefore, an organization wanting to progress need to enforce usage of a standard, simple problem solving method. What is that? Michael wrote the 9 steps and mentioned PDCA and I’d propose to aggregate them:
a) Plan
1-Define (5W-2H, plus metric that reflects the problem impact)
2-Protect customer (controls, rework, primary fix)
3-Collect data
4-Identify and confirm root causes (Brainstorm, Ishikawa and then 5 why, Pareto)
5-Choose solutions (Brainstorm)
b) Do: implement the solutions (Project Management)
c) Check: measure effectiveness (Metric and Key Performance Indicators)
d) Act: change standards (designs, work instructions…) embed the solution
Beyond classroom training, the practice on a real case, with a mentor proves essential. A mentor will support the mentee to continue her action despite difficulties. One mentee might feel challenged to go beyond a) – step 2 because: “fire is extinguished”. Then, having data collected or test performed by the team can prove difficult. Another is not succeeding in the Do, because by the time solutions are chosen, the problem has been forgotten and new problems get the focus. And the third one may feel discouraged by the fact that tests and data not always confirm what intuition and experience first proposed as possible root causes. Persistence is needed, as well as encouragements to persist or decision to shift to a complex solving method if this becomes appropriate.
After mentorship, it can be useful to set individual year objectives for problem-solving. “Perform one formal problem solving a quarter”. And implement corresponding reporting of improvements and evaluation of method.
Suggestion and idea systems will support problem solving as well. This can result in a priority management of identified problems, in the form of a unique, visible list of issues and actions.
A3 is absolutely a method that forces transparent communication between the problem-solver and her mentor, between her and her multidisciplinary team working at the solution, between her and her hierarchy and as well for herself, because articulating a PDCA on a limited space logically and concisely forces clarification of points that would otherwise remain hidden in the jungle of information of classical powerpoint.
Last, but not least: “stop the line” management method says that any process encountering an abnormality must be stopped and a solution applied. Can you detail how to implement such policy or stop the line rule? I’ve never seen this fully implemented upstream of the final assembly lines: if I have practiced stopping the line to contain and solve customer affecting problems (mostly quality), I have not seen this applied to any type of abnormality (standard work, inventory accumulation).
Other Michael Ballé Related Content

Gold Mine Master Class

Books

Articles

Webinars