Important issues for the future Adaptive and interorganizational workflows

1. Eindhoven University of Technology Faculty of Technology Management Department of Information and Technology P.O. Box 513 5600 MB Eindhoven The Netherlands w.m.p.v.d.aalst@tm.tue.nl Important issues for the futureAdaptive and interorganizational workflows Wil van der Aalst

2. Adaptive workflow • Workflows are subject to change. • Expected exceptions can be handled in a predefined manner. However, this is very expensive! • Unexpected exceptions cannot be handled using predefined mechanisms. • Therefore it is important to consider workflows that adapt.

3. structured (production) workflow adaptive workflow groupware unstructured process centric information centric J freedom, flexibility L no support, no control, no MI J support, control, MI L limited freedom, no flexibility

4. Workflow Management resource dimension activity = case + task + resource resource change task process dimension case work item = case + task case dimension Focus on process dimension and the interplay between cases and processes in the fourth dimension.

5. Changes: type, scope, and time entry time individual ad-hoc on-the-fly extend replace changes restart re-order structural proceed evolutionary transfer scope type time

6. Individual changes • Just one case is affected (ad-hoc change) • Each case has a private process or change description Time of change: • entry time • the process is fixed the moment the case starts • on-the-fly • the process may change during the execution of the case

7. Structural changes • Evolution: all future cases are affected (in principle) • Cases share a common process description What to do with existing cases? • backward recovery • all cases are aborted and restarted • forward recovery • abort and handle outside system • proceed (versions) • old cases are handled the old way • new cases are handled the new way • transfer (dynamic change) • old cases are moved to the new process • not always possible!

8. Problem 1: Correctness Two types of correctness notions: • syntactic • connectedness, termination, absence of livelock and deadlock • does not depend on the contents of tasks • soundness property • semantic • contents of tasks is considered • performance: time and quality • conformance to: • specification • template • old process • using notions of structure, (bi)simulation, inheritance, observable behavior

9. Correctness (2) Another criterion to classify errors: • transient • does not affect new cases • will disappear by ad-hoc problem solving • can be very expensive • permanent • affects all new cases • will not disappear by itself • can be very expensive # t # t

10. Errors resulting from change syntactic semantic   transient   permanent • Typically, standard verification techniques only work for syntactic & permanent errors! • Today’s workflow management systems do no support verification at all!

11. Permanent/syntactic error

12. Transient/semantic problem

13. Dynamic change problem • Structural change with case transfer • Transfer of cases is not always possible • See: [Ellis/Keddara/Rozenberg9], [Ellis/Keddara/Wainer98], [Agostini/Michelis98], [Voorhoeve/Aalst97], [Aalst/Basten/ .. 99].

14. Problem 2: Management information • In a workflow management system there are often multiple versions of one process. • In case of evolutionary change there are only a few versions but in case of frequent ad-hoc changes thousands of versions (compare with variant BOM) may coexist. • There is a need for aggregation: mapping all variants onto one process for a concise view on the workflow, I.e. a greatest common divisor or least common multiple! • There is a need for abstraction: abstracting from details of the process(es) but still insight in future developments.

16. Interorganizational workflow • E-commerce and virtual/extended enterprise result in interorganizational workflows • Coordination/collaboration versus autonomy • Frequent, distributed, and dynamic changes

17. Example

18. Example(contd.) public workflow

19. Example(contd.) partitioned workflow

20. private workflow of the contractor Example(contd.) A causal relation is added between process_cost_statement and create_specification. From a local perspective this seem harmless. However, the resulting IOWF deadlocks!

21. Example(contd.) private workflow of the contractor An alternative design in harmony with the public workflow.

22. Example(contd.) private workflow of the subcontractor The alternative procedure (procedure_2) may seem harmless from a local perspective. However, the external behavior changes!

23. Example(contd.) private workflow of the subcontractor An alternative design in harmony with the public workflow.

24. overall workflow Example(contd.) Combining the two original (i.e., incorrect) private workflows results in an overall workflow with potential deadlocks and a behavior different as agreed in the public workflow .

25. overall workflow

26. Case study: E-bookstore • The processing of customer orders. • Four domains: • customer, • bookstore, • publisher, • and shipper.

27. Step 1 public workflow

28. Step 2 partitioned workflow

29. Step 2(contd.)

30. Step 2(contd.)

31. Step 2(contd.)

32. Step 2(contd.)

33. Step 3 private workflow

34. Step 3(contd.) private workflow

35. Step 3(contd.) private workflow

36. The overall workflow is sound and a subclass of the public workflow!