The EDGEBIC Gantt View Explained: Plan vs Actual on One Timeline

EDGEBIC by User Solutions draws every job as a set of operation bars on one time axis, with the planned window and the logged actual window shown together, and dependency links between steps, so the plan and the reality are legible in a single picture rather than scattered across grids. The Job Gantt view is where a schedule stops being a table of dates and becomes something a human can read at a glance. This overview explains what the surface shows, how the plan-versus-actual baseline works, and why moving a bar is a staged proposal rather than an instant commit.

The Gantt is the visual companion to the tabular schedule. Where the reports catalog tells you which job, which step, and which hour in numbers, the Gantt shows you the same schedule as shape and slope. Both read the same committed plan, so they never disagree.

One Timeline, Two Baselines

The defining feature of the Gantt is that each operation carries two windows on the same row. The planned window is what the scheduler laid out. The actual window is drawn from the hours and dates your shop logs as work happens. Seeing them stacked means drift is not something you calculate, it is something you notice.

A job that is running to plan shows its actual bars sitting under or beside their planned counterparts. A job that is drifting shows the tell immediately: an early operation whose actual bar starts late or runs past its planned end, with the gap widening as your eye moves down the routing. Because there is no separate "variance report" to open, the picture is the variance report.

Bars are color coded to carry status without a click. The same color logic that drives the rest of the scheduling surfaces feeds the Gantt, so a bar reads consistently here and in every other view. For the settings that control that appearance, see the settings that change how your schedule looks.

Dependencies Between Operations

Operations are not independent bars floating on a timeline. The Gantt draws the links between them straight from the routing: when step 20 cannot begin until step 10 finishes, the arrow between them says so. Those links are derived from the same sequence the scheduler uses, which is how the picture stays honest.

Once the dependency graph is on screen, you can trace the chain that actually decides the job's finish date by following the arrows forward from the first operation. This matters because not every late operation delays the job. An operation with slack can run long and the finish date holds; an operation on the longest chain cannot. Reading the links turns "which of these forty bars matters" into "watch these eight." For the mechanics of how EDGEBIC orders operations from a routing, see how EDGEBIC orders operations.

Drag to Reschedule, Staged Before It Commits

The Gantt is interactive, and the interaction is deliberately cautious. You can grab a bar and drag it to a new time, but the drag does not write anything to the schedule. Instead it stages the change: the bar moves on screen, the downstream operations that depend on it ripple to show the consequence, and the view waits for your decision.

Two buttons close the loop. Save commits the staged move through the normal reschedule path, writing it to the database and recording it in the change history. Discard throws the staged change away, and the Gantt snaps back to the committed plan with no trace left behind. This deferred-apply model is what makes the Gantt safe to experiment in. You can pull an operation earlier, watch three successors slide, decide the ripple is unacceptable, and discard, all without ever having touched the real schedule.

Because a committed drag runs through the same reschedule machinery as any other change, it respects the same rules: completed work is preserved, and the move is logged. If you want to understand what happens on a full reschedule, how to reschedule safely walks the guardrails.

What the Gantt Does Not Do

Being clear about the boundary keeps expectations honest. The Gantt does not run the scheduler; it displays the result of a run. It does not invent capacity when you drag a bar into a full day; the reschedule that a Save triggers is what re-solves the timing, and a manual drag is a request, not a guarantee that the machine was free. And it does not replace the reports, which carry the exact numbers, the KPI formulas, and the export-to-PDF trail that a Gantt image cannot.

Think of it as the reasoning surface. The scheduler decides, the reports document, and the Gantt is where a planner looks to understand and to propose.

Where It Sits in the Workflow

A typical loop runs like this. You create and schedule your jobs, then open the Gantt to sanity check the shape: are the longest chains landing before their due dates, is any job stacked awkwardly against a single work center, does the actual baseline show a job already drifting. When you spot a problem, you either drag a proposal and save it, or you jump to the tabular tools to make a structural change and re-run.

For the picture at the plant level rather than the job level, the dashboard tabs give the one-glance health read that tells you which job to open in the Gantt first. And for the full system these surfaces sit inside, the complete EDGEBIC guide is the map.

The Point of a Shared Timeline

The reason the plan and the actual share one axis, rather than living in two screens you mentally overlay, is speed of judgment. A planner should be able to look at a job and know in seconds whether it is fine, drifting, or in trouble, and know which single operation is the cause. Two baselines on one row and dependency arrows deliver that judgment without arithmetic. That is the whole design intent: make the schedule readable.

Want to see your own jobs drawn this way? Bring an export to a demo and we will put your routings on the timeline.