Chapter 40
Technology Considerations
THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
- ✓ Service operation technology considerations:
- The types of tools that would benefit service operation
- The generic requirements for service management tools
- The specific service operation process requirements for service management tools
- The use of tools and how they support the service lifecycle
This chapter brings all technology requirements together to define the overall requirements of an integrated set of service management technology tools for service operation. The same technology, with some possible additions, should be used for the other phases of IT service management (ITSM)—service strategy, service design, service transition, and continual service improvement—to give consistency and allow an effective ITSM lifecycle to be properly managed.
Tools can help the service operation and other processes to work more effectively. They should allow large amounts of repetitive work to be carried out quickly and consistently. Tools also provide a wealth of management information, leading to the identification of weaknesses and opportunities for improvement.
The use of tools will help standardize practices and both centralize and integrate processes.
We are going to consider the generic requirements for such tools and the particular requirements needed to support the service desk function and the service operation processes of request fulfilment and event, incident, problem, and access management. It is important that the tool being used should support the processes, not the other way around.
Service Management Tools
We will begin by considering the generic requirements for IT service management tools. In this section, we look at a number of these requirements, which we would expect any good integrated toolset to offer.
The first two requirements are self-help functionality and a workflow engine.
You should be able to recall from the discussion of the release fulfilment process that we discussed the option for dealing with requests or simple incidents via self-help functionality. This might be restricted to the logging of requests and incidents, or it could allow them to be tracked and updated throughout their lifeycle. The advantage to providing a self-help facility is that requests and incidents can be logged at any time and this process is not dependent on service desk staff being available to answer the phone. This helps the service desk manage high volumes of calls if the less urgent ones are handled via a self-help, self-logging site. Self-help request tools can assist with password resets by, for example, requiring the user to validate their identity by answering previously set questions before the reset takes place. Additionally, a self-help request tool could download approved versions of requested software.
The next generic requirement is for a workflow or a process engine that can automate the steps of the process (assigning, escalating, etc.). It can also release work orders when prerequisite steps have been completed.
The next generic requirement is for an integrated configuration management system (CMS).
The service management tool should be integrated with the CMS to allow the organization’s configuration item (CI) information to be interrogated and linked to incident, problem, known error, and change records as appropriate.
Another generic requirement is for discovery/deployment/licensing technology tools; these are extremely helpful in verifying the accuracy of the CMS, especially with regard to license use. It is also very helpful if only changes since the last audit can be extracted and reported upon. The same technology can often be used to deploy new software to target locations; this is essential to enable patches, upgrades, and so on to be distributed to the correct users.
When implemented in conjunction with the self-help functionality previously mentioned, this facilitates the automation of the fulfilment of many service requests for software.
Another generic requirement is remote control. This allows the service desk analysts to take control of the user’s desktop (under properly controlled security conditions) to do things such as conduct investigations and correct settings.
Some tools will store diagnostic scripts and other diagnostic utilities to assist with earlier diagnosis of incidents.
Good reporting is a requirement of any ITSM toolset. The tools hold enormous amounts of information about what is happening day to day. This data is helpful in planning ahead and tracking trends, but such reporting has to be flexible if it is to be useful. Standard reports and ad hoc reports should both be easily available.
Another generic requirement to consider is a dashboard facility. Dashboards are useful, both for day-to-day operations and for IT and business management to get a clear idea of real-time performance.
To facilitate greater business alignment, business applications and tools need to be able to interface with ITSM support tools to give the required functionality. An example of integration includes event management tools spotting unusual spending patterns on credit cards.
Software as a Service (SaaS) technologies offer hosted service management capabilities over the Internet. The advantages this offers include lower capital and start-up costs, faster implementation, and built-in service continuity.
However, it also means limited customization and changes to functionality, access restricted to vendor’s hours of service availability, and licensing schemes that may become restrictive or expensive. There may also be limits on data storage size and possible security and access management constraints or risks. Finally, integration with other service management tools may be difficult or even impossible.
Each organization should review its requirements carefully so that it acquire the most appropriate toolset for its needs.
Tool Requirements for Service Operation Processes
In the following sections, we’ll consider the requirements of each service operation process.
Event Management
The tool requirements for this process include an open interface with standard Simple Network Management Protocol (SNMP) agents to enable events from differing technologies to be managed together. The tool should be easy to deploy and should route all events to a single location. It should be able to be programmed to handle alerts differently, depending upon symptoms and impact, and to escalate events if they are not responded to within a set time period. It is essential that the tool should provide meaningful management information and a business user dashboard. It should also have a direct interface into the organization’s incident management processes. Another possible capability would be the ability to use SMS messaging to escalate events to support staff.
Incident Management
Next, we will consider the specific tool requirements for incident management.
The first is the capability to log incidents quickly, often by using predefined “quick calls” for common incidents (also referred to as incident models), with preset categorization, prioritization, and assignment. Tracking and reporting of incidents must also be easy and efficient.
Another requirement is an integral CMS to allow automated relationships to be made and maintained between incidents, service requests, problems, known errors, workarounds, and all other CIs. The CMS should also be able to assist in determining priority, help investigation and diagnosis, and escalate to appropriate resolution teams within technical and application management.
A process flow engine is essential to allow processes to be predefined using target times to automate the workflow and escalation. So, for example, if a support team has not responded within 60 minutes to an incident assigned to them, the team leader is automatically informed.
An interface to event management should be in place, as previously discussed, to allow failures to be automatically raised as incidents, and a web interface can be set up to allow the use of self-help tools and self-logging of incidents and service requests.
An integrated known error database for recording and searching for diagnosed and/or resolved incidents and problems can help speed up future incident resolution.
Easy-to-use reporting facilities are needed to allow incident metrics to be produced, and diagnostic tools will help the service desk to resolve incidents at first contact. Reporting capabilities should enable efficient access to incident histories and summarizations of incidents by category, priority, status, and CIs impacted to provide data and support for reactive and proactive problem management activities.
Request Fulfilment
The specific requirements for request fulfilment include the ability to differentiate requests from incidents and the ability to link service requests to incidents or events that have initiated them. As previously mentioned, tools should include self-help capabilities to allow users to submit requests via a web-based, menu-driven selection process.
Otherwise, the facilities needed to manage service requests are very similar to those for managing incidents. They include predefined workflow control of request models, the ability to set and automate priority levels, automated escalation, and effective reporting.
Problem Management
Having a good ITSM tool is essential for effective problem management. A specific tool requirement for problem management is an integrated service management tool that differentiates between incidents and problems—and allows them to be linked.
Integration with change management is also required to allow request, event, incident, and problem records to be related to requests for change that have caused problems and to RFCs raised to resolve problems and incidents. There should be an integrated CMS to allow problem records to be linked to the components affected and the services impacted. Service asset and configuration management forms part of a larger service knowledge management system (SKMS), which includes links to many of the data repositories used in service operation.
An effective known error database (KEDB) will be an essential requirement to allow easy storage and retrieval of known error data. The ability to be able to link to vendor KEDBs is also a requirement.
Good reporting facilities are needed to ease the production of management reports and to allow drill-down capabilities for incident and problem analysis.
Access Management
The final service operation process, access management, requires integration with a number of technologies.
The first requirement is the ability to link to the technology used by human resources to validate the identity of users and to track their status. Another requirement is the ability to link to directory services. This technology enables technology managers to assign names to resources on a network and then provide access to those resources based on the profile of the user. Directory services tools also enable access management to create roles and groups and to link them to both users and resources.
Access management will use features in applications, middleware, operating systems, and network operating systems.
Changes to access requirements may be logged via a service request or be part of a work order from change management, so integration with these systems is very useful.
Access management also requires links to incident management in the case of suspected security incidents from people requesting access they should not have or inappropriate use of access.
Service Desk Function
In this section, we’ll consider the requirements of the service desk, because in addition to the technology requirements for each process, the service desk function has some specific requirements.
The first requirement is for a known error database (already mentioned when we talked about the requirements of the incident and problem processes) to store details of previous incidents/problems and their resolutions so that recurrences can be more quickly diagnosed and fixed.
Diagnostic scripts should be developed, stored, and managed to allow service desk staff to pinpoint the cause of failures. This requires input from the technical and application management functions and suppliers who need to provide details of likely faults, the key questions to be asked, and details of the resolution actions to be taken.
We have already mentioned the importance of a self-help web interface so users can log their own incidents and requests and even obtain assistance, which will enable them to resolve their own difficulties. This should include the following features:
- FAQs
- Password change capabilities, including identity checking, without the need for service desk intervention
- Software fixes, downloads, and repairs
- Downloads of additional authorized software packages
- Advanced notice of planned downtime
Finally, it is often helpful for the service desk analysts to be able to take control of the user’s desktop to allow them to, for example, conduct investigations or correct settings. Facilities to allow this level of remote control will be needed.
In addition to an integrated ITSM tool, the service desk needs the facilities offered by modern telephony services:
- An automated call distribution (ACD) system to allow a single telephone number. These systems provide extensive statistical reporting, providing insight into the busy times, average length of call, and so on.
- Interactive voice recognition (IVR) selection. These systems, which provide users with one or more menu selections, should be used with care. They should not have too many levels of options or offer ambiguous options.
- Computer Telephony Interface (CTI) software enables the caller to be identified from their telephone number and the incident record to then be automatically populated with their details extracted from the CMS.
- Voice over IP (VoIP) technology can significantly reduce telephony costs when dealing with remote and international users.
- Other possible facilities include cordless headsets, the ability to record calls for training purposes, and the ability to listen in on calls.
Service Management Tool Choice
There are many service management tools available, each with its own strengths and weaknesses, which makes choosing the right one difficult. To overcome this, you should define some objective selection criteria.
One simple method is MoSCoW analysis. This involves creating a detailed list of all your requirements and classifying each one as must have, should have, could have, or would like in future.
- Must have requirements are mandatory. Any tool that does not satisfy all of those requirements is rejected.
- Should have requirements are those that we expect but are not essential.
- Could have requirements are useful but not hugely important.
- And Would like in future requirements are those that we don’t need right now but will need in future. For example, we’re choosing a tool for incident management right now, but we’d like it to have problem management capability later.
You can then devise a scoring system based on this analysis, which would enable you to rank alternatives. It is possible to weight your decision, making a scoring system to ensure that you are getting the service management tool that delivers against your requirements.
Summary
This brings us to the end of the chapter. In this chapter, we reviewed the service operation requirements relating to tools such as the integrated service management tool.
We looked at the following topics:
- The types of tools that would benefit service operation in support of the processes and service desk function
- The generic requirements for service management tools
Exam Essentials
Understand the role of tools in supporting service operation. This includes understanding how to select tools that are appropriate for organizational needs.
Explain the generic requirements that service operation has for toolsets and why they are important. Understand the generic requirements that are applicable to service operation and how these tools will support the objectives of the lifecycle.
Understand the specific requirements for the individual service operation processes. Be able to identify the requirements for the individual processes from service operation to ensure maximum efficiency from the toolset.
Explain the selection technique known as MoSCoW. Understand what the acronym stands for (Must/Should/Could/Would) and be able to explain the use of each concept in tool selection.
You can find the answers to the review questions in the appendix. Which of these statements about service management tools and technology is correct? Which of these statements is/are correct? What is the first step when choosing a service management tool? Which of these would be included in the generic requirements for a service management tool? What is the MoSCoW technique used for? Which of these is most likely to be part of a self-service portal? Which of these considerations for reporting requirements for service management tools is important? Management support is critical for successful service operation. What benefits are expected from management’s commitment to technology and tools? Which of these statements is/are correct? True or False? A service management tool is a tool used to log records/tickets. No other tools are service management tools.Review Questions