Two debts, one warehouse
IT debt is the one everyone names.
Shortcuts in code. Deferred upgrades. Integrations built as quick patches. Middleware held together with tape.
The IT world has been talking about it for years.
Logistical debt is its quieter twin.
Shortcuts in process. An extra control step added one peak season and never removed. A parallel labelling tool. An Excel file that started as a workaround and became load-bearing. A workflow nobody documented because the person who designed it was sitting right there.
This is where shadow IT quietly takes root. Tools the official IT roadmap doesn’t know about. Macros, side databases, parallel apps, homemade dashboards — all built on the fly to keep operations moving. Each one solves a real problem on the day it’s born. Each one becomes harder to challenge with every month that passes.
These aren’t mistakes. They are rational decisions made under operational pressure.
Florian puts it plainly:
“In operations, adaptability is a permanent necessity. The workarounds you see in any warehouse are built with remarkable reactivity by IT and ops teams who do an extraordinary job every day for the business.”
But every workaround is a small loan on the future. Repaid later in complexity, hidden cost, and team fatigue.
The Logistical Debt Loop
Here’s the part the IT-debt conversation usually skips.
In a warehouse, the two debts feed each other.
One does not automatically cause the other. But once the loop is running, it is remarkably hard to break.
We call it the Logistical Debt Loop. It looks like this:
1. Operational pressure creates a quick fix
A side script. A custom dashboard. A workaround built in 30 minutes. The team solves the problem before lunch. Everyone is grateful.
2. The fix works, so it stays
The original constraint fades from memory. The macro becomes part of the daily routine. Nobody challenges it.
This is exactly the moment Florian flags as the most dangerous:
“The original solution stops being challenged. Its origin has dissolved. And in time, the parallel tools start masking the real gaps in the nominal system.”
3. A new requirement arrives
IT has to integrate around the workaround. A specific development is created. Then another. Then a third.
4. Each specific development rigidifies the system
Adaptations that were useful for a season start limiting the next ones.
Adaptations that were useful for a season start limiting the next ones. The cost of every future change goes up. Maintainability erodes and WMS architecture that was meant to absorb future change starts to resist it. Knowledge concentrates in fewer hands.
5. The rigid system creates more operational friction
Which triggers more workarounds. Loop closes.
Where does the loop start? Sometimes on the operational side, when a process shortcut becomes the new normal. Sometimes on the IT side, when a clunky legacy tool pushes operations to invent shortcuts in the first place.
Both directions are real. Both happen.
What matters is recognizing this: addressing only one side rarely stops the loop.
As Florian sees it from years of customer audits:
“All warehouses share a common foundation. But each one adopts a process adapted to its business. It’s the particularities stacked on top that create the real risk: maintenance complexity, and dependency on a handful of key people. The key is to choose what truly has value for your business.”
The reflex that costs you twice
Operations are often running after time. When the friction becomes unbearable, the reflex is always the same.
“Our IT is outdated. We need a new system.”
Sometimes that’s true. There are real signs that a WMS is reaching the end of its useful life, and recognizing them matters.
Often, though, it’s only half of the story.
If you migrate to a new WMS software without first looking at the operational debt underneath, there is a strong chance you will rebuild the same workarounds on top of the new platform. Only this time, with an integration bill attached.
There’s a perception bias worth naming here too.
Teams often over-invest in solving the rare-but-visible edge case and under-invest in the daily friction that actually drives the cost.
Process weight accumulates for marginal recurrence. The system gets blamed for carrying it.
Florian’s read on why this keeps happening:
“Operations are constantly chasing time. That pressure, legitimate as it is, limits the ability to step back and revisit processes in a structured way.”
And the system is never the only lever. Operations design, mechanisation, layout, equipment… all of these can reduce debt without touching a single line of code.
Adopt the standard, or adapt the software to your context?
One question keeps coming back in conversations with the Supply Chain Directors we work with.
It’s the most useful framing for this whole debate.
“Should we adopt the standard, or adapt the software to our context?”
It looks like a software question. It’s really a logistical-debt question.
The instinct on a WMS project is to bend the tool around how things are done today. The foundation is common to all warehouses, but each company adopts a process adapted to its business. Sometimes customising is genuinely necessary.
But after 40+ years as a WMS editor, here’s what we see:
It is common for teams to want to customise their WMS. And sometimes, turning a standard feature into a specific development makes perfect sense but if and only if it becomes a genuine business differentiator. A specificity is not just a technical tweak. It can also mean a business-specific process, a unique solution that no standard product covers. Workarounds nobody has revisited in years, edge cases that no longer reflect the business, “we’ve always done it this way” workflows whose original reason has been forgotten, none of these qualify.
As Florian puts it:
“If I were in your shoes, I’d build that customisation but only if it’s a real business differentiator. Specific developments must deliver measurable value.”
This is why we have built into our own processes what we call a “customisation tribunal”. A structured checkpoint where every specific development request is challenged before it is approved.
Every customisation has a cost beyond the day it is built.
It has to be maintained. Retested at every upgrade. Documented. Carried by a smaller and smaller group of people who still remember why it exists.
The more you stack, the heavier the system gets and the closer you move to the rigidity that triggered the project in the first place.
How far you should go down the customization route is its own conversation but the question above is the one that should come first.
Where to start, without stopping operations
1. Inventory your shadow tools.
Every Excel file. Every parallel app. Every “we always do it this way” workflow. Document them. Then decide which ones should be absorbed into the standard, which should disappear, and which reveal a real gap.
Valorise the work that built them. These tools exist because someone solved a real problem at speed.
2. Differentiate between core functionnality and custom-built add-ons
What belongs in native WMS functionality, and what has been bolted on over the years? This single distinction usually shows where the debt is concentrated and where the risk is highest.
3. Make the debt quantifiable
Operational surcharges. Premium transport. Shadow IT maintenance. Time spent on workarounds. Without numbers, the debt stays invisible and invisible debt never makes it into a business case.
4. Score by criticality
Not everything has to be fixed at once. Prioritise by operational risk and IT fragility, the same way a good specifications process does.
Use the audit as your roadmap
A logistical debt inventory is, in our experience, the most honest requirements document a company can bring into a WMS selection.
A principle Florian comes back to in almost every project:
“Put people at the centre of the requirements. Don’t twist the product to fit workarounds. Create cohesion around the teams who will run the system every day.”
A closing thought
Florian frames it as a question of maturity, not failure:
“Reclaiming control of these issues isn’t an admission of failure. It’s an act of operational and technological maturity.”
Naming logistical debt is the opposite of weakness.
It’s the move that turns a list of frustrations into a structured plan.
The two debts won’t untangle themselves in a single project. But the moment a team starts looking at the process side as seriously as it looks at the system side, the conversation changes.
Decisions get cleaner.
Costings get more reliable.
And the strategic challenges of a WMS project start to feel like one coherent picture instead of five disconnected fights.
The WMS, whichever one you eventually choose, has a much better chance of holding up over the decade that follows.
Florian’s closing line, and the one we’d leave you with:
“IT transformation always starts with a clear, structured vision of operations.”
The real question is no longer “how do we hold this week?”
It’s: what kind of model are we building, one compromise at a time?