A Method for Integrating Knowledge Management into Business Processes

Size: px
Start display at page:

Download "A Method for Integrating Knowledge Management into Business Processes"

Transcription

1 A Method for Integrating Management into Business Processes Igor Hawryszkiewycz Win Maung Department of Information Systems University of Technology Sydney Abstract management concerns two important activities. One is to define ways to capture and convert knowledge into a form useful within business processes. This includes the definition of knowledge objects and knowledge creation activities. The second is how to integrate the knowledge creation activities into the business process. The paper concentrates on such integration and ways to model it. The paper defines a knowledge creation process for knowledge management. It then describes ways of integrating these activities into collaborative processes. It also suggests that software agents be used to facilitate such integration. 1. INTRODUCTION As shown in Figure 1, knowledge management requires two kinds of process knowledge. One is knowledge about processes to be followed to collect, interpret and consolidate knowledge. We call this process the evolving knowledge process (EKP) in this paper. The EKP process includes activities that create new knowledge within the business. The second is how to integrate the EKP into business processes. The paper calls this the knowledge management process (KMP). Successful integration requires that selected knowledge management activities be initiated at appropriate points of the business process. This paper describes a way to integrate these two kinds of processes. EKP activities Business process Typical Activities Filtering Consolidation Transition Assign KM responsibilities for EKP activities to roles Figure 1 Integration of processes The paper first defines the knowledge process, here called the EKP process. This defines the activities needed to capture and present knowledge in ways useful to business processes. EKP is a process similar to Chain Model (Holsapple, 2003) but based on Nonaka theory of knowledge creation (Nonaka, 1995). The paper then describes how to integrate this knowledge management process into business processes. Such integration emphasizes collaboration and the paper develops a metamodel that describes collaboration and can provide ways to include knowledge processing activities. Organizations can use alternate strategies for such integration. They can centralize the knowledge process (KP) activities, distribute them, or have a mix of both. EKP activities, however, are seen by many as detracting from the main business activities and as such are often ignored or left till some free time becomes available. The paper then proposes software agents to minimize the effort needed to integrate the EKP activities into the business process. The agents are proposed primarily to facilitate such integration into business processes rather than actual processing of knowledge. They expedite the KM process by tracking knowledge objects and directing them to the best individuals to process them. The agents will contain the necessary knowledge to identify points in the process where knowledge should be processed and provide the tools to carry out the necessary knowledge management activities. 2. A KNOWLEDGE CREATION PROCESS (EKP PROCESS) The ideas of Nonaka (1995) and Polanyi (1962) provide the basis for the EKP process. We have found their ideas as abstract and have developed the EKP process as a realization of the ideas in a concrete form suitable for inclusion in computer supported business processes. The EKP model is elaborated in detailed steps that can 330

2 Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 be integrated as activities or work items in a business process. The integration into business processes using a modified rich picture descriptions. Business Process Business Process Model Adapted Method integrating Model Too hard to integrate integrating Practical Concrete Model (EKP) Contributions: To develop knowledge model Concrete structure & detailed steps Develop methods to apply in business processes Nonaka & Polanyi Figure 1: Research goal and contribution The Evolving Process (EKP) model has been described earlier (Maung, 2003a) but uses Nonaka s idea as the underlying structure. It is similar to (Holsapple, 2003) and (Soo, 1999) but differs in the way that knowledge management activities are integrated into business processes. The Evolving Process (EKP) model shown in Figure 2 is a detailed elaboration of Nonaka s knowledge creation process in a concrete form. It describes how to capture tacit and explicit knowledge in knowledge creation process and integrate into business process using adapted method, Maung (2003a). In this model, we define a sequence of activities and resources in the knowledge creation process. The challenge here is to understand how to use tacit knowledge in its business context to interpret and explicit knowledge and to structure it into forms suitable for use in business processes. Filtered Filtering Interpretation Captured Utilisable Memorised Interpreted Accumulation Domain Analysis Consolidation Organisational Memory Consolidated Represent resources Refinement Represent activities Figure 2: Evolving Process (EKP) Model 331

