(Service Name) Operational Level Agreement 03/2014

Operational Level Agreement (OLA)
Between
[Add your department and acronym ()]Information Technology Unit (ITU)
and
XYZ
For XYZ Service

Document Version History

Version # / Date / Revised By / Reason for Change

Associate Service Level Agreement (SLA)

Version # / Date / Revised By / Reason for Change

Table of Contents

1General Overview

2Responsible Parties

2.1Stakeholders

*NOTE: Availability is defined in Section 4, Hours of Coverage, Response Time and Escalations.

3Service Description

3.1Scope of Service

3.2Customer Requirements

3.2.1General

3.2.2Standard Hours of System Operation (if applicable)

3.2.3Minimum System Stability Objectives (if applicable)

3.2.4Charges (if applicable)

3.3Assumptions

4Service Provider Requirements (Roles and Responsibilities)

4.1Service Provider Responsibilities

5Incident and Service Request Management

5.1Service Requests

5.1.1Work Requests (if applicable)/Standard Service Requests

5.1.2Non-standard Service Requests/Ad-hoc Work Requests

5.1.3Service Change Request

5.1.4Service Maintenance/Change Management

5.1.5Non-standard Service Windows

6Incident Management

6.1Normal Incident Processing

6.2Major Incident Management

6.3Escalation Procedures

6.4Urgency Incident Criteria

6.5Urgent Outage Management

6.6Service Exceptions

6.7Problem Management

7Reviewing and Reporting

Older OLAs:

(Include link to previous year’s OLA if available)

1General Overview

(Include/revise Purpose, Goal and/or Objectives relative to the specific goals and/or services of the organization.

Tip: Complete other parts of this template and come back to this section for specific goals and objectives.)

This document is anOperational Level Agreement (OLA) between (IT service providers) to document the working relationships for supporting (Name the service supported. If this OLA is associated with and SLA, state the name of the service as listed in the SLA.).This OLA shall remain valid until revised or terminated.

The goal of this Agreement is to obtain mutual agreement for service provision between ITS units.

The objectives of this Agreement are to:

  • Provide clear reference to service ownership, accountability, roles and/or responsibilities.
  • Present a clear, concise, and measurable description of service provision to the customer.
  • Match perceptions of expected service provision with actual service support & delivery.

2Responsible Parties

2.1Stakeholders

(List all relevant contact persons, for example:)

The following Service Provider(s) will be used as the basis of the Agreement and represent the primaryStakeholders associated with this OLA:

Service Provider / Title/Role / Contact Information*
[Service Provider 1 by Function] / [Title/Role] / [Contact Information]
[Service Provider 2 by Function] / [Title/Role] / [Contact Information]
[Service Provide 3 by Function] / [Title/Role] / [Contact Information]

*NOTE: Availability is defined in Section 4, Hours of Coverage, Response Time and Escalations.

3Service Description

(Find existing descriptions of existing services in the ITU Service Catalog.)

3.1Scope of Service

(Technical description of the servers goes here.)

(Service Name) features include:

  • (List notable features)

3.2Customer Requirements

The Customer responsibilities and/or requirements in support of this Agreement include

  • (List user requirements)

3.2.1General

  • (List non-measured levels.)
  • Adherence to any related policies, processes and procedures outlined in (identify specific related material)
  • Advanced scheduling of all service related requests and other special services with the Service Provider.
  • Reasonable availability of customer representative(s) when resolving a service related incident orrequest.

3.2.2Standard Hours of System Operation (if applicable)

3.2.3Minimum System Stability Objectives (if applicable)

3.2.4Charges (if applicable)

3.3Assumptions

(Add assumptions specific to the service.)

  • That (Service name)service is documented in the service catalog.
  • This document represents the current configuration to support the (Service name) service. Changes to the (service name) service areaddressed as separate service projects outside the scope of this document.
  • Major upgrades are treated as a project outside the scope of this Agreement.
  • Funding for major upgrades/updates are negotiated on a service-by-service basis.

4Service Provider Requirements (Roles and Responsibilities)

(List Service Provider responsibilities; these can be categorized by department, application or specific toservice parameters.)

4.1Service Provider Responsibilities

Service Provider 1responsibilities and/or requirements in support of this Agreement include:

Service Provider 1agrees to:

  • Meet response times associated with the priority assigned to incidents and service requests.
  • Generate quarterly reports on service levels for Customer.
  • Train designated staff on appropriate service support tools, as required.
  • Log all Provider resource hours associated with services provided for review by the

Customer, if applicable.

  • Notify the Customer about all scheduled maintenance via the Maintenance Calendar, ITU Service Catalog web page, or appropriate communications method.
  • Facilitate of all service support activities involving incident, problem, change, release andconfiguration management.
  • Meet response times associated with the priority assigned to incidents and service requests.
  • Use the outage notification process to notify Customers for all scheduled maintenance via the ITU Event Calendar, Service Catalog web page and/or a communication to campus via agreed upon methods.
  • Participate in all service support activities including incident, problem, change, release, and configuration management.
  • Meet OLA metrics as stated in the (service name) OLA located (OLAlink)
  • (List any other appropriate items.)

Service Provider 2responsibilities and/or requirements in support of this Agreement include:

Service Provider 2agrees to:

  • Meet response times associated with the priority assigned to incidents and service requests.
  • Generate quarterly reports on service levels for Customer.
  • Train designated staff on appropriate service support tools, as required.
  • Log all Provider resource hours associated with services provided for review by the

