Capturing and Reusing Knowledge

8/20/2019 Capturing and Reusing Knowledge

1/20

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 frequentlyrequire 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

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 pro-

cesses. Studies have found that engineering changes for

complex products are often performed by heterogeneous

teams in distributed environments, where knowledge-

Inf Syst Front (2006) 8:375 – 394

DOI 10.1007/s10796-006-9009-0

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


2/20

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 re-

trieval 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, decision-

making, 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 accumu-

lation and reuse of the knowledge generated in collaborative

engineering change processes. We investigated the engi-

neering 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 pro-

cesses. The collaboration model is also used as a knowledge

annotation schema along with a Semantic Web (Berners-

Lee, 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 modeland 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 adevelopment 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. Al-

though 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)

Poor communication 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

Snowballing change 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 Cost savings (Clark & Fujimoto, 1991; Clark & Wheelright, 1993)

Change, replacement, withdrawal, and introduction of a part (Pikosz & Malmqvist, 1998)

Ease of manufacturing Difficulties in parts fabrication or assembly (Pikosz & Malmqvist, 1998)

Product performance improvement 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)

376 Inf Syst Front (2006) 8:375 – 394


3/20

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.

& 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 knowl-

edge sharing and transfer between team members critical.

Hence, support systems for ECM should be designed to

reduce the complexity of the process and to facilitate virtualcollaborations and knowledge management.

2.2 Computer-aided ECM systems

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 manage-

ment (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 collabora-

tive 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)

Product complexity 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)

Ad hoc activities 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 environment 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)

Knowledge intensiveness Creativity and innovation are highly required (Adler & Clark, 1991)

High reuse the information is necessary (Pikosz & Malmqvist, 1998)

ECRForm

ECREvaluation

Form

ECOForm

Problem

Detection

Identifying

Problem Scope

Generating

Alternatives

Approval

Process

Engineering

Change Log

ReferenceReference

Fig. 1 The process of engineering change management

Inf Syst Front (2006) 8:375 – 394 377


4/20

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 knowl-

edge management (KM) systems for product development

that are intended to capture process knowledge and toshare 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 develop-

ment 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 demon-

strate the use of typical KM functions for ECM, but they

are still limited in organizing and sharing product knowl-

edge 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 responsiblefor 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 distrib-

uted globally in 14 plants and six R&D centers. Product

engineering activities are closely related to concept gener-

ation, 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, anda 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 successful-

ly. 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 toinitiate 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 possibleerrors 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

378 Inf Syst Front (2006) 8:375 – 394


5/20

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 accumu-

lation 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 orga-

nized by product category, component modules, and part

information. The intranet system does not provide suffi-

cient 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 engineer-ing 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

Fig. 2 The process of engineering change

Inf Syst Front (2006) 8:375 – 394 379


6/20

fault. Hence, they often tried to handle the changes quickly

using off-line collaboration without using excessive, time-

consuming paperwork. This made it difficult to capture the

tacit knowledge embedded in the collaboration and pre-

venting 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.

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 accumula-

tion 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-

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 mecha-

nism 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

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 manage-

ment 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 theengineering change process as follows. The organizational

perspective explicitly defines and supports the life cycle of

virtual teams that involves organizing the virtual engineer-

ing 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 manage-

ment to a knowledge repository and preserve the rich

CollaborationModel

Collaborative Environment

for ECM (CECM)

Collaboration

Support:Routine and Non-routine

collaboration

Knowledge Management:Ontology, Case-Based

Reasoning, andSemantic Web

Fig. 3 Overview of the approach

380 Inf Syst Front (2006) 8:375 – 394


7/20

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 genera-

tion and accumulation of knowledge; setting, coordinating,

and reaching milestones of activities are also associatedwith knowledge creation so that additional efforts at

collecting knowledge can be minimized. Thus, the pro-

posed 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).

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 complet-

ing 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 conversa-

tions, can also be associated with the activity entity.

4.1.2 Conversation

A conversation is a set of structured messages based on

speech-act theory for supporting cooperative processes

