This is the author’s version of a work that was submitted/accepted for pub-lication in the following source:

Conforti, Raffaele, La Rosa, Marcello, Fortino, Giancarlo, ter Hofstede,Arthur H.M., Recker, Jan C., & Adams, Michael J.(2013)Real-time risk monitoring in business processes : a sensor-based ap-proach.Journal of Systems and Software, 86(11), pp. 2939-2965.

This file was downloaded from: https://eprints.qut.edu.au/58321/

c© Copyright 2013 Elsevier

This is the author’s version of a work that was accepted for publication in Journal of Sys-tems and Software. Changes resulting from the publishing process, such as peer review,editing, corrections, structural formatting, and other quality control mechanisms may not bereflected in this document. Changes may have been made to this work since it was submit-ted for publication. A definitive version was subsequently published in Journal of Systemsand Software, [Volume 86, Issue 11, (November 2013)] DOI: 10.1016/j.jss.2013.07.024

Notice: Changes introduced as a result of publishing processes such ascopy-editing and formatting may not be reflected in this document. For adefinitive version of this work, please refer to the published source:

https://doi.org/10.1016/j.jss.2013.07.024

Real-Time Risk Monitoring in Business Processes:

A Sensor-based Approach

Raffaele Confortia, Marcello La Rosaa,b, Giancarlo Fortinoc, Arthur H. M. ter Hofstedea,d,Jan Reckera, Michael Adamsa

aQueensland University of Technology, GPO Box 2434, Brisbane QLD 4001, AustraliaE-mail: {raffaele.conforti,m.larosa,a.terhofstede,j.recker,mj.adams}@qut.edu.au

bNICTA Queensland Lab, Brisbane, AustraliacUniversita della Calabria, Via P. Bucci, cubo 41C, 87036 Rende (CS), ITALY

E-mail: g.fortino@unical.itdTechnische Universiteit Eindhoven, P.O. Box 513, 5600 MB Eindhoven, The Netherlands

Abstract

This article proposes an approach for real-time monitoring of risks in executable businessprocess models. The approach considers risks in all phases of the business process man-agement lifecycle, from process design, where risks are defined on top of process models,through to process diagnosis, where risks are detected during process execution. The ap-proach has been realized via a distributed, sensor-based architecture. At design-time, sensorsare defined to specify risk conditions which when fulfilled, are a likely indicator of negativeprocess states (faults) to eventuate. Both historical and current process execution data canbe used to compose such conditions. At run-time, each sensor independently notifies a sensormanager when a risk is detected. In turn, the sensor manager interacts with the monitor-ing component of a business process management system to prompt the results to processadministrators who may take remedial actions. The proposed architecture has been im-plemented on top of the YAWL system, and evaluated through performance measurementsand usability tests with students. The results show that risk conditions can be computedefficiently and that the approach is perceived as useful by the participants in the tests.

1. Introduction

Business processes are constantly exposedto a wide range of risks. As demonstratedby the recent incidents in the finance sec-tor (the e 4.9B fraud at Societe Generale[47]; the US$2.3B UBS rogue trading scan-dal [33]), in the health sector (the Patel In-quiry [96, 44]) and in the aviation industry(terrorist attacks [101]), failures of process-driven risk management can result in sub-

stantial financial and reputational conse-quences, potentially threatening an organi-zation’s existence.

According to the AS/NZS ISO 31000standard, a business process risk is thechance of something happening that willhave a negative impact on the process objec-tives, and is measured in terms of likelihoodand consequence [89]. Legislative initiatives

Preprint submitted to Journal of Systems and Software August 6, 2013

such as the Sarbanes-Oxley Act1 and BaselII [8] in the finance sector have highlightedthe pressing need to better manage busi-ness process risks. As a consequence ofthese mandates, organizations are now seek-ing new ways to control process-related riskand are attempting to incorporate it as adistinct view in their operational manage-ment [100, 75]. However, whilst conceptu-ally appealing, to date there is little guid-ance as to how this can be done concretely.Currently, the disciplines of process man-agement and risk management are largelydisjoint and operate independently of oneanother [92]. In industry they are usuallyhandled by different organizational units,where the disconnectedness of the risk con-trol systems in place provide an environ-ment for potentially massive risk exposure.

For example, in the UBS case, whilethe bank employed best-practice financialrisk management strategies, the fraud en-acted by a single trader exploiting a con-firmation activity in the exchange-tradedfunds process may potentially have contin-ued for years without being detected [66].UBS later admitted that the disengaged na-ture of their risk and operational systemsmeant that, while some unexplained ac-tivity had been detected, it was not suffi-ciently investigated, nor were existing riskcontrols enforced [32, 33]. Rather, regularrisk reports, internal audits and externalreviews repeatedly delivered positive out-comes, leading to management complacencyand a lack of healthy mistrust [90]. An-other case in point is that of KfW Banken-gruppe, which in 2008 transferred e 300Mto Lehmann Brothers using an automatedtransfer facility hours before Lehmann de-clared bankruptcy [79]. Such examples il-

1www.gpo.gov/fdsys/pkg/PLAW-107publ204

lustrate a clear misalignment between riskmanagement and the (automated) enact-ment of business operations. Disasters likethese are likely to become more prevalentas businesses increasingly rely on heteroge-neous, complex and distributed ICT sys-tems for their day-to-day operations. Ofcourse, proper risk management is not onlypivotal in the finance sector, but also playsa central role in many other domains, in-cluding health (e.g., limiting the spread ofdiseases and minimizing exposure to litiga-tion), mining (e.g., physical safety), and avi-ation (e.g., maintenance and terrorism).

Within academia, recent research hascentered on the characterization of process-related risks. While risk metrics and mitiga-tion procedures have been broadly explored[89], such generalized strategies fail to tar-get the specific requirements of process-centric operationalization. Conversely, nu-merous techniques have been developed forspecific domains [3, 57, 43, 13], but the na-ture of such techniques renders them unableto offer strategies that can readily be ap-plied more generally.

Effective risk management is imperativefor organizational survival, and incidentssuch as those described above reveal thatproper integration of risk management withprocess management is now vital. Fur-ther, a focus on risk analysis alone is nolonger adequate. Rather, active, real-timerisk detection, analysis and mitigation is re-quired. Real-time risk detection is partic-ularly essential in mission-critical businessprocesses or those involving life-saving ac-tivities [20, 65]. Through the integrationof the risk management and process man-agement domains, a number of key ben-efits may be realized, from incorporatingrisk analysis and mitigation strategies dur-ing the process design phase, to monitoring

2

and mitigating emerging risks during pro-cess execution, to post-execution risk anal-ysis using process log data.

We propose a concrete approach for real-time monitoring of risks in executable busi-ness process models. This is achieved by in-corporating risk management into all phasesof the BPM lifecycle: from process design,where high-level risks defined via a riskanalysis method are mapped down to spe-cific process model elements such as activi-ties, resources and data, through to processdiagnosis, where risks are detected duringprocess execution. By automating risk de-tection, the interested users (e.g. a processadministrator or a risk manager) can be no-tified as early as a risk is detected (i.e. inreal-time), such that remedial actions canbe taken to rectify the current process in-stance, and prevent an undesired state ofthe process (fault for short), from occurring.Based on historical data, we can also com-pute the probability of a risk at run-time,and compare it to a threshold, so as to no-tify the user only when the risk is no longertolerable.

The proposed approach is operationalizedvia a distributed, sensor-based architectureon top of Business Process ManagementSystems (BPMSs). Each sensor is coupledwith a risk condition capturing the situationupon which the risk of a given fault may oc-cur. Sensors are defined at design-time onthe executable process model. Conditionscan be determined via a query language thatcan fetch both historical and current ex-ecution data from the logs of the BPMS.At run-time sensors are registered with acentral sensor manager. At a given sam-pling rate, or based on the occurrence of aspecific event, the sensor manager retrievesand filters all data relevant for the varioussensors (as it is logged by the BPMS en-

gine), and distributes it to the relevant sen-sors. If a sensor condition holds, i.e. if theprobability of the associated risk is above agiven threshold, the sensor alerts the sensormanager which in turn notifies the moni-toring component of the BPMS. The dis-tributed nature of the architecture guar-antees that there is no performance over-head on the BPMS engine, and thus on theexecution of the various process instances.We implemented this architecture on topof the YAWL system [95]. We extendedthe YAWL Editor to cater for the designof risk sensors, and equipped the run-timeenvironment with a sensor manager servicethat interacts with YAWL’s monitoring ser-vice and execution engine. Finally, to facil-itate the definition of process risks, we im-plemented a set of risk templates for vari-ous categories, such as organizational, data-related and technology-related. Such tem-plates are abstract risk definitions whichusers need to bind to concrete process el-ements.

To prove the feasibility of the proposedapproach, we used fault tree analysis [21](a well-established risk analysis method) toidentify risk conditions in a reference pro-cess model for logistics, in collaborationwith an Australian risk consultant. Theserisks embrace different process aspects suchas tasks’ order dependencies, involved re-sources and business data, and relate to his-torical data where needed, to compute riskprobabilities. We expressed these condi-tions via sensors in the YAWL system, andmeasured the time needed to compute theseconditions at run-time. The tests showedthat the sensor conditions can be computedin a matter of milliseconds without impact-ing on the performance of the running pro-cess instances. Finally, we conducted a us-ability analysis of the approach and its im-

3

plementation, by inviting 21 students to re-port on their experiences while using the ap-proach for analyzing and defining risk sen-sor conditions. The results from this exper-iment show that the approach is being per-ceived as interesting and useful, especiallyby novice users, confirming an intention ofthe participants to use it.

This paper is organized as follows. Sec-tion 2 illustrates the running example inthe logistics domain. Section 3 describesour risk-aware BPM approach while Sec-tion 4 presents the sensor-based architec-ture to implement this approach. Section 5formalizes the abstract syntax of the lan-guage proposed for risk detection while Sec-tion 6 shows how the risks defined on therunning example can be modeled via thislanguage. Next, Section 7 proposes a setof risk templates to facilitate the definitionof process risks. Section 8 illustrates theimplementation of the sensor-based archi-tecture, while Section 9 reports on the re-sults of the performance and usability evalu-ations. Section 10 covers related work whileSection 11 concludes the paper. AppendixA provides the complete abstract syntaxof the language for sensor conditions; Ap-pendix B provides a short description of theactions defined in the language; AppendixC describes the nested loops that can beexecuted during the verification of a sensorcondition while Appendix D describes thefunctions that can be invoked on variables(that are resources) during the verificationof a sensor condition. Finally, Appendix Eprovides the questionnaire used in the us-ability tests.

2. Running Example

In this section we use an example to illus-trate how the risk of possible faults to occur

during a business process execution can bedetected as early as possible. In particular,we show how risks can be expressed in termsof process-specific aspects such as tasks oc-currence, data or available resources. Fig-ure 1 describes the payment subprocess ofan order fulfillment business process whichis inspired by the VICS industry standardfor logistics [98]. The notation used to rep-resent this example is that of YAWL [95],although a deep knowledge of this languageis not required.

This process starts after the freight hasbeen picked up by a carrier and deals withthe shipment payment. The first task isthe production of a Shipment Invoice con-taining the shipment costs related to a spe-cific order for a specific customer. If ship-ments have been paid in advance, all thatis required is for a Finance Officer to is-sue a Shipment Remittance Advice speci-fying the amount being debited to the cus-tomer. Otherwise, the Finance Officer is-sues a Shipment Payment Order that needsto be approved by a Senior Finance Officer(who is the superior of this Finance Offi-cer). At this point, a number of updatesmay be made to the Shipment Payment Or-der by the Finance Officer that issued it,but each of these needs to be approved bythe Senior Finance Officer. After the docu-ment is finalized and the customer has paid,an Account Manager can process the ship-ment payment by specifying the balance. Ifthe customer underpaid, the Account Man-ager needs to issue a Debit Adjustment, thecustomer needs to pay the balance and thepayment needs to be reprocessed. A cus-tomer may also overpay. In this case theAccount Manager needs to issue a CreditAdjustment. In the latter case and in caseof a correct payment, the shipment paymentprocess is completed.

4

Process ShipmentPayment

Approve Shipment Payment Order

[payment incorrect due to overcharge]

[payment correct]

[payment incorrect due to underpayment]

Input condition

Outputcondition

Task

[else]

[pre-paid shipments]

Issue Shipment Invoice

Issue Shipment Remittance Advice

[order approved]

[ordernot approved]

Issue Shipment Payment Order

Update Shipment Payment Order

Settle Account

ReceivePayment

Issue CreditAdjustment

Issue DebitAdjustment

ReceivePayment

XOR join XOR splitArc

Figure 1: Order-Fulfillment: Payment subprocess.

In collaboration with a risk analyst of anAustralian consulting company, we identi-fied four faults that can occur during the ex-ecution of this payment subprocess. In or-der to prevent the occurrence of these faults,for each of them we also defined an associ-ated risk condition by using fault tree anal-ysis [21]. Accordingly, each risk conditionis expressed as a set of lower-level booleanevents which are organized in a tree via log-ical connectives such as ORs, ANDs andXORs, an example of fault tree is shownin Figure 2.

The first fault is an overtime processfault. A Service Level Agreement (SLA)for a process or for a given task within aprocess, may establish that the process (ortask) may not last longer than a MaximumCycle Time MCT , otherwise the organiza-tion running the process may incur a pecu-niary penalty. In our case, an overtime faultoccurs if an instance of the payment subpro-cess is not completed within an MCT of fivedays.

To detect the risk of overtime fault atrun-time, we should check the likelihoodthat the running instance does not exceedthe MCT based on the amount of time Tc

expired at the current stage of the execu-tion. Let us consider Te as the remaining cy-cle time, i.e. the amount of time estimatedto complete the current instance given Tc.Then the probability of exceeding MCT

can be computed as 1 − MCT/(Te + Tc)if Te + Tc > MCT and is equal to 0 ifTe+Tc ≤ MCT . If this probability is greaterthan a tolerance value (e.g. 60%), we notifythe risk to the user. The estimation of theremaining cycle time is based on past execu-tions of the same process and can be com-puted using the approach in [1], wherebyusing an annotated transition system an es-timation of the remaining cycle is calculatedby replaying the trace on the transition sys-tem and returning the expected time anno-tated on the last node visited (see Section 9for more details).

The second fault is related to the re-sources participating in the process. TheSenior Finance Officer who has approved aShipment Payment Order for a given cus-tomer, must have not approved another or-der by the same customer in the last d days,otherwise there is an approval fraud. Thisfault is thus generated by the violation of afour-eye principle across different instancesof the Payment subprocess.

To detect the risk of this fault we firsthave to check that there is an order, say or-der o of customer c, to be approved. Thismeans checking that an instance of task Ap-prove Shipment Payment Order is being ex-ecuted. Moreover, we need to check thateither of the following conditions holds: i)o has been allocated to a Senior FinanceOfficer who has already approved another

5

order for the same customer in the last ddays; or ii) at least one Senior Finance Of-ficer is available who approved an order forcustomer c in the last d days and all otherSenior Finance Officers who never approvedan order for c during the last d days arebusy. The corresponding fault tree is shownin Figure 2.

The third fault relates to a situationwhere a process instance executes a giventask too many times. This situation typ-ically occurs in the context of loops. Notonly could this lead to a process slowdownbut also to a “livelock” if the task is in aloop whose exit condition is purposefullynever met. In general, given a task t a max-imum number of allowable executions of tper process instance MAE i(t) can be fixedas part of the SLA for t. With referenceto the Payment subprocess, this can occurfor example if task Update Shipment Pay-ment Order is re-executed five times withinthe same process instance. We call this anorder unfulfillment fault.

To detect the risk of this fault at run-time, we need to check if: i) an order ois been updated (i.e. task Update Ship-ment Payment Order is currently being per-formed for order o); and ii) it is likely thatthis order will be updated again (i.e. taskUpdate Shipment Payment Order will berepeated within the same process instance).The probability that the number of timesa task will be repeated within the same in-stance of the Payment subprocess is com-puted by dividing the number of instanceswhere the MAE i for task Update ShipmentPayment Order has been reached, over thenumber of instances that have executed thistask at least as many times as it has beenexecuted by the current instance, and havecompleted. The tolerance value indicates athreshold above which the risk should be

