I have come across a business requirement at one of my large enterprise customers which is somehow special to the ServiceNow platform, but still something I bet most larger customers working with outsourced IT teams should encounter - one way or another.

As a primer to this article you might want to read the excellent blogs from Ed on similar topics:

As good as they are, they are not covering my case. So let's explain.

Business Statement

Vendor specific Underpinning Contracts provide service to the customer leveraging support teams across multiple time zones and different working hours. There is no 24/7 support agreement defined in the Vendor Underpinning Contracts.The end user SLA (end 2 end Service Commitment) already takes into account the impact of the timescales to support the Underpinning Contracts. For example an Underpinning Contract of 8 hours may well define an end 2 end SLA of 24 hours towards the end user once the potential periods where the current support team is not active (out of hours or out of time zone) are taken into account.

Customer requires the ability to measure a single SLA clock per Underpinning Contract, taking into account the time spent with different support teams, across different time zones, taking into account different working hours. Only hours worked across the teams during their allotted Time Zone and hours of service count towards the Underpinning Contract service measurement.

Example of single UC measurement for same Contract

Example of multiple UC measurement for different Contracts

Technical Challenge

ServiceNow SLA clocks (task_sla) set the Timezone and Schedule on initial creation of the task_sla record. Changes to the Timezone and Schedule, by updating the values directly on the task_sla, result in the complete measurement being recalculated on the new Timezone and Schedule.There is no exiting mechanism to capture the business time spent across different Timezones or Schedules other than creating multiple task_sla records per Timezone or Schedule change. Separate task_sla records work on same SLA definition and do not record time already ‘spent’ across other task_sla records; hence 4 hour UC at Timezone 1 would result in a new 4 hour UC at Timezone 2.

Multiple task_sla records do not provide a single pane of glass view of how the vendor is performing. Multiple task_sla records do not provide a mechanism to notify or alert vendor surpport teams on UC progression/breach.

Options

• Utilize metrics to calculate time spent on UC, based on Timezone and Schedule changes.
• * Would need to provide display on Incident of UC metric
  
  • Would need to provide mechanism for alerting based on UC thresholds (50%, 75%, etc)
    
  • Would need to remove visibility of UC task_sla to avoid confusion
• Provide reporting capability, based on rollup of multiple UC task_sla records.
• Custom solution generating parent SLA Rollup record automatically calculating the combined UC task_sla usage
• * New table and business rules
  
  • Minor changes to task_sla
    
  • Would need to provide display on Incident of UC metric
    
  • Would need to provide workflow for alerting based on UC thresholds (50%, 75%, etc)
    
  • Would need to remove visibility of UC task_sla to avoid confusion

Proposed Design SLA Rollup

New SLA Rollup mechanism where one parent UC measurement is maintained.

Service Contracts for each Underpinning Contract.

Service Offerings linked to Service Contracts.

OOTB SLA Definitions which generate multiple task_sla records based on time zone and/or schedule change per single Service Contract.

Child task_sla records are linked to the SLA Rollup record.

Parent UC Measurement is maintained in the SLA Rollup record using the linked child task_sla data to generate the relevant sla clock usage.

Presentation of the UC measurement at record level.

Change to ootb KPI reports and PA where needed.

Technical steps to build out SLA Rollup Design

• Create new scoped application SLA Rollup
• * This will hold single parent UC record for all task_sla records per contract per task
• Create new task_sla_rollup table based on attributes in task_sla (do not extend task_sla)
• * Add contract reference field
• Create Service Contracts for all Underpinning Contracts i.e. HCL, Wipro
• Create Service Offerings and link to relevant Underpinning Contracts
• Create new SLA Workflow to run against the parent UC record for threshold notifications
• Create SLA Definitions to generate UC clock each time group changes (or TZ/Schedule changes)
• * Some custom work may be required to capture the group schedule
  
  • If Kingston not used, custom work to capture when TZ or Schedule changes
    
  • SLA Type set to Underpinning Contract (do we need a new SLA Type for this?)
    
  • Do not use default SLA workflow for these definitions
    
  • Add parent field to task_sla table
• On creation of task_sla record; create new ‘parent’ task_sla_rollup table record
• * If UC record exists in SLA Rollup for contract and task, set parent in task_sla
  
  • If UC record does not exist in SLA Rollup create new ‘parent’ task_sla_rollup table record and copy across initial data set
• Create BR on task_sla on insert to check if existing vendor task_sla exists for task (incident)
• * Correlation rule Service Offering Contract = Contract and task exists as SLA Rollup record
  
  • Create and populate new task_sla_rollup table with required fields from task_sla
    
  • Link task_sla to parent task_sla_rollup record
• Create BR on task_sla on update to refresh UC data set
• * Data set attributes to be confirmed
  
  • Consider Continuation and Inheritance (move to UC record?)
    
  • Calculate breach time, Actual time left and Business Time left
• Amend existing views for task_sla to display SLA type (end2end) task_sla records
• Add new view to display OLA/UC type task_sla_rollup records
• Amend existing task_sla related lists to display SLA type (end2end) task_sla records only
• Create new OLA/UC related lists to display task_sla_rollup related records
• Review and Replace/Rework all existing ootb SLA KPI reports
• Review and Replace/Rework all Performance Analytics SLA specific elements
• Verify Mobile apps and potential impact on Service Portal

I hope this is useful for others, and to be frankly honest, it is not designed and build by me. One of my fellow TC colleagues was the brain behind it and socialised it with our product management teams as a good solution design which will serve the customer needs and at the same time does not impact future upgrades as it has very limited impact to existing functionality.

Labels:

• Multiple Versions
• Service Level Management