In The Chalk Circle – Page 5

May 21, 2010January 9, 2019

Takt Time Is Local

There was an interesting search in my logs today.

[does a system have a single takt time or multiple]

I always figure that if one person is looking, others are also curious, so let’s address it and maybe there will be a better search result for the next Googlenaut out there.

Takt time is local.

It is calculated based on the demand from your customer.

This is a critically important concept because for takt time to be of any use, it has to be relevant to the people who are actually doing the work.

Example 1:

A factory has four final assembly lines that feed into shipping.

There are 420 minutes of working time in the day, and total aggregated leveled output is 350 units of production.

What is the takt time?

For shipping, it is straight forward. The customer takt time is:

420 minutes / 350 units shipped = 72 seconds

So for shipping to stay on task, their process must be capable of packing and loading one unit every 72 seconds. If they can’t consistently achieve that, they are falling behind.

What about the assembly lines?

You don’t know, because you don’t know what each of them is expected to produce. You could say that the factory takt is 72 seconds, but that does not pass the “so what?” test for the people working on those lines. But if you know that:

Line A’s leveled production is 75 units
Line B’s leveled production is 50 units
Line C’s leveled production is 100 units
Line D’s leveled production is 125 units

then you can determine a meaningful takt time for each of those lines.

Line A: 336 seconds
Line B: 504 seconds
Line C: 252 seconds
Lind D: 201 seconds

In reality, I am going to run these lines a little faster, but that is a different topic entirely.

Now we have a takt time that actually matters. It reflects the work cycle that must be achieved for that line to meet its obligation to its customers.

Example 2:

Upstream there are fabrication or other feeder processes. We have not yet gotten them into directly linked flow.

Process E feeds one part to each unit produced on Line B; and one part on every FIFTH unit on Line C. What is the takt time?

Line B needs 50 parts. Line C needs (100 / 5 =) 20 parts for a total of 70 units of output.

So Process I has a takt time of (420 minutes / 70 units of output =) 360 seconds.

Value stream mapping is very useful for untangling this. Hopefully you can also start to see one of the reasons we work so hard to level volume and mix.

This isn’t complex stuff, but on the other hand, if you oversimplify it then it becomes meaningless. Remember, this is not about OUTPUT, it is about testing whether your process has succeeded each and every time it is carried out. You can only do that if you know what is expected right then and there.

Go to your shop floor. Watch the work. Can you tell, with each unit of output, whether the team member was successful that time? (More precisely, can you tell whether you were successful in giving that team member what she needed to succeed!). If you can’t tell, I guarantee that the people doing the work have no idea, which means you are leaving them to guess. Not a good thing.

October 1, 2009January 9, 2019

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.

October 1, 2009January 9, 2019

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.

“What should be happening?”
“What is actually happening?”

The above two questions define the gap.

“Why does the gap exist?”
“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.

The work should be complete on time.
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:

The work should be complete on time.
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.

September 16, 2009January 9, 2019

Audits vs. Leader Standard Work

5S audits, standard work audits, and for that matter ISO-900x audits, are a frequent source of questions in various online discussion forums. At the same time, the topic of “leader standard work” comes up frequently, as it did in a recent question / comment on “Walking the Gemba.”

I think the topic is worth exploring a bit.

Let’s start with audits.

Typically the purpose of an audit is to check compliance with a standard. The auditor has a checklist of some kind that defines various levels of compliance. He evaluates the current situation against the checklist, and produces a score, a report of discrepancies, a pass/fail evaluation of some kind.

So, for example, a typical 5S audit would assign various criteria in each of the 5 ‘S’ words, and assign a 1-5 scale against each of them. Periodically, the person responsible for 5S will come into the work area, do an audit, and post the score. Often there is a campaign to “get to level 3” or something.

Although there are fewer boilerplate checklists out there, “standard work audits” tend to be pretty similar, at least the ones I have seen.

Further up the scale is something like an ISO 900x audit, or an “Class-A MRP II” audit or a corporate “lean assessment.” These are often done by outside agencies to certify the organization. There is a lot of work up front to pass the audit, a plaque goes on the wall, and everybody is happy.

So what’s the problem? (this is turning into one of my favorite questions)

The key is in the difference between a “check” and a “countermeasure.”

A countermeasure is a change or adjustment to the system itself so that the root cause of a problem, or at least its effect, is eliminated.

Audits, on the other hand, actually change nothing about the underlying system. All they do is assess the current state against some (presumed) standard.

Yet so many organizations try to use “audits” as a means to alter the system.

What an audit is good for (if it is planned and performed well – a big assumption) is to CHECK to see if the other things you are doing are working. But, by itself, it is “management by measurement.” People will do what they must to pass an audit (if it even matters that much to them), then go back to what they were doing before.

