Creative Safety Supply: Kaizen Training and Research Page

Normally when I get an email from a company pointing me to the great lean resource on their web page, I find very little worth discussing. But Creative Safety Supply in Beaverton, Oregon has some interesting material that I think is worth taking a look at.

First, to be absolutely clear, I have not done business with them, nor do I have any business relationship. I can’t speak, one way or the other, about their products, customer service, etc

With that out of the way, I found their Kaizen Training and Research Page interesting enough to go through it here and comment on what I see.

What, exactly, is “PDCA?”

The section titled Kaizen History goes through one of the most thorough discussions of the evolution of what we call “PDCA” I have ever read, tracing back to Walter Shewhart. This is the only summary I have ever seen that addresses the parallel but divergent histories of PDCA through W. Edwards Deming on the one hand and Japanese management on the other. There has been a lot of confusion over the years about what “PDCA” actually is. It may well be that that confusion originates from the same term having similar but different definitions depending on the context. This section is summed up well here:

The Deming Circle VS. PDCA

In August of 1980, Deming was involved in a Roundtable Discussion on Product Quality–Japan vs. the United States. During the roundtable discussion, Deming said the following about his Deming Circle/PDSA and the Japanese PDCA Cycle, “They bear no relation to each other. The Deming circle is a quality control program. It is a plan for management. Four steps: Design it, make it, sell it, then test it in service. Repeat the four steps, over and over, redesign it, make it, etc. Maybe you could say that the Deming circle is for management, and the QC circle is for a group of people that work on faults encountered at the local level.”

So… I learned something! Way cool.

Rapid Change vs. Incremental Improvement

A little further down the page is a section titled Kaizen Philosophy. This section leans heavily on the thoughts / opinions of Masaaki Imai through his books and interviews. Today there is an ongoing debate within the lean community about the relative merits of making rapid, radical change, vs. the traditional Japanese approach of steady incremental improvement over the long-haul.

In my opinion, there is nothing inherently wrong with making quick, rapid changes IF they are treated as an experiment in the weeks following. You are running to an untested target condition. You will likely surface many problems and issues that were previously hidden. If you leave abandon the operators and supervisors to deal with those issues on their own, it is likely they simply don’t have the time, skill or clarity of purpose required to work through those obstacles and stabilize the new process.

You will quickly learn what the knowledge and skill gaps are, and need to be prepared to coach and mentor people through closing those gaps. This brings us to the section that I think should be at the very top of the web page:

Respect for People

Almost every discussion about kaizen and continuous improvement mentions that it is about people, and this page is no different. However in truth, the improvement culture we usually describe is process focused rather than people focused, and other than emphasizing the importance of getting ideas from the team, “employee engagement is often lip-service. There is, I think, a big difference between “employee engagement” and “engaging employees.” One is passive, waiting for people to say something. The other is active development of leaders.

Management and Standards

When we get into the role of management, the discussion turns somewhat traditional. Part of this, I think, is a common western interpretation of the word “standards” as things that are created and enforced by management.

According to Steve Spear (and other researchers), Toyota’s definition of “standard” is quite different. It is a process specification designed as a prediction. It is intended to provide a point of reference for the team so they can quickly see when circumstances force them to diverge from that baseline, revealing a previously unknown problem in the process.

Standards in this world are not something static that “management should make everyone aware of” when they change. Rather, standards are established by the team, for the team, so the team can use them as a target condition to drive their own work toward the next level.

This doesn’t mean that the work team is free to set any standard they like in a vacuum. This is the whole point of the daily interaction between leaders at all levels. The status-quo is always subjected to a challenge to move to a higher level. The process itself is predicted, and tested, to produce the intended quality at the predicted cost, in the predicted time, with the predicted resources. Because actual process and outcomes are continuously compared to the predicted process and outcomes, the whole system is designed to surface “unknowns” very quickly.

This, in turn, provides opportunities to develop people’s skills at dealing with these issues in near-real time. The whole point is to continuously develop the improvement skills at the work team level so we can see who the next generation of leaders are. (Ref: Liker and Convis, “The Toyota Way to Lean Leadership”)

Staging improvement as a special event, “limited time only” during which we ask people for input does not demonstrate respect, nor does it teach them to see and solve those small issues on a daily basis.

There’s more, but I’m going to stop here for now.

Summary

Creative Safety Supply clearly “gets it.” I think this page is well worth your time to read, but (and this is important), read it critically. There are actually elements of conflicting information on the page, which is awesome because it gives you (the reader) an opportunity to pause and think.

From that, I think this one-page summary really reflects the state of “lean” today: There IS NO CANONICAL DEFINITION. Anyone who asserts there is has, by definition, closed their mind to the alternatives.

