Knowledge Management Activities

1
Chapter 15

• Knowledge Management Activities

2
Recommended References

• General literature on knowledge management
• J. Liebowitz (ed.) Knowledge Management -
  Handbook. CRC Press 1999.
• Harvard Business Review on Knowledge Management
• Reference for change management
• B. Dellen Change Impact Analysis Support for
  Software Development Processes. Shaker Verlag
  1999.
• Abstraction and Cases
• R.Bergmann Effizientes Problemlösen durch
  Wiederverwendung von Fällen auf verschiedenen
  Abstraktionsebenen, DIKI 138, infix Verlag 1996
• Processes and information
• Boris Kötting, Michael M. Richter, Sigrid
  Goldmann Flexible Workflow Management in
  Software Engineering Processes

3
KM and Suppliers Utility

• The overall guiding line for knowledge management
  activities is provided by the preferences and
  utilities of the supplier who has, however, to
  take care of customer needs.
• This is mainly reflected in the strategic model
  of the supplier.
• Here this will not be discussed, we instead look
  at the consequences for the formal models and
  actions of the supplier. They will be discussed
  on a general level and have to be instantiated
  for specific applications. Each application has
  its own characteristics.
• An orientation is given by the sales cycle and
  its refinements in chapter 1, augmented by the
  suppliers view.

4
The Flow of Knowledge
Data
restructure
Knowledge Base
Data Bases
Information
make explicit
use
Flow from external sources
Knowledge
Actions
5
The General Szenario

• We assume a general agent scenario (see chapter
  14B).
• The agents (humans or machines) are
• One or more actors who carry out certain actions
• A knowledge manager KM, who has access to
  information sources, and who has to structure,
  maintain and apply them
• An external environment which can generate
  events.
• In this szenario a communication goes on, and any
  of the agents can take the initiative.
• The knowledge manager has to interact with all
  other management activities because they all need
  the knowledge
• The KM can act on demand and on his own
  pro-active

6
Active and Passive

• Active and passive are roles of agents
• Passive means in a context that the action an
  agent performs is a reaction on some other action
  which contains a demand.
• Active means that the action is not determined by
  a demand but the agent sees a necessity from an
  overall point of view. The action is usually
  triggered by some event The action usually asks
  for a further reaction.
• The switch from the role passive to active is
  called to be pro-active.

7
Fully Automatic Systems

• In the past knowledge based systems worked fully
  automatic
• They contained a correct and complete knowledge
  base.
• When they obtained an input they derived the
  output via reasoning (using an inference
  component) applied to the knowledge base.
• Often the desired the output contained besides
  the problem solution some explanation.
• The problems connected with fully automatic
  systems were
• to achieve and to maintain such a knowledge base
  (the knowledge acquisition bottleneck)
• partial solutions were useless because they are
  reported as failures.

8
Assistant Systems (1)

• The idea of an assistant system is to operate
  only partially automatic and to employ humans
  too.
• A consequence is that assistant systems usually
  do not perform long chains of inferences.
• Advantages of assistant systems are
• The work can employ knowledge and abilities of
  humans.
• To shift tasks between human and machine If a
  task is fully understood and all knowledge for it
  is available it can be transferred to the
  machine, i.e. automized. This can be done
  incrementally.
• Humans can take over the responsibility for
  decisions.

9
Assistant Systems (2)

• Assistant systems and knowledge
• The humans use and need knowledge
• Knowledge helps the human
• A knowledge based system to support humans has to
  have the character of an assistant system.
  Consequences
• Knowledge and its use has to be integrated in the
  general structure of the organization
• The division of labor between human (e.g.
  decision maker) and machine (automatic
  presentation of knowledge) has to be well
  understood

10
Assistant Systems (3)

• Assistant systems are a special kind of knowledge
  based systems. Two types of agents cooperate
• Human agents
• Software agents
• Hence assistant systems are examples of
  socio-technical systems.
• The human agent is dominating
• Sets the goals
• Is responsible
• The human agent is creative.
• The human agent cannot deal well with large data
  sets, complex computations etc.

