Tag: Jidoka

Posted on

Boeing Moving Line

Boeing’s “PTQ” (Put Together Quickly) videos show a time lapse of an airliner in production. They have been producing the for years – certainly since I was working there.

This one, though, shows something a little special.

When I first started working there, the idea of a line stop was unthinkable. The plane moved on time, period. Any unfinished work “traveled” with the plane, along with the associated out-of-sequence tasks and rework involved.

The fact that the 737 is now built on a continuously moving assembly line in Renton is fairly well known.

But what struck me in this PTQ video is that one of the things highlighted in it is a line stop. It happens pretty quickly at about 1:57.

The video is also full of rich visual controls to allow the team to compare the actual flow vs. the intended flow. See many many you can spot.

Posted on

Keep Visual Controls Simple

In this world of laser beams and ultrasonic transducers, we sometimes lost sight of simplicity.

Remember- the simplest solution that works is probably the best. A good visual control should tell the operator, immediately, if a process is going beyond the specified parameters.

Ideally the process would be stopped automatically, however a clear signal to stop, given in time to avoid a more serious problem, is adequate.

So, in that spirit I give you (from Gizmodo) the following example:

Warning Sign

Posted on

Automating the Coaching Questions

Hopefully that title got some attention.

In Toyota Kata, Mike Rother frames a PDCA coaching process around five questions.

The first three questions are:

  1. What is the target condition?
  2. What is the current condition?
  3. What problems or obstacles are preventing you from reaching the target?

Wouldn’t it be wonderful if we could build a machine that asked and answered those questions for us?

Of course automated processes do not improve themselves (yet). But they can be made to compare current operation against a standard.

When Sakichi Toyoda was working on automated weaving looms, he was actually striving to reduce the need to have an operator overseeing each and every machine. That was the point of automating the equipment. One of the problems he encountered was that threads break. When that happened, the machine would continue to run, producing defective material.

So in order to reach his goal, he needed to replace the need for a human operator to be asking these questions and give that ability to the process itself.

What is the target condition?

The loom continues to run and produces defect free material. For this to occur, the threads must remain intact.

What is the current condition?

The threads are either intact, or they are broken.

But if the machine cannot continuously ask, and answer, that second question then a human must do it. Otherwise, nobody gets to the third question, “What is stopping us?” unless they happen to notice the machine is smoothly producing defective material.

Since his goal was to reduce the need for human oversight, he had to solve this problem.

Toyoda’s (now classic, and still used) response was to put thin metal floaters on each thread. If a thread broke, the floater dropped, triggering an automatic machine shutdown.

The machine was now asking the second coaching question with each and every cycle, comparing the actual situation with the target situation.

The event of the machine shutting down triggered the attention of a human operator with the answer to the third question.

What problem or obstacle is preventing you from reaching the target?

Right now, there is a broken thread. I cannot produce defect-free material until this situation is corrected. Please assist me.

The process was named jidoka and in that moment, the foundation for what grew into the Toyota Production System was set.

Without reliable and consistent production, one-by-one flow and just-in-time are impossible. The options are to either work on the problem, or stop improving.

It is the leader’s responsibility to ensure that there are processes in place to do these things. Sitting still is not an option, there is nothing in these techniques that is a secret. Your competitors are doing it. It is only a matter of who can solve problems faster and better.

 

Posted on

5S Audits – Part III

I would like to thank everybody for a really engaging dialog in the previous two posts about 5S audits.

Now I would like to dig in and look at what an “audit” is actually finding, and how we are responding to those issues.

Our hypothetical production area is getting an audit. The checklist says things like “There are no unnecessary items in the work area” and “There is a location indicated for all items.”

If there are unnecessary things in the work area, or things are not in their designated locations, what happens?

Of course, the checklist is filled out and a score is assigned.

But what has been learned about the process?

In one of the comments, I asked something like “When was the problem first noticed?”

The core purpose of 5S is to establish a testable condition that asks the question: “Does the team member have everything he needs, and nothing he doesn’t, where he needs it, when he needs it, to carry out his process as we understand it?”

