Dear Gemba Coach,
I hear the phrase “daily problem solving” a lot. But what does it really mean in practice and how does it work? Are we making improvements – changes – to work every day, including standard work; do we check with co-workers and supervisors daily on our changes?
There are two main ways of looking at this: (1) do I solve all problems daily so that, in the end, the process works perfectly or (2) do I use problem solving as a device to teach frontline staff more about their work so that less problems appear?
To put this in context, my father used to insist, at the plant manager level that fighting fires was part of the plant manager’s job – if he couldn’t do that, sooner or later, he’d get replaced. BUT the more fires you fight, the more fires will appear. So you’ve got to develop people’s ability to solve their own problems so that less fires get started. A highbrow way of saying that is the organizational capability of having less fires depends on the individual competence in avoiding starting fires in the first places or solving things when they’re very small fires – or, to use another expression I learned by a sensei, focus on the buds of problems, before they flower.
Sine we’re talking about the old days, Shigeo Shingo used to show that much of quality control is really issuing “death certificates” – the problem has already occurred and we’re trying to pull the body out of the flow of the living. The question is how to avoid the situation in the first place. Because experts can’t be on call everywhere all the time, the only logistically sound solution is to turn everyone into an expert.
How do we do that? By seeing problem solving as a training technique, rather than seeing it as a, well, problem-solving techniques. We don’t want to fix every problem. We want to teach every person to better understand their job, and make sure the problem doesn’t occur in the first place. We want them to be autonomous in their problem solving which means:
- Do not walk past the bud of the problem without stopping and correcting the situation. The classical Chinese image is not walking past a child leaning into a well without holding them back. (At work, probably the hardest part, because in well-structured, process-oriented organizations, everyone thinks someone else should deal with the problem)
- Know how to solve a typical problem in a large variety of situations. The “one best way” rarely fits all situations and problem solving is highly contextual. Autonomy means solving the problem in making the outcome actually better, not going through the motions to find that, in the end, matters are worse.
- Know when to flag the issue because the fire has started to burn and it will soon become a raging blaze. This is much harder than it looks because most workplaces are set up to shoot the messenger, dismiss unfavorable information and never distract the boss from his or her wishful thinking. It takes a “problem first” culture, and clear understanding of the role of middle management to fight the natural tendency to sweep the issue under the rug and walk away hoping that no one has noticed we were the first on the scene.
As you can see, these are both cognitive (actual problem solving) and non-cognitive skills (the attitude to problems), which both need to be taught, and, since teaching it is hard, taught daily – hence the daily problem solving.
In this sense, daily problem solving means looking into one problem a day, not with the hope of solving all problems, but with the hope of learning more about our job (and our standards), every day.
For this to work, we need to realize that the problem solving structure – the PDCA, the A3 8-boxes, etc. – is nothing more (or less) than scaffolding to support problem solving. The aim is not to tick the boxes, but to get a better observation and discussion about the issue, which means getting closer to the “point of process,” the point where the tool (whether a computer system or a drill, or a press, etc.) hits the part, and the quality of the value add, compared to standards.
Observation and discussion of one problem a day (What is the point of cause? How do our standards help or hinder? What is the smart way to deal with this situation?) will progressively hone your mental model of what matters and what doesn’t in the normal situation, and so build from your experience and into your experience the orientation points needed to do the job well –and avoid future problems of the same sort.
Let’s look at this Toyota 5 why exercise:
The conclusion here is that racks should be designed so that the option specification sheet is in full view at the moment that parts are picked.
This means that we’ve learned a new point to be careful of when looking at how racks are set up on lines to make work easier for operators. With this in mind, the next line can be either kaizened in this way, or designed so the situation does not arise. The problem solving has led to reusable knowledge that will make this problem not occur again. And there, is the win.
Proof of Respect
To my mind, daily problem solving is indeed about sharing with supervisor and team how one person has solved one problem today (each day, one quick description of how one problem has been solved). The supervisor can ask all others to check their standards on the matter, and keep topics fresh in their minds. The engineering Toyota phrase I keep in mind is “80 points + alpha” – the 80 points one has to get right daily and the alpha improvement to do things a bit better. Daily problem solving is the opportunity to both (1) check the standards we need to have in mind (there are often so many that taking problems as an opportunity to revisit standards is important) and (2) the small plus to understand better the work from both the customer and employee point of view.
If we do this day in day out, we will find that performance increases because fires disappear, and that engagement increases as people feel more self-confident about both their work and working with their colleagues, other team members and supervisors. Daily problem solving is a proof of respect.