Last Updated on October 29, 2023 by maximosecrets

The Service Level Agreements (SLA) application is a powerful application but can be a bit difficult to understand. Then there are two versions the one you get in base Maximo and the one which Maximo for Service Provider clients use, which is the one embedded in other Maximo products like Maximo for Aviation or IBM Control Desk (ICD). This article is part of a series exploring the functionality of Service Requests and so I will be using the SLA application that you find in base Maximo. Most of the article will still be relevant to those of you with Maximo for Service Provider installed which I will now call SLA(SP) to make the distinction between the two.

Note. If you have SLA(SP) installed then you do not see the SLA application, it is replaced, and you will not find it if you are looking in the Application Designer application. There are user interface differences between the two applications. 

This article is also part of a series looking at the SLA application and I aim to extend to include the differences between SLA and SLA(SP). To date I have written content for:

• Service Level Agreements – An Introduction, this includes manually applying an SLA to a Service Request.
• Applying a Single SLA – The Matching Process
• Applying Multiple SLAs

There are KPIs, Escalations, Supporting SLAs, and creating SLAs for other objects than Service Request or Work Order to cover. So, plenty to write about, as I said it is a powerful application.

What is a Service Level Agreement?

The IT Information Library (ITIL) definition of a Service Level Agreement is “A written agreement between an IT service provider and the IT customer(s) defining the key service targets and responsibilities of both parties.”

In the context of Maximo, a maintenance department provides services to the operations team to keep the assets running. They are providing services, managing them and are accountable for these services, but what is often missing is the service targets. We know that zero downtime or another maintenance measure based on 100% of something is unlikely to be achieved and this is accepted by all parties, even if it isn’t written down. But where is the line between acceptable and unacceptable, the service level that maintenance should be striving to achieve?

The SLA application in Maximo allows you to define these service targets, then apply, measure, and monitor them.

• The SLA Commitments define the service targets. An SLA may have multiple SLA Commitments.
• An SLA is explicitly applied to a Service Request or Work Order, or it is implicitly applied to any Maximo main level object through its definition.
• You can measure the effectiveness of an SLA with a Key Performance Indicator (KPI).
• You can also monitor an SLA using an Escalation which will let you know when breaches have occurred, or limits have been reached.

ITIL also makes a reference to its Service Management models as being “intended to be reusable in a variety of organizational contexts and to help to take advantage of economies of scale and efficiencies.”. There is a lot that the maintenance world can learn from the IT world, particularly in this area which falls under Service Design. For a Maximo client to move from maintenance to service management is a big cultural step to take. For those clients taking their first steps towards service management the two applications in the Service Level Agreements module, Service Groups and Service Level Agreements are your starting point.

Defining an SLA

In the Service Level Agreements (SLA) application I’ve created a new SLA and used the autokey, which is normal. I’ve entered a description “Respond within 1 working day” and have used the Applies To lookup to find object SR – a Service Request. The Applies To lookup provides the set of objects in Maximo referenced as Main Objects (or it used to). What you won’t find in the list are child tables, for example PR line, PO line, Inventory Usage line. Not all applications have a main object in Maximo, for example Inventory Usage (INVUSE) is not defined as a main object and you cannot create an SLA for it, but you’ll find few other applications like this, ones without a main object.

The Type field has three options, CUSTOMER, INTERNAL and VENDOR.

• A CUSTOMER type is used for the agreement with the organization that requires the service, an SLA, it is the default for the field.
• An INTERNAL type is used for the agreement with another internal party that also helps to provide the service. An Internal SLA is sometimes called an Operational Level Agreement (OLA).
• A VENDOR type is used for the agreement with an external party that helps to provide the service. Also known as an Underpinning Agreement. This type has a link with Maximo Contracts.

Maximo SLAs can be related to each other so that a CUSTOMER type SLA is supported by an INTERNAL or VENDOR type SLA. The Related SLAs tab is used to define these relationships.

The Status field is initially set to DRAFT and must be set to ACTIVE to be applied to a Service Request or Work Order. If you no longer require the SLA, you can make it INACTIVE, however, it won’t be hidden from the List tab of the SLA application. To make changes to an SLA you will need to make it INACTIVE, make your change and then make it ACTIVE again. There is no View Status History action.

Notice that the Organization and SiteA structural element of a Maximo database that is used for data separation. More fields are empty, but they are not read-only, you can still modify their values. These are used in filtering the SLAs when working out which to apply to a Service Request or Work Order. The SLA object is defined at the System level in Maximo.

When defining the SLA, you should also enter the following fields, although they are not mandatory:

• Service Group – The category or group for multiple types of service.
• Service – The type of service, or a sub-category of service
• SLA Administrator – The person responsible for administering and monitoring the SLAs

I have entered FACILITY and ENVIRON for the two-level service category, the Service Group and Service respectively. I have also entered myself AJE – Andrew Jeffery as the SLA Administrator.

The Customer/Vendor Contact field is the person who you correspond with from the customer or vendor about the SLA.

I will not explain the other important fields like Ranking and Classification yet, and I will come back to this section and the three sections below this in the article Applying a Single SLA. You can manually apply an SLA to a Service Request or Work Order without using these fields. 

