Lean Leadership: Kaizen is Management

Chapter 4 of The Toyota Way to Lean Leadership lays out the picture of a company where continuous improvement of operations is the primary focus of the management system.

Note here that I said “focus of the management system” rather than “focus of the managers.” I believe there is a crucial difference which I will explain in a bit.

Liker and Convis start out by explaining what “kaizen” isn’t. Sad that they have to do this, but the problem is summed up nicely:

Too often [kaizen] has come to mean assembling a special team for a project using lean of Six Sigma methods, or perhaps organizing a kaizen “event” for a week to make a burst of changes. We sometimes hear the phrase “doing a kaizen” as if it were a one-off activity. At Toyota, kaizen […] is how the company operates at the most fundamental level.

One of the persistent mysteries (to me) is why, after decades of knowing otherwise, so many businesses still consider “kaizen” or “improvement” to be a separate activity from “management.”

A few weeks ago I expanded on a great presentation by Bill Costantino that explained the relationship between challenges, targets, kaizen and the knowledge space of the company.

In that post, I created an animation of Bill’s graphic that illustrates progressive targets pushing the threshold of knowledge relentlessly toward the objective.

In this model, although we have a decent idea where we are, and what we want to end up with, the details of the path to get there are not known in advance.

Lean Leadership illustrates the same point quite well with the story of a factory kaizen team at TMMK (Toyota’s Georgetown, Kentucky facility). Of note is that this team is made up largely of production workers. It isn’t “the improvement team.” It isn’t an engineering department team. It is the people who have to live with the solution.

The team’s challenge was to improve a wasteful process for handling and moving sheet metal parts through the plant to the point of use on the assembly line.

They started by studying another company’s solution to the problem.

Did I mention that this team of factory workers from Kentucky spent two weeks in Japan studying this supplier’s system? Why make this kind of investment? Ponder that a bit, we’ll get back to this too.

Once back in Kentucky, the team had a clear sense of the challenge, and set out to progressively develop their own solution by experimentation, observation, and learning.

First they tried copying the benchmarked system on a small-scale test to deepen their understanding of what they had studied. Trying it on their parts surfaced differences that weren’t obvious at first, and they learned copying definitely wouldn’t work.

Key: The reason they tried to copy was to learn more about it. This was a small-scale concept test, not an attempt at wholesale implementation.

Even if it had worked, copying develops no skill other than reverse-engineering someone else’s solution that was developed for a different problem in different conditions. When people then say “See, it won’t work here” this is likely how they got to that conclusion. Too many companies “benchmark” and then try to do this. This team took a completely different approach.

“OK, cool, it didn’t work. Try something else.” And that is how learning happens.

They go back to grasping the original problem – damage from forklift handling. This is crucial. So many teams get bogged down on defining the “problem” as “making the fixed solution work” and end up expending a lot of effort in a tunnel with a dead-end. This is about exploring possible solutions to the actual problem.

They end up developing something quite different from what they benchmarked, that delivered the right parts, in the right orientation to the assembly operator. They knew this because they were their own customers – these were people who did this job.

Once they had it working on a sub-set of easier parts, they expanded the concept step by step (a few parts at a time) to handle the larger ones.

Key: Get the simple version working before trying to add complexity. Control your experiments. This is how learning happens vs. “just fiddling with it until it works.”

They proceed step by step – now sharing back and forth with the benchmark company who is seeing their solutions and building on them, until they have an AGV pulling a sequenced line of part carts that were loaded by robots, everything moving at takt.

Still, there was a lot of human interaction and they kept working to better synchronize everything.

Step by step, they worked their way back into parts that came from outside suppliers, dealing with one issue at a time.

Then a remarkable thing happened:

…at some point an hourly team member asked why the company was spending so much money to buy AGVs from external suppliers. Toyota manufactures vehicles, after all. Team members found they could buy the little robotic device that pulls the carts and custom-make the carts themselves.

But they didn’t stop there.

Later they discovered they could buy inexpensive, generic circuit boards of the type used in the AGV and program the boards themselves so that the AGVs would stop and wait at certain points along the line. Programming the AGVs themselves was a breakthrough, since it cut out licensing fees and added the flexibility to reprogram them. The original AGVs cost about $25,000 each; the ones built in-house cost under $4,000. With more than 100 AGVs in use, the team members kaizen initiative saved TMMK more than $2 million.

Let’s take a step back from this and look at what was really happening here.

What did these team members know at the end of this process that the didn’t know at the beginning?

What knowledge did they add to the company’s capability? Beyond the simple technical solution, what else did they learn? What confidence did they gain?

In other words, how did participating in this process improve the capability of the team members to improve other processes?

What would it be worth to your company to have team members who could think like this? (Hint – you already have them)

I promised to address a couple of points later. Here they are:

The role of managers vs. the management system.

The management system in any company is rightly focused on ensuring that operations are delivering the most customer value for the least cost. This is true of any value-creating operation, be it organized for profit or non-profit.

But the picture being painted by Liker and Convis is one where this management system works by ensuring the managers (that is, the individual people who are responsible for the operation) are focused on developing people’s capability.

To do this, Toyota has a specific process for developing leaders to embrace this responsibility.

This isn’t a new message. But it is emerging more clearly and more consistently in the popular literature in the last few years.

Which brings us to who made the improvements.

In this example, the improvements were made by production team members.

The company probably could have achieved similar (or at least similar looking) results with a project plan and a team of engineers. It might have even been faster.

But the production workers would have learned nothing other than to accept whatever the engineers gave them.

It is unlikely it would have occurred to anyone to build their own AGVs and save another couple of megabucks.

And the capacity of the company for improvements would have remained the same rather than increasing. At some point, the rate of improvement is constrained by the resources that can be dedicated to the task.

So, while an individual improvement task might take longer as people learn, in the end there is a multiplier effect as more and more people get better and better at making improvements. Sadly, it is really impossible to assign an ROI to that, so traditional management doesn’t allow for it.

This post is long enough. There is more in Chapter 4 to talk about, but I want to get this out there.