Dear Gemba Coach,
I’ve been following the exchanges on The Lean Edge with great interest, and all the lean authors seem to focus on problem solving. In our company, lean has essentially been about implementing pull across the plants. Which way should we go?
Your question captures a key lean challenge, which is how to describe this system of numerous interrelated ways of thinking and behaving in specific and seemingly isolated terms. Because lean is a system that functions on several dimensions at the same time, it is difficult to describe in linear terms. Moreover, it is inaccurate to focus on one element without acknowledging its relationship to another. Consider, for example, the pull system and the focus on problem solving, which are two key aspects of lean. They must be viewed as part of a whole, like the palm and the back of a hand. In the lean system they work together to help teach every employee to improve their own processes. That’s because this learning can only occur when you have both the tension of pull, coupled with a firm focus on solving the problems that crop up. The old timers call this approach lowering the water in the river and seeing the rocks appear.
All the major elements of the system are linked. Just-in-time and jidoka are the two pillars of TPS. One way of describing the relationship between these two practices is that just-in-time is about productivity improvement, and jidoka is about highlighting problems made visible by the pull system. Pull creates the tension that reveals problems, but these problems must be seen, and dealt with, in a way that they won’t arise again – which is what delivers the productivity gain.
Let’s take this to the gemba. Suppose you have a kanban-based pull system in place. Now, have you watched what happens when you take cards out of the loop? Taking cards out reduces the batch size. If you’re producing As, Bs, and Cs, it means that you have less time to run B and C until you run out of As in the shop stock. This means that the impact of any variability in the process, either a changeover that takes longer than it should, or a machine that is off for a few minutes (change of welding tip?), or a late component, anything will cause the shop stock to dry up. When there are no parts to pull out of the shop stock, cards accumulate in the launcher – which should be seen as a problem.
Kanban was designed as a tool for kaizen, not the other way around. But as you tour many factories, you will see launchers full of cards and empty shop stocks, yet few supervisors becoming flustered over this condition. They shrug their shoulders; yes, we are in a backlog situation, and someone must be working on it, but so what? This is production, right? Murphy’s law will strike here first. Folks will argue that the missed delivery happened because of the pull system: if we had more boxes in the shop stock, we could have tolerated a longer machine breakdown, and still delivered to the next process and the customer. Problems accrue. A longer breakdown reduces productivity further as parts per hour per person go down and machines are underutilized. In fact, I’ve seen several factories running elaborate pull systems with fat inventories everywhere and poor efficiencies. The more inventory, the greater tolerance for mishaps, the less productivity. Conversely, the less inventory, the greater reactivity (one hopes), the smoother the production and the higher productivity.
What makes pull system effective is not the pull itself, but the reactivity of people to problems when they appear – what Steve Spear calls “swarming” problems in his breakthrough book The High-Velocity Edge. Furthermore, should the management set this as a goal, swarming problems can lead to root-cause problem solving, which will produce fundamental process improvement. A pull system alone does not guarantee effectiveness. To pay its promised returns (15% more productivity, 50% less defects, 25% less stocks than an MRP-run line) the pull system needs to be managed in a “lean” way. This means teaching people to see, react, reflect, share and challenge. We’ve discussed these basics before, but once again, they are:
- See: A lean system is designed to show something that is not right. In the ideal, the process will simply stop. This is hard to do in practice, so create some physical aspect that will indicate that you’re driving on the wrong side of the road (such as too many kanban cards in the launcher). However, in order to see, you’ve got to look. Team leaders and their supervisors must take the responsibility to own these problems and stop and think, as opposed to ignore the signs and soldier on. Taking responsibility for problems is far from natural, and needs constant reinforcement from management to encourage “problems first.”
- React: How many times have you spotted something not quite right at home yet failed to respond until you suddenly have a real problem: the dripping pipe which suddenly springs a leak that ruins your neighbor’s ceiling, and so on. The first task of lean management is to teach people how to react (for starters, to react at all). I recently visited a factory where they insisted on “escalation” as a reaction: in case of any problem, the problem should be escalated quickly up the ranks. As a result, everybody filled forms and wrote on boards assuming that someone else had to solve the problem. Escalation might be necessary, but that is not the aim of reacting: the aim is getting people to solve their own problems quickly. To do so, they’ve got to be trained. So it’s not a question of escalating the problem so that the boss gets out of the meeting and saves the day, but of creating a system where the boss can tell there is a problem and where, and come along to watch how people are doing by themselves and teach them how to do it better.
- Reflect: Lean is about learning by doing. There is no point in blue-sky thinking, no matter how clever, if you’ve not reacted first to plug the leak. So first stop the oil from gushing into the sea, and then try to figure out how to make sure this doesn’t happen again. Reacting will teach you about the true nature of the problem, but rather than be happy with the plaster, the idea is to start asking why? Until the root cause becomes apparent, and the process fixed so that the problem will not arise again (with no – or little – investment). Oddly, people prefer to reflect when they’ve not done anything… and usually get it wrong. Reflecting on one’s own actions is more emotionally challenging because one is forced to accept that the reaction was never perfect – there’s always something we missed under fire. But that’s the whole point of learning. By reflecting on the way we’ve reacted, we first have more facts at hand (from just having done it) as opposed to tons of data, and second we pay more attention and learn.
- Share: No one is expected to reinvent the wheel by themselves, and many brains are better than one – so it’s important to share learning, both at the reflection stage and at the confirmation stage. In lean, to share does NOT mean “apply best practice” – it actually means, well, share: comparing different ways to solve similar problems in different local conditions to spark new ideas. Again, the aim is learning, not just applying. And not to worry, if the practice really is a “best practice”, people will adopt it in a flash. “Not invented here” exists, but tends to happen when its unclear whether the touted change really is an improvement or simply a change.
- Challenge: We are natural problem solvers, but we’re also natural satisfiers; we’re extremely good at finding a workaround that passes the problem on to someone else or to some time in the future. Getting people to see their problems every day, to react, reflect and share requires constant challenging. Is the pull system tense enough? Is the immediate reaction good enough? Is the reflection deep enough? Is the sharing broad enough?
Lean as Learning System
As discussed in a different column, lean is a learning system, which determines a sustained pace of learning: you don’t get to choose how quickly you learn. I remember visiting a Toyota forklift plant just after their sensei had been there. There was a huge hand-drawn value-stream map on one of the plant’s walls (in the production area, actually), with parts containers identified as round circles on the flow. They showed me how, after touring the plant, the sensei had crossed out several of these circles, indicating the stocks should be taken out. In the end, this led the plant to radically reconfigure how they brought parts to the line and to invent an elaborate system of trolleys inserted into a train. The plant didn’t feel like it, but they did it: they learned at the speed imposed by their sensei’s lowering the water and revealing the rocks.
A lean pull system is a sensitive mechanism – it’s prone to fall over at the slightest mishap, kind of like juggling plates on sticks. And that’s the whole point of pull. Pull is not a stabilization tool, but something to keep you moving forward. On the plus side, it also becomes a stabilization tool because leveling the production plan, doing what it takes to make people show up on time in the morning, stabilizing the component supply, working at keeping machines running smoothly and conducting SMED workshops forever and ever are the only ways of keeping a pull system up. In other words, the pull system creates problems – and solving these problems creates performance. The pull system is the greatest production teacher you’ll ever have, but you have to be ready and willing to learn what it teaches.