We can look at “What Would Toyota Do?” as somewhat of a baseline, but ultimately we are talking about an organizational culture. Toyota does what they do because of the ways they structure how people interact with one another. Other companies may well achieve the same outcomes with different cultural mechanisms. But the interactions between people will override process mechanics every time.

Hopefully I created a lot of controversy here.  🙂

Learning = Extending the Threshold of Knowledge

“My computer won’t boot.”

Mrs. TheLeanThinker’s computer was hanging on the logo screen, keyboard unresponsive.

I know already that if the CPU were bad it wouldn’t get this far.

I also knew that the system hasn’t even tried to boot the OS from the hard drive yet, so that likely isn’t the problem.

Working hypothesis: It’s something on the motherboard.

Start with the simple stuff that challenges the working hypothesis:

  • Hang test a different, known good, power supply. No change.
  • Pull memory cards and reinstall them one by one. No change.
  • Pull the motherboard battery, unplug, wait a few minutes to possibly reset the BIOS. No change.
  • Try holding down the DEL key on power-up to get into BIOS settings. Nope, system still hangs, though it does read that one keystroke, the keyboard is dead after that.
  • Try Ctrl-Home to reach the BIOS flash process. Nope.

image

There is no evidence that the motherboard is not dead. Final test:

Get the numbers off the motherboard, find the same model on Amazon, order it for $37.50 to the door. (Intel hasn’t made this processor type since 2011).

New motherboard arrived today. Switch it out, takes about 30 minutes.

Boot up the machine, works OK, set the time in the BIOS, and pretty much good to go.

Convince Windows 10 that I haven’t made a bootleg copy.

Done.

The Threshold of Knowledge

I learned to code in 1973 on PDP-8 driving teletypes. Although my programming skills are largely obsolete these days, I am comfortable poking around inside the box of a PC, and I generally know how they work. Thus, the troubleshooting and component replacement I described above was not a learning experience. Yes, I learned what was wrong with this computer. (The “bad motherboard” was a hypothesis I tested by installing a new one.) But I didn’t learn anything about computers in general.

Rather than working through experiments into new territory, I was troubleshooting. Something that had worked was not working now. My experiments were an effort to confirm the point of failure.

Therefore, as interesting as the diversion was, aside from a little research on some of the more arcane troubleshooting, it was not a learning exercise for me. It was all within my Threshold of Knowledge.

In the Improvement Kata, “threshold of knowledge” refers to the boundary between “We know for sure” and “We don’t know.” Strictly speaking, we only say “We know” when there is specific and relevant evidence to back it up.

image

In this case, my challenge (fix the wife’s computer) was well inside the red circle.

But this wouldn’t be the case for everyone.

The Threshold of Knowledge is Subjective

Someone else with the same challenge may not see this as a routine troubleshoot-and-repair task. Rather, he has to learn.

I had to learn it at some point as well. The difference is that I had already learned it. I had already made mistakes, taken a week to build a PC and get it working many years ago. I learned by experimenting and being surprised when something didn’t work, then digging in and understanding why. On occasion, especially in the early days, I consulted experts who coached me, or at least taught me what to do and why.

Coaching To Extend the Threshold of Knowledge

Learning is the whole point of the Improvement Kata. That is why we call the “improver” the “learner.” If someone encounters a problem like my example and I am responsible for developing their skills, I am not serving them if I do something like:

  • Sit down at their machine and troubleshoot it.
  • Tell them what step to take, and asking what happened so I can interpret the outcome.

That second case is deceptive. The question is “Who is doing the thinking?” If the coach is doing the thinking, then the coach isn’t coaching, and the learner isn’t learning.

In this case I would also have to recognize this is going to take longer than it would if I did it myself. That is a trap many leaders fall into. They got where they are because they can arrive at a solution quickly. But the only reason they can do that is because, at some point in the past, they had time to learn.

“My computer doesn’t boot.” If my objective is for this person to learn, then I need to go back to the steps of learning. Given that the challenge is likely “My computer operates normally,” what would be my next question to help this person learn how to troubleshoot a problem like this?

I need to know what they know. “Do you know where in the boot sequence it is hanging up?” If the answer is “No,” or just a repeat of the symptom, then my next target condition is for them to understand the high-level sequence of steps that happens between “ON” and the login screen. That would be easy to depict in a block diagram. It’s just another process. But my learner might have to do a little research, and I can certainly point him in the right direction.

I’m not going to get into the details here, because this post isn’t about troubleshooting cranky computers.

General Application

