Service Level Management

---

Traditionally, IT departments were funded as a corporate overhead ”that is, paid for out of a central budget that was not particularly relevant to any specific department. Service level agreements came into existence when IT departments started to charge for the services being provided, normally via the chargeback method (described in Chapter 2, "The IT Budget"). So, with each department having to pay for its IT services out of its own budget, it became clear that there would have to be ways of quantifying the service being provided and attaching a reasonable cost to the provision of the service. The consumer also needed to know whether the service being provided was worth paying for ”and, if not, how to claim a refund!

The terms service level management and service level agreement have become popular in recent years because of IT departments being challenged about the level of service that they are actually providing. Questions have been asked, such as, "To what extent are the users and the computer applications being supported?", "Is the reliability of the network and computer systems acceptable?", "Are the IT services being provided in accordance with the business objectives and expectations?", and "Is the IT department providing value for money?"

Of course, these questions could not be properly answered because there was no means of determining the level of success or failure. The system manager could argue based on the performance and availability figures, but the client could counter with a documented list of occurrences when he or she was unable to carry out a required job because the network was down or the system was running far too slowly.

Service level management addresses these issues by ensuring that all parties understand what is expected from each. The system manager probably has to hear some unwelcome news in that he hasn't been doing such a great job as previously thought, and the client may well realize that what is being asked for is totally unrealistic . Either way, the objective is a mutual understanding and, most important, an understanding that is written down and agreed to by all parties concerned .

Service level management is all about quality of service and how to measure it. To determine the quality of the service being provided, it is necessary to adopt the view of the customer ”that is, the person or persons making use of the service (the consumer). A dissatisfied customer will not want to use your services again. It is the ultimate test of quality, the opinion of the consumer. This is great most of the time, but in our case, there is nothing substantial with which to make a comparison, no baseline that defines what is acceptable. Consider the following example in which quality can be measured:

A car is for sale at the local showroom. The customer can test-drive the vehicle, read the sales literature, compare it to other similar types of car available from different manufacturers, or read reviews about the car in various motoring magazines and journals. In this case, the service level agreement is the warranty that is taken out when the car is purchased. The customer will be entitled to free repairs if a specified fault occurs within a specified period and will have the use of a courtesy car while any repairs are being carried out. The customer, though, must have the car regularly serviced by an approved technician, and no modifications must be made to the car. If a repair cannot be effected, then the customer will be given a replacement car. This agreement is clearly defined and agreed to by all parties. The expectation is that the car will function without any problems for the entire period of warranty. From the customer's perspective, the fact that completing the repair may mean ordering spare parts from abroad is of no concern or relevance. The customer leaves the car with the dealer and expects to have it returned in full working order.

In the same way, the IT department is providing a service to the customer, but the system manager's responsibility might be only a part of that service. To provide the entire service may involve the hardware support technicians, the network team, development services, database administration and central hosts , to name a few. This is of no interest to the customer, and it shouldn't be. The customer wants something, and the IT department (as a whole) provides it. The customer isn't concerned with all the technical bits of computer wizardry that may be involved in providing the service, nor in the fact that there are several sections within the IT department involved ”this is irrelevant.

It can be seen that there is a difficulty in defining "quality of service." There is nothing to compare it to ”no baseline, no agreed tolerance. The service level agreement (SLA) is created to address this lack of clarity, allowing the service to be monitored and its performance to be measured.

A service level agreement is a contract between a provider and a consumer ”in this case, the provider is the IT department, with the system manager being a major part of it. The consumer could be the accounting or sales department. Often, SLAs between internal organizations within the same company would not form legal contracts, but one with a third-party supplier would. The primary reason for their existence is to define, in measurable terms, what is being provided and what is expected, and then to be able to determine how well (or not) the service is being provided.

Perfection is something that is not achievable. The SLA does not try to achieve 100% perfection , but it does define the level of imperfection that is acceptable. It also defines what is desirable and what is possible. Basically, the customer must make realistic expectations. There is no point in asking for something that cannot be delivered because it would undermine the whole process and make any SLA meaningless. A crucial part of setting up any SLA is that a common understanding is agreed and documented by both provider and consumer.

