Jump to content

SLA does not update when escalating priority


dwalby
 Share

Recommended Posts

Hi all,

When working on an incident/service request, is there a reason the SLA does not automatically update when escalating the priority? If for example I change the below priority to Priority 1, I'd expect this also to update the SLA 

image.png.99eb44147e674f0cbd09c2f9d456d71a.png

Instead, it seems the Priority gets updated, but the SLA remains the same. It may however be that I'm misunderstanding the usage and best-practice between priority and SLA, so any feedback would be welcome.

image.png.04f0eb1d9ae399bc2ec1ccb6a00097e3.png

Thanks in advance

Link to comment
Share on other sites

Hi @dwalby thanks for the post.

In Service Manager you can use various parameters to set which Service Level Agreement and Service Level target should be invoked including priority, catalog item, site, customer etc - this is for you to configure as needed in your SL rules.

https://wiki.hornbill.com/index.php/Service_Level_Agreement_Rules_Builder

Currently these rules are not re-evaluated on changes to a request such as a change in priority, customer etc but it is on our list to do, and i can add you as an interested party to me kept informed when it is available. 

In the meantime you can change the SLA and SL manually by clicking on the SL name - in your example BPHA Priority 5 and you can then change this as needed 

image.png

 

Steve

 

Link to comment
Share on other sites

@Steven Boardman Thanks for the response. For clarity and to better my understanding, what are the key differences between the Priority and SLA and why are they handled separately?

We're currently Supportworks users and when logging a request have to set the impact/urgency, which then calculates the SLA priority. In Service Manager however, it seems there are Priorities as well as SLA Priorities to administer, which I'm finding a little confusing.

Link to comment
Share on other sites

@dwalby sorry for any confusion here. 

Firstly i would say a priority is a priority, and we are not looking to change that.  

Supportworks and Service Manager are different solutions albeit from the same vendor but Service Manager is not an upgrade to Supportworks so will work in different ways.

In Supportworks you are correct there was an impact / Urgency Matrix which would drive the priority which the (response / fix timers) were tied to.  and if the values where changed post logging the priority would change automatically.  However there were a couple of limitations with this

* You could only set targets based on priority

* When the priority was changed the date and times for the priority would start again (from the point when the priority was changed)

* You had to define both a response and fix target even if you didn't need both

In Service Manager we are attempting to provide a more configurable approach.

You can create Service Level Agreements which are either global (can be applied to any service you create) or one's which are Service Specific.   

Inside each SLA you can define multiple Service Level Targets (say High, Low, Medium)

Each Service Level Target could be attributed a response and or fix target (if appropriate)

If you have more than one Service Level Target in an SLA you need to define in the SLA rule builder the conditions against which each Service Level Target will be invoked. 

In the rules builder you could have a simple 1 to 1 relationship - so for example if priority is High then use SLA > Service Level Target High.  However some of our customers may have more complex requirements such as, who is the customer, what is the catalog item, which site are they at and what priority has been chosen, the rules builder caters for the simple and more complex requirements. 

Once you have the SLA's and Service Level Targets defined you can choose which services to link them to and in turn in your business processes choose when the response and fix timers should start (check the relevent SLA rules and invoke the correct service level target) and when they should be stopped

There is more to configure granted but much more flexibility and we have the plans to add the options for the rules to be evaluated when request attributes are changed - such as Priority, site, customer

Sorry for the long explanation  but i hope that helps and there is more info on the wiki as well

https://wiki.hornbill.com/index.php/Corporate_Service_Level_Agreements

Steve

 

Link to comment
Share on other sites

