|
|
|
|
|
Establishing SLM Confusion's still supreme As cited by Sturm, Morris and Jander in Foundations of Service Level Management, an April 1999 Forrester Research report found that many organizations use SLAs, but still don't understand what can be done with a good SLA. The SLAs these businesses used:
Overall, current research indicates that many organizations today are using SLAs that are too complex to understand or implement, burdened with unrealistic objectives and lacking in balance between the interests of all stakeholders in the agreements.2 To add to the confusion, different industry analysts have different views about what an SLA should actually cover. The Giga Group, for example, advises that a good SLA should address response time, application availability and the cost of delivering service, while Hurwitz Group analysts believe that SLAs should address application availability and recovery and end-user response time. Not to be forgotten are Forrester Research, which insists that SLAs must emphasize business application availability, performance planning and administrative support, and the Meta Group, which believes that managing service levels should be addressed with Service Value Agreements, a dynamic model centered around business-focused process management.3 It's obvious that industry analysts cannot agree on which components of service level management an SLA should address, and efforts toward setting consistent standards for SLM continue to evolve. As a result, businesses have generally taken the "back to basics" approach to managing service levels. Mostly, they begin with some kind of written SLA, then progress to service level monitoring and reporting. However, not many businesses ever progress to what may be the most powerful aspects of service-level management: continuously improving customer satisfaction or achieved service levels. Evolving SLM According to data from Lucent Technologies NetworkCare Professional Services (NPS) surveys in 1998, 1999 and 2000, there is no lack of awareness in the marketplace of the importance of service-level management. A large percentage of respondents each year indicated that improving their organizations' SLM capabilities was very important. However, organizational issues like processes were consistently cited as the greatest barrier to implementing SLM4 In a perfect world, IT departments would actively seek out ways to implement SLM both internally, for their own continual improvement, and externally, as a way to satisfy customers. However, the impetus to manage service levels usually starts, not from proactivity, but from reactivity. Often, it is only after customers complain and IT is in a continuous and wasteful "firefighting" mode that a company tries to put in place the processes and procedures to head off problems before they happen. First, the department usually reviews its current service-management practices with an eye toward establishing a baseline for the quality of these services. At this point, it's essential for that department to first take a hard look at how it reacts to problems, and then create more formal processes and procedures to deal with them. Practices and processes to include on that important list are:
Establishing these initial procedures and internal processes helps ensure consistency in how IT delivers service to its customers. And by closely examining current problems with service, IT can decide where improvement needs to come first. Once IT has done this and has established baselines, it should set goals for improving customer service. These goals should be initially simple, easy to understand and measurable. Also, IT should develop incentives like performance bonuses and reward its staff responsible for achieving those goals. Establishing SLM for the lines of business Usually, the first agreements arise from specific problems that a company's line of business has had with IT service in the past. Maybe IT has tried to correct those problems - perhaps unsuccessfully or in a less-than-organized fashion. That being the case, IT will need to collect information on service availability, degradation, notification procedures and resolution. This information can be used to set a service baseline from which it can work to improve service quality and user satisfaction. Once the department uses this process to address one line of business, one type of service and one application, it can use the same process to address service levels to other lines of business for other services and applications. At this stage of developing SLAs, the agreements themselves will probably be informal, putting in place ad hoc processes and procedures to measure service levels. IT will most likely focus on its own best interests by responding to lines of business that are more insistent about stating their service requirements. At the next stage, the IT department will prioritize the lines of business, applications and services it delivers from a business-value perspective. More organizations moving toward SLM The 1999 Lucent NPs (formerly INS) survey indicated that while only half of the respondents said they had SLAs, 87 percent stated that they had some form of service-level management in place. In 2000, 85 percent stated they had some form of SLM in place, while 56 percent said they have SLAs in place, up only slightly from 49 percent in 1999. This shows that a significant number of organizations are in the early stages of managing service levels, in which agreements are informal and ad hoc. Organizations were clearly moving toward SLAs as indicated in the 1999 survey, which noted that 60 percent of respondents planned to implement either initial or additional SLAs.5 The 2000 Lucent NPs survey also showed that primary objectives for developing SLAs between IT and the lines of business centered around themes such as:
When trying to improve service levels, whether for internal or external organizations, "intuiting" or "guessing" about actual current levels only opens up the possibility of beginning the process in error. The IT department must measure service levels to understand the quality of services it provides to the lines of business as a first step in negotiating SLAs. Yet as stated in previous articles, assessing only system components provides a very narrow view of SLM and neglects the bottom line of providing true end-user satisfaction. In the 2000 Lucent NPs survey, as in 1999, it was obvious that most respondents still viewed service-level management from not an end-user, but a technology, perspective. Respondents indicated that the most important part of SLM was network availability, followed by application availability and then network performance and customer satisfaction. Managing services provided by external suppliers Networking services provided by telecommunications companies or Internet services provided by Internet services providers are the two services that IT departments most often outsource. As a result, it is increasingly important for IT departments to establish SLAs with those service providers. SLAs with external providers have different objectives from those used in internal SLAs. According to the 2000 Lucent NPs survey, the top three objectives of external SLAs are:
SLA structure At the time of that particular survey, the top elements included in internal SLAs, or those elements that respondents intended to add within six months, were:
SLAs usually begin with
Any specific performance objectives follow, and they usually focus on availability measures, response times and how much time is acceptable to resolve problems. Very few internal SLAs specify the costs of the services or provide for allocating costs. And few state penalties for the IT department if it does not meet service level objectives. Reporting Most service-level reports detail availability and performance statistics at the component level, and are difficult for anyone not in IT to interpret. Some reports also indicate how many problems were reported by IT's users, what types of problems the users reported and how severe the problems were as well as the how much time it took the IT department to respond to, and fix, them. These reports can help the IT department demonstrate its responsiveness to the lines of business and can illustrate whether service problems are related to systematic, underlying technology or staffing issues. The kinds of reports that might really be useful -- service-level information by application, location, and by user -- must be produced manually unless IT is employing a sophisticated set of tools and a rigorous methodology. Better tools mean better SLM Most service-level reports detail availability and performance statistics at the component level, and are difficult for anyone not in IT to interpret. Some reports also indicate how many problems were reported by It's users, what types of problems the users reported and how severe the problems were as well as the how much time it took the IT department to respond to, and fix, them. These reports can help the IT department demonstrate its responsiveness to the lines of business and can illustrate whether service problems are related to systematic, underlying technology or staffing issues. The kinds of reports that might really be useful -- service-level information by application, location, and by user -- must be produced manually unless IT is employing a sophisticated set of tools and a rigorous methodology. 1Sturm, Rick, Morris, Wayne, and Jander, Mary. Foundations of Service Level Management. Indianapolis, Ind.:SAMS Publishing, 2000. P. 88. 2Ibid, P. 88-89. 3Ibid., p. 89. 4Blum, Rick, and Kaplan, Jeffrey. Lucent Technologies NetworkCareSM Professional Services 1999 and 2000 Survey Results - Service Level Management, 1999 and 2000. 5Sturm, Rick, Morris, Wayne, and Jander, Mary. Foundations of Service Level Management. Indianapolis, Ind.:SAMS Publishing, 2000. P. 91. |
||
| Copyright (c) 2000-2003, nextslm.org. All Rights Reserved. Legal Statement. | ||
