The shift should not stop when the connection does

At twenty past six on a Tuesday morning the plant’s internet connection fails. An excavator two streets away has gone through a cable. The machines do not notice. The operators do not notice either, until they try to book the first order of the shift and the screen shows a spinning wheel.

What happens next depends on a decision that was made, usually without much discussion, on the day the software was bought.

The office assumption

Most business software is now built on the assumption that a connection is always there. For an office that is reasonable. An outage means email waits, a meeting moves and a morning is lost. Annoying, recoverable, and rarely anybody’s fault.

A production floor does not have that kind of slack. The shift has started, the material is staged and the machines are running whether or not the system can record what they do. When the floor system lives somewhere else, the plant has three options, and none of them is good.

Stop booking. Production continues and the record does not. Somebody reconstructs it later from memory and scraps of paper, and the gap becomes a permanent hole in the traceability.

Go back to paper. The paper procedure still exists in theory. In practice the forms are out of date, half the shift has never used them, and everything has to be typed in again afterwards.

Wait. If the line needs the system to release work, label product or record a check, an outage is a stoppage. This is the case nobody planned for and everybody pays for.

It is not only the cable

The connection is the obvious dependency and the easiest one to see. There are others that behave exactly the same way when they fail.

The supplier’s service. Planned maintenance on the vendor’s side, scheduled for a time that suits the vendor’s time zone rather than your night shift.

The subscription. A renewal stuck in purchasing, a price change, a product line retired with twelve months’ notice. Commercial decisions taken elsewhere that land on your floor.

The data. Production history is the most valuable record a plant has, and in many systems the hardest one to take with you. If your genealogy lives in somebody else’s database, so does the answer to your next recall question.

None of these is likely on any given day. Over the life of a production system, which is measured in years, most of them will happen at least once.

Local first, as a requirement

For a system that sits on the shop floor, the practical consequence is simple: it has to run in the building.

Runs on your premises. On hardware you control, inside the network the floor already depends on.

Keeps working with nothing outside. Bookings, scans, machine reads and the current state of every order carry on when the outside connection is gone. Anything that genuinely needs the outside world waits for it, rather than the other way round.

Your data in your database. Stored where you can back it up, query it and keep it, without asking anybody’s permission.

That is what sovereignty means in a factory. Not a position on geopolitics or a line in a brochure, but whether the shift can carry on when something outside the gate goes wrong.

The question to ask before you sign

Of any system that will touch the floor, ask what happens on the morning the connection fails. Not whether it is unlikely, and not what the uptime figure is, but what the operator standing in front of the screen will see and do. The same question is worth asking about the day the supplier changes its prices, and the day you want to leave with your whole production history.

If the honest answer is that they wait, the system is part of your production line — and it should be held to the same standard as everything else on it.