What is a Service Level Objective (SLO)?
A Service Level Objective within ITIL is a contract or agreement negotiated between you as a service provider and your customer(s). A Service Level Agreement (SLA) describes the service and specifies your responsibilities that you will deliver to the customer. You might use a single SLA across several services or even customers, depending on your business model.
A simple example of an SLA might be that we agree to resolve a priority 1 rated incident in 4 hours.
A more complicated example might be that we agree to provide a 99.99% up time for a service.
What Components Make Up a Service Level Objective within SCSM?
To create a SLO within SCSM we need four components:
- A metric to measure
- A Queue to apply it to
- A calendar that defines our “Work Hours”
- A time set against the metric
Creating a Metric in SCSM
A metric, within SCSM, is defining any two properties that can have time difference between them. For example: The Creation time and Resolution time of an Incident or Service Request.
The Metric is used as the point of measure for the workflow to use when displaying or reacting to a warning or breach event. Out of all the SLO’s I’ve seen, the most common two are IR First Contact and IR Resolution.
Creating a Queue in SCSM
Not all Service Level Object’s apply to all Work Items. To limit what SLO’s apply to what Work Items, we need to group together a bunch of Work Items that we want to apply the SLO to. Creating a Queue is a way of being about to group together a given type of work item based on a criteria that you choose.
Common examples used for Queues are:
- Priority based queues (P1, P2, P3 etc.)
- Category based queues (Server, Desktop, Network etc.)
The most critical thing to watch when creating Queues is to ensure you select a class that has the minimum number o relationships your required to achieve your goal. Selecting the “Incident (Advanced)” combination class for all Incident based Queues is the leading cause of SCSM slowdowns that I have seen.
Creating a Calendar in SCSM
The calendar is used to ensure that the SLO is only calculated when support staff are at work and not over weekend or overnight. (If you don’t work in a 24×7 organization).
You can have multiple calendars if you have different support groups working different hours, but for most organizations there is a single support schedule that the entire team works to.
Creating an SLO in SCSM
To create an SLO you have to have all of the perquisites created and available. The SLO is then just a case of selecting the time to set against the metric type and applying it to a given queue.
Within the SLO creation wizard you will be asked for both a warning time and breach time. Warning time triggers an event at a given time before the SLO breaches allowing you to have an e-mail sent to the relevant parties to give them fair warning that the Work Item needs to be worked on.
Breach time triggers an event at the time of the breach and can be used to notify management or an escalation team if required.
How to (and How Not to) Use SLOs in Day-to-Day Operations
In this authors opinion, for most organizations, SLO’s are not required and provide nothing more than a false sense of security in reports and a great source of anxiety for support staff.
We only advise customers to implement SLO’s if they have strict, contractually binding service levels that they must achieve under penalty of contract breach or financial fine.
If your organization wishes to use the Service Level Objective’s purely as a reporting measure after the fact, then I suggest you use some advance reporting features to tease this information out of the data after the fact rather than placing the stress of the SLO clock on the support staff.
Let us know if this is of help and feel free to reach out through the Cireson Community for more tips and tricks!
