A system gets bypassed three months after go-live — and it is never because staff resisted it

Three months after go-live, the floor is keeping handwritten ledgers again.

The sentence you hear at this point is almost always “the floor won’t cooperate.”

It is a convenient explanation, which is why everyone reaches for it. It is also the one that blocks the most: once you attribute it to staff resistance, the investigation stops — because you cannot remediate an attitude.

Every bypassed system I have seen went down the same chain. Three links, and not one of them sits with the operators.

1. Bad numbers. The problem starts in the item codes, not the system

If material codes are inconsistent, no interface will save you.

The three common kinds of dirt:

One item, many codes — purchasing, the warehouse and production each call the same thing something different, so there are three records in the system
One code, many items — an old code gets reused and the history behind it becomes meaningless
Inconsistent units — purchasing counts cartons, the warehouse counts pieces, finance counts kilos, and the conversion rule lives in one person’s head

Leave any one of these uncleaned and the numbers are wrong from day one. Once the numbers are wrong, trust in the system starts draining — early, while nobody has noticed the project is in trouble yet.

This link sits entirely before go-live, and entirely with the project team.

2. The variances surface, and the system gets blamed for them

Book-versus-physical variances will appear in the first weeks. How you explain them decides whether anyone is still using the system later.

These variances are not the system miscalculating. They are historical error becoming visible for the first time.

Before, the books were the books and the stock was the stock; each was wrong in its own way and they were never really reconciled. The system puts both on the same screen for the first time. That number is not new. It was always there — nobody could see it.

What the floor sees, though, is: the books were fine before the system, and they stopped matching after it.

So the counting rhythm has to change with it — frequent counts over small areas first, absorbing the variances before you open things up. If you do not give the variances a window to be absorbed, they all land on the system’s reputation at once. And this has to be said out loud, to everyone, before go-live — not offered as an explanation after the variances appear.

The order in which you handle a variance matters just as much. What we do: the warehouse supervisor and the supplier go through the variances line by line together, agree on how each one will be settled, and only then sign.

Signing is the last step, not the first. Sign first and work it out later, and you are asking one person to carry a number that has no resolution attached to it. Nobody signs, and the whole thing hangs there. Agree the resolution first and signing is just confirmation, not taking the blame.

A lot of projects stall here, and it is not because the variances were large. It is because the process put the signature before the negotiation.

3. You genuinely did make them slower

“Scanning is slower than the paper slip” is usually true.

An experienced operator’s sequence has been optimized over a decade or more: check the location, then the batch, then confirm the quantity. Many systems order their screens by database field instead. When the two conflict, each transaction genuinely takes longer.

What shows up as “unwilling to change” is actually you genuinely made them slower — and they repeat that action a few hundred times a day.

There is a very common fingerprint for this. In the master data, the inbound-process and outbound-process tables are often completely empty. Nine configuration fields for inbound, seven for outbound. Not one row filled in.

An undefined process means the system’s built-in template applies by default. The template is ordered for a generic scenario, not for the way this particular shop floor moves. And defining the process is itself what forces the project team onto the floor to watch the sequence of actions once — skip it and you have skipped the one occasion where going to the floor was mandatory.

So the chain completes

Bad numbers → the floor stops trusting the system → they start a parallel handwritten ledger → the system is reduced to printing documents.

Not one of the three links sits with the operators.

So the next time you see a spreadsheet, a WeChat group or a paper slip on the shop floor, do not start by asking who is using it. Ask: what is it covering for that the system failed to do?

The answer is usually the link you missed.

There is one question I still do not have a good answer to: when is the absorption window over?

Everyone agrees variances need time to be absorbed. But what is the test for “absorbed”? A variance rate below some number? A few consecutive counts with no new variances? The floor no longer complaining?

I have seen it defined too loosely — six months on, people were still saying “we’re in the absorption period.” I have also seen it defined too tightly, where the window closed and every remaining variance turned into an incident.

What do you use as the condition for calling it done?