A grocery chain spent about seven years and an estimated €500 million on an ERP programme, then switched it off and went back to the old system. The failure did not start with the technology. It started with a mismatch nobody was willing to name: the business valued stock one way, the software valued it another, and rather than settle that argument, both sides paid consultants to paper over it for years.
Packaging companies make the same mistake at a hundredth of the price, which is precisely why it goes unnoticed. The mismatch is not stock valuation here. It is sheet yield, waste that compounds through production stages, and tooling that has to be amortised over a run length nobody has agreed yet.
Seven Years, and the Applause Came Fifteen Months Before the End
The programme, known internally as eLWIS, had been in planning since 2011. Around 1,000 staff and hundreds of consultants worked on it. In April 2017 SAP gave Lidl a prize for being one of its best customers. By May the head of IT had left, and in July 2018 the programme was cancelled. The €500 million figure is an estimate that neither company has confirmed.
Years from the start of planning in 2011
Lidl's own explanation, given at the end, was that the strategic goals as originally defined were not achievable at an acceptable expense. An insider put it less diplomatically to Handelsblatt: they were practically starting from scratch.
The detail worth keeping is the award. Six years in, from the outside and from the vendor's side, this looked like a reference customer. A programme can pass every visible check and still be structurally dead, because the thing killing it is not visible in a status report.
The Fork Was One Modelling Decision
Lidl valued inventory at purchase price, the price it paid suppliers. Standard SAP for Retail values inventory at retail price, the price the customer pays. That is not a preference. It changes how profitability is reported, how stock is tracked, and how the supply chain is managed.
Faced with that, a business has two options. Change the practice and take the standard model, accepting the disruption and whatever competitive habit goes with it. Or keep the practice and have the software rebuilt to match, accepting the cost of maintaining a version of the product that only you run.
Lidl chose the second and, reportedly, did so because it believed its way of valuing stock was a competitive advantage worth protecting. That is a defensible position. What is not defensible is choosing it without pricing it, because the price is not the customisation. It is every upgrade afterwards.
In Packaging the Mismatch Has a Different Name
A converter evaluating a general-purpose ERP or a horizontal quoting tool is standing at the same fork, holding a list nobody in the demo will call a mismatch:
- Sheet yield, cut factors, and standard parent-sheet catalogs, where the price depends on how the blank nests rather than on a unit cost.
- A loss cascade that walks waste backwards through glueing, diecut, printing and material, instead of a flat percentage.
- Tooling amortised over a quantity that has not been agreed yet, and not charged again on the reorder.
- A dieline that has to be the drawing production actually runs, not an attachment beside the quote.
None of these are exotic. They are the arithmetic of the trade. But a product built to configure options and multiply them by a rate has no model for any of it, so each one arrives as a change request. Individually they look small. Collectively they are the same decision Lidl made, taken four times without anyone noticing a decision was being made. That product category has a name, and it is worth knowing what a CPQ engine assumes about price before one reaches your shortlist. It is also why the packaging ERP question is usually a quoting question wearing a bigger coat.
Customisation Is a Loan Against Your Next Upgrade
The reason a bent product ends badly is not that the code is bad. It is that the change lives beside the product rather than inside it.
Anything inside the product gets tested when the product is tested and upgraded when the product is upgraded. Anything beside it has to be re-checked every time, by someone who remembers why it exists. When that person moves on, the honest cost of an upgrade becomes unknowable, and the rational response is to stop upgrading. That is the moment a system stops improving, and it usually arrives years before anyone admits it.
Lidl's version was hundreds of consultants and a platform that could not scale. A converter's version is quieter: a pricing module nobody dares touch, a vendor who is the only party who understands the surcharge logic, and an estimator who keeps a spreadsheet on the side because the system's number is not trusted.
Three Questions That Surface the Fork in a Demo
Bring a real job rather than a requirements document, and ask:
Price this in front of me. Not a demo dataset. A dieline and a quantity you quoted last week, with the awkward finishing. What the vendor has to explain away is your list of mismatches.
Who changes the pricing logic after go-live, and how? If the answer involves a ticket, a release cycle, or a consultant, then every future difference between your business and the product becomes billable and slow. Pricing logic that your own team edits is not a convenience feature, it is what stops the fork forming.
How many other customers already use the thing I am asking for? If the honest answer is none, you are commissioning bespoke work, which is fine as long as everyone says so and prices the maintenance. If the answer is most of them, you are asking for the product.
What We Do About It, and What We Cannot Promise
We are not neutral. We came out of enterprise ERP, content and CRM implementations before building this, and the pattern above is the one we watched most often.
So the packaging arithmetic is in our product as standard rather than as customisation: sheet catalogs with cut-factor math, flute and GSM cost tables, the loss cascade, dielines, tooling billed once. Pricing logic is configuration your own team edits, not code we own. And where a customer needs something the trade generally needs, it goes into the product for everyone rather than into a private copy, which is how we run implementation rather than a slogan.
What we cannot promise is immunity. The organisational causes around the Lidl failure, no internal ownership, leadership turnover, and training that never caught up with the build, apply to a small vendor exactly as much as to SAP. A project can fail on all three while the software fits perfectly.
What is avoidable is the specific failure: paying to bend a product until it can no longer be upgraded, because nobody was willing to say early that the business and the software did not agree.
The Honest Summary
The question in an evaluation is never whether the software is good. It is whether the defaults already match the trade, and what happens to the parts that do not. Ask that out loud, before the contract, and the worst case is an awkward conversation. Ask it late, and the answer arrives as a system nobody dares upgrade.
Câu Hỏi Thường Gặp
Not on the technology. Lidl valued stock at purchase price and standard SAP for Retail values it at retail price, and rather than change the practice or accept the standard model, Lidl had the software customised to match its legacy logic. Roughly 1,000 staff and hundreds of consultants worked on the programme, which was abandoned in July 2018 after about seven years and an estimated €500 million. The company's own statement was that the strategic goals as originally defined were not achievable at an acceptable expense.
