from knowledge engineering to knowledge - eprints soton

Introduction

The concept of knowledge management hasundoubtedly become a major force in businessthinking in recent years. Many large organizationsare embracing knowledge management and claim-ing significant benefits. Books such as WorkingKnowledge (Davenport and Prusak, 1998) andThe Knowledge-Creating Company (Nonaka andTakeuchi, 1995) demonstrate with multiple ex-amples that many of the world’s most successfulorganizations are those that are best at managingtheir knowledge.

Organizations use a number of methods andsoftware tools to support knowledge management.

Most of these tools, however, have been de-veloped as part of an unstructured technologicalthrust: they are more concerned with new ways ofstoring and communicating information than withthe actual ways in which people create, acquireand use knowledge. Lotus Notes and the worldwide web are examples of these types of tech-nologies. While we do not deny the importance ofsuch tools, we believe that new methods and toolsare needed that can supplement existing techno-logies, but that are specifically oriented towardsknowledge. Such methods and tools would act as a bridge between people and current techno-logies. They would improve support for keyactivities such as knowledge creation, knowledgemapping, knowledge retrieval and knowledgeuse.

Our central thesis is that there are methods andtools, developed in the field of artificial intelligence,that can (and should) provide such a technology.This does not mean, however, that we believemanagers should fill their companies with intel-ligent systems such as expert systems, neural net-works and case-based reasoning systems. Instead,

British Journal of Management, Vol. 10, 309–322 (1999)

From Knowledge Engineering to Knowledge Management1

Nigel Shadbolt and Nick MiltonArtificial Intelligence Group, School of Psychology, University of Nottingham, University Park,

Nottingham NG7 2RD, UK

Knowledge management is seen by many to be a prerequisite for the successful organ-ization, and one that relies heavily, though not exclusively, on a sound technologicalinfrastructure. A major drawback, though, with current technology (e.g. Lotus Notesand www) is its focus on information management and communication rather than onknowledge itself. What knowledge management needs is tools and techniques that aremore oriented towards knowledge – its creation, mapping, transfer and use. We showhow many of the methods and tools used in the branch of artificial intelligence knownas knowledge engineering can be adapted to provide such a knowledge-oriented tech-nology, and lead to significant benefits for organizations. A number of case studies arepresented which illustrate our points, including decision-making at Andersen Consult-ing and best practice at Rolls-Royce. A more elaborated use is shown in the context ofbusiness process re-engineering, where a new software tool kit called SPEDE is beingapplied and validated within the aerospace and automotive industries.

© 1999 British Academy of Management

1 Parts of this work have been supported by an IMIgrant from the Engineering and Physical SciencesResearch Council of Great Britain. We thank all thoseinvolved in the SPEDE project for their help andassistance. We especially thank Paul Riley for workwith Rolls-Royce, Hugh Cottam for ideas contained inthis paper, and Jeni Tennison for invaluable technicalediting.

as we describe later, the methods and tools thatwe consider particularly important for knowledgemanagement are those that have been used in thedevelopment of intelligent systems, rather thanthe intelligent systems themselves. Such methodsand tools have a track record in providing abridge between people and computers.

The paper is structured as follows. We start, in the next section, with a brief background toknowledge engineering, and describe some of theprinciples that have emerged over the past 10–15years. In the third, we describe how these prin-ciples can help alleviate three major concerns ofknowledge management. The fourth section showshow the principles are realized in techniques andsoftware tools. In the fifth section, we present threecase studies to demonstrate how the techniquesand tools are being used in real knowledge-management situations. Finally, we finish with asummary and concluding remarks.

Knowledge engineeringBackground

Artificial intelligence has a relatively long historyin dealing with knowledge from both a theoreticaland practical perspective. The many influences on artificial intelligence (e.g. philosophy, psycho-logy and linguistics) bring to it a rich heritage ofideas and a sound foundation in applied science.Although the early years were dogged by grandnotions that machines would soon solve everyproblem as proficiently as the world’s best expert,artificial intelligence now has goals that are morerealistic.

Alongside this increased pragmatism, a majorshift in emphasis came approximately 20 yearsago. Before then, people believed that it wastheoretically possible to build a problem-solvingmachine that could take a few pieces of informa-tion and use its massive computing power to solveany problem. When people tried to build such amachine, however, they found that far from powerbeing the major element needed, knowledge wasthe major requirement (Minsky and Papert,1974). For machines to do intelligent things, theyrequired knowledge – lots of it and in a structuredform, so that it could be retrieved and used whenneeded. Such machines are known as ‘expertsystems’ since they are designed to mimic the

knowledge and the reasoning processes of anexpert practitioner, such as a physician, geologistor chemist.

However, the need to acquire knowledge for anexpert system became a problem in itself. Know-ledge engineers found that acquiring enoughhigh-quality knowledge to build a robust and use-ful system was a very long and expensive activity.Indeed, acquiring knowledge became the ‘bottle-neck’ in building an expert system (Hayes-Roth,Waterman and Lenat, 1983). This led to ‘know-ledge acquisition’ becoming a major researchfield within knowledge engineering. The aim ofthis field is to develop methods and tools that makethe arduous task of ‘transporting’ knowledge frominside an expert to inside a computer efficient andeffective (Shadbolt and O’Hara, 1997).

