Capturing and reusing knowledge in engineering ... - Springer Link

Inf Syst Front (2006) 8:375–394 DOI 10.1007/s10796-006-9009-0

Capturing and reusing knowledge in engineering change management: A case of automobile development Hong Joo Lee & Hyung Jun Ahn & Jong Woo Kim & Sung Joo Park

Received: 27 June 2006 / Accepted: 5 September 2006 / Published online: 5 December 2006 # Springer Science + Business Media, LLC 2006

Abstract The development of complex products, such as automobiles, involves engineering changes that frequently require redesigning or altering the products. Although it has been found that efficient management of knowledge and collaboration in engineering changes is crucial for the success of new product development, extant systems for engineering changes focus mainly on storing documents related to the engineering changes or simply automating the approval processes, while the knowledge that is generated from collaboration and decision-making processes may not be captured and managed easily. This consequently limits the use of the systems by the participants in engineering change processes. This paper describes a model for knowledge management and collaboration in engineering change processes, and based on the model, builds a prototype system that demonstrates the model’s strengths. We studied a major Korean automobile company to analyze the automobile industry’s unique requirements regarding H. J. Lee (*) Center for Coordination Sciences, Sloan School of Management, Massachusetts Institute of Technology, NE20-336, 3 Cambridge Center, Cambridge, MA 02139, USA e-mail: [email protected] H. J. Ahn Management Systems, Waikato Management School, University of Waikato, Gate 1 Knighton Road, Private Bag 3105, Hamilton, New Zealand J. W. Kim School of Business, Hanyang University, 17, Haengdang-dong, Seongdong-gu, Seoul 133-791, South Korea S. J. Park Graduate School of Management, Korea Advanced Institute of Science and Technology, 207-43, Cheongryangri-dong, Dongdaemun-gu, Seoul 130-722, South Korea

engineering changes. We also developed domain ontologies from the case to facilitate knowledge sharing in the design process. For achieving efficient retrieval and reuse of past engineering changes, we used a case-based reasoning (CBR) with a concept-based similarity measure. Keywords Automobile development . Case-based reasoning . Engineering change management . Knowledge capturing . Knowledge reuse . Semantic web

1 Introduction Engineering changes involve the modification of products and components that occur after the product design is released (Clark & Fujimoto, 1991; Huang, Yee, & Mak, 2003; Terwiesch & Loch, 1999). Development processes for complex products usually involve many engineering changes, which mostly reflect technological advances, resolve defects in the design, and improve the overall quality of the products (Adler & Clark, 1991; Pikosz & Malmqvist, 1998; Terwiesch & Loch, 1999). Engineering changes are considered inevitable, especially for complex products, because product development usually takes a long time and involves collaboration among designers and engineers who are often geographically distributed (Huang et al., 2003). In order to reduce the development cost and time required to produce a new product, many researchers and practitioners are interested in the efficient management of knowledge and collaboration in engineering change processes. Studies have found that engineering changes for complex products are often performed by heterogeneous teams in distributed environments, where knowledge-

376

Inf Syst Front (2006) 8:375–394

intensive collaboration and communication for various problem-solving and decision-making are essential (Alavi & Leidner, 2001; Grant, 1996). However, existing systems that support engineering change management (ECM) are mostly limited to the simple issuing and approval of engineering change orders (ECOs) through workflow management systems or storage and keyword-based retrieval of engineering change documents, which makes it difficult to capture and reuse the informal, unstructured knowledge inherent in engineering change processes. For this reason, a huge part of the valuable knowledge that has been generated during the past collaborations, decisionmaking, and from the contextual relationships between different types of knowledge can be lost, which often results in limited use of the systems. Since much of the engineering change knowledge are tacit and unstructured, it is very inefficient to use the existing support systems for sharing the knowledge among the designers and for solving problems (Ahn, Lee, Cho, & Park, 2005; Grant, 1997; Nonaka & Konno, 1999). The purpose of this paper is to develop a model and prototype support system for ECM to facilitate the accumulation and reuse of the knowledge generated in collaborative engineering change processes. We investigated the engineering change processes of a major Korean automobile company to determine the requirements of ECM for a specific industry. Then, a collaboration model was designed to support the geographically distributed designers and decision-makers involved in the engineering change processes. The collaboration model is also used as a knowledge annotation schema along with a Semantic Web (BernersLee, Hendler, & Lassila, 2001) language, so that knowledge items in ECM can accumulate naturally through the process, and contextual knowledge can also be captured easily. Domain ontologies are also developed to represent the knowledge context. To efficiently retrieve and reuse

past cases of engineering change, a case-based reasoning (CBR) technique is used with the concept-based similarity measure (Resnik, 1999). A prototype ECM system is implemented as a demonstration of the proposed model. The remainder of this paper is organized as follows. Section 2 reviews the literature on ECM issues. Section 3 describes a case study of the ECM practices in a Korean automobile company. Section 4 describes the derived model and examples of knowledge accumulation and retrieval. Section 5 presents the prototype system, which is called CECM (Collaborative environment for Engineering Change Management). Section 6 discusses the implications of this study and concludes with suggestions for further research.

2 Research background 2.1 Engineering change management Engineering changes are not always to the detriment of a development project, as many cost savings or performance improvements are brought into the project in the form of engineering changes (Clark & Fujimoto, 1991; Clark & Wheelright, 1993; Terwiesch & Loch, 1999). Table 1 summarizes the major causes of engineering changes. Although there are unnecessary changes that should be avoided, many of the engineering changes are actually beneficial. Therefore, it is neither desirable nor realistic to focus one’s efforts on simply eliminating the engineering changes (Clark & Fujimoto, 1991). Consequently, it is more important to manage the engineering change processes efficiently to reduce the time and cost of product development. The formal process of an engineering change usually consists of four stages (Huang, Yee, & Mak, 2001; 2003; Pikosz & Malmqvist, 1998; Terwiesch & Loch, 1999): initiating an engineering change request (ECR), evaluating

Table 1 Causes of engineering changes Causes of engineering changes

Descriptions

Careless mistakes

Corrections of errors on a document (Clark & Fujimoto, 1991; Clark & Wheelright, 1993; Pikosz & Malmqvist, 1998) Faults in the interpretation of customer demands into technical requirements (Pikosz & Malmqvist, 1998) Changes in the customer specification (Pikosz & Malmqvist, 1998) Changes in the manufacturing process or situations Change of a part depending on altered function or production requirements (Huang & Mak, 1998; Pikosz & Malmqvist, 1998; Wright, 1997) Organizational, technological and operational changes (Karvounarakis et al., 2003) Cost savings (Clark & Fujimoto, 1991; Clark & Wheelright, 1993) Change, replacement, withdrawal, and introduction of a part (Pikosz & Malmqvist, 1998) Difficulties in parts fabrication or assembly (Pikosz & Malmqvist, 1998) Weakness in the product identified during prototype testing (Pikosz & Malmqvist, 1998) Quality problems with some subsystems or component (Pikosz & Malmqvist, 1998) Development for future product revisions (Pikosz & Malmqvist, 1998)

