Index of /rozprawy2/11477

Pełen tekst

(1)AGH University of Science and Technology in Krakow Faculty of Electrical Engineering, Automatics, Computer Science and Biomedical Engineering. P H D D ISSERTATION. B USINESS P ROCESS C OMPOSITION . P LANNING WITH C ONSTRAINTS. AUTHOR : Piotr Wi´sniewski. S UPERVISOR : Prof. Antoni Lig˛eza. AUXILIARY S UPERVISOR : Krzysztof Kluza, PhD. Kraków 2019.

(2) ii. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(3) Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Wydział Elektrotechniki, Automatyki, Informatyki i In˙zynierii Biomedycznej. ROZPRAWA D OKTORSKA. S YNTEZA PROCESÓW BIZNESOWYCH . P LANOWANIE Z OGRANICZENIAMI. AUTOR : Piotr Wi´sniewski. P ROMOTOR : prof. dr hab. inz˙ . Antoni Lig˛eza. P ROMOTOR POMOCNICZY: dr inz˙ . Krzysztof Kluza. Kraków 2019.

(4) iv. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(5) v. Dla Taty. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(6) vi. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(7) Podzi˛ekowania Chciałbym bardzo serdecznie podzi˛ekować wszystkim, którzy w jakikolwiek sposób przyczynili si˛e do powstania tej pracy. W pierwszej kolejno´sci dzi˛ekuj˛e moim kochanym Rodzicom, za to, z˙ e od ponad c´ wierć wieku konsekwentnie wspieraja˛ kaz˙ da,˛ nawet najdziwniejsza˛ form˛e mojej edukacji. Dzi˛ekuj˛e takz˙ e moim Promotorom, bez których zaangaz˙ owania ta praca nie byłaby w stanie osiagn ˛ a´ ˛c obecnego poziomu. Profesorowi Antoniemu Lig˛ezie, za jego niezliczone cenne rady i uwagi oraz nieustanne motywowanie do dalszej pracy, a takz˙ e Dziekanowi Krzysztofowi Kluzie, za blisko cztery lata owocnej współpracy i za to, z˙ e w tym czasie stał si˛e przyjacielem, na którego moz˙ na liczyć w kaz˙ dej sytuacji. W tym miejscu nalez˙ y równiez˙ wspomnieć o promotorach moich prac dyplomowych na studiach: Profesorze Marku Ogieli, który był takz˙ e moim pierwszym opiekunem naukowym oraz o Profesorze Adamie Korytowskim, który poprzez prac˛e inz˙ ynierska˛ przekazał mi wiele cennych rad dotyczacych ˛ pisania tekstów naukowych. Dzi˛ekuj˛e równiez˙ wszystkim moim współpracownikom z AGH, którzy wspierali mnie podczas pisania tej pracy, w tym w szczególno´sci: Profesorowi Marcinowi Szpyrce, Doktorowi2 Krystianowi Jobczykowi, Doktor Edy´ z˙ ynskiemu. Nie mógłbym tez˙ zapomnieć o studentach, których na zaj˛eciach cie Kucharskiej oraz Mateuszowi Sla spotkałem juz˙ ponad dwie setki oraz o Kolez˙ ankach i Kolegach z Wydziałowej Rady Samorzadu ˛ Studentów. Dzi˛ekuj˛e Wam za udana˛ współprac˛e, w tym ciekawe dyskusje oraz moz˙ liwo´sc´ poznania ludzi o wielu zainteresowaniach i talentach. Chciałbym takz˙ e podzi˛ekować moim współpracownikom z Dassault Systèmes, w tym moim szefom: Karolinie, Darkowi, Kamilowi i Lesławowi za ich wyrozumiało´sc´ dla pracownika-doktoranta, a takz˙ e mojemu pierwszemu zespołowi projektowemu w składzie: Bogu´s, Bartek, Marysia, Edyta i Krzysiek, za ich wsparcie i s´wietna˛ atmosfer˛e w pracy. Dzi˛ekuj˛e równiez˙ pracownikom firmy Comef, zwłaszcza Bogusławowi i Michałowi, za ich cenne doktorskie rady i trzymanie za mnie kciuków. Na koniec, choć z nie mniejsza˛ siła,˛ chciałbym podzi˛ekować Kasi, która w ciagu ˛ ostatnich trzech tygodni dostarczyła mi niesamowitej ilo´sci pozytywnej energii i motywacji do pracy. Dzi˛ekuj˛e tez˙ wszystkim moim Przyjaciołom, a zwłaszcza: Annie-Marii, za jej szczere rady i uwagi j˛ezykowe, Arturowi, za niezliczone dyskusje w róz˙ nych miejscach na mapie Europy, Kamilowi, za dawanie przykładu naukowca z pasja,˛ Kubie, za jego wsparcie i pytania "jak tam twój doktorat?", a takz˙ e Pawłowi, za wszystkie wieczorne rozmowy w krakowskim mieszkaniu.. Kraków, 14 marca 2019 r.. vii.

(8) viii. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(9) Abstract One of the major tasks of Business Process Management is the design of process models, which often precedes the implementation and execution of a workflow. Since this activity usually involves multiple participants, a significant amount of project time may be consumed for the acquisition and generation of the final model. Taking this into account, the goal of this thesis is to develop an efficient method of business process modeling by using a planning-related approach based on Constraint Programming and to generate process models compliant with the BPMN standard based on an unordered list of tasks. This dissertation presents a novel participant-oriented approach to business process modeling. According to the main principle of the presented method, a set of semi-formal activity descriptions is used to form a declarative specification of the modeled process. Such a specification, along with a list of predefined constraints, is used to generate a set of admissible execution plans. At the final step of the method, a correct BPMN model in an interchangeable format is generated using a graph-based model construction algorithm. In contrast to the existing automated process modeling approaches, the method presented in this thesis does not require the process designer to specify activity ordering relations in an explicit way. Instead, each of the process participants contributes to workflow modeling by defining their tasks along with their prerequisites and outcomes. In addition, in this approach, the knowledge of particular modeling languages or practices is not required to compose process models. Another advantage of the proposed approach is the phase-based methodology of model generation. Such a solution provides a higher level of modeling flexibility and the ability to control the modeling at different levels of completion. The comparative evaluation of the implemented methods shows that the proposed solution is convenient for users and can generate prototype BPMN models which cover nearly 70% of business examples. Moreover, the presented model construction algorithm is proven to support the creation of process diagrams with complex flow structures.. ix.