As part of the SLA process, cost must be borne in mind when trying to improve the service. It is quite likely that with financial expenditure, the quality of service could be improved, maybe significantly, but at what cost? It may completely outweigh the perceived benefit. Even though the cost is not directly related to the quality of the service being provided, it must be considered as a potentially limiting factor.

The next few sections provide insight into some of the issues surrounding service level management and the SLA process. This coverage is not intended to be an exhaustive discussion, but it is enough to appreciate the sort of things that are included. An example is included at the end of the chapter.

Provider or Consumer?

As stated before, the SLA is a contract between a provider and a consumer. The two parties can loosely be defined as follows :

• Provider ”The person or department providing a service for others to use. This may be internal to the company or a third-party supplier.

• Consumer ”The person or department making use of the service that is being provided.

To complicate matters, the system manager can be, and often is, both a provider and a consumer. This creates a special challenge when trying to draw up a service level agreement with him. On one hand, the system manager is providing the computing services to the business, but on the other hand, he must make use of services provided to him ”the network, for example. Here, he is a consumer of a service which may already be the subject of a service level agreement: a telephone company in this case, that supplies the various communications media. This will usually be a third-party supplier and subject to a formal contract with associated penalties for substandard service.

The service level agreement will form a part of the formal contract. The system manager, as both provider and consumer, will have to take this into account when entering into any service level agreement with the business. This is because there is a risk that the provision of the entire service could be jeopardized if this part fails ”indeed it may prompt him to seriously review the dependencies that could affect his ability to deliver the service. The third-party supplier managing the network in this case is an extremely important dependency because a network failure would undoubtedly have a significant effect on the system manager's ability to guarantee a level of service.

Database administrators and developers could be further examples of dependencies that the system manager must take into account. If there are no agreements with either of these areas, he will be unable to specify when either a database problem will be resolved or an application bug will be fixed.

From the consumer perspective, this is irrelevant. The consumer makes use of the IT infrastructure and computer systems so that a task can be carried out. As stated earlier, the fact that several sections or departments may be involved in the provision of that service is of no interest to the consumer. However, as part of the negotiation process, the system manager will have to make clear any dependencies that could affect his ability to deliver the required level of service. The consumer, while not interested in the mechanics, will gain useful knowledge of how the service is provided. Value lies in the fact that the consumer's understanding of the issues is enhanced.

This difference in perspective is one of the main reasons why it is necessary to first arrive at a common understanding. The importance of documenting the understanding is to avoid future ambiguities and potential conflicts due to misinterpretation. This will certainly happen if the agreement is not documented.

What Are Dependencies?

Dependencies in this instance can be defined as anyone , or anything, that the system manager relies on in the provision of the required level of service.

Who Needs an SLA?

Any section or department in a company that is making use of a service provided by another department, such as IT services, needs an SLA so that a measurable, quantifiable, reasonable, and attainable level of service can be agreed on between the interested parties. Without the SLA, there is no evidence of performance. The users could complain that the service is slow, and the system manager could respond by saying that it isn't. Who's right? And how do they prove it? Of course, they can't prove it because there is no baseline to compare it to. With an SLA in place, however, the baseline determines what constitutes an acceptable level of service. If the user complains of a slow service, a comparison can be made against what was agreed on, and the necessary proof can be provided. Note that all of this depends on sufficient meaningful data being available.

The users, or consumers, also need an SLA for another reason. It is probably the only place where the user community is represented with authority. They will help to set the standards for the level of service that they require to do their jobs.

Senior management needs SLAs to ascertain the value of a given service and to measure how well the service is performing against an agreed target. This sort of information is invaluable to management, especially when deciding priorities and budgets . It allows them to see easily the value that, in this case, the IT services are providing to the business as a whole. The SLA describes the service in universally clear language that everyone can understand.

