Efficacy-aware Business Process Modeling [original]

Efficacy-aware Business Process Modeling

Matthias Lohrmann and Manfred Reichert

Ulm University,

Databases and Information Systems Institute,

{matthias.lohrmann,manfred.reichert}@uni-ulm.de

Abstract. In business process design, business objective models can ful-

fill the role of formal requirement definitions. Matching process models

against objective models would, for instance, enable sound comparison of

implementation alternatives. For that purpose, objective models should

be available independently of their concrete implementation in a busi-

ness process. This issue is not addressed by common business process

management concepts yet. Moreover, process models are currently not

sufficiently expressive to determine business process efficacy in the sense

of fulfilling a business objective. Therefore, this paper develops and in-

tegrates constructs required for efficacy-aware process modeling and apt

to extend common modeling approaches. The concept is illustrated with

a sample scenario. Overall, it serves as an enabler for progressive appli-

cations like automated process optimization.

Key words: Business Process Modeling and Analysis, Business Process

Design, Business Objectives and Goals

1 Introduction

The notion of business goals, objectives, or similar concepts has been widely

used to define the term business process (e.g., [1]). At the same time, seman-

tic quality of process models has been recognized as an important prerequisite

for successful adoption [2]. Nevertheless, objectives are still a notable excep-

tion to the progress towards formal business process semantics, and are only

rudimentarily considered in common modeling approaches [3, 4]. The effective-

ness of processes in regard to achieving business objectives can be subsumed as

business process efficacy. The case for assessing and controlling business process

efficacy with formal business objective models can be illustrated by considering

exemplary application scenarios:

Scenario 1 (Automated Business Process Optimization). Process-aware infor-

mation systems (PAISs) collect data on process execution that could be leveraged for

automated business process optimization [5]. Consider, for instance, process abortions:

if a process instance cannot be completed, it should abort as early as possible to avoid

unnecessary consumption of resources. Next-generation PAISs might re-arrange control

flow to foster this behavior based on the execution logs of past instances. However, this

must be done in a way to maintain the overall efficacy of the business process. Thus,

a semantic link between business objectives and business process models is required.

Scenario 2 (Identification of Business Process Variants). The management of

business process variants has emerged as an important business process management

(BPM) issue [6–8]. However, criteria to determine whether two process models are

variants of the same reference process remain a “missing link”. In this respect, modeling

business processes in a way that enables tracing to common business objectives can

provide an effective characteristic to assess the “equivalence” of process variants.

Scenario 3 (Benchmarking). Qualitative benchmarking deals with good practices

to identify opportunities for process improvement [9]. This often meets the resistance

of practitioners as the equivalence of process alternatives regarding their outcome is

doubted. Formalizing efficacy can help to alleviate this issue. Similar considerations

apply to more recent approaches like process performance management [10].

As depicted in Figure 1, our approach contributes capabilities which are re-

quired to address the scenarios lined out, but not provided by the state of the

art. This includes a clear distinction between business objectives (as a formal

requirements definition) and business processes (as an implementation), and the

ability to formally determine whether and under which circumstances a business

objective is achieved, i.e. whether a business process is efficacious. Proper for-

malization will, in the end, be key to efficient automation. Seamless integration

of new concepts with existing BPM approaches fosters applicability.

Constraint:

Integration with established

BPM approaches

(e.g. process modeling)

Contribution

Capability 1:

Model business objectives independently from

business processes, i.e. in a separate model

Capability 2:

Formally assess business process efficacy, i.e. whether

a business process fulfills a business objective

Fig. 1. Contribution Overview

2 Methodology and Outline

In general, business objectives exist independently of business processes. A cer-

tain process constitutes just one of many potential alternatives to achieve its

objective, e.g. by using another IT system or re-arranging the order of activities.

In other words, a business objective is achieved by inducing a state that satis-

fies particular criteria – no matter how this is done. Therefore, assessment and

control of business process efficacy generally require two modeling facilities:

Design Science Artifacts

Constructs Models Methods

Terminology:

Required constructs

for efficacy-aware

business process

models

Meta-model:

Interrelations between

constructs (business

objectives, extended

business process

models)

Method:

Operations required to

enable business

process model efficacy

assessment

Build

Evaluate

Business

Objectives Business

Processes

Available Results

Enable to assess business

process model efficacy

Effectiveness Criteria

Integrate with common

modeling languages

Build

Instantiations

Sample process:

Meta-model

instantiation: efficacy-

aware business

process model

Build

Evaluate

Build

Evaluate

Fig. 2. Methodology to Contrive an Efficacy-aware Business Process Meta-model

1. A business objective meta-model that is sufficiently expressive to model business

objectives independently of corresponding business processes in the sense of a for-

mal requirements definition.

2. An efficacy-aware business process meta-model that is sufficiently expressive to

determine whether a corresponding business process model fulfills a business ob-

jective, i.e. whether it is efficacious.

As we presented results towards business objective modeling in [11], the fo-

cus of this paper lies on the second modeling facility, the efficacy-aware busi-

ness process meta-model. Since this is a goal-bound artificial construct, we orient

our methodology at the design science paradigm [12, 13]. Figure 2 presents an

overview reflecting the design procedures build and evaluate, and the design arti-

facts constructs,models,methods, and instantiations [13]. As a first step, we build

a set of required constructs based on available results. This provides us with a ter-

minology for further considerations. We then describe the relations between the

constructs identified, thus building a meta-model.1The meta-model is amended

