More Cycle Time Questions from Search Results

A couple of more exam questions showed up in search results.

4. what can happen if the cycle time is much shorter than the takt time

The searcher didn’t even bother typing this one – just cut and paste the entire thing, including the question number.

Fortunately the answer is really easy:

Raiders of the Lost Ark warehouse

If you keep this up, you’ll need another building.

OK, here’s one that is a little more subtle:

185 units in 14 hours is what cycle time

Hmmm. My first thought is to go back to Who is Grading the Questions?

think whoever wrote this question is looking for something like 14 hours  (840 minutes) / 185 units = 272 seconds / unit (more or less). But that’s an average, it isn’t a cycle time.

The Average Rate of Output is not “Cycle Time.”

The average doesn’t give you any more information than the original question. This is simply a rate of output: 185 units in 14 hours. Cycle time is the measured time to complete one cycle.

There might be a single cycle that produces a batch of 185 units. Let’s say, for example, in a cure oven process that takes 14 hours to load, run and unload. Then the cycle time is 14 hours.

If the pieces are moving in a sequence of operations, but in a lot (which is different from a batch), where Operations 1 is completed on all 185, then Operation 2 is completed on all 185, etc. and maybe that all takes 14 hours? I have no idea what the cycle time(s) for the operations are. Most of the time the units are waiting in queue for the other 184 items to be done at each operation.

If we have true one-by-one flow then I have at least 185 cycle times. Hopefully they are all about the same, but likely that isn’t the case.

Are we measuring exit cycles (the cadence of output at the end of the process), or operator or machine cycle times?

By taking the average we are obscuring all of this information. Calling the average the “cycle time” just makes it worse because it gives people the impression that they are the same.

Cycle time is not calculated. It is measured. You cannot determine cycle time by applying mathematical operations on numbers. You have to go observe with a stopwatch.

And finally:

within each four hours worked, workers can take a total of 48 minutes in allowance (so allowance factor is based on workday). if the observed time is 6 minutes, and performance rating is 95%, what is the standard time (in minutes; give three significant digits after the decimal point)?

Even if I could understand the question, down to thousandths of a minute? Seriously?

</rant> <!– Until next time –!>

 

 

Using Takt Time to Compute Labor Cost

How can I use takt time in computing labor cost?

Sometimes the searches that lead here give us interesting questions.

While simple on the surface, this question takes us in all kinds of interesting directions.

Actually the simplest answer is this: You can’t. Not from takt time alone.

Takt Time

Takt time is an expression of your customer’s requirement, leveled over the time you are producing the product or service. It says nothing about your ability to meet that requirement, nor does it say anything about the people, space or equipment required to do it.

Cycle Time

Cycle time comes in many flavors, but ultimately it tells you how much time – people time, equipment time, transportation time – is required for one unit of production.

Takt time and cycle time together can help you determine the required capacity to meet the customer’s demand, however they don’t give you the entire story.

In the simplest scenario, we have a leveled production line with nothing but manual operations (or the machine operations are trivially short compared to the takt time).

If I were to measure the time required for each person on the line to perform their work on one unit of the product or service and add them up, then I have the total work required. This should be close to the time it would take one person to do the job from beginning to end.

Let’s say it takes 360 minutes of work to assemble the product.

If the takt time says I need a unit of output every 36 minutes, then I can do some simple math.

How long do I have to complete the next unit?  36 minutes. (the takt time)

How long does it take to complete one full unit?  360 minutes (the total manual cycle time)

(How long does it take) / (How long do I have) = how many people you need

360 minutes of total cycle time / 36 minutes takt time = 10 people.

But this isn’t your labor cost because that assumes the work can be perfectly balanced, and everything goes perfectly smoothly. Show me a factory like that… anywhere. They don’t exist.

So you need a bit more.

Planned Cycle Time (a.k.a. Operational Takt Time and “Actual Takt”)

How much more? That requires really understanding the sources of variation in your process. The more variation there is, the more extra people (and other stuff) you will need to absorb it.

If we don’t know, we can start (for experimental purposes) by planning to run the line about 15% faster than the takt time. Now we get a new calculation.

85% of the takt time = 0.85 x 36 minutes = ~31 minutes.  (I am rounding)

Now we re-calculate the people required with the new number:

360 minutes required / 31 minutes available = 11.6 people which rounds to 12 people.

Those two extra people are the cost of uncontrolled variation. You need them to ensure you actually complete the required number of units every day.

