Keywords

1 Introduction

Decisions are a key aspect of every business and its processes. Traditionally, decisions have been modelled either inside business process models or through decision logic using business rules or decision tables, amongst others. Recently, the Decision Model and Notation (DMN) standard [16] has been released with the aim of providing constructs to model decisions and decoupling decisions from process models. DMN can be used to model human decision-making, to identify requirements for automated decision-making and to implement those decisions.

Optimal decision making, and decision management as a more general concept, is of utmost importance for the achievement of strategic and operational goals in any organisational context. Therefore, decisions should be considered as first-class citizens that need to be modelled, measured, analysed, monitored to track their performance, and redesigned if necessary [8]. Similarly, Nura et al. [15] argue that currently, decisions are based on quantitative and qualitative proofs that can be measured by means of statistical methods for the former or using techniques like benchmarking or balance scorecard for the latter. In addition, they claim that by means of decision measurement organisations can set targets and get feedback on the progress made towards their objectives.

Regarding the analysis of a decision, several approaches agree on the importance of differentiating the quality of the decision that is judged by the process followed to reach the decision; and the quality of its outcome and the associated consequences [7, 10, 13]. According to those authors, a good decision does not guarantee a good outcome because of uncertainty presented in the decision process; and just looking at the decision outcome does not provide information about the quality of the decision. Most scenarios found in the literature evaluate decisions on the basis of the knowledge and preferences of the decision makers, such as in [2, 7]; and few information is taken from evidences in an objective manner, or is related to the process in which the decision takes place. Decisions are also studied in the context of business processes. However, authors have focused on the modelling of decisions and the analysis of the definition of decisions themselves, in terms of accuracy, certainty, consistency, covering and correctness [6, 11, 20]; using performance values to define decision rules [5] or providing languages for the definition of those decisions [17]; but to the best of our knowledge, no prior integrated work exists that analyses the relationship between decisions modelled in DMN and process performance and that evaluates decision performance itself based on data from event logs.

In this paper, we identify and analyse this relationship from three different perspectives. First, we analyse the impact of decisions on process performance and how this information can help the decision-making process. Second, we focus on the performance measurement of decisions themselves based on evidences gathered from the process execution. Finally, we analyse how process performance measures and indicators can be used for the definition of decisions. Furthermore, we also introduce solutions for the representation of these relationships: the concept of decision performance indicator (DPI) is proposed; PPINOT Metamodel [22] and the DMN standard are extended and integrated to propose a formal alternative for the measurement of decision performance; and the inclusion of performance information in decisions is improved providing more expressiveness by using PPINOT. Our proposal is applied to decisions made within the context of business processes and, ideally, modelled using DMN or a similar notation. Therefore, these decisions are usually made several times because they are repeated in each process instance.

The rest of the paper is organised as follows. Section 2 introduces the DMN standard in a real scenario. Section 3 analyses the relationship between decisions and performance measurement, whose representation using DMN and PPINOT is shown in Sect. 4. Section 5 presents the related work. Section 6 contains a brief discussion of the proposal. Finally, Sect. 7 concludes the paper.

2 Decision Model and Notation in a Running Example

DMN [16] is a standard for describing and modelling repeatable decisions within organisations, which provides a readily understandable notation by business and IT users and ensures that decision models can be automated and interchangeable. Two levels are used in DMN to model and describe decisions. For the first one, the requirement level, decision requirement diagrams (DRD) are used. They comprise a set of elements, their connection rules and a corresponding notation. For the second one, the decision logic level, the Friendly Enough Expression Language (FEEL) is provided for defining and assembling decision tables, calculations, if/then/else logic, etc. In addition, a notation for decision logic (boxed expressions) is provided to graphically represent those expressions and to show their relationship with elements of a DRD.

Figure 1 shows a DMN model based on real decisions made as part of the IT incident management process of a public organisation whose identity or characteristics cannot be revealed for privacy reasons. The IT Department receives and records incidents in one of its information systems. Incidents are resolved by agents external to the organisation, so before resolving them it is necessary to determine their priority level and the resource responsible for resolving it. By way of example, we focus on decisions related to the priority setting of IT incidents. The model was built with information provided by the organisation and the related data presented along the paper were taken from event logs of the aforementioned information system. An incident can be classified with the highest (P1), the intermediate (P2) or the lowest priority level (P3). This level determines the resource allocation and the total time allowed for the resolution of each incident. The priority is assigned considering two values: First, the level of impact (major, high, medium or low), which is a measure of the criticality of an incident often equal to the extent to which an incident leads to degradation of agreed service levels, and usually considers the number of people or systems affected. Second, the urgency (high, medium or low), which refers to the necessary speed for resolving an incident of a certain impact.

