Incorporating design outsourcing decisions within ... - Semantic Scholar

Computers in Industry 60 (2009) 392–402

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

Incorporating design outsourcing decisions within the design of collaborative design processes Mervyn Fathianathan a,*, Jitesh H. Panchal b,1 a b

Biomers Pte Ltd., 18 Boon Lay Way, 18@TradeHub21, #5-99, Singapore 609966, Singapore School of Mechanical and Materials Engineering, Washington State University, Pullman, WA 99163, USA

A R T I C L E I N F O

A B S T R A C T

Article history:

The product design process plays a central role in ensuring that new products are realized with improved quality, in a short lead-time and with costs kept to a minimum. Designing the design process is an essential ingredient to ensure sustained competitiveness of a company. The collaborative nature of today’s product development environment complicates the design of design processes. In this paper, it is proposed that design outsourcing and collaboration decisions should form a critical component of modeling and synthesizing collaborative design processes. An approach to modeling collaborative design processes is proposed based on the use of design nodes. The approach allows an ongoing design process to be modeled facilitating dynamic decision making on how the design process should progress accounting for the state of the design problem, design process factors, collaboration and design outsourcing factors. ß 2009 Elsevier B.V. All rights reserved.

Available online 18 March 2009 Keywords: Design process modeling Design outsourcing Collaborative design processes

1. Introduction The design and development of successful new products is imperative to the economic well-being of a company. Intense global competition is forcing companies to design and develop new products not only with improved quality, but also as rapidly as possible and keeping costs to a minimum. In this competitive environment, the product realization process is of central importance. The process that a company adopts to realize new products and how they manage this process plays a critical role in its success. Simon [1] points out that ‘‘. . . design process strategies can affect not only the efficiency with which resources for designing are used, but also the nature of final design as well’’. Appropriately structured design processes can improve not only the performance of a single product but also the evolution of the entire product line. Hence, the design of design-processes is an essential ingredient for the strategic development of products to ensure sustained competitiveness of a company. The design of design processes involves the systematic analysis and synthesis of the process that a company adopts to design a product. Systematic analysis and synthesis of design processes is necessary due to the complexity of design processes. Design

* Corresponding author. Tel.: +65 6779 5909; fax: +65 6779 5909x966. E-mail addresses: [email protected] (M. Fathianathan), [email protected] (J.H. Panchal). 1 Tel.: +1 509 335 8491. 0166-3615/$ – see front matter ß 2009 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2009.02.010

processes are often complex due to the inherent complexity of the product itself. Interactions and iterations between various activities and stakeholders add to the complexity of product realization processes. Whitney [2] highlights that the complexity of mechanical designs results from the multifunctional nature of the parts required to obtain efficient designs. The underlying design processes involve many organizational units and engineering disciplines and the level of human intervention comprises an additional barrier to process modeling. Modeling of design processes is also complex because these cannot be completely described a priori. Downstream activities are significantly dependent on the information generated by upstream activities and the associated level of uncertainty is consistently high. Designing design processes is further complicated today because product design and development is largely a collaborative effort among various geographically distributed companies. This organization of geographically distributed companies working together to realize a product is known as the extended enterprise and is the new unit of business competition [3]. This implies that the extended enterprise is only as strong as its weakest member. In addition, companies are not only outsourcing manufacturing activities to other companies, but also increasingly outsourcing design activities to partnering companies [4]. Design outsourcing decisions play a critical role in the quality, cost and lead-time of a product and hence, should form a critical component of designing a design process. There is therefore a need to develop methods for integrating design outsourcing decisions within a design process.

M. Fathianathan, J.H. Panchal / Computers in Industry 60 (2009) 392–402

Fig. 1. Creating collaborations as design process proceeds.

Companies face a number of design outsourcing decisions in the process of designing a product. These include at which point of the design process should the company involve a partner, how much control of design decisions should they give to a partner, which partner or partners should they work with and what kinds of interactions should they have with their partners. These decisions have to be made accounting for various factors including design problem requirements, partner capabilities, prior relationships with partners, etc. In this paper, we present an approach for incorporating design outsourcing decisions within the design of a collaborative design process. We present a design process modeling approach [5,6] and how design outsourcing decisions can be integrated into the process model for the design of collaborative design processes. Our frame of reference is a company that needs to decide on design outsourcing as the design process proceeds. As depicted in Fig. 1, a company creates relationships with collaborating partners as the design process proceeds. There is a plethora of challenges related to collaboration in product development [7] including: (a) development of standards for information representation [8,9], (b) communication between heterogeneous resources [10], (c) seamless flow of information between humans and computers, (d) methods for efficient collaboration between designers [11], (e) strategies for conflict resolution, (f) development of collaborative IT frameworks [12], etc. However, due to the extensive scope of this topic, and to limit the scope of this paper, we focus on integration of design outsourcing decisions within the design of the collaborative design processes. The role that the work presented in the current paper plays in integrated computational environments for collaborative design is that it provides a means of modeling and synthesizing collaborative design processes dynamically, thus providing a means to define the flow of tasks and hence, information between collaborating partners. In [13], the authors refer to this as asynchronous co-design process management. The rest of this paper is organized as follows. Section 2 presents the related research in collaborative design processes. Section 3 discusses the approach to modeling design processes using design nodes. Section 4 discusses the design of collaborative design processes and how design outsourcing decisions can be incorporated into the design process. Section 5 presents a case study and Section 6 concludes the paper. 2. Related research According to Panchal et al. [14,15], the design of design processes ‘constitutes a fundamental prerequisite for the strategic deployment of products and the effective consideration of their

