Using Service Level Agreements Takes the Guesswork out of IT Support

I was working on developing a Service Level Agreement (SLA) for a client recently and ended up finding some useful information on the topic in general. There is a lot of good information available about SLAs as it fits into the ITIL (Information Technology Infrastructure Library) model. ITIL is a British creation and much more popular on the other side of the ocean. Microsoft has a similar model called the Microsoft Operations Framework (MOF). I found the ITIL model more flexible so I'm focusing on that model. However in both ITIL and MOF, the Service Level Agreement is an important component of IT service management and I believe librareis would benefit from developing SLAs between their IT (information technology) service provider and the various departments that rely on that service. Thus this entry....

Based on ITIL, a Service Level Agreement (SLA) is a documented agreement between the service provider (IT Dept.) and the service recipient (e.g. various departments of the library). The SLA is an internal document. It is not a legal contract but a commitment that accurately and fairly reflects what the library wants (and needs) and what the IT Dept. can reasonably provide.

The SLA sets expectations. It should be short and concise like this Public Access Service Level Agreement used by the University of Sydney.

Two other related terms are the Operation Level Agreement (OLA) and the Underpinning Contracts (UCs). OLA are like SLAs but they are internal to the service department. In other words, once the IT Dept. in the library has established an agreement with all other library departments about what the library needs and can expect from the IT Dept. (as documented in the SLAs), then the IT Dept. needs to figure out what it needs to do in order to meet their commitments. The OLA establishes ITs commitments to itself. UCs are contracts between the library (for example) and an outside service provider. An UC establishes the targets that the contractor must meet in order to satisfy the needs of the client.

In the world of ITIL, SLAs, OLAs and UCs work together to form the service catalog (that would be catalogue to the ITIL blokes) which represents all the service components involved in addressing the customers needs. But let's get back to the SLAs....

Each SLA has specific components that are usually included depending on whether it is a Public Access Service Level Agreement or a Staff Desktop Service Level Agreement, a Web Service Level Agreement, or a Help Desk Service Level Agreement.

Most Service Level Agreements will include sections describing the following:

• Description of the Service
• Date of Agreement
• Service Hours
• Where Service is Delivered
• Service Coordinator
• Responsibilities of Service Coordinator
• User Responsibilities
• Support Procedures
• Escalation
• Procedure for Changes to Service
• Monitoring and Reporting

Other sections that you might consider including in your Service Level Agreement are Support Responsibilties,
External Dependencies, Server Maintenance Plans (aka Continuity), Standards Followed, Developments Underway or Planned, User Training Required to Use Service, Underpinning Contracts, Frequency of Reviews of SLA, and Cost/Charging.

The point is to flesh out and state clearly what is expected of the service and define how it is to work. The key is to define the service in a way that can be accomplished by your service group. It should be a practical, reality-based document that takes the guess work out of IT support for both the service provider and the service receiver.