7. Developing Case-Based Help-Desk Support Systems For Complex Technical Equipment

7. Developing Case-Based Help-Desk Support Systems
for Complex Technical Equipment
Help-desks support end-users of complex technical equipment by providing
guidance on the use of products and by performing maintenance operations when
needed. Since the complexity and diversity of technical equipment increases
continuously, help-desk operators have difficulty covering the entire range of
relevant products and need a knowledge repository to be able to find the correct
solution to a problem as soon as possible.
This chapter describes the processes that must be performed to develop a case-
based system to support help-desk operators in diagnosing complex technical
equipment. It is based on the help-desk recipe from the cookbook level in the
INRECA methodology. The recipe was created during the development of the
HOMER system described in section 3.1, and has been applied to the development
of several other help-desk systems. Using the methodology, we were able to speed
up the development process of a case-based help-desk support system by a factor
of 12 (see section 7.5). Apart from the increase in productivity, the methodology
also resulted in considerable benefits regarding product and process quality,
provided a means of communication, and served as a basis for management
decisions.

116 7. Developing Case-Based Help-Desk Support Systems
7.1 Characteristics of Case-Based Help-Desk Support Systems
The ever-increasing complexity of technical equipment makes it difficult for the
users of these systems to operate and maintain them without support. While the
probability that technical systems will fail grows exponentially with their
complexity, the expertise needed to be able to control every feature of such
complex systems usually exceeds the resources available to end-users.
Help-desks support end-users of complex technical equipment. When end-users
have problems, they count on help-desks to provide emergency services. Help-desk
operators provide guidance on how to use the system and keep the system
operational by performing necessary maintenance tasks. They are expected to be
able to solve problems on very short notice, in a very short time, and to be
knowledgeable in all areas that are related to the technical system at hand.
Help-desk operators use their own experiences to solve most of the problems
that are relayed to them. However, as systems become more complex, the areas
help-desk operators are experts in tend to diverge, i.e., problem solving experience
is distributed among experts and the areas of expertise do not necessarily overlap.
Nevertheless, when an end-user has a problem, he or she wants it solved as soon as
possible. If that expert is not available, the user has to wait, which is annoying and
not acceptable in a commercial environment. The problem-solving experience must
be available to every help-desk operator at all times.
Current trouble-ticket tools that are being used at help-desks do not provide a
means of capturing and reusing problem-solving experience in a convenient and
efficient manner. Since problem-solving experience is a corporate asset, it has to be
collected, preserved, and used as efficiently and effectively as possible. The best
way to achieve this is to use CBR to develop help-desk support systems.
The goal of developing a case-based help-desk support system is to create a
knowledge repository that contains problem-solving experiences for a complex
technical domain that changes over time. This knowledge repository will be used
in an organization, by a group of people with varying levels of expertise, in a time-
critical operation. It is obvious that the development and use of such a system does
not only involve technical processes, but also raises managerial and organizational
issues. In the following sections, we describe the tasks that must be performed to
develop a case-based help-desk support system and the processes that have to be
put into place to make such a system operational.

7.2 Development and Use of Case-Based Help-Desk Support Systems 117
Table 7.1. Processes during case-based help-desk support system development and use
System Development System Use
Managerial Processes - Goal Definition
- Awareness Creation
- CBR-Tool Selection
- Progress Verification and
Controlling
Organizational Processes - Project Team Selection
- Initial Domain Selection
- Project Team Training
- Knowledge Acquisition
Process Development
- Acquisition, Utilization and
Maintenance Process
Development
- End-User Training
- Continuous Knowledge
Acquisition
- Utilization Process
- Maintenance Process
Technical
Processes
General IT-
System
Related
- System Specification
- System Implementation
- System Integration
- System Verification
- Continuous System
Maintenance
Knowledge
Repository
Related
- Initial Knowledge
Acquisition
- Core Knowledge
Acquisition
- Continuous Knowledge
Acquisition and
Maintenance
7.2 Development and Use of Case-Based Help-Desk Support
Systems for Complex Technical Equipment
Table 7.1 lists the processes that must be considered and performed during the
development and use of a case-based help-desk support system. As described in
section 6.1.2, we distinguish among managerial, organizational, and technical
processes.
7.2.1 Managerial Processes During System Development
Goal Definition. For a case-based help-desk support system project to be
successful, precise goals must be determined at the outset. This enables
management to fix the direction in which the project should develop and to
measure the success of the project upon completion. Hard (quantitative) and soft
(qualitative) success criteria should be identified (cf. Stolpmann & Wess 1999).
Hard criteria are measurable quantities and cover aspects like:

