Last Updated on November 19, 2022 by maximosecrets

This is the third article in a series on the Service Level Agreements application. The first two in the series:

• Introduced SLAs and showed how you could manually apply them to a Service Request. You can find the article here: http://maximosecrets.com/2021/11/08/service-level-agreements-1-an-introduction/
• Discussed the SLA filter criteria and matching process that applies a single SLA to a Service Request. You can find the article here: http://maximosecrets.com/2021/11/08/service-level-agreements-2-applying-a-single-sla/

In the first two articles we were keeping things simple with an SLA only having one commitment. An SLA can have multiple commitments and it is also possible to apply multiple SLAs to a Service Request or Work Order, the subject of this article. This article will show how applying multiple SLAs based on Commitment Stringency works.

Organizations – SLA Options

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 there is an action for SLA Options. These site-based options will allow for multiple SLAs to be applied to a Service Request or Work Order (or other ticket and work order classes). The second set of radio buttons will only appear if you set the first set to “Allow Application of Multiple SLAs?”.

In the second article only one of our SLAs 1029 and 1036 could be applied because the current setting for the BEDFORD site is “Allow Application of One SLA?”. But we will now change that and set “Allow Application of Multiple SLAs?”. 

The second set of radio buttons will need some explaining and we will start with the default “Apply Multiple SLAs Based on Ranking”. When Maximo applies SLAs to a service request or work order there is a filtering of the bank of SLAs to see which candidates could be applied based on the information entered on the service request or work order. So, what happens if more than one SLA is a match to the data entered?

If “Allow Application of One SLA?” is set the answer is simple, it will be the one with the highest Ranking value but note the lower the number the higher the ranking and so 1 is the highest-ranking value. The ranking field is an integer that allows values greater than zero. I would restrict the range to perhaps between 1 and 99, starting out at 50 so that you can add SLAs with both higher rank (1-49) and lower rank (51-99). 

It will take some time to work out how you want to use the Ranking field based on the combination of the filter fields. But I’ll give you two examples to get you thinking.

1. If you had an SLA with a Classification of 1 \ 103 \ 10301 \ 1030101 – End User Issue \ Facility \ Heating/Air \ Too Hot, and another SLA with a Classification of 1 \ 103 – End User Issue \ Facility, then if on the Service Request the classification was entered as 1 \ 103 \ 10301 \ 1030101 then both SLAs are a match and either could be applied. The one which has a classification of 1 \ 103 \ 10301 \ 1030101 probably should have a higher Ranking value, it looks to be a better match.
2. If you had SLAs with a Classification, and SLAs with both a Classification and an Internal Priority, then which should have the higher rank? For example, if you have SLAs for the same Classification and one with an Internal Priority of 1 and another with Internal Priority 2, they could have equal ranking, as only one of them could be a match, if the Internal Priority was entered on the Service Request. On the other hand, if the Internal Priority on the Service Request was 3, 4 or blank then the SLA with the classification and no internal priority is a match, and the other two SLA are not a match. No two SLAs would be applicable, in which case it does not matter whether one has a higher Ranking value than the other, it would make no difference.

If “Allow Application of Multiple SLAs” is set, then Maximo will evaluate all SLAs to see which are a match. It will then either:

• Apply the SLAs based on highest ranking (Apply Multiple SLAs Based on Ranking)
• Apply the SLAs based on the earliest target date (Apply Multiple SLAs Based on Commitment Stringency)

When set to “Allow Application of Multiple SLAs” you get to see all the candidate SLAs which were a match because they are stored in a table called SLARECORDS. This is the table that the action View SLAs is based on.

If you are going to use setting Apply Multiple SLA Based on Commitment Stringency, then it does not matter how you use the Ranking field, if at all (which is what I would suggest) as the Ranking field will not be used. 

Let’s see what happens with the setting of “Apply Multiple SLAs Based on Ranking”.

Note. I will return to the other set of radio buttons when I write an article that involves creating an Escalation to monitor the SLA commitment.

Apply Multiple SLAs based on Ranking

Using the Apply SLA action on Service Request 1307 now shows our two SLAs 1029 and 1036 as being candidates for application to the Service Request. However, if you look closely only SLA 1029 has been applied as the Response Time (in the dialog) ties up with the Target Start field. The Target Finish field on the service request is blank, SLA 1036 was not applied. This is because the setting for applying multiple SLAs is based on Ranking. SLA 1029 had a ranking of 25 and SLA 1036 had a ranking of 30, 25 is a higher rank than 30, hence SLA 1029 was applied. If you are using Multiple SLAs based on Ranking then it would be a good idea to add the Ranking attribute to the View SLAs dialog as it will help in the design for Ranking values you enter for your SLAs.

Even if both SLAs had the same ranking, only one would be applied, and it would probably be a random selection. If you use this SLA options setting, then you ought to design the ranking so that no two matching SLAs would end up with the same ranking.

Apply Multiple SLAs based on Commitment Stringency

With the SLA Options setting in Organizations application set to Apply Multiple SLA based on Commitment Stringency, then the View SLAs action on Service Request 1307 shows both SLA 1029 and SLA 1036 as candidates for application to the service request. This table is based on the object SLARECORDS.

This time Maximo looks for the earliest Response Time and uses this for the Target Start. It also looks for the earliest Resolution Time and uses this for the Target Finish. You can see that the Target Start and Target Finish dates are the same as those shown for the two SLAs. In this case multiple SLAs have been applied. 

Note. If there are two rows in the View SLAs dialog it does not mean that both SLAs were applied, you will need to compare the dates with the target dates to see which was applied. The multiple rows shown are candidate SLAs, those which have passed the matching process, it isn’t restricted to two records, there may be several. There isn’t a field to indicate which SLAs were actually applied. 

When SLAs have Multiple Commitments

I have revised SLA 1029 to add three commitments: Contact – 2 hours, Response 1 Day, Resolution 15 Days.

I have revised SLA 1036 to add three commitments: Contact – 3 hours, Response 12 Hours, Resolution 5 Days.

Back on Service Request 1307 and having used the Apply SLA action, we can see the results in the View SLAs dialog. 

• The most stringent Contact Time comes from SLA 1029 – 03-Nov-21 08:00
• The most stringent Response Time comes from SLA 1036 – 04-Nov-21 10:00
• The most stringent Resolution Time comes from SLA 1036 – 23-Nov-21 14:00

The most stringent times have been used to provide the Target Contact, Target Start and Target Finish.

Incidentally with a Reported Date of 02-Nov-21 14:00, and using a calculation calendar/shift of DAY/DAY which is 8 hours/day Monday to Friday, then:

• The most stringent contact commitment is 2 hours which equates to 03-Nov-21 08:00.
• The most stringent response commitment is 12 hours, this is less than 1 day (24 hours), which does equate to 04-Nov-21 10:00.
• The most stringent resolution commitment is 5 days or 120 hours (5×24). This is 15 working days at 8 hours per day. This does calculate correctly to 23-Nov-21 14:00.

Please note that when you give a commitment in DAYS this only works well when there is no calendar, otherwise I would advise using HOURS. You know that 40 Hours is one working week for a 09:00 to 17:00 shift that operates Monday to Friday. Would you have thought that a Resolution of 15 Days on SLA 1029 would have resulted in a Resolution Time over two months later on 04-Jan-22 14:00? If you convert that to hours it is 360 hours (on a 24-hour clock) and you may recognise this instantly at 9 weeks, just over 2 months. Hopefully you get my point.