Business Process Support as a Basis for Computerized Knowledge Management Birger Andersson1, Ilia Bider2 , Erik Perjons1 1
Royal Institute of Technology, Stockholm, Sweden, email:
[email protected],
[email protected] 2 IbisSoft AB, Stockholm, Sweden, email:
[email protected]
Abstract. One of the major factors behind the less successful implementations of computerized knowledge management systems (KMS) is lack of motivation to use such a system on behalf of the end-users. The authors argue that to create such a motivation, i.e., achieve usability, a computerized KMS should be integrated with a business process support (BPS) system and provide three main functionalities: (1) provision of context, (2) automatic gathering of experience-based knowledge, and (3) an active generalized knowledge base. For creating such an integrated KMS/BPS, the authors suggest to use a state-oriented view on business processes. The paper describes a version of a system built according to this view. The system fully implements the first two functionalities, the third one being under development. The system was operationally tested internally, and it is currently installed at a pilot site. Research work in progress includes creating a formal language for representing an active generalized knowledge base, and investigating the impact of the introduction of an integrated KMS/BPS on the pilot organization.
1. Practical motivation To handle normal daily operations, any organization needs to have some kind of a system for managing practical knowledge required for completing them. Below, we will refer to this knowledge as to operational knowledge. Such system is aimed at gathering, storing and giving access to: • Knowledge on operational goals, policies, and procedures (routines) • Knowledge on current state of affairs in the organization • Knowledge on past experience Usually the operational knowledge is distributed throughout the whole organization [Davenport et al., 1998]. A large part of it is in the heads of people who: • are working in a particular department (knowledge about goals, policies, and procedures), • are engaged in a particular project/case/sale (knowledge about current state of affairs), or • have experience of past projects/cases/sales and their outcomes (knowledge about past experiences) If the knowledge resides only in the heads of people, the organization is vulnerable to absence of staff members. Nobody can answer a question about the state of affairs in a particular project/case/sale. Nobody can help to determine what to do next, or give an example of how a similar problem was successfully solved in the past. In addition, replacing old staff with new becomes unnecessary hard. Thus, one of the main business objectives of having a Knowledge Management (KM) system is to ensure that the knowledge belongs to the organization as a whole, not just to the individuals who work for it [Davenport et al, 1998]. To introduce a separate knowledge management system is not economically feasible, especially for small and medium size organizations. Furthermore, a separate system would result in an extra burden on the members of staff. It will require that they not only complete their everyday tasks, but also spend their time on registering and distributing their knowledge. A more promising solution would be to introduce a business support system that helps to complete everyday tasks and at the same automatically gathers and distributes the operational knowledge, without extra burden on the people engaged in the business. How should such a business support-/KM system look like, and on what conceptual model should it be built?
1
2. Introduction This paper deals with so-called practical knowledge, which we consider as information that can be used by a person to perform an appropriate action in a real-world situation. According to this view, information that has no connection to a context does not constitute practical knowledge. By a context, we understand a description of a real-world situation, or a class of real world situations. Practical knowledge can be divided into two categories experience based and generalized knowledge (see for, example [Henninger, 1997]): • Experience-based knowledge (EBK) can be expressed in the form of records on (memory of) actions undertaken in the past together with description of the contexts in which these actions were completed and the outcomes of these actions. The latter can, for example, be expressed in the terms of success/failure. EBK can be used in a current situation by analyzing outcomes of previous actions in similar contexts, when deciding on what to do next. • Generalized knowledge (GK) can be expressed in the form of laws and/or rules relevant in a given context. Laws establish limitations on what actions can be valid/successful in a given context; rules prescribe/ prohibit/ recommend actions for a given context. While EBK is expressed as facts, GK is expressed in an abstract form with explicit or implicit use of variables and/or quantifiers in the descriptions of contexts and actions. Both types of knowledge are important for the adequate behavior. For example, when available GK leaves too many options open, EBK can be used to choose one of them. Alternatively, past experience in similar contexts may need to be verified against the laws/rules that could have been changed. One more example, if the current situation is completely new, i.e., we can’t find similar contexts in our EBK, the selection of actions can be only based on the generalized knowledge. In this paper, we understand as a Knowledge Management System (KMS) a system that facilitate gathering, distribution and utilization of practical knowledge, experience-based as well as generalized. Today, KM is considered as a principle success factor and a major force behind business success, see for example [Davenport et al, 1998] and [Papavassiliou et al., 2003]. Effectiveness of practical KM is considered to be achievable through computerization and therefore there is a great interest in computerized KMSs. Although there exist some successful implementations of KMS, see, for example [Davenport et al., 1998], [Dixon, 2000], [Sharp, 2003], several reported implementations of KMS [KPMG, 2000], [Koenig et al., 2004] are less successful. One of the major factors of failure is lack of motivation to use such a system on behalf of the end-users, see, for example, [Henninger, 1999], [Malhotra, 2004]. This leads us to the question of what kind of functionality a computer based KMS should provide in order to motivate people to use it. We claim that the following 3 features are of particular importance for KMS usability: 1. Context provision. As was pointed out above, utilization of practical knowledge requires information on the context in which the knowledge is to be applied. In many situations, getting context information is far from a trivial task; it may, for example, involve lengthy communication with other people. Therefore, a system that provides full information about the context or helps to find it has more chances to be used than a system that just provide knowledge (be it experience based or generalized). 2. Automatic gathering of experience-based knowledge. Recording the experience-based knowledge is a tedious and tiresome job that requires not only records the actions undertaken, but also the full context of these actions and their outcomes in the short and long terms. No wonder that, normally, no such recording takes place and the experience-based knowledge remains only in the possession of the person who acquires it from his/her own practice. And even the latter is true only partially as it requires quite good memory. The exception of this rule is areas with a strong tradition of recording, often enforced by some laws or regulations. Representative examples of such areas are medical (patient journal), and legal profession. A system that can help in gathering experience-based knowledge without adding extra burden on the workers would have a better chance to be used than a system that just force people to record their actions. To achieve such functionality, the system should not only provide 2
information of the current context (see the previous feature), but also provide, at least some minimum, support for execution of actions. Providing action support ensures that information on actions undertaken will find its way into the system not because people are forced to do it, but because they would like to get help from the system to complete the actions. 3. An active generalized knowledge base. As far as GK is concern, it is not realistic to demand that a system should fully automatically extract it from experience-based knowledge. Manual intellectual job will always be required. It is more feasible to concentrate on the utilization part of the generalized knowledge by making it active [Abecker et.al. 2001]. For example, if a system could automatically supply the end-user with the part of GKB that fully covers the current situation (context), and nothing else, it would be greatly appreciated by the system users. In addition, if the knowledge is presented in an operational form, e.g., as a list of actions/options appropriate to the current situation, it will make utilization of knowledge easier than in the case it is presented as a list of general laws/rules. One logical consequence of the above deliberations is that a KMS should be built as an integral part of a system that both supports execution of actions and knowledge management. More often than not, the term “integration” is understood as an integration of separately built technical systems. This interpretation is of limited use for our purpose. We consider action support and knowledge management as two special views, or projections, of a unified system. To achieve acceptable results from the technical integration is much more complicated than building one “integrated” system from the very beginning. In this paper, we describe an approach to building an integrated action support/knowledge management system for one special domain that embraces routine daily operations of a typical organization, be it a private company, non-profit organization or public office. We refer to the practical knowledge needed for these operations as to operational knowledge (see also Section 1). It is well known that the daily operations are structured in business processes, independently of whether their participants are explicitly aware of it or not. Examples of such processes are processing an order, insurance claim, or bug in a software system. Any individual action in the domain of interest always takes place in a frame of some business process instance, which constitutes the context of knowledge application. Therefore, the operational knowledge, both experience-based, and generalized should be structured around business processes and their instances. As far as action support is concerned, a system in the chosen domain is always (more or less) aimed at Business Process Support, thus the integrated system we are about to discuss may be referred to as KMS/BPS. The goal of this paper is to present a conceptual/theoretical view on business processes that can be used as a basis for building a KMS/BPS and giving an overview of the results achieved so far on our way of exploiting this view. The latter includes system architecture, current installation, and short and long term plans. The rest of the paper is structured in the following way. In Section 3, we overview the state-oriented view on business processes that served as the basis for building the system. In Section 4, we describe the system architecture. In Section 5, we describe the pilot installation. In Section 6, we refer to related research. In Section 7, we summarize the result achieved and review research in progress.
3. State-oriented view on business processes 3.1 General notions According to a general definition of a business process, see, for example [Hammer et al., 1994], a business process is a partially ordered set of activities performed to reach a well-defined goal. A process engages a number of participants, which can be divided into two categories: “passive” and “active” participants. Passive participants are consumed, produced or changed through the execution of activities, for example, a document being written, an organization being reorganized, or a patient treated in the hospital. Active participants, or agents, are those participants that perform activities aimed at the passive participants. The roles of “passive” and “active” participant can both be filled by human beings, as well as artifacts. 3
When discussing business processes, it is important to differentiate the process type from the process instance. The notion of process type is used to talk about the process in general, like: sales process (in general), processing insurance claims, decision-making. The notion of process instance is used to pinpoint a particular process, like: processing a sale lead that concern a particular customer, processing insurance claim #1345678, passing an elderly care plan for 2002.
3.2 State-oriented view There are many different practical ways of modeling business processes, for example Petri-nets, IDEF0 and Role Activity Diagrams. Most of them are based on the notion of activity and activity ordering. For the sake of creating an integrated view on business process support/knowledge management, the state-oriented view suggested in [Khomyakov et al., 2000] and [Bider, 2002] represents a promising approach. The state-oriented view has its roots in the mathematical systems theory [Kalman et al., 1969] which deals with physical processes. One of the main notions of the mathematical system theory is the notion of state that, for continuous processes, is defined by a number of state variables accepting real values. A process type in such case is represented as set of trajectories in the state space defined via a set of differential equations of the form:
F(x, x& , w) = 0, where x& denotes the derivative of the vector of state variables x with respect to time, and w is a vector of environment variables. Such equations are binding the direction and speed of movement of the system in the state space to the position of the system in the space and the state of the environment. A state of a business process instance is defined by a “construct” that reflects the relevant part of the “business world” at a moment in time. The internal structure of the state construct depends on the business process type to which the current instance belongs. An example, of such structure for a business process related to a customer order is represented on Fig1 (left). The state structure includes: (a) attributes (variables), like To pay, Paid, Ordered, etc., and (b) references to various human and non-human participants of the process, like customer, product, etc.
Figure 1. Left - state of a business process; Right - operative plan that complement it Each business process has an objective or goal. The goal can be defined as a set of conditions that have to be fulfilled before a process instance can be considered as finished (end of the trajectory). A state that satisfies these conditions is called a final state of the process. The set of final states for the process in Fig. 1 can be defined as follows: (a) for each ordered item Ordered = Delivered; (b) To pay = Total + Freight + Tax; (c) Invoiced = To pay; (d) Paid = Invoiced. These conditions define a “surface” in the state space of this process. Each instance of a business process is driven forward towards the goal through activities that are executed either automatically or with a human assistance. An activity can be viewed as an action aimed at changing the process state in a special way. Execution of each activity results in a change in the process state, and thus a jump in the trajectory of the process instance. A change in the 4
process’s state can happen not only as a result of completing an activity, but also in many other, often non-anticipated, ways. For example, a customer may change, or cancel his/her order in the last moment (even after the goods have been delivered). A moment of time when the process’s state changes is called an event in the process’s lifetime. Each completed activity results in an event, but as it has been pointed out above, events can happen unpredictably as well. The sequence of all events of the given process can be numbered in the ascending order to compose an internal time axis of the process. A sequence of the process’s states taken after each event up to a certain moment of time forms the history of the process evolution. To link the internal time axis to the real or external time, event registration can be introduced. A registered event is a record that links the change in the state of a process to the reality outside the process. For example, it can record the date-time when the event happened and/or was registered, name the responsible for the event, register comments on the event at the moment of registration (or even later), etc. A list of all events that were registered within the frame of a given process up to a certain moment of time constitutes the chronicle of the process, i.e. its written history. Activities can be planned first and executed later. All activities planned, but not executed for a given process at a particular point of time constitute the process’s operative plan (to do list). The plan lists activities the execution of which diminishes the distance between the current state of the process instance and the nearest final state. The meaning of the term distance depends on the business process in question. Here, we use this term informally. For example, activities to plan for the process in Fig.1 can be defined in the following manner: • If for some item Ordered > Delivered, shipment should be performed, or • If To pay > Invoiced, an invoice should be sent, etc. The operative plan on Fig. 1 (Right) corresponds to the process instance state shown on the left. Conceptually, the notion of operative plan substitutes the idea of derivates in continuous processes, each activity on the plan list showing the “direction” of movement along some “axes” in the state space, and the speed of movement (e.g., through a deadline). A pair is called a generalized state. With regards to the generalized state, we can define the notion of a valid state in addition to the notion of final state. To be valid, the generalized state should include all planned activities required for moving the process to the next stipulated state. A business process type, i.e. a set of trajectories in the state space, can be defined as a subset of “valid” generalized states. Each trajectory in the state space that “runs” through the valid states constitutes a (valid) business process instance. Such definition “substitutes” the differential equations used to define continuous processes. A definition of a business process in the form of a set of valid states can be converted into an operational procedure called rules of planning. The rules specify what activities could/should be added to an invalid generalized state to make it valid. Using these rules, the process instance is driven forward in the following manner. First, an activity from the operative plan is executed and the state of the process is changed. Then, an operative plan is corrected to make the generalized state valid. Rules of planning can be roughly divided into three categories: • Obligations. Given current state and, possibly history, and other planned activities, certain activities should be present in the plan. • Prohibitions. Given current state and, possibly history, and other planned activities, certain activities should not be present in the plan. • Recommendations. Given current state and, possibly history, and other planned activities, certain activities are normally planned for the process instances of the type in question. While obligation and prohibitions can be enforced automatically by adding/deleting activities, recommendations give the human participants an option to follow or not to follow them based on their understanding of the situation. Besides what should be planned, rules of planning should also help to determine when things should be done and by whom, i.e. help in assignment of human resources.
5
3.3 Analysis from a knowledge management point of view According to Section 2, the following three issues should be clarified to show that the above model could really be used as a basis for building a KMS: • The representation of the action context • The representation of the experience-based knowledge • The representation of the generalized knowledge. In the above model, a minimum context that could/should be taken into consideration when executing or planning an action is the state of the business process instance in which frame the action should be undertaken. If this is not enough to make a decision or complete the action, historic information can be consulted, which includes both the process’s history and chronicle. The latter could show who produced the previous actions, and why, if it is written in the comments. The experience-based knowledge is represented by all the histories of all completed process instances. Having such histories, any action undertaken in the past can be connected to the context in which it has been completed, e.g., a state of the process at that point of time. In addition, the action can be connected to its short-term and long-term outcomes. The short-term outcome is the state of the process after completing the action. The long-term outcome is the result of the given process instance, e.g. its final state. The generalized knowledge can be represented both in the form of ”laws”, i.e. as a set of valid states, and in the form of rules, i.e., rules of planning.
4. The support system The heart of the integrated KMS/BPS we built based on the state-oriented view on business processes consists of: • A historical database that automatically stores information on all events and all past states of all processes, documents, and other business objects. • A principle of dynamic and distributed planning. Dynamic means planning when needed, distributed means planning to each other. Planning for each other constitute a communication channel between process participants along business process instances. Planning can be partly manual, partly automatic. • A navigational system that allows the end user to freely navigate through the space of interconnected processes in the present and past. The system, among other things, provides: • A virtual calendar that allows the users to plan tasks to each other, and gives immediate access to all information required for completing individual tasks. The latter includes information on the currents situation and all relevant events and documents in the past and future. • Automatic support of history recording that allows not only to see what happened in the past, but also how things looked like at that time. • Document management that facilitates getting access to any internal or external document without knowing its name or storage placement. The documents are found through association to their usage (e.g., purpose of creation). In addition, via support of history, all internal documents are automatically version controlled. The current version of the system is called ProBis and the system is built as a client/server solution where clients run under Microsoft Windows, and a server runs an SQL DBMS, Oracle, or MS SQL Server. The historical database is implemented as a set of stored procedures and triggers. The user interface is built with the help of the Prolifics application development tool from Prolifics, Inc. ProBis provides/intend to provide features discussed in the Section 2 in the following way: 1. Context provision. When a user needs to complete an action, planned or not, he/she automatically gets all the knowledge on the current state of the process in which frame the action is about to be executed, see Fig. 2. No extesive communication with the colleagues previously engaged in the process is required, as they do not have any additional information 6
than what is stored in the system. As was said in Section 3, the state of the process constitutes the immediate context of action. If this is not enough, the user can browse through the chronicle, see left box on Fig.2, and see what actions has been completed in the frame of the process, who completed them and when. If needed, he/she can also get a snapshot of the process’s state at any time in the past. The system also provides additional information that may be needed for the execution an actions, e.g. resource availability.
Fig. 2. Context provision in ProBis 2. Automatic gathering of experience-based knowledge. The full history of previously completed processes is automatically stored during the process lifetime, and it is easily available through a number of associations, like time-frame, document used, received or produced, people engaged in the process (own staff as well as external contacts). To stimulate workers using the system and thus avoid historic information bypassing it, the following action support is currently provided by the system: •
Easy planning. Just add a new task to a process, and it immediately appears in your virtual calendar as a reminder of what should be done, when and in connection to what.
•
Effective channels for internal communication. Instead of writing to your colleague a long message that explains the matter, and attaching a lot of documents to it, just drop a task, e.g. “review a document” into an “appropriate process” and assign it to your colleague. The rest of the information needed (including the full process history) is already attached to the process. The task will appear in your colleague’s virtual calendar. In addition, he/she will be notified that somebody else has changed his/her plans.
•
Easy reporting. To report a completed task, just move it from the left box on Fig. 2 to the right one. If needed, you can add a lengthy comment, or include an explanatory document, e.g. a voice message. No need to send any reporting messages, all your colleagues who are interested to know, including your chef, can see it for themselves.
•
Integration with external tools. In the current version, integration is provided for document processing. For viewing or editing a document, be it text, spread-sheet, voice message, an assigned external program can be called. The results of the editing are “caught” and stored in the historic database as the new “state” of the document.
3. An active generalized knowledge base. The current version of ProBis does not provide the means for automated planning; this part is under development. The earlier versions of the system (see [Bider, 1997]) had some automated planning capability, but it was hard coded in the 7
system. Current research is devoted to creating a formal language for expressing rules of planning. Having such a language, hard coding can be substituted by an interpreter.
5. Pilot Installation The current version of ProBis was developed for “Association of Tenants, Region West Sweden” (in Swedish: Hyresgästföreningen, Region Västra Sverige), abbreviated to HGF. HGF is a nonprofit interest organization that unites more than 60 000 tenants and has as its primary objective to guard the interests of its members. The regional office, where Probis is deployed and which is used as the main pilot site, has about 50 employees whose task is to provide service to the members and to the “field-level” organizations. The service is provided in a number of areas, such as giving legal and practical advice to HGF’s members, conducting rent negotiation with the properties owners on behalf of the members, lobbying, i.e. influencing decisions made by authorities on the local, national, or international levels. Most of business processes in the pilot organization are of administrative nature, such as negotiation, conflict management, lobbying, etc. We call such processes loosely structured to stress that for these processes it is difficult to pre-determine the order of activities. This term has connotation with the concept of ill-defined problems in AI, see, for example, [Simon, 1973], and with such terms as ad-hoc, emergent and dynamic workflows, see for example [Bernstein, 2000], [Jørgensen et al., 1999]. A first experience of introducing ProBis at the site was worse than expected. Based on the previous experience of setting a support system into one department of this organization, some delays were expected in the introduction process. However, the difficulties of introducing a system aimed at functioning throughout the whole organization showed to be much greater than in the case of system introduction in a single department. One of the major problems was that the system’s user-interface was poorly adapted to the “occasional” end-users. Based on results of the first try, the user-interface has been totally redesigned to satisfy the less skilled users (Fig. 2 is from the redesigned system). The redesigned system has been demonstrated to the staff of the pilot organization, who expressed their full satisfaction with the new “look-and-feel” of the system. The re-designed system will be fully deployed in the autumn of 2004.
6. Related Research Integration of KMS with BPS is discussed in [Papavassiliou et al., 2003], [Woitsch et al., 2002], [Abecker et al., 2001], [Reimer et al, 2000], [Van Kaathoven, 1999], [Davenport et al., 1996]. The main observation is that business processes are context-giving, structuring elements prevalent in most organizations making the integration of KMS with business process support systems natural. Due to the lack of space, below, we shortly review only two papers with the views similar to ours. [Papavassiliou et al., 2003] argues that a KMS should be a tool that supports both business processes and context sensitive information management. The system presented in [Papavassiliou et al., 2003] is used for business process modeling and is based on three components; a modeling tool for modeling processes and information structures, an archive in which the models are stored and a workflow engine. The workflow engine interacts with software agents observing running processes, interprets their information needs and performs an ontology-based search of the archive for relevant information that is presented to the modeler to use. Relevant information can be based on previous experiences of doing similar tasks, organizational documents, or laws and regulations. In this system a KMS is integrated with the BPS through the use of software agents watching business process enactments and using a structured archive for information store and retrieval. [Henninger, 1997] demonstrates a software design system that captures project-related information during the creation of individual software products. The information captured can be disseminated to subsequent projects to provide experience-based knowledge on various development issues encountered in the past. Cases represent project issues and contain information about how issues were resolved and resource consumption when resolving them. Cases are stored in a repository that can be searched and browsed to find issues with similar characteristics. The repository serves not only as means to disseminate design knowledge, but it also helps an 8
organization to learn what does and does not work in their development context. The system has three parts; a case-based repository storing project experiences and design artifacts, a repository for domain abstractions which is generalized knowledge gathered in part from the case-based repository, and domain-specific design environments which are the contexts in which application developer’s work. The system uses a classic case-based approach, which means that general principles (generalized knowledge schemas) are used as guides for decision makers (application developers), and cases describe situation specific problems that may arise in a certain context. Four requirements for the successful use of the system is recognized in [Henninger, 1999]: (1) use of the repository must become an integral part of the design process (2) use of the repository must be obligatory and not discretionary, (3) use of the repository must provide easily perceived benefits for the development effort at hand, and (4) the repository must contain up-to-date information of relevance to development efforts. Our basic ideas on the needs of integrating KM and BPS, and providing a combination of experience-based and generalized knowledge are quite similar to the works referred above. Our research differs in two respects. Firstly, we apply these ideas to a specific domain - loosely structured business processes. Secondly, we are trying to solve integration not through combining systems, but through finding a theoretical/conceptual view that covers both business process support and knowledge management.
7. Conclusions and Future Directions Summarizing the material discussed in the paper, we state that to achieve usability, a computerized system for an operational KM should be integrated with BPS and structured around three main functionalities: 1. Provision of context in a recognizable for the user form. A context is all information a user needs to act in a particular situation. This includes current state, historical information and future plans. Historical information, e.g. the events that lead to a current state, provides an explanation why it came about which might be necessary to know in complicated cases. Information on the future plans may be needed for not doing a job already planned for somebody else. 2. Automatically gathered structured experience base. This experience base is continuously fed with facts from the use of the system. The information in the experience base is structured according to the context in which it is gathered. This means that a user working in a particular context always can search the experience base to get facts about how work in similar contexts was conducted. 3. Active generalized knowledge base. The generalized knowledge base contains the business rules that constrains and regulates the operations of the organization. The rules concern most aspects of the running of the business, from the laws of the land to fairly detailed rules about measures to take in a specific context. We have chosen the state-oriented view on business processes as a basis for creating an integrated KMS/BPS for business processes of administrative nature (loosely structured business processes). We created a system that fully implemented the first two functionalities. The system was tested in our own operational practice, and it is currently installed at a pilot site. We made a substantial redesign of the system’s user interface to satisfy the needs of the users at the pilot site, who are about to start full exploitation of the system. Our research in progress goes in two directions. First direction is to provide the third functionality. Second direction is to investigate the impact of the introduction of such an integrated system on an organization. More specifically, to find out what are the consequences for productivity, efficiency, transparency, relations between managers and subordinates, man and woman, etc. This investigation is based both on qualitative, mainly interviews with the users of ProBis, and quantitative information, based on information gathered in ProBis’ historical database.
9
Acknowledgement. The work described in the paper is currently supported by the Swedish Agency for Innovation Systems (Vinnova).
References Abecker A., Mentzas G. (2001) Active knowledge delivery in semi-structured administrative processes, In: Wimmer M. (eds) (2001) Knowledge Management in Electronic Government, KMGov-2001, Schriftenreihe Informatik, Siena, Italy, pp 47-57. Bernstein A, (2000) How can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specificity Frontier, In: CSCW 2000, Philadelphia, USA, ACM Bider I. (1997) Developing Tool Support for Process Oriented Management, Data Base Management, 26-01-30, Auerbach. Bider I. (2002) State-Oriented Business Process Modelling: Principles, Theory and Practice, PhD Thesis, Royal Institute of Technology, Stockholm, Sweden. Davenport T., Jarvenpaa S.L., Beers M.C. (1996) Improving knowledge work processes, Sloan Management Review 37, No 4, Summer, pp 53-65. Davenport T., Prusak L. (1998) Working knowledge, Harvard Business School Press, Boston MA. Dixon, N. (2000) Common Knowledge, Harward Business Scholl Press, Boston MA. Hammer, M., and Champy, J. (1994) Reengineering the Corporation - A Manifesto for Business Revolution, Nicholas Brealey Publishing, London Henninger, S. (1997) Case-Based Knowledge Management Tools for Software Development, Journal of Automated Software Engineering, Vol. 4, No. 1. Henninger, S. (1999) Using Software Process to Support Learning Software Organizations, Workshop on Learning Software Organizations Proceedings, Kaiserslauten, Germany. Jørgensen H.D., and Carlsen S. (1999). Emergent Workflow, Integrated Planning and Performance of Process Instances, In: Workflow Management ’99, Münster, Germany Kalman R.E., Falb P.L., and Arbib, M.A. (1969) Topics in Mathematical System Theory, McGraw-Hill. Khomyakov M., Bider, I. (2000) Achieving Workflow Flexibility through Taming the Chaos, In: OOIS 2000 - 6th international conference on object oriented information systems, Springer, pp 85-92. M. E. D. Koenig & T. K. Srikantaiah (Eds.) (2004) Knowledge Management Lessons Learned: What Works and What Doesn't, Information Today Inc. American Society for Information Science and Technology Monograph Series. KPMG (2000): Knowledge Management Research Report, KPMG Consulting, Available (2004-09-12) at: http://www.kpmg.nl/Docs/Knowledge_Advisory_Services/KPMG%20KM%20Research%20Report%202000.pdf Malhotra Y. (2004) Why Knowledge Management Systems Fail? Enablers and Constraints of KnowledgeManagement in Human Enterprises. In: M. E. D. Koenig & T. K. Srikantaiah (Eds.) (2004) Knowledge Management Lessons Learned: What Works and What Doesn't, Information Today Inc. (American Society for Information Science and Technology Monograph Series), pp 87-112. Papavassiliou, G., Ntioudis S., Abecker A, Mentzas, G. A. (2003) Supporting Knowledge-Intensive Work in Public Administration Processes, Knowledge and Process Management, Vol. 10, No 3, pp 164-174. Sharp D. (2003) Knowledge Management Today: Challenges and Opportunities, Information System Management, Spring 2003. Simon, H. A. (1973) The structure of ill-structured problems, Artificial Intelligence 4, pp.181-201. Reimer U., Margelisch A., Staudt M. (2000) EULE:a knowledge-based system to support business processes, Knowledge-based Systems Journal 13(3), pp 251-260. Van Kaathoven R., Jesufeld M., Staudt M., Reimer U. (1999) Organisational memory supported workflow management, In: Scheer A-W (eds) (1999) Electronic Business Engineering, Physica Verlag, pp 543-563. Woitsch R., Karagiannis D. (2002) Process-Oriented Knowledge Management Systems Based on KM-Services: The PROMOTE Approach, In: Proceeding of the fourth International Conference on Practical Aspects of Knowledge Magagement (PAKM02), 2-3 Dec 2002, Vienna, Austria
10
