Kaizen – Page 4 – The Lean Thinker

May 6, 2013January 9, 2019

Kaizen vs. Kaizen “Events”

I got an interesting email from a friend a while ago, and am finally finishing up this post about it. Some months ago, he joined a new company and wrote about his impressions of some of the legacy he was walking into:

[before my arrival, the company] used Xxxxxx consultants to get their Lean effort up and running.

They were given training modules that are 30-40 slides long and unbearable to sit through.

They were taught a very rigid approach to kaizen that focuses more on strict standards than helping to improve performance.

As a result there are deep divides between some of the groups here and the Lean team. It’s unbelievably frustrating to see how much money was spent learning an approach to Lean that is outdated and ineffective.

Actually, it was worse than ineffective, it was detrimental in a lot of ways. There are numerous areas we have to dig ourselves out of a hole that was created by events that absorbed substantial resources for zero long term gain.

He goes on to ask for a discussion on The Lean Thinker…

[…] about the event and tools based approach versus the daily problem solving approach.

And goes on to observe:

There is still a deep divide in the Lean world as to which is the best method. It’s seems to me that there are more people on the event and tools side of the fence than there are on the daily problem solving side of the fence.

I included these quotes because this is a real perception from the real world. My friend recognizes the need to adopt daily improvements driven by line leaders.

What he sees, though, is that these kaizen events didn’t (in his view) transfer those skills, or that behavior, to the organization.

There is nothing unusual about the process described above. I was taught pretty much the same thing: A “kaizen event” is about a specialist workshop leader planning and conducting the event “to the standard.”

Who are you developing?

This approach does develop a skill in the organization.

A relatively small group of people (usually the promotion office staff) get pretty good at planning and running kaizen events following whatever standard is in place.

They get good at it because they are the ones who plan and run those events, over and over. In other words, they practice.

That, of course, begs the question: Who are you developing?

I’ve seen (and been in) a number of companies who strive to have “every team member participate in at least one kaizen event a year.” In a plant with 250 team members, at 8-12 of them participating in a typical kaizen event, that works out to something like 25 kaizen events a year, or a bit more than two a month. A typical promotion office staff in a plant this size might be able to keep up with that rate, but I have seen more struggle to do so than succeed.

So with this tempo of kaizen events, each team member gets to participate in an improvement activity roughly once a year.

Granted, a lot can get done over the course of that week. But the other 49 weeks are business-as-usual, so business-as-usual is what they are learning.

Put another way, if you want to get good at skiing, it is going to take more than one week on the slopes every winter.

More Important: What are you striving for?

This is really the same question I asked above, but in the context of the purpose of your kaizen events.

What was that consultancy striving to do with their client?

What was the client striving for?

My guess is both were pushing hard for rapid measurable results – an immediate and visible return on the investment.

But if you are striving to develop leaders, then the kaizen event takes on a completely different tone. (Note that when I say “leaders” I don’t limit myself to people in formal leadership position. I mean anyone who is willing and able to step up to a challenge, and enlist the help of others to meet it.)

There is also a very different expectation for what happens after a kaizen event. No longer do we have lists of actions to complete. Rather, we have the current obstacle we are working on, and the next experiment that is going to be conducted on Monday.

The key is that a kaizen event has to kick-start a change in the daily routine that goes above and beyond changing the work. I’ll go so far as to say that changing the work is secondary. If you can kick start getting improvement as part of the daily work, then the work itself will improve quickly enough.

Your measure of success, then, is not the results you get during the kaizen week. It is whether or not you can sustain the rhythm of improvement thereafter.

Just some things to think about.

May 4, 2013January 9, 2019

PDCA, A3 and Practical Problem Solving

Over the years, I have been party to at least three corporate-level efforts to bring “A3” or “Practical Problem Solving” into their toolbox. Sometimes it has other names, such as “Management by Fact” or such, but the approaches are all similar.

Typically these efforts, if they catch on at all, become exercises in filling out a form.

Actually, that shouldn’t be a surprise, because they are often taught that way – as process of filling in boxes in sequence, with a “module” for teaching each step.

Worse, it is often taught as an intellectual exercise, and once you are done with the three day class, you’ve been “taught.”

The various classes mention PDCA as being a crucial part of this process, but nobody really practices it.

People are sometimes taught that this process should be coached, but the “coaching” they get is typically organized as management reviews via PowerPoint.

The “problem solving team” shows their analysis and their “implementation plan” that is a list of tasks, and a timeline to get them done. The meetings become status reviews.

Sometimes the “coaches” offer suggestions and speculation about the problem, symptoms, or actions that might be taken. They rarely (if ever) get into the quality of the PDCA thinking.

This is one of the challenges we have in the west (and especially in the USA) where our culture is more one of “go it alone then get approval” rather than true teamwork with the boss. This often turns the “A3” into an exercise of getting approval for a proposal rather than a learning process.

Worse, it does nothing to teach the problem solvers to be better problem solvers.

Note that sometimes an A3 is used for a proposal, but the process of creating it is still coached, and part of the process is the consensus-building that happens before there is any meeting. But here in the west, we still seem to like to spring these things on a leadership team without a lot of that background work ahead of time.

Mike Rother and the “Toyota Kata” community have been discussing this gap lately, and working to close it.

The latest iteration is this SlideShare that Rother sent around today:

Practicing PDCA from Mike Rother

He clearly points out what people have been missing: The “A3” is really just another method to document the “improvement kata.”

The “Implementation” box, rather than representing an action item lists, is where the problem solver captures her PDCA cycles, what is being tried, what is being learned, as she drives toward the target condition.

The other boxes are capturing her understanding of the current condition, the target condition, and the impact of various problems and obstacles in the way of closing the gap.

One thing that makes this extraordinarily difficult: We are talking about more than the mechanics of problem solving here. We are talking about shifting the default, habitual structure of the interaction between people. That is culture, which is notoriously hard to change. Not impossible, but unless people are up front that they are actually trying to change at this level, there are a lot of obstacles in the way. This can’t be delegated.

May 2, 2013January 9, 2019

Rapid PDCA

This sub-assembly line had a planned cycle time of 15 minutes. The most skilled and experienced assembler could almost get all of the work done in that time, but generally, two people were required to consistently deliver without stopping the main line.

Among other obstacles identified, the first assembly step was being done on a bench. This required the assembler to stabilize the main part with one hand, position the part being installed with another hand, and hold the tool with… you get the idea.

The idea was to design and build a jig that would hold the main part steady, in the right orientation, at a good working height.

Iteration 1: Mock up the concept.

Rodney (the lean manager) and Maegan (the line team leader) are showing their first iteration of concept.

But even before this, their real first experiment was to hold the part by hand and test where it needed to be stabilized. The cardboard mock-up was a confirmation.

Iteration 2:

They experimented with contact points and hold points and made a few adjustments…

Iteration 3: Have a more robust version made out of wood, try it with an actual part.

Learned: The part isn’t stable enough to work on.

Next experiment: Add a clamp, and mount it to a tool stand.

Then Maegan tries it out.

What did we learn?

It is difficult to get the tools behind the clamp bar.

Iteration 4:

Add some wood shims to raise the part and see if that works better.

Expected result: Should be easier to get the tool in there. Now try it.

But we learned we need a better backstop for the clamp.

Iteration 5

Which seems to have done the trick.

This, plus a couple of other changes, got the cycle time under the 15 minutes, so one person could do this job.

All of this happened over less than a couple of hours. A far cry from the traditional tooling and jig design process.

Follow-Up:

This is the final version. As you can see, there is now a wedge under the clamp to change the angle + some additional clamps that allowed the tool to also be used for another subsequent operation.

May 1, 2013January 9, 2019

Results

Past Due Hours

This area was picked for the initial focus because they were way, way behind, and it was getting worse.

The initial work was done in mid-April. The target was consistent output at takt time.

