Keywords

1 Introduction

It is generally recognized that business processes need to be executed in a manner that is robust and resilient to changes in the operating environment within which these processes are executed. The challenge is not only to be flexible enough to deal with immediate impediments to process execution, but to also anticipate future states of affairs that might impede process execution (or the achievement of process goals). Impediments to the successful execution of a business process can appear in many forms. For instance, an outsourced search for past buying behaviour of a customer in a credit check process might return no results, or results for the wrong customer, thus preventing the successful execution of an instance of that process. An automated process for maintaining the ambient temperature inside a building might be impeded by a non-functioning air-conditioner, or by a faulty sensor that reports incorrect temperature readings. A clinical process might have to face obstacles caused by a patient who forgets (or deliberately ignores) to ingest a prescribed pill left at his/her bedside by a nurse.

Most of the examples above involve functional impediments (that prevent the achievement of functional process goals in a manner akin to the notion of obstacles [1]). Non-functional impediments can also occur, such as when the outsourced service for retrieving the past buying behaviour of a customer delays the delivery of its results, thus preventing a process from meeting its non-functional requirements. The framework we develop in this paper is general enough to handle both kinds of impediments, but we mainly focus on functional impediments in the formalization and evaluation due to space restrictions.

Traditional conceptions of process designs that rely on task IDs to represent information about the effects of that task are not easily amenable to the kinds of analysis that would reveal whether a given state of affairs impedes the achievement of process goals. To perform this analysis, we would require an exhaustive enumeration of all possible states of the environment that might present obstacles to the successful execution of a process task - an often-impossible exercise. This analysis is significantly simpler (and can be performed at runtime) if processes are annotated with task post-conditions. For instance, a given state of the environment would impede the process if it negated any of the desired post-conditions at that point. A large body of reported work leverages semantic annotation of business process designs [2,3,4,5,6,7,8,9,10]. A number of proposals also address the problem of semantic annotation of web services in a similar fashion [11,12,13,14]. Our framework, therefore, leverages semantically annotated process models (i.e., process models where each task is annotated with post-conditions).

Our discussion above suggests that the relationship between a process and its operating environment can often be adversarial. The adversarial behaviour of the environment might be intentional (where entities within the environment might have an interest in preventing the successful execution of a process) or unintentional (where the natural behaviour of the environment throws up impediments). In either case, there is value in viewing the interaction between the process and the environment as an adversarial game pitting the process (which is, say, the maximizing player) against the environment (the minimizing player). The value of a game formulation stems from the following. In a manner akin to a traditional 2-player adversarial game, the process can reason about a sequence of moves it might make (tasks it might execute) that would help achieve process goals (winning states in a game formulation) in the face of counter-moves by the opposing player (impediments thrown up by the environment). The game is one of perfect information since the state of the game (in this case, the state of the process operating environment) is equally accessible to both players. The game involves turn-taking, with the process making a move, then the environment making a move and so on. While this does not necessarily exactly reflect what might happen in a real-world setting, it serves as an adequate abstraction. This game-tree search formulation of the problem relies on the process having access to some modicum of understanding of the behaviour of the environment (an environment behaviour model). In the simplest case, this might be a set of impediments (conditions in the operating environment) that might hold. To be maximally robust, the process might perform worst-case reasoning by assuming extreme adversariality of the environment, where the environment makes those conditions true that most impede the achievement of process goals. More sophisticated models of the behaviour of the environment (via state transition models or via the generation of impediments in a context-sensitive fashion) could also be used.

It is useful to consider the manner in which adversarial game-tree search might be incorporated into the process execution machinery. Game-tree search essentially involves process re-consideration, i.e., re-designing the normative process flow (i.e., the flow mandated by the process design). Given that our understanding of possible impediments occurring in the operating environment of the process is context-sensitive in general (in many settings, it is difficult to re-compute or predict these impediments at design time), it is useful to reconsider process designs during run-time. The granularity of reconsideration can be parametric. At the one extreme, we have step-wise reconsideration, where we re-visit what is to be done next after every step. More generally, we might adopt a policy of reconsidering after every k steps (or k-step reconsideration, the lower the k, the more reactive the process is). Process reconsideration can also be triggered by situations where the observed effects do not correspond to the expected effects (something referred to as semantic non-conformance in [15]). It is also useful to note that adversarial game-tree search can form the basis of offline process design, and the experimental results we present later in the paper may also be viewed as illustrating that use case. Process reconsideration can be used to decide the immediate next step, or the sequence of the following n steps (closely related to k-step reconsideration).

We offer two formulations of the robust process design/execution problem, first in terms of the well-known minimax game tree search algorithm (with \(\alpha \)-\(\beta \) cutoffs), and second in terms of the Monte Carlo tree search algorithm. Our experimental evaluation suggests that this approach to achieving process robustness/resilience is practical. The experimental evaluation also offers a more nuanced understanding of the merits of minimax search with \(\alpha \)-\(\beta \) cutoffs relative to Monte Carlo tree search. Ultimately, the intent is to compute a sequence of tasks (which might be at variance with the mandated process model) that is most likely to achieve process goals in the face of potential impediments. In the case of the clinical process example mentioned earlier in this section, a robust workaround would be to execute an additional task that involves a nurse monitoring the ingestion of the prescribed pill by the patient (similar workarounds can be imagined for the other example settings).

The rest of the paper is structured as follows. Section 2 describes the setting of semantically annotated process models as well as the normative and observed execution traces that the proposed framework leverages. Section 3 describes the formulation of the robust process enactment problem as adversarial game tree search. Section 4 provides a detailed experimental evaluation while Sect. 5 provides concluding remarks.

2 Processes Annotated with Post-conditions

In this section, we define the class of process models that our proposal relies on, specifically semantically annotated process models. We also define the notions of normative and semantic execution trace that we shall leverage in the heuristic evaluation required by game tree search (these latter notions were first defined in [15], and our exposition below summarizes those results). The definition of a semantically annotated process model refers to effect scenarios, which provide answers to the following question posed at design time: given a process design and a designated point in that process design, what postconditions/effects would hold if the process were to execute up to that point? We assume a setting where tasks are drawn from a capability library (that describes all of the tasks/capabilities that the enterprise is able to execute). We also assume that all tasks in the capability library are annotated with post-conditions that describe the context-independent effects of executing those tasks. To answer the question posed above, we need to accumulate these context-independent post-conditions to simulate the effects of process execution. Unlike a number of the process annotation approaches referred to in the introduction that accumulate task post-conditions by using the AI planning device of add-lists and delete-lists of effects, we use the state update operator approach from [5, 8] (recall that a state update operator takes a state description and the effects of an action to generate one or more descriptions of the state that would accrue from executing this action in the input state). In our setting, the answer to the question posed above is non-deterministic in general, and is provided as a set of (mutually exclusive) effect scenarios. There are two reasons why we need these answers to be non-deterministic. First, in any process with XOR-branching, one might arrive at a given task via multiple paths, and the accumulated effects depend on the path taken. Since this analysis is done at design time, the specific path taken can only be determined at run-time (thus leading to non-determinism in the accumulated effects). Second, state update operators typically generate non-deterministic outcomes since the inconsistencies that commonly appear in state update can be resolved in multiple different ways. When the execution of a process leads to a state that is (possibly partially) characterized by an effect scenario, the execution of the next task in the model, or the occurrence of the next event, can lead to a very specific set of effect scenarios, determined by the state update operator being used. In effect, the process model determines a transition system, which determines how the partial state description contained in an effect scenario evolves as a consequence of the execution/occurrence of the next task (event) specified in the model. We assign each effect scenario appearing in a semantically annotated process model a unique ID (thus if the same partial description applies to a process at different points in its design, it would be assigned a distinct ID at each distinct point). We can thus refer to the predecessors (the effect scenarios that can lead to the current scenario via a single state update determined by the next task/event) and successors (the scenarios that can be obtained from the current scenario via a single state update determined by the next task/event) of each effect scenario with respect to the transition system implicitly defined by the process design.

