Deriving Decision Models from Process Models by ... - CiteSeerX

Deriving Decision Models from Process Models by Enhanced Decision Mining Ekaterina Bazhenova and Mathias Weske Hasso Plattner Institute at the University of Potsdam {ekaterina.bazhenova,mathias.weske}@hpi.de

Abstract. Optimal decision making during the business process execution is crucial for achieving the business goals of an enterprise. Process execution often involves the usage of the decision logic specified in terms of business rules represented as atomic elements of conditions leading to conclusions. However, the question of using and integrating the process- and decision-centric approaches, i.e. harmonization of the widely accepted Business Process Model and Notation (BPMN) and the recent Decision Model and Notation (DMN) proposed by the OMG group, is important. In this paper, we propose a four-step approach to derive decision models from process models on the examples of DMN and BPMN: (1) Identification of decision points in a process model; (2) Extraction of decision logic encapsulating the data dependencies affecting the decisions in the process model; (3) Construction of a decision model; (4) Adaptation of the process model with respect to the derived decision logic. Our contribution also consists in proposing an enrichment of the extracted decision logic by taking into account the predictions of process performance measures corresponding to different decision outcomes. We demonstrate the applicability of the approach on an exemplary business process from the banking domain.

1

Introduction

Business process management is a widely adopted concept for managing an enterprise work. Making the right decisions during the business process execution is important for achieving the strategical and operational business goals [7, 13]. The OMG group recently published the Decision Model and Notation (DMN) standard [17] that is supposed to complement BPMN for decision logic modeling and execution. However, an extra effort is needed to identify and implement integration of already existing and widely used process modeling and execution approaches with the new decision modeling standard. BPMN describes an end-to-end process as a flow of tasks, but the internal decision logic is often hidden in the process model in the form of implicit data dependencies, which makes it harder to derive the decision logic in an automated way [21]. In our paper, we address this issue by introducing an approach consisting of derivation of decision models from process models and execution logs on the examples of DMN and BPMN [16]. In particular, we derive the decision logic in the form of decision tables from the event logs of a process model. Based on the derived decision logic, we show the way to construct a corresponding DMN decision model.

2

Ekaterina Bazhenova and Mathias Weske

In the context of decision making in the business processes, often the strategic information is required, like, for example, knowledge about the time or risks associated with alternative actions to be taken. Deriving the decision logic, we also take into account the predictions of process performance measures corresponding to different decision outcomes, which is our another contribution. The rest of the paper is structured as follows. In Section 2, we present a use case from the banking domain describing the process of deciding if to give a credit to a client. In Section 3, we provide the formal foundations needed for deriving the DMN decision model from the event log of a given process model as presented in Section 4. This is followed by an application of the approach to the use case in Section 5. Finally, Section 6 presents related work, and Section 7 concludes the paper.

2

Motivating Use Case

In this section we provide a description of the business process from the banking domain, to which we refer throughout the rest of the paper. The corresponding business process model is presented in Fig. 1; it is based on a step-by-step approach that is genCredit erally scoring - plus while Creditassessing Bureaua personal loan [20]. followed Estimated case time

supplies clientID

Request to check if the account is eligible for credit

Case record

Account balance; Account duration; Strategy Nationality Case record

Case record

Spent case time

Eligibility local

Local evaluation

Prepare evaluation report

Case record

Case record

yes Record estimated case time

Collect application data

Decide evaluation strategy

Strategy? Applicant Risk Score

Decide account eligibility

Eligible? no

bureau

Outsource evaluation to credit bureau

Prepare rejection letter

Record spent time

Send prepared documents

Fig. 1. Process model showing the example business process of assessing the credit

