10.2 Summary of tool-evaluation criteria

The following criteria should generally be used to assess software tools under consideration:

• an 80% fit to operational requirements
• a meeting of ALL mandatory requirements
• little (if any) product customisation
• ITIL compliance
• a sound data structure and handling
• business-driven not technology-driven
• administration and maintenance costs within budget.

Software tools should handle processes in conformity with the practices discussed in the IT Infrastructure Library. A set of guidance (the Appraisal and Evaluation Library) is available for the guidance of organisations wishing to select Service Support and Service Delivery tools. The prime areas to consider are:

• functional requirements support, and the level of integration with, for example, Service Delivery processes and tools
• data structure, data handling and integration, including the capability to support the required functionality
• integration of multi-vendor infrastructure components, and the need to absorb new components in the future - these will place particular demands on the data-handling and modelling capabilities of the tool
• conformity to international open standards
• flexibility in implementation, usage and data sharing
• usability: the overall ease of use permitted by the User interface
• service levels: performance and availability
• distributed clients with a centralised shared database (e.g. client- server)
• back-up, control and security provisions
• the quality of information provided by the supplier, and its validation by contact with other Users.

10.2.1 Service Management tools

Few enterprises have no Service Management tools, and many are considering replacing or upgrading those that are in use. The range and sophistication of tools for Service Management automation has grown rapidly in recent years.

Tools for the automation of core processes such as Incident logging and tracking have been supplemented by computer-integrated telephony, software capable of handling complex and multiple Service Level Agreements (with separate targets and business clocks) and remote support technology. Other tools include:

• interactive voice response (IVR) systems
• the Internet, internal electronic mail, voicemail
• self-help knowledge
• case-based reasoning/search systems
• network management tools (including remote support capabilities)
• system monitoring
• Configuration Management and Change Management systems
• release and distribution systems
• security monitoring and control, including password control, detection of violations, and virus protection
• capacity planning
• IT Service Continuity Management (including automatic back-ups).

Although some of the tools are not yet commonly used, there are few areas of Service Management that cannot be helped by automation. Some areas of Service Management are too resource intensive to be performed effectively without automation. Each tool for the automation of Service Management has advantages and disadvantages, but automation is still recognised as vital.

It is necessary to ensure that the combination of technology, processes and people are integrated and meet the needs of the Customers. Automation should be used to enhance Service Management, not replace it.

Automation is increasingly being treated as part of workflow management, linking each task in the life-cycle, from a new service being planned through to disposal. The technology should be used to complement and enhance service delivery, not replace it.

Automation that provides support for distributed computing has revolutionised the ability of an enterprise to diagnose Problems remotely, and in many cases also to fix them remotely (and therefore faster). Remote support technology has also made it possible for an enterprise to make changes by downloading the new versions of software and to monitor the capacity of the infrastructure, identifying capacity problems before they become serious.

Automation has enabled easier contingency planning, with work being switched in the event of a local overload or a serious problem that has taken the service out from a specific area.

Some final considerations:

• supplier and product credibility and viability - installed base and degree of support; consider issues such as the financial viability of the vendor (are they likely to be around in a few years when you need them?); also consider large time-zone differences between the supplier and your organisation and language differences
• costs, including ongoing cost to upgrade and support - consider which is better:
  • buying a standard package at reasonable initial cost, where the trade-off is that customisation may be very expensive and complex
  • or a more flexible package at higher initial costs where customisation maybe relatively easy and cheap
• adaptability - will the tool be able to meet organisation specific requirements and constraints in the years to come.