Leader Standard Work operates at a much lower level of granularity, and looks for different things. Think of the analogy in a previous post about cost accounting:

When dieting, standard cost accounting would advise you to weigh yourself once a week to see if you’re losing weight. Lean accounting would measure your calorie intake and your exercise and then attempt to adjust them until you achieve the desired outcome.

So, to paraphrase, audits are weighing yourself once a week (or once a quarter!) to see if you are losing weight. Leader standard work, on the other hand, is a process to continuously verify that the calorie intake is as specified, and the exercise is as specified, while those things are being done.

That, in turn, implies that there is a daily plan for calorie intake, and a daily plan for exercise. Without those specifications, there is nothing to check.

Leader standard work defines what the leader will check, when it will be checked, and how it will be checked. It also defines how the leader will respond if there is a problem.

He is looking for solid evidence of control.

Are things going as planned?

Is anything disrupting the work cycles or flow of material?

Are quality checks being made as specified?

And, in my opinion, the most important: Are problems being handled correctly, or worked around?

This is important because a culture of working around problems is one in which problems are routinely hidden, often without malice and with the best of intentions. But hidden problems remain, come up again tomorrow, and become part of the routine, adding a little waste, a little friction, making the system a little worse every day.

The typical effort to “pass an audit” reinforces this – it actually hides problems, and the auditor’s job is to ferret them out. This is the exact opposite of the kind of problem transparency we need.

It is human nature to work around problems, and it is the default behavior, everywhere. It takes constant leader vigilance, coaching, response to prevent it.

August 23, 2009January 9, 2019

The Lean Manager: Part 2 – The Basics

This is Part 2 of a multi-part review. Part 1 is here.

In my review of Kaizen Express back in May, I took LEI to task for two things – First, I didn’t feel Kaizen Express contributed anything really new to the body of knowledge. I would have been satisfied if it had more clearly explained what had been said before, but it didn’t do that either. Second, and more importantly, I felt that Kaizen Express, and the LEI in general, were propagating the conception that the tools were what defined “lean” and that “the tools” were “the basics.” I disagreed on both points, and still do.

I am now about halfway through The Lean Manager, and I believe this book is addressing those issues – and hopefully challenging some of the thinking within the publishers. In other words, in its content, this book is everything that Kaizen Express isn’t. Get it. Read it. Do what it says, and you will actually be implementing the basics.

What makes this different? Instead of revolving around technical descriptions of the tools, this book clearly shows the proper relationship between the tools and the two most important aspects of what makes the Toyota Production System work:

Leaders (and how they lead and what they lead – and it isn’t implementing the tools)
People (yes, other books pay lip service by mentioning shop floor engagement, but The Lean Manager is all about shop floor engagement)

The authors start to hammer home the point in Chapter 2, Everybody, Every Day. In one of the many lecturettes they use to convey the key points via their characters, Amy, a corporate consultant, sums it up:

“Everybody, everyday solving problems, that’s the only answer to the Pareto dilemma. You’ve got to visualize two flows in the plant. One: the product flow[. . .]. Two: the problem flow to the person who finally solves the problem. [. . .] you shouldn’t funnel all problems to your key technical people. You should protect them to work on the really difficult issues. What you have to organize is the problem solving in the line!”

And with that, the rest of the story follows – this fictitious plant manager under fire in this fictitious company sets out to do that.

The subsequent chapters (so far – remember, I haven’t finished the book yet) are Go and See, which hammers home the importance of the leaders – all of the leaders being present, not just to witness problems, but to ensure they are being solved by the right people, in the right way. Further, they must break down any barriers which impede that flow. And it’s not just the leaders. Ultimately, the entire shop floor is organized so that everyone is immersed in genchi genbutsu every time a task is carried out or work is performed. This becomes the check in PDCA.

Chapter 3 is titled Managing is Improving and begins the confront the psychological and organizational aspects of the changes that are now coming to a head in the story. This part requires the most creativity on the part of the authors, as it is an entirely human process. Because it is a human process, not a technical one, it is impossible to write a technical manual on how to do it. It requires knowledgeable, dedicated leadership that is humble enough to stake out a position that might be wrong, knowing that doing so improves the chance of learning something.

And that has been the issue in our industry. It is far, far easier to describe the tools in excruciating detail than it is to confront the leadership and organizational change issues. And because the technical descriptions predominate the literature (including, and especially what has come out of LEI for the last 10+ years), it is far easier to believe that “implementing the tools” is something that leaders can delegate to specialized technical staff.

This book, so far, is (rightly) turning that thinking on its ear.

Continued at Part 3.

May 28, 2009January 9, 2019