Poor communication

Snowballing change

Cost savings Ease of manufacturing Product performance improvement

Inf Syst Front (2006) 8:375–394

Problem Detection

ECR Form

377

Identifying Problem Scope

ECR Evaluation Form Generating Alternatives

Reference

&

Non-routine, knowledge-intensive tasks: Many of the tasks involved in engineering change processes are non-routine and require problem solving by heterogeneous groups of people with high levels of expertise. This makes knowledge sharing and transfer between team members critical.

Reference

Engineering Change Log

ECO Form Approval Process

Hence, support systems for ECM should be designed to reduce the complexity of the process and to facilitate virtual collaborations and knowledge management.

Fig. 1 The process of engineering change management

2.2 Computer-aided ECM systems the ECR, issuing engineering change orders (ECOs) to relevant participants, and storing and analyzing the ECOs for management purposes (Fig. 1). Based on the four-stage model, the characteristics of typical engineering change management processes and associated problems can be identified as shown in Table 2 (Adler & Clark, 1991; Clark & Fujimoto, 1991; Huang & Mak, 1998, Huang et al., 2001; 2003; Pikosz & Malmqvist, 1998; Terwiesch & Loch, 1999). &

&

Complexity: The products and processes involved in engineering changes usually involve a high level of complexity. Complexity in processes requires iterative communication and collaboration to adjust the engineering changes. Complexity in products incurs snowballing effect when a change in a single part is propagated to numerous related parts or products, which often contributes to long ECO lead times (Terwiesch & Loch, 1999). Virtual collaboration: Today, engineering changes for a complex product like an automobile usually involve the collaboration of virtual design teams, which operate in a geographically distributed or global environment.

Early studies of computer tools for ECM have focused on stand-alone computer-aided systems for storing and retrieving engineering change documents (Huang et al., 2001; Wright, 1997) to replace paper-based ECM. In some companies, the engineering changes are managed by configuration management (CM) systems which focus on how products are configured and changed (Huang & Mak, 1998). Recently, ECM systems based on workflow systems have been proposed (Huang & Mak, 1998; Huang et al., 2001) that provide a wide set of functionalities for supporting the entire engineering change process. They allow employees to issue and approve engineering change requests, track the change status, and manage the related documents. Although the workflow-based systems manage documents efficiently, they are still limited in their ability to capture and reuse the knowledge involved in engineering changes. Important knowledge resources, such as context information on knowledge items, collaborative experiences, and decision-making processes, are not contained in ECM systems because the systems cannot incorporate collaborative change processes. Engineering change teams currently depend heavily on off-line collaboration without codifying

Table 2 Characteristics and problems in the engineering change process Characteristics of engineering change processes

Problems

Complex Process

Extensive document management (Clark & Fujimoto, 1991; Pikosz & Malmqvist, 1998) Complex approval process (Terwiesch & Loch, 1999) Long learning time for new employees and consultants (Pikosz & Malmqvist, 1998) Induce a series of downstream changes—snowballing changes (Huang & Mak, 1998; Pikosz & Malmqvist, 1998; Terwiesch & Loch, 1999) Couplings between the component or development activities (Terwiesch & Loch, 1999) Limit capacity of an individual engineer (Terwiesch & Loch, 1999) A significant time loss from “diving into the project again” (Loch & Terwiesch, 1996; Terwiesch & Loch, 1999) Distributed members (Huang et al., 2003) Cross functional and multi-disciplinary teamwork (Huang et al., 2001) Alternative solutions are evaluated to satisfy everyone (Pikosz & Malmqvist, 1998) Conflict between departments and cultural differences (Terwiesch & Loch, 1999) Creativity and innovation are highly required (Adler & Clark, 1991) High reuse the information is necessary (Pikosz & Malmqvist, 1998)

Product complexity

Ad hoc activities

Distributed environment

Knowledge intensiveness

378

Inf Syst Front (2006) 8:375–394

the knowledge explicitly. Consequently, knowledge reuse is poor because of the insufficient management of past experience and is limited to searching by keywords or reference numbers and hence browsing categories. In addition to workflow, other approaches exist for implementing ECM systems. There are several knowledge management (KM) systems for product development that are intended to capture process knowledge and to share product data (May, Carter, & Joyner, 2000; May & Carter, 2001; Monplaisir, 1999; Numata & Taura, 1996; Ramesh & Tiwana, 1999; Yoo & Kim, 2002). Ramesh and Tiwana focused on capturing process knowledge for collaborative product-development tasks, and suggested a model that represented concepts in product development along with a concept map describing dependencies among the concepts (Ramesh & Tiwana, 1999), which is similar to the issue-based information system (IBIS) model (Conklin & Begeman, 1988). Computer supported cooperative work (CSCW) has also been applied to product development (May et al., 2000; May & Carter, 2001; Monplaisir, 1999). It has been shown that the productivity of engineering design teams can be enhanced further when the CSCW functions are augmented with integrated process development architecture (May et al., 2000; May & Carter, 2001; Monplaisir, 1999). Numata and Taura (1996) emphasized communication among engineers participating in product development and suggested a knowledge network for enhancing the convenient transfer of knowledge among engineers (Numata & Taura, 1996). These systems demonstrate the use of typical KM functions for ECM, but they are still limited in organizing and sharing product knowledge manually so that contextual knowledge is usually difficult to capture.

3 Case study 3.1 Overview As a case study, we investigated the new product development projects of a major Korean automobile company. Data were collected from multiple sources, including the following: & & &

Semi-structured interviews with staff members responsible for engineering, operation management, cost management, and development process management. A collection of articles on engineering changes and new product development that were submitted as a result of the host company’s internal training program. Data analysis from a Web-based information system that the company uses to keep track of ECOs.

The company’s product development teams are distributed globally in 14 plants and six R&D centers. Product

engineering activities are closely related to concept generation, product planning, and process engineering activities, and need intensive communication with suppliers. Product development teams use a workflow system to handle engineering changes in which a simple workflow instance is defined as initiating ECRs, issuing and noticing ECOs, and approving ECOs. The company’s Web-based intranet system includes e-mail, community discussion boards, and a document management system. 3.2 The process of engineering change Figure 2 describes the steps needed before an engineering change of an automobile component is handled successfully. When a problem is detected in a certain process, a request is made for the engineering team or the engineer in charge of that automobile component to review the problem. Through discussions among engineers and team members who detected the problem, they decide whether to initiate an ECR. When a decision is made to initiate an ECR, the team completes the ECR form using the workflow system. This form contains information on the product and automobile components that need to be changed, and the reasons for and a description of the ECR. After the engineering team reviews the ECR, they decide to accept or reject it. The status of an ECR can be tracked and monitored by the person who made the request. The assigned engineer identifies the causes of the problem and the scope of the engineering change by communicating with related engineers. To generate alternative solutions to the engineering change, they usually rely on their past experience and knowledge. In addition, they try to find similar situations from the intranet system, which stores the problem and engineering change reports from past projects. Then, the engineer in charge issues an ECO that contains the information from the ECR; changes in weights and production costs, the time when the engineering changes will become effective, and the plans to handle obsolete parts. If there is a change in the unit cost of a part, the ECO has to be approved by the cost management department simultaneously. After administrative approval, the ECOs are sent to the technology management team to validate the consistency in the product design and to check for possible errors and inconsistencies. Then, the ECOs and associated product data are released and stored in the intranet system of the company. 3.3 Knowledge management practices To derive the desired features of ECM, the ECM process of the automobile company is reviewed and analyzed from a knowledge-management perspective, emphasizing the four

