Business Impact Analysis

One of the key inputs for understanding business needs, impacts, and risks is the output from a business impact analysis (BIA). BIA is used in a number of service design processes, particularly IT service continuity management (see Chapter 9, “IT Service Continuity Management and Demand Management”), where it is essential to help define the strategy for risk reduction and service continuity, BIA is normally used to identify the effect a disaster will have on the business, on both individual sections and the business as a whole. It is used to identify the criticality of any particular business process or activity, and will also be used to identify the times when this will particularly affect the business. BIA is also used for other processes—for example, availability management, capacity management, and information security management.

There are two areas of BIA. One is for business management, which involves understanding the impact of loss on a business process or function. The second is to understand the BIA from the perspective of service loss. Both of these should be applied to identify the critical services and determine what constitutes a major incident on the services when a new service is being designed. BIA will also help in defining the acceptable level and duration of service outage, including the important periods to avoid. In addition, BIA can assist with the understanding of financial loss and any security issues.

Service Level Requirements

As part of the service level management process (see Chapter 18, “Service Level Management and Supplier Management”), service level requirements for all services will be identified and the ability to deliver against the requirements will be assessed and defined in the service level agreements. This needs to be part of the approach to the design of services, and all processes in service offerings and agreements will need to be considered as part of the requirements capture.

Risks to the Services and Processes

It is important to ensure that business-as-usual processes are not adversely impacted by the implementation of the service offerings and agreements processes. This factor should be considered as part of the risk assessment during design, and will then be explored more fully during the transition lifecycle stage. Risk assessment and management form a key part of the service offerings and agreements processes—for example, service level management and supplier management. Any solution created during service design must take risks into consideration.

Implementing Service Design

The process, policy, and architecture for the design of IT services will need to be documented and utilized to ensure that the appropriate services are provided to the business.

We recommend that service design follow the continual service improvement approach and base the designs on the business requirements:

• Where do we start?
• How do we improve—the CSI approach:
  • What is the vision?
  • Where are we now?
  • Where do we want to be?
  • How do we get there?
  • Did we get there?
  • How do we keep the momentum going?

Challenges, Critical Success Factors, and Risks

When we consider the relationship between implementing good practices, and service offerings and agreements processes, it is important to be aware of the challenges, CSFs, and risks associated with the implementation.

Challenges

Challenges will take many different forms, depending on the nature of the organization supported. Some common factors are applicable to most organizations in some aspect. These include

• Understanding business requirements and priorities
• Understanding organizational culture
• Effective communication to the business and service management staff
• Collaboration and engagement with all stakeholders
• Gaining commitment from management and staff
• Supplier management and contractual obligations
• Cost and budgetary constraints

These are common to most organizations, and the meeting of these challenges will be critical to the success of implementation of service management processes, including those for service offerings and agreements.

Critical Success Factors

As you are aware, critical success factor (CSF) is a term used for an element that is necessary for an organization or project to achieve its mission. CSFs can be used to identify the important elements of success. These are measured by key performance indicators (KPIs) and should be set and measured as part of the service design lifecycle stage. The SOA processes will be critical in establishing the service requirements, and understanding the CSFs for each of the processes will provide a strong basis for the KPIs, which will be used to demonstrate success in the service lifecycle stage.

Risks

As with challenges, some common risks are applicable to most organizations. These need to be appropriately identified and addressed to ensure successful service management implementation. Some examples are

• Meeting the identified CSFs
• Maturity of process
• Unclear business requirements
• Unrealistic business timeframes for service management design, transition, and operation
• Insufficient testing
• Lack of balance in focus on innovation or stability
• Lack of coordination between business, IT, and suppliers
• Insufficient resources, including cost and budget
• Lack of a holistic approach across the whole service management lifecycle

Service Management Tool Choice

Many service management tools are 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 (see Figure 20.1).

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 the 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 that are not essential.
• Could have requirements are useful but not hugely important.
• And Would like in the future requirements are those that we don’t need right now but will need in the 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.

Planning and Implementing Service Management Technologies

The final topic of this chapter is service management tools. A good service management tool can be helpful for implementing processes based on the ITIL framework, but the tool should not define the process. Many organizations implement new tools to assist their implementation of new or improved processes. These organizations need to consider a number of factors if the new tool is to be helpful and appropriate.

Deployment

Many ITSM tools, particularly discovery and event monitoring tools, will require some client/agent software deploying to all target locations before they can be used. This deployment will require careful planning and execution and should be handled through formal release and deployment management. Some deployment considerations are listed here:

• There should be careful scheduling and testing, and the deployment must be tracked so that it is clear which CIs have the software and which have yet to receive it.
• The CMS should be updated as the deployment progresses.
• It is often necessary to reboot devices for the client software to be recognized, and this needs to be arranged in advance to minimize service interruption.
• Special arrangements may be needed for portable equipment, which may not be present on site during deployment.
• The devices receiving the software must be checked in advance to ensure that they have sufficient storage and processing capacity to host and run the new software.
• The network capacity needs to be checked to ensure that it is capable of transmitting everything required.
• The best time to deploy a tool is dependent on the maturity level. A tool that is deployed too early shifts the focus of the improvement initiative away from the requirement to change processes and ways of working, and the whole improvement exercise then becomes merely a tool implementation.
• Training in the tool prior to deployment is necessary if benefits are to be realized.

Remember, a tool is usually not enough to make things work better. However, if it supports processes and the user has been trained to use it, a good tool can help staff carry out new processes.

Here are some further aspects of the deployment that must be considered:

The Type of Introduction to Be Used A decision must be made whether a “Big Bang” introduction or some sort of phased approach is to be adopted. Because most organizations will have live services to keep running during the introduction, a phased approach is more likely to be necessary.

Transition between Tools If an older tool is being replaced, consideration must be given to the best way to transition between the old tool and the new tool. For example, the service desk should not be assigning an incident on a new tool to a team that has yet to transition from the old tool.

Data Migration A decision needs to be made regarding what data needs to be migrated from the old tool to the new one. This may require reformatting, and so may need to be validated after migration, especially if the data is transferred electronically. A period of parallel running may be implemented instead, with the old tool being available in a read-only mode for an initial period alongside the new one so that historical data can be referenced if needed.

Complete details on the release and deployment management process can be found in the ITIL Service Transition publication.