Modeling Real Capacity: Shifts, Calendars, and Parallel Machines

Ask a planner how many hours a work center has this week and you’ll usually get “forty” — five eight-hour days. It’s a useful shorthand and almost never the real number. The real number is lower, sometimes much lower, because a work center’s true capacity is the product of several things multiplying against each other, not a single figure anyone can read off a calendar.

Getting that real number right is the single most important input to any scheduler, finite or otherwise. Every other calculation — how long a job takes, whether two jobs collide, whether a due date is achievable — sits on top of it. Get the capacity model wrong and nothing built on top of it can be trusted, no matter how sophisticated the sequencing logic is.

The capacity hierarchy

Real shops describe capacity at more than one level, and the levels nest:

• Department or work center — a group of interchangeable (or near-interchangeable) resources doing the same kind of work: “the ovens,” “the CNC cell,” “the press floor.” This is the level most planning conversations happen at.
• Machine or workstation — the individual physical unit inside that group. Three ovens are three separate machines with their own calendars and their own occasional downtime, even if they’re identical models bought on the same purchase order.
• Operator or crew — a separate capacity dimension layered on top of the machines, covered in its own detail in When People Are the Constraint — worth flagging here because a shop that models machines perfectly and ignores who runs them has only modeled half the constraint.

A scheduling model needs to know which level actually limits throughput. Sometimes it’s the department as a whole; sometimes one specific machine inside it is the real ceiling while its siblings sit idle. Getting the hierarchy right — and knowing when to stop at the department level versus drilling into individual machines — is itself a modeling decision, not a fixed rule.

Parallel capacity: three ovens are not one triple-speed oven

Here’s a distinction that trips up capacity math more than any other: three machines running in parallel are not the same thing as one machine running three times as fast, even though both descriptions might use “3×” somewhere in a spreadsheet.

Say a bakery has three identical ovens, each capable of baking one batch in 25 minutes. Three ovens running in parallel can complete three different batches in that same 25-minute window — batch A on oven 1, batch B on oven 2, batch C on oven 3, all finishing together. One triple-speed oven could not do that: it would still process batches one at a time, just faster, finishing batch A in about 8 minutes and then starting batch B. The total throughput over an hour might work out similar on paper, but the two models behave completely differently the moment jobs have different due times, different products, or need to start at different moments — which in a real shop, they always do.

This is why a capacity model represents parallelism as parallelism — N independent slots that can each hold one job at a time — rather than collapsing it into a single faster rate. A scheduler that gets this wrong will either under-book a department (treating three ovens as if they were one, wasting two-thirds of the real capacity) or over-book it (assuming the ovens can somehow absorb more simultaneous work than three concurrent batches allow).

Efficiency: why book time and clock time diverge

A routing might say an operation takes 60 minutes. On the floor, it rarely takes exactly 60. A press that needs a die change between runs, an oven that loses a few minutes to temperature recovery after being opened, a line that runs at a slower pace on the overnight shift than the day shift — all of these mean the book time (what the routing says) and the clock time (what the wall shows) diverge, consistently, in a measurable direction.

Efficiency percentage exists to reconcile the two. A work center running at 90% efficiency turns a 60-minute book-time operation into roughly 67 minutes of real clock time (60 ÷ 0.90). It’s not a penalty or a target — it’s a measured fact about how that particular resource actually performs, and a capacity model that ignores it will consistently under-estimate how long things take and consistently over-promise what a shift can deliver.

Two mistakes show up constantly with efficiency numbers. The first is treating it as a knob instead of a measurement — inflating it to manufacture apparent slack (“let’s say 110%, we’re due for an improvement”), which just moves the lie from the schedule to the efficiency field instead of removing it. The second is the mirror image: never revisiting it once set, so a shop that genuinely got faster (new tooling, a process fix) keeps under-promising its own capacity for years because nobody updated the number that says how fast it runs.

Putting the pieces together

None of these factors act alone — real capacity is what’s left after all of them multiply against each other. Take a press department with four identical presses, each rated for a 15-minute cycle, running one 8-hour shift, at a measured 85% efficiency, five days a week.

Naive math says: 4 presses × 8 hours × 60 minutes = 1,920 minutes of raw capacity per day. Divide by the 15-minute book-time cycle and that reads as roughly 128 cycles a day. But 85% efficiency means the real clock time per cycle is 15 ÷ 0.85 ≈ 17.6 minutes, not 15 — so the honest daily throughput is closer to 109 cycles, a gap of nearly 15% between what the naive number promises and what the floor can actually deliver. Multiply that gap across a two-week planning horizon and it’s the difference between a schedule that’s merely tight and one that’s quietly unachievable from the day it’s published.

