Target Condition vs. Target

This search question landed someone on my site yesterday, and I thought it would be a good one to try to answer specifically:

why is lean manufacturing preferred to implement target condition as compared to target?

In other words, what is the difference between a “target” and a “target condition?”

Where this gets sticky is that there isn’t any canonical definition of either term. There are people who use “target” to describe what I mean when I say “target condition.” So I think it is probably best to focus on that term: “Target Condition.”

“Target Condition” = “Target Process”

A team I am working with is bringing up a new (to them) product line. Their short-term target is to complete 8 units / day. But just saying that doesn’t describe the way they want the process itself to operate.

The Target Condition for the line is unit-by-unit flow in critical parts; with order-by-order flow in others (where we can’t overcome batching at the moment). To that end, we have created some guidelines for the layout and movement of work; limits on work-in-progress inventory, etc.

Block diagram of flow line

We know that this can’t be achieved right away, but aren’t sure what problems will surface as we try. Thus, the effort is focused on trying to operate to the target process in order to surface those obstacles so they can be systematically addressed.

So – to answer the question “Why [does] lean manufacturing prefer to implement a target condition as compared to a target?” – Unless we know how we want the process to operate, we have no point of comparison for how it is actually operating.

Without the ability to compare “What should be?” with “What actually is?” we cannot identify the gaps we need to close, the problems we need to work on to get there.

Thoughts on Failure Modes of Kaizen Events

The common frustration in the weeks following a classic 5 day “kaizen event” (which go by many names) is that the follow-on actions are not completed, and the changes that were made erode quickly.

Recently I have asked myself why it works so well during the actual workshop, and then fades so quickly afterwards.

Mike Rother has a great graphic that starts this conversation:

The question I am exploring today (and bringing you along as I reflect on it) is “Why do the ‘lean tools’ work so much better during an event than during “business as usual?”

Hanging this on my current working theory, I think it comes down to different patterns of interaction.

What Happens During the Event

Look at how the structure of these events drives how people interact with one another.

The workshop preparation usually involves establishing a clear bigger-picture sense of the problem to be solved. Even if it isn’t specific, the team education establishes a sense of direction, typically toward 1:1 flow at takt, and a pull process that limits lead times.

The structure of the workshop itself has the team working together studying the current flows, seeing the problems for themselves, and working in pairs or small groups on proposed solutions.

Those proposed solutions are usually structured as experiments – “let’s try this.” At the end of a typical day there is some kind of structured reflection on what we tried, what we learned, what we are going to try tomorrow, and what we expect to achieve.

So – we have small groups of people, collaborating to solve a specific problem, running experiments and learning what will work.

Unfortunately the team usually comes up with more ideas than they can actually try out. Those end up on a to-do list for follow-up.

After the Workshop Week

There is a fundamental shift in the dynamics after the pizza party on Friday.

The team members go back to their regular jobs. The problems they are focused on are different. The leftover items from the workshop are added to the “stuff I need to do” list that nearly everyone in every workplace has.

Rather than continuous collaboration, there might be periodic meetings to talk about the status of these “action items.” But there isn’t specific time carved out to work on them.

If this is what happens then “Business as Usual” couldn’t be more different than the working structure that created all of these improvement ideas. Business-as-Usual is not creative, does not allow for experimentation, and is optimized for repeating what we already know vs. learning something new.

I’d like to point out here that I have seen exactly the same situation in companies that many others consider “lean” benchmarks. What I saw in those companies was a much heavier infrastructure of dedicated lean specialists who were doing the heavy lifting. It still wasn’t embedded in “business as usual.” Instead it is a parallel process that is running improvement events about as fast as the day-to-day processes erode the improvements.

In fact, to this day, after being after this for two decades, one of those companies still has to hire “lean experts” from outside. Why? What is the business-as-usual day of a supervisor that they never learn this stuff?

In summary: During the kaizen even week, we organize and interact in a way that works for creative problem solving and making improvements. Then, the next week, we stop.

It shouldn’t be a surprise that the dynamics shift from “experiment to solve the problem” to “get this stuff done.” Business-as-usual is represented by “get this stuff done.”

 

 

Lessons from Driving a Forklift

The spring and summer of 2000 were a long time ago, but I learned some lessons during those months that have stayed with me. In fact, the learning from that experience is still happening as I continue to connect it to things I see today.

I was a member of a team working hard to stand up a new production line of a new product. The rate pressures were very high, the production, production control, and quality processes were immature.

At a high level, the parts flow was supposed to work like this:

Steel parts are fabricated and welded, based on the production schedule for various configurations.

Unit sets of parts were sent to outside paint. (We didn’t have our own paint system yet.) In reality, unit sets would be broken up as some parts went to sister plants, others went to outside vendors, each with their own lead times and flow times.

Parts return from outside paint. Because of the different vendors and lead times, different parts arrive on different days.

On assembly day, kits are built for the parts required at each entry point on the assembly line. Those kits are delivered based on a pull. The assembly line had a number of entry points and feeders, so for each takt time cycle, though only one “unit’s worth” of parts were actually delivered, those parts were for different units, as feeders had different lead times into the main line.

image

The innocuous challenge was to develop the kitting process (in red) that broke down the parts into  kits and got them delivered to the line.

I got pulled in on Thursday of a “kaizen event” that was supposed to develop this process. What had actually happened, though, was analysis paralysis, a lot of theoretical discussions, a lot of drawings on a white board, but nothing had actually been tested or tried. My assignment was simple: Organize this and get it going on Monday.

I had four people working for me, though they were not officially direct reports. They were an eclectic mix of personalities and styles.

A few things became apparent very quickly:

The process of scheduling which parts needed to be fabricated and welded to be sent through painting on any particular day was broken. Result: What was needed wasn’t necessarily what got sent to paint.

The processes of keeping parts organized during the various outside paint operations was broken. Result: Unit sets got mixed together, parts went missing.

As a result this is what my days looked like:

I came in before a hint of dawn at 4:45am to prepare for the assembly line starting at 5:40. I would go out into the parts yard with the day’s production schedule and a flashlight. My goal was to answer a simple question:

What units on this list can I build with the parts that are here?

I would re-sequence the production schedule to front-load the units that looked like we had everything we needed. (This caused all kinds of problems with serial number sequences and engineering change control, but that is a different story.)