notified to the user. For example, if thisthreshold is 60% for task t, a risk shouldbe raised if the probability of MAE i(t) isgreater than 0.6.

The fourth fault is an underpaymentfraud. It relates to a situation in which agiven task is executed too many times acrossmultiple process instances. Similar to theprevious fault, given a task t we can definea maximum number of allowable executionsof t per process MAE p(t) as part of the SLAfor p. In our example, this type of fault oc-curs when a customer underpays more thanthree times within the last five days.

To detect the risk of underpayment fraud,we need to check if: i) a debit adjustment iscurrently being issued to a customer c (i.e.task Issue Debit Adjustment is currently be-ing performed for customer c); and ii) it islikely that the maximum number of debitadjustments will be issued to the same cus-tomer in a d-day time frame. The proba-bility that MAE p is reached for task IssueDebit Adjustment of customer c in d daysis computed by dividing the number of cus-tomers for which the MAE p for task IssueDebit Adjustment has been reached withind days, over the number of customers forwhich this task has been executed at leastas many times as it has been executed forc within d days. If this probability is abovea tolerance value, the risk should be raisedand the user notified. Similar to the pre-vious risk, the tolerance value indicates athreshold above which this risk should benotified to the user. The correspondingfault-tree is shown in Figure 2.

3. Risk-aware Business Process Man-agement

As we have seen in the context of thepayment example, a process-related fault is

6

Allocation to same resource

Approval of o allocated to Senior Finance Officer r

r approved another orderfor customer c in the

last d days

Other resourcesare busy

At least one Senior FinanceOfficer is available who

approved an order for customer c in the last d days

All other Senior FinanceOfficers who never approved an

order for c in the last d daysare busy

Order o ofcustomer c needs to be

approved

Approval fraudrisk

Debit adjustment beingissued to customer c

for order o

Underpayment fraudrisk

Another debit adjustmentis likely to be issued

to c for the same order o

Event Conditional event

LogicalAND

LogicalOR

Figure 2: The fault trees for Approval Fraud and Underpayment Fraud.

an unwanted situation that will negativelyimpact upon the objectives of the busi-ness process (e.g. the violation of a policymay lead to a process instance being inter-rupted), and is identified by a fault condi-tion and a consequence. Identifying a faultin a process requires determining the condi-tion upon which the fault occurs. For exam-ple, in the payment subprocess, we have anunderpayment fraud if a customer under-pays more than three times within a five-day time frame.

However, a fault condition holds onlywhen the associated fault has occurred,which is typically too late to avoid a processfailure. Indeed, we need to be able to esti-mate the risk of a process fault, i.e. if, andpossibly with what likelihood, the fault willoccur in the future. A process-related riskis the chance of a process-related fault hap-pening and is measured in terms of conse-quence (inherited from it related fault) andlikelihood. Early risk detection allows pro-cess users to promptly react with counter-measures, if any, to prevent the related faultfrom occurring at all.

We use the notion of risk condition, asopposed to fault condition, to describe the

set of events that lead to the possibility of afault to occur in the future. In order to eval-uate risk conditions “on-line”, i.e. while aprocess instance is being executed, we needto consider the current state of the BPMS.This means knowing the state of all run-ning instances of any process (and not onlythe state of the instance for which we arecomputing the risk condition), the resourcesthat are busy and those that are available,and the values of the data variables beingcreated and consumed. Moreover, we needto know the historical data, i.e. the execu-tion data of all instances that have beencompleted. In particular, we can use his-torical data to estimate the probability ofa given fault to occur, i.e. the risk proba-bility. For example, for the underpaymentfraud, we can estimate the likelihood thatanother debit adjustment is being issuedfor a given combination of customer/order(historical data), given that one such debitadjustment has just been issued (currentdata). To obtain a boolean risk condition,we compare the risk probability that we ob-tain with a tolerance value, such that thecondition holds if the risk probability ex-ceeds the given threshold. For example, we

7

Process

Implementation

Risk-aware workflow

implementation

Risk

Identification

Risk analysis

Risk-annotated

models

Risk-annotated

workflows

Current

process data

Historical

process dataRisk-related

Improvements

Process Design

Risk-aware

process modelling

1

2

3

4Process Diagnosis

Risk monitoring and

mitigation

Process

Enactment

Risk-aware

workflow execution Risk-related

Improvements

Reporting

Risks

Figure 3: Risk-aware Business Process Management lifecycle.

raise the risk of underpayment fraud if therisk probability is greater then 60%.

In other cases, we may avoid to embed arisk probability in the risk condition, if weare able to determine the occurrence of aset of events which directly leads to a highrisk. This is the case of the approval fraud,where both the events “Allocation to sameresource” and “Other resources are busy”already signal a high risk of approval fraud.

Based on these considerations, we presenta novel approach for on-line risk detectionin business processes. The focal idea of thisapproach, shown in Figure 3, is to embedelements of risk into all four phases of thetraditional BPM lifecycle [31].

Input to this “risk-aware” BPM lifecycleis a Risk Identification phase, where riskanalysis is carried out to identify risks in theprocess model to be designed. Traditionalrisk analysis methods such as FTA (as seenin the previous section), Root Cause Anal-ysis [50] or CORAS [58], can be employedin this phase. The output of this phase isa set of risks, each expressed as a risk con-dition. It is important to notice that notall risks identified during risk analysis canbe avoided by preemptively modifying the

business process in which they may even-tuate. For example, an overtime risk, i.e.the risk of not completing a process instancewithin the required time limit, depends onthe particular way in which the given pro-cess instance is being executed. Our ap-proach specifically targets those risks thatcan only be detected during process execu-tion.

Next, in the Process Design phase, thesehigh-level risk conditions are mapped downto process model-specific aspects. For ex-ample, the condition “debit adjustment be-ing issued to customer c for order o” ismapped to the occurrence of a specific task,namely “Issue Debit Adjustment” in thePayment process model. The result of thissecond phase is a risk-annotated processmodel. In the next phase, Process Imple-mentation, these conditions are linked toworkflow-specific aspects, such as contentof variables, and resource allocation states.For example, “customer c” is linked to theCustomer element of the XML representa-tion of the Debit Adjustment document.Process Implementation may be integratedwith Process Design if the language used atdesign-time is executable (e.g. BPMN 2.0 or

8

YAWL).The risk-annotated workflow model re-

sulting from Process Implementation is thenexecuted by a risk-aware process engine dur-ing Process Enactment. Historical datastored in process logs, and current execu-tion data coming from process enactment,are filtered, aggregated and analyzed in theProcess Diagnosis phase, in order to evalu-ate the various risk conditions. When a riskcondition evaluates to true, the interestedusers (e.g. a process administrator) are no-tified and reports can also be produced dur-ing this phase for auditing purposes. Fi-nally, this phase can trigger changes to thecurrent process instance, in order to miti-gate the likelihood of a fault to occur, or inthe underlying process model, to prevent agiven risk from occurring ever again.

In the next section we describe a sensor-based architecture to operationalize our ap-proach, according to the enhanced BPMlifecycle described above. In particular, theapproach does not cover Risk Identification,since the deliverables of this phase (e.g. afault tree) are already available in any or-ganization that conducts risk analysis. Asfor the last phase of the lifecycle (ProcessDiagnosis), in this paper we only focus onthe risk monitoring part. Risk mitigationis not in the scope of this paper as we pro-posed a solution to this problem in separatework [24]. More information on this solu-tion is provided in the Related Work sec-tion.

4. Sensor-based Realization

In order to realize our risk-aware BPMlifecycle, we devised an approach based onsensors. In a nutshell, the idea is to capturerisk and fault conditions via sensors, andthen monitor these sensors during process

execution. An overview of this approach isshown in Figure 4 using the BPMN 2.0 no-tation [68].

Sensors are defined during the ProcessDesign and Process Implementation phasesof our risk-aware BPM lifecycle (see Fig-ure 3), for each process model for which thepresence of risks and/or faults need to bemonitored. If the process model is specifiedvia an executable language, then these twophases coincide.

A sensor is defined through a booleansensor condition, constructed on a set ofprocess variables, and a sensor activationtrigger. Process variables are used to re-trieve information from the specific instancein which the sensor condition will be evalu-ated as well as from other instances, eithercompleted or still running. For example, wecan use variables to retrieve the resource al-located to a given task, the value of a taskvariable, or the status of a task. Process in-stances can either be identified based on thecurrent instance (e.g. the last five instancesthat have been completed before the cur-rent one), or based on the fulfillment of acase condition (e.g. “all instances where agiven resource has executed a given task”).The sensor condition can represent either arisk condition associated with a fault, or afault condition, or both. If both conditionsare specified, the fault condition is evalu-ated only if the risk condition evaluates totrue. For example, the sensor will check ifan overtime process fault has occurred ina process instance only if first the risk ofsuch fault has first been detected, based onthe estimation of the remaining cycle timefor this instance. Finally, the sensor acti-vation trigger can be either a timer peri-odically fired according to a sampling rate(e.g. every 5 minutes), or an event emittedby the process engine (e.g. the completion

9

Sensor-based Architecture - PostCameraReady

Enact ProcessModel

Processmodel

Define sensor

Processcase

Processlogs

Sensor

Register sensor

Monitor sensor

Update sensordata

Check sensorcondit ion

Sendnotif icat ion

Triggeroccurred

Process instancecompleted

For each sensor

Suff icientdata

Sensorcondit ion

fulf illed

Insuff icientdata Sensor condit ion

not fulf illed

Dr La Rosa Marcello 1 of 1 23.09.2011

Figure 4: Realization of risk-aware BPM lifecycle via sensors.

of a task).

During Process Enactment, the definedsensors are registered with a sensor man-ager, which activates them. In the ProcessDiagnosis phase, which starts as soon asthe process is enacted, the activated sen-sors receive updates on the variables of theirsensor conditions according to their trigger(timer or event). When a sensor receivesan update, it checks its sensor condition.If the condition holds, a notification is sentfrom the sensor to the monitor service of theBPMS.

The sensor manager relies on three inter-faces to interact with the BPMS (see Fig-ure 5(a)):

� Engine interface, used to register a sen-sor with a particular event raised bythe BPMS engine. When the event oc-curs the sensor is notified by the sensormanager.

� Database interface, used to query theBPMS database in order to collect cur-rent and historical information.

� Monitor interface, used to notify thedetection of risks and faults to the mon-itor service of the BPMS.

These interfaces can be implemented bythe vendor or user of the BPMS where thesensor manager needs to be installed. Inthis way, our sensor manager can virtuallybe interfaced with any BPMS. As an exam-ple, the conceptual model of the databaseinterface is showed in Figure 5(b), wheremethods have been omitted for space rea-sons. This conceptual model is inspiredby the reference process meta-model of theWfMC [45], in order to cover as many as-pects as possible of a workflow model, andmeantime, to remain as generic as possible.For example, class WorkFlowDefinition al-lows one to retrieve information about theprocess model where the sensor is defined,such as process identifier and name, whileclass SubProcess allows one to retrieve in-formation about a specific subprocess, andso on. This interface should be implementedaccording to the characteristics of the spe-cific database used in the BPMS at hand.For an efficient use of the interface, oneshould also define indexes on the attributesof the BPMS database that map the un-derlined attributes in Figure 5(b). Theseindexes have been determined based on thetypes of queries that can be defined in oursensor definition language.

10

Process engine

Sensor Manager

Monitor service

Process logsSensors

BPMS

DBint.face

Engineint.face

Monitorint.face

(a)

(b)

Figure 5: Sensor-based architecture (a); DatabaseInterface schema model (b).

An alternative approach to achieve theportability of the sensor manager, would beto read the BPMS logs from a standard se-rialization format such as OpenXES [38].However, as we will show in Section 9, thissolution is rather inefficient.

The advantages of using sensors aretwofold. First, their conditions can be mon-itored while the process model is being exe-cuted, i.e. in real-time. Second, accordingto a distributed architecture, each sensortakes care of checking its own condition af-

ter being activated by the sensor manager.In this way, potential execution slowdownsare avoided (e.g., the process engine and thesensor manager could be deployed onto twodifferent machines).

5. Sensor Definition Language: Ab-stract Syntax

In this section we describe the abstractsyntax [63] of the sensor definition language.A detailed description of all elements of thisabstract syntax is reported in Appendix A.The sensor definition language shares com-mon aspects with programming languagessuch as with query languages, since it is in-spired to JAVA from a syntactic point ofview and to SQL for its semantics. Duringthe definition of the sensor definition lan-guage we took in consideration the designprinciples discussed in [39, 9], in particu-lar: i) expressibility: is the language expres-sive?; ii) completeness: can the language de-scribe all objects of interest?; iii) extensibil-ity: can the language be easily extended?;iv) formal foundation: is the language for-mally defined in order to guarantee unam-biguity and executability?.

The design principle of expressibility ledto the introduction of various constructssuch as conditional and looping ones (dis-cussed later in this section). The principleof completeness led to the definition of el-ements of the language that allow the re-trieval of all information related to a workitem or a process instance available to theworkflow engine. In order to make the lan-guage extensible, we structured it hierarchi-cally allowing an easy introduction of newconstructs. Finally, the formal foundationof the language drove the implementationof the language and of its interpreter.

The definition of a sensor requires a risk

11

condition, a boolean fault condition, a sen-sor activation trigger, and a consequencewhich represents the gravity of the impactthe fault will have on the company in caseit occurs. The trigger can be a timer basedon a sampling rate, or an event producedby the engine interface. Risk condition andfault condition are constructed on a set ofprocess variables. A variable is defined witha mapping among a varName and an Info.

Sensor ,v : Variables; t : Trigger ;riskCond : RiskCon;faultCond : BoolCon;consequence : MaCon;

Trigger , timer | event

Variables ,Assignment+

Assignment , result : varName; i : Info

This Info can be a constant (usingDefinition), or the result of a functionexecuted on a variable (using VarFun),or a piece of information collected fromthe process instance (using CaseExp orCaseEleExp). We use a CaseExp if the in-formation is related to the process instanceitself, while a CaseEleExp if the informationis related to an element of a process instance(that must be specified using TaskOrNetthat identifies a task by taskLabel or a netby netName).

Info ,Definition | VarFun |CaseExp | CaseEleExp

VarFun ,ResCon | ResSimFun |ResComFun

Definition , c : constant

CaseEleExp ,ce : CaseExp; ton : TaskOrNet

TaskOrNet , taskLabel | netName

When we use a CaseExp we mustspecify the instances of interest (usingCaseIDStat), and the action that identi-fies the piece of information (using Action).Such Action can either be an informationrelated to a predicate function, a predicate

function with input, a task or net variable(i.e. a variable at the level of tasks or a vari-able at the level of processes), or a task ornet subvariable (i.e. a subvariable of a taskvariable or a net variable, respectively). Aninstance can be identified in various ways,by its position among all the instances of thesame process model (using absExp), by itsposition respect the current instance (usingrelExp), or by the fulfillment of some con-ditions (using CaseConSet).

CaseExp ,cis : CaseIDStat ; a : Action

CaseIDStat ,absExp | relExp | CaseConSet

Action ,predAct | inputPredAct |taskOrNetVar | SubVarExp

SubVarExp ,var+

These conditions can be on the identifierof the process instance (using CaseParam),or on a piece of information related to atask or a net (using CaseCon). It is alsopossible to specify multiple conditions thatare obtained by the conjunction of severalCaseParam and CaseCon elements (usingCaseConExp).

CaseConSet ,CaseCon | CaseParam |CaseConExp

CaseConExp ,ccs1 , ccs2 : CaseConSet ;bo : BoolOp

CaseCon , ton : TaskOrNet ; a : Action;co : CompOp; rhe : RHExp

CaseParam , i : idFun; co : CompOp;rhe : RHExp

CompOp , le | leq | ge | geq | eq |contains | isContained

Whether using a CaseParam or a CaseConit will be compared with a RHExp. ARHExp can be a constant , a function, avarName, or an expression containing thoseelements (using RHExpSet).

RHExp ,constant | function |varName | RHExpSet

RHExpSet , rhe1 , rhe2 : RHExp; o : Op

12

