Service Support Metrics

In Malcolm Fry's book (that is being hosted by NextSLM.ORG), he reviews each ITIL metric individually by quoting the ITIL definition, describing it in clear and concise terms, and making recommendations on how to best leverage the data for both IT managers and business managers. By focusing on these key metrics, one can help illustrate the value of ITIL best practices to those who have responsibility for related functional areas within IT.

He also adds to ITIL recommended metrics and introduce Business Alignment Indicators. These key metrics expand the ITIL best practices to highlight information that helps align IT goals and objectives with business priorities.

Please read on to know more about the same -

Introduction

Information Technology (IT) groups are generally adept at gathering vast amounts of data. The data collected is not always used successfully for analysis and decision-making, however. Very often, the opposite is true. The processing of raw data is sometimes a distraction, rather than a useful activity. For example, many IT departments measure and monitor every event on a Service Desk, yet they may fail to notice that a key server is getting close to capacity. Why? Service desk technologies automatically collect and collate vast amounts of data regarding Service Desk performance, whereas measuring the growth of a server relative to its capacity requires a different effort and intervention.

Let’s look at how we can best leverage data to provide both IT Managers and business managers with useful tools that help them keep IT services closely aligned with business goals.

The benefits of ITIL are often obvious to those who have received ITIL education, read the ITIL books or attended and ITIL conference or training. The first two books in this series focused on advanced ITIL concepts that help ITIL experts build commitment from non-ITIL experts within an organization, by selling what’s important to various constituents, and by better communication the goals outlined in ITIL Service Delivery and Service Support.

In this, the third book in the series, we’re going to continue developing advanced ITIL concepts by focusing on the monitoring and measuring best practices describe in the ITIL Service Support book including:

1) Incident Management

2) Problem Management

3) Change Management

4) Release Management

5) Configuration Management

Each section of the ITIL Service Support book details a list of metrics that should be considered for those managing that functional area. In total, the book lists about 80 suggested measurements to use for monitoring and measuring performance across these processes.

In this book, we’ll review each ITIL metric individually by quoting the ITIL definition, describing it in clear and concise terms, and making recommendations on how to best leverage the data for both IT managers and business managers. By focusing on these key metrics, you can help illustrate the value of ITIL best practices to those who have responsibility for related functional areas within IT.

We’ll also add to ITIL recommended metrics and introduce Business Alignment Indicators. These key metrics expand the ITIL best practices to highlight information that helps align IT goals and objectives with business priorities.

Driving Factors

There should always be reasons for monitoring or measuring. You should continually ask, “Why are we measuring?” or “Why are we collating this data?” Basically, there are four reasons to monitor and measure:

To direct: This includes monitoring and measuring to set direction for activities in order to meet set targets. It is the most prevalent reason for monitoring and measuring. For example, Service Level Agreements (SLAs) set target metrics and the IT department is measured against these targets. These targets set the direction for the IT department.

To intervene: This includes monitoring and measuring to identify a point of intervention including subsequent changes and corrective actions. For example, a network may monitored and identified to be slow. As a result, IT undertakes an investigation that will result in changes implemented to accelerate network performance. Special monitoring may be installed for the investigation to track the effects of the changes. Again, these metrics are usually monitored only for the duration of the changes. However, ongoing measurement may be necessary to direct and ensure that performance does not deteriorate in the future.

To justify: This includes monitoring and measuring to justify, with factual evidence or proof, that a course of action is required. For example, return on investment projections may be required to make a major purchase. Justification often requires forecast trending, financial projections, and/or modelling. In a typical scenario we first justify a project and then validate the deliverables.

To validate: This includes monitoring and measuring to validate previous decisions. For example, the justification to implement configuration (asset) management may be to reduce the costs of asset spending by 10 percent. This requires the implementation of a measurement tool to track and monitor the savings resulting from the project to validate that 10 percent savings goal has indeed been met. Once the project has been completed, it is no longer necessary to measure for validation.

The four basic reasons to monitor and measure lead to two key questions: “Why are we monitoring and measuring?” and “When do we stop?” To answer these questions, you must identify which of the above reasons is driving the effort. Too often, we continue to measure long after the need has passed. Every time you produce a report you should ask, “Do we still need this?”

Definitive Measuring Process
Whether you are measuring to direct, intervene, or justify, or validate you should follow the same simple process:

The process may be simple, but the activities may be time-consuming and difficult. Let’s look at the process in more detail:

Gathering: Gathering concentrates on collecting the raw data required for monitoring and measuring IT services and components. At first glance, it may appear that gathering the necessary data is easy, because IT automatically collects huge amounts of data. However, this is not always true. For example, a Service Desk tool primarily collects data entered by the Service Desk agents, but if a key field is not on the Incident record, then no data can be gathered for that parameter. You should ensure that you have the correct data collection methodology in place.
In addition, it is often necessary to collect more information than is required, so that, in the event of a poor measurement, a base of data is available for further investigation. One thing is certain—to be successful, you must collect the correct data. To do so, you must know why you’re gathering the data—is it to direct, intervene, validate, or justify?

Processing: Once you have gathered the data, the next step is to process the data into the required format. For example, you may have 3,000 Incidents a week, but only want to see the hourly totals to determine staff loading. You use report-generating technologies at this stage. Normally, this means taking huge amounts of data and condensing it into information for use in the succeeding stages.

Analyzing: Once the data is processed into information, you can then analyze the results, looking for answers to questions such as:

· Are there any trends?

· Are changes required?

· Are we operating according to plan?

· Are we meeting targets?

· Are corrective actions required?

· Are there underlying structural Problems?

Here you apply knowledge to your information. Without this, you have nothing more than a string of numbers showing metrics that are meaningless. It is not enough to simply look at this month’s figures and accept them without question, even if they meet SLA targets. You should analyze the figures to stay ahead of the game. Without analysis you merely have information. With analysis you have knowledge. If you find anomalies or poor results, then look for ways to improve.

Presenting or Using: The final stage is to take our knowledge and present it, that is, turn it into wisdom by utilizing:

· Reports

· Monitors

· Action plans

· Reviews

· Evaluations

· Requests For Changes

· New opportunities

As you can see, measuring and monitoring allows you to make informed decisions, taking IT forward in a constructive and structured manner.

This process defines a logical approach to follow, but how can you be sure that you are monitoring and measuring effectively? You need to have in place driving factors to ensure that you will produce effective metrics.

The driving factors affect the data that you collect as well as all the other stages in the process. There is no point in gathering huge amounts of data unless you are going to use it constructively. First, decide why you are going to monitor a parameter. Armed with this information, you can determine what data is required and where you can obtain that data. From here you can follow the process, but remember that success lies in identifying the driving factors at the outset.