(10) x. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(11) Streszczenie Jednym z głównych zadań zarzadzania ˛ procesami biznesowymi jest projektowanie modeli procesów, które zwykle nast˛epuje przed ich implementacja˛ i uruchomieniem. Modelowanie zwykle wymaga współudziału róz˙ nych uczestników procesu, co sprawia, z˙ e znaczna cz˛esć´ czasu realizacji projektu jest przeznaczana na utworzenie odpowiedniego modelu. Celem rozprawy jest opracowanie metody efektywnego modelowania procesów biznesowych poprzez wykorzystanie podej´scia opartego na automatycznym planowaniu i programowaniu z ograniczeniami, a takz˙ e generowanie modeli procesów zgodnych ze standardem BPMN na podstawie nieuporzadkowanej ˛ listy zadań. W rozprawie przedstawiono nowe podej´scie do modelowania procesów biznesowych zorientowane na uczestnika procesu. Zgodnie z główna˛ zasada˛ prezentowanej metody zbiór cz˛esćiowo sformalizowanych opisów aktywno´sci jest wykorzystywany do utworzenia deklaratywnej specyfikacji modelowanego procesu. Najpierw tego rodzaju specyfikacja, wraz z lista˛ predefiniowanych ograniczeń, słuz˙ y do wygenerowania dopuszczalnych planów wykonania procesu. Nast˛epnie za pomoca˛ algorytmu konstrukcji modelu opartego o graf skierowany tworzony jest plik reprezentujacy ˛ prototyp diagramu procesu w notacji BPMN. W odróz˙ nieniu od istniejacych ˛ podej´sc´ metoda prezentowana w tej pracy nie wymaga od projektanta deklarowania zalez˙ no´sci pomi˛edzy zadaniami w sposób jawny. Kaz˙ dy z uczestników procesu bierze natomiast udział w tworzeniu specyfikacji modelu poprzez zdefiniowanie swoich zadań wraz z ich warunkami poczatkowymi ˛ oraz wynikami działania. Ponadto od uczestnika procesu nie jest wymagana znajomo´sc´ notacji BPMN ani innego standardu modelowania. Inna˛ zaleta˛ opracowanego podej´scia jest metoda generowania diagramów BPMN podzielona na róz˙ ne etapy. Tego rodzaju podej´scie pozwala na wi˛eksza˛ elastyczno´sc´ w modelowaniu i umoz˙ liwia jego kontrolowanie na róz˙ nych etapach. Przedstawiona w tej pracy analiza porównawcza proponowanych metod pokazuje, z˙ e prezentowane rozwiazanie ˛ jest dogodne dla uz˙ ytkowników oraz pozwala na generowanie modeli BPMN złoz˙ onych z elementów, które wystarczaja˛ do pokrycia blisko 70% przypadków biznesowych. Otrzymane wyniki dowodza,˛ z˙ e zaproponowany w tej pracy algorytm konstrukcji modeli jest w stanie generować diagramy zawierajace ˛ złoz˙ one struktury przepływu.. xi.

