From 2011 to 2018, Lidl worked on replacing its merchandise management system with software built on SAP. In July 2018, the retailer stopped the project, after around €500 million spent according to published estimates. The mechanism the press reported can turn up, on a smaller scale, in an SME’s own project.
Author
Tudor HilcuFounder & CEO, THG Conseil
Published
Reading time
6 min
Topics
Projects, ERP
Contents8
In July 2018, Lidl stopped eLWIS, the project meant to replace its merchandise management system with software built on SAP for Retail. The project had started in 2011. The decision was first announced to staff, then confirmed to the press by both Lidl and SAP. According to estimates published in the German press, around €500 million had been committed; neither Lidl nor SAP confirmed that figure.
Lidl described the programme as the largest transformation project in its history. According to Handelsblatt, more than 1,000 Lidl and SAP employees worked on it, alongside more than a hundred consultants. The new system was already live in three countries: in Austria since May 2015, in Northern Ireland and in the United States.
This is case study no. 01 in the series I publish on LinkedIn; here is the full version, with its sources. It concerns a retail giant, but the mechanism can turn up, at its own scale, in an SME changing its management software, its ERP or its invoicing tool.
The starting gap: a question of method
Lidl and standard SAP for Retail did not value stock in the same way, and Lidl was attached to its method, which sets it apart from many of its competitors. Handelsblatt and heise online describe the same starting point: two ways of counting goods that do not meet.
Two paths were open: change Lidl’s method, or adapt the software. According to the press, Lidl did not want to change its method. An insider quoted by Handelsblatt explains that every process would have had to be reviewed, and that management was not ready for that. So the software was reworked to follow the retailer’s practices, at great expense.
These adaptations took up a great many consultant hours. Handelsblatt points to the general mechanism: modifications that pile up make software more complex, more fragile and more expensive. On who was responsible, the press reported accusations on both sides, with nothing settled.
The halt, and the return to the old system
In their letter to staff, quoted by the press, Lidl’s executives wrote that the original strategic objectives could no longer be reached at a reasonable cost. The cost-benefit analysis argued for developing the old in-house system, known as Wawi. Lidl presented the decision as a choice in favour of its own system, not against SAP: the two companies keep working together in other areas.
What stands out from the case comes down to one question, present from the start: should the method change, or the tool?
The same question, at SME scale
An SME does not spend €500 million on software. Yet it meets the same question as soon as it changes tools: when the standard software does not work the way we do, do we change how we work, or have the software adapted?
There is no answer that holds everywhere. A method that sets you apart with customers can justify an adaptation. A mere habit, much less so. The real risk lies elsewhere: leaving the question unanswered, and accepting adaptations one by one, without anyone looking at the total.
Five decisions to take, before and during the project
List the gaps before you sign. Ask for a demonstration on your own cases: a typical order, a return, an invoice, a month-end close. Note every place where the standard tool does not work the way you do.
For each gap, decide in writing: change the method or adapt the tool. With the name of the person who decides and a deadline. A gap with no decision ends up as an adaptation by default.
Cost each adaptation over its whole life. The development, but also testing, maintenance and the vendor’s updates, which will have to be carried through at every new version. Ask your vendor or integrator for that figure before you agree.
Keep a visible counter. The number of adaptations and their cumulative cost, reviewed at every steering committee. The pile-up shows while it can still be stopped.
Set in advance the points where everything can be stopped. Dates and written criteria: cost, timing, scope. At each of these points, ask the question openly: carry on, scale back or stop. Money already spent is not a reason to carry on.
Fictitious example: the gap register of a wholesale SME changing its management software
Customer discounts worked out by hand. Decision: change the method and use the tool’s discount grid. Who decides: the sales director, by 15 November.
Delivery note with trade-specific wording. Decision: adapt the tool with a new document template. Who decides: the managing director, by 30 November.
Weekly rolling stock count. Decision: to be decided. Who decides: the steering committee, by 6 December.
Three gaps, three names, three dates. The third one is not decided yet, and the register shows it: the decision has a deadline, so it can no longer drag on without everyone seeing.
What I learnt
I have come across this mechanism in my own assignments, on a smaller scale. For The Walt Disney Company, I coordinated 21 teams and 5 partners on an Oracle ERP and Blue Yonder WMS programme, and ran its budget working directly with financial control. That regular link between the programme and finance stops variances being discovered at year end: one more adaptation shows up in the month it is decided.
My companies taught me the other side: what a decision costs when it’s my name at the bottom of the contract. A method decision left waiting costs money too, even when nobody sees it go by.
The limits of this case
The facts come from the German press and the statements by Lidl that it reports. The figure of around €500 million is a published estimate, confirmed by neither Lidl nor SAP. The reasons for choosing to adapt the software are reported by insiders, not by Lidl. No source makes it possible to pin the failure on SAP, on an integrator or on Lidl alone: I stick to the mechanism. The current state of Lidl’s system has not been checked for this article.
Where to start this week
List the adaptations already requested, or planned, on the tool in your current project.
For each one, note who decided it and on what date. The ones with no name and no date are your decisions that are dragging on.
Put the two most expensive on the agenda of the next committee, with a single question: change the method or adapt the tool?
Ten minutes’ work, and you know which decisions are still waiting.
A project most often slips for one simple reason: a method decision that drags on.
The next case in the series, Revlon and SAP, shows the other risk: this time, the switchover happens. To track a project’s schedule, budget, risks and decisions every week, the PMO reporting template is free. If a software project is getting away from you, Project leadership explains how I work, and the rapid assessment takes two minutes, and nothing is sent: you then choose whether to call me or write to me.
