Modeling information gathering for decisions in business processes

Abstract

While process models typically contain decisions, the common view is that decision aspects of business processes are best modeled separately from the process behavior to achieve reuse and reduce complexity. To facilitate this, Decision Model and Notation (DMN) has been proposed as standard for modeling decision points in processes, complementing standards for process modeling such as Business Process Model and Notation (BPMN) and Case Management Model and Notation (CMMN). Decisions are taken based on input information elements, which are gathered in the process steps leading to a decision point corresponding to the decision. While research has been performed on integrated modeling of business processes and their decisions, there is less research on how to model information gathering for decisions in business processes. This paper discusses diferent strategies for information gathering for decisions in business processes, ranging from structured to flexible. Structured information gathering strategies can be encoded in process models, while flexible approaches compute eficient information gathering strategies based on decision support techniques.

Keywords

• eol>Business Process Modeling
• Decision Modeling
• Flexibility
• Context
• Knowledge-intensive Processes

1. Introduction

Many business processes contain decisions, which are essential to reach process outcomes. While decisions can be modeled to a certain extent in process models, it has long been recognized that for the purpose of decision management it is better to model decisions separate from the business processes in which the decisions are used [ 1 ]. Consequently, the Decision Modeling and Notation (DMN) has been proposed as modeling standard for decision making in business processes [ 2, 3 ]. DMN is compatible both with Business Process Model and Notation (BPMN) [ 3, 4 ], for procedural structured business processes with automated, repeatable decision making, as well as Case Management Model and Notation (CMMN) [ 5 ], for more loosely specified, knowledge-intensive business processes. According to the DMN standard [ 2 ], human decision making is best modeled with Decision Requirements Diagrams.

Decisions are taken based on pieces of information, which we call information elements in this paper. Not all information elements required for a decision may be available at the start of the process instance. Therefore, before making a decision, typically information elements need to be gathered. A tacit assumption made in many modeling approaches, for instance BPMN [ 4 ] and DMN [ 2 ], is that all relevant information elements need to be gathered before a decision is made. However, if a decision is very complex or needs to be made under time pressure, collecting all information elements is neither feasible nor useful. Also, information gathering can be costly. In all these cases, it makes sense to explicitly consider what information to gather at what point.

This paper discusses diferent strategies for gathering information elements for decisions in business processes. Structural information gathering strategies are specified in the process model accompanying a decision models, based on the structure of the decision model as specified in DMN. They require that all relevant information elements for a decision are gathered. Advanced information gathering strategies are also based on the structure of the decision model, but allow that only some of the information elements for a decision are gathered. Both the structural and advanced information gathering strategies are expressed at design-time in the modeling languages defining the business processes, for the purpose of this paper BPMN and CMMN. Finally, we also discuss two existing guidance approaches that compute eficient information gathering strategies based on decision support techniques such as decision trees and Markov Decision Processes (MDPs). These approaches help users to be eficient and flexible in gathering information at run-time by taking into account the decision context in a process.

The remainder of this paper is structured as follows. Section 2 gives background on integrated process and decision modeling using DMN, BPMN and CMMN. Section 3 introduces strategies for information gathering based on the structure of the decision model. Section 4 discusses strategies for advanced information gathering. Section 5 reviews two existing approaches that guide information gathering by computing an eficient information gathering strategy. Section 6 ends the paper with discussion and conclusion.

2. Integrated decision and process modeling

Decision Model and Notation (DMN) [ 2 ] specifies decisions and the input information elements (called input data in DMN) used in the decisions at the diferent levels of detail. At the highest level, Decision Requirements Diagrams (DRDs) specify the decisions (rectangles) and the input information elements (ovals) that are used to make the decisions. There can be subdecisions; for instance, in Figure 1 both Risk and Afordability are subdecisions of Eligibility. The outcomes of these subdecisions are input for the Eligibility decision. DMN also allows the specification of knowledge sources and flows in DRDs, but these are not used in the sequel of this paper.

