PPINOT

PPINOT is a set of tools and techniques for the definition and automated analysis of process performance indicators.

Registered Tool

Getting Started

A key aspect in any process-oriented organisation is the measurement 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, the management of these PPIs throughout the whole BP lifecycle is crucial.

PPINOT is a set of libraries aimed at facilitating and automating the PPI management. The support includes their definition using either a graphical or a template-based textual notation, their automated analysis at design-time, and their automated computation based on processing an event log obtained from a process simulator or a Business Process Management System.

PPINOT is integrated into PRspectives, which is a multi-perspective business process modeler that allows the definition of PPIs graphically by means of a web-based editor based on Oryx, or by using templates and linguistic patterns. The BPMN model together with the PPIs defined for it can be exported to an standard BPMN 2.0 XML file with some PPI-specific extensions.

PRspectives is available at http://prspectives.services.governify.io/. You can create and edit your own process models with PPIs by login using your Google or Facebook account. In addition, we have already created a public business process model called “RFC” (Request For Change) to help you to try the editor, so you do not need to crate a new business process model from scratch.

An example of process with a set of PPIs defined, that corresponds to the RFC process model is found below.

You can also run PRspectives on your own server following these instructions.

Documentation

PPINOT currently covers aspects related to the design, analysis and execution  of PPIs, having at its core the PPINOT Metamodel. In this section you can find some information and documentation about the way all this works.

  • Regarding the design aspect, it provides two alternatives: the graphical edition of PPIs and their template-based definition. It puts, thus, at users’ hand, notations that do not require technical knowledge.
  • Furthermore, it also offers a set of analysis operations to be automatically performed on the previously defined PPIs. These operations provide the users with information regarding the relationships between the businesss process elements and the PPIs as well as between the PPIs themselves.
  • Finally, with respect to the execution, it is also possible to take the PPI definitions (created using one of the two aforementioned alternatives) and import them into an open source BPMS, allowing thus the computation and reporting of PPI values.

Design – PPINOT Metamodel

The PPINOT Tool Suite uses at its core the so-called PPINOT Metamodel. This metamodel for the definition of PPIs presents a set of benefits summarised below:

  • It allows an unambiguous and complete definition of PPIs.
  • A PPI de fined using the PPINOT metamodel can always be traced back to the business process (BP) elements used in its de finition.
  • It is independent of the language used to model business processes.
  • It is the basis for the Visual PPINOT and the PPI Templates, that allow PPI definitions easily understandable by non-technical people.
  • It has been provided with a set of analysis characteristics for the extraction of information on the relationships between PPIs and BP elements.
  • It allows the automated instrumentation of business processes in a BPMS for the PPI values computation, as described here.

The following pictures depict the PPINOT Metamodel by using UML diagrams. The first figure shows an overview of the PPI definition, presenting all the attributes that need to be defined for a PPI.

The second figure presents a classification of the measures associated to PPIs, according to two dimensions: the number of process  instances  necessary to calculate the PPI value (single- or multi-instnace) and the type of measure that can be used to calculate it (time, count, condition, data and derived).

The third and last figure corresponds to an aspect of the metamodel worthy of further mention, the scope. It allows the user to filter the process instances to be considered for calculating the PPI value. Several filters can be defined attending to conditions on the number of instances, temporal aspects and the process instance state.

This metamodel is translated to an XML using this XML schema. The following page shows an example of an XML file containing a PPI definition.

Design – Visual PPINOT

The following figure presents a summary of the constructs of Visual PPINOT, that allows the depiction of PPIs over business process diagrams and is based on the PPINOT Metamodel.

This graphical notation has been integrated into a web-based business process editor, so that the user can visually define PPIs over business process models. Try the Visual PPINOT Editor here.

Furthermore, some empirical studies have been conducted to evaluate different aspects of our graphical notation.

Design – PPI Templates

Apart from the graphical notation, there exists the possibility of defining PPIs by means of a set of templates and linguistic patterns (L-Patterns, filling placeholders in prewritten sentences) provided for this purpose. They are also based  on the PPINOT Metamodel and help to structure the information in a normalised form, reduce ambiguity and promote reuse while serving as a guide to avoid missing relevant information. Furthermore, filling placeholders in prewritten sentences, i.e. using L–Patterns, is easier, faster and less error-prone than writing them from scratch.

In the following we show these templates. The notation used in the templates is the following: words in ligh blue colour,  between “<” and “>” are placeholders for either literals (lower case) or L-patterns (upper case first letter); words between “{” and “}” and separated by“ |´’ are one-only options; words between “[” and “]” are optionals.

The first template allows the definition of the attributes of a PPI, and is called PPI Template.

Within the PPI Template, there can be a reference to a scope (S-x) defined by means of another template. This Scope Template is shown below.

Analysis