Fig. 1.
figure 1

Decisions in an IT Incident management process modelled using DMN.

Full size image

A decision denotes the act of determining an output from a number of inputs, using decision logics. In our example, the main decision “Priority setting” requires information from two decisions (“Urgency resolution” and “Impact resolution”) and from Input data (“priority_log” and “IT_incident_log”). Solid arrows represent Information Requirements of decisions. “Priority setting rules” represents a so-called Business Knowledge, which encapsulates business know-how in the form of business rules or other formalisms. The invocation of a Business Knowledge by a decision logic of a decision is made by means of Knowledge Requirements depicted as a dashed arrow. Finally, “Normative of incident management” is a knowledge source that denotes an authority. In our case, the internal documentation establish relationship between systems and users, which must be taken into account to determine the level of impact and urgency.

Two tables, called Boxed Expressions, conform the notation provided by DMN to represent logic decisions. Invocation is a container for the parameter bindings that provides the context for the evaluation. Decision tables are a tabular representation of a set of related input and output expressions, organised into rules indicating which output applies to a specific set of input entries. In Fig. 1, both tables are included. The decision table shows an excerpt of all decision rules that can be defined to evaluate the priority of an incident. The decision table only shows rules for those incidents whose current priority is P1. Four input values are required to make a decision. The status_incident describes the current state of the incident selected: “Registered” refers to unresolved recorded incidents. The current_priority is P1, but in a complete table the value could be null (to do the first assignation), P1, P2 or P3; this is required because an incident priority may be evaluated and changed more than once. The impact and urgency are values stemming from previous decisions.

3 Analysis of the Relationship Between Decisions and Performance Measurement

There is a well-known relationship between decisions and business processes [1, 3, 4, 12], which has been analysed from different angles. However, although process performance is a relevant part of business process management, its relationship with decisions and decision models has not been analysed in depth. In this section, we identify and analyse this relationship from three perspectives, namely: the impact of decisions on process performance, the performance measurement of decisions themselves based on evidences gathered from the process execution, and the use of process performance indicators on the definition of decisions.

3.1 Impact of Decisions on Process Performance

Decisions are a key part of business processes and, as such, they can have an impact on their performance [14] that can be observed through their impact on their process performance indicators (PPIs). PPIs are quantifiable metrics that allow an evaluation of the efficiency and effectiveness of business processes [21]. Specifically, we can say that a decision has an impact on a PPI if the PPI value changes depending on the output selected in the decision. This fact is already acknowledged by DMN, which explicitly allows modelling the impact of decisions in performance indicators [16] by means of the relation impactedPerformanceIndicator. Thus, this relation enables the definition of a set of decisions and the performance indicators impacted by them. Figure 2 depicts an example of this relationship, in which PPI-1 and PPI-2 are identified as being impacted by Decision-1 and Decision-2, respectively. This example also allows one to identify indirect impacts between decisions and PPIs: Decision-1 has an indirect impact on PPI-2 because Decision-2 has an impact on PPI-2 and Decision-2 depends on Decision-1.

Based on relationships like those shown in Fig. 2, and on data about the execution of processes that allows the computation of PPIs, it is possible to obtain insights about the impact of decisions on process performance. Next, we detail two ways in which this information can be exploited.

Fig. 2.
figure 2

Example of relationships between decisions and PPIs

Full size image

Warn About Potential Performance Issues. PPIs include a target value that allows one to determine whether they are fulfilled or not. Those PPIs that are not being fulfilled enable the identification of process improvement areas. Therefore, a description of relationships, as shown in Fig. 2, can be used to identify all those decisions that have a direct or indirect impact on PPIs that are not being fulfilled. The result is a set of decisions that might be causing a negative impact on the performance of the process. These decisions should then be analysed by domain experts to determine whether they are actually having a negative impact on the performance or not.

