Night-shift knowledge belongs on the risk register

Ask a plant director what would happen if the three most experienced people on nights left in the same year, and the answer is rarely a plan. It is usually a pause, followed by the observation that it would be difficult.

That difficulty is a risk in the ordinary sense. It has a likelihood, an impact and, at the moment, no mitigation. It also happens to be the same problem that blocks unattended operation, which makes the case for addressing it stronger than either argument on its own.

One piece of work, two returns

Resilience. The judgement about which machine drifts, which material lot misbehaves and when to stop rather than continue lives in people. When they retire, change jobs or are simply off sick on the wrong night, the plant runs on less than it knows. Writing that judgement down in a form a system can read is also writing it down in a form a new operator can learn from.

Unattended hours. A system can only run without people where it knows what those people would have done. The context model and the exception taxonomy that unattended running needs are, in substance, the captured knowledge.

A business case built only on lights-out has to wait until the operation is ready. One that also counts the succession risk starts paying back from the first line that is properly captured, even if that line never runs unattended.

What it asks of your people

The cost is mostly time, and mostly from the people you can least spare.

Experienced operators and shift leaders. Structured sessions built around real cases rather than interviews, and repeated reviews of draft rules until they recognise their own judgement in them. Spread over weeks, scheduled around production, and including the night shift during its own hours.

Quality and process engineers. To reconcile what the shifts say with what the specifications and tolerances say, and to decide where the two disagree.

Somebody who can decide. Every exception type needs a defined response — continue, hold, stop or escalate — and some of those are management decisions about risk rather than technical ones. A plant manager or head of operations willing to make them is a prerequisite, not a nice-to-have.

IT and OT. Read-only access to equipment signals, MES and quality data. The context layer reads; it does not write to machines. Their part is small but on the critical path, because access arranged late delays everything after it.

Infographic

How the knowledge gets into the model

1. 01Real casesRecent deviations from the records, discussed with the shift.
2. 02Draft rulesConcrete enough to be wrong, so they can be corrected.
3. 03Shift reviewOperators correct them until they recognise their own judgement.
4. 04Supervised runningThe system decides, a person confirms, disagreements are logged.
5. 05New exceptionsAnything unrecognised stops, calls somebody and joins the taxonomy.

The part that is easy to get wrong

People asked to explain everything they know, in a programme whose stated aim is running without them, will reasonably wonder what happens to them. If that question is not answered honestly and early, the sessions produce polite and incomplete answers, and the model inherits the gaps.

What works is plain. Say what the programme is for and what it is not for. Credit the people whose judgement ends up in the model. Give them the role of reviewing and correcting it, which in practice is a role nobody else can fill, and which does not end when the first version is finished.

It also matters who runs the sessions. People talk differently to somebody from head office than to somebody who has come to learn how the line actually behaves at night.

Who should own the result

Not IT, and not the supplier. The context model is an operating document about how the plant behaves, and it needs an owner in operations who keeps it current as machines, materials and suppliers change. Without that owner it ages the way any manual does, only faster, because the system relying on it will not notice.

What a good outcome looks like

A line whose context model the night shift recognises as their own. An exception taxonomy that grows from every call rather than from workshops. A new operator who can read in it what used to be learned only at somebody’s shoulder.

Whether that line then runs unattended is a separate decision, made later and on evidence from supervised running. The knowledge is on the register either way, now with a mitigation next to it.

How we approach it

Dark factory context development captures tacit knowledge in structured sessions with the shift teams and turns it into a context model, an exception taxonomy and a decision record. For one line this usually takes two to four months, most of it spent with the people who work nights.