Itilv3diff SG 2741-01

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences
Students Training Guide

S150-2741-01
October 2007
Copyright Notice Copyright 2007 IBM Corporation, including this documentation and all software. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished as is without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose. Note to U.S. Government UsersDocumentation related to restricted rightsUse, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation. Trademarks The following are trademarks of IBM Corporation or Tivoli Systems Inc.: IBM, Tivoli, AIX, Cross-Site, NetView, OS/2, Planet Tivoli, RS/6000, Tivoli Certified, Tivoli Enterprise, Tivoli Ready, TME. In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli A/S. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Lotus is a registered trademark of Lotus Development Corporation. PC Direct is a trademark of Ziff Communications Company in the United States, other countries, or both and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium, and ProShare are trademarks of Intel Corporation in the United States, other countries, or both. SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. For further information, see http://www.setco.org/aboutmark.html. Other company, product, and service names may be trademarks or service marks of others. Notices References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A. Printed in Ireland.
Table of Contents
Preface Unit 1: ITIL Overview
History of Information Technology Infrastructure Library (ITIL) . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Information Technology Infrastructure Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4 ITIL Version 3 Publications Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6 Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Characteristics of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8 Generic Process Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9 ITIL Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 The Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Unit 2: The Service Lifecycle

Lesson 1: Service Lifecycle Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3
Components of the ITIL Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Service Lifecycle Illustrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
Lesson 2: Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5

Purpose of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 Service Strategy Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7 Elements of Value: Utility and Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Lesson 3: Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9

Five Aspects of Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10
Lesson 4: Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11

Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12 Value of Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
Lesson 5: Service Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14

Service Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 Value of Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Lesson 6: Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17

Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 Benefits of Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
Unit 3: ITIL Key Concepts

Service Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3 Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4 Service Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6 Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7 Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8 Service Design Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9 Service Knowledge Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10 Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12 Seven Rs of Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13 Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
I
Table of Contents
Unit 4: Key Principles and Models

The Five Major Aspects of Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3 Sourcing Approaches and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4 The Service V Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6 Service OperationsStability versus Responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7 Plan, Do, Check, and Act (PDCA) Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8 The Deming Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9 Continual Service Improvement Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10 Measurements for Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11 Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12 Types of Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13
Unit 5: Processes
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Lesson 1: Service Strategy and the Service Portfolio . . . . . . . . . . . . . . . . . . .5-3

