Recommended approach for vendor commitment-based SLAs - incidents

jmn
Kilo Explorer

11 hours ago

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?
0 Helpfuls
  • 83 Views
1 REPLY 1

Mathew Hillyard
Tera Sage

7 hours ago

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

 

0 Helpfuls