If more details about the decision making is required, so how decision outcomes are determined, the decision logic can be specified, either using a formal expression or a decision table. In this paper, we focus on decision tables. Table 1 shows a decision table for the Eligibility decision in Figure 1. In this decision table, each numbered row specifies a decision rule, consisting of the values of the three input information elements, where ‘-’ means that the value is not relevant, and decision outcome (last column). The hit policy A(ny) specifies how the rules are processed, but hit policies are not relevant for the purpose of this paper, and therefore not discussed.

While DRDs specify in a declarative way the information needs of decisions, they do not specify how this required input information is gathered. This information gathering aspect is handled in business processes, in which the decision specified in DMN are embedded as decision points. While diferent process modeling language have been proposed in the past decades, we focus on the process modeling standards that are intended to be used in tandem with DMN, namely Business Process Model and Notation (BPMN) [ 4 ] for procedural-style process models to handle routine work, and Case Management Model and Notation (CMMN) [ 5 ] for more declarative, flexible process models that are performed by knowledge workers. In both languages, tasks (visualized as rounded rectangles) are used to gather or compute information. In BPMN, data objects (paper symbol) and data flows (dashed arrow) can be used to specify input and output information elements of tasks (see Figure 2). In CMMN, data objects (paper symbol) can be specified, but not data flow, since all available information elements are assumed to be present in a case file that can be accessed by the entire process (see Figure 3). Small diamonds indicate entry conditions for a task in CMMN.

Both languages use a special type of task, called a business rules task in BPMN and a decision task in CMMN, that links to an external decision activity that can be specified in a DMN decision model [ 2 ]. Input information elements for the decision activity are gathered in the process in which the decision is embedded. Before the decision activity can be invoked, all required information elements should be present.

The topic of integrating decision and process modeling has been studied before. The DMN standard [ 2 ] provides some guidance on how a BPMN model and a DMN model can be linked. In addition, several detailed guidelines have been developed for aligning DMN models with BPMN models [ 6, 7 ] and CMMN models [ 8 ]. Other approaches have been proposed for extracting a DMN model from a BPMN model [ 9 ] and for integrated analysis of DMN and BPMN models [ 10 ]. DMN concepts have also been integrated with a declarative process modeling language [ 11 ]. However, all these approaches do not explicitly consider how information elements that are relevant for a decision are gathered.

3. Structural information gathering

We outline two strategies for information gathering based on the structure of decision models. The first one takes into account only DRDs, the second both DRDs and decision tables.

3.1. Standard information gathering

A DRD specifies information requirements for a decision, i.e., which information elements and which decisions are input to the decision. The default strategy is gathering all information elements that are needed as input for a decision, as specified in the DRD. So for each decision instance, the same information elements are gathered. Note that the DRD specifies what information elements are needed, but not in which order they need to be gathered. An accompanying BPMN or CMMN model can specify this information gathering order.

In BPMN, information is gathered in a procedural way. For instance, the BPMN model in Figure 2 specifies possible information gathering for the DRD in Figure 1: first three information elements are collected, after which a subdecision on risk is taken, then another information element is gathered, after which the subdecision on afordability is made, such that the final decision on eligibility can be taken. Note that alternative BPMN models are compatible with the DRD in Figure 1, like one in which the task Decide risk is performed after Decide afordability , and one in which these decision tasks are performed in parallel before Decide eligibility.

In CMMN, information gathering can be specified in a more declarative way. Figure 3 shows a CMMN model for the DRD in Figure 1; other CMMN models are compatible with Figure 1. Note that CMMN does not allow to model the input and output flow of information elements, as we explained in Section 2.

3.2. Value-based information gathering

If the decision logic is known, structural information gathering can be done in a more finegrained way. The decision logic can reveal that not all inputs are needed for each decision outcome. If an input is not required for a specific outcome, it is shown in a decision table with a hyphen. For example, Table 1 shows the decision logic of the Eligibility decision in Figure 2. If the age of the applicant is younger than 18, the two sub decisions concerning Risk and Afordability are no longer relevant. Still, the three other information elements for the Eligibility decision need to be gathered even in that case according to Figure 2.

