ITIL Certified ITIL Foundation 2011 Study Notes

®

ITIL Foundation

ITIL Foundation®

User Guide v1.7 27.01.2012

ITIL® is a Registered Trade Mark of the Cabinet Office.

The Swirl logo™ is a Trade Mark of the Cabinet Office.

®

ITIL Foundation



1

®

ITIL Foundation

Published by: ®

ITIL Certified - provided by ILX Group plc George House Princes Court Beam Heath Way Nantwich Cheshire CW5 6GD The Company has endeavoured to ensure that the information contained within this User Guide is correct at the time of its release. The information given here must not be taken as forming part of or establishing any contractual or other commitment by ILX Group plc and no warranty or representation concerning the information is given. All rights reserved. This publication, in part or whole, may not be reproduced, stored in a retrieval system, or transmitted in any form or by any means – electronic, electrostatic, magnetic disc or tape, optical disc, photocopying, recording or otherwise without the express written permission of the publishers, ILX Group plc. This document is the copyrighted intellectual property of ILX Group plc and may not be copied, disassembled or in any way modified without the express and written permission of ILX Group plc. © 2011 ILX Group plc



1

2

Foreword ®

ITIL Foundation

ITIL Certified, provided by ILX Group, is a leading developer and distributor of multimedia training products specialising in the area of project and programme and service management. ITIL® Foundation uses the very latest multimedia educational techniques to provide a learning environment which is stimulating, easy-to-use and stress-free. The aim of this course is to take students with little or no knowledge of ITIL to the level where they could take the Foundation (Part 1) examinations with a high degree of confidence in achieving a pass. The examination within the course package uses previous examination questions that are accessed at random to provide an accurate simulation of the real thing. We hope you enjoy the course and that you find it a useful starting point in your ITIL training programme.



2

3 CONTENT

PAGE

SECTION 1: Hardware/Software Requirements

4

SECTION 2: Installation Procedure

5

SECTION 3: Course Notes Session 1: Overview of ITIL and Service Management

6

Session 2A: Overview of Service Strategy

19

Session 2B: Service Strategy Processes

25

Session 2C: Financial Management

35

Session 3A: Overview of Service Design

40

Session 3B: Service Level Management

50

Session 3C: Service Catalogue Management

60

Session 3D: Availability Management

63

Session 3E: Information Security Management

70

Session 3F: Capacity Management

75

Session 3G: IT Service Continuity Management

82

Session 3H: Service Design – Design Coordination

87

Session 4A: Overview of Service Transition

90

Session 4B: Change Management

98

Session 4C: Service Asset and Configuration Management

105

Session 4D: Release and Deployment Management

116

Session 4E: Knowledge Management

123

Session 4F: Transition Planning and Support

127

Session 5A: Overview of Service Operation

129

Session 5B: Incident Management

140

Session 5C: Other Processes

149

Session 5D: Problem Management

154

Session 5E: Service Desk

162

Session 5F: Other Functions

175

Session 6A: Overview of Continual Service Improvement

180

Session 6B: Continual Service Improvement

185

Session 7: Technology and Architecture

191

Session 8: Competence, training, skills & ITIL exams

197

Session 9: Exam Simulator

201



3

5

Installation Procedure ®

ITIL Foundation

Hardware/Software Requirements For the best experience using this multimedia course on a computer, we recommend the following minimum specification: Operating System: Microsoft Windows XP / Vista / Windows 7 CPU: 1GHz or equivalent RAM: 128MB (2000/XP) Screen resolution: 1024 x 768 or higher Peripherals: Sound Card and Speakers, Keyboard and Mouse



4

1 S1p1

Overview of ITIL and Service Management ®

ITIL Foundation

ITIL Course Overview

Hello and welcome to this e-learning training course. This course has been designed to provide you with an overview of ITIL based IT Service Management. This course is based on ITIL ‘best practices’ as described in the ITIL Service Management publications. The course highlights how plans, processes, functions, roles, responsibilities and knowledge management all work together to help organizations to plan, design, transition, operate and improve the IT services that will deliver agreed benefits. In addition, the course provides the ideal background knowledge for anyone intending to operate in an ITIL based Service Management environment.

S1p2

Course and Session Objectives

In this introductory session, we will begin by outlining the objectives of this course. These are: • • •

To provide an awareness of ITIL best practice, its key concepts and associated terminology. To define what a service is and take a look at the service lifecycle. To outline the five ’core books‘ within the IT ’Infrastructure Library‘ and look at how some of the concepts can be implemented.

In this overview session, we will: • • • • • • •

Outline the course objectives Examine the history of ITIL, and look at why it is so successful Look at what we mean by a ‘best practice’ and look at some of those in the public domain Define what Service Management is, and what is meant by best practice We’ll also look at the concept of utility and warranty, what a stakeholder is in Service Management, and the concept of Internal and External services along with internal and external customers We’ll see how ITIL integrates with other best practice standards, frameworks and methods We’ll go on to describe the five service lifecycle stages and define a service, a function, a process and familiarize you with some generic roles across the service lifecycle, and introduce you to the RACI model.

Throughout this course, you will find direct quotes from relevant ITIL guidance. These quotes are intended to highlight important statements. Any on-screen quotes are indicated by inverted commas. Quotes included in the course subtitles are highlighted in the same way.

?

S1p3

Activity

ITIL is an acronym for Information Technology Infrastructure Library. It consists of a library of reference books outlining best practice guidelines for IT Service Management. And whilst we’re here, let’s also clarify what we mean by the term IT Infrastructure. Put simply, it is defined as; All of the hardware, software, networks, facilities and so on, that are required to develop, test, deliver, monitor, control or support IT services. IT Infrastructure does not include the associated people, processes and documentation. Before we go much further, here’s a quick question for you.



5

1


ITIL Foundation

‘Why do you think an organization would want to improve its IT infrastructure?’ Feedback Well, they’re all valid reasons for IT infrastructure improvement. The ethos behind the development of the IT Infrastructure Library or ITIL, is the recognition that organizations and IT must work hand in hand to satisfy corporate aims and meet the needs of the business. This is true regardless of the type or size of business. In each case there is a requirement to provide an economical service that is reliable, consistent and of the highest quality.

S1p4

What is Service Management?

The IT infrastructure sits at the heart of most organizations, consequently, and more importantly, the organization relies on IT to support almost all of its day-to-day business operations. ITIL guidance recognises this dependency and suggests that IT should be delivered to the organization in the form of ‘services’. To ensure that the services meet the present and future business needs the service must be properly managed, continuously reviewed and, if justified, updated. ITIL uses words and phrases which may have different meanings from those used in your organization. So an additional objective of this course is to introduce you to some of these words and phrases. In fact we will be introducing quite a few in this introductory session. For complete definitions, we suggest that you take a look at the Glossary of Terms, Definitions and Acronyms provided in the course.

S1p5

What are Services?

ITIL defines Service Management as ‘a set of specialised, organizational capabilities, providing value to customers in the form of services.’ There are four key words here, namely, ‘organization’, ‘capability’, ‘value’ and ‘customers’. For example, a customer is most likely to be a budget holder and a decision maker. The customer agrees requirements and changes to a service. Customers may act as the ’Service Owner‘ or ’Service Sponsor‘. A ‘customer’ is most likely to be senior staff member in your organization for example a Sales Manager or an HR Director. Customers are stakeholders. ‘Value’ simply means that you get something that is very useful to you. For example, if you are hungry you may decide to buy a pizza. The pizza supplier provides a ‘service’ that bakes and delivers the pizza. You may consider it a good ‘value’ service if the pizza stops you feeling hungry and the pizza is delivered within 20 minutes. The ‘capability’ needed to provide the service may be provided by people with the skills required to manage and carry out the order, baking, delivery and payment processes. We also need to recognise that as a service provider we may need to offer our services to external and internal customers, recognising both the internal and external services we provide. We will return to some of these concepts later on in the course.



6

1

Overview of ITIL and Service Management

S1p6

®

ITIL Foundation

The early history of ITIL

Before we go any further let’s take a brief look at the history of ITIL. The need for reliable IT Services in UK Government Departments triggered the CCTA (now known as the OGC) to sponsor the ITIL development project. The outcome was the IT Infrastructure Library. The first library included 34 books which were published between 1992 and 1998. The books contained comprehensive guidance on how ITIL concepts, processes and products could help organizations to manage their IT Services and the supporting IT infrastructure. By the late 1990’s many large organizations and government agencies throughout the world used ITIL best practice guidelines for IT Service Management. ITIL V2 was published in 2000 and became the world’s leading Service Management reference source. There is now a global community of users sharing the principles and concepts embedded in the framework.

S1p7

ITIL today

From its modest beginnings, ITIL went from strength to strength. But as technology changed a need to update the guidance was identified. So the ITIL V3 project began in 2004, and involved extensive world-wide consultations with hundreds of IT Service Management practitioners from the public and private sectors, including vendors, qualification bodies, exam institutes and education providers. May 2007 saw the launch of ITIL 3, confirming ITIL’s place as the world’s most credible framework for IT Service Management. Importantly ITIL is now supported by the international ISO/IEC20000 standard. Since its inception, ITIL has expanded from a library of books into a whole industry, with many organizations offering related products including training, consultancy and management tools. In September 2009 OGC announced its intention to update ITIL once more The quality criteria required the updates to be written in plain English and be free from inconsistencies across all five titles, and therefore beneficial to the end user and the training community. The ITIL updates were released in July 2011. At the same time the APM Group announced to the world that the Intellectual Property rights for the ITIL framework would move to the UK Government’s Cabinet Office.

S1p8

ITIL examination bodies

ITIL is a recognised global IT industry ‘best practice’. ITIL provides common processes, language and terminology that can be used by IT Service Management professionals anywhere. In 2006, the UK government’s Office of Government Commerce appointed the APMG as the accrediting body for ITIL. The APMG accredit the ITIL examination bodies, and authorised training organizations, such as ILX Group. As you might expect, the ITIL qualifications are recognised by organizations worldwide, and have become a prerequisite for appointments in many of the world’s blue chip companies.



7

1


ITIL Foundation

The ITIL qualifications and examinations are administered in the UK by ISEB, which form part of the British Computer Society, and the APMG. Other examination institutes include EXIN, Loyalist College, CERT-IT and PEOPLECERT Group. Due to the ever growing demand for ITIL qualifications and certification across the globe this list is sure to grow. If you intend to take an ITIL examination, then the qualification will be provided by one of these organizations.

S1p9

Complimentary standards

Service Management is also supported by several internationally recognised standards, including: •

ISO/IEC20000. We mentioned this earlier, this standard covers any enterprise offering IT services to internal or to external customers. It is often a mandatory requirement in any outsourcing tender. By gaining ISO/IEC20000 accreditation, a service supplier may gain the competitive advantage needed to win the business

•

ISO/IEC27001 specifies the requirements for establishing, and maintaining a documented Information Security Management System within the context of the organization's overall business risks

•

ISO 9001:2008 is one of the standards in the ISO 9000 family. It requires the accredited organizations to define, follow, monitor, record and improve the procedures that cover all their key business processes

• Whereas BS25999 assists in implementing business continuity management • And ISO/IEC19770 is the Software Asset Management processes standard These approaches to quality are in wide use and support the ITIL® approach to Continual Service Improvement. This list is not definitive, however by using the standards combined with the skills, knowledge and understanding that you and your organization already have, provides you with the framework for best practice operations and effective Service Management.

S1p10

Why is best practice needed?

Many organizations operate in a rapidly changing environment. As such they recognise the need to learn, adapt and improve. Whilst it is always possible to improve, there are always trade-offs. For example, to halve the pizza delivery service time from 30 minutes to 15 minutes might require less pizza choice and a much higher charge. The same principle applies to an IT service. For example a faster response time to a customer enquiry requires higher performance technologies to support it. Ultimately, someone has to pay for that technology. If the customer demands the performance improvement then the customer must pay for it. Whether you decide to improve or not to improve, may depend on how you compare with other organizations operating in similar conditions. To compare one organization against another may involve benchmarking.



8

1


ITIL Foundation

Benchmarking helps to identify the strengths and weaknesses in one organization’s products, services, processes or other areas and compares them against another similar organization. The reasons why ITIL is so successful is that it is vendor neutral, it is non-prescriptive, and it is scalable. It is also based on the ‘adopt and adapt’ approach which means it can be made to suit your organisational needs.

S1p11

Benchmarking

One simple way to benchmark is to compare your approach to delivering and supporting to IT services with the approach used by other similar organizations. Their approaches (and yours) may be documented in case studies and ‘best practice‘ guidance. Best practices are accepted ways of doing things successfully. Because they are successful they are copied, improved and adapted. ITIL is documented best practice. You can adopt it, you can adapt it or you can say we are perfectly happy as we are. You can do this because you will know what you do well and what could be done better.

S1p12

Complementary best practices

There are many other frameworks and methods that complement the ITIL library. Here we will look at some of the more common ones. You may be familiar with some of them. As they are also approaches to service improvement, they are described in a little more detail in the ITIL Continual Service Improvement Book. Let’s begin with COBIT or Control Objectives for IT. Whilst ITIL describes, ‘what to do and the processes required to do it‘ the complimentary COBIT concentrates on the governance frameworks that help define ’how to do it‘. Combine ITIL with COBIT and you should have the ideal governance framework. And what about CMMI or the Capability Maturity Model? Well, amongst other areas, CMMI assists in the delivery or acquisition of products and services. Many organizations who wish to outsource their IT services require the supplier to be audited to level 5. This is the ultimate optimising level, where the focus is very much on process improvement. Six Sigma includes concepts which can be applied within problem management to help identify and remove the causes of defects. This list is by no means definitive and you may want to research others include EFQM and Deming (Plan, Do, Check and Act). Importantly in September 2009 OGC announced the intention to become more aligned with PPRM guidance - in particular MSP, M_o_R, PRINCE2 and P3O. Practices built around how we deal with people or ‘cultural change’ may also exist and we shouldn’t forget academic research, training and education, and of course the proprietary experience of staff.



9

1


ITIL Foundation

?

S1p13

Activity

Here’s a quick question for you. ‘ISO 9001:2000 is...?’ Feedback ISO 9001:2000 is an internationally recognised quality standard which supports best practice in Service Management.

S1p14

What is a Service?

We’ve mentioned the word ‘service’ several times, without really explaining what a service is, in Service Management terms. The ITIL glossary of terms defines a service as ‘providing something of value to a customer that is not goods’. ITIL also says that a ‘service is a means of delivering value to customers by facilitating outcomes customers want to achieve, without the ownership of specific costs and risks‘. Typical examples of Service-oriented businesses include airlines, banks and telecoms companies. An example of a banking service might be the provision of current accounts, savings accounts or actually giving you the money you need when you need it. That’s ‘value’. To deliver the ‘value’ requires the use of people, processes and technology. In ITIL, Service and IT Service mean the same thing. If the service is an IT Service, then it’s an IT Service provider who will supply it. An IT Service is based on the use of information technology and supports the customer’s business processes. So returning to our earlier banking example, dispensing cash from an automatic teller machine is the service. IT will support the organization in the provision of that service, providing the networks, the account information held on servers, checking the electronic security and so on. A Service Level Agreement or SLA, describes exactly what the agreed service is. The SLA is a written agreement stating what will be provided, by the IT Service provider to the IT customer and what the IT customer will need to provide for the IT Service provider. The SLA also describes how the level of service will be measured.

S1p15

What is a Service?

In our definition of Service we were introduced to another new term, namely ‘outcomes’. To define an outcome requires the identification of three elements - an ‘objective’, or what the customer wants to achieve; ‘metrics’, how is the outcome going to be measured; and finally an ‘expected result’. For example, an organization has the following requirement, this is ‘to increase the number of loan applications processed on time.’ In this example the ‘objective’ is to ‘increase the volume’, the ‘metric’ is the ‘number of loan applications processed, and the ‘expected result’ is ‘the number of loans processed on time.



10

1


ITIL Foundation

The ITIL definition of a service contains another interesting concept, namely that ‘the service will be provided without the customer having ownership of the costs and risks.’ To provide an everyday example of this, imagine you are going to provide a meal as a birthday surprise for a friend. To provide the meal you could take either of two approaches. Firstly, as a customer, if you were prepared to accept all the costs and risks involved, you would need access to a kitchen, a large selection of ingredients, and the skills and know-how to prepare the meal, and all in the knowledge that it could go badly wrong. The alternative would be to visit a local restaurant. As a customer, you wouldn’t be responsible for all the costs, and the risks and a poor quality meal would be mitigated. In other words, we’re using a professional organization to provide a service. The service usually has to be paid for, but only a portion of the overall cost and risk is included in the bill to any one customer.

S1p16

ITIL lifecycle - Service Strategy

We will now describe the five ‘stages’ of the Service Lifecycle. The five stages are Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. We will describe the activities associated with each in more detail later in the course. Stage 1 is Service Strategy. This stage of the Service Lifecycle covers 2 aspects of strategy, namely: • •

Defining a strategy - whereby a service provider will deliver services to meet a customer’s business outcomes and Defining a strategy - for how to manage those services

Service Strategy is where the business and IT agree on what is required in the ‘long term’. A ‘business aligned’ strategy will describe what the business goals are, in other words what the business should be doing in the future. The strategy will also state what is required from IT to help the business reach that goal. The timescales set depend on the business needs and culture; the strategy is not a tablet of stone and in some ’agile‘ businesses it may need reviewing several times a year. From the IT viewpoint, one of the outcomes from the strategy will be a number of Business Cases. The Business Cases highlight what the business as a whole needs to achieve and what new or changed IT Services are required to meet those needs. For example an organization may decide that it wants to be in the fast food business. If so, then its strategy would focus on the processes needed for a rapid order-to-delivery service. This is because the ’market space‘ in which the organization operates, is the ‘fast-food’ business and not the ‘fine-food’ business. In other words, the fast food company is unlikely to encourage customers to linger over the food with candles and soft-music as that is not there ‘market space’. The true Service lifecycle really starts as soon as the Business Case for developing that Service has been approved. The lifecycle ends when the Service is withdrawn never to be resurrected.



11

1 S1p17


ITIL Foundation

Service Strategy - influences

There are all kinds of influences which may drive the IT Strategy, for example there may be a need comply with the environmental policy or legislation. For example, organizations that deal with US companies may be impacted by the Sarbanes-Oxley Act. In such cases there is a need to retain authentic and accurate records and provide an audit trail. IT Service Management may be expected to guarantee, in writing, that the IT systems and data storage comply with the act. As such, major development work may be needed to ensure compliance. Service Strategy is also involved in Investment Appraisals and policy setting. Investment Appraisal is part of Financial Management. If you do not have the financial resources to carry out the strategy, then you need to change the strategy. An example of policy setting might be where a supplier who wishes to be on your short-list of preferred suppliers may need to be ISO/IEC 20000 accredited as ’that is our policy’. Finally Service Strategy may be involved in Demand Management. This involves working with the business to determine where there might be significant growth or other changes in business activity. This may impact on the IT services provided.

?

S1p18

Activity

Here’s another quick question for you. Which option shows the correctly named core publications concerned with the Service Lifecycle? Feedback No, there is no core publication called Service optimisation. No. ITIL does not mention a phase called Development in the lifecycle and Service Management is too big as it covers IT life, the universe and everything. No, Service Support is not an ITIL v3 Phase-although it is recognised as such in ITIL v2. Service Improvement is ‘continuous’ so is not a phase as such. CSI is the fifth book in the ITIL series but that may be because it was the last one to be scoped, specified or completed. Yes, well done you are correct.

S1p19

ITIL lifecycle - Service Design

Phase two of the Service lifecycle is ‘Service Design’, and refers to the Application Management and Technical Management Functions and some Design and Transition Processes. Service Design evaluates the Business Case and, after agreement and approval by the ’responsible and accountable‘. Business and IT decision makers, will design and build the service. The service now enters the ’pipeline’. Depending on the complexity of the proposed service, the design stage may be a major project that needs significant collaboration from staff from other areas such as Business, Supplier, Project, Application and Technical Management. In ITIL the collaborators may also be referred to as ’stakeholders’.



12

1


ITIL Foundation

The main document produced from this stage of the Service Lifecycle is called ‘a Service Design Package’ or the SDP. This document will contain all requirements throughout the other stages of the Service Lifecycle and is referred to throughout many design and transition activities as well as in readiness for Operational support. We’ll look at SDP’s in more detail later in this course. The Business Systems Analyst and Designers from the Application Management function collaborate with the Service Catalogue Manager and the Service Asset and Configuration Manager to ensure that wherever possible new applications are built from existing service components; ideally these are linked together by business-process definitions.

S1p20

ITIL lifecycle - Service Transition

Stage three of the Service lifecycle is ‘Service Transition’, which tests, integrates and releases the new or changed service. The service may consist of newly built, procured or changed applications, processes, policies, tools and technologies that Service Design ’hands over‘ to them. Before the applications can be deployed, Service Transition must be satisfied that the business is ready for the Service that the business can use the Service and Service Operations can manage the Service. This might require major business change and user education. When you are confident that the Service will become operational and is no longer under development and therefore not in the pipeline, you might decide to tell other customers and users about it. To do so, you can register it in the ’Service Catalogue’ Testing is essential. The ’Service Design Package‘ should contain much of the information needed to help with the test and validation processes. After testing the ’Release and Deployment Management‘ process ensure that the Service is deployed into the production or ‘live’ environment. And after the service has ’gone live‘ it will need to be supported. It is unlikely that the Service Desk has the resources or capability to handle all the requests, events or incidents which often occur soon after a service ’roll-out’. Staff that were responsible for development for example programmers or other project team members frequently provide ’Early Life Support‘, known as ’ELS’. This means that they are on-call to help as needed. Depending on the reliability or ease of use of the service Early Life Support may need to be in place for many months.

S1p21

ITIL lifecycle - Service Operation

Service Operation is the fourth stage of the Service lifecycle. Service Operation is responsible for providing the day-to-day Service support. Service Operation manages different processes for example: • • • •

Request Fulfilment - ‘Send me some new toner for my printer’ Event Management - ‘The back-ups failed’ Access Management - ‘Reset my password’ Incident Management - ‘The customer database is off-line and therefore unavailable’



13

1


ITIL Foundation

• Problem Management - ‘Find the cause of the customer database being off-line and identify solutions’ Staff from the IT Operations Management function may also manage server farms, networks, data centre access and job scheduling. Staff from the Application Management function may help correct programming run-time errors whilst Technical Management may be identifying ways to use storage space more economically. Meanwhile the Service Desk function looks after the needs of the user community; they will need capable staff on the Service Desk to assist users when they have difficulties.

S1p22

ITIL lifecycle – Continual Service Improvement

And now the final phase, although it’s not really a phase, as it is ’Continual Service Improvement’. The Quality Management techniques and concepts described in Continual Service Improvement can be applied to most activities and processes in the Service Lifecycle. For example the book will help you to: • • • • • •

Identify potential improvements to the way the strategy is created or risks assessed and managed Implement better ways of recruiting and training staff Develop new metrics and measures to assess performance Improve Process effectiveness, efficiency and compliance Determine whether stronger levels of data encryption may be required Identify the root cause of problems faster

Supporting all the phases is a comprehensive ’Service Knowledge Management System‘; you will see what this contains a little later, but we have already mentioned some of the components, such as the Service Catalogue and the Service Design Package. There are many more.

S1p23

Function or Process?

We need to cover a few more definitions now. We have referred to ‘Functions’ and ‘Processes’ several times in this overview session. ITIL guidance makes a clear distinction between the two terms. The definition of a Function and a Process is something you should be aware of if you intend to continue your ITIL studies, or operate in an ITIL environment. The ITIL library provides several definitions of a Function including; • Self-contained units of organizations, specialised to perform certain types of work for specific outcomes • Self-contained units with capabilities and resources necessary for their performance and outcomes • A Function can be described as ‘providing structure and stability to organizations’, and rely on processes for cross-functional co-ordination and control Put simply, a Function is a team or group of people and the tools they use to carry out one or more activities or processes. A good example of a Function in IT terms is the Service Desk.



14

1


ITIL Foundation

In smaller organizations, one person or group can perform multiple Functions - for example, a Technical Management Department could also incorporate the Service Desk Function.

? Activity

S1p24

ITIL may be inconsistent in its identification of Processes and Functions, however, which one of the following options ’best‘ meets the ITIL guidance on what Functions are? Can you also say why one of them is most correct and the other three options are not wholly correct? Feedback No, Service Design, Transition and Operation are stages; it can be argued that each stage could be a function but that widens the scope of ’Self-contained units of organizations specialised to perform certain types of work for specific outcomes‘; a little too far. Yes, that’s correct. Service Desk, Application Management, Technical Management and IT Operations Management are ITIL Functions. They fit all the criteria of a function we outlined on the previous page. No, Incident Management is one of the processes that support the Service Desk, Service Operation and other Functions. No, Sales Management can be regarded as a Function, Service Strategy is a stage and Risk Analysis is considered to be a Process. It may support other Processes such as Risk Management, Change Management, and Availability Management. We’ll look at this in more detail later.

S1p25

What are Processes?

Processes define actions, dependencies and sequence. A Process is a set of co-ordinated activities combining and implementing resources and capabilities in order to produce an outcome that, directly or indirectly, creates value for an external customer or stakeholder. A car plant provides a ‘real life’ example. It takes in metal, plastic and various components and through a process of manufacturing produces finished cars as an output. The customer may derive value by using the car to get to work to earn money to buy a replacement car All Processes must exhibit four main characteristics. You could check whether these characteristics match the processes in your organization. Firstly they should be ‘measurable’. Processes are performance driven; therefore it must be possible to measure a process in a relevant manner They must produce ‘specific results’. The process must exist in order to produce a desired outcome. This result must be identifiable and countable. Each process delivers its primary result to a customer or stakeholder. These can be internal or external. And it should respond to a specific event. There must be an identifiable event that triggers the process. For example, the Service Desk phone ringing may trigger the Incident Management process The Process Owner is responsible for deciding what the process should do and ensuring that their Process is performed as agreed and documented. Other roles to consider are the roles of the process manager and the process practitioner and service owner. Some of the generic responsibilities of the process manager include working closely with the



15

1


ITIL Foundation

process owner to plan and coordinate all process activities, ensuring all activities are carried out as required throughout the service lifecycle as well as appointing people to the required process activities and managing the resources aligned to the process. Some of the generic activities of the process practitioner include the carrying out of one or more activities of a process, as well as ensuring the inputs, outputs and interfaces for the process activities are correct, finally the process practitioner will create and update records to show that activities have been carried out correctly.’ Finally some of the generic responsibilities of the service owner include identifying opportunities for service improvements and discussing these with the customer and raising requests for change. The service owner will also be responsible for representing the service in the change advisory board meetings. A summary of each of the roles can be viewed by clicking here.

?

S1p26

Activity

Which of the following statements meets all four main characteristics of a Process?

Feedback Yes, you are correct. It meets all four characteristics of a process which are that they are measurable, they produce specific results, they deliver an output to the customer and the process responds to a specific, traceable, event or trigger. No, this is a meaningless statement. There is no definition of quickly; it could mean seconds, days, months or millennia. There is no measure of productivity - from what to what. No, this is a meaningless statement. The term 'several' could mean two, five or twenty five? Also we can't be sure if it is to develop, buy, implement, or replace the Applications? Not really, but your almost correct. This is likely to be many processes. For example create an Invitation to Tender; evaluate supplier proposals and so on.

S1p27

ITIL roles

The final ITIL definition, which we will look at in this session, is ‘Role’. ITIL defines a Role as ‘a set of responsibilities defined in a process and assigned to a person or team.’ A Role in ITIL terms is defined within a process. A role carries with it a set of responsibilities, which may be carried out by an individual, or a team of people. Roles can be combined; in fact, one person or department may well be responsible for several roles. For example a single person may carry out the responsibilities of two roles namely the Change Manager and Configuration Manager. The Technical Management function or department if you prefer, is where you might find technical architects, capacity planners and network analysts. Therefore it is likely that staff from this department may perform some of the responsibilities of the ‘role’ of Problem Management, when diagnosing the root cause of incidents. The same department could also be expected to play several other ‘roles’ at different times, for example it may adopt some responsibilities of the Change Management ‘role’ by assessing the impact of changes, and manage the performance of devices under their control, working in the area of Capacity Management.



16

1


ITIL Foundation

Similarly if an Application does not respond, the programmer responsible, working in Application Management, may need to identify the cause and code the cure. Service Desk staff often carry out many tasks within ‘roles’, for example password resets in the ‘role’ of Access Manager, calling in engineers with a ‘role’ of Supplier Manager and so on. There are several Generic roles that act across the whole of the service lifecycle, namely - Service Owner, Process Owner, and Business Relationship Manager. It is important for those employed in a role to have clear understanding of their responsibilities, accountabilities. They should also know who would need to be consulted at a key stage of a project, or who would need to be kept updated on any progress during a Major Incident. The model to aid service providers achieve this is called the RACI model.

S1p28

Summary

That concludes this session entitled ‘Overview of ITIL and Service Management. In this session, we have: • Examined the history of ITIL. • And defined what is meant by ‘best practice’. • We have seen how ITIL integrates with other best practice methods and processes. • We have looked at why ITIL is so successful as well as how it is used in the public domain. • We went on to look at Value creation, and introduced you to the concept of Utility and Warranty of a service. • We discussed the understanding of both internal and external services and customers, along with stakeholders in Service Management • We went on to outline the five lifecycle stages of Service Strategy, Design, Transition, Operation and Continuous Service Improvement. • And finally we have described a Service, a Function, a Process and a Role, in ITIL terms and have provided you with a tool - the RACI model that can help you to understand how to allocate roles to recognised process activities

?

S1Q

Topic Quiz

Welcome to the topic quiz for this session. Here we will present you with a few questions based on the principles we have covered so far. Don't feel under pressure as your answers are not scored. Good luck!



17

2A

Overview of ITIL and Service Strategy ®

ITIL Foundation

S2Ap1

Session Objectives

This overview session looks at the ITIL Service Management publication Service Strategy which is the first of the five lifecycle stages we will be looking at. Service Strategy provides guidance on how to design, develop and implement Service Management as an organizational capability and a strategic asset. In this overview session we will look at some of the key activities. Once you’ve completed this session you will: •

Gain an understanding of what a service is and different types of service, including internal and external service, core, enabling and enhancing services

•

Recognise and understand some of the key concepts of Service Strategy such as organizational capability, strategic asset, and Risk Management

•

Identify the main purpose, scope, objectives and value of Service Strategy to the business

•

You’ll also recognise the need to identify, select and prioritise opportunities.

•

We’ll go on to consider the contents of the Business Case, including the Financial, Demand and Risk Management aspects.

•

Finally we will introduce you to the role, of the Business Relationship Manager.

S2Ap2

Introduction to Service Strategy

To operate and grow successfully in the long-term, Service providers must have the ability to think and act in a ‘strategic’ manner. The purpose of the Service Strategy publication is to help organizations to develop that ability. The main objectives of Service Strategy are to understand what Services should be offered to support the organization. In order for a service provider to be able to understand what services should be offered to support the organization, the service provider needs to recognise the types of services available to the organization. Services can be either internal or external, core, enabling or enhancing. An example of an internal service might be where a service desk exists to support services between departments or business units in the same organization, whereas an external service could be a service desk providing support to external customers or suppliers for example. This table shows examples of core, enabling and enhancing services. Service Strategy should also begin setting policies and objectives for the provision of Services in support of the business areas. Other objectives include understanding how to create value for an organization and to identify and select strategic investments. It should also define Service Quality. As you will see shortly, these objectives can be achieved by considering Service Strategy as a series of activities. But first, let’s take a look at some of the key concepts associated with Service Strategy.



18

2A S2Ap3


ITIL Foundation

Key Concepts

As we mentioned earlier, Service Strategy describes how you can design, develop and implement Service Management as an organizational capability and as a strategic asset. In the next few pages we’ll describe what ‘capability’ and ‘strategic assets’ may mean. We’ll also define what we mean by the ‘Service portfolio’. Organizational capability means different things in different organizations, however from the Service Management view; the focus should be on developing and using IT Services and other assets to help deliver ‘value’. The value will be delivered through the ways you use your capability assets and your resource assets, as both are needed. ‘Resources’ are the things most commonly managed, such as finance and data, they are often tangible and therefore easy to see and measure. ‘Capabilities’ include the processes you use, the management competence, the expertise and skills of the staff. They all work together to help achieve an agreed result. Capabilities are often intangible and therefore difficult to measure. Value requires resources and capabilities. Value can be measured by the amount of new and profitable business gained or by the costs saved. Real life examples are the web based systems that allow passengers to book flights and check-in online. These have increased business and reduced costs for many airlines. That’s value. Changes within IT Service Management may also be needed. There may also be a culture change, which focuses on becoming more responsive and improving our ability to understand and meet customer needs, more quickly than competitors. We may also need to build better customer, supplier and employee relationships. And improve service quality, so that new or changed Services are designed, developed and delivered to the business, meeting or exceeding expectations.

S2Ap4

Key Concepts - Strategic Asset

For Service Management to be recognised as a value adding strategic asset requires proper management of the capability and resource assets. From the business viewpoint Service Management is seen as a valuable strategic asset when it adds perceived value to the customer and is seen to be offering something very special that cannot be easily supplied by another organization. So for example, a bank might consider its branch network or customer data to be strategic assets. You might want to consider some of the following questions. Firstly, consider Service Management in your organization. •

What value does it add and what additional value could it add to the business as a whole?

Secondly, consider a Service in your organization.



19

2A •


ITIL Foundation

What value does it add and what additional value could it add to the business (or specific customer) as a whole?

And finally, what does your IT Service Management offer that would be very difficult for another organization to offer?

S2Ap5

Key Concepts - Service Portfolio, Service Catalogue

Other concepts in Service Strategy that we need to recognise include the Service Portfolio, Service Catalogue, Service Model, Constraints, Business Case, Risk and the Management of Risk. So let’s look at those now. Let’s begin with the Service Portfolio. From the initial business case through to the final termination of the Service, the information accessed via the Service Portfolio covers the complete Service lifecycle. There are three elements of the service portfolio, namely the service pipeline, the service catalogue and the retired services element. Within the service pipeline we can find information relating to what services are in the design concept stage, as well as information relating to those services that have been chartered, or are agreed and are ready to be progressed through the design stage of the lifecycle. Within the service catalogue element we can find information relating to all live operational services, rd including 3 party services. Within the retired services element of the service portfolio, we can find information relating to those services that have been retired and the reasons for their retirement. As soon as a Business Case is approved for a new Service the details are entered into the service Portfolio, and the Service Design stage can then begin. By referring to the service Portfolio, which forms part of the ‘all knowing’ Service Knowledge Management System, you should obtain any information required about a Service. The Service Portfolio represents the service. This means that you should be able to read or update any of the information associated with a service. This includes the Business Case, project documents, risks and costs, continuity plans, requirements and specifications, test plans, SLA’s and Contracts, any changes approved, or potential for development and so on. Now, let’s define what we mean by the Service Catalogue. The Service Catalogue is linked to the Portfolio as it identifies what is currently being provided to business customers or what is currently going through development or being transitioned into operations. There are typically 3 views to the service catalogue however, service providers will need to consider both the use and number of users to determine the number of views when designing the service catalogue. In many organizations it is seen as the brochure which tells people what we offer, what it looks like and how to buy it. Just like IKEA! The Service Catalogue is the part of the Service Portfolio that is visible to customers!



20

2A


ITIL Foundation

S2Ap6

Activity

Which of the following options should provide easy access to information about continuity plans, requirements and specifications, test plans, SLA’s and Contracts and other technical and business information? Feedback No - The Service Catalogue will help customers decide whether or not to do business with you. Yes, it is the Service Portfolio that will provide easy access to the information. No - The Business Case helps an organization make an informed decision about proceeding with a suggestion or not. No - The Market space is something that organizations use to help them decide which business / IT Areas to remain with, retire or exploit.

S2Ap7

Key Concepts - Constraints

Service Strategy guidance also discusses the concept of ‘Constraints’ and how these may impact the business and Services. Constraints can come from many sources, for example international standards, contractual terms and conditions, values and ethics, costs or methods of working, to name just a few. These Constraints will affect and determine your ‘solution space’. For example, employee conditions of service may prevent a Service Desk from working more than the 50 hours a week that the business demands. Other examples of ‘Constraints’, include; • Some applications may require screen inputs in many different languages • Certain transactions or data may not be permitted across international borders • Or price discounting my one of your competitors may result in you losing business By reviewing the Constraints, you can identify new approaches. So instead of reducing your price, you may be able to add some extra functions at little or no cost. Ultimately, if we could remove Constraints we might be able to provide higher levels of Service.

S2Ap8

Key Concepts - Business Case and Risk

You may well be familiar with the concept of a Business Case. A Business Case will identify the reasons for, and the benefits of, change. Amongst other things a Business Case provides: • • • • •

A reason for change The options being considered The costs involved The different options that might become available to us, and Associated Investment appraisal information.



21

2A


ITIL Foundation

Note that no Service details are permitted to enter the Service Portfolio unless there is an agreed and approved Business Case. When the Business Case is approved, the Design phase can begin. The new Service is now in the ‘Service Pipeline’. A Business Case is a decision support and planning tool, that projects the likely consequences of a business action. These consequences can take on qualitative and quantitative dimensions. Central to the creation of a good business is financial analysis input. The final concept we’ll look at in this session, is that of Risk, and the Management of Risk. Risk can be defined as the ‘uncertainty of outcome’, whether this is regarded as ‘positive opportunity’ or a ‘negative threat’. Risk is something that may, or may not, causes an interruption to the provision of Service. Many ‘best practices’ exist to support the Management of Risk, including the Cabinet Office’s M_o_R® method. Risk Management is essential for Security Management, Availability Management and Business and IT Service Continuity Management. We’ll look at these three processes when we cover Service Design.

?

S2Ap9

Activity

Which of the following are ‘Constraints’ and may cause an interruption to the provision of Services? Feedback All of these could impact or ‘constrain’ services. What would happen if you had a reduction in the number of users and you were charging for the Service? This reduction in revenue could impact your profits and then you may not have the money to maintain that service or other Services. If the Service Desk budget increased it may be reduced elsewhere, for example, a reduced budget for testing or fewer backups. A decrease in the budget for the Service Desk may mean that incidents are no longer resolved and Service suffers.

S2Ap10

Demand Management Roles

The Demand management process has some important roles associated with it, such as the process owner and manager. You should also be aware of the Business Relationship Manager role. The Business Relationship Manager role involves a high level of ‘strategic focus’ to ensure that customer outcomes are understood and being met. Some key activities include: • The development of high level customer requirements for a proposed new service • The building of Business Cases for a proposed new services • Confirming detailed functional requirements for a proposed new service with the customer • Confirming service availability requirement with the customer • Establishing Patterns of Business Activity • Evaluating the Business Case for a new service request from the customer, and assisting in the decision making process • And reporting on service performance versus targets



22

2A


ITIL Foundation

• The Business Relationship Manager will work closely with the Service Level Manager role S2Ap11

Summary

In this overview session we have been examining the ITIL Service Management publication, Service Strategy. In this overview session you have: Identified the main purpose, scope, objectives and Value to the business of Service Strategy. And we’ve been introduced to some of the key concepts involved in Service Strategy, including; • • • • • •

The Service Portfolio The Service Catalogue Business Relationship Manager role Constraints The Business Case And Risk and the Management of Risk

?

S2AQ

Topic Quiz




23

2B

Service Strategy Processes ®

ITIL Foundation

S2Bp1

Objectives

In this session we will be looking at the key concepts of the ITIL Service Strategy publication. In this session we will: Look at the processes primarily concerned with the Service Strategy stage of the Service lifecycle, including: • Financial Management for IT Services • Service Portfolio Management • Demand Management • We will introduce you to the Process Manager, Process Practitioner and Business Relationship Manager roles • •

We will go on to look at the ‘Value to the Business’ which Service Strategy brings And finally look at Components of Value and the Basics of Value creation

As you progress through the session you will be introduced to some new terminology, including the Service Portfolio, Service Catalogue, Service Pipeline, Service Management and Demand Management. You may find it beneficial to revisit this session once you have completed further sessions in the course.

S2Bp2

Funding, Accounting and Charging

Effective and Efficient Financial Management for IT services needs to cover funding (Budgets), forecasting, overspend, under-spend, costs, prices, it all happens when managing an IT Infrastructure. How many of you have to keep profit and loss accounts for IT service delivery? What are the issues? This ITIL process is about delivering the best possible quality service within budget. There are 3 main areas to consider when creating an IT Financial Management framework that can be considered as effective and efficient. Two of the three areas are mandatory - must haves - namely Funding and Accounting, the third is optional namely charging. Please note that this applies to Type 1 service providers these are internal only, for type III service providers which are external, charging will not be optional because by nature their business is to provide services at a cost, and to recover those costs by use of recognised charging methods in order to make a profit. Financial management for IT Services can indeed add value to the service provider and the business, however care is needed to ensure that the activities involved in funding and accounting and if used charging are not seen as an overhead and that there are tools, processes and identified activities to gather the data, analyse the data and produce meaningful and accurate bills to customers.

S2Bp3

Components of Value

Customer’s perceptions and preferences play a big part in understanding whether value has been delivered to our customers, and if not why not. Perceptions are influenced by attributes of a service, present or prior experiences with similar attributes and relative capability of competitors and other peers. Perceptions are also influenced by the customer’s



24

2B


ITIL Foundation

self-image or actual position in the market, such as those of being an innovator, market leader and risktaker. The value of a service takes on many forms, and customers have preferences influenced by their perceptions. The preferences and perceptions of customers will affect how they differentiate the value of one offering or service provider over another. So for example, Internet Service Providers offer different levels of service for home broadband users as opposed to home business users. Similarly, mobile phone providers offer different lines of service and costs to business and home users.

S2Bp4

The Basics of Value Creation

In order to create value for a customer, it is necessary to be able to identify the capabilities and resources that already exist both internally and externally. These capabilities and resources are referred to as the ‘Customer Assets’ and are used as a basis for defining the value of a customer or service. The performance of Customer Assets should be a primary concern for Service Management professionals because without customer resources and capabilities there is no basis for defining the value of a service. You can see the Customer Assets identified on this diagram as being; Management, Organization, Processes, Knowledge, People, Information, Applications, Infrastructure and Financial Assets. These Customer or Service Assets can be put into two groups, Capabilities and Resources. Resources and capabilities are types of assets Organizations use them to create value in the form of goods and services. Resources are direct inputs for production. Management, organization, people, and knowledge are used to transform resources.

S2Bp5

The Basics of Value Creation

Capabilities represent an organization’s ability to coordinate, control, and deploy resources to produce value. They are typically experience-driven, knowledge-intensive, information-based, and firmly embedded within an organization’s people, systems, processes, and technologies. It is relatively easy to acquire resources compared to capabilities. People are seen to be both a Capability and a Resource. Capabilities are the intangible assets of an organization. A Capability can be defined as the ability of an organization, a person, a process, an application or a configuration item which is a component of the infrastructure or an IT service, to carry out an activity. Take, for example, Management Structures. The Capability might be the ability to change the structure in order to use the Resources the best way we can. On the other hand, the business infrastructure is a tangible asset and, like financial capital and the other items listed here, it is a Resource.



25

Service Strategy Processes

2B S2Bp6

®

ITIL Foundation

Strategy Management for IT Services

Having been introduced to the concept of value in service management terms, let’s take a look at our first process, namely Strategy Management for IT services. ITIL describes it as ‘the process responsible for defining and maintaining an organization’s perspective, position, plans and patterns with regard to its services and the management of those services’. It’s this process which defines and maintains an organizations perspective, position and plans with regard to its services and the management of them. It is the responsibility of the organization’s executives and allows them to set objectives and prioritize investments in order to meet them. The process also ensures that a strategy is defined, maintained and achieves its purpose. The process objectives include: •

The analysis of the environment in which the service provider exists, both internally and externally

•

Spotting any constraints which might impact the achievement of business outcomes

•

It should regularly review the service providers perspective to ensure it is still relevant

•

Establishing the position of the service provider against its customers and competitors

•

And produce, maintain and manage changes to strategy planning documents and circulating them to all stakeholders

Once the strategy has been defined, strategy management for IT services is also responsible for ensuring that it achieves its intended business outcomes.

S2Bp7

Service Portfolio

The Service Portfolio tool represents all of the resources presently engaged or being released in various phases of the Service lifecycle. It is made up of three components: the Service Catalogue, the Service Pipeline and Retired Services. The Service Catalogue identifies what we’re currently providing or what’s likely to come in the very near future to the customer. It is the customers’ viewable information and should clarify or help answer the following questions: Why should a customer buy these services? Why should they buy these services from us? What are the pricing or chargeback models? What are our strengths and weaknesses, priorities and risk? How should our resources and capabilities be allocated? To complete the picture, the Service Pipeline is the development of changes on the way through, based on the customer’s requirements, and



26


2B

®

ITIL Foundation

Retired Services is the identification of services that we no longer need and the best way of removing these services.

S2Bp8

Service Portfolio Management

The Service Portfolio Management process is required to link service assets to their higher-level business services. On the one hand, you might find that a business process can be distributed across technologies and applications, span geographies, have many users and yet still reside in one place, for example, the data centre. Whereas on the other hand, the IT function might be organised into ‘Silos’ and so not have an overall understanding of the business requirements. So the role of Service Portfolio Management is to provide the necessary links between Business Service Management and IT Service Management.

S2Bp9


The purpose of the Service Portfolio Management process is to ensure that the Service Provider has the right mix of services to balance the investment in IT with the ability to meet business outcomes. As such the process ensures clearly defined services are linked to business outcomes which are aligned to the value of services. The process also enables us to track the investments in services throughout the service lifecycle, thus ensuring appropriate returns are being achieved. The Scope of the Service Portfolio management process is ‘whether the service provider is able to generate value from the services’.

S2Bp10


The objectives of the Service Portfolio management process are: •

To enable organisations to decide on investments by provision of a process and mechanism

•

To maintain the definitive portfolio of services provided

•

To enable evaluation of the services provided

•

It also enables control over services offered, conditions of service offerings and levels of investment in services

•

The process also allows us to track the investment in services throughout their lifecycle

•

Finally, Informing decisions regarding which services are viable and which are to be retired is another key objective.



27

2B


ITIL Foundation

?

S2Bp11

Activity

Now, see if you can answer these questions. Which of the options shown identifies two Service Portfolio components within the Service lifecycle?

Feedback The correct answer is Service Pipeline and Service Catalogue. The third is Retired Services - those which we no longer need.

?

S2Bp12

Activity

Which of the questions listed here is NOT answered by information in the Service Portfolio?

Feedback Information in the Service Portfolio does not answer the question ’What opportunities are there in the market?’

S2Bp13

Service Owner

So far in the session we have been talking about services in general, but when it comes down to it, every service needs to have an owner - someone who will be accountable to the IT Director for the delivery of that particular service and acts as the prime customer contact. In order to be able to do this, the Service Owner needs to understand the service both at a technical level and at a business level. The Service Owner also ensures that the ongoing service, its delivery and its support meets agreed customer requirements. These requirements are likely to be documented in Service Level Agreements. We will cover this more extensively later in the course. The Service Owner is also critical to Service Management in providing input into performance, availability and future requirements. And lastly, the Service Owner is responsible for liaising with the process owners through the Service lifecycle.

S2Bp14

Process Manager, Process Practitioner Roles

We have introduced you to the Process Owner and the Service Owner roles, now we need to introduce you to the roles of the Process Manager and Process Practitioner. The Process Manager has the following as key responsibilities: He or she will work with the process owner to plan and coordinate all process activities along with ensuring that all activities are carried out as required throughout the service lifecycle. The process Manager is also responsible for appointing people to the required roles along with managing the resources assigned to the process.



28

2B


ITIL Foundation

He or she will also work with service owners and other process managers to ensure the smooth running of services. The Process Practitioner is responsible for carrying out one or more activities of a process. He or she will also understand how their role contributes to the overall delivery of service and creation of value for the business. Working with other stakeholders, such as their manager, co-workers, users and customers, to ensure that their contributions are effective is another important responsibility. As is ensuring that inputs, outputs and interfaces for their activities are correct and creating or updating records to show that activities have been carried out correctly.

S2Bp15

Develop Strategic Assets

Let’s take a look at the main aspects of ‘strategic assets’. Firstly, Service Management can be considered as a Closed Loop control system. This will be explained in a little more detail in a moment, but essentially, we are talking about the ability to support the business by understanding how services are used and then effecting improvement by providing experience and training in order to improve the capabilities of Service Management focused on the customer assets. Next, Service Management is a strategic asset and, as such, it can be developed by increasing either: • The service potential - that is to say, what can or could Service Management do that offers increased value in the use of customer assets? or • The performance potential - Is there anything that Service Management can or could do better or more effectively utilising its service assets of resources and capabilities? Lastly, we need to look after the demand through Demand Management. Demand is about making sure that we have the right amount of capacity available and at the right cost. If we store too much capacity to deliver services, we are not making it cost-effective. If we run out of capacity, it might have a cost implication on the business. So, let’s take a closer look at these points.

S2Bp16

Service Management - A Closed Loop Control

In this Closed Loop control system, Service Management focuses on directly supporting the business and making improvements to maximise value offered. Everything that IT does directly supports a business area. So, if the business wants to provide ecommerce, for example, then we have an IT service provider that is only supporting that area of the business and therefore any change that the customer wants, IT supports directly in a closed way. Just to clarify the point, an example of an Open Loop system is the provision of services by an ISP, an Internet Service Provider. Here the service is available to lots of different customers and therefore each customer can’t drive the improvements to service in the same way as it could if it was in a Closed Loop. Look at the diagram again, it also illustrates Demand Management.



29

2B


ITIL Foundation

On the left hand side there are the customers’ assets, their capabilities and their resources - that is to say, what they’re trying to achieve in the business. In the middle there is the service that we can provide. On the right, we have the Service Provider with its service assets, the capabilities and resources at its disposal. So, in this Closed Loop system, let’s say the customer demands more service, we need to have the capacity to meet that demand. If that capacity is available we can very quickly provide the additional service - so we can say that the service potential is available to provide additional performance to the customer. However, there has to be a balance between the capacity that’s laying idle waiting for a demand and the associated costs to the organization. The more capacity we have, the more the costs go up. The more the customer demand varies the more capacity we will need to put on idle at certain times. So, it is all about understanding the balance.

?

S2Bp17

Activity

Which of these activities would you expect a Service Owner to undertake? Feedback The Service Owner would be involved in all of these activities except for Updating the Configuration Management Database after a Change.

S2Bp18

Demand Management – Purpose, Scope and Objectives

Demand Management helps the service provider to understand, anticipate and influence customer demand for services and the provision of capacity to meet these demands. Poorly managed demand is a source of risk for service providers because of uncertainty in demand and excess capacity generates cost without creating value that provides a basis for cost recovery. With this in mind, Demand management is recognised as a critical aspect of service management. The objectives of demand management are to: • • • • • •

Understand the levels of demand that would be placed on a service by identifying and analyzing patterns of business activity Understand the typical profiles of demand for services from different types of users by defining and analyzing user profiles Ensuring that services are designed to meet the patterns of business activity and the ability to meet business outcomes Maintain a balance between the cost of a service and the value that it achieves by working with capacity management ensuring that adequate resources are available at the appropriate levels of capacity Anticipate and prevent or manage situations where demand for a service exceeds the capacity to deliver Be able to meet the fluctuating levels of demand for those services

The scope of the demand management process is to identify and analyse the patterns of business activity that initiate demand for services and to identify and analyse how different types of users influence the demand for services.



30

2B


ITIL Foundation

Demand management is active in every stage of the service lifecycle, and works closely with several other processes one of the closest being capacity management. The diagram shows how a greetings card company benefits from understanding how the fluctuations in sales will impact on the demand for IT services.

S2Bp19

Demand Management - Service Package

Supply and demand is a very difficult balance and this represents a key challenge. Too much free capacity costs money without providing benefit. Not enough capacity and the business will usually suffer. So we need to understand the activities going on in order to be able to achieve a balance. This calls for Activity-based Demand Management. Techniques such as ’Business Activity Patterns‘ and ’User Profiles‘ can be used. The outcomes can be matched and analysed, enabling customers to better understand their own business activities, and service providers to better match the demand for their services. Rather than every demand from customers being treated as a new requirement, it makes sense to offer previously prepared service packages. Core Services deliver basic outcomes desired by one or more customers. An example of core service is providing printing facilities to an organization. The service could be provided on the basis that black and white printing is provided between 9.00am and 5.00pm. A Core Service Package (or CSP) is a detailed description of a core service that may be shared by two or more service level packages. A Service Package is defined as a detailed description of an IT Service that is available to be delivered to customers.

S2Bp20

Demand Management - Service Package (continued)

A Service Package includes a Service Level Package which is a defined level of utility and warranty for a particular service package. Each Service Level Package is designed to meet the needs of a particular business activity pattern. We can also develop differential offerings - in other words, the additional services that we can add. So, taking the printing example, it may well be that on top of a core service of black and white printing, we can provide additional support. Support for printing outside of those hours may be an additional level of service that we may be able to provide. Colour printing is another level of service that we may be able to provide, but it need not necessarily be a core service. The advantage of Core Service Packages is that we can provide them quite easily. They are a standard service. The customer can choose one or more core services and bring them together under a Service Package. The ability to understand Service Packages will also enable us to segment what are core packages, and what are additional required services?



31


2B

®

ITIL Foundation

Segmentation - Service Level Packages and Core Service Packages are made up of reusable components, many of which are themselves services. SLP are combined with CSP to build a Service Catalogue.

?

S2Bp21

Activity

For which of the options shown is Demand Management used? Feedback We need to understand patterns of business activity in order to be able to achieve a balance between supply and demand.

S2Bp22

Business Relationship Manager

The role of the Business Relationship Manager is to ensure that the required value is being created by the service provider for all current services, and to also obtain and focus on strategic business activities and future requirements and needs. The Business Relationship Manager role will also rely on other Service Management processes providing input and feedback from all aspects of service delivery, performance and support. The BRM will work closely with those in the role of SLM providing information from a strategic perspective in relation to daily operational requirements and targets. It should be noted that the BRM role will focus primarily on strategic and tactical needs whereas the role of SLM will focus primarily on day to day operational issues. The business relationship manager will focus on the customer portfolio tool and ensure that the data held in the tool is maintained.

S2Bp23

Business Relationship Management

Business Relationship Management is the process that enables BRMs to provide links between the service provider and the customers at the strategic and tactical levels. The processes purpose is two-fold, in that: • It should maintain a business relationship between the service provider and the customer with focus on the customer’s needs and • This focus on customer needs ensures that the service provider can meet the evolving business needs over time The scope of BRM for internal service providers is typically between a senior representative form IT and the senior managers of the business units. In external service providers, the BRM function is often carried out by a dedicated team who are focused on maximizing contract value through customer satisfaction. The objectives of BRM include: • Ensuring that the service provider understands the customers perspective of service • Ensuring high levels of customer satisfaction and establishing and just as importantly maintaining constructive customer relationships



32

2B •


ITIL Foundation

BRM should identify changes to the customer environment which could impact on service provision along with spotting technology trends which could impact on services too

BRM also assists the business in communicating the value of a service.

S2Bp24

Summary

In this session we have been looking at the key concepts of the ITIL Service Strategy publication. In this session we have: • Identified the purpose, scope, objectives and value to the business of Service Strategy • Looked at the key principles of Service Strategy, and • Covered in detail Components of Value • Introduced you to the Process Manager, Process Practitioner and Business Relationship Manager roles Along the way we have been introduced to some new terminology such as Service Portfolio, Service Catalogue, Service Pipeline, Service Management and Demand Management. You may find it beneficial to revisit this session once you have progressed further in the course.



33

Overview of Service Design

3A

®

ITIL Foundation

S2Cp1

Objectives

The subject of this session is Financial Management for IT services, which is the subject of chapter 4.3 of the ITIL Service Strategy publication. When you have completed this session you will: • Understand the purpose of IT Financial Management for IT services • Be aware of the importance of Financial Management • Have familiarised yourself with the basic concepts of Financial Management

S2Cp2

Process objectives

Budgets, Forecasting, Overspend, Underspend, Costs, Prices - they’re commonplace terms if you’re managing an IT infrastructure. The process of Financial Management is covered in section 4 of the Service Strategy publication. Financial Management is concerned with delivering the best possible quality service within budget, and identifying the costs associated with the provision of those services. The purpose of Financial Management is to provide cost-effective stewardship of the IT assets and financial resources used in Services. However, even though the goal appears to be straightforward, there are probably as many financial management methods as there are organisations. Fortunately ITIL provides specific guidance for IT Service Management and proves to be very useful in choosing which approach to take.

S2Cp3

Importance of Financial Management

Operational visibility, insight and superior decision making are the core capabilities brought to the enterprise through the rigorous application of Financial Management. Financial data continues to increase the importance of Financial Management for IT and the business as well. Financial Management is a strategic tool for service providers. Internal service providers are increasingly asked to operate with the same levels of financial visibility and accountability as their business unit and external counterparts. Moreover, technology and innovation have become the core revenue generating capabilities of many companies. Financial Management provides the business and IT with the quantification, in financial terms, of the value of IT services, the value of the assets underlying the provisioning of those services and the qualification of operational forecasting. Talking about IT in terms of ‘services’ is important. It can help to change the perception of IT and its value to the business. Therefore, a significant portion of Financial Management is working in tandem with IT and the business to help identify, document and agree upon the value of the services being received, and the enablement of service demand modeling and management.



34

3A

Overview of Service Design ®

ITIL Foundation

Like its business equivalent, IT Financial Management responsibilities and activities do not exist solely within the IT finance and accounting domain. Rather, many parts of the enterprise interact to generate and consume IT financial information, including operations and support units, project management organisations, application development, infrastructure, change management, business units, end users etc. These entities aggregate, share and maintain the financial data they need.

S2Cp4

Process Activities

Service Valuation quantifies, in financial terms, the funding sought by the business and IT for services delivered, based on the agreed value of those services. Financial Management calculates and assigns a monetary value to a service or service component so that they may be disseminated across the enterprise once the business customer and IT identify what services are actually desired. Service valuation focuses primarily on two key valuation concepts: Provisioning Value - which is the actual underlying cost to IT related to provisioning a service. Input comes from financial systems, and consists of payment for actual resources consumed by IT in the provisioning of a service.’ These cost elements may include items such as: •

Hardware and software license costs

•

Annual maintenance fees for hardware and software

•

Personnel resources used in the support or maintenance of a service

•

Utilities, data-centre or other facilities charges

•

Taxes, capital or interest charges

•

Compliance costs

The sum of these actual service costs typically represents the baseline from which the minimum value of a service is calculated since providers are seldom willing to offer a service where they are unable to recover the provisioning cost. Service Value Potential - is the value-added component based on the customer’s perception of value from the service or expected marginal utility and warranty from using the service in comparison with what is possible using the customer’s own assets.

?

S2Cp5

Activity

Try answering this Financial Management question. Feedback Accounting tells you where money is being spent, whereas budgeting assists with predicting future financial requirements. Finally charging is concerned with the recovery of costs.

S2Cp6

Cost Optimization

Financial Management for IT services provides key inputs for Cost Optimisation.’



35

3A


ITIL Foundation

Cost optimization is about giving expenditure to the expected levels of activity and return it is also about preventing unnecessary expenditure. Cost optimization should not be thought of as cost savings. The purpose of cost optimization is to ensure that levels of investment are appropriate for the level of service that customers demand and the levels of returns that are being projected. This may result in increased levels of expenditure if demand and potential returns increase. Cost optimization focuses on two perspectives: •

Is it possible and cost effective to use existing services or technology to achieve the outcomes?

•

What is the most cost effective investment (not always the cheapest) that needs to be made if the existing technology will not be able to work?

S2Cp7

Cost Categories

ITIL guidance on Financial Management identifies six cost categories. These can be further grouped into three distinct pairs, namely Capital and Operational costs, Direct and Indirect costs and finally Fixed and Variable costs. Let’s begin with Capital costs versus Operational costs. A Capital cost is an outright purchase of fixed assets, something an organization owns and has a worth. Capital items include buildings, hardware if it is owned, software, if it has been developed and it can be resold. Capital items are usually items to which depreciation can be linked - their actual value changes over time according to a policy that is set by the organization. Operational costs are the ongoing day-to-day and longer term costs which relate to elements that the organization doesn’t own. So, for example the lease of a building or the use of consumables are operational costs. Another pairing is Direct versus Indirect costs. A Direct cost is a cost specific to one entity, whereas an Indirect cost relates to a resource shared by a number of entities. And the final pairing is Fixed or Variable costs. Typical Fixed costs include salaries, standing charges and telephone line rental. It’s a fixed price, it doesn’t matter how much or how little you use it. Variable costs need to be measured in order to see the usage. Controlling the usage enables you to control the costs involved. An example of a Variable cost might be a charge per megabyte downloaded, via an Internet connection.

S2Cp8

Planning Confidence

One of the main purposes of Financial Management for IT services is to ensure proper funding for the delivery and consumption of services.



36

3A


ITIL Foundation

Planning confidence is not a tangible output or plan rather that it refers to the level of confidence that service stake holders have in the service provider being able to accurately forecast costs and returns. A lack of planning confidence will result in a lack of confidence in the service provider which in turn causes an unwillingness by the business to invest in IT unless absolutely necessary.

?

S2Cp9

Activity

Here's a quick question on cost types Feedback A cost that varies depending on usage is known as a Variable cost.

S2Cp10

Service Investment Analysis

Financial management for IT services provides the shared analytical models and knowledge used throughout an enterprise in order to assess the expected value and/or return of a given initiative, solution, program or project in a standardised fashion. It sets the thresholds that guide the organization in determining what level of analysis is to be applied to various projects based on size, scope, resources, cost and related parameters. The objective of service investment analysis is to derive a value indication for the total lifecycle of a service based on upon firstly, the value received, and secondly costs incurred during the lifecycle of the service.

S2Cp11

Accounting

Accounting within Financial Management differs from traditional accounting in that additional category and characteristics must be defined that enable the identification and tracking of service-oriented expense or capital items. The key Accounting functions are: •

Service recording - The assignment of a cost entry to the appropriate service

•

Cost Types - These are higher level expenses categories such as hardware, software, labour, administration, etc. These attributes assist with reporting and analysing demand and usage of services and their components in commonly used financial terms

•

Cost Classifications - There are also classifications within services that designate the end purpose of the cost. These include classifications such as:

Capital or Operational - This classification addresses different accounting methodologies which are required by the business and regulatory agencies Direct or Indirect - This designation determines whether a cost will be assigned directly or indirectly to a consumer or service. Direct Costs are charged directly to a service since it is the only consumer of the expense



37

3A


ITIL Foundation

Indirect or ’shared‘ costs are allocated across multiple services since each service may consume a portion of the expense Fixed or Variable costs - This segregation of costs is based on contractual commitments of time or price. The strategic issue around this classification is that the business should seek to optimise fixed service costs and minimise the variable in order to maximise predictability and stability Cost Units - This is the identified unit of consumption that is accounted for a particular service or service asset As the IT Organization’s accounting processes and practices mature toward a service orientation, more evidence is uncovered underlining its existence and performance.

S2Cp12

Compliance

Compliance relates to the ability to demonstrate that proper and consistent accounting methods and/or practices are being employed. This relates to financial asset valuation, capitalization practices, revenue recognition, access and security controls etc. If proper practices are documented and known, compliance can be easily addressed. It is important to understand the importance and ‘responsibility for being aware of regulatory and environmental risks which can affect the service operation and the customer’s business. Over the past decade a number of important regulatory and standards-related issues and opportunities have been introduced that impact Financial Management. Certain legislation has had enormous impact on financial audit and compliance activities. The implementation of public frameworks and standards such as COBIT, ISO/IEC 20000, Basel II, and other industry specific regulation may appear to be pure costs with no tangible benefits. However, regulatory compliance tends to improve data security and quality processes, creating a greater need for understanding the costs of compliance.

S2Cp13

Service economics

Service economics relies on four main areas, two of which we will look at in this part of the course namely business impact analysis and financial management for IT services. The other two areas are service portfolio management and return on investment which are covered in other modules of this e-learning course. Business impact analysis or BIA as it is known involves the service provider understanding the effect on a business if a service was not available this enables the business to prioritize investments in services and service continuity. Financial management for IT services provides financial data and information into BIA to help quantify the potential effect on the business. Financial management for IT services also helps to quantify and prioritize the actions needed to be taken in order to prevent the impact from becoming reality.

S2Cp14

Summary

In this session we have been examining Financial Management for IT services, which is the subject of chapter 4.3 of the ITIL Service Strategy publication.



38

3A


ITIL Foundation

• We defined the purpose of Financial Management for IT services, which is, ‘to provide cost-effective stewardship of the IT assets and financial resources used in Services’ • We went on to clarify what is meant by the terms Budgeting, Accounting and Charging, and to • Explain the types and classifications of cost

S3Ap1

Session Objectives

This overview session looks at the ITIL Service Management publication, Service Design which is the second of the five lifecycle Stages. The book provides guidance to help with the design of new or changed services and Service Management processes. The Service Design book describes the Design coordination, Service Level Management, Availability Management, IT Service Continuity Management, Capacity Management Service Catalogue Management, Information Security Management and Supplier Management processes. In this overview session you will: • Identify the main purpose and objectives of Service Design • Understand the value of Service Design to the business • and be familiar with the 4 ‘P’s of Service Design

S3Ap2

Introduction to Service Design

The Service Design stage of the lifecycle begins with a set of new or changed business requirements. It ends with the development of a service solution that meets the documented needs of the business. The associated Service Design Package or SDP contains all the Design information required for the testing, introduction and operation of the service solution. The Service Design book describes five aspects which should be considered during the Design stage: • The design of Service solutions for new or changed services • The design of Management information systems and tools especially the Service Portfolio which includes the Service Catalogue • The design of the technology architectures and management architectures • The design of the required processes • And the design of the measurement systems, methods and metrics. So what does this mean in practice? To design value-adding and innovative IT service solutions may require new skills and knowledge. To transition and manage the solutions may demand new architectures, new processes, new suppliers, significant business changes and improved governance. It’s in the Service Design stage where the requirements are identified, analysed, matched against the Service Strategy, specified and, once agreed, the solutions built.

S3Ap3

Purpose and Objectives

The main purpose and objectives of Service Design are:



39

3A


ITIL Foundation

‘To design IT services, together with the governing IT practices, processes and policies. To realize the service provider’s strategy and to facilitate the introduction of these services into supported environments ensuring quality service delivery, customer satisfaction and cost-effective service provision. The main objectives of Service Design is to design IT services so effectively that minimal improvement during their lifecycle will be required. However, continual improvement should be embedded in all service design activities to ensure that the solutions and designs become even more effective over time, and to identify changing trends in the business that may offer improvement opportunities. Service design activities can be periodic or exception-based when they may be triggered by a specific business need or event

S3Ap4

Scope

ITIL Service Design provides guidance for the design of appropriate and innovative IT services to meet current and future agreed business requirements. It describes the principles of service design and looks at identifying, defining and aligning the IT solution with the business requirement. It also introduces the concept of the service design package and looks at selecting the appropriate service design model. This publication covers the methods, practices and tools to achieve excellence in service design. It discusses the fundamentals of the design processes and attends to what are called the ‘five aspects of service’. Additionally ITIL Service Design enforces the principle that the initial service design should be driven by a number of factors, including the functional requirements, the requirements within service level agreements or SLAs, the business benefits and the overall design constraints. Service Design will also be tasked with the design of secure and resilient IT infrastructures, environments, applications and data/information resources and capabilities that meet the current and future needs of the business and customers. IT Service Continuity, Information Security and Availability Management provide significant help here. And finally Service Design will be involved in the measurement methods and metrics for assessing the effectiveness and efficiency of the design processes and deliverables. To ensure continuous improvement requires agreement on what can be measured, what must be measured and what should be improved.

S3Ap5

Purpose and Objectives - continued

Continued development of the skills and capabilities within IT is important in every organization and this is another important objective of Service Design. Commonplace as well as specialist skills are needed throughout the Service lifecycle. Some specialist skills will be developed through user training whereas others may need to be hired in from specialist consultants. Service Design ensures that the solutions they help to buy and build for the business are useable by the business and are supportable by IT staff. This requires business change, benefits realisation and staff training programmes to be developed. Service Design will also contribute to the improvement of the overall quality of IT service within the imposed design constraints. Wherever sensible, Service Design tries to re-use or exploit existing components and services. This requires detailed knowledge of the potential as well as operational services and their components. The up-to-date Service Portfolio, Service Catalogue, Service Design Package and Configuration Management System provide a useful source of that knowledge.

S3Ap6

Critical Success Factor and Key Performance Indicators



40

3A


ITIL Foundation

So what is a CSF? A CSF is a Critical Success Factor, it’s ‘Something that must happen if a Process, Project, Plan, or IT Service is to succeed‘. For example high level CSFs for a supermarket could include ‘Image in financial market; Market share’. Measures or KPIs and targets must be set for each of these CSFs. KPIs are Key Performance Indicators. These are metrics that are used to help manage a Process, IT Service or Activity. KPIs may concentrate on Efficiency, Effectiveness, and Compliance. An ‘Objective’ is the defined purpose or aim of a process, an activity or an organization as a whole. Objectives are best expressed in SMART terms, in other words, ‘Specific, Measurable, Agreed, Realistic and Trackable’. A ‘Metric’ is something that is measured. Availability or response times are typical examples. A ‘Measurement’ often states how it will be measured. Availability as a percentage and response time in seconds measured from time the enter button is pressed to the time a useful message is seen on the screen are typical examples.

?

S3Ap7

Activity

The table contains four statements. The activity here is to decide whether these are Measures, Metrics, KPIs or CSFs. Place the most relevant ‘term’ alongside each statement. Once you’re happy with your choices, click the submit button. Feedback The table should look something like this.

S3Ap8

4Ps - People, Partners, Products, Processes

In a 1995 study of US army IT projects, only 5% were used with minor changes and a miniscule 2% were used as delivered. The remainder were either abandoned in the design transition stages or delivered but never used. The cause may be a combination of many things, for example insufficient diligence when identifying and agreeing business and technical requirements, rushed development or limited testing. Service Design suggests that the probability of success is much higher if four important areas are considered, namely People, Partners/ Suppliers, Products/ Technology and Processes - naturally enough, they are referred to as the four Ps. People - refers to the manpower in the organization and the capabilities of that manpower. People make things happen, for example, the staff on the Service Desk provide a primary point of contact between IT and the users. Therefore they need capability, including the skills and knowledge and resources, such as information about previous calls. Given the capability and resources the Service Desk will restore the service to the users as agreed in the SLA.

S3Ap9

4Ps - People, Partners, Products, Processes

Partners/Suppliers are normally the external suppliers, manufacturers and vendors who help to support the IT Service Supplier. Many organizations have a preferred supplier policy and Supplier Management



41

3A


ITIL Foundation

ensures the correct relationship is maintained. Typically partners, both customer and supplier, work very closely with each other and often share confidential business plans and information. Products/Technology may be things which are provided, including databases, network monitoring tools or documentation such as project plans. Products are considered to be part of the delivered service. Finally, there are the Processes. We looked at what a Process is and its make up in the introductory session. One final point - it is important that all four areas, People, Partnerships/Supplier, Products/Technology and Processes, are integrated to get the best out of best practice Service Management.

?

S3Ap10

Activity

Which of these is the CORRECT description of the Four Ps of Service Design? Feedback The four Ps are People, Processes, Partnerships and Products and these are the main areas to be considered in the design of effective Service Management.

S3Ap11

Service Catalogue Management

We’ll spend the remainder of this session looking at the Service Design Processes. These include Design Coordination, Service Catalogue Management, Service Level Management, IT Service Continuity Management, Availability Management, Capacity Management and Supplier Management and Information Security Management. The first process we’ll look at is Service Catalogue Management. The Service Portfolio should contain all the future requirements for Services and is produced as part of Service Strategy. The Service Catalogue should provide details of all Services currently being provided. It is required for customer and Supplier Management as it shows the details of all operational and proposed services. A Service Catalogue is like a shopping catalogue, it states what is available to purchase, what it looks like, what it does, how much it costs and when it can be delivered. Much like a menu in a fast food restaurant which illustrates the food choices available along with prices, size and flavors. To support the Services described within the catalogue may require a complex infrastructure of Suppliers, Contracts, Agreements, Products, Technologies and People.

S3Ap12

Service Level Management

The second Service Design process we’ll look at is Service Level Management or SLM. The main objective of this process is to; plan, implement, control, review and audit the services and service provision to meet customer business requirements. This includes negotiation, implementation and monitoring of Service Level Agreements, and the on-going management of operational facilities to provide the agreed levels of service.



42

Overview of Service Design

3A

®

ITIL Foundation

Service Level Management therefore ensures an agreed level of IT Service is provided for all current IT Services and that future services are delivered to agreed achievable targets. To achieve these objectives SLM will work closely with clients to determine Service Level Requirements or SLRs and negotiates and creates the service level agreement or SLAs. An SLA is a written agreement between and IT Service provider and the customer or customers, defining the key service targets and responsibilities of both parties. An SLA can contain different headings and cover many different aspects, here are three examples: • ‘Availability’ such as reliability and uptime • ‘Capacity’ such as transaction throughput and response times • ‘Service Continuity’ for example, protection and recovery conditions The Supplier Management process will need to ensure that the Underpinning Contracts or UCs are fair and workable. Service Level Management helps to define internal agreements such as the Operational Level Agreement or OLAs.

?

S3Ap13

Exercise

We have already mentioned three examples showing what might be covered in an SLA. What would you expect an SLA to cover? Try creating a list of ‘headings‘ you think would be relevant. Once you’ve done this, have a look at our model answer shown here. Feedback Here are some typical examples of the headings you could expect to see in a Service Level Agreement. You may have different headings from those shown.

S3Ap14

IT Service Continuity Management

The third Service Design process we’ll look at is IT Service Continuity Management or ITSCM. This four phase process supports the organization’s Business Continuity Management or BCM. BCM is the business approach that ensures that the company’s main business activities can continue after a major event that has a large business impact. When business activities rely on IT Services, it is the responsibility of the IT organization to recovery the related Services in an agreed timescales. BCM covers the whole of the business, whereas ITSCM concentrates on IT Services. For example within UK local authorities the Chief Executives and the Category One Responders (the emergency services) must meet their legal obligations under the terms of the Civil Contingencies Act of April 2006. As an aspect of requirements and Strategy, the process helps to manage the risks to different services and identify contingency options.



43

3A


ITIL Foundation

For example if power failure is likely then the Service will be unavailable. The contingency option is to have an Uninterruptible Power Supply such as a standby generator. If Data Protection and confidentiality may be breached via Phishing and Viruses then Firewalls and Virus scanning may help to protect and prevent this. The Implementation and Operational Management phases are involved in co-ordinating the planning, designing, testing and maintenance procedures and contingency plans. These phases should help to reduce exposures and ensure agreed levels of continuity.

S3Ap15

Availability Management

Our next Service Design process is Availability Management. Availability Management defines, analyses, plans, measures and improves the availability of IT Services. Put simply, availability is ‘up time’. The service is available where you want it and when you want it. However Availability management also focuses on the reasons for any unavailability. A business can have any level of availability it wants, provided it is prepared to pay for it. We’ll look at this later when we discuss Six Sigma. The business is usually interested in ’end to end‘ availability of the service and not directly concerned about the availability of individual components such as a router. The Availability Manager is interested in both. The availability of a service is influenced by the complexity and reliability of components, people, processes and systems. Non-availability of key services can result in loss of productivity and revenue. For example, low level availability in the derivatives dealing room of a Bank could be disastrous. Very high levels of availability are needed in aircraft and other safety critical systems.

S3Ap16


Understanding Vital Business Functions is critical to Service providers. VBFs are used to reflect parts of business critical processes. In the example of an ATM (Automated teller machine) - the VBF would be the dispensing of the cash, and not mobile phone top ups or dispensing of a receipt or such like.

Availability Management must have a close working relationship with almost all the Design and Operation functions and processes. The closest process links are between Capacity, Service Level, Continuity, Security, Supplier and the Problem Management processes. The main output produced by this process is the Availability Plan. This plan will provide everybody in the organization with information relating to the Availability of the services over a reporting period, as well as providing details of initiatives that the Service Provider will be undertaking to sustain or improve future availability. This plan is produced in conjunction with the financial management reports and will require regular review.

S3Ap17

Capacity Management

Let’s move on to our next process, Capacity Management.



44

3A


ITIL Foundation

Capacity Management operates three sub-processes. These are; Business Capacity Management or BCM, Service Capacity Management or SCM, and Component Capacity Management or CCM. BCM involves the business considering its future demands for new or enhanced services. Much of Capacity Management is involved in predicting the long term changes to services that need to be initiated to meet the future growth and increasing demands of the business. SCM requires information regarding operational services such as peaks and troughs or potential breaches of the SLA. Capacity Management will identify where capacity need to be load balanced against the demand and supply. This might mean capacity is increased, re-distributed or reduced. CCM requires knowledge of technology, for example to decide: • how much storage space will be needed to archive emails • how to triple the number of transactions without increasing network bandwidth • or how to reduce the size of application programmes or speed up access to data There are many Capacity monitoring and analysis tools that provide early warning or prediction of capacity problems. Task Manager on your PC is a typical example. As in all ITIL based processes a plan is produced. The main output of this process is the Capacity Plan, As the Capacity Plan is an investment plan it is best to produce it in line the business budget lifecycle. It needs to be reviewed regularly, for example: • before mergers, or post down-sizing of the organization, • when changing suppliers or partners • and pre and post major change activities

?

S3Ap18

Exercise

A fast food company is bidding for a franchise to open a restaurant near Luton, England. How can Capacity Management, Service Level Management, Availability Management and Continuity Management help to ensure the restaurant is viable? Try putting together a list of two factors for each process. Once you’ve completed the exercise, compare your ideas to our model answers.

S3Ap19

Supplier Management

Time for our fifth Service Design process, Supplier Management. Supplier Management identifies potential suppliers and manages existing suppliers to ensure they deliver the products and services that achieve the results agreed. Supplier management is concerned with ‘the management of suppliers and the services they supply, to provide seamless quality of IT service to the business, ensuring value for money is obtained’. Supplier Management is involved in the complete Service lifecycle, from strategy - when a choice of strategic supplier might be made - through, design and procurement. Supplier Management is also involved through transition and change to operation and contract management to the termination of a contract.



45

3A


ITIL Foundation

Supplier managers need to understand the IT environment and how their organization sources and manages external partners. They may are involved in the selection of suppliers and tendering and procurement processes. They also provide advice on creating and changing service or supply contracts, working closely with legal specialists and with Service Level Management to ensure the terms and conditions underpin the SLA. They manage the day to day contract and ensure suppliers deliver what is expected. Many organizations use preferred suppliers and maintain a list of these suppliers. In the government sectors suppliers my need to be Security vetted. The process you use for selecting suppliers may have to follow rules, for example EU rules and regulations. The Supplier and Contract Management Information system is the main tool which holds information about suppliers.

S3Ap20

Information Security Management

Our sixth process is Information Security Management. Information Security Management helps with the selection, design, implementation and operation of information security controls. It also ensures the confidentiality, integrity, availability, accountability and relevant compliance of information systems. Some of this work is managed on a day to day basis by Access Management, which will be covered in the session on Service Operation. Information Security Management also ensures that an Information Security Policy is maintained and enforced to fulfil the needs of the Business Security Policy and the requirements of corporate governance. More specifically they conduct security control reviews to identify security threats to services and data, conduct risk assessments and recommend actions. They may also be involved in forensic investigations, for example in the review following breaches of security. The policy they produce may mandate different types of security controls to comply with legislation for example, dealing with data protection or copyright laws. In order to work successfully, Availability, IT Service Continuity, Access and Information Security Management maintain very close relationships.

S3Ap21

Design Coordination

Our final process to consider is Design Co-ordination. The activities undertaken within the service design stage are detailed and complex. Only through wellcoordinated action can a service provider hope to create comprehensive and appropriate designs that will support the achievement of the required business outcomes. The purpose of the design coordination process is to ensure the goals and objectives of the service design stage are met by providing and maintaining a single point of coordination and control for all activities and processes within this stage of the service lifecycle.



46

3A


ITIL Foundation

A key role in Service Design is that of the Design Manager: Let’s summarize some of their key responsibilities: • • • • • •

To design services in line with strategy To design functional requirements of the services The production of quality, secure and resilient designs for new or improved services To produce and maintain all design documentation To produce all Service Design Packages, or SDPs And to measure the effectiveness and efficiency of the service design process

S3Ap22

The value to the Business

There are many ways in which Service Design can add value to the business. Here we will outline some of the main benefits as outlined in the Service Design publication. Firstly by reducing the Total Cost of Ownership or TCO. This can only be minimised if all aspects of services, processes and technology are designed properly and implemented against the design. Service Design can add value by providing improved Quality and Consistency of Service or QoS. For example, Availability Management will help to identify which specific service components need upgrading, replacing or duplicating. Capacity Management on the other hand, ensures that there is always enough server space or network bandwidth to provide the response times required by the business, even during peak demand. Easier implementation of new or changed Services can be regarded as another value-add. Considering the business or functional requirements and the frequently ignored technical or non-functional requirements, then test cases can be created for each requirement. This is done as and when they are agreed. The Service Design Package or SDP is also kept up to date. By doing so, a service that is both reliable and supportable is released on time and on cost. Active involvement from the conception of the service, ensuring that new or changed services match business needs, with services designed to meet Service Level Requirements or SLRs and contracts results in Improved Service Alignment. Service Level Management is responsible for managing the ’client expectations and relationships‘. They negotiate and agree requirements via the Service Level Agreement and other documents. Supplier Management are responsible for the ’upstream‘ suppliers. They may be involved in selecting suppliers, outsourcing work, procuring products as well as managing and terminating the contracts.

?

S3Ap23

Activity

Consider and then prioritise to following statements in terms of which might deliver most 'value' as perceived by sales staff for an email service. Feedback Yes, this is probably the best option but we'd need more information. Do sales staff care about options C and D? And if sales only deal with this country does option A matter either? No, this is not really the best option. We really need more information. Statement D says nothing useful at all so would probably be bottom of our priority list. Do sales staff care about options C?

S3Ap24 ITIL® is a Registered Trade Mark of the Cabinet Office.

The value to the Business The Swirl logo™ is a Trade Mark of the Cabinet Office.

47

3A


ITIL Foundation

Let’s consider some further benefits of Service Design. Capacity, Financial, Availability and IT Service Continuity Management work with Technical and Application ’Architects‘ and the Business. By doing so they help to ensure that agreed performance are achievable, resulting in more effective Service Performance. Another significant benefit is improved IT Governance. This is a major area for Information Security Management. Defining the frequency and location for back-ups or ensuring compliance with Data Protection is a typical example. However they are not alone, as all Processes and Functions within Service Management are impacted by rules, standards and regulations. Governance may be also be imposed on the business, for example for US linked organizations must comply with ‘Sarbanes Oxley’. Service Design processes will be designed with optimal quality and cost-effectiveness resulting in more effective Service Management and IT Processes. ITIL suggests you adopt and adapt, if a process already works in your organization don’t change it. Improved Information and decision-making is another benefit. There are many process ‘databases’ that make up a Service Knowledge Management System or SKMS, such as the Service Portfolio with its component Pipeline and Catalogue; the Supplier and Contract Management Information System ; The Service Design Package and many others. Decisions made are based on reliable data, information and knowledge provided by these integrated databases.

S3Ap25

Summary

This concludes this overview session where we have been examining the ITIL Service Management publication, Service Design. We began the session by Identifying the main purpose scope and objectives of Service Design. We introduced you to the 8 processes primarily concerned with the Service Design stage of the Service Lifecycle, including the introduction of the main role concerned with activities throughout Service Design the Service Design Manager. We went on to outline some of the value which Service Design can add to the business. Finally we described the 4 Ps of Service Design, namely People, Partners/Supplier, Products/technology and Processes and concluded the session by looked at the eight processes associated with Service Design.

?

S3AQ

Topic Quiz

Welcome to the topic quiz for this session. Here we will present you with a few questions based on the principles we have covered so far. Don’t feel under pressure as your answers are not scored. Good luck!



48

3B

Supplier and Service Level Management ®

ITIL Foundation

S3Bp1

Objectives

In this session we will be examining two ITIL processes, Service Level Management, which is the subject of chapter 4.3 of the Service Design book and Supplier Management which is the subject of chapter 4.8 The first part of the session will focus on Service Level Management. Once you have completed it you will: • • • • • •

Understand the purpose of Service Level Management Be aware of some of the important process terminologies Be familiar with the Service Level Management process Have seen the makeup of a Service level Agreement Understand the key responsibilities of the Service Level Manager Be aware of the key process roles

The later part of the session focuses on Supplier Management. Once completed, you will: • Understand the purpose of Supplier Management • Have seen the Supplier Management process and associated sub-activities. • Be able to identify the four supplier categorisation types and the critical success factors associated with the process.

S3Bp2

Process - scope

Let’s begin this lesson by defining the scope of the Service Level Management process. One of the main Service Level Management responsibilities is proposing, negotiating and maintaining Service Level Agreements (SLAs). SLAs form an agreement between the IT Provider and the Customer. Also within the scope of this Service Level Management process is the establishment of internal Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). We will look at each of these documents a little later in the session. SLAs provide an important method of measuring IT Service quality and the Service Level Management process as a whole. This in turn, helps to drive the Continual Service Improvement Programme. Service Level Management is an important aspect of any IT operation, making sure that the level of service required is understood, operated, monitored, and delivered to its full potential - and all within budget! And of course provides the Service Provider and the business with an opportunity to regularly meet to discuss targets met, any breached targets, reasons for any breaches and what initiatives are being under taken to improve service, meet any new service needs or review any existing targets regarding Service requirements and needs.

?

S3Bp3

Activity

When establishing a new SLA, or amending an existing one, which of the following should the Service Level Manager take into account? Feedback All of these statements would be taken into account when establishing a new or amending an existing SLA.



49

3B S3Bp4


ITIL Foundation

Process purpose

The Service Design book of the ITIL library defines the purpose of Service Level Management as: The purpose of the SLM process is to ensure that all current and planned IT services are delivered to agreed achievable targets. This is accomplished through a constant cycle of negotiating, agreeing, monitoring, reporting on and reviewing IT service targets and achievements, and through instigation of actions to correct or improve the level of service delivered. Additionally the scope covered by this process are the: • • • •

Definition of the service Production and maintenance of an accurate service catalogue Interfaces, dependencies and consistency between the Service Catalogue and Service Portfolio Interfaces and dependencies between all services and supporting services within the catalogue and the Configuration Management System CMS • Interfaces and dependencies between all services and supporting components and Configuration Items CIs

S3Bp5

Process - objectives

The Service Level Management process has a number of clearly defined objectives namely to: • • • • • •

Define, document, agree, monitor, measure, report and review the level of IT services provided Provide and improve the relationship and communication with the business and customers Ensure that specific and measurable targets are developed for all IT services Monitor and improve customer satisfaction with the quality of service delivered Ensure that: IT and the customers have a clear and unambiguous expectation of the level of service to be delivered proactive measures to improve the levels of service delivered are implemented wherever it is cost-justifiable to do so

S3Bp6

Basic Concepts

So far in the session, we’ve mentioned several acronyms with which you may not be familiar. So let’s take a few minutes to look at some important Service Level Management terminology. The first of these and one you may be familiar with is Service Level Requirements (or SLRs). SLR documents are produced to help Service Level Management understand how the business is thinking with regard to the IT service it requires. So the contents of an SLR are based on business objectives, and are used to negotiate agreed Service Level Targets. A Service Level Agreement (or SLA) is a document expressing targets, measurements and other service stipulations. It will also document the roles and responsibilities of both IT and the business, to reduce the risk of misunderstandings and omissions. An Operational Level Agreement (or OLA) is an internal document underpinning the SLA. It forms an agreement between the IT Service Provider and another part of the same organization. For example an OLA might exist between the Service Desk and a Support Group to provide incident resolution with an agreed timeframe.



50

3B


ITIL Foundation

An Underpinning Contract (or UC) is an external contract underpinning the SLA. It is a contract between the IT Service Provider and a third party. Finally, a Service Improvement Plan (or SIP) is a formal plan to implement improvements to a process or IT service.

?

S3Bp7

Activity

Here’s a quick question for you. Which Service Level Management document would form an agreement between an internal IT department and an external supplier? Feedback A UC (or an Underpinning Contract) forms the agreement between an internal department and an external supplier.

S3Bp8

Process Overview - Part 1

On the previous page, we reviewed some important Service Level Management terminology. Here we will see how these fit into the Service Level Management process as a whole. We begin this overview of the SLM process assuming that the process has been planned and implemented. From this point the process can be divided into two distinct stages: Activities in the implementation stage would include the Service Level Manager gaining a thorough understanding of the business requirements (or SLRs). To assist the business in clearly understanding what services are currently available and to assist with the negotiation of new services, the Service Level Manager should ensure that an up-to-date Service Catalogue is made available to the business. Having gained an understanding of the requirements, the Service Level Manager is now in a position to design a draft Service Level Agreement and negotiate any changes in Operational Level Agreements and Underpinning Contracts, or to return back to the business to rework expectations and requirements. After an iterative cycle of negotiation with both areas, the SLM will be able to agree and publish the first version of the SLA. This leads us onto stage two.

S3Bp9

Process Overview - Part 2

Stage two of the Service Level Management process involves the on-going management of the process and monitoring the service over an agreed period. The Service Provider will prepare and publish reports on Service Levels and these will be reviewed against the targets with the business. An outcome of these reviews will be proposals or Requests for Change. These Requests for Change will feed into the continual service improvement approach to be adopted by the Service Provider. An additional responsibility of the Service Level Manager is to review both SLAs themselves and the Service Level Management process as a whole, to ensure that continual improvement of the process is maintained.



51

3B


ITIL Foundation

It’s also worth highlighting here the relationship between SLM and Supplier Management. Supplier Management manages external suppliers, ensuring that underpinning contracts are created, which in turn help meet the service level objectives agreed and documented in SLAs. These SLAs are themselves underpinned with OLAs.

S3Bp10

Service Level Framework

Service Level Requirements often change over time and it is necessary to maintain the service levels in line with business requirements. This means checking with the other providers. Operational Level Agreements need to be changed to support any changes to the customer SLAs. Regular reviews of the agreements and contracts will be required at appropriate intervals. SLAs will need to change over time and they tend to be either Service-based - where, for example, the email service is largely the same for everyone in the organization, or Customer-based, where, say, the Finance Department needs a particular set of SLAs for its accounting and billing systems. SLAs can be multi-level, for example: •

Multi-Level Corporate level - covering generic issues that are appropriate for the organization. Corporate level SLAs tend to change less frequently.

•

Customer level - where SLAs relate to a particular Customer, such as Finance or Marketing, and

•

Service level - which cover issues relevant to a particular service.

This layering of SLA’s is known as a multi-level SLA Framework. Another responsibility of Service Level Management is to initiate actions for Service Improvement Programmes (or SIPs). This is a continuous activity that proactively seeks new effective, efficient and cost-effective ways to deliver the service. This forms part of ‘Continual Service Improvement’.

S3Bp11

Example SLM Structure

To provide effective Service level Management, the IT provider should consider a number of sourcing approaches and options. One approach is to utilise the internal organisational resources. This is known as Insourcing. Insourcing can be further classified as either of two types. Type I uses internal IT to support one business area. Type II uses internal IT to support many business areas, in other words - Corporate. An alternative approach might utilise resources external to the organization, this is known as Outsourcing, and we have identified it here as Type III. The use of Type I, II or III approaches will be a strategic decision and therefore will be an input to Service Design. Other sourcing approaches might include:



52

3B


ITIL Foundation

Co-sourcing or multi-sourcing - this is often a combination of insourcing and outsourcing. Partnership - these are formal arrangements for two or more external organisations to work together to support the service provider, as opposed to outsourcing, which typically, would involve one external partner. Business Process Outsourcing - is the relocation of entire business functions or processes to another organization for management. Application Service Provision - involves formal arrangements with an Application Service Provider (or ASP). Knowledge Process Outsourcing - for the provision of domain-based processes and business expertise. KPO is a step ahead of BPO in one respect. Cloud - Cloud service providers offer specific predefined services usually on demand. Services are usually standard but can be customized to specific organizational needs. These services can be offered internally but generally refer to outsourced service provision. Multi-vendor sourcing - This type of sourcing involves sourcing different sources from different vendors offering a combination from the different sourcing options listed. The diagram on screen illustrates how these might be related to the Service Level Management process responsibilities.

?

S3Bp12

Activity

Try answering this revision question.

S3Bp13

Example SLA Contents

Here we will take a more detailed look at the contents of a typical Service Level Agreement. Remember we mentioned earlier that a Service Level Agreement describes the IT service, documents, service level targets, and specifies the responsibilities of the IT Provider and the Customer. Here are some example headings you could expect to see within Service Level Agreement. Service Description and Scope - this will include parties to the agreement, title and brief description, signatories, dates for start, end dates, reviews, scope and responsibilities and description of services covered. Service Hours - For example, ‘The Service Desk is available from 0800-1800 Monday to Friday. There is no Service at weekends or on public holidays’. Service Availability - a target of, say, 99%, or Service Unavailability over an agreed timescale. Reliability - this is another measurable target. For example, 2 breaks of service per year or measured as Mean Time Between Failures (or MTBF). Customer Support - Self-help information and the Service Desk telephone number. Contact Points and Escalation - a list of all parties involved in the agreement.



53

Supplier and Service Level Management

3B

®

ITIL Foundation

Service Performance - the expected responsiveness of the IT service. Batch Turnaround Times - for delivery of input and the time and place for delivery of output.

S3Bp14

Example SLA Contents - continued

Change - targets for approving, handling and implementing RFCs based on the category/urgency/priority. IT Service Continuity/Security - brief mention of any ITS Continuity Plan actions and how to invoke them, with coverage of any security issues such as customer responsibilities, for example, backing up standalone PCs or password changes. Charging - details of charging formulae and periods. Outsourcing contracts may be subject to ‘commercial-in-confidence’ contract clauses that would prevent the charging information being listed in this document. Service Reporting and Reviewing - the content, frequency and distribution of service reports and meetings. It’s a careful balancing act to ensure that enough information is included in SLAs without making them overly complex and unmanageable. A general rule is not to include things that cannot be measured.

S3Bp15

Process - metrics

ITIL guidance suggests the following metrics and Key Performance Indicators (or KPIs) to judge the effectiveness and efficiency of the Service Level Management process. •

The number or percentage of service targets being met

•

The number of, and severity of service breaches

•

The number of services with up to date SLAs

•

The number of SLAs supported by OLAs and/or UCs

•

Regular review meetings and reports

A more subjective KPI would be Improvements in Customer Perception.

S3Bp16

Role of Service Level Manager

It is important to note that there needs to be a very close working relationship between the roles of the Service Level Manager and the role of the Business Relationship Manager. While the SLM process exists to ensure that agreed achievable levels of service are provided to the customer and users, typically focussing on the operational day to day service achievements, breaches, the Business Relationship Management process is focused on a more strategic perspective. Business relationship management takes as its mission the identification of customer needs and ensuring that the service provider is able to meet the customers’ needs. This process focuses on the overall



54

3B


ITIL Foundation

relationship between the service provider and their customer, working to determine which services the service provider will deliver.

S3Bp17

Role of Service Level Manager

As the owner of the Service Level Management process, the Service Level Manager has the following responsibilities. Firstly they must ensure that the processes involved run efficiently and effectively and are monitored and audited on a regular basis to identify weaknesses and implement improvements. They will also act as a champion for Service Level Management throughout the organization, and will maintain awareness of process for all interested parties. They will maintain all appropriate standards and identify and shape policy. More specifically, they will be responsible for: •

Awareness of changing business needs.

•

Negotiating and agreeing levels of service, SLAs and OLAs

•

Assisting with the production and maintenance of the Service Portfolio, Service Catalogue and Application Portfolio.

•

Ensuring that all changes are assessed for their impact on all service levels.

•

Measuring, recording, analysing and then identifying ways of improving customer satisfaction.

In addition to the Service Level Manager, there are some other roles that interface with Service Level Management namely: • • • • • • •

Business Relationship Manager The Process Owner Service Design Manager Service Catalogue Manager Supplier Manager IT Planner IT Designer/Architect

S3Bp18

Process - benefits

There are a number of wide-ranging benefits to be gained from the successful implementation of a Service Level Management process. Having a service that is seen to be delivered against measured targets allows for the development of confidence within the business towards the IT supplier. This in turn, will allow customers to weigh service against charges and be able to measure the service in terms of Value for Money. A basis for charging for ‘standard’ and ‘extra’ levels of service can be established, providing benefits for the Financial Management process.



55

Supplier and Service Level Management

3B

®

ITIL Foundation

Consistent service monitoring will allow the Service Provider to show strengths and identify weaknesses, enabling the establishment of improvement targets. Additional benefits include: •

A greater potential for cost reduction in long term

•

Agreed conflict resolution routes can be established which allow for service improvement activities

•

Business demands will be more predictable

And finally, but of equal importance, there’s great potential for improved relationships and highly satisfied customers

S3Bp19

Supplier Management Objectives

Having completed our look at Service Level Management, let’s move on to the second subject in this session, namely, Supplier Management which is the subject of chapter 4.8 of the Service Design book of the ITIL library. The Supplier Management process exists to ensure that suppliers and the services they provide are managed in order to support IT service targets and business expectations, ensuring value for money for the business. For this process to work effectively, it is important to recognise the point at which the responsibility of the external organization ends and the internal IT provision starts. Scope of this process is the: •

Implementation and enforcement of the supplier policy

•

Maintenance of an Supplier and Contract Management Information System (SCMIS)

•

Supplier and contract categorization and risk assessment

•

Supplier and contract evaluation and selection

•

Development, negotiation and agreement of contracts

•

Contract review, renewal and termination

S3Bp20

Process - purpose

The purpose of Supplier Management is to obtain value for money from suppliers and to ensure that suppliers perform to the targets contained within their contracts and agreements, while conforming to any terms and conditions which might exist. All Supplier Management process activity should be driven by a supplier strategy and policy from Service Strategy. This is the starting point for designing the external services that will be provided by suppliers. Information relating to all elements of the process will be fed into the Supplier and Contract management information system. Sub-process activities will include:



56

3B •


ITIL Foundation

The evaluation and procurement of new contracts and suppliers. This requires Supplier Management to form ‘partnerships’ based on openness, rather than the traditional hierarchical relationships. By sharing risks and rewards and taking collective responsibility, both parties derive benefit from the relationship.

Other activities include: •

Establishing new suppliers and contracts.

•

Supplier and contract categorisation (we’ll look at this in more detail shortly), and

•

Managing the supplier and contract performance. This will involve identifying business needs and the preparation of a Business Case.

•

Ensuring that supplier selection meets business expectations is another important activity.

Finally, Supplier Management also deals with contract renewal and or termination.

S3Bp21

Supplier Categorization

The Supplier Management process should be adaptive and spend more time and effort managing key suppliers than less important ones. As such some form of categorisation process should exist. Assessing the risk and impact associated with using a supplier, and the value and importance of the supplier can be an effective categorisation technique. ITIL suggests four categorisations. These are Strategic, Tactical, Operational and Commodity. Strategic categorisation addresses the relationships at senior management level. Tactical categorisation addresses those relationships which involve a lot of commercial activity and would normally be dealt with by middle management. Operational level is for suppliers of operational products or services and managed by junior operational management. Finally, Commodity is intended for suppliers who provide low value or readily available products or services which could be sourced elsewhere without too much effort.

S3Bp22

Critical Success Factors

ITIL defines four Critical Success Factors for the Supplier Management process. Let’s look at each in turn. Firstly, the business needs to be protected from poor supplier performance or disruption. It’s important that the person managing the process has the authority to terminate a contract, if support from an outside supplier was below expected levels. Secondly, supporting services and their targets need to align with business needs and targets. Thirdly, availability of services is not compromised by supplier performance. Suppliers should be measured and monitored by the supplier manager and supplier performance shouldn’t compromise the availability of services provided to customers.



57

3B


ITIL Foundation

Finally, there needs to be clear ownership and awareness of supplier and contractual issues. For example, the penalties or incentives in providing the service should be clearly understood by both the supplier manager and the suppliers.

S3Bp23

Summary

This concludes the session on Service Level Management and Supplier Management. We began this session by looking at the Service Level Management process. •

We identified the purpose of SLM, which is ‘to maintain and gradually improve business-aligned IT service quality through a constant cycle of agreeing, monitoring, reporting and reviewing IT service achievements. Corrective actions are taken to eradicate unacceptable levels of service’

•

We looked at the Service Level Management process in some detail, including how Service Level Requirements (SLRs) are identified, negotiating Service Level Agreements (SLAs), as well as monitoring, reporting on, and reviewing SLA targets

•

We outlined how SLA structures are Service-based, Customer-based, and Multi-level, and as formal agreements with customers, are supported by internal Operational Level Agreements (OLAs) and external Underpinning Contracts (UCs)

•

We described how Service Level Management drives Service Improvement Programmes/Plans (SIPs) to enhance the quality of services

In the later part of the session we looked briefly at the Supplier Management process. We identified the purpose and scope of the process and looked at the Supplier Management process and associated sub-activities. We described the four supplier categorization types and outlined some of the critical success factors associated with the process.



58

3C

Service Catalogue Management ®

ITIL Foundation

S3Cp1

Objectives

The subject of this session is Service Catalogue Management which is covered in chapter 4.2 of the ITIL Service Design publication. In this session we will: •

State the purpose, scope and objectives of Service Catalogue Management

•

Identify the relationship between the Service Catalogue and the Service Portfolio

•

Identify the two Key Performance Indicators

•

Identify the role of the Service Catalogue Manager

S3Cp2

Process - purpose, scope, objectives

The subject of this session is Service Catalogue Management. You may recall that we mentioned this subject in the session on Service Strategy earlier in the course. The Service Catalogue Management process is covered in detail in the Service Design publication, hence our focus here. The purpose of the service catalogue management process is: ’to provide and maintain a single source of consistent information on all operational services and those being prepared to be run operationally, and to ensure that it is widely available to those who are authorized to access it’. Service Catalogue Management provides a single source of consistent information on all the agreed services, and ensures that the information is widely available to those who are approved to use it.

S3Cp3

The Service Catalogue and the Service Portfolio

As you can see from this diagram, the Service Catalogue forms part of the Service Portfolio. The Service Portfolio also contains all the future requirements for services or the ‘Service Pipeline’ and the ‘Retired Services’ Over the years, organizations’ IT infrastructures have grown and developed. As a result, there may not be a clear understanding of either the services currently being provided, or the customers of these services. To address this, ITIL recommends the production and maintenance of an IT Service Portfolio, containing a Service Catalogue. This will provide a central, accurate set of information on all services and just as importantly develop a service-focused culture. The Service Catalogue can be presented as a two view catalogue or a three view service catalogue: •

The Business Service Catalogue. This is the customer view of the Service Catalogue and contains details of all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on the IT services.

•

The Technical Service Catalogue. This should underpin the Business Service Catalogue and contains details of all the IT services delivered to the customer, together with relationships to the supporting services, shared services, components and CIs necessary to support provision of the service to the business.



59

3C


ITIL Foundation

•

The three view representation can be very useful to all when looking at how those services are utilised by the many business units - shared service representations. By representation we are referring to the way the catalogue is presented.

•

The different representations of the Service catalogue will depend on the requirements of the organization, and the value-add each representation will bring to the organization.

S3Cp4

Process - KPIs

There are two main Key Performance Indicators that relate to Service Catalogue Management. Firstly, the number of services that have been recorded and managed within the Service Catalogue as a percentage of those being delivered and transitioned in the live environment. The second KPI is to measure the number of variances detected between the information contained in the Service Catalogue and real world situation.

?

S3Cp5

Activity

Can you name the Service Catalogue representations available for organizations to build and use? Feedback The two aspects of the Service Catalogue are the Business Service Catalogue and the Technical Service Catalogue.

S3Cp6

Service Catalogue Manager

ITIL recommends a role to act as a process owner namely, the Service Catalogue Manager. The Service Catalogue Manager has a responsibility for producing and maintaining the Service Catalogue. Other key responsibilities include: •

Ensuring that all operational services and all the services being prepared for operational use are recorded within the Service Catalogue

•

Ensuring that all the information within the Service Catalogue is accurate and kept up to date

•

Ensuring that all the information within the Catalogue is consistent with what is contained in the Service Portfolio, and

•

Ensuring that the information in the Service Catalogue is adequately protected and backed up

S3Cp7

Summary

In this session we have been studying Service Catalogue Management, which is the subject of chapter 4.2 of the Service Design book. In this session we have:



60

3C


ITIL Foundation

•

Stated the purpose and objective of Service Catalogue Management

•

Identified the relationship between the Service Catalogue and the Service Portfolio and identified the two aspects to a Service Catalogue

•

Identified the two Key Performance Indicators

•

Identified the role and key responsibilities of the Service Catalogue Manager



61

3D

Availability Management ®

ITIL Foundation

S3Dp1

Objectives

In this session we will be examining Availability Management, which is the subject of chapter 4.4 of the Service Design book of the ITIL library. When you have completed this session you will: • • • •

Be aware of the main responsibilities of the process. Be aware of the two key elements of the process Understand the purpose, scope and objectives of Availability Management and its guiding principles You will also be familiar with some of the basic concepts of the Availability Management process, including reliability maintainability and serviceability and possess an understanding of Vital Business Functions

Finally you will be aware of the role and responsibilities of the Availability Manager

S3Dp2

Availability Management Overview

It is a fact that IT Infrastructures are becoming ever more reliable and hence availability levels are generally better than they have ever been. Availability is now regarded as one of the most important issues for IT Service Management because, even though reliability has increased, so has the dependence of businesses on their IT services. Availability Management is a balancing act. On one side is the need to deliver the appropriate component and service availability, balanced against ensuring this is done cost effectively. Understanding the business drivers and the need for availability, especially high availability, is essential to acquiring the appropriate investment, which in turn will provide the necessary infrastructure. Availability Management works closely with Service Level Management in setting realistic availability and reliability targets for Service Level Agreements and with other ITIL processes to maintain service levels against these targets. Targets are based on the Service Level Requirements and ensure that appropriate levels of component reliability, serviceability and maintainability are met. Amongst other things, Availability Management monitors and reports on service and component availability and reliability. It also investigates shortfalls and instigates actions to overcome them.

S3Dp3

Process - purpose and scope

IT service availability is critical to almost every organization. To put it simply, if IT stops, then in the majority of cases, business stops. Pressures on availability grow all the time, with customers demanding greater flexibility, extended hours of service and faster processing. This is particularly relevant in a world which operates 24/7, and 365 days of the year such as e-commerce. Effective Availability Management influences customer satisfaction and determines the reputation of the business in the market place.



62

3D


ITIL Foundation

ITIL defines the purpose and scope of Availability Management in the following way: ‘The purpose of the availability management process is to ensure that the level of availability delivered in all IT services meets the agreed availability needs and/or service level targets in a cost-effective and timely manner. Availability management is concerned with meeting both the current and future availability needs of the business.’ Availability management scope covers the design, Implementation, measurement, management and Improvement of IT service and component availability.

S3Dp4


There are six key objectives for Availability Management. These are: •

The production and maintenance of an appropriate and up-to-date Availability Plan, which reflects the current and future needs of the business

•

The provision of advice and guidance to all other areas of the business and IT on all availabilityrelated issues

•

To ensure that service availability achievements meet or exceed all their agreed targets, by managing services and resources-related availability performance

•

Assisting with the diagnosis and resolution of availability-related incidents and problems

•

Assessing the impact of all changes on the Availability Plan and the availability of all services and resources

•

To ensure that proactive measures to improve the availability of services are implemented wherever it is cost-justifiable to do so

S3Dp5

Guiding Principles

An effective Availability Management process can make a significant difference to the business, particularly if its deployment in an IT organization clearly recognises the business needs. To support this business focus, ITIL outlines a number of guiding principles for managing availability. These are: That availability is at the core of customer satisfaction and business success - a direct correlation exists between the service availability and customer and user satisfaction. When things go wrong, it is still possible to achieve business and end-user satisfaction. In other words, the way a service provider reacts in a failure situation has a major influence on customer and user perception and satisfaction. Improving availability can begin once we understand how IT services integrate with and support the business. Service availability is only as strong as its weakest link, in other words, availability can be greatly increased by the elimination of Single Points of Failure (SPOFs) or an unreliable or weak component. We’ll be looking at SPOFs a little later in the session.



63

3D


ITIL Foundation

Availability is not just a reactive process, it is also a guiding principle. The more proactive the availability process the better the service will be. For example the more adept we become at predicting and preventing events, the higher the level of availability will be. The final ITIL principle suggests that, ‘it is cheaper to design the right level of service availability into a service from the start, rather than trying just to ‘bolt it on’ later. Resilience is a key consideration for Availability Management.

S3Dp6

Basic Concepts

Let’s take a few moments to look at some of the basic concepts of Availability Management. As far as the business or end user is concerned, availability or rather unavailability is the key indicator of service quality. Availability in turn, is underpinned by the reliability and maintainability of the IT infrastructure and the effectiveness of the IT support organization. As such, availability will depend on such things as: the reliability of components; resilience to failure; the quality of maintenance and support, and the quality and extent of deployment of operational process and procedures. An IT service that consistently meets its SLA availability targets will have the following characteristics: •

Low frequency of failure, and

•

Rapid resumption of service after an incident has occurred

The standard measure of Availability is ‘Agreed Service Time minus Downtime divided by Agreed Service Time’. The ‘reliability’ of an IT service can be qualitatively stated as freedom from operational failure. The reliability of IT service is determined by: The reliability of each component within the IT infrastructure delivering the IT service, i.e. the probability that a component will fail to provide its required functions Secondly, the level of resilience designed and built into the IT infrastructure, i.e. the ability of an IT component failure to be masked to enable normal business operations to continue. And finally, the levels of preventive maintenance applied to prevent failures occurring. This can also be considered an aspect of Maintainability. Reliability can be measured in the following ways: Mean Time Between Failure (or MTBF) more commonly known as ‘Uptime‘ and Mean Time Between Service Incidents (or MTBSI).

?

S3Dp7

Activity

Now try answering this question. Feedback Agreed Service Time minus Downtime divided by Agreed Service Time is the standard measure of availability. If you wish to review this, skip back to the previous page.



64

3D S3Dp8


ITIL Foundation

Basic Concepts - continued

We briefly mentioned Maintainability a few moments ago. Maintainability relates to the ability of an IT infrastructure component to be retained in, or restored to, an operational state. The maintenance or restoration of the IT infrastructure component after a failure can be divided into 5 separate stages: • • • • •

Incident Detection Incident Diagnosis Incident Repair Incident Recovery Incident Restoration

The Mean Time to Restore Service (or MTRS), is used to measure Maintainability. We will look at the terms MTRS, MTBF and MTBSI in more detail later in this session. Finally, Serviceability describes the contractual arrangements made with a third party provider of services. This is to assure the availability, reliability and maintainability of IT components under their care.

S3Dp9

Terminology

Those of you with a keen ear will recall the acronym SPOF, mentioned a few minutes ago. The Availability Management process has many similar acronyms which you will need to be aware of, so let’s take a few moments to look at some of them now. Firstly, let’s revisit SPOF. SPOF stands for Single Point of Failure, and there could be many SPOFs in an IT infrastructure. SPOFs are components that have no back-up capability and can cause an interruption to users when they fail. The IT infrastructure should be designed for high availability, and as such SPOFs should be found and removed. SPOFs can usually be masked by providing resilience in the design of the infrastructure. The following three terms refer to analysis techniques. To help identify SPOFs, it is wise to carry out CFIA (Component Failure Impact Analysis). CFIA is a fairly simple technique that’s used to identify impact dependencies on organisational skills and competencies among staff supporting the IT Service. It is based on a grid with Configuration Items (or CIs) on one axis and the IT Service with a dependency on the other. Service Failure Analysis (or SFA) analyses the reasons for and impacts of Service Failures - simple really! Fault Tree Analysis (or FTA), is used to determine the chain of events that causes a disruption of IT Services. It draws a distinction between types of events such as basic, resulting, conditional and triggers. This analysis is combined with mathematical evaluation but that is beyond the scope of this course.

S3Dp10

Terminology - continued

We mentioned MTBF, MTRS and MTBSI a little earlier in the session. Each is a common calculation used in Availability Management for measuring ‘uptime’.



65


3D

®

ITIL Foundation

Mean Time Between Failure (or MTBF) is the average time that a Configuration Item or IT Service can perform its agreed Function without interruption. This is measured from when the CI or IT Service starts working, until it next fails. Mean Time to Restore Service (or MTRS) is the average time required to resolve an incident or downtime. Meantime Between System Incidents (MTBSI) is the average time between the occurrence of two successive incidents and would therefore include MTRS. These are shown in context in the next diagram:

S3Dp11

Vital Business Functions

The term Vital Business Function, or VBF, is used to reflect business critical elements of the business process. In the instance of an ATM - the VBF would be the dispensing of the cash, not the mobile phone top up or the dispensing of a receipt. The availability requirements, whether VBFs or not should be determined by the business and not IT. Here are some examples of how some VBFs may influence availability design and associated costs: High availability A characteristic of the IT service that minimizes or masks the effects of IT component failure to the users of a service. Fault tolerance The ability of an IT service, component or CI to continue to operate correctly after failure of a component part. Continuous operation An approach or design to eliminate planned downtime of an IT service. Note that individual components or CIs may be down even though the IT service remains available. Continuous availability An approach or design to achieve 100% availability. A continuously available IT service has no planned or unplanned downtime.

?

S3Dp12

Activity

Try dragging the Availability Management acronyms onto their correct definitions. Feedback The Mean Time to Restore Service (or MTRS) is the average time taken to restore a configuration item or IT Service after a failure. The Mean Time Between Service Incidents (or MTBSI) is the mean time from when a system or IT Service fails, until it next fails. And finally the Mean Time Between Failures (or MTBF) is the average time that a configuration item or IT Service can perform its agreed function without interruption.



66


3D

®

ITIL Foundation

S3Dp13

Process - roles

ITIL guidance recommends a key role to support the Availability Management process, namely that of Availability Manager. As a process owner, there are several important responsibilities. These range from ensuring that the processes involved run efficiently and effectively and are monitored and audited on a regular basis, to identifying weaknesses and implementing improvements. The Availability Manager will be the champion for Availability Management throughout the organization and will maintain awareness of process for all interested parties. Responsibilities also include maintenance of all appropriate standards and identifying and shaping policy. In particular, they will have responsibility for: • • • • •

The Availability Management process Establishing measures and reporting Monitoring effectiveness of Availability Management and ensuring continual Improvement Ensuring levels of availability are cost justified Availability champion within the IT support organization

S3Dp14

Process - Critical Success Factors

Amongst its many challenges, Availability Management must meet the expectations of the organization, its senior management and customers alike. This is regarded by ITIL as Availability Management’s primary concern. ITIL guidance goes on to outline the main Critical Success Factors (or CSFs) for Availability Management in the following way: • • •

To be able to manage availability and reliability of IT Services To satisfy business needs for access to IT Services To maintain availability of the IT Infrastructure, as documented in SLAs, provided at optimum costs.

Availability Management may wish to consider having its own Availability Management Information System (or AMIS) for storing information about key activities such as report generation, statistical analysis and availability forecasting, action plans, projected service outage reports, etc. Other Availability information may be taken from the Configuration Management System (or CMS) and the Capacity Management Information System (or CMIS) to avoid unnecessary duplication and cost.

S3Dp15

Process - benefits

There are a number of wide-ranging benefits to be gained from the successful implementation of an Availability Management process. Firstly, the ability to develop a strong emphasis on business support can be regarded as a high value return for implementing Availability processes - IT availability is high priority to business operations. The formation and maintenance of a single point of accountability for all matters regarding availability will lead on to the following benefits: • •

The levels of availability are cost justified The levels of availability required support SLA and SLM targets



67

3D • • • •


ITIL Foundation

Shortfalls are identified and correct actions are taken consistently The business users’ perspective is given a higher priority The frequency and duration of failures can be significantly reduced, and finally The IT support organization can demonstrate added value to the business

S3Dp16

Summary

This concludes this session on Availability Management. Having completed this session you should: •

Be aware of the main responsibilities of the Availability Management process

•

Understand the scope, purpose and objectives of Availability Management, its six key objectives and guiding principles

•

Be familiar with some of the basic concepts of the Availability Management process, including reliability, maintainability and serviceability, vital business functions

•

Be familiar with some of the key metrics and measurements used in this process and finally

•

Be aware of the Critical Success Factors for the Availability Management process and some of the benefits the process can deliver to the organization



68

3E

Information Security Management ®

ITIL Foundation

S3Ep1

Objectives

The subject of this session is Information Security Management, which is the subject of chapter 4.7 of the ITIL Service Design publication. When you have completed this lesson you will: •

Understand the purpose and scope of Information Security Management and be aware of the key objectives of the process

•

You will be familiar with some of the terms used in the process and have seen the Security Management Lifecycle in some detail

•

You will understand what is meant by an Information Security Policy and an Information Security Management System

•

Finally you will have seen some of the key responsibilities of the Security Manager role

S3Ep2


Information Security exists to serve the interests of the business or organization, but not all information or information services are equally important to the organization. But what do we mean by ‘information’? In ITIL terms information is used as a general term to describe such things as data stores, databases and metadata. The purpose of Information Security Management is: ‘To align IT security with business security and ensure that the confidentiality, integrity and availability of the organization’s assets, information, data and IT services always match the agreed needs of the business.’ The objective of information security management is ‘to protect the interests of those relying on information, and the systems and communications that deliver the information, from harm resulting from failures of confidentiality, integrity and availability’. As such the level of security needs to be appropriate to the significance of the information. Ultimately a balance must be found between the security measures and the cost and the value of the information and the risks in the environment.

S3Ep3

International standards

If an organization is considering the implementation of IT Security Management, then knowing what Information Security policy or policies or standards affect them, is vitally important. There are two international standards governing Security, which you should be aware of. These are: ISO IEC 27001:2005, which is the standard for Information Security Management System and ISO IEC 17799:2005, which is the general organisational Security standard. The ITIL Security Management process will take into account how the organization manages its own security against these standards and will map on the following considerations:



69

3E • • • • • •


ITIL Foundation

Business Security policy and plans Current business operation and associated security requirements Future business plans and requirements Legislative requirements Obligations and responsibilities with regard to security contained in SLAs, and finally The business and IT risks and their management

S3Ep4

Process - scope

The scope of the Information Security Management process covers: Being the focal point for all IT security issues along with ensuring that an Information Security Policy is produced, maintained and enforced Information Security Management should also have an understanding of the total IT and Business security environment, covering: •

Business security policy and plans

•

Current business operation and its security requirements

•

Future business plans and requirements

•

Legislative and regulatory requirements

•

Obligations and responsibilities with regard to security contained within SLAs

•

And the business and IT risks and their management

S3Ep5

Process Terminology

We have encountered several new definitions in this session so far. Let’s take a few moments to review some of those already seen, and outline some new ones. Confidentiality - is all about protecting sensitive information from unauthorised disclosure. Integrity - is concerned with safeguarding accuracy and completeness of information available to those who are authorised to access it. Availability - is about when the access is required. And Anonymity, which ensures that a User’s identity remains confidential.

?

S3Ep6

Activity

Try answering this question on Information Security Management. Feedback Availability of the data as and when the user/customer requires access to it and its related information . Confidentiality is concerned with protecting sensitive information from unauthorised disclosure. Finally Integrity safeguards the accuracy and completeness of information available.



70

3E S3Ep7


ITIL Foundation

Threat to Recovery - The Security Lifecycle

Security measures can be used in the prevention and handling of security incidents. Security incidents are generated from various sources. Statistics show that a large majority are human-generated or procedural errors and may well have health and safety or legal implications. ITIL identifies a Security lifecycle which is shown here. It begins with the identification of a threat. This can be defined as anything that disrupts business processes, or has a negative impact on business results. When a threat materialises, a security incident is noted. This security incident might result in damage to either information or assets, and will require corrective action or control. Appropriate security measures can be assigned to each of these stages. To prevent the incident occurring in the first place, preventative security measures are put in place. Reduction measures can be used to minimise the impact of the threat. If a security incident does occur then detection measures will be required. To counteract repetition or continuation of the Security incident, repressive measures are implemented. Corrective measures repair any damage. This might include restoring from a backup or a roll back to a previous secure situation. If the Security incident was considered serious, then an evaluation could take place. The evaluation process should establish: What went wrong? What caused it? How can we stop it happening again? It's important to study all Security incidents in order to assess the effectiveness of the organization's security measures. This should be supported by an appropriate reporting procedure and related supporting documents, including log files, audit files and Service Desk records. The evaluation information can be fed back into the control stage to support decisions such as proposed change to security mechanisms.

S3Ep8

?

Activity

?

Activity

Fill in the missing descriptions from the Security Incident lifecycle. Feedback The stages of the Security Incident lifecycle are: Threat, Incident, Damage and Control.

S3Ep9

Now let's complete the diagram. Move the security measures into their correct position in the Security Incident lifecycle diagram.



71

3E S3Ep10


ITIL Foundation

Information Security Policy

Information Security Management activities should focus on and be driven by an over-arching Information Security Policy and a set of underpinning specific security policies. The Information Security Policy should have the backing of senior management both within IT and the business as a whole. The Policy should cover all areas of security, in order to meet the needs of the business. The typical contents of an ISP include: • • • • • • • • • • • • • •

An overall information security policy Use and misuse of IT assets policy An access control policy A password control policy An email policy An internet policy An anti-virus policy An information classification policy A document classification policy A remote access policy A policy with regard to supplier access to IT service, information and components A copyright infringement policy for electronic material An asset disposal policy And a records retention policy

The Policy should be widely available to all customers and users as well as IT staff with the following exception... in the case of a Type III (External service provider) where the ISP relates to one or more external customers, this should be confidential from other customers. The Information Security Policy should be referred to in SLA’s and Underpinning contracts and key areas of the Policy should be highlighted to ensure full understanding of roles and responsibilities and help ensure adherence to the Policy. It’s important that all the policies are kept up to date. As such they should be reviewed regularly and as a minimum, at least annually.

S3Ep11

Security Management

In order to support the Information Security Policy, ITIL outlines an Information Security Management System (or ISMS). The ISMS contains the management procedures, standards and guidelines to support the various Security policies. Elements of the IT Security Management System (ISMS) are shown in the diagram here. The approach is based on the advice and guidance described in many sources, including ISO/IEC27001, an International Standard for Information Security, and NIST, the USA National Institute for Standards and Technology guidelines on information Security. The iterative framework consists of five elements. At its centre is Control. The objective of Control is to establish a management framework and control documentation, so that Information Security can be initiated in the organization, and a Security policy can be implemented. Maintain is concerned with learning from previous issues, including identifying countermeasures that will improve security, and planning the effective implementation of solutions.



72

3E


ITIL Foundation

To Plan is to understanding Security implications on and from: Service Level Agreements, Underpinning Contracts, Operational Level Agreements and Policy Statements. Implement is concerned with creating awareness, classification and registration of Security-based incidents and problems, personnel Security, physical Security, management of access rights to networks, applications and computers, and the generation and maintenance of Security incident procedures. Finally Evaluate involves conducting internal audits, external audits and self-assessments, as well as analysing the effects and impacts of Security incidents.

S3Ep12

Security Manager Role

As is common to many other processes, ITIL suggests a process owner, namely the Security Manager. The role has several important responsibilities assigned to it. These range from ensuring that the processes involved run efficiently and effectively and are monitored and audited on a regular basis, to identifying weaknesses and implementing improvements. The Security Manager will be the champion for Security Management throughout the organization and will maintain awareness of process for all interested parties. They will also maintain all appropriate standards and identify and shape policy. In particular, they will be responsible for: Security testing, ensuring the confidentiality, Integrity and availability of the services are maintained according to agreed levels in SLAs, attending CAB meetings to discuss any changes that may impact security, monitoring systems and services to maintain security levels, assisting with business impact analyses and identifying and classifying security related assets.

S3Ep13

Summary

In this session we have been looking at Information Security Management, which is the subject of chapter 4.7 of the Service Design book of the ITIL library. In this session: •

We looked at the purpose and scope of Information Security Management and the key objectives of the process

•

We went on to review some of the terms used in the process and outlined the Security Management lifecycle in some detail

•

We outlined the contents of an Information Security Policy and described the framework for managing information security, namely the Information Security Management System, including its iterative elements of Plan, Implement, Evaluate, Maintain and Control

•

Finally we described some of the key responsibilities of the Security Manager role



73

3F

Capacity Management ®

ITIL Foundation

S3Fp1

Objectives

The subject of this session is Capacity Management, which is the subject of chapter 4.5 of the ITIL Service Design publication. When you have completed this lesson you will: • • • • • •

Be able to define what Capacity is in IT terms Be familiar with the constraints which affect the process Be aware of the sub process activities of Business, Service and Component Capacity Management Have seen the typical contents of a Capacity Plan Be familiar with the Capacity Manager role And have seen the benefits that Capacity Management can provide

S3Fp2

Activity

ITIL guidance states that Capacity Management is responsible for ensuring that the Capacity of the IT infrastructure matches the evolving demands of the business in a cost-effective and timely manner. But what exactly do we mean by capacity in IT terms? The ITIL glossary defines capacity as ‘the maximum throughput that a Configuration Item or IT Service can deliver whilst meeting agreed Service Level Targets’. This definition refers to the capacity of the infrastructure as a whole. We may also describe the size or volume of a CI, such as a disk drive, as having a ‘capacity’. Having learnt what capacity is, try answering this question. Which types of infrastructure components do you think would need monitoring in capacity terms? Feedback You could reasonably argue that Hardware, Software, Networks and people should all be monitored in Capacity terms. For example we might monitor Hardware capacity, such as processors, servers and hard disk space. We could monitor Software such as application usage and growth. Monitoring Networks including messaging rates would be worthwhile, and finally we might monitor People, for example Service Desk staff at peak times. It’s clear then that Capacity Management extends across the whole Service lifecycle.

S3Fp3

Capacity Balancing Act

The purpose of Capacity Management is not only focussed on the ‘now’ aspect of service delivery, but is very much focussed on the future needs too. Capacity Management has both reactive and proactive activities, which we will look into in more detail during this session. Hardware, Software, Networks and People are all the concern of active Capacity Management. As such, the process activities can be considered a balancing act.



74

3F


ITIL Foundation

It’s a question of how much can be spent balanced against how much do we, or will we need. We all know that work expands to fill the time available to complete it, but it also seems that data expands to fill the space available for storage! It’s clear then that Capacity Management requires a close understanding of an organization’s requirements, both present and future. For example, acquisitions and mergers are a frequent occurrence in modern business and events of this nature will affect Capacity Management to a greater or lesser extent. Good Capacity Management means no surprises and that means keeping abreast of planned business requirements.

S3Fp4

Process Constraints

As Capacity Management involves both initial and ongoing resources and effort, you occasionally hear the question ‘Why not just buy a bigger machine or more storage discs or why don’t we lease more communications lines?’ There are normally very good reasons why this approach is impractical, inefficient or impossible. These can be defined as constraints. Constraints can be Financial, Technical, or Physical. Let’s look at each in a little more detail. Firstly Financial constraints. There may be insufficient funds available, or demands with a higher priority on the available funds. If performance problems exist or SLA’s are being breached, then action will need to be taken, but you may not be able to ‘buy your way out of trouble’. Technical Constraints may exist. There may not be a simple upgrade path. If, for example, the most powerful machine in the range is already in use, an upgrade to a different range of machines, perhaps from another manufacturer, may be very difficult and could involve the conversion of applications and so on. Similarly, it may not be possible to add additional memory or discs to a configuration due to a connection limitation. There may be Physical constraints, for example insufficient physical space in the computer room to accommodate extra equipment. The energy and/or the environmental requirements may exceed what is currently available. In effect the total cost of the upgrade is not only additional Hardware, but the expansion of the physical space, environmental equipment and so on. Finally there are Efficiency considerations. Unlimited and unconstrained purchase of equipment often leads to inefficient use of resources and waste. For example, if there is unlimited computing resource available there is no incentive for designers and programmers to design and write more efficient application code. So where do you spend your money? We may be in danger of having to rely on a supplier’s interpretations of our situation, which may not be the same as ours or, indeed, appropriate. Investing in a good Capacity Management process will, amongst other things, allow us to maintain an approach of ‘planned buying’ as opposed to ‘panic buying’.

S3Fp5


‘The purpose of the capacity management process is to ensure that the capacity of IT services and the IT infrastructure meets the agreed capacity- and performance-related requirements in a cost-effective and timely manner. Capacity management is concerned with meeting both the current and future capacity and performance needs of the business‘.



75

3F


ITIL Foundation

Capacity Management is concerned with ‘having the appropriate IT capacity, and making the best use of it’. It is not about the latest or biggest processor that is available from your supplier, unless of course that size of processor can be justified. If it cannot be justified and you have over capacity, consequently the cost of providing the IT services is likely to be more expensive than similar sized organizations. Operating under capacity can cause performance problems. It increases the probability that you cannot meet the targets in the SLAs, and leads to a deterioration in the quality of IT service. Capacity Management is concerned with achieving a balance between capacity requirements and available resources. Capacity Management needs to understand the business requirements or ‘the required service delivery’, the organization's operation or ‘the current service delivery’ and the IT infrastructure or ‘the means of service delivery’, and ensure that all the current and future capacity and performance aspects of the business requirements are provided cost-effectively. However, Capacity Management is also about understanding the potential for service delivery. New technology needs to be understood and, if appropriate, used to deliver the services required by the business. Capacity Management needs to recognise that the rate of technological change is very unlikely to slow down, and will continue at its current rate, if not speed up. Appropriate technology should be harnessed to ensure that the IT services required by the business can be delivered.

S3Fp6


In order to meet its goals, Capacity Management is set the following objectives: •

To produce and maintain an appropriate and up-to-date capacity plan, which reflects the current and future needs of the business

•

To provide advice and guidance to all other areas of the business and IT on all capacity - and performance-related issues

•

The process also ensures that service performance achievements meet all of their agreed targets by managing the performance and capacity of both services and resources

•

Capacity Management also assists with the diagnosis and resolution of performance- and capacity-related incidents and problems, along with the assessment the impact of all changes on the Capacity Plan, and the performance and capacity of all services and resources

•

Finally Capacity Management ensures that proactive measures to improve the performance of services are implemented wherever it is cost-justifiable to do so

S3Fp7

Process - activities

I’m sure you can see the importance of monitoring the performance and throughput of resources to check that thresholds will not be exceeded, SLAs will be met, and business volumes are where they’re expected to be. When we’re working towards ‘no surprises’ then proactive work is far more likely to succeed than reactive panic responses to unexpected breaches. For much the same reason careful tuning activities would be beneficial to optimize performance.



76

Capacity Management

3F

®

ITIL Foundation

We have already identified the importance of understanding business needs and how this translates into forecasting capacity requirements for the business. How could Capacity Management influence demands? This may be shared with Financial Management. The purpose is to provide a point of focus and management for all capacity and performance-related issues, relating to both services and resources. A CMIS (Capacity Management Information System) is the cornerstone of a successful process. It will contain data including business, service, technical, financial and utilization. It may not be one database - this information may well exist in several physical locations. For example, business data may include number of accounts and products supported, number of calls to the Service Desk, number of locations or branches, number of registered users of a system, number of PCs, seasonal variations of workload, number of web site transactions, and so on.

S3Fp8

Sub-process

There are the three sub processes that make up the Capacity Management process. Business Capacity Management is concerned with the long term view and will be discussed at fairly High Management level. The processes at this level will be reviewed on an annual basis. Inputs to this sub process will come from Patterns of business activities PBAs and Service Level Packages SLPs - which were introduced to you during the Service Strategy module. Service Capacity Management is concerned with the medium term view and will be discussed at Service Level Management level. The processes at this level will be reviewed on a monthly basis. Inputs to this sub process will come from the content of the SLA’s relating to the Service. And finally, Component Capacity Management. This is concerned with the short term view and will be discussed at Practitioner level. The processes at this level will be reviewed on a much more frequent basis, by the second in some cases. Each has its own inputs and outputs. Together they make up Capacity Management.

?

S3Fp9

Activity

Here's a quick Capacity Management revision question. Type the correct information in the white boxes to make this acronym correct. Feedback The acronym CMIS stands for Capacity Management Information System.

S3Fp10

Capacity Management

The production and updating of a Capacity Plan should occur at pre-defined intervals. Ideally the Plan should be published annually, in line with the business or budget lifecycle, and should be completed before the start of negotiations on future budgets.



77

Capacity Management

3F

®

ITIL Foundation

A quarterly re-issue of the updated Plan may be necessary to take into account changes in business plans, to report on the accuracy of forecasts and to make or refine recommendations. A Capacity Plan would include, for example: • • • • • • • •

Assumptions Management Summary Options for Service Improvement - resolving issues or managing capacity Service Summary Cost Models Component Summary - utilisation and performance Business Scenarios - workload forecasts Recommendations for the future capacity solutions passed through Continual Service Improvement (CSI)

S3Fp11

Process - activities continued

There are four major activities undertaken within Capacity Management: The primary objective of Demand Management is to influence the demand for computing resource and its use. It could include short-term requirements, where for example, there is insufficient available capacity for the work being done this week, or long-term Demand Management that would look at leveling peaks to use under-capacity outside core hours. Demand Management is also closely linked with Financial Management. Iterative Activities involves setting thresholds then monitoring, analyzing, tuning, implementation which is planned, and reporting. Note reporting is usually by exception. The objective with Modelling is to predict the behavior of IT services under a given volume and variety of work. This can include trend analysis and assist in deciding the right approach to implement a new system, for example. Application Sizing has a finite life-span. Used at the project initiation stage for a new application or when a major change is planned for an existing application. Its objective is to estimate the resource requirements to support the new or changed application so that it meets its required service levels.

?

S3Fp12

Activity

The three Capacity Management sub-processes are: Feedback The three Capacity Management sub-processes are: Business Capacity Management, Service Capacity Management and Component Capacity Management.

S3Fp13

Process - benefits

Before we complete this session, let’s take a little time to focus on the benefits of Capacity Management.

The first benefit can be described as ‘No Surprises’ - that is, Capacity is growing or declining at the rate expected and that business required changes are better anticipated.



78

Capacity Management

3F

®

ITIL Foundation

Secondly, ‘planned buying is cheaper than panic buying’ - reducing unnecessary costs and maintaining budgetary control. Deferred expenditure can be seen as another benefit. Expenditure can be planned across a time period to suit IT and other financial considerations. Service delivery matched to business need - a benefit common to most ITIL processes, gained here because of proper planning. Reduced risk of performance problems or failures - again through good planning and understanding of business requirements. Forecasting capacity to develop new services - good relationships with the business will foster an approach that leads to this benefit. Understanding of current and future technology - allowing to help shape future investment in IT that will support and deliver services that continue to meet Capacity and Availability requirements. Interaction with other Service Management processes - Problem Management, Service Level Management, Availability and IT Service Continuity have strong connections with Capacity, not forgetting the Financial Management of IT services. Finally, increased efficiency and cost savings - again, a common ITIL benefit gained through good management of process and function.

S3Fp14

Capacity Manager Role

There are several responsibilities that the Capacity Manager role would be expected to carry out. These include: •

Identifying and ensuring adequate capacity levels

•

Understanding current and forecasting future requirements of capacity

•

And performing sizing on new and changed services and systems

The Capacity Manager is also responsible for the analysis of; •

Monitoring tools

•

Usage and performance trends

•

Changes and their impacts

•

New technology

The Capacity Manager will also attend CABs as required and produce any required plans and reports. They will also monitor performance related incidents and problems. So it can be clearly seen that they support the main activities of the Capacity Management process.

S3Fp15

Summary

In this session we have been looking at Capacity Management, which is the subject of chapter 4.5 of the Service Design book of the ITIL library.



79

3F


ITIL Foundation

In this session we defined what Capacity is in IT terms and went on to look at several of the constraints which affect the Capacity Management process. We looked briefly at the sub-process activities of Business, Service and Component Capacity Management, and the four major process activities, namely Demand Management, Modelling, Application Sizing and the Iterative Activities. We introduced the role of the Capacity Manager. Finally we outlined the contents of a Capacity Plan and went on to summarise the benefits that Capacity Management can deliver.



80

3G

ITSC Management ®

ITIL Foundation

S3Gp1

Objectives

The subject of this session is IT Service Continuity Management, which is covered in chapter 4.6 of the ITIL Service Design publication. Once you have completed this session you will: •

Understand the terms Business Continuity Management and IT Service Continuity Management, and appreciate the relationship between these two processes.

•

Have an understanding of the Business Continuity lifecycle, and its four phases.

•

Be familiar with Business Impact Analysis and some of the recovery options outlined in ITIL guidance, and

•

Be aware of the role and responsibilities of the IT Service Continuity Manager and have seen some of the benefits this process can deliver.

S3Gp2

Introduction

In this highly competitive world of service-oriented business, organizations are judged on their ability to continue to operate and provide a service at all times. I’m sure you’ve found this in both your professional role but also as a consumer - things like train services running late or being cancelled, or phone calls with people who blame their computers for poor performance. IT Service Continuity Management (or ITSCM), is concerned with managing the IT infrastructure and services, to enable a pre-determined and agreed level of service to support the minimum business requirements, following an interruption to the business. This could range from an applications or system failure to a complete loss of the business premises. As such ITSCM forms an integral part of the Business Continuity Management (or BCM) process that most organizations should have in place, or at least should have discussed! To clarify, IT Service Continuity Management is focused on the continuity of IT Service to the business, whereas Business Continuity Management is concerned with the management of Business Continuity that incorporates all services upon which the business depends, one of which is IT. As BCM isn’t an ITIL process, our focus in this session is ITSCM. It’s now a stark fact of life that threats can come from all manner of directions and be very unexpected!

S3Gp3


These days, a reactive approach to dealing with risks to Business Continuity is not acceptable. Directors have a ‘duty of care’ to their shareholders, customers and creditors and could find themselves personally liable if they have been negligent, whatever their professional discipline. ITIL defines the purpose for IT Service Continuity Management as: To support the overall Business Continuity Management process by ensuring that, by managing the risks that could seriously affect IT services, the IT service provider can always provide minimum agreed business continuity-related service levels. ITIL defines the scope for IT Service Continuity Management as:



81

ITSC Management

3G • • •

®

ITIL Foundation

Focus is on events that the business considers significant enough to be treated as a ‘disaster’ Scope of ITSCM is determined by organization structure, culture and strategic direction, both business and technology Needs to take into account numbers, locations of offices and services performed in each

It is worth noting that whilst other IT service management processes such as Incident management, problem management, capacity management, availability management deal with the day to day operational incidents that impact on service availability, ITSCM has a much larger and wider scope to ensure the business can continue to operate and survive during times of major disasters.

S3Gp4

IT Service Continuity Lifecycle

Here we will take a few moments to look at the IT Service Continuity lifecycle and its four distinct phases. First of all let’s consider why we need to do it - what’s the business impact? Initiation looks at the policy setting, specifying the terms and reference and scope, the allocation of resources, defining the project organization and control structure and agreeing the project and quality plans. One of the first activities of the Requirements and Strategy phase is to carry out Business Impact Analysis. The purpose of Business Impact Analysis (or BIA) is to establish what impact a loss of a service would have on the business. The impact of the loss of a real time service, such as trading in the money market, will be felt immediately, while the business may cope for some time without other services. As well as establishing the impact of loss of each service, the BIA identifies the minimum requirements of each service to meet the critical business needs and therefore the IT Service recovery priority. Producing the BIA is a major opportunity to engage with the business and ensure that the IT Service Continuity Plans reflect the current and future business strategies, and are consistent with the overall Business Continuity Plan. Implementation - the following needs to be considered for the Implementation stage of the ITSCM process, the development of the IT Service continuity plans, the development of the IT plans, recovery plans and procedures, organizational planning - who will do what and when and at what stage of the implementation, risk reduction and recovery considerations, the actual implementation timings and mechanisms, and the Initial testing of the ITSCM plan. On-going operation - the activities involved with this stage of the ITSCM process include the education, awareness and training of all personnel within the organization of the ITSCM plan, the reviewing and auditing of the plan, the testing frequency of the plan, when to test, what type of tests need to be undertaken and to ensure that any request for changes raised and discussed at the CAB consider… any ITSCM requirements.

?

S3Gp5

Activity

In the purpose of IT Service Continuity Management, what does ITIL suggest should be resumed within required and agreed business timescales? Feedback ITIL suggests that ITSCM should support the BCM process by ensuring that the required IT technical and service facilities can be resumed within required, and agreed, business timescales.



82

3G S3Gp6

ITSC Management ®

ITIL Foundation

Impact Analysis

The only way of implementing effective ITSCM is through the identification of critical business processes and the analysis and coordination of the IT infrastructure and supporting IT services. How much an organization stands to lose is a good question to ask when determining ITSCM requirements. Business impact generally falls into one or more of the following categories: • • • • • • •

Loss of operational capability Loss of credibility or goodwill Loss of image or reputation Immediate and long term loss of market share Breach of law, regulations or standards Political, corporate or personal embarrassment Failure to achieve SLAs

Financial losses or impacts are measured against particular scenarios for each business process such as an inability to settle trades in a money market dealing process, or an inability to invoice for a number of days’ consultancy services. It is also important to understand how impacts may change over time. For example, it may be possible for a business to function without a particular process for a short time, such as in the case of invoicing, but over a longer period, getting it working again will become critical to business cash flow.

S3Gp7

Risk Analysis

The analysis of risks is a key activity in ITSCM. A Risk Assessment should also be carried out to ascertain the likelihood and impact of major incidents on the IT infrastructure. Having gathered the business requirements from the Business Impact Analysis and assessed the risks as part of the risk assessment, the organization now has the information it needs to be able to determine the appropriate strategy. The strategy is a balance between the risk reduction measures and recovery options to support the recovery of critical business processes within agreed timescales. Understanding the threats and the vulnerabilities is essential. Risk is defined as: ’a possible event that could cause harm or loss, or affect the ability to achieve objectives’. Risk analysis cannot take place unless the identification of a risk has occurred, risk analysis then feeds into the risk management aspect of Management of Risk. There are a number of risk assessment and management methods available for both the commercial and government sectors. Risk assessment is the assessment of the risks that may give rise to service disruption or security violation. Risk management is concerned with identifying appropriate risk responses or cost-justifiable countermeasures to combat those risks. A standard methodology, such as the Management of Risk (M_o_R), should be used to assess and manage risks within an organization.



83

ITSC Management

3G

®

ITIL Foundation

S3Gp8

ITSC Manager Role

As a process owner, there are several responsibilities that the IT Service Continuity Manager must undertake. These range from ensuring that the processes involved run efficiently and effectively and are monitored and audited on a regular basis, to identifying weaknesses and implementing improvements. The IT Service Continuity Manager will be the champion for IT Service Continuity Management throughout the organization and will maintain awareness of process for all interested parties. They will maintain all appropriate standards and identify and shape policy. In particular, they will be responsible for: • • • • • • •

Developing and managing the ITSCM Plan Interfacing with the overall Business Continuity Manager Maintaining the testing schedule Performing the quality review of procedures Performing regular reviews of Continuity Plans Negotiating contracts with third party suppliers Managing IT Service Continuity Plan whilst it is operation

S3Gp9

Process - benefits

ITSCM supports the Business Continuity Management process and delivers the required IT supporting infrastructure to enable the business to continue to operate following a service disruption. The annual spend on ITSCM can be likened to an insurance premium and, like insurance, the optimum spend is determined by the circumstances and risks that could influence the organization's business. The variety and frequency of events that pose a threat to businesses in today’s technology age have forced organizations to regard the continuing requirement for ITSCM as part of their corporate and management philosophy and culture. This allows an organization to identify, assess and take responsibility for managing its risks, thus enabling it to better understand the environment in which it operates, decide which risks it wishes to counteract, and act positively to protect the interests of all stakeholders including staff, customers, shareholders, third parties and so on. ITSCM can complement this activity and help to deliver business benefit. The IT organization can help the organization demonstrate to underwriters or insurers that they are proactively managing down their business risks. Therefore the risk to the insurance organization is lower and the premiums due should reflect this. Alternatively, the organization may feel comfortable in reducing cover or self-insuring in certain areas as a result of limiting potential losses.

S3Gp10

Process - benefits continued

Another benefit of ITSCM is the fulfillment of regulatory requirements. In some industries, a recovery capability is becoming a mandatory requirement. For example, regulators stipulate that financial organizations have sufficient Continuity and Security controls to meet the business requirements.



84

3G

ITSC Management ®

ITIL Foundation

Failure to demonstrate tested business and ITSCM facilities could result in heavy fines or the loss of trading licenses. Within the service community for instance, there is an obligation to provide continuous services, for example, hospitals, emergency services and prisons. Improved business relationship can be highlighted as another benefit. The requirement to work closely with the business to develop and maintain a continuity capability fosters a much closer working relationship between IT and the business areas. This can assist in creating a better understanding of the business requirements and the capability of IT to support those requirements. Being able to demonstrate effective ITSCM capabilities enables an organization to provide high service levels to clients and customers and thus win business. There is a responsibility on the directors of organizations to protect the shareholders’ interest and those of their clients. Contingency facilities increase an organization's credibility and reputation with customers, business partners, stakeholders and industry peers. For example, the growth of call centres in many organizations has meant that the need to maintain customer communications at all times is vital to the ability to retain customer confidence and loyalty. Finally, Service organizations are increasingly being asked by business partners, customers and stakeholders to demonstrate their contingency facilities and may not be invited to tender for business unless they can demonstrate appropriate recovery capabilities. In many cases this is a good incentive for customers to continue a business relationship and becomes a part of the competitive advantage used to win or retain customers.

S3Gp11

Summary

In this session we have been looking at IT Service Continuity Management, which is the subject of chapter 4.6 of the Service Design book of the ITIL library. In this session: •

We described the processes of Business Continuity Management and IT Service Continuity Management and looked at the purpose of ITSCM

•

We looked at the IT Service Continuity lifecycle and its four distinct phases, namely Initiation, Requirements and Strategy, Implementation and Operational Management

•

We outlined the ITSCM activity of Business Impact Analysis

•

Finally we looked at the role and responsibilities of the IT Service Continuity Manager, and listed some of the benefits that effective ITSCM can deliver



85

3H

Design Coordination ®

ITIL Foundation

S3Hp1

Objectives

The subject of this session is Design Coordination, which is covered in chapter 4.6 of the ITIL Service Design publication. Once you have completed this session you will: •

Understand the terms Business Continuity Management and IT Service Continuity Management, and appreciate the relationship between these two processes.

•

Have an understanding of the Business Continuity lifecycle, and its four phases.

•

Be familiar with Business Impact Analysis and some of the recovery options outlined in ITIL guidance, and

•

Be aware of the role and responsibilities of the IT Service Continuity Manager and have seen some of the benefits this process can deliver.

S3Hp2


So far in this course we have introduced you to 6 processes that are primarily concerned with the Service Design stage of the Service Lifecycle, however there is one remaining process to introduce namely Design coordination. Design coordination has the following objectives: •

•

It ensure the consistent design of appropriate services, service management information systems, architectures, technology, processes, information and metrics to meet current and evolving business outcomes and requirements To coordinate all design activities across projects, changes, suppliers and support teams, and manage schedules, resources and conflicts where required To plan and coordinate the resources and capabilities required to design new or changed services To produce service design packages or SDPs based on service charters and change requests To ensure that appropriate service designs and/or SDPs are produced and that they are handed over to service transition as agreed To manage the quality criteria, requirements and handover points between the service design stage and service strategy and service transition To ensure that all service models and service solution designs conform to strategic, architectural, governance and other corporate requirements and finally To improve the effectiveness and efficiency of service design activities and processes

S3Hp3


• • • • • •

The purpose of the design coordination process is to ensure the goals and objectives of the service design stage are met by providing and maintaining a single point of coordination and control for all activities and processes within this stage of the service lifecycle. The scope of the design coordination process includes all design activity, particularly all new or changed service solutions that are being designed for transition into (or out of, in the case of a service retirement) the live environment.



86

3H


ITIL Foundation

Some design efforts will be part of a project, whereas others will be managed through the change process alone without a formally defined project. Some design efforts will be extensive and complex while others will be simple and swift. Not every design activity requires the same level of rigor to ensure success, so a significant number of design efforts will require little or no individual attention from the design coordination process. Most design coordination process activity focuses around those design efforts that are part of a project, as well as those that are associated with changes of defined types. Typically, the changes that require the most attention from design coordination are major changes, but any change that an organization believes could benefit from design coordination may be included. Each organization should define the criteria that will be used to determine the level of rigour or attention to be applied in design coordination for each design. Some organizations take the perspective that all changes, regardless of how small in scope, have a ‘design’ stage, as it is important that all changes have clear and correct plans for how to implement them. In this perspective, the lifecycle stage of service design still occurs, even if the designs for simple or standard changes are usually pre-built and are reused frequently and quickly.

S3Hp4

Value to the Business

Here we will take a few moments to look at the value to the business of the Design coordination process and activities: The main value of the design coordination process to the business is the production of a set of consistent quality solution designs and SDPs that will provide the desired business outcomes. Through the work of design coordination organizations can: •

Achieve the intended business value of services through design at acceptable risk and cost levels.

•

Minimize rework and unplanned labour costs associated with reworking design issues during later service lifecycle stages

•

Support the achievement of higher customer and user satisfaction and improved confidence in IT and in the services received.

•

Ensure that all services conform to a consistent architecture, allowing integration and data exchange between services and systems

•

Provide improved focus on service value as well as business and customer outcomes

•

Develop improved efficiency and effectiveness of all service design activities and processes, thereby supporting higher volumes of successful change delivered in a timely and costeffective manner

•

Achieve greater agility and better quality in the design of service solutions, within projects and major changes

S3Hp5

Design Coordination Policies

A structured and holistic approach to design activities should be adopted, so that all available information is considered and to ensure that consistency and integration are achieved throughout the



87

3H


ITIL Foundation

IT organization, within all design activities. The design coordination process provides guidelines and policies to allow for this holistic approach and the coordination to ensure the practices are followed. The service provider should define policies for which service design efforts require which type of attention from design coordination. For example, the policy might specify that the design portion of all projects, as well as for all changes that meet specific criteria (such as major changes) should receive individual coordination, while other changes must simply adhere to predefined design standards for that change type. These design standards are likely to be embedded in the change model and/or associated documented procedures for executing changes of that type. The level of required documentation should also be established by policy. For design efforts that are part of a project or are associated with changes that meet specific criteria (such as major changes), a full service SDP will be required. For other changes, if in scope, the ‘service design’ may be documented very simply, and may even be pre-built if the change has been done before.

S3Hp6

Summary

This brings us to the end of this session on the subject of Design Coordination which is covered in chapter 4.1 of the ITIL Service Design publication. In this session we have: • Looked at the scope, objectives and purpose of this process • And gained an understanding of what is excluded from the scope of this process • We have also seen the value to the business that this process can deliver • And we have been introduced to the design coordination policies and their associated content



88

4A S4Ap1

Overview of Service Transition ®

ITIL Foundation

Session objectives

This overview session looks at the ITIL Service Management publication, Service Transition which is the third of the five lifecycle phases. In this overview session we will: •

Outline the main purpose and scope of Service Transition

•

Identify the main objectives and processes of Service Transition and the value it can bring to the business

•

We’ll go on to look at the main Service Transition Processes including Change Management, Service Asset and Configuration Management, Release and Deployment Management, Knowledge Management and Service Transition planning and support

The processes described are not limited to Service Transition. For example, Change Management applies throughout the lifecycle.

S4Ap2

Purpose and Scope

The Service Transition publication provides guidance for the development and improvement of capabilities for transitioning new or changed services into supported environments. More specially, the guidance describes how to: • • •

Implement new or changed Services that meet the customer’s agreed business requirements and business operations Ensure that customers and users are ready and willing to use the Service And ensure that Service Operations understand and support the service

S4Ap3

Purpose and scope continued

The purpose of Service Transition is: ‘to ensure that new, modified or retired services meet the expectations of the business as documented in the service strategy and service design stages of the lifecycle.’ To set customer expectations, for example how the new or changed Service can be used to enable business change. The customer may need the confidence that: • •

the Service will be easy to use and that the Service will meet the performance targets agreed and documented during the Service Design

Service Transition has clear objectives, namely to: • • • • • •

Plan and manage service changes efficiently and effectively Manage Risks relating to new, changed or retired services Successfully deploy service releases into supported environments Set correct expectations on the performance and use of new or changed services Ensure expected business value created by service changes And provide good quality knowledge and information about services and service assets



89

4A S4Ap4


ITIL Foundation

Service Transition objectives

In order to achieve the objectives we’ve outlined, the Service Transition Publication suggests that both Business Management and Service Transition Management agree the specific objectives and value expected. Let’s look at three objectives with examples of the potential value: •

Firstly, ‘Plan and manage service changes efficiently and effectively’

In the telecommunications business, decisions on when and how to release may depend on rapidly changing market conditions. Therefore, the business may decide it wants a Service that works most of the time now, rather than one which operates all of the time in one year. For other organizations such as tax collection, stability is far more important than agility. •

Our second objective is to ‘Successfully deploy service releases into supported environments’

The Change Management process will help to identify the best time to schedule changes, whilst the Test and Validation processes will ensure that the new Service is ready for release. Whether to release or not should be a joint decision by Service Transition Management and the customer. Their decision may depend on how well the Service meets the test criteria defined and agreed during Service Design. •

Our final objective is to ‘Ensure expected business value is created by service changes

The ability to manage changes is critical when the business is under some fundamental transformation such as a mergers, de-merger, acquisition or transfer of Services via outsourcing.

S4Ap5

Service Transition objectives continued

Let’s look at two more objectives and describe some of the value generated. •

Firstly the ‘Provision of good quality knowledge and information about services and service assets’

Service Asset and Configuration Management provides much of the information needed to supplement the knowledge that already exists in the organization. The Education and Training programmes for user and support staff must be completed. These should have started during Service Design. •

A further objective is to ‘Set correct expectations on the performance and use of new or changed services and Plan and manage service changes efficiently and effectively’

The plans should ensure that the new or changed Service is only transitioned when the Service Operations, the customer and the business is ready for it. This could involve significant work associated with; •

Data conversion

•

Installation of new hardware, furniture, power and cables



90

4A •


ITIL Foundation

Early Life Support to ensure the hand-over is successful and that the service continues to meet the Service Levels agreed, and the productivity of business and customer staff

Other information may be found via the Portfolio, Service Catalogue and the Design Package. All held in the Service Knowledge Management System. There is a close link between Service Management and Project Management. Service Transition provides the ’quality gateways‘ to ensure that the project products (such as new services, applications, process and so on) are transitioned safely into the live operational environment.

S4Ap6

Service Asset and Configuration Management

Now, let’s take a few moments to look at four important Service Transition Processes, namely Service Asset and Configuration Management, Change Management, Release and Deployment Management and Knowledge Management. As we mentioned earlier, other Transition processes exist, including Test and Validation and Early Life Support. The first process we’ll look at is Service Asset and Configuration Management. This process helps all areas of Service Management by providing the accurate configuration information upon which good decision making depends. Configuration Information includes details of the Service Assets. Good Configuration information is essential when deciding what changes to authorise. For example, Problem Management will rely on it for Root Cause Analysis. This information may be held on Configuration Management Databases or a CMDB. Ideally, these databases are integrated with other databases, for example, with those holding incidents and problem data. When integrated they provide the basis for a Configuration Management System.

S4Ap7

Exercise

Consider the fast food restaurant; Which of the following items of information on the following list should be held on the Configuration Management System? • •

Firstly, so that the correct pizza is cooked correctly And secondly so that an accurate order for the pizza is taken and the correct payment is made

Feedback So how does your answer compare? Note that a Configuration Management System can provide information to all parts of the organization and there may be many thousands of items to store. Knowing relationships is critical, such as the pizza depends on using a hot oven; the hot oven depends on a reliable power supply.

S4Ap8

Change Management

The second Service Transition process we’ll look at is Change Management. Change Management enables the service provider to add value to the business by: •

Prioritising and responding to Requests for Change or proposals



91

Overview of Service Transition

4A • • •

®

ITIL Foundation

Implementing changes that meet the customer’s agreed needs Reducing failed changes, service disruption and rework And helping to assess and manage change related risks.

The Change Management process is used across the whole Service lifecycle. However most of the effort is spent dealing with changes required to operational services. A Request for Change may be a simple standard change such as ’can you change my toner on the printer’? Simple standard changes could be delegated to the Service Desk. By doing so, Change Management can concentrate their skills on the changes that are much more complex and must be assessed with some care. The Change Advisory Board or CAB is a group of people who have the time and expertise to help the Change Manager assess complex changes. The CAB may also have direct access to the people with the authority to approve changes and allocate the resources needed to make the change. Importantly, major changes, for example changing suppliers or project definitions are often treated differently and not normally within the scope of Service Change Management.

?

S4Ap9

Activity

Consider the fast food restaurant. Assume you are reviewing some change requests. Which of the following changes might be considered complex and therefore need advice from the CAB? Feedback RFC1 may have many implications for example some restaurants may gave many months’ supply of mix (unlikely but possible). Also the mix may require special cooking and the ovens may not have the capability to meet the high temperature required. RFC 2 may incur significant application reprogramming for the existing order processing software; there may be existing maintenance contracts with existing suppliers that might still need to be paid for. RFC 3 might be ’just do it’. RFC 4 will need some agreement from the Service Desk manager and staff, otherwise, like RFC 3 it is probably a standard change - simple, low risk, happens often and easy to procedurize.

S4Ap10

Release and Deployment Management

Our third process is Release and Deployment Management. This process has two main aims and three useful definitions. Firstly, the aims: ‘To plan, schedule and control the build, test and deployment of releases,’ And ‘To deliver new functionality required by the business while protecting the integrity of existing services.’ We need to understand some new terminology here, firstly:



92

Overview of Service Transition

4A

®

ITIL Foundation

A ‘release’ refers to ’a collection of hardware, software and other related components required to implement one or more authorised changes’. A ‘deployment’ refers to ’the activity responsible for movement of a release into the live environment’. A ‘release unit’ refers to the ’portion of a service or IT infrastructure that is normally released together‘. What his means in practice is that an organization may decide that the most appropriate release unit for a critical service is the complete application as this will ensure full testing. Whereas a more appropriate release-unit level for a web service may be at page level. Before going live the service must have passed the appropriate test and validation stage; this should cover such areas as Operability Acceptance Testing, Supportability Acceptance Testing and User Acceptance Testing.

S4Ap11

Release and Deployment Management

Finally Release and Deployment must ensure that the release actually works. There are several deployment options to consider when deploying a release into the live environment. Here are some examples: Big bang - The new release is deployed to all user areas in one operation. Phased - The new release is deployed to different areas at different times using a scheduled deployment plan. Push - The service or component is deployed from the centre and pushed out to the target locations. This is often the approach used for software deployments which are launched from a central server to the target PCs. Pull - The service is made available to be pulled down by users. This is often used where users can choose when to install an upgrade. Automation - Using software distribution tools. Manual - A member of staff and an installation CD. Early Life Support is provided by the Project development staff who designed, programmed and integrated all the applications, hardware, training programmes and changes required for the new or changed Service. This simple approach exists to ensure that if something goes wrong there is someone who can fix it, and fix it now! Early Life Support requires responsible development staff to be on immediate call until the new service is completely accepted and adopted by the Business and Service Operations.

?

S4Ap12

Activity

Consider the fast food restaurant; The RFC to use the new pizza formula (low cooking time high temperature) has been authorised and all 50 restaurants will change over on the same day. What type of changeover will this be?



93

4A


ITIL Foundation

Feedback a) This normally just describes pushing applications from a host site to an individual PC. Virus scan updates are a typical example; your PC is automatically updated. b) This is the trial. We’d need to choose a restaurant that will be happy to be the one to see how it all works. c) This would apply if your tried the new formula in one or two restaurants and when it all works nicely all restaurants ‘cut-over’ on an agreed day.

?

S4Ap13

Activity

What risks might you need to manage by taking the big bang approach to adopt the new pizza formula? Feedback With reference to choices a and b it is difficult to see how anything to do with new pizza formula affects customer orders or payments. With regard to risk C, which states that the formula may not work in all ovens and that some ovens may operate differently. Testing will be required on different ovens and we should also consider that the new formula may require different handling from that used already. Therefore all staff must have been re-trained. Finally with regard to risk D, which states that the new formula may not be distributed in time as there is only one supplier. Then we may need to wait until all restaurants have the formula. Note there are other dangers in having a single source supplier.

?

S4Ap14

Activity

And now we link benefits and risks together with an IT specific example. Consider the following statement. What benefits and risk might result from this approach? Feedback We suggest choices a, b, and c so answer option 4. An answer with d is incorrect as supplier payments are not dependent on the sales order application; that said there could be a dependency. The Configuration Management System would help us to see whether this is so.

S4Ap15

Knowledge Management

Let’s have a look at another important Service Transition process, namely Knowledge Management. 'The purpose of the knowledge management process is to share perspectives, ideas, experience and

information and to ensure that these are available in the right place at the right time to enable informed decisions and to improve efficiency by reducing the need to rediscover knowledge‘.



94

4A


ITIL Foundation

The process objectives are: •

To improve the quality of management decision-making by ensuring that reliable and secure knowledge, information and data is available throughout the service lifecycle

•

To enable the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service by reducing the need to rediscover knowledge

•

The process should also ensure that staff have a clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from the use of those services

•

And maintain a service knowledge management system or SKMS that provides controlled access to knowledge, information and data that is appropriate for each audience

•

Finally, Knowledge Management should gather, analyse, store, share, use and maintain knowledge, information and data throughout the service provider organization

S4Ap16


Knowledge management is a whole lifecycle-wide process in that it is relevant to all lifecycle stages and hence is referenced throughout ITIL from the perspective of each publication. It is dealt with to some degree within other ITIL publications, but is most relevant to the Service Transition stage of the lifecycle as effective transitions are most likely to be achieved if we have accurate knowledge of Users, Service Desk, Support and Service Provider. Effective sharing of knowledge requires the development and maintenance of a Service Knowledge Management System or SKMS. This would be made available to all information stakeholders and should suit all information requirements.

S4Ap17

The DIKW structure

Knowledge Management is often visualized using the DIKW structure. This acronym stands for DataInformation-Knowledge-Wisdom. Data - is a set of discrete facts about events. This data needs to be captured in order for it to be analysed and turned into useful information. Information - is the ability to manage the data content. This should help answer the questions ‘Who, What, When and Where’. Information may be used to support conformance with legal and other requirements. Knowledge - puts information into an ‘ease of use’ format which can aid decision making. The ability to answer ‘How?’ to use the information supports decision making. The knowledge depends on how easy it is to use accurate and relevant information about the services. All the requirements need to be understood and captured in such a way that it supports the business. Tools can be used to capture, store and manage data, information and knowledge as in the Service Knowledge Management System. Philosophers ponder the meaning of Wisdom and Insight.



95

4A


ITIL Foundation

? Activity

S4Ap18 Which of these statements are correct? Feedback Service Transition will provide guidance on all these areas.

S4Ap19

Summary

In this brief overview session on Service Transition we have: •

Identified the main goals and some key objectives of Service Transition

•

We went on to outline the value to the business of Service Transition

•

Finally we looked at the main Service Transition Processes including Change Management, Service Asset and Configuration Management, Release and Deployment Management and Knowledge Management

?

S4AQ

Topic Quiz




96

Change Management

4B S4Bp1

®

ITIL Foundation

Session objectives

In this session we will be examining Change Management, which is the subject of chapter 4.2 of the Service Transition book of the ITIL library. When you have completed this session you will: • • • • • • •

Understand the purpose, scope and objectives of Change Management Be aware of some of the important process terminologies Be familiar with the Change Management process Have seen the make-up of a Change Advisory Board Understand the key responsibilities of the Change Manager Be able to identify the top five risk indicators of poor Change Management Be aware of the key process roles

S4Bp2


Change is one of life’s certainties and it is generally accepted as best practice that Change Management and Service Asset and Configuration Management are planned and implemented concurrently alongside a clear Release and Deployment process. 'The purpose of the change management process is to control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.' The scope of Change management should reflect the many different ways that change can be defined. The ITIL definition of a change is ‘the addition, modification or removal of anything that could have an effect on IT services’. The scope of change management also covers changes to all configuration items across the whole service lifecycle, whether these CIs are physical assets, such as servers or networks, or virtual assets such as virtual servers or virtual storage, or other types of asset such as agreements or contracts. The scope of change management also covers all changes to any of the five aspects of service design. Some examples of the different requests for changes include - Changes to architectures, processes, tools, metrics and documentation, changes to service or a service definition, project change proposal, a user access request or an operational activity.

S4Bp3


The objectives of the Change Management process are to: • • • • •

Respond to the customer’s changing business requirements while maximizing value and reducing incidents, disruption and re-work Respond to the business and IT requests for change that will align the services with the business needs Ensure that changes are recorded, evaluated, and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner It should also ensure that all changes to configuration items are recorded in the configuration management system And finally Change Management should optimize overall business risk



97

Change Management

4B

®

ITIL Foundation

S4Bp4

Change terminology

Before we look at the process of Change Management, let’s take a quick look at some of the basic terminology. There are three types of Change. Firstly a Standard change: this is a pre-authorised change that is low risk, relatively common and follows an accepted and established procedure or work instruction. We then have Normal change: this is any change request that is not a standard or emergency change. A basic change management flow model is used as a guide for this process. And finally Emergency: This is a change that must be introduced as soon as possible , for example to resolve a major incident or implement a security patch.

S4Bp5

Change terminology continued

Other common Change Management terms include: Request for Change (or RFC) which is a formal proposal for a change to be made. Change Advisory Board (or CAB) which is a group of people that assist the Change Manager in the assessment, prioritisation and scheduling of changes. A CAB is created to assist the Change Manager and may vary in membership depending upon the type or types of changes proposed and what is being changed. Typical attendees of a CAB include: IT Service Managers, technical representatives, customer representatives, user representatives, suppliers, developers, consultants, finance, security, HR, facility management or anyone affected by the changes being assessed. It is safe to say, ‘The CAB represents all interested parties’. An Emergency Change Advisory Board (or ECAB) would be convened when the normal meeting date is too far away to respond to the suspect emergency situation. ECAB members will assist the Change Manager and will decide if the emergency change should be approved. Clearly in a well-managed environment, emergencies should be few and far between. Other Change Management terms include the ‘Change Schedule’ (or CS) which takes into account other planned changes and their effect as well as key monthly, quarterly, annual or seasonal business activities. And finally the Projected Service Outage (or PSO) is a document that identifies the effect of planned changes on agreed service levels and downtime.

?

S4Bp6

Activity

ITIL defines several change types. Can you identify them from the list provided? Feedback ITIL defines three change process types. These are Standard, Normal and Emergency.



98

Change Management

4B

®

ITIL Foundation

?

S4Bp7

Activity

Can you match the ITIL Change Management acronyms to their definitions? Drag the acronyms onto their corresponding definitions. Feedback A Change Schedule documents planned changes and their effect as well as key monthly, quarterly, annual or seasonal business activities. A Projected Service Outage identifies the effect of planned changes on agreed service levels and downtime. And a Request For Change is a formal proposal for a change to be made.

S4Bp8

Change Proposals

Prior to new or changed services being chartered it is important that the change is reviewed for its potential impact on other services, shared resources as well as any potential impact to the change schedule. Major changes that involve significant cost, risk or organisational impact are typically initiated through the Service Portfolio Management process. The change proposal or proposals will be submitted to the change management process before any chartering of new or changed service activities occur. Once received, the change proposal is reviewed by the Change Manager, along with the current change schedule, where the Change Manager will look to identify any potential conflicts or issues and will respond to the change proposal by either authorising it or documenting any issues that need to be resolved.

S4Bp9

Change Proposals continued

When the change proposal is authorized, the change schedule is updated to include outline implementation dates for the proposed change. Note that authorization of the change proposal does not authorize implementation of the change but simply allows the service to be chartered so that service design activity can commence. Let’s look at the typical content of a change proposal: Firstly it will include a high-level description of the new, changed or retired service, including business outcomes to be supported, and utility and warranty to be provided. It will also include a full business case including risks, issues and alternatives, as well as budget and financial expectations. An outline schedule for design and implementation of the change will also be included.

S4Bp10

Change models / workflows

A Change Model is a way of pre-defining the steps that should be taken to handle particular type of change in an agreed way.



99

Change Management

4B

®

ITIL Foundation

Using support tools will ensure that changes are handled in a pre-defined path and to pre-defined timescales. Sometimes these changes are called Standard Changes. Examples of standard changes include the setting up of a new user account or upgrading a PC to make use of specific standard and prebudgeted software. Standard changes have the following elements: • • • • •

There is a defined trigger to initiate the RFC The tasks are well known and documented Advance authority has been declared Budgetary approval is also given in advance The risk is low and usually well understood

Some standard changes will be triggered by the Request Fulfilment process and be directly recorded and passed for action by the Service Desk. No change should be approved without a clear remediation or ‘back-out’ plan properly identified, tested and approved.

S4Bp11

Change models / workflows continued

Another Change Model to consider is that for emergency changes. We have discussed the role of the ECAB already. When a change is declared to be an emergency change, all care must be taken to ensure that as much of the normal change process as possible is correctly followed, even if the change is being ‘pushed through’ as quickly as possible. Especially important is the recording and logging of all actions and activities undertaken in performing the emergency change. It is the responsibility of Change Management to ensure that all records are completed retrospectively, at the earliest possible opportunity. This is vital to ensure valuable management information is not lost. Not all emergency changes will require ECAB involvement. If the change is predictable both in occurrence and resolution, and well understood in terms of the change itself, then it may be appropriate to delegate authority to the Operations teams to action the change and ensure it is properly documented and reported on. As much testing as possible should be carried out, balancing the potential impact of the change not working, against the impact to the business of delaying the change. Completely untested changes should be avoided. It is vital that criteria to judge whether or not the change is an emergency change is agreed. Usually the ECAB is made up of the Change Manager, a representative from the business affected who will confirm the urgency requirement, and a representative from the technical department concerned, who will confirm that no workaround exists to delay the emergency action.

S4Bp12

Normal Change Process

All other changes will follow the ‘Normal Change’ process. Here we will take a step-by-step look at that process. The first step is creating and recording the RFC. Here we would be looking to ensure that all change requests were raised correctly and logged accurately from commencement.



100

4B

Change Management ®

ITIL Foundation

Step two is to review the RFC and change proposal. Anybody in the organization should have the ability to request a change. However, some caution and control should be exercised to ensure that unnecessary or undesirable and time-wasting change requests are not made. Here we would perform a filtering exercise to ‘weed’ out incomplete or wrongly routed changes. Step three is to assess and evaluate the change, checking at this point that we had the correct level of authority; who should be involved in the CAB for this change? and that business justification, impact, costs, benefits and the risks of the change had been assessed and evaluated. The change can now either be authorised or rejected. In either case, the CAB’s decision should be communicated to all interested parties, especially the Change Initiator.

S4Bp13

Normal Change Process continued

Assuming the change is authorised, then we can plan updates and issue the revised Change Schedule and Projected Service Outage documents and begin the co-ordination of the change implementation. Change Management doesn’t actually perform the implementation - this is the responsibility of the Release and Deployment process. Change Management oversees the implementation and has Release and Deployment reporting progress on all implementation aspects, including the build and test stages prior to final approval to proceed with implementation. It’s a bit like the relationship between the Air Traffic Controller and the Pilot wishing to land an aeroplane at a busy airport. The Air Traffic Controller ensures that all is cleared for the approach and that a terminal is available - the pilot has the skills to land the particular aircraft. After Release Management has implemented the change, the responsibility lies with Change Management to review and close the change. Review and closure activities include ensuring that all change documentation, including baselines and evaluation reports have been collated; that all documentation regarding the change had been fully reviewed; and that the change record is closed when all actions have been completed. Throughout these process steps, it is vital that the information is gathered and recorded on the CMS.

?

S4Bp14

Activity

Each ITIL process emphasises the metrics and management reports to provide relevant information about the performance of the process. What reports might you expect to see from Change Management? Feedback Well they could all reasonably be valid reports of Change Management process performance. Actual measure will vary depending on the nature of the organization, and change over time as Change Management and other IT Service Management processes mature. The important thing is that measures are taken, and where possible, these should be linked to business goals as well as cost, service availability and reliability. Any predictions should be compared with actual measures.



101

Change Management

4B S4Bp15

®

ITIL Foundation

Role of the Change Manager

ITIL guidance suggests a role to manage this process, namely the Change Manager. The role includes the following responsibilities: •

Remediation Planning

•

Change Management process and function development and maintenance

•

The management of RFCs from receipt to closure

•

Production of management information on all matters referencing changes

•

Monitoring the effectiveness of the Change Management process and recommending improvements

•

Chairing and convening both the CAB and the ECAB

•

Distributing the Change Schedule via Service Desk, and

•

Maintaining the Change Log

It is worth mentioning that Remediation planning should cover the ability to have a back-out plan if the change is unsuccessful. However not all changes can be backed out. If this is the case what are the choices? It could be that the ITSCM plan would need to be invoked. The risk of proceeding should be known prior to the change being authorized

S4Bp16

Top 5 Risk Indicators

By managing change, you manage much of the potential risk that changes can introduce. Change Management is the process that tries to optimise risk exposure by monitoring the indicators of poor change to help identify if Change Management is working well. The top five risk indicators of poor Change Management are: •

Unauthorised changes being carried out. Any unauthorised change above zero is unacceptable

•

Unplanned outages that have not been identified in the Projected Service Outage (PSO) document

•

A low change success rate on review of changes made

•

A high number of emergency changes being introduced and this usually identifies poor planning of changes

•

Delayed project implementations

S4Bp17

Value to the business

By having an effective and efficient Change Management process in place, the service provider can add the following value to the business?



102

4B

Change Management ®

ITIL Foundation

•

Protecting the business, and other services, while making required changes

•

Implementing changes that meet the customers’ agreed service requirements while optimizing costs

•

Contributing to meet governance, legal, contractual and regulatory requirements by providing auditable evidence of change management activity. This includes better alignment with ISO/IEC 20000, ISO/IEC 38500 and COBIT where these have been adopted

•

Reducing failed changes and therefore service disruption, defects and re-work

•

Reducing the number of unauthorized changes, leading to reduced service disruption and reduced time to resolve change-related incidents

•

Delivering change promptly to meet business timescales

•

Tracking changes through the service lifecycle and to the assets of its customers

•

Contributing to better estimates of the quality, time and cost of change

•

Assessing the risks associated with the transition of services, the introduction or disposal

•

Improving productivity of staff by minimizing disruptions caused by high levels of unplanned or ‘emergency’ change and hence maximizing service availability

•

Reducing the mean time to restore service (MTRS), via quicker and more successful implementations of corrective changes

•

And finally liaising with the business change process to identify opportunities for business improvement

S4Bp18

Summary

In this session we have been examining Change Management, which is the subject of chapter 4.2 of the Service Transition book of the ITIL library. We identified the l purpose, scope and objectives of Change Management, which is ‘to ensure that changes have a higher success rate, align business and IT, and are value for money’. We looked at the CAB and its role as an advisory body set up to assist the Change Manager in assessing, evaluating and prioritising changes, and went on to look at the ECAB. We saw how ITIL defines three change types, namely Standard, Normal and Emergency, and went on to look at how the Normal Change lifecycle should be used for all new or risky changes – or anything that is not standard or emergency. We introduced you to the concept of Change Models and typical contents of a change model, as well as introducing you to the change proposal concept. We completed the session by looking at some of the key metrics of the process, the Value to the Business from a service provider with a change management process in place, and we went on to look at the role of the Change Manager, and to outline some of the risk indicators and benefits that effective Change Management can deliver



103

4C


S4Cp1

®

ITIL Foundation

Session objectives

In this session we will be examining Service Asset and Configuration Management, which is the subject of chapter 4.3 of the Service Transition book of the ITIL library. When you have completed this session you will: •

Understand the purpose of the Service Asset and Configuration Management process.

• • • •

Be familiar with some of the basic concepts, including: A Configuration Model A Configuration Item, and A Configuration Management System

•

Be able to identify the five Service Asset and Configuration Management process activities

•

Be aware of the key process roles

S4Cp2

Introduction

No organization however large or small, can be fully efficient or effective unless it manages its assets well, particularly those assets which are vital to the organization’s or its customer’s business. Service Asset and Configuration Management (or SACM), sets out to provide a logical model of the organization’s infrastructure by identifying, controlling, maintaining and verifying versions of all the organization’s configuration items. Some organizations go part way to doing this with a simple asset management system, but you’ll see that Service Asset and Configuration Management is much more thorough and provides valuable information to the organization as a whole, and far greater accuracy when it comes to supporting IT. This ITIL process manages the service assets in order to support other Service Management processes. We’ll begin this session by considering the purpose, objectives and scope of the process.

S4Cp3

Process - purpose

The purpose of the SACM process is to: •

ensure that the assets required to deliver services are properly controlled, and

•

that accurate and reliable information about those assets is available when and where it is needed.

This information includes details of how the assets have been configured and the relationships between assets.



104

4C


S4Cp4

®

ITIL Foundation


The main objectives of the Service Asset and Configuration Management process are to: •

Ensure that assets under the control of the IT organization are identified, controlled and properly cared for throughout their lifecycle

•

To identify, control, record, report, audit and verify services and other configuration items (CIs), including versions, baselines, constituent components, their attributes and relationships

•

Account for, manage and protect the integrity of CIs through the service lifecycle by working with change management to ensure that only authorized components are used and only authorized changes are made

•

Ensure the integrity of CIs and configurations required to control the services by establishing and maintaining an accurate and complete configuration management system (CMS)

•

Maintain accurate configuration information on the historical, planned and current state of services and other CIs

•

Support efficient and effective service management processes by providing accurate configuration information to enable people to make decisions at the right time - for example to authorize changes and releases, or to resolve incidents and problems

S4Cp5

Process - scope

Let’s complete this introductory section by taking a quick look at the scope of the Service Asset and Configuration Management process. •

The process is responsible for the management of the complete lifecycle of a CI

•

It also ensures CIs are identified, baselined, maintained and changes to them are controlled

•

It provides a configuration model of the services and service assets by recording the relationships between configuration items

•

It also provides the Interfaces to external and internal service providers where there are assets and CIs that need to be controlled - for example shared assets

Service Asset and Configuration Management may also cover non-IT assets, such as people or buildings, and interfaces to internal and external service suppliers.

?

S4Cp6

Activity

The creation of a configuration model is the responsibility if which ITIL process? Feedback The configuration model is defined in the scope of Configuration Management. The configuration model defines the services, assets and the infrastructure, and the relationships which exist between them.



105

4C


S4Cp7

®

ITIL Foundation

Basic Concepts

Before we turn our attention to the process activities, let’s take a brief look at three of the basic concepts described in the ITIL guidance. These are the configuration model, configuration items and the configuration management system. The ‘configuration model’ can be described as a single common representation that denotes the services, assets and the infrastructure and their relationships. The configuration model is used by all parts of IT Service Management and the organization as a whole. A ‘configuration item’ (or CI) is any asset, service component or any other items under the control of Configuration Management. And finally the ‘configuration management system’, which can be defined as a set of tools that are used to manage an IT service provider’s configuration data. We will be looking at each of these concepts in more detail as we progress through the session.

S4Cp8

Configuration Model

On the previous page we briefly discussed the configuration model, and how it assists in defining the services, assets and the infrastructure by recording the relationships between configuration items. However, the real power of the configuration model is that it is. The model - i.e. a single common representation used by all parts of IT Service Management and also by others such as HR, finance, suppliers and customers. It enables other processes to access valuable information and perform the following activities: •

Assessing impact and cause of incidents and problems

•

Assessing impact of proposed changes

•

Planning and designing new or changed services

•

Planning technology refresh and software upgrade

•

Planning release and deployment packages and migrating service assets to different locations

•

Optimising asset utilisation and costs

The information can be recorded at varying levels of detail. At the highest level it may form an overview of all the services. At a detailed level it may be possible to view the specification for a service component.



106

4C

Service Asset and Configuration Management ®

ITIL Foundation

S4Cp9

Configuration Item

A configuration item (or CI) is an asset, service component or other item that is under the control of Configuration Management. CIs may vary in complexity, size and type and may be individual or grouped together, for example as in a release. There may be a variety of CIs, and the following categories may be used to identify them: Service lifecycle CIs - such as a Business Case, Service Management plans, service lifecycle plans, change and release plans and test plans. These will include such information as how services will be delivered, expected benefits, cost and when they will be realised. Service CIs - such as service capability assets, service resource assets, service model, service package, release package and service acceptance criteria. Organization CIs - for example, the organization’s business strategy or other policies, which are internal to the organization but independent of the service provider. Internal CIs - could be those items delivered by individual projects, an intangible asset such as software for example. External CIs - might be an external customer’s requirements and agreements. And finally Interface CIs - that are required to the end-to-end service across a service provider interface.

S4Cp10

Configuration Management System

The Configuration Management System (or CMS) is a set of tools that are used to manage an IT service provider’s configuration data and holds all the information for CIs within the designated scope. It also maintains the relationships between all components and any related incidents, problems, known errors, changes and releases and appropriate documentation. The diagram displays how the CMS covers the data and information in layers of the data/information/knowledge hierarchy described in Knowledge Management, which is covered in section 4.7 of the ITIL Service Transition book. The CMS relies on interfaces with the following processes/tools: •

Secure Libraries and Secure Stores

•

The Definitive Media Library

•

Definitive Spares

•

Configuration Baseline

•

Snapshot

So let’s take a look at each of these in more detail.



107

4C


S4Cp11

®

ITIL Foundation

Secure Library

A ‘Secure Library’ is a collection of software, electronic or document CIs of known type and status. It’s important to note that access to Secure Libraries is strictly controlled.

The Libraries are often used for controlling and releasing components throughout the Release lifecycle. The most obvious example of a Secure Library is the Definitive Media Library (or DML). The Definitive Media Library houses the definitive authorised versions of all media CIs in a secure environment, access to which is, again, strictly controlled. It stores master copies of all versions that have passed quality assurance checks. It may consist of one or more software libraries or file-storage areas that are separate from development, test and live file-store areas. It will include definitive versions of purchased software as well as in-house developed software. The DML will also include a physical store to hold master copies, and it provides the foundation for Release and Deployment Management.

?

S4Cp12

Activity

Drag and drop the words into the table to complete this group of Service Asset and Configuration Acronyms? Feedback The table should look something like this.

S4Cp13

Secure Store

A Secure Store is a location that warehouses IT assets and it forms an important role in delivering security and continuity, by providing reliable access to equipment of a known quality. An area should be set aside for the secure storage of definitive hardware spares. Details of these will be recorded within the CMS. These items can be used for additional systems or recovery from incidents. Once their use has ended, they should be returned to the Spares Store or replaced. A Configuration Baseline captures the structure, contents and details of a particular configuration and represents a set of related items. This allows an organization to: •

Mark milestones in developments

•

Build service components from a defined set of inputs

•

Change or rebuild a specific version at a later date

•

Assemble all relevant components for a release, and



108

4C •


ITIL Foundation

Provide the basis for a configuration audit and back-out after a failed change

Often referred to as baselines, this information also assists Problem Managers in analysing evidence from incidents and further allows for a system restore. A Snapshot can be defined as the current state of an environment or CI. Recorded in the CMS, a Snapshot remains as a fixed historical record. Snapshots can enable Problem Management to analyse evidence about a situation pertaining at the time the incident actually occurred.

S4Cp14


There are five basic process activities in Asset and Configuration Management. These are: Management and Planning - This includes developing the Configuration Management Plan, identifying and setting the scope, objectives, roles and responsibilities. Configuration Identification - Where identification of CIs and naming and labeling of CIs is carried out. Gathering data and documentation for baselines and release identification is also carried out here. Configuration Control - This activity ensures only approved changes and decisions are conducted. Status Accounting - This is where the status of each CI is recorded and, where appropriate, reported upon. Configuration information and performance measures are also identified here. And finally, Verification and Audit - Includes activities to confirm the existence of CIs and to establish the accuracy of the CMS.

S4Cp15

Management and Planning

The first of the processes is Management and Planning. ITIL guidance suggests that no standard template exists for determining the optimum approach for Service Asset and Configuration Management. Senior management should decide upon a documented Configuration Management Plan that will detail specific activities within the context of the overall strategy. An example plan is shown here. Some important headings include: •

Scope: to include

Applicable services Infrastructure and Environments Geographical locations •

Requirements, including links to policy or strategy. Including:

•

links to business, service management and contractual requirements

•

Policies and standards, including industry standards such as ISO/IEC 20000. Internal standards relevant to SACM such as hardware or software standards



109

4C


ITIL Foundation

•

Organization for Configuration Management, including roles and responsibilities

•

Asset and Configuration Management tools

•

And Relationship Management, including interface controls for internal and external communication

S4Cp16

Configuration Identification

The second SACM process is Configuration Identification. An important part of Configuration Management is deciding the level at which control is to be exercised, with top level CIs broken down into components, which are themselves CIs and so on. This should be done by applying a top down approach and considering whether it is sensible to break down a CI into its component CIs. When planning the identification of CIs, it is important to: • • •

Define the classes and types of identification Define how CIs will be labelled, and Define roles and responsibilities of owners or custodians of CIs

The Configuration Identification processes should also: • • • • •

Define and document criteria for selecting CIs and their components Assign unique identifiers to CIs Specify the relevant attributes of each CI Specify when each CI is placed under Configuration Management, and Identify the owner of each CI

In addition, consideration should be given to establishing and applying clear naming and labelling procedures.

S4Cp17

Configuration Identification attributes

The unique characteristics of a CI are known as its attributes, and these provide a valuable record, which will support the Service Asset and Configuration Management process. The identified attributes will define specific functional and physical characteristics of each type of asset and CI together with any documentation or statistics. Typical examples of CI attributes include: • Unique identifier • CI type ID • Name • Version number • Model/type identification • Place/location • Department responsible • Supplier • Supply date • Change record identification



110

4C • • •


ITIL Foundation

Incident/Problem record identification CI history Status

S4Cp18

Configuration Identification relationships

Relationships describe how CIs work together to deliver the services. The recording of these relationships in the CMS is one of the main differences between a complete CMS and a simple asset register, and what makes a CMS so valuable to the organization. Example relationships include the following: •

A CI is part of another CI. For example, a software module is part of a program. This is known as a parent - child relationship.

•

A CI is connected to another CI. For example, a desktop computer is connected to a LAN.

•

A CI uses another CI. For example, a business service uses an infrastructure server.

•

A CI is installed on another CI. For example, this e-learning is installed on your PC.

Further consideration should be given to establishing clear guidelines for the identification of Media Libraries, Configuration Baselines and Release Units.

S4Cp19

Configuration Control

The third SACM process is Configuration Control. Configuration control ensures that there are adequate control mechanisms over CIs while maintaining a record of changes to CIs, versions, location and custodianship/ownership. Without control of the physical or electronic assets and components, the configuration data and information there will be a mismatch with the physical world. CIs should not be added, modified, replaced or removed without an appropriate controlling procedure being followed.

S4Cp20

Configuration Control continued

Policies and procedures should be in place to cover, amongst other things: •

Licence Control

•

Change Management

•

Version Control of service asset, software and hardware versions, images, builds and releases

•

Access Control, for example to facilities or to storage areas and

•

Build Control, including the use of build specification from the CMS to perform a build

•

Promotion, migration of electronic data and information



111

4C


ITIL Foundation

•

Taking a configuration baseline of assets or CIs before performing a release, for example into system, acceptance test and live, in a manner that can be used for subsequent checking against actual deployment

•

Deployment control including distribution

•

Installation

•

And maintaining the integrity of the DML

S4Cp21

Status Accounting and Reporting

Status Accounting and Reporting is the fourth SACM process. Each asset or CI will have one or more discrete states through which it can progress in its lifecycle. At each lifecycle status change the Configuration Management system will be updated. Typically there will be a range of states relevant to the individual asset or CIs. Configuration Status Accounting and Reporting is concerned with ensuring that all configuration data and documentation is recorded as each asset or CI progresses through its lifecycle. A simple example of a lifecycle might look something like this. Development or Draft, denoting that the CI is under development and that no particular reliance should be placed upon it. Approved, meaning that the CI may be used as a basis for further work. Withdrawn, meaning withdrawn from use, either because it is no longer fit for purpose or that there is no use for it. Further consideration should be given to ensure that CI status can be recorded efficiently and that there is a regular report available as required.

?

S4Cp22

Activity

Can you select the five Service Asset and Configuration and Management sub processes from the list below? Feedback The five Service Asset and Configuration and Management sub processes are; Management and Planning, Configuration Identification, Configuration Control, Status Accounting and Reporting and Verification and Audit.

S4Cp23

Verification and audit

The fifth and final SACM process is Verification and Audit. This is a series of reviews or audits to ensure: Conformity between documented baselines and the actual business environment. And to verify physical existence of CIs in the organization, DML or Spares Stores.



112

4C


ITIL Foundation

And also to check that Release and Configuration documentation is present prior to a release. Audits should be considered at the following times: •

After changes to the CMS

•

Before and after any significant changes

•

Before a release

•

Following recovery from disaster, and

•

Following detection of any unauthorised CIs

Audits can be planned or conducted at random.

S4Cp24

Process relationships

We’ve already started to see the role that the CMS plays for Incident and Problem Management and the Service Desk. The same is true for the other processes like, Release and Deployment Management, Change Management, Capacity Management, Availability Management, Financial Management and IT Service Continuity Management. Legal requirements can also be met, particularly for software licences and meeting contractual obligations about what is and isn’t supported and/or present in the infrastructure. Configuration Management can have a significant role to play in financial planning too. Software changes can trigger investigation into requirements for data protection, licence management and regulatory requirements. Also effective control mechanisms will reduce the use of unauthorised software and the risks and support issues it raises. Security can improve when controlling CIs as it’s more difficult to change items accidentally, maliciously or for erroneous versions. As we’ve seen the CMS facilitates Trend and Impact Analysis for changes and problems. Assistance with disaster recovery is another key area for Service Asset and Configuration Management. Unfortunately disasters are an ever-present concern and information held by SACM about the IT infrastructure could be invaluable in many circumstances, including fire or flood.

S4Cp25

Process - roles

As a process owner, there are several responsibilities that the Configuration Manager must undertake. These range from ensuring that the Configuration Management processes run efficiently and effectively and are monitored and audited on a regular basis, to identifying weaknesses and implementing process improvements. The Configuration Manager will be the champion for Configuration Management throughout the organization and will maintain awareness of the process for all interested parties.



113

4C


ITIL Foundation

The role will also: •

Maintain all appropriate standards and identify and shape policy

•

Be responsible for the maintenance of the Configuration Management system and the Configuration Management Database and will be involved in the impact assessment of all Changes and Releases

S4Cp26

Roles

Finally, the configuration manager will have a number of resources to manage, including Configuration Administrators and Configuration Librarians. The Configuration Administrator/Librarian is the custodian and guardian of all master copies of software, Assets and documentation CIs registered with Asset and Configuration Management. The major tasks of this role are: •

to control the receipt, identification, storage, and withdrawal of all supported CIs

•

to provide information on the status of CIs

•

To number, record, store and distribute Asset and Configuration Management issues

S4Cp27

Summary

This concludes the session on the ITIL process of Service Asset and Configuration Management. In this session we have looked at the reasons for implementing a Service Asset and Configuration Management process. We examined some of the basic concepts associated with the process, including: • • •

A Configuration Model A Configuration Item, and A Configuration Management System

We went on to identify the five Service Asset and Configuration Management process activities, namely: • • • • •

Management and Planning Configuration Identification Configuration Control Status Accounting and Reporting Verification and Audit

Finally we highlighted some key SACM roles.



114

4D S4Dp1

Release & Deployment Management ®

ITIL Foundation

Session objectives

In this session we will be examining Release and Deployment Management (or RADM), which is the subject of chapter 4.4 of the Service Transition book of the ITIL library. When you have completed this session you will: •

Understand the purpose, scope and objectives of Release and Deployment and be aware of some of the important process terminologies

•

Be familiar with the RADM process, Release models Understand the key responsibilities of the RADM Manager and be aware of other key process roles

Release and Deployment Management concentrates on effective planning that takes into account the technical and non-technical aspects of getting hardware and software changes into the IT infrastructure efficiently.

S4Dp2


So why do we need Release and Deployment Management? In simple terms, it's the controlling process which ensures that all aspects of a release are handled properly, including the software, hardware and documentation required. It focuses on protecting the live environment and its services through the use of formal procedures and checks. This process requires technical competence, and its sub-processes are often performed by technical staff under the overall authority of the Service Transition Manager. The purpose of the release and deployment management process is to plan, schedule and control the build, the testing and deployment of releases, and to deliver new functionality required by the business while protecting the integrity of existing services. But what exactly do we mean by the term ‘release’? Well, ITIL describes a release as ‘a collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT Services. It goes on to note that the contents of each release are managed, tested, and deployed as a single entity. The ITIL process of Release and Deployment Management exists to ensure this happens.

?

S4Dp3

Activity

Here’s a quick Release and Deployment question. How does ITIL define a ‘release’? Feedback ITIL describes a release as ‘a collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT Services.



115

4D S4Dp4


ITIL Foundation


Before we look at the RADM activities in detail, let’s outline some of the process objectives. •

Firstly it should define and agree release and deployment management plans with customers and stakeholders

•

It should also create and test release packages that consist of related configuration items that are compatible with each other

•

It should also ensure that the integrity of a release package and its constituent components is maintained throughout the transition activities, and that all release packages are stored in a DML and recorded accurately in the CMS

•

RADM activities also include the deployment of release packages from the DML to the live environment following an agreed plan and schedule

•

And ensuring that all release packages can be tracked, installed, tested, verified and/or uninstalled or backed out if appropriate

S4Dp5

Process - objectives continued

Other objectives of the RADM process include: •

Ensuring that organization and stakeholder change is managed during release and deployment activities

•

And that a new or changed service and its enabling systems, technology and organization are capable of delivering the agreed utility and warranty

•

RADM should also record and manage deviations, risks and issues related to the new or changed service and take any necessary corrective action

•

RADM should also ensure that there is knowledge transfer to enable the customers and users to optimize their use of the service to support their business activities

•

Along with ensuring that skills and knowledge are transferred to service operation functions to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels

S4Dp6

Release Policy

In order to provide effective management and control of all releases, it is necessary for the organization to have a Release Policy in place. It is the Release Policy that provides clear communication to all concerned. For example, a Release Policy may say that only ‘emergency fixes’ will be issued in between formally planned releases of enhancements and non-urgent corrections.



116

4D


ITIL Foundation

The Release Policy is created in Service Strategy and is a requirement for the successful deployment of changes. The Policy could form part of the overall Change Plan and could include aspects of Configuration Management too. The release policy should be defined for one or more services and will typically include: •

The unique identification, numbering and naming conventions for different types of release together with a description

•

The roles and responsibilities at each stage in the release and deployment management process

•

The requirement to only use software assets from the definitive media library

•

The expected frequency for each type of release

S4Dp7

Release Policy continued

The release policy should typically also include: •

The approach for accepting and grouping changes into a release, for example, how enhancements are prioritized for inclusion

•

The mechanism to automate the build, installation and release distribution processes to improve re-use, repeatability and efficiency

•

How the configuration baseline for the release is captured and verified against the actual release contents, such as hardware, software, documentation and knowledge

•

Exit and entry criteria and authority for acceptance of the release into each service transition stage and into the controlled test, training, disaster recovery and other supported environments

•

Criteria and authorization to exit early life support and handover to the service operation functions.

•

Release deployment models will document how the policy will be followed by providing the details of how this will be achieved and by whom.

S4Dp8

Release and Deployment Terminology

As is common with many other ITIL disciplines, Release and Deployment Management contains some concepts and terms which you may not be familiar with. The first of these concepts is a Release Unit. A Release Unit describes the portion of a service or IT infrastructure that is normally released together and may vary considerably across an organization. This should be defined in the Release Policy. The second concept is that of Release Identification. ITIL suggests that all releases must be uniquely identified and again, the identification scheme will be described in the Release Policy. The identification should include a reference to the constituent configuration items and a version number, for example; Stock Control v1.3.6.



117

4D


ITIL Foundation

S4Dp9


There are four phases to release and deployment management, these are: •

Release and deployment planning - Here plans for creating and deploying the release are created. This phase starts with change management authorization to plan a release and ends with change management authorization to create the release

•

The second phase is Release build and test, here the release package is built, tested and checked into the DML. This phase starts with change management authorization to build the release and ends with change management authorization for the baselined release package to be checked into the DML by service asset and configuration management. This phase only happens once for each release

•

The third phase is Deployment. Here the release package in the DML is deployed to the live environment. This phase starts with change management authorization to deploy the release package to one or more target environments and ends with handover to the service operation functions and early life support. There may be many separate deployment phases for each release, depending on the planned deployment options

S4Dp10


The fourth and final phase of the Release and Deployment Management is Review and close. Here experience and feedback are captured, performance targets and achievements are reviewed and lessons are learned. The diagram illustrates the multiple points where an authorized change triggers release and deployment management activity. This does not require a separate RFC at each stage. Some organizations manage a whole release with a single change request and separate authorization at each stage for activities to continue, while others require a separate RFC for each stage. Both of these approaches are acceptable, what is important is that change management authorization is received before commencing each stage. The starting point is Planning. The Planning activity will consider the Release and Deployment plans. For each release, the plans should define: •

The scope and content of the release

•

The risk assessment and risk profile

•

Organizations and stakeholders affected

•

Approvers of the change request

•

Who will take responsibility for the release

The pass and fail criteria for each release will also need to be considered. There should be an authorisation point defined throughout each stage of the release. As part of Planning, we also need to consider the build and test requirements and specifications prior to production. The Service ‘V’ model can assist here in identifying the different configuration levels to be built and tested to deliver a service capability. Let’s take a few moments to look at that now.



118

4D


ITIL Foundation

?

S4Dp11

Activity

In ITIL, components of an IT Service that are normally released together are known as a... Feedback Components of an IT Service that are normally released together are known as a Release Unit.

S4Dp12

Process - benefits

The importance of effective Change, Configuration and Release Management continues to grow alongside the organization’s dependency on IT. These processes can provide many benefits. •

Release and Deployment Management can provide the following benefits

•

It can add value to the business by delivering change, faster and at optimum cost and minimized risk

•

Releases are built and implemented to schedule

•

There should be low or no incidences of build failures

•

Only authorized hardware and software is held in estate

•

The Costs understood in advance

•

It can provide management reports on quantity, quality and effect of releases

•

And it should deliver right-first-time implementations

S4Dp13

Process - roles

Finally, let’s take a quick look at the roles and responsibilities of both a Deployment Manager and a Release Manager. The Release Packaging and Build Manager responsibilities include: •

Establishing the final release configuration, ensuring the correct combination of Knowledge, Information, Hardware, Software and Infrastructure is built

•

Building the final release

•

Testing the release prior to independent testing

•

Publishing outstanding known errors and workarounds

•

Providing input to the final implementation sign-off process



119

4D S4Dp14


ITIL Foundation

Process - roles - continued

The Release and Deployment Manager: •

Manages all aspects of the end-to-end release process

•

Updates the SKMS and CMS

•

Ensures the coordination of the build and test environment team and release teams, and ensures they follow established policies and procedures

•

Provides management reports on release progress

•

Deals with release package design, build and configuration, including testing to predefined Acceptance Criteria, and the acceptance and sign-off of release packages

•

Deals with the storage and traceability and auditability of controlled software

•

And deals with the release, distribution and the installation of package software

•

Also, don’t forget the following:

•

Build and test staff will be supporting the controlled test environment and the deployment staff in the changeover to operations

Early life support staff will provide knowledge and skills to support functions such as the Service Desk, second line support, operations control and Facility Management and will also capture related issues within the live environment.

S4Dp15

Summary

This brings us to the end of this session on Release and Deployment Management, which is the subject of chapter 4.4 of the Service Transition book of the ITIL library. In this session we: •

Outlined the goal and objectives of the RADM process and defined what a Release is in ITIL terms

•

Described the reason for, and typical contents of a Release Policy

•

Reviewed some Release and Deployment Management concepts, including a ‘Release Unit’ and ‘Release Identification’

•

We looked in some detail at the process activities in the Development, Test and Live environments, and described how the Service V-model can assist with the design, build and testing of a service package



120

4D •


ITIL Foundation

Finally we looked at some of the benefits provided by the RADM process, and went on to describe two important roles, namely, the Release Packaging and Build Manager and the Release and Deployment Manager, as well as introduced you to the staff required during Early Life support and Build and test environments



121


4E

®

ITIL Foundation

S4Ep1

Session objectives

The subject of this session is Knowledge Management which is covered in chapter 4.7 of the ITIL Service Transition publication. Once you have completed this session you will: •

Be able to state the purpose, scope and objectives of Knowledge Management

•

Be able to explain the DIKW structure

•

Understand the structure of an SKMS

It is worth pointing out that Knowledge Management is a whole lifecycle-wide process in that it is relevant to all lifecycle sectors and hence, although we are setting out the basic concepts here in Service Transition, it is very much applicable elsewhere, as well.

S4Ep2


The purpose of the knowledge management process is to share perspectives, ideas, experience and information and to ensure that these are available in the right place at the right time to enable informed decision. This in turn improves efficiency by reducing the need to rediscover knowledge. People need to be able to respond to circumstances and in order to do that; they need to understand the situation, the options and the consequences and benefits. They need to possess appropriate knowledge. The scope of Knowledge management covers: •

Service lifecycle-wide process, but is relevant to all stages of the lifecycle

•

Includes oversight of the management of knowledge, and the information and data from which that knowledge derives

•

Knowledge management excludes detailed attention to the capturing, maintenance and use of configuration data

The quality and relevance of the knowledge rests in turn on the accessibility, quality and continued relevance of the underpinning data and information available to service staff.

S4Ep3


Appreciating some of the key objectives of Knowledge Management will help you to gain a better awareness of its importance. Here are the key objectives: •

To improve the quality of management decision-making by ensuring that reliable and secure knowledge, information and data is available throughout the service lifecycle

•

Knowledge Management will enable the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service by reducing the need to rediscover knowledge



122

4E

Knowledge Management ®

ITIL Foundation

•

The process also ensures that staff have a clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from the use of those services

•

Knowledge Management will also maintain a service knowledge management system or SKMS which provides controlled access to knowledge, information and data that is appropriate for each audience

•

A final objective of Knowledge Management is to gather, analyse, store, share, use and maintain knowledge, information and data throughout the service provider organization

?

S4Ep4

Activity

We have just stated that one of the key objectives of Knowledge Management is: ‘To maintain a service knowledge management system or SKMS, that provides controlled access to knowledge, information and data that is appropriate for each audience.’ Which roles from the list below should have access to the SKMS? Feedback More roles than these 2 listed should have access to the SKMS. Again the list is too narrow in who should have access to the SKMS. Any role that is a stakeholder in the SKMS may have access to it. This could include the Incident Manager, Change Manager, Information Security Manager to the Service Asset and Configuration Manager role.

S4Ep5

The DIKW Diagram

This diagram is known as the DIKW structure - Data, Information, Knowledge, Wisdom. Let’s just check we understand what is meant by each of these terms as, in everyday use, the meaning often gets confused. Data is a set of discrete facts about events. All data needs to be captured and decisions have to be made about the data being captured. •

Which data is the correct data to capture?

•

How are we going to store and use the data?

•

What data is currently being captured and what data can be captured?

Information comes from analysing the captured data or, to put it another way, putting the data into its context thus producing useful information. In simple terms, whereas data may be a file of numbers, the information obtained from that data would be in some semi-structured form such as a document, and e-mail or even some form of multimedia. Information helps answer the questions Who? What? When? and Where? Another important use of information is in the support of conformance with legal and other requirements.



123


4E S4Ep6

®

ITIL Foundation

The DIKW diagram continued

Knowledge, the next stage in the synthesis, puts information into an ‘ease of use’ format such that it can actually aid decision-making - it can answer the question ‘How shall I use the knowledge based on the information that has been provided, with the aim being continual improvement?’ In Service Transition, knowledge is created by taking the information and not only adding such things as the experiences, ideas, insights, values and judgements of individuals but also experience of previous transitions, awareness of recent and anticipated changes and other areas that experienced staff will have been unconsciously collecting for some time. Finally, Wisdom is the application of the knowledge with common sense judgement. That is to say, being able to give reason ‘Why?’ a decision is made. So, to go back to the start, the actual data collected is of vital importance. It has to support the business and hence the business requirements have to be fully understood. Whilst tools are available to capture, store and manage data, information and knowledge, nothing exists to help us with wisdom.

?

S4Ep7

Activity

Select each of the options for which there is a tool to help us. Feedback Yes. Whilst there are tools to help us manage data, information and knowledge, there are no tools to help us with wisdom.

S4Ep8

Service Knowledge Management System (SKMS)

Within IT Service Management we refer to a Service Knowledge Management System (or SKMS). If we think in terms of the data, information, knowledge, wisdom that we have just described, the Configuration Management Databases (or CMDBs) for short, is where we gather and store our data. The Configuration Management System, besides containing the CMDBs also includes information about Incidents, Problems, Known Errors, Changes and Releases. It may also contain data about employees, suppliers, locations, business units, customers and users. In addition to this, the SKMS has a much wider base of knowledge, for example: •

The experience of staff

•

Records of peripheral matters, such as weather statistics, user numbers and behaviour, the organization’s performance figures

•

Suppliers’ and partners’ requirements, abilities and expectations

•

Typical and anticipated user skill levels.

The net result is that the SKMS is able to support the informed decision-making process.



124

4E S4Ep9

Knowledge Management ®

ITIL Foundation

Service Knowledge Management System (SKMS) continued

This diagram looks at the SKMS in more detail. It shows several layers representing, from the bottom up, Data, Information, Knowledge and Presentation. As we have already seen, tools do not exist to provide wisdom and so the SKMS, only goes as far as the Knowledge layer. Knowledge can be used to support many areas of the lifecycle, for example: Operations staff: • • • •

Incidents and time taken to restore service Staff experience Diagnostic time and fixes Scripts used

Transition staff: • •

Incidents related to changes or new services Incidents fixed by changes

Strategy: • •

Service portfolio Training in the use of services

S4Ep10

Summary

In this session we have been studying an overview of Knowledge Management which is covered in chapter 4.7 of the ITIL Service Transition publication. In this session we have seen: • • • •

The purpose, scope and objectives of Knowledge Management An explanation of the DIKW structure The roles within the Knowledge Management process The structure of an SK



125

Transition Planning and Support

4F

®

ITIL Foundation

S4Fp1

Session objectives

The subject of this session is Transition Planning and support, which is covered in chapter 4.1 of the ITIL Service Transition publication. Once you have completed this session you will: •

Be able to state the purpose of Transition Planning and Support

•

Be able to state the scope of Transition Planning and Support as well as the objectives of the process, and finally you will

•

Be able to explain the Value to the business of the Transition Planning and support process

S4Fp2


The purpose of the transition planning and support process is to provide overall planning for service transitions and to coordinate the resources that they require. The scope of the process includes: •

Maintaining policies, standards and models for service transition activities and processes - the Release Policy, and Change policy are examples to note

•

Guiding each major change or new service through all the service transition processes

•

Coordinating the efforts needed to enable multiple transitions to be managed at the same time

•

Prioritizing conflicting requirements for service transition resources

It is worth noting that the activities of detailed planning of the build, test and deployment of individual changes or releases are not the responsibility of Transition planning and support, these activities are carried out as part of change management and release and deployment management.

S4Fp3


Transition Planning and support, like Service Transition itself has many objectives, which are to: •

Plan and coordinate the resources to ensure that the requirements of service strategy encoded in service design are effectively realized in service operation

•

Coordinate activities across projects, suppliers and service teams where required

•

Establish new or changed services into supported environments within the predicted cost, quality and time estimates

•

Establish new or modified management information systems and tools, technology and management architectures, service management processes, and measurement methods and metrics to meet requirements established during the service design stage of the lifecycle



126

4F

Transition Planning and Support ®

ITIL Foundation

•

Ensure that all parties adopt the common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and coordination activities

•

Provide clear and comprehensive plans that enable customer and business change projects to align their activities with the service transition plans

•

Identify, manage and control risks, to minimize the chance of failure and disruption across transition activities; and ensure that service transition issues, risks and deviations are reported to the appropriate stakeholders and decision makers

•

And finally monitor and improve the performance of the service transition lifecycle stage

S4Fp4


Effective transition planning and support can significantly improve a service provider’s ability to handle high volumes of change and releases across its customer base. An integrated approach to planning improves the alignment of the service transition plans with the customer, supplier and business change project plans. This brings us to the end of this session. We have •

Introduced you to the purpose of Transition Planning and Support

•

Described the scope of Transition Planning and Support as well as the objectives of the process, and finally

•

Explained the value to the business of the Transition Planning and support process



127

5A S5Ap1

Overview of Service Operation ®

ITIL Foundation

Session objectives

This overview session looks at the ITIL Service Management publication, Service Operation, which is one of the five ITIL core publications within the service lifecycle. The Service Operation book provides guidance on how to achieve effective and efficient delivery and support of services, so that value is delivered for both the customer and the Service Provider. In this Overview session we will: •

Summarise the book by describing how Service Operation ‘co-ordinate and carry out the activities and processes required to deliver and manage services at agreed levels, to business users and customers’.

•

Identify the main objectives and processes of Service Operation and the value it can bring to the business

•

We will go on to introduce the main Service Operation processes including Incident Management, Problem Management, Event Management, Request Fulfilment and Access Management.

•

We’ll also look briefly at the functions and describe the role of the Service Desk and the importance of good communications.

•

Finally we’ll outline the remaining functions of IT Operations Management, Technical Management and Applications Management including Application development.

S5Ap2

Purpose and objectives

Service Operation is recognised as a critical stage of the service lifecycle. All of the previously wellplanned and well-implemented processes in Service Design and Service Transition will be to no avail if the day-to-day operation of those processes is not properly conducted, controlled and managed. Service improvements would also not be possible if day-to-day activities to monitor performance assess metrics and gather operational data are not systematically conducted during service operation. Those involved in the Service Operation stage of the service lifecycle will be following recognised processes and related activities, using tools and technology that will allow them to have an overall view of service operation and delivery, rather than just focussing on separate components, such as hardware, software applications and networks, that make up the end-to-end service from a business perspective. These processes and tools should also assist those in operational roles with the detection of any threats or failures to service quality. Value to the business will be realized by service providers adopting and implementing standard consistent approaches for service operation. By selecting and adopting the best practice as recommended in the ITIL service operation publication the following value to the business can be seen. These are summarized here, take a moment to read through them.

S5Ap3

Purpose and objectives continued

As services may be provided, in whole or in part, by one or more partner/supplier organizations, the service operation view of the end-to-end service should be extended to encompass external aspects of



128

Overview of Service Operation

5A

®

ITIL Foundation

service provision. When necessary, shared or interfacing processes and tools should be deployed to manage cross-organizational workflows. The Objectives of the Service Operation stage of the service lifecycle are: •

To coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers

•

And be responsible for the on-going management of the technology that is used to deliver and support services

Service Operations is the phase of the Service lifecycle that is responsible for ‘Business As Usual’ activities. Service Operations focus on the day-to-day activities required to support and deliver IT Services. Capabilities and resources are required to support and deliver the required Services. Capabilities include the people who use processes, skills and knowledge to find the cause of the failure and then propose the solution. Problem Management helps to do this.

S5Ap4

Purpose and objectives continued

A resource such as the Incident Record provides the information on earlier faults that may also help those involved with problem investigation and diagnosis such as the problem management activities, to identify the cause. In addition, Service Management is involved in day to day activities including; •

The management and control of the technology used to deliver Services, such as providing access to Services and ensuring that data is backed up

•

Monitoring the performance of technology, activities and processes including network performance monitoring and time to restore a Service after a failure

There are often conflicting demands that must be balanced, for example the highly reactive Incident Management process may suggest a ‘quick fix’ to an application to restore the service quickly, such as a ‘reboot’. Whereas Problem Management wants time to find the cause and fix it permanently. This means time and cost on the investigation. By focusing on the delivery and control process activities, a reliable and steady state of managed services can be achieved. The main scope of the Service Operation stage of the Service Lifecycle are: •

The services themselves

•

Service management processes

•

Technology

•

People

S5Ap5

Incident Management

Let’s take a few moments to examine the five main Service Operation Processes. These are Incident Management, Problem Management, Event Management, Request Fulfilment and Access Management



129


5A

®

ITIL Foundation

The first Process is Incident Management. Incident Management deals with ’any event which disrupts, or which could disrupt, a Service‘. The goal of this process is to ’restore normal Service Operation as quickly as possible and minimize the adverse impact on business operations’.

There are many ways in which Incident Management delivers value to the business; here are three important ones: •

Firstly it can identify potential improvements to Services

•

It can also identify additional Service or training requirements

•

And finally it can detect and resolve incidents quickly

All of these ultimately result in reduced downtime for the business and higher Service availability. Incident Management works very closely with other Service Operation areas such as Problem Management and IT Operations Management. They also need to be consulted when an SLA is defined. For example with Service Level and Supplier Management as Incident Management must ensure that the incident response times and resolution targets defined within the SLA and Contract are measurable, achievable and traceable.

S5Ap6

Incident Management continued

We’ll now look at some of the Incident Management process in detail. In order to ‘restore normal service operation as quickly as possible and minimize the adverse impact on business operations’ Incident Management must follow agreed procedures. Many incidents are not new, so it sensible to pre-define ‘standard’ Incident Models. The Incident Model should include the steps required handle the incident and the order in which to take them. They may define: •

How to prioritise the incident; in terms of urgency, impact and ease of resolution

•

Dependencies and Responsibilities; who should do what

•

Timescales and thresholds for completion of the actions

•

Escalation procedures; who should be contacted and when, for example Capacity- or performancerelated incidents would be routed to Capacity Management

•

Evidence-preservation activities; this is often a Governance requirement and particularly relevant for security and capacity-related incidents

There are many automated tools that help with Incident Management - as well as tools to help with all the other Service Operations processes.



130

5A


ITIL Foundation

?

S5Ap7

Activity

When an incident is logged the Incident Management process must prioritise it. For example, if an incident occurs that causes widespread disruption, it is sensible to use all available resources to restore the service. Whilst handling such a ’major incident‘ other incidents may be delayed with consequent impacts on other services. Therefore the priority defined for different incidents may require agreement across the organization as well as within specific IT organizational units. In your organization what is defined as a major incident? If you cannot answer, it may indicate that your organizations IT Service and the Business Continuity Plans are seriously incomplete! Here is a question from a Foundation Certificate examination paper. You might like to try out your skills. Feedback You actually need more information.

S5Ap8

Problem Management

The second of the Service Operation processes is Problem Management. The primary objectives of the Problem Management process are to: •

prevent problems and resulting incidents from happening

•

to eliminate recurring incidents

•

to minimize the impact of incidents that cannot be prevented

Problem Management may be reactive or pro-active. Reactive Problem Management analyses incidents and finds the root cause. Once the cause is found Problem Management helps to develop solutions. These are implemented through Change and Release Management. Pro-Active or preventive Problem Management helps to identify weak points in an IT Service and develop solutions to avoid or reduce them. Examples of proactive problem management activities might include: •

Conducting periodic scheduled reviews of incident records to find patterns and trends in reported symptoms that may indicate the presence of underlying errors in the infrastructure

•

Conducting major incident reviews where review of ‘How can we prevent the recurrence?’ can provide identification of an underlying cause or error

Problem Management maintains information about problems and the appropriate workarounds and resolutions. This information should help to reduce the number and impact of incidents. The records maintained, include problem records and known error records. The Known Error records, which are



131

5A


ITIL Foundation

stored in the Known Error Database, are also used by Incident Management to help identify work-rounds in other words a ‘quick fix’. Problem Management may use the same tools and similar categorization, impact and priority coding systems as described earlier in Incident Management. Ultimately Problem Management creates business value by removing the causes of incidents and downtime and therefore enabling the service to facilitate business efficiency.

S5Ap9

Problem Management Techniques

Problem Management may use different techniques to help find the root cause of problems. Let’s look at a few of the more frequently used ones. Firstly, Chronological Analysis - By documenting all events in time order it is often easy to identify related or unrelated events. Brainstorming involves collecting relevant people together to suggest causes or potential actions to resolve a problem. Pain Value Analysis on the other hand uses a ’pain factor‘ formula involving; •

The number of people affected

•

The duration of the downtime caused

•

The cost to the business

You may be familiar with Pareto Analysis or the ‘80:20 rule’. Put simply, this involves ranking the problems and solving the highest ranking problems first. The Ishikawa tool is another you might find useful, sometimes referred to the ‘fishbone’ or ‘cause and effect’ technique. The idea is to use the skeleton of a fish on a chart with the symptom inserted into a box on the skeleton where the head of the fish is usually located, then branch off at the least 4 main bones from the main backbone of the fish, each main trunk is then allocated a title/area of possible cause that can then be investigated and reported back on. If further investigation is then required resources are allocated accordingly. There are many other techniques and tools, such as ‘Kepner Tregoe’ to add to this list. The tools used in problem management to aid root cause analysis identification can also be used by Availability Management All processes we’ll discuss in this course must be monitored to determine how well they are working and to establish what can be improved. One metric which can help to measure how effective Problem Management is would be the improvement in the percentage of problems resolved within the last, year compared with the previous year.

?

S5Ap10

Activity

Consider the fast food restaurant.



132

5A


ITIL Foundation

How might Incident and Problem Management processes deal with the following? Feedback All of these go through the incident management process A customer being provided with the wrong pizza would be handled as an incident. It could be caused by many things such as picking up the wrong pizza in the kitchen. If it is happening often then there may be something more fundamental like the ordering screen on the handheld device may be difficult to see The credit card authorisation rejection could be due to network failures or an invalid card. If it is a network issue then the ‘work-round’ may be to take a paper copy of the card. Printers and display failures could be a major incident as the pizza ordering relies on the cook knowing what is ordered by print or screen. It needs rapid investigation to find the cause. Finally the waiters request for help is a simple “Request Fulfilment” we need to help to change it.

?

S5Ap11

Activity

Which of the following techniques is ‘most’ useful in determining the root cause of problems? Feedback Pain Value Analysis focuses on the impact of the problem and assists with prioritisation. Pareto Analysis focuses on helping you to decide which problem to tackle first based on impact and other factors. Chronological Analysis, Brainstorming and others like Ishikawa, 5 hats, Kepner Tregoe can assist with root cause identification.

S5Ap12

Event Management

Our third Service Operation process is Event Management. ITIL says that ‘Events’ are ‘Any change of state that has significance for the management of a configuration item (CI) or IT service. Events are typically recognized through notifications created by an IT service, CI or monitoring tool’. Service Operation depends on knowing the status of the infrastructure. This status can be provided by using monitoring tools. Event monitoring may be ‘active‘ or ’passive‘. In the fast food restaurant an ‘active’ example would be when the wifi network is regularly ’pinged‘ to see if it is available, if not then an alert is triggered. Creating an alert when the printer it is switched off would be a ‘passive’ example. There are three types of events: •

Informational - For example, a scheduled backup has completed normally

•

Warning; a threshold is threatened. - For example, the capacity of a disc volume is within 5% of the threshold

•

And Exception



133

5A -


ITIL Foundation

A router has failed

The latter events will lead to alerts being generated. Alerts require either an immediate action or an action in the near future. In our Fast food restaurant, Event Management tools will be monitoring oven temperature (the thermostat), Carbon Monoxide levels from the ovens and food temperature for health reasons. Whilst you are driving your car or flying your glider you are continually monitoring and reacting to events.

S5Ap13

Request Fulfilment

Our fourth process is Request Fulfilment. A ’Service Request‘ is often for a ’small changes‘. Typically the requests are low risk, frequently occurring, easy to model and low cost, and like other processes Request fulfilment will use the Request Model concept for dealing with repeated request types. Examples include a password reset; a request for more printer toner or a request for some information. The simplicity, frequency and low-risk nature of such requests makes them easy to delegate to the Request Fulfilment process. This helps to reduce the work-load on the Incident management processes leaving them to concentrate on more critical or complex work. The process needed to fulfil a request depends upon what is being requested, however in many cases Service Requests are initially logged and prioritised through the Incident Management processes before being passed to Request Fulfilment. A request is always traceable. A simple request for information needs to be checked to determine whether the requestor is allowed to have that information. In common with all the other processes it’s important to try to automate Request Fulfilment. If this is not feasible for all cases, then create simple models for the cases that cannot be automated. A request to download an application from your internal website or server should be easy to automate; a request to change the way the business runs is not so easy to automate!

?

S5Ap14

Activity

Here’s a short exercise for you to try. In the last five minutes the following requests were received by the London Service Desk where our fast food head office is based. Which if any are Service Requests? Which might need to be routed through Change Management and which might be out of scope of IT Service management? Feedback ’A’ is a simple Service Request. ’B’ should go to Change management as there may be impacts on other services and applications. This might take two minutes or two years! ’C’ is a simple Service Request, which may eventually be passed to Access Management.



134

5A


ITIL Foundation

’D’ is simple Service Request and can be automated. ’E’ should be routed to Change Management. The Service Desk Manager and staff as well as Personnel and Unions may have a view on this. Finally ‘F’ needs to go to Change management; IT Operations Management (Operations Control and Facilities). Information Security Management may also be involved.

S5Ap15

Access Management

Our fifth and final Service Operation process is Access Management. Access Management is the ’process of granting authorised users the right to use a service, while preventing access to non-authorised users‘. It has also been referred to as rights management or identity management in different organizations. When we looked at Service Design, we mentioned that Information Security Management is responsible for the Information Security Policy. Access Management adds value by ensuring the policy is followed. For example, Access Management may control access to services that use confidential data. This helps to achieve compliance with laws relating to Data Protection. Access Management focuses on the data availability too. Access Management can also trace who used the service and how they used it. This provides a useful trail if there has been some misuse of the service. Let’s have a quick look at some of the process they follow: When a user requests access they may do so via a Service Request. Access Management completes a Verification check to confirm that the user is who they say they are and that their request is allowable. They may perform identity checks such as asking for some piece of information that is known only to Access Management and the requestor. Some checks may be automated such as fingerprints, retinal images, voice recognition, DNA and so on. Access Management may then provide rights, monitor use and remove or restrict access rights as appropriate. At a day-to-day level they may be involved in re-setting passwords.

?

S5Ap16

Activity

Which of the following is MOST likely to be a role for Access Management? Feedback A Data Controller is a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed. Should be a Senior, Responsible Owner and more accountable than the Access Manager.



135

5A


ITIL Foundation

The Information Security Policy is a deliverable which should be jointly produced by the business, by Information Security and by other major stakeholders.

S5Ap17

Service Operation - Functions

Having completed our look at the Service Operation processes we’ll now go on to look at the four ‘functions’ in Service Operation. These are Service Desk, Application Management, IT Operations Management and Technical Management. We also take a look at some of the more important roles too. In ITIL, a function refers to ‘A person, group or team and the tools they use to carry out one or more processes or activities’. In large organizations a function may be performed by several departments or may grouped into one team. This is often the case with the Service Desk. In smaller organizations, one person or group can perform many functions - so for example, a Technical Management Department could also incorporate the Service Desk function. A role may include different responsibilities. In our fast food restaurant the order taker may also take payments and do some of the fast food preparation. Of course, how you decide to structure your IT Department depends on your business. You may decide to separate the people who look after the visible technology such as mainframes, networks and servers from the people who look after the invisible technology such as software. You could split them into separate departments and call them Technical Management and Application Management each with their own specialists. Where, Application Management will concentrate of Application Design and Programming. All the Service Design processes - and the people who perform those processes- may have responsibilities within each function. So for example, Capacity and Availability management need to be assured that the network and storage designs can meet the performance levels agreed. Whereas Service Level Management will be interested in ease of application support. Information Security management will works closely with Facilities management, as there may potential weakness in Data Centre physical security.

S5Ap18

Service Operation - Functions

Let’s take a few moments to expand a little on the Application Management, Technical Management and IT Operations Management functions. IT Operations Management consists of Operations Control and Facilities Management. •

IT Operations Control concentrates on Job Scheduling, the Backup and Restoration of data and applications, Printing and other related areas.



136

5A •


ITIL Foundation

Facilities Management on the other hand, concentrates on maintaining the physical IT environment. This includes Power management, Environmental conditioning and alert systems, Physical access control, Shipping and receiving.

Technical Management is able to ensure that the organization has access to the right type and level of people to manage technology and, therefore, to meet business objectives. Whereas Application Management concentrates on the tasks needed to identify and specify application requirements; to design, build, test, deploy, operate and optimise the application. Application management differs from Application development as Application management covers the entire on-going lifecycle of an application including the requirements, design, build, deploy, operate and optimize, whereas application development is mainly concerned with the one-time activities for the requirements design and build of applications. In all these functions it is absolutely essential to decide and agree who is accountable for the different areas. Additionally many people from IT and the business need to consulted, informed and take responsibility for completing the tasks. There are many different ways to help you do this. The Skills Framework for the Information Age or SFIA approach is an excellent starting point. By combining the SFIA and the ITIL framework guidance with and other techniques such as Responsible, Accountable, Consulted, Informed (the RACI model approach, ) matrices you will be able to clarify and define the roles and competencies needed.

S5Ap19

Service Desk

The last function we’ll look at is the Service Desk. We’ll consider what a Service Desk does as well as looking at some of the staffing requirements. ITIL suggest that a Service Desk ’is a functional unit made up of a dedicated number of staff who are responsible for dealing with a variety of service events‘. The primary aim of the Service Desk is to restore the ‘normal service’ to the users as quickly as possible. This might mean fixing a technical fault, fulfilling a request or answering a query. The Service Desk may also identify potential improvements to IT services and the business. The Service Desk owns the incident or service request throughout their lifecycle. Therefore they own the call from when it’s opened until it is closed. They monitor incident progress communicating status to the caller. They are the single point of contact between the user and the IT service provider. The type, size and location of a Service Desk depends on many factors such as the type of business, the numbers and location of the users and how complex the calls are. An organization may have any combination of different Service Desk structures. A large organization may have ’local desks‘ that deal with local issues and simple queries; however, they will escalate certain types of Incidents to a ’central desk‘ or desks. As the organization evolves approaches such as a ‘virtual‘ service desk or a ’follow the sun‘ approach may be adopted.



137

5A


S5Ap20

®

ITIL Foundation

Service Desk Staff

As the Service Desk is the Single Point of Contact between IT and the user, the staff working on the Service Desk need some essential knowledge including; •

a good understanding of what their organization does and how it is structured

•

a level of technical understanding with specific reference to the business applications and technologies they must support

In addition they need to reach a well-defined skill level. So for example, for a ‘call-logging’ service, the staff need very basic technical skills as there may be a high call handling rate but low resolution rate. The skills level needed may depend on service level targets, the complexity of the systems supported and ‘what the business is prepared to pay’. No matter what type of Service Desk structure is adopted all staff need to be able to understand and communicate. This might involve written or verbal questioning and reporting such as; •

Determining and recording the facts from the user regarding the incident

•

Reporting call progress

•

Informing users of changes, new procedures or service outage

•

And training on new services or applications

?

S5Ap21

Activity

Consider the following ‘work activities’ In which function are the activities most likely to be situated?

Feedback the correct option is now being shown.

S5Ap22

Summary

This concludes the session entitled ‘Overview of Service Operation.’ In this overview session, we have: •

Identified the main objectives of Service Operation.

•

Outlined the Value to the business which Service Operation can bring

•

Described the main Processes and Functions included in the ITIL guidance

•

And finally we looked at some of the important skills required by those working in Service Operation roles

S5AQ

?

Topic Quiz




138

5B S5Bp1

Incident Management ®

ITIL Foundation

Session objectives

In this session we will be examining Incident Management, which is described in Chapter 4.2 of the Service Operation book of the IT Infrastructure Library. When you have completed this session you will be able to: •

Define the term Incident Management according to ITIL Best Practice

•

Understand the difference between Incident Management and Problem Management

•

Identify the key stages in an Incident’s lifecycle

•

Assess the priority of incidents

•

And be aware of the key metrics in assessing the Incident Management process

S5Bp2

Process - purpose

ITIL defines an incident as ‘An unplanned interruption to an IT service or reduction in the quality of an IT service or a failure of a CI that has not yet impacted an IT service'. Historically, incidents were handled by a fragmented set of processes where users faced with a problem would contact IT staff direct and any resolutions would not be documented. Alternatively, system monitoring tools may have alerted technical specialists who would rectify the problem, but again with no central recording or control. This approach led to poor use of expensive resources, namely the IT experts, and a failure to learn lessons from previous incidents. ITIL Best Practice processes aim to resolve both of these issues. The main goal of Incident Management is ‘to restore normal service operation as quickly as possible, with a minimum of disruption to the business, ensuring the best possible levels of service quality and availability are maintained'. This has to be balanced against the efficient use of resources and the prioritisation of different incidents that can occur simultaneously. It is important to distinguish between Incident Management and Problem Management, which is the subject of a later session. Incident Management is aimed at a 'quick fix' or a workaround, rather than a longer term structural resolution to any fault. The priority for Incident Management is recovery of service as quickly and painlessly as possible, within the agreed service targets. Problem Management activities are about identifying the underlying cause of incidents, and finding ways of identifying and removing these errors in the infrastructure . This can lead to some conflict between the two disciplines when Incident Management staff are driven to get a system back up and running quickly.



139

5B


ITIL Foundation

Their colleagues in Problem Management, on the other hand, would like to have the system down for longer, so that they can conduct analyses and identify strategies for designing out any problems that may exist. Their colleagues in Problem Management, on the other hand, would like to have the system down for longer, so that they can conduct analyses and identify strategies for designing out any problems that may exist.

?

S5Bp3

Activity

What do you think is meant by ‘normal service operation’ in this context? Feedback Normal Service operation is defined by ITIL as a service that is operating within SLA limits.

S5Bp4

Process - benefits

An effective Incident Management process can create value to the organization as a whole. The value offered could include: •

The ability to reduce unplanned labour and costs for both the business and IT support staff caused by incidents

•

The ability to detect and resolve incidents which results in lower downtime to the business, which in turn means higher availability of the service. This means that the business is able to exploit the functionality of the service as designed

•

The ability to align IT activity to real-time business priorities. This is because incident management includes the capability to identify business priorities and dynamically allocate resources as necessary

•

It also provides the ability to identify potential improvements to services. This happens as a result of understanding what constitutes an incident and also from being in contact with the activities of business operational staff

•

The service desk can, during its handling of incidents, identify additional service or training requirements found in IT or the business

S5Bp5

Process - scope

We will see in a later session how the Service Desk plays a key role in the Incident Management process, recording incidents, monitoring progress, and retaining ownership on behalf of the user as long as the incident is still ‘open’. It is considered best practice to record all enquiries as incidents because they are often evidence of poor quality training and/or inadequate documentation. It may be that following the initial logging, a distinction is made between simple queries and an incident that relates to a failure or degradation of a system.



140

5B


ITIL Foundation

A request for a new product or service is usually regarded as a Request for Change rather than an Incident. However, because the processes are essentially similar, many organizations include Requests for Change within the scope of Incident Management. Within Incident Management, these will be referred to as Service Requests and may be passed to the Request Fulfilment process for handling. Automatically registered events, such as the failure of a disk drive or a network connection, are often regarded as part of normal operations. They are still included in the definition of incidents though, albeit that the service to end-users may never be affected.

S5Bp6

Incident Lifecycle

It is very important to understand the process that an incident goes through from its initial detection right through to its point of closure. The first step is the identification of the incident. Automated monitoring tools should exist to identify incidents before they are reported to the Service Desk. Ideally incidents should be identified before they have an impact on users. A check is carried out to assess whether this is actually a Service Request. Remember, Service Requests are not incidents, but it is possible that a Service request has been incorrectly submitted, for example, a user selects Incident instead of Service Request on a web-based form. It is vital that every incident is logged with a unique ID reference, even if we know that the problem has already been reported and a fix is being produced. Apart from the basic details about the incident, the log will normally include details of how the incident was reported and the Services and Configuration Items that are affected. Incidents should be categorised into different types for use in subsequent analysis. ITIL suggests organisations use multi-level categorisation. Example categorisations might be Hardware such as a switch, CISCO or Software such as Microsoft XP or Visio etc. Categorisation of a Service Request could be Service Request or User ID or Setup, but these will undoubtedly differ from one organization to another.

At this point the incident reaches the Incident Prioritisation process. We will be returning to the subject of priority a little later in this session. If the incident is categorised as a major incident, then it may be passed into a major incident procedure. ITIL suggests the creation of a Major Incident team. Under the leadership of the Incident Manager, the team are tasked with utilising the appropriate resources, to resolve major incidents as swiftly as possible.

S5Bp7

Incident Lifecycle continued

Initial diagnosis may result in a direct resolution of the incident at the Service Desk, or the incident being routed to the identified second-line support. This shuttling backwards and forwards of an incident between different support groups is one of the major issues for Incident Management. If this total process is taking too long then escalation procedures may be invoked. Escalation is covered in more detail in the Service Desk session.



141

Incident Management

5B

®

ITIL Foundation

Investigation and diagnosis could involve several support groups and it’s important to maintain accurate documentation in the incident record, and to organise resolution activities in parallel, in order to find a resolution as quickly as possible. Resolution and recovery itself may entail the business in further actions, such as re-entering or verifying data. For example, if a disk has crashed, the problem may have been resolved by replacing the disk drive, based on an official Request for Change, but the service has not been recovered until the data is brought up-to-date from the backup or archive copies. The Incident Record must be updated with any relevant information so that a full history is maintained. The resolving group should pass the incident back to the Service Desk for closure. Incident Closure should involve some confirmation by the originating user and, where appropriate a recategorisation activity will take place. It is quite likely, for example that an initial report of a printer problem was classified as a hardware fault but subsequent analysis determined that the fault was actually with the software. It is important that such corrections are made to the Incident category at Incident closure, so that an accurate record is maintained. It is usual to carry out a user satisfaction survey, either via telephone or e-mail on an agreed percentage of incidents, providing valuable user metrics for analysis of Service Desk performance. Another question at this point is, whether this is an on-going or recurring problem. Discussions should be held with Problem Management as to whether any preventative action is necessary, and if so, a Problem Record should be raised to initiate preventive action. And finally, formal closure of the Incident Record, with of course agreement with the user!

S5Bp8


Whilst all this is going on there are the issues of ownership, monitoring, tracking and communication to be maintained. Additionally, there will be constant updating of the status of the incident as it moves through the various points of its lifecycle. All of these are proactive activities carried out by the Incident Management staff - which is usually the Service Desk, acting on the users behalf. Activities include generating reports, keeping users informed and managing escalations. ITIL standard practice guidance says that all these activities remain with the Service Desk and the use of tools to help with automatic status tracking is very important in the Incident lifecycle. Finally, remember that everything should be logged as an incident - even if it is a Service Request, that is a request for a standard operational item, such as a password reset for example.

S5Bp9

Standard Incident Model

Let’s take a step back here and look at how an organization might address frequently recurring incidents.



142

Incident Management

5B

®

ITIL Foundation

Many incidents are not new - they involve dealing with something that has happened before and may well happen again. For this reason many organizations will find it useful to pre-define Standard Incident Models, applying them to appropriate incidents when they occur. An Incident Model defines the steps that should be taken to handle an incident via a clearly defined process. This ensures that incidents are handled routinely and in pre-determined timescales. An Incident Model should include the following: •

The steps that should be taken to handle the incident

•

The chronological order these steps should be taken in, with any dependences or co-processing defined

•

Responsibilities or 'who should do what'

•

Precautions to be taken before resolving the incident such as backing up data, configuration files, or steps to comply with health and safety related guidelines

•

Timescales and thresholds for completion of the actions

•

Escalation procedures or 'who should be contacted and when'

•

And any necessary evidence-preservation activities. This is particularly relevant for security and capacity related incidents

The completed Models should be input to any incident-handling support tools in use.

S5Bp10


In understanding the full lifecycle of an incident it is important to know what further records and processes may be generated as a result of an incident. When an infrastructure fault is first reported it is recorded as an incident, either by the Service Desk or direct to the incident management process by automated support tools. Incidents can spawn problems if they are recurring incidents, or if the Service Desk or second or third-line support cannot ascertain the underlying cause. Some problems will justify the generation of a ‘known error’, this being an admission or statement that we are aware of the problem and we have a resolution to it. In other cases, it may well be that a workaround is an adequate solution, at both the incident and problem levels. A good example of this might be ahead of a major infrastructure change, where making significant changes now would not be worthwhile. If a ‘known error’ is generated then in most cases this will lead to a Request for Change in order for the underlying fault to be corrected unless, as we have said, there are good reasons why we should just live with the problem for the time being, because the cost of a short-term fix is not justified. Once a Request for Change has been through the Change Management process, as defined by ITIL, then this will lead to the release of a structural solution to the problem. This will be a permanent fix to the underlying fault, not just a workaround.



143

Incident Management

5B

®

ITIL Foundation

Whilst all this is going on, the Configuration Management System should be being updated with information about the incident, any problems and their links to incidents, about any known errors and their links to problems, and about Requests for Change and their links to known errors. So an integrated Configuration Management System not only contains configuration item information but also related support records, such as incidents, problems, known errors, Requests for Change, and release records. The absence of a Configuration Management System will make it very difficult to harmonise separate incident-recording, problem-recording, and change-recording systems. We looked at the Configuration Management process in detail in session 4.

?

S5Bp11

Activity

Would you say that this statement is true or false?

S5Bp12

Incident Priorities

Assessing the priority of an incident is a very important process that needs to be carried out early in the incident’s lifecycle, since it determines what effort is going to be put into its resolution. Priority is determined mainly by the impact and the urgency of the incident or enquiry. Another factor affecting priority may be the existence of a specific statement in a Service Level Agreement that is threatened by the incident. Impact, in this definition, is the measure of the effect of the incident on the business. This could be measured in terms of numbers of users affected or financial loss, for example, so it is important to work very closely with the business in order to understand the factors that are considered high or low impact. Urgency concerns the timescale in which the incident needs to be resolved, for example, a fault with a nd payroll system that occurs on the 2 of the month may well be considered less urgent than the same fault th occurring on the 20 . These two factors together dominate the ITIL model for determining priority. So a high urgency does not always mean a high priority, if the impact is considered to be relatively low. For something to be high priority both the impact and urgency must be high. Note that it is usual to assign a prioritisation code to incidents, which will determine how the incident is handled by staff and support tools.

S5Bp13

Incident priorities continued

As we have already mentioned, Service Level Agreements can also influence priority. Further examples to work with are: An Incident, let’s say Incident As we have already mentioned, Service Level Agreements can also influence priority.



144

5B


ITIL Foundation

Further examples to work with are: An Incident, let’s say Incident ‘A’ occurs, affecting a large number of users updating customer payment records for a ledger system that is due for its monthly report in a matter of hours. On the other hand Incident 'B' occurs on a different service and this is the second incident to have occurred so far during the month. This incident stops the intranet capability which is used to pass low communications between departments, but is normally available to all staff. In both cases, the Service Level Agreement for the service states that response times to these calls should be within 2 to 4 hours. In these circumstances, all other things being equal, it would be reasonable to give Incident 'A' a higher priority. Where there are a number of medium-priority incidents to resolve then clearly the ones that have suitable resources immediately available will be tackled first. Note that when a major incident occurs - in other words one with a high impact, urgency and SLA threat Problem Management staff must be informed so that they can provide extra support to the Service Desk team, and may be able to provide those involved with the Major Incident activities with some information about workarounds from existing problem records. ‘A’ occurs, affecting a large number of users updating customer payment records for a ledger system that is due for its monthly report in a matter of hours. On the other hand Incident 'B' occurs on a different service and this is the second incident to have occurred so far during the month. This incident stops the intranet capability which is used to pass low communications between departments, but is normally available to all staff. In both cases, the Service Level Agreement for the service states that response times to these calls should be within 2 to 4 hours. In these circumstances, all other things being equal, it would be reasonable to give Incident 'A' a higher priority. Where there are a number of medium-priority incidents to resolve then clearly the ones that have suitable resources immediately available will be tackled first. Note that when a major incident occurs - in other words one with a high impact, urgency and SLA threat Problem Management staff must be informed so that they can provide extra support to the Service Desk team, and may be able to provide those involved with the Major Incident activities with some information about workarounds from existing problem records.

?

S5Bp14

Activity

Here’s a quick question. Feedback Incident Management is aimed at recovery of the service as quickly and painlessly as possible, whereas Problem Management is more about identifying the underlying causes of problems and finding out ways of engineering out the problems in the longer term.



145

5B S5Bp15


ITIL Foundation

Process Metrics

ITIL defines some key metrics in order to assess the performance of Incident Management processes. These measures include: • The total number of incidents • The size of the incident backlog • The number and percentage of major incidents • The percentage of incidents handled within agreed response time outlined in Service Level Agreements, Operational Level Agreements or Underpinning Contracts • The average cost of incidents • The percentage of incidents closed by the Service Desk without reference to other levels of support • Number and percentage of incidents processed by Service Desk staff ITIL goes on to outline the challenges, critical success factors and potential risks facing Incident Management. We will take a few moments to summarise them here. Challenges include: • The ability to detect incidents as early as possible • Convincing all staff that all incidents must be logged • Making information available about known errors to ensure staff learn from previous incidents • Configuration Management System integration, to assist with the identification of relationships between CIs • Integration into the Service Level Management processes in order to correctly assess the impact and priority of incidents, and • Defining escalation procedures Incident Management’s Critical Success Factors include: • • • •

Resolve Incidents as quickly as possible minimizing impacts to the business. Maintain Quality of IT services. Maintain user satisfaction with IT services. Increase visibility and communication of incidents to business and IT Support Staff and

Ensure that standardized methods and procedures are used for efficient and prompt response, analysis, documentation, on-going management and reporting of incidents to maintain business confidence in IT Capabilities. Finally the risks facing Incident Management include: • Being inundated with incidents that cannot be handled in an appropriate timescale due to a lack of, or inappropriate training.



146

5B


ITIL Foundation

• Incident backlog due to inadequate support tools • Poor information availability due to lack of integration or inadequate support tools

• Mismatch of objectives because of poorly-aligned or non-existent OLAs or UCs

S5Bp16

Summary

In this session we have been examining Chapter 4.2 of the Service Operation book, namely Incident Management. We have seen how Incident Management is defined, the scope of Incident Management and the differences between Incident Management and Problem Management, which is the subject of a later session. We have followed the main stages through which an incident passes during its lifecycle and looked at the records that must be kept and the need for an integrated Configuration Management System. We have also examined the different factors that must be considered in determining the priority of different incidents, which may be competing for limited resources.



147

Other Processes

5C

®

ITIL Foundation

S5Cp1

Session objectives

This session introduces three other processes involved in the Service Operation publication, namely: • • •

Event Management Request Fulfilment Access Management

When you have completed this session you will be able to state the objectives, basic concepts and roles relevant to each process. You will also recognise the difference between an event and an alert.

S5Cp2

Event Management - purpose

Let’s start by making it clear what we mean by an ‘event’. An event can be defined as 'any change of state that has significance for the management of a configuration item (CI) or IT service. Events are typically recognized through notifications created by an IT service, CI or monitoring tool'. So, what then is the purpose of event management? Well, the purpose of the process is to manage events throughout their lifecycle. Event Management provides the ability to detect events, make sense of them, and determine the appropriate control action to be provided. Event management is therefore the basis for operational monitoring and control. If events are programmed to communicate operational information as well as warnings and exceptions, they can be used as a basis for automating many routine operations management activities, for example executing scripts on remote devices, or submitting jobs for processing, or even dynamically balancing the demand for a service across multiple devices to enhance performance. Whilst we are considering some definitions, let’s consider what we mean by an alert. An alert is a warning that a threshold has been reached, something has changed or a failure has occurred. An important point to remember here is that events and exception events generate alerts, Informational events do not!

S5Cp3

Event Management - objectives

The Objectives of an Event Management process are to: • Detect all changes of state that have significance for the management of a CI or IT service • Determine the appropriate control action for events and ensure these are communicated to the appropriate functions • Provide the trigger, or entry point, for the execution of many service operation processes and operations management activities



148

Other Processes

5C

®

ITIL Foundation

Event Management should also provide the means to compare actual operating performance and behaviour against design standards and SLAs. • And provide a basis for service assurance and reporting and service improvement

S5Cp4

Event Management - scope

The scope of Event Management includes: •

Configuration items - a network switch, a router, a firewall for example

•

Environmental conditions - such as fire and smoke detection

•

Software licence monitoring

•

Security - including intrusion detection

•

And Monitoring activities, for example network traffic, application transactions and so on

S5Cp5

Event Management - scope

Event Management can be applied to any aspect of Service Management that needs to be controlled and which can be automated. Typical examples are: • • • • • • • •

Configuration Items Environmental conditions Software licence monitoring Security Normal activity Detection of incidents Capacity thresholds exceeded, and Availability issues

Take a look at this flowchart describing the Event Management process. When we consider the significance of an event, that is to say, the state of a service or a device, we can assign to it one of three states - Informational, Warning or Exception. Informational refers to an event that does not require an action and does not represent an exception. They are typically stored in the system or service log files and kept for a predetermined period. Warning refers to an event that has reached a threshold, and Exception refers to one that is currently operating abnormally. Some Warning events require triggers which enable specific tasks to be carried out, for example, the generation of an Incident Record. Others might set up an alert for human intervention or might simply initiate an auto-response if the event is understood and the required response is defined, for example, reboot a device. So, we define an Alert as a warning that a threshold has been reached, something has changed or a failure has occurred.



149

Other Processes

5C

®

ITIL Foundation

? Activity

S5Cp6 Is this statement true or false?

Feedback The statement is false. For Event Management to be applied, the aspect of Service Management must also be capable of being automated, for example, detection of incidents or software licence monitoring.

S5Cp7

Request Fulfilment

The second process in this session is Request Fulfilment. Request Fulfilment is the management of user and customer requests. Request Fulfilment can be either ‘standalone’ or form part of an Incident Management process. So what does it actually cover? Well, requests typically fall into one of four categories: • • • •

Standard changes Questions, difficulties and queries Standard operational requests, or Complaints, comments and praise

Standard changes are pre-approved or pre-authorised changes that are low-risk, relatively common and follow an accepted or established work instruction. For example: • • • •

A password reset Download of a licensed software program Updated access rights on promotion of the user (gaining new rights), or Adding a new user

S5Cp8

Request Fulfilment continued

Questions, difficulties and queries are users and customers’ requests for information on the availability of services and the procedure for obtaining them. It also relates to questions, difficulties and queries on using a service. These requests normally arise through either a lack of training or a lack of access to a user manual or other guidance. Standard operational requests fall into one of two categories: Requests for disposable items or Requests for items that are not specifically IT. Disposable items will typically include such things as stationery, toner cartridges and replacement keyboards or mice. Items that are not specifically IT often relate to actual physical facilities, office locations and non-IT items. Finally, complaints, comments and praise are self-explanatory. Capturing these via Request Fulfilment is important, as the information may well be of use to the business in the future. Items that are not specifically IT often relate to actual physical facilities, office locations and non-IT items. Finally, complaints, comments and praise are self-explanatory. Capturing these via Request Fulfilment is important, as the information may well be of use to the business in the future.



150

Other Processes

5C

®

ITIL Foundation

? Activity

S5Cp9 Select each of the following that would be dealt with by the Request Fulfilment process?

Feedback The Request Fulfilment process deals with user and customer requests. The requests from accounts and from the supplier were not requests from users and so would be dealt with elsewhere.

S5Cp10

Access Management - purpose

We will now examine the third process in this session, namely Access Management. The purpose of Access Management is to provide the right for users to be able to use a service or group of services. Access Management is therefore the execution of policies and actions defined in Information security management. Access Management goes beyond the simple provision of access to systems by being involved in the monitoring of access to systems. Access management is the process of granting authorized users the right to use a service, while preventing access to non-authorized users. It has also been referred to as rights management or identity management in different organizations. In this way, it is possible for access management to add value to the business by: • Controlling access to services, ensuring that the organization is able to maintain, more effectively, the confidentiality of its information • Ensuring that employees have the right level of access to execute their jobs effectively • Ensuring there is less likelihood of errors being made in data entry • Providing an ability to audit the use of services and to trace the abuse of services • Providing an ability to revoke access rights when needed, and Maintaining information that may be needed for regulatory compliance

S5Cp11

Access Management - Basic Concepts

There are five main areas of Access Management, namely; • • • • •

Rights Access Identity Directory Services, and Service or Service Groups

Rights are the entitlements or permissions granted to the user or role. For example a right to modify particular data or to authorise a change. Access is the users entitlement to the correct level of access.



151

5C

Other Processes ®

ITIL Foundation

Identity relates to the ability to identify a user. Directory Services is an application that manages information about the IT infrastructure available on the network and corresponding user access rights. For example, privileges or actual settings of access Read, Write, Execute, and so on. And finally, Services or Service Groups relates to access to services or service groups as a ‘set’.

?

S5Cp12

Activity

In which of the activities shown does Access Management NOT get involved? Feedback Access Management does not get involved in controlling the interfaces between computer networks. Access Management provides the right for users to be able to use a service or group of services.

S5Cp13

Summary

In this session we introduced the three additional processes involved in Service Operation, namely: • • •

Event Management Request Fulfilment Access Management

For each process we looked at its objectives, basic concepts and the role it plays. Event Management involves detecting events, making sense of them and deciding on the appropriate control action to be taken. Request Fulfilment is the management of user and customer requests. And Access Management is providing the right for users to be able to use a service or group of services.



152

Problem Management

5D

®

ITIL Foundation

S5Dp1

Session objectives

The subject of this session is Problem Management, which is covered in chapter 4.4 of the ITIL Service Operation publication. Once you have completed this session you will: •

Be able to define Problem Management according to ITIL best practice

•

Have seen and be able to identify Problem Management’s reactive and proactive activities

•

Recognise the standard set of activities for Problem Management

•

List the benefits gained from this process

S5Dp2

Process - purpose, scope, objectives

ITIL defines a problem as ‘the unknown cause of one or more incidents' and goes on to define the purpose of Problem Management, in the following way. ‘To minimise the adverse effect on the business of Incidents and Problems caused by errors in the infrastructure, and to proactively prevent the occurrence of Incidents, Problems and Errors.’ Broadly speaking, Problem Management exists to ensure that a process is in place that identifies once and for all the root causes of problems. It also helps minimise the effects as well as preventing potential problems occurring in the future, thereby attempting to minimise incidents and their causes. Problem Management processes are usually carried out by teams of technically focused specialists who work closely with Service Desk and Incident Management staff, and with other internal and external suppliers. The Scope of the process is: •

Diagnosing the root cause of incidents

•

Ensuring resolutions are implemented through controlled procedures

•

Maintaining information about problems, known errors, and resolutions

•

And interfaces with Knowledge management providing known error details and records

Problem management’s objectives are to prevent problems and resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented.

S5Dp3


As is common to other ITIL processes, Problem Management responds to incidents in a reactive way, but also has a proactive element. Proactive response adopts a forward-looking approach. Trying to prevent issues occurring by providing intelligent analysis of problem trends and statistics, they may even get involved in making decisions about purchasing, and IT provision. There is a close working relationship between proactive problem management activities and the CSI stage of the Service lifecycle.



153

Problem Management

5D

®

ITIL Foundation

As the term suggests, a proactive response is an on-going and methodical process. The intention is to minimise occurrences of incidents by identifying and resolving problems and known errors. We will define the difference between problems and known errors a little later in this session. The ‘reactive’ requirement of Problem Management is to resolve problems quickly, effectively and permanently. It should identify the underlying problems, which are causing related incidents, and find an immediate workaround. Any workaround should allow the smooth continuation of business. When a resolution is implemented via the Change Management process, it should be a permanent solution that will resolve the problem and the related incidents. Once a problem has been identified, and a satisfactory resolution found to that problem, then the change will normally be implemented through the Change Management process. Whether Problem Management acts reactively or proactively, it is important that resources to deal with them are prioritised on a ‘business needs’ basis. This prioritisation is sometimes referred to as ‘prioritising in pain factor order’. The pain factor relates to the seriousness of the impact on the business, which could mean the number of people affected by incidents or how the business processes are interrupted by the failure and the potential cost of such an impact. Remember Pareto analysis technique from earlier in the course? Pain value analysis assists Pareto analysis.

S5Dp4


The communication of management information between IT Service Management roles is very important. This information is used both internally, within the support teams, who may make up a virtual Problem Management team, and distributed to other IT Service Management roles, such as Service Level and Availability Management. For example, if IT users were encountering lots of problems caused by poor quality software delivered and supported by a third party supplier, then information gained from Problem Management would be very useful to the Contract Management team. They could use this to help the suppliers make improvements, or in evaluation or analysis of the software or supplied service. In some instances they could also revoke the contract.

?

S5Dp5

Activity

Which of these descriptions best describes the role of Problem Management? Feedback Problem Management processes need to have both reactive and proactive elements, so that long term and medium term benefits are balanced.

S5Dp6


So how do we define the responsibilities of staff working in Problem Management? These responsibilities can be broken down into a number of focused areas.



154

5D

Problem Management ®

ITIL Foundation

These are: • • • •

Problem management Proactive prevention of problems Providing management information from problem data Conducting major problem reviews

Problem Management focuses on identifying Known Errors. It does this by identifying the root cause of the problem and providing a temporary workaround where possible. Problem Management has become a common process in both the applications development, enhancement and maintenance environment as well as the live environment; Often, a service and its configuration items are introduced to the live environment with some Known Errors. Development may refer to these as bugs or defects. It is important that these are recorded in the ‘Known Error Database’, so that when related incidents are reported in the live environment they can easily be identified.

S5Dp7

Proactive activities

Proactive prevention of problems and providing management information from problem data includes techniques such as trend analysis, targeting support action, and providing support to the organization. This Configuration Item information can prove useful when attempting to identify the underlying cause of incidents. The provision of management information from problem data to Availability Management for example, can provide vital information on expected levels of availability, and as a consequence, influence statements made about availability in Service Level Agreements. Ultimately, by redirecting the efforts of an organization from reacting to large numbers of incidents to preventing future incidents, you provide a better overall service to your customers and make better use of the IT support organization resources. Finally, conducting Major Problem Reviews. These reviews take place after a problem causing a major incident or multiple-related incidents have been successfully resolved, or when the severity of a problem has been deemed to be major to the IT service provider in identifying the underlying root cause along with high costs involved in the identifying of the root cause. It is the responsibility of the Problem Management process to review, identify and prevent the problem recurring in the future. Additionally, information from these reviews can identify weaknesses in Problem Management and Incident Management processes. These review procedures form part of the ‘Continual Service Improvement Programme’, a key stage in the ITIL Service lifecycle.

S5Dp8

Process definition

So let’s look at some Problem Management definitions in more detail. Firstly, the definition of a problem, which is ‘the unknown cause of one or more incidents’. New Problem identification occurs when we are unable to find a match amongst the definitions of existing problems, or existing Known Error records. A Problem Record is then raised. One of the most effective



155

Problem Management

5D

®

ITIL Foundation

Problem Management techniques is to match against a number of multiple-related incidents, and realising that they have a common underlying cause. This activity is known as Incident matching. These multiple-related incidents are of particular concern to Service Managers, as they can threaten reliability clauses within Service Level Agreements or Contracts. For example, an SLA might specify that in any rolling month there will be no more than two breaks in service provision, and the duration of these breaks will be no greater than two minutes. So any train of events causing us to approach these parameters is a major concern. Hence Problem Management helps by providing a very important role in the ITIL Service Management structure, by providing early identification of problems, and communicating this information to relevant management areas.

?

S5Dp9

Activity

Here’s a quick question. When does a Problem become a Known Error? Feedback A Problem becomes a Known Error only when a documented root cause and a workaround have been identified.

S5Dp10

Problem Management processes

The Problem Management process set consists of a standard set of control activities. These are: • • • • • • • • • •

Detection Logging Categorisation Prioritisation Investigation and Diagnosis Creating Workarounds Creating Known Errors Resolution Closure Major Problem Review

Each reported problem may pass through this process set, so let’s take a few moments to define each of these in more detail. Detection Problems can be generated from many sources. An incident might be completely new and have no matching characteristics with records in either existing Problem or Known Error databases. It may also be a recurring incident, which has already been identified, or it might come about as a result of Problem Management’s proactive work, where a trend has been identified and a problem identified as a result. Logging Once a problem has been identified, a record is created with a unique identifier, and a link is generated to any associated records, such as the incidents that caused it, and also to any Known Errors to which it might relate.



156

5D


ITIL Foundation

It’s likely that the problem will pass through the Change process, and at this point it will be linked to Requests for Change. Throughout this process records will also be linked to related configuration items, within the configuration management database.

S5Dp11

Problem Management processes continued

Categorisation Problem Categorisation is often an extension of the Incident categorisation, and is used mainly to determine an appropriate allocation of resources. For example, a problem might be identified in the Local Area Network. This leads to the creation of a team of problem-solvers mainly drawn from network specialists. Prioritisation When a Problem is identified, the amount of effort required to detect and recover the failing Configuration Item has to be determined. It is also important to be aware of the impact of the Problem on existing service levels. This process is known as Prioritisation. Problem prioritisation is also used to determine the sequence in which problems are addressed. If we are experiencing a large number of incidents related to several different areas of the business then priority must be assigned appropriately. Every incident, problem or change will have both an impact on the business services and urgency. Impact describes how vulnerable the business might be, for example, life threatening or merely a small inconvenience. Urgency illustrates the time that is available to avert, or at least reduce, this impact. In addition to using the impact and urgency considerations during the problem prioritisation stage the severity of the problem record also needs to be considered. Severity in the context of problem management refers to how serious the problem is from a service or customer perspective as well as an infrastructure perspective.

S5Dp12


Investigation and Diagnosis These two stages are defined separately because they form an iterative process. Initial investigation results in initial diagnosis, which leads to further investigation and so on. Ultimately the outcome from this process should be a Known Error. These two stages are complex, and require a good technical knowledge, supported by problem-solving and diagnostic skills. ITIL recommends, amongst others, two techniques to help this process. These are Kepner and Tregoe analysis, and Ishikawa fishbone diagrams. Both are important mechanisms, which allow those working in Problem Management to use a structured approach to problem diagnosis.

S5Dp13


Applying Workarounds In some cases it may be possible to find a workaround to the incidents caused by the problem - a temporary way of overcoming the difficulties. In cases where a workaround is found, it is vital that the



157

5D


ITIL Foundation

problem record remains open and that details of the workaround are always documented within the problem record. It is worth noting that in some cases there may be multiple workarounds associated with a problem. As problem investigation and diagnosis activities carry on, there may be a series of improvements that do not resolve the problem, but lead to a progressive improvement in the quality of the workarounds available. These may impact on the prioritization of the problem as successive workaround solutions may reduce the impact of future related incidents, either by reducing their likelihood or improving the speed of their resolution.

S5Dp14


Raising a Known Error Record As soon as the diagnosis is complete a Known Error record must be raised and placed in the Known Error Database, so that if further incidents or problems arise, they can be identified and the service restored. Be careful though, in some cases it may be advantageous to raise a known error record even earlier in the overall process, even though the diagnosis may not be complete or a workaround found. This might be used for information purposes or to identify a root cause or workaround that appears to address the problem but hasn’t been fully confirmed. Therefore, it is inadvisable to set a concrete procedural point for exactly when a known error record must be raised. It should be done as soon as it becomes useful to do so! Problem Resolution If any change in functionality is required to resolve the problem, then an RFC must be raised and passed to Change Management. Problem Management is not responsible for implementing any resolutions - it is responsible for identifying the resolutions.

S5Dp15


Closure Problem closure is often carried out automatically when a resolution to a Known Error is implemented. However we should point out that an interim closure status could exist. For example, when a Known Error has been identified and a solution put in place, a status of ‘Closed pending Post Implementation Review’ could be assigned to it in either the Incident, Known Error or Problem records. ‘Closed pending PIR’ allows us to confirm the effectiveness of the solution prior to final closure. For incidents, this may involve nothing more than a telephone call to the user to ensure that they are now content. For more serious Problems or Known Errors, a formal review may be required. On resolution of every Major Problem, Problem Management should complete a Major Problem review. The appropriate people involved in the resolution should be called to the review to determine: •

Those things that were done correctly

•

Those things that were done wrong

•

What could be done better in the future



158

5D


ITIL Foundation

•

How to prevent recurrence

•

Whether there has been any third-party responsibility and whether follow-up actions are needed

Major problem reviews can aid with education and learning across an organization as well as feed into proactive problem management and CSI activities.

S5Dp16

Proactive activities

We discussed earlier in this lesson how Problem Management works reactively to identify problems, by checking knowledge bases for records of problems, Known Errors, changes, and so on. A proactive activity involves the analysis of past incidents, and the IT infrastructure as a whole. For example, analysis might identify that a pre-existing problem at one site, might reoccur at another site, which has a similar server, hardware and software configuration.

Proactive activities can be sourced from a Major Problem review meetings which we looked at on the previous page. Also involved is the broader analysis of the IT infrastructure itself. The examination of over-complex relationships, or single points of failure, can identify any vulnerable points that are a potential threat to a business. This analysis might indicate that a particular network route is more heavily used than expected, and as a consequence is a potential future risk. Often this work is carried out in conjunction with Availability Management, and involves careful analysis of paths through the component infrastructure that make up the various services. For example, a customer using on-line banking to read their balance may involve hundreds of different paths. Another element of proactive Problem Management involves working with third party suppliers and our own internal staff to ensure all procedures are adequate, for example testing procedures, release procedures and so on. Internal staff can be encouraged to take part in system reviews during development, ensuring a higher level of maintainability is designed into the system. And finally, providing access to ‘knowledge bases’. Service Desk staff will be able to link recently occurring incidents to Known Errors and Problems in these bases, resulting in a better understanding of the underlying problems and Known Errors in the organization.

?

S5Dp17

Activity

Would you say the following statement is true or false? Feedback If an incident exists in a Known Error knowledge base, the Service Desk staff would usually deal with it. Problem Management would usually be notified if the incident was unrecorded in either Known Error or Problem knowledge databases.



159

5D


ITIL Foundation

S5Dp18

Summary

In this session we have been examining Chapter 4.4 of the Service Operations book, Problem Management. We have examined in detail the standard set of Control activities, and several Problem Management definitions. We finished by walking through the Problem Management activities, and looked at Problem Managements proactive activities and some of the potential drawbacks associated with the process.



160

5E S5Ep1

Service Desk ®

ITIL Foundation

Session objectives

In this session we will be examining the IT Service Desk, which is described in Chapter 6.3 of the Service Operations book of the IT Infrastructure Library. When you have completed this session you will be able to: • List the main reasons why the establishment of a Service Desk can have major benefits for the organization, the end-user and the IT provider alike. • Describe the importance of the Service Desk as a single point of contact for IT users. • Identify three of the main approaches to structuring a Service Desk. • Define the skills associated with a Service Desk, and finally • Recognise some key Service Desk tools and metrics.

?

S5Ep2

Activity

Before we start, here’s a quick question for you. A well-structured and efficient Service Desk can provide benefit to any organization. Do you think this statement is true or false? Feedback A well-structured and efficient Service Desk can provide many benefits to an organization. We’ll identify some of these benefits as we progress through this session.

S5Ep3

Introduction

One of the most important considerations when delivering IT Services is to ensure the provision of proper support for the users, so that when an issue or a query comes up, they can contact someone who will provide a solution or an answer. Often, time is of the essence and users want either a rapid resolution or an appropriate workaround to the fault, enabling them to carry on with their work with a minimum of interruption. In order to support users in this way, ITIL offers guidance on day-to-day service operation and specifically includes valuable information on creating and maintaining a Service Desk function in its Service Operation publication. The Service Desk is meant to be the focal point for the reporting of incidents, Requests for Change, service requests or any queries that a user may have about a service. It also provides a channel for the IT provider to communicate information to users. The Incident Management process enables the recording, tracking, monitoring and resolution of events that are a threat to ‘normal service’. Problem Management addresses the underlying reasons for such incidents and seeks to implement permanent resolutions in order to prevent a recurrence. We have covered these processes and functions elsewhere in this course. For the rest of this session we will be examining the Service Desk function.



161

Service Desk

5E

®

ITIL Foundation

S5Ep4

Service Desk definition

When a customer or user has an issue, complaint or question, they want answers quickly. More importantly they want a result - the issue solved. Nothing is more frustrating than calling an organization and getting passed around until you find the right person to speak to, provided, of course, that they are not out to lunch or on holiday or that it's just after five o'clock. ITIL Best Practice demands a single point of contact for users in their communication with the IT service provider. Such a facility is known by various names in different organizations, some common ones being Help Desk, Call Centre or Customer Hotline. The name used by ITIL - and hence during this course - is ‘Service Desk’. Obviously, what ITIL is referring to in this context is an IT Service Desk - but the principle can, and often is, applied to many areas of a company’s business. So, in addition to an IT Service Desk there may be a Service Desk where customers for the company’s products can call to get support. Another Service Desk may exist so that employees can get answers to queries relating to company policies, personnel issues and so on. For the purpose of this course we will be making the assumption that the Service Desk refers to an Information Technology (or IT) Service Desk.

?

S5Ep5

Activity

Would you say this statement is true or false? Feedback In the next few pages we will be looking at the reasons why organizations establish Service Desks and we will see that there are major benefits for all parties - the business, the user and the IT provider alike.

S5Ep6

Why have a Service Desk?

The establishment and operation of an effective Service Desk is a relatively expensive proposition. So it is important to understand why such a facility might be needed and the benefits that it should provide. The users and managers of our IT services are customers in every sense of the word. Like all customers they would quickly become frustrated and unhappy if they were unable to find somebody who could help them when they had issues with the systems on which they depend. So customer satisfaction and retention can be listed as an important benefit. Another guiding principle of ITIL is that IT should maintain a focus on the support of business goals. IT does not exist to provide IT components or technology just for the sheer joy of playing with new equipment. It is there to help the organization achieve its business objectives. A well-staffed and efficient Service Desk is a critical element in proving to the business that IT is listening and responding to its needs.



162

Service Desk

5E S5Ep7

®

ITIL Foundation

Why have a Service Desk? - continued

An efficient Service Desk can help to reduce the overall cost of ownership of the IT department, and it can do this in a number of ways. An efficient Service Desk can make better use of skilled and expensive IT staff, resulting in reduced costs. Straightforward issues can be resolved immediately by the Service Desk, leaving skilled network technicians or database experts, for example, to concentrate only on the complex faults or concentrate on improving the quality of the infrastructure. It would usually be the case that users or customers are performing a valuable function for the organization. So, any time that they are unable to operate at full efficiency, as a result of a fault with the IT Services, will be both disruptive and costly. An effective Service Desk can significantly reduce the likelihood of such faults. This factor becomes even more crucial in an e-business context where the lack of service will directly impact on customers and certainly lead to loss of business.

S5Ep8

Benefits of a Service Desk

Another major benefit of a Service Desk is its contribution to the continual improvement of the services offered by IT. The Service Desk will keep records of types of enquiry, the issues that are raised, the particular services, or aspects of a service, that seem to cause most issues and so on. Identifying the most commonly occurring faults and feeding this information back quickly to the IT Service Management structure is a valuable element of the Service Desk function. In this way, the Service Desk is the thermometer by which we can monitor the health of the IT services that are being provided. Additionally, the Service Desk can also operate as a ‘shop window’, adding value to the business by making users aware of facilities that they may not know exist, or how to make better use, in a business sense, of the facilities that they are already using.

?

S5Ep9

Activity

ITIL best practice strongly advocates that the IT Service provider should do which of the following? Feedback ITIL dictates that IT should do both A and B, so the answer is C.

S5Ep10

Points of contact

There is often some confusion about the terms ‘user’ and ‘customer’. So far in this course we have used the words interchangeably and for many people they mean pretty much the same thing. ITIL, however, does draw a distinction between the two terms.



163

5E

Service Desk ®

ITIL Foundation

A User (or End-User) is taken to mean the person who actually uses the product or service under discussion - a machine operator, for example. A Customer is the person who negotiates for the provision of the product or service, what the specification should be, any changes that may be needed, and possibly the payment arrangements. It may well be that the User and the Customer are the same person, but in many cases, for operational systems, they will be different groups of people - Customers normally being managers, and Users being the operators. These definitions are relevant here because whilst the Service Desk is the main point of contact between the User and the IT service provider, the Service Level Management process is the main point of contact between the paying customer and the IT Service provider. In both cases the key point of reference is the IT Service itself – as defined in the Service Level Agreements - which will contain statements about hours of availability, time to resolve issues, response times, and so on.

The importance of this to the Service Desk is that they must be aware of what Service Level Agreements are in place and how these relate to the questions, complaints, service requests and issues that may be raised by users. It may well be, for example, that a user calls in complaining of a 2 second transaction response time, when in fact the Service Level Agreement specifies that 95% of responses should be within 4 seconds. Such an incident would be given a much lower priority than had the figures been reversed. So, the general point is that the Service Level Agreements provide the link between the Customer, User and Service Level Management and that the Service Desk has a responsibility to act on behalf of the User within the IT infrastructure.

S5Ep11

A single point of contact

As we have already seen, the idea of the Service Desk as a single point of contact is an important one in ITIL. Some organizations will take this principle to its ultimate conclusion and have a single Service Desk as the point of contact for everything to do with the ability of the business to continue to function properly. So staff within such an organization could call the Service Desk if the lift broke down, or a light bulb in their area failed, or they had a query on their pension arrangements. A disadvantage of this kind of Service Desk is that it requires a very high level of expertise at the first point of contact. In addition the likelihood of the request or issue being resolved at the Service Desk is also reduced. For our purposes in this course, we’ll assume a Service Desk is the single point of contact for just Information Technology (or IT) issues, providing users with a single telephone or fax number, or with a single web or e-mail address.



164

Service Desk

5E

®

ITIL Foundation

?

S5Ep12

Activity

Which item of documentation needs to be available to the Service Desk staff on a reference basis so that they can determine whether a customer's complaint about a service really is valid? Feedback Service Desk staff will need to be fully aware of any Service Level Agreements that are in place so that they can assess priority of issues, service requests or incidents raised by the users.

S5Ep13

A single point of contact continued

So, as the single contact point, the first duty of the Service Desk is to act as the IT user’s ‘friend’ within the IT department. This particularly relates to the role of the Service Desk in: •

Monitoring progress on incidents and queries.

•

Reporting this progress back to the user.

•

Chasing any experts that have been assigned responsibility for resolving an issue.

•

Monitoring any Service Level Agreements that may specify maximum acceptable response times for resolving user issues.

As the user’s friend, the Service Desk has the responsibility of communicating with the user, both reactively and proactively. Reactively, being in response to issues and queries raised by the users, and 'proactively' being where the Service Desk goes out to make users aware of issues that might affect them. It is not uncommon, for example, for the Service Desk to publish regular electronic newsletters to the user community informing them of new facilities, changes to services and so on.

S5Ep14

A single point of contact continued

In order to operate effectively as a single point of contact and the user’s friend, the Service Desk should have the following ingredients: •

Well trained motivated staff with good interpersonal skills.

•

Well organised systems and processes for recording and tracking incidents and matching against previous incidents and solutions.

•

Appropriate technology, such as automatic call distribution equipment and knowledge-based systems that assist in identifying solutions to issues.

•

Enough technical competence to address users’ issues directly or to interface with technical experts if necessary.

In addition, the Service Desk must have all the necessary linkages with other ITIL disciplines.



165

5E

Service Desk ®

ITIL Foundation

For example, there must be continuous communication with the Problem Management process – particularly when a Major Incident has cropped up. There will also need to be liaison with Service Level Management so that potential breaches of Service Level Agreements can be recognised. Configuration Management records will need to be readily accessible so that, for example, a caller’s IT equipment can be easily identified. Conversely, the Availability Management process will be keen to look at Service Desk records of incidents for conducting their own analyses and as part of their role in improving service availability.

S5Ep15

Service Desk structure

A debate that often takes place in the early stages of implementing a Service Desk is how the desk should be structured, from a geographical perspective. There are a number of strategies that will usually be considered and the most suitable solution will vary depending on the requirements of the organization. In this example of a Local Service Desk, each distinct site or region of the organization has its own Service Desk, and hence can provide local expertise to solve local issues. There are a couple of obvious disadvantages to this approach, such as duplication of resources and the maintenance of organization-wide standards and consistency. Also, lessons learned in one area may not be passed on to the others. Such difficulties can be minimised by the use of centralised logging of incidents and resolutions and by establishing a central configuration management database that is accessible by all the local Service Desks. The big advantage of this approach is local knowledge, and this will obviously become increasingly important the more geographically and functionally dispersed the organization’s sites become. In these situations, the issues of language, cultural or political differences may favour the use of a local Service Desk. Local Service Desks can also be valuable in providing expert knowledge in specialist areas of the organization.

S5Ep16

Service Desk structure continued

The opposite extreme of the local Service Desk is the centralised Service Desk, where all incidents and queries are reported to and handled by a single centralised structure. Centralisation has the benefit of providing consolidation of management information and improves utilisation of resources, and therefore can reduce operation costs. There are dangers, however, in that a perceived loss of local knowledge may tempt local sites to set up their own unofficial help desks. Another major issue with this centralised approach can be the cost of voice and data communications.



166

5E

Service Desk ®

ITIL Foundation

Particularly in an international context, careful planning will be needed, otherwise long-distance telephone calls could easily drive up the cost of providing the service to unacceptable levels. It might still be necessary to maintain a local presence to handle support requirements of physical hardware. Another Service Desk structure suggested by ITIL is the virtual Service Desk. This is based on the concept that physical location is not relevant and that whilst the Service Desk may be perceived as a centralised point, it may actually consist of several local Service Desks. As far as the local users are concerned they are contacting a local Service Desk, but in reality their calls may be automatically routed to the most appropriate desk, based on the proximity, time of day, staffing or other organisational criteria. This option is obviously much more demanding on the use of technology, particularly telephony re-routing equipment, in order to ensure that the whole process appears transparent to the end user. However the use of the Internet and associated support tools can provide users with the perception of a single, centralised Service Desk.

S5Ep17

Service Desk structure continued

The logical extension of the virtual Service Desk is what is sometimes called the ‘follow the sun’ option. This is widely used by multi-national companies, or even, these days, by local companies who want to take advantage of cheaper labour rates in other parts of the world. So a typical ‘follow the sun’ strategy might consist of a Service Desk in Australia, operating between the hours of 6am to 6pm local time and a second desk in London operating the same hour’s local time there. The aim is to provide as close to 24-hour coverage as possible for users in each hemisphere with the European Service Desk coming on line just as the Australian one is closing down for the night, and vice versa. So, people in Europe requiring support during the night will have their calls automatically re-routed to Australia. A major advantage of this approach is that the local Desk will tend to be handling local calls during the period of peak demand, so that overnight re-routing, and hence long-distance traffic, should be relatively minimal, but support is there if needed. The communication costs can be offset against local labour costs, as staff in each geographical area may only have to work one shift in a 24-hour period. Of course, ‘follow the sun’ may well be more than two Service Desks, depending on the location of users, time differences and coverage required. To make this work effectively, well controlled escalation and handover processes are needed. It is imperative that information about incidents is replicated or shared between the different sites so that the European Desk, for example, can continue to support a user with a query that may have been raised with the Australian Desk a few hours earlier. Although there are some complexities with this approach, it clearly has many advantages and it is becoming a very common arrangement for multi-national organizations offering 24 hour/7day a week service, particularly those in the e-commerce field.



167

Service Desk

5E

®

ITIL Foundation

S5Ep18

Super User

ITIL guidance on Service Desk identifies an additional role. This is the Super User. ITIL defines a Super User as ‘a user who helps other users, and assists in communication with the Service Desk or other parts of the IT Service Provider'. Typically Super Users provide local support for minor incidents and issues. This role can be useful for example, in preventing ‘incident storms’ when a key service or component fails. A Super User can be a useful conduit for the distribution of information throughout the wider user community. This role might also act as a filter of requests and issues raised by users. In many cases a Super User will provide specific support for an application or a particular business area. Super Users may also be responsible for: • • •

Staff training for users in their area Providing support for minor incidents or simple Request Fulfilment Involvement with new releases and rollouts

Care should be taken over the appointment of Super Users and firm commitment should be sought from the individuals and their managers that they will have sufficient time to perform the role. Clearly defined management controls should be implemented and appropriate training should be provided. Remember that Super Users are not intended as a replacement to a Service Desk.

?

S5Ep19

Activity

There are three main approaches to structuring a Service Desk - local, central and virtual. Click in the white boxes so that the correct titles are shown against each of these diagrams.

S5Ep20

Communicating with the Service Desk

Faults or issues can be communicated to the Service Desk via many mechanisms. These can be categorised into two sorts: Human-generated and Machine- generated. Human users can communicate using a whole range of options such as telephone, fax, voice mail, e-mail, browser-based web forms, and so on. Machine-generated communications could come from some form of system-monitoring tool. For example, the loss of a particular communications link in a network would usually be reported via network-monitoring software. Such incidents are often referred to as Operational Events. These automatically-generated notifications allow the Service Desk staff to inform users about possible issues caused by the fault or take action to repair it. So when a Service Desk is established, the different inputs that will be encountered must be anticipated and catered for.



168

Service Desk

5E

®

ITIL Foundation

Clearly, some of these inputs allow potential for some form of automated response. If something comes in via e-mail then at least an acknowledgement of receipt can be generated automatically. It may even be possible to introduce a degree of self-service where users register and track their own incidents without the need for inter-personal communication with Service Desk staff. Be careful with this one though. It can all too easily be used as an excuse for the Service Desk not playing its role in monitoring and processing incidents on behalf of the user. Also, be careful with telephone calls. If they are not handled properly it is possible that the user will hang up in frustration and not re-dial. Hence the information that would have been gained about a particular incident or query will be lost. All that would be recorded is that a call had been dropped, which in turn will be used as a key measure of Service Desk performance. Lost calls of this kind are often referred to as ‘fugitives’. There’s a fault out there that cannot be investigated because it hasn’t been recorded and although the user could have been more persistent, the fault is with the Service Desk staff and/or their technology for not making it easier for them to report the incident.

S5Ep21

Escalation Management

Escalation Management is an important part of running an effective Service Desk. Escalation is the process of moving an incident or query to the point where it is most ably resolved. ITIL distinguishes between Functional and Hierarchical escalation. Here for example, in a generic rather than just IT Service Desk, calls that cannot be directly handled by the Service Desk will be directed to experts in the relevant functional area. The percentage of calls that get passed upwards will be determined by the skill levels and training of the Service Desk staff. So Functional escalation is the handing over of responsibility to a functionally more competent area, in order to tackle a particular issue. Hierarchical escalation is where issues are passed up the management chain, either because they are very serious or need higher level authority to sanction the resources needed to provide a solution. The first level of Hierarchical escalation would normally be to the Incident Manager, who is usually the owner of the Incident Management process. More serious issues may then go up to the Problem Management team, with a remit to call together the necessary specialists to resolve the incident as quickly as possible. Very explicit parameters need to be established to govern Hierarchical escalation, otherwise it is very easy for it to become the norm, rather than the exception.



169

Service Desk

5E S5Ep22

®

ITIL Foundation

Service Desk capability

Related to the escalation procedures is the general debate about how skilled and capable of resolving the issues the Service Desk staff should be. ITIL does not make any recommendations in this respect because there is no absolute answer – every case must be considered on its merits. Factors that are normally considered include the increased costs of employing more highly skilled staff against the improved service to the end-users that will almost certainly result. Also this may be a dynamic situation with the optimum skill level changing over time. Immediately following the introduction of a new service, for example, it may be desirable to have some second level staff available on the Service Desk to handle the initial rush of calls about the new system. So at one end of the scale we may have an unskilled Service Desk, merely logging and routing calls, and at the other end would be an expert Desk capable of handing most, if not all, the conceivable issues at the first point of call. In between these would be what is often called the skilled or semi-skilled Service Desk, and this is considered by many to be the optimal solution. Achieving this optimal balance is an interesting and difficult task. As we have said, there are no hard and fast rules. There is a school of thought that says a good target is to have about 70% of all issues resolved at the Service Desk, without further referral. But this will vary considerably depending on the service being offered and the maturity level of that service. Whatever skill level is adopted, the use of diagnostic scripts will increase the rate of resolution at first call, as will access to knowledge databases, change schedules and so on. Service Level Agreements must also be accessible so that work can be prioritised depending on the SLA clauses.

S5Ep23

Service Desk capability continued

Regardless of the technical skills that are put in place on the Service Desk, all operators must have certain basic attributes to make them suitable for the job. These will include: •

A customer-focused attitude, where helping the customer is far more important and satisfying than playing with the latest technology.

•

An articulate nature, in particular the ability to translate technical information into something that is meaningful to the business user. This can be particularly challenging when dealing with customers who are slow to catch on or who become frustrated, irate or even abusive.

•

A methodical approach to questioning and the recording of facts and the ability to maintain that approach when under severe pressure or when handling a difficult customer.



170

Service Desk

5E

®

ITIL Foundation

•

A good business perspective and understanding of what are the business critical services. This business culture is often helped by recruiting service desk staff from within the business itself.

•

And finally, multi-lingual capability is becoming an increasingly important attribute for some Service Desk staff. This is particularly true in the case of the virtual Service Desk, as discussed earlier, or in multi-national organizations.

?

S5Ep24

Activity

Click in the white box to select a word that makes this sentence correct: A user calls in to the Service Desk with a query about VAT codes in an invoicing program and is passed through to the accounting software team. This is an example of Functional / Hierarchical / Operational escalation. Feedback This is an example of Functional escalation.

S5Ep25

Service Desk technology

For the Service Desk to work effectively, some investment in modern technology will be needed. Relevant technology can be categorised into two types - telephony and software. Examples of telephony technology might be an ACD (or Automatic Call Distribution) system, which ensures that a bank of Service Desk operators are used in an optimal order and that work is smoothed out as evenly as possible. Conference call facilities can be useful in allowing a second-line expert, for example, to be included in the conversation with the end-user. The use of VoIP (or Voice over Internet Protocol) can also provide significant cost savings, particularly in international organizations. CTI (or Computer-Telephony Interface) systems can achieve major gains in efficiency. An example of this would be the identification of an incoming caller based on their telephone number and the linkage of this with a configuration management database. This would allow all the details of the user, their facilities and equipment, and possibly service history, to be brought to the operator’s screen before the call is even answered. Useful software technology would include Intelligent Knowledge-based systems that record incidents, learn from them, identify patterns over time and are able to suggest probable causes and solutions. In addition, database access would provide fast identification of Known Errors, problems or any information that would help to provide a better answer to a call. Also being widely implemented are Automatic Referral or Escalation tools which divert an issue to a predetermined list of second-line support staff, perhaps after a certain period of time. And finally Automatic Tracking and Alert tools could be used to monitor the status of an incident as it progresses through the various stages towards a resolution.



171

Service Desk

5E

®

ITIL Foundation

As with all business investments, the cost of introducing such technology must be carefully weighed against the benefits that they bring in terms of service improvements and operational efficiency.

S5Ep26

Function metrics

In order to continually improve service provision to users, regular measurement of Service Desk performance should take place. The resulting metrics can provide valuable information about Service Desk maturity, and its usefulness to users and the organization as a whole. It’s important to evaluate these metrics thoroughly, to ensure that any statistical evidence provides an accurate picture of Service Desk performance. A simple metric might be to measure the total number of calls received. However this in itself doesn’t provide clear evidence that Service Desk performance is good or bad. For example, calls to the Service Desk might increase due to a new software or hardware release, or because the organization is in the middle of a busy sales period. To help evaluate Service Desk metrics more accurately ITIL guidance suggests the following metrics. •

The first line resolution rate. The percentage of calls closed while the user is still engaged in the call or didn’t require escalation.

•

The average time to resolve an incident at first line.

•

The average time to escalate an incident which can’t be resolved at the first line.

•

The average cost of handling an incident. ITIL suggests two potential metrics here, these being;

•

The total cost of the Service Desk (dividing the cost of operation by the number of calls received), or more accurately, calculating the cost per minute of Service Desk provision. This can then help identify incidents with the greatest cost. Remember the adage ‘Time is Money’.

•

The average time to review and close a resolved call, and finally

•

The number of calls received, broken down by time of day, and day of week combined with the average call duration metric, is critical in determining the number of staff required on the Service Desk.

S5Ep27

Function metrics continued

In addition to the statistical metrics or ‘hard’ measures we have just outlined, it’s important to gather data on customers’ or users’ experience, and these are known as ‘soft’ measures. These usually involve surveys or interviews following contact with the Service Desk and are a useful way to establish how customers and users: • • •

Felt their called had been answered, Whether they had been dealt with courteously and in a professional manner, and Whether their experience had left them feeling confident about using the Service Desk again.

There are many ways to gather user feedback and ITIL outlines the following survey techniques and tools:



172

5E • • • • • •

Service Desk ®

ITIL Foundation

After-call survey Outbound telephone survey Personal interview Group interviews Postal or e-mail surveys Online surveys

Compiling surveys and evaluating the results can be complex. As such it’s likely that a specialist obtain more valuable results.

S5Ep28

will

Summary

In this session we have been looking at the reasons for, and functions of, the IT Service Desk. We have seen how the Service Desk’s role is to act as a single point of contact and the user’s ‘friend’ in IT. We have examined different strategies for structuring and resourcing a Service Desk, and we have seen the skills and attributes that Service Desk staff must have if they are to operate efficiently. We have reviewed some of the technology that can be employed to improve the efficiency of operation of the Service Desk Finally we have identified some of the ‘hard’ and ‘soft’ measures employed to measure Service Desk performance.



173

Other Functions

5F

®

ITIL Foundation

S5Fp1

Session objectives

The subject of this session is the three service functions which operate alongside the Service Desk, namely, the Technical Management function, the Application Management function, and the IT Operations Management function. These are the subject of chapters 6.4, 6.5 and 6.6 of the ITIL Service Operation publication. When you have completed this session you will be able to state the roles, objectives and organisational overlap of: • The Technical Management function • The Application Management function, and • The IT Operations Management function

S5Fp2

Technical Management - roles

In the session on Incident Management we talked about Functional escalation - passing incidents to the ‘next’ level of support. We will now take a look at some of the functions, other than the Service Desk, that may be involved in not only Incident Management but other parts of the ITSM lifecycle. They are: • Technical Management • Application Management, and • IT Operations Management Let’s start with Technical Management. Technical Management refers to the individuals, groups, departments or teams that provide technical expertise and overall management of the IT Infrastructure. The two roles required by this function are; • To be the custodian of technical knowledge, including its documentation, and expertise related to managing the IT Infrastructure, and • To provide the actual resources to support the ITSM lifecycle

S5Fp3

Technical Management - objectives

Technical Management has three main objectives. The first is to support businesses process through well designed and highly resilient, cost effective technical topology.



174

5F

Other Functions ®

ITIL Foundation

In order to support the ITSM lifecycle, Technical Management will be involved in Service Design, for example in Availability and Capacity Management and in Service Transition, in areas such as Change and Release and Deployment Management. So for example, in Availability Management it is typically looking to eliminate single points of failure and to add in resilience to the design of the infrastructure. In Capacity Management, it uses modelling techniques to achieve cost effectiveness. In Change Management it is a matter of being the change builder or independent tester in areas of expertise. And in Release and Deployment Management, Technical Management carries out operational acceptance testing.

S5Fp4

Technical Management - objectives continued

The second main objective of Technical Management is the support of the business processes through the use of adequate technical skills to maintain the technical infrastructure in optimum condition. This support covers two phases of the lifecycle - Service Operation and Continual Service Improvement. Let’s look at Service Operation activities. In Incident Management, Technical Management would be involved in restoring services as soon as possible in line with business needs. In Problem Management it would identify the unknown, underlying cause of one or more incidents and provide Requests for Change to improve the IT infrastructure. In Continual Service Improvement, Technical Management would identify improvements to the technical infrastructure to assist the drive towards optimum performance.

S5Fp5

Technical Management - objectives continued

The third main objective of Technical Management is to support the business processes through the swift use of technical skills to speedily diagnose and resolve any technical failures that do occur. Adequate technical skills will reside in groups, departments or teams such as Mainframe team, Server department, Desktop team, Database team, Storage team, and so on. These groups, departments and teams require their skills to be kept up to date with current and emerging technology so they are able to support the IT Infrastructure.

?

S5Fp6

Activity

In which of these is Technical Management involved? Feedback Amongst other things, Technical Management is involved in ensuring that their own skills are kept up to date, restoring services as soon as possible in line with business needs and carrying out independent testing in their area of expertise.



175

Other Functions

5F S5Fp7

®

ITIL Foundation

Application Management - objectives

We will now look at another function in ITIL’s Service Operation publication, namely, Application Management. It’s this function which makes one of the key IT Services decisions, of whether to ‘build’ or ‘buy’ an application. In general, Application Management is responsible for managing applications throughout their lifecycle. The four objectives of Application Management are to ensure that: • Applications are well designed, resilient and cost-effective • The required functionality is available to achieve the required business outcome • There is organization of adequate technical skills to maintain operational applications in optimum condition, and • There is swift use of technical skills to speedily diagnose and resolve any technical failures that do occur

S5Fp8

Application Management - roles

Application Management has dual general roles: • Firstly, it is the custodian of technical knowledge, documentation, management of skills and expertise related to managing applications, and • Secondly, it provides the actual resources to support applications through the ITSM lifecycle In addition it has two specific roles: These are: • The provision of guidance to IT Operations on how best to carry out the ongoing operational management of applications, and • The integration of the Application Management lifecycle and managing applications until retirement

S5Fp9

Application Management - scope

The Application lifecycle matches the ITSM lifecycle but with its focus on applications rather than services. We can therefore think of it in terms of the following stages: • Requirements - the support of strategic decisions • Design - the Service Design phase of the Application service lifecycle • Build and Deploy - links to the Service Transition phase of the Service lifecycle regarding applications • Operate - documenting or maintaining the technical skills • Optimise - the Continual Service Improvement phase



176

5F

Other Functions ®

ITIL Foundation

?

S5Fp10

Activity

Is this statement true or false? Feedback This statement is false. Whilst these are all activities in which Application Management is involved, it is important to appreciate that Application Management is involved in the full lifecycle of applications right through to their retirement.

S5Fp11

IT Operations Management - objectives

In addition to Technical Management there is a specific need for IT Operations Management, and as such, ITIL describes a function to facilitate this. IT Operations Management includes IT Operations control, which is the department, group or team responsible for running the day-to-day operational activities. IT Operations Management has three main objectives. These are: • The maintenance of the status-quo to achieve stability of the organization’s day-to-day processes and activities • Regular scrutiny and improvements to achieve improved service at reduced costs, whilst maintaining stability, and

• Swift application of operational skills to diagnose and resolve any IT Operations failure

S5Fp12

IT Operations Management - components

There are two completely separate aspects to IT Operations Management - Operations Control and Facilities Management. Operations Control oversees the execution and monitoring of IT operational events and activities such as: • • • • •

Console management Job scheduling Backup and restore Print and output Maintenance activities for individual components

On the other hand, Facilities Management handles the accommodation aspects of IT such as: • The Data centre building • Computer rooms including the cabling • Recovery site accommodation • Power and air conditioning • Fire and security systems



177

5F

Other Functions ®

ITIL Foundation

?

S5Fp13

Activity

Which of the options shown is NOT one of the main objectives of IT Operations Management? Feedback Answer options 2, 3 and 4 are the main objectives of IT Operations Management.

S5Fp14

Summary

In this session we have been looking at the three service functions which operate alongside the Service Desk, namely the Technical Management function, the Application Management function, and the IT Operations Management function. These are the subject of chapters and 6.4, 6.5 and 6.6 of the ITIL Service Operation publication. We saw that Technical Management is the custodian of technical knowledge including its documentation and expertise related to managing the IT Infrastructure, and provides the actual resources to support the ITSM lifecycle. We saw that Application Management works together with Technical Management performing the same roles for applications as Technical Management does for the IT infrastructure, in that it is the custodian of technical knowledge, including its documentation and expertise related to managing applications. It also provides resources to support the ITSM lifecycle. We saw that IT Operations control is responsible for running the day-to-day operational activities, and oversees the execution and monitoring of the operational activities and events in the IT Infrastructure. Finally we introduced you to Facilities management which refers to the management of the physical IT environment such as a Data Centre, or a recovery centre, together with the power and cooling equipment.



178

6A S6Ap1

Overview of CSI ®

ITIL Foundation

Session Objectives

This overview session looks at the ITIL Service Management publication, Continual Service Improvement. This book provides guidance to help maintain and improve the Design, Transition and Operations of Services in line with changing business requirements. The book describes quality management techniques such as the Deming Plan, Do, Check and Act Cycle; the 7 step improvement process, the Continuous Service Improvement approach, Six Sigma, Balance Score Cards, Capability Maturity Model, DMAIC and other approaches. Continual Service Improvement or CSI is an on-going activity that applies to the complete Service lifecycle, including Service Strategy. As such CSI should be part of a pro-active rather than re-active organizational culture. In this brief overview session we will: • Identify the purpose of Continual Service Improvement • Outline the main objectives of Continual Service Improvement • We’ll go on to describe the value to the business from Continual Service Improvement • We will conclude the session by reviewing the main techniques or processes involved

S6Ap2

The purpose of CSI

The purpose of CSI is to align IT services with changing Business needs by identifying and implementing improvements to IT Services that support Business processes. These improvement activities support the lifecycle approach through Service Strategy, Service Design, Service Transition and Service Operation. CSI is always seeking ways to improve service effectiveness, process effectiveness and of course cost effectiveness. The objectives for Continual Service Improvement are to: •

Review, analyse, prioritize and make recommendations on improvement opportunities in each lifecycle stage: service strategy, service design, service transition, service operation and CSI itself

•

It should also review and analyse service level achievement

•

And identify and implement specific activities to improve IT service quality and improve the efficiency and effectiveness of the enabling processes

•

CSI can improve cost effectiveness of delivering IT services without sacrificing customer satisfaction

•

And ensure applicable quality management methods are used to support continual improvement activities

•

CSI can also ensure that processes have clearly defined objectives and measurements that lead to actionable improvements

•

Finally CSI can help us understand what to measure, why it is being measured and what the successful outcome should be



179

6A S6Ap3

Overview of CSI ®

ITIL Foundation


The value delivered via Continual Service Improvement may arise from four common service improvement outcomes. These are: • • • •

Improvements Benefits Return on investment (or RoI) Value on Investment (or VoI)

Improvements are ’outcomes that when compared to the ‘before’ state, show a measurable increase in a desirable metric or decrease in an undesirable one’. Imagine for example that too many of our fast food restaurants’ customers complain about slow service and leave the restaurant. Before taking further action, we need to find out what they expect. One approach is to ask the customers what they expect and then benchmark our restaurant with other similar restaurants to see how they meet expectations.

S6Ap4


‘Benefits’ are usually defined and measurable and will give an indication of when they are likely to be realised. A Benefit from Continual Service Improvement would result in an overall improvement in quality of business operations. This might result from simple changes to the supporting processes. Return on Investment or RoI can be described as the ‘difference between the benefit achieved and the amount expended to achieve that benefit, expressed as a percentage’. Finally, Value on Investment or VoI can be described as the extra value created from benefits that include non-monetary or long-term outcomes. So for example, if our fast food restaurant enables their wifi connection so that it can be used by customers, then that might make them the preferred place to hold company meetings. Additional services such as video conferencing could also be added. This is adding Value on Investment.

S6Ap5

CSI Register

This part of the model focuses on the CSI Register. Organizations can quite possibly find themselves in a position where many initiatives and improvement activities have not only been identified, for example from Major Problem Reviews or Post Implementation Reviews but will also require managing through to implementation. This could be through either a formal change management process or through a formal Programme or Project Management route. It is considered best practice to hold details of these initiatives in a register, called the CSI register. Each entry into the CSI register should be categorized as follows: •

Small, medium or large undertakings

With additional categorization considerations to timescales - in other words can the initiatives listed be achieved quickly, or in the medium term or longer term.



180

6A

Overview of CSI ®

ITIL Foundation

The CSI register contains important information for the overall service provider and should be held and regarded as part of the service knowledge management system or SKMS. It is important to recognise that a CSI register provides the service provider with a coordinated, consistent view of the potentially many improvement activities. It is therefore important that time is spent defining the interface from the CSI register of initiatives with strategic initiatives and with processes such as problem management, capacity management and change management. Inputs from the service review meeting activity, undertaken as part of the SLM process is likely to result in a number of requirements for improvement.

? Activity

S6Ap6

Take a look at this table of information. Use your skill and judgment to decide whether the statements are ’Improvements‘, ’Benefits‘, ’Return on Investment’ (ROI) or ’Value on Investment’ (VOI), or any combination of each? Feedback We think that all the options can be regarded as ’Improvements‘ and ’Benefits‘, However the lunch break may be a ’dis-benefit‘ to the employee’s boss but a benefit to the employee!

S6Ap7

The CSI Model

Having outlined some of the key concepts, let’s look at the Continual Service Improvement Model and the Deming, Plan, Do, Check Act cycle. We will also take a brief look at Six Sigma, and CMMI. Let’s begin with the Continual Service improvement Approach. The process follows six steps: We begin by identifying some long term goal. The CSI book refers to this as the ‘Vision’. In our fast food company our vision might be to increase profitability by 30% within 24 months. Having identified the ‘vision’ the next stage is to complete a baseline assessment of our current position. This could be assessed in terms of the business, organization, people, process and technology. This could be regarded as the ’as is‘ state. So for example, the assessment might suggest that we need to generate more revenue by getting 5% more customers who are prepared to pay 20% more for their meal.

S6Ap8

The CSI Model

At this point specific goals are established. To get more customers we might need to reduce the time a customer spends in the restaurant occupying a table but not spending any money. So the goal might be to reduce this time from an average of 45 minutes to 30 minutes. This is regarded as the ’to be‘ state. To move from one state to another, there will have to be change. The change could result in an improvement to the current processes. At pre-defined stages we check that we are on track to meet the goal. The change is supported by Business Change Programmes which are supported by IT programmes. After 24 months we can check whether we have increased our profitability as required and move forward towards new goals. The IT Service Management contribution might come from the use of the automated meal ordering service we mentioned earlier.



181

Overview of CSI

6A

®

ITIL Foundation

The Continual Service Improvement Approach can work with Balance Score Cards by helping to focus on areas such as business, organization, people, customer, process, finance, learning and growth and technology.

?

S6Ap9

Activity

Which of the following is NOT a step in the Continual Service Improvement (CSI) Approach?

Feedback ‘Is there a budget’ is not a step in the Continual Service Improvement Approach.

S6Ap10

The Deming Cycle

Deming Cycle is an approach that helps to develop higher quality, higher productivity and increased competitiveness. The process is iterative and is broken down into four distinct stages. The first of these is Plan. This stage is where the goals are set. Gap analysis is performed to identify any improvements needed. Based on the results of the analysis steps to close the gap are defined. The ‘Do’ stage involves the implementation of a project to close the identified gaps. Now it’s time to Check whether a gap still exists between the ‘where you were’ and ‘where you want to be’. From a Service Level Management view there may be recommendations to update or modify the Service Catalogue or some SLAs. The Supplier Management process may also be involved, such as a contract change. This may be complex to implement. Finally the Act stage is where the improved service or service management process improvements are implemented. It’s here you decide what changes to apply. Often the Act stage says ‘don’t change’; there is no need for it yet.

S6Ap11

The 7 Step Improvement Process

The 7 Step Improvement process approach provides the service provider with a structured approach to improvement. The 7 main steps are can be broken down into the 4 sections from the Deming cycle of the Plan, Do, Check, Act and are as follows: •

Plan

•

Identify the strategy for improvement

•

Define what you will measure

•

Do

•

Gather the data

•

Process the data

•

Check



182

6A •

Analyse the information and data

•

Present and use the information

•

And then we Act

Overview of CSI ®

ITIL Foundation

Finally the seventh step is to implement the improvement. We’ll look into this process in more detail during the next module of this course.

?

S6Ap12

Exercise

Here’s a short activity. A client asks you to define a series of steps that could help them identify, implement and exploit potential improvements. What six steps could you suggest? Try thinking about the CSI approach and the Deming cycle we looked at earlier. Once you’ve given it some thought, click on the reveal button to see our model answer.

S6Ap13

Summary

This concludes this overview session on the ITIL publication Continual Service Improvement. In this overview session we have; •

Identified the goal of Continual Service Improvement, which is to implement improvements to IT services that support business processes

•

We went on to identify the main objectives of Continual Service Improvement including its role in reviewing Service Level Achievements

•

We also described the value to the business CSI can bring. And introduced to you the CSI register

•

Finally we reviewed the main techniques or processes associated with CSI, including the Continuous Service Improvement approach, the Deming Plan, Do, Check, Act cycle and the 7 Step improvement process

?

S6AQ

Topic Quiz




183

6B

Continual Service Improvement

S6Bp1

®

ITIL Foundation

Session objectives

In this session we will be looking at the CSI Improvement approach, the 7-Step Improvement process and the Deming cycle. These are covered in the ITIL Continuing Service Improvement publication. When you have completed this session you will: •

Understand the key principles of the CSI Improvement approach

•

Be able to explain the high level objectives, basic concepts, activities, roles and metrics for the 7step Improvement process

•

Appreciate the origin of the Deming cycle, and be able to identify and discuss the four stages that make up the cycle

S6Bp2

Continual Service Improvement Approach

The Continual Service Improvement approach provides a series of steps for process improvement. Consider this saying about measurements and management: You cannot manage what you cannot control, you cannot control what you cannot measure, you cannot measure what you cannot define. In terms of the model, measurement allows you to answer the questions: • Where are we now? • Where do we want to be? • Did we get there? ‘Where are we now?’ utilises baselines and provides a starting point for later comparison. Other baselines can be taken as markers to show the progress you are making toward the step ‘Did we get there?’ There are four reasons to measure and monitor: • • • •

To validate decisions which have been made previously To direct activities in order to meet set targets To justify a future course of action supported with factual evidence To intervene - to identify a point of intervention including subsequent changes and corrective actions

Baselines should ideally be performed at every completed phase of the project. ‘How do we get there?’ is concerned with the tactical planning involved in service and process improvement. The final step is ‘How do we keep the momentum going?’ In this step we revisit the vision and ask the business the question ‘Is this where we want to be?’ It is now up to the business to decide if there needs to be a change in vision, which in turn would result in new business goals and objectives.



184

6B

Continual Service Improvement ®

ITIL Foundation

?

S6Bp3

Activity

Which of these is the first activity of the Continual Service Improvement (CSI) model? Feedback The first activity is to understand the vision of the business which includes understanding the mission, goals and objectives.

?

S6Bp4

Activity

Which of these is NOT a step in the Continual Service Improvement (CSI) model? Feedback Budgets are not specifically considered within the CSI model.

S6Bp5

The 7-step improvement process

Fundamental to CSI is the concept of measurement. To support this concept CSI uses the 7-Step Improvement process. The 7 steps in the improvement process are shown on this diagram. They are: Step 1 - Identify the Strategy for improvement Step 2 - Define what you will measure Step 3 - Gather the data Step 4 - Processing the data Step 5 - Analyse the data and information Step 6 - Present and use the data Step 7 - Implementing improvement Let’s take a brief look at each in turn. Step 1 - Identify the strategy for improvement This will often be driven by business requirements and therefore a good place to start would be the Service Level Agreements which are in the Service Catalogue. Identify the overall vision, business need, the strategy and the tactical and operational goals Step 2 - Define what you will measure Service Strategy and Service Design should have identified this information early in the lifecycle. CSI can then start its cycle all over again at ‘Where are we now?’ and ‘Where do we want to be?’ This identifies the ideal situation for both the business and IT. CSI can conduct a gap analysis to identify the opportunities for improvement as well as answering the question ‘How do we get there?’

S6Bp6

The 7-step improvement process continued

Step 3 - Gathering the data In order to properly answer the question ‘Did we get there?’ data must first be gathered (usually through service operations). Data can be gathered from many different sources based on goals and objectives identified. At this point the data is raw and no conclusions are drawn.



185

6B


ITIL Foundation

You will recall that data is a set of discrete facts about events. This data needs to be captured in order for it to be analysed and turned into useful information. Decisions must be made to capture the correct data, and how the data is to be stored and used. The key is to gather quality data about services, tools, processes, organization or configuration items. There are three specific types of data to capture. The first type is Technology data - data associated with component and application metrics, for example, performance and availability data. The next is Process data such as CSFs, KPIs and activity metrics. The KPIs will cover quality, performance, value and compliance. Finally there is Service data, for example, availability of the end-to-end service to the user.

S6Bp7


Step 4 - Process the data Here the data is processed in alignment with the critical success factors or CSFs and KPIs specified. This means that timeframes are coordinated, unaligned data is rationalized and made consistent, and gaps in the data are identified. The simple goal of this step is to process data from multiple disparate sources to give it context that can be compared. Once we have rationalized the data we can begin analysis. To obtain information is the ability to manage the data content and have the data presented in an ‘easy to use’ format. This should help answer the questions ‘Who? What? When? and Where?. Information may be used to support conformance with legal and other requirements. Data gathering can be done by automation or manually. The key questions are: • • • •

What is the frequency of processing the data? Is the data required daily, weekly, monthly? What format is required by the output? What tools and systems can be used for processing the data? How do we evaluate the processed data?

S6Bp8


Step 5 - Analyse the information and data As we bring the data more and more into context it evolves from raw data into information where we can start to answer questions about who, what, when, where and how as well as trends and the impact on the business. It is the analysing step that is most often overlooked or forgotten in the rush to present data to management. First, data needs to be turned into Information. Analysis of this information transforms the information into knowledge. Knowledge puts information into an ‘ease of use’ format which can aid decision-making.



186

6B


ITIL Foundation

Knowledge gives us the ability to answer ‘How?’ to use the information and therefore support decisionmaking. For example, how will we improve based on the information that has been provided?

S6Bp9


Step 6 - Presenting and using the information Here the answer to ‘Did we get there?’ is formatted and communicated in whatever way necessary to present to the various stakeholders an accurate picture of the results of the improvement efforts. Knowledge is presented to the business in a form and manner that reflects their needs and assists them in determining the next steps. In this step we turn knowledge into wisdom, that is to say we allow the knowledge to be applied with common sense judgement. We do this by producing reports, monitors, action plans, reviews, evaluations and identifying opportunities. There are three stakeholders to present to, each with their own focus on improvement: • The business • Senior IT management • Internal IT Step 7 - Implement Improvement The knowledge gained is used to optimize, improve and correct services and processes. Issues have been identified and now solutions are implemented – wisdom is applied to the knowledge. Managers need to: • Identify issues • Present solutions • Explain how corrective actions will be taken to improve the service

?

S6Bp10

Activity

Which of the options shows the CORRECT order of the first four activities in the 7-Step Improvement process? Feedback Define what you should measure, define what you can measure, gather data and process data.

?

S6Bp11

Activity

Which of these options most accurately describes the 7-Step Improvement process? Feedback A process for identifying the strategy for improvement, defining what you will measure, gathering the data, processing the data, analyzing the data, presenting and using the data and implementing the improvement.



187

6B

Continual Service Improvement

S6Bp12

®

ITIL Foundation

The Deming Cycle

The Deming cycle originates from work in management philosophy by W. Edwards Deming, aimed at achieving higher quality, increased productivity, and a more competitive position. The Deming cycle is used for process improvement. The four key stages of the cycle are: • • • •

Plan - Design or revise processes that support the IT Services Do - Implement the plan and manage the process Check - Measure the processes and IT Services, compare with the objectives and produce reports Act - Plan and implement changes to improve the processes

These four key stages are then followed by a phase of consolidation which prevents the cycle from ‘rolling back down the hill’. Our goal in using the Deming cycle is steady, ongoing improvement. It forms a foundation of Continual Service Improvement. The Deming cycle is critical at two points in CSI: • Implementation of CSIs • The application of CSI to services and Service Management processes At implementation, all four stages of the Deming cycle are used. With ongoing improvement, CSI draws on the Check and Act stages to monitor, measure, review and implement initiatives. The cycle is underpinned by a process-led approach to management, where defined processes are in place, the activities are measured for compliance to expected values, and outputs are audited to validate and improve the process.

?

S6Bp13

Activity

Now, a final question. Which of the following is the correct order of the four key stages in the Deming cycle? Feedback The correct answer is Plan, Do, Check, Act. If you feel unsure, you should go back and take another look.

S6Bp14

Roles in CSI

Finally, there are a number of key roles in CSI, the two most important being the Service Manager and the Continual Service Improvement (CSI) Manager. These roles are production roles and focus on CSI as a way of life within an organization.



188

6B


ITIL Foundation

This table illustrates the key activities in CSI and shows how both the Service Manager and the CSI Manager have a key role to play in each of them.

S6Bp15

Summary

In this session we have been examining the CSI Improvement approach, the 7-Step Improvement process and the Deming cycle. These are covered in the ITIL Continuing Service Improvement publication. You should now understand the key principles of the CSI improvement approach. You should be able to explain the high level objectives, basic concepts, activities, roles and metrics for the 7-Step Improvement process. You should also appreciate the origin of the Deming cycle, and be able to identify and discuss the four stages that make up the cycle.



189

7 S7p1

Technology and Architecture ®

ITIL Foundation

Session objectives

The subject of this session is Technology and Architecture which is covered in chapter 7.1 of the ITIL Service Design publication, chapter 7 of the Service Transition publication and chapter 7.1 of the Service Operation publication. Also covered is service automation and how it assists with the integration of the Service Management processes. This is covered in chapter 8.1 of the Service Strategy publication. Once you have completed this session; • • •

You will be able to identify generic requirements for an integrated set of Service Management technology for Service Design, Service Transition and Service Operation. You will also understand how service automation assists with the integration of Service Management processes. Finally we’ll spend some time looking at the tool selection guidance.

S7p2

Service Design tools

There are many and varied tools and techniques, both proprietary and non-proprietary, that can be used to assist with the design of services and their associated components. Most can be categorized as relating to: • • • • •

Hardware Software Environment Process Data

The main benefits of using these tools are: • • • • • •

Speeding up the design process Ensuring that standards and conventions are followed Offering prototyping, modelling and simulation facilities Enabling ‘What if?’ scenarios to be examined Enabling interfaces and dependencies to be checked and correlated Validating designs before they are developed and implemented to ensure that they satisfy and fulfil their intended requirements.

?

S7p3

Activity

Now, can you identify which of these areas technology would help to support during the Service Design phase of the lifecycle? Feedback Technology would help to support all of these during the Service Design phase of the lifecycle.



190

Technology and Architecture

7 S7p4

®

ITIL Foundation

Service Transition tools

Technology has a major role to play in Service Transition. Not only should technology be designed in, there should also be in place mechanisms for maintaining and maximising benefit from that technology. There are two ways in which Service Transition is supported by technology: •

Enterprise-wide tools that support the broader systems and processes within which Service Transition delivers support.

•

Tools targeted more specifically at supporting Service Transition or parts of Service Transition.

S7p5

Service Transition tools continued

The following systems, supporting the wider scope, will provide automated support for some elements of Service Transition management. IT Service Management systems, like the Configuration Management System (or CMS), will provide integration capabilities to integrate and link in the CMDB’s and records such as incidents, problems, known errors and changes. There are system, network and Application Management tools including service dashboards and reporting tools. Specific ITSM technology and tools will cover: • • • • • • • • • •

Service Knowledge Management System Collaborative, content management, workflow tools Data mining tools Extract, load and transform data tools Measurement and reporting systems Test management and testing tools Database and test data management tools Copying and publishing tools Release and Deployment technology, and Deployment and logistics systems and tools

S7p6


There are many support tools that can assist Change Management, Configuration Management and Release Management. Coming in a variety of combinations, they may include: •

Configuration Management Systems and tools, version control tools and document management systems

•

Requirements analysis and design tools, systems architecture and CASE tools, which can facilitate impact analysis from a business perspective



191

Technology and Architecture

7

®

ITIL Foundation

•

Database management audit tools, to track physical databases.

•

Distribution and installation tools

•

Comparison tools, for example, software files, directories, databases

•

Build and release tools that provide listings of input and output CIs

•

Installation and de-installation tools that provide listings of CIs installed

•

Compression tools, to save storage space

•

Listing and configuration baseline tools, for example, full directory listings with date-time stamps and check sums

•

Discovery and audit tools (also called ‘Inventory’ tools), detection and recovery tools, where the build is returned to a known state

•

Visualisation, mapping and graphical representations with drill-down reporting tools including those that access objects from several databases, providing integrated reports across systems

S7p7


To support Service Operation, an integrated ITSM technology is needed. In some cases, it may be in the form of a toolset, as some suppliers sell their technology as ‘modules’ and organizations can choose whether or not to integrate products from alternative suppliers. However, there needs to be core functionality. There needs to be: • • • • • • • • •

Self-Help Workflow or process engine Integrated CMS Discovery/Deployment/Licensing technology Remote control Diagnostic utilities Reporting Dashboards Integration with Business Service Management

Click on each of these for more detailed information. Self-Help Many organizations find it beneficial to offer ‘Self-Help’ capabilities to their users. The technology should therefore support this capability with some form of web front-end allowing web pages to be defined offering a menu-driven range of Self Help and Service Requests with a direct interface into the back-end process-handling software. Workflow or process engine A workflow or process control engine is needed to allow the pre-definition and control of defined processes such as an Incident Lifecycle, Request Fulfilment Lifecycle, Problem Lifecycle, Change Model, etc. This should allow responsibilities, activities, timescales, escalation paths and alerting to be predefined and then automatically managed.



192

7


ITIL Foundation

Integrated CMS The tool should have an integrated CMS to allow the organization’s IT infrastructure assets, components, services and any ancillary CIs (such as contracts, locations, licenses, suppliers etc. - anything that the IT organization wishes to control) to be held, together with all relevant attributes, in a centralised location, and to allow relationships between each to be stored and maintained, and linked to Incident, Problem, Known Error and Change Records, as appropriate. Discovery/Deployment/Licensing technology In order to populate or verify the CMS data and to assist in License Management, discovery or automated audit tools will be required. Such tools should be capable of being run from any location on the network and allow interrogation and recovery of information relating to all components that make up, or are connected to, the IT Infrastructure. Such technology should allow ‘filtering’ so that the data being carried forward can be vetted and only required data extracted. It is also very helpful if ‘changes only’ since the last audit can be extracted and reported upon. The same technology can often be used to deploy new software to target locations - this is an essential requirement for all Service Operation teams or departments, to allow patches, transports etc. to be distributed to the correct users. An interface to ‘Self Help’ capabilities is desirable to allow approved software downloads to be requested in this way but automatically handled by the deployment software. Tools that allow automatic comparison of software licences’ details held (in the CMS, ideally) and actual licence numbers deployed, with reporting of any discrepancies, are extremely desirable. Remote control It is often helpful for the Service Desk analysts and other support groups to be able to take control of the user’s desk-top (under properly controlled security conditions) so as to allow them to conduct investigations or correct settings, etc. Facilities to allow this level of remote control will be needed. Diagnostic utilities It could be extremely useful for the Service Desk and other support groups if the technology incorporated the capability to create and use diagnostic scripts and other diagnostic utilities (such as, for example, case-based reasoning tools) to assist with earlier diagnosis of incidents. Ideally, these should be ‘context sensitive’ and presentation of the scripts automated so far as possible. Reporting There is no use in storing data unless it can be easily retrieved and used to meet the organization’s purposes. The technology should therefore incorporate good reporting capabilities, as well as allow standard interfaces which can be used to input data to industry-standard reporting packages, dashboards, etc. Ideally, instant, on-screen as well as printed reporting can be provided through the use of contextsensitive ‘top ten’ reports. Dashboards Dashboard-type technology is useful to allow ‘see at a glance’ visibility of overall IT service performance and availability levels. Such displays can be included in management-level reports to users and customers, but can also give real-time information for inclusion in IT web pages to give dynamic reporting, and can be used for support and investigation purposes. Capabilities to support customised views of information to meet specific levels of interest can be particularly useful. However, they sometimes represent a technical rather than service view of the infrastructure and in such cases they may be of less interest to customers and users. Integration with Business Service Management There is a trend within the IT industry to try to bring together business-related IT with the processes and disciplines of IT Service Management – some call this Business Service Management. To facilitate this, business applications and tools need to be interfaced with ITSM support tools to give the required functionality. This can be illustrated by this example: More advanced tools integration capabilities are needed to allow greater exploitation of this sort of business and IT integration.



193

7


ITIL Foundation

?

S7p8

Activity

Now, can you identify which of these areas technology would help to support during the Service Operation phase of the lifecycle? Feedback Technology would help to support all of these during the Service Operation phase of the lifecycle.

S7p9

Service automation

Automation can have particularly significant impact on the performance of service assets such as management, organization, people, process, knowledge and information. Applications by themselves are a means of automation, but their performance can also be improved where they need to be shared between people and process assets. Advances in artificial intelligence, machine learning and rich-media technologies have increased the capabilities of software-based service agents to handle a variety of tasks and interactions. Automation is considered to improve the utility and warranty of services. It may offer advantages in many areas of opportunity, including the following: The capacity of automated resources can be more easily adjusted in response to variations in demand volumes. Automated systems present a good basis for measuring and improving service processes by holding constant the factor of human resources. Conversely, they can be used to measure the differential impact on service quality and costs due to varying levels of knowledge, skills and experience of human resources. Automation is a means for capturing the knowledge required for a service process. The following are some of the areas where Service Management can benefit from automation: • • • • • •

Design and modelling Service Catalogue Pattern recognition and analysis Classification, prioritization and routing Detection and monitoring Optimization

S7p10

Tool Selection - guidance

ITIL provides guidance on selecting tools to enable processes to work more effectively. Included in this guidance is the Service Management tool evaluation process, as shown here. We’ll take a few moments here, to look at the process. The first step is to identify the requirements in each of the relevant areas, for example: • • • •

Functional requirements Financial requirements Technical requirements Legal requirements



194

7


ITIL Foundation

The next step is to identify the products available. This can involve a lot of research or access to research that has already been done. There are many sources of information such as the Internet, Service Management publications, attending seminars, conferences and exhibitions. The third step is to set out the selection criteria which will allow the requirements to be ordered in terms of relative need. MoSCoW analysis can be used to prioritise requirements. MoSCoW analysis derives its name from the following acronym. • • • •

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 it in the future

Hence ‘MoSCoW’ analysis. You are now in a position to evaluate and rank the tools against the requirements such that you end up with a shortlist of possible tools. Finally, you are in a position to select the appropriate tool to support IT and the business.

?

S7p11

Activity

Now, see if you can recall the correct sequence of events used in choosing a technology tool.

Feedback First you need to identify the requirements and then the selection criteria. Having done that, you are in a position to embark on evaluation before selecting the technology tool.

S7p12

Summary

In this session we have: •

Identified generic requirements for an integrated set of Service Management technology for Service Design, Service Transition and Service Operation.

•

Understood how service automation assists with integrating Service Management processes.

•

Understood the tool selection guidance.



195

8 S8p1

ITIL Qualification and Exam Techniques ®

ITIL Foundation

Session objectives

So far in this course, we have concentrated on your knowledge of ITIL - what it is, what it contains and how it works in practice. Well, do you remember at school, that there were always some kids who may not have been that bright, and may not have worked that hard, but they always got through the exams OK. Every class had at least one of them! The reason that they got through wasn’t down to luck - they were just good at taking exams. They had the right mental approach, and they worked out how to stack the odds in their favour. In this session we will be looking at how you too, can increase your chances of getting a good result in the Foundation exam. - not just by knowing ITIL well - but by approaching the examination in an objective and systematic manner. But first, let’s take a brief look at the competencies, training and skills required within service management along with the ITIL examination structure as a whole. In line with the ‘keeping it simple ‘ ethos the standardising of job titles, functions, roles and responsibilities can all contribute to simplifying both service management and human resource management. Many service providers use a common framework of reference for competence and skills to support activities such as skill audits, planning future skill requirements, organizational development programmes and resource allocation. For example, resource and cost models are simpler and easier to use if jobs and roles are standardized. SFIA or the Skills Framework for the Information Age offers that common framework for Service providers to reference. Each of the identified service management roles in an organization must have the following attributes. These are summarized here.

S8p2

ITIL Qualification Structure

In 2007 the APMG was appointed by the UK’s Office of Government Commerce, as the official accreditor for ITIL. APMG are also authorised to licence other Examination Institutes (or EI’s) to administer ITIL qualification and accreditation activities. Official professional qualifications based on ITIL are currently offered by the following Examination Institutes. •

The APM Group Limited in the UK.

•

The Information Systems Examination Board (or ISEB). ISEB are also based in the UK.

•

The Examination Institute for Information Science (or EXIN) in the Netherlands, and

•

Loyalist Certification Services (or LCS) in North America.



196

8 S8p3


ITIL Foundation

ITIL Qualification Structure continued

In 2007 a new ITIL qualification scheme was launched to coincide with the launch of the version 3 ITIL library. The new structure consists of four levels. These are Foundation level, Intermediate level, ITIL Expert and the ITIL master qualification. This course only addresses the Foundation level requirements, which is, as you would expect, the entrylevel qualification. However it is a pre-requisite for going on the take the more advanced qualifications. The Foundation level qualification focuses on the student’s understanding of the key concepts, terminology and processes in ITIL and success at this level will earn students two credits.

The Intermediate qualification framework consists of two clearly defined streams. Both assess an individual’s comprehension and application of the concepts of ITIL. Candidates may take units from either stream, which provide credits towards the ITIL Expert qualification. The Lifecycle stream provides five individual certificates and is built around the five core ITIL publications, namely Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. The Capability stream provides four individual certificates and is built around four clusters, namely: • • • •

Planning, protection and optimization Service offerings and agreement Release, control and validation Operational support and analysis

S8p4

ITIL Qualification Structure continued

To achieve Expert level qualification, all candidates must pass the ‘Managing through the Lifecycle’ course. To obtain ITIL Expert level qualification, candidates must accrue 22 credits in total. This qualification brings together the full essence of a lifecycle approach to Service Management, and consolidates the knowledge gained across the qualification scheme. Finally the ITIL Master qualification will assess an individual’s ability to apply and analyse the ITIL concepts in new areas. If you choose to continue your ITIL studies, then a whole host of training opportunities await you. In addition to e-learning such as this ILX Group product, there are a wealth of classroom-based courses available. Much has been written on the subject of ITIL and Service Management and its impact on modern business, and you will find many useful books on the subject. In addition there are many Internet-based Service Management forums, which can prove an invaluable source of information on the subject.

S8p5

ITIL Foundation Qualification

Let’s return to the subject of the ITIL Foundation exam. The objective of the exam is to confirm a very broad-brush knowledge across the whole of ITIL and therefore does not demand a very detailed knowledge within any specific area.



197

8


ITIL Foundation

In simple terms this is a test that you are broadly familiar with the contents of the ITIL Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement publications. The exam itself consists of 40 multiple choice questions and one hour is allowed. In order to achieve a pass at least 26 questions must be answered correctly - in other words 65% or more of the questions asked. The examination is ‘closed book’ - in other words you can take no notes or documentation of any kind into the exam room with you. The first tip for doing well at Foundation level is therefore to do your homework. Study this course material, read the manuals and practice in the Exam Simulator. Once you are regularly scoring in excess of 30 out of 40 in the Exam Simulator you can be reasonably sure that will you pass the real Foundation exam.

S8p6

Exam strategy

Assuming that you have done all your preparation and that you have all the required knowledge, the next step is to focus on the examination itself. As we have seen, you are allowed 60 minutes to answer 40 questions. The vast majority of people finish the exam well within this time, so Tip 1 - Don’t feel under time pressure. Remain cool and stick to your game plan. You have plenty of time. The Foundation questions can be categorised into three types: •

Those that you find really easy and can answer without too much thought (although do be careful with the exact semantics of some of the questions and make sure that you have read them properly).

•

Those that you probably know the answer to but the wording of the question needs some digesting. There are a lot of ’negative’ type questions so do be careful over these.

•

Those that, even though you understand the question, you are not 100% sure of the answer.

A good strategy is therefore to do the exam paper in three passes. When you are first presented with the paper, work your way through, answering all the questions where the right answer is immediately obvious to you. Avoid any temptation to deliberate too long over any question. If in doubt move on to the next one. This first pass will ensure that, in the unlikely event that you do run out of time, at least you will have answered all the easy questions. For anybody who has done the right level of background study and preparation this alone will probably be enough to secure a pass.

S8p7

Exam strategy continued

Now go back to the beginning of the paper and start work on all the second category of questions. Once you have worked out what a question means, if you know the answer then answer the question, otherwise move on to the next unanswered question.



198

8


ITIL Foundation

This time when you get to the end of the paper you should have answered all the questions that you understand and that you are confident of the answers. Hopefully by now you will have answered the majority of the 40 questions. Now it’s time for the third and final pass. Go back to the start of the paper again and consider each of the questions that you have not yet answered. At this stage you may need to be careful over the timing. What you don’t want to do is run out of time and leave any questions unanswered, even if you have to guess the answers. Marks don’t get subtracted for wrong answers so if you have 4 or 5 questions that you just don’t know the answer to - make guesses - by random chance you will get at least one of them right. So, count up how many questions still remain unanswered and allocate a maximum time for each one so that you will just get them all answered. If you have 5 unanswered questions and 5 minutes left - don’t spend more than one minute on any one question. Again, never submit a paper unless all the questions have been answered. One final tip. Be very careful about changing any of your answers. Experience has shown that about two thirds of changes that candidates make to their answers are in fact changing a correct answer to an incorrect one. Often your first instincts are the right ones.

?

S8p8

Activity

This concludes this ITIL Foundation level training course. We hope you have enjoyed your study and wish you every success in your Service Management career. Just before you finish, try one last exercise. ITIL is nothing if not full of acronyms and many of the questions in the Foundation exam assume that you are familiar with most of them. So it is worthwhile running through the list of acronyms given in the ITIL manuals and memorising the less obvious ones.



199

9 S9p1

Exam Simulator ®

ITIL Foundation

ITIL exam simulator introduction

Welcome to the ITIL Foundation Exam Simulator. The exam consists of 40 multiple-choice questions which are randomly selected from our database. You have 60 minutes to complete the examination and the time remaining is shown on the bottom of the screen. Once you begin the exam you will be presented with a page that looks like this. You will notice that the top portion of the page contains a question reference matrix. You can choose to answer the questions in numerical sequence by clicking the Forward and Back buttons, or you can select a question by clicking its number in the matrix. You can come back to any question you’ve previously answered in the same way. Once you are happy with your answers, you can submit them for marking by clicking the Submit button, shown here. At this point you will be given your score. Valuable feedback on which of your answers were correct or incorrect is also provided. Again you can review your answers by selecting them in the question reference matrix. Green question numbers indicate a correct answer and those in red were marked incorrect. Regardless of whether you answered correctly or not, each question displays an explanation pane, providing useful references to the relevant ITIL publication. You can also add the question to your Revision Pad and by doing so you activate the Revision Pad function. When you next enter the course, the Revision Pad will be displayed on the course main menu as a drop-down box. Clicking on the question reference will display the question and answer options, whilst clicking on the adjacent session reference will take you to the appropriate revision point in the course itself. At the end of the exam you will be given an assessment of your performance and have the opportunity to print off a certificate of your result. If at any point you exit the exam before completion, you will have to restart from the beginning. Please note although the pass mark for the exam simulator is set to 50%, we recommend that you should be achieving an 80% or above pass rate on a regular basis before attempting the official exam. This will also provide you with a good cross-section of the hundreds of questions within the exam simulator database.

Good Luck!



200

ITIL Certified ITIL Foundation 2011 Study Notes

Recommend Documents