Posts

Posted on

Just a Few Seconds

What is a few seconds of delay? Why is it such a big deal?

Consider this example.

While touring the Pilsner Urquell brewery in (surprise!) Pilsen, Czech Republic, we saw a lot of really good information boards, general organization, and a clear management commitment to continuous improvement.

Their packaging plant produces 60,000 bottles of beer an hour. Even though they produce “bottles of beer” this is more of a process industry than a discrete product industry. Most of the operations are highly automated with human supervision, rather than human operated. So do the principles of “lean” apply?

Partly, it depends on your definition of “lean.” If you subscribe to the most common partial definition, where “lean” is a set of tools, then most people would struggle finding relevance to the context. On the other hand, if you look at this as a structure for the work, the work place, and the organization to drive out and solve problems – then you are in comfortable territory here.

While those machines are largely automated, they do occasionally have problems.

Those problems can be seen as a disruption or slowing of production. But in a large complex operation, many times these things are subtle and hard to pick up.

If you are running a process industry, consider these questions.

What is your nominal, expected rate of throughput at each and every critical juncture in the plant?

How do you know you are achieving that rate?

What is the threshold of slowing or disruption that will get your attention?

Remember, we want to look at “chatter as signal” here. While failure is a common condition, it is not a condition we ignore.

conveyer

This conveyer is coming out of the carton machine. Bottles go in. Flat cartons go in. Glue pellets go in. Cartons of beer come out, at a pretty good clip.

While we were there, though, a carton was mangled. As it got just downstream of this spot, the line was stopped. I don’t know if it was an automatic or a manual stop – I would hope it was automatic.

A couple of team members pulled the carton out, and re-started the line.

The line was stopped for 32 seconds.

Count how many cartons of beer go by in 32 seconds. Subtract that from the day’s production. It isn’t one mangled carton, it is almost 60 cartons of beer that will not be made today.

Sitting next to our mangled carton was another one, presumably from earlier in the shift.

120 cartons.

“Stop and respond to every deviation.”

Why did the line stop? Because the carton was mangled. Good call.

Why was the carton mangled?

Again – this is an operation bordering on world class, but I don’t know what goes on behind the scenes. They could be doing everything I mention here. So please look at this as an opportunity for a hypothetical example.

This is the kind of problem that executives often decide is not worth solving. It is, in the grand scheme of profit and loss, floor sweepings.

Hopefully that is not the case at Pilsner Urquell. I honestly don’t know. But what I do know is I can estimate that a couple of pallets of beer never get made each day as long as this problem persists. If a thief stole two pallets of beer from the warehouse every day, security would be all over it.

In a “lean” operation, though, we pay attention to these things. Just a few seconds matter. Why? Because those few seconds are what stand between the current condition and a target of more production with no more capital equipment.

In a process industry, that equipment costs big, big bucks. So now we are talking, not about a case of beer, not even about a little problem, but rather the fact that if there is a systematic approach to dealing with these little problems we might be saving many millions in future investments.

How reliable and consistent is the equipment and machinery in your operation?

Do you carry out regular maintenance checks? How do you know? Is there a way to verify that those checks were actually made – or at a minimum, verify that someone had to go to the place where they should be done? How do you know? It is one thing to have the pretty pictures in notebooks or on a board. It is another to have a physical check of some kind.

If you can verify those checks are being made, great. That is standard work. You have created a working hypothesis:

“If we carry out these checks, and this routine maintenance, at these times, in this way, then we will never be surprised by a stoppage.”

Of course you will be wrong. Unexpected slowdowns and stoppages are going to happen. But in our lean world, chatter is signal. Being wrong tells us something we didn’t know when we created those checks. That unexpected failure or breakdown had some kind of precursor that we might have prevented, and certainly should have seen. So we set up the process to immediately detect a slowdown or stoppage and let us know. We verify that the checks have been made, and then look at what we must change about them to cover the new insight we have.

Maybe this time we are only saving a few seconds. But it is really impossible to measure the effects of problems that do not occur.

If you are overrun by these problems, deal with the ones you can, maybe just a few every day, but deal with them in the right way, using thorough problem solving to the root cause. Be able to answer the question “What did we learn about our process here?” with something that you didn’t know previously.

Just a few seconds, but just as you save sixty seconds to save a minute, those seconds add up. At the very least, know what is happening out there. Go and see.

Posted on

Deciding vs. Discovering and Developing

In a recent blog post, Why C level executives don’t engage in ‘lean’…, Steven Spear makes a really interesting observation. He cites two main reasons.

