Enabling Flexibility in Process-aware Information Systems - Fing

Enabling Flexibility in Process-aware Information Systems Challenges, Methods, Technologies

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

Content

 Keynote based on new Springer

book Enabling Flexibility in Process-Aware Information Systems

Content  Part 1 – Process-aware Information Systems  Part 2 – Flexibility Issues  Part 3– Flexibility Support for Pre-specified Process Models  Pre-specified process models and flexibility-by-design  Process configuration  Handling of anticipated exceptions  Handling unforeseen exceptions with Ad-hoc Changes  Process Evolution  Process Monitoring, Mining & Analysis  Business Process Compliance 3

Content  Part 4– Loosely-specified Process Models  Concretizing Loosely-specified process models  Constraint-based process models  User and Data Driven Processes  A Framework for Object-Aware Processes

4

Business Processes and Workflows Part 1 - Process-aware Information Systems

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

5

A Retail Process

Welcome customer

Offer Clothes

Bill Clothes

Hand over clothes

Mendling 2006 6

Business Process Lifecycle Evaluation:

Evaluation Design: Enactment: Operation Monitoring Maintenance

Enactment

Administration and Stakeholders

Design & Analysis

Business Process Identification and Modeling

Analysis: Configuration

Validation Simulation Verification

M. Weske: Business Process Management, © Springer-Verlag Berlin Heidelberg 2007

Process Mining Business Activity Monitoring

Configuration: System Selection Implementation Test and Deployment

Fig 1.5. Business process lifecycle

7

BPM Value Proposition Lower

BPM adoption maturity

Higher

Process Optimization

Transformation Process monitoring

Business insight

Value to shareholders and competitiveness

Higher

Compliance & consistency IT agility

Process execution

Efficiency Knowledge

Lower

Process modeling

Workers, supervisors, and managers CIO CFO CXO Customers and partners Stakeholders

CEO Forester 2007 BPM Market Overview

8

Process-aware Information System Process Composer

Process-aware Information System (PAIS)

Process Repository

Create Process Schema Modify Process Schema Check Process Schema …

Late Modeling Web Clnt API Admin. API Validatíon

Modeling API Authorization

Msg Queuing

Audit Trail

Exceptions

Dyn. Change API Time Mgmt ...

Process Execution Engine Application Components

Instance 4 Instance 3 Instance 2 Instance 1

Process Models

Instance 6 Instance 5

Instance 11 Instance 10 Instance 9 Instance 8 Instance 7

Instance 14 Instance 13 Instance 12

Anwendungen / Application Server

...

Process Engineer

Users

9

Simple Process Model

Process Model S Patient Admission

Anamnesis & Clinical Examination clinicalSuspicionOf CruciateRupture = „Yes“

Non Operative Therapy

x

X-ray

+

MRT

Activity

x

XOR-Split/Join

+

AND-Split/Join

Sonography

x

Non Operative Therapy 1

+

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Operative Treatment

cruciateRupture = „Yes“ and operationIndicated = „Yes“

10

Built-time versus Run-time - Process Type versus Process Instance Level -

11

Business Process – System Perspective Process Schema S Patient Admission

Non Operative Therapy

Anamnesis & Clinical Examination clinicalSuspicionOf CruciateRupture = „Yes“

x

X-ray

+

Non Operative Therapy 1

+

MRT

x

Activity

x

XOR-Split/Join

+

AND-Split/Join

x

Process Instance I2  



+

+ x

x x

Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>

Activity States:

Operative Treatment

cruciateRupture = „Yes“ and operationIndicated = „Yes“

 

Discharge & Documentation

x Initial Treatment & Operation Planning

Sonography

Process Instance I1 

x

Enabled

 Completed





x

  x x x +  +   

Execution Trace: σ2 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „Non Operative Therapy“>

Skipped

12

User Perspective and Work item Lifecycle MRT

MRT

Patient  Admission

Anamnesis &  Clinical Examination

Peter

Joe

Process Instance I5

Non Operative Therapy



x

X-ray

+



Non Operative Therapy 1

+

MRT



Sonography

Offered Offered

Allocated Allocated

x

Started Started

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Operative Treatment

Completed Completed

Withdrawn Withdrawn

13

Let‘s do the MRT

User Perspective MRT

MRT

Patient  Admission

Anamnesis &  Clinical Examination

