SLM - Resolution Target - Need higher maximum

[Martyn Houghton]

At the moment the maximum Service Level Management Target you can set for 'Resolution' is 40 days,23 hours and 55 minutes. We are currently implementing further service desk on to our instance and they have some long running SLA's for cosmetic software issues which in affect have an SLA of a year. Based on on 261 working days a year and 9 hours a day, I need to set a target of 97 days and 21 hours but are not able to set the value higher than the for mentioned maximum.

Can these maximum value be increased please.

Cheers

Martyn

 

[Melissa Gurney]

@Claire Holtham 

[Guest Paul Alexander]

We are also looking a target of more than 40 days and we'd like the maximum value to be increased please.

[Steven Boardman]

Hi @Martyn Houghton @Melissa Gurney @paul.alexander@vinci.plc.u

Thanks for the post, i have raised this internally and will feedback on what we can do here. 

Martyn thanks for your use case. 

Melissa, Paul - would you be able to provide more information on the length of resolution times you may need?

Martyn has highlighted that the existing 40 Days actually already caters for say 120 elapsed working days if your working time calendar is set to an 8 hour working days, Mon-Fri as there are 3 x 8 hours in each 1 working day.

So in the example above if i had a 40 day resolution target on a 9-5 Monday - Friday Working Calendar then this would be 21st September, 2017 from today.  However if it was 40 days on a 24 hour 7 day working calendar it would be the 16th May 2017 from today.

Thanks

Steve

[Steve Giller]

It's quite a way off, but if we get around to putting projects onto Service Manager we could be looking at SLAs as long a 3 years.
That's a relatively unlikely setup, but I can see it being asked for knowing the departments who don't use Service Manager but are looking at it as an option.

If you're looking at this could I suggest that alongside it you consider the option to switch between working hours and "actual" hours?
It would be useful on longer SLAs to be able to select, for example, 1 week on the IT Working Time Calendar and have the system convert that to the actual hours based on the existing settings.

[Guest Paul Alexander]

Hi @Steven Boardman

I think we're actually looking more for what @DeadMeatGF was suggesting...and that's to have an option to switch to 'actual' hours (or days in our case)

One of our processes involves a 60 day review, which is 60 actual (not working) days after the request has been completed. We don't have a need for the ticket to be closed during this time, as the review is the last task before the call is resolved.

Hopefully that makes sense!

thanks

[Steven Boardman]

Thanks @paul.alexander@vinci.plc.u

Would an approach to this be to use a Human Task in the business process, so after you have completed all of the work of the request, you have Human Task created, which within it Lifespan Settings,  it's Start Date can be set to 60 days, which will be 60 actual days from the point the task is invoked in your process? This task can be assigned to a user, group, role or variable (such as owner of the request).  

The task can have custom outcomes, and it can also be set to expire if not completed in say 70 days which would allow branching based on completion or non completion in a defined time period, with whatever required actions defined in your business process. 

The task will appear on the Task lists, calendar and custom boards? as well as the Activities panel on the right hand side slide bar on all views.

Is this something which might work in this scenario?

Steve

[Guest Paul Alexander]

Thanks @Steven Boardman

 

I'll give that a look and let you know. Looks like it might just work for us....

 

thanks

[Steven Boardman]

@Martyn Houghton @DeadMeatGF @Paul Alexander @Melissa Gurney we have increased the SLA Target days maximum from 40 to 120 in the next Service Manager build. hope this helps, the next update will be out in the next couple of weeks

[Martyn Houghton]

@Steven Boardman

Thanks that will help with some of more long-winded development/requests for changes etc.

Cheers

Martyn

[Martyn Houghton]

@Steven Boardman

Following on from the extension of the maximum duration on an SLA in SM build 1117,  is there any plans to allow the system to cope with an SLA only having one of the SLA timers set, either Response or resolution. I.e. the workflow has the start and stop timer nodes in for both as most of the priorities have both, but would not fail when there is no timer for the current service level.

I know I could achieve this by hard coding in decision nodes to the workflow not to start the timer if there is no timer on the current SLA, but with a growing number of SLA's this requires quite a bit or work/administration.

Is there a way to query the current Service Level assigned to a request to determine if there is a Response or Resolution Timer, which would allow you to route around the timer start/stop nodes.

Cheers

Martyn

[Steven Boardman]

@Martyn Houghton i've done some testing and i can't replicate an issue in this scenario.  I will explain what i have tried.

* In my business process i have both start response timer and start resolution  timer configured

* I have a stop response timer in a subsequent stage and a stop resolution timer at the end of the last stage

* I have a corporate SLA which has 3 service levels

 > One has both a response and resolution target

> One has a response only target

> One has a resolution only target

 I have rules in this SLA to invoke a different Service Level Target based on the priority of the request

* In addition i have a Service Specific SLA which has 2 service levels

> One with a response only target

> One with a resolution only target

I have rules in this SLA to invoke different Service Level Targets based on the category of the request

* I have linked both  of these SLA's to a test service. 

* Because i have two SLA's against the same service, i have a rule which invokes the correct SLA based on who the customer of the request is, and then in turn the rules in the chosen SLA determine the Service Level and it's relevant timer(s)

I have run multiple tests on all of the above examples and in each occasion the correct SLA and Service Level is invoked, and regardless of if the Service Level has both a response and resolution timer configured, or only one of them the business process progresses - starts the required timer(s), ignoring any timers which are not configured in the Service Level without impacting the business process, and likewise as the business process goes through the stop timers for both response and resolution it stops the timer(s) is configured and ignores any where the resolution was not set, again with no errors in the business process. 

Does this sound different to what you are seeing? if so I am wondering if this is related to something else causing this, and if so my first thought is does this relate to the old service level timers (shown here)

 

Or have you moved across to using the Corporate and Service Specific service levels where i have done my testing and can't seem to replicate the issue you describe?

 

Could you confirm if i am testing the right scenario and which Service Levels you are using?

 

[Martyn Houghton]

@Steven Boardman

Your scenario is correct and we are using Corporate Service Level agreements. I will give it another test, as it might have been something I done wrong in the workflow/config, as it appears it is designed to cope with the having the different combinations of timers.

Cheers

Martyn