A Case for Declarative Process Modelling - Slides on Adaptive Case Managment from AdaptiveCM 2014 workshop

IT UNIVERSITY OF COPENHAGEN

September 1, 2014

A Case for Declarative Process Modelling:Agile Development of a Grant Application System

Morten Marquard &Thomas Hildebrandt

joint work withTijs Slaats, & Søren Debois


CSCW in Healthcare, University of Copenhagen, 27 June, 2014

Thomas Hildebrandt - [email protected]

2010: Case Studies of Best Practice Workflow and Workflow in Practice (Innovation Network)

A single slide about me

2

CSCWd

21

2 1

bN

a

c

a b

d’

b’a’

c’

a’ b’N’

1

12

2

Figure 6.1: Two labelled nets N and N ′ that are HP bisimilar but not HHP bisimilar. Thetransitions are labelled by the actions {a, b, c, d} as the names suggest, e.g. a1 is labelled bya

extends the classical notion of bisimulation with the requirement, that any two related runsmust have the same causal dependency between actions, that is the same history. Heredi-tary HPB additionally imposes a backtracking condition: for any two related runs, the runsobtained by backtracking a pair of related transitions, must be related, too. We allow back-tracking not only in the order which is laid down by the related runs; as long as no othertransitions depend on a particular transition, it can be backtracked. Thereby it is ensuredthat the matching is not dependent on the order in which independent actions are linearized.Intuitively this is what we expect from a bisimulation for concurrency.

Figure 6.1 shows the standard example from [95] of two systems that are plain but nothereditary HP bisimilar. Both systems have an a-action (b-action) that can be followed bya dependent c-action (d-action) or an independent (not competing on any places) b-action(a-action). And both have an a-action (a b-action) which can be followed by an independentb-action (a-action). Consequently, the two systems are HP bisimilar. However, observe thatin any HPB we can find, the matching of the parallel a- and b-transitions depends on theorder in which they appear in the runs to match. So, the systems are not hereditary HPbisimilar. Note that the c transition dictates that we have to match a1 to a′1, and so a1.b1

to a′1.b′1. Then the backtracking condition requires that b1 and b′1 are related. But from this

point, the system N ′ can make a d transition which N cannot match, so b1 and b′1 can clearlynot be related runs.

After stating the necessary definitions in Sec. 6.1, we present a trace-theoretical char-acterisation of the difference between HHPB and HPB in Sec. 6.2. This will confirm ourview of HHPB as a bisimulation for concurrency as opposed to HPB as a bisimulation forcausality. In Sec. 6.3, we consider the effect of restricting HHPB, by bounding how far backin two related runs one can pick transitions to backtrack. Remarkably, we prove in Sec. 6.3.1that for a fixed bound, each such bisimulation is decidable. However, in Sec. 6.3.2 we findthat the bounded bisimulations form a strict hierarchy, all trivially stronger than HPB butalso strictly weaker than hereditary HPB. In Sec. 6.4 we apply our results to approach thedecidability of HHPB (for finite-state systems). After noting that decidability follows almostimmediately for the class of bounded asynchronous nets, we present a non-trivial reduction inSec. 6.4.2 showing that HHPB is decidable for systems with transitive independence relation.In the end, we remark on other partial results and give directions for further progress.

Let us note that one can also consider hidden actions in the context of HPB and HHPB.To avoid confusion with this standard use of strong and weak in the context of bisimulation,

63

Foundational Process Models &Theoretical Computer Science

BRICSDS-00-1

T.T.Hildebrandt:C

ategoricalModelsfor

Concurrency:Independence,Fairnessand

Dataflow

BRICSBasic Research in Computer Science

Categorical Models for Concurrency:Independence, Fairness and Dataflow

Thomas Troels Hildebrandt

BRICS Dissertation Series DS-00-1

ISSN 1396-7002 February 2000

PhD, Aarhus University, 2000

Interdisciplinary research projects with industry

www.itu.dk/research/models2012: Head of Process & System Models Group

2007-11: Computer Supported Mobile Adaptive Business Processes (Foundations of Technology and Production)

2008-2012: Trustworthy Pervasive Healthcare Processes (Strategic Research)

2011-2014: Flexible Cross-organizational Case Management (Industrial PhD) 2004-2011: Director of FIRST PhD School

2000-2003: Head of Study Program on Internet Technology

2014-17: Computational Artifacts: Design Oriented Theory of Computational Artifacts in Cooperative Work Practices (Velux, www.COMPART.ku.dk)

2012-: EU COST Action IC1201 - Behavioural Types for Reliable Large-Scale Software Systems

http://www.COMPART.ku.dk




Agile Development of a Grant Application System September 1st, 2014

IT Supported Flexible Processes

3

However, the focus is not on data but on process-related information (e.g., theordering of activities). Process mining is also related to monitoring and businessintelligence [41].