with operations required for efficacy assessment in the sense of a method. On

that basis, efficacy-aware business process models can be built.Evaluation of

results then occurs in reversed order: a sample process is used to evaluate the

effectiveness of the method, the meta-model and, in turn, the set of constructs.

In terms of functionality, the resulting artifacts can be considered as effective

if efficacy assessment has been enabled. As an additional effectiveness criterion

to ensure applicability, we also demand that results should integrate well with

existing business process modeling languages. This means that new constructs

and meta-model elements should only be used where required due to limitations

in well-established languages, and all new constructs should be well-connected

to existing terminology. Note that these effectiveness criteria correspond to the

1Note the shift in terminology: in terms of design science artifacts, our meta-model

constitutes a model.

second capability and the constraint stipulated in Figure 1. The first capabil-

ity, separating objective from process models, has been addressed in [11] which

provides the basis for this paper.

Accordingly, Section 3 reflects existing results and related work as a starting

point to build our approach. Section 4 derives terminology required for efficacy

assessment. Section 5 builds a meta-model for efficacy-aware business processes.

Section 6 presents operations required for efficacy assessment as well as an ex-

emplary instantiation of the meta-model to discuss the validity of our results.

3 Background

This section discusses related approaches and summarizes our previous work.

3.1 Related Work

Since the notion of goals or objectives is part of most definitions of the term

“business process”, there have been a number of approaches towards integrating

objectives into process modeling. Table 1 summarizes related approaches along

a set of semantic requirements relevant in the context of business objectives. A

more detailed analysis is presented in [11].

Semantic Requirements Reflection in Related Work Conclusions

Consideration of the affect-

ing environment: Objectives

must consider the state of

both target artifacts to be

created and altered and envi-

ronmental conditions (e.g. in

decision processes).

Mostly no formal, state-based

concept of objectives achieve-

ment (e.g., [14–16]); objectives

may be viewed not as state to be

achieved, but as set of tasks to be

executed (e.g., [17, 18]).

The requirement to de-

lineate objectives from

activities and to suffi-

ciently consider environ-

mental conditions are

still open issues.

Varying target environment:

Depending on environmental

conditions, the set of arti-

facts to be created or altered

and the set of operations to

be carried out may vary.

Goals are mostly discussed on an

abstract level without referring to

single target artifacts (e.g., [14,

15]) or without an environmental

conditions concept (e.g., [18, 16]).

Flexible adaptation to

environmental condi-

tions in terms of actu-

ally required process

results is still an open

issue.

Order constraints: Con-

straints to the order of activ-

ities to be carried out must

be representable).

Constraints are partially consid-

ered as an abstract construct [18]

or via consistency of paths [17].

Other approaches omit order con-

straints (e.g. [14–16]).

The notion of con-

straints is partly avail-

able, but needs to be

refined.

Table 1. Semantic Requirements and Related Work

The gap of existing approaches regarding the coverage of semantic require-

ments is not surprising considering that goal structures are mostly used as an

auxiliary tool in process design, but not as a means to formally manage effi-

cacy. Typically, this leads to the absence of separate business objective models.

Instead, business objectives are integrated into business process models.

This view is also reflected in a number of general process modeling formalisms

(e.g., EPCs [4]) as well as, in a broader context, enterprise architecture ap-

proaches (e.g., [19]). It corresponds to the methods category of design science

artifacts, and the merits of related concepts should be evaluated in this context.

In contrast, this paper is mainly focused on constructs and models.

Beyond the related work discussed in Table 1, it is instructive to consider i*

[20] and KAOS [21] from the requirements engineering field. The i* framework

aims at documenting actors’ goals and dependencies in early-phase requirements

engineering, but not on formalizing objectives. Accordingly, i* addresses a dif-

ferent lifecycle stage and cannot be matched against the semantic requirements

for our approach. In turn, KAOS provides a framework for capturing aspects

relevant to information systems requirements engineering via an “acquisition

strategy”. The constraints construct in KAOS corresponds to the concept of

business objectives in [11] and could be extended by the aspects relevant to

BPM as discussed there (cf. Section 3.2). The focus of this paper, however, is on

integrating with common BPM approaches instead of requirements engineering.

To avoid unnecessary complexity, we thus settle for our approach which is more

specific in this respect.

Approaches towards the compliance of process models to given rules (e.g.,

[22]) are aimed at ensuring the compliance of process execution with constraints

imposed (e.g., legal requirements), but do not address issues such as deriving

required resources from a process model. They are thus not sufficient to enable

efficacy assessment.

3.2 Available Results from Previous Work

Addressing the first capability stipulated in Section 1, we suggested and evalu-

ated a meta-model for formal business objectives modeling in [11]. This paper

focuses on its integration with common business process modeling concepts to

enable efficacy assessment. Consequently, this section provides an overview on

relevant business objective concepts needed for the understanding of our results.

Business processes are enacted to induce a change to their environment.

The intended change constitutes a business objective. A na¨ıve approach might

be to simply model a set of actions required to fulfill the business objective.

However, this is not sufficient, as business processes need to interact with their

environment. This means that the intended final state must be derived from the

initial state of the environment. As an example, consider the approval of loans.

The loan decision must consider the customer’s credit history. Thus “approve

loan” is not sufficient to describe the business objective. This challenge lies

behind most of the constructs shortly presented in the following.

For business objective modeling, we discern target elements as characteristics

of the business process’s environment to be altered, and conditional elements as