@Steven Boardman can you add me as an interested party (if I'm not already there).

Reason its important to us (and I assume most customers) is we use the Priorities as the key measure for our SLA's. For example P1 is critical and has a 4 hour fix, going down to P4 which is 5 days. Most analyst are used to changing the priority as its the main measure we use. Having to amend it in two places isn't a natural action so the SLA rarely get changed (and needs additional permissions in Service Manager for us), so crucially the time to fix the ticket doesn't get updated.

Look forward to seeing this one.

Link to comment
Share on other sites

While we are investigating the ability to dynamically change the Service Level, there is an alternative that might be useful in some circumstances.  The BPM has an operation under the Update Request called Service Level.  There are no parameters needed for this.  You can simply add this in at certain points within your workflow to automatically re-assess the service level based on the rules that you have already provided.  This would work well when you have a request has been allocated some initial values such as priority, but within your workflow you have a task or stage for evaluating or assessing the request.  After the assessment has taken place you can use the Update Request->Service Level to check the Service Level rules and automatically update the targets.

image.png

Regards,

James

Link to comment
Share on other sites

Thanks @James Ainsworth - after a request is raised I use an impact assessment to determine the priority, the SLA 'level' then gets mirrored  (e.g. Priority 1 = BPHA SLA Priority 1) automatically set based on a decision within the BPM.

Just to clarify, would the just one 'Update Request>Service Level' node detailed in your above post automatically update the SLA 'level' if the Priority is changed at any point in the requests lifespan?

As @Steven Boardman mentioned previously, in Supportworks changing the priority would restart the date/time of the response and fix times. Would the same apply in Service Manager?

Thanks for your input as always

Link to comment
Share on other sites

Hi @dwalby

The 'Update Request>Service Level' will only update the request at the point that it is run in the BPM.  In order to have the service level targets automatically changed whenever a priority is changed, this would require the change mentioned above for ''Dynamically changing the Service Level targets''. 

There are some added benefits to manually changing the Service Level targets as described by Steve Boardman above.  This being that you can be made aware if changing the Service Level is going to result in the request being put into a situation where the targets will be past and your SLA breached.  Anything that is done automatically may result in a request SLA breaching without being made aware first.

Regards,

James

Link to comment
Share on other sites

Hi @nasimg

Thanks for your post.

All of the default roles for Full Access, such as Incident Management Full Access will provided this ability.  There is also an individual right called updateRequestServiceLevel which could be added to a custom role under the Service Level Management section on the Application Rights tab for a Service Manager Role.

 

image.png

Let us know if that helps.

Regards,

James

  • Like 1
Link to comment
Share on other sites

@Steven Boardman

+1 for adding us too. 

I have noticed that when we change the SLA it seems to ignore the amount of time spent on hold in the previous SLA. 

We changed a P1, which had been on hold for a number of hours waiting for a third party, to a P3 (via the SLA method mentioned in your first post) and the call breached its response SLA. The call had been on hold since before the P1 response SLA had breached (15 minutes) so I don't see why it suddenly breached the P3 response SLA (4 hours).

Link to comment
Share on other sites

  • 9 months later...

@dwalby @HGrigsby @HHH @Dan Munns @nasimg just an update to let you know in the next Service Manager update due in the next week to ten days you will have the ability to enable dynamic recalculation of Service Level Agreements and Service Level targets based on manual changes to requests attributes.

With this feature enabled if the Priority, Site, Customer, Category fields etc are changed manually on a request, the SLA / SL Targets will be recalculated and if needed automatically changed based on the rules you have defined in your SLA's.

This will be off be default, but can be enabled globally by enabling a system setting 

There are of course already options to manually change an SLA /SL Target or do this as part of the Business Process but this just extends these options to manual changes to values on the request - most commonly the priority. 

  • Like 1
Link to comment
Share on other sites

@Steven Boardman

Thanks. Appreciate it adds slightly more complexity, but for those of us having different service desks running on the same instance for different business areas, having settings like this where a default value can be set a system side and an override at Service Level would be a good design philosophy to apply.

Cheers

Martyn

Link to comment
Share on other sites

Currently when raising an incident if we perform an impact assessment and it calculates as a Priority 1, it follows a set process for a Major Incident. If the incident starts life as a Priority 3, but is then escalated to Priority 1 it does not invoke the Major Incident BPM tasks.

@Steven Boardman With this new feature if an SLA gets re-calculated from a Priority 3 to Priority 1 for example, is it now possible in the BPM to start a Major Incident Procedure for example?

Link to comment
Share on other sites

@dwalby each BPM Is effectively a point in time set of decisions - so when you get to a node in a process, it evaluate the conditions at that point in time.   If you have a Major Incident Procedure which is invoked at a given time when a BPM get's to a certain point in the process based on the priority of the Incident at that point in time - then nothing will change with the ability for the Service Level (i am assuming your P1-3's), what this story introduces is the option to automatically re-calculate the SL based on your defined rules in the SLAs, this is not tied to or able to influence the BPM.

I understand what you are looking for here, in effect form field rules - i.e if SL field = P1 do X at any time in an Incidents lifecycle. The BPM is something a little bit different to this and is always moving forward and evaluating conditions at given points in time.

Link to comment
Share on other sites

@Steven Boardman thanks for this. Do you have any suggestions on how this can be achieved otherwise?

To further expand on my scenario, if we have an incident reported by a single user reporting that their email is offline (usually we'd define this as P5/P4), but then receive several reports thereafter we'd want the initial report as the 'master' incident record and escalate to a P1. At this point I'd want the major incident process to execute in the same way that it does currently when I raise an incident and define it as a P1 at the stage it's logged. Maybe this is something worthy of a separate thread discussion?

Link to comment
Share on other sites

In the absence of form field logic i am not sure there is a perfect solution for you here.  In reality the Actions you wish to invoke in the event of a Major Incident either on initial report or subsequently would have have to be at defined places in your workflow so

On Log check priority for example

On action 1 (task complete, any suspend action etc) check Priority etc

Each of which would branch on major to the actions (nodes) you would want to perform.

This approach is not really practical to configure nor real time, as you would only check on an action.

An alternative might be to raise a linked Incident as needed - i.e on initial logging check if major and let the BPM kick in,  you could automate the creation of the MI using the log request node in the BPM), if you needed to escalate to MI at any other point in the Incident lifecycle, you could raise a linked Incident which had your MI process and let your MI ticket cascade down updates and resolution to this or other linked Incidents.

Neither ideal i accept but i wanted to make some suggestions, happy to see if others have different approaches which could be taken

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...