Process or Tool First?

It is important that the tool being used supports the processes—not the other way around. Although a process should not be modified to fit the tool, there may not be a tool that can support the process as it has been designed. As long as it achieves the desired end result, a tool can be chosen that requires the process to be redesigned to some extent. The benefits of being able to automate the process should outweigh any loss as a result of changing the process.

Specifying Requirements

The same attention should be given to choosing any tool for a business. Requirements must be gathered from stakeholders, as described in Chapter 16, “Technology-Related Activities,” in the section “Service Design Activities and Techniques within Requirements Engineering.” These requirements will then form the statement of requirements (SoR) for use during the selection process. It is essential that requirements are clearly stated, and they should be subdivided into business requirements, mandatory facilities, and “nice to have.” The statement can then be used as a checklist.

There are dozens, if not hundreds, of service management tools available. Details can be found on the Internet, in service management manuals, by asking other organizations, by asking consultants, or by attending seminars and conferences to see what products are available. Consider restricting your consideration to those tools that have been independently assessed.

Evaluation

Consideration must be given to the architectural platform where the tool will reside, and compatibility with the architecture will be a key mandatory requirement. Such mandatory requirements may well restrict which products can be included in the evaluation process, but this is to be expected and ensures that the final choice can meet the requirements. It is also essential to ensure that any tool procurement exercise fits within existing approved budgets.

One simple evaluation method is known as a MoSCoW analysis. It involves creating a detailed list of all 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 the requirements is rejected.
• Should have requirements are those that we expect but are not essential.
• Could have requirements are useful but not hugely important.
• Would like in future requirements are those that we don’t need right now but will be needed in future

As with choosing any tool, functionality (i.e., utility) is not the only requirement. The product’s ability to perform in terms of warranty must also be considered; factors such as scalability and security must match the requirement.

The following points should also be considered when evaluating service management tools:

• How data is structured and handled.
• Compatibility with infrastructure components from other vendors. If the tool conforms to international open standards, integration with other tools will be easier.
• Flexibility.
• Ease of use.
• It should be easy to set up the tool to deliver the functionality, such as support for monitoring service levels.
• The technical platform used; does it use a client/server approach?
• How is data protected and backed up?
• If the decision is made to import historical data into the new tool, there should be a simple mechanism to do so.
• The support options provided by the tool vendor should be assessed.

Most organizations find it preferable to use a single integrated tool across the various service management processes, rather than having the overhead of integrating different tools.

Evaluation Process

The diagram in Figure 18.1 shows the standard approach of identifying requirements before identifying products. In reality, looking at products in the market may highlight useful facilities that one had previously been unaware of. These can then be added to the final requirements statement.

The stages shown here are targeted primarily at the evaluation of packaged software products, but a similar approach could also be used when evaluating custom-built software. The key message is to define what is required, compare available products, discard any that do not meet the mandatory requirements, and then choose the product based on how well it fulfils these requirements. Although cost is an important factor, you may not get the required functionality if you buy a tool because it is cheap, and it would therefore be a waste of money; conversely, most expensive does not necessarily mean best, and buying a tool that has facilities you will never use is also a waste of money.

Choosing the Preferred Option

Tools should be rejected if they fail to meet any of the mandatory requirements. When no tool achieves this, choose the best fit and reconsider how the remaining requirements might be fulfilled—possibly through customization or using additional tools. It is possible that the supplier might make the necessary changes.

When evaluating tools, a 100 percent fit to requirements is unlikely. Use the 80/20 rule. A tool is deemed to be fit for its purpose if it meets 80 percent or more of the business’s operational requirements. Whatever tool or type of tool is chosen, the fulfilment of the requirements may be achieved in different ways:

• Some products fulfil the requirement “out of the box” without further work being required.
• Sometimes the requirement can be fulfilled by configuring the tool. The configuration is preserved when the product is upgraded.
• Some tools require customization. Some of the issues to be considered when choosing such a tool include the following:
  • The customization would need to be repeated on every product upgrade.
  • Extensive customization of any product is best avoided because of the high costs incurred when the product is upgraded.
  • There is a risk that the tool may change so much in the future that the customization cannot be carried out on later releases.
  • Vendors may also refuse to support the customized product.
  • Finally, training in the tool would need to be bespoke because the implementation would be unique.

Other considerations when scoring the short-listed products include the background and experience of the vendor in the service management area. Some vendors specialize in service management; others just wish to add a service management tool to their suite of other tools. Are you confident that the supplier will still be supplying and supporting the product in five years? Carrying out the following actions will help you choose the right supplier:

• Consider the support offered. Try telephoning the supplier’s service desk to see how easy it is to get through, and ask some test questions to assess their technical competence.
• Arrange a visit to an organization with similar tool requirements to see the tool in use.
• Assess the training needs of your organization, and evaluate the capability of the supplier to provide the appropriate training.
• Confirm whether the integration with telephony or other tools has been carried out successfully elsewhere.

The tool that is finally selected should provide the following benefits:

• An 80 percent fit to all functional and technical requirements
• Meets all mandatory requirements
• Little (if any) product customization required
• Adherence of tool and supplier to service management best practice
• A sound data structure and handling
• Integration with other service management and operational management tools
• Support of open standards and interfaces
• Business-driven rather than technology-driven design
• Administration and maintenance costs within budget
• Acceptable levels of maintenance and release policies
• Security and integrity
• Availability of training and consultancy services
• Good report generation
• Scalability and growth

Implementation

Selecting the tool is just the start. Consideration should be given to its implementation. This includes populating the tool with data. The sources of this data need to be chosen: what, where, how and when? Timing is important to the testing, implementation, and go-live processes. Schedule the implementation when sufficient resources are available to ensure success.

Many organizations now choose to buy Software as a Service (SaaS) products. Several service management tools are available as a service. Using this approach means that hardware and software are not required because these products provide network-based access to and management of commercially available software. These types of products will still require planning and implementation, but the process should be simplified because no dedicated hardware is required.