One of the primary purposes of marking out the locations is to indicate the standard so that someone can notice right away that the standard has been broken. What should happen right then and there?

Since we define a “problem” as “any departure from the standard or specification,” and we have taken the first step of removing ambiguity from the situation (by deciding what should be here, and marking it out), we want an immediate response to the problem.

Ideally this means that the team member would indicate trouble (andon call, or other means) as soon as he discovered that his air gun was missing, or didn’t work.

The back-up to this is the team leader’s standard work. His eyes should be scanning for situations where there is a problem that the team member hasn’t called out. This is why the standards are marked out, posted, etc. To make this job easy for him. His immediate response would be to (1) Seek to understand the situation – what pulled the team member off his standard work, where did the problem originate, (2) Correct the situation. Sometimes that’s it. Other times, there is another problem to dig into.

It could be that something about the work process or conditions has changed and the team member is improvising a bit. That would bring extra stuff into the area, for example. I recall a great example where we pulled all of the thread cutting tools out of assembly so we could better detect when assembly was getting defective fabricated parts. It worked by forcing the process to stop and an andon call since assembly could not proceed if the threads were not cut.

At the same time, if a thread cutter found its way back into the assembly area, we would know we had two problems. First, we had defective parts. But more important, the process of telling us about that problem had been bypassed.

The back-up to the team leader’s standard work is the supervisor’s standard work. She is looking two levels down, but her response is going to be different. Unless safety or quality is jeopardized, the supervisor is going to find the team leader and (1) Seek to understand what pulled the team leader off of his standard work, and (2) correct the situation.

If the next level up is spending any time at all out on the shop floor, it is the same thing – maybe once a day – seeking out verifiable evidence that things are working as they should be. In the lack of positive evidence of control, we must assume there are hidden problems.

Now, if the audit finds something like this (click on the image for a bigger one):

Then it isn’t about the tape being out of place, nor is it a question about where the screwdriver is. What we have discovered is that none of the checks have been made, or if they have, no one has done anything about them.

Someone said “If we don’t do audits then 5S deteriorates.” OK – but why does 5S deteriorate?

Simply put, it is going to deteriorate, just as your process does, a little bit every day. Disorder is always being injected into everything. Your process will never, ever be stable on its own. No matter how good you are, the next level of granularity will show up as deterioration.

This is the “chatter” that Steven Spear talks about.

The question comes down to your core intention for the audit.

If you are assessing how well the area manager is coaching and teaching his people to see and respond to problems so that you can establish a target condition for his learning, and then develop his capabilities accordingly… there are better ways (in my opinion) to do that.

If you are assigning a numeric score in the hope that, by measuring something you can influence behavior, it might work, but people can come up with ingeniously destructive ways to achieve the numeric goals. As a thought experiment – how might an area manager get a high score on his 5S audit in ways that run completely counter to the goals of 5S, people development or “lean?”

The bottom line is that “Audit 5S” is not something that you should accept as a given. Rather, it is a proposed countermeasure to some problem. But if you start with a clear problem statement like “Team members are bringing thread taps into the assembly line,” and start asking “Why” five times, get to a root cause to that problem, you are unlikely to arrive at a monthly or periodic 5S audit as a countermeasure – nor are you ever going to need one.

The problem?

I think we feel the need to do audits because we have no process to immediately detect, correct and solve the little problems that happen every day. These little issues are the ones that cause the 5S erosion. Because we don’t have a process to deal with them one-by-one, we have to have an elaborate process that disrupts our normal work flow and takes them on in big batches.

Does that sound like a “lean” process to you?

How might we relentlessly drive the “audit” process closer to the ideal of one-by-one confirmation?

That would be “lean thinking.”

 

 

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

Overburdened with Andon Calls

Bryan Zeigler has a great post on his “Lean is Good” blog site. Titled “Andon Calls and Muri,” he describes Toyota’s phenomenal  capacity for responding to problems, and then takes us back to where the rest of us are with some really great questions:

If it is physically impossible to answer every andon call in order to work on every problem, is it best to fix the first one that comes sequentially?  Then do work arounds and rework until we can respond to another one?

I have always used systems to prioritize what problems we work on whether it be pareto charts, value stream maps, or just plain standing in the circle.  Once directions, or as Toyota Kata describes them, process target conditions, are established and the highest priority items are “fixed” and then we move on the the next most important challenge.

Working on all problems in the process would overburden the organization’s problem solvers.  This would be a form of dreaded muri right?  I’ve read and heard much about the Toyota staffing levels required to operate TPS effectively.  Most range from 5 to 7 employees under each level of leadership position.  Again, my experiences are more like 30 to 40 employees under a 1st line leader.

Two questions:

  1. What percentage of daily problems are organizations that you work in staffed to handle?
  2. What philosophies do you utilize to ensure you don’t introduce Muri to the problem solving teammates in the organization?

Great observation, and great questions. And Bryan is certainly not the only one who has had the insight to ask them.

At this point, I have to issue a bit of a disclaimer. I have spent a full day on the shop floor in Bryan’s workplace. I can visualize exactly what he is talking about. Unfortunately schedules didn’t allow me to meet him, but I have a pretty good sense of the situation he is dealing with.

Since pretty much everyone has these issues when they start to contemplate andon calls, let’s start by reviewing the theoretical base, then moving into reality.

The core principle of jidoka is “Stop and respond to every abnormality.” That is what we are trying to do here. This means there must be a clear definition of what is “normal” and what is “abnormal.”

In the strictest sense, if it isn’t clearly defined as “normal” it is ambiguous.

In a system where the most basic fundamental is to define processes, ambiguity is a problem as well. Put another way, “ambiguity” is, by definition, “abnormal.”

So, in effect, we are asking the team member to let us know when anything is not clearly consistent with the defined norms.

The first response to an andon call is to clear the problem. If the “problem” is lack of clarity then deal with that. Replace uncertainty with clarity. Set some kind of an hard criteria for what does, and does not, need your attention. This means take management responsibility for the fact that the problem exists, and you aren’t going to do anything about it right now.

The next step is critical: If you can’t solve it right now, contain it.

“Containing the problem” means establish a temporary standard of some kind. Some kind of action that allows the team member to resume safe, defect free work. You might have introduced some inefficiency into the process, but safety and quality take priority.

And here is the dangerous part. You have the problem more or less under control. You can easily walk away and move on to the next one.

But consider this: You have the tiger in a cage. You are in the cage with it. You have to keep feeding the tiger (with time, resources) so it doesn’t eat your process. The only way to make the tiger go away is to get to the root cause.

This temporary standard does, however, give you a measure of stability. You can organize your problem solving efforts and focus on the ones that are the most critical to you. Meanwhile, however, you are burning resources feeding all of those tigers.

Typically a temporary countermeasure (problem containment) is some adjustment to the process. You have set a new standard work sequence that includes the steps required to keep this problem from affecting customers or escaping downline.

Yes, it is a work-around. But it is one you developed deliberately for a specific reason, until you can get to clearing that issue for good.

As you continue to identify problems and at least get them contained in some way, continue to refine the things you want to call attention to.

First, be explicitly clear on what things must trigger an andon call. These are the things you really want to know about when they happen. For sure it should be any safety issue and any issue that threatens quality. It could be an issue you are currently focused on resolving, such as late parts delivery, an upstream quality issue, a piece of unreliable equipment.

Then establish the time trigger. To do this you need to have three things pretty clear in your mind.

  • A good idea of how long the process is supposed to take.
  • A method for the team member to know when he is behind, and how much.
  • A standard for how much delay you are willing to tolerate. Put another way, how long to are you willing to let the team member get behind before he tells someone? My suggestion here is no more time than you can help him catch up. If he gets further behind than that, you are going to pass the problem to another part of the process downstream in the form of a late delivery.