“If somebody comes to me with a problem, I have two problems.”

  • The original issue.
  • The fact that this person didn’t know how to handle it.

You can easily translate my computer example into a production quality example. A defect is produced by a process that normally does not produce them. What is different between “Defect” and “Defect-Free?” Something is. We just don’t know what.

Is it something we need to learn? Something we need to teach? Or something we need to communicate?

If my working challenge for my organization is something like “Everyone knows everything they need to do their jobs perfectly.” then I am confronted every day with evidence that this is not as true as I would like.

If I look at those interventions as “the boss just doing his job” then I lose the opportunity to teach and to grow the organization. I am showing how much I know, and by doing so just extending the dependency. That might feel good in the short term, but it doesn’t do much for the future.

Think about this… in your organization, if the boss were promoted or hired out of the job tomorrow, would you look outside the immediate organization for a replacement? If so, you are not developing your people. When I see senior leaders being hired from outside, all I can do is wonder why they have so little faith in the people they already have.

_________

*I remember when Gateway built their own machines, which I guess shows how long I’ve been playing with PCs. Then again, I remember when the premium brand was Northgate. Of course, I also remember programming on punch cards.

It’s “What must we learn?” not “What should we do?”

Darren left a great question in the Takt Time-Cycle Time post:

Question… Which system is more efficient, a fixed rigid Takt based production line or a flexible One Piece Flow?

In terms of designing a manual based production line to meet a theoretical forecasted ‘takt time’, (10 fixed workstations needs 10 operators), how do you fluctuate in a seasonal business (+/-25%/month) to ensure you don’t end up over stocking your internal customer?

Would One Piece Flow be more efficient on the whole value chain in this instance due to its flexibility?

That was a few weeks ago. Through its evolution, this post has had four titles, and I don’t think there is a single sentence of the original draft that survived the rewrites.

I started this post with a confident analysis of the problem, and the likely solution. Then I realized something. I don’t know.

My brain, just like every other brain on the planet (human and others) is an incredibly efficient pattern matching machine. I got a little bit of information, and immediately filled in a picture of Darren’s factory and proceeded to work out a course of actions to take, as well as alternatives based on other sets of assumptions.

NO, No, no!

Our Reflex: Jumping to Solution

This graphic is copied from Mike Rother’s presentation material. It is awesome.

image

It is likely that at this point you know that it doesn’t say “JUMPING TO CONCLUSIONS” under the little blue square, and of course you are right.

image

But in spite of the fact that you know the truth, it is likely you still read “JUMPING TO CONCLUSIONS” when you look at the first graphic. I know I do, and I present this all of the time.

Our brains are all wired to do this, it is basic survival. It happens very fast. Think about a time when you have been startled by something you thought you saw, that a few seconds later you realized it was nothing.

That pattern recognition triggered the startle. It was seconds later that your logical brain took over and analyzed what was really going on. This is good. We don’t have time to figure out if that movement in the grass was really a leopard or not. We’ll sort that out after we get away.

Our modern brains work the same way with learned patterns imagebut we are usually very poor at distinguishing between “what we really know” and “what we have filled in with assumptions.”

This is the trap that we “lean experts” (whatever that means) fall into all of the time. We take limited information, extrapolate it into a false full understanding, and deliver a diagnosis and treatment.

Boom. Done. Next?

What’s even worse is we often don’t hang around to see if the solution worked exactly the way we expected, or if anomalies came up.

In other words, everything comes down to takt, flow and pull, right? Kinda, but kinda not.

Some Technical Background

All of the above notwithstanding, it really helps to understand how the mechanics of “lean” tie together to create the physical part of an organic/technical process.

What I mean by “really helps” is this understanding gives you a broad sense of how the mechanics help people learn. Someone who only understands the mechanics as “a set of tools” is committing the gravest sin: Leaving out the people.

One Piece Flow

One piece flow is not inherently efficient. It is easy to have lots of excess capacity, which translates to either overproduction or waiting, and still have one piece flow.

This is the people part: One piece flow makes those imbalances very obvious to the people doing the work so you can do something about them, if you choose to. Many people think the goal is one piece flow. The goal is making sure the people doing the work can see if the flow is going smoothly or not; and give them an opportunity to fix the things that make flow less than smooth.

A pull system is designed to throw overproduction (or under-production) right into your face by stopping your line rather than allowing excess stuff to just pile up. Again, it is a tool to give the people doing the work immediate visibility of something unexpected rather than the delayed reporting of inventory levels in a computer somewhere.

Flexibility

Any given level of capacity has a sweet spot for efficiency. Even “inefficient” systems are most efficient when their capacity (usually defined by a bottleneck somewhere) is at 100% utilization (which rarely happens).

