Tag: Problem Solving

Posted on

Pull as Kaizen

Michael Ballé’s recent Gemba Coach column drives home the importance of understanding that all of the so-called “tools of lean” are really there to drive problem solving.

A well designed kanban system is (or at least should be) built to not simply provide a pull signal, but more importantly, to continuously ask, and answer:

  • “What is supposed to be happening?” (what is the target condition?)
  • “What is actually happening” (what is the current condition?)

and give at least a hint of the problem that needs to be addressed right now when there is an issue. As a minimum, what condition must be addressed right now, and the first “Why? to be investigated.

A couple of months ago I posed a hypothetical question about a team’s effort to put in a kanban process and asked for your thoughts and comments.

The scenario I described was, with one or two trivial changes, copied directly from pages 48 and 49 of the Lean Enterprise Institute’s latest workbook, Creating a Lean Fulfillment Stream.

Although the process as described would likely work (at least for a few items), I was really surprised to see an LEI book describe a process that explicitly and deliberately breaks the “rules of kanban” that they have published elsewhere, particularly in Lean Lexicon. The LEI did not make up the rules of kanban, they have been well established for decades. Thus, I have to admit that my first response was to question the credibility of the entire book (Lean Fulfillment Stream), even though there are many things in it that are worthwhile.

Many of you correctly called out issues with the mechanics. Now, in light of this new information, I would again like to invite comment.

If a good process should be set up to continuously ask, and reveal the answers to, those two questions, where does this kanban scheme come up short?

How would those issues cause problems with the processes that Ballé is describing in his column?

 

Posted on

If The Student Hasn’t Learned…

The teacher hasn’t taught.

This article, titled “Why China is Not Ready for Lean Manufacturing” presents an account of trying to teach “lean manufacturing” in a Chinese factory. The experience is summed up in a couple of key paragraphs:

The team arrived in Dongguan and went to work giving an overview class on Lean techniques. The factory workers seemed attentive and interested in learning. The next day, the Silicon Valley Lean team gathered the people from the assembly line to begin the process of working on the quality problem. After 3 hours, the Lean team ended the session in utter frustration. No one participated. No one would identify problems on the line. No one knew how to approach gathering or analyzing data. No one volunteered.

So what happened? The training was adequate and the Lean principles and methods are sound and easily understood. Why weren’t the Chinese factory workers participating?

Why indeed?

The author’s conclusion is that Chinese worker’s culture and values conflict with the idea of collaboration and contributing ideas to improve production quality and efficiency.

But the article brought up two separate thoughts.

First, there is nothing magic about Western culture. These concepts can, and do, fall just as flat in the USA and Europe as they did in this factory. The problem in these cases has less to do with the national culture, and more to do with attempting to apply a rote approach to teaching.

Second, the result cited here was exactly the opposite of my own experience in a Chinese factory.

It took some persistence, and it took some deliberate steps to remove fear from the factory floor, but in the end we had these Chinese workers making some very innovative contributions.

400ArmBoringMock01 This photo is an old boring mill. It was a slow old boring mill. We needed to squeeze cycle time out of the process to make the projected takt time. We showed the workers some photos of other teams’ efforts to mock-up fixtures so they could quickly try out ideas. The workers, after a few false starts, constructed what you see here, and ended up with a pretty good set of fixtures that could be loaded and unloaded quickly. After some trials, they figured out on their own that they could fit two fixtures on the platform, which allowed them to be unloading and loading one while boring on the other.

400BucketBoring

One of the machinists complained that the machine could run faster if it had a liquid cooling system. With encouragement, he designed and built a simple, but working, cooling system for the cutting tools. (The steel box in the foreground with a pump on it.) The clever part was the chip filter made from a bottle cap and a nail.

400BucketCellMock01 Another team was working on a welding cell. They ended up designing and fabricating more efficient fixtures than had been provided by the engineers. Then they set out to develop the most efficient way to get parts positioned, to load them quickly into the fixture, and weld up the part.

 

 

What was different?400CellWorkDesign

First, we didn’t do any classroom education. Not quite true. We showed them photos of really good welding fixtures that had been designed by a sister company. That took about 30 minutes. We explained what features made those fixtures good. Then we continuously encouraged them to try things so they could learn on their own. And try they did.

We didn’t ask them to go beyond mock-up. We fully expected to take their ideas, turn them over to engineers to get them finalized and drawn up, then have the fixtures fabricated. But the workers took it on their own initiative to dig through the (embarrassingly large) amount of scrap metal out back, bring in what they needed, machine parts, scrounge others, and built their fixtures in steel.

