Why Lidl Walked Away From a Seven-Year SAP Project: An ERP Case Study

Real-world case study · ERP & Retail

Most ERP case studies describe a go-live. This one is worth studying because it describes the opposite. A large, well-run retailer with clear reasons to modernise spent seven years on a project and then decided the original goals could not be reached at an acceptable cost.

Nothing here is a criticism of either company. The value is in the pattern, which smaller businesses run into on a smaller scale every time they choose software and then try to bend it around the way they already work.

At a glance

• Company: Lidl (Schwarz Group)
• Industry: Grocery retail
• Country: Germany, with international operations
• Period: 2011 to July 2018
• Technology: SAP for Retail on SAP HANA (project name eLWIS)
• Outcome: Project stopped; Lidl returned to developing its own legacy system

The challenge

Lidl ran its merchandise management on an in-house system known internally as Wawi. According to Computerwoche, the goal of eLWIS was to replace it with an integrated SAP-based system that would connect process chains “from supplier to customer” instead of running isolated functions.

For a large grocery retailer, merchandise management is the core of the business: buying, pricing, stock, replenishment and margin all depend on it.

The situation before

The existing system had been built around Lidl’s own way of working. That is often a strength. A custom system fits the business exactly, but it also becomes harder to extend, integrate and staff over time, which is one common reason companies move to standard ERP platforms.

Public sources do not describe specific failures of the legacy system. They describe a strategic decision to standardise on SAP.

The solution Lidl chose

Lidl selected SAP for Retail running on SAP HANA. The international rollout was announced in spring 2016, championed by Alexander Sonnenmoser, the board member responsible for IT. Consultancy.uk reports that he left the company in May 2017.

Implementation

The project ran from 2011. Reporting on why it stalled centres on one design decision. Consultancy.uk, citing German trade press, reports that Lidl valued its inventory on the basis of purchase prices, while SAP’s retail software is built around retail prices. Rather than change its internal process, Lidl reportedly asked for the software to be customised to keep its existing method, and those changes added complexity, cost and performance problems.

Lidl did not publish its own technical account, so these reasons should be read as reported analysis rather than confirmed findings.

Documented results

In July 2018 Lidl stopped the project. In an internal message reported by Consultancy.uk, CEO Jesper Højer said the strategic goals as originally defined were not possible at an acceptable expense. Computerwoche reports that Lidl described it as “not a decision against SAP, but for our own system” and said it would modernise its existing Wawi system instead.

Lidl did not disclose the cost. The figure of about €500 million comes from the trade paper Lebensmittel Zeitung, citing industry observers, and has been repeated by other outlets. Treat it as a reported estimate, not an official number.

Why this matters

Standard business software carries assumptions about how a business works. When a company’s process differs from those assumptions, it has two choices: change the process or change the software. Both have costs. The Lidl case shows how expensive the second choice can become when it is made on a process at the centre of the business, and how long a project can run before that cost becomes visible.

The same pattern appears in smaller ERP, billing and inventory projects. A business picks a tool, then asks for “just a few changes” until the tool no longer behaves like the product that was evaluated.

What businesses can learn

• Map the core processes first. Write down how pricing, stock valuation and approvals actually work before any demo.
• Find the non-negotiables early. If a process truly sets you apart, test whether the software supports it out of the box during selection, not after.
• Treat customisation as a cost line. Every change must be built, tested and maintained through every future upgrade.
• Set stop points. Agree in advance what evidence would make you pause, change scope or stop, so sunk cost does not make the decision.
• Phase the rollout. Smaller releases surface fit problems in months rather than years.

Raymond Cardoza Enterprises perspective

Before choosing any ERP, billing or inventory platform, a business should map its processes, data and reporting needs, and then mark which of those it is willing to standardise. That fit-gap review is far cheaper than discovering the gap halfway through a rollout. It is the same discipline behind our business solutions work and the approach described in our SME digital transformation case study.

Sources and verification

Every figure in this case study comes from the sources below. Primary sources are listed first.

1. Computerwoche (German): Lidl stoppt millionenschweres SAP-Projekt für Warenwirtschaft
2. Consultancy.uk: Lidl cancels SAP introduction having sunk €500 million into it
3. RetailDetail: Lidl’s failed IT project cost half a billion