service level management

Page 1 of 5

A structured approach to service level management

Management summary
Enterprises are increasingly realising the importance of service level management within the IT infrastructure. Service level agreements (SLAs) are not enough. SLAs only highlight whether or not the service is reaching agreed quality standards. A structured approach to service level management enables businesses to manage more effectively the factors, which lead to world-class service delivery. This white paper describes an approach to service management, which can be applied to a wide range of companies. Based on models of the service infrastructure, structured service management identifies service delivery components and helps the creation of meaningful measurements relating to these, including key performance indicators for overall service monitoring. This enables specific actions for service improvement to be identified. It also enables service to be managed at a technical and managerial level, irrespective of organisational structure. Whilst structured service management allows monitoring against service level agreements, it does not require service level agreements to be effective. The structured service management approach creates defined and repeatable processes and encourages the development of a service culture.

Introduction
Enterprises are increasingly realising the importance of service level management within the IT infrastructure. Service level agreements (SLAs) are not enough. SLAs only highlight whether or not the service is reaching agreed quality standards. A structured approach to service level management enables businesses to manage more effectively the factors, which lead to world-class service delivery. A key feature of the structured service management approach is that it is independent of organisational structure and does not require service level agreements to be in place in order to deliver world-class service. Over time, service management has evolved from primitive beginnings to more sophisticated solutions. Structured service management is identified with the more advanced third- and fourth-generation processes. First generation (1970-1985). Measurements of service, discussion of performance against agreements. Second generation (1980-1995). Service-focused/customer-focused organisational functions created. Problem diagnosis to prevent repetition. Third generation (1990- ). Infrastructure to manage service, service culture, continuous improvement. Customerfocused service. Fourth generation (1990- ). Problems treated as a source of research and development to improve service. Customer-centred service.

Table 1. The development of service level management. Customer-focused service is where the service provider is deeply aware of the customer as someone who needs to be cared about and directed service improvement efforts at the customer. Customer-centred change is where the service provider becomes a partner with the customer in jointly diagnosing how service can be improved by deeply understanding the customer's experience of the service.

The seven IT resources

In order to manage IT, seven resources need to be managed. These are: Hardware Management software Application software

file://C:\My%20Documents\Technology\Telecom\Backbone\Paper%20service%20lev... 05-Mar-02

service level management

Page 2 of 5

Network Data Physical environment People-based activities (e.g., methodologies, procedures) Each of these resources has a common set of attributes. Together, these attributes create the "personality" of the resource, which differs from organisation to organisation. For example, no two network installations are the same, even though they may have some equipment in common. Poor management of these resources leads to poor management of the service provided to end-users. Because the resources each have their own "personality", it is unlikely that two IT installations will be similar in any meaningful way. Consequently, it is foolish to blindly copy service control reports from one business to another. Examples of resource attributes include: cost, configuration, specification and inventory. Managing the resource means managing the attributes. For example, for the people resource, poor organisation (i.e., configuration) leads to poor service and poor training (i.e., specification, affects skill sets) leads to poor service.

The Service Level Management Model

Traditionally, in managing an IT service, businesses have evolved mature systems for production management and network management. These systems tend to be reflected in the organisational structure. The management processes are well understood and implemented widely. The main objective of structured service management is to provide a predictable, acceptable service to the customers of the service. This predictable and acceptable requirement acts as the test of how well the service provider performs in meeting service levels or assessing service problems. Note that "cost" has been deliberately left out of the equation. Whilst cost of service is an important factor for the organisation, it is not a factor when poor the customer receives service. Overemphasis on cost is often an excuse for failure or for creating a poor service delivery infrastructure.

Service Level Management Architecture

The Service Level Management Architecture shows the factors, which when managed effectively, lead to creating a predictable and acceptable service.

Figure 1. Service Level Management Architecture. To understand the Service Level Management architecture, let's start at the beginning. With Service Level Agreements in place, a problem may occur. The issue is to determine what caused the problem. After some investigation, it may transpire that a server does not have sufficient capacity for its current workload. Why isn't there enough capacity? Further investigation reveals changes have taken place that affected available server capacity. Thus, it isn't enough just to have a service level agreement in place. A service level infrastructure that enables the source of the problem to be determined systematically, and better still, to manage the service factors so that potential problems are avoided. The Emperian SLM architecture is at the heart of our structured approach: everything else revolves around and supports the model. The SLM model consists of three levels and seven service components: Level 1: Problem management and change management Level 2: Capacity management, Performance management, Availability management and Access management Level 3: Service level monitoring Level 1: Problem management and change management reflect changes and problems related to the seven IT resources - hardware, management software, application software, network, data, physical environment and people. Making changes to the seven IT resources can create problems as a result. Alternatively, the dimensions of a service can change (e.g., e-commerce volumes change), and problems occur because appropriate changes fail to be made to the seven IT resources. Problems are either the result of a change or a change in the service environment. Problems mean that a service has been affected. To rectify the problem and restore service, changes will have to be made changes to one or

