Category: The Basics

Posted on

Why Don’t They See This Is Better?

“Resistance to change” is a common theme of discussion among practitioners on various online forums, as well as in emails I get from readers.

One thing I see fairly often is that a practitioner will be suggesting a visual control or a specific application of a “lean tool” as a “better way” in the process being examined.

“They can just look it up on the computer,” say those holding on to the status quo, “why do we need to put up a board?”

Why indeed?

So the practitioner tries to make a logical case, and often comes away frustrated. “Leaders aren’t supporting the changes” is a common lament at this point.

But let’s break down the problem and see if there is more we can do.

We are often debating whether or not a particular solution is better than the current way.

But in our “implement the tools” approach, we tend to make “lack of a specific solution” into a problem.

Whoa. Let’s back up a bit and see if we can head this off.

Do you have agreement on a clear target objective, one that all parties can describe? Do you know how the process should be performing?

Note I said “should” not “could.”

“Could” is potential.

“Should” is an unmet expectation. Big psychological difference there.

If everyone agrees that the status quo isn’t getting it done, and also agrees on what they want to achieve instead, then the next question is “OK, what is stopping us from taking the next step?”

This shouldn’t be an abstract exercise. As you watch the people in the process try to reach a higher performance level, look for “What just got in our way?”

You need to help the leaders, and your other constituents see it with their own eyes. Don’t expect them to take your word for it. You wouldn’t take theirs without your own observation.

If everyone can see, for example, that a team member gets too far behind to recover before anyone else notices, or that a machine is experiencing stoppages or excessive changeovers, for example, then you can start discussing solutions.

Perhaps the team leader needs to make quick status checks periodically, in a way that is not intrusive.

What is stopping him?

Well, that’s difficult right now, because everything is buried in the computer, and often updated in batches after the work is done.

Hmmm.. What could we do to make things more visible, in real time? Is there a way we can set up the work area so the team leader (and the worker, and anyone else just happening by) could readily see there is an issue here?

Now, and not before, is the time to start discussing solutions. But you can’t just make the logical argument. You have to get agreement each step of the way.

That might very well take longer than you want it to. People are funny that way.

But the bottom line is this: “Lack of your pet solution,” no matter how many books and name-brand authors refer to it, “is not a problem.”

We create a lot of our own resistance by running into things, and leaving fires behind us.

Posted on

5S in Three Bullets

I was in a conversation today and we ended up boiling 5S down to three key points:

  • You have everything you need.
  • You need everything you have.
  • You can see everything clearly belongs where it is.

Of course at the next level, these statements are the standards you are continuously checking against.

Presumably we have cleared out everything else, leaving only what we thought was needed, and established visual controls to verify we have those things, and only those things, in the work area.

Then, as the work is done, the moment someone discovers something else is needed, THAT is the time to deal with the issue.

– Ask “Is this something we should need in the normal course of the work?”

If so, then you learned something that you didn’t know or didn’t remember when you first organized the area. Add that item, find a place for it, and establish a visual control. Right now.

If not, then “Why did we need it this time?”

What broke the normal pattern of work?

This is where 5S breaks down – when we don’t discriminate between something that is needed in the normal course of work, and something that is needed as an exception.

If we just “get it” and add it to the work area, then we normalize deviance and incrementally erode the process. If we ignore the issue, we add “getting this when it is needed” to the work cycle.

If, on the other hand, we seek to understand what broke the normal pattern and deal with the core issue, we have a shot at real kaizen. (It is perfectly OK to get what you need and keep it around as a temporary countermeasure. Just put it someplace where you will KNOW when you used it.)

The worst thing you can do is allow these small problems to accumulate and try to correct them en-mass as some kind of “corrective action.”

Kanban

Likewise, kanban can be expressed the same way. It is more dynamic, but is really answering the same questions in the context of materials.

 

Standard Work

If you paraphrase these key points to just about any other “tool of lean” then the purpose of surfacing problems and driving solution becomes apparent.

  • You are doing everything that is required.
  • Everything being done is required.
  • Everything being done clearly is part of the sequence.

