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.
Comments 23
The best (or ‘worst’, if you like) example of a misconception I have seen was a welding machine that allowed the operator to actually set the Takt Time…
Posted 29 Apr 2010 at 12:33 am ¶hi, Using takt time the number of resources can be calculated. but how to optimize them in case of limited number of available resources.
Posted 29 Jul 2011 at 4:50 am ¶Jyoti -
Posted 29 Jul 2011 at 11:05 am ¶Reducing the resources necessary to produce value is the ultimate goal of kaizen.
The takt time / cycle time calculation tells you what you MUST have to do the job as it is currently done.
If you don’t like what the math tells you, then set a target objective (what cycle time do you NEED?) then apply kaizen / problem solving to hit that target.
good article….helped to understand the concept…Can you brief on throughput …
Posted 24 Aug 2011 at 8:13 am ¶“Throughput” is more ambiguous than “cycle time.”
The Theory of Constraints community has a very specific definition, relating to the rate cash is generated through sales.
But outside of that, you really have to take it in context. In general, “throughput” relates to the output capacity of the system, or a part of the system.
When I am talking about capacity and constraints, I am generally looking at cycle times vs. the required operational takt (the actual rate we are striving to hit when things are running).
Posted 24 Aug 2011 at 5:08 pm ¶Hello,
Posted 03 Sep 2011 at 1:28 pm ¶I am facing a very big issue regarding takt time and cycle time. It would be really great if you could help me solve it. I am currently doing my Master thesis in a company and I am a bit confused with this takt time cycle time ratio.Well the scenario is like this. The company I am doing my thesis is a solar panel manufacturing company.There are 9 different processes involved with both manual station and machine. Each process has a different cycle time and at each process the number of input differs i.e, in the first process there is an input of 11 products which comes out after a specific processing time.At the next step ,which is a manual process, these products are worked on manually and are placed as a batch of four in the third process. Now the problem arises in the third process,where the cycle time is much greater than the takt time. Could you please help me with this situation. I am not able to get a clear picture.
Thanks,
Maria
Maria -
Let’s start with the takt time. That simply defines the one-by-one required rate that each process must deliver to its customer.
Deliver faster than the takt time, and you are using capacity (and spending money) wastefully.
Deliver slower than the takt time and the customer is not getting what they need.
This is over-simplified, but it is the foundational concept.
What you strive to achieve is the closest possible balance between cycle time and takt time. The closer that balance, the more efficient your production process.
Now, let’s look at situations where the cycle time is much longer than the takt time.
Let me use automobile manufacturing as an example.
If I look at the high-level process steps for assembling a car, they are:
Stamping
Welding
Painting
Assembly
The takt time on an automobile line is typically about 55 seconds.
Obviously it take longer than 55 seconds to assemble a car.
It actually takes about six hours.
So “assembly” as a process step is MUCH longer than the takt time, about 400 times longer.
So they break up “assembly” into small sub-steps, each taking a tiny bit less than 55 seconds.
Looking at your process #3, the question is: If they took in ONE item, and processed it all the way through, how long would it take?
Divide that time by the takt time.
The result is the number of stations or work zones, units of work-in-process, that are necessary in that process for them to make the takt time.
In other words, if the takt time is 5 minutes, and it takes 20 minutes to perform the process, they need to be working on four of them at once, each at different stages of the process.
They COULD also run batches of four, cycling one batch every 20 minutes, and that would make the output, but it introduces other problems into the flow that we want to try to eliminate.
If this isn’t clear enough, feel free to click on the “Contact Mark” link on the right sidebar. That sets you up to email me directly, and we can get specific about your situation.
Mark
Posted 03 Sep 2011 at 1:49 pm ¶hi,
can you help me hoe to calculate cycletime?
and what are the rating factor i can give.
and now i will calculate :
Standard time=(normal working time*rating factor*operator efficiency) normal working time is : stage wise process time and rating factor is iwll give 10% and operator efficiency is 80% this type i will callculate.
this correct. can give me the ratting factor details. and manual work how much efficiency i can give and then machine works means how much EFF i can give & welding workers how much EFF i can give please need to send me the details in my mail ID :
Posted 13 Oct 2011 at 12:06 am ¶Replied by direct email about the difference between traditional industrial engineering calculations (with efficiency factors, etc) and the TPS approach.
Efficiency factors are really inefficiency factors. They are saying, in effect, that there are aspects of this process that we simply cannot understand, therefore we will lump them together and just accept them.
TPS takes the opposite approach. By rigidly specifying every detail of how the process should operate (PLAN), and then setting up built-in “CHECKS” that compare actual vs. intended, we surface the issues that we did not understand.
In other words, “Chatter is Signal.”
Ironically, we know that we will be wrong nearly every time. But only if we try to be as “right as we can” will we learn what we did not know.
Posted 13 Oct 2011 at 12:54 am ¶hi,should the OEE be taken into account while calculating takt time???
Posted 17 Oct 2011 at 5:54 am ¶like:: takt time =(available time*OEE)/demand
Arjun –
There are a couple of answers to your question.
When determining the overall takt time for the value stream – the customer takt time- no.
But realistically, if the machine is not operational 100% of the time, then you need to run it faster when it IS operational if you want to make the production numbers.
OEE has a number of components, some of them are planned down time (tools changes, changeovers, planned maintenance, etc) others are unplanned (slowdowns, stoppages, etc).
As you account for these factors, you subtracting from available time.
Just multiplying by OEE is the simplest solution, but this is like the issue with “efficiency factors” that I discussed in a previous comment on this topic.
What I suggest is breaking down the losses separately.
Planned maintenance time
Tool changes
Changeovers
Things like the above are planned, you know when they will happen.
I would account for their impact on production by subtracting a pro-rated factor from available time.
Note: I would discourage multiplying anything by a percentage. You need to know how much actual time you are taking away from production.
Then, of course, you also need to plan these activities and develop a way to work out how much time is ACTUALLY spent vs. how much time you planned on spending, and apply kaizen to these tasks. Any improvement goes straight to machine capacity.
Unplanned stoppages and slowdowns are a little trickier because you don’t know when they will happen.
And how you handle them realistically depends on how you are approaching maintenance.
A sadly high number of operations just use OEE as a blanket factor, but don’t have an active program to raise it (i.e. aggressive TPM).
They are the ones who just factor in the downtime and build the rest of their processes to accommodate it.
If you do have a good TPM program, then you set your system to run a little better than you CAN. You factor in some, but not all, of the problem(s).
That becomes your operational takt time (or your target cycle time). You have a “line stop” situation whenever your process exceeds this planned cycle time.
You respond to the problem, determine what caused it, fix it, eliminate the root cause, and try again.
If you do it that way, eventually you will be running smoothly at the planned time.
That is time to reduce your factor again, and flush out more problems.
Doing it this way assures you meet the overall takt time, gives you time to work on problems, and drives you to get better.
Posted 17 Oct 2011 at 11:43 am ¶However it requires you to have good visual controls and know, at any time, the exact status of the equipment:
- Should it be running?
- Is it running?
- How fast should it be running?
- How fast is it running?
Hi,
Help me to calculate the cycle time and takt time for an assembly line and packing line where 10000 units will be assembled/8hrs with 20 members and the same 10000 units will be packed/8hrs with 30 members.
Also, help me how to reduce my takt time or speeding up my takt time. Pl send me the details to my mail ID.
Posted 25 Oct 2011 at 9:56 am ¶Replied by email.
Key points:
This takt time is somewhat less than 3 seconds, which is really too fast for a single line if the work is mostly manual. You run the risk of repetitive motion injuries as well as other problems.
If the work is mostly automated, then I would suggest a “pitch” calculated around about 100 units of production to take the time into a more human scale.
You can establish a “target cycle time” but otherwise, cycle time must be measured in the actual operation.
Posted 25 Oct 2011 at 8:45 pm ¶The number of people required is calculated by total cycle time / takt time.
Hi Mark, thanks for ur reply on my query..
Posted 30 Oct 2011 at 5:29 am ¶i need to know the difference between Efficiency and Productivity.
Outside of traditional industrial engineering / accounting factors, there really aren’t formal definitions for these terms.
“Productivity” is generally calculated as some form of Units of Output / Units of Resources Input, so you could have “units produced / person” for example.
“Efficiency” is generally some measure of the “resources actually used productively / total resources available”
Using either of these to measure people’s job performance is generally destructive to the goals of the organization.
Posted 30 Oct 2011 at 7:23 pm ¶It is better to use any measures as a way to determine how effective your improvements and problem solving activities are.
I am having an issue with both Takt Time and cycle Time if my Actual takt time is 16.9 seconds per unit and my daily goals are 1498, with just 3 operators how many units per minute should we be building as a finished product? I personally would like to see at least 5 per minute but some say that I might be pushing my employees to hard? Please help
Posted 15 Nov 2011 at 2:13 am ¶The number of team members is not a factor in determining takt time.
If your takt time is 16.9 seconds, that works out to 3.6 units / minute of required production.
If you are building faster than that, you are overproducing.
Posted 15 Nov 2011 at 11:42 am ¶I wanted to thank you for your extremely fast reply and also how exactly did you figure the 3.6 per minute? what is the actual calculation I should use for this?
Posted 16 Nov 2011 at 1:17 am ¶Jason -
Dividing a minute by your takt time gives “takt times per minute.”
Since 1 takt time = one unit of production (by definition):
If the takt time is 60 seconds, then you make one unit / minute.
If the takt time is 15 seconds, then you make four units / minute.
60 seconds / 16.9 seconds = 3.55 ~ 3.6
Posted 16 Nov 2011 at 5:54 am ¶Thank You Mark Great Information.
Posted 18 Nov 2011 at 10:46 am ¶How do we Account for Downtime that is not in the equation for Takt Time?
Is there a way to improve our Efficiency with the help of Takt time if so, it probably does require to overproduce right?
Also If say you have a machine in which seems to be non operational or you are constantly fighting to keep it running and no means to justify the cost for a new one can we still then use Takt Time to acquire our Goals?
If not why then is Takt time being viewed as a great component of production?
It may be a very good theory but while using this I find it extremely difficult to motivate employees whom simply view this as a means to stop them from getting an early weekend without having to use vacation or personal, yes I believe personally takt time is great tool for helping eliminate injuries but at the same time it brings down employee morale Im not quite sure how my employees view this as bringing their morale down except they cant get done faster than they would like too…Could you please help me understand better why they think this???Confused!!!!
Posted 07 Dec 2011 at 10:33 am ¶Jason -
If your equipment reliability is keeping you from producing to takt time, then it is telling you that you need to work on making the equipment more reliable (certainly not just buying new). There is an entire field of work called “TPM” that is about nothing but equipment reliability. It can be advanced stuff, though, and I don’t know your specific application.
On the other hand, if your team finishes early (I think you said you had three people) in spite of the unreliable equipment, then I have to ask “Do you have things you wish someone could help you with, but you can’t afford to hire any one else?” If the answer to that is “yes” then where your efficiency comes in is to work hard to get enough wasted motion out of the work that you only need two people to get a unit out every 3.6 minutes. (From your other notes, right now I assume you think you need three). Where takt time helps with efficiency is by letting you calculate how many people you SHOULD need if you had fewer problems, then you can work on some of those problems to get the actual work to match.
This is a topic that has books written about it, so I really can’t do justice to it in a short comment here. My first suggestion is to pick up a decent book about “lean production” and work to get the basics down. That should help you have better context for your questions as well as the answers. “Toyota Kata” by Mike Rother may be a little advanced for a beginner, but it does have good concepts that directly relate to the questions your are asking.
Posted 07 Dec 2011 at 7:33 pm ¶Your knowledge astounds me! Thnx again Mark
Posted 08 Dec 2011 at 7:49 am ¶Trackbacks & Pingbacks 1
[...] Takt Time – Cycle Time dal blog The Lean Thinker di Mark Rosenthal: Una bellissima discussione sul significato di takt time, cycle time e lead time (traduzione automatica) [...]
Post a Comment