When the shop floor and the system clash, why is it always the system that gives way

In the projects I’ve run, whenever the shop floor and the system clashed, it was almost always the system that gave way. The reason is simple: by then the hardware is already installed. Changing hardware costs a lot and takes a long time; changing the system costs far less time and money.

There were exceptions. After acceptance, an entire automated warehouse was moved to a new location: a new commercial negotiation, a new schedule, three months in all.

In this series I want to go through these changes one at a time.

1. Once the AS/RS and AGVs are in, the system is the only thing left to change

Let me start with the most typical one.

Before the trial go-live, we found that orders couldn’t be released. For the system to release orders automatically, the production plan had to be fixed 7 days ahead and key materials had to arrive 3 days ahead. On the floor, the plan was still changing on the day itself; orders went out while the BOM was still being revised.

We didn’t change the floor. We changed the system: the “release” step went back to the planners, who now release by operation one day ahead. Everything after that, picking, allocation and outbound, stays automatic.

Why is it always the system that gives way? By that point the layout was long fixed, and the AS/RS, conveyors and AGVs were all installed. Changing hardware means a lot of money and a long lead time. Changing the system means a setting, a piece of logic, or one step in a process, for far less time and money.

So when the floor and the system clash, the first question is usually not who is right, but which side is cheaper to change.

When the system gives way, people’s roles shift too. When the work was manual, the material handler and the planner who placed orders were the same person. With the system, the roles split: the planner enters the plan in the system first, and only then can the material handler pick and send out delivery tasks. The work is divided more finely, responsibilities become clearer, and where more people are needed, you add them.

2. Implementation rules are clear on paper; the hard part is the floor

In the previous series I went from kickoff to acceptance, one rule per stop. In the customization post, for example, I wrote: if the standard functions can be configured to do it, it isn’t customization.

What does that look like on the floor? A client asked for a few “special customizations” in the reporting system. When we looked, no development was needed; we just configured the fields and dimensions they wanted. The business didn’t know the system well yet and took existing features for customization.

Everyone understands the rules. Why things still drift on the floor only shows up in specific cases. The two series can be read side by side: one says how a stop should be done, the other says what actually happened there.

Each post tells one story: what the original plan was, where it didn’t fit the floor, how we changed it, what it cost, and, if I did it again, where I would act earlier.

At the end of each post, one sentence says which post in the previous series it maps to, and how. A case study: a rule from that post actually played out on the floor. An addition: it covers something that post didn’t. A deep dive: that post touched on it, and this one digs a layer deeper.

3. Across 12 changes on the floor, three threads keep coming back

I’ve ordered them by project stage, from implementation, go-live preparation and trial run through to after acceptance.

First, what gets handed back to people is usually just the step that needs human judgment. Order release went back to people, returns handling went back to people, and the AGVs still do the moving.

Second, many changes end up back at the few data tables prepared before go-live. Opening stock data, material delivery tables: if one of them is wrong, the floor has to change something.

Third, if how to handle change isn’t written down at kickoff and in the contract, it has to be renegotiated every time. A new leader, a warehouse moved: money and time both have to be worked out from scratch.

The next post starts at the implementation stage: the blueprint is signed, development is under way, and the client gets a new leader.

---

On your projects, when the floor and the system clashed, was there ever a time the floor gave way?