Knowledge management process models for knowledge maps

1. Knowledge
management
process models for
knowledge maps

3. Colophon
st
Date : March 1 , 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.
M E T I S D 4 . 3 III

4. 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.
IV

5. 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 - Find combinations of technical support and
innovative power of my organisational incentives that stimulate the exchange
organisation? of knowledge, experience and vision, and the
- How do I ensure that the application of new ideas
knowledge and vision of my
smart people becomes
knowledge of my organisation?
- Am I doing well with knowledge - Identify indicators of good knowledge management
management?
- What knowledge does my - Extract knowledge from communication and
organisation have? documentation and provide relevant views on this
- They say my organisation has knowledge for knowledge workers and knowledge
smart people, but how do I managers
know?
- Does my organisation - Identify the opportunities that communication and
sufficiently exploit the options to network infrastructures offer for the exchange of
communicate with the outside information and knowledge across the borders of
world? To learn from customers? 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.
M E T I S D 4 . 3 V

6. 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.
VI

7. 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 VII

9. 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
M E T I S D 4 . 3 1

10. 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.
2

11. 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
M E T I S D 4 . 3 3

12. 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
1
addition the authors give on p.32 a brief list of characteristics for describing the demand :
• 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.
4

13. 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.
M E T I S D 4 . 3 5

14. 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).
6

15. 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
M E T I S D 4 . 3 7

16. 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.
8

17. Item Attributes
conference Title
Dates
course Title
Dates
document Title
Content
publication date
e-mail date & time
message
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.
M E T I S D 4 . 3 9

18. 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.
10

19. 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.
M E T I S D 4 . 3 11

20. 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.
12

21. 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.
M E T I S D 4 . 3 13

22. 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.
14

23. • 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. Leadership 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.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?
M E T I S D 4 . 3 15

24. B. Coordination 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.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. Control 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.6 Is there technological support for KM
control?
D.1 How are knowledge resources valued?
16

25. 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. Measurement 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.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:
M E T I S D 4 . 3 17

26. 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.
18

27. Figure 5: The CIBIT© model
M E T I S D 4 . 3 19

28. 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
20

29. 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.
M E T I S D 4 . 3 21

30. 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.
22

31. 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
M E T I S D 4 . 3 23

32. 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).
Knowledge management task
Actions Status
to change of
configuration configuration
Organisational resources
configuration
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).
24

33. Inventarisation of Analysis strong & weak
External & Internal knowledge & points External & Internal
developments organisational context developments
Conceptua-
lise
Evaluation
Definition
results of required
improvements
Reflect
Review
Comparison Planning
old and new
of im-
situation provements
Act
Development Consolidation
of knowledge
of knowledge
External & Internal
Distribution Combination External & Internal
of knowledge of knowledge developments
developments
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:
M E T I S D 4 . 3 25

34. 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.
26

35. 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.
M E T I S D 4 . 3 27

36. • 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.
28

37. 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
M E T I S D 4 . 3 29

38. 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
nd
modified in the 2 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.
30

39. 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.
M E T I S D 4 . 3 31

40. 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
32

41. 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.
M E T I S D 4 . 3 33

42. 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 Segments
Segment 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 Fragments
Fragment 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.
34

43. 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).
Name: the name of the knowledge asset (at
segment or section level
Domain: the knowledge domain to which the
asset belongs
Business processes: the business processes in which the
General identifiers knowledge asset is used as a resource
Organisational role the organisational role to which the
knowledge asset is usually attached
Current agents: agents (persons, computer programs,
books etc.) carrying the knowledge
asset at the moment of analysis
Nature: the characteristics of the knowledge
asset in terms of quality (heuristic,
formal, complete, under development
Content identifiers etc.)
Current proficiency levels: the level of proficiency at which the
knowledge asset is available to the
organisation
Stability: the rate of change of the content (fast,
slow etc.)
Time: when the knowledge asset is available
for business processes (e.g., working
days from 9-5)
Location: the physical location of the knowledge
Availability identifiers asset (e.g., the main office, department
of mortgages)
Form: 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
M E T I S D 4 . 3 35

44. • 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
General/organisational 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
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
36

45. Content 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.)
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
Use 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
Measurability: The degree to which to
knowledge lends itself to be
measured
M E T I S D 4 . 3 37

46. 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)
Availability 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
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
38

47. 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.
M E T I S D 4 . 3 39

48. 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).
40

49. 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
M E T I S D 4 . 3 41

50. 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.
42