We would start pulling in those parts, and breaking them down into the kits. We set up FIFO lanes for each entry point on the assembly line, and worked as fast as we could to build up about a three hour backlog. Why? Because it took about three hours to expedite a missing part through paint. Once we had that queue built up, as we discovered shortages (or parts painted the wrong color!), we had a chance to get the situation corrected and have a shot at not creating a shortage on the line.

We were working 10 hour shifts, I was typically there for 12-14 hours. Even though I was a “lean guy” my daily work was orchestrating all of this chaos, expediting and delivering parts, and I spent at least six of those hours every day driving a forklift. I got really good at forktruck operation that summer.

At the end of the day, I might sit and chill for a little while, then would get in my truck, go home, and do it all again tomorrow. One of those days as I went to back out of the parking space, I hit the turn signal to put my stick-shift truck into reverse – because that’s how the forklift controls worked.

What I Learned

I actually continue to learn. But here are a few things that have stood out for me.

Shop Floor Production Supervisor is a really hard job. I wasn’t a supervisor, but I was doing many of the things that we asked supervisors to do. Making my people take their breaks. Slow down on the pallet jack. Listening to a frustrated guy who was ready to quit – understanding his paradigm, and helping him re-frame his experience. Constant radio calls to places in whatever building I wasn’t in at the time. Operating within a system that functions only with continuous intervention.

I totally knew how to set up a workable, stable process. I knew how to get all of these processes linked together to pull everything through. I knew how to build in effective quality checks.

What I was able to do was spend a few minutes at the end of my day, or during my lunch breaks (instead of eating) trying to implement some kind of simple visual control that mitigated against repeating a mistake we had just made. We attached a tag with a production sequence number (000 through 999, repeating) to each kit. That let us, and the people on the line, see if we had delivered something out of sequence.

Then, after I had delivered a yellow painted kit to go onto an otherwise blue painted unit (oops) we made a board with the production sequence numbers and the associated colors for the major components.

Then… after I had delivered (note the theme here) the wrong size of a major component to the line, we added that information to the board AND tagged those components so we could quickly distinguish one from the other.

But I was never able to address the upstream issues that were delivering short kits to us in the first place. All I could do was add steps, add time, add inventory to protect myself from those things and do my best to fix it before the main line got stopped.

We had a saying in the Army: “When you are up to your a$$ in alligators, it is hard to work on finding the best way to drain the swamp.”

Thus:

It is unreasonable to expect systems improvements when everyone is scrambling to make the system function at all. It isn’t that they don’t want to make improvements. It isn’t that they don’t know what to do. It is that there is barely time to breathe before the next problem needs to be stamped down.

And finally: A five person job requires five people. I had four people working for me. That wasn’t enough. Guess who had to fill in the rest of it? I tried my best to handle the problems so they could get into some kind of cadence on the stuff that wasn’t a problem. But (Routine+Problems) = (or greater than) 5 people in this case, and it took all of us just to navigate the rapids without dumping everyone out of the boat. If everything was running smoothly, it was probably a three person job. If we could have set up a sequenced pull from assembly all the way back through weld, it would have been a two or even one person job.

Reflection

That forklift key is still on the keyring in my pocket as a reminder of that time. What follows are some of the bigger-picture things that come to mind as I continue to construct, tear down and reconstruct my own thinking.

Attribution Error

There is a strong tendency among us humans to attribute our own failures to a poor environment, but to attribute other’s failings to individual character or capability. Yet in many cases, simply changing the venue or circumstances can allow a previously low-performer to blossom. We see this (and the opposite) all of the time in professional athletics.

Making this error is easy when we are talking about “they.”  If only they… Why don’t they… They don’t get it… “They” are people who are likely doing the very best they can within the context of the system they are in. And, as I pointed out above, changing the system from the inside is hard.

Actually that isn’t quite accurate. Changing the system is hard work.

The Pace of Change

The organization I was describing above was experiencing circumstances at the time that outpaced their ability to experiment, reflect, and adapt. Every organization has a rate at which they are able to change.

Just to make things more complicated, it is possible to learn what must be done much faster than those things can be put into place. This frustrates a lot of change agents. They see the technical changes that must take place, but often struggle against cultural barriers and obstacles. These things take much longer, and it is pretty much impossible to put them on a fixed timeline or project plan. Thus, we frame them as “resistance to change.” We know what must be done, but “they” don’t do it.

Organizations Under Stress

When an organization is under stress, there is fear of complete breakdown. People become very conservative and avoid the uncertain and unfamiliar. If they become overwhelmed just trying to get their task done, they are going to shut out any information that isn’t relevant right now. Horizontal communications break down, and the feeling of isolation increases.

At this point, all coordination has to funnel upward and then downward through the vertical linkages, as cross-functional coordination largely isn’t happening.

Now the higher leader gets overwhelmed, feeling she has to micro-manage every detail- because she does. “Why don’t they talk to each other?” Well, the structures for that were probably very informal, and now have broken down.

This Isn’t About “Them”

As I mentioned above, it is really easy to attribute the perception of dysfunction to individuals. And as people become isolated within their own task-worlds, avoiding a mistake becomes the dominate motivation. This happens even in organizations with the most benign intentions.

If you are a leader, pay attention to the emotions. If people are snippy, are pushing back on ideas as “just more work” then that saturation point may well have been reached. Pushing harder isn’t going to make things go faster, it is going to slow them down.

image

Overproduction vs. Fast Improvement Cycles

A couple of weeks ago ago I posted the question “Are you overproducing improvements?” and compared a typical improvement “blitz” with a large monument machine that produces in large batches.

I’d like to dive a little deeper into some of the paradoxes and implications of 1:1 flow of anything, improvements included.

What is “overproduction” – really?

In the classic “7 wastes” context, overproduction is making something faster than your customer needs it. In practical terms, this means that the cycle time of the producing process is faster than the cycle time of the consuming process, and the producing process keeps making output after a queue has built up above a predetermined “stop point.”

If the cycle times are matched, then as an item is completed by the upstream process, it is consumed by the downstream process.

If the upstream process is cycling faster, then there must be an accumulation of WIP in the middle, and that accumulation must be dealt with. Further, those accumulated items are not yet verified as fit-for-use by the downstream process that uses them.

The way this applies to my “Big Improvement Machine” metaphor is that we are generating “improvement ideas” faster than we can test and incorporate them into the process.

“Small Changes” Doesn’t Mean “Slow Changes”

