Capturing and reusing knowledge in engineering changemanagement: 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 asautomobiles, involves engineering changes that frequentlyrequire redesigning or altering the products. Although it hasbeen found that efficient management of knowledge andcollaboration in engineering changes is crucial for thesuccess of new product development, extant systems forengineering changes focus mainly on storing documentsrelated to the engineering changes or simply automating theapproval processes, while the knowledge that is generatedfrom collaboration and decision-making processes may notbe captured and managed easily. This consequently limitsthe use of the systems by the participants in engineeringchange processes. This paper describes a model forknowledge management and collaboration in engineeringchange processes, and based on the model, builds aprototype system that demonstrates the models strengths.We studied a major Korean automobile company to analyzethe automobile industrys unique requirements regarding

engineering changes. We also developed domain ontologiesfrom the case to facilitate knowledge sharing in the designprocess. For achieving efficient retrieval and reuse of pastengineering changes, we used a case-based reasoning(CBR) with a concept-based similarity measure.

Keywords Automobile development . Case-basedreasoning . Engineering change management . Knowledgecapturing . Knowledge reuse . Semantic web

1 Introduction

Engineering changes involve the modification of productsand components that occur after the product design isreleased (Clark & Fujimoto, 1991; Huang, Yee, & Mak,2003; Terwiesch & Loch, 1999). Development processesfor complex products usually involve many engineeringchanges, which mostly reflect technological advances,resolve defects in the design, and improve the overallquality of the products (Adler & Clark, 1991; Pikosz &Malmqvist, 1998; Terwiesch & Loch, 1999). Engineeringchanges are considered inevitable, especially for complexproducts, because product development usually takes a longtime and involves collaboration among designers andengineers who are often geographically distributed (Huanget al., 2003).

In order to reduce the development cost and timerequired to produce a new product, many researchers andpractitioners are interested in the efficient management ofknowledge and collaboration in engineering change pro-cesses. Studies have found that engineering changes forcomplex products are often performed by heterogeneousteams in distributed environments, where knowledge-

Inf Syst Front (2006) 8:375394DOI 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, USAe-mail: hongjoo@mit.edu

H. J. AhnManagement Systems, Waikato Management School,University of Waikato, Gate 1 Knighton Road,Private Bag 3105, Hamilton, New Zealand

J. W. KimSchool of Business, Hanyang University, 17, Haengdang-dong,Seongdong-gu, Seoul 133-791, South Korea

S. J. ParkGraduate School of Management,Korea Advanced Institute of Science and Technology,207-43, Cheongryangri-dong, Dongdaemun-gu,Seoul 130-722, South Korea

intensive collaboration and communication for variousproblem-solving and decision-making are essential (Alavi& Leidner, 2001; Grant, 1996). However, existing systemsthat support engineering change management (ECM) aremostly limited to the simple issuing and approval ofengineering change orders (ECOs) through workflowmanagement systems or storage and keyword-based re-trieval of engineering change documents, which makes itdifficult to capture and reuse the informal, unstructuredknowledge inherent in engineering change processes. Forthis reason, a huge part of the valuable knowledge that hasbeen generated during the past collaborations, decision-making, and from the contextual relationships betweendifferent types of knowledge can be lost, which oftenresults in limited use of the systems. Since much of theengineering change knowledge are tacit and unstructured, itis very inefficient to use the existing support systems forsharing the knowledge among the designers and for solvingproblems (Ahn, Lee, Cho, & Park, 2005; Grant, 1997;Nonaka & Konno, 1999).

The purpose of this paper is to develop a model andprototype support system for ECM to facilitate the accumu-lation and reuse of the knowledge generated in collaborativeengineering change processes. We investigated the engi-neering change processes of a major Korean automobilecompany to determine the requirements of ECM for aspecific industry. Then, a collaboration model was designedto support the geographically distributed designers anddecision-makers involved in the engineering change pro-cesses. The collaboration model is also used as a knowledgeannotation schema along with a Semantic Web (Berners-Lee, Hendler, & Lassila, 2001) language, so that knowledgeitems in ECM can accumulate naturally through theprocess, and contextual knowledge can also be capturedeasily. Domain ontologies are also developed to representthe knowledge context. To efficiently retrieve and reuse

past cases of engineering change, a case-based reasoning(CBR) technique is used with the concept-based similaritymeasure (Resnik, 1999). A prototype ECM system isimplemented 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 3describes a case study of the ECM practices in a Koreanautomobile company. Section 4 describes the derived modeland examples of knowledge accumulation and retrieval.Section 5 presents the prototype system, which is calledCECM (Collaborative environment for Engineering ChangeManagement). Section 6 discusses the implications of thisstudy 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 performanceimprovements are brought into the project in the form ofengineering changes (Clark & Fujimoto, 1991; Clark &Wheelright, 1993; Terwiesch & Loch, 1999). Table 1summarizes 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 onesefforts on simply eliminating the engineering changes (Clark& Fujimoto, 1991). Consequently, it is more important tomanage the engineering change processes efficiently toreduce the time and cost of product development.

The formal process of an engineering change usuallyconsists 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:375394

the ECR, issuing engineering change orders (ECOs) torelevant participants, and storing and analyzing the ECOsfor management purposes (Fig. 1).

Based on the four-stage model, the characteristics oftypical engineering change management processes andassociated 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 inengineering changes usually involve a high level ofcomplexity. Complexity in processes requires iterativecommunication and collaboration to adjust the engineeringchanges. Complexity in products incurs snowballing effectwhen a change in a single part is propagated to numerousrelated parts or products, which often contributes to longECO lead times (Terwiesch & Loch, 1999).

& Virtual collaboration: Today, engineering changes for acomplex product like an automobile usually involve thecollaboration of virtual design teams, which operate in ageographically distributed or global environment.

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

Hence, support systems for ECM should be designed toreduce 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 onstand-alone computer-aided systems for storing and retrievingengineering change documents (Huang et al., 2001; Wright,1997) to replace paper-based ECM. In some companies, theengineering changes are managed by configuration manage-ment (CM) systems which focus on how products areconfigured and changed (Huang & Mak, 1998).