As the team looked at the process, and identified the sources of disruption and variation, “changeovers” surfaced pretty quickly as a main issue.

“Which obstacle are you addressing now?” was the changeover times on the output process, so the target condition for the area’s team was to get the disruption to output for a change over down to a single takt time vs. the highly variable (up to 10 takt times or more) disruptions they were seeing.

One big mindset change was the concept of takt time. There was a lot of perceived variation in the run times of these parts. But upon study, the team realized the variation was a lot less than they thought. Yes, it is there, but over any given couple of hours, it all evens out most of the time.

As the team studied their changeovers, one of them had an insight that “We can do a lot of these things before we shut the machine down.” And in that moment, the team invented the SMED methodology of dividing “internal” and “external” changeover tasks.

Once that objective was grasped, they went to town, and saw lots of opportunities for getting most of the setup done while the last part was still running.

Their lot sizes were already quite small, the core issue here was the disruption of output caused by the increased tempo of changeovers. So that time was put back into capacity, resulting in the results you see above.

They continue to work on their changeover times, have steadily reduced the WIP between process stages, and (as you can see) keep outrunning their goals for “past due hours.”

But the really important bit here is that this was largely the team leaders, the supervisor, and the area manager. Yes, there was technical advice and some direction giving by the VP and the Continuous Improvement manager, but the heavy lifting was done by the people who do the work every day.

Consistent Output

This is from another company, in a completely different industry. Their issue, too, was that they were always behind. In this industry, the idea of a takt time is pretty alien. Even the idea of striving for a fixed level of output every day is pretty alien.

The team’s initial focus was maintenance time. They perceived that equipment reliability was causing them to fall behind in production, and so were shipping product to a sister plant every week to fill in the gaps.

The first question posed to them was “How much time is needed for production?”

In other words, they needed to figure out how much production time was “enough,” so they could then assess how much time maintenance could have. That would establish their target.

But in answering that question, they developed a takt time, then measured output cycles vs. that takt. What they saw was lots of inconsistency in the way the work was being done.

If they could hold to something close to their demonstrated lowest-repeatable cycle times, they could then know when they were “done” for a given shift, or day, and actually plan on maintenance time rather than seeing it as a disruption to production.

The focus shifted to the work cycles.

What is cool about this team is that the team leader / “learner” (in Toyota Kata terms) was the maintenance manager.

He gained a real shift in perspective. “Production” were no longer the people who wouldn’t let him maintain the machine, they were his customers, to whom maintenance needs to deliver a specified, targeted, level of availability as first priority.

The teamwork developed about the end of Day 2 of this intense learning week, and they have been going after “sources of variation” ever since.

Here is the result in terms of “daily output:”

As you can see, not only is the moving average increasing, but the range is tightening up as they continue to work on sources of variation.

The big downward spike on the right is two days of unplanned downtime. In retrospect, they learned two things from that.

After foundering a bit, they applied the same PDCA discipline to their troubleshooting, and got to the issue pretty quickly. As a sub-bullet here, “What changed?” was a core question, and it turned out someone had known “what had changed” but hadn’t been consulted early on. Lesson learned – go to the actual place, talk to EVERYONE who is involved rather than relying on assumptions.
Though they sent product out for processing, they realized they could have waited out the problem and caught up very quickly (with no customer impact) had they had more faith in their new process.

All pretty cool stuff.

These things are why this work is fun.

November 8, 2012January 9, 2019

Finding Patterns

“What is your target condition?”

“One-by-one flow, meeting an 11 minute planned cycle time, with two people.”

“What is your current condition now?”

“We are making rate, but our lowest repeatable times add up to 28 minutes, and with that and the 32% variation we are seeing, we need 3 people on the line to do it consistently.”

“Where is all of that variation coming from? What are people struggling with?”

“All of the assemblies are different!”

And this was kind of true. We had five different larger assemblies firing in a repeating cycle:

A, B, C, A, D, E, A, B, C, A, D, E

