Intelligent Agent Supported Business Process ... - Semantic Scholar

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

Intelligent Agent Supported Business Process Management* Minhong Wang and Huaiqing Wang Department of Information Systems, City University of Hong Kong, Hong Kong {iswmh, iswang}@cityu.edu.hk Abstract The complex business environment requires managing business processes with the ability to adapt to changes and to collaborate in activities. Conventional workflow approaches based on predefined logical procedure offer little support for the dynamic business environment. A cognitive agent-based approach is proposed to manage business activities based on situational awareness and real-time decisions on activities. Business activities are delegated to a number of cognitive and collaborative problem-solving agents. Each software agent perceives its environment by capturing events and monitoring the state of tasks and resources. Based on the continuous perception of environment, business rules concerning process routing, operational constraint, exception handling and business strategy are used by such software agents to perform appropriate actions. The mechanism of this approach is investigated, and a case application of exception management in securities trading is developed to demonstrate the validity and benefits of this approach.

1. Introduction In recent years businesses around the world have been facing the challenges of a rapidly changing environment due to the development of business market and technology. As a result, organizations are paying more attentions to supporting business process management with the ability to adapt to the dynamic environment. Management of business processes in an organizational setting is commonly referred to the development of business applications that directly follow the execution logic of the underlying business processes. However, traditional workflow approaches model and manage business processes based on a predefined logical procedure of activities and from a centralized perspective. That is, a complete list of all the activities and all the paths are provided, the criteria for following a particular

*

path are specified, and the ordering constraints on the actions are given. Such rigid and exact specification works well for simple business processes, but inadequate for complex and dynamic business activities due to the lack of flexibility and adaptability [2, 7, 8, 12]. The challenge of the changing business environment requires managing complex processes in non-procedure paradigms. Non-procedure paradigms do not depend on systems giving exact details to solve problems, but let systems determine how to accomplish tasks [5]. An exact execution order of activities may not be practical in a changing environment. The question of which task to execute, and when to execute, is more dependent on the current environment and underlying business policies, other than the static process schema. Furthermore, business climate is changing from centralized and closed to distributed and open mainly by virtue of the proliferation of networks. Therefore, an agent-based approach is proposed in this paper to manage complex business activities in today’s large-scale and distributed business environment. In this approach, business activities are delegated to a number of autonomous agents. These agents may be human beings as well as machines or software applications. Each of them has awareness of situation and can make real-time decision on activities. The agent can perceive its environment by capturing events that occurred and monitoring states of tasks and resources, and then take actions properly. Business knowledge concerning process routing, operational constraint, exception handling, and business strategy are elaborated for such agents to reason appropriate actions in current situations. Compared with traditional workflow approaches focusing on specifying the execution order of activities beforehand, this approach attempts to declare rules for autonomous agents to manage their activities via perceiving and interacting with the environment. In addition to real-time reaction to changes, the agent-based approach supports proactive activities, which refer to the exhibition of goal-oriented behaviours by taking

This research is supported by a UGC CERG research grant (No.CityU 1234/3E) from the Hong Kong SAR Government.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

1


initiatives. By using agents, the process is not only controlled by response to certain events, but also supported by real time decision on the whole situation via continuous perception of the environment and knowledge of decision making. Compared with existing work on agent applications in process management, this research contributes to investigate how agents manage their processes with autonomous, reactive and collaborative features in complex business environment. The rest of the paper is organized as the follows. Related work including workflow technology and agent application in business process management is reviewed in Section 2. In Section 3, a cognitive agent supported process management framework is proposed. The mechanism of cognitive agent and its knowledge engineering for process management is elaborated as well. For illustration and evaluation of the proposed approach, a case application of exception management in securities trading is presented for demonstrate in Section 4, with the comparison with other approaches. Finally, some conclusions are summarized in Section 5, and future work is discussed as well.

