Главная

Статьи

Библиотека статей

Менеджмент знаний

Karl Wiig Knowledge Research Institute 5211 Vicksburg Drive Arlington, Texas phone: 76017-4941 e-mail: 7111.1427@compuserve.com

Robert de Hoog Dept. of Social Science Informatics University of Amsterdam Roetersstraat 15 1018 WB Amsterdam The Netherlands phone: +31 20 5256794 fax: + 31 20 5256896 e-mail: dehoog@swi.psy.uva.nl

Rob van der Spek Kenniscentrum CIBIT Arthur van Schendelstraat 570 P.O.Box 573 3500 AN Utrecht The Netherlands phone: +31 30 2308900 fax: +31 30 2308999 e-mail: rvdspek@cibit.hvu.nl

Carrying out knowledge management effectively requires support from a repertoire of methods, techniques and tools. This paper provides a selection of those methods. They are described according to a conceptual framework that sees knowledge management as consisting of four activities that are performed sequentially. These activities are Review, Conceptualize, Reflect and Act. For each activity some methods are discussed while additional ones are referred to in the existing literature. At several points in the paper links with other contributions in this special issue are stipulated, as is also done the other way round. It is concluded that there is already a comprehensive set of support methods available, but for some peculiar aspects of knowledge assets there are still gaps. This holds in particular for the tangibility and measurability of knowledge assets.

During the last couple of years interest in knowledge management has grown rapidly. This is evidenced by the increasing number of books, conferences and seminars devoted to this topic. The material presented varies greatly from general theoretical considerations to specific case studies. However, it seems that the middle ground is not so well covered. With middle ground we mean the area occupied by methods and techniques that are neither too general nor too specific. Too general refers to the lack of operational value of some of the theories and philosophies. Too specific signifies that the techniques employed are only applicable in one or at most a few cases. The goal of this paper is to present a selection of methods and techniques which can start to populate this middle ground. This overview relies heavily on the material in Wiig (1995), but provides a more coherent description framework and adds some methods that emerged recently.

In section 2 we will present the description framework, which is very similar to the one presented in van der Spek & de Hoog (1995). The main part of the paper, section 3, provides a selection of some important methods and techniques for knowledge management. We do not claim that the selection is exhaustive. Being exhaustive would far surpass the admissible size of a paper in a journal. Due to its wide ranging nature knowledge management can easily accommodate methods and techniques developed in other fields. The reader should feel free to use those whenever it suits his current purpose. We will focus mainly on methods and techniques that are dealing with knowledge in the first place. We will pull things together in section 4 and point to gaps that are still existing in knowledge management’s repertoire.

Knowledge management does not carry it’s name accidentally. Management normally means that “something” has to be managed. In other words, we have a set of management activities directed towards dealing with an “object”, which is the subject of knowledge management. This immediately defines two important aspects of knowledge management: a knowledge management level dealing with the knowledge object level. This simple distinction is depicted in figure 1, and is fairly standard from a control theory point of view.

Figure 1: Levels in knowledge management.

It is clear that knowledge management, to be effective, has to satisfy certain goals. If we see knowledge as a company resource, managing it will basically have to live up to the goals common to all resource management, that is taken care that the resource is:

• delivered at the right time;

• available at the right place;

• present in the right shape;

• satisfying the quality requirements;

• obtained at the lowest possible costs.

Apart from the question how to achieve this, knowledge does have some properties that are absent in almost all other resources used in a company. Below we will list some of the most important characteristics that set knowledge apart from other resources:

• knowledge is intangible and difficult to measure;

• knowledge is volatile, that is it can “disappear” overnight;

• knowledge is most of the time embodied in agents with wills;

• knowledge is not “consumed” in a process, it sometimes increases through use;

• knowledge has wide ranging impacts in organizations (e.g. “knowledge is power”);

• knowledge cannot be bought on the market at any time, it often has long lead times;

• knowledge is “non-rival”, it can be used by different processes at the same time.

It is our belief that knowledge management should focus on these unique properties of knowledge and come up with a set of methods, tools and techniques that helps in tackling problems that arise from these and other properties.