file://C:\My%20Documents\Technology\Telecom\Backbone\Paper%20service%20lev... 05-Mar-02

service level management

Page 3 of 5

more of the seven IT resources. When there is a problem, it must be discovered which source has changed, either explicitly or implicitly. This is why it is important to log in a change management system, changes to the resources, changes to the user demand parameters and changes to the service environment. Similarly, it is important to log, in the problem management system, any of the seven IT resources affected by a problem. Level 2: Capacity management, performance management, availability management and access (security) management are components, which describe the service parameters the customer experiences. Any problem will be articulated in terms of these four components. For example: "There isn't enough bandwidth to meet my needs" "The application is slow" "The server wasn't there when I needed it" "The system is great - when I can get into it..." In this context, access management is a broad-brush term covering areas such as accessibility and security privileges. These service components need to be managed in order to deliver a predictable and acceptable service, by altering the balance between the seven IT resources. Level 3: Service level monitoring provides the monitoring and reporting mechanism for services. It comprises such items as SLAs and overall service management reporting, account management and possibly helpdesk activities. Essentially, Level 3 is an overhead and would be unnecessary if everything was guaranteed to behave well. Conceptually, SLAs reside at the interface between Level 3 (Service monitoring) and the customer. The SLA is a construct: it is not a deliverable. Having an SLA does not create a service. Which is why a service management infrastructure is required. Service needs to be managed at each of these three levels simultaneously; and each service component needs to be actively managed. Consequently, before service level agreements are in place, processes must pre-exist to manage capacity, performance and availability. And before these are in place, processes must also exist to handle problems and changes. In practical terms, service is rarely provided in such a logical stratified fashion. However, it is possible to bring them together as a single integrated approach to service management, even if they have been created piecemeal.

Service component and resource links

Important links exist between the seven IT resources and the service components. If a resource is changed (e.g., a hardware upgrade, reorganisation of staff responsibilities), then these have the potential to impact Level 2 service components. For example, a hardware upgrade can affect server availability. A partial hardware outage during an equipment changeover/replacement can affect capacity and performance. An application software implementation can affect security/access. In turn, each of these can have a significant effect the service delivered, both in terms of predictability, acceptability or both. Thus, if changes are made to IT resources, then their impact on Level 2 service components must always be considered. Similarly, changes in any resource may need to be taken into account in the Level 1 and Level 3 service components. For example, a staff reorganisation may affect the ability to perform change and problem management. Changing a PC's presentation package, say, from Freelance to PowerPoint may affect the ability to produce timely SLM information. Failure to notify resource changes to Level 1 and Level 3 service components tend to affect management of the service rather than the delivery of the service itself.

Level 1 and Level 2 links

Links exist between Level 1 and Level 2 service components. A change management system must have a way of recording and managing the impact of change on Level 2 service components before the change is made; and must also specify which resources are affected and which are responsible for the change. Similarly, a problem management system must have a way of recording which Level 2 service components are affected and also which resources are affected or involved, if problems are to be managed effectively.

Level 2 and Level 3 links

For any organisation, there is an optimum level of service that can be achieved with the available resources. Providing the best services with existing resources can be continuously strived for and does not require SLAs. If the service expectations of, for example, internal customers are greater than can be achieved through existing resources, then this can be demonstrated through the structured service management approach. It is not necessary to have service level agreements (SLAs) in place in order to provide a predictable and acceptable service. Service level objectives (SLOs) are better at helping to create this than SLAs. SLOs are the measures that a professional technician or line manager would use to assess how well the service was being provided from the point of view of creating the maximum possible service achievement with the resources that are available. In this context, a technician is not a person with esoteric technical skills. A technician is any person with the necessary skills to perform their particular operational job.

file://C:\My%20Documents\Technology\Telecom\Backbone\Paper%20service%20lev... 05-Mar-02

service level management

Page 4 of 5

