Month: October 2009

Posted on

Continuous Erosion

“Sustaining the gains” is a frequent topic of discussion in the continuous improvement world. Often the discussion degenerates into a rant about “management commitment.”

But in the real world, people generally don’t sabotage improvements on purpose. (Though I have seen it happen, but only once.) The mechanism is far more subtle.

Before we get into what happens after improvements are made, let’s look at a common improvement process itself.

In many companies, the primary method for making improvements is through special events or projects. These are usually planned, organized and led by a staff specialist.

Although the exact methods and words vary, the general process usually looks something like this:

  • Identify an opportunity, select an area for improvement.
  • Analyze the current state.
  • Select an improvement team.
  • Teach the team members how to apply the improvement tools.
  • Facilitate the development of improvement ideas.
  • Work with the team members to implement them.
  • Wrap up with a report or presentation, including remaining action items for management.

A variation on this is where the team is chartered, and it is up to them to identify an opportunity. This approach was more common in the late 1980’s than it is today.

This process actually works. It is capable of making pretty dramatic changes over a short period of time, often only a few days.

So why do the results erode? Or put another way, what is the problem?

Take a look at the routine decisions that are made during normal work, especially the ones that result in some change to the process. Those decisions must be made, because people have to get something done. The question comes down to whether those decisions result in improving the new process, or eroding it somehow.

Once things are in operation, some kind of unforeseen event always happens. Guaranteed. It can be something that the improvement team didn’t think of. It can be a piece of malfunctioning equipment. Maybe there is a material shortage or a defective part is delivered. The same things happen in administrative processes, only the words are different. Incomplete information arrives.

It could even be a deliberate decision. A production rate change. A software upgrade. Making room for some other activity.

All of these things, no matter how small or inconsequential, force decisions to be made. “How do we deal with this this and get production going again?”

The person making that decision is either:

  1. Fully capable of applying kaizen principles, and applies them in a solution to the problem.
  2. Is not fully fully capable of applying kaizen principles, but knows that, and seeks assistance in finding a solution to the problem.
  3. Is not fully capable, may or may not know this, and does the best he can to get production back on track.

Both (1) and (2) result in making the system better, more robust and more responsive.

(3) usually results in a little bit of erosion. Variation is accommodated, things are made a bit more complex, the layout is now less than optimal, the old process does not work as designed anymore so the team member must improvise a bit. That, in turn, introduces more variation into the process, and usually drives a cascade of these little decisions.

If there is no mechanism for problem escalation (and if there was, we would likely be in (1) or (2) in the first place), then this becomes the new way, and things are steadily creeping closer to where they were before the event happened.

Given enough time (which can be amazingly brief), the process reverts back to where it was, or morphs into something else entirely – but equally wasteful.

Meanwhile the improvement specialists have moved on to the next project. Even if the local leader did ask for assistance, they might not be available, or worse, they tell him to figure it out.

Follow this with an “audit” that dings the local leader for “not supporting the changes” and wonder why he is less than enthusiastic about this kind of help.

Here is the question I want to leave hanging out there:

What was the intent of the kaizen event? (and was that intent accomplished?)

Posted on

Notes From a Kaizen Event

I was cleaning out some old stuff and came across a folded piece of paper with notes on it. They were from my parting comments to a kaizen event team that had put in a great week with spectacular results. They had started out wanting to improve the delivery of WIP to and from the warehouse.

When we went to the shop floor to see the current situation, what I saw was much more opportunity. It took a little work, especially with the area manager, but by the end of the week they had gone from needing 5 work cells with 6 people each – plus more to meet the holiday seasonal production – to 4 production cells with 5 people each, that could comfortably meet the rush. Not bad for a week’s work.

That’s the background.

When I look at old notes like this, I am always comparing what I knew then with what I know now. Now and than I turn up something that gives a hint that I knew what I was doing.

These comments were as much for the rest of the audience as they were for the team members themselves. After all, they knew what they did, and were fully aware of what they had to do next. But the other teams, and their collective bosses, needed to hear it as well.

  • Wow – great team. You caught flow fever early in the week and ran with it. You make me look like I knew what I was doing – thank you.
  • You connected the operations into a smooth flow.
  • Now you can begin the process of kaizen. Stick with it, stay on the shop floor, and work to stabilize the work. Many problems will come up. Help the work teams learn how to see them and solve them.
  • If you can save, and stabilize, a quarter of a second every day, in three months you can get another 20% of productivity. Think about that – and do the math for yourself.

What made this work?

First and foremost, we had the operational manager there, fully participating. He was skeptical at first, but once I sat down with him and went through his production requirements, step by step, he began to see things in terms of takt times and production leveling rather than just quantities to push out the door. That was a big shift.

The other big thing was having  the team work off line for a few hours to construct a mock-up of a “typical” work cell. Then, without worrying a bit about the takt time, work to minimize the cycle time of one person going through the complete cycle. They learned for themselves that to save time you must study motion. We went through three or four cycles of granularity – every time they thought they had “the” solution, we introduced another tool to see the next level of extra motion. Through this exercise, they gained confidence that it was entirely possible to make a dramatic improvement in the “optimal layout” that they already had.

After that, it was a matter of getting to work. They watched the actual operators, and now could see the excess motions that were being driven by the way the work was arranged. They started making little adjustments – always being respectful of the workers. “We’d like to try something different here, just to see if it works better for you. May we just try something?”

That “May we try this?” attitude introduced something into the dynamic that doesn’t show up often enough – humility. Rather than these managers saying “We’ve got a better way, do it like this.” they were saying “We really don’t know if this will work or not,” and asking not only permission to try, but for input on whether it worked, or how it could work if it wasn’t quite there.

A lot of changes got implemented, but there was no arguing or friction because everything was just an experiment to see if it would work or not.

In the end, I saw something I had never seen before – the manager put in a budget request for a reduction, because he knew he could  get it done with less, or at least figuring out how was within his reach.

That scrap of paper reminded me of a pretty good week.

Posted on

Problems Hidden In The Open

We were down on the shop floor watching an assembly operation. The takt time was on the order of three hours. The assembler was new to the task, and the team leader periodically came by and asked if he was “doing OK.” The reply was always in the affirmative.

As the takt time wound down to under five minutes to completion, this operation was the only one not reporting “Done.”

The count down hit zero, things went red, the main line stopped, and the line stop time started ticking up.

The team leader, other assemblers, the supervisor began pitching in to assist. Between them, the job was completed in about 10 minutes, and the line restarted.

So, again, my favorite question:

What’s the problem?

Lets try breaking it down to four key questions.

  1. “What should be happening?”
  2. “What is actually happening?”

    3. The above two questions define the gap.

  3. “Why does the gap exist?”
  4. “What are we doing about it?”

These questions simply re-frame PDCA, but without so much abstraction.

So, in this situation:

What should be happening?
Two things come to mind immediately.

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

For this to work, though, the team member needs a clear and unambiguous way to answer a key question of his own: Am I on track to finish on time? Ideally the answer to this question is a clear “Yes” or a clear “No,” with no ambiguity or judgment involved. (Like any “Check” it should produce a binary result.)

On an automobile line with a takt time on the order of 55 seconds, the assembler can get a good sense of this. If he loses more than three or four seconds, he isn’t going to make it. But “a good sense” isn’t good enough.

Even in this fast-moving situation, you will see visual indicators that help the team member answer this question. Take a look at this photo.

toyota-assy

See the white hash marks along line at the bottom of the picture? Those mark off the moving line work zone into ten increments of about 5 ½ seconds. The assembler knows where he should be as he performs each task. If he is a hash mark behind, he isn’t going to finish on time. Pull the andon. We can safely say that, in this example, we have accomplished (1) and (2) above.

With longer takt times, it is much tougher for a human to have a good sense of how much time will be required to complete the remaining work. That makes it that much more critical that some kind of intermediate milestones are clearly established and linked to time.

What would be a reasonable increment for these checks? –> How far behind are you willing to let your worker get before someone else finds out? I’d say a good starting point is at the point when he can’t recover the time himself, the problem is no longer his. Following the standard work is the responsibility of the team member. Recovering to takt time is the team leader’s domain. At the very least, he is the one who pitches in and helps, or gets someone else to do so. But he can’t do this if he doesn’t know there is a problem.