Given these preliminaries, we define a semantically annotated process model \(\mathcal {P}\) as a process model (such as a BPMN model) or a process graph (in the usual sense that the term is used in the literature - a formal definition is omitted to save space) in which each task or event is associated with a set of effect scenarios. Each effect scenario es is a 4-tuple \(\langle ID, S, Pre, Succ \rangle \), where S is a set of sentences in the background language, ID is a unique ID for each effect scenario, Pre is a set of IDs of effect scenarios that can be valid predecessors in \(\mathcal {P}\) of the current effect scenario, while Succ is a set of IDs of effect scenarios that can be valid successors in \(\mathcal {P}\) of the current effect scenario.

A semantically annotated process model is associated with a set of normative traces, each providing a semantic account of one possible way in which the process might be executed. Formally, a normative trace nt is a sequence \(\left\langle \tau _1, es_1, \tau _2, \ldots es_{n-1}, \tau _n, es_n \right\rangle \), where

  • Each of \(\tau _1, \ldots , \tau _n\) is either an event or an activity in the process.

  • \(es_1 = \left\langle ID_1, S_1, \emptyset , Succ_1 \right\rangle \) is the initial effect scenario, normally associated with the start event of the process;

  • \(es_n = \left\langle ID_n, S_n, Pre_n, \emptyset \right\rangle \) is the final effect scenario, normally associated with the end event of the process;

  • \(es_i \ldots , es_n\) are effect scenarios, and for each \(es_i = \left\langle ID_i, S_i, Pre_i, Succ_i \right\rangle \), \(i \in [2..n]\), it is always the case that \(ID_{i-1} \in Pre_i\) and \(ID_{i} \in Succ_{i-1}\).

We shall refer to the sequence \(\left\langle \tau _1, \tau _2, \ldots , \tau _n \right\rangle \) as the identity of the trace nt. To simplify exposition, we will on occasion use es to refer to only the S in the 4-tuple denoting an effect scenario.

A semantic execution trace of a process \(\mathcal {P}\) is a sequence \(\left\langle \tau _{1}, o_1, \tau _{2}, o_{2}, \ldots , \tau _{m}, o_{m} \right\rangle \) where each \(\tau _{i}\) is either a task or an event, and each \(o_{i}\) is a set of sentences in the background language that we shall refer to as an observation that describes (possibly incompletely) the state of the process context after each task or event. We shall refer to the sequence \(\left\langle \tau _1, \tau _2, \ldots , \tau _m\right\rangle \) as the identity of the execution trace. Note that we do not require each \(\tau _{i}\) to belong to the process design \(\mathcal {P}\) to allow the possibility of actual executions being erroneous, or to represent on-the-fly re-designs.

3 The Robust Process Enactment Problem

We address the robust process enactment problem, defined as follows:

Given

  • A semantically annotated process model \(\mathcal {P}\),

  • A capability library consisting of tasks with context-independent post-conditions \(\mathcal {C}\) (in more sophisticated settings, we might view each element of \(\mathcal {C}\) as having both a precondition pre and a postcondition post),

  • An environment behaviour model \(M: \mathcal {S} \rightarrow 2^{\mathcal {S}}\), where \(\mathcal {S}\) is set of all possible states,

  • A set of goal conditions (the achievement of any one of which would count as successful process execution) \(\mathcal {G}\),

  • The sequence of tasks \(\left\langle \tau _1, \tau _2, \ldots , \tau _i \right\rangle \) that have been executed thus far,

  • The current observed state \(o_i\) of the process operating environment, and

  • A state update operator \(\oplus \),

Determine:

  • A sequence of tasks \(\left\langle \tau _1, \tau _2, \ldots , \tau _i, \ldots , \tau _n \right\rangle \) where each \(\tau _i \in \mathcal {C}\) that is most likely to achieve a goal-satisfying state (i.e., a state that makes at least one of the goal conditions true) under the assumption that the environment behaves in a maximally adversarial fashion.

Note that this formulation permits us to also consider other variations, such as:(1) determining what the next task should be, (2) determining what the next k tasks should be and (3) determining at the initial state what the complete sequence of tasks should be that would lead to a goal-satisfying state.

Fig. 1.
figure 1

Example: game tree search in car service

Full size image