Insights About How a Decision Impacts a PPI. The relationship between decisions and PPIs can also be useful to identify how a specific decision value (outcome) may impact a PPI. This can be done by computing the PPI for each outcome of the decision and comparing the values obtained for them. Table 1 gathers data related to PPI-1, which is defined as the total time spent by an IT Department to solve an IT incident and whose target value is less than 30 h. This table shows how the priority decision impacts on PPI-1. The depicted data correspond to 476 PPI-1 values calculated monthly during November 2017, using PPINOT tool suite. Although the priority value of an incident may change several times, for our example, only the last priority value registered was considered. Specifically, only those cases where priority value after the last evaluation remained P1 or changed from P1 to P2 or to P3 were taken into account. Value column represents the PPI value for those cases in which the output of the decision is the one specified in the first column of the table (h stands for hours). Instance column represents the number of instances whose current decision is P1 and changes to another one.

Table 1. Influence of output decision in process performance - Part I
Full size table

Several interesting conclusions can be derived from this table. First, it is clear that the value of PPI-1 depends on the decision analysed because it changes significantly depending on the decision made, especially if the decision is to change from P1 to P2. Second, contrary to expectations, changing from P1 to P3 does not significantly increase the resolution time required, but the opposite. Possibly, this is because this decision is made when the incident has been thoroughly analysed, the causes have been identified and its priority has not been identified as critical. Third, it provides insights about actions that can be taken to improve the performance of PPI-1. Specifically, we can try to reduce the time it takes when the decision is P2.

3.2 Performance Measurement of Decisions

Decision measurement has been recognised as an important aspect within the organisation, because it helps to identify the progress made towards their objectives [15] and because the quality and speed of decisions may influence the success within an organisation [14]. Statistical methods or benchmarking and balance scorecard techniques are used to measure decisions [15]. Certain approaches, such as [2, 7, 14], suggest measures to assess decisions, but most of them are based on information provided directly by participants using surveys and interviews about users opinions or preferences, and not on objective data.

PPIs quantify the performance of a process in an objective manner, calculating their values with data generated within the process. Decisions have been decoupled from business processes to provide flexibility in the process management. With the aim of quantifying decision performance, in this paper we propose the concept of decision performance indicator (DPI) as analogous indicators that can also be computed from data gathered from the process execution. A DPI can relate to both the activities of the process where the decision is made and the decision elements (inputs, outcomes or other decisions, for example).

Considering the four performance dimensions defined in the Devil’s quadrangle: time, cost, quality and flexibility, we discuss how the first three dimensions can be addressed using DPIs. Concerning time and cost, they can be applied in the same way as in the activities of a business process since, in this context, a decision is usually considered an activity. Therefore, one can measure for instance the elapsed time to make a decision or the cost of making the decision by considering the resources involved and the time spent in the decision. In our IT incident management scenario, a DPI that measures time could be “the total time spent to make a priority assignment decision should be less than 10 min.”

Theories on the quality of decisions emphasize the differentiation between the quality of the decision as a process and the quality of the output [10] because the output may depend on external factors that are not under the control of the decision-maker. Factors that may influence the quality of decisions are [10]: Decision makers, who have their own knowledge and experiences; the frame as the possible ways of seeing the decision or its resolution contexts; the set of viable alternatives created for each frame; the decision maker’s preferences; the information that we know; and the logic by which the decision is made. As it usually happens with quality, it cannot be measured directly, but it is possible to find proxies for it. In this way, in our IT incident management scenario we could define DPIs to evaluate decision makers such as “at least 80% of the people that make the priority escalation decision must be senior developers,” DPIs to evaluate information, like “at least 95% of incidents must have the root cause field filled,” or DPIs to evaluate the quality of the output, like “at least the 85% of incidents must not have changes in their priority”.

3.3 Use of Performance Indicators on the Definition of Decisions

A decision involves a set of inputs and rules that are evaluated to determine an output. Inputs usually represent literal values or information provided by input data [16], as shown in Fig. 1. However, in some cases, decisions could require information provided by measures or indicators related to the performance of the process [17]. For instance, in the context of our example, let us suppose that it is necessary to inform the management staff when the time an IT incident is in Priority 1, or the number of evaluation iterations for the IT incident exceed some predefined thresholds. Under these conditions a decision table can be constructed, but in this case its inputs are a set of performance measures that need to be evaluated to determine the need to send an alert or not and the type of it. Therefore, a mechanism to be able to include process performance information into decisions is necessary to support these use cases. Furthermore, it would also be possible to consider not only the value of a performance measure, but its prediction [5]. For instance, one could also consider the predicted total resolution time as an input for the priority decision.

4 The Decision Performance in PPINOT