─ problem solution quality (first-call resolution rate, solution correctness, and
consistency, average cost of proposed solution, etc.),
─ process quality (average time needed to solve a problem, average number of
escalations needed, quality of dynamic priority assignment, etc.),
─ organizational quality (speedup in help-desk operator training, flexibility of
staffing, cost per interaction, etc.).
Soft criteria, on the other hand, measure the subjective quality of the help-desk and
cover aspects like:
─ end-user satisfaction (availability of the help-desk, perceived competence,
friendliness, etc.),
─ help-desk operator satisfaction (workload, work atmosphere, repetitiveness of
tasks, intellectual stimulation, etc.),
─ corporate aspects (preservation of knowledge, publicity, etc,).
The goals must be communicated to the project team, and the team has to be
motivated to achieve them (see also chapter 4).
When project goals are selected, it is important that these goals be realistic both
in terms of their time frame and whether they can be achieved with an acceptable
amount of resources. The case-based help-desk support project must be seen as
part of the long-term knowledge management strategy for the company. Since
knowledge increases and evolves, the experience in a CBR system must be
maintained continuously. System development is only the initial phase in any CBR
project.
Awareness Creation and Motivation. The case-based help-desk support system
project targets the most precious asset of the employees: their experience. The
project’s goal is to collect the problem-solving experience of each relevant
employee and make it available to anybody who needs it in the organization.
Obviously the help-desk operators will have a motivational barrier to giving
away their experience. Every employee knows that “knowledge is power.” In help-
desk environments or domains where experience is being used to solve problems
having experience translates into being superior and indispensable, whereas giving
away the knowledge can be perceived as becoming obsolete.
However, as soon as help-desk operators become part of a project team and
understand that sharing knowledge means that they will get back much more than
they invest, most barriers disappear. It has to be made clear that the user and
beneficiary of the developed system is not going to be an anonymous “company,”
but they themselves. They will be able to access the experience of their colleagues
and solve problems they could not solve before, as well as end situations in which
colleagues constantly pester them for advice. The resulting help-desk system will
enable them to work with increased efficiency and effectiveness.
Apart from the help-desk operators, management has to be motivated as well.
CBR is perceived to be rather academic by most managers. While to them

investing resources into a database project seems to be no problem, investing into
CBR is investing into a venture with an uncertain outcome. It has to be clarified
that CBR is an established technology and by no means only an academic
playground. It also has to be clarified that the initial installation of the case-based
help-desk support system is only the beginning of a process that will enable the
company to capture and reuse experience. Management must be prepared to invest
resources on a continuous basis while the system is operational. A CBR system is
only useful if it contains knowledge and is being maintained on a continuous basis.
Without continuous management support and employees who are willing to fill
and use the system, any CBR project is bound to fail.
CBR Tool Selection. Based on the project, domain, and user-group specifications,
a suitable tool to develop the case-based help-desk support system must be
selected. Criteria to be taken into account include:
─ the operating environment in which the system is going to be used (hardware
and software, network architecture, database type, etc.),
─ the complexity of the technical domain (home appliances or networked
workstations),
─ the level of experience of both the end-users and the help-desk operators,
─ the organization of the help-desk (number of levels, physical locations, etc.),
─ the project goals that have been defined.
Since the case-based help-desk support system is going to serve as a (long-term)
knowledge repository for the organization, this selection should be based not only
on technical criteria, but also should take into account economic and organizational
considerations, as well as strategic decisions of the company.
7.2.2 Organizational Processes During System Development
Project Team and Initial Domain Selection. The creation of a project team to
serve as the “knowledge engineers” and the selection of a group to act as initial test
users of the system are the first organizational steps that must be taken.
Apart from the person implementing the case-based help-desk support system
(CBR consultant), the project team should contain help-desk personnel who are
very experienced in the relevant subdomain to be modeled and well respected by
the help-desk operators outside the project group. Personnel that are interested in
“technology” rather than implementing useful systems are very common in help-
desk environments, but definitely not helpful in creating a case-based system and
should be avoided. Once selected, the members of the group should be kept
constant, i.e., fluctuations should be avoided.
The group of initial users should comprise two types of help-desk personnel:
One that is on a comparable level of expertise with the project team with respect to
the selected subdomain (i.e., expert users) and help-desk personnel who are less