Consider for example a car servicing process in an auto repair/maintenance store that consists of a task that replaces the tyres of the car, then a wheel alignment task, followed by a road test. Suppose that the alignment machine in store is currently unavailable. As the result, the normative process task (i.e. wheel alignment) cannot be performed. The capability library of the store suggests some alternative tasks or task sequences can be executed to achieve the same process goal which may include (see Fig. 1).

  1. (1)

    Ask the customer to take the car to another shop for wheel alignment and reimburse the customer against a receipt, then complete the remaining tasks in-store;

  2. (2)

    The shop takes the car to a pre-arranged shop for wheel alignment, pays that shop, then completes the remaining tasks;

  3. (3)

    Ask the customer to come back another day when the machine becomes available by delaying the currently impeded process;

  4. (4)

    Rearrange the task sequence, i.e. skip the current task and complete the remaining tasks first, then do the wheel alignment later when the machine becomes available.

At first blush, all tasks/task sequences that resolve the current impediment seem to be equally feasible. However, if we look further into the future, the ramifications of some of the options above may cause problems for later tasks and impact quality of service requirements such as the overall customer satisfaction, service standards, etc. For example, if option (4) is taken and the road test is preformed before the wheel alignment, the test may be unsafe and the test result maybe inaccurate. In addition, after wheel alignment is performed, another road test may be required. Option (3) requires the customer schedule another time, which may lead to a dissatisfied customer. As the result, options (1) and (2) may be better options as they only delay the current process instance slightly during the time of the unavailable machine, and do not increase the possibility of any future impediments. They may however increase the cost, and in particular option (1) may reduce the customer satisfaction, as well as introduce some potential new impediments (worst case scenarios) such as the arranged shop refusing to provide wheel alignment service due to the large amount of requests that affect its normal operation, or the customer losing the receipt for reimbursement etc. Thus, the purpose of the game-tree search is to consider and evaluate all the feasible alternatives during process execution.

The general problem can be instantiated in a variety of ways. The assumption of maximally adversarial behaviour on the part of the environment is a form of worst-case reasoning. It entails that the environment will behave in a manner (consistent with the environment behaviour model) that most impedes process goal satisfaction. This does not necessarily mean that the environment is deliberately adversarial, but only that the worst-case behaviour of the environment has been taken into account in deciding what to do next during process enactment. We will say that a condition (made true by the environment) c impedes the achievement of a goal condition g if and only if \(c \wedge g\, \models \! \perp \). In some cases, we might approximate the environment behaviour model via a set of conditions that the environment is capable of bringing about. In other cases, we might provide more sophisticated behaviour models in the form of state transition systems or sets of event-condition-action rules. The sequence of steps executed thus far might be empty if a procedure for solving this problem is invoked at the start of the execution of a process instance, or if the intent is to compute a maximally robust process design. The current state of the process operating environment is important as an independent input since the sequence of process steps executed might lead to a predicted state of affairs (via the accumulation of task post-conditions as discussed earlier) that might be at variance with the current state (this, in itself, can be a trigger for process reconsideration). When the intent is design-time analysis for computing robust process models, the current state might be left empty, or populated by the expected start state of the process (one could also reason by cases and compute multiple process models if a set of mutually exclusive start states need to be accounted for). The accumulation of task post-conditions involves the application of a state update operator. Several such operators have been proposed in the literature, two prominent ones being the Possible Worlds Approach (PWA) [16] and the Possible Models Approach [17].