Inf Syst Front (2006) 8:375–394

379

Fig. 2 The process of engineering change

stages of the knowledge process: knowledge creation, storage/ retrieval, transfer, and application (Alavi & Leidner, 2001): &

&

Knowledge Creation: Despite the knowledge-intensive nature of the engineering change process, there is no formal consideration of knowledge management related to ECM in the automobile company. An engineering change process is regarded as merely an instance of the company’s workflow, and the resulting knowledge is embedded in separate documents. The current system fails to capture the variety of knowledge associated with engineering changes. In addition, the knowledge created in off-line collaboration is not incorporated in the current workflow system because the system does not provide a way to link informal, unstructured knowledge with the structured knowledge in workflows. The rigidity of the document form also limits the generation and accumulation of knowledge. Knowledge Storage/Retrieval: All ECRs and ECOs are stored automatically in the intranet system after the workflow is finished. The engineering changes are organized by product category, component modules, and part information. The intranet system does not provide sufficient support of the contextual knowledge which can be used to navigate for the relevant knowledge. The valuable links between a specific engineering change and related parts, products, problems, and solutions are not preserved in the system. Past engineering changes are retrieved using

&

&

a simple keyword-based search and browsing predefined categories of engineering changes. Knowledge Transfer: According to a company report on new automobile development projects, one-third of all engineering change problems are not new. As a universal characteristic of automobile companies, product engineering departments are highly compartmentalized according to the models and functions of the automobiles. Knowledge related to the same problems in different components or the same component in different models cannot be transferred easily. Knowledge Application: Since ECM systems merely store minimal knowledge of engineering changes, valuable knowledge, such as difficulties in making changes and important decision-making issues, is lost. The engineers depend mainly on their tacit knowledge of past experience and off-line communications to solve the engineering changes at hand.

3.4 Findings from the case study The engineering change process of an automobile company is complex; it handles various types of knowledge, and requires collaboration among distributed engineers. At the automobile company of the case study, the engineers in the engineering department usually regarded engineering changes raised in the latter part of the development as their

380

Inf Syst Front (2006) 8:375–394

fault. Hence, they often tried to handle the changes quickly using off-line collaboration without using excessive, timeconsuming paperwork. This made it difficult to capture the tacit knowledge embedded in the collaboration and preventing the use of similar cases in later stage. Even for the engineering cases preserved in the current system, the stored knowledge are not sufficient to capture the rich relationships between design knowledge items. The system provided access to the database via simple keyword-based queries and category-based browsing. These problems have limited the accumulation of knowledge which led in turn to ineffective and inefficient use of the system. Although the problems found in the case study are specific to the target organization, we reasonably postulate that many of the problems stem from the inherent complexity of general engineering change processes.

ration can be a very powerful method of supporting knowledge-intensive work in a distributed collaborative environment. Third, for the knowledge management functions, we develop ontologies, design a case-based reasoning mechanism for knowledge retrieval in CECM, and provide resource description framework (RDF)-based Semantic Web representations of engineering change knowledge. The ontologies provide common representations of various types of knowledge used for engineering processes, which are used to create Semantic Web pages for knowledge sharing. Combining the case-based reasoning mechanism with the ontologies is useful to retrieve engineering change cases in practice.

4.1 Design of the collaboration model for engineering change management 4 The collaboration model for engineering change management The objective of this research is to design a collaborative environment for ECM (CECM) to facilitate the accumulation and use of knowledge amassed through the engineering change processes of the target organization as shown in Fig. 3. The key points in the approach are as follows. First, a model is developed that captures the nature of the collaboration in engineering processes. The model tries to support both routine and non-routine collaboration to overcome the limitations of many workflow-based systems that only save form-based documents and use them in routine workflow. Second, the figure shows that the collaboration model is used for knowledge management functions of CECM as well. The collaboration model plays an important role in capturing both general and contextual knowledge naturally, along with collaborative processes. In other words, it not only provides a basis for collaboration support but also is used as a schema for knowledge representation for the CECM. Aligning knowledge management with collabo-

Collaborative Environment for ECM (CECM)

Collaboration Support:

Knowledge Management: Ontology, Case-Based Reasoning, and Semantic Web

Routine and Non-routine collaboration

Collaboration Model

Fig. 3 Overview of the approach

Since the engineering change process involves many knowledge-intensive tasks performed in a distributed environment, we adopted the knowledge context model (KC-V) as a base model. The KC-V model was originally developed to capture and to utilize contextual knowledge in virtual collaboration environments. The KC-V identifies three key perspectives of the modeling context in virtual environments: organization, activity, and context (Abecker, Bernardi, Hinkelmann, Kühn, & Sintek, 2000; Jarvenpaa & Leidner, 1999; Maus, 2001; Wong & Burton, 2000). It has been used to build a knowledge and collaboration management system for virtual work called the Virtual Workgroup Support System (VWSS) (Ahn et al., 2005). The most distinguishing feature of KC-V and VWSS is that they integrate collaboration with knowledge management, when knowledge is captured naturally along with activities. The coordination and execution of activities naturally contribute to the accumulation of knowledge, and in doing so, the knowledge context is effectively preserved based on the context structure of the KC-V. Hence, we developed our collaboration model by refining the KC-V and reflecting unique characteristics of the problem domain as shown in Fig. 4. The three perspectives of the KC-V are applied to the engineering change process as follows. The organizational perspective explicitly defines and supports the life cycle of virtual teams that involves organizing the virtual engineering change teams, collaborating until the engineering change problems are solved, and disbanding the teams after the goals are reached. The activity perspective emphasizes the alignment of knowledge management and collaborative activities. It tries to link the outputs of routine and non-routine activities of engineering change management to a knowledge repository and preserve the rich

Inf Syst Front (2006) 8:375–394

381

4.1.2 Conversation

relationships among knowledge items so that they can be used as contextual knowledge. Instead of merely storing engineering change forms in a document base, for example, it can turn discussion messages into knowledge items; answering various workflow requests or ad hoc non-routine conversation messages naturally contributes to the generation and accumulation of knowledge; setting, coordinating, and reaching milestones of activities are also associated with knowledge creation so that additional efforts at collecting knowledge can be minimized. Thus, the proposed system based on the KC-V is neither a collaboration system nor a knowledge management system but a combination of both that preserves the rich knowledge context. The third component, the context perspective, simply helps to organize the knowledge items by linking entities of the organizational perspective and the activity perspective (Ahn et al., 2005).