A number of ideas were things I could clearly see would not work. I knew that heat distortion from welding would make a particular fixture design difficult (impossible!) to unload after welding. I could tell them it wouldn’t work, or I could let them try it on their own. I chose the path that would engage their curiosity and let them learn through experience. They became better welders for it.

Honestly – this was a slow time while we were working out other issues with market positioning, sales, design and sourcing decisions, and most of this activity was intended to keep people busy and engaged. But what we ended up with was production-ready work cells, all built upon ideas from the workers.

So why did I tell this little story?

First, I will admit that I was pretty proud of these guys. This was a few years ago now, but it was fun blowing away everyone’s stereotypes about Chinese factories and Chinese workers.

But I wanted to make a key point.

Instead of looking for cultural reasons why “this won’t work here” we kept faith that, if the initial response was silence and non-participation, there was something that we needed to address in the way we taught, and in the environment we were creating.

Indeed, what the Chinese culture brings to kaizen is a centuries-old tradition of improvising with what you have to get something done. This is a great strength that can be hard to find in cultures with longer traditions of wealth.

Just as we were encouraging these workers to try things so they could learn what did work, we had to do the same thing. We didn’t give up after three hours. Eventually we managed to remove the fear and bring out the best these people had to offer.

Classroom education is actually a very poor way to teach people how to study a process, understand it and improve it. Sometimes it kind of works, but I think that is because it is marginally effective if all of the other conditions are right. Perhaps in some cultures that starting point is past the limit of what classroom education can handle. That isn’t a problem with the culture, it is revealing the inherent weakness in the approach.

There is no cookbook. There is only a clear objective, and good faith effort to keep trying until a solution is found.

Epiloge: Yes, this factory got into production. However the parent company could never get traction in this market with this product and recently made a decision to close this plant and pursue a different strategic direction. That is not a reflection at all on the people who did the work in these photos.

Posted on

“Opportunities” vs “Problems”

Over the decades, I have observed that it is quite common for organizational leaders to try to use the word “opportunity” when talking about a problem.

I can understand the desire to do this – we typically think of “problems” as something to do with people.

But I find the emphamistic language… problematic.

 

 

Mr. Opportunity

 

There is a Honda marketing campaign in the USA that features a cartoon character named “Mr. Opportunity.” His tag-line is “I’m Mr. Opportunity, and I’m knocking.” The opportunity is an invitation to take advantage of discounted prices for Honda cars.

Words mean things.

An opportunity is something that I may, or may not, decide to pursue.

But in lean thinking, no problem can go unaddressed.

Rather than a friendly cartoon character knocking on your door, a problem has kicked your door in and is standing in your living room. It must be dealt with, and dealt with quickly.

It has to be contained, pushed back, and finally resolved to keep it from getting back in.

IF the process for doing these things is carried out correctly, there are opportunities for the organization to learn along the way. But in the vast majority of cases, the only way those opportunites get exploited is if the leaders insist on hearing what was learned. So even those “opportunities” shift to imperatives.

Friendly euphemism that soften the urgency do not help us. If we are to have a true problem solving culture, we have to be willing to call things what they actually are.

Posted on

5S Erosion – Continued

In the post on 5S erosion, I posed a couple of questions.

What, exactly, is the function of a 5S audit?

What, exactly, is the problem [the audit is supposed to solve]?

How do you know [that is the problem]? What have you observed?

The responses have been interesting, wide ranging, but so far have not directly addressed the questions.

If you were preparing a simple A3, “auditing” would be one of the checks or countermeasures.

But what problem would you be addressing?

What have you observed that indicates there is a problem?

Note that I am not questioning the value of having a standard for workplace organization.

I am not even directly challenging audits, measurements, etc. However these things must have a clear purpose, or we are just blindly implementing tools and repeating mantras. And if we cannot articulate the core purpose of these things to each other, how can we ever ask others to do these things with any more authority than “because I said so” or “because it is in this book?”

Posted on

5s Erosion: What Is The Problem?

I had another opportunity today to discuss why I am not a big fan of “5S audits.” I fully realize that 5S audits are out there in a big way and are almost pro-forma as a “lean practice.” I have not run into any consultants who do not have some kind of 5S audit in their collection of tools, and the topic has pretty constant traffic on the Lean Enterprise Institute discussion forums – and just about anyone who offers one up gets a lot of requests for copies.

Before I go too far, though, let me explain what I mean when I say “5S audit.”

What I typically see is a single page with a 6×6 matrix of squares on it. Down the left hand side in column 1 are labels for whatever 5 “S words” are being used in this particular version. Across the top in the top row are points assignments from 1 to 5.

The grid is then filled with criteria in each “S” to get the specified number of points, maximum 5 in each category.

Auditor takes the checklist, looks at the area being audited, perhaps asks some questions, and assesses, for each “S” how many points are given.

It is typical to then make some kind of chart – spider diagrams are popular – and assign the area a score, perhaps an average, so they are, for example, at “Level 3” on their 5S efforts.

Does that about capture it? There are variations, but I do not care so much about the form as I do the function.

And what, exactly, is the function?

That is a question that does not get asked often enough, and if it does, the asker does not press hard enough on “exactly.”

Let’s keep in mind that this audit consumes time and resources and produces nothing. Therefore it had better be an effective countermeasure to some kind of problem.

What, exactly, is the problem?

How do you know? What have you observed?

Give that a little thought.

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

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

Posted on

Problems Hidden In The Open

We were down on the shop floor watching an assembly operation. The takt time was on the order of three hours. The assembler was new to the task, and the team leader periodically came by and asked if he was “doing OK.” The reply was always in the affirmative.

As the takt time wound down to under five minutes to completion, this operation was the only one not reporting “Done.”

The count down hit zero, things went red, the main line stopped, and the line stop time started ticking up.

The team leader, other assemblers, the supervisor began pitching in to assist. Between them, the job was completed in about 10 minutes, and the line restarted.

So, again, my favorite question:

What’s the problem?

Lets try breaking it down to four key questions.

  1. “What should be happening?”
  2. “What is actually happening?”

    3. The above two questions define the gap.

  3. “Why does the gap exist?”
  4. “What are we doing about it?”

These questions simply re-frame PDCA, but without so much abstraction.

So, in this situation:

What should be happening?
Two things come to mind immediately.

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

For this to work, though, the team member needs a clear and unambiguous way to answer a key question of his own: Am I on track to finish on time? Ideally the answer to this question is a clear “Yes” or a clear “No,” with no ambiguity or judgment involved. (Like any “Check” it should produce a binary result.)

On an automobile line with a takt time on the order of 55 seconds, the assembler can get a good sense of this. If he loses more than three or four seconds, he isn’t going to make it. But “a good sense” isn’t good enough.

Even in this fast-moving situation, you will see visual indicators that help the team member answer this question. Take a look at this photo.

toyota-assy

See the white hash marks along line at the bottom of the picture? Those mark off the moving line work zone into ten increments of about 5 ½ seconds. The assembler knows where he should be as he performs each task. If he is a hash mark behind, he isn’t going to finish on time. Pull the andon. We can safely say that, in this example, we have accomplished (1) and (2) above.

With longer takt times, it is much tougher for a human to have a good sense of how much time will be required to complete the remaining work. That makes it that much more critical that some kind of intermediate milestones are clearly established and linked to time.

What would be a reasonable increment for these checks? –> How far behind are you willing to let your worker get before someone else finds out? I’d say a good starting point is at the point when he can’t recover the time himself, the problem is no longer his. Following the standard work is the responsibility of the team member. Recovering to takt time is the team leader’s domain. At the very least, he is the one who pitches in and helps, or gets someone else to do so. But he can’t do this if he doesn’t know there is a problem.

So – what should be happening?

The team member must have continuous positive confirmation that he is on track to complete the work on time. With the failure of that positive confirmation, he should pull the andon and get assistance.

The team member must call for assistance (“pull the andon”) if his work falls behind the expected progress for any reason whatsoever.

What is actually happening?

In our example, the team member didn’t get help until it was too late. In fact, he verbally assured the team leader he was “OK” on a couple of occasions. The line stop was irrefutable evidence of a problem. That was a good thing. This company has a takt time, and runs to it. Think of what would have happened if they didn’t. It might take hours, or days, before this problem surfaced. (We are nowhere near the root cause yet. The line stop is just evidence of a problem, not the problem itself.)

Why does the gap exist?

It is a hell of a lot harder to answer this question than the other two. In this case, you are going to have to peel back a lot of layers before you get to the actual, systemic, root cause. But in the immediate sense, with a takt time bordering on three hours, there is really no realistic way a worker can judge if he has fallen too far behind to catch up. The fact that, in this case, the assembler was still learning the job, and that just compounds the situation.

From casual observation – when the team leader visited, he asked if things were OK and accepted the reply – I would start to investigate whether the team leader had a good sense himself of where the work should be at his regular check points… if he has regular check points at all.

But all of this is speculation, because after 10 minutes of watching the initial response to the line stop, our little group had moved on. I am mentioning these things as possibilities because you likely have the same issues in your shop. (And if you don’t have a rigorous sense of takt time, it is equally likely you don’t know about those issues even at the level we saw here. At least THIS company can see the evidence of the problem. That is a credit to their visual controls.)

What are we going to do about it?

Obviously there are a couple of immediate things that can be addressed to at least contain the problem. (That is, convert a hard line stop into multiple andon calls so the actual problems are seen earlier.)

I would want to establish a regular routine for the team leader’s checks. His leader standard work. At regular intervals, he should be checking progress of the work. How often? How far behind do you want the assembly to get before you are certain someone finds out about the problem? In this case, even every 20 minutes is less rigorous than the hash marks on the auto assembly line. But it would be a start.

So we have the team leader coming by every 20 minutes.

But he can’t just ask “How is it going?” We clearly saw that didn’t work. It isn’t that the assembler lied to him, it is that the assembler didn’t know because there was no standard.

What work should be complete 20 minutes into the work cycle? At 40 minutes? At 60? What verifiable facts can the team leader check by observation? There are a lot of ways to do this, most of them very simple and non-intrusive. Think it through.

But wait – now the team leader himself has standard work. What cues him to do it? Is he supposed to notice that 20 minutes has elapsed? In this case, the company already has a pretty sophisticated andon and sound system. It would be a pretty simple matter to put in an audible signal that told the team leader to make his checks. But, again, that is just one solution. I can think of a couple of others. Can you?

What is the team leader checking for? This is a critical question.

Think about it.

What was the original answer to “What should be happening?” (which is “the standard”)

We said:

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

We want the assembler himself to be checking #1.

So why do we have the team leader check?

So he can verify that the assembler is pulling the andon when he should. This is important because it is human nature not to ask for help until it is too late. This isn’t limited to factory floors. How many cardiac patients die because they ignored the warning symptoms for fear that it isn’t serious enough to get help?

It isn’t enough to ask the team member to call for help. You have to expect it, encourage it and require it.

Interestingly enough, as I was writing this post, John Shook posted his story about converting the culture at NUMMI.

A cornerstone of Respect for People is the conviction that all employees have the right to be successful every time they do their job. Part of doing their job is finding problems and making improvements. If we as management want people to be successful, to find problems, and make improvements, we have the obligation to provide the means to do so.

But, some of our GM colleagues questioned the wisdom of trying to install andon at NUMMI. “You intend to give these workers the right to stop the line?” they asked. Toyota’s answer: “No, we intend to give them the obligation to stop whenever they find a problem.” [emphasis added]

What was the problem in our example? We don’t know yet. We certainly can’t start looking for causes.

But the evidence of a problem was that the team member could not complete the work in the time expected. That is, he was not successful doing the job. And the line stopped because the support system failed to pick up the fact that he was falling behind until it was too late to recover.

It really does come down to respect for people.

Posted on

Reducing Inventory

Yesterday’s post on vendor managed inventory touched on a couple of things about “lean” and reducing inventory that I’d like to explore further.

All too often “inventory reduction” has been a way to “sell” a lean manufacturing implementation. The reduction of inventory becomes the objective. While this isn’t inherently a bad thing, it is all to easy to get caught up in the trap of “management by measurement” and do it the wrong way.

Reduced inventory is a result of good kaizen, but it isn’t the justification for doing it. The purpose of kaizen is to solve problems, specifically the problems that disrupt the smooth flow of work and creation of value. Solving those problems saves time – worker’s time, customer’s time, leader’s time because everything runs more smoothly and predictably.

The primary reason that inventory is there is because things aren’t smooth and predictable. Once they are, you can take some of it out.

The necessity to have inventory at any given point in the system is evidence of a problem that has not yet been solved. (Including, sometimes, simply having poor inventory management, which is another way of saying “overproduction.”)

By asking “What must we do to live without this piece of inventory?” you can uncover the next problem to solve, and then make a decision to solve it.

If it is solved, then inventory can be reduced. But it doesn’t happen automatically, you have to actually take it out of the system and keep it from coming back.

But in any case, this is a lot different than just shoving the ownership of the inventory onto someone else.

Posted on

Design Innovation Example

This post on the Fastcompany.com blog shows a clever desktop manufacturing invention.

But what really got my attention was the development process that starts at 3:40 in the video. It shows the process of developing it. They may not call it “3P” but, by and large, this is what it looks like.

As they develop ideas, they try them out in simulation, learn, improve, try, learn, improve. As the design matures in stages, they are moving forward, step by step, with concepts that are solid. This process is fast, flushes out problems early, while they are cheap to fix, and fun.

Contrast this with what might be created by a traditional process with the assignment of making a “tabletop NC cutter for cardboard.”