Improved ASLA Generation
Service Level Agreements (SLAs) provide coverage for the users of the service, defining the minimum level of support that a provider is to offer a customer in case of a service degradation or outage. To be able to report the actual response duration, actual resolution duration and downtime duration in a service level management report, small records called ‘Affected SLAs’ (ASLAs) are automatically generated by Xurrent and added to requests. This may happen after certain updates of the request, for example when the status of the request, the related service instance, or the team it is assigned to changes.
In many cases, picking the affected SLA after an update of the request is straightforward. When an incident affects the service instance (SI) that delivers a service to the members of an organization, for example, the SLA that was defined for delivering that service to those people using that specific SI is directly relatable to the requester. When a service desk analyst uses the Service Hierarchy Browser (SHB) to select the correct service instance for the request, that link between requester and SI is already made.
In some cases, deciding which SLAs were affected after a request is updated is more complicated. When the coverage of an SLA is defined for members of teams that use a service instance to underpin other service instances that these teams are responsible for, a service hierarchy emerges. Such a service hierarchy can become rather complex, and the SI that is affected may not be directly relatable to the requester. In that case, a logical path between the service instance and the requester must be established to decide which SLAs are considered ‘affected’.
Consider for example the situation on the right, where service instance C underpins service instance B, underpinning service instance A. Service instance C also underpins A directly. If an incident is registered in such a case and the affected service instance is selected directly in the request form without making clear to Xurrent which path should be followed from the service instance to the requester, affected SLAs for both paths (red and green) were sometimes generated. In more complex situations, an even large number of possible paths may exist, even including accounts of customers or providers. In such cases, even issues around data separation can come into play.
The logic within Xurrent that decides which SLAs are considered ‘affected’ in such cases has now been improved. In short, paths between a requester and an SI that include less external and internal accounts and that are shorter are preferred. In some cases, this can result in a large reduction of the number of ASLAs related to a request.
In a future release, another change in the ASLA generation shall be announced. That one will involve ‘remembering’ the path that a service desk analyst followed through the Service Hierarchy Browser.