And to make the discussion more interesting, each of these items has four sub-assemblies, of different types, that go into it. This line was building those sub-assemblies in a sequence that matched the need. So it is easy to see why all of that variation seemed overwhelming.

But there was commonality, a lot of it. The operations were very similar, with the differences being things like:

A left-hand or right-hand difference.
An operation is included, or excluded from a particular sub-assembly.
Differences in geometry that had little or no bearing on the actual operations being conducted.

My goal was to lead them to doing more detailed observations, seeing the blind assembly operations, chaotic layout on the bench, the occasional hunt for information, and at this point, the learning curve the assemblers are still coming down as we identify key points.

We are hard-wired to see differences in things – that blade of grass is bent, is there a tiger there? Sometimes it is more challenging to seek out and become aware of the underlying patterns. In other words, what these items have in common.

Rather than looking at obstacles to build the parts, we want to look at the obstacles to smoothly carrying out the operations. It is a subtle difference, but an important one. Sometimes you have to search through the noise to find the signal.

As of this writing, the bench is getting better organized, tools are getting homes, and some assembly aids and tools are being developed to avoid having large fingers trying to get things done in small places.

The work is starting to stabilize enough that the patterns are becoming more visible, which allows capturing the work breakdown in a rational way that can be taught – first the base industrial skills, then the common operations, then the sequence of those operations for specific parts.

We’ll get there.

October 20, 2012January 9, 2019

Some PDCA Cycles

We had five sequential operations. Although the lowest repeatable times for each were well within the planned / target cycle time, there was a lot of variation.

Though Operation 3 was working pretty continuously, Operations 4 and 5 (downstream) were getting starved on occasion, and the empty “bubble” was working its way to the output. The exit cycles, therefore, were irregular enough that they weren’t making rate.

The team set their target to stabilize Operation 3, with the expectation that doing so would smooth out the overall exit cycles.

To that end, they went back and started to study Operation 3 in a little more detail to better understand the obstacles that were impacting the Team Member’s ability to complete the work smoothly.

Then a wrinkle – a different team member was now doing the work, and his cycles were faster.

This actually was an opportunity. Why is one Team Member faster than another?

Their hypothesis was that the faster Team Member had some knack or technique, that enabled him to perform more consistently. And indeed, he did have a few tricks.

So the first experiment was to capture this work cycle in a Job Breakdown, then see if using Job Instruction and teaching it to the first Team Member they could duplicate the results of the second.

Then another wrinkle. The first team member was back on the job. Armed with the knowledge gained by breaking down the steps, key points and reasons for Team Member #2, they took more baseline data from Team Member #1 to set up their experiment.

…only to discover that Team Member #1 was also doing things that #2 didn’t do.

One of those things was unbending a part that was sometimes being bent by an upstream operation.

It seems that #2 was just passing those along as he got them. With that background, the conversation went something like this:

“What obstacle are you addressing?”

“The manual rework in Operation 3 is adding variation and extending his cycles.”

“What experiment are you running next?”

“We think the jig being used in Operation 1 is a bit undersize, allowing the part to deform. We are going to adjust the jig to the proper size.”

“What do you expect from that?”

“We expect to eliminate bent and deflected parts, and see more consistency in Operation #3’s cycles.”

Then they tried it. Skipping ahead a bit:

“What actually happened?”

“The parts are now more consistent, and there Operation #3 has a lot less variation, and is running closer to the planned cycle time… except that now he is waiting on parts from the upstream operation.”

“Huh. What is happening there? What did you just learn?”

“Well, it looks like Operation #3’s variation was masking inconsistent delivery from Operation #2. That team member is operating in small batches, then turning and delivering 3-5 parts at a time. When there was a lot of variation in Op #3, those parts were kind of buffering everything. Now he is working more consistently and faster, and ends up waiting on parts.”

“Because of the layout, the Operation #2 Team Member has to turn to his left and pass the parts behind him. He said he batches so he doesn’t have to turn so often. So what we are thinking is we want to…”

