The tool most relevant to your role as SLM is your organisation’s service management tool, as this chapter explains.
Your organisation’s service management tool is used to log incidents, service requests, problems and changes. It may also log or interface with the tool(s) that contain(s) the service asset and configuration information, and log(s) events.5
Most of today’s toolsets have fully integrated capabilities and provide extensive reporting that is usually customisable. It is this tool and its reporting capabilities that are critical to your role in that it is the source of information about workload volumes and performance. It is therefore also the source of the information that will allow you to determine the extent to which your organisation is meeting its service levels.
As we have already mentioned, these tools or toolsets typically report activities by type, such as incidents, or problems by priority. Your challenge is to gain a different perspective or view, namely one that represents customers or services. The ability to obtain this information will depend on two things: the extent to which this is possible in the toolset; and the ability (and willingness) of those responsible to enter the appropriate data accurately.
Regarding the second point, to report by service and/or customer requires the service and/or customer to be identified by the analyst and accurately logged in the record. To do this requires a definition of services and customers to be available to or configured within the tool and kept up to date, a task with which you might help, particularly if there is no service catalogue in place.
Essentially, you will need to be able to report performance against service levels both by service and customer for incidents, service requests, problems and changes as a minimum. This will be very time-consuming if not done automatically by the tool, but the tool is only capable of reporting using the appropriate parameters, and if the necessary information is entered.
You will need to verify the capability of the tool in this respect prior to commencing service level discussions with your customers. You will also need to ensure that the analysts responsible for creating and updating the records do so in the required way to support the analysis.
It would be hard to overestimate the importance of the tool capabilities and analyst activities in recording information, since this is the primary source of service level reporting. If the source information is available and accurate, then taking this data and building them into a report will depend on the extent to which the tool can do this, and/or on your own abilities. Even then, you still need to gather and report on exceptions and variances that will require potentially deeper analysis of the data and/or consultation with your colleagues.
Should your organisation have a disparate set of tools or tools that lack integration capability, then you may have to extract data separately from:
• the configuration management system/databases, in order to validate equipment type, locations and ownership (for instance);
• the event management system, to validate performance against service levels by tracking response time (for instance);
• the change management toolset, to report on the number and success of changes as well as the schedule of change and projected service outage report to advise your customers of upcoming events of relevance.
Ultimately, if the data you need is unavailable for whatever reason, then you either have to accept the situation or find a way to tailor the systems to be able to report the required information.
5 Examples of such tools include Remedyforce and those offered by ServiceNow.