No matter how good your solution or idea, it is just an academic exercise until it is anchored as the an organizational norm. The rate limit on improvement is established by how quickly people can absorb changes to their daily, habitual routine.

Implementing and testing small changes one-by-one is generally faster than trying to make One Big Change all at once. When we do One Big Change, it is usually actually a lot of small changes.

I hear “we don’t have time to experiment,” but when I ask what really happens if a big change is made, what I hear almost every time is they had to spend considerable time getting things working. Why? Because no matter how well the Big Change was thought through, once you are actually trying it, the REAL problems will come up.

Key Point #1: Don’t waste time trying to develop paper solutions to every problem you can imagine. Instead, “go real” with enough of the new process to start revealing the real issues as quickly as possible.

In other words, the sooner you start actively learning vs. trying to design perfection, the quicker you’ll get something working.

Slow is Smooth, Smooth is Fast

Your other objective here is to develop the skill within the organization to test and anchor changes quickly, as a matter of routine. This will take time.

When we see a high-performance organization making rapid big changes, what we are typically seeing is making small changes even more rapidly. They have learned, through practice over time, how to do this. It isn’t reasonable to expect any organization to immediately know how to do this.

Key Point #2: If managers, or professional change agents (internal or external consultants, for example) are telling people exactly what to do, this learning is not taking place.

It is critical for the organization to develop this learning skill, and they are only going to do it if they can practice. Learning something new always involves doing it slowly, and poorly at first. If your internal or external consultants are serving you, their primary focus is on developing this basic competence. Their secondary focus is on getting the changes into place. This is the only approach that actually strengthens the organization’s capability.

The same is true for an operational manager who “gets” lean, but tries to just direct people to implement the perfect flow. It will work pretty well for a while. But think about how you (the operational manager) learned this stuff: Likely you learned it by making mistakes and figuring things out. If you don’t give your people a chance learn for themselves, you limit the organization in two ways:

  1. They will never be any better than you.
  2. They will wait to do what they are told, because that is what you are teaching them to do.

Think about what you want your people to be capable of doing without your help, and make sure you are giving them direction that requires them to practice doing those things. It will likely be different than telling them what they layout should look like.

Improve your Cycle Time for Change

Coming back to the original metaphor, if you want fast changes to last, you have to work speeding up the organization’s cycle time for testing improvement ideas. Part of this is going to involve making that activity an inherent and deliberate part of the daily work, not a special exception to daily work.

Part of that is going to be paying attention to how people are working on testing their ideas. The Improvement Kata and Coaching Kata are one way to learn how to deliberately structure this work so that learning takes place. Like any exponential curve, progress seems painfully slow at first. Don’t let that fool you. Be patient, do this right, and the organization will slingshot itself past where you would be with a liner approach.

Small changes, applied smoothly and continuously become big changes very quickly.

Are You Overproducing Improvements?

Imagine a factory with a large monument machine. It takes several days to set up. When it does run, it runs very fast, much faster than you can actually use its output. Therefore, you take the excess output and store it to use later. Actually, you don’t know how many items you need to make, so you make as many as you can while the machine is available to you.

image

Some of that excess output may prove to be less useful than you thought, but there is pressure to use it all anyway since it was so expensive to produce.

After a run making items for one process, you change it over to make items for a different process, and build up a queue of output there.

When all of the output is used, it all may or may not work the way you expected it to.

Most of us would see this as a classic case of “overproduction” – overwhelming the system with excess output that hasn’t been checked for quality, that isn’t needed right now, and might or might not be useful in the future. But it seemed like good efficiency to make it while we could.

Our lean thinking tells us we want to do a few things here. Ultimately, we want to work hard to break up the batches, and make the value flow more evenly to each of the customer processes, and ultimately to the end customers. The work we must do to keep things moving smoothly and evenly will pay off in both tangible and intangible ways.

One of the primary reasons we push hard for 1:1 flow in the lean world is to enable one-by-one confirmation.

We want to test each item of output to confirm that it actually performs as expected rather than making lots of them without knowing if they are any good.

How Do You Produce Improvements?

Now, imagine doing improvements this way. What would it look like?

A process would be scheduled to receive the rapid output of the Improvement Machine.

The Improvement Machine would be set up over a period of several days to produce improvements for the target process.

Once it was running, we would run the Improvement Machine very fast for a week or so. It would produce improvements faster than the target process can really absorb them.

At the end of the run, we might test the improvements as a batch. We might not test them at all, but rather report that they have been implemented with the assumption that they will work. We would also have excess improvements stored on a to-do list for future use.

Those excess improvements might, or might not, prove to be useful, but we would have huge pressure to implement them because they are on the list.

Once the machine was done producing improvements for one process, it would be set up to produce improvements the same way for another.

We would measure how many times we were able to run the improvement machine in a year, not so much the actual sustained impact we were making.

Improvements that were made without the machine might not be measured or credited at all. Or worse, these rogue improvements might actually be discouraged since they are made by people who aren’t certified to run the machine.

Now… substitute “kaizen event” for “improvement machine” and see if it makes any sense.

Why Are Big Batches Necessary?

The reason the Large Monument Machine has to cycle batches of output to different customers is because those customer processes don’t have the internal capability to do what it does. We need an outside resource to do it.

The countermeasure we strive to apply in these cases is to identify the capability that the customer process does need. We then work hard to develop it on a scale they can incorporate into their daily work. This is typically smaller, more specialized, and scoped to their needs.

My purpose here, though, is to apply a metaphor, not to discuss the economics of large capital equipment.

When we “batch improvements” it is often for the same reason: The area that is being improved can’t do it themselves, so we have to dedicate a scarce outside resource – an improvement expert – to lead them through it. Since that improvement leader can’t be there 100% of the time, he has to work as hard and fast as he can when he IS there.

Making Improvements vs. Teaching How to Make Improvements

The countermeasure in both scenarios is the same: Develop the capability within the process. In the case of making improvements, this means asking ourselves “Why can’t they do it?”

All of these are harder than just doing it for them. But if we want improvement to flow, this is the work that must be done.

Think Big, Change Small

Anton, my Dutch friend, had a study mission group of Healthcare MBA students from the University of Amsterdam visiting Seattle last week.

Friday morning I spent about four hours with them going through the background and basics of the Improvement Kata and Coaching Kata, and worked to tie that in to what they observed in their visits to local companies. They were a great, engaging group that was fun to work with.

