SLA Description Template

Total Page:16

File Type:pdf, Size:1020Kb

SLA Description Template

SERVICE LEVEL AGREEMENT

SERVICE 123

(Enter Service Name above) Service 123

Purpose

This document forms the agreement between the IT Service Provider and the Business Owner for the provision of the Service 123.

Document Control

Version Date Amended by: Amendment

Document Sign-off

NAME ROLE SIGNATURE DATE

(Enter name) Business Owner

(Enter name) IT Service Owner

-2- Service 123

IT Service Owner Business Owner: Service Availability Hours: Business Criticality:

Business Criticality

Mon – Sat:

Sun: Key Service Periods:

Enter Name Enter Name Detail any critical periods; eg. month end, times of day, days of week, peak trading periods etc. Note – Detail the hours the service is to this does not change the SLA, however, it alerts all be available to the business. parties to ensure correct focus at key times for this service)

Description & Scope:

This section should provide a brief description of the service and the scope of the service included within this SLA (eg. does this include data feeds to other systems? etc).

SLA Review: Service Review:

The SLA will be reviewed by the Business Owner and Service Delivery Service delivery against availability targets detailed within this SLA will be Manager following a request for change of service/support hours, or reported on monthly (enter date of month reports to be produced, and and annually (enter month if preference stated by Business) to ensure it what forum they will be presented, eg. monthly review meeting). The remains in alignment with business requirements and is valid and useful to reports will be presented as a RAG status report with additional notes for both parties. missed targets.

-3- Service 123

Service Levels & Measures:

Availability

IT must agree with the Business Owner which service levels are to be measured and reported upon. (Note, Consider if toolset is in place to provide monitoring/measuring). The following are provided as examples of a standard SLA measuring availability on a 24 x 7 service.

 The target availability of this system is 99% across a monthly period. This equates to a maximum of 7 hrs 26 minutes downtime.

 The success or otherwise of this target will be reported on and reviewed on a monthly basis.

Calculation: Agreed Service Hours – unplanned system downtime x 100

Agreed Service Hours 1

 This target will be measured using the information logged on the Help desk tool

 The overnight schedules will be monitored by IT and all batch delays and failures will be logged on the Help desk tool.

 A manual process (as detailed above) will then be undertaken to calculate the availability for the reporting period.

 The success or otherwise of this target will be reported on and reviewed on a monthly basis as detailed in the ‘Service Review’ section of this document.

Reliability & Maintainability

 Within a review period of a calendar month, a maximum of 1 ‘severity 1’ service breach will be acceptable.

 This application is categorised as ‘business critical’ , therefore it must have the ability to be recovered and be operational within X (enter recovery time in line with criticality level) hours of a ‘disaster’ occurring

On-Line Performance

There are currently no known system thresholds for this service.

Note. Any measurements detailed in this section, must be able to be monitored, measured and reported upon.

-4- Service 123

Customer Support

This service is supported (enter hours of support)

 All system faults or incidents should be reported by the user to (enter first line support group and contact details)

 (enter support group) will log all system faults, incidents and service requests and assign an incident severity as defined in the table below. In the event that a first line fix is not available, the incident will be assigned to (enter appropriate support group) for resolution.

 Overnight batch processes will be monitored by IT. Any failures or delays will be logged and assigned to the (enter support group) Team for resolution. (delete statement if no overnight batch to monitor).

Target Fix Severity Definition

Severity 1 – Critical. High business impact, serious internal end user impact or serious Severity 1 2 hours external customer impact.

Severity 2 – Urgent. Moderate to high business impact that applies to a smaller Severity 2 4 hours number of users or a degradation rather than complete loss of service.

Severity 3 – Normal. Moderate to Low business impact. Refers to everyday faults (PC, Severity 3 10 hours Printer issues etc) and general service requests (eg. password resets etc.)

-5- Service 123

Communication

In the event of a Severity 1 incident or an incident affecting multiple users (eg. System outage, overnight batch delays) a verbal communication will be made by IT to the Business Owner within 30 minutes of the incident occurring. Further updates will be provided upon resolution or at 2 hour intervals.

Incidents can be escalated if they have either not been resolved within the relevant Target Fix time (according to assigned Severity), will exceed the assigned SLA, or are not being addressed. In all circumstances, priority will be given to ‘Severity 1’ incidents.

Contact Severity 1 Severity 2 Severity 3

1 st Stage Escalation

Enter support team, contact details and hours (if applicable eg. if 24/7) 30 mins 60 mins 120 mins

2 nd Stage Escalation

(Enter contact details and hours if applicable) >30 mins 3 hours 9 hours

3 rd Stage Escalation

(Enter contact details) 2 hours 4 hours N/A

-6- Service 123

Change Management

 All requests for change to service should be communicated to IT, who will manage them through the internal Systems process. All requests for change must be signed off via the Change Management Process.

o A request to extend/change service hours on an ad-hoc basis must be communicated at least 7 working days in advance.

o A request for change to the (enter service name) service requires a minimum of 5 working days notice. However, in the event that a change is required to fix a ‘business critical production system problem, an ‘emergency’ change may be raised to implement such a fix. This is still subject to sign-off by Change Management. The Business Owner will be informed of any such changes.

o An application functional change or long term change to service hours should be requested via IT as a ‘service requirement’. Service requirements will be collated and timescales and costs for implementation agreed with the Business Owner.

o In the event that planned downtime is required by Systems, a period of 3 working day’s notice must be provided to the Business Owner

o In order to protect our Business at key trading periods and through major system upgrades, no systems changes (with the exception of ‘emergency production fixes) will be actioned during the periods detailed in Appendix A

-7- Service 123

IT Service Continuity.

This service is covered in the company Disaster Recovery plan and must be able to be recovered within X hours of a disaster occurring and data restored to within 1 minute of loss of service (enter appropriate details, definitions below. If no DR plan exists, state in this section). Note – DR plans must be in place to support this statement.

Business Critical 1 Must be able to be recovered within 8 hours of a disaster occurring and data restored to within 1 minute of loss of service. (note. this is for hardware and software – 4 hours for hardware, 4 for software)

Business Critical 2 Must be able to be recovered within 12 hours of a disaster occurring and data restored to within 1 minute of loss of service.

Business Critical 3 Must be able to be recovered within 24 hours of a disaster occurring and data restored to within 1 minute of loss of service

Business Critical 4 Must be able to be recovered within 48 hours of a disaster occurring and data restored to within 1 minute of loss of service

Business Critical 5 Must be able to be recovered within 72 hours of a disaster occurring and data restored to within 1 minute of loss of service

Security

 Data Security. All systems data is backed up each night and stored for retrieval in case of on site disaster. (Amend as applicable

 User Security. All requests for new user Id’s and Passwords should be made to IT (Detail appropriate group).

 Password resets and new profiles must be requested from (Detail appropriate group).

 All users must abide by the Security Policy at all times. Full details on all the above can be found at:

-8- Service 123

APPENDIX A

SYSTEM CHANGE FREEZE PERIODS 2006

Month Dates Reason for Freeze

March 1st – 8th Year End

April/May 6th April – 2nd May Easter & Spring Bank Holiday key trading periods

May 23rd – 30th May Bank Holiday key trading period

August 22nd – 30th August Bank Holiday key trading period

-9-

Recommended publications