What Is a Schedule Change Type?

A schedule change type is the classification stamped on each row of a job's schedule change history, recording what kind of change the row represents rather than just when it happened. Every movement of a scheduled operation is written to an append-only audit trail, and the change type is the label that makes that trail readable. EDGEBIC by User Solutions stamps one on every entry so a planner reviewing a job can tell engine behavior apart from human decisions at a glance.

How it works

The change history is append-only. Nothing is edited or removed, so a job accumulates a complete record of everything that ever happened to its schedule. That completeness is only useful if the rows can be told apart, which is what the change type does.

Six classifications cover the lifecycle. Initial marks the first time a job was placed on the schedule, the original commitment everything afterwards is measured against. Reschedule marks the engine replanning the job, whether that was a full replan, a nightly incremental run, or a targeted rerun after something changed. Work center swap marks an operation moving from one machine to another. Date override marks a planner manually dragging a bar to new dates. Closed marks an operation being reported complete, with an actual end date recorded. Reopened marks a completed operation being unlocked again after a close-out turned out to be wrong.

The value of separating these is that identical-looking date movements have very different meanings. Two operations can both end three days later than planned. If one moved under a reschedule row, the engine did that in response to conditions, and the question to ask is what changed upstream. If the other moved under a date override row, a person did that, and the question is who and why. Without the type, both are just dates that changed.

The types also mark the boundary of what the scheduler will still touch. A closed operation is historical fact and the engine leaves it alone on future runs. A reopened row is therefore significant: it is the record that a piece of history was deliberately reverted to something the engine may plan again.

A concrete example

Think of the revision history on a shared document. Everyone can see that the text changed on Tuesday, but the history is only useful because it also says what kind of change it was: created, edited, formatting, comment resolved, restored to earlier version. "Restored to earlier version" is a very different event from "edited", even though the visible result is the same words on the page.

Now put that on a job. Job 42 shows an initial row from the first Monday, three reschedule rows across the following week, one work center swap moving step 3 from Mill-1 to Mill-2, a date override on step 5, and a closed row on step 1. Read only the dates and you have a job that wandered. Read the types and you have a narrative: the engine replanned three times as actuals came in, the shop moved one operation to a different machine, and a planner deliberately pushed one step out. Three of those are the system doing its job. One is a decision with a person behind it.

How EDGEBIC uses it

Every change to a scheduled operation writes an audit row carrying its change type, and those rows are what the job audit trail reads back. The trail itself is the glossary term schedule change log, and running it for a specific job is covered in how to run the job audit trail.

Because the types separate engine activity from manual activity, they are what makes a disputed date answerable. That use is walked through in how the audit trail settles schedule change disputes and in the schedule change log audit trail. The engine activity behind the reschedule rows is defined in what is a reschedule.

A schedule change type is the difference between knowing that a job moved and knowing why. For the wider vocabulary, see the manufacturing glossary, and to see a live change history against a real plan, explore EDGEBIC.