Knowledge management process models for knowledge maps

Knowledge management process models for knowledge maps

M E T I S D 4 . 3 III

Colophon

Date : March 1st , 2004

Version : 1.0

Change :

Project reference : Metis D4.3

TI reference :

URL :

Access permissions : Public

Status : Final

Editor :

Company : University of Amsterdam

Author(s) : Robert de Hoog

Synopsis:

This report investigates how knowledge

management process models consisting of a

set of tasks, can be linked to knowledge maps.

Several models and properties of knowledge

are reviewed. The result is a combined model

of knowledge management tasks and

properties of knowledge that, when

incorporated in a knowledge map, can support

task performance. Based on this model a

prototype of a knowledge mapping tool can be

designed and built.

IV

Preface

Most knowledge mapping efforts are directed toward mapping documents and other sources

by using the domain content of these documents. While these maps can be useful for people

engaged in the actual use of the knowledge, this does not necessarily hold for people

concerned about managing the knowledge. A simple example from Basell can explain this. A

person that has to repair or replace a component in the Extruder, needs the knowledge how

to do this. This knowledge can be described in manuals and can also reside in people’s

minds. A person that has to make sure that Basell possesses the knowledge to replace and

repair a component, is more interested in how stable this knowledge is, whether the

proficiency level of the knowledge is adequate, how accessible this knowledge is and other

aspects. These properties of knowledge can be seen as a kind of meta-knowledge,

knowledge about knowledge. Most of the time this meta-knowledge cannot be extracted from

the domain content. As a consequence, knowledge mapping efforts relying on the content of

documents will often fail to provide the information needed to deal with many knowledge

management issues.

More in general it can be said that different goals give rise to different knowledge maps and

that goals can be derived from tasks people are performing. This implies that identification of

tasks should most of the time precede knowledge mapping efforts. In this report several

knowledge management process models consisting of tasks are reviewed and compared.

Several criteria for constructing “good” knowledge management process models are

identified. From another angle, properties of knowledge that have been proposed in the

literature, independent of any knowledge management process model, are reviewed and

combined. Synthesizing both in a knowledge management process–knowledge properties

model, leads to a framework that can be used to design and build a knowledge mapping

environment that can support knowledge management.

M E T I S D 4 . 3 V

About Metis

Knowledge management: smart employees and smart organisations

Each company, even a company with knowledge workers, needs to invest to be able to

continuously improve itself, that is, to become smart. The objective of knowledge management

is to transform companies from organisations with just smart people to smart organisations. A

smart organisation knows what knowledge it wants to have, has employees that have this

knowledge, and uses technologies in a smart way to support the knowledge workers in the

organisation. Of course, a smart organisation uses its network to acquire knowledge.

Knowledge management is something you do, so why research?

Managing knowledge, sharing knowledge, and making knowledge available, are things

companies need to do themselves. In practice difficulties appears though. It has become

clear, that companies that apply knowledge management, are left with a number of

unanswered questions. Research to find solutions for those questions is therefore needed.

Examples of those questions and solutions are:

- How can I enhance the

innovative power of my organisation?

- How do I ensure that the knowledge and vision of my smart people becomes knowledge of my organisation?

- Find combinations of technical support and organisational incentives that stimulate the exchange of knowledge, experience and vision, and the application of new ideas

- Am I doing well with knowledge management?

- Identify indicators of good knowledge management

- What knowledge does my organisation have?

- They say my organisation has smart people, but how do I know?

- Extract knowledge from communication and documentation and provide relevant views on this knowledge for knowledge workers and knowledge managers

- Does my organisation sufficiently exploit the options to communicate with the outside world? To learn from customers?

- Identify the opportunities that communication and network infrastructures offer for the exchange of information and knowledge across the borders of organisations

The current project explores these types of solutions. In this project we study how companies

can apply knowledge management to enhance their business results. We support knowledge

managers with insights and instruments. These could be innovative technologies, like the

automatic generation of knowledge maps, but also guidelines, new business models or future

scenarios. For this, we analyse existing knowledge management instruments, like

communities and document management systems, elaborate on, and apply them in a specific

company context of the project partners. In other words, we look ahead, and work together

with companies to obtain tailored and long-lasting solutions. Thís is knowledge management

between industry and the academic world in optima forma. For more information see Metis

website.

VI

Management summary

This report investigates what aspects should be represented in knowledge maps that can

support the performance of knowledge management tasks. In this context a clear distinction is

made between using the knowledge and managing the knowledge. It is argued that this are

different tasks that require mapping of different aspects of knowledge.

Accepting that managing knowledge is a separate task, the next question to answer is how

one can describe or model this task in more detail. This is needed because it is assumed that

the information in knowledge maps are functional in the context of one or more tasks. This

question is addressed by reviewing knowledge management process models described in

previous Metis deliverables and the knowledge management literature. The Metis deliverables

referring to knowledge management tasks most of the time do this in an incomplete or

somewhat fuzzy way. The general knowledge management literature abounds with models,

but there are at least four available that keep a more or less clear distinction between

management and work. These models are reviewed and selected on the basis of a set of

criteria consisting of cyclical nature, knowledge specificity, separating management from

work, appropriate grain size, tool independency and time horizon. Not all of them perform well

on all these criteria.

As knowledge maps will basically display values of variables or properties, the question is

which properties? Based on the knowledge management literature a set of agreed upon

properties is constructed that could be used in knowledge management relevant knowledge

maps. It is concluded that the value of the majority of these properties cannot or not easily

derived by using techniques for knowledge mapping for work, for example based on the

content of documents.

In order to make things more specific for knowledge management two more aspects are

analyzed and added:

• Characteristics of knowledge that set knowledge apart from other organizational

resources

• General management goals that must be satisfied by (knowledge) management

activities

Based on knowledge management tasks, relevant properties, characteristics of knowledge

and general management goals, three tables are constructed that together form a knowledge

management – knowledge properties model for knowledge maps. Based on this model one

can select either a knowledge management task, a knowledge characteristic or a

management goal and find the knowledge properties that can be used to support the chosen

perspective. These tables can be used to design meaningful knowledge maps for knowledge

management as a management task, but also for designing web sites/portals that organize

knowledge about knowledge management.

M E T I S D 4 . 3 VII

Table of Contents 1 INTRODUCTION.......................................................................................................................1

2 KNOWLEDGE MANAGEMENT TASKS IN METIS..............................................................3

2.1 JUST-IN-TIME KNOWLEDGE MANAGEMENT ..............................................................................3 2.2 KEY PERFORMANCE INDICATORS FOR KNOWLEDGE MANAGEMENT IN A COMMUNITY OF

PRACTICE ..........................................................................................................................................5 2.3 MANAGING KNOWLEDGE MANAGEMENT.................................................................................7 2.4 KNOWLEDGE MAPPING ...........................................................................................................8 2.5 FROM KNOWLEDGE MAP TO KNOWLEDGE WEB ......................................................................10 2.6 SUMMARY ...........................................................................................................................10

3 KNOWLEDGE MANAGEMENT TASKS IN THE LITERATURE......................................11

3.1 THE HOLSAPPLE-JOSHI MODEL .............................................................................................11 3.2 THE CIBIT MODEL...............................................................................................................17 3.3 THE WIIG ET AL. MODEL ......................................................................................................23 3.4 THE DUINEVELD ET AL. MODEL ............................................................................................28 3.5 SELECTION/CONSTRUCTION CRITERIA FOR A KNOWLEDGE MANAGEMENT MODEL AND

KNOWLEDGE MANAGEMENT TASKS ..................................................................................................29

4 KNOWLEDGE PROPERTIES ................................................................................................32

5 A KNOWLEDGE MANAGEMENT – KNOWLEDGE PROPERTIES MODEL FOR

KNOWLEDGE MAPPING..............................................................................................................43

5.1 CHARACTERISTICS OF KNOWLEDGE ......................................................................................43 5.2 KNOWLEDGE MANAGEMENT GOALS......................................................................................47 5.3 SUMMARY AND REFLECTION ................................................................................................51

6 REFERENCES..........................................................................................................................53

M E T I S D 4 . 3 1

1 Introduction

The knowledge management literature, which exists now for more than 10 years, is still in

considerable terminological disarray. Though this is admissible for an emerging discipline, in

the long run some kind of standardized set of terms and meanings should emerge.

Unfortunately there are still not many visible signs of this desirable process. This holds also

for the Metis project. A brief look at the 2002 deliverables shows a bewildering variety of

words, concepts and terms. As a consequence it is very difficult to see the forest for the trees.

Detecting similar developments and approaches is almost impossible, which in the end will be

detrimental to the project’s objectives. The same observation can be found in the Metis Quick

Guide 2002.

In the context of the knowledge mapping task(s) the state of affairs is more or less the same.

Knowledge mapping, for better or for worse, requires a goal and this goal determines what is

mapped and how it should be mapped. The analogy with real maps is clear. The map needed

for a walking tour in the Alps differs from the roadmap you need to traverse the same area. A

map of the geology of a region differs from a map of the waterways. The first is needed to

detect geological formations, the second is for navigating purposes. In all these examples the

nature of the map is derived from the goal the user wants to pursue with the map.

In this deliverable I will explore how the nature of knowledge maps is related to goals

someone wants to achieve with these maps. Of course these goals are approached from a

knowledge management perspective, which in turn requires some clear concepts about what

knowledge management tasks are or could be. Most of the time our goals are bound to real

world tasks we want to accomplish, see the verbs in the map examples above: walking,

traversing, detecting and navigating. It is here that the terminological confusion hits hardest.

No clear tasks, no clear goals, no clear knowledge mapping requirements. The same line of

relating requirements to tasks, is also visible in requirements engineering in general

(Lauesen, 2003).

The identification of knowledge management tasks can proceed along two directions:

