Skeleton Service Level Agreement



[pic]

Operational Level Agreement

For

[xxxx]

Document Version: [xx]

Date of first approval: [dd/mm/yyyy]

Date last modified : [dd/mm/yyyy]

Table of Contents

1 Owners, Signatories and Versions 3

1.1 Owners and Signatories 3

1.2 Contributors and Version Control 3

2 Guidance 4

3 Agreement Components 4

3.1 Service Description 4

3.2 Scope of the Agreement 4

3.3 Service Targets and Key Performance Indicators (KPIs) 4

3.4 Support Arrangements 4

3.5 Training 5

3.6 Service Desk 5

3.7 Incident and Problem Management 5

3.8 Change Management 7

3.9 Release Management 7

3.10 Configuration Management and Documentation 7

3.11 Availability Management 7

3.12 Capacity Management 8

3.13 Service Continuity Management 8

3.14 Service Level Management 8

3.15 Financial Management 8

4 Change Procedure 9

5 Glossary of Terms 10

Owners, Signatories and Versions

Operational Level Agreement for [xxxx]

This agreement is made between [xxxx] and [xxxx]

This agreement is effective for [x] years from […………………..] to [………………………..]

This agreement remains valid until superseded by a revised agreement mutually endorsed by the signatories below. The agreement will be reviewed [annually]. Minor changes may be recorded on the form at the end of the agreement, providing they are mutually endorsed by all parties through change control procedure, with versioning updated.

1 Owners and Signatories

|Role |Name |Position & Unit |Date |Signature |

|Service Owner | | | | |

|Other Signatory | | | | |

|Other Signatory | | | | |

For services or major service enhancements produced as deliverables from a project the OLA will be an output of the User Acceptance stage of the project. In these cases that signatories to this document should include the Project Manager and Project Sponsor for the project.

2 Contributors and Version Control

|Name |Position & Unit |Section Updated |Date |Version Number |

|Service Owner | | | | |

|Contributor | | | | |

|Contributor | | | | |

Guidance

An OLA is a document that provides a record of agreed roles and responsibilities explaining who and what must be done by various internal organisation partners in providing a service to our customers and users. The agreed activities included in the document form an agreement between the internal partners and the service owner. The audience for this document is internal, and should be of no concern to end users or customers.

The OLA may need to be underpinned by contracts with external organisations and service partners, normally known as 'suppliers'. These contracts are also commonly referred to as UPC's (Under-Pinning Contract). The OLA should specify where a UPC is required.

Once the UPC's and OLA/s for a service have been agreed, this normally forms the basis for knowing the scope and parameters of the service we aim to offer to customers and users. This customer and user oriented offering is documented in an SLA(Service level Agreement)

.

There are parts of the template where grey italics or squared brackets are used (the latter [], indicating that a date, number or name should be entered.) These can be deleted for final draft. 

Some sections of the document are pre-populated with standard text reflecting University or Information Services policy and best practice. These should not be changed. Typically all sections of the document should be completed, although where this is not appropriate please state none or n/a, so it is clear to the reader that this section has been considered and not omitted. 

Please contact service.management@ed.ac.ukif you have any queries.

Agreement Components

1 Service Description

Describe the service covered by this OLA, typically including the following categories (Service aims, entitlement, throughput, owner/contacts, customers, communications, deliverables, hours, availability, capacity, DR level, security and backups, suppliers etc).

2 Scope of the Agreement

Describe at a high level, the business areas or units involved in the agreement and the broad objectives of this agreement. State clearly the document audience and any exclusions or caveats.

1 Service Targets and Key Performance Indicators (KPIs)

Describe any metrics and targets that will be used to assess performance of tasks as part of the OLA.

1 Support Arrangements

The IS support model is typically a layered service model, with Helpine and Computing Officers providing frontline support. Please describe the workflow for the service support, either stating that it follows normal layered models, or where it differs from the normal arrangements. Please also confirm hours of support availability.

2 Training

Identify responsibilities for training provision, materials, frequency and depth of training.

1 Service Desk

