Abstract

Product developers are faced with the challenge of covering an ever-increasing external variety with as little internal variety as possible. Modular product architectures offer one way of resolving the challenge. They have an impact on all life phases and on economic targets. These effects are represented in the Impact Model of Modular Product Families. A large number of modularization methods can be found in the literature. The modularization methods consist of different activities: decomposition of product, analysis and revision of components, and reintegration to modules. Module drivers play a major role in reintegration, as they determine which components together form a module. It is not yet clear what effects different modularization methods involving different module drivers have on economic targets. For this reason, the module drivers are examined in their role as levers of modularity and integrated into the Impact Model via access points. By documenting the results in a specially developed uniform method step description and the Impact Model, we enable the selection of modularization methods with regard to their economic impact. The introduction is followed by the state of research. In Sec.3, the research problem and the research approach are presented. In Sec.4, the generic method step description is applied to seven modularization methods. Based thereon, the modularization methods are compared with each other with regard to their addressed economic objectives. In an explanatory example, the method selection made possible by this is presented. Finally, the results are discussed and an outlook is given.

1 Introduction

Product development faces the challenge of covering an ever-increasing external variety demanded by the market. This is accompanied by an increase in internal variety and the resulting increase in complexity costs [1]. Modularization is an established strategy to reduce the internal variety while retaining the needed external variety [2].

The impacts of modularization, especially on the economic targets, are multifaceted, but often only implicit known. These are for example impacts on process times, product costs, process costs, product quality, and process flexibility across all life phases of a product family. Their appearance and strength depend on many aspects, e.g., the company boundary conditions such as production type or stockpiling strategy.

The Impact Model of Modular Product Families (Impact Model) represents the implicit knowledge of impacts explicitly and in a systematical way [3]. Differentiation and standardization currently represent the levers for the impact chains contained therein.

Modularization usually involves similar essential steps, based on Pimmler and Eppinger [4]. First, the decomposition of the product into components takes place (A). This is followed by the analysis and revision of the components (B). This step provides the levers of differentiation and standardization. The strength of the levers of differentiation and standardization can come from design adaptations at a component level. These adaptations take place, for example, within a design for a variety of methods [5]. Finally, the reintegration into modules is carried out (C).

Modularization methods integrate modules for a variety of reasons, including what Ericsson and Erixon call module drivers (e.g., Ref. [6]). These can be very diverse, especially in the case of product-strategic modularization, where the module formation is based not only on functional reasons but also on strategic reasons. By taking the strategic reasons into account, it is possible, for example, to address economies of scale that occur in different life phases as a result of modularization. The effects on economic targets, depending on the module drivers, are unclear (question mark in Fig. 1). This complicates the selection of suitable modularization methods, considering the economic objectives of a company. Figure 1 summarizes the situation.

Fig. 1
Desired coupling of the core steps to the economic targets via the lever of modularity
Fig. 1
Desired coupling of the core steps to the economic targets via the lever of modularity
Close modal

The core steps of modularization methods are shown on the left in Fig. 1. Different core steps provide different levers of modularity: The opposing levers of differentiation and standardization are provided by core step B. The effects of these levers are known and are included in the Impact Model, which involves the economic targets (Fig. 1, right). Another lever of modularity emerges from core Step C, the module drivers, i.e., the reasons why components are combined into modules.

The relationship between module drivers and impacts on economic targets has not yet been defined and therefore something we want to explore further and document consistently in this paper.

This leads us to the following research question: How can the selection of modularization methods be supported to specifically address economic objectives? This question will be answered in a three-step approach.

First, common modularization methods are examined with regard to their method steps. In this paper, we are primarily interested in the module-forming steps and their module drivers.

After the module drivers have been identified, the inclusion of the module drivers as levers of modularity for the Impact Model takes place. In a subsequent analysis, possible access points are identified and documented. The aim is to infer the economic targets from the module drivers. Once the access points have been defined, the core steps of existing modularization methods can be compared with each other in terms of their economic impact.

To ensure consistency and for the documentation of the results, a generic method step description of the module-forming steps is developed, which is then applied to the core step C of the modularization methods. The method step description focuses in particular on the representation of the module drivers as levers for modularity. The uniform description of the core steps provides a way to compare modularization methods in terms of their economic impact.

Our contribution is threefold as follows:

  1. First, we show the analysis procedure and comparison results of modularization methods in terms of their module-forming steps.

  2. Second, we provide a unified method step description for the module-forming steps of modularization methods.

  3. Moreover, third, we provide a way to select modularization methods in terms of their impact on economic targets.

When designers, engineers, product planners, and others look for suitable modularization methods, they are overwhelmed by a large amount of differently documented information in the literature. Our contribution will support them in selecting a suitable modularization method without losing sight of the economic objective. For this purpose, a database is established, which forms a bridge between modularization methods, via the levers of modularity, to the economic targets, which are part of the Impact Model.

The introduction is followed in Sec. 2 by the state of research, in which the methodical development of modular product architectures, including modularization methods, the effects of modular product families, and descriptions of methods in general, are discussed. Next, in Sec. 3, the research problem and the research approach are presented, with the individual steps of the approach being explained with the aid of examples on how to proceed. Furthermore, Sec. 3 presents the generic method step description for documenting the module-forming step. In Sec. 4, the template for the method step description presented in Sec. 3 is applied to seven modularization methods and discussed. Furthermore, the levers of modularity contained therein are visualized in the Impact Model. Based on this, the modularization methods are compared with each other with regard to their addressed economic objectives. In an explanatory example, the method selection made possible by this is presented. This is followed by a discussion of the results and an outlook.

2 State of Research

There is a great body of literature providing methods to support the design of modular product families ([4,6] etc.). Different modularization methods were selected from the literature, which are described in Sec. 2.1.1. However, the transfer and application of these modularization methods in industrial practice is challenged because it is difficult to understand the core idea of the methods with regard to the design of modular product families. This problem was recognized by Otto et al. [7], among others, and the systematic requirement flow-down model of architecting steps was created (Sec. 2.1.2) [7]. Furthermore, module drivers are presented in Sec. 2.1.3. In Sec. 2.2, the Impact Model is presented, including the already existing levers of standardization and differentiation, in order to show a basis for the integration of the new lever of modularity module drivers. Last, different models to describe design methods are presented in Sec. 2.3.

2.1 Methodical Development of Modular Product Families

2.1.1 Methods for the Modularization of Product Families.

There is a large number of modularization methods in the literature, which can be used for the development of modular product families. These can be divided into methods in which the module forming takes place rather under technical–functional aspects and those in which product-strategic aspects are addressed in the course of the module-forming steps [8]. Three frequently mentioned methods for modularization are Design Structure Matrices (DSM) [4], Heuristics [9], and the Modular Function Deployment (MFD) [6].

In DSM, couplings between elements of a system are represented. Related to product architectures, it can concern thereby functional couplings between components. Pimmler and Eppinger [4] used this representation method to derive meaningful modules. The derivation of modules is based on the decoupling of components, which are little connected. The derivation of modules can be achieved manually or algorithm based [10].

Stone et al. [9] developed an approach where modularization happens at the functional level. The basis for this is a function structure. To identify the modules, the approach provides three heuristics: dominant flow, branching flow, and conversion flow [9].

Ericsson and Erixon [6] developed the MFD method. Modules are formed under product-strategic aspects, the so-called module drivers. The module drivers are used to identify components that should form a single module or a basis for a module. Technical–functional couplings are not specifically taken into account in this method [8].

Besides these quite basic modularization methods, which have also been studied very often in the literature, there are many more, which are mostly modifications and further developments of these.

For example, there are many methods based on DSM [11]. One example therefore is the approach toward considering technical and economic aspects in product architecture design from Lanner and Malmquist [12]. Furthermore, DSM is used in a wide variety of methods, for example, by Yan et al. [13] to support sustainability-oriented modular product design through kernel-based fuzzy c-means clustering and genetic algorithms. Stone's approach was also further developed. Further guidelines on the modularity of function structures were developed by Zamirowski and Otto [14] for platforms (repeated modules), as well as by Salonen and Otto for reliability [15].

Jiao and Tseng [16] published a method for the development of modular product family architectures for mass customization. This method focuses on the customer and his requirements. Functional, technical, and physical views are combined.

Furthermore, there are methods that address life phase aspects in detail, based on Erixon's idea. In Life Phase Modularization, different aspects of life phases are addressed and a harmonization of these takes place [17,18]. The method combines product strategy views and technical–functional views. Blackenfelt [19] also builds on Erixon's idea and combines it with functional aspects. For this purpose, the information from the Module Indication Matrix according to Ericsson and Erixon [6] is transformed into a DSM format. Furthermore, the groups of the module drivers according to Erixon into Carryover, Commonality, Make or Buy and Life Cycle.