In figure 1 we distinguished the two levels we have to deal with in knowledge management, but both ovals are still not further specified. In order to put some flesh on them we must define in more detail their components. For the management level we use the knowledge management cycle depicted in figure 2.

Figure 2: The knowledge management cycle.

In figure 2 knowledge management is split into four separate activities, each dealing with a particular aspect. 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 organization 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 the 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).

We will use the model of figure 2 to order a set of methods and techniques that can assist the “knowledge manager” in carrying out the knowledge management task. Before starting to describe this selection a word of caution is needed. We have used the words methods and techniques in a very loose way. Usually a method is a well defined set of procedures that can be applied without much additional support by its user. For the current purpose this definition seems to be too restrictive because things that will be useful could be excluded. Thus we will also incorporate checklists, forms, tables, diagrams etc. in the overview, not the least because they have proved to be useful in practice. Additionally, we will be able by using the description framework to identify gaps in the existing repertoire.

Though the Review activity is taken as a starting point, this does not mean that in practice every KM cycle has to start at this point. But from the point of view of this paper its seems to be the most obvious location to do so. The Review activity will consist of two sub-activities: monitoring performance and evaluation of the performance, discussed in more detail below.

Monitoring the performance of an organization 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. Most of the time they will be linked to improvement projects as described in section 3.3.2.

But it are not only improvement plans that must be monitored. More in general a keen eye must be kept on the knowledge household of the organization. Especially important is watching the external environment for new events that may have impacts on the way the organization is dealing with knowledge In figure 2 this is shown as “incoming” arrows that will influence the execution of the knowledge management cycle. A SWOT analysis as described in section 3.2.2 will help in keeping track of external threats and opportunities. Most organizations already have units specially working in the area of “business intelligence” and their task can be enlarged to include knowledge related issues. In addition it is very useful to install in all knowledge workers the attitude of being on the lookout for weaknesses in the current way of working. Lessons learned programs are particularly powerful for this (see for the importance of lessons learned the papers by Junnarkar and van Heijst et al., this volume).

The monitoring must be evaluated in the light of the original objectives: did the implemented improvement plans led to the results envisioned? This is of course a very tricky question, because the relation between actions and results is quite often tenuous, especially when the time elapsed between implementation of the action and occurrence of results is considerable. But even if one is not interested in finding the precise causal relations between actions and results, the important thing is to have an idea where the organization is going from a strategic perspective. Wiig (this volume) describes these strategies at two levels:

• fundamental strategies providing the driving forces behind the organization;

• knowledge management strategies, giving the main focus to where the organization is heading with its knowledge household.

For more details the reader is referred to Wiig’s paper. Both strategic aspects can be used to evaluate the current performance of the organization against high levels goals. How to carry out this evaluation depends on the nature what is to be evaluated. In principle general methods and techniques for decision support or program evaluation can be used. Some of these are described cursorily in section 3.3.1.

One of the most important elements for effective knowledge management is to get a picture of the knowledge in the organization. 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 organizational role provides the knowledge. The conceptual structure we will employ for dealing with these questions is given in figure 3.

Figure 3: Key aspects of an inventory.

The “what” is answered by identifying business processes, the “which” refers to the knowledge assets that contribute to the successful execution of business processes, the “where” and “when” are captured by the Time and Location descriptors of a knowledge asset and the which organizational role refers to abstract roles in an organization that participate in business processes. In our view these roles can be played by different agents. We will show below how the different methods and techniques enable finding answers to these questions.

The first and foremost question one has to answer is the identification of knowledge assets. However, this is not an easy task because, as has been mentioned above, knowledge assets are rarely immediately visible. This requires the selection of an appropriate description level for knowledge assets. A convenient way to organize these levels is the knowledge detail dimension displayed in table 1 (from Wiig, 1995).

Table 1: Description levels for knowledge assets.