Upon receiving the request to check if the account is eligible for a credit, the bank worker firstly enters the estimated case time in the case record and then collects application data such as account balance, account duration, nationality, and registers it in the same case record. Afterwards, an expert decision is made about the evaluation strategy of the case: should it be done locally, or outsourced to a credit bureau. Presumably, there are guidelines identifying how the application risk score is assigned in the case of local evaluation; in the case of the credit bureau evaluation, the algorithm is not known. The process follows with an account eligibility decision, noted by a corresponding case recording. In case of a positive decision, the worker prepares an evaluation report, otherwise, a rejection letter. The process finishes after the worker sets the spent case time in the case record. Fig. 1 is a typical representation of a process model that is not aware of decisions. For example, the model contains textual annotations and decision activities which incorporate the business logic that is not represented explicitly in the model. It is not difficult to imagine that upon expanding, such process models quickly become complex, and the business logic management becomes tedious. For understanding what would be a decision-aware process model in this case, we need to refer to the context of the business process. Nowadays there exist two main types of credit evaluation: (1) judgmental credit-evaluation systems, which may rely

Deriving Decision Models from Process Models by Enhanced Decision Mining

3

on the subjective evaluation of loan officers; and (2) credit-scoring systems that are empirically derived [5]. Basically, it has been settled in literature that using scoring in credit evaluation rules out personal judgment. In credit scoring systems, the decision are taken, depending on the applicant’s total score, whilst in personal judgment this issue is neglected. The decision here depends on decision-makers’ personal experience and other cultural issues, which vary from market to market [1]. With that, the brute force empiricism that characterizes the development of credit scoring systems can lead to a treatment of the individual applicant in an unjust manner; an example of such an occasion is judging the applicant’s creditability by the first letter of a person’s last name [6]. Thus, it seems reasonable to use automated credit scoring systems complemented with an explanatory model. The derivation of DMN decision model corresponding to this process model could provide such an explanatory model considering the past experiences, as the goal of the DMN standard is to provide basic principles and rules of thumb for organizing process models to maximize agility, reuse, and governance of decision logic in BPM solutions [21]. We demonstrate the derivation of such a model specific for the use case in Section 5.

3

Formal Framework

With respect for deriving the decision model from the process model and its execution log, we firstly review the most common ways to express decisions in process models. One of the most widely used decision construct is the exclusive gateway. It has passthrough semantics for exactly one out of a set of outgoing paths if the associated condition, a Boolean expression, evaluates to true [16]. Thus, a gateway does not ”decide” anything; it just specifies the path taken by a process instance based on existing process data. For example, in Fig. 1 the evaluation strategy decision is taken in the activity preceding the corresponding gateway, which only uses the result of this decision. Additionally, in our previous work [4], we identified further decision structures in process models, through analysis of 956 industry process models from multiple domains. We discovered that a single splitway pattern is a common decision pattern, which was used in 59% of the models. For this paper, we use the notion of a Decision point [19], which corresponds to this single split gateway from our previous work. With that, we assume that the decision task preceding any decision gateway refers to the same business decision (the omission of this decision task is a common mistake made by inexperienced BPMN users [21]). Next, we provide the formal grounding distinguished into process modeling and decision modeling formalisms. We formally define the concepts of process model and decision point as follows. Definition 1 (Process Model). Process model m = (N, D, Σ, C, F, α, ξ) consists of a finite non-empty set N of control flow nodes, a finite set D of data nodes, a finite set Σ of conditions, a finite set C of directed control flow edges, and a finite set F of directed data flow edges. The set of control flow nodes N = J ∪ E ∪ G consists of mutually disjoint sets J ⊆ T ∪S of activities being tasks T or subprocesses S, set E of events, and set G of gateways. C ⊆ N × N is the control flow relation such that each edge connects two control flow nodes. F ⊆ (D × J) ∪ (J × D) is the data flow relation indicating read respectively write operations of an activity with respect to a data node. Let Z be a set of control flow constructs. Function α : G → Z assigns to each gateway a type in

4

Ekaterina Bazhenova and Mathias Weske