To allow for more fine-grained information gathering, one option is to use an advanced DMN engine, which allows that a decision only receives partial input [ 12 ], so some of the input information elements. But if the BPMN model is not changed, still all information elements are gathered for the decision. To allow that a decision is already taken if suficient information elements with appropriate values are available, the BPMN model needs to be adjusted, as shown in Figure 4 for the Eligibility decision specified in Table 1. The value-based strategy can also be used in CMMN, but due to space limitations no example is provided here.

Note that from a process modeling point of view, the BPMN model in Figure 4 can be viewed as bad practice, since it encodes part of the decision logic of the DMN model. However the BPMN model does provide a gain in throughput time compared to Figure 2, since for underage applicants no longer the subdecisions are needed. Also, if for instance monthly income is not directly available and costly to gather, it does not need to be gathered if the applicant is underage, so eficiency in general is achieved this way.

4. Advanced information gathering

In the previous section, we focused on decisions that have fixed inputs and decision logic. In this section, we study information gathering for decisions that are more flexible. First we focus on decisions having optional inputs, next on decisions that are based on a specific context.

4.1. Optional information gathering

DRDs specify structural decisions, meaning that the decision requirements are fixed and all inputs are mandatory. But some decisions can be more flexible, in the sense that some information elements are optional: they are not always available. DMN does not support such kind of decision requirements; we propose to model them in DRDs using arrows with an open circle at the opposite end of the arrow. For instance, Figure 5 shows a DRD in which the information element Credit history is optional input.

An optional information element can mean diferent things. From the point of view of the information supplier, an optional information element is not always available. For the decision in Figure 5, perhaps the client comes from a foreign country and the bank does not know yet the credit history. If the information element is not available but required for decision making, its value can be imputed [ 13 ] before the decision logic is activated. For instance, for the Risk decision in Figure 5 the credit score of a client can be imputed based on the credit scores of clients having similar profiles, as shown in Figure 6.

From the point of view of the decision, an optional information element can mean that the information element is nice to have, but not essential. In that case, if a decision uses the information element as input, two diferent versions of the decision logic can be specified: one with and one without the information element present. To illustrate this, Table 2 and 3 show two decision tables for the DRD in Figure 5, which can be viewed as two variants for the decision task Assess risk in the accompanying BPMN model in Figure 7. Task Assess risk uses two diferent input sets, one with and one without Credit score. Input sets are supported by BPMN, but cannot be visualized [ 4 ].

In a CMMN setting, a missing information element can be handled as explained above, but also by giving freedom to the user, i.e., a knowledge worker, how to deal with missing information elements. For instance, Figure 8 shows that a knowledge worker estimates the credit score; this task is enabled (the entry condition is not shown) if the credit history is missing. The triangle indicates that the knowledge worker needs to manually start this task, if relevant. However, the knowledge worker can also decide to skip (disable) this task if the credit history is missing. For that reason, still two versions of the decision logic are needed.

4.2. Contextualized information gathering

Context can afect the way processes are performed in diferent ways [ 14, 15 ], including decision making in business processes [ 16 ]. Typically, information about the context drives decision making in a business process [ 16, 17 ] and changes in context can lead to run-time adaptation of a process instance [ 18, 19 ], but in these cited approaches the information that is gathered does not depend upon the context.

But for some real-world business processes, the context also determines the information that needs to be gathered. For instance, part of the context of a loan application is the client who requests the loan. To decide upon a loan, the information that a bank collects about a selfemployed client difers from the information it collects about a client having a paid employment. So the client profile determines which information needs to be gathered for a loan decision. This can be expressed in DMN by using for each client profile a diferent DRD and a diferent process model in order to gather the requested information for that particular profile. This leads to diferent variants of the process models in which the loan decision is embedded.