2. Related work As a promising approach to business process management, WFMS (Workflow Management System) is a kind of information system that defines, manages and executes “workflows” through the execution of software whose order of execution is driven by a computer representation of the workflow logic [26]. WFMS has become a fundamental building block that infiltrates organization [1]. One of the fundamental assumptions in most WFMSs is that workflow schema (i.e., control flow) are predefined. A significant weakness of predefined workflow schemas is their lack of flexible mechanisms to adequately cope with ever changing and distributed environments, and a number of efforts have been make towards such problems. With respect to dynamic and flexible workflow management, some related research is worth mentioning. In [11], several technical papers on adaptive workflow systems are collected. Among them, a number of techniques are suggested for supporting exception handling in workflow systems to dynamically adapt to the changing environment, e.g., knowledge-based approach, run-time dynamism, configurable execution, reflexivity, evolving models from workflow instances, etc. [10, 12]. They emphasize on the improvement of conventional workflow models to deal with dynamic workflow adaptation. However, most research has focused on the handling of expected exceptions whose character can be anticipated at build-time [8, 11]. Moreover, while

providing mechanisms for the seamless integration of exception handling into workflow descriptions, such kind of approach lacks the consideration of practical aspects that become important in workflow systems such as the participation of autonomous, heterogeneous legacy systems, and the strong impact of human intervention [21]. An event-based model for workflows is employed in some research [3]. For example, the ECA (event conditions actions) rules are used in the WIDE project to support exceptions and asynchronous behaviour during workflow execution through enhanced database technology and extended transaction management [6]. ECA rules were advocated by database practitioners to make data repositories react to internal or external events and trigger a chain of activities. In [13], roles and data objects are added to the ECA framework, and a model for dynamic routing and operational control in workflow management systems is developed using workflow control tables, sequence constraints, and event-based rules. Such approaches use predefined workflow schema as well as ECA rules in a static bind, and ECA rules are used as a supplement of workflow schema for adapting to business changes [31]. They focus on the evolution of dynamic business processes by runtime reactions to certain events and modifications on predefined workflow schema. The handling of unexpected exception is not considered in this approach. The application of agents to business process management has been studied in a flurry of research. Agent technology provides an extension and alternative to process management with flexible, distributed, and intelligent features [4, 17, 20, 22, 29]. In existing applications, an agent-based workflow system usually consists of multiple agents, each responsible for specific work items. The management of the whole process is performed by one routing agent through its mediating with other agents. In other cases, the whole process is broken into pieces and embedded into each agent. However, the approaches involved in such applications are somewhat special and ah-hoc. More efforts are needed to investigate the mechanisms how to employ multi-agent technology into business process management, especially focusing on solving the problem through the essences of agents.

3. Agent-supported process management 3.1. Multi-agent framework The term agent is used to denote an encapsulated software-based computer system that enjoys the properties of autonomy, social ability, reactivity, and proactivity [27, 28]. An agent is situated in some

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

2


environment; it has a set of goals, certain capabilities to perform actions, and some knowledge (or beliefs) about its environment. Agent-based approach is to assign business applications’ main activities to autonomous agents. Such agents are flexible problem solvers that have specific goals to achieve and interact with one another to manage their interdependencies. By modularizing a complex problem in terms of multiple autonomous components that can act and interact in flexible ways, agent-oriented techniques are well appropriate for complex, dynamic, and distributed software systems [8]. Considering the large-scale and distributed settings in today’s business environment, business activities can be delegated to a number of autonomous problem-solving

agents, each of which plays a specific role in business activities. For example, in an order management system, several kinds of agents, such as customer agent, validation agent, payment agent, etc., can be specified for the processing of orders. As outlined in Figure 1, each agent in a workflow system possesses certain resources, and is equipped with specific business logic as its knowledge. These agents can perceive changes in the internal and external environment, and make decisions on tasks based on their business logic. As viewed from the whole environment, each agent works autonomously to achieve its goal and interact with each other for collaboration. The mechanisms how agents control their processes is investigated in Section 3.2.

Agent-2 Network

Agent-n

perceive

possess

Agent-1

possess

Environment

perform

Resource

Business logic

use change decide

Task

decide

type of

Interaction

Figure 1. A framework of agent-based complex process management

3.2. Mechanism of cognitive agent In a dynamic and complex business environment, process management is more like a real time dynamic decision-making task. It is a type of task that requires a series of interdependent decisions in a continuously changing environment [15]. This kind of task has four key characteristics: (1) the task requires a series of decisions; (2) the decisions are interdependent; (3) the environment changes autonomously and as a result of decisions; and (4) decisions are made in real time [15]. The agent-based approach proposed in this paper is characterized by the ability to continuously perceive the business process environment and make real-time decisions on tasks based on underlying business logic. In addition to real-time reaction to the process environment, the proposed approach also supports proactive activities, which refer to the exhibition of goal-oriented behaviours by taking