11
Assistant Systems (4)

• The software agent (the assistant) is
  subordinate
• The decisions are of limited character
• The space of freedom for actions is limited and
  precisely defined.
• The assistant knows
• The range of the decisions, i.e. what to do on
  his own with which degree of freedom
• Whom to inform about the decisions.
• Often the assistant has only to provide
  information
• in a very effective way
• not to much and not less
• at the right time.

12
Assistant Systems (5)

• A major problem is the interface between human
  and software agents which is the bases for
  communication
• The software agent acts as a formal system and
  requires formal input in a specific
  representation form
• The human agent has limited memory
• The human wants information in a form suitable
  for human understanding and reasoning.
• Therefore the interface has to perform a
  non-trivial transformation. The use of
  interchange formats like XML may be helpful but
  is by no means sufficient.
• The interface has also to reflect that the human
  has the responsibility for descisions.

13
Classification of Knowledge Management Tasks

• 1) Searching for knowledge and receiving
  knowledge
• 2) Restructuring the knowledge
• 3) Making knowledge explicit
• 4) Associating the knowledge with the actions
  described in the process model
• 5) Making knowledge available for actions which
  need it and delivering it to the right agents in
  the right moment
• 6) Updating knowledge and change management
• 7) Quality management

14
Knowledge Management and General Management

• All these tasks cannot be separated from the
  general management activities.
• Knowledge is used when actions are performed and
  actions are organized by the management.
• Actions on the other hand change the knowledge,
  e.g.
• organizational changes
• change in the employees
• change of the context (new products, customers
  etc.)
• Therefore knowledge management is a central
  element of management.

15
Knowledge Management Technical Aspects

• Knowledge is electronically stored in data bases
  on computers.
• These locations have arisen historically and are
  often not compatible with each other.
• A consequence is that important knowledge cannot
  be found when necessary.
• The first step for the management is to define a
  knowledge structure in order to know where is
  what.
• The second step is to organize communications,
  e.g. by introducing adequate client-server
  structures.

16
Task (1) Searching and Receiving Knowledge

• Data, information and knowledge does not come
  from itself
• Some sources of knowledge are known, others have
  to be found
• Knowledge sources do not continuously have new or
  interesting knowledge
• The management task is
• Get an overview over sources and organize the
  search for them
• Determine the times (or periods) when sources
  have new knowledge
• Organize the access to and the flow from the
  sources
• Receive the demanded knowledge properly
• Classify and receive the knowledge which came in
  but not on demand
• It is important that these activities are
  standardized
• Techniques of document analysis are important

17
Document Oriented Knowledge Structure

• The knowledge is in documents and the content is
  clear from the document description the type of
  reaction to the content is known from the type of
  the document, e.g.
• Bills
• New pricelist
• New product list
• Change of address
• Access to the knowledge inside of the documents
  does therefore not require to study the document
  itself.
• This is like the access in data bases where one
  has only to know the key of the stored data.
• The flow of knowledge therefore reduces to the
  flow of documents and the search for knowledge is
  the search for documents.

18
Tables

• Often knowledge is organized in tables with a
  number of columns and rows.
• Such tables are presented in a certain layout.
• It is not always easy to reconstruct the original
  table from the presented layout
• lenght of entries may vary
• entries may contain several lines
• Distances between rows or columns may vary
• This puts restrictions for extracting the content
  of the table from the table document.

19
Content Oriented Knowledge Structures (1)

• It is not sufficient to know the title or the key
  of the document in order to react properly.
• It is rather necessary to study the document
  itself.
• Examples
• Complaints from customers
• Special regulations for special purposes
• Scientific documents
• Legal documents
• The access to the documents should be simplified,
  e.g. using abstracts, extracting key words etc.

20
Content Oriented Knowledge Structures (2)

• The knowledge management should structure the
  knowledge and simplify the access.
• This is an area where the similarity concept
  plays an important role because no exact key
  matches are possible but often inexact matches
  with document descriptions are applied.