In table 1 the description levels are ordered from general (top) to specific (bottom). From the perspective of an inventory the appropriate description level should be somewhere in the middle of table 1. The top levels are probably too general for providing sufficient details for later phases in the knowledge management cycle. The lower levels are too detailed for an inventory, because they are very close to the operational knowledge itself. In later phases of the knowledge management cycle and when knowledge management actions (e.g., building knowledge based systems) are taken up, the lower levels will come to the fore (see for a “bottom up” view the paper by Wielinga et al., this volume). Thus for the inventory the knowledge section and/or knowledge segment will be preferred

After establishing the description level, the next activity is to identify the knowledge assets and link them to business processes using them (see figure 3). For this a wide range of methods/techniques is available under the name Basic Knowledge Survey Methods. Tables 2 and 3 summarize some of these methods (for more details the reader is referred to Wiig, 1995, chapter 6). In table 2 each method/technique that is mainly geared toward the identification of knowledge assets is characterized with the following aspects:

• what the method is used for;

• which other knowledge management methods it may provide with information;

• what it provides;

• what the method is based on.

Table 2: Overview of knowledge inventory methods (identification of knowledge assets).

Applying one or more of the methods and techniques from table 2 will result in an overview of which knowledge assets are “possessed” by which agents having a location (e.g., a department) in the organization. According to figure 3 we also need to link these knowledge assets to business processes. Of course some information for this will be available from applying methods in table 2, but a more detailed analysis is needed most of the time. Table 3 summarizes some methods/techniques that will support this linking of knowledge assets to business processes. Just as in table 2 the methods are characterized with the following aspects:

• what the method is used for;

• which other knowledge management methods it may provide with information;

• what it provides;

• what the method is based on.

Table 3: Knowledge inventory methods and techniques (linking knowledge assets to business processes).

As can be seen from tables 2 and 3 the methods and techniques will in practice rely on each other because they can reciprocally use information collected. The result of the inventory will be a broad and relatively high level overview of the knowledge assets in an organization. It has been shown to be convenient to “package” the results in a framework that permits a quick look at the crucial aspects of knowledge assets. The framework in table 4 has been used in practice and has been shown to be useful. It is a slightly modified version of the frame presented in van der Spek & de Hoog (1995),

Table 4: Knowledge description frame.

A comparison between figure 3 and table 4 shows that the latter captures the important aspects of the former. The knowledge description frame in table 4 can be easily implemented in data base and hypertext systems, serving as an organizing principle and high level entry interface for more elaborate corporate memories (see also the paper by van Heijst et al., this volume). For example, the “content” category can be further specified to the level of knowledge elements, fragments and atoms by means of methods and techniques used for knowledge engineering (see also Wielinga et al., this volume).

The analysis of strong and weak points can be done in many different ways. We will go deeper into two methods we have experience with: Bottleneck analysis and S(strengths) W(eaknesses) O(pportunities) T(hreats) (SWOT) analysis.

Applying methods and techniques from tables 2 and 3 will give information that point to bottlenecks concerning the use of knowledge. However, before applying these methods one can direct the attention to certain “generic” bottlenecks that frequently occur in organizations. This “sensitizing” is important because most bottlenecks are not easily recognized, particularly not by those who are closely involved in using knowledge assets. In Wiig (1995) a list of knowledge related problems is given which can be used:

• Knowledge is not managed as a valuable asset. In most organizations knowledge is not managed like other assets. Typically, knowledge is not considered explicit as an asset, rather it is considered - and therefore managed - as a commodity ( for a more detailed discussion of the notion of an asset see Wilkins et al., this volume).

• Insufficient knowledge at Point-of Action. In many situations it is found that knowledge workers are asked to perform tasks for which their knowledge is insufficient. They may not possess the required knowledge themselves, nor may it be available through other sources like knowledgeable co-workers, reference material, knowledge based systems etc.

• Missed learning opportunities. It is often found that valuable knowledge flows are missing by not providing feedback from downstream activities to those who are upstream in the business process chain.

• Knowledge transfer is narrow. Quite often organizations train their workforce to perform routine functions competently, but neglect to prepare them to deal with exceptions. This happens when the knowledge transfer to knowledge workers focuses on training rudimentary skills, or when knowledge workers only perform a narrow set of tasks without the opportunity to practice outside its boundaries.

