9Technology and implementation

9.1GENERIC REQUIREMENTS FOR IT SERVICE MANAGEMENT TECHNOLOGY (SO 7.1)

The same technology should be used at all stages of the service lifecycle. Generally this includes:

• Self-help A web front end offering a menu-driven range of self-help and service requests. It should have a direct interface with the process-handling software at the back end
• Workflow or process engine To allow predefinition and control of defined processes such as incident lifecycle, request fulfilment lifecycle and change models. It should allow predefinition and management of responsibilities, activities, timescales, escalation paths and alerting
• Integrated configuration management system (CMS) To manage information about all the organization’s IT infrastructure and other CIs, together with required attributes and relationships. It should support links, for example, to incidents, problems, known errors, change records and release records
• Discovery, deployment and licensing technology To populate or verify CMS data and assist in licence management. It can often also be used to deploy software, ideally with an interface to self-help
• Remote control To enable support personnel to take control of users’ desktops to conduct investigations or correct settings. It must include appropriate security controls
• Diagnostic utilities Including scripts and case-based reasoning tools. Ideally it should present automated context-sensitive scripts
• Reporting Tools should include good reporting capabilities and a means for providing data to industry-standard reporting packages and dashboards
• Dashboards To provide ‘at a glance’ visibility of overall IT service performance. Displays can also be included in management reports. Dynamic, customized web-based views can be very useful
• Integration with business service management To allow combined views of ITSM and business-related IT.

9.2EVALUATION CRITERIA FOR TECHNOLOGY AND TOOLS (SD 7.2)

Some generic points that organizations should consider when selecting any service management tool include:

• Data handling, integration, import, export and conversion
• Data backup, control and security
• Ability to integrate multi-vendor components, existing and into the future
• Conformity with international open standards
• Usability, scalability and flexibility of implementation and usage
• Support options provided by the vendor, and credibility of the vendor and tool
• The platform the tool will run on and how this fits the IT strategy
• Training and other requirements for customizing, deploying and using the tool
• Costs: initial and ongoing.

It is generally best to select a fully integrated tool, but this must support the processes used by the organization, and extensive tool customization should be avoided.

Consideration should also be given to the organization’s exact requirements. These should be documented in a statement of requirements. Tool requirements should be categorized using 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, but WOULD like in the future.

Each proposed tool can be evaluated against these criteria to ensure that the most appropriate option is selected.

9.3EVALUATION CRITERIA FOR TECHNOLOGY AND TOOLS FOR PROCESS IMPLEMENTATION

9.3.1Event management (SO 7.2)

Event management technology should have the following features:

• A multi-environmental, open interface to:
  • Allow monitoring and alerting across heterogeneous services and the entire IT infrastructure
  • Accept any standard (e.g. simple network management protocol) event input and generation of multiple alerting
• ‘Standard’ agents to monitor the most common environments, components and systems
• Configurable and programmable functionality to support correlation, assessment and handling of alerts, manipulation and routing of events (centralized or local)
• Capability to suppress or flag events during periods of scheduled outages
• Capability to allow an operator to acknowledge an alert, and if no response is entered within a defined timeframe, to escalate the alert
• Good reporting functionality.

Technology should allow a direct interface into the organization’s incident management and escalation processes to support staff, third-party suppliers and engineers.

9.3.2Incident management (SO 7.3)

Integrated ITSM technology should have the following features:

• Incident-logging capabilities that allow for efficient entry of incident data, categorization, prioritization, tracking and reporting of incidents
• An integral CMS to allow automated relationships to be made and maintained and used to assist in prioritization, investigation and diagnosis
• A process flow engine to allow processes to be predefined and automatically controlled
• Automated alerting and escalation capabilities
• A web interface to allow self-help and service requests to be input via internet or intranet screens
• An integrated known error database (KEDB)
• Easy-to-use reporting facilities
• Diagnostic tools.

Note that target times should be included in the support tools that are used to automate the workflow control and escalation paths.

9.3.3Request fulfilment (SO 7.4)

Integrated ITSM technology is needed so that service requests can be linked to related incidents or events.

Some organizations may use the incident management element of ITSM tools and treat service requests as a subset and defined category of incidents. Request fulfilment technology should have the following capabilities:

• Front-end self-help capabilities To allow users to submit requests via some form of web-based, menu-driven selection process which may be integrated with an IT service catalogue and access controls to validate service requesters prior to fulfilment
• Workflow engine capabilities To automate work steps and authorization tasks for supporting service request models and fulfilment activities.

Otherwise the facilities required are very similar to those for managing incidents and changes: for example, predefined workflow control of models, priority levels, automated escalation and effective reporting.

9.3.4Problem management (SO 7.5)

Problem management should have the following features:

• An integrated ITSM tool that differentiates between incidents and problems
• Integration with change management. This is very important, so that request, event, incident and problem records can be related to the requests for change (RFCs) that have caused problems
• Integration with the CMS. This is needed to allow problem records to be linked to the components affected and the services. Service asset and configuration management forms part of a larger service knowledge management system (SKMS) which includes linkages to many of the data repositories used in service operation
• An effective KEDB. This is an essential requirement to allow easy storage and retrieval of known error data
• Good reporting facilities.

