For the vast majority of industries, companies want to deliver what their customers are asking for and at the same time achieve economy of scale at an optimal level of product complexity. Many world-leading, successful companies have decided to solve this dilemma by building strategic product architectures using modularity methods.
Companies that are interested in modularization can easily get stuck on where and how to start. What methods are available to help them achieve a successful module system?
In this blog post, I will walk you through five key success factors to consider when starting a modularization program and I will talk you through one method called Modular Function Deployment (MFD).
What is Modularization?
The key to modularization is the breakdown of the product into modules that are separated by standardized and stable interfaces. Standardizing interfaces by defining the right modules improves flexibility in development and thus shortens development times and lowers development costs. However, to realize these advantages, the modular system must be defined in such a way that both of the following can be achieved: A stable decoupling of modules and a realization of the necessary variety of products over the entire product life cycle.
To achieve this wanted stability and flexibility and reaching that desired modular system there are different methods available to support the work. In this article, five success factors for such a method are identified and presented. In addition to this, a method that incorporates all these success factors is described. If you are new to the modularization topic, you are invited to read an introduction to what modularization is and how modularity can increase your business performance.
How to modularize the product into a successful modular system?
Five Key Success Factors of a Modularization Method
When considering a method to guide and support modularization work the following success factors should be considered:
- Creating a clear understanding of the customer and application needs
- Capturing stakeholder needs, internal and external
- Establishing relationships between functions and connecting functions to stakeholder requirements
- Identifying strategically important interfaces between modules
- Understanding how software and hardware interact to provide solutions
1. Creating a Clear Understanding of the Customer and Application Needs
The process of creating a good modular system that will last is not merely about breaking down the product into modules. Even if that is an important task, the results are not going to be long-lasting or very profitable, nor efficient if it is not built on the customer’s and all other stakeholders’ views and needs. A method used for modularization should have the ability to include and clarify these needs so that they can be effectively considered during the creation and implementation of the modular system.
2. Capturing Stakeholder Needs, Internal and External
The days when each function of an organization worked in a silo, disconnected from others, is history. A solid and sustainable modular system with its modules and interfaces must reach the goals of your business strategy with reducing complexity. For this to happen, it is important that the method that is supporting the creation and management of the modular product architecture can collect, connect, and use input from different functions and stakeholders. Both internal and external. This allows a holistic view in order to establish one modular system, used and communicated by and to all functions of the organization.
3. Establishing Relationships Between Functions and Connecting Functions to Stakeholder Requirements
With a good method for modularization, it should be possible to see how everything is connected and how to act or protect as things change over time. To achieve this connection between the customer needs, stakeholder requirements and the functions of the product, the method must include a way to make this happen. Being able to not only list these items, but also create the relationships. Establishing the relationships will support any analysis of the initial input and any future changes and hence optimize the concepts for interfaces, modules, and module variants to balance the customer needs, technical requirements, and business objectives. Things will change, and when that happens it is important to be able to see the impact of a new decision or the reason for a previously made one.
4. Identifying Strategically Important Interfaces Between Modules
When all the input and collected data from customer, from stakeholder to technical solutions of the product has been established, the method must have enough information and ability to help determine and present a strategic result of what are the important interfaces of the architecture and the modules carrying them.
5. Understanding how Software and Hardware Interacts to Provide Solutions
A modular system is often a system built of everything, from mechanical parts to software. Even if it is not, you will have different types of modules that will be managed differently. It is therefore an essential feature of the method used for creating and maintaining the modular system that it is not explicit or limited to hardware or mechanical solutions, nor limited to only manage software. It doesn’t really matter for the method selection if these different types of modules appear in the same module system or are separated in their respective systems. In order to keep consistency, manage shared relations and shared customer needs, and to avoid spending time solving the same thing in different places, the same method should be able to handle all types of modules.
Methods to Define a Modular System
There are many different methods and approaches that are used for modularization in product development. It is easy to think that an exclusive focus on the internal technical aspects is where to start, because that feels closest to the challenges facing the management of the product architecture. There are too many parts to manage, they are taking too long to develop and that is where all the complexity harbors. Introducing modularity by simply starting to “cut the cake” a bit differently will make all the difference, right? While that is part of the solution it is not the whole truth. With no connection made between corporate strategy and the modular product architecture, the potential of a modular system will only reach so far. This since the understanding and reason for the initial complexity will not be fully revealed. For more information about understanding product complexity watch this webinar "Understanding the Value of Optimal Product Complexity"
To give an example and clarify how to go about defining a module system and aligning its technical aspects with the business strategy and customer needs the following section will walk through the Modular Function Deployment method.
Modular Function Deployment Method
Modular Function Deployment (MFD) is a method which goes from clarifying customer need to create and define modules and module variants, combining the business strategic goals with the technical aspects of the product to get the best possible modular architecture.
Overview of the steps in MFD
The MFD method and the tools included in it is a systematic approach made to be iterative and stepwise and consider and balance all stakeholder voices.
MFD-process with its included tools
Where and How to Start?
It begins with collecting and clarifying customer needs for the targeted segments. The input expressed by customers and stakeholders is ranked to get a view of what is important for each segment. An expression from a customer of what is wanted from the product is something that is often put in terms of “Long operating life” or “high reliability” or similar. This must then be translated into tangible and quantifiable measures to also being able to use this to specify the product and to create and maintain the relationship between different functions of the product and between functions and the stakeholders. The often non-measurable customer needs now have their measurable counterparts created. An example of this would again be the customer value “Long operating time” that would have a relation to the specification of the product by for example “Energy storage capacity”.
Needs as expressed by the customers
The relationship between customer needs, stakeholders and the specification of the product is initiated. What will follow in the work with the MFD method is to facilitate this relationship into the functions and technical solutions of the product, which is still not mentioned. So far there are no actual solutions. What has been stated and collected are measures needed within the modular system. Now the functions and their technical solutions are needed to continue. The measures indicated before this step need to be realized. What solutions are needed to build the product? And where do we realize and manage the different needs? Linking the functions and their technical solutions with the measurable specifications of the product, which in turn is connected to the voice of the customer and the stakeholders gives the first input of where we need variance and development in the product.
The tools used in the steps so far and the steps to come, are all connected to each other and builds on previously stated input, hence creating relationships also between the steps in the process and the functions using the data. This makes sure that what is created in one step of the method is aligned with the needs and strategies that has been defined, and that it is always possible to trace those back in the chain of decisions made so far.
Strategically Correct Modules and Interfaces
The customer needs are now the foundation of the modular system being created, and it is connected to everything within the architecture. This is the fundamental basis of proposing modules with MFD. However, considering the capabilities and the business strategies of the company along with the nature of the product assortment being modularized, there are probably requirements that has not been captured just yet. In addition to the customer needs there are certainly other internal needs and strategies that should affect how modules are defined.
In MFD, the way to acknowledge and include these still missing pieces is the assignment of module drivers. The module drivers are a tool to analyze if there are strategic reasons for surrounding a solution with an interface, i.e. consider it a module. The three main strategic reasons could be: to enable future development, to enable flexible configuration for different customers, or to enable commonality and re-use over time. For each of these three main, high-level reasons there are a number of detailed lower-level reasons to support with capturing internal stakeholder views and create strategically correct modules.
The picture is now starting to form in the sense of what is needed to be able to construct all desired product configurations. Strategically important interfaces and modules has now been identified. The needed variance for each module and the reason for the variance can be traced back to what has been done up until this point. Modules represent the idea, it is the functional building block including the strategy. Each module has one or several realizations called module variants.
Progressing further in the process means the module variants for all modules must be created. Depending on the needs, strategies, and the connection of these to a certain module the module will need a particular number of variants to satisfy that. The step of the MFD-method called “Define variants and configurations” is guiding the work with achieving those wanted module variants to cover the entire range of the product family as well as how they are combined to construct all desired products. The different modules, along with their included functions and technical solutions could now be a result of varying formats depending on the product that has been broken down. Present in the list of modules there could now be hardware modules and software modules, possibly even mixes of the two. Running through a modularization project using MFD does the same job no matter the type of modules involved.
Example of data created when using the MFD method
Achievable and Profitable Module System
Before confirming and releasing the architecture along with the modular objects and the data within, a feasibility check is performed. This is done by:
-
- Checking to determine if the architecture can deliver the range of products to cover the desired market needs
- Assessing the feasibility, development time and technical challenges of the selected concepts
- Determine our confidence in the suppliers inside and outside the company ability to deliver towards cost, quality and lead time.
- Make plans to address the risks through technology development, prototyping, supplier engagements or by making changes to the proposed architecture.
- When the checking of the customer, technical, operational, and financial objectives of the architecture is done, a roadmap is created to guide implementation.
Methods for Modularization – Checking all the Boxes
A method for modularization and modular system development should not only be able to suggest a way to technically divide the product into modules. It should also be able to support:
- Creating a clear understanding of the customer and application needs.
- Capturing stakeholder needs, internal and external.
- Establishing relationships between functions and connecting functions to stakeholder requirements.
- Identifying strategically important interfaces between modules.
- Understanding how software and hardware interact to provide solutions.
The MFD method starts with collecting and making sure the customer needs are understood. The input expressed by the customer is then also translated to be able to specify the product. During the process of understanding and translating customer needs, the relations start to form between functions and stakeholder requirements. By doing so, every decision, technical solution, and eventually module can be traced back to their originating customer needs. Module drivers are introduced to further cement the internal requirements and strategies into the modular design. After that, both internal and external needs have been considered and the picture of which are the strategically important interfaces becomes clear.
The result will be used to create all wanted product configurations by combining modules of varying format: hardware as well as software. Basically, the formats that are needed to be able to satisfy all requirements and create all wanted product configurations, no matter the type of module.
We have now arrived at the point when the product has been divided into modules, in a stable yet flexible modular system, which contains the necessary variety of products over the entire product life cycle. Finally, we have also realized along the way that this was made possible by the fulfillment of the success factors.
If you would like to learn more about the MFD method and how to improve efficiency, agility, and flexibility with modularity, download this guide below:
Want to get in touch?
Please contact me directly if you'd like to discuss the topic covered or have a sounding board in general around Modularity and Strategic Product Architectures.
