The mechanisation was ready — the ERP that had to drive it was not

The market grew and the company grew with it. To handle that growth, the distribution centre had to be expanded from twenty thousand to twenty-five thousand square metres. But the board set one condition: more square metres alone was not enough. The processes to come also had to be more efficient than the processes already there.

That made it a different project from a construction project. The building, the layout, the mechanisation and the systems had to come together in one design — and that design had to be in place before the first pile went into the ground.

There had already been a master plan phase. The internal project team had not arrived at the solutions the company needed, and the external party leading that phase had too little connection with the people in the company who would have to work with it. So there was a plan, but it had no support.

The managing director summed up our assignment in one sentence:

That is exactly the tension in a project of this size. An expansion affects everyone, and everyone has a wish. Hitch them all on and you stop moving; ignore them all and you get a building the organisation does not fit into. The task was to keep moving, while taking along the carriages that really mattered.

This was solved by forming the project team from the company’s own organisation: the warehouse manager, the production manager, the IT manager and the head of maintenance. We reported to the COO, with weekly feedback to the CEO and CFO. Those who would have to run it were at the table when the choices were made — and that is exactly what had been missing in the previous master plan phase.

The new ERP was to be taken into use about eighteen months before completion of the new building. We were not involved in that project. In the end the go-live did not succeed — not delayed, but not successful.

That left us in an unworkable situation. A fully mechanised operation was ready that had to be controlled by a system that did not exist, and the existing ERP system had never been intended for that.

The solution was a low-code middleware layer, linked to the existing ERP system. Not an elegant architecture, but a working one: the entire mechanisation could be controlled and started up on it. The building opened on the agreed date.

We mention this because it shows where the value of project orchestration lies. Not in the plan that is right beforehand — anyone can write that down — but in what happens when an adjacent project collapses and the completion date stands.

At handover, particular attention went to the maintenance department. A mechanised operation is only as reliable as its maintenance, and that maintenance has to be carried by people who work there themselves — not by an external service provider who only comes when something stops.

That is ultimately the sharpest test for programmes like this: not whether the installation works at completion, but whether the organisation keeps it running itself afterwards.