1) “Lean” is regarded as a tool kit. There has already been a lot written here, and elsewhere, on this fallacy and how it continues to be propagated. Spear’s most interesting observation is his second point.

2) Business leaders are trained to make decisions. They are not trained to engage in discovery and development of the organization.

This really hit home for me. Synchronicity being what it is, last week in Prague this very topic was the subject of more than one conversation over a glass some glasses of Pilsner Urquell.

Spear sums it up here:

The thing is, business managers are not trained to learn/discover.  Rather they are trained to decide about transactions.  Consider the MBA curriculum core:

  • Finance–how to value transactions
  • Accounting–how to track transactions
  • Strategy–taught as a transactional discipline of entering or exiting markets based on relative strength and weakness.
  • OM courses–heavily pervaded by analytical tools (in support of decisions).

Largely absent: scientific method, experimentation, exploration, learning methods, teaching methods, etc.

Therefore, even for those who have seen TPS et al as management systems rooted in organizational learning and broad based, non stop, high velocity discovery are ill prepared to switch from decision mode to discovery.

Each of these two factors – regarding “lean” as a tool kit and being trained to make decision – would, alone, bias an executive toward “deciding to implement lean” and then delegating it to staff technical specialists. And when we say “management support” here in the USA, we often come from the same paradigm. While we feel that a decision to do it is nice, but not enough, we often have a tough time putting our finger on exactly what we want when we say “we need more management engagement.”

To make it worse, even if we have management engagement, they still don’t have the skill sets to actually engage the way they need to.

So we end up implementing the tools, and wondering why the leadership doesn’t grab the ball and run with it. The reason? Because they decided to give you (the technical practitioner) the ball.

What to do?

There is a great trend out there right now. All of this is starting to come together.

Taking the pieces that are out there and putting them together we have identified a problem, we have likely arrived at a couple of good causes, and we have a proposed countermeasure on the table.

If you have been reading along over the last few weeks, you know I have been reading (and like, a lot) Mike Rother’s book Toyota Kata. In his last chapters, Rother puts forth an approach that just might work for teaching leaders the skills that Spear points out they simply do not have. I found it affirming because I was starting to advocate, and follow, a similar approach. Toyota Kata will help a lot because it gives me not only a little more structure, but also some credible backing that I might not be nuts for thinking this.

Watch for a full review of Toyota Kata in the next week or so, but in the meantime, know that though I have some minor quibbles, I am going to advocate buying it, reading it, and doing what it says.

Posted on

Cenek Report: Litmus Test for Commitment

Robert Cenek offers up a succinct “check” for the level of a leader’s commitment to a change initiative on his blog.

The element that resonates with my own experience is the first on on his list: Intellectual curiosity. I cannot say enough how much core difference there is between a leadership team who says they “want to be lean” (or “world class” or any other buzz word) and a leadership team who digs in and does book studies, discussions, and generally works to learn about what they are supposed to do in the work environment they propose.

In the later case, they are acknowledging two critical things:

  • They must play a different role than they have been in the past.
  • They have to learn how to play that role.

Acknowledging that they have to learn how to play the role acknowledges, further, that they aren’t doing it today.

While this seems all touchy-feely, if it is done with the true intent to change, it is actually application of improvement methodology.

  • They are working to develop an understanding of the target condition.
  • They are working to understand the gap between their current behavior and that target.
  • They are working systematically to close that gap.

But I added the italics around “if it is done with the true intent to change” for a reason. I have also run into leaders who had a deep intellectual understanding of how the process works, but that understanding for some reason never translated into actions and directives that pulled the rest of the organization along. At a further extreme, resources are expended to make sure everyone in the organization is educated – sometimes extensively – yet nothing actually changes.

There is a commonly held misconception out there that education alone will precipitate change in the way people behave on a daily basis. Truthfully, it will cause that change, but traditional classroom education, and even participation in kaizen traditional kaizen events, is not going to do it.

Education, by itself, does nothing other than cause frustration as a few bright people “get it” and then see that it is business as usual as the “change initiative” fades into the background noise.

Changing a culture is about changing how small groups of people interact with one another. Getting this into place at the operational levels of the business was the topic of my talk in Prague yesterday. But at the leadership team level, they are usually left to their own devices, and have to make a conscious effort to take awkward and incompetent steps among themselves before they are any good at it. Without those first steps, there is no reflection, and without reflection there is no learning.

Posted on

Understanding the Solution

Another great insight from “Toyota Kata” by Mike Rother.

