You might have come across service guarantees every day, right from an e-commerce store promising same day delivery or your neighborhood pizza shop promising 30 minutes delivery to your cloud services provider guaranteeing 99% up time. The intent with any of these service promises is to set the correct customer expectations, monitor, maintain and improve the alignment between business activities and service quality. If the expectations are not defined, the standard service level expectation from your customers will be “Now” or in some cases “Yesterday”. Hence it is very important to identify, define & agree on levels of service you can offer.
This is no different for your IT organization, Service Level Management(SLM) is a key component of your overall service strategy. The main aim of SLM is to maintain and improve service quality through a constant cycle of agreeing, monitoring, reporting and improving the current levels of service and to improve alignment between business and IT.
Let's take an example of an Organization "XYZ corp". This organization has several departments, has several customers(end users) from each of these departments, and has external vendors/suppliers from where they procure equipment and have equipment support contracts. And the IT service desk of XYZ corp has several teams such as OS support team, server support team, network support team etc.
Now let's look at the definitions
A Service Level Agreement (SLA) is a formal, negotiated contract that outlines service level expectations and clarifies responsibilities between the Service Desk and its Customers (End users). In simple words an SLA is a business contract that specifies service level expectations around critical infrastructure and business services. Typically, they refer to response, restoration and resolution targets that the Service Desk needs to meet.
In our example SLA is between the IT service desk and customers from these departments.
An Operational Level Agreement (OLA) is an internally negotiated document that identifies the service level expectations between the Service Desk and the Technical Support Teams. In simpler words OLAs are similar to SLAs, except they communicate internal team based expectations within specific stages of the Workflow process.And typically OLAs are signed off before SLAs
In our example OLAs can be between internal support teams such as between server support team and network support team.
An Underpinning Contract(UC) enables the Service Desk to monitor and maintain control of requests that are forwarded to external service and support providers. In simple words the obligations of external service providers are specified using Underpinning Contracts (UCs).
In our example, UC is between IT service desk and vendors/suppliers.
In Novell Service Desk, a Service Level Agreement (SLA) can be assigned to a Customer, Organizational Unit or an Item. An SLA is assigned to a Workflow i.e. Workflows are where SLA timers stop/start. You can specify the expected response, restoration & resolution time. To successfully meet SLA expectations, NSD allows you to associate each Workflow State of a request with an Operational Level Agreement (OLA) or Underpinning Contract (UC)
So, when a request is created, NSD checks if any of these elements have an SLA. The business logic applied to assign an SLA to a request is as follows:
When Billing is enabled, the system checks that a maintenance contract is in place during the request creation process and assigns a Status of Pending - No Contract when an SLA contract is non-existent or expired. To assign an SLA in this situation, the Technician can create a Per Item or Per Request SLA Contract within the Contract tab of the request Information screen.
Novell Service Desk gives you the option of using multiple SLAs to guide response timeframes for the variety of situations your technicians face. Designing SLAs with varying levels of granularity allows you to compartmentalize tasks and corresponding response times. You can also automatically escalate older tasks, so that no service request goes unresolved. It includes:
Targets, Priorities & support hours: SLA can be defined for specific process such as Incident or SR or can be common for all requests. You can also define priorities such as Urgent, High, Medium etc for each SLA. And you can define support hours for each SLA.
Triggers & Alerts: A Request's Service Level Agreement can include trigger points that set the rate at which automated escalations will occur for Request. Auto-escalation is triggered when the number of support hours specified for either an Request Service Level Response, Restoration or Resolution time is exceeded and the SLA Trigger action is set to Escalate. When it is escalated, the request is reassigned to a Technician in the next escalation level and an email is sent to the newly assigned Technician. This process repeats itself until either the Request Status changes to an inactive State, for example, Closed - Resolved, On Hold, Closed or until all of the Team's available escalation layers are exhausted.
Three types of alerts can be set:
Blackouts: A Blackout Period is based on an agreement between the Customer and the Service Desk regarding set times that the Customer has no service expectations. This can also be the preferred time for Item upgrades and maintenance as they will not affect service availability. A Blackout Period can be specified within an SLA. During this time the SLA is viewed as inactive and its measuring time is stopped. OLAs that underpin a Workflow State that apply an SLA with a Blackout Period, also adopt the Blackout Period.
Blackouts are typically used as part of Change and Configuration Management to advise Users about the appropriate periods of time that an Item associated with an SLA should be scheduled to be taken offline if an Outage is needed. When an Outage is being scheduled on an item the Blackout period is displayed, informing the end user of the best time to schedule a Planned Outage
Few points to note while setting SLAs: