Tag: Problem Solving

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

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

Posted on

Get Specific

A couple of days ago I had an interesting session with an improvement team in a fairly large company. They have been working on this for almost 10 years, and believe that while they have made some spot progress, they are clear that they have spent a lot of money but not yet established what they call a “lean culture.” Their implied question was “How do we get there?”

My question was “When you say ‘a lean culture,’ exactly what are you thinking about?”

What do people do? How do they behave?

“People find and eliminate waste every day.”

OK, so if they were doing that, what would you see if you watched?

There was a bit of a struggle to articulate an answer.

I see this all of the time. We rely on the jargon or general statements to define the objective, without really digging down the next couple of layers and getting clear with ourselves about what the jargon means to us. This is especially the case when we are talking about the people side of the system.

But the people are the system. They are the ones who are in there every single day making it all happen. It is people who do all of the thinking.

Consider these steps:

  • Define Value.
  • Map your value streams.
  • Establish flow.
  • Pull the value through the value stream.
  • Seek perfection.

This is the implementation sequence from Lean Thinking by Womack, Jones and Roos, that has been the guideline for a generation+ of practitioners.

Learning to See taught that generation (and is teaching this one) to establish a current-state map of the value stream, and then a design the future state to implement as flow is established. The follow-on workbooks focused on establishing flow and pull, and did it very well.

While not the only way to go about this, it does work for most processes to establish flow in materials and information.

But what do people do every day to drive continuous improvement, and how are those efforts organized, harnessed, and captured to put the results where they can truly benefit customers and the business?

Here are some things to think about.

What exactly is the target condition for your organization? Can you describe what it will look like? Can you describe it in terms of what people experience, and do, every day?

When your people go home to their families and share what they did at work today, what will they talk about? And I don’t just mean the engineers and managers. What will the front-line value-creating people remember from the workday?

How will they talk about problems?

If your target future state now includes changes in how people work, ask yourself more questions.

When, exactly, are they going to do these things you described? By “when” I mean what time, starting when, ending when.

What, exactly, do they do when they encounter a problem during production?

How, exactly, do you expect the organization to respond to that problem? Who, exactly, is responsible to work through the issue and get things back on track? How long do they have to do it? If the problem is outside their scope, what is supposed to happen? How, exactly, does additional support get involved?

If these new activities involve new skills, when and how, exactly, are people supposed to learn them and practice them to get better at it? Who is supposed to teach them, when, where, and how? How will you verify that the new skills are being used, and are having the effect you intend?

“If we do this, what will happen?”

And then what? And then what?

Think it through.

The “people” future state is far more important than future state of the material and information flow.

Posted on

John Shook: “A Technical Problem or a People Problem?”

John Shook dives into some of the messy issues of true root cause in his most recent post.

We touched on a similar issue here a few months ago. But it is always worth coming back around to people because because in this system (actually in any system) there are always two issues with people.

  1. People are the most fallable part of the process.
  2. The process cannot operate without them.

The reflex is often to go into total denial about #1 and expect people to be vigilant and perfect every time. “Weed out the bad apples, and everything will be fine.” Of course that doesn’t work.

In John Shook’s example, he traced through Ohno’s classic “5 Why” example.

1. Why did the machine stop?
There was an overload and the fuse blew.
2. Why was there an overload?
The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently?
The lubrication pump was not working sufficiently.
4. Why was it not pumping sufficiently?
The shaft of the pump was warn and rattling.
5. Why was the shaft worn out?
There was no strainer attached, and metal scrap got in.

Then Shook asks a really interesting question:

Why was no strainer attached?

Why not indeed? Isn’t that somebody’s job?
And now, as he points out, we have transitioned from “technical” to “people.”

Maybe the standard work for the maintenance worker or machine operator didn’t go far enough. Or maybe the standard work did specify changing the strainer but the worker failed to observe the standard. How was the standard developed, how was it communicated and trained? How easy was it to “forget” to change the strainer?

Coming, as I do, from mostly “brownfield” environments, the existance of standard work in the first place isn’t something that we can take for granted.

Nevertheless, Shook is making a critical point here. It does not matter whether there was no standard work, or whether the standard work broke down for some reason that we do not yet know (another “Why?”). This is still a process problem. We must start with a working assumption that the team member cares, and is doing the very best job possible, given the expectations, the resources, and his understanding at the time.

I am aware of a couple of cases where engineering change implementation pulled up short of actually observing the new installation and looking for unforeseen problems. One of them was quite subtle, and actually took a few weeks to find the basic cause, much less the root cause.

Another resulted in a bolt snapping during final torque. Messy to fix, but better in the factory than in the field.

These are additional cases where technical problems resulted from process breakdown, and in both cases, it was a case of unverified or blindly held assumptions, and not following through with the customer process.

Shook concludes with two really important points, and I can’t agree more. First:

…the work design must also include the “human factors” considerations that make it possible to do the job the right way, and even difficult to do it the wrong way.

I like to say “Make the right way the easy way” if you want things done in a certain manner.

Which brings us to Shook’s final point: You have to look at the total package – the human and the technical as an integrated system. You can’t separate them because. You can’t “take people out of the process.” All you can do is construct the process to give people’s minds the most opportunity to focus on improving the work rather than burdening them with making sure they get it right.

Always work to support people to do the right thing in the right way. If the organization carries a belief that it is necessary to force or “incentivize” people to do the right thing, then there is a people problem, but it isn’t with the workers.