Service Catalog SLA -> (Item vs Task vs Both)?

[Mikolz]

Hi Everyone,

Just looking to get some best practice information about SLA's and service catalog entries. I cant seem to find anything on the forum, but I was just wondering what are some best practices regarding SLA's on service catalog items? Is it best to run them at the item level or day the catalog task level? What about if an item is to be fulfilled by multiple groups? In that case it makes sense to run them on a catalog task level vs the item level. What has been your experience with this? Is one way better than the other, if so why? Any information about personal experiences, suggestions, opinions would be appreciated. Thanks.

[Uncle Rob]

Hey Zac,

I usually assume that the Requested Item is the client facing abstraction of the service being offered.   That's where the promise of service should be tracked.   Most times, a customer won't care what component pieces of work are.   You're not promising you'll get 1/3 of their request done in X days.   You're promising delivery of service in X days.

Therefore: SLA at RITM level.

BUT!   That doesn't mean you don't put SLA definitions against catalog tasks.   Far from it.   I simply call those OLA's &/or underpinning contracts, and they form the foundation on which I can actually, legitimately, measurably, objectively promise what I do on the RITM SLA.

First time I dabbled in SLA's and Catalog was 8 years ago.   Word came from the top that all New Hires would turn around in 3 days ("PERIOD!").   What they didn't know, because they didn't measure before hand, was that the ID Management team was taking 3 days to clear their ticket... and that was step 1 of 5.   The child tasks need SLA Definitions, but they are not the same type or definition as what we put in front of the customer.

EDIT:   Sorry about the essay.

[Mikolz]

No need to apologize, this is good stuff. I agree with you that the RITM from a business users perspective is what is important to them. So I take it the RITM SLA definition would be the sum of the underpinning operational level agreements?   Also, when you say they are not the same type or definition, I am assuming you are referring to type as a systematic one (i.e defining the the typ as either OLA or underpinning?). Which leads me to my last question, from a system perspective, what is the difference between the latter two?

[Uncle Rob · Accepted solution]

Hey Zack.

So I take it the RITM SLA definition would be the sum of the underpinning operational level agreements?

Yes, the SLA I put at the RITM is the sum of what I know from measuring my component work.   Its important to note I don't do this automatically.   My RITM SLA isn't doing some kind of calculation of preferred timelines for the sc_tasks.   This all assumes I've been using Metric Definitions to find out how long that child work usually takes before I make the promises.

Also, when you say they are not the same type or definition, I am assuming you are referring to type as a systematic one

Correct.   We're talking about SLA Definition records either way.   Some just represent real client facing ITIL-ish SLA's.   Some represent OLA/underpinning contracts.

Which leads me to my last question, from a system perspective, what is the difference between the latter two?

From a system perspective, there is nothing mechanically different from an SLA Definition defined as an SLA, OLA, or UC

[gyedwab]

The RITM SLA is either the sum of the underpinning operational levels, or slightly more than that to account for handovers.

From a ServiceNow system perspective, there's no difference between SLA, OLA, and underpinning contract; it's mostly for filtering and reporting purposes.

The advantage of the RITM SLA is to make sure you're looking at it from the customer's perspective... the service catalog lets you define a Delivery Time which gives the user an Estimated Delivery Date, and you want to make sure that your Estimated Delivery Dates are setting good expectations.

For example, here's a report we use (part of the Explore Analytics ITSM Application) to compare that Estimated Delivery Date to the amount of time on average it takes to deliver the item:

Item Delivery Analysis