Recently, ECM systems based on workflow systemshave been proposed (Huang & Mak, 1998; Huang et al.,2001) that provide a wide set of functionalities forsupporting the entire engineering change process. Theyallow employees to issue and approve engineering changerequests, track the change status, and manage the relateddocuments. Although the workflow-based systems managedocuments efficiently, they are still limited in their ability tocapture and reuse the knowledge involved in engineeringchanges. Important knowledge resources, such as contextinformation on knowledge items, collaborative experiences,and decision-making processes, are not contained in ECMsystems because the systems cannot incorporate collabora-tive change processes. Engineering change teams currentlydepend heavily on off-line collaboration without codifying

Table 2 Characteristics and problems in the engineering change process

Characteristics of engineeringchange 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 changessnowballing 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

ECR Evaluation

Form

ECOForm

ProblemDetection

IdentifyingProblem Scope

GeneratingAlternatives

Approval Process

EngineeringChange

Log

ReferenceReference

Fig. 1 The process of engineering change management

Inf Syst Front (2006) 8:375394 377

the knowledge explicitly. Consequently, knowledge reuse ispoor because of the insufficient management of pastexperience and is limited to searching by keywords orreference numbers and hence browsing categories.

In addition to workflow, other approaches exist forimplementing ECM systems. There are several knowl-edge management (KM) systems for product developmentthat 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 andTiwana focused on capturing process knowledge forcollaborative product-development tasks, and suggested amodel that represented concepts in product developmentalong with a concept map describing dependencies amongthe concepts (Ramesh & Tiwana, 1999), which is similar tothe 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 engineeringdesign teams can be enhanced further when the CSCWfunctions are augmented with integrated process develop-ment architecture (May et al., 2000; May & Carter, 2001;Monplaisir, 1999). Numata and Taura (1996) emphasizedcommunication among engineers participating in productdevelopment and suggested a knowledge network forenhancing the convenient transfer of knowledge amongengineers (Numata & Taura, 1996). These systems demon-strate the use of typical KM functions for ECM, but theyare still limited in organizing and sharing product knowl-edge manually so that contextual knowledge is usuallydifficult to capture.

3 Case study

3.1 Overview

As a case study, we investigated the new product developmentprojects of a major Korean automobile company. Data werecollected 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 newproduct development that were submitted as a result of thehost companys internal training program.

& Data analysis from a Web-based information system thatthe company uses to keep track of ECOs.

The companys 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. Productdevelopment teams use a workflow system to handleengineering changes in which a simple workflow instanceis defined as initiating ECRs, issuing and noticing ECOs,and approving ECOs. The companys Web-based intranetsystem 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 engineeringchange of an automobile component is handled successful-ly. When a problem is detected in a certain process, arequest is made for the engineering team or the engineer incharge of that automobile component to review theproblem. Through discussions among engineers and teammembers who detected the problem, they decide whether toinitiate an ECR. When a decision is made to initiate anECR, the team completes the ECR form using the workflowsystem. This form contains information on the product andautomobile components that need to be changed, and thereasons for and a description of the ECR. After theengineering team reviews the ECR, they decide to acceptor reject it. The status of an ECR can be tracked andmonitored by the person who made the request. Theassigned engineer identifies the causes of the problem andthe scope of the engineering change by communicatingwith related engineers. To generate alternative solutions tothe engineering change, they usually rely on their pastexperience and knowledge. In addition, they try to findsimilar situations from the intranet system, which stores theproblem and engineering change reports from past projects.Then, the engineer in charge issues an ECO that containsthe information from the ECR; changes in weights andproduction costs, the time when the engineering changeswill become effective, and the plans to handle obsoleteparts. If there is a change in the unit cost of a part, the ECOhas to be approved by the cost management departmentsimultaneously. After administrative approval, the ECOsare sent to the technology management team to validate theconsistency in the product design and to check for possibleerrors and inconsistencies. Then, the ECOs and associatedproduct data are released and stored in the intranet systemof the company.

3.3 Knowledge management practices

To derive the desired features of ECM, the ECM process ofthe automobile company is reviewed and analyzed from aknowledge-management perspective, emphasizing the four

378 Inf Syst Front (2006) 8:375394

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

& Knowledge Creation: Despite the knowledge-intensivenature of the engineering change process, there is noformal consideration of knowledge management relatedto ECM in the automobile company. An engineeringchange process is regarded as merely an instance of thecompanys workflow, and the resulting knowledge isembedded in separate documents. The current systemfails to capture the variety of knowledge associated withengineering changes. In addition, the knowledge createdin off-line collaboration is not incorporated in the currentworkflow system because the system does not provide away to link informal, unstructured knowledge with thestructured knowledge in workflows. The rigidity of thedocument form also limits the generation and accumu-lation of knowledge.

& Knowledge Storage/Retrieval: All ECRs and ECOs arestored automatically in the intranet system after theworkflow is finished. The engineering changes are orga-nized by product category, component modules, and partinformation. The intranet system does not provide suffi-cient support of the contextual knowledge which can beused to navigate for the relevant knowledge. The valuablelinks between a specific engineering change and relatedparts, products, problems, and solutions are not preservedin the system. Past engineering changes are retrieved using

a simple keyword-based search and browsing predefinedcategories of engineering changes.

& Knowledge Transfer: According to a company report onnew automobile development projects, one-third of allengineering change problems are not new. As a universalcharacteristic of automobile companies, product engineer-ing departments are highly compartmentalized according tothe models and functions of the automobiles. Knowledgerelated to the same problems in different components orthe same component in different models cannot betransferred easily.

& Knowledge Application: Since ECM systems merely storeminimal knowledge of engineering changes, valuableknowledge, such as difficulties in making changes andimportant decision-making issues, is lost. The engineersdepend mainly on their tacit knowledge of past experienceand off-line communications to solve the engineeringchanges at hand.