• Linguistic tools, Thesauri etc. are useful.
• In most situations, content oriented structures
  are still handled by humans. But the humans need
  support.

21
Task (2) Restructuring Knowledge (1)

• The incoming data, information and knowledge are
  usually not structured in the form required from
  the applications, e.g.
• Wrong format
• Redundant
• In an inadequate context
• Not applicable etc.
• The task of the knowledge management is to
  organize
• Restructuring
• Pointing out weaknesses and getting other sources
• Again, this should be standardized

22
Task (2) Restructuring Knowledge (2)

• Restructuring has to aspects
• Restructuring of a single input document
• Embed ijn or distribute the input over the whole
  knowledge structure.
• The whole knowledge structure is determined by
  the general structure of the company. Therefore
  the proper handling of input knowledge is
  connected with the general structure and
  strategy.
• It may be necessary to duplicate knowledge used
  by different agents.
• Different agents may need knowledge pieces in
  different forms or formats.

23
Task (3) Making Knowledge Explicit (1)

• Knowledge is often implicitly contained in data
  or texts.
• It is the purpose of data mining techniques to
  make knowledge in data bases explicit.
• The knowledge management has to organize this
• Where are weak points ?
• Which information can be helpful for improvement
  ?
• How to obtain the information ?
• Data mining activities are long term activities,
  they are costly and need careful planning (see
  chapter 13).
• The knowledge managers decides which data mining
  activities have to be carried out.

24
Task (3) Making Knowledge Explicit (2)

• Knowledge in texts can at least partially be made
  explicit by
• Extracting key words
• extracting phrases
• extracting abstracts.
• The key words, phrases or form of the abstract
  has to be determined according to the needs of
  the users. Problems arise if different user types
  are present.
• Key words are often insufficient or even
  misleading.
• Such techniques have been developed in
  information retrieval and use e.g. liguistic
  tools.

25
Task(4) Which Knowledge for What ?

• The use of knowledge in business is not for fun
  but
• Is oriented on business processes
• Influences partially the general structure of the
  processes
• Has to allow a fast and optimal representation of
  the knowledge in actual contexts
• If no actions are involved the knowledge is
  silent !
• If actions are performed without knowledge they
  are useless !

26
Knowledge and Processes
general process
needs
needs
actual data and information
general knowledge
instance
actual process
27
Types of Processes (Examples)
Sales offer A dialogue has to be started Design
and planning processes Process models are
instantiated Execution processes Correct
information of participants (A problem if changes
occur Who has to be informed about what
?) Fault diagnosis Reasons for failure ? Which
data are needed for the diagnosis ? (Help desk
problem!) Logistic chains Transportation and
delivery over several steps Processes may deal
with physical objects or pieces of information.
28
Knowledge Support for Processes (1)
Step in the general process (process model)
Instantiation Details
Corresponding steps in the actual process
The knowledge manager organizes the necessary
sources
Knowledge Source
Knowledge Source
Knowledge Source
29
Knowledge Support for Processes (2)

• The process model can be described in various
  levels of abstraction. On each level the
  preconditions and effects of an action are
  described in an appropriate abstraction.
• On abstract levels the types of knowledge
  dominate. Each type is associated with a
  knowledge source.
• The main tasks of the knowledge manager include
• Structuring the knowledge sources according to
  the process model
• Distributing the knowledge correctly
• Establishing the links between the actions in the
  process model and the knowledge sources
  dynamically (i.e. observing the time schedule)

30
Information Goals

• The actual information needed for a process is
  usually incomplete
• The information is available from internal or
  external sources
• Costs are involved in order to obtain the
  information
• The information has some value for the actions
  chosen in the process
• Consequence for knowledge management
• Define information goals and a plan to achieve
  them in order to have optimal effects

31
Cost/Benefit Consideration

• Cost aspect Obtaining information has costs
  (direct payment, time of employees etc.)
• The value of the information is determined by the
  actions performed
