How Capacity Is Computed for a Work Center, Shift, and Day

EDGEBIC by User Solutions computes a work center's available hours for a given shift and day with one formula: take the base shift hours, subtract holiday and downtime, multiply by the utilization percentage, multiply by the number of machine instances, then subtract hours already allocated and any late-start penalty. The result is the finite capacity bucket the scheduling engine fills, and every term in it corresponds to a real reason the shift is worth more or less than its clock length suggests.

A shift on the calendar says "08:00 to 16:00." That is not the same as how many machine-hours the shift can actually deliver to a schedule. The gap between those two numbers is exactly what this calculation captures, and it is the number that makes finite capacity finite.

The formula, term by term

For each combination of work center, date, and shift, EDGEBIC builds one bucket:

available = (base shift hours - holiday hours - downtime hours)
            x utilization %
            x number of instances
            - already allocated hours
            - late-start penalty

Each term earns its place:

• Base shift hours is the working length of the shift for that weekday, net of breaks. A shift defined 08:00 to 16:00 with a one-hour break contributes 7 hours.
• Holiday and downtime come off the top. A whole-day holiday zeroes the shift; a partial holiday or a scheduled maintenance window reduces it.
• Utilization percentage is the throttle applied to the shortened shift. Work centers created or imported in current versions run at 100 percent and the value is not editable on the work center screen, so deliberate slack is expressed through shift hours, downtime, or a per-day capacity override instead, which is the point of protective capacity.
• Number of instances multiplies by how many physical machines run the shift. Two identical machines double the hours.
• Already allocated subtracts what earlier operations have already booked in this bucket, so the number is what remains, not the gross.
• Late-start penalty clips the first usable slot when an operation cannot begin at the shift's start.

The order matters. Holiday and downtime are subtracted before the multipliers because they shorten the shift itself, while utilization and instances scale the shortened shift. Get the order wrong and the same inputs produce a different, wrong number.

Why instances and utilization are separate

It is tempting to fold these into one figure, but they answer different questions and behave differently. Instances is a count of physical capacity: how many machines exist and run this shift, and it is a number you set on the work center. Utilization is a throttle on the shift itself, and in current versions it sits at 100 percent with no editor field, so it is a term to read rather than a dial to turn.

Keeping them separate still matters when you read a capacity figure, because it tells you which part of the number to question. If the offered hours look wrong, the machine count and the shift definition are where to look, not a hidden percentage. And when you do want a machine planned below its clock, the reduction goes into the shift hours, a downtime event, or a per-day capacity override, all of which the hours-based capacity model honors.

The late-start clip

The final term is easy to miss but shapes a lot of "why only six hours?" questions. An operation's earliest start is usually the end of the step before it, and that can land partway through a shift. When it does, the portion of the shift before that start is unusable for this operation, so EDGEBIC subtracts it. A shift from 08:00 to 16:00 with an operation that cannot begin until 10:00 offers this operation only 6 hours on day one, even though the shift's full length is longer. There is also a floor on how thin a remainder the engine will book, described in the smallest slice of capacity a scheduler will use, which keeps rounding drift out of the plan.

This is a per-operation clip, not a permanent loss. A different job that can start at 08:00 could still claim that early window. It is specific to the operation whose constrained start clipped it, which is why the allocator filling a partial first shift is its own distinct behavior.

A worked example: one machine center, one day

Take a milling center on a Monday. The day shift is 08:00 to 16:00 with a one-hour break, so 7 base hours. The center runs three machine instances at the standard 100 percent utilization. Monday has a scheduled 1-hour maintenance downtime and no holiday, and 8 hours are already allocated to earlier jobs.

Work the formula:

So this bucket offers 10.0 available hours. If the next operation to reach this center also had a constrained start of, say, 10:00, a late-start penalty would come off that 10.0 as well. Every figure is traceable to a real cause: the break, the maintenance, three machines, and the work already on the books.

Why the calculation is the foundation

This one number is what the rest of the engine trusts. The multi-shift allocator walks the calendar consuming these buckets in priority order. Holidays and downtime enter here, so they shape the schedule and the dashboards identically. And because the formula is deterministic, the same inputs always yield the same available hours, which is why a schedule is auditable: pick any placement and you can rebuild the capacity it consumed.

There is one important exception to the formula. When a planner enters a capacity override for a specific work center, shift, and date, that override replaces the formula outright, which is how you model an authorized Saturday of overtime or a short-staffed day without disturbing the standing calendar. That mechanism is covered in how a daily capacity override replaces the formula.

For the wider context of why respecting this bucket matters at all, finite versus infinite capacity scheduling makes the case, and the complete scheduling engine guide shows where capacity sits in the full pipeline. To see the formula run against your own shifts and machines, explore the EDGEBIC engine or bring your data to a demo.