3 A Method for Integrating Management into Business Processes The EKP process model is defined as a sequence of activities that create and capture of what are called knowledge objects in a business context. As shown in Figure 2, the process consists of six activities: knowledge accumulation, domain knowledge analysis, filtering knowledge, knowledge interpretation, knowledge consolidation and knowledge refinement. resources are captured knowledge, filtered knowledge object, memorised knowledge object, interpreted knowledge object, consolidated knowledge object and organisational memory. 2.1 EKP Activities EKP Activities Accumulation Domain Analysis Filtering Interpretation Description Collecting, gathering and recording useful information, data and knowledge and retains them as captured knowledge objects. These are processed in subsequent stages. Identifying, classifying, categorising and organising captured knowledge objects, and recording them as utilisable knowledge objects. Determining whether utilisable knowledge objects are relevant to a particular goal, and retaining it if it is relevant. If it is not currently needed then it is memorized until it is needed. (Godbout, 1996). Filtering thus also distinguishes between current and future needs. Determines the value provided by the filtered knowledge objects. (It is a dynamic human process of justifying personal belief toward the truth.) (Nonaka, 1995). Consolidation Refinement Table 1: EKP activities and descriptions Classifying interpretative knowledge objects, which events are relating to the categories, and main interested objects. Modifying, updating knowledge into a form suitable for use in business activities. 2.2 EKP Resources The EKP resources are primarily a form of explicit knowledge that has been constructed by using captured information and supplementing it with user comments as to their relevance in the current business context. To some extent this can be seen as the capture of that part of tacit knowledge that can be explicitly recorded. EKP Resources Description Captured Utilisable Filtered Memorised Interpreted Consolidated Organizational Memory Table 2: EKP resources and descriptions which is acquired with the goal of applying it is a particular activity in the workspace. which is classified by its application in an organizational function. which that may be immediately useful to a person or organization to achieve a goal., which is memorized for later use. which include possible ways that to be applied in making decision in current ongoing organization. which is verified, validated and interpreted for intended purpose. It includes identified in categories and interested objects. which is stored for short-term or long-term memory. Our next step is to integrate the activities into the business process. We use the metamodel concepts to describe the business process and realize the integration by including EKP activities represented as these concepts. 332

4 Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference MODELING COLLABORATIVE BUSINESS PROCESSES The metamodel is described in Figure 3 and has evolved through a variety of applications that include business networking (Hawryszkiewycz, 1996), strategic planning (Hawryszkiewycz, 1997) and is an extension of an earlier description (Hawryszkiewycz, 2002). A further foundation for the conceptual model described here is organization computational theory (Carley and Gasser, 1999) as a basis for managing knowledge about collaborative relationships. Thus rather than identifying data objects and processes, we identify organizational entities and their agencies. The model shown in Figure 3 combines organizational structures such as activities and work-items, work processes including events and workflows, and social structures that enable groups to be formed and participants to be included in such groups. It provides ways to combine work-items into activities with members of groups assigned responsibilities through roles for those work-items. Here the EKM activities can be modeled as work-items can be grouped in different activities for different users. It supports social interactions, through group formations, discussions or notifications, as well as more structured workflows by associating events with artifacts. assesssituation attached-to workflow Work processes Organizational made-of structures event is-in provides event-rule activity view -type has case-of completion initiationevent assigned-to -event notifies work role carries-out initiates item composed-of occupies actions is-in group participant case-of take includes can-access notifies is-in uses, creates case-of uses uses case-of artifact document Meeting Discussion Idea generation Resolve issue Edit document tool Social structures soloaction interaction Figure 3: Collaborative Metamodel The main concepts are: Artifact - data objects such as documents, calendars. It can also be a record of discussions or other personal interactions. View a collection of artifacts. These can be documents, calendars, or multi-media records. They can also be other views. Activity - produces a well defined artifact as its output (e.g. Produce a planning document), and can include many work-items to do so. Provides views, which are needed to carry-out the work-items. Role - defines responsibilities in system in terms of work-items that it can carry out and the views that it can access Participant a specific person that is-in a group and can be assigned to a role Group a collection of participants that can be assigned to a role. Work-item - a set of actions and interactions needed to produce intermediate outcomes that eventually produce an activity output (e.g. Review part of a planning document - which may include a number of actions, assess a situation). A work-item is composed of a number of actions and provides tools to carry out the actions. They can also represent the knowledge management activities Action - a specific unit of work carried out by a role (e.g. change an artifact, send an artifact). Can notify selected roles when completed. Can be a: Soloaction carried out by one participant, or Interaction - the basic exchanges between people when they collaborate in the activities. Event type is in an activity and can either be an initiation-event that notifies a role in the activity to carry out work-item, or is a completion-event initiated by a role following completion of a workitem, Event-rule defines the next initiation-event or events to be activated following the completion-event Workflow - describes a sequence of event rules. Can be attached to an artifact. 333