“Hang on, I want to stick to the structure so you guys can practice hearing and responding to it… So – what is your next step?”

“We talked to the team members, and they all agree that if we straighten out that bend in the layout, this will be a lot easier on them, so we are going to do that during the lunch break.”

“And what do you expect from that?”

“Operation #3 will get his parts one-by-one, as they are ready, and won’t have to wait on them.

“Great, so when can we see what you have learned?”

“Give us about 30 minutes after lunch break is over.”

You can probably surmise that things smoothed out a bit.

Then they went back to capturing a hybrid of the best practices of both operators in a job breakdown. At this point, the Team Members were genuinely interested in how they were doing, and both were quite open to learning the “tricks” of the other, so “Get the worker interested in learning the job” had pretty much been done.

A lot was learned over a few hours.

Reflection:

The “real world” is often quite a bit messier than the real world. There was actually a lot more dialog than I reconstructed here to keep the “learners” on track and focused on their stated target vs. resorting to an action of “improvements.”

In addition, merely beginning to work on one obstacle revealed enough information that they were dealing with a different underlying problem.

At another point in the week, they also believed they saw a need for more consistent part presentation. I happened to agree with them, but…

when pressed for what result they expected, the initial response was “The parts will be consistently presented.”… but what does that have to do with your target?

That was tough because, at the time, they were looking at the cycles of the 2nd operator that were, actually, pretty consistent, and lost sight of the fact that they were working on reducing the overall variation of output from that position.

They had a very hard time articulating why consistent part presentation would address the issue, even though they knew it should.

I think this is the result of years of conditioning that the “tools” – such as consistent part presentation – are good for their own sake, without really examining the underlying problems and causes that are being addressed.

If we lean practitioners are scratching our heads wondering why people don’t see this stuff helps, it would be a lot easier to deal with if we could point to the issue being addressed at the moment.

More tomorrow.

October 10, 2012January 9, 2019

One-by-one, As Requested, When Requested

The world continues to move toward meeting customer’s true demand of one of something, when they want it, where they want it.

3D printing is one area where we can see the beginnings of a disruptive technology curve.

Laser printing has been around even longer.

Books are an area where the traditional mass-printing model is under assault from a number of directions.

Now On Demand Books is offering their Espresso Book Machine, fully automated production technology for a copy of a traditional paperback book. Check out the video.

Yes, the costs are higher for now, but in a niche market (which is where disruptive technology matures), that is less of an issue.

The trend is inevitable – it isn’t how fast you can go, it is how slow can you go while preserving the economy of scale. That is the challenge.

August 9, 2012January 9, 2019

Good Leads Are Critical

When we did the first “Toyota Kata” based kaizen event here a second shift lead came up and told me “I’ve been working here 34 years and this week I learned what my job is.”

In most companies leads are expediters charged with forcing product out of the process when the system breaks down.

As we have introduced better flow into this process, things generally work better for overall output, but obstacles still occur.

The leads now assume a critical role for daily kaizen. They are the nerve endings for the entire production process. They are the ones who see the issues when they are small.

We are working with them this week to develop their skills to see, and capture those issues – the rough spots where the production team members struggle a bit to get things working; or where the team needs to bypass the intended process flow to make things work.

By helping them see the difference between smooth flow and rough flow, we are increasing the sensitivity of those nerve endings, and starting to flush out more sources of unplanned variation in a process with a fair amount of part and cycle variation.

At the same time, we are working with the core shop floor leadership team running then through PDCA cycles to develop their skills for improving flow.

What is kinda cool is that it is working, and the linguistic patterns (which reflect thought patterns) are shifting.

June 6, 2012January 9, 2019

Organize, Standardize, Stabilize, Optimize

As I work in the field, I continue to encounter a desire to get right to optimal results – “Why aren’t we working to eliminate all of the waste?”

Once people start seeing opportunities, there is a great temptation to try to simply engineer a new process and implement it. This is especially true in value stream mapping processes. The future state map seems like an engineering specification – just make it look like this, and all of these issues will go away.

