Tag: Chalk Circle

Posted on

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the lean.org forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

Posted on

“TWiT Live” Walkthrough of Ford’s Rouge Plant

Tom sent this link to me, and I thought I would share it.

I can’t say much for the correspondent, but this is a decent view of a modern automobile assembly line.

The actual tour starts at around the 6:00 point.

When I look at a production line, one of the key things I am looking for is how they detect and respond to problems – both the mechanics and the strength of the problem solving culture.

I am curious to hear from any of my readers from Ford (I know you are out there).

Posted on

5S Audits – Part III

I would like to thank everybody for a really engaging dialog in the previous two posts about 5S audits.

Now I would like to dig in and look at what an “audit” is actually finding, and how we are responding to those issues.

Our hypothetical production area is getting an audit. The checklist says things like “There are no unnecessary items in the work area” and “There is a location indicated for all items.”

If there are unnecessary things in the work area, or things are not in their designated locations, what happens?

Of course, the checklist is filled out and a score is assigned.

But what has been learned about the process?

In one of the comments, I asked something like “When was the problem first noticed?”

The core purpose of 5S is to establish a testable condition that asks the question: “Does the team member have everything he needs, and nothing he doesn’t, where he needs it, when he needs it, to carry out his process as we understand it?”

One of the primary purposes of marking out the locations is to indicate the standard so that someone can notice right away that the standard has been broken. What should happen right then and there?

Since we define a “problem” as “any departure from the standard or specification,” and we have taken the first step of removing ambiguity from the situation (by deciding what should be here, and marking it out), we want an immediate response to the problem.

Ideally this means that the team member would indicate trouble (andon call, or other means) as soon as he discovered that his air gun was missing, or didn’t work.

The back-up to this is the team leader’s standard work. His eyes should be scanning for situations where there is a problem that the team member hasn’t called out. This is why the standards are marked out, posted, etc. To make this job easy for him. His immediate response would be to (1) Seek to understand the situation – what pulled the team member off his standard work, where did the problem originate, (2) Correct the situation. Sometimes that’s it. Other times, there is another problem to dig into.

It could be that something about the work process or conditions has changed and the team member is improvising a bit. That would bring extra stuff into the area, for example. I recall a great example where we pulled all of the thread cutting tools out of assembly so we could better detect when assembly was getting defective fabricated parts. It worked by forcing the process to stop and an andon call since assembly could not proceed if the threads were not cut.

At the same time, if a thread cutter found its way back into the assembly area, we would know we had two problems. First, we had defective parts. But more important, the process of telling us about that problem had been bypassed.

The back-up to the team leader’s standard work is the supervisor’s standard work. She is looking two levels down, but her response is going to be different. Unless safety or quality is jeopardized, the supervisor is going to find the team leader and (1) Seek to understand what pulled the team leader off of his standard work, and (2) correct the situation.

If the next level up is spending any time at all out on the shop floor, it is the same thing – maybe once a day – seeking out verifiable evidence that things are working as they should be. In the lack of positive evidence of control, we must assume there are hidden problems.

Now, if the audit finds something like this (click on the image for a bigger one):

Then it isn’t about the tape being out of place, nor is it a question about where the screwdriver is. What we have discovered is that none of the checks have been made, or if they have, no one has done anything about them.

Someone said “If we don’t do audits then 5S deteriorates.” OK – but why does 5S deteriorate?

Simply put, it is going to deteriorate, just as your process does, a little bit every day. Disorder is always being injected into everything. Your process will never, ever be stable on its own. No matter how good you are, the next level of granularity will show up as deterioration.

This is the “chatter” that Steven Spear talks about.

The question comes down to your core intention for the audit.

If you are assessing how well the area manager is coaching and teaching his people to see and respond to problems so that you can establish a target condition for his learning, and then develop his capabilities accordingly… there are better ways (in my opinion) to do that.

If you are assigning a numeric score in the hope that, by measuring something you can influence behavior, it might work, but people can come up with ingeniously destructive ways to achieve the numeric goals. As a thought experiment – how might an area manager get a high score on his 5S audit in ways that run completely counter to the goals of 5S, people development or “lean?”

The bottom line is that “Audit 5S” is not something that you should accept as a given. Rather, it is a proposed countermeasure to some problem. But if you start with a clear problem statement like “Team members are bringing thread taps into the assembly line,” and start asking “Why” five times, get to a root cause to that problem, you are unlikely to arrive at a monthly or periodic 5S audit as a countermeasure – nor are you ever going to need one.

The problem?

I think we feel the need to do audits because we have no process to immediately detect, correct and solve the little problems that happen every day. These little issues are the ones that cause the 5S erosion. Because we don’t have a process to deal with them one-by-one, we have to have an elaborate process that disrupts our normal work flow and takes them on in big batches.

Does that sound like a “lean” process to you?

How might we relentlessly drive the “audit” process closer to the ideal of one-by-one confirmation?

