8 Multi-Shift Scheduling Mistakes (and How to Spot Them)

Almost every complaint that starts with "the multi-shift schedule looks wrong" traces back to configuration rather than to the engine, and the same eight errors account for most of them. The list below gives each mistake, the symptom it produces, and the fix. All of it applies to EDGEBIC by User Solutions, and all of it is faster to check than to debug.

If you have not set up shifts yet, work through how to schedule jobs across shifts first. If you want to understand the arithmetic well enough to predict the right answer before you look, read how EDGEBIC allocates hours across shifts.

1. Letting the Shift Describe the Clock Instead of the Work

Symptom: Every work center looks like it has more capacity than it delivers. Jobs are promised on time and finish late. The plant is quietly overbooked.

Cause: The shift was entered as the gross window and nothing takes the rest off. Work centers run at 100 percent utilization and the value is not editable on the work center screen, so a two-instance work center on an 8-hour shift offers a full 16 hours whether or not the machines really deliver them.

Fix: Define each shift as what the machine genuinely converts into production once breaks, minor stoppages, and unrecorded interruptions are removed. Well-run equipment usually lands between 80 and 90 percent of its clock, so an 8-hour window often means a 6.5 to 7.2 hour shift. For losses that recur on a known pattern, a downtime event takes them off automatically. Do this before your first real schedule rather than after three weeks of confusing results.

This is the single most common setup error, and it is silent: nothing warns you, the schedule is internally consistent, and it simply promises more than your shop can run.

2. Shifts Saved With Zero Daily Hours

Symptom: A work center schedules nothing at all. The shift appears in its assigned list and looks correct.

Cause: The shift definition has zeroes on the weekdays that matter. A shift with no hours contributes no capacity anywhere it is assigned, on every machine that claims it.

Fix: Open the shift and confirm start time, end time, and break duration on each weekday it should run. This is worth checking first whenever a machine is unexpectedly dark, because the shift list gives no visual clue that a row is empty.

3. The Global Shifts Flag Silently Overriding Assignments

Symptom: You assigned a specific shift to one work center, saved it, and the machine still runs plant-standard hours.

Cause: The work center has Use Global Shifts turned on. When it is on, the plant-wide shift list applies and the machine's own assigned list is bypassed.

Fix: Turn off global shifts on that work center, then confirm its assigned list holds the shift you want. This is the mechanism for a furnace running 06:00 to 18:00 while the rest of the plant runs 08:00 to 16:00: a dedicated shift record, global shifts off, and the dedicated record assigned.

4. Assigning One Shift to a Machine That Runs Two

Symptom: You added a second shift, the crew is working it, and the schedule still behaves as though the machine stops at 16:00.

Cause: Only assigned shifts are searched for capacity. A machine holding only the day shift is invisible to the scheduler between 16:00 and 08:00 no matter what happens physically.

Fix: Assign every shift the machine actually runs. For a work center meant to run around the clock, that means both the day and the night shift on its list. The payoff is large: a 28-hour operation that takes four days on a single shift can finish in under two with a second shift assigned.

5. Two Identical Shift Records Instead of One Shared Record

Symptom: Two machines that must run at the same time never schedule together. The group slides day after day, or scheduling reports that no simultaneous window could be found.

Cause: EDGEBIC matches a common shift across a group by the shift record itself, not by the printed times. Two separate rows both reading 08:00 to 16:00 are two different shifts, so the group has nothing in common.

Fix: Assign one shared shift record to every machine in the group. This matters specifically for parallel and synchronized work centers, where a common shift is a precondition for any simultaneous slot. It costs nothing to reuse a shift row and it removes an entire class of failure.

6. Expecting Calendar Changes to Move Existing Schedules

Symptom: You added a holiday, or removed a capacity override, and jobs are still planned on that day.

Cause: Calendar edits change the capacity map that the next scheduling run reads. They do not rearrange the current plan on their own.