In addition, there are methods that are specialized in certain aspects; e.g., sustainability. Modularization methods have been applied to identify a platform or common modules in product families to increase varieties in terms of economic benefits and sustainability [20,21]. Lifecycle planning methods help to elaborate suitable product architectures based on concepts of modularization [22]. Different lifecycle options require specific modular product architectures. To plan and evaluate lifecycle options, different weighting criteria like physical lifetime, value lifetime, or constituent material can be used [22]. The module definition is based on these criteria. A method to support lifecycle option planning is proposed by Kobayashi [23] and extended by Umeda [24].

2.1.2 General Procedure for Modularization.

There are also already many comparisons in the literature on the topic of modularization methods [7,8,10,2527]. Different aspects are considered in the comparisons. Often, the concepts of modular product architectures, which represent the result of the method executions, are compared. This can take place qualitatively or on the basis of metrics, like the Coupling Index (CI) [28]. Further metrics for the analysis of couplings and modularity are listed in Hölttä-Otto et al. [29]. Especially in modularization methods, where the modules are defined based on product strategy decisions, the resulting concepts are very case specific, because the decisions in the context of the method applications are often made subjectively [10]. Therefore, the comparison only by metrics is not sufficient to compare the methods with each other.

The transfer and application of the methods in industrial practice is challenged by at least the following reason. It is difficult to understand the core idea of the methods with regard to the design of modular product architectures.

Otto et al. [7] investigated different methods in this area and detailed the procedure. They presented the detailed procedure in a systematic requirement flow-down model of architecting steps (Fig. 2, right).

Fig. 2
Generic procedure for modularization (extension of Ref. [7])
Fig. 2
Generic procedure for modularization (extension of Ref. [7])
Close modal

The model consists of a total of 13 steps which are divided into standard steps and steps which can be skipped depending on the use case. Furthermore, alternatives for the individual steps are provided, and method steps and tools of individual methods are assigned to the steps.

Steps 1–4 can be understood as preparatory steps for modularization. In steps 9–13, the post-processing of the modularization takes place.

In steps 5–8, the core steps of modularization can be found (Fig. 2, left). In step 5, customer requirements are translated into functional requirements. This helps designers to understand what a system should do or provide to meet the given customer requirements. Components are defined, partly via functions from the requirements. Thus, in step 5, the decomposition of products takes place. Step 6 involves defining a generic system platform architecture. For this purpose, architectures of the individual product variants are created and merged into a generic architecture. In this step, the variance of components is analyzed so that they can then be combined to form a generic architecture. In step 7, adjustments are made at the component level. An attempt is made to standardize the components as far as possible and necessary. Step 8 is called the critical step by Otto et al. [7]. In this step, the modules are formed, i.e., reintegration into modules takes place (so this step matches core step C). The goal is to minimize the links between the modules as far as possible—in other words, to decouple the modules from one another.

2.1.3 Reasons for the Reintegration to Modules—Module Drivers.

As already written, the “critical step” of modularization is the step in which the modules are formed [7]. In this paper, we refer to this step as the module-forming step (core step C) of modularization. Ericsson and Erixon [6] have coined the term module driver in this context. Module drivers are the reasons for which components are combined into modules. The 12 module drivers according to Ericsson and Erixon [6] are listed in Table 1.

Table 1

Module driver according to Ericsson and Erixon [6]

Life cycle contextModule drivers
Product development and designCarryover
Technology evolution
Planned product changes
VarianceDifferent specification
Styling
ProductionCommon unit
Process and/or organization
QualitySeparate testing
PurchaseSupplier available
After salesService and maintenance
Upgrading
Recycling
Life cycle contextModule drivers
Product development and designCarryover
Technology evolution
Planned product changes
VarianceDifferent specification
Styling
ProductionCommon unit
Process and/or organization
QualitySeparate testing
PurchaseSupplier available
After salesService and maintenance
Upgrading
Recycling

These module drivers according to Ericsson and Erixon [6] are further developed, specified and classified in different ways in the literature. As a result, many of these module drivers can also be found in other modularization methods.

Blees et al. [17], for example have expanded the module drivers to include company-specific module driver characteristics and subdivided these into life phases [18]. Borjesson and Hölttä [30] speak of strategic similarity and independence drivers. This contrast can be found more frequently in the literature: Reasons which lead to the fact that components are summarized to modules and reasons which lead to the fact that components are separated. An example for this are also the Heuristics by Stone et al. [9]: The heuristic dominant flow aims at grouping components, which are flowed through by the main flow, to a module, so that the main flow must be cut as rarely as possible. This heuristic aims more at grouping components together. The heuristic branching flow gives rather an indication, which components should be separated from each other. Another example is provided by module drivers according to Ericsson and Erixon [6]: The module driver carryover states, that components which are to be used in several products should be combined. The module drivers related to recycling tend to indicate which components should be separated from each other for recycling reasons.

2.2 Impact Model of Modular Product Families.

As aforementioned, modularization is a bridge between internal variety and external variety. With the lowest possible internal variety, a large external variety should be covered. On the one hand, this means that customer requirements can be met based on the modularization. On the other hand, the internal effort, for example on the process side, is lower. The modularization of product families nevertheless brings further advantages with it. These have been discussed in many different ways in the literature, with the effects being considered in a very differentiated manner [31,32]. The Impact Model represents a collection of these [3,33]. In ongoing research projects, the Impact Model is continuously validated and adapted to new knowledge [3,34,35].

The specificity of the Impact Model is that attention is paid not only to the impact itself, but also to the cause. The cause modularity is subdivided into different properties and characteristics, oriented originally to Salvador [36] and developed further by Hackl et al. [3] as shown in Fig. 3.

Fig. 3
Properties and characteristics of modularity (further developed based on Ref. [3])
Fig. 3
Properties and characteristics of modularity (further developed based on Ref. [3])
Close modal

The properties and the characteristics describe the modularity from point of view of the variety management in the course of whole product families. By the characteristics, the properties can be achieved [37]. The characteristics can be affected directly by the developer. The characteristics are oversizing, interface standardization, decoupling and function binding. The properties of modularity are commonal use and combinability. Oversizing describes the fact that modules are exceeded in size or in their interfaces, for example, so that they can subsequently be used across the product family as standardized—i.e., commonally. The commonal use of modules is also made easier by interface standardization. In addition to the commonal use, interface standardization also enables the combinability, which is also made possible by function binding and decoupling. The function binding means here that a one-to-one assignment of functions to modules takes place. Decoupling states that the connections, such as flows, should be stronger within a module than between modules.

Through the levers of standardization and differentiation, the characteristics and the properties can be addressed. The properties are then followed by the impact chains. An excerpt of the current status of the Impact Model can be seen in Fig. 4.

Fig. 4
Excerpt of the Impact Model of Modular Product Families (adapted based on Ref. [3])
Fig. 4
Excerpt of the Impact Model of Modular Product Families (adapted based on Ref. [3])
Close modal

Figure 4 shows an example of an impact chain. The commonal use, which is made possible by interface standardization and oversizing, leads in the procurement life phase to the fact, that there are also fewer different part numbers due to the decreasing variance. As a result, not as many orders need to be generated and the orders that are generated include larger quantities. The costs per unit can be lowered by larger numbers of items due to quantity discounts. The effects that result directly from the properties are the so-called primary effects. The subsequent effects explain the causal relationships in further detail. The impact chain ends in an economic impact. The economic effects are time, costs, quality and flexibility, whereby—if possible—a distinction is also made between product-related economic effects and process-related economic effects.

In current research, it has been found that not only the levers of standardization and differentiation allow access to the Impact Model. In addition, especially the characteristics are not only influenced by modularization per se, but also already to a large extent in the variety-oriented product design. When components are standardized, this standardization continues in modules. Another idea is, that a further lever can be the module drivers in the core steps of modularization methods [38,39]. For example, there are methods in which the method user is encouraged to combine take-over parts into a module. So, if this module driver carryover is applied, it has the consequence that the commonal use of this module is made possible.

2.3 Definitions and Descriptions of Design Methods.

In spite a diffuse understanding of the term method [40], positive effects of method applications to reduce development time and increase quality of results are reported in literature [41]. A common way to define the term method is to border it from methodology, process and tool [42,43].

2.3.1 Design Method Descriptions.

Ways to provide knowledge about methods differ widely with regard to the structuring of information, the detailing of activities and required information as well as boundary conditions to apply the methods. A detailed overview of different method properties or attributes used is given by Ponn [44]. To address the basic understanding of methods as procedures of activities leading to a certain goal or result [45], in most method descriptions a process-oriented presentation is used. The process-oriented presentation goes back to the Structured Analysis and Design Technique (SADT) [46]. The Process-Oriented Method Model (POMM), for example, builds on it (Fig. 5).