One thing I do to close out every session I do with a group is ask “What did we learn?” and write down their replies on a flip chart. I find that helps foster some additional discussion and consolidate learning. It also gives me feedback on what “stuck” with them.

Sometimes I get a gem that would make a good title for a blog post. The title of this post is one of those.

Think Big

Alice and the Cat

Alice went on, “Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to,” said the Cat.

“I don’t much care where…“ said Alice, “…so long as I get somewhere,” Alice added in explanation.

“Oh, you’re sure to do that,” said the Cat, “if only you walk long enough.”

The question, of course, is whether or not where Alice ends up is where she intends to go. A lot of continuous improvement activity takes this approach –  Look for waste. Brainstorm ideas. Implement them. Just take steps. And, like Alice, you will surely end up somewhere if you do this enough.

I had a former boss (back in the late 90’s) advocate this approach. “We are painting the wall with tennis balls dipped in paint.” The idea, I think, was that sooner or later all of the splotches would start to connect into a coherent color. Maybe. But, at the same time, he was also very impatient for tangible results. Actually that isn’t true. He was impatient for tangible activity which is not the same thing at all.

Direction and Challenge Establish Meaning

In her journeys through Wonderland, Alice learns that objective truth has no meaning in a world of random nonsense. The story, of course, is a parody of the culture and times of Victorian England. It does, however, reflect the frustrations many practitioners can feel when they are just trying to “make improvements.”

As one thing is “fixed,” another pops up for any number of reasons:

  • The “new” problem may well have been hidden by the “fixed” one.
  • Leadership may be chasing short-term symptoms and constantly redirecting the effort.

Day to day it just seems like random stuff, and can get pretty demoralizing.

The point of “Think Big” is that being clear about where WE (not just you) are trying to go helps everyone understand the meaning of what they are doing. That is the whole point of “Understand the Direction and Challenge” as the first step of the Improvement Kata. “What is the meaning behind what you are working on?” It is really a verification check by the coach that the coach has adequately communicated meaning to the learning.

Establish “Why” not “What”

At the same time, it is important for the organization to be clear on why improvement is necessary. I have discussed this a number of times, but keep referring back to Learning to See in 2013 where I ask “Why are you doing this at all?” as the question everyone skips past.

“Where we are going” should not simply be your model of your [Fill Company Name In Here] Production System.

No matter how well explained or understood, a model does not directly address the “Why are we doing this at all?” question that provides meaning to the effort.

It may well establish a good representation of what you would like your process structure to look like, but it does not give people any skill in actually putting these systems into practice, nor a reason to put in the effort required to learn something completely new.

Change Small

Small changes = fast progress as long as there is a coherent direction.

The classic 5 day kaizen event is often an attempt to make a radical improvement in a short period of time. Things usually look really impressive at the end of the week, and even into the next few weeks. What happens, though, is that the follow-up is usually more about finishing up implementation action items than it is working to stabilize the new process.

The problem comes from the baseline assumption that we already understand all of the problems, and our changes will solve them. We line things up, get 1:1 flow running, and yes, there is a dramatic reduction in the nominal throughput time simply because we have eliminated all of the inventory queues.

There is tons of research that backs up the assertion we can’t expect people to be creative when they are under pressure to perform. They are going to revert to their existing habits. During the event itself,  the short time period and high expectations put pressure on people to just implement stuff. People are likely to defer to the suggestions and lead of the workshop leader and install the standard “lean tools” without full understanding of how they work or what effect they will have on the process and people dynamics.

Come Monday morning, we put all of those changes to the test… at once. The people are working in a different way. The problems that will be surfaced are different. The tighter the flow, the more sensitive the system will be to small problems. It is pretty easy to overwhelm people, especially the supervisors who have to decide right now what to do when things don’t seem to be working.

That same pressure to perform exists, only now it is pressure to produce, and possibly even catch up production from what was lost during the previous week. Once again, we can’t expect people to think creatively when these new issues come up, they are going to revert to what they know.

When we do see successful “big change” it is usually the result of many small changes that have each been tested and anchored.

So why is the “blitz” approach so appealing? I think I got some insight into the reason in a conversation with a continuous improvement director in a large corporation. He had so little opportunity to actually engage and break things loose that, when he did, he felt the need to push in everything he could.

My interpretation of this goes back to the first line above: Small changes = fast progress as long as there is a coherent direction. In his case, there wasn’t coherent direction. He had a week, maybe two, to push as hard as he could in the direction he felt things should go. The rest of the time, things were business as usual.

This is why “think big” is important. It provides organizational alignment, and reduces the pressure to seize a limited opportunity and, frankly, inject chaos.

Small, Quick Changes

Because we often don’t see just how long it takes to stabilize a “quick, big change,” we tend to think that quick small changes are slower. I disagree. In my experience the opposite is true.

When there is a clear Challenge and Direction, and frequent check-ins via coaching cycles (or less formal means) on what changes are being made, no time is wasted working on the wrong things.

When small changes are made and tested as part of experiments vs. just being implemented, then there is less chance of erosion later. Rather than overwhelming people with all of the problems at once from a bunch of changes, one-by-one lets them learn what problems must be dealt with. They have an opportunity to always take the next step from a working process rather than struggling to get something that is totally unfamiliar to work at all.

That, in turn, builds confidence and capability.

In a mature organization that has practiced this for years, an outside observer might well see “big changes” being made. But that organization is operating from a base of learning and experience, and what might look big to you might not be big to them. It is all a matter of perspective.

What Do You Think?

I’m throwing this out there, hoping to hear from practitioners. What have you struggled with getting changes made that actually shift people’s behavior (vs. just implementing tools and techniques). What has worked? What hasn’t worked? I’d love to hear in the comments.

Push Improvement vs. Pull Improvement

I’m writing up a proposal for a benchmarking and study week, and just typed the term “push improvement” as a contrast to a true “continuous improvement culture.” I wanted to explore that a bit here, with you, and perhaps I’ll fill in the idea in my own mind.

Push Improvement

A few years ago I was working with a few sites of a multi-national corporation. In one of their divisions, their corporate lean office was pushing various programs into place. Each site was required to implement, and was graded on:

  • 5S
  • Jidoka
  • Heijunka
  • Toyota Kata