• Unnecessary division of tasks and decisions. For many reasons task and decisions may be needlessly divided between departments, specialty areas, individual workers etc. This typically propagates into the division of knowledge which is needed to perform the complete task. In practice this will lead again to narrow tasks and for the client to the “many windows” phenomenon.

Another way to identify bottlenecks is to use the description frame from table 4 and link observable symptoms to the different aspects of knowledge. This leads to a list of “generic” bottlenecks and associated symptoms:

• Business processes. Limited reuse of knowledge over business processes. Only one or a few business processes listed. Reinventing the wheel.

• Current agents. Vulnerability of knowledge. Only one or a few agents listed. Departure of agent will cause problems.

• Nature. Quality of knowledge for business processes. If process is crucial and knowledge is very heuristic, mistakes and rework will occur frequently.

• Current proficiency levels. Indicators of proficiency are at the low end of the scale. Agents are not well qualified for the job. Mistakes, rework and increasing checking/controlling of work. Proliferation of supervisors.

• Stability. If stability is low a high rate of innovation is called for. Feeling of falling behind the competition. Frantic, undirected search for improvements, quick succession of products meeting with limited success in the market.

• Time. The knowledge is only available during a limited period. Delay and queuing.

• Location. The knowledge is not available at the location where it is needed. Delay and communication (phone calls, sending and receiving forms)

• Form. The knowledge is in the wrong form, it cannot be readily understood by others. Translation needed. Presence of tasks/processes that don’t use the knowledge but only reformulate it.

Both approaches outlined above can be used, depending on the state of the organization. If the knowledge assets have been described in an inventory, the second approach may result in more specific bottlenecks than the first. If not, the best way is to start with the first. Alternating between the two will occur frequently in practice.

Analysis of strengths and weaknesses of an organization and the opportunities and threats it is facing is a well known and widely used technique. In the context of knowledge management it can be used for at least two different objectives:

• setting the high level goals for the organization;

• analyzing the knowledge “household” of the organization from the perspective of one or more of those goals.

For this paper the second is more relevant.

From experience we have learnt that it does not make sense to start a SWOT analysis of the knowledge without a very clear definition of the organizational goal(s) against which to measure the SWOT’s. Thus the first indispensable step is to define this goal or these goals clearly. When there are more goals it is better to perform a SWOT analysis for each goal separately. Lumping too many goals together will confuse the analysis, especially when SWOT’s are generated and judged by different people. In order to make their opinion comparable they need the same frame of reference. The procedure of finding SWOT’s can be different, ranging from intensive sessions lasting for one or several days to individual interviews with knowledgeable people. The approach we follow consists of the following steps:

1. Interview separately the relevant people. Do this in an “open” way, that is without explicitly asking for SWOT’s. Focus the interview by clearly outlining the selected organizational goal and the role of knowledge in achieving it. This could also be part of other methods and techniques mentioned in tables 2 and 3.

2. Analyze the interviews and classify the remarks made as one of the SWOT’s. Analyze all the SWOT’s and combine comparable ones and delete ones that are not relevant for the goal. This should be done by at least three people in order to prevent biases. Try to limit the number of SWOT’s in each category to not more than five.

3. Return to the people interviewed previously (and if necessary other ones) and show them the five SWOT’s in each category. Ask them to add at most five new ones to each category. Next ask them to rank order the SWOT’s in terms of importance for the selected organizational goal.

4. Analyze the rank orders. If there is strong agreement about the importance of the SWOT’s they can be introduced in the SWOT Tactics Matrix (see Table 5). In case of significant disagreement, there might be a problem that needs solving before any further progress can be made in the area of knowledge management. Disagreement can reflect disagreement concerning the goal, but also differences in values and knowledge between the people participating in the SWOT exercise. It is even possible that cliques exist, sharing their rank ordering, which may be diametrically opposed to the one of another group. As there is no common ground for building the SWOT Tactics Matrix, there will be also no common ground for defining and selecting improvements.