Once all the variables have been speci-fied the risk condition can be defined. ARiskCon is composed of two MaCon ele-ments, one is the risk likelihood and theother is the risk threshold. A risk condi-tion evaluates true if the likelihood exceedsthe threshold. A MaCon is an arithmeticalexpression that can use constants, variables,results of functions invoked on variables (us-ing ResSimFun, and ResComFun), and theresults obtained by the execution of loops(using MaFor , and FixMaFor). A MaConmay be in a conditional form, representedas MaITE , or be a normal expression rep-resented as MaExp, despite it is always pos-sible to have conditional elements inside anormal expression. A conditional expres-sion MaITE is composed of a BoolCon rep-resenting the if and two MaCons represent-ing the then and else clauses, respectively.

RiskCon , riskL, riskT : MaCon

MaCon ,MaITE | MaFor | ResSimFun |MaExp | FixMaFor | constant |ResComFun | varName

MaITE , if : BoolCon; then, else : MaCon

From the definition of the MaExp ele-ment on, the syntax describes an arithmeti-cal expression. In fact a MaExp elementcan be solved via the analysis of an unaryexpression MaUnExp (i.e. a negative ex-pression) or a binary expression MaBinExp,that is an arithmetical operation betweentwo MaCons.

MaExp ,MaUnExp | MaBinExp

MaUnExp , s : sub; me : MaCon

MaBinExp ,me1 ,me2 : MaCon; mo : MaOp

MaOp ,add | sub | mul | div | exp | mod

As said before a condition expression isdefined using a BoolCon. A BoolCon is aboolean expression that can use constants,variables, results of functions invoked onvariables (using ResCon), and the resultsobtained by the execution of loops (using

BoolFor , and FixBoolFor). A BoolCon maybe in a conditional form, represented asBoolITE , or be a normal expression rep-resented as BoolExp, despite it is alwayspossible to have conditional elements in-side a normal expression. A conditionalexpression BoolITE is composed of threeBoolCons representing the if, the then, andthe else.

BoolCon ,BoolITE | BoolExp | BoolFor |FixBoolFor | Comp | ResCon |varName | constant

BoolITE , if , then, else : BoolCon

The BoolExp element represents a booleanexpression that is describes from this pointon. In fact a BoolExp element can besolved via the analysis of an unary ex-pression BoolUnExp or a binary expressionBoolBinExp, that can contain the result ofa comparison Comp, and so on.

BoolExp ,BoolUnExp | BoolBinExp

BoolUnExp ,n : neg ; e : BoolCon

BoolBinExp ,e1, e2 : BoolCon; bo : BoolOp

BoolOp ,and | or

Comp ,ce1 , ce2 : CompElem;co : CompOp

CompElem ,MaCon | ResListFun |varName | constant

CompOp , l | leq | eq | geq | g | noteq

The functions that can be invoked ona variable are identified by the elements:ResCon, ResListFun, ResSimFun, andResComFun. These elements can be usedonly in specific points of the syntax sincethe result returned can be a boolean, or a

13

list, or a number.

ResCon , res : varName; a : Activity

ResListFun , result : varName;lrf : listResFun

ResSimFun , resource : varName;srf : simResFun

ResComFun , res1 , res2 : varName;crf : comResFun

Activity , resource : varName;lrf : ResListFun

The constructs MaFor and BoolFor areused to execute nested loops. The definitionof one of these elements requires to spec-ify the type of loop (TypeBF for BoolForor TypeMF for MaFor), the list of vari-ables (i.e. ListResult) that will be used tocreate the nested loops (one loops for eachvariable), and the expression that must beexecuted. The constructs FixMaFor andFixBoolFor are nested loops like MaFor andBoolFor for which the variable fixEle deter-mines the number of loops that need to beexecuted. The TypeBF and TypeMF de-scribe how the results of each execution willbe joined. It is possible to choose amongfour types of loops: and (i.e. logic AND), or(i.e. logic OR), add (i.e. addition), and mul(i.e. multiplication).

MaFor , t : TypeMF ; lr : ListResult ;fme : ForMaCon

FixMaFor ,fixEle : varName; mf : MaFor

TypeMF ,add | mul

BoolFor , t : TypeBF ; lr : ListResult ;fbe : ForBoolCon

FixBoolFor ,fixEle : varName; bf : BoolFor

TypeBF ,and | or

ListResult ,varName+

As for a condition also for loops it is possi-ble to assume conditional or normal forms.The expression executed inside a loop issimilar to the condition expression but withsome variations. The ForMaCon is a arith-metical expression that can use constants

and variables, the difference with an MaConis that it is not possible to use loops or func-tions inside this type of expression.

ForMaCon ,ForMaITE | ForMaExp |constant | varName

ForMaITE , if : ForBoolCon;then, else : ForMaCon

ForMaExp ,ForMaUnExp |ForMaBinExp

ForMaUnExp , s : sub; me : ForMaCon

ForMaBinExp ,me1 ,me2 : ForMaCon;mo : MaOp

The ForBoolCon is a boolean expressionand does not allow the use of loops or func-tions as the ForMaExp. Clarified this twopoints, all the elements the name of whichstarts with For are equals to the elementsused by an BoolCon.

ForBoolCon ,ForBoolITE | ForBoolExp |ForComp | varName |varName | constant

ForBoolITE , if , then, else : ForBoolExp

ForBoolExp ,ForBoolUnExp |ForBoolBinExp

ForBoolUnExp ,n : neg ; e : ForBoolCon

ForBoolBinExp ,e1, e2 : ForBoolCon;bo : BoolOp

ForComp ,ce1 , ce2 : ForCompElem;co : CompOp

ForCompElem ,ForMaCon | varName |constant

6. Risk Definition for the RunningExample

The abstract syntax defined in Section 5has been used as a formal foundation forthe definition of the concrete syntax of ourlanguage for sensor conditions. During therealization of the concrete syntax we fol-lowed the dot notation typical of object-oriented languages, whereby a “.” is used

14

as a separator between the object on whicha function is requested and the functionitself. In particular, whenever a function“a()” needs to be invoked on an object “b”,the structure used is “b.a()”. In the contextof our language we follow this hierarchy:“case.task.action()”, “case.net.action()”, or“case.action()” for the definition of vari-ables, and “task.action()”, or “net.action()”for the identification of cases which satisfycertain conditions. Finally, another aspectin common with object-oriented languagesis the declaration of variables. In our con-crete syntax, conditions can only be definedusing variables that have been previouslydeclared and defined using a mapping.

Using this concrete syntax, we now haveall ingredients to show how the risks that weidentified for the Payment subprocess canbe captured via sensor conditions. Thereis an overtime process if an instance of thepayment subprocess is not completed withinan MCT of five days (see Section 2). Thiscondition is checked by using two variables:one to retrieve the amount of time Tc ex-pired and the other to retrieve the Te re-maining cycle time.

d = 5Tc = case(current).Payment(PassTimeInMillis)Te = case(current).(TimeEstimationInMillis)

Assuming a tolerance value of 60%, therisk condition defined to monitor this riskis:

(1-(d*24*60*60*1000)/(Te+Tc))>0.6.

There is an approval fraud whenever aSenior Finance Officer (SFO) approves twoorders for the same customer within fivedays (see Section 2). Accordingly, the cor-responding risk can be detected if given anorder o of customer c to be approved, i) o is

allocated to a SFO who approved anotherorder for the same customer in the last fivedays; or ii) the only SFOs available are theones who approved an order for customer cin the last five days.

This risk condition is triggered by anevent, i.e. the spawning of a new instanceof task Approve Shipment Payment Order(see Figure 1). This is checked using a vari-able to retrieve the status of this task inthe current instance. The risk condition it-self is given by the disjunction of the twoconditions described above. The first con-dition is checked by using variable ASPO#to retrieve the number of times this task wascompleted for customer c by the resourcesto whom is currently allocated. VariableASPO# is defined via a case condition overcustomer c, the resource to whom is cur-rently allocate (variable sfo1), the comple-tion time of this task (that must be greaterthan the start time of the current task Ap-prove Shipment Payment Order minus fivedays in milliseconds2), and the identifier ofthe instance (that must be different fromthe identifier of the current instance).

The second condition is checked by us-ing two variables and invoking two func-tions. Variable sfo2 retrieves which re-sources completed task Approve ShipmentPayment Order, and variable sfo retrievesall resources that can be offered this task(i.e. the current task). The first variableis defined via a case condition over cus-tomer c and the completion time of this task(that must be greater than the start timeof the current task Approve Shipment Pay-ment Order minus five days). The two in-voked functions return the number of tasks

2Time is measured in milliseconds as logging sys-tems save timestamps in this unit, and this facili-tates the comparison of timings.

15

started on the resources that completed taskApprove Shipment Payment Order, and thenumber of tasks in the execution queue ofthe resources that have been offered thistask, and did not complete it for customerc in the last five days.

After the definition of the variables, de-fined in Table 1, the risk condition is speci-fied as follows:

(ASPO#>0)∨((sfo2.startMinNumber=0)∧(sfo.startMinNumberExcept.sfo2>=1)).

An order unfulfillment occurs wheneveran order is updated more than five times(see Section 2). Accordingly, the respec-tive risk can be detected if: i) task Up-date Shipment Payment Order is currentlybeing performed for a given order; and ii)it is likely that this order will be updatedagain (i.e. task Update Shipment PaymentOrder will be repeated within the sameprocess instance). The probability thatthe number of times a task will be re-peated within the same instance of the Pay-ment subprocess is computed by dividingthe number of instances, where five execu-tions for task Update Shipment PaymentOrder has been reached, over the numberof instances that have executed this taskat least as many times as it has been ex-ecuted by the current instance, and havecompleted. This condition can be checkedby using variable USPO#US to retrievethe amount of orders that have been up-dated at least as much as this order, andvariable USPO#U5 to retrieve the amountof orders that have been updated at leastfive times.

The variables described can be definedvia the sensor definition language as in Ta-ble 2. Assuming a tolerance value of 60%,the risk condition is specified as follows:

(USPO#U5/USPO#US)>0.6.

An underpayment fraud occurs when-ever a customer underpays more than threetimes in a five-day time frame (see Sec-tion 2). Accordingly, the respective risk canbe detected if: i) task Issue Debit Adjust-ment is being performed for a given cus-tomer and order (this is the trigger for thisrisk); and ii) the probability that the max-imum number of allowable executions forthis task will be reached in a five-day timeframe, is above the fixed tolerance valuefor this risk, (this is the risk condition it-self). This condition can be checked byusing variable Probability to retrieve theprobability that an attempted fraud willtake place. This variable use the Action“FraudProbabilityFunc” to compute thespecific probability (see Appendix B), andtakes as input, among other information,variable IDA#Issue which retrieves the num-ber of times task Issue Debit Adjustmenthas been completed for this customer.

The defined variables are implementedthrough the sensor language as follows as inTable 3. These variables are used to com-pose the following risk condition, assuminga tolerance value of 60%:

Probability>0.6.

The definition of actions and functionsused in the above variables is provided inappendix. In particular, the complete listof all actions is provided in Appendix B,the complete lists of the nested loops and ofthe functions are provided in Appendix Cand Appendix D.

7. Risk Templates

To facilitate the definition of concrete riskconditions on process models, we defined a

16

sfo1 = case(current).Approve Shipment Payment Order 593(allocateResource)c = case(current).Issue Shipment Invoice 594.ShipmentInvoice.Companyd = 5

ASPO = case(current).Approve Shipment Payment Order 593(OfferTimeInMillis)ASPO# = case(Approve Shipment Payment Order 593(completeResource)=sfo1 ∧

Issue Shipment Invoice 594.ShipmentInvoice.Company=c ∧Approve Shipment Payment Order 593(CompleteTimeInMillis)>(ASPO-(d*24*60*60*1000)) ∧ (ID)!=[IDCurr]).Approve Shipment Payment Order 593(CountElements)

sfo2 = case(Issue Shipment Invoice 594.ShipmentInvoice.Company=c ∧Approve Shipment Payment Order 593(isCompleted)=“true” ∧Approve Shipment Payment Order 593(CompleteTimeInMillis)>(ASPOStartTime-(d*24*60*60*1000)) ∧ (ID)!=[IDCurr]).Approve Shipment Payment Order 593(completeResource)

sfo = case(current).Approve Shipment Payment Order 593(offerDistribution)

Table 1: Variable definition for approval fraud risk.

USPO#UC = case(current).Update Shipment Payment Order 604(Count)USPO#U5 = case(Update Shipment Payment Order 604(Count)>=5).

Update Shipment Payment Order 604(CountElements)USPO#US = case(Update Shipment Payment Order 604(Count)>=USPO#UC ∧

Process Shipment Payment 603(isOffered)=“true”).Update Shipment Payment Order 604(CountElements)

Table 2: Variable definition for order unfulfillment risk.

notion of risk template. A risk template isan “abstract” risk condition defined usinggeneric tasks and generic variables associ-ated with these tasks, which are not linkedto any real process model. These generictasks and variables will then be bound toreal tasks and variables when the templateis used to define a concrete risk condition fora specific process model. These templatesare thus used as “shortcuts” to simplify thedefinition of risk conditions.

Several studies address different types ofrisks [76, 27, 62, 81, 86, 88]. After an anal-ysis of these studies we decided to subdi-vide our risk templates into categories re-flecting these types of risks. We expect thatthis division into categories also reduces theeffort required by a user to select a suit-able template. These categories were de-fined using the risk taxonomy proposed by

Rosemann and zur Muehlen [76] and othertypes of risks proposed in the literature [40].Our organization of templates based on theabove taxonomy is not intended to be anexhaustive coverage of all possible process-related risks. Instead, we provide an exten-sible structure that can easily be extendedbased on specific requirements or furthertaxonomies.

We organized risk templates in two lev-els. The first level is obtained using therisk taxonomy, obtaining five categories ofrisks. These categories are: i) Structural,capturing risks deriving from wrong deci-sions taken at design time; ii) Data, cap-turing risks of damaging data integrity; iii)Technology, capturing risks of impacting onthe availability of IT systems; iv) Organiza-tional, capturing risks of process faults thatmay impact on the employees or be caused

17

IDAStartTime = case(current).Issue Debit Adjustment 605(StartTimeInMillis)c = case(current).Issue Shipment Invoice 594.ShipmentInvoice.Companyd = 5

IDA#Issue = case(Issue Shipment Invoice 594.ShipmentInvoice.Company=c ∧Issue Debit Adjustment 605(Count)>0 ∧ Issue Debit Adjustment 605(CompleteTimeInMillis)>(IDAStartTime-d*24*60*60*1000)).Issue Debit Adjustment 605(CountElements)

GroupingElement = Issue Shipment Invoice 594.ShipmentInvoice.CompanyWindowElement = Issue Debit Adjustment 605(CompleteTimeInMillis)

Threshold = 0.6Probability = case(Issue Debit Adjustment 605(Count)>0 ∧ (ID)!=[IDcurr]).

Issue Debit Adjustment 605(FraudProbabilityFunc, IDA#Issue, 3,GroupingElement, WindowElement, (d*24*60*60*1000))

Table 3: Variable definition for underpayment fraud risk.

by them; and i) Goal, capturing risks of notachieving the process objectives that cannotbe categorized in any of the previous cate-gories. For each of these risk categories wedefined eleven subcategories. These subcat-egories are based on the type of risks pro-posed in the literature [40]. Specifically, wehave: i) Strategic, risks of affecting the im-plementation of business strategies; ii) Op-erations, risks of affecting the capability ofsupplying and producing services or goods;iii) Supply, risks that prevent a resourcefrom executing an operation; iv) Customer,risks related to customers; v) Asset, risksderiving from the use of an asset; vi) Com-petitive, risks deriving from faults relatedto competitiveness; vii) Reputation, risks ofloss of reputation; viii) Financial, risks offinancial loss; ix) Fiscal, risks caused bychanges in taxation; x) Regulatory, risks re-lated to changes in regulations; xi) Legal,risks of faults that may lead to legal actions.Figure 6 shows a mind map illustrating howrisk templates are categorized and subcat-egorized. This subdivision in categories isnot absolute. Thus, a situation in which arisk could belong to more subcategories atthe same time is possible. In this case theuser should choose the template from the

subcategory considered to be the most ap-propriate, i.e. the one that would generatethe risk condition that is the closest to theuser requirements.

