A good modular system balances the scope of the system and its lifespan with the effort to create it. In this post, I will suggest a schematic metric that explains the value over time of such a modular system. I will also explain how this schematic metric can support decision-making around configurable product platforms, and I will conclude with an example of a company that learned how to balance, the hard way.
What is a Modular System?
A modular system is a collection of building blocks that can be configured in different ways, adapting for different customer needs. Over time, some modules will be developed to serve new purposes or to improve performance in some aspect. Optimization and cost-cutting can be done within modules without the typical ripple effect throughout the product and, when done well, without reducing the value to customers. Many companies use modularization as a tool to create configurable product platforms, reducing product complexity and making the customer order process more efficient by configuring-to-order rather than engineering-to-order.
When done successfully, the benefits of using such a system are significant. Everyone who does work related to the products will benefit. The most obvious benefits lie within development, where engineers will design and maintain fewer components. We see such benefits throughout the value chain – from sales, through the supply chain and into the after-market. The cost of complexity can be reduced.
Just as there are great examples of modular systems, there are also bad examples, including modular systems that focus on one aspect of efficiency, ignoring the others. For example, standardizing the product platform across brands to decrease supply chain complexity while neglecting the impact on customer value as brands become the same products with different labels. Another example is creating a flexible system to reduce complexity for an existing assortment of products while failing to take customer-driven future developments into account. These approaches can create a product platform that is flexible, but for the wrong things.
This leads to the question: how can you tell a good modular system from a not so good modular system?
The Scope Factor
Many companies have turned to modular design for their product platforms as a solution for coping with ever-increasing complexity in their product offering. While the promise of complexity reduction, consolidated volumes and supply chain efficiency coupled with increased flexibility is very attractive, many companies still face common issues:
- Improvements only span a small portion of the complete portfolio, making it hard to implement broader improvements in complexity and supply chain
- Number of product platforms increases over time
- Subsystems that could be shared across several product platforms are not captured
The fundamental driver behind working with modular products is to enable high flexibility while reducing the needed complexity - Do more with less. This sounds easy in theory; however, it proves to be hard in practice.
A wider scope (i.e. a more flexible modular system) means more customers and more volumes are consolidated in the modular system. However, there's a risk that we go too wide in the same modular system, sacrificing performance or cost with products that have completely different needs.
The Lifespan Factor
Let’s recognize that modular system development comes with a cost. Developing the system is inherently more costly than developing a single product. It takes time to consider all possible products to be included in the system. Spending this time up-front pays off over time by making all the subsequent launches less resource and time consuming.
Once we have developed and implemented the system, maximum leverage is gained by using it as much as possible. You want more volume to carry the development cost, more volume to purchase and more volume to manufacture efficiently. Simply, volume on a platform can be increased in two ways: scope flexibility and change robustness. With the two, you can create many products for a long time.
The Effort Factor
While the above discuss explains the benefits of a modular system, we must also understand the effort needed to create and maintain the modular system. The greater the complexity and effort; the more volume is required for profitability. Many companies use the count of unique components, also known as part numbers, as a measure of complexity of a product platform. To understand the effort to create and maintain a modular system, we use the average part number count over the life of the modular system. With this measure of effort, we can formulate a schematic equation that explains the profitability of the modular system.
Profitability of a Modular System
Profitability is a concept that compares the net outcome of something with the effort of doing it. Given the factors we have already discussed, we can define the profitability of the modular system:
With this simple model in mind, it is easy to understand that you should think twice before making these three decisions:
- Reducing the scope of a product platform development project
- Face-lifting only parts of a product platform, practically splitting it in two platforms of the same volume with an increase in total part number count (i.e. effort)
- Developing a product platform without having a long-term perspective of changing requirements
Reducing the Scope of a Product Platform Development Project
I often hear about projects that are reduced in scope with the purpose of enabling a shorter time-to-market. While time-to-market is a critical factor, I would argue that in many cases the scope reduction is not the best decision. It may be a short-term win, but it is likely a mid-term loss.
In one example, I have seen the increased scope of developing the platform adding approximately three months to the initial six-month project. Each subsequent project based on the platform saved two months. Look at what happens:
Note that the first two projects are assuredly launched later in the wider-scope alternative. By spending the extra three months with front-loading the first project, time and resources were saved on projects 3, 4, and into the future. The longer the platform lifespan – the more time-to-market (TTM) benefit we get!
Since you are aiming at covering a wide scope with one system, you should be very careful about standardizing on the high-performance products. While being a seemingly simple solution to commonality, it will destroy the profit margin for less demanding products. Standardization, in this case, will reduce the scope of the platform, even if you try to sell the standardized product to a wider range of customers.
Face-lifting Only Parts of a Platform
This item is related to the previous one but comes from another angle. Consider a product platform that has been running for some time and that needs an upgrade from Technology A to Technology B. However, you must first create a specification for the whole platform to use Technology B. To cut the time-to-market of this project, you reduce the scope so that you are only upgrading the high runners. What happens? One platform becomes two! You can’t phase out the old platform because it includes products that are crucial to completing your portfolio.
Therefore, you must spend the effort of maintaining and producing two platforms rather than one. Until you replace both these platforms with a complete, new generation platform, you are stuck. If you don’t, you’re caught in a spiral of more and more platforms – and fewer and fewer resources, putting even more focus on reducing the scope of development projects because of resource constraints!
Developing a Product Platform Without a Long-Term Perspective of Changing Requirements
Determining the requirements that exist today is often not that difficult. Look at your existing portfolio, your competitors’ portfolios and ask some key customers, and you are likely 95% there. It is harder to foresee the future, but it is the key to increasing the lifespan of the platform. How can we be prepared for change?
While random changes are problematic, this is often not the case. By understanding the actual needs of your customers, having a solid strategy for the customers you want to win, and having a good technical roadmap, you can foresee or even lead the change – at least many parts of it. The more we can do to isolate change to specific parts of the product, the longer the life of the platform and the more profitable it will be.
A Great Example of a Modular System
One of the best examples of a modular system is the Volkswagen Group cars. There is both incredible flexibility of the system, and there is a clear learning and improvement path over a long period of time. Volkswagen has shown strong commitment and has improved by learning over time, which is now paying off in the third generation of their modular system.
The Volkswagen Group MQB Modular System has a very wide scope
Today, Volkswagen modular systems span the whole range of passenger cars. They are only defined by differences in fundamental structural design principles, including electric (MEB, PPE platforms) and internal combustion (MQB, MLB platforms) drive lines. Innovations save more than $3 billion annually1. In 2020, the MQB platform consolidates more than 80% of Volkswagen Group’s total production volume – almost 11 million cars. This MQB platform was launched in 2012, so it’s already 8 years old! Only time will tell how long it will live. It is exciting to think of the MQB platform and its siblings as something even bigger, where multiple modular systems are made from sub-systems that can be shared across the modular systems. This will be covered in a future blog post.
To achieve this great platform, Volkswagen started working with modular systems in 1993. At this time, the called it platforms. In order to reach scale effects and supply chain efficiencies, Volkswagen standardized the 20 car models they had into 5 common platforms based on car size. The A‑platform, for example, was created for cars of the same size such as Audi A3, Audi TT, Volkswagen Golf, Seat León, and Skoda Octavia.
This A-platform is a clear example of a poor modular system. Why? Because standardization was used to reduce complexity instead of modularization to reach flexibility. Since so much of the actual performance of the cars was tied to the standardized platform, it became much harder for the customer to see and feel the differences between the different models.
Fourth generation Golf, based the common A-platform scope
This meant that many of the brand characteristics were lost. What happens when an Audi customer understands that she can get a very similar car for half the price with the Seat brand? Either she buys the cheaper brand, or – if the premium brand is a purchase driving factor – she visits the competing premium brand instead. Explained with the model for the profitability of a modular system, Volkswagen reduced the scope of the platform but still used the narrower scope to fulfil the needs of a wide-scope market.
This almost 30-year evolution of working with modular systems at Volkswagen is a great example of focus and long-term commitment to this strategy. By continuously improving on the execution, excellence has been reached.
In my next blog I will move beyond the idea of good, balanced module systems into how they can be leveraged across multiple product platforms to generate even greater profitability. I will continue with the same example company who started with independent module systems and transitioned to ones that are broadly shared. You can read it here: A High-Level Modular System with Multiple Shared Subsystems
If you are interested to read more on this topic, I suggest that you check out this blog Accelerate Agility, Flexibility and Efficiency with Modular Design, where we compare traditional product design with modular design. Or download our 5-step guide to create a Modular product Architecture below.
AUTHOR
Tobias Martin
Vice President & Partner
tobias.martin@modularmanagement.com
