The Business Case for Kaizen
Dear Gemba Coach,
Our management team introduced kaizen events to our company three years ago. As a manager involved with lean, I have participated in many of these, and can say that a large number of managers are now able to run kaizen with our own black belts - without consulting support. Yet in this difficult period, I find that events are lagging. Managers often cancel or postpone scheduled events, and the kaizen approach is being challenged by executives who say that it is costly in resources and disappointing in improvements. I can see the benefits kaizen has brought our company, but find it hard to formulate the argument persuasively. Is there a powerful way to make the business case for kaizen?
Thank you for this deep and difficult question, which crops up often. The good news is that yes, there is a business case for kaizen. Unfortunately, it's not easily explained to someone who is not open minded enough to hear it.
The traditional argument for kaizen finds a way to calculate actual "savings," i.e. translating the improvement in dollar value. This is a great way to confirm the value of the work to the kaizen group, but it rarely convinces management. That's because these savings often appear paltry at the global level compared to overall budgetary considerations, and because these specific savings are rarely tied directly to the bottom line - there are too many other factors over time in the system that muddy these numbers. So how can one clarify the cost/benefit formula here?
The first step is to ask the simple question: what is the real benefit of kaizen? It is quite clear that the profitability of any industrial process (whether manufacturing or service) is mainly a result of its design: the technology and organization which structure the process which should deliver a product or service at a target unit cost for a target volume level. However this target level is rarely reached because reality happens. People have to use the software, equipment, materials, premises and so on in varying local conditions, with varying markets and supply conditions, with varying degrees of staff training and motivation and so on. As a result many unforeseen problems occur which hamper the "ideal" working of the process, and make it run suboptimally. These problems add up and create real costs which do show up in the accounts as extra resources (or lower sales due to disappointed customers).
The Biggest Benefit
Running processes closer to target performance is essentially about getting the operators of the processes to learn the tricks of the trade that will allow them to use the software, equipment, materials, premises smartly in real-life conditions. Continuous improvement in this sense is a constant drive to close the gap between actual performance of the existing process and target performance of the process as it was originally designed.
Occasionally, during a kaizen event someone might hit upon a brilliant idea which will lead to a very profitable process redesign - which is nice, but not the main aim of kaizen. The number one benefit of kaizen is teaching people how to solve day to day issues to run the process well in existing conditions. This will show up in the accounts by taking out a layer of additional costs one incurs to compensate for broken processes.
To estimate the potential benefit of kaizen, take the best day performance of your process, and apply this to every day of the month (if we've done it one day, we should be able to do it every day) and compare this to real day-to-day performance data. The gap is the potential benefit from kaizen.
Why kaizen? Because frequent iterations is a superior training method. The best known way to learn to do something is to try it again and again until one gets the hang of it. So the best way of learning how to solve specific process problems is to kaizen on this topic again and again until the problem is "solved" (i.e. the new way of doing things is inscribed in the standard). On this topic I recommend Rob Austin and Lee Devin's great book on Artful Making.
Now, to your question: what about the cost side? As Austin and Devin show, frequent iterations is the best known way to both learn and explore problems, but each iteration has a cost. And indeed, running a "classic" kaizen event has to be the costliest way of doing kaizen: a team of people "immobilized" for three to five days, a coach (internal is cheaper than a consultant, but still), a meeting room, sometimes stopping operations for the event.
From a cost point of view, what would be the ideal kaizen event? Well, a non-event. Imagine that an operator herself figures out something is wrong in the process (at a rental car service desk, for example, she has to pick up the phone to help customers find their way to rental returns, thus slowing the queue of customers who want to pick up a car), and tries several ways in which to solve the problem (written instructions, maps, etc.). This isn't likely to happen on its own with every operator, so it's the supervisor's job to get us closer and closer to this ideal.
In fact, we can kaizen how we do kaizen. There is a real skill in learning to do kaizen at the lowest possible cost of iteration. From the starting point of "no investment" in full-scale kaizen events, to getting operators to use cardboard mock ups and simple tricks to test kaizen ideas directly on the workstation in the course of their shift. Indeed, one of the fascinating things to look for in a Toyota plant (and not obvious to see at first glance) is all the scotch-taped and cardboard modifications around workstations where operators are trying new ideas as they work. And ideally, operators would be able to draw a "kaizen" document explaining the problem they tried to solve, and the savings generated by their solution, once this has been refined and accepted by the entire team.
Iterations are the way to learn how to keep processes close to target performance, but iterations have a cost, so it's part of our lean work to learn to increase these iterations while continuously reducing their cost. This is a specific kaizen skill which must be developed in-house and taught to the supervisors, so they can engage every one of their staff into such ongoing activities.
Should we entirely forego "classic" kaizen events? Probably not. The coach led kaizen events are important as a refresher course on what kaizen is supposed to be. The important point of these events is that they should tackle larger changes, involving more cross-functional players and rigorously follow the PDCA methodology to "show how it's done." In order to support kaizen done in the work areas by the frontline managers and their teams, it's important to maintain a schedule of full production kaizen events - but these can be planned through the year and budgeted carefully.
I'm not sure whether this will help you with your management colleagues, my experience is that it's hard to wake up someone who is pretending to sleep, but here is how the kaizen argument goes:
- To make money in our business and satisfy our customers, our processes must run every day close to their target performance.
- People who run these processes at the Gemba experience day-to-day difficulties due to local conditions that reduce effectiveness and generate additional costs to compensate for these inefficiencies.
- To reach target performance we need to constantly engage and train people to solve these problems and improve real performance, aiming for target performance.
- The best known way of doing this is through "kaizen" - frequent quick iterations of problem solving in order to "get it right" from experience and deep thinking, locally.
- These iterations, however, have a cost (most obviously the cost of running "classic" kaizen events), and we must work to reduce this cost by pushing kaizen further and further into a normal part of daily work.
- This requires deepening our own understanding of kaizen every day and, in a way, kaizening how we do kaizen.
Should we forgo the hope of big payoffs then? Absolutely not - we still want the big bucks. But the big payoff won't likely come from existing processes. As we learn how to deal with the problems posed by existing operations (through solving them), we will also generate new ways of doing things for the next investment.
When I first studied how Toyota involved one of their suppliers 15 years ago, I was surprised by the fact that they didn't ask for any financial concessions upfront for all their help (as opposed to their competitors who said: give us a 15% price rebate now, and we’ll show you how to get the next 15% out of your processes). It took me a while to figure out that Toyota did have a financial advantage at having a supplier cell which ran smoothly without quality issues for then. But what happened then, a few years down the line, is that when it was time to design the new version of the product, all the learning accumulated from a couple of years of kaizen led to a design which was 27% cheaper than the first one - and Toyota and the supplier shared this windfall.
I recently had the privilege of dining with Mr. Masaaki Imai who coined the term "kai'zen" 30 years ago, and as we discussed kaizen, I realized he had explained this basic mechanism linking small step improvement to large performance leap right from the start. It just took me many, many, iterations to figure it out.
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?