“But that cost is too high.”

Getting to Cost

12 people is the result of math, simple division that any 3rd grader can do. If you don’t like the answer, there are two possible solutions.

  1. Decide that 360 / 30 = something other than 11.6 (12). (or don’t do the math at all and just “decide” how many people are “appropriate” – perhaps based on some kind of load factor. This, in fact, is a pretty common approach. Unfortunately, it doesn’t work very well for some reason.
  2. Work to improve your process and reduce the cycle time or the variation.

Some people suggest slowing down the process, but this doesn’t change your labor cost per unit. It only alters your output. It still requires 360 minutes of work to do one unit of assembly (plus the variation). Actually, unless you slow down by an increment of the cycle time, it will increase your labor cost per unit because you have to round up to get the people you actually need, and/or work overtime to make up the production shortfall that the variation is causing.

So, realistically, we have to look at option #2 above.

This becomes a challenge – a reason to work on improving the process.

Really Getting to Cost

Challenge: We need to get this output with 10 people.

Now we have something we can work with. We can do some more simple math and determine a couple of levers we can pull.

We can reverse the equation and solve for the target cycle time:

10 people x 30 minute planned cycle time-per-unit = 300 minutes total cycle time.

Thus, if we can get the total cycle time down to 300 minutes from 360, then the math suggests we can do this with 10 people:

300 minutes required / 30 minutes planned cycle time = 10 people.

But maybe we can work on the variation as well. Remember, we added a 15% pad by reducing the customer takt time of 36 minutes to a planned cycle time (or operational takt time, same thing, different words) of 30 minutes. Question: What sources of instability can we reduce so we can use a planned cycle time of 33 minutes rather than 30?

Then (after we reduce the variation) we can slow down the process a bit, and we could get by with a smaller reduction in the total cycle time:

330 minutes required / 33 minutes planned cycle time = 10 people.

(See how this is different than just slowing it down? If you don’t do anything about the variation first, all you are doing is kicking in overtime or shorting production.)

So which way to go?

We don’t know.

First we need to really study the current process and understand why it takes 360 minutes, and where the variation is coming from. Likely some other alternatives will show themselves when we do that.

Then we can take that information, and establish an initial target condition, and get to work.

Summarizing:

  • You can’t use takt time alone to determine your labor cost. Your labor cost per unit is driven by the total manual cycle time and the process variation.
  • With that information, you can determine the total labor you need on the line with the takt time.
  • None of this should be considered an unalterable given. Rather, it should be a starting point for meeting the challenge.

And finally, if you just use this to reduce your total headcount in your operation, you will, at best, only see a fraction of the “savings” show up on your bottom line. You need to take a holistic approach and use these tools to grow your business rather than cut your costs. That is, in reality, the only way they actually reach anywhere near their potential.

 

 

 

Another Homework Question

Another interesting homework question has shown up in the search terms. Let’s break it down:

23. if the slowest effective machine cycle time in a cell is 55 seconds and the total work content is 180 seconds, how many operator(s) should operate the cell so that labor utilization is at 100%?

I find this interesting on a couple of levels.

At a social level, the idea of cutting and pasting a homework question into Google hoping to find the answer is… interesting. Where is the thinking?

What are we teaching?

The question is asking “How many people do we need to run as fast as we can?” (as fast as the slowest machine). But how fast do they need to run? Maybe they only need a part every 95 seconds. If that is true, then I need fewer people, but I am going to run the slowest machine even slower.

In other words, “What is the takt time?” What does the customer need? How often must we provide it?

Then there is the “labor utilization” metric, with a target of 100%. Assuming the planned cycle time is actually 55 seconds (which it shouldn’t be!), we need 3.3 people in this work cell. (180 seconds of labor cycle time / 55 seconds planned cycle time: “How long does it take?” / “How long do you have?” = Minimum Required Capacity)

How about improvement? What do we need to do to get from 3.3 people to 3 people? We can solve for the labor cycle time.  55 seconds of planned cycle time * 3(people) = 165 seconds of total labor. So we need to get that 180 seconds down to a little less than 165 seconds.

Now we have a challenge. We need to save a bit over 15 seconds of cycle time. That might seem daunting. But we don’t have enough information (the current condition) to know where to begin. Then we can establish the next target condition and get started making things better.

These types of questions bother me because they imply all of these things are fixed, and they imply we run “as fast as we can” rather than “as fast as we must.”

Edit: Today I saw two more searches for:

total work content divided by slowest machine cycle time

so it looks like at least two others are working on the same assignment.  🙂

Thoughts?

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.

Taktzeit

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

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

All of this had been anecdotal.

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

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

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

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

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

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

 

By the way, just to put things into perspective:

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

Takt Time – Cycle Time

There has been an interesting discussion thread on “Kaizen (Continuous Improvement) Experts” group on LinkedIn over the last few weeks on the differences between takt time and cycle time.

This is one of the fundamentals I’d have thought was well understood out there, along with some nuances, but I was quite surprised by the number (and “quality”) of misconceptions posted by people with “lean” and “Sigma” in their job titles.

I see two fundamental sources of confusion, and I would like to clarify each here.

“Cycle Time” has multiple definitions.

“Cycle time” can mean the total elapsed time between when a customer places an order and when he receives it. This definition can be used externally, or with internal customers. This definition actually pre-dates most of the English publications about the Toyota Production System.

It can also express the dock-to-dock flow time of the entire process, or some other linear segment of the flow. The value stream mapping in Learning to See calls this “production lead time” but some people call the same thing “cycle time.”

In early publications about the TPS, such as Suzaki’s New Manufacturing Challange and Hirano’s JIT Implementation Manual, the term “cycle time” is used to represent what, today, we call “takt time.” Just to confuse things more, “cycle time” is also used to represent the actual work cycle which may, or may not, be balanced to the takt time.

We also have machine cycle time, which is the start-to-start time of a machine and is used to balance to a manual work cycle and, in conjunction with the batch size,  is a measure of its theoretical capacity.

“Cycle time” is used to express the total manual work involved in a process, or part of a process.

And, of course, “cycle time” is used to express the work cycle of a single person, not including end-of-cycle wait time.

None of these definitions is wrong. The source of confusion is when the users have not first been clear on their context. Therefore, it is critically important to establish context when you are talking. Adjectives like “operator cycle time” help. But the main thing is to be conscious that this can be a major source of confusion until you are certain you and the other person are on the same wavelength.

Takt time is often over simplified.

The classic calculation for takt time is:

Available Minutes for Production / Required Units of Production = Takt Time

This is exactly right. But people tend to get wrapped up around what constitutes “available time.” The “pure” definition is usually to take the total shift time(s) and subtract breaks, meetings, and other administrative non-working time. Nobody ever has a problem with this. (Maybe because that is the way Shingijutsu teaches it, and people tend to accept what Shingijutsu says at face value.)

So let’s review and example of what we have really done here. For the sake of a simple discussion, let’s assume a single 8 hour shift on a 5 day work week. There is a 1/2 hour unpaid lunch break in the middle of the day, so the workers are actually in the plant “at work” for 8 1/2 hours. (this is typical in the USA, if you are in another country, it might be different for you)

So we start with 8 hours:

8 hours x 60 minutes = 480 total minutes

But there is a 10 minute start-up process in the morning, two 10 minute breaks during the day, and 15 minutes shut-down and clean up at the end of the shift for a total of 45 minutes. This time is not production time, so it is subtracted from “available minutes”:

480 – 45 = 435

A very common mistake at this point would be to subtract the 30 minute lunch break. But notice that we did not include that time to start with. Subtracting it again would count it twice.

So when determining takt time, we would use 435 minutes as the baseline. If  leveled customer demand was 50 units / day, then the takt time would be:

435 available minutes / 50 required units of production = 8.7 minutes (or 522 seconds)

Note that you can just as easily do this for a week, rather than a day.

435 minutes x 5 days = 2175 total available minutes

2175 available minutes / 250 required units of production still equals 8.7 minutes (or 522 seconds)

All of this is very basic stuff, and I would get few arguments up to this point, so why did I go through it?

Because if you were to run this factory at a 522 second takt time, you will come up short of your production targets. You will have to work overtime to make up the difference, or simply choose not to make it up.

Why? Because there are always problems, and problems disrupt production. Those disruptions come at the expense of the 435 minutes, and you end up with less production time than you calculated.

Then there is the fact that the plant manager called an all-hands safety meeting on Thursday. That pulled 30 minutes out of your production time. Almost four units of production lost there.

I could go on with a myriad of examples gathered from real production floors, but you get the idea.

Here is what is even worse, though.

When are you going to work on improvements?

If you expect operators to do their daily machine checks, when do you expect that to happen?

Do you truly expect your team members to “stop the line” when there is a problem?

All of these things take time away from production.

The consequence is that the shop floor leadership – the ones who have to deal with the consequences of disrupted production – will look at takt time as a nice theory, or a way to express a quota, but on a minute-by-minute level, it is pretty useless for actually pacing production.

All because it was oversimplified.

If you expect people to do something other than produce all day, you have to give them time to do it.

Let’s get back to the fundamental purpose of takt time and then see what makes sense.

The Purpose of Takt Time

Here is some heresy: Running to takt time is wholly unnecessary. Many factories operate just fine without even knowing what it is.

What those factories lose, however, is a fine-grained sense of how things are going minute by minute. Truthfully, if they have another way to immediately see disruptions, act to clear them, followed by solving the underlying problem then they are as “lean” as anyone. So here is the second heresy: You don’t NEED takt time to “be lean.”

What you need is some way to determine the minimum resource necessary to get the job done (JIT), and a way to continuously compare what is actually happening vs. what should be happening, and then a process to immediately act on any difference (jidoka). This is what makes “lean” happen.

Takt time is just a tool for doing this. It is, however, a very effective tool. It is so effective, in fact, that it is largely considered a necessary fundamental. Honestly, in day to day conversation, that is how I look at it. I made the above statements to get you to think outside the mantras for a minute.

What is takt time, really?

Takt time is an expression of your customer demand normalized and leveled over the time you choose to produce. It is not, and never has been, a pure customer demand signal. Customers do not order the same quantity every day. They do not stop ordering during your breaks, or when your shift is over. What takt time does, however, is make customer demand appear level across your working day.

This has several benefits.

First, is it makes capacity calculations really easy through a complex flow. You can easily determine what each and every process must be capable of. You can determine the necessary speeds of machines and other capital equipment. You determine minimum batch sizes when there are changeovers involved. You can look at any process and quickly determine the optimum number of people required to make it work, plus see opportunities where a little bit of kaizen will make a big difference in productivity.

More importantly, though, takt time gives your team members a way to know exactly what “success” looks like for each and every unit of production. (assuming you give them a way to compare every work cycle against the takt time – you do that, don’t you?)

This gives your team members the ability to let you know immediately if something is threatening required output. Put another way, it gives your entire team the ability to see quickly spot problems and respond to them before little issues accumulate into working on Saturday.

The key point here is that to get the benefit, you have to have a takt time that actually paces production. It has to be real, tangible, and practically applied on the shop floor. Otherwise it is just an abstract, theoretical number.

This means holding back “available time” for various planned (and unplanned) events where production would be stopped.

Further, in a complex flow, there may be local takt times – for example, a process that feeds more than one main line is going to be running to the aggregated demand, and so its takt will be faster than either of them. Likewise, a feeder line that builds up a part or option that is not used on every unit is going to be running slower.

And finally if disruptions do cause shortfalls to the required output, you have to make it up sometime. If you are constrained from running overtime (and many operations are for various reasons), then your only alternative is to build a slight over speed into your takt time calculation. The nuances of this are the topic of a much longer essay, but the basics are this:

– If everything goes well, you will finish early. Stop and use the time for organized improvement of either process or developing people. Continuing to produce is overproduction, and just means you run out of work sooner if you have a good day tomorrow.

– If there are issues, the use the buffer time for its intended purpose.

– If there are more issues than buffer time, there is an operational decision to make. Have a policy in place for this. The simplest is “hope for a better day tomorrow” and use tomorrow’s buffer time to close the gap. If this isn’t enough, then a management decision about overtime or some other remedy is required.

What about just allowing production to fall short? Well.. if this is OK, then you were running faster than customer demand already. So pull that “extra” out of your schedule, stop overproducing (which injects its own disruptions into things), and deal with what just actually have to accomplish. Stop inflating the numbers because they hide the problems, the problems accumulate, and you end up having to inflate even more.

Gee, all of this seems complicated.

Yeah, it can be. But that complexity is usually the result of having an ad-hoc culture that makes up the reactions as you go along rather than a comprehensive thought-out systems-level approach. The key is to work through the “what if…” for what you are doing and thinking about doing, how the pieces actually interconnect and interact, and have a plan.

That plan is the first part of Plan-Do-Check-Act.

Then, as the real world intrudes, you can test your thinking against reality and get better and better rather than just being glad you survived another day.

And that, is the whole point of knowing your cycle times and takt times.

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.

  4. Why does the gap exist?”
  5. “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.

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.

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.

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.