• A descriptive approach: people performing knowledge management in real life are

observed or interviewed, and from these data a descriptive model of knowledge

management tasks is derived.

• A prescriptive approach: from a theoretical/analytical viewpoint a normative model is

built that prescribes what “good” knowledge management tasks are.

Both approaches are present in the Metis project as well as the general literature on

knowledge management. Sometimes both approaches meet. This happens when developers

of normative models try to find out whether their theoretical work stands the test of practice.

Descriptive models are sometimes transformed into normative ones by stating that reasonable

people should follow “best practices”. There is no a priori preference for one approach. The

2

only requirement for authors could be to ask them to be clear about which approach, or

combination, they pursue. However, this requirement is only rarely met. The approach chosen

here is decidedly normative, but to a certain extent it is influenced by experiences from the

practical application of normative and descriptive models.

In this report I will first briefly review several deliverables from the 2002 Metis batch to find out

what they say about knowledge management tasks. Next I will review the existing literature on

definitions of knowledge management tasks. This is followed by an inventory of domain

independent properties of knowledge (meta-knowledge or knowledge about knowledge) that

were proposed in the literature. Finally I will develop a set of knowledge management tasks

and combine these with properties of knowledge that should be represented/mapped in order

to be able to perform these tasks adequately.

M E T I S D 4 . 3 3

2 Knowledge management tasks in Metis

This chapter reviews several documents from the Metis project on the presence or absence of

information about knowledge management tasks. All reports were scanned, but only the ones

having (part of) the sought information are discussed in more detail. When reading the

sections below the reader must be aware that these reports were read with a very specific

objective in mind. So if the documents are criticized, they are criticized in the light of that

objective. As most authors did not have this objective, one cannot blame them. In other

words: if I find something missing in a document, this does not mean that it is a “bad”

document. It can serve other objectives in an excellent way!

2.1 Just-in-time knowledge management

The report by d’Huy et al. (2002) seems to focus on a subset of knowledge management

where optimisation of the match between knowledge demand and knowledge supply in

organisation is the central concern. As this research is, until now, mainly based on theoretical

considerations and tries to define a model “for” JIT knowledge management, it can be

classified as a prescriptive approach.

Before the authors embark on their work, they first review several models from the literature.

They adopt the knowledge value chain approach from Weggeman (p.16) as the definition of

the knowledge management process (and by implication knowledge management tasks).

However, later they introduce other models, for example the Baets model and the KnowMe

models, which are far less clear in their identification of tasks. To make matters even more

complex, they define on p.26 a set of questions, which in my view would constitute a fairly

explicit brief for JIT knowledge management. If I rewrite these questions as tasks to find

answers, and I combine them with the specific transformation considerations on p.33, the

following set of knowledge management tasks would emerge:

• Task 1 Determine knowledge demand

o Task 1.1 Find out the actual demand for knowledge inside the organisation

o Task 1.2 Find out the the knowledge demand expected in the future

o Task 1.3 Determine which demand of knowledge comes from outside the

organisation (market, business)

o Task 1.4 Assess need to react to these demands

• Task 2 Determine knowledge supply inside the organisation

o Task 2.1 Find out which knowledge is available inside the organisation

4

o Task 2.2 Determine the location of the specific knowledge inside the

organisation

o Task 2.3 Find out which knowledge is not available inside the organisation

and for which a certified demand has been determined in Task 1.4.

• Task 3 Bring demand and supply together on a JIT basis

o Task 3.1 Define fitting knowledge transformation instruments (e.g., from table

2, p.34)

o Task 3.2 Determine costs associated with the transformation instruments

o Task 3.3 Find out whether the time needed to effectuate the transformation

fits the time available for meeting the demand

o Task 3.4 Decide between outsourcing and do it ourselves

Though one could argue about the completeness of this model or the specificity for

knowledge management (if “knowledge” was replaced by “iron”, would the model be

different?), there can be no doubt that it is a task model for JIT knowledge management. In

addition the authors give on p.32 a brief list of characteristics for describing the demand1:

• time related: the knowledge is needed at a certain time

• type: demand for a product/service, result, person..

• level: oriented on individual, group or organisation

• quality

• quantity

• hardness (what possibilities there are to redefine the demand)

Of course this list is only a sketch, but gives at least a clue about properties of knowledge that

should be described to support the JIT knowledge management tasks. One should note that

these properties are completely different from the properties that are usually mapped in

(automated) knowledge mapping tools. These focus on the content, because they can be

derived from the knowledge carriers (most of the time documents). Automated derivation of

properties like the ones listed above from the carriers is almost impossible as the content will

not contain any clues about, for example, the “time related” attribute.

1 Note that this is about properties of the “demand”, which can differ from the properties of the knowledge. One could argue that “demand” is a property of knowledge which has also properties.

M E T I S D 4 . 3 5

Given what was said above, it seems a bit odd that in the final chapter the authors introduce

the “first JIT knowledge management model” shown below in Figure 1.

Figure 1: JIT knowledge management model by d’Huy et al. (2002)

Compared with their earlier (reconstructed in the task model above) knowledge management

model, this model is less explicit in terms of tasks. Moreover the authors appear to be

confused about the model’s status. The text says it’s a model “for” JIT knowledge

management but the caption calls it a model “of” knowledge management. The former refers

to a prescriptive view, the latter to a descriptive one.

To summarize: in my opinion this report contains a skeletal task model for JIT knowledge

management. It also shows that mapping knowledge for JIT knowledge management has to

focus on properties that cannot, or not easily, automatically derived from the content of

documents. At the same time, this last aspect must be described in more detail to make a

clear link between JIT knowledge management tasks and mapping the, for these tasks,

relevant properties of knowledge.

2.2 Key performance indicators for knowledge management in a community of practice

The main question addressed by this document (de Moor & Smits, 2002) is: how to measure

and use key performance indicators in knowledge management in organisational communities

of practice. This is partly addressed by investigating the literature and partly by a case study

in a small knowledge intensive organisation. Thus it can be seen as a combination of a

prescriptive and a descriptive approach. Nonetheless, an answer on the main question would

be more of a prescriptive than a descriptive nature. Key performance indicators can be seen

as properties of knowledge and/or knowledge processes that one has to measure in the

context of knowledge management tasks. Thus performance indicators presuppose tasks in

whose context their measurement is meaningful.

6

The case study in this report is inside a company for which innovation is the key to survival.

This means that the process of knowledge creation is taken as the focus. As the authors say

on p.8: “Knowledge management concerns the support and stimulation of this cyclical process

of knowledge creation”. The cyclical process they are referring to is the well-known Nonaka-

Takeuchi model of knowledge creation. Next the question could arise how to organise this

“support” and “stimulation”. Concerning this problem the authors propose a mixture of

enabling conditions, types of Ba, guidelines, strategies and learning disabilities (derived from

the work of Senge). From this mixture it is very difficult to derive a set of knowledge

management tasks. If I apply the same method as in the previous section, rephrasing the

components of the mixture as tasks, a rather disorganized set remains with no discernible

(sequential) structure. However, this seems not necessary. When they arrive at defining

indicators they basically return to the four knowledge processes from Nonaka & Takeuchi,

which are transformed into knowledge types in the following way:

• Socialization -> Sympathized knowledge

• Externalization -> Conceptual knowledge

• Combination -> Systemic knowledge

• Internalization -> Operational knowledge

For each category they identify indicators (for example “direct communication links” for

sympathized knowledge) which are used to give a “quick overview of the effectiveness of the

various …. processes”. Re-engineering this to tasks, it amounts to saying that there are at

least four knowledge management tasks in whose context these measurements are

meaningful:

• Promote and monitor socialization processes

• Promote and monitor externalisation processes

• Promote and monitor combination processes

• Promote and monitor internalisation processes

It can easily be seen that this still are very general tasks without the details needed to carry

them out. On the other hand, it is also evident that the indicators used, the properties of

knowledge to be mapped to support these tasks, are hardly or not at all derivable in an

automatic way from documents containing knowledge content. In this respect the same holds

as in the previous section.

Finally the authors introduce a model of levels of knowledge management for a community of

practice (see Figure 2).

M E T I S D 4 . 3 7

Figure 2: Knowledge management model by de Moor & Smits (2002)

When detailing these levels on p.27, several task related terms appear. For example:

“Operational management receives (looks for) customer requests for a knowledge intensive

product or service. Operational KM then forms a project team consisting of some knowledge

workers …… Operational KM needs an up-to date overview of free and available resources

(represented in map1) to be able to effectively create the project team”. Comparable

statements are made for the other levels. It should be noted that the “maps” (or indicators)

referred to are completely different from the set of indicators identified for the global tasks

enumerated above. Thus from a knowledge task-knowledge mapping perspective this section

of the report is the most interesting. A more detailed description of the tasks/indicators related

to these levels would be welcome.

Summarizing: part of the report does not contain clear indications of knowledge management

tasks. Only the last chapter, by defining different levels of knowledge management,

approaches what could be labelled as an initial set of knowledge management tasks. At the

same time it has become clear that in both “parts” of the report knowledge mapping must be

focused on properties of knowledge or knowledge processes that cannot be automatically

derived from documents.

2.3 Managing knowledge management

This report by Efimova (2002) is definitely written from the descriptive angle. It gives the

results of an empirical investigation of the role of Chief Knowledge Officers (CKO’s). One of

the questions this study focused on was: “What do CKO’s do? Activities and interventions”. In

addition other topics are: what the capabilities and competencies of CKO’s are and the

resources and support a CKO requires. The first two can contain clues about knowledge

management tasks, the third about properties of knowledge needed for carrying out these

8

tasks. An interesting point in the first question is the distinction the author makes between

“activities” and “interventions”, something that is missing in the documents analysed in the

