1 Introduction

In the modern information economy, knowledge work is the key activity associated with economic growth (Elliott & Jacobson, 2002). While different definitions of knowledge work exist, knowledge workers generally use their expertise and experience to identify and solve problems (Pyöriä, 2005). Thereby, knowledge workers make informed decisions, from which a solution emerges gradually (Ciccio et al., 2015).

Physicians are example knowledge workers. To treat patients, physicians gather information, for example, during anamnesis, examinations, and blood tests. Physicians decide on a treatment based on this data, their knowledge, and their experience. Yet, new knowledge—such as an adverse drug reaction—is gathered and may be used to adjust the treatment. Knowledge work also exists in other domains, e.g., during the claim handling at insurance companies.

Processes that are primarily concerned with knowledge work are called knowledge-intensive processes. They are data-centric, goal-driven, and multi-variant (Ciccio et al., 2015). Case management is a process management paradigm designed for such processes (Swenson, 2013). A case is concerned with a subject (e.g., the patient) in a situation (e.g., the disease), and the goal of the case is the resolution of the situation (e.g., the successful treatment) (Object Management Group, 2016). A challenge is that knowledge is often volatile and vast, so knowledge-intensive processes are unrepeatable and unpredictable (Ciccio et al., 2015; Swenson, 2013). Respective process models are often under-specified and may be adapted at run-time (Ciccio et al., 2015). This makes case management challenging.

Information systems can be used to gather and organize data. Process-aware information systems may also determine enabled activities, which are compliant with a process model (Weske, 2019). But, in knowledge-intensive processes, there may be many enabled activities (Ciccio et al., 2015). Information systems, in general, cannot determine which activities align with the goals of the knowledge worker. Instead, the worker has to be aware of their goals, enabled activities, and their relationship. This causes cognitive load and may lead to errors.

This gap leads to our research questions:

RQ1:

How can knowledge workers’ goals be specified using the explicit information available in process models and cases?

RQ2:

How can we determine enabled activities that align with modeled goals?

By determining activities that support a modeled goal, knowledge workers receive decision support: Activities that contradict a goal do not need to be considered during a decision.

Our contribution includes conceptual solutions for RQ1 and RQ2. Based on the fragment-based Case Management (fCM) approach (Hewelt & Weske, 2016), we conceptualize case models and cases to specify respective goals using first-order logic (RQ1). We translate the goals into a set of model checking problems to determine compatible activities (RQ2). This paper is an extension of our previous publication (Haarmann et al., 2021) proposing a method for modeling goals w.r.t. an fCM model.

This article is structured as follows: First, we give necessary background information regarding knowledge-intensive processes, case management, and model checking (Section 2). Afterward, we present related work (Section 3). Section 4 details the specification of goals. In Section 5, we describe the translation of goals to model checking problems. We evaluate our contribution with a proof of concept implementation, which we use for performance measurements and a user study (Section 6). Finally, we conclude our work (Section 7).

2 Background

In this paper, we combine different lines of research. On the one hand, our approach is based on modeled knowledge-intensive processes. We furthermore employ model checking to provide decision support for knowledge workers. In this section, we present respective preliminaries.

2.1 Knowledge-intensive processes

Data is the fuel for the information economy, and the demand for people making good business decisions by gathering, accessing, and making sense of data is increasing (Elliott & Jacobson, 2002). These people are called knowledge workers (Pyöriä, 2005). They use their expertise and experience for tasks, such as problem identification, problem-solving, and planning (Pyöriä, 2005). They learn continuously to keep their knowledge up-to-date (Pyöriä, 2005), and they need to cope with novel and unique situations (Ciccio et al., 2015).

In business process management, activities conducted in an enterprise are organized into processes (Weske, 2019). Processes that focus on knowledge work are called knowledge-intensive. They differ from traditional processes (Swenson, 2012), which becomes evident in the list of characteristics elicited by Di Ciccio et al., (2015). Of course, knowledge-intensive processes are knowledge-driven: Knowledge workers consider available information to choose a course of action, but this knowledge cannot be captured holistically and efficiently. Therefore, accurate predictions are impossible. Instead, processes emerge gradually with each decision, which knowledge workers align with their goals. Furthermore, two instances of a knowledge-intensive process always differ—the process is non-repeatable.

Traditional processes, on the other hand, are usually limited to a few well-defined variants with clearly defined decision rules. Respective process management paradigms are therefore not well suited for knowledge-intensive processes (Swenson, 2013). As an alternative, case management was proposed.

2.2 Fragment-based Case Management

The case management paradigm addresses the needs of flexible data-centric processes. A case has a subject that is in a situation, which needs to be resolved (Object Management Group, 2016). In a hospital setting, the subject is a patient, the situation is a disease, and the resolution is a successful treatment. The knowledge workers are responsible for choosing and executing actions that change the situation and eventually resolve it. Case management supports the collection, organization, and management of relevant information. Furthermore, it asserts that knowledge workers adhere to essential constraints.

