Toyota Kata “A3 Problem Solving”

Over the years, I’ve been exposed a number of efforts to “implement A3 problem solving” in various companies. I worked for some of those companies, I’ve observed others.

The results are nearly always the same.

Here are a couple of examples. Let me know if any of these match up with experiences you have had.

Example 1: The company had put many people through “Practical Problem Solving” training and was (ironically) trying to measure how many problem solving efforts were underway.

I was watching a presentation by one of these problem solving teams to management. Their A3 was on a computer, projected onto the screen. They were reporting their “results.” Yet there were large discontinuities in their problem solving flow. The actions they were taking simply did not link back (through any kind of identifiable cause) to the problem they were solving.

The management team listened carefully, applauded their efforts, and moved on to the next topic of their meeting.

Example 2: A different company had a form to fill out called an “MBF” or “Management by Fact.” From the labels on the boxes, it was clearly intended to be structured problem solving. By the time I worked there, however, “MBF” had become a verb. It was a solo activity, filling out the form at the desk, and reporting on it in a staff meeting.

Example 3: Well-meaning former Toyota team members, now working for a different large company wanted to “train everyone in problem solving.” They put together a “class” that presented the purpose of each block on their A3 form with the expectation that people would adopt the process.

All of these efforts had something in common.

They didn’t work.

Over the last few days, I’ve been privileged to be included in an email exchange about the relationship between A3 and Mike Rother’s Toyota Kata. My small contribution was apparently enough to get my name onto the cover, but I want to give a real nod in the direction of a Jenny Snow-Boscolo for instigating inspiring a really good exchange.

The result is here. I think this presentation does a really good job of summing up the relationship between Toyota Kata and Toyota A3. Thanks to Mike Rother for taking the initiative and putting it all together (more below)

One of the difficulties with gaining insight into Toyota’s management processes is that they really aren’t codified. This shouldn’t be a surprise. Look at your own company, and ask how much of the culture – the reflexive way things are done and interactions are structured – is written down.

(In fact, if it is written down, I would contend it is likely your actual culture has little resemblance to what is written about it. Those things tend to be more about what they wish the culture was.)

Culture, any culture, is learned through daily interaction. This is all well and good in cases where people are immersed in it from the beginning.

But the rest of us aren’t operating in that problem solving culture. Rather, we are trying to create it. And as the former Toyota Team Members from Example 3 (above) learned, it isn’t a simple matter of showing people.

Rather than two different things, we are looking at a continuum here. At one end is the culture described on Slide 9. There isn’t any formal structure to it, the process for teaching it isn’t codified. It is learned the same way you learn the way to get the job done in any company. They just learn different things than you did.

But in another organization there is no immersion. If there is anyone who is steeped in The Way, they are few and far between.

In these cases, we want to start with something more overt. And that is the purpose of having a rote drill or kata. It isn’t something you implement. It is a structure, or scaffold, to learn the basic moves. Just as mastering the musical scales is only a prelude to learning to play the instrument, the kata is the foundational structure for learning to apply the underlying thinking patterns.

So… if you are working on kata, it is critical that you are reflecting on your thinking patterns as much (or more) than you are reflecting on your improvements. It might seem rote and even busywork at first. But it is there to build a foundation.

Standards: Notes On A Whiteboard

image

I saw this on a client’s whiteboard this morning. (Actually I saw it a while ago, but just took the photo.)

By having a clear expectation about what is supposed to happen, they can work to converge the process toward some kind of consistency. The opposite is just accepting whatever happens as OK.

By having a degree of stability, it is easier to see issues and opportunities, that in turn, allow them to set the next level of standard.

He put it up there to remind him when he is distracted in the day-to-day fray that “What are we trying to achieve?” is the important first question to ask.

Remember, there is no dogma. Your choice of words and definitions may vary. But these work for him.

Curiosity

The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.

To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.

Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?

Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.

To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.

Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.

Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”

You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?

That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.

“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?

All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.

Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.

I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.

But if not them, who? And how do they know it is getting done?

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.

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:

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.

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.

01 Cardboard Concept

02 Cardboard Concept

 

Iteration 2:

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

03 Adjust Cardboard

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

03 Wood #1

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

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

04 Wood on stand

Then Maegan tries it out.

2012-12-06_13-04-56_819

What did we learn?

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

2012-12-06_13-07-39_802

Iteration 4:

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

image

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

image

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

Iteration 5

2012-12-06_13-29-46_964

2012-12-06_14-02-43_995

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.

image

image

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.

hours-past-due-sm

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:”

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.

  1. 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.
  2. 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.

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.

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.

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.