If other process steps are capable of running faster (which is the very definition of a bottleneck), they will, they must either be underutilized or build up work-in-process. This is part of the problem Darren is asking about – flooding his downstream operation with excess WIP to keep his line running efficiently.

If your system is designed to max out at 100 units / day, and you make less than, that your efficiency is reduced. If the next operation can’t run at 100 units / day and absorb your output, then it is the bottleneck. See above.

Now, let’s break down your costs of capacity. In the broadest sense, your costs come down to two things:

  • Capital equipment. (And let’s include the costs of the facility here.)
  • Labor – paying the people.

The capital equipment cost is largely fixed. At any rate of production less than what the equipment is capable of holding, you are using it “less efficiently” than you could. Since machines usually operate at different rates, it is you aren’t going fully utilize anything but the slowest one. It doesn’t make sense to even try.

People is more complicated. In the short term, your labor costs are fixed as well. You are paying the people to be there whether they are productive or not.

When the people are operating machines, your flexibility depends on how well the automation is designed. The technical application of “lean tools” to build flow cells pushes hard against this constraint. We strive to decouple people from individual machines, so the rate can flex up and down by varying the work cycles rather than just having people wait around or over produce.

At the other end of the labor spectrum is pure manual work, like assembly. We are striving for that same flexibility by moving typically separated operations together so people can divide the labor into zones that match the desired rate of production.

All of these approaches strive for a system that allows incrementally adjusting the capacity by adding people as needed. However this adds costs as well, often hidden ones. Where do these people come from, and frankly, “what are they doing when they aren’t working for you?” are a couple of questions you need to confront. The people are not parts of the machine. The system is there to help the people, not the other way around. This is people using tools to build something, not tools being run by people.

Handling Seasonal Production Efficiently

“Our demand is seasonal” is something I hear quite a bit. It is usually stated as though it is a unique condition (to them) that precludes level production. In my nearly 30 years in industry, I haven’t encountered a product (with the possible exception of OEM aircraft production and major suppliers) that didn’t have a seasonal shift of some kind.

Depending on the fluctuations and predictability of future demand, using a combination of managing backlog and building up finished goods is a pretty common way to at least partly level things out for planning purposes.

That being said, I know of at least one company whose product is (1) custom ordered for every single unit and (2) highly seasonal (in fact, they are in their peak season as I write this). They don’t have as many options.

Solving the Problem

With all of that, we get to Darren’s specific question.

The short answer is “I don’t know, but we can figure it out.”

There isn’t a fixed answer, there is a problem to solve, a challenge to overcome.

Challenge

I am interpreting the challenge here as “Have the ability to flex production +/- 25% / month without sacrificing efficiency.”

Just to ensure understanding of the challenge, I would ask to translate the production capacity targets into takt times. What is the fastest takt time you would need to hit? What is the slowest?

In other words, the +/-25% makes me do math, even if I know the baseline, before I really know what you need to be able to do. Let’s get some hard numbers on it so we will all agree when we see it, or don’t.

Remember, takt time is simply a normalization of your demand over your production time. It is a technique for short-term smoothing of your demand. It doesn’t mean you are operating that way.

Current Condition

We need to learn more, so the next questions have to do with the current condition.

While this post is too short to get down to the details, there are some additional questions I would really need to understand here.

Known: There are 10 fixed workstations with 10 operators.

Assumed to be known: The high and low target takt times (from the challenge).

How are the workstations laid out?

What are the cycle times of each operation?

What is actually happening at each of the workstations?

What are they currently capable of producing in relation to the takt times we want to cover in our +/- 25% range?

A good way to start would be to get exit cycles from each of the positions, and from the whole line. What is the current cadence of the operation? What are the lowest repeatable cycle times? How consistently is it able to run? What is driving variation?

Since we are looking for rate flexibility, I am particularly concerned with understanding points of inflexibility.

I would be looking at individual steps, at distance between the workstations, and how easily it is to shift work from one to another. Remember, to be as efficient as possible, each work cycle needs to be as close as possible to the takt time we are striving to achieve this season. Since that varies, we are going to need to create a work space that gives us the smoothest transitions possible.

What is the Next Target Condition?

I don’t know.

Until we have a good grasp of the current condition, we really can’t move beyond that point. While I am sure Darren knows much more, I am at my threshold of knowledge: 10 workstations, 10 operators. That’s all I know.

However I do know that it is unlikely I would try to get to the full challenge capability all at once. Even if I did have a good grasp of the current condition, I probably can’t see the full answer, just a step that would do two key things:

  • Move in the direction I am trying to go.
  • Give me more information that, today, is hidden by the nature of the work.