That would be “lean thinking.”

 

 

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.

Posted on

The Lean Manager: Part 3 – People, Purpose, Problems, Process vs. “Systems”

Click image for Amazon.com listing

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

Before I get into it, I will break the rules of blogging and acknowledge a time gap here. I did finish the book shortly after I wrote part 2, in fact, I didn’t want to put it down. So now I am going back through and bringing out some key points, intermixed with some other stuff that has caught my interest lately. Anyway – back to what you came for…

Steve Spear has described the TPS as a “socio-technical system.” Put in less formidable terms, it is a system that uses the structure of the work, the work environment and the support systems (the technical part) to create an organizational culture of problem solving.

Jenkinson, Andy’s boss in the book, describes it:

“You need to organize a clear flow of problem solving, explained Jenkinson one more time. “Operators need to have a complete understanding of normal conditions, so that whenever there is a gap, they know it’s a problem. Go and see is not just for the top management, It’s for everybody. This means operators as well, in particular how they learn to see parts and see the equipment they use. How can all operators recognize they have a problem? [emphasis added]

The simple statement, and following question posed by Jenkinson sums up a great deal that is left out of lean implementations. I see it everywhere, and will be commenting on it more shortly.

We talk about “go and see” (or “genchi genbutsu“) as something leaders do. I think this is because traditional leaders aren’t naturally out in the work areas, on the shop floor, in the hangars, etc. We don’t think about the workers because they are there all of the time.

Yes, they are. But what do they see? Do they see disruptions and issues as things they are expected to somehow work around and deal with? Or do they see these things as something to call out, and fully participate in solving?

And if they do see a problem, what is the process for engaging it?

Just saying “you are empowered to fix the problem” does not make it so. When are they supposed to do it? Do they have the skills they need? How do you know? Is there a time-based process to escalate to another level if they get stuck? (Or do they just have to give up?)

And indeed, as the story in the book develops, Andy turns out to be taking a brute-force approach. He is directing staff to implement the tools and to solve problems. But in spite of nearly continuous admonitions from his boss and other experts, he is not checking how they are doing it. He has put a “get-r-done” operations manager into place, and while the guy is getting “results,” in the long haul it doesn’t work very well. Yes, they end making some improvements, but at the expense of alienating the work force.

It is only late in the story (and I won’t get into the details to avoid playing the spoiler to a pretty good plot twist) that Andy finally learns the importance of having a process that is deliberately designed to engage people.

Commentary – it is amazing to me just how much we (in the “lean community”) talk about engaging people, but never really work through the deliberate processes to do it. There are explicit processes for everything involving production, administration, etc. but somehow we expect “engaging people” to happen spontaneously just because we believe it is a good thing.

The message in this book is loud and clear. This is about leadership. The tools are important, yes, but only (in my opinion) because they are proven techniques that allow people to become engaged with the process.

But the tools alone do not require people to get engaged.

Permission to make input is necessary, but not sufficient. If you want people to be engaged, you have to deliberately engage them. Otherwise you are just asking them to become nameless cogs in “the system.”

Posted on

The Lean Manager: Part 2 – The Basics

Click image for Amazon.com listing

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.

Posted on

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.

Posted on

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 m2) warehouse and replaced it with an 85,000 square foot (<8000 m2) 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.

Posted on

Learning To Sensei: LEAN.org

John Shook’s latest column on LEI’s site is about coaching and whether it is better to give them the answers or just ask questions.

Asking questions in a way that actually teaches is a skill that we, as a “lean” community do not foster very well. Certainly in U.S. corporate culture, we are expected to be the experts, and to have the answers. John’s post is summed up well by his last paragraph:

Learning to Sensei: A prerequisite for the apprentice sensei who is learning to not give solutions is to grasp for himself the fact that he doesn’t actually know the solution. Once you grasped that, then it’s very easy to not give “the answer” you simply don’t really have an answer to give. But, while it is not necessary for you to give or even possess “the solution”, you do have an important obligation, which is to give the question or learning assignment in a way that will lead to the learning, with learning as the goal. Once that is accomplished, all sorts of “solutions” will fall out. Then you can experience the joy, liberation, and humility that come with admitting you don’t know.

You can read the whole thing here:

LEAN.org – Lean Enterprise Institute: Coaching and Questions; Questions and Coaching

Now, as an additional value-add…

This really falls under the general notion of “Socratic teaching.” One of the best overviews of what this is really about is Rick Garlikov’s classic piece where he recounts his experiment with teaching through questions. If you don’t think this can work for difficult topics, then I suggest you read his account of using only questions to teach binary arithmetic to a typical class of third graders. If he can teach 8 year olds to understand that 0110 + 0011 = 1001, then surely we can get adults through understanding why takt time is important for management.

“What are you trying to do?”

“How will you know you have done it?”

Posted on

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.

assembly-valencien-640

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 cardThus, 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”

deming

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.