Checklist SLA OLA: Difference between revisions

From IT Process Wiki
mNo edit summary
Line 7: Line 7:
</imagemap>
</imagemap>
<br style="clear:both;"/>
<br style="clear:both;"/>
== <span id="Service Level Agreement - Operational Level Agreement">Overview</span> ==


'''ITIL Process''': [[ITIL V3 Service Design|ITIL 2011 Service Design]] - [[Service Level Management]]
'''ITIL Process''': [[ITIL V3 Service Design|ITIL 2011 Service Design]] - [[Service Level Management]]
Line 32: Line 34:


The SLA document evolves from the [[Service Level Management#SLR|Service Level Requirements]] during the Service Design process.
The SLA document evolves from the [[Service Level Management#SLR|Service Level Requirements]] during the Service Design process.
A multi-level SLA structure is often adopted to avoid duplication and reduce the frequency of updates, as in the following example of a three-level SLA structure:
* Corporate level, covering issues applicable to every customer within a business
* Customer level, covering issues applicable to a particular customer or customer group within a business, regardless of the service being used
* Service level, covering issues applicable to specific services


<p>&nbsp;</p>
<p>&nbsp;</p>
__TOC__
== Service Level Agreement - Contents ==


'''A Service Level Agreement typically contains the following information (actual contents may vary depending on the type of service):'''
''A Service Level Agreement typically contains the following information (actual contents may vary depending on the type of service):''


<p>&nbsp;</p>
<p>&nbsp;</p>


# Service name  
==== Service name ====
# Clearance information (with location and date)  
 
## Service Level Manager
==== Clearance information (with location and date) ====
## Customer representative
# Service Level Manager
# Contract duration
# Customer representative
## Start and end dates
 
## Rules regarding renewal and termination of the agreement (if applicable, also rules regarding early termination of the agreement)
==== Contract duration ====
# Description/ desired customer outcome
# Start and end dates
## Business justification and benefits
# Rules regarding renewal and termination of the agreement (if applicable, also rules regarding early termination of the agreement)
## Business processes/ activities on the customer side supported by the service
 
## Desired outcome in terms of utility (example: "Field staff can access enterprise applications xxx and yyy without being constrained by location or time")
==== Description/ desired customer outcome ====
## Desired outcome in terms of warranty (example: "High availability required during office hours in locations …")
# Business justification and benefits
# Communication between customer and service provider
# Business processes/ activities on the customer side supported by the service
## Responsible contact person on customer side with contact details
# Desired outcome in terms of utility (example: "Field staff can access enterprise applications xxx and yyy without being constrained by location or time")
## Designated Business Relationship Manager on service provider side with contact details
# Desired outcome in terms of warranty (example: "High availability required during office hours in locations …")
## Service Reporting (contents and intervals of service reports to be produced by the service provider)
 
## Procedure for handling exceptions and complaints (e.g. details to be included in formal complaints, agreed response times, escalation procedure)
==== Communication between customer and service provider ====
## Satisfaction surveys (description of the procedure for measuring customer satisfaction on a regular basis)
# Responsible contact person on customer side with contact details
## Service Reviews (description of the procedure for reviewing the service with the customer on a regular basis)
# Designated Business Relationship Manager on service provider side with contact details
# Service and asset criticality
# Service Reporting (contents and intervals of service reports to be produced by the service provider)
## Identification of business-critical assets connected with the service
# Procedure for handling exceptions and complaints (e.g. details to be included in formal complaints, agreed response times, escalation procedure)
### Vital Business Functions (VBFs) supported by the service
# Satisfaction surveys (description of the procedure for measuring customer satisfaction on a regular basis)
### Other critical assets used within the service (e.g. certain types of business data)
# Service Reviews (description of the procedure for reviewing the service with the customer on a regular basis)
## Estimation of the business impact caused by a loss of the service or assets (in monetary terms, or using a classification scheme)
 
# Service times
==== Service and asset criticality ====
## Times when the service required to be available
# Identification of business-critical assets connected with the service
## Exceptions (e.g. weekends, public holidays)
## Vital Business Functions (VBFs) supported by the service
# Required types and levels of support
## Other critical assets used within the service (e.g. certain types of business data)
## On-site support
# Estimation of the business impact caused by a loss of the service or assets (in monetary terms, or using a classification scheme)
### Area/ locations
 
### Types of users
==== Service times ====
### Types of infrastructure to be supported
# Times when the service is required to be available
### Reaction and resolution times (according to priorities, definition of priorities e.g. for the classification of Incidents)  
# Exceptions (e.g. weekends, public holidays)
## Remote support
 
### Area/ locations
==== Required types and levels of support ====
### Types of users (user groups granted access to the service)
# On-site support
### Types of infrastructure to be supported
## Area/ locations
### Reaction and resolution times (according to priorities, definition of priorities e.g. for the classification of Incidents)  
## Types of users
# Service level requirements/ targets
## Types of infrastructure to be supported
## Availability targets and commitments
## Reaction and resolution times (according to priorities, definition of priorities e.g. for the classification of Incidents)  
### Conditions under which the service is considered to be unavailable (e.g. if the service is offered at several locations)
# Remote support
### Availability targets (exact definition of how the agreed availability levels will be calculated, based on agreed service time and downtime)
## Area/ locations
### Reliability targets (required by some customers, usually defined as MTBF (Mean Time Between Failures) or MTBSI (Mean Time Between Service Incidents))
## Types of users (user groups granted access to the service)
### Maintainability targets (required by some customers, usually defined as MTRS (Mean Time to Restore Service))
## Types of infrastructure to be supported
### Down times for maintenance (number of allowed down times, pre-notification periods)  
## Reaction and resolution times (according to priorities, definition of priorities e.g. for the classification of Incidents)  
### Restrictions on maintenance, e.g. allowed maintenance windows, seasonal restrictions on maintenance, and procedures to announce planned service interruptions
 
### Definitions of Major Incidents as well as Emergency Changes and Releases to resolve urgent issues, including procedures to announce unplanned service interruptions  
==== Service level requirements/ targets ====
### Requirements regarding availability reporting
# Availability targets and commitments
## Capacity/ performance targets and commitments  
## Conditions under which the service is considered to be unavailable (e.g. if the service is offered at several locations)
### Required capacity (lower/upper limit) for the service, e.g.
## Availability targets (exact definition of how the agreed availability levels will be calculated, based on agreed service time and downtime)
#### Numbers and types of transactions
## Reliability targets (required by some customers, usually defined as MTBF (Mean Time Between Failures) or MTBSI (Mean Time Between Service Incidents))
#### Numbers and types of users
## Maintainability targets (required by some customers, usually defined as MTRS (Mean Time to Restore Service))
#### Business cycles (daily, weekly) and seasonal variations
## Down times for maintenance (number of allowed down times, pre-notification periods)  
### Response times from applications  
## Restrictions on maintenance, e.g. allowed maintenance windows, seasonal restrictions on maintenance, and procedures to announce planned service interruptions
### Requirements for scalability (assumptions for the medium and long-term increase in workload and service utilization)
## Definitions of Major Incidents as well as Emergency Changes and Releases to resolve urgent issues, including procedures to announce unplanned service interruptions  
### Requirements regarding capacity and performance reporting
## Requirements regarding availability reporting
## Service Continuity commitments (availability of the service in the event of a disaster)
# Capacity/ performance targets and commitments  
### Time within which a defined level of service must be re-established
## Required capacity (lower/upper limit) for the service, e.g.
### Time within which normal service levels must be restored
### Numbers and types of transactions
# Mandated technical standards and specification of the technical service interface
### Numbers and types of users
# Responsibilities
### Business cycles (daily, weekly) and seasonal variations
## Duties of the service provider
## Response times from applications  
## Duties of the customer (contract partner for the service)
## Requirements for scalability (assumptions for the medium and long-term increase in workload and service utilization)
## Responsibilities of service users (e.g. with respect to IT security)
## Requirements regarding capacity and performance reporting
## IT Security aspects to be observed when using the service (if applicable, references to relevant IT Security Policies)
# Service Continuity commitments (availability of the service in the event of a disaster)
# Pricing model
## Time within which a defined level of service must be re-established
## Cost for the service provision
## Time within which normal service levels must be restored
## Rules for penalties/ charge backs
 
# Change history
==== Technical standards/ specification of the service interface ====
# List of annexes and references (e.g. to an existing SLA master agreement which also applies to this agreement)
Mandated technical standards and specification of the technical service interface
# Glossary (if applicable)
 
==== Responsibilities ====
# Duties of the service provider
# Duties of the customer (contract partner for the service)
# Responsibilities of service users (e.g. with respect to IT security)
# IT Security aspects to be observed when using the service (if applicable, references to relevant IT Security Policies)
 
==== Pricing model ====
# Cost for the service provision
# Rules for penalties/ charge backs
 
==== Change history ====
 
==== List of annexes and references ====
(e.g. to to higher-level SLAs on the corporate or customer level which also apply to this agreement)
 
==== Glossary ====
(if applicable)


<p>&nbsp;</p>
<p>&nbsp;</p>

Revision as of 18:18, 10 March 2012

<seo metakeywords="sla ola, ola sla, itil sla, ola itil" metadescription="ITIL Template Service Level Agreement (SLA), Operational Level Agreement (OLA). This checklist covers two document types which use identical structures: ..." />

DE - ES - Checklist SLA OLA - Template SLA OLAdiese Seite auf Deutschesta página en español
DE - ES - Checklist SLA OLA - Template SLA OLA


Overview

ITIL Process: ITIL 2011 Service Design - Service Level Management

Checklist Category: Checklists ITIL Service Design

Source: Checklist "Service Level Agreement (SLA), Operational Level Agreement (OLA)" from the ITIL Process Map

 

This checklist serves as a template for a Service Level Agreement (SLA), and an Operational Level Agreement (OLA).

It covers two document types which use identical structures:

  • Service Level Agreement (SLA) - an agreement between an IT service provider and a customer.
  • Operational Level Agreement (OLA) - an agreement between an IT service provider and another part of the same organization, governing the delivery of a infrastructure service.

 

The following statements on Service Level Agreements are therefore equally applicable to OLAs, with one important point to consider: When agreeing an SLA, the Service Provider acts as a provider of services to the business; in the case of an OLA, the agreement is between two parties within the service provider organization.

 

The Service Level Agreement extends the service definition from the Service Catalogue, defining detailed service level targets, mutual responsibilities, and other requirements specific to a service provided for a certain (group of) customer(s). It focuses on the definition of requirements from a customer viewpoint.

The SLA document evolves from the Service Level Requirements during the Service Design process.

A multi-level SLA structure is often adopted to avoid duplication and reduce the frequency of updates, as in the following example of a three-level SLA structure:

  • Corporate level, covering issues applicable to every customer within a business
  • Customer level, covering issues applicable to a particular customer or customer group within a business, regardless of the service being used
  • Service level, covering issues applicable to specific services


 

Service Level Agreement - Contents

A Service Level Agreement typically contains the following information (actual contents may vary depending on the type of service):

 

Service name

Clearance information (with location and date)

  1. Service Level Manager
  2. Customer representative

Contract duration

  1. Start and end dates
  2. Rules regarding renewal and termination of the agreement (if applicable, also rules regarding early termination of the agreement)

Description/ desired customer outcome

  1. Business justification and benefits
  2. Business processes/ activities on the customer side supported by the service
  3. Desired outcome in terms of utility (example: "Field staff can access enterprise applications xxx and yyy without being constrained by location or time")
  4. Desired outcome in terms of warranty (example: "High availability required during office hours in locations …")

Communication between customer and service provider

  1. Responsible contact person on customer side with contact details
  2. Designated Business Relationship Manager on service provider side with contact details
  3. Service Reporting (contents and intervals of service reports to be produced by the service provider)
  4. Procedure for handling exceptions and complaints (e.g. details to be included in formal complaints, agreed response times, escalation procedure)
  5. Satisfaction surveys (description of the procedure for measuring customer satisfaction on a regular basis)
  6. Service Reviews (description of the procedure for reviewing the service with the customer on a regular basis)

Service and asset criticality

  1. Identification of business-critical assets connected with the service
    1. Vital Business Functions (VBFs) supported by the service
    2. Other critical assets used within the service (e.g. certain types of business data)
  2. Estimation of the business impact caused by a loss of the service or assets (in monetary terms, or using a classification scheme)

Service times

  1. Times when the service is required to be available
  2. Exceptions (e.g. weekends, public holidays)

Required types and levels of support

  1. On-site support
    1. Area/ locations
    2. Types of users
    3. Types of infrastructure to be supported
    4. Reaction and resolution times (according to priorities, definition of priorities e.g. for the classification of Incidents)
  2. Remote support
    1. Area/ locations
    2. Types of users (user groups granted access to the service)
    3. Types of infrastructure to be supported
    4. Reaction and resolution times (according to priorities, definition of priorities e.g. for the classification of Incidents)

Service level requirements/ targets

  1. Availability targets and commitments
    1. Conditions under which the service is considered to be unavailable (e.g. if the service is offered at several locations)
    2. Availability targets (exact definition of how the agreed availability levels will be calculated, based on agreed service time and downtime)
    3. Reliability targets (required by some customers, usually defined as MTBF (Mean Time Between Failures) or MTBSI (Mean Time Between Service Incidents))
    4. Maintainability targets (required by some customers, usually defined as MTRS (Mean Time to Restore Service))
    5. Down times for maintenance (number of allowed down times, pre-notification periods)
    6. Restrictions on maintenance, e.g. allowed maintenance windows, seasonal restrictions on maintenance, and procedures to announce planned service interruptions
    7. Definitions of Major Incidents as well as Emergency Changes and Releases to resolve urgent issues, including procedures to announce unplanned service interruptions
    8. Requirements regarding availability reporting
  2. Capacity/ performance targets and commitments
    1. Required capacity (lower/upper limit) for the service, e.g.
      1. Numbers and types of transactions
      2. Numbers and types of users
      3. Business cycles (daily, weekly) and seasonal variations
    2. Response times from applications
    3. Requirements for scalability (assumptions for the medium and long-term increase in workload and service utilization)
    4. Requirements regarding capacity and performance reporting
  3. Service Continuity commitments (availability of the service in the event of a disaster)
    1. Time within which a defined level of service must be re-established
    2. Time within which normal service levels must be restored

Technical standards/ specification of the service interface

Mandated technical standards and specification of the technical service interface

Responsibilities

  1. Duties of the service provider
  2. Duties of the customer (contract partner for the service)
  3. Responsibilities of service users (e.g. with respect to IT security)
  4. IT Security aspects to be observed when using the service (if applicable, references to relevant IT Security Policies)

Pricing model

  1. Cost for the service provision
  2. Rules for penalties/ charge backs

Change history

List of annexes and references

(e.g. to to higher-level SLAs on the corporate or customer level which also apply to this agreement)

Glossary

(if applicable)