Fig. 5
Process-oriented Method Model (POMM) [47]
Fig. 5
Process-oriented Method Model (POMM) [47]
Close modal

The POMM proposed by Birkhofer et al. [47], comprises the attributes process, defining in- and outputs, the sequence of tasks as well as general conditions, user aspects and working aids (tools) to use the method. The assess parts are intended to support both the selection of the method and additional information to ease application.

Other approaches research access to method knowledge using digital tools, see for example Albers et al. [48]. The user interface of Innofox is shown in Fig. 6.

Fig. 6
InnoFox user interface (according to [48])
Fig. 6
InnoFox user interface (according to [48])
Close modal

Here, the methods are described by brief descriptions with regard to the attributes short description, input and output, respective work steps, required tools and resources, advantages and disadvantages, area of applications, as well as suitable sources and application examples. In order to support a situation and need specific method selection, filter options are provided based on aspects such as objective, number of employees required or type of infrastructure required. However, these cover a wide range of methods and thus include only a small number of modularization methods.

2.3.2 Description of Individual Method Steps.

Processes and methods can be structured at different levels to identify recurring sequences. The POMM, see Fig. 5, for example, includes a hierarchical structuring of a method into method steps, whereby the method steps according to VDI2221 [49] can also be referred to as activities. The required depth of description is use case specific.

One example for the description of single method steps in detail instead of describing whole methods is the Method Process Visualization (MPV) according to Beckmann et al. [50] (Fig. 7).

Fig. 7
Method and Process Visualization (MPV) [50]
Fig. 7
Method and Process Visualization (MPV) [50]
Close modal

Beckmann et al. [50] addressed the question of how it can be possible to transfer methods into practice. In order to make this possible, the authors do not consider whole methods per se, but go to the step level. The cut is made by looking at which competencies are needed in which sections of the methods, and what the practice needs in order to carry out parts of the methods. Another example is provided by Hanna et al. [51]. They link process models with product models to make development more consistent. Even for this, whole methods have to be subdivided, because different parts of a product model are needed in different steps of the method [51].

The description attributes in the step level are similar: Individual method steps provide an output that can be an input for a next method step. The subdivision of methods into method steps offers many potentials. For example, the modularization methods considered in this paper are very extensive design methods, which consist of many individual steps. By dividing them into steps, these methods can be adapted step by step (see [7]).

3 Research Problem and Research Approach

There are various modularization methods in the literature which are described in different ways. In the modularization methods, there is the core step C in each case, in which the module forming takes place.

The reasons for this vary from modularization method to modularization method. Due to the very different descriptions of core step C in different methods, the module drivers are difficult to grasp at a glance. Without a consistent description of the module-forming steps, it is not possible to easily and quickly access knowledge about the module drivers per modularization method. In order to support the selection of modularization methods and to make the addressing of economic targets visible, we proceed as follows.

We examine a selection of existing modularization methods with regard to their method steps. In doing so, we identify the core steps A to C in the methods including their module drivers (Sec. 3.1). After the module drivers have been identified, they are categorized by comparing them with the elements of the Impact Model. This defines the access points of the module drivers as levers for modularity on the Impact Model (Sec. 3.2).

The module-forming steps of the different methods are then described with an adapted method step description, in which the focus lies on the module drivers as the access points (Sec. 3.3). The method step description itself is developed in a workshop with method researchers and builds on the findings from the state of research. In the method step description, the bridge described in the introduction (Fig. 1), which represents the superordinate relationship between the modularization methods and the economic targets, is documented (Fig. 8). Furthermore, the access points are marked in the Impact Model.

Fig. 8
Description of the module-forming step (core step C) to illustrate the relationship between modularization methods and their economic impact
Fig. 8
Description of the module-forming step (core step C) to illustrate the relationship between modularization methods and their economic impact
Close modal

Based on the method step descriptions and the Impact Model, method steps of different modularization methods can now be compared with each other. In addition, the method description of the module-forming steps facilitates the method selection.

3.1 Analysis of Existing Modularization Methods and Their Module-Forming Steps.

In this paper, the selected modularization methods have already been described in the state of research. These are the method Life Phase Modularization according to Blees [17] (M1), Modular Function Deployment according to Ericsson and Erixon [6] (M2), the method for developing modular mechatronic products by Blackenfelt [19] (M3), the Integration Analysis of Product Decomposition method by Pimmler and Eppinger [4] (M4), the lifecycle planning method based on lifetime heterogeneity [23,24] (M5), the method for identifying product portfolio architecture modularity using function and variety heuristics according to Zamirowski and Otto [14] (M6), and the product family architecture development method for mass customization by Jiao and Tseng [16] (M7).

These are, on the one hand, the basic methods of modularization and, on the other hand, methods which build on them and combine, among other things, product-strategic variance aspects with technical–functional aspects.

First, the module-forming step is to be found. The steps of the modularization methods are thus analyzed and assigned to the parts of Fig. 2, left: preparatory steps for modularization, core steps of the modularization and post-processing of the modularization. The consideration of the product architecture levels is particularly helpful in the identification of the core steps of the modularization. After the core steps of the modularization have been identified, the focus is on core step C and it is researched which module drivers lead to the modules being formed here. This analysis procedure serves the first part of the contribution of this paper.

In the following, the procedure is explained on the basis of Life Phase Modularization (M1). The method is described in Ref. [17], among others. It is based on a design for variety method [5]. With the help of the description of the process of modularization methods in Ref. [7] (Fig. 2), it turns out that core step A: decomposition of product, and core step B, analysis and revision of components are part of this upstream method. The product-strategic modularization is described in detail in Ref. [17]. This is the core step C: Reintegration to Modules. A set of module drivers, which are based on those of Ericsson and Erixon [6], is set up and then used to create network diagrams. In this method, the modules drivers are thus easy to identify. An example of such a module driver, which is also already used by Ericsson and Erixon, is separate testing. This is a module driver which is used in the network diagram “production.” In the network diagrams, the components of a product family are assigned to the module drivers and then combined into modules, whereby components are assigned to modules under life phase-specific aspects. The different module structures of the individual life phases are then collected in a tool called Module Process Chart in order to harmonize the different views.

3.2 From Module Drivers to Economic Impact.

After the module drivers from the different modularization methods have been identified and clustered, the economic effects they bring with them are now to be analyzed. This also serves the first part of the contribution mentioned in the introduction. For this, the idea is taken up that the module drivers represent another lever of modularity for the Impact Model, in addition to standardization and differentiation [38,39]. We utilize the knowledge in the Impact Model. The module drivers are compared with the elements of the Impact Model to identify the access points of these levers.

This can involve different levels of detail. Some module drivers represent a direct lever and can be causally addressed straight to individual effects (and the resulting consequential effects). The previously mentioned module driver separate testing (module driver in methods M1-3) is an example of this (Fig. 9).

Fig. 9
Representation of the access point of the module driver separate testing as lever of modularity
Fig. 9
Representation of the access point of the module driver separate testing as lever of modularity
Close modal

The Fig. 9 shows an example of the superordinate link between module drivers and economic targets. If components are assembled in the module-forming step of a modularization method, which is to be tested together in certain production processes; for example, then parallel testing is made possible by the separation. The parallel testing is an effect in the Impact Model and represents in this case the access point for the lever. This effect is followed by the effects of reducing the time for failure detection and lowering the manufacturing costs per unit. Nevertheless, it should be noted that additional costs due to possibly necessary test facilities could reduce this effect somewhat. All in all, the parallel testing results in positive effects on process time, process costs, and process flexibility [38,39].

An example of a reason for module reintegration, which as a lever enables access to a whole area of the Impact Model, is the module driver carryover (module driver in methods M1-3, M6). If components are to be merged that are carryover parts, this addresses directly the commonal use. Thus, all primary effects of the life phase product development can be achieved, which result from the property commonal use in the Impact Model.

If modularization methods mainly address technical–functional aspects during module reintegration, it is more difficult to access the effects of the Impact Model. Nevertheless, technical functional module formations pull also product-strategic effects, above all in the product development. If for example components are summarized, which fulfill together a function (module driver in method M1, M3-4), then the commonal use is increased, if this function is to be contained in different products. In addition, individual effects in the life phase product development are affected, as for example ease of mapping organization to the task. This primary effect has a positive influence on every economic target via follow-up effects.

3.3 Generic Method Step Description for Documenting the Module-Forming Steps.

As shown in the state of research, there are already many different method descriptions. Thus, no description needs to be developed from scratch, but existing descriptions can be used and further developed. The goal we pursue with the description is the representation of core step C of modularization methods with focusing on the module drivers as levers for modularity to achieve economic targets.

Against the background of this goal, existing generic method (step) descriptions were examined. The focus was thereby on the individual attributes, which the descriptions bring along. The goal is to describe method steps and not whole methods. Nevertheless, also whole method descriptions were considered since the attributes applied here can be referred also to as method step level. Furthermore, different descriptions were examined on the one hand regarding their similarities and on the other hand regarding their differences in a creative workshop with method researchers.

The research results, analysis results, and workshop results led to the following generic method step description for the module-forming steps of modularization methods (Fig. 10), which belongs to the second part of the contribution mentioned in the introduction.

Fig. 10
Generic method step description of module-forming steps
Fig. 10
Generic method step description of module-forming steps
Close modal

The module-forming step (2) is part of an entire modularization method (1) and therefore has an input from previous steps and an output for further steps (4). In addition, the externally required input and the results of the step implementation are listed. The step itself is described in great detail with the following attributes: short description (3), aim of the method step, required methodical knowledge, working aids, sup-activities, steps, related methods (steps from other modularization methods), and most important in our case and on top of that core step C specific: The module drivers which are considered as levers of modularity and are the access point for the Impact Model (5).

4 Comparison and Selection of Modularization Methods Using the Description of Core Steps

This section is divided into three subsections. First, the results of the identification of the levers of modularity of the modularization methods in the Impact Model are presented and analyzed (contribution part 1). This is followed by a description of the module-forming steps of the modularization methods (contribution part 2). Differences between the modularization methods with regard to their addressing of economic objectives are highlighted (contribution parts 1 and 2). Finally, an example is given to show how this knowledge can be used to support the selection of methods with regard to economic objectives (contribution part 3).

4.1 Identification and Representation of the Levers of Modularity in the Impact Model.

The seven modularization methods listed in Sec. 3.1 were now examined in detail as described. The module-forming steps, core step C, were identified. In these steps, the reasons that lead to which modules emerge were now examined in more detail and categorized according to the life phases from which they originate. As previously described, these module drivers are the newly introduced levers of modularity. Depending on which module drivers are prioritized in module formation, different economic effects can be achieved. Section 3.3 describes the procedure used to identify access points in the Impact Model. Figures 11 and 12 show the Impact Model with all identified access points of the module drivers of the selected 7 methods.

Fig. 11
Impact Model of Modular Product Families with the access points of modularization methods (Part 1, continued in Fig. 12).
Fig. 11
Impact Model of Modular Product Families with the access points of modularization methods (Part 1, continued in Fig. 12).
Close modal
Fig. 12
Impact Model of Modular Product Families with the access points of modularization methods (Part 2)
Fig. 12
Impact Model of Modular Product Families with the access points of modularization methods (Part 2)
Close modal

The access points are marked by rectangles. The M and the first number stand for the respective method from which the access to the Impact Model takes place (see legend). Since the methods usually have several module drivers that can be linked to the Impact Model as a lever of modularity, the access points are also abbreviated by numbers in the description.

Three different types of access points can be distinguished. The first type represents access to an entire life phase. An example of this was given in Sec. 3.2. These access points are rectangles placed in the upper right corner of the life phases. There is another distinction here. If the rectangle has an bold light border, the access point refers to all effects of the life phase that result from the property combinability. If the border is bold dark, it refers to all effects that result from the property commonal use. With a thin border, all effects of the respective life phase are addressed. The second type is the access point, which contains an * and is also placed at the top right of the life phases. These access points indicate that an entire life phase is addressed, but that some effects occur particularly strongly. The access points are also listed with * at the impact chains. The last type is the access point for individual impact chains. This marking is also made as a rectangle directly behind the respective impact chains.

If the Impact Model is examined, it can be seen that the impact chains act as access points for the levers of modularity with varying frequency. Some impact chains are addressed by many methods (4000 and 4010). Others are only sporadically marked by access points (5040). Also, some impact chains are not addressed at all, as for example the impact chain 4070.

4.2 Description of the Module-Forming Steps of Selected Methods.

Once the methods have been studied and the access points of the lever of modularity are identified within the Impact Model, the results of the analysis can also be documented in the generic method step description of module-forming steps.

These will then be used to quickly review the module-forming steps of the modularization methods in combination with the use of the Impact Model.

The detailed descriptions of the seven methods can be found in the  Appendix. Table 2 summarizes the main description attributes. The markings via the numbers 1–5 can be found in Fig. 10.

Table 2

Summary of the applied descriptions with the main attributes