393

respective lifecycles’. The authors highlight three key aspects for designing design processes: (a) systematic approaches for modeling and representation of design processes that support their design, (b) analysis of design processes from the standpoint of comparing different process options, and (c) synthesizing new design processes using existing knowledge. Although the authors provide a framework for research in designing design processes, they do not present specific design process models or methods to support designers in making specific design process related decisions. Bras and Mistree [16] present a decision based design process modeling approach for designing design processes. However in both these efforts, collaboration in design processes has not been addressed. Further, specific decisions such as ‘when to involve a partner in the product realization processes,’ and ‘which partners to collaborate with’ are not addressed in the existing literature on designing design processes. Significant research has been carried out on modeling and managing collaborative design processes [17–21]. Some efforts are focused on making collaborative decisions [22,23], while other efforts such as the use of game theory for collaboration are focused on developing effective collaboration strategies [24–28]. However, the research has been limited to strategies for efficiently executing collaborative design processes after the decision to collaborate with specific partners has been made. Related to the collaborative design processes is the partner selection problem. The partner selection problem has been widely addressed in the agile manufacturing [29,30] and supply chain literature [31]. For example, Gupta and Nagi [32] present an optimization framework for selecting best partners and their sequence in a virtual enterprise. The authors present a set of attributes based on which the partner selection decision is based. These attributes are categorized into quality, price, delivery, production capabilities, management, and service. Some of the attributes such as quality, price and cycle time are quantitative, whereas others such as past-performance, service, and organizational structure are qualitative. In order to combine both the quantitative information and fuzzy qualitative information into a common optimization framework, Gupta and Nagi present a flexible optimization framework based on fuzzy logic and analytical hierarchy process (AHP). Wu et al. [33] present an interval programming formulation for selecting partners at multiple sites in an agile virtual enterprise, while accounting for the precedence relationship between tasks and minimizing the overall manufacturing cost. The interval programming formulation is transformed into a graph–theoretical problem that can be solved using a polynomial bounded algorithm. Choi and Hartley [34] consider the impact of a company’s position in the supply chain on the partner selection decisions. Using a survey of various companies in the auto industry, they evaluate the differences between selection criteria for different levels in the supply chain. Their evaluation is based on the following eight factors: finances, consistency, relationship, flexibility, technological capability, customer service, reliability, and price. The authors statistically show that some of the decision criteria for auto assemblers, direct suppliers and indirect suppliers are similar, whereas some of the criteria such as technological capability and financial issues are different. Sha and Che [35] present a multiphase mathematical approach for solving the partner selection problem in supply chain networks. The approach is based on genetic algorithms (GA), analytical hierarchy process (AHP), and the multi-attribute utility theory (MAUT). Hong-Yi [36] presents an interval programming model for partner selection while accounting for cost, time, and risk. The emphasis is on minimizing the risk on the overall project objectives. The risk parameters are expressed as intervals in the nonlinear programming formulation. The resulting nonlinear

394


interval programming model is solved using genetic algorithms. Huang et al. [37] present an approach to selection of the type of supply chain for optimal performance. The authors classify manufacturing supply chains into lean, agile, and hybrid supply chains. The approach presented by the authors for selecting the type of supply chain is based on the characteristics of the product. Hacklin and Marxt [38] present a tool for partner selection that allows decision-makers to evaluate different firms autonomously. The tool helps in developing profiles for the firms, which can be used by the decision-makers as a basis for partner selection discussion. In general, the partner selection problem is a subset of a supply chain design problem. Beamon [31] provides a broad overview of the literature on supply chain analysis and design. The author categorizes the literature based on four different types of models for supply chains: (a) deterministic analytical models, (b) stochastic analytical models, (c) economic models, and (d) simulation models. Most of the models used for the manufacturing partner selection problem are deterministic analytical models. Although Gupta and Nagi [32] address the subjectivity in selection, they do not account for uncertainties in the agile enterprise. This is particularly important because the partner attributes are subject to change, and the dynamic nature of an agile enterprise may render an optimal partner network into a suboptimal one, in a short period of time. The main emphasis in the existing efforts in partner selection are on (a) using a comprehensive set of attributes for making the partner selection decision and (b) developing a comprehensive yet tractable optimization approach for the complex partner selection problem. Duffy [39] discusses the latest trends in evaluation criteria for partner selection. The author highlights that emphasis is now being placed on developing long-term innovative relationships rather than short-term product based partnerships. Hence, aspects such as supplier’s market share, strategic plan, and investment in research are becoming important criteria for partner selection decisions. In summary, much of the research in designing design processes has not considered collaboration decisions within the design process. The research conducted on collaborative design processes focuses on managing the collaboration after partners are selected. The existing literature on partner selection focuses on the manufacturing of the product after the design has been frozen. Partner selection has not been sufficiently considered during the product design process. In this paper, we fill this research gap by proposing an approach for incorporating partner selection and design outsourcing decisions in general within the design process. Our assertion is that if the partner selection is considered while making major product decisions, product design and manufacturing enterprises can not only make informed decisions, but also reduce the development costs. The integrated nature of the product decisions and the partner selection decisions presents an opportunity for improving the design process, which has not been explored in the literature. Having discussed the existing literature, we discuss a design process modeling approach, which is utilized to support the design of collaborative design processes. The approach is presented next. 3. Design process modeling using design nodes Designing design processes necessitates developing models of the design process to facilitate systematic analysis and decision making on how the design process should proceed. This section presents an approach to modeling design processes based on the use of design nodes [5]. It is proposed that a design node is a juncture in a design process where it is determined how the design process should proceed, while accounting for the structure of the design problem and design process alternatives. Although a number of design process modeling approaches have been