(Agostini, De Michelis, & Grasso, 1997; Delteil, Faron-

Zucker, & 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 asECRs, ECOs, and interim or final reports of an engineering

change activity. In contrast, the discussion entity was de-

signed to broadly represent unstructured communications

between actors, and is associated with activity, document,

and conversation entities.

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 discus-

sions, is explicitly associated with its creation context, which

ActivityProcess

ConversationActor DocumentDiscussion

KnowledgeItem

Role

1

Milestone

1

Concept

0..*

.

1

.

1

.

0

.1

Ontology

1 p ar

t i c i p a t e s

pertains to

o

wn s

b el on g s t o

produces

initiates

p e r f o

r m s h a s

is related with

coordinates

refers

h o

l d s

includes

containsKnowledge

Contex t

is super of

possesses

ScheduleEvent

preserves

Fig. 4 The collaboration model

Inf Syst Front (2006) 8:375 – 394 381


8/20

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, conver-

sations, 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 engineer-

ing 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 descrip-

tions, 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 problem-

solving 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 knowl-

edge items through the links provided by the knowledge

context of a given knowledge item.

(2) System-independent representation of knowledge: Se-

mantic 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 withRDFS 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 ill-

structured 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 compo-

nents makes the experts’ subjective weighting almost

382 Inf Syst Front (2006) 8:375 – 394


9/20

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

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 theontologies was collected from the experts in the case

company using questionnaires. The result of the AHP

calculation is presented in Fig. 6.

0.447

0.21

0.035

0.094

0.214

0 0.1 0.2 0.3 0.4 0.5

Component

Problem

Process

Product

Solution

Normalized Weights

Fig. 6 Weights of the five

ontologies

…

…

…

…

…

…

…

…

…

…

…

Engineering Change Case

Relevant CasesCase information

-Product-Component

-Process

-Problem

-Solution

Activity information

-Activity hierarchy

-Subordinated items

Related Document

-Milestone

-Preparation material

Related Discussion

-Discussed articles

-Decision making history

Related Activities & Items

Case Based Reasoning

Knowledge

Context

Fig. 5 Knowledge context and

navigation paths

Inf Syst Front (2006) 8:375 – 394 383


10/20

The final similarity measure between two engineering

change cases, E1 and E2, is given in formula (1) (see

Appendix B).

Sim E 1; E 2ð Þ ¼

Pi

wi f i simi c1i; c2ið ÞP

i

wi; ð1Þ

where wi is the weight of ontology i calculated using theAHP, f i 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 E 1 and E 2 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 pro-

duct 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 con-cepts of case 2. The table in the lower part of Fig. 8 shows

how each concept in the different ontologies is used to cal-

culate 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 pro-

vides 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 propor-tional to the size of a given ontology (see Appendix B). The

sixth column contains the weights of the ontologies calcu-

lated using the AHP.

This CBR method has the following additional advan-

tages 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 solu-

tions 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

Problem ontology Component ontology

p=0.3info = 1.2039

Assembly

Screwing

ResistanceFixing Installation Implementation

Clipp ing Stapl ing Coupl ing F it ting

p=0.3info = 1.2039

p=0.1info = 2.3025

p=0.05info = 2.9957

p=0.03info = 3.5065

p=0.001info = 6.9077

p=0.049info = 3.0159

Problemp=1

info = 0

Performancep=0.2info = 1.6094

Component

Axle Steering

Suspension Axle

Mechanism

Chassis

Pedal

FrontSuspension

RearSuspension

p=1info = 0

p=0.4

info = 0.9162

p=0.2info = 1.6094

p=0.05info = 2.9957

p=0.1info = 2.3025

Engine

p=0.2info = 1.6094

ClimateControl

p=0.1info = 2.3025

Brake

p=0.5

info = 0.6931

Vehicle

Passenger Car SUV

Compact Midsize

Car

Van

A3 X7

p=1info = 0

p=0.7

info = 0.3566

p=0.05info = 2.9957

p=0.1info = 2.3025

Bus Truck

Fullsize

Product ontology

Luxury

X8X6X5M4

Process ontology

Process

Prototype #1

Pilot

p=1

info = 0

Engineering Manufacturing

p=0.1info = 2.3025

p=0.2info = 1.6094

Prototype

Prototype #2 Assembly Planning Pilot Production

p=0.05info = 2.9957

p=0.03info = 3.5065

Fig. 7 Parts of ontologies

384 Inf Syst Front (2006) 8:375 – 394


11/20

remain valid for a long time and not require frequent updates.

Third, the similarity measures can be calculated automati-

cally 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

..

X8

L2.0

2003

Europe

FrontSuspension

F301

Screwing

Pilot production

…

..

X67

F2.0

2000

Asia

FrontSuspension

F102

Fitting

Pilot production

…

-

0.9678

0.9098

0.3358

0.5118

0.214---Solution

0.0352.3025Pilot productionYesProcess

0.0942.3025LuxuryNoProduct

0.4472.9957Front SuspensionYesComponent

0.211.2039AssemblyNoProblem

Maximum

Similarity

Value

Closest Common

Parent

Identical

wi,

weight of

ith

ontology

Similarity between conceptsOntology

0864.1

035.0094.0447.021.0

3025.29678.0035.03025.29098.0094.09957.23358.0447.02039.15118.021.0

=

+++

xx +xx+xx +x x=Similarity

i f

Product

Component

Problem

Process

Case 1 Case 2

Fig. 8 Similarity calculation between cases

Inf Syst Front (2006) 8:375 – 394 385


12/20

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 changecase retrieval using the following methods: concept-based

retrieval (i.e., process-based, problem-based, and compo-

nent-based retrievals), ontology-based retrieval, and key-

word-based retrieval.

& 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 engineer-

ing 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 ontol-

ogies. This mechanism uses formula (1) to calculate the

similarity and weight values described in Fig. 6.

& Keyword-based retrieval : The basic concept of keyword-

based 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

keyword-based retrieval (Salton & McGill, 1983). They

represent each object as a vector of features in a k -

dimensional space and compute similarity using mea-

sures such as the cosine or Euclidian distance. We

extracted keywords from all the cases and eliminated

keywords with a low term frequency-inverse document

Ontology

Workspace Management

ActorManagement

DocumentManagement

DiscussionManagement

MilestoneManagement

CECM

Process support system

C onv er s a t i on

s u p p or t

Knowledge

Repository

Delivery

Query

OntologyManagement

Activity Management

Role

Management

ApprovalRouting

Reasoned

SpecifiedStored &Retrieved

Inde xing

Case Base

Fig. 9 Architecture of CECM

Table 3 Average similarities

between retrieval methods

a Significant at alpha = 0.05 b Significant at alpha = 0.10

N Average similarities Standard deviation (1) (2) (3) (4)

(1) Process-

based

70 2.652381 0.9683 –

(2) Problem-

based

70 2.761905 1.2176 0.404 –

(3) Component-

based

70 2.828571 0.9975 0.205 0.668 –

(4) Ontology-

based

70 3.185714 0.7773 0.000a 0.013a 0.013a –

(5) Keyword-

based

70 2.914286 0.9439 0.025a 0.246 0.545 0.073 b

386 Inf Syst Front (2006) 8:375 – 394


13/20

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 theautomobile 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 be-

tween 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 thevalues 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

component-based) at the 0.05 significance level. In addi-

