Pattern from the field · Manufacturing

Two Systems That Disagreed on Order State

A manufacturer's order system wasn't slow. It was lying, and three people cleaned up after it every morning. A tight, one-domain fix that paid back in year one.

Manufacturing · Anonymised client pattern

The situation

A manufacturing client called us because their order system was “slow”. It was not slow. It was lying, and three people spent the first hour of every working day cleaning up after it.

Orders lived in an old ERP. Production scheduling lived in a tool someone bought in 2019. A nightly export tried to keep the two in step, and failed often. When it failed, staff patched the gap by hand and trusted their gut over the screen. By the time we arrived, the workaround was the process. Nobody believed either system. They believed a spreadsheet a shift lead kept on her own laptop.

What was really going on

The two databases disagreed with each other, and there was no agreed answer to a simple question: which system is right about the state of an order? The nightly batch quietly picked a winner whenever rows conflicted, and often picked wrong. The result was a slow erosion of trust until the official systems were treated as suggestions and the real record lived off to the side.

Underneath the technical fault sat the actual root cause: nobody at the company owned “order state”. Not in the code, and not on the org chart. Two systems both believed they were authoritative, and no person was responsible for saying which one won.

What we did

We scoped it tight on purpose: one domain, order state, not the whole ERP. Three moves.

First, pick a winner. The ERP, because that is what finance and the customer see. Obvious on paper; it still cost a week of meetings, because the floor had real reasons to trust the newer tool’s timestamps.

Second, replace the nightly export with an event-driven sync that retries, and when two rows genuinely conflict, drops them into a manual-review queue instead of silently choosing one.

Third, move reconciliation out of people’s heads and into code, with tests.

The first version made things worse. It resolved toward the newer tool, finance caught a mismatch within two days, and for a week the shift lead’s spreadsheet came back out. We flipped the winner, added the review queue, and it settled. Not the clean arc that sentence makes it sound, but honest. This is what real systems integration looks like: clear ownership of the data, explicit conflict handling, and the discipline to correct course when the first cut is wrong.

What changed

Now the money, openly estimated rather than audited, because that is the part these stories usually skip.

Those roughly 750 person-hours a year of re-typing, fully loaded at about EUR 40 an hour, came to around EUR 30,000 burned re-entering numbers two systems should have agreed on themselves. The build was two engineers for six weeks, call it EUR 55,000. Labour savings alone do not pay that back in year one.

The mis-shipped orders do. Two or three went out wrong every month: a re-pick, a re-ship, an annoyed customer each time. Put a conservative EUR 800 on each and that is another EUR 25,000 to 30,000 a year. That was the largest number in the story, and most case studies bury it in a parenthetical. Taken together, the fix paid back inside the first year.

Here is what we deliberately did not fix with code. Nobody owned order state on the org chart. We named who should and wrote it down. If that is ignored, someone buys another tool in 2028 that also wants to own orders, and the spreadsheet comes straight back. The integration was the easy layer. The ownership was the root cause.

So the real question is not technical. Who owns the data model at your company, by name, not by diagram? If you cannot answer that, talk to us, because your morning reconciliation ritual already has.

Anonymised, composite pattern drawn from real engagements. Figures are openly estimated, not audit-grade.

Recognise this in a system you own? We can talk it through.

The rewrite is the easy part. The diagnosis isn't.