1. INTRODUCTION
In order to reduce complexity and increase manageability of complex systems, one of the principles used in systems engineering is to cluster system elements into larger chunks (Chiriac et al., Reference Chiriac, Hölttä-Otto, Lysy and Suk Suh2011); this is known as modularization. The design and manufacturing of these modules is often outsourced to different suppliers for reducing or managing time-to-market and cost. Consideration of interfaces (Tripathy & Eppinger, Reference Tripathy and Eppinger2011), cost reduction (Nepal et al., Reference Nepal, Monplaisir and Famuyiwa2012), platform policy (Zhang et al., Reference Zhang, Huang and Rungtusanatham2008), and new technology integration (Chiu & Okudan, Reference Chiu and Okudan2011) require integrating suppliers starting in early design stages. Because suppliers are getting more and more tightly integrated into the design process in complex system design (Le Dain et al., Reference Le Dain, Calvi and Cheriti2011), they form, together with the original equipment manufacturer (OEM), an extended enterprise (Nguyen Van, Reference Nguyen Van2006), and greatly influence the outcome of the OEM's final products.
In modular design, interfaces shared among modules in a given system architecture are usually specified and standardized (Ro et al., Reference Ro, Liker and Fixson2007), so that changes in one module of the system normally do not require changes in other parts of the system (Hoetker, Reference Hoetker2006). This gives OEMs the ability to choose suppliers more freely vis-à-vis the evolving system requirements.
Before choosing suppliers for a new system, OEMs usually first identify a group of potential suppliers, let them submit proposals, and then choose a suitable supplier for each module after negotiation. The focus of this work is about this stage where the group of potential suppliers is identified. OEMs normally tend to use those suppliers with which they have a prior history of cooperation, because past interactions usually improve communication between buyer and suppliers (Levinthal & Fichman, Reference Levinthal and Fichman1991; Singh & Mitchell, Reference Singh and Mitchell1996). This leads to faster, cheaper procurement and more successful system development (Hoetker, Reference Hoetker2005). However, existing suppliers may not always satisfy all new requirements of an OEM for the system. In such situations, the OEM has to find new suppliers with suitable new modules and technical capabilities. The integration of new suppliers and modules is facilitated by the modularity of the system. However, these new suppliers and modules usually add uncertainty due to various reasons (e.g., supplier's capabilities to cooperate well with the OEM, technological uncertainty of new modules, and the uncertain compatibility between modules).
These uncertainties due to new supplier and module integration may impact decision making of an OEM on identifying potential suppliers, as attested by several studies. For instance, Janssen et al. (Reference Janssen, Krol, Schielen and Hoekstra2010) assessed the influence of presenting data with or without the uncertainty information on decision making; a statistically significant shift in preferences was observed when uncertainty information was presented. In addition, uncertainty integration was also found important in system architecture generation (Marie-Lise et al., Reference Marie-Lise, Marc, Marija and Jean-Claude2012), which we think should be considered simultaneously with supplier identification, in order to consider possible new technologies to better satisfy new requirements. However, very few methods considered uncertainty while integrating assessment of supplier capabilities in system architecture generation. With the Architecture & Supplier Identification Tool (ASIT), we respond to the need for controlling overall system uncertainty by combining architecture generation and supplier identification.
Section 2 addresses different concepts of modularity as well as approaches that are specifically designed for supplier selection. Section 3 discusses different types of uncertainty, and argues for the need to integrate uncertainty information in early design. The overall ASIT process is presented and discussed. In Section 4, a case study on powertrain design is used to illustrate ASIT. In order to study if the consideration of uncertainty changes choices made in supplier identification, we also compare ASIT with concept selection method (CSM) by King and Sivaloganathan (Reference King and Sivaloganathan1999). CSM is a well-known deterministic approach for concept evaluation that does not consider overall uncertainty. The difference in results of these two approaches is discussed in Section 5. Finally, we provide a discussion of advantages and limits of ASIT and present our conclusions in Sections 6 and 7, respectively.
2. BACKGROUND
2.1. Modularity in complex systems
A complex system is a system with numerous components and interconnections, interactions, or interdependencies that are difficult to describe, understand, predict, manage, design, and/or change (Magee & de Weck, Reference Magee and de Weck2004). Systems and complex systems can be decomposed into different levels of modules, and the number of modules increases as the grain size of modules decreases (Chiriac et al., Reference Chiriac, Hölttä-Otto, Lysy and Suk Suh2011). An example decomposition of a vehicle system is shown in Figure 1 (Van Eikema Hommes, Reference Van Eikema Hommes2008). In this context, a module is defined as a chunk that is tightly coupled within and loosely connected to the rest of the system (Gershenson et al., Reference Gershenson, Prasad and Zhang2003). Normally, different levels of modules are also systems or complex systems themselves. The method proposed in this paper applies for systems and complex systems at any level of their decomposition. For example, the case study illustrates applying the method on a powertrain, which is a complex system and also a first-level module in Figure 1.
Partial decomposition of a vehicle system.
2.2. Modularity in buyer–supplier relations
According to Fixson and Park (Reference Fixson and Park2008), there is a substantial literature stream suggesting that many products are becoming more modular over time. The modularity of products leads to modularity of organizations (Garud et al. Reference Garud, Kumaraswamy and Langlois2009). For example, in their empirical work, Ro et al. (Reference Ro, Liker and Fixson2007) found that the emergence of modularity in product design is changing the structure of the extended enterprises in the American auto industry. The traditional US supplier management model is as shown on the left of Figure 2. According to Ro et al. (Reference Ro, Liker and Fixson2007), in the traditional supplier management model, the parent department (e.g., chassis department) is further divided into more specialized functional departments (e.g., suspension, steering, and braking). Each of the functions is undertaken by an OEM release engineer who manages the first-tier suppliers. In this case, the OEM directly interacts with suppliers.
Influence of modularity on supplier management model. Adapted from “Evolving Models of Supplier Involvement in Design: The Deterioration of the Japanese Model in U.S. Auto,” by Y.K. Ro, J.K. Liker, and S.K. Fixson, Reference Ro, Liker and Fixson2008, IEEE Transactions on Engineering Management 55, 359–377. Copyright 2008 by IEEE. Adapted with permission.
The desired form of the US supplier model is called “the systems integrator model” (Ro et al., Reference Ro, Liker and Fixson2007), which is shown on the right of Figure 2. In this form, a lead supplier manages and coordinates the design and assembly of large-scale modules and systems across a number of other suppliers. In this case, the OEM needs to communicate only with the integrator suppliers; that is to say, the OEM is concerned about the high-level modules (e.g., chassis, powertrain). The integrator suppliers work more independently in this case, and the structure of the extended enterprise is more loose and flexible, implying the formation of a “modular organization.”
The ease of reconfiguration of organizational actors in modular organizations allows “modular innovation,” by which firms improve their products by incorporating improvements in various product modules that may occur at different rates for different modules (Langlois & Robertson, Reference Langlois and Robertson2002). It also allows a firm to select the best supplier for a given module at a given time (Garud & Kumaraswamy, Reference Garud and Kumaraswamy1995). The proposed supplier identification tool in this paper assumes that the context in which the tool is used reflects the above mentioned buyer–supplier relations and that the tool is proposed as a decision support tool for the said context.
2.3. Supplier identification and selection methods
Petersen et al. (Reference Petersen, Handfield and Ragatz2005) demonstrated that “a careful and complete analysis of potential suppliers, leading to the selection of a supplier with the right capabilities and culture to work on the project was positively associated with effective decision making by the project team during the new product development process.” There are hundreds of prior works concerning supplier identification and selection. Most of the supplier selection methods are provided under the traditional product development decision-making process; that is to say, first the product architecture is fixed by the OEM, then a production/manufacturing method is decided. Based on these decisions, suppliers are selected (Nepal et al., Reference Nepal, Monplaisir and Famuyiwa2012). In these methods, product architectures are fixed before supplier selection. The supplier selection is usually based upon financial and managerial criteria such as quality, cost, delivery, and other performances. In early design, however, such data is not necessarily available and is also uncertain. Reviews of supplier selection criteria can be found in works of Ha and Krishnan (Reference Ha and Krishnan2008), Chiu and Okudan (Reference Chiu and Okudan2011), and Ye et al. (Reference Ye, Jankovic and Bocquet2013). The published supplier selection methods under this context are often multicriteria decision-making methods using mathematical, statistical, artificial intelligence, or a combination of these methods. Surveys of these methods can be found in various publications such as by de Boer et al. (Reference de Boer, Labro and Morlacchi2001), Ha and Krishnan (Reference Ha and Krishnan2008), and Chiu and Okudan (Reference Chiu and Okudan2011).
Because of the emergence of modularity, suppliers are more involved in the product design phase. Therefore, companies have started to consider supply chain issues during product development. For example, studies were carried out for matching product development and supply chain design. Ülkü and Schmidt (Reference Ülkü and Schmidt2011) studied the matching between product modularity level and the supply chain configurations, that is to say, the buyer–supplier collaboration level during product design. Pero et al. (Reference Pero, Abdelkafi, Sianesi and Blecker2010) studied how new product development and supply chain variables were related to each other; they found that innovation had a strong effect on supply chain complexity and matching product features with supply chains improved performance. Some methods are also provided to address product development and supply chain issues simultaneously. Lamothe et al. (Reference Lamothe, Hadj-Hamou and Aldanondo2006) proposed a mixed integer linear programming model to help choose product family variants in a way that the operating cost of the supply chain delivering the product is optimized. More specifically, we have found three studies that consider product design and supplier selection conjointly. Zhang et al. (Reference Zhang, Huang and Rungtusanatham2008) developed a mixed integer linear programming model to support product platform design. The main objective was to balance the commonality and variety of the product platform. The suppliers were considered simultaneously with the product platform to reduce cost. Chiu and Okudan (Reference Chiu and Okudan2011) proposed a graph theory based method considering product design and supply design simultaneously. In their work, product functions, assembly issues, and supply chain performance were considered in the early product design stage. The main objective was to optimize product cost and lead time. Nepal et al. (Reference Nepal, Monplaisir and Famuyiwa2012) proposed a fuzzy logic based framework to tackle product design and supply chain design at the same time. Their objective was to minimize the total supply chain costs and maximize total supply chain compatibility. The relevant state of the art in concurrent product and supply chain design is summarized by Gan and Grunow (Reference Gan and Grunow2013).
As can be seen above, among existing studies, Zhang et al. (Reference Zhang, Huang and Rungtusanatham2008), Chiu and Okudan (Reference Chiu and Okudan2011), and Nepal et al. (Reference Nepal, Monplaisir and Famuyiwa2012) addressed product architecture generation and supplier selection simultaneously. All of these consider the cost issue as their main objective. Chiu and Okudan (Reference Chiu and Okudan2011) also considered lead time, and Nepal et al. (Reference Nepal, Monplaisir and Famuyiwa2012) tackled supply chain compatibility issues. However, none of the existing works considered overall uncertainty, which is, in our opinion, an important issue in early design. Because of the frequent high-level innovation integration and uncertainty in early complex system design, we address this gap.
3. PROPOSITION FOR UNCERTAINTY INFORMATION INTEGRATION
3.1. Uncertainty sources in supplier identification
De Weck et al. (Reference de Weck, Eckert and Clarkson2007) defined uncertainty as “an amorphous concept that is used to express both the probability that certain assumptions made during design are incorrect as well as the presence of entirely unknown facts that might have a bearing on the future state of a product or system and its success in the marketplace.” Funtowicz and Ravetz (Reference Funtowicz and Ravetz1993) stated that the uncertainty comprises information about the simplifications made during the translation of a natural system into a model.
Many previous works classified uncertainty for early product and system design (Clarkson & Eckert, Reference Clarkson and Eckert2005; McManus & Hastings, Reference McManus and Hastings2006; de Weck et al., Reference de Weck, Eckert and Clarkson2007). The risk management in early design was also investigated by Van Wie et al. (Reference Van Wie, Grantham, Stone, Barrientos and Tumer2005), Lough et al. (Reference Lough, Stone and Tumer2009), Altabbakh et al. (Reference Altabbakh, Murray, Grantham and Damle2013), and others. In the context of this work, we consider the underlying uncertainty of choosing new suppliers and new modules (possibly using new technologies) during supplier identification.
We identified three sources of uncertainty in using new suppliers and modules: uncertainty related to suppliers’ capabilities to cooperate well with the OEM; the probability that a module can be successfully developed; and the compatibility between the modules. For example, supplier A may be able to provide a module B that potentially satisfies the requirements well. However, in reality, the supplier A may not be able to cooperate well with the OEM, and the module B may not be successfully developed. Moreover, even though the module B is developed, it may not be compatible with other modules. In our opinion, these uncertainties should be considered when reviewing the high satisfaction score of supplier A.
3.2. ASIT
In order to integrate the previously discussed system architecture uncertainties together with supplier capability related uncertainties, we propose ASIT. ASIT is a matrix-based method containing information related to requirements, functions, modules, suppliers, and uncertainties. The main objective is to support decision making of the design team in architecture generation and supplier identification. Figure 3 presents an overview of ASIT, which contains four phases that are automated by a MatLab program.
Overview of the Architecture & Supplier Identification Tool.
Due to uncertainty management, complex systems are rarely designed from scratch. Therefore, project documents regarding the requirements, functions, and modules usually exist; thus, design information is captured and reused. This information capture and reuse is often facilitated through software (e.g., DOORS). However, various types of data are rarely stored in one place. The idea of ASIT is to store critical, high-level data (pertaining not only to functions but also to requirements, modules, and other types of information) on previous projects within a matrix system. The matrix system is composed of a design structure matrix and six domain-mapping matrices, as shown in Figure 4.
The matrix system used in the Architecture & Supplier Identification Tool.
When starting a new project, usually the project manager organizes a 1 to 3 day workshop to discuss innovation integration, different system architectures, as well as other constraints. These workshops are attended by experts of different domains in order to cover overall system knowledge. With the support of the matrix system in ASIT, the experts can choose the adequate existing requirements from the list and, if necessary, add new requirements to it. Based on the requirement–function relations stored in matrix M1, the existing functions related to the defined requirements can be found. This is fundamentally a cognitive phase tackling new and existing requirements, where experts will discuss and allocate them to existing functions or create new functions. The functions, in this context, can be seen as translations of requirements to technical language, describing what the module/system should do from a technical point of view. Experts also discuss module types that are needed based on functions, and relations between new functions and module types. Matrices M1 and M2 can be updated after these discussions. The main difficulty in this phase is the expression of requirements and functions due to various semantic possibilities. Here we assume that designers/engineers are able to define and use a shared language and understanding. Clearly, semantic consistency in reference to functions and other terms is needed.
After the update of matrices M1 and M2, ASIT can automatically point to (calculate) unsatisfied requirements by existing products using matrices M1, M2, and M7. In phase 2, new suppliers and new modules (possibly with new technologies) that can potentially satisfy the unsatisfied requirements are found externally, or proposed by experts, thereby updating matrices M2 and M3. Then ASIT automatically generates all possible architectures based on the function–module relations provided in matrix M2. In phase 3, uncertainty of generated architectures is calculated based on uncertainty of modules, compatibility between modules, and uncertainty of suppliers’ capabilities. The needed information is provided by a group of experts and stored in matrices M4, M5, and M6. The requirements satisfaction by generated architectures is also calculated. Finally, in phase 4, using the uncertainty threshold and the requirements satisfaction threshold defined by the experts, the generated architectures are filtered to identify potential architectures and corresponding suppliers.
As explained above, information stored in the matrix system comes from two sources: information estimated by experts and information from existing products. A group of experts work together to provide expert estimation by using predefined levels (as shown in Figs. 5 and 6). The information on existing products is considered already stored in the matrix system, because after each project, the related data in the matrix system is updated based on project outcomes. The expert estimation contains four types of information: percentages used in matrix M1, representing the level a function fulfills a requirement; satisfaction levels used in matrix M2, representing how well a module satisfies a function; probabilities as defined in Figure 6, describing uncertainties in matrices M4, M5, and M6; and binary information, used to define whether one element belongs to another element (matrices M3 and M7).
Linguistic terms for satisfaction levels (Fiod-Neto & Back, Reference Fiod-Neto and Back1994).
Linguistic terms for probabilities.
The satisfaction levels used in ASIT are defined as “interval scales” (Stevens, Reference Stevens1946), so that operations such as addition, subtraction, and multiplication by a real number are meaningful. Ten levels (1–10) are used for representing satisfaction: “1” is defined as “a very inadequate solution” and “10” is defined as “an ideal solution.” The unit of measurement is 1/10 of the satisfaction difference between “1” and “10.” The descriptive meanings for the satisfaction levels are adapted from Fiod-Neto and Back's parameter value scores (Fiod-Neto & Back, Reference Fiod-Neto and Back1994, pp. 35–45) and are shown in Figure 5. Here “0” is used to represent “the module does not provide the function.” During workshops, experts use the linguistic terms in Figure 5 to provide their estimations, and then the linguistic terms are quantified using 1–10 scale equivalents.
Probabilities are also often provided using linguistic terms by experts (Meyer & Booker, Reference Meyer and Booker2001). Many previous works provided natural language terms associated with probabilities (e.g., Lichtenstein & Robert, Reference Lichtenstein and Robert1967; Moore, Reference Moore1983; Boehm, Reference Boehm, Ghezzi and McDermid1989; Hamm, Reference Hamm1991; Conrow, Reference Conrow2003). However, in these previous works, the proposed probability-related terms were different (Hillson, Reference Hillson2005). Therefore, based on linguistic terms listed in the works of Hillson (Reference Hillson2005) and Halliwell and Shen (Reference Halliwell and Shen2009), we propose a list of linguistic terms as shown in Figure 6. The experts provide their estimations using these linguistic terms for ASIT. In the next section, a powertrain design case is used to illustrate the implementation of ASIT.
4. IMPLEMENTATION
4.1. Case study description
We use the powertrain design for a motor vehicle to demonstrate the utilization of ASIT. Due to innovation integration as well as fuzziness in early design (de Weck et al., Reference de Weck, Eckert and Clarkson2007; Marie-Lise et al., Reference Marie-Lise, Marc, Marija and Jean-Claude2012), a vehicle is usually decomposed into two or three levels of subsystems at this stage. The powertrain is one of the high-level subsystems that can be further decomposed. The main objective in designing a powertrain is to provide adequate propulsion with minimal use of fuel while emitting minimal hazardous by-products or pollutants. For the sake of simplicity, only gas engine and hybrid engine architectures are considered for the powertrain in this case study.
A powertrain is a system of mechanical parts in a vehicle that first provides energy, and then converts it in order to propel the vehicle. In a traditional gas-engine vehicle, the engine provides power converted from other sources of energy. The transmission then takes the power, or output, of the engine and, through specific gear ratios, slows it down and transmits it as torque. Through the driveshaft, the engine's torque is transmitted to the final drive (wheels, continuous track, etc.) of the car. In hybrid electric vehicles, besides the four modules mentioned above, batteries provide electrical energy and electric motors are used to transform electric energy into torque. Therefore, in this study, we consider six types of modules: engine, battery, transmission, electric motor, driveshaft, and final drive.
In general, when considering couplings that exist within a powertrain system as well as new architectures that are emerging due to new technologies (e.g., hybrid and electric vehicles), the powertrain can be considered as a complex system. Michelena and Papalambros (Reference Michelena and Papalambros1995) stated that “in practice, this task is completed incrementally by trial and error and is costly and time consuming.” Further, as a system of variables to be optimized it is overwhelming; Wagner (Reference Wagner1993) showed through tested mathematical models that a powertrain system design can have 87 design relations, 127 variables, and 57 degrees of freedom. However, in this case study, not all subsystems and technologies are considered in order to simplify the explanations.
Because of the increasing demand of lower emissions and higher fuel efficiency, the OEM plans to design a new powertrain for its motor vehicle to better satisfy market needs. The new powertrain needs to satisfy six requirements (the first five are adapted from Michelena & Papalambros, Reference Michelena and Papalambros1995), including: fleet averaged corporate average fuel economy standard (violation of this standard results in proportional fines); acceleration time (this directly relates to customer perceived performance); cruising velocity at gradient (relates to the speed at which vehicle can climb a 6% gradient in forth gear); the 0–60 mph time (this requirement relates to average speed vehicle acceleration over the speed range of the engine); greenhouse gas emissions (this measure shows a vehicle's impact on climate change in terms of the amount of greenhouse gases, e.g., CO2, it emits); and rechargeable by external electric power (this requirement indicates that the OEM would like to develop a plug-in hybrid electric vehicle using rechargeable batteries, the new trend in the market). These requirements can be satisfied by certain functions (e.g., transform energy to torque), and each of the functions is satisfied by one or more modules (Ulrich & Eppinger, Reference Ulrich and Eppinger2000). For the new powertrain development, the OEM expects optimum performance of the system, but at the same time, the uncertainty of system development has to be controlled.
4.2. Phase I: Requirements satisfaction by existing products
For the new powertrain design, a list of requirements is defined by a group of experts. The aim of this phase is to use ASIT to calculate how the OEM's existing powertrains satisfy these requirements and which functions are not satisfied, pointing to the need for new module development.
Existing information is stored in the ASIT matrix system. When starting a new project, the matrices M1 and M2 need to be updated by experts with new requirements and functions. Identification of requirements requires experts to choose appropriate existing requirements, and then add new requirements to the list, if necessary. By using the requirement–function relations in matrix M1, functions that satisfy these requirements are allocated. Experts allocate newly identified requirements to existing functions or add new functions. With new requirements and functions added, the requirement–function relations in matrix M1, and the function satisfaction by modules in matrix M2 are estimated by experts. The updated matrix M1 is shown in Figure 7, where the requirement “rechargeable by external electric power” is a new requirement, and the function “accept recharge” is a new function.
M1: Requirement: Function relations.
The updated matrix M2 is shown in Figure 8, where a new function is added and module types needed are also identified by experts.
M2: Function satisfaction by modules.
After M1 and M2 are updated, ASIT leverages information from M1, M2 and M7 (see Fig. 9) to estimate requirements satisfaction by existing systems. The M7 is an excerpt of the OEM's existing powertrains. In this case study, the OEM successfully developed two types of powertrains in the past (i.e., regular gas engine powertrain and hybrid, as shown in matrix M7 in Fig. 9), which are used as foundations for the new product development. In matrix M7, “1” represents “the module belongs to the architecture” and “0” represents “the module does not belong to the architecture.”
M7: Composition of existing products.
In order to propagate the function satisfaction by modules (Fig. 8) to the function satisfaction by architectures, the composition of the existing powertrains (matrix M7, Fig. 9) is considered. How a system satisfies a function depends on the capability of its relevant modules. When there is only one module in the product that is designed to satisfy a function, the satisfaction level of the function by the product is considered the same as the satisfaction level of the function by the module. When there are multiple modules satisfying the function, the satisfaction level is defined as the average of satisfaction levels of the modules. For example, the gas powertrain has only one module (engine 1) fulfilling the function “provide power.” Therefore, if “engine 1” satisfies the “provide power” function at Level 8, the gas powertrain should also satisfy this function at Level 8, as shown in matrix Mfun-arch in Figure 10. The satisfaction levels here represent “how good a module is with regards to a function” qualitatively. Taking the average of satisfaction levels is a simplification adopted in this work; the weights of modules for satisfying a function can also be considered.
Function satisfaction level of existing products.
In order to propagate the satisfaction of functions to the satisfaction of requirements (by existing products), the requirement–function relations (M1, Fig. 7) are used. Numbers in this matrix represent the percentage that a function satisfies a requirement. The sum of each row of the matrix can be greater or equal to 0 and smaller or equal to 1, because the requirements may be only partly satisfied. For propagating the satisfaction of functions to the satisfaction of requirements, we use the formula:
$$M_{\rm req-arch}=M_{1} \times M_{\rm fun-arch}.$$The requirements satisfaction of the existing powertrains is shown in Figure 11.
Requirement satisfaction of existing products.
We define that Level 5 represents the “satisfactory solution,” and we further define that a requirement is unsatisfied if its satisfaction level is lower than 5 by at least one architecture. Therefore, the requirements “0–60 mph time,” “low greenhouse gas emission,” and “rechargeable by external electric power” are unsatisfied. Using M1 in Figure 7, one can see that the requirement “0–60 mph time” is related to the function “provide power”; the requirement “low greenhouse gas emission” is related to the function “respect environment”; and the requirement “rechargeable by external electric power” is related to the function “accept recharge.” Then, by using M2 in Figure 8, one can see that the satisfaction of these three functions depends on the engine and the battery. Therefore, new engines and batteries that can potentially satisfy these functions need to be identified.
4.3. Phase II: Generating solutions
The objective of this phase is to find/propose potential new solutions for unsatisfied functions by experts, and then use ASIT to generate all possible architectures. After searching for new modules provided either by new or existing suppliers, two new engines and two new batteries are found. Both engines are from new suppliers; one of the new batteries is from a new supplier, while the other one is from an existing supplier of the OEM. The matrix system including M2 (function satisfaction by modules) and M3 (suppliers) is updated by using expert estimations on new modules and suppliers.
The updated function satisfaction by modules is shown in M′2 in Figure 12. It can be seen that the two new engines perform well for functions “respect environment” and “economize fuel” but not as much for “provide power” in comparison to existing modules. The two new batteries perform well in satisfying “provide power” and “accept recharge,” but for other functions they do not show much advantage.
M′2: Function satisfaction by modules (with new modules).
As indicated by experts during Phase 1 when identifying module types, the powertrain of a plug-in hybrid electric vehicle needs an engine, a battery, a transmission, an electric motor, a driveshaft, and a final drive. Therefore, by taking one module from each type of modules mentioned in M′2, all possible architectures are generated (see Fig. 13).
Generated possible architectures.
4.4. Phase III: Evaluating possible architectures
The objective of this phase is to use ASIT to calculate uncertainty and requirements satisfaction of all possible architectures. The calculation of requirements satisfaction is mainly based on M′2, while the uncertainty information is provided by a group of experts and stored in M4 (compatibility between modules), M5 (uncertainty of each module), and M6 (uncertainty of suppliers’ capabilities).
The matrix M4 shows interface compatibilities between modules due to innovation integration. We define that “not compatible” is equal to “0,” “perfectly compatible” is equal to “1,” and a number between 0 and 1 represents the probability that the two modules work well together. Compatibility between modules in existing products is defined as “1,” while other compatibilities are between 0 and 1. M4 is symmetrical, and the elements describing the relations between modules, which satisfy the same function, do not need any interpretation (because they will never be used in the same architecture). The matrix M5 represents the uncertainty of modules. Similar to the definition of compatibility, we define “not mature at all” as “0” and “mature” as “1,” and a number between 0 and 1 represents the probability that the module can be developed successfully by the supplier. Similarly, the matrix M6 represents the probability that a supplier and the OEM can work well together. The matrix M3 represents the relations between modules and suppliers, where the number “1” represents that the supplier provides the module.
Because module uncertainty, supplier uncertainty, and compatibility between modules can all be considered in probabilistic terms, we define the uncertainty of an architecture as the product of all its modules’ uncertainties, its suppliers’ uncertainties, and the compatibilities between the modules, because of the independence of probabilities. The matrices M3, M4, M5, and M6 are shown in Figure 14.
M3, M4, M5, and M6: Uncertainty information.
Done in a similar way as in calculating the requirements satisfaction by existing products, the requirements satisfaction by possible architectures is calculated using the matrix M′2 (in Fig. 12) and the matrix M1 (in Fig. 7). In this case, we assume equal importance of the requirements (this assumption can be changed if needed), and an overall requirements satisfaction score is obtained for each architecture (X) by calculating the average of its requirements satisfaction regarding each requirement (Y), as shown by the equation
$$\eqalign{{\hbox {overall requirement satifaction of}}\;X &={1\over 6}\sum_{Y=1 \ldots6 }\;\cr&\quad\; (\hbox{satisfaction of} \;Y \;{\rm by}\; X).}$$The obtained uncertainties and satisfaction levels are presented in Figure 15. Considering the lack of precision in expert estimation, only two decimal numbers are kept for the results. The “uncertainty” represents the overall uncertainty level of an architecture. The bigger the number, the greater the level of confidence we have for the architecture. The “satisfaction” represents the satisfaction level of the requirements by an architecture. The bigger the number, the better the architecture satisfies the requirements.
Uncertainty and requirements satisfaction of all possible architectures.
4.5. Phase IV: Architecture filtering
The aim of this phase is to use ASIT to filter possible architectures by their uncertainties and the requirement satisfaction levels. The thresholds are provided by experts.
The OEM tends to keep the architectures with the best performance while rejecting highly uncertain architectures in view of the uncertainty related to the project. In this project, the uncertainty threshold is set to 0.02, and the satisfaction threshold is set to 5. Thus, all architectures with uncertainty lower than 0.02 and satisfaction level lower than 5 are rejected. After filtering, 3 out of the 12 generated architectures remain (architectures 6, 7, and 8), as shown in Figure 16, for final consideration.
Uncertainty and satisfaction filtering of possible architectures.
The composition of architectures 6, 7, and 8 can be found in Figure 13, and the suppliers for the modules are recorded in matrix M3 in Figure 14. Because the modules “engine 1,” “battery 1,” and “battery 3” do not belong to any of the three selected architectures, these three modules are deleted from the initial list. With regard to suppliers, only suppliers that are contributing to selected modules are kept for further consideration. That is why supplier 5 is not considered further.
Finally, for battery, transmission, electric motor, driveshaft, and final drive, only one supplier remains; for the engine, three potential suppliers are identified for further negotiation.
5. COMPARISON
There are several possibilities to compare ASIT to others, including the method proposed by Bryant et al. (Reference Bryant, McAdams, Stone, Kurtoglu and Campbell2005), change propagation method proposed by (Clarkson et al., Reference Clarkson, Simons and Eckert2004), and risk management in early design proposed by (Lough et al., Reference Lough, Stone and Tumer2009). However, in order to investigate how consideration of uncertainty changes supplier identification, we choose to compare ASIT to a similar matrix-based method that does not consider uncertainty. The concept selection method (CSM) proposed by King and Sivaloganathan (Reference King and Sivaloganathan1999) is a well-known matrix based approach that ranks different concepts with consideration of function satisfaction. The consideration of function satisfaction is rare in complex system generation approaches, and that is why CSM was chosen for the comparison (see Fig. 17 for the main differences).
Main differences between the concept selection method and the Architecture & Supplier Identification Tool.
The CSM uses two matrices to represent function satisfaction by modules and compatibility between modules, respectively. For each architecture, the summation of function satisfaction and the product of the compatibility score are multiplied, providing an overall score for each architecture. The CSM and ASIT use different scales for inputs. The CSM requires that “the total score for all modules with respect to each function to equal 1.0,” and the compatibility between two modules is represented using a 0–2 scale. In order to allow the comparison, the inputs of the two methods are normalized.
In CSM, overall scores for each architecture are calculated and ranked (see Fig. 18). In ASIT, only the architectures with requirements satisfaction and uncertainty above the thresholds are identified, with a set of suppliers contributing to a given architecture design (Fig. 18).
Comparing results of the concept selection method and the Architecture & Supplier Identification Tool.
One can see on the left side of the table that when compatibility is considered as part of the performance, architecture 2 receives a very high score. This is because this architecture is an existing architecture, and thus the “compatibility performance” is very high. Therefore, when adding the “function satisfaction performance” and the “compatibility performance” together, this architecture receives a good performance score although the “function satisfaction performance” alone is not good enough. We can also see that on the left side of the table, architecture 12 is ranked as the third best architecture. However, it is not among the remaining architectures when considering overall uncertainty, because its uncertainty is lower than the set uncertainty threshold (0.02). Further analysis reveals that the module “battery 3” in architecture 12 is of uncertainty value 0.2, which means that although this module can potentially provide very good performance, its development is estimated to be very uncertain, and the probability that its supplier works well with the OEM is low (0.3). The same situation can be found for other architectures such as architectures 10 and 11. Uncertainty consideration implies that certain potential architectures (5, 9, 10, 11, and 12) are eliminated, resulting in the elimination of supplier 5 providing battery 3 used in architectures 9, 10, 11, and 12. As explained before, battery 3 provides very good performance; however, its uncertainty is very low (In this work, we define “uncertainty = 0” as “not certain at all” and “uncertainty = 1” as “perfectly certain”).
6. DISCUSSION
We have seen that the consideration of overall uncertainty influences the result of potential supplier identification. This is because the suppliers, which are potentially high performing but also highly uncertain, are excluded based on the risk that the OEM is willing to take on for the project. In financial terms, return is always accompanied by risk. High-return options usually also have high risk. That is why return/risk trade-offs are necessary when making financial decisions. Using the corollary in engineering design, the concepts with better performance might also have higher uncertainty. Therefore, we propose to consider both performance and uncertainty when making decisions in architecture generation and potential supplier identification. In addition, we have also seen that when considering performance and uncertainty, the two should be considered separately to prevent mixing up the two different indicators.
As proposed in this work, ASIT can assist OEMs in considering performance and uncertainty when identifying suppliers. The use of matrices as a database form in ASIT provides two main advantages when using this tool in early design of complex systems. First, the usage of matrices is practical because the number of modules is limited, as only the first tier suppliers are considered. The explicit form of matrices makes the relations between elements clear, facilitating comprehension and communication between experts. Second, the storage of two dimension matrices does not require special techniques. This flexibility enables companies to continue using tools that they are familiar with. Standardization in terms of the vocabulary used while describing requirements, functions, and so on, also ensures consistency. The matrices used in ASIT are organized as a matrix system. There are prior works that also use matrix systems, such as the quality unction deployment (Rosenthal, Reference Rosenthal1992), the concept selection method (King & Sivaloganathan, Reference King and Sivaloganathan1999), the architecture generation method (Bryant et al., Reference Bryant, McAdams, Stone, Kurtoglu and Campbell2005), and the multiple-domain design scorecard method (Jankovic et al., Reference Jankovic, Holley and Yannou2012). With the mapping flow of requirement–function–module–supplier–uncertainty, ASIT is the first tool to incorporate supplier and uncertainty information, which allows integrating uncertainty information when considering architecture and supplier simultaneously, and features a “variable” view of the design (i.e., design is not fixed).
However, there are several limitations in this work. First, as an initial step toward introducing uncertainty to supplier identification combined with architecture generation, the sources of uncertainty considered in this work may not be exhaustive. Although the information used is mostly from expert estimation, we have not considered the subjectivity in expert estimation. The sensitivity of ASIT regarding this type of uncertainty should be investigated in future works to verify the robustness of this tool. Second, with specific regard to performance, only requirements satisfaction is considered in this paper. Many other types of performance are also important in the supplier identification (e.g., sustainability, product cost, and lead time). We believe that the feasibility of getting this type of information in the early complex system design stage needs to be considered. Third, the weights of requirements and the importance of modules for satisfying a function (when the function is satisfied by more than one module) are considered to be equal in this paper. It might be fruitful to explore using varying weights. Several studies pointed out the need for investigating the impact of preference aggregation and collaborative expert estimation. We believe that this is an important issue and it should be tested within an industrial setting. The work of Clemen and Winkler (Reference Clemen and Winkler1999) and Keeney (Reference Keeney2009) set a good basis for future research in this aspect. Regarding the validation of the proposed tool, it will be necessary to test the tool in an industrial environment in the future.
7. CONCLUSIONS
Potential supplier identification is the phase of preparing supplier candidates for supplier selection by the OEMs. Because of the use of modular design in complex systems, the suppliers are more and more involved in system design, which makes the technical ability of suppliers more important to better satisfy system requirements. However, using novel architectures and suppliers with potentially better performance often comes with higher uncertainty as well.
We proposed ASIT, which uses both requirement satisfaction and uncertainty thresholds to filter possible architectures and suppliers. The uncertainty related to suppliers’ capabilities to cooperate well with the OEM, the technological uncertainty in new modules, and the uncertainty of compatibility between modules are considered. To the best of our knowledge, ASIT is the first supplier identification tool that combines architecture generation with control of the overall uncertainty. By comparing to a method that does not consider uncertainty using a case study of powertrain design, it is shown that considering uncertainty impacts the result of the supplier identification, and that uncertainty should be considered independently from the performance.
Suppliers with potentially high performance may also have high uncertainty. The utilization of ASIT in supplier identification has the potential in balancing risk and return for the OEM while identifying optimal suppliers.
Yun Ye is currently a PhD student in the Laboratory of Industrial Engineering at Ecole Centrale Paris. She accomplished her Ingénieur généraliste degree at Ecole Centrale de Pékin and Ecole Centrale Paris, and she has mechanical and computational science backgrounds from her master and bachelor studies. Her research focuses on the early supplier and architecture identification phase of complex system design.
Marija Jankovic is an Associate Professor in industrial engineering at Ecole Centrale Paris and a Deputy Director for Master Studies in Engineering Design and Management. She received her BS degree in 2001 from the Faculty of Organizational Sciences at the University of Belgrade and her MS degree in industrial engineering from Ecole Centrale Paris in 2002. The majority of her research projects are done in collaboration with industry or government, and with direct implementation and verification of research results. Dr. Jankovic collaborates with major French and international companies, such as Snecma, Thales, EADS, PSA Peugeot Citroen, and Schlumberger.
Gül E. Kremer currently serves as a Program Director for the US National Science Foundation. She previously served as a Professor in the School of Engineering Design and Department of Industrial & Manufacturing Engineering at Pennsylvania State University. She was also a Fulbright Scholar to Ireland. Dr. Kremer received her PhD in engineering management and systems engineering from the University of Missouri–Rolla and her MBA in production management from Istanbul University. She received her MS and BS in industrial engineering from Yildiz Technical University, Istanbul.
Jean-Claude Bocquet is a Professor and the Director of the Laboratory of Industrial Engineering at Ecole Centrale Paris. He also serves as Director of Educational Enterprise Sciences, Vice Chairman of the Board of Directors of Ecole Centrale Paris, and Chairman of the Board of Directors CEESAR (European Center for Security Studies and Risk Analysis). He serves as an expert at the Ministry of Research for research evaluation in industrial engineering for AERES and an expert for the ANR. Dr. Bocquet received his master's in mechanics and his PhD in mechanical computer-assisted design and artificial intelligence at ENS de Cachan, France.