terms of a control flow construct. Function ξ : (G × N ) ∩ C 9 Σ assigns conditions to control flow edges originating from gateways with multiple outgoing edges.  Definition 2 (Decision Point). Let m = (N, D, Σ, C, F, α, ξ) be a process model. Then dp = (N 0 , D0 , Σ 0 , C 0 , F 0 , γ, σ) is a decision point of process model m if the following holds: 1. dp is a connected subgraph of process model m such that N 0 ⊆ N , D0 ⊆ D, Σ 0 ⊆ Σ, C 0 ⊆ C, and F 0 ⊆ F ; 2. Functions γ and σ are restrictions of functions α and ξ respectively with corresponding new domains; 3. |Gdp | = 1 ∧ |g • | ≥ 2 ∧ (γ(g) = XOR ∨ γ(g) = IOR), g ∈ Gdp (the decision point contains exactly one split gateway), 4. |Jdp | = |g • | + 1 (the number of activities of dp equals the number of outgoing edges1 of the split gateway g plus 1), 5. •g = t ∧ | • g| = 1, t ∈ Tdp (task t is the only predecessor of the split gateway), 6. | • t| = 0 (task t is the start node of dp), 7. ∀j ∈ Jdp \t : •j = g (all activities other than the one preceding the split gateway g directly succeed g), 8. ∀j ∈ Jdp \t : |j • | = 0 (all activities other than the one preceding the split gateway g are end nodes of dp), and 9. ∀j ∈ Jdp \t, c ∈ Cdp such that (g, a) = c : σ(c) ∈ Σdp (all outgoing edges of the split gateway are annotated with a condition).  We use subscripts, e.g., Jm or Ndp , to denote the relation of sets and functions to process model m, decision point dp, etc., and omit the subscripts where the context is clear. Fig. 2 presents two corresponding decision points with two alternative paths at the split gateway from the use case presented in the previous section. According to our assumption, the decisions are taken in the tasks preceding the gateways. In both of the decision points, since the gateway is of the type XOR, only one alternative can be chosen. In Decision Point 1 (dp1 , left part of the figure), based on the result of the task Decide evaluation strategy, different credit evaluation strategies are chosen (local or outsourcing to credit bureau). In Decision Point 2 (dp2 , right part of the figure), based on the result of task Decide account eligibility, only one of the alternative activities is executed: the preparation either of the evaluation report, or of the rejection letter. local

Decide evaluation strategy

Strategy? bureau

Local evaluation Outsorce evaluation to credit bureau

yes

Decide account eligibility

Eligible? no

Prepare evaluation report Prepare rejection letter

Fig. 2. Decision Points 1 and 2 referring to Fig. 1

As decisions are happening within the scope of process models, it is important to take into account the process-related context. For deriving decisions, we propose to take into account in the context of a particular decision rule the quantifiable measures called Key Performance Indicators or KPIs. In our approach, we assume that the values of the KPIs are associated with the single activities of all the decision points of a process model. 1

the number of outgoing (incoming) edges directly translates to the number of direct successors (predecessors) and vice versa

Deriving Decision Models from Process Models by Enhanced Decision Mining

5

Definition 3 (KPIs of Alternatives in a Decision Point). Let DP = {dp1 , . . . , dpM } be a set of M decision points of a process model m. Then K = {K1 , . . . , Ki } is a set of i ∈ N+ key performance indicators (KPIs) if there is a function ψ : (tdpj • ×K) 9 R, 1 ≤ j ≤ M , which assigns the value of a given KPI to the tasks succeeding a gateway (alternatives) in each of the decision points of the process model.  Our proposal is to enrich the business rules obtained by the decision mining in the previous section, by considering the values of the KPIs corresponding to the activities of a decision point. We will look at this in detail in Section 4. DMN defines two levels for modeling decision logic, the decision requirements level and the decision logic level. The first one represents how decisions depend on each other and what input data is available for the decisions; these nodes are connected with each other through information requirement edges. A decision may additionally reference the decision logic level where its output is determined through an undirected association. The decision logic level describes the actual decision logic applied to take the decision. Decision logic can be represented in many ways, e.g. by a function or a decision table. In this paper, we utilize decision tables. Definition 4 (Decision Requirement Diagram). Decision requirement diagram drd = (Ddm , ID, IR) consists of a finite non-empty set Ddm of nodes called decisions, a finite set ID of input data nodes, and a finite set of directed edges representing information requirements: IR ⊆ {ID, Ddm } × Ddm .  Definition 5 (Decision Table). Decision table dt = (I, O, R) consists of a finite nonempty set I of inputs, a finite non-empty set O of inputs, and a list of rules R, where each rule is composed of the specific input and output entries of the table row.  Examples of the decision models will be given further in the paper (e.g., in Fig. 4); decisions are rectangles, input data are ellipsis, information requirement edges are solid, and the decision table associations are dashed.

