Secrets of Service Level Management: A process owner’s guide

11Support tools for SLM

It is not a coincidence that this chapter is the last of Part 2 on service design. Once we have the process established, then we can start considering the tools and solutions to support the process and functions of the organization. The technology should always support the process and not the other way around.

In this chapter we will outline the basic activities of selecting the support tools suitable for your organizational needs by documenting the functional requirements of the basic support tools that are typically deployed by service level management (SLM).

Note that the process of purchasing a software solution is very difficult. Many service level managers are required to provide a business case and a solid return on investment (ROI) before any acquisition can be considered. The procurement process details are out of scope for this chapter; however, the purchasing process will include the functional requirements document, which is the main focus of this chapter.

11.1FUNCTIONAL REQUIREMENTS DOCUMENT

The objective of this chapter is to provide you with an overview of the functional requirements for tools and solutions that support the activities of the SLM process. Before diving into the development process for these requirements, let’s examine the overall structure of such a document.

The functional requirements document captures the intended behaviour of the system and is sometimes referred to as the software requirements specification. This document is a complete description of the behaviour of the system to be implemented. It includes a set of use cases that describes all the interactions the users will have with the software. In addition, the document contains non-functional requirements that impose constraints on the design, such as performance requirements, quality standards and/or design constraints.

Most companies will specify their functional requirements for vendors using the request for proposal (RFP). There are many ways to collect and compile the functional requirements and in the next section we propose the use-case method, which is a simple method to implement and is very effective.

11.1.1Functional requirements via the use case method

We recommend the use-case method as a framework on which to develop our functional requirements.

Use cases have become a popular way to express software requirements because they are very practical. A use case bridges the gap between user needs and system functionality by directly stating the user’s intention and the system response for each step in a particular interaction (see Figure 11.1).

Use cases were introduced as part of an object-oriented development methodology by Ivar Jacobson in Object-Oriented Software Engineering (ACM Press, 1992), but more recently they have been extended into a general technique for defining functional requirements. A use case defines a set of interactions between the actors – in our case the end users – and the solution under consideration. The actor is defined in the user profile section when the categorization occurs.

Figure 11.1 Use case within a software requirements specification

Generally, use-case steps are written in an easy-to-understand process orientation. The use-case development is completed by engaging the users who will validate the process and its activities. Note that the development of the use-case process is not documented in the functional requirements document; only its results are published within the document. Table 11.1 contains a number of example use cases for a service level agreement (SLA) system.

An effective use case is largely a sequence of interactions between the user and the solution, written in natural language that is easy to understand. Remember that in order for a use case to be successful, it must be well planned and include the stakeholder’s (mainly the user’s) identification and their requirements.

11.2CHOOSING APPROPRIATE TOOLS

The volume and complexity of activities will determine the types of tools required to support the SLM process. In small organizations the use of spreadsheets and Microsoft® Word will be sufficient to meet the needs of SLM. In larger organizations where the service structure is complex, there is a need for a robust solution to allow consistency and control over the process.

Technology has progressed greatly and there are many software solutions companies competing for market share. How would you make the right decision to select the tool that will fit your SLM needs and meet your business requirements? What are the steps in such a process?

Table 11.1 Example of steps for analysing an SLA compliance report

User intention	System response	Comments
Login to dashboard	The initial screen subsequent to login is a dashboard providing four different views: SLA report, open incidents, financial report, closed incidents by site	The specific requirements for dashboards and reports are detailed in the report catalogue
Filter SLA breaches	The system will filter out all those SLAs within compliance, presenting only those that are in warning or breached	Warning levels are thresholds that are defined within the SLA
Drill down	By clicking on the SLA result, the system will drill down to a more detailed report	The drill-downs per SLA are defined in the report catalogue

We will focus on four areas that may require you to develop or purchase a solution to support the activities of SLM:

Metrics management The development of metrics, key performance indicators (KPIs) and service levels can grow into complex calculations that require a solution to manage.
Performance reports Performance monitoring, data-gathering and compilation procedures are time-consuming tasks that greatly benefit from automated systems.
Service improvement plan (SIP) The SIP outlines the improvements to be made, their priorities, owners and estimated completion time.
Cost management There is the need for visibility regarding underlying service cost drivers so that a solution can be utilized that enables cost modelling.

Keep in mind that SLM is a process which incorporates activities that essentially need to be integrated and, by the same token, the tools that underpin these activities must be integrated as well. Remember to consider the integration between the tools on both the process side and the technical side.

There is a common thread through the solutions that support SLM and a link that should be transparent in the overall solution requirements. The metrics and measurements are derived from the service list. The measurements will be utilized by the SLA and the SLA compliance report. The review of the SLA compliance report produces a set of action items that are addressed by the SIP. Figure 11.2 depicts the high-level relationship between the SLM systems.

The remaining sections consider the four main SLM tools in more detail, providing you with an overview of the primary functional requirements.

Figure 11.2 Linking between SLM elements

Table 11.2 List of primary requirements for a metrics management solution

