Operating Level Agreement (OLA) Template About this template This template provides a consistent format for all Operating Level Agreements (OLAs) between internal departments of ITS and a recognized IT customer requesting IT services(s). It addresses responsibilities and procedures for these internal departments, whose purpose is to provide IT services and support to the UCSC community. The objective of the OLA is to present a clear, concise and measurable description of the services provided. For additional Service Provider responsibilities, refer to the related document, OIT Incident Management System Operations Policy (Remedy/ServiceWare). How to use this template Save this template under a new name before making any changes. To save the template under a new name 1 On the File menu, click Save As. The Save As window opens. 2 In the Save in box, select the location for the new file. 3 Enter a new name in the File name box. 4 Click Save. Use only the sections of this document relevant to the SLA being addressed. Delete any non-relevant sections. Delete any blue text during final revision. Blue text indicates instructional information. Replace pink text with appropriate relevant text. Pink text also indicates a cross-reference you may need to modify or delete. Reformat pink text to black. Do not revise red text. Reformat red text to black during final revision. Delete the template watermark. To delete the template watermark 1 On the View menu, click Header and Footer. The Header and Footer toolbar opens. 2 In the document, select the template watermark. 3 Press DELETE. 4 Click Close in the Header and Footer toolbar. Change the header to reflect the appropriate Service Provider. To change the header 1 On the View menu, click Header and Footer. The Header and Footer toolbar opens. 2 Select and delete the appropriate items from the header. 3 In the Header and Footer toolbar, click Close. Generate a new table of contents after final edits are made. To generate a new table of contents 1 Right-click in the Contents. A context-sensitive menu appears. 2 Select Update Field. The Update Table of Contents window opens. 3 Select Update entire table. 4 Click OK. The Contents is updated. Select this instructional page and press DELETE. Rev. 01/30/07 1 OLA template 0129.doc
Operational Level Agreement (OLA) for [Consumer] by [Provider] Effective Date: Document Owner: Version Version Date Revision / Description Author Approval Approver Title Approval Date Agreement Termination Approver Title Termination Date Other Agreement Ref.:
Table of Contents Operating Level Agreement (OLA) Template... 1 1 General Overview... 4 2 Parties Responsible... 4 Stakeholders... 4 Hours of coverage... 4 3 Supported Services and Charges... 5 Service Scope... 5 Service Components... 5 Customer Requirements... 6 Service Provider Requirements... 6 Service Assumptions... 6 4 Roles and Responsibilities... 7 Stakeholder 1... 7 Stakeholder 2... 7 Stakeholder 3... 7 5 Prioritization and Escalation... 7 Incident Prioritization... 7 Service Prioritization... 8 6 Service Requests/Response Times... 8 Service Requests... 8 Service Maintenance... 8 Service Exceptions... 9 7 Reporting, Reviewing and Auditing... 9 8 Appendix A: Associated Policies, Processes and Procedures... 9 Incident Management... 9 Major Incident Handling... 9 ITS Service Outage Announcement Process... 10 Change management (initiated by group providing service)... 11 1
General Overview This document represents an Operational Level Agreement ( OLA ) between [Consumer] and [Provider] to document the work and response times for supporting [service name from service catalog or elsewhere] ( The Service ). This OLA shall remain valid until revised or terminated. The purpose of this Operational Level Agreement ( OLA or Agreement ) is to ensure that the proper elements and commitments are in place to provide consistent service support and delivery to the Customer(s) by the Service Provider(s). The goal of this Agreement is to obtain mutual agreement for service provision between the Service Provider(s) and Customer(s). 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. Include / revise Purpose, Goal and/or Objectives relative to the specific goals and/or services of the organization. 2 Parties Responsible Stakeholders List all relevant contact persons, for example: The following Service Provider(s) and Customer(s) will be used as the basis of the Agreement and represent the primary stakeholders associated with this OLA: IT Service Provider(s): ( Provider ) IT Customer(s): ( Customer ) Stakeholder Title / Role Contact Information [Stakeholder 1] [Title / Role] [Contact Information] [Stakeholder 2] [Title / Role] [Contact Information] [Stakeholder 3] [Title / Role] [Contact Information] [Stakeholder 4] [Title / Role] [Contact Information] Hours of coverage List all Service Providers hours of coverage. Service Provider Availability (Internal) Hours of Operation (To customers) Support Center Monday-Friday, 8am 5pm Monday-Friday, 8am 5pm
3 Supported Services and Charges State specifically the services provided by each silo involved, listing the deliverables for each party. This is not the same as the IT Services covered under the Objectives & Scope, but rather the services each party will render to the other. This Agreement covers the following Services. The IT Service Catalog contains full descriptions, specifications, and costs (if any). Reference No. Service OR (above, ola by service. Below, ola by service category. This begs the question about ola development re: by service or by unit) In order to effectively support Service Level Agreements and/or other dependent agreements, policies, processes and/or procedures, specific service parameters must be defined. Service Scope The following Services are covered by this Agreement; full descriptions, specifications and costs are outlined in the IT Service Catalog. (References to the Service Catalog may be pasted into this document or added as an Appendix to the Agreement for clarification, if required) Reference No. Service 2.1.1 Batch Processing 9.3.1 Data Backup 12.1 12.9 Service Support Service Components As a subset of services provided, the physical and/or logical components covered by this Agreement include the following: (Itemize all applicable infrastructure components associated with service provision, including any hardware and/or software) Component Name Component Description Component Location Application Server X Primary application server for IP 255.255.255.255 Application Z
Application Server Y File & Print Server Z Network Hub A Operating System B Customer Requirements Backup application server for Application Z File & Printer Server for Application Z Network Hub for all Application Z traffic Operating system on Application Servers X and Y IP 255.255.255.255 IP 255.255.255.255 IP 255.255.255.255 Resides on Application Server Y and Y Customer responsibilities and/or requirements in support of this Agreement include: List Customer responsibilities; these can be categorized by department, application or specific to service parameters. Adherence to any related policies, processes and procedures outlined in Appendix A: Related Policies, Processes and Procedures. Appropriate incidents and/or request prioritization as previously outlined and/or in cooperation with the Service Provider. Advanced scheduling of all service related requests and other special services with the Service Provider. Creation and maintenance of all required project documentation. Appropriate use of support toolsets as outlined in Appendix A: Related Policies, Process and Procedures. Payment for all service-related setup and/or configuration costs prior to service provision. Review related service hours logged by Service Provider for accuracy. Review all service related reports distributed by the Service Provider. Reasonable availability of customer representative(s) when resolving a service related incident or request. Service Provider Requirements Service Provider responsibilities and/or requirements in support of this Agreement include: List Service Provider responsibilities; these can be categorized by department, application or specific to service parameters. Meeting response times associated with service related incidents. Generating quarterly reports on service levels for Customer (-see Service Level Management). Training required staff on appropriate service support tools. Logging all Provider resource hours associated with services provided for review by the Customer. Appropriate notification to Customer for all scheduled maintenance (-see Service Level Management). Facilitation of all service support activities involving incident, problem, change, release and configuration management. Service Assumptions Assumptions related to in-scope services and/or components include: Services are provided to internal IT customers only. Internal customer user base will remain within 10% of current staff levels.
Funding for major upgrades will be provided by the Customer and treated as a project outside the scope of this Agreement. Changes to services will be communicated and documented to all stakeholders. 4 Roles and Responsibilities For the agreed services covered, document who has responsibility for each step in delivering the service.. (These can be also be categorized as Help Desk, Network and/or Application specific.) Stakeholder 1 Outline Stakeholder 1 s responsibilities, Stakeholder 1 agrees to: Be willing and available to provide critical information within <x> hours/minutes of receiving a request for information from Stakeholder 2 seeking to resolve a Stakeholder 1 issue. <><><> <><><> Stakeholder 2 List Stakeholder 2 s responsibilities. Stakeholder2 agrees to: Meet response times associated with the priority assigned to issues. Generate and share with Stakeholder 1 periodic reports to monitor compliance with service goals (see Service goals on page Error! Bookmark not defined.). Stakeholder 3 List Stakeholder 3 s responsibilities (these would be customer requirements in support of this agreement) Stakeholder 3 agrees to: Adherence to any related policies, processes and procedures outlined in Appendix A: Related Policies, Processes and Procedures. Appropriate incidents and/or request prioritization as previously outlined and/or in cooperation with the Service Provider. Advanced scheduling of all service related requests and other special services with the Service Provider. Creation and maintenance of all required project documentation. Appropriate use of support toolsets as outlined in Appendix A: Related Policies, Process and Procedures. Payment for all service-related setup and/or configuration costs prior to service provision. Review related service hours logged by Service Provider for accuracy. Review all service related reports distributed by the Service Provider. Reasonable availability of customer representative(s) when resolving a service related incident or request. <><><> 5 Prioritization and Escalation This section will probably be the most contentious to define, since failure to perform can result in escalation. It is important to stress that the goal is not finger pointing or to make another department a scapegoat, but to assure delivery of prompt service as agreed, and the acceleration of support for high priority issues. Incident Prioritization The support center will prioritize incoming requests as high priority if the request meets any one of the following criteria: 7.1 Significant number of people affected.
Organizational structure is a multiplier for number of people affected. 7.2 Percentage of total tasks that can no longer be performed by individuals. 7.3 Academic and Administrative Calendar deadlines. 7.4 Significant impact on the delivery of instruction. 7.5 Significant or lasting impact on student academic performance. 7.6 Significant risk to law, rule, or policy compliance. Service Prioritization <><><>placeholder<><><> 6 Service Requests/Response Times 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 times must align with the escalation times as well. Service Requests In support of services outlined in this Agreement, the Service Provider will respond to service related incidents and/or requests submitted by the Customer within the following time frames: Priority Initial Status Ongoing Status Escalation Normal 2 hours As needed Need to discuss High 30 minutes As needed Need to discuss Response times listed are in business hours Initial Status: Ticket assignee enters note in IT Request that describes the current status of the request. Initial status note should include estimated time of next status note Refer to the service support policies, processes and related procedures for additional information in Appendix A: Related Policies, Processes and Procedures. Specific incident and/or request parameters, thresholds and/or samples may be inserted here for additional clarification. Service Maintenance All services and/or related components require regularly scheduled maintenance ( Maintenance Window ) in order to meet established service levels. These activities will render systems and/or applications unavailable for normal user interaction for the following locations and timeframes: Location(s): [Location(s)] Timeframe(s): [Timeframe(s)] e.g.: 2:00 a.m., Sundays, U.S. Eastern time Time Sunday Monday Tuesday Wednesday Thursday Friday Saturday Begin 02:00 EST 0:00 0:00 02:00 EST 0:00 0:00 0:00
End 14:00 EST 0:00 0:00 02:30 EST 0:00 0:00 0:00 Add additional locations and timeframes as required Service Exceptions Any deviations from current policies, processes and standards are noted by the following Service Exceptions: (Insert any special exceptions related to coverage times and dates) Exception Parameters Coverage Federal Holidays N/A No coverage Fiscal Year Close Last business day in May Additional coverage, 8:00 a.m. to 5:00 p.m. U.S. Eastern time Emergency service coverage Critical business need Customer may request support by contacting the Service Desk 7 Reporting, Reviewing and Auditing Any agreement requires oversight and reporting, and no agreement runs forever. This section clearly defines the duration of the OLA, when and under what conditions to review the OLA, and when, what and to whom to report. Also included in this section should be Key Performance Indicators (KPIs) so that the OLA owner can track performance and if required take action before breaches occur. This Agreement is valid from the Effective Date outlined herein and is valid until the Date of Termination. The Agreement should be reviewed at a minimum once per fiscal year; however, in lieu of a review during any period specified, the current Agreement will remain in effect. The Designated Review Owner ( Document Owner ) is responsible for facilitating regular reviews of this document. Contents of this document may be amended as required, provided mutual agreement is obtained from the primary stakeholders and communicated to all affected parties. The Document Owner will incorporate all subsequent revisions and obtain mutual agreements / approvals as required. Designated Review Owner: [Document Owner] Review Period: [Review Period] e.g. Annually or Quarterly Previous Review Date: [Last or Previous Review Date] Next Review Date: [Next Review Date] This Agreement will be posted to the following location and will be made accessible to all stakeholders: Document Location: [OLA Directory and/or Location] 8 Appendix A: Associated Policies, Processes and Procedures Incident Management <><><>Place holder <><><> Major Incident Handling <><><>Place holder <><><>
ITS Service Outage Announcement Process ITS Service Outage Announcement Process Planned and Unplanned (Emergency) Outages When to Use this Process: This is a communication process for ITS service outages during standard business hours in order to lessen campus impact. This process is directly associated with Change Management and is used for all service changes that require communication. In collaboration with other ITS units, the Portfolio Management Group (PMG) will manage all internal and external service announcements for ITS. All service messages are reviewed and edited, and once approved, distributed by Lisa Bono, ITS Communication Coordinator. This process is required when there is a planned or unplanned service outage visible to the client or an emergency service failure. This process is optional for other service changes, including routine maintenance, that need to be communicated. Steps for Planned Service Outages: 1) Here are questions to guide your thinking on what needs to be communicated: Who will this outage affect? If the service outage affects clients, who and how many, is there training involved, and what are some of the ways the clients might be affected. Am I prepared? Are the appropriate representatives, (e.g., end users, ITS management, Support Center, providers of the service) aware of the risks associated with the outage. What will happen if I don t do this planned service outage? Is the outage due to the need for emergency work, have I considered the least disruptive way to make the work happen, and have I confirmed this approach with my manager. 2) Email the service outage information to announce@ucsc.edu a minimum of two weeks prior to the scheduled maintenance date. This preparation window allows time to approve the schedule, prepare the message, and notify the ITS division and other campus groups as necessary. 3) Include this information in your email: What Happens: Who: requested by, sponsored by, prepared by What: description of outage (service/location) Why: reason for outage When: date and time of proposed outage Audience: If known, who does this outage affect Risk elements: Number of users impacted, training required, time to perform change, local testing, backout/recovery, impact if outage not performed Lisa will discuss the proposed schedule for service outage to the interim change
approval board (CAB) for final approval. This group currently consists of Bill Hyder, Brad Smith, Pat LeCuyer, Janine Roeth, Divisional Liaisons, Support Center Managers, and specific directors associated with the outage. Once approved, Lisa communicates the outage and adds to the ITS online maintenance calendar. Change management (initiated by group providing service) Define the process for managing changes to service delivery, including enhancements or upgrades in products or services. Describe the anticipated scope of changes, including impact on availability of applications or network resources. Describe the change validation process, that is, how the success or completion of the change is verified and closure achieved, and who is responsible. The ITS Change Management policy is to ensure that standardized methods and procedures are used for the efficient and prompt handling of all changes, to minimize the impact of any related incidents upon ITS services. There will be one change management process to identify, assess, prioritize and schedule changes to the production environment. All changes affecting the characteristics or configuration within the production applications and infrastructure for which ITS has accountability will be subject to the change management process. A risk assessment level will be associated with every change and will be assigned using the predetermined criteria. The approving authority will be based on the risk assessment. The Change Management process has several stages as illustrated in the following diagram: