You can monitor Service Level Agreements (SLAs) with Escalations and Key Performance Indicators (KPIs).

Escalations

The Escalation tab in the Service Level Agreements application is used to define an Escalation to an SLA Commitment. There is a one-to-one relationship between an SLA and an Escalation, but each SLA Commitment can create its own Escalation Point. The Escalation Point is created by using the Define Escalation button on the Commitments table window. If this is the first Escalation Point to be created for the SLA, then the Escalation will also be created.

The Escalation is for the same Applies To object as the SLA. The Escalation Condition has a similar structure for all Applies To objects and it performs a subquery on the SLARECORDS table to apply the Escalation to the records which have been associated with the SLA linked to the Escalation. This works perfectly well for Ticket and Work Order based applications where there is an Apply SLA action that will write records to this table; however, this table is not populated by other applications or objects. For example, you can have an SLA based on the ASSETS object but there is no action that will write a record to the SLARECORDS table for the Asset, and so you cannot monitor the SLA Commitment.

In most cases the Escalation Point will monitor an Elapsed Time Attribute, which is a date field in the Applies To object or one of the three date fields in the SLARECORDS object, CONTACTDATE, RESPONSEDATE or RESOLUTIONDATE. In most cases for Service Requests and other ticket-based objects the Elapsed Time Interval will be based on TARGETCONTACTDATE, TARGETSTART or TARGETFINISH. For work order based objects this will be TARGSTARTDATE or TARGCOMPDATE. The Escalation Point Condition will be a test to see if the corresponding actual date remains null, i.e. the SLA commitment is stopped when the actual date has been entered, for TARGSTARTDATE the condition would be ACTSTART is null.

The Elapsed Time Interval and Interval Unit of Measure are used together. If the Escalation Point condition still applies at the time, then perform the associated Actions and Notifications. For example, 0.00 HOURS will perform the actions and notifications when time now has reached the value in the field indicated by the Elapsed Time Interval, at the Target Start Date if no Actual Start has been entered then perform the actions and notifications. A negative is a time before this and a positive is a time after. For example, -30 MINUTES would perform a set of actions or notifications 30 minutes before the Target Start Date has been reached if no Actual Start has been entered.

For Commitments that are not based on an Elapsed Time Interval date then the Escalation Point Condition is used.

The Escalation Point can be set to repeat until the condition is found to be false, for example a notification is sent every time the escalation runs until a time when the Service Request has an Actual Start date. You need to be mindful of bombarding people with system generated emails as they will soon cease to be read. You could instead increase a numeric field by one every time the escalation repeats and then add to a Start Center Result Set portlet the worst offending SLAs where breaches have occurred. The notifications generated from SLA based Escalations can be viewed from the Communication Log tab.

Additional Escalation Points can be created for the same SLA Commitment either by using the Define Escalation button or by using the New Row button below the Escalation Points table window.

When you change the SLA’s status to ACTIVE the Escalation will be made Active if there are no issues preventing this. When the SLA is made INACTIVE the Escalation will also be made inactive. There are actions to Activate/Deactivate an Escalation, Delete the Escalation, or Validate the Escalation.

The Escalation tab is really just a window onto the Escalations application, but it is more controlled than providing open access to the Escalations application, which like Actions and Communication Templates is part of the System Configuration module which should be restricted to administrators or those who know what they are doing. Unless you restrict the Schedule field on the Escalation, you might still have the escalation running every 1 minute with the likely impact on performance.

Key Performance Indicators (KPIs)

The KPIs tab allows you to create a KPI or associate one or more KPIs with the SLA. In Maximo terms a KPI is a SQL Select and Where clause that when combined and run calculate a single numeric value that can be compared against a Target, Caution At or Alert At values. This will derive a coloured indicator, red, yellow or green when compared with the last calculation made, the Current Value.

The last two calculated values for a KPI will give an indication of trend, up or down arrows and coloured according to the band that they are in. The KPI Manager application also supports a trend graph, and a schedule can be created for how frequently you wish a new calculation to be made.

There is a KPI Templates application. For example, you have the ability to measure downtime on 100 critical assets on which your SLA is based. Each of these will need to be an individual KPI but they can be created relatively easily using a KPI Template.

The KPIs tab on the SLA is showing the current state of each individual KPI relevant to the SLA in the one place. If you wanted to perform a notification when the SLA is in breach because of one or more KPIs where the Current Value would have drifted into the red zone compared with the Alert At value, then you would base an Escalation on the SLA table, but the query would need to use the SLAKPI table which is what links the SLAs and KPIs together and the KPIMAIN table which is where all the values for the KPI are held.

You could create an Escalation Point for each individual KPI, but this would take some time to set up manually.