I can hear some people saying you have to use Ranking and Classification, not true, as you will find out. I can hear others saying we never use Service Group and Service. These two fields underpin service management in Maximo, and it is a better starting point and easier to implement than a full classification hierarchy for all the services you provide, which may take many weeks to create.

We will now look at the Commitments table.

In the Commitments table you can enter multiple commitments. It is quite normal for a Service Request to have two or three commitments, Response and Resolution, sometimes also Contact. These three commitment types are time-based, and they will calculate the three target dates on a service request:

• Response commitment calculates the Target Start
• Resolution commitment calculates the Target Finish
• Contact commitment calculates the Target Contact

Incidentally, the Contact commitment type will not show if the Applies to object is WORKORDER, because there is no Target Contact date on a work order. The Contact, Response and Resolution commitment types will not show for any object that is not one of the ticket or work order classes because they cannot be used to calculate a date on another Maximo object. 

Many of the other commitment types are asset-based, Availability, Capacity, Reliability, Downtime. They are not restricted to use with the ASSET object. The Delivery commitment type is normally used with the PO object and the Other commitment type can be used with any object.

I’ve created a Commitment for SLA 1029 with a commitment type of RESPONSE, a description of “Response 1 Working Day”, a Value of 1.00 and Unit of Measure of DAYS. The SLA can be saved and the status changed to ACTIVE. This is all we would need to do, to apply an SLA manually to a Service Request.

The Time Period (Days) is not available when the Type is CONTACT, RESPONSE, or RESOLUTION. It is used with the other Commitment Types, for example: 

• AVAILABILITY – 80 PERCENT in 30 Days (Time Period)
• DOWNTIME – 5 DOWNTIME (hours) in 30 Days (Time Period)
• RELIABILITY – 5 FAILURES in 7 Days (Time Period)
• DELIVERY – 14 DAYS – I would leave Time Period (Days) blank, it wouldn’t make sense to use it.

I did come across an issue which I have raised with IBM Support. The four example commitment types just mentioned, and CAPACITY and OTHER all have the same internal value in the Synonym Domain COMMITMENTTYPE, the internal value is OTHER. If you try to create a second commitment which also has the internal value of OTHER, you will receive the error message “BMXAA3945E – A commitment of this type already exists for this SLA.” 

Commitments are supposed to allow you to have only one of each commitment type, except for the Commitment Type of OTHER where you should be able to have as many as you like, you make the distinction between them using the Description field.

Note. While I have entered a Response of 1 DAYS my recommendation is to use a Unit of Measure of HOURS when the Commitment Type is CONTACT, RESPONSE or RESOLUTION. DAYS is converted to 24 hours and so it is not a Working Day. This is deliberate as I wanted to illustrate this point. 

Explicitly Apply the SLA – No Matching

In this section I am referring to Explicitly Apply the SLA, because in applications like Service Request and Work Order Tracking there are a set of actions which are used to apply the SLA – it is an explicit action. 

You could have an SLA against the SR object that you never explicitly apply to a Service Request but which you still measure with a KPI and monitor with an Escalation. For example, no more than 10 service requests are to miss their response time in any 30-day period. This is an example of an implicitly applied SLA, although you won’t find that phrase in any Maximo documentation. In this case you apply the SLA by simply changing its status to ACTIVE.

I’ve created a new Service Request 1307 with a description of SLA Test and after save used the Apply SLAs action. The error message “BMXAA3965E – Please select a site before applying an SLA.” was received. You must first add a value to the Site field on the Service Request, before you can apply an SLA, I entered BEDFORD for the Site. Note, this is not the Asset Site field.

When you use the Apply SLA action you may get the error message “BMXAA3946E – No applicable SLA(s) found for this record.”. This action is using filter criteria on the SLA to match against the values you have entered on the Service Request to see if there is a match, if so, the SLA may be applied. The filter criteria will be the subject of the 2nd article in this series, it is where we will return to the fields Ranking and Classification.

You can apply an SLA without adding any filter criteria to the SLA by using the action Select/Deselect SLAs. This will show you any SLAs that have already been applied to the Service Request. There has been none so far, and so we will use the New Row button to add one. The Select SLAs dialog now opens. There is a radio button to “Show Filtered SLAs” or “Show All SLAs”. As we have no filter criteria, we will select the “Show All SLAs” option and use the Refresh button. SLA 1029 is now displayed, and we can select this.

SLA 1029 is transferred to the Select/Deselect SLAs dialog. If you used the New Row button again you will more than likely receive the error message “BMXAA3954E – Only one SLA may be applied to a record. Please remove the existing SLA to continue.” This is because there is an option in the OrganizationsA structural element of a Maximo database which is used for data sharing and is often aligned to a legal entity of an organisation. More application to allow you to apply multiple SLAs, or not, this is the subject of the 3^rd article in this series. Notice the Delete button at the end of the row, this is used to Deselect an SLA.

After pressing the OK button, the SLA Applied checkbox with now be ticked (not shown). A Target Start has been calculated one day after the Reported Date, which acts as the seed date for calculating the target dates when SLAs are applied to a Service Request or Work Order.

Using the View SLAs action, we can see that SLA 1029 was applied and that its Response Time was 03-Nov-21 16:19. This table window is based on a table called SLARECORDS which records the details of the SLAs which were candidates for being applied to a Service Request or Work Order.