Over the past 15 years, knowledge engineershave developed a number of principles, methodsand tools that have made knowledge acquisitionan efficient and effective activity. Interestingly,many of the issues and problems that are beingwritten about in the knowledge management lit-erature are familiar territory to those involved inknowledge engineering. Thus, many of the prin-ciples, methods and tools of knowledge engineer-ing may have relevance to knowledge management.In recent years, knowledge engineers have begunto adapt, test and validate knowledge engineeringmethodologies within real knowledge manage-ment initiatives. In the next section, we coversome of the principles from knowledge engin-eering that are relevant and useful to knowledgemanagement.

Knowledge engineering principles

Principle 1: Recognize that there are different typesof knowledge. Philosophers have been thinkingabout knowledge for thousands of years. Part of their endeavour has been the identification ofdifferent types of knowledge.

One distinction is between declarative know-ledge (knowledge of facts) and procedural know-ledge (knowledge of how to do things). A popularway of thinking about these is the differencebetween ‘knowing that’ and ‘knowing how’ (Ryle,1949). This distinction has been recognized andused for a long time in psychology. In knowledgeengineering, these two types are often referred toas static knowledge and dynamic knowledge: wewill use these terms in the rest of this paper.

310 N. Shadbolt and N. Milton

Another well-known classification of knowledgeis that of tacit knowledge (cannot be articulatedeasily) and explicit knowledge (can be articulatedeasily). Since this is of particular relevance toknowledge management, we shall leave discus-sion of these until later.

A particularly important way of classifyingknowledge is to what extent it is abstract (appliesacross many situations) or specific (applies to oneor a few situations). Developing ways in which spe-cific knowledge can be made more abstract andabstract knowledge can be made more specifichas been a major effort in knowledge engineering.

The field of logic has also inspired otherimportant knowledge types: concepts, attributesand values. For instance, within the statement ‘it isa fast car’, we refer to ‘car’ as being a concept, and‘fast’ as being a value of the attribute speed. Con-cepts, attributes and values can be linked togetherto form another important class of knowledge –rules. For example, ‘if it is a fast car, then it is anexpensive car’.

There are other types of knowledge, some ofwhich we will mention later in this paper. Theimportant point is that it is easier to deal withknowledge if you can recognize different types ofknowledge and understand how they relate to oneanother.

Principle 2: Recognize that there are different typesof experts – and expertise. Not only are there dif-ferent types of knowledge, but there are differenttypes of experts. As such, it is important toidentify the different types of experts involved ina project and tailor the methods accordingly.

The difference between knowledge that can bearticulated easily and knowledge that cannot bearticulated easily is a very important distinctionfor both knowledge engineering and knowledgemanagement. Psychologists and knowledge engin-eers have found that experts vary in how well theycan articulate their knowledge. This is because thenature of experts’ knowledge varies depending ontheir training and experience (Chi, Glaser andFarr, 1988). Shadbolt and Burton (1995) identi-fied different types of experts, ranging from thosewhose knowledge of a domain is almost com-pletely tacit (called ‘samurai’), to those whoseknowledge is almost completely explicit (called‘academics’).

In addition to differences in ability to articulateknowledge, experts vary in how well they recall

information in a given context. Studies in psy-chology have repeatedly shown that experts arenot able to remember the same things duringinterviews as they can when they are performinga task. In addition, the ability to recall the sameinformation in different tasks can vary betweenindividuals. For instance, those with experience ofteaching others in a classroom setting are usuallybetter at explaining their knowledge than thosewithout such experience.

Finally, experts may vary in the validity of theknowledge they can articulate. It is a well-knownphenomenon in psychology that people are biasedand error prone when they try to explain some-thing: they attempt to save face or show off, theyrationalize or misinterpret what happens and soon. Again, people may vary in the extent to whichthey do this, and it is important to recognize this.Knowledge engineers have devised a number ofmethods to overcome such problems, such asaggregating knowledge from various sources andvalidating knowledge across sources.

Principle 3: Recognize that there are different waysof representing knowledge. The field of artificialintelligence may not have produced fully intelli-gent machines, but one of its major achievementsis the production of a range of ways of repre-senting knowledge. Explanations of these repre-sentations (which include various forms of logic,rules, semantic networks and frames) is beyondthe scope of this paper. However, producingdifferent knowledge representations is a vital part(arguably the vital part) of artificial intelligence,since the ease of solving a problem is almostcompletely determined by the way the problem isconceptualized and represented.

The same is true for the task of communicatingknowledge. A well-chosen analogy, anecdote ordiagram can make all the difference when tryingto communicate a difficult idea to someone, especi-ally someone who is not an expert in the field.Indeed, the history of science contains manyexamples of people only understanding newtheories when theoreticians use the appropriaterepresentation.

Principle 4: Recognize that there are different waysof using knowledge. People use knowledge indifferent ways depending on the task they areperforming. From a knowledge perspective, it isuseful to be able to classify tasks. A number of

From Knowledge Engineering to Knowledge Management 311

ways of classifying tasks have been created inknowledge engineering. One classification, adaptedand refined from ideas in psychology, is a hier-archy of knowledge-intensive tasks based on thetype of problem being solved (Schreiber et al.,forthcoming), as shown in Figure 1. Knowledgeengineers have created models that define the typesof knowledge that form the inputs and outputs ofthe task, as well as how the knowledge is trans-formed for each of the tasks in Figure 1. Usingthese models, the knowledge involved in a taskcan be defined in terms of the way it is used tosatisfy a goal or set of goals. This can not only in-crease the efficiency of task analysis and processmodelling, but also enables one to identify howthe same piece of knowledge is used differentlydepending on the context in which it is used.