Note that in some cases the components or systems that are being investigated by problem management may have been provided by third-party vendors or manufacturers. Therefore, vendors’ support tools and/or KEDBs may also need to be used.

9.3.5Access management (SO 7.6)

Access management uses a variety of technologies, including:

• Human resource management technology, to authenticate the identity of users, authorize their access, and track their status
• Directory services technology to enable technology managers to assign names to resources on a network and then provide access to those resources based on the profile of the user.
  Directory services tools also enable access management to create roles and groups and to link these to both users and resources
• Access management features in applications, middleware, operating systems and network operating systems
• Change management systems
• Request fulfilment technology.

9.3.6Service desk (SO 7.7)

Telephony systems used by the service desk should include:

• An automatic call distribution system to allow group pick-up capabilities from a single telephone number
• Computer telephony integration software to allow caller recognition and the incident record from the CMS to be automatically updated with the user’s details
• Voice-over internet protocol, which can reduce telephony costs
• Statistical software to allow telephony statistics to be gathered and analysed:
  • Number of calls received, in total and broken down by any ‘splits’
  • Call arrival profiles and answer times
  • Call abandon rates
  • Call handling rates by individual service desk call handlers
  • Average call durations
• Hands-free headsets, with dual-user access capabilities for use, for example, during training of new staff.

The following support tools will be particularly beneficial for use by the service desk:

• An integrated KEDB to store details of previous incidents, problems, workarounds, root causes and their resolutions
• Functionality to categorize and quickly retrieve previous known errors, using pattern matching and keyword searching against symptoms
• Multi-level diagnostic scripts to allow service desk staff to pinpoint the cause of failures. These context-sensitive scripts appear on screens, dependent upon the multi-level categorization of the incident, and are driven by the user’s answers to diagnostic questions
• Automated ‘self-help’ functionality so users can seek and obtain help to resolve their own difficulties. Ideally this should be a 24/7 web interface driven by menu selection: for example, frequently asked questions; ‘how to do’ search capabilities; password change or software repairs and fixes. Self-help may also include allowing users to log incidents themselves
• Remote control of the user’s desktop to allow service desk analysts to conduct investigations or correct settings
• Appropriate IT service continuity and resilience levels.

9.4PRACTICES FOR PROCESS IMPLEMENTATION

9.4.1Service operation and project management (SO 8.2)

It is important that all projects make use of project management processes. Many organizations treat service operation as ‘business as usual’ and do not use project management for activities such as major infrastructure upgrades or deployment of new or changed procedures.

Using project management processes can bring the following benefits:

• Project benefits are agreed and documented
• It is easier to see what is being done and how it is being managed
• Funding can be easier to obtain
• There is greater consistency and improved quality
• Objectives are more likely to be achieved, leading to higher credibility for operational groups.

9.4.2Assessing and managing risk in service operation (SO 8.3)

Risk assessment and management is required throughout the service lifecycle. There are occasions, such as the following, when assessment of risk to service operation must be carried out and acted on very quickly:

• Risks from potential changes or known errors
• Failures or potential failures: these may be identified by event management, incident management or problem management, but also by warnings from manufacturers, suppliers or contractors
• Environmental risks: risks to the physical environment as well as political, commercial or industrial relations risks, which could lead to invoking IT service continuity
• Suppliers, particularly if they control key service components
• Security risks
• Support of new customers or services.

9.4.3Operational staff in service design and transition (SO 8.4)

Activities during service design and service transition should involve staff from all IT groups to ensure that new components and services are designed, tested and implemented in a way that will provide the service utility and service warranty required.

Service operation staff must be involved during the early stages of design and transition to ensure that new services are fit for purpose from an operational perspective and supportable in the future. This will mean that:

• Services are capable of being supported from a technical and operational viewpoint with existing (or agreed additional) resources and skills
• There is no adverse impact on other practices, processes or schedules
• There are no unexpected operational costs
• There are no unexpected contractual or legal complications
• There are no complex support paths with multiple support departments or third parties.

Planning changes, and implementing them, does not involve technology alone. Thought must be given to awareness, cultural change, motivation and many other issues.

9.5CHALLENGES, CRITICAL SUCCESS FACTORS AND RISKS RELATING TO IMPLEMENTING PRACTICES AND PROCESSES

9.5.1Challenges (ST 9.1, SO 9.1, SD 9.1)

There are a number of challenges faced within service operation that need to be overcome. These include:

• Lack of engagement with development and project staff. While it is good to have segregation of duties, involving service operations staff at the outset of development projects is good for both teams
• Justifying funding: while it is often difficult to justify expenditure in the area of service operation, in reality, such an investment can show a positive return on investment and improvement in service quality; for example, reduced software licence costs and reduced support costs due to fewer incidents
• Challenges for service operation managers, such as differing perspectives of projects and operations, ineffective transitions and managing virtual teams
• Unreasonable targets and timescales, as previously agreed in the SLAs and OLAs
• Normal daily operation or business as usual not having been considered as part of the design
• Poor supplier management and/or poor supplier performance
• Achieving a balance between maintaining a stable production environment and being responsive to the business needs for changing the services
• Insufficient knowledge transfer and training during service transition.

9.5.2Critical success factors (SD 9.3, ST 9.2, SO 9.2)

CSFs to consider include:

• Management support Senior and middle management support is needed for all ITSM activities and processes, particularly in service operation; for example, for funding and resourcing, for new initiatives and for empowerment of middle managers
• Business support Regular communications with the business to understand its concerns and aspirations and to give feedback on efforts to meet its needs are essential in building the correct relationships and ensuring ongoing support
• Champions ITSM projects and the resulting service operation are more successful if there are ‘champions’ who lead and encourage others with their enthusiasm and commitment. These champions are usually senior managers, but successful champions can also come from other parts of the organization
• Staffing and retention Having the appropriate number of staff with the appropriate skills is critical to the success of service operation. Challenges include lack of staff with an understanding of service management, difficulty of retaining staff and workload management
• Service management training In addition to generic service management training, staff should be trained on:
  • The organization’s own processes that have been implemented
  • People skills, especially for those in customer-facing positions
  • Understanding the business and the required service culture
  • Service management tools
• Suitable tools Many service operation processes and activities cannot be performed effectively without adequate support tools. Senior management must provide funding for procurement, deployment and ongoing maintenance of these
• Validity of testing The quality of IT services provided is dependent upon the quality of systems and components delivered to the operational environment, requiring adequate and complete testing of new components and releases and documentation testing for completeness and quality
• Measurement and reporting Clear definitions of how things will be measured and reported will provide staff with targets to aim for and allow IT and business managers to review progress and identify opportunities for improvement.

Other CSFs include defining clear accountabilities, roles and responsibilities, establishing a culture that enables knowledge to be shared freely and willingly, demonstrating continual improvements and improved customer and user satisfaction ratings.

9.5.3Risks (ST 9.3, SO 9.3, SD 9.2)

In addition to not meeting the challenges and not addressing the CSFs above, other risks are:

• Service loss: the ultimate risk to the business of weaknesses in service operation is the loss of critical IT services with subsequent adverse impact on employees, customers and finances
• Resistance to change and circumvention of the processes due to perceived bureaucracy
• Lack of maturity and integration of systems and tools, resulting in people ‘blaming’ technology for other shortcomings
• Poor integration between the processes, causing process isolation and a silo approach to delivering ITSM.

Additional risks to successful service operation include inadequate funding and resources, loss of key personnel, faulty initial design and differing customer expectations.

9.6PLANNING AND IMPLEMENTING SERVICE MANAGEMENT TECHNOLOGIES (SO 8.5)

There are a number of factors to consider when deploying and implementing ITSM support tools:

• Licences The cost of service management tools is usually determined by the type and number of user licences needed. Most tools are modular, so the specific selection of modules also affects the price. It is important to plan the provision of licences to avoid unexpected costs. There are a number of different licence types:
  • Dedicated licences For staff who need frequent and prolonged use of the module (e.g. service desk staff)
  • Shared licences For staff who use the module regularly, but with significant times when it is not needed. The ratio of licences to users should be calculated to give sufficient use at acceptable cost
  • Web licences For staff who need occasional access, or remote access, or who only need limited functionality
  • Service on demand The charge is based on the number of hours the service is used. This is suitable for smaller organizations or very specialized tools that are not used often. It can also include tools licensed as part of a consulting exercise (e.g. for carrying out capacity modelling)
• Deployment Many tools, especially discovery and event-monitoring tools, require deployment of clients or agents. This requires careful scheduling, planning and execution and should be subject to formal release and deployment management. Devices may need to be rebooted and this needs to be planned. Change management is used and the CMS updated. Particular care should be taken when planning deployment to laptops and other portable equipment that may not be connected all the time
• Capacity checks It may be necessary to check for sufficient system resources (e.g. disk space, CPU, memory) when planning a deployment. Allow sufficient lead time for upgrading or replacing equipment, and check network capacity
• Timing of technology deployment If tools are deployed too early, they can be seen as ‘the solution’ on their own and essential process improvements will not be carried out. If tools are deployed too late, it can be hard to implement the new process. People need to be trained in use of the tool as well as the new or updated process, and timing for this must be planned, possibly with additional training after the tools have gone live
• Type of introduction The new tool often replaces an existing tool, and careful planning is needed for the transition. A phased approach can be more appropriate than a ‘big bang’ approach, but this depends on the exact circumstances. The key factor is planning what data needs to be migrated, and how. If data is being migrated, a data quality audit should be performed. An alternative approach is parallel running, in which case the old tool should run in a ‘read only’ mode to prevent mistakes.