Change Triggers

There are many events that can trigger a change in the service operation environment:

• There may be a requirement to install or upgrade hardware, network, or application software.
• Changes or upgrades to system software, such as operating systems and utilities, also need to be handled with care.
• Regular updates to software, including patches and bug fixes, are also changes that need to be managed because they have the potential to have a serious impact on the environment if not implemented carefully.
• Often, changes in operation are the result of external factors such as those resulting from legislation, the need to conform to an external standard, or new governance rules. For example, a change in legislation could mean that records of transactions need to be kept for a longer period, which would impact archiving and storage requirements.
• A common reason for change in the service operation stage is the replacement of obsolete hardware or software. These items may still be functioning correctly but are no longer supported by the supplier and may be incompatible with future releases of other components and, therefore, need to be replaced.
• Other triggers for change in service operation are those driven by the business, which may need IT to support a new business initiative, such as providing a “reserve and collect” facility through an e-commerce website.
• Processes and procedures should be subject to continual service improvement; each change that results from these initiatives must be implemented without any adverse consequences. The same is true for any service management tool, whether it is being upgraded or replaced.
• Changes in staff can also be potentially disruptive, and care needs to be taken to ensure that the necessary knowledge transfer takes place so the service provided is not affected.
• A requirement for a change in agreed service levels or a change in the sourcing model (outsourcing service provision, changing an outsourcer, or insourcing a service previously outsourced) will need to be planned to ensure that it is implemented smoothly.

Service transition would be responsible for planning these changes, but service operation has to be ready to absorb them without them disrupting the services provided.

Change Assessment

All changes have a potential impact on operations. This is not always understood by nonoperations staff, so it is essential that service operation staff have an opportunity to assess all changes. It is not sufficient to involve operations staff at the CAB stage because it may be too late; fundamental decisions regarding the design of the new or changed service will have been made far earlier. It is unrealistic to think that a redesign could happen at such a late stage. To prevent this, it is essential that operation staff are consulted and informed much earlier, during the initial design stage, and remain involved throughout.

It is good practice for the change manager to inform all affected parties of the changes being assessed so that affected areas (in this case, the service operation area) can prepare a response showing the operational impact of the change and setting out any concerns. This can be distributed prior to the CAB meeting to inform the discussion.

Service operation staff need to be involved throughout the design and implementation of a change with an operational impact. Early involvement is necessary to ensure that the design takes account of operational issues and requirements; involvement in the later stages is necessary to ensure that the change is scheduled to avoid potential disagreements or particularly sensitive periods.

Measurement of Successful Change

The ultimate measure of a successful change made to service operation is that there are no unexpected variations or outages; the only visible effects are the benefits that result from the change, such as enhanced functionality, quality, or financial savings.

Risks Resulting from Changes

A change might be implemented despite the existence of known errors that become apparent during testing but were not considered serious enough to delay the change. The existence of such known errors poses a risk to operational stability; until the errors are resolved, incidents resulting from them can recur. The impact of these incidents and the effectiveness of the appropriate workaround for each (including the speed at which it overcomes the fault) must be assessed. The results of this assessment will feed into the prioritization of the problem. Having a proven workaround mitigates the risk to a certain extent because, although the fault will occur when the service is operational and will therefore impact the business, a quick fix can reduce the impact of the incident.

Every incident, whether reported through the incident and problem processes, through a warning from the supplier, or by event management, will be assessed for impact and urgency to calculate its priority. This assessment is also an assessment of the risk it poses to the business. Finally, new projects that will result in delivery into the live environment are assessed because there is a risk that they may impact other services.

Other Sources of Risk

There are other risks to operational stability that would require a risk assessment. The first is an environmental risk. Environmental risks would include the sorts of risks that are assessed as part of IT service continuity planning, such as fire and flood. There may also be political and commercial risks and risks related to industrial relations. Examples of these are the risks faced by drug companies that carry out testing on animals and therefore may be subject to sabotage by those opposed to this practice, the risk of strikes affecting operation, or even the risk of a competitor engaging in a price war, which would drive down the income received.

Suppliers may also constitute a source of risk. Their failure to deliver could affect the delivery of the overall service. Their ability to provide a service might also be affected by their own internal risks. This is particularly a problem if they are the sole supplier for a particular element of the service. Taking on new suppliers also involves some risk; without a known track record of reliable delivery, there is a risk that their service may not be satisfactory. Another major area of risk involves security; security-related incidents or events may result in either theoretical or actual risks. Finally, every new customer or service to be supported is both an opportunity to be successful and a potential risk for failure.

Licenses

The first factor to be considered is the type of license. There are usually a number of options, at different costs. Where tools are licensed on a modular basis, careful planning is needed to ensure that the right access is obtained to enable people to carry out their work with no unnecessary modules being purchased. Here are some possible options:

• Dedicated licenses. For this option, each named person has their own license. Dedicated licenses are suitable for staff that require frequent and prolonged use of a particular module. For example, service desk staff would need a dedicated license to use an incident management module.
• Shared licenses. These licenses can be shared between individuals; there is, however, a possibility that a staff member may not be able to access the tool because the license is already in use. Shared licenses are suitable for regular users who do not require constant access, such as second-line support staff. Careful calculation is required to ascertain the correct ratio of users to licenses. These licenses are more expensive than dedicated licenses, but fewer are required.
• Web licenses. These allow access via a web browser. Web licenses are usually suitable for staff requiring remote access or only occasional access. They usually cost a lot less than other licenses (they may even be free with other licenses). It is possible to provide sufficient access for a large number of occasional users by purchasing a small number of such licenses, as the number of concurrent users and therefore the number of licenses required will be low. In this way overall costs can be reduced further.
• On demand. Access to tools is provided when required (on demand), and the supplier charges for the access based on the time spent using the application. This can be attractive to smaller organizations or if the tools in question are very specialized and used relatively infrequently. A variation to this is the use of a specialist tool as part of a consultancy assignment (e.g., specialist capacity management tools); in such cases, the license fees are likely to be included in the consultancy fee.
• Agent/activity. A further variation in license options is software that is licensed and charged on an agent/activity basis. An example of this is simulation software (e.g., agent software that can simulate customer paths through a website to assess and report upon performance and availability).

In all cases, it is essential than sufficient investigation has been done to ensure that the costs are understood and agreed and that the organization remains legal in respect to having sufficient licenses.

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 will need 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 Part 3 of this book, “Service Transition.”