3.4 Findings from the case study

The engineering change process of an automobile companyis complex; it handles various types of knowledge, andrequires collaboration among distributed engineers. At theautomobile company of the case study, the engineers in theengineering department usually regarded engineeringchanges raised in the latter part of the development as their

Fig. 2 The process of engineering change

Inf Syst Front (2006) 8:375394 379

fault. Hence, they often tried to handle the changes quicklyusing off-line collaboration without using excessive, time-consuming paperwork. This made it difficult to capture thetacit knowledge embedded in the collaboration and pre-venting the use of similar cases in later stage. Even for theengineering cases preserved in the current system, thestored knowledge are not sufficient to capture the richrelationships between design knowledge items. The systemprovided access to the database via simple keyword-basedqueries and category-based browsing. These problems havelimited the accumulation of knowledge which led in turn toineffective and inefficient use of the system. Although theproblems found in the case study are specific to the targetorganization, we reasonably postulate that many of theproblems stem from the inherent complexity of generalengineering change processes.

4 The collaboration model for engineeringchange management

The objective of this research is to design a collaborativeenvironment for ECM (CECM) to facilitate the accumula-tion and use of knowledge amassed through the engineeringchange processes of the target organization as shown inFig. 3. The key points in the approach are as follows.

First, a model is developed that captures the nature of thecollaboration in engineering processes. The model tries tosupport both routine and non-routine collaboration toovercome the limitations of many workflow-based systemsthat only save form-based documents and use them inroutine workflow.

Second, the figure shows that the collaboration model isused for knowledge management functions of CECM aswell. The collaboration model plays an important role incapturing both general and contextual knowledge naturally,along with collaborative processes. In other words, it notonly provides a basis for collaboration support but also isused as a schema for knowledge representation for theCECM. Aligning knowledge management with collabo-

ration can be a very powerful method of supportingknowledge-intensive work in a distributed collaborativeenvironment.

Third, for the knowledge management functions, wedevelop ontologies, design a case-based reasoning mecha-nism for knowledge retrieval in CECM, and provideresource description framework (RDF)-based SemanticWeb representations of engineering change knowledge.The ontologies provide common representations of varioustypes of knowledge used for engineering processes, whichare used to create Semantic Web pages for knowledgesharing. Combining the case-based reasoning mechanismwith the ontologies is useful to retrieve engineering changecases in practice.

4.1 Design of the collaboration model for engineeringchange management

Since the engineering change process involves manyknowledge-intensive tasks performed in a distributedenvironment, we adopted the knowledge context model(KC-V) as a base model. The KC-V model was originallydeveloped to capture and to utilize contextual knowledge invirtual collaboration environments. The KC-V identifiesthree key perspectives of the modeling context in virtualenvironments: organization, activity, and context (Abecker,Bernardi, Hinkelmann, Khn, & Sintek, 2000; Jarvenpaa &Leidner, 1999; Maus, 2001; Wong & Burton, 2000). It hasbeen used to build a knowledge and collaboration manage-ment system for virtual work called the Virtual WorkgroupSupport System (VWSS) (Ahn et al., 2005). The mostdistinguishing feature of KC-V and VWSS is that theyintegrate collaboration with knowledge management, whenknowledge is captured naturally along with activities. Thecoordination and execution of activities naturally contributeto the accumulation of knowledge, and in doing so, theknowledge context is effectively preserved based on thecontext structure of the KC-V. Hence, we developed ourcollaboration model by refining the KC-V and reflectingunique characteristics of the problem domain as shown inFig. 4.

The three perspectives of the KC-V are applied to theengineering change process as follows. The organizationalperspective explicitly defines and supports the life cycle ofvirtual teams that involves organizing the virtual engineer-ing change teams, collaborating until the engineeringchange problems are solved, and disbanding the teamsafter the goals are reached. The activity perspectiveemphasizes the alignment of knowledge management andcollaborative activities. It tries to link the outputs of routineand non-routine activities of engineering change manage-ment to a knowledge repository and preserve the rich

CollaborationModel

Collaborative Environmentfor ECM (CECM)

CollaborationSupport:

Routine and Non-routinecollaboration

Knowledge Management:Ontology, Case-Based

Reasoning, andSemantic Web

Fig. 3 Overview of the approach

380 Inf Syst Front (2006) 8:375394

relationships among knowledge items so that they can beused as contextual knowledge. Instead of merely storingengineering change forms in a document base, for example,it can turn discussion messages into knowledge items;answering various workflow requests or ad hoc non-routineconversation 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 atcollecting knowledge can be minimized. Thus, the pro-posed system based on the KC-V is neither a collaborationsystem nor a knowledge management system but acombination of both that preserves the rich knowledgecontext. The third component, the context perspective,simply helps to organize the knowledge items by linkingentities of the organizational perspective and the activityperspective (Ahn et al., 2005).

4.1.1 Activity and process

A process can have hierarchically organized activities asshown in Fig. 4. It also has the life-cycle status of anengineering change process as an attribute. After complet-ing an engineering change, the entire set of knowledgeitems and the structure of the activities used in the processcan be stored in the knowledge repository, along with theknowledge context. Placed at the center of the model, theactivity is crucial for integrating knowledge items with aknowledge context. Knowledge items are associated withactivities via the knowledge context entity, and othercontext 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 onspeech-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, arecreated and the status of an associated activity or documentis updated. Conversation is a simplification of theCoordination construct in the KC-V model. This changewas made because the coordination construct in the KC-Vmodel was aimed at very broad types of coordination thatare not necessary for the engineering change process.

4.1.3 Two types of knowledge item: documentand discussion

The collaboration model supports two types of knowledgeitem: document and discussion entities. The document entityrepresents formal, structured documents and forms, such asECRs, ECOs, and interim or final reports of an engineeringchange activity. In contrast, the discussion entity was de-signed to broadly represent unstructured communicationsbetween actors, and is associated with activity, document,and conversation entities.

4.1.4 Knowledge context