4

Algorithm

Derivation of the Decision Model

In this section we propose the following step-by-step approach to derive decision models from process models. We demonstrate each step of the approach on the examples of BPMN process models and DMN decision models. The algorithm is expressed through BPMN process model, as shown in Figure 3. Process model

1. Identify decision points

Decision points

Decision model

Event log

2. Find decision logic

3. Construct decision model

Adapted process model

4. Adapt process model

Decision tables

Fig. 3. Algorithm of derivation of the decision model and adaptation of the process model

The inputs to the algorithm are the process model m and the corresponding event log which contains the values of data object attributes assigned during the process execution. For concrete example of logs, see Section 5. The goal of the algorithm is to get

6

Ekaterina Bazhenova and Mathias Weske

the outputs: (1) The decision model consisting of one decision requirements diagram and corresponding decision tables; and (2) The adapted process model m0 , in which the described decisions are referenced by a business rule task. In order to simplify the algorithm explanation, we assume for the rest of this chapter, that each decision point of the input process model m contains only two outgoing control flow paths and, correspondingly, two alternative tasks to be executed, so that |g • | = 2. The extrapolation of the algorithm for an arbitrary finite set of control flow paths and corresponding tasks will be presented in future work. Below we describe the actual algorithm step-by-step. Step 1. Identify decision points. Firstly, the decisions points are identified in the input process model, accordingly to Definition 2: given a process model m, we determine constructs of directly succeeding control flow nodes that represent a gateway preceded by a task and succeeded by a task on each of the outgoing paths. The step output is a set of M decision points DP = {dp1 , . . . , dpM } corresponding to a process model m. Step 2. Find decision logic. The decision logic is extracted in the form of decision tables from a given process model m and a corresponding execution log by following the substeps below: 2-A. We firstly build a control-flow based skeleton of the decision model to be derived, therefore utilizing the algorithm from our previous work [4], see Fig. 4. [BPMN] decision point dpi

d’

t

c1

t

[DMN] decision model

a1 g

c2

Inputs Outputs g output t output c1 o1 c2

g

-

a2

d’

o1

t table (dti‘’)

Inputs Outputs g output t output

t

c1

-

c2

g table (dti‘)

Fig. 4. Control-flow based mapping of a BPMN decision point and DMN decision model

o1

c2

o2

t table (dti‘’)

g

Inputs

g output

-

c1

d’

A1

...

Aw

Outputs ind g output

op q 1 ... op q w op 0 c 1 V c2 ... ... ... ... ...

g table (dti‘)

Fig. 5. Enhanced decision model in case of 2 alternatives

The skeleton of the DMN decision model extracted from the arbitrary decision point dpi of the process model m in Fig. 4 demonstrates that there are two decision tables to be considered. The first one is a decision table dt0i which basically does not ”decide” anything, as there are no rules for that; it reflects that the decision is chosen non-automatically (e.g., the case of judgmental credit evaluation systems). The second decision table dt00i refers to the top-level decision and reflects the rule of process routing (o1 and o2 would be labels of the edges following the gateway of the decision point in the refactored model) after the strategy output was determined. What is of interest, is how to mine the meaningful explanatory business rules which will replace the dashes in dt0i table (see Fig. 4). 2-B. Given is a process model m containing corresponding set DP = {dp1 , . . . , dpM } of M decision points. Let d0 = (A1 , . . . , Av ), v ∈ N∗ be a data node of the decision point which consists of the attributes Ai , 1 ≤ i ≤ v. The concrete values of these attributes are stored in the process execution log. The decision outcomes of the decision point cl ∈ Cdp = (c1 , . . . , cs ), where s, l ∈ N+ , 1 ≤ l ≤ s are associated with control flow edges following the decision point gateway. The step outcome to be achieved

