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

1,202 views

Published on

We present the use of Dynamic Condition Response Graphs (www.DCRGraphs.net) developed at Exformatics.com and researchers in the Process and System Models Group at IT University of Copenhagen (www.itu.dk/research/models) for modelling and implementing an Adaptive Case Management system for a grant application process.

Published in: Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,202
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. September 1, 2014 A Case for Declarative Process Modelling: Agile Development of a Grant Application System IT UNIVERSITY OF COPENHAGEN Morten Marquard & Thomas Hildebrandt joint work with Tijs Slaats, & Søren Debois
  2. 2. 2012-: EU COST Action IC1201 - Behavioural Types for Reliable Large-Scale Software Sy stems IT UNIVERSITY OF COPENHAGEN CSCW in Healthcare, University of Copenhagen, 27 June, 2014 Foundational Process Models & Theoretical Computer Science PhD, Aarhus University, 2000 a’ b’ BRICS Basic Research in Computer Science 2 CSCW d c’ Categorical Models for Concurrency: Independence, Fairness and Dataflow Thomas Troels Hildebrandt BRICS Dissertation Series DS-00-1 ISSN 1396-7002 February 2000 2000-2003: Head of Study Program on Internet Technology 2012: Head of Process & System Models Group Thomas Hildebrandt - hilde@itu.dk 2010: Case Studies of Best Practice Workflow and Workflow in Practice (Innovation Network) A single slide about me 2 2 1 b b d’ a’ b’ N’ 1 2 1 BRICS DS-00-1 T. T. Hildebrandt: Categorical Models for Concurrency: Independence, Fairness and Dataflow labelled nets N and N′ that are HP bisimilar but not HHP bisimilar. The by the actions {a, b, c, d} as the names suggest, e.g. a1 is labelled by notion of bisimulation with the requirement, that any two related runs causal dependency between actions, that is the same history. Heredi-tary imposes a backtracking condition: for any two related runs, the runs backtracking a pair of related transitions, must be related, too. We allow back-tracking the order which is laid down by the related runs; as long as no other a particular transition, it can be backtracked. Thereby it is ensured not dependent on the order in which independent actions are linearized. we expect from a bisimulation for concurrency. the standard example from [95] of two systems that are plain but not bisimilar. Both systems have an a-action (b-action) that can be followed by d-action) or an independent (not competing on any places) b-action have an a-action (a b-action) which can be followed by an independent Consequently, the two systems are HP bisimilar. However, observe that find, the matching of the parallel a- and b-transitions depends on the appear in the runs to match. So, the systems are not hereditary HP the c transition dictates that we have to match a1 to a′1, and so a1.b1 backtracking condition requires that and b′are related. But from this Interdisciplinary research projects with industry www.itu.dk/research/models 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 2004-2011: Director of FIRST PhD School Management (Industrial PhD) 2014-17: Computational Artifacts: Design Oriented Theory of Computational Artifacts in Cooperati ve Work Practices (Velux, www.COMPART.ku.dk)
  3. 3. Agile Development of a Grant Application System September 1st, 2014 IT Supported Flexible Processes Process 3 IT UNIVERSITY OF COPENHAGEN In this article, we showed that PAISs support operational However, the focus is not on data but on process-related information ordering of activities). Process mining is also related to monitoring intelligence [41]. 8 Conclusion Process-aware information systems (PAISs) follow a characteristic 13 shows the four phases of such a life-cycle [7]. In the processes are (re)designed. In the configuration phase, designs by configuring a PAIS (e.g., a WFMS). After configuration, the starts where the operational business processes are executed using In the diagnosis phase, the operational processes are analyzed problems and to find things that can be improved. The focus of management (systems) is on the lower half of the life-cycle. is little support for the diagnosis phase. Moreover, support in limited to providing an editor while analysis and real design support Figure 13: PAIS life-cycle. enactment
  4. 4. Agile Development of a Grant Application System September 1st, 2014 Let us look at the process.. IT UNIVERSITY OF COPENHAGEN 4
  5. 5. Agile Development of a Grant Application System September 1st, 2014 Let us look at the process.. Only the “happy” path is described IT UNIVERSITY OF COPENHAGEN 4
  6. 6. Agile Development of a Grant Application System September 1st, 2014 Let us look at the process.. Only the “happy” path is described Other patient conditions or on-going treatments are IT UNIVERSITY OF COPENHAGEN not taken into account 4
  7. 7. Agile Development of a Grant Application System September 1st, 2014 Let us look at the process.. Only the “happy” path is described Other patient conditions or on-going treatments are IT UNIVERSITY OF COPENHAGEN not taken into account Only describes how not why 4
  8. 8. Agile Development of a Grant Application System September 1st, 2014 Let us look at the process.. Only the “happy” path is described Other patient conditions or on-going treatments are Typically introduces unnecessary dependencies IT UNIVERSITY OF COPENHAGEN not taken into account Only describes how not why 4
  9. 9. Agile Development of a Grant Application System September 1st, 2014 Model all routes? IT UNIVERSITY OF COPENHAGEN 5
  10. 10. Agile Development of a Grant Application System September 1st, 2014 Model all routes? A complex “Spaghetti” diagram - that still only describes how and not why IT UNIVERSITY OF COPENHAGEN 5
  11. 11. Agile Development of a Grant Application System September 1st, 2014 Model all routes? A complex “Spaghetti” diagram - that still only describes how and not why and describes only the anticipated events IT UNIVERSITY OF COPENHAGEN 5
  12. 12. Agile Development of a Grant Application System September 1st, 2014 Flexibility vs Support • Flexibility: ability to defer, change, 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) and deviate • support: provide analysis and guidance • unstructured: do what ever you want, but get no support • structured: support, but no IT UNIVERSITY OF COPENHAGEN Motivation Flexibility versus Support in workflows Classical trade-off between flexibility and support1 flexibility [1] W.M.P. van der Aalst et al. Declarative workflows: Balancing between flexibility and support 6 Sunday, March 14, 2010 Motivation Flexibility 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 Classical trade-off between flexibility and support1 flexibility [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] “Good standards for business process modelling are still missing and even today’s WFMSs are too rigid” Process-Aware Information Systems: Design, Enactment, and Analysis Wil M.P. van der Aalst Department of Mathematics and Computer Science, Eindhoven University of P.O. Box 513, NL-5600 MB Eindhoven, w.m.p.v.d.aalst@tue.nl Abstract. Process-aware information systems support operational business by combining advances in information technology with recent insights from management science. Workflow management systems are typical examples
  13. 13. Agile Development of a Grant Application System September 1st, 2014 AdapKve Case Management IT UNIVERSITY OF COPENHAGEN http://www.xpdl.org/nugen/WfMC p/adaptive-case-management/public.htm “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.” 7
  14. 14. Agile Development of a Grant Application System September 1st, 2014 AdapKve Case Management IT UNIVERSITY OF COPENHAGEN http://www.xpdl.org/nugen/WfMC p/adaptive-case-management/public.htm “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.” 7 from BPM
  15. 15. Agile Development of a Grant Application System September 1st, 2014 AdapKve Case Management IT UNIVERSITY OF COPENHAGEN http://www.xpdl.org/nugen/WfMC p/adaptive-case-management/public.htm “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 7 (record)
  16. 16. Agile Development of a Grant Application System September 1st, 2014 AdapKve Case Management IT UNIVERSITY OF COPENHAGEN http://www.xpdl.org/nugen/WfMC p/adaptive-case-management/public.htm “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 7 (record) Process “snippets” or “fragments”
  17. 17. Agile Development of a Grant Application System September 1st, 2014 What could we have done? IT UNIVERSITY OF COPENHAGEN 8
  18. 18. Physician Check Discharge Patient Agile Development of a Grant Application System September 1st, 2014 Events & Compliance Rules IT UNIVERSITY OF COPENHAGEN Surgery Report 9 Suite Surgical discharge letter for referring phys. Surgical Ward Nurse Patient Record Admit Patient Write Discharge Letter Create Make Lab Rest Provide Postsurgical Care Transport Patient to Ward Perform Surgery Prepare Patient Send Patient to 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 to the surgical suite. c2 After examining the patient a decision must be made. However, this must not be done before 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.
  19. 19. Physician Check Discharge Patient Agile Development of a Grant Application System September 1st, 2014 Events & Compliance Rules IT UNIVERSITY OF COPENHAGEN Surgery Report 10 Suite Surgical discharge letter for referring phys. Surgical Ward Nurse Patient Record Admit Patient Write Discharge Letter Create Make Lab Rest Provide Postsurgical Care Transport Patient to Ward Perform Surgery Prepare Patient Send Patient to 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 to the surgical suite. c2 After examining the patient a decision must be made. However, this must not be done before 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.
  20. 20. Agile Development of a Grant Application System September 1st, 2014 SimulaKon of Process IT UNIVERSITY OF COPENHAGEN 11
  21. 21. Agile Development of a Grant Application System September 1st, 2014 SimulaKon of Process IT UNIVERSITY OF COPENHAGEN 12
  22. 22. Agile Development of a Grant Application System September 1st, 2014 SimulaKon of Process IT UNIVERSITY OF COPENHAGEN 13
  23. 23. Agile Development of a Grant Application System September 1st, 2014 SimulaKon of Process IT UNIVERSITY OF COPENHAGEN 14
  24. 24. Agile Development of a Grant Application System September 1st, 2014 SimulaKon of Process IT UNIVERSITY OF COPENHAGEN 15
  25. 25. Agile Development of a Grant Application System September 1st, 2014 SimulaKon of Process IT UNIVERSITY OF COPENHAGEN 16
  26. 26. Agile Development of a Grant Application System September 1st, 2014 Agile to IT UNIVERSITY OF COPENHAGEN Live Development? • When to involve the users ? Requirement Specification Implementation Test Configure Go-Live 17
  27. 27. Agile Development of a Grant Application System September 1st, 2014 Agile to IT UNIVERSITY OF COPENHAGEN Live Development? • When to involve the users ? Requirement Specification Implementation Test Configure Go-Live 17 Chaos
  28. 28. Agile Development of a Grant Application System September 1st, 2014 Agile to IT UNIVERSITY OF COPENHAGEN Live Development? • When to involve the users ? Requirement Specification Implementation Test Configure Go-Live 17 Chaos Depression
  29. 29. Agile Development of a Grant Application System
  30. 30. Agile Development of a Grant Application System September 1st, 2014 CollaboraKve Modelling IT UNIVERSITY OF COPENHAGEN 19
  31. 31. Agile Development of a Grant Application System September 1st, 2014 AdapKve Case Management & DCR • A Case for Declara/ve Process Modelling: Agile Development of a Grant Applica/on System Flexibility is the default with S. Debois, M. Marquard & T. Slaats, Adap/veCM, 2014, Germany • 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 IT UNIVERSITY OF COPENHAGEN 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 Management with R. R. Mukkamala, M. Marquard & T. Slaats, Adap/veCM, 2013, Austria Hierarchical Declara/ve Modelling with Sub-­‐processes and Refinement with S. Debois & T. Slaats, BPM, 2013, The Netherlands
  32. 32. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research IT UNIVERSITY OF COPENHAGEN 21
  33. 33. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • How can we make ACM useful in practice? IT UNIVERSITY OF COPENHAGEN 21
  34. 34. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • How can we make ACM useful in practice? • (Live) Expert end-user co-development IT UNIVERSITY OF COPENHAGEN 21
  35. 35. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • How can we make ACM useful in practice? • (Live) Expert end-user co-development • Communication - with and between users IT UNIVERSITY OF COPENHAGEN 21
  36. 36. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • 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 21
  37. 37. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • 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 21
  38. 38. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • 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 IT UNIVERSITY OF COPENHAGEN 21 with external systems
  39. 39. Agile Development of a Grant Application System September 1st, 2014 Ongoing Research • 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 IT UNIVERSITY OF COPENHAGEN 21 with external systems • Case studies
  40. 40. Agile Development of a Grant Application System September 1st, 2014 Flow-­‐chart based guidance.... IT UNIVERSITY OF COPENHAGEN 22
  41. 41. Agile Development of a Grant Application System September 1st, 2014 Constraint based guidance IT UNIVERSITY OF COPENHAGEN 23

×