Service Offering SLAs - Service Offering field vs Configuration Item field

Kyle Brown · ‎10-08-2018

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 · ‎10-08-2018

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.

View solution in original post

ITsACrowd · ‎03-25-2020

Hi Mark,

Would you suggest outages are also raised against the service offering in both incidents and changes?

Thanks

Adam

Kyle Brown · ‎10-09-2018

Thanks again Mark, really helpful stuff.

ITsACrowd · ‎03-25-2020

Hi All,

This is a very interesting thread, but it sounds like there are still some further challenges.

Let's say for example we follow the advice provided by Mark Stanger on the incident form, and the primary CI field was locked down to Service Offering only. There could be multiple service offerings to choose from (platinum, gold etc) for a single business service. Thus this would cause a lot of confusion, how would you expect to overcome this one? Perhaps some logic that Trevor raised, if it's a ‘mission critical CI’ or a ‘VIP user’ it would automatically select the tier of offering for that service, would that work? What if you have a mix of tier offering impacted, i.e. critical and non- critical impacted?

Trevor raised another good point as well, '...a technician should know the business service but not necessarily the service offering that would apply to an incident...". I would say the technician may know the business application or utility, but might not fully understand the business or technical service nor the offering if it's tiered.

I am trying to find a way to link together the business applications, service offering and business services so that records can be prepopulated in the most effective manner. Will this be covered in updates in the CSDM material?

Trevor Muhl · ‎07-09-2020

Hello Kyle,

I was recently taking a closer look at the property you mentioned--"Specify the field from Task used to match with Service Offerings". After installation of the "Service Portfolio Management SLA Commitments" plugin, this property is available on Orlando instances.

After updating that property to "service_offering", everything seems to be working as expected (currently on a New York instance). Service offering SLAs are properly associated with tasks and SLA results are generated and visible on the service offering. The CI field can be used for a legitimate CI.

Can you clarify what issues you may be having if they are still present? Thank you.

Kyle Brown · ‎07-10-2020

Well I'll be damned, they actually went and fixed it (made it useful)!

Thank you for taking the time to update this with your findings Trevor.