How The Sensei Teaches

In a previous post, I talked about Steven Spear’s observation about how a sensei saw a process and the problems. Jeffery Liker, Mike Hoseus and David Meier have done a good job capturing how a sensei teaches and summed it up in a diagram in the book Toyota Culture. (for those of you following at home, the diagram is figure 18.9 on page 541).

I want to dissect this model a bit and share some of the thoughts I had.

This is the whole diagram:

How a sensei teaches

This diagram strikes me in a couple of ways.

Let’s zoom in to the left hand side.

sensei-do-loop1

I’m calling the part I’ve highlighted in red the “sensei do-it-loop.” That is, the sensei says “Do this,” the students do it, then the sensei says “Now, do this.” Repeat.

While this first loop is the starting point, all too often, it is also the ending point.

And in this loop, process improvement actually happens, everybody applauds at the Friday report-out. The participants may even prepare a summary of key learning points. And perhaps, as follow up, they will apply the same tools in a similar situation. (As much as I hope for this outcome, though, it doesn’t happen as often as I would like.)

A lot of consulting engagements go on this way for many years. Some go decades. I am sure processes improve, and I am equally sure it is very lucrative for those consultants. But even if they are extraordinarily skilled at seeing improvement opportunities and pointing them out, these consultants are not sensei in the meaning of this diagram. That distinction is made clear in the next section.

This is where the learning happens.

Sensei Learning

I have highlighted the learning loop in red.

The sensei is primarily interested in developing people so that they can see the opportunities and improve the processes themselves. He wants to move them along the continuum from “Do” to “Think” so that they understand, not only this process, but learn how to think about processes in general. When the sensei asks the questions, he is forcing people to articulate their understanding to him. He is really saying “teach me.” In this way he pushes people to deepen their own understanding from “think it through” to “understand it well enough to explain to someone else.”

Think about Taiichi Ohno’s famous “chalk circle.” The “DO THIS” was “stand here and watch the process.” He had seen some problem, and wanted the (hapless) manager to learn to see it as well. Ohno didn’t point it out, he just directed their eyes. His “test” was “What do you see?,” essentially repeated until the student “got it.”

The second leap here is from “Think” to “Self Learning.” At this point, people have learned to ask the questions of themselves, and of each other. So when he asks his questions, the sensei is not merely interested in the answers as a CHECK of learning, he is also teaching people the questions.

These questions are also a form of “reflection.” They are a CHECK of what was planned vs. what was done; and what was intended vs. what was accomplished. The ACT in this case is to think through the process of improvement itself, not simply what was improved.

Until people learn to do this, “Self Learning” does not occur, and the team is forever dependent on external resources (the sensei, consultants) to push themselves.

But the sensei is not through. Once people have a sense of self-learning, the next level is capability to teach others. “All leaders as teachers.”

Learning to Teaching

Someone, I don’t know who, once said that teaching is the best learning. I can certainly say that my own experiences back this up. My greatest ah-ha moments have come when I was trying to explain a concept, not when it was being explained to me.

I would contend, therefore, that a true sensei is not so much one who has mastered the subject, but rather one who has mastered the role of the eternal student. It is mastery in learning that sets apart the very best in a field.

Thus the sensei‘s work is not done until he has imparted this skill to the organization.

As the leaders challenge their people to thoroughly understand the process, the problems, to explore the solutions, so do the leaders challenge themselves to understand as well.

They test their people’s knowledge by asking questions. They test the process knowledge of their people by expecting their people to teach them, the leaders, about the process. Thus, by making people teach, they drive their people to learn in ways they never would have otherwise. The leader teaches by being the student. The student learns by teaching. And the depth of skill and knowledge in the entire organization grows quickly, and without bound.

So Here Is Your Question:

If your organization is typical of most who are treating “lean” as something to “implement” you have the following:

You have a cadre of technical specialists. Their job, primarily, is to seek out opportunities for kaizen, assemble the team of people, teach them the mechanics, then guide them through making process improvements that hit the targets. This is often done over the course of 5 days, but there are variations on this. The key point is that the staff specialists are delegated the job of evangalizing “lean” and teaching it to the people on the shop floor.

Again, if it is typical, there is some kind of reporting structure up to management. How many kaizens have you run? What results have you delivered? How many people have been trained? Managers show their commitment and support by participating in these events periodically, by attending the report-outs, and by paying attention to these reports and follow-up of action items.

Now take what you have just read, and ask yourselves – “Are we getting beyond the first loop, or are we forever just implementing what is in the books?”

How are you reinforcing the learning?

Who is responsible to learn by teaching?

