Are you really solving problems when you think you are solving problems?

In many ways, Lean is about developing a culture of autonomous problem solvers – but, what, exactly, do we mean by “solving a problem”?

A problem is when a mishap in the normal process leads to a gap in performance. An unexpected traffic jam on the way to take a train is a problem when it gets you at the station late. Missing the train because of it is a problem when you arrive too late for an important meeting. Not being there at the meeting is a problem when you can’t close the deal, and so on.

Solving problems in the casual sense means first, working a way around the problem – is there another route to catch this train? Is there another way to reach the meeting? Can the meeting be reschedule? Then it’s about controlling or changing the process so that the problem will not arise again. Should you invest in an earlier start to compensate for traffic jams although most morning the road is clear? Should you invest in a real-time traffic monitoring system to get earlier warning of heavy traffic? Should you explore all alternate routes beforehand in case of a slowdown?

As Art Smalley and David Mann point out, there is problem solving, and then there is problem solving. Problem solving can be administrative, detection based or preventative. If we go back to the quality teachings of Shigeo Shingo, when tackling quality problems, we’re trying to progress through three levels:

• Level 1 – post-inspection: counting the dead, so to speak. The process does what it does, and then we inspect the bad parts or jobs out of the result, put in layers of auditing, and post-hoc corrective measures. We manage the problem, once it has happened.
• Level 2 – self-inspection: learning to monitor critical points in the normal process to get early warning and stop and fix. In accidents as in quality incidents, there is usually a time tunnel in which the process is no longer doing what it should, but performance is still ok (some slow downs on the road will be stressful, but you still get to the station on time). Then there’s a point where performance drops dramatically (this can be represented as a Taguchi curve). Early warning signs and instant correction help to both stop the problem from getting really bad and learn a lot more about the process itself.
• Level 3: source inspection: knowing what to look for beforehand to prevent the problem from happening in the first place. The is the aim of the “five why?” analysis, which is about finding the real root cause of the process and changing or monitoring this.

If you think mechanically about problems, problems are either solved or not. Practices are either good or bad. The trick is to move from bad practices to good ones.

But if you think more organically, every practice is Yin-Yang – changing a practice moves the balance point. Solving the problem by shifting from post-inspection to self-inspection to source-inspection means understanding better what to monitor carefully in the technical process to avoid disastrous performance loss.

This isn’t easy because often, the source inspection point are not necessarily visible or simplistically correlated to where the problem symptom appear. To get a feel for the systemic nature of many issues, check out this astounding film about the environmental impact of reintroducing wolves in Yellowstone.Similarly, Taiichi Ohno’s famous five why example:

1. “Why did the robot stop?”The circuit has overloaded, causing a fuse to blow.
2. “Why is the circuit overloaded?”There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”Because there is no filter on the pump.

Shifts the focus from monitoring robot stops, to installing an monitoring a filter on the pump (the filter will eventually clog up). Lack of filter on the pump, however, is not immediately visible when looking at the robot stops – it has to be discovered amongst hundreds of other possible causes.

Our explicit attitude towards learning is what makes the real difference toward problem solving:

1. People won’t learn, they can’t be bothered and have to be forced to do the job properly: this assumption leads to “administrative” or “post-inspection” solutions – ask someone else to inspect the work of those who do it and put in place paper controls and audits to take corrective action once the process has effectively derailed.
2. People can learn if they respond to very visible signs of problems: This is the “detection” or “self-inspection” approach to problem solving – by creating visually intuitive standards (think red light at an intersection) people will respond to red flashing lights and stop what they’re doing and make an effort to get back in the standard, and in doing so people learn what to watch out for, as long as their attention is guided by visible signs.
3. People can think deeply, and can discover the deeper roots of problems: this is the root cause or source inspection approach, not giving up until the focus point of the issue has been shifted to something easier to monitor and control.

is creating a culture of problem solvers about making plans to audit and control processes? Or is it about making plans to support individual learning about the nature of the processes?

In my experience, this is the “magic ingredient” the sensei bring to your lean practice: pushing you to move through the levels and go all the way to the learning, even when the symptoms of the problem are gone and the “fix” is in place.

This is also the biggest mistake people make about obeys and visual management when they use displays to monitor processes with all sorts of powerpoint indicator charts on the wall and action plans, as opposed to creating spaces for learning: what are our issues? What are we currently trying to do? How are customers reacting? What have we discovered?

The root cause of really learning to solve problems is not about the problem-solving itself, but about your explicit commitment to learning as opposed to the traditional obsession with control. Quality improvement is very different from quality assurance. More paperwork will not help you discover a root cause. You have to be there, when the problem happen, and look deeply with others around you into what is going on, discard the wrong hypotheses until, progressively, the real principles at work will become clear.