- Email: [email protected]
Application of DSMs for Analyzing Product and Organizational Structures
15TH INTERNATIONAL DEPENDENCY AND STRUCTURE MODELLING CONFERENCE, DSM 2013 MELBOURNE, AUSTRALIA, AUGUST 29 – 30, 2013
Application of DSMs for Analyzing Product and Organizational Structures Wolfgang Bauer, Fatos Elezi, Maik Maurer Institute of Product Development, Technische Universität München, Germany Abstract: The application of DSM methods for analyzing and optimizing structures is widely used for both, product and organization structures. The concept of modularity is applicable for both structures and achieved by clustering. Various literatures propose to implement modular structures and align the product and organization structure. This paper aims at developing a modular product structure for an existing product by modularization of the structure with and without respect to the current component responsibilities. Assigning teams for the module responsibilities, the two concepts are then analyzed and compared concerning the requested team communication if components are changed. Keywords: Modularization, clustering, organization structure, product structure
1 Introduction Today, modularity of products is very popular in industry. Modularity is a characteristic of a complex technical system which implies designing structures based on minimizing interfaces between modules while maximizing interfaces within them (Baldwin and Clark 1997). Modules can be combined in order to obtain new product configurations and offer a high variety of products. The internal complexity can be reduced while a high external variety can be offered (Baldwin and Clark 2000; Sanchez 2004). When aiming at a platform management, the first step is the implementation of a modular product architecture, in which subsystem interfaces are clearly defined and subsystems are shared across the product family (Meyera and DeToreb 2001). Modular products need a development process and organization that advocate the challenges of such a product structure. The designs teams are supposed to communicate according to the known product interfaces (Sosa et al. 2004). Modularization of the product can be used to coordinate the development effort, as development tasks can be partitioned. Through the definition and standardization of inter-modular dependencies, development tasks can be performed autonomously and concurrently (Sanchez and Mahoney 2002). To achieve this, (Colfer and Baldwin 2010) argue that if an organization wants to develop a modular product with independent components, the developers must have detailed prior knowledge of all possible dependencies between the components and modules. Especially by changing design parameters of a component, the necessary communication and coordination to other design teams must be transparent. To prevent possible change effects, whether planned or not, to other teams’ component both, the interfaces between components and the teams’ responsibility have to be known. The information flow can be made transparent to flow to the right people at the right time (Eppinger and Browning 2012).
DSM 2013
11
Part I: Application of DSM and Matrix Methods
The paper is structured as follows: section 2 outlines the objectives in the context of the case study. In section 3, the applied approach as well as the analyses of the product structure, both dependent and independent of the organization, are presented and discussed. Section 4 gives a summary and an outlook of further research.
2 Problem Outline In the presented study, the firm has not yet implemented a modular architecture strategy. The current product portfolio and derived variants evolved historically, resulting in no systematically defined product structures or modules. In order to manage the offered variety and ensure the use of carry-over modules in different products, the current product structure has to be analyzed regarding modularity. Besides the existing product structures, the boundary conditions of the current development organization are taken into account in this study. It is necessary to analyze the organization structure and its alignment to the product structure. A transparent, purposeful and efficient communication between the design teams should be established by knowing the change implications within or across modules as well as the responsible design team. When changing a component, the effects can be traced in the product structure. If it is an intra-module effect the communication path is quite obvious. But if the changes affect other modules, the communication can be supported by the created transparency. Often, such change effects are not explicitly recognized by a design team and the implication is discovered very late, for example during integration or testing, leading to high change costs. This will cause a longer production time in manufacturing, a low end-product performance, more time required for experiments and testing, a higher system integration effort and little product innovation (Lau 2009). Based on the initial situation, the main objective is the development of a modular product concept with respect to the current development organization. The modular product concept should be designed in a robust way such as changes and their effects within the structure should be minimized and encapsulated in modules and its correspondent teams. If changes occur the propagation within the structure must be known in order to identify the required communication paths within and across design teams. The analyses and optimizations are accomplished in two different ways, both applying DSM methods (Browning 2001; Eppinger and Browning 2012). First, the product structure of a basic unit is analyzed concerning modularity with respect to the current development teams’ responsibility for the product components. Second, the product structure is modularized ignoruing organizational boundary conditions but with respect to physical interfaces and minimal change impact into the whole structure. Both concepts are compared concerning the modularity and the team interaction structure.
3 Applied Approach and Case Study The procedure applied in the case study contains four steps. Step 1 includes the system definition and data acquisition according to (Lindemann et al. 2009). A component Design Structure Matrix (DSM) as well as a Domain Mapping Matrix (DMM) (Danilovic and 12
DSM 2013
W. Bauer, F. Elezi, M. Maurer
Browning 2007), mapping the components to design teams responsible for the component development, are built. In step 2, the DSM is clustered with respect to the teams’ responsibility. In step 3, the initial component DSM is clustered to identify modules independent from the organizational responsibilities. After the clustering, the teams’ responsibility is highlighted within the reordered matrix. In step 4, the two different modular concepts are compared. The advantages and disadvantages are assessed to choose the more appropriate concept. In the following sub-sections, the single steps are presented in more detail by applying a case study of a basic unit of a refrigerator product family and its current organization. 3.1 System Definition and Information Acquisition In the first step, a component DSM was built. Therefore, the bill of material served as basis and subsequent discussions with engineers finalized the DSM. The final DSM is built out of 94 components. The main objective of the structural optimization is the deduction of a modular structure which is robust against changes, meaning that changes should propagate only within modules. Fewer interfaces should be between different modules than within modules as changes propagate over the interfaces. The dependency type between the components was chosen “changes”. A dependency was set in the DSM, if for example a change of component A changes component B. In this case, the dependency is bidirectional. The DSM was filled out in four workshops with the four current design teams. To reduce the acquisition effort and ensure the data quality, we took advantage of the symmetry of the DSM. Each team filled the rows of “their” components. The following teams controlled the set interfaces between their and the other teams’ components which were already set. In total, 462 dependencies of 8742 possible ones were set. Moreover, the DMM “team is responsible for component” was built up and filled during the workshops to have the responsibility for each component at hand. The “responsibility for components” was chosen from two different reasons: first, human resource management activities encompass the definition of responsibilities and the assignment of tasks to individual persons or teams (Pons 2008). Second, the frequency of communication between the teams or even between all involved designers as shown in (Eppinger and Browning 2012) was too time-consuming for this initial study. 3.2 Intra-team Clustering of the Component DSM In this step, the information from the DMM was used to split up the component DSM with respect to the responsibility of each component. This was only possible because no component is developed by more than one team. The resulting four DSMs were clustered with an algorithm in order to identify component modules. Each team was given a color code (orange, green, blue, and grey). The result of the clustering of the four re-ordered DSMs is shown in Figure 1.
DSM 2013
13
Part I: Application of DSM and Matrix Methods
Figure 1. Resulting modules based on clustering the DSMs with respect to the organization
The components of team oranges responsibility are clustered into three modules, two of them connected by one intersectional component each. The clustering of team blue’s components resulted in seven clusters, only four are connected by physical interfaces. One component in team blue is not connected to any other of these components1. Team green’s components are re-ordered into three modules with only one interface (intersectional) between two modules. The components in team grey’s responsibility are grouped in one single module. After the clustering, the initial component DSM was re-ordered according the results from the clustering of each of the four team-driven DSMs. In contrary to the four DSMs, not only the intra-team dependencies but also the inter-team dependencies are depicted. The different physical modules of the whole system is now at hand, named modular concept 1. The clustered and reassembled DSM is shown in Figure 2. The resulting re-ordered DSM shows potential modules as well as the responsibility of the teams for these modules. This provides a first solution to the stated problem of a missing defined modular concept including the modules as well as the physical interfaces between the modules. From the organizational view, two aspects are made transparent: first, the physical interfaces between the intra-team modules are known. Therefore, the teams can be split up in more development sub-teams according to the number of modules of the team. Subteams can take over the responsibility for more than one module, for example in team blue. It seems likely that the intra-team interfaces are known at least implicitly. The module responsibility within the team is clear and changes can be communicated efficient. With a high probability, the communication will take place anyway. Second, the physical interfaces between the different teams are shown in the DSM. The
1 A plausibility check revised this phenomenon, resulting that the dependencies as well as the responsibility was set in the right way.
14
DSM 2013
W. Bauer, F. Elezi, M. Maurer
Figure 2. Modular concept 1
probability of inter-team communication between the teams is lower than in the first case (intra-team). Changes to one component which spreads to other modules can be traced by the DSM. Because of the color-coded information about the teams’ responsibilities, the communication way between the teams is known. This overcomes the problem stated by (Sosa et al. 2004) that necessary technical interdependencies may not be sufficiently addressed by technical communication.
Figure 3. Scheme (left) and results (right) of calculating the indirect dependencies between the design teams
The intensity of the inter-team communication according to the shared inter-module interfaces, is shown in Figure 3. The values within the team interaction matrix represent the number of indirect dependencies between team i and team j because team i is responsible for components (DMMTeam,i-Components) which can change components (DSMComponents) for which team j is accounted. The higher the value the stronger two teams are linked based on physical interfaces between the teams’ modules. For example, team orange and team green share the highest amount of inter-module interfaces, whereas team blue and team green are not connected at all. The connected teams have to be aware of their inter-module interfaces and have to carefully check these interfaces if changes of components in their responsibility propagate to other modules. To receive these values, indirect dependencies are calculated according to (Lindemann et al. 2009): DSM 2013
15
Part I: Application of DSM and Matrix Methods
DSMTeams = DMMTeam,i-Components * DSMComponents * DMMTeam,j-ComponentesT The values in the cross-diagonal of the DSM represent the shared interfaces within the four teams. These values are significantly higher than the inter-team values which support the request of more interfaces within a module and a team’s responsibility than between the physical modules accounted to different teams. Having this first modularization concept and the intra-team and inter-team communication ways at hand, a more efficient and effective development process is enabled by defined physical interfaces and communication ways. 3.3 Clustering of the Component DSM without Respect to the Organization In step 3 the initial component DSM is clustered to identify modules independent from the organizational responsibilities. The clustering was again carried out applying a clustering algorithm. As the main objective of the modular concept is to avoid inter-module change propagation, the initial results of the clustering was further optimized in the following way: the product under consideration is a basic unit from which variant instances are derived. The derivation is carried out by varying variation parameters, such as color or energy efficiency. If changes occur during the product life cycle, e.g. due to changing market conditions or requested new variants by regional sales and distribution, these variation parameters change to meet the market demand. The components which realize the variation parameters were – if possible – grouped into modules.
Figure 4. Modular concept 2
Regarding this modular concept, changes during the product life cycle can be isolated in a better way and undesired change propagation to other modules can be decreased. Modular concept 2 consists of nine modules, shown in Figure 4. Four development teams with mixed competencies are recommended. Team 1 is proposed to be the core team as they share numerous interfaces to other modules to integrate a lot of other modules. Team 1 should be responsible for monitoring these interfaces to ensure the interaction and integration of all modules. 16
DSM 2013
W. Bauer, F. Elezi, M. Maurer
3.4 Comparison of Modular Concepts By comparing both modular concepts (see Table 1), concept 2 turns out to be the more appropriate one. First, more interfaces are encapsulated within the modules than between modules. Second, no intersectional dependencies between modules occur. This fact improves the independence of the modules amongst each other. Third, modular concept 2 better meets the objective of minimal change propagation beyond modules as it is optimized towards this requirement. Because of these three reasons, it is recommended to re-structure the current teams and the responsibilities for the identified modules. Rearranging and aligning the teams according to modular concept 2 reduce the necessary inter-team communication which often causes unplanned and late changes to the product structure. The communication paths between the teams are more transparent as possible change propagations between teams can be traced using the DSM in Figure 4. Changes must be monitored regarding inter-module propagation and aligned by communication to the right team at the right time, resulting in fewer unplanned changes, engineering effort and improved time-to-market. Table 1. Comparison of Modular concepts Criteria Number of Modules Interfaces encapsulated in modules / Interfaces between modules Module intersections / Affected interfaces Minimal change propagation
Modular Modular Concept 1 Concept 2 14
9
300 / 162
326 / 136
3 / 42
0
no
yes
4 Conclusion and Outlook The contribution introduced the relation between product and organizational structures and outlined the challenges and objectives of the case study. A component DSM and a DMM, mapping the team responsibility to the components, was acquired. The product structure was modularized by clustering with respect to the current design teams, resulting in the modular concept 1. Modular concept 2 was achieved by clustering without concerning the organization. The concepts were compared in whereat concept 2 performs better as it contains better manageable inter-module dependencies, is more robust against changes and eliminates intersectional dependencies. In the next steps the functional structure as well as the dependencies between the functions and their components will be acquired. These interdependencies enlarge the perspective on the product and will be analyzed in an analogue way, with and without respect to the organization. If the final modular concept is chosen, further product variants will be structurally analyzed in order to identify and increase the carry-over rate of modules. The organization will be aligned to the product family structure to achieve a counterbalanced work load of the design teams.
DSM 2013
17
Part I: Application of DSM and Matrix Methods
Acknowledgments We thank the German Research Foundation (Deutsche Forschungsgemeinschaft – DFG) for funding this project as part of the collaborative research center ‘Sonderforschungsbereich 768 – Managing cycles in innovation processes – Integrated development of product-service-systems based on technical products’.
References Baldwin, C.Y. and Clark, K.B. (1997) Managing in an Age of Modularity. Harvard Business Review, 75, pp. 10. Baldwin, C.Y. and Clark, K.B. (2000) Design rules: The power of modularity. Cambridge, MA, MIT Press. Browning, T.R. (2001) Applying the design structure matrix to system decomposition and integration problems: a review and new directions. IEEE Transactions on Engineering Management, 48(3), pp. 292-306. Colfer, L. and Baldwin, C.Y. (2010) The mirroring hypothesis: Theory, evidence and exceptions. Harvard Business School Finance Working Paper (10-058). Danilovic, M. and Browning, T.R. (2007) Managing complex product development projects with design structure matrices and domain mapping matrices. International Journal of Project Management, 25(3), pp. 300-314. Eppinger, S.D. and Browning, T.R. (2012) Design structure matrix methods and applications. Cambridge, MA, MIT Press. Lau, A.K.W. (2009) Managing modular product design: critical factors and a managerial guide. In Management of Engineering & Technology, 2009. PICMET 2009. Portland International Conference on. pp. 2045-2057 IEEE. Lindemann, U., Maurer, M. and Braun, T. (2009) Structural Complexity Management. Springer London, Limited. Meyera, M.H. and DeToreb, A. (2001) Perspective: Creating a platform‐based approach for developing new services. Journal of Product Innovation Management, 18(3), pp. 188-204. Pons, D. (2008) Project management for new product development. Project Management Journal, 39(2), pp. 82-97. Sanchez, R. (2004) Creating modular platforms for strategic flexibility. Design Management Review, 15(1), pp. 58-67. Sanchez, R. and Mahoney, J.T. (2002) Modularity, flexibility and knowledge management in product and organization design. Managing in the Modular Age: Architectures, Networks, and Organizations, pp. 362. Sosa, M.E., Eppinger, S.D. and Rowles, C.M. (2004) The misalignment of product architecture and organizational structure in complex product development. Management science, 50(12), pp. 1674-1689. Contact: Wolfgang Bauer, Technische Universität München, Institute of Product Development, Boltzmannstraße 15, 85748 Garching, Germany, Phone +49 89.289.151.40, [email protected], http://www.pe.mw.tum.de
18
DSM 2013
Application of DSMs for Analyzing Product and Organizational Structures Wolfgang Bauer, Fatos Elezi, Maik Maurer Institute of Product Development, Technische Universität München, Germany Abstract: The application of DSM methods for analyzing and optimizing structures is widely used for both, product and organization structures. The concept of modularity is applicable for both structures and achieved by clustering. Various literatures propose to implement modular structures and align the product and organization structure. This paper aims at developing a modular product structure for an existing product by modularization of the structure with and without respect to the current component responsibilities. Assigning teams for the module responsibilities, the two concepts are then analyzed and compared concerning the requested team communication if components are changed. Keywords: Modularization, clustering, organization structure, product structure
1 Introduction Today, modularity of products is very popular in industry. Modularity is a characteristic of a complex technical system which implies designing structures based on minimizing interfaces between modules while maximizing interfaces within them (Baldwin and Clark 1997). Modules can be combined in order to obtain new product configurations and offer a high variety of products. The internal complexity can be reduced while a high external variety can be offered (Baldwin and Clark 2000; Sanchez 2004). When aiming at a platform management, the first step is the implementation of a modular product architecture, in which subsystem interfaces are clearly defined and subsystems are shared across the product family (Meyera and DeToreb 2001). Modular products need a development process and organization that advocate the challenges of such a product structure. The designs teams are supposed to communicate according to the known product interfaces (Sosa et al. 2004). Modularization of the product can be used to coordinate the development effort, as development tasks can be partitioned. Through the definition and standardization of inter-modular dependencies, development tasks can be performed autonomously and concurrently (Sanchez and Mahoney 2002). To achieve this, (Colfer and Baldwin 2010) argue that if an organization wants to develop a modular product with independent components, the developers must have detailed prior knowledge of all possible dependencies between the components and modules. Especially by changing design parameters of a component, the necessary communication and coordination to other design teams must be transparent. To prevent possible change effects, whether planned or not, to other teams’ component both, the interfaces between components and the teams’ responsibility have to be known. The information flow can be made transparent to flow to the right people at the right time (Eppinger and Browning 2012).
DSM 2013
11
Part I: Application of DSM and Matrix Methods
The paper is structured as follows: section 2 outlines the objectives in the context of the case study. In section 3, the applied approach as well as the analyses of the product structure, both dependent and independent of the organization, are presented and discussed. Section 4 gives a summary and an outlook of further research.
2 Problem Outline In the presented study, the firm has not yet implemented a modular architecture strategy. The current product portfolio and derived variants evolved historically, resulting in no systematically defined product structures or modules. In order to manage the offered variety and ensure the use of carry-over modules in different products, the current product structure has to be analyzed regarding modularity. Besides the existing product structures, the boundary conditions of the current development organization are taken into account in this study. It is necessary to analyze the organization structure and its alignment to the product structure. A transparent, purposeful and efficient communication between the design teams should be established by knowing the change implications within or across modules as well as the responsible design team. When changing a component, the effects can be traced in the product structure. If it is an intra-module effect the communication path is quite obvious. But if the changes affect other modules, the communication can be supported by the created transparency. Often, such change effects are not explicitly recognized by a design team and the implication is discovered very late, for example during integration or testing, leading to high change costs. This will cause a longer production time in manufacturing, a low end-product performance, more time required for experiments and testing, a higher system integration effort and little product innovation (Lau 2009). Based on the initial situation, the main objective is the development of a modular product concept with respect to the current development organization. The modular product concept should be designed in a robust way such as changes and their effects within the structure should be minimized and encapsulated in modules and its correspondent teams. If changes occur the propagation within the structure must be known in order to identify the required communication paths within and across design teams. The analyses and optimizations are accomplished in two different ways, both applying DSM methods (Browning 2001; Eppinger and Browning 2012). First, the product structure of a basic unit is analyzed concerning modularity with respect to the current development teams’ responsibility for the product components. Second, the product structure is modularized ignoruing organizational boundary conditions but with respect to physical interfaces and minimal change impact into the whole structure. Both concepts are compared concerning the modularity and the team interaction structure.
3 Applied Approach and Case Study The procedure applied in the case study contains four steps. Step 1 includes the system definition and data acquisition according to (Lindemann et al. 2009). A component Design Structure Matrix (DSM) as well as a Domain Mapping Matrix (DMM) (Danilovic and 12
DSM 2013
W. Bauer, F. Elezi, M. Maurer
Browning 2007), mapping the components to design teams responsible for the component development, are built. In step 2, the DSM is clustered with respect to the teams’ responsibility. In step 3, the initial component DSM is clustered to identify modules independent from the organizational responsibilities. After the clustering, the teams’ responsibility is highlighted within the reordered matrix. In step 4, the two different modular concepts are compared. The advantages and disadvantages are assessed to choose the more appropriate concept. In the following sub-sections, the single steps are presented in more detail by applying a case study of a basic unit of a refrigerator product family and its current organization. 3.1 System Definition and Information Acquisition In the first step, a component DSM was built. Therefore, the bill of material served as basis and subsequent discussions with engineers finalized the DSM. The final DSM is built out of 94 components. The main objective of the structural optimization is the deduction of a modular structure which is robust against changes, meaning that changes should propagate only within modules. Fewer interfaces should be between different modules than within modules as changes propagate over the interfaces. The dependency type between the components was chosen “changes”. A dependency was set in the DSM, if for example a change of component A changes component B. In this case, the dependency is bidirectional. The DSM was filled out in four workshops with the four current design teams. To reduce the acquisition effort and ensure the data quality, we took advantage of the symmetry of the DSM. Each team filled the rows of “their” components. The following teams controlled the set interfaces between their and the other teams’ components which were already set. In total, 462 dependencies of 8742 possible ones were set. Moreover, the DMM “team is responsible for component” was built up and filled during the workshops to have the responsibility for each component at hand. The “responsibility for components” was chosen from two different reasons: first, human resource management activities encompass the definition of responsibilities and the assignment of tasks to individual persons or teams (Pons 2008). Second, the frequency of communication between the teams or even between all involved designers as shown in (Eppinger and Browning 2012) was too time-consuming for this initial study. 3.2 Intra-team Clustering of the Component DSM In this step, the information from the DMM was used to split up the component DSM with respect to the responsibility of each component. This was only possible because no component is developed by more than one team. The resulting four DSMs were clustered with an algorithm in order to identify component modules. Each team was given a color code (orange, green, blue, and grey). The result of the clustering of the four re-ordered DSMs is shown in Figure 1.
DSM 2013
13
Part I: Application of DSM and Matrix Methods
Figure 1. Resulting modules based on clustering the DSMs with respect to the organization
The components of team oranges responsibility are clustered into three modules, two of them connected by one intersectional component each. The clustering of team blue’s components resulted in seven clusters, only four are connected by physical interfaces. One component in team blue is not connected to any other of these components1. Team green’s components are re-ordered into three modules with only one interface (intersectional) between two modules. The components in team grey’s responsibility are grouped in one single module. After the clustering, the initial component DSM was re-ordered according the results from the clustering of each of the four team-driven DSMs. In contrary to the four DSMs, not only the intra-team dependencies but also the inter-team dependencies are depicted. The different physical modules of the whole system is now at hand, named modular concept 1. The clustered and reassembled DSM is shown in Figure 2. The resulting re-ordered DSM shows potential modules as well as the responsibility of the teams for these modules. This provides a first solution to the stated problem of a missing defined modular concept including the modules as well as the physical interfaces between the modules. From the organizational view, two aspects are made transparent: first, the physical interfaces between the intra-team modules are known. Therefore, the teams can be split up in more development sub-teams according to the number of modules of the team. Subteams can take over the responsibility for more than one module, for example in team blue. It seems likely that the intra-team interfaces are known at least implicitly. The module responsibility within the team is clear and changes can be communicated efficient. With a high probability, the communication will take place anyway. Second, the physical interfaces between the different teams are shown in the DSM. The
1 A plausibility check revised this phenomenon, resulting that the dependencies as well as the responsibility was set in the right way.
14
DSM 2013
W. Bauer, F. Elezi, M. Maurer
Figure 2. Modular concept 1
probability of inter-team communication between the teams is lower than in the first case (intra-team). Changes to one component which spreads to other modules can be traced by the DSM. Because of the color-coded information about the teams’ responsibilities, the communication way between the teams is known. This overcomes the problem stated by (Sosa et al. 2004) that necessary technical interdependencies may not be sufficiently addressed by technical communication.
Figure 3. Scheme (left) and results (right) of calculating the indirect dependencies between the design teams
The intensity of the inter-team communication according to the shared inter-module interfaces, is shown in Figure 3. The values within the team interaction matrix represent the number of indirect dependencies between team i and team j because team i is responsible for components (DMMTeam,i-Components) which can change components (DSMComponents) for which team j is accounted. The higher the value the stronger two teams are linked based on physical interfaces between the teams’ modules. For example, team orange and team green share the highest amount of inter-module interfaces, whereas team blue and team green are not connected at all. The connected teams have to be aware of their inter-module interfaces and have to carefully check these interfaces if changes of components in their responsibility propagate to other modules. To receive these values, indirect dependencies are calculated according to (Lindemann et al. 2009): DSM 2013
15
Part I: Application of DSM and Matrix Methods
DSMTeams = DMMTeam,i-Components * DSMComponents * DMMTeam,j-ComponentesT The values in the cross-diagonal of the DSM represent the shared interfaces within the four teams. These values are significantly higher than the inter-team values which support the request of more interfaces within a module and a team’s responsibility than between the physical modules accounted to different teams. Having this first modularization concept and the intra-team and inter-team communication ways at hand, a more efficient and effective development process is enabled by defined physical interfaces and communication ways. 3.3 Clustering of the Component DSM without Respect to the Organization In step 3 the initial component DSM is clustered to identify modules independent from the organizational responsibilities. The clustering was again carried out applying a clustering algorithm. As the main objective of the modular concept is to avoid inter-module change propagation, the initial results of the clustering was further optimized in the following way: the product under consideration is a basic unit from which variant instances are derived. The derivation is carried out by varying variation parameters, such as color or energy efficiency. If changes occur during the product life cycle, e.g. due to changing market conditions or requested new variants by regional sales and distribution, these variation parameters change to meet the market demand. The components which realize the variation parameters were – if possible – grouped into modules.
Figure 4. Modular concept 2
Regarding this modular concept, changes during the product life cycle can be isolated in a better way and undesired change propagation to other modules can be decreased. Modular concept 2 consists of nine modules, shown in Figure 4. Four development teams with mixed competencies are recommended. Team 1 is proposed to be the core team as they share numerous interfaces to other modules to integrate a lot of other modules. Team 1 should be responsible for monitoring these interfaces to ensure the interaction and integration of all modules. 16
DSM 2013
W. Bauer, F. Elezi, M. Maurer
3.4 Comparison of Modular Concepts By comparing both modular concepts (see Table 1), concept 2 turns out to be the more appropriate one. First, more interfaces are encapsulated within the modules than between modules. Second, no intersectional dependencies between modules occur. This fact improves the independence of the modules amongst each other. Third, modular concept 2 better meets the objective of minimal change propagation beyond modules as it is optimized towards this requirement. Because of these three reasons, it is recommended to re-structure the current teams and the responsibilities for the identified modules. Rearranging and aligning the teams according to modular concept 2 reduce the necessary inter-team communication which often causes unplanned and late changes to the product structure. The communication paths between the teams are more transparent as possible change propagations between teams can be traced using the DSM in Figure 4. Changes must be monitored regarding inter-module propagation and aligned by communication to the right team at the right time, resulting in fewer unplanned changes, engineering effort and improved time-to-market. Table 1. Comparison of Modular concepts Criteria Number of Modules Interfaces encapsulated in modules / Interfaces between modules Module intersections / Affected interfaces Minimal change propagation
Modular Modular Concept 1 Concept 2 14
9
300 / 162
326 / 136
3 / 42
0
no
yes
4 Conclusion and Outlook The contribution introduced the relation between product and organizational structures and outlined the challenges and objectives of the case study. A component DSM and a DMM, mapping the team responsibility to the components, was acquired. The product structure was modularized by clustering with respect to the current design teams, resulting in the modular concept 1. Modular concept 2 was achieved by clustering without concerning the organization. The concepts were compared in whereat concept 2 performs better as it contains better manageable inter-module dependencies, is more robust against changes and eliminates intersectional dependencies. In the next steps the functional structure as well as the dependencies between the functions and their components will be acquired. These interdependencies enlarge the perspective on the product and will be analyzed in an analogue way, with and without respect to the organization. If the final modular concept is chosen, further product variants will be structurally analyzed in order to identify and increase the carry-over rate of modules. The organization will be aligned to the product family structure to achieve a counterbalanced work load of the design teams.
DSM 2013
17
Part I: Application of DSM and Matrix Methods
Acknowledgments We thank the German Research Foundation (Deutsche Forschungsgemeinschaft – DFG) for funding this project as part of the collaborative research center ‘Sonderforschungsbereich 768 – Managing cycles in innovation processes – Integrated development of product-service-systems based on technical products’.
References Baldwin, C.Y. and Clark, K.B. (1997) Managing in an Age of Modularity. Harvard Business Review, 75, pp. 10. Baldwin, C.Y. and Clark, K.B. (2000) Design rules: The power of modularity. Cambridge, MA, MIT Press. Browning, T.R. (2001) Applying the design structure matrix to system decomposition and integration problems: a review and new directions. IEEE Transactions on Engineering Management, 48(3), pp. 292-306. Colfer, L. and Baldwin, C.Y. (2010) The mirroring hypothesis: Theory, evidence and exceptions. Harvard Business School Finance Working Paper (10-058). Danilovic, M. and Browning, T.R. (2007) Managing complex product development projects with design structure matrices and domain mapping matrices. International Journal of Project Management, 25(3), pp. 300-314. Eppinger, S.D. and Browning, T.R. (2012) Design structure matrix methods and applications. Cambridge, MA, MIT Press. Lau, A.K.W. (2009) Managing modular product design: critical factors and a managerial guide. In Management of Engineering & Technology, 2009. PICMET 2009. Portland International Conference on. pp. 2045-2057 IEEE. Lindemann, U., Maurer, M. and Braun, T. (2009) Structural Complexity Management. Springer London, Limited. Meyera, M.H. and DeToreb, A. (2001) Perspective: Creating a platform‐based approach for developing new services. Journal of Product Innovation Management, 18(3), pp. 188-204. Pons, D. (2008) Project management for new product development. Project Management Journal, 39(2), pp. 82-97. Sanchez, R. (2004) Creating modular platforms for strategic flexibility. Design Management Review, 15(1), pp. 58-67. Sanchez, R. and Mahoney, J.T. (2002) Modularity, flexibility and knowledge management in product and organization design. Managing in the Modular Age: Architectures, Networks, and Organizations, pp. 362. Sosa, M.E., Eppinger, S.D. and Rowles, C.M. (2004) The misalignment of product architecture and organizational structure in complex product development. Management science, 50(12), pp. 1674-1689. Contact: Wolfgang Bauer, Technische Universität München, Institute of Product Development, Boltzmannstraße 15, 85748 Garching, Germany, Phone +49 89.289.151.40, [email protected], http://www.pe.mw.tum.de
18
DSM 2013