Checklist SLA OLA UC

<seo metakeywords="sla ola, sla ola uc, itil sla, uc itil" metadescription="Templates Service Level Agreement (SLA), Operational Level Agreement (OLA), Underpinning Contract (UC). This checklist covers three document types ..." />

DE - ES - Checklist SLA OLA UC - Template SLA OLA UC - Service Level Agreement (SLA), Operational Level Agreement (OLA), Underpinning Contract (UC)

ITIL Process: ITIL V3 Service Design - Service Level Management

Checklist Category: Checklists ITIL V3 Service Design

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

 

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

The three document types 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.
• Underpinning Contract (UC) – a contract between an IT service provider and an external provider of an infrastructure service.

As UCs are formal contracts with external suppliers they may contain references to general terms and conditions or an additional first section specifying commercial and legal details.

 

The following statements on Service Level Agreements are therefore equally applicable to OLAs and UCs, with one important point to consider: When agreeing an SLA the Service Level Manager acts as a provider of services to the business; he is in the role of a customer in the case of an OLA/ UC.

 

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
3. Contract duration
   1. Start and end dates
   2. Rules regarding termination of the agreement
4. Description/ desired customer outcome
   1. Business justification
   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: “Access is facilitated worldwide in a secure and reliable manner”)
5. 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)
6. Reference to further contracts which also apply (e.g. to an existing SLA Master Agreement, or in the case of UCs to contracts with important sub-contracted suppliers)
7. Service times
   1. Hours when the service is available
   2. Exceptions (e.g. weekends, public holidays)
   3. Maintenance slots
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. Downtimes for maintenance (number of allowed downtimes, pre-notification periods)
      6. Restrictions on maintenance, e.g. allowed maintenance windows, seasonal restrictions on maintenance
      7. Procedures for announcing interruptions to the service (planned/ unplanned)
      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. Costs and pricing
    1. Cost for the service provision
    2. Rules for penalties/ charge backs
13. Change history
14. List of annexes