Last Updated on November 19, 2022 by maximosecrets
In the first article on Service Level Agreements (SLAs) we said that there was a matching process between the record on which an SLA will be applied and the SLAs that had been defined in the Service Level Agreements application. To allow this matching process to proceed the SLA has several fields and some table windows which are used as filter criteria against which the record will be evaluated before an SLA is applied. Further, what happens if multiple SLAs are matching to the details entered on the Service Request or Work Order, how does Maximo decide which is applied?
Filter Criteria
In the first article we said that the SiteA structural element of a Maximo database that is used for data separation. More and Organization fields were being used as filter criteria. The Service Request must have a value in the Site field to use the Apply SLA action. If the Service Request is for the BEDFORD site, the SLA’s which reference BEDFORD, or organization EAGLENA without reference to a site, or reference no Site or Organization, will be a match.
We also said that Service Group and Service fields were being used as filter criteria. If both fields have been entered on the SLA, then both field values must be on the Service Request for there to be a match. If both fields have been entered on the Service Request, then an SLA with the Service Group and a null Service would still be a match as would an SLA with both Service Group and Service as null values.
The Applies to field which provides the Maximo object on which an SLA can be applied, can also be considered as a filter criterion, but there are several other fields which we did not mention last time.
In the Dates section there is a Start Date and an End Date which provides a period of time against which the SLA will be valid. The Reported Date on the Service Request will be compared against these two fields and if the Reported Date is after the Start Date and before the End Date or the End Date is left null then the SLA will be considered a match.
The Classification field is also part of the filter criteria. The Classification you enter needn’t be at the end of the hierarchy, a leaf node, but anywhere in the hierarchy that makes sense. The Service Request will be a match if it has a classification value that is the same or lower in the classification hierarchy than the classification referenced on the SLA.
There are two calendar sections the Applies To Calendar and the Calculation Calendar, we will be returning to the Calculation Calendar later. The Applies To Calendar must have all three fields Organization, Calendar and Shift entered. The Reported Date and Time on the Service Request is compared with the work periods of the calendar and shift to see if it exists within a work period. For example, if the Calendar was used to indicate the operational hours of a facility between 08:00 and 18:00 Monday to Friday then a call received at 16:00 on a Thursday would make the SLA a match, but it would not be a match if the call was received at 20:00 or on a Saturday or Sunday.
The Vendor field on the SLA is also part of the matching criteria and if used then the Organization field will also be entered. For the SLA to be a match the Service Request must reference the same Vendor and the Site on the Service Request must exist within the Organization referenced on the SLA.
On the Assets and Locations tab in the Service Level Agreements application there are two other tabs, Assets and Locations, and Asset Types, both of which have a table window allowing multiple records to be entered. An example where this may be used is if the response times are faster for conference rooms than other parts of a building.
In the Assets and Locations table the two fields are mutually exclusive, if you enter a location and the asset field already has a value it will be blanked, and vice versa. The Description field shows the description of either the asset or the location. If the SLA reference’s multiple locationsA physical place where assets exist and where work can be performed. More and or assets, then the SLA will be a match if the Service Request’s location or asset exists in the SLAs Asset and Locations table. Assets and Locations exist in hierarchies, there is no hierarchy search as there is in the Service Provider version of the Service Level Agreements application.
If you use the Asset Types on the SLA, then it will be a match to the Service Request if the Service Request references an asset that belongs to one of the asset types referenced. If the asset has no asset type, then the SLA which references an Asset Type will not be a match.
When using Assets or Locations as SLA filter criteria then you should consider using the Site field which will act as a filter for the locations and assets that you can enter. But there is another reason and that is performance. When Maximo is searching the SLA table for suitable candidates that may be a match there is an initial query which includes the Site field, then for those SLA records that are a match Maximo needs to evaluate each one for other filter criteria including the assets and locations referenced. There would be little point evaluating hundreds of assets and locations in the TEXAS site if the Service Request was for the BEDFORD site, only to find that no asset or location existed. This can be avoided if the SLA referenced a Site. An SLA that references multiple assets and locations from different sites should be avoided, instead duplicate, and make each SLA site specific.
You might have been thinking up to now, where do I enter the Priority in the Service Level Agreements application? The final part of the filter criteria is in the ‘Additional SLA Criteria’ section, which has just one field for entering a SQL Where clause that you can build using the SQL Expression Builder. For example, if you entered ‘internalpriority <=2’ then the SLA will be a match to the Service Request if it had an Internal Priority of either 1 or 2. If it had no Internal Priority the SLA would not be a match.
As we conclude this section on the filter criteria you must now have realised that you should not apply an SLA too early on a Service Request or Work Order. If most of your SLAs are using the Classification and Internal Priority as filter criteria, then a Service Request needs to have had those two fields entered before the Apply SLA action is used.
Applying an SLA
You apply a Service Level Agreement using the Apply SLA action on the ticket and work order based applications, this could also be achieved via an Escalation or by using Workflow. The matching process considers all of the filter criteria mentioned earlier, if there are multiple filter criteria then all of them must evaluate to true for there to be a match to the record where the SLA is being applied. From a SQL point of view consider this as having a logical AND between each part of the filter criteria, not an OR. For Locations and Assets think of this as having a logical OR, the Service Request’s asset or location only needs to exist in the SLA table.
Note. The matching process for the Service Provider version of the Service Level Agreements application is different, particularly in the area around the handling of locations and assets. I strongly recommend either thorough testing or trapping where clauses used in a SQL log to thoroughly understand how the matching process works, in particular, knowing the full extent of the initial query can help to improve performance.
When Maximo has evaluated the SLA to see which is a match to the Service Request, by default only one SLA can be applied and it uses the Ranking field to evaluate this, here the highest rank is 1. I would use a range between 1 and 100 and start in the middle at 50 as this allows you to give some SLAs a higher rank and others a lower rank. Try to avoid a rank of 1 as when you are testing the matching of SLAs you would be constantly having to change the SLA with a rank of 1 just to prove that a new SLA does actually match.
Let’s assume an SLA has been found with the highest rank. The next step is that it is applied to the Service Request and a record is entered in the SLARECORDS table and the ‘SLA Applied?’ check box will be set. If you scroll down to the Dates section you will find that one or multiple of the Target Contact, Target Start or Target Finish fields will have been calculated. The same principle holds for work orders except there is not Target Contact field.
The dates that are calculated are based on the commitments you made on the SLA, in particular the CONTACT, RESPONSE and RESOLUTION type commitments. If the Response was 4 HOURS and the Reported Date was at 15:00 on a Thursday, then it does not necessarily mean that the Target Start would be at 19:00. It would if there was no Applies To Calendar or Calculation Calendar, as 24 hours a day x 365 days would be assumed.
The Calculation Calendar is used to provide the working hours as the basis for calculating each of the target dates. If this was set to a calendar and shift which had work periods of 08:00 to 18:00 Monday to Friday, then in our example the Target Start would have been calculated as 09:00 on the Friday. If you are going to use a working time calendar then the SLA commitments should be in HOURS, as a commitment of 5 DAYS will be converted to 120 HOURS (5 x 24) and 120 hours on a working week may calculate a target date in three weeks’ time when one week was expected.
If there is no Calculation Calendar, then the Applies to Calendar will be used if it is present, but it is good practise to always specify a Calculation Calendar unless 24 hours a day will provide the correct target dates. The version of the Service Level Agreements application in base Maximo only uses the Reported Date as the seed date and time on which to calculate target dates. The Service Provider version provides more flexibility.
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 and the action SLA Options there are some settings that allow you to choose between applying a single or multiple SLAs and if you choose multiple then to apply SLAs based on Ranking or Commitment Stringency. The default is to apply a single SLA, and this is based on ranking.
If you choose to apply multiple SLAs, this allows you to separate the SLA commitments onto separate SLAs, which provides you a greater degree of flexibility, but with it you will have a larger number of SLAs and potential then for undesired results. Consider this, when an SLA is applied the Target Start can only be calculated from one applied SLA, the Target Finish could be applied from a different SLA, in both cases by default the SLA to be applied will be the one with the highest Ranking. You can see the SLAs that were applied using the View SLAs action. If there are two or more SLAs with a target date and they have the same Ranking value, then the one that is applied cannot be predicted, hence if you are using Multiple SLAs based on Ranking, then you should ensure this situation does not apply.
When multiple SLAs are being applied based on Commitment Stringency then the SLA that would give the earliest target date will be applied. The View SLAs actions which is based on the object SLARECORDS shows the calculated fields of Contact Time, Response Time, and Resolution Time. You can see which was applied by comparing it with the Target Dates.
If you do use the Related SLAs tab, to have supporting SLAs then the commitments which you have internally or with vendors may be more stringent than the one you have with your customer. You therefore need to make sure that they are either applied on different records, for example WOACTIVITY, or WORKORDER, or they have a lower ranking which means that they would not be applied to a Service Request leaving the higher ranked Customer SLA to be applied.
Leave a Reply