Deriving Decision Models from Process Models by Enhanced Decision Mining

7

is the identification of the attributes (A1 , . . . , Aw ), 1 ≤ w ≤ v which have statistical correlation with the variable c in the log, which can be done, e.g., with the help of the correlation analysis. 2-C. Following the identification of the attributes which statistically correlate with the variable c, is the decision rule extraction in the following form: A1 op q1 , . . . , Aw op qw −→ cl , where op is a comparison predicate and q is a constant. The concrete implementation of such extraction, e.g., with the help of the decision trees, can be found in [19]. This step is concluded with plain transformation of the decision rules into a decision table dt0 (decision table dt00 contains user-made decisions, which can not be automatized with the help of rules as described above). The obtained table can be further contracted and minimized, e.g., following the techniques from [3]. 2-D. The rules extracted at the previous step explain what happened in the past. However, taking into account the predictions of the values of KPIs of the alternatives to be taken based on their historical values recorded event log, can potentially improve what will happen. To achieve this, the enrichment of the rules utilizing the KPIs of the alternatives in the decision point (see Definition 3) is done at this step. Given is K = {K1 , . . . , Ki }, a set of i ∈ N+ key performance indicators (KPIs) which assigns the value of a given KPI to the tasks succeeding a gateway in each of the decision points of the process model. Let ind be a variable indicating the performance of which alternatives in the decision point is better: ind = P (suma2 ) − P (suma1 ), where P (sumai ) is a predicted value calculated as the expected value of the KPIs based on the historical records in the event log. In order to aggregate the values of KPIs, it is i P common to use the total performance function which sums them [18]: sum = Kj . j=1

Taking into account the business goal is to maximize the total performance function, the decision rules extracted at the previous step, can be modified in the following way: 1. A1 op q1 , . . . , Aw op qw , ind > 0 −→ cl , l = 1, 2 2. A1 op q1 , . . . , Aw op qw , ind < 0 −→ ¬cl , l = 1, 2 In such a case, the mapping of the BPMN decision point from Fig. 4, will be refined as shown in Fig. 5. The concrete numerical examples for the rules enriched with predictions of the KPIs of alternatives in the decision point can be found in Section 5. Step 3. Construct decision model. After the decision tables are identified for each decision point, the compound decision model of the whole process model can be constructed. The basic structure of the DMN elements corresponding to the decision point in the process model, is shown in Figures 4 and 5. However, this mapping is not considering yet the data and decision dependencies in the process model. We suggest three complementing steps for completing the decision model, as described below. t1

t2

3-A

t1

t2

t

t

t

3-B

g1

g2

g1

g2

g

D’1

D’2

D’1

D’2

D’

g

g A1

...

Aw

D’

t

3-C

g (recommended)

D’

Fig. 6. Improvement of mapped elements of decision points

3-A. Let us assume that 2 arbitrary decision points dp1 and dp2 are found in a process model m, and dp2 follows dp1 . The attributes which strongly correlate to the corresponding variables cdp1 and cdp2 were identified as an output from the previous step:

8

Ekaterina Bazhenova and Mathias Weske