Principle 5: Use structured methods. This prin-ciple leads on from the first four. We have shownthat there are different types of knowledge,different types of experts, different ways of repre-senting knowledge and different ways of usingknowledge. Therefore, you need a way of relatingthese types of knowledge, experts, representa-tions and tasks together to perform a knowledge-oriented activity. To do this, requires well-definedmethods: methods that are structured such thatthe right techniques and tools are used depending

on the situation and, especially, the goals in-volved. Using these methods, one will not try tointerview experts about knowledge they cannotarticulate, represent it in a form no one willunderstand and eventually find they do not reallyneed it anyway. To avoid such situations, know-ledge engineers have developed three aids:

1. a range of techniques and software tools,described later;

2. formal descriptions of general static know-ledge, called ‘ontologies’;

3. formal descriptions of general dynamicknowledge, that is, models of problem solvingsuch as grammars.

The use of ontologies and problem-solvingmodels is still in its infancy within the context of knowledge management, and is beyond thescope of this paper. However, the essence of thesetopics is that knowledge can and should be reusedboth within, and across, domains.

Three important problems

The problems faced in knowledge managementare many and varied: we certainly do not believethat technology generally (let alone knowledge


Knowledge-intensive task

Analytictask

Synthetictask

Classification

Assessment

Diagnosis

Monitoring

Prediction

Design

Scheduling

Planning

Modelling

Assignment

Figure 1. Hierarchy of knowledge-intensive task types (adapted from Schreiber et al., forthcoming)

engineering technology) is the panacea for themall. We do believe, however, that the principlesdescribed in the previous section can begin toprovide solutions to some important problems.Three knowledge management problems thatrepeatedly crop up are listed below.

1. Organizations contain such a vast amount ofknowledge that mapping all of it would beboth impossible and a waste of time.

2. Tacit knowledge is vital to an organization,yet it is very difficult to acquire and map.

3. Ordinary language is the main form of com-munication, yet it is so full of jargon, assump-tions and ambiguities that people often fail tounderstand what others are trying to say.

In the rest of this section, we will show how know-ledge engineering principles can help addressthese problems.

Mapping the right knowledge in the right way

Avoiding the need to map too much knowledgerequires a number of techniques and tools basedon the principles described in the previous sec-tion. Seven of the more important considerations(some of which have already been mentioned)are:

1. choose what knowledge needs to be mappedby first capturing the goals and uses to whichthe knowledge is to be put;

2. decide on the scale (i.e. the level or granu-larity) of the knowledge to be acquired;

3. choose from a range of tools, so the right oneis used for the job;

4. reuse knowledge (do not reinvent the wheel);5. piece together knowledge from multiple

sources;6. validate knowledge by checking it with other

experts;7. structure knowledge as it is captured, so that

it is easier to search databases and retrievethe relevant knowledge.

Some of these may look familiar to those involvedin knowledge management. If so, this supportsour idea that knowledge engineering can be ofuse to knowledge management. However, if youfeel there is nothing new here, our plea is that theutility of knowledge engineering for knowledge

management is in the techniques and tools whichallow us to satisfy the seven aims listed above.These will be covered in the next section.

Making tacit knowledge explicit

Tacit knowledge, first described by Polanyi (1966),is knowledge that is impossible to articulate (e.g.how to ride a bicycle). Explicit knowledge, on theother hand, is knowledge that can be articulated(e.g. a bicycle has two wheels). Tacit knowledge isoften thought of as knowledge of how to do things(i.e. procedural knowledge). However, not allprocedural knowledge is tacit: for example, it ispossible to articulate how to boil an egg. Similarly,not all tacit knowledge is procedural: for examplesubconscious ideas are not procedural in nature.Tacit knowledge is, by definition, impossible toarticulate: thus the acquisition and sharing of tacitknowledge can be a long and difficult task. However, some believe that it is worth the effort,given the vital role that tacit knowledge plays inorganizations.

In their influential book The Knowledge-Creating Company, Nonaka and Takeuchi (1995)argue that the success of Japanese companies is aresult of their skills and expertise at organizationalknowledge creation. They state that ‘the key toknowledge creation lies in the mobilisation andconversion of tacit knowledge’. Their theory oforganizational knowledge creation explains howtacit and explicit knowledge interact, and howknowledge is converted from one to the other.They demonstrate that the main ways in whichtacit knowledge is made explicit is through meta-phors, analogies, concepts, hypotheses and models.

While we agree with much of what Nonaka andTakeuchi have to say, we feel two aspects needaddressing. The first is their assumption that know-ledge is either tacit or explicit. In our experience,we have found that knowledge is often neitherexclusively tacit nor exclusively explicit, but lieson a continuum between the two. A simple every-day example of this is a person trying to remembersomething saying, ‘it’s on the tip of my tongue’.‘Tip of the tongue’ knowledge is far more explicitthan the term ‘tacit knowledge’ would suggest: itoften only requires a small prompt to be madeexplicit (e.g. by being given the initials of a per-son’s name you cannot quite remember). Anotherexample, mentioned previously, is the existence ofdifferent types of experts: given two experts in the


same area of expertise (i.e. domain), one expertmay find it easy to articulate his or her know-ledge, while the other may find it difficult.