Multiple case management approaches exist (Steinau et al., 2019). Cases are described by models, which commonly consist of a data model structuring the information about cases and a behavioral model defining activities and behavioral constraints. These constraints are often expressed declaratively to remain concise in the presence of flexibility (van der Aalst et al., 2009).

Our contribution builds upon the fragment-based Case Management approach (fCM) (Hewelt & Weske, 2016). Since many knowledge-intensive processes contain structured and unstructured parts, fCM models include structured, control flow-based fragments that can be composed dynamically within data constraints (Meyer et al., 2014). Similar to BPMN (Object Management Group, 2014), data is organized in data objects that have a finite set of abstract states (Hewelt & Weske, 2016). In contrast to BPMN, links among objects (Haarmann & Weske, 2020) and data associations with multiplicity constraints (Haarmann et al., 2021) play an important role.

2.2.1 Fragments

At the core of every fCM model are fragments (Hewelt & Weske, 2016). These are acyclic control flow graphs, similar to BPMN processes. They contain start events, activities, exclusive gateways, as well as data object nodes. A start event denotes the beginning of a new case. Fragments without a start event can therefore be started while the case is running. These fragments can run repeatedly, and fragment instances can be executed concurrently.

Data object nodes play a crucial role (Haarmann et al., 2021). They are grouped into input and output sets. When an activity is executed, it reads objects for one input set and writes objects for one output set. Subsequently, input sets represent data requirements. Activities can only be executed if the respective data requirements are satisfied. Therefore, data constraints the behavior.

In the following, we describe the fragments for the claim handling process of an insurance company. Fragment F1 in Fig. 1 shows the happy paths of the process: a claim is received. Its risk is assessed. It is rejected or approved in a decision, and it is disbursed, or a rejection letter is sent subsequently.

Fig. 1
figure 1

Fragment 1 for handling insurance claims

Full size image

In some cases, a decision cannot be made directly. The claim remains in question and one or multiple expert assessments are requested (F2) and created and reviewed (F3) as depicted in Fig. 2. During the review, an assessment may be rejected if it does not satisfy formal requirements. In this case, it can be improved by re-executing fragment F3.

Fig. 2
figure 2

Fragments 2 and 3 for handling insurance claims

Full size image

Given a set of approved assessments, a claim can be reassessed, creating an advice object (F4) (see Fig. 3). If more assessments are requested, the claim may be reassessed again. Eventually, the decision is revised (F5): it can be approved, rejected, or remain in question.

Fig. 3
figure 3

Fragments 4 and 5 for handling insurance claims

Full size image

2.2.2 Domain model

Data-centric process modeling approaches commonly include a data model (Steinau et al., 2019). It defines the structure of data objects as well as the possible relationships among objects. In fCM, the case model-specific data model is called domain model (Hewelt & Weske, 2016). It is a class diagram consisting of classes, binary associations, and multiplicity constraints—similar to UML class diagrams (Object Management Group, 2017).

Furthermore, fCM defines additional constraints that every domain model must satisfy (Haarmann et al., 2021): Two classes are connected by at most one association. All associations are existential—this means at least one of the corresponding multiplicity constraints has a positive upper bound. These constraints are necessary to define clearly when two objects get linked (Haarmann et al., 2021), and similar constraints exist in other data-centric process modeling approaches (Snoeck, 2014; Snoeck et al., 2021).

The domain model for the fragments is shown in Fig. 4. It consists of one class for each type of data objects: claim, risk, assessment, and advice. Furthermore, associations model the relationship among corresponding objects. Each claim is associated with up to one risk, five assignments, and five advice objects. Furthermore, each advice is based on at least one assignment.

Fig. 4
figure 4

Domain model for handling insurance claims

Full size image

2.2.3 Object behavior

Each data object has a set of attributes and a set of links. Jointly, they define the state of the data object. However, in business process management, data object states are often limited to a finite set of states. This also holds for fCM: data object nodes in fragments refer to data objects of a specific class in a specifics state (Hewelt & Weske, 2016). Activities may update the state of objects. All possible updates are called the object behavior (Haarmann et al., 2021).

In fCM, object behaviors are described by state transition systems. A case model has a state transition for each class. It defines all possible states and state transitions of corresponding objects. States are an abstraction for the possibly infinite many data states a data object can be in. The level of abstraction for those states is up to the modeler.

The object behavior for the insurance claim handling process consists of one state transition system for each class (see Fig. 5). The claim may be in one of the states received, in question, approved, disbursed, rejected, and rejection sent, and it may transition from one state to another as depicted in Fig. 5. However, object behavior models are not necessarily connected graphs. A risk, for example, may be high, medium, or low, but its state cannot change.

Fig. 5
figure 5

Object behaviors for handling insurance claims

Full size image

2.2.4 Termination condition