The knowledge context entity defines the context of aknowledge item explicitly, as depicted in the Fig. 4. In thisway, each knowledge item, such as documents and discus-sions, is explicitly associated with its creation context, which

Activit yProcess

ConversationActor DocumentDiscussion

KnowledgeItem

Role

1

Milestone

1

Concept

0..*

.

1

.

1

.

0

.1

Ontology

1pa

rticipa

tes

pert ains t o

ow

ns

be

lon

gs to

produces

init iates

per fo

rms

has

is related w ith

coordinates

refers

hold

s

includes

cont ainsKnowledge

Contex t

is super of

possesses

ScheduleEvent

preserves

Fig. 4 The collaboration model

Inf Syst Front (2006) 8:375394 381

is centered on the activity entity within which the knowledgeitem was created. Through this explicitly defined knowledgecontext entity, the system can provide comprehensive linksto entities that are helpful for understanding individualknowledge items, such as related activities, actors, conver-sations, and milestones.

4.1.5 Ontology

The ontology construct in the collaboration model isderived from the domain construct of the KC-Vand is usedto retrieve past knowledge items reflecting the complexmultidimensional characteristics of the automobile industry.For an automobile development project, the followingdomain ontologies were identified as key dimensions(Golebiowska, Dieng-Kuntz, Corby, & Mousseau, 2001):

& Product ontology: a hierarchy of product segmentationsand their manifestations, such as passenger cars, recreationvehicles, 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 thatdescribes the causes of problems and reasons for engineer-ing changes, such as product safety and manufacturingdifficulties.

& Solution ontology: a hierarchy of solution types inengineering changes, such as product form modificationand assembly hole relocation.

& Process ontology: the structure of a new product developmentprocess and its hierarchy of activities in a project, such asplanning, styling, or pilot production stages.

Figure 7 shows examples of these ontologies.

4.2 Knowledge representation with the collaborationmodel and ontologies

The collaboration model can be a schema of knowledgeannotation used to define knowledge structure and validateknowledge in a knowledge management application. All ofthe constructs in the collaboration model are used toannotate the knowledge items, along with their contextinformation. Resource description framework schema(RDFS) is a schema-specification language developed forrepresenting the RDF statements (RDF, 1999; RDFS, 2000)used for the Semantic Web (Berners-Lee et al., 2001;Decker, Mitra, & Melnik, 2000; RDF, 1999). An RDFannotation consists of a set of statements, each onespecifying 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 thecollaboration model are generated. The RDF instances of

the domain ontologies are also used in defining a case.Consequently, the knowledge items in engineering changeprocesses are annotated using the RDF definitions foroutputs such as ECOs, modification results, and problem-solving reports.

The Semantic Web-based knowledge representationcombined with the collaboration model and domainontologies has the following advantages:

(1) Accumulation of knowledge context: As shown in Fig. 5,a knowledge annotation includes contextual informationof knowledge items, such as related activities, milestones,and actors. Users can navigate to other relevant knowl-edge items through the links provided by the knowledgecontext of a given knowledge item.

(2) System-independent representation of knowledge: Se-mantic Web technology such as RDF enables us to enrichknowledge by annotating or giving its meaning with tagsdefined in the ontologies. The structure and meaning ofRDF statements can be identified by other systems withRDFS and associated ontologies. For example, using RDFpages, it becomes easier for other systems, such as aproduct data management (PDM) system, to identify themeaning of engineering changes, such as related parts, thesource of problems, and problem-solving methods.

4.3 Knowledge reuse in engineering change management

Ontology-driven knowledge management answers queriesusing logical deduction based on ontologies (Broekstra,Kampman, Harmelen, & Sesame, 2003; Karvounarakiset al., 2003), but the strictness of deductive reasoning hasbeen 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 thestrictness by allowing the retrieval of knowledge items thatare 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) isdefined as an aggregate of the related components,processes, problems, products, and solutions that does notallow easy quantification for developing numerical distancemeasures. For example, to define the numerical distancebetween a 2.5 DOHC gasoline engine and a 2.0 dieselengine, one may have to rely on experts subjectiveopinions. Furthermore, the manually assigned weights andsimilarity measures can easily be outdated because of theintroduction of new products or new components. Inaddition, the large number of different parts and compo-nents makes the experts subjective weighting almost

382 Inf Syst Front (2006) 8:375394

impossible (Kolodner, 1993). In order to address thisproblem, the information-based measure of Resnik (1999),which measures concept similarities automatically, is adopted(Resnik, 1999). In addition, since an engineering changecase is defined using several different ontologies, properweights should be assigned to the ontologies depending ontheir relative importance in retrieving engineering changecases. For example, we need to determine the relative

importance of the process aspect of an engineeringchange case compared to the component aspect. Todetermine 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 casecompany using questionnaires. The result of the AHPcalculation 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 fiveontologies

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

KnowledgeContext

Fig. 5 Knowledge context andnavigation paths

Inf Syst Front (2006) 8:375394 383

The final similarity measure between two engineeringchange cases, E1 and E2, is given in formula (1) (seeAppendix B).

Sim E1;E2 Piwi fi simi c1i; c2i

Piwi

; 1

where wi is the weight of ontology i calculated using theAHP, fi is the factor used to reduce the effects of differentdepths in different ontologies (see Appendix B), and c1i andc2i represent the respective concepts of E1 and E2 inontology i.

As an illustration, consider the situation in Fig. 8. In thisexample, there are two engineering change cases; case 1 isan ECR and case 2 is an ECO, and these two cases areassociated with the ontologies in Fig. 7. Arrows are used toindicate comparison points between the two cases; the pro-duct concept in case 1 is compared to the product conceptin case 2. In addition, the component, problem, and processconcepts 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 (ClosestCommon Parent) shows the closest common parent betweentwo concepts in the two cases and the fourth column pro-vides the information value of the closest common parent inthe third column. The fifth column represents compensationvalues for reducing the size effect of ontologies because theaverage value of the information-based measure is propor-tional to the size of a given ontology (see Appendix B). Thesixth 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, diversefactors pertaining to engineering changes can be consideredto find similar cases of past engineering change. In thispaper, components, processes, problems, products, and solu-tions are reflected as the attributes of engineering changes.Second, although there can be frequent changes in individualitems in the ontology, it is unlikely that the relativeimportance of the ontologies will change markedly overtime. Therefore, once AHP weights are calculated, they will