5. Build the SWOT Tactics Matrix. This matrix sets off the components of SWOT in columns and rows. The cell entries will become proposals for improvement, indicated in italics are the general strategic approaches that can be pursued. An example of a SWOT Tactics Matrix is shown in table 5.

Table 5: Example of a SWOT Tactics Matrix.

Table 5 contains the results of a SWOT exercise carried out for a faculty of a large university. The selected goal is to increase the income generated from contract research to a certain level at a fixed point in the future. The interviewees were asked to rank order the SWOT’s for the faculty’s knowledge household from this perspective. In the rows and columns the number refers to the aspects most frequently positioned as the most important one. Thus for threats the major one is that all universities try to follow the same strategy. If there are less than five entries in the opportunities/strengths cell this may signify future problems.

Other ways of dealing with knowledge inventories can be found in the paper by Junnarkar (this volume). The different maps that are build in his approach are similar to elements outlined above (e.g., the knowledge map). Wielinga et al. (this volume) explore another road: using libraries of ontologies.

The Conceptualize phase is an important one that should be carried out thoroughly. It provides the major inputs for the next phase where the emphasis is on deciding. Aspects missed or left out in the Conceptualize phase will decrease the quality of the decisions made in the Reflect phase, because problems and bottlenecks are overlooked, alternatives are wrongly specified or not at all, impacts of improvements and improvement plans will be wrongly estimated and value conflicts will remain undetected.

The main goal of the Reflect phase is to produce improvement plans that stand a reasonable chance of success when executed in the Act phase. Though this seems to be a bit of academic hairsplitting, we want to keep the distinction between an improvement and an improvement plan. In order to implement an improvement, actions must be undertaken, actions which will have to take into account organizational and other obstacles. In practice there will be substantial iteration between the definition and selection of improvements and the definition and selection of improvement plans. In the former the emphasis on increasing the value of knowledge assets for the organization (i.e., the goal function is mainly value oriented), while in the latter risks become more important (i.e., the goal function is mainly oriented toward risk reduction).

The Conceptualize phase will, as has been mentioned above, produce a set of bottlenecks, problems, opportunities, weaknesses etc. for which improvements must be identified. In addition, when not all improvements can be realized at the same time or some may be too costly, they have to receive a priority rating. 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. Many so-called improvements came to grief simply because they were defined before a proper Conceptualize phase had been carried out. Of all errors that can be made, the worst ones are solving the wrong problem and selecting the wrong solution. Especially when information technology could be involved these dangers loom large. Another mistake is to think that improvements/solutions can be simple, single measures. As managing knowledge is a complex task and knowledge is deeply embedded in the workings of the organization it is only rarely the case that something simple will bring big yields. Thinking in terms of panaceas, is the usual companion of the two errors just mentioned.

Defining improvements is a difficult task which will require a substantial number of iterations. Probably a good approach is to think in terms of programs than in terms of more or less isolated actions. As the actual definition of improvements depends strongly on the context, we will list as suggestions some of those programs below.

• Effectiveness improvement programs.

Another approach is to stay close to the SWOT Tactics Matrix. This requires that the cells in this matrix must be filled with alternatives that can deal with the four options. Table 6 shows how the SWOT Tactics Matrix from table 5 could look like for the example.

Table 6: Example of a SWOT Tactics Matrix with improvements.

It is important to provide a substantial number of improvements in the Matrix as the main goal is still to broaden the range of options. When it comes to the selection of improvements, unattractive alternatives will disappear, while untenable ones will not survive the risk analysis of plans carried out in section 3.3.2.