• Performance of actions is more costly if done
  without the right knowledge. It is important do
  quantify this properly !
• Executed actions lead to new situations which
  have now costs or gains as a consequence.
  Knowledge can make predictions.
• The value of a piece of knowledge is the
  difference of costs connected with the action
  when performed with or without the knowledge.
• This has an individual and a statistical
  interpretation.

32
Standardized and Non-standardized Processes

• Standardized processes occur regularly in the
  same way although each instance has different
  data inputs.
• Non-standardized processes also occur often but
  only the principal task of the process is known
  and each time the process has its own appearance.
  A general process model may be too abstract to be
  useful.
• Non-standardized process should not be mixed up
  with completely new and surprising actions which
  react on unforeseen events and which have no
  process model at all.

33
Standardized Processes

• Because the structure of the process is known it
  is also known which type of knowledge is needed
  in order to perform them properly.
• The task of the knowledge management is to
  provide such knowledge and data structures such
  that knowledge support is simple Here the
  support is document oriented. For this purpose
  the KM has to watch the process.
• Example Because employees have their regular
  vacations a corresponding list is advisable and
  persons on vacation can be replaced properly.
  This task is more difficult when persons become
  sick or leave the company.

34
Non-standardized Processes

• Because of the somewhat irregular type of these
  processes it is often not possible to provide
  standard documents with the knowledge needed.
• On the other hand the type of knowledge is known
  and it is the task of the knowledge management to
  make access to this knowledge possible.
• Example It cannot be foreseen which employee
  will be sick and a list of all possible
  replacements for every sick person is usually
  impossible. But the knowledge structure should it
  make possible to find out who can replace a
  person in an actual situation.

35
Task (5) Organizing the Use of Knowledge

• Knowledge has for each
• task to be accessible
• for the right persons
• at the right time
• at the right place
• in the needed format

• Missing Knowledge
• creates errors
• Too much knowledge confuses

This task is very complex and uses different
techniques. Some will be discussed here.
36
Task (6) Change Management

• Knowledge is not invariant but undergoes
  continuous changes. There are external reasons
  for this (the context changes) as well as
  internal reasons (e.g. organizational changes).
• These changes have to be reported at the right
  time to those agents who need it.
• The report can be given on demand as well as
  pro-active.
• The change management organizes this in a
  systematic way.

37
Task (7) Quality Management (1)

• The aspects of quality are a consequence of the
  utility concepts.
• Quality decreases over time due to changes
  (external as well as internal) if no reaction
  takes place.
• The quality of the processes has to be controlled
  continuously
• Oberservation of the environment data
• Observation of the process
• Interpretation of observed data on the basis of
  quality models.
• The results of the control are transformed into
  actions which re-establish the quality.

38
Quality Management (2)

• Quality conditions are defined as constraints
• Hard constraints Have to be satisfied in any
  case
• Weak constraints should be satisfied but not
  under all circumstances.
• Weak constraints have degrees
• in hierarchical orderings
• by point valuations
• in fuzzy degrees
• This leads to an optimization task Weak
  constraints should be satisfied in an optimal
  way. This should optimize the intended quality.

39
Quality Management (3)

• For each violation of a constraint a maintenance
  operation has to be defined.
• The degree of weakness of each constraint is
  transformed to a degree of importance of the
  maintenance operation.
• There have observable events to be defined which
  can easily be checked and which indicate
  (possible) constraint violations.
• On this basis a practical system has to be built
  in order perform maintenance efficient and
  economically.
• The knowledge manager has to ensure the quality
  of the knowledge and has in particular to deal
  with knowledge gaps (see chapter 2).

40
Maintenance

• The maintenance operations are structured in two
  ways
• importance
• events which trigger the operations
• The trigger is usually an event
• An analysis can show that the events take place
  in certain periods of time Then time points can
  take over the role of triggering.
• Operations which are dependent on similar
• events
• points of time
• objects to maintain
• can be grouped into packages of maintenance
  operations.

41
Formal Notions

• In order to support the KM all activities and
  objects of interest have to be formally
  represented.
