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.

Write it Down

Recently, a team was trying to understand a seeming anomalous message (or lack of one, actually) in their complex computer transaction system. (Complex Computer Transaction System is abbreviated “E.R.P.”)

They discussed possible causes, settled in the likely culprit, constructed an experiment to try to replicate the issue and… everything worked perfectly. Meaning that the cause they were testing wasn’t the cause at all.

They worked to reconstruct the timeline from initial data entry to the point where the message should have been issued, and did a better job looking at what along the way could have suppressed the message.

After a series of trials, they found the culprit. It had originated in a data entry omission in a sister plant. They were able to turn the problem on and off at will with that one field.

They had actually discussed this possibility in their original discussion. But they had talked past it, and ended up focusing elsewhere.

There was a great learning here.

If you are discussing possible causes to a problem, write them down. All of them.

Get methodical. Be certain what evidence you either have in hand, or need to get, to eliminate a potential suspect from the list.

It feels slower, but it works better than faster approaches that don’t work.

Problem Solving Modes

I want to tack a similar issue onto yesterday’s post about normal operating mode vs. recovery mode.

Listening to a team trying to understand a complex issue, I noticed three different threads intertwining in their conversation.

  1. They would discuss the actions needed to work through the issue and get the product to the customer. This is appropriate and necessary, but not in a meeting to discuss cause and countermeasure of the issue itself. This topic is habitual because it is the mode the group normally operates in. They are working to change that, but until they do, they’ll have to do what is necessary to meet the requirement… just not in this meeting.
  2. They would discuss the actions required to understand the next level of the cause – the investigation itself.
  3. They would discuss possible preventive countermeasures.

We’ve already said #1 should be taken off line. As you listen to the conversation in your problem-solving meetings, watch for this one because it can be very distracting as it is often confused with finding the cause.

#3 – discussing possible preventive countermeasures – often takes place before the root cause is understood. Though it is certainly appropriate to discuss (and experiment with) preventive countermeasures once the root cause it known, it is simply an exercise in idle speculation to do so before that.

In fact, doing so can be dangerous. You could put in a “countermeasure,” followed by an intermittent problem “going away” or the symptoms disappearing for a random reason, and end up with a powerful superstitious belief that you HAVE to operate that particular screen with the mouse in your left hand, or it won’t work.

The best course of action is to follow a methodical series of experiments to rule out possible causes.

This is harder than it looks. This week a team had an epiphany when they discovered that an unlikely cause they had talked themselves out of early on turned out to be the actual issue. The lesson they learned was don’t eliminate a possible cause without hard evidence. The more certain you are, the more you need to get that evidence.

Ask yourself “What would I have to prove to eliminate this as a possible factor?”

Just some thoughts for the day.

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.

One-By-One; On Demand; As Requested

Once again we see another data point on the trend.

Why is “batching more efficient?”

Simple – you haven’t solved the problems yet.

Here is an ice cream shop that has no ice cream… until you order it.

Does this shop surface the next layer of issues to solve? Certainly. But by thinking it is possible and they trying it, she is learning fast.

Version 12.0 of the Toyota Kata Handbook

As of about 12:30 Pacific 11/4 there have been a couple of revisions, so be sure to download the latest.

Mike Rother has released Version 12.0 of the Toyota Kata handbook on his website.

The handbook, over the last few iterations, has become much more pragmatic (and practical).

The information about the coaching process is greatly improved. I’d say it backs up my own experience and learning pretty well.

As Requested; When Requested; Where Requested

Amazon.com’s competitive advantage over regular retail has typically been around good prices with the thing you are looking for being available. In essence, they are an online, extreme extension of the big box store.

The downside has been that if you want it now, you have to either pay extra for expedited shipping, or get it somewhere else.

Meanwhile, retailers have been attacking Amazon’s price advantage by working hard to put them in a position where they have to collect local sales taxes, leading to a number of court cases plus Amazon actually pulling their presence OUT of states to avoid having economic nexus.

Now Amazon has reversed this trend, and is starting to build very local distribution centers, promising, not next day delivery, but same day delivery – as in order it today, get it today.

The analysts out there are all saying this is the “death of retail” – assuming, I suppose, that although Amazon can change its strategy, brick-and-mortar retailers are, somehow, frozen in theirs. “Death of retail” really means “We analysts, while certainly not admitting we never saw this coming, can’t think of how we would respond.”

Ultimately someone will figure it out.

But I digress.

The point is this:

Short lead times AND high variety of offering AND good prices are what customers want, and that is what anyone in the business of fulfilling customer needs should be striving for.

The ultimate transaction is “I’d like one of these.” followed by “Here you go.”

Just because you can’t figure it out doesn’t mean others aren’t trying to.

Where does this ultimately lead?

This video speculates what would will happen when Amazon figures out how to deliver what you order the day before you order it. Enjoy. Smile

 

Simple Solution to Complex Problem

This video captures a crucial aspect of lean thinking – searching for the simple and elegant solution.

We can’t say this is an obvious idea, a lot of very smart people have been working on this problem for decades.

But it is a simple idea. Sometimes the search needs to be outside of the regular domain people are used to working in.

The web site is here:http://creativemachines.cornell.edu/jamming_gripper

The other aspect of lean thinking that is captured here is keep working to solve the problem. I run into so many technical people today who are so convinced that the problem is unsolvable with current technology that they either give up, or look to advance the state of the art in some (usually expensive) way.

One thing I am glad to see is a trend in engineering schools toward making things rather than just designing them.