We often think great problem solving means solving the problem, that is applying countermeasures, and we may even propose and apply several countermeasures in the hope that one of them will stop the problem. In contrast, in Toyota’s way of thinking, if the solution is not obvious, it means we have not yet understood the situation sufficiently. Time to go and see again.

So here I am, in the beginning stages of trying to figure out how to get this problem solving culture anchored – not in a single site, but in about a dozen – spanning at least 16 time zones, with six or seven languages involved. I have to keep the message very focused, direct, and simple. I have spent the last couple of months in “go and see” mode.

One of the things I am beginning to emphasize to these management teams is that their problem solving is typically far to broad in scope. They are trying to find general solutions to broad ranges of problems, like part shortages. But “Why do we have part shortages” is the wrong question. Asking that question requires studying a huge population of part shortages, and quickly entering into “Pareto paralysis.”

Jamie’s comment to the Pareto Paralysis” post was a good one. Pareto charts are a powerful analysis tool, but in my view, they are best used when breaking down which cause to work on, rather than trying to break down which problem to work on. There is a huge difference.

What I see is that teams spend too much time time deciding what problem is most important, to the detriment of actually spending time solving problems. But I digress.

Rather than spend a lot of time breaking down “part shortages,” how about taking one part shortage. Instead of asking “Why do we have part shortages” I want to know “Why was that part late today.?”

Taking a look at a single instance, rather than a whole class of problems, does a couple of things.

First, it lets the management team do something that is critically important in these beginning stages: They learn to dig in and gain solid understanding of the situation of a single problem. They have to look at how the process was supposed to work, and understand when, where and why it broke down. Frankly, until they can explain that to me, in detail, I am not the least bit interested in proposed solutions. They first have to teach me well enough that I can understand what they understand.

Going back to the quote, at that point, if the system level solution is not obvious, then it is likely that I don’t yet understand the situation. That means that they have not yet understood it enough to explain it to me, which means they need to go back and dig some more.

The other thing, though, is that the way to learn good problem solving is to:

  1. Start with single instances, rather than classes of problems.
  2. Practice, practice, practice.

Why is it important for senior leaders to get good at this kind of problem solving? After all, aren’t they paid to manage others to do this? Yup, they are. But until they have mastered the game, they are not good coaches.

What I need is senior leaders who are going to insist on the same level of understanding from their people. Leaders need to understand what questions to ask, and how to re-focus people from “We have too many part shortages” to “Why was that part late today?” If each person can teach two more how to think that way, we’ll get there pretty fast.

Posted on

Where Is “Culture” Created?

The idea of a continuous improvement culture, a problem solving culture, a kaizen culture, has been with us for decades. Ultimately it is what everyone says they want to create. Yet creating that culture remains elusive for all but a few.

I have noticed that, generally, when people describe the culture they are trying to create they do so in terms of what people do.

  • Leaders support the changes.
  • Team members take initiative.
  • People “see waste and eliminate it.”
  • People engage in problem solving.
  • Team members are fully engaged in improving their own work.

All of these things are true, but they miss the mark.

They are all the actions of individuals, sometimes interacting with a process.

But what is “culture?”

I would contend that “culture” is composed of the norms and rituals of how people interact with each other.

For example, prolonged direct eye contact (“staring”) is rude in some cultures, but not in others. Cultural norms define how subordinates interact with their bosses, where people sit, whether they bow or shake hands when they meet. Cultural norms define how problems are brought up – by whom and to whom – or if they are brought up at all. In some cultures, “losing face” is a disaster, in others, openly blunt honesty is highly prized.

Within a company, of course, there are additional layers. In addition to the social norms of the society at large, there are rituals and norms about how people interact at work.

Therefore, I would contend that “culture” is something which emerges from the pattern of interactions between people.

Why is it important to understand this?

Because if we are trying to change the culture, we should not be focusing so much on individual behaviors as we are coaching those interactions.

In “Toyota Kata,” Mike Rother describes structured, practiced behaviors that are the building blocks of a culture of continuous improvement. Like kata in martial arts, more sophisticated moves are built up from these fundamentals. But if you really look at it, the behaviors he describes are actually interactions.

What this means is that if we are trying to coach toward change, we need to be simultaneously coaching at least two people at once. In each of these interactions there is a request or stimulus, and there is a response. Each has a specifically defined “way to do it.”

Stepping back a bit, if I look at Steve Spear’s “rules-in-use” from “Decoding the DNA of the Toyota Production System” I see the same patterns. The rules actually define structure for how people and processes are interacting with one another in a way that drives continuous improvement.