plus a few other things. Those are the ones I really remember. Each of these programs was separate and distinct, they had been deployed on some kind of phased time-table over a few years. They also had requirements to maintain some number of Six-Sigma Black Belts and Green Belts in their facilities, with the requirement to report on a number of projects.

They brought me in to teach the Toyota Kata stuff.

In reality, while people taking the class generally thought it was worthwhile, the leadership teams were also a little resentful that all of this stuff was being, in the words of one plant manager, “pushed down our throats.”

Even the Toyota Kata “implementation” had a specific sequence of steps that the site was expected to check off and report their progress on. In addition, there were requirements for how the improvement boards would look, including the position of the corporate logo and the colors used – all in the name of “standardization.”

At the same time, of course, the plants were also measured on their performance – financial, delivery, quality, etc. These metrics were separate and distinct from their audit scores on all of the lean stuff.

On the shop floor, they had the artifacts in place – the boards, the charts, the lines on the floor, but were struggling with making it all work. There was no integration into the management system. Each of these was a program.

I should also point out that, ironically, the plant that was getting the most traction with continuous improvement at the time was the one that was pushing back the hardest against this rote, “standard” approach.

A few years before that, I had been working (as an employee) in another multi-national company. There was a big push from the executives at the very top to develop a set of metrics they could use to determine if a site was “doing lean correctly.” They wanted a set of measurements they could monitor from corporate headquarters that would ensure that any business performance improvement was the result of “doing lean” rather than something else.

Both of these organizations were looking at this as an issue with compliance rather than developing their leaders.

Implementations like these typically involve things like:

  • Developing some kind of “curriculum” and rolling it out.
  • Requiring sites to have a “value stream map” and a “lean plan.”
  • Audits and “lean assessments” against some kind of checklist.
  • Monitoring the level of activity, such as how many kaizen events sites are running.

I have also seen cases of an underlying assumption that “if only we can explain it well enough, then managers will understand and do it.” This assumption drives building models and diagrams that try to explain how everything works, or the relationships between the tools. I’ve seen “pillar models,” puzzles, gears, notional value stream maps, and lots of other diagrams.

In summary, “push improvement” is present when implementing an improvement program is the goal. Symptoms are things such as a project plan with milestones for specific “lean tools” to be in place.

The underlying thinking is that you are doing improvement because you can, not because you must.

This is, I believe, what Jeff Liker and Karyn Ross refer to as mechanistic lean in their book The Toyota Way to Service Excellence.

Relationship to the Status Quo

One of the obstacles that organizations face with this approach is the traditional relationship to the status quo. Most business leaders are trained to evaluate any change against a financial return based on the cost. In other words, we look at the current level of performance as a baseline; evaluate the likely improvement; look at what it would cost to get to that new level and ask “Is it worth doing this?”

If the answer comes up short of some threshold of return, then the answer is “no,” and the status-quo remains as a rational optimum.

Implication: The status-quo is OK unless there is a compelling reason to change it.

For the lean practitioner, this presents a problem. We have to convince management that there is a short-term return on what we are proposing to do in order to justify the effort, time and expense. Six Sigma black belt projects are intently focused on demonstrating very high cost benefit, for example. And, honestly, if you are spending the money to bring in a consultant from Japan and an interpreter, I can see wanting some assurance there is a payback.1

If the discussions are around “What improvements can we make?” and then working up the benefit, you are in this trap. Those benefits, by the way, rarely find their way to the actual P&L unless there is already a business plan to take advantage of them.

The root cause of this thinking may well be disconnection of continuous improvement from whatever challenges the organization is facing; coupled with assumptions that a “continuous improvement program” can be implemented as a project plan on a predictable timeline.

Pull Improvement

Solving Problems

The purpose of any improvement activity is to solve problems. Real problems. In my classes, I often ask for a show of hands from people who have a shortage of problems on a daily basis. I never get any takers. Since there are usually lots of problems – too many to deal with all of them – we need to be careful to work on the right ones. The ROI approach I talked about above is a common way to sort through which ones are worth it. We can also get locked into “Pareto Paralysis”

So which ones should we work on?

Inverting this question, when someone wants to make a change, put in a “lean tool,” etc., my question is “What problem are you trying to solve?” And “we don’t have standard work” is not a problem, it is lack of a proposed solution. In these cases I might ask “…. and therefore?” to try to understand the consequence of this “lack of…” The problem might be buried in there somewhere. But if the issue at hand is trying to raise an audit score for its own sake, we are pack to “Push Improvement.”

A meeting gets derailed pretty fast when people are debating which solution should be applied without first agreeing on the problem they are solving. The Coaching Kata question “Which one [obstacle] are you addressing now?” is intended to get help the learner stay clear and focused on this.

But long before we are talking about problems, we need to know where we are trying to end up. This is why the idea of a clear and compelling challenge is critical.

Challenge First

Organizations that are driven by continuous improvement have a different relationship with the status-quo. Those organizations always have a concrete challenge in front of them. In other words, the status-quo is unacceptable. “Today is the worst we will ever be.”

Cost enters into the discussion when looking at possible ways to reach that destination. But it does not drive the decision about whether or not to try. That decision has already been made. The debate is on how to do it.

The Challenge with Challenges

“Wait a minute… we have objectives to reach too!” Yes, lots of organizations set out objectives for the year or longer. Here are some of the scenarios I have seen, and why I think they are different.

The goal setting is bottom-up. The question “What can we improve?” cascades down the organization, and individual managers set their goals for the year and roll them back up. There may be a little back-and-forth, and discussion of “stretch goals,” but the commitment comes from below. In most of the cases I have seen these goals are carefully worded, the measurements delicately negotiated, with bonuses riding on the level of attainment of these objectives. I have used the word “goal” here because these are rarely challenges or even challenging.

The goal is based strictly on hitting metrics. I have discussed the dangers of “management by measurement” a few times in the past.

A pass is given if there is a strong enough justification made for missing the goal. Thus the incentive to carefully define the metrics, and include caveats and loopholes.

There are measurements but not objectives. Any improvement is OK.

Any true challenge is labeled as a “stretch goal” meaning “I don’t really expect you to be able to reach it.”

And, sometimes the end of the year is an exercise in re-negotiating the definition of “success” to meet whatever has been achieved.

None of this is going to drive continuous improvement, nor align the effort toward achieving something remarkable or “insanely great.”

But here is the biggest difference: FEAR.