Peter

Joe

Process Instance I5

Non Operative Therapy



x

X-ray

+



Non Operative Therapy 1

+

MRT



Sonography

Offered Offered

Allocated Allocated

x

Started Started

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Operative Treatment

Completed Completed

Withdrawn Withdrawn

14

User Perspective

Patient  Admission

Anamnesis &  Clinical Examination

Peter

Joe

Process Instance I5

Non Operative Therapy



x

X-ray

+



Non Operative Therapy 1

+

MRT



Sonography

Offered Offered

Allocated Allocated

x

Started Started

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Operative Treatment

Completed Completed

Withdrawn Withdrawn

15

User Perspective

Patient  Admission

Anamnesis &  Clinical Examination

Peter

Joe

Process Instance I5

Non Operative Therapy



x

+

X-ray



MRT



Non Operative Therapy 1

+



Sonography

Offered Offered

Allocated Allocated

x

Started Started

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Operative Treatment

Completed Completed

Withdrawn Withdrawn

16

User Perspective Initial

Initial

Patient  Admission

Anamnesis &  Clinical Examination

Peter

Joe

Process Instance I5

Non Operative Therapy



x

+

X-ray



MRT

 

Sonography

Offered Offered Withdrawn Withdrawn

x

Non Operative Therapy 1

 +

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Allocated Allocated

Started Started

Operative Treatment

Completed Completed

17

Business Processes and Workflows Part 2 - Flexibility Issues

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

18

Process Spectrum

Processes on the right side of the spectrum are mostly knowledge-intensive  Unpredictability: Course of action depends on situation-specific parameters  Non-repeatability: Two process instances hardly look the same  Emergence: Future course of action depends on knowledge gained through activity execution 19

Variability  Variability is typical for many domains and requires that

processes are handled differently depending on the particular context

 Drivers  Product and service variability  Differences in regulations  Different customer groups  Temporal differences

20

Example: Handling Medical Examinations 21

Variety of related variants • Same business

objective • Commonalities • Differences due

to varying application context

(c) 2012 Barbara Weber, Manfred Reichert

Adaptation  Ability to adapt the process and its structure to

temporary events

 Drivers  Special Situations  Exceptions  Anticipation of Adaptation  Planned  Unanticipated 22

Evolution  Ability of the implemented process to change when the

business process evolves  Drivers

represented in

External

Internal

Changing Business Context Design Errors

Changing Technological Context Changing Legal Context

Real-world Process

PAIS

Technical Problems Poor Internal Quality

Organizational Learning

provide feedback to 23

Example: Tender Preparation

Evolution  Extent of Evolution  Incremental  Continuous Process Improvement  Revolutionary  Business Process Reengineering  Duration  Temporary  Permanent

25

Evolution  Swiftness  Deferred  Ongoing instances are not affected  Immediate  Ongoing instances are affected

 Visibility  Observable Behavior  Internal Structure 26

Looseness  Knowledge-intensive processes cannot be fully pre-

specified, but require loose specifications

 Drivers  Unpredictability  Non-Repeatability  Emergence

27

Flexibility Issues along the Process Lifecycle Traditional Process Lifecycle Support

 

Schema S‘:

B

Schema S: C

x

A

x D

A

Need for Process Evolution

Process Monitoring

Instance I1 Instance I1B Instance I1 B A

x

A A

x

E

Need for Variability Support

Need for Looseness of Process Specifications

Create Instances

 Execution Log

C D

 Process engineer / Process administrator

Bx

x

C B x E C x E C E x  x D D D

Process Execution

Need for Process Adaptation (Support for Planned and Unplanned Exceptions / Special Cases)

 Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4

Process participant

28

Flexibility Needs and Technological Requirements

Flexibility Need

Dimension

Technological Requirement

Variability

Configuration

Looseness

Loosely-specified processes

Adaptation

Planned Unplanned

Exception Handling Ad-hoc Changes

Evolution

Deferred Evolution Immediate Evolution Poor Internal Quality Organizational Learning

Versioning Process Instance Migration Refactoring Monitoring, Analysis and Mining

29

Business Processes and Workflows

Pre-specified Process Models and Flexibility by Design

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

30

Basic Control Flow Concepts – Activities

Atomic Activities

Automated

Human

Web services, Java applications, database function

Electronic forms

Complex Activities Refer to sub-process models 31

Basic Control Flow Concepts  Control Connectors (i.e., Gateways)  (X)OR-Split / (X)OR-Join  AND-Split / AND-Join  Control Flow Edges  Sequence Flow  Default Path  Transition Conditions

32

Basic Control Flow Concepts - Example Transition Conditions

Atomic Activity

Sequence Flow

XOR Gateway

Default Path

AND Gateway 33

Basic Data Flow Concepts  Data objects + Data edges  Data objects can be linked to  activities via data edges Read access  Write access 

 

referenced by transition conditions attached to outgoing messages

34

Basic Data Flow Concepts - Example Data Edge – Write Access

Data Object

Data Edge – Read Access

Transition Condition references SparePartsList

35

Examples of Control Flow Patterns (1)

For an overview of patterns visit: http://www.workflowpatterns.org

36

Examples of Control Flow Patterns (2)

37

Expressiveness and Flexibility by Design

38

(Missing) Expressiveness and Flexibility by Design

Flexibility by Design

39

Evaluation of Existing PAISs

Business Processes and Workflows Process Configuration

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

41

Business Processes and Workflows Exception and Compensation Handling

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

42

Process Adaptations

Planned

Unplanned

Exception Handling

Ad-hoc Changes

43

Exception Handling in PAIS Sources for Exceptions Activity Failure Technical

Semantical

Upon detection of a particular exception

Resource Unavailability

Constraint Violations

Trying Alternatives Ordered

Unordered

Add Behavior Deferred Immediate Fixing Fixing ExceptionRetry driven Rework

Deadline Expiry

Inconsistence real-world / PAIS

Exception Handler

Cancelling Behavior a suitable handler is chosen

Reject

Compensate

Resource Patterns Delegate

Escalate

… 44

Exception Handling Patterns - Immediate Fixing -

45

Exception Handling Patterns - Deferred Fixing -

46

Exception Handling Patterns - Reject -

47

Exception Handling Patterns - Compensate -

48

Compensation Handling - Sagas 49

Abort!

The SAGAS concept normal processing

B

A Commit

C Commit

D Commit

Compensation Information

Ac

Bc

Cc

System Log

Abort Transaction (Rollback Work)

ready!

Compensation of A

Compensation of B

Compensation of C

Rollback

[GaSa87]

Compensation Spheres

50

Compensation Spheres

51

Compensation and Fault Handling in BPEL (1) 52

Scopes provide a context which influences the execution behavior of its enclosed activities

process

Local declarations: partner links, message exchanges, variables, correlation sets

scope scope

Local handlers: event handlers, fault handlers, a termination handler, and a compensation handler Isolated scopes provide control of concurrent access to shared resources

scope

scope

primary activity scope

scope

scope

scope scope

Termination handler to deal with forced scope termination (external faults) Compensation handler to undo persisted effects of already completed activities

52

Compensation and Fault Handling in BPEL (2) 53 process scope compensation handler

5. Propagate compensation

invoke

fault handler compensate

compensate

3. The fault triggers the process-level fault handler

compensation handler invoke

4. Compensate previous work

compensation handler

6. Undo work (in reverse order)

invoke

invoke 1. Do some work (successfully invoke two services)

invoke 2. Invoke another service (throws fault)

 This example shows the default compensation behavior supported by BPEL; i.e., a completed scope is compensated by invoking the compensation handlers of its constituting activities in reverse order. How-ver, a more specific compensation handler for a scope may be provided as well (e.g., only com-pensating some of 53 the already completed activities or invoking a specific process dealing with the exception).

Resource Patterns  Exception Handling Patterns (like Deferred Fixing, Reject

etc.) focus on behavioral changes

 Many exceptions (e.g., resource unavailability or deadline

expiry) require changes regarding resource perspective like delegation, escalation or reallocation

54

Resource Patterns

55

Selected Resource Patterns

For more details visit: http://www.workflowpatterns.org

56

Flexible Handling of Work Items  Application of Exception Handling patterns often

requires changes to the lifecycle of work items.

 Work items may have to be  Skipped  Redone  Done ahead of time  Canceled  Suspended/Resumed

57

Flexible Handling of Work items

58

Flexible Handling of Workitems

For more details visit: http://www.workflowpatterns.org

59

Business Processes and Workflows Handling Unforeseen Exceptions

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