initiatives. Compared with ECA rules used for reaction to certain events, the business logic in our approach works as knowledge for task decision in current workflow environment, which can used for handling unexpected exceptions whose character cannot be anticipated at builttime. As described in Figure 2 (left part), the agent orchestrates business activities dynamically at runtime and continues the evaluation of workflow throughout execution, during which business changes occur and business rules are dynamically bound to the workflow. The evolution of business processes is driven by changes from environment and runtime decision of tasks in current situation. The changes from environment may activate tasks, and the activated tasks may produce new changes into the environment and subsequently start the next round of decision making of tasks. Based on the foresaid mechanism of cognitive agents in process management,

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

3


the agent model is designed in Figure 2 (right part). The details of this model are elaborated through an example in

Section 4.2.2.

message

output

Communication facility

(1) (13)

(12) (18)

Environment_state Interpreter

update

Change

repeat

create

Business rule

decide

fact

Resource

(2) (8) (14)

Task

Taks Taks Task

state (7) (22)

Environment state

reason

Business rule

Rule engine

fact

task schedule

Activator

(4) (10) (16) (20)

command (5) (11) (17) (21)

(3) (9) (15) (19)

message (6)

Agent

Figure 2. Mechanism of cognitive agent

3.3. Knowledge engineering of agent Knowledge engineering has evolved from the late 1970s onwards, from the art of building expert systems, knowledge-based systems, and knowledge intensive information systems. By it very nature, knowledge engineering has a very close relationship with the engineering of agents and multi-agent systems (more specially, of knowledge bases used by agents). In all applications of knowledge engineering, the conceptual modeling of knowledge at different levels of details is a central topic [18]. As related before, the essentials of the proposed agent-based process management is the perception of the current business environment, and the reasoning about tasks based on business logic. Accordingly, two fundamental concerns of knowledge, environment state and business logic, are discussed in the following section. Some examples are used for illustration. In these examples, the perception of environment and business rules for process reasoning are written in Jess, which is a rule engine and scripting environment written in Sun's Java language [9].

The information about events that occurred usually refers to the messages captured and interpreted by the system. For example, the event of receiving a request of Order No.15421 from a customer can be interpreted as the fact below. (event (e-type order_request) (ord-no 15421)) The states of resources and tasks can be kept being detected by the system, and represented as facts for reasoning. The state of an order can be presented as the following fact, from which we know about the validation and confirmation status of Order No.15412. (order (ord-no 15412) (validation validated) (confirmation NULL)) The state of a task is described in the following example, which records the confirmation activity for Order No.15420 has started and not yet completed. (task (t-type confirm_order) (ord-no 15420) (start-time 1.009598657E9) (finish-time NULL))

3.3.1. Environment state

3.3.2. Business logic

The agent is situated in the environment by perceiving situation data and in the society by message communicating with other agents. In order for the interaction with the external world, the agent needs to obtain the information about the environment, which may include events that occurred in the environment, state of tasks or resources, etc. This kind of knowledge may come from several kinds of data, e.g. input from external systems (including users), output of tasks, and status of tasks and resources. They form the agent’s dynamic beliefs about its environment.

In general, business logic is a set of formal or informal statements about how business is done. It can be represented in the form of business rules, each of which represents a small unit of knowledge of business management. At a high level, business rules could be classified under one or more concerns, such as controlling workflow, reducing business risk, making efficient use of resources, and improving customer service [16]. In our approach, rules of process management concern process routing, operational constraint, exception handling, and business strategy

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

4