Our second problem with Nonaka and Takeuchiis the lack of advice on how technology can helpthe process of making explicit tacit knowledge. As we will show in the next section, techniquessuch as repertory grids can be used to expose tacitknowledge. Other techniques, such as analysingsequences of behaviour, can uncover knowledgethat the expert cannot articulate, assumes is tooobvious to mention, or has not previously noticed.Prompts are an important way of movingknowledge from the tacit end of the continuum tothe explicit end. Providing the right promptsrequires you to identify what types of knowledgeyou are trying to capture, what type of expert isinvolved and what representations to use.Structured methods, along with the techniquesand tools described later, can help achieve this.

Avoiding the Tower of Babel

People talk different languages. They use jargon,acronyms and shortcuts when they talk to otherexperts within their domain. They have commonassumptions that they do not need to articulate.When experts talk to people who are not expertsin their domain, they find it difficult to break outof this: they assume their audience has a lot moreknowledge and understanding than it really does.Language is also rather imprecise. People use thesame word to mean different things (ambiguity)and use different words to mean the same thing(synonyms). These characteristics of language canlead to major problems for organizations – lack ofknowledge dissemination, misunderstandings andthe hardening of functional boundaries.

One technique in knowledge management thatattempts to alleviate such problems is the con-struction of a thesaurus of company terminology.We believe this is a useful first step. However,other actions need to be taken. A prime need is toform a clear and precise ‘language’ in which to represent the terminology of the domain. Form-ing the ‘language’ requires first classifying theterminology in terms of the types of knowledgepresent, then determining where it resides on ahierarchy of knowledge – abstract knowledge atthe top, specific knowledge at the bottom. Thelocation of a term is determined by the attributesassociated with it, which also need to be analysed

and classified. Using this technique, one can build amore precise description of the domain, and asso-ciate it with the everyday language that peopleuse. This is an example of an ‘ontology’, that is, a formal description of the static knowledge in a domain. Work in knowledge engineering hasdeveloped a number of ontologies.

As part of the SPEDE project, which wedescribe later, we have been developing a set ofontologies. One of these is based on linguisticsand is specifically used to help people commun-icate. Experience has shown that familiar gram-matical categories (e.g. nouns, verbs, and adjectives)are a good means of analysing a domain into itsontological primitives (e.g. concepts, tasks andattributes). Novice knowledge engineers, in par-ticular, find the mapping intuitively appealing anduseful. A special grammar, based on this onto-logy, has been created to facilitate the process oftransforming natural language descriptions intomore formal notations, and then back again. Useof this grammar aims to help employees deal withthe jargon, synonyms and ambiguous terminologythat act as barriers between them and the know-ledge they need.

Techniques and toolsTechniques

A number of techniques have been developed inknowledge engineering to embody the principlesdescribed earlier. Unfortunately, lack of spacedoes not allow us to describe many of the tech-niques: a fuller catalogue is given by Wielinga,Sandberg and Schreiber (1997). Instead, we shallfocus on one particular set of techniques that con-stitutes a methodology for acquiring knowledgefrom an expert during ‘knowledge acquisition’.

Two types of techniques are used. One type isnatural techniques (e.g. interviews and on-the-jobobservation); the other type is ‘contrived’ tech-niques. Knowledge engineers have developed thelatter to capture various types of knowledge thatare either inefficient or impossible to acquire usingnatural techniques. These contrived techniquesgenerally involve special ways of representingknowledge and/or special tasks that the expert is set (Hoffman et al., 1995). Many of the tools described here support these contrivedmethods. The methodology we shall briefly cover


is a process of moving from natural to contrivedtechniques. It is summarized in the followingsteps.

1. Conduct an initial interview with the expertto (a) scope what knowledge should beacquired, (b) determine to what purpose theknowledge should be put, (c) gain some under-standing of key terminology, and (d) build arapport with the expert. This interview (aswith all encounters with experts) should berecorded on either audiotape or videotape forlater analysis.

2. Transcribe the initial interview and analysethe resulting document (called a ‘protocol’)to produce a set of questions that cover theessential issues across the domain and thatserve the goals of the knowledge-acquisitionexercise.

3. Conduct a second interview with the expertusing the pre-prepared questions to providestructure and focus. (This is called a ‘semi-structured interview’.)

4. Transcribe the semi-structured interview andanalyse the resulting protocol, looking forknowledge types: concepts, attributes, values,classes of concepts, relationships betweenconcepts, tasks and rules.

5. Represent these knowledge elements in anumber of formats, for example, hierarchiesof classes (taxonomies), hierarchies of con-stitutional elements, grids of concepts andattributes, diagrams and flow charts. In ad-dition, document, in a structured manner,anecdotes (‘war stories’) and explanationsthat the expert gives.

6. Use the resulting representations and struc-tured documentation with contrived techniquesto allow the expert to modify and expand onthe knowledge you have already captured.

7. Repeat the analysis, representation-buildingand acquisition sessions until the expert ishappy that the goals of the project have beenrealized.

8. Validate the knowledge acquired with otherexperts, and make modifications wherenecessary.

This is a very brief description of one methodfor knowledge acquisition. It does not assumethat any previous knowledge has been gathered,or that any generic knowledge can be applied. In

