For a full description, see: Kreimeyer, M.; Deubzer, F.; Danilovic, M.; Fuchs, S. D.; Herfeld, U.; Lindemann, U.: Team composition to enhance collaboration between embodiment design and simulation departments. In Proceedings of International Conference on Engineering Design, ICED’07, 28 – 31 August 2007, Paris. (with friendly permission by the authors)
Efficient collaboration between design and simulation departments is a key factor to efficient product development. An important part of efficient collaboration are adequate team structures that collect the appropriate competencies in a team.
This case presents the setup of team structures in automotive body development at a German premium automotive manufacturer. It involves an organization of approximately 800 engineers in embodiment design and about 50 engineers in simulation. The study focused on the development of the so-called “trimmed body” of a sedan. This scope comprises the car’s body, all doors and hatches as well as the interior panelling, including more than 400 components that are exposed to more than 130 structural load-cases related to comfort and safety.
Problem description and system definition
As the numbers show, single engineers need to navigate a highly complex system in search of specific information about the product. The overall goal of this research was therefore to design a strategy to ensure a purposeful transfer of information from the right senders to the right recipients, i.e. from the embodiment design engineers to the simulation engineers and back. This was aspired to create a higher level of interaction and better coordination between the departments in question. Specifically, integration and coordination between the three following aspects was aimed at:
- between different load cases (evaluated properties of the whole car’s trimmed-body, e.g. crash, harshness, vibration)
- between core components evaluated through simulation
- between the core elements in both embodiment design and simulation
The methodology shown below therefore was designed to answer the question how, through teams of manageable size, coordination of all engineers could be achieved so that, at the same time, information transfer in both directions could be ensured. These teams were to be supported by a core team to coordinate the overall efforts and, in particular, be responsible for the core components and load-cases.
Information acquisition
Three weighted DMMs were used to compute adequate teams:
- responsibility of embodiment design engineers in components
- involvement of components in simulated functions
- responsibility of simulation engineers for functions to be simulated
All matrices were collected as weighted matrices to represent the degree of involvement of one domain in the next. See below for a more detailed description of the matrices.
Dependencies
With the focus of organizing information exchange into adequate clusters (that later serve as teams), an algorithm to systematically compose the necessary competences to form teams that efficiently collaborate was formulated. The basic idea is to map components and load-cases in a DMM. This matrix is then clustered to obtain groups (“clusters”) of components and properties which are highly alike within each cluster. Then, relevant personnel is attributed to the clusters, and people who are part of a cluster form a team.
The methodology involves the following steps:
1. Weighting of the involvement of each component in each load case
To represent the quality of involvement, the linkage between components and load-cases is represented in the DMM using a weigh according to the importance of a component for a certain load-case. The matrix is then clustered to form (more or less) coherent clusters that contain elements that can be considered self similar on the individual level. They therefore represent each a particular situation or entity of information exchange between the involved engineers that can be standardized up to this level of self-similarity. The levels considered for the weighing are the following:
- level 3 – component is evaluated by load case (strongest linkage)
- level 2 – component is a significant part of the model
- level 1 – component is an element of the models border area
2. Attribution of personnel weighted according to the level of involvement
Depending on how much an engineer is responsible for a component (in embodiment design) or a load-case (in simulation), his involvement in that element is weighted accordingly. This assures at a later stage that those people of higher relevance to a cluster of components and load-cases can be identified easily. Again, the linkages are modelled as DMMs . The levels considered for the weighing are the following:
- level 3 – engineer is responsible for component or load case (strongest linkage)
- level 2 – engineer conducts the embodiment design/simulation of component/load case
- level 1 – engineer supports embodiment design/simulation of component/load case
However, the main problem turned out to be the fact that responsibilities and involvement in work procedures were only irregularly formalized and could not be accessed at all as only little documentation was available. Therefore, ultimately, only two modes of participation were used.
3. Configuration of team building blocks
Joining the three DMMs, the engineers involved in each cluster of in the component–load-case–DMM can be computed as shown below. Depending on the size of the initial cluster, these teams can be very large. In such a case, one large team is not desirable, as again one large team (as the worst case) is no improvement. In such a case, the overall strategy can either be applied on a finer level, or the strength of involvement can be used to compute the relevance of each person engineer to the overall team building block. If an engineer is only supporting the embodiment design (= weight 1) of one component that only borders the simulation area (= weight 1) and only has to interact with a simulation engineer who’s supporting the simulation of a load-case (= weight 1), their collaboration is of little relevance. In this case, the interaction strength is 1 * 1 * 1 = 1. If, however, another person is responsible for the embodiment design of a component (= weight 3) and conducts the embodiment design of yet another component (= weight 2), and each component is evaluated (= weight 3) by a simulation engineer responsible for that load-case (= weight 3), the interaction strength comes to 3 * 3 * 3 + 2 * 3 * 3 = 45. Thus, he is important in comparison to the first one.
4. Strategy to design integrated teams
Up to this stage, a number of team building blocks have been set up. These cannot exist solely, as the evaluation of a simulation will usually involve a number of these blocks to be “run” to collect all component-related information necessary for one load-case. The same is true for the integration of different simulations into one cluster of components. Therefore, for each direction of information exchange, the team building blocks have to be combined as necessary to for integrated virtual teams.
For the direction of function evaluation, those team building blocks that integrate all embodiment design engineers involved in cluster of load-cases are collected. Respectively, for function integration purposes, those team building blocks that collect all simulation results relevant to a cluster of components are combined to form a function integration team. Hereby, the networked structure of the product architecture from both a functional and a topology viewpoint can be recreated in the organizational structure to offer orientation for all engineers involved.
5. Coordination team
Besides the teams, a authority that oversees the collaboration was necessary to prioritize tasks and to settle conflicts. For this, only the key stake holders within the overall product architecture were extracted to act as a core team. Only those engineers that bear responsibility (= weight 3) for components that are evaluated (= weight 3) are eligible. This way, all core components of the product as well as all core functional properties are included.
Results
The body-in-white consists of a little more than 400 components, and there are about 130 load-cases that represent core functions (e.g. vibration and eigenfrequencies) that are simulated by FEM simulation. Accordingly, the DMM for components and load- cases involves >400 components in its rows and >130 load-cases in its columns. For each dependency, the weight is shown in a colouring scheme (yellow = 1, orange = 2, red = 3). After clustering, 153 relevant clusters could be identified that relate to 12 integrated teams for function evaluation and 22 integrated teams for function integration.
The following figure shows the three DMMs reduced to those relations elements that are weighted at level 3 to compute engineers eligible for the core team. As can be seen, the matrix of components and load-cases contains only rows and columns with at least one red element. The DMM for the simulation engineers turns out to be rather small, as only six simulation departments are involved in the 65 remaining load-cases. This way, 32 out of 153 clusters were identified as core clusters with relevant level three relationships that contribute to the coordination team.
In summary, the following structure was used:
- 1 integrated team for overall coordination
- 12 integrated teams for function evaluation
- 22 integrated teams for function integration
- 153 clusters of information packages, 32 of them being core clusters
Use case provided by Matthias Kreimeyer
The Design Structure Matrix (DSM) 