In this section we propose an integrated approach for representing the relationships described above that extends the DMN standard and PPINOT, an existing solution for PPI management.

4.1 PPINOT

PPINOT [22] is a metamodel for the definition and modelling of PPIs, which has high expressiveness, allows the definition of PPIs in an unambiguous and complete way, facilitates traceability between business process elements and PPIs and promote the fulfillment of SMART criteria (specific, measurable, achievable, relevant and time bounded). In PPINOT a PPI is defined by means of a set of attributes: goals, indicating its relevance; a target value to be reached; a scope, which defines the subset of instances to be considered during its calculation; a set of human resources involved and a measure definition that specifies how the PPI is computed.

Measure definition is a complex attribute that can be one of three types: base measures that measure time, count, state conditions or data over a single process instance; aggregated measures to aggregate one base measure over several process instances; and derived measures used for the calculation of a mathematical function over other measures (aggregated or not). Measures are connected with processes by Conditions that indicate how and when to take values from the process, and DataContentSelections to obtain an attribute of a data object.

Furthermore, PPINOT also comes with a template-based notation that provides a set of linguistic patterns to allow user-friendly definitions of PPIs [23]. Table 2 shows linguistic patterns for the definition of measures based on the PPINOT Metamodel (see Fig. 3). It has been extended to allow definitions of PPIs considering decisions concepts. Gray boxes in the figure comprise the PPINOT extension that will be explained in following subsections.

Table 2. L-patterns for measure definitions in PPINOT
Full size table
Fig. 3.
figure 3

Excerpt of the PPINOT metamodel

Full size image

4.2 PPINOT on the Impact of Decisions on Process Performance

The DMN metamodel considers a relationship between classes Decision and PerformanceIndicator to specify the list of indicators impacted by the decision. However, as PPIs are not DMN’s objective, PerformanceIndicator class does not provide specialised attributes to clearly and unambiguously define PPIs; which could provide errors and inconsistencies in calculating and analysing information. In this sense, we propose to integrate DMN with PPINOT to benefit from the aforementioned characteristics for the definition of PPIs. This is carried out by refining the class DMN:PerformanceIndicators in the DMN metamodel with the class PPINOT:PPI. This means, for instance, that these PPIs modelled with PPINOT can be automatically computed and analysed by means of tools developed on the basis of the PPINOT metamodel [22]. This automation could facilitate the calculation of, for example, the values presented in Table 1.

Similar to Table 1, Table 3 gathers PPI values of the average time spent in solving an incident that changed priority from P2 or P3 to another priority value. In this case, the results show data computed using PPINOT tool suite from a total of 99937 instances of our scenario event log. It can be seen that the change from priority P2 to P1 did not reduce the resolution time, probably because resources allocated to solve incidents with P1 are not enough or because the analysis before solving P1 incidents is more exhaustive and requires more time. For incidents with P3, the behaviour is the expected: if priority changes from P3 to P1 the resolution time is less than if it changes from P3 to P2.

Table 3. Influence of output decision in process performance - Priority times
Full size table

4.3 Definition of Decision Performance Indicators in PPINOT

Based on the PPINOT metamodel, we argue that the performance of decisions can be measured in three dimensions. First, we may be interested in measuring the output of a decision in terms of how many times each output occurs. Second, we may be interested in measuring the time a decision (or a part of a decision) takes. Obviously these two dimensions could be combined (e.g., the average time a decision takes grouped by its output). And third, we may want to know the quality of the information involved in the decision, because in some cases, a decision is made without all the information originally required, due to the high cost for obtaining that information (in terms of time or resources assigned). For example, if urgency value is not known, a policy could be defined for the Priority setting decision in which if the current_priority is null or P3 and impact is major, the incident priority is automatically changed to P1.

We propose an extension of the PPINOT metamodel that allows the modelling and definition of DPIs over DMN elements, taking into account the three dimensions identified. Just like a PPI definition and based on it, we define a DPI as a quantifiable metric that allows the evaluation of the efficiency and effectiveness of decisions, and it shares its attributes with a PPI: target, scope, etc. Figure 3 shows the PPINOT metamodel including new elements to support the measurement of decisions, depicted in light grey.