Fig. 2. Design problem definition.

proposed in the literature, existing efforts are mainly suitable for improving existing design processes and provide little guidance to designers for defining an ongoing design process. A salient feature of the design node approach to modeling design processes is that it allows an ongoing design process to be modeled, facilitating dynamic decision making on how the design process should progress accounting for the state of the design problem. The approach also captures top-down and bottom-up design approaches. Constructs for modeling design processes, design nodes and modeling of design processes using design nodes are discussed in this section. 3.1. Design process constructs The design nodes approach to modeling design processes adopts the view that actions of designers or design teams are dynamic and based on the current state of solving the design problem. Based on this view, constructs for modeling design processes should capture the design problem being solved and the possible actions that designers take in solving the problem. Two sets of constructs are therefore proposed in modeling design processes—design problem constructs and design tasks constructs. We define a design problem as shown in Fig. 2, the satisfaction of design requirements (DR1, DR2,. . .) through the definition of design parameters (DP1, DP2,. . .), the values of which are selected among various alternatives (A11, A12, A21, A22,. . .) utilizing knowledge sources (K1, K2,. . .). From this definition, four elements can be defined as constructs of a design problem: design requirements, design parameters, alternatives and knowledge. The definitions of terms design requirements, parameters, and alternatives are based on the approach presented by Suh [40]. Design tasks are actions that designers take to solve the design problem. Seven different actions are defined that designers take in solving a design problem: identification of design requirements, decomposition of design requirements, identification of design parameters, decomposition of design parameters, generation of alternatives, analysis of alternatives and decision/selection. The design problem and design tasks constructs present a generic approach to model design processes. The constructs for modeling the design process are illustrated in Fig. 3. 3.2. Design nodes A design node embodies the design problem and design tasks constructs and thus, presents an approach to integrate design problem and design process factors. Design nodes are therefore, higher level constructs that are used to define a design process. Each design node presents a sub-problem of the overall design problem. Fig. 4 depicts a general design node. A general design node can be instantiated to include the design tasks constructs and thus, will reveal how the design problem is to be solved. An approach for modeling a design process requires capturing both the decision making, and the exploration and learning aspects of design. We identify that design nodes can be instantiated in two main ways. These design nodes are referred to as a top-down design decomposition node and a bottom-up design evolution node.


Fig. 3. Design constructs for modeling design processes.

395

design solution. In contrast to the top-down approach, the bottom-up approach does not involve transitioning from an abstract level to a detailed level. The bottom-up design process involves utilizing detailed solutions to identify the values for design parameters. The bottom-up design process is often characterized by an iterative ‘generate-and-evaluate’ process. An initial set of detailed solutions are generated and evaluated to determine the appropriateness of the solutions. Depending on the appropriateness of the solutions, new detailed solutions are generated to satisfy the design requirements. In generating and testing complete solutions, knowledge is generated on the appropriateness of a solution as well as on the relationships between the various sub-parameters that constitute the solution. The generated knowledge could be used for solving future design problems. A design problem that could not be solved through a top-down approach could in the future be solved using the knowledge generated in previous bottom-up attempts. The bottom-up design evolution node is characterized through the following: (i) the parameter in consideration, (ii) a set of solutions that could possibly satisfy the requirements, (iii) the information or knowledge that is available to evaluate solutions, (iv) the information or knowledge that is generated through the bottom-up process and (v) iterative generation of solutions to determine the design parameter value. 3.3. Design node approach to modeling design processes

Fig. 5. Top-down decomposition node.

The approach to modeling design processes using design nodes is shown in Fig. 7. Using the design node approach, a design process is modeled by defining a design node (i.e. defining the design problem) and instantiating the design node (i.e. defining how the design problem will be solved through the design tasks). As the design process progresses, design nodes are decomposed into subdesign nodes, each with its own instantiation. Fig. 8 shows how the approach is carried out. It depicts a design process where a design node at level i (Design Node1) is defined by the need to satisfy requirements R1 and R2 through a design parameter DP1. Design Node1 is instantiated as a top-down design decomposition node. In the top-down design decomposition node, a decision is made to select one or more values for the design parameter in consideration. The chosen value or values are then decomposed in the next level of the hierarchy into sub-design nodes. In Fig. 8, this is depicted as Design Node11 with the need to satisfy requirements R11 and R21 and Design Node12 with the need to satisfy requirements R12 and R22. At a point in the progression of the design process, the design problem cannot or should not be decomposed further. In that situation, a design node is instantiated as a bottom-up design evolution node. In Fig. 9, Design Node12 is instantiated as a bottom-up design evolution node. As design evolution involves generating and testing a set of solutions for the design parameter, each new set of solutions being generated and tested is defined as a separate bottom-up design evolution node. The iterative process is carried out till an appropriate solution is found to satisfy the design requirements. One of the salient features of dynamically modeling the design process considering both design tasks and the design problem is that