Just a thought for the day.

Posted on

Takt Time Is Local

There was an interesting search in my logs today.

[does a system have a single takt time or multiple]

I always figure that if one person is looking, others are also curious, so let’s address it and maybe there will be a better search result for the next Googlenaut out there.

Takt time is local.

It is calculated based on the demand from your customer.

This is a critically important concept because for takt time to be of any use, it has to be relevant to the people who are actually doing the work.

Example 1:

A factory has four final assembly lines that feed into shipping.

There are 420 minutes of working time in the day, and total aggregated leveled output is 350 units of production.

What is the takt time?

For shipping, it is straight forward. The customer takt time is:

420 minutes / 350 units shipped = 72 seconds

So for shipping to stay on task, their process must be capable of packing and loading one unit every 72 seconds. If they can’t consistently achieve that, they are falling behind.

What about the assembly lines?

You don’t know, because you don’t know what each of them is expected to produce. You could say that the factory takt is 72 seconds, but that does not pass the “so what?” test for the people working on those lines. But if you know that:

  • Line A’s leveled production is 75 units
  • Line B’s leveled production is 50 units
  • Line C’s leveled production is 100 units
  • Line D’s leveled production is 125 units

then you can determine a meaningful takt time for each of those lines.

  • Line A: 336 seconds
  • Line B: 504 seconds
  • Line C: 252 seconds
  • Lind D: 201 seconds

In reality, I am going to run these lines a little faster, but that is a different topic entirely.

Now we have a takt time that actually matters. It reflects the work cycle that must be achieved for that line to meet its obligation to its customers.

Example 2:

Upstream there are fabrication or other feeder processes. We have not yet gotten them into directly linked flow.

Process E feeds one part to each unit produced on Line B; and one part on every FIFTH unit on Line C. What is the takt time?

Line B needs 50 parts. Line C needs (100 / 5 =) 20 parts for a total of 70 units of output.

So Process I has a takt time of (420 minutes / 70 units of output =) 360 seconds.

Value stream mapping is very useful for untangling this. Hopefully you can also start to see one of the reasons we work so hard to level volume and mix.

This isn’t complex stuff, but on the other hand, if you oversimplify it then it becomes meaningless. Remember, this is not about OUTPUT, it is about testing whether your process has succeeded each and every time it is carried out. You can only do that if you know what is expected right then and there.

Go to your shop floor. Watch the work. Can you tell, with each unit of output, whether the team member was successful that time? (More precisely, can you tell whether you were successful in giving that team member what she needed to succeed!). If you can’t tell, I guarantee that the people doing the work have no idea, which means you are leaving them to guess. Not a good thing.

Posted on

Home Appliance Utilization

Bob Hanover has a great little article about applying visual controls to household laundry on his “Thoughtput Solutions” site. (cute way to use TPS as the name for the company, too.)

The concept he outlines is the same one that is (or should be) used to trigger batch run points for kanban managed machines.

But I want to talk about machine utilization, especially of home appliances.

A modern home washing machine can cost anywhere from a few hundred dollars to over a thousand, depending on the make, model and features.

In a household like Bob’s, with two adults and seven kids, it makes sense to ensure this expensive machine is running to full capacity.

To keep the machine running, as each load is complete, the next one should be started, otherwise the machine will sit idle, and that would be bad… right?

Let’s do some math.

Typically a home washing machine completes its automatic cycle in just around half an hour.

Typically a home dryer completes its automatic cycle in around 45-50 minutes.

So, if you want avoid having the washer stand idle, what are you doing to do?

I’ll tell you what nobody does. Nobody keeps putting loads into the washer and piling up wet clothes to wait for the dryer. It is obvious that the dryer is pacing the process, and running loads through the washer faster than the dryer can take them would defy common sense. Wouldn’t it?

Yet we do this all of the time in factories.

Why?

Posted on

Taktzeit

Now and again someone wonders out loud why, in this lexicon of Japanese terms, we have the word “takt.”

I had always passed along what I had heard – that the word was German, short for taktzeit and used in their factories to represent the pace of production. During WWII, the Germans had helped the Japanese set up more efficient production lines, and the word migrated into Japanese usage.

All of this had been anecdotal.

factory_floor07But today I ran across Alan Hamby’s phenomenally in-depth reference site on the German WWII Tiger Tank. Alan has extensive detail on the Henschel Tiger Tank Factory, and in some of the photos are signs indicating the number of the “takt” or production position.

