On the definition and analysis of process performance indicators

ON THE DEFINITION AND ANALYSIS OF PROCESS PERFORMANCE INDICATORS ADELA DEL RÍO ORTEGA PhD dissertation June 2012 Supervised by Prof. Dr. Antonio Ruiz Cortés and Prof. Dr. Manuel Resinas Arias de Reyna University of Seville To Rafa, you made this happen, thanks for existing. To Nachete, my redheaded bundle of joy to whom this thesis has stolen so much time. ACKNOWLEDGEMENTS i After a long time of hard work, finally it’s time to look back and thank all the people who supported, challenged and push me to make this thesis possible, and to whom I am eternally grateful. First of all, thank God, for giving me the gifts and possibilities of carrying out this thesis. Second, I want to thank my supervisors, Antonio Ruiz and Manuel Resinas, because this thesis is the result of their encouragement, guidance and support. Thanks Antonio, for being not only my supervisor, but also my personal coach, for encouraging me in the tough times and helping me to get the best of myself. Thanks for your useful advice on both, work and life. Thanks Manolo, because you have been my guide in the research world from the beginning, when you taught me how to write research papers; but above all, thanks for teaching me that there is no mountain high enough so as not to be scaled. My fellow researcher of the ISA group also deserve a big thanks because, in one way or another, they contributed to this thesis. In particular I am grateful to Cristina Cabanillas, for being my travelling companion all these years; to Guti, for being by my side every day and giving me support and advice; to Amador Durán and Beatriz Bernárdez, for our fruitful discussions and their feedback to my work; to Pablo Trinidad, for his willingness and assistance with the technical aspects of this thesis; and to the rest of members of the ISA group, for their companionship and great help along this time. I also want to show my gratitude to other members of the Department of Computer Languages and Systems, especially to Alejandro Fernández-Montes, for making more bearable the long hours of work with his coffee breaks. This thesis has also fed off the insights and directions of colleagues from other universities and research centres. I must express special gratitude to Professor Mathias Weske, who welcomed me warmly in his lab during my research stay in Potsdam, and provided me extensive feedback during my thesis time. Por último unas palabras de agradecimiento en español. Gracias a mi familia, mis padres, mis hemanos, mi abuela, etc., por estar siempre ahí. Especialmente, gracias mamá y papá, por enseñarme la cultura del esfuerzo, por confiar plenamente en mis posibilidades, por apoyarme siempre en mis decisiones, y por no escatimar en sacrificios para hacer posible esta tesis. Gracias también a mi familia política, y en especial a Lili, por cuidar de Nachete como si fuera yo. Y gracias a mis amigos, que han entendido mis ausencias en estos últimos meses. Sin su ayuda y apoyo, esta tesis sería inimaginable. Finalmente, y lo más importante, gracias a VOSOTROS que de verdad me habéis dado aliento. Gracias Nachete, mi bichito pelirrojo, por arrancarme sonrisas cuando apenas quedaban fuerzas. Y sobre todo, gracias Rafa, porque esta es “nuestra” tesis. Sin ti, sin tus ideas, sin tu apoyo, sin tus largas horas de paciente espera, sin tu amor, esto no habría sido posible. Adela del Río Ortega June 2012 ii ABSTRACT iii A key aspect in any process-oriented organisation is the evaluation of process performance for the achievement of its strategic and operational goals. Process Performance Indicators (PPIs) are a key asset to carry out this evaluation, and, therefore, having an appropriate definition of these PPIs is crucial. After a careful review of the literature related and a study of the current picture in different real organisations, we conclude that there not exists any proposal that allows to define PPIs in a way that is unambiguous and highly expressive, understandable by technical and non-technical users and traceable with the business process (BP). Furthermore, it is also increasingly important to provide these PPI definitions with support to automated analysis allowing to extract implicit information from them and their relationships with the BP. This information can assist process analysts in the definition and evolution of PPIs, as well as in the evaluation and optimization of the BPs associated. The challenge we face in this thesis is to devise a set of techniques and tools to allow such an advanced definition of PPIs and their subsequent automated analysis. In order to face this challenge we first propose a metamodel that allows unambiguous and highly expressive PPI definitions, as far as we know, it supports PPI definitions that could not be expressed yet, i.e. PPIs not only related to time or control flow, supported by most existing approaches, but also those related to the state of BP elements and to the content or certain restriction of Data, among others. Regarding the understandability, we propose a BPMN-like graphical notation and a set of templates and linguistic patterns inspired in successful approaches from the requirements engineering field. Both representations rely on the metamodel and can be automatically mapped from one to each other. Furthermore, we provide an automatic semantic mapping from the metamodel to Description Logics, that allows the implementation of design-time analysis operations in such a way that DL reasoners’ facilities can be leveraged. Finally, we have developed PPINOT tool suite, providing support for all these contributions, as well as the possibility to extract the information required to calculate PPI values from Activiti, an open source BP management platform. iv RESUMEN v La medida del rendimiento de los procesos es un aspecto esencial en cualquier organización orientada a procesos para la consecución de sus objetivos operacionales y tácticos. Un elemento clave para llevar a cabo esta evaluación son los indicadores de rendimiento de procesos (Process Performance Indicators-PPIs), y por ello, es crucial disponer de una definición apropiada de estos PPIs. Tras una revisión pormenorizada de la literatura relacionada y el estudio de la situación actual en diversas organizaciones, concluimos que no existe ninguna propuesta que permita definir PPIs de forma no ambigua y altamente expresiva, entendible por parte de usuarios técnicos y no técnicos, y trazable con los procesos de negocio (Business Process-BP). Además, cada vez resulta más importante dotar a estas definiciones de PPIs de soporte para su análisis automático, permitiendo la extracción de información implícita sobre ellos y sobre su relación con lo elementos del BP. Esta información permite asistir a los analistas de procesos en la definición y evolución de los PPIs, así como en la evaluación y optimización de los BPs asociados. El desafío que abordamos en esta tesis es desarrollar un conjunto de técnicas y herramientas que permitan esta definición avanzada de PPIs y su consiguiente análisis automático. Para abordar este desafío, proponemos un metamodelo que permite definiciones no ambiguas y altamente expresivas; hasta donde sabemos, permite definir PPIs que hasta ahora no se podían, soportando PPIs no sólo relacionados con el tiempo y el flujo de control, soportados por la mayoría de las propuestas existentes, sino también aquellos relacionados con el estado de los elementos del BP y el contenido o determinada restricción de los datos, entre otros. Con respecto a la comprensibilidad, proponemos una notación gráfica compatible con BPMN, y un conjunto de plantillas y patrones lingüísticos, inspirados en exitosas propuestas del ámbito de la ingeniería de requisitos. Ambas representaciones están basadas en el mencionado metamodelo y pueden transformarse automáticamente de una a la otra. Además, proporcionamos una transformación semántica del metamodelo a lógicas descriptivas (DL), que permite la implementación de un conjunto de operaciones de análisis en tiempo de diseño, de forma que podemos aprovechar las facilidades proporcionadas por los razonadores de DL. Finalmente, hemos desarrollado una herramienta, PPINOT Tool Suite, que proporciona soporte para las contribuciones introducidas anteriormente, así como la posibilidad de extraer la información necesaria para calcular los valores de los PPIs a partir de Activiti, una plataforma de gestión de BPs. CONTENTS 10.2.2 PPINOT Template Editor . . . . . . . . . . . . . . . . . . . . . . . . . 137 10.2.3 PPIAnalyser ............................... 138 10.3 Real Application Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 10.3.1 Experiment................................ 139 10.3.2 Casestudies................................ 140 10.4Summary ..................................... 143 IV Final Remarks 145 11 Conclusions and Future Work 147 11.1Conclusions.................................... 147 11.2SupportforResults................................ 148 11.3 Discussion, limitations and extensions . . . . . . . . . . . . . . . . . . . . . . 149 11.4Otherfuturework................................. 150 V Appendices 153 A DL In a nutshell 155 A.1 DescriptionLogics ................................ 155 A.1.1 Description Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 157 A.2 OWL ....................................... 157 B PPI Definitions for the RFC Management Process 163 B.1 PPI Specification according to PPINOT Metamodel . . . . . . . . . . . . . . . 163 B.2 PPINOT Graphical Representation . . . . . . . . . . . . . . . . . . . . . . . . 169 B.3 PPIandScopeTemplates............................. 169 xii CONTENTS C Experiment Material 181 C.1 Theory and Practice Self-Assessment . . . . . . . . . . . . . . . . . . . . . . 181 C.2 PPINOT Graphical Notation Poster . . . . . . . . . . . . . . . . . . . . . . . . 181 C.3 BPMNQuestionnaire............................... 183 C.4 PPIQuestionnaire................................. 187 D Acronyms 213 Bibliography 215 xiii CONTENTS xiv LIST OF FIGURES xv 2.1 Simple business process example (process of submitting a paper to a conference) 15 2.2 Business process management lifecycle as described by Weske in [105] . . . . 16 2.3 Different views and roles involved in a BPMS . . . . . . . . . . . . . . . . . . 18 2.4 Typical parts of a BPMS (picture taken from [69])................ 19 3.1 Measuring performance in an organisation (PPIs and KPIs) . . . . . . . . . . . 26 3.2 PPIsvsKPIs ................................... 26 3.3 PPI management lifecycle integrated into the BPM lifecycle . . . . . . . . . . 28 4.1 Excerpt of an EPC process model example with measurement points, taken from [49] ..................................... 34 4.2 PPI tree example, taken from [49] ........................ 34 4.3 Metric dependency Pattern for Duration of Activities [51]............ 35 4.4 PPI specification using Momm et al. approach, taken from [54]......... 36 4.5 PPI definition examples according Wetzstein et al., taken from [107]...... 37 4.6 WSML logical expression example according Wetzstein et al., taken from [107] 38 4.7 MMC specification for a loan process, taken from [39] ............. 38 4.8 PPI example according to Popova et al. approach [77].............. 39 4.9 PPI relationships example according to Popova et al. approach [77]....... 40 4.10 Indicators graph example according to Barone et al.’s approach, taken from [4] 41 4.11 BAM model for cycle times according Friedenstab et al., taken from [33] . . . 42 LIST OF FIGURES 5.1 Process of the request for change management . . . . . . . . . . . . . . . . . . 49 5.2 Kiviat diagram: level at which the related approaches overcome the existing problems ..................................... 56 6.1 PPIs in PPINOT Metamodel . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2 PPIdimensions .................................. 64 6.3 Measure definition in PPINOT Metamodel . . . . . . . . . . . . . . . . . . . . 65 6.4 Filterdefinition .................................. 69 6.5 Kiviat diagram for the problems overcome by PPINOT Metamodel . . . . . . . 70 7.1 PPINOT Graphical Notation (overview) . . . . . . . . . . . . . . . . . . . . . 73 7.2 PPIexample.................................... 74 7.3 Linear time measure example . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.4 Cyclic time measure example . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.5 Countmeasureexample.............................. 76 7.6 State condition measure example . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.7 DataProperty condition measure example . . . . . . . . . . . . . . . . . . . . 77 7.8 Datameasureexample .............................. 78 7.9 Aggregated measure example . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.10 Aggregated measure example . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.11 Derived instance measure example . . . . . . . . . . . . . . . . . . . . . . . . 81 7.12 Derived process measure example . . . . . . . . . . . . . . . . . . . . . . . . 82 7.13 IsGropuedBy example corresponding to the CountAggregatedMeasure “number of RFC registered per project” . . . . . . . . . . . . . . . . . . . . . 86 7.14 Kiviat diagram for the problems overcome by PPINOT Graphical Notation . . . 95 8.1 Mapping: from the user view to the computer view . . . . . . . . . . . . . . . 108 xvi LIST OF FIGURES 8.2 Mapping of PPI template to PPINOT metamodel . . . . . . . . . . . . . . . . 109 8.3 Mapping of AP template to PPINOT metamodel . . . . . . . . . . . . . . . . . 110 8.4 Kiviat diagram for the problems overcome by PPI Templates and L-patterns . . 111 9.1 Kiviat diagram for the problems overcome by the catalogue of automated analysisoperations .................................. 131 10.1 PPINOT component model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 10.2PPINOTscreenshot................................ 137 10.3PPINOTscreenshot................................ 138 10.4 Correct answers in % according to the previous BPMN knowledge . . . . . . . 141 10.5 Correct answers in % according to the difficulty of the process model . . . . . 142 10.6 Kiviat diagram for the problems overcome by PPINOT Tool Suite . . . . . . . 144 11.1 Kiviat diagram for the problems overcome by the set of contributions presented inthisdissertation................................. 148 11.2 Publications grouped by type and topic . . . . . . . . . . . . . . . . . . . . . . 149 11.3 Kiviat diagram for the problems overcome by the catalogue of automated analysisoperations .................................. 151 A.1 DLsummary ................................... 158 B.1 PPINOT Graphical Representation of PPIs 1 to 4 . . . . . . . . . . . . . . . . 169 B.2 PPINOT Graphical Representation of PPIs 5 to 8 . . . . . . . . . . . . . . . . 170 C.1 PPINOT graphical Notation Poster . . . . . . . . . . . . . . . . . . . . . . . . 182 xvii LIST OF FIGURES xviii LIST OF TABLES xix 5.1 PPIs defined for the RFC management process . . . . . . . . . . . . . . . . . . 50 5.2 Comparison of the analysed approaches and our proposal . . . . . . . . . . . . 57 7.1 Attributes of PPIs ................................ 74 7.2 Attributes of BaseMeasures .......................... 75 7.3 Attributes of TimeMeasures .......................... 75 7.4 Attributes of AggregatedMeasures ..................... 78 7.5 Attributes of DerivedMeasures ....................... 80 7.6 Attributes of Time Connectors ....................... 83 7.7 Attributes of Applies To ........................... 85 7.8 Attributes of IsGroupedBy ........................... 86 7.9 Attributes of Uses ................................ 87 7.10 PPINOT Connection Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.11 Compliance with requirements and principles by PPINOT notation (I) . . . . . 89 7.12 Compliance with requirements and principles by PPINOT notation (II) . . . . . 90 7.13 subset of PPIs defined for the RFC management process . . . . . . . . . . . . 92 8.1 Template for PPI specification . . . . . . . . . . . . . . . . . . . . . . . . . . 99 8.2 PPI specification example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.3 Template for the Scope (S) specification . . . . . . . . . . . . . . . . . . . . . 102 8.4 Example of an scope definition . . . . . . . . . . . . . . . . . . . . . . . . . . 103 LIST OF TABLES 8.5 PPI specification example (defined over a derived process measure) . . . . . . 106 9.1 BP elements involved in a PPI . . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.1 OWL DL (class and property) axioms and facts . . . . . . . . . . . . . . . . . 160 A.2 OWLclassconstructors.............................. 161 B.1 PPI template for PPI1 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 171 B.2 S-1scopedefinition................................ 171 B.3 PPI template for PPI2 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 172 B.4 PPI template for PPI3 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 173 B.5 PPI template for PPI4 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 174 B.6 PPI template for PPI5 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 175 B.7 S-2scopedefinition................................ 175 B.8 PPI template for PPI6 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 176 B.9 S-3scopedefinition................................ 176 B.10 PPI template for PPI7 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 177 B.11S-4scopedefinition................................ 177 B.12 PPI template for PPI8 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 178 B.13 PPI template for PPI9 from Table §5.1 . . . . . . . . . . . . . . . . . . . . . . 179 xx PREFACE PART I CHAPTER 1. INTRODUCTION pleteness, and high expressiveness; while it enables the straightforward transformation from one to eachother. Acatalogue of analysis primitives operations is provided in order to derive, at designtime, relationships between PPIs and BP elements, and between PPIs themselves. Furthermore, a semantic mapping of PPINOT metamodel to Description Logics (DL) is defined in order to provide an implementation of the aforementioned analysis operations, taking advantage of DL reasoners to infer the required knowledge from PPI definitions. Asuite of tools (PPINOT Tool Suite) has been developed in order to support the above contributions. It consists of a graphical editor, a template editor and an analyser. It also provides the possibility to extract the information required to calculate PPI values from Activiti, an open source BP management platform, and to create reports with these values. 1.6 THESIS CONTEXT This thesis has been developed in the context of the research group Applied Software Engineering (Ingeniería del Software Aplicada-ISA) of the Universidad de Sevilla, and it opens a new research line within the BPM area. The work that has made this thesis development possible is in the context of the following research projects and networks: • ISABEL: Ingeniería de Sistemas Abiertos Basada en LínEas de productos. Proyecto de excelencia de la Junta de Andalucía, referenced as TIC-2533. In the context of this project I was awarded a four-year grant for the development of my PhD thesis, and it set the basis for starting the work related to the first research question (the appropriate definition of PPIs). • S-Cube: the European Network of Excellence in Software Services and Systems, funded by the European Commission from 01.03.2008 to 29.02.2012. Thanks to our participation in this network, we identified the need to provide PPI definition with automated analysis. • SETI: reSearching on intElligent Tools for the Internet of services. CYCIT project referenced as TIN2009-07366. In this project we investigated the use of techniques from artificial intelligence (DL reasoning) to address the implementation of the aforementioned automated analysis. 8 1.7. STRUCTURE OF THIS DISSERTATION 1.7 STRUCTURE OF THIS DISSERTATION This dissertation is organised as follows: Part I: Preface. It comprises this introduction chapter, in which we introduce our research context, motivate our thesis by presenting the problems addressed, establish our goals and summarise our contributions to fulfill them. Part II: Background Information. It provides the reader with information regarding the research context in which our work has been developed. In Chapter §2, we introduce the main concepts of BPM, and the treatment these concepts have received in the literature. In Chapter §3, we delve into the Process Performance Management (PPM) concept and present a summary of the most relevant approaches in the context of the definition and automated analysis of PPIs. Part III: Our Contribution. This part is the core of our dissertation and is organised in six chapters. Chapter §5 describes the problems that motivated our research work in this dissertation, analyses current solutions, and concludes that current proposals for supporting the design and instrumentation phases of the PPIM lifecycle (including automated analysis) have a number of drawbacks. In Chapter §6 we present a metamodel (PPINOT metamodel) for the definition of PPIs, that is useful along the whole PPI lifecycle. In Chapter §7 we propose a graphical notation to depict PPIs over BP models based on this metamodel. Chapter §8 provides a set of PPI-templates and L-PATTERNs, based on PPINOT metamodel, that use natural language to define PPIs, making such a definition available to non-technical users.In Chapter §9 we define a set of analysis operations to extract information at design-time from PPI definitions and present a formalisation of the PPINOT metamodel using DL that allows to implement the aforementioned analysis operations. Finally, in Chapter §10 we present PPINOT tool suite, that provides support for the previous contributions and describe the real scenarios where our approach implemented in PPINOT tool suite has been applied. Part IV: Final Remarks. It concludes this dissertation and highlights some future research directions in Chapter §11. Part V: Appendices. Appendix §A provides a brief introduction to DL and OWL-DL. The specification of the set of PPIs defined in our motivating scenario is presented in Appendix §B, using the different notations presented: the PPINOT metamodel (using a textual notation), our graphical notation and PPI-templates and patterns. Finally, Appendix §C shows the material used during the experiment described in Section §10.3.1. 9 CHAPTER 1. INTRODUCTION 10 BACKGROUND INFORMATION PART II 2 BUSINESS PROCESS MANAGEMENT 13 "If you can’t describe what you are doing as a process, you don’t know what you are doing." W. Edwards Deming (1900 – 1993), American statistician and professor BPM can be seen as both, a management principle and a suite of software technologies for the management of the lifecycle of BPs. In this chapter we introduce the main concepts of BPM. In Section §2.1 we introduce the BPM concept. We delve into BPs and their role in BPM in Section §2.2. Section §2.3 describes a BPM lifecycle as a way to provide a comprehensive view of the concepts and technologies relevant for BPM. We pay special attention to the modelling of BPs as a core activity in BPM, presenting some notations in Section §2.4. Finally, Section §2.5 summarises the chapter. CHAPTER 2. BUSINESS PROCESS MANAGEMENT 2.1 INTRODUCTION Business Process Management (BPM) aims at offering a high level managerial perspective of organisations. It can be seen as a principle to manage businesses: A company provides to the market products or services, which are the outcome of a number of activities performed. Business processes are the key instrument to organise these activities and to improve in general their relationships [105]. BPM is gaining increasing interest from both academia and business. Many companies are taking this process-oriented perspective in their business, as a way of identifying which steps really create value, who is involved in the process and which is the exchanged information; ultimately, finding out how to improve, where to increase quality, reduce waste or save time [1]. According to van der Aalst et.al., BPM can be defined as “supporting business processes using methods, techniques, and software to design, enact control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information” [98]. The goal of this chapter is to provide an overview of the major concepts of BPM, focusing on those aspects that are most interesting and useful for this dissertation. 2.2 BUSINESS PROCESSES Weske states in [105] that “BPM has its root in the process orientation trend of the 1990s, where a new way of organizing companies on the basis of Business Processs (BPs) was proposed”. Hammer et.al. define a business process as a collection of activities that take one or more kinds of input and create an output that is of value to the customer [41]. They do not consider any relationship or constraint between this collection of activities, but Davenport does it in [17], where he defines a business process as “a set of logically related tasks performed to achieve a defined business outcome for a particular customer or market”. He also takes into account this relationship between process activities when he defines a business process as “a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs” and continues “business process have customers (internal or external) and they cross organizational boundaries”. Based on these definitions, Weske defines a business process as “a set of activities that are performed in coordination in an organizational and technical environment. These activities jointly realize a business goal. Each business process is enacted by a single organization, but it may interact with business processes performed by other organizations” [105]. 14 2.2. BUSINESS PROCESSES process of writting a paper Research Group supervisor supervisor review paper propose corrections author author write paper ask for review implement corrections new review required? submit paper to conference yes no Adela del Río 1 of 1 12.04.2012 Figure 2.1: Simple business process example (process of submitting a paper to a conference) As simple example of BP we propose the (simplified) process of submitting a paper to a conference depicted in Figure §2.1. The goal is to submit the paper with the highest possible quality (in such a way that it can be accepted). In this example we can see the set of activities that allows to realize such a goal. The coordination between these activities is defined by the ordering constraints described in the model. Though it is not reflected in the model of Figure §2.1, this BP also interacts with other BPs, for instance the one defined by the conference organization in order to receive the papers submitted and redirect them to the reviewers (not depicted in the Figure). In this example we can identify some of the five dimensions of BPs [19,29]. (1) The functional dimension describes the activities to be performed in a BP. (2) The behavioural dimension specifies the control flow dependencies between these activities, e.g. the paper must be written before it can be reviewed. (3) The organisational dimension focuses on the people, roles or organisational units involved, e.g. the author or the supervisor. (4) The informational dimension defines the information that must be produced or consume by activities, i.e. the data flow, e.g. the paper document is required during the review paper activity. (5) Finally the technical dimension makes reference to the different tools or machines that may be required in order to perform certain activities, e.g. the activity of submitting the paper to the conference is not feasible if no computer and internet connection (between others) are available. As stated in [105] and [19] the basis of business process management is the explicit representation of business processes, since it helps to discover weaknesses in the current organisation of activities and serve as starting point to be analised and improved. Furthermore, “process documentation serves educational purposes–new employees entering the organization can quickly 15 CHAPTER 2. BUSINESS PROCESS MANAGEMENT take up how things are done, or during organizational change programs, it can be shown how activities should be carried out in the new way” [19]. Nevertheless the BPM also comprises other activities as described in BPM lifecycle presented in the following section. 2.3 BUSINESS PROCESS MANAGEMENT LIFECYCLE In the literature there is no consensus about the number and the name of the phases in the BPM lifecycle. They vary depending on the granularity for identifying the phases and the way of grouping the functionality in the different phases [64,97,98,105,106]. In this work we will present the BPM lifecycle desribed by Weske in [105]. He proposes the four-phase BPM lifecycle depicted in Figure §2.2 Business Process Management •!System Selection, Implementation, Test & Deployment •!Operation, Monitoring & Maintenance •!Design: BP Identification & Modelling •!Analysis: Validation, Simulation & Verification •!Process Mining & BAM Evaluation Design and Analysis Configuration Enactment Figure 2.2: Business process management lifecycle as described by Weske in [105] This lifecycle starts with the Design and analysis phase. If no process exists, the goal of this phase is to define a new one; but if there is already an existing process, then the goal is to create an alternative for the current process. The new process need to be identified based, in the first case, on surveys on the organisational and technical environment, and in the second case, on the identified improvement possibilities. In either case, the informal business process description is translated to a particular business process modelling notation (usually a graphical 16 2.3. BUSINESS PROCESS MANAGEMENT LIFECYCLE one). Once a BP is defined, it need to be validated to check whether all valid process instances are reflected by its corresponding business process model. Furthermore, simulation techniques can help during the validation by allowing to detect possible undesired execution sequences and also to verify that the process actually exposes the desired behaviour. Finally, verification techniques allow to check correctness properties. Once the business process model is designed and verified, it needs to be implemented. This is done during the configuration phase. It can be done in different ways. If a set of policies and procedures that the employees of the enterprise need to comply with are used to implement it, no system is required. However, if a dedicated software system is needed, it must be selected and configured in order to take into account the interactions of the employees with the system and the integration with existing software systems. This integration with existing systems may involve some implementation work, for instance to attach legacy system to the Business Process Management System (BPMS). Finally this configuration must be tested, where traditional testing techniques from the software engineering area can be applied, and deployed in its target environment. Next phase is the enactment, that encompasses the run time of the business process. On the one hand, a correct orchestration is necessary for the business activities to be performed according to the business process’s execution constraints. On the other hand, process monitoring is an important mechanism for providing information about the status of running business process instances (BAM techniques [26] are used for this purpose). During this phase, valuable execution data is gathered. Typically execution logs are used to orderly storage information about processes such as the start or the end of activities. Finally, the evaluation phase uses information collected to evaluate and improve business process models and their implementations. Techniques from the fields of business process intelligence [40], and hence, process mining [102,103], data warehousing and classical data mining are applied in this phase (). Note that there not exists a strict temporal ordering in which these phases need to be executed; incremental and evolutionary approaches involving concurrent activities in multiple phases are, thus, common. 2.3.1 Business Process Management System All these phases of the BPM lifecycle must be supported by BPM products (see Figure §2.3). These software products are called BPM suites or Business Process Management Systems (BPMSs). They are supposed to provide an integrated set of tools to model, simulate, 17 CHAPTER 3. PROCESS PERFORMANCE MANAGEMENT 3.1 INTRODUCTION As stated in the previous chapter (Section §2.1) BPM is used, among others, as a way of finding out how to improve BPs, i.e., it assists in the BPs optimisation. To achieve this improvement, it is essential to evaluate the performance of business processes, since it helps organisations to define and measure progress towards their goals. This is the main objective of PPM. According to Heß [42], PPM aims at optimizing the process sequences at work in the company through computer-supported analysis of process structures in conjunction with KPIs, so as to organize them more effectively. Furthermore they consider PPM as the heart of a wider concept called Corporate Performance Management (CPM), or also known as Business Performance Management or Enterprise Performace management. The phrase CPM was coined by Gartner Group to describe the combination of “processes, methodologies, metrics and technologies to measure, monitor and manage the performance of the business” [9]. Nowadays, CPM is used to denote all the long-term, process-oriented modes of action and approaches that have been adopted in companies for the management of BP performance , including dynamic methods such as activity-based cost calculation, the process BSc or process mining as well as static process analysis. In this chapter we provide some concepts related to this issue that are connected with the work developed in this dissertation. 3.2 HISTORIC EVOLUTION OF PPM Similar to other past trends in information systems and business management, PPM has evolved. Traditionally, PPM (or probably more accurate for its beginning, business performance management) focused on the strategic and tactical level (enterprise-oriented), most frequently taking into account only financial measures and using data-driven techniques. Here we can include several approaches: the Activity-Based Costing (ASC) [8,62,95], which relates resource costs to activities, products and services, giving a realistic view on the overall costs and profitability of the organisation; Competitive Benchmarking, which consists on a continuous process of comparing a firm’s practices and performance measures with that of its most successful competitor/s.[82,108]; or the Balance Scorecard of Kaplan and Norton [7,45,46], that provides a system to describe an organisation’s overall performance using financial and non financial indicators. From the point of view of the software support for this kind of performance management, we can highlight systems or techniques such as Decision Support Systems (DSS),Executive information systems (EIS) or Business Intelligence (BI) projects that used Data Warehouse and OLAP tools [34,104] 24 3.3. PROCESS PERFORMANCE INDICATORS This approach has recently changed with the evidence that “analysis must be linked more closely with the company’s value creation. Traditional Business Intelligence Systems are being replaced by process-oriented Performance Management Solutions” [42], i.e. now the focus is on processes and the spectrum of performance-relevant data is broader, since financial and non-financial measures (operational data) are taken into account [38,50]. The main objective now is “to set up an overall view of the company’s core processes and to establish a cycle for continuously improving process efficiency” [49]. 3.3 PROCESS PERFORMANCE INDICATORS According to A. Kronz in [49] “collecting and analyzing performance-related KPIs is the first prerequisite for holistic process management and form the basis for consistent and continuous process optimization”. Later on he also claims that “the basis for all process controlling is a process-oriented KPI system that links the process perspective to the essential controlling aspect of the business. KPIs must enable conclusions to be drawn regarding the effectiveness of the processes and their efficiency”. Hence, PPIs (process oriented KPIs according to the previous citation) become first-calls citizens in BPM since they serve as the basis for the sustained success of the project [89]. Process Performance Indicators (PPIs) can be defined as quantifiable metrics that allow to evaluate the efficiency and effectiveness of business processes. They can be measured directly by data that is generated within the process flow and are aimed at the process controlling and continuous optimization [14]. Often, the terms PPIs and KPIs are used interchangeably, but, in fact, there is no consensus in the literature regarding the relationship between PPIs and KPIs. Some authors do not establish any difference between them [55,76,77], while others (see [22,107] for instance) consider PPIs as a particular case of KPIs, i.e. process-related KPIs. Finally, there are others who attribute different definitions to each one, placing them at different levels, KPIs nearest to the tactical and strategical level, while PPIs nearest to the operational level [14]. Our approach in this dissertations coincides with the second one, i.e., we consider PPIs as a particular case of KPIs defined for measuring the performance of BPs. A set o KPIs are defined for the organisation as a way of measuring the level of fulfillment of its strategic and operational objectives. Furthermore, the operation of such organisation is defined by means of a set of BPs, whose performance are measured through PPIs. Taking to account this picture, depicted in Figure §3.1, every PPI is a KPI, but not vice versa, though, every KPI can become 25 CHAPTER 3. PROCESS PERFORMANCE MANAGEMENT Process Performance Indicator KPI1 KPIn ! BPn BP1 ! PPI1-1 PPI1-n ! PPIn-1 PPIn-n ! Figure 3.1: Measuring performance in an organisation (PPIs and KPIs) a PPI if a BP is defined and used to calculate it, and it allows to improve the defined BP. Figure §3.2 illustrates this relationship PPI-KPI. There are two PPIs defined for the process example of Section §2.2, the paper submission, and two examples of KPIs for a research group, considering it as an organisation example. It can be seen that, although both KPIs are somehow related to the process of submitting a paper, they cannot be measured from its execution data. PPI vs KPIs KPIs PPIs number of RFCs per project % papers that require a 2nd review Paper with JCR >=1.5 accepted Figure 3.2: PPIs vs KPIs In order to define PPIs, it is recommended that they satisfy the SMART criteria [24,53,91]. SMART is a nemonic used to set objectives and KPIs/PPIs. There is no clear consensus about what the five keywords mean. In this thesis we consider the following meaning: Specific (it has to be clear what the PPI exactly describes), Measurable (it has to be possible to measure a current value and to compare it to the target one), Achievable (it makes no sense to pursue a goal 26 3.4. PPI MAGEMENT LIFECYCLE that will never be met), Relevant (it must be aligned with a part of the organisation’s strategy, something that really affects its performance) and Time-bounded (a PPI only has a meaning if it is known the time period in which it is measured). Furthermore, as stated in [49], “it is imperative to establish a clear connection between the process and its PPIs, without which it is practically impossible to interpret the PPIs or derive any meaningful measures” 1. In order to establish such a connection, it is convenient to integrate the management of PPIs into the whole BPM lifecycle [21,22,49], providing thus the aforementioned cycle for continuously improving process efficiency. 3.4 PPI MAGEMENT LIFECYCLE During our research work we identified the challenges to integrate the PPI management into the BPM lifecycle, analysing related work (see [21]). For the sake of simplicity we present here a summary of such work, whose approach coincides in some aspects with the one presented in [49]. We take as starting point the BPM lifecycle presented in Section §2.3 to define a PPIM lifecycle as follows. As stated in the introduction Chapter (§1), it is desirable to define a lifecycle for the PPI management and to integrate it into the BPM lifecycle for several reasons: first of all, PPIs management needs are quite similar to the ones of BPs, also identifying for them several phases, so it makes sense to define a PPIM lifecycle; on the other hand, though PPIs are closely related to BPs, they are not intrinsic to their definition and management, so this PPIM lifecycle must be independent; finally, the main benefit of integrating this PPIM lifecycle into the BPM lifecycle is that PPIs become firts-class citizen in process-oriented organisations, enabling thus a proper evaluation and optimisation of BPs. In the following, we present our PPIM lifecycle, depicted in figure §3.3. It coincides in some aspects with the one presented in [49]. It is divided into four phases, each of which is integrated in one of the phases of the BPM lifecycle presented in previous chapter as follows. In the Design and Analysis phase of the BPM lifecycle, PPIs should be modelled together with the business process. Here the definition and structure of the PPIs as well as its relationship with the BP must be described. This model of PPIs should also enable their analysis by detecting the dependencies amongst them at design time and also using them as part of the business process analysis, for instance in business process simulation techniques (Simulation attempts to 1we use here PPIs instead of KPIs as done in the cited work to maintain a coherence along the document regarding the terms used. 27 CHAPTER 3. PROCESS PERFORMANCE MANAGEMENT Business Process Management Design Instrumentation Computation Evaluarion Design and Analysis Configuration Enactment Evaluation BPM lifecycle PPIM lifecycle Define PPIs, Connect with BP, design-time analysis Implement measurement points Calculate PPIs’ values and monitor PPIs Identify PPI correlations, conflicts and predict future behaviour Figure 3.3: PPI management lifecycle integrated into the BPM lifecycle “mimic” real-life or hypothetical behavior on a computer to see how processes or systems can be improved and to predict their performance under different circumstances [101]). We call this PPIM lifecycle phase Design. Then, during the BPM lifecycle Configuration phase, the instrumentation of the process necessary to take the measures must be defined. This means to implement measurement points taking into account the implementation and support of the processes by Information Technology (IT) (for instance indicating where data input come from, i.e. data sources like databases of ERP systems or workflow management systems or BPMS). This is the Instrumentation phase. During the Enactment phase of the BPM lifecycle, all important events related to the execution of activities (e.g. start/end of activities, data produced or changed by activities, etc.) are gathered and recorded in log files. Based on these events, the PPIs’ values have to be calculated and the monitoring of these PPIs should be carried out. BAM techniques [26] are used for this purpose (BAM refers to near real time monitoring of business activities, measurement of PPIs, their representation in dashboards, and automatic and proactive notification in case of deviations [97]). These activities make up the Computation phase. Finally, during the BPM lifecycle Evaluation phase, the information available allows to evaluate and improve business process models and their implementations. The monitoring information related to PPIs obtained in the previous phase will help to identify correlations between 28 3.5. SUMMARY them and predict future behaviour. Techniques from the fields of process mining [102,103], business process intelligence [40], data warehousing and classical data mining are applied in this phase (Business process intelligence is based on the application of business intelligence techniques, in particular data/process mining , data warehouse and OLAP tools, to BPs, allowing thus to check conformance, predict the future, recommend appropriate actions and identify improvements points). We also call this PPIM lifecycle phase Evaluation. 3.5 SUMMARY In this chapter we have highlighted the importance of Process Performance Management (PPM) inside the business process orientation. We have introduced the main concepts related to PPM, that establish the context for our main contributions in this dissertation. In particular we have presented its historic evolution until arrive to the current picture, where, in order to achieve a holistic process management, it is crucial to integrate PPIs and their management into the whole BPM lifecycle. Finally we have also described the PPIM lifecycle that results of such integration. 29 CHAPTER 3. PROCESS PERFORMANCE MANAGEMENT 30 4 STATE OF THE ART 31 In my walks, every man I meet is my superior in some way, and in that I learn from him. W. Somerset Maugham (1803 – 1882), American essayist, lecturer and poet In this chapter we survey the current proposals in the context of the desing and instrumentation phases of the PPIM lifecycle. Between Section §4.2 and Section §4.11 we describe those approaches that have more relevance to our work, or that more influenced it, putting special emphasis on the way PPIs are defined, the possible PPIs that are supported and the analysis capabilities provided. Then, in Section §4.12, we comment other approaches somehow related to our work in this dissertation. CHAPTER 4. STATE OF THE ART 4.1 INTRODUCTION Many works have been done in the identification and classification of key performance indicators for any company [44] and those relevant for specific domains such as logistics, production, supply chains, etc. (e.g. [7,13,48,96]). Nevertheless, since in this dissertation we focus on PPIs, and more concretely on the design and analysis phases of the PPIM lifecycle, we are interested in those proposals especially related to them. In this chapter we describe the main approaches identified1, putting especial emphasis on the way PPIs are defined in them, the possible PPIs that are supported and the analysis capabilities provided. A further analysis of these proposals as well as the level of fulfillment of a set of requirements established will be presented in Sections §5.4 and §5.5. 4.2 CASTELLANOS ET AL. APPROACH Castellanos et al.’s approach [12] is implemented in the IBOM platform, that allows, among other things, to define PPIs (they call them business metrics and they are not solely focused on business processes)and perform intelligent analysis on them to understand causes of undesired values and predict future values. The user can define PPIs (through a Graphical User Interface (GUI)) to measure characteristics of process instances, processes, resources or of the overall business operations. Specifically, they characterize PPIs through four attributes: name (unique), target entity (objet to be measured), data type (numeric, boolean, taxonomy or SLA) and desirable values (they define green, yellow and red ranges for values or categories). For the computation logic definition, templates are used. These templates map data and metadata about process executions into numeric and boolean measures. Some examples of templates given in [12] are presented below: A: Did process Pend in state S?(boolean template). B: Total execution time between the activation of step S1 and the completion of step S2 (numeric template). C: Percentage Pof the value of numeric output variable V(numeric template). D: Was step Sexecuted? (boolean template). New templates can be added by the user2. These templates includes, apart from the previous 1The order established between the approaches presented was defined by their date of publication. 2The way these new templates can be defined is not described in this paper, so it is not possible to assure the 32 4.3. ARIS APPROACH specification part, readable by humans, an implementation part, specified in SQL, that contains the code to be executed to compute the value. It is noteworthy that this approach is not focused on business processes but on the whole organisation. 4.3 ARIS APPROACH ARIS [18] models PPIs (process-oriented KPIs for them) and allow for using the Balance Scorecard approach [46] for modelling cause-and-effect relationships and assign PPIs to the strategic objectives. Furthermore, in [88], the ARIS Process Performance Manager (PPM) is described. This tool provides a mechanism to define measurement points over BPs defined using EPCs. A measurement point defines a point in the process at which data is collected for calculating PPIs. It gathers the description of the change of status of application objects (e.g. functions, that is the name for activities in EPCs). If the system contains organisational information related to the process, it can also be gathered by measurement points. Figure §4.1 depicts an excerpt of a process example with measurement points defined, taken from [49]. Then, allocation diagrams allow to define which measurement points are used to calculate each PPI, as well as to link multiple PPIs to a new PPI; i.e they maintain calculation rules for PPIs. This tool also allows to classify PPIs in the so-called trees, in order to group them (e.g. quality, cost, time, or process-oriented groupings). An example of a PPI tree taken from [49] is presented in Figure §4.2. Finally, it also supports the evaluation or analysis of PPIs. This evaluation interprets PPIs with reference to various criteria -called dimensions- (time period; product; region) and describes relationships3between the results and the predefined target values. In addition, the monitoring of PPIs and notification in case of deviations are also supported, as well as some basic process mining techniques can be used to analyse weak points. flexibility of this platform with respect to the PPI values it supports 3It is not defined which kind of relationships. 33 CHAPTER 4. STATE OF THE ART env_influence_on: ENV_CHARACTERISTIC !PI !{pos, neg}: an environmental characteristic of the sort ENV_CHARACTERISTIC influences a performance indicator in a positive or negative way (i.e., contributes to the increase/decrease of a performance indicator). For example, a large amount of rain contributes negatively to the amount and quality of harvest. Other types of relations between performance indicators, processes and roles, related to power, supervision, authorization, etc. are discussed in the organizationoriented view [31]. 6. Performance evaluation Every task in an organization contributes to the satisfaction of one or more organizational goals through performing its process instances. Each goal is formed based on a certain performance indicator(s) which can be measured (directly or indirectly) during or after the process execution depending on the goal evaluation type—in the end or during a certain period of time (evaluation period defined as goal horizon). Data about the actual execution of the processes is recorded by the workflow management system in the form of a trace which can be used for analysis. The satisfaction (degree of satisficing) of the goal(s) is determined by comparing the measured value(s) with the corresponding goal expression (s). Further, the obtained goal satisfaction (satisficing) measure is propagated by applying the rules defined in [39,40], upwards in the goal hierarchy for determining the satisfaction (degree of satisficing) of higher level goals. In particular, the satisfied label is associated with a hard goal refined into an and-list if and only if all goals in this list are satisfied. The propagation mechanisms defined for soft goals are more elaborated and are described in more detail in [39,40]. Thus, the organizational performance is evaluated by determining the satisfaction (degree of satisficing) of key organizational goals. In the following an algorithm for determining the satisfaction (degree of satisficing) of a goal is provided. ARTICLE IN PRESS Fig. 3. The relationships between the performance indicators identified for the case study. V. Popova, A. Sharpanskykh / Information Systems 35 (2010) 505–527514 Figure 4.9: PPI relationships example according to Popova et al. approach [77] uses :GOAL_PATTERN ×PPI_EXPRESSION env_in f luence_on :ENV_CHARACTERISTIC ×PPI × {pos,neg} In addition, these relations are further investigated in [76,78], where they present formal techniques for the analysis of executions of organizational scenarios, and discuss analytic issues for consistency and verification checks of the goal structures and between goals and PPIs, respectively. 4.10 BARONE ET AL. APPROACH Barone et al. present in [4] the Business Intelligence Model (BIM), whose main goal is to allow business users to conceptualise business operations and strategies, and performance indicators, so that they can be connected to enterprise data through automated tools. They propose to define a global view of a company’s workflows and define PPIs on its activities and resources. The set of PPIs defined together with the relationships among them constitute the so-called Indicators Graph. Figure §4.10 shows the indicators graph provided [4] according to its case study. 40 4.11. FRIEDENSTAB ET AL. APPROACH 40 D. Barone et al. Strategic indicators Operational indicators Middle management indicators Stock status (R1) Inventory accuracy (R1) # of orders # of orders rejected # of stock available at customer first request (P2) (R1) Size of safety stock RESOURCES +- Inventory Order Product Package Customer Truck/Cargo R1 R2 R3 R4 R5 R6 Make an order Check availability in stock Accept the order Reject the order Package product(s) Deliver package ACTIVITIES - + P1 P2 P3 P4 P5 P6 Revenue Brand awareness score (G4) Marketing performance audit score (AVG) # of items for each order (P3) (R2) # of orders accepted (G3) (G6) (P4) (R2) (P1) (P3) (R2) (R5) # of products damaged % of truck/cargo load capacity utilized # of products (R3) # of wrong items shipped (P6) # of packages (R3) # of wrong items ordered (P6) # of products returned (R5) Red Orange Green Traffic Light INTENTIONS G1 G2 G3 G4 G5 G6 G7 G8 G9 G10 G11 G12 G13 G14 G15 G16 G17 G18 +- Shareholder value increased Cost decreased Revenue increased Brand image improved Sales improved Marketing improved Supply chain cost decreased Online sales process improved Customer satisfaction maximized Packaging optimized Delivery optimized Packaging cost reduced Delivery cost reduced Delivery (lead) time reduced Packaging of product with defects avoided Packaging time reduced Damages during delivery reduced Management cost reduced Cargo cost per unit shipped Operating costs (G2) Management Cost (G18) Packaging quality index (G10) (P5) Transportation quality index (G11) (P6) Supply chain costs (G7) Online process quality index (G8) Shareholder value (G1) # of products damaged during delivery # of products sold (G5) On time delivery and pickup (G14) (P6) (AVG) Shipment duration (G14) (P6) (G17) (P6) (G13) (R6) # of products with defects (R3) # of products with defects packed (G15) (P5) # of products damaged before/during packaging (G15) (P5) (AVG) Packaging duration (G16) (AVG) Packaging cost (G12) (P5) (G13) (R6) Customer satisfaction index (G9) (R5) Fig. 7. BestTech’s Indicators Graph Figure 4.10: Indicators graph example according to Barone et al.’s approach, taken from [4] 4.11 FRIEDENSTAB ET AL. APPROACH Friedenstab et al. have recently presented in [33] a twofold contribution: on the one hand, a metamodel that extends BPMN in order to include BAM-relevant concepts, including PPIs; on the other hand, a graphical notation for those concepts described in the metamodel. They support the definition of PPIs to measure duration and frequency (the number of times that something happens) of process instances, to compose them by arithmetic operations, and to aggregate them considering a set of instances, delimited by means of the filter. Furthermore, target definitions can be defined for these PPIs and, actions in order to react when these targets are not achieved. Figure §4.11 depicts the BAM model example provided in [33] to define cycle times, according to the case study presented in that work. This work does not provide any mechanism for these PPI definition analysis. 41 CHAPTER 4. STATE OF THE ART !"#$" "$%$&'$# !"#$" ($)# *"#$" %*)+&",-.&*) /$%$&0. !"# $%&'% (' )*+),++'&- .'/ 0$ !"#$" %*,01$.$# 2**#3 "$%$&'$# 4"*%$33 *"#$" 45"%6-3$ *"#$" 0"*%$33 7)-189$ *"#$" !'$"-11 %8%1$ .&,$ !" !"# 7'$"-:$ %8%1$ .&,$ ;8%1$ .&,$3 #-36<*-"# (6&0 :**#3 =$>0"$33? (6&0 :**#3 =3.-)#-"#? ;*,0-)8@&).$")-1 0-". !"AB 6 C-3. *"#$"3 %8%1$ .&,$ DE F)3.-)%$3 !!! GH$'&-.&*)I H$+-51.J K*I 4"*%$33 !L)$" #$%&'()&"*+*,&"-./& -<*'$ 1&,&.M0 4-".&-1 %8%1$ .&,$ $% &' (' 4$"%$).-:$ 4-".&-1 %8%1$ .&,$ N !'$"-11 %8%1$ .&,$ !" !"# 7'$"-:$ 0$"%$).-:$ 7'$"-:$ %8%1$ .&,$ O AB 6 )(.-.$ P ;*,01$.$# Figure 11. BAM model: cycle times Process Section is needed to describe the company-internal part of the business process. In particular, the Start Marker is attached to the ‘Analyze Order’ Sub Process, while the End Marker is connected with the ‘Process Order’ Sub Process. To measure the cycle time of this Process Section, it is connected with a Duration measure which reuses the abovedescribed Filter to include only successfully completed processes. Though, not the cycle time of the Process Section itself, but its percentage with respect to the cycle time of the overall process is required. Therefore, a Composed Basic Measure has to be applied that relates both measures to each other. Finally, this measure is aggregated and connected with the cycle times Dashboard. (3) Cycle times of the last 50 orders. For the third timerelated measure, another Duration element is necessary. This has to be supplemented by a Filter element that specifies a Quantitative Limit, since only the last 50 process instances should be regarded. As the cycle times are supposed to be visualized, the Duration element is also connected with the above mentioned Dashboard. IV. REVIEW OF RELATED APPROACHES AND DISCUSSION When proposing a new modeling method, there is a need to demonstrate its “worthiness” against the background of the “blooming production” of modeling methods [17]. We therefore subsequently review the state-of-art in BAM modeling and will then discuss our approach against the identified body of methods. A. Review of related approaches DEL-R´ IO-ORTEGA,RESINAS and RUIZ-CORT´ ES strive for a better integration of Process Performance Indicators (PPIs) into the business process lifecycle (definition, execution, analysis). PPIs should be modeled together with the business processes. Thus, they present an ontology to define PPIs which comprises a comprehensive classification of PPIs and explicitly defines how the PPIs are related to elements of a BPMN business process model (e.g., data objects or activities) [5]. Due to the clear orientation to BPMN, the authors provide a valuable contribution for closer integration of business process modeling and monitoring aspects. However, while a connection between BPMN constructs and PPIs is established, a graphical notation to include the measures into process models is missing. Further, the sole definition and modeling of process metrics is of limited value in a BAM context as threshold values and the corresponding exception handling mechanisms need to be expressed as well. A related approach that connects process KPIs and process models is provided by WETZSTEIN,MAand LEYMANN who propose a semantic framework for BAM which aims !"#!!"#! Figure 4.11: BAM model for cycle times according Friedenstab et al., taken from [33] 4.12 OTHER RELATED APPROACHES In this section we comment other related approaches more restrictive regarding the definition and analysis of PPIs, or taken form other areas that served as inspiration for the work performed in this dissertation. 4.12.1 GRAI/GIM Approach GRAI [15] is a conceptual model for manufacturing systems that divide them into three subsystems: physical, decision and information systems. Over this conceptual model is build the GIM approach, GRAI Integrated Methodology. Within the modelling formalisms provided by GIM, GRAI Grid [25] is used to build a decision system model. In this formalism, the definition of performance indicators are defined, but not focused on business processes. They establish three parameters or attributes to define performance indicators: name, value domain or dimension and procedure to calculate the value. They also define the relation of these performance indicators with objectives and decision variables. 42 4.12. OTHER RELATED APPROACHES 4.12.2 Soffer et al. Approach Soffer et al propose in [93] a formal framework that defines a process model on the basis of states and state variables. Furthermore, they also define PPIs (referred to as soft-goals) and their relationships to processes and state variables. Criterion functions (any function on the values of state variables) are used to define these PPIs. They put especial emphasis in relating criterion functions and PPIs to processes, so that PPIs are defined over the the appropriate BPs. They apply their approach to the SCOR model and perform a PPI analysis. This analysis allows to identify, among others, which criterion functions are fully dependent on the process, which are partially dependent on it. 4.12.3 Korherr and List Approach Korherr et al. extend in [47] the BPMN and EPC metamodels to define business process goals and performance measures. They only allow the definition of cost, quality and cycle time measures, from which only cycle time measure are explicitly connected to the business process elements. They do not delve into the information required to define such measures and to calculate them. 4.12.4 Costello et al. Approach Costello et al. propose in [16] a model to include the definition of PPIs into process models using XML. They define events associated to what they call process (business activity). These events are mainly intended to the calculation of cycle time PPIs. They also present a mapping of this event-based model to an ontology developed using OWL (the Web Ontology Language). This ontology serves as a basis for defining rules for the calculation of PPI values. Finally, they provide a software implementation called iWISE architecture to support their approach. 4.12.5 García et al. Approach A work somehow related to this area, but focused on software measurement rather than processes is the one presented in [35]. The authors describe in this work a software measurement ontology called SMO. In [57] they also present a graphical notation for the depiction of software measurements, based on SMO. 43 CHAPTER 4. STATE OF THE ART 4.13 SUMMARY In this chapter we have presented those related work that provides partial support for the PPIM lifecycle phases described in previous chapter. We have described the way each proposal address the definition of PPIs and the level of analysis support provided. 44 OUR CONTRIBUTION PART III 5 MOTIVATION 47 The important thing in science is not so much to obtain new facts as to discover new ways of thinking about them. William Bragg (1862–1942), British physicist and Nobel Prize in Physics 1915 Our goal in this chapter is to describe the problems identified during our research and to motivate the contributions provided in this dissertation. We analyse the current solutions and bring attention to the advances we have achieved to solve these problems. In Section §5.1, we motivate our research. Section §5.2 presents a motivating scenario that will be used along the dissertation. In Section §5.3, we present the main problems addressed in this dissertation. In Section §5.4, we analyse the level of compliance of the presented problems by the current solutions found in the literature. In Section §5.5, we resume and compare the information previously obtained and contextualise our contributions. CHAPTER 5. MOTIVATION 5.1 INTRODUCTION Supporting the PPIM lifecycle requires to overcome a number of problems introduced in Chapter §1. The final goal of this chapter is twofold. First, to motivate the need for specifics techniques and tools to improve both the design and the instrumentation phases of the PPIM lifecycle; and to do so we describe in detail the aforementioned problems. Second, to introduce our contributions in this topic, that are the result of an extensive analysis of a variety of PPIs defined by different organisations, a careful study of the related literature, and the application of the knowledge gained in previous experiences with the automated analysis in other areas like feature models and SLAs. We consider these contributions can promote the progress of the discipline both at a technical and a social level. From a technical standpoint the application of DL to the PPI definitions helps to eliminates ambiguities and provides more semantics about some concepts and relationships, and facilitates their automated analysis by leveraging reasoner services available for such a formalism. From a social standpoints, the techniques proposed for defining, representing and analysing PPIs will thrive even more the aforementioned process orientation in organisations. 5.2 MOTIVATING SCENARIO: PROCESS OF THE REQUEST FOR CHANGE MANAGEMENT Our motivating scenario for the work developed in this dissertation is presented in this section. It takes place in the context of the Information Technology Department of the Andalusian Health Service. We particularly focus on the business process of managing Request for Changes for existing Information Systems. This process was modelled by the quality office of this department using BPMN, but due to space and in order to make it easier to understand, we have simplified the real process obtaining the diagram depicted in Figure §5.1. The process starts when the requester submits a Request For Change (RFC). Then, the planning and quality manager must identify the priority and analyse the request in order to make a decision. If the RFC was in the strategic plan or pre-approved, the requester will be asked to submit a release request and the process will continue through the global Project Management Process (PMP). Otherwise, according to several factors like the availability of resources, the requirements requested, and others, the RFC will be either approved, cancelled, raised to a committee for them to make the decision, paralysed or sent to the area manager in order for her to negotiate new requirements. 48 5.2. MOTIVATING SCENARIO: PROCESS OF THE REQUEST FOR CHANGE MANAGEMENT Figure 5.1: Process of the request for change management 49 CHAPTER 5. MOTIVATION Problems State of the art P1: Traceability P7: Tooling support P3: Expressiveness P4: Understandability P2: Ambiguity and incompleteness P5: Visual gap P8: Standard support P6: Automated design-time analysis Figure 5.2: Kiviat diagram: level at which the related approaches overcome the existing problems dresses this feature does not take into account the possibility of grouping by certain dimension (isGroupedBy in our proposal). Both, Figure §5.2 and Table §5.2 show that the problem of ambiguity and incompleteness is the most addressed, since most of the approaches analysed are research works, while the understandability, visual gap and automated design-time analysis problems are the most disregarded. Furthermore, Table §5.2 let us confirm that none of the approaches address simultaneously all the problems and requirements identified (Section §5.3), and conclude that a definition, representation and analysis of PPIs that overcome the aforementioned problems and requirements constitute still an unresolved challenge. In this dissertation we address this challenge by means of the following contributions: (1) a metamodel (PPINOT metamodel) for the definition of PPIs that is useful along the whole PPI lifecycle; (2) a graphical notation to depict PPIs over BP models based on this metamodel; (3) a set of PPI-templates and L-PATTERNs to improve the definition of PPIs without needing to have a deep knowledge of BP notations; (4) a formalisation of the PPINOT metamodel using DL that allows to define a set of families of analysis operations to extract information at designtime from that PPI definitions; (5) A software tool suite that provides support for all the previous contributions (except for some analysis operations partially implemented yet). 56 5.5. DISCUSSION Proposal P1 P2 P3 P4 P5 P6 R1 R2 P3.1 P3.2 P3.3 P3.4 P3.5 P3.6 P3.7 P3.8 P6.1 P6.2 Castellanos et al. [12]∼3 3 3 ∼N/A 3*∼ ∼ 3 ARIS PPM [88]∼3 3 3 ∼3 3 3 ∼N/A ∼3 Mayerl et al. [51]∼333N/A 3*3∼3 Momm et al. [54]3 3 3 3 3*∼3 Pedrinaci et al. [70] N/A 333N/A 3*3 3 ∼ ∼ 3 3 Wetzstein et al. [107]3 3 3 3 3 3*3∼ ∼ ∼ 3 González et al. [39]3 3 3 3 ∼3∼3*3∼3 Popova et al. [77]333N/A N/A N/A 3*3N/A 3∼ Barone et al. [4]∼3 3 3 3 3*3∼ ∼ Friedenstab et al. [33]3 3 3 3 ∼3*3 3 ∼3 3 PPINOT 333333 333333333 (P1) Traceability (P3.7) Derived measures (P2) Ambiguity and incompleteness (P3.8) Definition of scope (P3.1) Time measures (P4) Understandability (P3.2) Count measures (P5) Visual gap (P3.3) Condition measures (P6.1) PPI-BP Interaction (P3.4) Data measures (P6.2) Relationships among PPIs (P3.5) Resource measures (R1) Tooling support (P3.6) Aggregated measures (R2) Standards support Table 5.2: Comparison of the analysed approaches and our proposal 57 CHAPTER 5. MOTIVATION 5.6 SUMMARY In this chapter, we have presented the main problems that motivated this dissertation. We have analysed the related literature on the definition and analysis of PPIs and observed that no proposal exists that overcomes all the problems identified. We have also emphasised the value and originality of our main contributions. 58 6 PPINOT METAMODEL 59 When you can measure what you are talking about and express it in numbers, you know something about it. Lord William Thomson Kelvin (1824-1907), British mathematical physicist and engineer To overcome the limitations related to the definitions of PPIs introduced in Chapter §5, we present here PPINOT metamodel. Its main advantages are: (1) it enables a seamless relationship between PPIs and business process models, which makes the use of PPIs along the business process lifecycle easier; (2) it eliminates the ambiguity and incompleteness problem of natural language; (3) it allows the definition of commonly used PPIs that, to the best of our knowledge, cannot be defined with other similar proposals, specially those related to data; (4) it provides these definitions of PPIs with the amenability to be automatically analsyed at design-time, as we describe in Chapter §9. The chapter is organised as follows: in Section §6.1 we introduce it; Section §6.2 briefly comments a set of considerations we make with respect to BP models; then, Sections §6.3, §6.4 and §6.5 describe in detail the metamodel; finally, we summarise the chapter in Section §6.6. CHAPTER 6. PPINOT METAMODEL 6.1 INTRODUCTION When managing PPIs, the first obstacle is to delimit a PPI conceptually since there is no consensus about the key elements and their relationships that need to be taken into account when defining PPIs. Consequently, it is necessary to establish a representation method simple and easy to understand, but also expressive enough to accommodate the different domains and situations where PPIs can be defined. In this chapter, we tackle this problem by introducing the PPINOT metamodel. This metamodel is the result of an extensive analysis of a variety of PPIs defined by different organisations, a careful study of the related literature and a process of successive refinements of the metamodel after applying it to different scenarios. The following sections detail the main features of the metamodel, which has been driven by these requirements: • Must allow the definition of SMART PPIs: As with other indicators, it is recommended that PPIs satisfy the SMART criteria [91]. SMART is an abbreviation for five characteristics of good indicators, namely: Specific (it has to be clear what the indicator exactly describes), Measurable (it has to be possible to measure a current value and to compare it to the target one), Achievable (it makes no sense to pursue a goal that will never be met), Relevant (it must be aligned with a part of the organisation’s strategy, something that really affects its performance) and Time-bounded (a PPI only has a meaning if it is known the time period in which it is measured). Therefore, the metamodel must allow the definition of PPIs according to the SMART criteria. • Must have a high expressiveness: The metamodel must be able to express all of the PPIs found in both the literature review and in the organisations whose PPIs have been analysed so that it can provide a solid basis for defining PPIs in any organisation. • Must be compatible with BPMN: The metamodel must be compatible with BPMN since it is the standard de facto in the industry to define business processes. • Must be extensible: The metamodel must provide mechanisms to be extended according to several variation points, namely: the type of measure used by the PPI, the expression of its target value and the definition of its scope in terms of the subset of process instances used to calculate the value of the PPI. 60 6.2. BUSINESS PROCESS MODEL CONSIDERATIONS 6.2 BUSINESS PROCESS MODEL CONSIDERATIONS First of all we establish some considerations regarding process models we will use later on in our proposal. These considerations will be refined when applying our PPINOT Metamodel to a concrete language or notation. Every business process includes BP elements that can be flow elements or dataObjects. Examples of flow elements in BPMN are activities or events. Any BP element when instantiated has a state associated that changes along the process instance evolution. The set of state values for every BP element changes depending on the language or notation. Except for dataObjects, whose state values are usually defined by the user, we consider that there exist one or a set of values corresponding to the start or activation of the BP element, and one or a set of values for its end. For instance, in BPMN 2.0 activities can have the following states: ready, active , withdrawn, completing, completed, failing, failed, terminating, terminated, compensating and compensated. In this case, the start corresponds to the change to state active, and the end can correspond to withdrawn, completed, failed, terminated or compensated. 6.3 CONCEPTUAL MODELLING OF PPIS As stated before, Process Performance Indicators (PPIs) can be defined as quantifiable metrics that allow to evaluate the efficiency and effectiveness of business processes. They can be measured directly by data that is generated within the process flow and are aimed at the process controlling and continuous optimization [14]. Consequently, the PPINOT metamodel (c.f. Figure §6.1) is defined according to this definition and taking into account the requirement that it must allow de definition of SMART PPIs. In particular, its attributes are defined as follows: •identifier: string. Every PPI must be uniquely identified by an identifier, that usually will be a number preceded by PPI. •name: string. This attribute provides a descriptive name for every PPI. •relatedTo: Process. This attribute makes reference to the process for which the PPI is defined. 61 CHAPTER 6. PPINOT METAMODEL Figure 6.1: PPIs in PPINOT Metamodel •goals: string [0..*]. This attribute allows the user to establish the strategic or operational goal/s that the PPI is related to. It highlights the relevance of the PPI (connecting to the Relevant characteristic of the SMART criteria). It can be fulfilled with an expression in natural language. A more formal definition of the relationship between the PPI and the organisational goals is out of the scope of this paper. Some approaches regarding this issue can be found in [77,78] •definition: MeasureDefinition. This attribute provides a definition about how the indicator is measured. With this field, the two first characteristics of the SMART criteria (Specific and Measurable) are fulfilled. In the next section, a detailed description of MeasureDefinition is provided. •target: Target. Every PPI has an associated target value to be reached indicating the consecution of the previously defined goals. In order to fulfill the Achievable characteristic of the SMART criteria, this target value must be reasonable, based on previous experiences and predictions based on simulations. PPINOT allows the definition of three kinds of target values: a simple target, a composed target and a custom target. A simple target is used to specify the lower bound and/or upper bound that make up the range within which the PPI value should be (If only an upper bound is defined, it acts as a maximum; if only a lower bound is defined, it acts as a minimum; finally, if both bounds are set, they define a range within which the PPI value must be). The composed target allows to define several target values or ranges, for those cases where the value of the PPI is a map (e.g. PPI7 and PPI8 from our case study). Finally the custom target offers the possibility to define a restriction that the PPI value must fulfill (allowing a higher case mix for 62 6.4. MEASURE DEFINITIONS the target value, e.g. utility functions can be defined, or a metamodel of preferences like the one presented in [36] can be used). •scope: Filter. This attribute indicates the subset of instances of the perviously specified process that must be considered to compute the PPI value. This field is related to the Time-Bounded characteristic of the SMART criteria. •responsible: HumanResource. This attribute holds the human resource in charge of the PPI. This human resource can be a person, a role, a department or an organisation. A more detailed definition of the types of human resources are out of the scope of this metamodel. However, some approaches regarding this issue can be found in [10,11]. •informed: HumanResource [0..*]. This attribute represents the human resources that are interested in the PPI, i.e., who must be informed. This human resource can be also a person, a role, a department or an organisation. Unlike the responsible, which must be only one person, there may be many people informed about the state of the PPI. •comments: String. Other information about the PPI that cannot be fitted in previous fields can be recorded here. In the following sections, we detail how MeasureDefinition and Filter are defined in the PPINOT metamodel. Furthermore, we also introduce the concept of Condition, which is necessary to express the relationship between MeasureDefinitions and the business process. 6.4 MEASURE DEFINITIONS Figure §6.2 depicts the two dimensions into which the definition of measures for PPIs can be classified. The first dimension (Y axis) is the number of process instances necessary to calculate the PPI value. There are two possible values in this dimension, namely: single-instance measures if a single process instance is used to calculate the measure, and multi-instance measures if the PPI value is calculated using a set of process instances. Usually, most PPIs are defined using multi-instance measures. The second dimension (X axis) is the way in which the PPI value is calculated. In this case PPIs can be defined over the following types of measures: •time measure: it reflects the duration between two time points in the process. 63 CHAPTER 6. PPINOT METAMODEL !"#$%&'()*'+,- .&'/#,%&'()*'+,- 0&1,- 23"')- 23'4&$3'- 5*)*- 5,6&7,4- 8//6,/*),4!,*("6,- !"#$%"&'#( )'%#*+'#( 9*(,!,*("6,- 5,6&7,4!,*("6,- Figure 6.2: PPI dimensions •count measure: it counts the number of times certain condition is satisfied. •condition measure: it checks if certain condition is (for running instances) or has been (for finished instances) met. •data measure: it takes the value of a data property of certain dataObject. •derived measure: it is calculated by performing a mathematical function over any number of measures previously defined. These dimensions are captured in the PPINOT metamodel by means of three classes that extend MeasureDefinition:BaseMeasure,AggregatedMeasure and DerivedMeasure (cf. Figure §6.3). The relationship of these classes with the dimensions are depicted in Figure §6.2. A BaseMeasure represents single-instance measures that measures time, count, conditions and data. An AggregatedMeasure represents multi-instance measures that can be defined as an aggregation of single-instance measures (i.e. multi-instance measures that measures time, count, conditions and data). Finally, a DerivedMeasure represents either a single-instance or a multi-instance measure that calculates the value of the PPI by performing a mathematical function over other measures. The reason for considering DerivedMeasure as a top-level class in the metamodel is twofold. First, the way in which the value of the PPI is calculated is conceptually different from 64 6.4. MEASURE DEFINITIONS Figure 6.3: Measure definition in PPINOT Metamodel the other four types of measures. Second, a derived multi-instance measure cannot always be defined as an aggregation of derived single-instance measures. For instance, a derived multiinstance measure such as max(timeinanalyseincommittee) max(timeinprocess)cannot be defined as max(timeinanalyseincommittee timeinprocess ). In the following sections, we detail how each type of measure definition can be specified in the PPINOT metamodel. 6.4.1 Time Measure A time measure measures the duration of time between two time instants. These two time instants can correspond with the change to a certain state of a BP element activity, pool, or dataObject, or with the triggering of a certain event. For instance, the PPI “duration of RFC analysis” can be expressed as follows: The duration between the time instant when activity analyse RFC changes to state active and the time instant when activity analyse RFC changes to state completed. 65 CHAPTER 7. PPINOT GRAPHICAL NOTATION 7.1 INTRODUCTION There exists a partial view from the different departments or roles in charge of, on the one hand, the modelling and execution of business processes, and, on the other hand, the definition and consecution of goals and its associated indicators: nobody has a comprehensive view of both worlds, making thus very difficult the maintenance of coherence across them. In Chapter §6 we have presented a metamodel for the definition of PPIs over BPs; however, there exists a visual gap between BP models and this model of PPIs. In the same manner as explicit BP models expressed in a graphical notation (such as, for instance, BPMN) ease communication about these processes, allowing thus stakeholders to communicate efficiently, and refine and improve them; a graphical notation that allows the depiction of PPIs together with the corresponding BP models will also bring this benefit together with this comprehensive view, absent up to know. In this chapter, we present PPINOT graphical notation, that allows the depiction of PPIs over BPMN Business Process Diagrams (BPDs), based on PPNIOT metamodel, described in Chapter §6. It is a graph-based notation defined attending to a set of requirements and principles for designing cognitively effective visual notations established by several authors. We also provide a simple guide to assist the user in defining PPIs using PPINOT graphical notation 7.2 NOTATION CONSTRUCTS Figure §7.1 shows an overview of our proposed notation. Connections with BPMN elements are depicted by links, which can be decorated with a label giving the link type (e.g.“from”, “isGroupedBy”). In the following subsections we present each type of construct in our notation and the corresponding connectors that allows to link them with the BPMN diagram and to establish some relations between them. 7.2.1 PPI First we present the construct for the PPI, that will be in most cases the container of the other constructs. A PPI is depicted by a rectangle, having on the upper left corner a circle representing an indicator (as represented in Figure §7.1). Its attribute name will appear on top of this shape, in the middle. Within that shape, the measure that defines the PPI is placed (sometimes there will be only one measure, in case of BaseMeasures and “simplified” AggregatedMeasures (see Section §7.2.3 for more details), and sometimes, more than one, connected trhough links uses, in case of the rest of AggregatedMeasures and DerivedMeasures). 72 7.2. NOTATION CONSTRUCTS !!"#$%&'&!($)*++&!*(,$(-./)*&"/01).%$(+&#$%.2$/& !"#$%&"$' & 3.+*&4*.+5(*6&()'*"#$%&"$'"#+,' -&.+"$$'(/$)#/+"'$"-#&#)"012' & 788(*8.%*0&4*.+5(*3'()'*"#$%&"$' $"4"�'-&.+"$$'(/$)#/+"$'51' #66&"6#7/6'),"*'),&.%6,'#/' #66&"6#7./'8%/+7./3'4"#9&47:9& 7;<9&=>4& & & ?*(1@*0&4*.+5(*3'()'-"&8.&*$'#' *#),"*#7+#0'8%/+7./'.4"&'$"4"�' (/$)#/+"' 9?*(1@*0=1/8A*"/+%./)*4*.+5(*B'.&'' -&.+"$$'*"#$%&"$' 9?*(1@*045A2"/+%./)*4*.+5(*BC' :.//"+).&$' 7DDA1*+&%$'98.&'.),"&'*"#$%&"$;3' •!'<8'()'($'+.%/)='/.'0#5"0' •!<8'()'($'>)#)":./?(7./='),"'0#5"0' *%$)'5"'#'$)#)"' •!'<8'()'($'@#)#A&.-"&)1:./?(7./='),"' 0#5"0'*%$)'5"'#'&"$)&(+7./'.4"&'#' @#)#A&.-"&)1' •!'<8'()'($'@#)#='),"'0#5"0'*%$)'5"'#' ?#)#'+./)"/)''9#/?'*#15"'#'$)#)";' 788(*8.%*+&98.&'#66&"6#)"?' *"#$%&"$;3'()'+.//"+)$').'),"' (/$)#/+"!"#$%&"$'#66&"6#)"?& & 1+<($5D*03E'98.&'#66&"6#)"?' *"#$%&"$;3'()'#00.B$').'6&.%-'51' +"&)#(/'?#)#'+./)"/)'9$-"+(C"?' ),&.%6,'#/'#D&(5%)";' >+*+'98.&'?"&(4"?'*"#$%&"$;3' :.//"+)$').'),"'*"#$%&"$' +.*5(/"?').'+#0+%0#)"'()2' E#&(#50"$'+#/'5"'%$"?'8.&'),"' *"#$%&"$'+.*5(/"?'#/?'B&()"' (/$(?"'),"'?"&(4"?'*"#$%&"'),"' +.&&"$-./?(/6'8.&*%0#"2' F,#)').'*"#$%&"' F1-*3'@%./'5")B""/' )B.'(/$)#/)'+./?(7./$2' G$5/%3'G%*5"&'.8'7*"$' +"&)#(/'(/$)#/)'+./?(7./'($' *")2' =%.%*&G$/012$/6&+,"+H(/6' B,"),"&'#/'#+74()1='#'-..0=' #'?#)#'.5I"+)'.&'+"&)#(/' "4"/)$'#&"'(/'#'6(4"/'$)#)"' 9&"#?1='+#/+"00"?=' +.*-0")"?='")+2;2' ?.%.&!($D*(%E&G$/012$/6& +,"+H(/6'B,"),"&'#' +./?(7./'.4"&'#'?#)#' -&.-"&)1'+./)"/)'($'*")2' ?.%.&)$/%*/%3'J5)#(/(/6'),"' 4#0%"'.8'+"&)#(/'?#)#' +./)"/)2& =>4' =>4' AA<' !!"3'+./)#(/(/6'),"' *"#$%&"'),#)'?"C/"$' ),"'AA<' F1-*&)$//*)%$(+'98.&'7*"'*"#$%&"$;' •!K&.*' •!L.' •!M+74()1NA..0O>)#&)'' •!M+74()1NA..0OP/?' !"#$% &#% Figure 7.1: PPINOT Graphical Notation (overview) The element PPI has the set of attributes previously described in Chapter §6 and are summarised in Table §7.1. These attributes are not represented graphically We take PPI9 “process duration” as example of PPI. It is depicted in Figure §7.2 7.2.2 BaseMeasure The BaseMeasure element has the set of attributes depicted in table §7.2. Depending on what to be measured, there are four types of BaseMeasures. In each case, a different icon is added on the upper left corner to the BaseMeasure shape. In the following we list them: •TimeMeasure In this case, where time is measured, the icon added is an hourglass. There aare two links to the BPMN diagram (BPD). They are called Time connectors (see §7.2.5 for more detail). The element TimeMeasure inherits the attributes of BaseMeasure (see Table §7.2). Table §7.3 presents the additional attributes of the TimeMeasure element. 73 CHAPTER 7. PPINOT GRAPHICAL NOTATION Attribute Name Description/Usage identifier: string To uniquely identify the PPI name: string Descriptive name of the PPI goals: string To establish strategic or operational goals target: string Set the restriction which is the objective to achieve scope: string To indicate the subset of instances taken into accout to calculate the PPI value responsible: HumanResource Human resource in charge of the PPI informed: HumanResource [0..*] Human resources interested in the PPI comments: string other information to add Table 7.1: Attributes of PPIs Figure 7.2: PPI example 74 7.2. NOTATION CONSTRUCTS Attribute Name Description/Usage name: string The name of the BaseMeasure scale: string This attribute identifies the domain for the measure, i.e. a set of values with defined properties, e.g. natural, integer, float, map, [0..100] unitOfMeasure: string The unit of the BaseMeasure, e.g. seconds, hours or euros Table 7.2: Attributes of BaseMeasures Attribute Name Description/Usage timeMeasuretype: string = LinearTimeMeasure {LinearTimeMeasure |CyclicTimeMeasure} This attribute allows to dedifferentiate between LinearTimeMeasures and CyclicTimeMeasures. singleInstanceAggFunction: string[0..1] newline{avg |max |min |sum} this attribute defines the aggregation function applied if timeMeasuretype = CyclicTimeMeasure Table 7.3: Attributes of TimeMeasures As explained in Section §6.4.1 TimeMeasures can be subdivided into LinearTimeMeasures and Cyclic- TimeMeasures; graphically, the difference between them is that the CyclicTimeMeasure has a symbol representing a loop (different from the one of BPMN) on the right of the hourglass icon. Figure 7.3: Linear time measure example From the TimeMeasure example “duration of the analysis of an RFC”, we can distin- 75 CHAPTER 7. PPINOT GRAPHICAL NOTATION !"#$%&'&() *!'+,&) Figure 7.4: Cyclic time measure example guish between the LinearTimeMeasure, depicted in Figure §7.3, and the Cyclic- TimeMeasure, depicted in Figure §7.4 (in this case, the value of attribute singleInstance- AggFunction must be fulfilled, e.g. avg for the PPI “average duration of the analysis of an RFC in a process instance”). •CountMeasure This measure counts, therefore, the icon selected to represent it is an ellipse with the numbers 1, 2 and 3 inside (as shown in Figure §7.1). The CountMeasure’s shape is connected to the BPD through a connector called appliesTo (see Subsection §7.2.6 for further explanation). This connector will go to the flow element whose condition is being counted. The element CountMeasure inherits the attributes of BaseMeasure (see Table §7.2). An example of CountMeasure is “number of times an RFC is successfully analysed” (depicted in Figure §7.5). !"#$%&'&() *!'+,&) *!'+,&) Figure 7.5: Count measure example •ConditionMeasure 76 7.2. NOTATION CONSTRUCTS This type of measure checks certain condition, therefore, the icon added to the upper left corner of the BaseMeasure’s shape is an ellipse with the checklist symbol inside (as shown in Figure §7.1). This measure is connected to the BPD, as in the previous case, through the connector appliesTo. The element ConditionMeasure inherits the attributes of BaseMeasure (see Table §7.2). As detailed in Section §6.4.3, ConditionMeasures can be subdivided into StateCondition and DataPropertyCondition. Graphically, the difference between them is that in the case of DataPropertyCondition, there is an envelope before the checklist symbol inside the ellipse. The StateConditionMeasure example “check if RFC under analysis” is depicted in Figure §7.6. !"#$%&'&() *!'+,&) *!'+,&) Figure 7.6: State condition measure example The DataPropertyConditionMeasure example “check if RFC with priority high” is depicted in Figure §7.7. Figure 7.7: DataProperty condition measure example •DataMeasure In this case, where the value of certain part of a dataObject is taken, the icon added is a stick figure carrying an envelope (see the icon in Figure §7.1). Again, as in the previous cases, the connection to the BPD is through the connector appliesTo. The element DataMeasure inherits the attributes of BaseMeasure (see Table §7.2). The DataMeasure example “number of Information Systems an RFC affects to” is depicted in Figure §7.7. 77 CHAPTER 7. PPINOT GRAPHICAL NOTATION Figure 7.8: Data measure example 7.2.3 AggregatedMeasure The AggregatedMeasure’s shape is obtained by superimposing three shapes of the BaseMeasure as depicted in Figure §7.1. Inside the front rectangle (ruler) of this shape, the value of attribute AggregationFunction is written (“Min”,“Max”, “Avg” or “Sum” ). This AggregatedMeasure must be related to the SingleInstanceMeasure it aggregates; this relationship is established through a connector called aggregates (see subsection §7.2.7 for further explanation). The element AggregatedMeasure has the set of attributes depicted in Table §7.4. Attribute Name Description/Usage name: string The name of the AggregatedMeasure scale: string This attribute identifies the domain for the measure, i.e. a set of values with defined properties, e.g. natural, integer, float, map, [0..100] unitOfMeasure: string The unit of the AggregatedMeasure, e.g. seconds, hours or euros aggregationFunction: string[0..1] { avg |max |min |sum } This attribute defines the aggregation function applied to the BaseMeasure aggregated in the AggregatedMeasure Table 7.4: Attributes of AggregatedMeasures The AggregatedMeasure example “ number of RFCs rejected in the last year” is depicted in Figure §7.9. When the SingleInstanceMeasure aggregated is a BaseMeasure, then, this connection can be omitted and the AggregatedMeasure inherits its links to the BPD as well as its type (time-cyclic or linear-, count, stateCondition, dataPropertyCondition or data); in such a 78 7.2. NOTATION CONSTRUCTS Figure 7.9: Aggregated measure example case, the corresponding icon will be added again on the upper left corner of the AggregatedMeasure shape and they take the name TimeAggregatedMeasure,CountAggregatedMeasure, StateConditionAggregatedMeasure,DataPropertyConditionAggregatedMeasure and DataAggregatedMeasure respectively. Figure §7.10 shows the previous AggregatedMeasure example depicted following this simplification (a StateConditionAggregatedMeasure is depicted in this case). Figure 7.10: Aggregated measure example For the case of TimeAggregatedMeasures the set of attributes of TimeMeasures are inherited (see Table §7.3). 7.2.4 DerivedMeasure As stated in Section §6.4.5, DerivedMeasures can be subdivided into Derived- SingleInstanceMeasures and DerivedMultiInstanceMeasure. In either cases, there will be as many links as measures combined to calculate the value. These connectors are called uses (see §7.2.9 for more details). There exists the possibility to add a formula with the corresponding mathematical function that allows to calculate the value of the DerivedMeasure. It must be written inside its shape, using variables representing the combined measures. The set of attributes of DerivedMeasures are depicted in Table §7.5. The shapes are different according to the previous mentioned subdivision. •DerivedInstanceMeasure 79 CHAPTER 7. PPINOT GRAPHICAL NOTATION Attribute Name Description/Usage name: string The name of the DerivedMeasure scale: string This attribute identifies the domain for the DerivedMeasure, i.e. a set of values with defined properties, e.g. natural, integer, float, map, [0..100] unitOfMeasure: string The unit of the DerivedMeasure, e.g. seconds, hours or euros function: string[0..1] This attributes identifies the mathematical function applied to calculate the value of the DerivedMeasure Table 7.5: Attributes of DerivedMeasures The shape depicting this DerivedInstanceMeasure is similar to the one used for the BaseMeasure, but the ruler has up and in the middle a square with a plus symbol inside, trying to convey the need to perform a mathematical function to obtain the value of this measure (see Figure §7.1) An example of DerivedInstanceMeasure is “percentage of time spent in activity analyse RFC with respect to the duration of the process ”, and is depicted in Figure §7.11. •DerivedProcessMeasure This case is very similar to the previous one, but now, since these are ProcessMeasures, the depiction is obtained by superimposing three of the previous shapes (the ones for the DerivedInstanceMeasure). An example of DerivedProcessMeasure is “percentage of approved RFCs with respect to all the registered RFCs”, and is depicted in Figure §7.12. 7.2.5 Time Connector ATime Connector is used to represent the point in the process where time starts and ends to be measured. Each Time Connector has only one source and one target. The source must be a TimeMeasure or an AggregatedTimeMeasure, and the target must be one of the following elements: activity, pool, event or dataObject. ATime Connector is depicted through a dashed line. Depending on the value of the attribute conditionType, it acquires different forms: if conditionType = from, it is decorated with the label “from” and an empty circle at the initial end, and it will be connected to the flow element where the time starts to run. If conditionType = to it is decorated 80 7.2. NOTATION CONSTRUCTS Figure 7.11: Derived instance measure example with the label “to” and a filled circle at the initial end, and will be connected to the flow element that closes the measured time period. If a Time Connector’s target is the start of an activity or a pool, an empty circle must be attached to the final end (the part connected to the flow element) and the label “start” appears above the connector, near to the target; if, on the contrary, the Time Connector’s target is the end 1of an activity or a pool, a filled circle has to be added to the final end of the link and the label “end” appears above the connector, near to the target. If any other state is indicated in attribute state, its value appears above the Time Connector near to the target element. There must be only two Time Connectors per TimeMeasure or AggregatedTimeMeasure, one from and one to, except for the case where the target is a dataObject, that there can be 1with end we refer to an activity or a pool that has reached one of the following states: completed, compensated, failed and terminated 81 CHAPTER 7. PPINOT GRAPHICAL NOTATION From/To 42 Business Process Model and Notation, v2.0 !"The markers for “throwing” Events MUST have a dark fill (see “End Event” on page 246 and “Intermediate Event” on page 249 for more details). !"Participant Bands for Choreography Tasks and Sub-Choreographies that are not the initiator of the Activity MUST have a light fill (see “Choreography Task” on page 323 and “Sub-Choreography” on page 328 for more details). !"Flow objects and markers MAY be of any size that suits the purposes of the modeler or modeling tool. !"The lines that are used to draw the graphical elements MAY be black. !"The notation MAY be extended to use other line colors to suit the purpose of the modeler or tool (e.g., to highlight the value of an object attribute). !"The notation MAY be extended to use other line styles to suit the purpose of the modeler or tool (e.g., to highlight the value of an object attribute) with the condition that the line style MUST NOT conflict with any current BPMN defined line style. Thus, the line styles of Sequence Flows, Message Flows, and Text Associations MUST NOT be modified or duplicated. 7.5 Flow Object Connection Rules An incoming Sequence Flow can connect to any location on a Flow Object (left, right, top, or bottom). Likewise, an outgoing Sequence Flow can connect from any location on a Flow Object (left, right, top, or bottom). A Message Flow also has this capability. BPMN allows this flexibility; however, we also RECOMMEND that modelers use judgment or best practices in how Flow Objects should be connected so that readers of the Diagrams will find the behavior clear and easy to follow. This is even more important when a Diagram contains Sequence Flows and Message Flows. In these situations it is best to pick a direction of Sequence Flows, either left to right or top to bottom, and then direct the Message Flows at a 90° angle to the Sequence Flows. The resulting Diagrams will be much easier to understand. 7.5.1 Sequence Flow Connections Rules Table 7.3 displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flows. These rules apply to the connections within a Process Diagram and within a Choreography Diagram. The # symbol indicates that the object listed in the row can connect to the object listed in the column. The quantity of connections into and out of an object is subject to various configuration dependencies are not specified here. Refer to the sections in the next chapter for each individual object for more detailed information on the appropriate connection rules. Note that if a Sub-Process has been expanded within a Diagram, the objects within the Sub-Process cannot be connected to objects outside of the Sub-Process. Nor can Sequence Flows cross a Pool boundary. Table 7.3 – Sequence Flow Connection Rules From\To ‰# # # # 42 Business Process Model and Notation, v2.0 !"The markers for “throwing” Events MUST have a dark fill (see “End Event” on page 246 and “Intermediate Event” on page 249 for more details). !"Participant Bands for Choreography Tasks and Sub-Choreographies that are not the initiator of the Activity MUST have a light fill (see “Choreography Task” on page 323 and “Sub-Choreography” on page 328 for more details). !"Flow objects and markers MAY be of any size that suits the purposes of the modeler or modeling tool. !"The lines that are used to draw the graphical elements MAY be black. !"The notation MAY be extended to use other line colors to suit the purpose of the modeler or tool (e.g., to highlight the value of an object attribute). !"The notation MAY be extended to use other line styles to suit the purpose of the modeler or tool (e.g., to highlight the value of an object attribute) with the condition that the line style MUST NOT conflict with any current BPMN defined line style. Thus, the line styles of Sequence Flows, Message Flows, and Text Associations MUST NOT be modified or duplicated. 7.5 Flow Object Connection Rules An incoming Sequence Flow can connect to any location on a Flow Object (left, right, top, or bottom). Likewise, an outgoing Sequence Flow can connect from any location on a Flow Object (left, right, top, or bottom). A Message Flow also has this capability. BPMN allows this flexibility; however, we also RECOMMEND that modelers use judgment or best practices in how Flow Objects should be connected so that readers of the Diagrams will find the behavior clear and easy to follow. This is even more important when a Diagram contains Sequence Flows and Message Flows. In these situations it is best to pick a direction of Sequence Flows, either left to right or top to bottom, and then direct the Message Flows at a 90° angle to the Sequence Flows. The resulting Diagrams will be much easier to understand. 7.5.1 Sequence Flow Connections Rules Table 7.3 displays the BPMN Flow Objects and shows how these objects can connect to one another through Sequence Flows. These rules apply to the connections within a Process Diagram and within a Choreography Diagram. The # symbol indicates that the object listed in the row can connect to the object listed in the column. The quantity of connections into and out of an object is subject to various configuration dependencies are not specified here. Refer to the sections in the next chapter for each individual object for more detailed information on the appropriate connection rules. Note that if a Sub-Process has been expanded within a Diagram, the objects within the Sub-Process cannot be connected to objects outside of the Sub-Process. Nor can Sequence Flows cross a Pool boundary. Table 7.3 – Sequence Flow Connection Rules From\To ‰# # # # 44 Business Process Model and Notation, v2.0 Only those objects that can have incoming and/or outgoing Message Flows are shown in the table. Thus, Lane, Gateway, Data Object, Group, and Text Annotation are not listed in the table. 7.6 BPMN Extensibility BPMN 2.0 introduces an extensibility mechanism that allows extending standard BPMN elements with additional attributes. It can be used by modelers and modeling tools to add non-standard elements or Artifacts to satisfy a specific need, such as the unique requirements of a vertical domain, and still have valid BPMN Core. Extension attributes MUST NOT contradict the semantics of any BPMN element. In addition, while extensible, BPMN Diagrams should still have the basic look-and-feel so that a Diagram by any modeler should be easily understood by any viewer of the Diagram. Thus the footprint of the basic flow elements (Events, Activities, and Gateways) MUST NOT be altered. The specification differentiates between mandatory and optional extensions (Section 8.2.3 explains the syntax used to declare extensions). If a mandatory extension is used, a compliant implementation MUST understand the extension. If an optional extension is used, a compliant implementation MAY ignore the extension. Table 7.4 – Message Flow Connection Rules From\To ˆ! ! ! ! ˆ! ! ! ! ˆ! ! ! ! ˆ! ! ! ! ˆ! ! ! ! Name Pool Name Pool Business Process Model and Notation, v2.0 207 Figure 10.52 – A DataObject Collection (see Figure 10.53) Figure 10.53 - A DataObject that is a collection Visual representations of Data Objects Data Object can appear multiple times in a Process diagram. Each of these appearances references the same Data Object instance. Multiple occurrences of a Data Object in a diagram are allowed to simplify diagram connections. Lifecycle and Accessibility The lifecycle of a Data Object is tied to the lifecycle of its parent Process or Sub-Process. When a Process or Sub-Process is instantiated, all Data Objects contained within it are also instantiated. When a Process or Sub- Process instance is disposed, all Data Object instances contained within it are also disposed. At this point the data within these instances are no longer available. The accessibility of a Data Object is driven by its lifecycle. The data within a Data Object can only be accessed when there is guaranteed to be a live Data Object instance present. As a result, a Data Object can only be accessed by its immediate parent (Process or Sub-Process), or by its sibling Flow Elements and their children, including Data Object References referencing the Data Object. For example - Consider the follow structure: Process A Data object 1 Task A Sub-process A Data object 2 Task B Sub-process B Data object 3 Sub-process C Data object 4 Task C Task D or or or or or or or Table 7.10: PPINOT Connection Rules 88 7.3. DESIGN RATIONALE Rumbaugh [85] Moody [56] PPINot Comments 1 Clear mapping concepts to symbols Semiotic Clarity 3Deliberate symbols deficit 2 No overloading of symbols Graphic Economy 3We leave concepts offdiagram to simplify 3 Uniform mapping concepts to symbols Perceptual 3 4 Distinction not too subtle Discriminability 5 Easy to draw by hand - ∼Some symbols not so easy to draw but intuitive 6 - Semantic Transparency 3 7 Looks good when printed -3 8 Must fax & copy well. No colours -3 Table 7.11: Compliance with requirements and principles by PPINOT notation (I) economy means that the number of different graphical symbols should be cognitively manageable), in our notation, each of the key concepts (PPI, each type ofBaseMeasure,AgregatedMeasures, DerivedMeasure, etc) was mapped to a distinct symbol. We only left without symbols those concepts that, not being crucial for the understandability of the depictions, could raise the complexity of it (for instance the scope). Regarding the third row, taking into account that perceptual discriminability refers to the fact that different symbols should be clearly distinguishable from each other; we strived to select symbols that emphasize similarities between related concepts (e.g. between DerivedSingleInstanceMeasure and DerivedMultiInstanceMeasure), whilst using clearly distinct symbols for concepts clearly dissimilar (e.g. symbols for the different types of BaseMeasures, time, data, etc.). In order to accomplish the principle of semantic transparency (row 6), which aims to use visual representations whose appearance suggests their meaning, we provide a correspondence between the icons selected and the concepts they represent (e.g a ruler to represent measures). Most of these icons are also easily drawn by hand, fulfilling thus the principle of 89 CHAPTER 7. PPINOT GRAPHICAL NOTATION Rumbaugh [85] Moody [56] PPINot Comments 9 - Visual Expressiveness ∼Among the 8 possible visual variables, we only use shape and texture 10 Consistent with past practice - N/A No past practice 11 Self consistent - 3 12 - Dual Coding 3Text complements graphics 13 Users can remember it - ∼Subjective requirements 14 Common cases appear simple -∼Need for an experiment to prove them 15 Suppressible details Manageable Complexity ∼Different levels of abstraction for PPIs 16 - Cognitive Fit 7Only one dialect simple enough to everyone and every media 17 - Cognitive Integration N/A Only one type of diagram Table 7.12: Compliance with requirements and principles by PPINOT notation (II) Rumbaugh in row 5, but in some cases (e.g. the DerivedMeasure), it is not so like that; in these cases, the decision was made in favour of compliance with the semantic transparency principle. Our notation does not rely on shading, line thickness, colours, or any other distinction that are subtle, confusing or that do not fax/copy well. With these decisions, we fulfill criteria from rows 4, 5, 7 and 8 of Rumbaugh, but we leave partially uncovered the principle of visual expressiveness from row 9 (use the full range and capacities of visual variables). We considered it could be useful to allow the user to use these mechanisms (colours, shading, etc.) to emphasize concepts of the business domain, not of the notation domain (following also the BPMN recommendations). Related to the consistency with past practice (row 10), since, to the best of our knowledge, 90 7.4. GUIDELINES there is no graphical notation for this role, many of the concepts used do not exist and is important to have new and clearly distinct symbols for new and clearly distinct concepts (criteria from row 11). Anyway, we did take into account some concepts of BPMN, for example not using the classical clock but an hourglass to depict TimeMeasures (since BPMN uses such symbol for Timers). Attending to the dual coding principle (row 12), in most cases, the text is used to complement graphics and not to distinguish them (for instance in connectors from and to, The text reinforces what we already expressed graphically by means of full and empty circles). Regarding requirements from rows 13 and 14, they are somehow a bit subjective. Due to this fact, an experiment has been conducted. More information in section §10.3.1 Relative to row 15 (being complexity manageable to include explicit mechanisms for dealing with complexity, understanding this as the number of elements on a diagram), we addressed it in some way (e. the user can decide wether to explicit the mathematical function within the derivedMeasure or wether to model the measures an aggregatedMeasure aggregates or not to show them); however, we did not delve into this detail yet: there exists, thus, the possibility to overload a diagram with too much PPIs. For this issue we plan to extend the notation with a new PPI-view, where only PPIs would appear (without the BPMN diagram), and the relationships between them. We are also working on presenting the user those PPIs interesting for them, i.e., to allow the user to group PPIs according to certain property (e.g. all the PPIs defined for certain activity, or those regarding time) and only those PPIs will appear at the diagram. Finally, we do not provide different dialects depending on the audience the notation is addressed to (experts versus novices) or the media in which it is represented (whiteboard, computer, etc), leaving thus uncovered the cognitive fit principle. We decided to use a standard notation, as it is done in BPMN. Furthermore, we do not include explicit mechanisms to support integration of information from different diagrams (cognitive integration principle) since there are not different views or diagrams in our approach nor in BPMN, preserving thus the alignment with this notation we extend. 7.4 GUIDELINES In this section we intend to provide a simple guide to assist the user in defining PPIs using PPINOT graphical notation. The idea is to show the way to translate a definition of a PPI in natural language to the one using our graphical notation. 91 CHAPTER 7. PPINOT GRAPHICAL NOTATION As stated in Section §6.1, in order to define good PPIs, is recommended that they satisfy the SMART criteria. Having PPIs defined in natural language, this SMART criteria is not always fulfilled. To be able to translate such PPI definition into the graphical notation (fulfilling thus the aforementioned characteristics), the user will have to answer three simple questions: What to measure?,How to measure? and When to measure? 1. What to measure? This question is related to the elements of the process on which to perform the measure, and the concept that needs to be measured over that element: time, repetitions, a certain condition, etc. In most cases, this information can be obtained by identifying noun or noun phrases. 2. How to measure? Here the user has to establish the way of obtaining the measure, i.e. if the measure can be performed directly over the elements of a process instance (taken from the execution of the process), or they can be obtained by aggregating several instances or applying a mathematical function. 3. When to measure? Finally, it is necessary to specify the instances to be measured, the moment in time and/or how often they must be measured. This implies to define, as stated before, a scope (using filters). Table 7.13: subset of PPIs defined for the RFC management process Description Periodicity id Average time of committee decision yearly PPI2 Percentage of corrective changes monthly PPI3 Number of RFCs per project yearly PPI8 We take several examples related to the PPIs defined for the Request for Change Management process shown in Table §7.13 (that is an excerpt of Table §5.1). •Example 1: PPI2 - Average time of committee decision –What to measure? looking at the definition of the PPI, we can identify two noun phrases: “time” and “committee decision”. Then, we can derive two facts: first, 92 7.4. GUIDELINES that we need to measure time; it is noteworthy that whenever time is measured, a start (from) and an end (to) must be defined; the second fact is related to the process element over which we want to measure time. Looking to the process, it can be deduced that the committee decision is made during the activity "Analyse in committee", thus the start and the end correspond to the start and the end of this activity. –How to measure? This means how to obtain the value from the process. Let’s see which of the three possibilities (directly, aggregating or through mathematical function) is the one to choose in this case: If we need to measure the average, it implies that more than one instance is taken into account. Moreover, it also indicates that we must aggregate several instances (AggregatedMeasure) using the aggregation function average. –When to measure? Finally, we have to identify how many instances we have to take into account when aggregating. This is defined in Table §7.13 through the “periodicity’ =Yearly”. That is, we need to aggregate every instance whose start is later or equal to the first of January and the end is before or equal to the thirty-first of December, every year. •Example 2: PPI8 - Number of RFCs per project –What to measure? In this case, we have again three nouns: “number”, “RFCs” and “project”. The first one represents the concept we need to measure, i.e. number of times or repetitions. The second one is related to the element of the process over which to perform the measure. This can be done in different ways: directly in the start event (when receiving the request for change), over the dataObject “RFC registered” or even over the start of the whole pool of the process (since whenever the process is instantiated, a new RFC appears); we choose the first case, thus, the element is the start event “Receive RFC”. Finally, the third noun does not correspond to this question and can induce to an error; the explanation comes in next paragraph. –How to measure? Since we need to count the number of times an RFC is received, we have to aggregate several instances. Furthermore, this time we are not interested in the average value as in the previous case, but in the total number; hence, we have to use the aggregation function sum. Regarding the noun “project” , this indicates we want to group the RFCs received according to the different project they belong to. Therefore, this aggregation must be done grouping by the data content “project” contained in the dataObject "RFC" –When to measure? To delimit the number of instances we have to take into account 93 CHAPTER 7. PPINOT GRAPHICAL NOTATION when aggregating, we look again at the “periodicity” column in Table §7.13, this time is “monthly”, what means that whenever a month ends, we must count the number of RFC received in that period and group them by project. •Example 3: PPI3 - Percentage of corrective changes –What to measure? We can identify two noun phrases in the description: “percentage” and “corrective changes”. The first one is directly related to the second question, since the fact of measuring a percentage implies to use a mathematical function applied to two other measures to calculate it. The issue in this case is to identify these two measures and follow the same process as in previous cases. For this example these two measures can be defined as “number of RFCs received” (this information is implied in the description of the PPI) and “number of corrective RFCs received” (deduced from the second noun phrase). The first one is almost the same as the preceding example, i.e. we measure “number of times of repetitions” over the start event “Receive RFC”. In the second measure, we check which of the RFCs received fulfill the “condition” of being a corrective change; this information is contained in the data object "RFC received". –How to measure? As stated in the previous question, a mathematical function must be applied over the two mentioned measures. The mathematical function is a∗100 b, where a’ corresponds to “number of corrective RFCs received” (following the same process as the two previous example, we get that this is a DataPropertyCondition- AggregatedMeasure) and bto “number of RFCs received” (CountAggregatedMeasure) –When to measure? Again, as in the first example, we have that “periodicity’ =Yearly”, therefore, for both measures (a and b,) we have to aggregate the instances included in the whole year and then apply the function to that values. 7.5 SUMMARY In this chapter we have described PPINOT Graphical notation, our proposal on the graphical definition of PPIs over BPMN models. With this proposal we address the problem of the existing visual gap between BP models and PPI definitions. Furthermore it makes the definition of PPIs understandable for non-technical users. We have also described the principles that our design decision making is based on. Finally, we have also presented a set of guidelines to assist the user in the task of defining PPIs with our proposal. We summarise the problems we overcome with this contribution by means of the Kiviat diagram depicted in Figure §7.14. 94 7.5. SUMMARY Graphical Notation Contribution P1: Traceability P7: Tooling support P3: Expressiveness P4: Understandability P2: Ambiguity and incompleteness P5: Visual gap P8: Standard support P6: Automated design-time analysis Figure 7.14: Kiviat diagram for the problems overcome by PPINOT Graphical Notation 95 CHAPTER 7. PPINOT GRAPHICAL NOTATION 96 8 PPI TEMPLATES AND L-PATTERNS 97 I believe scientists have a duty to share the excitement and pleasure of their work with the general public, and I enjoy the challenge of presenting difficult ideas in an understandable way. Antony Hewish (–) In this chapter we propose a novel mechanism to improve the definition of PPIs using templates and L-PATTERNs based on PPINOT metamodel, introduced in Chapter §6. The main benefits of this approach are that it is easy to learn, promotes reuse, reduces ambiguities and the possibiity of missing information, is understandable to all stakeholders and maintains traceability with the process model. Furthermore, since the translation to a formal model based on Description Logics is straightforward (see Section §9.4), it makes it possible to perform automated analysis on these PPI definitions and infer knowledge regarding the relationships between them and to the process elements. Concretely, in Section §8.1, we introduce this chapter. In Section §8.2, we present PPI templates for its definition, making use of L-PATTERNs explained in Section §8.3. Finally, Section §8.5 summarises the chapter. CHAPTER 8. PPI TEMPLATES AND L-PATTERNS time instants where a BP element activity, pool, or dataObject changes to certain state, or a time instant where certain event is triggered. The PPI is defined as the duration between the time instant when {<BP element> <BP element name>changes to state <state>| event <event name>is triggered} and the time instant when {<BP element> <BP element name>changes to state <state>| event <event name>is triggered}. An example of the L-PATTERN used for the definition of PPI “duration of RFC analysis” (using a time measure) is the following one: The PPI is defined as the duration between the time instant when activity analyse RFC changes to state active and the time instant when activity analyse RFC changes to state completed. 8.3.2 Count Measure When the PPI counts the number of times something happens, the L-PATTERN used to define the PPI is the following one. The user must complete the BP element and the state if the PPI measures a change of state, and the event if the PPI measures the trigger of an event. The PPI is defined as the number of times {<BP element> <BP element name>changes to state <state>| event <event name>is triggered}. An example of use of this L-PATTERN corresponding to the definition of PPI “RFC successfully analysed” (that uses a count measure) is presented below: The PPI is defined as the number of times activity analyse RFC changes to state completed. 8.3.3 Condition Measure When the PPI measures the fulfillment of certain condition, depending on whether this condition is referred to the state of a BP element or to a restriction of a dataObject, one of the two following L-PATTERNs must be chosen. The user must fullfill the BP element and the state in the first case, and the restriction, the state and the dataObject in the second one. The PPI is defined as: <BP element> <BP element name>{is currently | has finished} in state <state>. 104 8.3. L-PATTERN CATALOGUE FOR PPIS The PPI is defined as: dataObject <dataObject name>[in the state <state>] satifies: <restriction on dataObject properties>. An example of use of the first L-PATTERN corresponding to the definition of PPI “RFC under analysis” (that uses a state condition measure) is presented below: The PPI is defined as: activity analyse in committee is currently in state active. An example of use of the second L-PATTERN corresponding to the definition of PPI “RFC with priority high” (that uses a data property condition measure) is presented below: The PPI is defined as the fulfillment of the priority=high over the dataObject RFC. 8.3.4 Data Measure When the PPI measures the value of certain content of a dataObject, the following L- PATTERN is used. The user must complete it with the data content and the dataObject. The PPI is defined as the value of <data content>of <dataObject name>. An example of use of this L-PATTERN corresponding to the definition of PPI “information systems that an RFC affects to” (that uses a data measure) is presented below: The PPI is defined as the value of information systems of RFC. 8.3.5 Derived Measure When the PPI is calculated by applying a mathematical function over some other measures, there appear two possible L-PATTERNs: • one for the case of derived single-instance measures: The PPI is defined as the mathematical function <mathematical function with variables x1, ..., xn>, where <x1>is <definition of the corresponding {time measure | count measure | condition measure | data measure | derived single-instance measure}>, ..., <xn>is <definition of the corresponding {time measure | count measure | condition measure | data measure | derived single-instance measure}> 105 CHAPTER 8. PPI TEMPLATES AND L-PATTERNS • one for the case of derived multi-instance measures: The PPI is defined as the mathematical function <mathematical function with variables x1, ..., xn...>, where <x1>is <definition of the corresponding {aggregated measure | derived multi-instance measure}>, ..., <xn>is <definition of the corresponding {aggregated measure | derived multi-instance measure}> Table §8.5 shows another example of use of the PPI template, for a PPI defined by a derived process measure, taking as starting point the same process. It refers to the scope definition S-1, depicted in Table §8.4 PPI–005 Percentage of RFCs approved from registered Process Request for change (RFC) Goals •BG–002: Improve customer satisfaction Definition The PPI is defined as the mathematical function (a/b)*100 where a is the number of times dataObject RFC is in state approved and b is the number of times dataObject RFC is in state registered Unit of measure none Target The PPI value must be greater than or equal to 90 % Scope The process instances considered for this PPI are described in the analysis period S-1 Source Event logs Responsible Planning and quality manager Informed CIO Comments first values of this PPI are dated in 2007. Table 8.5: PPI specification example (defined over a derived process measure) 8.3.6 Aggregated Measure When the PPI value is calculated by aggregating one of the previous measures in several process instances, the L-PATTERN varies according to the single instance measure that is aggregated. In the following we describe all the possible L-PATTERNs. The parts that need to be completed for the user in each L-PATTERN are those explained before in the corresponding subsection. Furthermore, as stated in Section §6.4.6, in all the cases it is possible to group them by certain data content, and hence the last part of the following L-PATTERNs is added. 106 8.4. MAPPING PPI TEMPLATES AND L-PATTERNS TO PPINOT METAMODEL • Time aggregated measure: The PPI is defined as the {sum | maximum | minimum | average} of the duration between the time instant when {<BP element> <BP element name>changes to state <state>| event <event name>is triggered} and the time instant when {<BP element> <BP element name>changes to state <state>| event <event name>is triggered} [and is grouped by <data content>of <dataObject>] . • Count aggregated measure: The PPI is defined as the {sum | maximum | minimum | average} of the number of times {<BP element> <BP element name>changes to state <state>, event <event name>is triggered} [and is grouped by <data content>of <dataObject>]. An example of this L-PATTERN corresponding to the definition of PPI “number of RFCs per project” is presented below: The PPI is defined as the sum of the number of times event Receive RFC is triggered and is grouped by project of RFC. • Condition aggregated measure: The PPI is defined as the {sum | maximum | minimum | average} of the number of times {<BP element> <BP element name>{is currently, has finished} in state <state>, the <restriction>over the dataObject <dataObject name>[in state <state>] is fulfilled} [and is grouped by <data content>of <dataObject>]. • Data aggregated measure: The PPI is defined as the {sum | maximum | minimum | average} of the value of <data content>of <dataObject>[and is grouped by <data content>of <dataObject>]. • Derived aggregated measure: The PPI is defined as the {sum | maximum | minimum | average} of the value of <mathematical function over single-instance measures>[and is grouped by <data content>of <dataObject>]. 107 CHAPTER 8. PPI TEMPLATES AND L-PATTERNS !"#$%&'"() *"%+($#") ,"-./0+1&2)(&30.) 4#5"/)6&/%$(0-%-) Figure 8.1: Mapping: from the user view to the computer view 8.4 MAPPING PPI TEMPLATES AND L-PATTERNS TO PPINOT METAMODEL Figure §8.2 depicts the mapping from the PPI-template to PPINOT metamodel. It shows that there exists a correspondence 1:1 between the fields identifier,name,goals,responsible, informed and comments and the corresponding attributes with the same names in the class PPI. The same happens with the field unit of measure and the corresponding attribute in class MeasureDefinition. Furthermore, the first three options given for the target correspond to the class SingleTarget and the last one to the class CustomTarget in PPINOT metamodel. Furthermore, the information to be fulfilled by the user in these options corresponds to the lowerBound,upperBound and restriction attributes respectively. Regarding the mapping of the PPI definition, there is also a direct correspondence between the options TimeMeasure,CountMeasure,ConditionMeasure,DataMeasure,DerivedMeasure and AggregatedMeasure, and the classes with the same name of PPINOT metamodel. The information that the user provides by fulfilling the L-patterns, is mapped to a number of condition classes, together with their state and restriction attributes, as well as to the BPElement class. Associations aggregates and aggregationFunction as well as the class AggregationFunction are used to map the information fulfilled in the aggregated measure L-Pattern. Finally, an association called uses and the class Variable is used to map the information contained in the derived measure L-pattern. This last part of the mapping is not contained in Figure §8.2 for the sake of simplicity and readability. Regarding the definition of the scope, Figure §8.3 summarises the mapping between the AP-template and the corresponding part of the PPINOT metamodel. On the one hand, the con- 108 8.4. MAPPING PPI TEMPLATES AND L-PATTERNS TO PPINOT METAMODEL Figure 8.2: Mapping of PPI template to PPINOT metamodel ditions in AP-template are translated to the corresponding classes in the metamodel; concretely, the first condition corresponds to the class LastInstancessFilter, and the information fulfilled by the user is mapped to the attribute numberOfInstances; the second condition corresponds to the class ProcessStateFilter and the information fulfilled by the user is mapped to the attribute processState; finally, the third and the fourth ones correspond to the class TimeFilter. Regarding the information fulfilled by the user, in this case, there are several aspects to be fulfilled, the berfore | after and or | at selection is mapped to an attribute called conditionType (whose value is enumerated), then, if the user choose a date or a time tis mapped to the classes AbsoluteTimeDefinition and RelativeTimeDefinition, respectively. Finally, if the third condition is selected, it is mapped to the value start of the attribute moment, and if it is the fourth condition the chosen, to he value end.Note that all this information of the metamodel is not depicted in Figure §8.3 for the sake of simplicity and readability. On the other hand, with respect to the periodicity, it is mapped to the class Period, concretely, each option is mapped to one of its subclasses Daily,Weekly,Monthly and Yearly, respectively, and the information fulfilled by the user to the corresponding attributes. It is noteworthy that every condition starts with an optional not and ends (except the last one) with an optional and | or. This options are mapped to the class ComposedFilter and allow to form any combination of the different filters (options) provided by using and,or and not. 109 CHAPTER 8. PPI TEMPLATES AND L-PATTERNS Figure 8.3: Mapping of AP template to PPINOT metamodel 8.5 SUMMARY In this chapter we have presented a notation based on templates and L-PATTERNs that can help to define PPIs while keeping the benefits from using natural language and avoiding early formalization of PPIs. Concretely two templates, one for PPIs and one for the definition of the scope have been presented. As previously stated, this notation is easy to learn, promotes reuse, reduces ambiguities and the possibiity of missing information, is understandable to all stakeholders and maintains traceability with the process model. Furthermore we have shown the mapping to our PPINOT metamodel, that will allow a subsequent automated analysis on these PPI definitions. We summarise the problems we overcome with this contribution by means of the Kiviat diagram depicted in Figure §8.4. 110 8.5. SUMMARY PPI-templates and L-patterns Contribution P1: Traceability P7: Tooling support P3: Expressiveness P4: Understandability P2: Ambiguity and incompleteness P5: Visual gap P8: Standard support P6: Automated design-time analysis Figure 8.4: Kiviat diagram for the problems overcome by PPI Templates and L-patterns 111 CHAPTER 8. PPI TEMPLATES AND L-PATTERNS 112 9 AUTOMATED ANALYSIS OF PPIS 113 Technology does not drive change, it enables change. Unknown source, In this chapter we deal with the automated analysis of PPIs. Until now, the effort on this field has been driven to the development of techniques and tools to automatically analyse BPs and PPIs at runtime (specially BAM techniques) and post mortem, i.e. using the information obtained from those process instances already finished (e.g. techniques from the fields of business intelligence, data warehousing and process mining); but little efforts have been conducted to automatically analysed PPIs at design time. We propose here a set of analysis operations, grouped in families, that allow to obtain, at design-time, information implicitly contained in the PPI definitions. This information can assist business process analysts during PPIs definition and business process evolution. Furthermore, we provide a formalisation of the PPINOT metamodel using DL as well as the implementation of the aforementioned operation analysis. Thanks to this formalisation, it is possible to use the power of existing DL reasoning systems to automatically analysed PPIs. The structure of this chapter is the following one: In Section §9.1, we introduce the main issues addressed in this chapter. Then, Section §9.2.2 and Section §9.3 describe two families of analysis operations, one for obtaining the relationships between PPIs and BP elements, and the other for obtaining the relationships between PPIs themselves, respectively. In Section §9.4 we provide the formalisation of our approach using DL. Finally Section §9.5 summarises the chapter. CHAPTER 9. AUTOMATED ANALYSIS OF PPIS relationships between PPIs is very appealing since it helps to detect this conflicts and, hence, to understand better the consequences of trying to optimise one PPI or another. The PPINOT metamodel enables a design-time analysis of these relationships based on the following operations. 9.3.1 PPIs associated to the same, a subset or a superset of the elements of other PPI These operations are derived from the operation PPIs associated to a BP element, explained in the previous section. They take a PPI, the set of PPIs defined by a business process and the corresponding BP model as inputs and returns the set of PPIs that are associated to either: • the same elements as the given PPI: PPISameElements(PPI,PPI[1..∗],BP):PPI[0..∗] • a subset of the elements of the given PPI: PPISubsetElements(PPI,PPI[1..∗],BP):PPI[0..∗] • a superset of the elements of the given PPI: PPISupersetElements(PPI,PPI[1..∗],BP):PPI[0..∗] The information provided by these operations can be useful to find out about possible redundancies amongst the PPIs defined for a business process. For instance, many PPIs associated to a superset of the elements of a given PPI could be an indicator that the PPI is providing redundant information since there are many PPIs associated to the same BP elements. Nevertheless, these operations just provides hints and it is always the task of the PPI modeller to decide whether an indicator provides redundant information or not. 9.3.2 Time-related PPIs that include other time-related PPIs This operation takes a time-related PPI (i.e. a PPI defined by means of a time measure or an aggregation of time measures), the PPIs model and the corresponding BP model as inputs and returns the set of time-related PPIs that are included in it. IncludedTimeMeasures(PPI,PPIs,BP):set <PPI > 120 9.3. RELATIONSHIPS BETWEEN PPIS A time-related PPI p1is included in another time-related PPI p2if the fragment of the process measured by p1is contained in the fragment of the process measured by p2. This can happen in three cases: 1. if both of them are defined over time measures and p2is contained in p1. 2. if p1is defined over an aggregated measure that aggregates a time measure and p2is defined over a time measure and p2is contained in p1. 3. if p1and p2are defined over aggregated measures that aggregate a time measure and p2 is contained in p1. For instance, a PPI defined as the duration between the time instant when the event Receive RFC is triggered and the time instant when the end event Report RFC Approved is triggered includes a PPI defined as the duration between the time instant when activity Analyse RFC starts and the time instant when activity Analyse RFC ends since the process fragment measured by the latter PPI (activity Analyse RFC) is contained in the process fragment measured by the former (the whole process). The information provided by this operation may be useful to find redundant time-related PPIs. Furthermore, it can be used to set dependencies between PPIs since an increase in the value of a PPI included by other PPI may cause an increase in the value of the latter. 9.3.3 PPIs that depends on other PPI This operation takes a PPI, the PPIs model and the corresponding BP model as inputs and returns the set of PPIs that depends directly or inversely with the given PPI. DependsDirectlyOn(PPI,PPIs,BP):set <PPI > DependsInverselyOn(PPI,PPIs,BP):set <PPI > A PPI P1depends directly on another PPI P2if any of these conditions hold: •P1is defined as an aggregation of the measure that defines P2 •P1is defined as a derived measure that is calculated as a mathematical function of the measure that defines P2and the changes in the latter affects the other measure in the same 121 CHAPTER 9. AUTOMATED ANALYSIS OF PPIS direction (positively). For instance, if PercentRequestsApproved =RequestsApproved RequestRegistered × 100, then PercentRequestsApproved is calculated positively from Requests Approved and is calculated negatively from Requests Registered. •P1is a time-related PPI that includes P2. •P1depends directly on another PPI P3and this PPI depends directly on P2 •P1depends inversely on another PPI P3and this PPI depends inversely on P2 Similarly, a PPI P1depends inversely on another PPI P2if any of these conditions hold: •P1is defined as a derived measure that is calculated as a mathematical function of the measure that defines P2and the changes in the latter affects the other measure in the opposite direction (negatively). •P1depends directly on another PPI P3and this PPI depends inversely on P2 •P1depends inversely on another PPI P3and this PPI depends directly on P2 The information provided by this operation is useful to build graphs of dependencies between PPIs so that the analyst can visually analyse the dependencies between the PPIs that have been defined. It can also be used in what-if analyses to evaluate the impact trying to improve a PPI may have on the others and, hence, to identify potentially conflicting PPIs. 9.4 FORMALISING THE PPINOT METAMODEL USING DESCRIPTION LOGICS This section introduces a formalisation of the PPINOT Metamodel using DL, whose two main goals are, as stated before, on the one hand to help eliminating ambiguities in the metamodel as well as to provide more semantics about some of the concepts and relationships, and on the other hand, to facilitate an automated analysis of the PPIs model by leveraging reasoner services available for the formalism. 9.4.1 Mapping the PPINOT Metamodel into DL The mapping of the PPINOT metamodel into DL involves defining a DL knowledge base that includes the classes and relations of the metamodel as axioms of its TBox. In particular, we 122 9.4. FORMALISING THE PPINOT METAMODEL USING DESCRIPTION LOGICS must create one DL concept for each class of the metamodel (keeping the same names) and set in the knowledge base the hierarchies that appear in the metamodel using the concept inclusion axiom (e.g. BaseMeasure vInstanceMeasure vMeasureDe f inition). The directed associations in the metamodel are mapped into roles of the TBox whose domain is the DL concept corresponding to the class of the metamodel that acts as source, and whose range is the DL concept corresponding to class that acts as target. The cardinality restrictions of the associations are mapped as concept inclusion axioms to the source class. For instance, the cardinality restriction: “each Condition appliesTo at most one BPElement” is mapped into the following axiom: Condition v≤ 1appliesTo.BPElement. In addition, we have created inverse roles for most of the roles to make the formulation of some analysis operations easier. For example, roles isUsedBy,isAggregatedBy,isFromFor and isUsedInCondition have been defined as the inverse roles of isDe f inedOver,aggregates, from and appliesTo respectively. Finally, we introduce a new DL role relatesTo as a superrole of the roles that relate measures with conditions (i.e. from vrelatesTo,to vrelatesTo, when vrelatesTo and so on). 9.4.2 Automated Analysis of PPIs using DL An advantage of formalising the definition of PPIs using DL is the possibility to automate the analysis operations described in Sections §9.2.2 and §9.3 by means of DL reasoners. DL reasoners are software tools that implement several operations on the ontologies in an efficient manner by using several heuristics and techniques. Some examples of such operations are: •satis f iability(C): It determines whether a description of the concept Cis not contradictory with the KB. •subsumes(A,B): It determines whether concept Asubsumes concept B, i.e., whether description of Ais more general than description of B. •individuals(C): It finds all individuals that are instances of concept C. •realization(i): It finds all concepts to which the individual ibelongs. On the basis of these operations and the mapping of the metamodel to DL described above, the analysis operations detailed in Sections §9.2.2 and §9.3 can be formulated so that DL reasoners can be used to implement them. Specifically, the approach we follow to formalise these operations in DL is to define the relationship as a new role in the knowledge base and, then to formulate the operations in terms of DL reasoning operations. 123 CHAPTER 9. AUTOMATED ANALYSIS OF PPIS Operations for the relationship measured by This relationship is formalised in DL by defining a new role in the KB (measuredBy), whose domain is BPElement and whose range is PPI so that measuredBy(e,p)means that a BP element eis measured by PPI p. To give semantics to the relationship in terms of the elements defined in the KB we use the fact that the relationship measured by can be inferred from the measure definition of a PPI. The idea is to introduce a new role measures with domain MeasureDe f inition and range BPElement that relates measure definitions with BP elements and, then, use this new role in the definition of measuredBy as follows: measures−◦de f inition−vmeasuredBy Finally, role measures is used to relate each measure definition with the BP elements used in the definition. In the KB, this can be formalised using the composition of roles as follows: relatesTo ◦appliesTo vmeasures measuresData ◦data vmeasures aggregates ◦measures vmeasures isGroupedBy ◦data vmeasures uses ◦re f ersTo ◦measures vmeasures The first two axioms define role measures for base measures, the next two axioms define it for aggregated measures and the last axiom defines it for derived measures. Note that in both aggregated and derived measures role measures is defined recursively based on the measure definitions they aggregate or compose. Based on role measuredBy, the operations for this relationship can be easily formulated as follows: • The BP elements measured by a set of PPIs Pare those elements ethat have a role measuredBy(e,p), where p∈P. In DL, this can be expressed as the result of individuals(∃measuredBy.P). • Similarly, the PPIs that measure a given BPElement eis equivalent to the result of individuals(∃measuredBy−.{e}). 124 9.4. FORMALISING THE PPINOT METAMODEL USING DESCRIPTION LOGICS Operations for the relationship involved in Like in relationship measured by, the elements involved in a PPI Pare determined by its definition, which is expressed in the metamodel by means of a measure definition. Therefore the approach we follow with this relationship is very similar to the one followed with relationship measured by. Specifically, we define two new roles in the KB, namely: role involvedIn whose domain is BPElement and whose range is PPI so that involvedIn(e,p)means that a BPElement e is involved in a PPI p, and role inv whose domain is also BPElement, but whose range is MeasureDe f inition. Finally, the following axiom formalises the relationship between them by stating that the elements involved in a PPI are those involved in its measure definition: inv ◦de f ines−vinvolvedIn Consequently, the definition of role involvedIn can be reduced to the definition of role inv. However, this relationship is more complex than relationship measured by and, hence, we cannot define role inv in a generic way, but for each measure definition. In particular, we add an axiom that represent the BP elements involved in a measure definition mfor each measure definition min the KB. This axiom may vary depending on the type of the measure definition (i.e. time, count, condition, data, aggregated or derived) as detailed in Table §9.1. Next we detail each of the possible cases. Time measure According to Table §9.1 the elements involved for a time measure tm are ∃inv.{tm} ≡ ElemStarttm tElemEndtm tElemPathtm, where: •ElemStarttm is the element where time starts to be measured unless the state in which the measure starts is an end state. In that case, ElemStarttm is empty: ElemStarttm ≡ ∃appliesTo−.(∃from−.{tm} u ¬∃state.EndState) •ElemEndtm is the element used in the condition that specifies when time ends to be measured unless the state specified by the condition is a start state, in which case it is empty: ElemEndtm ≡ ∃appliesTo−.(∃to−.{tm} u ¬∃state.StartState) •ElemPathtm is the BP elements that succeeds the start and precedes the end: ElemPathtm ≡ ∃succ.(∃appliesTo−.(∃f rom−.{tm})) u ∃prec.(∃appliesTo−.(∃to−.{tm})) 125 CHAPTER 9. AUTOMATED ANALYSIS OF PPIS Count measure In this case, the elements involved for a count measure cm are: ∃inv.{cm} ≡ ElemCountcm tInvolvedXorcm, where: •ElemCountcm is the element that is being counted: ElemCountcm ≡ ∃appliesTo−.(∃when−.{cm}) •InvolvedXorcm corresponds to every gateway that precedes the element that is being counted: InvolvedXorcm ≡XorGateway u ∃prec.(∃appliesTo−.(∃when.−{cm})) Condition measure The elements involved for a condition measure cm are: ∃inv.{cm} ≡ ElemCondcm tElemWriterscm, where: •ElemCondcm is the element whose condition is being evaluated: ElemCondcm ≡ ∃appliesTo−.(∃meets−.{cm}). •ElemWriterscm correponds to every activity that can modify, i.e., write the data object whose state is being evaluated if there is any: ElemWriterscm ≡ ∃dataOutput.(DataObject u ElemCondcm) Datameasure The elements involved in a data measure dm are: ∃inv.{dm} ≡ DataMeasureddm ∪ ElemWritersdm, where: •DataMeasureddm is the data object that is being measured: DataMeasureddm ≡ ∃data−.(∃measuresData−.{dm}). •ElemWritersdm is the activities that could have modified that data object ElemWriterscm ≡ ∃dataOutput.DataMeasureddm Aggregated measure The elements involved in an aggregated measure am are: ∃inv.{am} ≡ ∃inv.{bm} t InvolvedDataam, where: •∃inv.{bm}is the elements involved in the base measure that the aggregated measure aggregates (i.e. bm ∈ ∃aggregates−.{am}). •InvolvedDataam is the data that the aggregated measure groups by if there is any: InvolvedDataam ≡ ∃data−.(∃isGroupedBy−.{am}) 126 9.4. FORMALISING THE PPINOT METAMODEL USING DESCRIPTION LOGICS Derived measure Finally, for a derived measure dm, the elements involved will be those elements involved in each of the measures used in the mathematical function applied to calculate the value. Let d1,..., dnbe the first, ..., nth measure definition used to calculate dm ({d1, . . ., dn} ∈ ∃isUsedToCalculate.{dm}), then, the elements involved in the derived measure are the union of the elements involved in these measures: ∃inv.{dm}≡∃inv.{d1} t ··· t ∃inv.{dn}. These definitions have two limitations regarding time measures and count measures that are worth mentioning. The first one is the definition regarding time measures considers all of the elements between the first occurrence of the element that starts the time measure and the last occurrence of the element that ends the time measure. However, if the time measure is cyclic, it only should include the elements until the first occurrence of the element that ends the time measure. The consequence is that if the time measure is cyclic, then the definition may include more involved elements than it should (i.e. those between the first and the last occurrence of the element that ends the time measure). However, from a practical point of view, this only affects when the time measure is defined in a loop since in other cases the first and the last occurrence of the element that ends the time measure coincides. The second limitation is that in count measures we consider every preceding gateway and we do not exclude those opening gateways that were already closed with another one (that is, for instance, a splitting gateway with its corresponding merge). Both limitations could be solved using another formalism such as Petri nets to analyse the control flow of the business process and including the result of the analysis in the KB. For instance, Petri nets could be used to obtain the process fragment between the first occurrence of the element that starts the time measure and the first occurrence of the element that ends it. However, the specific mechanism on how to do so is out of the scope of this paper. Like relationship measured by, operations for relationship involved in can be formulated based on role involvedIn as follows: • Operation InvolvedBPElement, which returns the BP elements that are involved in a set of PPIs Pcan be formulated as individuals(∃involvedIn.P) • Operation NotInvolvedBPElement, which returns the BP elements that are not involved in any PPI of the set of PPIs Pcan be formulated as individuals(¬(∃involvedIn.P)) • Operation InvolvedInAllBPElement, which returns the BP elements that are involved in all of the PPIs included in a set of PPIs Pcan be formulated as individuals(∃involvedIn.{p1} ∩ ...∩ ∃involvedIn.{pn}), where p1, . . . pn∈P. 127 CHAPTER 9. AUTOMATED ANALYSIS OF PPIS • Operation AssociatedPPI, which returns the PPIs in which a given BP element eis involved can be formulated as individuals(∃involvedIn−.{e}). Operations to identify PPIs associated to the same, a subset or a superset of the elements of other PPI The last three operations related to the involved in relationship are classified outside the previous subsection because they allow to extract information regarding the relationships between PPIs. As described above, they returns the PPIs associated to the same, a subset or a superset of the elements of a given PPI pmust be done in three steps. First, a concept InvolvedBPElementqthat represents all the BP elements that are involved by a PPI q (InvolvedBPElementq≡ ∃involvedIn.{q}) is defined for each PPI qincluded in the KB. This allows the DL reasoner to classify all these concepts by using DL operation subsumes. Then, this classification is used to obtain the concepts that are equivalent or a subset or a superset to the concept InvolvedBPElementpdepending on whether we are defining operation PPISameElements,PPISubsetElements or PPISupersetElements, respectively. In each case, the result is a set of InvolvedBPElementp1, . . ., InvolvedBPElementpnconcepts. The final step is to obtain the PPIs p1, . . ., pnassociated to those InvolvedBPElement concepts. These are the resulting PPIs. Operation Included Time-related PPIs In order to implement this operation, we define a new role in the KB called inlcudes, whose domain is MeasureDe f inition and whose range is also MeasureDe f inition so that includes(m1, m2)means that a measure definition m2is included in a measure definition m1. According to the definition of the inclusion relationships given in Section §9.3.2, we define a set of inference rules1that allow to obtain the corresponding inclusion relationships. Let m1,m2,n1and n2be four measure definitions, c1,c2,c3and c4four timeInstantConditions, and e1,e2,e3, and e4four BP elements, then, the three inference rules corresponding to the three possible cases of inclusions are: 1Rules are expressed using a syntax close to the Semantic Web Rules Language (SWRL). 128 9.4. FORMALISING THE PPINOT METAMODEL USING DESCRIPTION LOGICS from(?m1, ?c1),appliesTo(?c1, ?e1), from(?m2, ?c2),appliesTo(?c2, ?e2),succeeds(?e2, ?e1), to(?m1,?c3),appliesTo(?c3, ?e3), to(?m2,?c4),appliesTo(?c4, ?e4),precedes(?e4, ?e3)−→ includes(?m1,?m2) aggregates(?m1,?n1),f rom(?n1,?c1),appliesTo(?c1, ?e1), from(?m2, ?c2),appliesTo(?c2, ?e2),succeeds(?e2, ?e1), to(?n1,?c3),appliesTo(?c3, ?e3), to(?m2,?c4),appliesTo(?c4, ?e4),precedes(?e4, ?e3)−→ includes(?m1,?m2) aggregates(?m1,?n1),f rom(?n1,?c1),appliesTo(?c1, ?e1), aggregates(?m2,?n2),f rom(?n2,?c2),appliesTo(?c2, ?e2), succeeds(?e2,?e1), to(?n1,?c3),appliesTo(?c3, ?e3), to(?n2,?c4),appliesTo(?c4, ?e4),precedes(?e4, ?e3)−→ includes(?m1,?m2) Furthermore, we also define another role, called inlcudesPPI, whose domain and range are PPI and that establish the inclusion relationship between two PPIs, i.e., analogously to includes(m1, m2),includesPPI(p1, p2)means that a PPI p2is included in a PPI p1. We finally define an inference rule that allows to obtain the inclusion relationship between PPIs: isDe f inedOver(?p1,?m1), isDe f inedOver(?p2,?m2), includes(?m1, ?m2)−→ includesPPI((?p1,?p2) Where p1and p2are two PPIs. Operation Depends on PPIs As stated in Section §9.3.3, a PPI P1depends directly on another PPI P2if one of the five conditions indicated hold. In order to implement this operation, the task is twofold: 1. We define roles aggregates,includes and isCalculatedPositively as subroles of dependsDirectlyOn 129