The Service Desk (IS Help Section) will be responsible for day to day service incident support and standard (known/documented) changes, initial recording and assignment of calls. The Service Desk will be responsible for:

• Receiving incidents and first line customer liaison, typically ensuring local computing officers or users have done adequate initial checks and provided appropriate details of the issue.

• Recording, classifying and tracking incidents and complaints

• Keeping customers informed of progress

• Initial assessment of requests, incidents and complaints, trying to resolve them where possible (using known errors), and passing them on where not. This critically requires adequate information gathering in a structured yet friendly manner. A primary objective is to enable minimal disruption to the customers/business, applying 'work-arounds' where necessary and applying priority, based on urgency and impact to business.

• Monitoring and escalations on SLAs

• Liaison with second and third line support

• Recording and recommending service improvements

• Identifying repeating incidents (caused by Problems)

• Highlighting customer training and educational needs

• Service alert publishing for an end user audience

• Involvement in sign off of change and release

• Implementing authorised RFC's E.g. user account admin changes

• User account admin and team admin permissions management and recording

• The Service Desk will capture data relating to service incident trends and associated KPIs.

2 Incident and Problem Management

The following table contents can be amended to detail specific agreements and tasks necessary to deliver individual services.

|1st Line Incident and Problem |IS USD Helpline - as per Helpline Responsibilities. |

|2nd Line Incident and Problem |Handling more complex incidents and problems to identify and |

| |implement work-arounds or solutions, where work requires technical |

| |skills/permissions not available to the IS Helpline. |

| | |

| |IS USD Operations |

| | |

| |Recording known errors and work-arounds for inclusion in the IS USD |

| |Helpline knowledge base. |

| |Liaison with second and third line support and involvement in major |

| |problem reviews |

| |Recording and recommending service improvements to service level |

| |managers. |

| |Identifying repeating incidents caused by Problems |

| |Highlighting customer training and educational needs |

| |Leading in any user and desktop audits |

| |Involvement in user forums |

| | |

| |IS USD Consultancy |

| | |

| |Working closely with customers and users |

| |Assisting with escalation resolution |

| |Assisting service owners with SLA creation/change |

| |Understanding and communicating user and customer service |

| |enhancement needs |

|3rd Line Incident and Problem (Service Owner) |IS Applications Service Management |

| | |

| |Triage to ensure incident and problem priority achieves maximum |

| |business benefit at minimal cost |

| |Prioritisation of incidents and problems with recognition of service|

| |support/problem budgets |

| |Business and IT administration to resolve incidents and problems |

| |Escalations relating to effectiveness of incident and problem |

| |management process |

| |Regular meetings with support partners in Operations and Production |

| |units |

|4th Line Incident and Problem (Technical and |IS Applications Production Management |

|Infrastructure) | |

| |Manage, record and escalate licence capacity to service owner |

| |Manage infrastructure logs |

| |Manage and escalate operational capacity to service owner |

| |Manage and escalate operational performance to service owner |

| |Manage and escalate operational security risks/resolution to service|

| |owner. |

| |Problem management and trend analysis, with responsibility for |

| |effective use of existing problem management resources, and |

| |infrastructure / Operating Systems / Data storage / SAN etc. |

| |Highlight requirements for annual capital funding bids |

| |Desktop CAB representation |

| |Technology licence management |

| |Firewall and security certificate management |

|Facilities Management Incident and Problem |IS ITI Unix or Architecture (delete as appropriate) are responsible |

| |for facilities management of the Windows and Unix environments in |

| |which the service infrastructure operates. |

|Networks Incident and Problem |IS ITI Network Services are responsible for all network provision |

| |and performance. |

3 Change Management

IS service change process is facilitated by the IS alerts system and procedures:

See

In addition IS Applications manage a service estimation template, which must be updated with increased or decreased costs as a result of specific changes

See

Please provide details of any further change management processes for this service, change advisory boards, change approval, change impacts benefits and priorities, forward schedule of change, change benchmarks and metrics, change freeze periods etc.

4 Release Management