A conversation is a set of structured messages based on speech-act theory for supporting cooperative processes (Agostini, De Michelis, & Grasso, 1997; Delteil, FaronZucker, & Dieng, 2001). During a conversation process, knowledge items, such as discussions and documents, are created and the status of an associated activity or document is updated. ‘Conversation’ is a simplification of the ‘Coordination’ construct in the KC-V model. This change was made because the coordination construct in the KC-V model was aimed at very broad types of coordination that are not necessary for the engineering change process. 4.1.3 Two types of knowledge item: document and discussion The collaboration model supports two types of knowledge item: document and discussion entities. The document entity represents formal, structured documents and forms, such as ECRs, ECOs, and interim or final reports of an engineering change activity. In contrast, the discussion entity was designed to broadly represent unstructured communications between actors, and is associated with activity, document, and conversation entities.

4.1.1 Activity and process A process can have hierarchically organized activities as shown in Fig. 4. It also has the life-cycle status of an engineering change process as an attribute. After completing an engineering change, the entire set of knowledge items and the structure of the activities used in the process can be stored in the knowledge repository, along with the knowledge context. Placed at the center of the model, the activity is crucial for integrating knowledge items with a knowledge context. Knowledge items are associated with activities via the knowledge context entity, and other context entities, such as actors, milestones, and conversations, can also be associated with the activity entity.

4.1.4 Knowledge context The knowledge context entity defines the context of a knowledge item explicitly, as depicted in the Fig. 4. In this way, each knowledge item, such as documents and discussions, is explicitly associated with its creation context, which

Fig. 4 The collaboration model

is related w ith .

1

Ont ology

Concept

cont ains

pr eserv es

Process

0..* s ha

.

.

Actor

1

1

Milest one

belongs t o

s

1

ds

rm

is super of

ho l

p

fo er

1

owns

Role

1

Conversation

.

Discussion re fer s

init iat es

coordinat es

pro duces pert ains t o

Event

Schedule

Know ledge Item

Activit y

includes

par t icipat es

0

possesses

Know ledge Contex t

Docume nt

382

Inf Syst Front (2006) 8:375–394

is centered on the activity entity within which the knowledge item was created. Through this explicitly defined knowledge context entity, the system can provide comprehensive links to entities that are helpful for understanding individual knowledge items, such as related activities, actors, conversations, and milestones. 4.1.5 Ontology The ‘ontology’ construct in the collaboration model is derived from the ‘domain’ construct of the KC-V and is used to retrieve past knowledge items reflecting the complex multidimensional characteristics of the automobile industry. For an automobile development project, the following domain ontologies were identified as key dimensions (Golebiowska, Dieng-Kuntz, Corby, & Mousseau, 2001): & & &

& &

Product ontology: a hierarchy of product segmentations and their manifestations, such as passenger cars, recreation vehicles, and commercial vehicles. Component ontology: a hierarchy of components, modules, and functions in a vehicle, such as engine, cockpit, and axle. Problem ontology: a collection of problem types that describes the causes of problems and reasons for engineering changes, such as product safety and manufacturing difficulties. Solution ontology: a hierarchy of solution types in engineering changes, such as product form modification and assembly hole relocation. Process ontology: the structure of a new product development process and its hierarchy of activities in a project, such as planning, styling, or pilot production stages.

Figure 7 shows examples of these ontologies. 4.2 Knowledge representation with the collaboration model and ontologies The collaboration model can be a schema of knowledge annotation used to define knowledge structure and validate knowledge in a knowledge management application. All of the constructs in the collaboration model are used to annotate the knowledge items, along with their context information. Resource description framework schema (RDFS) is a schema-specification language developed for representing the RDF statements (RDF, 1999; RDFS, 2000) used for the Semantic Web (Berners-Lee et al., 2001; Decker, Mitra, & Melnik, 2000; RDF, 1999). An RDF annotation consists of a set of statements, each one specifying the property of a resource (Decker et al., 2000; De Michelis, & Grasso, 1994; Melnik, 2000; Melink & Decker, 2000; RDF, 1999). Based on the RDFS descriptions, instances of domain ontologies and the entities of the collaboration model are generated. The RDF instances of

the domain ontologies are also used in defining a case. Consequently, the knowledge items in engineering change processes are annotated using the RDF definitions for outputs such as ECOs, modification results, and problemsolving reports. The Semantic Web-based knowledge representation combined with the collaboration model and domain ontologies has the following advantages: (1) Accumulation of knowledge context: As shown in Fig. 5, a knowledge annotation includes contextual information of knowledge items, such as related activities, milestones, and actors. Users can navigate to other relevant knowledge items through the links provided by the knowledge context of a given knowledge item. (2) System-independent representation of knowledge: Semantic Web technology such as RDF enables us to enrich knowledge by annotating or giving its meaning with tags defined in the ontologies. The structure and meaning of RDF statements can be identified by other systems with RDFS and associated ontologies. For example, using RDF pages, it becomes easier for other systems, such as a product data management (PDM) system, to identify the meaning of engineering changes, such as related parts, the source of problems, and problem-solving methods.

4.3 Knowledge reuse in engineering change management Ontology-driven knowledge management answers queries using logical deduction based on ontologies (Broekstra, Kampman, Harmelen, & Sesame, 2003; Karvounarakis et al., 2003), but the strictness of deductive reasoning has been recognized as one of the major obstacles in illstructured and complex problems (Bergmann & Schaaf, 2003). Case-based reasoning (CBR) can be used to relax the strictness by allowing the retrieval of knowledge items that are close to queries, but not exact matches (Bergmann & Schaaf, 2003; Kolodner, 1993; Lorenzo & Perez, 1997). However, there are difficulties in applying CBR to ECM. First, an engineering change case (e.g., ECR or ECO) is defined as an aggregate of the related components, processes, problems, products, and solutions that does not allow easy quantification for developing numerical distance measures. For example, to define the numerical distance between a 2.5 DOHC gasoline engine and a 2.0 diesel engine, one may have to rely on experts’ subjective opinions. Furthermore, the manually assigned weights and similarity measures can easily be outdated because of the introduction of new products or new components. In addition, the large number of different parts and components makes the experts’ subjective weighting almost

Inf Syst Front (2006) 8:375–394 Fig. 5 Knowledge context and navigation paths

383

Engineering Change Case … … … … … … … … … … …

impossible (Kolodner, 1993). In order to address this problem, the information-based measure of Resnik (1999), which measures concept similarities automatically, is adopted (Resnik, 1999). In addition, since an engineering change case is defined using several different ontologies, proper weights should be assigned to the ontologies depending on their relative importance in retrieving engineering change cases. For example, we need to determine the relative Fig. 6 Weights of the five ontologies

Case information -Product -Component -Process -Problem -Solution

Relevant Cases Case Based Reasoning

Activity information -Activity hierarchy -Subordinated items

Related Document -Milestone -Preparation material

Related Activities & Items Knowledge Context

Related Discussion -Discussed articles -Decision making history