However, there are also business processes in which the context is actually controlled by the process and the context can change because of information gathered during the process [ 20 ]. For instance, suppose that in diagnosing a female patient having abdominal pain, three diagnoses ofer likely explanations [ 21 ]. Each diagnosis can be viewed as a separate context that needs to be explored next by performing additional tests to decide upon a final treatment [ 21 ]; some tests are relevant for multiple diagnoses. Figure 9 shows a CMMN model of the corresponding information gathering process. There are five information gathering tasks; each task can be started or skipped by the knowledge worker coordinating the process. Next to each task the information element that the task produces is shown. Each information element is annotated with the diagnosis for which the information element is relevant. Since there are three alternative diagnoses, there are three possible ways to start the treatment, visualized by three diamonds.

A knowledge worker like a doctor can use the context annotations in Figure 9 to decide which information element to gather first. To aid his decision, it can be analyzed how much each information element contributes to each context [ 21 ]; by adding the diferent contributions, the overall contribution per information element can be computed (Table 4). For the example, Location and CBC data have the highest priority, since they contribute most to the diferent contexts. However, the knowledge worker can decide to first explore another information element that contributes less, for instance because of tacit medical knowledge and the observed condition of the patient.

5. Guidance for information gathering

While DMN specifies the information needs for decisions, it does not specify any additional requirements. In practice, it may well be that certain costs are associated with the information elements [ 22, 23 ]. For instance, if an information element is missing, it needs to be gathered at a certain cost, typically a time investment of an employee who could also work on other tasks. In that case, it makes sense to minimize the information gathering costs, without sacrificing quality. We next review two existing approaches that ofer guidance to users in information gathering for decision making in business processes [ 22, 23 ]. The guidance comes from decision support techniques and is not encoded in process models.

5.1. Decision tree guidance

The first guidance approach defines an optimal information gathering strategy for a given decision table [ 22 ]. The strategy is expressed as a decision tree, that orders the information elements. Based on the decision table, the costs for each information element to be gathered, and the frequency of the decision rules in the decision table, the approach computes a decision tree that prioritizes the information elements that need to be gathered such that the costs of information gathering are minimized.

To illustrate this approach, Figure 10 shows a decision tree for the decision table in Table 1. The tree ensures that not all information elements need to be gathered always. For instance, if the client is older than 18 and has a high risk, the afordability does not need to be computed.

While this approach resembles the value-based information gathering strategy outlined in Section 3, the key diference is that the decision tree is complementary to the process model, while the value-based information strategy specifies information gathering solely in the process model. Advantage of using a decision tree is that an optimal strategy can be computed.

This approach could be combined with the value-based information gathering strategy by incorporating the logic of the computed decision tree in the process flow. While this ensures optimal information gathering, such a process model is considered bad practice from a modeling point of view, since then the process model contains the actual decision logic in the process model. Note that with value-based information gathering, only a minor part of the decision logic is specified in the process model.

5.2. MDP-based guidance

The second guidance approach focuses on information gathering for knowledge-intensive decision making [ 23 ]. The motivation is that a knowledge worker prepares a decision by gathering relevant information, but that gathering all relevant information is typically too costly, while gathering too little information may deteriorate the quality of the decision. Based on the gathered information, the decision making itself is based on tacit knowledge, and therefore its decision logic is not modeled in decision tables.

The MDP-based approach for guiding information gathering [ 23 ] assumes past data about the decision making process. First, a function is defined that predicts the reward of the outcome of each decision outcome of the process. This function can be derived from the past process data using regression analysis for example. The function is used during the process to guide the user which information element to gather next. Based on the available information elements, and using expected values based on past business data for the unavailable information elements, the function can be used to compute whether it pays of to gather an additional information element or to stop gathering and make a decision. An optimal information strategy can be determined by casting this guidance problem in Markov Decision Processes (MDPs) and computing an optimal MDP policy. The MDP policy can be used to configure a recommender that guides users in when to gather what information for knowledge-intensive decision making [ 23 ].

The approach has been applied to a large quotation process of a service provider for aircraft components [ 23 ]. Figure 11 shows a screenshot of a decision support tool developed for this processs. Figure 11(a) shows a specific state of the process modeled in CMMN, divided in a user part in which information is gathered and a control part in which the decision which information to gather is made. Figure 11(b) shows which of the information elements (variables) have been gathered in the current state. Based on this current state, Figure 11(c) shows the estimated expected profit of each enabled task, to gather an additional information element (variable). The information gathering task in bold, In-house capability check, has the highest profit, but the user can choose another enabled task instead. A huge gain in eficiency was shown to be possible for this process [ 23 ].