Typically managed by project implementation plans. Provide details of any service specific requirements for release management and who should be involved..

5 Configuration Management and Documentation

Typically IS USD Helpline manage user documentation, although the service owner has overall responsibility. Please detail any additional documentation, knowledge base and configuration responsibilities for the service, such as TAD (infrastructure and OS maintenance).

6 Availability Management

The standard availability for IS services is at least 99.5%, but for higher priority services 99.9% availability is the target. High priority availability is published via the IS website

See

Please provide any additional service specific responsibilities.

7 Capacity Management

Describe who is responsible for capacity planning, management and documentation and how often this is reviewed. Provide any relevant inks

8 Service Continuity Management

Describe who is (typically IS Apps Production Management) responsible for resilient multi site infrastructure failover, invoking recovery, periodic failover tests etc.

9 Service Level Management

IS Applications Service Management have overall responsibility for the service, with particular operational and strategic input:

• Oversight of service documentation and communication standards

• Customer and internal service communications

• Oversight of system wide Change Management process and agenda

• Business leader for system level change

• Priorities for operational level change and RFC proposals

• Finances/resources/costs

• SLA's and OLA's (including policy)

• Supplier Management and UPCs

• Audit planning

• Service strategy, upgrade and improvement plans

• Service Continuity requirements

• Service Availability requirements

• Service Capacity requirements and monitoring/reporting

• Publishing service progress reports

• Maintenance of BCM and process owner matrix

• Responsibility for maintaining internal administrative and operational documentation. This should be located in the appropriate section of Insite Tech Collaboration:

• Leading user forums

10 Financial Management

Provide details of who has responsibility for service financial budgets, invoices, billing etc. Typically within Applications Division, responsibility will be delegated on behalf of the service owner to the Directors Office to monitor and coordinate payment of supplier invoices and administer the internal invoicing of customers and users.

Change Procedure

This OLA will be re-negotiated typically when:

• the end date (where specified) of the agreement is reached (Renegotiation will commence in adequate time for the OLA to continue to run uninterrupted, if this is agreed by both parties).

• Changes to the organisation, technologies, or strategy, significant enough to impact on the delivery of the OLA.

• Continuous or serious breaches (it is not usual for a single breach to be sufficient to trigger a re-negotiation).

There are 2 levels of change that can be made to this OLA:

Minor Change

Small points of clarification, or updates to terminology, team names etc that do not materially change the OLA in terms of obligations and charges. No re-negotiation is required in these cases.

The service owner can be the focal point in authoring changes either unilaterally of via emailed suggestions.

Major Change

Any change that materially affects the OLA, especially with regards to roles, responsibilities and recurrent charges should be drafted and signed off by party signatories.

The service owner should act as the focal point for the initiation of major change. This may have come about due to user demand, changing costs, resources, or upgrade requirements.

The process/responsibility change should be documented and requires written sign off by all signatory parties.

Any OLA change should be communicated to all those units and partners involved in service provision and support, with links to the golden copy of the OLA being provided.

Notification of Cessation

Note that where an agreement is being revoked, there may be commitment to Software, licensed for a specific period. In this case the party revoking the agreement will be liable for the costs of software/licences becoming redundant, if it cannot be re-allocate. In the event of the agreement being revoked, this should be communicated to the service owner at least 3 months in advance, for onward communication to all other stakeholders. Any signatory is entitled to provide notice to revoke their involvement in the OLA.

Glossary of Terms

Please add as required

KPI - Key performance Indication, refers to standard measurements, benchmarks and targets that can be recorded to show specifically that a service has achieved or made progress towards a pre-defined standard/target or not.

Customer - Customer, in the context of ITIL, refers to a representative of service users, normally a senior manager who had agreed to make the service available to their users.

User – User, in the context of ITIL, refers to the individual end user who makes use of the service.

FAQ - Frequently Asked Question

Work-around(s) – measure(s) taken to get the users working again as quickly as possible, however this may for example be by providing an alternate access, recognising that the underlying problem is not resolved.

[pic][pic][pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download