Now you have some simple rules.

Please try to perform the standard work so we can see any problems with it.

  • If any unsafe condition exists, stop and pull the andon. Wait until we can clear the hazard.
  • Do not knowingly ship bad quality to the next process. Pull the andon so we can come, assess, and decide how we are going to deal with that.
  • If you have this problem, this problem, or this problem, stop and pull the andon so we can come and clear the problem as well as understand it as soon as it happens.
  • If you accumulate any delays longer than xx minutes, pull the andon.

This puts you in control. You get to decide how much excess capacity (how many extra people) to pad delays. You get to decide what problems trigger a call. You get to decide what you can handle.

All I ask is:

  • Do not tolerate unsafe conditions. Always stop the process and always initiate a call.
  • Do not tolerate a process that routinely passes bad quality down stream. Always initiate a call. Don’t put the team member in a position where he has to judge what “good enough” is. Have a hard standard and stick to it.
  • Always thank the team member for bringing problems to your attention. Never discourage an andon call.
  • Never allow an andon call to go unanswered. Set a response time standard, measure it, and apply the same problem solving principles to that.

The other thing I would suggest is a system to manage problem solving. There are some suggestions in this post on morning markets.

The key point is that any problem you decide not to work on has to have some kind of temporary countermeasure incorporated into your expectations. If you do something that adds time, you must allow time for it to be done. Doing otherwise is introducing overburden – or to Bryan’s point, shifting the overburden from your problem solving back to the team member.

If you pay attention to what is really happening, and take management responsibility for all of the problems that the team members encounter, then (and only then) can you set rules about which ones you will, and will not, work on right now.

The hardest part of all of this? It is the “taking management responsibility” part. Getting an effective andon call process into place requires as much (actually more) process discipline in the leader’s ranks as it does on the shop floor. This is discipline not to panic, not to wish problems away, and to respond as though the team member is doing you a favor for calling out a problem vs. causing it.

An andon call process is a vital step toward truly engaging the team members. And it begins the shift from intermittent improvement to continuous improvement.

Posted on

Simple and Easy Processes

In the last post I commented on Ron Popeil’s product development approach – to make the product easy to demonstrate drives making it easy to use, which creates more value for the customer.

Let’s take the same thinking back to your internal customers.

What if, rather than just writing a procedure, you had to go and demonstrate it to the people who had to follow it? What if you had to demonstrate it well enough that they saw the benefit of doing it that way, and could demonstrate it back to you to confirm that they understood it? If you broke down the work and organized it to be easy to demonstrate and teach, would it look any different? (Hmmm. TWI Job Instruction actually sounds a lot like this.) Would you still ask “Why didn’t they just follow the procedure?”

Look at the information displays and the controls on your equipment. Do they provide total transparency that things are working? Or do they abstract and obscure reality in some way? Can your internal customer be sure things are going as expected?

Do controls give clear feedback that they are being set correctly? Are sequences of operations readily apparent?

How many “blinking 12:00” situations do you have out there on your shop floor – things that have been put into place, but nobody uses because nobody can really figure it out?

Come back to the design of the product itself. Is the manufacturing and assembly process apparent, obvious, and as simple as you can make it? Would it be designed differently if you had to demonstrate how to fabricate and assemble it?

How about your administrative processes? I recall, many years ago, a “process documentation process” being taught. In the class they were using “baking cookies” as a demonstration example. Yet the instructors, who presumably were experts, actually struggled trying to show how this works. This “process” was far less clear than they had thought it was when they had simply thought through it. “It did not work on TV.”

Look at your computer programs and their user interfaces. What makes sense to a programmer rarely makes sense in actual use. Watch over someone’s shoulder for a while. Could you easily demonstrate this process to someone else?

Ron Popeil cooks real chickens and real ribs in the production of his infomercials. He does not use contrived or carefully limited demonstration examples. As you look at your examples and exercises, how well do they stand up to the real world application? Can you go out to the shop floor and demonstrate your “product” in actual use?