[23]. Such rules form the knowledge base of cognitive agents in process management. Rules on process routing are used for scheduling tasks or activities. Following the previous example, an order request received from a customer is scheduled for validation. This routing can be specified by the following rule, which is to activate the task of order validation based on the order request. (defrule order-request (event (e-type order_request) (ord-no ?no)) =>(assert (task (t-type validate_order) (ord-no ?no) (start-time (time))))) According to [2], four basic types of process routing are generalized, which include sequential routing, conditional routing, parallel routing, and iterative routing. Each type can be specified using AND/OR and split/join blocks, based on which process routing can be mapped into business rules to manage business activities. Rules about operational constraints are used to exercise control of tasks and prohibit unauthorized operations. Such rules can be specified on the basis of business requirements. The rule below is an example to reject the cancellation of an order that has been confirmed. (defrule reject-confirmed-order (event (e-type order_cancel_request) (ord-no ?no)) (order (ord-no ?no) (confirmation ?cfm)) =>(if (= ?cfm confirmed) then (assert (task (t-type reject_cancel_order) (ordno ?no))) else (if (= ?cfm NULL) then (assert (task (t-type cancel_order) (ord-no ?no)))))) In order to keep track of the changes in the workflow environment to reduce business risks, monitoring rules can be applied to capture real-time status of tasks or resources and take actions when necessary. For example, if an order request has not been confirmed in 20 minutes (i.e., 1200 seconds), the system will remind the user of the confirmation task if this reminder message has not been delivered before. (defrule remind-confirmation (task (t-type confirm-order) (ord-no ?no) (start-time ?t1) (finish-time NULL)) (test (> (- (time) ?t1) 1200)) (not (remind-history (r-type remind_confirm_order) (ord-no ?no)))

=>(assert (task (t-type remind_confirm_order) (ord-no ?no))) (assert (remind-history (r-type remind_confirm_order) (ord-no ?no)))) As related before, business logic could be used not only for controlling workflow, but also for reducing business risk, making efficient use of resources and improving customer service. Business strategies can be regarded as one type of business logic, though most of them are implicit and difficult to translate into business rules. The following is an example of a promotion strategy, in which a gift will be sent to a customer who has made a large order. (defrule send-gift (event (e-type order_confirmed) (ord-no ?no)) (large-order (ord-no ?no)) (not (gift-sent (ord-no ?no))) =>(assert (task (type send_gift) (ord-no ?no))) (assert (gift-sent (ord-no ?no) (send-time (time)))))

4. Case study For illustration and evaluation of the proposed cognitive approach, a case application of exception management in securities trading is presented in this section. Relevant information of exception management in securities trading can be found in [19, 24, 25].

4.1 Case description With rising trading volumes and increasing risks in securities transactions, the securities industry is making an effort to shorten the trade lifecycle and minimize transaction risks. Significant inefficiencies in crossborder transactions caused by data re-entry, lack of standards, delays, frequent manual intervention, and other breaks in the security transaction workflow have led to high failure rates, high costs and operational risks in such trades. Exceptions in securities transactions may not only increase processing costs, but also damage service reputations. The financial services industry is making efforts to achieve the end-to-end automation of security trading process from order to settlement. While attempting to achieve this, exception management is critical to pass trade information within the trade lifecycle in a timely and accurate fashion. Care must be taken to ensure that trades containing errors are detected and reconciled at the earliest opportunity [19, 14]. According to [24, 25], the major activities/tasks and general procedure of exception management in securities trading are briefly described below.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

5


i) Trade Detail Monitoring is to capture unusual components in trade details, such as a trade dealt at a price significantly different from the market price, incorrect calculation of trade cash value, missing components, and so on. ii) Trade Status Monitoring is to keep watch on the agreement status of each trade, and detect the trades that have not been agreed on a timely manner or trades that were not agreed on by trade parties. iii) Diagnosis is to investigate the nature of exceptions and offer resolution advice to settle the problems. iv) Resolution is to carry out actions on exceptions based on the output of the diagnosis. Generally speaking, the process starts with the monitoring of trade details and trade agreement status. Any exception detected will be reported and result in the diagnosing activity. Then, a diagnostic report will come out with resolution advice. Once the resolution advice is

validated by the manager, actions will be carried out to resolve the exception. However, the process in realworld situations is more complex than this. Followed are some possible situations that are not covered in the general process. 1) Information contained in an error report is not enough to make resolution advice, and additional data are required for diagnosis. 2) The resolution advice on a problem detected is not produced within a normal time frame due to lack of information or other reasons. 4) Diagnostic experts need to make some adjustment on advised resolutions. 5) The chief manager is not available to validate the resolution advice. 6) Emergent errors are required to be reported to the chief manager directly for instant actions.

HPHUJHQWHUURUUHSRUW

7UDGH GDWD Trade Status Monitoing Agent

UHVSRQVH UHPLQGHU

UHPLQGHU

TXHU\ UHVROXULRQDGYLFH

HUURUUHSRUW

Diagnostic Agent HUURUUHSRUW

TXHU\

Resolution Agent

UHVSRQVH TXHU\

Trade Details Monitoing Agent