The termination condition defines the desired outcome of the cases. It is a logical expression that is evaluated on the data state of the case: data object nodes act as propositions. They are connected using the logical operators AND (∧) and OR (∨). Without loss of generality, we assume that the termination condition is in disjunctive normal form: it is a disjunction of product terms.

Similar to an input set, a product term is satisfied if a set of linked objects that adheres to the specified constraints exists. The complete expression is satisfied if at least one product term holds. If both the termination condition holds, the case can be closed.

The termination condition of the example requires the claim to be in state rejection sent or disbursed. This is expressed by the following condition:

$$ Claim[rejection~sent] ~\vee ~Claim[disbursed] $$

2.2.5 Case model

A case model consists of a set of fragments, a domain model, a set of object behaviors that are assigned to classes in the domain model, and a termination condition. The fragments define the activities, their dependencies, data requirements, and data operations. The domain model constrains the structure of the case data. The object behaviors limit the states and state transitions per class, and the termination condition specifies the case goal. To provide more flexibility and the means to adapt a case to environmental changes, fCM allows adapting the the case model and its components during run-time.

These relationships among the elements of the case model can be observed in the insurance example. The fragments allow arbitrarily many assessments, but the domain model limits the number of assignments to five per claim.

Activity ‘create assessment’ (see Fig. 2) has two input sets and two output sets: it reads a claim in state in question and an assessment either in state rejected or requested. It writes the assessment in state created or improved. However, according to the assessment’s behavior, it cannot change from state requested to improved nor from state rejected to state created. Therefore, ‘create assessment’ has only two valid input-output-set combinations.

Due to the relationships among the components of the case model, consistency is important. A case model must satisfy the following properties:

Object Behavior Conformance

Activities must comply with the object behaviors. They may only perform state changes modeled in the transition systems.

Contextual Object Creation

When an activity creates an object, it must read or co-create all objects required to create the novel object. The objects which are required depend on the associations and multiplicity constraints.

Contextual Batch Processing

When a set of similar objects is read, a reference object must be read to determine the set unambiguously. The set consists of all objects of the specified class that are linked to the reference object.

The metamodel in Fig. 6 provides an overview of fCM case models. The domain model, object behaviors, fragments, and the termination condition are connected, showing clearly the data-centric nature of fCM.

Fig. 6
figure 6

Metamodel for fCM case models (adapted from Haarmann,(2021))

Full size image

2.2.6 Execution semantics

Fragments can be executed dynamically and repeatedly according to the control- and data-flow as long as the constraints of the domain model and the object behavior are not violated. The semantics combine the different elements of a case model. Therefore, a mapping of fCM case models to colored Petri nets has been defined (Haarmann et al., 2021). It asserts that activities are executed without violating the object behaviors or the domain model.

During a case, activity instances are executed, instantiating classes and associations and updating data objects. Furthermore, control flow is advanced. We call an activity instance that is reading and writing specific data objects an action. Actions can be in one of the following states: init, control flow enabled, data-flow enabled, enabled, running, or terminated (cf. Fig. 7).

Fig. 7
figure 7

Life cycle of an activity instance in fCM

Full size image

The state of a case is determined by the data objects, the links among them, and the actions as defined in Definition 1.

Definition 1 (Case State)

Given a case model, let \(\mathcal {A}\) be the set of activities, \(\mathcal {C}\) the set of classes, \(\mathcal {Q}_{c}\) be the set of states for a class \(c\in \mathcal {C}\). Furthermore, let \(\mathcal {I}\mathcal {D}\) be the set of possible identities. The state s of a case is defined by a tuple s = (O,L,A).

  • O is a set of data objects, where each data object o ∈ O

    • is the instance of the class \(o.\textit {class}\in \mathcal {C}\).

    • has a state \(o.\textit {state}\in \mathcal {Q}_{o.\textit {class}}\) and the identity \(o.\textit {id}\in \mathcal {I}\mathcal {D}\).

  • \(L\subseteq \{\{o_{1},o_{2}\}\)|o1,o2 ∈ O} is a set of links, where each link is an unordered pair of objects.

  • A is a set of actions, where each action a ∈ A

    • is an instance of activity \(a.\textit {activity} \in \mathcal {A}\).

    • is in state \(a.\textit {state}\in Q_{\mathcal {A}}\), where \(Q_{\mathcal {A}}=\{\textit {init, df-enabled, cf-enabled, enabled, running, terminated}\}\).

    • reads a set of data objects \(a.\textit {reads}\subseteq O\).

    • writes a set data objects a.writes.Footnote 1

We use the case state for modeling goals and colored Petri net formalizations of case models (cf. (Haarmann et al., 2021)) for model checking-based recommendations.

2.3 Model checking

Model checking is a formal method to prove whether a behavioral model satisfies given properties (Clarke et al., 2001; Baier & Katoen, 2008): the model and the properties are formally defined. A model checker takes both, generates the model’s state space, and searches it to find paths that violate or satisfy the property. In business process management, model checking is used to check generic properties, such as soundness (van der Aalst et al., 2011), and domain-specific ones, such as compliance rules (Knuplesch & Reichert, 2017; Awad et al., 2011).

