Service Level Management provides a bridge between the IT service provider and the Business, operating as a focal point for customers and the business in their dealings with the IT service provider. Through regular contact and communication, SLM must represent the IT service provider to the Business, and the Business to the IT service provider. From its central position, SLM is able to build strong and effective relationships between the IT service provider and the business customers, managing their expectations and ensuring that delivered services meet or exceed those expectations.
Service Level Requirements
The needs of the business, expressed in terms the business understands, are documented as Service Level Requirements (SLRs), which contain a definition of the services the customers need, including key performance and availability targets. The SLRs will be translated by the IT service provider into Service Specifications, which define how the IT provider will make the services available, including the use of third-party providers.
Service Level Agreements (SLA)
Where one party delivers services to another, it is a good idea to have some kind of agreement setting out the basis on which the service is provided. Such agreements would normally contain, among other things, a description of what is to be provided, the key performance indicators, the way the service is to be charged for (where relevant) and the responsibilities of each of the parties. In ITIL SLM, the agreements between the internal IT service provider and the business customers that it supports are known as Service Level Agreements (SLAs) and it is through SLAs that SLM manages the relationship between itself and its customers.
It would be hard to find IT services provided by IT giants like TCS, Infosys, Wipro etc., where they do not have any accepted/agreed upon SLAs with their customers.
Definition of SLA:
ITIL defines a Service Level Agreement (SLA) as an agreement between an IT service provider and a customer. The SLA describes the IT service, records service level targets, and specifies the responsibilities for the IT service provider and the customer. A single SLA may cover multiple IT services or multiple customers.
In order to be effective, the SLA must be a written document signed off by all parties affected by it. SLAs are important so they will rarely be agreed without negotiation between the IT service provider and the customer, beginning with a Statement of Intent that sets out the terms, conditions and targets to be agreed. It has to be in a language that both sides will understand, and this means in the language of the customer and not the technical language or jargon of the provider. The SLA defines (in language that has meaning to the customer) precisely what is to be delivered and when and where it is to be delivered. It also defines the standard of quality to be delivered, usually in terms of performance and availability. It will define the responsibilities of both the service provider and the customer. This is important. It makes little sense for a service provider to commit to deliver a service without making it clear what is expected of the customer.
The SLA will include contact details, what should happen if something goes wrong, the way any disputes should be handled, any provisions for redress, the mechanism for getting the SLA changed if necessary and the period over which the agreement will stand unless otherwise changed by agreement. If the service is to be charged for, then the way charges are to be determined and the arrangements for invoicing should be included. Charges may also be included in a separate document, the Tariff, referenced in the SLA.
It is common in IT for individual services to be shared by a number of customers, and individual customers will use a range of services. This means that there is a choice in designing SLAs: they can be customer-based, where an SLA covers a range of services delivered to a particular customer; or they can be service-based, where a common SLA covers all customers of a given service.
A customer-based SLA is an agreement with a specific customer or customer group covering all the IT services they use. For example, a local authority education department might have a single agreement embracing payroll, school administration, human resources, purchasing, financial management systems, and so on. In some ways, this simplifies the relationship between IT and the customer, putting the customer‘s perspective to the fore. On the other hand, customer-based SLAs are complex and often difficult to agree and manage. Additionally, customers may be disappointed that the same service levels available to them, for common services such as email, for example, cannot be tailored to their specific needs.
A service-based SLA is an agreement with all the customers of a specific service. An example might be the organization’s intranet service. This kind of agreement makes good sense where all customers are offered the same level of service, but becomes complicated when this is not the case. Sometimes, different levels of service are inevitable (e.g. where remote users have to rely on low-speed communications). Alternatively, customers may simply demand choice. For example, some organizations will offer a PC support service with identical terms and conditions for all users, but others may offer different levels of service according to what the customer is prepared to pay. Using banded levels of service (e.g. bronze, silver and gold support levels) is a very common way of simplifying this problem. Another issue with service-based SLAs is who signs on behalf of the customer and who represent them. Having user groups with elected representatives or spokespersons is one solution.
Some organizations choose a multi-level SLA approach, where elements of services common to all customers are covered by a corporate-level SLA. Issues relating to a particular customer or customer group, no matter what the service, are then covered by a customer-level SLA and all issues relating to a specific service for the customer or customer group are covered by a service-specific SLA.
The SLA for a service must be based on realistic, achievable targets (e.g. for performance and availability), and the achievement of these targets depends on the performance of the internal and external services that underpin the delivery of the main service. Putting it another way, SLAs must reflect the levels of service actually being delivered or that can be delivered. They are about what can be done rather than what we would like to be done. If a customer requires a different level of service, this would normally be dealt with by raising a Service Level Requirement.
In order for SLM to be confident about the achievement of its SLA targets, it must have specific agreements with the internal and external providers. These agreements fall into two distinct types:
• Underpinning Contracts (UCs)
• Operational Level Agreements (OLAs)
Both should be negotiated, agreed and in place before a commitment is made to the relevant SLA.
Where an external supplier provides services that underpin the delivery of an IT service, it is essential that the provisions of the contract with the external supplier are consistent with the targets built into any SLA that depends on the external supplier. SLM must avoid making commitments in SLAs that cannot be guaranteed because the Underpinning Contract with an external supplier offers a lower standard. For example, it would make little sense for SLM to base an SLA availability target on a projected server availability of 99.9 per cent when the support and maintenance contract for the server guarantees no better than 98 per cent. It is the responsibility of SLM to ensure consistency, seeking to renegotiate UCs where contractual commitments fall short of customer needs.
The ongoing relationship between the IT service provider & the customer will be covered in future in the chapter on Supplier Management, but it is important to recognize here that UCs must always be kept in line with the needs of the business. This means that as business requirements change, the IT service provider must ensure that UCs are renegotiated or replaced, if cost-effective to do so, to ensure they continue to serve the business.
Operational Level Agreements
Many organizations find it helpful to have written agreements between different parts of the IT service provider that specify the performance targets that each part is able and prepared to underwrite. These agreements, which are known as Operational Level Agreements (OLAs), enable SLM to have confidence in the SLAs they negotiate with customers. They are not formal contracts, and need not be written in the style of formal contractual documents, but they will make clear what should be expected of a particular section of the IT service provider.
Definition of OLA:
An Operational Level Agreement (OLA) is an agreement between an IT service provider and another part of the same organisation. An OLA supports the IT service provider‘s delivery of IT services to the customers. The OLA defines the goods or services to be provided and the responsibilities of both parties.
Managing Service Levels
Putting SLAs in place with consistent UCs and OLAs achieves nothing unless performance against the SLAs is measured, monitored and reported and appropriate actions are taken to maintain and continually improve service delivery. The ongoing responsibilities of SLM are concerned with maintaining a constructive and positive relationship with its customers, measuring and monitoring performance against SLAs, reporting and reviewing performance with the customer, dealing with changing requirements and seeking to improve continually service levels where this is cost-effective. This is not a one-sided relationship, however. SLM also has a responsibility to help its customers and the business make the most effective use of IT and to meet their obligations included in SLAs.
Reports to customers and users should be in a format that is easy to follow. SLA Monitoring Charts (SLAM) are often used (sometimes referred to as a ‘RAG’ report based on the use of the colors red, amber and green to indicate SLA breach, warning or met, respectively).
SLM has responsibility for regularly reporting to the customer on performance, but will rely on other Service Management processes for the information: the Service Desk will report on the number of Incidents handled and their performance in dealing with them; Availability Management will report on Availability; Capacity Management will report on any capacity issues; and so on.
SLA Review Meetings
Regular meetings with customers are a central part of SLM. They are not just an opportunity to report on and review performance, although this is one of the key issues. It is fundamentally about building and maintaining the relationship. Review meetings are a forum for exchanging information about issues of concern, such as the need for user training or worrying trends in performance or workload. They provide an opportunity for both the IT service provider and the customer to share their plans for future change: the business may be planning an expansion in usage; there may be relevant proposals in the Forward Schedule of Changes; IT may be planning to replace key service components or to introduce new service management elements. These meetings are a means to ensure that both sides have a common understanding and that there are no difficult surprises to manage.
Continual Service Improvement is a fundamental goal of Service Management. A key objective of the regular review meetings is to identify and agree service improvements and incorporate them into the Service Improvement Plan and Service Quality Plan as part of the Continual Improvement Stage of the Service Lifecycle.
Service Improvement Plan
The Service Improvement Plan is a formal Plan to implement improvements to a Process or IT Service.
Service Improvement Plans (SIPs) are about finding and implementing ways to restore or improve service quality. They should cover all relevant services, processes and activities, and address related priorities, costs, impacts and risks. A SIP will often involve a range of initiatives (e.g. covering internal IT processes, customer training and behaviour, and third-party services, and so on).
Prev: Goals, Purpose & Objectives of Service Level Management
Next: Metrics used in Service Level Management