Tag: Pacing

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

Shingijutsu Kaizen Seminar – Day 3

Yesterday I told you the plan for today. Here is what really happened.

We got the even pitch going for a while. I was at the front of the line releasing units down the line as the pre-build Team Member was done with them. I was watching distance (since distance = time on a moving line). As the previous unit hit the pitch first pitch line, I launched the next. One of the little discoveries was that the conveyor has a “slow spot” that really changes the speed. Oh – and that happens to be when we measured the speed yesterday. Net result? The units were actually fired down line about 10% faster than they should have been. Oops.

Next discovery? Nobody noticed. So much for this great labor bottleneck. There were line stops, but they had nothing to do with this.

In the first position, our experiment to actually present parts at the point of use cut the team members’ work cycle. How much depends on the situation. His work cycle previously varied all over the place – easily by 100% or more when he had to go look for parts and wasn’t sure where they were.

By simply stabilizing his work, we cut his cycle time to well under the takt.

We ended up not recording line stops, but on the other hand, there weren’t any actual andon calls today. That is both good news – nothing we did really disrupted things – and bad news – their system has serious issues, and none of them trigger andon calls.

The kaizen team members studying the semi-automated test operation designed and proved a work sequence that not only handled this bottleneck process, they cut it nearly in half. It can be done well under the takt time if the Team Member and supervisor don’t panic and try to work ahead. If they do, it disrupts everything for two or three units. To “pay” for this improvement, the kaizen team members shifted a (very) small amount of work to the next position down line. All he has to do is disconnect the test equipment. That gives our team member of focus the time to start the next unit right away. Disconnection takes only a few seconds, and easily fits into the work cycle of this team member.

Another sub-team worked on the sub-assembly process with similar results to the first team. By actually making sure all of the parts are present and presented well, the terrifically unstable cycle started to get consistent. There is a lot of work here, and honestly I think the best solution is to break up the sub-assembly cell and get these processes operating right next to the assembly line. There are huge advantages in information flow (they could just look upline by two units and see what they needed to start next). There are huge advantages in material conveyance – there isn’t any. Quality issues would be spotted immediately and could be addressed immediately. Lots of other advantages as well.

This evening we worked on the final report-out. Since this is a Shingijutsu event, there is a fairly rigid pattern for how these report-outs should go. The team spent until about 10:30 working on it and having it reviewed by sensei. I think we got off pretty clean in that department since I already knew the drill, coached the team on what was important plus sensei knows me from past events. I have seen draft report-outs thrown across the room in the past – not especially effective communication in the details, but the big picture, “this is not acceptable,” gets across fairly clearly. That didn’t happen this time. I think Shingijutsu as a company, is mellowing out a little. It is too hard to actually say, but time will tell.

Posted on

Be A Perfect Supplier; Be A Perfect Customer

Operations that work to the “push” are well known for complex and interdependent problems. What looks like a problem in one area often has causes, or parts of causes, in other areas. Quality problems, delivery problems (late, too much, too little, wrong stuff), sub-optimizing attempts to reduce local cost.. all of these things propagate unchecked through the plant. To fix one area means having to fix almost all of the others at once. This initial improvement gridlock is pretty common.

When you start talking about implementing JIT in an environment like that, the pushback is visceral and, to be honest, legitimate. The only reason they get anything done is because the system runs to sloppy tolerances and doesn’t expect much. JIT demands a degree of mutual vulnerability, at least it seems that way when it is first presented.

The other really big psychological issue is that lean is often presented as a solution to all of these problems. Quite correctly, the survivalist shop floor supervisors don’t see that. And they are right. The problems do not go away when you implement flow. I sometimes find it surprising how many people don’t get that. All they see is fewer problems in operations that have flow, and they mix up cause and effect. Good flow is the result of solving the problems. Not the other way round, but I digress.

If you are dealing with this problem gridlock, where do you start? The first step is to contain the problems as close as possible to their sources.

The objective is to apply what temporary countermeasures are necessary to appear as a perfect supplier to your downstream customers; and the appear as a perfect customer to your upstream suppliers.

So what is a “perfect supplier?” That is probably the easier of the two logical questions to answer. A perfect supplier is capable of supplying what you need; when you needed it; with perfect quality; one-by-one; at takt.

What is a “perfect customer?” This one is a little harder, but it is good to look back at what makes a perfect supplier. Ask yourself – what things does the customer do that makes it difficult to be a good supplier? What does a bad customer look like?

  • They order or demand things in batches.
  • They give no advance notice about what they need.
  • Their demand is unpredictable and inconsistent.

A lot of this seeming unpredictability actually originates in the supplying process. I recall a case where the manager of a fabrication shop swore that his customer’s demands were totally random. At the assembly plants, though, they operated to takt with a steady mixed-model schedule. There was very little change from one day to the next. Why the big disconnect? The fabrication ship ran things in big batches, and set up big batch pull signals. Naturally those big batch pull signals would go a long time between trigger points, so they would seem to come back at arbitrary times, for huge amounts. Self-inflicted gunshot wound. Once they took the simple step of shipping things in smaller containers, a lot of that seeming instability went away. Smaller containers meant more frequent releases of pull orders, which gave them a cleaner picture of the demand picture. Think of it this way: The smaller the pixels on your screen, the more resolution you have in the image.

