Service Operations

8. Implementing Service Operations

It should be noted that Service Operation is a phase in a lifecycle and not an entity in its own right. By the time a service, process, organization structure or technology is operating, it has already been implemented. However, there are a number of processes and functions described in this publication, and it is therefore important to address the implementation considerations which should have been addressed by the time they come into operation. A number of these have been covered in the relevant section - for example guidance is given about organization structures and roles in Chapter 6. This will not be repeated here. Rather, this section will focus on some generic implementation guidance for Service Operation as a whole.

8.1 Managing Change In Service Operation

Service Operation should strive to achieve stability - but not stagnation! There are many valid and advantageous reasons why 'change is a good thing' - but Service Operation staff must ensure that any changes are absorbed without adverse impact upon the stability of the IT services being offered.

8.1.1 Change Triggers

There are many things that may trigger a change in the Service Operation environment. These include:

New or upgraded hardware or network components
New or upgraded applications software
New or upgraded system software (operating systems, utilities, middleware etc. including patches and bug fixes
Legislative, conformance or governance changes
Obsolescence - some components may become obsolete and require replacement or cease to be supported by the supplier/maintainer
Business imperative - you have to be flexible to work in ITSM, particularly during Service Operation, and there will be many occasions when the business needs IT changes to meet dynamic business requirements
Enhancements to processes, procedures and/or underpinning tools to improve IT delivery or reduce financial costs
Changes of management or personnel (ranging from loss or transfer of individuals right through to major take-overs or acquisitions)
Change of service levels or in service provision - outsourcing, in-sourcing, partnerships, etc.

8.1.2 Change Assessment

Service Operation staff must be involved in the assessment of all changes to ensure that operational issues are fully taken into account. This involvement should commence as soon as possible (see paragraph 4.6.1) not just at the later stages of change - i.e. CAB and eCAB membership - by which time many fundamental decisions will have been made and influence is likely to be very limited. The Change Manager should inform all affected parties of the change being assessed so input can be prepared and available prior to CAB meetings.

However, it is important that Service Operation staff are involved at these latter stages as they may be involved in the actual implementation and they will wish to ensure that careful scheduling takes place to avoid potential contentions or particularly sensitive periods.

8.1.3 Measurement of Successful Change

The ultimate measure of success in respect of changes made to Service Operation is that customers and users do not experience any variation or outage of service. So far as possible, the effects of changes should be invisible, apart from any enhanced functionality, quality or financial savings resulting from the change.

8.2 Service Operation And Project Management

Because Service Operation is generally viewed as 'business as usual' and often focused on executing defined procedures in a standard way, there is a tendency not to use Project Management processes when they would in fact be appropriate. For example, major infrastructure upgrades, or the deployment of new or changed procedures, are significant tasks where formal Project Management can be used to improve control and manage costs/resources.

Using Project Management to manage these types of activity would have the following benefits: The project benefits are clearly stated and agreed

There is more visibility of what is being done and ho it is being managed, which makes it easier for other IT groups and the business to quantify the contributions made by operational teams
This in turn makes it easier to obtain funding for projects that have traditionally been difficult to cost justify
Greater consistency and improved quality
Achievement of objectives results in higher credibility for operational groups.

8.3 Assessing And Managing Risk In Service Operation

There will be a number of occasions where it is imperative that risk assessment to Service Operation is quickly undertaken and acted upon.

The most obvious area is in assessing the risk of potential changes or Known Errors (already covered elsewhere) but in addition Service Operation staff may need to be involved in assessing the risk and impact of:

Failures, or potential failures - either reported by Event Management or Incident/Problem Management, or warnings raised by manufacturers, suppliers or contractors
New projects that will ultimately result in delivery into the live environment
Environmental risk (encompassing IT Service Continuity-type risks to the physical environment and locale as well as political, commercial or industrialrelations related risks)
Suppliers, particularly where new suppliers are involved or where key service components are under the control of third parties
Security risks - both theoretical or actual arising from security related incidents or events
New customers/services to be supported.

8.4 Operational Staff In Service Design And Transition ^N

All IT groups will be involved during Service Design and Service transition to ensure that new components or service are designed, tested and implemented to provide the correct levels of functionality, usability, availability, capacity, etc. Additionally, Service Operation staff must be involved during the early stages of Service Design and Service Transition to ensure that when new services reach the live environment they are fit for purpose, from a Service Operation perspective, and are 'supportable' in the future.

In this context, 'supportable' means:

Capable of being supported from a technical and operational viewpoint from within existing, or preagreed additional resources and skills levels
Without adverse impact on other existing technical or operational working practices, processes or schedules
Without any unexpected operational costs or ongoing or escalating support expenditure
Without any unexpected contractual or legal complications
No complex support paths between multiple support departments of third-party organizations.

8.5 Planning And Implementing Service Management Technologies

There are a number of factors that organizations need to plan for in readiness for, and during deployment and implementation of, ITSM support tools. These include the following.

8.5.1 Licences

The overall cost of ITSM tools, particularly the integrated tool that will form the heart of the required toolset, is usually determined by the number and type of user licences that the organization needs.

Such tools are often sold in modular format, so the exact functionality of each module needs to be well understood and some initial sizing must be conducted to determine how many - and what type - of users will need access to each module. Licences are often available in the following types (the exact terminology may vary depending upon the software supplier).

8.5.1.1 Dedicated Licences

For use by those staff that requires frequent and prolonged use of the module (e.g. Service Desk staff would need a dedicated licence to use an Incident Management module).

8.5.1.2 Shared Licences

For staff who make fairly regular use of the module, but with significant intervals in between, so can usually manage with a shared licence (e.g. third-line support staff may need regular access to an Incident Management module - but only at times when they are actively updating an incident record). The ratio of required licences to users needs to be estimated, so the correct number of licences can be purchased - this will depend upon the number of potential users, the length of periods of use and the expected frequency between usages to give an estimated concurrency level.

The cost of a shared licence is usually more expensive than that of dedicated licences - but the overall cost is less as users are sharing and fewer licences are therefore needed in total.

8.5.1.3 Web Licences

Usually allowing some form of 'light interface' via web access to the tool's capabilities, this is usually suitable for staff requiring remote access, only occasional access, or usage of just a small subset of the functionality (e.g. engineering staff wishing to log details of actions taken on incidents or users just wanting to log an incident directly). Web licences usually cost a lot less than other licences^N (may even be free with other licences!) and the ratio of use is also often lower - so overall costs are reduced further^N.

8.5.1.4 Service on Demand

There has been a trend within the IT industry for suppliers to offer IT applications 'on demand', where access is given to the application for a period of demand and then severed when it is no longer needed - and charged on the basis of the time spent using the application. This type of offering mad be-offered by some ITSM tool suppliers - which could be attractive to smaller organizations or if the tools in question are very specialized and used relatively infrequently.

An alternative to this is where the use of a tool is offered as part of a specific consultancy assignment (e.g. a specialist Capacity Management consultancy, say, who may offer a regular but relatively infrequent Capacity Planning consultancy package and provide use of the tools for the duration of the assignment). In such cases the licence fees are likely to be included as part of, or as an addendum to, the consultancy fee.

A further variation is where software is licensed and charged on an agent/activity basis. An example of this is interrogation/monitoring and/or simulation software (e.g. agent software that can simulate pre-defined customer paths through an organization's website, to assess and report upon performance and availability). Such software is typically charged on the basis of the number of agents, their location and/or the amount of activity generated.

In all cases, full investigations of the licensing structure must be investigated and well understood during the procurement investigations and well before tools are deployed - so that the ultimate costs do not come as any sort of surprise.

8.5.2 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 (see Service Transition publication).

Even where network deployment is possible, this needs careful scheduling and testing - and records must be maintained throughout the rollout so that support staff have knowledge of who has been upgraded and who has not. Some form of interim Change Management may be necessary and the CMS should be updated as the roll-out progresses.

It is often necessary for a reboot of the devices for the client software to be recognized - and this needs to be arranged in advance, otherwise long delays can occur if staff do not generally switch off their desktops overnight.

There may be particular problems deploying to laptops and other portable equipment and special arrangements may be necessary for staff to log on and receive the new software.

8.5.3 Capacity Checks

Some Capacity Management may be necessary in advance to ensure that all of the target locations have sufficient storage and processing capacity to host and run the new software - any that cannot will need upgrading or replacing, and lead times for these actions need to be included in the plans.

The capacity of the network should also be checked to establish whether it can handle the transmission of management information, the transmission of log files and the distribution of clients' and also possibly software and configuration files.

8.5.4 Timing of Technology Deployment

Care is needed to ensure that tools are deployed at the appropriate time in relation to the organization's level of ITSM sophistication and knowledge. If tools are deployed too soon, they may be seen as an immediate panacea and any necessary action to change processes, working practices or attitudes may be hindered or overlooked.

A tool alone is usually not enough to make things work better. There is an old adage: 'A fool with a tool is still a fool!' The organization must first examine the processes that the tool is seeking to address and also ensure that staff are 'bought in' to the new processes and way of working and have a adopted a 'service culture'.

However, tools can and often do make things a reality for many people - they are tangible and technical staff can immediately see how the new processes can work and how they may improve their way of working.

Some processes just cannot be done without adequate tooling, so there is a careful balance to be made to ensure tools are introduced when they are needed - but not before!

Similarly, care is needed to ensure that training in any tools is provided at the correct point - not too early or knowledge will diminish or be lost, but early enough so that staff can be formally trained and fully familiarize themselves with the operation of the tools well in advance of live deployment. Additional training should be planned for an additional period when the tools go live and into the future, as needed.

8.5.5 Type of Introduction

A decision is needed on what type of introduction is needed - whether to go for a 'Big Bang' introduction or some sort of phased approach. As most organizations will not start from a 'green field' situation, and will have live services to keep running during the introduction, a phased approach is more likely to be necessary.

In many cases a new tool will be replacing an older, probably less sophisticated, tool and the switch-over between the two is another factor to be planned.

This will often involve deciding what data needs to be carried forward from the old tool to the new one - and this may require significant reformatting to achieve the required results. Ideally this transfer should be done electronically - but in some cases a small amount of rekeying of live data may be inevitable and should be factored into the plans. Caution: older tools generally relied on more manual entry and maintenance of data so if electronic data migration is being used, an audit should be performed to verify data quality.

Where data transfer is complicated or time consuming to achieve, an alternative might be to allow a period of parallel running - with the old tool being available for an initial period alongside the new one, so that historical data can be referenced if needed. In such cases it will be prudent to make the old tool 'read-only' so that no mistakes can be made by logging new data in the old tool.

Complete details on the Release and Deployment Management process can be found in the Service Transition publication.