A job that carries its own route through the factory

A job in a multi-process factory is not one operation. It is ten or fifteen, in an order that depends on what is being made. Plates and dies have to arrive. Material has to be cut. The work prints, laminates, gets coated, foiled, punched, pasted, packed. Each of those is a different team, usually a different machine, sometimes a different building.

The job itself, meanwhile, is tracked on a paper bag that travels with the work.

What the paper job bag cannot do

• Only the person holding it knows where the job has actually reached
• "Where is this order?" is answered by walking the floor or ringing a supervisor
• A job waiting on a plate, a die, or a material looks identical to one being worked on
• Sequencing is decided at each machine, so an urgent job is only urgent where somebody has been told
• Output per process, per machine, or per shift is unmeasurable, because nothing records it
• When something goes wrong, reconstructing what happened means asking people what they remember

Give the job a route it carries with it

The route is configuration, not code

The factory keeps a catalogue of every process it can perform, each with the team that owns it and its natural position in a sequence. A job type carries the list of steps that kind of work requires. Creating a job instantiates that route: the steps it will pass through, in order, each one waiting on the one before it.

Adding a new product type is then a configuration change - pick its steps - rather than a development task. That distinction is what stops the system going stale the first time the factory takes on work it has never run before.

Each process records what that process actually does

A printing step and a lamination step have almost nothing in common in what they need to capture. Rather than a generic checklist with a notes field, each step type has its own record and its own fields: the machine, the material drawn, the counts, the settings that matter to that operation and to no other. What they share is only the status, the position in the sequence, and the timestamps.

Priority where sequencing actually happens

Steps carry a priority order and a date, and priority can be set per machine - because sequencing is not decided for the factory as a whole, it is decided at each punching machine and each fabrication line by whoever is loading it. Modelling it that way means the plan on the screen is the same plan being worked on the floor, rather than a management view nobody downstairs recognises.

Timestamps, run logs, and an expected duration per process

Every step records when it started and when it completed. Run entries underneath record the quantity completed, the material consumed, and who completed it, which is what turns output per step, per machine, and per shift into something you can report rather than estimate.

Each process type also carries an expected duration, so a step running past it surfaces on its own while there is still time to do something about it.

Everything that happens before the first machine

Plates, dies, blocks, and positives are received against the job that needs them, so a job blocked on tooling is visibly blocked on tooling rather than just sitting still. Where a customer has to approve a physical sample before production starts, that gate sits in front of the route as a step of its own instead of depending on somebody remembering it.

One trail, for afterwards

Every status change writes an entry: which step, from which status to which, by whom, and when. Job-level changes keep the values before, the values after, and the difference between them. When a customer raises a complaint it attaches to the job that caused it, next to the record of how that job was actually made.

When this is worth building

A workshop with three processes and one supervisor does not need this - the whiteboard is genuinely faster. It becomes worth building when the number of processes exceeds what one person can hold in their head, or when jobs routinely wait at a step nobody realises they are waiting at.

The usual trigger is a delivery date missed for a reason that turns out to have been avoidable: a job sitting idle waiting for a die that had arrived a week earlier, or an urgent order sequenced last at the one machine that mattered. Both are visibility problems, and both stop happening once the job carries its own route.