Another reason that senior management would favor the use of SLAs is that they often provide the information needed to determine whether outsourcing is a viable option. Part of the SLA process involves gathering and monitoring collected data. A cost element of providing the service should also be available. This cost element can be compared with external suppliers and hence aid the decision for whether outsourcing is an option.

A good way of collecting the required information is to use a time recording system. In this way, time is booked to various tasks by the people carrying them out. Managers then can produce reports to detail how much time (and, hence, cost) is spent providing a specific service. Figure 3.1 shows an example timesheet that has been completed by a system administrator for a working week. A report would contain, say, monthly figures for the total time spent on a specific task and by all those contributing to it.

Figure 3.1. A method of tracking time, such as a detailed timesheet, is crucial for managers who need to determine the most cost-effective way of meeting requirements.

It can be seen from Figure 3.1 that the system administrator appears to spend his time fairly evenly between the sales and personnel systems. These figures could easily be quantified as a cost if either of them were being considered for outsourcing. Other cost elements to be considered could include these:

• Maintenance and support costs ”These are the system and software support maintenance contracts. If the service were to be outsourced to a third party, this element would definitely be included.

• Development services costs ”This is the amount of time required by development services, for example, to fix bugs or provide enhancements. This element would also be included if outsourcing was being considered.

• Management overhead costs ”This is the necessary overhead that is inherently built into the overall cost of providing the service. This element is often omitted because it is not seen as a direct cost. Note that an element of the management overhead would still exist if the service were to be outsourced, although it would be proportionately reduced.

• Media and consumables ”This element is not normally considered when deciding whether to outsource a service, but it can still be considered as part of the overall cost of providing the service.

• Administrative support costs ”These costs relate to the production, copying, and distribution of reports, as well as the secretarial duties relevant to the provision of the service. Again, this is another element that is frequently overlooked, but it should be included if an accurate cost of providing the entire service is to be calculated.

• Clear definition of responsibility ”An SLA defines exactly who is responsible for providing a service or a part of a service. This aspect becomes more apparent when a service is outsourced, especially if more than one supplier is involved. For example, consider an SLA covering several remote sites as well as a central, primary site. If a restore request is received for a file that is resident on a remote system, the SLA provides sufficient information to determine which section carries out the system administration duties, thus preventing the request from "falling through the gap."

The system manager needs SLAs so that the services that he is providing can be well documented and understood . During negotiations, the level of service that can reasonably be achieved becomes apparent. Unrealistic expectations on behalf of the consumer are also highlighted at this stage, and the system manager can work at getting these reduced to a more reasonable level. This focuses on what can actually be done, something that may not have been addressed before. Previously, a lot of the work may have been "firefighting," sorting out problems as they arise. Here, though, is an opportunity to analyze the service in its entirety and to anticipate the potential problems, pitfalls, or network bottlenecks that could cause concern in the future.

A final reason for the system manager to favor the use of SLAs is that it could provide the necessary justification for further expenditure on improvements. The negotiation process and the monitoring of the performance should raise the profile of problematic areas. Using the SLA results, for example, the system manager could not only specify what is needed to improve the service, but also provide the projected improvement in efficiency and throughput that is likely. He will be able to identify this improvement only if there is something already available to compare it with. This will exist in the agreement, as discussed earlier.

Unrealistic Expectations

Unrealistic expectations usually arise because the consumer is not fully aware of what is actually achievable. The following are a couple of examples:

• 100% availability of the application ”This is impossible to guarantee. Even with significant investment, there is still no guarantee. The best possible availability can be calculated only in conjunction with other SLAs (probably with third-party suppliers). The question of availability may not even be negotiable with the consumers because of agreements already active with third-party organizations.

• Problem calls responded to within 30 minutes ”These calls would be passed on by the help desk system, which is usually also subjected to an SLA. The system manager cannot possibly respond before the call has been passed to his department (by the help desk). The compromise would be to agree on a response time based on the help desk SLA, coupled with a priority mechanism based on the severity of the situation. The priority attached to various types of problems is defined in the scope and terms of the agreement (see later in this chapter in the section "Creating an SLA").

The Benefit

There are three main beneficiaries of a service level agreement:

• The system manager ”With an SLA, the system manager can gain accurate insight into how well (or not) he is achieving his objectives. The data that he collates as part of his responsibility to the agreement can also be used as justification for further expenditure on the systems, especially if the data reveals that the systems are underperforming in certain areas.

  The system manager also benefits because user departments are much more likely to involve the IT department in the early design decisions of systems. With the users made aware of the costs associated with a system, and its subsequent support, there is likely to be greater focus on longer- term (the complete life cycle) issues. This results in overall savings for the company as a result of better strategic planning.

• The end user ”The users benefit from SLAs because the IT department is forced to account more accurately for the services being provided. The costs must be based precisely on the performance being achieved, so the user perceives that he is receiving better value for his money.

  A side effect of the SLA is that the applications being used by the user community are prioritized according to their importance to the business. The creation of the SLA forces the focus to be placed on applications demanding the highest level of service, as well as identifying those that can operate with a reduced level of service. With the user department being charged for the services being provided, there is a more concentrated focus on what is being asked for. The user is less likely to ask for more than is absolutely necessary because of the costs that would be incurred.

• Senior management ”The senior manager reaps huge benefits from the SLA process. He now has a set of clearly defined metrics available from which he can manage the IT department based on performance. It is easier for him to quantify the contribution being made to the business by the IT department and, hence, to identify priorities when allocating funds for additional resources or equipment. The presence of SLAs helps the senior manager when attempting to compare the cost of carrying out a service within the company against that of outsourcing the service to an external supplier.

Of course, the business benefits from the existence of SLAs in that it runs more efficiently and also has the supporting data to provide justification for greater investment. This kind of information can prove valuable , for example, when attempting to convince shareholders or investors of the need for investment in technology.

Creating an SLA

This section discusses the procedures that are followed during the creation of a service level agreement. It is not intended to be a definitive discussion, but it gives an overview of the topics to be addressed.

There are several steps to follow in the creation of an SLA, and these are similar for various agreements ”in our case, one between the IT department and another department, within the same organization. The steps are described in detail in the following sections.

Step 1: Gain Agreement That an SLA Is Required

Without this, there is little point in continuing. The fundamental agreement that the SLA is required is the first step to achieving a mutually agreeable solution.

Step 2: Select and Assemble the SLA Team

A team needs to be selected from both the service provider section and the client section. The actual numbers making up the team will vary according to the size and complexity of the agreement being sought, but the guidelines in the following paragraphs might prove useful.

In an ideal world, the chief of each of the departments would be a part of the team, but this is not often possible, so, for the IT department, this may be delegated to the system manager. He can negotiate on behalf of the IT chief and possesses sufficient knowledge, both technical and business-related, to provide positive input to the process. As a general rule, I recommend two initial members from each group , calling on other "experts" as required for specific input related to their field of expertise.

Both parties should send people with sufficient authority to be able to finalize the agreement. Some managers deliberately send delegates that do not possess sufficient authority, but this is negative and counterproductive, and serves no real purpose other than to frustrate the proceedings .

The number of attendees should be balanced from both parties. They do not have to be exactly equal, but deviation should be kept to a minimum. Similarly, there should not be an excess of power on one side ”it can be intimidating to be faced with a team that is much more senior than yours. In fact, the less senior party could feel pressured into concessions that make the whole agreement worthless and meaningless. The requirement here is that a mutually understood and agreed contract is drawn up; it is not a competition to see who will win.

Step 3: Prepare for the SLA Negotiation

After the groups have been assembled , there must be some preparation before the start of negotiations. The system manager, for example, needs to identify the processes involved for the provision of his service. If it involves any sections or external providers that are beyond his control, then his ability to provide any guarantee of service is severely diminished. He must first obtain agreements (SLAs, maybe) himself from all of these so that he is then in a position to be able to offer a minimum and maximum level of service.

The system manager must be able to monitor the level of service being provided so that, if required, he can produce evidence to show that targets have been met or exceeded. He cannot promise a level of service if he can't measure it. Conversely, the client group must identify as precisely as possible the service that is required. A certain amount of discipline is required on behalf of the client team: Clients must request the level of service that is necessary to carry out their function, rather than a "wish list" of what they would like to see.