But don’t stop here. Take a look at Alan’s site, and look at how this factory is set up and operated. This plant was set up to produce a Tiger I tank every six hours, and built a total of 1375 of them between 1942 and early 1945. Yes, there is a lot of waste, but bluntly, I have seen 21st century factories making products of similar size and complexity that are far worse than this.

The idea of pacing and balancing production is not new. By the time these photos were taken around 1943, the concept had been proven for over 20 years. Yet when I visit factories today this is a seemingly novel concept. I always wonder why today’s operations managers are not insisting on at least the efficiencies that were achieved by 1935.

Thanks to Alan for his kind permission to bootstrap from his research and use these rare photos here.

Just to be clear, though, having a pace for production does not make a line “lean.” Far from it. But it is a foundational element. It may not be sufficient, but it is (in nearly all cases) necessary. What makes it foundational element for improvement, however, is not so much the pacing and balancing aspect. Rather, the concept of takt time can be used as a way to structure improvement goals and targets in a way that is meaningful to the people doing the work.

We talk a lot (all to much, in my view) about metrics, but tend to think of the things management is interested in – like labor productivity. But the way you get labor productivity is to focus on the takt time, the total cycle time, and the stability of that cycle time. Those are the things that determine how much gets done by how many people. You can measure “labor productivity” all you want, but you can’t change it unless you get down another couple of levels. Fortunately (for us) Reichsminister Speer didn’t figure that out.

By the way, just to put things into perspective:

In 1943, Boeing Plant 2 was producing one B-17 bomber an hour, sixteen planes a day, six days a week. They did it by using a paced assembly line and continuously working to simply and improve the flow.

Posted on

Press release – New LEI Book: “Building a Lean Fulfillment Stream”

I wanted to pass along this press release from the Lean Enterprise Institute.

I will be getting a copy and post a review after I actually read it.

[Edit: I read it, and decided not to post my review.]

One thing I am going to be looking for is how the proposed model implements PDCA to drive continuous improvement. There are lots of good schemes for building a fulfillment system out there. In the past, I have used a few pages in Chapter 4 of “Lean Thinking” as a solid, workable starting point for fulfillment streams that did just that. So I will be curious whether this book builds on that foundation. [Edit: It doesn’t.] Anyway – here is the LEI’s release for the book:

New Workbook Demonstrates Use of Lean Management to Rethink Supply Chains and Logistics

Building a Lean Fulfillment Stream, the latest workbook from the nonprofit Lean Enterprise Institute, shows how lean thinking converts “supply chains” into swift, smoothly flowing “fulfillment streams” while reducing the total cost of fulfillment.

Cambridge, MA, May 11, 2010 — Despite the substantial progress many organizations have made using lean management techniques to improve internal operations, they have paid little attention to launching lean transformations in their external links to downstream customers and upstream suppliers.

Now, in the pioneering new workbook, Building a Lean Fulfillment Stream, (Lean Enterprise Institute, May 12, 2010, $50.00) lean logistics veterans Robert Martichenko and Kevin von Grabe describe a proven approach for applying lean principles to supply chains and logistics.

Using the example company ABE Corp. as their model, the authors illustrate both the implementation process and the benefits to ABE’s bottom line from applying lean principles. Plus, they show how the conversion process is a win-win for every company along the supply chain. The narrative is supported by 41 charts and illustrations, including value-stream maps, calculation details, and financial analyses.

Readers will learn:

  • How to calculate the critical total cost of fulfillment so you make decisions that meet customer expectations at the lowest possible total cost, no matter where costs occur in the supply stream.
  • How to apply the eight guiding principles for implementing lean fulfillment, even when all the data and variables are not known.
  • The seven major types of waste in logistics and supply chains.
  • How a fulfillment stream council comprised of representatives from internal departments, customers, suppliers, and transportation providers critical guidance and support.
  • The “eight rights” used to measure perfect order execution.
  • What lean metrics to use to measure progress, such as why average days on hand of inventory is a better measure than inventory turns.
  • A method for collaborating effectively with customers.
  • How to identify waste in shipping, receiving, and yard management.

Building a Lean Fulfillment Stream: rethinking your supply chain and logistics to create maximum value at minimum total cost

– By Robert Martichenko and Kevin von Grabe

– Published May 12, 2010, Lean Enterprise Institute

– 111 pages; 41 charts and illustrations

– ISBN: 978-1-934109-19-9

– $50.00 (hardcover)

– Excerpts, author Q & A, bios, more: http://budurl.com/vamd