So that does the perfect customer look like? Level, predictable demand at takt with no major fluctuations.

Think of the purpose of heijunka or leveling production. Because customer demand arrives in spikes, batches, lumps, the leveling process is necessary to make that demand appear to be arriving exactly at takt time.

Although the books, such as Learning To See say there is only one pacemaker process or scheduling point, non-trivial flows frequently require re-establishing the pulse.

This is especially true if orders are batched up either through the ordering process itself or the delivery process. An example of this is a manual kanban process between an assembler and the supplier. Even though there is a paced assembly line and good leveling, kanban cards are collected and delivered to the supplying process in transportation-interval “chunks.” The supplier needs to have their own heijunka board to re-level the demand and pick at takt from the supermarkets. The alternative is that the demand arrives at the production cells in those same batches, and the smooth takt image is lost.

In a Previous Company we were working a project to establish pull on a trans-continental value stream that had five major operations, all in different geographic locations. To use the word “monument” does not even begin to describe the capital infrastructure involved, and there were a lot of these assets shared with other value streams, so relocating and directly connecting flows was out of the question. There were unreliable processes, big batches, transportation batches, end-using customers’ orders in huge, sudden surges based on their surge based business cycle. Step by step we isolated inventory buffers and ended up putting in heijunka to re-level the demand at nearly every stage of the process. It was big, ugly, cumbersome, but it worked to isolate problems within a process vs. pass them up and down stream.

The objective was simple: Use inventory buffers and heijunka to make each process in the chain appear as a perfect customer to its suppliers – always pulling exactly at takt. The consuming process “owned” the inventory buffers necessary to do this. Reason: Simple. The problems that cause them to be a less-than-perfect customer are theirs, so they own the inventory that is necessary to protect their suppliers from those problems. Likewise, that process owned whatever inventory was necessary them to appear to be a perfect supplier. They had to enable their customer to pull one-by-one, exactly at takt, from them, even if their problems kept them from producing that way.

Never mind that the downstream process didn’t actually consume at takt. THEIR inventory buffer translated their spiky signal into one which reflected the takt time.

All of this was very sophisticated and complicated, but in the long haul it worked. Megabucks of inventory came out of the system. Megabucks remained, but we knew exactly why it was there, and who had to solve what problems to reduce it.

If you can’t be a perfect customer, create the illusion that you are.

If you can’t be a perfect supplier, create the illusion that you are.

Then you own the problems yourself, you own the inventory-consequences of having those problems, and you control your own destiny.

Posted on

Takt Time and Leveling – What’s The Point?

A few days ago I wrote about asking “What is your takt time?” and the likely responses to that question. But in my list of common responses, I left one out – “What’s the point? We get everything out by the time the truck leaves.”

Here’s a real-life example: In a high-volume consumer goods factory we had a daily transportation cycle. Shipments left once a day. Parts and materials arrived once a day. Although the operation was not without its glitches, the process itself incorporated a lot of automation (another story entirely), and the time through the machinery was pretty quick.

We were trying to implement the production leveling (heijunka) into the enterprise flow between the factory and the distribution system. While the mechanics were very straight forward, leveling the model mix during the course of the day encountered a logical question: What’s the point?

And what is the point? With or without model-mix leveling the same stuff ended up on the truck at the end of the day, and the total amount of inventory in the factory was not going to dramatically change. So why go through the trouble, especially of working changeovers on the packaging equipment, when there was apparent no net effect?

The question is a logical one until we understand that takt time (or pitch in this case) is not a production quota. It is part of a standard.

What’s so important about standards?
Without a standard, you can’t detect a problem.

Daily management is about rapidly detecting, correcting and solving problems. This is much easier to do when dealing with small problems before they grow into big ones.

The “What’s the point?” question even gets asked in the course of many lean manufacturing implementations. The operation reaches a level of performance that is “good enough” – for example, everything makes it onto the truck by the end of the day – and they are satisfied with that level of performance. This is when continuous improvement stops.

Have all of the problems been solved? Has all of the waste been removed? Of course not. But the next level of problems, and therefore the next level of performance, is under the radar.

In the factory I described above they had more demand than they could handle. They were already working 24/7, and were working to add capacity. They wanted to speed up the automation, and possibly even add additional lines. Yet, during the course of a day:

  • They lost many units to defects.
  • The lost production to machine stoppages and slow-downs.
  • They had part shortages and frequently substituted one product for another in the shipments, and made it up tomorrow.
  • Because they were “behind” they relentlessly kept the lines running, only to find defective product in final inspection.

The list goes on. They are all familiar things.

So what is the point of applying leveling product mix and establishing the discipline of a takt time or pitch?

Honestly, there isn’t any point unless they also implement a leadership process to immediately call out and respond to any slippage or deviation from the intended pace and sequence of production.

So – what started out as a question about a common tool or technique in the TPS has come around to what the core issue really is when that “What’s the point?” question is asked: Lean manufacturing is not about the tools and techniques. It is a system to assist a proactive leadership culture that is almost obsessed with finding and fixing the problems that keep them from achieving perfect safety, perfect quality, perfect flow, with zero waste.

A “problem” is any deviation from the standard. (And if you don’t have a standard, that is a problem.)

Two key questions:

Are we meeting the standard? If the answer is “yes” then:

Are we looking at perfection?

One or the other of those questions is going to drive you to address the next level of problems.