Post on 21-Jun-2015
description
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
IT UNIVERSITY OF COPENHAGEN
CSCW in Healthcare, University of Copenhagen, 27 June, 2014
Thomas Hildebrandt - hilde@itu.dk
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
IT UNIVERSITY OF COPENHAGEN
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
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Let us look at the process..
4
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Let us look at the process..
4
Only the “happy” path is described
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Let us look at the process..
4
Only the “happy” path is described
Other patient conditions or on-going treatments are not taken into account
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Let us look at the process..
4
Only the “happy” path is described
Other patient conditions or on-going treatments are not taken into account
Only describes how not why
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Let us look at the process..
4
Only the “happy” path is described
Other patient conditions or on-going treatments are not taken into account
Only describes how not why
Typically introduces unnecessary dependencies
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Model all routes?
5
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Model all routes?
5
A complex “Spaghetti” diagram- that still only describes how and not why
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Model all routes?
5
A complex “Spaghetti” diagram- that still only describes how and not why
and describes only the anticipated events
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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, w.m.p.v.d.aalst@tue.nl
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
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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.”
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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.”
from BPM
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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.”
from BPM to ACM
(record)
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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.”
from BPM to ACM
(record)
Process“snippets”
or “fragments”
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
What could we have done?
8
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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
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
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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
WriteDischarge Letter
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
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
SimulaKon of Process
11
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
SimulaKon of Process
12
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
SimulaKon of Process
13
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
SimulaKon of Process
14
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
SimulaKon of Process
15
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
SimulaKon of Process
16
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Agile to Live Development?• When to involve the users ?
Requirement Specification
Implementation
Test
Configure
Go-Live
17
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Agile to Live Development?• When to involve the users ?
Requirement Specification
Implementation
Test
Configure
Go-Live
17
Chaos
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Agile to Live Development?• When to involve the users ?
Requirement Specification
Implementation
Test
Configure
Go-Live
17
ChaosDepression
Agile Development of a Grant Application System
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
CollaboraKve Modelling
19
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
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
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
• (Live) Expert end-user co-development
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
• (Live) Expert end-user co-development
• Communication - with and between users
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
• (Live) Expert end-user co-development
• Communication - with and between users
• Usability test (at run-time)
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
• (Live) Expert end-user co-development
• Communication - with and between users
• Usability test (at run-time)
• Process mining & uncertainty
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
• (Live) Expert end-user co-development
• Communication - with and between users
• Usability test (at run-time)
• Process mining & uncertainty
• Reliable & adaptable protocols for communication with external systems
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Ongoing Research
21
• How can we make ACM useful in practice?
• (Live) Expert end-user co-development
• Communication - with and between users
• Usability test (at run-time)
• Process mining & uncertainty
• Reliable & adaptable protocols for communication with external systems
• Case studies
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
Flow-‐chart based guidance....
22
IT UNIVERSITY OF COPENHAGEN
Agile Development of a Grant Application System September 1st, 2014
23
Constraint based guidance