familiar with the specific problem area (i.e., novice users). While the expert test-
users can communicate to the project group in their language, the novice users will
represent the target group for which the system is being implemented. Feedback
from both types of users is required for a successful project. After a first “rapid
prototype” has been implemented, the expert users can give hints regarding
problems with the knowledge modeled in the system. The members of the novice
user group, on the other hand, will serve as models of the help-desk operator who
will use the system. The vocabulary in which the cases are being represented and
the knowledge contained within them has to be adjusted to the novice user group
Which domain one selects for the initial knowledge acquisition is of utmost
importance. The domain should be representative of the problems that are being
handled at the help-desk, both in terms of complexity and frequency. It should also
be a problem area that accounts for a considerable amount of the workload and
about which the help-desk operators are interested in sharing (obtaining)
knowledge.
Training the Project Team. Training the project team is another organizational
process that has a major impact on the success of the help-desk project. At the
beginning of the project, the project team is (most of the time) inexperienced with
respect to CBR and knowledge acquisition. Since the project group will be
responsible for system maintenance and continuous case acquisition after the
development has finished, it is very important that they are trained in CBR, as well
as in knowledge acquisition and modeling, during the initial knowledge
acquisition.
While the project team should also get advanced training to be able to model,
fill, and maintain the knowledge in the system, the test users only need to be
trained in using the resulting case-based help-desk support system.
Development of the Knowledge Acquisition, Utilization, and Maintenance
Processes. The introduction and use of a case-based help-desk support system
usually causes a re-evaluation and modification of the existing knowledge and
information management processes in a help-desk environment. When the system
is used, it must be integrated into the operating environment of the help-desk
operators and become part of the standard business process. Existing processes
must be altered to facilitate the flow of information to and from the CBR system.
When organizational processes are defined, the tasks to be performed, the
personnel or roles to perform these tasks, and the communication among the
groups/roles have to be fixed.
After the development of the case-based help-desk support system is complete, it
will serve as the central source of information for the help-desk operators. To
ensure a smooth flow of information, the knowledge sources and formats, as well
as the qualification of the personnel that requires the knowledge, have to be
analyzed, and processes that allow efficient and effective acquisition, use, and
maintenance of knowledge have to be developed. One should keep in mind that

while the group enacting the initial knowledge acquisition process is the project
team and rather experienced, the users who use the system in the end (both in terms
of knowledge retrieval and continuous acquisition) may be less qualified.
During the development of HOMER (see section 3.1), we found it very useful to
define three roles for the organizational processes during the use of the help-desk
system:
─ the help-desk operator,
─ the CBR author,
─ the CBR administrator.
Help-desk operators are the users from the target group. Their duty is to use the
implemented help-desk system in their daily work. If they cannot find an
appropriate solution with the system, they will have to solve the problem on their
own and generate a new case. Depending on the domain and on managerial
decisions, this new case may or may not be made immediately available as an
“unconfirmed” case to the other help-desk operators. For maintenance purposes,
the operators are also encouraged to comment on the quality and applicability of
the cases in the case base.
The unconfirmed, new cases have to be verified in terms of their correctness and
suitability for the case base by the CBR author(s). The CBR author is a person with
experience both in the domain and in using the CBR system. While the CBR
author can decide on the quality and inclusion of a case in the case base, he or she
is not allowed to perform modifications on the vocabulary, the similarity, and the
adaptation knowledge. These can only be performed by the CBR administrator.
The long term maintenance of the knowledge in the system is performed in co-
operation by the CBR authors and the administrator (see section 7.3.2.)
The personnel enacting the roles of the CBR author(s) and the CBR
administrator should be included in the project group from the start of the project.
It should be noted that both these roles require a considerable amount of resources
and should be performed by dedicated personnel. If the organization or the size of
the help-desk does not permit dedicating more than one person to these tasks, the
duties of the CBR author and CBR administrator should be performed by one
person.
7.2.3 Technical Processes During System Development
General IT-System Development Related Processes. The development of a case-
based help-desk support system is similar to any other IT project in most aspects.
As usual, the system has to be specified, implemented, integrated, and verified.
The definition of the requirements, the implementation, and the testing and
revision of both the prototype and the actual case-based help-desk support system
are steps that have to be performed in accordance with standard software

engineering techniques. However, the user-interface and the connection to
supporting programs (integration) are two features that require additional attention.
The essential task in developing a user interface is to present the relevant data,
at the right moment, in the right representation, and on a level of abstraction that is
suitable for the current users of the system. If the available data is presented to the
users in a way that they do not understand, in a representation they are not familiar
with, or at a moment when it is irrelevant, it will only cause confusion and be of no
use. While the exact specification of the firmware installed on a printer may be
necessary information for a second-level help-desk operator, it will be rather
useless for a first-level help-desk operator who is just trying to figure out whether
the printer is connected to the computer. The user interface of the case-based help-
desk support system has to be developed in accordance with the user group (i.e.,
second level, first level, or even end-user), the specific domain, and company
policies (who is allowed to see what kind of data). It has to present the right data,
at the right moment, on the right level of abstraction, and in accordance with
company policies.
A case-based help-desk support system cannot operate in isolation. While the
CBR system will store experience, it will not contain data regarding device
configurations, maintenance contracts, and users. Maintenance information and
device configurations are stored in an inventory system most of the time. Data
regarding the end-users is usually stored in another, separate database. Since this
information is needed during problem solving, the system has to have interfaces to
these databases.
Most help-desks use trouble-ticket tools in their daily operations; they record,
manage, trace, escalate, and analyze the calls they receive. While these trouble-
ticket tools are very useful in handling calls, they do not provide means to capture
and reuse problem-solving experience. Depending on the environment, the case-
based help-desk support system should also either be integrated into the user
interface of the trouble-ticket tool or vice-versa. Data from the trouble-ticket
system has to be transferred to the CBR system to initialize the attributes that relate
to the data that has already been acquired. Except for very complex second-level
applications, it is not feasible to have two points of entry to the problem-solving
process.
Initial Knowledge Acquisition for the Case-Based Help-Desk Support System.
A CBR system is useless without cases. When the case-based help-desk support
system is handed over to the help-desk operators, it has to contain enough cases to
cover at least part of the relevant problems at the help-desk. Otherwise the system
will be considered useless and the project will fail.
Initial knowledge acquisition serves three major goals:
─ training the project team in knowledge acquisition,
─ initializing the knowledge in the system,
─ collecting enough help-desk cases to bootstrap the system.