Fig. 6. Bottom-up design evolution node.

Fig. 7. Design process modeling approach based on design nodes.

Fig. 4. A general design node.

The top-down design decomposition node is shown in Fig. 5. It defines the design problem and the tasks undertaken to decompose the design problem. In the top-down design process, a transition is made from abstract levels to detailed levels. Each level transition involves a greater amount of detail. To transition to the next level, decisions are made on the value of the design parameter. Based on this value of the design parameter, the design problem is decomposed into sub-problems. A top-down design decomposition node is characterized through the following: (i) the parameter in consideration, (ii) the requirements that the parameter is to satisfy, (iii) the alternatives for the possible value that the parameter could take, (iv) the information or knowledge that is available to make the decision, and (v) the decided upon value for the parameter. The bottom-up design evolution node is shown in Fig. 6. It defines the design problem and the design tasks undertaken to evolve the

396


Fig. 8. Application of design nodes at different levels of a design process.

Fig. 9. Design process modeled using top-down and bottom-up nodes.


it allows one to make informed decisions on how the design process should proceed. Various design principles can be implemented to decide on how the design process should progress. For example, Suh [40] advocates maintaining the functional independence of requirements. Therefore, if a design problem is decomposed into subproblems, each sub-design problem should be characterized by functionally independent requirements. Finally, the design node view of the design process can be expanded to reveal a design task view as shown in Fig. 9. In this figure, both the top-down and bottom-up aspects of a design process are shown. The design parameters are shown as triangles, alternatives as rectangles, and the values of design parameters as ovals. The steps in the top-down process include generation of alternative concepts (A11, A12, A13, etc.) for satisfying a set of design parameters (DP1), evaluation of alternatives, selection of an alternative, and identification of next level design parameters (DP11, DP12). The bottom-up design process is shown as an evolution of design alternatives (A121, A122, A123, etc.) to satisfy a design parameter (DP12). Having discussed the design nodes approach to design process modeling, we discuss how this approach can be used to design collaborations in a design process in the next section. 4. Designing collaborations within the design process This section discusses how design outsourcing decisions can be incorporated into the design of design processes using design nodes. Section 4.1 discusses how design nodes are used in designing design processes and Section 4.2 discusses the incorporation of design outsourcing decisions in the design process. 4.1. Design process design using design nodes The design problem being solved and the design of the design process to solve the design problem are naturally related. The interplay between product design and design process design are shown in Fig. 10. Once a design problem has been defined as shown in the top left of the figure, there is a shift to the design of the design process. Just as there are different levels of abstraction in defining design parameters, there are also levels of abstraction in design process design parameters. As seen in the figure, the first level of abstraction is the overall approach to solving the design problem. In the design node approach to design process design, this involves making a decision on how the design node is to be instantiated, either in a top-down design decomposition manner

397

or in a bottom-up design evolution manner. Determining how the design node is to be instantiated provides an overall idea of how the design process is to proceed. The design process design then shifts to the next level of detail where the specific design methods to be utilized are determined as well as the sequence of the design methods. In this paper, we focus on the first level of abstraction (i.e. deciding how a design node is to be instantiated). Should a design node be instantiated as a top-down design decomposition node or a bottom-up design evolution node? A number of factors need to be considered in determining how a design node is to be instantiated. For example, is there sufficient knowledge or information to make a decision and decompose the problem to the next level of the hierarchy? A design parameter at the higher levels of the hierarchy could possibly be decomposed into multiple design parameters, each considered as a separate problem. However, to decompose the problem and identify requirements for the sub-problem necessitates knowing the relationships between the component sub-problems. When designers do not have knowledge of the relationships, they adopt a bottom-up design evolution approach which results in knowledge generated about the relationships. Another reason for adopting a bottom-up approach could be in dealing with highly complex design problems where the overall design problem is comprised of a large number of interdependent design problems. A large number of interdependent design parameters are difficult to deal with. Several have discussed the failure of large-scale projects as a result of being unable to anticipate the effect of changes when a large number of interdependent design parameters are present [41,42]. Bar-Yam [42] recently proposed that in such situations a bottom-up evolutionary approach could be more appropriate. As evident from the above discussion, various factors need to be considered in deciding between instantiating a design node as a top-down design decomposition or bottom-up design evolution node. Efforts are currently underway to arrive at a comprehensive list of factors that need to be considered in the design node instantiation decision. 4.2. Incorporating design outsourcing decisions within the design process In a product development process, the collaboration can take place at various stages starting from the planning and requirements gathering phase to the eventual product retirement. For