tion, 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 imple-

mented, 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 func-

tions to manage engineering change operations, such as

processes, activities, conversations, documents, actors,

discussions, and schedules. The knowledge repository

enables the representation of engineering change experi-ence 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.

Fig. 10 Process and activity

management

Inf Syst Front (2006) 8:375 – 394 387


14/20

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 theactivity 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

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,

Fig. 11 Initiating an ECR

388 Inf Syst Front (2006) 8:375 – 394


15/20

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 knowl-

edge 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 informa-

tion 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 workflow-

bas ed ECM sys tem, sin ce eng ine ering cha nges are

requested after engineers discuss problems informally. The

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 ideasfor 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 non-

routine. Routine activities are related to the approval

processes involved in engineering change management, such

as initiating an engineering change request, evaluating therequested change, and issuing engineering change orders.

Users can define any activities used to perform collab-

orative tasks, such as proposing alternatives and identifying

the scope of the problem. These activities can be decom-

posed into sub-activities with participants, documents,

discussions, milestones, and conversations.

Fig. 12 Knowledge delivery

Inf Syst Front (2006) 8:375 – 394 389


16/20

5.6 Closing the workspace

After the engineers come up with the final solution, it

h as to b e app ro ved b y man ag emen t o r 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, evolu-

tionary 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 knowl-

edge 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 perfor-

mance 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,

Fig. 13 Knowledge context of

the past case

390 Inf Syst Front (2006) 8:375 – 394


17/20

knowledge-intensive, and costly as well. Such domains

may include consumer electronics, motorcycle manufac-

turers, 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 conductingthe 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 O j 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 a ji=1/ α , α ≠0.

Rule 2. If Oi is judged to be of equal relative importance as

O j , then aij =1, a ji=1; in particular, a ii=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 ¼ 1

lmax

Xn

j ¼1

aij w j i ¼ 1; 2; :::; nð Þ;

where 1max is the maximum eigenvalue of matrix A (Saaty,

1980).