([FHSWLRQ UHVROXWLRQ

UHVSRQVH

HPHUJHQWHUURUUHSRUW

([FHSWLRQPDQDJHPHQWV\VWHP

Securities trading & settlement systems

Interface

Figure 3. Exception management prototype for securities trading

4.2 Prototype development It is seen that exception management in securities trading is a kind of complex process. Furthermore, it is also a kind of collaborative process, in which multiple organizations (e.g. trading company, settlement company, etc.) and a mixture of human activities and automated tasks may be involved. Considering the distributed environment and complex processes, the agent-based approach is applied by delegating tasks to a collection of agents, i.e. Trade Details Monitoring Agent (TDMA), Trade Status Monitoring Agents (TSMA), Diagnostic Agent (DA), and Resolution Agent (RA).

Each agent plays a specific role in exception management, responsible for relevant tasks mentioned in Section 4.1. The framework of the system is portrayed in Figure 3, which describes the internal interactions between agents and the external relationship between the exception management system and legacy trading and settlement systems. These agents are deployed in organizations or departments involved in securities transactions, such as trading company, settlement company, etc. They communicate with each other through the network. The deployment of these agents may differ depending on deployment of securities trading organizations

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

6


throughout the trading life cycle. Usually, TDMA is located with the trading system, while TSMA is placed with the settlement system. They monitor exceptions in trade details and trade agreement status respectively. DA can be set up in the risk management department to examine the nature of reported exceptions and provide advice of resolutions. Based on the report of the DA, RA placed in the chief management department can carry out actions to resolve exceptions. Besides agents, interface facilities are employed together with agents to support the interaction between the system and users. Following the agent-based approach to complex process management proposed in Section 3, a prototype system has been developed for exception management in securities trading. The prototype is built using JWSDP (Java Web Services Development Package) (Java.sun.com), and Jess (Java Expert System Shell) [9] is adopted as the expert system engine. Using Jess, we build Java applets and applications that have the capacity to reason using knowledge which supply in the form of declarative rules. In the prototype, each agent is built as a cognitive entity equipped with specific business knowledge, based on which it can controls its activities in dynamic environment. Due to the limited space of this paper, only DA is illustrated as an example of agents in the system. The details are represented as follows. 4.2.1. Environment state The information of environment state are used to described 1) the major events that occur to DA, and 2) state of tasks and resources situation of DA. Such information listed in Table 1 and Table 2 is used for DA to know about its situation and reason appropriate actions. Table 1. Events that occur to Diagnostic Agent Event (event (e-type error_report) (err-no 102) (trd-no 12362)) (event (e-type data_receive) (err-no 102) (trd-no 12362)) (event (e-type resolution_advice) (err-no 102) (trd-no 12362)) (event (e-type modify_resolution) (err-no 102))

Meaning An error report No.102 is submitted from a monitoring agent; this error is related to trade No.12362. The requested data of trade No.12362 are received for the diagnosis of error No.102. The resolution advice for error No.102 related to trade No.12362 is produced. A request to modify the resolution to error No.102 is received.

Table 2. State of tasks and resources of Diagnostic Agent Task & resource (task-ongoing (t-type diagnose) (err-no 102) (start-time 1.009598657E9) (finish-time NULL)) (held-error-report (err-no 102)) (remind-history (r-type remind_diagnose) (err-no 101)) (large-trade (trd-no 13258))

Meaning The diagnostic task on error No.102 has started and not completed yet. The diagnosis on error No.102 is suspended. The reminder message has been sent out for the delayed diagnosis on error No.101. Trade No.13258 is of large value.

4.2.2. Business rule Rule-1 is to start a diagnostic task when an error report is received. (defrule rule-1 “start diagnosis” (event (e-type error_report) (err-no ?e_no)) => (assert (task (t-type diagnose) (err-no ?e_no) (starttime (time))))) Once additional data of trade detail or trade agreement status are required for diagnostic tasks, rule-2 or rule-3 is fired to activate the request task. (defrule rule-2 “request trade detail” (event (e-type trade_detail_request) (err-no ?e_no) (trdno ?t_no)) => (assert (task (t-type request_trade_detail) (err-no ?e_no) (trd-no ?t_no)))) (defrule rule-3 “request trade status” (event (e-type trade_status_request) (err-no ?e_no) (trdno ?t_no)) => (assert (task (t-type request_trade_status) (err-no ?e_no) (trd-no ?t_no)))) When requested data are received, rule-4 is fired to start the corresponding diagnostic task that was held for lack of data. (defrule rule-4 “continue diagnosis” (event (e-type data_receive) (err-no ?r_no)) ?held-error (assert (task (t-type diagnose) (err-no ?e_no) (starttime (time)))) (retract ?held-error))

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

7


An emergent error (e.g. errors of large trades) is required to be reported to the chief manager directly for instant action (defrule rule-5 “report emergent error” (event (e-type error_report) (err-no ?e_no) (trd-no ?t_no)) (large-trade (trd-no ?t_no)) => (assert (task (t-type emergent_report) (err-no ?e_no) (start-time (time))))) The diagnostic expert can adjust the resolution only before it is confirmed. This policy is specified in rule-6 below. (defrule rule-6 “reject modification of resolution” (event (e-type modify_resolution) (err-no ?e_no)) (confirmed-resolution (err-no ?e_no)) => (assert (task (t-type reject_modify_resolution) (err-no ?e_no))) Rule-7 is to keep watch on diagnostic tasks, and send out a reminder message if they have not been completed within a specified time frame. (defrule rule-7 “remind diagnosis” (task-ongoing (t-type diagnose) (err-no ?e_no) (starttime ?t1) (finish-time NULL)) (test (> (- (time) ?t1) 1200)) (not (remind-history (r-type remind_diagnose) (err-no ?e_no))) =>(assert (task (t-type remind_diagnose) (err-no ?e_no))) (assert (remind-history (r-type remind_diagnose) (errno ?e_no)))) 4.2.3. Mechanism and operation The mechanism of Diagnostic Agent follows the model outlined in Figure 2. The operation details of this agent are illustrated as follows. As described in Figure 2, when (1) an error is reported by a Monitoring Agent, (2) this event is transformed as the fact (event (e-type error_report) (err-no 102)). (3) The fact fires rule-1, thus (4) a diagnostic task is set in motion, and then (5) activated. However the expected resolution advice is not geberated for lack of data. Subsequently, (6) the data request is sent out, and (7) the current error report is recorded being held for recall. (8) The data request is interpreted as a corresponding fact, (9) which fires the rule-2 or rule-3. Then, the data request task is (10) scheduled, (11) activated, and (12) finally the request is sent out to the Monitoring Agent. When (13) the requested data arrive, (14) this event is translated into fact, (15) which fires rule-4. Thus, the diagnostic task on the held error report is (16) recalled, (17) activated, and finally (18) a resolution advice is sent to the Resolution

Agent. If the diagnostic task is not completed within a specified time frame, (19) this fact may fire rule-7, (20) schedule, and (21) activate the task of sending a reminder message to the relevant manager. (22) This reminder action is recorded in the history for memory.

4.3 Comparison and discussion The case above illustrates how the agent-oriented techniques are applied to business exception management, especially from the perspective of task management and knowledge engineering. For the evaluation of our approach, a comparison of the proposed approach with other related work is presented. Table 3. Comparison of the proposed agent-based approach with workflow approaches Approach Feature

Task routing Operational constraint Adaptation to changes Decisionbased control Employment of Business strategies Distributed Environment

Workflow approach without ECA rules

Workflow approach with ECA rules

Proposed agentbased approach

++ +

++ ++

+ ++

_

+

++

_

_

++

_

+

++

_

_

+

As described in Table 3 below, traditional workflow technology focuses on process logic and performs well in task routing. It also supports some degree of reaction to changes by including operational constraints and conditional branches in workflow model to deal with anticipated changes. However it falls short of features of flexible and collaborative workflow management, such as adaptation to changing environment, real time decisions on tasks, and distributed process management [2, 7, 8, 12]. Most efforts on flexibility in workflow systems have focused on the handling of expected exceptions whose character can be anticipated at buildtime [8, 11] By supplementation of ECA rules, workflow technology improves its function in the reaction to certain events by modelling exceptions in workflow [30]. ECA rules describe the situation under which the associated exceptions occur and the operations that

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

8


would resolve these exceptions. It supports operational control of asynchronous behaviour [6, 30]. Nevertheless, such operations are only based on reactions to certain events, instead of the perception of the whole dynamic environment. As a static bind of workflow schema with ECA rules, this approach exists limitations for highly flexible process management, e.g. reaction to unexpected changes, real time process sequencing, etc [31]. Agent paradigm surpasses previous object-oriented or functional paradigm in its capabilities to be autonomous, social, reactive and proactive [8]. The main benefits of an agent-based approach come from its flexibility, adaptability, and decentralization. Reactive agents can constantly monitor their environments and react to changes. Being proactive takes a step further which refer to the exhibition of goal-oriented behaviours by taking initiatives. Though agent technology has been applied in process management, most of them did not make good use of agent. The essences of agents, especially the proactive feature, are not addressed adequately in most work. Therefore, limited improvements for flexible process management have been observed in most applications. The cognitive approach proposed in this paper is designed to 1) overcome the limitations of workflow approaches; 2) investigate the mechanism of agent application in complex process management. This approach manages dynamic business processes by supporting the capability of decision-based control of the process through continuous perception of the process environment and real-time decision of tasks. It focuses on the ability to dynamically predict and modify workflow model based on business rules and reasoning. Furthermore, the mechanism of agent application in complex business process is investigated, especially in the context of cognitive mechanism of agent and its knowledge engineering. In the above case, the dynamic process of exception management and interaction among problem-solving entities is complex and unknown at workflow definition time. Therefore, it is difficult to manage using traditional workflow system. By using a cognitive approach, such a complex process is well modeled and controlled through the rules for task routing (e.g., rule-1, rule-2, rule-3, rule-4). Furthermore, constraints on operations (e.g., rule-6), monitoring of task progress (rule-7), and manipulation of business strategies (e.g., rule-5) are easy to perform by including them into business logic for process management.

constant changes in the business environment. There have been a number of research interests in the development of workflow management systems that offer a flexible and dynamic mechanism for routing and operational controls in workflow systems. This research aims to manage business processes based on real-time routing and strategic control of dynamic and complex activities. In this approach, the business process is defined as a set of business rules that control tasks through explicit representation of process knowledge. Compared with other related workflow model based on static routing and limited alternatives, our framework is characterized by 1) continuous perception of the process environment, 2) real time and decision-based control of the business process, 3) the extension from process logic to business logic for process management. Compared with most existing agent application in process management, this work has made more efforts on investing how to employ multi-agent technology into business process and exception management, especially from the flexible task management and knowledge engineering view, which is a basis for building intelligent agents to perform rational activities in process management. One limitation of this approach arises from the complexity of business logic, such as identification of business logic from business activities, correct representation of rules in a business sense, and maintenance of rules. Conventional workflow systems have the advantage in environments where there are only a few types of work and the routing schemes are relatively stable. Our model is more complex and appropriate for an environment that is characterized by many types of work involving dynamic routing patterns. The future work may consider to refine and extend this approach by building the pattern of business logic underlying common business activities, and designing user-friendly language support for rule specification and manipulation in complex process management.