Requirement	Description
Visual interface	The structure of the metrics management must reflect the service structure of the organization (see Chapter 5). A graphical user interface will allow easy access and navigation through the metrics.
Design capabilities	The solution must provide a platform to support the design calculation of the metrics. The design of the measurements is laid out much like a process, and it is diagrammed step by step (see Figure 11.3). Each step is accompanied by documentation explaining the designer’s intent.
Open code	The calculation is imported from the diagram into a code, allowing minimum manual modification. However, the solution must be flexible to allow the developer further coding.
Metric definition	A metric such as ‘Incidents must be resolved within %variable% hours’ will be linked to a calculation.
Solution sets	The categorization of metrics and their management use different numbers of variables (see Chapter 9).
Integration with reporting	Data produced through the calculations and the output results become the source for the performance reports.

11.3METRICS MANAGEMENT SOLUTION

11.3.1Overview

The metrics management solution is a collection of available metrics. It consists of the metrics, measurements and calculations for the services. The metrics management solution supports the activities of developing, modifying and managing the metrics in a structured fashion.

Ideally the metrics management solution is integrated with the performance reporting solution; but even in a case where it stands alone, the metric definitions must be available for the reporting solution to be utilized.

Table 11.2 lists the primary requirements for a metrics management solution, but it is not all-inclusive. When developing the use case, consider this list along with the user requirements.

11.3.2Guidelines and recommendations

11.3.2.1Prerequisite design

Do not confuse the deployment of the metrics management solution with your design work. The design activities for the implementation of SLM, which this publication provides, include the documentation of process activities, SLA structure and the overall structure of the SLM function. The solution that manages your metrics is focused on performance measurements only and not on the overall design of the process.

Figure 11.3 Videoconferencing example – Severity 1 and 2 time to resolve

11.3.2.2Metrics and reporting

One of the most common pitfalls in the implementation of a metrics management solution is the compromise on the implementation of a performance reporting solution, neglecting the management of metrics that underpin the reports. If you decide to purchase a solution that fulfils both your reporting requirements and your metrics requirements, assess your metrics management requirements individually and make sure that the solution can satisfy these requirements.

11.4PERFORMANCE REPORTS SOLUTION

11.4.1Overview

The performance reports solution is considered by many to be the main tool to support SLM activities.

The primary report generated by the reporting solution is the SLA compliance report. This report will provide RAG (red, amber and green) results for each service level objective (SLO). The complete set of reports and dashboards are detailed in Part 4 (on service operation) and specifically in Chapter 15.

Table 11.3 is a list of primary requirements for a performance reports solution, but it is not all-inclusive. When developing the use case, consider this list along with the user requirements.

11.4.2Guidelines and recommendations

11.4.2.1The Excel addiction

Some habits are hard to break, but the Excel habit is the hardest of them all. Many reporting analysts are Microsoft Excel wizards and perform all their reporting duties using spreadsheet functionalities. One of the goals of this publication is to promote thinking outside the box for ITIL practitioners. The adoption of an automated reporting tool will allow you to spend more time on activities that you never had time for before, such as improving your procedures, paying better attention to your customers, and overall performance in best-practice activities.

11.4.2.2The integrity of your data source

Those who have any type of experience with implementation of the SLM reporting solution will confess to ongoing nightmares and anxiety disorder symptoms, all as a result of the data sources encountered. Your reports are only as good as your data, and the number-one risk on the reporting project plan comes from the data sources.

Do not be blinded by the attractive interface of the solution and the data adaptor agents of the solution. If your data sources are not accessible or lack basic integrity, there is much work to be done before selecting the correct tool.

11.4.2.3Stakeholder management

The reporting analyst is not the only stakeholder in the reporting environment. One of your main stakeholders is the customer. In the case of an external service provider, the SLM reports take a much larger role. Customer satisfaction tends to rise when a login to the reporting solution is provided. The customer feels that information is not hidden from them and they view the service provider more as a partner than an external vendor.

11.5SERVICE IMPROVEMENT PLAN SOLUTION

The SIP is becoming more popular within service management practices, and rightly so. The primary objective is to create a continual service improvement (CSI) register of improvement opportunities to track projects that are related to the improvement of services.

Table 11.3 List of primary requirements for a performance reports solution

Requirement	Description
User access	Users should be able to access the reports via a thin layer such as a web browser. The login will manage access permissions to user groups such as reporting analyst, SLM staff, customer and operations.
Dashboard	For each user group a default dashboard is set up, presenting different reports in the same view.
Report configuration	The users will be able to change basic report configurations, such as sorting, filtering and time duration.
Reports navigation	There is easy-to-use navigation from one report to another, including drill-downs, saved reports, recently used reports and importation of reports into different formats.
Service review preparation	Analysis of a predefined list of reports, the creation of reports for presentation, root cause analysis reports and SIP alignment.
SLA adjudication	Modification of the SLA results process, including the approval process with the customer; modification of data source and recalculation of results; modification of high-level SLA results.
Customized view	Each use will be given a default view according to its user group. Within that, the users will be able to customize their view by saving reports, creating a mailing list and modifying dashboards.
Export	The user will be able to export the reports in different formats – Excel, Word, images. This feature includes sending reports via email.
Report catalogue	The reporting analyst will utilize the solution as the report catalogue, managing the reports by title, description and target audience.
Data refresh	The updating of the data source underpinning the reports will be refreshed according to the nature of the reports. Some reports, such as open ticket status, may need refreshing every 15 minutes, while the SLA compliance report requires only a daily refresh.
Metrics management	In cases where the metrics management solution is a separate solution, the design of the reporting solution must include tight integration between the systems to allow the reporting solution to base its calculations on the measurements in the metrics management solution.
Alerting	The solution will enable the reporting analyst to establish thresholds for the SLOs and generate automatic alerts when the threshold is reached.
Admin requirements	Owing to the high importance of the availability of the system and the integrity of the data, the solution must provide the administration function with the ability of data processing, especially for the main data links that create the data bottleneck: data source link, calculation and report generation.