importance of the ‘process aspect’ of an engineering change case compared to the ‘component aspect.’ To determine the weights, the analytic hierarchy process (AHP) was used (see Appendix A) (Chen & Huang, 2001; Saaty, 1980). A set of pair-wise comparisons of the ontologies was collected from the experts in the case company using questionnaires. The result of the AHP calculation is presented in Fig. 6.

Solution

0.214

Product

0.094

Process

0.035

Problem

0.21

Component

0.447 0

0.1

0.2

0.3

Normalized Weights

0.4

0.5

384

Inf Syst Front (2006) 8:375–394

The final similarity measure between two engineering change cases, E1 and E2, is given in formula (1) (see Appendix B). P wi  fi  simi ðc1i ; c2i Þ P SimðE1 ; E2 Þ ¼ i ; ð1Þ wi i

where wi is the weight of ontology i calculated using the AHP, fi is the factor used to reduce the effects of different depths in different ontologies (see Appendix B), and c1i and c2i represent the respective concepts of E1 and E2 in ontology i. As an illustration, consider the situation in Fig. 8. In this example, there are two engineering change cases; case 1 is an ECR and case 2 is an ECO, and these two cases are associated with the ontologies in Fig. 7. Arrows are used to indicate comparison points between the two cases; the product concept in case 1 is compared to the product concept in case 2. In addition, the component, problem, and process concepts of case 1 are compared to the corresponding concepts of case 2. The table in the lower part of Fig. 8 shows

how each concept in the different ontologies is used to calculate the aggregate similarity. The third column (Closest Common Parent) shows the closest common parent between two concepts in the two cases and the fourth column provides the information value of the closest common parent in the third column. The fifth column represents compensation values for reducing the size effect of ontologies because the average value of the information-based measure is proportional to the size of a given ontology (see Appendix B). The sixth column contains the weights of the ontologies calculated using the AHP. This CBR method has the following additional advantages in retrieving engineering change cases. First, diverse factors pertaining to engineering changes can be considered to find similar cases of past engineering change. In this paper, components, processes, problems, products, and solutions are reflected as the attributes of engineering changes. Second, although there can be frequent changes in individual items in the ontology, it is unlikely that the relative importance of the ontologies will change markedly over time. Therefore, once AHP weights are calculated, they will Component ontology

Problem ontology Component p=1 info = 0

Problem

Chassis

Engine p=0.3 info = 1.2039

p=0.2 info = 1.6094

Assembly

Fixing

Installation

Resistance

Clipping

Stapling

Axle

p=0.03 info = 3.5065

p=0.2 info = 1.6094 Coupling

Fitting

p=0.001 info = 6.9077

Product ontology

Vehicle

p=0.05 info = 2.9957

Passenger Car

SUV

A3

Midsize

M4

Brake

p=0.1 info = 2.3025

X6

Prototype

Process

Pilot

Manufacturing

p=0.2 info = 1.6094

Luxury

X7 p=0.05 info = 2.9957

Fig. 7 Parts of ontologies

Axle Mechanism

Rear Suspension

p=1 info = 0

Truck

Van

Fullsize

X5

Pedal

Process ontology

Prototype #1 Compact

Steering

p=1 info = 0

Engineering p=0.5 info = 0.6931

Suspension

Front Suspension

p=0.049 info = 3.0159

p=0.7 info = 0.3566

Car

Bus

p=0.1 info = 2.3025

Implementation

p=0.05 info = 2.9957 Screwing

Climate Control

p=0.4 info = 0.9162

p=0.2 info = 1.6094

Performance

p=0.3 info = 1.2039 p=0.1 info = 2.3025

p=1 info = 0

p=0.1 info = 2.3025

X8 p=0.03 info = 3.5065

Prototype #2

Assembly Planning p=0.05 info = 2.9957

Pilot Production p=0.1 info = 2.3025

Inf Syst Front (2006) 8:375–394

385

Case 1

Case 2

.. X8 Product L2.0 2003 Europe Component FrontSuspension F301 Problem Screwing Process Pilot production …

Identical

Closest Common Parent

Maximum Similarity Value

fi

wi, weight of ith ontology

Problem

No

Assembly

1.2039

0.5118

0.21

Component

Yes

Front Suspension

2.9957

0.3358

0.447

Product

No

Luxury

2.3025

0.9098

0.094

Process

Yes

Pilot production

2.3025

0.9678

0.035

Solution

-

-

-

-

0.214

Ontology

Similarity = = 1.0864

.. X67 F2.0 2000 Asia FrontSuspension F102 Fitting Pilot production

…

Similarity between concepts

0.21 x 0.5118 x1.2039 + 0.447 x 0.3358 x 2.9957 + 0.094 x 0.9098 x 2.3025 + 0.035 x 0.9678 x 2.3025 0.21 + 0.447 + 0.094 + 0.035

Fig. 8 Similarity calculation between cases

remain valid for a long time and not require frequent updates. Third, the similarity measures can be calculated automatically from the engineering change case base without human intervention. This automatic calculation keeps the cost of expanding the case base for new products and components low. Finally, the retrieval mechanism can be flexible and accommodate new types of ontologies when users wish to

include additional dimensions to engineering change cases for new organizational strategies or practices. 4.4 Performance analysis of case retrieval To test the feasibility of the proposed CBR method, we collected 261 ECRs from previous past development

386

Inf Syst Front (2006) 8:375–394

Table 3 Average similarities between retrieval methods

a

Significant at alpha = 0.05 b Significant at alpha = 0.10

(1) Processbased (2) Problembased (3) Componentbased (4) Ontologybased (5) Keywordbased

N

Average similarities

Standard deviation

(1)

70

2.652381

0.9683

–

70

2.761905

1.2176

0.404

–

70

2.828571

0.9975

0.205

0.668

–

70

3.185714

0.7773

0.000a

0.013a

0.013a

–

70

2.914286

0.9439

0.025a

0.246

0.545

0.073b

projects of the automobile company. Since the engineering change cases collected were ECRs, this analysis could not use a solution ontology. Through discussion and interaction with the engineers at the company, four domain ontologies were built using Protégé, an ontology editor used to build Semantic Web content. We simulated engineering change case retrieval using the following methods: concept-based retrieval (i.e., process-based, problem-based, and component-based retrievals), ontology-based retrieval, and keyword-based retrieval. &

&

&

&

&

(3)

(4)

keyword-based retrieval (Salton & McGill, 1983). They represent each object as a vector of features in a kdimensional space and compute similarity using measures such as the cosine or Euclidian distance. We extracted keywords from all the cases and eliminated keywords with a low term frequency-inverse document CECM Process support system

Concept-based retrieval: This retrieval mechanism is