5. Conclusion

[3] A. Basu and A. Kumar, Research Commentary: Workflow Management Systems in e-Business, Information Systems Research, Vol. 13, No. 1, March 2002, 1-14.

One basic premise of advanced business process management is that business processes must adapt to the

References [1] W.M.P. van der Aalst, Loosely Coupled Interorganizational Workflows: Modeling and Analyzing Workflows Crossing Organizational Boundaries, Information and Management, 37(2), 2000, pp.67-75. [2] W.M.P. van der Aalst, A. Kumar, XML-Based Schema Definition for Support of Interorganizational Workflow, Information Systems Research, 2003, Vol.14, No.1, pp.23-46

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

9


[4] D. Chiu, Q. Li and K. Karlapalem, Cooperative Exception Handling in ADOME Workflow Management System, Information Systems: an International Journal (special issue on Web Information Systems Engineering), 26(2), 2001, pp.93-120.

[20] H. Wang, J. Mylopoulos and S. Liao, Intelligent Agents and Financial Risk Monitoring Systems, Communications of the ACM, Vol. 45 (3), 2002, pp.83-88.

[5] J. Giarratano, G. Riley, Expert systems: principles and programming, PWS Publishing Company, Boston, 1998, pp.38.

[21] S. Huwang, J. Tang, J., Consulting past exceptions to facilitate workflow exception handling, Decision support systems, 2004, 37, pp.49-69