Customer, if applicable.

  • Notify the Customer about all scheduled maintenance via the Maintenance Calendar, ITU Service Catalog web page, or appropriate communications method.
  • Facilitate of all service support activities involving incident, problem, change, release, and configuration management.
  • Meet response times associated with the priority assigned to incidents and service requests.
  • Use the outage notification process to notify Customers for all scheduled maintenance via the ITU Event Calendar, Service Catalog web page and/or a communication to campus via agreed upon methods.
  • Participate in all service support activities including incident, problem, change, release, and configuration management.
  • Meet OLA metrics as stated in the (service name) OLA located (OLAlink)
  • (List any other appropriate items.

(Add additional service providers, as needed.)

5Incident and Service Request Management

(This section validates the supported processes to manage service delivery. Document Exceptions.)

5.1Service Requests

(Provide clear and unambiguous definitions of how long it will take the parties to respond. For example, if the OLA is between the Service Desk and the mainframe group, this section might include the definition of initial response to inquiry; time to review and evaluate; time to perform diagnostics; etc. These timesmust align with the escalation times as well.)

Example: In support of service outlined in this Agreement, the Service Provider will respond to service relatedincidents and/or requests submitted by the Customer within the following timeframes:

(Outline how to request the service and expected response and deliver times. Outline working durationsand customer/client interactions. This is not the service level but are key performance indicators (KPIs)that are monitored and reported on.

Service Providers may or may not be translated internal metric into the metrics usedfor the SLA. The SLA will state the outer bounds of the service delivery timeframe and service related

metrics.)

5.1.1Work Requests (if applicable)/Standard Service Requests

(Describe service requests related to this service. Examples of this could be application upgrades, OS patches, architecture changes, consultation about use of the service, setting up mail lists, etc.)

5.1.2Non-standard Service Requests/Ad-hoc Work Requests

(Describe one-time or limited-time work.)

(Describe how each non-standard service request or ad-hoc work request is to be processed so that it gets evaluated by the most appropriateservice team.)

5.1.3Service Change Request

Service Providers send Change Requests are sent to the Change Management Review Board for evaluation. (Link to Change Management section Requests for Change Process.) Service Providers schedule maintenance and service during regular maintenance windows, as appropriate. The Service Providers at their discretion will schedule Service changes that Service Providers cannot schedule during regular maintenance windows, unless defined in this OLA.

(List changes that the customer has preapproved and can be performed by the service provider without additional customer approval.)

Service Maintenance/Change Management

5.1.4Service Maintenance/Change Management

All services and/or related components require regularly scheduled maintenance (“Maintenance Window”) in order to meet established service levels.

5.1.5Non-standard Service Windows

(If a regular non-standard service window is required, please list below.)

(Fill in times.)

Time / Sunday / Monday / Tuesday / Wednesday / Thursday / Friday / Saturday
Begin
End

6Incident Management

6.1Normal Incident Processing

(Service Providers supporting this service will prioritize incoming service incidents as scheduled, standard, or emergency priority unless the service incident fits one or more of the criteria listed below.)

6.2Major Incident Management

(Service Providers supporting this service will prioritize incoming incident requests as an urgent incident if it meets agreed upon criteria. For example:)

  • Significant number of people affected.
  • Organizational structure is a multiplier for number of people affected.
  • Percentage of total tasks that can no longer be performed by individuals.
  • Academic and Administrative Calendar deadlines.
  • Significant impact on the delivery of instruction.
  • Significant or lasting impact on student academic performance.
  • Significant risk to law, rule, or policy compliance.

6.3Escalation Procedures

(Define the conditions that would necessitate an escalation and the procedures to be followed.)

6.4Urgency Incident Criteria

(Describe Urgency Criteria, if different from publish Urgency Levels.) (link to Urgency Levels.)

6.5Urgent OutageManagement

(Evaluate if your service has any Urgency Incident situations. If so, complete this section. Otherwise state as such and delete the text below.)

Under these circumstances, begin Urgency Outage Management:

  • Circumstance 1
  • Circumstance 2

Major Incident Handling Team / Contact Information / Back up Contact Information
Tech Lead / Add name and phone / Add name and phone
Major Incident Coordinator – 8-5 / Add name and phone / Add name and phone
Major Incident Coordinator – After Hours / Add name and phone / Add name and phone
SC Subject Matter Expert / Add name and phone / Add name and phone
Communications Support / Add name and phone / Add name and phone

(Additional information regarding the roles, responsibilities, and process flows of the Urgency Incident Management process is located here.)

6.6Service Exceptions

Any deviations from current policies, processes, and standards are noted by the following Service Exceptions:

(Insert special exceptions related to coverage times and dates; typically the first item is the only item in the list.)

Exception / Parameters / Coverage
University Holidays / N/A / No coverage
Fiscal Year Close / Last business day in June / Additional coverage, 8:00 a.m. to 5:00 p.m. U.S. Eastern time

6.7Problem Management

(This section is a placeholder for the problem management process. If your service has a way of analyzing and resolving problems - root cause analysis - , note it here. Otherwise, enter N/A)

7Reviewing and Reporting

This Agreement is valid from (date).At a minimum, the Stakeholders will review this Agreement once per fiscal year; however; in lieu of a review during any period specified, the current Agreement will remain in effect until next review.

The service provider(s) will be responsible for facilitating regular reviews of this document. The primary Stakeholders may amend parts of this Agreement, but must communicate any changes to all affected parties in a timely manner. The service provider(s) will incorporate all subsequent revisions and obtain mutual Agreements/approvals as required.

The service providers will hold this Agreement in a repository and make it available to all Stakeholders upon request.

.

ITU Service-Specific OLA Template (Delete this info. when completed.) 05/28/14

This is a draft document and is under review and revision David Robinson, ; 3-9477 pg. 1