previous sections. Though not clearly defined, I assume this to refer to tasks a CKO has to

perform (“activities”) and interventions s/he carries out in the organisation.

Unfortunately, this distinction is not so neatly kept in the reporting of the results (it shares this

with the remarkable similar paper by McKeen & Staples, 2003). After some interpretation, I

assume that the “interventions” are described in the section on “KM techniques and tools”.

The “activities” are probably located in the sections on “CKO goals and measurement” and

“CKO responsibilities”. These goals and responsibilities can be rewritten as tasks, but just as

in the previous section, they lack (sequential and nested) structure. Some are directly

formulated as tasks, e.g., “monitoring and evaluating” (see Figure 6 in the document) others

are not. An example of rewriting a goal as a task is: “Being an internal centre of excellence for

knowledge sharing (goal) -> Developing myself into an internal centre….”. I could not find any

location in the document where “resources and support” are described and, as a

consequence, it is not possible to derive any knowledge properties that could support their

implicitly defined tasks or “activities”.

To summarize: this report seems to fall short of its initial promise to identify CKO activities

(i.e., knowledge management tasks). With some effort a list can be extracted, but this is

unstructured and probably incomplete. In the same vein, no information is given about

resources and support for these activities, which makes it impossible to derive properties of

knowledge that should be included in knowledge maps.

2.4 Knowledge mapping

Though this report by Huijsen et al. (2003) has mainly a technical flavour, it could contain

some information about the relation between knowledge management tasks and knowledge

mapping.

The obvious place to look for this information is in the section devoted to Knowledge-Mapping

stakeholders. This section describes 7 categories of stakeholders. However, their “stakes” are

mainly described in terms of “typical questions” they might be interested in. For example for

management: how many people have expert knowledge in subject area X. Or for knowledge

management: for which subjects that are many people interested in are there no communities

(see p.9 and 10). Though again these questions can be rephrased as tasks, this will lead to

another incomplete and unstructured list. The Knowledge Cockpit demonstrator described in

Chapter 4 of the document seems mainly useful for knowledge workers who want to locate

expertise, which could also be one of the knowledge management concerns. The report

presents a database schema shown below in Table 1.

M E T I S D 4 . 3 9

Item Attributes

conference Title

Dates

course Title

Dates

document Title

Content

publication date

e-mail

message

date & time

Addressee

keyword keyword string

Language

Definition

approved/unapproved

person Name

Phone

e-mail address

Fax

Location

organisation (meant for external contacts that are included)

Photograph

position Description

project Title

Period

webpage Title

URL

Table 1: Data base schema proposed by Huijsen et al. (2003)

A comparison between what has been indicated in the previous sections about knowledge

properties needed for mapping to support knowledge management tasks, shows that only a

very limited subset of attributes from Table 1 can serve these purposes. The majority is tightly

coupled to a document as the main carrier of (static) knowledge.

To summarize: this document contains almost no clues about knowledge management tasks.

The database schema is mainly geared to support knowledge workers in their day-to-day

work, which is, of course, a quite valuable goal.

10

2.5 From knowledge map to knowledge web

This case study by Brussee et al. (2003) delves deeply into the daily working of several

employees in a company. The larger part of the document is irrelevant for the purpose of this

report, but there is a small exception. This is due to the fact that one of the actors performs a

Human Resource Management task.

The observations are analysed using the 5-T method and one of the T’s is about Tasks. In a

section devoted to tasks, I found the following quote:” Yvonne de L. ‘s task is to find people

suitable for the Myth assignment. She divides this in subtasks: finding out what expertise is

needed for a particular task by looking into the expertise nodes of the knowledge maps and

checking with people if this is what is needed, and finding the people by checking their

expertise and asking others what their impression is” (p.31). This quote amounts to a fairly

precise description of a (sub)task of the HRM task(s) performed by Yvonne. It should be

noted that she does not deal with the knowledge directly: She handles it as a resource to be

used in other (operational) tasks. Another interesting point is that there is an immediate link

between a knowledge map (“nodes in the knowledge map”) and a task (“finding out what is

needed for a particular task”). Note also the implicit distinction between her HRM task(s) and

the tasks in the Myth project. In addition, what is described here is very similar to what was

described in section 2.1 on JIT knowledge management.

To summarize: though only a minor part of the report could be useful, at least one description

can be seen as a good example of how (knowledge) management tasks and knowledge

maps, presenting relevant properties of knowledge, should be linked.

2.6 Summary

The review of several Metis reports has shown that only a few contain clues about knowledge

management tasks. The one that comes closest is the re-written set of questions from the JIT

deliverable, but these are incomplete and lack detail. In the next chapter we will investigate

whether the literature on knowledge management has more to offer.

M E T I S D 4 . 3 11

3 Knowledge management tasks in the literature

In this chapter I will review several knowledge management models proposed in the

knowledge management literature. As there is a bewildering array of models available it is not

so easy to make a selection. The main focus in selecting is on identifying models that contain

more or less explicit task descriptions.

3.1 The Holsapple-Joshi model

The most recent contribution to the discussion about knowledge management tasks can be

found in the interesting paper by Holsapple & Joshi (2003). What they try to do is to clarify the

main concepts that make up the notion of knowledge management, thus addressing the

disarray referred to in Chapter 1. It should be noted that their model is based on empirical

research (expert opinions) as reported in Holsapple & Joshi (2002).

Their starting point is what they call a “Knowledge management episode”: a pattern of

activities performed by multiple processors with the objective of meeting some knowledge

need. Figure 3 below gives the architecture of a knowledge management episode.

Figure 3: Architecture of a knowledge management episode (Holsapple & Joshi, 2003)

Based on the architecture shown in Figure 3 they develop a knowledge management

ontology, a set of ordered concepts that characterize knowledge management. For the

purpose of this report two elements of Figure 3 are important: the nature of a knowledge

management episode and the knowledge management influences. I will deal with episodes

first.

An episode consists of a configuration of what they call “Knowledge manipulation activities”.

Their definition of “knowledge manipulation” is not precise, but the general idea is that this is a

skill to handle knowledge resources. Figure 4 below depicts their general model of knowledge

manipulation activities that can play a role in an episode.

12

Figure 4: Knowledge manipulation activities according to Holsapple & Joshi (2003).

Figure 4 gives the high-level knowledge manipulation tasks, these are further decomposed

below.

Acquiring knowledge: identifying knowledge in the environment and transforming it into a

representation that can be internalised and/or used.

Subtasks

• Identifying: locating, accessing, valuing, and/or filtering knowledge from outside

sources.

• Capturing: extracting, collecting, and/or gathering knowledge deemed to be

sufficiently valid and useful.

• Organizing captured knowledge: distilling, refining, orienting, interpreting, packaging,

assembling, and/or transforming captured knowledge into representations that can be

understood and processed by another knowledge management manipulation activity.

• Transferring organized knowledge: communication channel identification and

selection, scheduling and sending.

M E T I S D 4 . 3 13

Selecting knowledge: identifying needed knowledge within an organisation’s existing

knowledge resources and providing it in an appropriate representation to an activity that

needs it.

Subtasks

These are basically the same as under “Acquiring knowledge”, but the domain is within the

organisation.

Internalizing knowledge: incorporating or making the knowledge a part of the organisation.

Subtasks

• Assessing and valuing: determining the suitability of the knowledge.

• Targeting: identify knowledge resources that are to be impacted by the knowledge

produced by internalisation.

• Structuring: representing knowledge to be conveyed in the appropriate form for the

targets.

• Delivering: modifying existing knowledge resources, depositing, storing, updating,

disseminating, distributing and sharing knowledge, it also involves channel

identification and choice, scheduling, and sending.

Using knowledge: this is decomposed in generating knowledge and externalizing knowledge.

Generating knowledge: produces knowledge by processing existing knowledge.

Subtasks

Monitoring the organisation’s knowledge resources and the external environment by invoking

selection and/or acquisition activities as needed.

Evaluating selected or acquired knowledge in terms of its utility and validity.

Producing knowledge from a previously existing base, this can involve creating, synthesizing,

analysing, and constructing knowledge.

Transferring the produced knowledge for externalisation and/or internalisation, includes

channel identification and choice, scheduling and sending.

14

Externalizing knowledge: using existing knowledge to produce external outputs for release

into the environment.

Subtasks

Targeting the output: determining what needs to be produced.

Producing: applying, embodying, controlling and leveraging existing knowledge to produce

output.

Transferring: packaging and delivering the projections that have been produced for the

targets, this includes channel identification and choice, scheduling and sending.

As can be easily seen from the text above, the task decomposition for some subtasks goes

even further. Verbs like “creating”, “locating”, “packaging” clearly refer to tasks, but these are

not described in detail by the authors. Neither do they say anything about the ordering of

these terms. However, with some effort some orderings can be imposed. For example, the

“Identifying” subtask from “Acquiring knowledge” consists of the lower level tasks locating,

accessing, valuing and filtering, and the order of enumeration can be seen as a “natural”

sequence of carrying out these tasks.

A slightly confusing aspect of this model is the recurrence of tasks in different parts of the

model. For example, the task “channel identification” appears in the main tasks Acquiring,

Internalizing, Generating and Externalizing. Though precise performing of these tasks is

obviously context dependent, a more specific naming could have been chosen.

More worrying is the question how knowledge management specific this model is. One could

try to replace all occurrences of “knowledge” in the text above with another resource, e.g., oil,

and see whether the model still makes sense. In my opinion the major part of the tasks are

then still meaningful and executable. One could argue that the model gets it’s “flavour” from

dealing with a very specific resource type, but the authors fail to explain how this influences

the way to carry out the tasks.

The second aspect of the architecture depicted in Figure 3 are the knowledge management

influences. These “managerial influences” can be seen as management in a more limited

sense. They consist of four management activities:

• Coordination: this involves the determination of what knowledge activities to perform

in what sequence, which participants will perform them, and what knowledge

resources will be operated on by each.

• Control: ensuring that the needed knowledge resources and processes are available

in sufficient quality and quantity.

M E T I S D 4 . 3 15

• Measurement: the valuation of knowledge resources and processors.

• Leadership: establishing enabling conditions for fruitful knowledge management.

These four activities are supported by a set of factors to be considered, phrased as questions.

In parallel to what I did with the JIT-model in Chapter 1, these questions can be re-phrased as

tasks (i.e., finding an answer to the question). In Table 2 below I reproduce Holsapple &

Joshi’s terminology, but the reader should substitute the “What” and “How” with something

line “Find out” or “Investigate”. I have numbered the tasks and questions, this will be re-used

in Chapter 5.

Managerial Influence Factors to consider (tasks)

A.1 Is there top level commitment to KM

initiatives? How does it manifest? Does it

align with the organization’s purpose and

strategy?

A.2 How is KM leadership cultivated at lower

levels?

A.3 How are condition created that allow

processors to do their best individual and

collective knowledge work?

A.4 How is a culture appropriate to

knowledge work established?

A. Leadership

A.5 Is there technological support for KM

leadership?

B.1 What knowledge activities are

performed?

B.2 How are they organized to accommodate

dependencies?

B.3 Which processors perform them?

16

B.4 What knowledge resources are used

and/or changed?

B.5 Is the knowledge processing self-

directed, guided or dictated?

B.6 What incentive structures are in place to

secure efforts?

B.7 How is the knowledge processing

integrated with other operations?

B.8 How are best KM coordination practices

recognized/preserved/applied?

B. Coordination

B.9 Is there technological support for KM

coordination?

C.1 What regulations are in place to ensure

quantity, quality and security of knowledge

resources and processors?

C.2 How are knowledge resources protected

from loss, obsolescence, improper

exposure/modification, and erroneous

assimilation? Via legal, social, technical

means?

C.3 What validation controls are used to

ensure sufficient accuracy, consistency, and

certainty of knowledge resources?

C.4 What utility controls are used to ensure

sufficient clarity, meaning, relevance and

importance of knowledge resources?

C.5 How are best KM control practices

recognized/preserved/applied?

C. Control

C.6 Is there technological support for KM

control?

D.1 How are knowledge resources valued?

M E T I S D 4 . 3 17

D.2 How are processors evaluated?

D.3 In what ways are effectiveness of

knowledge activities, coordination

approaches, knowledge controls, and

knowledge management leadership

assessed?

D.4 What are the impacts of an

organization’s KM on its competitiveness and

bottom-line performance?

D.5 How is effectiveness of these

measurement practices gauged?

D.6 How are best KM measurement

practices recognized/preserved/applied?

D. Measurement

D.7 Is there technological support for KM

measurement?

Table 2: Managerial influences on knowledge management episodes (adapted from

Holsapple & Joshi, 2003)

One of the problems with Table 2 is that some tasks seem to be “meta” knowledge

management tasks (e.g., D.6), that is, they are meant to assess the knowledge management

tasks themselves. Though certainly relevant from an organizational perspective, they are

probably outside the scope of knowledge maps for the support of the knowledge management

tasks proper.

Summarizing: the Holsapple & Joshi model combines at least three different conceptual

levels, the work-related knowledge management episodes, the managerial influences which

directly impinge upon these episodes and the “meta” assessment of these managerial

influences. In Chapter 5 I will return to how these levels can be handled for knowledge

mapping purposes.

3.2 The CIBIT model

Originally CIBIT worked in their consultancy practice with a version of the Wiig et al. (1997)

model (see Figure 11), which goes back to a model by Van der Spek & Spijkervet (1996)

which is a modified version of the model by Van der Spek & de Hoog (1994),

Based on their experiences in many consultancy projects, they created the model shown in

Figure 5. The main reasons for this shift were:

18

1) Without a clear focus many knowledge management initiatives are doomed to fail.

They drift off into personal hobbies or technology driven “improvements”.

2) The focus must be linked to key performance indicators of an organisation. A

knowledge management initiative that cannot show how and what it will contribute to

those indicators will not live long.

The model consists of three main phases (Focus, Organize and Perform) and one ongoing

task Communicate. Subtasks are linked to questions, for example “What would we like to be”,

which in turn are linked to “How” tasks (e.g., “Aligning KM with the business strategy”). The

main difference with the Wiig et al. model can be found in the Focus phase. The model used

by CIBIT contains more details about tasks than the ones shown in Figure 5. However, part of

this is proprietary.

M E T I S D 4 . 3 19

Figure 5: The CIBIT© model

20

Nevertheless, the operational character of these tasks is used in the KM Quest knowledge

management simulation game (Leemkuil et al., 2003). This simulation game is an attempt to

operationalize (parts of) knowledge management to a level where it can be executed by a

computer. This is not the place to give an extensive description of the KM Quest game, but

some screen-dumps will give an indication how it deals with knowledge management tasks.

The screen-dump in Figure 6 shows the entry (main) screen of KM Quest. The figure on the

computer represents the knowledge management task model at the highest level of

abstraction. The characters are short-hands for Focus, Organize, Implement and Monitor. The

whiteboard represents the state of the organisation in which the knowledge management task

is situated. Shown are three key performance indicators: profit, level of sales and customer

satisfaction. In this way the conceptual separation between knowledge management as a

management task and the results operational (work) processes is visualised.

Figure 6: First layer of specification of knowledge management tasks

The knowledge management tasks on the computer screen in Figure 6 can be made more

specific by clicking on them. This will result in the screen-dump as shown in Figure 7

M E T I S D 4 . 3 21

Figure 7: Second layer of specification of knowledge management tasks

Figure 7 shows the second layer of tasks in the Focus phase. The main goal of this phase is

to determine where the main emphasis of knowledge management will be for the coming

period(s). This is in line with the first observation on the reasons behind the CIBIT model.

The next level of specification of a knowledge management task is accessible by clicking on

one of the boxes in Figure 7 when the screen shown in Figure 8 pops up.

22

Figure 8:Third layer of knowledge management tasks

In Figure 8 one can see the more detailed description of the task “Focus on properties of

knowledge domains” from Figure 7. What is presented is a method or tool to support the

execution of this task. Additional task information is available through the “What to….” and

“How to….” buttons. These provide a fourth layer of specification. The “How to….” screen

associated with Figure 8 is shown in Figure 9.

M E T I S D 4 . 3 23

Figure 9: Fourth layer of knowledge management task specification

As can be seen from Figure 9, additional information is provided about how to perform the

tasks as well as about connections to other tasks.

The sequence of screen-dumps in Figure 6 to Figure 9, shows how the knowledge

management tasks in the KM Quest simulation, which are quite similar to the CIBIT model,

are decomposed onto a level where they are supportable by computer based tools. This is not

because computer based tools are favoured over other ones, but only to demonstrate the

level of preciseness of the task description. I will return to this issue of task detail in section

3.5.

3.3 The Wiig et al. model

In several papers (see for example Wiig et al. (1997) and de Hoog (2000)) I have proposed a

general framework for conceptualising knowledge management. At the core of this framework

lies the distinction between knowledge management activities and knowledge work activities.

Below this framework is described.

In economic theory an entrepreneur is seen as a person that configures production factors in

such a way that organisational value is created. As an entrepreneur is just another term for a

24

manager, this entrepreneurial brief is equally applicable to management and managers. So if

one wants to take the term “management” in knowledge management serious, this brief has to

be the starting point. This brief consists of a task, “configuring”, and a result, “a specific

configuration of production factors”. If we want to create a theory for knowledge management

the first objective is to specify the nature of the task, the result and how they are related.

The notion of a knowledge management task and a result, or the subject of the task, can be

conveniently shown in a simple figure (see Figure 10).

Figure 10: Knowledge management as a task and resource(s) configuration as a result

In this framework a definition of the knowledge management task entails a more detailed

model of the upper ellipse in Figure 10. The knowledge management interventions on work

processes belong to the downward arrow “actions to change organisational resources

configuration”. It should be noted that this framework accepts any definition of knowledge

management tasks as long as it keeps the distinction between the upper and the lower

ellipses. For example, the JIT knowledge management task as outlined in section 2.1 can be

taken as a specification of content of the upper ellipse. Also parts of the Holsapple-Joshi

model can be used to fill it with more detail. Another example of how this upper ellipse can be

modelled is shown in Figure 11 (taken from Wiig et al. 1997).

Knowledge management task

Organisational resources configuration

Actionsto changeconfiguration

Statusofconfiguration

Knowledge management task

Organisational resources configuration

Actionsto changeconfiguration

Statusofconfiguration

M E T I S D 4 . 3 25

Review

Conceptua-lise

Reflect

Act

External & Internaldevelopments

External & Internaldevelopments

External & Internaldevelopments

External & Internaldevelopments

Inventarisation ofknowledge &organisational context

Analysis strong & weakpoints

Evaluationresults

Comparisonold and new situation

Developmentof knowledge

Distributionof knowledge

Combinationof knowledge

Consolidationof knowledge

Planningof im-provements

Definitionof requiredimprovements

Figure 11: Knowledge management task model by Wiig et al. (1997).

The tasks depicted in Figure 11 are described below.

Reviewing means checking what has been achieved in the past, what the current state of

affairs is. Conceptualise is sitting back and try to get a view on the state of the knowledge in

the organisation and analyzing the strong and weak points of the knowledge household.

Reflect is directed towards improvements: selecting the optimal plans for correcting

bottlenecks and analyzing them for risks which accompany their implementation. Act is the

actual effectuation of the plans chosen previously. Most of the time the actions will be either

one or a combination of generic operations on knowledge:

• develop the knowledge (buy it, learning programs, machine learning on databases)

• distribute the knowledge (to the points of action, KBS’s, manuals, network connections

• combine the knowledge (find synergies, reuse existing knowledge)

• consolidate the knowledge (prevent it from disappearing, KBS’s, tutoring programs,

knowledge transfer programs)

The lower level tasks from Figure 11 are defined as follows:

26

Review

• Comparison of old and new situation. Monitoring the performance of an organisation

from a knowledge management perspective requires that the appropriate monitoring

procedures are in place and operational. These procedures will of course depend on

the kind of measures taken earlier and must be tailored to them.

• Evaluation results. The monitoring must be evaluated in the light of the original

objectives: did the implemented improvement plans led to the results envisioned?

Conceptualize

• Inventarisation of knowledge and organisational context. One of the most important

elements for effective knowledge management is to get a picture of the knowledge in

the organisation. This amounts to finding answers to the question what uses the

knowledge, which knowledge is used, where the knowledge is used, when the

knowledge is used, and which organisational role provides the knowledge

• Analysis of strong and weak points. Based on the results from the inventarisation an

analysis must be made of the strong and weak points of the current state of the

knowledge household. This can be done by subtasks like bottleneck analysis or

SWOT approaches.

Reflect

• Definition of required improvements. The Conceptualize phase will, as has been

mentioned above, produce a set of bottlenecks, problems, opportunities, weaknesses

etc. for which improvements must be identified. This identification process is of utmost

importance and it is absolutely crucial to keep the analysis of problems and

bottlenecks apart from the definition of improvements until this stage. After

improvements have been identified they must receive a priority, because most of the

time they cannot be implemented together due to constraints in time and money.

Selection of improvements is thus needed.

• Planning of improvements. After improvements have been chosen it is necessary to

translate them into operational plans. Most of the time this will amount to starting one

or more projects. As each of these projects will be instantiated differently, depending

on the context, not much more can be said about them. However, the risks involved in

carrying out improvement plans must be carefully assessed.

M E T I S D 4 . 3 27

The Act phase was described already above. It should be mentioned that in the Wiig et al.

framework the actions comprising the Act phase are not seen as knowledge management.

Most of the actions belong to other domains of expertise, like human resource management,

education and training, information- and knowledge engineering, for example. They represent

the downward arrows in Figure 10.

The authors address the question about the knowledge management specific nature of their

model, by enumerating several aspects of knowledge that makes it different from other

organisational resources:

Positive

• Growth through use, instead of being consumed. By applying knowledge agents can

increase their knowledge by absorbing new insights or by replacing obsolete

knowledge by more up-to-date knowledge. At the same time, using the knowledge

does not “destroy” it.

• Non-rival. Knowledge can be used simultaneously in different processes.

• No natural/physical limits. Apart from the energy needed by agents handling

knowledge there is no natural or physical limit to the amount of knowledge.

• Free from location and time constraints. Knowledge can be applied anywhere and at

any time, when needed. It is only weakly tied to a physical substrate other than the

agent that embodies the knowledge.

Negative

• Embodied in agents with a will. Mostly knowledge is embodied in agents with a will of

their own: humans. This makes accessibility and applicability sometimes difficult, as

the willingness of these agents is an important factor in using the knowledge.

• Intangible and difficult to measure. We cannot directly point to “knowledge” as a

physical quantity. And as we cannot see it easily we cannot measure it in a

straightforward manner. This makes “controlling” it a major challenge.

• Volatile. Apart from the fact that knowledge is often embodied in humans, which are

free to leave your organisation, sudden discontinuities in social, scientific and

organisational areas can make knowledge obsolete overnight.

• Value paradox. Boisot (1998) has pointed out that knowledge suffers from a value

paradox. In order to extract value from knowledge we have to codify, abstract and

diffuse it. But in this process knowledge will loose it’s scarcity and as a consequence

the opportunity to extract value from it.

28

• Long lead times. Knowledge cannot be conjured out of a hat. Mostly it takes years to

build expertise in a certain domain. This requires long term planning.

In their perspective knowledge management should be concerned with maximizing the

positive aspects and minimizing the negative ones. The resource view implies that the

measure of success is the providing of knowledge to organisational processes that need it, at

the right time, in the right shape, at the right location, with the required quality against the

lowest possible costs, in order to achieve organisational goals.

3.4 The Duineveld et al. model

The last model discussed in this chapter is a mixture of the CIBIT model (as expanded in the

KM Quest simulation environment) and the Wiig et al. model. It was developed by Duineveld

et al. (2001) in the context of the EU funded IBROW project. Figure12 shows their model.

Figure 12: The Duineveld et al. model

Figure 12 is quite similar to Figure 11 up to some re-labeling of tasks. It also contains

elements (e.g., Focus) which are derived from the CIBIT model (see Figure 5). The model is

based on a comparison of 16 papers containing knowledge management process models.

A more interesting part of their work is the Knowledge management task ontology they

propose (see Figure 13). As this is presented as a formal ontology, implying a hierarchical

structure, the sequence from Figure 11 is lost. Nonetheless, the tree consists of a list of tasks

that has similarities with the list proposed by Holsapple (see section 3.1). The list is also more

detailed than the list accompanying Figure 11. However, the paper itself lacks a more precise

description of what these tasks entail.

M E T I S D 4 . 3 29

Figure 13: The knowledge management ontology by Duineveld et al.

Another thing that is lacking is a rationale for the grouping of these tasks. Interestingly, the

task “Combination” has no subtasks. This is an indication that this is one of the more difficult

things to imagine.

3.5 Selection/construction criteria for a knowledge management model and knowledge management tasks

In this chapter and Chapter 2 several knowledge management models and tasks were

presented and sometimes criticized. This raises the question what a “good” model and “good”

tasks are. One answer is to carry out empirical research to determine either the normative or

descriptive “goodness”. In the context of the Metis knowledge mapping task this not a good

solution at the moment. The use of the knowledge management task ontology is for enriching

the to be designed knowledge cockpit and only when this enriching has taken place empirical

research into the quality can take place. This implies that one has to select/construct a model

first, which brings one back to the question about what is “good”. Below I will present and

30

discuss several criteria that seem to me to be important. Of course they are subjective, but

that holds for all criteria. As the ultimate arbiter is reality, it is better to make a choice first and

test it, instead of discussing forever thecriteria.

The following criteria seem to me important for selecting/constructing knowledge management

models and tasks. Cyclic

There can be no doubt about the fact that knowledge management is an ongoing concern,

just like other forms of management. Management only stops when the managed processes

disappear. This criteria implies that cyclic models, i.e. models that have a loop structure, are

to be preferred over linear (one way) models (see for an example Tiwana, 2000, this has been

modified in the 2nd Edition (Tiwana, 2003)).

Knowledge specific

When discussing the models, several times the issue was raised whether the model is

applicable to managing any organisational resource or specific for knowledge management.

The more knowledge management specific the better it seems, because this is a way to prove

that knowledge management is different from resource management in general (if it is!). This

can be achieved in at least two ways:

1) by including management tasks that only make sense in a knowledge management

context;

2) by setting goals for knowledge management tasks which are derived from unique

properties of knowledge as an organisational resource.

Thus models following one, or preferably both, ways are to be preferred over models that omit

them. Separate management from work

Though this may be my pet, I still feel that is extremely important to make a conceptual

distinction between doing the work and managing the work, even if they are often closely

intertwined. Driving the bus is not the same as managing the bus company, though both

belong to the same domain. The most straightforward analogy is with project management.

The project manager performs tasks like making a work-breakdown, estimating effort and

resources, scheduling project tasks, monitoring outcomes and dealing with events. The work

consists of, for example, writing code, gathering requirements, building UML models and

testing the code. This distinction is also reflected in the kind of tools that are available to the

different tasks. MS Project®, for example, is designed to support the project management

tasks, while programming languages, such as Java, are designed to support the development

tasks. Mixing the two will lead to immense confusion in a project.

M E T I S D 4 . 3 31

Appropriate grain size

Knowledge management tasks can be described at different levels of specificity (see, for

example, Figures 6-9). The question is “What is the appropriate level” which, of course,

passes the bucket to what we mean with “appropriate”. People working with task

decompositions are very aware of this nasty problem. A task like “Boiling water” can be

described as “Fill a kettle”, “Light the fire”, “Wait till the kettle whistles”, but the “Light the fire”

task can be described in more detail, e.g., “Take the box with matches”, “Take a match from

the box”, “Light the match”, “Turn the knob of the stove” etc.

Unfortunately there is no general solution to this problem. The overriding idea is to take the

competence of the executor of the task into consideration. Most of the time this leads to more

general task descriptions for more competent executors, simply because we can rely on the

executor to “fill in” the details. A variant of this principle is proposed by Lauesen (2003). His

criterion for a task is closure: the user must feel he or she has achieved something when the

task is complete. This is almost equivalent to saying that meaningful task descriptions must

have attached to them at least one goal of which one can more or less unambiguously

establish whether it was achieved or not.

However, as will be discussed in the next chapter, sometimes a “bottom up” approach can

help. This takes tasks of a fairly low grain size as a starting point and tries to cluster them into

meaningful larger tasks. Tool independent

One the problems in knowledge management is the inclination of tool vendors to position their

tool as “the“ knowledge management tool. This generates much confusion, the more so

because it is an illusion that one tool can cover all aspects of knowledge management. Thus a

knowledge management process model should be tool independent. This does not imply that

there can be no tools that can be used to support (sub)tasks. One of the long-term goals of

knowledge management research and development is design and implement a rich repertoire

of tools. But these tools must be seen as “plug in” tools that can be selected at will by anyone

involved in knowledge management processes. Time horizon

From experience it is known that knowledge management tends to come in two flavours: short