A set of pair-wise comparisons of ontologies wascollected 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 5.593 6.804 3.476 1.197

Problem 0.179 1 6.082 2.924 1.71

Process 0.147 0.164 1 0.281 0.147

Product 0.288 0.342 3.557 1 0.43

Solution 0.836 0.585 6.804 2.327 1

Fig. 14 Evolution of an ECR

Inf Syst Front (2006) 8:375 – 394 391


18/20

Consequently, we obtained the normalized weights of

the ontologies:

wc; w pb; w pc; w pd ; w s

¼ 0:447; 0:21; 0:035; 0:094; 0:214f g

The terms wc, w pb, w pc, w pd , and w s are the weights of the

component, problem, process, product, and solution ontol-

ogies, respectively.

Appendix B. Definition of the similarity measure

B.1 Definition of ontologies

Each ontology Oi is defined as a tree of concept nodes, C ki(k =1, 2, ...). (Note that when designating a specific

ontology, we use the terms O pd , O pb, O pc, Oc, and O s for

the product, problem, process, component, and solution

ontologies, respectively.)

B.2 Definition of an engineering change case

An engineering change case E j is defined as the set of

concepts that correspond to the concepts in the ontologies,

i . e . , E j ¼ akj akj 2 O pd [ O pb [ O pc [ Oc [ O s and k ¼

1; 2; :::; number of concepts in the caseg.

B.3 Definition of the similarity between two concepts

in a single ontology

The similarity between two concepts c pi and cqi in Oi is

defined as (Resnik, 1999)

sim c pi; cqi

¼ log N E j cri 2 E j

N U ð Þ ;

where cri is the closest common parent (CCP) to both c piand cqi and U is the entire set of engineering change cases

in the case base. N ({ E j |criZ E j }) is the number of

engineering change cases that belong to concept cri. The

CCP represents a node in O I , 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,’ ‘Assem-

bly,’ and ‘Problem.’ Therefore, the common parents in this

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 f i for Oi is defined as

f i ¼ log

Pm

N Omð Þ

N Oið Þ :

(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, E 1 and E 2, is defined as

Sim E 1; E 2ð Þ ¼

Pi

wi f i simi c1i; c2ið Þ

Pi

wi;

where c1i and c2i are the concepts of E 1 and E 2,

respectively, defined in the Oi dimension, c1Z E 1, c2iZ

E 2, c1iZOi , and c2iZOi .

References

Abecker, A., Bernardi, A., Hinkelmann, K., Kühn, O., & Sintek, M.

(2000). Context-aware, proactive delivery of task-specific infor-

mation: 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 Cooper-

ative 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 andknowledge 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.

392 Inf Syst Front (2006) 8:375 – 394


19/20

Chen, C., & Huang, C. (2001). A multiple criteria evaluation of high-

tech industries for the science-based industrial park in Taiwan.

Information & Management, 41, 839 – 851.

Clark K. B., & Fujimoto, T. (1991). Product development perfor-

mance: 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 inthe 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 Manufac-

turing, 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.

Monplaisir, L. (1999). An integrated CSCW architecture for integrated

product/process design and development. Robotics and Comput-

er-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 pro-

cess. IEEE Transactions on Engineering Management, 43(4),

356 – 367.

Pikosz, P., & Malmqvist, J. (1998). A comparative study of

engineering change management in three Swedish engineer-

ing 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/rdf-

schema/ .

Resnik, P. (1999). Semantic similarity in a taxonomy: An information-

based 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 Innova-

tion 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 recommen-

dation systems, intelligent information systems, and virtual collabora-tion 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.

Inf Syst Front (2006) 8:375 – 394 393

http://www-db.stanford.edu/~melnik/rdf/uml/http://www-db.stanford.edu/~melnik/rdf/uml/http://www.w3.org/TR/rec-edf-syntax/http://www.w3.org/TR/rec-edf-syntax/http://www.w3.org/TR/rdf-schema/http://www.w3.org/TR/rdf-schema/http://www.w3.org/TR/rdf-schema/http://www.w3.org/TR/rdf-schema/http://www.w3.org/TR/rec-edf-syntax/http://www.w3.org/TR/rec-edf-syntax/http://www-db.stanford.edu/~melnik/rdf/uml/http://www-db.stanford.edu/~melnik/rdf/uml/


20/20

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 sys-

tems, data mining applications, and business process modeling and

integration.

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 Develop-

ment 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.

394 Inf Syst Front (2006) 8:375 – 394

Documents

Capturing and Reusing Knowledge