Tag: Kaizen

Posted on

Toyota Kata Seminar, Day3

The key points addressed today (Day 3) at the Toyota Kata seminar were:

  • The PDCA cycle – small experiments that the “learner” develops to advance toward the target condition.
  • The coaching cycle (or kata) – an introduction to the role of the coach, and how coaching is structured in practice.
  • A fairly brief discussion on the current experience with the implementation path for an organization.

Roles

Even though the book and course material are quite explicit, a couple of people in the room weren’t readily grasping this until today.

Who Is Being Coached?

In the Kata model, the first level of “learner” is the first line leader who has direct responsibility for the process, and the people who work in it.

On a production floor, this would be the area supervisor.

The core material of the course is how to plan and execute continuous improvement in your work group. This is called the “Improvement Kata”

The “Coaching Kata” is covered and demonstrated (quite well), but it is not the prime topic this week.

Who is doing the coaching?

The coach is nominally the direct supervisor of the person being coached.

To learn how to coach, one must first learn the game. Thus, no matter your role in the organization chart, you come to this seminar gain awareness of the role of your first line leaders.

Then you go home and practice the role some more. Once you have lived in their shoes, then you can turn around and expect them to do the same.

What is absolutely critical to understand here is that this is not a “kaizen event” model. This is a daily improvement model. The coaching cycle happens for a few minutes every day between front line supervisor and the immediate manager. It is a process for developing better supervisors. It cannot (or at least should not) be delegated.

Here is the crucial difference: In many kaizen events, the specialist staff workshop leader is the one directing the actions of the team. The area supervisor may be a member of the team, but she is often not the one actually guiding the effort. In this model, there is no “learner” because there is no deliberate process to improve the problem solving and leadership skills of the supervisor.

If the course has a weak point it is that we “learners” are organized in a way that LOOKS more like a traditional kaizen team, which shifts the instructor / coach more into a role that LOOKS like that of the traditional kaizen workshop leader. Thus, it is easy for a participant to slip into a well-engrained mindset about kaizen events. We have all “practiced” the kaizen event pattern many times. The “kata” pattern is new.

This is the nature of the instructor coaching a group of “learners” rather than the 1:1 that is designed to happen in reality.

So, advice if you decide to attend: Be explicitly conscious that the structural limitations of the course, and deliberately work to overcome them in your mindset. This will help you grasp the material that you are there to learn.

That being said, I have a very explicit picture now of how I want shop floor supervisors to behave and lead. I have a pretty good idea of how to help them get there.

I’ve got an early flight, more later.

Posted on

From The Toyota Kata Seminar

I am taking the Toyota Kata seminar this week in Ann Arbor. There are two programs offered:

  • A one-day classroom overview of the concepts in Toyota Kata.
  • The one-day classroom overview followed by two days of practice on a shop floor, for a total of three days.

I am taking the three day version.

Impressions of Day 1

There are about (quick count) 36 participants, a big bigger group than I expected considering the premise. I don’t know how many are not going to be attending the shop floor part, but most people are.

I suppose the ultimate irony is the slide that makes the point that classroom training doesn’t work very well for this.

Realistically, I can see it as necessary to level-up everyone on the concepts. The audience runs the gamut of people who have read, studied, written about, made training material from, and applied the concepts in the book; to people who seem to have gone to the class with quite a bit less initial information.

That being said, everyone had some kind of exposure to lean principles, though there was a lot of “look for waste” and “apply the tools” mindset present. Since one of the purposes of the class is to challenge that mindset, this is to be expected.

You can get a good feel for the flow and content of the material itself on Mike Rother’s web site. He has a lot of presentations up there (via Slide Share).

Like any course like this, the more you know when you arrive, the more nuance you can pull out of the discussion.

Since I have been trying to apply the concepts already, my personal struggles really helped me to get a couple of “ah-ha” moments from the instruction.I arrived with a clear idea of what I wanted to learn, and what I thought I already knew. Both pre-disposed me to get insight, affirmation, and surprise learning from the material.