Note that the information gathering process model (the upper part in the CMMN model of Figure 11(a)) contains no explicit strategy for information gathering. Similar to the decision tree approach outlined above, the MDP recommender augments the process model with guidance support for information gathering. Key diference with the decision tree approach is that decision trees are static: the ordering of the nodes in the tree is fixed. While the MDP recommender approach allows for more flexible information gathering, since the preferred ordering of gathering information elements can change depending on the value of an information element that is gathered next. Another diference is that the MDP approach supports a trade of how much information needs to be gathered to make a knowledge-intensive decision, while the decision tree approach aims to minimize the information gathered for a routine decision, whose decision logic can be expressed in decision tables.

6. Discussion and conclusion

We have outlined diferent approaches to support information gathering for decisions in business processes, based on the modeling standards DMN, BPMN and CMMN; Figure 12 positions them in a spectrum. Design-time approaches can be used to encode information gathering strategies in the process models accompanying the decision models. The encoded strategies are easy to understand and explain, since they are encoded in the process model. However, they are neither very eficient nor very flexible, since they they are not specific to a decision instance. Run-time approaches compute eficient information gathering strategies, based on decision support techniques such as decision trees and MDPs. These strategies ofer high flexibility and eficiency, since they take into account the specific decision instance and ensure that only design time run time standard value-based optional contextualized decision-tree

MDPs Low efficiency Low flexibility High understandability High efficiency

High flexibility Low understandability relevant information elements are gathered. But the information gathering is then not explicitly modeled in the process models, which makes the strategies less understandable and explainable for user performing the information gathering.

The approaches in Section 3 and 4 ofer design-time strategies, encoded in process models, while the guidance approaches in Section 5 provide run-time strategies. In theory, it is possible to use the guidance approaches to identify a best information gathering strategy that results in for instance the least costs on average, and to encode this specific strategy using one of the model-based approaches of Section 3 and 4. However, this will come at the expense of a loss of lfexibility for specific decision-instances, which is the strength of the guidance approaches to information gathering.

There are several directions for future work, for instance looking at fuzzy decision models to aid the information gathering, building upon fuzzified process models [ 24 ], or expanding upon contextualized decision making using DMN [ 17 ]. Another interesting direction for future work is further exploring the influence of regulatory policies on information gathering [ 20 ].

References