characteristics that need to be considered to determine the intended final state.

Both make up the environmental elements of a business process. In our loan

approval example, the loan decision constitutes a target element, and its aspired

value depends on the state of the customer’s credit history as a conditional

element. To describe the state of both target and conditional elements, we use

the concept of binary state determinants (BSDs).

We discern between target BSDs and conditional BSDs, which relate the

state of target and conditional elements, respectively, to a value range, either

absolutely or in terms of other conditional elements. If the respective relation

holds, the BSD is fulfilled. Regarding our loan example, “loan decision = ap-

proved” might be a target BSD, and “overdues <5% of credit volume” might

be a conditional BSD. Target BSDs are classified according to types reflecting

their semantic interrelation with environmental conditions which can, in turn,

be expressed through sets of conditional BSDs. Figure 3 provides an overview.

Types

Target

BSDs

Types

Target



BSDs

Types of Target BSDs

Monovalent

Target

Bivalent Target

BSDs

Trivalent Target

BSDs

Monovalent

Target

BSDs

Must always be

fulfilled to achieve

the business

Bivalent

Target

BSDs

Environmental conditions must be considered to

determine if the target BSD must be fulfilled

Trivalent

Target

BSDs

State of

environmental

conditions

determines one of

objective, regardless

of environmental

conditions

Example: “customer

address validated =

three options: for

certain states, the

BSD must be

fulfilled, for other

states, the BSD

Fully Determinate

Bivalent Target BSDs

The related

environmental

conditions determine

Partially Determinate

Bivalent Target BSDs

Must be fulfilled if the

respective

environmental

address

validated

true”

states,

the

BSD

must not be fulfilled,

and for the

remaining states, we

are indifferent

dli

conditions

determine

whether the BSD

must or must not be

fulfilled

Example: “loan

environmental

conditions are given

If not, we are

indifferent whether

the BSD is fulfilled



ng mo

ng,

trivalent target BSDs

are resolved into two

partially determinate

bivalent BSDs

approved = true” Example: “customer

entered into data

base = true” (only

really necessary if

the loan is

approved)

the

loan

approved)

Fig. 3. Types of Target BSDs

To model the environmental conditions that determine whether a bivalent

target BSD must be fulfilled, each bivalent target BSD is linked to a condi-

tional proposition. Conditional propositions consist of conditional BSDs that are

arranged into sets of necessary and sufficient sub-conditions (cf. Example 1).

The sub-conditions allow minimizing the number of required checking actions

by following a strategy to quickly approve or disapprove the proposition.

Thus, a business objective bundles a set of target BSDs. It is achieved if

and only if each target BSD comprised has assumed a state reflecting its condi-

tional propositions. An efficacious business process has to approve or reject each

conditional proposition, and manipulate target elements accordingly. Figure 4

shows an exemplary business objective model. The corresponding semantics are

described in Example 1.

Clearing

document

posted

Age class

amended

Impairment

document

posted OR

true

Business

impairment

requirement

Symbols

Monovalent

Target BSD set

Conditional

Element Conditional BSD /

Subcondition

Target / Conditional

BSD link OR

AND Necessary

Subconditions

Sufficient

Subconditions

Fully Determinate

Bivalent Target BSD set

Partially Determinate

Bivalent Target BSD set

Reporting

impairment

requirement

Payment

received Payment received = false AND

Reporting impairment req’ment > 0

Amount

receivable

Impairment

document

NOT posted AND

AND

false

Payment received = false AND

Reporting impairment req’ment > 0

Payment received = false AND

Business impairment req’ment > 0

Payment received = false AND

Business impairment req’ment > 0

Amount receivable > max

(Business impairment req’ment,

Reporting impairment req’ment)

…

= 0

A B C D

AND AND

Fig. 4. Exemplary Business Objective: Year-end Receivables Processing

Example 1 (Business Objective: Year-end Receivables Processing). Properly pro-

cessing receivables, e.g. open customer invoices, constitutes a business objective

during year-end closing in accounting. Figure 4 informally presents the respec-

tive objective model described in the following. The top four horizontal lines

in the model correspond to the relevant conditional elements, and the bottom

four lines correspond to target BSDs. Vertical lines and nodes are used to link

conditional elements and target BSDs by way of conditional propositions. For

reference, target BSDs and sub-conditions have been amended with numbers

and literals, respectively. The individual target BSDs are modeled as follows:

–Target BSD Clearing document posted (1): If payment has been received

for the receivable, it must be cleared, i.e. removed from the list of open

items. If not, a clearing document must not be posted. Accordingly, Clearing

document posted constitutes a fully determinate bivalent target BSD linked

to Payment received (A) as a conditional BSD. Since there are no other

conditional BSDs to be considered, there is no need to discern sufficient and

necessary sub-conditions.

–Target BSDs Impairment document posted / Impairment document NOT

posted: An open receivable must be impaired (i.e., its book value as an asset

must be reduced) in certain cases, but it must not be impaired in others.

Moreover, there may be circumstances where we are indifferent. Accordingly,

Impairment document posted constitutes a trivalent target BSD which we

resolve into two partially determinate bivalent ones: Impairment document

posted and Impairment document NOT posted.

•Target BSD Impairment document posted (2): Business and reporting

impairment requirements are needed if the receivable is not being fully

recoverable according to management’s judgment or having to be im-

paired for (legal) reporting guidelines, respectively. If there is no payment

but a business impairment requirement (B), or if there is no payment

