Service Offering SLAs - Service Offering field vs Configuration Item field

[Kyle Brown]

 Hi all,

I'm trying to get my head around how you're supposed to be able to effectively monitor Service Offering SLAs while also being able to use the CMDB to see a history of a CI (incidents and requests raised against it, etc).

Taking Incidents as the use case, it seems that the only way of getting a Service Offering SLA to fire is by putting a Service Offering in the Configuration Item (cmdb_ci) field and that the Service Offering (service_offering) field does nothing. This then means you can't put the actual CI being affected by the Incident in the CI field for it to flag up the CMDB.

For example, if I raise an Incident for a faulty laptop, I have a choice between putting the laptop as the CI, which then appears in the related list on the CI record as a historical Incident, but won't have any record of this incident against the Laptop Service for SLA reporting purposes. Alternatively I can put the Laptop Service as the CI, which will generate a Service Offering SLA record and will show on the "My Services - SLAs" homepage widget for the Laptop Service Service Offering, but the actual laptop CI won't have any record that there was ever an issue. This seems crazy, I would expect the CI to go in the CI field and the SO to go in the SO field.

Even more confusingly, older versions of ServiceNow DID have a property in the SLA engine called "Specify the field from Task used to match with Service Offerings" which let you choose between the 2, but if you selected the Service Offering field, the SLA generated correctly but was never counted as part of the SLA Results calculation....this property no longer exists in the newer releases.

I feel like either my organisation are approaching Services (and measuring them) incorrectly, or I'm missing something obvious in the platform. Does anybody have any ideas?

Thank you to those who read this far, even if you don't reply.

Kyle

[Mark Stanger · Accepted solution]

This is kind of confusing.  A way that I've always used to approach this...that I think works really well once users get used to it...is to restrict the Configuration item field just to service offerings.  These service offerings end up being like your categorization for an incident and guarantee that you can trigger the appropriate SLAs and record outages, etc.  Then I have users list the specific CI(s) that are being impacted in the 'Affected CIs' related list at the bottom of the form.  Adding a message on the from field to indicate how this works goes a long way to helping users figure out what to do.

[Kyle Brown]

Thanks Mark, really appreciate the response.

Now that you've said it I don't know why I didn't consider the Affected CI related list in the first place. Evidently I WAS missing something obvious.

So I suppose the only follow-up question is...all that being considered, what is the point in the service_offering field? It doesn't seem to serve any functionality or drive anything in the system...unless it's just a legacy field from a previous SLA engine when the "Specify the field from Task used to match with Service Offerings" property used to exist.

[Mark Stanger]

That’s an excellent question...and one I’ve asked before as well.  In my opinion this functionality really just wasn’t thought through (or revisited much after the first incarnation).  The only possible use I can see for that field would be to use it as a primary selection to filter additional CIs.  The only problem with that is that the Service Offering is the CI you wanted anyway!

The way I’ve always looked at is that your Service Offerings should be so obviously named that they act much like categories.  If an end user (and certainly a technician) can’t tell you at least the high-level Service Offering then you haven’t named them clearly enough.  Put the Service Offering directly in the CI field and, if done correctly, it can replace Category, Subcategory, etc.  As for the specific CI, that’s generally unknown on an incident anyway.  Nor is that something that would be part of an initial classification generally.  That becomes known (and can be added in the ‘Affected CIs’ related list) as the incident works its way to resolution.

On that same note, this works completely different in change management.  I wouldn’t advise this type of setup/filtering there because the Service Offering doesn’t need to be used in that same way.  You also know exactly the primary CI there.  While you could certainly list a Service Offering as the primary CI, you’re almost always targeting a specific device (or devices) from the beginning.

Please mark my response as correct if I’ve answered your question.  Thanks!

[Trevor Muhl]

Hello Mark,

I appreciate your helpful response here. It has definitely changed how I approach this functionality. Is there any way to marry this approach with the concept of a service offering being a "premium" or "standard" version of a service?

For example, a customer company may subscribe to multiple service offerings. They may pay for a "premium" service offering for production CIs (for faster response, greater guaranteed uptime) and pay for a less expensive "standard" service offering for sub-production CIs (slower response, lesser guaranteed uptime).

A technician should know the business service but not necessarily the service offering that would apply to an incident. With this approach however, the affected CI should theoretically determine the service offering that applies.

This is where I get slightly off-topic (apologies if that is the case). What is the best way to establish a relationship between a customer CI and a subscribed service offering? If that is established, I can then create an algorithm to select a service offering (which applies its SLA) based on customer, business service, and affected CIs.

There is a similar question here.

Let me know if my approach is flawed in any way. Thank you.

- Trevor Muhl