5 A Method for Integrating Management into Business Processes The model also includes a variety of commands that can be used up to setup and change systems specified in terms of the model. These include ways to create new groups, activities or work-items and set up the necessary views, workflows and notifications. A typical set of steps followed to create a model are: 1. Define the high level activities in the system and the work-items in each activity. 2. Define groups or teams and add participants to the groups. 3. Add artefacts needed by the work-items and create views for the work-items to identify the artefacts needed by the work-item. 4. Define roles and assign responsibilities for work-items to roles and then assign participants to the roles. 5. Expand work-items in terms of their actions and identify views for these to use or create artefacts. 6. Identify any predefined events and consequent rules and specify the initiation-events; to be activated following a completion-event. Workflows are made of that specify sequences of event rules. 3.1 Notation used in describing systems using the collaborative metamodel The paper now describes how to use these semantics to model collaborative applications and implement the models. Integration into business processes requires ways to show how EKP knowledge activities are placed into activities and then allocating the action to a person responsible for the action. Figure 4 shows the notation used to describe models in terms of the proposed semantics. The notation includes symbols correspond to those in other methodologies such as Prometheus as the goal is to extend to agent systems. Others are specific to the model. Thus we use a loose cloud notation for activities as we see activities not being fixed but evolving over time through creation of new work-items or roles as needed. The loose cloudy shape portrays the fact that new activities can be easily formed by grouping existing work-items. The event structure is also different to make a distinction between completion and initiation events and also to distinguish from agent events that are part of agent architectures. Activity view Artifact Participant Role Group Structure diagram event event-rule event Work-item Action Notification Contains Agent protocol percept Agent Extension to agents Figure 4: Notation 4. SUPPLY CHAIN MANAGEMENT (FINISHED PRODUCT) Figure 5 illustrates a model of supply chain management using the concepts illustrated in Figure 3. It is based on descriptions found in (Simchi-Levi, 2000). The objective of supply chain management is to minimize costs by reducing inventories while ensuring on-time delivery of customer orders. Every activity in supply chain management can impact on cost and plays a role in making the product conform to customer requirements while ensuring a smooth path from suppliers through warehouses and distribution centre to retailers. 334