I would not suggest this for anyone who was looking to be convinced. Classroom training in any case doesn’t do that very well, and this material isn’t going to win over a skeptic. You have to be disposed to want to learn to do it.

At the end of the day, the overall quality, etc. of the presentation was pretty typical of “corporate training” stuff – not especially riveting, but certainly interesting. But we don’t do this for the entertainment value, and the learner has a responsibility to pull out what they need in any case.

Insights from Day 2

Day 1 is intended, and sold, as a stand-alone. The next two days are available as follow-on, but not separately.

The intended purpose was to practice the “improvement kata” cycle in a live shop floor environment. Today was spent:

  • Developing our “grasp of the current condition.” There is actually a quite well structured process for doing this fairly quickly, while still getting the information absolutely necessary to decide what the next appropriate target is.
  • Developing a target condition. Based on what we learned, where can this process be in terms its key characteristics and how it performs, in a short-term time frame. (A week in this case)

Key Points that are becoming more tangible for me:

The “Threshold of Knowledge” concept.

I elaborated on Bill Costantino’s (spelled it right this time) presentation on this concept a while ago. In the seminar, I am “groking” the concept of threshold of knowledge a bit better. Here is my current interpretation.

There are really three thresholds of knowledge in play, maybe more. First is the overall organization. I would define the organizations’ threshold of knowledge as the things they “just do” without giving it any thought at all.

For example – one company I know well has embedded 3P into their product design process to deeply that the two are indistinguishable from one another. It is just how they do it.

They still push the boundaries of what they accomplish with the process, but the process itself is familiar territory to them.

Likewise, this company has a signature way to lay out an assembly line, and that way is increasingly reflected in their product designs as 3P drives both.

It wasn’t always like that. It started with a handful of people who had experience with the process. They guided teams through applying it, in small steps, on successively more complex applications until they hijacked a design project and essentially redid it, and came out with something much better.

Another level of knowledge threshold is that held by the experienced practitioner.

Today I walked into a work cell in the host company for the first time, and within a few minutes of observation had a very clear picture in my own mind of what the next step was, and how to get there. My personal struggle today was not in understanding this, but in methodically applying the process being taught to get there. I knew what the answer would be, but I wasn’t here to learn that.

An extended threshold of knowledge in one person, or even in a handful of people, is not that useful to the company.

But that is exactly the model most kaizen leaders apply. They use their expert knowledge to see the target themselves, and then direct the team to apply the “lean tools” to get there.

They tell the team to “look for waste” but, in reality, they are pushing the mechanics. You can see this in their targets when they describe the mechanics as the target condition.

The team learns the mechanics of the tools, but the knowledge of why that target was set remains locked up in the head of the staff person who created it.

So his job is to set another target condition: Expanding the threshold of knowledge of the team.

He succeeds when the team develops a viable target themselves. It might be the same one he had, but it might not. If he framed the challenge correctly, and coached them correctly, they will arrive at something he believes is a good solution. If they don’t he needs to look in the mirror.

So the next level of knowledge threshold is that held by the team itself.

If enough teams develop the same depth, then they start to interconnect and work together, and we begin to advance the organization’s threshold. Now what was previously required a major “improvement event” to develop is just the starting baseline, and the ratchet goes up a bit.

None of the above was explicitly covered today, but it is what I learned. I am sure I’ll get an email from a certain .edu domain if I am off base here. Smile

There is no Dogma in Tools

This is the third explicit approach I have been taught to do this.

The first was called a “Scan and Plan” that I learned back in the mid/late 1990’s. It was more of a consultant’s tool for selecting a high-potential area for that first “Look what this can do” improvement event.

Though I don’t use any of those forms and tools explicitly, I do carry some of the concepts along and apply them when appropriate.

Then I was exposed to Shingijutsu’s approach. This is heavily focused on the standard work forms and tools. Within the culture of Shingijutsu clients, it would be heresy not to use these forms.