We defined 14 risk templates as a start-ing point for a larger risk template repos-itory. For example, one template of typeData/Operations, aims to detect a possibleinconsistency in the value of a critical vari-able. The template requires a as the criticalvariable, b the identifier variable, and twoset of instances s1 and s2, where s1 is com-posed of the instances in which the valuesof a and b are equal to the value of a andb for the current instance, and s2 is com-posed of the instances in which the valueof a is equals to the value of a for the cur-rent instance. If the number of instancesin s1 divided by the number of instances ins2 is greater than a certain threshold thetemplate triggers a notification. This risktemplate can be used to represent a case inwhich the critical variable is a credit cardnumber, or a bank account, while the iden-tifier variable is the customer identifier.

Another risk template, of typeGoal/Financial, detects the possibilitythat a particular process may exceed thebudget assigned for its execution. This risk

18

Figure 6: Template structure with categories andsubcategories.

is detected looking at all the completedinstances of the process and at all thecompleted instances with an execution costat least equal to the execution cost of thecurrent instance. The condition calculatesthe probability that the current instancewill exceed the budget. This risk can beassociated with any process where the costis a relevant element. An example is aninsurance process where opinions fromdifferent assessors may be required but thetotal cost of their involvement should notexceed the premium.

Considering the category Organizational,subcategory Reputation, we have risks thataffect the reputation of the company due to

“employees’ mistakes”. For example, a de-livery company may incur in a reputationalrisk if a delivery needs to be rescheduleddue to an employee’ mistake. In this casethe customer may think that the companyis not professional enough with a consequentimpact on the credibility of the company.

In the category Organizational, subcate-gory Supply, we defined a template that ad-dresses possible delays with the execution oftasks. It detects the possibility that a crit-ical task would not be started as soon as itis offered. This risk is detected looking atall the resources which have been offered awork item of the critical task. If the ratiobetween the number of resources that arebusy versus the total number of resourcesis greater than a certain threshold the riskis detected. This type of risk is relevantfor processes in healthcare such as a pro-cess for transferring organs from one hospi-tal to another, where the unavailability ofa resource may cause the organ deteriora-tion. Finally, taking in consideration theprocess described in Section 2, let’s say thatthe company wants to avoid that process-ing a shipment payment may be subjectedto delays, what we have to do is: i) im-port the template; ii) create a mapping ofour generic critical task to the task “Pro-cess Shipment Payment”; and iii) modifythe specified threshold if required.

Table 4 provides a brief overview of thetemplates currently available in the YAWLsystem (see Section 8). Besides the threetemplates described above, we have, amongothers, templates for the following risks: un-derpayment fraud, approval fraud, overtimefor activity, sequence of activities and pro-cess, and violation of the four-eyes principlewithin and across cases.

19

Category SubCategory Template Name Risk Description

Data

Financial Underpayment Fraud Underpayment fraud

OperationalData Inconsistency Across Cases

Wrong information provided, detected usingmultiple cases

Data Inconsistency Parallel Activity Wrong information provided to parallel tasks

Goal

Financial Process Cost ExceededExceeding the budget during the execution ofthe process

Strategic

Activity Time ExceededExceeding the time limit within which theactivity needs to be completed

Multi-Activity Time ExceededExceeding the time limit within which asequence of activities needs to be completed

Process Time ExceededExceeding the time limit within which theprocess needs to be completed

Organizational

Financial Approval Fraud Approval fraud

Operational

Four-Eyes Principle Four-Eyes Principle violation

Four-Eyes Principle Across CasesFour-Eyes Principle violation for activitiesacross different cases

Inadequate Preparation The activity is executed by a novice resource

SupplyDelay In Start The activity start will be delayed

Task Priority UnfulfilledActivity with high priority cannot startbecause resources are busy

Structural Operational Loop A loop is executed too many times

Table 4: Risk Templates and descriptions

8. Software Implementation

In order to prove the feasibility of our ap-proach, we implemented the sensor-basedarchitecture in the YAWL system.3 Wedecided to extend the YAWL system forthe following reasons. First, this sys-tem is based on a service-oriented archi-tecture, which facilitates the seamless ad-dition of new services. Second, the systemis open-source, which facilitates its distri-bution among academics and practitioners,and widely used in practice (the system hasbeen downloaded over 100,000 times sinceits first inception in the open-source com-munity). Finally, the underlying YAWLlanguage is very expressive as it provideswide support for the workflow patterns [95].

As part of this implementation, we ex-tended the YAWL Editor version 2.2betawith a new component, namely the Sen-sor Editor, for the specification of sensorswithin YAWL process models. Such graphi-cal component, shown in Figure 7, fully sup-

3Available at www.yawlfoundation.org

ports the specification of sensor conditionsas defined in Section 4, and the specificationof risk templates.

A wizard (see figure 8) was developed aspart of the YAWL Editor to facilitate theuse of risk templates and in particular themapping required for their use. This wiz-ard using an user friendly interface guidesthe user during each step of the mapping,providing a description of each generic taskand variable. The wizard also provides thepossibility of customizing a risk, since it ispossible to modify a risk condition duringthe creation of a risk using templates.

Moreover, we implemented the SensorManager as a generic component which ex-poses three interfaces (engine, database andmonitor) as described in Section 4. We thenwrapped this component into a Web ser-vice which implements the three interfacesfor the YAWL system, allowing the compo-nent to interact with the YAWL Engine, theMonitor service and the YAWL database.While there is a straightforward mappingbetween the YAWL Engine and our engine

20

Figure 7: The Sensor Editor within the YAWL Editor.

Figure 8: Template Wizard: a) Tasks mapping, b) Variables mapping.

interface, and between the YAWL Moni-tor service and our monitor interface, wehad to join several YAWL tables to im-plement our database interface. This isbecause in the YAWL system, event logsare scattered across different database ta-bles. For example, to retrieve all identi-fiers of the process instances for a specificprocess model, given the model identifier,we need to perform a join among the fol-lowing YAWL tables: logspecification,lognetinstance, lognet and logevent.

The complete mapping is illustrated inTable 5. As an example, this table alsoshows the mapping between our databaseinterface and the relational schema used byOracle BPEL 10g to store BPEL processlogs. Also in this case, the database canbe fully mapped by joining several tables.

Finally, we implemented a separate ser-vice to estimate the remaining cycle time Te

for a process or task instance. This serviceuses ProM’s prediction miner [1] to com-pute the estimations, and provides the re-

21

sults to the Sensor Manager on demand.While the estimation of Te could be doneon-line, i.e. while evaluating a particularsensor condition at run-time, parsing thefull logset each time would be inefficient.Rather, we compute this estimation off-line,whenever a new process model is deployedto the YAWL Engine, by using the logsetavailable at that time. Periodically, we up-date the logset with the new instances beingexecuted meantime, and invoke this serviceto refresh the estimations for each processmodel currently deployed.

9. Evaluation

In this section we discuss two evaluationsof the sensor-based architecture. In Section9.1, we discuss a performance analysis of theimplementation of the architecture in theYAWL system, and in Section 9.2, we reporton a usability evaluation of the architectureon basis of an online focus-group with 21students that gained experience in using thesystem for risk sensor condition analysis anddefinition tasks.

9.1. Performance Analysis

We used our implementation to evaluatethe scalability of the approach. First, wemeasured the time needed to evaluate thebasic functions (e.g. counting the number ofinstances of a task or retrieving the resourceallocated to a task). Next, we measured thetime needed to evaluate the sensor condi-tions for the risks defined in the Paymentsubprocess. The tests were run on an IntelCore I5 M560 2.67GHz processor with 4GBRAM running Linux Ubuntu 11.4. TheYAWL logs were stored on the PostGres 9.0DBMS. These logs contained 318 completedprocess instances from 36 difference process

models, accounting for a total of 9,399 pro-cess events (e.g. task instance started andcompleted, variable’s value change). Specif-ically, there were 100 instances from thePayment subprocess yielding a total of 5,904process events. The results were averagedover 10 runs.

Table 6 shows the results of the evalua-tion of the basic functions provided by ourlanguage. In particular, in this table wecompare the evaluation times obtained byaccessing the YAWL logs via our databaseinterface, with those obtained by access-ing a serialization of the logs, e.g. in theOpenXES format. While OpenXES pro-vides a simple and unique representation ofa generic set of process logs, accessing anOpenXES file in real-time, i.e. during theexecution of a process instance, is not fea-sible, due to the long access times (e.g. 6.5sec. on average for evaluating a net vari-able). On the other hand, accessing thelogs via our database interface, despite itrequires the creation of a specific imple-mentation for each BPMS database, pro-vides considerably faster times than access-ing OpenXES files (at least 87% gain w.r.t.OpenXES access). In fact, as we can seefrom Table 6, the evaluation times for allthe basic functions are below 30 ms, apartfrom function task variable, which takesalmost 100 ms and function net variable,which takes about 430 ms.

The last two basic functions reported inTable 6, namely task distribution andtask initiator, are evaluated in less than250 milliseconds. These functions are notcomputed by accessing the logs, but ratherby accessing information that is containeddirectly in an executable process model, e.g.the resources that are associated with a spe-cific task. However, in our implementationwe still use the database interface to ac-

22

Database tableTables that need to be joined

YAWL Oracle BPEL 10gWorkFlowDefinition logspecification, lognet, lognetinstance, logevent cube instance and cube scope

SubProcess logspecification, lognet, lognetinstance, logevent cube instance and cube scope

Activitylognetinstance, logtask, logtaskinstance, lognet,

wftask and work itemlogevent, logspecification, rs eventlog

Variableslogtask, lognet, lognetinstance, logtaskinstance,

audit trail, audit detail and xml documentlogevent, logdataitem, logspecification

Role rs participant wftaskActivityRole rs eventlog, logtaskinstance wftask

Table 5: Database interface mapping for YAWL 2.2beta and Oracle BPEL 10g.

Basic function DescriptionOpenXES Database Reductiontime [ms] time [ms] rate [%]

net statusfunctions checking if a net status has been reached

6,535 18.9 99.71(isStarted, isCompleted)

net timefunctions returning the time when a net status has been

6,781 18.8 99.72reached (startTime, completeTime, startTimeInMillis,completeTimeInMillis)

net variable returns the value of a net variable 6,489 432.6 93.33task count number of times a task has been completed 803 19.8 97.53

task resourcefunctions that return the resources associated with a task

850 20.9 97.54(offerResource, allocateResource, startResource,completeResource)

task statusfunctions checking if a task status has been reached

792 30.5 96.14(isOffered, isAllocated, isStarted, isCompleted)

task time

functions returning the time when a task status has been

824 22.3 97.29reached (offerTime, allocateTime, startTime,completeTime, offerTimeInMillis, allocateTimeInMillis,startTimeInMillis, completeTimeInMillis)

task variable returns the value of a task variable 787 96.7 87.71

taskfunctions returning the resources associated with a task by

243 -distribution

default (offerDistribution, allocateDistribution,startDistribution, completeDistribution)

task initiatorfunctions returning the allocation strategy for a resource

249.6 -association (offerInitiator, allocateInitiator, startInitiator,completeInitiator)

Table 6: Performance of basic functions.

cess this information, in order to providethe developer with a single access point toall process-related data.

Table 7 reports the results of the eval-uation of the sensor conditions defined forour running example. While the sensor con-ditions for the overtime process and orderunfulfillment faults are very low (below 150ms), longer times are obtained for evaluat-ing the conditions for the two faults relatedto fraud. This is because both these condi-tions require to evaluate “complex queries”,i.e. queries over the entire process logs: inthe approval fraud, we need to retrieve all

resources that approved an order for a spe-cific customer, while in the underpaymentfraud we need to retrieve all process in-stances where a debit adjustment was is-sued and aggregate these instances per cus-tomer. These queries are different thanthose needed to evaluate the basic func-tions, as the latter are performed on theevents in the logs that are relative to a sin-gle known process instance, e.g. the instancefor which the sensor condition is being eval-uated.

The worst-case complexity of evaluatingone such a complex query is still linear

23

SensorMin Max Ave St.Dev.[ms] [ms] [ms]

Overtime process 121 137 131.8 4.66Approval fraud 6,483 7,036 6,766.4 183.06Order

69 91 77.4 7.18unfulfillmentUnderpayment

3,385 3,678 3,523 89.98fraud

Table 7: Performance of sensors.

on the number of parameters that need beevaluated in the query (corresponding tothe language element CondExprSet in Sec-tion 4) multiplied by the total number ofinstances present in the logs (correspondingto the size of table WorkflowDefinition ad-dressed by our database interface).

In conclusion, the performances of eval-uating sensor conditions should always beconsidered w.r.t. the specific process forwhich the risks are defined, and the typeof trigger used. For example, let us assumean average duration of 24 hours for the Pay-ment subprocess, with a new task being ex-ecuted every 30 minutes. This means wehave up to 30 minutes to detect an overtimeprocess risk before a new task is executed,and we need to compute this sensor condi-tion again. If we choose a rate of 5 minutesto sample this condition, we are well belowthe 6 minute-threshold, so we can check thissensor condition up to 6 times during theexecution of a task. Since we do this in lessthan 150 ms, this time is acceptable. Foran event-driven risk we also need to con-sider the frequency of the specific event usedas trigger. For example, the approval fraudrisk is triggered every time an instance oftask Approve Shipment Payment Order isoffered to a Senior Financial Officer for ex-ecution. Since we take up to 7 seconds tocompute this sensor condition, we are ableto cope with a system where there is a re-quest for approval every 7 seconds. So alsofor this sensor, the performance is quite ac-

ceptable.

9.2. Usability Analysis

For the evaluation of the usability of thesensor-based architecture, we followed theexample from related studies [54, 55] andconducted focus group-like online sessionswith students. Each online session con-sisted of a tutorial followed by a question-naire. Specifically, the tutorial provided de-tailed instructions on the developed com-ponent for defining sensors, and then pre-sented two tasks that the students had toperform with the system, related to theanalysis of risk conditions and of risk sensorconditions. Once the students completedthe tutorial, they had to report on their us-age experiences using a structured question-naire (see Appendix E). The sessions werenot timed and no time limits were imposedon the users.

The questionnaire consisted of five parts:

� In part one, participants had to pro-vide relevant demographic informationabout their process modeling experi-ence.

� In part two, they were asked to providedetails about their experience in usingworkflow management systems in gen-eral.

� In part three, they were asked to pro-vide details about their experience inusing YAWL in particular. The ques-tions for parts one to three were, wherepossible, adapted from prior surveys onprocess modeling [54, 55] and usage ofthe YAWL system [74].

� In part four, users had to report ontheir experience in using the system toperform the two tasks in the tutorial.Specifically, these were:

24

1. the analysis of the risk sensor con-ditions for two YAWL models us-ing the developed risk definitionlanguage (risk scenarios 1 and 3in Appendix E), and

2. the specification of risk sensorconditions for a YAWL modelbased on a risk definition usingfault tree analysis (risk scenario 2in Appendix E).

The tasks in the tutorial were presentedusing three risk scenarios on the basisof the developed sensor-based architec-ture. Risk scenarios 1 and 3 describerisks using the developed risk definitionlanguage. Here we asked participantsto analyze the risk proposed. Risk sce-nario 2 describes a risk using a faulttree. Here we asked participants to de-fine such a risk using the proposed lan-guage.

For each of these application tasks,we assessed how well participants wereable to assess risks, in terms of accu-racy of understanding the risks and thedifficulty of understanding the mean-ing of the risks. Accuracy and diffi-culty are widely used measures [14, 60]of the effectiveness and the efficiencyof the sensor-based approach in termsof how well users of the approach canunderstand the risk information pro-vided through the approach, and howmuch cognitive effort is required to de-velop this understanding. We used a 5-point scale to measure the difficulty ofunderstanding the risk from very sim-ple to very difficult, and we definedfive true/false/do not know questionsto measure accuracy of comprehensionof the risk information provided.

� In part five, we captured participantsperceptions about the usage experi-ence of the approach as implemented inthe YAWL environment. This part ofthe questionnaire contained measure-ment items that were adapted from [74]and measured satisfaction (SAT), use-fulness (PU), ease of use (PEOU) andintentions to use (ITU). Similar to pre-vious uses of these items [71, 72, 74],the measures were of appropriate relia-bility, with Cronbachs Alphas rangingfrom 0.64 (ITU) to 0.81 (PU).