• We refer to chapter 4 with respect to the formal
  representation techniques.
• We distinguish between actions which occur in the
  planning phase of the manager and actions which
  the manager really executes. These actions will
  change the real world (e.g. sending a message).
• The knowledge manager has an own knowledge base
  which governs the management actions and is about
  the other knowledge bases.

42
Actions on Knowledge Bases

• A knowledge manager has to maintain the knowledge
  bases and this requires actions which change
  these bases.
• The formal notion of such an action is defined in
  chapter 4.
• A particular type of action is important in this
  content Actions which are generated because of
  the change of the context (the outer world).We
  call such changes events.
• The formal representations are the ECA- Rules
  (Event-Condition-Action-Rules
• IF Event AND Conditions THEN Action
• These rules specify the preconditions in the way
  that they distinguish between external events and
  internal conditions.

43
Changes and Dependencies

• Entities for a process are concepts which
  organize the knowledge for the process (e.g.
  catalogue or an internal price list).
• An entity E has a change impact on an entity F if
  a change of E results in a change of F. E.g., the
  internal price list has a change impact on the
  catalogue.
• An entity E is change dependent on an entity F if
  a change of E may result in a change of F.
• Two entities are change dependent if one of them
  is dependent on the other one.
• E.g., the buying price and the sales price of a
  product are change dependent.

44
Change Knowledge

• The change knowledge describes all aspects of
  changes
• The source and the initiator of the change
• The description about what is changed
• The reasons of the change
• The dependencies and the dependent entities
• The rationals for the dependencies
• The impact on the dependent entities
• The agent who executes the change

45
Change Operators

• The actual change is described by operators.
  These operators are defined on information units,
  e.g. on attributes, formulas etc.)
• We distinguish (as usual) three types of
  operators
• ADD operators Adding an information unit.
• REMOVE operators Removing an information unit.
• MODIFY operators Replaces some information unit
  by another one. This can be defined as a macro
  operator in terms of ADD and REMOVE.
• Operators are defined on a general level and can
  be instantiated.

46
Information Dependency

• An action A is strongly information dependent on
  an information unit IU if A cannot be properly
  executed without the knowledge of IU.
• An action A is performance dependent on an
  information unit IU if A can be better executed
  with the knowledge of IU.
• In both cases the execution of A gives rise to
  the information goal IU.
• If the agent who executes A is active he sends a
  query to some agent (possibly the KM) or
  knowledge source.
• If the KM is active he sends the information to
  the agent (pro-active).

47
Pro-active Actions, Trigger and ECA-Rules

• Pro-active actions have to occur with a goal
  Actions have to be carried out where and when it
  is necessary but not unnecessary or randomly.
• In order that such actions do not take place in
  an arbitrary way they have to be activated by a
  trigger.
• The most important form of triggering is again
  represented by ECA-rules
• Event-Condition-Action Rules
• Event Something (usually external) that starts
  the rule
• Condition Description of special circumstances
  necccessary
• Action Action (e.g. giving certain information
  to some agent)

48
ECA-Rules

• Actions on demand are also described by
  ECA-Rules
• Event A demand or query
• Condition Description of when action is expected
• Action Action (e.g. giving certain information
  or help to some agent or to perform something)
• ECA-Rules contain important knowledge
• ECA-Rules have to be structured
• The structure should reflect the tasks of the KM
  and the process model

49
Generating and Using Rules

• Rule patterns are defined at compile time they
  represent general knowledge. The generality is
  contained in the variables which can be
  instantiated in their domain.
• Patterns use typed variables (e.g. for products,
  documents, agents, ...).
• Instances of rules are generated at run time and
  this is again triggered by events.
• The time of generation of rules is not
  necessarily identical with the time when they are
  used. This time is determined by the event which
  is part of the precondition of the rule.

50
Example ECA-Rules for Change Management (1)

• Change rule pattern
• Event ADD, REMOVE or MODIFY operation (with
  variables also for documents).