8 ConclusionProcess-aware information systems (PAISs) follow a characteristic life-cycle. Fig-ure 13 shows the four phases of such a life-cycle [7]. In the design phase, theprocesses are (re)designed. In the configuration phase, designs are implementedby configuring a PAIS (e.g., a WFMS). After configuration, the enactment phasestarts where the operational business processes are executed using the system con-figured. In the diagnosis phase, the operational processes are analyzed to identifyproblems and to find things that can be improved. The focus of traditional work-flow management (systems) is on the lower half of the life-cycle. As a result thereis little support for the diagnosis phase. Moreover, support in the design phase islimited to providing an editor while analysis and real design support are missing.

Figure 13: PAIS life-cycle.

In this article, we showed that PAISs support operational business processesby combining advances in information technology with recent insights from man-agement science. We started by reviewing the history of such systems and thenfocused on process design. From the many diagramming techniques available, wechose one particular technique (Petri nets) to show the basics. We also emphasizedthe relevance of process analysis, e.g., by pointing out that 20 percent of the morethan 600 process models in the SAP reference model are flawed [24]. We also

26

Process enactment



Let us look at the process..

4




4

Only the “happy” path is described




4


Other patient conditions or on-going treatments are not taken into account




4



Only describes how not why




4



Only describes how not why

Typically introduces unnecessary dependencies



Model all routes?

5



Model all routes?

5

A complex “Spaghetti” diagram- that still only describes how and not why



Model all routes?

5

A complex “Spaghetti” diagram- that still only describes how and not why

and describes only the anticipated events



Flexibility vs Support

6

MotivationFlexibility versus Support in workflows

• Flexibility: ability to defer, change, and deviate

• support: provide analysis and guidance

• unstructured: do what ever you want, but get no support

• structured: support, but no flexibilityClassical trade-off between flexibility and support1

[1] W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support

Sunday, March 14, 2010

MotivationFlexibility versus Support in workflows

• Flexibility: ability to defer, change, and deviate

• support: provide analysis and guidance

• unstructured: do what ever you want, but get no support

• structured: support, but no flexibilityClassical trade-off between flexibility and support1

[1] W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support

Sunday, March 14, 2010

[Schmidt & Bannon: Taking CSCW Seriously: Supporting Articulation Work, 1992]

Already in 1983, researchers in Computer Supported Cooperative Work (CSCW) concluded that office automation systems “do not deal well with unanticipated conditions” (Barber) & “were automating a fiction” (Sheil)

“Good standards for business process modelling are still missing and even today’s

WFMSs are too rigid”Process-Aware Information Systems:Design, Enactment, and AnalysisWil M.P. van der AalstDepartment ofMathematics and Computer Science, Eindhoven University of Tech-nology, P.O. Box 513, NL-5600 MB Eindhoven, [email protected]

Abstract. Process-aware information systems support operational business pro-cesses by combining advances in information technology with recent insightsfrom management science. Workflow management systems are typical examplesof such systems. However, many other types of information systems are also“process aware” even if their processes are hard-coded or only used implicitly(e.g., ERP systems). The shift from data orientation to process orientation has in-creased the importance process-aware information systems. Moreover, advancedanalysis techniques ranging from simulation and verification to process miningand activity monitoring allow for systems that support process improvement invarious ways. This article provides an overview of process-aware informationsystems and also relates these to business process management, workflow man-agement, process analysis techniques, and process flexibility.

Keywords: Process-Aware Information Systems, Workflow Management, Busi-ness Process Management, Petri Nets, Process Mining, Process Verification, Sim-ulation

1 IntroductionInformation technology has changed business processes within and between enter-prises. More and more work processes are being conducted under the supervisionof information systems that are driven by process models. Examples are work-flow management systems such as FileNet P8, Staffware, WebSphere, FLOWerand YAWL and Enterprise Resource Planning (ERP) systems such as SAP andOracle. Moreover, many domain specific systems have components driven by(process) models. It is hard to imagine enterprise information systems that areunaware of the processes taking place. Although the topic of business processmanagement using information technology has been addressed by consultants

1



AdapKve Case Management

7

http://www.xpdl.org/nugen/p/adaptive-case-management/public.htmWfMC

“Adaptive Case Management (ACM) is information technology that exposes structured and unstructured business information (business data and content) and allows structured (business) and unstructured (social) organizations to execute work (routine and emergent processes) in a secure but transparent manner.”

http://www.xpdl.org/nugen/p/adaptive-case-management/public.htm





7



from BPM






7



from BPM to ACM

(record)






7



from BPM to ACM

(record)

Process“snippets”

or “fragments”





What could we have done?

8



Events & Compliance Rules

9

10.1 Motivation 299

Sur

gic a

lSui

tedischarge letter

for referring phys.O

utpa

tient

Dep

artm

ent

Sur

gica

lWar

d

MT

AP

hysi

cia n

Phy

sici

anN

u rse

AdmitPatient

PerformCheckup

ExaminePatient

Inform aboutRisks

Inform aboutAnesthesia

MakeDecision

CheckPatient Record

AdmitPatient

ScheduleSurgery

