When should we do an A3 or use a different problem-solving tool?
Dear Gemba Coach,
I would really appreciate your perspective on the following: (1) When should we do an A3 for something vs. when would it be appropriate to just use an idea board? (2) What is the difference between a problem and an idea?
I remember a while back endless debates about whether Toyota was abandoning pull because rather than using parts bins along the lines for operators to pick items, some plants were moving to kitting – preparing kits of parts for assembly. Then some lines weren’t. Then some were doing half-and-half.
Then Toyota’s French plant started running three shifts instead of the usual two (with maintenance done during the night shift), so Toyota was abandoning its TPM model. Then the plant went to 2 shifts. Then back to three shifts. Other Toyota plants still run on two, to my knowledge.
Yesterday a journalist asked me whether Toyota was abandoning kaizen because its head of a research institute in California said that kaizen wouldn’t cut it for disruptive innovation. Last time I visited Toyota plants, quality and flexibility targets were still as demanding as ever, and many of the tricks that helped operators achieve them could never have been thought up by engineers – only through kaizen.
Truth is in the eye of the beholder. These “is this lean or is this not” debates all hinge around our own fixation with solutions. We’re endlessly looking for good ideas that we can pinch and apply. We would call it a “best practice,” and try to apply it.
Lean thinking looks at this upside down. Lean thinking is about deeply understanding the problem and then explaining the local solution in its context.
For instance, if we go back to the lineside bins versus kitting problem, the question is one of variety’s impact on physical and mental ergonomic burdens for the team member. When variety increases because the line is more flexible and more products follow each other on the line, the operator now must both (1) pick the right parts for the right product and (2) handle some complex arrangement of parts. This creates the double burden of making the right picking decisions and then walking to and from the parts point of delivery.
If the problem is easing the team member’s mental burden by taking away parts choices, kitting is a good idea. The same with heavy or unwieldy part. On the other hand, if the problem is greater fluidity and flexibility of the parts flow to assembly, having shelves of small containers is the right idea. And then it all must fit within the station and a short walking distance so team members aren’t walking around without need.
Which all depends on the car’s design and process set-up. There is no one solution. These are ideas in a given context.
When an A3 Is Justified
Ideas, in lean, are usually the result of someone or a team solving a complex trade-off in a given context. This is also why having an idea that is not picked up by your team or your management doesn’t make you wrong, or doesn’t mean it was a bad idea. The team or management chose to solve the trade-off differently, but the idea remains valid – and might be taken up next time a similar problem arises.
Lean’s upside-down thinking is about understanding problems in-depth and then trying ideas as they come to see whether they work or not, and then looking for the next idea. The flow of ideas (the ultimate source of productivity for the company) depends on how deeply we understand the problem and how committed we are to solve it, every day – because really tricky problems rarely simply go away.
Having had an idea, and having shaped it into a workable solution, you now have a second problem: you’re not alone in the organization and colleagues from other functions need to understand what you have in mind.
If the idea only concerns the team, it still needs to be explained to every other team member, as well as members from other shifts, but it can well stay on a local idea or kaizen board. If the idea has implications beyond the team, it can be presented as a QC story. Here’s a great example from Art Smalley and Durward Sobek: http://a3thinking.com/blog/?p=42
Once a problem has been solved, the issue is to make sure that (1) everyone concerned understands the thinking that led to the solution so that (2) everyone understands the parameters of the solution – its scope, where it will work, and where it won’t.
If we return to the kitting issue, I remember when line activities at a Toyota forklift plant led it to start kitting. This immediately created a problem of flow for flexibility in logistics. Logistics then came up with a delivery train solution that moved smaller trolleys with kits within an awkward looking contraption that could handle both kitting and flow requirements. This local solution could only come together as a joint effort between line management and logistics.
Which brings us to A3s.
One obvious answer is there are easy problems (just look harder, ask why, and solve it). Then there are harder problems, which require more structured thinking and might warrant an A3.
But we often completely miss yet another dimension of management. In today’s age, management is mostly about maintaining the processes and rituals of the company. But in earlier times of management theory, when “management” was still figuring out itself, people understood more clearly that management’s main role was not just having meetings and reporting and controlling, but also coordinating.
At some point, people across functions need to understand what each other does to figure out whether they help or hinder new solutions being applied: are they part of the solution, or part of the problem.
Lean companies attack this issue with formal interface presentations. Amazon uses APIs at a management level (present the parameters of your solution to the other functions so they can interface with it). Toyota uses A3s.
For instance, here’s an A3 I saw at Toyota.
Yes, without doubt, the A3 structure is useful to help the person conducting the problem-solving structure their thoughts.
But most importantly, the A3 helps explain (1) how this person understands the problem, (2) what other solutions were envisaged, (3) why this specific solution was picked, and (4) where it might be interesting to look at somewhere else (or what else needs to be solved to make the solution stick.
A3s are essential for management to communicate across functions and build more robust teamwork so that the company performs better together.
Here is another picture from Toyota Boshoku in Brazil where A3s are displayed in an obeya so that all functions can figure out what each is doing.
Don’t Just Solve Problems
Lean thinking very clearly hinges on three core intents: (1) improving customer satisfaction by (2) continuously improving how we work from (3) all people all the time developing their understanding of their jobs (and each other’s jobs). In this light, one person’s problem-solving skills are only one part of the problem. The second part is teaching this person to navigate the organization and deal with his or her colleagues, or stakeholders outside of the organization to make countermeasures work.
Mastery over one’s job is not simply getting better at solving problems. It’s also getting better at having one’s solutions adopted by the organization, which means becoming more convincing and being more flexible in terms of finding countermeasures that also work for others. In this, the A3 is an invaluable tool because it allows one to present one’s deep thinking in a way that should be understood at one glance (okay, read in one minute) and where others can see how this countermeasure (or proposal in some cases) fits within their own issues and improvements.
In short, yes, A3s are reserved for harder problems (as opposed to go back, look harder, ask why), but they are also mainly used for problems that need to be shared across the board. Management’s real value added is not just to run things and solve problems, but to interface across functions by better defining these interface points. A3s are the core interface tool.
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?