– Media: Chet Marchwinski, LEI, cmarchwinski@lean.org, 617-871-2930

Based on the workbook, the workshop Building the Lean Fulfillment Stream: Supply Chain and Logistics Management teaches supply chain and logistics managers the “must know” lean concepts and applications.

Robert Martichenko
Robert is an LEI faculty member and CEO of LeanCor, a third-party logistics provider dedicated to the application of lean principles throughout supply chain functions. He learned about lean working at Toyota Motor Manufacturing Indiana and has over 15 years of lean supply chain and third-party logistics experience. He is co-author of the business management book Lean Six Sigma Logisticsand the lean primer Everything I Know about Lean I Learned in First Grade. Robert also teaches global business at Saint Louis University’s John Cook School of Business.

Kevin von Grabe
Kevin is vice president of lean deployment LeanCor. His experience in materials management, transportation, and third-party logistics includes a greenfield start up at Toyota Motor Manufacturing Indiana. Kevin’s international experience includes operational start ups for Jabil Circuit at plants in Hungary and China.

Posted on

Toyota Kata: Avoid Pareto Paralysis

A great key point comes out on page 124 of Toyota Kata by Mike Rother.

…a Toyota person once told me to focus on the biggest problem. However, when I tried to do this I noticed a negative effect: We got lost in hunting for and discussing what was the biggest problem. When we tried gathering data and making Pareto charts, it took a lot of time and the biggest problem in the Pareto chart was usually “other” which put us back into debating options. By the time we decided what the biggest problem was, the situation at the process had changed. This effect is called Pareto paralysis, and I encourage you to avoid it. Pareto paralysis delays your progress as people try to determine the “right” first step to take.

[…] it matters more that you take the first step than what the first step is.

I have seen this many times with my own eyes. It is a common problem when “problem solving” is taught as “application of the seven tools” and “correct” use of the tools becomes more important than understanding the problem or making actual progress.

Hirano, I believe, has been quoted as saying:

Waste often comes disguised as useful work.

That is what is happening here. The team thinks they are working to solve the problem when, in reality, they are still trying to decide what problem to work on. The gridlock may be driven by fear of working on the wrong problem. But in reality, there is no wrong problem, there is only the one that is in your way.

Here is something else I commonly see. When they discover “problem solving” many organizations want to immediately undertake large projects that involve “stretch goals” and breaking down complex issues. They look at operational metrics that are actually aggregated – total inventory, total lead time, productivity of the entire factory, total defect rates, total lead time through the system. While those metrics are nice to gage progress, they do not give you any actionable information.

Even worse is using averages. Averages aggregate even more, and “bad” tends to be countered by “good” in many average calculations. What is important is to look at each instance vs. an external, discrete, and objective standard or specification. Average defect rates tell you nothing at all about what to work on. But this unit had this defect, or this part dimension was this amount out of specification DOES.

Put another way, there are very few big problems. Big “problems” are the aggregated symptoms of many small problems.

This is good news and bad news.

The good news is that small problems can usually be understood, cleared and sometimes solved fairly quickly. The bad news is that it takes work to do this. The other bad news is that there isn’t any other way that actually works.

Doing a good job working on large complex issues requires engaging across the organization, time, and a high level of skill at understanding the situation, framing the problem, getting to causes, working on solutions, testing understanding, etc. Doing it well requires a mentor who is intimately familiar with the thinking behind problem solving.

This skill can not be gained in a “problem solving” or “A3” class, at least not one that simply walks the team members through the process once or twice. Skill comes from practice, and effective practice comes from starting simple, working in an environment where it is safe to experiment and to be wrong. This means working on shop floor issues that can be isolated from one another, the effect of a test or simulation can be seen immediately. The factory and production organization that Steven Spear describes in his research about Toyota is actually designed deliberately to facilitate this kind of work.

Another common mistake is setting up performance targets too early. If the processes are inherently unstable – if there is no sense of takt time, you are having problems with consistent quality or delivery, the first goal is simply to get to the point where you actually know how things are performing against an indicator of stability. Again, this is usually much simpler than setting a high level target and then trying to break down and stratify all of the issues out there. Set that stability target, study the process, and take on the disruptions as you see them. If there is a debate about which one to start with, then start with the simplest one so you can improve your capabilities.

In the end, it is about taking on problems as they come up, where they come up. That thinking is facilitated by the way you structure the flow, the work, and the organization itself. Get to the shop floor, stand in the chalk circle, and ask “What is stopping this team member from being successful right now.”