similar to sorting through categorized engineering changes using concepts, such as engineering changes made to the same component or ones caused by the same problem. Process-based retrieval: This mechanism searches for past engineering change cases that took place during the same product development process as the target case, and retrieves the recent cases. Problem-based retrieval: This mechanism searches for past engineering change cases that took place because of the same problem as the target case, and retrieves the recent cases. Component-based retrieval: This mechanism searches for cases of past engineering change in the same engineering component as the target case. Engineers browse component hierarchies to find relevant cases. For example, engineering changes in the form or relocation of a heat protector to reduce interference with other parts belong to the same component category. Ontology-based retrieval: As described in Section 4.3, the ontology-based retrieval mechanism determines the semantic similarity between complex objects in ontologies. This mechanism uses formula (1) to calculate the similarity and weight values described in Fig. 6. Keyword-based retrieval: The basic concept of keywordbased retrieval is to find engineering change cases that have keywords similar to the target case. Vector space models are very common in information retrieval and

Workspace Manageme nt Activi ty Ma nageme nt Conve rsatio n support

&

(2)

Actor Manageme nt Document Manageme nt

Role Management Appr ov al Routing

Discussion Manageme nt Milest one Manageme nt Sto red & Retrieved

Specified

Knowledge Reposit ory

Ont ology Manageme nt

Delive ry Query Inde xin g

Ontolo gy

Reasoned Case Base

Fig. 9 Architecture of CECM

Inf Syst Front (2006) 8:375–394

frequency (TF-IDF) (Salton & McGill, 1983). We constructed keyword vectors for each case and calculated similarities between cases using the cosine measure. The Korean automobile company that we studied uses component-based retrieval and simple keyword-based search methods. To compare similarities between the case retrieval mechanisms, we asked seven expert raters from the automobile company to rank similarity values and to rate relevant cases. We provided ten randomly selected target cases and retrieved the relevant cases using the five methods. Table 3 shows the average similarities as rated by the experts. The ontology-based retrieval method provided the greatest average similarity. The average similarities between the five methods were tested statistically using repeated measures ANOVA. Each pair within the five methods was compared. The null hypothesis was that average similarities resulting from the two methods would be the same. Table 3 summarizes the comparisons, and the values in the cells indicate the significance level. The average similarity of the ontology-based method was significantly higher than results for the other methods; the ontology-based method had a higher average similarity than the three concept-based methods (process-, problem-, and Fig. 10 Process and activity management

387

component-based) at the 0.05 significance level. In addition, the ontology-based method had greater average similarity than the keyword-based method at the 0.1 significance level.

5 Collaborative environment for engineering change management (CECM) A prototype system called Collaborative environment for Engineering Change Management (CECM) was implemented, as shown in Fig. 9. CECM consists of three subsystems: the engineering change process support system, the knowledge repository, and the ontology management. The process support system provides functions to manage engineering change operations, such as processes, activities, conversations, documents, actors, discussions, and schedules. The knowledge repository enables the representation of engineering change experience and the retrieval of similar knowledge items. Annotations on knowledge items and knowledge context are stored in the knowledge repository. The ontology management provides functions to edit the existing ontology and hierarchies of concepts.

388

5.1 Engineering change process and activity execution The process and activity management functions in CECM attempt to capture both formal and structured knowledge in workflows, and informal and unstructured knowledge from online ad hoc collaboration. The functions also try to help users organize relevant knowledge in engineering changes around the engineering change activities because the activity is the key element of the knowledge context in the model. After detecting a problem in product development, a workspace is created to handle the engineering change process and to organize a temporary team with diverse backgrounds. In a workspace, routine activities for approval are predefined, such as initiating an engineering change request, evaluating the requested change, and issuing engineering change orders, and users can define any other activities according to their own needs. An

Fig. 11 Initiating an ECR

Inf Syst Front (2006) 8:375–394

activity can be decomposed into sub-activities and can have participants, documents, discussions, milestones, and conversations. Figure 10 shows an example of a workspace concerned with ‘noise reduction on heat protector’ in the ‘X8’ car. Employees can organize a workspace according to the specific requirements of an engineering change and online discussion sessions can be created on the workspace that enable the connection of informal knowledge and formal documents or outputs.

5.2 Initiating a draft of an ECR A workspace in CECM generates a workflow for handling engineering changes, as shown in Fig. 11, when a user fills out the ECR form. Users can associate various types of knowledge with workflow forms, such as documents,

Inf Syst Front (2006) 8:375–394

discussions, and cases retrieved from the repository (see the ‘Relating entities’ row of the form in Fig. 11). In this way, the workflow is also associated with the relevant knowledge items from the workspace.

5.3 Knowledge delivery When a user prepares to initiate ECRs or ECOs, similar ECRs, ECOs, and knowledge can be delivered by the proactive execution of the CBR mechanism. Figure 12 shows an example screen in which relevant past cases were listed. The user can set the weights of the five ontologies for the CBR using two options: weights assigned by the user or weights generated by the AHP (default weights). When the user selects a relevant case, such as ‘Noise reduction on climate control systems,’ the context information from the case is presented in the manner shown in Fig. 13. The user can see the activities that created the knowledge, discussions, and associated decision-making. 5.4 Evolution of the engineering change document ECRs and ECOs are the final outputs in the workflowbased ECM system, since engineering changes are requested after engineers discuss problems informally. The Fig. 12 Knowledge delivery

389

initial ECRs and ECOs in CECM are interim requests and evolve gradually through discussions and collaborative activities in the workspace. This mechanism of the early evolution of the change saves time and costs. Figure 14 shows an example of a conversation leading to revision of an ECR. If users want to revise the request or the solutions to an engineering change case, they can initiate a conversation process. They describe their ideas for revision and reference entities, especially past engineering change cases, using the conversation form. In this way, the evolutionary history of the documents is also captured, together with the related discussions and decision-making. 5.5 Collaborative activities An activity can be divided into two types: routine and nonroutine. Routine activities are related to the approval processes involved in engineering change management, such as initiating an engineering change request, evaluating the requested change, and issuing engineering change orders. Users can define any activities used to perform collaborative tasks, such as proposing alternatives and identifying the scope of the problem. These activities can be decomposed into sub-activities with participants, documents, discussions, milestones, and conversations.

390

Inf Syst Front (2006) 8:375–394

Fig. 13 Knowledge context of the past case

5.6 Closing the workspace After the engineers come up with the final solution, it has to be approved by management or the cost management department. The approval of the ECO is routed automatically based on the scope of the change. Before closing the workspace, the workspace manager can rearrange the workspace by organizing knowledge items, removing redundant items and activities, and changing the structure of the workspace for later use. Knowledge items in the workspace are stored with their contextual information such as related activities, evolutionary history, related conversations and discussion, actors, and documents, for reuse.

6 Conclusion This paper presented a model of ECM that focuses on the integration of collaborative activities and knowledge management throughout the lifecycle of engineering changes. A prototype ECM system called CECM was

developed based on the model to demonstrate its practical feasibility. There are several significant advantages of the proposed model. First, the model provides a basis for the integration of informal and unstructured off-line collaboration with structured online workflows so that valuable knowledge can be captured effectively in context. Second, the collaboration model demonstrated how Semantic Web technology can help represent and share various types of engineering change-related knowledge in context. Five types of ontologies were developed for the automobile industry, which can be extended or modified for other industries. Third, in order to store, search, and retrieve engineering cases efficiently, the CBR technique was used along with the concept-based similarity measure so that manual efforts in managing the cases could be minimized. A simple experiment showed that the CBR-based mechanism provides greater performance in retrieving relevant cases compared with the keyword-based search used in many existing ECM systems. The proposed model and system can be used in other domains where engineering change processes are complex,