In the metamodel, a performance indicator (PI) is related to all indicator attributes. From PI, PPI and DPI are derived. PPI is defined over business processes and DPI over DMN decisions. The measure definition attribute can be instantiated as one of a set of measures. In the context of decisions, several of those measures can be reused. First, both TimeMeasure and CountMeasure are related to a Condition, specifically a TimeInstantCondition. For a TimeMeasure two time instants are required: the starting (from) and ending (to) points when values will be taken. The CountMeasure requires a time instant to indicate the moment when the value is taken. The TimeInstantCondition can be applied to a MeasurableElement that can be instantiated as a BPElement for a PPI definition, or as a DMNElement for a DPI definition. DMNElements can be: decision, business knowledge, input data or decision tables. DataMeasure measures the value of an attribute of a DataObject or a DMNElement in this case, being possible to specify a condition to obtain this information. Both AggregatedMeasure to consider several instances and DerivedMeasure to define formulas, can also be reused for decisions. By way of example, a DPI could be defined as the average time spent to assign an IT incident priority, whose scope is comprised by all instances and its target is set to less than 4 hours. On the basis of PPINOT templates [23] and linguistic patterns (see Table 2), the PPI is defined in Table 4. The LinearTimeMeasure pattern specifies its measure definition.

Several patterns can be used to define other types of DPIs. For example, a CountMeasure and its linguistic pattern can be used to define a DPI to count the number of decisions made or to know the number of times that a specific outcome was selected in a decision. By combining a DataMeasure and a DerivedMeasure it is possible to identify decisions with particular values such as “urgency” null and “current_prioriy” P3. Thus, the quality of information involved in a decision can be evaluated, because it is possible to identify decisions whose output has been selected with a lack of information. We have not found evidence about the possibility of using a StateCondition in the context of the performance measurement of decisions, reason why it was not included in the PPINOT metamodel extension.

Table 4. Example of DPI definition using template and linguistic patterns
Full size table

4.4 Using PPINOT PPIs in the Definition of Decisions

In order to provide greater flexibility and expressiveness on the definition of decisions, we propose the use of PPIs in the definition of decisions by means of the extension of DMN boxed expressions with linguistic patterns of PPINOT.

Boxed invocations use business parameters to indicate the business knowledge model to be used, and each parameter is accompanied by a binding expression that indicates the value assigned to the parameter for the purpose of evaluating a business knowledge model invoked. In our proposal, a boxed invocation is extended to include measure definitions as parameters, expressing them through PPINOT linguistic patterns. The value of this measure will be evaluated in a decision table, where according to the value obtained for each measure, a particular output can be selected. In the same way, a boxed invocation can also be extended to include PPIs as parameters. In this case, the extension incorporates: a scope, to indicate instances involved in the calculation; the target, to specify the expected PPI value; and a measure definition that indicates how to calculate the PPI. The evaluation in a decision table consists of identifying if the PPI target value is achieved or not. Decision tables are not extended because they support literals, values and expressions that can also be used to evaluate new parameters. Unlike the previous subsection, here we focus on PPI definitions and the complete set of MeasureDefinitions, because we want to measure process performance and use this information as an input to make decisions.

Let’s suppose a scenario in which two types of alerts, time_alert and workload_alert, can be sent depending on specific values obtained from the process (see Fig. 4.a). Boxed expressions receive PPINOT measure definitions as inputs. The Invocation (on the left) lists measures involved in the decision “Decide alert”: execution_time and number_it_incidents_received. The column “type” indicates whether the measure is applied over a single instance or over a set of them using an aggregated operation. Traditional attributes of Boxed Invocations can also be used, such as priority_type to indicate the incident current priority. The decision table (on the right) contains the same measures as the invocation. Rules are defined to select a type of alert, according to the knowledge of experts and depending on the value established for each one. This decision table is implemented using traditional FEEL expressions. The second example shown in Fig. 4.b depicts a decision that involves two PPIs. Here, the invocation table is extended to include the scope, the target value and its measure definition. The decision table maintains its structure but in this case, the rules to evaluate PPI values are based on true-false values to indicate whether the PPI target value has been reached. In invocation, as many measures or PPIs as needed can be included as inputs.

Fig. 4.
figure 4

Example of PPINOT measures (a) and PPIs (b) DMN box expressions.

Full size image

5 Related Work

Relations between business processes and decisions, and specifically decisions modelled in DMN, have been addressed in different approaches. For example, [1] proposes the integration of processes and decision modelling using BPMN and DMN, [4] derives decision models from business processes, [12] relates processes and decisions by means of a set of integration scenarios, or [3] presents frameworks for adjusting decision models dynamically according to the business process environment and ensure SLA compliance, to name a few. However, process performance is not considered in the context of these relationships.