Method 1Core step C 2Short description of step 3Input and Output 4Module driver and access points 5
M1 (Blees et al., 2010)3. Create strategic modularizations for all relevant product life phasesIn network plans, module drivers are assigned to components via module driver characteristics. They are then grouped into modules according to their assignmentsInternal input: Product representation (Module interface graph (MIG))
External input: Requirements of different life phases
Output: Strategic modularizations in Network Diagrams
Product Development: Technical–functional module driver (M1A1), temporal variety (–), carryover parts (M1A2*)
Procurement: modular sourcing (M1A3)
Production: process (M1A4), organization (M1A5*), separate testing (M1A6)
Sales and Management: variant product properties (M1A7), adaption/extension (M1A8)
Service: service/maintenance (M1A9), product recycling (M1A10), material recycling (M1A10), thermal recycling (M1A10), and disposal (M1A10)
M2 (Ericsson and Erixon, 1999)3. Generation of concepts for modularization by clustering the MIMThe technical solutions are clustered in suitable modules based on their evaluation regarding the module drivers, this clustering is carried out in the Module Identification Matrix (MIM)Internal Input: Prepared Module Identification Matrix (MIM)
External input: Expert knowledge about the company and its products
Output: Modularization concept in MIM
Product Development: Carryover (M2A1*), separate testability (M2A2), technology push (–), planned design change (–), styling (–)
Procurement: Strategic supplier available (M2A3)
Production: Technical specification (M2A4), common unit (M2A5), process (M2A6), organization (M2A7*), separate testability (M2A8)
Sales and Marketing: Upgrading (M2A9)
Service: Service/maintenance (M2A10), recycling (M2A11)
M3 (Blackenfelt, 2000)3. Create modularizations considering strategic and functional aspectsPotential modules are identified based on two DSMs: one is a “conventional” DSM, the other one is a transformed MIM and thus represents strategic aspects. For the modularization itself basically existing algorithms are used (with adjustments)Internal Input: Strategic and functional DSM
External Input: Relations of (partial) solutions with each other and condensed module drivers
Output: Potential modules considering strategic and functional aspects in DSMs
Product Development: Carryover (carryover (M3A1*), technology push (–), planned product change (–)), function aspects (M3A2), life cycle (separate testing (M3A6), …), commonality (styling (–), …)
Procurement: Make or buy (supplier available (M3A3), …)
Production: Make or buy (process/organization (M3A4*), …), commonality (common unit (M3A5), technical specification (M3A6), …), life cycle (separate testing (M3A7), …)
Sales & Marketing: Life cycle (upgrading (M3A8), …)
Service: Life cycle ( service/maintenance (M3A11), recycling (M3A9), …)
M4 (Pimmler and Eppinger, 1994)3. Cluster the Elements into ChunksThe interactions between the decomposed elements and their degree of interaction are shown in a matrix, which is then clustered along the diagonal to represent possible modulesInternal input: Interaction between Elements
External input: Requirements of different life phases
Output: Clustered Interaction Matrix
Product Development: Functional aspects (M4A1)
M5 (Kobayashi, 2001; Umeda et al., 2007)3. Create strategic modularizations for all relevant product life phasesThis method supports identification of eco-efficient lifecycle options such as maintenance, reuse, upgrade or extension of use for products and components based on the analysis of value and physical lifetimeInternal Input: Product Concept
External Input: Customer requirements
Output: Lifecycle options and Modules in LCOP-Chart
Product Development: Reuse (M5A1)
Sales and Marketing: Upgrading (M5A3)
Service: Maintenance (M5A2)
M6 (Zamirowski and Otto, 1999)3–4. Clustering functions according to heuristicsThe family function structure was expanded to cover all product variant functions. The functional heuristics are used to identify alternative clusters. The variety of functions across the family guideInternal input: Family Function Structure
External input: Marketing & Variety Requirements
Output: Functional modules and Partitioned Function Structure
Product Development: Technical–functional module driver (M6A1), temporal variety (–), carryover parts (M6A2*)
Sales and Marketing: Variant product properties (M6A4), adaption/extension (M6A5)
M7 (Jiao and Tseng, 1999)2–3. Technical modeling of Product family architecture (PFA) -> Physical modeling of PFAThe product family is derived from a mapping of Functional Requirements and the decomposition of the product familyInternal input: Representation of the functional view of a product family
External input: Knowledge about production system
Output: Product family architecture and variant trees
Production: Manufacturability (M7A1), Costs (M7A2), Volume (M7A3), Schedule (M7A4)
Sales and Marketing: Mass customization (M7A5)
Method 1Core step C 2Short description of step 3Input and Output 4Module driver and access points 5
M1 (Blees et al., 2010)3. Create strategic modularizations for all relevant product life phasesIn network plans, module drivers are assigned to components via module driver characteristics. They are then grouped into modules according to their assignmentsInternal input: Product representation (Module interface graph (MIG))
External input: Requirements of different life phases
Output: Strategic modularizations in Network Diagrams
Product Development: Technical–functional module driver (M1A1), temporal variety (–), carryover parts (M1A2*)
Procurement: modular sourcing (M1A3)
Production: process (M1A4), organization (M1A5*), separate testing (M1A6)
Sales and Management: variant product properties (M1A7), adaption/extension (M1A8)
Service: service/maintenance (M1A9), product recycling (M1A10), material recycling (M1A10), thermal recycling (M1A10), and disposal (M1A10)
M2 (Ericsson and Erixon, 1999)3. Generation of concepts for modularization by clustering the MIMThe technical solutions are clustered in suitable modules based on their evaluation regarding the module drivers, this clustering is carried out in the Module Identification Matrix (MIM)Internal Input: Prepared Module Identification Matrix (MIM)
External input: Expert knowledge about the company and its products
Output: Modularization concept in MIM
Product Development: Carryover (M2A1*), separate testability (M2A2), technology push (–), planned design change (–), styling (–)
Procurement: Strategic supplier available (M2A3)
Production: Technical specification (M2A4), common unit (M2A5), process (M2A6), organization (M2A7*), separate testability (M2A8)
Sales and Marketing: Upgrading (M2A9)
Service: Service/maintenance (M2A10), recycling (M2A11)
M3 (Blackenfelt, 2000)3. Create modularizations considering strategic and functional aspectsPotential modules are identified based on two DSMs: one is a “conventional” DSM, the other one is a transformed MIM and thus represents strategic aspects. For the modularization itself basically existing algorithms are used (with adjustments)Internal Input: Strategic and functional DSM
External Input: Relations of (partial) solutions with each other and condensed module drivers
Output: Potential modules considering strategic and functional aspects in DSMs
Product Development: Carryover (carryover (M3A1*), technology push (–), planned product change (–)), function aspects (M3A2), life cycle (separate testing (M3A6), …), commonality (styling (–), …)
Procurement: Make or buy (supplier available (M3A3), …)
Production: Make or buy (process/organization (M3A4*), …), commonality (common unit (M3A5), technical specification (M3A6), …), life cycle (separate testing (M3A7), …)
Sales & Marketing: Life cycle (upgrading (M3A8), …)
Service: Life cycle ( service/maintenance (M3A11), recycling (M3A9), …)
M4 (Pimmler and Eppinger, 1994)3. Cluster the Elements into ChunksThe interactions between the decomposed elements and their degree of interaction are shown in a matrix, which is then clustered along the diagonal to represent possible modulesInternal input: Interaction between Elements
External input: Requirements of different life phases
Output: Clustered Interaction Matrix
Product Development: Functional aspects (M4A1)
M5 (Kobayashi, 2001; Umeda et al., 2007)3. Create strategic modularizations for all relevant product life phasesThis method supports identification of eco-efficient lifecycle options such as maintenance, reuse, upgrade or extension of use for products and components based on the analysis of value and physical lifetimeInternal Input: Product Concept
External Input: Customer requirements
Output: Lifecycle options and Modules in LCOP-Chart
Product Development: Reuse (M5A1)
Sales and Marketing: Upgrading (M5A3)
Service: Maintenance (M5A2)
M6 (Zamirowski and Otto, 1999)3–4. Clustering functions according to heuristicsThe family function structure was expanded to cover all product variant functions. The functional heuristics are used to identify alternative clusters. The variety of functions across the family guideInternal input: Family Function Structure
External input: Marketing & Variety Requirements
Output: Functional modules and Partitioned Function Structure
Product Development: Technical–functional module driver (M6A1), temporal variety (–), carryover parts (M6A2*)
Sales and Marketing: Variant product properties (M6A4), adaption/extension (M6A5)
M7 (Jiao and Tseng, 1999)2–3. Technical modeling of Product family architecture (PFA) -> Physical modeling of PFAThe product family is derived from a mapping of Functional Requirements and the decomposition of the product familyInternal input: Representation of the functional view of a product family
External input: Knowledge about production system
Output: Product family architecture and variant trees
Production: Manufacturability (M7A1), Costs (M7A2), Volume (M7A3), Schedule (M7A4)
Sales and Marketing: Mass customization (M7A5)

The main description attributes in the context of this paper are the name of the module-forming steps, the short description of the step, input (method internal, i.e., from the previous method step, and method external) and output and the identified lever of modularity, the module drivers with the access points, which are also marked in the Impact Model (Figs. 11 and 12). If the module drivers of the modularization methods do not represent levers of modularity that can be addressed to elements of the Impact Model, then no access point is listed. Furthermore, there are the collective effects, which are marked in green in the Impact Model. Thus, for example, all impact chains that belong to the product development life phase or are generally process impact chains have an effect on subsequent life phases.

Using the information on the module drivers and their access points contained in the method step descriptions and the Impact Model, the modularization methods can now be compared with each other in terms of the different economic effects that can be achieved with the lever of modularity.

When examining the modularization methods and the module drivers as levers of modularity, some differences between the methods became apparent.

The categorization of the module drivers already revealed some differences.

Methods M1, M2, and M3 contain module drivers from all life phases, which are listed in the Impact Model. The Life Phase Modularization according to Blees et al. [17] already assigns the module drivers to the life phases, while the Modular Function Deployment according to Ericsson and Erixon [6] assigns the module drivers to other categories, which means that this had to be adapted. The result was that the same module driver in two different methods represents different levers in the Impact Model. The module driver separate testing addressed in the Life Phase Modularization is clearly assigned to testing in production. In Modular Function Deployment, prototype testing is also addressed by this module driver in the product development phase. Blackenfelt [19] grouped the module drivers. These groups contain contradictory or opposing module drivers, which are then coordinated within the group. By categorizing the module drivers into life phases, these groups are split up again.

Method 4 is structured differently; it is a method with technical functional aspects, which mainly occur as module drivers of the product development life phase. The aforementioned collective effects play a major role in identifying the economic objectives that can be achieved by this method.

Method M5, M6, and M7 provide module drivers of selected life phases. For example, Kobayashi [23] provides a method that deals with life cycle aspects and thus mainly includes module drivers of the peripheral life phases: Product development, sales and marketing, and service. Jiao and Tseng [16] present a method that mainly includes production aspects.

In the method step descriptions, it is noticeable that some module drivers as levers for modularity do not tie in with the Impact Model via access points, such as the module drivers styling and temporal variety.

4.3 Application: Method Selection With Regard to the Objectives.

The collection of method step descriptions in combination with the Impact Model can now be used in different ways. On the one hand, the description enables a quick information acquisition on the module-forming steps of different modularization methods. Furthermore, the effects that can be achieved by carrying out the module-forming step of the different methods can be read off directly. It is shown which economic objectives can be achieved by many methods and which goals are not taken into account in the selection of the methods. It should be noted that the economic targets are shown qualitatively at this point in the basic research. We thus provide a generic database and its application, which can be used as a basis for specific cases. For quantitative analysis, a lot of case-specific data would be necessary.

The whole selection process builds on the database shown in Figs. 1 and 8. Modularization methods provide levers of modularity, whereby the economic impacts can be addressed, which are part of the impact model. For the selection process, this data linkage is viewed from the other side (Fig. 13).

Fig. 13
Method selection based on the economic impact
Fig. 13
Method selection based on the economic impact
Close modal

If one has not yet decided on a method, the Impact Model can be used to select suitable methods. For this purpose, relevant areas are defined in advance in the Impact Model (1). The Impact Model helps at this point to sharpen the objective behind the application of the modularization method.

The user of the database first selects the economic targets which he wants to address by means of a modularization method. In previous research, it became apparent that the impact chains of the Impact Model are dependent on the company's boundary conditions. Therefore, the user receives an Impact Model adapted to his company for the selection of the economic targets. Thus, the user can select only economic targets, which he can reach also by the given circumstances. Furthermore, the probabilities for the occurrence of effects are quantified in current research [35]. With the help of this quantification, it should be possible to prioritize impact chains in the future.

The module drivers, which allow access to the selected areas of the Impact Model, are detected via the access points (2). Modularization methods can then be selected whose module-forming steps have a positive impact on the relevant areas (3–4). Depending on the prioritization of the impact chains that will be possible in the future, it will also be possible to prioritize decision paths and thus also the resulting modularization methods.

