Last Updated on November 19, 2022 by maximosecrets
The Service Level Agreements (SLA) application will be found in the Service Level module, and it is used to calculate target dates on the ticket and work order based applications – the service targets. Most often it is used by the Service Requests and Work Order Tracking applications.
There are two versions of the application, the one that comes with base Maximo and the one that comes with the Service Provider add-on. We will assume that Service Provider is not being used, although much of what we will describe will be relevant to Service Provider users.
An SLA has a mandatory Applies To field which is the object against which the SLA will be applied, this is likely to be SR or WORKORDER. While you can choose other objects like ASSET this would be documenting your SLAs but wouldn’t cause any calculations to take place in Maximo. There is no function to apply an SLA to an Asset.
The SLA has a Type field with three options, CUSTOMER, INTERNAL and VENDOR. Customer is the most likely to be used and is the default. Internal is for Operational Level Agreements (OLAs) between two internal parties. Vendor is used for an agreement with an external party, otherwise known as an Underpinning Agreement (UA) and is used with Maximo Contracts. There is no difference in Maximo functionality between CUSTOMER and INTERNAL.
The Related SLAs tab is used to relate one SLA with another, for example a customer SLA is supported by an internal or vendor SLA.
SLAs have a simple set of statuses, DRAFT, ACTIVE or INACTIVE. There is no status history and inactive SLAs are not hidden. Active SLAs are read-only, therefore, to make a change to an active SLA, you make it inactive, make the change and then change status to active again.
SLAs are defined at the System level. There is a A structural element of a Maximo database that is used for data separation. More and Organization field, but these are used as filters when applying an SLA to the Applies To object and are not used for data separation or data sharing purposes.
Much of what you see in the SLA application is associated with filtering SLA records to see which are applicable to a ticket or work order record. There is a matching process where the record on which an SLA might be applied is reviewed and candidate SLAs that meet the criteria of the ticket or work order are determined and then one or multiple are applied based on either a ranking value or based on stringency. This means that the SLA that would derive the most stringent or earliest target date will be the one applied.
Site and Organization are part of this matching process. For example, a Service Request for the BEDFORD site would only be a match for SLAs that reference the BEDFORD site, or the EAGLENA organization because the BEDFORD site belongs to the EAGLENA organization, or which have no reference to a Site or Organization. Incidentally on a Service Request you must enter a Site before you can apply an SLA.
Service Group and Service are also used in the matching process and these two fields are to be recommended because they underpin Service Management in Maximo. Many clients do not use these two fields opting to use Classifications instead, but this is like wishing to implement Service Management without putting in the foundation layer. Besides, it is quicker to establish a two-level code for Service Groups and Services than a whole classification hierarchy which is rarely found to be correct first time because implementers tend to focus more on the contractual obligations, in Maximo terms the commitments, rather than focusing on how easy it will be to navigate a classification hierarchy that will lead to the correct SLA being applied.
In the Commitments table you enter your obligations regarding the SLA. In most cases the Type field for a Service Request SLA will be CONTACT, RESPONSE or RESOLUTION. For a Work Order it is only RESPONSE and RESOLUTION because there is no Target Contact Date, consequently the Type of CONTACT will not be shown in the Select Value lookup for work orders. The Response type will calculate a Target Start Date using the Reported Date as the seed date, and the Resolution type will calculate a Target Finish Date.
For commitments of type CONTACT, RESPONSE or RESOLUTION you will need to enter a Value and Unit of Measure which would be a time-based unit, for example 4 HOURS, 7 DAYS, etc. You can enter a decimal value, but for 2.5 HOURS it may be better to use 150 MINUTES. Incidentally if you wish the time-based commitment to be in working time then you need to use a unit of measure of HOURS and not DAYS, as Days is interpreted as 24 hours, elapsed time and not working time.
For other Applies To objects that are not ticket or work order based, then the commitment type of CONTACT, RESPONSE or RESOLUTION cannot be selected as there are no dates to calculate. Instead, there are commitment types like AVAILABILITY, CAPACITY, DOWNTIME, RELIABILITY, DELIVERY and OTHER. The OTHER commitment type is the only one which allows you to have multiple records of the same commitment type, use the Description field to differentiate between these commitments.
For other Applies To objects the unit of measure may not be time-based, but the SLA may be based on Hours of Downtime, Number of Failures, Percent, Number of Users, or Other. Depending on the nature of the commitment you may wish to enter a Time Period (Days), for example for an AVAILABILITY commitment you may enter 80 PERCENT with a Time Period of 30, meaning our commitment is 80% availability over any 30-day period.
You can explicitly apply SLAs by using the action Apply SLA. This action can also be performed via an Escalation or via Workflow using the Action called ‘SR APPLYSLA’ which invokes the Application Action APPLYSLA. This Application Action is also available for Work Orders but there is no ready built Action for it.
When you apply an SLA Maximo starts the matching process against the bank of SLAs for the Applies To object that are at ACTIVE state. It will filter by the Site on the Service Request or Work Order to look for SLAs that are specific to a Site or Organization. It will filter by the Service Group and/or Service on the Service Request or Work Order. It does much more than this which will be the subject of the next article.
But before we leave the introduction to a Service Level Agreement there are two other actions that you will find in applications like Service Requests and Work Order Tracking. The Select/Deselect SLAs action allows you to delete an applied SLA or manually add another. There are radio button options to ‘Show Filtered SLAs’ or ‘Show All SLAs’. The View SLAs action shows the SLAs that were applied to the Service Request or Work Order, notice I am using the plural here, as a setting in the A 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 will allow multiple SLAs to be applied.