Seeing Next Month's Overload This Month

Capacity visibility is not a number for the plant. It is an answer for a specific machine on a specific future day: how many hours exist, and how many are already spoken for. Plants do not fail on average. They fail at one resource, on four days, eight weeks from now, and the only useful capacity view is one that shows that.

EDGEBIC by User Solutions computes capacity day by day from your shifts, holidays, downtime, instances, and utilization settings, then places committed work into it. This post covers the arithmetic behind an available hour, the views that expose it, what an overload actually tells you, and where visibility stops and decisions begin. It sits under the EDGEBIC results guide. For the metric definition, see capacity utilization KPI.

Why the Average Lies

The documented eight-work-center example is the clearest demonstration.

Plant utilization across the whole set: 68.1%. Anybody reading that number concludes there is room. There is not, at the only resource that matters, and no amount of spare inspection capacity will help.

That is why EDGEBIC rates each resource individually: critical above 100%, high at 85 to 100%, good at 60 to 85%, low at 30 to 60%, idle below 30%. The headline for the example above reads plainly: plant at 68.1%, one overloaded, two underloaded. Both halves of that sentence are actionable, and the average alone is neither.

What an Available Hour Actually Is

Visibility is worthless if the denominator is guessed, so it pays to know exactly how EDGEBIC arrives at a day's capacity. The documented worked example, for a machining center on a Wednesday:

Shift 08:00 to 16:30                        = 8.5 gross hours
less 30-minute break                        = 8.0
less 1.0 h recurring Wednesday maintenance  = 7.0 net
x 2 machine instances                       = 14.0 raw hours
x 85% planned utilization                   = 11.9 usable hours

A job needing 10 hours fits that Wednesday. A job needing 13 spills into Thursday, and the schedule says so rather than quietly assuming the day stretches.

Two override paths sit above the formula, and both are deliberate planner decisions. A daily override replaces the calculation entirely for one work center, shift, and date: the documented case is an approved four-hour Saturday run for a rush order, entered with a reason, on a Saturday the plant would otherwise skip. The planner enters the total hours the machine will genuinely be available and the engine takes that number verbatim without multiplying it by instances or efficiency. A monthly override spreads a total across a period, for cases like a retooling week where the plant can only guarantee a fixed number of machine hours.

See how EDGEBIC calculates work center capacity for the full resolution order, and shifts and calendars for how holidays and downtime enter it.

The Three Views That Matter

The forward capacity view is where an overloaded day shows red before it arrives, per work center and per shift. The important discipline is knowing what red means, because it has three different causes: genuinely too much work, work sequenced badly, or a data error inflating demand. Reading a red day walks the diagnosis.

The daily heatmap in the utilization report breaks the next 14 days into one row per work center per day: scheduled hours, that day's capacity, utilization percentage, and how many jobs land on it. This is the view that answers "which four days break" rather than "is the month tight."

The per-work-center backlog drill-down turns a number into a list. Select the overloaded resource and the grid below shows the specific orders queued on it, with their setup, queue, flow, and transit values. The conversation shifts from twenty hours over capacity to these four orders, and one of them has a due date that could move.

The utilization report's default window is the last 30 days plus the next 60, which is deliberately asymmetric: you need enough history to see whether plan matched actual and enough forward view to still have cheap options.

The Two Sides of an Overload

A red day is a decision point, not a verdict, and the useful thing about seeing it early is that expensive options and cheap options are both still available.

Expensive options, which are all you have if you find out late: overtime at premium, expedited freight, a customer apology.

Cheap options, available only with lead time:

• Move the work. Work center groups can route a job to an equivalent machine automatically. In the documented three-mill example, when the fastest mill is booked until Wednesday, the job goes to an available slower mill and finishes Monday.
• Change the sequence. In the documented paint case, the same three jobs carry 330 minutes of changeover in due-date order and 90 minutes resequenced, which is the difference between a day that overflows the shift and one that finishes with three hours spare. The overload was created by the order, not by the work.
• Move a date. Calling a customer six weeks out is a negotiation. Calling them two days out is an apology.
• Plan the overtime. A daily capacity override records the approved hours and the reason, so the extra Saturday is part of the plan rather than a surprise on a timesheet.

The Other Half of Visibility: Underload

The example above has two work centers below 50%, and shops usually skip past that row. It is worth reading.

Underload is either spare capacity you could sell, spare capacity you could use to relieve the constraint, or a resource you are paying for and do not need. All three are commercial questions, and none of them can be asked without per-resource numbers. The same report that finds your overload finds this, and the department capacity view rolls it up when you need the organizational picture rather than the machine picture.

Testing a Change Before Living With It

Visibility gets more valuable when you can ask "what if" without committing. What-if scenarios let you simulate a modified picture (an added shift, a different order mix, a machine out for a week) and compare against the live plan before anything is written.

The optimizer contributes the same way: it returns a comparison with KPI deltas and an explicit list of operations that would move, and the database is untouched until a planner accepts. Nothing about looking is destructive, which is what makes forward visibility safe to use for decisions rather than just for reporting.

What the Software Cannot Do Alone

It cannot see demand you have not entered. The forward view covers committed orders. Work that exists as a verbal commitment or a probable reorder is invisible until somebody records it, and the resulting overload appears late for exactly that reason.

It cannot validate your shift calendar. Capacity arithmetic starts from shifts, breaks, holidays, downtime, instance counts, and the utilization percentage. Every error in those inputs is an error in every day's number, and the most common one is a utilization figure nobody has revisited in years.

It cannot forecast. Demand beyond your order book is a planning exercise with its own methods and its own error bars. The scheduler tells you precisely what your committed work needs, which is a different and more reliable question.

It cannot resolve the overload. Choosing between overtime, an alternate route, a moved date, and a declined order is management judgement with commercial consequences. The value of seeing it early is that all four options are still open.

It cannot make anyone look. A red day nobody reviews is worth exactly as much as no red day at all. The routine (after every scheduling run, check the next 14 days, ask why for each red one) is a habit, not a feature.

Want to see the next 60 days of your own plant? Bring your open orders, routings, and shift calendar to a demo, and we will build the heatmap on your data.