The “Kata” approach targets pretty much the same information, but collects and organizes it differently. I can see, for myself, a of better focus on the structure of establishing a good target. I can also see a hybrid between this method and what I have used in the past. Each form or analytical tool has a place where it provides insight for the team.

One thing I do like about the “Kata” data collection is the emphasis on (and therefore acknowledgement of) variation in work cycles. (All of this is in the book by the way. Read it, then get in touch with me if you want some explanation.)

Now, I want to be clear – in spite of the title of this section, when I am coaching beginners, I will be dogmatic about the tools they use. In fact, I plan to be a lot more dogmatic than I have been.

I am seeing the benefit of providing structure so that is off the table. They don’t have to think about how to collect and organize the data, just getting it and understanding it.

What I can do, as someone with a bit more experience, is give them a specific tool that will give them the insight they need. That is where I say “no dogma.” That only applies when the principles are well within your threshold of knowledge.

The real ah-ha is that, unlike the Shingijutsu approach, we weren’t collecting cycle times at the detailed work breakdown level. Why not? Because, at this stage of improvement, at this stage of knowledge threshold for the team, the work cell, that level of detail is not yet necessary to see the next step.

I will become necessary, it just isn’t necessary now.

Target Conditions and PDCA Cycles

One place where my work team bogged down a bit this afternoon was mixing up the target condition that we are setting for a week from now, and what we are going to try first thing in the morning.

The target condition ultimately requires setting up a fairly rigid standard-work-in-process (SWIP) (sometimes called “standard in-process stock) level in the work cell.

There was some concern that trying that would break things. And it will. For sure. We have to stabilize the downstream operation first, get it working to one-by-one, and make sure it is capable of doing so.

The last thing we want to do while messing with them is to starve them of material.

So – key learning point – be explicitly clear, more than once, that the Target Condition is not what you are trying right away. It is the predicted, attainable, result of a series of PDCA steps – single factor experiments. You don’t have the answers of how to do it yet. So don’t worry about the SWIP level right now. That will become easier… when it is easier.

More tomorrow…

Posted on

Internalizing Outside Knowledge

Continuing on a theme – a kaizen event should be primarily about learning, using the real-world improvement opportunity as a vehicle.

Outside consultants (some style themselves as “sensei”) can be a good way to bootstrap this process by bringing in existing experience so you can develop your own more quickly. (Full disclosure here – Right now I am one of those consultants, though I have played on both sides of the game and learned a lot from others.)

But it is important to use them the right way.

The way that doesn’t work is to bring in an outside consultant to lead improvement for you. Typically this means that the company assembles a working team, delegates the improvement to that team, and hires a consultant to lead them.

Once the event or activity is over, it might be repeated again with a different group of people, on a different project, even with a different consultant.

Though this can be somewhat effective at dealing with individual issues, the company’s capability to do this themselves is never developed.

Learning might occur within the company, but it will be a random event.

On the other hand, if the client company puts together a team that has an internally designated leader, and that leader is also charged with capturing knowledge, and there is some continuity from one event to the next, then a working relationship develops.

In my opinion, this is a legitimate role of a Kaizen Promotion Office, and is likely why a lot of consultants (at least the ones with the clout to impose conditions on their clients) insist on the company forming one.

The people in the KPO have two roles.

  • To capture and internalize the cutting edge of skill and knowledge for the company.
  • To practice that skill and knowledge by teaching others.

I have personally experienced both situations – where I am asked to be a substitute leader, and where I have the opportunity to develop people in the company. I can tell you that the later is a lot more fun, and the former is mostly frustrating.

I also see a difference in follow-up. Where there is no internal leadership, it is much tougher for the team to stay on the game and push the changes to a point where they are ingrained and sustain.

If you are interested in some expanded thoughts on this topic, I invite you to read the white paper “Getting the Most From Lean Consultants” on the “Resources Page.”

Posted on

Toyota Kata Handbook