Fear of failure. Fear of committing to something I don’t already know how to achieve. Fear of admitting “I don’t know.”

And fear breeds excuses and other victim language that makes sure success or failure was beyond my control.

Fearless Challenges

So maybe that’s it. The key difference is fearless challenge. So what would that look like?

Here I defer to Jeff Liker and Gary Convis’s great book The Toyota Way to Lean Leadership. But I have seen this in action elsewhere as well.

Some key differences here:

  • The challenge comes from above. It isn’t a bottom-up “what can we improve?” It is a top-down “This is what we need to be able to do.”
  • It is an operational need, not a process specification. In other words, it isn’t the “lean plan.” The process specification is what is created to meet the challenge.
  • The challenge is an integral part of developing people’s capability. Perhaps this is the key difference.
  • There is no fear because the challenge comes with active support to meet it. That support, if done well, is both technical and emotional. We’re in this together – because we are.

Improvement = Meeting the Challenge

Given that there is a business or operational imperative established, we are no longer trying to push improvement for its own sake. We have an answer to “Why are we doing this?” beyond “to get a higher 5S score.”

Now there is a pull.

In my Toyota Kata class, I give the teams a challenge that, in the moment, is seemingly impossible. That is intentional. I hear air getting sucked in through teeth. “No way!” is usually the reply when I ask how it feels.

Then, for the next few hours, the teams are methodically guided through:

  • Grasping the current condition – understanding their process as a much deeper level.
  • Breaking down the problem into pieces, taking on one at a time. First a target condition, then specific obstacles.

Depending on how much time they have, 1/4 to 1/3 of the teams crack the problem, a few excel and go beyond, and those that don’t usually acknowledge they are close.

The teams that get there fastest are the ones who get into a quick cadence of documented experiments and learning. They see the problems they must solve much quicker, and figure out what they need to do. I tell them at the start, as I hold up my blank Experiment Records, “The teams that get it are the ones who burn through these the quickest.”

In the process of tackling the challenge, they learn what continuous improvement is really about. I don’t specify their solution. Any hints I give are about what to pay attention to, not what the solution looks like. I don’t deploy tools or give them a template for the solution. At the same time, most teams converge on something similar, which isn’t surprising.

Taking this to the real world – I see similar things. Teams taking on similar challenges on similar processes often arrive at similar looking solutions. But each got there themselves, for their own reasons, often following quite different paths.

While it seems more efficient to just tell them the answers, it is far more effective to teach them how to solve the problem. That is something they can take beyond the immediate issue and into other domains.

Pull Improvement = Meeting a Need

In my post Learning to See in 2013, I posed the question nobody asks: Why are you doing this at all? I point out that, in many cases, value-stream mapping is used as a “what could we improve?” tool, which is backwards from the original intent.

If there is a clear answer to “Why are we doing this?” or, put another way, “What do we need to be able to do that, today, we can’t?” or even “What experience do we aspire to deliver to our customers that, today, we cannot?” then everything else follows. Continuous Improvement becomes a daily discussion about what steps are we taking to get there, how are we doing, what are we learning, what do we need to do next (based on what we learned)?

This is pull. The people responsible for getting a higher level of performance are pulling the effort to get things to flow more smoothly. The mantra here is “not good enough,” but that must be the form of a challenge that inspires people to step up, not punitive.

Then it’s easy because “they” want to do it.

image

Epilogue: For the Practitioner

If you are reading this, you are likely a practitioner – someone on staff who is responsible for “continuous improvement” in some form, but not directly responsible for day-to-day operations. I say that because I know, in general, who my subscribers are.

This concept presents a dilemma because while you are challenged with influencing how the organization goes about improving things, the challenge of what improvements must be made (if it exists at all) is disconnected from your efforts.

That leaves you with trying to “drive improvement into the organization” and “be a change agent” and all of those other buzzwords that are probably in your job description.

Here are some things to at least think about that might help.

Let go of dogma. If you think continuous improvement is only valid if a specific set of tools or jargon are used, then you are already creating resistance for your efforts.

Focus on learning rather than doing. You don’t have all of the answers. And even if you did, you aren’t helping anyone else by just telling them what to do. No matter how much sense it makes to you, logical arguments are rarely persuasive, and generally create a false “yes.”

Seek first to understand. Listen. Paraphrase back. Try to get the words “Yeah, that’s right.” to come out of that resistant manager you are dealing with. Remember your purpose here is to help line leadership meet their challenges. Often those challenges are vague, are negative – as in trying to avoid some consequence – or even expressed as implied threats. You don’t have to agree, but you do need to “get it.”

That’s the first step to rapport, which in turn, is necessary to any kind of agreement or real cooperation. As a friend of mine said a long time ago: “You can always get someone’s attention by punching them in the nose, but they likely aren’t going to listen to what you have to say.” Making someone wrong is rarely going to increase their cooperation.

All of this, by the way, is harder than it sounds. I’m still learning these lessons, sometimes multiple times. I’ve been on my own journey of explicit / deliberate learning here for a couple of years.

We have a couple of generations now of improvement practitioners who have been trained with the idea that “lean is good” (or Six Sigma is good, or Theory of Constraints is good, or…). Therefore, it follows, that these things need to be put into place for their own sake – because all of the best companies do them.

This approach, though, reflects (to me) a shallow understanding of what continuous improvement is all about. It skips the “Why?” and goes straight to “How” and “What.” My experience has also been that relatively few of the practitioners steeped in this can actually articulate how the mechanics of these systems actually drive improvement on a daily basis after all of the mechanics are in place beyond a superficial statement like “people would see and remove waste.”

It seems that implementing the mechanics is equated with improvement, when in reality, those mechanics are simply an engine for starting improvement.

Yes, the mechanics are important, but the mechanics are not the reason. We are leaving out the people when we have these discussions. What are they doing every day (other than “following their standard work”)? How do these mechanics actually help them move, as a team, toward a goal they cannot otherwise attain?

————–

1In its worst manifestation, this thinking can be a cancer on the integrity of the company, for example, GM has had a couple of scandals where it has been revealed that they calculated the ROI of fixing a safety defect vs. the cost of paying off wrongful death lawsuits. Don’t even go there!

The Lean Plateau

Many organizations trying to deploy lean get great results for the first couple of years, then things tend to stall or plateau. This is in spite of continued effort from the “lean team.”

image

We Still Don’t Have a Lean Culture