Inf Syst Front (2006) 8:375–394

391

Fig. 14 Evolution of an ECR

knowledge-intensive, and costly as well. Such domains may include consumer electronics, motorcycle manufacturers, and computer manufacturers. Although many large-scale manufacturers are already using their own ECM systems and it may require a huge investment to implement CECM, the suggested ECM model and CECM present a vision of an advanced ECM system for the future that utilizes next generation web and intelligent information technologies. We also believe that the huge costs of engineering changes in many industries justify such a transition to and investment in the advanced model of ECM. Acknowledgment The authors acknowledge the help of the many interviewees at the host Korean automobile company in conducting the case study and research survey.

Appendix A. Brief introduction to the AHP method used to calculate the weights of the ontologies We have O1, O2, ..., On as the criterion for which weight values should be calculated. Using the n criterion, an (n×n) matrix A can be defined where element aij of A is the experts’ preference of Oi over Oj when retrieving relevant

engineering change cases. It is also assumed that the elements of A adhere to the following rules: Rule 1. If aij =α, then aji =1/α, α≠0. Rule 2. If Oi is judged to be of equal relative importance as Oj, then aij =1, aji =1; in particular, aii =1 for all i. The final objective is to calculate the weight value wi for each ontology Oi. Using the above matrix, wi can be calculated using the following formula: wi ¼

n 1 X

lmax

aij wj ði ¼ 1; 2; :::; nÞ;

j¼1

where 1max is the maximum eigenvalue of matrix A (Saaty, 1980). A set of pair-wise comparisons of ontologies was collected from the experts in the target company using questionnaires. Matrix A was obtained by integrating the experts’ preferences as follows: Component Problem Process Product Solution

Component 1 0.179 0.147 0.288 0.836

Problem 5.593 1 0.164 0.342 0.585

Process 6.804 6.082 1 3.557 6.804

Product 3.476 2.924 0.281 1 2.327

Solution 1.197 1.71 0.147 0.43 1

392

Inf Syst Front (2006) 8:375–394

Consequently, we obtained the normalized weights of the ontologies:   wc ; wpb ; wpc ; wpd ; ws ¼ f0:447; 0:21; 0:035; 0:094; 0:214g The terms wc, wpb, wpc, wpd, and ws are the weights of the component, problem, process, product, and solution ontologies, respectively.

case are ‘Assembly’ and ‘Problem’ and the CCP is ‘Assembly’ because ‘Assembly’ is closer to ‘Screwing’ and ‘Fitting’ than ‘Problem.’ B.4 Definition of the compensation factor for reducing size effects (Inverse Concept Frequency) The compensation factor fi for Oi is defined as P fi ¼ log

Appendix B. Definition of the similarity measure B.1 Definition of ontologies Each ontology Oi is defined as a tree of concept nodes, Cki (k=1, 2, ...). (Note that when designating a specific ontology, we use the terms Opd, Opb, Opc, Oc, and Os for the product, problem, process, component, and solution ontologies, respectively.)

N ðOm Þ

m

N ðO i Þ

(Note that this measure is similar to the inverse document frequency (IDF) measure widely used in information retrieval [Salton & McGill, 1983].) B.5 Definition of the similarity between two engineering change cases The similarity between two cases, E1 and E2, is defined as P