6 Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 Figure 5: Supply chain management top level diagram The activities in Figure 5 include: buy goods, where the customer makes an order request. order processing, where the order clerk uses order requests to make arrangements with suppliers. The order manager provides procedure and a set of contracts and guidelines on preferred suppliers to the order clerks, who issue orders in response to customer requests, purchasing, where the purchasing officer negotiates with the suppliers to discuss goods and prices distribution, where warehouse facilities (such as storage cost, storage time, location, stock in store and distance) are provided the inventory controller to control stock levels and warehouse locations, and the delivery clerk uses facilities to receive goods and dispatches goods with receipts to customer. 4.1 Integrating EKP Activities into the Business Process The next step is to add the EKP work-items to the activities shown in Figure 5. The way this is done depends on the chosen knowledge management strategy. Figure 6 illustrates the alternative where EKP activities are distributed through the different business activities. Each EKP activity becomes a work-item. Figure 6 shows the EKP activities as shaded work-items. The model also defines specific roles responsible for the work-items. In Figure 6, we associate knowledge resources with the actual data object, then implementing a distributed knowledge policy. An alternate would be to centralize the EKP activities. In that case there will need to be a separated high level activities of knowledge management with information sent to it from other activities for knowledge processing. We describe how EKP activities in Order process allocate the responsible person for the action in Figure 7. For example, when the Order Manager makes arrangement (Shaded work-item; Domain Analysis) with Suppliers, she produces a set of contracts and also adds to guidelines on preferred suppliers. These guidelines are the filtered knowledge objects. In purchasing activity and distribution activity has its own agent to coordinate with other EKP activities and other work-items. 335

7 A Method for Integrating Management into Business Processes Customer Buy goods Make orders (Filtering knowledge) Receive goods & receipt (Consolidated knowledge object) Order Request EKP knowledge resources associated with order request Inventory Controller Delivery Clerk Distribution Stock level EKP knowledge resources associated with stock Warehouse Order Clerk Order Manager Select supplier to meet orders (Filtering knowledge) Making supplier Arrangement (Domain knowledge analysis) Create orders ( consolidation) Order process Guideline on preferred suppliers (Filtered knowledge object) Contract EKP knowledge resources associated contract Controlling Stock (Domain knowledge analysis) Receive goods (Consolidated knowledge object) Dispatch goods & Receipts (Consolidated knowledge object) EKP knowledge resources associated with warehouse Transport method Orders EKP knowledge resources associated with ordes Approved orders EKP knowledge resources associated with approved orders Goods & Receipts ELP knowledge resources associated with transportation Supplier (s) Purchasing Purchase goods (Domain knowledge analysis) Purchased goods EKP knowledge resources associated with purchased goods EKP knowledge resources associated with goods & receipts Purchasing officer Negotiate with Supplier (Filtering knowledge) Price lists Legends: EKP knowledge resources associated with supplier lists EKP knowledge resources associated with price lists Artifact EKP activity Supplier Lists Associated with (knowledge resources) Figure 6 Integrating EKP activities into the business process 5. IMPLEMENTATION OF THE MODEL We are using a system known as LiveNet which has been developed at the Cooperative Systems Laboratory, University of Technology, Sydney (UTS) to realize the models. Each of the activities in the model becomes a workspace in the implementation. User can create different folders in the workspace and each folder contains the elements that contain the various knowledge object of the EKP process. They can also create as work-items and sub-workspaces. An authorized user can select documents, backgrounds and get information about the various roles and participants in the workspace. As an example Figure 7 is a realization of the distribution activity in Figure 5. It includes all the artifacts which are modeled as part of the activity. 336

