Recommended approach for vendor commitment-based SLAs - incidents

[jmn]

Hi ServiceNow Community,

I am looking for guidance on the recommended CSDM model for vendor-specific commitment-based SLAs for incidents.

We have multiple vendors supporting different business applications and infrastructure CIs. The same vendor may support:

• many business applications,
• thousands of infrastructure CIs,
• several CI classes,
• and have multiple support groups.

We already have global Incident SLAs that apply to all Incidents. However, these are general SLAs and do not reflect the contractual response and resolution targets agreed with individual vendors.

Commitment-based SLAs are associated with Service Offerings. Ideally, we would apply the commitments to Business Service Offerings (or Technology Management Offerings). However, our Service Offering model is not yet mature, and many CIs have no Service Offerings.

We are considering the following model:

1. Create a Technology Management Offering associated with the vendor’s support scope (one for one vendor)

2. Associate the vendor-supported CIs with dedicated vendor related Technology Management Offering

3. Create Service Commitments of type SLA on the Technology Management Offering, representing the vendor’s contractual response and resolution targets.

4. On the incident form we have only Business Service Offering field so we can expose related TMO so the SLAs can be triggered correctly

5. Apply some logic in the SLA definition or by some BR that if BSO exists and have commitment based SLAs then attach those as a first choice (together with global SLAs that we will have always) but if none then check TMSO for commitment based SLAS and attached those as second choice (together with global SLAs that we will have always), then if none - keep only global SLAs.

Does this make sense? Is there any other approach we can use or consider?

[Mathew Hillyard · Accepted solution]

Hi @jmn 

Good question! Some foundational thoughts:

1. Don't create objects for the sake of convenience that don't match their function. You will inevitably have to unpick and redo them. A Service Offering is the stratification of a service into geographical, SLA, or specific product. It should really be vendor-agnostic to the consumer (TMSOs still have consumers, albeit technical). So your service offering should describe the product/service being offered, not who supplies it. You will then use OLA to measure the service delivered by the vendor 

2. TMSOs can refer to infrastructure support by class (e.g. Windows Server Provisioning), or application support.

• If Infra, then you will need suitable attributes on the CIs to group them into CMDB Groups then related that to a Dynamic CI Group and then to your TMSO.
• If Application support then the CIs that support this offering must relate upwards to the Service Instance(s) that is/are instantiations of whatever Business Applications provide that technology. 

3. Typically Vendors are linked via OLAs unless they directly provide the entire service offering on your behalf. So think of this as potentially a separate SLA that underpins the customer-facing SLA, rather than the customer-facing SLA itself (again, unless they provide the entire service offering). You can define OLAs in ServiceNow I believe.

4. The Incident form OOTB has Service, Service offering and Configuration item. All Service Offerings are on the same table [service_offering] so unless you have restricted this field to service classification = business service, you should see all Service Offerings. If you have restricted it then of course you can choose to remove it.

5. You could try something like this but I'd be concerned about the complexity of such a solution, the performance impact of generating task_sla records and the difficulty of understanding exactly why an SLA has been applied. I would advise you to relate SLAs to the Service Offering based on something meaningful and have the flexibility to have a business-relevant SLA for the customers, but also internally-relevant and measurable OLAs for teams/vendors who support that Service Offering.

I hope this helps!

Mat

[jmn]

Hi Matt,

Thank you so much for the quick and detailed reply. This is very helpful.

I think I may have been trying too hard to reinvent the wheel here 😊 The OLA concept is definitely interesting. Currently, we use OLAs only on Incident Tasks to measure the contribution of internal support teams, but perhaps vendor-specific OLAs could provide the missing measurement layer in this scenario.

Based on your explanation, I am now thinking about the following model:

• Global SLAs would continue to run on all Incidents as the general baseline.
• Commitment-based SLAs would be associated with the relevant Business or Technology Management Offering when the vendor provides the entire offering end to end and the commitment genuinely applies to that offering.
• Vendor-specific OLAs could measure the vendor’s contribution when the vendor supports only part of the service or provides the underlying technical support.

This would allow us to keep Service Offerings vendor-agnostic while still measuring performance against each vendor’s contractual targets.

One follow-up question: how would you recommend triggering and distinguishing the vendor-specific OLAs? Would Assignment Group be the appropriate trigger, for example, by starting the relevant vendor OLA when the Incident is assigned to one of the support groups delivered by that vendor?

Some vendors have several support groups, so I am wondering whether those groups should be maintained directly in the OLA conditions or whether there is a more scalable way to identify the vendor responsible for the assigned group.

Thank you again. This has helped me look at the requirement from a different angle.

[Mathew Hillyard]

Hi @jmn 

There are several ways to implement vendor OLAs; as you mentioned, assignment group is a common approach because as soon as it lands in the vendor queue, that's when you start to measure their performance. If the entire Service Offering is supported by the vendor then I guess the SLA is the OLA but it is still worthwhile measuring them separately so you can see the performance of the supporting Service Offering(s). E.g.

Service Offering for, e.g. Workday

SLA to measure response/resolution for the customer overall

Workday Incidents have a standard Tier 1 support group by the vendor, but as a separate function.

Tier 2 Incidents are managed and supported by a dedicated App Support Service Offering. That Offering is wholly supported by the vendor. Trigger an OLA against that App Support Service Offering to measure vendor resolution performance when the Incident is assigned to Tier 2.

This removes the need for complex SLA logic and makes it easy to understand what happens over the lifecycle of the Incident (reassignment count etc).

I hope this helps!

Mat

[Damhoej]

First of all: A Business Application is NOT an operational CI.
It represents a logical solution that has no versions.
The highest operational CI in CSDM is a Service Instance, and to Service Instances you can connect different Service Offerings on different levels. So you may need to granulate your service instances or use Dynamic CI groups to connect he proper offerings (with SLA) to the proper vendor.