Fix: Run a reschedule after any calendar change you expect the plan to honor. Two things to know while you do it. Operations already carrying actual dates from the shop floor are preserved exactly, because completed work is never moved by a reschedule. And if you want to see what a change would do before committing to it, run the affected orders and review the result before publishing to the floor.

7. Overriding Only One Shift on a Two-Shift Day

Symptom: A capacity override produced roughly half the hours you entered, or removing an override left a day with capacity that matches neither the formula nor your intent.

Cause: Overrides are keyed to a work center, a shift, and a date. One override covers one shift.

Fix: On a machine running day and night shifts, enter two override rows to change the whole day, and clear both when you remove them. Also remember what the override is for: it is the only calendar mechanism that can create capacity where the standing calendar has none, which is exactly how a Saturday of authorized overtime is modeled without editing the weekly pattern.

8. Modeling a Cell as Separate Work Centers Instead of Instances

Symptom: Long operations never finish faster despite having four identical machines. Every routing has to name a specific machine, and a job waits for its named machine while others sit idle.

Cause: The cell is modeled as four work centers rather than one work center with four instances.

Fix: Model identical, interchangeable machines as instances on a single work center. Load balancing then splits an operation across all of them so a 20-hour job finishes in 5 elapsed hours, and any job can use whichever machine is free. If the machines are similar but not identical, with different speeds or setup times, the right structure is a machine pool instead: see what a work center group is.

One related trap: a work center flagged for one job per instance per day with only a single instance can accept exactly one job per day in total. That is correct for a single furnace and surprising for anything else. If several jobs should run that day, raise the instance count to match the number of physical chambers.

Two Symptoms That Are Not Mistakes

Some results look wrong and are not.

A job spans more calendar days than it has hours. A 20-hour operation starting Friday at noon on a weekday-only calendar finishes Tuesday afternoon. Four elapsed days, 20 machine hours. Days with no configured shift are skipped and cost nothing, so elapsed time and consumed capacity are different quantities. Reading one as the other is the most common misdiagnosis on this feature.

A job takes the day shift when the night shift is emptier. Slot ranking gives a large bonus to a shift that can start immediately, and that bonus intentionally outweighs available capacity. A job released at 09:00 correctly takes this morning's remaining hours rather than waiting for a bigger empty block tonight.

If a gap in the plan still looks wrong after those two checks, idle gaps in the schedule walks through the real causes, and work center overloaded covers the opposite symptom.

The Five-Minute Audit

Run this before your next schedule, once per work center. It catches all eight mistakes above and takes about five minutes for a shop with twenty machines.

1. Shift hours. Do they describe the productive window or the gross clock? Nothing scales them down afterwards, so every shift should carry hours somebody chose.
2. Instance count. Does it match the number of physical machines the work center represents? Cells of identical machines should be instances, not separate work centers.
3. Assigned shifts. Does the list contain every shift this machine actually runs? Open one and confirm its weekday hours are not zeroes.
4. Global shifts flag. Is it on where you meant per-machine hours to apply?
5. Shared shift records. For any machine that must run alongside another, does the same shift row appear on both?
6. Standing exceptions. Are this year's plant holidays entered, and are planned maintenance windows on the calendar rather than in somebody's head?

The order matters. Shift hours and instance count set the size of every slot, so a mistake there distorts everything downstream and is invisible in the schedule itself. Shift assignment errors are noisier and easier to spot. Calendar gaps announce themselves eventually, usually as a job scheduled on a day the plant is closed.

If you would rather check the output than the settings, the capacity view is the fastest read: scan for work centers sitting at zero on days they should be running, and for any machine reading above 100 percent that is not deliberately configured as a synchronized mirror. Both are configuration signatures rather than engine faults.

Where to Go Next

Once the shift calendar is right, the rest of the platform stands on it: anchor scheduling around a bottleneck and parallel work centers both place their work through the same allocator. The complete guide to EDGEBIC is the map of how those pieces connect, and what multi-shift scheduling is is the shortest route to a shared vocabulary with your team.