For this evaluation, we recruited partic-ipants by contacting individuals that hadpreviously completed a university under-graduate or post-graduate course on busi-ness process automation. The cohortswere from the Universita della Calabria,Cosenza, Italy and the Queensland Univer-sity of Technology, Brisbane, Australia, andwe perused the course email lists for con-tact. We recruited participants from thesecohorts because principles of process model-ing and automation in general as well as theYAWL system specifically were featured inthe courses, thus allowing us to select par-ticipants with sufficient levels of backgroundexperience and expertise, in turn minimiz-ing the risk of confounding the usability re-sults due to lack of experience with work-flow systems or process modeling in general.

The usability test was administered be-tween January and September 2012. Over-all 21 participants participated, where 10of them were from Italy and 11 from Aus-tralia. Participants, on average, had about2.6 years of experience with process mod-eling and had read and created, on av-erage, 71 and 15 process models, respec-tively, over the last twelve months. Par-ticipants experience with different process

25

Figure 9: Accuracy of risk comprehension, on ascale from 0 (low) to 5 (high).

modeling languages varied, with most hav-ing experience, at least, with UML Ac-tivity Diagrams, Petri Nets, EPCs and/orBPMN. These characteristics describe ourparticipants as proxies for novice to aver-age BPM professionals, with one of our par-ticipants representative of an expert practi-tioners (more than 5 years experience, morethan 250 models created, more than 1000models read). Overall, our study popula-tion might not be representative of expertsbut is roughly equivalent to the range of ex-pertise found in actual BPM practitionersas reported in other surveys, e.g. [73].

The box-plots in Figure 9 and Figure 10show the accuracy of the comprehension ofthe risks in the three scenarios as well as theperceived difficulty of understanding theserisks. The data shows that scenarios 1 and3 were reasonably well understood (averagesfor the comprehension questions were 2.9 forscenario 1 and 3.1 for scenario 3, both ex-ceeding 50% accuracy), while comprehen-sion of scenario 2 was significantly lower(average score 1.7). Similarly, perceived dif-ficulty was highest for scenario 2 (average of3.7), while the perceived difficulty for sce-

Figure 10: Difficulty of risk comprehension, on ascale from 1 (very simple) to 5 (very difficult).

nario 1 and 3 was similar in range (averages3.4 and 3.3, respectively).

Next, we were interested in understand-ing under which circumstances participantswere able to obtain higher levels of accuracyin understanding the risk information pro-vided. To that, we built a regression modelin which we regressed relevant demographicdata and perceived difficulty onto the to-tal comprehension score across all three riskscenarios. Specifically, we included as coef-ficients:

� PMExp(Years): Process modeling ex-perience in years

� PMExp(Training): Extent of formaltraining in process modeling in daysover the last twelve months

� PMExp(SelfEducation): Extent of self-education in process modeling in daysover the last twelve months

� PMExp(processModelsCreated):Number of process models created overthe last twelve months

26

StandardizedCoefficients

Variable Beta t Sig.PMExp(Years) -0.80 -2.79 0.02PMExp(Training) -0.03 -0.16 0.88PMExp

1.28 4.31 0.00(processModelsCreated)BPMSFAM 0.38 1.15 0.28YAWLUse(time) 0.80 3.07 0.01YAWLUse(features) -0.30 -1.40 0.20YAWLUse(models) -1.20 -3.86 0.00RISKPerDif -0.19 -1.05 0.32

Table 8: Regression analysis of risk comprehensionacross all three scenarios

� BPMSFAM: Self-perceived familiaritywith BPMSs [71]

� YAWLUse(time): length of use of theYAWL system

� YAWLUse(features): Number ofYAWL features used

� YAWLUse(models): Number of YAWLmodels created, read or edited over thelast twelve months

� RISKPerDif: Average perceived com-prehension difficulty across the threepresented scenarios.

The regression model was significant (F= 3.54, p = 0.04) and explained 77.9 per-cent of the variance in total comprehensionscore, thus attesting to very good explana-tory power. Table 8 gives the results fromthe regression model analysis.

Table 8 shows that four factors were sig-nificant predictors for explaining compre-hension accuracy, these being process mod-eling experience in years, number of pro-cess models created, use of the YAWL sys-tem and number of YAWL models cre-ated, edited or read over the last twelvemonths. Several interesting findings arenoteworthy. First, PMExp(Years) andYAWLUse(models) are negative predictors,

which may suggest that novice users withlittle process modeling experience and lit-tle experience with YAWL models bene-fited more from the risk sensor approach.Second, the difficulty of understanding therisk information provided is not related tohow well users understand the risks. Third,training in process modeling or more var-ied use of the YAWL system, likewise, areirrelevant in terms of understanding risk in-formation provided by the sensor-based ar-chitecture.

Finally, we were interested in the partici-pants’ evaluation of the sensor-based archi-tecture. Following the theory of technologyacceptance [28] and its extended applicationin the process modeling context [72], we un-derstand that satisfaction, ease of use andperceived usefulness are key criteria for ex-plaining intentions to use a process model-ing artifact. Figure 11 shows the box-plotsfor the average total factor scores for thesefour criteria.

The data displayed in Figure 11 suggeststhat participants rated the usefulness of theapproach high (mean score > 5.3) and werein general inclined to use the system (meanscore > 4.4). Satisfaction with the approachwas reported as average (mean score = 4.0)and ease of use, notably, was reported as low(mean score < 3.5), indicating potential toimprove interface and user interaction of thesystem. This is not surprising, since we didnot explicitly consider the principle of “clar-ity” when designing the concrete syntax ofour language.

In a post-hoc analysis, we compared eval-uations of SAT, PU, PEOU and ITU acrossusers that scored low or high on risk com-prehension, based on a median split, andacross users that rated the perceived diffi-culty of understanding risks as low or high,again based on a median split. MANOVA

27

Figure 11: Perceptual evaluations of the sensor-based architecture on a scale from 1 (low) to 7(high).

tests in both cases showed that evaluationsof the approach were independent fromcomprehension accuracy or difficulty, withp-values ranging from 0.30 to 0.49 and 0.18to 0.58, respectively. The results indicatethat the evaluations of satisfaction, useful-ness, ease of use and intentions to use wererobust against variances in the performancein using the system.

In summary, our evaluation showed thatthe sensor-based risk identification andmodeling approach provided value in allow-ing participants to develop an understand-ing of process risks. We found the ap-proach to be useful particularly for userswith limited experience in process modelingor BPMSs. The evaluation further revealedthat ease of use of the system should be im-proved to warrant better user acceptance.

10. Related Work

Risk measurement and mitigation tech-niques have been widely explored in vari-ous fields. At the strategic-level, risk man-agement standards prescribe generic pro-cedures for identifying, analyzing, evaluat-ing and treating risks (see e.g. [89]). Al-though helpful, such general guidelines areinevitably vague and fail to provide any spe-cific guidance for operationalizing risk man-agement strategies in business processes. Atthe other extreme, there are many tech-niques for identifying risks in specific areassuch as employee [3], conflict of interest [57]and in the engineering field more gener-ally [43, 13]. Other approaches, such asfault-tree analysis [21], are general enoughto be applied to multiple domains. How-ever, none of these approaches provides in-sights on how to define and operationalizethe detection of process-related risks. Inthe following, we first discuss related workat methodological level with respect to theproposed approach and then related workwith respect to the architectural level of ourproposal is discussed.

Previous process-based research recog-nizes the importance of explicitly linkingelements of risk to business process mod-els, through specific methodological ap-proaches. Such approaches, discussed be-low, can be mainly categorized into designtime Risk-aware BPM with and without in-tegrated risks constructs. The former [76,102, 48, 97, 82, 85, 83, 84, 26, 25, 100, 5] ana-lyzes and models BPM risks through the in-troduction of new integrated risk constructswhereas the latter [64, 67, 78, 77, 11, 42, 91,53, 94, 70, 56, 12, 46, 6, 7, 34, 35, 51, 4, 10,80, 49, 87, 52] reuses existing risk analysismethods. In the next paragraphs we are go-ing to discuss the most relevant of these ap-

28

proaches while we refer to [92] for a compre-hensive discussion on all these approaches.

Among these approaches we can identifyseveral groups. The first group is com-posed of the approaches described in [26,25, 100, 64, 67, 78, 77, 82, 85, 83, 84, 56].They propose to extend existing model-ing languages, such as Business ProcessModel and Notation (BPMN), Event-drivenProcess Chain (EPC), Value-Focused Pro-cess Engineering (VFPE), semantic busi-ness process modeling language (SBPML)and the integrated definition (IDEF) lan-guage, with risk-related constructs. The ap-proaches provide the possibility to annotatebusiness process models with risk-relatedinformation and in some cases it is also pos-sible to annotate mitigation actions. Fur-thermore Rotaru et al. [67, 78, 77] also pro-pose an utility calculation technique thatcan be used to determine optimal risk coun-termeasure solutions.

The second group is composed of ap-proaches [4, 10, 80, 11, 6, 7] which proposerisk-informed design. In these approachescommon is the idea of modelling businessprocesses (in one or several stages) whichcontain elements of risk and possible miti-gation actions. These models are then usedto create a process model in which mitiga-tion activities are already part of the pro-cess itself. In particular, Betz et al. [11]propose a method based on simulation tochoose the optimum process model variantif several variants are proposed.

The third group focuses on simulationand is composed of the approches describedin [48, 97, 94, 51, 49]. The ROPE (Risk-Oriented Process Evaluation), methodologyproposed by Jakoubi et al. [48, 97], is basedon the observation that faults (here called“threats”) impact the functionality of re-sources (required for the execution of pro-

cess activities). If a threat is detected, acountermeasure process or a recovery pro-cess is invoked to counteract the threat.The ROPE methodology aims to incorpo-rate these aspects in a single model thatcan be simulated to determine a companyscritical business processes and single pointsof failure. Similarly, Taylor et al. [94], pro-pose a simulation environment based on thejBPM Process Definition Language (JPDL)workflow language. In this environmenta process models annotated with risk in-formation (i.e. key risk indicator (KRI),key performance indicator (KPI), and riskevent) can be simulated in order to evalu-ate the effects of risk events on some pre-defined KPIs and KRIs. Finally, Kaegi etal. [51] simulate a process model describedin BPMN via agent-based modelling tech-nique to analyze business process-relatedrisks, while Jallow et al. [49], propose anapproach where risks in business processesare analysed. The approach use the MonteCarlo simulation [61], on a given a set ofidentified risk events and their occurrenceprobabilities, in order to assess and quan-tify the impact/consequences of those riskevents (in terms of time, cost, performance,and other objectives) on each process activ-ity and on the overall process.

Other works which cannot be groupedtogether annoverate: i) a taxonomy ofprocess-related risks [76, 102, 67], which in-cludes five process-related risk types (goals,structure, information technology, data andorganization) that can be captured by fourinterrelated model types (risk structuremodel, risk/goal matrix, risk state model,and an extension to the EPC notation); ii)an extended goal-risk framework [5], whichconsists of an asset layer (composed ofbusiness process goals, activities, and busi-ness artifacts), an event layer (composed of

29

various events, including risk events, thatcan impact the asset layer), and a treat-ment layer (composed of a set of risk treat-ment activities that can mitigate the im-pact of the risk events modeled in theevent layer); and iii) a technique to evalu-ate a workflow’s non-completion risk due touncertain/dynamic information [87], whichquantifies the confidence level of the non-monotonic predicates of a workflow andwhether one of these confidence levels is be-low certain threshold considers the workflowto be risky suggesting the use of a backupworkflow.

Finally, in the approach proposed byKang et al. [52], a technique to estimatethe probability that a process instance en-ters an abnormal termination state is de-fined. Process-related historical data is usedto inform the probability estimation calcu-lation. Then, a run-time risk estimation al-gorithm is developed such that appropriaterisk alerts can be produced when risky situ-ations are detected. The main limitation ofthis approach is the necessity of having anexhaustive log containing all possible exe-cutions and the impossibility of making dis-tinctions among different abnormal termi-nation states.

With respect to the risk-aware BPM life-cycle shown in Figure 3, all the above pro-posals cover the risk-aware process model-ing phase (see Table 9). None of them spec-ifies how risk conditions can be concretelylinked to run-time aspects of process mod-els such as resource allocation, data vari-ables and control-flow conditions, for thesake of detecting risks during process execu-tion. Thus, none of these approaches opera-tionalizes risk detection into workflow man-agement systems. Moreover, they neglecthistorical process data for risk estimation.As such, these approaches are complemen-

tary to our work, i.e. they can be used ata conceptual level for the identification ofprocess-related risks, which can then be im-plemented via our sensor-based lower-levelmethodology.

From the architectural point of view, ourapproach, specifically our sensor-based ar-chitecture, is also related to real-time mon-itoring of business process execution. Simi-larly to our approach, Oracle Business Ac-tivity Monitoring (BAM) [69] relies on sen-sors to monitor the execution of BPEL pro-cesses. Three types of sensors can be de-fined: activity sensors, to grab timings andvariable contents of a specific activity; vari-able sensors, to grab the content of the vari-ables defined for whole BPEL process (e.g.the inputs to the process); and fault sensors,to monitor BPEL faults. These sensors canbe triggered by a predefined set of events(e.g. task activation, task completion). Foreach sensor, one can specify the endpointswhere the sensor will publish its data atrun-time (e.g. a database or a JMSQueue).We allow the specification of more sophis-ticated sensor (and fault) conditions, wheredifferent process-related aspects can be in-corporated such as data, resource allocationstrategies, order dependencies, as well ashistorical data and information from otherrunning process instances. Moreover, oursensors can be triggered by process eventsor sampled at a given rate. Nonetheless,our sensor-based architecture is exposed asa service and as such it could be integratedwith other process monitoring systems, suchas Oracle BAM.

A Sensor, as defined in this work, may becategorized as a specialization of the moregeneral rules framework known as Event-Condition-Action (ECA) rules, which orig-inally came to prominence through theiruse with Active Database Management Sys-

30

Approach

Process Process Process Processdesign/ implementation/ enactment/ diagnosis/

Risk-aware Risk-aware Risk-aware Riskprocess workflow workflow monitoring

modeling implementation executionzur Muehlen et al. [76, 102] XAsnar and Giorgini [5] XKaragiannis et al. [53] XSingh et al. [87] XCope et al. [26, 25] XWeiss and Winkelmann [100] XMock and Corvo [64] XRotaru et al. [67, 78, 77] XSienou et al. [82, 85, 83, 84] XLambert et al. [56] XJakoubi et al. [48, 97] XTaylor et al. [94] XKaegi et al. [51] XJallow et al. [49] XBergholtz et al. [4, 10, 80] XBetz et al. [11] XBhuiyan et al. [6, 7] XHermann and Hermann [42] XStrecker et al. [91] XPanayiotou et al. [70] XBhuiyan et al. [12, 46] XFenz et al. [34, 35] XKang et al. [52] XOur proposal X X X X

Table 9: Comparison of available R-BPM approaches with respect to the four phases of our R-BPM lifecycle.

tems [30]. A Sensor extends the ECA no-tion by including two conditions, one whichdescribes a potential fault, and the otherthe possibility of risk. A Sensor also de-livers a consequence when a triggered con-dition evaluates to true, rather than an ac-tion per se. ECA rules have also been usedas the basis for several well-known excep-tion handling strategies in workflow sys-tems [15, 17, 19]. For example, a defi-nition language for exception rules calledChimera-Exec was developed for the WIDEprototype [16]. An extended ECA frame-work can be found in the defeasable work-flow approach [59], which has an addedjustification condition to support context-dependent reasoning of actions to be taken.The RUMBA project combines ECA ruleswith an Aspect-Oriented framework to pro-vide a modular approach to the integra-

tion of rules and active processes [18]. TheWorklet approach incorporates an extendedrules-based framework, which embeds ex-ceptions directly into the evaluation tree [2].

Real-time monitoring of process modelscan also be achieved via Complex EventProcessing (CEP) systems. In this context,CEP systems have been integrated intocommercial BPMSs, e.g. webMethods Busi-ness Events4, ARIS Process Event Moni-tor [29] and SAP Sybase [93], as well asexplored in academia [36, 41]. A CEP sys-tem allows the analysis of aggregated eventsfrom different sources (e.g. databases, emailaccounts as well as process engines). Us-ing predefined rules, generally defined witha specific SQLlike language [99], a CEP sys-tem can verify the presence of a specific