The benefit of an SLO is that it can be a technical measurement that does not always need to be explained to the outside world. This means it can use the language of those doing the job without being embarrassed about it. Wellwritten SLAs state requirements in business terms. This can be a real issue, if these business terms are not translated into the actions of those responsible for delivering the service. Further, they will know how well they are doing in their own terms, rather than through an SLA performance report stated in SLA language. For example, an SLA may state that subsecond response time is required for users accessing a mainframe. But what does this mean to an installer of LAN hardware and software for users accessing the mainframe over the LAN? In practical terms, it means that the person responsible for upgrading LAN hardware and software should not do so at times of high mainframe usage (e.g., 10am-noon or 2pm-5pm during the working week). For a systems programmer, an SLO could be the amount of swapping/paging. For an operations person, it could be the amount of tapes that need to be loaded from outside a robotic tape silo. Each function will have its own set of SLOs that describe how they know when they can be affecting service levels. Some SLOs can also be crossfunctional. The SLOs provide the control mechanisms for the technicians to be able to manage the service. They also enable management to be undertake at the lowest possible organisational level. They also help identify service failures.

SLOs and Level 3 service components

SLOs provide the link between the Level 2 and Level 3 service components, by monitoring selected elements of the Level 2 service delivery components which contribute to the overall service which is monitored in Level 3. This more granular approach to measurement offers the capability to anticipate events which may lead to service brownouts. Further, these measurements are in the hands of those who can directly affect the service delivery. If SLAs are in place, then the measures used (e.g., response times, system availability times) must also be accessible to the staff managing the SLOs. A chasm must not exist between the groups managing the SLOs and SLAs. The information gained from SLOs can be aggregated into higher level key performance indicators using in Level 3 monitoring (e.g., response time by subsystem, total number of days problems have been outstanding within a severity category, such as problem backlog days).

SLO measurements
Items to measure in SLOs will be related to the seven service components: problem management, change management, capacity management, performance management, availability management, access management and service level monitoring. They will also be related to the seven IT resources: hardware, management software, application software, network, data, physical environment and people-based activities. Thus, SLOs will track such items as: Resource event occurrences (e.g., backup running into the online day) Problem situations Changes: successes, failures Ratios, averages, utilisation (e.g., peak and average bandwidth usage on WAN links) Rates, duration (e.g., set-up times, turnaround times) Totals, increments, volumes (e.g., trending, baselining) Existence, non-existence of resources (availability, outage)

For example, by monitoring the length of an overnight schedule, it may be possible to see a creep into the online day through the introduction of a new strategic application. Thus, SLOs help avoid and mitigate potential problems before they occur.

Service system layers

Service is the responsibility of everyone in the service system (not just the service provider). It thus includes managing the seven IT resources; those involved in any way with the chain of events that creates or distributes the service; and the recipients of the service itself. Customers have rights to a service, but they also have a duty of care not to damage the service delivery themselves. Some customers recognise only their rights and do not appreciate their corresponding duties. The service system has three layers: customer layer, service layer and resource layer.

file://C:\My%20Documents\Technology\Telecom\Backbone\Paper%20service%20lev... 05-Mar-02

service level management

Page 5 of 5

Figure 2. The service system layers.

Customer-diagnosed change
Customer-diagnosed change is a method of building service excellence by focusing activity on the most important needs and problems of customers, in relation to the service they are receiving. It is aimed at removing the barriers to service excellence. Usually, when asked about what they want, customers state generalised requirements: what they already have, together with a wish list which only scratches the real problems and difficulties they are dealing with. When asked about their problems, customers are much more specific and much more focused. They will state what is really important to them and why it is important and why it is important. Customer-diagnosed change uncovers the real problems of customers in relation to the service they are experiencing. This enables change to be focused on what is really important to them rather than what the service provider perceives is important. It is the customer who diagnoses what changes are required. Whilst traditional approaches to service management have an essentially introverted perspective - collecting and analysing statistics in order to measure and improve service - this aspect of structured service management seeks feedback from customers about their experiences i.e., takes an extroverted approach to service management. This also avoids the often unactionable statements found in surveys devised by service providers.

Conclusions
The aim of structured service management is to provide a predictable and acceptable level of service to customers. The service management architecture provides a core infrastructure through which service can be managed. This must be done in conjunction with management of the seven It resources. Service level agreements are not always required for service management. Structured service management can operate with or without service level agreements, whether formal or informal. The use of service level objectives is a fundamental requirement of managing service. Customer-diagnosed change focuses on resolving the unfulfilled service needs of customers by focusing on their problems as experienced by them.

file://C:\My%20Documents\Technology\Telecom\Backbone\Paper%20service%20lev... 05-Mar-02