Problem ontology Component ontology

p=0.3info = 1.2039

Assembly

Screwing

ResistanceFixing Installation Implementation

Clipping Stapling Coupling Fitting

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 AxleMechanism

Chassis

Pedal

FrontSuspension

RearSuspension

p=1info = 0

p=0.4info = 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.5info = 0.6931

Vehicle

Passenger Car SUV

Compact Midsize

Car

Van

A3 X7

p=1info = 0

p=0.7info = 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=1info = 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:375394

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 humanintervention. This automatic calculation keeps the cost ofexpanding the case base for new products and componentslow. Finally, the retrieval mechanism can be flexible andaccommodate new types of ontologies when users wish to

include additional dimensions to engineering change casesfor new organizational strategies or practices.

4.4 Performance analysis of case retrieval

To test the feasibility of the proposed CBR method, wecollected 261 ECRs from previous past development

..

X8L2.02003Europe

FrontSuspension F301

Screwing

Pilot production

..

X67F2.02000Asia

FrontSuspensionF102

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

MaximumSimilarity

Value

Closest Common Parent

Identical

wi, weight of

ith

ontology

Similarity between conceptsOntology

0864.1035.0094.0447.021.0

3025.29678.0035.03025.29098.0094.09957.23358.0447.02039.15118.021.0

= + ++

xx + xx+ xx + x x= Similarity

if

Product

Component

Problem

Process

Case 1 Case 2

Fig. 8 Similarity calculation between cases

Inf Syst Front (2006) 8:375394 385