For an operation this size, (if I were the learner / person doing the improvement here) I would probably set that target condition for myself at no more than a week or two. (This also depends on how much time I can focus on this operation, and how easy it is to experiment. The more experiments I can run, the faster I will learn, and the quicker I can get to a target.)

Now… I will re-state the target condition to answer this question:

“We can’t… [whatever the target condition is]… “because ________.” as many times as I can. That is one way to flush out obstacles.

Another way is just to tell the skeptics we are going to start operating like this right away, then write down all of the reasons they think it won’t work. Smile

Then the question is “OK, which of these obstacles are we going to address first?”

Iterate Experiments / PDCA to learn.

Once I know which obstacle I am choosing to address first, I need to know more about it. What do I want to learn, or what effect do I want to have on the process? Those things are my expected result.

Now… what do I need to do to cause that to happen? That is my next experiment.

And we are off to the races. As each learning cycle is completed, your current condition, your current level of understanding, changes. As you learn more, you better understand the obstacles and problems.

When you reach a target condition (or realize you are at the deadline and haven’t reached it), then go back to the top, review the challenge, make sure you understand the current condition, and establish a new target. Lather, rinse, repeat.

This Isn’t About “The Answers.”

imageA long time ago, when I first started this blog, I wrote a post called “The Chalk Circle.” I told the story of one of my more insightful learning experiences in the shadow of one of the original true masters, the late Yoshiki Iwata. My “ah ha” moment finally came several years later, and a year after his death. He wasn’t interested in the answers, he was teaching me the questions.

We don’t know the answers to a problem like “How do I get maximum efficiency through seasonal demand changes.” The answer for one process might give you something to think about, but copying it to another is unlikely to work well. What would work for Darren’s operation is unlikely to work in Hal’s. Even small differences mean there is more learning required.

When confronted with a problem, the first question should never be “What should we do?” Rather, we need to ask “What do we need to learn?”  What do we know? What do we not understand? What do we need to learn, then what step should we take to learn it? Taking actions without a learning objective is just trying stuff and hoping it works without understanding why.

What works is learning, by applying, the thinking behind sound problem solving, and being relentlessly curious about what is keeping you from moving to the next level.

I have come a long way since my time with Mr. Iwata, I continue to learn (lots), sometimes by making mistakes, sometimes with unlikely teachers, at times and in ways I least expect it. Sometimes it isn’t fun in the moment. Sometimes I have to confront something I have hidden from myself.

One thing I have learned is that the people who have all of the answers have stopped learning.

Darren – if you want to discuss your specific situation, click on “Contact Mark” and drop me an email.

Toyota Kata: What is the Learner Learning?

In the language of Toyota Kata we have a “coach” and a “learner.” Some organizations use the word “improver” instead of “learner.” I have used those terms more or less interchangeably. Now I am getting more insight into what the “learner” is learning.

The obvious answer is that, by practicing the Improvement Kata, the learner is learning the thinking pattern that is behind solid problem solving and continuous improvement.

But now I am reading more into the role. The “learner” is also the one who is learning about the process, the problems, and the solutions.

Steve Spear has a mantra of “See a problem, solve a problem, teach somebody.” This is, I think, the role of the learner.

What about the coach?

The coach is using the Coaching Kata to learn how to ask questions that drive learning. He may also be un-learning how to just have all of the answers.

As the coach develops skill, I advise sticking to the Coaching Kata structure for the benefit of beginner learners. It is easier for them to be prepared if they understand the questions and how to answer them. That, in turn, teaches them the thinking required to develop those answers.

Everybody is a Learner

The final question in the “5 Questions” is “When can we go and see what we have learned from taking that step?” It isn’t when can I see what You have learned. It is a “we” question because nobody knows the answers yet.

The Improvement Kata: Next Step and Expected Result

In the Improvement Kata sometimes it helps to think about the outcome desired and then the step required to accomplish it.

A couple of months ago, I gave a tip I’ve learned for helping a coach vet an obstacle.

Another issue I come across frequently is a weak link between the “Next Step” and the “Expected Outcome.”

In the “Five Questions” of the Coaching Kata we have:

What is your next step or experiment?” Here we expect the learner / improver to describe something he is going to do. I’m looking for a coherent statement that includes a subject, verb, object here.

Then we ask “What do you expect?” meaning “What do you expect to happen?” or “What do you expect to learn?” from taking that step?

I want to see that the “Expected Result” is a clear and direct consequence of taking the “Next Step.”

Often, though, the learner struggles a bit with being clear about the expected outcome, or just re-states the next step in the past tense.