[6] P. Grefen, B. Pernici, G. Sanchez, Database support for workflow management: the WIDE project, Kluwer Academic Publishers, 1999, Boston, Mass.

[22] M. Wang and H. Wang, The Design of Intelligent Workflow Monitoring with Agent Technology, forthcoming in Knowledgebased Systems, 2004.

[7] M. N. Huhns, M. P. Singh, Workflow agents, IEEE Internet Computing, Volume 2, Issue 4, 1998, pp.94 –96.

[23] M. Wang and H. Wang, Agents and Web-services Supported Business Exception Management, Proceedings of 8th Pacific Rim International Conference on Artificial Intelligence (PRICAI 2004), Auckland, New Zealand, August 2004, Lecture Notes in Artificial Intelligence, 2004, vol.3157, pp.615-624, Springer.

[8] N. R. Jennings, P. Faratin, T. J. Norman, P. O'Brien and B. Odgers, Autonomous Agents for Business Process Management, Int. Journal of Applied Artificial Intelligence, 14 (2), 2000, pp.145-189. [9] Jess – the rule engine for the http://herzberg.ca.sandia.gov/jess, 2001.

JavaTM

platform,

[24] M. Wang, H. Wang, K. Wan, and D. Xu, Knowledge-based Exception Handling in Securities Transactions, Proceeding of Hawaii International Conference on System Science (HICSS-37), Hawaii, US, January 2004.