During initial knowledge acquisition, the knowledge in the system can be
distributed among the domain model (vocabulary), similarity measure, adaptation
knowledge, and the case base. These knowledge containers (Richter 1998) have to
be created and filled. While the similarity measures, the adaptation knowledge, and
the vocabulary are compiled knowledge, the case base is interpreted at runtime. In
principle, each container could be used to represent most of the knowledge.
However, this is obviously not very feasible, and the CBR consultant should
carefully decide on the distribution of knowledge into the containers. After the
initial knowledge acquisition is completed, this distribution is more or less fixed
and should only be changed with caution.
The processes for the acquisition of knowledge for each container run in parallel
and cannot be easily separated during the initial knowledge acquisition. Since the
vocabulary lays ground for entering the cases and describing the similarity
measures and adaptation knowledge, it has to be available first. However, to be
able to create a domain model (i.e., the vocabulary), one has to understand how the
domain is structured, and this can only be done by looking at the cases, the
similarities, and the adaptation rules.
In our experience, the best way to approach this problem is to create and use
standardized forms to acquire an initial amount of cases from the project team. The
form should be developed in co-operation with the project team. A sample form
that was developed for the initial case acquisition for the HOMER (cf. section 3.1)
application is shown in Tab. 7.2.
The first thing that must be done is to ask the project team to fill out as many
case acquisition forms as they can. By looking at the elements of the forms, the
vocabulary (i.e., the phrases that have to be used and the domain structure) can be
derived and a vocabulary that is capable of describing the cases that have been on
the forms can be modeled.
By asking the project team what the range of possible values for each attribute
on the forms is and inquiring what would have happened if one of the values on a
form were different, a broad range of cases can be created and the vocabulary
expanded in a short time. Discussions among the project team members raise the
level of understanding of both the approach and the problems, and should be
encouraged in this early phase. One should also keep in mind that the goal is not to
model the domain in every detail but on a level that helps the system’s user solve a
problem (i.e., the system does not have to solve the problem autonomously).
Especially during initial knowledge acquisition, it is advisable to have more cases
on an “everyday” level rather than having a few extremely specific ones.
While the initial vocabulary is being created and value ranges fixed, questions
regarding adaptation rules and similarities should be posed and the results entered
into the system.

Table 7.2. Sample form for initial case acquisition
Homer Case Acquisition
Problem Nr : 0816 Date: 26.04.99
Author: S. Itani Verified by: J. Fleisch
Problem Description (Failure) Printer does print pages full of gibberish
Reason (Fault) File is Postscript, Printer does not
understand PS
Solution Send File to Postscript Printer, delete file
from queue
What did you check to find out what the problem was ?
Printer Model HP LJ 6L
File Type Postscript
Other Notes: The reverse of this problem did also
happen, somebody sent a PCL file to a pure
PS printer
One of the major challenges one must face when creating a system to capture
and represent the experience of domain experts, is determining the level of
abstraction with which the domain and the knowledge will be modeled. If the
model used is too simplistic, it will cause problems while the experience is being
captured and will miss important details. If, however, the domain model is too
specific, the user will get lost quickly in useless details, and knowledge acquisition
will be very tedious and time consuming. Maintenance is very difficult for both a
too-simplistic and a too-complex model.
The system’s intended users also influence the decision to use a structured
domain model approach as opposed to a textual query-answer-based approach. For
inexperienced help-desk operators, a tool with which simple problems can be
solved by answering a limited number of questions is of great value (Thomas et. al.
1997). However, for experienced help-desk operators who would not bother to use
a system for (subjectively) trivial problems, a structured domain model approach
yields better results. The system will be able to present the not-so-obviously
similar solutions that the help-desk operators could not find. Since knowledge
contained in the domain model is used in similarity calculation, the retrieved
solutions will be similar in a semantic and structural manner. The domain model
allows the solutions in the case base to be applicable to a broader range of
problems.
The cases in the help-desk domain should be modeled in accordance with the
approach the help-desk operators use in solving problems (Fig. 7.1).

7.3 Using the System 125
The Problem Description is the first information the help-desk operator gets
from the end-user. This description is what the end-user subjectively perceives as
the problem. It may or may not have to do with the actual cause of the failure.
The System Description contains information regarding the system itself as well
as the operating environment. It consists of the questions the help-desk operator
must ask or the information he or she must obtain from various sources to arrive at
a diagnosis. The system description contains the necessary and sufficient amount
of information needed to diagnose the problem.
The Solution contains the fault, i.e., what caused the problem, and the remedy,
i.e., how to solve the problem. Depending on how the system is implemented and
what statistical information is needed for further evaluation, some additional,
administrative data may also be added to the case description.
Each complete path from problem description to solution makes up one case.
Once the cases from the initial forms have been entered into the help-desk
system, the system should be shown to the project group to verify the results it
delivers. Afterwards the initial knowledge acquisition can continue as more cases
are entered from additional forms and the knowledge containers are incrementally
updated.
Initial knowledge acquisition takes place in two steps. During the first,
preliminary knowledge acquisition, the cases for the prototype of the case-based
help-desk support system are collected. While the collected cases will help to
initialize the knowledge containers and train the project team, the collection of the
“core” cases for the system should be done in a second step, the core knowledge
acquisition. Nevertheless, the approach that is used in both processes is similar.
7.3 Using the System
7.3.1 Managerial Processes During System Use
Project progress with respect to the qualitative and quantitative criteria selected as
project goals must be monitored constantly during system development and use
(cf. Stolpmann & Wess 1999). Regular project reviews should take place. Standard
project planning and controlling techniques can and should be applied to case-
Problem Diagnosis
Path
Solution
Fig. 7.1. Basic structure of a help-desk case

based help-desk support projects.
Measuring the impact of the help-desk system on the efficiency and
effectiveness of the target group (increase in first-call problem resolution, decrease
in problem solution time, etc.) and making the results available to both the project
and the target groups will motivate the help-desk operators to use the system and
help uncover deficiencies.
7.3.2 Organizational Processes During System Use
Knowledge Acquisition, Utilization and Maintenance Processes. The
knowledge acquisition, utilization and maintenance processes that have been
defined during system development have to be enacted during system use. The use
of the case-based help-desk support system contains the Application Cycle in
which the system is used by the help-desk operator and the Maintenance Cycle in
which the system is maintained by the CBR author and the CBR administrator (see
section 7.3.3, Fig. 7.2).
During the application cycle, the cases that are stored in the case-based help-
desk support system are being used to solve problems. Even if no new cases are
being acquired during this cycle, statistical data regarding the quality and usage of
the cases (last retrieval time, last application date, success rate etc.) can be
collected. This data can be used to determine the quality of the cases and for
maintenance purposes.
Whenever a help-desk operator decides that the proposed solution is not
appropriate, a new case has to be entered into the case base. However, since the
quality of these cases varies according to the user entering them, they cannot be
transferred to the case base without being verified by the CBR author. This is done
in the maintenance cycle. The extension and maintenance of the case base is the
duty of the CBR author and the CBR administrator.
Training the Help-Desk Operators. Just as the test-users were trained during the
project team training, the help-desk operators have to be introduced to the basics of
CBR technology and the developed case-based help-desk support system. Since the
operators are going to participate in the continuous acquisition of knowledge,
standards on how to store cases have to be introduced and taught. Feedback-
channels also should be created and introduced during this training.
7.3.3 Technical Processes During System Use
Continuous Knowledge Acquisition and Maintenance. The knowledge
contained in a case-based help-desk support system is an incomplete model of the
domain in the real world. Whenever the real world changes, the model in the
system has to be updated. The necessity for changes in the model may either arise

7.3 Using the System 127
from real changes in the world or from the learning effect associated with using the
case-based help-desk support system. By learning, the system improves the
model’s coverage of the real world. Since the model is incomplete by definition
(and no such thing as a closed world exists in the real world), with growing
knowledge, updates in the knowledge containers will be necessary.
While nobody would consider purchasing a database system with the
assumption that it would continue to work without any maintenance at all, there
seems to exist a misconception about knowledge-based systems in this respect. All
concepts used for maintaining database systems are also applicable to knowledge-
based systems. However, because of the semantics associated with the information
in knowledge-based systems, additional maintenance operations are necessary.
Learning and changes in the real world can make maintenance necessary for each
knowledge container.
A case-based help-desk support system comprises two linked process cycles: the
Application Cycle and the Maintenance Cycle (see Fig. 7.2).
The Application Cycle takes place each time a user solves a problem with the
case-based help-desk support system. During the application of the CBR system,
the standard tasks Retrieve, Reuse, and Revise must be performed (see section 2.6).
During Retrieval the most similar case or cases in the case base are determined
based on the new problem description. During Reuse the information and
knowledge in the retrieved case(s) is used to solve the new problem. The new
problem description is combined with the information contained in the old case to
form a solved case. During Revision the applicability of the proposed solution
(solved case) is evaluated. If necessary and possible the proposed case is repaired.
If the case solution generated during the reuse phase is not correct and cannot be
Maintenance
Cycle
Retain Refine
Application
Cycle
Reuse
Revise
Retrieve
ReCycle
Fig. 7.2. Use of the case-based help-desk support system