Fig. 10. Design process design using design nodes.

398


example, a company may collaborate with partners to clarify the design problem and develop a realistic product proposal or in the later phases with outsourcing of manufacturing. Two of the most common types of collaborations that are made during the product development are component outsourcing and design outsourcing [4]. The primary difference between component outsourcing and design outsourcing is that the former involves utilizing off-the-self products of the partners whereas the latter involves providing the partner control of a part of the design. In the case of component outsourcing, the design alternatives are already available and the decision involves selecting the appropriate design alternative. The decision is based on the attributes for various alternatives and other factors such as cost from different partners. Hence, the collaboration is mainly driven by the existing design. However, in the case of design outsourcing, the design alternatives are not available at the time of deciding which partners to collaborate with. The decision about selecting partners is more difficult. The factors affecting the decision include a broad set of attributes such as expertise of the potential partners, past reputation, potential for long term collaboration, compatibility, etc. The primary collaboration related decisions made by the company are: (a) When should a company involve partners in the design process? (b) Whom should a company select as a partner and how many partners should be involved in the product development process? (c) How much control should be given to a partner on design decisions? (d) What should the collaboration strategy be? Specifically, What kind of interactions should the company have with the partners?

When should the design information be shared between the partners? Various aspects (objectives, alternatives, and knowledge) associated with these decisions are listed in Table 1. In this table, our objective is not to provide a comprehensive list of the factors in these decisions. The objective is to provide an overview of the types of factors considered in the design collaboration decisions. This is primarily because the factors depend on the particular design problem at hand. Note that objectives involve product requirements also, indicating the coupling between the design process decisions and the product decisions. As discussed in the preceding section, once a design problem has been defined, there is a shift to the design of the design process where a decision is made on the approach of solving the design problem (i.e. how the design node is to be instantiated). In a collaborative environment, this decision on how the design process should proceed should account for the above identified collaboration related decisions. Fig. 11 shows a framework, in the form of a flowchart, for incorporating design outsourcing decisions within the design of the design process. In the approach depicted in Fig. 11, prior to making a decision on the approach of solving the design problem, a decision is made on whether to involve a partner at that stage or not. This decision is often dependent upon the company’s capability and knowledge. For example, upon identifying the design problem, a company could deem that it does not have the knowledge or capability to solve the design problem and hence, would require a partner to collaborate with. Another example could be the case where the company has the knowledge and capability to solve the design problem, but deems that the design problem could be solved by another company in a faster time. The decision to involve a partner therefore involves tradeoffs between cost and benefits in involving

Table 1 Aspects involved in making design collaboration decisions. (a) When should a company involve partners in the design process?

(b) Whom should a company select as a partner?

Objectives Minimum cost, design time, risk Satisfy product specifications Ability to satisfy future needs

Objectives Minimum cost, design time, risk Ability to satisfy current product requirements Capabilities for future collaboration Low potential communication barriers

Alternatives Designing within the company Outsourcing the design task

Alternatives Different possible design collaborators

Knowledge Impact of involving partners in the design process in terms of cost, design time Impact of design interdependencies Performance of individual partners on previous similar projects Potential benefits from developing knowledge by designing in-house

Knowledge Past success of partner companies Strategies for future expansion of partner companies Cost, reliability, quality Potential for future collaboration

(c) How much control should be given to a partner on design decisions?

(d) What should the collaboration strategy be?

Objectives Minimum cost, design time, iterations Maximum control of the design and the design process Maximum knowledge

Objectives Minimization of cost, design time, iterations Minimization of lead-time due to information exchange

Alternatives Provision of full control of an aspect of the design to a partner Provision of little control, where decisions made by the partners must be approved by the organization

Alternatives Independent design of the components by the partners Provision of a well-defined problem to the partners and all constraints involved in the design. Interactions at well-defined process gates Frequent interactions with the collaborators during the design making for continuous exchange of overall product information

No control, the organization only receives recommendations from the partners; decisions are made by the design organization

Knowledge Partner’s abilities and experience Past success

Knowledge Coupling between product design parameters, and inter-related decisions Partner’s work environment and culture


399

Fig. 11. Incorporating collaboration factors in design process design.