Step 4: Establish the Terms and Scope of the Agreement

Items under this heading include, but are not limited to, the following:

• Length of the contract ”Typically, this is between one and two years. Given the technology present today, it would be imprudent to try to create any contract lasting longer than two years (indeed, two years is a long time), although, as detailed later in this section, the agreement will be subjected to modification from time to time. A contract start date and end date should be defined here, too.

• Response times for trouble tickets ”These can vary in priority according to the type of problem raised and must be organized in such a way that the urgent ones are dealt with in a timely manner and in the right order. An example is to have priority 1, 2, and 3 (or high, medium, and low), with a realistic response time attached to each, such as one hour , one day, and one week, respectively. For example, a problem that affects all the users would definitely attract a priority 1 status, whereas a request to add a new user scheduled to join next week would attract a priority 3 response. A priority 2 response could be a problem affecting only one user.

• Data retention and restoration requirements ”The expectations of how long data is required to be kept (and how and where the data is to be stored) would be included here, in addition to the time taken to restore a specified file (or item of data). For example, if six months of data is held locally, then a restore could be expected within an hour or two. Conversely, restoring a file that is two years old could involve retrieving the backup media from an off-site storage facility and might be specified as taking up to one week.

Resolution and Response

Some SLAs define a resolution time as well as a response time. This can prove to be a dangerous practice for the system manager. Responding to a trouble ticket within a certain time is one thing, but guaranteeing the resolution time is quite different and could potentially cause major problems.

• Enforcement of quotas ”Any user quotas, usually in terms of disk space storage, should be identified either on a per-user or per-application basis. The system manager needs this information to be able to allow sufficient storage space for the consumers' needs, ensure that the data will be safely backed up, and provide contingency (in the case of high availability requirements) through the use of RAID or mirroring.

• Identify clear boundaries of responsibility ”When multiple organizations or departments bear responsibility for parts of the system, clear boundaries need to be identified so that each party is aware of the extent of its involvement. This is often a contentious aspect, with disputes arising as to whether a problem is hardware- or software-related and who carries out the initial investigation to determine where the fault lies.

• Identify the standard path for escalation ”This is the default action to take when nonperformance is identified ”that is, failure to achieve the agreed level of service. The escalation path is described in more detail in the section "Penalties for Missed Targets."

The scope of the agreement should be clearly defined so that there can be no misunderstanding between the parties at a later date about what is included in the agreement and what is excluded. Occasionally there will be specific exclusions ”for example, if the client group is using an old piece of hardware for a specific function, then the system manager might want to exclude it on the grounds that it is no longer supported and is covered only on a best-endeavors basis.

Step 5: Document the SLA

This is the part of the process in which a mutually acceptable agreement is reached and both parties understand what is being provided and what is being expected. The agreement should possess the following characteristics:

• Any objectives identified must be within the control of the service provider ”There is no point in trying to set the expectations when the service provider has no direct control. An example of this could be the client group stating that the wide area network (WAN) connections must be available all the time. The system manager might have an agreement with the network section, but it is the network section who will have the SLA with the external communications company, which maintains the WAN connections. However, if the client group requests that there be no more than 60 minutes scheduled downtime on the Solaris servers in a year, this is under direct control of the system manager and is a valid expectation.

• Any objectives must be meaningful ”This is quite difficult in that an objective initiated by the client group may not be meaningful to the IT department, and vice versa. For example, the number of network collisions or bad receive packets are meaningless to the client group. The client would like to see something such as "a query must be actioned in three seconds or less." The latter will be much more meaningful to both parties; the measurement of it, however, is a different matter entirely.

• The agreement must be mutually acceptable ”The whole idea of creating a service level agreement is one of it being mutually acceptable. It is unlikely that both parties will always like everything contained in an SLA, but they should find it acceptable ”there is a distinct difference. If one of the parties finds something that it decides is unacceptable, then this issue should not be agreed to, and renegotiation should take place. This is infinitely preferable to having an agreement made containing items that are unacceptable to one of the parties ”it undermines the whole value of having the SLA in the first place. Basically, if the job is worth doing, then it should be done properly.