The “kaizen bursts” are supposed to represent the obstacles in the way, but they often show up as “action items” instead as people are tempted to make this into a project.

But the messy reality in the actual workplace (gemba) requires a far more methodical approach.

The title of this post is from four steps that a consultant friend shared with me years ago. As I converge my own practice toward guiding people through implementing the daily improvement culture vs. implementing the tools, I am finding these words a handy mantra. This is how I have found myself explaining it lately:

Organize includes all steps required to make the current condition apparent. This can include 5S activity, but is by no means limited to that.

You want to know enough about what is going on that you can tell the normal, intended, pattern from one which has been disrupted by an obstacle or issue.

In other words, you know how the process should operate if people don’t encounter any serious issues.

This allows you to standardize.

This is not a standard in terms of something you are trying to enforce.

Rather, it is a standard that you are striving to achieve each and every time the process is run.

“Did we make takt time with this work cycle?”

“Did this changeover go the way we intended?”

“Did we make a good part this time?”

(for Brian): “Did we get the quote out in two days?”

Once you know how the process is supposed to work, and what results you are supposed to get, you can clearly identify those times when it doesn’t work that way, or the results are not what you wanted.

Stabilize: Now you can begin marching up the PDCA ramp toward the standard as you work to stabilize the process by systematically eliminating the issues.

Of course, for this to actually work, you must have a process to flag problems right away, pounce on them, clear them, and then feed them into a follow-on process that works to solve them.

As you apply countermeasures to sources of instability, you are adjusting the standard itself to include those countermeasures, making it more robust.

So Stabilize and Standardize play off one another in successive PDCA cycles.

Now… here is the trick part. “Optimize” can be indistinguishable from “Stabilize.” It is more of a semantics issue than anything else, and honestly, it isn’t worth arguing about.

Why?

Because as a process becomes stable, you are going to keep driving toward perfection, True North. You are going to have intermediate-term goals you are trying to reach that keep you moving forward. You are optimizing as long as you are moving in the right direction. So there isn’t really a distinctive point of shifting gears, there is only the most important issue to address right now to hit the next target condition.

May 8, 2012January 9, 2019

Struggling to Learn

One of the challenges of teaching and consulting is resisting the temptation to give people the answers. Honestly, I like giving people the answers. It feels genuinely helpful, and it provides a nice ego boost.

But according to this article on Time’s “Time Ideas” site by Anne Murphy Paul titled “Why Floundering is Good,” that isn’t the best way to teach.

In fact, it can hinder learning.

The key point is summarized at the end:

… we need to “design [teaching] for productive failure” by building it into the learning process. Kapur has identified three conditions that promote this kind of beneficial struggle. First, choose problems to work on that “challenge but do not frustrate.” Second, provide learners with opportunities to explain and elaborate on what they’re doing. Third, give learners the chance to compare and contrast good and bad solutions to the problems.

Right now we are (hopefully) in the midst of a paradigm shift in how lean practitioners and teachers go about what we do.

Traditionally, a lot of us have simply given people the answers, or at least strong suggestions. Given the time constraints and overly ambitious targets of a typical 5 day event, that is understandable.

But now we are starting to see these events as skill building, which means learning, which means the teams need time to muddle through.

I have been structuring my approach quite differently for about a year now. I’ll be the first to admit that I, too, am figuring it out, reinforcing what works well, altering what needs to work better. These days I am far more comfortable letting things move through this struggle in order to set up deeper understanding once the light does come on.

The trick is to let them fail small, and not let them fail big. The problem has to have a solution that is within reach, or they will only come away frustrated.

Thus, teaching is becoming a matter of judging the knowledge and skill threshold and making sure they don’t take on too much at once. That is part of respect for people.

One problem at a time. Single factor experiments.

A great deal of the power in the “Coaching Kata” is turning out to be the question “Which *one* [obstacle] are you addressing now?” as it rules out working on everything at once.