I’ll share a secret with you about a recent post. When Paul and I took Earl through his own warehouse that Friday night, neither of us had been in there before. While I can’t speak for Paul, everything I knew about warehouse operations and crossdocks, I learned from Earl. I didn’t teach him anything that night. Paul and I did, however, push him to teach us, and in doing so, he learned a great deal.

May 10, 2009January 9, 2019

Genchi Genbutsu in a Warehouse

Now and then something comes across that makes it all worth it. And nothing is more “worth it” to me than to know something I said or did contributed to someone’s insight or impetus to do something spectacular.

Yesterday Earl sent me an email that is one of those times. I was going to edit it from an email to me into a story about Earl’s experience. But instead, I decided to just publish it (with his permission) pretty much as I got it. But to be clear, this is about Earl, and his learning, not about me or my teaching.

Mark,

I received this email [see below] the other day from John.

John was one of the lean leaders working for me in Rochester when I was the Lean Director for Kodak’s Global Logistics team and you were the Lean Director for Equipment Mfg. He is now a professor at RIT teaching lean.

One of the things he does with every class is bring them through his old operation in Kodak. The operation is an outbound crossdock for all of Kodak Park where, through applying our lean principles, primarily “flowing at takt”, we have taken a 2,000,000 square foot (186,000 m²) warehouse and replaced it with an 85,000 square foot (<8000 m²) crossdock.

Along the way we reduced the costs by 70%, improved the reliability to +/- a few hours, and amassed an enviable safety record….and as you can see in his note, we’re making it better every day.

When I think back to how we got here, I have to go back to what started as an innocent Friday night, when you, Paul Cary, and I were sitting around his office and you and Paul were pushing on me that we weren’t really thinking about lean in the right way in Logistics, and I was pushing back that “you didn’t understand”….that we just move pallets around the warehouse.

I can remember like it happened yesterday, but it was actually a few years ago, you and Paul looked at each other, looked at me, jumped up and said “Let’s go see”, so we did.

Several hours later, we emerged from the warehouse, not tired and worn out, but energized and excited. You had helped me to see what was invisible to me (and everyone else around)….even though I was the local “lean expert”.

The approach was classic “Mark”, and I have to admit I’ve stolen it and used it as my own many times, although not nearly as effortlessly. At your insistence, we entered through the outbound dock door, as you pointed out, “closest to the customer”. As I started to walk through and into the warehouse proper, you stopped at the door, and made me stop and describe what I was seeing.

The “Five Why’s” were relentless, and I think it was something like 30-40 minutes before we even moved off that spot, but the seeds were planted right then and there. I had now started to see the whole warehouse as “waste” and totally unnecessary if we could only get product flowing at takt. I can’t tell you how many times I’ve relied on the lessons learned that night to guide me when I get in the middle of something unfamiliar to me.

Well, it took us a couple of years, but your invaluable and patient counsel over the next few years shaped a whole organization’s culture. I know better (now) than to suggest “we’ve arrived”, but the principle of using “flow at takt” and making waste visible to drive continuous improvement is firmly rooted in our DNA now.

Aside from the impressive performance statistics of the operation I know you’ll appreciate more that the things you taught me have been dutifully passed along from me to the manager of the area, and through him, to his successor, and now through the college to many more. All we have to do now is close the loop and get you to hire one of the RIT students somewhere!

I’ll not pretend that a couple of hours on a Friday night several years ago was all it took, and I’m forever indebted to the many hours you spent with me afterwards helping me to grow, but it was truly a life changing event, and I thought you’d appreciate seeing a snippet of what it’s led to. Thanks again for all your insight and support in our, and my, journey.