Mike Rother has made some significant revisions to his Improvement Kata Handbook.

 

  • The role of “True North” is much better defined as the context of improvement.
  • He has filled in a lot of valuable detail for “Grasping the Current Condition” and setting Target Conditions.
  • The structure for the PDCA cycle has been tightened up.
  • And the time, place and method of coaching is much more explicit.

Even if you took a look earlier, get the latest and study it.

 

Posted on

Learning Kaizen

Learn to be thorough before working on speed. The speed will come naturally with competence.

Every coach in the world gives some form of this advice to her students. This is true for athletics, for music, for any skill we are trying to develop.

Yet when planning kaizen events, we tend to forgo this advice, and push the team to produce huge “results” for the Friday report-out.

Getting those results is actually pretty easy. Any facilitator with a little bit of experience with the tools can push the team to rearrange a layout, get some basic flow, and turn in some really good numbers in a few days.

But what skills has the team developed in this process?

Maybe how to see a similar opportunity and copy the layout there.

Maybe how to close out an action item list, but that is still just rote implementation.

What processes and systems have to be in place to sustain those results? What skills are needed to use those processes and systems effectively. When, during the course of these five days, did your team practice those skills, or for that matter, even learn what they need to learn?

Posted on

The Report-Out

The classic one-week kaizen event ends with a report-out by the team that outlines the improvements they have made, and the results they have achieved.

Actual results, though, are notorious for falling short of what was reported. Action items are left over, and things frequently peter out unless there is a huge effort to force sustainment.

Let’s look at this a little differently.

Typically what happens during the kaizen week is that a new process is designed, and some things are put into place to enable it – point of use, rearranging things for flow, etc.

The report out is describing expected results, and how the process must operate to deliver them.

In other words, a very common outcome of a kaizen event is a pretty well thought out target condition. This is how we want the process to operate, this is the result we are going to strive to achieve. It is all future tense.

What happens next will make or break things.

The next question that should be asked is “Great! When are you going to try it, and what do you expect to learn?” If the report-out does not directly address this question, then you can expect the typical result – steady erosion.

In fact, the process of seeing and addressing those problems must be embedded into the daily management process itself.

The report-out is the beginning of kaizen, not the end. The next phase is not “follow-up.” It is a natural continuation, if less intense, of the kaizen process. The report-out is describing an engineering prototype. Now it is time to test it and discover what we didn’t know during the design process.

 

Posted on

Notes on A White Board

WHAT STOPPED THE WORK TODAY?

Identify each step (details!)

For each step ask:

Why is this necessary? What is its purpose? —-> Eliminate unnecessary, wasteful details.

Can this detail be done outside of the critical flow? —-> re-sequence. Prior to the start, everything ready to go.

Clearly define who must do what and when.

  • Content
  • Sequence
  • Timing
  • Outcome

How will we continuously verify actual work vs. the plan?

Ask “What stopped the work?”

  • Why must the team member leave the work area?
  • What slows him down?

(Back to start)

Posted on

Release the Constraints of Reality

One of the more effective facilitation tools I have come across is to have a team first construct an ideal flow, without the constraints of the space geometry, known flow-busters, or even too much concern about the takt time.

Just make things flow as smoothly and efficiently as you can envision. Develop the flow as though a single person were performing the entire process from start to finish. Make it as smooth as possible for this person. No back tracking, no awkward motions. Everything is where it needs to be, when it needs to be there.

This allows the team to let go of all of the “reasons why not” for a while, and see the possibilities.

Then, one by one, re-introduce the constraints of reality.

How can we make it work when we introduce this problem? Does the process still meet the target objective?

Approaching it this way helps teams that are so embedded in the stormy ocean of day-to-day problems that they can’t see things possibly working smoothly.

It also reinforces the notion that we want to see things, not as “what can we improve from the baseline” but rather “how far are we from the target?”

In slightly modified form, this approach worked pretty well this week. Slightly modified? I, too, sometimes have to bend things around how the world presents itself to me.

Posted on

The Flow of Improvement

Mike Rother shared an overview presentation on the “Improvement Kata.”

 

