Service Management tools
Tools will enable the Service Design processes to work more effectively. Tools will increase efficiency and effectiveness, and provide a wealth of management information, leading to the identification of weak areas. The longer-term benefits to be gained from the use of tools are cost savings and increased productivity, which in turn can lead to an increase in the quality of the IT service provision.
The use of tools will enable the centralization of key processes and the automation and integration of core Service Management processes. The raw data collected by the tools can be analysed, resulting in the identification of ‘trends’. Preventative measures can then be implemented, again improving the quality of the IT service provision.
Some points that organizations should consider when evaluating Service Management tools include:
Consideration must be given to the exact requirements for the tool. What are the mandatory requirements and what are the desired requirements? Generally the tool should support the processes, not the other way round, so minimize modification of the processes to fit the tool. Where possible, it is better to purchase a fully integrated tool (although not at the expense of efficiency and effectiveness) to underpin many (if not all) Service Management processes. If this is not possible, consideration must be given to the interfaces between the various tools.
It is essential to have a Statement of Requirements (SoR) for use during the selection process – this statement can be used as a ‘tick list’. The tool requirements should be categorized using the MoSCoW analysis:
The tool must be adequately flexible to support your required access rights. You must be able to determine who is permitted to access what data and for what purpose, e.g. read access to customers.
In the early stages, consideration must also be given to the platform on which the tool will be expected to operate – this may be on existing hardware and software or a new purchase. There may be restrictions laid down by IT strategy – for example, all new products may have to reside on specific servers. This might restrict which products could be included in the evaluation process. Make sure that the procurement fits within existing approved budgets.
There are many Service Management tools available. Details can be found on the internet, Service Management publications, from asking other organizations, from asking consultants or attending seminars and conferences to see what products are available.
During the early stages of the selection process, think about vendor and tool credibility. Are they still going to be supporting the purchase in a few months’ or a year’s time? Consider the past record of the supplier as well as that of the tool. Telephone the supplier’s Service Desk to see how easy it is to get through, and ask some test questions to assess their technical competence. Ask the vendor to arrange a visit to a reference site to see what the experience is with the tool in practice – if possible without the vendor or supplier present. Make sure that the organization has similar requirements of the tool. See the tool in operation and speak to the users about their experiences, both initially and ongoing.
Assess the training needs of the organization and evaluate the capability of the supplier to provide the appropriate training. Also the ongoing training and tool update (upgrades and changes in user requirements) will need to be assessed to ascertain the support and training costs. In particular, consider training costs, training location, time required, how soon after training the tool will be in use, and during the implementation project ensure that sufficient training is provided – think about how the new tool will impact both IT and customer. Also ensure that interfaces with other tools and telephony are functioning correctly. It is wise to identify whether the planned combination has been used (or tried) elsewhere and with what results. Consider periods of parallel running alongside existing solutions before finally going live.
When evaluating tools, a 100% fit to requirements should not be expected and will almost certainly not be found. The ‘80/20 rule’ should be brought into effect instead. A tool is deemed to be fit for its purpose if it meets 80% or more of the business’s operational requirements. Those operational requirements should be categorized as discussed earlier.
Any product should be rejected as unsuitable if not all of the mandatory requirements (‘must haves’) are met. In some circumstances, it will be impossible to find an existing software product that will either meet all of the mandatory requirements or provide an 80% match. In this situation, the product offering the best functional design should be selected and the unsuitable elements re-written. This enhancement process should be done by the vendor if at all possible. In some cases, part of the enhancement costs may be met by the purchaser. Some products have been designed to include user hooks – this provides accessibility to site-written code at key procedural points, without the need for the package to be modified.
It doesn’t end when the product has been selected. In many ways this could be considered as only the beginning. The tool now has to be implemented. Once the hardware platform has been prepared and the software loaded, data population needs to be considered. What, where from, how and when? Timing is important to the testing, implementation and the go-live processes. Resources must be available to ensure success. In other words, don’t schedule implementation during a known busy period, such as year-end processing. Today ‘software as a service’ products are available where hardware and software are not required. These products give network-based access to and management of commercially available software. These types of products will still require planning and implementation, but this should simplify the process as no dedicated hardware is required.
Consideration should also be given to managed service providers and Application Service Providers who may be able to provide the same functionality.
Whatever tool or type of tool is chosen, the fulfilment of the requirements can be differentiated between:
Extensive customization of any product is always best avoided because of the high costs incurred at product upgrade. Vendors may be unwilling to support old releases, and purchasers may be unable to resource the necessary re-application of any bespoke customization. Customization may also release the vendor from much of their support obligations – this would be disastrous if, as a result, your Service Management system is unavailable for any length of time. Further costs would be incurred in providing the bespoke training that would be required. It would be impossible to take advantage of any cheap scheduled training courses being run by the software supplier.
The process of tool evaluation is shown in Figure 7.1.