The Schedule Should Live Where a Second Person Can Open It

The owner's question

Sooner or later a plant owner asks the question. When the planner is on holiday, ill, or has handed in notice, who else can run this week's schedule? The question stays unasked while the schedule works. Ask it in a quiet month and the answer is reassuring, because the planner knows. Ask it when it matters, the week before the holiday or the day the notice lands, and the answer turns out to depend on one person being available and one memory being intact. The plant has an artifact: a spreadsheet, a whiteboard, a printed grid. What it does not have is an artifact a second person can drive. The rows are visible; the reasoning that produced them is not, and the changeover estimates and conflict checks behind them live with one person. In that plant, the honest answer is nobody.

Four things a head-held schedule makes impossible

Together they make planning capacity a single point of failure. Holiday cover, illness, a notice period, each one is a bet that one person is available and able to reproduce the schedule on demand. The risk is not just the schedule itself; it is the capacity to produce it.

This is not the planner's fault

None of this argues for replacing the planner. Field studies of real production scheduling have long observed that experienced planners absorb machine failures, expediting and policy changes with heuristics that formal systems struggle to match. That judgment matters, and it is mostly tacit: it resists being written down or captured in a file. The argument here is about the record, not the role. A schedule that exists only in one person's head cannot be opened by a second person, however good it is. The sharpest version of this problem is the plant where one or two people hold the whole picture and cover for each other; the question is not how many planners there are, but how many people can open the schedule.

The fix is a record, not a memory-capture project

The failure is architectural, not personal: the schedule has no durable home. A standard intervention for knowledge-loss risk is documentation, but not a binder of handover notes assembled in the last month of a notice period. The fix is that the schedule itself becomes the record. A schedule that lives in team data is a necessary first step, and only a first step: it makes the record openable, verifiable, and possible to take over. It does not transfer the planner's expertise, because no file can, but it ends the silent dependence on one person's memory.

The schedule and the setup as team-owned records

In Schantt, the schedule and the setup that produced it are team-owned data, not the output of one person's working memory.

The schedule is a persisted record: every scheduled operation carries its position in the production sequence, its quantity, its machine, and its timings, and it is visible row by row in tables, API views, and the Gantt chart. It does not leave with the person who built it.

The setup that produced the schedule, the configuration that describes how the plant runs, is a persisted record too. Stages, machines, product classes, products, per-class routing, batch sizes and cycle times, line throughputs, changeover times, transfer times, calendars, and calendar exceptions: all of it is team data. Nothing about how the schedule was built is required to live in a head.

Both records live inside one team's scope. Access follows the team's roles, administrator or member, and that is the boundary: one team, one planning scope, one set of people who can open the schedule. Handing over and taking over start from the record instead of from zero. A successor's entry point is the same team data everyone else sees; there is no dependence on the departing planner's private notes.

The schedule can be verified against its own record. A schedule entered in Schantt has passed the routing, machine, position and calendar checks, and it is stored with its timings, so the owner does not have to take the planner's word. When the schedule is built with Auto or Semi-Auto optimization, the accepted solution's timings are persisted the same way.

This record is what is scheduled, not what is happening on the floor right now. It is the schedule, not live status. And it is still something a person builds and owns. Manual mode stores a human decision; Auto and Semi-Auto optimize the part of the plant you have configured. The planner stays central; only the memory becomes shared.

What changes for the owner

Holiday and illness stop being all-or-nothing bets, because a second person can open the schedule and pick up from the record. What they pick up is the schedule itself, not the planner's judgment. Departure and retirement start from something rather than nothing: the record exists independently of who built it, and it does not walk out the door when the person does. The owner no longer takes the schedule on trust.

The coverage gap on a holiday, the delay while a successor gets up to speed, the capacity at risk during a notice period: what used to sit with one person now sits in team data, where it can be looked at. It does not make the successor an instant expert. It removes the part of the risk that was never about skill: the part where the schedule itself was inaccessible.

The takeaway

The schedule should be an asset the plant owns, not a memory one person holds. Four questions to check whether yours is, this week:

1. Can a second person open this week's schedule, right now, without asking anyone?
2. Is the configuration behind it recorded in team data?
3. Can the schedule be checked against its own record?
4. What happens on the planner's next holiday?

If the first three answers are no, the fourth is the risk you are already carrying. A schedule that lives where a second person can open it is a schedule the plant owns. Build that home the year before you need it, not the week after.