a partner. If a decision is made not to involve a partner, then the design node can be instantiated without considering any collaboration related factors. The factors involved in the decision to involve a partner are listed in the top-left corner of Table 1. If a decision is made to involve a partner in the design of a product, the next stage in the flowchart deals with the level of control to be given to the partnering company. The next stage involves a decision on whether or not to outsource the design problem entirely to a partner. This decision depends on the level of confidence in the partner that the collaboration will result in a successful design execution, i.e., the uncertainty in the design process is low. If a decision is made to outsource the design problem entirely to a partner, the company provides the requirements to the partnering company. As the company outsources the design problem entirely to a partner, there is no need for the company to instantiate the design node as it. The elements of the design node, with the exception of the final design parameter values, are therefore transparent to the company. The factors involved in deciding to outsource the design problem entirely to a partner are depicted in the bottom-left of Table 1. In outsourcing the design problem, the company also has to decide on an appropriate partner. The partner selection factors are shown in the top-right of Table 1. If a decision is not made to outsource the design problem entirely to a partner, then the company needs to make a decision on how the design node is to be instantiated. However, the difference in this case is that the decision will depend not only on the nature of the design problem and design process factors such as efficiency, but also on collaboration factors. In this case, the decision is more complex and involves the top-right, and two bottom sections of Table 1. If a company adopts a top-down design approach, it typically sends out a request-for-proposal where concepts are submitted to the company and the company works collaboratively with a selected company in solving the design problem. This often implies that a company selects one partner to work with and the decision is made under greater uncertainty. Alternatively, a company could adopt a bottom-up approach to design where multiple detailed solutions are solicited from possible partnering companies and evolved iteratively towards solving the design problem. In this approach, the decision on partner selection is delayed till more concrete information is available. However, this is not always possible as partnering companies might impose restrictions on a company in terms of exclusive collaborations. It is evident from this section that collaboration decisions greatly influence and even impose restrictions on design process decisions. Work is currently underway for extending the framework articulated in this section to incorporate multi-objective decision making considering all these aspects in designing design processes.

incorporation of design outsourcing decisions within the design of the design process. The design node approach was used to model the design process of a company in the process of designing a new product. The actual names of the companies involved in the case study are withheld as the product is yet to be released in the market. In this case study, Company X has been asked to develop a Ushaped rod that is to be part of a device. The rod should be durable, translucent to allow light to pass through and it should be adjustable to allow the curved portion of the rod to maintain contact with other parts of the device. With these requirements, the company identified the design parameters as material of the rod (DP1) and method of adjusting curved portion of the rod (DP2). The engineering team generated a number of alternative concepts for the material of the rod and the method of adjusting the curved portion of the rod. It should be noted that the design parameters are inter-related in this example. For example, the type of material would determine if heat could be applied to adjust the geometry of the rod. The design problem is depicted as a design node in Fig. 12. The design parameters at this point are only defined at an abstract level. As the design process proceeds, the design parameters are defined in more detailed levels. With the available knowledge, the engineering team decided to instantiate the design node as a topdown design decomposition node. This implies a level of confidence in the team that with the current knowledge, a concept can be chosen and be decomposed to sub-design problems. Fig. 13 shows the design node instantiated as a top-down design decomposition node. In this case, the engineering team has decided to adopt a rod that is made up of two materials, a metal portion that will allow easy adjustment and a polymer composite portion that will be translucent. This was decided upon after determining that light only needs to pass through certain parts of the rod. Once the concept is selected, the design team proceeds to decompose the problem into two sub-problems, one for the design of the metal portion and one for the design of the polymer composite portion. The design node decomposition is shown in Fig. 14. The requirements for the metal portion are durability,

5. Case study In this section, we present a case study to illustrate how design nodes are utilized in the design of design processes and the

Fig. 12. Case study Design Node1.

400


Fig. 13. Instantiated case study Design Node1.

ability to adjust length of the metal portion and provide a strong connection to the polymer composite end. At this point, in relation to the flowchart in Fig. 11, the company needs to decide if it should involve a partner and if so, should it outsource the design completely and to whom. The various factors of Table 1 are incorporated into a single decision as shown in Fig. 15. In this case, it was decided that Company X will outsource the design node completely to Partner A. The requirements for the polymer composite portion are translucency, durability and a strong connection with the metal portion. With its expertise in polymer composite fabrication, Company X decides to develop the polymer composite portion using its proprietary fabrication method. It identifies three design parameters: polymer matrix, reinforcement and the diameter of the rod. As the company does not have expertise in polymer synthesis, it decides to collaborate with another company to provide them with a polymer matrix. Company X has the option of collaborating with a number of different companies to provide them with a polymer matrix. Further, Company X could either use an off-the-shelve polymer matrix from one of these companies or work with these companies to custom-synthesize a polymer matrix. Custom synthesis of a polymer matrix by a partnering company can be viewed as a co-design effort. Company X also needs to identify a supplier for the fiber reinforcement from an array of potential suppliers who offer different grades of fibers. One approach to solving the polymer composite design problem would have been to decompose the design problem into subproblems by identifying the requirements for each of the design parameters. This would mean that specific requirements would be identified for the polymer matrix, the reinforcement and the diameter of the rod. In that case, each design parameter could have been treated separately and values identified independently. However, these design parameters are interdependent. The

Fig. 15. Collaboration decision for Design Node11.

polymer matrix used, the properties of the fiber, and the structure of the fiber used in the composite and the diameter of the rod have a direct influence on the properties of the composite. The alternative approach to designing the polymer composite portion of the rod that Company X could adopt is a bottom-up design evolution approach. In a bottom-up design evolution approach, the rationale would be to quickly evaluate different alternatives, learn from the performance of these alternatives and accordingly change the values of the design parameters to arrive at a satisfactory solution. The various alternatives of how the design process could proceed are shown in Fig. 16. Company X has the options of collaborating with five companies with different variants of fibers, four polymer matrix companies, two with offthe-shelve products and another two with the ability to custom

Fig. 16. Collaboration decision for Design Node12.

Fig. 14. Decomposition of Design Node1.


401

Fig. 17. Bottom-up design evolution of Design Node12.