repaired, a new solution has to be generated by the help-desk operator. The
solution that has been retrieved by the system or created by the help-desk operator
is put to use during the Recycle task. The Application Cycle is performed by the
end-user of the system (help-desk operator).
Whenever a new solution is generated during system use, this case is stored in
the case buffer, made available to all help-desk operators as an “unconfirmed
case,” and sent to the Maintenance Cycle. These operations as well as the
maintenance cycle are not visible to the standard help-desk operator.
The Maintenance Cycle consists of the Retain and Refine tasks. While the
Application Cycle is executed every time a help-desk operator uses the CBR
system, the Maintenance Cycle can be executed less frequently, i.e., only when
there is a need for maintaining the system or at regular intervals.
During the Retain task, the CBR author checks the quality of the new cases that
were generated by the helpdesk operators and stored in the case buffer.
The CBR author verifies and approves the representation and content of each
case. In terms of representation, the cases should:
─ contain the information that is necessary and sufficient to solve the problem,
─ be described on an abstraction level that is appropriate for the system’s end-
user.
The content is verified by checking whether the case is:
─ correct,
─ (still) relevant,
─ applicable.
During the Refine phase, maintenance steps for the knowledge containers are
performed by the CBR administrator. The case base, vocabulary, similarities, and
adaptation knowledge have to be refined, and quality-decreasing effects of external
changes in the domain, as well as the inclusion of new cases in the case base, have
to be counteracted.
The goal of the Refine task with respect to the case base is to keep the case base
correct, to have maximal coverage of the problem space, and to have no redundant
cases. After each case has been validated in the retain task, their suitability for
inclusion in the case base has to be determined.
Before a new case is taken into the case base, it must be checked to see:
─ whether it is a viable alternative that does not yet exist in the case base,
─ whether it subsumes or can be subsumed by an existing case,
─ whether it can be combined with another case to form a new one,
─ whether the new case would cause an inconsistency,
─ whether there is a newer case already available in the case base.
The operations that have to be performed during case base maintenance vary
depending on the application domain and the vocabulary that is used to represent

7.4 Process Model for a Help-Desk Project 129
the cases. Recent research on maintenance issues in CBR has addressed this issue
in much detail (Leake & Wilson 1998, Smyth & McKenna 1998, Surma &
Tyburcy 1998, and Racine & Yang 1997, Nick et al. 2001, Reinartz et al. 2001,
Wilson & Leake 2001).
Both the inclusion of new cases and changes in the domain may have an effect
on the validity and quality of the compiled knowledge containers (vocabulary,
similarity, adaptation knowledge) as well. The maintenance of these containers is
also performed in the Refine step. Since changes in the vocabulary can cause
information in the cases to be no longer available or missing (e.g., attributes can be
added and deleted, classes can be moved) maintenance of the vocabulary should be
performed with utmost caution (Heister & Wilke 1998).
It should be noted that the refinement of the knowledge containers does not
necessarily have to be triggered by external events but may also be performed
through introspection. By analyzing the content of the knowledge containers, more
efficient ways to structure the domain, adaptation rules, and similarities, as well as
new cases, can be discovered or derived.
While maintenance operations for the case base can be performed by the CBR
author, maintenance of the vocabulary, the similarity, and adaptation knowledge
should only be performed by the CBR administrator.
General IT-System-Related Processes. Once the case-based help-desk support
system has been put into operation, it has to be debugged, monitored, and updated
continuously. The necessity for updates does not necessarily have to come from the
help-desk system itself, but may also be initiated by changes in the (IT)
environment. Since these processes are not CBR-specific but apply to IT systems
in general, we refrain from going into their details here.
7.4 Process Model for a Help-Desk Project
The overall process for the development and introduction of a case-based help-
desk support system can be divided into six main phases:
─ project planning and initialization,
─ implementation of a rapid prototype,
─ evaluation and revision of the prototype,
─ implementation of the integrated case-based help-desk support system,
─ evaluation and revision of the case-based help-desk support system,
─ utilization of the case-based help-desk support system.