It is also noticeable that some methods provide module drivers that access a large number of sections in the Impact Model. For this reason, the module drivers were also classified within the method steps. Depending on the economic targets that need to be achieved in the Impact Model, different module drivers should therefore be prioritized during the method implementation.

The following is a simple example that describes this procedure in more detail.

Company A is faced with the challenge that the services of this company are often rated poorly, as a result of which more and more customers migrate to the competitor. With the initial goal definition, it is defined that above all the lowering of the process times in the service is to be obtained by the restructuring of the offered product families. In the Impact Model, there are three service chains in terms of process time: 5050, 5060, and 5070. When the access points are examined, it becomes noticeable that the associated module drivers belong to the modularization methods M1, M2, M3, and M5.

Thus, these methods are now on a shortlist. On further inspection, these methods show some differences: Methods M1, M2, and M3 also address many of the economic targets of the other life phases and are thus somewhat broader in scope. Method M5 focuses only on three life phases in terms of module formation, which suggests that specialization is taking place here. The method selection has now been narrowed down, and further factors for method selection would have to be considered. The method selection was thus narrowed down. Depending on which additional factors are important to company A, a further narrowing down can take place according to the same scheme. If the company has already decided in advance on another method, such as Method 7, because the company works with method experts of this method, Method 7 can be adapted by aspects of methods M1, M2, M3, and M5.

5 Discussion

In this section, the results from Sec. 4 are discussed, and initial opportunities for revision or further research are identified.

5.1 Discussion of the Categorization of the Module Drivers.

The categorization of the module drivers into the life phases of the Impact Model basically works very well. Nevertheless, it is noticeable that different methods are based on different life cycle sequences, which result from the stocking strategy of a company. For example, procurement sometimes precedes production. Other methods assume that a product is first sold and then developed and manufactured. It should be investigated whether there is an influence of the stocking strategy on the economic objective and goal achievement and how this can be integrated into the method selection with regard to the economic objectives. Furthermore, there are some module drivers that cannot be integrated into the Impact Model via access points as a lever of modularity. When examining these module drivers, it became apparent that they can be roughly divided into two categories: Module drivers that are related to the ability to change (temporal variety (module driver in methods M1 and M6), technology push (module driver in method M2-3), …) and module drivers that are related to product personalization (styling (module driver in method M2-3)). It makes sense that these module drivers cannot be linked to the Impact Model, as this is currently intended more for variant management. The Impact Model therefore tends to show exactly the opposite: what happens, in terms of the economic targets, when variety is minimized. Through the integration of product personalization and the ability to change, variety is used in a planned manner to respond to individual customer wishes or future situations. There are now two ways to reach here. Either these aspects are integrated into the data basis of the Impact Model, in which case the Impact Model is expanded, or further Impact Models need to be created.

Furthermore, the levers provide information on which impact chains can possibly be extended in the Impact Model. An example of this is recycling. There are relatively many methods that are also linked to impact chain 5070 in the Impact Model with different module drivers. Here, it is noticeable that the module drivers and the effects of the Impact Model are on different abstraction levels. The Impact Model should be expanded to include more differentiated sustainability aspects and recycling aspects, as these points in particular are becoming increasingly important nowadays.

5.2 Discussion of the Execution of the Method Step Descriptions.

We divided into teams and applied the generic method step description described in Sec. 3.3 to the modularization methods from Sec. 3.1 separately from each other. This allowed us to gain valuable experience and validate the template for the description in terms of applicability.

The generic method step description could be applied to the module-forming steps of all seven methods (see the  Appendix). Thanks to the standardized description, the individual description attributes can now be recorded quickly and easily, and they can thus also be compared with one another. The selection of methods in this paper covers a wide range, which is why we assume that the generic method step description can also be applied to other modularization methods. The application of the template was done by us as design method experts. However, it must be said that in most cases we did not develop the methods ourselves and therefore used the literature that could be found for the information gathering. When using the template, we noticed that some areas were much easier to fill in than others. With the published information on the methods, the short descriptions and the objectives of the method step were easily detected. The stakeholder and also the inputs and outputs tended to be easy to name, but one should be aware that these items are also very use case specific. The attribute that required methodical knowledge for the method step was rather difficult to name, as this is a very subjective point.

5.3 Discussion of the Method Comparison and Selection Based on the Impact Model the and Method Step Descriptions.

It should be noted that although modularization methods provide certain module drivers, these are not necessarily used to form the modules. In the module-forming steps of Life Phase Modularization according to Blees et al. [17], for example, modularization concepts are created for each life phase individually. These concepts are then harmonized, whereby compromises have to be made. Knowledge of potential impacts can be used to support compromise formation.

This paper has shown that method selection can be supported in terms of its impact on economic targets. However, there are many other factors that lead to the selection of modularization methods. Examples are required resources, method knowledge, or applicability. These factors should be weighed when selecting a method.

With the help of the knowledge base (Table 2 and Figs. 11 and 12) and the procedure (Fig. 13), existing methods can be selected as described. However, if there is not a suitable method for the desired economic objectives, the knowledge base provides information on which modularization methods can be combined to achieve the set objectives. This is then a method adaptation. If a method adaptation was accomplished, then the adapted method is again taken up into the data basis, in order to strengthen the base. If there is no suitable method, this is a sign that there is a need for research.

6 Summary and Outlook

Within the scope of this paper, a procedure was developed to document the economic effects of the module-forming steps of modularization methods and then to use them for a comparison of methods in a qualitative, generic way.

For this purpose, modularization methods were first analyzed. By means of module drivers of the module-forming steps, the link to an Impact Model was made possible, which shows the economic effects (contribution part 1, related Secs. 3.1, 3.2, 4.1, 4.2, and 5.1). A generic method step description for the presentation of module-forming steps of modularization methods was developed based on existing models in the literature which enables the relevant information of the steps to be recorded quickly and easily (contribution part 2, related Secs. 3.3, 4.2, and 5.2). Furthermore, this description enables an analysis, comparison, and quick selection of modularization methods with regard to their addressed economic objectives (contribution part 3, related Secs. 4.3 and 5.3). The database developed in this paper is qualitative. The method analyses, comparisons, and selection are therefore also qualitative. In Sec. 2.1.2, it was shown that quantitative comparisons are also possible, for example, through the use of modularization metrics. With this paper, we have shown the possibility of qualitatively comparing methods with each other with regard to their addressed economic objectives. Section 4.3 also shows how modularization methods should be prioritized based on the quantification of the probability of occurrence of effects in the Impact Model. There is a need for research to combine the approach presented here with existing approaches from the literature to enable a multicriteria comparison. The formalization of the dependencies of the data along the decision path (Fig. 13) would also be beneficial for a multicriteria comparison. In this way, the influence of the probability of occurrence of individual effects on the modularization methods and their prioritization would be well represented.

We are aware that modularization methods have to be adapted in large modularization projects. For the application of the methods, method experts are necessary who make these adaptations specific to the situation. Our contribution allows us to support the objectives in such projects and the adaptations of modularization methods. Especially, the effects on economic targets in the later life phases, such as sales and service, are otherwise often lost sight of, as these are mentally far away from the development. It would be useful to examine documented use cases in order to validate the relationships between the levers of modularity and the Impact Model. Use cases here refer to the implementation of modularization methods in the context of modularization projects. In such use cases, the quantitative economic targets that were achieved could be included in the database. The database can be strengthened by backing up the qualitative correlations with quantitative findings.

Furthermore, the current visualization of the Impact Model is slowly reaching its limits. The relationships, which were initially analyzed and have now been visualized, can be thoroughly modeled in SysML in further research. In this way, the knowledge would be stored in a central location and indirect relationships can be made visible. A model-based implementation would have the additional advantage that different views of the data relationships can be created, thus reducing the total amount of visible information. A model-based implementation would also simplify the presentation of the relationship between module formation, module drivers, and economic targets, building on a consistent database. A tabular overview would reach its limits here. It would be very confusing since the relationships can fan out in both directions: A method has one (or more) module-forming steps, in which in turn several module drivers are used, each of which can result in several economic targets in the Impact Model. In the other direction, an economic target can be linked to several module drivers via the access points, which in turn occur in several modularization methods. Through a model-based implementation, the influence of company boundary conditions on a suitable method selection would also become visible. This would further simplify method selection. The Impact Model has already been mapped in SysML [52]. This modeling will be expanded to include new knowledge about the interface between modularization methods and the Impact Model. The already acquired analytical knowledge can be further deepened by analyses and simulations in SysML.

In the context of this paper, only the module-forming steps were examined. Other steps can also be exciting with regard to the objective and can be investigated, for example, method steps that can be assigned to the generic step “commonality assignment” according to Otto et al. [7]. Also, especially, the step that precedes the module formation (core step B) has a great impact on the module formation itself. This factor, which is probably very use case specific, should also be included and taken into account.