(12) Contents 1 Introduction. 1. 1.1. Research Problem and Scope of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Original Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3. 1.3. Plan of the Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 2 Business Process Management. 7. 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.2. BPM Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11. 2.3. Business Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1. Process Modeling Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14. 2.3.2. Notation Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20. 3 Business Process Automated Modeling and Planning 3.1. 7. 21. Automated Generation of Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1. Generating Models from Natural Language (A) . . . . . . . . . . . . . . . . . . . . 22. 3.1.2. Generating Models from Structured Text (B) . . . . . . . . . . . . . . . . . . . . . 23. 3.1.3. Translating Process Models (C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. 3.1.4. 1:1 Mapping of Process Models (D) . . . . . . . . . . . . . . . . . . . . . . . . . . 24. 3.1.5. Generating Process Models from Specifications (E) . . . . . . . . . . . . . . . . . . 24. 3.1.6. Generating Process Models from Data Models (F) . . . . . . . . . . . . . . . . . . 24. 3.1.7. Generating BPMN Diagrams based on Declarative Models (G) . . . . . . . . . . . . 24. 3.1.8. Spreadsheet-Based Process Modeling (H) . . . . . . . . . . . . . . . . . . . . . . . 25. 3.1.9. Generating Models from Process Fragments (I) . . . . . . . . . . . . . . . . . . . . 28. 3.1.10 Process Mining (J) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.11 Model Configuration (K) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2. Implementation Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.1. Answer Set Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30. 3.2.2. XSL Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 xii.

(13) xiii. CONTENTS. 3.3. 3.2.3. Natural Language Processing Libraries . . . . . . . . . . . . . . . . . . . . . . . . 31. 3.2.4. ProM Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. 3.2.5. Other Software Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. Business Process Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.1. Overview of Automated Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 32. 3.3.2. Planning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. 3.3.3. Application of AI Planning in Process Modeling . . . . . . . . . . . . . . . . . . . 35. 4 Constraint Programming. 37. 4.1. Constraint Satisfaction Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37. 4.2. Applications of Constraint Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 40. 4.3. CSP Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3.1. The PROLOG language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44. 4.3.2. MiniZinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45. 4.3.3. Other Environments for Constraint Programming . . . . . . . . . . . . . . . . . . . 47. 5 Motivation. 49. 5.1. State-of-the-art Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49. 5.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51. 5.3. Participatory Process Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53. 5.4. Business Process Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53. 5.5. Construction of BPMN Models based on Artificial Traces . . . . . . . . . . . . . . . . . . 54. 5.6. Highlights of the Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56. 6 Composition of a Business Process. 57. 6.1. Overview of the Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57. 6.2. Running Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59. 6.3. Defining Process Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60. 6.4. Collecting Process Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62. 6.5. Creating the Merged Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64. 6.6. Generating Workflow Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66. 6.7. Constructing a BPMN Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.7.1. Generating an Activity Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73. 6.7.2. Refining Graph Edges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75. 6.7.3. Identifying Logical Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78. 6.7.4. Generating a BPMN 2.0 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(14) xiv. CONTENTS. 6.8. The Mining-Driven Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91. 7 Implementation and Tools 7.1. 7.2. 7.3. Conceptual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.1.1. Aim and Scope of the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . 93. 7.1.2. Users and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94. 7.1.3. High Level Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95. 7.1.4. Data Flow and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96. Functional Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 7.2.1. Specification Editor – Defining a Modeling Task . . . . . . . . . . . . . . . . . . . 97. 7.2.2. Specification Editor – Collecting Activity Specifications . . . . . . . . . . . . . . . 100. 7.2.3. Process Composer – Merging a Process Specification . . . . . . . . . . . . . . . . . 102. 7.2.4. Process Composer – Generating Workflow Traces . . . . . . . . . . . . . . . . . . . 104. 7.2.5. Process Composer – Generating a Log for Process Mining . . . . . . . . . . . . . . 105. 7.2.6. Process Composer – Constructing a BPMN Model . . . . . . . . . . . . . . . . . . 106. Technical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 7.3.1. Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108. 7.3.2. Application Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114. 7.3.3. System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115. 8 Evaluation of the Proposed Approach 8.1. 8.2. 8.3. 8.4. 93. 117. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 8.1.1. Determining the Number of Traces in a Proces Model . . . . . . . . . . . . . . . . . 118. 8.1.2. Constraint-Based Log Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 121. Validation of the Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 8.2.1. Generation of Workflow Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128. 8.2.2. Graph-Based Model Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . 128. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 8.3.1. Evaluation on Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131. 8.3.2. Support for BPMN Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136. 9 Conclusions and Future Work. 137. 9.1. Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137. 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139. 9.3. Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(15) CONTENTS. 9.4. xv. Plans for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141. A BPMN Models used for Evaluation. 143. A.1. Liability Insurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143. A.2. Supply Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144. A.3. Student Project Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144. A.4. Employee Hiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145. A.5. Bank Account Opening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145. A.6. Intricate example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146. B Business Process Specification Survey. 147. B.1. User’s Role in BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147. B.2. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148. B.3. Example Activity Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150. B.4. Prepare Activity Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151. Bibliography. P. Wi´sniewski Business Process Composition. Planning with Constraints. 153.

(16) List of Abbreviations AI. –. Artificial Intelligence. ARD. –. Attribute Relationship Diagrams. ASP. –. Answer Set Programming. BOM. –. Bill Of Materials. BPM. –. Business Process Management. BPMN. –. Business Process Model and Notation. CFC. –. Control Flow Complexity. CMMN. –. Case Management Model and Notation. CoE. –. Center of Excellence. CP. –. Constraint Programming. CSP. –. Constraint Satisfaction Problem. CSV. –. Comma-Separated Values. D3. –. Decision Dependency Design. DMN. –. Decision Model and Notation. EPC. –. Event-driven Process Chain. LD. –. Looping Depth. LTL. –. Linear Temporal Logic. NLP. –. Natural Language Processing. OMG. –. Object Management Group. PBWD. –. Product Based Workflow Design. PDM. –. Product Data Model. PDDL. –. Planning Domain Definition Language. PST. –. Product Structure Tree. SBVR. –. Semantics of Business Vocabulary and Business Rules. TQM. –. Total Quality Management. UML. –. Unified Modeling Language. UML AD. –. UML Activity Diagram. WfMC. –. Workflow Management Coalition. WFM. –. Workflow Management. XML. –. Extensible Markup Language. XSLT. –. Extensible Stylesheet Language Transformations. YAWL. –. Yet Another Workflow Language.

(17) List of Figures 1.1. Example process model of offer preparation. . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 2.1. The general concept of the Six Sigma approach. . . . . . . . . . . . . . . . . . . . . . . . .. 8. 2.2. The area of Workflow Management and Business Process Management. Based on [193]. . .. 9. 2.3. Overview of the Business Process Management Life Cycle (based on [81, 235]). The scope of this work has been marked with green background. . . . . . . . . . . . . . . . . . . . . . 12. 2.4. A set of common BPMN flow objects. Based on [172]. . . . . . . . . . . . . . . . . . . . . 16. 2.5. Swimlanes in BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. 2.6. The most common artifacts in BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. 2.7. Example BPMN model of the tramway dispatching process. Based on [223]. . . . . . . . . . 17. 2.8. Petri net representing the tramway dispatching process. . . . . . . . . . . . . . . . . . . . . 18. 2.9. Model of tramway dispatching process designed using the EPC language. . . . . . . . . . . 18. 2.10 UML Activity Diagram representing the tramway dispatching process. . . . . . . . . . . . . 19 2.11 Model of the tramway dispatching process in the YAWL language. . . . . . . . . . . . . . . 19 3.1. Proposal of method classification for automated generation of business process models. . . . 22. 3.2. BPMN model corresponding to the spreadsheet-based representation presented in 3.1. . . . . 26. 3.3. Overview of the process recomposition approach. Based on [231]. . . . . . . . . . . . . . . 28. 4.1. The general concept of Constraint Programming, based on [15] (. – feasible solution, # – infeasible solution). . . . . . . . . . . . . . . . . . . . . . . . . 38. 4.2. The MiniZinc execution process. Based on [56]. . . . . . . . . . . . . . . . . . . . . . . . . 47. 5.1. The difference between collaborative and participatory process modeling (O – Process Owner, P – Process Participant). Own work based on the initial concept [229]. . 53. 5.2. Components of a declarative process specification. . . . . . . . . . . . . . . . . . . . . . . 54. 6.1. Outline of the approach which consists of four main phases and a preliminary step. Based on [229]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58. 6.2. Example BPMN model representing order processing. . . . . . . . . . . . . . . . . . . . . . 59 xvii.

(18) xviii. LIST OF FIGURES. 6.3. Example business process graph with nested loops. . . . . . . . . . . . . . . . . . . . . . . 68. 6.4. Example output of the CSP solver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72. 6.5. Activity graph generated for the example business process. . . . . . . . . . . . . . . . . . . 75. 6.6. Activity graphs created from the example workflow logs: (a) W1 and (b) W2 . . . . . . . . . 76. 6.7. Activity graph of the example business process after the refinement of edges. . . . . . . . . 78. 6.8. An example of an OR-split gateway (a) and its equivalent structure (b). . . . . . . . . . . . 79. 6.9. An extracted part of graph GA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84. 0. 0. 6.10 The discovered gateway structure for graph GA . The numbers of gateways are shown in parentheses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.11 Business process graph created based on the example activity graph (Figure 6.7). . . . . . . 87 6.12 Metamodel of the supported BPMN subset. . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.13 Example process discovered using ILP miner. . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.1. BPMN model depicting the system implementation. . . . . . . . . . . . . . . . . . . . . . . 95. 7.2. BPMN model depicting process modeling using the proposed software. . . . . . . . . . . . 97. 7.3. Data Flow Diagram of the application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98. 7.4. Specification Editor – the Process Info tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . 98. 7.5. Specification Editor – the Outcomes tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99. 7.6. The XML metamodel for Process Requirements. . . . . . . . . . . . . . . . . . . . . . . . 100. 7.7. Specification Editor – the Activities tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100. 7.8. Specification Editor – the Activity Overview tab. . . . . . . . . . . . . . . . . . . . . . . . 101. 7.9. Specification Editor – the Activity Info tab. . . . . . . . . . . . . . . . . . . . . . . . . . . 102. 7.10 Specification Editor – the Activity Details tab. . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.11 XML metamodel for Activity Descriptions. . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.12 Process Composer – the Merge Specification tab. . . . . . . . . . . . . . . . . . . . . . . . 104 7.13 Process Composer – the Generate Traces tab. . . . . . . . . . . . . . . . . . . . . . . . . . 105 7.14 Process Composer – the Create Log File tab. . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.15 Process Composer – the Construct Model tab. . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.16 High-level UML class diagram of the developed application. . . . . . . . . . . . . . . . . . 109 7.17 UML class diagram for Activity Description. . . . . . . . . . . . . . . . . . . . . . . . . . 109 7.18 UML class diagram for BPMN Writer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.19 UML class diagram for Data Entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.20 UML class diagram for Flow Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 7.21 Class diagram for Gateway Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.22 Class diagram for Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(19) LIST OF FIGURES. xix. 7.23 UML class diagram for MiniZinc Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.24 UML class diagram for Process Composer. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.25 UML class diagram for Process Graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 7.26 UML class diagram for Process Specification. . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.27 Class diagram for Sequence Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.28 Class diagram for Trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.29 UML class diagram for XES Writer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.30 Sample content of the Composer Configuration file. . . . . . . . . . . . . . . . . . . . . . . 114 8.1. Overview of the proposed approach with the highlighted scope. Based on the idea proposed in paper [230]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118. 8.2. Simple sequential workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119. 8.3. Example process with two basic types of gateways. . . . . . . . . . . . . . . . . . . . . . . 120. 8.4. Example process with nested gateway structures. . . . . . . . . . . . . . . . . . . . . . . . 121. 8.5. Token flow subgraphs extracted from a business process model. . . . . . . . . . . . . . . . . 122. 8.6. Composition accuracy calculated for the set of example models. . . . . . . . . . . . . . . . 130. 8.7. Composition accuracy calculated with respect to the looping depth of the example models. . 131. 8.8. Structure of survey respondents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132. 8.9. BPMN familiarity test results grouped by score rank. . . . . . . . . . . . . . . . . . . . . . 133. 8.10 BPMN familiarity test results grouped by score rank. . . . . . . . . . . . . . . . . . . . . . 134 A.1 Liability Insurance process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 A.2 Supply Management process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 A.3 Student Project Evaluation process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 A.4 Employee Hiring process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 A.5 Bank Account Opening process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 A.6 Intricate example process model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 B.1 Example model 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.2 Example model 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 B.3 Example model 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 B.4 Example model 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 B.5 Example model 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(20) xx. P. Wi´sniewski. LIST OF FIGURES. Business Process Composition. Planning with Constraints.

(21) Chapter 1. Introduction This chapter introduces the reader to the content of this dissertation. Section 1.1 provides an overview of the scope of the conducted research, as well as the goal of this work. In Section 1.2, the original contributions to the current state of knowledge related to Business Process Management are introduced. Finally, in Section 1.3, the plan of this work, understood as the content of each chapter, is presented.. 1.1. Research Problem and Scope of the Thesis. Modeling business processes is a way to describe organizational workflows which aim to achieve required goals, understood as products or services delivered to a final customer. Providing an understandable representation of a process helps to establish a common link between technical and business people. This, in turn, gives an opportunity to optimize the process structure. As a consequence, the company may achieve their business objectives in a more efficient way. Therefore, worldwide affiliations such as the Object Management Group1 define universal standards for visualizing business process models. Business Process Model and Notation (BPMN) [144] is one of the most widely used standards for modeling business processes and inter-organizational collaboration. BPMN process diagrams depict chains of activities triggered by one or more start events and finished by an end event, which represents an outcome of the process. Figure 1.1 shows an example process model designed in BPMN. Although a well-designed process model does not require major improvements, the requirements for modern software systems and business workflows are constantly changing which causes the need to modify or re-create process model frequently. For that reason, it is important to design processes in an efficient way. It is proved that manually created process representations usually suffer from various modeling errors, such as inconsistent connections or deadlocks [107]. Thus, automating the modeling phase could be beneficial for obtaining process models of higher quality and in a shorter time compared to manual modeling. 1. http://www.omg.org/. 1.

(22) reparation 2. 1.1. Research Problem and Scope of the Thesis. Customer. Sales Assistant. Create Offer. Include Remarks. Request for Quotation. no. Sales Maanger. Sales Maanger. Universal Exports. Sales Assistant. yes. Review Offer. Send Offer to Customer. Approved?. Offer Sent. Figure 1.1: Example process model of offer preparation.. Business Process Composition refers to twenty Business Process Management use cases proposed by van der Aalst [195] (see Chapter 2), which were defined to classify the area of research related to business processes. As there is no explicit use case related to the automated generation of process models, the "Compose model" use case has been considered. According to the cited paper "Use case compose model refers to the situation where different models are combined into a larger model". In case of the proposed approach method, parts of the process specification may be regarded as subprocesses or components of other models. Another field related to this work is the web service composition. According to the survey made by Rao and Su [158], in case of process composition "The process generator usually takes the functionalities of services as input and outputs process model that describes the composite service. The process model contains a set of selected atomic services and the control flow and data flow among these services". In addition, Sirin, Hendler and Parsia [174] provide an example of composition based on two web-based language translators: As an example of composition, suppose there are two web services, an on-line language translator and a dictionary service, where the first one translates text between several language pairs and the second one returns the meanings of English words. If a user needs a French Dictionary service, neither of these can satisfy the requirement. However, together they can – the input can be translated from French to English, fed through the English Dictionary, and then translated back to French. Compared to the approach proposed in this work, these two services may be regarded as separate tasks of the process. The specification of a process proposed in this thesis includes input and output parameters of an activity. The generated process model needs to fulfill the data requirements, e.g. which data entities have to exist when the process is completed. This may be achieved only by a limited number of task sequences, not necessarily using all the activities included in the specification. By the time when different declarative P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(23) 1.2. Original Contribution. 3. descriptions are combined, the resulting process representation remains an unordered list of activities. According to the primary concept of the proposed approach, the composition is the overall semi-automated process that includes three main phases, namely: specification merge, workflow trace generation, and model construction which may be performed in two ways. Automated Planning is an area of research that aims to generate a chain of actions oriented at achieving desired goals. A definition of a planning problem and its solution is therefore closely related to Business Process Management, since a plan can also represent a single instance of a particular workflow. However, every business process can be executed in a limited number of ways, each of which refers to a different process instance. The upper limit of this number depends on different factors, such as occurrence of specific events, resource availability or other external conditions. All of these aspects can be represented by particular pieces of data and form a part of preconditions or effects for the executed activity. In other words, an activity can be executed only if a given set of constraints is satisfied. Thus, planning of a business process must be accompanied by constraints that determine the conditions needed for every activity to be executed, as well as the potential outcomes caused by this activity. The goal of this work is determined by the future usability of the proposed solutions and includes the development of supporting arguments for the following theses: • The use of Constraint Programming and Automated Planning may constitute an efficient method of business process modeling. • The composition of a business process based on an unordered list of tasks with determined inputs, outputs and additional conditions can be used to obtain workflows compliant with the BPMN standard. It is assumed that these goals can be achieved by defining an approach which would potentially reduce the number of iterations needed for creating a business process model. Thus, the proposed methodology covers a set of algorithms used to specify the process in a declarative way and then construct its representation in a widely used modeling language, as well as the implementation of such algorithms as a reusable software module. As the next step, such an approach to automated process composition is compared to the existing generation methods, such as manual model design and process mining.. 1.2. Original Contribution. The original contribution of this dissertation includes the following: 1. Providing a comparative overview and classification of automated process generation methods (Section 3.1). 2. Defining and explaining the concept of participatory process modeling (Section 5.3). 3. Identifying a set of phases needed to compose a BPMN model based on activity descriptions provided by the participants (Sections 6.1-6.4). P. Wi´sniewski Business Process Composition. Planning with Constraints.

(24) 4. 1.3. Plan of the Work. 4. Defining a set of constraints that ensure the correctness of a synthetic process trace (Section 6.6). 5. Introducing the concept of an activity graph synthesized based on a generated log (Section 6.7). 6. Defining an algorithm to construct a BPMN model, including formalization of the process model and constraint-based identification of logical structures (Section 6.7). 7. Providing a concept of a software system for the proposed approach (Section 7.1). 8. Proposing a detailed design of two application modules, namely Process Editor and Process Composer, which may be used to apply the methods developed in this thesis (Section 7.2). 9. Implementing the Process Composer module (Section 7.3) and evaluating it on a set of example process models (Section 8.2). 10. Defining a dedicated method to validate process models generated from event logs (Section 8.1).. 1.3. Plan of the Work. This thesis is divided into two main parts based on their specificity and the level of originality. The first part is dedicated to the state-of-the-art analysis of the research led within the scope of this work, which was performed through analytical and critical review of the state-of-the-art literature positions. It is organized as follows: Chapter 2 gives an overview of Business Process Management as a research area, including using business processes as knowledge representation (Section 2.1), the concept of BPM Life Cycle (Section 2.2), as well as business process models and modeling languages (Section 2.3). Chapter 3 discusses the idea of business process modeling, focusing on the automated model generation (Section 3.1), as well as tools and technologies that may be applied for modeling (Section 3.2). Also in this chapter, the area of Automated Planning has been reviewed and placed in the domain of Business Process Management (Section 3.3). As the end of the first part, in Chapter 4, Constraint Programming is presented to the reader. The definition of a Constraint Satisfaction Problem (Section 4.1) is followed by a presentation of application areas for CSPs with an emphasis on its use in Business Process Management (Section 4.2), as well as a brief overview of the existing tools for solving such problems (Section 4.3). Chapter 5 serves as an introduction to the second part of this work, which mainly describes the contributions and novel ideas. It starts with a state-of-the-art literature review (Section 5.1), followed by a definition of problems within the area of process composition and solutions proposed in this thesis (Section 5.2). Then, Chapter 5 presents the concept of participatory process modeling (Section 5.3) and explains the idea of using declarative process specifications (Section 5.4). In addition, the methodology for defining process modeling constraints, as well as the justification for constructing process models based on synthetic traces (5.5), were presented. Finally, Section 5.6 presents the main solutions proposed in this thesis and described in Chapters 6-8.. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(25) 1.3. Plan of the Work. 5. The second part of the thesis consists of defining, implementing and evaluating the concept of constraintbased business process composition. Chapter 6 provides a formalization and the detailed specification of the proposed approach. It includes a problem definition with distinction of five phases (Section 6.1), namely: requirements definition (Section 6.3), data collection (Section 6.4), specification merge (Section 6.5), solving the Constraint Satisfaction Problem by generating synthetic traces (Section 6.6) and constructing the final model (Section 6.7). In addition, an alternative method to generate process models using existing process mining algorithms is proposed (Section 6.8). In Chapter 7, an idea of software implementation of the methods described in this work is presented. The proposal includes a conceptual design which discusses the use of the application from a business perspective (Section 7.1), a functional analysis and description of the developed software (Section 7.2), as well as the technical details of the implemented module (Section 7.3). As a complementary segment of this part, Chapter 8 describes the evaluation of the ideas presented in this work, including a methodology developed for verifying process models (Section 8.1), checking the correctness of the proposed methods (Section 8.2) and discussing the applicability of the presented solution including evaluation on a group of business and academic users (Section 8.3). Finally, concluding remarks including the summary of the ideas proposed in this thesis (Section 9.1), and its limitations (Section 9.2) are presented in Chapter 9. The last chapter includes also a list of published research works (Section 9.3), as well as plans for future work (Section 9.4).. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(26) 6. P. Wi´sniewski. 1.3. Plan of the Work. Business Process Composition. Planning with Constraints.

(27) Chapter 2. Business Process Management This chapter presents Business Process Management which is a wide domain of scientific research, being applied in areas such as industry, finance, IT and business administration. Section 2.1 provides a general overview and purpose of using business processes as knowledge representation. In Section 2.2 the concept of BPM Life Cycle as well as its phases were presented. Finally, the idea of Business Process Models is described in Section 2.3.. 2.1. Overview. Business Process Management (BPM for short) [216] is a holistic approach which aims to increase efficiency of workflows present in different organizations. Its goal is to formally define processes, redesign them if needed, optimize procedures, as well as to define the rules of application for business process models. One of the guiding principles of BPM is looking at the processes from a broader perspective instead of focusing on certain activities. Improving a process means also reviewing parallel or alternative chains of actions, occurring events, decisions to be made, as well as the final value represented by a product or service offered to the final recipient. Increasing complexity of business processes requires efficient tools and methodologies to manage processes effectively. BPM originated from various management approaches that emerged during the 1980s along with the growing popularity of computers and shortened product life cycles [59]. Dumas et al. [38] have indicated four major disciplines related to Business Process Management, namely: • Total Quality Management (TQM) – an approach which aims to augment customer satisfaction and business performance of the organization. The general idea of TQM consists in bringing together all the suggestions which may improve the process in terms of quality or customer relations. It is based on six major concepts [11]: Management Commitment, Customer Focus, Employee Involvement, Continuous Process Improvement, Supplier Partnerships and Performance Measures. 7.

(28) 8. 2.1. Overview. • Operations Management – an approach focusing on task, issues and decision made by supervisors responsible for certain products or services. It is present mainly in the industry, represented by various IT systems such as Manufacturing Operations Management [30]. • Lean Production – a concept which evolved from Just-in-Time Manufacturing (JIT) approach that was invented by Japanese manufacturers in late 20th century. The main goal of this approach is providing the maximized customer service with minimal waste in the system [11]. It is worth noting that in this case the notion of waste covers not only physical scrap, but also all the actions which do not add value to the final product. • Six Sigma – a methodology which intends to ensure that the entire system does not fail. This goal is achieved by systematically reducing the variability of the production process. In the desired situation, 99.7% of the process output values should fall in the doorway two times narrower than the specification [11], whose limit should be set as six standard deviations (σ) of a normal distribution. The general concept of the Six Sigma approach is presented in Figure 2.1. Upper Spec. Limit. Lower Spec. Limit. 99.7% values. -6σ. -3σ. -1σ. Mean. 1σ. 3σ. 6σ. Figure 2.1: The general concept of the Six Sigma approach. In addition to the related disciplines, it is worth mentioning Workflow Management as a significant source of origin for BPM. The definition of workflow has been formulated by the Workflow Management Coalition (WfMC) [217] as: the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules [104]. In general, BPM is considered a broader term than Workflow Management, since it covers also features such as diagnosis, simulation, verification or validation of process designs [81]. Van der Aalst [193] defined four main phases of process management which include: 1. Process Design – creation or re-creation of the process, 2. System Configuration – implementing the process by configuring a process management system, P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(29) 9. 2.1. Overview. 3. Process Enactment – executing in the operational business process with the configured system, 4. Diagnosis – analysis and verification of the process to finds areas for improvement. Figure 2.2 presents a simplified BPM flow where the area of application for Workflow Management was indicated. As it can be clearly seen, Business Process Management creates a closed loop between the phases. This is a basis for the so called BPM Life Cycle which is described in details in Section 2.2. Business Process Management Process Design. System Configuration. Diagnosis. Process Enactment Workflow Management. Figure 2.2: The area of Workflow Management and Business Process Management. Based on [193].. The most important notion in terms of BPM is a Business Process (BP for short). Although many different definitions of a business process have been invented in the last decades [120], a BP can be briefly described as a set of partially ordered activities, events and decisions which produce a certain output. Such an output, also referred to as a goal, is related to a product, service or any other value for the final recipient. To clarify the understanding of what a Business Process is and how it can reflect the real-life workflows, Dumas et al. [38] identified common ingredients for business processes: – activities – units of work performed manually or as an automated service, an atomic activity that cannot be divided is called a task, – events – things that happen without measurable duration, – decision points – situation when a decision is made which affects the execution of the process, – actors – process participants, seen as people, organization or software systems, – physical objects – equipment, materials or documents, – immaterial objects – electronic data, people’s knowledge, – outcomes – final products or services, as well as negative outcomes e.g. refusals or error messages, – customer – internal or external recipient of the outcome. The analysis of common ingredients leads to a definition of a Business Process as a collection of interrelated events, activities and decision points that involve a number of actors and objects, and that collecP. Wi´sniewski Business Process Composition. Planning with Constraints.

(30) 10. 2.1. Overview. tively lead to an outcome that is of value to at least one customer [38]. This definition combines several existing approaches [31, 39] and thus, it is further considered as valid in this work. In order to illustrate which chains of activities can be regarded as business processes, let us present a simple example of order picking [170] which is a common process in manufacturing companies: A logistic supervisor receives an order. Then, he or she prepares the pick list and sends it to a logistic operator. In the next step, the operator collects items from the warehouse and puts them on a trolley. If the requested material is not available in stock, the operator triggers an alert and the picking is stopped. Otherwise the trolley is moved to the production line and the picking order is completed. Table 2.1 shows the example picking process mapped into the process ingredients proposed by Dumas et al. [38]. It is worth noting that not every business process must contain all the indicated elements. For instance, one can imagine a simple workflow where all the activities are executed in a fixed sequence by a single actor. However, in real-life implementations such situations happen rarely. Table 2.1: Business process ingredients of Order Picking. Ingredient Activities Events Decision Points Actors Physical Objects Immaterial Objects Outcomes Customer. Values Prepare Pick List, Send Pick List, Pick Item, Trigger Alert Order Received, Material Missing, Picking Completed Material in Stock Logistic Supervisor, Logistic Operator Pick List, Trolley, Inventory records in the Warehouse Management System Components on the Production Line, Order Cancellation Manufacturing Department. Currently, BPM is used not only as an approach to manage physical processes taking place in an organization. Since highly developed IT systems exist in various areas of industrial and business applications, there is a need to ensure their reliability and efficiency, as well as to simplify their design and development phases. Therefore, BPM techniques play a vital role at the time when a system specification is prepared [90]. Examples of such systems may range from human-machine interfaces, through production management and control, to web services covering a large domain of implementations. Although Business Process Management is a term which covers a large number of potential applications and offers a significant level of flexibility and customization for the organization, it should be implemented with attention and adherence to good practices. Vom Brocke et al. [211] proposed ten principles of successful BPM. The main rules to follow when implementing BPM methods focus on ensuring that the defined procedures are adapted to the specifics of the organization and work as a constant practice. Good BPM applications should be cross-functional and on the other hand, they need to be included in the organizational structure of the company. A successful introduction of Business Process Management must also be followed by a strong involvement of all the stakeholders of the process. This is easier to achieve if the process repP. Wi´sniewski. Business Process Composition. Planning with Constraints.

(31) 2.2. BPM Life Cycle. 11. resentation is clear and comprehensible for the process participants [132]. The last principles which are significant with respect to this work refer to simplicity, understood as the economical amount of resources invested to implement BPM, as well as the advice to use IT solutions that support the enactment of Business Process Management.. 2.2. BPM Life Cycle. In the previous section, four main phases of process management were described (see Figure 2.2). As new areas of application for Business Process Management have emerged rapidly in the recent years, the closed loop procedure of managing business processes has been specified and extended in order to better represent the evolution of a process. This continuous sequence of phases is called Business Process Management Life Cycle (see Figure 2.3). Such a representation of BPM allows for repetitive maintenance and control of the process, as well as adapting it to changing business needs. In every iterations, parameters of the process which are related to its outcome may be improved causing the amelioration of the whole system. Thus, the crucial step in BPM is to define metrics which enable analysts to measure the value delivered by the process [38]. Such measures may be cost- or time-related e.g. cycle time which is defined as time needed to perform the process [210]. In some of the approaches [38, 214] it is assumed that the first phase of the BPM life cycle may start by discovering the existing process and re-designing it afterwards. In such a case there is a distinction between the as-is process model, i.e. the model representing the current state of the process and the to-be process model which is the result of process redesign. As this work is primarily related to generating models which have not existed before, the process designed in the first iteration of the cycle will always be a to-be model. The phases of the BPM life cycle as presented in Figure 2.3 may be defined as follows: • Goal Specification – In this phase, a specification of process participants, outcomes and environmental factors is prepared. It may also include additional constraints on the process, such as triggering conditions for activities. Its output is the initial architecture of the process that provides an overall view of the activities to be performed. • Process Design – At this stage, a detailed specification of the workflow and data being processed is defined. The output of this phase is a process model created in a selected notation. In addition, based on the created model several target metrics are defined in order to control and evaluate the future execution of the process. • Process Implementation – This phase covers the executable workflow modeling and application of the created process model in the environment. It requires organizational change management understood as redefining the activities performed by the participants, as well as process automation, including enhancements of existing IT systems in the organization. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(32) 12. 2.2. BPM Life Cycle. Goal Specification Process Architecture. Measures for Improvement. Process Evaluation. Process Design. Target Metrics. Process Model. Process Implementation. Implemented Process. Monitoring Results. Process Monitoring. Process Enactment. Measurements. Figure 2.3: Overview of the Business Process Management Life Cycle (based on [81, 235]). The scope of this work has been marked with green background. • Process Enactment – Once the process is implemented, its instance is created for every initial event. The process is executed in a runtime environment where it may be controlled by an IT system. Outcomes of the process are measured using predefined metrics. • Process Monitoring – This phase occurs usually while the process is running. Event data and values of the conducted measurements are collected and registered in a database. • Process Evaluation – Finally, the registered data are analyzed in terms of their compliance with the initially defined requirements. The purpose of this phase is to find potential errors, as well as to define areas of improvement for the whole process. Within the BPM life cycle, six major roles may be defined [38]: 1. Management Team – high level management of the organization which is responsible for defining the manner in which the operations are executed. 2. Process Owners – people planning and organizing the efficient execution of the process. 3. Process Participants – human actors who execute activities of the business process. They are involved as domain experts and support process improvement actions. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(33) 2.3. Business Process Models. 13. 4. Process Analysts – people responsible for controlling process implementation and redesign activities. 5. System Engineers – IT specialists who collect system requirements and conduct appropriate changes in the BPM software. 6. Centre of Excellence (CoE) – a group responsible for collecting and documenting knowledge about processes. It supports other stakeholders in maintaining the correct BPM practices.. 2.3. Business Process Models. The BPM life cycle, described in Section 2.2, must be accompanied by appropriate models of the managed process. Process modeling can be understood as a set of techniques for representing the workflow using visual diagrams which depict the process and its dependencies. Such diagrams represent the workflow by displaying the way the activities are performed in order to achieve the business goal. According to the definition proposed by Weske [216], a process model is a blueprint for a set of process instances with a similar structure. It means that the model must illustrate the general overview of the process, taking into consideration different execution scenarios of particular instances. As explained before in Section 2.1, business process models may be used to describe the architecture of complex IT system. An example of such applications are Manufacturing Execution Systems [160] where BP models present the integration of the technical and functional model of the system. They also depict production processes and thus, a complete modeling framework is created. An advantage of such an approach is the fact that the system specification is comprehensible for all the process stakeholders. Van der Aalst [195] identified twenty Business Process Management use cases in order to categorize activities and techniques related to process models. Six main categories include: obtaining process models, managing configurable models, process execution, model-based analysis, extracting information from event data and model improvement. Table 2.2 summarizes these use cases and their categories. This work covers the category of obtaining process models which was highlighted in the first row. Since the Design Model use case is defined as creation of a process model from scratch by a human, the use case which reflects the automated generation of process graphical representation is Compose Model. It can be described as combining different models into a larger process model. Therefore, components needed for process composition should either be subprocesses or consistent elements of a process model, including atomic tasks. Although many different process modeling languages have been presented in recent years [216, 81], Business Process Model and Notation (BPMN for short) proposed by the Object Management Group (OMG)1 is the most widely used standard for business process modeling [90]. Therefore, it has been chosen as a basis for the process composition approach proposed in this work. Further in this section, a brief 1. http://www.omg.org. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(34) 14. 2.3. Business Process Models. Table 2.2: Twenty BPM Use Cases [195]. Category Obtaining Models. Configurable Models. Process Execution. Model-Based Analysis Extracting Diagnostics from Event Data Producing New Models Based on Diagnostics or Event Data. Use Case Design Model Discover Model from Event Data Select Model from Collection Merge Models Compose Model Design Configurable Model Merge Models into Configurable Model Configure Configurable Model Refine Model Enact Model Log Event Data Monitor Adapt While Running Analyze Performance Based on Model Verify Model Check Conformance Using Event Data Analyze Performance Using Event Data Repair Model Extend Model Improve Model. Abbreviation DesM DiscM SelM MerM CompM DesCM MerCM ConCM RefM EnM LogED Mon AdaWR PerfM VerM ConfED PerfED RepM ExtM ImpM. overview of BPMN as well as other process modeling standards which can be used as a substitute or as an extension, was presented (Section 2.3.1).. 2.3.1. Process Modeling Languages. This section provides an overview of common notations used for process modeling. It describes in details the Business Process Model and Notation, which is the main modeling language used in this thesis, as well as four other types of process representation, namely: Petri nets, Event-driven Process Chains, UML Activity Diagrams and YAWL. All these languages are used to specify the chain of activities and their relationships in the process. This may also be referred to as process orchestration [216] which describes the execution constraints of process elements, as well as the control flow structures.. Business Process Model and Notation BPMN provides a limited set of graphical elements for depicting diagrams which represent the ingredients of the process and the manner in which it should be executed [115]. The present BPMN 2.0 version of the specification [144] enables process analysts and system to design process, choreography and collaboration models. However, since this work refers to process models which are the most popular BPMN diagrams [24], these will receive the most attention in this section. Within the BPMN elements collection for process models, one can distinguish four major groups, P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(35) 2.3. Business Process Models. 15. namely: flow objects, connecting objects, swimlanes and artifacts. Flow objects are the necessary part of every process model. In this set, there are three main object types: 1. Activities (rounded rectangles) – representing a unit of work that has to be performed in the process. 2. Events (circles) – representing incidents occurring at the time of process execution. 3. Gateways (rhombi) – controlling the flow of tokens in the process. It is worth noting that these three groups correspond to the definition of a business process provided in Section 2.1. Decision points in the process are in this case represented by alternative (both inclusive and exclusive) split gateways. The set of activities can be divided into tasks and subprocesses. According to the intuitive definition of process ingredients (see Section 2.1) a task is an atomic unit of labour that may be executed manually (User Task) or automatically (Service Task). On the other hand, a subprocess is a complex activity which may be regarded as an autonomous process at the lower level. As a consequence, in every subprocess one can distinguish lower-rank activities. In the set of events, there are three types of objects: – start events – indicating the beginning of a process with optional triggering conditions, – intermediate events – capable of occurring at any time within a process, – end events – determining the end of a path in a process or subprocess. The control of the process flow is managed by gateways. They split the main path into branches and join them afterwards. The most frequently occurring BPMN gateways are data-based. In other words, they evaluate an expression of process data, while they are not capable of making a decision regarding the flow of the process [172]. Data-based gateways in the process can be exclusive (XOR), enabling only one outgoing sequence flow based on given process data, or inclusive (OR) that are preceding potentially parallel branches. Another type of a control flow element is a parallel (AND) gateway which represents concurrent flows executed at every process instance. A set of the most typically used BPMN flow objects is presented in Figure 2.4. Connecting objects are constructs that link flow objects between each other. The following list defines two major types of connecting objects: – sequence flow – showing the execution order of a process e.g. succession of activities, – message flow – representing the exchange of information between different participants of the process. Swimlanes are BPMN objects that separate business functions or functional parts of the systems. Participants of the process, understood as either business entities or organizational collaborators [122], are represented by pools. Every pool can be further divided into sub-partitions called lanes. They represent specific objects or roles. In BPMN, lanes are represented by rectangles extended either vertically or horizontally along the length of a pool. Figure 2.5 shows the usage of swimlanes in a process model. P. Wi´sniewski Business Process Composition. Planning with Constraints.

(36) 16. 2.3. Business Process Models. Activities Subprocess. Task. Events. Start. End. Timer. Message. Intermediate. Gateways. Exclusive. Parallel. Inclusive. Lane1. Pool. Lane 2. Figure 2.4: A set of common BPMN flow objects. Based on [172].. Figure 2.5: Swimlanes in BPMN. The last group of elements present in BPMN are artifacts. They represent additional information that allows process designers to model specific details in the process. The main types of artifacts are: data objects, groups and annotations. These types are shown in Figure 2.6. Annotation. Group. Task Data object. Figure 2.6: The most common artifacts in BPMN.. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(37) 17. 2.3. Business Process Models. Example 2.3.1. In order to illustrate the notation, a sample model of tramway departure process was selected [223]. Its BPMN model is presented in Figure 2.7. This process consists in preparing a tramway car to leave the depot in the morning. It contains two organizational participants: the Depot which is responsible for storing and servicing the rolling stock and the Traffic Department which controls and manages the tramway traffic [226], as well as one human actor who is the driver. The process goal is the successful departure from the depot which results in starting regular operation with passengers on the given day. Based on the scheduled departure time in the timetable, the Traffic Department prepares and prints the Traffic Card which is the main document for the driver. In the next step, two chains of activities are executed in parallel. The Depot prepares the car for departure while the Traffic Department awaits the driver. If the driver does not arrive, another employee is called. In the next step, the driver is subject to alcohol testing. If alcohol is detected in the exhaled air, a new driver is called and the procedure is repeated. Finally, when the car is ready and the driver is authorized to work, the car can be. Tram taken DDR by the driver from the track. The process ends when the Traffic Department registers the departure.. Depot. Depot. Take Car from Stock. Wash Car. Place Car on Track. Driver. Take Car from Track. Traffic Department. Driver arrived? yes. Check Alcohol Level. Alcohol level OK? yes. Print Traffic Card Scheduled Departure. Authorize Driver. Register Departure. no. no. Traffic Department. Tramway Company. Driver. Registered Departure. Await Driver Call for Driver. Figure 2.7: Example BPMN model of the tramway dispatching process. Based on [223].. Petri Nets Petri nets are represented by directed bipartite graphs with two types of nodes [191]: places, represented by circles and transitions, represented by rectangles. All the nodes are connected by an arch. The bipartition implies that an arc cannot link two nodes of the same type. However, both places and transitions can have multiple incoming and outgoing arcs. The execution of the workflow is represented by tokens which stay in places. A transition, that represents a process activity, may be fired (executed) if and only if each of its preceding places contains at least one token. The distribution of tokens in a Petri net is called marking and defines the state of the system. There are many extensions to the general concept of Petri net which can be P. Wi´sniewski Business Process Composition. Planning with Constraints.

(38) 18. 2.3. Business Process Models. useful for process modeling, such as coloured or prioritized nets [184], as well as Petri nets with decision tables [185]. Figure 2.8 represents the tramway dispatching process (see Figure 2.7 as reference) mapped. m-PetriNet. into a Petri net. Take Car from Stock. Wash Car. Place Car on Track. Print Traffic Card. Take Car from Track Check Alcohol Level. Await Driver. Register Departu re. Authorize driver. Call for Driver. Figure 2.8: Petri net representing the tramway dispatching process.. Event-driven Process Chain Event-driven Process Chains (EPCs for short) are used as an informal notation to model domain concepts and processes [216]. Process models in the EPC notation are build of three major blocks, namely: events, functions and connectors. Blocks are connected by directed edges which represent the control flow. Functions represent units of work which are triggered by events and create new events as a result of their execution.. Tram-EPC The running example (see Figure 2.7) translated into the EPC modeling language is presented in Figure 2.9. ready to take car from stock. Scheduled Departure. car taken from stock. Take Car from Stock. car washed. Wash Car. Place Car on Track. car on track. Print Traffic Card. Take Car from Track. ready to wait for driver. driver arrived. Await Driver. driver not present. Call for Driver. Check Alcohol Level. alcohol level OK. Authorize Driver. tramway departed. Register Departure. Departure Registered. driver authorized. alcohol detected. Figure 2.9: Model of tramway dispatching process designed using the EPC language.. Unified Modeling Language Unified Modeling Language (UML for short) is a generic language used for process and system modeling [96, 180]. The notation covers 17 different diagram types which can be divided into two major categories [90]: structure diagrams which represent the structure of a modeled application and behavior diagrams which represent general types of behavior. In the latter, one can distinguish activity diagrams which focus on the flow of activities and dependencies between them [83]. UML Activity Diagrams are made of action and decision nodes which are connected by control flow elements. In addition, it should have at least one initial and end node, both denoted with black circles. A UML diagram which represents the example business process (see Figure 2.7) is shown in Figure 2.10. P. Wi´sniewski. Business Process Composition. Planning with Constraints.

(39) 19. 2.3. Business Process Models Take Car from Stock. Place Car on Track. Wash Car. Register Dparture. Print Traffic Card Await Driver. Driver arrived?. yes. Check Alcohol Level. no. Alcohol level OK?. yes. Take Car from Track. Authorize Driver. no Call for Driver. Figure 2.10: UML Activity Diagram representing the tramway dispatching process.. Yet Another Workflow Language One of the recently introduced notations for process modeling is Yet Another Workflow Language (YAWL for short), proposed by van der Aalst and ter Hofstede [200]. It is based on Petri nets; however, it also supports advanced control flow patterns, such as: multiple instances, composite tasks and inclusive branching. In addition, YAWL syntax allows tasks to be directly connected, which makes the diagram more comprehensible compared to a standard Petri net. A YAWL representation of the example tram dispatching model (see Figure 2.7) is presented in Figure 2.11.. Figure 2.11: Model of the tramway dispatching process in the YAWL language.. Other Modeling Languages Besides the five major notations presented in this section, there exists a variety of standards to model workflows. One of the common notations used to illustrate simple business processes are flowcharts [46] which originated in 1960s as a tool to improve the documentation of computer programs [93]. Another related approach is PERT (Program Evaluation and Review Technique) [238]. It uses a graph-based notation for project planning and calculation of the total execution time for a set of tasks. It can be also used to optimize a workflow by extracting the critical path, understood as the longest chain of activities [176]. For a more P. Wi´sniewski Business Process Composition. Planning with Constraints.

(40) 20. 2.3. Business Process Models. detailed analysis of a business process, e.g. from a temporal perspective, other graph-based representations can be applied. Existing approaches include the use of temporal graphs [21], graph transformations [97], as well as dedicated solutions such as Compliance Rule Graphs [92].. 2.3.2. Notation Comparison. Table 2.3 describes how the different process ingredients (see Section 2.1) are represented in the notations mentioned in Section 2.3.1. The summary was based on [83, 121, 216]. Table 2.3: Business process ingredients represented by different modeling notations. Ingredient Activities Events. BPMN Activities Events. Petri nets Transitions N/A. EPC Functions Events. Decision Points. Objects. Artifacts. Alternative Paths N/A N/A N/A. Connectors. Actors. OR/XOR Gateways Swimlanes. Outcomes. End Events. Final Marking. Organization Units Information Resources Final Events. Customer. Pool. N/A. N/A. UML AD Activities Send/Receive Signals Decision Nodes Partitions Object Nodes End Nodes Partitions. YAWL Tasks N/A OR/XOR Tasks N/A N/A Output Condition N/A. The results of the comparative analysis show that, within the selected languages, only BPMN and UML Activity Diagrams can satisfy the requirement to represent all common process ingredients. However, according to the detailed comparison of UML and BPMN [90], BPMN process models can cover a larger number of business cases, including not only the process itself, but also specifications of the analyzed system in terms of its requirements and implementation. Although the coverage of common process ingredients can be enough to visualize the workflow, a single notation is not capable of modeling a process from all perspectives. For example, a BPMN model can be accompanied by UML diagrams to represent the analyzed system from a logical perspective [91]. Additional models could be needed to represent time aspects [83], cases, related events [179] or rules [212].. P. Wi´sniewski. Business Process Composition. Planning with Constraints.