Take a look at the other classic “tools of lean.” How would they fit into the same pattern?

 

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

Measuring Improvement

One of the most common (and frustrating) problems for the staff lean practitioner is being asked to “measure the savings” resulting from specific improvements.

(This problem is related to, but different from, trying to measure “lean progress” or the status of implementation.)

There are two issues in play here.

First is the level of understanding in the leaders who ask for this in the first place. Frankly, it isn’t their fault. Authors, consultants, and practitioners have been “selling” the concept of “lean production” as a stand-alone thing to do for decades.

It is really easy, in the initial excitement of grasping the potential, to just try to push the tools and promise that great savings will result from simply implementing them.

The initial literature was all about describing the performance of benchmark companies (like Toyota, though there were others), describing the visible tools and saying, in effect, “if you just implement these tools, you’ll get this kind of results.

But making these changes can be expensive. The obvious costs are consulting fees, time (perceived to be) taken away from production work. Therefore, there must be a sufficient ROI to “justify” making the changes.

For the practitioner, the countermeasure is to try to shift the focus to establishing a business objective first.

This shifts the conversation from “justifying improvement” to “what problems must we solve to hit the objective?”

The financial evaluation then shifts from "justifying moving beyond the status-quo” to evaluating alternative solutions to the problem.

If you ask directly, most managers will have things in mind that they would like to do better. The challenge is to get those things framed in enough detail that some value is created for actually getting there.

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

Lean Facilitators are Countermeasures

What is the role of your lean facilitator?

This question comes up now and again, was recently posed on the LEI forums by someone looking for help with a job description.

I extrapolated from his question that he was looking to the job description as a line of defense against dilution of the facilitator’s focus and effort by projects that might not be going in the appropriate direction.

In effect, this is putting the lean facilitator in the role of a weakened zampolit with the role of educating the “correct view” and challenging decisions that run counter to it. Except that more often he has to sell the “correct view” rather than impose it.

The fact that the question is being asked at all indicates that the organization has not really thought through what their operational vision is. How will the company work, what are the responsibilities and roles of the leaders?

What are the leaders’ job descriptions in this new world?

Those job descriptions become a target condition for each of them.

What is the gap?

If there are gaps in skills and knowledge, then we need countermeasures.

At this point, the role and responsibility of a lean facilitator might begin to emerge as one of those countermeasures. Don’t have the expertise? Import it.

What doesn’t work, though, is to use the lean facilitator to substitute for the leader’s full and direct participation in the process of improvement. And no job description, no matter how carefully crafted, can fix that.

Posted on

The Benefits of Continuous Improvement

There are a lot of variations on a theme where someone asks an Internet forum how to quantify or justify the benefits of implementing a continuous improvement program.

If you think about it, though, this is really interesting question.

What are the benefits of NOT having continuous improvement? Why would managers deliberately decide not to have a learning organization, not to have continuous improvement, not to fully engage the intelligence of their workers?

Why would managers deliberately decide not to improve safety, quality, delivery, lead times?

What if we asked the question that way?

What is the benefit of not having these things?

If that question is subsequently dismissed as stupid (which I hope it would be), then the question is no longer whether they should be pursued, but how.

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

One, Zero and Zero

Sometimes we like to talk in abstracts. “Reduce batch sizes” or “reduce lead time.”

But let’s be clear what we are striving for. With every improvement we make, we want to converge on the idea of:

  • Batch size of one.
  • Lead time of zero.
  • Zero waste of resources.

Lest anyone thinks that is impossible, consider the post before this one about 3D printing technology, and look where it is going.

As Mike Rother emphasizes in his teaching the trend throughout the history of making things has been in this direction.

The pendulum swung in favor of volume in the industrial revolution as production shifted from craft (batch size of one, long lead times, high costs) toward large batches, in order to achieve better economics.

Somewhere along the way, we lost sight of the fact that we gave something up for those lower costs.

The companies that can return the benefits of one-off production while holding the costs are going to win.

But.. make no mistake… the suppliers of cheap mass molded and cast parts have a disruptive technology headed their way that fits the model perfectly.