1 / 58

Chapter 15

Chapter 15. Knowledge Management Activities. 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:

triage
Télécharger la présentation

Chapter 15

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

More Related