Our proposal involves the use of game tree search to solve a 2-player adversarial game of perfect information in addressing the robust process enactment problem. The two players are the process and the environment. The game is one of perfect information since the state of the environment is equally accessible to both players. The simplest game tree search algorithm is minimax search, which involves a maximizing player (that seeks to maximize the payoff or utility) and a minimizing player (that seeks to minimize the payoff - all states of the game being assessed by the same utility/payoff function). The key data structure is a game tree where each node represents a state of the game and nodes at alternating levels represent states of the game that can be achieved via moves made by a given player. For a fully expanded game tree, the leaf nodes represent end-game states (these can be labelled with 1, \(-1\) and 0 to represent a win, loss or draw for the maximizing player, or with values from a real-valued interval to represent degrees of winning etc. for the maximizing player). The minimax algorithm proceeds by propagating these values up the game tree, with a node corresponding to a state where the maximizing player makes a move being labelled with the maximum of the utility values of its child nodes (and the converse for nodes where the minimizing player makes a move). The intent is to obtain a payoff/utility value labelling all of the child nodes of the root of the tree (the state at which a move must be made by one of the players). Once these labels are obtained, the maximizing player selects that move that leads to the state with the highest utility (converse for the minimizing player). For most complex games (such as chess), the full tree is too large to enumerate, and search proceeds by cutting off the tree at a fixed (parametric) depth and treating the nodes at that depth as pseudo-leaf nodes. Since these nodes do not represent end-game states, they do not have exact payoff values associated with them. Instead, a heuristic evaluation function is used to estimate the “goodness” of a given node (an approximate indicator of the likelihood that a move leading to that node will eventually lead to a win for the maximizing player). Minimax search with \(\alpha \)-\(\beta \) cutoffs involves bound propagation on payoff values to prune the search tree (we do not provide a more detailed exposition due to space constraints).

