All posts

Takt Time for CPG Schedulers: Turn Demand Into a Daily Run Plan

Takt Time for CPG Schedulers: Turning Customer Demand Into a Daily Run Plan the Line Can Actually Hit

A planner loads a filler to its nameplate speed, confirms the run-rate against last quarter's OEE, feels good about the shift — and still misses fill. What happened? The line ran fast enough. It just didn't run long enough at the right pace to keep up with what customers were actually pulling. The plan was built around how fast the line can go, and nobody ever computed how fast it has to go.

That second number is takt time — the customer's drumbeat. This article is about calculating it, separating it from the paces it gets confused with, and turning it into a daily run plan you can defend.

What takt time actually is (and isn't)

Takt time is the available production time divided by customer demand. Its whole purpose is to precisely match production with demand (Lean Enterprise Institute). Put another way, it's the required assembly duration needed to match demand — a tool that measures the average interval between the start of one unit and the start of the next when items are produced sequentially (Wikipedia).

The critical thing to internalize: takt is set by the customer, not the machine. It is a target, not a spec sheet. If your process can't produce at takt time, the fix is demand leveling, additional resources, or process re-engineering — the line rate doesn't get a vote (Wikipedia).

This is where takt differs from the paces most CPG schedulers already track. Your OEE-based schedulable run-rate tells you what the line can do. Takt tells you what demand requires. They are two different numbers, and the whole scheduling game is closing the gap between them.

The formula, step by step

Takt time is deceptively simple:

Takt time = Net available production time / Customer demand

The two inputs are where the discipline lives.

Step 1: Net available time — not gross shift time

Net available time is the amount of time actually available for work. It excludes break times and any expected stoppage: scheduled maintenance, team briefings, sanitation, and so on (Wikipedia).

The textbook example: an 8-hour shift is 480 minutes gross. Subtract lunch, breaks, a shift briefing, and startup checks and you might net 400 minutes. In CPG you subtract more than the generic factory does — planned CIP (clean-in-place), changeover windows, and any mandated quality holds all come off the top before you have a number worth dividing.

Step 2: Demand for the period

This is where the takt calculation lives or dies. Pull demand from a forecast you trust — not a stale spreadsheet from two planning cycles ago. If your forecast doesn't survive contact with the floor, your takt won't either; see forecasting that survives the floor for how to keep that number honest.

Step 3: Divide

With 400 net minutes and demand of 400 units for the day, takt = 1 minute per unit. Every 60 seconds, one unit needs to start — or you fall behind demand.

A CPG-scale worked example: say a filler runs a single SKU across a 400-minute net shift and the day's demand is 24,000 cases. Takt = 400 min ÷ 24,000 = 0.0167 min/case, or 1 second per case. That's a real high-speed number — and it immediately raises the question every CPG scheduler has to answer next.

Takt vs. cycle time vs. line rate — three paces you must separate

iSixSigma frames the contrast cleanly. Takt time is available production time ÷ customer demand (their example: 450 min ÷ 150 units = 3 min/unit). Cycle time is something different: the actual amount of work time needed to complete a single task (iSixSigma). Takt is the demand-set target; cycle time is what the process actually achieves. The gap between them is the scheduler's problem to solve.

Pace What it answers Where it comes from
Takt time How fast must we run to meet demand? Customer demand ÷ net available time
Cycle time How long does one unit actually take? Observed process work time
Line rate (effective) How fast can we run, all losses in? Nameplate × OEE

Read the table left to right: takt is the must-run pace, line rate is the can-run pace, and cycle time is the granular reality underneath. When effective line rate is faster than takt, you have slack — you don't need the whole shift. When it's slower, you have a problem no amount of hoping fixes.

The CPG reality check: you don't pace cases to takt

Here's the twist that trips up planners coming from discrete assembly. On a manual assembly line, takt is a literal metronome — a unit starts every takt interval. On a high-speed CPG filler running hundreds of units a minute, you do not pace case-by-case to takt. A one-second takt isn't a conveyor instruction; it's a planning fact.

So use takt at the daily/SKU planning layer, not the conveyor. The move is to invert the calculation. Instead of asking "what interval must each unit hit," ask "how much line-time does this SKU's demand require?"

Required line-time (per SKU) = SKU demand / effective run-rate

Then sum required line-time across every SKU on the line and test it against net available time. That's a direct feasibility check — and it's exactly the logic behind rough-cut capacity planning. Takt is the demand-side discipline that feeds RCCP its numbers.

Turning takt into a run plan

Build the daily plan in this order:

  1. Compute required run-time per SKU. Demand ÷ effective (OEE-adjusted) run-rate. Use the schedulable run-rate, not nameplate — nameplate lies.
  2. Add changeovers. Sum the changeover time between the SKUs you're running. The sequence matters here; a smart run order shrinks total changeover, which is the whole point of sequence-dependent changeover scheduling.
  3. Compare to net available time. Required run-time + changeovers vs. what the shift actually offers.
  4. Close the gap if it doesn't fit. Takt time can be adjusted to requirements by changing daily working time and reducing machine downtime (Wikipedia). Translated to levers a planner controls: add a shift, add a crew, or cut downtime.

If the required time exceeds available time even after those levers, the plan is infeasible and you need to say so before the shift, not after the stockout.

When the line genuinely can't hit takt

Sometimes demand rises above what the process can deliver. The documented responses are exactly three (Wikipedia):

  • Demand leveling. Smooth the peaks so the required pace is achievable across the horizon rather than spiking on one day. This is the entire premise of heijunka production leveling — flatten the drumbeat so the line can keep time.
  • Add resources. More shifts, more crew, more available time in the denominator's numerator.
  • Re-engineer the process. Attack the losses. In CPG the biggest recoverable chunk is usually changeover — SMED and changeover reduction directly buys back net available time.

And crucially: don't schedule to takt with zero slack. A built-in buffer of three to five percent downtime allows for needed adjustments or recovery from failures (Wikipedia). A plan that only works if nothing goes wrong is a plan that will fail, because something always goes wrong.

Using takt to expose the bottleneck

Takt does double duty as a diagnostic. Because it's a clear target pace, it makes bottlenecks — stations that need more time than planned — and unreliable stations easy to spot (Wikipedia). If one station on a line can never sustain takt while the rest can, you've found your constraint. That's the entry point to drum-buffer-rope scheduling: pace the whole line to the constrained resource and stop pretending the other stations' surplus speed helps.

Common mistakes

  • Using gross shift time instead of net. Dividing demand into 480 minutes when only 400 are real gives you a takt that's too generous — and a plan that quietly runs short every day.
  • Taking takt off a stale forecast. Garbage demand in, garbage pace out. Takt is only as current as the number feeding it.
  • Confusing takt with cycle time. Takt is what demand requires; cycle time is what the process delivers. Treating them as the same thing hides the gap you're supposed to be managing.
  • Scheduling exactly to takt with no buffer. Skip the 3–5% and the first jam eats your whole day.
  • Applying unit-takt to a high-speed line. Don't pace cases to a one-second metronome; convert demand to required line-time at the daily/SKU layer instead.

Operator takeaway: a repeatable workflow

Run this five-step loop every planning cycle:

  1. Compute takt — net available time ÷ current demand. Start from gross shift time and honestly subtract breaks, briefings, CIP, and planned maintenance.
  2. Convert to required line-time — per SKU, demand ÷ effective (OEE-adjusted) run-rate, plus changeovers.
  3. Capacity check — sum required line-time against net available time.
  4. Close the gap — level demand, add a shift or crew, or cut downtime.
  5. Build the buffer — hold 3–5% back for recovery.

The translation from demand to required line-time is exactly the mechanical step CPG Scheduler automates: it pulls each SKU's demand, applies your real run-rates and changeover matrix, and shows you whether the day fits before you commit the crew. Takt gives you the target; the tooling closes the loop.

The planner who misses fill despite a fast line isn't running the wrong machine. They're answering the wrong question. Compute the pace demand actually requires — then build a plan that can hold it.

Sources

More from the journal

Takt Time for CPG Schedulers: Turn Demand Into a Daily Run Plan · CPG Scheduler