Modularisation in Supply Chain

00:04 Introduction
00:20 What part of a business' processes are we talking about making more modular?
04:07 What do you mean by “monolith”?
04:19 Was the idea that we had just one big machine where everything connects to that locally?
06:30 The Internet has been around for quite some time. Why are we still talking about modularisation?
08:47 Any examples of how this dependency on one system has affected a company in the real world?
11:16 What are the benefits of changing from one larger system to many smaller ones?
13:33 Surely this is introducing a reliance on many more companies, instead of relying on one large ERP system which is realistically so large it will not face any issues?
16:49 Do we have an example of a company that tried this and failed?
19:12 Surely there is going to be some crossover between technology? How can things be decoupled?
22:47 What is the moral of today’s story? Do things simply, do it right and build things that work together well?


While the physical infrastructure supporting most supply chains is highly modular, their software infrastructure counterpart, e.g. inventory control or demand forecasting systems, tends to be monolithic and brittle. As a result, large scale ‘software’ supply chain failures are still ongoing.

Modularisation is the process of subdividing a company’s computer processes from one dominant, stand-alone system into a number of separate sub-programs or apps. One could arguably say that in fact supply chains themselves are the most modular entity to exist today.

After 7 years and an expense of over 500 million euros, supermarket giant Lidl have recently announced that they are putting a stop to their ambitious project that aimed to replace their in-house legacy ERP system with SAP. In this episode, we discuss the history of ERP systems and investigate just why Lidl’s project went so horribly wrong.

We try to comprehend why it is so difficult for most companies, especially large multinationals, to upgrade from their existing “monolithic” systems that are often reliant on an outdated set-up. We try and understand how these systems could instead be replaced by a usually more efficient system of separate sub-programs or apps.

We then discuss how companies can avoid a potential overlap between these different apps and what can be done to ensure that your business can make a smooth transition to a more modular approach, without it being an engineering nightmare.

To conclude, our personal reflection on the matter takes its inspiration from Silicon Valley: if you’re going to fail, fail fast. We try to understand why, with regards to ERP systems, this should most definitely apply. We debate both the benefits and drawbacks of a modular approach and learn how the use of these systems can lead to duplicates or even redundant data.