4http://www.softwareag.com/au/products/wm/events/overview

31

pattern among a stream of simple eventsprocessed in a given time window. Ourapproach differs from CEP systems in thefollowing aspects: i) strong business pro-cess orientation vs general purpose system;ii) ability to aggregate and analyze com-plex XML-based events (e.g. process vari-ables) vs simple events; iii) time-driven andevent-driven triggers vs event-driven trig-ger only. Moreover, CEP systems typicallysuffer from performance overheads [41, 99]which limit their applicability to real-timerisk detection [99].

This article is an extended version of thework presented in [23]. Compared to thiswork, this article provides the full and re-vised definition of the language’s abstractsyntax, the support for risk templates, theusability evaluation with users and a com-prehensive related work.

11. Conclusion

We contributed an approach for real-timemonitoring of risks in executable businessprocess models. The approach embeds ele-ments of risk into each phase of the BPMlifecycle: from process design, where high-level risks defined via a risk analysis methodare mapped down to specific process modelelements such as activities, resources anddata, through to process diagnosis, whererisks are detected during process execution,and those no longer tolerable are notified toprocess administrators. To the best of ourknowledge, this is the first attempt to con-cretely embed risks into executable businessprocesses and enable their automatic detec-tion at run-time.

As a second contribution, we providedan operationalization of the proposed risk-awareness approach on top of BPMSs.This is achieved via a distributed, sensor-

based architecture that communicates witha BPMS via a set of tool-independent in-terfaces. Each risk is associated with a sen-sor condition and refers to a fault, which isan undesired state of the process. Condi-tions can relate to any process aspect, suchas control-flow dependencies, resource allo-cations, the content of data elements, bothfrom the current process instance and frominstances of any process that have alreadybeen completed. At design-time, these con-ditions are expressed within a process modelvia a simple query language, for which weprovide an abstract syntax. At run-time,each sensor independently alerts a sensormanager when the associated risk condi-tion evaluates to true during the executionof a specific process instance. When thisoccurs, the sensor manager notifies a pro-cess administrator about the given risk byinterfacing with the monitoring service ofthe BPMS. This allows early risk detectionwhich in turn enables proper remedial ac-tions to be taken in order to avoid poten-tially costly process faults.

We designed a set of risk templates to al-low process designers to easily specify newrisk conditions into a process model. Eachtemplate captures an abstract risk. To usethese templates, one has to bind the tem-plate variables to concrete elements of theprocess model for which the risk conditionneeds to be monitored. We contend that byusing such templates the effort of definingrisks in executable process models can bereduced.

As a proof-of-concept, we implementedthe sensor-based architecture on top of theYAWL system along with 14 representa-tive templates. We then used the toolto evaluate the feasibility of the approachin practice. This was carried out in twodirections. First, we evaluated the per-

32

formance of the implementation; second,we evaluated the usability and ease of useof the approach with users of the YAWLsystem. The performance measurementsshowed that the sensor conditions can becomputed efficiently and that no perfor-mance overhead is induced to the BPMS en-gine. The results of the empirical evaluationwith users showed that the sensor-based riskidentification and modeling approach pro-vided value to develop an understanding ofprocess risks. We found the approach tobe useful particularly for users with limitedexperience in process modeling or BPMSs.The evaluation further revealed that easeof use of the language for defining sensorsshould be improved to warrant better useracceptance. In order to overcome this limi-tation we plan to devise a mechanism for au-tomatically deriving skeletons of sensors di-rectly from fault trees. We expect that thiswill allow a smoother transition from high-level risk definitions to low-level risk con-ditions. Moreover, aiding features providedby common source code editors such as au-tocomplete, syntax highlighting and bracketmatching can be put in place to reduce thehuman effort.

The approach presented in this paperand its operationalization serve as the cor-nerstone for other techniques that aim tobridge the gap between risk and processmanagement. In particular, in [24] we doc-umented a technique which uses input fromthis approach in order to mitigate risks.Specifically, as soon as one or more risksare detected which are no longer tolerable,the technique identifies a set of alternativemitigation actions that can be applied byprocess administrators. A mitigation ac-tion is a sequence of controlled changes ap-plied to the process instance, that takesinto account a snapshot of the process re-

sources and data, and the current statusof the system in which the process is exe-cuted. Furthermore, in [22] we reported ona second technique which also builds on theapproach presented in this paper to allowprocess participants to make risk-informeddecisions. This is achieved by estimatingthe risk that the current process instancewill end up with one or more faults basedon the input provided by the participant,e.g. when filling out a user form based onthe conditions specified for each fault.

This work suffers from several limitationswhich offer opportunities for future work.First, to overcome the low perceived ease ofuse of the tool resulting from the usabilitytests, we plan to improve the concrete syn-tax of the sensor definition language, takinginto account the design principle of clar-ity. Second, manual work is currently re-quired to convert the results of risk analy-sis into sensor conditions. This operationis error-prone, especially in the content ofcomplex risk definitions. In this respect, weplan to devise a mechanism for automati-cally deriving skeletons of sensor conditionsdirectly from a fault tree. This will allow asmoother transition from high-level risk def-initions to low-level sensor conditions. Fi-nally, we plan to evaluate the usefulness oftemplates with end users. In doing so, wewill consider the results against their cor-relation with the user background in termsof exposure to YAWL in particular, and torisk management in general.

Acknowledgments We thank PeterHughes for his help with the identificationof process-related risks. This researchis partly funded by the ARC DiscoveryProject “Risk-aware Business ProcessManagement” (DP110100091). NICTAis funded by the Australian Government

33

as represented by the Department ofBroadband, Communications and theDigital Economy and the Australian Re-search Council through the ICT Centre ofExcellence program.

References

[1] van der Aalst, W.M., Schonenberg, M., Song,M., 2011. Time prediction based on processmining. Information Systems 36, 450 – 475.

[2] Adams, M., ter Hofstede, A., van der Aalst,W., Edmond, D., 2007. Dynamic, extensi-ble and context-aware exception handling forworkflows, in: Proceedings of the 15th Inter-national Conference on Cooperative Informa-tion Systems (CoopIS’07), Springer, Vilam-oura, Portugal. pp. 95–112.

[3] Albrecht, W.S., Albrecht, C.C., Albrecht,C.O., Zimbelman, M.F., 2008. Fraud Exam-ination. 3rd ed., South-Western Publishing.

[4] Andersson, B., Bergholtz, M., Edirisuriya,A., Ilayperuma, T., Johannesson, P., 2005.A declarative foundation of process models,in: Pastor, O., e Cunha, J.F. (Eds.), CAiSE,Springer. pp. 233–247.

[5] Asnar, Y., Giorgini, P., 2008. Analyzing busi-ness continuity through a multi-layers model,in: Dumas, M., Reichert, M., Shan, M.C.(Eds.), BPM, Springer. pp. 212–227.

[6] Bagchi, S., Bai, X., Kalagnanam, J., 2006.Data quality management using business pro-cess modeling, in: IEEE SCC, IEEE Com-puter Society. pp. 398–405.

[7] Bai, X., Padman, R., Krishnan, R., 2007. Arisk management approach to business pro-cess design, in: ICIS, Association for Infor-mation Systems. p. 28.

[8] Basel Committee on Bankin Supervision,2006. Basel II - International Convergence ofCapital Measurement and Capital Standards.

[9] Bentley, J., 1986. Programming pearls: littlelanguages. Communications of the ACM 29,711–721.

[10] Bergholtz, M., Gregoire, B., Johannesson, P.,Schmitt, M., Wohed, P., Zdravkovic, J., 2005.Integrated methodology for linking businessand process models with risk mitigation, in:REBNITA, Citeseer.

[11] Betz, S., Hickl, S., Oberweis, A., 2011. Risk-aware business process modeling and simula-

tion using xml nets, in: Hofreiter, B., Dubois,E., Lin, K.J., Setzer, T., Godart, C., Proper,E., Bodenstaff, L. (Eds.), CEC, IEEE. pp.349–356.

[12] Bhuiyan, M., Islam, M.M.Z., Koliadis, G.,Krishna, A., Ghose, A., 2007. Managingbusiness process risk using rich organizationalmodels, in: COMPSAC (2), IEEE ComputerSociety. pp. 509–520.

[13] Bhushan, N., Rai, K., 2004. Strategic Deci-sion Making: Applying the Analytic Hierar-chy Process. 3rd ed., Springer.

[14] Burton-Jones, A., Wand, Y., Weber, R.,2009. Guidelines for empirical evaluations ofconceptual modeling grammars. Journal ofthe Association for Information Systems 10,495–532.

[15] Casati, F., 1999. A discussion on approachesto handling exceptions in workflows. ACMSIGGROUP Bulletin 20, 3–4.

[16] Casati, F., Fugini, M., Mirbel, I., 1999.An environment for designing exceptions inworkflows. Information Systems 24, 255–273.

[17] Casati, F., Ilnicki, S., Jin, L., Krishnamoor-thy, V., Shan, M.C., 2000. Adaptive and dy-namic service composition in eFlow , 13–31.

[18] Cetin, S., Altintas, N., Solmaz, R., 2006.Business rules segregation for dynamic pro-cess management with an aspect-orientedframework, in: Proceedings of the Interna-tional Workshop on Dynamic Process Man-agement (DPM 2006), Springer, Vienna,Austria. pp. 193–204.

[19] Chiu, D.K., Li, Q., Karlapalem, K., 1999. Ex-ception handling with workflow evolution inADOME-WFMS: a taxonomy and resolutiontechniques. ACM Siggroup Bulletin 20, 8–8.

[20] Comfort, L., Mosse, D., Znati, T., 2009. Man-aging risk in real time: Integrating informa-tion technology into disaster risk reductionand response. Commonwealth: A Journal ofPolitical Science 15, 27–45.

[21] Commission, I.E., 1990. IEC 61025 FaultTree Analysis (FTA).

[22] Conforti, R., de Leoni, M., La Rosa, M.,van der Aalst, W.M.P., 2013. Support-ing Risk-Informed Decisions during Busi-ness Process Execution. QUT ePrints55979. Queensland University of Technology.http://eprints.qut.edu.au/55979.

[23] Conforti, R., Fortino, G., La Rosa, M., ter

34

Hofstede, A.H.M., 2011. History-aware, real-time risk detection in business processes, in:Proc. of CoopIS, Springer.

[24] Conforti, R., ter Hofstede, A.H.M., La Rosa,M., Adams, M., 2012. Automated risk mit-igation in business processes, in: Proc. ofCoopIS, Springer.

[25] Cope, E.W., Kuster, J.M., Etzweiler, D.,2009. Risk Extensions to the BPMN 1.1 Busi-ness Process Metamodel. Technical ReportRZ3740. IBM Research.

[26] Cope, E.W., Kuster, J.M., Etzweiler, D.,Deleris, L.A., Ray, B., 2010. Incorporatingrisk into business process models. IBM Jour-nal of Research and Development 54, 4.

[27] Cousins, P.D., Lamming, R.C., Bowen, F.,2004. The role of risk in environment-relatedsupplier initiatives. International Journal ofOperations & Production Management 24,554–565.

[28] Davis, F.D., 1989. Perceived usefulness, per-ceived ease of use, and user acceptance of in-formation technology. MIS quarterly 13, 319–340.

[29] Davis, R.B., Brabander, E., 2007. ARIS De-sign Platform: Getting Started with BPM.Springer.

[30] Dayal, U., Buchmann, A.P., McCarthy, D.R.,1988. Rules are objects too: a knowledgemodel for an active, object-oriented databasesystem, in: Advances in Object-OrientedDatabase Systems. Springer, pp. 129–143.

[31] Dumas, M., van der Aalst, W.M., ter Hof-stede, A.H., 2005. Process-Aware Informa-tion Systems: Bridging People and Softwarethrough Process Technology. Wiley & Sons.

[32] Ermotti, S., 2011. Internal message fromSergio P. Ermotti, Group CEO, about theunauthorized trading incident. http://www.

ubs.com/global/en/about_ubs/media/

global/unauthorized_trading_incident/

2011-10-05-internal-message-ermotti.

html (Accessed 16 May 2013).[33] Faulds, F., Bessis, J., 2013. Rogue trading:

Back to front. Journal of Risk Managementin Financial Institutions 6, 4–5.

[34] Fenz, S., 2010. From the resource to the busi-ness process risk level, in: Proceedings of theSouth African Information Security Multi-Conference (SAISMC’2010), pp. 100–109.

[35] Fenz, S., Neubauer, T., 2009. How to deter-

mine threat probabilities using ontologies andbayesian networks, in: Proceedings of the 5thAnnual Workshop on Cyber Security and In-formation Intelligence Research: Cyber Secu-rity and Information Intelligence Challengesand Strategies, ACM, New York, NY, USA.pp. 69:1–69:3.

[36] Gay, P., Pla, A., Lopez, B., Melendez, J., Me-unier, R., 2010. Service workflow monitoringthrough complex event processing, in: ETFA,IEEE. pp. 1–4.

[37] Golden, W., Acton, T., Conboy, K., van derHeijden, H., Tuunainen, V.K. (Eds.), 2008.16th European Conference on InformationSystems, ECIS 2008, Galway, Ireland, 2008.

[38] Gunther, C.W., Verbeek, E., 2013. Sup-porting Risk-Informed Decisions duringBusiness Process Execution. Tech-nical Report 55979. Eindhoven Uni-versity of Technology. http://www.xes-standard.org/ media/openxes/openxesdeveloperguide-1.9.pdf.

[39] Halpin, T., Bloesch, A., 1999. Data modelingin uml and orm: a comparison. Journal ofDatabase Management (JDM) 10, 4 – 13.

[40] Harland, C., Brenchley, R., Walker, H., 2003.Risk in supply networks. Journal of Purchas-ing and Supply Management 9, 51 – 62.

[41] Hermosillo, G., Seinturier, L., Duchien, L.,2010. Using complex event processing for dy-namic business process adaptation, in: IEEESCC, IEEE Computer Society. pp. 466–473.

[42] Herrmann, P., Herrmann, G., 2006. Securityrequirement analysis of business processes.Electronic Commerce Research 6, 305–335.

[43] Hespos, R.F., Strassmann, P.A., 1965.Stochastic decision trees for the analysis ofinvestment decisions. Management Science11, 244–259.

[44] High Court of Australia, . Patel vThe Queen [2012] HCA 29 (24 August2012). http://www.austlii.edu.au/au/

cases/cth/HCA/2012/29.html Accessed 2May 2013.

[45] Hollingsworth, D., 1995. The Workflow Ref-erence Model. Workflow Management Coali-tion. Workflow Management Coalition.

[46] Islam, M.M.Z., Bhuiyan, M., Krishna, A.,Ghose, A., 2009. An integrated approach tomanaging business process risk using rich or-ganizational models, in: Meersman, R., Dil-

35

lon, T.S., Herrero, P. (Eds.), OTM Confer-ences (1), Springer. pp. 273–285.

[47] Jacque, L., 2010. Global Derivative Debacles:From Theory to Malpractice. World Scien-tific. chapter 11: Societe Generale. pp. 179–196.

[48] Jakoubi, S., Goluch, G., Tjoa, S., Quirch-mayr, G., 2008. Deriving resource require-ments applying risk-aware business processmodeling and simulation, in: [37]. pp. 1542–1554. pp. 1542–1554.

[49] Jallow, A.K., Majeed, B., Vergidis, K., Ti-wari, A., Roy, R., 2007. Operational riskanalysis in business processes. BT Technol-ogy Journal 25, 168–177.

[50] Johnson, W.G., 1973. MORT - The Manage-ment Oversight and Risk Tree. U.S. AtomicEnergy Commission.

[51] Kaegi, M., Mock, R., Ziegler, R., Nibali, R.,2006. Information systems’ risk analysis byagent-based modelling of business processes,in: Soares, C.G., Zio, E. (Eds.), ESREL, Tay-lor & Francis. pp. 2277–2284.

[52] Kang, B., Cho, N.W., Kang, S.H., 2009.Real-time risk measurement for business ac-tivity monitoring (bam). International Jour-nal of Innovative Computing, Informationand Control 5, 3647–3657.

