Weighted Average Cycle Time

Weighted average cycle time (Tcwa), also known as “average weighted cycle time,” provides a representative average cycle time (Tc) within a mixed model environment. Varied models or services in a given cell, line or work area often have varied work contents due to different steps, duration of steps, sequence of steps, etc. Accordingly, the Tc‘s vary.

Tcwa can be calculated for operator cycle times, machine cycle times and effective machine cycle times. Often Tcwa is presumed to be operator related, but this is not always the case.

As we endeavor to maintain a Tc that is less than or, at most, equal to takt time (Tt), mixed models and their varying work content will likely have Tc‘s for some products or services that are below Tt, while others exceed Tt. Tcwa serves as an average proxy for Tc and can be the same as planned cycle time.

Clearly, change in product or service mix will change Tcwa. As the demand mix shifts to one with a greater proportion of Tc(s) that exceed the average, then Tcwa will approach and may exceed Tt. The lean practitioner must be aware of these dynamics and should proactively address the situation through reducing work content, optimizing balance between operators, adding additional operator(s) or lines, strategically applying/sizing FIFO lanes, etc.

The math follows.

wtd avg ctwtd avg ct example












Related posts: The Cycle Time Family, Time, Time Observation Form Math

There are 3 Comments

MarkRHamel's picture


Excellent questions. Takt time, the average rate of customer demand, is in many ways a design parameter for developing the "system" - standardized work (SW), cell or line capacity, etc. The weighted average cycle time is similar in this design parameter nature. That said, standardized work, by product or product family, is specific to the actual cycle time for the product. Consistent with that notion, "playbooks" that dictate staffing levels and the related SW, are what satisfies the dynamic demand.

If demand is seasonal, then that is good reason to have seasonal takt times (and use that as a design parameter). If demand is randomly volatile, and you do not want to buffer that with strategic inventory (a.k.a. kanban), then you will probably need to carry excess capacity. It makes sense to practically and graphically look at historical and future demand, as well as calculate the related coefficient of variation (on historical demand), in order to gain insight into demand and thus ways to apply takt time.

In the end, one should simulate the use of the playbooks and required staffing over a number of historical days/weeks to see how it would satisfy customer requirements.

Also, remember that work content (think cycle time here as well) variation between products within a product family is excessive (say 30%+), then you may very well have more than one product family. Work content should be a consideration for product family selection and line/cell designation.

This is a big, meaty subject and I probably did not do it justice here. We can continue the conversation here or off line if you would like.

Best regards,

Phil Coy's picture

You made your case for why to use Average Weighted Cycle Time based on a mixed model scenario. But wouldn't it be better to use the actual cycle times for each item instead? The challenge with HMLV is that daily demand is highly variable especially at the item level. For value streams with hundreds to thousands of product variants, on any one day or in any one week, there would be lots of products without any orders at all. Then the question is: over what time period do you average the daily demand? Lumpy demand with large spikes at the item level is going to require using the actual cycle time by item and the actual demand. I can understand why this metric would be helpful in a more high volume repetitive environment. Isn't it potentially misleading for HMLV?

Kevin's picture

WACT is excellent in helping design SW and in keeping ~5% under TT. Thank you for the calculation example.

WACT (or even CT) should never be greater than TT or used as a substitute for TT. If you don't use TT you don't know if you are under or over producing and false reorder or remake signals are sent up the value stream. Just as importantly, without TT there is no indicator if a job is stable or if the job needs kaizen (outside of doing a SW audit).

So even in HMLV environments, TT is what to aim for even though it may have to be recalculated daily.