Introduction to the Improvement Kata

View more presentations from Mike Rother.

The words on one graphic really jumped out at me:

batch-improvement

Aside from his intended point that you never get good at anything but “business as usual” if “business as usual” is what you do most of the time, there are some other implied questions.

First of all, if there were only 15 days between improvement events, that would be overwhelmingly better than what I normally see. Typically a particular area can see months go by between scheduled improvement events.

Most organizations (how about yours?) seem to believe that once an improvement event (or a “belt project”) is concluded, that people should just “follow the new process” to hold the gains.

No wonder we see the advice to “fix it again!” We have to fix it again just to restore it to where it was after it erodes.

But there is a deeper question here.

What kind of “improvement processing” is this? Are we moving toward “one by one flow of improvements” or are we running improvements in batches?

This is batch improvement. We are doing a changeover, running the improvement process, then doing another changeover, and running business as usual.

Unless business as usual includes a robust and reliable process for detecting small problems, responding immediately, clearing them, and solving them, nobody but the event facilitators are learning how to do improvements. People may be learning about improving, but unless they are doing it every day, they are not getting particularly good at it.

Want to see evidence of this? What happens between the events? Do things get better or worse? If “business as usual” includes improvement, things will get progressively better, and you can stop reading this because your organization gets it.

So here are a few questions for you.

Assuming you want to strive for true, daily, continuous improvement, what is the next step you plan to take in that direction?

How will your “business as usual” operate when you take that step?

How is it operating now? What is the gap?

What is stopping you from doing that now? If nothing, then do it now, and cycle back to the first question.

Which of those problems are you working on next?

When are you going to be able to check your results and learn what the next incremental target is?

Now – head down to your work area and ask yourself how you expect problems to be handled. Then watch and see what is actually happening when problems are encountered.

In other words, let’s manage improvements the same way we are asking everyone else to manage production.

Posted on

What Have You Learned?

“What have you learned?” It is a question I hear often at the end of kaizen events and other improvement activity. The key points of a typical report-out, though, seem to be on how much was accomplished, and what was learned comes as an afterthought.

A typical week-long kaizen event is organized like this:

Monday: There may be some classroom type training followed by studying the process. This study is often collecting cycle times and building spaghetti charts.

Tuesday: The team develops their vision or target state – they decide what they are going to do.

Wednesday / Thursday: Make some pretty dramatic changes to the process.

Friday: Report the results followed by pizza for everybody.

The pre-planning often includes some targets for cycle time or inventory, and sometimes even qualifies as a “target condition” that is focused on larger level objectives. But equally often, it doesn’t. The target results are vague or simply “Look at this process and improve it.”

Here is a question – how many coaching cycles – instances where a situation was understood, a target was established, an attempt was made to hit the target, and learning was assessed – actually happen in the course of this week?

In the worst case, zero. Those are the instances where the Friday report-out is followed on Monday by leaving work team to bask in their newly improved process. There is no attempt at all to see what they are struggling with, or if there is, it is an “audit” with the idea of “ensuring compliance” with the new process. No learning at all takes place in this situation. There is only blame shifting.

Nearly as bad is when the answer is “one.” That is, there is some attempt prior to Friday to see if the target condition is achieved, and to understand what new issues have emerged. The problem here is that it is usually too late to do anything. The improvement experts are moving on to planning another event, and whatever is left behind is usually an action item list of incompletes from the week.

That doesn’t work very well either.

Neither does trying to capture “learnings” on a flip chart at the end of the event. That is a nice feel-good exercise, but rarely translates into improving the process of process improvement

So if the above is a “current condition” then what is the target?

How can improvement itself be organized so that we learn how to do it better?

One thing would be to structure kaizen events to cycle through the coaching process many more times during the week. Take the five day agenda, and carry it through EVERY day. That is a start. How would your kaizen events be different if you did five one-day events in a row rather than one five day event? Isn’t that close to one-piece-flow?

What would be the next  step after that?