WriteDischarge Letter


MakeLab Rest

CreateSurgery Report

ProvidePostsurgical Care

DischargePatient

TransportPatient to Ward

surgeryok

PerformSurgery

PreparePatient

Send Patientto Surgical Suite

Fig. 10.1 Prespecified process model Smed

Table 10.1 Examples of compliance rules for medical processes

c1 Before a surgery may be performed the patient must be prepared for it and be sent tothe surgical suite.

c2 After examining the patient a decision must be made. However, this must not be donebefore the examination.

c3 After the examination, the patient must be informed about the risks of the (planned)surgery.

c4 Before scheduling the surgery the patient has to be informed about anesthesia.

c5 If a surgery has not been scheduled it must not be performed.

c6 After a patient is discharged a discharge letter must be written.

c7 After performing the surgery and before writing the discharge letter, a surgery reportmust be created and a lab test be made.

particularly crucial for process instances defined or adapted on-the-fly (cf. Chap. 7),i.e., for which there is no fully prespecified process model. Likewise, compliancemonitoring at run-time is required if a priori compliance checking is not feasible,e.g., if the process model is too large or the compliance rules are too complex.Regarding completed process instances, in addition, a process-aware informationsystem (PAIS) needs to be able to determine whether these instances were executedin compliance with given regulations, laws, and guidelines. For this purpose, a



Events & Compliance Rules

10

10.1 Motivation 299

Sur

gic a

lSui

tedischarge letter

for referring phys.O

utpa

tient

Dep

artm

ent

Sur

gica

lWar

d

MT

AP

hysi

cia n

Phy

sici

anN

u rse

AdmitPatient

PerformCheckup

ExaminePatient

Inform aboutRisks

Inform aboutAnesthesia

MakeDecision

CheckPatient Record

AdmitPatient

ScheduleSurgery



MakeLab Rest

CreateSurgery Report

ProvidePostsurgical Care

DischargePatient

TransportPatient to Ward

surgeryok

PerformSurgery

PreparePatient

Send Patientto Surgical Suite

Fig. 10.1 Prespecified process model Smed

Table 10.1 Examples of compliance rules for medical processes

c1 Before a surgery may be performed the patient must be prepared for it and be sent tothe surgical suite.

c2 After examining the patient a decision must be made. However, this must not be donebefore the examination.

c3 After the examination, the patient must be informed about the risks of the (planned)surgery.

c4 Before scheduling the surgery the patient has to be informed about anesthesia.

c5 If a surgery has not been scheduled it must not be performed.

c6 After a patient is discharged a discharge letter must be written.

c7 After performing the surgery and before writing the discharge letter, a surgery reportmust be created and a lab test be made.

particularly crucial for process instances defined or adapted on-the-fly (cf. Chap. 7),i.e., for which there is no fully prespecified process model. Likewise, compliancemonitoring at run-time is required if a priori compliance checking is not feasible,e.g., if the process model is too large or the compliance rules are too complex.Regarding completed process instances, in addition, a process-aware informationsystem (PAIS) needs to be able to determine whether these instances were executedin compliance with given regulations, laws, and guidelines. For this purpose, a



SimulaKon of Process

11




12




13




14




15




16



Agile to Live Development?• When to involve the users ?

Requirement Specification

Implementation

Test

Configure

Go-Live

17





Implementation

Test

Configure

Go-Live

17

Chaos





Implementation

Test

Configure

Go-Live

17

ChaosDepression

Agile Development of a Grant Application System



CollaboraKve Modelling

19



AdapKve Case Management & DCR

• Flexibility is the default

• Collaborative Modeling & Execution

• Process Fragments can be added & removed during simulation and execution

• Underlying formal model supports verification (also after dynamic adaptation)

• Events can come from many sources

20

Towards Trustworthy Adap/ve Case Management with Dynamic Condi/on Response Graphs with R. R. Mukkamala & T. Slaats, EDOC 2013, Canada

Dynamic Condi/on Response Graphs for Trustworthy Adap/ve Case Managementwith R. R. Mukkamala, M. Marquard & T. Slaats, Adap/veCM, 2013, Austria

Hierarchical Declara/ve Modelling with Sub-‐processes and Refinementwith S. Debois & T. Slaats, BPM, 2013, The Netherlands

A Case for Declara/ve Process Modelling: Agile Development of a Grant Applica/on Systemwith S. Debois, M. Marquard & T. Slaats, Adap/veCM, 2014, Germany



Ongoing Research

21



Ongoing Research

21

• How can we make ACM useful in practice?



Ongoing Research

21


• (Live) Expert end-user co-development



Ongoing Research

21



• Communication - with and between users



Ongoing Research

21




• Usability test (at run-time)



Ongoing Research

21





• Process mining & uncertainty



Ongoing Research

21






• Reliable & adaptable protocols for communication with external systems



Ongoing Research

21






• Reliable & adaptable protocols for communication with external systems

• Case studies



Flow-‐chart based guidance....

22



23

Constraint based guidance