Main Activities of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 Service Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4 Define the Market and Understand the Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Develop the Offerings and Strategic Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6 Service Portfolio Management (SPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8 The Service Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 Increasing Service and Performance Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Prepare for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 Strategic Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 Setting Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13 Defining Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13 Expansion, Growth, and Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Lesson 2: Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16 Service Catalog Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
Lesson 3: Information Security Management . . . . . . . . . . . . . . . . . . . . . . . . .5-20

Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contents of the Information Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Security Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22 5-23 5-25 5-26
Lesson 4: Supplier Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28

Supplier Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29 Supplier Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-30
Lesson 5: Service Asset Configuration Management and Release Management 5-32

Service Asset and Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SACMThe Logical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Asset and Configuration Management (SACM) Interfaces . . . . . . . . . . . . . . . . . . . . . Release and Deployment Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Factors to Consider for Release Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Release Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request Fulfilment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-32 5-34 5-35 5-37 5-38 5-39 5-40 5-41 5-43 5-45 5-47
Lesson 6: Event Management and Request Fulfilment . . . . . . . . . . . . . . . . .5-41
II
Copyright IBM Corp. 2007
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Table of Contents
Unit 6: Functions
Lesson 1: Technical, Applications, and Operational Management . . . . . . . . . .6-3
Technical Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Technical Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IT Operations Control and Facilities Management Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IT Operations Control and Facilities Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 6-5 6-6 6-7 6-8 6-9
III
Table of Contents
IV
Preface
Student Guide
2007 IBM Corporation
Preface
Course Description
This course presents the basic concepts in ITIL Service Management. The course is designed to prepare the student for a the ITIL Foundation Certificate in IT Service Management. This course is intended for students that have previously completed the Version 2 ITIL Foundation Certificate. The purpose of obtaining the ITIL Foundation certificate in IT Service Management includes the following goals: To obtain knowledge of the ITIL terminology, structure, and basic concepts To comprehend the core principles of ITIL practices for Service Management
The ITIL Foundation certificate in IT Service Management is not intended to enable the holders of the certificate to apply the ITIL practices for Service Management independently.
Audience
The target group of the ITIL Foundation certificate in IT Service Management is: Individuals who have previously completed the ITIL Foundations certificate for Version 2 Individuals who require a basic understanding of the ITIL framework and how it can be used to enhance the quality of IT service management within an organization IT professionals from an organization that has adopted and adapted ITIL who need to be informed about and thereafter contribute to an ongoing service improvement program
The target group includes, but is not limited to, IT professionals, business managers, and business process owners.
VI
Preface
Course Objectives
IBM Software Group | Tivoli software
Course Objectives
Upon completion of this course, you will be able to: Define ITIL terminology, structure and basic concepts including:
ITIL Service Strategy ITIL Service Design ITIL Service Transition ITIL Service Operation ITIL Continual Service Improvement
Explain the core principles of ITIL practices for Service Management Successfully complete the ITIL Foundations Level Certification Exam
Course Outline
The following outline is a high-level description of the contents of this course. Each unit has an overview presentation, and most have a series of student exercises designed to reinforce the concepts presented. The course contains the following units: Unit 1: ITIL Overview This unit defines service and explains the concept of Service Management as a practice. Unit 2: The Service Lifecycle This unit defines the Service Lifecycle and explains the objectives and business value for each phase in the Service Lifecycle. Unit 3: ITIL Key Concepts This unit defines some of the key terminology and explains the key concepts of Service Management.
Copyright IBM Corp. 2007 IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences
VII
Preface
Unit 4: Key Principles and Models This unit explains key principles and models of Service Management and opposing forces within Service Management.
Unit 5: Processes This unit defines Service Management processes in the Service Lifecycle. This unit explains how the Service Management processes contribute to the Service Lifecycle. It also explains many details for three core processes. Such details include the high-level objectives, scope, business value, basic concepts, activities, interfaces, key performance indicators (KPIs), and challenges. The objectives, business value, some basic concepts, and interfaces for ten of the remaining processes are also presented.
Unit 6: Functions This unit explains the role, objectives, organizational structures, staffing, and metrics of the Service Desk function. It also explains the role, objectives, and overlap of the functions of Technical Management, Application Management, and IT Operations Management.
VIII
Preface
Typographical Conventions
In this course, the following typographical conventions are used.
Convention Bold
Usage Commands, keywords, file names, authorization roles, URLs, or other information that you must use literally appear in bold. Variables and values that you must provide appear in italics. Words and phrases that are emphasized also appear in italics. New terms appear in bold italics when they are defined in the text. Code examples, output, and system messages appear in a monospace font. In this manual, the arrow character is used as a path arrow. The arrow indicates the path to the named window.
Italics
Bold Italics Monospace
>
IX
Preface
Unit 1: ITIL Overview
Unit 1: Information Technology Infrastructure Library (ITIL) Overview
1-1
Introduction
This unit defines service and explains the concept of Service Management as a practice.
Objectives
Objectives
Upon completion of this unit, you will be able to:
Define and explain the concept of a service Define and explain the concept of Service Management Explain the process model List the characteristics of processes
1-2
History of Information Technology Infrastructure Library (ITIL)

History of Information Technology Infrastructure Library (ITIL)

Developed in the United Kingdom in the 1980s by what is now called the Office of Government Commerce (OGC) Further development incorporated public and private sector best practices (IBM, Microsoft, HP, and others)
ITIL Version 1 contained 40 books, which were consolidated into seven books in 1999 in ITIL Version 2. ITIL Version 3 currently consists of five books.
1-3
Information Technology Infrastructure Library

Information Technology Infrastructure Library

A set of books that describe internationally accepted best practices for IT infrastructure management A process-based approach to IT infrastructure management A common language for IT management A framework that is independent of organizational structures, architectures, or technologies
Each book addresses capabilities having direct impact on the performance of a service provider. The structure of the ITIL core is in the form of a lifecycle. The ITIL core is expected to provide structure, stability, and strength to service management capabilities with durable principles, methods, and tools. The best practices guidance in ITIL can be adapted for changes used in various business environments and organizational strategies.
1-4
ITIL Version 3 Publications Framework
The ITIL Core consists of five publications: Service Strategy Service Design Service Transition Service Operation Continual Service Improvement
1-5
Services
Services
Deliver value to customers Facilitate outcomes Result in an increase in the probability of expected outcome
Services deliver value to customers by giving customers what they want without the ownership of specific costs and risks. Services facilitate outcomes by enhancing the performance of associated tasks and reducing the effect of constraints.
1-6
Processes
Processes
A structured set of activities designed to accomplish a specific objective A process takes one or more inputs and turns them into defined outputs A process includes all of the roles, responsibilities, tools, and management controls required to reliably deliver the outputs
Processes are closed-loop systems because they have the following characteristics: Provide change and transformation towards a goal Use feedback for self-reinforcing and self-corrective action
It is important to consider the entire process and how one process fits into another.
1-7
Characteristics of Processes
Characteristics of Processes
Measurable Specific results Respond to a specific event or are triggered at specific times
Processes are measurable and driven by performance. Managers want to measure cost, quality, and other factors, while practitioners are concerned with duration and productivity. The reason a process exists is to deliver a specific result. This result must be individually identifiable and countable. For example, changes can be counted, but it is impossible to count how many Service Desks were completed. Every process delivers a primary result to a customer or stakeholder. A process can be ongoing or iterative. It should be traceable to a specific trigger. Functions are often mistaken for processes.
1-8
Generic Process Elements
Data enters the process, is processed, and produces output. The outcome is measured and reviewed. A process is always organized around a set of objectives. The main outputs from the process should be driven by the objectives and should always include process measurements (metrics), reports, and process improvement. Each process should have an owner who is responsible for Maintaining the process Improving the process Ensuring that the process meets the objectives set for it
The objectives of any IT process should be defined in measurable terms. Objectives should be expressed in terms of business benefits and underpinning business strategy and goals. Service Design should assist each process owner to ensure the following objectives: All processes use standard terms and templates. All processes are consistent.

1-9
All processes integrate with each other to provide end-to-end integration across all areas.
If the activities of the process occur with a minimum use of resources, the process is considered efficient. Process analysis, results, and metrics should be incorporated in regular management reports and process improvements.
1-10
ITIL Processes
ITIL Processes
Version 3 ITIL books focus on the following items:

Sets of processes The lifecycle of a service
Working with defined processes is the foundation of ITIL
10
It is possible to work more efficiently and effectively by making the following definitions: The activities of an organization The necessary inputs The outputs that will result from the process
Measuring and steering the activities increases this effectiveness. Finally, by adding norms to the process, it is possible to add quality measures to the output.
1-11
The Process Model

The Process Model

A process model enables understanding and helps to articulate the distinctive features of a process Process control can be defined as the activity of planning and regulating a process, with the objective of performing a process in an effective, efficient, and consistent manner
11
Processes, should be defined, documented, and controlled. After they are under control, they can be repeated, and they become manageable. Degrees of control over processes can be defined. Then process measurement and metrics can be built in to the process to control and improve the process.
1-12
Summary
Summary
You should now be able to:
Define and explain the concept of a service Define and explain the concept of Service Management Explain the process model List the characteristics of processes
12
1-13
1-14
2-1
Introduction
This unit defines the Service Lifecycle and explains the objectives and business value for each phase in the Service Lifecycle.
Objectives
Objectives
Explain the Service Lifecycle Describe the structure and components of the ITIL Library Explain the purpose of Service Strategy Explain the two elements of value: Utility and Warranty Describe the main goals and objectives of Service Design Explain the value Service Design provides to the business Explain the value Service Transition provides to the business Explain the value Service Operation provides to the business Explain the value Continual Service Improvement provides to the business
2-2
Unit 2: The Service Lifecycle Service Lifecycle Defined
Lesson 1: Service Lifecycle Defined

Components of the ITIL Library
Components of the ITIL Library

The ITIL Library has the following components:
The ITIL Core: Best practice guidance applicable to all types of organizations who provide services to a business The ITIL Complementary Guidance: A complementary set of publications with guidance to specific to industry sectors, organization types, operating models, and technology architectures
The ITIL Core consists of five publications:

Service Strategy Service Design Service Transition Service Operation Continual Service Improvement
2-3
Unit 2: The Service Lifecycle Service Lifecycle Defined
Service Lifecycle Illustrated
Each publication addresses capabilities that have direct effect on the performance of a service provider. The ITIL core documents form the Service Lifecycle. The ITIL core is expected to provide structure, stability, and strength to service management capabilities with durable principles, methods, and tools. The ITIL Lifecycle serves to protect investments and provide the necessary basis for measurement, learning, and improvement.
2-4
Unit 2: The Service Lifecycle Service Strategy
Lesson 2: Service Strategy
Service Strategy
The Service Lifecycle
2-5
Purpose of Service Strategy

Purpose of Service Strategy

Service providers must have the ability to think and act in a strategic manner. The achievement of strategic goals or objectives requires the use of strategic assets. Service Strategy shows how to transform service management into a strategic asset. Technical knowledge of IT is necessary but not sufficient. Strategy requires knowledge from the disciplines such as operations management, marketing, finance, information systems, organizational development, systems dynamics, and industrial engineering.
2-6
Service Strategy Objectives

Service Strategy Objectives

Service Strategy seeks to answer the questions:
What services should we offer and to whom? How do we differentiate ourselves from competing alternatives? How do we truly create value for our customers? How do we capture value for our stakeholders? How can we make a case for strategic investments? How can financial management provide visibility and control over valuecreation? How should we define service quality? How do we choose among different paths for improving service quality? How do we efficiently allocate resources throughout a portfolio of services? How do we resolve conflicting demands for shared resources?
2-7
Elements of Value: Utility and Warranty

Elements of Value: Utility and Warranty

Utility
Attributes of the service that have a positive effect on the performance of activities, objects, and tasks associated with desired outcomes
Warranty
The positive effect being available when needed, in sufficient capacity or magnitude, and dependably in terms of continuity and security
Utility is what the customer gets, and warranty is how it is delivered.
Customers cannot benefit from something that is fit for purpose but not fit for useor vice versa. It is useful to separate the logic of utility from the logic of warranty for the purpose of design, development, and improvement. Considering all the separate controllable inputs, Service Strategy allows for a wider range of solutions to the problem of creating, maintaining, and increasing value.
2-8
Unit 2: The Service Lifecycle Service Design
Lesson 3: Service Design
Service Design
2-9
Unit 2: The Service Lifecycle Service Design
Five Aspects of Service Design
Five individual aspects of Service Design are considered within this book: 1. The design of new or changed services 2. The design of the Service Portfolio, including the Service Catalog 3. The design of the technology architecture and management systems 4. The design of the processes required 5. The design of measurement methods and metrics The Service Design stage of the lifecycle starts with a set of new or changed business requirements. This stage ends with the development of a service solution designed to meet the documented needs of the business. This developed solution and its Service Design Pack (SDP) are then passed to Service Transition to evaluate, build, test, and deploy the new or changed service. When these transition activities are complete, control of the new or changed service is transferred to the Service Operation stage of the Service Lifecycle.
2-10
Unit 2: The Service Lifecycle Service Transition
Lesson 4: Service Transition
Service Transition
2-11
Service Transition
Service Transition
Sets customer expectations on how the performance and use of the new or changed services can be used to enable business change Enables the business change project or customer to integrate a release into their business processes and services Reduces variations in the predicted and actual performance of the transitioned services Reduces the known errors and minimizes the risks from transitioning the new or changed services into production Ensures that the new or changed services can be used in accordance with the requirements and constraints specified within the service requirements
12
The objectives of Service Transition are as follows: To plan and manage the resources to successfully establish a new or changed service To bring the new or changed service into production within the predicted cost, quality, and time estimates. To ensure that there is minimal unpredicted impact on the production services, operations, and support organization. To increase the customer, user, and service management staff satisfaction with the service transition practices, including deployment of the new or changed service, communications, release documentation, training, and knowledge transfer. To increase proper use of the services and underlying applications and technology solutions. To provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the service transition plans.
2-12
Value of Service Transition

Value of Service Transition

Improves the ability to adapt quickly to new requirements and market developments Aids in transition management of mergers, de-mergers, and acquisitions Increases the success rate of changes and releases for the business Improves predictions of service levels and warranties for new and changed services Expedites timely cancellation or changes to maintenance contracts for both hardware and software when components are disposed of or decommissioned Aids understanding the level of risk during and after change, for example, service outage, disruption, re-work
13
The purpose of Service Transition is to perform the following tasks: Plan and manage the capacity and resources required to package, build, test, and deploy a release into production Provide a consistent framework for evaluating the service capability and risk profile before a new or changed service is deployed Establish and maintain the integrity of all identified service assets and configurations as they evolve through the service transition stage Provide knowledge and information so that Change Management, Release Management, and Deployment Management can expedite a release through the test environments and into production Provide build and installation mechanisms to deploy releases to the test and production environments Ensure that the service can be managed, operated, and supported within the design requirements and constraints
2-13
Unit 2: The Service Lifecycle Service Operations
Lesson 5: Service Operations
Service Operations
2-14
Service Operations
Service Operations
The purpose of Service Operations is to coordinate and to carry out the activities and processes required to deliver and to manage services at agreed upon levels to business users and customers Service Operations is also responsible for the ongoing management of the technology that is used to deliver and support services Well designed and implemented processes will be of little value if the day-to-day operation of those processes is not properly conducted, controlled, and managed Service improvements will not be possible if day-to-day activities to monitor performance, assess metrics, and gather data are not systematically conducted during Service Operations Service Operations includes the implementation and carrying out of all ongoing activities required to deliver and support services
15
Any activity that forms part of a service is included in Service Operation. The activity could be performed by the Service Provider, an external supplier, or the user or customer of that service. A number of ITIL processes (such as Change and Capacity Management) originate at the Service Design or Service Transition stage. However, many Service Management processes are performed in Service Operation, All services require some form of technology to deliver them. Managing this technology is not a separate issue, but an integral part of the management of the services themselves. Regardless of what services, processes, and technology are managed, people drive the demand for the services and products of organizations. Ultimately, people manage the technology, processes, and services and are a key part of Service Operations.
2-15
Value of Service Operation

Value of Service Operation

The operation of service is where plans, designs, and optimizations are implemented and measured. From a customer viewpoint, Service Operation is where actual value is seen.
16
However, a challenge to Service Operations exists. A service is expected to run within the budget established earlier in the lifecycle. In reality, however, few organizations plan effectively for the costs of ongoing management of services. Difficulty occurs obtaining funding during the operational phase to fix design flaws or unforeseen requirements. Design issues are often left to Incident and Problem Management to resolve, as though they were purely operational issues. It can be difficult to obtain funding for tools or actions, including training, that are aimed at improving the efficiency of Service Operations. Attempts to optimize the service or manage it more effectively are only seen as successful if the service has had problems in the past. Some services are taken for granted. Improvements are perceived as unnecessary and fixing services that are not broken.
2-16
Unit 2: The Service Lifecycle Continual Service Improvement
Lesson 6: Continual Service Improvement
Continual Service Improvement
2-17


Continual Service Improvement (CSI) aligns and re-aligns IT services to changing business needs by identifying and implementing improvements to IT Services Improvement activities support the Service Lifecycle through Service Strategy, Service Design, Service Transition, and Service Operation CSI strives to make processes more effective and efficient, as well as cost-effective
18
The objectives of CSI are as follows: To review, analyze, and make recommendations on improvement opportunities in each lifecycle phase: Service Strategy, Service Design, Service Transition, and Service Operations. To review and analyze Service Level Achievement results. To identify and implement individual activities to improve IT Service Quality and improve the efficiency and effectiveness of enabling the IT Service Management (ITSM) processes. To improve cost effectiveness of delivering IT services without sacrificing customer satisfaction. To ensure applicable quality management methods are used to support continual improvement activities.
2-18
Benefits of Continual Service Improvement

Benefits of Continual Service Improvement

Business and Customer Benefits Financial Benefits IT Organization Internal Benefits
19
Business and customer benefits include the following items: Overall improved quality of business operations More reliable business support provided by Incident Management, Problem Management, and Change Management processes Increased staff productivity because of increased reliability and availability of IT services Better working relationships between customers and the IT service provider
Financial benefits include the following items: Cost-effective provision of IT services Cost-justified IT infrastructure and services Reduced costs for implementing changes Reduced business impact due to IT changes Improved service reliability, stability, and thus availability Improved resource allocation and usage
2-19
IT Organization Internal Benefits include the following items: Improved metrics and management reporting Alignment of cost structure with business needs Defined roles and responsibilities
2-20
Summary
Summary
Explain the Service Lifecycle Describe the structure and components of the ITIL Library Explain the purpose of Service Strategy Explain the two elements of value: Utility and Warranty Describe the main goals and objectives of Service Design Explain the value Service Design provides to the business Explain the value Service Transition provides to the business Explain the value Service Operation provides to the business Explain the value Continual Service Improvement provides to the business
20
2-21
2-22
3-1
Introduction
This unit defines some of the key terminology and explains the key concepts of Service Management.
Objectives
Objectives
Describe the Service Portfolio, Service Catalog, and Service Model Identify Business Cases and Risk Management Explain Service Knowledge Management Systems (SKMS) Describe Alerts and Events
3-2
Service Portfolio
The Service Portfolio represents all the resources presently engaged or being released in various phases of the Service Lifecycle. Entry, progress, and exit are approved only with approved funding and a financial plan for recovering costs or showing profit, as necessary. The portfolio should have the right mix of services in the pipeline and catalog to secure the financial viability of the service provider. The Service Catalog is the only part of the Service Portfolio that recovers costs or earns profits. Service Portfolio Management (SPM) is about maximizing value while managing risks and costs. The value realization is derived from better service delivery and better customer experiences. SPM begins by documenting the standardized services of the organization and therefore has strong links to Service Level Management, particularly the Service Catalog.
3-3
Service Catalog
The Service Catalog is an important tool for Service Strategy. It is the virtual projection of the actual and present capabilities of the service provider. Many customers are only interested in what the provider can commit now rather than in future. The value of future possibilities is discounted in the present. The Service Catalog is the subset of the Service Portfolio that is visible to customers. The Service Catalog: Consists of services presently active in the Service Operation phase and those approved to be readily offered to current or prospective customers. Is useful in developing suitable solutions for customers from one or more services. Contains items that can be configured and suitably priced to fulfill a particular need. Channels service orders and demand. Acts as the acquisition portal for customers, including pricing and service-level commitments, and the terms and conditions for service provisioning.
3-4
Providers might have many customers or serve many businesses. Therefore, the Service Portfolio might project multiple Service Catalogs. The Service Catalog expresses the operational capability of the provider within the context of a customer or market space.
3-5
Service Model
Service Model
Codifies the service strategy for a market space Blueprints process and functions needed to create value Describes how service assets create value for a given portfolio of contracts Interaction means demand connects with the capacity to serve Is useful for effectiveness in continual service improvement
Service Agreements specify the terms and conditions under which such interaction occurs with commitments and expectations on each side. Service Transition evaluates the options or paths for improvements and recommends solutions that are cost-effective and low risk. Service Models continually evolve, based on external feedback received from customers and internal feedback from Service Management processes. Continual Service Improvement (CSI) processes ensure the feedback to the strategy, design, transition, and operation processes. Improvements can be made to the structure, the dynamics of a model, or to both.
3-6
Business Case
Business Case
Definition: A decision support and planning tool that projects the likely consequences of a business action. The consequences can take on qualitative and quantitative dimensions. A financial analysis, for example, is frequently central to a good business case.
3-7
Risk
Risk
Risk is defined as uncertainty of outcome, whether positive opportunity or negative threat Managing risks requires the identification and control of the exposure to risk, which may have an impact on the achievement of the business objectives of an organization The aim is to support better decision-making through a good understanding of risks and their likely impact
The two phases of risk include: Risk Analysis, which is concerned with gathering information about exposure to risk so that the organization can make appropriate decisions and manage risk appropriately. Risk Management, which involves making the following plans: Having processes in place to monitor risks Having access to reliable and up-to-date information about risks Having the right balance of control in place to deal with those risks Having decision-making processes supported by a framework of risk analysis and evaluation
3-8
Service Design Package

Service Design Package

A Service Design Package (SDP) should be produced during the design stage for:
Each new service A major change to a service Removal of a service Changes to the Service Design Package itself
This SDP is then passed from Service Design to Service Transition The SDP details all aspects of the service and the requirements of the service through all of the subsequent stages of the lifecycle of the service
The Service Design Package should contain the following items: Business Requirements Service Functional Requirements Service Level Requirements Organizational Readiness Assessment Service Lifecycle Plan
3-9
Service Knowledge Management System

Service Knowledge Management System

Data: Gathered within CMDB Fed through the CMS Goes into the SKMS Supports the informed decision making process
10
Knowledge management is focused within the Service Knowledge Management System (SKMS). Underpinning this knowledge is a considerable quantity of data. This data will be held in a central logical repository or Configuration Management System (CMS) and Configuration Management Database (CMDB). The Server Knowledge Management system is a broader concept that covers a much wider base of knowledge, for example: The experience of staff Records of peripheral matters, for example, weather, user numbers, user behavior, and performance figures of an organization Supplier and partner requirements, abilities, and expectations Typical and anticipated user skill levels
Internal CIs comprise CIs delivered by individual projects. Internal CIs include tangible (data center) and intangible assets such as software required to deliver and maintain the service and infrastructure.
3-10
External CIs include external customer requirements and agreements, releases from suppliers or subcontractors, and external services.
3-11
Service Request
\
Service Request
A generic description for many varying types of demands that are placed upon the IT department by the users The scale and frequent, low risk nature means that service requests are better handled by a separate process, rather than being allowed to congest and obstruct the normal incident and Change Management processes
11
Many service requests are actually small changes. Service Requests have the following characteristics: Low risk Frequently occurring Low cost
Examples of service requests include: A request to change a password A request to install an additional software application onto a particular workstation A request to relocate some items of desktop equipment A question requesting information
3-12
Seven Rs of Change Management

Seven Rs of Change Management

Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What resources are REQUIRED to deliver the change? Who is RESPONSIBLE for the build, test, and implementation of the change? What is the RELATIONSHIP between this change and other changes?
12
The questions for the Seven Rs of Change Management must be answered for all changes. Without this information, the impact assessment cannot be completed, and the balance of risk and benefit to the live service will not be understood. Without this understanding, the change might not deliver all of the possible or expected business benefits. The change might even have an unexpected detrimental effect on the live service.
3-13
Event
Event
Defined as any detectable or discernable occurrence that has significance:
For the management of the IT infrastructure For the delivery of an IT service and evaluation of the impact a deviation might cause to the services
Typically notifications created by an IT Service, Configuration Item (CI), or monitoring tool Effective Service Operation is dependent on:
Knowing the status of the infrastructure Detecting any deviation from normal or expected operation
13
Two types of monitoring and control systems tools for effective service operation are: Active monitoring tools that poll key CIs to determine their status and availability. Any exceptions will generate an alert that needs to be communicated to the appropriate tool or team for action. Passive monitoring tools that detect and correlate operational alerts or communications generated by CIs.
3-14
Summary
Summary
Describe the Service Portfolio, Service Catalog, and Service Model Identify Business Cases and Risk Management Explain Service Knowledge Management Systems (SKMS) Describe Alerts and Events
14
3-15
3-16
4-1
Introduction
This unit explains key principles and models of Service Management and opposing forces within Service Management.
Objectives
Objectives
Explain the five major aspects of Service Design Explain the Service V model Summarize the conflicting motives in Service Operation Describe the Plan, Do, Check, and Act (PDCA) Model Explain the Continual Service Improvement Model and the role of measurement and governance for Continual Service Improvement
4-2
The Five Major Aspects of Service Design

The Five Major Aspects of Service Design

Design of new or changed Services Service Portfolio Design which includes the Service Catalog Technology and architectural design Process design Measurement design
Five individual aspects of Service Design are considered within this book: Design of new or changed services Design of the Service Portfolio, including the Service Catalog Design of the technology architecture and management systems Design of the processes required Design of measurement methods and metrics
The Service Design stage of the lifecycle starts with a set of new or changed business requirements and ends with the development of a service solution designed to meet the documented needs of the business. This developed solution and its Service Design Pack (SDP) are then passed to Service Transition to evaluate, build, test, and deploy the new or changed service. When these transition activities are completed, control of the new or changed service is transferred to the Service Operation stage of the service lifecycle.
4-3
Sourcing Approaches and Options

Sourcing Approaches and Options

Insourcing relies on utilizing internal organizational resources Outsourcing uses the resources of an external organization or organizations Co-sourcing is a combination of insourcing and outsourcing Partnership or multi-sourcing is an arrangement between two or more organizations to work together Business Process Outsourcing (BPO) relocates entire business functions Application Service Provision involves formal arrangements with an Application Service Provider (ASP) organization
Insourcing relies on using internal organizational resources in the design, development, transition, maintenance, operation, and support. The resources can be used in any combination with new, changed, or revised service or data center operations. Outsourcing uses the resources of an external organization or organizations in a formal arrangement. The arrangement provides a well-defined portion of the design, development, maintenance, operation, and support of the service. Outsourcing includes services from Application Service Providers (ASPs). Co-sourcing combines insourcing and outsourcing to use a number of outsourcing organizations working together to co-source key elements within the lifecycle. This process typically involves a number of external organizations working together to design, develop, change, maintain, operate, and support a portion of a service. Partnership, or multisourcing, is an arrangement between two or more organizations to work together to design, develop, transition, maintain, operate, and support IT services. The focus here tends to be on strategic partnerships that use critical expertise or market opportunities. Business Process Outsourcing (BPO) relocates entire business functions. Formal arrangements between organizations specify for one organization to provide and to manage the entire business processes or functions of the other organization in a low-cost location. Common examples are accounting, payroll, and call center operations.

4-4
Application Service Provision involves formal arrangements with an Application Service Provider (ASP) organization that will provide shared computer-based services to customer organizations over a network. Applications offered in this way are also sometimes referred to as on-demand software and applications. Through ASPs, the complexities and costs of such shared software can be reduced and provided to organizations that could otherwise not justify the investment.
4-5
The Service V Model
The Service V model can be used to represent the different configuration levels that need to be built and tested to deliver a service capability. The left side of the diagram represents the specification of the service requirements down through the detailed service design. The right side focuses on the validation activities that are performed using the specifications defined on the left side. At each stage on the left side, the equivalent group on the right side is directly involved.
4-6
Service OperationsStability versus Responsiveness

Service OperationsStability versus Responsiveness

Service Operations must ensure that the IT Infrastructure is stable and available as designed Service Operations must meet response requirements A balance between Stability and Responsiveness will require that technologies and processes are adaptive rather than rigid
The function, performance, and architecture of a platform might change over a number of years. With each change comes an opportunity to provide better levels of service to the business. Other changes happen quickly and sometimes under extreme pressure. For example, a business unit acquires a large contract that requires additional IT services, more capacity, and faster response times.
4-7
Plan, Do, Check, and Act (PDCA) Model

Plan, Do, Check, and Act (PDCA) Model

W. Edwards Deming is best known for his management philosophy leading to:
Higher quality Increased productivity More competitive position
The four key stages of the Deming Cycle or Circle are:

Plan Do Check Act
The goal of CSI in using the Deming Cycle is steady, ongoing improvement.
4-8
The Deming Cycle
The Deming Cycle consists of cycles of Planning, Acting, Checking the results, and Doing actions that improve the process. Over time the goal of the Deming Cycle is steady improvement of processes.
4-9
Continual Service Improvement Model
4-10
Measurements for Continual Service Improvement

Measurements for Continual Service Improvement

Why are measurements performed?
To validate To direct To justify To intervene
10
The four basic reasons to monitor and measure lead to three key questions: Why monitor and measure? When can monitoring and measuring of this item be stopped? Is anyone using this data?
Every time you produce a report, ask yourself, Is this report still needed and used by anyone? Reasons to continue producing a report could include: To validate: Monitoring and measuring to validate previous decisions. To direct: Monitoring and measuring to set direction for activities in order to meet set targets. It is the most prevalent reason for monitoring and measuring. To justify: Monitoring and measuring to justify, with factual evidence or proof, that a course of action is required. To intervene: Monitoring and measuring to identify a point of intervention, including subsequent changes and corrective actions.
4-11
Baselines
Baselines
An important beginning point for highlighting improvement is to establish baselines as markers or starting points for later comparison Baselines are also used to establish an initial data point to determine if a service or process needs to be improved It is important that baselines are documented, recognized, and accepted throughout the organization
11
Baselines must be established at each level: Strategic goals and objectives Tactical process maturity Operational metrics and Key Performance Indicators (KPIs)
4-12
Types of Metrics
Types of Metrics
Technology metrics Process metrics Service metrics
12
Information for measuring is gathered from IT Service Management tools, monitoring tools, reporting tools, investigation tools, existing reports, and other sources. Technology metrics are often associated with component-based and application based metrics such as performance, availability and so on. Process measurements can help determine the overall health of a process. Key Performance Indicators (KPIs) can help answer questions about quality, performance, value, and compliance in following the process. Service Metrics are the results of the end-to-end service. Component or technology metrics are used to compute the Service Metrics.
4-13
Summary
Summary
Explain the five major aspects of Service Design Explain the Service V model Summarize the conflicting motives in Service Operation Describe the Plan, Do, Check, and Act (PDCA) Model Explain the Continual Service Improvement Model and the role of measurement and governance for Continual Service Improvement
13
4-14
Unit 5: Processes
Unit 5: Processes
5-1
Unit 5: Processes
Introduction
This unit defines Service Management processes in the Service Lifecycle. This unit explains how the Service Management processes contribute to the Service Lifecycle. It also explains many details for three core processes. Such details include the high-level objectives, scope, business value, basic concepts, activities, interfaces, key performance indicators (KPIs), and challenges. The objectives, business value, some basic concepts, and interfaces for ten of the remaining processes are also presented.
Objectives
Objectives
Outline the four main activities in the Service Strategy process State the objectives, business value, basic concepts, and interfaces for Service Portfolio Management (SPM) and Service Design State the objectives, business value, basic concepts, and interfaces for Service Catalog Management, Information Security Management (ISM), and Supplier Management State the objectives, business value, basic concepts, and interfaces for Service Asset and Configuration Management (SACM), Release and Deployment Management, Service Operation Explain the high-level objectives, scope, business value, basic concepts, process activities, interfaces, key metrics, and challenges for Event Management and Request Fulfilment
5-2
Unit 5: Processes Service Strategy and the Service Portfolio
Lesson 1: Service Strategy and the Service Portfolio

Main Activities of Service Strategy
Main Activities of Service Strategy

Define the market Develop the service offerings Develop strategic assets Prepare for implementation
5-3
Service Owners
Service Owners
Are responsible to the Customer for the initiation, transition, and ongoing maintenance and support of a particular service Act as prime Customer contact for all Service-related enquiries and issues Ensures that the ongoing Service delivery and support meet agreed upon Customer requirements Identifies opportunities for Service Improvements, discuss with the Customer and will raise the RFC for assessment if appropriate Are accountable to the IT Director for the delivery of the Service
The Service Owner is responsible to the customer for the initiation, transition, and ongoing maintenance and support of a particular service. The Service Owner has the following responsibilities: Act as primary customer contact for all service-related enquiries and issues Ensure that the ongoing Service delivery and support meet agreed-upon customer requirements Identify opportunities for service improvements, discuss them with the customer, and raise the RFC for assessment, if appropriate Interact with the appropriate Process Owners throughout the Service Management lifecycle Solicit required data, statistics, and reports to analyze and to facilitate effective service monitoring and performance Will be accountable to the IT Director for the delivery of the service
5-4
Define the Market and Understand the Customer

Define the Market and Understand the Customer

Develop service strategies Differentiate services from the competition Use existing opportunities: Customers who are not well supported represent opportunities for services to be offered as solutions Use new opportunities: New opportunities emerge when changes in the business environment cause a previously well-supported customer to be poorly supported
Defining the market and understanding the customer includes the following activities: Service strategies are developed for services offered Providers differentiate their services from competing alternatives available to customers Service management offers services as part of a business strategy
An example of this: A software vendor decides to offer software as a service. The vendor combines its capabilities in software development with new capabilities in service management. The vendor also makes use of its capabilities in maintaining software applications to bundle technical support as part of the core service. By adopting a service-oriented approach supported by service management capabilities, the vendor has transformed into a service business. This approach has also been adopted by internal software engineering groups who have changed from being cost centers to being profit centers.
5-5
Develop the Offerings and Strategic Assets

Develop the Offerings and Strategic Assets

Services are a means of delivering value to customers by facilitating outcomes customers need without owning specific costs and risks A market space is a set of opportunities to deliver value to the business of a customer through one or more services To meet the needs of future opportunities, Service Management must further invest in assets such as Process, Knowledge, People, Applications, and Infrastructure Service management as a strategic asset identifies the key relationships and interactions to have better visibility and control over the systems and processes they operate
A market space represents a set of opportunities for service providers to deliver value to the business of a customer through one or more services. Often it is unclear how services create value for customers. Services are often defined in the terms of resources made available for customers to use. Service definitions lack clarity on two points: Context in which such resources are useful Business outcomes that justify the expense of a service from the customers perspective
This problem leads to poor designs, ineffective operation, and lackluster performance in service contracts. Service improvements are difficult when it is not clear where improvements are truly required. Customers can understand and appreciate improvements only within the context of their own business assets, performances, and outcomes. A proper definition of services takes into account the context in which customers perceive value from the services. An outcome-based definition of services ensures that managers plan and implement all aspects of service management entirely from the perspective of the values of the customer. Such an approach ensures that services not only create value for customers but also capture value for the service provider.
5-6
Solutions that enable or enhance the performance of the customer assets indirectly support positive outcomes generated by those assets. Such solutions and propositions hold utility for the business. When that utility is backed by a suitable warranty, customers perceive benefits in a continued relationship and trust the provider to increase value and add possibilities of new customers and market spaces. These benefits justify further investments in Service Management in terms of capabilities and resources which have a tendency to reinforce each other. Stakeholders might initially trust the provider with low-value contracts or noncritical services. Service Management responds by delivering the performance expected of a strategic asset. The performance is rewarded with contract renewals, new services, and customers. Together these rewards represent a larger value of business. To handle this increase in value, Service Management must invest further in assets such as process, knowledge, people, applications, and infrastructure. Successful learning and growth enables commitments of higher service levels as Service Management is conditioned to handle bigger challenges. Over time, this cycle results in higher capability levels and maturity in Service Management, leading to a higher return on assets for the service provider. Unless properly defined, the cost of service assets spent in support of customers assets might be difficult to account for and recover. This uncertainty leads to situations where adequate value is created for the customer but inadequate value is captured for the provider. To develop Service Management as a strategic asset, define the value network by identifying the key relationships and interactions. This definition will provide to have better visibility and control over the systems and processes they operate. Managers can manage the complexity of their business environments as customers pursue their own business models and strategies. Service Management also helps account for all the costs and risks involved in providing a service or supporting a customer. Strategic assets are dynamic. They are expected to continue to perform well under changing business conditions and objectives of their organization. Therefore, strategic assets must have learning capabilities. Performance in the immediate future should benefit from knowledge and experience gained from the past. Service Management must operate as a closed-loop system that systematically creates value for the customer and captures value for the service provider. An important aspect of Service Management is controlling the interactions between customer assets and service assets.
5-7
Service Portfolio Management (SPM)

Service Portfolio Management (SPM)

The Service Portfolio represents the commitments and investments made by a service provider across all customers and market spaces Service portfolios represent the ability and readiness of a service provider to serve customers and market spaces Service Portfolio Management is critical to having the right services available to offer to customers
The Service Portfolio represents the commitments and investments made by a service provider across all customers and market spaces. It represents present contractual commitments, new service development, and ongoing service improvement programs initiated by Continual Service Improvement. Portfolio management helps managers prioritize investments and improve the allocation of resources. Portfolios instill a certain financial discipline necessary to avoid making investments that will not yield value. Service Portfolios represent the ability and readiness of a service provider to serve customers and market spaces. SPM tries to maximize value while managing risks and costs. Through SPM, managers are better able to understand quality requirements and related delivery costs. They can then seek to reduce costs through alternative means while maintaining service quality. The SPM journey begins by documenting the standardized services of the organization and therefore has strong links to Service Level Management, particularly the Service Catalog.
5-8
The Service Portfolio
5-9
Increasing Service and Performance Potential

Increasing Service and Performance Potential

The capabilities and resources (service assets) of a service provider represent the service potential or the productive capacity available to customers through a set of services Projects that develop or improve capabilities and resources increase the service potential The performance potential of services is increased by having the right mix of services to offer to customers, and designing those services to have an impact on the business of the customer The performance potential of services also arises from the removal of costs and risks from the businesses of the customers
The capabilities and resources (service assets) of a service provider represent the service potential or the productive capacity available to customers through a set of services. Projects that develop or improve capabilities and resources increase the service potential. The following example shows the results of implementing a Configuration Management system: Implementation of a Configuration Management system leads to improved visibility and control over the productive capacity of service assets such as networks, storage, and servers. The configuration management system also helps to quickly restore such capacity in the event of failures or outages. Those assets are used more efficiently, and service potential is increased because of capability improvements in Configuration Management. Through Configuration Management, all service assets should be identified with the name of the services to which they add service potential. This identification helps decision makers arrive at decisions related to service improvement and asset management. Clear relationships make it easier to ascertain the impact of changes, make business cases for investments in service assets, and identify opportunities for scale of and scope of economies. The Configuration Management system identifies critical service assets across the service portfolio for a given customer or market space. The services offered by a service provider represent the potential to increase the performance of customer assets. Without this potential, customers cannot justify procuring the services. Performance potential of services needs to be defined so that management
5-10
decisions are rooted in creating value for customers. This practice avoids many problems of service businesses where value for customers is created in intangible forms. Such forms are therefore harder to define and to control. Working backwards from the performance potential of customers ensures that service providers are always aligned with business needs, regardless of how often those needs change. The performance potential of services is increased primarily by the following characteristics: Having the right mix of services to offer to customers Designing those services to have an impact on the businesses of the customers
The productive capacity of service assets is transformed into the productive capacity of customer assets. An important aspect of delivering value for customers through services is reducing risks for customers. By deciding to use a service, customers often are seeking to avoid certain risks and costs. Therefore, the performance potential of services also arises from removing costs and risks from the businesses of the customers.
5-11
Prepare for Implementation

Prepare for Implementation

Performing Strategic Assessment Setting Objectives Defining Critical Success Factors
10
Strategic Assessment
Established service providers frequently do not understand their unique differentiators. The differentiation can come in many forms: Barriers to entry, such as the knowledge of the organization regarding the business of the customer or the broadness of service offerings Raised switching costs, due to lower cost structures generated through specialization or service sourcing A particular attribute not readily found elsewhere, such as: Product knowledge Regulatory compliance Provisioning speeds Technical capabilities Global support structures
5-12
Setting Objectives
Objectives represent the results expected from pursuing strategies, while strategies represent the actions to be taken to accomplish objectives. Clear objectives provide for consistent decision making, minimizing any future conflicts. They set forth priorities and serve as standards. To craft objectives, an organization must: Understand what outcomes customers want Determine how best to satisfy the important but underserved outcomes
From this understanding, the organization can create metrics to measure how well a service is performing. These data sources are the primary means by which a service provider creates value.
Defining Critical Success Factors

Every market space has critical success factors that determine the success or failure of a service strategy. These factors are influenced by customer needs, business trends, competition, regulatory environment, suppliers, standards, industry best practices, and technologies. Identifying critical success factors for a market space is an essential aspect of strategic planning and development. In each market space, service providers require a core set of assets in order to support a Customer Portfolio through a Service Portfolio. Consider the example of the market space for high-volume, real-time data processing, such as those required by the financial services industry. In such industries, service providers must have: Large-scale computer systems Highly reliable network infrastructure Secure facilities Knowledge of industry regulations
Without these assets, such service units cannot provide the utility and warranty demanded by customers in that market space. The dynamic nature of markets, business strategies, and organizations requires critical success factors be reviewed periodically or at significant events. Such events could include changes to customer portfolios, expansion into new market spaces, changes in the regulatory environment, and disruptive technologies. For example, the healthcare industry has new legislation on the portability and privacy of patient data. This change alters the critical success factors for all service providers operating in healthcare market spaces.
5-13
Expansion, Growth, and Differentiation

Expansion, Growth, and Differentiation

The best opportunities for expansion lie in areas where an important customer need remains poorly satisfied Growth in a market space is dependent upon a demonstrated ability to deliver value and a strong record with existing customers Differentiation in Market Spaces is normally created through better a better mix of services, superior service designs, and operational effectiveness
11
The best opportunities for service providers lie in areas where an important customer need remains poorly satisfied. Service Portfolios should be extended to support such areas of opportunity. Typically there is a need for services to provide certain levels of utility and warranty. However, managers should not overlook the costs and risks in such areas. There are typically strong reasons why certain needs of customers remain unfulfilled. Breakthrough performance and innovation are often required to successfully deliver value in underserved areas of opportunity. The long-term vitality of the service provider rests on supporting customer needs as they change or grow as well as exploiting new opportunities that emerge. This analysis identifies opportunities with current and prospective customers. It also prioritizes investments in service assets based on their potential to serve market spaces of interest. Because market spaces are defined in terms of the business needs of customers, service provider strategies are therefore aligned to customers. For this reason, service providers must think in terms of market spaces and not simply industry sectors, geographies, or technology platforms. This way of thinking is intuitive to the senior leadership of Type I providers. They are accustomed to being driven more by the outcomes expected by their business units than by the traditional market segmentation. When service strategies are linked to market spaces, it is easier to make decisions about service portfolios, designs, operations, and long-term improvements. Investments in service assets such as skills sets, knowledge, processes, and infrastructure are driven by the critical success factors for the market space.

5-14
Strategic planning and review includes examining opportunities for growth within current customers and services. Growth in a market space depends on demonstrated ability to deliver value and a strong record with existing customers. Differentiation in market spaces is normally created by the following techniques: Better a better mix of services Superior service designs Operational effectiveness that allows for efficiency and effectiveness in the delivery and support of services
Through various combinations of factors there are many ways to create differentiation. Service Management leads to differentiation in every supported market space by making decisions on the following topics: Service design Transition Operation Improvement
5-15
Unit 5: Processes Service Catalog Management
Lesson 2: Service Catalog Management

Service Catalog Management
Service Catalog Management

The Service Catalog is a central source of data recording the status of all IT services delivered by the service provider organization Service Catalog Management (SCM) process ensures that a Service Catalog is produced and maintained containing accurate information on all operational services and those being prepared to be run operationally After a Service is developed for use by customers the Service should be added to the Service Catalog
12
Service Catalog Management (SCM) process ensures that a Service Catalog is produced and maintained with accurate information. All operational services and those being prepared to be run are included in the Service Catalog. SCM provides a single source of consistent information about all of the agreed-upon services. SCM ensures that the catalog is widely available to those approved to access it. Service Catalog Management (SCM) performs the following tasks: Manages the information contained within the Service Catalog Ensures that the catalog is accurate Ensures that the catalog reflects the current details, status, interfaces, and dependencies of all services that are being run or being prepared to run in the production environment
The Service Catalog provides a central source of information about the IT services delivered by the service provider organization. The catalog ensures that all areas of the

5-16
business can view an accurate, consistent picture of the IT services, their details, and their status. The catalog should contain: View of the current IT services from the customers perspective How the services are intended to be used Business processes enabled by the services Levels and quality of service the customer can expect for each service Details of all operational services being provided Those services being prepared for transition to the live environment Summary of their characteristics Details of the customers
The Portfolio should contain all of the future requirements for services. The Service Portfolio is produced as part of Service Strategy and should include participation by those involved in Service Design, Transition, Operation, and Improvement. After a service is chartered, being developed for use by customers, Service Design produces the specifications for the service. At this point the service should be added to the Service Catalog. The SCM process produces and maintains the Service Catalog to ensure: A central, accurate, and consistent source of data A record of the status of all operational services or services being moved to the live environment A record of appropriate details of each service
5-17
Service Catalog Management Outputs

Service Catalog Management Outputs

Updates to the Service Portfolio which should contain the current status of all services and requirements for services Updates to the Service Catalog containing the details and the current status of every live service provided by the service provider
13
Many sources of information are relevant to the Service Catalog Management (SCM) process. These should include: Business information from the business and IT strategy, plans, and financial plans of the organization Information about organizational current and future requirements from the Service Portfolio Business impact analysis providing information about the impact, priority, and risk associated with each service or change to service requirements Details of any agreed-upon, new, or changed business requirements from the Service Portfolio The Service Portfolio The Configuration Management System (CMS) Feedback from all other process Triggers for the SCM process, which are changes in the business requirements and services.
5-18
One of the main triggers is a Request For Change (RFC). The Change Management process includes new services, changes to existing services, and services being retired. The process outputs of SCM include the following items: The documentation and agreement of a definition of the service Updates to the Service Portfolio, which should contain the current status of all services and requirements for services
The Service Catalog should contain: Details of every live service provided by the service provider or service being moved into the production environment Current status of each of these services Interface Dependencies
5-19
Unit 5: Processes Information Security Management
Lesson 3: Information Security Management

Information Security Management (ISM)

The ISM process aligns IT security with business security and ensures that information security is effectively managed in all service and Service Management activities ISM manages all aspects of IT and information security within all areas of IT and Service Management activity Security must address entire business processes from end to end and cover the physical and technical aspects
14
The Information Security Management (ISM) process has two goals: To align IT security with business security Ensure that information security is effectively managed in all service and Service Management activities
The term information is used in a general way and includes data stores, databases, and metadata. Information security protects the interests of those relying on information, and the systems and communications that deliver the information. It protects the interests from harm resulting from failures of availability, confidentiality, and integrity. For most organizations, the security objective is met when the following criteria occur:

Information is available and usable when required, and the systems that provide it can appropriately resist attacks and recover from or prevent failures (availability) Information is only observed by, or disclosed to, those who have a right to know (confidentiality) Information is complete, accurate, and protected against unauthorized modification (integrity)
5-20
Business transactions as well as information exchanges between enterprises, or with partners, can be trusted (authenticity and nonrepudiation)
To be effective, security must address entire business processes from end-to-end and cover the physical and technical aspects. ISM raises the awareness of the need for security within all IT services and assets throughout the organization. The process ensures that the ITP is appropriate for the needs of the organization. ISM manages all aspects of IT and information security within all areas of IT and Service Management activity. ISM provides assurance of business processes by the following methods: Enforcing appropriate security controls in all areas of IT Managing IT risk in line with business and corporate risk management processes and guidelines
5-21
Security Framework
Security Framework
Information Security Policy (ITP) and specific security policies that address each aspect of strategy, controls, and regulation Information Security Management System (ISMS), containing the standards, management procedures, and guidelines supporting the information security policies A comprehensive security strategy closely linked to the business objectives, strategies, and plans A set of security controls to support the ITP Monitoring processes to ensure compliance and provide feedback on effectiveness Training and awareness strategy and plan
15
The Information Security Management process and framework will typically consist of the following items: An Information Security Policy (ITP) and specific security policies that address each aspect of strategy, controls, and regulation An Information Security Management System (ISMS), containing the standards, management procedures, and guidelines supporting the information security policies A comprehensive security strategy closely linked to the business objectives, strategies, and plans An effective security organizational structure A set of security controls to support the ITP The management of security risks Monitoring processes to ensure compliance and provide feedback on effectiveness Communications strategy and plan for security Training and awareness strategy and plan
5-22
Contents of the Information Security Policy

Contents of the Information Security Policy (ITP)

Use and misuse of IT assets policy An access control policy A password control policy An e-mail policy An Internet policy An anti-virus policy An information classification policy A policy with regard to supplier access of IT service, information, and components An asset disposal policy
16
Information Security Management activities should be focused on and driven by an overall Information Security Policy (ITP) and a set of underpinning specific security policies. The ITP should have the full support of top executive IT management and ideally the support and commitment of top executive business management. The ITP should cover all areas of security, be appropriate, meet the needs of the business. The ITP should also include the following items: An overall ITP The use and misuse of IT assets policy An access control policy A password control policy An e-mail policy An Internet policy An anti-virus policy An information classification policy A document classification policy

5-23
A remote access policy A policy with regard to supplier access of IT service, information, and components An asset disposal policy
These policies should be widely available to all customers and users. All SLRs, SLAs, contracts, and agreements should refer to compliance with these policies. The policies should be authorized by top executive management within the business and IT. Compliance should be endorsed on a regular basis. All security policies should be reviewed and, when necessary, revised on at least an annual basis.
5-24
Information Security
5-25
Information Security Management Interfaces

Information Security Management (ISM) Interfaces

Incident and Problem Management IT Service Continuity Management Service Level Management Change Management Configuration Management Availability Management Capacity Management Financial Management Supplier Management
18
Information Security Management (ISM) interfaces include the following items: Incident and Problem Management: In providing assistance with the resolution and subsequent, justification, and correction of security incidents and problems. The Incident Management process must include the ability to identify and deal with security incidents. Service Desk and Service Operations staff must recognize a security incident. IT Service Continuity Management (ITSCM): With the assessment of business impact and risk and the provision of resilience, failover, and recovery mechanisms. Security is a major issue when continuity plans are tested or invoked. A working ITSCM plan is a mandatory requirement for ISO27001. SLM: Assistance with the determining of security requirements and responsibilities and their inclusion within SLRs and SLAs together with the investigation and resolution of service and component security breaches. Change Management: ISM should help assess every change for impact on security and security controls. Also ISM can provide information about unauthorized changes. Legal and HR: These issues must be considered when investigating security issues.
5-26
Configuration Management: Will give the ability to provide accurate asset information to assist with security classifications. Having an accurate CMS is therefore an extremely useful ISM input. Security: Often seen as an element of Availability Management with Confidentiality Integrity and Availability (CIA) being at the essence of Availability and ISM. ISM should work with both Availability Management and IT Service Continuity Management (ITSCM) to conduct integrated risk assessment and management exercises. Capacity Management: Must consider security implications when selecting and introducing new technology. Security is an important consideration when procuring any new technology or software. Financial Management: Provides adequate funds required to finance security requirements. Supplier Management: Assists with the joint management of suppliers and their access to services and systems and the terms and conditions to be included within contracts concerning supplier responsibilities.
5-27
Unit 5: Processes Supplier Management
Lesson 4: Supplier Management

Supplier Management
Supplier Management process manages suppliers and the services they supply, to provide seamless quality of IT service to the business, ensuring value for money is obtained Supplier Management ensures the provision of end-to-end, seamless, quality IT services are delivered to the business and aligned to their expectation The Supplier and Contracts Database (SCD) records all supplier and contract details, together with details of the type of services or products provided by each supplier
19
Supplier Management includes the following points: Supplier Management process manages suppliers and the services they supply to provide seamless quality of IT service to the business, ensuring value for money is obtained. Supplier Management ensures the provision of end-to-end, seamless, quality IT services are delivered to the business and aligned to their expectation. The Supplier and Contracts Database (SCD) records all details about suppliers, contracts, and the type of service or products provided by each supplier.
5-28
Supplier Management Process
5-29
Supplier Management Interfaces

Supplier Management Interfaces

IT Service Continuity Management Service Level Management Information Security Management Financial Management Service Portfolio Management Problem and Incident Management
21
Events that could trigger Supplier Management activity include: New or changed corporate governance guidelines New or changed business and IT strategies, policies, or plans New or changed business needs, or new or changed services New or changed requirements within agreements, such as SLRs, SLAs, OLAs, or contracts Review and revision of designs and strategies Periodic activities such as reviewing, revising, or reporting, including review and revision Supplier Management policies, reports, and plans Requests from other areas, particularly SLM and Security Management for assistance with supplier issues Requirements for new contracts, contract renewals, or contract terminations Recategorization of suppliers and or contracts
5-30
The key interfaces that Supplier Management with other processes are: IT Service Continuity Management (ITSCM): With regard to the management of continuity service supplier. SLM: Assistance with the determining of targets, requirements, and responsibilities. Their inclusion within underpinning agreements and contracts to ensure that they support all SLR and SLA targets. Also the investigation of SLA and SLR breaches caused by poor supplier performance. ISM: In the management of suppliers and their access to service and systems and their responsibilities with regards to conformance to ISM policies and requirements. Financial Management: To provide adequate funds required to finance Supplier Management requirements and contracts and to provide advice and guidance on purchase and procurement matters. Service Portfolio Management: To ensure that all supporting services and their details and relationships are accurately reflected within the Service Portfolio.
5-31
Unit 5: Processes Service Asset Configuration Management and Release Management
Lesson 5: Service Asset Configuration Management and Release Management

Service Asset and Configuration Management
Service Asset and Configuration Management (SACM)

Service Asset and Configuration Management (SACM) provides a logical model of the IT infrastructure SACM correlates IT services and different IT components (physical, logical, and so forth) needed to deliver services SACM defines and controls the components of services and infrastructure and maintaining accurate configuration records Service Asset and Configuration Management improves the service performance and optimizes the costs caused by poorly managed assets, for example:
Service outages Fines Correct license fees Failed audits
22
Service Asset and Configuration Management (SACM) is used for the following reasons: To protect the integrity of service assets and configuration items (and where appropriate, those of its customers) through the Service Lifecycle To place IT assets and designated configuration items within the Service Lifecycle under configuration management To ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining and accurate a complete Configuration Management system To support efficient and effective business and service management processes by providing accurate information about assets and configuration items.
5-32
The goal of Service Asset and Configuration Management is to provide a logical model of the IT infrastructure correlating IT services and different IT components (physical, logical, and so on) needed to deliver these services by defining and controlling the components of services and infrastructure and maintaining accurate configuration records. This goal enables an organization to: Comply with corporate governance requirements Control the asset base Optimize the costs Manage change and releases effectively Resolve incidents and problems faster
Service Asset and Configuration Management optimizes the performance of service assets and configurations, improves the overall service performance, and optimizes the costs and risks caused by poorly managed assets. Such assets include service outages, fines, correct licence fees, and failed audits. SACM provides visibility of accurate representations of a service, release, or environment that enable the following events to occur: Better forecasting and planning of changes Changes and releases to be assessed, planned, and delivered successfully Incidents and problems to be resolved within the service level targets Warranties to be delivered Better adherence to standards, legal, and regulatory obligations (fewer nonconformances) More business opportunities because of ability to demonstrate control of assets and services Changes to be traceable from requirements New ability to identify the costs for a service
5-33
SACMThe Logical Model

SACMThe Logical Model

Configuration Management delivers a required logical model of the services, assets, and the infrastructure by recording the relationships between configuration items The logical model of Configuration Management is a single common representation used by all parts of IT Service management, and beyond, such as HR, Finance, supplier, and customers The Configuration Items and related configuration information can be at varying levels of detail, for example:
An overview of all the services A detailed level to view the specification for a service component
23
Configuration Management delivers a required logical model of the services, assets, and the infrastructure by recording the relationships between configuration items. The real power of the logical model of the infrastructure of configuration management is that it is the main model. It is a single common representation used by all parts of IT Service Management, and beyond, such as Human Resources, Finance, supplier, and customers. The configuration items and related configuration information can be at varying levels of detail. Examples would be an overview of all the services or a detailed level to view the specification for a service component. A more detailed level of Configuration Management should be used when the service provider requires tight control, traceability, and tight coupling of configuration information through the Service Lifecycle.
5-34
Configuration Items
Configuration Items
A Configuration Item (CI) is an asset, service component, or other item which is, or will be, under the control of configuration management Configuration Items can vary widely in complexity, size, and type
CIs can be an entire service or system including all hardware, software, documentation, and support staff CIs can also be a single software module or a minor hardware component
Configuration Items can be grouped and managed together, for example, a set of components grouped into a release
24
A Configuration Item (CI) is an asset, service component or other item which is, or will be, under the control of configuration management. Configuration Items can vary widely in complexity, size, and type. They can include an entire service or system, including all hardware, software, documentation, and support staff. A CI can also be a single software module or a minor hardware component. Configuration Items can be grouped and managed together. An example would be a set of components grouped into a release. Configuration Items should be selected using established selection criteria. They should be grouped, classified, and identified in such a way that they can be managed and traced throughout the Service Life Cycle. There will be a variety of CIs; the following categories can help identify them: Service Lifecycle CIs: These CIs include the business case, Service Management plans, Service Lifecycle plans, Service Design Package, Release and Change plans, Test plans. They provide a picture of the services of the service provider, how these services will be delivered, what benefits are expected, at what cost, and when they will be realized. Service CIs include: Service capability assets (management, organization, processes, knowledge, people) Service resource assets (financial capital, systems, applications, information, data, infrastructure and facilities, financial capital, people)
5-35
Service Model Service Package Release Package Service Acceptance Criteria
Organization CIs: Some documentation will define the characteristics of a CI whereas other documentation will be a separate CI and need to be controlled. An example would be the business strategy of the organization or other policies that are internal to the organization but independent of the service provider. Regulatory or statutory requirements also form external products that need to be tracked, as do products shared between more than one group. Internal CIs: CIs delivered by individual projects, including tangible assets such as a data center and intangible assets such as software, that are required to deliver and maintain the service and infrastructure. External CIs: External customer requirements and agreements, releases from suppliers or subcontractors, and external services.
5-36
Service Asset and Configuration Management (SACM) Interfaces

Service Asset and Configuration Management (SACM) Interfaces

Change Management Financial management IT Service Continuity Management Problem and Incident Management Availability Management
25
SACM is the single virtual repository of data and information for IT service management. Consequently, SACM supports and interfaces with every other process and activity to some degree. Some of the more noteworthy interfaces are as follows: Change Management: Identifying impact of proposed changes. Financial Management: Capturing key financial information such as cost, depreciation methods, owner, and user (for budgeting and cost allocation), maintenance and repair costs. IT Service Continuity Management (ITSCM): Awareness of assets the business services depend on, control of key spares and software. Incident, Problem, or Error Management: Providing and maintaining key diagnostic information, maintenance and provision of data to Service Desk. Availability Management: Detecting of points of failure. Configuration Control (synonymous with change control): Understanding and capturing updates to the infrastructure and services.
5-37
Release and Deployment Management

Release and Deployment Management

Release and Deployment Management deploys releases into production and enables effective use of the service in order to deliver value to the customer A Release Unit describes the portion of a service or IT infrastructure that is normally released together according to the release policy of the organization The unit can vary, depending on the types or items of service asset or service component, such as software and hardware Releases should be uniquely identified according to a scheme defined in the Release policy
26
The goals of release and deployment management are: To deploy releases into production To enable effective use of the service to deliver value to the customer
Well-planned and implemented release and deployment makes a significant difference to the service costs of an organization. A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. At worst, it can cripple the environment and degrade the live services. A release unit describes the portion of a service or it infrastructure that is normally released together according to the release policy of the organization. The unit can vary, depending on the types or items of service asset or service component such as software and hardware. The general aim is to decide upon the most appropriate release-unit level for each service asset or component. An organization might, for example, decide that the release unit for business critical applications is the complete application. Such a decision would ensure that testing is comprehensive. The same organization might decide that a more appropriate release unit for a Web site is at the page level.
5-38
Factors to Consider for Release Units

Factors to Consider for Release Units

The ease and amount of Change necessary to release and deploy a Release unit The amount of resources and time needed to build, test, distribute, and implement a Release unit The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure The storage available in the build, test, distribution, and live environments
27
Factors to consider for release units include: The ease and amount of change necessary to release and deploy a Release unit The amount of resources and time needed to build, test, distribute, and implement a release unit The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure The storage available in the build, test, distribution, and live environments
Releases should be uniquely identified according to a scheme defined in the release policy. The release identification should include a reference to the CIs that it represents and a version number that will often have two or three parts. An example would be emergency fix releases: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.
5-39
Release Management Process

Release Management Process

Begins with receipt of an approved RFC to deploy a release package Deployment commences with receipt of an approved RFC to deploy a Release Package to a target deployment group Deployment is completed with a handover of the new or changes service to Operations
28
The release process begins with receipt of an approved RFC to deploy a production-ready Release Package. Deployment begins with receipt of an approved RFC to deploy a Release Package to a target deployment group or environment. Examples include a business unit, customer group, or service unit. Deployment is completed with a transfer of the new or changed service to Operations. This transfer occurs when Change Management successfully completes a Post Implementation Review of the deployment.
5-40
Unit 5: Processes Event Management and Request Fulfilment
Lesson 6: Event Management and Request Fulfilment

Event Management
Event Management
An Event is any detectable or discernable occurrence that has significance for the management of the IT infrastructure or the delivery of IT service and evaluation of the impact a deviation might cause to the services Events are typically notifications created by an IT Service, Configuration Item (CI) or monitoring tool Active monitoring tools poll key CIs to determine their status and availability Passive monitoring tools detect and correlate operational alerts or communications generated by CIs Event Management provides the entry point for the execution of many Service Operation processes and activities
29
An Event can be defined as any detectable or discernible occurrence that has significance for: Management of the IT infrastructure or the delivery of IT service Evaluation of the impact a deviation might cause to the services
Events are typically notifications created by an IT Service, Configuration Item (CI), or monitoring tool.
5-41
Effective Service Operation depends on knowing the status of the infrastructure and detecting any deviation from normal or expected operation. This knowledge is provided by good monitoring and control systems, which are based on two types of tools: Active monitoring tools that poll key CIs to determine their status and availability. Any exceptions will generate an alert that needs to be communicated to the appropriate tool or team for action. Passive monitoring tools that detect and correlate operational alerts or communications generated by CIs.
Event Management provides the ability to detect Events, make sense of them, and determine the appropriate control action. Event Management is therefore the basis for Operational Monitoring and Control. These events can also be programmed to communicate operational information as well as warnings and exceptions. In such cases, they can be used as a basis for automating many routine Operations Management activities. Some examples of Event Management include: Executing scripts on remote devices Submitting jobs for processing Dynamically balancing the demand for a service across multiple devices to enhance performance
Event Management provides the following functions: The entry point for the execution of many Service Operation processes and activities A method of comparing actual performance and behavior, against design standards and Service Level Agreements A basis for Service Assurance and Reporting, as well as Service Improvement
5-42
Event Management Process
There are many different types of Events, for example: Events that signify regular operation: Notification that a scheduled workload has completed A user has logged in to use an application An e-mail has reached its intended recipient
Events that signify an exception: A user attempts to log on to an application with the incorrect password An unusual situation has occurred in a business process that might indicate an exception requiring further business investigation (for example, a Web page alert indicates that a payment authorization site is unavailable which affects financial approval of business transactions) A CPU of a device is above the acceptable utilization rate A PC scan reveals the installation of unauthorized software
Events that signify unusual, but not exceptional, operation. These indicate that the situation might require closer monitoring. In some cases the condition will resolve itself. An example would be an unusual combination of workloads. As the workloads are completed, normal operation is restored. In other cases, operator
5-43
intervention might be required if the situation is repeated or if it continues for too long. These rules or policies are defined in the monitoring and control objectives for that device or service. Examples of this type of event are: The memory utilization of a server reaches within 5% of its highest acceptable performance level The completion time of a transaction is 10% longer than normal
Two things are significant about the previous examples: There is no definitive rule about exactly what constitutes normal operation, unusual operation, or an exception. For example, a manufacturer might provide a benchmark of 75% memory utilization is optimal for application X. However, it is discovered that under the specific conditions of the organization, response times begin to degrade above 70% utilization. Each example relies on the sending and receipt of a message of some type. These are generally referred to as Event Notifications, and they do not happen on their own. The next section will explore exactly how Events are defined, generated, and captured.
5-44
Event Management Interfaces

Event Management Interfaces

Incident and Problem Management Change Management Capacity and Availability Management Configuration Management Asset Management
31
Event Management can be initiated by any type of occurrence. The key is to define which of these occurrences is significant and which need to be acted upon. Triggers include: Exceptions to any level of CI performance defined in the Design specifications, Operational Level Agreements or Standard Operating Procedures Exceptions to an automated procedure or processthat is, a routine Change that has been assigned to a build team has not been completed in time An exception within a business process that is being monitored by Event Management The completion of an automated task or job A status change in a device or database record Access of an application or database by a user or automated procedure or job A situation where a device, database, or application, and so on has reached a predefined threshold of performance
Event Management can interface any process that requires monitoring and control. Those processes that do not require real-time monitoring, but which do require some form of intervention following an Event or group of Events, are especially benefitted.

5-45
The primary IT Service Management (ITSM) relationships are with Incident Management, Problem Management, and Change Management. Capacity Management and Availability Management are critical in defining which Events are significant, what appropriate thresholds should be, and how to respond to them. In return, Event Management will improve the performance and availability of services by: Responding to Events when they occur Reporting on actual Events and patterns of Events to determine (by comparison to SLA targets and KPIs) if some aspect of the infrastructure design or operation can be improved
Configuration Management is able to use Events to determine the current status of any CI in the infrastructure. Comparing Events with the authorized baselines in the Configuration Management System (CMS) will help discover any unauthorized activity in the organizations. Asset Management (covered in more detail in the Service Design and Transition books) can use Event Management to determine the lifecycle status of assets. For example, an Event could be generated to signal that a new asset has been successfully configured and is now operational. Events can be a rich source of information that can be processed for inclusion in Knowledge Management systems. For example, patterns of performance can be correlated with business activity and used as input into future design and strategy decisions. Event Management can help detect potential impact on SLAs early and ensure that any failures are rectified as soon as possible, minimizing impact on service targets.
5-46
Request Fulfilment
Request Fulfillment
Request fulfillment is the process of dealing with service requests from the users Service Requests are a generic description for varying types of demands that are placed upon the IT department by the users Service Requests are typically small changes that are low risk, frequently occurring, low cost and so forth. Examples:
A request to change a password A request to install an additional software application onto a particular workstation A request to relocate some items of desktop equipment
The scale and frequent, low risk nature of Service Requests mean that they are better handled by a process separate from Change Management or Incident Management
32
The term service request is used as a generic description for varying types of demands that are placed upon the IT department by the users. Many of these demands are actually small changes that are low risk, frequently occurring, low cost, and so forth. Examples include the following requests: To change a password To install an additional software application onto a particular workstation To relocate some items of desktop equipment For information
Their scale and frequent, low-risk nature means that they are better handled by a separate process. Otherwise, they might congest and obstruct the normal incident and change management processes. Request Fulfilment is the processes of dealing with service requests from the users. The objectives of request fulfilment process include: To provide a channel for users to request and receive standard services for which a predefined approval and qualification process exists
5-47
To provide information to users and customers about the availability of services and the procedure for obtaining them To source and deliver the components of requested standard services (for example, licenses and software media) To assist with general information, complaints, or comments
The value of Request Fulfilment is to provide quick and effective access to standard services. Business staff can use these services to improve their productivity or the quality of business services and products. Request Fulfilment effectively reduces the bureaucracy involved in requesting and receiving access to existing or new services. The cost of providing these services is also reduced. Centralizing fulfilment also increases the level of control over these services. This control in turn can help reduce costs through centralized negotiation with suppliers. It can also help to reduce the cost of support.
5-48
Summary
Summary
Outline the four main activities in the Service Strategy process State the objectives, business value, basic concepts, and interfaces for Service Portfolio Management (SPM) and Service Design State the objectives, business value, basic concepts, and interfaces for Service Catalog Management, Information Security Management (ISM), and Supplier Management State the objectives, business value, basic concepts, and interfaces for Service Asset and Configuration Management (SACM), Release and Deployment Management, Service Operation Explain the high level objectives, scope, business value, basic concepts, process activities, interfaces, key metrics, and challenges for Event Management and Request Fulfilment
34
5-49
5-50
Unit 6: Functions
Unit 6: Functions
6-1
Unit 6: Functions
Introduction
This unit explains the role, objectives, organizational structures, staffing, and metrics of the Service Desk function. It also explains the role, objectives, and overlap of the functions of Technical Management, Application Management, and IT Operations Management.
Objectives
Objectives
Describe the role and objectives of the Technical Management function Describe the role and objectives and of the Application Management function Describe the role and objectives of the IT Operations Management function (IT Operations Control and Facilities Management)
6-2
Unit 6: Functions Technical, Applications, and Operational Management
Lesson 1: Technical, Applications, and Operational Management

Technical Management
Technical Management
Technical Management ensures that the knowledge required to design, test, manage, and improve IT services is identified, developed, and refined Technical Management ensures that resources are effectively trained and deployed to design, build, transition, operate, and improve the technology required to deliver and support IT Services
Technical Management performs a dual role: It is the custodian of technical knowledge and expertise related to managing the IT Infrastructure. In this role Technical Management ensures that the knowledge required to design, test, manage, and improve IT services is identified, developed, and refined. It provides the actual resources to support the IT Service Management Lifecycle. In this role Technical Management ensures that resources are effectively trained and deployed to design, build, change, operate, and improve the technology required to deliver and support IT services.
6-3
By performing these two roles, Technical Management can ensure that: The organization has access to the right type and level of human resources to manage technology The organization can therefore meet business objectives.
Part of this role is also to ensure a balance between the skill level, usage, and the cost of these resources. An additional but important role played by Technical Management is to provide guidance to IT Operations regarding how best to maintain the ongoing operational management of technology.
6-4
Technical Management Objectives

Technical Management Objectives

The objectives of Technical Management helps plan, implement, and maintain a stable technical infrastructure Technical management ensures well-designed, highly resilient, cost-effective technical topology Maintains technical skills to maintain the technical infrastructure in optimum condition Ensures swift use of technical skills to quickly diagnose and resolve any technical failures that do occur
The objectives of Technical Management are to help plan, implement, and maintain a stable technical infrastructure to support the business processes of the organization through: Well-designed, highly resilient, cost-effective technical topology Adequate technical skills to maintain the technical infrastructure in optimum condition The swift use of technical skills to quickly diagnose and resolve any technical failures that do occur
6-5
Application Management
Application Management
Application Management is to applications what Technical Management is to the IT Infrastructure One of the key decisions to which Application Management contributes is the decision of whether to buy an application or build it
Application Management is to applications what Technical Management is to the IT Infrastructure. Application Management plays a role in all applications, whether purchased or developed in-house. One of the key decisions to which Application Management contributes is the decision of whether to buy an application or build it. After that decision is made, Application Management performs a dual role. The first role, Application Management, is the custodian of technical knowledge and expertise related to managing applications. In this role Application Management, working with Technical Management, ensures that the knowledge required to design, test, manage, and improve IT services is identified, developed, and refined. The second role, Application Management, provides the actual resources to support the IT Service Management Lifecycle. In this role Application Management ensures that resources are effectively trained and deployed to design, build, change, operate, and improve the technology required to deliver and support IT services.
By performing these two roles, Application Management is able to ensure that the organization has access to the right type and level of human resources to manage applications and is therefore able to meet business objectives. This function starts in Service Strategy, expands in Service Design, is tested in Service Transition, and is refined in Continual Service Improvement.

6-6
Application Management Objectives

Application Management Objectives

The objective of Applications Management is to build Applications that are well designed, resilient, and cost-effective Assure that the required functionality is available to achieve the required business outcome Verify the organization has adequate technical skills to maintain operational applications in optimum condition Use technical skills to quickly diagnose and resolve any technical failures that do occur
The objectives of Application Management are to support the business processes of the organization by helping to identify functional and manageability requirements for application software. The next objectives are to assist in the design and deployment of those applications and the ongoing support and improvement of those applications. These objectives are achieved through the following items: Applications that are well-designed, resilient, and cost-effective The assurance that the necessary functionality is available to achieve the required business outcome The organization of adequate technical skills to maintain operational applications in optimum condition Swift use of technical skills to quickly diagnose and resolve any technical failures that do occur
6-7
IT Operations Control and Facilities Management Role

IT Operations Control and Facilities Management

Operations Control, which oversees the execution and monitoring of the operational activities and events in the IT Infrastructure Facilities Management, which refers to the management of the physical IT environment, typically a data center or computer rooms, and recovery sites together with all the power and cooling equipment IT Operations is concerned with ensuring the stability of the IT infrastructure and consistency of IT Services
The role of Operations Management is to implement the ongoing activities and procedures required to manage and maintain the IT infrastructure in order to deliver and support IT services at the agreed-upon levels. These activities include: Operations Control, which oversees implementing and monitoring of IT infrastructure operational activities and events. An Operations Bridge or Network Operations Center can assist with this activity. Console Management, which refers to defining central observation and monitoring capability and then using those consoles to monitor and control activities. Facilities Management, which refers to the management of the physical IT environment. This environment is typically a data center or computer rooms and recovery sites together with all the power and cooling equipment. Facilities Management also includes the coordination of large-scale consolidation projects, for example, data center consolidation or server consolidation projects. IT Operations Management is responsible primarily for maintaining existing stability. The stability of the IT infrastructure and consistency of IT services is a primary concern of IT Operations. IT Operations Management must be able to continually adapt to and keep pace with business requirements and demand. IT Operations Management can challenge current methods and ways of thinking.
6-8
IT Operations Control and Facilities Management Objectives

IT Operations Management Objectives

Maintenance to maintain stability of the day-to-day processes and activities of the organization Regular scrutiny and improvements to achieve improved service at reduced costs, while maintaining stability Swift application of operational skills to diagnose and resolve any IT operations failures that occur
The objectives of IT Operations Management include: Daily maintenance to sustain stability of the day-to-day processes and activities of the organization Regular scrutiny and improvements to achieve improved service at reduced costs, while maintaining stability Swift application of operational skills to diagnose and resolve any IT operations failures that occur
6-9
Summary
Summary
Describe the role and objectives of the Technical Management function Describe the role and objectives and of the Application Management function Describe the role and objectives of the IT Operations Management function (IT Operations Control and Facilities Management)
6-10

Itilv3diff SG 2741-01

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Itilv3diff SG 2741-01

Enviado por

Direitos autorais:

Formatos disponíveis

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Students Training Guide

Unit 2: The Service Lifecycle

Lesson 2: Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-5

Lesson 3: Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-9

Lesson 4: Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-11

Lesson 5: Service Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-14

Lesson 6: Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . .2-17

Unit 3: ITIL Key Concepts

Unit 4: Key Principles and Models

Lesson 1: Service Strategy and the Service Portfolio . . . . . . . . . . . . . . . . . . .5-3

Lesson 2: Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16

Lesson 3: Information Security Management . . . . . . . . . . . . . . . . . . . . . . . . .5-20

Lesson 4: Supplier Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28

Lesson 5: Service Asset Configuration Management and Release Management 5-32

Lesson 6: Event Management and Request Fulfilment . . . . . . . . . . . . . . . . .5-41

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Copyright IBM Corp. 2007

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

2007 IBM Corporation

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Bold Italics Monospace

Copyright IBM Corp. 2007

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Unit 1: ITIL Overview

Unit 1: Information Technology Infrastructure Library (ITIL) Overview

2007 IBM Corporation

Unit 1: ITIL Overview

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Unit 1: ITIL Overview

History of Information Technology Infrastructure Library (ITIL)

History of Information Technology Infrastructure Library (ITIL)

Copyright IBM Corp. 2007

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Unit 1: ITIL Overview

Information Technology Infrastructure Library

Information Technology Infrastructure Library

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Unit 1: ITIL Overview

ITIL Version 3 Publications Framework

Copyright IBM Corp. 2007

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Unit 1: ITIL Overview

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Unit 1: ITIL Overview

Copyright IBM Corp. 2007

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Unit 1: ITIL Overview

IT Infrastructure Library (ITIL) Foundations Version 2 to Version 3 Differences

Copyright IBM Corp. 2007

Unit 1: ITIL Overview