This is the arithmetic a capacity model has to get right before a scheduler ever looks at a single due date: how many parallel resources, over how many real (calendar-exploded) hours, at what measured efficiency. Every later decision — sequencing, prioritization, what-if analysis — inherits whatever this number gets wrong.

Shifts, calendars, and why they have to be exploded into real dates

A shift pattern — “Monday through Friday, 7am to 3pm” — is an abstraction. A scheduler can’t plan against an abstraction; it needs to know that this specific Tuesday has 8 hours of open capacity on this specific machine, and that the Wednesday after next is a plant holiday with zero.

That’s what a calendar explosion does: it walks the abstract weekly pattern forward across the planning horizon and writes a concrete capacity figure onto every individual date, for every resource, accounting for weekends, holidays, and any planned exceptions (a maintenance window, a training day, a known short shift). The abstract pattern is what a planner edits; the exploded, dated entries are what a scheduler actually reads. This two-tier structure matters because it means a calendar change — adding a holiday, extending a shift — doesn’t take effect until the exploded entries are regenerated. Edit the pattern and stop there, and the scheduler keeps working off the old dates, which is one of the most common and most confusing capacity-modeling mistakes: the planner is certain they fixed the calendar, and the schedule behaves as if they never touched it.

Multi-shift and 24/7 operations add one more wrinkle worth naming: a shift that crosses midnight belongs to two calendar dates at once, and a scheduler has to decide — consistently — which date “owns” a job that starts at 11pm and finishes at 3am. Get this ambiguous a few different ways in different places and capacity quietly gets double-counted or dropped at every shift boundary, invisible until someone reconciles two reports that should agree and don’t.

The invisible time: queue, wait, and move

Setup and run time are the parts of an operation everyone thinks about, because they’re the parts where visible work happens. But in most shops, they’re a minority of total lead time. The rest is queue time (a job sitting behind other work, waiting for the machine to free up), wait time (a part cooling, curing, or drying after processing, before it can move on), and move time (physical transport between one resource and the next).

None of these involve a machine actually doing anything to the part, which is exactly why they’re easy to leave out of a mental model of “how long does this take” — and exactly why leaving them out produces schedules and lead-time estimates that are wrong in the same direction every time: too optimistic. A part that takes 40 minutes of combined setup and run time can easily take four or five hours door-to-door once realistic queue and move time are added, and a scheduler that only knows about the 40 minutes will promise dates no plant can hit.

Wait time deserves a particular callout because it behaves differently from the others: it happens outside the resource’s own capacity. A part curing in a paint booth after coating is not consuming booth capacity — the booth is free for the next job — but the part still isn’t available for its next operation until the cure finishes. A capacity model has to track both halves of that correctly: the booth’s capacity frees up immediately, but the routing’s timeline doesn’t move forward until the wait completes.

The garbage-in rule

Every one of the traps above shares a single lesson: a scheduler — however sophisticated its sequencing logic — can only ever be as good as the capacity numbers it’s fed. Feed it a work center that’s really three parallel machines described as one, an efficiency figure nobody’s updated in years, a calendar pattern that was edited but never re-exploded, or a routing that only counts setup and run while ignoring queue and move, and it will produce a plan that’s internally consistent and factually wrong. The math doesn’t fail loudly; it just quietly compounds a bad input into a confidently wrong output.

This is why experienced planners treat the capacity model itself as the thing worth auditing first when a schedule keeps missing reality, before touching sequencing rules, priority weights, or anything downstream. A schedule that keeps producing dates the floor can’t hit is far more often a symptom of a capacity model that’s lying — an efficiency number that’s stale, a calendar that was never re-exploded, a parallel resource collapsed into one — than a symptom of the scheduling logic itself being wrong.

Where SmartFlow fits

Finite scheduling only works if it treats the real capacity model — parallel machines, calendars, efficiency — as a hard ceiling rather than a suggestion. SmartFlow APS reads each work center’s shift calendar and parallel-machine count and enforces them as hard limits: verified across audited runs, no machine is ever double-booked past its true parallel capacity. It doesn’t edit or override the capacity model — the calendars, efficiency percentages, and parallel counts stay exactly what the shop configured; the scheduler only ever reads them.

Related reading

• Finite vs Infinite Capacity Scheduling, Explained Properly — why treating capacity as a hard ceiling, rather than a warning, is what finite scheduling actually changes.
• Sequence-Dependent Setup: The Changeover Matrix Explained — changeover time eats into the same shift windows this page describes.
• Measuring a Schedule: OTIF, Tardiness, Utilization, and the Trade-offs — utilization is only meaningful once the capacity it’s measured against is honest.
• In Microsoft Dynamics 365 Business Central: Work Centers, Machine Centers, and Shop Calendars: BC’s Capacity Model — how these same concepts map onto BC’s specific tables and fields.