synthesize polymers. It should be noted that although assessing the potential of all possibilities might improve the design quality, this would result in a large design space, leading to increased product lead-time and cost. In this case, it was decided that Company X will adopt a bottom-up design evolution approach working with two fiber companies and one polymer matrix company capable of synthesizing custom polymers. It should be noted that each stage of the design evolution can be represented as a separate design node. This is depicted in Fig. 17. It is also to be noted that the design node for the metal portion of the rod in Fig. 14 is left uninstantiated as this node is solved by a partnering company. From this case study, it can be seen that decisions on how the design process should proceed accounting for collaboration factors are not trivial and require systematic analysis and decision making. 6. Conclusions In this paper, it was identified that design outsourcing and collaboration decisions constitute a critical component of designing a design process. A flexible and general approach to modeling design processes based on the use of design nodes was presented. The design node approach to modeling design processes allows an ongoing design process to be modeled allowing dynamic decision making on how the design process should proceed. It also captures the nature of the design problem and the tasks to solve the design problem. The design node approach to modeling design processes was extended to incorporate design outsourcing and collaboration factors to allow designing a collaborative design process. Various collaborationrelated decisions were identified and a framework was proposed to incorporate the collaboration decisions into the design process. Future work will look into developing methods for effectively making these complicated decisions on how the design process should proceed accounting for design problem, design process and collaboration factors. References [1] H.A. Simon, The Sciences of the Artificial, The MIT Press, Cambridge, MA, 1996. [2] D.E. Whitney, Why mechanical design cannot be like VLSI design, Research in Engineering Design 8 (3) (1996) 125–138. [3] J.H. Dyer, Collaborative Advantage: Winning through Extended Enterprise Supplier Networks, Oxford University Press, 2000. [4] S.N. Wasti, J.K. Liker, Collaboration with suppliers in product development: a US and Japan comparative study, IEEE Transactions in Engineering Management 46 (4) (1999) 444–461. [5] M. Fathianathan, J.H. Panchal, Design nodes: an approach for modeling design processes, in: Proceedings of the 4th International Conference on Digital Enterprise Technology, Bath, United Kingdom, 2007. [6] M. Fathianathan, J.H. Panchal, An approach to modeling an ongoing design process utilizing top-down and bottom-up design methods, Proceedings of the IMECHE, Part B: Journal of Engineering Manufacture, in press.

[7] W. Shen, Q. Hao, W. Li, Computer supported collaborative design: retrospective and perspective, Computers in Industry 59 (9) (2008) 855–862. [8] V. Srinivasan, Standardizing the specification, verification, and exchange of product geometry: research, status and trends, Computer-Aided Design 40 (7) (2008) 738–749. [9] S. Rachuri, E. Subrahmanian, A. Bouras, S. Foufou, R.D. Sriram, Information sharing and exchange in the context of product lifecycle management: role of standards, Computer-Aided Design 40 (7) (2008) 789–800. [10] W. Gielingh, An assessment of the current state of product data technologies, Computer-Aided Design 40 (7) (2008) 750–759. [11] X.F. Zha, R.D. Sriram, M.G. Fernandez, Knowledge-intensive collaborative decision support for design processes: a hybrid decision support model and agent, Computers in Industry 59 (9) (2008) 905–922. [12] L.Q. Fan, A. Senthil Kumar, B.N. Jagdish, S.H. Bok, Development of a distributed collaborative design framework within peer-to-peer environment, ComputerAided Design 40 (9) (2008) 891–904. [13] W.D. Li, Z.M. Qiu, State-of-the-art technologies and methodologies for collaborative product development systems, International Journal of Production Research 44 (13) (2006) 2525–2559. [14] J.H. Panchal, M.G. Fernandez, C.J.J. Paredis, J.K. Allen, F. Mistree, The importance of designing design processes in product lifecycle management: research issues and strategies, in: ASME 2004 Computers and Information in Engineering Conference, Salt Lake City, UT, USA. Paper Number: DETC2004/CIE-2004-139, 2004. [15] J.H. Panchal, M.G. Fernańdez, C.J.J. Paredis, J.K. Allen, F. Mistree, Leveraging design process related intellectual capital—a key to enhancing enterprise agility, in: W. Li, et al. (Eds.), Collaborative Product Design & Manufacturing Methodologies and Applications, Springer-Verlag, 2007, pp. 211–244. [16] B.A. Bras, F. Mistree, Designing design process in decision-based concurrent engineering, SAE transactions, Journal of Materials and Manufacturing 100 (1991) 451–458. [17] M. Klein, H. Sayama, P. Faratin, Y. Bar-Yam, The dynamics of collaborative design: insights from complex systems and negotiation research, Concurrent Engineering: Research and Applications 11 (3) (2003) 201–209. [18] H. Park, M.R. Cutkosky, Framework for modeling dependencies in collaborative engineering process, Research in Engineering Design 11 (2) (1999) 84– 102. [19] S. Austin, A. Baldwin, J. Hammond, M. Murray, D. Root, D. Thomson, A. Thorpe, Design Chains: A Handbook for Integrated Collaborative Design, Thomas Telford House, 2001. [20] Y.-E. Nahm, H. Ishikawa, Integrated product and process modeling for collaborative design environment, Concurrent Engineering: Research and Applications 12 (1) (2004) 5–23. [21] O. Shai, Y. Reich, Infused design. I. Theory, Research in Engineering Design 15 (2004) 93–107. [22] K. Lewis, F. Mistree, Collaborative, sequential and isolated decisions in design, ASME Journal of Mechanical Design 120 (4) (1998) 643–652. [23] A. Xiao, Collaborative multidisciplinary decision making in a distributed environment, PhD Dissertation, Mechanical Engineering, Georgia Institute of Technology, Atlanta, GA, USA, 2003. [24] S.S. Rao, T.I. Freihet, A modified game theory approach to multiobjective optimization, Journal of Mechanical Design 113 (3) (1991) 286–291. [25] K. Badhrinath, S.S. Rao, Modeling for concurrent design using game theory formulations, Concurrent Engineering: Research and Applications 4 (4) (1996) 389–399. [26] K. Lewis, F. Mistree, Modeling interaction in multidisciplinary design: a game theoretic approach, AIAA Journal 35 (8) (1997) 1387–1392. [27] M. Marston, Game based design: a game theory based approach to engineering design, PhD Dissertation, Woodruff School of Mechanical Engineering, Georgia Institute of Technology, Atlanta, GA, USA, 2000. [28] G. Hernandez, C.C. Seepersad, F. Mistree, Designing for maintenance: a game theoretic approach, Engineering Optimization 34 (6) (2002) 561–577. [29] A. Gunasekaran, Y.Y. Yusuf, Agile manufacturing: a taxonomy of strategic and technological imperatives, International Journal of Production Research 40 (6) (2002) 1357–1385. [30] L.M. Sanchez, R. Nagi, A review of agile manufacturing systems, International Journal of Production Research 39 (16) (2001) 3561–3600.