term and event driven, or strategic and driven by long-term goals. A knowledge management

process model must accommodate both flavours to be applicable in organisations.

In Chapter 5 I will review the proposed knowledge management – knowledge properties on

these criteria.

32

4 Knowledge properties

As has been said before, knowledge management tasks and properties of knowledge about

which data is needed to perform these tasks, are inextricably intertwined. In Chapter 2 in the

context of knowledge mapping, it emerged that most of this mapping was based on properties

of the knowledge domain (i.e. content), which may be less relevant for knowledge

management tasks (see for example the data base schema in Table 1). In this chapter I will

review several proposals from the literature that enumerate these properties. Fortunately

Holsapple (2003) has already written another seminal paper in which he gives an overview of

properties of knowledge that have been proposed in the literature.I will briefly enumerate them

in Table 3.

Property Range/definition

Mode Tacit vs explicit

Type Descriptive vs procedural

Domain Domain where knowledge is used

Orientation Domain vs relational vs self

Applicability From local to global

Management level Operational vs control vs strategic

Usage Practical vs intellectual vs recreational vs

spiritual vs unwanted

Accessibility From public to private

Utility Progression of levels from a clear

representation to one that is meaningful, to

one that is relevant, to one that is important

Validity Degree of accuracy or certainty

Proficiency Degree of expertise embodied in knowledge

Source Origin of knowledge

M E T I S D 4 . 3 33

Immediacy Latent vs currently actionable

Age From new to established to old

Perishability Shelf-life of knowledge

Volatility Degree to which knowledge is subject to

change

Location Position of knowledge (e.g ontological,

organisational, geographic locus)

Abstraction From concrete to abstract

Conceptual level Automatic vs pragmatic vs systematic vs

idealistic

Resolution From superficial to deep

Programmability Degree to which knowledge is transferable

or easy to use

Measurability Degree to which knowledge can be

measured

Recursion Knowledge vs meta-knowledge vs meta-

meta-knowledge

Table 3 : Knowledge properties taken from Holsapple (2003).

Though the author states that this list contains “potential levers for practitioners to wield in

their KM efforts” (p.186) and mentions that it can be an addendum to the ontology of

knowledge resources (see section 3.1), he does not clearly link these properties to knowledge

management tasks. The list is also rather disorganized, it could be structured not only by

linking it to knowledge management tasks, but also by grouping similar properties under a

more general heading. For example properties like Type, Management level, Abstraction,

Resolution and Recursion are all referring to general content properties which do not depend

on a particular domain. Properties like Usage, Origin, Immediacy and Location seem to be

more connected to the organisational aspects of knowledge. What is also lacking in

Holsapple’s paper is an indication of the grain size of knowledge, the “chunk” of knowledge

one wants to characterize with these properties.

34

The grain size problem is tackled in the paper by Wiig et al. (1997), based on earlier work by

Wiig. Table 4 shows a hierarchy of knowledge ranging from very general to very specific.

Knowledge Span

Examples

Knowledge domain Domains 1. Internal Medicine 2. Mechanical Engineering 3. Business Management

Knowledge Region Regions 1. Urology 2. Automotive Mechanical Design 3. Product Marketing

Knowledge Section Sections 1. Kidney diseases 2. Transmission Design 3. New Product Planning

Knowledge Segment

Segments 1. Diagnosis of kidney diseases 2. Gear Specification and Design 3. Product Marketability

Knowledge Element Elements 1. Diagnostic strategies, such as “When considering which

disease is present, first collect all symptoms, then try to explain as many of them as possible with one disease candidate”

Knowledge Fragment

Fragments 2. “If the symptom is excruciating pain, then consider

kidney stone” 3. “When there are too many gears in the transmission,

the energy loss will be excessive” Knowledge atom 1. “Excruciating pain is a symptom”

2. “Use case hardening of gear surfaces in pressure range 4”

Table 4: Hierarchy of knowledge description levels (from Wiig et al., 1997)

A comparison between Tables 3 and 4 shows that not all properties listed in Table 3 can be

meaningfully attached to every description level in Table 4. Thus selecting properties is

conditional on selecting a level in the hierarchy in Table 4 first. This is not easy to do in a way

that is applicable and valid for many contexts. Based on experiences in practical situations, I

found that the region/section/segment level is most appropriate for short term knowledge

management. The lowest three are mainly relevant for knowledge engineering, the domain

level is probably more suitable for strategic knowledge management. However, this is not

something that one should take for granted in every situation.

M E T I S D 4 . 3 35

Based on the choice for the region/section/segment level as being the most appropriate, Wiig

et al. (1997) give another table (a knowledge description frame) that contains properties

(called “identifiers”) of knowledge (see Table 5).

General identifiers

Name: Domain: Business processes: Organisational role Current agents:

the name of the knowledge asset (at segment or section level the knowledge domain to which the asset belongs the business processes in which the knowledge asset is used as a resource the organisational role to which the knowledge asset is usually attached agents (persons, computer programs, books etc.) carrying the knowledge asset at the moment of analysis

Content identifiers

Nature: Current proficiency levels: Stability:

the characteristics of the knowledge asset in terms of quality (heuristic, formal, complete, under development etc.) the level of proficiency at which the knowledge asset is available to the organisation the rate of change of the content (fast, slow etc.)

Availability identifiers

Time: Location: Form:

when the knowledge asset is available for business processes (e.g., working days from 9-5) the physical location of the knowledge asset (e.g., the main office, department of mortgages) the physical and symbolical embodiment of the knowledge asset (paper, in a computer program, in the mind of an agent etc., language, format etc.)

Table 5: Knowledge description frame taken from Wiig et al. (1997)

Several properties from Table 5 can also be found in Table 3, which indicates that they are

seen as important. A combination of Table 3 and Table 5 will give a fairly complete overview

of relevant properties. This is shown in Table 6, which uses a refined categorization described

below.

The following main categories can be discerned:

• General/organisational: properties that reflect the organisational embedding of the

knowledge

• Content: properties of the content which are not related to the domain of the

knowledge, but can be seen as properties that are applicable across all domains

36

• Use: properties indicating aspects that influence the use of the knowledge in the

organisation

• Availability: properties related to physical and logical positioning of the knowledge

Name: The name of the knowledge “chunk”

Domain: The knowledge domain to which the knowledge “chunk” belongs

Business processes The business processes in which the knowledge is used as a resource

Role: The organisational role to which the knowledge is usually attached

Current agents: Agents (persons, computer programs, books etc.) carrying the knowledge at the moment of analysis

Perishability: The degree to which the knowledge can be kept in the organisation

General/organisational

Age: The time the knowledge is present in the organisation

Nature: The characteristics of the knowledge in terms of quality (heuristic, formal, complete, under development etc.)

Type: The methodological characterization of the knowledge (causal, descriptive, procedural)

Management perspective: The knowledge management perspective for which the knowledge is relevant (operational, control, strategic)

Abstraction: The degree to which the knowledge is general or specific

M E T I S D 4 . 3 37

Resolution: The degree to which the knowledge is superficial or deep

Recursion: The distance between the domain of application and the knowledge (knowledge vs meta-knowledge)

Conceptual level: The categorization of the knowledge in terms of automatic, pragmatic, systematic or idealistic

Validity: The degree to which the knowledge has been proven

Stability: The rate of change of the content (fast, slow etc.)

Content

Proficiency: The level of proficiency at which the knowledge is available to the organisation

Applicability: The range in which the knowledge is used in the organisation (local vs global)

Usage: The prevalent way of using the knowledge (practical, intellectual)

Utility: The value of the use of the knowledge for the organisation

Immediacy: The degree to which the knowledge can be immediately employed (latent vs currently actionable)

Transferability:: The degree to which the knowledge can be transferred between processes and agents

Use

Measurability: The degree to which to knowledge lends itself to be measured

38

Time: When the knowledge is available for business processes (e.g., working days from 9-5)

Location: The physical location of the knowledge (e.g., the main office, department of mortgages)

Form: The physical and symbolical embodiment of the knowledge (paper, in a computer program, in the mind of an agent etc., language, format etc.)

Accessibility: The roles, persons and organisations that can have access to the knowledge

Availability

Mode:

Tacit vs explicit

Table 6: Summary of important knowledge properties

However, Table 6 does not tell the whole story as it does not address the more dynamic

aspects of knowledge processes in organisations.

The KM Quest knowledge management simulation game discussed in section 3.2 includes an

executable model of the behaviour of a fictitious organisation in which the knowledge

household must be managed. In the screen dumps shown in Figures 6 and 7 one can see that

one of the knowledge management tasks is to monitor the state of the knowledge household.

This monitoring requires information concerning the knowledge, or, in other words indicators

or properties. To support this monitoring a rich set of indicators is included. Below these will

be discussed briefly. However, just as for the previous proposals, one should keep in mind

that defining a property or indicator is not the same as measuring it. Thus when reading the

elaboration of the KM Quest properties and how they are displayed it is important to realize

that in the system the measurements are assumed to exist, which in practice may be quite

difficult to do.

As the fictitious company is characterized as a product leadership organisation (Treacy &

Wiersema, 1995), the crucial knowledge domains in the organisation are marketing,

production and R&D, so these are represented in the category knowledge related variables.

For these domains there are several core knowledge processes which merit attention (based

on Probst et al., 1999; Wiig et al., 1997; Choo, 1998):

� Knowledge gaining: a measure for the acquisition of knowledge from outside the

organisation

� Knowledge development: a measure for the internal development of knowledge

M E T I S D 4 . 3 39

� Knowledge utilisation: a measure for how the knowledge is actually used

� Knowledge retention: a measure for the success with which loss of knowledge is

prevented

� Knowledge transfer: a measure for the transfer of knowledge between the three domains,

which is also crucial for product leadership organisations

These core knowledge processes are similar to several knowledge management tasks as

described in Chapter 3. Several occur, for example, in the Holsapple-Joshi model, the Wiig et

al. model and the Duineveld et al. model, which is not too surprising as the identification of

these processes was based on a study of the literature. These core knowledge processes are

characterized by three properties reflecting their quality:

• Speed: the time needed for the process

• Effectiveness: the actual result of the process • Efficiency: the "cost"/"benefit" ratio of the previous two properties

Knowledge domains, core knowledge processes and quality properties of the latter, form a

three-dimensional space representing the knowledge management focus. This results in an

extensive list of indicators which are triplets of the type <knowledge domain, process,

property>, for example <marketing,development,speed>. Some theoretical combinations are

not meaningful, like those combining “retention” and “speed”, these are excluded.

In addition the KM Quest approach assumes that the state of these knowledge processes

influence the level of competence in the three knowledge domains. To the list of indicators are

added three indicators for the levels of competence. Together this leads to a list of 42

indicators. Of course it will not be easy to actually measure several of these indicators. For

example, something like “effectiveness of knowledge utilisation in marketing” can be hardly

measured in a straightforward way. However, with some creativity one could come up with at

least some proxy measures, just like the way other authors (Sveiby, 1997, Edvinsson &

Malone, 1997) use these for rather abstract concepts.

In the KM Quest these indicators are displayed together in a “knowledge map” which can be

seen as a kind of “knowledge cockpit” that allows a knowledge manager to monitor the state

of the knowledge household. Figure 14 below is a screen-dump from the KM Quest system

showing the knowledge map.

40

Figure 14: The knowledge map in the KM Quest system

The window in Figure 14 shows the knowledge map at the beginning of the game. The three

large squares represent the knowledge domains (Marketing, Production and Research). Each

square is divided into six rectangles, one for each knowledge process. These rectangles are

tagged with a symbol that is explained at the right hand side. Within each rectangle the value

of two properties of each process is shown. Effectiveness by means of a colour code, green is

fine, red is bad. Speed by means of abbreviations, for example “S=vf” means “speed is very

fast”. Adding also the “efficiency” of the processes to the map would clutter it too much. The

value of these indicators is shown in a graph that displays together the efficiency of all

processes for a knowledge domain (see Figure 15).

M E T I S D 4 . 3 41

Figure 15: Displaying efficiency of knowledge processes in Marketing

In Figure 15 the user can tailor the graph by toggling the checkboxes at the right hand side.

Removing the “٧” at utilisation will delete the “utilisation” line from the graph.

Experiments with the KM Quest system have shown that having access to these “knowledge

maps” contribute to the capability of players to achieve good results.

When I summarize the three examples of how to deal with properties of knowledge which are

relevant for knowledge management, two conclusions seem to be warranted:

1. Properties and indicators should combine static and dynamic aspects. The properties

proposed by Holsapple and Wiig et al. and summarized in Table 6, mainly address

static aspects. Though they can, of course, change their values over time, they are

attached to “chunks” of identifiable knowledge. The properties included in the KM

Quest system focus mainly on the dynamics of knowledge processes.

2. Identifying knowledge management tasks can also proceed in a “bottom up” fashion.

One can rephrase each indicator as a task by stating that taking care of that indicator

is a knowledge management task, for example, taking care of the speed of knowledge

transfer between research and marketing. By clustering and sequencing these tasks

one can arrive at a knowledge management process model. This is evident from the

fact that the knowledge processes in the KM Quest system occur as knowledge

42

management tasks in several knowledge management process models described in

Chapters 2 and 3.

Following the second observation, I will use in the next chapter a combination of the “top

down” (from Chapter 3) and the “bottom up” (from this chapter) approach to construct a

knowledge management-knowledge properties model that can serve as a specification for

knowledge management focused knowledge mapping.

M E T I S D 4 . 3 43

5 A knowledge management – knowledge properties model for knowledge mapping

In the previous two chapters I have presented quite some information referring to knowledge

management process models and knowledge properties. In this chapter a synthesis will be

presented. Several criteria for such a synthesis were discussed in section 3.5. The synthesis

will consist of three parts:

• characteristics of knowledge that sets it apart from other organisational resources

which should be the main concern of knowledge management (the unique aspects for

knowledge management),

• organisational goals that should be attained with knowledge management,

• the knowledge management-knowledge properties model that should support the first

two aspects

5.1 Characteristics of knowledge

Though there may be other, probably more epistemologically oriented, characteristics of

knowledge, I think that the ones enumerated in section 3.3 are relevant for the present

purpose. In Table 7 below I first list all the positive properties and indicate which tasks and

properties are related to each of them. In Table 7 I’m mapping the tasks from Chapter 3 on

these characteristics. In the “Tasks” column, in each cell the section from Chapter 3 is

indicated by the section number, followed by the tasks from that chapter that seem to address

that particular characteristic. Before embarking on this, I must say a few words on how to

handle the Holsapple-Joshi model. If I apply the criteria put forward in 3.5 it can be argued

that only the part of that model dealing with managerial influences (see Table 2) can be said

to satisfy the criterion of separation between management and work. The knowledge

manipulation activities as depicted in Figure 4 basically can be seen as belonging to the

“work” aspect. However, there are several ambiguities in Figure 4 and the resulting task

decomposition as presented in 3.1. One could argue that several tasks from Figure 4 can also

be interpreted as being more general knowledge management tasks, instead of only

knowledge manipulation activities performed in the context of a knowledge management

episode. For example, the internalizing task is described as “incorporating or making the

knowledge part of the organization”, which can hardly be seen as related only to a work task.

This holds more or less also for the tasks selecting and acquiring. When it comes to finding

examples of both types of activities Holsapple is not very consistent either. In Holsapple &

Singh (2003) empirical evidence is presented on the efficacy of the activities, based on a

review of the (knowledge) management literature. The cases described can quite often be

seen as belonging to either the “episode” part or to the “managerial influences” part. In order

to deal with this ambiguity I have decided to incorporate both perspectives in the tables,

leaving it to the prospective user to choose between them or accept them both. The entries

44

for the tasks from Figure 3 and Table 2 are made from my interpretation as seeing them as

primarily knowledge management (related) tasks.

The entries and coding in the tables are as follows:

• 3.1 Holsapple-Joshi model (knowledge manipulation activities, managerial

influences)

• 3.2 CIBIT/KM Quest model

• 3.3 Wiig et al model

• 3.4 Duineveld et al. model

For tasks the notation convention is “name-of-general-task(subtasks)”. For example

“generating(transferring)” means the generating task with the subtask transferring from

section 3.1. Tasks taken from the Holsapple-Joshi model’s managerial influences are

indicated by their codes as given in Table 2. For properties the same convention is used, but

this is only relevant for process-oriented properties from the KM Quest system. Other

properties are taken from Table 6.

It should be noted that this classification is based on my interpretation and must be seen as

tentative. Moreover, as will become clear, in many cases a unique classification cannot be

achieved. Several tasks and properties can belong to more than one class.

Positive characteristics Tasks Properties

Growth 3.1 Generating(producing),

A6, B8, C5, D6

3.2 Organize(how to improve

the knowledge and learning

infrastructure), Focus(Which

knowledge areas should we

focus on?)

3.3 Conceptualize(analysis of

strong and weak points),

Development, Combine

3.4 Gaining(acquire,capture),

Combination

stability, usage,

development(speed,

effectiveness)

M E T I S D 4 . 3 45

Non-rival 3.1 Internalizing(delivering),

Acquiring(organizing),

Internalizing(targeting),

Internalizing(delivering),

Generating(transferring), B1,

B2, B4

3.2 Organize(how to improve

the knowledge and learning

infrastructure)

3.3 Distribute

3.4 Distribution(identify

source), Distribute(identify

destination)

transferability, immediacy,

accessibility, mode,

applicability, abstraction,

utilisation(effectiveness),

transfer(speed,

effectiveness)

No physical limits 3.1 None

3.2 None

3.3 None

3.4 None

None

Free from time/location

constraints

3.1 Largely the same as Non-

rival, B3, B4

3.2 Organize(how to improve

the knowledge and learning

infrastructure)

3.3 Distribute

3.4 Distribution(identify

source), Distribute(identify

destination)

time, location,

transfer(speed)

Table 7: Positive characteristics of knowledge and their relation with tasks and properties

46

In Table 8 below, the same procedure is followed for the negative characteristics.

Negative characteristics Tasks Properties

Agents with a will 3.1 A2, A3, B6, D2

3.2 Organize(How to make it

happen?)

3.3 Reflect(planning

improvements),

3.4 Utilization(monitor use),

Utilization(stimulate use)

accessibility, immediacy,

role, current agents, form,

proficiency, perishability

Intangible 3.1 Acquiring(capturing),

Generating(monitoring), B4,

D1

3.2 None

3.3 Conceptualize

(inventarisation)

3.4 Gaining(acquiring,

capturing)

mode, accessibility

Volatile 3.1 Internalizing(delivering),

C2

3.2 Organize(how to improve

the knowledge and learning

infrastructure)

3.3 Consolidate

3.4 Consolidation(retention)

retention

M E T I S D 4 . 3 47

Value paradox 3.1 Externalizing(producing)

3.2 None

3.3 None

3.4 None

utility, transferability

Long lead times 3.1 Acquiring(locating),

Generating(monitoring)

3.2 Organize(how to improve

the knowledge and learning

infrastructure)

3.3 Conceptualize(analysis of

strong and weak points)

3.4 Gaining(identify needed

knowledge),

Utilization(monitor needs)

age, gaining(speed,

effectiveness)

Table 8: Negative characteristics of knowledge and their relation with tasks and properties

5.2 Knowledge management goals

For knowledge management goals, the same kind of table can be constructed as in section

5.2. I will also use the list of goals discussed in section 3.3 (see Table 9 below). In the same

vein, I will use tasks and properties from Chapters 3 and 4, just as in Tables 7 and 8.

Goal Tasks Properties

Time 3.1 Acquiring(transferring),

Internalizing(delivering),

Generating(transferring), B1,

B2, B3, B4, B7

3.2 Organize(how to improve

time

48

the knowledge and learning

infrastructure)

3.3 Conceptualize

(inventarisation),

Conceptualize(analysis of

strong and weak points),

Distribute

3.4 Distribution(identify

source), Distribute(identify

destination)

Shape 3.1 Internalizing(structuring),

Acquiring(organizing), C4

3.2 None

3.3 Conceptualize

(inventarisation),

Conceptualize(analysis of

strong and weak points)

3.4 Distribute(customize),

Distribute(choose format),

Consolidate(structure)

form

Location 3.1 Generating(transferring),

Acquiring(transferring), B1,

B2, B3, B4

3.2 Organize(how to improve

the knowledge and learning

infrastructure)

3.3 Conceptualize

(inventarisation),

Conceptualize(analysis of

strong and weak points),

Distribute

location

M E T I S D 4 . 3 49

3.4 Distribution(identify

source), Distribute(identify

destination)

Quality 3.1 Generating(evaluating),

Acquiring(identifying),

Internalizing(assessing and

valuing),

Generating(evaluating), C1,

C2, C3

3.2 None

3.3 Conceptualize(analysis of

strong and weak points),

Distribute

3.4 Consolidate(validation),

Consolidate(check

consistency with existing

knowledge), Maintain(verify),

Maintain(correct mistakes),

Maintain(update),

Maintain(version control)

Gaining(acquire, validate)

nature, resolution, validity,

proficiency, conceptual level

Lowest costs 3.1 Acquiring(valuing),

Internalizing(assessing and

valuing), D1, D2

3.2 None

3.3 None

3.4 None

utility

Achieving organisational

goals

3.1 D4 None directly for knowledge,

for goals in general

50

3.2 Focus(What would we

like to be?), Focus(Which

performances would we like

to improve?)

3.3 Conceptualize(Analysis

of strong and weak points)

3.4 None

measures like profit,

customer satisfaction, market

share etc.

Table 9: Organisational goals and their relation with knowledge management tasks and

properties of knowledge

Tables 7-9 can be summarized in a table that shows how “well” characteristics and goals are

covered by tasks and properties. An overview of this may contain clues about areas where

additional work in terms of defining knowledge management tasks and knowledge properties

is needed. This is shown in Table 10.

Characteristic/goal Number of tasks Number of properties

Growth 12 4

Non-rival 12 9

No physical limits 0 0

Free from time/location

constraints

11 3

Agents with a will 8 7

Intangible 7 2

Volatile 5 1

Value paradox 1 2

Long lead times 6 3

M E T I S D 4 . 3 51

Time 14 1

Shape 8 1

Location 12 1

Quality 16 1

Lowest costs 5 1

Achieving organisational

goals

4 n.a.

Table 10: Summary of coverage of characteristics and goals

In Table 10 the numbers in the cells corresponding with the properties and goals should not

be taken literally. They are based on the single indicators in Table 9. With some effort more

indicators from Table 6 could have been added. It is somewhat surprising to see that

concerns, which are particularly relevant for higher management (lowest costs, achieving

organisational goals, value paradox), are less well covered than other issues. Also, volatility

seems to be underrepresented, which seems to be out of synch with all the known efforts

spent on knowledge repositories.

5.3 Summary and reflection

The three tables in the previous two sections together form an initial knowledge management-

knowledge properties model. The interesting aspect is that, compared to the original starting

point, identifying tasks leading to goals leading to relevant properties for knowledge mapping,

the tables also permit a reversal of goals and tasks and properties. From a design viewpoint

this means that access to relevant properties of knowledge can be achieved in two ways:

• Identify a goal or several goals, find the associated task(s) and the needed knowledge

properties. For example: if the main concern is about capitalizing on non-rivalness

and location, then the relevant tasks and properties can be read from the cells in

Tables 7-9.

• Identify a task or several tasks and find the needed knowledge properties from the

cells in the last column of Tables 7-9.

One can even start with a property and derive which tasks and goals could be associated with

that property.

If I compare this initial model with the criteria put forward in section 3.5 the conclusions below

appear to apply.

52

Cyclic: This model is clearly a static model. It does not impose a sequence of goals and/or

tasks. The question is whether for knowledge mapping purposes such a sequence is needed

as long as it is emphasized that knowledge management is an ongoing activity.

Knowledge specific: The characteristics leading to goals are very knowledge specific.

Several tasks also make only sense in the context of knowledge (structuring, transforming,

validating, consistency, etc.).

Separate management from work: The majority of the tasks are management tasks, though

there are some boundary cases, in particular for the Holsapple-Joshi model.

Appropriate grain size: The tasks derived from the literature differ in grain size. As a

consequence the tasks in Tables 7-9 differ also. It seems that tasks derived from the

Holsapple-Joshi model and the CIBIT/Expanded KM Quest (not completely shown) have the

best grain size.

Tool independent: The tasks in Tables 7-9 can be supported by a wide variety of tools.

Future work in Metis could be directed to adding a fourth column to these tables, indicating

the availability, and maybe the evaluation, of tools.

Time horizon: The Tables 7-9 are not particularly strong in supporting more long term, or

strategic, aspects. For this they rely for the major part on the CIBIT/KM Quest approach.

Summarizing, the initial model meets several of the criteria, but can be improved. This can be

one of the future activities in the framework of the Metis project. At the same time, it will be

not too difficult to build a simple demonstrator of a tool that “animates” Tables 7-9. However,

one should remember that identifying properties is not the same time as actually measuring

them. To build a useful operational tool, quite some effort is needed to find suitable indicators

for these properties that can be measured in a reliable, cost-effective and non-threatening

way. Only if this work is completed we can start talking about a “real knowledge management

cockpit”.

M E T I S D 4 . 3 53

6 References

Boisot, M. (1998). Knowledge assets. Oxford University Press.

Brussee, R., A.H. Salden & J. Swaak (2003). From knowledge map to knowledge web. Metis

report Metis/D0.5

Choo C.W. (1998) The Knowing organization. How organizations use information to construct

meaning, create knowledge, and make decisions. Oxford University Press, New York, Oxford.

D’Huy, K., L. van der Hulst, K. de Jong, J. Kleberg, N. van den Nieuwenhuijzen, A. Verdoorn

& W. Wagenaar (2002). Just in time knowledge management. Metis report Metis/D5.1.

Duineveld, A.J., B.J. Wielinga, V.R. Benjamins & N. Christoph (2001). Knowledge

management library. Deliverable D2a, IBROW project IST-1999-19005, University of

Amsterdam.

Edvinsson, L. & M.S. Malone (1997). Intellectual Capital. Harper Business.

Efimova, L. (2002). Managing knowledge management. Metis report Metis/D1.2.1

Holsapple, C. & K. Joshi (2002). Knowledge manipulation activities: results of a Delphi study.

Information and Management, 39, 6, p.477-490.

Holsapple, C.W. (2003). Knowledge and Its Attributes. In: C.W. Holsapple (Ed), Handbook on

knowledge management, Vol. 1, p.165-188. Springer Verlag.

Holsapple, C.W. & K.D. Joshi (2003). A knowledge Management Ontology. In: C.W.

Holsapple (Ed), Handbook on knowledge management, Vol. 1, p.89-124. Springer Verlag.

Holsapple, C.W. & M. Singh (2003). The Knowledge Chain Model: Activities for

Competitveness. In: C.W. Holsapple (Ed), Handbook on knowledge management, Vol. 2,

p.215-251. Springer Verlag.

Hoog, R. de (2002). Even kennis maken. Oratie, Universiteit Twente.

Huijsen, W., R. Brussee, A. Salden, W. Van Dieten, M. Kempen & W.Ruiterman (2003).

Knowledge mapping. Metis report Metis/D3.1.1.

Lauesen, S. (2003). Task descriptions as functional requirements. IEEE Software,

March/April, 58-65.

Leemkuil, H. , T. de Jong, R. de Hoog & N. Christoph (2003). KM Quest: A collaborative

Internet-based simulation game. Simulation & Gaming, 34, 1, p.89-11.

54

McKeen, J.D. & D.S. Staples (2003). Knowledge managers; Who Are They and What Do

They Do? . In: C.W. Holsapple (Ed), Handbook on knowledge management, Vol. 1, p.21-42.

Springer Verlag.

Metis Quick Guide 2002. Metis Report Metis/D0.4.2.

Moor, A. de & M. Smits (2002). Key performance indicators for knowledge management in a

community of practice. Metis report Metis/D7.2.

Probst, G., S. Raub & K.Romhardt (1999) Managing knowledge. Building blocks for success. Wiley.

Spek, R. van der & R. de Hoog (1994). Towards a methodology for knowledge management.

In: J.P.Barthes (Ed), Proc. ISMICK '94, Management of industrial and corporate knowledge.

IIIA, Compiegne, p.93-102.

Spek, R. van der & A. Spijkervet (1995). Knowledge management, dealing intelligently with

knowledge. Kenniscentrum CIBIT, Utrecht.

Sveiby, K.E. (1997). The new organizational wealth. Berrett Koehler.

Tiwana, A. (2000,2003. The knowledge management toolkit. Prentice Hall.

Treacy, M. & F. Wiersema (1995). The discipline of market leaders. Harvard Business Press,

New York.

Wiig, K.M., R. de Hoog & R. van der Spek (1997). Supporting Knowledge Management: A

Selection of Methods and Techniques. Expert Systems With Applications, 13(1), 15-27.