Department Capacity Analysis in EDGEBIC: How the Numbers Are Built

Department capacity analysis is a rough-cut view: it tells you whether a planning period looks loadable before the finite capacity engine tells you exactly when each operation runs. In EDGEBIC by User Solutions the department layer answers period-level questions with two planner-maintained numbers and a handful of derived ones. Knowing which figures are maintained and which are live is the difference between using the view well and being misled by it.

This is the mechanism post. For setup see how to organize departments and plants, and for what departments are in the wider model see customers, departments and units of measure explained.

The two inputs everything derives from

A department carries exactly two capacity numbers, and both are entered by a planner:

• Capacity (hours): total working hours available in this department for the planning period.
• Planned hours: hours already committed against that capacity.

Neither is recalculated automatically when a manufacturing order is scheduled or completed. That is a documented design choice, not an oversight, and it is the single most important thing to know about this screen. Every percentage on the page inherits the freshness of those two numbers.

The formulas

Four values derive from that pair.

Utilization, rounded to one decimal place:

Utilization = (planned hours ÷ capacity hours) × 100

Available hours, the same pair subtracted rather than divided:

Available = capacity hours − planned hours

Bottleneck presence, read live from the members:

Has bottlenecks = any member work center carries the bottleneck flag

Work center count, also live: the number of work centers currently assigned.

Worked example. A machining department at a Houston plant has three CNC work centers. Capacity is configured at 600 hours per month, derived as three work centers times eight hours a day times twenty-five working days. After reviewing the order queue the planner sets planned hours to 510.

Utilization = round((510 ÷ 600) × 100, 1)
            = round(85.0, 1)
            = 85.0
Available   = 600 − 510 = 90 hours

The card shows 85.0 percent, an amber bar, and 90 hours of slack. The planner reads that as: two more fifty-hour jobs and this department is over.

The color and level thresholds

The utilization figure maps to a color band and a text level. The thresholds are fixed:

The 85.0 percent example lands in amber and Medium. That banding is why the card is legible at a glance across a wall of departments: you are scanning for red before you read any digits.

The caveat carries all the way here too. A red bar on stale numbers is a false alarm, and a green bar on stale numbers is a false comfort. The color is exactly as reliable as the maintenance discipline behind the two inputs.

The plant-wide roll-up

The department summary aggregates across every department:

Total capacity        = Σ capacity
Total planned hours   = Σ planned hours
Total available hours = Σ (capacity − planned)
Average utilization   = mean of active department utilizations
Total bottlenecks     = count of departments containing a bottleneck

Worked example across three departments:

That is the capacity analysis dialog: a grid with a totals row, plus summary tiles for total capacity, total planned, total available, and average utilization. Refresh re-pulls the data and export saves it, which makes the export the artifact to bring to a planning meeting rather than a screenshot.

Note that average utilization is a mean of department percentages, not a weighted plant figure. Three departments at 65, 55, and 66 average to 62.0 regardless of their relative sizes. For a period-level sanity check that is fine. For anything load-bearing, read the totals row instead: 594 planned against 960 capacity is 61.9 percent, close here because the departments are similarly sized, and materially different when one department dwarfs the others.

The number that actually governs throughput

Here is the trap this view sets, and it is the same trap every aggregate capacity report sets. The plant above reads 62 percent utilized with 366 hours of slack, and it can still miss dates every week.

Throughput is governed by the constraint, not by the average. If one mill in the machining department carries the bottleneck flag, everything downstream queues behind it, and the plant can look a third idle while that single machine is saturated. The department card tells you this if you read it in the right order:

1. Bottleneck chips first. They are live and they point at the constraint.
2. Per-work-center utilization rows second. These are also live, drawn from the work center data rather than the maintained planning figures.
3. The department utilization bar last. It is a period-level planning number.

That ordering is worth building into the habit, because the layout puts the bar at the top and the chips at the bottom. The theory here is standard constraint management, and the practical follow-through is in production bottleneck identification and the bottleneck anchor scheduling example, where the engine schedules the constraint first and works outward from it.

Live numbers versus maintained numbers

A department card mixes two kinds of data, and separating them is the whole skill:

If your organization will not commit to updating the two planning numbers each period, the honest answer is to set capacity once, ignore the bar, and use the live rows. You lose the period-level lens and keep everything that is current. That is a legitimate way to run the screen, and it beats trusting a stale percentage.

How to derive capacity hours properly

The standard derivation:

Capacity = instances × shift hours per day × working days in the period

Then adjust for what you already know about the period:

• Subtract planned maintenance downtime.
• Subtract public holidays that fall inside the period.
• Subtract any shift you know will not run.

A three-work-center department on a single eight-hour shift across twenty-two working days, with one public holiday and a full day of planned maintenance, works out as:

3 × 8 × 22   = 528 raw hours
− 3 × 8      = 504  (public holiday, all three down)
− 8          = 496  (one work center down one day)

Note that the engine does not use this number. The engine reads the actual shift calendars, work center instances, holidays, and downtime events to allocate specific hours on specific days. The department figure is a parallel rough-cut estimate that exists so a planner can sanity-check a period before the detailed schedule is built. Where the two disagree, the engine is right and your capacity figure needs revisiting. That relationship between rough-cut planning and detailed scheduling is the subject of capacity planning versus production scheduling.

What this view is good at

Used with its limits understood, the department layer answers four questions well:

Is this period loadable at all? Total planned against total capacity, before anyone builds a detailed schedule.

Where is the slack? Available hours per department tells you which area can absorb a rush order and which cannot.

Which area is the constraint in? The bottleneck chips, live and unambiguous.

How is the network balanced? Across sites, a card per plant shows whether one location is starving while another is drowning. In a Houston plus Monterrey network, the cards read as a site map with their own utilization figures, and the totals line shows the whole network's capacity.

What it is not good at

Minute-level truth. That is the finite capacity engine's job, and the difference between the two approaches is the subject of finite versus infinite capacity scheduling.

Live load. The bar does not move when you schedule a job.

Blocking production. Setting a department to Maintenance changes the card color and nothing else. The engine keeps booking its work centers. To actually block time, add holidays or downtime to each affected work center. That two-step catches people out often enough that it is worth repeating in every department discussion.

Weighted plant utilization. Read the totals row, not the average tile, when department sizes differ materially.

The Analytics tab

Beside the cards sits an Analytics tab with two charts over the same data: department utilization as a percentage of available capacity per department, and capacity distribution as planned hours against remaining available hours, stacked per department. The stacked view is the more useful of the two for a planning conversation, because it shows absolute hours rather than percentages, and absolute hours are what you move a job into.

A practical routine

A monthly rhythm that keeps this screen honest:

1. At period start, recompute capacity hours per department from instances, shifts, and known downtime.
2. Set planned hours from the committed order queue.
3. Open the capacity analysis, export the grid, and take it to the planning meeting.
4. During the period, read the bottleneck chips and per-work-center rows rather than the bar.
5. At period end, compare what actually ran against the planned figure and adjust next period's derivation.

Four of those five steps take minutes. The one that takes judgement is step 1, and it is the one that makes every other number on the page mean something.

For the mistakes that quietly break this view, see customer and department setup mistakes. For the platform overview, read the complete EDGEBIC guide or start at the product hub.