but a reporting impairment requirement (C), the impairment must be

posted. Accordingly, the OR label associated with the target BSD indi-

cates that there are two sufficient sub-conditions, each consisting of two

conditional BSDs.

•Target BSD Impairment document NOT posted (3): On the other hand,

if no payment has been received (D), and there is neither a business nor

a reporting impairment requirement (E and F), an impairment must not

be posted. Thus, there are three necessary sub-conditions as indicated

by the AND label going with the target BSD.

–Target BSD Age class amended (4): If an open receivable has not been cleared

(D) and its amount is greater than the amount to be impaired (G), it must

be amended with an age class for correct balance sheet reporting (e.g., “>

12 months”). If the receivable has been reduced to zero through clearing or

impairment, we are indifferent whether an age class is amended. Therefore,

Age class amended constitutes a partially determinate target BSD with two

necessary sub-conditions.

Note that for target BSDs with more than one conditional BSD, the notation

allows showing either necessary or sufficient sub-conditions, depending on the

modeler’s choice, and that monovalent Target BSDs do not occur in our example.

The business objectives modeling approach has been derived from semantic

requirements (cf. Table 1) and tested against usability criteria by applying it

to an exemplary real-world case with a modeling method [11]. In contrast to

related work (cf. Section 3.1), it provides the ability to formally describe business

objectives as intended states of the environment. It also provides a convention

to model order constraints. However, this topic is not covered by our example,

as it is more of a challenge when modeling business objectives without referring

to a concrete process model.

4 Business Process Model Efficacy

In Section 3.2, we discussed how business objectives can be modeled indepen-

dently from business processes, thus addressing the first capability in Figure 1.

This section focuses on the second capability, enabling efficacy assessment. We

first deepen our understanding of what constitutes an efficacious business pro-

cess. Then, we discuss what information is required to assess efficacy.

Considering the notion of business objectives in [11], we can define:

Definition 1 (Business Process Model Efficacy). A business process model

is formally efficacious iff no target BSD in its business objective can be fulfilled

unless the respective conditions defined by the business objective are fulfilled.

A business process model is fully efficacious iff it is formally efficacious and

all conditions which the model poses to target BSDs, but which are not defined

by the business objective, are considered as reasonable by subject matter experts.

A business process model is ideally efficacious iff it is formally efficacious and

there are no additional conditions posed to target BSDs beyond those defined by

the business objective.

Note that ideally efficacious business processes do not occur in practice as

each business process requires resources which are not part of the business ob-

jective (e.g., expenditure of labor).

According to Def. 1, assessing efficacy requires to analyze process models

regarding the conditions they pose towards the fulfillment of target BSDs. To

assess formal efficiency, the conditions obtained are then compared to the con-

ditions posed by the objective model. Moreover, to assess full efficacy, they are

in matched against subject matter experts’ expectations.

Example 2 (Efficacy Assessment). As an example, reconsider the loan approval

process. Comparing it with the business objective, in this case, will clarify

whether decision criteria for loan approval such as the credit history are ob-

served, i.e. whether the process is formally efficacious. For full efficacy, however,

we also need to consider whether an unreasonable amount of working time is

required for the process. This is not documented in the business objective, but

requires the judgment of subject matter experts.

Efficacy assessment can be supported by consolidating and properly struc-

turing the conditions a business process poses to individual target BSDs. Similar

to the modeling of business objectives in [11], this can be achieved by amend-

ing target BSDs with conditional propositions consisting of conditional BSDs. In

contrast to business objectives, business processes pose a conditional proposition

even to monovalent target BSDs, since each business process requires resources

to be available (i.e., there are no ideally efficacious processes, cf. Def. 1). As

discussed in Section 3.2, assessment can be simplified by structuring conditional

propositions into necessary and sufficient sub-conditions.

Example 3 (Necessary and Sufficient Sub-conditions). Again, consider the ap-

proval of loans. The availability of customer master data and the responsible

manager both constitute necessary sub-conditions. Assuming that the customer’s

credit history is usually available in the data base, but may also have to be

obtained manually, we have two sufficient sub-conditions: the described neces-

sary sub-conditions plus the data base entry, and the described necessary sub-

conditions plus the availability of a clerk for manual evaluation.2

Moreover, to achieve formal efficacy (cf. Def. 1), the environmental conditions

resulting from a process model with respect to a target BSD must “encompass”

the environmental conditions specified in the objective model. More precisely,

each necessary sub-condition of the target BSD in the business objective should

be a necessary sub-condition in the process model as well. Therefore, we discern

between the outer conditional environment and the inner conditional environ-

ment defined by process and objective model, respectively. Figure 5 summarizes

the constituents of the outer conditional environment. We use the Referent Mod-

eling Language (RML) described in [23], since it provides a concise means of

describing set relations. The concept of target presumptions will be illustrated

in Section 6.

Target BSDs

Outer Conditional

BSDs OCB

nos.contains

Outer Conditional

Propositions OCP

tb.

depends on

Necessary Outer

Sub-conditions NOS Sufficient Outer

Sub-conditions SOS

sos.contains

nos.requires sos.validates

ocp.

contains

nos.is target

presumption

Relevant RML Symbols

Set: class concept as

basic construct

Explicit partial many-to-

many relation

Implicit partial many-to-

many relation

Explicit total many-to-

many relation

Each left side set element

explicitly relates to exactly

one right side set element

Fig. 5. Relating Target BSDs and the Outer Conditional Environment