reality, the aim would be to reuse as much pre-viously acquired knowledge as possible. Know-ledge engineers have developed techniques toassist this. For instance, knowledge engineers use ontologies and grammars to suggest ideas tothe expert such as general classes of concepts inthe domain and general ways in which tasks areperformed. This reuse of knowledge is the essenceof making the knowledge-acquisition exercise asefficient and effective as possible. The science ofknowledge acquisition is an evolving process: asmore knowledge is gathered and abstracted toproduce generic knowledge, the whole processbecomes more efficient.

In the next section, we describe a set of soft-ware tools that can be used to support the kind ofmethodology described above.

Tools

PC-PACK is a commercially available set ofknowledge engineering tools that we developedfollowing research on a variety of projects(Shadbolt, Motta and Rouge, 1993). Furtherinformation, as well as demonstration software, isavailable on the Internet (http://www.epistemics.co.uk). Although PC-PACK comprises twelvetools, we have found that a subset of these is ofparticular relevance to knowledge management:these are described below.

Protocol Editor. The Protocol Editor tool isused to analyse transcripts of interviews or anyother text-based information, e.g. reports, spe-cifications or manuals. The aim is to identify the important aspects of the domain, for example,the concepts, attributes, tasks and relationships. Thetool simulates the way someone would mark apage of text using different coloured highlighterpens. Each type of knowledge is associated with adifferent colour, for example, green for concepts,yellow for attributes. Using this tool, the user cango quickly through a document highlighting theimportant knowledge. Figure 2 illustrates the useof the Protocol Editor.

When the user has completed highlighting adocument, the marked text can be automaticallysaved in the PC-PACK database for use in allother tools.

Laddering tool. The Laddering tool enables theuser to build various hierarchies of knowledge. It


displays each hierarchy as a tree, with abstractcategories towards the left, and specific categoriestowards the right. Instances (i.e. unique entities)are shown on the extreme right. The term ‘ladder-ing’ comes from a particular way of acquiringknowledge that involves a structured questioningtechnique (Corbridge et al., 1994). PC-PACKprovides three basic types of ladders: a ladder ofconcepts, a ladder of attributes and values and aladder of tasks. Within each of these, the userstarts by using the knowledge elements identifiedin the Protocol Editor tool, and adds new con-cepts, attributes and relationships as the ladderingcontinues. Full editing facilities are available: forexample, an element in a ladder can be moved toanother position using a simple ‘drag and drop’operation. Figure 3 illustrates the Laddering toolin use.

A fourth type of ladder is also included. Thisrepresentation, suggested by Andersen Con-sulting, is a ladder of requirements (called the‘Requirements Ladder’). This is covered later.

Matrix tool. The Matrix tool supports asso-ciating attributes to concepts, as well as enteringvalues. It presents a matrix (i.e. grid) withconcepts listed down the left, and attributes listedacross the top. This tool is similar to a spread-sheet; however, it has some special features thathelp to save time when entering knowledge. Onefeature is that the hierarchical structures from the concept and attribute ladders are retained inthe matrix. This enables a method called ‘inherit-ance’: when an attribute is associated with a high-level concept, it, and the values it takes, areinherited by all its sub-concepts. This is anexample of ‘default reasoning’. For example, onedoes not want to have to enter the number ofwheels that the concept ‘car’ has for every type ofcar. It is easier to assume a default value of fourwheels for all cars, then only overwrite the valuefor cars without four wheels (e.g. three-wheelers).

Repertory Grid tool. The Repertory Grid toolprovides a number of facilities. The first feature


Figure 2. Screen shot from the PC-PACK Protocol Editor

allows the user to generate new attributes using a technique called ‘triadic elicitation’. Simply put, the tool asks the expert what is similar anddifferent about three randomly-chosen concepts,that is, in what way are two of them similar anddifferent from the third. This is an effective wayof eliciting attributes that experts cannot immedi-ately articulate. The second feature of this tool is based on rating concepts along a continuum for which the end points are opposing attributes:for example, fast–slow, or accurate–inaccurate.This idea is based on a psychological theory calledpersonal construct psychology (Kelly, 1955),which is widely used in areas such as clinicalassessments. A 9-point scale is used in PC-PACK,so that the expert can make fine distinctionsbetween concepts. For instance, the relationshipbetween various measuring methods can be estab-lished by assessing each of them on scales such as accurate–inaccurate, cheap–expensive andreliable–unreliable. A third feature of this toolapplies the resulting scales to a statistical tech-nique called cluster analysis. This produces a grid

of concepts against attributes in which the position of concepts and attributes in the gridshows how similar they are to other concepts or attributes, i.e. it clusters together those withsimilar scores on the scales. Figure 4 shows such a grid for various measuring methods used inmanufacturing.

The lines to the bottom and right of the grid inFigure 4 indicate similarity ratings – joining linesthat are closer to the grid indicate more similaritybetween linked concepts or attributes. In Figure 4,we can see that accuracy and ease of use are sim-ilar, indicating that accurate machines are alsoeasier to use. This relationship may be somethingthe expert had not articulated before, or not havenoticed before. Thus, the tool can be used to un-cover hidden correlations and causal connections,i.e. tacit knowledge.

Control Editor. Unlike the previous tools, whichdeal essentially with static knowledge, the Con-trol Editor is used for acquiring and representingdynamic knowledge: it is used for building


Measurement Tools

Contact Meas Tools

Non-Contact Meas Tools

Ultrasonics

Caliperscope

Manual Olivetti Machine

Shutter Gauging

Rise & Fall

Machsize

Dial Indicator

Vernier Height Gauge

Profile Analysers

CMM

Laser

CT

White Light

St

Ult

Figure 3. Screen shot from the PC-PACK Laddering tool

process-control diagrams for individual tasks orgroups of tasks. This tool has different symbolsfor tasks, for the inputs and outputs of tasks, fordecision points, for data flow and for control flow,in a similar way to a flow chart. It also has anumber of specialized symbols, including one forthe ‘agent’ (i.e. person, group or computer) thatperforms a task. A particularly important featureof the Control Editor is the way a hierarchy oftasks can be built and displayed. Hierarchies arenavigated using a three-dimensional feel, where-by double-clicking on a task symbol will reveal a‘lower’ page representing how that task is per-formed. Using this facility, the user can start bymodelling a task at a very high level (made up of a few sub-tasks), then double-click on each of

these sub-tasks to build the next layer of the taskhierarchy. This is much clearer than having asingle large two-dimensional diagram, and allowsthe user to set the scale (i.e. level or granularity)of what knowledge is acquired.

Hyperpic tool. The tools described so far havemostly supported activities such as analysis andcodification. The Hyperpic tool allows the user totake a more flexible approach to storing, acquir-ing and using knowledge. Right-clicking on any ofthe concepts, attributes or tasks shown in theother PC-PACK tools invokes the Hyperpic tool.The tool allows text and pictures to be entered inorder to document/annotate the knowledge alreadyrepresented. The tool supports a hypertext format


Figure 4. Screen shot from the PC-PACK Repertory Grid tool

that allows words to be highlighted and ‘linked’ toother pages in the document (in the way the wwwoperates). This allows structured knowledgedocuments to be constructed, which can be basedon the hierarchies produced in the Ladderingtool. We often use the Hyperpic tool to produce athesaurus of relevant terminology. For those whowant to produce Internet or intranet knowledgedocuments, the Hyperpic tool can automaticallyproduce files in the correct format (i.e. HypertextMarkup Language [HTML]) at the ‘press of abutton’. Organizations use PC-PACK in this wayto provide a smooth and efficient transition frominside the expert’s head to inside the company’sInternet-based knowledge base.

Case studies

To illustrate the ways in which the principles,techniques and tools from knowledge engineeringcan be of real practical benefit to knowledgemanagement, we present four case studies in thissection. All cases involved the use of the PC-PACK knowledge tool kit either in its originalform, or in a form adapted to the needs of theparticular organization and application. The casestudies we present here are not the only cases thatillustrate our message.

Andersen Consulting

Andersen Consulting is a global management andtechnology consulting organization whose missionis to help its clients to become more successful.The organization helps its clients link strategy,people, processes and technology.

Andersen Consulting use PC-PACK for bothexpert-system development and knowledge man-agement. Montero and Scott (1998) give a fulldescription of its use in systems development, so we will focus on its other role – as an aid toknowledge auditing, knowledge sharing anddecision-making.

Numerous decisions are made to arrive at thebest solution during processes such as planningand design. However, often the organization loses much of the knowledge of why a particulardecision was made and what alternatives werediscarded (i.e. the ‘audit trail’): those involvedeither forget what happened or fail to keepadequate records. Thus, stakeholders in such

decisions (e.g. managers, decision implementers,and future decision-makers) have no access toknowledge that could be vital for them. Studiesshow that this is especially important in large-scale development projects (Ramesh and Dhar,1992). A tool that can capture the rationale behinddecisions would, therefore, be an important aid toknowledge management.

Andersen Consulting wanted such a tool to beadded to PC-PACK. At their suggestion, part of the Laddering tool was configured to allow arequirements engineer to ladder requirements,issues, positions, arguments and assumptions, andthe relations between them, as well as to defineand visualize alternative decisions (as sets of posi-tions on issues). Requirements engineers use theLaddering tool, with this addition, in combinationwith the Protocol Editor. According to AndersenConsulting, the result is not only useful for model-ling, but also a ‘powerful brainstorming tool forthe interaction between expert and analyst’(Montero and Scott, 1998).

Unilever

Unilever is an international organization withover 300 000 people worldwide and having over 1000 brands. The importance of knowledgemanagement to Unilever’s continued success isrecognized at the highest levels of management.Unilever currently use PC-PACK in both in its‘traditional’ role during the development of ex-pert systems, and in more non-technological areasof knowledge management. It is the latter that webriefly describe below.

The main use of PC-PACK to support know-ledge management at Unilever is in ‘knowledgeworkshops’. By projecting what would normallyappear on the VDU on to a large screen, a groupof experts can interact and represent the currentstate of their thinking. In this way, they can buildand critically analyse an ontology of the domainin question. Tools, such as the laddering andmatrix tools, are used dynamically to add, deleteand modify elements. Thus, the group can reach aconsensus on the main knowledge categories andrelationships in the domain. Since this is notknown beforehand, these sessions are as muchabout ‘brainstorming’ as they are about know-ledge mapping. One can see this as an example ofwhat Leonard-Barton (1995) refers to as ‘creativeabrasion’ leading to creativity and innovation.


One use of such a method is to identify certainproduct ranges and their associated attributes.This provides knowledge for such activities asproduction restructuring or devising new market-ing strategies. A more elaborate use is to buildladders of typical problems, their causes and pos-sible solutions. Attributes of these are then identi-fied using the repertory grid and matrix tools.Automatic translation of ladders and matricesproduce various graphical representations. Thesecan be used to summarize what causes and solu-tions apply to a particular problem.

Rolls-Royce

Rolls-Royce is a world-leading power-systemsbusiness, providing products and services tocommercial and military customers in propulsion,electrical power and materials-handling marketsaround the world.

Alongside its involvement in the SPEDE pro-ject (covered below), Rolls-Royce has introduceda programme using PC-PACK to capture anddisseminate best practice. The results are beingincluded in their company ‘Capability Intranet’for knowledge sharing both within and acrossdepartments. In line with the advice of Davenportand Prusak (1998), Rolls-Royce are gatheringbest practice in the context of a wider programmeof knowledge mapping and transfer.

A key feature of this programme is that relat-ively novice users are applying the methods andtools of knowledge engineering for knowledgemanagement. We see this as a vital aspect of aknowledge technology. Companies have suchvast amounts of knowledge that knowledge man-agement must be performed by all employeesrather than a small group of in-house experts or consultants. Hence, the use of PC-PACK inRolls-Royce is being performed by companyemployees as part of a three-month secondmentto a special facility set up at the University ofNottingham. This secondment, which currentlycomprises 16 employees, includes an intensivetwo-week training programme, followed by aten-week project. Such projects have focused ondesign and manufacturing and have includedwork in the following areas:

• capture and dissemination of knowledge re-quired for the design of jet engine compon-ents, e.g. compressor blades and annulus;

• identification of best practices within manu-facturing inspection, especially co-ordinatemeasuring machines;

• development of a materials knowledge baseand advice system for designers (who typicallyhave limited knowledge of the properties anduses of new types of materials);

• analysis of human resource issues withindesign, especially selection and training.

For an area with no previous knowledge on theCapability Intranet, a pair of trained employeesusually produce around 350 quality web pagesfrom scratch by the end of their ten-week project.Estimates by Rolls-Royce suggest that this isaround five times more than would be producedwith conventional methods. Not only that, but theknowledge gathered is seen as better structured,better validated and better focused on userrequirements, such that knowledge retrieval anduse are enhanced. Furthermore, there is morethan a ten times reduction in the time neededfrom experts.

Based on the results, Rolls-Royce estimate thatintroduction of a knowledge technology based onPC-PACK can provide potential savings of sev-eral million pounds in quality documentation alone.

Results from this pilot study demonstrate thatknowledge engineering techniques and tools arerelatively easy to learn and apply by novice userswithin real knowledge management projects.

The SPEDE project

SPEDE is a large IMI-funded project involvingboth industry and academia. The industrialpartners are Rover, Rolls-Royce and Computer-vision; the academic partners are the universitiesof Leeds, Nottingham and Warwick. The overallobjective is to produce a set of widely applicablemethods and software tools to assist and guide thebusiness process engineer in the task of businessprocess improvement (BPI); mainly BPR, butincluding other improvement approaches. Forvalidation purposes, the focus is on the generalapplicability of these methods within the productintroduction process at component level.

Many methods and tools are available thatclaim to support BPR and BPI. An analysis byBach et al. (1996) reveals both the large numberof methods in existence and the great extent towhich they contradict one another. They conclude


their examination with a list of requirements forthe next generation of methods and tools. Theseinclude the need for an integrated set of toolswhich can support: (a) the reuse of existing in-house solutions, (b) the use of reference modelsof industry-wide best practice, and (c) the dissem-ination of company know-how. SPEDE aims tosatisfy these requirements by having three mainelements.

1. It provides knowledge acquisition tools thatallow rapid elicitation of BPI requirements,structured acquisition of heterogeneous pro-cess information and validation of capturedinformation. These tools aid the dissemina-tion of company know-how by establishinglinks to corporate memory and knowledgemanagement resources.

2. It establishes and makes use of a database ofgeneric business processes to minimize theeffort in the creation and use of business pro-cess models. This, combined with an ontology-based retrieval system, allows the reuse ofexisting in-house solutions, as well as makingavailable reference models of industry-widebest practice.

3. It provides a demonstration environment that facilitates organizational change usingprocess simulation and process enactment.

Another important aspect of SPEDE is thatanalyses of implemented solutions are used tomodify and update the database of generic models,so that the database evolves to become a reposit-ory of organizational best practice.

The SPEDE tool set includes a number of PC-PACK tools, some of which have been modifiedand extended to be more useful for a BPI initiative.In particular, work has focused on the develop-ment of process modelling tools, grammars andontologies. These have allowed creation of gen-eric models of business processes and the designof an ontology-based retrieval system. Ongoingwork is testing and refining the tools and methodsat Rover and Rolls-Royce.

Summary and concluding remarksSummary

We have attempted to convey our belief thatprinciples, techniques and tools, developed for

knowledge engineering, can be modified andextended to help organizations with knowledgemanagement. There have been four strands tothis argument:

1. With its basis in artificial intelligence, know-ledge engineering can draw on a rich heritagefrom a number of fields such as philosophyand experimental psychology, from which ithas inherited many ideas, and sound practicalguidance.

2. Knowledge engineering has been dealingwith knowledge for the past 15 years, fromboth a theoretical and practical perspective,and has built up a stock of principles, tech-niques and tools that have a good track recordin a wide range of applications.

3. There is a substantial overlap between theconcerns and problems encountered in bothknowledge engineering and knowledge man-agement because, in many areas, they aretrying to do the same thing – use technologyto ‘transport’ knowledge from an expert in adomain to those who are not experts.

4. A number of organizations (e.g. AndersenConsulting, Rolls-Royce and Unilever) arefinding real and significant benefits in usingthe knowledge engineering techniques andtools for a number of different knowledgemanagement activities such as brainstorming,identifying best practice, population of intra-nets, improving decision-making and processimprovement.

Concluding remarks

There are two important caveats we would like tomention. First, the techniques and tools describedin this paper have only been applied in real know-ledge management settings for the past couple ofyears, and though results look very promising,they have not been thoroughly tested with theempirical rigour that we would like to see. A fulldouble-blind test of knowledge engineering tech-nology against current knowledge managementpractices is yet to take place (although we plan todo this in the next year). Thus, claims such as a five-fold increase in efficiency over existingmethods must be taken cautiously. In some ways,initial use of these new techniques and tools hasbeen too successful. Consequently, we find wehave to manage organization’s expectations and


reiterate that knowledge engineering methodsare not the panacea for all their knowledge man-agement problems.

The second caveat is our belief that technology(any technology) alone will not allow an organ-ization to manage its knowledge assets as effect-ively as possible. As Davenport and Prusak pointout in their recent book Working Knowledge,knowledge technology must be supported by boththe right culture and the right organizational struc-ture if it is to work effectively. An organizationmight have the most efficient intranet in the world– easy to use, easy to understand, on everybody’sdesk, populated by all the useful knowledge thatan employee needs – and yet it may still be over-looked if people are too stubborn, proud, cynicalor demotivated to use it.

Some might say that cultural problems areinsurmountable using knowledge technology. Wedisagree. We believe that with further modifica-tion and adaptation our techniques and tools canbe used to capture the ways in which behavioural,cultural and organizational change takes place,and how it can be managed best. There is expertiseinvolved in such processes, which can and shouldbe captured and disseminated. The application oftechnology to capture knowledge about know-ledge management might, we believe, herald a newera for both knowledge technology and organiza-tional effectiveness.

References

Bach, V., L. Brecht, T. Hess and H. Osterle (1996). EnablingSystematic Business Change. Verlag Vieweg, Wiesbaden.

Chi, M. H., R. Glaser and M. Farr (eds) (1988). The Nature ofExpertise. Lawrence Erlbaum Associates, Hillsdale, NJ.

Corbridge, C., G. Rugg, N. Major, M. Shadbolt and A. M.Burton (1994). ‘Laddering: Technique and Tool Use inKnowledge Acquisition’, Journal of Knowledge Acquisition,6, pp. 315–341.

Davenport, T. H. and L. Prusak (1998). Working Knowledge:How Organizations Manage What They Know. HarvardBusiness School Press, Boston, MA.

Hayes-Roth, F., D. A. Waterman and D. P. Lenat (eds) (1983).Building Expert Systems. Addison-Wesley, Reading, MA.

Hoffman, R., N. R. Shadbolt, A. M. Burton and G. Klein(1995). ‘Eliciting Knowledge from Experts: A Method-ological Analysis’, Organizational Behavior and DecisionProcesses, 62(2), pp. 129–158.

Kelly, G. A. (1955). The Psychology of Personal Constructs.Norton, New York.

Leonard-Barton, D. (1995). Wellsprings of Knowledge.Harvard Business School Press, Boston, MA.

Minsky, M. and S. Papert (1974). Artificial Intelligence.Condensed lectures, Oregon State System of HigherEducation, Eugene.

Montero, L. and C. T. Scott (1998). Improving the Quality ofComponent Business Systems with Knowledge Engineering.To be presented at the 11th Knowledge Acquisition forKnowledge-Based Systems Workshop.

Nonaka, I. and H. Takeuchi (1995). The Knowledge-CreatingCompany. Oxford University Press, New York.

Polanyi, M. (1966). The Tacit Dimension. Routledge & KeganPaul, London.

Ramesh, B. and V. Dhar (1992). ‘Supporting Systems-Development by Capturing Deliberations During Require-ments Engineering’, IEEE Transactions on SoftwareEngineering, 18(6), pp. 498–510.

Ryle, G. (1949). The Concept of Mind. Hutchinson, London.Schreiber. A. Th., J. Akkermans, A. Anjewierden, R. De

Hoog, N. Shadbolt, W. Van De Velde and B. Wielinga(forthcoming). Engineering and Managing Knowledge.

Shadbolt, N. R. and A. M. Burton (1995). ‘KnowledgeElicitation: A Systematic Approach’. In: J. R. Wilson and E. Corlett (eds), Evaluation of Human Work: A PracticalErgonomics Methodology, (2nd revised edn). Taylor andFrancis, London.

Shadbolt, N. R. and K. O’Hara (1997). ‘Model-Based ExpertSystems and the Explanation of Expertise’. In: P. J.Feltovich, K. Ford and R. Hoffman (eds), Expertise inContext. AAAI Press/MIT Press, Menlo Park, CA.

Shadbolt, N., E. Motta and A. Rouge (1993). ‘ConstructingKnowledge-Based Systems’, IEEE Software, November, pp. 34–39.

Wielinga, B., J. Sandberg and G. Schreiber (1997). ‘Methodsand Techniques for Knowledge Management: What hasKnowledge Engineering to Offer?’, Expert Systems withApplications, 13(1), pp. 73–84.


from knowledge engineering to knowledge - eprints soton

Documents