[1] J. Vanthienen , F. Caron , J. De Smedt, Business rules, decisions and processes: five reflections upon living apart together , in: Proc. SIGBPS Workshop on Business Processes and Services (BPS'13) , 2013 , pp. 76 - 81 .

[2] OMG, Decision Model and Notation (DMN), Version 1 .5, 2023 .

[3] T. Debevoise , J. Taylor , The MicroGuide to Process and Decision Modeling in BPMN/DMN, 2014 .

[4] OMG, Business Process Model and Notation (BPMN ), Version 2.0.2 , 2014 .

[5] OMG, Case Management Model and Notation (CMMN) Version 1 .1, 2016 .

[6] F. Hasic , J. D. Smedt , J. Vanthienen , Augmenting processes with decision intelligence: Principles for integrated modelling , Decision Support Systems 107 ( 2018 ) 1 - 12 .

[7] L. Janssens , E. Bazhenova , J. D. Smedt , J. Vanthienen , M. Denecker , Consistent integration of decision (DMN) and process (BPMN) models , in : Proc. CAiSE'16 Forum , volume 1612 of CEUR Workshop Proceedings, CEUR-WS.org , 2016 , pp. 121 - 128 .

[8] F. Hasic , L. Vanwijck , J. Vanthienen , Integrating processes, cases, and decisions for knowledge-intensive process modelling , in: D. Bork , D. Karagiannis , J. Vanthienen (Eds.), Proc. 1st International Workshop on Practicing Open Enterprise Modeling within OMiLAB (PrOse 2017 ), volume 1999 of CEUR Workshop Proceedings, CEUR-WS.org , 2017 .

[9] E. Bazhenova , F. Zerbato , B. Oliboni , M. Weske, From BPMN process models to DMN decision models , Information Systems 83 ( 2019 ) 69 - 88 .

[10] M. de Leoni , P. Felli, M. Montali , Integrating BPMN and DMN: modeling and analysis , Journal on Data Semantics 10 ( 2021 ) 165 - 188 .

[11] S. Mertens , F. Gailly , G. Poels, Towards a decision-aware declarative process modeling language for knowledge-intensive processes , Expert Systems with Applications 87 ( 2017 ) 316 - 334 .

[12] S. Vandevelde , V. Etikala , J. Vanthienen , J. Vennekens , Leveraging the power of IDP with the flexibility of DMN: A multifunctional API , in: S. Moschoyiannis, R. Peñaloza , J. Vanthienen , A. Soylu , D. Roman (Eds.), Proc. RuleML+RR 2021 , volume 12851 of Lecture Notes in Computer Science, Springer, 2021 , pp. 250 - 263 .

[13] W. E. Winkler , Methods for evaluating and creating data quality , Information Systems 29 ( 2004 ) 531 - 550 . Data Quality in Cooperative Information Systems .

[14] M. Rosemann , J. Recker , C. Flender , Contextualisation of business processes, International Journal on Business Process Integration and Management 3 ( 2008 ) 47 - 60 .

[15] R. Song , J. Vanthienen , W. Cui , Y. Wang , L. Huang , Towards a comprehensive understanding of the context concepts in context-aware business processes , in: S. Betz (Ed.), Proc. S-BPM ONE 2019 , ACM, 2019 , pp. 5 : 1 - 5 : 10 .

[16] A. Yousfi , A. K. Dey , R. Saidi , J. Hong , Introducing decision-aware business processes , Computers in Industry 70 ( 2015 ) 13 - 22 .

[17] R. Song , J. Vanthienen , W. Cui , Y. Wang , L. Huang , A DMN-Based method for contextaware business process modeling towards process variability , in: Proc. BIS 2019 , volume 353 of Lecture Notes in Business Information Processing , Springer, 2019 , pp. 176 - 188 .

[18] A. Marrella , M. Mecella , S. Sardiña , Intelligent process adaptation in the SmartPM system , ACM Transactions on Intelligent Systems and Technology 8 ( 2017 ) 25 : 1 - 25 : 43 .

[19] V. T. Nunes , F. M. Santoro , C. M. L. Werner , C. G. Ralha , Real-time process adaptation: A context-aware replanning approach , IEEE Trans. Syst. Man Cybern. Syst . 48 ( 2018 ) 99 - 118 .

[20] Z. Ozturk Yurt , R. Eshuis , A. Wilbik , I. T. P. Vanderfeesten , Context-aware modeling for knowledge-intensive medicinal product development processes , Software and Systems Modeling 22 ( 2023 ) 709 - 731 .

[21] Z. Ozturk Yurt , R. Eshuis , A. Wilbik , I. T. P. Vanderfeesten , Guiding knowledge workers under dynamic contexts , in: X. Franch , G. Poels , F. Gailly , M. Snoeck (Eds.), Proc. CAiSE 2022 , volume 13295 of Lecture Notes in Computer Science, Springer, 2022 , pp. 218 - 234 .

[22] E. Bazhenova , M. Weske , Optimal acquisition of input data for decision taking in business processes , in: Proceedings of the Symposium on Applied Computing , SAC '17, Association for Computing Machinery, 2017 , p. 703 - 710 .

[23] S. Voorberg , R. Eshuis , W. van Jaarsveld, G. J. van Houtum , Decisions for information or information for decisions? Optimizing information gathering in decision-intensive processes , Decision Support Systems 151 ( 2021 ).

[24] R. Eshuis , M. Firat , U. Kaymak, Modeling uncertainty in declarative artifact-centric process models using fuzzy logic , Information Sciences 579 ( 2021 ) 845 - 862 .