So – what should be happening?

The team member must have continuous positive confirmation that he is on track to complete the work on time. With the failure of that positive confirmation, he should pull the andon and get assistance.

The team member must call for assistance (“pull the andon”) if his work falls behind the expected progress for any reason whatsoever.

What is actually happening?

In our example, the team member didn’t get help until it was too late. In fact, he verbally assured the team leader he was “OK” on a couple of occasions. The line stop was irrefutable evidence of a problem. That was a good thing. This company has a takt time, and runs to it. Think of what would have happened if they didn’t. It might take hours, or days, before this problem surfaced. (We are nowhere near the root cause yet. The line stop is just evidence of a problem, not the problem itself.)

Why does the gap exist?

It is a hell of a lot harder to answer this question than the other two. In this case, you are going to have to peel back a lot of layers before you get to the actual, systemic, root cause. But in the immediate sense, with a takt time bordering on three hours, there is really no realistic way a worker can judge if he has fallen too far behind to catch up. The fact that, in this case, the assembler was still learning the job, and that just compounds the situation.

From casual observation – when the team leader visited, he asked if things were OK and accepted the reply – I would start to investigate whether the team leader had a good sense himself of where the work should be at his regular check points… if he has regular check points at all.

But all of this is speculation, because after 10 minutes of watching the initial response to the line stop, our little group had moved on. I am mentioning these things as possibilities because you likely have the same issues in your shop. (And if you don’t have a rigorous sense of takt time, it is equally likely you don’t know about those issues even at the level we saw here. At least THIS company can see the evidence of the problem. That is a credit to their visual controls.)

What are we going to do about it?

Obviously there are a couple of immediate things that can be addressed to at least contain the problem. (That is, convert a hard line stop into multiple andon calls so the actual problems are seen earlier.)

I would want to establish a regular routine for the team leader’s checks. His leader standard work. At regular intervals, he should be checking progress of the work. How often? How far behind do you want the assembly to get before you are certain someone finds out about the problem? In this case, even every 20 minutes is less rigorous than the hash marks on the auto assembly line. But it would be a start.

So we have the team leader coming by every 20 minutes.

But he can’t just ask “How is it going?” We clearly saw that didn’t work. It isn’t that the assembler lied to him, it is that the assembler didn’t know because there was no standard.

What work should be complete 20 minutes into the work cycle? At 40 minutes? At 60? What verifiable facts can the team leader check by observation? There are a lot of ways to do this, most of them very simple and non-intrusive. Think it through.

But wait – now the team leader himself has standard work. What cues him to do it? Is he supposed to notice that 20 minutes has elapsed? In this case, the company already has a pretty sophisticated andon and sound system. It would be a pretty simple matter to put in an audible signal that told the team leader to make his checks. But, again, that is just one solution. I can think of a couple of others. Can you?

What is the team leader checking for? This is a critical question.

Think about it.

What was the original answer to “What should be happening?” (which is “the standard”)

We said:

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

We want the assembler himself to be checking #1.

So why do we have the team leader check?

So he can verify that the assembler is pulling the andon when he should. This is important because it is human nature not to ask for help until it is too late. This isn’t limited to factory floors. How many cardiac patients die because they ignored the warning symptoms for fear that it isn’t serious enough to get help?

It isn’t enough to ask the team member to call for help. You have to expect it, encourage it and require it.

Interestingly enough, as I was writing this post, John Shook posted his story about converting the culture at NUMMI.

A cornerstone of Respect for People is the conviction that all employees have the right to be successful every time they do their job. Part of doing their job is finding problems and making improvements. If we as management want people to be successful, to find problems, and make improvements, we have the obligation to provide the means to do so.

But, some of our GM colleagues questioned the wisdom of trying to install andon at NUMMI. “You intend to give these workers the right to stop the line?” they asked. Toyota’s answer: “No, we intend to give them the obligation to stop whenever they find a problem.” [emphasis added]

What was the problem in our example? We don’t know yet. We certainly can’t start looking for causes.

But the evidence of a problem was that the team member could not complete the work in the time expected. That is, he was not successful doing the job. And the line stopped because the support system failed to pick up the fact that he was falling behind until it was too late to recover.

It really does come down to respect for people.