3 Simple Tips That Could Have Prevented Lidl from Loosing 500 Milion Euro on Custom Software

3 Simple Tips That Could Have Prevented Lidl from Loosing 500 Milion Euro on Custom Software

When German grocery store giant Lidl decided to replace their aging inventory system with a new custom solution, they didn’t expect the project to become an unmitigated disaster. They hired a well respected IT consultancy firm (KPS) to guide them through the transformation, and they chose the software powerhouse SAP for the development work. In theory, they had done everything right, but by July of 2018, the project was dead. The financial cost to Lidl was over 500 million Euros, but the reputational cost for both Lidl and SAP was far higher.

In the back and forth blaming that ensued, Lidl claimed that the consulting firm was not responsive enough and caused too many delays. In response, KPS claimed that Lidl demanded too many changes and that its management refused to adopt standard accounting norms, which caused significant development overruns. SAP, in turn, largely remained quiet on the topic, though some within the project’s development circle cited Lidl’s inflexibility and disorganization, pointing out that many large companies have adopted SAP systems without similar issues.

Is it possible that all of these views are accurate? While this case has been analyzed in countless articles and blogs, the common conclusion is that the Lidl failure resulted from a perfect storm of missteps by Lidl and SAP, but far less is mentioned about the consultancy firm responsible for the process.

It is difficult to believe that KPS conducted a thorough discovery process and failed to factor the accounting issues into their feasibility study—unless they never completed an accurate feasibility study.

The main breaking point between Lidl and the SAP developers focused on the method of recording inventory cost: purchase price instead versus retail price. This one requirement brought the entire project down, despite the best efforts of over 1000 high-caliber developers and consultants. This is a problem that should have been solved before any code was written.

Of course, there were other factors. A crisis is rarely the result of one failure; it is commonly the result of many, but the importance of this failure cannot be overstated. Lidl wanted a feature that could not be delivered within their timeframe or budget. Are they to blame? Or, are the people who told them it could be done to blame?

Sometimes, businesses do need to modernize their processes before hiring a software development company. To be transformative, technology and software must provide ways for core company processes to run efficiently, not to address symptoms of legacy design that are no longer relevant.

Still, we can’t blame Lidl for entering into a project without committing to the changes required to make their vision feasible, if they weren’t made aware of the consequences for not doing so.

This falls on KPS and their communications with SAP. If the ‘purchase price versus sale price’ feature was not checked in advance, and not added to the project’s blueprint, the crisis was inevitable.

So how can businesses protect themselves from such miscalculations? How can you trust your consultants and software houses when a good reputation and a history of success isn’t enough?

This is where we rely on a proven methodology: the Endpoint Modeling system. Here are 3 ways that an EPM approach could have avoided or mitigated the Lidl disaster.

Early Feasibility Study

The purpose of an Endpoint feasibility study is to ensure that every detail of a proposed project can be done within the timeframe and budget allowed. It is the key to our 100% customer satisfaction rating. We don’t rely on our reputation to protect us; we rely on the math. Every feature, every software handshake, and API is checked and rechecked before the build phase begins. We only accept projects we know are feasible from the start, and we encourage the businesses we work with to review our work. If core business processes need to be changed in order for your ideal solution to work, we want you to know that before we go ahead.

 

Complete UI/UX Prototyping

Functionality is not the only element that needs to be checked while creating the blueprint for a new project. The look and feel of an application, an ERP system or a CRM solution also needs approval before moving into the development phase. By offering clickable walk through prototypes, we’re able to make changes without creating a risk to timelines and budgets. Prototypes also foster adoption and create ways for all the stakeholders to add or change important items before they are coded into the new technology solution.

 

Budget and Specification Guarantees

We think it’s important to put our promises into our contracts so that our customers know they will not have to endure a disaster of their own. If we don’t deliver the product you want, at the agreed price, we will assume the loss.

 

What are your thoughts on the Lidl software debacle? Do you think the blame lies with Lidl, KPS or SAP? Or, do you believe that all three are to blame? Let us know in the comments!

Submit a Comment

Your email address will not be published. Required fields are marked *