Moving an Operation to Another Machine on the EDGEBIC Gantt

You reassign an operation to another work center in EDGEBIC by dragging its bar from one machine lane to another: the move stages as a pending change, saves as the Resource Replaced state, and can survive the next reschedule so a deliberate reroute holds. EDGEBIC by User Solutions treats a machine change as a first-class action, distinct from a simple time move, because rerouting work carries different consequences than shifting a date. This post walks through the reroute, what it records, and how it behaves afterward.

For the full drag vocabulary, see drag-and-drop rescheduling; this post focuses on the specific case of changing which machine runs an operation.

Drag Across Lanes to Reroute

The Schedule View Gantt draws each work center as its own horizontal lane, and each bar is one operation of one job on the machine whose lane it sits in. To move an operation to a different machine, you drag its bar out of its current lane and drop it onto the target machine's lane.

The moment you drop it, the bar turns to the Overridden state, exactly like a time-only drag. Nothing is committed yet; the reroute is a pending change staged in memory. The pending-changes count on the toolbar goes up by one, and you decide its fate with the two buttons that govern every edit:

You can drag the bar sideways to a new lane and forward or backward in time in the same move, and both the machine change and the time change stage together.

Resource Replaced: a Machine Change on the Record

A plain time move saves as Applied. A machine change saves as Resource Replaced, a separate state with its own color, because EDGEBIC wants the reroute to be visible and auditable, not hidden inside a generic edit.

When you Save a lane-to-lane move, EDGEBIC records the new work center and keeps the original one stored alongside it. That is what lets the bar show the Resource Replaced color on every later reload, not just in the session where you moved it. Anyone reading the schedule next week can see at a glance that this operation was steered off the engine's chosen machine, and the Resource Replacement Audit records who did it and when. A reroute is a decision worth remembering, and EDGEBIC remembers it.

The Override-and-Warn Contract

Here is the part planners must understand: saving a reroute records the machine change; it does not re-check the new machine's capacity. This is EDGEBIC's deliberate override-and-warn model. You can drag an operation onto a machine that is already busy, EDGEBIC will warn you about a questionable move, and it will still let you save.

That trust is intentional. When a machine goes down and you know an alternate can absorb the work, you should not have to argue with the software. You are the planner; EDGEBIC stages your judgment and records it. What it will not do is silently pretend the new machine has room it does not have, and what it will not do is re-plan the rest of the job on its own. Those are separate, explicit steps.

If you move more than one operation of the same job to different machines, EDGEBIC adds a multiple work center replacement warning so a sweeping reroute is a conscious act. Review the pending set, confirm the moves, and Save, or Discard the whole batch if it was wrong.

Letting the Engine Re-Plan Around the Reroute

Saving records dates and machines. When you want the engine to actually re-plan the job around your reroute, press Re-Schedule. It re-plans only the jobs you touched and leaves the rest of the plant alone, so a single machine swap does not disturb forty other jobs.

A reroute you commit with Save Changes is remembered by the engine as your intent, so a reschedule respects it rather than snapping the operation back to the original machine. This is the same principle behind a planned start pin: a deliberate placement, once saved, survives the next engine run. Choosing an alternate machine is exactly the kind of flexibility finite capacity scheduling is meant to give you, made direct with a drag.

A Worked Reroute

CNC-1 goes down at mid-morning, and a job's milling step is due to run there today. CNC-2 is free.

1. Open Schedule View and find the milling bar in the CNC-1 lane.
2. Drag it onto the CNC-2 lane. The bar turns Overridden; the pending count reads 1.
3. Press Save Changes. The bar commits as Resource Replaced, recording CNC-2 as the new machine and CNC-1 as the original.
4. Press Re-Schedule. The engine re-plans this job's remaining steps around CNC-2. Downstream operations that may now be out of sequence briefly flag for review, then settle on reload.
5. Every other job in the plant is exactly where it was.

Three clicks moved real work off a broken machine and kept the record honest about where it now runs.

When a Reroute Is Blocked

There is one deliberate exception. Certain capacity-request jobs have work center replacement disabled by configuration. If you drag one of those to a different lane, EDGEBIC accepts the time shift but silently reverts the machine change and tells you so in the status message. That is by design: those jobs are meant to stay on their assigned machine. For every ordinary production operation, the lane-to-lane reroute works as described.

Why Machine Moves Get Their Own State

It would have been simpler to treat every drag the same. EDGEBIC does not, because a machine change and a time change ask different questions later. Was this job run late, or run somewhere else? Which operations were steered off plan, and onto what? By saving a reroute as Resource Replaced and preserving the original machine, EDGEBIC keeps that answer legible for the planner, the supervisor, and the audit trail. A reroute is a small decision with a long memory, and that is exactly how a scheduling system should treat it.

See the full EDGEBIC platform, read the visual scheduling pillar guide, or bring a down-machine scenario to a demo and reroute a live job onto its alternate with US.