Additionally, it would be interesting to evaluate how a change in the business model would impact the module drivers. As for example the modularization of a product service-system could increase the (re-)configurability over the life cycle [53]. The Impact Model is continuously validated in order to consolidate the database stored in it. If the focus then changes over time, for example, with regard to sustainability, such changes will be reflected in the Impact Model. When this happens, the linkages of the modularization methods in these areas would need to be revised.

From this summary and outlook, it can be seen that our contribution is the first major step in a research direction to address a multifaceted problem. This basic research can now be seen as a basis for further research in this context.

Acknowledgment

Thanks to the German Research Foundation (Deutsche Forschungsgemeinschaft—DFG; Funder ID: 10.13039/501100001659) for funding this project within the research grant “WiMo 2— Entwicklung eines Wirkmodells der Eigenschaften modularer Produktstrukturen zur Bewertung methodischer Ansaetze” at the Hamburg University of Technology.

Conflict of Interest

There are no conflicts of interest.

Data Availability Statement

The authors attest that all data for this study are included in the paper.

Appendix

Below are the individual method step descriptions of the methods from Table 2:

  • M1 (Blees et al., 2010)

  • M2 (Ericsson and Erixon, 1999)

  • M3 (Blackenfelt, 2000)

  • M4 (Pimmler and Eppinger, 1994)

  • M5 (Kobayashi, 2001; Umeda et al., 2007)

  • M6 (Zamirowski and Otto, 1999)

  • M7 (Jiao and Tseng, 1999)

Fig. 14
Method step description of method M1
Fig. 14
Method step description of method M1
Close modal
Fig. 15
Method step description of method M2
Fig. 15
Method step description of method M2
Close modal
Fig. 16
Method step description of method M3
Fig. 16
Method step description of method M3
Close modal
Fig. 17
Method step description of method M4
Fig. 17
Method step description of method M4
Close modal
Fig. 18
Method step description of method M5
Fig. 18
Method step description of method M5
Close modal
Fig. 19
Method step description of method M6
Fig. 19
Method step description of method M6
Close modal
Fig. 20
Method step description of method M7
Fig. 20
Method step description of method M7
Close modal

References

