Checklist SLA OLA: Difference between revisions

From IT Process Wiki
(Created page with "<seo metakeywords="sla ola, ola sla, itil sla, ola itil" metadescription="ITIL Template Service Level Agreement (SLA), Operational Level Agreement (OLA). This checklist covers tw...")
 
mNo edit summary
Line 1: Line 1:
<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: ..." />
<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: ..." />
<imagemap>
<imagemap>
Image:ITIL-Wiki-deutsch.jpg|right|Checklist SLA OLA - Template SLA OLA
Image:ITIL-Wiki-de-es.jpg|DE - ES - Checklist SLA OLA - Template SLA OLA|100px
default [https://wiki.de.it-processmaps.com/index.php/Checkliste_SLA_OLA diese Seite auf Deutsch]
rect 0 0 50 30 [https://wiki.de.it-processmaps.com/index.php/Checkliste_SLA_OLA diese Seite auf Deutsch]
rect 50 0 100 30 [https://wiki.es.it-processmaps.com/index.php/Lista_de_control_-_SLA_OLA_UC esta página en español]
desc none
desc none
</imagemap>
</imagemap>
Line 17: Line 18:
This checklist serves as a template for a ''Service Level Agreement (SLA)'', and an ''Operational Level Agreement (OLA)''.
This checklist serves as a template for a ''Service Level Agreement (SLA)'', and an ''Operational Level Agreement (OLA)''.


The three document types use identical structures:
It covers two document types which use identical structures:


* Service Level Agreement (SLA) - an agreement between an IT service provider and a customer.
* Service Level Agreement (SLA) - an agreement between an IT service provider and a customer.

Revision as of 11:57, 7 January 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


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 Service Level Agreement typically contains the following information (actual contents may vary depending on the type of service):

 

  1. Service name
  2. Clearance information (with location and date)
    1. Service Level Manager
    2. Customer representative
  3. 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)
  4. 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 …")
  5. 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)
  6. 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)
  7. Service times
    1. Times when the service required to be available
    2. Exceptions (e.g. weekends, public holidays)
  8. 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)
  9. 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
  10. Mandated technical standards and specification of the technical service interface
  11. 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)
  12. Pricing model
    1. Cost for the service provision
    2. Rules for penalties/ charge backs
  13. Change history
  14. List of annexes and references (e.g. to an existing SLA master agreement which also applies to this agreement)
  15. Glossary (if applicable)