5 Efficacy-aware Business Process Models

Business process modeling languages are mostly oriented at execution seman-

tics of business processes, for instance because this is required for computerized

workflow implementation. In terms of semantics, this requires modeling possible

task sequences, but not the formalization of the impact on target BSDs or en-

actment preconditions (e.g., the availability of labor). We thus need to extend

existing approaches towards efficacy-aware process models.

The Business Process Model and Notation (BPMN) constitutes a broadly ap-

plied language covering common process modeling concepts [3]. Since we aim at

seamless integration with well-established concepts (cf. Figure 1), we use BPMN

as a basis for extension instead of defining an entirely new formalism. Table 2

summarizes the additional terminology required. The meta-model presented in

Figure 6 shows how the necessary terms are interrelated, and how they integrate

with BPMN concepts.

In BPMN, the modeler is generally free with respect to the level of granularity

regarding tasks and activities as atomic or aggregate constructs. In our context,

BPMN Terms Efficacy-aware

Meta-model Terms

Semantic Adaptations

Data objects Environmental ele-

ments: affecting and

affected elements,

target and condi-

tional elements

Environmental elements replace data objects. From the

perspective of the business process, they comprise the

overlapping sub-sets of affecting elements (e.g., data

fields altered) and affected elements (e.g., resources

spent). From the perspective of the business objective,

they comprise target elements and conditional ele-

ments (cf. Section 3.2). Both perspectives overlap. For

example, a target element can be an affected element

and an affecting element.

Conditions

attached to

split gateways

Branches and branch-

conditional BSDs

A branch is a sequence flow succeeding a conditional

split gateway. Branch-conditional BSDs take up the

concept presented in [11]. They are used to describe

split gateway conditions by relating affecting elements

to absolute or relative conditions (e.g., “A = 5” or

“A <B”). Thus, branch-conditional BSDs represent

environmental conditions that co-determine which

tasks are enacted.

[none] Task-requisite BSDs The BSD concept is also used to describe enactment

preconditions attached to tasks. Semantically, we as-

sume that an enabled task is enacted if and only if all

task-requisite BSDs are fulfilled. Task-requisite BSDs

may relate to resources that just need to be available

(e.g., “information system available = true”), or to re-

sources actually spent (e.g., “working time available >

1h”).

[none] State operations State operations related to tasks are used to model

effects on affected elements as functions (e.g., “A = A

+ B”). We assume that if a task is enacted, all related

state operations are executed, and that state opera-

tions related to tasks are the only elements of business

process models with an impact on affected elements.

Table 2. Required Terminology

Environmental

Elements EE

Affecting

Elements AGE

Affected

Elements ADE

Target

Elements TE Conditional

Elements CE

Control Flow

Constructs CFC

Gateways G

Tasks T

t.requires

State

Operations SO t.induces

ade.is left-side element

Task-requisite

Binary State

Determinants TB

Branch-conditional

Binary State

Determinants BCB

age.is

left-side

element

age.is

left-side

element Branches B

requires

b.induces

g.triggers

Relevant RML Symbols

Set: class concept as basic

construct.

Grey elements are comprised

in the BPMN set of constructs;

events, activities, sequence

flow etc. are not shown for

lack of a direct relation to

efficacy-aware extensions

Explicit partial many-to-many

relation

Implicit partial many-to-many

relation

Explicit partial many-to-one

relation

Each left side set element

explicitly relates to exactly one

right side set element

Disjoint total generalization

Overlapping total

generalization

Fig. 6. Efficacy-aware Business Process Meta-model

Task-requisite BSDs:

- Payments list available

- Clerk time available >= 10

State operations:

-Payment identified := Payment received

- Clerk time available -= 10

Check for

payment

Perform

business

impairment

test

Clear open

item

Branch-conditional BSD:

Payment identified

Age

receivable

Branch-conditional BSD:

Amount receivable = 0

Perform

reporting

impairment

test

Post

impairment

Branch-conditional BSD:

Impairment amount = 0

Task-requisite BSDs:

- Manager time available >= 5

State operations:

-Impairment amount :=

business impairment

requirement

- Manager time available -= 5

Task-requisite BSDs:

- Clerk time available >= 10

State operations:

- Impairment amount posted := true

- Amount receivable := amount receivable –

impairment amount

- Clerk time available -= 10

Task-requisite BSDs:

- Aging transaction available

State operations:

- Age class amended := true

Task-requisite BSDs:

- Payment identified

- Clerk time available >= 10

State operations:

-Clearing document posted := true

- Clerk time available -= 10

Task-requisite BSDs:

- Impairment amount available

- Clerk time available >= 5

State operations:

- Impairment amount :=

max(impairment amount,

reporting impairment requirement)

- Clerk time available -= 5

458

10 11

Fig. 7. Exemplary Business Process: Year-end Receivables Processing

however, we need to limit this degree of freedom to obtain stricter execution

semantics. Accordingly, we require tasks to be enacted atomically, i.e., either

in total or not at all. Thus, tasks do not have internal execution semantics.

Trivially, this can be achieved by sufficiently refining tasks during modeling.

Figure 7 illustrates a process modeled in terms of BPMN and amended with

additional information according to Table 2. Its semantics are described in Ex-

ample 4.

Example 4 (Sample Business Process). Figure 7 depicts a sample process model

which corresponds to the business objective model from Figure 4. Relevant con-

trol flow elements have been annotated with reference numbers 1-12.

