How to Measure Cycle Times – Part 1

The cycle time of a process is a key to match the supply with the demand in lean manufacturing. Everybody working on a shop floor knows the term. Yet, I still find that people sometimes confuse what exactly it means. The cycle time is the fastest repeatable time in which you can produce one part. Hence, in this post as part of a series on manufacturing speed measurements I would like to dig deeper into what cycle times really are, and how to best measure them. As it turns out, there is actually quite some detail on how to measure cycle times, hence I split this post into two parts (second part How to Measure Cycle Times – Part 2), with an additional third post focusing on the details of manual cycle times.

Definition of Cycle Time

Most definitions for cycle time I have found online are rather basic, defining cycle time often as the time required to complete a cycle (Merriam Webster). However, for practical terms, this definition is way to broad. A much more useful definition for me is:

The cycle time is the fastest repeatable time in which you can produce one part.

Hence, it is measured as a time per part, and does not include losses like breakdowns, defects, and other delays (for more on losses see my articles on OEE). As with most other time measurements, you can also distinguish between the current cycle time you actually have (simply called cycle time), and the cycle time you want – the target cycle time.

Yet even this will leave some remaining ambiguity. For example, if you have batch processes, is the cycle time the time for one batch, or the time for one part? Depending on what you need the time for, both may make sense. Confusingly, I am not aware of an widely accepted name that distinguishes one from the other. Both are commonly called cycle time, regardless if for a batch or for a single part.

Please be aware that this definition above is far from universally accepted. Quite a few practitioners define cycle time to include losses. Others call the definition above an “effective cycle time”. This has significant potential for confusion! I strongly prefer to use cycle time only for times without unplanned losses or delays. In any case, if discussion takt times and cycle times with someone else, please verify what they are talking about! Based on a discussion on the LinkedIn Group TPS Principles and Practice, cycle time is more often defined excluding losses (Many thanks to all who contributed in this discussion).

How to Measure Cycle Times

 The Easy but Terrible Wrong Way!

Many people simply calculate the cycle time by dividing the working time by the number of parts produced during this working time.

\[Customer \; Takt = \frac{Work \; Time}{Number\; of \; Parts }\]

This is terribly wrong! This is how you calculate the line or process takt time, which includes losses. If you calculate the cycle time using this approach, you include all the losses and breakdowns. Even if you pick a “good day”, you still have lots of minor delays, slow-downs, some defects, and so on that will creep into your measurement.

The More Convenient but Slightly Flawed Approach

Another common approach to determine the cycle time is to simply look it up in one of the data sheets. When the machine was built, surely somebody must have set a time into the machine. Similarly, there is often data available on how fast a manual work should be. Often, this number is used without questioning.

While this number is probably closer to the truth, it still is far from good. The speed of machines change over time. The number you have received may no longer be correct. The number may also be only the primary process, but may not include the loading or unloading or other preparation. For example, in an injection molding machine I once had the situation that the “cycle time” included the injection and the cooling, but not the opening, ejection, and closing of the mold, hence the “official” cycle time was too short.

Similarly, for human operations there is often a time available based on MTM or REFA data. However, this usually includes 5% to 25% extra time for toilet or other breaks. While I totally agree to include the time when calculating the average target speed for the operator, it must not be included in the peak speed of the process. I will write more on that in the near future.

Hence, some practitioners say that you always must measure your data yourself. I am not that hardcore. Measuring it yourself will take quite a bit of time, especially if you have many processes (details see below). If you are short on time (and most people are), you can also use the data found in some documents. But please check if these numbers are approximately in the right ballpark. Also keep in mind that different part types may have different cycle times. I would not trust them without verification, but if the numbers are close enough I sometimes skip the detailed measurement.

The Most Precise but still Imperfect and Time-Consuming Way

The most precise way to determine the cycle time is to measure a number of individual parts. To determine the entire cycle time, you would need to measure the time between the completion of one part until the completion of the next part for multiple parts. This is the same as measure the time between the beginning of one part until the beginning of the next part. If it is more convenient, you could even measure the time between one action of the cycle and the same action of the cycle of the next part. I.e. if during the cycle there is a point where a light comes on, or an audio signal is given, or the computer automatically takes a time stamp, then you can also measure the time between successive lights/signals/time stamps for successive parts. In any case the result may look something like a chart below:

You will have variation. The question is: How to get the cycle time from this data set?

The smallest value in the data is 4.9 seconds. Yet, this is not our cycle time. Our cycle time should be repeatable, and the smallest value is not repeatable. In any case, I also often find that this is a measurement error. Hence, do not use the minimum as the cycle time.

What I also see way to often is people simply taking the arithmetic mean, i.e. the sum of all times divided by the number of measurements. Unfortunately, this is then skewed towards a larger value by the larger outliers.For example, if you measure the average wealth of 30 people, and one of them is Bill Gates (worth ca. $ 80 billion), then the average wealth of everybody is at least $2.6 billion, even if all the other 29 people are poor paupers.

Similar for the data above, measurement 7 and 16 seem to be very large. The arithmetic mean of the data set above is 11.8 seconds, and hence above most actual measurements. Do not simply use an arithmetic mean for cycle times. Sometimes I see the largest values discarded, and the arithmetic mean of the remainder used. It is possible to use the mean without these extreme values, although not my preferred way.

What I often do is to use the median or an percentile. The median is the measurement where half of the measurements are larger, and the other half are smaller. A 25th percentile (also known as the first quartile) is the measurement where 25% of the measurements are smaller and 75% of the measurements are larger. This would also work.

Yet even then the results differ. As shown in the graph below, the median is 8.8 seconds, and the first quartile is 7.1 seconds, a difference of 20%. Which one should we use? Or should we use the 10th percentile (6.2s), the 15th percentile (6.6s), or the 20th percentile (6.8s)? By the way, more measurements won’t bring the numbers closer together, since this is not a measurement error but caused by the underlying random distribution.

Here I don’t have a definite answer for you.As mentioned in the heading, this method is still imperfect. If i seem to have few outliers at the bottom (i.e. very small times) I often use the first quartile (i.e. the 25th percentile) or the 10th percentile. If i do have lots of outliers, I sometimes use the median. For example, I once had a system that generated automatic data, but due to a technical quirk often measured two parts with no delay in between. Hence, 1/3rd of my data had a time between parts of zero, and a quartile would then give me a cycle time of zero, which is not useful.

Hence, I cannot answer you definitely which percentile to use. Plot the data, look at the data and try to figure out what you think your system can repeat if there are no problems. If you graph the data as shown above, you can also simply put in a line where you think the cycle time fits best. As for the graph above, would you go with the Min, 1st quartile, median, or average value for a repeatable cycle time? For me, the 1st quartile would look best. I will talk a bit more about this problem in my next post.

Summary

Overall there are three ways to measure cycle times. A really bad one (divide work day by number of parts produced), a mediocre one (look up the [outdated? wrong?] data somewhere), and a time-consuming and still slightly flawed way (measure the individual cycles and take the best quartile or so). However, even with this data, there are still things that can go wrong. In my next post (How to Measure Cycle Times – Part 2) I will talk about the dangers of changing the sequence of the steps within a process, on different part types with different cycle times, and some general comments on the accuracy of cycle times in general. Stay tuned, and in the meantime Go Out and Organize your Industry!