• Any objectives must be achievable and cost-effective ”Both parties must realize very early in the SLA process that there is a requirement to be realistic about what is being provided and what is being expected. It is a complete waste of time if the expectations are impossible to achieve with the current system and network configurations. It is also unlikely that any system manager would agree to an expectation that he knows he can't accommodate. If any hardware or software upgrades are required to satisfy the expectation, then they must be justified as cost-effective and beneficial.

• It must be possible to measure objectively the service being provided ”Some of the client expectations will be extremely difficult to measure accurately without the use of a management tool ”even some of these do only part of the job. Data may be available from several sources that, when correlated and analyzed , provides the necessary information to determine whether the expectation has been satisfied. However, both parties must agree on the objectiveness of the data being gathered. The subject of monitoring performance against targets is discussed in greater detail later in this chapter in the section "Monitoring Performance Against Targets."

Step 6: Identify Nonperformance Indicators

As part of the SLA agreement, a set of criteria must be established so that indicators exist when the performance expectations of the client are not being met. To be able to do this, it is necessary first to have established the minimum level of service required. It could be something as simple as the example in Step 6, that a query should take no longer than three seconds to return the result. This is an end-to-end response time and may prove difficult to measure with any accuracy. The system manager may agree to an indicator as being the availability of the database (on which the query runs). It may be possible to measure the overall availability by using data extracted from more than one management system. It will depend on whether the client accepts the data as being valid, and also how much effort is expended in producing the required information ”it may not be cost-effective to do it.

Step 7: Identify and Agree to Corrective Action

Any corrective action should be invoked only as an exception. This section should identify the tolerances that are permissible. For example, if an expectation is that a query should take only three seconds, then what happens if it takes four seconds? And what if this happens only once? It can be seen that it would be unreasonable to invoke a nonperformance procedure for a one-off occurrence. A more representative and meaningful indicator of nonperformance would be if a percentage of queries in a day took longer than six or seven seconds to complete. The tolerances should be reasonable and realistic. As for corrective action, this is discussed more fully later in the section "Penalties for Missed Targets."

Step 8: Determine and Agree to a Review Process

Any SLA that is created will have to undergo a regular review. This is true because, as experience is gained , some of the performance parameters may evolve and be more finely tuned . A regular review should be agreed to and documented. A weekly review may be necessary in the early stages of implementation, but this could probably be reduced to monthly after an initial period.

Step 9: Establish Procedures to Allow Modification and Refinement of the Agreement

As part of the review process, the agreement must be subjected to occasional modification and refinement. This would normally come as a result of experience, or maybe an upgrade to the existing facilities or a new release of the application software. The process for modifying the agreement needs to be addressed here and agreed to.

Types of Availability

There are two kinds of availability, scheduled and unscheduled. Scheduled availability takes into account such aspects as routine maintenance and agreed upgrades, and can be easily planned in advance. Unscheduled availability includes such things as system crashes and database corruption, and cannot be planned for. It is often important to separate the availability requirements according to these two types.

Monitoring Performance Against Targets

The monitoring of performance is a difficult task and is usually hampered by the lack of accurate data relating to the target. The gathering of data for performance-monitoring purposes will often involve correlating data from more than one management system. For example, to ascertain the performance of the query example described earlier, it may be necessary to obtain network statistics, workstation performance statistics and database/host performance information. Any of these could potentially cause a bottleneck that could result in the SLA targets not being achieved.

Even with the data being correlated from several systems, there is no real guarantee of the accuracy. The IT department may state that queries are being completed in two seconds or less, but the user may disagree , stating that the system is slower than expected and discounting the collected data as invalid. Network monitoring tools have tended to look at only OSI Level 1 and 2 for their performance information, and only report on lost packets, number of retransmits, and so on.