1.
Blecker
,
T.
, and
Abdelkafi
,
N.
,
2006
, “
Complexity and Variety in Mass Customization Systems: Analysis and Recommendations
,”
Manage. Decis.
,
44
(
7
), pp.
908
929
.
2.
Krause
,
D.
, and
Gebhardt
,
N.
,
2018
,
Methodische Entwicklung Modularer Produktfamilien: Hohe Produktvielfalt Beherrschbar Entwickeln
,
Springer Vieweg
,
Berlin
.
3.
Hackl
,
J.
,
Krause
,
D.
,
Otto
,
K.
,
Windheim
,
M.
,
Moon
,
S. K.
,
Bursac
,
N.
, and
Lachmayer
,
R.
,
2020
, “
Impact of Modularity Decisions on a Firm's Economic Objectives
,”
ASME J. Mech. Des.
,
142
(
4
), p.
041403
.
4.
Pimmler
,
T. U.
, and
Eppinger
,
S. D.
,
1994
, “
Integration Analysis of Product Decompositions
,”
6th International Conference on Design Theory and Methodology
,
Minneapolis
,
MN, Sept. 11–14
.
5.
Kipp
,
T.
, and
Krause
,
D.
,
2008
, “
Design for Variety—Efficient Support for Design Engineers
,”
Proceedings of the 10th International Design Conference—Design 2008
,
Dubrovnik, Croatia
,
May 19–22
.
6.
Ericsson
,
A.
, and
Erixon
,
G.
,
1999
,
“Controlling Design Variants. Modular Product Platforms
,
Society of Manufacturing Engineers, ASME Press
,
New York
.
7.
Otto
,
K.
,
Hölttä-Otto
,
K.
,
Simpson
,
T. W.
,
Krause
,
D.
,
Ripperda
,
S.
, and
Moon
,
S. K.
,
2016
, “
Global Views on Modular Design Research: Linking Alternative Methods to Support Modular Product Family Concept Development
,”
ASME J. Mech. Des.
,
136
(
7
), p.
071101
.
8.
Krause
,
D.
, and
Ripperda
,
S.
,
2013
, “
An Assessment of Methodical Approaches to Support the Development of Modular Product Families
,”
Proceedings of International Conference on Engineering Design ICED 2013
,
Seoul, South Korea
,
Aug. 19–22
, pp.
031
040
.
9.
Stone
,
R. B.
,
Wood
,
K. L.
, and
Crawford
,
R. H.
,
2000
, “
A Heuristic Method to Identify Modules From a Functional Description of a Product
,”
Des. Stud.
,
21
(
1
), pp.
5
31
.
10.
Hölttä
,
K.
,
2004
, “
Comparative Analysis of Product Modularisation Methods
,”
Norddesign
,
Tampere, Finland
,
Aug. 18–20
.
11.
Browning
,
T. R.
,
2016
, “
Design Structure Matrix Extensions and Innovations: A Survey and New Opportunities
,”
IEEE Trans. Eng. Manage.
,
63
(
1
), pp.
27
52
.
12.
Lanner
,
P.
, and
Malmquist
,
J.
,
1996
, “
An Approach Towards Considering Technical and Economic Aspects in Product Architecture Design
,”
Proceedings of the 2nd WDK Workshop on Product Structuring 1996
,
Delft, The Netherlands
,
June 3–4
, pp.
12
16
.
13.
Yan
,
J.
,
Feng
,
C.
, and
Cheng
,
K.
,
2012
, “
Sustainability-Oriented Product Modular Design Using Kernel-Based Fuzzy c-Means Clustering and Genetic Algorithm
,”
Proc. Inst. Mech. Eng. B
,
226
(
10
), pp.
1635
1647
.
14.
Zamirowski
,
E. J.
, and
Otto
,
K.
,
1999
, “
Identifying Product Portfolio Architecture Modularity Using Function and Variety Heuristics
,”
ASME Design Engineering Technical Conferences—Design Theory and Methodology
,
Las Vegas, NV
,
Sept. 12–16
, pp.
187
197
.
15.
Salonen
,
M.
,
Hölttä-Otto
,
K.
, and
Otto
,
K.
,
2008
, “
Effecting Product Reliability and Life Cycle Costs With Early Design Phase Product Architecture Decisions
,”
Int. J. Prod. Dev.
,
5
(
1–2
), pp.
109
124
.
16.
Jiao
,
J.
, and
Tseng
,
M.
,
1999
, “
A Methodology of Developing Product Family Architecture for Mass Customization
,”
J. Intell. Manuf.
,
10
(
1
), pp.
3
20
.
17.
Blees
,
C.
,
Jonas
,
H.
, and
Krause
,
D.
,
2010
, “
Development of Modular Product Families
,”
Proceedings of the 12th International Dependency and Structure Modelling Conference DSM10
,
Cambridge, UK
,
July 22–23
, pp.
169
182
.
18.
Greve
,
E.
,
Rennpferdt
,
C.
, and
Krause
,
D.
,
2020
, “
Harmonizing Cross-Departmental Perspectives on Modular Product Families
,”
Procedia CIRP
,
91
, pp.
452
457
.
19.
Blackenfelt
,
M.
,
2001
, “Modularisation by Relational Matrices—A Method for the Consideration of Strategic and Functional Aspects,”
Design for Configuration
,
Springer
,
Berlin/Heidelberg
, pp.
134
152
.
20.
Kim
,
S.
, and
Moon
,
S. K.
,
2017
, “
Sustainable Product Family Configuration Based on a Platform Strategy
,”
J. Eng. Des.
,
2017
(
10–12
), pp.
731
764
.
21.
Moon
,
S.
, and
McAdams
,
D. A.
,
2012
, “
A Market-Based Design Strategy for a Universal Product Family
,”
ASME J. Mech. Des.
,
134
(
11
), p.
111007
.
22.
Umeda
,
Y.
,
Fukushige
,
S.
,
Tonoike
,
K.
, and
Kondoh
,
S.
,
2008
, “
Product Modularity for Life Cycle Design
,”
CIRP Ann. - Manuf. Technol.
,
57
(
1
), pp.
13
16
.
23.
Kobayashi
,
H.
,
2001
, “
A Method of Life Cycle Planning for Product Eco-improvement
,”
Int. J. Enviro. Conscious Des. Manuf.
,
8
(
4
), pp.
27
37
.
24.
Umeda
,
Y.
,
Daimon
,
T.
, and
Kondoh
,
S.
,
2007
, “
Life Cycle Option Selection Based on the Difference of Value and Physical Lifetimes for Life Cycle Design
,”
Proceedings of the International Conference on Engineering Design ICED 2007
,
Paris, France
,
July 28–31
, pp.
145
146
.
25.
Daniilidis
,
H.
,
Bauer
,
W.
, and
Lindemann
,
U.
,
2012
, “
Compendium for Modular and Platform Based Architecting
,”
Procedia Comput. Sci.
,
8
, pp.
220
225
.
26.
Borjesson
,
F.
,
2010
, “
A Systematic Qualitive Comparison of Five Approaches to Modularity
,”
Proceedings of the International Design Conference—Design 2010
,
Dubrovnik, Croatia
,
May 17–20
, pp.
147
156
.
27.
Gupta
,
S.
, and
Kremer
,
G.
,
2008
, “
Analyzing Three Modularizing Methodologies From Assembly and Variety Viewpoints
,”
Proceedings of the Industrial Engineering Research Conference 2008
,
Vancouver, Canada
,
May 17–20
, pp.
1660
1665
.
28.
Martin
,
M.
, and
Ishii
,
K.
,
2000
, “
Design for Variety: Developing Standardized and Modularized Product Platform Architecture
,”
J. Eng. Des.
,
13
(
4
), pp.
213
235
.
29.
Hölttä-Otto
,
K.
,
Chiriac
,
N. A.
,
Lysy
,
D.
, and
Suh
,
E. S.
,
2012
, “
Comparative Analysis of Coupling Modularity Metrics
,”
J. Eng. Des.
,
23
(
10–11
), pp.
787
803
.
30.
Borjesson
,
F.
, and
Hölttä-Otto
,
K.
,
2014
, “
A Module Generation Algorithm for Product Architecture Based on Component Interactions and Strategic Drivers
,”
Res. Eng. Des.
,
25
(
1
), pp.
31
51
.
31.
Fixson
,
S. K.
,
2007
, “
Modularity and Commonality Research: Past Developments and Future Opportunities
,”
Concurr. Eng.
,
15
(
2
), pp.
85
111
.
32.
Lau Antonio
,
K. W.
,
Yam
,
R. C. M.
, and
Tang
,
E.
,
2007
, “
The Impacts of Product Modularity on Competitive Capabilities and Performance: An Empirical Study
,”
Int. J. Prod. Econ.
,
105
(
1
), pp.
1
20
.
33.
Hackl
,
J.
, and
Krause
,
D.
,
2016
, “
Effects of Modular Product Structures on Life Phases and Economic Factors
,”
Proceedings of the 14th International Design Conference—Design 2016
,
Dubrovnik, Croatia
,
May 16–19
, pp.
1285
1294
.
34.
Schwede
,
L.-N.
,
Greve
,
E.
, and
Krause
,
D.
,
2020
, “
Validation Concept for the Investigation of Effects of Modular Product Families
,”
Proceedings of DESIGN Conference
,
Dubrovnik, Croatia
,
Oct. 26–29
, Vol. 1, pp.
2395
2404
.
35.
Greve
,
E.
,
Fuchs
,
C.
,
Hamraz
,
B.
,
Windheim
,
M.
,
Schwede
,
L.-N.
, and
Krause
,
D.
,
2020
, “
Investigating the Effects of Modular Product Structures to Support Design Decisions in Modularization Projects
,”
Proceedings of the 2020 IEEE International Conference on Industrial Engineering and Engineering Management (IEEM)
,
Singapore
,
Dec. 14–17
, IEEE, pp.
295
299
.
36.
Salvador
,
F.
,
2007
, “
Toward a Product System Modularity Construct. Literature Review and Reconceptualization
,”
IEEE Trans. Eng. Manage.
,
54
(
2
), pp.
219
240
.
37.
Weber
,
C.
,
2007
, “
Looking at DFX and Product Maturity From the Perspective of a New Approach to Modelling Product and Product Development Processes
,”
The Future of Product Development, Proceedings of the 17th CIRP Design Conference
,
Berlin, Germany
,
Mar. 26–28
, Springer, pp.
85
104
.
38.
Krause
,
D.
,
Schwede
,
L.-N.
,
Dambietz
,
F. M.
, and
Hanna
,
M.
,
2021
, “
Model-Based Systems Engineering—Discovering Potentials for Methodical Modular Product Development
,”
Design Methodology for Future Products
,
Springer
.
39.
Schwede
,
L.-N.
,
Winter
,
M.
,
Lödding
,
H.
, and
Krause
,
D.
,
2020
, “
Darstellung des Zusammenhangs von Produktarchitektur- und Produktionssystemgestaltung in SysML
,”
Proceedings of the Symposium Design for X (DfX)
,
Bamberg, Germany
,
Sept. 16–17
, pp.
41
50
.
40.
Blessing
,
L. T. M.
, and
Chakrabarti
,
A.
,
2009
,
DRM, a Design Research Methodology
,
Springer
,
London
.
41.
Graner
,
M.
,
2013
,
Der Einsatz von Methoden in Produktentwicklungsprojekten: Eine Empirische Untersuchung der Rahmenbedingungen und Auswirkungen
,
Springer Gabler
,
Wiesbaden
.
42.
Martin
,
J. N.
,
1997
,
Systems Engineering Guidebook: A Process for Developing Systems and Products, Systems Engineering Series
,
CRC Press
,
Boca Raton, FL
.
43.
Gericke
,
K.
,
Eckert
,
C.
, and
Stacey
,
M.
,
2017
, “
What Do We Need to Say About a Design Methods?
Proceedings of International Conference on Engineering Design ICED 2017
,
Vancouver, Canada
,
Aug. 21–25
, pp.
101
110
.
44.
Ponn
,
J.
, and
Lindemann
,
U.
,
2011
,
Konzeptentwicklung und Gestaltung Technischer Produkte, Systematisch von Anforderungen zu Konzepten und Gestaltlösungen
,
Springer-Verlag
,
Berlin/Heidelberg
.
45.
Lindemann
,
U.
,
2009
,
Methodische Entwicklung Technischer Produkte. Methoden Flexibel und Situationsgerecht Anwenden
,
Springer-Verlag
,
Berlin, Heidelberg
.
46.
Ross
,
D. T.
, and
Schoman
,
K. E.
,
1977
, “
Structured Analysis for Requirements Definition
,”
IEEE Trans. Soft. Eng.
,
SE-3
(
1
), pp.
6
15
.
47.
Birkhofer
,
H.
,
Kloberdanz
,
H.
,
Berger
,
B.
, and
Sauer
,
T.
,
2002
, “
Cleaning up Design Methods—Describing Methods Completely and Standardised
,”
Proceedings of Design Conference 2002
,
Dubrovnik, Croatia
,
May 14–17
, pp.
17
22
.
48.
Albers
,
A.
,
Reiß
,
N.
,
Bursac
,
N.
,
Walter
,
B.
, and
Gladysz
,
B.
,
2015
, “
InnoFox-Situationsspezifische Methodenempfehlung im Produktentstehungsprozess
,”
Stuttgarter Symposium für Produktentwicklung
,
Stuttgart, Germany
,
June 19
.
49.
VDI 2221
,
2019
,
Design of Technical Products and Systems, Model of Product Design
,
VDI
,
Düsseldorf
.
50.
Beckmann
,
G.
,
Gebhardt
,
N.
,
Bahns
,
T.
, and
Krause
,
D.
,
2016
, “
Approach to Transfer Methods for Developing Modular Product Families Into Practice
,”
Proceedings of Design Conference 2016
,
Dubrovnik, Croatia
,
May 16–19
, pp.
1185
1194
.
51.
Hanna
,
M.
,
Schwenke
,
J.
,
Schwede
,
L.-N.
,
Laukotka
,
F.
, and
Krause
,
D.
,
2021
, “
Model-Based Application of the Methodical Process for Modular Lightweight Design of Aircraft Cabins
,”
Proceedings of the 17th CIRP Design Conference
,
Twente, Netherlands
,
May 19–21
, Elsevier, pp.
637
642
.
52.
Schwede
,
L.-N.
,
Hanna
,
M.
,
Wortmann
,
N.
, and
Krause
,
D.
,
2019
, “
Consistent Modelling of the Impact Model of Modular Product Structures with Linking Boundary Conditions in SysML
,”
Proceedings of the International Conference on Engineering Design ICED 2019
,
Delft, The Netherlands
,
Aug. 5–8
, pp.
3601
3610
.
53.
Gembarski
,
P. C.
, and
Lachmayer
,
R.
,
2018
, “
Product-Service-Systems—What and Why Developers Can Learn From Mass Customization
,”
Enterprise Modelling and Information Systems Architectures
,
13
(
16
), pp.
1
16
.