During Project Planning and Initialization, the preliminary requirements for the
execution of the project are fulfilled. The project goals are defined, the project
information is disseminated, the project team is created and trained, and the CBR
tool is acquired (Fig. 7.3).
The Implementation of the Rapid Prototype enables the project team to test the
validity of the goals and the requirements set forth in the project-planning phase. It
also serves to train the project team in knowledge acquisition techniques and in
using the CBR tool. The processes that will be used during knowledge acquisition
can be defined and refined. The “Rapid Prototype Implementation,” “Preliminary
Knowledge Acquisition,” and “Knowledge Acquisition Process Development”
processes are closely interconnected and influence each other. While changes in
the prototype will effect the way knowledge is acquired, changes in the domain
model will effect changes in the acquisition process as well as the user interface of
the system, etc. (Fig 7.4). The interaction between processes is shown with dotted
lines in the figures.
Project
Information
Project Goal
Description
Goal Definition
Project Team Selection Requirements Definition
Project Team
Requirements
Definition
Document
CBR-Tool Selection
CBR-Tool
Project Vision
Project Team Training
Trained
Project Team
Initial Domain Selection
Domain for
Initial
Implementation
Awareness Creation and
Motivation
Fig. 7.3. Project planning and initialization

7.4 Process Model for a Help-Desk Project 131
Trained
Project Team
Requirements
Definition
Document
CBR-Tool
Rapid Prototype
implementation
Knowledge Acquisition
Process Development
Preliminary Knowledge
Acquisition
Rapid Prototype
Preliminary
Case-Base
Knowledge
Acquisition
Process Model
Fig. 7.4. Implementation of a rapid prototype
Preliminary
Case-Base
Rapid Prototype
Initial Test
Users
Requirements
Definition
Document
Test of Rapid Prototype
Rapid Prototype
Test Report
Requirements Revision
Revised
Requirements
Document
Fig. 7.5. Evaluation and revision of the prototype

During the Evaluation and Revision of the Prototype (Fig. 7.5), the initial users
(see section 7.2.3) evaluate the developed a rapid prototype as well as the structure
and content of the knowledge containers. The results are collected in a revised-
requirements definition document, which serves as a basis for the development of
the actual system.
The Implementation of the Integrated Case-Based Help-Desk Support System
contains the development of the actual system to be used at the help desk. The
implementation is based on the preliminary case base, the revised requirements, the
rapid prototype, input from the project team, and the process model for knowledge
acquisition. While the system is implemented, the project team acquires the core-
case base to be deployed with the system after implementation is complete. The
processes to be used when the system is used are also developed in close
connection with the implementation and the knowledge acquisition in this phase
(Fig. 7.6.).
During the Evaluation and Revision of the Case-Based Help-Desk Support
System the system is evaluated by the initial users and revised according to the
results of this evaluation (Fig. 7.7.).
The system is put to use in the Utilization of the Case-Based Help-Desk Support
Trained
Project Team
Revised
Requirements
Document
Rapid Prototype
Implementation of Inte-
grated Case-Based Help
Desk Support System
Utilization Process
Development
Core Knowledge
Acquisition
Integrated
Case-Based
Help-Desk
Support System
Core
Case-Base
Utilization
Process
Model
Preliminary
Case-Base
Knowledge
Acquisition
Process Model
Fig. 7.6. Implementation of the integrated case-based help-desk support system

7.5 Impact of the Methodology 133
System phase. The impact of the system is continuously monitored and feedback is
given to developers and users (Fig. 7.8).
7.5 Impact of the Methodology in Developing and Using Help-
Desk Support Systems
The process models shown above were created during the development of the
HOMER application (see section 3.1). One of the goals of the implementation of
HOMER was to observe and record the processes that have to be enacted during
system development and use. The results of these observations have been
documented as a recipe in the cookbook level of the INRECA methodology. The
process models shown above have been extracted from this recipe.
In the course of developing the methodology, we documented the tasks that were
performed, their duration, the resources needed, and the outcome of the tasks.
While monitoring our own actions, we discovered redundancies as well as
dependencies among processes that were not obvious. This enabled us to structure,
optimize, and understand some of the processes better. Even the development of
the methodology had an impact on the way the project progressed.
Core
Case-Base
Case-Based
Help-Desk
Support System
Initial Test
Users
Revised
Requirements
Document
Test of Help-Desk System
Help-Desk
System Test
Report
Revision of Help-Desk
System
Revised
Integrated Help-
Desk System
Utilization
Process
Model
Fig. 7.7. Evaluation and revision of the case-based help-desk support system

After the process models were complete, the methodology and the developed
tools were used during the project definition, application development, and system
utilization phases of new projects. As described in chapter 5, the methodology has
an impact on productivity, quality, communication, and management decision
making. We could observe the advantages of using the methodology in each of
these areas and in all three project phases, both to the customer (management and
user) and to the developer.
Trained
Project Team
Core
Case-Base
Integrated
Case-Based
Help-Desk
Support System
Knowledge
Acquisition
Process
Utilization
Process
Model
Utilization of
Case-Based Help-Desk
Support System
Continuous System
Maintenance
Continuous Knowledge
Acquisition
Optimized
Held-Desk
Case-Base
Operational
System
Progress Verification
Feedback to
Development
and Help-Desk
Fig. 7.8. Utilization of the Case-Based Help-Desk Support System

