Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 15 Knowledge Management Activities. - 2 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern Recommended.

Similar presentations


Presentation on theme: "Chapter 15 Knowledge Management Activities. - 2 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern Recommended."— Presentation transcript:

1 Chapter 15 Knowledge Management Activities

2 - 2 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern Recommended References General literature on knowledge management: –J. Liebowitz (ed.): Knowledge Management - Handbook. CRC Press –Harvard Business Review on Knowledge Management Reference for change management: –B. Dellen: Change Impact Analysis Support for Software Development Processes. Shaker Verlag 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 - 3 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 - 4 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern The Flow of Knowledge Data Information Knowledge Data Bases Knowledge Base Actions Flow from external sources restructure make explicit use

5 - 5 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 - 6 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 - 7 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 - 8 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 - 9 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern general process general knowledge actual data and information actual process Knowledge and Processes instance needs

27 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern Knowledge Support for Processes (1) Step in the general process (process model) Corresponding steps in the actual process Knowledge Source The knowledge manager organizes the necessary sources Instantiation Details

29 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 Task (5): Organizing the Use of Knowledge This task is very complex and uses different techniques. Some will be discussed here.

36 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern A Change Management Architecture (2) Knowledge managerGeneric rule pattern manager Listens to changes Domain rule pattern manager Listens to changes Change rule manager Adds, removes change rules Adds, removes change rules

56 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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 (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern 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.


Download ppt "Chapter 15 Knowledge Management Activities. - 2 - (c) 2000 Dr. Ralph Bergmann and Prof. Dr. Michael M. Richter, Universität Kaiserslautern Recommended."

Similar presentations


Ads by Google