A targeted reschedule is a scheduling run whose scope is deliberately limited to a named set of jobs, so only those jobs are re-planned while every other job keeps both its plan and its reserved capacity. It is the counterpart to a whole-plant run, and on a busy floor it is usually the correct one. The reason is not performance but stability: a schedule that changes only where something actually changed stays believable, and a schedule that reshuffles a hundred jobs because one machine broke does not. EDGEBIC by User Solutions remembers the jobs you touched and offers a Re-Schedule button that re-plans exactly those.
How it works
Scope is the only thing that differs between a targeted run and a full one. The engine, the preservation rules, and the capacity math are all identical. What changes is which jobs are opened.
Jobs in scope are re-planned normally. They go through the same three-zone treatment every reschedule uses. Completed operations are preserved exactly as recorded and never re-placed. Operations already in progress keep their machine and their recorded start, with only the remaining hours planned forward. Everything not yet started is planned again from the job's real resume point.
Jobs out of scope are not opened at all. Their operations keep their dates, their machines, and their instance assignments. Critically, the capacity they have booked is still visible to the run as claimed. That distinction is what makes a targeted run safe: an out-of-scope job is invisible as a candidate for change but perfectly visible as a consumer of hours.
The modified set is tracked for you. Saving a change on the board marks that job as touched since the last run, so pressing re-schedule immediately afterwards picks up the right set without anyone having to remember it. Where a planner wants a different scope they can select jobs explicitly, or re-plan a single job from its own view.
The trade-off is easy to state. A targeted run cannot improve a job by taking capacity from one it was not asked to consider. If job A would finish two days earlier by displacing job B, a targeted run on A will not do it, because B is out of scope and its hours are treated as spoken for. A full run would consider the swap. Whether that is a loss depends entirely on whether anyone has acted on B's plan yet, which is a judgment the software cannot make and the planner can.
A concrete example
A job runs saw, mill, then paint. The mill was down Monday, so the planner drags the mill operation to start Tuesday morning and saves. The mill bar now records a Tuesday start. Paint, still planned for Tuesday afternoon, is flagged for review because it now overlaps the mill's new end.
The planner presses re-schedule. The run's scope is one job.
Within that job, the mill's recorded start survives untouched, because recorded work is never re-placed. Paint is re-planned forward from the mill's new end and lands Wednesday morning. Its review flag clears on reload. Saw, which is complete, does not move at all.
Everything else in the plant is exactly where it was. The two jobs sharing the paint booth on Tuesday keep their slots, which is why paint landed Wednesday rather than Tuesday afternoon: the booth's Tuesday hours are claimed by jobs the run was not asked to move. The supervisor's printed list for the rest of the week is still accurate for every job except the one that changed, and the one that changed is the one everybody already knows about.
Compare that with a full run. It might well have found a better global arrangement, perhaps by moving one of those other jobs off the booth. It would also have handed the supervisor a list that no longer matches the one on the wall, for a reason nobody on the floor witnessed. That is the cost a targeted run exists to avoid.
How EDGEBIC uses it
Targeted rescheduling is the polite option on a busy plant, and it is the standard second half of any manual override. The full sequence is drag, save, then re-schedule: the drag and save record what you decided, and the targeted run lets the engine work out the consequences within the affected job only. Running it is covered in how to reschedule only the jobs that changed in EDGEBIC.
What the run preserves inside a job in scope is the same contract every reschedule honors, described in what is actuals preservation on reschedule and worked through in how EDGEBIC preserves completed work on reschedule. The point where remaining work restarts from is covered in what is the next step start date in rescheduling.
The most common reason to reach for a targeted run is a flag left behind by a manual move, which is described in what is a downstream changed flag in scheduling. For the broader picture of what a run does and does not touch, see EDGEBIC rescheduling explained.
The takeaway
A targeted reschedule is a scoping decision, not a different algorithm. Everything the engine does inside an in-scope job is exactly what it always does; the discipline is in refusing to open jobs nobody asked about. That refusal is what stops a schedule from becoming something the floor learns to ignore, because a plan that only changes when something real changed is a plan people keep reading. Reach for a full run when the plant genuinely needs re-optimizing, and for a targeted one every other time. For the wider vocabulary see the manufacturing glossary, and for the product itself see EDGEBIC.
A targeted reschedule is a scheduling run whose scope is limited to a named set of jobs, usually the ones a planner just edited, so that only those jobs are re-planned. Every job outside the scope keeps its plan and, just as importantly, keeps its reserved capacity, which the run treats as unavailable. The result is a schedule that absorbs one disruption without redistributing the consequences of that disruption across a plant that had nothing to do with it.
Because a full run can move jobs nobody asked it to move, and every move has a cost on the floor that the schedule itself cannot see. A supervisor has already assigned people, staged material, and printed a list; an operation that shifts machines overnight for a small mathematical gain destroys work that was already done. Scoping a run to what actually changed is what keeps a live schedule trustworthy, which is worth considerably more than a marginally tighter plan.
The jobs you touched are remembered. Saving a change on the board marks that job as modified since the last run, and the targeted run picks up exactly that set. You can also scope explicitly by selecting jobs before running, or re-plan a single job from its own view. In every case the rule is the same: jobs in scope are re-planned under the usual preservation rules, and jobs out of scope are not opened at all.
Almost certainly because it belongs to a job that was not in the run's scope. A targeted run only re-plans the jobs it was given, so an operation in a neighboring job that was affected by your change stays where it is. If that neighbor genuinely needs to move, either edit and save something on it so it joins the modified set, or select it explicitly and run again. A review flag still showing after a run is usually this, and is worth a second look rather than an alarm.
No. Capacity reserved by jobs outside the scope is respected exactly as if those jobs were being planned in the same run. The run sees those hours as claimed and places the in-scope work around them. What a targeted run will not do is take capacity away from an out-of-scope job in order to give an in-scope job a better slot, which is the whole point: the trade would improve one job at the cost of a plan somebody had already acted on.
Expert Q&A: Deep Dive
Q: I ran a targeted reschedule and a downstream operation still looks out of sequence. Why did it not move?
A: Almost certainly because it belongs to a job that was not in the run's scope. A targeted run only re-plans the jobs it was given, so an operation in a neighboring job that was affected by your change stays where it is. If that neighbor genuinely needs to move, either edit and save something on it so it joins the modified set, or select it explicitly and run again. A review flag still showing after a run is usually this, and is worth a second look rather than an alarm.
Q: Does a targeted reschedule risk overbooking a machine that other jobs are using?
A: No. Capacity reserved by jobs outside the scope is respected exactly as if those jobs were being planned in the same run. The run sees those hours as claimed and places the in-scope work around them. What a targeted run will not do is take capacity away from an out-of-scope job in order to give an in-scope job a better slot, which is the whole point: the trade would improve one job at the cost of a plan somebody had already acted on.
Frequently Asked Questions
Ready to Transform Your Production Scheduling?
User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.
User Solutions Team
Manufacturing Software Experts
User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.