The Total Assigned Hours Metric in Optimization

Total assigned hours is the sum of all the work hours a plan schedules across every operation and work center. It measures the total workload the plan commits, not how that work is spread over time. The EDGEBIC optimizer reports it on the comparison screen so you can confirm a proposed plan carries the same real work as your current one.

EDGEBIC by User Solutions computes total assigned hours through the same single calculator that produces every other optimizer measure, so the number on the comparison screen and the number in the audit record always agree. This post explains what the metric means, why it usually holds steady across reorderings, when it genuinely changes, and how it differs from makespan. For the wider set of measures, see how the optimizer scores a schedule and the EDGEBIC optimizer guide.

What the metric counts

Total assigned hours adds up every hour of work the plan places on a resource. Each operation contributes its run hours plus its setup hours, summed across all jobs and all work centers in scope. The result is one number: the total amount of production work the plan has committed.

It is a workload measure, deliberately blind to timing. It does not care whether the work runs Monday or Friday, back to back or with gaps between operations. It answers a single question: how much work does this plan actually contain? That makes it the natural companion to the timing measures, which answer when the work runs and whether it lands on time.

Why reordering usually leaves it unchanged

Here is the useful property: for a plain reordering, total assigned hours barely moves. The reason is simple. Reordering jobs changes the sequence in which work runs, not the amount of work. The hours of cutting a set of parts, milling them, and assembling them are fixed by the routings and the order quantities. Shuffling which job goes first does not add or remove any of those hours.

So when the optimizer reorders jobs to hit due dates or compress the plan, it is moving the same total workload into a better arrangement. Total assigned hours should read close to "no change" on the comparison screen, and that is exactly what you want to see. It confirms the proposal is a genuine rearrangement of your real work rather than a plan that quietly dropped an operation or double-counted one. Treat a flat total assigned hours as a green light on the plan's integrity.

When it actually changes

The metric does move in two honest situations, and both tell you something specific.

The first is setup savings. When the optimizer groups similar jobs to reduce changeovers, the setup hours it eliminates come straight off the total. A plan that cuts an hour of changeover shows an hour less total assigned hours, because that hour of setup work no longer happens. If your site has populated a setup matrix, a fall in total assigned hours should line up with a fall in the setup hours row on the same screen, the effect described in how the optimizer cuts total setup time.

The second is a shift of work onto different resources. If a different job order leads the scheduler to route an operation through an alternate work center with a different efficiency, the hours that operation contributes can change. In that case the total moves because the work is being done somewhere with a different rate, not because any real production vanished.

In both situations, the production content itself is preserved by the routings. Genuine work is never silently dropped.

Total assigned hours versus makespan

The clearest way to understand the metric is to set it beside makespan, because the two are often confused and they measure opposite things:

Two plans can carry identical total assigned hours yet have very different makespans. One might pack the same work into a tighter window with the machines rarely idle, while the other leaves gaps that stretch the finish. That gap between workload and span is exactly what the MinMakespan preset attacks: it does not reduce the work, it removes the idle time around it. Understanding the makespan side of the picture is covered in what makespan is.

How to use it on the comparison screen

On the KPI comparison table, treat total assigned hours as a check, not a target. Read the measures your chosen goal ranks first, such as weighted lateness under On-time first or overall span under Fastest overall finish, to judge whether the plan improved. Then glance at total assigned hours to confirm the workload is intact: flat is expected, a fall usually means setup savings, and the setup row will confirm it. Reading the whole grid, including which rows appear only conditionally, is covered in reading the optimizer KPI comparison table.

For a metric that does drive the goal directly, compare this with the on-time job count metric in optimization, which the optimizer works to improve rather than merely preserve. To run the optimizer on your own orders, visit EDGEBIC.

The bottom line

Total assigned hours is the plan's total workload: every run and setup hour summed across every operation. Because reordering changes when work runs and not how much there is, the metric usually holds steady, which makes it a clean sanity check that a proposal preserved your real work. When it does fall, the cause is normally setup savings, visible in the setup hours row. Keep it distinct from makespan, which measures span rather than work, and use it to confirm integrity while your goal measures tell you whether the plan actually got better.