Service Management Functions
Service Level Management
Managing the Windows Server Platform
On This PageContributorsProgram Manager Lead Writer Other Contributors Mark Ross Sutherland, G2G3 Group Ltd. Frank Zakrajsek, Microsoft Corporation Test Manager QA Manager Lead Technical Writer Technical Writer Lead Technical Editor Editor Patricia Rytkonen, Volt Technical Services Christine Waresak, Volt Technical Services Production Editor 1 - IntroductionThis chapter provides an overview of this document's purpose, its audience, and its use. It also provides the background of and a brief introduction to Microsoft Frameworks. Document PurposeThis guide provides detailed information about the Service Level Management service management function (SMF) for organizations that have deployed, or are considering deploying, Microsoft technologies in a data center or other type of enterprise computing environment. This is one of the more than 20 SMFs defined and described in Microsoft® Operations Framework (MOF). The guide assumes that the reader is familiar with the intent, background, and fundamental concepts of MOF as well as the Microsoft technologies discussed. An overview of MOF and its companion, Microsoft Solutions Framework (MSF), is available in the MOF Service Management Function Library guide. This overview also provides abstracts of each of the service management functions defined within MOF. Detailed information about the concepts and principles of MOF and MSF is also available at http://www.microsoft.com/solutions/msm. Intended AudienceThis material is designed to be of value to both internal staff and consultants. It is aimed primarily at two main groups: information technology (IT) managers and IT support staff who either introduce or support Service Level Management in a production IT environment. It is assumed that readers are fully conversant with MOF Process, Team, and Risk models. Copies of documents describing these models are available at http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx. How to Use This GuideThis guide can be used as a starting point for introducing Service Level Management into an organization or, when an organization has some degree of Service Level Management, for developing and improving existing Service Level Management processes within the organization. This guide shows that Service Level Management can be used in line with or independent from MOF, but maximum benefits will be derived when it is used as a part of the complete framework of recommended practices. BackgroundThe United Kingdom Office of Government Commerce (OGC) developed the IT Infrastructure Library (ITIL) as a comprehensive and coherent code of practice to help organizations provide efficient and cost-effective IT services. The OGC is a government executive agency tasked with developing best practice guidance on the use of information technology (IT) in service management and operations. To accomplish this, the OGC charters projects with leading IT companies around the world to document and validate best practices in the disciplines of IT service management. Microsoft Frameworks recognizes that current industry best practice for IT service management is well documented within the ITIL. Microsoft FrameworksMicrosoft Frameworks provides innovative solutions that are built on proven practices for people, processes, and technology based on the IT life cycle. A part of its strategy is to address the ever-changing nature of today’s distributed IT environments. Its solutions are delivered through integrated frameworks and custom-tailored service engagements by MSO and Microsoft partners. The frameworks draw on the extensive experience that Microsoft, its customers, and its industry partners have in implementing and running mission-critical systems using Microsoft products and technologies. The frameworks provide a bridge that connects products and technologies with customer solutions. The frameworks provide the managerial and technical knowledge that organizations need to get the most from their technology investment. The IT life cycle contains four phases—planning, preparing, building, and operating:
MSF and MOF provide the information, tools, and resources related to the people, processes, and technologies needed to successfully complete each phase. The first phase, planning, involves planning at the organizational level and necessarily precedes the planning for a specific solution that is the first phase of a project within MSF. Both MSF and MOF incorporate the preparing and readiness phases of the life cycle within their respective processes. MSF provides guidance on the building phase, and MOF discusses the operating phase of the IT life cycle. Microsoft Solutions FrameworkMSF provides guidance in the planning, building, and deploying phases of the project life cycle. This guidance is in the form of white papers, deployment guides, tools, templates, case studies, and courseware in the areas of enterprise architecture, application development, component design, and infrastructure deployment. Many of these resources are available on the MSF Web site at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx Microsoft Operations FrameworkMOF offers comprehensive technical guidance for achieving mission-critical production system reliability, availability, and manageability for Microsoft products and technologies. This direction consists of white papers, operational guides, assessment tools, best practices, case studies, and support tools for effective data center management within today’s complex distributed IT environment. Many of these resources are available online at: http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/default.mspx. Executive SummaryDelivering cost-effective, consistent, and reliable IT services is becoming increasingly business critical. Even with rapid technology advancements, many business customers feel that IT is failing them, and they are struggling for a way to address their concerns. Their questions reflect their frustration.
Businesses and IT departments must understand the effect they have on one another. Their respective demands and expectations must be defined and agreed on. The most effective way of managing this is through the Service Level Management process. Service Level Management is a defined process that enables the IT department to deliver exactly what is expected of it and to ensure that these services are recognized as beneficial to the business. IT can facilitate effective cost management of the services, focus on the full range of services available, monitor the service components, and ensure that the service is delivered through monitoring, reporting, and developing knowledge of the services that are offered. 2 - Service Level Management Process and ActivitiesThis chapter provides an overview of Service Level Management (SLM), including the six major processes of Service Level Management: setup activities, service catalog, service level agreements, service level monitoring, service level reporting, and service level agreement review. OverviewService Level Management aligns business needs with the delivery of IT services. It provides the interface with the business that allows the other SMFs to deliver IT solutions that are in line with the requirements of the business and at an acceptable cost. The goal of Service Level Management is to successfully deliver, maintain, and improve IT services. Service Level Management aims to align and manage IT services through a process of definition, agreement, operation measurement, and review. The scope of Service Level Management includes defining the IT services for the organization and establishing service level agreements (SLAs) for them. Fulfilling SLAs is assured by using underpinning contracts (UCs) and operating level agreements (OLAs) for internal or external delivery of the services. Introducing Service Level Management into a business will not give an immediate improvement in the levels of service delivered. It is a long-term commitment. Initially, the service is likely to change very little; but over time, it will improve as targets are met and then exceeded. This document describes the framework to initiate, develop, review, and improve Service Level Management within the organization. If an organization wants to implement Service Level Management, it must first assess what services IT provides to the organization’s customers and determine what existing service contracts are currently in place for these services. This assessment can make the IT service department aware, often for the first time, of the full range of services it is expected to deliver. With the information gained through this exercise, the organization can then develop and implement the full benefits of the Service Level Management process. Service Level Management requires that the IT organization fully understand the services it offers. Implementing Service Level Management follows these steps:
This SLA is developed in line with the requirements and priorities of the services documented in the service catalog, the requirements specified under negotiation of the SLAs, the monitoring of the service against the agreement criteria, and the reporting and reviewing of this information to highlight and remove failures in the levels of performance of the service. Figure 1 displays the six major processes in the Service Level Management function.  Figure 1: Service level management processes The major processes shown in Figure 1 are discussed briefly in this chapter and are then described in detail throughout the remainder of this document. Figure 1 illustrates the linear process for Service Level Management. There is also, however, a cyclical approach used throughout this document that can be applied to each process in turn. This cyclical process has been considered at each stage and can be used to add value in the implementation of the elements of Service Level Management. Figure 2 illustrates this cyclical approach.  Figure 2: Service level management cyclical approach Getting StartedChapter 3, "Getting Started," although not strictly focused on a specific process, offers assistance and guidelines for introducing and implementing the range of SLM processes within an organization. Setup ActivitiesSetup activities are a series of appraisal steps that are carried out at the beginning of a Service Level Management project. These preliminary steps help the business determine if there is a need for Service Level Management and if it has the resources to implement it. As part of this process, the IT department establishes a baseline for the business by taking a snapshot of the existing services and management activities. The final step is to analyze the information collected in the previous steps and use the results to plan the implementation of Service Level Management for maximum benefit to the business. Service CatalogA service catalog, written in business—rather than technical—language, is a definitive guide to the services available to the business. It provides end-to-end descriptions of the service components used to deliver the services and the IT functionality used by the business. This information is then used to create and define SLAs within each area, as SLAs are developed according to the priority and business requirements of the service. Service Level AgreementsSLAs are an essential, beneficial, and often the most visible part of the Service Level Management SMF. The SLAs are a mutually agreed–on and negotiated offering for both the IT department and the business. Service Level MonitoringServices are monitored and measured according to the agreed-on SLA criteria in order to ensure compliance with the SLAs. Service level monitoring entails continual measurement of mutually agreed–on service-level thresholds and the initiation of corrective actions if the thresholds are breached. Service Level ReportingService level reports, used by both the business and the IT department, contain the monitoring data used to measure performance against objectives. Service Level Agreement ReviewThe service level agreement is formalized in a review procedure: the service level agreement review (SLA Review). The SLA Review is a two-way communication between the IT department and the organization. It ensures that the services are being delivered efficiently and are optimized to meet the organization's requirements. Key Definitions
3 - Getting StartedThis chapter discusses the reasons for implementing Service Level Management, how to start its implementation, and the implementation cycle. Why Implement Service Level ManagementWhy are so many customers unhappy with the quality and cost of IT service delivery? Are things really so bad, or are we seeing a symptom of poor communication between IT service providers and their customers? You can use Service Level Management to improve communication. This includes using appropriate SLAs supported by a service catalog that shows customers the full range of options available to them. The principles outlined here produce a number of measurable benefits, including:
The main goal of Service Level Management is to improve the services available to the business in the long term and to resolve service provision issues that currently exist. Among the many benefits to the IT department, in addition to the improvement of service, is an increased knowledge of business expectations and improved cost management. Service Level Management allows the IT department to meet business expectations and opens a dialog to confirm these expectations. For example, an IT department may want to deliver a service at a 100 percent, 99.999 percent, or even 70 percent availability, but it may not be able to explain how it arrived at this number. Unless this expectation is documented and agreed on early in the Service Level Management process, the IT department might focus on a non-business critical service—for example, developing staff, investing in hardware, software, and other costly endeavors—with little real benefit to the business. How to StartService Level Management guides the rest of the operational frameworks processes and aligns them to the requirements and expectations of the business. When IT understands the organization's expectations, it can focus on meeting them. Establishing good communications between the IT department and the business representatives leads to a better understanding of the needs, abilities, resources, and costs, and it allows IT and business representatives to work together to deliver solutions. Implementing Service Level Management should follow a cycle of defining, confirming, agreeing, monitoring, reporting, and reviewing. Consider the following processes when getting started:
Pilot AreaMany organizations begin by implementing Service Level Management initially in one small- to medium-sized department, documenting the available services, creating a service catalog, and introducing SLAs. Select a specific department to start with, such as a corporate finance department; or choose a business service, such as an order system. Alternatively, select a part of the business that in the past has had a poorly managed service that would see an immediate benefit from the introduction of Service Level Management. In any case, the number of users involved in the pilot area should be manageable, and there should be no degradation of service when introducing Service Level Management. The purpose of the pilot is to define, manage, monitor, and report on only the selected service. If the pilot succeeds, it can be applied to other services within the organization. Explain the benefits of Service Level Management to the management and staff of the pilot area. Give them time to buy in and contribute to the pilot by means of discovery workshops, feedback and review sessions, and participation in the setup stages. This will acquaint them with services they have and what is important to them. It will help to set the scene for Service Level Management for the rest of the organization. Solicit volunteer staff from the IT department, if required, at the outset of Service Level Management to assist with the feedback and development of the Service Level Management process in the pilot area. A simple baseline of existing contracts and services should be completed within the chosen pilot area, a review of service desk calls should be carried out, and workshops conducted to ascertain services delivered, consumed, and required. A service catalog should be created for these services and the effects and priorities confirmed for each service. For example, for a corporate finance department, the services and systems and their relative priorities should be documented, their cost should be justified, and beneficial SLAs should be created against services in order to add value. Service CatalogOnce defined, the pilot area should be surveyed with interviews, workshops, and other discovery exercises (such as incident and change request reports) to learn what services are being consumed. Record only relevant information related to each service. This record of services is the service catalog. Information that will be valuable may include:
The information recorded in the service catalog can then be used as a reference in the implementation of the other processes for Service Level Management. This record is essential to the other processes because it documents the services that will be managed. Service Level AgreementsTo create SLAs, start simply by using the information in the service catalog and build to more complex agreements once the simple processes have been validated. Begin with what can be measured, and deliver reports for these agreements. It is important to establish the importance of the SLA measurements and the time and costs that may be associated with producing the measurement report. Service Level ObjectivesWhen setting service level objectives, measure what the business is asking for. Often this can include process measurements—for example, rating customer satisfaction, returning phone calls, and response to queries. There may be ways in which existing technology within the organization can be used to assist in these measurements. For example, call-center technology can run reports that are collated against calls logged at the service desk registering outgoing calls by individuals. There are often complex component chains that result in the delivery of a service. It is possible, however, to agree on a final objective for the service as long as the service delivery of this objective can be measured over the end-to-end chain of components. Figure 3 illustrates a typical component chain. If the service delivery of this objective cannot be measured, it should not be agreed on unless an alternative can be found.  Figure 3: Typical component chain Although it is important to acknowledge the business requirements and endeavor to report on them, it is also essential to ask why these objectives, or this SLA, or this measurement, are important. Answers to questions like these may reveal that the business wants something different or that the business needs can be provided by a different service measurement. If it is difficult for an organization to define its objectives or SLAs, it may need help in identifying and defining what it wants. A record of existing services, contracts, and performance metrics produced by the IT services department can help in this. Operating Level AgreementsWhen implementing Service Level Management for the pilot area selected, it is helpful to prepare the IT department so that the pilot will be successful. To do this, create SLAs that are in line with the objectives by creating operating level agreements (OLAs – the internal service agreement between internal departments) and ensure that IT teams respond when an OLA is breached or when monitoring or reporting indicate problems. Underpinning ContractsContracts with external service providers should be reviewed to ensure that any service levels stipulated in these underpinning contracts (UCs) agree with the SLA requirements. These contracts can be reviewed and brought in line with the new requirements, or the new requirements can be aligned with any existing contracts as long as there is no business requirement regarding changing external contracts. Figure 4 illustrates the relationships between the SLA, the OLA, and underpinning contracts in end-to-end Service Level Management.  Figure 4: Relationships between the SLA, the OLA, and underpinning contracts Monitoring and ReportingUsing the service catalog and SLAs for the department, reports should be designed and scheduled and, if required, real-time monitoring of the SLA criteria should be conducted. The thresholds, alerts, notifications, and actions for real-time monitoring of criteria should be considered and service performance measured against them. The reports produced from historical data and the monitoring function can then be confirmed at the required intervals during a service level review with the representative from the pilot department. Service Level Agreement ReviewThe service level agreement review (SLA Review) provides an opportunity to review performance against SLA objectives and, more importantly, to gather perceptions and opinions from business representatives on any perceived change in service during the period of the SLA pilot. If any service levels were perceived to have been breached but have not been highlighted by the service review or reports, this would indicate that there might be issues with the criteria of the SLA and objectives. Work with the business representatives to identify any issues from the previous period and any current issues that may need to be addressed before the next review. These issues might include providing additional resources to support new services or service levels if these resources were not considered at the outset of the agreement period. If any issues arise from the SLA Review or during informal discussion, review the SLAs and update them in line with the change management process. On a regular basis, review the reporting requirements of the SLA and eliminate any reports that are no longer relevant. Service Level Management reports and reviews should be adaptable and reflect business needs. Ensure that any changes are added to the internal service catalog, agreements, and reporting and review processes. Keeping these records up-to-date adds value to the Service Level Management process. Getting Started Final ThoughtsThis "Getting Started" chapter has briefly described the full cycle of implementing Service Level Management: defining, confirming, agreeing, monitoring, reporting, and reviewing. As long as the initial pilot has not uncovered any significant issues, the next stage is to confirm rollout to the rest of the organization in line with release and rollout planning principals within Microsoft operations. Keep the Service Level Management process simple and at the appropriate level. Do not assume that, because it works in a small area, it will necessarily work in an expanded area. The expanded area might require an unmanageable (and often unnecessary) number of SLAs for a vast number of services. Not all services will need a specific SLA; most can be grouped under a corporate-level SLA. Service Level Management is equally beneficial to the business and to the IT department. It should be:
Summary of Getting StartedThe following list summarizes the important points discussed in this chapter.
4 - Setup Activities for Service Level ManagementThis chapter describes how to assess the need for Service Level Management, determine the required resources, and analyze the metrics for a baseline. There is a series of recommended setup activities to carry out when introducing Service Level Management. These activities are outlined in Figure 5.  Figure 5: Service level management setup activities Assess the Need for Service Level ManagementTo assess the need for Service Level Management:
Existing and Future FunctionsWhen introducing Service Level Management, review any Service Level Management functions that may currently exist and then determine what Service Level Management functions will be needed in the future. Most organizations will have some level of reporting on IT services that can be used for this purpose. For example, the organization might keep a record of calls received by the service desk or calls made to a third-party provider. To implement Service Level Management, it is necessary to judge the relevance of the current measurements of IT services and to assess the requirements and measurements for future Service Level Management within the organization. Buy-InService Level Management is most effective when IT and the business work together to achieve the objectives of the organization. Such a partnership can be established by conducting a buy-in exercise during the early stages of the Service Level Management implementation. Buy-in, in this instance, refers to joint workshops in which representatives of both the business and IT define the service catalog, develop the SLAs, and participate in the service level agreement reviews. Service Level Management is one of the few areas of service management that depends on input from the business as much as it does on the IT department's functionality. Effective Service Level Management works to the advantage of both IT and the business and benefits the other underpinning MOF SMFs as well. SponsorsAppoint a business sponsor who sits at the appropriate level within the business and who can give the IT department the authority to decline any unrealistic demands from the business, unless the cost of those demands can be justified. A sponsor must encourage buy-in among business and IT managers, ensure that they understand the potential benefits and long-term effects of service improvement through Service Level Management, and ensure that key people contribute in a positive way to the Service Level Management process. Key ContactsKey business contacts can help develop knowledge of the IT services available and the priority and effect of these services. It is essential that relationships be built with key personnel so that they can help to set up service catalogs and SLAs. In addition, when this relationship is established and Service Level Management is mature, these contacts can be used to review services outside of the SLA Review. They can act as contacts in case of a potential breach of the SLA, or if escalation is needed, or for advice on changes to be introduced to the service. Assess the Required ResourcesIn many organizations, members of the Support Role Cluster carry out most of the responsibilities for administering Service Level Management. For example, reporting and metrics on support activities is a team role responsibility that may be carried out by the service desk. The role clusters do not imply an organization chart or set of job titles. Regardless of who carries out the roles, there are functions that require different resources be assigned to them depending on the size of the organization and the scale of Service Level Management within it. Further information on the MOF Team Model and role clusters is available at www.microsoft.com/mof. The size of the organization and the complexity of the services provided by IT may mean that its functions require a specific investment of resources—for example, support costs, head count, and technology. The cost of this investment should always be justified to ensure that the investment is reasonable. In other organizations, the roles are distributed among different groups, including IT, the business organization, and sometimes external resources. The responsibilities of the Service Level Management function are documented in more detail in the "Roles and Responsibilities" chapter later in this guide. It is important to note, however, that SLA monitoring will affect all of the other roles and SMFs if an SLA objective is included within their areas. In addition to personnel resources, other resources will be required for delivering the service catalog and SLAs. The catalog, as well as the monitoring and reporting of the SLAs, may require technology resources. It is during this stage of setup that the use of specific technologies and organizational standards need to be addressed. For example, it may be suitable to use e-mail to alert a breach of SLA, or to use pagers and SMS alerts to mobile telephones. Establish an SLM BaselineA baseline is a line drawn in time, taking a “snapshot” of the situation. In this instance, it is a picture of the Service Level Management within the organization. A baseline provides a picture of the services being delivered at that specific time and provides a plan for achieving future goals in Service Level Management. Optimizing IT performance requires not only a clear vision of the objective, but also of the current baseline from which the process will begin. Baseline the Services AvailableMeasure the services currently available within the organization as a baseline for initiating Service Level Management. By baselining the existing services before creating a service catalog, measurable criteria for improving and maintaining the service can be formulated. New services or changes discovered by change management should be included in the procedure for updating and maintaining the service catalog from this baseline point onward. Getting Information on Available Services
Baseline Existing Service Level AgreementsLook for existing SLAs. For example, there may be SLAs with other providers. There may already be contracts that, although not SLAs by name, may adequately deliver the requirements of the business. It is essential that Service Level Management benefit the business and IT. There should be no unnecessary redevelopment of contracts that already meet the needs of the business. Contracts that do not meet the needs of the business—for example, contracts with legacy vendors—should be reviewed in case an SLA is assigned to the service in question. Analyze the Metrics for a BaselineWhen considering the implementation of Service Level Management, the metrics may come from many sources. For example, we recommend reviewing existing contracts for baselining the existing Service Level Management function. The metrics should be collated and presented in a readable format for comparison against the completed service catalog. For example, contracts can be consolidated into a contracts database and may be under change control. Apply change control to all of the elements of data gathering completed during the setup activities. This ensures that the Service Level Management processes will detect any changing services and minimizes the possibility of errors or inconsistencies due to changes. The purpose of this analysis is to find any gaps between the existing and the required functionality of Service Level Management and to use this information to plan the implementation. Carefully examine your current Service Level Management status and consider your goals when planning and implementing the rest of the stages outlined in this guide. It is important that Service Level Management fit the organization. The baseline provides the information needed to help decide where maximum value can be added. Note: Once gathered, the baseline information provides a starting point for the Service Level Management project. From this point, additions, changes, and retirements to services should be discovered by the change management and new Service Level Management processes. Summary of Setup ActivitiesThe following list summarizes the important points discussed in this chapter.
5 - Service CatalogThis chapter defines the service catalog and describes how to make it an official record and how to maintain this record. The service catalog is an essential record that will ensure the success of Service Level Management. The modern IT environment contains multiple components, all working together to deliver IT services to an organization. Each day new solutions are developed and implemented, and each day old solutions become outmoded and pass from use. Unless there is a record of the services an organization uses, it is impossible to meet the service expectations of that organization. Figure 6 illustrates the process of making and maintaining a service catalog.  Figure 6: The service catalog What Is a Service Catalog?A service catalog is a record of all the services in use within an organization. The record should include:
The information in the service catalog should be manageable and realistic. Too much peripheral information will make it difficult to maintain. A service catalog should contain all of the IT services provided within an organization. SLAs should be established and prioritized to monitor, report, and review those IT services. This does not mean, however, that some services should not be monitored; the requirements of the business can determine what is important in a department. For example, having a financial system in an accounting department should be a high priority and would certainly require an SLA. The same financial system, however, when used only occasionally by a few staff in—for example, a personnel administration department—may be of lower priority. It would therefore be unlikely to be subject to a specific SLA or to come under scrutiny during service level reviews. The financial system in the personnel administration department would still have an expected level of service, but this may not be officially recognized and managed. The service catalog provides many benefits beyond Service Level Management. For example, it allows business impact mapping for the services, aids the change management team in assessing effects of changes on services, adds a business focus to the CMDB, improves communications between IT and the business, and improves knowledge-sharing between stakeholders in business areas and staffing issues. Define a Service CatalogA service is defined by the business organization's perception. For example, e-mail may be a service and printing may be a service, regardless of the number of service components (CIs) required to deliver the service to the end user. Where to Discover What Services IT Is Delivering to the Business
Formalize a Service CatalogTo formalize a service catalog is to create an officially recognized record. Making the service catalog an official record within the organization places it under change control. This is important since the record is valuable only if it is maintained and accurate. There are many ways to formalize a service catalog. When determining which method is most suitable for use, consider how you want to view, report against, and use the service catalog. A service catalog can be stored as part of the CMDB either as one component (the service catalog) or as its services. Microsoft applications, such as Microsoft Excel or Microsoft Access, can be used to record the services and such details as the components, effects, priorities, and SLAs and SLOs. If the tool selected allows the service catalog to be part of the CMDB, then this can add value by integrating the information in the service catalog with the configuration item (CI) in the CMDB. This can then be used to add value to the Change Management SMF, Incident Management SMF, and all other SMFs using the CMDB. Note: Most of the IT department, as well as key individuals, should have easy access to the service catalog. This ensures that everyone involved in delivering the service—such as supporting, operating, or developing solutions—can view the service information. This can be achieved in various ways—for example, by putting the catalog on an intranet or extranet site. In this case, unauthorized personnel should be able to access the catalog on a view-only basis. This will ensure the catalog's integrity of information. Maintain a Service CatalogWhatever the storage mechanism for the service catalog, the change controls on the records must be strictly monitored. Allowing read-only access to the majority of IT should ensure this. As with the CMDB, a service catalog's records are only as useful as their data. When a change to a service or the development of a new service is made, however, the service catalog should be updated to reflect it. This may require some buy-in from IT and the IT development function; but once these groups recognize the value of maintaining the service catalog and the importance of the SLA to the operations of service provision, they will most likely cooperate. Controlling service catalog entries may be the responsibility of the service level manager, an administrator, or someone defined by the Support Role Cluster. This ensures that changes to the services are noted and signed off. In this way, changes to the service catalog are subsequently reflected in the SLAs, OLAs, reports, and reviews. Note: It is important that the service catalog track its version and status. Recording changes to a service record will make it less likely that out-of-date versions of the service catalog will be used. Change a ServiceWhen changing an existing service or adding a new service, the requirements for the service catalog should be specified during the development stage of the change as part of the development deliverables. The expected priority and effect of the new service to the business organization should also be added. This information can include the specification of SLAs at the design stage. This can often be helpful because the solution is designed and built according to the SLA rather than the SLA being tailored to the solution once it is implemented, which can be costly and require further development. A change to a service should take into account the range of service information recorded in the service catalog. For example, it may appear that although a service may not be changed, a service component used in its delivery may be changed. Therefore, a full impact analysis must be carried out as part of the change management and approval process. Then it must be fed back into the service catalog to be recorded. For example, end users might use a service, such as Microsoft Office, remotely at their client computer. The service, however, has not had a change raised on it. In addition, an element of the delivery mechanism, such as the bandwidth of the network, may be changed. This may or may not affect the performance of the service, but the details of the change to the service component should be recorded in the service catalog as part of the change management process. Using different version or status controls for a service in the catalog can be useful here. For example, services included in the catalog can be defined by status—such as In Development, Test, Pilot, Production, Retired, and Training—depending on the needs of the business and IT organization. Add a ServiceAs new solutions are brought into the production environment, information for the service catalog should be gathered from the business. For example, the following information should be added to the service catalog.
If a pilot is carried out for the release of a new solution, any degradation or impact on service performance would affect the priority and the level may be increased to that of a production service. Any issues in a pilot service would need to be highlighted immediately in line with the release, and pilot acceptance criteria and other issues would have to be resolved quickly. As the new solution is developed, it is often easier to record all of the components used in delivering the service while they are being designed and built according to the requirements listed in the service specification. It is often more difficult, however, to record all of the components for an existing service. For example, if a new service is being designed and specified, the components to be used in the delivery are all apparent at this stage. If a service is in use, however, some of the components used in the delivery of the service may not be as easily identified. There may be problems in determining the full range of components used in the delivery chain. It is a good practice to involve the service catalog requirements as early as possible in the development of a new service. This can save time and effort later on if the service catalog is maintained correctly. Version and status controls are helpful in adding a service because they can be used for test, pilot, and production services. Retire a ServiceAs workshops, reviews, and informal reports highlight issues and legacy services that may no longer be in use, it may become evident that these services must be phased out. An organization might be paying licensing costs on legacy systems it no longer uses, while an existing new system could be used instead. Highlighting poor cost control in these instances indicates the financial benefits for the IT department of keeping a record of services. If a service exists within the service catalog but is no longer used—either due to a change in IT or in working practice, or as a result of a larger scale transition to an alternative service—the project must ensure that the information from the service is still accessible or is transferred as part of the migration or replacement project. Then the record in the service catalog can be changed to a Retired status. Review a ServiceThe service catalog is flexible. The service, for example, may no longer have a high priority or be used by as many staff as the record indicates. Conversely, the service might have gained a higher priority in the organization. For example, as recently as three years ago, many organizations regularly referred to e-mail as a non business–critical system. Now many organizations could not function properly without it, and their customers would be exposed to a service failure if their e-mail messages were returned undelivered. The service catalog review process can link into the service level review and be a part of it, or it can use the reports and data produced for the service level review to prompt the review of the service catalog. In addition to the informal review of the service catalog, we recommend that a scheduled review be conducted. The frequency of this review depends on the number of services available and the overhead associated with them. One approach is to review by priority of service or department. The stages of a review are:
Inform all interested parties when a review causes changes to be made in the service catalog. The service catalog can add further value by including records of the key consumers and users of the service and their preferred methods of communication. This information can then be used with other technologies. For example, you can use the intranet to report that the service catalog has been updated or that changes have been signed off by the relevant departments. As with all processes and procedures, a review is often beneficial to other areas of IT and the organization. For example, change management and incident management may find new information on service effects and priorities useful in ensuring that their own practices are fully aligned to the organization. This should be a two-way communication: The incident and change management groups should share their information with the service catalog review using, for example, a share point or intranet. Note: You can review a service as part of a virtual team. This can benefit from a buy-in and have its own staff in a larger organization. This relates to the administration of the CMDB but is the service view of the components. The CMDB can be used for Service Level Management administration in the following manner: The service catalog can be stored as part of the CMDB—with the services recorded as configuration items (CIs) and the service details, SLAs, service level reporting requirements, and service components required to deliver the service recorded within the CMDB as a relationship. Summary of the Service CatalogThe following list summarizes the important points discussed in this chapter.
6 - Service Level AgreementsThis chapter describes the different types of service level agreements (SLAs). It also provides a brief introduction to negotiating, documenting, and revising SLAs. SLAs are useful in ensuring that the services delivered meet the expectations of the business, the required performance targets, and the required cost for delivery of the services. An effective SLA reflects the communication between the business customer and IT. It includes the organization's future plans and their uncertainties, and it lists the demands on IT that will have to be met in order to fulfill these expectations. Then both IT and the business community can be clear on the organization's goals and how to achieve them. The flow chart in Figure 7 illustrates how this phased approach fits into the linear SLA process for Service Level Management.  Figure 7: Service level agreement processes The following diagram (Figure 8) was used in the "Overview" section of Chapter 2. It is, however, directly applicable to the SLA process. Figure 8 illustrates the phases that IT should go through in implementing effective SLAs. This cycle does not stop after the SLAs are implemented and subject to the service level review. It starts over following the review in order to ensure that the defined SLAs are still applicable to the organization's expectations.  Figure 8: Service level agreements cyclical approach What Are Service Level Agreements?SLAs are formal, typically signed, agreements between IT and the organization to document the expectations and requirements of a service delivered to the organization from the IT service provider. There are many different types of SLAs:
When considering how to build the SLA structure, it is useful to consider the service catalog definitions of the services in question and the business areas that they pertain to, the practicality of the reporting and monitoring functions, the involvement and manageability of the review meetings, and any informal communication. All of these factors can contribute to the structure that is put into place. For example, if an organization uses a service across several departments, but the culture within that organization treats different areas as separate functions, it may be worth creating an SLA that delivers the minimum requirements of the service across the entire business. This can be considered as a generic SLA, but departments may indicate that they want individually specified response times, resolution times, or review meetings specifically for their own areas. These are exceptions to the generic service availability. Because such specific SLA objectives may be added to a department's agreements, the organization-wide SLA becomes measurable, and the specifics can be reported when required. Defining Types of Service Level AgreementsA successful SLA may be the result of many hours of negotiation, but the final report may be only a single-page document to be discussed at the SLA Review. An SLA will qualify as successful if it delivers what was requested, if it offers a simple representation of the complexity of the service and component architecture, if it can demonstrate the measures on performance, and if it is delivered in a suitable format. As long as they meet their objectives, SLAs do not need to be long, complex, multipage documents. Although there are different types of SLAs, the basic process for their creation and content is fundamentally the same. The differences arise from the groups for which the agreement is made. A group's needs affect the requirements of the document and the actions taken should the SLA not be met. The SLAs discussed in this document are:
Internal Service Level AgreementsAn internal SLA is most common between an IT department and another business department—for example, sales and marketing or human resources. However, an internal SLA can also exist between other, non-IT departments. For example, scanning, mail, customer service, and billing departments may all have SLAs with other business areas to which they deliver their services. Although internal SLAs between two departments within one organization rarely have legal consequences, the internal SLA describes the relationship, the expectations, and the timescales for the delivery of the service. It is binding in that it represents an agreement between the two parties. Every endeavor should be made to meet the levels of services documented and signed off within it. The internal parties are accountable for what they do and do not achieve as outlined in the SLA. There may be repercussions within the organization when an agreed-upon service is not fulfilled, even though the document is not a legal contract. The status of IT may suffer, for example, if there are issues on chargeable services or if the costs of providing an agreed-upon service cannot be justified. Internal SLAs require administration of their operation, reporting review, and optimizing processes. These functions can be carried out by various role clusters as deemed suitable within the organization, as responsibilities for this administration may be defined by SLO. System administration objectives, for example, may be monitored and reported on by the system administration function, and request for change objectives may be reported on and monitored by the change manager. The collation of all this data for the SLAs may be the responsibility of a service level administrator or the Support Role Cluster. In addition to interval-based administration, there will also be administration as a result of changes. A change to a service component, a service, or a line of business can result in a change to the SLA itself. A change-control process must be applied to all SLA documents, and it can be useful to use version control for this. If it is possible within the organization to store the SLAs as CIs within the CMDB, then the SLAs will be part of the change control and will affect analysis processes within that system. If SLAs are stored in another format, ensure that there is a limited authority for changing them in order to guarantee their integrity. Make sure that they can be accessed on a read-only basis by any interested parties, in both IT and the business. External Service Level AgreementsExternal SLAs are more formal, legally binding contracts than internal SLAs. External SLAs may be more structured than internal SLAs because they usually include costs, bonuses, and sometimes penalty clauses. The service is still agreed on at a specified cost and deliverables—for example, availability and security are often included in the cost. The variation and termination of this SLA differs from an internal SLA in that it is usually less flexible and involves a stated, rather than an undisclosed, cost every time service criteria are changed. Increased hours of support from an outsourced service desk, for example, will incur charges for increased staff and availability of services. Internally, these costs would still be present, and in some instances may be charged back to the business. However, they are likely to be justified by the increase in business revenue provided by the longer hours of service. Any legal implications in the SLA contract—including termination, re-tender, bonuses, penalties, and costs—should be considered before the SLA is agreed on. If an external SLA needs to be legally binding, it should be checked by a legally qualified professional. This may be an internal legal department or an external legal counsel. The legalities will differ in different situations, organizations, and countries, but a contractual SLA should not be entered into without confirmation of the legal implications in the SLA contract. This includes descriptions of termination, bonuses, penalties, and costs. External companies that the organization may have an SLA with include any outsourcing arrangements, telephone companies, hardware suppliers, lease companies, software suppliers, service desks, data security firms, backup companies, and business continuity firms. Consider entering into an SLA with any external contract you have with a supplier. Even if the requirements are not technical, they indicate the level of service you expect from the contract. Such an SLA would put the business in a much stronger position in managing the external relationship. Operating Level AgreementsAn operating level agreement (OLA) is an internal SLA to meet operational requirements and is invisible to the service's consumer. An OLA is rarely legally binding but does assist the IT organization in meeting internal requirements. For the OLA to be successful, IT groups must be aware of and aligned with the organization's goals. Meeting performance measures or resolution timings within an IT department, for example, enables the end-to-end OLA to be achieved for the organization. This may result in maximum availability or flawless data security, for example, for the customer. Table 1 lists the differences between SLAs and OLAs. Table 1 SLAs and OLAs
SLA and OLA templates are available in the appendices in this guide. Note: OLAs used within departments may need some administration in documentation reporting and applying a change process in line with any changes affecting the OLA. For example, a technical support unit may offer a resolution time of six hours on a certain component. If a change should affect the configuration of this component, however, the OLA may require review in line with the change and its potential effects, positive or negative, on the resolution agreement in the OLA. The change process should ensure that the OLA changes are applied to the SLA process as a related activity. Underpinning Contracts Underpinning contracts may undermine SLAs if the service level requirements are not synchronized with each other. For example, an eight-hour response SLA for a telephony fault would mean the contracts in place with an external telephony supplier would need to be less than the eight hours for the SLA requirements to be achieved in case the external party needs to be called in. There may be a cost associated with ensuring that the underpinning contract meets the demands of the business. There may be an alternative method, but it is still likely to incur a cost, which should also be justified. For example, if an organization has a vendor who supplied a complex and expensive disk array that experiences a fault, the vendor may have a 15-hour SLA for finding and delivering a replacement from anywhere in the world. If the business cannot manage without the service delivered by this component for 15 hours, then it may manage this continuity issue by having a hot-swap component stored on site. This incurs a cost to the business for the hot-swap component, but this may be justified if the service delivered generates enough income for the organization. A new contract can be negotiated in line with an SLA that is being agreed on with the business organization. However, this may incur a cost and should be carefully considered and justified against the requirements of the SLA before being financially signed off. The existing underpinning contracts and any new contracts taken out with suppliers need to align themselves to the end deliverable. Figure 9 illustrates how the SLAs, OLAs, and underpinning contracts support the expectations of the customer and the organization. |