60

Process Adaptations

Planned

Unplanned

Exception Handling

Ad-hoc Changes

61

User View on an Ad-hoc Process Change 62

Examinations

Examination

Start

Exception – We need an additional lab test !

U Wallace, Edgar U Miller, Anne

Check Check Anesthesiology Anesthesiology

U Smith, Karl

Lab Test X-Ray

U Jones, Isabelle Explanation Operation Risks

End

62

Behavioral Changes Require Structural Process Model Adaptations

63

Behavioral Changes Require Adaptations of the Process Instance State

64

Behavioral Changes Require Adaptations of the Process Instance State

65

Behavioral Changes Must not Violate Process Model Soundness and Proper Instance Execution Data flow error caused by missing data

No Proper Completion ensured. End node can be reached since B is still enabled

66

Ad-hoc Changes of a Process Instance Must Not Affect any Other Process Instances 67

Process Type Level Process Schema S Patient Admission

Non Operative Therapy

Anamnesis & Clinical Examination clinicalSuspicionOf CruciateRupture = „Yes“

x

x

X-ray

+

MRT

Non Operative Therapy 1

+

x

x

Activity

x

XOR-Split/Join

+

AND-Split/Join

Discharge & Documentation

Initial Treatment & Operation Planning

Sonography

Operative Treatment

cruciateRupture = „Yes“ and operationIndicated = „Yes“

Process Instance Level Process Instance I1

Process Instance I2

 



x





+

+

x

x

x

Execution Trace: σ1 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „X-ray“>

x +

+ x

x

x

Execution Trace: σ2 = < „Patient Admission“>

67

Structurally Adapting Pre-Specified Process Models 68

Change Primitives     

Add node Remove node Add edge Remove edge Move edge

High-Level Change Operations  

Combines a set of change primitives Referred to as Adaptation Patterns in the following

68

Adaptation Patterns

69

Adaptation Patterns versus Change Primitives

70

Adaptation Patterns versus Change Primitives

Change Primitives

Process Adaptation Patterns

Operate on single elements of process schema

Provide high-level change operations

Correctness has to be checked after adaptation

Correctness-by-construction

No Assumption regarding structure of process schema

Process schema needs to be blockstructured

71

Dynamic Change Bug

72

Correctness of Process Instance Changes 73

Ensuring Dynamic Correctness activated step

Schema S‘:

Schema S:

invoice





C

A

B



make invoice

E

F

D

A

send invoice

C

E

B

F

D

May the depicted schema change be propagated to the process instance? Need for general correctness criterion State Compliance [ReDa98, RRW08a, RRD04a, RRD04b] 73

Correctness of Process Instance Changes 74

Ensuring Dynamic Correctness activated step

Schema S‘:

Schema S:

invoice





C

A

B



make invoice

E

A

E

B

F

D

D

, ,

F

send invoice

C

 Trace reproducible on new schema?

More complicated: loop backs

Further challenges:

- How to efficiently check for compliance? - How to efficiently migrate process instances?

[RRD04a, RRD04b] 74

Correctness of Process Instance Changes 75 Process Type Level Process Schema S Patient Admission

Non Operative Therapy

Anamnesis & Clinical Examination

x

clinicalSuspicionOf CruciateRupture = „Yes“

x

X-ray

+

MRT

Non Operative Therapy 1

+

Activity

x

XOR-Split/Join

+

AND-Split/Join

Sonography

x

Discharge & Documentation

x Initial Treatment & Operation Planning

Operative Treatment

cruciateRupture = „Yes“ and operationIndicated = „Yes“

Process Instance Level Process Instance I3 



x

 

+

 

+

x





x

x

Execution Trace: σ3 = < „Patient Admission“, „Anamnesis & Clinical Examination“, „MRT“, „X-ray“, „Sonography“>

I3 is not state compliant with change Delete (I3, MRT)

75

Handling Planned and Unplanned Exceptions with AristaFlow BPM Suite  Example: Order Handling Process

Handling Planned and Unplanned Exceptions with AristaFlow BPM Suite

Handling Planned and Unplanned Exceptions with AristaFlow BPM Suite

Handling Planned and Unplanned Exceptions with AristaFlow BPM Suite

Business Processes and Workflows Process Monitoring, Analysis and Mining

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

80

C) Execution Log Entries of Process Instance 4711