Taking the bottlenecks as a starting point is also feasible. However, there is a danger that the way a bottleneck is stated implies a bias toward a certain improvement type. If we take the Location bottleneck and the resulting effect of delay and communication it is tempting to think in terms of information technology improvements. One could develop a knowledge based system that contains the necessary knowledge and distribute it either physically or through a network to where it is needed.. This overlooks other options like training the knowledge worker at the point of action, providing a paper guide, making communication less time consuming (e-mail) etc. In addition, the knowledge based system alone will not do the job. Using it requires also training, the system must be maintained, the necessary equipment must be in place. Thus the improvement is not only the knowledge based system but all associated measures are part of it.

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. Fortunately we are on firm ground for this problem. Decision analysis was thoroughly researched during the last forty years and this resulted in a well defined repertoire of methods. The most suitable approach seems to be Multi-Attribute Utility Theory (or MAUT) as described in von Winterfeldt & Edwards (1986). This method requires that all alternatives can be evaluated on a set of attributes that represent important value concerns for the decision maker. The overall value or utility of an alternative is a particular combination of the values on the separate attributes. For eliciting value functions over attributes and rules for combining attribute values, a wide range of procedures is available. An extensive description of these is outside the scope of this paper, because they are well covered by the cited literature. In addition there is a suite of computer programs that automate parts of this procedure (e.g., Logical Decisions®), while Olson (1996) describes several other programs that embody procedures that differ from MAUT. Computer programs are very useful for investigating the sensitivity of the priorities for changes in some of the input components (e.g., differences in importance between attributes). MAUT is based on the idea of a single decision maker whose value concerns are elicited and used. Quite often decision making concerning knowledge management improvements is collective. This complicates the procedure because there is no satisfactory solution to the question of interpersonal utility comparisons (“my values are not other people’s values”). When decision making is collective one should turn to procedures for group decision making, which range from pure negotiation games to consensus seeking approaches (see for an overview op group decision making Wilkenfeld et al., 1995).

Somewhere in the decision process the need can arise to put a value on knowledge assets. This value can either be entirely judgmental or based on some “objective” measurements, for example in terms of money. Finding such a measurement is very hard indeed. Wilkins et al. (this volume) review several proposals, but many only address the combined value of all knowledge assets of an organization. Measuring the value of separate knowledge assets is a different story, and the method proposed by Wilkins et al. (this volume) still has a considerable number of limitations. However, every method for measuring the value of knowledge assets will need a definition of the knowledge assets to begin with. Thus a proper knowledge inventory is a prerequisite for dealing with the valuation issue. The question of the value of knowledge assets will surface in almost all phases in the knowledge management cycle. In absence of a widely applicable method based on “hard” data, judgments will for some time to come be the only way to deal with this valuation issue.

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. Thus aspects normally needed for projects must be paid attention to, like:

• time scale (start date, end date);

• budget (amount of money that the project has available);

• deliverables (what is the project going to deliver and when);

• people and other resources (inputs to the project);

• quality planning and control (who keeps track of the quality of the products);

• responsibilities (who takes care of what, who is the project leader).

As each of these aspects 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.

Risks can be assessed by a simple schema that combines the probability of occurrence of a risk with the estimated severity of the impact on one or more quality features of the improvement plan. In general risks with a high probability of occurrence and a severe impact must be taken serious. An improvement plan exposed to several risks exhibiting this high/severe combination, should be reconsidered, even if the expected gain from it is large. If we take for example from table 6 the improvement “Consider reorganizing working arrangements on a less “scientific” basis” and we have made a plan to achieve this in six months, it can be that people entrenched in the current structure will oppose the plan and the time scale because it could undermine their position. If we estimate the probability of this to be high, and such actions will create havoc in the organization, it might be wise to reconsider the improvement plan.

Assessing risks can be supported by risk lists that serve as memory support. Being forced to check for all risks in the list, will create awareness of risks and forces people to think about them carefully. As yet there are no risk lists for knowledge management plans, but for the time being use can be made of lists developed for knowledge based systems development. In de Hoog et al. (1994) such a list is provided consisting of the major components shown in table 7. The risks are formulated in terms of possible impacts on different aspects of the organization.

Table 7: Tentative risks/impacts list for improvement plans.

Though most plans will be carried out in projects not all of them will. Some are ongoing concerns which should become part of the normal operations of the organization. For example, the improvement “Liaise with congress/courses organizers” from table 6, will be something that is not meant to happen in a limited (project) period of time. Nevertheless, it still important to plan them and think about responsibilities and risks. Another important aspect is to ask for periodic reports which will enable monitoring of performance. As long as knowledge management is not incorporated into all normal operations, one should not fall into the trap of believing that execution of plans goes without further monitoring.

