Approach Pillars & Partners Cases Insights About us Contact NL

Case · Transformation

Mechanising an existing DC that could not stop for a single day

10 → 1

From ten separate sub-processes to one integrated operation on one system.

Sector

Retail, textiles

Scale

Revenue of several hundred million, more than a thousand stores

Our role

Transformation orchestration and programme management

Duration

Design 2021, go-live 2023, handover 2024

Pillar

Mechanisation & implementation

The situation

The client was growing, mainly through expansion in Southern Europe, and had decided to handle that growth from the existing distribution centre. That was not possible without intervention. Replacing the existing mechanisation was an investment of millions without a single cubic metre of extra capacity, and even with a night shift and overtime the DC would eventually no longer be able to cope with the volumes.

At the same time, the board wanted to increase availability in the stores, which required considerably greater accuracy per allocation. More volume, more variation, less space — and an operation made up of separate sub-processes, each with its own system and its own version of the truth about stock, capacity and planning.

The bottleneck

Buying technology was not the problem: several suppliers could deliver what was needed. The problem lay in three constraints that stacked on top of each other and that no supplier could solve.

The mechanisation had to stay within the existing building — the wish of both the owner and the management itself. The building was too low for the chosen technology, so one hall had to be raised considerably: roof off, floor reinforced, installations moved.

The operation had to keep delivering in the meantime — not only during construction, but also during the transition. Two operations in one building, at the same time.

And warehouse management had to be separated from the existing system landscape. The new WMS had to connect to an outdated environment that could not do everything that was needed. That constraint would come back later.

Our approach

Four phases, from the first question to handover

Phase 1

Start from the bottleneck

We started with a small team from the client itself: a DC manager and a supply chain analyst led by the supply chain manager, with weekly reporting to the CFO. First, answer the question of whether it could be done in this building at all, and at what price. Three growth scenarios were calculated to test whether the chosen capacity was robust. The outcome was counter-intuitive: by absorbing part of the growth via a second DC in Southern Europe, the installation could be smaller and therefore cheaper.

Phase 2

Choose the technology that fits

A tender along the usual steps, which arrived at two concepts. A mechanised flow-rack system was the logical choice on paper: high input and output, ideal for cross-dock, and it would replace the outdated sorter at the same time. But it could not increase the number of logistics packaging units — and that was exactly what was needed for higher store availability. The technically strongest solution was not the solution that served the business goal.

Phase 3

Get it working on the floor

Eight project charters, each with its own lead from the client’s organisation. The team grew with the programme: operations manager, supply chain project manager, facilities, inventory management and IT. Weekly steering groups during construction and testing, and tested with representatives of the departments themselves. One solution design that captured the ten processes as one whole and became the guide for construction and testing. A control room as the central orchestration layer, where shift management can adjust on six parameters in real time. And one design decision that made the difference: separating the two go-lives. First the WMS, separately and complete; only then the mechanisation, with a gradual transition from the old to the new process.

Phase 4

On board until it delivers

The go-live was not a software release but a simultaneous transition on six tracks — stock migration, system interfaces, allocation, store schedules, transport integration and work instructions on the floor — worked out to the hour. During the introduction, the operational and IT teams met three times a day at fixed times. Then three months of hypercare, with one point of contact for every issue and an escalation ladder up to the steering group. Handover went to the DC manager, the supply chain director and the supply chain project manager — and it did not happen on our initiative: they indicated themselves that the moment had come.

What happened

The WMS go-live took one weekend and caused no disruption to store deliveries. The mechanisation took more effort, but was running fully at handover in the spring of 2024.

According to the client, the business case has now been achieved. There was a period in between, and it is worth mentioning — because it shows where programmes like this really get stuck.

At handover, part of the volume was still handled manually, for two reasons that both lay outside the technology.

The boxes. Too many sizes the system could not handle well, and boxes that were not sturdy enough to be processed automatically. Every exception is a manual action, and enough exceptions turn an automated flow into a semi-automated one. Both rationalising the sizes and raising the quality are a matter of purchasing policy, not a system setting.

The legacy of the old system landscape. Fill-rate optimisation depends on a distinction the existing system could not yet make properly. Without that distinction there is nothing to optimise, and the required fill rate was not reached.

Both were taken up by the organisation itself, and both were solved by the organisation itself — with the result the business case had predicted all along: fewer people on the floor and a higher fill rate per roll cage.

For us, that is the strongest part of this case. Not that the system started running, but that the company took the last two steps itself.

The figures the decision was based on

Sub-processes

10 separate systems

↓

integrated operation on one WMS

Investment

building on the existing system

↓

~2×

to sustain growth and margin

Cumulative break-even

investment 2021–2023

↓

2025

paid back within four years

Structural annual benefit

operations unchanged

↓

several million

lower staffing and transport costs

Measurement note

The financial figures come from the client’s business case (base case, 2022) and are estimates made beforehand, not realised outcomes. The comparison is always with the variant without mechanisation. The annual benefit stated is the difference in operating costs in the last year of the business case and consists mainly of lower staffing and lower transport costs.

At the formal handover, most of the volume ran through the mechanised system; the rest was still processed by hand. Shuttle utilisation and performance against the plan standard are separate measures with their own outcomes and are not used here.

At the moment of handover, the system was running but the business case had not yet been achieved. Closing that gap was the work of the organisation itself, after our involvement. That the business case has now been achieved is a statement by the client; we did not measure that result ourselves.

Why it kept working

What remained when we left:

A control room with fixed roles and its own steering figures — where shift management adjusts itself rather than noting problems afterwards.

One point of contact for breakdowns and questions — with a fixed route behind it — so that a problem does not sit in five places at once and nowhere really.

A clear boundary — between what the floor solves itself and what goes to programme management.

Four construction and technology partners under one management structure — with one point of contact at the client.

A meeting and reporting rhythm that follows from how the work is done — instead of an operation that bends to the reporting schedule.

None of these five is technology. All five are the reason the technology kept working.

But the real proof is what happened after us. We left with a running system and two tasks that had been named and understood: the boxes, and the legacy of the old system landscape. Not a vague remainder, but two concrete tasks with a known cause and a known effect on the business case. The organisation solved them itself.

That is ultimately the sharpest test of a transformation: not whether the consultant stays long enough, but whether the company finishes the job without them.

Does this sound familiar?

One of these four is enough.

You face a mechanisation decision where the technology is available, but the orchestration is not.

You have several subsystems that have never produced a single version of the truth.

You have to mechanise in a building that has to keep running in the meantime.

You want an investment of this size not just to be rolled out, but to be made to pay in the operation.

Who led the project

Ardy Thoonsen

Jaap Eikelboom

Henkjan van Slooten

architectural design and construction supervision

More about the team All cases

Next step

Curious what this means for your operation?

A one-hour introduction is enough to see whether there is something to gain. No obligation, and afterwards you know where you stand.

Arrange an introduction

We orchestrate your operational transformation. From technology to a working operation — for over 30 years.

Navigation

Approach Pillars & Partners Cases Insights About us Contact

Contact

info@supplytoday.nl +31 71 785 10 37Van Berckelweg 38, Noordwijk, the Netherlandssupplytoday.nl