We use model checking for decision support. We formalize fCM case models with colored Petri nets as described in (Haarmann et al., 2021). We formalize properties with computational tree logic (Clarke & Emerson, 1981). A model checker (i.e., CPN Tools)Footnote 2 proves whether the property can be satisfied and may provide a witnesspath or counterexample.

Computational tree logic (CTL) (Clarke & Emerson, 1981) extends propositional logic with temporal operators and path quantifiers. It can express statements about state transition systems, where each state has a set of propositions. Thereby, we can express statements, such as “In all paths, the case will terminate eventually”.

Formally, both universal and existential path quantifiers exist in CTL. A requires that the formula holds for all paths and E that the formula holds for at least one path. Furthermore, the following temporal operators are available:

X ϕ :

Formula ϕ must hold in the next state.

F ϕ :

Formula ϕ must hold eventually.

G ϕ :

Formula ϕ must always hold.

ϕ 1 U ϕ 2 :

Formula ϕ1 holds until ϕ2 holds, and ϕ2 must hold eventually.

In CTL, path quantifiers and temporal operators always occur in pairs: a path quantifier is always followed by a temporal operator, and a temporal operator is always preceded by a path quantifier. Consider the natural language example from above. Let terminated be the propositional variable which is true if the case has terminated. In CTL, the statement above is formalized as follows:

$$ \textbf{AF}(\textit{terminated}) $$

Due to space limitations, we limit the discussion of model checking to the fundamental idea. Details, e.g., how a model checker verifies a model against a CTL formula, can be found in the respective literature (Clarke et al., 2001; Baier & Katoen, 2008).

3 Related work

In this section, we provide an overview of related work. We address knowledge intensive-processes, modeling of knowledge-intensive processes, and decision support and planning in BPM.

According to (Pyöriä, 2005), many definitions of knowledge work exist. We focus on the work of experts who are concerned with identifying and solving problems, and who gather and assess data to make informed decisions about their next actions. Their work is organized into knowledge-intensive processes (Ciccio et al., 2015).

Knowledge-intensive processes are often under-specified since knowledge workers’ expertise and experience are vast and fast-changing (Swenson, 2013). Ciccio et al. (2015) characterize knowledge-intensive processes and deduce a set of requirements. Among other things, such processes are unrepeatable and unpredictable and therefore require flexibility at design- and run-time.

Traditional process modeling languages, such as BPMN (Object Management Group, 2014), define process variants explicitly and are therefore considered unsuited for knowledge-intensive process (Swenson, 2012). To address this challenge, the research community has proposed novel process modeling approaches. Two trends are apparent: process models become more (i) declarative and (ii) data-centric (Ciccio et al., 2015).

The two most widely used purely declarative approaches are DECLARE (Pesic et al., 2007) and DCR-Graphs (Hildebrandt and Mukkamala, 2010). Rather than defining variants explicitly, declarative approaches define ordering constraints among activities. Every instance that does not violate these constraints is valid. DECLARE and DCR-Graphs use constraints based on linear temporal logic over finite traces.

Data-centric approaches, on the other hand, focus on data requirements, operations, and conditions (Steinau et al., 2019). The Guard-Stage-Milestone approach, for example, defines stages with pre- and post-conditions (Hull et al., 2010). The possible order of stages is given declaratively by these conditions. Other data-centric approaches, such as PHILharmonicFlows (Künzle & Reichert, 2011) and BAUML (Estañol, 2017), are more procedural: they define imperative models for each data type and allow composing them into larger processes. A recent overview of data-centric approaches is provided by Steinau et al. (2019). Hybrid approaches aim to combine the advantages of data-centric and declarative approaches. OCBC (van der Aalst et al., 2017) provides a combined syntax for both model types, while RESEDA (Seco et al., 2018) also incorporates event. With ReGraDa (Galrinho et al., 2021) a novel process definition and programming language was provided to execute processes on a database level. Case management approaches also address the requirements of knowledge-intensive processes (Swenson, 2013). They are data-driven, flexible, and often adaptable, i.e., the model can change at run-time. The fragment-based Case Management approach (Hewelt and Weske, 2016; Haarmann et al., 2021) is considered hybrid, since it combines activity-centric, imperative fragments and declarative data conditions. The highly structured parts (the fragments) can be combined dynamically if it is supported by the data dependencies. Furthermore, fCM is adaptable because new fragments can be added at run-time.

While these languages are all capable of modeling aspects of knowledge-intensive processes, they offer limited guidance at run-time. Though planning is crucial for knowledge work (Pyöriä, 2005), only a few approaches support late goal modeling (Ciccio et al., 2015), i.e. the modeling during run-time of goals to reach via planning.