402


[31] B.M. Beamon, Supply chain design and analysis: models and methods, International Journal of Production Research 55 (3) (1998) 281–294. [32] P. Gupta, R. Nagi, Flexible optimization framework for partner selection in agile manufacturing, in: IERC Proceedings 1995, 4th Annual Industrial Engineering Research Conference, Norcross, GA, USA, 1995, pp. 691–700. [33] N. Wu, N. Mao, Y. Qian, An approach to partner selection in agile manufacturing, Journal of Intelligent Manufacturing 10 (6) (1999) 519–529. [34] T.Y. Choi, J.L. Hartley, An exploration of supplier selection practices across the supply chain, Journal of Operations Management 14 (4) (1996) 333– 343. [35] D.Y. Sha, Z.H. Che, Supply chain network design: partner selection and production/distribution planning using a systematic model, Journal of Operations Research Society 57 (1) (2006) 52–62. [36] C. Hyong-Yi, Interval programming model for risk-based partner selection of virtual enterprise, Chinese Business Review 6 (3) (2007) 34–41. [37] S.H. Huang, M. Uppal, J. Shi, A product driven approach to manufacturing supply chain selection, Supply Chain Management: An International Journal 7 (4) (2002) 189–199. [38] F. Hacklin, C. Marxt, Decision support for strategic partner selection in collaborative design innovation, in: Proceedings of the International Design Conference, May 18–24, Dubrovnik, 2004. [39] R.J. Duffy, The future of purchasing and supply: supply chain partner selection and contribution, Purchasing Today (1999) 41. [40] N.P. Suh, Principles of Design, Oxford University Press, Oxford, UK, 1990. [41] J. Mihm, C.H. Loch, Spiraling out of control: problem solving dynamics in complex distributed engineering projects, in: D. Braha, A. Minai, Y. Bar-Yam (Eds.), Complex Engineering Systems, Perseus Books, New York, 2006 . [42] Y. Bar-Yam, When systems engineering fails—toward complex systems engineering, in: Proceedings of International Conference on Systems, Man and Cybernetics, IEEE Press, Piscataway, NJ, 2003, pp. 2021–2028.

Dr. Mervyn Fathianathan is a Director of BioMers Pte Ltd., a company engaged in developing novel polymer composite based products for biomedical applications. Prior to that, he was an Assistant Professor at the George. W. Woodruff School of Mechanical Engineering at Georgia Institute of Technology. He was also a former Chevening Technology Enterprise Scholarship Fellow where he undertook technology commercialization in the United Kingdom. He received his Ph.D. and B. Eng (Hons) in mechanical engineering from the National University of Singapore. His research interests are focused on IT-enabled engineering design, specifically computational environments for designing design processes, network-centric product realization and computational design methods for adaptive systems. Dr. Jitesh H. Panchal is an assistant professor at the School of Mechanical and Materials Engineering at Washington State University. He received his Bachelor of Technology from Indian Institute of Technology at Guwahati, and MS and Ph.D. in Mechanical Engineering from Georgia Institute of Technology. His research interests are in the field of Engineering Systems Design. Specifically, his current research focus is on simulationbased distributed design methodologies and technologies for multilevel systems. Dr. Panchal is a member of American Society of Mechanical Engineers (ASME), American Institute of Aeronautics and Astronautics (AIAA) and American Society for Engineering Education (ASEE).