• Condition A formula (with variables also for
  documents).
• Action Two types of actions
• 1) Change actions As in the event part
• 2) Notify actions An operation of the form
• NOTIFY(recipient, cop, rat, reason, init)
• where recipient is an attribute which
  applies to agents or an operation of the form
  responsible(d) where d is of type document, cop
  stands for the change operation in the event, rat
  is of type rationale for the change dependency,
  reason is of type reason for the change, init is
  of type agent or of type responsible(d) d of
  type document (the agent responsible for the
  event).

51
Example ECA-Rules for Change Management (2)

• Example Changes in the internal price list
  (document pl) cause a change in the catalogue
  (document c). Short form of the rule pattern
• Event
• REPLACE(pl, product prod, price x, price y)
• Condition
• product prod in pl and in c
• Action
• NOTIFY(responsible(c) , event, price of prod,
  new parts, price manager)
• An instance of the pattern is e.g. given by
• pl pl1, c c1, prod TV, x 750, y 770,
  responsible(c1) Hans, new parts video, price
  manager Peter.

52
Discussion (1)

• In the example the only action is notification.
  Further support would provide information how the
  catalogue is changed, e.g. additional information
  on the improved product. Here this is left to the
  creativity of the catalogue agent.
• Important knowledge is contained in the relation
  that product prod is in both, the price list p
  and the catalogue c. It is therefore useful that
  the agent responsible for c has for each product
  an entry which specifies the source of the
  description details.

53
Discussion (2)

• The KM has to
• define the rule patterns and the instances
• group the rules in packages
• determine when the rules are applied
• organize the network through which the
  communication takes place and how the actions are
  executed
• determine how the notification is received (e.g.
  is a receive notification demanded ?).
• These are organizational aspects responsible for
• safe
• efficient
• flow of information.

54
A Change Management Architecture (1)

• Agents and their relations
• The knowledge manager KM Takes care on the
  knowledge base.
• The generic rule pattern manager Stores the
  generic change rule patterns and has to listen to
  knowledge base updates which may result in new
  instances of the patterns (any addition/removal
  of an entity may result in addition or deletion
  of a change rule).
• A domain rule pattern manager Same as above, but
  dealing with domain dependent change rule
  patterns.
• Change manager Manages the change dependencies.
  Changes in the knowledge base are notified by
  this agent and may cause the change rules to fire
  which in turn cause further knowledge in the
  knowledge base.

55
A Change Management Architecture (2)
Listens to changes
Knowledge manager
Generic rule pattern manager
Listens to changes
Adds, removes change rules
Domain rule pattern manager
Adds, removes change rules
Change rule manager
56
Example ECA-Rules for Information Management (1)

• Suppose agent ag is responsible for action A.
• Information query rule pattern
• Event Action A has to executed
• Condition A formula F (with variables) in the
  preconditions of A
• Action Prolog-type query to the KM For which
  values of the variables in F will f evaluate to
  true?
• QUERY(recipient, ag, F, list of variables, A)
• where recipient is an attribute which applies
  to agents or knowledge sources.
• Example QUERY(storage manager, sales person,
  delivery time(prod), offer(prod)).

57
Example ECA-Rules for Information Management (2)

• Suppose agent ag is responsible for action A.
• Pro-active information rule pattern
• Event Agent ag will now execute action A (this
  event is a result of the observation of ag by the
  KM)
• Conditions A formula Improve(A, IU) (information
  unit IU improves performance of A) a formula
  notinformed(ag, IU) (agent ag does not have
  information IU)
• Action NOTIFY(ag, A, IU, reason)
• Example NOTIFY(ag, consulting customer C on
  product type P, special information on P, C has
  asked for details on P last time)
• Such rules are also used during a dialogue

58
Summary

• A general knowledge management with agents was
  described.
• Knowledge management and process models are
  strongly connected
• Knowledge gaps are often difficult to discover
• Different tasks of the KM were discussed, in
  particular change and information management
• ECA-rules were introduced as a general formalism
  for triggering actions.