8 Decision Support in an Uncertain and Complex World: The IFIP TC8/WG8.3 International Conference 2004 Figure 7 LiveNet interface for Supply Chain Management 5.1 Extending to Agent Support The kind of workspace shown in Figure 7 requires participants to be aware of EKP activities, which they must carry out and to initiate these activities themselves. Participants are often busy and can sometimes overlook and not carry out the EKP activities. Furthermore, often experts with needed tacit knowledge in the EKP activities are often not known or are not easily available. We propose to facilitate this process by using software agent to determine outstanding EKP activities and notify appropriate roles to carry them out. The agent will provide the context within the workspace of what is needed from the activity and an easy way to collect it. The agent architecture for this purpose has been described earlier (Hawryszkiewycz, Lin, 2003). Software agents correspond to the metamodel concepts and are built using the Mueller s (1996) layered architecture chosen from a number of available architectures (Wooldridge, 1999). Each activity, artifact, role, and workitem has its agent. These agents are customized to EKP activities. The customization identifies the required characteristics of each EKP activity. Plans are then defined to achieve subgoals that achieve these requirements. For example, the subgoals of the Acquisition activity include identification of knowledge needs, identification of knowledge sources and beliefs in the best way to acquire this knowledge. The plans for each subgoal identify the actions to achieve the subgoals. These actions can include both retrieving information from recorded sources or contacting individuals for comment. A change to a knowledge work item will be detected by the agent, which will then place it in an activity with related knowledge objects and assign action on it to the responsible role. 6. SUMMARY The paper identified two processes needed to integrate knowledge processing into organizations. One is the process needed to capture and process knowledge. The paper described Evolving Process (EKP) model, which is based on Nonaka s knowledge creation theory, for this purpose. The other is the knowledge management process that integrates EKP activities into the business processes. The paper described a way to model such integration and implement it as workspaces supported by software agents. REFERENCES Carley, K.M., and Gasser, L. (1999): Computational Organizational Theory in Chapter 7 "Computational Organization Theory" by KM Carley & L Gasser in "Multiagent Systems" Gerhard Weiss (Ed) MIT Press Godbout.M (1999) Filtering, Changing Information into Assets, Journal of Systematic Management, January, Hawryszkiewycz, I.T. (2002): Designing Collaborative Business Systems in IFIP 17 th World Computer Congress, TC8 Stream on Information Systems: The e-business Challenge, ed. Roland Traunmiller, Montreal, August 2002, Kluwer Academic Publishers, Boston, pp Hawryszkiewycz, I.T. (1996): Support Services For Business Networking, in Proceedings IFIP96, Canberra, eds. E. Altman and N. Terashima, Chapman and Hall, London, ISBN Hawryszkiewycz, I.T. (1997): A Framework for Strategic Planning for Communications Support Proceedings of The inaugural Conference of Informatics in Multinational Enterprises, Washington, October, 1997, pp Hawryszkiewycz, I.T. and Lin, A.(2003): Process Support for Emergent Processes Proceedings of the Second IASTED International Conference on Information and Management, Scottsdale, Arizona, November, 2003, pp Holsapple. C and Jones.K (2003) Toward and Elaboration of the Chain Model, Ninth Americas Conference on Information Systems, Tempa, Florida August 2003, USA. LiveNet at University of Technology Sydney, Australia:( Maung, W (2003a) Capturing tacit and Explicit in evolving Process, The Management Aston Conference 2003, KMAC 2003, The OR Society, Birmingham, UK, July 2003, pp Maung, W (2003b) Filtering in Software Design IS OneWorld Conference 2003, Las Vegas USA April 23-25,

9 A Method for Integrating Management into Business Processes Müller J. P. (1996). The design of Intelligent Agents. Springer Verlag Pp Nonaka.I (1995) Creation Company, Oxford university press. Polyani, M (1962) Personal, Towards A Post Critical Philosophy, New York, Harper. Soo, C.W, et al (1999) The Process of Creation in Organization, Working Paper Series, AGSM, UNSW, Sydney, Australia. Spring 1999, Simchi-Levi, Kaminsky, P (2000) Designing and Managing the Supply Chain McGraw-Hill, Boston, USA. Wooldridge, M.(1999): Intelligent Agents in Chapter 1 "Computational Organization Theory" by KM Carley & L Gasser in "Multiagent Systems" Gerhard Weiss (Ed) MIT Press ACKNOWLEDGEMENTS The work described in this paper has been funded in Faculty of Information Technology Doctoral Research Scholarship from the University of Technology Sydney, Australia. COPYRIGHT Igor Hawryszkiewycz & Win Maung The authors grant a non-exclusive licence to publish this document in full in the DSS2004 Conference Proceedings. This document may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. The authors assign to educational institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. Any other usage is prohibited without the express permission of the authors. 338