Other proposals focus on the quality of the logic expressed in decision tables. To this end, measures such as certainty, consistency and covering are proposed to evaluate a set of decision-rules extracted from a complete [18], incomplete [19] or an ordered decision table [20]. In the same vein, [11] proposes an algorithm for measuring rule set consistency evaluating similarity between different rule sets; and [6] proposes algorithms for correctness checking tasks over DMN tables. However, they do not evaluate each decision instance, but the decision model expressed as decision tables.

More related to our proposal are [5, 9], which are related to the impact of decisions in process performance. Specifically, [9] derives decision criteria formulated as decision rules based on experience gained through past process executions, although they do not consider the specifics of the DMN standard. Concerning [5], the authors propose a formal framework to derive decision models from event logs using DMN and BPMN and taking into account predictions of PPIs. However, they are concerned with obtaining decision models instead of helping to understand the consequences of each decision. Regarding the performance measurement of decisions, [2] addresses the quality of customer decisions using measures mostly based on preferences of decision makers and not on objective data taken from the process. Finally, the use of performance indicators in the definition of decisions is dealt with in [17], which proposes a query language to extract information from process or task instances that allows definitions of measures in boxed invocation.

6 Discussion

The analysis of the performance-decision relationships and the application of the integrated approach introduced for representing them using DMN and PPINOT in our scenario have shown improvements on the current state-of-the-art in three main directions. First, the analysis of the impact of decisions in performance complements the work of [5, 9] by focusing on helping to understand the impact of decisions explicitly modelled using notations such as DMN and has proven to be very useful in our scenario. It also helps to identify the more problematic decisions to be analysed (i.e. those related to the PPIs with undesired values), preventing an important waste of time and effort that would be put on analysing hundreds of decisions otherwise. Finally, the integration of PPINOT in DMN to represent this relationship makes it easier the automated computation of PPIs. Second, with the novel concept of DPI proposed and the specific mechanism with templates and patterns provided, the performance of decisions can be defined and measured based on the data generated along the execution of the process. This opens a new way of measuring the performance of decisions that can be used to complement or replace more traditional approaches [2, 7] that measure the performance of decisions using more subjective data such as surveys and do not take process information into account. And third, the use of the complete toolbox provided by PPINOT for the management of PPIs in DMN boxed expressions means an enrichment of the type of information that can be currently added as decision criteria in proposals such [17], whose definition language is less expressive than PPINOT; or [5] that does not focus on the definition of metrics.

Along the application of our approach to the evaluation scenario, some limitations were nevertheless identified. Concerning the impact of decisions in performance, although some tasks like the computation of Tables 1 and 3 can be automated, it remains, however, a domain-expert task to propose how to improve a decision in the light of the gathered insights. To do so, it would be interesting to explore the use of machine learning techniques to support this task. Furthermore, the computation of Tables 1 and 3 could also be extended so that the “priority” is not considered a single value, but the set of priorities the incident was assigned during its life. Finally, regarding DPIs, most of the limitations stem from deficient information sources. In order to define and compute measures, PPIs and DPIs, certain information must be available in the corresponding logs. However, this is not always the case. For instance, the information about the instant when a decision starts to be considered or the experience of a decision-maker are often missing. Therefore, if we need to measure the duration of a decision or the influence a user’s experience has on a decision output, it will be necessary to cross-check information from different sources, in case this information is actually recorded somewhere. Nevertheless, the quick pace at which BPMSs are improving their support to decision management makes us think that more and better information concerning decisions will be available soon, mitigating this issue.

7 Conclusions and Future Work

This paper seeks to improve the understanding of the relationship between decision management and performance measurement. The main conclusion of our analysis is that decision management can be significantly enriched by considering performance indicators and their relationship with decisions in three different perspectives: the impact of decisions on process performance, the measurement of the performance of decisions and the use of PPIs and performance measures as inputs for decisions. Some advantages of explicitly defining these relationships have been encountered, such as the provision of important insights regarding possible dysfunctional decisions from a performance point of view or the identification of possible actions to be taken to improve the performance. Furthermore, in this paper we also outline how these relationships can be modelled and supported by extending PPINOT. However, performance relationships could be represented using other performance notations or techniques as it has been partially shown in papers such as [17]. The future work is aimed at developing an exhaustive evaluation of each of the relationships identified between decisions and performance measurement and extending PPINOT tools to facilitate the modelling and management of DPIs.