If you ever find your way back East, you have to stop in to see it, drinks are on me. It is pretty wild, but if you do, I might tiptoe carefully around the idea that you’re the guy that taught me to “physically constrain the process to force it to flow at takt”. It was an essential part of our journey, but obviously anyone that would suggest we can change a 2,000,000 square foot warehouse into an 85,000 square foot crossdock can’t be seeing the world the right way! (Of course I have to follow that up with one of my favorite quotes one of the VP’s here used….”If it wasn’t for the fact we already did it, we would have said it’s impossible”. Thanks again.
This is the email he is talking about:

Dave and Tony, thanks again for giving the walk through to my 25 advanced lean class students yesterday. Some observations:

I think the floor was about the cleanest I have ever seen it. It is always clean, but yesterday seemed even more so.

The evidence of continuous improvement is amazing. Yesterday I saw a number of things that I did not see in my last visit Feb 10 – new lane structures, hybrid cards, changes in box 2, clearer e-box sheets, new standard work sheets and visuals, etc.

I really appreciate you taking to heart the input I gave you based on the feedback from my last class on the tour structure/agenda itself. The last tour was very good, this one was awesome. The standard work sheet Dave showed me for the tour was great standard work – content, sequence, timing and outcomes were all vividly clear. I asked for more of a focus on the production control system and you delivered on that request. Dave, in your intro, you sounded like me teaching my class (maybe not a good thing?!?).

[…]I was pleased the students had more time to ask more questions. I keep preaching continuous improvement in class and you guys model it which helps give the message credibility in the minds of the students.

The other thing that struck me, which is not new but seemed different for some reason I can’t explain….. You are moving large volumes of freight, […] and the floor is just so calm. There is no panic, no arguing, no anxiety, just people following the processes, getting product from point A to point B, in a quiet, controlled, efficient way. I still remember when I brought the facilities class over last spring, and especially 2 of the folks with lots of work experience said “I never imagined that a warehouse type of environment could actually look like this.”

Your safety performance is stunning. I know the record when I was there was 534 days. Then we had 2 “old-age” repetitive motion injuries in 2 weeks, then you went 600 + days. Now you are at 200+ days. Absolutely remarkable in a tight space with fork lift trucks moving around. 3 OSHA reportables in 4 years, wow.

I clearly remember “that Friday night.” I think we were in there until 10:00 or later. Paul and I had a really good synergistic style, we reinforced each other, and it was an intense experience for whoever was on the receiving end. This was not the last time we took someone through this exercise.

To be sure, it was Earl and his team that did all of the heavy lifting. All Paul and I did was give him a sense of an ideal flow, and challenged them to discover, and overcome, the obstacles between the current state and that vision – one problem at a time, a couple every day.

February 5, 2009January 9, 2019

TPS Failure Modes – Part 1

Following on from the buzz created by the last couple of posts, I would like to go back in time a bit.

In 2005 Steven Spear wrote a working paper called “Why General Motors Lost and Toyota Won.” A reader can clearly the see emerging themes that were developed into his book Chasing the Rabbit .

Spear talks about the leverage of “operationally outstanding” in changing the game, the capabilities he sees in “operationally outstanding” organizations, then “Failure Modes at Becoming Toyota Like.”

I would like to dwell a bit on these failure modes, and reflect a little on what they look like.

Failure Mode 1: Copy Lean Tools Without Making Work Self Diagnostic

So what does “self diagnostic” mean?

For something to be “self diagnostic” you need two pieces of information:

What is supposed to happen.
What actually happens.

Then you need some mechanism that compares the two and flags any difference between them. This sounds complicated, but in reality, it isn’t.

Let’s look at a common example: At the most basic level, this is the purpose of 5S.

5S as a Self Diagnostic Tool

In 5S, you first examine the process and seek to understand it. Then, applying your best understanding, you decide what is necessary to perform the process, and remove everything else. Applying your best understanding again, you seek to locate the items where they would be used if the process goes the way you expect it to.

You improve the self-diagnostic effect by marking where things go, so it immediately clear if something is missing, out of place, or excess.

Then you watch. As the process is carried out, your “best understanding” is going to be tested.

Can it be done with the things you believed are necessary? If something else is required, then you have an opportunity to improve your understanding. Get that item determine where it is used, and carry out the operation. But go a little deeper. Ask why you didn’t realize this was needed when you examined the process. Challenge your process of getting that initial understanding and you improve your own observation skills.

Is everything you believed is necessary actually used? If not, then you have another opportunity to improve your understanding. Is that item only used sometimes? When? Why? Is it for rework or exceptions? (see failure mode #2!) Why did you believe it was necessary when you did your initial observation?

Does something end up out of place? Is it routinely used in a place other than where you put it? This is valuable information if you now seek to understand how the process is different from what you expected.

Now think about the failure mode: What does fake-5S look like? What is 5S without this thinking applied?

How do you “do” 5S?

Look long and hard if you are trying to audit your way into compliance rather than using it as a diagnostic for your understanding of your process.

Though the jargon “self diagnostic” sounds academic, we have all talked about visual controls “distinguishing the normal from the abnormal” or other similar terms. It is nothing new. What makes this a failure mode is that people normally don’t think it is that important when Spear cites a mountain of evidence (and I agree) that this is critical to success. You can only solve the problems you can see.

Another Example: Takt Time

What is takt time? Before you whip out your calculators and show me the math, step back and ask the core question of “What it is” rather than “how to calculate it.” What is it?

Takt time is part of a specification for a process – it defines what should be happening. By setting takt time you are saying “IF our process can routinely cycle at this interval, then we can meet our customer’s demand. Takt time defines both part of a “defect free” outcome of your work cycle as well as a specification for process design.

Then you apply your very best knowledge of the process steps and sequence and set out a work cycle which you believe can be accomplished within the takt. It becomes self-diagnostic when you check, every time if the actual work cycle was the same as the intended work cycle. An easy way to check is to compare the actual time with the designed time.

In Decoding the DNA of the Toyota Production System, Spear cites an example of seat installation.

At Toyota’s plants, […] it is instantly clear when they deviate from the specifications. Consider how workers at Toyota’s Georgetown, Kentucky, plant install the right-front seat into a Camry. The work is designed as a sequence of seven tasks, all of which are expected to be completed in 55 seconds as the car moves at a fixed speed through a worker’s zone. If the production worker finds himself doing task 6 (installing the rear seat-bolts) before task 4 (installing the front seat-bolts), then the job is actually being done differently than it was designed to be done, indicating that something must be wrong. Similarly, if after 40 seconds the worker is still on task 4, which should have been completed after 31 seconds, then something, too, is amiss. To make problem detection even simpler, the length of the floor for each work area is marked in tenths. So if the worker is passing the sixth of the ten floor marks (that is, if he is 33 seconds into the cycle) and is still on task 4, then he and his team leader know that he has fallen behind.

On this assembly line, time is used, not so much to pace the work, but as a diagnostic tool to call out instances when the work departs from what is intended – or in simpler terms, when there is a problem.

All of this has been about checking that the process is being carried out as expected. But, bluntly, the customer really doesn’t give a hoot about the process. The customer is interested in the output. How do you know that the output of your process is actually helping your customer?

To know that you first have to be really clear on a couple of things:

Who your customer actually is.
What value do you provide to that customer?

Put another way, can you establish a clear, unambiguous specification of what a defect free outcome is for each supplier-customer interface in your process? Can you follow that trap line of supplier-customer interfaces down to the process of delivering value to your paying customers?

To make this self-diagnostic, though, you have to not only specify (what should be happening), you have to check (what is actually happening), and you have to do it every time.

So poka-yoke (mistake proofing) is a way to verify process steps. Other mistake proofing will detect problems with the outputs. All are (or should be) designed to diagnose any problems and immediately halt the process or, at the very least, alert someone.

The theme that is emerging here is the concept of PLAN-DO and CHECK, with the CHECK being thoroughly integrated into the process itself, rather than a separate function. (Not that it can’t be, but it is better if CHECK is continuous.)

The Supply Chain

I was walking through the shop one afternoon and spotted an open bundle of steel tube – about half of them remaining. They used kanban to trigger re-order. The rule of kanban is that the kanban card is pulled and placed in the post when the first part is consumed. To make this clear, they literally attached the kanban to the bands with a cable tie. Thus, breaking the band would literally release the kanban. Simple, effective.

But, though this bundle had been opened, there was the kanban card still attached to the (now broken) banding. It was lurking at the base of the pallet, but visible.

I went and got the supervisor, and told him that “You are going to have a shortage of 4×5 tube on Wednesday, and it is your fault. Would you like to know why?” I guess I should point out that I had a pretty good relationship with this guy, so he knew I was playing him a little. Then I just said “Look, and tell me what you see.”

It took a few seconds, but he saw the kanban, said “Argh” and started to pick it up to put into the post. I stopped him and asked if it was his responsibility to do that. No, it was the welder’s responsibility. “Then you should take a minute with him, and do what I just did with you.”

Then I asked him how often the kanban cards were collected. (I knew, I wanted to check that he knew.) “Daily, about 1 pm.”

“How often do you walk by here every day?” He said at least twice, in the morning and right after lunch. “So all you need to do is take a quick glance as you walk by, twice a day, and you will always get that kanban into the post before 1pm.”

He did, and their periodic shortages dropped pretty much to zero.

Why?

First, the system was set up JIT. We knew the expected rate of use of that part. We knew the supplier’s lead time and delivery frequency. We knew the bundle size. MATH told us the minimum number of kanban cards that would need to circulate in this loop to ensure the weld cell never ran out… unless one of the inputs was wrong or unless the process operated differently than we expected.

We also knew that, given the rate of consumption, how many bundles should be in the shop at any given time, and we had space market out for just that amount. Thus, we could tell immediately if something was received early, or if our rate of consumption fluctuated downward. (Because a pallet would arrive, but there would be no place to put it.)

We could have just had a Team Member come by once a day and check if a bundle had been opened, and send an order to replenish it. We could have been even more sophisticated and just set up a barcode scan that would trigger a computer order.

But if we had set up the process that way, how could the Supervisor distinguish between “Ordered” or “Not Ordered?” It was that stray out-of-place kanban card that told him.

Bin with kanban card Thus, physical kanban cards, physically attached to the materials, represent a self-diagnostic check. If the card is there, then that container should be full. Quick to check. If the container is not full, there should be no card. Quick to check. If a container arrives with no card, it was not properly ordered and is likely excess (or at least calls for investigation). Quick to check. The physical card, the seeming crude manual operation, provides cross-checks…self-diagnosis… simply and cheaply in ways that few automated systems replicate.

So far these have all been manufacturing examples. But Spear is clear that all work is self-diagnostic, not just manufacturing.

What non-manufacturing work fits into this model?

(Hint: All of it.)

What about a project plan? Though in reality, most project plans don’t. Read Critical Chain by Goldratt to understand the difference – and produce and manage project plans that are much more likely to finish on time.

What about a sales plan? Do you predict your monthly sales? Do you check to see if week 1 actual sales deviated from what was expected? Do you plan on activities that you believe will hit your sales targets? Which customers are you calling on? What do you predict they will do? (Which tests how well you really know them.) Do you actually call on those customers? Do they need what you thought they would? Or do you learn something else about them? (Or do you make a best guess “forecast” and wait for the phone to ring?)

Once you have a sales plan, do you put together a manufacturing and operations plan which you believe will match production to sales? How much variation do you expect to accumulate between production and sales over the course of that plan? Do you put alarm thresholds on your finished goods or your backlog levels that would tell you when that predicted variation has been exceeded?

How do you (and how often do you) compare actual sales (volume, models, and revenue) against the plan? Do you know right away if you are off plan? How long will you tolerate being off plan before you decide that something unexpected is happening? Is there a hard trigger point already set out for that? Or do you let the pain accumulate for a while?

A lot of companies were caught totally by surprise a few months ago when their sales seemed to fall off a cliff. Question: Did you have rising inventory levels before that? Was there a threshold that forced attention to something unexpected? Or did you increasingly tolerate and normalize deviance from your intended business plan?

At the next levels up – you have a business plan of some kind. You have financial targets. Do you have specific actions you plan to take at specific times? Do you check if those actions were actually taken? Do those actions have some kind of predicted outcome associated with them? Do you check if the actual outcome matches what you predicted? If you just “try something to see what happens” you might learn, but you might not. If you predict, then try to see IF it happens, you are more likely to gain more understanding from that experience.

When you design a product, do you have performance specifications? Do you test your design(s) against those performance specifications? Do you do that at every stage, or just at the end?

When you say “We need training” have you first specified what the work process is? Have you studied the situation and determined that people do not have the skills or knowledge to do the job? Have you specified what those skills are?

Have you developed the training to specifically develop those skills? Do you have a way to verify that people got the skills required? Do you check if, now, they can perform the work that they could not perform before? If you didn’t do the last, why did you “train” them at all? How do you know it was not just entertainment?

“Management Is Prediction”

This quote, attributed to W. Edwards Deming, really sums up what this is about. By specifying an outcome – “defect free” (which implies you know that is), within a certain time; and by specifying the process steps; you are predicting the outcome.

“If we do these things, in this sequence, it should require this amount of time, and produce this result.”

Then do it, and check:

Does what you really had to do reflect the tasks you thought would be required?

Does the order you really did them in reflect what was in the plan?

Does the time required reflect the time you planned on?

Did it produce the intended result?

Building those checks into the process itself makes it self-diagnostic.

Try This

Go study a process, any process. Just watch. Constantly ask yourself:

How does this person know what to do?

How does this person know if s/he is doing it right?

What alerts this person if s/he makes a mistake?

How does this person know s/he succeeded?

If there are clear, unambiguous answers right in front of you – without research, without requiring vigilance or luck on the part of the Team Member, then you probably have something approaching self-diagnostic work. Likely, you don’t. If that is the case, don’t say you are “doing lean.” You are only going through the motions.

January 28, 2009January 9, 2019

Walking the Gemba

Duke left a great question as a comment to “A Morning Market.” He asked:

What’s the key differences between the [morning] market meeting and a gemba walk? Maybe I should ask what is the purpose of a gemba walk?

Good question.

I’ll start with one of my (other) favorite quotes from an old friend, Dave:

“It isn’t about shaking hands and kissing babies.”

That is to say, a lot of leaders think that heading out to the work area to “show the flag,” and do a meet-and-greet with the team members is “walking the gemba.” While they may be at the gemba, and they may actually be walking around, this isn’t it.

Walking the gemba is part of “Check” in Plan-Do-Check-Act. It is the process of carefully observing to see where things are not as they should be. Sometimes there is less walking involved, and more just standing and watching.

This, of course, begs the question: Watching for what? This, ultimately, is what makes it different than even just walking around looking.

Try this exercise. Go to some place where any activity is taking place. It really doesn’t matter what. If you aren’t in a factory, just go watch someone doing data entry or computer work. Watch the receptionist process walk-in customers and phone calls.

Note: Whatever you choose, please talk to people and tell them what you are doing, otherwise this is going to seem creepy to them if they aren’t used to it.

Get a feel for what is happening. More importantly, try to envision what is supposed to be happening. If this process were going perfectly, how would it look? Try hard to visualize in your mind a smooth, totally value-adding work flow.

Now, as you watch, become totally conscious of what is really happening. Why is this process other than how you visualized it? What disrupts the work? Where could mistakes be made? What keeps those mistakes from being made? Is it just vigilance? Or is there some mechanism to either prevent the mistake or either cue the person on the correct way, or alert them on the incorrect?

Is there any backtracking, rework, looping around? Are things where they are actually needed? Do people have to look around for things?

How do they know what they should be doing? What is their source of information? Do they have to hunt it down, or worse, guess at what should be done? Or is the “right thing” and the “right way” chrystal clear to even the casual observer (that would be you).

Is there a pace to the work? Even if it isn’t traditional takt-time work (especially if it isn’t), there is some kind of deadline. How does the person know whether things are on time or not? When do they learn they are behind?

If the person encounters some kind of problem, something unexpected, something needed but not there, what happens? Is there a support system to get this person back on-process? Or is he or she left to their own devices to just figure it out?

As you watch, keep your standard very high. If something is not obviously as it should be, then question whether it is. “Control” has the burden of proof here, not chaos.

When you see these things, focus in on one of them. Ask yourself “Why?” does this condition exist? Where does the problem originate? Go there. Study some more. How is it that this process fails to support its customer? Do they have a clear understanding of what is expected? (Probably not, most don’t, especially administrative processes.) How do they know they delivered (or didn’t) what their customer required? Did they think their output was defect free (according to their standards), but was really causing problems for their customer?

Often it helps to look at one person doing a single task, find a single issue, and follow the trap line upstream until you arrive at the origin of the problem. Often, again, you will have a fixable root cause right in front of you.

Now the fun begins. As a leader, it is not your job to fix the problem. That is not what you are looking for.

When you walk the gemba, you are assessing how well your organization is tuned to seeing these issues, clearing them, finding their causes, and solving them. If you see these opportunities, then your job now is to teach.

Grab whoever it is whose responsibility bounds both the effect and the origin of the problem. Guide him through the same things. If this issue was unaddressed, there are a couple of problems this leader must address.

First, there is someone downstream likely coping with an issue that he should be raising. (Or worse, there is no process for raising the issue, or worse still, no process to respond if he does.) If that isn’t happening, help this leader understand that this is the shortfall here, not the actual issue. It is now his turn to teach, in turn, either the Team Member, or whatever leader is between him and the Team Member.

Second, upstream, there is a process which either does not understand what “defect free” is, or does not have (or does not use) a positive way to verify it before sending it along. Same issue. This is a leader training process until the education reaches the level that should be doing the checks and the verifications.

The best way to learn how to do this is to walk your flow with someone who has the skill. It is simply a skill, and it can be taught. But learning also requires some humility, and the student must bring that to the “classroom.”

So, to recap in two short statements.

The gemba walk is a “Check” of Plan-Do-Check-Act.
You are checking the health of your leadership systems by looking at how they engage their people and processes.

Walking the gemba is a process of developing your people.

May 12, 2008January 9, 2019

Theological Debates

A frequent topic in the lean.org forums is some version of “what is the difference between lean and ____” where the blank is one of the industry buzzwords. Some of the common ones are various prefixes to “Sigma.” Others are old standards such as TQM, SPC, TOC, etc. These discussions are always interesting as the various camps line up. “Lean looks at waste, while xxx-Sigma looks at variation” is a common one. Apparently “Agile” is about high-tech machinery, and of course, none of that is found in “lean.”

My put on all of this is pretty simple. It’s all the same, people.

There is nothing about TPS that excludes any level of machining technology, so long as that technology is applied as a solution to a problem rather than for its own sake. The last time I checked, Toyota, and TPS, were obsessive about stamping out variation. Constraints? Yup. You bet I know what the constraint is, and you bet I manage it tightly. If I have done everything right, my enterprise constraint is production (rather than sales), but just barely. And internally, if I have done it right, my constraint is manual work rather than technology. Why? Because every Team Member can work on improving manual work cycles. Not the case with an engineering constraint.

In the end, this is all about the rational, deliberate application of skilled problem solving, using the scientific method, aka PDCA.

If you are looking at “which one to implement” stop fretting about it. Go out to your work area, stand and watch a while, see what is stopping your good people from doing a great job, and start fixing it.