A) Process Model Process Model S 3 1

x

2

4

+

clinicalSuspicionOf CruciateRupture = „Yes“

7

x

+ x

5 6

9

8

x

10

XOR-Join1

cruciateRupture = „Yes“ and operationIndicated = „Yes“

7: Non Operative Therapy 1 1: Patient Admission 2: Anamnesis & Clinical Examination 8: Initial Treatment & Operation Planning 3: Non Operative Therapy 9: Operative Therapy 4: X-Ray 10: Discharge & Documentation 5: MRT 6: Sonography

B) Process Instances Process Instance 4711 on S Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1) Insert(S, Puncture, Follow-up Examination, XORJoin 1) 

x





+ x

+ 







x

x

Running

User

Timestamp

Patient Admission

Start

Garry

2007/09/08 15:30

Patient Admission

Complete

Garry

2007/09/08 15:45

Anamnesis & Clinical Examination

Start

Helen

2007/09/09 11:00

Anamnesis & Clinical Examination

Complete

Helen

2007/09/09 11:45

X-Ray

Start

Paula

2007/09/09 12:34

Sonography

Start

Sandy

2007/09/09 13:20

X-Ray

Complete

Paula

2007/09/09 14:00

Sonography

Complete

Sandy

2007/09/09 14:30

Non Operative Therapy 1

Start

Peter

2007/09/10 09:10

Non Operative Therapy 1

Complete

Peter

2007/09/10 09:45

Follow-up Examination

Start

Helen

2007/09/12 11:07

Follow-up Examination

Complete

Helen

2007/09/12 11:20

Puncture

Start

Helen

2007/09/12 11:21

 Completed

Change TX

Applied Changes

User

Timestamp

001

Delete (S, MRT)

Paula

2007/09/09 12:50

002

Insert(S, Follow-up Examination, Non Operative Therapy, XOR-Join 1)

Helen

2007/09/10 09:00

002

Insert(S, Puncture, Follow-up Examination, XOR-Join 1)

Helen

2007/09/10 09:00

XOR-Join1

Delete (S,MRT)

Activity States:

Event

D) Change Log Entries of Process Instance 4711

 

Activity



Skipped

Process Instance 4711 2007/09/09 10:30 3 1 

2

x

7 82

4

Restoring Structure and State from Execution and Change Log

+

+

5

x

x 9

8

6

x

10

XOR-Join1

Process Instance 4711 2007/09/09 12:51 3 1 

2 



x 4

+

7

+

5

x

x 9

8

6

x

10

XOR-Join1

Process Instance 4711 2007/09/10 09:46 3 1



2



 11: Follow-up Examination 12: Puncture

x 4

+

 +

5 6

7





11

12

x

x 8

9

x XOR-Join1

10

82

Mining Execution Logs  Process Discovery  Presumes the presence of an event log and extracts information from such a log (e.g., process model, social network)  Conformance checking  Analyzes whether or not the process instances in the log follow prescribed behavior of rules  Extension algorithms  Enhance the process model based on information from the execution log (e.g., decision mining)

For more details see processmining.org 83

What can Process Mining be used for? supports/ controls

information system

operational process

records refers to

models

configures

process discovery

(un)desired properties

process models

conformance testing

log-based verification

event logs Processmining.org 84

Process Discovery using Heuristic Miner

85

Process Discovery using Heuristic Miner

86

Conformance Checking

87

LTL Checker

88

Business Processes and Workflows Process Evolution

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

89

Evolution  Drivers represented in External

Internal

Changing Business Context Design Errors

Changing Technological Context Changing Legal Context

Real-world Process

PAIS

Technical Problems Poor Internal Quality

Organizational Learning

provide feedback to

90

Schema Evolution 91

91

Change Support Features

Schema Evolution, Version Control and Instance Migration 92

 Schema Evolution  Changes at the process type level  How to deal with running instances when adapting the

original process schema?   

Scenario 1: No version control Scenario 2: Co-existence of instances of old / new schema Scenario 3: Change propagation and instance migration

92

Scenario 1 - No Version Control 93

 Schema is overwritten and instances are migrated Type change overwrites schema S Process Schema S

Insert X between A and B Insert Y between C and AND-Join1

C A

+

+

B

AND-Split1

E

Process Schema S’ C A

F

X

AND-Join1

D

C +