[53] Karagiannis, D., Mylopoulos, J., Schwab, M.,2007. Business process-based regulation com-pliance: The case of the sarbanes-oxley act,in: RE, IEEE. pp. 315–321.

[54] La Rosa, M., ter Hofstede, A.H.M., Wohed,P., Reijers, H.A., Mendling, J., van der Aalst,W.M.P., 2011a. Managing process modelcomplexity via concrete syntax modifications.Industrial Informatics, IEEE Transactions on7, 255–265.

[55] La Rosa, M., Wohed, P., Mendling, J., terHofstede, A.H.M., Reijers, H.A., van derAalst, W.M.P., 2011b. Managing processmodel complexity via abstract syntax modifi-cations. Industrial Informatics, IEEE Trans-actions on 7, 614–629.

[56] Lambert, J.H., Jennings, R.K., Joshi, N.N.,2006. Integration of risk identification withbusiness process models. Systems engineering9, 187–198.

[57] Little, A., Best, P.J., 2003. A framework forseparation of duties in an sap r/3 environ-ment. Managerial Auditing Journal 18, 419–

430.[58] Lund, M.S., Solhaug, B., Stølen, K., 2011.

Model-Driven Risk Analysis. Springer.[59] Luo, Z., Sheth, A., Kochut, K., Arpinar, B.,

2003. Exception handling for conflict resolu-tion in cross-organisational workflows. Dis-tributed and Parallel Databases 11, 271–306.

[60] Mendling, J., Strembeck, M., Recker, J.,2012. Factors of process model comprehen-sion - findings from a series of experiments.Decision Support Systems 53, 195–206.

[61] Metropolis, N., 1987. The beginning of themonte carlo method. Los Alamos Science 15,125–130.

[62] Meulbroek, L., 2000. Total strategies forcompany-wide risk control. Financial Times9, 1–4.

[63] Meyer, B., 1990. Introduction to the theoryof programming languages. Prentice-Hall.

[64] Mock, R., Corvo, M., 2005. Risk analy-sis of information systems by event processchains. International journal of critical in-frastructures 1, 247–257.

[65] Mogihim, F.H., Zadeh, H., Wickramasinghe,N., 2012. An intelligence e-risk detectionmodel to improve decision efficiency in thecontext of the orthopaedic operating room,in: Critical Issues for the Development ofSustainable E-health Solutions. Springer, pp.17–32.

[66] Mollenkamp, C., Sonne, P., Hall, D., 2011.Rogue trading lasted 3 years. The Wall StreetJournal.

[67] Neiger, D., Churilov, L., zur Muehlen, M.,Rosemann, M., 2006. Integrating risks inbusiness process models with value focusedprocess engineering, in: Ljungberg, J., An-dersson, M. (Eds.), ECIS, pp. 1606–1615.

[68] Object Management Group (OMG),2011. Business Process Model andNotation (BPMN) ver. 2.0. ObjectManagement Group (OMG). URL:http://www.omg.org/spec/BPMN/2.0.

[69] Oracle, http://download.oracle.com/docs/cd/E15523 01/integration.1111/e10224/bpsensors.htm. Accesssed: June 2011. BPELProcess Manager Developer’s Guide.

[70] Panayiotou, N.A., Oikonomitsios, S.,Athanasiadou, C., Gayialis, S.P., . Riskassessment in virtual enterprise networks:A process-driven internal audit approach,

36

in: Managing Risk in Virtual EnterpriseNetworks: Implementing Supply ChainPrinciples. IGI Global.

[71] Recker, J., 2010a. Continued use of processmodeling grammars: the impact of individ-ual difference factors. European Journal ofInformation Systems 19, 76–92.

[72] Recker, J., 2010b. Explaining usage of pro-cess modeling grammars: Comparing threetheoretical models in the study of two gram-mars. Information & management 47, 316–324.

[73] Recker, J., 2010c. Opportunities and con-straints: the current struggle with bpmn.Business Process Management Journal 16,181–201.

[74] Recker, J., La Rosa, M., 2012. Understand-ing user differences in open-source workflowmanagement system usage intentions. Infor-mation Systems 37, 200–212.

[75] Rikhardsson, P., Best, P.J., Green, P., Rose-mann, M., 2006. Business process risk man-agement and internal control: A proposed re-search agenda in the context of complianceand ERP systems, in: Proceedings of the Sec-ond Asia/Pacific Research Symposium on Ac-counting Information Systems, Melbourne,Australia.

[76] Rosemann, M., zur Muehlen, M., 2005. Inte-grating risks in business process models, in:ACIS, AISeL.

[77] Rotaru, K., Wilkin, C., Churilov, L., Neiger,D., 2008. Formalising risk with value-focusedprocess engineering, in: [37]. pp. 1583–1595.pp. 1583–1595.

[78] Rotaru, K., Wilkin, C., Churilov, L., Neiger,D., Ceglowski, A., 2011. Formalizing process-based risk with value-focused process engi-neering. Information Systems and e-BusinessManagement 9, 447–474.

[79] Salzer, E., 2011. Live aus der praxis–fallbeispiele fur spezifische kommunika-tionsstrategien, in: Quintessenz der Un-ternehmenskommunikation. Springer, pp.46–90.

[80] Schmitt, M., Gregoire, B., Dubois, E., 2005.A risk based guide to business process de-sign in inter-organizational business collab-oration, in: International Workshop on Re-quirements Engineering for Business Needand IT Alignment (REBNITA 2005).

[81] Schwartz, P., 2000. When good companies dobad things. Strategy & Leadership 28, 4–11.

[82] Sienou, A., Karduck, A.P., Lamine, E., Pin-gaud, H., 2008. Business process and riskmodels enrichment: Considerations for busi-ness intelligence, in: ICEBE, pp. 732 –735.

[83] Sienou, A., Karduck, A.P., Pingaud, H.,2006. Towards a framework for integratingrisk and business process management, in:Dolgui, A., Morel, G., Pereira, C.E. (Eds.),Information Control Problems in Manufac-turing. Elsevier. volume 6, pp. 615–620.

[84] Sienou, A., Lamine, E., Pingaud, H., Kar-duck, A.P., 2009. Aspects of the bprimlanguage for risk driven process engineering,in: Meersman, R., Herrero, P., Dillon, T.S.(Eds.), OTM Workshops, Springer. pp. 172–183.

[85] Sienou, A., Lamine, E., Pingaud, H., Kar-duck, A.P., 2010. Risk driven process engi-neering in digital ecosystems: Modelling risk,in: DEST, pp. 647–650.

[86] Simons, R.L., 1999. How risky is your com-pany? Harvard Business Review 77, 85.

[87] Singh, P., Gelgi, F., Davulcu, H., Yau, S.S.,Mukhopadhyay, S., 2008. A risk reductionframework for dynamic workflows, in: IEEESCC (1), IEEE Computer Society. pp. 381–388.

[88] Smallman, C., 1996. Risk and organizationalbehaviour: a research model. Disaster Pre-vention and Management 5, 12–26.

[89] Standards Australia and Standards NewZealand, 2009. Standard AS/NZS ISO 31000.

[90] Straumann, T., 2010. The UBS Crisis inHistorical Perspective. Technical Report. In-stitute for Empirical Research in Economics,University of Zurich.

[91] Strecker, S., Heise, D., Frank, U., 2010.RiskM: A multi-perspective modelingmethod for IT risk assessment. InformationSystems Frontiers 13, 1–17.

[92] Suriadi, S., Weiß, B., Winkelmann, A.,ter Hofstede, A., Wynn, M., Ouyang, C.,Adams, M., Conforti, R., Fidge, C., La Rosa,M., Pika, A., 2012. Current Research inRisk-Aware Business Process Management -Overview, Comparison, and Gap Analysis.BPM Center Report BPM-12-13. BPMcen-ter.org.

[93] Sybase, http://www.sybase.com.au/files/

37

White Papers/Sybase CEP ImplementationMethodology wp.pdf. Accessed: June 2011.Sybase CEP Implementation Methodologyfor Continuous Intelligence.

[94] Taylor, P., Godino, J.J., Majeed, B., 2008.Use of fuzzy reasoning in the simulation ofrisk events in business processes, in: Louca,L., Chrysanthou, Y., Oplatkova, Z., AlBe-gain, K. (Eds.), Proceedings of the 22nd Eu-ropean Conference on Modelling and Simula-tion, pp. 25–30.

[95] ter Hofstede, A.H.M., van der Aalst, W.M.P.,Adams, M., Russell, N., 2010. Modern Busi-ness Process Automation: YAWL and itsSupport Environment. Springer.

[96] Thomas, H., 2010. Sick to Death. Allen &Unwin.

[97] Tjoa, S., Jakoubi, S., Quirchmayr, G., 2008.Enhancing business impact analysis and riskassessment applying a risk-aware businessprocess modeling and simulation methodol-ogy, in: ARES, IEEE Computer Society. pp.179–186.

[98] Voluntary Interindustry Commerce SolutionsAssociation, http://www.vics.org. Accessed:June 2011. Voluntary Inter-industry Com-merce Standard (VICS).

[99] Wang, D., Rundensteiner, E.A., Ellison,R.T., Wang, H., 2011. Active complex eventprocessing infrastructure: Monitoring and re-acting to event streams, in: Abiteboul, S.,Bohm, K., Koch, C., Tan, K.L. (Eds.), ICDEWorkshops, IEEE. pp. 249–254.

[100] Weiß, B., Winkelmann, A., 2011. Develop-ing a process-oriented notation for modelingoperational risks - a conceptual metamodelapproach to operational risk management inknowledge intensive business processes withinthe financial industry, in: HICSS, IEEE Com-puter Society. pp. 1–10.

[101] Woo, G., 2008. Terrorism Risk. Wiley Hand-book of Science and Technology for Home-land Security. 2:1–17. John Wiley & Sons.

[102] zur Muehlen, M., Ho, D.T.Y., 2005. Riskmanagement in the bpm lifecycle, in: Bus-sler, C., Haller, A. (Eds.), Business ProcessManagement Workshops, pp. 454–466.

38

Appendix A. Detailed Abstract Syntax

This Appendix provides a detailed description of each element of the abstract syntax ofthe sensor definition language.

Definition Description

Sensor , v : Variables; t : Trigger ; riskCon : RiskCon; A sensor is composed of a set of variables, a trigger,faultCon : BoolCon; consequence : MaCon; a risk condition, a fault condition, and a consequence.

Trigger , timer | event A trigger can either can be timer or event based.

Variables , Assignment+ A set of variables is a several assignments.

Assignment , result : varName; i : Info A variable assigns a name to an information.

Info , VarFun | Definition | CaseExp | An information is a function invoked on a variable,CaseEleExp a definition, or a piece of information collected from

the process instance (i.e. CaseExp or CaseEleExp).

VarFun , ResCon | ResSimFun | ResComFun The three types of functions invoked on variables areavailable: ResCon, ResSimFun or ResComFun.

Definition , c : constant A definition is a constant.

CaseExp , cis : CaseIDStat ; a : Action A piece of information related to the process instance.

CaseEleExp , ce : CaseExp; ton : TaskOrNet A piece of information related to an element(i.e. a task or a net) of the process instance.

TaskOrNet , taskLabel | netName The identifier of a task or of a net.

CaseIDStat , absExp | relExp | CaseConSet Identifies an instance or a set of instances.

Action , predAct | taskOrNetVar | SubVarExp | An action is either a predefined action, a taskinputPredAct variable, a net variable, a subvariable, or a

predefined action that requires an input.

SubVarExp , var+ A subvariable of a task variable or of a net variable.

CaseConSet , CaseCon | CaseParam | CaseConExp The three types of identifiers for a set of instances.

CaseCon , ton : TaskOrNet ; a : Action; co : CompOp; Identifies instances for which a specific piece ofrhe : RHExp information is compared with a RHExp.

CaseParam , i : idFun; co : CompOp; rhe : RHExp Identifies instances for which the instance IDis compared with a RHExp.

CaseConExp , ccs1 , ccs2 : CaseConSet ; bo : BoolOp Identifies instances for which several conditionsare satisfied.

CompOp , l | leq | g | geq | eq | contains | isContained Set of comparison operators.

RHExp , constant | function | varName | RHExpSet Can be a constant, a function, a function invokedon a variable, or a RHExpSet .

RHExpSet , rhe1 , rhe2 : RHExp; o : Op An arithmetical expression built using RHExp.

RiskCon , riskLikelihood , riskThreshold : MaCon A risk condition is composed of two MaCon.

MaCon , MaITE | MaExp | MaFor | FixMaFor | A arithmetical condition can be an if-then-elseResSimFun | ResComFun | varName | expression, an expression, a loop, a function on aconstant variable, a variable name, or a constant.

MaITE , if : BoolCon; then, else : MaCon A arithmetical condition that varies based on theresult of a boolean condition.

MaExp , MaUnExp | MaBinExp The two types of arithmetical expression:MaUnExp or MaBinExp.

MaUnExp , s : sub; me : MaCon A negative arithmetical expression.

MaBinExp , me1 ,me2 : MaCon; mo : MaOp A arithmetical operation between MaCons.

MaOp , add | sub | mul | div | exp | mod The set of arithmetical operators.

BoolCon , BoolITE | BoolExp | BoolFor | A boolean condition can be an if-then-else expression,FixBoolFor | Comp | ResCon | an expression, a loop, a comparison, a function on avarName | constant variable, a variable, or a constant.

BoolITE , if , then, else : BoolExp A boolean condition that varies based on the result ofanother boolean condition.

BoolExp , BoolUnExp | BoolBinExp The two types of boolean expression:BoolUnExp or BoolBinExp.

BoolUnExp , n : neg; e : BoolCon A negated boolean expression.

BoolBinExp , e1, e2 : BoolCon; bo : BoolOp A boolean operation between BoolCons.

BoolOp , and | or The set of boolean operators.

39

Definition Description

Comp , ce1 , ce2 : CompElem; co : CompOp A comparison between two CompElems.

CompElem , MaCon | ResListFun | varName | constant A comparison element can be a arithmeticalcondition, a function invoked on a variable,a variable, or a constant.

ResCon , res : varName; a : Activity A function invoked on a variable using an activity.

ResListFun , result : varName; lrf : listResFun A function invoked on a variable. It returns a list.

ResSimFun , resource : varName; srf : simResFun A function invoked on a variable which is a resource.

ResComFun , res1 , res2 : varName; crf : comResFun A function invoked on two variables which are resources.

Activity , resource : varName; lrf : ResListFun A function invoked on a variable which is a resources.

MaFor , t : TypeMF ; lr : ListResult ; A nested loop that cycles on each element of afme : ForMaCon ListResult and aggregates the result of a ForMaCon

based on a TypeMF .

FixMaFor , fixEle : varName; mf : MaFor A MaFor that cycles on each element of a ListResultusing as index of the loop the element fixEle.

TypeMF , add | mul Two forms of aggregations: adding and multiplying.

BoolFor , t : TypeBF ; lr : ListResult ; A nested loop that cycles on each element of afbe : ForBoolCon ListResult and aggregates the result of a ForBoolCon

based on a TypeBF .

FixBoolFor , fixEle : varName; bf : BoolFor A BoolFor that cycles on each element of a ListResultusing as index of the loop the element fixEle.

TypeBF , and | or Two forms of aggregations: AND or OR.

ListResult , varName+ A list of variables.

ForMaCon , ForMaITE | ForMaExp | constant | A arithmetical condition can be an if-then-elsevarName expression, an expression, a constant, or a variable.

ForMaITE , if : ForBoolCon; A arithmetical condition that varies based on thethen, else : ForMaCon result of a boolean condition.

ForMaExp , ForMaUnExp | ForMaBinExp The two types of arithmetical expression:ForMaUnExp or ForMaBinExp.

ForMaUnExp , s : sub; me : ForMaCon A negative arithmetical expression.

ForMaBinExp , me1 ,me2 : ForMaCon; mo : MaOp A arithmetical operation between ForMaCon.

ForBoolCon , ForBoolITE | ForBoolExp | ForComp | A boolean condition can be an if-then-else expression,varName | constant an expression, a comparison, a variable, or a constant.

ForBoolITE , if , then, else : ForBoolExp A boolean condition that varies based on the result ofanother boolean condition.