In our setting, each node represents a state of the process operating environment. The moves available to the process player correspond to tasks in the capability library while the moves available to the environment player correspond to the conditions (potential impediments) that can be made true by the environment as per the environment behavioural model. Both task post-conditions and impediments can be viewed as sentences in the underlying language. Given such a sentence e and a prior state s, the resulting state is denoted by \(s \oplus e\) where \(\oplus \) is the state update operator provided as input. State update operators generate possibly many non-deterministic outcomes in the general case (the Possible Worlds Approach, for instance, generates as a resulting state \(s' \cup e\) for each maximal - with respect to set inclusion - subset of s that is consistent with e). The non-deterministic states associated with a given move represents a point of departure from standard minimax search (where a given move leads to a unique state). This can be handled easily by extending the worst-case reasoning approach that underpins minimax search. Thus, if a maximizing player contemplates a given move, it will pick the state with the lowest payoff amongst the possibly many states that can result from that move as the resulting state (converse for the minimizing player).

Designing a heuristic evaluation function that is able to estimate the likelihood of a given state leading to a “win” for the maximizing player is another challenge. The evaluation function we use in generating the experimental results presented in the next section is conceived with the following intuition in mind. Instead of assigning numeric values for each state, this function generates a preference ordering on a set of states (which can be used in much the same way as a set of numeric payoff values). A state s is preferred over another state \(s'\) if s is “closer” (in a sense to be made precise below) to either the nearest goal state or the nearest state in any normative execution trace with an identity (recall the definition at the end of Sect. 2) for which the sequence of tasks already executed serves as a prefix (and which has not been already traversed in the execution thus far). Given a set of sentences t and a background knowledge base KB, we use \(Cn_{KB}(t)\) to denote the set of all logical consequences of \(t \cup KB\). Let the union of the goal states and the states in the normative execution traces discussed above be referred to as the set of desired states. One plausible and intuitive means (but by no means the only one) of assessing the proximity of a state s to a desired state d (denoted by f(s, d)) is as follows:

$$\begin{aligned} f(s, d) = \frac{\left| Cn(s)\cap Cn(d)\right| }{\left| Cn(d)\right| } \end{aligned}$$
(1)

This function obtains a higher value the closer the cardinality of the intersection of the set of consequences of s and d gets to the cardinality of d. In the experimental evaluation, we compute the number of clauses in a CNF representation of d that are entailed by s, as one computational realization of the expression above. Since we are able to work with ground theories (universally quantified rules in the KB are replaced by their ground instances - of which there is a relatively small number), we use the SAT4J SAT solver as our theorem prover.

Each step in the search process proceeds as follows. If the current (observed) state is o, and it is the process player’s turn to make a move, then the set of feasible next states (that determine the next level of the game tree) is given by the set \(o\oplus post\) for each post associated with available tasks in the capability library (in more sophisticated settings where we also have task pre-conditions, we determine whether \(o\,\models \, pre\) before we conclude that a task is feasible to execute). If it is the environment player’s turn to make a move, then the set of feasible next states is determined by \(\bigcup M(s_i)\) for each \(s_i\) satisfying \(o\,\models \, s_i\).

It is useful to consider the impact loops in a process in this context. It is fairly obvious that generating semantic annotations for process designs with loops is problematic (simply because we cannot predict at design time the number of times the process would loop). In the context of the robust process enactment problem, however, loops pose no problems. It is perfectly feasible for this framework to return a task sequence that includes multiple iterations of a task or task sequence, if that is the best strategy for dealing with potential obstacles (as a trivial example, we might end up needing to press a “temperature-up” button on a thermostat to achieve the desired temperature).

4 Evaluation

Let I being the set of impediments that the environment is capable of making true. For the purposes of experimental evaluation, we adopt a maximally adversarial model of the environment. We generate the set of impediments I by creating a distinct impediment from the negation of every clause in a conjunctive normal form (CNF) representation of a goal. Thus, given a set of goal states \(G_p\) (in CNF) of the process p, the set of impediments \(I_p\) is defined as:

$$\begin{aligned} I_p = \left\{ \lnot c | \forall c \in g, \forall g\in G_p\right\} \end{aligned}$$
(2)

Minimax Tree Search: In this evaluation we use minimax tree search with \(\alpha \)-\(\beta \) cutoffs. Due to the complexity of the search, we limit the depth of the game tree to 5. The heuristic evaluation function discussed in the previous section is applied to the pseudo-leaf nodes at this depth.

Monte Carlo Tree Search: We compare the performance of minimax search with \(\alpha \)-\(\beta \) cutoffs against a popular Monte Carlo Tree Search(MCTS) algorithm, namely Upper Confidence Bounds for Trees (UCT) (the description of the algorithm can be found in [18]) with a random play-out simulation to evaluate a given state. Every time the process needs to select the next task to execute, the tree is sampled 5n times where n is the number of possible tasks available for the process to select. We then select a leaf node that is not a terminal state (i.e., a goal state), expand it and preform random play-out at all the newly expanded nodes. The random play-out is a simulated game play where each player randomly selects a move at every turn until the game reaches a terminal state or until the time runs out (we use a timeout of 3 s). The value 1 is returned when a goal state is reached in the random play-out. Alternatively, 0 is returned if a goal state cannot be reached in the given time (3 s).

Evaluation Data: Semantically annotated process models that generate sensible results are difficult to randomly generate. Two sets of hand-crafted semantically annotated process models are used in this evaluation. The first set of 8 processes are structurally and semantically simpler. Process1 is the simplest, with only 4 tasks in sequence, 1 or 2 assertions in the effects of each task and 3 rules in the background knowledge base. Process2 has the same number of tasks as Process1 but with one extra XOR branch and slightly more complex semantic annotations. Process3 is also a sequence of tasks, but with more complex semantic annotations. For the rest of the processes (Process4 to Process8), we progressively increase either the structural complexity (i.e. more tasks and/or more XOR branches), or increase the complexity of the semantic annotations. Process8 is a “real world” process created using information available at workflowpatterns.com.

The second set of processes have considerably greater structural and semantic complexity relative to the first set. The number of unique tasks (capabilities) in each process in this set varies from 10 to 100, with the number of XOR gates varying from 1 to 15. In terms of semantic complexity, we use between 20 to 50 propositional state variables to describe states of objects in the environment (which is expressive enough for most task effects/postconditions of interest). We assume that each task will impact between 1 to 5 state variables. We use between 20 to 50 rules in a background knowledge base that constrain the state changes.

Evaluation Setup: For every process, we first compute all the unique instances (i.e. sequence of tasks and events from beginning to the end of the process) and for each of these instances, we simulate the process execution by computing a normative trace (as defined earlier and in [15]). This is the base line simulation without any impediments, with each normative trace leading to a goal state (this is used to compute the success rate, i.e., the number of goal-satisfying instances divided by the number of distinct normative traces). Then we generate a sequence of impediments of length of \((n-1)\) where n is the number of tasks in the process instance, by randomly selecting impediments from \(I_p\). We insert one impediment after every completed task (except when the goal is realized after a task, which is when we force the simulation to stop).

We run three kinds of simulations:

  • Standard Process (execution): In this simulation, we use the exact sequence of tasks in the process instances (but with impediments inserted after every task) to see if, in a maximally adversarial environment, the process is still able to achieve its goal.

  • MCTS: Here, the next task for the process to execute is selected using MCTS. Again, one impediment will appear after each task unless after the task, the goal is achieved, or, there are no more impediments.

  • Minimax Tree Search The setup is the same with MCTS except the next task is selected using the minimax algorithm.

Fig. 2.
figure 2

Summary of result—simple process set

Full size image

Evaluation Results: Figure 2 shows a summary of the evaluation on the simple process set, where each row is the summary of instances of a process in the simple process set except the first row, which is a summary of all process instances. The number of available tasks indicates how many distinct tasks populate the capability library, which translates to the number of tasks that are used to construct the process model in the standard process simulation, and the number of “moves” for MCTS and minimax tree search to consider at each step (when it is the process players turn to make a move). The number of total process instances indicates the total number of process instances that have been simulated, where each instance uses the same sequence of impediments. The success counts record the number of times each method (standard process, MCTS, and minimax tree search) successfully achieves the goals of the process. The average simulation time measures the total time MCTS or minimax tree search takes to terminate in seconds (the termination means either the goal is realized or the two methods have used the same number of tasks compared to the standard process). The average decision time measures the average time taken by MCTS or minimax tree search to find the next best task to execute.

It is clear that the standard, predefined process is not reactive enough in this setting where the environment constantly acts against reaching a goal state. MCTS shows improvements in the overall success rate but minimax tree search is able to achieve the highest rate of success. The downside to using minimax search is the computational cost (average decision time).

For processes with simpler semantics (Process1, Process2, and Process3), minimax tree search makes a decision much faster compared to MCTS, and the time spent increases when there are more available tasks to evaluate for both methods. However, for processes that have complex semantics (larger number of rules in the knowledge base and larger sets of assertions in the postconditions of each task, as exemplified by Process4, Process5, Process6, and Process7), the time spent by minimax tree search increases dramatically, and minimax tree search takes longer than MCTS except for Process6. Process6 is a special case, possibly because the set of rules in the knowledge base create a simpler problem for the underlying reasoning machinery to solve. Overall, in all 294 process instances, it is clear that MCTS is more efficient for large complex processes. Minimax tree search achieves a higher success rate, but can take a very long time to decide on the next best move for large complex processes.

Fig. 3.
figure 3

Success rate—complex processes

Full size image
Fig. 4.
figure 4

Average decision time (seconds)—complex processes

Full size image

The next set of results involve the complex set of processes. The major issue in conducting this evaluation was that the minimax tree search took more memory than available (2 GB) in the experimental setup leading to the simulation be terminated. Consequently, we are only able to complete a small number of simulations successfully given the time and space limitation with the unoptimized prototype used in the evaluation. Some of the issues we had with the more complex process models can be overcome by optimizing the game tree search as well as the actual implementation, which is beyond the scope of this paper. Figure 3 show the success rate of the 3 methods, and Fig. 4 illustrates the time taken by MCTS and minimax tree search to select the next task to execute, which shows that MCTS is able select tasks relatively quickly to achieve a more than 80% chance of success.

5 Related Work

Process flexibility has long been recognized as an issue in real world business process management [19,20,21,22,23]. Part of the existing literature on process flexibility addresses flexibility by design [24], including exception handling [22], or achieving minimal deviation from a design during execution [15]. Other parts of that literature addresses flexibility at runtime [25], by taking into account risk [26], by generating optimized enactment plans given multiple optimization objectives [27] and in contexts where processes are human-driven [28]. Agent technology has also been used to model flexible processes, as the agent architectures are designed to deal with a flexible environment [20]. Schuschel and Weske adapt planning algorithms developed in the agent community for process planning [29]. Our approach is effective in anticipating impediments and devising workarounds, issues which most existing proposals tend not to address.

6 Conclusion

This paper highlights a hitherto under-explored connection between game-tree search and business process management. Preliminary results suggest that incorporating a game-tree search based module which reconsiders the intended flow of a process in view of likely conditions that might occur in the operating environment which might impede the process can lead to more robust processes that achieve their goals despite these impediments.