7.5 Impact of the Methodology 135
7.5.1 Impact of the Methodology During Project Definition
During the definition of a project, the processes to be executed have to be detailed.
For each process, this involves defining the methods to be used, the project’s
duration, the resources needed, the results to be produced, the interaction with
other processes within the project, and the sequence in which the processes must be
executed.
By means of the methodology we were able to create project definitions with
structured process models, task definitions, roles and responsibilities, duration, and
resource allocations. The methodology enabled us to make the case-based help-
desk support system development process traceable both to the customers and to
ourselves.
While the creation of the project definition for HOMER from scratch took us
about three months, we were able to reuse the help-desk recipe to define three new
projects in less than a week each. The overall duration of these projects varied
between six months and three years. Since we reused a recipe that had been
executed before, we could be sure that all aspects that needed be taken into account
were covered. Since the basic “recipe” was available, we could concentrate on the
peculiarities of each domain. The quality and level of detail we were able to
achieve in these project descriptions were far beyond the level that can be achieved
when a description is created from scratch.
Apart from these advantages in increased productivity and quality, the
methodology was also very useful for communicating with the customer and
conveying the message that the development of a CBR system is not an art, but,
rather, solid technology. As we mentioned above, Case-Based Reasoning is still
considered an academic approach by some managers. Being able to describe each
process in the development of a case based system in detail enabled us to convince
managers of the validity of the approach, clarified the need for continuous
maintenance and resource allocation, and let us raise realistic expectations. We
were able to give customers figures on how much effort had to be spent by whom
and when. Project progress became measurable. This gave them a basis for making
decisions, enabled them to plan their resource allocation in advance, and prevented
the loss of critical resources in the course of the project.
7.5.2 Impact of the Methodology During System Development
The detailed project plan that was created during project definition served as a
guideline during the development of the system. The ability to trace a structured
path and the use of the software tools that was developed to support the
methodology allowed us to speed up the development process by a factor of 12.
While the development and testing of the first prototype in HOMER and
comparable applications took up to six months from the initiation of the projects,

we were able to create a prototype and test it at another site of DaimlerChrysler
within two weeks.
Since the tasks that have to be performed and the results that have to be
achieved during the implementation of the system were described in detail in the
“recipe” and the project definition, some tasks could be transferred from one
developer to the other without additional effort, and the progress that was achieved
during the project could be measured. A clear-cut definition of the tasks to be
performed and the availability of tools for creating and maintaining a domain
model allowed us to use less-qualified personnel during the development of the
system without compromising the quality of the resulting product. This allowed
both the developer and the customer to optimize the allocation of personnel
resources.
7.5.3 Impact of the Methodology During System Use
During the development and initial use of HOMER, we had to define and modify
the tasks and qualifications of the personnel needed to operate the system several
times. Since the processes for the acquisition, use, and maintenance of the
knowledge in the case-based help-desk support system are defined in the
methodology, we were able to introduce new help-desk systems in a much more
efficient manner. While the domain modeling and maintenance task could only be
performed by a highly qualified help-desk operator in the HOMER project, the
domain modeling and model-maintenance tools, as well as the similarity editor that
was developed to support the INRECA methodology, enabled us to use much-less-
qualified personnel in the ensuing projects.
The detailed definition of the duties that have to be performed and the
qualification that is needed for the project group also enabled the customers to
allocate the necessary resources in advance and monitor the status of the project
according to the goals that had been set when the project was initiated.
The methodology was also used to train users in the administration of a case-
based help-desk support system. Using process charts, we explained the overall
structure of the project to the operator who would be in charge of the project after
it was completed. This allowed the operator to maintain and use the system without
getting lost in details and neglecting important aspects, like maintaining the case
base.
7.6 Conclusion
To develop case-based help-desk support systems that will be used in dynamic,
corporate environments by a large group of users, one must take into account the
managerial, organizational, and technical processes. It has to be kept in mind that

7.6 Conclusion 137
once a CBR system is in place, continuous knowledge acquisition and maintenance
is necessary. Processes for knowledge acquisition and maintenance have to be
developed and put in place, and personnel have to be dedicated to performing these
tasks.
The processes necessary to develop a case-based help-desk system have been
described in a recipe of the cookbook level in the INRECA methodology. The
methodology structures the development and use of case-based help-desk systems,
makes it transparent, traceable, and its success measurable. Using the INRECA
methodology in the project definition, system development and system utilization
phases of new projects resulted in considerable increases in productivity and
quality. The methodology also provided a means of communication and served as a
basis for management decision making.

7. Developing Case-Based Help-Desk Support Systems For Complex Technical Equipment

More Related Content

Similar to 7. Developing Case-Based Help-Desk Support Systems For Complex Technical Equipment (20)

More from Don Dooley (20)

Recently uploaded (20)

7. Developing Case-Based Help-Desk Support Systems For Complex Technical Equipment