In BPM, different approaches focus on automated planning. Marrella et al., (2014) present SmartPM where planning can be used to handle exceptions such that the data state can be automatically corrected. Venero et al., (2020) proposed planning for knowledge-intensive processes utilizing Markov decision processes. Furthermore, Sprovieri and Vogler (2015) apply planning on partly structured models to compose processes. However, as knowledge-intensive processes are emergent and driven by knowledge workers, automated planning is not fully applicable. Other approaches aim to provide decision support for knowledge workers during the execution of a process. Wynn et al., (2007) and Rozinat et al., (2009) offer decision support by simulation of business processes. Also, various contributions for predictive process monitoring exist, which predict the next actions in an ongoing process with machine learning techniques. The surveys of Teinemaa et al., (2019) and Francescomarino et al., (2018) provide an overview. Unfortunately, knowledge-intensive processes are characterized as non-repeatable and non-predictable (Ciccio et al., 2015). Therefore, simulations cannot necessarily be repeated, and machine learning models might not be applicable.

4 Modeling goal constraints

We aim at providing decision support for knowledge workers w.r.t their goals. In our model-based approach, a goal consists of constraints on case states. We consider a goal to be a combination of multiple objectives. To satisfy the goal, all corresponding objectives need to be reached. An objective is an operative goal. It is a statement about a single execution state, i.e., actions as well as data objects, their states, and links. In this section, we first define objectives, before we discuss temporally combining multiple objectives into goals.

4.1 Objectives

An objective is an operative goal and considered with a single case state. It can be formally defined as a logic expression over any case state (Definition 2). If it evaluates to true for a given state, the objective is satisfied.

Definition 2 (Objective)

Given a case and its case model, let s = (O,L,A) be a state of the case, O the set of data objects, L the set of links between them, and A the actions. G is the set of possible objectives over the state s and the case model. A data objective g ∈ G is a first-order logic expression about the sets O, L, and A.

Objectives are required to be within the scope of the case model. They can make statements about the actions in an execution state and the data state of a case. The actions are instances of the modeled activities and have a state according to their life cycle. The data state consists of a set of linked data objects. Each such object has an state that is modeled in the fragments and object behavior. It abstracts from the concrete values of the attributes. To be within the scope of a model, an objective can make statements about object states but not attributes.

Objectives may make statements about the actions A, the data objects O with their classes, object states, and unique IDs, and the links of data objects L in a certain execution state. They can be used to formulate the following objectives:

g1: The knowledge worker wants the advice with ID advice1 linked to two approved assessments.

$$ \begin{array}{@{}rcl@{}} g_{1} \equiv \exists o_{1} \in O: \mid\{o_{2} \in O \mid o_{2} .class&=&Assessment \\ \land o_{2} .state&=&approved \land \{o_{1},o_{2}\}\in L \}\mid=2 \end{array} $$

g2: The knowledge worker wants to be able to execute the activity ‘revise decision.’

$$ \begin{array}{@{}rcl@{}} g_{2} \equiv \exists a\in A: a.activity=revise~decision \land a.state=enabled \end{array} $$

g3 : The knowledge worker wants to execute ‘revise decision’ reading an advice object that is linked to all existing assessments.

$$ \begin{array}{@{}rcl@{}} g_{3} \equiv \exists a \in A, o_{1}\in a.reads, \forall o_{2} \in O: a.activity&=&revise decision \land\\ a.state&=&enabled \land o_{1}.class=Advice \land\\ (o_{2}.class&=&Assessment \implies \{o_{1},o_{2}\}\in L) \end{array} $$

4.2 Combined goal constraints

A goal is a temporal combination of objectives. To satisfy a goal, the objectives need to be satisfied in an execution sequence in a given order. The temporal order of objectives can be defined as follows:

Definition 3 (Temporally Ordered Objectives)

Let p = (ps,pa) be an execution sequence with the sequence of states ps = 〈s1,s2,...sn〉 and the sequence of actions pa = 〈a1,a2,...an− 1〉. Two objectives g1 and g2 are temporally ordered g1 ≤tg2 in p if g1 is satisfied in a state si ∈ ps, g2 is satisfied in a state sj ∈ ps, and i ≤ j.

Definition 4 (Goal)

Let G be a set of objectives and ≤t the temporal order relation for objectives. Γ is the set of goals, which are temporal order relations for the objectives G. A goal γ ∈Γ is a partial order \(\gamma = (G^{\prime }, \leq _{t})\) for a set of objectives \(G^{\prime } \subseteq G\).

A goal (Definition 4) is a partial order of objectives for the temporal order relation ≤t. Consider the following example of a goal:

γ1: First, the knowledge worker wants to gather three assessments in state approved. Afterward, they want to create a single advice object. Once both the set of assessments and the advice object exist, they want to execute ‘revise decision’. Formally, we break the goal into three objectives:

$$ \begin{array}{@{}rcl@{}} g_{4a}&\equiv& \mid\{o\in O\mid o.class=Assessment\land o.state=approved \}\mid = 3 \land\\ &&\mid\{o\in O\mid o.class=\textit{Advice}\}\mid = 0\\ g_{4b} &\equiv&\mid\{o\in O\mid o.class=Advice\}\mid = 1\\ g_{4c} &\equiv& \exists a \in A: a.activity=revise decision\land a.state=enabled \end{array} $$

The objectives are ordered in a sequence 〈g8a,g8b,g8c〉. This results in the following formalization of the combined goal γ1:

$$ \gamma_{1}=(\{g_{4a},g_{4b},g_{4c}\},\{(g_{4a},g_{4a}),(g_{4b},g_{4b}),(g_{4c},g_{4c}),(g_{4a},g_{4b}),(g_{4a},g_{4c}),(g_{4b},g_{4c})\}) $$

5 Decision support

Modeling goals is only the first step to providing decision support for knowledge workers. We use the goals to inform knowledge workers about enabled actions that are compatible with their goals. For this purpose, we use model checking.

Our approach (see Fig. 8) requires the following inputs: a formalization of the case model, i.e., its colored Petri net representation (cf. Haarmann et al., 2021), the current state of the case, and the goal of the knowledge worker. Based on these inputs, we generate a set of model checking problems. For each action that is enabled in the current state, we check whether it is compatible with the goal. This information is provided to the knowledge worker.

Fig. 8
figure 8

Approach for filtering enabled actions based on a given objective

Full size image

5.1 Translating goals into model checking problems

First, we consider objectives, which are evaluated on one state. Given the set of actions, objects, and links, the first-order logic formula of the objective is true or false. If it is true, reaching the state implies accomplishing the objective. We assume that knowledge workers are only interested in reaching objectives. They might become obsolete over time and within one goal.

To check whether an action is compatible with an objective, we simulate the action to retrieve the corresponding successor state. Then, we use a model checker to check if we can reach a state that satisfies the objective. Therefore, we translate the objective into a temporal logic formula. Let g be an objective of the knowledge worker, it is transformed into the following CTL formula: EF(g). It reads ‘In the current state starts a path with a state satisfying the objective.’ We allow goals to combine different objectives. Objectives might become obsolete over time. Therefore, we are only interested in reaching objectives, denoted by EF(g). They do not need to hold globally.

Given the example objective g2, ‘The knowledge worker wants to have an advice object based on all assessments’, the knowledge worker wants to advance the case to a state, in which an advice object exists, and this advice object is linked to all assessments. With the CTL formula EF(g2), we can verify that the objectives can be reached from the current state.

CTL is a propositional logic (Clarke & Emerson, 1981), objectives are specified in first-order logic. To solve this mismatch, we create a propositional variable for each objective. For each state, we check whether it satisfies the objective. If so, the respective propositional variable is true, otherwise false. Depending on the implementation of the model checker, it is possible to either compute the value of the propositional variables for each state in advance, or to evaluate the propositional variables ad hoc during the execution of the query.

Given a goal (a partial order of objectives), we derive all strictly ordered sequences of objectives. Each sequence \(\langle g_{1}, g_{2}, {\dots } g_{n}\rangle \) is translated into CTL:

$$ \begin{array}{@{}rcl@{}} \textbf{EF}(g_{1} \land \textbf{EF}(g_{2} \land {\dots} \land \textbf{EF}(g_{n})\dots)) \end{array} $$

Given multiple sequences translated into terms \(t_{1},t_{2},{\dots } t_{m}\), we combine them into one formula: \(t_{1} \vee t_{2} \vee {\dots } \vee t_{m}\)

Consider the following example: the knowledge worker wants to create at least three assessments and later terminate the case. The propositional variables are defined as follows:

$$ \begin{array}{@{}rcl@{}} g_{9a} &\equiv& \mid\{o \in O \mid o.class = Assessment\} \mid \geq 3\\ g_{9b} &\equiv& terminated \end{array} $$

This results in the following CTL formula: EF(g9a ∧EF(g9b))

5.2 Filtering enabled actions

Given the CTL representation of the goal, we can filter the set of enabled actions. For each such action, we derive the corresponding successor state and use a model checker to verify if the successor state is compatible with the goal. If so, the action may be taken by the knowledge worker. Of course, additional external information needs to be considered. If no suitable action exists, knowledge workers might adapt their goal or the model so that an existing or an alternative action allows reaching the goal. Either way, the feedback of the model checker is provided to assist knowledge workers during their decision making.

Consider the following example: A knowledge worker at our example insurance company assesses the risk of a claim to be high. Next, they decide that assessments are necessary, i.e., the claim is in state in question. The knowledge worker plans to request at least four assessments, wait for their creation before deriving an advice to reassess the claim. They express this plan as a goal:

$$ \begin{array}{@{}rcl@{}} g_{10a} &\equiv& \mid\{o \in O \mid o.class = Assessment\}\mid \geq 4 \land \mid\{o \in O \mid o.class = Advice\}\mid = 0\\ g_{10b} &\equiv& \mid\{o \in O \mid o.class=Advice\}\mid = 1\\ g_{10} & \equiv& (\{g_{10a},g_{10b}\},\{(g_{10a},g_{10a}),(g_{10a},g_{10b}),(g_{10b},g_{10b})\}) \end{array} $$

Using our approach, the knowledge worker can easily avoid actions that make the goal unreachable. Therefore, the goal g10 is translated into a CTL formula:

$$ \textbf{EF}(g_{10a} \land \textbf{EF}(g_{10b})) $$

Consider the state, where the claim is in question, the risk is low, and one assessment has been requested and approved. Activities ‘request expert assessment’ and ‘reassess claim’ are enabled. Both are simulated, and the resulting states are verified against the CTL formula. The state after executing ‘reassess claim’ violates the goal. Executing ‘request expert assessment’ is compatible with the goal. Thus, the knowledge worker should execute the latter.

Knowledge-intensive processes emerge, and knowledge workers need to make decisions frequently to drive the process toward their goals (Ciccio et al., 2015). Using our approach iteratively, they can model their current goal and receive recommendations for the current situation, leading them toward their goals.

6 Evaluation

To evaluate our approach, we first provide a proof of concept implementation, which supports modeling goals using forms. It translates the modeled goal into a model checking problem. Second, we evaluate the technical feasibility of our approach. Therefore, we measure the performance using the model checker provided by CPN ToolsFootnote 3. Finally, we conduct a preliminary user study to show that our approach offers valuable decision support for knowledge workers.

6.1 Proof of concept implementation

Our implementation has two aims. First, the knowledge worker must be allowed to specify goals according to the presented framework. Second, recommendations according to this goal need to be derived from the case. This allows knowledge workers to be assisted in making decisions towards their goals.

The prototype consists of a combination of tools (see Fig. 9). The fcm2cpnFootnote 4 translator allows translating an fCM model into its formal representation as a colored Petri net (CPN). This CPN can be executed by a knowledge worker using the CPN modeling and simulation tool CPN Tools.

Fig. 9
figure 9

The architecture of involved components for the prototype

Full size image

During the execution of an fCM, the fCM-query-generatorFootnote 5 can be used to define goals at run-time. It produces a state space query that can be used in CPN Tools to analyze the state space of the case. The query can determine if a certain state lies on a path that leads to a state satisfying the goal.

In the query generator, the knowledge worker can select an fCM case model. The generator parses the model and generates a form for specifying a goal using the objects and activities of the case model. The knowledge worker can define statements consisting of data goals and activity goals. Data goals are existential or universal qualifications or multiplicity constraints about data objects and their states. Activity goals describe activities that should be enabled. A number of data and activity goals can be concatenated by using AND, OR, and NOT.

Considering the case model for a claim handling process, Fig. 10 depicts the input form for the goal of having the activity ‘disburse claim’ enabled, having exactly one approving advice, and at least 4 approved assessments.

Fig. 10
figure 10

The user interface for specifying a goal

Full size image

The goal is stored as a logical expression, and a state space query is generated. This query is a temporal logic expression in the CTL derivative ASK-CTL.Footnote 6 It evaluates the objectives for each state ad hoc and checks whether the goal can be reached from a given state.

To receive decision support during the execution in CPN Tools, a knowledge worker can define their goal in the query generator. For this goal, a state space query is generated. In CPN Tools for every possible next state, the state space query can be executed. It evaluates if this state allows reaching the goal, and more importantly, if not. This information for all next actions can be used as a recommendation to the knowledge workers (see Fig. 11).

Fig. 11
figure 11

Engine with recommendations: incompatible actions are struck through

Full size image

6.2 Run-time experiments

Knowledge-intensive processes are multi-variant and often highly concurrent. Since the state space of a process grows exponentially to the degree of concurrency, model checking can be computationally expensive, slow, or even technically infeasible. To show the feasibility of our approach for the presented example, we conducted an experiment using CPN Tools: We measure the performance using the CPN Tools model checker (ASK-CTL) for our sample case model and multiple goals. All results can be found in our respective repository.Footnote 7

Our solution requires a finite state space. To guarantee this, the model needs to be adapted so that the number of data objects is finite by require that every class is linked directly or indirectly to the case class and that all multiplicity constraints define an upper bound (* must not be used). Also, the number of concurrent fragment instances needs to be finite. All fragments require a data pre-condition to start, which is given in our example.

Our prototype needs to calculate the state space of the case model first. CPN Tools calculates the state space in 2 min 12 sec.Footnote 8 The state space consists of 52,964 states. It needs to be calculated only once per model and can be used for all instances and all goals.