projects of the automobile company. Since the engineeringchange cases collected were ECRs, this analysis could notuse a solution ontology. Through discussion and interactionwith the engineers at the company, four domain ontologieswere built using Protg, an ontology editor used to buildSemantic Web content. We simulated engineering changecase retrieval using the following methods: concept-basedretrieval (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 issimilar to sorting through categorized engineeringchanges using concepts, such as engineering changesmade to the same component or ones caused by thesame problem.

& Process-based retrieval: This mechanism searches forpast engineering change cases that took place during thesame product development process as the target case,and retrieves the recent cases.

& Problem-based retrieval: This mechanism searches forpast engineering change cases that took place becauseof the same problem as the target case, and retrieves therecent cases.

& Component-based retrieval: This mechanism searches forcases of past engineering change in the same engineer-ing component as the target case. Engineers browsecomponent hierarchies to find relevant cases. Forexample, engineering changes in the form or relocationof a heat protector to reduce interference with otherparts belong to the same component category.

& Ontology-based retrieval: As described in Section 4.3,the ontology-based retrieval mechanism determines thesemantic similarity between complex objects in ontol-ogies. This mechanism uses formula (1) to calculate thesimilarity and weight values described in Fig. 6.

& Keyword-based retrieval: The basic concept of keyword-based retrieval is to find engineering change cases thathave keywords similar to the target case. Vector spacemodels are very common in information retrieval and

keyword-based retrieval (Salton & McGill, 1983). Theyrepresent 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. Weextracted keywords from all the cases and eliminatedkeywords with a low term frequency-inverse document

Ontolo gy

Workspace Manageme nt

ActorManageme nt

DocumentManageme nt

DiscussionManageme nt

MilestoneManageme nt

CECM

Process support system

Co

nve

rsatio

n su

pp

ort

Knowledge Repository

DeliveryQuery

OntologyManageme nt

Activi ty Ma nageme nt

RoleManagement

ApprovalRouting

Reasoned

SpecifiedStored &Retr ieved

Inde xin g

Case Base

Fig. 9 Architecture of CECM

Table 3 Average similaritiesbetween retrieval methods

a Significant at alpha = 0.05b 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.073b

386 Inf Syst Front (2006) 8:375394

frequency (TF-IDF) (Salton & McGill, 1983). Weconstructed keyword vectors for each case and calculatedsimilarities between cases using the cosine measure.

The Korean automobile company that we studied usescomponent-based retrieval and simple keyword-basedsearch methods. To compare similarities between the caseretrieval mechanisms, we asked seven expert raters from theautomobile company to rank similarity values and to raterelevant cases. We provided ten randomly selected targetcases and retrieved the relevant cases using the five methods.Table 3 shows the average similarities as rated by theexperts.

The ontology-based retrieval method provided thegreatest average similarity. The average similarities be-tween the five methods were tested statistically usingrepeated measures ANOVA. Each pair within the fivemethods was compared. The null hypothesis was thataverage similarities resulting from the two methods wouldbe the same. Table 3 summarizes the comparisons, and thevalues in the cells indicate the significance level. Theaverage similarity of the ontology-based method wassignificantly higher than results for the other methods; theontology-based method had a higher average similarity thanthe three concept-based methods (process-, problem-, and

component-based) at the 0.05 significance level. In addi-tion, the ontology-based method had greater averagesimilarity than the keyword-based method at the 0.1significance level.

5 Collaborative environment for engineering changemanagement (CECM)

A prototype system called Collaborative environment forEngineering Change Management (CECM) was imple-mented, as shown in Fig. 9. CECM consists of threesubsystems: the engineering change process supportsystem, the knowledge repository, and the ontologymanagement. The process support system provides func-tions to manage engineering change operations, such asprocesses, activities, conversations, documents, actors,discussions, and schedules. The knowledge repositoryenables the representation of engineering change experi-ence and the retrieval of similar knowledge items.Annotations on knowledge items and knowledge contextare stored in the knowledge repository. The ontologymanagement provides functions to edit the existingontology and hierarchies of concepts.

Fig. 10 Process and activitymanagement

Inf Syst Front (2006) 8:375394 387

5.1 Engineering change process and activity execution

The process and activity management functions in CECMattempt to capture both formal and structured knowledge inworkflows, and informal and unstructured knowledge fromonline ad hoc collaboration. The functions also try to helpusers organize relevant knowledge in engineering changesaround the engineering change activities because theactivity is the key element of the knowledge context in themodel.

After detecting a problem in product development, aworkspace is created to handle the engineering changeprocess and to organize a temporary team with diversebackgrounds. In a workspace, routine activities forapproval are predefined, such as initiating an engineeringchange request, evaluating the requested change, andissuing engineering change orders, and users can defineany other activities according to their own needs. An

activity can be decomposed into sub-activities and canhave participants, documents, discussions, milestones, andconversations.

Figure 10 shows an example of a workspace concernedwith noise reduction on heat protector in the X8 car.Employees can organize a workspace according to thespecific requirements of an engineering change and onlinediscussion sessions can be created on the workspace thatenable the connection of informal knowledge and formaldocuments or outputs.

5.2 Initiating a draft of an ECR

A workspace in CECM generates a workflow for handlingengineering changes, as shown in Fig. 11, when a user fillsout the ECR form. Users can associate various types ofknowledge with workflow forms, such as documents,

Fig. 11 Initiating an ECR

388 Inf Syst Front (2006) 8:375394

discussions, and cases retrieved from the repository (see theRelating 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, similarECRs, ECOs, and knowledge can be delivered by theproactive execution of the CBR mechanism. Figure 12shows an example screen in which relevant past cases werelisted. The user can set the weights of the five ontologiesfor the CBR using two options: weights assigned by theuser or weights generated by the AHP (default weights).

When the user selects a relevant case, such as Noisereduction on climate control systems, the context informa-tion from the case is presented in the manner shown inFig. 13. The user can see the activities that created theknowledge, discussions, and associated decision-making.

5.4 Evolution of the engineering change document

ECRs and ECOs are the final outputs in the workflow-based ECM system, since engineering changes arerequested after engineers discuss problems informally. The

initial ECRs and ECOs in CECM are interim requests andevolve gradually through discussions and collaborativeactivities in the workspace. This mechanism of the earlyevolution of the change saves time and costs.

Figure 14 shows an example of a conversation leadingto revision of an ECR. If users want to revise the requestor the solutions to an engineering change case, they caninitiate a conversation process. They describe their ideasfor revision and reference entities, especially pastengineering change cases, using the conversation form.In this way, the evolutionary history of the documents isalso captured, together with the related discussions anddecision-making.

5.5 Collaborative activities

An activity can be divided into two types: routine and non-routine. Routine activities are related to the approvalprocesses involved in engineering change management, suchas 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 identifyingthe 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:375394 389

5.6 Closing the workspace

After the engineers come up with the final solution, ithas to be approved by management or the costmanagement department. The approval of the ECO isrouted automatically based on the scope of the change.Before closing the workspace, the workspace managercan rearrange the workspace by organizing knowledgeitems, removing redundant items and activities, andchanging the structure of the workspace for later use.Knowledge items in the workspace are stored with theircontextual 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 onthe integration of collaborative activities and knowledgemanagement throughout the lifecycle of engineeringchanges. A prototype ECM system called CECM was

developed based on the model to demonstrate itspractical feasibility.

There are several significant advantages of theproposed model. First, the model provides a basis forthe integration of informal and unstructured off-linecollaboration with structured online workflows so thatvaluable knowledge can be captured effectively incontext. Second, the collaboration model demonstratedhow Semantic Web technology can help represent andshare various types of engineering change-related knowl-edge in context. Five types of ontologies were developedfor the automobile industry, which can be extended ormodified for other industries. Third, in order to store,search, and retrieve engineering cases efficiently, theCBR technique was used along with the concept-basedsimilarity measure so that manual efforts in managing thecases could be minimized. A simple experiment showedthat the CBR-based mechanism provides greater perfor-mance in retrieving relevant cases compared with thekeyword-based search used in many existing ECMsystems.

The proposed model and system can be used in otherdomains where engineering change processes are complex,

Fig. 13 Knowledge context ofthe past case

390 Inf Syst Front (2006) 8:375394

knowledge-intensive, and costly as well. Such domainsmay include consumer electronics, motorcycle manufac-turers, and computer manufacturers.

Although many large-scale manufacturers are alreadyusing their own ECM systems and it may require a hugeinvestment to implement CECM, the suggested ECMmodel and CECM present a vision of an advanced ECMsystem for the future that utilizes next generation web andintelligent information technologies. We also believe thatthe huge costs of engineering changes in many industriesjustify such a transition to and investment in the advancedmodel of ECM.

Acknowledgment The authors acknowledge the help of the manyinterviewees at the host Korean automobile company in conductingthe case study and research survey.

Appendix A. Brief introduction to the AHP methodused to calculate the weights of the ontologies

We have O1, O2, ..., On as the criterion for which weightvalues should be calculated. Using the n criterion, an (nn)matrix A can be defined where element aij of A is theexperts preference of Oi over Oj when retrieving relevant

engineering change cases. It is also assumed that theelements of A adhere to the following rules:

Rule 1. If aij=, then aji=1/, 0.Rule 2. IfOi 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 foreach ontology Oi. Using the above matrix, wi can becalculated using the following formula:

wi 1lmaxXn

j1aijwj 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 usingquestionnaires. Matrix A was obtained by integrating theexperts preferences as follows:

Component Problem Process Product SolutionComponent 1 5.593 6.804 3.476 1.197Problem 0.179 1 6.082 2.924 1.71Process 0.147 0.164 1 0.281 0.147Product 0.288 0.342 3.557 1 0.43Solution 0.836 0.585 6.804 2.327 1

Fig. 14 Evolution of an ECR

Inf Syst Front (2006) 8:375394 391

Consequently, we obtained the normalized weights ofthe ontologies:

wc;wpb;wpc;wpd;ws

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

The terms wc, wpb, wpc, wpd, and ws are the weights of thecomponent, 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, Cki(k=1, 2, ...). (Note that when designating a specificontology, we use the terms Opd, Opb, Opc, Oc, and Os forthe product, problem, process, component, and solutionontologies, respectively.)

B.2 Definition of an engineering change case

An engineering change case Ej is defined as the set ofconcepts 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 conceptsin a single ontology

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

sim cpi; cqi log N Ej cri 2 Ej

N U ;

where cri is the closest common parent (CCP) to both cpiand cqi and U is the entire set of engineering change casesin the case base. N({Ej|criZEj}) is the number ofengineering change cases that belong to concept cri. TheCCP represents a node in OI, which is the parent orancestor of both of the two given concepts located closestto it. (Note that the numerator in the log term can becomemuch smaller in large ontologies with greater depth andmore concepts. For this reason, it is expected that theaverage value of the similarity is proportional to the size ofan ontology.) For example, if we calculate a similarity valuebetween the Screwing and Fitting concepts in theproblem ontology in Fig. 6, the parents of the Screwingconcept are Fixing, Assembly, and Problem, and theparents of the Fitting concept are Installation, Assem-bly, and Problem. Therefore, the common parents in this

case are Assembly and Problem and the CCP isAssembly because Assembly is closer to Screwingand Fitting than Problem.

B.4 Definition of the compensation factor for reducing sizeeffects (Inverse Concept Frequency)

The compensation factor fi for Oi is defined as

fi logPmN Om N Oi :

(Note that this measure is similar to the inverse documentfrequency (IDF) measure widely used in informationretrieval [Salton & McGill, 1983].)

B.5 Definition of the similarity between two engineeringchange cases

The similarity between two cases, E1 and E2, is defined as

Sim E1;E2 Piwi fi simi c1i; c2i

Piwi

;

where c1i and c2i are the concepts of E1 and E2,respectively, defined in the Oi dimension, c1ZE1, c2iZE2, c1iZOi, and c2iZOi.

References

Abecker, A., Bernardi, A., Hinkelmann, K., Khn, O., & Sintek, M.(2000). Context-aware, proactive delivery of task-specific infor-mation: The knowmore project. Information Systems Frontiers, 2(3/4), 253276.

Adler, P. S., & Clark, K. B. (1991). Behind the learning curve: A sketchof the learning process. Management Science, 37(3), 267281.

Agostini, A., De Michelis, G., & Grasso, M. A. (1997). RethinkingCSCW systems: The architecture of Milano. In Proceedings ofthe Fifth European Conference on Computer Supported Cooper-ative Work, pp. 3348.

Ahn H. J., Lee, H. J., Cho, K. H., & Park, S. J. (2005). Utilizingknowledge context in virtual collaborative work. DecisionSupport Systems, 39, 563582.

Alavi, M., & Leidner, D. (2001). Knowledge management andknowledge management systems: Conceptual foundations andresearch issues. MIS Quarterly, 25(1), 107136.

Bergmann, R., & Schaaf, M. (2003). Structural case-based reasoningand ontology-based knowledge management: A perfect match?Journal of Universal Computer Science, 9(7), 608626.

Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic web.Scientific American; May.

Broekstra, J., Kampman, A., & Harmelen, F. (2003). Sesame: Ageneric architecture for storing and querying RDF and RDFschema. In J. Davies, D. Fensel, & F. Harmelen (Eds.), Towardsthe semantic web: Ontology-driven knowledge management(pp. 7189), West Sussex: Wiley.

392 Inf Syst Front (2006) 8:375394

Chen, C., & Huang, C. (2001). A multiple criteria evaluation of high-tech industries for the science-based industrial park in Taiwan.Information & Management, 41, 839851.

Clark K. B., & Fujimoto, T. (1991). Product development perfor-mance: Strategy, organization, and management in the worldauto industry. Boston: Harvard Business School Press.

Clark, K. B., & Wheelright, S. C. (1993). Managing new product andprocess development: Text and cases. New York: Free Press.

Conklin, J., & Begeman, M. (1988). gIBIS: A hypertext tool forexploratory policy discussion. ACM Transactions on OfficeInformation Systems, 6(4), 303331.

Decker, S., Mitra, P., & Melnik, S. (2000). Framework for the semanticweban RDF tutorial. IEEE Internet Computing, 4(6), 6873.

Delteil, A., Faron-Zucker, C., & Dieng, R. (2001). Learningontologies from RDF annotations. In Proceedings of the SecondWorkshop on Ontology Learning, p. 38.

De Michelis, G., & Grasso, M. A. (1994). Situating conversation withinthe language/action perspective: The Milan Conversation Model.In Proceedings of the 5th Conference on CSCW, pp. 89100.

Golebiowska, J., Dieng-Kuntz, R., Corby, O., & Mousseau, D. (2001).Building and exploiting ontologies for an automobile projectmemory. In Proceedings of K-CAP01, Victoria, October.

Grant, R. (1996). Toward a knowledge-based theory of the firm.Strategic Management Journal, 17, 109122.

Grant, R. (1997). The knowledge-based view of the firm: Implicationsfor management practice. Long Range Planning, 30(3), 450454.

Huang, G. Q., & Mak, K. L. (1998). Computer aids for engineeringchange control. Journal of Materials Processing Technology, 76,187191.

Huang, G. Q., Yee, W. Y., & Mak, K. L. (2001). Development of aweb-based system for engineering change management. Roboticsand Computer Integrated Manufacturing, 17, 255267.

Huang, G. Q., Yee, W. Y., & Mak, K. L. (2003). Current practice ofengineering change management in Hong Kong manufacturingindustries. Journal of Materials Processing Technology, 139,481487.

Jarvenpaa, S. L., & Leidner, D. E. (1999). Communication and trust inglobal virtual teams. Organization Science, 10(6), 791815.

Karvounarakis, G., Magkanaraki, A., Alexaki, S., Christophides, V.,Plexousakis, D., Scholl, M., et al. (2003). Querying the semanticweb with RQL. Computer Networks and ISDN Systems, 42(5),617640.

Kolodner, J. (1993). Case-based reasoning. San Francisco, CA:Morgan Kaufmann Publishers.

Loch, C. H., & Terwiesch, C. (1996). Accelerating the process ofengineering change orders: Capacity and congestion effects.Journal of Product Innovation Management, 16, 145159.

Lorenzo, M. M. G., & Perez, R. E. B. (1997). A model and itsdifferent application to case-based reasoning. Knowledge-BasedSystems, 9(7), 465473.

Maus, H. (2001). Workflow context as a means for intelligentinformation support. In Akman, V. et al (Eds.), CONTEXT2001, LNAI, Vol. 2116, pp. 261274.

May, A., & Carter, C. (2001). A case study of virtual team working inthe European automotive industry. International Journal ofIndustrial Ergonomics, 27, 171186.

May, A., Carter, C., & Joyner, S. (2000). Virtual team working in theEuropean automotive industry: User requirements and a casestudy approach. Human Factors and Ergonomics in Manufac-turing, 10(3), 273289.

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 informationmodeling and interoperability on the web. In Proceedings ofECDL00 Workshop on the Semantic Web, Lisbon, Portugal,September.

Monplaisir, L. (1999). An integrated CSCW architecture for integratedproduct/process design and development. Robotics and Comput-er-Integrated Manufacturing, 15, 145153.

Nonaka, I., & Konno, N. (1999). The concept of Ba: Building afoundation for knowledge creation. California ManagementReview, 40(3), 4054.

Numata, J., & Taura, T. (1996). A case study: A network systemfor knowledge amplification in the product development pro-cess. IEEE Transactions on Engineering Management, 43(4),356367.

Pikosz, P., & Malmqvist, J. (1998). A comparative study ofengineering change management in three Swedish engineer-ing companies. In Proceedings of DETC98, Atlanta, GA,USA.

Ramesh, B., & Tiwana, A. (1999). Supporting collaborative processknowledge management in New Product Development Teams.Decision Support Systems, 27, 213235.

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 innatural language. Journal of Artificial Intelligence Research, 11,95130.

Saaty, T. L. (1980). The analytic hierarchy process. New York:McGraw-Hill.

Salton, G., & McGill, M. (1983). Introduction to Modern InformationRetrieval. New York: McGraw-Hill.

Terwiesch, C., & Loch, C. H. (1999). Managing the process ofengineering change orders: The case of the climate controlsystem in automobile development. Journal of Product Innova-tion Management, 16, 160172.

Wong, S., & Burton, R. M. (2000). Virtual teams: What are theircharacteristics, and impact on team performance? Computationaland Mathematical Organization Theory, 6, 339360.

Wright, I. C. (1997). A review of research into engineering changemanagement: Implications for product design. Design Studies,18, 3342.

Yoo, S. B., & Kim, Y. (2002). Web-based knowledge management forsharing product data in virtual enterprises. International Journalof Production Economics, 75, 173183.

Hong Joo Lee is a post doctoral fellow at the Sloan School ofManagement, Massachusetts Institute of Technology. He received hisM.S. and Ph.D. degrees in 1999 and 2006, respectively, from theGraduate School of Management at Korea Advanced Institute ofScience 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 Schoolat the University of Waikato, New Zealand. He received his Ph.D.from the Graduate School of Management at Korea AdvancedInstitute of Science and Technology (KAIST) in 2004. His mainresearch interests include multi-agent systems, intelligent informationsystems, and e-supply chain management.

Inf Syst Front (2006) 8:375394 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/

Jong Woo Kim is an associate professor of information systems atthe School of Business, Hanyang University, Seoul, Korea. Hereceived his M.S. and Ph.D. degrees in 1991 and 1995, respectively,from the Department of Management Science, the Department ofIndustrial Management at Korea Advanced Institute of Science andTechnology (KAIST), Korea. His current research interests includeintelligent information systems, e-commerce recommendation sys-tems, data mining applications, and business process modeling andintegration.

Sung Joo Park is a Professor of Information Systems at the KAISTGraduate School of Management in Seoul, Korea. He holds a B.S.degree in Industrial Engineering from the Seoul National University, anM.S. in Industrial Engineering from the Korea Advanced Institute ofScience, and a Ph.D. in Systems Science from the Michigan StateUniversity. He has been a senior researcher at the Software Develop-ment Center, KIST, and a professor at the KAIST since 1980. His areasof research interests include intelligent information systems and theapplication of agent technology to management decision-making.

394 Inf Syst Front (2006) 8:375394

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Capturing and reusing knowledge in engineering change management: A case of automobile developmentAbstractIntroductionResearch backgroundEngineering change managementComputer-aided ECM systems

Case studyOverviewThe process of engineering changeKnowledge management practicesFindings from the case study

The collaboration model for engineering change managementDesign of the collaboration model for engineering change managementActivity and processConversationTwo types of knowledge item: document and discussionKnowledge contextOntology

Knowledge representation with the collaboration model and ontologiesKnowledge reuse in engineering change managementPerformance analysis of case retrieval

Collaborative environment for engineering change management (CECM)Engineering change process and activity executionInitiating a draft of an ECRKnowledge deliveryEvolution of the engineering change documentCollaborative activitiesClosing the workspace

ConclusionAppendix A. Brief introduction to the AHP method used to calculate the weights of the ontologiesAppendix B. Definition of the similarity measureB.1 Definition of ontologiesB.2 Definition of an engineering change caseB.3 Definition of the similarity between two concepts in a single ontologyB.4 Definition of the compensation factor for reducing size effects (Inverse Concept Frequency)B.5 Definition of the similarity between two engineering change cases

References

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /Warning /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 150 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 600 /MonoImageMinResolutionPolicy /Warning /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/Description >>> setdistillerparams> setpagedevice