Adp1 = (A1 , . . . , Awdp1 ) and Adp2 = (A1 , . . . , Awdp2 ). If there exist at least one attribute y ∈ N+ , such that Ay ∈ Adp2 \ Adp1 and Ay ≡ ox , x ∈ N+ , where ox is the output of dp1 , then there is a data dependency between the top level decision tdp1 and the gateway (data-based) decision g. In such a case, in the resulting DMN diagram there should be a corresponding information requirement (directed edge) inserted (left fragment in Fig. 6). 3-B. As the decision model needs to be explanatory, we suggest to replace the input data node corresponding to the mapping of a decision point to a decision model (described on the previous step) by w input data nodes, the names of which correspond to the attributes (A1 , . . . , Aw ), w ≤ v which correlate statistically with the decision (central fragment in Fig. 6), in this manner they ”explain” the decision. 3-C. At last, we suggest to concatenate the name of the gateway decision g in the resulting decision model with the string ”recommended”, so that the difference between the gateway and the top-level decision is clearer for the user: in the first case, the business rule is triggered, and in the second case, the actual decision is taken (either automatically, or manually), and the automated process routing happens (right fragment in Fig. 6). Step 4. Adapt process model. After deriving the decision logic from a process model to a decision model, the process model needs to be adapted in order to be consistent together with the decision model. Basically, the entire decision logic is hidden inside of the first decision task of the decision point. For that purpose, BPMN offers business rule tasks that can be linked to decision models and that will output the value of the top-level decision of the decision model.

5

Application to Use Case

The approach is evaluated by showing its applicability to a credit assessment use case introduced in Section 2. An exemplary process execution log can be seen in Figure 7; it is constructed analogously to the real-life German credit data set publicly available2 . For applying the algorithm introduced in the previous section, we consider two KPIs caseID

esT

accB

accD

ifF

strategy

eligibility

1 2 3 4 5 6 7 8

20 18 22 19 20 21 22 17

2500 4720 1600 150 800 590 430 4200

3 1 1 5 1.5 3 1 4

≠F F ≠F ≠F F F ≠F F

local bureau local local bureau bureau local local

Y N N Y N N Y Y

KPI1 (time) 0.35 0.42 0.41 0.37 0.45 0.42 0.31 0.33

Risk score Parameter points Account balance ≥500 0.02 2 > 1000 > 2 > 1000 < 2 > 1000 < 2 < 1000 > 2 < 1000 > 2 < 1000 < 2 < 1000 < 2

Outputs ifF strategy ≠F local = F bureau ≠ F bureau = F bureau ≠F local = F bureau ≠F local = F bureau

Rule No 1 2 3 4 5

Inputs accB accD > 1000 > 2 > 1000 > 2 > 1000 < 2 < 1000 < 1000

ifF ≠F =F ≠F =F

Outputs strategy local bureau bureau local bureau

Rule No ifF 1 ≠F 2 3 4 =F

Outputs Inputs accB accD strategy > 1000 >2 local > 1000 2 ∧ accB > 1000 −→ strategy = local” is 95%, and the coverage of the rule ”if F 6= F ∧accD > 2 ∧ accB > 1000 −→ strategy = bureau” is 5%. In the classical mining, only one 3

The Decision Miner, which is embedded in the ProM framework, can be downloaded from www.processmining.org

10

Ekaterina Bazhenova and Mathias Weske

rule with the highest coverage that satisfies a given threshold will be chosen. However, let us consider the process instance execution, recorded in the event log as shown in Fig. 11. The case of local evaluation whether the client is eligible for a credit takes less time than in the case of requesting credit bureau to do the evaluation. With that, the risk score assigned by the credit bureau is lower than the risk score which would be assigned by local evaluation. We assume as described in the previous section, that the total performance is measured by summing the KPI values, and in such a case, it can be seen that outsourcing the evaluation to a credit bureau results in a better process performance. With that, if we simply followed the rule obtained by classical mining (Fig. 10, top right), then we would have to execute the process in a way which would result in a worse performance. However, an enrichment of the decision rules with the KPIs predictions (Fig. 10, bottom right), a rule leads to a better process performance. local evaluation

coverage=95% Outputs “classical” decision Inputs rule mining ifF accD accB strategy local ≠ > 1000 >2 F coverage=5% Outputs Inputs ifF accD accB strategy enrichment of the decision rules with ≠ F > 1000 >2 bureau the KPI predictions

ifF ≠F

Outputs Inputs accD accB strategy > 1000 >2 local

Outputs Inputsacc ifF accD B ind strategy ≠ F > 1000 >2 ≥0 local ≠ F > 1000 >2