This post is full of questions, not answers. I don’t have the answers. Only you (can) know how well your processes are engineered.

Design your production system (for product or service) as carefully as you would design the product or service itself.

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

If you want to go faster, stop.

Mark’s post on The Whiteboard tells a pretty common story. The good news is that this company has more business than they can handle. Pretty good results in these times. The bad news is that they are having problems ramping up production to meet the demand. In Mark’s words:

I’m working for a company that is very, very busy. They developed a new process that is the first of it’s kind and have taken the market share away from their competition. But they have not spent enough time making the process robust enough to handle the increase demand and the scrap costs are going out of the roof. Currently about 65K a day. Any suggestions? Our number 1 scrap producer is a machine that can not perform at the same capability as when Engineering did their run off…

At the risk of coming across as flip, the very first thing to do if a machine starts producing scrap material is to shut it down.  It is better to make nothing because that is a cheaper alternative than making stuff you can’t use.

However, it goes deeper than that.

Engineering had done a “run off” (which I presume was a test on theoretical speeds). Now actual performance isn’t meeting expectation. This is a problem.

But let’s rewind a bit and talk about how to manage a production ramp-up. Hopefully it is a problem more people will be having as the economy begins to recover.

Although this is in the context of the machine, exactly the same principles apply to any type of production. Only the context and the constraint changes.

Presumably there was some speed for this machine where it didn’t produce scrap, or the scrap was minimal. Going back to that time, here is what should have happened.

Promise production at the rate the machine is known to support.

Now crank up the speed a bit and see what happens. In the best case, you are overproducing a bit, but you are learning what the machine is actually capable of doing.

Crank it up a little more. Oops, scrap.

STOP!

Because you have been running a little faster than required, you have bought a little time. Understand why that scrap happened. Try to replicate it. Dig into the problem solving. Try to replicate the problem under controlled conditions. LEARN.

Hopefully you can find the cause and fix it.

Try it. Run the machine again, at the faster speed. Scrap? Back around to the “problem solving” cycle. Repeat until you can reliably run at the faster speed without scrap.

Then, and only then, promise the higher rate, because now you can reliably deliver it.

Then notch it up a bit until you encounter the next problem.

This cycle of promising only what you can actually deliver protects the customer while you are pushing the envelop internally to discover the next problem.

The alternative? Make a promise knowing you actually have no clue whether or not you can meet it.

But that’s what they did. So now they are burning a lot of money every day making scrap material.

The same principles apply, however. They are already not delivering what they promised. So throttle things back to the point where they can predict the results, and go from there. Pretending they can run faster than they can is not accomplishing anything other than burning money. Deal with facts, no matter how uncomfortable.

If you make a schedule based on what you wish you could do, you will have a schedule you wish you could meet.

No matter what, each time scrap is produced, the fact must be acknowledged. That allows the immediate response that is framed around a simple question:

“How the hell did this happen?”

Put another way, “What have we just learned about the limits of this process?”

It is only within that framework that you actually get any better. Anything else is relying on luck, and in this case at least, that didn’t work.

Posted on

Looking at the wrong stuff: America’s Best Hospitals: The 2009-10 Honor Roll

This news piece, America’s Best Hospitals: The 2009-10 Honor Roll, originally got my attention because I hoped someone might be actually be paying attention to the things that make a real difference in our national debate about health care.

Unfortunately, it looks like more of the same.

This survey looks at things like technical capability – what kinds of specialty procedures these hospitals can perform, and their general reputation  and then ranks them accordingly.

But where are we asking about the basics?

Which hospitals kill or injure the fewest of their patients? What is the rate of post-operative or other opportunistic infection? How about medication errors? These are the things that all hospitals should be “getting right” and yet the evidence is overwhelming that most don’t. Further, nobody seems to be paying attention to it except tort lawyers.

Now take a look at this post on Steven Spear’s blog, and especially the Paul O’Neal commentary that he links to.

Tell me what makes a “good” hospital?