of 9
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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
8/20/2019 Capturing and Reusing Knowledge
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/
8/20/2019 Capturing and Reusing Knowledge
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