Somewhere in almost every growing company, a plan is forming to finally consolidate everything: one ERP, one workspace, one system where the processes and the data will at last live together. The instinct is right about the problem. Knowledge is scattered across twenty tools, nobody can see across them, and every status gets assembled by hand. The plan is still the most expensive recurring mistake in business software. Lidl spent seven years and an estimated €500 million moving onto SAP, then went back to its old system. Birmingham City Council budgeted £20 million for Oracle, is forecast to spend £144 million, and is redoing the implementation from scratch. Neither failure was carelessness. Both organisations lost the same bet: that real work will hold still long enough to be poured into one structure. This post is about why that bet keeps losing, and what studying these failures taught us while we were building Naxis Assistant, our private knowledge engine: the part the urge was right about can be delivered while every tool stays exactly where it is.
Two famous wrecks, one autopsy
Both wrecks are documented in unusual depth: auditor reports, internal memos that reached the press, years of trade coverage. When we were designing Naxis, our team went through that record properly. Anyone building a product that promises a company one place to ask owes these projects the homework, because they were attempts at the same promise, made the expensive way, and they show exactly where it breaks.
In 2011 Lidl set out to replace its home-grown merchandise system with SAP. The project, called eLWIS, ran for seven years and became one of the most studied failures in enterprise software. At the centre of it sat something almost comically small: Lidl values inventory at purchase prices, the software assumed retail prices, and neither side would yield. Bending the system to fit meant custom code on top of custom code, each change making the next one harder, until costs rose faster than progress. In 2018 Lidl wrote the project off and returned to the system it had set out to retire.
Birmingham City Council, the largest local authority in Europe, budgeted £19 million plus £1 million of contingency to move onto Oracle. The system went live in April 2022, more than a year late. Afterwards the council could not reconcile its own bank accounts, could not produce auditable accounts, and paid millions for people to do by hand what the system was bought to do. The chosen fix says everything: not a patch but a full reimplementation, deliberately plain this time. It was due to go live in April 2026. That date slipped too, and as this post is published in July the fix is still not live; the council now says later in 2026. The forecast stands at £144 million, seven times the original budget.
And notice who failed. Lidl is one of the most operationally disciplined retailers in Europe; Birmingham City Council manages a multi-billion pound budget. These were highly organised institutions with mature vendors, and they failed at the same joint: the point where the one-system model met the way the organisation actually works, and the organisation was asked to bend.
Why the bet keeps losing
A consolidation project is a bet with two halves. The first half says the way your company works can be described in one data model. The second half says that description will still be true after the years the migration takes, and forever after. Both halves break on the same fact: real work is fluid. Roles blur, teams cut across tools, every department has one system it cannot give up because half its know-how is encoded in it, and the exceptions are not noise, they are the job. By the time the new system lands, the company it was modelled on no longer exists.
From there the project has two ways to die.
- It bends the system to the company. That is the Lidl spiral: customisation on top of customisation until the standard product is gone and every upgrade becomes a project of its own.
- It bends the company to the system. Then people quietly route around it: the spreadsheet next to the ERP, the group chat next to the ticketing tool, the real numbers in someone's drive. The data ends up scattered again, one heavy system later.
There is also a quieter failure that arrives even with success: the one system becomes tool number twenty-one. Some knowledge moves in, the rest keeps living where it always did, and the company now maintains one more place to search.
This is worth saying directly: none of it is a discipline problem. If your company is well organised, and it probably is, the bet does not get safer, because organisation was never the missing ingredient. Lidl had world-class process and enforced it rigorously. What loses is the premise itself, and a premise cannot be brute-forced: more discipline just means entering more things twice, more accurately, into a structure reality has already left behind.
And the megaproject misses its own target. The reason you wanted consolidation is that knowledge travels through people: leaders answering the same question ten times, five people asked for a status that already exists. That traffic survives the migration, because knowledge keeps being created in the seams between systems. The decision lives in a mail thread, the promise in a call summary, the caveat in a CRM comment at the bottom of a record no dashboard shows. One more system does not close the seams.
What the urge is actually reaching for
Strip the megaproject away and look at what anyone actually wanted from it. Nobody wanted the migration. They wanted one place to ask. The owner wants a status without asking five people. The new hire wants answers without knowing which of the twenty tools holds them, or that a tool exists at all. Department heads want to stop being the routing layer between their team's questions and their team's own files.
That requirement does not need the data to move. It needs the tools you already have to become answerable.
This is where the wrecks stopped being cautionary tales for us and became a design brief. Building Naxis Assistant, we took the failure modes above and built against each one. The one-model bet loses, so Naxis never asks your company to fit a model: it connects to every tool you already use, the standard ones and the custom ones, and reads them as they are. Migrations lose a race against reality, so there is none: each source is re-swept every fifteen minutes, and answers reflect what is currently true. Go-live days lose to habit, so there isn't one of those either: people ask in plain words, in Teams, Slack, WhatsApp, Telegram or the browser, and the answer arrives with the sources attached, or with an honest no when the record does not support one. And because a single system holding everything is where access disasters start, each person is answered only from what they are permitted to see, enforced inside retrieval, on an isolated deployment per company, in the cloud or on your own servers.
The return is measured in time, on both sides of every question. The person asking gets seconds instead of a chase; the person who would have been asked never hears the question at all. Every answer from the record is two people's day left intact. At the leadership level the stakes are larger still: around 40% of leadership capacity goes to gathering and distributing what the company has already established, and that is the share that comes back.
Notice what is absent: no migration, no go-live day, no retraining, no new place anyone has to remember to fill in. The contract stays in the drive, the numbers stay in the database, the promise stays in the mailbox. Naxis does not help you centralize. It makes forced centralizing unnecessary.
Where consolidation is still right
None of this argues against ever unifying a system. Systems of record earn consolidation when the process they record is genuinely uniform: one payroll, one ledger, one CRM for one sales motion. Those are transactions, and transactions thrive on structure.
What keeps failing is consolidating knowledge: the attempt to give everything everyone knows one shape and one home. Knowledge is the exhaust of work. It appears in whatever tool the work happened in, at the speed of the work, and no migration outruns it. So keep the ledger in the ledger and the payroll in the payroll, and let an asking layer make the whole answerable.
So the honest close is the one the wrecks point to. You are, in all likelihood, running an organised company; Lidl and Birmingham were organised too, and it did not save the bet, because the problem sits deeper than discipline and cannot be brute-forced with more of it. Leave the tools alone, put an asking layer over them, and the thing the one system was always meant to deliver arrives anyway: any status, any number, any promise, in seconds, with the sources attached, for exactly the people allowed to see it. Wherever your knowledge lives today is where it gets to stay; Naxis makes all of it answerable in the channels you already use, and the hours that used to go into gathering and relaying come back to the actual work. Nothing to migrate, nothing new to maintain, no rollout. Naxis is not an app you open; it just is.
See every source it connects to
The demo runs on a fictional company whose knowledge lives across the usual tools, the way every real company's does. Ask it for a status nobody prepared, and notice that nothing had to be migrated to make the answer possible.