Business objective and business process relate to the management of receiv-

ables during year-end closing. Receivables are first matched against unallocated

payments (1). If payment has been identified (3), the receivable is cleared (12).

Otherwise (2), it is assessed in an impairment test based on management’s ap-

praisal (4) and formal criteria (5). If an impairment amount has been identified

(7), the impairment is posted (8). If an open item remains (10), it is allocated

to an age class (11). The latter task, for instance, can be enacted if it is enabled

and the aging transaction is available (task-requisite BSD). If it is enacted, the

age class is amended (state operation).

6 Efficacy Assessment Method and Sample Validation

Since our approach towards an efficacy-aware business process models extends

BPMN with a small set of additional terms, we may assume the second effective-

ness criterion (i.e., integration with common modeling languages) to be fulfilled.

Accordingly, our validation focuses on the functional requirement of enabling to

Target BSD

(cf. Fig. 4)

Relevant State Operation

(Task No.)

Control Flow Path Alternatives

(cf. Fig. 7 for reference numbers)

Clearing document

posted

Clearing document posted =

true (12)

(1-3-12)

Impairment document

posted

Impairment document posted

= true (8)

(1-2-4-5-7-8)

Impairment document

NOT posted

Impairment document posted

= true (8)

NOT (1-2-4-5-7-8)

Age class amended Age class amended = true (11) (1-2-4-5-7-8-10-11) OR (1-2-4-5-6-10-11)

Table 3. Target BSDs, State Operations, and Control Flow Paths

assess business process efficacy. Figure 5 shows which information must be avail-

able to allow assessing efficacy. This section discusses, by means of the sample

process described in Example 4, how this information can be derived from an

efficacy-aware business process model and used for efficacy assessment. It thus

demonstrates a method as discussed in Section 2.

To enable efficacy assessment for a business process model, we require infor-

mation about the outer conditional environment of target BSDs as described in

Figure 5. This information is obtained by executing three steps presented in the

following. The fourth step constitutes the actual efficacy assessment.

Step 1 (Matching Target BSDs, State Operations, and Control Flow

Paths). State operations describe the actions carried out on environmental ele-

ments when enacting tasks (cf. Table 2), and are required to fulfil target BSDs.

Table 3 therefore matches target BSDs against relevant state operations and

possible control flow paths to enact the state operations.

Note that, for the third target BSD (Impairment document NOT posted),

the relevant state operation must not be executed to fulfill the target BSD.

This issue generally occurs for fully determinate bivalent target BSDs and for

de-composed trivalent target BSDs (cf. Section 3.2).

Building relevant control flow paths necessitates traversing the process model.

This is trivial for our simple example, but may get more complex in other cases.

Respective algorithms are discussed in, for instance, [24]. Loops with an an

unspecified number of iterations mostly reflect sets of uniform target elements

to be managed. As an example, consider lists of documents to be processed.

In line with common modeling approaches [25], this issue is best addressed by

using a corresponding structure of super- and sub-processes. Efficacy assessment

is then executed separately for each level.

Step 2 (Consolidating Control Flow Paths). To determine the outer con-

ditional environment required to fulfill a target BSD, we need to consolidate

the BSDs comprised in relevant alternative control flow paths (cf. Table 3)

considering the respective state operations. This can be achieved by “merg-

ing” subsequent control flow path elements until each relevant control path has

been consolidated into one set of conditional BSDs. The required operations are

shortly described in this step, but formalized in [26]. Two subsequent control

flow elements are merged as follows:

(a) Apply the state operations of the first element to the BSDs of the second element.

This is necessary to consider that state operations of the first element might affect

BSDs of the second element.

(b) Merge the resulting BSDs with the first element’s BSDs.

This provides us with new sets of BSDs and state operations, which jointly

describe a new virtual control flow element.

Example 5 (Control Flow Path Consolidation). The results of recursively follow-

ing through the consolidation procedure for the first relevant control flow path

of the Age class amended target BSD are presented in Figure 8. The top line de-

picts the relevant control flow path alternative extracted from the process model

(cf. Figure 7). In the second line, the merge operation has been executed for the

first two control flow elements. In this case, the respective sets of BSDs do not

address common environmental elements. Accordingly, the branch-conditional

BSD of (2) has simply been added to the merged set of BSDs of the new virtual

control flow element. The third line shows the results of following through the

merge procedure for the entire control flow path alternative, so that only one

virtual control flow element remains. This element bundles all BSDs and state

operations as though they would be enacted in a single task.

For more complex processes, the consolidation of control flow paths can be

structured along sub-processes that occur multiple times. Virtual control flow

elements can then be re-used. In our example, this applies to 1-2-4-5-7-8: this sub-

path is relevant to both Impairment document posted and Age class amended.

Note that parallel execution paths can be handled by using block-structured

process models and recursively consolidating parallel paths into activities. As

an additional consistency condition, this requires that the affected elements of

neither parallel path are affecting elements of the other one (cf. Table 2).

Step 3 (Building Necessary and Sufficient Sub-conditions). Necessary

and sufficient outer sub-conditions for a target BSD as defined in Figure 5 can

now be derived according to a simple schema:

–Each set of merged BSDs of a consolidated control flow path constitutes a sufficient

outer sub-condition since fulfillment of the BSDs is sufficient to enable the target

BSD. Accordingly, there are as many sufficient outer sub-conditions as there are