This was the comment by the Continuous Improvement director of a pretty large corporation. They had been running improvement events for several years, everyone had pretty much been through one.

Each of the events had made pretty good strides during the week, but the behavior wasn’t changing. Things were eroding behind the events, even though everyone agreed things were better.

It was getting harder and harder to make more progress. They had hit the plateau.

What Causes the Lean Plateau?

While it might not be universal, what I have seen happen is this:

The implementation is led by a small group of dedicated technical experts. They are the ones who are looking for opportunities, organizing the kaizen event teams, leading workshops, and overseeing the implementation of lean techniques.

While this works in the short term, often the last implemented results begin to erode as soon as the lean experts shift their attention elsewhere.

At first, this isn’t noticed because the implementation is proceeding faster than the erosion.

However the more areas that are implemented, the faster the erosion becomes. There is simply more “surface area” of implemented areas.

At some point, the rate of erosion = the rate of implementation, and the lean team’s efforts start to shift from implementing new areas to going back and re-implementing areas that have eroded.

The lean team’s capacity becomes consumed re-implementing, and they spend less and less time going over new ground. They are spending all of their time “spinning the plates” and no time starting new ones.

Key Point: The lean plateau occurs when the level of implementation effort and the rate of erosion reach an equilibrium.

In the worst scenario, sooner or later financial pressures come into play. Management begins to question the expense of maintaining an improvement office if things aren’t getting significantly better on the bottom line. What they don’t see is that the office is keeping things from getting worse, but they aren’t called the “maintain what we have office” for a reason.

Breaking the Lean Plateau

When I was a lean director in a large company, we were confronting this very question. We had a meeting to talk about it, and quickly started blaming “lack of management commitment.”

Leaders Weren’t Stepping Up

In any given area, after education and planning, our last step was always to have a major effort to put flow production into place. Since the performance of the area would be substantially better, we expected the leaders to work hard to continue that performance.

What actually happened in an area was “implemented,” was the line leaders in that area – supervisors, managers, senior managers – weren’t working to look for erosion and correct it.

Instead, when a problem was encountered, they were making some kind of accommodation that compromised flow. The effect of the problem went away, but things had eroded a bit.

What we thought we learned: The weren’t “supporting the changes.”

What we really learned – though it was only realized in hindsight: This is the mechanism of “erosion.”

Flow production is specifically designed to surface small problems quickly. If there is no mechanism to detect those problems, respond, correct, and learn, then the only thing leaders can do is add a little inventory, add a little time, add an extra operation.

As Hirano put it so well decades ago:

All waste is cleverly disguised as useful work.

But Our Current Condition was Incomplete

There were outliers where it was working.

As we talked, we realized that each of us had experience with an outlier – one or two areas that were actually improving pretty steadily. Trying to understand what was different about these bright spots, we looked for what they all had in common. Surprisingly:

  • They were areas with no dedicated improvement teams.
  • They ran few, if any, 5-day kaizen events.
  • They were geographically close to one of us (senior “Directors”).
  • One of us had decent rapport with the area management team.
  • We each had an informal routine with them: We would drop by when we had time, and walk the work area with the area leader. We could discuss the challenges they were facing, how things were operating, go together to the operations concerned, and look at what was happening. We could ask questions designed to “sharpen the vision” of the leader. Sometimes they were leading questions. Most of the time they were from genuine curiosity.
  • By the time we left, there was generally some action or short term goal that the leader had set for himself.

Even though we “lean directors” had never worked together before, our stories were surprisingly consistent.

The Current Condition (Everywhere Else)

aka Dave’s Insight

The next logical question was “If that is what we do, what happens everywhere else? What do the lean staff people do?”

Now we were trying to understand the normal pattern of work, not simply the outcome of “the area erodes because the leaders don’t support the changes.”

Dave confidently stood up and grabbed the marker. He started outlining how he trained and certified his kaizen leaders. He worked through the list of skills he worked to develop:

  • Proficiently deliver the various topical training modules – Waste vs. Value Add; Standard Work; Jidoka; Kanban and Pull;
  • “Scan” an area to find improvement opportunities.
  • Establish the lean tools to be deployed.
  • Organize the workshop team.
  • Facilitate the “Vision”
  • Manage the “Kaizen Newspaper” items
  • etc

and at some point through this detailed explanation he stopped in mid sentence and said something that brought all of us to reality (Please avert your eyes if you are offended by a language you won’t hear on network TV):

“Aw… shit.”

What we realized more or less simultaneously was this:

Management wasn’t engaged because our process wasn’t engaging them.

Instead, our experts were essentially pushing them aside and “fixing” things, then turning the newly “leaned” area over to the supervisors and first line managers who, at most, might have participated in the workshop and helped move things around.

Those critical front line leaders were, at best left with a to-do list of ideas (kaizen newspaper items) that hadn’t been implemented during the 5 days.

There was nothing in the structure to challenge them to meet a serious business objective beyond “Look at how much better everything runs now.” The amount of improvement was an after-the-fact measurement (or estimate) rather than a before-we-begin imperative.

So it really should be no surprise that come Monday morning, when the inevitable forces of entropy showed up, that things started to erode. The whole system couldn’t have been better designed for that outcome.

Why the Difference in Approach?

In retrospect, I don’t know. Each of us senior “lean directors” had been taught, or heavily influenced by, Toyota-experienced Japanese mentors, teachers, consultants.

When we engaged the “outlier” areas, we were following a kinder, gentler version of what they had taught us.

On the other hand, what we were teaching our own people was modeled more on what western consultants were doing. Perhaps it is because it is easier to use forms and PowerPoint for structure than to teach the skills of the conversations we were having.

Implement by Experts or Coached by Leaders

That really is your choice. The expert implementation seems a lot easier.

Unfortunately the “rapid improvement event” (or whatever you call them) system has a really poor record of sustaining.

Perhaps our little group figured out why.

There are no guarantees. No approach will work every time. But a difficult approach that works some of the time is probably better than an easy path that almost never works.

Using Takt Time to Compute Labor Cost

How can I use takt time in computing labor cost?

Sometimes the searches that lead here give us interesting questions.

While simple on the surface, this question takes us in all kinds of interesting directions.

Actually the simplest answer is this: You can’t. Not from takt time alone.

Takt Time

Takt time is an expression of your customer’s requirement, leveled over the time you are producing the product or service. It says nothing about your ability to meet that requirement, nor does it say anything about the people, space or equipment required to do it.

