Who Does What After the Scheduler Goes Live

After a scheduling system goes live, the production planner stops building the schedule and starts governing it, and four other roles pick up small, specific duties that keep the model matching the floor. The failure mode is not that anyone refuses. It is that nobody is named, so the work that keeps a schedule accurate (data maintenance, deviation reporting, actuals logging) becomes everyone's job and therefore no one's.

This guide sets out the operating model that works with EDGEBIC by User Solutions: what each role does daily and weekly, what changes from before, and what happens when each part is skipped. For the permissions side of the same question (which role can edit what in the system), see users and roles explained. This page is about job design rather than access control.

The Planner: From Builder to Governor

The largest change lands here, and it is easy to misread as a reduction in the job. It is not.

What moves to the engine: sequencing against finite capacity, the arithmetic of net shift hours times machine instances times utilization, cascading a change through every downstream operation, and charging the correct changeover for each transition. All of that was previously done in a head or a spreadsheet and all of it is now computed.

What stays with the planner, and gets more of their attention:

• Priority judgment. Which customer genuinely comes first when two jobs compete. The engine can rank by due date; it cannot know that one of those customers is in a contract renewal.
• Promise-date negotiation. When a quoted date is not achievable, someone has to decide whether to add capacity, re-sequence, or renegotiate. That is a business decision.
• Override discipline. Every manual override is either judgment (legitimate) or a symptom (a data error). Distinguishing them is the planner's most valuable habit.
• Model integrity. Someone has to believe the schedule enough to defend it, and that requires knowing that the inputs are right.

The planner's daily rhythm

The planner's weekly rhythm

That anomaly review is the highest-value recurring half hour in the whole operating model. The report runs roughly forty named checks covering over-utilization, instance collisions, dependency violations, off-calendar bookings, configuration gaps and setup matrix integrity, and it typically finds problems before the floor does. See how to run and read the anomaly report.

If this role is unowned: the schedule is run irregularly, the floor cannot rely on when it appears, and small data errors accumulate until schedules look visibly wrong.

The Master Data Owner: The Quiet Critical Role

Often the same person as the planner in a small shop, and it must still be named separately, because it is the task that gets dropped first when a week is busy.

What they own:

• Routings. Operations, sequence, hours per piece, setup time. When a process changes on the floor, the routing changes in the system. See how to build a routing step by step.
• Work center capacity. Machine instance counts, utilization percentages, and whether the configuration still matches the physical shop. A machine sold in March that is still in the system in June inflates every capacity number that touches it. See how to set up work centers.
• Calendars. Shifts, plant holidays, and the per-day capacity overrides that carry approved overtime, maintenance days and de-rated machines. Standing maintenance has no record of its own in the current release, so it has to be netted out of the shift hours or entered as overrides on the dates it happens: a weekly one-hour block the calendar does not know about is 52 hours a year of phantom capacity per machine. See the calendar setup guide.
• The setup matrix. True from-to changeover times, maintained as products and processes change. In the documented paint booth example these are the numbers that separate a plan claiming 90 minutes of setup from a floor living through 510. See the setup matrix explained.

Time required: about thirty minutes a week in a steady state, concentrated after any process or equipment change.

If this role is unowned: the model decays over roughly a quarter. Nothing breaks visibly; schedules just get progressively less credible until someone declares the software the problem.

The Supervisor: From Private Sequences to Deviation Reporting

Before scheduling software, a good supervisor keeps a private list because the published plan cannot be trusted. That list is skilled work and it is also the mechanism by which the official schedule stays irrelevant.

What changes: the supervisor executes the published sequence and reports deviations rather than silently absorbing them.

What they report, and why it matters:

What they still decide: which operator runs which machine, how work is staged, and anything that depends on being physically present. The schedule sets sequence, not assignment of people to stations, unless you are using operator and skill scheduling, which adds qualification constraints to the plan. See operator and skill scheduling explained.

If this role is unowned: deviations stay on the floor, the model drifts from reality, and within a couple of months the private list is back.

The critical dependency here is responsiveness. A supervisor who reports three problems and sees none of them fixed stops reporting on the fourth. Visible, fast correction is what sustains this loop, which is the subject of getting the floor to trust the schedule.

The Operator: Log What Happened

The smallest duty and the one the whole rescheduling behavior depends on.

Operators record actual hours and pieces, and a reason code when work stops. The shop floor terminal captures punches by state (setup, run, idle, down, rework, teardown) with reason codes grouped into machine, material, quality and waiting categories. Every supervisor correction to a closed punch is written to an append-only adjustment record, so nothing is silently rewritten.

Why it matters more than it looks: a reschedule preserves completed and in-progress work verbatim and re-plans only what has not happened yet. That behavior is what makes a mid-week reschedule acceptable to the floor. It is also only as good as the record of what has actually been done. See how actuals flow into the schedule and how to log actual hours and pieces.

Time required: seconds per state change.

If this is skipped: rescheduling works from stale information and produces plans that look wrong to the people who know what really happened. This is the most common single cause of a struggling implementation at day 90.

Sales: Quote From the Schedule

The role change here is one sentence long and frequently ignored: promise dates come from the schedule, not from asking a supervisor.

A date produced by quote simulation is the result of actually scheduling the prospective job against current committed capacity. A date produced by asking someone is an estimate built on partial information about this week. See how a quote becomes a promise date.

If this is skipped: quoted date accuracy never improves regardless of how good the schedule gets, because quoting is running off a different model. This is the most common reason a healthy implementation shows a flat on-time number at day 90.

IT or the System Administrator: Light but Real

A small, genuine duty set: database backups, user and role administration when people join or change jobs, and the periodic import runs if master data arrives from an ERP.

That last one is worth being precise about. Data moves in and out through configurable Excel, CSV and database import masks rather than a certified connector to any named ERP: you map your columns to the target fields once, save the mapping, and reuse it, including a conversion factor for cases where your file stores setup in minutes and the schedule stores hours. See import masks explained and how EDGEBIC protects your schedule data.

The One-Page RACI

A is accountable, R performs the work, C is consulted, I is informed.

The Three Named People Test

Before go-live, answer these out loud with names rather than job titles:

1. Who runs the schedule, at what time, every day?
2. Who owns the routings, capacities and calendars, in a protected weekly slot?
3. Who reviews the anomaly report weekly and clears the items?

If any answer is a department rather than a person, the work will not happen. That is the single strongest predictor of whether an implementation still looks healthy at day 90, which is covered in what changes by day 90.

For the wider implementation risk picture, see the real risks in a scheduling implementation. For the mechanisms behind each documented result, see the measurable results guide.

To talk through how this operating model fits your shop's headcount, contact US and bring your current scheduling routine. We will map it against what EDGEBIC actually asks of each role.