[10] P. J. Kammer, G. A. Bolcer, R. N. Taylor, A. S. Hitomi, M. Bergman, Techniques for Supporting Dynamic and Adaptive Workflow, Computer Supported Cooperative Work, 2000, Vol. 9, Issue 3-4, pp.269-292.

[25] M. Wang, H. Wang, D. Xu, K. Wan, and Doug Vogel, A Web-service Agent-based Decision Support system for Securities Exception Management, Expert Systems with Applications, 2004, 27(3), pp.439-450.

[11] M. Klein, C. Dellarocas, A. Bernstein, Introduction to the Special Issue on Adaptive Workflow Systems, Computer Supported Cooperative Work, Vol.9, Issue 3-4, 2000, pp.265-267.

[26] WfMC, The http://www.wfmc.org.

[12] M. Klein, C. Dellarocas, A Knowledge-based Approach to Handling Exceptions in Workflow Systems, Computer Supported Cooperative Work, Vol.9, Issue 3-4, 2000, pp.399-412. [13] A. Kumar and L. Zhao, Dynamic Routing and Operational Controls in a Workflow Management System, Management Science, Volume 45, No. 2, 1999, pp.253-272. [14] V. Kumar and G. David, Global Straight Through Processing, The Evolution Continues, Electronic Data Systems Publication, 2000. [15] F. J. Lerch, D. E. Harter, Cognitive support for real-time dynamic decision making, Information systems research, Vol.12, No.1, 2001, pp.63-82. [16] T. Morgan, Business rules and information systems, Addison-Wesley, New York, 2002.

workflow

reference

model,

[27] M. Wooldridge, N. Jennings, Intelligent agents: theory and practice. The Knowledge Engineering Review, 10(2), 1995, pp.115-152. [28] M. Wooldridge, An introduction to multiagent systems. England: J. Wiley, Chichester, 2002. [29] H. Zhuge, Workflow- and agent-based cognitive flow management for distributed team cooperation, Information & Management, Vol.40, 2003, pp.419-429. [30] F. Casati, S. Ceri, S. Paraboschi, & G. Pozzi, Specification and implementation of exceptions in workflow management systems, ACM Transactions on Database Systems, 1999, 24 (3), pp.405 – 451. [31] L. Zeng, D. Flaxer, H. Chang, & J. Jeng, PLMflow-Dynamic Business Process Composition and Execution by Rule Inference, Lecture Notes in Computer Science, Vol.2444, pp.141-150.

[17] P. D. O’Brien and W. E. Wiegand, Agent based process management: applying intelligent agents to workflow, The Knowledge Engineering Review, Vol. 13(2), 1998, pp.1-14. [18] G. Schreiber, H. Akkermans, A. Anjewierden, R. deHoog, N. Shadbolt, W. VandeVelde, and B. Wielinga, Knowledge engineering and management: the CommonKADS methodology, Cambridge, Mass. MIT Press, 2000. [19] M. Simmons, Securities operations: a guide to trade and position management, John Wiley & Sons, New York, 2001.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

10