Cycle Time

Cycle time comes in many flavors, but ultimately it tells you how much time – people time, equipment time, transportation time – is required for one unit of production.

Takt time and cycle time together can help you determine the required capacity to meet the customer’s demand, however they don’t give you the entire story.

In the simplest scenario, we have a leveled production line with nothing but manual operations (or the machine operations are trivially short compared to the takt time).

If I were to measure the time required for each person on the line to perform their work on one unit of the product or service and add them up, then I have the total work required. This should be close to the time it would take one person to do the job from beginning to end.

Let’s say it takes 360 minutes of work to assemble the product.

If the takt time says I need a unit of output every 36 minutes, then I can do some simple math.

How long do I have to complete the next unit?  36 minutes. (the takt time)

How long does it take to complete one full unit?  360 minutes (the total manual cycle time)

(How long does it take) / (How long do I have) = how many people you need

360 minutes of total cycle time / 36 minutes takt time = 10 people.

But this isn’t your labor cost because that assumes the work can be perfectly balanced, and everything goes perfectly smoothly. Show me a factory like that… anywhere. They don’t exist.

So you need a bit more.

Planned Cycle Time (a.k.a. Operational Takt Time and “Actual Takt”)

How much more? That requires really understanding the sources of variation in your process. The more variation there is, the more extra people (and other stuff) you will need to absorb it.

If we don’t know, we can start (for experimental purposes) by planning to run the line about 15% faster than the takt time. Now we get a new calculation.

85% of the takt time = 0.85 x 36 minutes = ~31 minutes.  (I am rounding)

Now we re-calculate the people required with the new number:

360 minutes required / 31 minutes available = 11.6 people which rounds to 12 people.

Those two extra people are the cost of uncontrolled variation. You need them to ensure you actually complete the required number of units every day.

“But that cost is too high.”

Getting to Cost

12 people is the result of math, simple division that any 3rd grader can do. If you don’t like the answer, there are two possible solutions.

  1. Decide that 360 / 30 = something other than 11.6 (12). (or don’t do the math at all and just “decide” how many people are “appropriate” – perhaps based on some kind of load factor. This, in fact, is a pretty common approach. Unfortunately, it doesn’t work very well for some reason.
  2. Work to improve your process and reduce the cycle time or the variation.

Some people suggest slowing down the process, but this doesn’t change your labor cost per unit. It only alters your output. It still requires 360 minutes of work to do one unit of assembly (plus the variation). Actually, unless you slow down by an increment of the cycle time, it will increase your labor cost per unit because you have to round up to get the people you actually need, and/or work overtime to make up the production shortfall that the variation is causing.

So, realistically, we have to look at option #2 above.

This becomes a challenge – a reason to work on improving the process.

Really Getting to Cost

Challenge: We need to get this output with 10 people.

Now we have something we can work with. We can do some more simple math and determine a couple of levers we can pull.

We can reverse the equation and solve for the target cycle time:

10 people x 30 minute planned cycle time-per-unit = 300 minutes total cycle time.

Thus, if we can get the total cycle time down to 300 minutes from 360, then the math suggests we can do this with 10 people:

300 minutes required / 30 minutes planned cycle time = 10 people.

But maybe we can work on the variation as well. Remember, we added a 15% pad by reducing the customer takt time of 36 minutes to a planned cycle time (or operational takt time, same thing, different words) of 30 minutes. Question: What sources of instability can we reduce so we can use a planned cycle time of 33 minutes rather than 30?

Then (after we reduce the variation) we can slow down the process a bit, and we could get by with a smaller reduction in the total cycle time:

330 minutes required / 33 minutes planned cycle time = 10 people.

(See how this is different than just slowing it down? If you don’t do anything about the variation first, all you are doing is kicking in overtime or shorting production.)

So which way to go?

We don’t know.

First we need to really study the current process and understand why it takes 360 minutes, and where the variation is coming from. Likely some other alternatives will show themselves when we do that.

Then we can take that information, and establish an initial target condition, and get to work.

Summarizing:

  • You can’t use takt time alone to determine your labor cost. Your labor cost per unit is driven by the total manual cycle time and the process variation.
  • With that information, you can determine the total labor you need on the line with the takt time.
  • None of this should be considered an unalterable given. Rather, it should be a starting point for meeting the challenge.

And finally, if you just use this to reduce your total headcount in your operation, you will, at best, only see a fraction of the “savings” show up on your bottom line. You need to take a holistic approach and use these tools to grow your business rather than cut your costs. That is, in reality, the only way they actually reach anywhere near their potential.

 

 

 

Another Homework Question

Another interesting homework question has shown up in the search terms. Let’s break it down:

23. if the slowest effective machine cycle time in a cell is 55 seconds and the total work content is 180 seconds, how many operator(s) should operate the cell so that labor utilization is at 100%?

I find this interesting on a couple of levels.

At a social level, the idea of cutting and pasting a homework question into Google hoping to find the answer is… interesting. Where is the thinking?

What are we teaching?

The question is asking “How many people do we need to run as fast as we can?” (as fast as the slowest machine). But how fast do they need to run? Maybe they only need a part every 95 seconds. If that is true, then I need fewer people, but I am going to run the slowest machine even slower.

In other words, “What is the takt time?” What does the customer need? How often must we provide it?

Then there is the “labor utilization” metric, with a target of 100%. Assuming the planned cycle time is actually 55 seconds (which it shouldn’t be!), we need 3.3 people in this work cell. (180 seconds of labor cycle time / 55 seconds planned cycle time: “How long does it take?” / “How long do you have?” = Minimum Required Capacity)

How about improvement? What do we need to do to get from 3.3 people to 3 people? We can solve for the labor cycle time.  55 seconds of planned cycle time * 3(people) = 165 seconds of total labor. So we need to get that 180 seconds down to a little less than 165 seconds.

Now we have a challenge. We need to save a bit over 15 seconds of cycle time. That might seem daunting. But we don’t have enough information (the current condition) to know where to begin. Then we can establish the next target condition and get started making things better.

These types of questions bother me because they imply all of these things are fixed, and they imply we run “as fast as we can” rather than “as fast as we must.”

Edit: Today I saw two more searches for:

total work content divided by slowest machine cycle time

so it looks like at least two others are working on the same assignment.  🙂

Thoughts?