B.2 Definition of an engineering change case An engineering change case Ej is defined as the set of concepts that correspond to the concepts in the ontologies,  i . e . , Ej ¼ akj akj 2 Opd [ Opb [ Opc [ Oc [ Os and k ¼ 1; 2; :::; number of concepts in the caseg. B.3 Definition of the similarity between two concepts in a single ontology

:

SimðE1 ; E2 Þ ¼

i

wi  fi  simi ðc1i ; c2i Þ P ; wi i

where c1i and c2i are the concepts of E1 and E2, respectively, defined in the Oi dimension, c1 ZE1, c2i Z E2, c1i ZOi, and c2i ZOi. References

The similarity between two concepts cpi and cqi in Oi is defined as (Resnik, 1999) 

sim cpi ; cqi



   Ej cri 2 Ej ; ¼  log N ðU Þ N

where cri is the closest common parent (CCP) to both cpi and cqi and U is the entire set of engineering change cases in the case base. N({Ej|cri ZEj}) is the number of engineering change cases that belong to concept cri. The CCP represents a node in OI, which is the parent or ancestor of both of the two given concepts located closest to it. (Note that the numerator in the log term can become much smaller in large ontologies with greater depth and more concepts. For this reason, it is expected that the average value of the similarity is proportional to the size of an ontology.) For example, if we calculate a similarity value between the ‘Screwing’ and ‘Fitting’ concepts in the problem ontology in Fig. 6, the parents of the ‘Screwing’ concept are ‘Fixing,’ ‘Assembly,’ and ‘Problem,’ and the parents of the ‘Fitting’ concept are ‘Installation,’ ‘Assembly,’ and ‘Problem.’ Therefore, the common parents in this

Abecker, A., Bernardi, A., Hinkelmann, K., Kühn, O., & Sintek, M. (2000). Context-aware, proactive delivery of task-specific information: The knowmore project. Information Systems Frontiers, 2 (3/4), 253–276. Adler, P. S., & Clark, K. B. (1991). Behind the learning curve: A sketch of the learning process. Management Science, 37(3), 267–281. Agostini, A., De Michelis, G., & Grasso, M. A. (1997). Rethinking CSCW systems: The architecture of Milano. In Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, pp. 33–48. Ahn H. J., Lee, H. J., Cho, K. H., & Park, S. J. (2005). Utilizing knowledge context in virtual collaborative work. Decision Support Systems, 39, 563–582. Alavi, M., & Leidner, D. (2001). Knowledge management and knowledge management systems: Conceptual foundations and research issues. MIS Quarterly, 25(1), 107–136. Bergmann, R., & Schaaf, M. (2003). Structural case-based reasoning and ontology-based knowledge management: A perfect match? Journal of Universal Computer Science, 9(7), 608–626. Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic web. Scientific American; May. Broekstra, J., Kampman, A., & Harmelen, F. (2003). Sesame: A generic architecture for storing and querying RDF and RDF schema. In J. Davies, D. Fensel, & F. Harmelen (Eds.), Towards the semantic web: Ontology-driven knowledge management (pp. 71–89), West Sussex: Wiley.

Inf Syst Front (2006) 8:375–394 Chen, C., & Huang, C. (2001). A multiple criteria evaluation of hightech industries for the science-based industrial park in Taiwan. Information & Management, 41, 839–851. Clark K. B., & Fujimoto, T. (1991). Product development performance: Strategy, organization, and management in the world auto industry. Boston: Harvard Business School Press. Clark, K. B., & Wheelright, S. C. (1993). Managing new product and process development: Text and cases. New York: Free Press. Conklin, J., & Begeman, M. (1988). gIBIS: A hypertext tool for exploratory policy discussion. ACM Transactions on Office Information Systems, 6(4), 303–331. Decker, S., Mitra, P., & Melnik, S. (2000). Framework for the semantic web—an RDF tutorial. IEEE Internet Computing, 4(6), 68–73. Delteil, A., Faron-Zucker, C., & Dieng, R. (2001). Learning ontologies from RDF annotations. In Proceedings of the Second Workshop on Ontology Learning, p. 38. De Michelis, G., & Grasso, M. A. (1994). Situating conversation within the language/action perspective: The Milan Conversation Model. In Proceedings of the 5th Conference on CSCW, pp. 89–100. Golebiowska, J., Dieng-Kuntz, R., Corby, O., & Mousseau, D. (2001). Building and exploiting ontologies for an automobile project memory. In Proceedings of K-CAP’01, Victoria, October. Grant, R. (1996). Toward a knowledge-based theory of the firm. Strategic Management Journal, 17, 109–122. Grant, R. (1997). The knowledge-based view of the firm: Implications for management practice. Long Range Planning, 30(3), 450–454. Huang, G. Q., & Mak, K. L. (1998). Computer aids for engineering change control. Journal of Materials Processing Technology, 76, 187–191. Huang, G. Q., Yee, W. Y., & Mak, K. L. (2001). Development of a web-based system for engineering change management. Robotics and Computer Integrated Manufacturing, 17, 255–267. Huang, G. Q., Yee, W. Y., & Mak, K. L. (2003). Current practice of engineering change management in Hong Kong manufacturing industries. Journal of Materials Processing Technology, 139, 481–487. Jarvenpaa, S. L., & Leidner, D. E. (1999). Communication and trust in global virtual teams. Organization Science, 10(6), 791–815. Karvounarakis, G., Magkanaraki, A., Alexaki, S., Christophides, V., Plexousakis, D., Scholl, M., et al. (2003). Querying the semantic web with RQL. Computer Networks and ISDN Systems, 42(5), 617–640. Kolodner, J. (1993). Case-based reasoning. San Francisco, CA: Morgan Kaufmann Publishers. Loch, C. H., & Terwiesch, C. (1996). Accelerating the process of engineering change orders: Capacity and congestion effects. Journal of Product Innovation Management, 16, 145–159. Lorenzo, M. M. G., & Perez, R. E. B. (1997). A model and its different application to case-based reasoning. Knowledge-Based Systems, 9(7), 465–473. Maus, H. (2001). Workflow context as a means for intelligent information support. In Akman, V. et al (Eds.), CONTEXT 2001, LNAI, Vol. 2116, pp. 261–274. May, A., & Carter, C. (2001). A case study of virtual team working in the European automotive industry. International Journal of Industrial Ergonomics, 27, 171–186. May, A., Carter, C., & Joyner, S. (2000). Virtual team working in the European automotive industry: User requirements and a case study approach. Human Factors and Ergonomics in Manufacturing, 10(3), 273–289. Melnik, S. (2000). Representing UML in RDF. Available at http:// www-db.stanford.edu/~melnik/rdf/uml/. Melink, S., & Decker, S. (2000). A layered approach to information modeling and interoperability on the web. In Proceedings of ECDL’00 Workshop on the Semantic Web, Lisbon, Portugal, September.

393 Monplaisir, L. (1999). An integrated CSCW architecture for integrated product/process design and development. Robotics and Computer-Integrated Manufacturing, 15, 145–153. Nonaka, I., & Konno, N. (1999). The concept of “Ba”: Building a foundation for knowledge creation. California Management Review, 40(3), 40–54. Numata, J., & Taura, T. (1996). A case study: A network system for knowledge amplification in the product development process. IEEE Transactions on Engineering Management, 43(4), 356–367. Pikosz, P., & Malmqvist, J. (1998). A comparative study of engineering change management in three Swedish engineering companies. In Proceedings of DETC’98, Atlanta, GA, USA. Ramesh, B., & Tiwana, A. (1999). Supporting collaborative process knowledge management in New Product Development Teams. Decision Support Systems, 27, 213–235. RDF. Resource Description Framework, 1999. Available at http:// www.w3.org/TR/rec-edf-syntax/. RDFS. RDF Schema, 2000. Available at http://www.w3.org/TR/rdfschema/. Resnik, P. (1999). Semantic similarity in a taxonomy: An informationbased measure and its application to problems of ambiguity in natural language. Journal of Artificial Intelligence Research, 11, 95–130. Saaty, T. L. (1980). The analytic hierarchy process. New York: McGraw-Hill. Salton, G., & McGill, M. (1983). Introduction to Modern Information Retrieval. New York: McGraw-Hill. Terwiesch, C., & Loch, C. H. (1999). Managing the process of engineering change orders: The case of the climate control system in automobile development. Journal of Product Innovation Management, 16, 160–172. Wong, S., & Burton, R. M. (2000). Virtual teams: What are their characteristics, and impact on team performance? Computational and Mathematical Organization Theory, 6, 339–360. Wright, I. C. (1997). A review of research into engineering change management: Implications for product design. Design Studies, 18, 33–42. Yoo, S. B., & Kim, Y. (2002). Web-based knowledge management for sharing product data in virtual enterprises. International Journal of Production Economics, 75, 173–183.

Hong Joo Lee is a post doctoral fellow at the Sloan School of Management, Massachusetts Institute of Technology. He received his M.S. and Ph.D. degrees in 1999 and 2006, respectively, from the Graduate School of Management at Korea Advanced Institute of Science and Technology (KAIST). His research areas are recommendation systems, intelligent information systems, and virtual collaboration and knowledge management.

Hyung Jun Ahn is a Senior Lecturer at Waikato Management School at the University of Waikato, New Zealand. He received his Ph.D. from the Graduate School of Management at Korea Advanced Institute of Science and Technology (KAIST) in 2004. His main research interests include multi-agent systems, intelligent information systems, and e-supply chain management.

394 Jong Woo Kim is an associate professor of information systems at the School of Business, Hanyang University, Seoul, Korea. He received his M.S. and Ph.D. degrees in 1991 and 1995, respectively, from the Department of Management Science, the Department of Industrial Management at Korea Advanced Institute of Science and Technology (KAIST), Korea. His current research interests include intelligent information systems, e-commerce recommendation systems, data mining applications, and business process modeling and integration.

Inf Syst Front (2006) 8:375–394 Sung Joo Park is a Professor of Information Systems at the KAIST Graduate School of Management in Seoul, Korea. He holds a B.S. degree in Industrial Engineering from the Seoul National University, an M.S. in Industrial Engineering from the Korea Advanced Institute of Science, and a Ph.D. in Systems Science from the Michigan State University. He has been a senior researcher at the Software Development Center, KIST, and a professor at the KAIST since 1980. His areas of research interests include intelligent information systems and the application of agent technology to management decision-making.