+

B

E

A

F

X

B

A

B

+ D

+

E

F

+

E

F

Process Instance I2

C +

Y

D

Process Instance I2 

F

AND-Join1

+

D



D

E

Process Instance I1

C A

+

+

AND-Split1

Schema Evolution

Process Instance I1

B

Y

E

F

Change is propagated to all running process instances

 A

X

 B

C +

Y Inconsistent state

D

93

Scenario 2 - Version Control 94

 Co-existence of instances of different schema versions Type change results into a new version of schema S Process Schema S

Insert X between A and B Insert Y between C and AND-Join1

C A

B

+

+

AND-Split1

E

C A

F

AND-Join1

D

Process Schema S’ X

Schema Evolution

B

Y +

+

AND-Split1

D

E

F

AND-Join1

Old instances remain with schema S Instances created from S (before schema evolution)

Process Instance I1

Process Instance I4

C A

B

+

+

Instances created from S’ (after schema evolution)

E

F

 A

 X

 B

C +

D

A

+

+ D

E

F

+

E

F

Process Instance I5

C

 B

+ D

Process Instance I2 

Y

E

F

 A

 X

C B

+

Y

D

94

Scenario 3 – Instance Migration 95

 Compliant instances are migrated to the new schema Type change results into a new version of schema S Process Schema S

Insert X between A and B Insert Y between C and AND-Join1

C A

+

+

B

AND-Split1

E

Process Schema S‘ C A

F

X

AND-Join1

D

B

+

+

AND-Split1

Schema Evolution

Y

D

E

F

AND-Join1

Migration of compliant process instances to S’ Process Instance I1

Process Instance I1 C

C A

+

+

B

E

A

F

Process Instance I2 A

C

 B

+

+

B

+

+

E

F

D

D



X

Y

E

F

Propagation of compliant process instances to schema S’ (incl. state adaptations)

Process Instance I2 not compliant with S’

D

95

Business Processes and Workflows Business Process Compliance

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

96

Motivation

Process correct?

Syntax?

Soundness?

Motivation

Process correct?

§ 3 is violated!

Business Processes and Workflows Summary

M O N T E V I D E O , D E C E M B E R 1 1 TH 2 0 1 2

PRESENTED BY BARBARA WEBER UNIV. OF INNSBRUCK

99

Integrated Lifecycle Support for Adaptive and Dynamic Processes (1) 100



Traditional Process Lifecycle Support



Schema S‘:

B

Schema S: C

B

x D

C

x

A A

x E

x

Create Instances

D

 

Process engineer / Process administrator

Execution Log

A

Process Monitoring

Process Execution

Instance I1 Instance I1 B Instance I1  B x A A

C

x

B

C x  C D D D

x

E x x

 Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4

E E

Process participant

100

Integrated Lifecycle Support for Adaptive and Dynamic Processes (2) 101

Lifecycle Support in adaptive PAISs

 

Schema S‘:

B

Schema S: C

B

x D

C

x

A A

x E

x

 

Process engineer / Process administrator

Execution Log

Instance I1 Instance I1 B Instance I1  B A

Process Monitoring

x A A

Change Log



Change Propagation

Create Instances

D

B C x E  C E x x E x  C x D D D

Exception: Delete (I1, E)

Process Execution

Instancespecific Change

 Arbeitsliste Tätigkeit 1 Tätigkeit 2 Tätigkeit 3 Tätigkeit 4



Process participant

101

Summary  Increasing adoption of PAISs to support business

processes at an operational level

 Effective business process support imposes several

different flexibility needs 

Adaptation, Evolution, Variability, and Looseness

 Flexibility needs partially supported by existing

commercial systems

Summary  Increasing adoption of PAISs to support business

processes at an operational level

 Effective business process support imposes several

different flexibility needs    

Adaptation Evolution Variability Looseness

Summary  Adaptation support through  Exception handling (preplanned exceptions)  Ad-hoc changes (unforeseen changes)  Evolution support through  Versioning of process models  Instance migration  Variability support through  Process Configuration

Summary  Looseness requires different paradigms for representing

business processes  

Constraint-based process models Data-centric / Object-aware process models

Thank you for your attention !

For more information visit our website http://bpm.q-e.at/, our facebook page www.facebook.com/bpmqe , follow bpm_qe on twitter, or send an email to [email protected]