Additional equipment or software may be needed to gather some of the data required for performance analysis. These could include LAN analyzers to examine packet throughput on the network, network-management software (such as Solstice Domain Manager), and the error logs already available.

Some better management tools now coming on the market are capable of monitoring the end-to-end process, something that has traditionally been missing from such tools. Framewatch, from GTE , is an example of the new generation of system-management tools. It uses RMON2 -enabled devices that can probe into the application layer of the OSI model and provide comprehensive information relating to the application. (RMON2 is the successor to RMON, Remote Monitoring.) This sort of management information is required to be able to report on the end-to-end performance and provide meaningful data for SLA purposes.

Another source for monitoring the performance of SLA objectives is by using the help desk system. In this instance, the number of calls logged against either a service or an application can be analyzed to gain insight into the level of performance being achieved. This data should be used to supplement other information and should not be relied upon by itself.

The system manager will be required to provide a periodic report detailing the performance levels that have been achieved. The report will be the result of the data gathering and analysis, displayed in a format that the users and senior management can easily interpret. It may be a good idea to produce the report in two forms: in a tabular form because, even though it may be more difficult to read, it will provide accurate figures; and in a graphical form, because it's easier to interpret and shows where any trends lie.

Monitoring trends can be of significant value. The system manager could be fore- warned of deteriorating performance and could address the issue before the impact is felt. Conversely, the senior manager could use the data to aid the forecast for the following year. The data could be used as a basis for the SLA reviews, which is where changes may be made to the SLA as experience increases .

Figure 3.2 shows an example of the type of information that could be included in a typical management report detailing the availability levels.

Figure 3.2. A detailed report provides a more comprehensive picture and also highlights areas requiring improvement. This important data could otherwise be concealed within an overall summary.

The same report is also shown in Figure 3.3 as a graph.

Figure 3.3. The graphical report provides easy-to-understand information and is ideal for displaying a comparison with previous figures.

Penalties for Missed Targets

When the service level agreement is between two departments working in the same company, it is unlikely that there will be a financial penalty for nonperformance. The only time that a financial penalty might be imposed is when the company runs a recharge scheme, or when the service provider is operating as a profit center, charging all its costs to its customers. In these cases, it is reasonable that the client would want to claim compensation for a degraded level of service.

It is worth noting here that if the agreement is between an internal department and a third-party supplier, then financial compensation for failing to meet an agreed target is usually part of the contract drawn up between the parties.

Sometimes the penalty clause is left out of an SLA altogether because the emphasis is directed so heavily on what is expected and required that the parties forget to include a section on what to do if either fails to meet the objectives.

There are alternatives to a penalty clause, and a lot of companies do not like to use the term penalty. One option is to include an escalation procedure for nonperformance to identify and resolve the issue. This means that when the objectives of the SLA are not reached and the tolerances are exceeded, an escalation procedure is invoked. This has the detrimental effect of informing management, which can be embarrassing and uncomfortable. The aim of the SLA is not to try to punish, but to provide the incentive to always try to at least meet the targets, if not exceed them.

If the service provider is constantly performing below the agreed level, then the SLA itself might need revisiting because the expectations possibly have been set too high and are therefore unrealistic. This is not always an indication of failure ”it could merely be an indication that the negotiation process did not fully achieve a mutual understanding of the service being provided.

It should be remembered that the original aim of setting up SLAs is to be able to define and manage mutually acceptable levels of service. The SLA should identify areas of the service that need improving and aim to focus on these areas instead of looking for ways of punishing substandard performance.

Using an Escalation Procedure

An escalation procedure is a defined set of steps designed to do two things: raise the profile of a perceived issue and get something done about it. The means of escalation in this case would probably be in the form of a service level exception report , a written report circulated to management highlighting the underachievement. Management, now aware of the problem, is expected to "take ownership" of the issue and exert pressure so that it doesn't happen again.

A more common, everyday example is when, as a consumer, you return to the store to complain about the quality of the goods that you have purchased. When your complaint is not dealt with satisfactorily, you demand to see the manager. You have now escalated the situation to a higher authority.

---

Top