control flow path alternatives for a target BSD (cf. Table 3

–Any merged BSD that occurs in each control flow alternative constitutes a nec-

essary outer sub-condition. Note that, for the purpose of necessary outer sub-

conditions, BSDs where the same set of affecting elements is covered in each con-

trol flow alternative are represented by their most “relaxed” form (in our case, this

applies to the available clerk time).

Task-requisite BSDs:

- Payments list available

- Clerk time available >= 10

State operations:

-Payment identified :=

Payment received

- Clerk time available -= 10

Check for

payment

Perform

business

impairment

test

Branch-

conditional

BSD:

No payment

identified

Age

receivable

Branch-

conditional

BSD:

Amount

receivable

> 0

Perform

reporting

impairment

test

Post

impairment

Branch-

conditional

BSD:

Impairment

amount >0

Task-requisite BSDs:

- Manager time available >= 5

State operations:

-Impairment amount :=

business impairment

requirement

- Manager time available -= 5

Task-requisite BSDs:

- Clerk time available >= 10

State operations:

- Impairment document posted := true

- Amount receivable := amount

receivable – impairment amount

- Clerk time available -= 10

Task-requisite BSDs:

- Aging transaction

available

State operations:

- Age class

amended := true

Task-requisite BSDs:

- Impairment amount available

- Clerk time available >= 5

State operations:

- Impairment amount :=

max(impairment amount,

reporting impairment requirement)

- Clerk time available -= 5

1458

210 11

Merged BSDs:

- Payments list available

- Clerk time available >= 10

- No payment received

Perform

business

impairment

test

Age

receivable

Branch-

conditional

BSD:

Amount

receivable

> 0

Perform

reporting

impairment

test

Post

impairment

Branch-

conditional

BSD:

Impairment

amount >0

458

210 11

Merged BSDs:

- Payments list available

- Clerk time available >= 25

- No payment received

- Manager time available >=5

- Business impairment requirement available

- max(business impairment requirement,

reporting impairment requirement) > 0

- Amount receivable > max(business impairment

requirement, reporting impairment requirement

- Aging transaction available

145

10 11

Merged state operations:

-Payment identified := Payment received

- Clerk time available -= 25

- Impairment amount := max(business

impairment requirement, reporting

impairment requirement)

- Manager time available -= 5

- Impairment document posted := true

- Amount receivable := amount receivable –

max(business impairment requirement,

reporting impairment requirement)

- Age class amended := true

Merged state operations:

-Payment identified := Payment received

- Clerk time available -= 10

Intermediate

steps omitted

Fig. 8. Control Flow Path Consolidation Example (cf. Fig. 7)

–If the state operation inducing the target BSD has affecting elements, an addi-

tional necessary outer sub-condition is derived from the image function describing

the operation’s content (cf. [26, Def. 4]): the target presumption as included in

Figure 5. To this end, we substitute the function’s affected element in the target

BSD by the image function. The resulting term yields the target presumption. It

represents environmental conditions not caused by control flow, but by the final

state operation itself.

The resulting sub-conditions are then compared to the respective necessary sub-

conditions of the target BSD as per the objective model. Results for Age class

amended are shown in Table 4.

Binary State Determinants Outer Sub-conditions Objective Model:

Necessary

Sub-conditions

Sufficient:

Path 1

Sufficient:

Path 2

Necessary

Payments list available X X X

Clerk time available ≥25 X

Clerk time available ≥15 X X

Payment received = false X X X X

Manager time available ≥5 X X X

Business impairment req’ment available X X X

max(impairment requirements) >0 X

max(impairment requirements) = 0 X

Amount receivable >max(imp. req’s) X X X

Aging transaction available X X X

Table 4. Target BSDs and the Conditional Environment for Age class amended

Step 4 (Assessing Efficacy). To compare the outer conditional environment

as defined by a process model to the conditional environment of a business

objective, we must mainly consider the inconsistencies. According to Def. 1,

Table 4 enables to conclude:

–Target BSDs included in the business objective but not covered by state operations

signify that the business process is not formally efficacious, because the business

process alone is not sufficient to fulfill all target BSDs. This is not the case in our

example.

–Necessary sub-conditions of the business objective not covered by the process in-

dicate that the business process is not formally efficacious, because it may induce

target BSDs without considering relevant constraints. Again, this is not the case

in our example.

–Necessary outer sub-conditions of the process model with regard to a Target BSD

that do not correspond to necessary sub-conditions of the business objective indi-

cate resources required by the business process to induce a target BSD. It needs

to be judged whether these are considered as reasonable – the process may be not

fully efficacious even if it is formally efficacious.

For our sample process, we can conclude that the process is formally effica-

cious. Whether it is fully efficacious will mainly depend on whether the associ-

ated requirements regarding available labor resources are deemed as reasonable

by subject matter experts. Our sample validation has thus shown that our busi-

ness process meta-model (cf. Figure 6) enables efficacy assessment. As a next

step, we might use the objective model and the assessment method to evaluate

alternative implementation options for business process optimization.

7 Conclusion

In this paper, we built an approach towards efficacy-aware business process mod-

els based on the design science paradigm, insights on related work, and available

results on business objectives modeling. We derived required terminology from

functional requirements, and integrated the results into a meta-model extending

BPMN. We described a method to assess the efficacy of a corresponding process

model, and demonstrated the validity of our approach by application to a sample

case, thus addressing our functional effectiveness criterion.

Together with the business objectives modeling approach presented in [11],

the results presented yield the capabilities required for application scenarios

described in Section 1: the ability to model business objectives independently

from business processes, and the ability to formally assess efficacy. Seamless

integration with established BPM methods is warranted. As an example of how

application scenarios might be further pursued, reconsider our first scenario:

Scenario 1 (Automated Business Process Optimization). Formal efficacy as-

sessment as demonstrated in Section 6 permits to determine whether process adapta-

tions compromise business objective achievement. It thus becomes possible to automat-

ically propose adaptations aimed at cost or time optimization and test their efficacy.

Propositions might either be derived from empirically assessing “wasteful” execution

paths, or based on random selection and subject to subsequent statistical assessment. A

prospective approach would require preliminary determination of the efficacious scope

of action. In this respect, the procedure of consolidating efficacy-aware process models

(cf. Section 6) would have to be inverted.

In addition to adoption of the results presented into practical application

scenarios, future work will also address integration of the business objectives

modeling approach with requirements engineering frameworks such as KAOS

[21]. Corresponding to the integration into the BPM field of knowledge, this will

further improve the practical appeal of the approach.

References

1. Davenport, T.J., Short, J.E.: The new industrial engineering: Information tech-

nology and business process redesign. Sloan Mgmt. Rev. (4) (1990) 11–27

2. Krogstie, J., Sindre, G., Jørgensen, H.: Process models representing knowledge for

action: a revised quality framework. Europ. J. of Inf. Syst. 15(1) (2006) 91–102

3. The Object Management Group: Business Process Model and Notation: Version

2.0 (2011) http://www.omg.org/spec/BPMN/2.0.

4. Scheer, A.W., Thomas, O., Adam, O.: Process Modeling Using Event-Driven Pro-

cess Chains. In: Process-aware Information Systems. Wiley (2005) 119–145

5. Reichert, M., Weber, B.: Enabling Flexibility in Process-aware Information Sys-

tems: Challenges, Methods, Technologies. Springer (2012) to appear.

6. Hallerbach, A., Bauer, T., Reichert, M.: Capturing variability in business process

models: the Provop approach. J. Sw. Mnt. Ev. Res. Pract. 22(6-7) (2010) 519–546

7. Li, C., Reichert, M., Wombacher, A.: Mining business process variants: Challenges,

scenarios, algorithms. Data & Knowl. Eng. 70(5) (2011) 409–434

8. Weber, B., Reichert, M., Mendling, J., Reijers, H.A.: Refactoring large process

model repositories. Comput. Ind. 62(5) (2011) 467–486

9. Camp, R.C.: Benchmarking: the search for industry best practices that lead to

superior performance. Quality Press (1989)

10. IDS Scheer: Process intelligence white paper: What is process intelligence? (2009)

http://www.process-intelligence.com.

11. Lohrmann, M., Reichert, M.: Modeling business objectives. In: Proc. 4th S-BPM

ONE – Scientific Research. LNBIP 104 (2012) 106–126

12. Simon, H.A.: The Sciences of the Artificial. 3rd edn. MIT Press (1996)

13. March, S.T., Smith, G.F.: Design and natural science research on information

technology. Decis. Support Syst. 15(4) (1995) 251–266

14. Kueng, P., Kawalek, P.: Goal-based business process models: creation and evalu-

ation. Bus. Process Manag. J. 3(1) (1997) 17–38

15. Neiger, D., Churilov, L.: Goal-oriented business process modeling with EPCs and

value-focused thinking. In: Proc. 2nd BPM. LNCS 3080 (2004) 98–115

16. Markovic, I., Kowalkiewicz, M.: Linking business goals to process models in se-

mantic business process modeling. In: Proc. 12th EDOC, IEEE (2008) 332–338

17. Soffer, P., Wand, Y.: On the notion of soft-goals in business process modeling.

Bus. Process Manag. J. 11(6) (2005) 663–679

18. Lin, Y., Sølvberg, A.: Goal annotation of process models for semantic enrichment

of process knowledge. In: Proc. 19th CAiSE. LNCS 4495 (2007) 355–369

19. Engelsman, W., Quartel, D., Jonkers, H., van Sinderen, M.: Extending enterprise

architecture modelling with business goals and requirements. Ent. Inf. Sys. 5(1)

(2011) 9–36

20. Yu, E.S.K.: Towards modelling and reasoning support for early-phase requirements

engineering. In: Proc. 3rd Int’l Symp. on Requirements Engineering, IEEE (1997)

226–235

21. Dardenne, A., van Lamsweerde, A., Fickas, S.: Goal-directed requirements acqui-

sition. Sc. of Comp. Programming 20(1-2) (1993) 3–50

22. Ly, L.T., Knuplesch, D., Rinderle-Ma, S., G¨oser, K., Pfeifer, H., Reichert, M.,

Dadam, P.: Seaflows toolset – compliance verification made easy for process-aware

information systems. In: Proc. CAiSE’10 Forum. LNBIP 72 (2010) 76–91

23. Sølvberg, A.: Data and what they refer to. In: Conceptual Modeling. Springer

(1999) 211–226

24. Cormen, T.H., Leiserson, C.E., Rivest, R.L., Stein, C.: Introduction to Algorithms.

3rd edn. MIT Press (2009)

25. Weske, M.: Business Process Management. Springer (2007)

26. Lohrmann, M., Reichert, M.: Formalizing concepts for efficacy-aware business pro-

cess modeling. Technical Report UIB-2012-05, Databases and Information Systems

Institute, Ulm University (2012)