The Act phase of the cycle in figure 2 concerns the actual “running” of the improvement plans. In the conceptual frame chosen in this paper this work is not part of knowledge management. It belongs to adjacent areas having their own methods, techniques and tools for support. Some of these are:

• Human Resource Management Many improvements will have immediate consequences for people in the organization. To mention a few: remuneration schemas, training, promotion, hiring of staff, mobility of personnel etc. Human Resource Management is a well developed field and the reader is referred to books like Noe et al. (1994) for more details.

• Information Technology Another major enabler is information technology. It offers all kinds of techniques that can be used to improve the knowledge household. A non-exhaustive list is: knowledge based systems, data base systems, machine learning, workflow systems, group decision support systems etc. For developing these applications they have their own methods and techniques. For example, for knowledge based systems the comprehensive CommonKADS methodology is available, making knowledge engineering results accessible (see for more details Wielinga et al., this volume).

• Organization development Quite often the way of organizing and the way of working has to be resonsidered. Business Process Reengineering is an important approach in this area (see Hammer & Champy, 1993), but others can be found in the literature (e.g., Lorsch, 1987).

The monitoring of the actions belong to the next step in the cycle and is discussed in section 3.1.1, thus completing the circle!

In this paper a selection of methods and techniques was presented for supporting knowledge management. They were ordered by means of a conceptual frame representing the knowledge management cycle. Due to its wide ranging nature many more methods and techniques can be included in the repertoire of knowledge management. The book by Wiig (1995) is a major source, but is still far from complete. Notwithstanding this comprehensive repertoire there are still some areas which are less well covered. They are related to some of the peculiar characteristics of knowledge mentioned in section 2:

• intangibility: the proper description level of knowledge assets is still under discussion;

• measurability: the value of knowledge is hard to determine, workable valuation schemas are not yet available though the paper by Wilkins at al. (this volume) is a step in this direction;

• lead times: learning is difficult to achieve, lessons learned programs and the so-called “learning organization” are still far from abundant;

• agents with wills: implementing improvement plans entails the analysis of risks, many risks are associated with the importance of knowledge for behavior of people in organizations, good methods for analyzing these risks are lacking.

Especially in these respects the repertoire can be extended and most of the other papers in this special issue are devoted to one or more of them.

Hammer, M. & Champey, J. (1993). Reengineering the corporation: A manifesto for Business Revolution. Harper Collins, New York.+

Hoog, R. de, Benus, B., Metselaar, C., Vogler, M. & Menezes, W. (1994). Organization Model: Model Definition Document. Report ESPRIT Project P5248 KADS-II, KADS-II/M6/DM6.2c/UvA/041/3.0, University of Amsterdam.

Lorsch, W.J. (Ed). Handbook of organizational behaviour. Prentice-Hall, Englewood Cliffs.

Noe, R.A., Hollenbeck, J.R., Gerhart, B. & Wright, P.M. (1994). Human Resource Management; gaining a competitive advantage. Irwin, Homewood.

Olson, D.L (1996). Decision aids for selection problems. Springer Verlag.

Spek, R. van der & Hoog, R. de (1995). A Framework for a Knowledge Management Methodology. In: K. Wiig, Knowledge management methods. Practical Approaches to Managing Knowledge. Schema Press, Arlington, Texas, 379-393.

Standish Group International (1996). Report presented at the International Project Leadership Conference, Paris.

Wiig, K. (1995). Knowledge management methods. Practical Approaches to Managing Knowledge. Schema Press, Arlington, Texas.

Wilkenfeld, J., Kraus, S., Holley, K.M. & Harris, M.A. (1995). GENIE: A decision support system for crisis negotiations. Decision Support Systems, 14, 369-391.

Winterfeldt, D. von & Edwards, W. (1986). Decision analysis and Behavioural Research. Cambridge University Press.

Версия для печати  |  Пользовательское соглашение