Table 11.4 is a list of primary requirements for a CSI register solution, but it is not all-inclusive. When developing the use case, consider this list along with the user requirements.

11.5.1Guidelines and recommendations

11.5.1.1The intimidation factor

The SIP process is fairly new and has only recently been introduced to some organizations. Many other organizations are comfortable doing what they always have done, following operational processes such as incident management and problem management, tracking services through performance reports. Managers tend to say: ‘If it works, why change it?’

The SIP process has been proven to promote communication among the customer, SLM and operations, and it also adds the structure of service improvement that is missing in many organizations.

11.5.1.2KISS (keep it simple, stupid)

When designing the CSI register solution, the scope of its attributes must be well defined, avoiding any attempt to include excessive and often unnecessary information. Simplicity is a virtue.

Table 11.4 Primary requirements for a CSI register solution

Requirement	Description
CSI register population	The potential CSI register records for review are generated from three sources: SLA compliance reports, the incident management system and manual entries. The first two should be automatically generated utilizing ‘pull’ or ‘push’ data. The manual entries should be handled via the solution interface.
CSI register review	The CSI register owner reviews the register on an ongoing basis, including access permissions to user groups. The viewing of CSI register content will allow record sorting by priority, category and outstanding action items.
Select and filter	The CSI register owner will have permission to filter out records for later review, as well as to change content and add comments.
Prioritization	During service review meetings and ongoing communication with customers and operations, the prioritization is subject to change. The other attribute related to this action is the completion date.
Alerting	The solution will enable the CSI register owner to establish thresholds for records and generate automatic alerts when the threshold is reached.
Reporting	The reporting work is done through collaboration with the SLM reporting function and typically includes: outstanding open records, closed by priority, and closed by category.

Table 11.5 Primary requirements for a cost management solution

Requirement	Description
Cost model design	The cost model will allow development of the cost model structure, including its categories and cost drivers. The solution will allow changes to the structure and content.
Cost allocation and population	Population of the cost model will be performed by connecting to financial systems and automatically collecting the data, allowing for manually entered data also. The solution will include editing features to permit the user to overwrite information supported by log files.
Budgeting and planning	A clear view is provided of the budget versus actual position, and the configuration of a process to manage future gaps.
Charging	The solution will support different charging methods and invoice the business units according to their service consumption.
Penalties	The solution will support the measurement of penalties for which the service provider is responsible in the event of SLA breaches. The solution will also support the ongoing process of determining the final figure for the penalty following negotiations between the customer and the service provider.
Earn-backs	The service provider may earn back penalties after providing a high level of service provision. The solution must be able to calculate the invoice considering the level of service and penalties.
Analytics	The solution will automate forecasting reports such as budget versus actual costs, potential cost overruns and suggested adjustments.

Remember that the CSI register solution assists in managing records that are ultimately being executed outside the scope of the process. Register records are a placeholder for projects or changes that are to improve the services and are not there to manage the projects or the change.

11.6COST MANAGEMENT SOLUTION

11.6.1Overview

SLM, as explained in Chapter 10 on financial management, will be assigned as the owner of activities associated with transparency, which include cost modelling, chargeback, penalties and earn-backs.

Table 11.5 is a list of primary requirements for a cost management solution, but it is not all-inclusive. When developing the use case, consider this list along with the user requirements.

11.6.2Guidelines and recommendations

11.6.2.1Avoid working in a void

The SLM cost management activities are closely linked to other areas, including SLA tracking, customer satisfaction and much more. Thus it is advisable to combine the cost management solution with other SLM solutions, thereby illustrating the close relationship between them.

11.6.2.2Optimizing cost management

It is virtually impossible to achieve a flawless cost model the first time around; it should be viewed as a starting point for an improvement process aiming for a stable and reliable model. This is a significant difference from the deployment of any other software solution. In other solutions, the better you plan and design, the less adjustment and bug fixing you will need to do, whereas in cost management it is anticipated that adjustments will be necessary as an integral part of the deployment.

11.7SUMMARY

Ideally, one solution can be customized to your needs and that will fulfil the requirements to support the activities of SLM. There are basic elements that are linked among all processes and therefore should be linked within the technology deployed for them. However, budget and technical constraints are factors that we must manage and therefore require us to identify all stakeholders and collect all their requirements, so by the end of the deployment the solution is fit for purpose and fit for use.