We describe here a set of analysis operations, grouped in families, that allow obtainining, 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, these analysis operations are automated by mapping the PPINOT metamodel into a Description Logics (DL) knowledge base and then using standard DL reasoning operations to analyse it instead of implementing ad-hoc analysis algorithms.

We focus on two families of operations:

  1. PPIs-BP: operations that obtain information about the relationship between PPIs and the elements of a business process at design-time. We distinguish two different relationships, depending on wether we focus on those BP elements whose execution is used to calculate PPI values (MeasuredBy) or those that have (or can have) an influence in them (InvolvedIn). These operations helps during instrumentation of business processes, or during their evolution.
  2. PPIs-PPIs: operations that obtain information about the relationship between PPIs themselves at design-time. These operations are defined taking into account, apart from the aforementioned InvolvedIn relationship, to help to identify redundancies in the definition of PPIs, relationships of inclusion and dependencies, helping also to detect potential conflicts between PPIs.

The following table summarises the catalogue of analysis operations grouped by the aforementioned families and relationships. It also details the inputs and outputs in every operations. The reference business process is always an input for any operation.

Execution

Taking as starting point any of the available PPI defi nitions (graphical or templates), PPINOT also provides the possibility to extract the information required to compute PPI values from Activiti, an open source BP management platform, and to create reports with these values. More information coming soon.

Modelling Service Level Agreements for Business Process Outsourcing Services

Service level agreements (SLAs) have been used by many proposals in the last decade to automate different stages of the service lifecycle, using a formal definition of the different parts of an SLA such as service level objectives (SLOs), penalties, or metrics, to automate their negotiation, the provisioning and enforcement of SLA–based services, the monitoring and explanation of SLA runtime violations, or the prediction of such violations. What all of these proposals have in common is that most of them have been designed for computational services. Therefore, they are aimed at enhancing software that supports the execution of computational services such as network monitors, virtualisation software, or application servers with SLA–aware capabilities, where there are no human or non-automatic tasks involved in service consumption.

On the other hand, business process outsourcing (BPO) services are non–computational services such as logistics, supply–chain, or IT delivery services, that are based on the provisioning of business processes as services, providing partial or full business process outsourcing. Like computational services, their execution is regulated by SLAs and supported by specific software. In this case, since BPO services are process–oriented, the software that supports them is usually a process–aware information systems (PAIS) such as ERPs, CRMs, or business process management systems (BPMSs). However, unlike computational services, there is little work related to the extension of PAIS with SLA–aware capabilities to support BPO services.

A PAIS with SLA–aware capabilities, i.e. an SLA–aware PAIS, is a PAIS that uses explicit definitions of SLAs to enable or improve the automation of certain tasks related to both the SLAs and their fulfilment such as performance monitoring, human resource assignment or process configuration. For instance, an SLA–aware PAIS could be automatically instrumented according to the metrics defined in the SLA so that when there is a risk of not meeting an SLO, an alert is raised allowing the human actors involved in the process to take measures to mitigate the risk. Another example could be the automated configuration of the process, e.g. removing or adding activities, executed by the SLA–aware PAIS depending on the conditions of the SLA agreed with the client.

Apart from the benefits derived from the automation of these tasks, the need for a SLA–aware PAIS becomes more critical in a business–process–as–a–service scenario. A business–process–as–a–service is a new category of cloud–delivered service, which, according to Gartner, can be defined as “the delivery of BPO services that are sourced from the cloud and constructed for multitenancy. Services are often automated, and where human process actors are required, there is no overtly dedicated labour pool per client. The pricing models are consumption–based or subscription–based commercial terms. As a cloud service, the business–process–as–a–service model is accessed via Internet–based technologies.” In this setting, the conditions of the SLA agreed with each client may vary. Therefore, it is crucial for the PAIS that supports the business–process–as–a–service to behave according to the SLA agreed with the client. An example could be the prioritisation of the execution of tasks for those clients whose SLAs have bigger penalties if they are not met.

Our proposal to model BPO SLAs combines well founded approaches and standards for modelling computational SLAs and PPIs. Specifically, we rely on WS–Agreement, which provides the general SLA structure, BPMN, which is used to model the business process related to the service, PPINOT, which allows the definition of metrics, and iAgree, which provides a language to define SLOs and penalties. The details can be found at a paper published at CAISE 2015.

In the following we present the real scenarios to which our approach has been applied.They take place in different scenarios

Most of them take place in the context of the definition of statements of technical requirements (SOTR) of a public company of the Andalusian Local Government, from now on Andalusian Public Company, APC for short, while other belongs to the SLA template published by the Government of the Northwest Territories (GNWT), in America.

Who are using PPINOT

  • IT department of the Andalusian Health Service
  • BPT group at Hasso Plattner Institut (University of Potsdam)
  • Information and Communication Service of the University of Seville