Service Design

1Introduction 2Serv. Mgmt. 3Principles 4Processes 5Tech Activities 6Organization 7Tech Considerations 8Implementation 9Challenges Appendeces

7. Technology Considerations

7.1Design Tools 7.2Mgmt Tools

It is generally recognized that the use of Service Management tools is essential for the success of all but the very smallest process implementations. However, it is important that the tool being used supports the processes - not the other way around. As a general rule, don't modify processes to fit the tool. However, with the use of tools to support processes, there is a need to be pragmatic and recognize that there may not be a tool that supports the designed process totally, so an element of process re-design may be necessary. Don't limit the requirements to functionality: consider the product's ability to perform, enlarge the size of the databases, recover from failure and maintain data integrity. Does the product conform to international standards? Is it efficient enough to enable you to meet your Service Management Requirements?

Often organizations believe that by purchasing or developing a tool all their problems will be solved, and it is easy to forget that we are still dependent on the process, the function and, most importantly, the people. Remember:

'a fool with a tool is still a fool'

[To top of Page]

7.1 Service Design Tools

There are many tools and techniques that can be used to assist with the design of services and their associated components. These tools and techniques enable:

The tools and techniques are many and varied, including both proprietary and non-proprietary, and are useful in:

Developing Service Designs can be simplified by the use of tools that provide graphical views of the service and its constituent components, from the business processes, through the service and SLA to the infrastructure, environment, data and applications, processes, OLAs, teams, contracts and suppliers. Some Configuration Management tools provide such facilities, and are sometimes referred to as an element of Business Service Management (BSM) tools. They can contain or be linked to 'auto-discovery' tools and mechanisms and allow the relationships between all of these elements to be graphically represented, providing the ability to drill down within each component and obtain detailed information if needed.

If these types of tool also contain financial information, and are then linked to a 'Metrics Tree' providing KPIs and metrics of the various aspects of the service, then the service can be monitored and managed through all stages of its lifecycle. Sharing this single, centralized set of service information allows everybody in the service provider organization and the business to access a single, consistent, 'real-world' view of the service and its performance, and provides a solid base for the development of good relationships and partnerships between the service provider and its customers.

These types of tools not only facilitate the design processes, but also greatly support and assist all stages in the Service Lifecycle, including:

The following generic activities will be needed to implement such an approach:

For the applications asset type, additionally:

For the data/information asset type, additionally:

Ensure that data designs are undertaken in the light of:

For the IT infrastructure and environmental asset type, additionally:

For the skills (people, competencies), additionally:

In addition, in order to establish effective interfaces and dependencies:

[To top of Page]

7.2 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 analyzed, 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:

M - MUST have this
S - SHOULD have this if at all possible
C - COULD have this if it does not affect anything else
W - WON'T have this time but WOULD like in the future.

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 fulfillment 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.

Figure 7.1 Service Management tool evaluation process
Figure 7.1 Service Management tool evaluation process

The process of tool evaluation is shown in Figure 7.1. It shows the standard approach of identifying requirements before identifying products, but pragmatically there may be some element of overlap, where exploration of tools on the market opens one's eyes to new options that change the requirements. These stages are targeted primarily at the evaluation of packaged software products, but a similar approach could also be used when evaluating custom-built software. Produce a clear Statement of Requirements (SoR) that identifies the .business requirements together with the mandatory facilities and those features that it would be 'nice to have'. Also identify the site policies and standards to which the product must conform. Such standards may include it running under particular system software, or on specific hardware.

Remember the considerations about the supplier's suitability, and carry out a formal evaluation of the products under consideration.

If well-developed and appropriate tools are used to support the processes, the results achieved will be far greater and often the overall costs of service provision will be less. Selecting the right tool means paying attention to a number of issues:

[To top of Page]


Visit my web site