While this is the order we ask the questions, sometimes it helps to think about them in reverse.

Reverse the Order

Have the learner first, think about (and then describe) what she is trying to accomplish with this step. Look at the obstacle being addressed, and what was learned from the last step.

Based on those things, ask “what do you want to accomplish with your next step?”

The goal here is to get the learner to think about the desired result. Don’t be surprised if that is still stated as something to do, because we are all conditioned to think in terms of action items, not outcomes.

“What do you need to learn?” sometimes helps.

“I need to learn if ______ will eliminate the problem.” might be a reply.

Even a proposed change to the process usually has “to learn if” as an expected outcome, because we generally don’t know for certain what the outcome will be until we try it.

Have the learner fill in the “Expected Outcome” block.

NOW ask “OK, what do you have to do to ______ (read what is in the expected outcome)?”

PDCA Outcome-Activity

That should get your learner thinking about the actions that will lead to that outcome.

A Verbal Test

A verbal test can be to say “In order to ______ (read the expected outcome), I intend to _____ (read the next step.”

If that makes sense grammatically and logically, it is probably well thought out.

Toyota Kata: Is That Really an Obstacle?

“What obstacles do you think are preventing you from reaching the target condition?”

When the coach asks that question, she is curious about what the learner / improver believes are the unresolved issues, sources of variation, problems, etc. that are preventing the process from operating routinely the way it should (as defined by the target condition).

I often see things like “training” or worse, a statement that simply says we aren’t operating the way the target says.

Here is a test I have started applying.

Complete this sentence:

“We can’t (describe the target process) because ________.”

Following the word “because,” read the obstacle verbatim. Read exactly what it says on the obstacle parking lot. Word for word.

If that does not make a grammatically coherent statement that makes sense, then the obstacle probably needs to be more specific.

 

 

Toyota Kata: Don’t Change The Target Condition Date

A target condition has three main elements:

  • An achieve-by date.
  • A level of performance that will be achieved.
  • The operational process that will be in place.

The details of the #2 and #3 can take a number of forms, but today I want to talk about the achieve-by date.

Keep the time horizon fairly short, especially at first. For a typical process that is carried out every day, I usually suggest a two week time horizon. My rationale is this: I don’t want the target condition to seem big or complex. Two weeks is enough time to understand and significantly improve a handful of steps in a complex process. It is a short enough time to keep the improver from trying to fix a complex or global issue all at once.

For example, if a process is carried out in multiple departments, two weeks is enough to try experiments in one of them, but not enough to implement a change across the whole organization. Having that time horizon helps establish the principle of small, quick, steps rather than trying to develop some kind of implementation plan.

It is important to set an actual date, not just “in two weeks” – in two weeks from when?

But here is the most important part: Once the date is set, don’t change it.

If the date comes up, and the target condition hasn’t been reached, it is very tempting to say “Just a few more days.” But once a date is slipped, the date means nothing, because it can be slipped again.

Instead, missing the date is time to step back, reflect, and go back through the steps of the improvement kata.

This is the same thing you should do when you hit your target condition.

If you hit your target way early, or miss the date, it is also time to reflect on what you didn’t understand about your current condition when you established that target. Then:

  • Confirm understanding of the direction and challenge.
  • Grasp the current condition. This is important. Don’t just assume you know what it is. Take the time to do some observations and confirm everything is working the way you think.
  • Establish the next target condition. This means erasing the old target condition, starting with a clean obstacle sheet, looking at the current condition and establishing a new target condition. I would discourage you from simply re-stating the old one. List the obstacles that you think are now preventing you from reaching the new target.
  • Pick one obstacle (an easy one, not the one you were beating your head on for the last two weeks!), and design your next experiment. Start your PDCA iteration.

Coaches: Don’t let your learner just adjust the date. There is a learning opportunity here, be sure to capitalize on it.

 

Toyota Kata and Hoshin Kanri

Jeff asked an interesting question in a comment to the post Often Skipped: Understand the Challenge and Direction:

[Hoshin Kanri] seems to suggest I reach long term objectives (vision) through short term initiatives/projects as if I can (should?) know the steps. [Toyota Kata] says I don’t know the way to reach my long term vision, so I limit focus to next target condition and experiment (repeatedly) toward the vision.

Seems contradictory to me. What am I missing?

Let’s start out with digging into what hoshin kanri is supposed to do. I say “supposed to do” because there are a lot of activities that are called “hoshin kanri” that are really just performance objectives or wish lists.

First, hoshin kanri is a Japanese term for a Japanese-developed process. We westerners need to understand that Japanese culture generally places a high value on harmony and harmonious action. Where many Americans (I can’t speak for Europeans as well) may well be comfortable with constant advocacy and debate about what should be worked on, that kind of discussion can be unsettling for a Japanese management team.

Thus, I believe the original purpose of hoshin kanri was to provide a mechanism for reaching consensus and alignment within a large, complex organization.

In the late 1980’s and early 1990’s, hoshin kanri concepts emerged out of their Japanese incubator and came to western business. In this process, the DNA combined and merged with western management practices, and in many (never say “all”) western interpretations, the hoshin plan tends to be something patched onto the existing Management By Objectives framework.

That, in and of itself, isn’t a bad thing. Hoshin kanri’s origins are from MBO migrating to Japan where they took MBO and mixed in Japanese cultural DNA.

However, I’m not comfortable that what we have ended up with in the west meets the original concept or intent.

With that as background, let’s get to the core of Jeff’s question.

What is the purpose of hoshin kanri?

Let’s start with chaos. “We want continuous improvement.”

In other words, “go find stuff to improve,” and maybe report back on what you are going to work on. A lot of organizations do something like this. They provide general guidance (if they even do that), and then maybe have the sub-organization come tell and report what they expect to accomplish. I have experienced this first hand.

“I expect my people to be working on continuous improvement,” says the executive from behind his desk in the corner office. Since he has delegated the task, his job is to “support his empowered workforce” to make things better.

image_thumb.pngFlatly, that doesn’t work unless the culture is extremely well aligned and there is a
continuous conversation and stream of consciousness within the organization
. That is very rare. How to achieve that alignment is the problem hoshin kanri is intended to solve. It isn’t the only way to do it, but it is an effective method.*

A Superficial Overview of the Process of Hoshin Kanri

The leadership sees or sets a challenge for the organization – something they must be able to do that, today, they cannot. This is not (in my opinion) the same as “creating a crisis.” A crisis just scares people. Fear is not a good motivator for creative improvement.

Different parts of the organization may get a piece of the challenge, or the leadership team may, as a whole, work to figure out what they need to accomplish. Here is an important distinction: “What must be accomplished” is not the same as a plan to accomplish it. A challenge, by its very nature, means “We don’t know exactly what we will have to do to get there.”

This can take the form of KPI targets, but that is not what you are doing if there is a simple percent improvement expected with no over-arching rationale.

Now comes the catchball.

Catchball is not Negotiation of the Goal

Catchball is often interpreted as negotiating the goals. That’s not it. The goals are established by a market or competitive or other compelling need. So it isn’t “We need to improve yield by 7%.” followed by “Well, reasonably, I can only give you 5%.” It doesn’t work like that.

Nor is it “You need to improve your yield by 7%, and if you don’t get it then no bonus for you.” That approach is well known to drive some unproductive or ineffective behavior.

And it isn’t “You’re going to improve your yield by 7% and this is what you are going to do to get there.”

Instead, the conversation might sound something like “We need to improve our yield by 7% to enable our expected market growth. Please study your processes as they relate to yield, and come back and let me know what you think you need to work on as the first major step in that direction.”

In other words, please grasp your current condition, and come back with your next target condition.

That sounds a lot like the Coaching Kata to me.

SIDEBAR:

Toyota Kata is not a problem solving method. 

Toyota Kata is a set of practice routines designed to help you learn the thinking pattern that enables an organization to do hoshin kanri, and any other type of systematic improvement that is navigating through “We want to get there, but aren’t sure exactly how.”

An executive I am working with mentioned today that Toyota Kata is what is informing their policy deployment process. Without that foundation of thinking, their policy deployment would have been an exercise in assigning action items and negotiating the goals.

So what is the difference between hoshin kanri and Toyota Kata?

There isn’t a difference. They are two parts of the same thing. Hoshin kanri is a mechanism for aligning the organization’s efforts to focus on a challenge (or a few challenges).

Toyota Kata is a practice routine for learning the thinking pattern that makes hoshin kanri (or policy deployment) function as intended.

In hoshin planning, you are planning the destination, and perhaps breaking down individual efforts to get there, but nothing says you already know how to get there.

It isn’t an “action plan” and it isn’t a list of discrete, known action items. Rather, it is specific about what you must accomplish, and if you accomplish those things, then the results are predicted to add up to what you need.

What to Do vs How to Get It Done

At some point, someone has to figure out how to make the process do what is required. That has to happen down at the interface between people and the work actually being done. It can’t be mandated from above. Hoshin helps to align the efforts of improving the work with the improvements required to meet the organization’s challenge.

From the other side, the Improvement Kata is not about short-term objectives. The first step is “understand the challenge and direction.” Part of the coach’s job is to make sure this understanding takes place, and to ensure that the short-term target condition is moving in the direction of the challenge.

We set shorter term target conditions so we aren’t overwhelmed trying to fix everything at once, and to have a stable anchor for the next step. It enables safer learning by limiting the impact of learning that something didn’t work.

However, in Toyota Kata, while we might not know exactly how to get there, but we are absolutely clear where we have to end up.

The American Football analogy works well here. The challenge is “Score a touchdown.” But if you tried to score a touchdown on every play, you would likely lose the game. The target condition is akin to “get a first down.” You are absolutely clear what direction you have to move the ball, and absolutely clear where you need to end up in order to score. But you aren’t clear about the precise steps that are going to get you there. You have to figure that out as you go.

Hoshin Kanri focuses the effort – “What to work on.”

Toyota Kata teaches the thinking behind “How to work on it.”


*Though hoshin kanri may be effective, getting it to work effectively is a journey of learning that requires perseverance. It is much more than filling out a set of forms.

Toyota Kata in Health Care

I’m about four months into helping a major regional hospital develop a solid foundation for applying the Improvement Kata and Coaching Kata to learn “improvement thinking.”

They now have active improvement boards running in pre-op, post-op, surgery, radiology, the lab, the emergency department, the cardio-vascular floor, medical-surgery floor, ICU, cardiac rehab, billing, admissions, case management, and supplies. I think that’s everything going right now.

Several of these departments have more than one board, and a few are beginning to get started spontaneously.

We are starting to see the culture begin to shift in many of these departments. Staff are getting engaged in improving the work flows, administration team members are more engaged with the staff.

Directors and managers are starting to reach across organizational boundaries to deal with obstacles and problems at the departmental interfaces.

And the organizations are starting to shift how they talk. When confronted with a list of problems, leaders are starting to ask “OK, which one are we addressing first?” Leaders are asking “What do you expect to happen?” and “What did we learn?” when talking about actions. They are working to engage thinking in their organizations vs. just giving direction.

Is it all rainbows and unicorns? Of course not. But the effort is clearly being made, and it shows. My overall process coaching is getting much more nuanced, because they are “getting” the fundamentals.

OK, so what did we do?

We started out with two weeks of pretty intense “kick-start.” One week was half-days of training and simulation (with a morning and afternoon group), getting a feel for the rhythm of the improvement kata, and a taste of the coaching kata, and culminating with the first round of improvement boards getting set up with at least a direction, if not a clear challenge.

We deliberately did not use industrial examples. And now that I’ve done it a few times, I can incorporate more health care language and examples into the sessions, which just makes it easier.

Week two was pairs of learners/coaches being coached through grasping the current condition, establishing a target condition, and the first couple of PDCA cycles / experiments.

But what made it work is they kept at it.

The next month, we did it again. We coached the established boards to tighten up their game, while establishing a series of new ones.

Because they had kept at it, the first round of boards now had a routine for their improvement cycles and coaching. And once there is a pattern, then we can work on improving it.

What I am learning.

Just get them going, then leave them alone for a while to keep at it. That lets the team establish a baseline routine for how they are practicing. Then I can come back periodically and propose adjustments on one or two items that let them step it up to the next level.

I am finding this much more effective than demanding they get it perfectly from day one. There is just too much to think about.

Establish a target condition, have them practice to that pattern, grasp the current condition, establish a new target… for the team’s practice. Get the improvement engine running, even if roughly, then work on tuning it for performance.

To be clear, this is my normal approach (and it is different, I am told, from what a lot of others try to do), but I am getting a lot of validation for it here.

Results

A member of the administration (leadership team) who is actively coaching shared this chart with me today. I have “sanitized” it a bit. Suffice it to say these three lines represent the percentage of deliveries of three separate (but related) processes within or before the target turn-around time of 30 minutes. Their challenge is to turn 95% of them around in 30 minutes or less.

The vertical red line represents when they started applying the Improvement Kata to this process.

Otherwise, the picture speaks for itself.

image

They have recognized that there is no silver bullet here. Rather, there have been dozens (or more) of changes that each save a little bit of time that is adding up.

As one of my early Japanese teachers said “To save a minute, you must find sixty ways to save a second.” and that is exactly what they are doing here. They are finding a minute here, a few seconds there, and anchoring them in changes to the way they organize the work flow.

Lab Team: “Way to go!”

Another Homework Question

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

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

I find this interesting on a couple of levels.

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

What are we teaching?

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

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

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

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

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

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

Edit: Today I saw two more searches for:

total work content divided by slowest machine cycle time

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

Thoughts?