There is a particular meeting that happens about two years into a large retail transformation. The new platform is live, or nearly. The original business case is on the screen. And somebody asks, carefully, why the thing that prompted all of this still happens.
The business case is written in the wrong language
Business cases for replatforming are written in platform terms: consolidation, total cost of ownership, deprecation, a single view. The pain that actually motivated the programme is almost never expressed that way. It sounds like:
- "It takes six weeks to change a promotion."
- "Nobody can tell me why that order didn't ship."
- "We have three answers to what margin this line made."
None of those are platform problems. They are ownership, process and definition problems — and a new platform inherits all three, faithfully.
A new system does not decide who owns the answer. It gives the disagreement a new place to happen.
Four questions worth answering before you sign
4
questions to answer before procurement
All four are answerable in weeks, and all four survive whichever decision you make.
3
of them are not about technology
Which is usually the finding, rather than the inconvenience.
- Who decides? For the process that hurts most, name the person who could change it today. If there isn't one, a platform will not create one.
- What is the definition? If three teams calculate margin differently, migration will carry all three definitions across, intact.
- What is the actual cycle time, and where does it go? Measure the six weeks. In our experience the system is rarely the largest block of it.
- What will you switch off? A programme with no decommission list is an integration programme wearing a transformation badge.
The pattern we keep seeing
What the business case promised
- One view of the customer
- Faster change
- Lower cost to run
- Fewer systems
What the team describes two years in
- One view, still carrying three definitions
- Faster deployments, unchanged approval cycle
- A new licence, with the old one still running
- The same systems, plus an integration layer
This is not an argument against replatforming. Ageing systems do genuinely constrain retailers, and there is a point at which the constraint is real and expensive. It is an argument for being honest about which of your problems the platform will actually solve — usually fewer than the case claims, and rarely the ones people complain about most.
A cheaper first move
Before committing: take the single process that generates the most complaints, and instrument it. Not redesign it — measure it. Where does the time go? Who touches it? How many times does it change hands? What proportion of the elapsed time is waiting rather than working?
That exercise takes weeks, not years. In our experience it does one of two things. Either it identifies changes worth making inside the estate you already own, or it produces a far better business case for replacing it — with evidence attached. Both are better outcomes than a case built on an assumption.
If you take one thing from this note
Instrument the painful process before you procure the solution to it. The measurement is cheap, it survives whichever decision you make, and it is the only thing that will tell you whether the platform was ever the problem.
In short
- Business cases are written in platform terms; the real pain is usually ownership and definitions.
- Name the decision-maker for the process that hurts most — before procurement.
- Migration carries your inconsistent definitions across unchanged.
- No decommission list means it is an integration programme, not a transformation.
- Instrument the painful process first. It is cheap and it survives any decision.