Second, we need to filter the enabled actions based on a goal. Given the following goal, ‘The knowledge worker wants to create at least four assessments, exactly one advice object, and disburse the claim afterward’, we filtered the enabled actions in 10 random states, five times each. The filtering took on average 433 ms per action. For a more complex goal, the filtering took on average 510 ms. As the state space must only be generated once for the case model, the time needed to derive recommendations in the presented example process is low enough to support knowledge workers during the execution.

6.3 Preliminary user study

To evaluate whether our approach can support the decisions of knowledge workers and drive the process to their goals, we performed an experiment.

Research question

The goal of our experiments is to compare the performance of KiP executioners with or without recommendations in terms of (i) the number of attempts required, (ii) the number of actions executed, and (iii) the duration from start until reaching the goal. The hypotheses are that (i) users with recommendations need only one attempt, while users without them need more, (ii) with recommendations less actions are required to reach the goal, and (iii) with recommendations users need less time to reach the goal.

Experimental setup

All 14 participants are computer science students in their bachelors (4), masters (7), or Ph.D. (3), with different but comparable experience with BPM and fCM (see the histogram in Fig. 12).

Fig. 12
figure 12

Histogram for the self assessment of the participant’s prior experience with fCM

Full size image

The participants were split randomly into two equally sized groups. Each participant was provided with the fCM model for our example, a predefined goal, and an execution engine.Footnote 9 The treatment group was provided with recommendations according to their current execution state using color coding: compatible actions were colored in green, incompatible actions in red. The control group was asked to reach the goal without additional help.

Results

Table 1 shows the experimental results. With recommendations, participants reached the goal in one attempt. In the control group, participants needed on avg. 1.86 attempts. The t-test for the number of attempts shows a great effect, with statistical significance for an α-value of 0.05. Hypothesis (i) holds.

Table 1 The results of the experiments for the three hypotheses
Full size table

When considering only the successful attempts, users that received the recommendations executed on average 19.43 actions, while users in the control group needed 20 on average. Here the effect is smaller and also shows no statistical significance. The second hypothesis cannot be proven. Still, the results indicate toward an improvement given recommendations.

When looking at how long the participants needed to reach the goal, the treatment group performed better. They needed only 422s on average, while participants without recommendations needed 634s. Also, we can observe a great statistically significant effect. The third hypothesis is supported as well.

Qualitative measurements

We asked all participants “What supported you in reaching the goal,” and “What hindered you in reaching the goal”? Most participants in the control group received the most support from the case model. In contrast, most participants that received recommendations considered the red color of incompatible actions helpful. They used the model less. Participants of the control group felt hindered by the complexity of the model and wished for an improved interface for the execution engine. In contrast, out of the participants with recommendations, only two mentioned the complexity of the model as hindering. Whereas, most of them requested an improved UI as well. We assume that the recommendations reduced the need to understand the complex model fully.

Threats of validity

The presented experiment yields some limitations. The number of participants was small. No participant was an actual knowledge worker. All were computer science students that are used to formal languages. In our experiments, we provided execution engines with technical interfaces. Both could be a bias.

Still, the results indicate that our approach might be helpful to support knowledge workers at run-time. However, the group of participants is too small and too homogeneous to make a general statement.

7 Discussion and conclusion

We presented a model-based approach for supporting knowledge workers in deciding on the next action. They were enabled to specify goals based on an fCM model including activities and data objects. From the goal, we derive model checking problems, which can be used to filter enabled actions: For each such action, we determine whether it is compatible with the goal. This information provides valuable decision support.

Other approaches (Teinemaa et al., 2019; Francescomarino et al., 2018) propose sequences of actions. But, knowledge-intensive processes are emergent; hence, predictions are likely inaccurate, and recommending sequences of actions in advance has limited value. Our approach recommends sequences of actions in a valuable way because it iteratively considers the current situation, rather than a past situation.

We use model checking for deriving recommendations, allowing us to use established tools and techniques. However, the fCM models may have large state spaces. Experiments were conducted indicating that the presented approach provides valuable recommendations for knowledge workers.

As our approach requires explicitly modeled goals, it can be relevant to investigate the combination with existing machine learning-based approaches for computing recommendations to incorporate past behavioral patterns and tacit knowledge into decision support. Also, incremental approaches and heuristics may be applied to direct the search and cope with large state spaces. The technical feasibility of the approach in terms of run-time for computing recommendations needs to be investigated for real-world processes. A larger study should be conducted involving more diverse knowledge workers of different domains and real-world process models and changing goals. The use of eye tracking could provide relevant insights, as it is able to measure the cognitive load of knowledge workers (Wang et al., 2017; Nagel et al., 2019). Future experiments should also evaluate the presented goal modeling approach.

Overall, our approach can be applied iteratively to the execution of knowledge-intensive processes. It supports knowledge workers, who frequently have to choose from many possible actions. It is a step towards run-time support for knowledge-intensive processes. By reducing the cognitive load, the approach may enable users to execute processes faster and with fewer errors.