ForBoolExp , ForBoolUnExp | ForBoolBinExp The two types of boolean expression:ForBoolUnExp or ForBoolBinExp.

ForBoolUnExp , n : neg; e : ForBoolCon A negated boolean expression.

ForBoolBinExp , e1, e2 : ForBoolCon; bo : BoolOp A boolean operation between ForBoolCons.

ForComp , ce1 , ce2 : ForCompElem; co : CompOp A comparison between two ForCompElems.

ForCompElem , ForMaCon | varName | constant A comparison element can be a arithmeticalcondition, a variable, or a constant.

40

Appendix B. Actions

This appendix describes all actions available in the sensor definition language.

Action Description(ID) returns the ID of the generic instance that is being analyzed[IDCurr] returns the ID of the instance that the sensor is monitoringCount returns the number of times a task has been completedofferResource returns the resources to which the task has been offeredallocateResource returns the resources to which the task has been allocatedstartResource returns the resources that started the taskcompleteResource returns the resource that completed the taskisOfferd returns “true” if the task has been offeredisAllocated returns “true” if the task has been allocatedisStarted returns “true” if the task has been startedisCompleted returns “true” if the task has been completedOfferTime returns the time when the task has been offeredAllocateTime returns the time when the task has been allocatedStartTime returns the time when the task has been startedCompleteTime returns the time when the task has been completedOfferTimeInMillis returns the time (in millisecond) when the task has been offeredAllocateTimeInMillis returns the time (in millisecond) when the task has been allocatedStartTimeInMillis returns the time (in millisecond) when the task has been startedCompleteTimeInMillis returns the time (in millisecond) when the task has been completedPassTimeInMillis returns the amount of time (in millisecond) that was needed to complete the taskTimeEstimationInMillis returns an estimation of the time (in millisecond) needed to completed the task/processVariable returns the value of the variable or sub-variable requiredofferDistribution returns the list of resources to which the task is offered by defaultallocateDistribution returns the list of resources to which the task is allocated by defaultstartDistribution returns the list of resources to which the task is started by defaultofferInitiator returns the offering policy of the task (user or system)allocateInitiator returns the allocating policy of the task (user or system)startInitiator returns the starting policy of the task (user or system)CountElements returns the number of instances that satisfy the parameters required

FraudProbabilityFunc

returns the probability of a fraud using as parameters: the current number of executions,the maximum number of executions allowed, the parameter used to group these instances,the parameter used to identify a temporal window, and the dimension of the temporalwindow

List of actions of the architecture

Appendix C. Nested Loops

This appendix describes the four types of nested loops available in the sensor definitionlanguage.

For Description

forAND[][]executes a nested loop for each list provided in input (among the first couple of brackets) resolving theexpression (defined among the second couple of brackets), then returns the AND conjunction of theresults obtained

forOR[][]executes a nested loop for each list provided in input (among the first couple of brackets) resolving theexpression (defined among the second couple of brackets), then returns the OR conjunction of theresults obtained

forADD[][]executes a nested loop for each list provided in input (among the first couple of brackets) resolving theexpression (defined among the second couple of brackets), then returns the sum of the results obtained

forMUL[][]executes a nested loop for each list provided in input (among the first couple of brackets) resolving theexpression (defined among the second couple of brackets), then returns the product of the resultsobtained

List of nested loops

41

Appendix D. Functions

This appendix describes the functions available in the sensor definition language.

Function Description

offeredListreturns the list of tasks currently offered to the resource/resources (returns a listof list if used on resources)

allocatedListreturns the list of task currently allocated to the resource/resources (returns a listof list if used on resources)

startedListreturns the list of task currently started by the resource/resources (returns a listof list if used on resources)

offeredNumberreturns the number of tasks currently offered to the resource/resources (returnsa list if used on resources)

allocatedNumberreturns the number of tasks currently allocated to the resource/resources (returnsa list if used on resources)

startedNumberreturns the number of tasks currently started by the resource/resources (returnsa list if used on resources)

offeredMinNumber returns the minimum number of tasks currently offered to the resource/resourcesallocatedMinNumber returns the minimum number of tasks currently allocated to the resource/resourcesstartedMinNumber returns the minimum number of tasks currently started by the resource/resources

offeredMinNumberExceptreturns the minimum number of tasks currently offered to the resource/resourcesexcluding the resource/resources provided in input (the input is provided usinga dotted format after the name of the function)

allocatedMinNumberExceptreturns the minimum number of tasks currently allocated to the resource/resourcesexcluding the resource/resources provided in input (the input is provided using adotted format after the name of the function)

startedMinNumberExceptreturns the minimum number of tasks currently started by the resource/resourcesexcluding the resource/resources provided in input (the input is provided using adotted format after the name of the function)

offeredContainreturns true if the task provided in input (using a dotted format after the nameof the function) is currently offered to the resource/resources.

allocatedContainreturns true if the task provided in input (using a dotted format after the nameof the function) is currently allocated to the resource/resources.

startedContainreturns true if the resource/resources started the task provided in input (usinga dotted format after the name of the function).

List of functions

42

Appendix E. Questionnaire

Part 1) Background Questions

E1a: Which description matches bestyour current status?

� Student

� Academic

� Professional

E1b:Please specify your gender:

� Female

� Male

� Prefer not to tell.

E2: How many years ago did you startprocess modeling?

Years

E3a: How many process models have youanalyzed or read within the last 12 months?(A year has about 250 work days. In caseyou read one model per day, this would sumup to 250 models per year)

Models

E3b: How many process models have youcreated or edited within the last 12 months?

Models

E3c: How many activities did all thesemodels have on average?

Activities

E4a: How many work days of formaltraining on process modeling have you re-ceived within the last 12 months? (This in-cludes e.g. university lectures, certificationcourses, training courses. 10 weeks of a 120minute university lecture is roughly 3 workdays)

Days

E4b: How many work days of self-education have you made within the last 12months? (This includes e.g. learning-by-doing, self-study of textbooks or specifica-tions)

Days

Part 2) Your experience with Work-flow Management Systems

Q1: Which of the following (process)modelling techniques other than YAWLhave you used to describe a process or pro-cedure? Tick all that apply.

� None. Please go to question 10.

� BPMN

� UML

� Activity Diagrams

� EPCs

� BPEL

� Petri Nets

� Protos

� Other:

43

Q2: If you have used any technique otherthan YAWL, roughly, how many concep-tual process models do you think you havecreated?

process models

Q3: If you have used any technique otherthan YAWL, roughly, how many workflowmodels (i.e. executable process models) doyou think you have read?

workflow models

Q4: How long have you been using aWorkflow Management System?

� I am evaluating to do so/I have juststarted

� Less than 1 month

� 1 - 6 months

� 7 - 12 months

� More than 1 year

Q6: Indicate your level of agreement tothe following statements on the given scaleby circling the number that best describesyour view on the statement.

Str

on

gly

dis

agre

e

Dis

agre

e

Som

ewh

at

dis

agre

e

Norm

al

Som

ewh

at

agre

e

Agre

e

Str

on

gly

agre

e

Overall, I am veryfamiliar with Workflow ManagementSystems.

1 2 3 4 5 6 7

I feel very confidentin my understandingof WorkflowManagementSystems.

1 2 3 4 5 6 7

I feel very competentin using WorkflowManagementSystems.

1 2 3 4 5 6 7

Part3) Your experience with theYAWL system

Q1: How long have you been usingYAWL?

� I am evaluating to do so/I have juststarted

� Less than 1 month

� 1 - 6 months

� 7 - 12 months

� More than 1 year

Q2: Please indicate, roughly, the typi-cal extent of usage of YAWL. This includesany activity related to the YAWL system,e.g. development, reading documentation,modelling, executing or simulating YAWLworkflows, and using a system that is basedon some YAWL component. Keep in mind,a regular working days has eight hours (480minutes).

� Not applicable

� On average, I spend hours andminutes on YAWL every working

day.

Q3: Roughly, how many YAWL modelsdo you think you have created or read?

YAWL models

Q4: Which features of the YAWL systemhave you ever used? Tick all that apply

� Not applicable

� Execution environment

44

� Syntax checker/verification

� Cancelation region

� OR-join

� Multiple instance task

� Deferred choice

� Milestone

� Retain familiar/Separation of duties

� Deferred distribution

� Distribution set filter

� Allocation strategies

� Worklets/Exlets

� Custom services

� Configuration

Part 4) Risk Sensor ComprehensionIn this part, you will be shown 3 risks re-

lated to a process described in YAWL. Youwill be asked questions about each of them.

Risk 1: Consider the following YAWLmodel and associated risk condition de-scribed below.

Variables:A = case(current).Update Shipment Payment

Order(Count)B = case(Update Shipment Payment

Order(Count)>=E).Update ShipmentPayment Order(CountElements)

C = case(Update Shipment PaymentOrder(Count)>=A AND ProcessShipment Payment(isOffered)=“true”).Update Shipment PaymentOrder(CountElements)

D = 0.6E = 5

Sensor Condition:(C/B)>D where“/”is the division operator

Q0. How difficult is it to understand themeaning of the above sensor condition:

� 1 – very simple

� 2 – rather simple

� 3 – neutral

� 4 – rather difficult

� 5 – very difficult

Q1. Does the sensor send a notification ifthe task Update Shipment Payment Ordermay not be executed?

� Yes / No / I do not know

Q2. Can the sensor notify a risk if thetask Update Shipment Payment Order hasbeen executed only twice?

� Yes / No / I do not know

Q3. Does A retrieve the value of a vari-able named Count of the task Update Ship-ment Payment Order?

� Yes / No / I do not know

Q4.Does C return the number of in-stances where the task Process ShipmentPayment has been offered?

45

� Yes / No / I do not know

Q5. Does D indicate a threshold that ifexceeded produces a notification from thesensor?

� Yes / No / I do not know

Risk 2: Using the YAWL model of page6 above, an Approval fraud risk has beenidentified using Fault Tree Analysis, asshown below.

To detect the risk of this fault, we firsthave to check whether there is an order, sayorder o of customer c, to be approved. Thismeans checking that an instance of task Ap-prove Shipment Payment Order is being ex-ecuted. Moreover, we need to check thateither of the following conditions holds:

1. o has been allocated to a Senior Fi-nance Officer who has already ap-proved another order for the same cus-tomer in the last d days; or

2. at least one Senior Finance Officer isavailable who approved an order forcustomer c in the last d days andall other Senior Finance Officers whonever approved an order for c duringthe last d days are available

Q0. How difficult is it to understand themeaning of the above risk:

� 1 – very simple

� 2 – rather simple

� 3 – neutral

� 4 – rather difficult

� 5 – very difficult

Q1. Could condition Abe used as triggerfor the sensor?

� Yes / No / I do not know

Q2. If condition B is expressed using avariable, would the following assignment becorrect?

B = case(current).Approve ShipmentPayment Order(allocateResource)

� Yes / No / I do not know

Q3. Could condition D be expressed us-ing only one variable in the risk condition?

� Yes / No / I do not know

Q4. Could condition E be expressed us-ing only one variable in the risk condition?

� Yes / No / I do not know

Q5. Could the AND between conditionsB and C be expressed using only one vari-able in the risk condition?

� Yes / No / I do not know

46

Risk 3: Consider the following YAWLmodel and the associated risk conditiondescribed below.

Variables:A = case(current).Process Shipment

Payment.CustomerB = case(Process Shipment Payment.

Customer=A AND Issue DebitAdjustment(isCompleted)=“true”).Issue Debit Adjustment(CountElements)

C = case(Process Shipment Payment.Customer=A AND Issue CreditAdjustment(isCompleted)=“true”).Issue Debit Adjustment(CountElements)

D = case(Process Shipment Payment.Customer=A).Process ShipmentPayment(CountElements)

F = 0.4

Sensor Condition:(B/D)>F|(C/D)>F where“/” is the di-vision operator and “|” is the logical ORoperator

Q0. How difficult is it to understand themeaning of the above sensor condition:

� 1 – very simple

� 2 – rather simple

� 3 – neutral

� 4 – rather difficult

� 5 – very difficult

Q1. Does the sensor send a notificationif the task Issue Debit Adjustment is notexecuted?

� Yes / No / I do not know

Q2. Will the sensor send a notification assoon as the task Issue Credit Adjustment iscompleted?

� Yes / No / I do not know

Q3. Does B return the number of in-stances where the customer is the sameof the current instance and the task IssueDebit Adjustment has been completed?

� Yes / No / I do not know

Q4. Does C return the number of in-stances where the task Process ShipmentPayment has been offered?

� Yes / No / I do not know

Q5. Does B always return a value greaterthan the value return by C?

� Yes / No / I do not know

Part 5) Your views on the use ofthe Sensor-based component of theYAWL system

This part of the survey captures some in-formation about how you overall rate theSensor-based component of the YAWL sys-tem you have been using. Please note againthat all information you provide will betreated confidently. Thus, we ask you toplease answer honestly.

In the following, you will be given anumber of statements on opinions thatyou may have towards the Sensor-basedcomponent of the YAWL system. Pleaseindicate your level of agreement to the

47

statements on the given scale by tickingthe box that best describes your view onthe respective statement.

Facilitating Str

on

gly

dis

agre

e

Dis

agre

e

Som

ewh

at

dis

agre

e

Norm

al

Som

ewh

at

agre

e

Agre

e

Str

on

gly

agre

e

ConditionsGuidance wasavailable to me inthe use of theSensor-basedcomponent of theYAWL system.

1 2 3 4 5 6 7

Specializedinstructionconcerning the use ofthe Sensor-basedcomponent of theYAWL system wasavailable to me.

1 2 3 4 5 6 7

A specific person orgroup was availablefor assistance withdifficulties with theSensor-basedcomponent of theYAWL system.

1 2 3 4 5 6 7

Satisfaction Str

on

gly

dis

agre

e

Dis

agre

e

Som

ewh

at

dis

agre

e

Norm

al

Som

ewh

at

agre

e

Agre

e

Str

on

gly

agre

e

I am extremelypleased with my useof the Sensor-basecomponent of theYAWL system.

1 2 3 4 5 6 7

I am extremelycontented with myuse of theSensor-basecomponent of theYAWL system.

1 2 3 4 5 6 7

I am extremelydelighted with myuse of theSensor-basecomponent of theYAWL system.

1 2 3 4 5 6 7

I am extremelysatisfied with my useof the Sensor-basecomponent of theYAWL system.

1 2 3 4 5 6 7

Perceived Str

on

gly

dis

agre

e

Dis

agre

e

Som

ewh

at

dis

agre

e

Norm

al

Som

ewh

at

agre

e

Agre

e

Str

on

gly

agre

e

UsefulnessOverall, I find theSensor- basedcomponent of theYAWL system usefulfor modellingprocess-related risks.

1 2 3 4 5 6 7

I find theSensor-basedcomponent of theYAWL system usefulfor achieving thepurpose of modellingprocess-related risks.

1 2 3 4 5 6 7

I find theSensor-basedcomponent of theYAWL system helpsme in meeting myprocess-related risksmodelling objectives.

1 2 3 4 5 6 7

Perceived Str

on

gly

dis

agre

e

Dis

agre

e

Som

ewh

at

dis

agre

e

Norm

al

Som

ewh

at

agre

e

Agre

e

Str

on

gly

agre

e

Ease of UseI find it easy tomodel process-related risks in theway I intended usingthe Sensor-basedcomponent of theYAWL system.

1 2 3 4 5 6 7

I find learning to usethe Sensor-basedcomponent of theYAWL system iseasy.

1 2 3 4 5 6 7

I find easy to createprocess-related risksusing theSensor-basedcomponent of theYAWL system.

1 2 3 4 5 6 7

48

Intention Str

on

gly

dis

agre

e

Dis

agre

e

Som

ewh

at

dis

agre

e

Norm

al

Som

ewh

at

agre

e

Agre

e

Str

on

gly

agre

e

to UseI intend to use theSensor-basedcomponent of theYAWL system whenI have to define anddetect risks inbusiness processes.

1 2 3 4 5 6 7

I predict I would usethe Sensor-basedcomponent of theYAWL system.

1 2 3 4 5 6 7

I plan to use theSensor-basedcomponent of theYAWL system in thefuture.

1 2 3 4 5 6 7

I prefer to continueto work with theSensor-basedcomponent of theYAWL system.

1 2 3 4 5 6 7

49