itil book from ibm, it service management

IT Infrastructure Library (ITIL) Foundations v3Student’s Training GuideS150-3100-00

April 2009

Copyright NoticeCopyright © 2009 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 Soft-ware 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 Corpora-tion. 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 writ-ten 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 Users—Documentation related to restricted rights—Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.

TrademarksThe 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 Den-mark, Tivoli is a trademark licensed from Kjøbenhavns 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 fur-ther information, see http://www.setco.org/aboutmark.html.Other company, product, and service names may be trademarks or service marks of others.

NoticesReferences 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 prod-ucts, programs, or services can be used. Subject to valid intellectual property or other legally pro-tectable 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.

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 I

• • •••

Table of Contents

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Table of Contents

Preface Course Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIVAudience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIVIBM Tivoli Technical Education . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIVTivoli User Group Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVCourse Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVCourse Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVTypographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVIIProduct Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

Unit 1: ITIL OverviewIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Lesson 1: History of ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-3History of ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Information Technology Infrastructure Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5Contents of the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6Components of the ITIL Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7ITIL Version 3 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8Summary of the Service Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9ITIL Qualifications Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

Lesson 2: Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-13Service Management as a Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16

Lesson 3: Process and Service Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-17Process Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18Service Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19

Lesson 4: Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-20Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21Characteristics of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22Generic Process Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23Process Elements for ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24ITIL Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25The Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26

Lesson 5: Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-27Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28

Lesson 6: Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-29Roles Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30

Lesson 7: Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-31Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32Phases of Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33

Lesson 8: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-34Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35

II IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Table of Contents


Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39

Unit 2: Service StrategyIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Lesson 1: Service Strategy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-3Service Strategy Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Purpose of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Service Strategy Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Service Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7Business Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8Elements of Value: Utility and Warranty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9The Four Ps of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10Service Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Lesson 2: Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Service Providers 2-14Internal Service Provider (Type I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15Internal Service Provider (Type I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16Shared Services Provider (Type II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17Shared Services Provider (Type II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18Shared Services Provider (Type III) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19Shared Services Provider (Type III) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20Choosing Service Provider Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21Sourcing Approaches and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23

Lesson 3: The Process of Strategy Generation . . . . . . . . . . . . . . . . . . . . . . .2-25Strategy Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26Main Activities of Service Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27Defining the Market: Market Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28Expansion, Growth, and Differentiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30Develop the Offerings and Strategic Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32Increasing Service and Performance Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34Strategic Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-36Setting Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37Defining Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38Strategy Generation, Evaluation, and Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39Measurement and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40Strategy Generation Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41

IT Steering Group (ISG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41Service Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41Service Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-41Requirements Requester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42Service Design Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42

Lesson 4: The Process of Service Portfolio Management . . . . . . . . . . . . . . .2-43Service Portfolio Management (SPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44Service Portfolio Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45Service Portfolio Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-47Service Portfolio Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-48Service Portfolio Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49

Define . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-49Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50Approve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-50

Service Portfolio Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51Service Portfolio Process Manager (Service Portfolio Manager) . . . . . . . . . . . . . . . . . . . . 2-51

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 III

• • •••

Table of Contents


Service Portfolio Process Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51Service Portfolio Management Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-51Service Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-52

Lesson 5: The Process of Financial Management . . . . . . . . . . . . . . . . . . . . .2-53Financial Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-54Financial Management Goals and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-55Financial Management Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-56Financial Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-57Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-58Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-59Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-61Implement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-62Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-63Financial Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64

Service Valuation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-64Demand Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65Service Provisioning and Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65Planning Confidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65Service Investment Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-65Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-66Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-66Variable Cost Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-67

Financial Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68Financial Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68IT Financial Administrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-68

Lesson 6: The Process of Demand Management . . . . . . . . . . . . . . . . . . . . .2-69Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-70Activity-based Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-71Demand Management Goal and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-72Demand Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73Demand Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-74

Lesson 7: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-75Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-76Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-78Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-79

Unit 3: Service DesignIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Lesson 1: Service Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3Service Design Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Five Major Aspects of Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5Service Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6Service Management: The 4 Ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8Service Design Package (SDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9Contents of SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10The RACI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-11RACI-VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12Technology Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14

Lesson 2: Process of Service Catalog Management . . . . . . . . . . . . . . . . . . .3-16Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17Service Catalog Management Goal and Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19Service Catalog Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20Service Catalog Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

IV IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Table of Contents


Service Catalog Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22Service Catalog Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23Service Catalog Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25SCM Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26Service Catalog Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28

Lesson 3: Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29Service Level Management (SLM) Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30Service Level Agreements, Operational Level Agreements, and Underpinning Contracts . . . 3-32Service Level Agreements, Operational Level Agreements, and Underpinning Contracts . . . 3-33Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34Operational Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-36Underpinning Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-37Service Level Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38SLM Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-39SLM Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40SLM Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41Service Level Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42Service Level Management Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44Service Level Management Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45SLM: Key Performance Indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47SLM Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49Service Level Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

Lesson 4: Process of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . .3-52Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53Purpose and Goals of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-54Capacity Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56Benefits of Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57Capacity Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-58Modeling and Trending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60

Baselining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60Trend Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60Analytical Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61Simulation Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61Application Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-61

Capacity Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62Capacity Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63Capacity Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-64Capacity Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . 3-65Capacity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67

Lesson 5: Process of Availability Management . . . . . . . . . . . . . . . . . . . . . . .3-68Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-69Availability, Reliability, Maintainability, and Serviceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71Proactive Versus Reactive Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72Availability Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-73Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75Availability Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-76Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-77Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78Other Availability Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-79Availability Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-80Availability Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-81Availability Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-82Availability Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-83Availability Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-84Availability Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-85Availability Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-86Availability Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-87

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 V

• • •••

Table of Contents


Availability Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . 3-89Availability Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-91

Lesson 6: Process of IT Service Continuity Management . . . . . . . . . . . . . . .3-92IT Service Continuity Management Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93ITSCM Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94IT Service Continuity Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-95ITSCM Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-96ITSCM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-99ITSCM Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101ITSCM Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-102ITSCM KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-103ITSCM Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-105Service Continuity Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-107

Lesson 7: Process of Information Security Management . . . . . . . . . . . . . . .3-109Information Security Management (ISM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-110Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-111Contents of the Information Security Policy (ITP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-112Information Security Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-114Information Security Management Goal and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-115Information Security Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-116Information Security Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117Information Security Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-118Information Security Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-120Information Security Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121Information Security Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-122ISM Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-123Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-125

Lesson 8: Process of Supplier Management . . . . . . . . . . . . . . . . . . . . . . . .3-126Supplier Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-127Supplier Management Goal and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-128Supplier Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129Supplier Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-130Supplier Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131Supplier Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-133Supplier Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-135Supplier Management Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-136Supplier Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-137Supplier Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . 3-138Supplier Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140

Lesson 9: Service Design Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-142IT Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143Service Design Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-144

Lesson 10: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-146Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-148Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-152Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-154

Unit 4: Service TransitionIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

Lesson 1: Service Transition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3Service Transition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4Service Transition Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5Value of Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

VI IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Table of Contents


Service Knowledge Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-8SKMS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-9Service Transition Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-10Service Transition Lifecycle Stages Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-11Technology Considerations for Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12

Knowledge Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12Configuration Management System (CMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-13

Lesson 2: Process of Transition Planning and Support . . . . . . . . . . . . . . . . .4-14Transition Planning and Support Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-15Transition Planning and Support Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-16Transition Planning and Support Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17Service Transition Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-18Transition Planning and Support Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20Transition Planning and Support Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21

Define Transition Strategy and Lifecycle Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-21Prepare for Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22Plan and Coordinate Service Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22

Transition Planning and Support Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24Transition Planning and Support KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-25Transition Planning and Support Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-26

Lesson 3: Process of Change Management . . . . . . . . . . . . . . . . . . . . . . . . .4-28Change Management Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-30Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-31Change Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-32Change Types: Normal Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-33Change Types: Standard Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34Change Types: Emergency Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-36Release Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-37Seven Rs of Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-38Change Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-39Change Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-41Policies Supporting Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-42Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-43Change Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44Change Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46Change Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-48Change Management Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-50Change Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-52Change Advisory Board (CAB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-53

Lesson 4: Process of Service Asset and Configuration Management . . . . . .4-54Service Asset and Configuration Management Purpose and Goal . . . . . . . . . . . . . . . . . . . . . 4-55SACM, the Logical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-57Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-58Types of Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-59Configuration Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-61Definitive Media Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-62Configuration Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-63SACM Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-64SACM Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-65SACM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-67SACM Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-68SACM Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-69Service Asset Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-70Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-71Configuration Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-72Configuration Administrator or Librarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-73

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 VII

• • •••

Table of Contents


Lesson 5: Process of Release and Deployment Management . . . . . . . . . . . .4-74Release and Deployment Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-75Release and Deployment Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-76Release Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-77Factors to Consider for Release Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-78Release and Deployment Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-79Release and Deployment Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-80Service V Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-82Release and Deployment Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . 4-83Release and Deployment Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-85Release and Deployment Management Challenges, Success Factors, and Risks . . . . . . . . . 4-86Release Packaging and Build Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-88Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-90

Lesson 6: Process of Service Validation and Testing . . . . . . . . . . . . . . . . . .4-91Service Validation and Testing Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-92Objectives of Service Validation and Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-93Service Validation and Testing Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-94Service Validation and Testing Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-95Service Validation and Testing Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-97Service Validation and Testing Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-98Service Validation and Testing KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-99Service Validation and Testing Challenges, Critical Success Factors, and Risks . . . . . . . . . 4-100Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-102

Lesson 7: Process of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-103Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-104Objectives of Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-105Evaluation Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-106Evaluation Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-107Evaluation Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-108Evaluation KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-109Evaluation Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-110Performance and Risk Evaluation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-111

Lesson 8: Process of Knowledge Management . . . . . . . . . . . . . . . . . . . . . .4-112Knowledge Management Purpose and Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-113Knowledge Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-114Knowledge Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-115DIKW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-116Knowledge Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-117Knowledge Management Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-120

Service Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-120Operations Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-120Transition Staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-121

Knowledge Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-122Knowledge Management Process Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-123

Lesson 9: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-124Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-126Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-130Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-132

Unit 5: Service OperationIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Lesson 1: Service Operation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4

VIII IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Table of Contents


Service Operation Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5Service Operation Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6Service Operation Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7Conflicting Motives in Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8External View of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9Internal View of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10Stability Versus Responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11Balancing Service Cost and Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12Service Operation: Reactive versus Proactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13Communication in Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14Technology Considerations for Service Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15

Technology for Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Technology for Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Technology Tools for Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Technology Tools for Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Technology Tools for Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16Technology Tools for Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-17

Lesson 2: Process of Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18Event Management Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19Event Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-21Event Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23Event Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24Event Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26Event Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28Event Management Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . . 5-29Event Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-31

Lesson 3: Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-32Incidents Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-33Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-34Incident Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-35Incident Management Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36

Time Scales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36Incident Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-36Major Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37The Role of Problem Management in Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-37

Incident Management Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-38Incident Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-40Incident Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-41Incident Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-42Incident Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-44Incident Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-45Urgency, Impact, and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-46Diagnosis and Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-47Incident Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49

Functional Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-49Hierarchic Escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-50

Incident Resolution, Recovery, and Closure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-51Incident Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-53Incident Management Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-55Incident Management Key Performance Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-57Incident Management Challenges, Success Factors, and Risks . . . . . . . . . . . . . . . . . . . . . . . 5-59Incident Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-60

Lesson 4: Process of Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . .5-61Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-62Service Request Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-64Request Fulfillment Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-65Request Fulfillment Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-66

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 IX

• • •••

Table of Contents


Request Fulfillment Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-67Request Fulfillment Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-68Request Fulfillment Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-69Request Fulfillment KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-71Request Fulfillment Challenges, Critical Success Factors, and Risks . . . . . . . . . . . . . . . . . . . 5-72Request Fulfillment Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-74

Lesson 5: Process of Problem Management . . . . . . . . . . . . . . . . . . . . . . . . .5-75Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-76Problem Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-78Workaround . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-80Known Error Data Base (KEDB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-81Reactive versus Proactive Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-82Problem Management Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-83Problem Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-84Problem Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-85Problem Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-86Problem Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-88Problem Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-90Problem Management Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-91Problem Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-92

Lesson 6: Process of Access Management . . . . . . . . . . . . . . . . . . . . . . . . . .5-93Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-94Access Management Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-95Access Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-96Access Management Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-97Access Management Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-98Access Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-100Access Management KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-102Access Management Critical Success Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-103Access Management Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-104

Lesson 7: The Service Desk Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-105Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-106Service Desk Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-108The Service Desk Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-109Service Desk Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-110

Local Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-110Centralized Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-110Virtual Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-111Follow-the-Sun Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-111

Service Desk Organizational Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-112Service Desk Staffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-113Service Desk Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-115

Lesson 8: Technical Management, Applications Management, and Operations Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-116

Technical Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-117Technical Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-118Application Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-119Application Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-121Operations Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-122Operations Management Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-123

Lesson 9: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-124Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-126Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-130Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-132

X IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Table of Contents


Unit 6: Continual Service ImprovementIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

Lesson 1: Continual Service Improvement Overview . . . . . . . . . . . . . . . . . . . .6-3Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4Continual Service Improvement (CSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5CSI Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6Benefits of Continual Service Improvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7Business and Customer Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-8Financial Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9IT Organization Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10CSI Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11Metrics and Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12CSI Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Continual Service Improvement Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14The Deming Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15The Deming Cycle and CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16The Deming Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17CSI: Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18Technology Considerations for CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19

Lesson 2: The 7-Step Improvement Process . . . . . . . . . . . . . . . . . . . . . . . . .6-21The 7-Step Improvement Process Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-227-Step Improvement Process Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24CSI Critical Success Factors and KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-267-Step Improvement Process Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27

Lesson 3: Process of Service Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-29Aspects of Service Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-30Implementing Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31Content and Audience Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32Service Reporting Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-33Service Reporting Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-34Reporting Analyst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-35

Lesson 4: Process of Service Measurement . . . . . . . . . . . . . . . . . . . . . . . . .6-36Service Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-37Measurements for CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-39Types of Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-40Service Measurement Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-41Service Measurement Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-42

Lesson 5: Process of Creating a Return on Investment . . . . . . . . . . . . . . . . .6-45Return on Investment for CSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-46Return on Investment Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-47

Lesson 6: Continual Service Improvement Roles . . . . . . . . . . . . . . . . . . . . . .6-49Service Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-50Continual Service Improvement Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-51

Lesson 7: Unit Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-52Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-55Review Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-56Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-57

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 XI

• • •••

Table of Contents


Appendix A: ITIL GlossaryITIL V3 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

Appendix B: ITIL V3 Practice ExaminationPractice Examination Answer Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-7

Tivoli Professional Certification Special Offer for Having Taken This Course . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IReasons for Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IRole-based Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IWhen to Attempt a Certification Exam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IILocation and Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IISources of Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II

XII IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Table of Contents


• • • ••

XIII

Preface

© 20 08 IBM Corporation

Student Guide

XIV IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

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.

The purpose of the ITIL Foundation certificate in IT Service Management is to obtain knowledge of the ITIL terminology, structure, and basic concepts and 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 require a basic understanding of the ITIL framework and how it may be used to enhance the quality of IT service management within an organization.

• IT professionals who are working within an organization that has adopted and adapted ITIL and who need to be informed about and thereafter contribute to an ongoing service improvement program.

The target group may include, but is not limited to, IT professionals, business managers, and business process owners.

IBM Tivoli Technical Education

The latest information about IBM Tivoli education offerings can be found online at:

http://www.ibm.com/software/tivoli/education/

Also, if you have any questions about education offerings, send an e-mail to the appropriate alias for your region:

• Americas: [email protected]

• Asia Pacific: [email protected]

• EMEA: [email protected]

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 XV

• • •••

Preface


Tivoli User Group Community

You can get even more out of Tivoli software by joining and participating in one of the 91 independently run Tivoli User Groups around the world. Learn about online and in-person Tivoli User Group opportunities near you at www.tivoli-ug.org.

Course Objectives

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.

IBM Software Group | Tivoli software

2

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

• Describe the ITIL management framework • Successfully complete the ITIL Foundations Practice Certification

Exam in preparation for ITIL Foundations Certification Exam

XVI IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Preface


• Unit 2: Service Strategy

In this Unit, you will learn more about Service Strategy.

• Unit 3: Service Design

In this unit, you will learn about Service Design.

• Unit 4: Service Transition

In this unit, you will learn about Service Transition.

• Unit 5: Service Operation

In this unit, you will learn about Service Operation.

• Unit 6: Continual Service Improvement

In this unit, you will learn about Continual Service Improvement.

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 XVII

• • •••

Preface


Typographical Conventions

In this course, the following typographical conventions are used.

Product Information

Product Documentation

In some cases IBM Tivoli product documentation is available in the classroom or on the Instructor Resources CD. For access to documentation outside the classroom environment, visit the IBM Web site.

Convention Usage

BoldCommands, keywords, file names, authorization roles, URLs, or other information that you must use literally appear in bold.

ItalicsVariables and values that you must provide appear in italics. Words and phrases that are emphasized also appear in italics.

Bold Italics New terms appear in bold italics when they are defined in the text.

Monospace 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.

XVIII IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Preface


• • • ••

1-1

Unit 1: ITIL Overview


Unit 1: Information Technology Infrastructure Library (ITIL) Overview

1-2 IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Unit 1: ITIL Overview


Introduction

This unit defines service and explains the concept of Service Management as a practice.

Objectives


2

Objectives

Upon completion of this unit, you will be able to:Define and explain the concept of a serviceDefine and explain the concept of Service Management Define and distinguish between functions, roles, and processes List the characteristics of processesExplain the process model

Explain the Service Lifecycle

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 1-3

• • •••

Unit 1: ITIL OverviewHistory of ITIL


Lesson 1: History of ITIL


Lesson 1: History of ITIL


• • • ••



History of ITIL

ITIL promotes a quality approach to achieving business efficiency and effectiveness in the use of information systems. ITIL best practices are applicable to all IT organizations, no matter what their size or what technology they use. Today, ITIL is one of the most widely accepted approaches to IT Service Management in the world.

Information Technology Infrastructure Library (ITIL) Version 1 contained over 40 books, which were consolidated into seven books between 1999 and 2006 in ITIL Version 2. ITIL Version 3 currently consists of five core books. ITIL V3 builds upon ITIL V2 but focuses on the lifecycle of a service that should be aligned to business needs.


4

History of 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)


• • •••



Information Technology Infrastructure Library

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.


5

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


• • • ••



Contents of the Library

The ITIL library is a set of books that describe internationally accepted best practices for IT Service Management, including these practices:

• A process-based approach to IT Service Management

• A common language for IT Service Management

• A framework that is independent of organizational structures, architectures, or technologies


6

Contents of the Library

The five volumes that make up the ITIL lifecycle are:ITIL Service Strategy ITIL Service Design ITIL Service Transition

ITIL Service Operation ITIL Continual Service Improvement


• • •••



Components of the ITIL Library

ITIL promotes a quality approach to achieving business efficiency and effectiveness in the use of information systems. ITIL best practices are applicable to all IT organizations, no matter what their size or what technology they use. ITIL is one of the most widely accepted approaches to IT Service Management in the world.


7

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 businessThe ITIL Complementary Guidance: A complementary set of publications with guidance to specific to industry sectors, organization types, operating models, and technology architectures


• • • ••



ITIL Version 3 Framework

The ITIL Core documents form the Service Lifecycle. Each publication addresses capabilities that have direct effect on the performance of a service provider. 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.


• • •••



Summary of the Service Lifecycle

Strategy

• Determine requirements from the business

Design (Overlaps with Strategy)

• Design service

• Consider warranty attributes (such as availability and capacity)

• Create service through development and integration

Transition

• Test service

• Coordinate Request for Changes (RFCs) to put service into production

• Deploy release

• Run service pilots


9

Summary of the Service Lifecycle

The Service Lifecycle contains the elements of:

• Strategy

• Design

• Transition

• Operation

• Improvement


• • • ••



Operation (Overlaps with Transition)

Operate and monitor service

• Support service

• Manage requests

Improvement (Overlaps with Transition and Operation)

• Report service metrics

• Identify ROI

• Improve services


• • •••



ITIL Qualifications Scheme

The ITIL Qualification Scheme gives credits for each exam taken. Candidates who have accumulated a sufficient number of credits can achieve the ITIL Expert in IT Service Management.Foundation Level.

The Foundation level focuses on knowledge and comprehension to provide a good grounding in the key concept, terminology, and processes of ITIL.

There are two streams in the Intermediate Level. Both assess your ability to analyze and apply the concepts of ITIL. Candidates can take units from either of the Intermediate streams to gain credits towards the Expert Level. The two streams are the Intermediate Lifecycle Stream and the Intermediate Capability Stream.

The Intermediate Lifecycle Stream includes five individual certificates built around the following books:

• Service Strategy

• Service Design

• Service Transition

• Service Operation

• Continual Service Improvement


10

ITIL Qualifications Scheme

Four Levels:• Foundation Level

• Intermediate Level (Lifecycle Stream and Capability Stream)

• ITIL Expert

• ITIL Master


• • • ••



The focus of these modules is on the introduction and implementation of the specific Lifecycle phase in addition to coverage of the principles, processes, and related activities.

The Intermediate Capability Stream includes four individual certificates loosely based on the V2 Clustered Practitioner qualifications, but broader in scope in line with the updated V3 content. It focuses on detailed process implementation and management within the following cluster groupings:

• Operational Support and Analysis: Event, Incident, Request, Problem, Access, Service Desk, Technical, IT Operations, and Application Management

• Service Offerings and Agreements: Portfolio, Service Level, Service Catalog, Demand, Supplier, and Financial Management

• Release, Control and Validation: Change, Release and Deployment, Validation and Testing, Service Asset and Configuration, Knowledge, Request Management, and Service Evaluation

• Planning, Protection, and Optimization: Capacity, Availability, Continuity, Security, Demand, and Risk Management.

The ITIL Expert Level in IT Service Management requires successful completion of a number of Intermediate units in addition to the mandatory Foundation Level and the Managing Across the Lifecycle capstone course. This course brings together the full essence of a Lifecycle approach to Service Management and consolidates the knowledge gained across the qualification scheme.

The ITIL Master Level of the qualification asseses your ability to apply and analyze the ITIL concepts in new areas. This higher level qualification is currently under development.

The ITIL Managers Bridge certification is for individuals who already have the Manager’s Certificate in IT Service Management in an earlier ITIL version, and want to earn the ITIL Expert in IT Service Management to demonstrate their knowledge of ITIL V3.


• • •••

Unit 1: ITIL OverviewServices


Lesson 2: Services


Lesson 2: Services


• • • ••



Service Management as a Practice

Service Management is defined as a set of specialized organizational capabilities for providing value to customers in the form of services. The ability to provide these services is achieved by using the functions and processes for managing services throughout a lifecycle. Service Management uses specializations in strategy, design, transition, operation, and continual improvement. At the heart of Service Management, is the ability to convert resources into critical services. Without Service Management, a service organization can not be effective.

The ITIL Framework is a source of good practice in Service Management. ITIL is used by organizations worldwide to establish and improve capabilities in Service Management.

Proprietary knowledge is customized, difficult to obtain access to, and deeply embedded in an organization. Therefore, it is often preferable to use proven public frameworks and standards. The ITIL Core provides best practice guidance applicable to all types of organizations who provide services to a business.


12

Service Management as a Practice

• ITIL used worldwide to establish and improve capabilities in Service Management

• The wide adoption of good practices in industry is advantageous because organizations can compare themselves to peers and close gaps in capabilities and performance

• Sources for good practices include:Public frameworks Standards Proprietary knowledge of organizations and individuals


• • •••



Services

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.


13

Services

• Service is a way to deliver value to customers by helping them obtain goals without their ownership of specific costs and risks

• Deliver value to customers

• Facilitate outcomes

• Result in an increase in the probability of expected outcome


• • • ••



Service Management

The organizational capabilities of Service Management provide value to customers in the form of services.

These organizational capabilities are functions and processes for managing services throughout a lifecycle. They are specialized in strategy, design, transition, operation, and continual improvement.

The capabilities represent the capacity, competency, and confidence for action of the service organization.

Without these capabilities, a service organization is merely a bundle of resources that by itself has relatively low intrinsic value for customers.


14

Service Management

• A set of specialized organizational capabilities that take the form of:

Processes

Functions

Roles

• The core of service management is the act of transforming resources into valuable services


• • •••

Unit 1: ITIL OverviewProcess and Service Owners


Lesson 3: Process and Service Owners


Lesson 3: Process and Service Owners


• • • ••



Process Owners

Duties of Process Owners include the following tasks:

• Documenting and publicizing the process.

• Defining the Key Performance Indicators (KPIs) to evaluate the effectiveness and efficiency of the process.

• Reviewing KPIs and taking action required following the analysis.

• Improving the effectiveness and efficiency of the process.

• Ensuring all relevant staff have the required training in the process and are aware of their role in the process.

• Interacting with line management to ensure that the process receives the needed staff resources. Line management and Process Owners have complementary tasks. They must work together to ensure efficient and effective processes. Often line management ensures the required training of staff.


16

Process Owners

• Responsible for ensuring that their processes are performed according to the agreed-upon and documented process

• Must ensure that the processes meet the aims of their definitions


• • •••



Service Owners

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.


17

Service Owners

• The Service Owner is responsible to the customer for the initiation, transition, and ongoing maintenance and support of a particular service.


• • • ••

Unit 1: ITIL OverviewProcesses


Lesson 4: Processes


Lesson 4: Processes


• • •••



Processes

Processes should be defined, documented, and controlled. After they are under control, they can be repeated, and they become manageable.

Processes are closed-loop systems because they have the following characteristics:

• Provide change and transformation toward 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.


19

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


• • • ••



Characteristics of Processes

Processes are measurable and driven by performance. Managers want to measure cost, quality, and other factors. 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, and it should be traceable to a specific trigger. Functions are often mistaken for processes.


20

Characteristics of Processes

• Measurable

• Specific results

• Respond to a specific event or are triggered at specific times

• Deliver its primary results to a customer or stakeholder


• • •••



Generic Process Elements

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. They should also 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.

• 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.


21

Generic Process Elements

• Defines how data enters the process

• Defines how the data is processed

• Defines the output, which is driven by objectives

• Measures and reviews the outcome using metrics, reports, and process improvement


• • • ••



Process Elements for ITIL

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.


• • •••



ITIL Processes

It is possible to work more efficiently and effectively by:

• Defining the activities of an organization, the necessary inputs

• Defining the outputs that will result from the process

Measuring and steering the activities increases this effectiveness.

By adding norms to the process, it is possible to add quality measures to the output.


23

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


• • • ••



The Process Model

Degrees of control over processes can be defined. Then, process measurement and metrics can be built into the process to control and improve it.


24

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


• • •••

Unit 1: ITIL OverviewFunctions


Lesson 5: Functions


Lesson 5: Functions


• • • ••

Unit 1: ITIL OverviewFunctions


Functions

Capabilities include work methods that are internal to the functions. Sample functions include Technical Management and the Service Desk. These functional units facilitate multiple processes.

Functions have their own body of knowledge, which is accumulated from experience of the functional organization.

Functions provide structure and stability to organizations.


26

Functions

• General units of organizations

• Specialized to perform certain type work

• Responsible for specific outcomes

• Self-containedCapabilities

Resources necessary for performance and outcomes


• • •••

Unit 1: ITIL OverviewRoles


Lesson 6: Roles


Lesson 6: Roles


• • • ••

Unit 1: ITIL OverviewRoles


Roles Defined

A technical management department can perform the role of Problem Management when diagnosing the root cause of incidents. This same department could also function in other roles at different times. For example, they may assess the impact of changes (Change Management role) or manage the performance of devices under their control (Capacity Management role).


28

Roles

• A role refers to a set of connected behaviors or actions that are performed by a person, team, or group in a specific context

• The scope of their roles, and what triggers them to play those roles, are defined by the relevant process and agreed to by their line manager


• • •••

Unit 1: ITIL OverviewRisk


Lesson 7: Risk


Lesson 7: Risk


• • • ••



Risk

The aim is to support better decision-making through a good understanding of risks and their likely impact.


30

Risk

• Risk is the uncertainty of outcome, whether positive opportunity or negative threat

• Managing risks requires:Identification of the risk Control of the exposure to risk, which can affect the achievement of the business objectives of an organization


• • •••



Phases of Risk

Risk Analysis is concerned with gathering information about exposure to risk so that the organization can make appropriate decisions and manage risk appropriately.

Risk Management 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


31

Phases of Risk

The two phases of risk include:1. Risk Analysis2. Risk Management


• • • ••

Unit 1: ITIL OverviewUnit Scenario


Lesson 8: Unit Scenario

Company X wants to create a service catalog. Every organization catalog can be different, but there are a few common services that a company might start with.

One of these might be requesting access to applications and or systems. Another might be requesting a project or enhancement to applications maintained by internal or external development teams.

With v3 ITIL, defining a service is handled through the Service Design, then Transition, and finally with Services Operations.

The services (Services Catalog) are managed with the Service Management process. The Business Relationship Manager is the role that assists the business in determining the services offerings required to meet customer demands.

The output to the service catalog management process is the Service Catalog. It is critical that the organization make sure the user interface to the service is easy to use. Such an interface will increase customer receptiveness and lessen usability issues. In addition, service should be tested to make certain the operations in the back end fulfillment process are scalable for the volume of requests. These operational processes can be further researched in the V3 Service Operations book.

The organization develops a business case for every service within the Service Strategy. It starts by collecting information from all existing services as well as every proposed service. It then determines the required investment in terms of potential benefits. In addition, it will define the resources and capabilities required for provisioning and maintaining each service. During this process, it will be important to consider the constituencies: users, IT operations, finance leaders, and business leaders.

Service Catalog should be integrated with Request Fulfillment because it can be the backbone of the organization. In addition, it can be the primary means for business to interact with and request services from IT.

The catalog is defined within the structure of ITIL of Service Strategy, Design, Transition and then Operations lifecycle. An individual service life cycle begins with the Service Pipeline, then is live or available for service, and is finally retired.


• • •••



Review Questions

1. Which of the following choices is a way to deliver value to customers by helping customers obtain their goals without the ownership of specific costs and risks?

a. Risk management

b. Service management

c. Process management

d. Operation management

2. Which of the following choices is true about the Process Model?

a.Defines how data enters the process and is processed

b. Defines the output

c. Measures and reviews the outcome

d. All of the above

3. Which of the following choices is not a characteristic of processes?

a.Measurable

b. Specific results

c. Customers

d. Does not respond to specific events

4. A set of specialized organizational capabilities for providing value to customers in the form of services describes which of the following choices?

a.Service Design

b. Continual Service Improvement

c. Service Management

d. Service Operation

5. How do services deliver value to customers?

a.By introducing new products so that customers often have an option to upgrade

b. By reducing cost for the customers so they will pay less for the same product

c. By giving customers what they want without the ownership of specific costs and risks


• • • ••



d. By making the products of better quality and testing them more rigorously

6. Which of the following choices is a structured set of activities designed to accomplish a specific objective?

a.Element

b. Process

c. Function

d. Role

7. Which of the following choices are general units of organizations specialized to perform certain types of work?

a.Element

b. Process

c. Function

d. Role

8. Which of the following choices is a set of connected behaviors or actions that are performed by a person, team, or group in a specific context?

a.Element

b. Process

c. Function

d. Role


• • •••




• • • ••



Review Answers

1. Which of the following choices is a way to deliver value to customers by helping customers obtain their goals without the ownership of specific costs and risks?

b. Service management

2. Which of the following choices is true about the Process Model?

d. All of the above

3. Which of the following choices is not a characteristic of processes?

d. Does not respond to specific events

4. A set of specialized organizational capabilities for providing value to customers in the form of services describes which of the following choices?

c. Service Management

5. How do services deliver value to customers?

c. By giving customers what they want without the ownership of specific costs and risks

6. Which of the following choices is a structured set of activities designed to accomplish a specific objective?

b. Process

7. Which of the following choices are general units of organizations specialized to perform certain types of work?

c. Function

8. Which of the following choices is a set of connected behaviors or actions that are performed by a person, team, or group in a specific context?

d. Role


• • •••



Summary


33

Summary

You should now be able to:Define and explain the concept of a serviceDefine and explain the concept of Service Management Define and distinguish between functions, roles, and processes List the characteristics of processesExplain the process model

Explain the Service Lifecycle


• • • ••



• • • ••

2-1

Unit 2: Service Strategy




• • • ••



Introduction

In this Unit, you will learn more about Service Strategy.

Objectives


2

Objectives

Upon completion of this unit, you will be able to:Explain the purpose of Service Strategy Explain the two elements of value: utility and warranty Describe the three types of service providers

Explain how to choose between service provider types Describe the key principles of Service Strategy Discuss the main Service Strategy processes and associated activities


• • •••

Unit 2: Service StrategyService Strategy Overview


Lesson 1: Service Strategy Overview


Lesson 1: Service Strategy Overview


• • • ••



Service Strategy Defined

A healthy business model will describe the defined objectives of the business. A clear strategy for accomplishing the objectives must be clearly stated to the customer. Otherwise, the customer will not recognize the increase in value. The Service Strategy defines a clear path to delivering value to the customer.

Customers are looking for ways to strategically improve their business models. They want solutions that will break through existing performance barriers. They want to increase performance without an increase in cost. This kind of improvement provides an opportunity to offer a solution by providing improved products and services.


4

Service Strategy Defined

• Service Strategy is a strategic plan designed to achieve defined objectives

• The Service Strategy defines a clear path to delivering value to the customer


• • •••



Purpose of Service Strategy


5

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


• • • ••



Service Strategy Objectives


6

Service Strategy Objectives

Service Strategy seeks to answer the following 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 value creation?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?


• • •••



Service Model

Service Agreements specify the terms and conditions under which such interaction occurs with commitments and expectations on each side. Interaction means demand connects with the capacity to serve.

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.


7

Service Model

A Service Model performs the following tasks:Codifies the Service Strategy for a market space Outlines process and functions needed to create value Describes how service assets create value for a given portfolio of contracts Increases effectiveness in Continual Service Improvement

Purpose of Service Model:

Define the value to be created in the form of the utility and the warranty provided to customers.


• • • ••



Business Case

The consequences can take on qualitative and quantitative dimensions. A financial analysis, for example, is frequently central to a good business case.


8

Business Case

• A business case is a decision support tool and planning tool that projects the likely consequences of a business action

• The elements of a business case include:Introduction: Presents business objectives addressed by service management initiative Methods and Assumptions: Defines boundaries of business case, such as time periodBusiness Impacts: The financial and non-financial business case results Risks and Contingencies: The probability that alternative results will engage Recommendations: Specific actions recommended


• • •••



Elements of Value: Utility and Warranty

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 use, or 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 permits a wide range of solutions to the problem of creating, maintaining, and increasing value.


9

Elements of Value: Utility and Warranty

UtilityAttributes of the service that have a positive effect on the performance of activities, objects, and tasks associated with required outcomes

WarrantyThe positive effect being available when needed, in sufficient capacity or magnitude, and dependably available in terms of continuity and security


• • • ••



The Four Ps of Service Strategy

After a service provider has a thorough understanding of its service objectives, it is ready to begin the service lifecycle. The entry points to service strategy are referred to as the Four Ps. These points identify the different forms a service strategy might take.

A strategic perspective articulates the business philosophy and manner in which services are provided. CIOs might determine that their businesses most value a certain type of service provider.

An internal service provider (Type I) restricted to serving one business unit might adopt a position based on:

• Product knowledge

• Customer responsiveness

• Value

• Cost

• Specialized services or broad sets of services


10

The Four Ps of Service Strategy

• Perspective: Describes a vision and direction

• Position: Describes the decision to adopt a well-defined stance

• Plan: Describes the means of moving from the current state to a future state

• Pattern: Describes a series of consistent decisions and actions over time


• • •••



Planning the transition requires answering questions such as:

• How can high-value or low-cost services be offered?

• How specialized services be offered?

Patterns might be:

• A service provider who continually offers specific services with deep expertise is adopting a high-value or high-end service strategy.

• A service provider who continually offers dependable and reliable services is adopting a high-warranty strategy.


• • • ••



Service Automation

Automation can have a significant effect on the performance of service assets such as management, organization, people, process, knowledge, and information.

Service management can benefit from automation in the following areas:

• Design and modeling

• Service catalog

• Pattern recognition and analysis

• Classification, prioritization, and routing

• Detection and monitoring

• Optimization


11

Service Automation Can

• Improve the utility and warranty of services

• Improve the quality of service

• Reduce costs and reduce risks by reducing complexity and uncertainty, and by efficiently resolving trade-offs

• Handle capacity with fewer restrictions on time of access

• Be used to measure the differential impact on service quality and costs

• Handle scheduling, routing, and allocation of resources

• Reduce the depreciation of knowledge


• • •••

Unit 2: Service StrategyService Providers


Lesson 2: Service Providers


Lesson 2: Service Providers


• • • ••



Service Providers

There are three types of service providers.


13

Service Providers

• Internal Service Provider, Type I

• Shared Services Provider, Type II

• External Service Provider, Type III


• • •••



Internal Service Provider (Type I)

Duplication and waste occur when Type I providers are replicated within the enterprise.

To take advantage of both economy of scale and economy, Type I providers of similar characteristics are consolidated into a corporate business function.

Internal Service Providers might include functions such as:

• Finance

• Administration

• Logistics

• Human resources

• IT


• • • ••





15


• Type I providers are typically business functions embedded within the business units they serve which may be part of a larger enterprise or a parent organization

• Internal Service Providers provide services required by the various parts of the business

• Type I providers avoid certain costs and risks associated with conducting business with external parties


• • •••



Shared Services Provider (Type II)

Shared Service Units (SSUs) can create, grow, and sustain an internal market for their services and model themselves along the lines of service providers in the open market.

Like corporate business functions, they can use opportunities across the enterprise and spread their costs and risks across a wider base. However, SSUs have fewer protections in the areas of strategic value and core competence.

Type II providers benefit from a relatively captive internal market for their services. However, their customers might still evaluate them in comparison with external service providers.

Poorly performing Type II providers face the threat of substitution, putting pressure on the leadership to adopt industry best practices and strive for operational effectiveness.

Industry-leading shared services units have been successfully spun off from their parent companies as independent businesses competing in the external marketplace.


• • • ••





17


• Functions such as finance, IT, human resources, and logistics are not always at the core of competitive advantage of an organization

• Instead, the services of such shared functions are consolidated into an autonomous special unit called a shared services unit (SSU)

• Shared Services Providers are subject to comparisons with external service providers whose performance they should approximate if not exceed

• Type II can offer lower prices compared to external service providers by standardizing service offerings across business units and using market-based pricing to influence demand patterns


• • •••



Shared Services Provider (Type III)

The experience of Type III providers is not limited to any one enterprise or market.

The breadth and depth of such experience is often the single-most distinctive source of value for customers.

The breadth comes from serving multiple types of customers or markets.

The depth comes from serving multiples of the same type.

Security is always an issue in shared services environments. When the Type III provider also provides services to competitors, security becomes a larger concern.

As a counterbalance, Type III providers might reduce systemic risks by transferring them to external service providers, who spread those risks across a larger value network.


• • • ••



Shared Services Provider (Type III)


19

External Service Provider (Type III)

• Type III providers can offer competitive prices and drive down unit costs by consolidating demand

• Customers might be motivated to choose a Type III provider because of access to knowledge, experience, scale, scope, capabilities, and resources that are either beyond the reach of the organization or outside the scope of a carefully considered investment portfolio

• Business strategies often require reductions in the asset base, fixed costs, operational risks, or the redeployment of financial assets

• Customers who need flexible and lean structures might prefer to buy services rather than own and operate the assets necessary for certain business functions and processes


• • •••



Choosing Service Provider Types

Examples of transaction costs might include, but are not limited to, the costs of the following activities:

• Finding and selecting qualified providers

• Defining requirements

• Negotiating agreements

• Measuring performance

• Managing the relationship with suppliers

• Resolving disputes

• Making changes or amends to agreements

Some questions an organization might ask when choosing Service Provider Types:

• Does the activity require highly specialized assets?

• Will they be idle or obsolete if that activity is no longer performed?

• How frequently is the activity performed within a period or business cycle? Is it infrequent or sporadic?


20

Choosing Service Provider Types

• Services may be sourced from each type of service provider with decisions based on:

Transaction costs

Strategic industry factors

Core competence

Risk management capabilities of the customer

• The principles of specialization and coordination costs apply


• • • ••



• How complex is the activity? Is it simple and routine? Is it stable over time with few changes?

• Is it hard to define good performance? Is it hard to measure good performance?

• Is it tightly coupled with other activities or assets in the business? Would separating it increase complexity and cause problems of coordination?


• • •••



Sourcing Approaches and Options

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. Outsourcing 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 using formal arrangements between organizations. In BPO, one organization provides and manages the entire business processes or functions of the other organization in a low cost location. Common examples are accounting, payroll, and call center operations.


21

Sourcing Approaches and Options

• Insourcing relies on using 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


• • • ••



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 otherwise might not justify the investment.


• • •••

Unit 2: Service StrategyThe Process of Strategy Generation


Lesson 3: The Process of Strategy Generation


Lesson 3: The Process of Strategy Generation


• • • ••



Strategy Generation

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

For example:

A software vendor might decide to offer software as a service. The vendor combines their capabilities in software development with new capabilities in service management. The vendor also makes use of their 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 itself 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.


23

Strategy Generation

• Differentiate your 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.


• • •••



Main Activities of Service Strategy

Business needs and requirements should be the driving force behind all service solutions and activities. In addition, Service Strategy must also reflect the strategies and policies of the service provider organization,

Service Strategy consists of:

• Strategies

• Policies

• Resources and Constraints

• Service Level Package (SLP) from Requirements

The key to any successful Service Strategy is to focus on fully satisfying the customer’s needs at a sufficient value to the customer.


24

Main Activities of Service Strategy

• Define the market

• Develop the service offerings

• Develop strategic assets

• Prepare for implementation


• • • ••



Defining the Market: Market Space

Services are a means of delivering value to customers by facilitating outcomes customers need without owning specific costs and risks.

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 customer perspective of the customer

This problem leads to poor designs, ineffective operation, and lackluster performance in service contracts. Service improvements are difficult when it is not clear what improvements are truly required. Customers can understand and appreciate improvements only within the context of their own business assets, performances, and outcomes. A correct 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. These activities should be completed entirely from the perspective of what is valuable to the customer. Such an approach ensures that services not only create value for customers but also capture value for the service provider.


25

Defining the Market: Market Space

• 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.


• • •••



Solutions that enhance the performance of the customer assets indirectly support positive outcomes generated by those assets. Such solutions and propositions hold utility for the business.

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 aids 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 correctly defined, the cost of service assets spent in support of customers assets might be difficult to account for and recover. Incorrect cost definition leads to situations where adequate value is created for the customer, but inadequate value is captured for the provider.


• • • ••



Expansion, Growth, and Differentiation

Service portfolios should be extended to support areas of opportunity. Usually 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 typically 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 and 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, geographical areas, 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 a given market space.


26

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 depends on 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


• • •••



Strategic planning and review includes examining opportunities for growth within current customers and services.

The best opportunities for service providers lie in areas where an important customer need is not satisfied. Service portfolios should be extended to support such areas of opportunity. Extension typically means that 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 usually required to successfully deliver value in underserved areas of opportunity.

Strategic planning and review includes examining opportunities for growth within current customers and services. Growth in a market space is dependent upon 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 permits efficiency and effectiveness in the delivery and support of services

With 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


• • • ••



Develop the Offerings and Strategic Assets

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.

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 that 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 can be difficult to account for and recover. This difficulty leads to situations where adequate value is created for the customer, but inadequate value is captured for the provider


27

Develop the Offerings and Strategic Assets

• Services are a means of delivering value to customers by facilitating outcomes customers need without their owning specific costs and risks

• 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


• • •••



To develop Service Management as a strategic asset, define the value network by identifying the key relationships and interactions. This definition will provide 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.


• • • ••



Increasing Service and Performance Potential

The capabilities and resources (service assets) of a service provider represent the service potential available to customers through a set of services. Projects that develop or improve capabilities and resources increase the service potential.

Implementation of a Configuration Management system (CMS) leads to improved visibility and control over the productive capacity of service assets. These assets include 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 decisions are rooted in creating value for customers. This practice avoids many problems of service businesses where value for customers is harder to define and control. Working


28

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 goods and 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


• • •••



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 having the right mix of services. In addition, it is increased by 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.


• • • ••



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


29

Strategic Assessment

• Analyze External Factors

• Establish Objectives

• Analyze Internal Factors


• • •••



Setting Objectives

To craft objectives, an organization must:

• Understand what outcomes customers want

• Determine how best to satisfy the important but under served 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.


30

Setting Objectives

• Objectives represent the results expected from pursuing strategies.

• 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.


• • • ••



Defining Critical Success Factors

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 using a Service Portfolio. For example, in the market space for high-volume, real-time data processing, such as those required by the financial services industry, 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. In addition, significant events such as changes to customer portfolios, expansion into new market spaces, changes in the regulatory environment, and disruptive technologies need to be monitored. For example, the health care 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 health care market spaces.


31

Defining Critical Success Factors

Critical Success Factors are influenced by:

• customer needs

• business trends

• competition

• regulatory environment

• suppliers

• Standards

• industry best practices

• technologies


• • •••



Strategy Generation, Evaluation, and Selection


32

Strategy Generation, Evaluation, and Selection

• Determine perspective: Vision

• Form a position: Policies

• Craft a plan: Plans

• Adopt patterns of action: Actions


• • • ••



Measurement and Evaluation


33

Measurement and Evaluation

• Service StrategyService Portfolio

Service Design requirements

Service Transition requirementsService Operation requirements

• Continual Service Improvement Strategy


• • •••



Strategy Generation Roles

IT Steering Group (ISG)

The IT Steering Group (ISG) sets the direction and strategy for IT Services. It includes members of senior management from business and IT. The ISG reviews the business and IT strategies in order to make sure that they are aligned. It also sets priorities of service development programs and projects.

Service Owner

The Service Owner of each service record contains the role or function currently accountable for the service, but not for the Service Portfolio Management process.

Service Sponsor

The Service Sponsor is the person or board responsible for budgets and costs related to a specific service.


34

Strategy Generation Roles

• IT Steering Group (ISG)

• Service Owner

• Service Sponsor

• Requirements Requester

• Service Design Team


• • • ••



Requirements Requester

The Requirements Requester is the person or group of persons expressing new demands and requirements to be fulfilled by the IT service provider.

Service Design Team

The Service Design Team is the team associated to all tasks in the context of designing a service. This team is responsible for creating a Service Design Package.


• • •••

Unit 2: Service StrategyThe Process of Service Portfolio Management


Lesson 4: The Process of Service Portfolio Management


Lesson 4: The Process of Service Portfolio Management


• • • ••



Service Portfolio Management (SPM)

The Service Portfolio represents present contractual commitments, new service development, and ongoing service improvement programs initiated by Continual Service Improvement.

The portfolio also includes external vendor services, which are an integral part of service offerings to customers.

The Service Portfolio represents all the resources presently engaged or being released in various phases of the Service Lifecycle. Each phase requires resources for completion of projects, initiatives, and contracts. The phases are also an important governance aspect of Service Portfolio Management (SPM).


36

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


• • •••



Service Portfolio Management

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. 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.

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.

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.


• • • ••



Through SPM, managers are better able to understand quality requirements and related delivery costs. They can then seek to reduce costs by 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.


• • •••



Service Portfolio Management Goals

The purpose of Service Portfolio Management is to create, manage and improve a service portfolio containing a detailed design package for each IT service.


38

Service Portfolio Management Goals

• Every planned and operated service by the provider is documented.

• Every new service must complete a set of standardized activities and procedures.

• Essential information is documented and provided to the relevant management processes.

• Each service and its design package is regularly reviewed.

• Every service is reviewed within the Continual Service Improvement Process.

• Through the service portfolio, an information base for a service catalog is provided.


• • • ••



Service Portfolio Management Benefits

A Service Portfolio describes the services of a provider in terms of business value. It outlines business needs and the response to those needs. By definition, business value terms correspond to marketing terms. Therefore, a Service Portfolio provides a means for comparing service competitiveness across alternative providers.

A Service Portfolio either clarifies or helps to clarify the following strategic questions:

• Why should a customer buy these services?

• Why should they buy these services from us?

• What are the pricing or chargeback models?

• What are our strengths and weaknesses, priorities and risk?

• How should our resources and capabilities be allocated?


39

Service Portfolio Management Benefits

• Helping managers prioritize investments and improve the allocation of resources.

• Instilling financial discipline necessary to avoid making investments that will not yield value.

• Representing the ability and readiness of a service provider to serve customers and market spaces.


• • •••



Service Portfolio Management Activities

Service Portfolio Management includes the following activities:

Define

Collect information from all existing services as well as every proposed service. Every proposed service would include those in a conceptual phase. For example, all services the organization would provide if it had unlimited resources, capabilities and time. The purpose of this exercise is to understand the opportunity costs of the existing portfolio. A service provider needs to understand its limitations. In this way, it is better able to assess if it should keep doing what it is doing or reallocate its resources and capabilities.


40

Service Portfolio Management Activities

• Define

• Analyze

• Approve

• Charter


• • • ••



Analyze

In this phase, the intent of the strategy is designed. During this activity, the following questions should be answered:

• What are the long term goals of the service organization?

• What services are required to meet those goals?

• What capabilities and resources are required for the organization to achieve those services?

• What are the perspective, position, plan and patterns?

The answers to these questions guide the analysis and the desired outcomes of SPM. The ability to satisfactorily answer these questions requires the involvement of senior leaders and subject matter experts.

Approve

In this phase, deliberate approvals or disapprovals of the proposed portfolio take place. In addition, the corresponding authorization for new services and resources occurs in this phase.

Charter

In this phase decisions are communicated, resources are allocated, and services are chartered. This phase should begin with a list of decisions and action items. These are to be communicated to the organization clearly and unambiguously. These decisions should be correlated to budgetary decisions and financial plans. Budget allocations should enforce the allocation of resources.


• • •••



Service Portfolio Management Roles

Service Portfolio Process Manager (Service Portfolio Manager)

The Service Portfolio Process Manager manages the entire SPM process. This person is responsible for the effectiveness and efficiency of the SPM process.

Service Portfolio Process Owner

The Service Portfolio Process Owner is the Initiator of the process. This person is accountable for defining the strategic goals of the processes. In addition, this person is responsible for allocating all required process resources.

Service Portfolio Management Team

The members of this team are assigned to complete various activities in the SPM process.


41

Service Portfolio Management Roles

• Service Portfolio Process Manager (Service Portfolio Manager)

• Service Portfolio Process Owner

• Service Portfolio Management Team

• Service Agent


• • • ••



Service Agent

The Service Agent of each service record contains the role or function responsible for the current activity or task within the process of Service Portfolio Management. The Service agent can be changed through a functional escalation, if allowed. This following role is assigned for each new instance of the Service Portfolio Management process and usually exist for the entire lifetime of one process instance. Changes in the assignment of this role is possible. However, the change applies only to a specific process instance, and not to the process in general.


• • •••

Unit 2: Service StrategyThe Process of Financial Management


Lesson 5: The Process of Financial Management


Lesson 5: Financial Management


• • • ••



Financial Management

Financial Management consists of the function and processes responsible for managing an IT service provider’s budgeting, accounting, and charging requirements.

Internal service providers are increasingly asked to operate with the same levels of financial visibility and accountability as their business unit and external counterparts. Moreover, technology and innovation have become the core revenue-generating capabilities of many companies.

Financial Management quantifies, in financial terms, the value of IT Services and the assets underlying the provisioning of services. In addition, Financial Management provides the qualification of operational forecasting. A significant portion of Financial Management is working with IT and the business to identify, document, and agree on the value of the services being received. Financial Management also contributes to service demand modeling and management.


43

Financial Management

• Financial Management as a strategic tool is equally applicable to all three service provider types

• Financial Management consists of the following benefits:Enhanced decision making Speed of change Service Portfolio Management

Financial compliance and control Operational control Value capture and creation


• • •••



Financial Management Goals and Benefits

Financial Management consists of the following benefits:

• Enhanced decision making

• Speed of change

• Service Portfolio Management

• Financial compliance and control

• Operational control

• Value capture and creation


44

Financial Management Goals

• To ensure that management of IT Services are cost effective

• To provide full accountability for IT Service expenditures to the services delivered to customers

• To assist management in making decisions on IT investment by providing detailed business cases for changes to IT Services


• • • ••



Financial Management Considerations

Financial Management must consider several types of costs:

• Direct costs are those that are directly attributable to a specific service. Indirect costs are those that are shared among multiple services. These costs should be analyzed to identify line items that should be maintained. The data available and the level of effort required should be considered in this decision.

• Labor costs are another key expenditure requiring consideration. Analyzing labor costs can be difficult because of the complexity and accuracy of time-tracking systems. Sometimes tracking labor resources assigned across services is not available. In this case, rules and assumptions must be created for allocation of these costs. In its simplest form, organizing personnel costs across financial centers based on a service orientation is a viable method for aligning personnel costs to services.

• Variable cost elements include expenditures that are not fixed. They vary according to factors such as the number of users or the number of running instances.

Translation from cost account data to service value is only possible after costs are attributed to services. Pricing the perceived value portion of a service involves analysis of historical costs, perceived value-added, and planned demand variances.


45

Financial Management Considerations

• Direct versus indirect costs

• Labor costs

• Variable cost elements

• Translation from cost account data to service value


• • •••



Financial Management Activities


46

Financial Management Activities

• Plan

• Analyze

• Design

• Implement

• Measure


• • • ••



Plan


47

Plan

• Address critical questions about the business and IT culture

• Assess the corporate culture and regulatory and compliance considerations

• Identify all internal and external contacts that provide or receive IT financial information

• Clarify IT and business expectations such as:Deliverables Chargeback system Service Catalog implementation and pricing


48

Plan (Continued)

• Determine systems that require Financial Management data

• Determine the funding or operating model to be used• Assign responsibilities for the deliverables • Outline activities to be performed• Prepare the organization chart based on activities, size of

data to be, and tools • Prepare policy and operating procedures list


• • •••



Analyze

Financial analysis includes the following tasks:

• Gather details around the planning and funding of identified items.

The most detailed task will be analyzing the data pertaining to service valuation and demand modeling.

• Make certain that all processes and information required to produce deliverables are accounted for.

IT or the business might hold expectations regarding deliverables. Therefore, analyze backward to make certain all information required to produce the expected deliverables are accounted for. This process is part of Financial Management responsibilities.

• Become familiar with current expenses in preparation for creating new valuation and funding documents.

There might be issues that become apparent after reviewing expenditures. For example, it might become evident that not all IT payments are collected into one financial center. However, in order to report and account for services costs, IT expenditures must be centralized.


49

Analyze

• Gather details around the planning and funding of identified items

• Make certain that all processes and information required to produce deliverables are accounted for

• Become familiar with current expenses in preparation for creating new valuation and funding documents

• After completing an accounting of all IT expenditures, perform service valuation, including:

Producing reports that provide for the first element of valuation pricing of service assets

Adding that value to each service to calculate the total price for an IT service

Analyzing and calculating the value-add price

• Adjust plans for implementation if necessary


• • • ••



• Perform service valuation after an accounting of all IT expenditures has been completed.

Calculation of the value-add price will require a great amount of input from Service Level Management, Availability, Security and Capacity Management

• Adjust plans for implementation if necessary

If during the analysis phase it becomes apparent that Financial Management dependent processes are not available, the plans for implementation must be adjusted. For example, if no IT Services have already been identified, then valuation will be postponed.


• • •••



Design

The design phase creates the outputs that are expected from a Financial Management implementation. Working with key contributors and service economics supporters is essential during this phase. Design is completed using data inputs and translations, reports, methodologies and models.


50

Design

• Processes

• Valuation Models

• Accounting processes

• Chargeback methods

• Procedures

• Roles and responsibilities


• • • ••



Implement


51

Implement

• Activation of planned processes

• Input initially comes from corporate financial systems and Change Management processes


• • •••



Measure

Auditing provides verification that processes are being followed.


52

Measure

• Measures of success should to be provided on financial trends within funding, valuing and accounting

• Audit for any credibility gap between the value being received and price being paid

• Perform regular audits


• • • ••



Financial Management Inputs and Outputs

Service Valuation

Financial Management collects data inputs from across the enterprise. It uses this data to assist in generating and disseminating information as an output. This information feeds critical decisions and activities such as service valuation. Service Valuation quantifies, in financial terms, the funding sought by the business and IT for services delivered, based on the agreed value of those services. Financial Management calculates and assigns a cost value to a service or service component. Then, they can be disseminated across the enterprise once the business customer and IT identify what services are actually desired.

Service Valuation focuses on two key concepts: Provisioning Value and Service Value Potential. Provisioning Value is the actual underlying cost to IT related to provisioning a service. This cost includes both tangible and intangible elements. Input comes from financial systems, and consists of payment for actual resources consumed by IT in the provisioning of a service. Service Value Potential is the value added component based on customer perceptions of what it could achieve using its own assets against what the service organization can provide.


53

Financial Management Inputs and Outputs

• Service Valuation

• Demand Modeling

• Service Provisioning and Optimization

• Planning Confidence

• Service Investment Analysis

• Accounting

• Compliance

• Variable Cost Dynamics


• • •••



Demand Modeling

Through the application of Financial Management, the Service Catalog is able to provide customers with the capability to regulate their demand and prepare budgets. Demand modeling uses service oriented financial information with factors of demand and supply in order to model anticipated usage by the business, and provisioning requirements by IT. This is for identifying funding requirements, variations and drivers of those variations, and to assist in the management of service demand. In this context, inputs for managing service demand include pricing and incentive adjustments that are intended to alter customer consumption patterns.

Service Provisioning and Optimization

Financial Management provides key inputs for Service Provisioning Optimization (SPO). SPO examines the financial inputs and constraints of service components or delivery models to determine if alternatives should be explored relating to how a service can be provisioned differently to make it more competitive in terms of cost or quality.

Planning Confidence

Financial Management tries to ensure that the delivery and consumption of services receives appropriate funding. Financial Management Planning focuses on demand and supply variances resulting from business strategy, capacity inputs and forecasting. It does not focus on individual line item expenditures or business cost accounts. As with planning for any other business organization, input should be collected from all areas of the IT organization and the business. The financial requirements act as inputs to critical business decision making.

Service Investment Analysis

The objective of service investment analysis is to derive a value indication for the total lifecycle of a service based on:

• The value received

• Costs incurred during the lifecycle of the service

In Service Investment Analysis, it is best to use an exhaustive inventory of assumptions rather than a limited set of high-level inputs, in order to generate a more realistic and accurate view of the investment being made.


• • • ••



Accounting

Financial Management works with corporate financial systems and service management. This type of service oriented accounting provides far greater detail regarding service provisioning and consumption. In addition, it results in generation of data that feeds directly into the planning process. The functions and accounting characteristics that occur include:

• Service recording: The assignment of a cost entry to the appropriate service.

• Cost types: The higher level expenses categories such as hardware, software, labor, and administration.

• Cost classifications: The classifications within services that designate the end purpose of the cost.

• Capital or operational: This classification addresses different accounting methodologies that are required by the business and regulatory agencies.

• Direct or indirect: This designation determines whether a cost will be assigned directly or indirectly to a consumer or service.

– Direct costs are charged directly to a service since it is the only consumer of the expense.

– Indirect or shared costs are allocated across multiple services since each service can consume a portion of the expense.

• Fixed or variable: This segregation of costs is based on contractual commitments of time or price.

• Cost units: This is the identified unit of consumption that is accounted for a particular service or service asset.

Compliance

Compliance relates to the ability to demonstrate that proper and consistent accounting methods and practices are being employed. This relates to areas such as financial asset valuation, capitalization practices, revenue recognition, access and security controls.


• • •••



Variable Cost Dynamics

Variable Cost Dynamics (VCD) focuses on analyzing:

• The many variables that impact service cost

• How sensitive those elements are to variability

• The related incremental value changes that result

Examples of components that could be used in analysis include:

• Number and type of users

• Number of software licenses

• Cost or operating footprint of data center

• Delivery mechanisms

• Number and type of resources

• The cost of adding one more storage device

• The cost of adding one more user license


• • • ••



Financial Management Roles

Financial Manager

The Financial Manager is responsible for managing an IT service provider’s budgeting, accounting and charging requirements.

IT Financial Administrator

The IT Financial Administrator is responsible for:

• Gathering cost and budget data

• Administering financial reporting tools

• Maintaining cost models

• Assembling and producing financial reports


54

Financial Management Roles

• Financial Manager

• IT Financial Manager


• • •••

Unit 2: Service StrategyThe Process of Demand Management


Lesson 6: The Process of Demand Management


Lesson 6: The Process of Demand Management


• • • ••



Demand Management

One process of Service Management that cannot be ignored is Demand Management. Demand Management is important because customers don’t want to pay for unused resources. Although sometimes it is necessary to have surplus capacity to deliver service levels, unnecessary idle capacity can be avoided through correct Demand Management. In addition, inadequate capacity has an adverse effect on the quality and growth of delivered services. Therefore, it is essential that Demand Management techniques be used.

Consumption and production produce demand in a highly synchronized pattern. The productive capacity of resources available to a service is adjusted according to demand forecasts and patterns. Some types of capacity can be quickly increased as required and released when not in use. The arrival of demand can be influenced using pricing incentives. However, it is not possible to produce and stock service output before demand actually materializes.


56

Demand Management

• Essential that Demand Management techniques be used

• Demand Management includes techniques such as: Off-peak pricing

Volume discounts Differentiated service levels


• • •••



Activity-based Demand Management

Business processes are the primary source of demand for services. Patterns of business activity (PBA) influence the demand patterns seen by the service providers. It is very important to study the business activity of the customer to identify, analyze and codify such patterns. This will provide sufficient basis for Capacity Management. Examine the business activity and plans of the customer in terms of the demand for supporting services.

Business activities drive demand for services. Customer assets such as People, Processes, and Applications generate patterns of business activity (PBA). Since PBA generate revenue, income and costs they account for a large proportion of business outcomes. Patterns of business activity (PBA) are identified, codified, and shared across process for clarity and completeness of detail.

One or more attributes such as frequency, volume, location and duration describe business activity. They are associated with requirements such as security, privacy and latency or tolerance for delays. This profile of business activity can change over time with changes and improvements in business processes, people, organization, applications and infrastructure. PBA are placed under change control.

Each PBA has to be substantially different from another PBA in order to be coded with a unique reference. Codifying patterns helps multidimensional analysis, using criteria such as likeness and nearness. This provides efficiency and robustness in developing a catalog patterns with simplification and standardization. This, in turn, reduces the number of patterns, makes analysis easier, and avoids complicated solutions.


57

Activity-based Demand Management

• PBA define dynamics of a business and include interactions with customers, suppliers, partners, and other stakeholders

• Services often directly support PBA


• • • ••



Demand Management Goal and Benefits

Demand Management is a critical aspect of service management. Poorly managed demand is a source of risk for service providers because of uncertainty in demand.

The benefits of Demand Management include:

• Reducing cost generated by excess capacity

• Creating value that provides a basis for cost recovery

• Improving quality of services by reducing insufficient capacity

• Reducing the uncertainty in demand but cannot entirely eliminate it

• Influencing the arrival of demand in specific patterns using Demand Management techniques such as:

– Off-peak pricing

– Volume discounts

– Differentiated service levels

• Predicting demand for services in the service catalog that support the process

• Predicting demand for underlying service assets that support those services


58

Demand Management Goal

The goal of demand management is to reduce cost and create value by being able to predict demand and reduce idle capacity.


• • •••



Demand Management Activities

User profiles (UP) are based on roles and responsibilities within organizations for people, and functions and operations for processes and applications. Business processes and applications are treated as users in many business contexts. Many processes are not actively executed or controlled by staff or personnel.

Process automation allows for processes to consume services on their own. Processes and applications can have user profiles.

You construct user profiles using one or more predefined PBAs UPs represent patterns that are persistent and correlated.


59

Demand Management Activities

• Study the business of the customer to identify, analyze, and codify patterns.

• Visualize the business activity and plans in terms of the demand for supporting services.

• Identify, codify, and share patterns of business activity (PBA) across process for clarity and completeness of detail.

• Construct user profiles (UPs) using one or more predefined PBAs. UPs represent patterns that are persistent and correlated.

• Associate each user profile with one or more PBAs.


• • • ••



Demand Management Interfaces

Some of the benefits for analyzing PBAs are in the form of inputs to service management functions and processes such as:

• Service Design can then optimize designs to suit demand patterns

• Service Catalog can map demand patterns to appropriate services

• Service Portfolio Management can approve investments in additional capacity, new services, or changes to services

• Service Operation can adjust allocation of resources and scheduling

• Service Operation can identify opportunities to consolidate demand by grouping closely matching demand patterns

• Financial Management can approve suitable incentives to influence demand


60

Demand Management Interfaces

Inputs to service management functions and processes:

• Service Design

• Service Catalog


• Service Operation

• Financial Management


• • •••

Unit 2: Service StrategyUnit Scenario



The scenario for Unit 1described the creation of a service that existed inside a Service Catalog.

Unit 2 discussed the details of why a Service Catalog and services exist. In addition, it focused on the strategic approach and the theoretical approach to the service delivery of those services.

For this scenario, company X has decided to bring ITIL concepts and guidelines into its organization. Service Strategy makes an effective case for the delivery of IT as a service and for a strategic, analytical, and theoretical approach to such delivery.

An organization might ask where to start if the organization has never implemented any of the ITIL activities covered.

For an organization just starting on ITIL, it is often recommended that the business looks at the services there are to manage. In addition, the organization should obtain a solid grasp of what the business requirements are with respect to each of them.

To achieve this, a Service Catalog can be established. Eventually, the more comprehensive Service Portfolio of current, under development, and planned services, can be encompassed in the overall strategic approach to ITIL. Most organizations already are performing the services that will be identified for the catalog and need to develop the official offering. For example, the organization must decide the type of service provider the IT department is within the organization. In addition, the organization must determine the specifics in regards to utility and warranty. For example, what does the service do (utility), and how well does it do it (warranty)?

Unit 1 contained a service which was a request for a project or enhancement to applications maintained by internal or external development teams. It is fairly easy to document the utility and warranty of these services. However, determining elements such as the Delivery Model or Services Model can be more challenging. The organization can go with the approach of co-sourcing, where a combination of in-sourcing and outsourcing is used to support the service for enhancements to applications.


• • • ••



Review Questions

1. Which of the following choices is not an objective of Service Strategy?

a.Determining which services to offer and to whom

b. Determining how to carry out the activities and processes required to deliver services

c. Determining how to differentiate your services from competing alternatives

d. Determining how to create value for your customers

2. Which of the following activities are included in defining the market and understanding the customer?

a.Service strategies are developed for services offered.

b. Providers differentiate their services from competing alternatives available to customers.

c. Service management offers services as part of a business strategy.

d. All of the above.

3. A software vendor decides to offer software as a service. The vendor combines the capabilities in software development with new capabilities in service management. The vendor also uses of the 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. Of which of the following Service Strategies is this situation an example?

a.Developing Service Offering

b. Defining the market

c. Developing Strategic Assets

d. Preparing for Implementation

4. Which of the following items will a Service Model not perform?

a.Codifies the service strategy for a market space

b. Documents processes and functions needed to create value

c. Describes how service assets create value for a portfolio of contracts

d. Defines nonevolving processes and functions


• • •••



5. Which is the only part of the Service Portfolio that recovers costs or earns profits?

a.Service Catalog

b. Service Pipeline

c. Customers

d. Service Concepts

6. Which of the following choices represents all the resources presently engaged or being released in various phases of the Service Lifecycle?

a.Service Catalog

b. Service Operation

c. Service Transition

d. Service Portfolio

7. Which of the following choices is the virtual projection of the actual and present capabilities of the service provider?

a.Service Catalog

b. Service Operation



8. Which of the following choices is not true about the Service Catalog?

a.It contains items that can be configured.

b. It is invisible to customers.

c. It consists of services presently active in the Service Operation phase.

d. It is useful in developing suitable solutions for customers.

9. Which of the following choices describes the purpose of Service Portfolio Management?

a.Maximizes value while managing risks and costs

b. Permits understanding of quality requirements and related delivery costs

c. Has strong links to Service Level Management

d. All of the above


• • • ••



Review Answers

1. Which of the following choices is not an objective of Service Strategy?

b. Determining how to carry out the activities and processes required to deliver services

2. Which of the following activities are included in defining the market and understanding the customer?

d. All of the above

3. A software vendor decides to offer software as a service. The vendor combines the capabilities in software development with new capabilities in service management. The vendor also uses of the 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. Of which of the following Service Strategies is this situation an example?

b. Defining the market

4. Which of the following items will a Service Model not perform?

d. Defines nonevolving processes and functions

5. Which is the only part of the Service Portfolio that recovers costs or earns profits?

a. Service Catalog

6. Which of the following choices represents all the resources presently engaged or being released in various phases of the Service Lifecycle?


7. Which of the following choices is the virtual projection of the actual and present capabilities of the service provider?

a. Service Catalog

8. Which of the following choices is not true about the Service Catalog?

b. It is invisible to customers.

9. Which of the following choices describes the purpose of Service Portfolio Management?



• • •••



Summary


62

Summary

You should now be able to:Explain the purpose of Service Strategy Explain the two elements of value: utility and warranty Describe the three types of service providers

Explain how to choose between service provider types Describe the key principles of Service Strategy Discuss the main Service Strategy processes and associated activities


• • • ••



• • • ••

3-1

Unit 3: Service Design




• • • ••



Introduction

In this unit, you will learn about Service Design.

Objectives


2

Objectives

Upon completion of this unit, you will be able to:Explain the key principles and concepts related to Service Design Discuss Service Design processes and associated activities

Describe the Service Design roles


• • •••

Unit 3: Service DesignService Design Overview


Lesson 1: Service Design Overview


Lesson 1: Service Design Overview


• • • ••



Service Design Introduction

Design and development of a new application should not be done in isolation. It should consider the impact on the following elements:

• Overall service

• Management systems and tools

• Architectures

• Technology

• Service management processes

• Necessary measurements and metrics

Such consideration ensures that the functional elements are addressed by the design. In addition, all of the management and operational requirements will be addressed as a fundamental part of the design. They will not be added as an afterthought.

When any of the individual elements of design are changed or amended, all other aspects are considered.


4

Service Design Introduction

• Main purpose is design of new or changed services being introduced into the live environment

• Service Design emphasizes a holistic approach to all aspects of design


• • •••



Five Major Aspects of Service Design

The Service Design stage starts with a set of new or changed business requirements and ends with the development of a service solution. This solution is designed to meet the documented needs of the business.

This developed solution with its Service Design Pack (SDP) is then passed to Service Transition. Service Transition will 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.


5

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


• • • ••



Service Design

The Business: Separate businesses or business clients with their individual structures and processes.

SLA: A Service Level Agreement (SLA) is a formal negotiated agreement between customers and their service provider, or between service providers. It records the common understanding about services, priorities, responsibilities, and guarantee, with the main purpose to agree on the level of service.

IT Services: Services rendered for computer-based information systems.

Support Teams: Provide support for hardware, software, and employees. This support might include supporting local machines and servers.

Service Improvement: Aligns and realigns IT services to changing business needs. This alignment is accomplished by identifying and implementing improvements to IT services. At the same time, it strives to make processes more effective and cost efficient.


• • •••



Service Strategy: Design and develop Service Management as a strategic asset. It provides a wider range of solutions to the problem of creating, maintaining, and increasing value.

Service Transition: Sets customer expectations on how the performance and use of new or changed services can be used to promote business change. In addition, it reduces known errors and minimizes risks from transitioning new or changed services into production.

Service Operation: Coordinates the activities and processes required to deliver, support, and manage services at agreed upon levels to business users and customers.

Service Portfolio: Identifies the agreed-upon scope of service

SLM: Service Level Management (SLM) ensures an agreed-upon level of IT service is provided for all current IT services. In addition, it makes certain that future services are delivered to agreed-upon targets.

SCM: Service Continuity Management (SCM) is the assessment of business impact and risk and the provision of resilience, failover, and recovery mechanisms.

Suppliers: Typically external vendors who provide services to the Service Provider.


• • • ••



Service Management: The 4 Ps

Many designs, plans, and projects fail because of a lack of preparation and management.


7

Service Management: The 4 Ps

The implementation of ITIL Service Management about preparing and planning use of the four Ps:

PeopleProcessesProducts (services, technology, and tools)Partners (suppliers, manufacturers, and vendors)


• • •••



Service Design Package (SDP)

The Service Design Package should be produced during the design stage for each new service, major change to a service, or removal of a service.


8

Service Design Package (SDP)

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


• • • ••



Contents of SDP


9

Contents of SDP

• Business Requirements

• Service Functional Requirements

• Service Level Requirements

• Organizational Readiness Assessment

• Service Lifecycle Plan


• • •••



The RACI Model

Service Design can not be successful unless the roles and responsibilities for each of the activities are clearly defined. If roles and responsibilities are not clearly defined, the decision-making process falls apart. One tool that is useful to facilitate clear decision making processes is the RACI model.


10

The RACI Model

• Responsible: The person or group responsible for completing a task

• Accountable: The individual ultimately held responsible for the task

• Consulted: The person or people whose opinions are sought

• Informed: The person or people who are given updates on the task


• • • ••



RACI-VS

Some organizations use an expanded version of RACI, called RACI-VS. The VS stands for:

Verifies: the person or group that confirms the accurate completion of acceptance criteria

Signs Off: The person with final approval and authorization before product release.

Some organizations use a RASCI model in which the S signifies Supportive. The supportive role is available when additional resources are necessary to complete the task.

RACI and other decision-making models and tools are important because they can help to avoid conflicts. In addition, they can save time because roles are defined before the decision needs to be made.

The roles of the RACI model are placed on a chart with activities, roles, and codes identified. The following steps should be used to build a RACI chart:

• Identify the activities, tasks, and processes

• Identify and define the functional roles involved

• Meet and assign the RACI codes

• Identify any gaps or overlaps for example, where there are two Vs or no Vs


11

RACI-VS

• Verifies: Person or group who confirms the accurate completion of acceptance criteria

• Signs Off: Person who finally approves and authorizes before product release


• • •••



• Distribute the chart and incorporate feedback

• Ensure that the allocations are being followed


• • • ••



Technology Considerations

When choosing tools for Service Management, it is important to remember that the tool should support the process. Often times, organizations try to change their processes to fit the tool. Although it might be necessary to make a few changes in design, the tool should support the defined process.

Some factors that should be considered when evaluating Service Management tools are:

• Data structure, data handling and integration

• Integration of components from various vendors, and the future need to apply new components

• Conformity to international open standards

• Flexibility in implementation, usage and data sharing

• Usability

• Support for monitoring service levels

• Ability to support distributed clients with a centralized shared database

• Conversion requirements for previously tracked data

• Data backup, control, and security


12

Technology Considerations for Service Design

• Identify the requirements

• Identify the products

• Apply the selection criteria

• Evaluate the products

• Develop a short list

• Score the products

• Rank the products

• Select the product


• • •••



• Support options provided by the tool vendor

• Scalability at increasing of capacity


• • • ••

Unit 3: Service DesignProcess of Service Catalog Management


Lesson 2: Process of Service Catalog Management


Lesson 2: Process of Service Catalog Management


• • •••



Service Catalog Management

Service Catalog Management (SCM) process ensures that a Service Catalog is produced and maintained. The catalog contains accurate information about all operational services and those being prepared to be run. SCM provides a single source of consistent information on all of the agreed-upon services. It also ensures that the catalog is widely available to those approved to access it.

The catalog should contain:

• View of the current IT services from the customer’s 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


14

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


• • • ••



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

The Service Catalog has two components:

The Business Service Catalog: This part contains details of all the IT services delivered to the customer. In addition, it details the relationships to the business units and the business process that rely on the IT services. This is the customer view of the Service Catalog.

The Technical Service Catalog: This part contains details of all the IT services delivered to the customer. In addition it details the relationships to all the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. This should support the Business Service Catalog and not form part of the customer view.


• • •••



Service Catalog Management Goal and Objective

The purpose of Service Catalog Management is to supply a definitive source of information on all of the agreed services. In addition, Service Catalog Management should make certain that the catalog is widely available to approved individuals.

The objective of Service Catalog Management is to manage the information contained within the Service Catalog. The information should be accurate for all services that are being run, or being prepared to run, in the live environment. Some of the information it should include is current details, status, and interfaces and dependencies.


15

Service Catalog Management Goal

• The goal of the Service Catalog Management process is to ensure that a Service Catalog is produced and maintained, containing accurate information on all operational and planned services.


• • • ••



Service Catalog Management Benefits


16

Service Catalog Management Benefits

• Through the service catalog, all areas of the business can view an accurate and consistent picture of IT services Service details Service status.

• The Service Catalog is customer focused view of the IT services in use, how they are intended to be used, the business processes they facilitate.

• Customers can view the levels and quality of service they can expect for each service


• • •••



Service Catalog Management Activities

The Service Catalog Management (SCM) process ensures that a Service Catalog is produced and maintained. The catalog contains accurate information about all operational services and those being prepared to be run. SCM provides a single source of consistent information on all of the agreed-upon services. It also ensures that the catalog is widely available to those approved to access it.


17

Service Catalog Management Activities

• Develop and document a service definition

• Develop the contents of the Service Portfolio and Service Catalog with Service Portfolio Management

• Maintain a Service Catalog and its contents

• Interface with business and IT Service Continuity Management on dependencies of business processes with supporting IT services

• Interface with support teams, suppliers, and Configuration Management on dependencies between IT and supporting services, components, and CIs

• Interface with Business Relationship Management and Service Level Management so information is aligned to business


• • • ••



Service Catalog Management Inputs

Business information from the organization includes:

• Business strategy

• IT strategy

• Business plans

• Financial plans

• Information on their current and future requirements from the Service Portfolio

The Business Impact Analysis provides information on the impact, priority, and risk associated with each service or changes to service requirements.

The business requirements provide details of any agreed, new, or changed business requirements from the Service Portfolio.


18

Service Catalog Management Inputs

• Business information from the organization

• Business Impact Analysis

• Business requirements The Service Portfolio

• The Configuration Management System

• Feedback from all other processes


• • •••



Service Catalog Management Outputs

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. 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.


19

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


• • • ••



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 active service provided by the service provider or service being moved into the production environment

• Current status of each of these services

• Interface dependencies


• • •••



Service Catalog Management KPIs


20

Service Catalog Management KPIs

• The number of services recorded and managed within the Service Catalog as a percentage of those being delivered and transitioned in the live environment

• The number of variances detected between the information contained within the Service Catalog and the actual situation


• • • ••



SCM Challenges, Success Factors, and Risks

The major challenge to Service Catalog Management maintaining an accurate Service Catalog as part of a Service Portfolio. It is difficult to integrate both the Business Service Catalog and the Technical Service Catalog as part of an overall Configuration Management System (CMS) and Service Knowledge Management System (SKMS). The best approach to this difficulty, is to develop stand-alone spreadsheets or databases before trying to integrate the Service Catalog and Service Portfolio into the CMS or SKMS. Cooperation and acceptance by the members of the organization will help facilitate the process. This acceptance will often support the standardization of the Service Catalog and Service Portfolio.

The risks associated with the provision of an accurate Service Catalog include:

• Inaccuracy of catalog data Catalog data without appropriate change control

• Poor acceptance and usage of the Service Catalog and Service Portfolio

• Inaccuracy of service information received from the business, IT and the Service Portfolio

• Lack of tools and resources required to maintain the information

• Poor access to accurate Change Management information and processes


21

SCM Success Factors

• An accurate Service Catalog

• User awareness of the services being provided to them

• IT staff awareness of the technology supporting the services


• • •••



• Poor access to and support of appropriate and accurate CMS and SKMS

• Information that is either too detailed too high a level to maintain or be of any value


• • • ••



Service Catalog Manager

The main role of the Service Catalog Management Process is Service Catalog Manager. The Service Catalog Manager has responsibility for producing and maintaining the Service Catalog.


22

Service Catalog Manager

• Ensures all operational service and all services being prepared for operational running are recorded within the Service Catalog

• Ensues all information within Service Catalog is accurate and up to date

• Ensures all information within Service Catalog is consistent with information within Service Portfolio

• Ensues information within Service Catalog is adequately protected and backed up


• • •••

Unit 3: Service DesignService Level Management


Lesson 3: Service Level Management


Lesson 3: Process of Service Level Management


• • • ••



Service Level Management (SLM) Concepts

SLM is the name given to the processes of planning, coordinating, drafting, agreeing upon, monitoring, and reporting of Service Level Agreements (SLAs). It is the ongoing review of service achievements to ensure that the required and cost-justifiable service quality is maintained and gradually improved. SLM is concerned with:

• Ensuring that current services and SLAs are managed

• Ensuring that new requirements are captured

• Ensuring that new or changed services and SLAs are developed to match the business needs and expectations

Service Level Agreements (SLAs) provide the basis for managing the relationship between the service provider and the customer. SLM provides that central point of focus for a group of customers, business units or lines of business.

SLM is also responsible for ensuring that all targets and measures agreed upon in SLAs with the business have the following support:

• Appropriate underpinning Operational Level Agreements (OLAs) or contracts

• Internal support units


24

Service Level Management (SLM) Concepts

• SLM is the name given to the processes of planning, agreeing to, monitoring, and reporting of SLAs, and the ongoing review of service achievements to ensure that quality is maintained and improved

• An SLA is a written agreement between an IT service provider and the IT customers, defining the key service targets and responsibilities of both parties

• An Operational Level Agreement (OLA) is an agreement between an IT service provider and another part of the same organization, for example, a facilities department that maintains the air conditioning or network support team that supports the network service


• • •••



• External partners

• External suppliers

An Operational Level Agreement (OLA) is an agreement between an IT service provider and another part of the same organization that assists with services.


• • • ••



Service Level Agreements, Operational Level Agreements, and Underpinning Contracts


25


• Service Level Agreement (SLA)Key service targets and responsibilities of both parties

• Operational Level Agreement (OLA)Internal departments or organizations

• Underpinning Contract (UC)A contract with an external organization


• • •••





• • • ••



Service Level Agreement

A Service Level Agreement (SLA) is a written agreement between an IT service provider and the IT customers. An SLA defines the key service targets and responsibilities of both parties. The elements of the SLA must be written in measurable terms. The emphasis must be on agreement. SLAs should not be used as a way of holding one side or the other to ransom. A true partnership should be developed between the IT service provider and the customer, so that a mutually beneficial agreement is reached. Otherwise the SLA might quickly fall into disrepute, with each side blaming the other for perceived faults and transgressions. The resulting environment will prevent any true service quality improvements from taking place.

There are three SLA structures that can be developed according to the needs of the organization.

• Service-based SLA: This is an agreement that covers one service, for all the customers of that service

• Customer-based SLA: This is an agreement with an individual customer group, covering all the services they use


27

Service Level Agreement

• A written agreement between an IT service provider and the IT customers

• Defines the key service targets and responsibilities of both parties in measureable terms

• True partnership between IT service provider and customer

• Three SLA structures:

Service-based SLACustomer-based SLA

Multi-level SLA


• • •••



• Multi-level SLA: Such a structure allows SLAs to be kept to a manageable size, avoids unnecessary duplication, and reduces the need for frequent updates. An example of this structure would be a three-layer structure such as:

– Corporate level: Covering all the generic SLM issues appropriate to every customer throughout the organization

– Customer level: Covering all SLM issues relevant to the particular customer group or business unit, regardless of the service being used

– Service level: Covering all SLM issues relevant to the specific service, in relation to a specific customer group


• • • ••



Operational Level Agreement

An Operational Level Agreement (OLA) is an agreement between an IT service provider and another part of the same organization that assists with services. Examples of such divisions include:

• Facilities department that maintains the air conditioning

• Network support team that supports the network service

An OLA should contain targets that underpin those within an SLA to ensure that targets will not be breached by failure of the supporting activity.

Formal contracts are appropriate for external supply arrangements that significantly contribute to the business. Contracts provide binding legal commitments between customer and supplier. Contracts cover the obligations each organization has to the other from the first day of the contract. Often contractual obligations extend beyond the end of the contract. A contract is used as the basis for external supplier agreements where an enforceable commitment is required. High-value relationships, strategic relationships, or both are underpinned by formal contracts. The formality and binding nature of a contract are not at odds with the culture of a partnership agreement, but rather form the basis on which trust in the relationship might be founded.


28

Operational Level Agreement

• Agreement between IT service provider and another part of the same organization that helps provide services

• Should contain targets that underpin those within an SLA to ensure that targets will not be breached by failure of the supporting activity


• • •••



Underpinning Contracts

An underpinning contract is likely to be structured with the following sections:

• The main body containing the commercial and legal clauses

• Elements of a service agreement, as described earlier, attached as schedules

• Other related documents as schedules, for example:

– Security requirements

– Business continuity requirements

– Mandated technical standards

– Migration plans (agreed prescheduled change)

– Disclosure agreements


29

Underpinning Contracts

• Provide binding legal commitments between customer and supplier

• Cover the obligations each organization has to the other from the first day of the contract

• Likely to be structured with the following sections:Main body containing commercial and legal clauses

Elements of a service agreement

Other related documents, such as schedules


• • • ••



Service Level Management Goals

The SLM process works to ensure that all operational services and their performance are measured in a consistent, professional manner throughout the IT organization. In addition, it works to guarantee that the services and the reports produced meet the needs of the business and the customers.


30

Service Level Management (SLM) Goals

• Goal is to ensure that an agreed-upon level of IT service is provided for all current IT services

• SLM tries to make sure that future services are delivered to agreed-upon targets

• Proactive measures taken to seek and implement improvements to the level of service delivered


• • •••



SLM Objectives


31

Service Level Management Objectives

• Define, document, agree to, monitor, measure, report, and review the level of IT services provided

• Provide and improve relationship and communication with business and customers

• Ensure specific and measurable targets are developed for all IT services

• Monitor and improve customer satisfaction with quality of service delivered

• Ensure IT and customers have a clear and unambiguous expectation level of service to be delivered

• Ensure proactive measures to improve levels of service delivered are implemented whenever cost justifies it


• • • ••



SLM Benefits

Service Level Management (SLM) provides a consistent interface to the business for all service-related issues. It provides the business with the agreed-upon service targets and the required management information to ensure that those targets have been met. When targets are breached, SLM should provide feedback on the cause of the breach. In addition, it should give details of the actions taken to prevent the breach from recurring. Therefore, SLM provides a reliable communication channel and a trusted relationship with the appropriate customers and business representatives.


32

Service Level Management Benefits

• Provides a consistent interface to the business for all service-related issues

• Provides the business with the agreed-upon service targets

• Provides the required management information to ensure that targets have been met


• • •••



SLM Concerns


33

SLM Concerns

• Ensuring that current services and SLAs are managed

• Ensuring that new requirements are captured

• Ensuring that new or changed services and SLAs are developed to match the business needs and expectations


• • • ••



Service Level Management Activities

Review meetings must be held on a regular basis with customers to review the service achievement in the last period and to preview any issues for the coming period. It is normal to hold such meetings monthly or, as a minimum, quarterly.

Customers and appropriate IT managers should receive reports a few days before service level reviews. These reports will help facilitate the resolution of any queries or disagreements before the review meeting. These reports should incorporate details of performance against all SLA targets and any actions being undertaken to improve service quality.

The report can include a SLA Monitoring (SLAM) chart at the front to provide an overview of how achievements have measured up against targets. These are most effective if color coded red, amber, and green (RAG).

These service reports should detail current performance against targets and historic information on past performance and trends. Therefore, the impact of improvement actions can be measured and predicted.

The key activities within the SLM process should include:

• Determine, negotiate, document, and agree upon requirements for new or changed services in SLRs

• Manage and review the requirements throughout the Service Lifecycle into SLAs for operational services


• • •••



• Monitor and measure service performance achievements of all operational services against targets within SLAs

• Collate, measure and improve customer satisfaction

• Produce service reports

• Conduct service review and instigate improvements within an overall Service Improvement Plan (SIP)

• Review and revise SLAs, service scope OLAs, contracts, and any other underpinning agreements

• Develop and document contacts and relationships with the business, customers, and stakeholders

• Develop, maintain, and operate procedures for:

– Logging, assigning, and resolving all complaints

– Logging and distributing compliments

• Provide the appropriate management information to aid performance management and demonstrate service achievement

• Provide and maintain up-to-date SLM document templates and standards


• • • ••



Service Level Management Input

Many sources of information are relevant to the Service Level Management process. These should also include:

• Business Impact Analysis that providing information about the impact, priority, risk, and number of users associated with each service

• Business requirements: details of any agreed-upon, new, or changed business requirements

• The strategies, policies, and constraints from Service Strategy

• CMS containing information about the relationships between the business services, the supporting services. and the technology

• Customer and user feedback, complaints, and compliments

• Other inputs, including:

– Advice, information, and input from any of the other processes (such as Incident Management, Capacity Management, and Availability Management)

– Existing SLAs, SLRs, and OLAs

– Past service reports on the quality of service delivered


35

Service Level Management Input

• Business information from business strategy, plans, and financial plans and information about their current and future requirements of the organization

• The Service Portfolio and Service Catalog

• Change information from the Change Management process with a forward schedule of changes and a need to assess all changes for their impact on all services


• • •••



Service Level Management Output

The outputs of Service Level Management should include:

• Service Reports: Reports that provide details of the service levels achieved in relation to the targets contained within SLAs. These reports should contain details of all aspects of the service and its delivery, including:

– Current and historical performance

– Breaches and weaknesses

– Major events

– Changes planned

– Current and predicted workloads

– Customer feedback

– Improvement plans

– Activities

• Service Improvement Plan (SIP): Overall program or plan of prioritized improvement actions, encompassing all services, all processes, associated impacts, and risks.


36

Service Level Management Output

• Service reports • Service Improvement Plan (SIP)

• Service Quality Plan • Document templates • Service Level Agreements (SLAs) • Service Level Requirements (SLRs)

• Operational Level Agreements (OLAs) • Service review meeting minutes and actions

• SLA review and service scope review meeting minutes • Revised contracts


• • • ••



• Service Quality Plan: Plan that encompasses documenting and planning the overall improvement of service quality.

• Document templates: Standard document templates, format, and content for SLAs, SLRs, and OLAs, aligned with corporate standards.

• Service Level Agreements (SLAs): Set of targets and responsibilities that should be documented and agreed to within an SLA for each operational service.

• Service Level Requirements (SLRs): Set of targets and responsibilities should be documented and agreed within an SLR for each proposed new or changed service.

• Operational Level Agreements (OLAs): Set of targets and responsibilities should be documented and agreed to within an OLA for each internal support team.

• Reports on OLAs: Reports based on the service levels promised in the operating level agreement and underpinning contracts.

• Service Review Meeting Minutes and Actions: All meetings should be scheduled on a regular basis; their planned agendas, discussions, and actions recorded; and their progress documented.

• SLA review and Service Scope Review Meeting Minutes: Summaries of agreed-upon actions and revisions to SLAs and service scope.

• Revised Contracts: Changes to SLAs or new SLRs might require existing underpinning contracts to be changed or new contracts to be negotiated and agreed upon.


• • •••



SLM: Key Performance Indicators (KPIs)

Key Performance Indicators (KPIs) and metrics can be used to judge the efficiency and effectiveness of the SLM activities and the progress of the SIP. These metrics should be developed from the service, customer, and business perspective and should cover both subjective and objective measurements.

Objective measurements include the following items:

• Number or percentage of service targets being met

• Number and severity of service breaches

• Number of services with up-to-date SLAs

• Number of services with timely reports and active service reviews.

Subjective measurements include improvements in customer satisfaction.

The SLM process often generates a good starting point for a Service Improvement Plan (SIP). The Service Review process might inspire this process, but all processes and all areas of the service provider organization should be involved in the SIP.

When an underlying difficulty has been identified that adversely affects service quality, SLM must act with Problem Management and Availability Management, instigate a SIP. They must identify and implement whatever actions are necessary to overcome the


37

SLM: Key Performance Indicators (KPIs)

• Number or percentage of service targets being met

• Number and severity of service breaches

• Improvements in customer satisfaction


• • • ••



difficulties and restore service quality. SIP initiatives might also focus on such issues as user training, service and system testing, and documentation. In these cases, the relevant people need to be involved and adequate feedback given to make improvements for the future. At any time, a number of separate initiatives that form part of the SIP might be running in parallel to address difficulties.

If an organization is outsourcing its Service Delivery to an external vendor, the issue of service improvement should be discussed at the outset. In addition, it should be covered and budgeted for in the contract. Otherwise, the supplier has no incentive during the lifetime of the contract to improve service targets. Incentive is especially lacking if contractual obligations are already being met and additional expenditure is needed to make the improvements.


• • •••



SLM Challenges, Success Factors, and Risks

One challenge faced by SLM is that of identifying suitable customer representatives with whom to negotiate. Who owns the service? In some cases, this answer might be obvious. A single customer manager might be willing to act as the signatory to the agreement. In other cases, it might require negotiating or cajoling to find a representative volunteer. Volunteers often want to express their personal views rather than represent a consensus. It might be necessary for all customers to sign the agreement.

Sometimes customer representatives can genuinely represent the views of the customer community. Perhaps they frequently meet with a wide selection of customers. This situation is ideal. Unfortunately, often representatives are from the head office and seldom meet service customers. In the worst case, SLM might have to perform their own program of discussions and meetings with customers to ensure that true requirements are identified.

An example of differing needs of an organization:

Regarding negotiating the current and support hours for a large service, an organization found a discrepancy. This discrepancy was in the required time of usage between Head Office and the customers of a field office. Head Office (with a limited user population) wanted service hours covering 8:00 a.m. to 6:00 p.m., whereas the field office (with at least 20 times the user population) stated that starting an hour earlier would be better. However, all offices closed to the public by 4:00 p.m. at the latest, and would not require a service much after 4:00 p.m. Head Office was given preference, and so the 8:00 a.m. to 6:00 p.m. hours of operation were set. The service was put into use and monitored. It was found that


38

SLM Challenges

• Serviceability: Ensure that the Service Provider can actually meet the terms of the SLAs

• Utility: Ensure the requirements presented actually represent the customer needs

• Identifying suitable customer representatives with whom to negotiate who are genuinely able to represent the views of the customer community

• Existing service issues interfere with establishing the longer term requirements

• Staffing at different levels within the customer community may have different objectives and perceptions


• • • ••



service extensions were typically requested by the field office to cover the extra hour in the morning. Actual usage figures showed that the service was not used after 5:00 p.m., except on very rare occasions. The Service Level Manager was blamed by the IT staff for having to cover a late shift. In addition, the customer representative blamed the Service Level Manager for charging for an unused service that included staff and running costs.

Care should be taken when opening discussions on service levels for the first time. It is likely that current issues (the failure that occurred yesterday) or long-standing grievances (that old printer that the company has been trying to get replaced for ages) are likely to be aired at the outset. Important though these might be, they must not be permitted to interfere with establishing the longer-term requirements. However, that you might have to address any issues raised at the outset before you gain the credibility to progress further.

If there has been no previous experience of SLM, then start with a draft SLA. A decision should be made regarding which service or customers are to be used for the draft. It is helpful if the selected customer is enthusiastic and wants to participate, perhaps because they are anxious to see improvements in service quality. The results of an initial customer perception survey might give pointers to a suitable initial draft SLA.

One difficulty sometimes encountered is that staff at different levels within the customer community might have different objectives and perceptions. For example, a senior manager might rarely use a service. The manager might be more interested in issues such as value for money and output. However, a junior staff member staff might use the service throughout the day and might be more interested in issues such as responsiveness, usability, and reliability. It is important that all of the appropriate and relevant customer requirements, at all levels, are identified and incorporated in SLAs.

The Service Design Package is passed from Service Design to Service Transition. The SDP details all aspects and requirements of the service. These details are provided through all of the subsequent stages of the lifecycle of the service.


• • •••



Service Level Manager

The main role of the SLM Process is that of the Service Level Manager. The Service Level Manager ensures that the aims of Service Level Management are met.


39

Service Level Manager

• Keeping aware of changing business needs

• Ensuring that the current and future service requirements of customers are identified, understood, and documented in SLA and SLR documents

• Negotiating and agreeing upon levels of service to be delivered to the customer (either internal or external)

• Formally documenting these levels of service in SLAs

• Negotiating and agreeing upon OLAs and, in some cases, other SLAs and agreements that underpin the SLAs with the customers of the service


• • • ••

Unit 3: Service DesignProcess of Capacity Management


Lesson 4: Process of Capacity Management


Lesson 4: Process of Capacity Management


• • •••



Capacity Management


41

Capacity Management

• Process that extends across the Service Lifecycle

• Supported initially in Service Strategy where decisions and analysis of business requirements customer outcomes influence the development of:

Patterns of business activity (PBA)

Levels of service (LOS)Service level packages (SLPs)

• Provides predictive and ongoing capacity indicators needed to align capacity to demand


• • • ••



Purpose and Goals of Capacity Management

The goals of the Capacity Management process are:

• To ensure that cost-justifiable IT capacity in all areas of IT always exists

• To ensure that capacity is matched to the current and future agreed-upon needs of the business in a timely manner

The Capacity Management process should:

• Be the center of all IT performance and capacity issues

• Encompass all areas of technology

• Consider space planning and environmental systems capacity

• Understand the IT and business environments including:

– The current business operation and its requirements, through the patterns of business activity

– The future business plans and requirements using the Service Portfolio

– The service targets and the current IT service operation though SLAs and Standard Operating Procedures


42

Purpose and Goals of Capacity Management

To provide a point of focus and management for all capacity-related and performance-related issues for both services and resources


• • •••



– All areas of IT technology and its capacity and performance, including infrastructure, data, environment, and applications

• Understand the potential for the delivery of new services


• • • ••



Capacity Management Objectives

The objectives of Capacity Management are to:

• Create and maintain a valid Capacity Plan reflecting the current and future needs of the business

• Give guidance to all other areas of the business and IT on capacity and performance-related issues

• Ensure that service achieves or exceeds all agreed performance targets by managing the performance and capacity of services and resources

• Help diagnose and resolve performance-related and capacity-related incidents and problems

• Assess the impact of all changes on the Capacity Plan

• Assess the impact of changes on performance and capacity of all services and resources

• Ensure the implementation of proactive performance improvement measures whenever it is cost-justifiable


43

Capacity Management Objectives

• Create and maintain a valid Capacity Plan • Give guidance to all other areas of the business and IT • Ensure that service achieves agreed performance targets • Help diagnose and resolve performance and capacity

related incidents and problems • Assess impact of changes on Capacity Plan• Assess impact of changes on performance and capacity • Ensure implementation of proactive performance

improvement measures


• • •••



Benefits of Capacity Management

Capacity Management ensures that IT resources are appropriately planned and scheduled. Therefore, the service organization can provide a consistent level of service that is matched to the current and future needs of the business. These needs are agreed and documented within SLAs and OLAs.

In conjunction with the business and their plans, Capacity Management provides a Capacity Plan. This plan outlines the IT resources and funding needed to support the business plan and a cost justification of that expenditure.


44

Benefits of Capacity Management

• Capacity Management provides information on current and planned resource utilization of individual components. This assists the organization in making confident decisions on:

Which components to upgrade When to upgrade

How much the upgrade will cost


• • • ••



Capacity Management Activities

Capacity Management three subprocesses:

• Business Capacity Management: translates business needs and plans into requirements for service and IT infrastructure. This process ensures that the future business requirements for IT services are quantified, designed, planned and implemented on schedule.

• Service Capacity Management: focuses on the management, control, and prediction of the performance lifecycle and capacity of the live, operational IT services usage and workloads. It ensures that the performance of all services is monitored and measured. In addition, it ensures that the collected data is recorded, analyzed and reported.

• Component Capacity Management: focuses on the management, control and prediction of the performance, utilization and capacity of individual IT technology components. It ensures that all components are monitored and measured. In addition, it ensures that the collected data is recorded, analyzed and reported.

Capacity Management contains activities that are both proactive and reactive. The proactive activities include:

• Preventing performance issues by taking the necessary actions before they occur


45

Capacity Management Activities

Contains three subprocesses:

• Business Capacity Management

• Service Capacity Management

• Component Capacity Management


• • •••



• Producing trends of the current component utilization

• Using trend information to estimate future requirements, and plan for upgrades and enhancements

• Modeling and trending the predicted changes in IT services

• Ensuring that upgrades are budgeted, planned and implemented before SLAs and service targets or performance issues

• Improving service performance wherever it is cost justifiable

• Adjusting and optimizing the performance of services and components

The reactive activities of Capacity Management include:

• Monitoring, measuring, reporting, and reviewing the current performance of both services and components

• Responding to all events that involve capacity, and instigating corrective action

• Reacting to and assisting with specific performance issues relating to capacity

All of the information accumulated during these activities should be stored in the Capacity Management Information System (CMIS). process. Information contained within the CMIS is stored and analyzed by all the sub-processes of Capacity Management. It is a repository that holds a number of different types of data, including business, service, resource or utilization, and financial data, from all areas of technology. The CMIS is unlikely to be a single database, and probably exists in several physical locations. The data stored in the CMIS include the following types:

• Business data

• Service data

• Component utilization data

• Financial data


• • • ••



Modeling and Trending

A prime objective of Capacity Management is to predict the behavior of IT services under a given volume and variety of work. Modeling is an activity that can be used to beneficial effect in any of the sub-processes of Capacity Management.

Baselining

The first stage in modeling is to create a baseline model that accurately reflects performance. When this baseline model has been created, predictive modeling can be done. If the baseline model is accurate, then the accuracy of the result of the potential failures and changes can be trusted. Effective Capacity Management, together with modeling techniques, facilitates Capacity Management to answer questions about what could happen in various circumstances. For example: What if the throughput of Service A doubles?

Trend Analysis

Trend analysis can be done on the resource utilization and service performance information that has been collected by the Capacity Management process. Typically, trend analysis only provides estimates of future resource utilization information.


46

Modeling and Trending

• Baselining

• Trend Analysis

• Analytical Modeling

• Simulation Modeling

• Application Sizing


• • •••



Analytical Modeling

Analytical models are representations of the behavior of computer systems using mathematical techniques. The technique of analytical modeling requires less time and effort than simulation modeling, but typically it gives less accurate results.

Simulation Modeling

Simulation involves the modeling of discrete events. An example of this is, transaction arrival rates against a given hardware configuration. This type of modeling can be very accurate in sizing new applications or predicting the effects of changes on existing application. However, it can also be very time-consuming and costly.

Application Sizing

The main objective of application sizing is to estimate the resource requirements to support a proposed change or new service. This estimate will ensure that it meets its required service levels. To achieve this goal, application sizing has to be an integral part of the Service Lifecycle.

Application sizing has a finite life span. It is initiated at the design stage for a new service, or when there is a major change to an existing service, and is completed when the application is accepted into the live operational environment. Sizing activities should include all areas of technology related to the applications, and not just the applications themselves. These areas should include the infrastructure, environment, and data. Application sizing will often use modeling and trending techniques.

The sizing of the application should be refined as the design and development process progresses.


• • • ••



Capacity Management Inputs

Other sources of input include:

• Financial information from Financial Management Change information from the Change Management process

• Performance information from the Capacity Management Information System (CMIS) on the current performance of all services and IT infrastructure components

• Information on the relationships between the business, the services, the supporting services and the technology from the CMS

• Workload information from the IT Operations team


47

Capacity Management Inputs

• Business information from the business strategy, plans, financial plans, and current and future requirements

• Service and IT information from Service Strategy, the IT strategy and plans, and current budgets

• Component performance and capacity information from manufacturers and suppliers

• Service performance issues from the Incident and Problem Management processes with incidents and problems relating to poor performance

• Service information from the SLM process


• • •••



Capacity Management Outputs

Further examples of information Capacity Management provides include:

• Workload analysis and reports: used by IT Operations to assess and implement changes in conjunction with Capacity Management

• Ad hoc capacity and performance reports: used by all areas of Capacity Management, IT and the business to analyze and resolve service and performance issues

• Forecasts and predictive reports: used by all areas to analyze, predict and forecast particular business and IT scenarios and their potential solutions

• Thresholds, alerts and events


48

Capacity Management Outputs

• The Capacity Management Information System (CMIS): holds the information needed by all subprocesses within Capacity Management

• The Capacity Plan: used by all areas of the business and IT management. It is acted on by the IT service provider and senior management of the organization to plan the capacity of the IT infrastructure

• Service performance information and reports: used by many other processes. For example, it assists the Financial Management process by identifying when money needs to be budgeted for IT infrastructure upgrades, or the purchase of new components


• • • ••



Capacity Management KPIs


49

Capacity Management KPIs

• Accurate business forecasts

• Knowledge of current and future technologies

• Ability to demonstrate cost-effectiveness

• Ability to plan and implement the appropriate IT capacity to match business needs


• • •••



Capacity Management Challenges, Success Factors, and Risks

Some of the challenges facing Capacity Management are:

Persuading the business to provide information on its strategic business plans

• Combining all of the CCM data into an integrated set of information that can be consistently analyzed to provide usage details for all components of the services

• Analyzing the huge amounts of information produced by BCM, SCM and CCM

Some of the major risks associated with Capacity Management include:

• A lack of commitment from the business

• A lack of appropriate information from the business on future plans and strategies

• A lack of senior management commitment

• A lack of resources for the Capacity Management process

• SCM and CCM performed in isolation

• The processes become too bureaucratic or manually intensive


50

Capacity Management Success Factors

• Accurate business forecasts

• Knowledge of current and future technologies

• Ability to demonstrate cost-effectiveness

• Ability to plan and implement the appropriate IT capacity to match business need


• • • ••



• The processes focus too much on the technology (CCM) and not enough on the services (SCM) and the business (BCM)

• The reports and information provided do not give the appropriate information to the customers and the business


• • •••



Capacity Manager

The main role for the Capacity Management process is that of Capacity Manager. A Capacity Manager is responsible for ensuring that the goals of Capacity Management are met.


51

Capacity Manager

• Ensure there is adequate IT capacity to meet required levels of service

• Ensure senior IT management is correctly advised on how to matchcapacity and demand

• Ensure use of existing capacity is optimized

• Identify, with the Service Level Manager, capacity requirements through discussions with the business users

• Understand current usage of infrastructure and IT services

• Understand the maximum capacity of each component

• Perform sizing on all proposed new services and systems to identify capacity requirements

• Forecast capacity requirements based on business plans, usage trends, and sizing of new services


• • • ••

Unit 3: Service DesignProcess of Availability Management


Lesson 5: Process of Availability Management


Lesson 5: Process of Availability Management


• • •••



Availability Management

The responsibilities of the Availability Management process include:

• Ensuring that the level of service availability delivered in all services matches or exceeds the current and future agreed-upon needs of the business in a cost-effective manner

• Providing a point of focus and management for all availability-related issues for both services and resources

• Ensuring that availability targets in all areas are measured and achieved

Availability Management should perform the following activities:

• Produce and maintain an appropriate and up-to-date Availability Plan, which reflects the current and future needs of the business

• Provide advice and guidance to all other areas of the business and IT on all availability-related issues

• Ensure that service availability objectives meet or exceed all of their agreed-upon targets by managing services and resources related to availability performance

• Assist with the diagnosis and resolution of availability-related incidents and problems


53

Availability Management

• The Availability Management process ensures that the level of service availability delivered in all services matches or exceeds the agreed upon levels in a cost effective manner

• Availability Management provides a point of focus and management for all availability related issues

• Availability Management ensures that availability targets in all areas are measured and achieved


• • • ••



• Assess the impact of all changes on the Availability Plan

• Assess the performance and capacity of all services and resources

• Ensure that proactive measures to improve the availability of services are implemented whenever the cost justifies it

Like Capacity Management, the Availability Management process and planning must be involved in all stages of the service lifecycle. The appropriate availability and resilience should be designed into services and components from the initial design stages. This early design will ensure that the availability of any new or changed service meet expected targets. In addition, it will ensure that all existing services and components continue to meet all of their targets. This concept is the basis of stable service provision.


• • •••



Availability, Reliability, Maintainability, and Serviceability

The reliability of the service can be improved by increasing the reliability of individual components. In addition, it can be improved by increasing the resilience of the service to individual component failure. An example is increasing the component redundancy by using load-balancing techniques. The reliability of the service is often measured and reported as Mean Time Between Service Incidents (MTBSI) or Mean Time Between Failures (MTBF).


54

Availability, Reliability, Maintainability, and Serviceability

• Availability: Ability of a service, component, or Configuration Item (CI) to perform the agreed-upon function when required

• Reliability: Measure of how long a service, component, or Configuration Item can perform the agreed-upon function without interruption

• Maintainability: Measure of how quickly and effectively a service, component, or Configuration Item can be restored to normal working after a failure

• Serviceability: Ability of suppliers to meet the terms of their contracts


• • • ••



Proactive Versus Reactive Availability Management


55

Proactive Versus Reactive Availability Management

• Proactive Availability Management consists of producing recommendations, plans and documents, on design guidelines and criteria for new and changed services and the continual improvement of service

• Proactive Activities are a key part of Service Design and Continual Service Improvement

• Reactive Availability Management consists of monitoring, measuring, analyzing, reporting, and reviewing all aspects of component and service availability


• • •••



Availability Management Process

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 customer’s 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 correct 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 carry out all aspects of service management. Service management is performed entirely from the perspective of what is valuable to the customer. Such an approach ensures that services not only create value for customers but also capture value for the service provider.


• • • ••



The Availability Management process continually works to ensure that all operational services meet their agreed-upon availability targets. In addition it strives to ensure that new or changed services are designed appropriately to meet their intended targets. Furthermore these goals are accomplished without compromising the performance of existing services. In order to achieve this goal, Availability Management should perform the reactive and proactive activities.

Solutions that enhance the performance of the customer assets indirectly support the achievement of the outcomes generated by those assets. Such solutions and propositions hold utility for the business. When that utility is backed by a suitable warranty, customers are ready to buy. Services are a means of delivering value to customers by facilitating outcomes customers want without owning specific costs and risks.


• • •••



Availability

Availability is the ability of a service, component, or configuration item (CI) to perform its agreed-upon function when required. It is often measured and reported as a percentage.


57

Availability

Downtime should only be included in this calculation when it occurs within the Agreed Service Time (AST), although total downtime should also be recorded and reported


• • • ••



Availability Terms


• • •••



Reliability

Reliability is a measure of how long a service, component, or CI can perform its agreed-upon function without interruption. The reliability of the service can be improved by increasing the reliability of individual components. In addition reliability can be improved by increasing the resilience of the service to individual component failure. An example is increasing the component redundancy by using load-balancing techniques.


59

Reliability is often measured and reported as Mean Time Between Service Incidents (MTBSI) or Mean Time Between Failures (MTBF)

Reliability


• • • ••



Maintainability

Maintainability is a measure of how quickly and effectively a service, component, or CI can be restored to normal operation after a failure. It is measured and reported as Mean Time To Restore Service (MTRS) and should be calculated using the formula shown in the slide.


60

Maintainability

Example: A situation where a 24 x 7 service has been running for a period of 5020 hours with only two breaks, one of 6 hours and one of 14 hours, would give the following figures:

Availability = (5020 – (6 + 14)) / 5020 x 100 = 99.60%

Reliability (MTBSI) = 5020 / 2 = 2510 hours

Reliability (MTBF) = 5020 – (6 +14) / 2 = 2500 hours

Maintainability (MTRS) = (6 + 14) / 2 = 10 hours


• • •••



Other Availability Terms


61

Other Availability Terms

• Serviceability: The ability of a supplier to meet the terms of their contract. Often this contract will include agreed-upon levels of availability, reliability, and maintainability for a supporting service or component.

• High Availability: A characteristic of the IT service that minimizes or masks the effects of IT component failure to the users of a service.

• Fault Tolerance: The ability of an IT service, component, or CI to continue to operate correctly after failure of a component part.

• Continuous Operation: An approach or design to eliminate planned downtime of an IT service. Note that individual components or CIs might not be functioning even though the IT service remains available.

• Continuous Availability: An approach or design to achieve 100% availability. A continuously available IT service has no planned or unplanned downtime.


• • • ••



Availability Management Goals


62

Availability Management Goals

• to ensure that the level of service availability delivered in all services meets or exceeds the current and future agreed needs of the business

• to ensure delivered services are met or exceeded, cost-effectively


• • •••



Availability Objectives


63

Availability Management Objectives

• Produce and maintain a current and accurate Availability Plan that reflects current and future needs of the business

• Provide advice and guidance to all other areas of the business and IT on all availability related issues

• Ensure that service availability achievements meet or exceed allagreed targets

• Assist with diagnosis and resolution of availability related incidents and problems

• Assess impact of all changes on the Availability Plan and performance and capacity of all services and resources

• Ensure that proactive measures to improve the availability of services are implemented wherever it can be cost justified


• • • ••



Availability Management Benefits


64

Availability Management Benefits

• Ensures availability of systems and services matches evolving agreed needs of the business

• Ensures IT delivers right levels of service availability required by the business to satisfy its business objectives and customers

Results in in customer loyalty

• Ensures not only that the availability of any new or changed service meets its expected targets, but also that all existing services and components continue to meet all of their targets


• • •••



Availability Management Activities

The responsibilities of the Availability Management process include:

• Ensuring that the level of service availability delivered in all services matches or exceeds the current and future agreed-upon needs of the business in a cost-effective manner

• Providing a point of focus and management for all availability-related issues for both services and resources

• Ensuring that availability targets in all areas are measured and achieved

Like Capacity Management, the Availability Management process and planning must be involved in all stages of the service lifecycle. All stages include strategy and design through transition and operation to improvement. The appropriate availability and resilience should be designed into services and components from the initial design stages. This early design will ensure that the availability of any new or changed service meet expected targets. It will also ensure that all existing services and components continue to meet all of their targets. These accomplishments are the basis of stable service provision.


65

Availability Management Activities

• Produce and maintain an appropriate and up-to-date Availability Plan, which reflects the current and future needs of the business

• Provide advice and guidance to all other areas of the business and IT on all availability-related issues

• Ensure service availability objectives meet or exceed all agreed-upon targets by managing services and resources related to availability performance

• Assist with diagnosis and resolution of availability-related incidents and problems

• Assess impact of all changes on Availability Plan

• Assess the performance and capacity of all services and resources

• Ensure proactive improvements to availability are implemented


• • • ••



Availability Management Interfaces

Availability Management commences as soon as the availability requirements for an IT Service are clear enough to be articulated. It is an ongoing process, finishing only when the IT Service is decommissioned or retired.

The key interfaces that Availability Management has with other processes are as follows:

• Incident and Problem Management: In providing assistance with the resolution and subsequent, justification, and correction of availability incidents and problems

• Capacity Management: With the provision of resilience and spare capacity

• IT Service Continuity Management: With the assessment of business impact and risk and the provision of resilience, fail-over, and recovery mechanisms

• Service Level Management: Assistance with the determining of availability targets and the investigation and resolution of service and component breaches


66

Availability Management Interfaces

• Incident and Problem Management• Capacity Management

• IT Service Continuity Management• Service Level Management


• • •••



Availability Management Inputs

Other sources of information that Availability Management uses include:

• Change and release information from the Change Management process

• Configuration Management information on the relationships between the business, the services, the supporting services, and the technology

• Service targets from SLAs, SLRs, OLAs and contracts

• Component information on the availability, reliability, and maintainability requirements for the technology components that underpin IT services

• Technology information from the CMS on the topology and the relationships between the components and the assessment of the capabilities of new technology

• Past performance from previous measurements, achievements and reports and the Availability Management Information System (AMIS)

• Unavailability and failure information from incidents and problems


67

Availability Management Inputs


• Business impact information supported by IT services

• Previous Risk Analysis and Assessment reports and a risk register

• Service information from the Service Portfolio and the Service Catalog

• Service information: from the SLM process

• Financial information: from Financial Management


• • • ••



Availability Management Outputs

Other outputs produced by Availability Management include:

• Monitoring, management and reporting requirements for IT services and components

• An Availability Management test schedule for testing all availability, resilience and recovery mechanisms

• The planned and preventative maintenance schedules

• The Projected Service Outage (PSO) in conjunction with Change and Release Management

• Details of the proactive availability techniques and measures that will be deployed to provide additional resilience to prevent or minimize the impact of component failures on the IT service availability

• Improvement actions for inclusion within the Service Improvement Plan


68

Availability Management Outputs

• The Availability Management Information System (AMIS)

• The Availability Plan for the proactive improvement of IT services and technology

• Availability and recovery design criteria and proposed service targets for new or changed services

• Service availability, reliability and maintainability reports of achievements against targets

• Component availability, reliability and maintainability reports of achievements against targets

• Revised risk analysis reviews and reports and an updated risk register


• • •••



Availability Management KPIs

KPIs that help to manage availability and reliability of IT service include:

• Percentage reduction in the unavailability of services and components

• Percentage increase in the reliability of services and components

• Effective review and follow-up of all SLA, OLA and underpinning contract breaches

• Percentage improvement in overall end-to-end availability of service

• Percentage reduction in the number and impact of service breaks

KPIs that help to satisfy business needs for access to IT services include:

• Percentage reduction in the unavailability of services

• Percentage reduction of the cost of business overtime due to unavailable IT

• Percentage reduction in critical time failures

• Percentage improvement in business and users satisfied with service by CSS result


69

Availability Management KPIs

Types:

• KPIs that help to manage availability and reliability of IT service

• KPIs that help to satisfy business needs for access to IT services

• KPIs that help identify availability of IT infrastructure achieved at optimum costs


• • • ••



KPIs that help identify availability of IT infrastructure achieved at optimum costs include:

• Percentage reduction in the cost of unavailability

• Percentage improvement in the Service Delivery costs

• Timely completion of regular Risk Analysis and system review

• Timely completion of regular cost-benefit analysis


• • •••



Availability Management Challenges, Success Factors, and Risks

The main Critical Success Factors for the Availability Management process are:

• Manage availability and reliability of IT service

• Satisfy business needs for access to IT services

• Availability of IT infrastructure, as documented in SLAs, provided at optimum costs

Some of the major Risks associated with Availability Management include:

• A lack of commitment from the business to the Availability Management process

• A lack of commitment from the business and a lack of appropriate information on future plans and strategies

• A lack of senior management commitment to or a lack of resources, budget,or both for the Availability Management process

• The reporting processes becomes too labor intensive


70

Availability Management Challenges

• Meeting the expectations of the customers, the business and senior management

• Maintaining access to the right level of quality information on the current business need for IT services and its plans for the future

• Integrating all of the availability data into information that can be analyzed in a consistent manner to provide details on the availability of all services and components

• Convincing the business and senior management of the investment needed in proactive availability measures


• • • ••



• The processes focuses too much on the technology and not enough on the services and the needs of the business

• The Availability Management information (AMIS) is maintained in isolation and is not shared or consistent with other process areas


• • •••



Availability Manager

The main role for the Availability Management process is that of Availability Manager. The Availability Manager has responsibility for ensuring that the aims of Availability Management are met.


71

Availability Manager

• Ensures all existing services deliver the levels of availability agreed with the business in SLAs

• Assists with investigation and diagnosis of all incidents and problems that cause availability issues or unavailability of services or components

• Participates in the IT infrastructure design, including the specification of the availability requirements for hardware and software

• Proactively improves service availability wherever possible and optimizes availability of IT infrastructure

• Assists with the assessment and management of risk


• • • ••

Unit 3: Service DesignProcess of IT Service Continuity Management


Lesson 6: Process of IT Service Continuity Management


Lesson 6: Process of IT Service Continuity Management


• • •••



IT Service Continuity Management Goal

Most business processes rely heavily on technology. Therefore, it is critical that IT maintain a high level of availability. To keep technology available, it is essential to establish risk reduction measures and recovery options. The purpose of IT Service Continuity Management (ITSCM) is to maintain the necessary ongoing recovery capability within the IT services and their supporting components.

ITSCM provides a crucial role in supporting the Business Continuity Planning process. In many organizations, it is used to increase awareness of continuity and recovery requirements. In addition, it is often used to justify and implement a Business Continuity Planning process and Business Continuity Plans.


73

IT Service Continuity Management Goal

• Make certain that IT technical facilities and service facilities can be resumed within the required time frame

• These facilities include:Computer systemsNetworksApplicationsData repositoriesTelecommunicationsEnvironmentTechnical support Service Desk


• • • ••



ITSCM Objectives

ITSCM focuses on those events that the business considers significant enough to be considered a disaster. Less significant events will be dealt with as part of the Incident Management process. What constitutes a disaster will vary from organization to organization. The scope of ITSCM within an organization is determined by the organizational structure, culture, and strategic direction (both business and technology). This scope is identified in terms of the services provided and how these develop and change over time.


74

ITSCM Objectives

• Maintain IT Service Continuity and IT recovery plans

• Complete regular Business Impact Analysis exercises

• Conduct regular Risk Analysis and Management exercises

• Provide continuity and recovery advices to other areas

• Ensure continuity and recovery mechanisms are put in place

• Assess impact of all changes on continuity and recovery plans

• Ensure proactive plans are in place when necessary

• Negotiate contracts with recovery capability suppliers


• • •••



IT Service Continuity Management Benefits

ITSCM provides an important role in supporting the Business Continuity Planning process.


75

IT Service Continuity Management Benefits

• Can be used to raise awareness of continuity and recovery requirements

• Can be used to justify and implement a Business Continuity Planning process and Business Continuity Plans

• Ensures that the recovery arrangements for IT services are aligned to identified business impacts, risks and needs


• • • ••



ITSCM Activities

The ITSCM activities take place in the following stages:

Stage 1: Initiation

• Set the policy. This step should be established and communicated to all affected members of the organization.

• Specify terms of reference and scope: This step includes defining the scope and responsibilities of all staff in the organization.

• Allocate the resources. In this step financial and manpower resources are allocated.

• Define the project organization and control structure. In this step, it is recommended to use standard project planning methodology.

• Agree on project and quality plans.


76

ITSCM Activities

• Agree on scope of ITSCM process and policies

• Conduct Business Impact Analysis (BIA) of loss of IT service

• Conduct Risk Analysis (RA) to identify possibility and likelihood of threats to continuity

• Develop overall ITSCM strategy

• Develop ITSCM plan

• Test plans

• Operate and maintain plans


• • •••



Stage 2: Requirements and Strategy

• Requirements: Perform Business Impact Analysis and risk assessment. The purpose of a Business Impact Analysis (BIA) is to quantify the impact to the business that loss of service would have. The BIA identifies:

– The form that the damage or loss might take

– How the degree of damage or loss is likely to escalate and the time and severity of the service disruption

– The staffing, skills, facilities and services

– The time within which minimum levels of staffing, facilities and services should be recovered

– The time within which all required business processes and supporting staff, facilities and services should be fully recovered

– The relative business recovery priority for each of the IT services

• Strategy: Following the requirements analysis, the strategy should document the required risk reduction measures and recovery options to support the business. This is an assessment of the level of threat and the extent to which an organization is vulnerable to that threat. Risk Analysis can also be used in assessing and reducing the chance of normal operational incidents and is a technique used by Availability Management to ensure the required availability and reliability levels can be maintained.

Stages one and two are mostly Business Continuity Management (BCM) activities. ITSCM should only be involved in these stages for the following reasons:

• To support the BCM activities

• To understand the relationship between the business processes

• To understand the impacts caused by loss of IT service

As a result of these initial Business Impact Analysis and Risk Analysis activities, BCM should produce a Business Continuity Strategy. The first real ITSCM task is to produce an ITSCM strategy that supports the BCM strategy and its needs.

The Business Continuity Strategy should focus on business processes and associated issues (for example, business process continuity, staff continuity, buildings continuity).

Stage 3: Implementation


• • • ••



You can develop an ITSCM strategy that supports the Business Continuity Strategy after the following tasks have been completed:

• You have produced the Business Continuity Strategy.

• You have identified the role that IT services will provide within the strategy.

Therefore, cost-effective decisions can be made, considering all the resources needed to deliver a business process. After the strategy has been approved, the IT Service Continuity Plans must be produced in line with the Business Continuity Plans. Be sure to properly test these plans before final implementation.

Stage 4: Ongoing Operation

This stage consists of the following activities:

• Education, awareness, and training

• Review

• Testing

• Change Management

• Invocation of the Business Continuity Plans


• • •••



ITSCM Interfaces

Incident and Problem Management: This provides 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 Operation staff must recognize a security incident.

IT Service Continuity Management (ITSCM): ITSCM deals 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.

Service Level Management (SLM): SLM provides assistance with the determining of security requirements and responsibilities. It also ensures their inclusion within SLRs and SLAs. In addition, SLM promotes 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 Human Resources (HR) Department: Legal and HR issues must be considered when investigating security issues.

Configuration Management: Configuration Management gives the ability to provide accurate asset information to assist with security classifications. Having an accurate Configuration Management System (CMS) is therefore an extremely useful ISM input.


77

ITSCM Interfaces

• Incident and Problem Management

• IT Service Continuity Management (ITSCM)

• Service Level Management (SLM)


• Legal and Human Resources (HR) Department

• Configuration Management

• Capacity Management


• Supplier Management


• • • ••



Capacity Management: 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: Financial Management provides adequate funds required to finance security requirements.

Supplier Management: Supplier Management assists with the joint management of suppliers and their access to services and systems. In addition, it makes available the terms and conditions to be included within contracts concerning supplier responsibilities.

Security is often seen as an element of Availability Management with Confidentiality Integrity and Availability (CIA) being at the essence of Availability and ISM. Also ISM should work with both Availability Management and IT Service Continuity Management (ITSCM) to conduct integrated risk assessment and management exercises.


• • •••



ITSCM Inputs

There are many sources of input required by the ITSCM process. Some of them are:


• IT information from the IT strategy and plans and current budgets

• A Business Continuity Strategy and a set of Business Continuity Plans from all areas of the business


• Financial information from Financial Management

• Configuration Management System containing information on the relationships between the business, the services, the supporting services and the technology

• Business Continuity Management and Availability Management testing schedules

• IT Service Continuity Plans and test reports from supplier and partners, where appropriate


78

ITSCM Inputs

• Business information

• IT information

• A Business Continuity Strategy and a set of Business Continuity Plans

• Service information

• Financial information

• Configuration Management System

• Business Continuity Management and Availability Management testing schedules

• IT Service Continuity Plans and test reports


• • • ••



ITSCM Outputs

ITSCM plans include:

• Crisis Management plans

• Emergency Response plans

• Disaster Recovery plans

Business Impact Analysis exercises and reports are produced in conjunction with Business Continuity Management and the business.

Risk Analysis and Management reviews and reports are produced in conjunction with the business, Availability Management, and Security Management.


79

ITSCM Outputs

• A revised ITSCM policy and strategy

• A set of ITSCM plans

• Supporting plans and contracts with recovery service providers

• Business Impact Analysis exercises and reports

• Risk Analysis and Management reviews and reports

• An ITSCM testing schedule

• ITSCM test scenarios

• ITSCM test reports and reviews


• • •••



ITSCM KPIs

ITSCM should include:

• Regular audits of the ITSCM Plans to ensure that, at all times, the agreed recovery requirements of the business can be achieved

• All service recovery targets are agreed and documented in SLAs and are achievable within the ITSCM Plans

• Regular and comprehensive testing of ITSCM Plans

• Regular reviews are undertaken of the business and IT continuity plans with the business areas

• Negotiation and management of all necessary ITSCM contracts with third party

• Overall reduction in the risk and impact of possible failure of IT services


80

ITSCM Key Performance Indicators

• Regular audits of the ITSCM Plans

• All service recovery targets agreed on and documented in SLAs

• Testing of ITSCM Plans • Regular reviews

• Negotiation and management of contracts• Reduction in the risk and impact of possible failure

• Notification of the plans


• • • ••



• Notification throughout the organizations of the plans. This ensures:

– Awareness of business impact, needs, and requirements throughout IT

– That all IT service areas and staff are prepared and able to respond to an invocation of the ITSCM Plans

– Regular communication of the ITSCM objectives and responsibilities within the appropriate business and IT service areas


• • •••



ITSCM Challenges, Critical Success Factors, and Risks

The main Critical Success Factors for the ITSCM process are:

• IT services are delivered and can be recovered to meet business objectives.

• Awareness throughout the organization of the business and IT Service Continuity Plans.

Some of the major risks associated with ITSCM include:

• Lack of commitment from the business to the ITSCM processes and procedures

• Lack of commitment from the business and a lack of appropriate information on future plans and strategies

• Lack of senior management commitment or a lack of resources and/or budget for the ITSCM process

• The processes focus too much on the technology issues and not enough on the IT services and the needs and priorities of the business


81

ITSCM Challenges

• providing appropriate plans when there is no BCM process

• ensuring that accurate information is obtained from the BCM process on the needs, impact and priorities of the business

• ensuring that the ITSCM information and plans are aligned and integrated with those of the business

• keeping them aligned by management and control of business and IT change


• • • ••



• Risk Analysis and Management are conducted in isolation and not in conjunction with Availability Management and Security Management

• ITSCM plans and information become out-of-date and lose alignment with the information and plans of the business and BCM


• • •••



Service Continuity Manager

The main role for the ITSCM process is that of IT Service Continuity Manager. The IT Service Continuity Manager has responsibility for ensuring that the aims of ITSCM Management are met.

Further responsibilities for this role include:

• Assessing potential service continuity issues and invoking the Service Continuity Plan if necessary

• Managing the Service Continuity Plan while it is in operation, including fail-over to a secondary location and restoration to the primary location

• Performing post mortem reviews of service continuity tests and invocations, and instigating corrective actions where required

• Developing and managing the ITSCM plans to ensure that, at all times, the recovery objectives of the business can be achieved

• Ensuring that all IT service areas are prepared and able to respond to an invocation of the continuity plans

• Maintaining a comprehensive IT testing schedule, including testing all continuity plans in line with business requirements and after every major business change


82

Service Continuity Manager

• Performing Business Impact Analyzes for all existing and new services

• Implementing and maintaining the ITSCM process

• Ensuring that all ITSCM plans, risks and activities underpin and align with all BCM plans, risks and activities

• Ensuring the ITSCM plans are capable of meeting the agreed and documented targets under any circumstances

• Performing risk assessment and risk management to prevent disasters where cost-justifiable and where practical

• Developing and maintaining the continuity strategy


• • • ••



• Undertaking quality reviews of all procedures and ensuring that these are incorporated into the testing schedule

• Communicating and maintaining awareness of ITSCM objectives within the business areas supported and IT service areas

• Undertaking regular reviews, at least annually, of the Continuity Plans with the business areas to ensure that they accurately reflect the business needs

• Negotiating and managing contracts with providers of third-party recovery services

• Assessing changes for their impact on Service Continuity and Continuity Plans

• Attending CAB meetings when appropriate


• • •••

Unit 3: Service DesignProcess of Information Security Management


Lesson 7: Process of Information Security Management


Lesson 7: Process of Information Security Management


• • • ••



Information Security Management (ISM)

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.

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. 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 enforcing appropriate security controls in all areas of IT. In addition, it manages IT risk in line with business and corporate risk management processes and guidelines.


84

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


• • •••



Security Framework

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


85

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


• • • ••



Contents of the Information Security Policy (ITP)

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 and 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 antivirus policy

• An information classification policy

• A document classification policy


86

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 antivirus policy• An information classification policy

• A policy with regard to supplier access of IT service, information and components

• An asset disposal policy


• • •••



• 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.


• • • ••



Information Security Process


• • •••



Information Security Management Goal and Objectives

The goal of the Information Security Management (ISM) process is to align IT security with business security. In addition, it ensures that information security is effectively managed in all service and Service Management activities.


88

Information Security Management Objectives

• 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)

• Business transactions as well as information exchanges between enterprises, or with partners, can be trusted (authenticity and nonrepudiation)


• • • ••



Information Security Management Benefits


89

Information Security Management Benefits

• Ensures that an Information Security Policy is maintained and enforced that fulfills the needs of the Business Security Policy and the requirements of corporate governance

• Raises awareness of the need for security within all IT services and assets throughout the organization, ensuring that the policy is appropriate for the needs of the organization

• Manages all aspects of IT and information security within all areas of IT and Service Management activity

• Provides assurance of business processes by:enforcing appropriate security controls in all areas of IT managing IT risk in line with business and corporate risk management processes and guidelines


• • •••



Information Security Management Activities

The key activities within the ISM process are:

• Production, review, and revision of an overall Information Security Policy and a set of supporting specific policies

• Communication, implementation, and enforcement of the security policies

• Assessment and classification of all information, assets, and documentation

• Implementation, review, revision, and improvement of a set of security controls and risk assessment and responses

• Monitoring and management of all security breaches and major security incidents

• Analysis, reporting, and reduction of the volume and impact of security breaches and incidents

• Schedule and completion of security reviews, audits, and penetration tests


90

Information Security Management Activities

• Production, review and revision of security policy

• Communication, implementation, and enforcement of security policy

• Assessment and classification

• Monitoring and management of security breaches and incidents

• Schedule and completion


• • • ••



Information Security Management Interfaces

Incident and Problem Management: This provides 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 Operation staff must recognize a security incident.

IT Service Continuity Management: ITSCM deals 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.

Service Level Management: SLM provides assistance with the determining of security requirements and responsibilities. It also ensures their inclusion within SLRs and SLAs. In addition, SLM promotes 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 Human Resources Department: Legal and HR issues must be considered when investigating security issues.

Configuration Management: Configuration Management gives the ability to provide accurate asset information to assist with security classifications. Having an accurate Configuration Management System (CMS) is therefore an extremely useful ISM input.


91

Information Security Management (ISM) Interfaces


• IT Service Continuity Management

• Service Level Management


• Legal and Human Resources Department




• Supplier Management


• • •••



Capacity Management: 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: Financial Management provides adequate funds required to finance security requirements.

Supplier Management: Supplier Management assists with the joint management of suppliers and their access to services and systems. In addition, it makes available the terms and conditions to be included within contracts concerning supplier responsibilities.

Security is often seen as an element of Availability Management with Confidentiality Integrity and Availability (CIA) being at the essence of Availability and ISM. Also ISM should work with both Availability Management and IT Service Continuity Management (ITSCM) to conduct integrated risk assessment and management exercises.


• • • ••



Information Security Management Inputs


• Corporate governance and business security policies and guidelines, security plans, and risk analysis and responses

• IT information from the IT strategy, plans, and current budgets

• Service information from the SLM process with details of the services from the Service Portfolio and the Service Catalog, SLAs, and SLRs

• Risk Analysis processes and reports from ISM, Availability Management, and ITSCM

• Details of all security events and breaches from all areas of IT and SM, especially Incident Management and Problem Management

• Change information from the Change Management process to assess all changes for their impact on security policies, plans, and controls

• CMS containing information on the relationships between the business, the services, supporting services, and the technology

• Details of partner and supplier access from Supplier Management and Availability Management on external access to services and systems


92

Information Security Management Inputs


• Corporate governance and business security policies • IT information

• Service information • Risk Analysis processes and reports

• Details of all security events and breaches • Change information

• Configuration Management System• Details of partner and supplier access


• • •••



Information Security Management Outputs

• An overall Information Security Management Policy with a set of specific security policies

• A Security Management Information System (SMIS) that contains all the information relating to ISM

• Revised security risk assessment processes and reports

• A set of security controls with details and risks of the operation and maintenance

• Security audits and audit reports

• Security test schedules and plans, including security penetration tests and other security tests and reports

• A set of security classifications and a set of classified information assets

• Reviews and reports of security breaches and major incidents

• Policies, processes, and procedures for managing partners and suppliers and their access to services and information


93

Information Security Management Outputs

• Information Security Management Policy

• Security Management Information System (SMIS)

• Revised security risk assessment

• A set of security controls

• Security audits

• Security test schedules and plans

• A set of security classifications

• Reviews and reports

• Policies, processes and procedures


• • • ••



Information Security Management KPIs

Further Information Security Management KPIs include:

• The number of suggested improvements to security procedures and controls

• Decrease in the number of security nonconformance detected during audits and security testing

• Increase in the number of services and processes that conform with security procedures and controls

• Increased awareness of the security policy and its contents, throughout the organization

• Percentage increase in completeness of the technical Service Catalog against IT components supporting the services

• Service Desk supporting all services


94

Information Security Management KPIs

• Percentage decrease in security breaches reported to the Service Desk

• Percentage decrease in the impact of security breaches and incidents

• Decrease in the number of non-conformances of the ISM process with the business security policy and process

• Increase in the acceptance and conformance of security procedures

• Increased support and commitment of senior management


• • •••



ISM Challenges, Success Factors, and Risks

ISM has the following main critical success factors:

• Protection against security violations

• Determination of a concise policy, integrated with the needs of the business

• Justification of security procedures that are appropriate and supported by senior management

• Education for and marketing of security requirements

• Establishment of a mechanism for improvement

• Integration of information security in all IT services and ITSM processes

• Protection of the availability of services against security incidents

• Establishment of clear ownership of the security policies among the customer community


95

Information Security Management Challenges

• Ensuring there is enough support from the business, business security, and senior management

• Ensuring that accurate information is obtained from the business security process on the needs, risks, impact, and priorities of the business

• Ensuring that the ISM policies, information, and plans are aligned and integrated with those of the business

• Keeping the policy, information, and plans aligned by management and control of business and IT change using strict Change Management and Configuration Management control


• • • ••



Some of the risks that threaten effective ISM include:

• Increasing requirements for availability and robustness

• Growing potential for misuse and abuse of information systems affecting privacy and ethical values

• External dangers from hackers, leading to denial of service, virus attacks, extortion, industrial espionage, and organizational or private data leaks


• • •••



Security Manager

The Security Manager responsibilities explained in more detail:

• Developing, maintaining, and communicating the Information Security Policy

• Identifying and classifying IT and information assets (Configuration Items) and the level of control and protection required

• Performing security risk analysis and risk management in conjunction with Availability and IT Service Continuity Management

• Monitoring and managing all security breaches and handling security incidents and taking remedial action to prevent recurrence wherever possible

• Reporting, analyzing, and reducing the impact and volumes of all security incidents in conjunction with Problem Management

• Ensuring that all changes are assessed for impact on all security aspects

• Ensuring that the confidentiality, integrity, and availability of the services are maintained at the levels agreed upon in the SLAs

• Ensuring that all access to services by external partners and suppliers is subject to contractual agreements and responsibilities


96

Security Manager

• Managing all aspects of the Information Security Policy

• Identifying and classifying IT and information assets

• Performing security risk analysis and risk management

• Monitoring and managing all security breaches

• Reducing impact and volume of security incidents

• Ensuring all changes are assessed for impact on security

• Ensuring confidentiality, integrity, and availability are maintained

• Ensuring access to services subject to contractual agreements

• Acting as a focal point for security issues


• • • ••

Unit 3: Service DesignProcess of Supplier Management


Lesson 8: Process of Supplier Management


Lesson 8: Process of Supplier Management


• • •••



Supplier Management

Supplier Management includes the following points:

• Supplier Management process manages suppliers and the services they supply. It provides 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.


98

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


• • • ••



Supplier Management Goal and Objectives

The Supplier Management process manages suppliers and the services they supply. It provides 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.

The purpose of the Supplier Management process is to receive value for money from suppliers. In addition, it ensures that suppliers perform to the targets contained within their contracts and agreements, while conforming to the terms and conditions.

The goal of Supplier Management is to manage suppliers and their services ensuring that high quality and value is achieved.


99

Supplier Management Objectives

• Achieve value for money from supplier and contracts

• Ensure that underpinning contracts and agreements with suppliers are aligned to business needs

• Ensure contracts and agreements support and align with agreed targets in SLRs and SLAs

• Manage relationships with suppliers • Manage supplier performance

• Negotiate contracts with suppliers and manage them through their lifecycle

• Maintain a supplier policy and a supporting Supplier and Contract Database (SCD)


• • •••



Supplier Management Process


• • • ••



Supplier Management Benefits


101

Supplier Management Benefits

• Ensures the delivery to the business of quality IT services that are aligned to expectations.

• Aligns with all corporate and all other IT and SM processes requirements. This ensures that the business obtains value from supporting supplier services and that they are aligned with business needs.


• • •••



Supplier Management Activities

Supplier Management should complete the following activities:

Identify the business needs and preparation of the business case. This activity includes:

– Producing a Statement of Requirement (SOR) and/or Invitation To Tender (ITT)

– Ensuring conformance to strategy/policy

– Preparing the initial business case

– Identifying method of purchase or procurement

– Establishing evaluation criteria

– Evaluating alternative options

– Selecting and negotiating contracts, targets, and the terms and conditions

– Awarding the contract


102

Supplier Management Activities

• Identifying business needs and preparation of the business case

• Establishing new suppliers and contracts

• Categorizing suppliers and contracts

• Managing supplier and contract performance

• Managing the end of term


• • • ••



Establishing new suppliers and contracts. This activity includes:

• Setting up the supplier service and contract

• Transitioning the service

• Establishing contacts and relationships

Categorizing suppliers and contracts. This activity includes:

• Assessing the supplier and contract

• Ensuring changes are progressed through Service Transition

• Performing categorization of the supplier

• Updating the supplier contract database (SCD)

• Maintaining the SCD

Managing the supplier and contract performance. This activity includes:

• Managing the operation and delivery of services and products

• Monitoring and reporting

• Reviewing and improving

• Managing the supplier and the relationship

• Planning for closures, renewals, and extensions.

Managing the end of term. This activity includes:

• Determining the benefits delivered and ongoing requirements

• Renegotiating, renewing, terminating, or transferring


• • •••



Supplier Management Interfaces

Events that might 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


103

Supplier Management Interfaces



• Information Security Management



• Problem and Incident Management


• • • ••



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. In addition, SLM supports their inclusion in underpinning agreements and contracts. Such inclusion ensures that they support all SLR and SLA targets and 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.


• • •••



Supplier Management Inputs


• Supplier and contracts strategy from the Service Strategy processes

• Supplier plans and strategies from

• Supplier contracts, agreements and targets

• Supplier and contract performance information

• IT information from the IT strategy, plans, and current budgets

• Contract or supplier performance issues from the Incident and Problem Management processes

• Financial contract information from Financial Management


• Information from the CMS


104

Supplier Management Inputs


• Supplier and contracts strategy

• Supplier plans and strategies

• Supplier and contract performance information

• IT information

• Contract or supplier performance issues

• Financial contract information

• Service information

• Information from the CMS


• • • ••



Supplier Management Outputs


105

Supplier Management Outputs

• The Supplier and Contracts Database (SCD). This holds the information needed by all sub-processes within Supplier Management.

• Supplier and contract performance information and reports. These are used as to manage the quality of service provided by suppliers and partners.

• Supplier and contract review meeting minutes.

• Supplier Service Improvement Plans (SIPs). These are used to manage the progress of agreed improvement actions.

• Supplier survey reports.


• • •••



Supplier Management KPIs

• Business protected from poor supplier performance or disruption

– Increase in the number of suppliers meeting the targets within the contract

– Reduction in the number of breaches of contractual targets

• Supporting services and their targets align with business needs and targets

– Increase in the number of service and contractual reviews held with suppliers

– Increase in the number of supplier and contractual targets aligned with SLA and SLR targets

• Availability of services is not compromised by supplier performance

– Reduction in the number of service breaches caused by suppliers

– Reduction in the number of threatened service breaches caused by suppliers

• Clear ownership and awareness of supplier and contractual issues

– Increase in the number of suppliers with nominated supplier managers

– Increase in the number of contracts with nominated contract managers


106

Supplier Management KPIs

• Business protected from poor supplier performance or disruption

• Supporting services and their targets align with business needs and targets

• Availability of services is not compromised by supplier performance

• Clear ownership and awareness of supplier and contractual issues


• • • ••



Supplier Management Challenges, Success Factors, and Risks

The Supplier Management process has the following critical success factors:

• Business must be protected from poor supplier performance or disruption

• Supporting services and their targets must align with business needs and targets

• Service availability must not be compromised by supplier performance

• Ownership and awareness of supplier and contractual issues must be clearly defined


107

Supplier Management Challenges

• Dealing with business and IT needs that are constantly changing

• Managing a bad contract

• Dealing with lack of expertise within the organization • Being tied into long-term contracts

• Relying on supplier for a service delivery • Managing disputes over charges

• Dealing more with problems than positive actions • Managing communication issues and personality conflicts • Losing the strategic perspective


• • •••



Supplier Management faces the following risks:

• Lack of commitment from the business and senior management

• Lack of resources

• Legacy of badly written and agreed contracts

• Inability for suppliers to meet targets or terms and conditions of the contract

• Lack of cooperation from suppliers in the Supplier Management process

• Upset due to suppliers being are taken over and the resulting changes

• Excess of bureaucracy

• Poor corporate financial processes


• • • ••



Supplier Manager

The main role for the Supplier Management process is that of Supplier Manager. The Supplier Manager has responsibility for ensuring that the aims of Information Supplier Management are met.


108

Supplier Manager

• Assisting in the development and review of SLAs, contracts, and agreements

• Ensuring IT suppliers and contracts provide value for money

• Ensuring IT supplier processes are consistent and meet expectations

• Maintaining and monitoring a Supplier and Contracts Database (SCD)

• Monitoring all suppliers and contracts on a regular basis • Ensuring that underpinning contracts, agreements, and

SLAs are aligned with those of the business


• • •••



The Supplier Manager also has the following responsibilities:

• Ensuring that interfaces and dependencies between suppliers, supporting services, and supplier processes are agreed and documented

• Ensuring that all roles and relationships between lead and any sub-contracted suppliers are properly documented

• Ensuring that sub-contracted suppliers are meeting their contractual obligations

• Performing regular contract and SLA reviews

• Updating contracts or SLAs when required

• Managing an effective process for dealing with contractual disputes

• Managing expected end, early end, or transfer of a service

• Monitoring and reporting supplier performance against targets

• Identifying and implementing improvement actions as appropriate

• Ensuring changes are assessed for impact on suppliers, supporting services, and contracts

• Attending CAB meetings when appropriate

• Coordinating and supporting all individual IT supplier and contract managers


• • • ••

Unit 3: Service DesignService Design Roles


Lesson 9: Service Design Roles


Lesson 9: Service Design Roles


• • •••



IT Planner

An IT Planner is responsible for the production and coordination of IT plans. The IT Planner also has the following responsibilities:

• Evaluate supplier proposals for equipment, software, and services

• Identify internal and external factors that influence IT

• Manage the planning for the provision and use of IT architectures, products, and services

• Review IT performance Initiate improvement measures

• Manage priorities and schedules for the implementation of new or changed IT service

• Assist in formulating plans and making IT procurement decisions

• Manage all IT plans

• Conduct Post Implementation Reviews (PIRs) in conjunction with Change Management


110

IT Planner

• Develop IT plans Manage the implementation progress of all IT strategies and plans

• Develop and maintain the overall set of IT standards, policies, plans, and strategies

• Manage all aspects of IT standards, policy, and strategy implementation

• Recommend policy for the effective use of IT throughout the organization

• Review IT costs

• Manage, plan and coordinate IT systems and services


• • • ••



Service Design Manager

The Service Design Manager is responsible for the overall coordination and deployment of quality solution designs for services and processes.


111

Service Design Manager

• Ensuring the Service Design Strategies are reflected in the Service Design practice

• Ensuring the Service Designs are produced to meet and fulfill the documented business requirements

• Developing and maintaining all necessary SDPs

• Evaluating the effectiveness and efficiency of the Service Design process


• • •••



The responsibilities of the Service Design Manager also include:

• Designing the following aspects of the services:

– functional

– infrastructure

– environment applications

– data management

• Producing quality and stable designs that meet agreed current and future IT requirements for:

– new or improved services

– technology architecture

– processes

– measurement systems

• Developing and maintaining all design documentation, including:

– designs

– plans

– architectures

– policies


• • • ••

Unit 3: Service DesignUnit Scenario



Unit 1 scenario focused on the creation of a single service. Service Design brings the organization to the activities and focus of the overall Services Portfolio. The Portfolio is the full breadth of services offered to the business. These services can exist within any of the statuses that advise whether the service is available or not.

This scenario will not focus on the creation of the entire portfolio. It will focus on the creation of another service. The service is personal computer (PC) refresh. Service design uses the 4 Ps that are a focus for each service. When examining the PC refresh process the Ps might be:

• People: Users, Finance team, IMAC (desktop mobility) team, Software management

• Products: Service request for acquisition of the new equipment, software distribution tool, asset management tool for recording data

• Processes: Service Request, IMAC, and Retirement, Software reconciliation and Installation, PC wipe of data.

• Partners: Suppliers of the PCs, Retirement Company that properly disposes of PC equipment.

The 4 Ps need to be considered in the creation and definition of single services. The 4 Ps also need to be considered in the load and level of the effort.

When designing the services, it is important to establish the level of that service and how it will be monitored and measured. When considering the PC refresh, it might be critical to monitor approval times, delivery from the supplier, and delivery to the users. In addition, it will be important to check time and accuracy. For example, check how many incidents or issues the user needs to resolve with support from the Service desk, or IMAC rework team. Surveys can be another metric to get feedback from the users to indicate how smoothly the process was for them. Because all of these can be metrics, it will be important to accompany them with SLAs to ensure the delivery is meeting expectations. An example would be delivery being completed 2 weeks from request, with 1 day of interruption of user work time.

SLAs can often blend together with Availability Management. In this scenario, availability can be measured or monitored as the level of impact the swap from old PCs to new PC impacts the users. For example, to have an impact of no more than 8 hours of lost work time. Another example might be moving to proactive availability, such as pushing a communication with all necessary data to users that contains a link. This link might provide a means for the users to agree to a swap out date. Additionally, users might enter the information about the software and data they expect moved to the new PCs.


• • •••



As you learned in this unit, information security management becomes important in the services portfolio. For example, in this case, the data will be cleared from the retiring PC (person data). In addition, the management of software licenses of, for example, spyware, or antivirus software is also a big consideration. Furthermore, ensuring PC security of the old and new PCs is also necessary.

Within Service Design, it is essential to understand how the Process Owners and Service Owners work into and manage the services throughout their lifecycle. Consider the Process Owners of Configuration Management, Asset Management, Desktop or IMAC mobility team, and Change Management. Because this example is a PC process, it might be very likely be owned by the Desktop Manager.

Because this service interacts with suppliers, it is involved in managing the supplier process which is actually part of service design. Lastly, it might be necessary to ensure collaboration with the managers of other areas. For example, if this process was provided before, but manually and with out proactive processes, then other roles might need to be involved. These roles help provide automation and ensure effective and fast service to the user.

If an organization uses services such as PC refresh, they can be combined to create a complementary set of services that make up the portfolio.


• • • ••



Review Questions

1. Which of the following choices is the main purpose of the Service Design stage?

a.Minimizes the risks from transitioning the new or changed services to production

b. Coordinate the activities and process required to deliver services

c. Design of new or changed services being introduced into the production environment

d. Design and develop service management as a strategic asset

2. Which of the following choices is not one of the five individual aspects of Service Design?

a.Design of the technology architecture and management systems

b. Response to the business and IT requests for change

c. Design of the Service Portfolio, including the Service Catalog

d. Design of measurement methods and metrics

3. What type of approach should be adopted for all service design areas to ensure consistency and integration?

a.Holistic

b. Transitional

c. Isolated

d. Adaptive

4. Which of the following choices describes the value Service Design provides to the business?

a.Provides a consistent interface to the business for all service-related issues

b. Provides the business with the agreed-upon service targets

c. Provides a reliable communication channel and a trusted relationship with the appropriate customers and business representatives

d. All of the above

5. Which of the following choices are important to Service Management?

a.People

b. Processes


• • •••



c. Products

d. Partners

e. All of the above

6. Which of the following choices includes ensuring that an agreed-upon level of IT service is provided for all current IT services and that future services are delivered to agreed-upon targets?

a.Service Catalog Management

b. Service Level Management

c. Availability Management

d. Capacity Management

7. Which of the following choices is not part of the Service Level Management Process?

a.Ensure that availability targets in all areas are measured and achieved.

b. Log and manage all complaints and compliments.

c. Produce service reports.

d. Determine, negotiate, document, and agree upon the requirements for services.

8. Which of the following choices is not a responsibility for a Service Catalog Manager?

a.Ensuring that all the information within the Service Catalog is accurate and up to date

b. Ensuring that all of the information within the Service Catalog is consistent with the information in the service portfolio

c. Ensuring that the information within the Service Catalog is adequately protected and backed up

d. Ensuring that the current and future service requirements of customers are identified, understood, and document in SLA and SLR documents

9. Which of the following choices is not a responsibility for an Availability Manager?

a.Proactively improves service availability wherever possible and optimizes the availability of the IT infrastructure

b. Participates in the IT infrastructure design, including the specification of the availability requirements for hardware and software


• • • ••



c. Identifies and classifies IT and information assets (Configuration Items) and the level of control and protection required

d. Assists Security and IT Service Continuity Management with the assessment and management of risk

10. Which of the following processes has the goal of aligning IT security with business security and ensure that information security is effectively managed in all service and Service Management Activities?

a.Information Security Management

b. Capacity Management


d. IT Service Continuity Management

11. Which of the following processes ensures the provision of end-to-end, seamless, quality IT services are delivered to the business and aligned to their expectation?

a.Information Security Management

b. Supplier Management


d. IT Service Continuity Management


• • •••




• • • ••



Review Answers

1. Which of the following choices is the main purpose of the Service Design stage?

c. design of new or changed services being introduced into the production environment

2. Which of the following choices is not one of the five individual aspects of Service Design?

b. Response to the business and IT requests for change

3. What type of approach should be adopted for all service design areas to ensure consistency and integration?

a. Holistic

4. Which of the following choices describes the value Service Design provides to the business?

d. All of the above

5. Which of the following choices are important to Service Management?

d. All of the above

6. Which of the following choices includes ensuring that an agreed-upon level of IT service is provided for all current IT services and that future services are delivered to agreed-upon targets?

b. Service Level Management

7. Which of the following choices is not part of the Service Level Management process?

a. Ensure that availability targets in all areas are measured and achieved.

8. Which of the following choices is not a responsibility for a Service Catalog Manager?

d. Ensuring that the current and future service requirements of customers are identified, understood, and document in SLA and SLR documents.

9. Which of the following choices is not a responsibility for an Availability Manager?

c. Identifies and classifies IT and information assets (Configuration Items) and the level of control and protection required


• • •••



10. Which of the following processes has the goal of aligning IT security with business security and ensure that information security is effectively managed in all service and Service Management Activities?

a. Information Security Management

11. Which of the following processes ensures the provision of end-to-end, seamless, quality IT services are delivered to the business and aligned to their expectation?

b. Supplier Management


• • • ••



Summary


113

Summary

You should now be able to:Explain the key principles and concepts related to Service Design Discuss Service Design processes and associated activities

Describe the Service Design roles

• • • ••

4-1

Unit 4: Service Transition




• • • ••



Introduction

In this unit, you will learn about Service Transition.

Objectives


2

Objectives

Upon completion of this unit, you will be able to:Explain the key principles and concepts related to Service Transition Discuss Service Transition processes and associated activities

Describe the Service Transition roles


• • •••

Unit 4: Service TransitionService Transition Overview


Lesson 1: Service Transition Overview


Lesson 1: Service Transition Overview


• • • ••



Service Transition Overview

Service Transition uses all the processes described in the other ITIL parts of the Service Lifecycle. It uses all the processes because it is responsible for testing them. This testing occurs either as part of a new or changed service or as part of testing changes to the Service Management processes.

Service level management is important to ensure that customer expectations are managed during Service Transition. Incident and problem management are important for handling incidents and problems during testing, pilot, and deployment activities.


4

Service Transition Overview

• Service Transition is a change in state, corresponding to a movement of an IT Service or other Configuration Item. This change occurs from one lifecycle status to the next.


• • •••



Service Transition Objectives

Further objectives of Service Transition include:

• To ensure that the new or changed services can be used in accordance with the requirements and constraints specified within the service requirements

• To plan and manage resources to successfully establish a new or changed service and bring it into production within the predicted cost, quality, and time estimates

• To ensure a 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

– Knowledge transfer


5

Service Transition Objectives

• Sets customer expectations on how performance and use of new or changed services can be used to enable business change

• Enables business change project or customer to integrate a release into business processes and services

• Reduces variations in predicted and actual performance of transitioned services

• Reduces the known errors and minimizes the risks from transitioning the new or changed services into production


• • • ••



• 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


• • •••



Value of Service Transition

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 quality knowledge and information. Therefore, Release and Deployment Management can expedite effective decisions during a release.

• Provide efficient repeatable 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 Service Design requirements and constraints.


6

Value of Service Transition

• Improves the ability to adapt quickly to new requirements and market developments

• Aids in transition management of mergers, demergers, 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 r isk during and after change, for example, during service outage, service disruption, or rework


• • • ••



Service Knowledge Management System

Knowledge management is focused within the Service Knowledge Management System (SKMS).

Underpinning this knowledge is a considerable quantity of data. It 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


7

Service Knowledge Management System

• Under Service Transition, knowledge management is focused within the Service Knowledge Management System (SKMS)

• The Service Knowledge Management system covers a wide base of knowledge


• • •••



SKMS Data


8

SKMS Data

• Gathered within CMDB

• Fed through the CMS

• Goes into the SKMS

• Supports the informed decision making process


• • • ••



Service Transition Strategy


9

Service Transition Strategy

• Defines the overall approach to organizing Service Transition and allocating resources

• Includes: PurposeScope Organizations and stakeholders CriteriaRequirements and content ApproachDeliverables for each stageFinancial requirements

ContextApplicable standards requirementsFramework for Service TransitionPeople and rolesSchedule of milestones


• • •••



Service Transition Lifecycle Stages Example


10

Service Transition Lifecycle Stages Example

• Acquire and test input configuration items (CIs) and components

• Build and test

• Service release test• Service operational readiness test

• Deployment• Early life support

• Review and close service transition


• • • ••



Technology Considerations for Service Transition

Technology is extremely important in Service Transition. Designs should include methods for maintaining and maximizing benefit from the technology used. Two ways in which Service Transition is supported by technology are by:

• Enterprise-wide tools that support the broader systems and processes within which Service Transition delivers support

• Tools targeted more specifically at supporting Service Transition or parts of Service Transition

Knowledge Management Tools

• Knowledge Management tools maintain electronic copies of records and documents. Records are different from documents because they provide evidence of activities, rather than intentions.

• Document Management: Document Management defines the set of capabilities to support the following areas for documents and information:

– Storage


11

Technology Considerations for Service Transition

• Knowledge Management Tools

• Configuration Management System (CMS)


• • •••



– Protection

– Archiving

– Classification

– Retirement

• Records Management: Records management defines the set of capabilities to support the following areas for records:

– Storage

– Protection

– Archiving

– Classification

– Retirement

• Content Management: Content management is the capability that manages the storage, maintenance and retrieval of documents and information of a system or Web site.

Configuration Management System (CMS)

The CMS contains details about the attributes and the history of each Configuration Items (CIs) and details of the important relationships between CIs. Many organizations have some form of Configuration Management in operation, but it is often paper-based. For large and complex infrastructures, Configuration Management will operate more effectively when supported by a software tool that is capable of maintaining a CMS.

The Configuration Management System should prevent changes from being made to the IT infrastructure or service configuration baseline without valid authorization through Change Management.


• • • ••

Unit 4: Service TransitionProcess of Transition Planning and Support


Lesson 2: Process of Transition Planning and Support


Lesson 2: Process of Transition Planning and Support


• • •••



Transition Planning and Support Purpose


13

Transition Planning and Support Purpose

• Plan appropriate capacity and resources

• Provide support for the Service Transition teams

• Plan the changes required while ensuring integrity of all customer assets

• Ensure reporting of Service Transition issues, risks, and deviations

• Coordinate activities across relevant areas


• • • ••



Transition Planning and Support Goals


14

Transition Planning and Support Goals

• Plan and coordinate the resources

• Identify, manage, and control the risks of failure and disruption


• • •••



Transition Planning and Support Objectives


15

Transition Planning and Support Objectives

• Establish successful plan within the predicted cost, quality and time estimates

• Ensure common adoption of the framework of standard reusable processes and supporting systems

• Provide clear and comprehensive plans that enable customer and business to align activities with the Service Transition plans


• • • ••



Service Transition Policy

The Service Design Package includes the following information that is required by the Service Transition team:

• The applicable service packages

• The service specifications

• The service models

• The architectural design required to deliver the new or changed Service including constraints

• The definition and design of each release package

• The detailed design of how the service components will be assembled and integrated into a release package

• Release and deployment plans

• The Service Acceptance Criteria

The types of release should be defined as this helps to set customer and stakeholder expectations about the planned releases.


16

Service Transition Policy

• The release policy should be defined for one or more services.

• All releases should have a unique identifier that can be used by Configuration Management and the documentation standards.

• The types of release should be defined. Typical Types of releases include:

MajorMinor

Emergency


• • •••



Typical types of releases include:

• Major Releases: This type usually contains large areas of new functionality. They can include those releases that eliminate temporary fixes to problems. A major upgrade or release usually supersedes all preceding minor upgrades, releases, and emergency fixes.

• Minor Releases: This type usually contains small enhancements and fixes, some of which might already have been issued as emergency fixes. A minor upgrade or release usually supersedes all preceding emergency fixes.

• Emergency releases: This type usually contains the corrections to a small number of known errors. Sometimes it contains an enhancement to meet a high priority business requirement.


• • • ••



Transition Planning and Support Benefits


17

Transition Planning and Support Benefits

• Improve ability to deal with considerable amounts of change and releases

• Improve alignment of Service Transition Plans with changed Project Plans


• • •••



Transition Planning and Support Activities

The Transition Planning and Support process consists of the following activities.

Define Transition Strategy and Lifecycle Stages

The Service Transition strategy defines the overall approach to organizing Service Transition and allocating resources. The aspects to consider are:

• Purpose, goals and objectives of Service Transition

• Context

• Scope

• Applicable standards, agreements, legal, regulatory, and contractual requirements

• Organizations and stakeholders involved in transition

• Framework for Service Transition:

• Criteria

• Identification of requirements and content of the new or changed service


18

Transition Planning and Support Activities

• Define Transition Strategy and Lifecycle Stages

• Prepare for Service Transition

• Plan and Coordinate Service Transition

• Provide Transition Process Support


• • • ••



• People

• Approach

• Deliverables from transition activities including mandatory and optional documentation for each stage

• The Service Design Plan should define the lifecycle stages for a Service Transition:

• Acquire and test input configuration items (CIs) and components

• Build and test

• Service release test

• Service operational readiness test

• Deployment

• Early life support

• Review and close service transition

Prepare for Service Transition

• Review and acceptance of inputs from the other service lifecycle stages

• Review and check the input deliverables

• Identify, raise, and schedule RFCs

• Check that the configuration baselines are recorded in Configuration Management before the start of Service Transition

• Check transition readiness

Plan and Coordinate Service Transition

• Develop a Service Transition Plan. A Service Transition plan describes the tasks and activities required to release and deploy into the test environments and production.

• Maintain an integrated set of transition plans that are linked to lower-level plans such as release, build and test plans.

• Quality review all Service Transition, release, and deployment plans.


• • •••



• Provide Transition Process Support

• Provide support for all stakeholders regarding the Service Transition framework of processes and supporting systems and tools.

• Maintain an oversight of the actual transitions against the integrated Service Transition plans, release, and change schedules.


• • • ••



Transition Planning and Support Inputs and Outputs


19

Transition Planning and Support Inputs and Outputs

Inputs:

• An authorized Request for Change (RFC)

• A Service Design package

• A release package definition and design specification

• Service Acceptance Criteria (SAC)

Outputs:

• Transition strategy

• Integrated set of Service Transition plans


• • •••



Transition Planning and Support KPIs

Further Transition Planning and Support KPIs include:

• Better management information on the predicted versus actual performance and cost of Service Transition

• Improved efficiency and effectiveness of the processes and supporting systems, tools, knowledge, information and data

• Reduction in time and resource to develop and maintain integrated plans and coordination activities

• Project and service team satisfaction with the Service Transition practices


20

Transition Planning and Support KPIs

• The percentage of releases that met agreed cost, quality, scope, and release schedule requirements

• Reduced variation of actual versus predicted scope, quality, cost, and time

• Increased customer and user satisfaction with plans and communications

• Reduction in number of issues, risks and delays caused by inadequate planning

• Improved Service Transition success rate


• • • ••



Transition Planning and Support Roles

The responsibilities include:

• Determining transition planning and support requirements, processes and tools

• Maintaining and integrating lower level plans to establish overall integrated transition plans

• Monitoring and managing progress on Service Transition changes, issues, risks and deviations

• Maintaining records and providing management information on resource use, project progress, and budget data

• Managing and coordinating requests for resources

• Coordinating Service Transition activities across projects, suppliers and service teams where appropriate

• Publishing Service Transition performance statistics and identifying key areas for improvement

• Undertaking formal quality reviews of transition activities in accordance with the quality management plan


21

Transition Planning and Support Roles

• Sometimes, the Service Transition manager is responsible for planning and support.

• However, in some organizations this function might be performed by a Service Management office or be an IT planning responsibility.

• Either way, this role provides support for the Service Transition teams and people.


• • •••



• Managing support for tools and Service Transition processes

• Communicating with stakeholders


• • • ••

Unit 4: Service TransitionProcess of Change Management


Lesson 3: Process of Change Management


Lesson 3: Process of Change Management


• • •••



Change Management Scope

Service Change will deal primarily with Service Operational Changes, but organizations can use the service. Change process for strategic changes or portfolio changes if they choose.

Changes that lie outside the scope of a service change process of an organization might include:

• Changes with significantly wider impacts than service changes, for example, departmental organization, policies, business operations. These changes will produce Requests for Change (RFCs) to generate consequential service changes.

• Changes at an operational level, such as repair to printers or other routine service components.


23

Change Management Scope

• Service Change is the addition, modification, or removal of authorized, planned, or supported service or service component and its associated documentation.

• Each organization should define the changes that lie outside the scope of their service change process.

• The scope of Change Management covers changes to baseline service assets and configuration items across the whole Service Lifecycle.


• • • ••



Service Request

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


24

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


• • •••



Change Request

An organization needs to ensure that appropriate procedures and forms are available to cover the anticipated requests.

Avoiding a bureaucratic approach to documenting a minor change removes some of the cultural barriers to adopting the change management process.

Some of the forms might be:

• A request for change document

• A service desk call

• A project initiation document


25

Change Request

• A formal communication seeking an alteration to one or more Configuration Items

• Change requests can take several forms

• Different types of change may require different types of change requests


• • • ••



Change Types


26

Change Types

• Normal

• Standard

• Emergency


• • •••



Change Types: Normal Change


27

Change Types: Normal Change

• An ITIL normal change refers to changes that must follow the complete change management process.

• A normal change will proceed through all steps of the change management process and will eventually be reviewed by the Change Advisory Board (CAB).

• The CAB will provide advice regarding the change to the person who is deemed responsible to approve or reject normal changes.


• • • ••



Change Types: Standard Change

Examples of a standard change type might include:

• An upgrade of a computer in order to make use of specific standard and perpetuated software

• Desktop move for single user

• Low-impact, routine application change to handle seasonal variation

The crucial elements of a Standard Change are as follows:

• A defined trigger initiates the RFC

• The tasks are well-known, documented, and proven

• Authority is effectively given in advance

• Budgetary approval will typically be preordained or within the control of the change requester

• The change typically has a low risk and always a well-understood risk

Standard Changes should be identified early when building the Change Management process to promote efficiency. Otherwise, a Change Management implementation can create unnecessarily high levels of administration and resistance to the Change


28

Change Types: Standard Change

• Change to a service or infrastructure when the change:Is preauthorized by Change Management

Has an accepted and established procedure to provide a specific change requirement

• Changes intended to introduce immediately required business improvements are handled as normal changes, assessed as having the highest urgency


• • •••



Management process. All changes, including Standard Changes, will have details of the change recorded. For some Standard Changes this record might be different from normal change records.

Some Standard Changes to Configuration Items (CIs) might be tracked on the asset or CI lifecycle, particularly where a comprehensive Change Management System (CMS) provides:

• Reports of changes

• Current status of changes

• Related configuration items

• Status of the related CI versions

In these cases, the Change Management and Configuration Management reporting is integrated. Change Management can have oversight over all changes to service CIs and release CIs.


• • • ••



Change Types: Emergency Change

The number of emergency changes should be kept to an absolute minimum, because they are generally more disruptive and prone to failure.

Occasions will occur when emergency changes are essential. Consequently, procedures should be devised to deal with them quickly, without sacrificing normal management controls.

If emergency changes are not designed carefully and tested before use, the impact of the emergency change might be greater than the original.


29

Change Types: Emergency Change

• Emergency changes are sometimes required and should be:

Designed carefullyTested before use

• Can document some details retrospectively• Reserved for changes intended to repair an error in an IT

service• The IT service must be negatively affecting the business

to a high degree


• • •••



Release Unit

An organization might, for example, decide that the Release Unit for business critical applications is the complete application. It might do so to 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.

A release unit to upgrade to a small portion of a sales application might require the entire site contents to be packaged and released together.


30

Release Unit

• 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 type or items of service asset or service component, such as software and hardware


• • • ••



Seven Rs of Change Management

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.


31

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?


• • •••



Change Management Goals

The change management process should ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner.

Changes arise for a variety of reasons:

• Proactive changes. For example, seeking business benefits such as reducing costs or improving services, or increasing the ease and effectiveness of support.

• Reactive changes are a means of resolving errors and of adapting to changing circumstances, supporting new product lines, and so forth.

Changes should be managed for the following reasons:

• To optimize risk exposure (supporting the risk profile required by the business)

• To minimize the severity of any impact and disruption

• To be successful on the first attempt

To make an appropriate response to all Requests for Change, Change Management should include an assessment of:

• Risk and business continuity


32

Change Management Goals

• Change Management responds to the changing business requirements of the customer while reducing incidents, disruption, and rework

• Change Management responds to the business and IT requests for change


• • • ••



• Change impact

• Resource requirements

• Change authorization

• Business benefit

This assessment is essential to maintain the required balance between the need for change and the impact of the change.

Each organization should define the changes that lie outside the scope of their service change process, which typically might include the following changes:

• Changes with significantly wider impacts than service changes, for example, departmental organization, policies, business operations. These changes will produce RFCs to generate consequential service changes.

• Changes at an operational level, such as repair to printers or other routine service components.


• • •••



Change Management Benefits

By managing changes, you manage much of the potential risk that changes can introduce. Service and infrastructure changes can have a negative impact on the business by disrupting service and delaying the identification of business requirements. However, Change Management enables the service provider to perform the following tasks:

• Prioritizing and responding to business and customer change proposals

• Implementing changes that meet the agreed-upon service requirements of the customers while optimizing costs

• Reducing failed changes resulting in service disruption, defects, and rework

• Delivering change promptly to meet business time scales

• Tracking changes through the Service Life Cycle and to the assets of its customers

• Contributing to better estimations of the quality, time, and cost of change

• Assessing the risks associated with the transition of services

• Aiding productivity of staff by minimizing disruptions caused by high levels of unplanned or emergency changes, hence maximizing service availability

• Reducing the Mean Time to Restore Service (MTRS) through quicker and more successful implementations of corrective changes


33

Change Management Benefits

• Prioritizing and responding to change requests

• Reducing failed changes and service disruption• Delivering change promptly

• Tracking changes through the Service Lifecycle • Contributing to better estimations of the quality, time, and

cost of change• Reducing disruptions due to high levels of unplanned or

emergency changes• Reducing the Mean Time to Restore Service (MTRS)

through quicker and more successful implementations of corrective changes


• • • ••



Policies Supporting Change Management

Policies that support change management include:

• Creating a culture of change management across the organization where there is zero tolerance for unauthorized change

• Aligning the service change management process with business, project, and stakeholder change management processes

• Prioritizing change such as innovation, prevention, detection, corrective change

• Segregating of duty controls

• Establishing a single focal point for changes in order to minimize the probability of conflicting changes and potential disruption to the production environment

• Integrating with other service management processes to establish traceability of change, detect unauthorized change, and identify change-related incidents

• Establishing performance measures for the process, for example, efficiency and effectiveness


34

Policies Supporting Change Management

• Establishing zero tolerance for unauthorized change

• Establishing accountability and responsibilities for changes through the Service Lifecycle

• Establishing a single focal point for changes

• Preventing people who are not authorized to make a change from having access to the production environment

• Establishing Change Windows: enforcement and authorization for exceptions

• Establishing performance and risk evaluation of all changes that affect service capability


• • •••



Remediation


35

Remediation

• Before approval, all changes should address the question of what to do if the change is not successful

• There should be a back-out plan, which will restore the organization to its initial situation

often done through the reloading of a baseline set of CIs, especially software and data

• If change is not reversible, an alternative approach to remediation is required


• • • ••



Change Management Activities

Managing individual changes typically include the following activities:

• Create and recording changes

• Review Request For Change (RFC) and change proposal

• Filter changes (for example, incomplete changes, wrongly routed changes)

• Assess and evaluate the change

• Establish appropriate level of change authority

• Establish relevant areas of interest (such as who should be involved in Change Advisory Board)

• Assess and evaluate the business justification, impact, cost, benefits, and risk of changes

• Request independent evaluation of a change

• Authorize the change

• Obtain authorization and rejection


36

Change Management Activities


• • •••



• Communicate the decision with all stakeholders, in particular the initiator of the request for change

• Plan updates

• Coordinate change implementation

• Review and close change

• Collate the change documentation, for example, baselines and evaluation reports

• Review the changes and change documentation

• Close the change document when all actions are completed

Throughout all the previous process activities and those described within this section, information is gathered, recorded in the CMS, and then reported.


• • • ••



Change Management Interfaces

Change and Release Management should be integrated with:

• Processes used for organizational programs or projects

• Supplier management

• Processes and procedures of the supplier

Occasionally a proposed change will potentially have a wider impact on other parts of the organization (for example, facilities or business operations), or vice versa. Then service change process must interface appropriately with other processes involved.

Service Management processes might require change and improvements. Many will also be involved in the impact assessment and implementation of service changes.

Asset and Configuration Management: The Configuration Management System provides reliable, quick, and easy access to accurate configuration information. This information helps stakeholders and staff assess the impact of proposed changes and to track workflow. This information enables the correct asset and service component versions to be released to the appropriate party or into the correct environment. As changes are


37

Change Management Interfaces

• Release Management

• Asset and Configuration Management

• Problem Management


• Security Management

• Capacity and Demand Management


• • •••



implemented, the configuration management information is updated. The CMS might also identify:

• Related CI and assets that will be affected by the change, but not included in the original request

• Similar CI and assets that might benefit from similar change

Problem Management: Changes are often required to implement workarounds and to fix known errors. Problem Management is one of the major sources of Requests for Changes (RFCs) and also often a major contributor to Change Advisory Board (CAB) discussion.

IT Service Continuity: Procedures and plans should be updated through change management to ensure that they are accurate, up to date, and distributed to stakeholders.

Security Management: Changes required by security will go through the change management process and security will be a key contributor to CAB discussion on many services. Every significant change will be assessed for its potential impact on the security plan.

Capacity and Demand Management: Poorly managed demand is a source of costs and risk for service providers because uncertainty is always associated with the demand for services. Capacity management has an important role in assessing proposed changes, not only the individual changes but the total impact of changes on service capacity. Changes arising form capacity management, including those set out in the capacity plan, will be initiated as RFCs through the change process.


• • • ••



Change Management Inputs and Outputs

The inputs for Change Management are:

• Policy and strategies for change and release

• Request for Change

• Change proposal

• Plans that include:

– Change

– Transition

– Release

– Deployment

– Test

– Evaluation

– Remediation

• Current change schedule and Projected Service Outage (PSO)


38

Change Management Inputs and Outputs

• Changes can be submitted as an Request For Change (RFC).

• The RFC will often be accompanied by an associated change proposal.

• The change proposal will be based on a change model and will provide more detail about the specific change proposed.


• • •••



• Current assets or configuration items

• Planned configuration baseline

• Test results, test report, and evaluation report

Outputs from the Change Management process are:

• Rejected RFCs

• Approved RFCs

• Change to the services, service, or infrastructure from approved RFCs

• New, changed, or disposed assets or configuration items

• Change schedule

• Revised PSO

• Authorized change plans

• Change decisions and actions

• Change documents and records

• Change Management reports


• • • ••



Change Management Key Performance Indicators

Change Management must ensure that measures that have specific meaning. It is relatively easy to count the number of incidents that eventually generate changes. However, it is more valuable to examine the underlying cause of such changes and identify trends. The following options would be even better:

• Measure the impact of change

• Demonstrate reduced disruption over time because of the introduction of Change Management

• Measure the speed and effectiveness with which the IT infrastructure responds to identified business needs

Measures taken should be linked to business goals, wherever practical, and to cost, service availability, and reliability. Any predictions should be compared with actual measurements.

The Key Performance Indicators for Change Management include the following measurements:

• The number of changes implemented to services which met the agreed-upon requirements of the customer. These requirements will include quality, cost, and time (expressed as a percentage of all changes).


39

Change Management Key Performance Indicators

• Reduction in the number of disruptions to services

• Reduction in the number of unauthorized changes

• Reduction in the backlog of change requests

• Reduction in the number and percent of unplanned changes and emergency fixes

• Change success rate (percentage of changes deemed successful at review or number of RFCs approved)

• Reduction in the number of failed changes

• Average time to implement based on urgency, priority, and change type

• Incidents attributable to changes


• • •••



• The benefits of change expressed as value of improvements made + negative impacts prevented or terminated compared to the costs of the change process.

• Reduction in the number of disruptions to services, defects, and rework caused by inaccurate specification, and poor or incomplete impact assessment.

• Reduction in the number of unauthorized changes.

• Reduction in the backlog of change requests.

• Reduction in the number and percent of unplanned changes and emergency fixes.

• Change success rate (percentage of changes deemed successful at review and number of RFCs approved.)

• Reduction in the number of changes when remediation is invoked.

• Reduction in the number of failed changes.

• Average time to implement based on urgency, priority, and change type.

• Incidents attributable to changes.

• Percentage accuracy in change estimate.


• • • ••



Change Manager

The main role in Change Management is that of the Change Manager. Some of the main duties of the Change Manager can be delegated.


40

Change Manager

• Receive, log, and allocate a priority, in collaboration with the initiator, to all Requests for Change (RFCs). Reject any totally impractical RFCs.

• Chair all Change Advisory Board (CAB) and Emergency Change Advisory Board (ECAB) meetings, table all RFCs for a CAB meeting, issue an agenda, and circulate all RFCs to CAB members before meetings to allow prior consideration.

• Determine meeting invitations and allocate specific RFCs (depending on the nature of the RFC, the changes, and areas of expertise of the personnel).

• After consideration of the advice given by the CAB or ECAB, authorize acceptable changes.

• Issue Change Schedules through the Service Desk. • Review all implemented changes to ensure that they have met their

objectives. Refer back any that have been reversed or have failed.


• • •••



Change Advisory Board (CAB)

The Change Advisory Board (CAB) is a body that exists to support the authorization of changes. The CAB also assists Change Management in the assessment and prioritization of changes. When a CAB is convened, members should be chosen who are capable of ensuring that all changes within the scope of the CAB are adequately assessed. These assessments should come from both a business and a technical viewpoint. When the need for emergency change arises, there might not be time to convene the full CAB. It is necessary to identify a smaller organization with authority to make emergency decisions. This body is the Emergency Change Advisory Board (ECAB).

The CAB might be asked to consider and recommend the adoption or rejection of changes appropriate for higher level authorization. Then recommendations will be submitted to the appropriate change authority


41

Change Advisory Board

• Will be composed according to the changes being considered

• Might vary considerably in make up, even across the range of a single meeting

• Should involve suppliers when that is useful

• Should reflect both user and customer views • Is likely to include the Problem Manager, Service Level

Manager, and Customer Relations staff for at least part of the time


• • • ••

Unit 4: Service TransitionProcess of Service Asset and Configuration Management


Lesson 4: Process of Service Asset and Configuration Management


Lesson 4: Process of Service Asset and Configuration Management


• • •••



Service Asset and Configuration Management Purpose and Goal

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.

The goal of Service Asset and Configuration Management is to provide a logical model of the IT infrastructure. This model correlates IT services and the various IT components (physical, logical, and so on) needed to deliver these services. It does this by defining and controlling the components of services and infrastructure and maintaining accurate configuration records.


43

SACM Purpose and Goal

• Service Asset and Configuration Management (SACM) provides a logical model of the IT infrastructure

• SACM correlates IT services and different IT components (such as physical and logical) 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


• • • ••



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. In addition, it improves the overall service performance. Furthermore, it optimizes costs and risks caused by poorly managed assets such as service outages, fines, correct licence fees, and failed audits.

SACM provides visibility of accurate representations of a service, release, or environment that ensure the following events 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


• • •••



SACM, the Logical Model

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, suppliers, and customers.

The configuration items and related configuration information can be at various levels of detail. For example, it can include an overview of all the services or a detailed view of a service component specification.

A more detailed level of Configuration Management should be used when the service provider requires tight control, traceability, and tight coupling of configuration information.


44

SACM, the 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 or a detailed level to view the specification for a service component


• • • ••



Configuration Items

A Configuration Item is an asset, service component, or other item which is, or will be, under the control of configuration management. Configuration Items might vary widely in complexity, size, and type, ranging from an entire service or system including all hardware, software, documentation, and support staff to a single software module or a minor hardware component.

Configuration Items might be grouped and managed together. An example is a set of components might be grouped into a release. Configuration Items should be selected using established selection criteria. In addition, they should be grouped, classified, and identified to be manageable and traceable throughout the Service Lifecycle.


45

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, 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


• • •••



Types of Configuration Items


46

Types of Configuration Items

• Service Lifecycle

• Service

• Organization

• Internal

• External


• • • ••



There will be a variety of CIs; the following categories can help identify them:

• Service Lifecycle 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

– The benefits that are expected

– The cost

– The time frame for 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)

– Service Model

– Service Package

– Release Package

– Service Acceptance Criteria

• Organization CIs: Some documentation will define the characteristics of a CI. Other documentation will be a separate CI and need to be controlled. An example is 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: Comprise those delivered by individual projects. They include tangible assets such as a data center. They also include intangible assets such as software, that are required to deliver and maintain the service and infrastructure.

• External CIs: Such as external customer requirements and agreements, releases from suppliers or subcontractors and external services.


• • •••



Configuration Management System

Some of these items will have related specifications or files that contain the contents of the item such as software, documents, or a photograph.

For example, a Service CI will include the details such as:

• Supplier

• Cost

• Purchase date

• Renewal date for licenses and maintenance contracts

• Related documentation, such as SLAs and Underpinning Contracts

Note: Asset data held in a CMS (CMDB data) might be made available to external financial Asset Management systems. These systems will perform specific asset management process reporting outside of Configuration Management.


47

Configuration Management System

• The Configuration Management System (CMS) holds all the information for CIs within the designated scope, and is used for wide range of purposes.

• CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation

• CMS could contain corporate data about employees, suppliers, locations and business units, customers, and users


• • • ••



Definitive Media Library

The library can consist of one or more software libraries or file-storage areas, separate from development, test, or active file-storage areas.


48

Definitive Media Library (DML)

• Secure library that stores and protects the definitive authorized versions of all media CIs

• Stores master copies of versions that have passed quality assurance checks

• Contains the master copies of all controlled software (both purchased and developed) in an organization

• Stores master copies of controlled documentation for a system

• Is separate from development, test, or active file-storage areas

• Can consist of one or more software libraries or file-storage areas


• • •••



Configuration Baseline


49

Configuration Baseline

• The configuration of a service, product, or infrastructure that has been formally reviewed and agreed upon

• Serves as the basis for further activities and can be changed only through formal change procedures

• Captures the structure, contents, and details of a configuration

• Represents a set of configuration items that are related to each other


• • • ••



SACM Benefits

SACM provides visibility of accurate representations of a service, release, or environment that facilitates 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


50

SACM Benefits

• Optimizes the performance of service assets and configurations

• Improves the overall service performance

• Optimizes the costs and risks caused by poorly managed assets such as:

Service outages Fines Correct license fees Failed audits


• • •••



SACM Activities

The activities for Service Asset and Configuration Management include:

• Management and Planning: The plans define the specific Configuration Management activities within the context of the overarching Service Asset and Configuration Management strategy.

• Configuration Identification: Identification includes the following activities:

– Define and documenting configuration items and components selection criteria

– Selecting the configuration items and the components

– Assigning unique identifiers to configuration items

– Specifying the relevant attributes of each configuration item

– Specifying when each configuration item is placed under Configuration Management

– Identifying the owner responsible for each configuration item

• Configuration Control: This activity ensures that there are adequate control mechanisms over CIs. During this activity, a record of changes to CIs, versions, location, and ownership is maintained.


51

SACM Activities

• Management and Planning

• Configuration Identification

• Configuration Control

• Status Accounting and Reporting

• Verification and Audit


• • • ••



• Status Accounting and Reporting: The significance of each state should be defined in terms of what use can be made of the asset or CI in that state. The organization should perform configuration status accounting and reporting activities throughout the lifecycle of the service in order to support and facilitate an efficient Configuration Management process.

• Verification and Audit: The activities include a series of reviews or audits to:

– Ensure there is conformity between the documented baselines and the actual business environment

– Verify the physical existence of CIs in the organization

– Check that the records in the CMS match the physical infrastructure

– Check that release and configuration documentation exists before executing a release


• • •••



SACM Interfaces

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 Management, Problem Management, or Error Management: Providing and maintaining key diagnostic information, maintenance and provision of data to Service Desk

• Availability Management: In detection of points of failure

• Configuration Control (synonymous with change control): Understanding and capturing updates to the infrastructure and services


52

SACM Interfaces


• Financial management


• Problem and Incident Management

• Availability Management


• • • ••



SACM Key Performance Indicators

Other KPIs for SACM include:

• Percentage re-use and redistribution of under utilized resources and assets

• Degree of alignment of insurance premiums with business needs

• Ratio of used licenses against paid for licences (should be close to 100%)

• Average cost per user for licenses

• Achieved accuracy in budgets and charges for the assets utilized by each customer or business unit

• Percentage reduction in business impact of outages and incidents caused by poor Asset and Configuration Management

• Improved audit compliance


53

SACM KPIs

• Percentage improvement in maintenance scheduling over the life of an asset

• Degree of alignment between provided maintenance and business support

• Assets identified as the cause of service failures

• Improved speed for incident management to identify faulty CIs and restore service

• Impact of incidents and errors affecting specific CI types


• • •••



SACM Challenges, Critical Success Factors, and Risks

Some of the Critical Success Factors include:

• Establishing valid justification for collecting and maintaining data at the agreed level of detail

• Demonstrating a top-down approach

• Setting a justified level of accuracy

• Making use of enabling technology to automate the CMS practices and enforce SACM policies

Some of the Risks to successful SACM include:

• Over emphasis on a technical focus, rather than a service and business focus

• Degradation configuration information accuracy over time that can cause errors and be difficult and costly to correct

• Not keeping the CMS up to date due to the movement of hardware assets by non-authorized staff


54

SACM Challenges

• Convincing technical support staff to adopt a check in and check out policy

• Attracting and justifying funding for SACM,

• Overcoming an overemphasis on data collection

• Gaining commitment and support from management who do not understand the importance of SACM to other processes


• • • ••



Service Asset Manager


55

Service Asset Manager

• Evaluates existing Asset Management systems and the design

• Develops Asset Management standards, Asset Management plans, and procedures

• Arranges recruitment and training of staff

• Ensures that staff comply with identification standards

• Proposes interfaces, agrees to interfaces, or both with Change Management, Problem Management, Network Management, Release Management, computer operations, logistics, finance, and administration functions

• Plans population of the Asset DB and manages the Asset DB, central libraries, and tools

• Provides reports, including management reports (indicating suggested action to deal with current or foreseen shortcomings),impact analysis reports, and asset status reports


• • •••



Configuration Manager


56

Configuration Manager

• Evaluates existing Configuration Management Systems (CMS) and their design

• Agrees to CIs to be uniquely identified with naming conventions.Ensures that staff comply with identification standards for object types, environments, processes, lifecycles, documentation, versions, formats, baselines, releases, and templates

• Proposes interfaces to and agrees to interfaces with Change Management, Problem Management, Network Management, Release Management, computer operations, logistics, finance, and administration functions

• Plans population of the CMS. Manages CMS, central libraries, tools, common codes and data. Ensures regular maintenance of the CMS

• Provides reports, including management reports (indicating suggested action to deal with current or foreseen shortcomings),impact analysis reports, and configuration status reports


• • • ••



Configuration Analyst


57

Configuration Analyst

• Proposes scope of the processes and recorded information Develops Asset and Configuration Management standards, plans, and procedures

• Trains Asset and Configuration Management specialists

• Creates Asset and Configuration Management processes and procedures

• Assists in uniquely identifying CIs with naming conventions

• Ensures that developers and configuration system users comply with identification standards

• Liaises with the configuration administrator and librarian on population of the CMS

• Manages asset and CMS, central libraries, common codes and data

• Uses or provides the asset and CMS to facilitate impact assessment for RFCs


• • •••



Configuration Administrator or Librarian

Further duties of this role include:

• Maintains current status information on CIs

• Accepts and records the receipt of new or revised configurations into the appropriate library

• Archives replaced CI copies

• Holds the master copies

• Administers configuration control process

• Produces configuration status accounting reports

• Assists in conducting configuration audits

• Works with other configuration libraries where CIs are common to other systems


58

Configuration Administrator or Librarian

• Controls the receipt, identification, storage, and withdrawal of all supported CIs

• Provides information on the status of CIs

• Numbers, records, stores and distributes Asset and ConfigurationManagement issues

• Assists Asset and Configuration Management to prepare the Asset and Configuration Management Plan

• Creates an identification scheme for Configuration Management libraries and the Definitive Media Library (DML)

• Creates an identification scheme for assets and the Definitive Spares (DS)

• Creates libraries or other storage areas to hold CIs

• Assists in the identification of products and CIs


• • • ••

Unit 4: Service TransitionProcess of Release and Deployment Management


Lesson 5: Process of Release and Deployment Management


Lesson 5: Process of Release and Deployment Management


• • •••



Release and Deployment Management Goals

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 might 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. They might make this decision to 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.


60

Release and Deployment Management Goals

• To deploy releases into production.

• To facilitate effective use of the service in order to deliver value to the customer.


• • • ••



Release and Deployment Management Objectives


61

Release and Deployment Management Objectives

• Ensure clear and comprehensive release and deployment plans

• Ensure a release package can successfully be built, installed, tested, and deployed

• Ensure a new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements

• Ensure minimal unpredicted impact on production services, operations, and the support organization

• Ensure customers, users, and Service Management staff are satisfied with the Service Transition practices and outputs


• • •••



Release Management Process

Release and Deployment Management is important to ensure that there are clear release and deployment plans. In addition, Release and Deployment Management makes sure that skills and knowledge are transferred to operations and support staff. Furthermore, Release and Deployment Management makes certain there is minimal unpredicted impact on production services.

The release process commences with receipt of an approved RFC to deploy a production-ready Release Package. Deployment commences 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.


62

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


• • • ••



Factors to Consider for Release Units

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, for example, emergency fix releases: Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.


63

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 production environments


• • •••



Release and Deployment Management Benefits


64

Release and Deployment Management Benefits

• Delivers change faster, at optimum cost, and with minimized risk

• Assures that customers and users can use the new or changed service in a way that supports the business goals

• Improves consistency in implementation approach across the business

• Contributes to meeting auditable requirements for traceability through Service Transition


• • • ••



Release and Deployment Management Activities

Some of the sub-activities to these activities include:

• Planning:

– Developing release and deployment plans

– Planning the pass or fail criteria

– Building and testing prior to production

– Planning release package and build

– Deployment planning

– Logistics and delivery planning

– Financial and commercial planning

• Preparing for build, test and deployment

• Building and testing

– Using release and build documentation


65

Release and Deployment Management Activities

• Planning

• Preparing for build, test and deployment

• Building and testing

• Testing services and conducting pilots

• Planning and preparing for deployment

• Performing and transfer, deployment and retirement

• Verifying deployment

• Conducting early life support (ELS)

• Reviewing and closing services

• Reviewing and closing service transitions


• • •••



– Acquiring and testing input configuration items and components

– Packaging the release

– Building and managing test environments

• Testing services and conducting pilots

– Conducting service rehearsals

– Delivering rehearsals

– Documenting rehearsals

– Taking action after rehearsals

– Conducting pilots

• Planning and preparing for deployment

– Conducting assessments

– Developing plans and preparing for deployment

– Performing transfer, deployment and retirement

– Transferring and transitioning business and organization

– Deploying processes and materials

– Transferring services

– Deploying services

– Decommissioning and retiring services

– Removing redundant assets


• • • ••



Service V Model

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.


• • •••



Release and Deployment Management Inputs and Outputs

The release process begins with receipt of an approved RFC to deploy a production-ready release package. Deployment begins when an approved request to deploy a release package to a target deployment group or environment is received


67

Release and Deployment Management Outputs

• Release and deployment plan

• Completed RFCs for the release and deployment activities

• Service notification

• Updated service catalog with the relevant information about the new or changed service


• • • ••



Release and Deployment Management inputs are:

• Authorized RFC

• Service level package

• Service design package, including service model and service acceptance criteria (SAC)

• IT service continuity plan and related business continuity plan

• Service Management and operations plans and standards

• Technology and procurement standards and catalogs

• Acquired service assets and components and their documentation

• Build models and plans

• Environment requirements and specifications

• Release policy and release design from Service Design

• Release and deployment models including template plans

• Exit and entry criteria for each stage of release and deployment


• • •••



Release and Deployment Management KPIs


68

Release and Deployment Management KPIs

• Variance from service performance required by customers (minimal and reducing)

• Number of incidents against the service (low and reducing)

• Increased customer and user satisfaction with the services delivered

• Decreased customer dissatisfaction


• • • ••



Release and Deployment Management Challenges, Success Factors, and Risks

Some of the critical success factors in Release and Deployment Management are:

• The new or changed service capability and resources are built in the target environment or deployment group

• The new or changed service has been tested against the Service Design

• The service capability has been proved in a pilot deployment

• Re-usable test models are developed that can be used for regression testing in future releases

Some of the risks to Release and Deployment Management include:

• Poorly defined scope

• Uncommitted staff

• Incompetent management

• Lack of finances to support the effort

• Poorly defined controls


69

Release and Deployment Management Challenges

• Developing standard performance measures and measurement methods across projects and suppliers

• Coping with projects and suppliers with inaccurate estimated delivery dates resulting in delays in activities

• Understanding the different stakeholder perspectives that strengthen effective risk management

• Building a thorough understanding of risks that have impacted or might impact successful Service Transition

• Encouraging a risk management culture where people share information and take a pragmatic approach to risk


• • •••



• Unclear expectations from stakeholders

• Poor communication

• Poor decision-making processes

• Lack of support from senior management

• Lack of contingency plan

• Poor design


• • • ••



Release Packaging and Build Manager

Release Packaging and Build Management is the flow of work to deliver applications and infrastructure that meet the Service Design requirements. The flow of work includes:

• Establish requirements

• Design

• Build

• Test

• Deploy

• Operate

• Optimize

The Release Packaging and Build Manager cannot perform this role in isolation. This role will have significant interaction with the following functions, among others:

• Change and Service Asset Configuration Management



70

Release Packaging and Build Manager

• Establishes the final release configuration (for example, knowledge, information, hardware, software, and infrastructure)

• Builds the final release delivery

• Tests the final delivery before independent testing

• Establishes and report outstanding known errors and workarounds

• Provides input to the final implementation sign-off process


• • •••




• Incident Management


• • • ••



Deployment Manager


71

Deployment Manager

• Coordinates release documentation and communications, including training, and customer documentation, service management, and technical release notes

• Plans the deployment in conjunction with Change and Service Knowledge Management Systems (SKMS) and Service Asset Configuration Management (SACM)

• Provides technical and application guidance and support throughout the release process, including known errors and workarounds

• Provides feedback on the effectiveness of the release

• Records metrics for deployment to ensure within agreed-upon Service Level Agreements (SLAs)


• • •••

Unit 4: Service TransitionProcess of Service Validation and Testing


Lesson 6: Process of Service Validation and Testing


Lesson 6: Process of Service Validation and Testing


• • • ••



Service Validation and Testing Purpose

Service Validation and Testing ensures that all new and changed services will successfully achieve their purpose and use. If services are not adequately tested, prior to being introduced into the live environment, it could lead to a rise in:

• Incidents

• Service desk calls

• Problems and errors

• Costs

• Ineffective use of Services


73

Purpose of Service Validation and Testing

• Obtain objective evidence that new or changed service will support all agreed-upon service levels

• Quality assure a release and all its service components

• Identify, assess and address issues, errors, and risks throughout Service Transition


• • •••



Objectives of Service Validation and Testing

In addition to these objectives, any errors or variances should be remedied early in the Service Lifecycle, a considerably cheaper option than fixing errors in production.


74

Objectives of Service Validation and Testing

Confirm that the new or changed service or service offering:

• Will deliver the expected outcomes and value for the customers within projected costs, capacity, and constraints

• Will deliver the required performance with desired constraints removed

• Meets certain specifications under the specified terms and conditions of use

• Have been correctly defined in terms of customer and stakeholder

• Requirements


• • • ••



Service Validation and Testing Benefits

For testing to be successful, all parties must understand that it does not give any guarantees. However, validation and testing provides a measured degree of confidence. The required degree of confidence varies depending on the business requirements and pressures of an organization.


75

Service Validation and Testing Benefits

• Service failures can result in:Loss of reputation

Loss of money

Loss of time

InjuryDeath

• Increased degree of confidence in required value and outcomes


• • •••



Service Validation and Testing Activities

Validation and Testing activities are not undertaken in a sequence. Service Validation and Testing activities include:

• Validation and Test Management: Test management includes the planning, control and reporting of activities through the test stages of Service Transition. These activities include:

– Planning the test resources

– Prioritizing and scheduling tests

– Managing and documenting incidents, problems, errors, nonconformances, risks, and issues

– Monitoring progress and feedback from validation and test activities

– Managing incidents, problems, errors, nonconformances, risks, and issues discovered during transition

– Capturing configuration baseline

– Testing metrics collection, analysis, reporting, and management


76

Service Validation and Testing Activities

• Validation and Test Management

• Test Planning and Design

• Verify Test Plan and Test Design

• Prepare the Test Environment

• Perform Tests

• Evaluate Exit Criteria and Report

• Test Clean Up and Closure


• • • ••



• Test Planning and Design: This activity begins early in the lifecycle. These activities include:

– Defining required resources

– Supporting services including access, security, catering, communications

– Scheduling milestones, and delivery dates

– Confirming time for consideration of reports and other deliverables

– Establishing point and time of delivery and acceptance

– Establishing financial requirements and budgets

• Verify Test Plan and Test Design: These activities include:

– Ensuring that the test model delivers adequate and appropriate test coverage for the risk profile of the service

– Verifying that the test model covers the key integration aspects and interfaces

– Validating that the test scripts are accurate and complete

• Prepare the Test Environment: The release and deployment processes should also be used to prepare the test environment when appropriate.

• Perform Tests: Carry out and record the results of all tests according to test plans. All results should be documented.

• Evaluate Exit Criteria and Report: Compare actual results to predicted results. Summarize the results of the test metrics.

• Test Clean Up and Closure: Ensure that the test environments are cleaned up or initialized. Identify areas for improvement.


• • •••



Service Validation and Testing Interfaces


77

Service Validation and Testing Interfaces

• Works with Service Design to ensure that designs are valid

• Works closely with CSI to feed failure information and improvement ideas resulting from testing exercises

• Service Operation will use maintenance tests to ensure the continued efficacy of services.

• Service Strategy should make sure that testing is include in budget, resource and profile planning.


• • • ••



Service Validation and Testing Inputs and Outputs

The direct output from testing is the report delivered to service evaluation. This report covers the following information:

• Configuration baseline of the testing environment

• Testing carried out (including options chosen and constraints encountered)

• Results from those tests

• Analysis of the results including:

– Comparison of actual results with expected results

– Risks identified during testing activities


78

Service and Validation Testing Inputs

• The Service Package

• Service Level Package

• Service Provider Interface Definitions

• Service Design Package

• Release and Deployment Plans

• Acceptance Criteria

• Request for Change Documents


• • •••



Service Validation and Testing KPIs


79

Service and Validation Testing KPIs

• Reduction in the impact of incidents and errors attributable to newly transitioned services

• More effective use of resource and involvement from the customer

• Reduced delays in testing that impact the business

• Increased mutual understanding of the new or changed service

• Clear understanding of roles and responsibilities associated with the new or changed service


• • • ••



Service Validation and Testing Challenges, Critical Success Factors, and Risks

Critical success factors for validation and testing include:

• Understanding stakeholder perspectives that support effective risk management for the change impact assessment and test activities

• Building a thorough understanding of risks that have impacted or might impact successful Service Transition of services and releases

• Encouraging a risk management culture where people share information and take a pragmatic approach to risk

• Building quality into every stage of the service lifecycle using a structured framework such as the V-model

• Identifying issues are identified early in the service lifecycle

• Testing provides evidence that the service assets and configurations have been built and implemented correctly

• Developing test models that can be used again for regression testing in future releases


80

Service and Validation Testing Challenges

• The most common challenge to effective testing is the lack of respect and understanding for the role of testing. As a result, Testing and Validation often does not receive adequate funding. This makes it difficult to set up a test environment that mirrors that of the client.

• Lack of staff, skills, and testing tools make it challenging to complete testing on schedule.


• • •••



Risks to successful validation and testing include:

• Unclear expectations and objectives

• Lack of understanding of the risks means that testing is not targeted at critical elements

• Resource shortages introduce delays and have an impact on other Service Transitions


• • • ••



Test Manager


81

Test Manager

• Define the test strategy

• Design and plan testing conditions, test scripts, and test data sets to ensure appropriate and adequate coverage and control

• Allocate and oversee test resources while implementing test policies

• Provide management reporting on test progress, test outcomes, success rates, issues, and risks

• Conduct tests as defined in the test plans and design

• Record, analyze, diagnose, report, and manage test events

• Manage test environment requirements \

• Verify tests conducted by release and deployment teams

• Administer test assets and components


• • •••

Unit 4: Service TransitionProcess of Evaluation


Lesson 7: Process of Evaluation


Lesson 7: Process of Evaluation


• • • ••



Evaluation

The purpose of evaluation is to provide a consistent and standardized method of determining the performance of a service change. Evaluation is accomplished in the context of existing and proposed services and IT infrastructure. The actual performance of a change is assessed against its predicted performance. Any deviations between the two are analyzed and managed.


83

Evaluation

• The process responsible for assessing a new or changed IT service to ensure that risks have been managed

• Help determine whether to proceed with the change


• • •••



Objectives of Evaluation

The goal of evaluation is to set achievable stakeholder expectations. In addition, evaluation hopes to provide effective and accurate information to Change Management. This information will make sure changes that adversely affect service capability and introduce risk are not overlooked.

The evaluation process uses the Plan–Do–Check–Act (PDCA) model to ensure consistency across all evaluations.


84

Objectives of Evaluation

• Evaluate the intended effects and unintended effects (depending on constraints) of a service change

• Provide good quality outputs so that Change Management can expedite decision about service change approval


• • • ••



Evaluation Benefits


85

Evaluation Benefits

• Information will allow a more accurate focus on value in future service development and Change Management

• Continual Service Improvement can use evaluation to analyze future improvements to the process of change

• Enable predictions and measurement of service change performance


• • •••



Evaluation Activities


86

Evaluation Activities

• Evaluation of predicted performance

• Analyze test plan results

• Evaluate risk

• Evaluation of actual performance

• Develop evaluation report

• Complete evaluation report


• • • ••



Evaluation Inputs and Outputs


87

Evaluation Inputs and Outputs

• Inputs for Evaluation include:Service Package (SP) Service Design Package (SDP) Service Acceptance Criteria (SAC)

Test results and report

• Evaluation output consist of the evaluation report for Change Management.


• • •••



Evaluation KPIs


88

Evaluation KPIs

• Variance from service performance required by customers (minimal and reducing)

• Number of incidents against the service (low and reducing)

• Number of failed designs that have been transitioned (zero)

• Cycle time to perform an evaluation (low and reducing)


• • • ••



Evaluation Challenges


89

Evaluation Challenges

• Developing standard performance measures and methods across projects and suppliers

• Dealing with projects and suppliers inaccurately estimating delivery dates

• Understanding the different stakeholder perspectives that strengthen effective risk management for the evaluation activities

• Assessing the balance between managing and taking risks as it affects service delivery

• Demonstrating less variation in predictions during and after transition • Taking a pragmatic and measured approach to risk • Building a thorough understanding of r isks that have impacted or

might impact successful Service Transition • Encouraging a risk management culture where people share

information


• • •••



Performance and Risk Evaluation Manager


90

Performance and Risk Evaluation Manager

• Uses Service Design and release package to develop the evaluation plan to input to service testing

• Establishes risks and issues associated with all aspects of the Service Transition

• Provides evaluation report to input to Change Management


• • • ••

Unit 4: Service TransitionProcess of Knowledge Management


Lesson 8: Process of Knowledge Management


Lesson 8: Process of Knowledge Management


• • •••



Knowledge Management Purpose and Goal


92

Knowledge Management Purpose and Goal

• The purpose of Knowledge Management is to ensure that information is delivered to the appropriate place or competent person at the right time to facilitate an informed decision.

• The goal of Knowledge Management is to help organizations improve the quality of management decisions. It assists in decision making by ensuring that reliable and secure information is available throughout the service lifecycle.


• • • ••



Knowledge Management Objectives


93

Knowledge Management Objectives

• Enable service provider to be more efficient, improve quality of service, increase satisfaction, and reduce cost

• Ensure staff understand the value their services provide to customers and the ways in which this value is realized

• Ensuring that, at a given time and location, service provider staff have adequate information on:

Who is currently using their services

The current states of consumption

Service delivery constraints

Difficulties faced by the customer in fully realizing the benefits expected from the service


• • •••



Knowledge Management Benefits


94

Knowledge Management Benefits

• Thorough understanding of new or changed service by the user, service desk, support staff and supplier

• Awareness of the use of the service, and the discontinuation of previous versions

• Establishment of the acceptable risk and confidence levels associated with the transition


• • • ••



DIKW


95

DIKW

• Knowledge Management is usually displayed within the Data–to–Information–to–Knowledge–to–Wisdom (DIKW) structure.

• Data is a set of discrete facts about events.

• Information comes from providing context to data.

• Knowledge is composed of the tacit experiences, ideas, insights, values, and judgments of individuals.

• Wisdom gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgment.


• • •••



Knowledge Management Activities

Service Knowledge Management consists of the following activities.

Developing a Knowledge Management strategy including:

• Identifying the governance model

• Identifying the organizational changes underway

• Identifying planned and consequential changes in roles and responsibilities

• Establishing roles and responsibilities and ongoing funding

• Identifying policies, processes, procedures and methods for Knowledge Management

• Addressing technology and other resource requirements

• Identifying performance measures

• Identifying and planning for knowledge identification capture and maintenance


96

Knowledge Management Activities

• Developing a Knowledge Management strategy

• Transferring knowledge to other parts of the organization at specific points in the lifecycle

• Establishing data and information requirements

• Defining the information architecture

• Establishing data and information management procedures

• Evaluating and Improving Knowledge Management

• Using the service knowledge management system


• • • ••



Transferring knowledge to other parts of organization at specific points in lifecycle

• Conducting formal training and developing documentation

• Analyzing any knowledge gaps within the organization

• Establishing a communications improvement plan if necessary

Establishing data and information requirements

• Establishing the designated data and information items, content, form, and reason

• Encouraging the use of common and uniform content and format requirements

• Establishing data security requirements

• Defining user access requirements

• Identifying changes

Defining the information architecture

• Creating and regularly updating a Service Management information model

• Defining stable and optimal information systems

• Standardizing data classification schemes across the organization

Establishing data and information management procedures including:

• Identifying information to be collected

• Maintaining and disseminating information collected

• Storing and retrieving data

• Establishing authority and responsibility for information and data items

• Defining and communicating rights, obligations and commitments for the retention of, transmission of, and access to information and data items

• Establishing backup and recovery of data

• Handling collection and retention requirements

Evaluating and Improving Knowledge Management

• Measuring the use of collected information

• Evaluating the usefulness of collected information

• Identifying irrelevant information


• • •••



Using the service knowledge management system

• Aligning training and knowledge material to the business perspective


• • • ••



Knowledge Management Inputs and Outputs

Effective Service Knowledge Management depends on the support and delivery by most, if not all, of those working in and around IT Service Management. Service Knowledge Management has the following specific inputs and outputs.

Service Operations

Service Knowledge Management will record and analyze errors within the service detected during transition. These errors, along with consequences and workarounds, will be communicated to Service Operations.

Operations Staff

Incident management staff, on service desk and second-line support, are the point of capture for much of the everyday IT Service Management data. They must report their actions completely in order for Service Knowledge Management to be effective. Problem management staff will be key users of collected knowledge. They are typically responsible for the normalization of data capture by means of developing and maintaining scripts supporting data capture within incident management.


97

Knowledge Management Inputs and Outputs

• Service Operations

• Operations Staff

• Transition Staff


• • •••



Transition Staff

Service Transition staff capture data of relevance through all lifecycle phases. Therefore, they need to be aware of the importance of collecting it accurately and completely.


• • • ••



Knowledge Management KPIs


98

Knowledge Management KPIs

• Reduction in the user error category of errors due to targeted knowledge transfer

• Lower incident, problem and error resolution times

• Enhanced customer experiences such as:

Quicker resolution of a query Directly resolved issues without external support

Decreased transfer of issues and resolution at lower staff levels Reduced time for transition and duration of early life support


• • •••



Knowledge Management Process Owner

The Knowledge Management process owner has the following responsibilities:

• Ensures compliance with organization policies and processes

• Performs knowledge identification, capture, and maintenance

• Identifies, controls and stores pertinent information not available by any other means

• Maintains the controlled knowledge items

• Ensures all knowledge items are accessible to those who need them

• Monitors publicity regarding the knowledge information

• Acts as an advisor to business and IT personnel on Knowledge Management matters


99

Knowledge Management Process Owner

• The role of the Knowledge Management process owner is crucial.

• This role will design, deliver, and maintain the Knowledge Management strategy, process, and procedures.


• • • ••

Unit 4: Service TransitionUnit Scenario



Unit 4 introduced the management area of Service Transition. Within this area is the introduction of a service into production and its lifecycle. An example of a lifecycle is from development to testing. For this scenario, a company is running its financial structure on a mainframe system. They want to introduce a new financial system into the organization to take advantage of streamlined processes. This change will lead to increased productivity and automation of functions that today can be extremely manual and labor intensive.

An introduction of a new financial system might likely come from the head of the financial department or the operations manager for the IT department. This system initiation might be because of costly maintenance of the mainframe or lack of skills within the team. In addition, a request such as this might come from the leadership of the business. Finance might be unable to provide the type of reporting and analysis necessary to keep up with market trends and fast changing sales approaches.

The request can come in many forms. However, it is likely to enter the system as a service change request because the service of providing financials exists but needs altering. A change to the financial structure of the organization is not one that any business can take lightly. Thus, a request such as this is likely to go through rigorous approvals, reviews and analysis. In addition, it might need approval from the board of the organization because of the cost and level of effort. Transition might not focus on this area. However, it will deal with the change requests that are necessary to implement this service change.

Change Management will oversee the numerous changes, such as a request for hardware and software for the new architecture of the new system. This change should undergo impact, security and data analyses reviews. This unit covered the overall change management concepts and process. Therefore, there will likely be numerous changes. For example, the retirement of the mainframe operations which support the existing financials. Another change might be the establishment of the new software and system to set up testing, development, and training environments.

ITIL v3 introduced the 7 Rs of change. Example of these might be:

• Raised: Financial VP.

• Reason: Current application is not providing the level of financial support to the business as needed.

• Return: Employee efficiencies within the finance team and to the overall business from Sales to Payroll capabilities

• Risks: New system might not be accepted easily; resources will need retraining; IT team is understaffed and will struggle to implement. Cost analysis was inaccurate, and it will require added cost to get to production.


• • •••



• Resources Required: Hardware, software, subject matter experts with the new tool set. Resources trained in main frame for change of processes, project team such as project manager, application designer, and database manager.

• Responsible: Development resources such as a consultant team or database and server administrator who might be responsible for development. Most likely, users, trainers, and system administrators who handle and own responsibility for testing and the final implementation. Can be owned by all of those resources. In addition, the IT operations staff for a smooth transition into production.

• Relationship: Relationship to other changes, such as whether there is a year end or quarter end to be noted, or a sales push for end of year. More tactical examples include other systems with which the tool set will interface. Any downstream systems that might need to be changed to accommodate the new general ledger data or data parameters.

As you learned, service transition does not end at change management. It also encompasses release and service asset configuration management. Change provides the controls that are necessary to bring a new application into an organization. However, release and service asset configuration helps the organization to determine how this will be accomplished. For example, a release unit of the new system might be payroll versus payables. The purpose of this release unit is to minimize external facing risks for the first release of the tool set. In addition, it will also help the organization to quickly revert back to the previous system if redundancy was planned for at least first release.

As you can imagine, the roles involved in a service change such as this are extensive. The unit describes the general ITIL service change roles. A more specific example is the training team assigned to determine necessary training. A further example is the communications team assigned to help advise the whole organization about the changes to the new system. Consider other roles such as database administrators who oversee a new system, or security to ensure system lock down and availability.

This scenario is one example of how Service Transition might be used in an organization. Most organizations are already performing these types of tasks and efforts. However, it is typically not structured, regimented, or controlled in the manner that ITIL v3 introduces.


• • • ••



Review Questions

1. Which of the following are objectives of Service Transition? Choose all that apply.

a.Ensure that IT and the customers have a clear and unambiguous expectation of the level of service to be delivered.

b. Set customer expectations on how the performance and use of the new or changed service can be used to facilitate business change

c. Help the business change project or customer to integrate a release into their business processes and services.


2. Which of the following describes the value Service Transition provides to the business? Check all that apply.

a.Improves predictions of service levels and warranties for new and changed services

b. Expedites timely cancellation or changes to maintenance contracts for both hardware and software when components are disposed of or decommissioned

c. Aids understanding the level of risk during and after change, for example, service outage, disruption, and rework

d. All of the above

3. The IT service must be negatively affecting the business to a high degree to initiate which type of change?

a.Normal Change

b. Standard Change

c. Emergency Change

d. Service Change

4. A desktop move for a single user is an example of which of the following changes?

a.Normal Change

b. Standard Change

c. Emergency Change

d. Simple Change


• • •••



5. A portion of a service or IT infrastructure that is normally released together according to the release policy of the organization is referred to as which of the following choices?

a.Service Change

b. Change Request

c. Configuration Item

d. Release Unit

6. What are the seven Rs of Change Management?

a.Questions that must be answered for all changes

b. A formal policy for Service Transition

c. An outline for the Change Management process

d. All of the above

7. Which is the correct order for service activities in the Service V model?

a.Define Customer and Business Requirements, Design Service Release, Define Service Requirements, Design Service Solution, Develop Service Solution

b. Define Customer and Business Requirements, Define Service Requirements, Design Service Solution, Design Service Release, Develop Service Solution

c. Define Service Requirements, Define Customer/Business Requirements, Design Service Solution, Design Service Release, Develop Service Solution

d. Define Customer and Business Requirements, Define Service Requirements, Design Service Solution, Develop Service Solution, Design Service Release

8. Which is the correct order for validation activities in the Service V model?

a.Validate Service Packages, Offerings, and Contracts, Service Acceptance Test, Service Release Package Test, Component and Assembly Test, Service Operational Readiness Test

b. Service Acceptance Test, Validate Service Packages, Offerings, and Contracts, Service Operational Readiness Test, Service Release Package Test, Component and Assembly Test

c. Validate Service Packages, Offerings, and Contracts, Service Acceptance Test, Service Operational Readiness Test, Service Release Package Test, Component and Assembly Test


• • • ••



d. Validate Service Packages, Offerings, and Contracts, Service Acceptance Test, Service Operational Readiness Test, Component and Assembly Test, Service Release Package Test

9. The addition, modification, or removal of authorized, planned, or supported service or service component and its associated documentation is called which of the following choices?

a.Standard Change

b. Change Request

c. Service Request

d. Service Change

10. A formal communication seeks an alteration to one or more Configuration Items. Which type of change request would this require?

a.Standard Change

b. Change Request

c. Service Request

d. Service Change

11. Which of the following choices is the goal to provide a logical model of the IT infrastructure correlating IT services and components needed to deliver these services? It completes this goal by defining and controlling the components of services and infrastructure and maintaining accurate configuration records.

a.Service Asset and Configuration Management

b. Release and Deployment Management

c. Change Management

d. Service Transition Management

12. Which of the following choices is the goal of deploying releases into production and ensuring effective use of the service to deliver value to the customer?






• • •••




• • • ••



Review Answers

1. Which of the following are objectives of Service Transition? Choose all that apply.

b. Set customer expectations on how the performance and use of the new or changed service can be used to facilitate business change

AND

c. Help the business change project or customer to integrate a release into their business processes and services.

2. Which of the following describes the value Service Transition provides to the business? Check all that apply.

d. All of the above

3. The IT service must be negatively affecting the business to a high degree to initiate which type of change?

c. Emergency Change

4. A desktop move for a single user is an example of which of the following changes?

b. Standard Change

5. A portion of a service or IT infrastructure that is normally released together according to the release policy of the organization is referred to as which of the following choices?

d. Release Unit

6. What are the seven Rs of Change Management?

a. Questions that must be answered for all changes

7. Which is the correct order for service activities in the Service V model?

b. Define Customer and Business Requirements, Define Service Requirements, Design Service Solution, Design Service Release, Develop Service Solution

8. Which is the correct order for validation activities in the Service V model?

c. Validate Service Packages, Offerings, and Contracts, Service Acceptance Test, Service Operational Readiness Test, Service Release Package Test, Component and Assembly Test


• • •••



9. The addition, modification, or removal of authorized, planned, or supported service or service component and its associated documentation is called which of the following choices?

a. Service Change

10. A formal communication seeks an alteration to one or more Configuration Items. Which type of change request would this require?

b. Change Request

11. Which of the following choices is the goal to provide a logical model of the IT infrastructure correlating IT services and components needed to deliver these services? It completes this goal by defining and controlling the components of services and infrastructure and maintaining accurate configuration records.

a. Service Asset and Configuration Management

12. Which of the following choices is the goal of deploying releases into production and ensuring effective use of the service to deliver value to the customer?



• • • ••



Summary


101

Summary

You should now be able to:Explain the key principles and concepts related to Service Transition Discuss Service Transition processes and associated activities

Describe the Service Transition roles

• • • ••

5-1

Unit 5: Service Operation




• • • ••



Introduction

In this unit, you will learn about Service Operation.

Objectives


2

Objectives

Upon completion of this unit, you will be able to:Explain the key principles and concepts related to Service Operation Discuss Service Operation processes and associated activities

Describe the Service Operation roles


• • •••

Unit 5: Service OperationService Operation Overview


Lesson 1: Service Operation Overview


Lesson 1: Service Operation Overview


• • • ••



Service Operation


4

Service Operation

The purpose of Service Operations is to coordinate and to carry out activities and processes required to deliver and manage services at agreed-upon levels to business users and customers


• • •••



Service Operation Scope

Many ITIL processes (such as Change Management and Capacity Management) originate at the Service Design or Service Transition stage of the Service Lifecycle. However, these processes are in use continually in Service Operation. Some processes are not included specifically in Service Operation, such as Strategy Definition, the actual design process itself. These processes focus more on longer-term planning and improvement activities. Therefore, they are outside the direct scope of Service Operation. However, Service Operation provides input and influences these regularly as part of the lifecycle of Service Management.

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 determine the demand for the services and products of organizations. Ultimately, people manage the technology, processes, and services and are a key part of Service Operation.


5

Service Operation: Scope

• Service Operation is any activity that forms part of a service is included in Service Operation. Such activities include those performed by the Service Provider, an external supplier, and the user or customer of that service

• The services themselves. Any activity that forms part of a service is included in Service Operation, even if it is performed by:

The service provider

An external supplier

The user or customer of that service

• Service Management Processes. The ongoing management and execution of many Service Management processes are performed in Service Operation


• • • ••



Service Operation Goals

Any activity that forms part of a service is included in Service Operation. It does not matter if the activity is performed by the Service Provider, an external supplier, or the user or customer of that service.


6

Service Operation: Goals

• Service Operation is responsible for ongoing management of the technology that is used to deliver and support services

• Well-designed and well-implemented processes will be of little value if daily operation of those processes is not properly conducted, controlled, and managed

• Service improvements will not be possible if daily activities to monitor performance, assess metrics, and gather data are not systematically conducted during Service Operations

• Service Operations includes implementation and carrying out of all ongoing activities required to deliver and support services


• • •••



Service Operation Value

However, a challenge to Service Operations exists. A service is expected to run within the budget established earlier in the lifecycle. In reality, however, very 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.”


7

Service Operation Value

• 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


• • • ••



Conflicting Motives in Service Operation

The possibility exists that a conflict might develop between maintaining the status quo and adapting to changes in the business and technological environments.

Resolving the conflict and moving toward a best practice approach represents an opportunity for growth and improvement.


8

Conflicting Motives in Service Operation

• All functions, processes, and activities of a Service Operation are designed to deliver a specified and agreed-upon level of services

• It is possible that a conflict might develop between maintaining the status quo and adapting to changes in the business and technological environments

• One of key roles of the Service Operation is to deal with this conflict and to achieve a balance between conflicting sets of priorities

• Resolving the conflict and moving toward a best-practice approach represents an opportunity for growth and improvement

• IT organizations might suffer from an imbalance by tending more toward one extreme or the other


• • •••



External View of IT

Focusing on business requirements without considering the methods and logistics required to deliver the requirements results in making promises that can not be kept.

Service Operations should maintain a balance between an internal IT view and an external business view.


9

External View of IT

• External view is based on services that are delivered. It is the way in which services are experienced by users and customers. These people might not always understand, nor care about, the details of the technology used to manage those services. All that concerns them is that the services are delivered as required and agreed upon.

• Potential Weakness: Focusing only on business requirements results in making promises that cannot be kept


• • • ••



Internal View of IT

As mentioned before, Service Operations should maintain a balance between an internal IT view and an external business view.


10

Internal View of IT

• The internal view of IT is the way in which IT components and systems are managed to deliver the services

• Potential Weakness: Focusing only on internal systems results in expensive services that deliver little value


• • •••



Stability Versus Responsiveness

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.


11

Service Operation: Stability versus Responsiveness

• Service Operation must ensure that the IT Infrastructure is stable and available as designed

• Service Operation must meet response requirements

• A balance between stability and responsiveness will require that technologies and processes are adaptive rather than rigid


• • • ••



Balancing Service Cost and Quality

Service Operation is required to consistently deliver the agreed-upon level of service. Service Operation must keep costs and resource utilization at an optimal level. An increase in the level of quality typically results in an increase in the cost of service. The relationship between quality and cost of service is not always directly proportional.

For example, improving service availability from 55% to 75% can be straightforward and might not require a huge investment. However, improving availability of the same service from 96% to 99.9% might require large investments in high-availability technology, support staff, and tools.


• • •••



Service Operation: Reactive versus Proactive

Reactive Risks: Each project is dealt with as though it is the first occurrence. Therefore, responding to business needs and incidents only after they are reported can cause delivery of new services to take a long time. Staff turnover tends to be high and morale low, as IT staff move from project to project without achieving a lasting, stable set of IT services.

Proactive Risks: Proactive behavior is typically seen as positive. However, being too proactive can be expensive and can result in staff being distracted. Discouraging effort investment in proactive Service Management can ultimately increase the effort and cost of reactive activities and further risk stability and consistency in services.


13

Service Operation: Reactive versus Proactive

• Reactive: A reactive organization does not act unless it is prompted to do so by an external driver

• Proactive: A proactive organization is always looking for ways to improve the current situation


• • • ••



Communication in Service Operation

In some organizations, communication takes place in meetings. Other organizations prefer to use e-mail or the communication inherent in their Service Management tools.

One organization might require that all communications regarding changes must be sent by e-mail. Others might believe that the Service Management tools themselves contain sufficient information and that e-mails are redundant. Issues can often be prevented or mitigated with appropriate communication. All communication must have an intended purpose or a resultant action. Information should not be communicated unless there is a clear audience.

Good communication is essential for successful Service Operation, just as it is for any other phase of the lifecycle.


14

Communication in Service Operation

Good communication is needed:

• With other IT teams and departments

• With users and internal customers

• Between the Service Operation teams and departments themselves


• • •••



Technology Considerations for Service Operation

An integrated ITSM technology is needed that includes the following core functions:

• Self-help capabilities

• Workflow or process engine

• Integrated CMS

• Discovery, deployment, and licensing technology

• Remote control

• Diagnostic utilities

• Reporting

• Dashboards

• Integration with business service management


15

Technology Considerations for Service Operation

• Technology for Event Management

• Technology for Incident Management

• Technology Tools for Request Fulfillment

• Technology Tools for Problem Management

• Technology Tools for Access Management

• Technology Tools for Service Desk


• • • ••



Technology for Event Management

Technology for Event Management should permit a direct interface into the Incident Management processes. This interface would be completed by entry into the Incident Log. In addition, technology for Event Management should include the capability to escalate to support staff, third-party suppliers, or engineers.

Technology for Incident Management

An integrated ITSM technology is required. In addition, workflow and automated escalation tools should be used. The target times should be included in support tools, which should be used to automate the workflow control and escalation paths.

Technology Tools for Request Fulfillment

Integrated ITSM technology is needed so that Service Requests can be linked to incidents or events that have initiated them.

Technology Tools for Problem Management

The following tools are needed for Problem Management:

• Integrated Service Management technology

• Integrated Change Management technology

• Integrated CMS

• An effective Known Error Database

Technology Tools for Access Management

The following tools are needed for Access Management:

• Human Resource Management technology

• Access Management features in Applications, Middleware, Operating Systems and Network Operating Systems

• Change Management systems

• Request Fulfillment technology


• • •••



Technology Tools for Service Desk

The following tools are needed for Service Desk

• Telephony

• Support tools such as:

– Known Error Database

– Diagnostic scripts

– Self-help web Interface


• • • ••

Unit 5: Service OperationProcess of Event Management


Lesson 2: Process of Event Management


Lesson 2: Process of Event Management


• • •••



Event Management Defined

Effective Service Operation depends on knowing the status of the infrastructure and detecting any deviation from normal or expected operation. It 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.

The ability to detect events, make sense of them, and determine their appropriate control action is provided by Event Management. Event Management is, therefore, the basis for Operational Monitoring and Control. In addition, if these events are programmed to communicate operational information, warnings, and exceptions, they can be used as a basis for automating many routine Operations Management activities. Some examples of Event Management:

• Executing scripts on remote devices

• Submitting jobs for processing

• Dynamically balancing the demand for a service across multiple devices to enhance performance


17

Event Management

• An event can be defined as any significant detectable occurrence.

• An occurrence is significant if it affects the management of the IT infrastructure or the delivery of IT service.

• Events are typically notifications created by an IT Service, Configuration Item (CI), or monitoring tool.


• • • ••



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, and Service Improvement


• • •••



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 is an unusual combination of workloads. As the workloads are completed, normal operation is restored. In other cases, operator 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 without previous configuration. The next section will explore exactly how events are defined, generated, and captured.


• • •••



Event Management Benefits


19

Event Management Benefits

• Provides mechanisms for early detection of incidents

• Makes it possible for some types of automated activity to be monitored by exception

• Signal status changes or exceptions that allow the appropriate person or team to perform early response

• Allows the business to benefit from more effective and more efficient Service Management overall

• Provides a basis for automated operations


• • • ••



Event Management Activities

The Event Management process is initiated by an event. Event Management contains the following activities:

• Occurrence of event

• Notification of event

– Most CIs generate Event notifications using an open standard such as SNMP (Simple Network Management Protocol).

– Event notification should contain meaningful data and target a specific audience

• Detection of event

The event is detected by an agent running on the same system, or transmitted directly to a management tool that will read and interpret the event.

• Event filtering

It is determined whether the event is informational, a warning, or an exception.

• Categorization of event


20

Event Management Activities

• Occurrence of event

• Notification of event

• Detection of event

• Event filtering

• Categorization of event

• Correlation of event

• Initiation of a trigger

• Selection of response

• Review of actions

• Closing of event


• • •••



• The event is categorized as being informational, warning, or an exception.

• Informational: Informational refers to an event that does not require any action and does not represent an exception.

• Warning: A warning is an event that is generated when a service or device is approaching a threshold.

• Exception: An exception means that a service or device is currently operating abnormally. This typically means that an SLA an OLA have been breached and business is being affected. An example of an exception is a server going down.

• Correlation of event

The significance of the event and the actions that should be taken is determined.

• Initiation of a trigger

If a response is required, it is initiated using a trigger. For example, if a change is required, a Change Trigger will initiate a Request for Change.

• Selection of response: In this activity, responses to the event are chosen. They could include:

– Logging the event

– Auto responding to the event

– Escalating the event to include human intervention

– Initiating the Incident, Problem, or Change Management process

– Opening an RFC

– Opening or linking to a problem record

– Opening an Incident record

• Review of actions

Significant events or exceptions are handled and tracked appropriately.

• Closing of event

Most events are not opened or closed. However, events that generated an incident, problem, or change should be formally closed. A link to the appropriate record from the other process should be included.


• • • ••



Event Management Interfaces

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 process, for example, 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 has reached a predefined threshold of performance

Event Management can interface to any process that requires monitoring and control. It is especially effective for those processes that do not require real-time monitoring. However, these processes do require some form of intervention following an event or group of events.


21

Event Management Interfaces



• Capacity and Availability Management


• Asset Management


• • •••



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. In addition, they define what appropriate thresholds should be and how to respond to them. In return, Event Management will improve the performance and availability of services. It will respond to events when they occur and by reporting on actual events and patterns of events. The reports will be used to determine (by comparison to SLA targets and KPIs) if some aspect of the infrastructure design or operation can be improved.

Configuration Management can 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 to determine whether unauthorized activity is taking place in the organizations.

Asset Management can use Event Management to determine the lifecycle status of assets. For example, an event can 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 play an important role in ensuring that potential impact on SLAs is detected early. In addition, it can ensure that any failures are rectified as soon as possible so that impacts on service targets are minimized.


• • • ••



Event Management KPIs

Other KPIs for Event Management include:

• Number and percentage of repeated or duplicated events

• Number and percentage of events indicating performance issues

• Number and percentage of events indicating potential availability issues

• Number and percentage of each type of event per platform or application

• Number and ratio of events compared with the number of incidents


22

Event Management KPIs

• Number of events by category

• Number of events by significance

• Number and percentage of events that required and had human intervention

• Number and percentage of events that resulted in incidents or changes

• Number and percentage of events caused by existing problems or known errors


• • •••



Event Management Challenges, Critical Success Factors, and Risks

The main critical success factors for effective Event Management include:

• Illustrating the benefits of effective Event Management in terms of a positive return on investment.

• Achieving the correct level of filtering. There are three keys to the correct level of filtering:

• Integrate Event Management into all Service Management processes where feasible.

• Design new services with Event Management in mind.

• Include a formal process to evaluate the effectiveness of filtering.

• Planning effectively for the rollout of the monitoring agent software across the entire IT Infrastructure.


23

Event Management Challenges

• Obtaining the necessary funding.

• Setting the correct level of filtering.

• Rolling out of the necessary monitoring agents across the entire IT infrastructure.

• Acquiring the necessary skills at a reasonable cost and in a reasonable amount of time.


• • • ••



The main risks associated with Event Management include:

• Failure to obtain adequate funding.

• Failure to ensure the correct level of filtering.

• Failure to maintain momentum in rolling out the necessary monitoring agents across the IT Infrastructure.


• • •••



Event Management Roles

The Service Desk is responsible for communicating information about this type of incident to the relevant Technical or Application Management team and, where appropriate, the user.

Technical and Application Management participates in the instrumentation of the service, classify events, update correlation engines, and ensure that any auto responses are defined during Service Design. During Service Transition, they will test the service to ensure that events are properly generated. In addition, they will ensure that the defined responses are appropriate. During Service Operation, Technical and Application Management will typically perform Event Management for the systems under their control.

It is common for Event Monitoring and first-line response to be delegated to IT Operations Management. Operators for each area are tasked with monitoring events, responding as required, or ensuring that Incidents are created as appropriate.


24

Event Management Roles

• Events tend to occur in multiple contexts and for many different reasons.

• It is unusual for an organization to appoint an Event Manager.

• It is important that Event Management procedures are coordinated to prevent duplication of effort and tools.


• • • ••

Unit 5: Service OperationIncident Management


Lesson 3: Incident Management


Lesson 3: Process of Incident Management


• • •••



Incidents Defined

An incident includes failure of a configuration item that has not yet affected service is also an incident. An example is the failure of one disk from a mirror set.

Incident Management can include handling failures, questions, or queries reported by the users. Examples of ways incidents can be reported include:

• Telephone calls to the Service Desk

• Communications from technical staff

• Automatic detection and reports by event monitoring tools

Incidents can also be reported, logged, or both, by technical staff. For example, technical staff notice something unusual with a hardware or network component,. They can report or log an incident and refer it to the Service Desk. However, all events are not necessarily incidents. Many classes of events are not related to disruptions at all, but are indicators of normal operation or are simply informational.

Although both incidents and Service Requests are reported to the Service Desk, they are not the same. Service Requests do not represent a disruption to agreed-upon service. They provide a way to meet the needs of the customers and can address an agreed-upon target in a Service Level Agreement. Service Requests are dealt with by the Request Fulfillment process.


26

Incidents Defined

• Unplanned interruption to an IT service

• Reduction in the quality of an IT service

• Failure of a configuration item that has not yet affected service


• • • ••



Incident Management

Incident Management is the process for dealing with all incidents. This process can include:

• Failures

• Questions

• Queries

Incident Management includes any event that disrupts, or that might disrupt, a service. It includes events which are communicated directly by users, either through the Service Desk or through an interface from Event Management to Incident Management tools.


27

Incident Management

• Incident Management restores normal service operation as quickly as possible and minimizes the adverse impact on business operations, therefore ensuring that the best possible levels of service quality and availability are maintained

• Normal service operation is defined as service operation within Service Level Agreement (SLA) limits


• • •••



Incident Management Goals

Normal Service Operation is defined as Service Operation within Service Level Agreement (SLA) limits.


28

Incident Management Goals

• The primary goal of the Incident Management process is to restore normal Service Operation as quickly as possible.

• Incident Management tries to minimize the adverse impact on business operations.

• Restoring normal Service Operations ensures that the best possible levels of service quality and availability are maintained.


• • • ••



Incident Management Terms

Time Scales

Time scales must be agreed upon for all incident-handling stages. These will differ, depending upon the priority level of the incident. Time scales will be captured as resolution targets within Operational Level Agreements and Underpinning Contracts. All support groups should be made fully aware of these time scales. Service management tools should be used to automate time scales and escalate the incident as required based on predefined rules.

Incident Modules

Many incidents are not new. They involve deal with something that has happened before and might happen again. For this reason, many organizations find it helpful to predefine standard incident models and apply them to appropriate incidents when they occur. An incident model is a way of predefining the steps that should be taken to handle a process in an agreed-upon way. Support tools can then be used to manage the required process. This process will ensure that standard incidents are handled in a predefined path and within predefined time scales.


29

Incident Management Terms

• Time Scales

• Incident Modules

• Major Incidents

• The role of Problem Management in Incidents


• • •••



Major Incidents

A separate procedure, with shorter time scales and greater urgency, must be used for major incidents. A definition of what constitutes a major incident must be agreed upon. In addition, it must be ideally mapped to the overall incident prioritization system. Then, this type of incident will be dealt with through the major incident process.

People sometimes use loose terminology or confuse a Major Incident with a problem. In reality an incident remains an incident forever. It might grow in impact or priority to become a Major Incident, but an incident never becomes a problem. A problem is the underlying cause of one or more incidents and always remains a separate entity.

When necessary, the major incident procedure should include the dynamic establishment of a separate major incident team under the direct leadership of the Incident Manager. This team is formulated to concentrate on this incident alone to ensure adequate resources and focus are provided to finding a swift resolution. Sometimes the Service Desk Manager also fulfills the role of Incident Manager (for example, in a small organization). To avoid time or priority conflicts, a separate person might need to be designated to lead the team. That person should ultimately report back to the Incident Manager.

The Role of Problem Management in Incidents

If the cause of the incident needs to be investigated at the same time, then the Problem Manager will be involved as well. However, the Incident Manager must ensure that service restoration and underlying cause are kept separate. Throughout the investigation, the Service Desk ensures that all activities are recorded and users are kept fully informed of progress.


• • • ••



Incident Management Process Flow

All incidents must be fully logged and stamped with date and time, regardless of their origin. They might be raised through a Service Desk telephone call or automatically detected through an event alert. A separate Incident Record must be logged for each additional incident handled. This record ensures that an historical record is kept and credit is given for the work performed. All relevant information relating to the nature of the incident must be logged so that a full historical record is maintained. If the incident has to be referred to other support groups, they will have all the relevant information to assist them.

The information needed for each incident is likely to include the following items:

• Unique reference number

• Incident categorization (often broken down into between two and four levels of subcategories)

• Incident urgency

• Incident impact

• Incident prioritization


• • •••



• Date and time recorded

• Name and ID of the person or group recording the incident

• Method of notification (telephone, automatic, e-mail, in person, and so on)

• Name, department, telephone, location of user

• Callback method (telephone, mail, and so on)

• Description of symptoms

• Incident status (active, waiting, closed and so on)

• Related Configuration Item

• Support group or person to which the Incident is allocated

• Related problem or known error

• Activities undertaken to resolve the incident

• Resolution date and time

• Closure category

• Closure date and time

Part of the initial logging must allocate suitable incident categorization coding so that the exact type of the call is recorded. This code will be important later when looking at incident types and frequencies. Therefore, trends for use in Problem Management, Supplier Management, and other ITSM activities can be established. Multilevel categorization is available in most tools, typically to three or four levels of granularity. For example, an incident might be defined as one of the following categories:

• Hardware

• Server

• Memory Board

• Cell Card Failure

• Software

• Application


• • • ••



Incident Process Flow


31

Incident Process Flow

• All incidents must be fully logged, date stamped, and time stamped, regardless of whether they are raised through a Service Desk

• All relevant information relating to the nature of the incident must be logged

• A suitable incident categorization coding should record the exact type of the call

• Every incident should have an appropriate prioritization code


• • •••



Incident Management Benefits

The value of Incident Management includes:

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

• The ability to align IT activity to real-time business priorities. Incident Management includes the capability to identify business priorities and dynamically allocate resources as necessary.

• The ability to identify potential improvements to services. This ability is a result of understanding what constitutes an Incident. In addition it comes from being in contact with the activities of Business operational staff.

• The Service Desk can, during their handling of incidents, identify additional service or training requirements found in IT or the business.

Incident Management is highly visible to the business. It is, therefore, easier to demonstrate the value than most areas in Service Operation. For this reason, Incident Management is often one of the first processes to be implemented in Service Management projects. An added benefit is that Incident Management can be used to highlight other areas that need attention. Therefore, justification for expenditure on implementing other processes is provided.


32

Incident Management Benefits

• Incident Management is highly visible to the business

• Incident Management is often one of the first processes to be implemented in Service Management projects

• Incident Management detects and resolves incidents results in lower downtime to the business

• Incident Management identifies potential improvements to services


• • • ••



Incident Management Activities

• Incident Identification

– All key components should be monitored so that failures or potential failures are detected early. Early detection ensures that Incident Management can be started quickly.

– Incidents should be resolved before they have an impact on users.

• Incident Logging

– All incidents must be fully logged, date stamped, and time stamped. Logging should occur for incidents that are raised through a Service Desk call and those automatically detected by an event alert.

• Incident Categorization

Initial logging should include allocation of suitable incident categorization coding so that the exact type of the call is recorded.

• Incident Prioritization

Logging the incident must include agreement and allocation of an appropriate prioritization code.

• Investigation and Diagnosis


33

Incident Management Activities

• Incident Identification

• Incident Logging

• Incident Categorization

• Incident Prioritization

• Investigation and Diagnosis

• Escalation

• Resolution and Recovery

• Incident Closure


• • •••



• Escalation

The Service Desk should keep the user informed of any relevant escalation that takes place. It should ensure the Incident Record is updated accordingly to keep a full history of actions.

• Resolution and Recovery

The Service Desk should be able to provide some help fairly quickly and resolve service requests for some informational requests. However, if a fault is being reported, this is an incident and likely to require some degree of investigation and diagnosis.

• Incident Closure

The Service Desk should check that the incident is fully resolved. In addition, it should be determined that users are satisfied and willing to agree that the incident can be closed.

Some of these activities are discussed further in the following pages.


• • • ••



Incident Prioritization

Every incident should have an appropriate prioritization code. This code will determine how the incident is handled both by support tools and support staff.

An indication of impact is often, but not always, the number of users being affected. In some cases, the loss of service to a single user can have a major business impact. It all depends upon who is trying to do what. Therefore, numbers alone are not enough to evaluate overall priority.


34

Incident Prioritization

Prioritization can normally be determined by taking into account both:

The urgency of the incident (how quickly the business needs a resolution) The level of impact it is causing


• • •••



Incident Priorities

Priority 1: Significant damage, must be recovered immediately

Priority 2: Limited damage, should be recovered immediately

Priority 3: Significant damage, does not need to be recovered immediately

Priority 4: Limited damage, does not need to be recovered immediately


35

Priorities


• • • ••



Urgency, Impact, and Priority

Priority = Impact x Urgency


36

Urgency, Impact, and Priority

• PriorityThe required sequence of Incident resolutionPriority = Impact x Urgency

• Impact The extent to which an incident leads to a departure from expected service operations, such as the number of users or CIs affected

• Urgency The required speed of resolving an Incident


• • •••



Diagnosis and Investigation

If the incident has been routed through the Service Desk, the Service Desk Operator must carry out initial diagnosis. This diagnosis typically occurs while the user is still on the telephone. If the call is raised in this way, the operator tries to discover the full symptoms of the incident. In addition, the operator tries to determine exactly what has gone wrong and how to correct it. It is at this stage that diagnostic scripts and known error information can be most valuable in facilitating earlier and accurate diagnosis.

If possible, the Service Desk Operator will resolve the incident while the user is still on the telephone. In addition, the operator will close the incident if the resolution is successful.

Sometimes the Service Desk Operator cannot resolve the incident while the user is still on the telephone. However, there is a prospect that the Service Desk might be able to resolve it within the agreed-upon time limit without assistance from other support groups. In this case, they should inform the user of their intentions, give the user the incident reference number, and attempt to find a resolution.

In some incidents the user is just seeking information. In this case, the Service Desk should be able to provide the information fairly quickly and resolve the service request. However, if a fault is being reported, it is an incident and likely to require some degree of investigation and diagnosis.

Each of the support groups involved with the incident handling will investigate and diagnose what has gone wrong. All such activities (including details of any actions taken to try and resolve or re-create the incident) should be fully documented in the incident


37

Diagnosis and Investigation

• The Service Desk Operator must carry out initial diagnosis, typically while the user is still on the telephone

• If possible, the Service Desk Operator will resolve the incident while the user is still on the telephone and close the incident if the resolution is successful

• In the case of incidents where the user is just seeking information, the Service Desk should be able to provide it quickly and resolve the service request

• If the Service Desk cannot resolve the issue, the Service Desk will begin functional escalation to the next level of support


• • • ••



record. This documentation ensures that a complete historical record of all activities is maintained at all times.

Valuable time can often be lost if investigative and diagnostic action (or indeed resolution or recovery actions) are performed serially. Where possible, such activities should be performed in parallel to reduce overall time scales, and support tools should be designed and selected to permit this parallel action. However, care should be taken to coordinate activities, particularly resolution or recovery activities. Otherwise, the actions of different groups might conflict or further complicate a resolution.


• • •••



Incident Escalation

Functional Escalation

Sometimes it becomes clear that the Service Desk cannot resolve the incident themselves. In addition, sometimes the target times for first point resolution have been exceeded. In either case, the incident must be immediately escalated for further support. If the organization has a second-level support group, the Service Desk should refer the incident to them. However, sometimes it is obvious that the incident will need deeper technical knowledge. Also, there are times when the second-level group has not been able to resolve the incident within agreed-upon target times. In either of these cases, the incident must be immediately escalated to the appropriate third-level support group.

Note: Third-level support groups might be internal, but they might also be third parties such as software suppliers or hardware manufacturers.

The rules for escalation and handling of incidents must be agreed upon in Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). Rules must exist for internal and external support groups.


38

Incident Escalation

• Functional Escalation

• Hierarchical Escalation


• • • ••



Hierarchic Escalation

If incidents are of a serious nature (for example, priority 1 incidents), the appropriate IT managers must be notified, for informational purposes at least. Hierarchic escalation is also used if the Investigation and Diagnosis or Resolution and Recovery steps are taking too long. They are also used if the steps are proving to be too difficult. Hierarchic escalation should continue up the management chain so that senior managers are aware, can be prepared, and take any necessary action, such as allocating additional resources or involving suppliers. Hierarchic escalation is also used when there is contention about to whom the Incident is allocated. Hierarchic escalation can be initiated by the affected users or customer management as they see fit. Therefore, it is important to make IT managers aware so that they can anticipate and prepare for any such escalation.

The exact levels and time scales for both functional and hierarchic escalation need to:

• Be agreed upon

• Take into account Service Level Agreement targets

• Be embedded within support tools

The tools can then be used to police and control the process flow within agreed-upon time scales.

The Service Desk should keep the user informed of any relevant escalation that takes place. In addition, the service desk should ensure the incident record is updated accordingly. This record will keep a full history of actions.


• • •••



Incident Resolution, Recovery, and Closure

When a potential resolution has been identified this should be applied and tested. The specific recovery actions and the people who will be involved them might vary, depending upon the nature of the fault.

In some cases it might be necessary for two or more groups to take separate, though perhaps coordinated, recovery actions for a resolution. In such cases, Incident Management must coordinate the activities and interact with all parties involved.

Regardless of the actions taken, or who does them, the incident record must be updated accordingly. The update should include all relevant information and details. This update ensures that a full history is maintained. The resolving group should pass the incident back to the Service Desk for closure action.

The Service Desk should check that the incident is fully resolved. In addition it should check that the users are satisfied and willing to agree that the incident can be closed.

Some organizations might use an automatic closure period on specific, or even all, incidents. For example, the incident will be automatically closed after two working days if no further contact is made by the user. When this approach is considered, it must first be fully discussed and agreed upon with the users. It also needs to be widely publicized so that all users and IT staff are aware of the method. It might be inappropriate to use this method for certain types of incidents, such as Major Incident or those involving VIPs. Despite all adequate care, sometimes incidents recur, even though they have been formally closed. Because of such cases, it is wise to have predefined rules regarding if and when an incident


39

Incident Resolution, Recovery, and Closure

• Even when a resolution has been found, sufficient testing must be performed to ensure that recovery action is complete and that the service has been fully restored to the users

• The incident record must be updated accordingly with all relevant information and details so that a full history is maintained

• The resolving group should return the incident to the Service Desk for closure action

• It might make sense, for example, to agree that if the incident recurs within one working day, it can be re-opened. After one working day, a new incident must be raised, but linked to the previous incidents


• • • ••



can be re-opened. It might make sense, for example, to agree that if the incident recurs within one working day then it can be reopened. However, beyond this point a new incident must be raised, but it should be linked to the previous incidents.


• • •••



Incident Management Interfaces

Problem Management: Incident Management forms part of the overall process of dealing with problems in the organization. Incidents are often caused by underlying problems, which must be solved to prevent the incident from recurring. Incident Management provides a point where incidents are reported.

Configuration Management: This role provides the data used to identify and track the progress of solving incidents. Uses of the Configuration Management System (CMS) include:

• Identifying faulty equipment

• Assessing the impact of an incident

• Identifying the users affected by potential problems

The CMS contains information about which categories of incident should be assigned to which support group. In turn, Incident Management can maintain the status of faulty CIs. It can also assist Configuration Management to audit the infrastructure when working to resolve an incident.

Change Management: Where a change is required to implement a workaround or resolution, the change needs to be logged as a Request for Change (RFC). It is then sent through Change Management. In turn, Incident Management is able to detect and resolve incidents that arise from failed changes.


40

Incident Management Interfaces

• Problem Management





• Service Level Management (SLM)


• • • ••



Capacity Management: Incident Management provides a trigger for performance monitoring where there seems to be a performance problem. Capacity Management might develop workarounds for incidents.

Availability Management: Availability Management will use Incident Management data to determine the availability of IT services and look at where the incident lifecycle can be improved.

Service Level Management (SLM): The ability to resolve incidents in a specified time is a key part of delivering an agreed-upon level of service. Incident Management enables SLM to define measurable responses to service disruptions. It also provides reports that help SLM to review SLAs objectively and regularly. In particular, Incident Management is able to assist in defining where services are at their weakest. Therefore, SLM can define actions as part of the Service Improvement Program (SIP). (See the Continual Service Improvement book for more details). SLM defines the acceptable levels of service within which Incident Management works, including:

• Incident response times

• Impact definitions

• Target fix times

• Service definitions, which are mapped to users

• Rules for requesting services

• Expectations for providing feedback to users


• • •••



Incident Management Inputs

Most information used in Incident Management comes from the following sources:

• The Incident Management tools, which contain information about:

– Incident and problem history

– Incident categories

– Action taken to resolve incidents

– Diagnostic scripts

• Incident Records, which include the following data:

– Unique reference number

– Incident classification

– Date and time of recording and any subsequent activities

– Name and identity of the person recording and updating the Incident Record

– Name, organization, and contact details of affected users

– Description of the incident symptoms


41

Incident Management Inputs

• Incident Management Tools

• Incident Records


• • • ••



– Details of any actions taken to try to diagnose, resolve, or re-create the incident

– Incident category, impact, urgency, and priority

– Relationship with other incidents, problems, changes or Known Errors

– Closure details


• • •••



Incident Management Key Performance Indicators

The metrics that should be monitored and reported upon to judge the efficiency and effectiveness of the Incident Management process, and its operation, will include:

• Total numbers of Incidents (as a control measure)

• Breakdown of incidents at each stage (for example logged, WIP, or closed)

• Size of current incident backlog

• Number and percentage of major incidents

• Mean elapsed time to achieve Incident resolution or circumvention, broken down by impact code

• Percentage of Incidents handled within agreed response time (incident response-time targets might be specified in SLAs, for example, by impact and urgency codes)

• Average cost per incident

• Number of incidents reopened and as a percentage of the total

• Number and percentage of incidents incorrectly assigned


42

Incident Management Key Performance Indicators

• Total numbers of Incidents (as a control measure)

• Number and percentage of major incidents

• Mean elapsed time to achieve incident resolution or circumvention, broken down by impact code

• Percentage of incidents handled within agreed-upon response time (Incident response-time targets may be specified in SLAs, for example, by impact and urgency codes)

• Number of incidents reopened and as a percentage of the total

• Percentage of incidents closed by the Service Desk without reference to other levels of support (often referred to as first point of contact)


• • • ••



• Number and percentage of incidents incorrectly categorized

• Percentage of Incidents closed by the Service Desk without reference to other levels of support (often referred to as first point of contact)

• Number and percentage of Incidents processed per Service Desk agent

• Number and percentage of Incidents resolved remotely, without the need for a visit

• Number of incidents handled by each Incident Model

• Break-down of incidents by time of day, to help pinpoint peaks and ensure matching of resources

Reports should be produced under the authority of the Incident Manager. This person should draw up a schedule and distribution list. These actions should be done in collaboration with the Service Desk and support groups handling incidents. Distribution lists should at least include IT services management and specialist support groups. Consider also making the data available to users and customers, for example, through SLA reports.


• • •••



Incident Management Challenges, Success Factors, and Risks

Critical Success Factors of Incident Management include:

• A quality Service Desk.

• Clearly defined targets from SLAs.

• Skilled and customer oriented support staff at all stages of the process.

• Integrated support tools to drive and control the process.

• Well defined agreements that influence and shape the correct behavior of all support staff.

Risks to successful Incident Management include:

• Improperly trained or unavailable resources.

• Inadequate support tools to raise alerts and prompt progress.

• Inadequate tools or lack of integration.

• Poorly aligned or non-existent OLAs or underpinning contracts.


43

Incident Management Challenges

• Detecting incidents as early as possible

• Convincing all staff (technical teams as well as users) that all incidents must be logged

• Encouraging the use of self-help Web-based capabilities (which can speed up assistance and reduce resource requirements)

• Availability of information about problems and known errors

• Integration into the Configuration Management System • Integration into the Service Level Management process


• • • ••



Incident Manager

The main role of Incident Management is that of the Incident Manager. In many organizations the role of Incident Manager is assigned to the Service Desk supervisor. In larger organizations with high volumes, a separate role might be necessary. In both cases, it is important to give the Incident Manager the authority to manage incidents effectively through the first, second, and third lines.


44

Incident Manager

• Driving the efficiency and effectiveness of the Incident Management process

• Producing management information

• Managing the work of incident support staff (first line and second line)

• Monitoring the effectiveness of Incident Management and making recommendations for improvement

• Developing and maintaining the Incident Management systems

• Managing major incidents

• Developing and maintaining the Incident Management process and procedures


• • •••

Unit 5: Service OperationProcess of Request Fulfillment


Lesson 4: Process of Request Fulfillment


Lesson 4: Process of Request Fulfillment


• • • ••



Request Fulfillment

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, and low cost. Examples of these changes are:

• 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.

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 Fulfillment is the processes of dealing with service requests from the users. The objectives of Request Fulfillment process include:

• To provide a channel for users to request and receive standard services for which a predefined approval and qualification process exists


46

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

• 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


• • •••



• 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 Fulfillment 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 Fulfillment effectively reduces the bureaucracy involved in requesting and receiving access to existing or new services. Therefore, it also reducing the cost of providing these services. Centralizing fulfillment also increases the level of control over these services. This in turn can help reduce costs through centralized negotiation with suppliers, and can also help to reduce the cost of support.


• • • ••



Service Request Examples


47

Service Request Examples

Service Requests are typically small changes that are low risk, frequently occurring, and low costExamples:

A request to change a passwordA request to install an additional software application onto a particular workstation

A request to relocate some items of desktop equipment


• • •••



Request Fulfillment Objectives


48

Request Fulfillment Objectives

• To provide a channel for users to request and receive standard services for which a predefined approval and qualification process exists

• 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


• • • ••



Request Fulfillment Benefits


49

Request Fulfillment Benefits

• Provides quick and effective access to standard services. Business staff can use this access to improve their productivity or the quality of business services and products.

• Effectively reduces the bureaucracy involved in requesting and receiving access to existing or new services.

• Reduces the cost of providing these services. • Centralizing fulfillment increases the level of control over

these services. This control can reduce costs through centralized negotiation with suppliers and can also reduce the cost of support.


• • •••



Request Fulfillment Activities

The Request Fulfillment process has the following activities:

• Menu Selection:

Users should be offered a menu type selection using a web interface to select and input details of Service Requests from a pre-defined list. Then, appropriate expectations can be set by giving target delivery or implementation target dates.

• Financial Approval:

The cost of fulfilling the request must first be established.

• Other Approval:

In some cases, further approval might be needed.

• Fulfillment:

Some simpler requests might be completed by the Service Desk. Others might have to be forwarded to specialist groups or suppliers for fulfillment


50

Request Fulfillment Activities

• Menu Selection

• Financial Approval

• Other Approval

• Fulfillment


• • • ••



Request Fulfillment Interfaces


51

Request Fulfillment Interfaces

• Service Desk and Incident Management

• Release Management

• Asset and Configuration Management


• • •••



Request Fulfillment Inputs

The Request Fulfillment process requires input from the following sources:

• Service Requests for information about:

– The service is being requested and when it was requested

– The requestor and authorizer of the service

– The process that will be used to fulfil the request

– The person assigned the request

– The action that was taken and when it was taken

– The date and time when the request was logged as well as the date and time of all actions taken

– Closure details

• Requests for Change when the Request Fulfillment process is initiated by an RFC


52

Request Fulfillment Inputs

• Service Requests

• Requests for Change

• The Service Portfolio

• Security Policies


• • • ••



• The Service Portfolio which will identify the scope of the agreed Service Request to be identified

• Security Policies will prescribe any controls to be executed or adhered to when providing the service


• • •••



Request Fulfillment KPIs


53

Request Fulfillment KPIs

• Total number of Service Requests

• Breakdown of service requests at each stage

• Size of current backlog of outstanding Service Requests

• Mean elapsed time for handling each type of Service Request

• Number and percentage of Service Requests completed within agreed target times

• Average cost per type of Service Request

• Level of client satisfaction with the handling of Service Requests


• • • ••



Request Fulfillment Challenges, Critical Success Factors, and Risks

Request Fulfillment has the following critical success factors:

• Agreement about the services that will be standardized, the authorization process, and the cost

• Publication of the services to users as part of the Service Catalog

• Definition of a standard fulfillment procedure for each of the services being requested

• Identification of a single point of contact which can be used to request the service

• Provision of the self-service tools to provide a front-end interface to the users

Request Fulfillment can encounter the following risks:

• Poorly defined scope, where people are unclear about exactly what the process is expected to handle

• Poorly designed or implemented user interfaces so that users have difficulty raising the requests that they need


54

Request Fulfillment Challenges

• Clearly defining and documenting the type of requests that will be handled within the Request Fulfillment process

• Clearly defining and documenting the type of requests that will either go through the Service Desk and those that will need to go through formal Change Management

• Establishing self-help front-end capabilities that allow the users to interface successfully with the Request Fulfillment process


• • •••



• Badly designed or operated back-end fulfillment processes that can't handle the requests being made

• Inadequate monitoring capabilities so that accurate metrics cannot be gathered


• • • ••



Request Fulfillment Roles


55

Request Fulfillment Roles

• Service Desk and Incident Management staff initially handle Service Requests.

• Eventual fulfillment will be undertaken by the appropriate Service Operation teams or departments or by external suppliers.

• Often, Facilities Management, Procurement, and other business areas aid in the fulfillment of the Service Request.

• In most cases there will be no need for additional roles to be created.


• • •••

Unit 5: Service OperationProcess of Problem Management


Lesson 5: Process of Problem Management


Lesson 5: Process of Problem Management


• • • ••



Problem Management

ITIL defines a problem as the unknown cause of one or more incidents.

Problem Management is the process responsible for managing the lifecycle of all problems.

Problem Management prevents problems and resulting incidents from happening, eliminates recurring incidents, and minimizes the impact of incidents that cannot be prevented.

Problem Management includes the activities required to diagnose the root cause of incidents and to determine the resolution to those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures, especially Change Management and Release Management.

Problem Management will also maintain information about problems and the appropriate workarounds and resolutions. Then the organization can reduce the number and impact of incidents over time. In this respect Problem Management has a strong interface with Knowledge Management. Tools such as the Known Error Database will be used for both.

Although Incident Management and Problem Management are separate processes, they are closely related. In addition, they will typically use the same tools. Furthermore, they might also use similar categorization, impact, and priority coding systems. This similarity will ensure effective communication when dealing with related incidents and problems.


57

Problem Management

• A problem is the unknown cause of one or more incidents

• Problem Management includes the activities required to diagnose the root cause of incidents and to determine the resolution to those problems

• Problem Management will also maintain information about problems and the appropriate workarounds and resolutions

• Problem Management works together with Incident Management and Change Management to ensure that IT service availability and quality is increased


• • •••



Problem Management works with Incident Management and Change Management to ensure that IT service availability and quality is increased. When incidents are resolved, information about the resolution is recorded. Over time, this information is used to shorten the resolution time and identify permanent solutions, reducing the number of incidents and their resolution time. The result is less downtime and less disruption to business critical systems.


• • • ••



Problem Management Concepts

Problem Management consists of two major processes:

• Reactive Problem Management, which is generally performed as part of Service Operation

• Proactive Problem Management, which is initiated in Service Operation, but generally operates as part of Continual Service Improvement

Creating a Known Error Record in the Known Error Database ensures quicker diagnosis. In addition, the creation of a Problem Model for handling such problems in the future might be helpful. This concept is similar to the idea of Incident Models, but applied to problems and incidents.

The Known Error record should hold exact details of the fault and the symptoms that occurred. It should also contain precise details of any workaround or resolution that can restore the service and resolve the problem. An incident count will also be useful to determine the frequency with which incidents are likely to recur and influence priorities.

Care should be taken to avoid duplication of records, the same problem described in two or more ways as separate records. To avoid repetition, the Problem Manager should be the only person able to enter a new record. Other support groups should be permitted, indeed encouraged, to propose new records. However, these should be examined by the Problem Manager before entry to the KEDB.


58

Problem Management Concepts

• Reactive Problem Management, which is generally implemented as part of Service Operation

• Proactive Problem Management, which is initiated in Service Operation but generally driven as part of Continual Service Improvement

• Known Error Database allows storage of previous knowledge of incidents and problems, and how they were overcome, to allow quicker diagnosis and resolution if they recur


• • •••



The KEDB should be used during the incident and problem diagnosis phases to speed up the resolution process. New records should be added as quickly as possible when a new problem has been identified and diagnosed. All support staff should be fully trained and know the value that the KEDB can offer and the way it should be used. They should be able to readily retrieve and use data.


• • • ••



Workaround

In some cases it might be possible to find a workaround to the incidents caused by the problem.

An example of a workaround would be:

A manual amendment is made to an input file to permit a program to complete the run successfully. In addition, it ensures the billing process completes satisfactorily. However, it is important that work on a permanent resolution continues when justified. In this example, the reason why the file became corrupted in the first place must be found and corrected to prevent this situation from happening again.


59

Workaround

• A workaround is a temporary way of overcoming a difficulty

• When a workaround is found, it is therefore important that the:

Problem record remains open

Details of the workaround are documented within the problem record


• • •••



Known Error Data Base (KEDB)

A Known Error is a problem for which a cause has been identified.

A Known Error Record in the Known Error Database ensures quicker diagnosis. In addition, the creation of a Problem Model for handling such problems in the future can be helpful. Problem Models are similar in concept to the idea of Incident Models, but they can be applied to problems and incidents.

As soon as the diagnosis is complete, a known error record must be raised and placed in the Known Error Database. An immediate record is particularly important when a workaround has not been found. Even a temporary workaround, one that is not yet a permanent resolution, has value in restoring service. When a record exists, future similar incidents or problems can be identified and the service restored more quickly.

In some cases you might want to create a known error record even earlier in the overall process. Even if just for informational purposes, the diagnosis might not be complete, or a workaround implemented, it can still be useful.

It is not advisable to try to set a specific procedural point exactly when a known error record must be raised. The point should be set as soon as it becomes useful.

The incident count can be used to determine the frequency with which incidents are likely to recur and, therefore, influence priorities.


60

Known Error Data Base (KEDB)

• The purpose of a Known Error Data Base (KEDB) is to

Store previous knowledge of incidents and problems Record how incidents and problems were overcome

Diagnose and resolve recurring incidents or problems quicker

• The known error record should hold precise details of the following items:

The fault and the symptoms that occurred Any workaround or resolution action that can be taken to restore the service or resolve the problem

• An incident count is also useful


• • • ••



Reactive versus Proactive Problem Management

Problem Management consists of two major processes:

• Reactive Problem Management, which is generally performed as part of Service Operation

• Proactive Problem Management, which is initiated in Service Operation, but generally operates as part of Continual Service Improvement

Notice how the Reactive side of the illustration tends to be solving current problems. Toward the right on the continuum, the Proactive approach to problem management has more management and strategies to avoid problems.


• • •••



Problem Management Process

This chart shows the Problem Management process flow. Though there can be variations depending on the problems, most problems will be managed through a similar flow process.


• • • ••



Problem Management Objectives


63

Problem Management Objectives

• Prevent problems and resulting incidents from happening

• Eliminate recurring incidents

• Minimize the impact of incidents that cannot be prevented


• • •••



Problem Management Benefits

Some other benefits of Problem Management are:

• Higher availability of IT services

• Higher productivity of business and IT staff

• Reduced expenditure on workarounds or fixes that do not work

• Reduction in cost of effort in fire-fighting or resolving repeat incidents


64

Problem Management Benefits

• Problem Management works with Incident Management and Change Management to ensure that IT service availability and quality are increased.

• When incidents are resolved, information about the resolution is recorded.


• • • ••



Problem Management Activities

The activities of the Problem Management process are:

• Problem Detection: There are frequently a variety of ways to detect problems. Frequent and regular analysis of problem data must be performed to identify any trends.

• Problem Logging: Regardless of the detection method, all the relevant details of the problem must be recorded so that a full historic record exists. This must be date and time stamped to allow suitable control and escalation.

• Problem Categorization: Problems must be categorized in the same way as incidents

• Problem Prioritization: Problems must be prioritized in the same way as incidents, but the frequency and impact of related incidents must also be taken into account

• Problem Investigation and Diagnosis: An investigation should be conducted to try to diagnose the root cause of the problem

• Workaround Identification: In some cases it might be possible to find a workaround to the incidents caused by the problem


65

Problem Management Activities

• Problem Detection

• Problem Logging

• Problem Categorization

• Problem Prioritization

• Problem Investigation and Diagnosis

• Workaround Identification

• Known Error Record Introduction

• Problem Resolution

• Problem Closure

• Major Problem Review

• Development Environment Error Detection and Logging


• • •••



• Known Error Record Introduction: As Known Error Record must be introduced and placed in the Known Error Database so that if further incidents or problems arise, they can be easily identified and corrected

• Problem Resolution: Ideally, as soon as a solution has been found, it should be applied to resolve the problem

• Problem Closure: When any change has been completed and reviewed, and the resolution has been applied, the Problem Record should be formally closed

• Major Problem Review: After every major problem, while memories are still fresh, a review should be conducted to learn any lessons for the future

• Development Environment Error Detection and Logging: When something is released into the production environment that includes known deficiencies, they should be logged as Known Errors in the KEDB


• • • ••



Problem Management Interfaces

Problem Management interfaces with the following groups:

• Change Management: Problem Management ensures that all resolutions or workarounds that require a change to a CI are submitted through Change Management through an RFC. Change Management will monitor the progress of these changes and keep Problem Management advised. Problem Management is also involved in rectifying the situation caused by failed changes.

• Configuration Management: Problem Management uses the CMS to identify faulty CIs and also to determine the impact of problems and resolutions. The CMS can also be used to form the basis for the KEDB and hold or integrate with the problem records.

• Release and Deployment Management: This area is responsible for implementing problem fixes out into the live, or production, environment. It also assists in ensuring that the associated known errors are transferred from the development Known Error Database into the live, or active, Known Error Database. Problem Management will assist in resolving problems caused by faults during the release process.

• Availability Management: This area is involved with determining how to reduce downtime and increase uptime. As such it has a close relationship with Problem Management, especially the proactive areas. Much of the management


66

Problem Management Interfaces



• Release and Deployment Management


• Capacity Management: Some problems require investigation by Capacity Management teams and techniques, for example, performance issues. It also assists in assessing proactive measures. Problem Management provides management information relative to the quality of decisions made during the Capacity Planning process

• IT Service Continuity




• • •••



information available in Problem Management will be communicated to Availability Management.

• Capacity Management: Some problems will require investigation by Capacity Management teams and techniques, such as performance issues. Capacity Management will also assist in assessing proactive measures. Problem Management provides management information relative to the quality of decisions made during the Capacity Planning process.

• IT Service Continuity: Problem Management acts as an entry point into IT Service Continuity Management. It occurs when a significant problem is not resolved before it starts to have a major impact on the business.

• Service Level Management: The occurrence of incidents and problems affects the level of service delivery measured by Service Level Management. Problem Management contributes to improvements in service levels, and their management information is used as the basis of some of the SLA review components. Service Level Management also provides parameters within which Problem Management works. Parameters can include impact information and the effect on services of proposed resolutions and proactive measures.

• Financial Management: This area assists in assessing the impact of proposed resolutions or workarounds, and pain value analysis. Problem Management provides management information about the cost of resolving and preventing problems. This information is used as input into the budgeting and accounting systems and Total Cost of Ownership calculations.


• • • ••



Problem Management KPIs


67

Problem Management KPIs

• The total number of problems recorded in the period

• The percentage of problems resolved within SLA targets

• The percentage of problems not resolved within SLA targets

• The number and percentage of problems that exceeded their targetresolution times

• The backlog of outstanding problems and the trend

• The average cost of handling a problem

• The number of major problems

• The percentage of Major Problem Reviews successfully performed

• The number of Known Errors added to the KEDB

• The percentage accuracy of the KEDB (from audits of the database)


• • •••



Problem Management Critical Success Factors


68

Problem Management Critical Success Factors

• Linking Incident and Problem Management tools

• Relating Incident and Problem Records

• Ensuring an effective working relationship between all the staff lines

• Making sure that business impact is well understood by all staffworking on problem resolution

• Using all Knowledge and Configuration Management resources available

• Ongoing training of technical staff in technical aspects of their job

• Ongoing training of technical staff in business implications of the services they support and the processes they use


• • • ••



Problem Manager

This role will coordinate all problem management activities and will have specific responsibility for the following duties:

• Works with all problem resolution groups to ensure swift resolution of problems within SLA targets.

• Owns the Known Error Database. Acts as the gatekeeper for the inclusion of all Known Errors and management of search algorithms.

• Formally closes all problem records.

• Works with suppliers and contractors to ensure that external vendors fulfill their contractual obligations to resolve problems.

• Manages and documents all follow up activities relating to major problem reviews.


69

Problem Manager

• Smaller organizations might not be able to justify a full-time employee for this role.

• It can be combined with other roles in such cases.

• The role of Problem Management must not be left only to technical staff.

• A single point of coordination and an owner of the Problem Management process is essential.


• • •••

Unit 5: Service OperationProcess of Access Management


Lesson 6: Process of Access Management


Lesson 6: Process of Access Management


• • • ••



Access Management

The Access Management process and the related policies are likely to be defined and maintained by Information Security Management. It is completed by the various Service Operation functions.


71

Access Management

• Access Management is the process of controlling which users can and cannot use a service

• Some organizations refer to it as Rights Management or Identity Management

• Access Management is the process that helps users use the services that are documented in the Service Catalog.


• • •••



Access Management Concepts

Access: The level and extent of a service’s operation or data that a user is entitled to use.

Identity: The information about a user that distinguishes that person as a unique individual and which verifies their status within the organization.

Rights or privileges: The actual settings whereby a user is provided access to a service or group of services. Typical rights, or levels of access, include read, write, execute, change, delete.

Services or service groups: It is not effective to provide access to each service for each user separately. It is more efficient to grant each user, or group of users, access to a set of services at the same time.

Directory Services: A specific type of tool that is used to manage access and rights.


72

Access Management Concepts

• Access

• Identity

• Rights or privileges

• Services or service groups

• Directory Services


• • • ••



Access Management Goals


73

Access Management Goals

• Grant the right to users to be able to use a service or group of services.

• Execute policies and actions defined in Security and Availability Management.

• Help the organization to manage the confidentiality, availability and integrity of the organization’s data and intellectual property.

• Provide a user with access to a service

• Ensure that the service is available at the agreed upon times.


• • •••



Access Management Benefits


74

Access Management Benefits

• Leads to more effective control of confidentiality of information

• Gives employees the level of access necessary to complete their jobs

• Protects against unskilled users making errors in data entry or in the use of a critical service

• Gives the ability to audit service use and trace the abuse

• Grants the ability to revoke access rights when needed

• Enables organization to comply with regulations (for example: SOX, HIPAA, COBIT)


• • • ••



Access Management Activities

The process of Access Management includes the following activities:

Requesting Access: Access (or restriction) can be requested using one of any number of mechanisms, including:

• A standard request generated by the Human Resource system

• A Request for Change

• A Service Request submitted through the Request Fulfillment system

• The execution of a pre-authorized script or option

Verifying Access: Access Management needs to verify every request for access to an IT service from two perspectives:

• That the user requesting access is who they say they are

• That they have a legitimate requirement for that service

Providing Rights: Access Management does make IT service access decisions, but executes the policies and regulations defined during Service Strategy and Service Design


75

Access Management Activities

• Requesting Access

• Verifying Access

• Providing Rights

• Monitoring Identity Status

• Removing or Restricting Rights


• • •••



Monitoring Identity Status: As users work in the organization, their roles change and so also do their needs to access services. Examples of changes include:

• Job changes

• Promotions or demotions

• Transfers

• Resignation or death

• Retirement

• Disciplinary action

• Dismissals

Removing or Restricting Rights: Access Management will execute the decisions and policies made during Service Strategy and Design and also decisions made by managers in the organization


• • • ••



Access Management Interfaces

Access Management is triggered by a request for a user or users to access a service or group of services. This could originate from any of the following:

• An RFC

• A Service Request

• A request from the appropriate Human Resources Management personnel

• A request from the manager of a department

Access Management should be linked to the Human Resource processes to verify the identity of the users. In addition, this interface can ensure that they are entitled to the services being requested.

Information Security Management is a key driver for Access Management as it will provide the security and data protection policies and tools needed to execute Access Management.

Change Management plays an important role as the means to control the actual requests for access. This is because any request for access to a service is a change, although it is usually processed as a Standard Change or Service Request. SLM maintains the agreements for access to each service including:

• The criteria for who is entitled to access each service


76

Access Management Interfaces

• Human Resource

• Information Security Management




• • •••



• The cost of the access

• The level of access that will be will be granted to different types of user

There is also a strong relationship between Access Management and Configuration Management. The CMS can be used for data storage and interrogated to determine current access details.


• • • ••



Access Management KPIs


77

Access Management KPIs

• Number of requests for access

• Instances of access granted, by service, user, and department

• Instances of access granted by department or individual granting rights

• Number of incidents requiring a reset of access rights

• Number of incidents caused by incorrect access settings


• • •••



Access Management Critical Success Factors


78

Access Management Critical Success Factors

• The ability to verify the identity of a user

• The ability to verify the identity of the approving person or body

• The ability to verify that a user qualifies for access to a specific service

• The ability to link multiple access rights to an individual user

• The ability to determine the status of the user at any time

• The ability to manage changes to a user’s access requirements

• The ability to restrict access rights to unauthorized users

• The use of a database of all users and the rights that they have been granted


• • • ••



Access Management Roles


79

Access Management Roles

• Since Access Management is an execution of Security and Availability Management, these two areas will be responsible for defining the appropriate roles.

• It is unusual for an organization to appoint an Access Manager.

• It is important that there is a single Access Management process and a single set of policies related to managing rights and access.

• This process and the related policies are likely to be defined and maintained by Information Security Management. They will probably be executed by the various Service Operation functions.


• • •••

Unit 5: Service OperationThe Service Desk Function


Lesson 7: The Service Desk Function


Lesson 7: The Service Desk Function


• • • ••



Service Desk

A Service Desk is a functional unit made up of a dedicated number of staff responsible for dealing with a variety of service events. These events are often made through telephone calls, Web interface, or automatically reported infrastructure events. The Service Desk is a vitally important part of the IT Department of an organization. The Service Desk should be the single point of contact for IT users on a day-to-day basis. The Service Desk will handle all incidents and service requests, typically using specialist software tools to log and manage all such events.

A good Service Desk can often compensate for deficiencies elsewhere in the IT organization. However, a poor Service Desk, or the lack of one, can give a poor impression of an IT organization.

Providing the correct caliber of staff for the Service Desk is important. To improve staff retention, IT managers should do their best to make the desk an attractive place to work.

The exact nature, type, size, and location of a Service Desk will vary, depending upon the many factors, including those listed:

• Type of business

• Number of users

• Geography


81

Service Desk

• A Service Desk deals with a variety of service events, often made through telephone calls, Web interface, or automatically reported infrastructure events

• The nature, type, size, and location of a Service Desk will vary, depending upon the type of business, number of users, geography, complexity of calls, scope of services, and many other factors


• • •••



• Complexity of calls

• Scope of services


• • • ••



Service Desk Responsibilities

The primary aim of the Service Desk is to restore normal service to the users as quickly as possible. In this context, restore normal service is meant in the widest possible sense. For example, restoration can involve fixing a technical fault, fulfilling a service request, or answering a query. The phrase means to do anything that is needed to ensure the users to satisfactorily return to work.

Specific responsibilities will include:

• Logging all relevant incident and service request details, allocating categorization and prioritization codes

• Providing first-line investigation and diagnosis

• Resolving all the incidents and service requests that they can

• Escalating incidents and service requests that they cannot resolve within the agreed-upon time scales

• Keeping users informed of progress

• Closing all resolved incidents, requests, and other calls

• Conducting customer and user satisfaction callbacks and surveys as agreed upon

• Communicating with users and keeping them informed of incident progress, notifying them of impending changes or agreed-upon outages


82

Service Desk Responsibilities

• Logging all relevant incidents and service requests

• Assigning categorization and prioritization codes

• Providing first-line investigation and diagnosis

• Escalating incidents and service requests that they cannot resolve within agreed upon time scales

• Keeping users informed of progress


• • •••



The Service Desk Function

The main function of the Service Desk is to restore the normal service to the users as quickly as possible. Restoring to normal service can include repairing a technical fault, or fulfilling a service request, or answering a query. It involves whatever is needed to help the users to return to an agreed-upon level of work.


83

The Service Desk Function


• • • ••



Service Desk Organizational Structures

Local Service Desk

A Local Service Desk is where a desk is collocated within, or physically close to the user community it serves. Physical proximity often aids communication and gives a clearly visible presence, which some users like. However, Local Service Desks can often be inefficient and expensive. Staff wait to deal with incidents, and the volume and arrival rate of calls might not justify the staff dedicated to this function.

Centralized Service Desk

It is possible to reduce the number of Local Service Desks by merging them into a single location or into a smaller number of locations. This merging is done by drawing the staff into one or more centralized Service Desk structures. This practice can be more efficient and cost effective:

• Fewer overall staff members deal with a higher volume of calls.

• Staff can develop higher skill levels. More frequent occurrence of events provides greater familiarization with their resolution.


84


• Local Service Desk

• Centralized Service Desk

• Virtual Service Desk

• Follow-the-Sun Service Desk


• • •••



It might still be necessary to maintain some form of local presence to handle physical support requirements. However, such staff can be managed and deployed from the central desk.

Virtual Service Desk

Often, personnel might be located in a number of geographical or structural locations. However, it is possible in these situations to give the impression of a single, centralized Service Desk. Technology, particularly the Internet, and corporate support tools can help build this illusion. These technologies and tools permit the following practices to meet user demand:

• Telecommuting from home

• Secondary support group

• Off-shoring

• Outsourcing

• Any combination of the previous items.

Note: Safeguards are needed in all of these circumstances to ensure consistency and uniformity in service quality and cultural terms.

Follow-the-Sun Service Desk

Some global or international organizations might want to combine two or more of their geographically dispersed service desks to provide a 24-hour follow-the-sun service desk. For example, a Service Desk in the Asia-Pacific region can handle calls during standard office hours. At the end of this period, they can transfer responsibility for any open incidents to a European-based desk. That desk handles these calls and their own incidents during the European business day. Then the European desk transfers its open incidents to a U.S.-based desk, which in turn transfers responsibility back to the Asia-Pacific desk to complete the cycle.


• • • ••




This image illustrates types of Service Desks and covers Local, Centralized, and Virtual applications of the Service Desk.

Local Service Desk: Service desk is co-located within or physically close to the user community it serves. This location often aids communication and gives a clearly visible presence. Some users like this approach. However, it can often be inefficient and expensive to resource. Staff are tied up waiting to deal with incidents when the volume, and arrival rate of calls might not be justified.

Centralized Service Desk: Service desks are merged into a single location or into a smaller number of locations. This merging is done by drawing the staff into one or more centralized Service Desk structures. This setup can be more efficient and cost-effective. It leads to fewer overall staff to deal with a higher volume of calls. It can also lead to higher skill levels through great familiarization because of more frequent occurrence of events.

Virtual Service Desk: Virtual Service Desk uses technology, particularly the Internet, and the use of corporate support tools. It is possible to give the impression of a single, centralized Service Desk. In fact, the personnel might be spread or located in any number or type of geographical or structural locations.

Local User: A user who is at the same physical location as the Service Desk.

Remote User: This user and the Service Desk are at physically separate locations.


• • •••



Service Desk Staffing

An organization must ensure that the correct number of staff are available at any time to match business demand. Call rates can be volatile. Often in the same day, the arrival rate might go from very high to very low and back again. An organization must decide on the level and range of skills it requires of service desk staff. It must then ensure that these skills are available at the appropriate times. A range of skill options are possible. These options include:

• A call-logging service where staff need only basic technical skills

• A technical service desk including the most technically skilled staff in the organization

All Service Desk staff should be adequately trained before they take calls. IT managers need to recognize the importance of the Service Desk and its staff and give the Service Desk special attention. Any significant loss of staff can be disruptive and lead to inconsistent service. Therefore, efforts should be made to make the Service Desk an attractive place to work.

Many organizations find it useful to appoint or designate a number of Super Users throughout the user community. These Super Users act as liaison points with IT in general and the Service Desk in particular. Super Users can be given some additional training and awareness and used as a conduit for communications flow in both directions. They can filter requests and issues raised by the user community, in some cases even going as far as to raise incidents or requests themselves. This practice can help prevent incident storms, when a


86

Service Desk Staffing

• An organization must ensure that the correct number of staff are available

• Call rates vary at different times and the service desk must be staffed to meet demand

• An organization must decide on the level and range of skills it requires of its service desk staff

• Training and retention are critical factors for a Service Desk

• Super Users act as liaison points with IT in general and the Service Desk in particular


• • • ••



key service or component fails and affects many users. Super Users can also transmit information from the Service Desk outward quickly.


• • •••



Service Desk Metrics

Metrics should be established so that the performance of the Service Desk can be evaluated at regular intervals. Regular evaluation is important to assess the health, maturity, efficiency, and effectiveness of Service Desk operations. In addition, it helps awareness of opportunities to improve Service Desk operations.

Detailed metrics are needed and must be examined over a period of time. These will include the call-handling statistics previously mentioned in telephony, and the following metrics:

• The first-line resolution rate: the percentage of calls resolved at first line, without the need for escalation to other support groups

• Average time to resolve an incident (when resolved at first line)

• Average time to escalate an incident (where first-line resolution is not possible)

• Average Service Desk cost of handling an incident

• Percentage of customer or user updates conducted within target times, as defined in SLA targets

• Average time to review and close a resolved call

• The number of calls broken down by time of day and day of week, combined with average call time, is a critical in determining the number of staff required


87

Service Desk Metrics

• The first-line resolution rate: the percentage of calls resolved at first line, without the need for escalation to other support groups

• Average time to resolve an incident

• Average time to escalate an incident

• Percentage of customer or user updates conducted within target times, as defined in SLA targets

• Average time to review and close a resolved call


• • • ••

Unit 5: Service OperationTechnical Management, Applications Management, and Operations Management Functions


Lesson 8: Technical Management, Applications Management, and Operations Management Functions


Lesson 8: Technical Management, Application Management, and Operations Management Functions


• • •••



Technical Management

Technical Management function 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. These resources will design, build, change, operate, and improve the technology required to deliver and support IT services.

By performing these two roles, Technical Management is able to ensure that the organization has access to the right type and level of human resources to manage technology. Therefore, it is able to meet business objectives. Part of this role is also to ensure a balance between the skill level, utilization, and the cost of these resources. Technical Management has an additional but important role. It is to provide guidance to IT Operations regarding how best to maintain the ongoing operational management of technology.


89

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 Objectives

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


90

Technical Management Objectives

• 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


• • •••



Application Management

In the first role, Application Management is the custodian of technical knowledge and expertise related to managing applications. In this role Application Management, working together with Technical Management, ensures that the knowledge required to design, test, manage, and improve IT services is identified, developed, and refined.

In 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 perform the following functions when developing technology required to deliver and support IT services:

• Design

• Build

• Transition

• Operate

• Improve

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. Therefore, the organization is able to meet business objectives. This function


91

Application Management

• Application Management plays a role in all applications, whether purchased or developed in-house.

• One of the key decisions to which they contribute is the decision of whether to buy an application or build it.

• After that decision is made, Application Management performs a dual role.


• • • ••



starts in Service Strategy, expands in Service Design, is tested in Service Transition, and is refined in Continual Service Improvement.


• • •••



Application Management Objectives

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


92

Application Management Objectives

• To support the business processes of the organization by helping to identify functional and manageability requirements for application software.

• To assist in the design and deployment of those applications and the ongoing support and improvement of those applications.


• • • ••



Operations Management

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, 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.


93

Operations Management

• The Operations Management function implements the ongoing activities and procedures required to manage and maintain the IT infrastructure.

• These activities facilitate the delivery and support IT services at the agreed-upon levels


• • •••



Operations Management Objectives


94

Operations Management Objectives

• 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


• • • ••

Unit 5: Service OperationUnit Scenario



When many organizations think of ITIL, they think of Service Operations. It is typical in the industry that businesses or IT departments start with Services Operations when they begin the ITIL journey or discipline. Creating a single scenario for these functions and management areas is not very helpful. Therefore, several will be created to illustrate the information presented in this unit.

Incident management and event management actions are typically handled by the Service Desk function. Most organizations have Service Desks. However, they can often be confused with help desks. Recognizing the differences between these two areas is simply a matter of maturity of processes and the acceptance of ITIL into the organization.

The Service Desk team is often the single point of focus when a user needs to:

• Generate a service request

• Log an incident

• Gain information

A frequent example is users stating they cannot log in to their e-mail. This Service Request can be an incident, depending on the issue. This situation can become a problem if the incident is not quickly solved or proves to be shown of a greater challenge. Examples are:

• If the user can not log in because a disk is out of space and system is shut down

• If the system was quarantined because of a security breach that is under investigation

Alternatively, perhaps the user is a contractor hired to assist with the installation of the financial system. The user might have called to acquire an e-mail account. The user was then told to request a service. ITIL v3 calls this a Service Offering.

Events that are typically driven through automated system alerts can also be classified as an incident. Examples:

• The security software or spyware sent a red alert to the incident tool set to alert of a concern

• The e-mail database server sent an alert of disk space running out

These alerts are then worked or moved through automation to a team assigned to work the issue. This team must bring service back into the availability mandated by the Service Level Agreement.


• • •••



This unit described problem management. Consider for a moment the examples here and what might bring them into focus or scrutiny by the problem team. Perhaps it is the frequency for which they have occurred. For example, the e-mail system has run out of space before, or the spyware has alerted the system several days before. In these cases, if the problem team was focused on analysis and proactive problem management, they will see frequency as an issue. Perhaps it is time to allocate additional disk space or to change archive settings. Or, perhaps the spyware has located an exposed hacker risk, or is simply not adequate for the current version. These things being investigated through a problem record for research and resolution will move into the Problem Management space.

Service Operations consist of standard roles within organizations such as service desk manager and service desk staff. However, not all organizations have problem managers. Some organizations have size and staff issues. Some are not yet mature in their ITIL adoption to have established true ITIL problem management. As an organization develops and begins the path to Service Operations, it is critical to establish roles and ownership. These roles ensure that the business benefits from the full value of the processes. They will be able to move into the continual service improvement processes, when they have aligned the organization’s roles towards ITIL.


• • • ••



Review Questions

1. The goal of which of the following choices is to deploy releases into production and to ensure effective use of the service in order to deliver value to the customer?





2. Which of the following choices are conflicting balances in Service Operation? Select all that apply.

a.Quality versus Cost of Service

b. Stability versus Responsiveness

c. Reactive versus Proactive

d. IT Services versus Technology Components

3. Which of the following choices deals with any occurrence that has significance for the management of the IT infrastructure or the delivery of IT service?

a.Event Management

b. Problem Management

c. Incident Management

d. Access Management

4. Which of the following roles deals with an unplanned interruption to an IT service, reduction in the quality of an IT service, or failure of a configuration item that has not yet affected service?

a.Event Management





• • •••



5. Which of the following roles deals with the unknown cause of one or more incidents?

a.Event Management




6. Which of the following roles manages the overall desk activities and acts as further escalation point for the supervisors?

a.Problem Manager

b. Incident Manager

c. Service Desk Manager

d. Service Desk Analyst

7. Which of the following roles provides first-level support through taking calls and handling the resulting incidents or service requests?

a.Problem Manager

b. Incident Manager



8. Which of the following roles monitors the effectiveness of Incident Management and making recommendations for improvement?

a.Problem Manager

b. Incident Manager



9. Which of the following roles owns the Known Error Database and acts as the gatekeeper for the inclusion of all Known Errors?

a.Problem Manager

b. Incident Manager



• • • ••




10. Which of the following management functions acts as the custodian of technical knowledge and expertise related to managing the IT Infrastructure?

a.Application Management Function

b. IT Operations Management Function

c. Technical Management Function

d. Service Desk Function

11. Which of the following management functions acts as the custodian of technical knowledge and expertise related to managing applications?





12. Which of the following management functions has the role of implementing the ongoing activities and procedures required to manage and maintain the IT infrastructure?






• • •••




• • • ••



Review Answers

1. The goal of which of the following choices is to deploy releases into production and to ensure effective use of the service in order to deliver value to the customer?


2. Which of the following are conflicting balances in Service Operation? Select all that apply.

a. Quality versus Cost of Service

b. Stability versus Responsiveness

c. Reactive versus Proactive

d. IT Services versus Technology Components

3. Which of the following choices deals with any occurrence that has significance for the management of the IT infrastructure or the delivery of IT service?

a. Event Management

4. Which of the following roles deals with an unplanned interruption to an IT service, reduction in the quality of an IT service, or failure of a configuration item that has not yet affected service?


5. Which of the following roles deals with the unknown cause of one or more incidents?


6. Which of the following roles manages the overall desk activities and acts as further escalation point for the supervisors?


7. Which of the following roles provides first-level support through taking calls and handling the resulting incidents or service requests?


8. Which of the following roles monitors the effectiveness of Incident Management and making recommendations for improvement?

b. Incident Manager

9. Which of the following roles owns the Known Error Database and acts as the gatekeeper for the inclusion of all Known Errors?


• • •••



a. Problem Manager

10. Which of the following management functions acts as the custodian of technical knowledge and expertise related to managing the IT Infrastructure?

a. Technical Management Function

11. Which of the following management functions acts as the custodian of technical knowledge and expertise related to managing applications?

a. Application Management Function

12. Which of the following management functions has the role of implementing the ongoing activities and procedures required to manage and maintain the IT infrastructure?



• • • ••



Summary


96

Summary

You should now be able to:Explain the key principles and concepts related to Service Operation Discuss Service Operation processes and associated activities

Describe the Service Operation roles

• • • ••

6-1

Unit 6: Continual Service Improvement




• • • ••



Introduction

In this unit, you will learn about Continual Service Improvement.

Objectives


2

Objectives

Upon completion of this unit, you will be able to:Explain the key principles and concepts related to Continual Service Improvement Discuss Continual Service Improvement processes and associated activities

Describe the Continual Service Improvement roles


• • •••

Unit 6: Continual Service ImprovementContinual Service Improvement Overview


Lesson 1: Continual Service Improvement Overview


Lesson 1: Continual Service Improvement Overview


• • • ••



Continual Service Improvement

The dominant pattern in the lifecycle is the sequential progress. This progress goes from Service Strategy through Service Design, Service Transition, Service Operation and back to Service Strategy through CSI. However, that is not the only pattern of action. Every element of the lifecycle provides points for feedback and control, which are channeled through CSI.


4

Continual Service Improvement (CSI) provides feedback and control between the functions and processes within and across the elements of the Service Lifecycle

Continual Service Improvement


• • •••



Continual Service Improvement (CSI)


5

Continual Service Improvement (CSI)

• Continual Service Improvement aligns and realigns 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, efficient, and cost-effective


• • • ••



CSI Objectives


6

Continual Service Improvement Objectives

• Review, analyze, and make recommendations on improvement opportunities in each lifecycle phase: Service Strategy, ServiceDesign, Service Transition, and Service Operation

• Review and analyze Service Level Achievement results

• Identify and implement individual activities to improve IT Service Quality and improve efficiency and effectiveness of enabling the IT Service Management (ITSM) processes

• Improve cost effectiveness of delivering IT services without sacrificing customer satisfaction

• Ensure applicable quality management methods are used to supportcontinual improvement activities


• • •••



Benefits of Continual Service Improvement


7

Benefits of Continual Service Improvement

• Business and Customer Benefits

• Financial Benefits

• IT Organization Internal Benefits


• • • ••



Business and Customer Benefits


8

Benefits of CSI: Business and Customer

• 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


9

Benefits of CSI: Financial

• 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 utilization


• • • ••



IT Organization Benefits


10

Benefits of CSI: IT Organization

• Improved metrics and management reporting

• Alignment of cost structure with business needs

• Defined roles and responsibilities


• • •••



CSI Key Terms

Goals and Objectives: the inputs and outputs of a process are identified

Baselines: the current performance of the process is recorded as a starting point or baseline level

Key Performance Indicators (KPIs): set to measure against and determine the quality of the service

Metrics: measurements are taken and compared to the determined KPIs

Governance: External and internal requirements for services which help shape goals and objectives


11

CSI Key Terms

• Goals and Objectives

• Baselines

• Key Performance Indicators (KPIs)

• Metrics

• Governance


• • • ••



Metrics and Measurement

It is important to remember that there are three types of metrics that an organization will need to collect to support CSI activities as well as other process activities. The types of metrics are:

• Technology metrics: These metrics are often associated with component and application based metrics such as performance and availability.

• Process metrics: These metrics are captured in the form of CSFs, KPIs, and activity metrics for the service management processes. These metrics can help determine the overall health of a process. Four key questions that KPIs can help answer are around quality, performance, value, and compliance of following the process. CSI would use these metrics as input in identifying improvement opportunities for each process.

• Service metrics: These metrics are the results of the end-to-end service. Component metrics are used to compute the service metrics.


12

Metrics and Measurement

• Metrics are a system of parameters or ways of quantitative assessment of a process that is to be measured, along with the processes to carry out such measurement.

• Metrics define what is to be measured.

• Three types:Technology MetricsProcess Metrics

Service Metrics


• • •••



CSI Principles

The only way to focus on these principles is to ensure that improvement opportunities are identified throughout the entire service lifecycle.


13

CSI Principles

For all services and the underlying ITSM processes, service improvement must focus on:

• Increasing the efficiency

• Maximizing the effectiveness

• Optimizing the cost


• • • ••



Continual Service Improvement Model

The primary purpose of CSI is to continually align and realign IT services to the changing business needs. This alignment is done by identifying and implementing improvements to IT services that support business processes. These improvement activities support the lifecycle approach through Service Strategy, Service Design, Service Transition and Service Operation. In effect, CSI searches for ways to improve process effectiveness, efficiency, and cost effectiveness.


14

Continual Service Improvement Model


• • •••



The Deming Cycle

The goal of CSI in using the Deming Cycle is steady, ongoing improvement.


15

The Deming Cycle

W. Edwards Deming is best known for his management philosophy leading to:

Higher qualityIncreased productivityMore competitive position

The four key stages of the Deming Cycle or Circle are:PlanDo

CheckAct


• • • ••



The Deming Cycle and CSI

At implementation, all four stages of the Deming Cycle are used. With ongoing improvement, CSI draws on the check and act stages to monitor, measure, review and implement initiatives.


16

The Deming Cycle and CSI

The Deming Cycle is critical at two points in CSI:

• Implementation of CSIs

• Application of CSI to services and service management processes


• • •••



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.


• • • ••



CSI: Governance

Enterprise governance describes a framework that covers both the corporate governance and the business management aspects of the organization. Enterprise governance also considers the whole picture to ensure that strategic goals are aligned and good management is achieved.

The most recent and highly visible example of a renewed emphasis on corporate governance is the Sarbanes-Oxley Act (SOX) of 2002 in the United States. Created in the aftermath of fraudulent behavior by corporate giants, SOX includes the following provisions:

• Requires corporations to engage in corporate fairness

• Mandates complete transparency of transactions

• Holds executives accountable for any material deficiencies

IT governance ensures that the IT of an organization sustains and extends the strategies and objectives of that organization.

IT departments and organizations must now comply with new rules and legislation and continually demonstrate their compliance through successful independent audits by external organizations.


18

Continual Service Improvement: Governance

• Enterprise Governance describes a framework that covers:Corporate governanceBusiness management

• Corporate governance is about promoting:Corporate fairnessTransparencyAccountability

• IT governance consists of:LeadershipOrganizational structuresProcesses


• • •••



Technology Considerations for CSI

Tools that support CSI activities include:

• IT service management suites

• Systems and network management tools

• Event management tools

• Automated incident and problem resolution tools

• Automated incident and problem resolution tools

• Service Request and fulfillment tools

• Performance management tools

• Application and service performance monitoring tools

• Statistical analysis tools

• Version control Software

• Configuration Management software

• Test management software


19

Technology Considerations for CSI

• CSI activities require software tools.

• These tools:Support the monitoring and reporting on IT services and ITSM processes. Will be used for data gathering, monitoring, analysis, and reporting for services.

Assist in determining the efficiency and effectiveness of the IT Service Management processes.


• • • ••



• Security Management tools

• Project and portfolio management tools

• Financial Management tools

• Business intelligence and reporting tools


• • •••

Unit 6: Continual Service ImprovementThe 7-Step Improvement Process


Lesson 2: The 7-Step Improvement Process


Lesson 2: The 7-Step Improvement Process


• • • ••



The 7-Step Improvement Process Activities

The 7-Step Improvement Process for Continual Service Improvement ensures that you identify what you actually measure and where you find that information. The 7-Step Improvement Process consists of the following steps:

1. Define what you should measure. This step is extremely important, but it is often skipped. Service Strategy and Service Design should have defined this already. CSI looks at this again, from the perspective of where things stand now. This helps to define the ideal condition for both the Business and IT.

2. Define what you can measure. CSI performs a gap analysis using the identified and implemented service level requirements and IT capabilities and the available budgets to pinpoint areas for improvement. In addition, the question of how to achieve these improvements is answered. If customers and IT do not define achievable measurement and reporting requirements, it is highly unlikely that the customer will be satisfied.

3. Gather the data. To evaluate the success or failure of the goals and objectives, data is gathered (typically through Service Operations). Data gathering includes answering the questions: Who? What? When? Can the integrity of the data be trusted?

4. Process the data. In this step, time frames are coordinated, unaligned data is rationalized and made


21

The 7-Step Improvement Process Activities

1. Define what you should measure

2. Define what you can measure 3. Gather the data

4. Process the data 5. Analyze the data

6. Present and use the information for assessment, summary, and action plans

7. Implement corrective action


• • •••



consistent, and gaps in data are identified. The goal is to sort and compare data from many sources. After the data is rationalized, analysis can begin. This step includes answering questions about frequency, format, system, and accuracy.

5. Analyze the data. In this step, the data is analyzed. Service gaps, trends, and impact on business is identified. Questions that are answered in this step relate to data relations, trends, plans, targets, and corrective action.

6. Present and use the information for assessment, summary, and action plans. In this step, the results of the improvement efforts are presented to all the stakeholders. In addition, suggestions for future endeavors are suggested.

7. Implement corrective action. The corrective actions that need to be taken to improve the service are communicated and explained to the organization. Following this step, the organization establishes a new baseline and the cycle begins anew.


• • • ••



7-Step Improvement Process Interfaces

In order to support improvement activities it is important to have CSI integrated within each lifecycle stage including the underlying processes residing in each lifecycle phase. Some of the integration of the process with the lifecycle stages and Service Management processes include:

Service Strategy: Responsible for monitoring the progress of strategies, standards, policies and architectural decisions that have been made and implemented.

Service Design: Monitors and gathers data associated with creating and modifying (design efforts) of services and service management processes.

Service Transition: Develops the monitoring procedures and criteria to be used during and after implementation.

Service Operation: Responsible for the actual monitoring of services in the production environment. Service Operation plays a large part in the processing activity. It provides input into what can be measured and processed into logical groupings as well as doing the actual processing of the data.

Service Level Management: SLM plays a key role in the data gathering activity as SLM is responsible for not only defining business requirements but also the capabilities of IT to achieve them.


22

7-Step Improvement Process Interfaces

• Service Strategy

• Service Design• Service Transition

• Service Operation• Service Level

• Availability and Capacity • Incident Management and Service Desk

• Security Management• Financial Management


• • •••



Availability Management and Capacity Management: Provide significant input into existing monitoring and data collection capabilities, tool requirements to meet new data collection requirements and ensuring the Availability and Capacity Plans are updated to reflect new or modified monitoring and data collection requirements.

Incident Management and Service Desk: Incident Management can define monitoring requirements to support event and incident detection. It does this through automation. It also has the ability to automatically open incident tickets and automatically escalate incident tickets. As a single point of contact it is important for the Service Desk to monitor telephony items

Security Management: Defines security monitoring and data collection requirements. Monitors, verifies, and tracks the levels of security according to the organizational security policies and guidelines. Assists in determining effects of security measures on the data monitoring and collection.

Financial Management: Financial Management provides the necessary templates to assist CSI to create the budget and expenditure reports for the various improvement initiatives as well as providing the means to compute the ROI of the improvements.

The 7-Step Improvement Process also interfaces with these and other processes in monitoring and data collection, measuring the data, analyzing the data, presenting and using the information, and implementing corrective action.


• • • ••



CSI Critical Success Factors and KPIs

It is recommended that in the early stages of a CSI program only two to three KPIs for each CSF are defined, monitored and reported. As the maturity of a service and service management processes increase, additional KPIs can be added. Based on what is important to the business and IT management, the KPIs can change over a period of time. Also, keep in mind that as service management processes are implemented this will often change the KPIs of other processes.

Contributions from the key roles identified in Service Design, Service Transition and Service Operation, each of which has very specific goals to meet. Ultimately, the quality of the service will be determined by how well each role meets its goals, and by how well those sometimes conflicting goals are managed along the way. That makes it crucial that organizations find some way of measuring performance – by applying a set of metrics to each goal.


23

7-Step Improvement Process Critical Performance Factors and KPIs• Opinions on number of CSFs and KPIs to define are

varied.

• Some recommended no more than two to three KPIsdefined per CSF at any given time and that a service or process has no more that two to three CSFs associated with it at any given time.

• Others recommend four to five.

• When considering the number of services, the upper limit can be overwhelming.


• • •••



7-Step Improvement Process Roles

Step 1: Define what you should measure: Roles for this step include individuals involved with decision making from IT and the business. These individuals understand the internal and external factors that influence the measured elements to support the business, governance, and regulatory legislation. Titles for these roles might be: service manager, service owner, service level manager, CSI manager, process owner, process managers, customers, business and IT analysts, and senior IT managers.

Step 2: Define what you can measure: Roles for this step internal and external providers who understand the capabilities of the measuring processes, procedures, tools and staff. Titles for these roles might be: service manager, service owner, process owner, process managers, internal and external providers.

Step 3: Gathering the data: Roles for this step include individuals involved in day-to-day process activities within the Service Transition and Service Operation lifecycle phases. Titles for these roles might be: service desk staff, technical management staff, application management staff, IT security staff.

Step 4: Processing the data: Roles for this step include individuals involved in day-to-day process activities within the Service Transition and Service Operation lifecycle phases. Titles for these roles might be: service desk staff, technical management staff, application management staff, IT security staff.


24

7-Step Improvement Process Roles

• Different roles and titles for each step


• • • ••



Step 5: Analyzing the data: Roles for this step include internal and external providers who understand the capabilities of the measuring processes, procedures, tools, and staff. Titles for these roles might be: service owner, process owner, process managers, business/IT analysts, senior IT analysts, supervisors, and team leaders.

Step 6: Presenting and using the information: Roles for this step include internal and external providers who understand the capabilities of the service and the underpinning processes and possess good communication skills. Key personnel involved with decision making from both IT and the business. Titles for these roles might be: CSI manager, service owner, service manager, service level manager, process owner, process managers, customers, business and IT analysts, senior IT managers, internal and external providers.

Step 7: Implementing corrective action: Roles for this step include internal and external service providers. Titles for these roles might include: CSI manager, service owner, service manager, service level manager, process owner, process managers, customers, business and IT analysts, senior IT managers, internal and external providers.


• • •••

Unit 6: Continual Service ImprovementProcess of Service Reporting


Lesson 3: Process of Service Reporting


Lesson 3: Process of Service Reporting


• • • ••



Aspects of Service Reporting

It is important to the business to see a historical representation of the past period’s performance. However, it is mostly concerned with the historical events that continue to be a threat going forward. It is also concerned with how IT intends to safeguard against such threats.

IT should build an approach to reporting that leads to action. That is, reporting should focus on:

• This is what happened.

• This is what we did.

• This is how we will ensure it does not impact you again.

• This is how we are working to improve the delivery of IT services generally.


26

Aspects of Service Reporting

• Identifying the purpose

• Identifying the target audience

• Identifying the use for the report


• • •••



Implementing Reporting


27

Implementing Reporting

• Target audiences and the related business views on the service delivered

• Agree on what to measure and report

• Agree on definitions of all terms and boundaries• Define basis of all calculations

• Define reporting schedules• Provide access to reports and medium to be used

• Schedule meetings to review and discuss reports


• • • ••



Content and Audience Considerations


28

Content and Audience Considerations

• Make clear which policies and rules have been applied for each report

• Translate flat historical data into meaningful business views

• Annotate around the key questions, threats, mitigations and improvements

• Make reporting customizable and automated

• Select medium that is accessible

• Shape reports to meet changing business needs


• • •••



Service Reporting Benefits


29

Service Reporting Benefits

• the targeted recipient having clear and relevant information

• information accessible in a medium chosen by the recipient

• reporting that details the delivery of IT into the customer environment within their boundaries

• information that is not clouded by the data related to the delivery of IT into other areas of the business


• • • ••



Service Reporting Activities

The key to effect Service Reporting is to take the time to define and agree on how reporting will be implemented with the business and Service Design.


30

Service Reporting Activities

• Targeted audiences and the related business views on the service delivered

• Agreement on what to measure and what to report on

• Agreed definitions of all terms and boundaries

• Basis of all calculations

• Reporting schedules

• Access to reports and medium to be used

• Meetings scheduled to review and discuss reports


• • •••



Reporting Analyst

One of the key roles for CSI is that of Reporting Analyst. The Reporting Analyst will often work in concert with the Service Level Management roles. The reporting analyst reviews and analyzes data from components, systems and sub-systems in order to obtain a true end-to-end service achievement. The reporting analyst identifies trends and establishes if the trends are positive or negative. This information is then used in the presenting of the data.

The Reporting Analyst has the following responsibilities:

• Participates in CSI meetings and Service Level Management meetings to ensure the validity of the reporting metrics, notification thresholds, and overall solution

• Consolidates data from multiple sources

• Produces trends and identifies:

– Whether the trends are positive or negative

– What their impact is likely to be

– If the trends are predictable for the future

• Produces reports on service or system performance based on the negotiated OLAs and SLAs and improvement initiatives


31

Reporting Analyst

• Participates in CSI meetings and Service Level Management meetings

• Consolidates data

• Produces trends

• Produces reports on service or system performance


• • • ••

Unit 6: Continual Service ImprovementProcess of Service Measurement


Lesson 4: Process of Service Measurement


Lesson 4: Process of Service Measurement


• • •••



Service Measurement

Service Measurement is the ability to predict and report service performance against the established target of achievements of an end-to-end service.

One of key set of activities of the Continual Service Improvement is to measure, analyze, and report on IT services and ITSM results. Measurements will, of course, produce data. This data should be analyzed over time to produce a trend. The trend will tell a story that can be positive or negative.

Measurements of this kind must have ongoing relevance. Information that was important to know last year might not be pertinent this year.


33

Service Measurement

• Service Measurement is the ability to predict and report service performance against the established target of achievements of an end-to-end service

• Service Measurement requires someone to:Take the individual measurements

Combine individual measurements to provide a view of the true customer experience

• The measuring process must regularly confirm that:The data being collected and collated is still required Measurements are adjusted where necessary


• • • ••



Measurements for CSI

The four basic reasons to monitor and measure lead to three key questions:

1. Why monitor and measure?

2. When can monitoring and measuring of this item be stopped?

3. 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 might 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.


34

Measurements for Continual Service ImprovementMeasurements are performed to:

Validate

DirectJustifyIntervene


• • •••



Baselines

Baselines must be established at each level: strategic goals and objectives, tactical process maturity, operational metrics, and Key Performance Indicators (KPIs).


35

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

• Baselines must be documented, recognized, and accepted throughout the organization


• • • ••



Types of Metrics

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.


36

Types of Metrics

• Technology metrics

• Process metrics

• Service metrics


• • •••



Service Measurement Objective

Service measurement requires someone to take the individual measurements and combine them to provide a view of the true customer experience.

For services most organizations use three basic measurements:

• Availability of the service

• Reliability of the service

• Performance of the service


37

Service Measurement Objective

• For IT to measure and report against an end-to-end service


• • • ••



Service Measurement Activities

Defining what to measure

Effective service measures concentrate on a few vital, meaningful indicators that are economical, quantitative, and usable for the desired results. Some common measurements include:

• Service levels

• Customer satisfaction

• Business impact

• Supplier performance

Setting targets

Targets set by management are quantified objectives to be attained. They express the aims of the service or process at any level and provide the basis for the identification of problems and early progress towards solutions and improvement opportunities.


38

Service Measurement Activities

• Defining what to measure

• Setting targets

• Defining process measurement

• Creating a measurement framework grid

• Using measurement and metrics

• Creating scorecards and reports


• • •••



Defining process measurement

Define what to measure at the process activity level. Some key activity metrics to capture are:

• Number of urgent changes

• Number of failed urgent changes

• Unauthorized changes that failed

Creating a measurement framework grid

Create a framework grid that will lay out the high-level goals. It will also define which KPIs will support the goal and which category the KPI addresses. KPI categories can be classified as the following categories:

• Compliance

• Quality

• Performance

• Value

Using measurement and metrics

• Identify whether the results that are being shown make sense.

• Do not jump to conclusions without analyzing the possible causes for the results.

• Look at measurements as a whole but also analyze trends and provide interpretation of the meaning of the metrics and measures.

Creating scorecards and reports

• Reports and scorecards should be linked to overall strategy and goals. Using a Balanced Scorecard approach is one way to manage this alignment.

• When creating reports it is important to know their purpose and the details that are required.

• Before starting the design of any report it is also important to know the following:

– Who is the target audience of the report?

– How will the report be used?

– Who is responsible for creating the report?


• • • ••



– How will the report be created?

– How frequently is the report to be created?

– What information will be produced, shared, or exchanged?


• • •••

Unit 6: Continual Service ImprovementProcess of Creating a Return on Investment


Lesson 5: Process of Creating a Return on Investment


Lesson 5: Process of Creating a Return on Investment


• • • ••



Return on Investment for CSI

It is important to recognize that an investment in CSI, and realizing its benefits, can vary. They can depend on the customer base, size of IT, and the maturity of the ITIL process implemented. In addition, benefits will cross existing organizational boundaries and true benefits can only be captured in collaboration with the users, customers, and ITIL process owners.

A baseline must be established for all future measurements to be meaningful. Measurements can often reflect a single picture or point in time. However, analyzing these pictures over time will help identify trends. These trends, in turn, help identify areas of improvement. The first measurement is the baseline. It is essential that the same measurements be used consistently to establish trend patterns.

While the initial identification of benefits is an estimate of those likely to be realized by the proposed process improvement initiative, there is also a need to subsequently measure the benefits actually achieved.


40

Return on Investment for CSI

• One of the keys for measuring and reporting is to be able to define improvement opportunities that will create a Return on Investment for the business.

• Most organizations need proof that process improvement will be beneficial for the business in terms of increased productivity and cost.

• Creating a Return on Investment (ROI) must take into consideration the investment cost and the gains to the organization.


• • •••



Return on Investment Activities

The activities associated with the Return on Investment process are creating and ROI statement, establishing the business case, and measuring the beneifits achieved.

Creating an ROI Statement

• Calculating internal resource costs. These costs will be internal resource costs, tool costs, consulting costs, and others.

• Defining what the organization will gain. These returns are often difficult to define.

• Defining the cost of lost productivity. Availability is a good measure to understand the cost of lost productivity, downtown, or of being unable to complete a business transaction. Things to look at in terms of availability include:

– Impact by minutes lost.

– Impact by business transaction.

– Defining the cost to downtime.


41

Creating a Return on Investment Activities

• Creating an ROI statement

• Establishing the business case

• Measuring the benefits achieved


• • • ••



Establishing the Business Case

The Business Case should identify the reasons for starting a service or process improvement initiative. The focus should not only be on ROI but also on the business value that service improvement brings to the organization and its customers. Examples of business value measures are:

• Time to market

• Customer retention

• Inventory carrying cost

• Market share

Measuring the Benefits Achieved

Determine the current or anticipated concern of the organization with respect to IT. Estimate the cost if the status quo were to remain. Estimate the savings that could be realized if the ITSM processes were put in place or improved upon.


• • •••

Unit 6: Continual Service ImprovementContinual Service Improvement Roles


Lesson 6: Continual Service Improvement Roles


Lesson 6: Continual Service Improvement Roles


• • • ••



Service Manager

The key responsibilities of a Service Manager are as follows:

• Provide leadership on the development of business case and product line strategy and architecture, new service deployment and lifecycle management schedules.

• Perform Service Cost Management activities in close partnership with other organizations such as Operations, Engineering, and Finance. Many of these organizations are held to strict internal supplier agreements.

• Manage various and sometimes conflicting objectives to achieve the goals and financial commitments of the organization.

• Create an imaginative organization that encourages high performance and innovative contributions from members within a rapidly changing environment.


43

Service Manager

• Provides leadership on development of business case and product line strategy and architecture, new service deployment, and lifecycle management schedules

• Performs Service Cost Management activities

• Manages various objectives to achieve goals and financial commitments of organization

• Creates an imaginative organization


• • •••



Continual Service Improvement Manager

The key responsibilities of the Continual Service Improvement Manager are as follows:

• Communicates the vision of CSI across the IT organization

• Works with Service Owner to identify and prioritize improvement opportunities

• Works with the Service Level Manager to ensure that monitoring requirements are defined

• Works with the Service Level Manager to identity Service Improvement Programs

• Ensures that monitoring tools are in place to gather data

• Ensures baseline data is captured for comparing with improvement data

• Defines and reports on CSI Critical Success Factors, Key Performance Indicators, and CSI activity metrics

• Identifies other frameworks, models, and standards that will support CSI activities

• Presents recommendations to Senior Management for improvement

• Identifies and delivers process improvements in critical business areas across Manufacturing and relevant divisions


44

Continual Service Improvement Manager

• Works with Service Owner to identify and prioritize improvement opportunities

• Works with Service Level Manager to ensure monitoring requirements are defined

• Works with Service Level Manager to identity Service Improvement Programs

• Ensures that monitoring tools are in place to gather data

• Defines and reports on CSI Critical Success Factors, Key Performance Indicators, and CSI activity metrics


• • • ••

Unit 6: Continual Service ImprovementUnit Scenario



As an organization attempts to adopt ITIL methodology, it begins to align processes, persons, and tools to meet this new model. During this time, it is important to not forget that Continual Improvement is critical to the business. Continual Improvement is crucial even at the design phase of the first step of accepting ITIL. No single business can integrate ITIL methodology overnight. In addition, business and markets change. Such changes cause a service to adapt in order to continue to support the business.

Continual Service Improvement (CSI) enables the organization to review the maturity level of processes. In addition, it measures the level of influence IT and Operations has on the overall business. If the business is focused on selling something, IT can determine how they are:

• Assisting the business to sell better

• Shortening a sales cycle

• Facilitating the ordering process in terms of speed and accuracy

CSI facilitates adjustments to processes for better data gathering at the appropriate steps. In the previous example of the financial system being implemented, CSI should be put in place immediately at point of production. One task will be to review or document how the users are actually using the tool set. Another task will be to see if any gaps of usability were missed during design and testing.

CSI can assist the business to implement processes in a semi-automated fashion. Then the review process can determine where automation truly can assist and improve efficiencies and reduce manual activities. These types of reviews help drive resources to seek ways to reduce cost and focus spending on what will facilitate increased revenue. Returning to the financial system example, after it is put in place, a CSI is set up to review the payables functions. The review might bring out that today a payables resource must enter suppliers manually. Although that was appropriate at the initial stages, business has expanded and additional suppliers and vendors are being added at a very strong pace. Through CSI, it is determined that it is time to automate an interface to the system. This automation will help suppliers to enter their own information through a secured Web site or link. This automation will reduce manual entry and facilitate better control for payment. Then, pay out will not occur too soon or too late. Thus, contract breaches and penalties are avoided.


• • •••



Review Questions

1. Which of the following choices comprise the Deming Model?

a.Plan, Do, Check, Act

b. Plan, Manage, Do, Act

c. Plan, Do, Check, Revise

d. Plan, Do, Check, Evaluate

2. Which of the following choices represent the business value for performing measurements?

a.Validate

b. Direct

c. Justify

d. Intervene

e. All of the Above

3. Which of the following choices are used to establish an initial data point to determine if a service or process needs to be improved?

a.Measurements

b. Baselines

c. Reports

d. KPIs

4. Which type of metrics is often associated with component-based and application based metrics such as performance and availability?

a.Technology

b. Process

c. Service

d. Management


• • • ••



5. Which type of metrics can help answer questions about quality, performance, value, and compliance in following the process?

a.Technology

b. Process

c. Service

d. Management

6. Which type of metrics are the results of the end-to-end service?

a.Technology

b. Process

c. Service

d. Management


• • •••




• • • ••



Review Answers

1. Which of the following choices comprise the Deming Model?

a. Plan, Do, Check, Act

2. Which of the following choices represent the business value for performing measurements?

e. All of the Above

3. Which of the following choices are used to establish an initial data point to determine if a service or process needs to be improved?

b. Baselines

4. Which type of metrics is often associated with component-based and application based metrics such as performance and availability?

a. Technology

5. Which type of metrics can help answer questions about quality, performance, value, and compliance in following the process?

b. Process

6. Which type of metrics are the results of the end-to-end service?

c. Service


• • •••



Summary


46

Summary

You should now be able to:Explain the key principles and concepts related to Continual Service Improvement Discuss Continual Service Improvement processes and associated activities

Describe the Continual Service Improvement roles


• • • ••



• • • ••

A-1

Appendix A: ITIL Glossary

The following pages contain the Glossary of Terms and Definitions V3.1.24, published 30 May 2007.

This glossary can be freely downloaded. See http://www.get-best-practice.co.uk/glossaries.aspx for details of licence terms.

ITIL Glossary © Crown Copyright Office of Government Commerce. Reproduced with the permission of the Controller of HMSO and the Office of Government Commerce.

ITIL ® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office.

A-2 IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••



ITIL V3 Glossary

Acceptance: Formal agreement that an IT Service, Process, Plan, or other Deliverable is complete, accurate, Reliable and meets its specified Requirements. Acceptance is usually preceded by Evaluation or Testing and is often required before proceeding to the next stage of a Project or Process. See Service Acceptance Criteria.

Access Management (Service Operation) The Process responsible for allowing Users to make use of IT Services, data, or other Assets. Access Management helps to protect the Confidentiality, Integrity and Availability of Assets by ensuring that only authorized Users are able to access or modify the Assets. Access Management is sometimes referred to as Rights Management or Identity Management.

Account Manager (Service Strategy) A Role that is very similar to Business Relationship Manager, but includes more commercial aspects. Most commonly used when dealing with External Customers.

Accounting (Service Strategy) The Process responsible for identifying actual Costs of delivering IT Services, comparing these with budgeted costs, and managing variance from the Budget.

Accredited Officially authorized to carry out a Role. For example an Accredited body may be authorized to provide training or to conduct Audits.

Active Monitoring (Service Operation) Monitoring of a Configuration Item or an IT Service that uses automated regular checks to discover the current status. See Passive Monitoring.

Activity A set of actions designed to achieve a particular result. Activities are usually defined as part of Processes or Plans, and are documented in Procedures.

Agreed Service Time (Service Design) A synonym for Service Hours, commonly used in formal calculations of Availability. See Downtime.

Agreement A Document that describes a formal understanding between two or more parties. An Agreement is not legally binding, unless it forms part of a Contract. See Service Level Agreement, Operational Level Agreement.

Alert (Service Operation) A warning that a threshold has been reached, something has changed, or a Failure has occurred. Alerts are often created and managed by System Management tools and are managed by the Event Management Process.

Analytical Modeling (Service Strategy) (Service Design) (Continual Service Improvement) A technique that uses mathematical Models to predict the behavior of a Configuration Item or IT Service. Analytical Models are commonly used in Capacity Management and Availability Management. See Modeling.

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 A-3

• • •••



Application Software that provides Functions that are required by an IT Service. Each Application may be part of more than one IT Service. An Application runs on one or more Servers or Clients. See Application Management, Application Portfolio.

Application Management (Service Design) (Service Operation) The Function responsible for managing Applications throughout their Lifecycle.

Application Portfolio (Service Design) A database or structured Document used to manage Applications throughout their Lifecycle. The Application Portfolio contains key Attributes of all Applications. The Application Portfolio is sometimes implemented as part of the Service Portfolio, or as part of the Configuration Management System.

Application Service Provider (ASP) (Service Design) An External Service Provider that provides IT Services using Applications running at the Service Provider's premises. Users access the Applications by network connections to the Service Provider.

Application Sizing (Service Design) The Activity responsible for understanding the Resource Requirements needed to support a new Application, or a major Change to an existing Application. Application Sizing helps to ensure that the IT Service can meet its agreed Service Level Targets for Capacity and Performance.

Architecture (Service Design) The structure of a System or IT Service, including the Relationships of Components to each other and to the environment they are in. Architecture also includes the Standards and Guidelines which guide the design and evolution of the System.

Assembly (Service Transition) A Configuration Item that is made up from a number of other CIs. For example a Server CI may contain CIs for CPUs, Disks, Memory etc.; an IT Service CI may contain many Hardware, Software and other CIs. See Component CI, Build.

Assessment Inspection and analysis to check whether a Standard or set of Guidelines is being followed, that Records are accurate, or that Efficiency and Effectiveness targets are being met. See Audit.

Asset (Service Strategy) Any Resource or Capability. Assets of a Service Provider include anything that could contribute to the delivery of a Service. Assets can be one of the following types: Management, Organization, Process, Knowledge, People, Information, Applications, Infrastructure, and Financial Capital.

Asset Management (Service Transition) Asset Management is the Process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle. Asset Management is part of an overall Service Asset and Configuration Management Process. See Asset Register.

Asset Register (Service Transition) A list of Assets, which includes their ownership and value. The Asset Register is maintained by Asset Management.


• • • ••



Attribute (Service Transition) A piece of information about a Configuration Item. Examples are name, location, Version number, and Cost. Attributes of CIs are recorded in the Configuration Management Database (CMDB). See Relationship.

Audit Formal inspection and verification to check whether a Standard or set of Guidelines is being followed, that Records are accurate, or that Efficiency and Effectiveness targets are being met. An Audit may be carried out by internal or external groups. See Certification, Assessment.

Authority Matrix Synonym for RACI.

Automatic Call Distribution (ACD) (Service Operation) Use of Information Technology to direct an incoming telephone call to the most appropriate person in the shortest possible time. ACD is sometimes called Automated Call Distribution.

Availability (Service Design) Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance, and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service.

Availability Management (Service Design) The Process responsible for defining, analyzing, Planning, measuring and improving all aspects of the Availability of IT Services. Availability Management is responsible for ensuring that all IT Infrastructure, Processes, Tools, Roles etc are appropriate for the agreed Service Level Targets for Availability.

Availability Management Information System (AMIS) (Service Design) A virtual repository of all Availability Management data, usually stored in multiple physical locations. See Service Knowledge Management System.

Availability Plan (Service Design) A Plan to ensure that existing and future Availability Requirements for IT Services can be provided Cost Effectively.

Back-out Synonym for Remediation.

Backup (Service Design) (Service Operation) Copying data to protect against loss of Integrity or Availability of the original.

Balanced Scorecard (Continual Service Improvement) A management tool developed by Drs. Robert Kaplan (Harvard Business School) and David Norton. A Balanced Scorecard enables a Strategy to be broken down into Key Performance Indicators. Performance against the KPIs is used to demonstrate how well the Strategy is being achieved. A Balanced Scorecard has 4 major areas, each of which has a small number of KPIs. The same 4 areas are considered at different levels of detail throughout the Organization.

Baseline (Continual Service Improvement) A Benchmark used as a reference point. For example: An ITSM Baseline can be used as a starting point to measure the effect of a Service Improvement Plan


• • •••



A Performance Baseline can be used to measure changes in Performance over the lifetime of an IT Service

A Configuration Management Baseline can be used to enable the IT Infrastructure to be restored to a known Configuration if a Change or Release fails

Benchmark (Continual Service Improvement) The recorded state of something at a specific point in time. A Benchmark can be created for a Configuration, a Process, or any other set of data. For example, a benchmark can be used in:

• Continual Service Improvement To establish the current state for managing improvements.

• Capacity Management To document Performance characteristics during normal operations.

• See Benchmarking, Baseline.

Benchmarking (Continual Service Improvement) Comparing a Benchmark with a Baseline or with Best Practice. The term Benchmarking is also used to mean creating a series of Benchmarks over time, and comparing the results to measure progress or improvement.

Best Practice Proven Activities or Processes that have been successfully used by multiple Organizations. ITIL is an example of Best Practice.

Brainstorming (Service Design) A technique that helps a team to generate ideas. Ideas are not reviewed during the Brainstorming session, but at a later stage. Brainstorming is often used by Problem Management to identify possible causes.

British Standards Institution (BSI) The UK National Standards body, responsible for creating and maintaining British Standards. See http://www.bsi-global.com for more information. See ISO.

Budget A list of all the money an Organization. or Business Unit plans to receive, and plans to pay out, over a specified period of time. See Budgeting, Planning.

Budgeting The Activity of predicting and controlling the spending of money. Consists of a periodic negotiation cycle to set future Budgets (usually annual) and the day-to-day monitoring and adjusting of current Budgets.

Build (Service Transition) The Activity of assembling a number of Configuration Items to create part of an IT Service. The term Build is also used to refer to a Release that is authorized for distribution. For example Server Build or laptop Build. See Configuration Baseline.

Build Environment (Service Transition) A controlled Environment where Applications, IT Services and other Builds are assembled prior to being moved into a Test or Live Environment.


• • • ••



Business (Service Strategy) An overall corporate entity or Organization. formed of a number of Business Units. In the context of ITSM, the term Business includes public sector and not-for-profit organizations., as well as companies. An IT Service Provider provides IT Services to a Customer within a Business. The IT Service Provider may be part of the same Business as their Customer (Internal Service Provider), or part of another Business (External Service Provider).

Business Capacity Management (BCM) (Service Design) In the context of ITSM, Business Capacity Management is the Activity responsible for understanding future Business Requirements for use in the Capacity Plan. See Service Capacity Management.

Business Case (Service Strategy) Justification for a significant item of expenditure. Includes information about Costs, benefits, options, issues, Risks, and possible problems. See Cost Benefit Analysis.

Business Continuity Management (BCM) (Service Design) The Business Process responsible for managing Risks that could seriously impact the Business. BCM safeguards the interests of key stakeholders, reputation, brand and value creating activities. The BCM Process involves reducing Risks to an acceptable level and planning for the recovery of Business Processes should a disruption to the Business occur. BCM sets the Objectives, Scope and Requirements for IT Service Continuity Management.

Business Continuity Plan (BCP) (Service Design) A Plan defining the steps required to Restore Business Processes following a disruption. The Plan will also identify the triggers for Invocation, people to be involved, communications etc. IT Service Continuity Plans form a significant part of Business Continuity Plans.

Business Customer (Service Strategy) A recipient of a product or a Service from the Business. For example if the Business is a car manufacturer then the Business Customer is someone who buys a car.

Business Impact Analysis (BIA) (Service Strategy) BIA is the Activity in Business Continuity Management that identifies Vital Business Functions and their dependencies. These dependencies may include Suppliers, people, other Business Processes, IT Services etc. BIA defines the recovery requirements for IT Services. These requirements include Recovery Time Objectives, Recovery Point Objectives and minimum Service Level Targets for each IT Service.

Business Objective (Service Strategy) The Objective of a Business Process, or of the Business as a whole. Business Objectives support the Business Vision, provide guidance for the IT Strategy, and are often supported by IT Services.

Business Operations (Service Strategy) The day-to-day execution, monitoring and management of Business Processes.

Business Perspective (Continual Service Improvement) An understanding of the Service Provider and IT Services from the point of view of the Business, and an understanding of the Business from the point of view of the Service Provider.


• • •••



Business Process A Process that is owned and carried out by the Business. A Business Process contributes to the delivery of a product or Service to a Business Customer. For example, a retailer may have a purchasing Process which helps to deliver Services to their Business Customers. Many Business Processes rely on IT Services.

Business Relationship Management (Service Strategy) The Process or Function responsible for maintaining a Relationship with the Business. BRM usually includes:

• Managing personal Relationships with Business managers

• Providing input to Service Portfolio Management

• Ensuring that the IT Service Provider is satisfying the Business needs of the Customers This Process has strong links with Service Level Management.

Business Relationship Manager (BRM) (Service Strategy) A Role responsible for maintaining the Relationship with one or more Customers. This Role is often combined with the Service Level Manager Role. See Account Manager.

Business Service An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the Business. The term Business Service is also used to mean a Service that is delivered to Business Customers by Business Units. For example delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful delivery of Business Services often depends on one or more IT Services.

Business Service Management (BSM) (Service Strategy) (Service Design) An approach to the management of IT Services that considers the Business Processes supported and the Business value provided. This term also means the management of Business Services delivered to Business Customers.

Business Unit (Service Strategy) A segment of the Business which has its own Plans, Metrics, income and Costs. Each Business Unit owns Assets and uses these to create value for Customers in the form of goods and Services.

Call (Service Operation) A telephone call to the Service Desk from a User. A Call could result in an Incident or a Service Request being logged.

Call Center (Service Operation) An Organization. or Business Unit which handles large numbers of incoming and outgoing telephone calls. See Service Desk.

Call Type (Service Operation) A Category that is used to distinguish incoming requests to a Service Desk. Common Call Types are Incident, Service Request and Complaint.

Capability (Service Strategy) The ability of an Organization., person, Process, Application, Configuration Item or IT Service to carry out an Activity. Capabilities are intangible Assets of an Organization. See Resource.

Capability Maturity Model (CMM) (Continual Service Improvement) The Capability Maturity Model for Software (also known as the CMM and SW-CMM) is a model used to


• • • ••



identify Best Practices to help increase Process Maturity. CMM was developed at the Software Engineering Institute (SEI) of Carnegie Mellon University. In 2000, the SW-CMM was upgraded to CMMI® (Capability Maturity Model Integration). The SEI no longer maintains the SW-CMM model, its associated appraisal methods, or training materials.

Capability Maturity Model Integration (CMMI) (Continual Service Improvement) Capability Maturity Model® Integration (CMMI) is a process improvement approach developed by the Software Engineering Institute (SEI) of Carnegie Melon University. CMMI provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. See http://www.sei.cmu.edu/cmmi/ for more information. See CMM, Continuous Improvement, Maturity.

Capacity (Service Design) The maximum Throughput that a Configuration Item or IT Service can deliver whilst meeting agreed Service Level Targets. For some types of CI, Capacity may be the size or volume, for example a disk drive.

Capacity Management (Service Design) The Process responsible for ensuring that the Capacity of IT Services and the IT Infrastructure is able to deliver agreed Service Level Targets in a Cost Effective and timely manner. Capacity Management considers all Resources required to deliver the IT Service, and plans for short, medium and long term Business Requirements.

Capacity Management Information System (CMIS) (Service Design) A virtual repository of all Capacity Management data, usually stored in multiple physical locations. See Service Knowledge Management System.

Capacity Plan (Service Design) A Capacity Plan is used to manage the Resources required to deliver IT Services. The Plan contains scenarios for different predictions of Business demand, and costed options to deliver the agreed Service Level Targets.

Capacity Planning (Service Design) The Activity within Capacity Management responsible for creating a Capacity Plan.

Capital Expenditure (CAPEX) (Service Strategy) The Cost of purchasing something that will become a financial Asset, for example computer equipment and buildings. The value of the Asset is Depreciated over multiple accounting periods.

Capital Item (Service Strategy) An Asset that is of interest to Financial Management because it is above an agreed financial value.

Capitalization (Service Strategy) Identifying major Cost as capital, even though no Asset is purchased. This is done to spread the impact of the Cost over multiple accounting periods. The most common example of this is software development, or purchase of a software license.


• • •••



Category A named group of things that have something in common. Categories are used to group similar things together. For example Cost Types are used to group similar types of Cost. Incident Categories are used to group similar types of Incident, CI Types are used to group similar types of Configuration Item.

Certification Issuing a certificate to confirm Compliance to a Standard. Certification includes a formal Audit by an independent and Accredited body. The term Certification is also used to mean awarding a certificate to verify that a person has achieved a qualification.

Change (Service Transition) The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc.

Change Advisory Board (CAB) (Service Transition) A group of people that advises the Change Manager in the Assessment, prioritization and scheduling of Changes. This board is usually made up of representatives from all areas within the IT Service Provider, the Business, and Third Parties such as Suppliers.

Change Case (Service Operation) A technique used to predict the impact of proposed Changes. Change Cases use specific scenarios to clarify the scope of proposed Changes and to help with Cost Benefit Analysis. See Use Case.

Change History (Service Transition) Information about all changes made to a Configuration Item during its life. Change History consists of all those Change Records that apply to the CI.

Change Management (Service Transition) The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.

Change Model (Service Transition) A repeatable way of dealing with a particular Category of Change. A Change Model defines specific pre-defined steps that will be followed for a Change of this Category. Change Models may be very simple, with no requirement for approval (e.g. Password Reset) or may be very complex with many steps that require approval (e.g. major software Release). See Standard Change, Change Advisory Board.

Change Record (Service Transition) A Record containing the details of a Change. Each Change Record documents the Lifecycle of a single Change. A Change Record is created for every Request for Change that is received, even those that are subsequently rejected. Change Records should reference the Configuration Items that are affected by the Change. Change Records are stored in the Configuration Management System.

Change Request Synonym for Request for Change.

Change Schedule (Service Transition) A Document that lists all approved Changes and their planned implementation dates. A Change Schedule is sometimes called a Forward Schedule of Change, even though it also contains information about Changes that have already been implemented.


• • • ••



Change Window (Service Transition) A regular, agreed time when Changes or Releases may be implemented with minimal impact on Services. Change Windows are usually documented in SLAs.

Charging (Service Strategy) Requiring payment for IT Services. Charging for IT Services is optional, and many Organizations. choose to treat their IT Service Provider as a Cost Center.

Chronological Analysis (Service Operation) A technique used to help identify possible causes of Problems. All available data about the Problem is collected and sorted by date and time to provide a detailed timeline. This can make it possible to identify which Events may have been triggered by others.

CI Type (Service Transition) A Category that is used to Classify CIs. The CI Type identifies the required Attributes and Relationships for a Configuration Record. Common CI Types include: hardware, Document, User etc.

Classification The act of assigning a Category to something. Classification is used to ensure consistent management and reporting. CIs, Incidents, Problems, Changes etc. are usually classified.

Client A generic term that means a Customer, the Business or a Business Customer. For example Client Manager may be used as a synonym for Account Manager. The term client is also used to mean:

• A computer that is used directly by a User, for example a PC, Handheld Computer, or Workstation.

• The part of a Client-Server Application that the User directly interfaces with. For example an email Client.

Closed (Service Operation) The final Status in the Lifecycle of an Incident, Problem, Change etc. When the Status is Closed, no further action is taken.

Closure (Service Operation) The act of changing the Status of an Incident, Problem, Change etc. to Closed.

COBIT (Continual Service Improvement) Control Objectives for Information and related Technology (COBIT) provides guidance and Best Practice for the management of IT Processes. COBIT is published by the IT Governance Institute. See http://www.isaca.org/ for more information.

Code of Practice A Guideline published by a public body or a Standards Organization., such as ISO or BSI. Many Standards consist of a Code of Practice and a Specification. The Code of Practice describes recommended Best Practice.

Cold Standby Synonym for Gradual Recovery.

Commercial off the Shelf (COTS) (Service Design) Application software or Middleware that can be purchased from a Third Party.


• • •••



Compliance Ensuring that a Standard or set of Guidelines is followed, or that proper, consistent accounting or other practices are being employed.

Component A general term that is used to mean one part of something more complex. For example, a computer System may be a component of an IT Service, an Application may be a Component of a Release Unit. Components that need to be managed should be Configuration Items.

Component Capacity Management (CCM) (Service Design) (Continual Service Improvement) The Process responsible for understanding the Capacity, Utilization, and Performance of Configuration Items. Data is collected, recorded and analyzed for use in the Capacity Plan. See Service Capacity Management.

Component CI (Service Transition) A Configuration Item that is part of an Assembly. For example, a CPU or Memory CI may be part of a Server CI.

Component Failure Impact Analysis (CFIA) (Service Design) A technique that helps to identify the impact of CI failure on IT Services. A matrix is created with IT Services on one edge and CIs on the other. This enables the identification of critical CIs (that could cause the failure of multiple IT Services) and of fragile IT Services (that have multiple Single Points of Failure).

Computer Telephony Integration (CTI) (Service Operation) CTI is a general term covering any kind of integration between computers and telephone Systems. It is most commonly used to refer to Systems where an Application displays detailed screens relating to incoming or outgoing telephone calls. See Automatic Call Distribution, Interactive Voice Response.

Concurrency A measure of the number of Users engaged in the same Operation at the same time.

Confidentiality (Service Design) A security principle that requires that data should only be accessed by authorized people.

Configuration (Service Transition) A generic term, used to describe a group of Configuration Items that work together to deliver an IT Service, or a recognizable part of an IT Service. Configuration is also used to describe the parameter settings for one or more CIs.

Configuration Baseline (Service Transition) A Baseline of a Configuration that has been formally agreed and is managed through the Change Management process. A Configuration Baseline is used as a basis for future Builds, Releases and Changes.

Configuration Control (Service Transition) The Activity responsible for ensuring that adding, modifying or removing a CI is properly managed, for example by submitting a Request for Change or Service Request.

Configuration Identification (Service Transition) The Activity responsible for collecting information about Configuration Items and their Relationships, and loading this


• • • ••



information into the CMDB. Configuration Identification is also responsible for labeling the CIs themselves, so that the corresponding Configuration Records can be found.

Configuration Item (CI) (Service Transition) Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.

Configuration Management (Service Transition) The Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI. Configuration Management is part of an overall Service Asset and Configuration Management Process.

Configuration Management Database (CMDB) Service Transition) A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.

Configuration Management System (CMS) (Service Transition) A set of tools and databases that are used to manage an IT Service Provider's Configuration data. The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes. See Configuration Management Database, Service Knowledge Management System.

Configuration Record (Service Transition) A Record containing the details of a Configuration Item. Each Configuration Record documents the Lifecycle of a single CI. Configuration Records are stored in a Configuration Management Database.

Configuration Structure (Service Transition) The hierarchy and other Relationships between all the Configuration Items that comprise a Configuration.

Continual Service Improvement (CSI) (Continual Service Improvement) A stage in the Lifecycle of an IT Service and the title of one of the Core ITIL publications. Continual Service Improvement is responsible for managing improvements to IT Service Management Processes and IT Services. The Performance of the IT Service Provider is continually measured and improvements are made to Processes, IT Services and IT Infrastructure in order to increase Efficiency, Effectiveness, and Cost Effectiveness. See Plan-Do-Check-Act.

Continuous Availability (Service Design) An approach or design to achieve 100% Availability. A Continuously Available IT Service has no planned or unplanned Downtime.


• • •••



Continuous Operation (Service Design) An approach or design to eliminate planned Downtime of an IT Service. Note that individual Configuration Items may be down even though the IT Service is Available.

Contract A legally binding Agreement between two or more parties.

Contract Portfolio (Service Strategy) A database or structured Document used to manage Service Contracts or Agreements between an IT Service Provider and their Customers. Each IT Service delivered to a Customer should have a Contract or other Agreement which is listed in the Contract Portfolio. See Service Portfolio, Service Catalogue.

Control A means of managing a Risk, ensuring that a Business Objective is achieved, or ensuring that a Process is followed. Example Controls include Policies, Procedures, Roles, RAID, door-locks etc. A control is sometimes called a Countermeasure or safeguard. Control also means to manage the utilization or behavior of a Configuration Item, System or IT Service.

Control Objectives for Information and related Technology (COBIT) See COBIT.

Control Perspective (Service Strategy) An approach to the management of IT Services, Processes, Functions, Assets etc. There can be several different Control Perspectives on the same IT Service, Process etc., allowing different individuals or teams to focus on what is important and relevant to their specific Role. Example Control Perspectives include Reactive and Proactive management within IT Operations, or a Lifecycle view for an Application Project team.

Control Processes The ISO/IEC 20000 Process group that includes Change Management and Configuration Management.

Core Service (Service Strategy) An IT Service that delivers basic Outcomes desired by one or more Customers. See Supporting Service, Core Service Package.

Core Service Package (CSP) (Service Strategy) A detailed description of a Core Service that may be shared by two or more Service Level Packages. See Service Package.

Cost The amount of money spent on a specific Activity, IT Service, or Business Unit. Costs consist of real cost (money), notional cost such as people's time, and Depreciation.

Cost Benefit Analysis An Activity that analyses and compares the Costs and the benefits involved in one or more alternative courses of action. See Business Case, Net Present Value, Internal Rate of Return, Return on Investment, Value on Investment.

Cost Center (Service Strategy) A Business Unit or Project to which Costs are assigned. A Cost Center does not charge for Services provided. An IT Service Provider can be run as a Cost Center or a Profit Center

Cost Effectiveness A measure of the balance between the Effectiveness and Cost of a Service, Process or activity, A Cost Effective Process is one which achieves its Objectives at minimum Cost. See KPI, Return on Investment, Value for Money.


• • • ••



Cost Element (Service Strategy) The middle level of category to which Costs are assigned in Budgeting and Accounting. The highest level category is Cost Type. For example a Cost Type of “people? could have cost elements of payroll, staff benefits, expenses, training, overtime etc. Cost Elements can be further broken down to give Cost Units. For example the Cost Element “expenses? could include Cost Units of Hotels, Transport, Meals etc.

Cost Management (Service Strategy) A general term that is used to refer to Budgeting and Accounting, sometimes used as a synonym for Financial Management

Cost Type (Service Strategy) The highest level of category to which Costs are assigned in Budgeting and Accounting. For example hardware, software, people, accommodation, external and Transfer. See Cost Element, Cost Type.

Cost Unit (Service Strategy) The lowest level of category to which Costs are assigned, Cost Units are usually things that can be easily counted (e.g. staff numbers, software licenses) or things easily measured (e.g. CPU usage, Electricity consumed). Cost Units are included within Cost Elements. For example a Cost Element of “expenses? could include Cost Units of Hotels, Transport, Meals etc. See Cost Type.

Countermeasure Can be used to refer to any type of Control. The term Countermeasure is most often used when referring to measures that increase Resilience, Fault Tolerance or Reliability of an IT Service.

Course Corrections Changes made to a Plan or Activity that has already started, to ensure that it will meet its Objectives. Course corrections are made as a result of Monitoring progress.

CRAMM A methodology and tool for analyzing and managing Risks. CRAMM was developed by the UK Government, but is now privately owned. Further information is available from http://www.cramm.com/

Crisis Management The Process responsible for managing the wider implications of Business Continuity. A Crisis Management team is responsible for Strategic issues such as managing media relations and shareholder confidence, and decides when to invoke Business Continuity Plans.

Critical Success Factor (CSF) Something that must happen if a Process, Project, Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each CSF. For example a CSF of "protect IT Services when making Changes" could be measured by KPIs such as "percentage reduction of unsuccessful Changes", "percentage reduction in Changes causing Incidents" etc.

Culture A set of values that is shared by a group of people, including expectations about how people should behave, ideas, beliefs, and practices. See Vision.

Customer Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group who defines and agrees the Service Level Targets. The term Customers is also sometimes informally used to mean Users, for example "this is a Customer focused Organization.".


• • •••



Customer Portfolio (Service Strategy) A database or structured Document used to record all Customers of the IT Service Provider. The Customer Portfolio is the Business Relationship Manager's view of the Customers who receive Services from the IT Service Provider. See Contract Portfolio, Service Portfolio.

Dashboard (Service Operation) A graphical representation of overall IT Service Performance and Availability. Dashboard images may be updated in real-time, and can also be included in management reports and web pages. Dashboards can be used to support Service Level Management, Event Management or Incident Diagnosis.

Data-to-Information-to-Knowledge-to-Wisdom (DIKW) A way of understanding the relationships between data, information, knowledge, and wisdom. DIKW shows how each of these builds on the others.

Definitive Media Library (DML) (Service Transition) One or more locations in which the definitive and approved versions of all software Configuration Items are securely stored. The DML may also contain associated CIs such as licenses and documentation. The DML is a single logical storage area even if there are multiple locations. All software in the DML is under the control of Change and Release Management and is recorded in the Configuration Management System. Only software from the DML is acceptable for use in a Release.

Deliverable Something that must be provided to meet a commitment in a Service Level Agreement or a Contract. Deliverable is also used in a more informal way to mean a planned output of any Process.

Demand Management Activities that understand and influence Customer demand for Services and the provision of Capacity to meet these demands. At a Strategic level Demand Management can involve analysis of Patterns of Business Activity and User Profiles. At a Tactical level it can involve use of Differential Charging to encourage Customers to use IT Services at less busy times. See Capacity Management.

Deming Cycle Synonym for Plan Do Check Act.

Dependency The direct or indirect reliance of one Process or Activity upon another.

Deployment (Service Transition) The Activity responsible for movement of new or changed hardware, software, documentation, Process, etc to the Live Environment. Deployment is part of the Release and Deployment Management Process. See Rollout.

Depreciation (Service Strategy) A measure of the reduction in value of an Asset over its life. This is based on wearing out, consumption or other reduction in the useful economic value.

Design (Service Design) An Activity or Process that identifies Requirements and then defines a solution that is able to meet these Requirements. See Service Design.

Detection (Service Operation) A stage in the Incident Lifecycle. Detection results in the Incident becoming known to the Service Provider. Detection can be automatic, or can be the result of a User logging an Incident.


• • • ••



Development (Service Design) The Process responsible for creating or modifying an IT Service or Application. Also used to mean the Role or group that carries out Development work.

Development Environment (Service Design) An Environment used to create or modify IT Services or Applications. Development Environments are not typically subjected to the same degree of control as Test Environments or Live Environments. See Development.

Diagnosis (Service Operation) A stage in the Incident and Problem Lifecycles. The purpose of Diagnosis is to identify a Workaround for an Incident or the Root Cause of a Problem.

Diagnostic Script (Service Operation) A structured set of questions used by Service Desk staff to ensure they ask the correct questions, and to help them Classify, Resolve and assign Incidents. Diagnostic Scripts may also be made available to Users to help them diagnose and resolve their own Incidents.

Differential Charging A technique used to support Demand Management by charging different amounts for the same IT Service Function at different times.

Direct Cost (Service Strategy) A cost of providing an IT Service which can be allocated in full to a specific Customer, Cost Center, Project etc. For example cost of providing non-shared servers or software licenses. See Indirect Cost.

Directory Service (Service Operation) An Application that manages information about IT Infrastructure available on a network, and corresponding User access Rights.

Do Nothing (Service Design) A Recovery Option. The Service Provider formally agrees with the Customer that Recovery of this IT Service will not be performed.

Document Information in readable form. A Document may be paper or electronic. For example a Policy statement, Service Level Agreement, Incident Record, diagram of computer room layout. See Record.

Downtime (Service Design) (Service Operation) The time when a Configuration Item or IT Service is not Available during its Agreed Service Time. The Availability of an IT Service is often calculated from Agreed Service Time and Downtime.

Driver Something that influences Strategy, Objectives or Requirements. For example new legislation or the actions of competitors.

Early Life Support (Service Transition) Support provided for a new or Changed IT Service for a period of time after it is Released. During Early Life Support the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional Resources for Incident and Problem Management.

Economies of scale (Service Strategy) The reduction in average Cost that is possible from increasing the usage of an IT Service or Asset. See Economies of Scope.


• • •••



Economies of scope (Service Strategy) The reduction in Cost that is allocated to an IT Service by using an existing Asset for an additional purpose. For example delivering a new IT

Effectiveness (Continual Service Improvement) A measure of whether the Objectives of a Process, Service or Activity have been achieved. An Effective Process or Activity is one that achieves its agreed Objectives. See KPI.

Efficiency (Continual Service Improvement) A measure of whether the right amount of resources have been used to deliver a Process, Service or Activity. An Efficient Process achieves its Objectives with the minimum amount of time, money, people or other resources. See KPI.

Emergency Change (Service Transition) A Change that must be introduced as soon as possible. For example to resolve a Major Incident or implement a Security patch. The Change Management Process will normally have a specific Procedure for handling Emergency Changes. See Emergency Change Advisory Board (ECAB).

Emergency Change Advisory Board (ECAB) (Service Transition) A sub-set of the Change Advisory Board who make decisions about high impact Emergency Changes. Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.

Environment (Service Transition) A subset of the IT Infrastructure that is used for a particular purpose. For Example: Live Environment, Test Environment, Build Environment. It is possible for multiple Environments to share a Configuration Item, for example Test and Live Environments may use different partitions on a single mainframe computer. Also used in the term Physical Environment to mean the accommodation, air conditioning, power system etc. Environment is also used as a generic term to mean the external conditions that influence or affect something.

Error (Service Operation) A design flaw or malfunction that causes a Failure of one or more Configuration Items or IT Services. A mistake made by a person or a faulty Process that impacts a CI or IT Service is also an Error.

Escalation (Service Operation) An Activity that obtains additional Resources when these are needed to meet Service Level Targets or Customer expectations. Escalation may be needed within any IT Service Management Process, but is most commonly associated with Incident Management, Problem Management and the management of Customer complaints. There are two types of Escalation, Functional Escalation and Hierarchic Escalation.

eSourcing Capability Model for Client Organizations (eSCM-CL) (Service Strategy) A framework to help Organizations. guide their analysis and decisions on Service Sourcing Models and Strategies. eSCM-CL was developed by Carnegie Mellon University. See eSCM-SP.

eSourcing Capability Model for Service Providers (eSCM-SP) (Service Strategy) A framework to help IT Service Providers develop their IT Service Management Capabilities


• • • ••



from a Service Sourcing perspective. eSCM-SP was developed by Carnegie Mellon University. See eSCM-CL.

Estimation The use of experience to provide an approximate value for a Metric or Cost. Estimation is also used in Capacity and Availability Management as the cheapest and least accurate Modeling method.

Evaluation (Service Transition) The Process responsible for assessing a new or Changed IT Service to ensure that Risks have been managed and to help determine whether to proceed with the Change. Evaluation is also used to mean comparing an actual Outcome with the intended Outcome, or comparing one alternative with another.

Event (Service Operation) A change of state which has significance for the management of a Configuration Item or IT Service. The term Event is also used to mean an Alert or notification created by any IT Service, Configuration Item or Monitoring tool. Events typically require IT Operations personnel to take actions, and often lead to Incidents being logged.

Event Management (Service Operation) The Process responsible for managing Events throughout their Lifecycle. Event Management is one of the main Activities of IT Operations.

Exception Report A Document containing details of one or more KPIs or other important targets that have exceeded defined Thresholds. Examples include SLA targets being missed or about to be missed, and a Performance Metric indicating a potential Capacity problem.

Expanded Incident Lifecycle (Availability Management) Detailed stages in the Lifecycle of an Incident. The stages are Detection, Diagnosis, Repair, Recovery, Restoration. The Expanded Incident Lifecycle is used to help understand all contributions to the Impact of Incidents and to Plan how these could be controlled or reduced.

External Customer A Customer who works for a different Business to the IT Service Provider. See External Service Provider, Internal Customer.

External Metric A Metric that is used to measure the delivery of IT Service to a Customer. External Metrics are usually defined in SLAs and reported to Customers. See Internal Metric.

External Service Provider (Service Strategy) An IT Service Provider which is part of a different Organization. to their Customer. An IT Service Provider may have both Internal Customers and External Customers. See Type III Service Provider.

External Sourcing Synonym for Outsourcing.

Facilities Management (Service Operation) The Function responsible for managing the physical Environment where the IT Infrastructure is located. Facilities Management includes all aspects of managing the physical Environment, for example power and cooling, building Access Management, and environmental Monitoring.


• • •••



Failure (Service Operation) Loss of ability to Operate to Specification, or to deliver the required output. The term Failure may be used when referring to IT Services, Processes, Activities, Configuration Items etc. A Failure often causes an Incident.

Failure Modes and Effects Analysis (FMEA) An approach to assessing the potential Impact of Failures. FMEA involves analyzing what would happen after Failure of each Configuration Item, all the way up to the effect on the Business. FMEA is often used in Information Security Management and in IT Service Continuity Planning.

Fast Recovery (Service Design) A Recovery Option which is also known as Hot Standby. Provision is made to Recover the IT Service in a short period of time, typically less than 24 hours. Fast Recovery typically uses a dedicated Fixed Facility with computer Systems, and software configured ready to run the IT Services. Immediate Recovery may take up to 24 hours if there is a need to Restore data from Backups.

Fault Synonym for Error.

Fault Tolerance (Service Design) The ability of an IT Service or Configuration Item to continue to Operate correctly after Failure of a Component part. See Resilience, Countermeasure.

Fault Tree Analysis (FTA) (Service Design) (Continual Service Improvement) A technique that can be used to determine the chain of Events that leads to a Problem. Fault Tree Analysis represents a chain of Events using Boolean notation in a diagram.

Financial Management (Service Strategy) The Function and Processes responsible for managing an IT Service Provider's Budgeting, Accounting and Charging Requirements.

First-line Support (Service Operation) The first level in a hierarchy of Support Groups involved in the resolution of Incidents. Each level contains more specialist skills, or has more time or other Resources. See Escalation.

Fishbone Diagram Synonym for Ishikawa Diagram.

Fit for Purpose An informal term used to describe a Process, Configuration Item, IT Service etc. that is capable of meeting its Objectives or Service Levels. Being Fit for Purpose requires suitable Design, implementation, Control and maintenance.

Fixed Cost (Service Strategy) A Cost that does not vary with IT Service usage. For example the cost of Server hardware. See Variable Cost.

Fixed Facility (Service Design) A permanent building, available for use when needed by an IT Service Continuity Plan. See Recovery Option, Portable Facility.

Follow the Sun (Service Operation) A methodology for using Service Desks and Support Groups around the world to provide seamless 24 * 7 Service. Calls, Incidents, Problems and Service Requests are passed between groups in different time zones.

Fulfillment Performing Activities to meet a need or Requirement. For example by providing a new IT Service, or meeting a Service Request.


• • • ••



Function A team or group of people and the tools they use to carry out one or more Processes or Activities. For example the Service Desk. The term Function also has two other meanings:

• An intended purpose of a Configuration Item, Person, Team, Process, or IT Service. For example one Function of an Email Service may be to store and forward outgoing mails, one Function of a Business Process may be to dispatch goods to Customers.

• To perform the intended purpose correctly, "The computer is Functioning"

Functional Escalation (Service Operation) Transferring an Incident, Problem or Change to a technical team with a higher level of expertise to assist in an Escalation.

Gap Analysis (Continual Service Improvement) An Activity which compares two sets of data and identifies the differences. Gap Analysis is commonly used to compare a set of Requirements with actual delivery. See Benchmarking.

Governance Ensuring that Policies and Strategy are actually implemented, and that required Processes are correctly followed. Governance includes defining Roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified.

Gradual Recovery (Service Design) A Recovery Option which is also known as Cold Standby. Provision is made to Recover the IT Service in a period of time greater than 72 hours. Gradual Recovery typically uses a Portable or Fixed Facility that has environmental support and network cabling, but no computer Systems. The hardware and software are installed as part of the IT Service Continuity Plan.

Guideline A Document describing Best Practice, that recommends what should be done. Compliance to a guideline is not normally enforced. See Standard.

Help Desk (Service Operation) A point of contact for Users to log Incidents. A Help Desk is usually more technically focused than a Service Desk and does not provide a Single Point of Contact for all interaction. The term Help Desk is often used as a synonym for Service Desk.

Hierarchic Escalation (Service Operation) Informing or involving more senior levels of management to assist in an Escalation.

High Availability (Service Design) An approach or Design that minimizes or hides the effects of Configuration Item Failure on the Users of an IT Service. High Availability solutions are Designed to achieve an agreed level of Availability and make use of techniques such as Fault Tolerance, Resilience and fast Recovery to reduce the number of Incidents, and the Impact of Incidents.

Hot Standby Synonym for Fast Recovery or Immediate Recovery.


• • •••



Identity (Service Operation) A unique name that is used to identify a User, person or Role. The Identity is used to grant Rights to that User, person, or Role. Example identities might be the username SmithJ or the Role "Change manager".

Immediate Recovery (Service Design) A Recovery Option which is also known as Hot Standby. Provision is made to Recover the IT Service with no loss of Service. Immediate Recovery typically uses mirroring, load balancing and split site technologies.

Impact (Service Operation) (Service Transition) A measure of the effect of an Incident, Problem or Change on Business Processes. Impact is often based on how Service Levels will be affected. Impact and Urgency are used to assign Priority.

Incident (Service Operation) An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.

Incident Management (Service Operation) The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to Users as quickly as possible.

Incident Record (Service Operation) A Record containing the details of an Incident. Each Incident record documents the Lifecycle of a single Incident.

Indirect Cost (Service Strategy) A Cost of providing an IT Service which cannot be allocated in full to a specific Customer. For example Cost of providing shared Servers or software licenses. Also known as Overhead. See Direct Cost.

Information Security Management (ISM) (Service Design) The Process that ensures the Confidentiality, Integrity and Availability of an Organization.'s Assets, information, data and IT Services. Information Security Management usually forms part of an Organizational approach to Security Management which has a wider scope than the IT Service Provider, and includes handling of paper, building access, phone calls etc., for the entire Organization.

Information Security Management System (ISMS) (Service Design) The framework of Policy, Processes, Standards, Guidelines and tools that ensures an Organization. can achieve its Information Security Management Objectives.

Information Security Policy (Service Design) The Policy that governs the Organization.’s approach to Information Security Management.

Information Technology (IT) The use of technology for the storage, communication or processing of information. The technology typically includes computers, telecommunications, Applications and other software. The information may include Business data, voice, images, video, etc. Information Technology is often used to support Business Processes through IT Services.

Infrastructure Service An IT Service that is not directly used by the Business, but is required by the IT Service Provider so they can provide other IT Services. For example Directory Services, naming services, or communication services.


• • • ••



Insourcing Synonym for Internal Sourcing.

Integrity (Service Design) A security principle that ensures data and Configuration Items are only modified by authorized personnel and Activities. Integrity considers all possible causes of modification, including software and hardware Failure, environmental Events, and human intervention.

Interactive Voice Response (IVR) (Service Operation) A form of Automatic Call Distribution that accepts User input, such as key presses and spoken commands, to identify the correct destination for incoming Calls.

Intermediate Recovery (Service Design) A Recovery Option which is also known as Warm Standby. Provision is made to Recover the IT Service in a period of time between 24 and 72 hours. Intermediate Recovery typically uses a shared Portable or Fixed Facility that has computer Systems and network Components. The hardware and software will need to be configured, and data will need to be restored, as part of the IT Service Continuity Plan.

Internal Customer A Customer who works for the same Business as the IT Service Provider. See Internal Service Provider, External Customer.

Internal Metric A Metric that is used within the IT Service Provider to Monitor the Efficiency, Effectiveness or Cost Effectiveness of the IT Service Provider's internal Processes. Internal Metrics are not normally reported to the Customer of the IT Service. See External Metric.

Internal Rate of Return (IRR) (Service Strategy) A technique used to help make decisions about Capital Expenditure. IRR calculates a figure that allows two or more alternative investments to be compared. A larger IRR indicates a better investment. See Net Present Value, Return on Investment.

Internal Service Provider (Service Strategy) An IT Service Provider which is part of the same Organization. as their Customer. An IT Service Provider may have both Internal Customers and External Customers. See Type I Service Provider, Type II Service Provider, Insource.

Internal Sourcing (Service Strategy) Using an Internal Service Provider to manage IT Services. See Service Sourcing, Type I Service Provider, Type II Service Provider.

International Organization for Standardization (ISO) The International Organization for Standardization (ISO) is the world's largest developer of Standards. ISO is a non-governmental organization which is a network of the national standards institutes of 156 countries. Further information about ISO is available from http://www.iso.org/

International Standards Organization. See International Organization for Standardization (ISO)

Internet Service Provider (ISP) An External Service Provider that provides access to the Internet. Most ISPs also provide other IT Services such as web hosting.


• • •••



Invocation (Service Design) Initiation of the steps defined in a plan. For example initiating the IT Service Continuity Plan for one or more IT Services.

Ishikawa Diagram (Service Operation) (Continual Service Improvement) A technique that helps a team to identify all the possible causes of a Problem. Originally devised by Kaoru Ishikawa, the output of this technique is a diagram that looks like a fishbone.

ISO 9000 A generic term that refers to a number of international Standards and Guidelines for Quality Management Systems. See http://www.iso.org/ for more information. See ISO.

ISO 9001 An international Standard for Quality Management Systems. See ISO 9000, Standard.

ISO/IEC 17799 (Continual Service Improvement) ISO Code of Practice for Information Security Management. See Standard.

ISO/IEC 20000 ISO Specification and Code of Practice for IT Service Management. ISO/IEC 20000 is aligned with ITIL Best Practice.

ISO/IEC 27001 (Service Design) (Continual Service Improvement) ISO Specification for Information Security Management. The corresponding Code of Practice is ISO/IEC 17799. See Standard.

IT Directorate (Continual Service Improvement) Senior Management within a Service Provider, charged with developing and delivering IT services. Most commonly used in UK Government departments.

IT Infrastructure All of the hardware, software, networks, facilities etc. that are required to Develop, Test, deliver, Monitor, Control or support IT Services. The term IT Infrastructure includes all of the Information Technology but not the associated people, Processes and documentation.

IT Operations (Service Operation) Activities carried out by IT Operations Control, including Console Management, Job Scheduling, Backup and Restore, and Print and Output Management. IT Operations is also used as a synonym for Service Operation.

IT Operations Control (Service Operation) The Function responsible for Monitoring and Control of the IT Services and IT Infrastructure. See Operations Bridge.

IT Operations Management (Service Operation) The Function within an IT Service Provider which performs the daily Activities needed to manage IT Services and the supporting IT Infrastructure. IT Operations Management includes IT Operations Control and Facilities Management.

IT Service A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.


• • • ••



IT Service Continuity Management (ITSCM) (Service Design) The Process responsible for managing Risks that could seriously impact IT Services. ITSCM ensures that the IT Service Provider can always provide minimum agreed Service Levels, by reducing the Risk to an acceptable level and Planning for the Recovery of IT Services. ITSCM should be designed to support Business Continuity Management.

IT Service Continuity Plan (Service Design) A Plan defining the steps required to Recover one or more IT Services. The Plan will also identify the triggers for Invocation, people to be involved, communications etc. The IT Service Continuity Plan should be part of a Business Continuity Plan.

IT Service Management (ITSM) The implementation and management of Quality IT Services that meet the needs of the Business. IT Service Management is performed by IT Service Providers through an appropriate mix of people, Process and Information Technology. See Service Management.

IT Service Management Forum (itSMF) The IT Service Management Forum is an independent Organization. dedicated to promoting a professional approach to IT Service Management. The itSMF is a not-for-profit membership Organization. with representation in many countries around the world (itSMF Chapters). The itSMF and its membership contribute to the development of ITIL and associated IT Service Management Standards. See http://www.itsmf.com/ for more information.

IT Service Provider (Service Strategy) A Service Provider that provides IT Services to Internal Customers or External Customers.

IT Steering Group (ISG) A formal group that is responsible for ensuring that Business and IT Service Provider Strategies and Plans are closely aligned. An IT Steering Group includes senior representatives from the Business and the IT Service Provider.

ITIL A set of Best Practice guidance for IT Service Management. ITIL is owned by the OGC and consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them. See http://www.itil.co.uk/ for more information.

Job Description A Document which defines the Roles, responsibilities, skills and knowledge required by a particular person. One Job Description can include multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by one person.

Job Scheduling (Service Operation) Planning and managing the execution of software tasks that are required as part of an IT Service. Job Scheduling is carried out by IT Operations Management, and is often automated using software tools that run batch or online tasks at specific times of the day, week, month or year.

Kano Model (Service Strategy) A Model developed by Noriaki Kano that is used to help understand Customer preferences. The Kano Model considers Attributes of an IT Service grouped into areas such as Basic Factors, Excitement Factors, Performance Factors etc.


• • •••



Kepner & Tregoe Analysis (Service Operation) (Continual Service Improvement) A structured approach to Problem solving. The Problem is analyzed in terms of what, where, when and extent. Possible causes are identified. The most probable cause is tested. The true cause is verified.

Key Performance Indicator (KPI) (Continual Service Improvement) A Metric that is used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed. See Critical Success Factor.

Knowledge Base (Service Transition) A logical database containing the data used by the Service Knowledge Management System.

Knowledge Management (Service Transition) The Process responsible for gathering, analyzing, storing and sharing knowledge and information within an Organization. The primary purpose of Knowledge Management is to improve Efficiency by reducing the need to rediscover knowledge. See Data-to-Information-to-Knowledge-to-Wisdom, Service Knowledge Management System.

Known Error (Service Operation) A Problem that has a documented Root Cause and a Workaround. Known Errors are created and managed throughout their Lifecycle by Problem Management. Known Errors may also be identified by Development or Suppliers.

Known Error Database (KEDB) (Service Operation) A database containing all Known Error Records. This database is created by Problem Management and used by Incident and Problem Management. The Known Error Database is part of the Service Knowledge Management System.

Known Error Record (Service Operation) A Record containing the details of a Known Error. Each Known Error Record documents the Lifecycle of a Known Error, including the Status, Root Cause and Workaround. In some implementations a Known Error is documented using additional fields in a Problem Record.

Lifecycle The various stages in the life of an IT Service, Configuration Item, Incident, Problem, Change etc. The Lifecycle defines the Categories for Status and the Status transitions that are permitted. For example:

• The Lifecycle of an Application includes Requirements, Design, Build, Deploy, Operate, Optimize.

• The Expanded Incident Lifecycle includes Detect, Respond, Diagnose, Repair, Recover, Restore.

• The lifecycle of a Server may include: Ordered, Received, In Test, Live, Disposed etc.


• • • ••



Line of Service (LOS) (Service Strategy) A Core Service or Supporting Service that has multiple Service Level Packages. A line of Service is managed by a Product Manager and each Service Level Package is designed to support a particular market segment.

Live (Service Transition) Refers to an IT Service or Configuration Item that is being used to deliver Service to a Customer.

Live Environment (Service Transition) A controlled Environment containing Live Configuration Items used to deliver IT Services to Customers.

Maintainability (Service Design) A measure of how quickly and Effectively a Configuration Item or IT Service can be restored to normal working after a Failure. Maintainability is often measured and reported as MTRS. Maintainability is also used in the context of Software or IT Service Development to mean ability to be Changed or Repaired easily.

Major Incident (Service Operation) The highest Category of Impact for an Incident. A Major Incident results in significant disruption to the Business.

Managed Services (Service Strategy) A perspective on IT Services which emphasizes the fact that they are managed. The term Managed Services is also used as a synonym for Outsourced IT Services.

Management Information Information that is used to support decision making by managers. Management Information is often generated automatically by tools supporting the various IT Service Management Processes. Management Information often includes the values of KPIs such as "Percentage of Changes leading to Incidents", or "first time fix rate".

Management of Risk (MoR) The OGC methodology for managing Risks. MoR includes all the Activities required to identify and Control the exposure to Risk which may have an impact on the achievement of an Organization.’s Business Objectives. See http://www.m-o-r.org/ for more details.

Management System The framework of Policy, Processes and Functions that ensures an Organization. can achieve its Objectives.

Manual Workaround A Workaround that requires manual intervention. Manual Workaround is also used as the name of a Recovery Option in which The Business Process Operates without the use of IT Services. This is a temporary measure and is usually combined with another Recovery Option.

Marginal Cost (Service Strategy) The Cost of continuing to provide the IT Service. Marginal Cost does not include investment already made, for example the cost of developing new software and delivering training.

Market Space (Service Strategy) All opportunities that an IT Service Provider could exploit to meet business needs of Customers. The Market Space identifies the possible IT Services that an IT Service Provider may wish to consider delivering.


• • •••



Maturity (Continual Service Improvement) A measure of the Reliability, Efficiency and Effectiveness of a Process, Function, Organization. etc. The most mature Processes and Functions are formally aligned to Business Objectives and Strategy, and are supported by a framework for continual improvement.

Maturity Level A named level in a Maturity model such as the Carnegie Mellon Capability Maturity Model Integration.

Mean Time Between Failures (MTBF) (Service Design) A Metric for measuring and reporting Reliability. MTBF is the average time that a Configuration Item or IT Service can perform its agreed Function without interruption. This is measured from when the CI or IT Service starts working, until it next fails.

Mean Time Between Service Incidents (MTBSI) (Service Design) A Metric used for measuring and reporting Reliability. MTBSI is the mean time from when a System or IT Service fails, until it next fails. MTBSI is equal to MTBF + MTRS.

Mean Time To Repair (MTTR) The average time taken to repair a Configuration Item or IT Service after a Failure. MTTR is measured from when the CI or IT Service fails until it is Repaired. MTTR does not include the time required to Recover or Restore. MTTR is sometimes incorrectly used to mean Mean Time to Restore Service.

Mean Time to Restore Service (MTRS) The average time taken to Restore a Configuration Item or IT Service after a Failure. MTRS is measured from when the CI or IT Service fails until it is fully Restored and delivering its normal functionality. See Maintainability, Mean Time to Repair.

Metric (Continual Service Improvement) Something that is measured and reported to help manage a Process, IT Service or Activity. See KPI.

Middleware (Service Design) Software that connects two or more software Components or Applications. Middleware is usually purchased from a Supplier, rather than developed within the IT Service Provider. See Off the Shelf.

Mission Statement The Mission Statement of an Organization. is a short but complete description of the overall purpose and intentions of that Organization. It states what is to be achieved, but not how this should be done.

Model A representation of a System, Process, IT Service, Configuration Item etc. that is used to help understand or predict future behavior

Modeling A technique that is used to predict the future behavior of a System, Process, IT Service, Configuration Item etc. Modeling is commonly used in Financial Management, Capacity Management and Availability Management.

Monitor Control Loop (Service Operation) Monitoring the output of a Task, Process, IT Service or Configuration Item; comparing this output to a predefined norm; and taking appropriate action based on this comparison.


• • • ••



Monitoring (Service Operation) Repeated observation of a Configuration Item, IT Service or Process to detect Events and to ensure that the current status is known.

Near-Shore (Service Strategy) Provision of Services from a country near the country where the Customer is based. This can be the provision of an IT Service, or of supporting Functions such as Service Desk. See On-shore, Off-shore.

Net Present Value (NPV) (Service Strategy) A technique used to help make decisions about Capital Expenditure. NPV compares cash inflows to cash outflows. Positive NPV indicates that an investment is worthwhile. See Internal Rate of Return, Return on Investment.

Notional Charging (Service Strategy) An approach to Charging for IT Services. Charges to Customers are calculated and Customers are informed of the charge, but no money is actually transferred. Notional Charging is sometimes introduced to ensure that Customers are aware of the Costs they incur, or as a stage during the introduction of real Charging.

Objective The defined purpose or aim of a Process, an Activity or an Organization. as a whole. Objectives are usually expressed as measurable targets. The term Objective is also informally used to mean a Requirement. See Outcome.

Off the Shelf Synonym for Commercial Off the Shelf.

Office of Government Commerce (OGC) OGC owns the ITIL brand (copyright and trademark). OGC is a UK Government department that supports the delivery of the government's procurement agenda through its work in collaborative procurement and in raising levels of procurement skills and capability with departments. It also provides support for complex public sector projects.

Office of Public Sector Information (OPSI) OPSI license the Crown Copyright material used in the ITIL publications. They are a UK Government department who provide online access to UK legislation, license the re-use of Crown copyright material, manage the Information Fair Trader Scheme, maintain the Government’s Information Asset Register and provide advice and guidance on official publishing and Crown copyright.

Off-shore (Service Strategy) Provision of Services from a location outside the country where the Customer is based, often in a different continent. This can be the provision of an IT Service, or of supporting Functions such as Service Desk. See On-shore, Near-shore.

On-shore (Service Strategy) Provision of Services from a location within the country where the Customer is based. See Off-shore, Near-shore.

Operate To perform as expected. A Process or Configuration Item is said to Operate if it is delivering the Required outputs. Operate also means to perform one or more Operations. For example, to Operate a computer is to do the day-to-day Operations needed for it to perform as expected.

Operation (Service Operation) Day-to-day management of an IT Service, System, or other Configuration Item. Operation is also used to mean any pre-defined Activity or


• • •••



Transaction. For example loading a magnetic tape, accepting money at a point of sale, or reading data from a disk drive.

Operational The lowest of three levels of Planning and delivery (Strategic, Tactical, Operational). Operational Activities include the day-to-day or short term Planning or delivery of a Business Process or IT Service Management Process. The term Operational is also a synonym for Live.

Operational Cost Cost resulting from running the IT Services. Often repeating payments. For example staff costs, hardware maintenance and electricity (also known as "current expenditure" or "revenue expenditure"). See Capital Expenditure.

Operational Expenditure (OPEX) Synonym for Operational Cost.

Operational Level Agreement (OLA) (Service Design) (Continual Service Improvement) An Agreement between an IT Service Provider and another part of the same Organization. An OLA supports the IT Service Provider's delivery of IT Services to Customers. The OLA defines the goods or Services to be provided and the responsibilities of both parties. For example there could be an OLA:

• between the IT Service Provider and a procurement department to obtain hardware in agreed times

• between the Service Desk and a Support Group to provide Incident Resolution in agreed times. See Service Level Agreement.

Operations Bridge (Service Operation) A physical location where IT Services and IT Infrastructure are monitored and managed.

Operations Control Synonym for IT Operations Control.

Operations Management Synonym for IT Operations Management.

Opportunity Cost (Service Strategy) A Cost that is used in deciding between investment choices. Opportunity Cost represents the revenue that would have been generated by using the Resources in a different way. For example the Opportunity Cost of purchasing a new Server may include not carrying out a Service Improvement activity that the money could have been spent on. Opportunity cost analysis is used as part of a decision making processes, but is not treated as an actual Cost in any financial statement.

Optimize Review, Plan and request Changes, in order to obtain the maximum Efficiency and Effectiveness from a Process, Configuration Item, Application etc.

Organization. A company, legal entity or other institution. Examples of Organizations. that are not companies include International Standards Organization. or itSMF. The term Organization. is sometimes used to refer to any entity which has People, Resources and Budgets. For example a Project or Business Unit.


• • • ••



Outcome The result of carrying out an Activity; following a Process; delivering an IT Service etc. The term Outcome is used to refer to intended results, as well as to actual results. See Objective.

Outsourcing (Service Strategy) Using an External Service Provider to manage IT Services. See Service Sourcing, Type III Service Provider.

Overhead Synonym for Indirect cost

Pain Value Analysis (Service Operation) A technique used to help identify the Business Impact of one or more Problems. A formula is used to calculate Pain Value based on the number of Users affected, the duration of the Downtime, the Impact on each User, and the cost to the Business (if known).

Pareto Principle (Service Operation) A technique used to prioritize Activities. The Pareto Principle says that 80% of the value of any Activity is created with 20% of the effort. Pareto Analysis is also used in Problem Management to prioritize possible Problem causes for investigation.

Partnership A relationship between two Organizations. which involves working closely together for common goals or mutual benefit. The IT Service Provider should have a Partnership with the Business, and with Third Parties who are critical to the delivery of IT Services. See Value Network.

Passive Monitoring (Service Operation) Monitoring of a Configuration Item, an IT Service or a Process that relies on an Alert or notification to discover the current status. See Active Monitoring.

Pattern of Business Activity (PBA) (Service Strategy) A Workload profile of one or more Business Activities. Patterns of Business Activity are used to help the IT Service Provider understand and plan for different levels of Business Activity. See User Profile.

Percentage Utilization (Service Design) The amount of time that a Component is busy over a given period of time. For example, if a CPU is busy for 1800 seconds in a one hour period, its utilization is 50%

Performance A measure of what is achieved or delivered by a System, person, team, Process, or IT Service.

Performance Anatomy (Service Strategy) An approach to Organizational Culture that integrates, and actively manages, leadership and strategy, people development, technology enablement, performance management and innovation.

Performance Management (Continual Service Improvement) The Process responsible for day-to-day Capacity Management Activities. These include Monitoring, Threshold detection, Performance analysis and Tuning, and implementing Changes related to Performance and Capacity.


• • •••



Pilot (Service Transition) A limited Deployment of an IT Service, a Release or a Process to the Live Environment. A Pilot is used to reduce Risk and to gain User feedback and Acceptance. See Test, Evaluation.

Plan A detailed proposal which describes the Activities and Resources needed to achieve an Objective. For example a Plan to implement a new IT Service or Process. ISO/IEC 20000 requires a Plan for the management of each IT Service Management Process.

Plan-Do-Check-Act (Continual Service Improvement) A four stage cycle for Process management, attributed to Edward Deming. Plan-Do-Check-Act is also called the Deming Cycle. PLAN: Design or revise Processes that support the IT Services. DO: Implement the Plan and manage the Processes. CHECK: Measure the Processes and IT Services, compare with Objectives and produce reports ACT: Plan and implement Changes to improve the Processes.

Planned Downtime (Service Design) Agreed time when an IT Service will not be available. Planned Downtime is often used for maintenance, upgrades and testing. See Change Window, Downtime.

Planning An Activity responsible for creating one or more Plans. For example, Capacity Planning.

PMBOK A Project management Standard maintained and published by the Project Management Institute. PMBOK stands for Project Management Body of Knowledge. See http://www.pmi.org/ for more information. See PRINCE2.

Policy Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.

Portable Facility (Service Design) A prefabricated building, or a large vehicle, provided by a Third Party and moved to a site when needed by an IT Service Continuity Plan. See Recovery Option, Fixed Facility.

Post Implementation Review (PIR) A Review that takes place after a Change or a Project has been implemented. A PIR determines if the Change or Project was successful, and identifies opportunities for improvement.

Practice A way of working, or a way in which work must be done. Practices can include Activities, Processes, Functions, Standards and Guidelines. See Best Practice.

Prerequisite for Success (PFS) An Activity that needs to be completed, or a condition that needs to be met, to enable successful implementation of a Plan or Process. A PFS is often an output from one Process that is a required input to another Process.

Pricing (Service Strategy) The Activity for establishing how much Customers will be Charged.

PRINCE2 The standard UK government methodology for Project management. See http://www.ogc.gov.uk/prince2/ for more information. See PMBOK.


• • • ••



Priority (Service Transition) (Service Operation) A Category used to identify the relative importance of an Incident, Problem or Change. Priority is based on Impact and Urgency, and is used to identify required times for actions to be taken. For example the SLA may state that Priority2 Incidents must be resolved within 12 hours.

Proactive Monitoring (Service Operation) Monitoring that looks for patterns of Events to predict possible future Failures. See Reactive Monitoring.

Proactive Problem Management (Service Operation) Part of the Problem Management Process. The Objective of Proactive Problem Management is to identify Problems that might otherwise be missed. Proactive Problem Management analyses Incident Records, and uses data collected by other IT Service Management Processes to identify trends or significant Problems.

Problem (Service Operation) A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.

Problem Management (Service Operation) The Process responsible for managing the Lifecycle of all Problems. The primary Objectives of Problem Management are to prevent Incidents from happening, and to minimize the Impact of Incidents that cannot be prevented.

Problem Record (Service Operation) A Record containing the details of a Problem. Each Problem Record documents the Lifecycle of a single Problem.

Procedure A Document containing steps that specify how to achieve an Activity. Procedures are defined as part of Processes. See Work Instruction.

Process A structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management Controls required to reliably deliver the outputs. A Process may define Policies, Standards, Guidelines, Activities, and Work Instructions if they are needed.

Process Control The Activity of planning and regulating a Process, with the Objective of performing the Process in an Effective, Efficient, and consistent manner.

Process Manager A Role responsible for Operational management of a Process. The Process Manager's responsibilities include Planning and co-ordination of all Activities required to carry out, monitor and report on the Process. There may be several Process Managers for one Process, for example regional Change Managers or IT Service Continuity Managers for each data center The Process Manager Role is often assigned to the person who carries out the Process Owner Role, but the two Roles may be separate in larger Organizations.

Process Owner A Role responsible for ensuring that a Process is Fit for Purpose. The Process Owner’s responsibilities include sponsorship, Design, Change Management and continual improvement of the Process and its Metrics. This Role is often assigned to the


• • •••



same person who carries out the Process Manager Role, but the two Roles may be separate in larger Organizations.

Production Environment Synonym for Live Environment.

Profit Center (Service Strategy) A Business Unit which charges for Services provided. A Profit Center can be created with the objective of making a profit, recovering Costs, or running at a loss. An IT Service Provider can be run as a Cost Center or a Profit Center

Pro-forma A template, or example Document containing example data that will be replaced with the real values when these are available.

Program A number of Projects and Activities that are planned and managed together to achieve an overall set of related Objectives and other Outcomes.

Project A temporary Organization., with people and other Assets required to achieve an Objective or other Outcome. Each Project has a Lifecycle that typically includes initiation, Planning, execution, Closure etc. Projects are usually managed using a formal methodology such as PRINCE2.

Projected Service Outage (PSO) (Service Transition) A Document that identifies the effect of planned Changes, maintenance Activities and Test Plans on agreed Service Levels.

Projects IN Controlled Environments (PRINCE2) See PRINCE2

Qualification (Service Transition) An Activity that ensures that IT Infrastructure is appropriate, and correctly configured, to support an Application or IT Service. See Validation.

Quality The ability of a product, Service, or Process to provide the intended value. For example, a hardware Component can be considered to be of high Quality if it performs as expected and delivers the required Reliability. Process Quality also requires an ability to monitor Effectiveness and Efficiency, and to improve them if necessary. See Quality Management System.

Quality Assurance (QA) (Service Transition) The Process responsible for ensuring that the Quality of a product, Service or Process will provide its intended Value.

Quality Management System (QMS) (Continual Service Improvement) The set of Processes responsible for ensuring that all work carried out by an Organization. is of a suitable Quality to reliably meet Business Objectives or Service Levels. See ISO 9000.

Quick Win (Continual Service Improvement) An improvement Activity which is expected to provide a Return on Investment in a short period of time with relatively small Cost and effort. See Pareto Principle.

RACI (Service Design) (Continual Service Improvement) A Model used to help define Roles and Responsibilities. RACI stands for Responsible, Accountable, Consulted and Informed. See Stakeholder.


• • • ••



Reactive Monitoring (Service Operation) Monitoring that takes action in response to an Event. For example submitting a batch job when the previous job completes, or logging an Incident when an Error occurs. See Proactive Monitoring.

Reciprocal Arrangement (Service Design) A Recovery Option. An agreement between two Organizations. to share resources in an emergency. For example, Computer Room space or use of a mainframe.

Record A Document containing the results or other output from a Process or Activity. Records are evidence of the fact that an Activity took place and may be paper or electronic. For example, an Audit report, an Incident Record, or the minutes of a meeting.

Recovery (Service Design) (Service Operation) Returning a Configuration Item or an IT Service to a working state. Recovery of an IT Service often includes recovering data to a known consistent state. After Recovery, further steps may be needed before the IT Service can be made available to the Users (Restoration).

Recovery Option (Service Design) A Strategy for responding to an interruption to Service. Commonly used Strategies are Do Nothing, Manual Workaround, Reciprocal Arrangement, Gradual Recovery, Intermediate Recovery, Fast Recovery, Immediate Recovery. Recovery Options may make use of dedicated facilities, or Third Party facilities shared by multiple Businesses.

Recovery Point Objective (RPO) (Service Operation) The maximum amount of data that may be lost when Service is Restored after an interruption. Recovery Point Objective is expressed as a length of time before the Failure. For example a Recovery Point Objective of one day may be supported by daily Backups, and up to 24 hours of data may be lost. Recovery Point Objectives for each IT Service should be negotiated, agreed and documented, and used as Requirements for Service Design and IT Service Continuity Plans.

Recovery Time Objective (RTO) (Service Operation) The maximum time allowed for recovery of an IT Service following an interruption. The Service Level to be provided may be less than normal Service Level Targets. Recovery Time Objectives for each IT Service should be negotiated, agreed and documented. See Business Impact Analysis.

Redundancy Synonym for Fault Tolerance. The term Redundant also has a generic meaning of obsolete, or no longer needed.

Relationship A connection or interaction between two people or things. In Business Relationship Management it is the interaction between the IT Service Provider and the Business. In Configuration Management it is a link between two Configuration Items that identifies a dependency or connection between them. For example Applications may be linked to the Servers they run on, IT Services have many links to all the CIs that contribute to them.

Relationship Processes The ISO/IEC 20000 Process group that includes Business Relationship Management and Supplier Management.


• • •••



Release (Service Transition) A collection of hardware, software, documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, Tested, and Deployed as a single entity.

Release and Deployment Management (Service Transition) The Process responsible for both Release Management and Deployment.

Release Identification (Service Transition) A naming convention used to uniquely identify a Release. The Release Identification typically includes a reference to the Configuration Item and a version number. For example Microsoft Office 2003 SR2.

Release Management (Service Transition) The Process responsible for Planning, scheduling and controlling the movement of Releases to Test and Live Environments. The primary Objective of Release Management is to ensure that the integrity of the Live Environment is protected and that the correct Components are released. Release Management is part of the Release and Deployment Management Process.

Release Process The name used by ISO/IEC 20000 for the Process group that includes Release Management. This group does not include any other Processes. Release Process is also used as a synonym for Release Management Process.

Release Record (Service Transition) A Record in the CMDB that defines the content of a Release. A Release Record has Relationships with all Configuration Items that are affected by the Release.

Release Unit (Service Transition) Components of an IT Service that are normally Released together. A Release Unit typically includes sufficient Components to perform a useful Function. For example one Release Unit could be a Desktop PC, including Hardware, Software, Licenses, Documentation etc. A different Release Unit may be the complete Payroll Application, including IT Operations Procedures and User training.

Release Window Synonym for Change Window.

Reliability (Service Design) (Continual Service Improvement) A measure of how long a Configuration Item or IT Service can perform its agreed Function without interruption. Usually measured as MTBF or MTBSI. The term Reliability can also be used to state how likely it is that a Process, Function etc. will deliver its required outputs. See Availability.

Remediation (Service Transition) Recovery to a known state after a failed Change or Release.

Repair (Service Operation) The replacement or correction of a failed Configuration Item.

Request for Change (RFC) (Service Transition) A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change itself.

Request Fulfillment (Service Operation) The Process responsible for managing the Lifecycle of all Service Requests.


• • • ••



Requirement (Service Design) A formal statement of what is needed. For example a Service Level Requirement, a Project Requirement or the required Deliverables for a Process. See Statement of Requirements.

Resilience (Service Design) The ability of a Configuration Item or IT Service to resist Failure or to Recover quickly following a Failure. For example, an armored cable will resist failure when put under stress. See Fault Tolerance.

Resolution (Service Operation) Action taken to repair the Root Cause of an Incident or Problem, or to implement a Workaround. In ISO/IEC 20000, Resolution Processes is the Process group that includes Incident and Problem Management.

Resolution Processes The ISO/IEC 20000 Process group that includes Incident Management and Problem Management.

Resource (Service Strategy) A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT Service. Resources are considered to be Assets of an Organization. See Capability, Service Asset.

Response Time A measure of the time taken to complete an Operation or Transaction. Used in Capacity Management as a measure of IT Infrastructure Performance, and in Incident Management as a measure of the time taken to answer the phone, or to start Diagnosis.

Responsiveness A measurement of the time taken to respond to something. This could be Response Time of a Transaction, or the speed with which an IT Service Provider responds to an Incident or Request for Change etc.

Restoration of Service See Restore.

Restore (Service Operation)Taking action to return an IT Service to the Users after Repair and Recovery from an Incident. This is the primary Objective of Incident Management.

Retire (Service Transition) Permanent removal of an IT Service, or other Configuration Item, from the Live Environment. Retired is a stage in the Lifecycle of many Configuration Items.

Return on Investment (ROI) (Service Strategy) (Continual Service Improvement) A measurement of the expected benefit of an investment. In the simplest sense it is the net profit of an investment divided by the net worth of the assets invested. See Net Present Value, Value on Investment.

Return to Normal (Service Design) The phase of an IT Service Continuity Plan during which full normal operations are resumed. For example, if an alternate data center has been in use, then this phase will bring the primary data center back into operation, and restore the ability to invoke IT Service Continuity Plans again.

Review An evaluation of a Change, Problem, Process, Project etc. Reviews are typically carried out at predefined points in the Lifecycle, and especially after Closure. The purpose


• • •••



of a Review is to ensure that all Deliverables have been provided, and to identify opportunities for improvement. See Post Implementation Review.

Rights (Service Operation) Entitlements, or permissions, granted to a User or Role. For example the Right to modify particular data, or to authorize a Change.

Risk A possible Event that could cause harm or loss, or affect the ability to achieve Objectives. A Risk is measured by the probability of a Threat, the Vulnerability of the Asset to that Threat, and the Impact it would have if it occurred.

Risk Assessment The initial steps of Risk Management. Analyzing the value of Assets to the business, identifying Threats to those Assets, and evaluating how Vulnerable each Asset is to those Threats. Risk Assessment can be quantitative (based on numerical data) or qualitative.

Risk Management The Process responsible for identifying, assessing and controlling Risks. See Risk Assessment.

Role A set of responsibilities, Activities and authorities granted to a person or team. A Role is defined in a Process. One person or team may have multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by a single person.

Rollout (Service Transition) Synonym for Deployment. Most often used to refer to complex or phased Deployments or Deployments to multiple locations.

Root Cause (Service Operation) The underlying or original cause of an Incident or Problem.

Root Cause Analysis (RCA) (Service Operation) An Activity that identifies the Root Cause of an Incident or Problem. RCA typically concentrates on IT Infrastructure failures. See Service Failure Analysis.

Running Costs Synonym for Operational Costs

Scalability The ability of an IT Service, Process, Configuration Item etc. to perform its agreed Function when the Workload or Scope changes.

Scope The boundary, or extent, to which a Process, Procedure, Certification, Contract etc. applies. For example the Scope of Change Management may include all Live IT Services and related Configuration Items, the Scope of an ISO/IEC 20000 Certificate may include all IT Services delivered out of a named data center

Second-line Support (Service Operation) The second level in a hierarchy of Support Groups involved in the resolution of Incidents and investigation of Problems. Each level contains more specialist skills, or has more time or other Resources.

Security See Information Security Management

Security Management Synonym for Information Security Management


• • • ••



Security Policy Synonym for Information Security Policy

Separation of Concerns (SoC) (Service Strategy) An approach to Designing a solution or IT Service that divides the problem into pieces that can be solved independently. This approach separates "what" is to be done from "how" it is to be done.

Server (Service Operation) A computer that is connected to a network and provides software Functions that are used by other computers.

Service A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

Service Acceptance Criteria (SAC) (Service Transition) A set of criteria used to ensure that an IT Service meets its functionality and Quality Requirements and that the IT Service Provider is ready to Operate the new IT Service when it has been Deployed. See Acceptance.

Service Analytics (Service Strategy) A technique used in the Assessment of the Business Impact of Incidents. Service Analytics Models the dependencies between Configuration Items, and the dependencies of IT Services on Configuration Items.

Service Asset Any Capability or Resource of a Service Provider. See Asset.

Service Asset and Configuration Management (SACM) (Service Transition) The Process responsible for both Configuration Management and Asset Management.

Service Capacity Management (SCM) (Service Design) (Continual Service Improvement) The Activity responsible for understanding the Performance and Capacity of IT Services. The Resources used by each IT Service and the pattern of usage over time are collected, recorded, and analyzed for use in the Capacity Plan. See Business Capacity Management, Component Capacity Management.

Service Catalogue (Service Design) A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes. See Contract Portfolio.

Service Continuity Management Synonym for IT Service Continuity Management.

Service Contract (Service Strategy) A Contract to deliver one or more IT Services. The term Service Contract is also used to mean any Agreement to deliver IT Services, whether this is a legal Contract or an SLA. See Contract Portfolio.

Service Culture A Customer oriented Culture. The major Objectives of a Service Culture are Customer satisfaction and helping the Customer to achieve their Business Objectives.


• • •••



Service Design (Service Design) A stage in the Lifecycle of an IT Service. Service Design includes a number of Processes and Functions and is the title of one of the Core ITIL publications. See Design.

Service Design Package (Service Design) Document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement.

Service Desk (Service Operation) The Single Point of Contact between the Service Provider and the Users. A typical Service Desk manages Incidents and Service Requests, and also handles communication with the Users.

Service Failure Analysis (SFA) (Service Design) An Activity that identifies underlying causes of one or more IT Service interruptions. SFA identifies opportunities to improve the IT Service Provider's Processes and tools, and not just the IT Infrastructure. SFA is a time constrained, project-like activity, rather than an ongoing process of analysis. See Root Cause Analysis.

Service Hours (Service Design) (Continual Service Improvement) An agreed time period when a particular IT Service should be Available. For example, "Monday-Friday 08:00 to 17:00 except public holidays". Service Hours should be defined in a Service Level Agreement.

Service Improvement Plan (SIP) (Continual Service Improvement) A formal Plan to implement improvements to a Process or IT Service.

Service Knowledge Management System (SKMS) (Service Transition) A set of tools and databases that are used to manage knowledge and information. The SKMS includes the Configuration Management System, as well as other tools and databases. The SKMS stores, manages, updates, and presents all information that an IT Service Provider needs to manage the full Lifecycle of IT Services.

Service Level Measured and reported achievement against one or more Service Level Targets. The term Service Level is sometimes used informally to mean Service Level Target.

Service Level Agreement (SLA) (Service Design) (Continual Service Improvement) An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers. See Operational Level Agreement.

Service Level Management (SLM) (Service Design) (Continual Service Improvement) The Process responsible for negotiating Service Level Agreements, and ensuring that these are met. SLM is responsible for ensuring that all IT Service Management Processes, Operational Level Agreements, and Underpinning Contracts, are appropriate for the agreed Service Level Targets. SLM monitors and reports on Service Levels, and holds regular Customer reviews.


• • • ••



Service Level Package (SLP) (Service Strategy) A defined level of Utility and Warranty for a particular Service Package. Each SLP is designed to meet the needs of a particular Pattern of Business Activity. See Line of Service.

Service Level Requirement (SLR) (Service Design) (Continual Service Improvement) A Customer Requirement for an aspect of an IT Service. SLRs are based on Business Objectives and are used to negotiate agreed Service Level Targets.

Service Level Target (Service Design) (Continual Service Improvement) A commitment that is documented in a Service Level Agreement. Service Level Targets are based on Service Level Requirements, and are needed to ensure that the IT Service design is Fit for Purpose. Service Level Targets should be SMART, and are usually based on KPIs.

Service Maintenance Objective (Service Operation) The expected time that a Configuration Item will be unavailable due to planned maintenance Activity.

Service Management Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.

Service Management Lifecycle An approach to IT Service Management that emphasizes the importance of coordination and Control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous Improvement of IT Services.

Service Manager A manager who is responsible for managing the end-to-end Lifecycle of one or more IT Services. The term Service Manager is also used to mean any manager within the IT Service Provider. Most commonly used to refer to a Business Relationship Manager, a Process Manager, an Account Manager or a senior manager with responsibility for IT Services overall.

Service Operation (Service Operation) A stage in the Lifecycle of an IT Service. Service Operation includes a number of Processes and Functions and is the title of one of the Core ITIL publications. See Operation.

Service Owner (Continual Service Improvement) A Role which is accountable for the delivery of a specific IT Service.

Service Package (Service Strategy) A detailed description of an IT Service that is available to be delivered to Customers. A Service Package includes a Service Level Package and one or more Core Services and Supporting Services.

Service Pipeline (Service Strategy) A database or structured Document listing all IT Services that are under consideration or Development, but are not yet available to Customers. The Service Pipeline provides a Business view of possible future IT Services and is part of the Service Portfolio which is not normally published to Customers.

Service Portfolio (Service Strategy) The complete set of Services that are managed by a Service Provider. The Service Portfolio is used to manage the entire Lifecycle of all Services, and includes three Categories: Service Pipeline (proposed or in Development);


• • •••



Service Catalogue (Live or available for Deployment); and Retired Services. See Service Portfolio Management, Contract Portfolio.

Service Portfolio Management (SPM) (Service Strategy) The Process responsible for managing the Service Portfolio. Service Portfolio Management considers Services in terms of the Business value that they provide.

Service Potential (Service Strategy) The total possible value of the overall Capabilities and Resources of the IT Service Provider.

Service Provider (Service Strategy) An Organization. supplying Services to one or more Internal Customers or External Customers. Service Provider is often used as an abbreviation for IT Service Provider. See Type I Service Provider, Type II Service Provider, Type III Service Provider.

Service Provider Interface (SPI) (Service Strategy) An interface between the IT Service Provider and a User, Customer, Business Process, or a Supplier. Analysis of Service Provider Interfaces helps to coordinate end-to-end management of IT Services.

Service Provisioning Optimization (SPO) (Service Strategy) Analyzing the finances and constraints of an IT Service to decide if alternative approaches to Service delivery might reduce Costs or improve Quality.

Service Reporting (Continual Service Improvement) The Process responsible for producing and delivering reports of achievement and trends against Service Levels. Service Reporting should agree the format, content and frequency of reports with Customers.

Service Request (Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted. See Request Fulfillment

Service Sourcing (Service Strategy) The Strategy and approach for deciding whether to provide a Service internally or to Outsource it to an External Service Provider. Service Sourcing also means the execution of this Strategy. Service Sourcing includes:

• Internal Sourcing - Internal or Shared Services using Type I or Type II Service Providers.

• Traditional Sourcing - Full Service Outsourcing using a Type III Service Provider.

• Multivendor Sourcing - Prime, Consortium or Selective Outsourcing using Type III Service Providers.

Service Strategy (Service Strategy) The title of one of the Core ITIL publications. Service Strategy establishes an overall Strategy for IT Services and for IT Service Management.

Service Transition (Service Transition) A stage in the Lifecycle of an IT Service. Service Transition includes a number of Processes and Functions and is the title of one of the Core ITIL publications. See Transition.


• • • ••



Service Utility (Service Strategy) The Functionality of an IT Service from the Customer's perspective. The Business value of an IT Service is created by the combination of Service Utility (what the Service does) and Service Warranty (how well it does it). See Utility.

Service Validation and Testing (Service Transition) The Process responsible for Validation and Testing of a new or Changed IT Service. Service Validation and Testing ensures that the IT Service matches its Design Specification and will meet the needs of the Business.

Service Valuation (Service Strategy) A measurement of the total Cost of delivering an IT Service, and the total value to the Business of that IT Service. Service Valuation is used to help the Business and the IT Service Provider agree on the value of the IT Service.

Service Warranty (Service Strategy) Assurance that an IT Service will meet agreed Requirements. This may be a formal Agreement such as a Service Level Agreement or Contract, or may be a marketing message or brand image. The Business value of an IT Service is created by the combination of Service Utility (what the Service does) and Service Warranty (how well it does it). See Warranty.

Serviceability (Service Design) (Continual Service Improvement) The ability of a Third Party Supplier to meet the terms of their Contract. This Contract will include agreed levels of Reliability, Maintainability or Availability for a Configuration Item.

Shift (Service Operation) A group or team of people who carry out a specific Role for a fixed period of time. For example there could be four shifts of IT Operations Control personnel to support an IT Service that is used 24 hours a day.

Simulation Modeling (Service Design) (Continual Service Improvement) A technique that creates a detailed Model to predict the behavior of a Configuration Item or IT Service. Simulation Models can be very accurate but are expensive and time consuming to create. A Simulation Model is often created by using the actual Configuration Items that are being modeled, with artificial Workloads or Transactions. They are used in Capacity Management when accurate results are important. A simulation model is sometimes called a Performance Benchmark.

Single Point of Contact (Service Operation) Providing a single consistent way to communicate with an Organization. or Business Unit. For example, a Single Point of Contact for an IT Service Provider is usually called a Service Desk.

Single Point of Failure (SPOF) (Service Design) Any Configuration Item that can cause an Incident when it fails, and for which a Countermeasure has not been implemented. A SPOF may be a person, or a step in a Process or Activity, as well as a Component of the IT Infrastructure. See Failure.

SLAM Chart (Continual Service Improvement) A Service Level Agreement Monitoring Chart is used to help monitor and report achievements against Service Level Targets. A SLAM Chart is typically color coded to show whether each agreed Service Level Target has been met, missed, or nearly missed during each of the previous 12 months.


• • •••



SMART (Service Design) (Continual Service Improvement) An acronym for helping to remember that targets in Service Level Agreements and Project Plans should be Specific, Measurable, Achievable, Relevant and Timely.

Snapshot (Service Transition) The current state of a Configuration as captured by a discovery tool. Also used as a synonym for Benchmark. See Baseline.

Source See Service Sourcing.

Specification A formal definition of Requirements. A Specification may be used to define technical or Operational Requirements, and may be internal or external. Many public Standards consist of a Code of Practice and a Specification. The Specification defines the Standard against which an Organization. can be Audited.

Stakeholder All people who have an interest in an Organization., Project, IT Service etc. Stakeholders may be interested in the Activities, targets, Resources, or Deliverables. Stakeholders may include Customers, Partners, employees, shareholders, owners, etc. See RACI.

Standard A mandatory Requirement. Examples include ISO/IEC 20000 (an international Standard), an internal security Standard for Unix configuration, or a government Standard for how financial Records should be maintained. The term Standard is also used to refer to a Code of Practice or Specification published by a Standards Organization. such as ISO or BSI. See Guideline.

Standard Change (Service Transition) A pre-approved Change that is low Risk, relatively common and follows a Procedure or Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request. See Change Model.

Standard Operating Procedures (SOP) (Service Operation) Procedures used by IT Operations Management.

Standby (Service Design) Used to refer to Resources that are not required to deliver the Live IT Services, but are available to support IT Service Continuity Plans. For example a Standby data center may be maintained to support Hot Standby, Warm Standby or Cold Standby arrangements.

Statement of requirements (SOR) (Service Design) A Document containing all Requirements for a product purchase, or a new or changed IT Service. See Terms of Reference.

Status The name of a required field in many types of Record. It shows the current stage in the Lifecycle of the associated Configuration Item, Incident, Problem etc.

Status Accounting (Service Transition) The Activity responsible for recording and reporting the Lifecycle of each Configuration Item.


• • • ••



Storage Management (Service Operation) The Process responsible for managing the storage and maintenance of data throughout its Lifecycle.

Strategic (Service Strategy) The highest of three levels of Planning and delivery (Strategic, Tactical, Operational). Strategic Activities include Objective setting and long term Planning to achieve the overall Vision.

Strategy (Service Strategy) A Strategic Plan designed to achieve defined Objectives.

Super User (Service Operation) A User who helps other Users, and assists in communication with the Service Desk or other parts of the IT Service Provider. Super Users typically provide support for minor Incidents and training.

Supplier (Service Strategy) (Service Design) A Third Party responsible for supplying goods or Services that are required to deliver IT services. Examples of suppliers include commodity hardware and software vendors, network and telecom providers, and Outsourcing Organizations. See Underpinning Contract, Supply Chain.

Supplier and Contract Database (SCD) (Service Design) A database or structured Document used to manage Supplier Contracts throughout their Lifecycle. The SCD contains key Attributes of all Contracts with Suppliers, and should be part of the Service Knowledge Management System.

Supplier Management (Service Design) The Process responsible for ensuring that all Contracts with Suppliers support the needs of the Business, and that all Suppliers meet their contractual commitments.

Supply Chain (Service Strategy) The Activities in a Value Chain carried out by Suppliers. A Supply Chain typically involves multiple Suppliers, each adding value to the product or Service. See Value Network.

Support Group (Service Operation) A group of people with technical skills. Support Groups provide the Technical Support needed by all of the IT Service Management Processes. See Technical Management.

Support Hours (Service Design) (Service Operation) The times or hours when support is available to the Users. Typically this is the hours when the Service Desk is available. Support Hours should be defined in a Service Level Agreement, and may be different from Service Hours. For example, Service Hours may be 24 hours a day, but the Support Hours may be 07:00 to 19:00.

Supporting Service (Service Strategy) A Service that enables or enhances a Core Service. For example a Directory Service or a Backup Service. See Service Package.

SWOT Analysis (Continual Service Improvement) A technique that reviews and analyses the internal strengths and weaknesses of an Organization. and the external opportunities and threats which it faces SWOT stands for Strengths, Weaknesses, Opportunities and Threats.


• • •••



System A number of related things that work together to achieve an overall Objective. For example:

• A computer System including hardware, software and Applications.

• A management System, including multiple Processes that are planned and managed together. For example a Quality Management System.

• Database Management System or Operating System that includes many software modules that are designed to perform a set of related Functions.

System Management The part of IT Service Management that focuses on the management of IT Infrastructure rather than Process.

Tactical The middle of three levels of Planning and delivery (Strategic, Tactical, Operational). Tactical Activities include the medium term Plans required to achieve specific Objectives, typically over a period of weeks to months.

Tag (Service Strategy) A short code used to identify a Category. For example tags EC1, EC2, EC3 etc. might be used to identify different Customer outcomes when analyzing and comparing Strategies. The term Tag is also used to refer to the Activity of assigning Tags to things.

Technical Management (Service Operation) The Function responsible for providing technical skills in support of IT Services and management of the IT Infrastructure. Technical Management defines the Roles of Support Groups, as well as the tools, Processes and Procedures required.

Technical Observation (TO) (Continual Service Improvement) A technique used in Service Improvement, Problem investigation and Availability Management. Technical support staff meet to monitor the behavior and Performance of an IT Service and make recommendations for improvement.

Technical Service Synonym for Infrastructure Service.

Technical Support Synonym for Technical Management.

Tension Metrics (Continual Service Improvement) A set of related Metrics, in which improvements to one Metric have a negative effect on another. Tension Metrics are designed to ensure that an appropriate balance is achieved.

Terms of Reference (TOR) (Service Design) A Document specifying the Requirements, Scope, Deliverables, Resources and schedule for a Project or Activity.

Test (Service Transition) An Activity that verifies that a Configuration Item, IT Service, Process, etc. meets its Specification or agreed Requirements. See Service Validation and Testing, Acceptance.

Test Environment (Service Transition) A controlled Environment used to Test Configuration Items, Builds, IT Services, Processes etc.


• • • ••



Third Party A person, group, or Business who is not part of the Service Level Agreement for an IT Service, but is required to ensure successful delivery of that IT Service. For example a software Supplier, a hardware maintenance company, or a facilities department. Requirements for Third Parties are typically specified in Underpinning Contracts or Operational Level Agreements.

Third-line Support (Service Operation) The third level in a hierarchy of Support Groups involved in the resolution of Incidents and investigation of Problems. Each level contains more specialist skills, or has more time or other Resources.

Threat Anything that might exploit a Vulnerability. Any potential cause of an Incident can be considered to be a Threat. For example a fire is a Threat that could exploit the Vulnerability of flammable floor coverings. This term is commonly used in Information Security Management and IT Service Continuity Management, but also applies to other areas such as Problem and Availability Management.

Threshold The value of a Metric which should cause an Alert to be generated, or management action to be taken. For example "Priority1 Incident not solved within 4 hours", "more than 5 soft disk errors in an hour", or "more than 10 failed changes in a month".

Throughput (Service Design) A measure of the number of Transactions, or other Operations, performed in a fixed time. For example 5000 emails sent per hour, or 200 disk I/Os per second.

Total Cost of Ownership (TCO) (Service Strategy) A methodology used to help make investment decisions. TCO assesses the full Lifecycle Cost of owning a Configuration Item, not just the initial Cost or purchase price. See Total Cost of Utilization.

Total Cost of Utilization (TCU) (Service Strategy) A methodology used to help make investment and Service Sourcing decisions. TCU assesses the full Lifecycle Cost to the Customer of using an IT Service. See Total Cost of Ownership.

Total Quality Management (TQM) (Continual Service Improvement) A methodology for managing continual Improvement by using a Quality Management System. TQM establishes a Culture involving all people in the Organization. in a Process of continual monitoring and improvement.

Transaction A discrete Function performed by an IT Service. For example transferring money from one bank account to another. A single Transaction may involve numerous additions, deletions and modifications of data. Either all of these complete successfully or none of them is carried out.

Transition (Service Transition) A change in state, corresponding to a movement of an IT Service or other Configuration Item from one Lifecycle status to the next.

Transition Planning and Support (Service Transition) The Process responsible for Planning all Service Transition Processes and coordinating the resources that they require. These Service Transition Processes are Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation, and Knowledge Management.


• • •••



Trend Analysis (Continual Service Improvement) Analysis of data to identify time related patterns. Trend Analysis is used in Problem Management to identify common Failures or fragile Configuration Items, and in Capacity Management as a Modeling tool to predict future behavior It is also used as a management tool for identifying deficiencies in IT Service Management Processes.

Tuning The Activity responsible for Planning Changes to make the most efficient use of Resources. Tuning is part of Performance Management, which also includes Performance Monitoring and implementation of the required Changes.

Type I Service Provider (Service Strategy) An Internal Service Provider that is embedded within a Business Unit. There may be several Type I Service Providers within an Organization.

Type II Service Provider (Service Strategy) An Internal Service Provider that provides shared IT Services to more than one Business Unit.

Type III Service Provider (Service Strategy) A Service Provider that provides IT Services to External Customers.

Underpinning Contract (UC) (Service Design) A Contract between an IT Service Provider and a Third Party. The Third Party provides goods or Services that support delivery of an IT Service to a Customer. The Underpinning Contract defines targets and responsibilities that are required to meet agreed Service Level Targets in an SLA.

Unit Cost (Service Strategy) The Cost to the IT Service Provider of providing a single Component of an IT Service. For example the Cost of a single desktop PC, or of a single Transaction.

Urgency (Service Transition) (Service Design) A measure of how long it will be until an Incident, Problem or Change has a significant Impact on the Business. For example a high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the financial year. Impact and Urgency are used to assign Priority.

Usability (Service Design) The ease with which an Application, product, or IT Service can be used. Usability Requirements are often included in a Statement of Requirements.

Use Case (Service Design) A technique used to define required functionality and Objectives, and to Design Tests. Use Cases define realistic scenarios that describe interactions between Users and an IT Service or other System. See Change Case.

User A person who uses the IT Service on a day-to-day basis. Users are distinct from Customers, as some Customers do not use the IT Service directly.

User Profile (UP) (Service Strategy) A pattern of User demand for IT Services. Each User Profile includes one or more Patterns of Business Activity.

Utility (Service Strategy) Functionality offered by a Product or Service to meet a particular need. Utility is often summarized as "what it does". See Service Utility.


• • • ••



Validation (Service Transition) An Activity that ensures a new or changed IT Service, Process, Plan, or other Deliverable meets the needs of the Business. Validation ensures that Business Requirements are met even though these may have changed since the original Design. See Verification, Acceptance, Qualification, Service Validation and Testing.

Value Chain (Service Strategy) A sequence of Processes that creates a product or Service that is of value to a Customer. Each step of the sequence builds on the previous steps and contributes to the overall product or Service. See Value Network.

Value for Money An informal measure of Cost Effectiveness. Value for Money is often based on a comparison with the Cost of alternatives. See Cost Benefit Analysis.

Value Network (Service Strategy) A complex set of Relationships between two or more groups or organizations. Value is generated through exchange of knowledge, information, goods or Services. See Value Chain, Partnership.

Value on Investment (VOI) (Continual Service Improvement) A measurement of the expected benefit of an investment. VOI considers both financial and intangible benefits. See Return on Investment.

Variable Cost (Service Strategy) A Cost that depends on how much the IT Service is used, how many products are produced, the number and type of Users, or something else that cannot be fixed in advance. See Variable Cost Dynamics.

Variable Cost Dynamics (Service Strategy) A technique used to understand how overall Costs are impacted by the many complex variable elements that contribute to the provision of IT Services.

Variance The difference between a planned value and the actual measured value. Commonly used in Financial Management, Capacity Management and Service Level Management, but could apply in any area where Plans are in place.

Verification (Service Transition) An Activity that ensures a new or changed IT Service, Process, Plan, or other Deliverable is complete, accurate, Reliable and matches its Design Specification. See Validation, Acceptance, Service Validation and Testing.

Verification and Audit (Service Transition) The Activities responsible for ensuring that information in the CMDB is accurate and that all Configuration Items have been identified and recorded in the CMDB. Verification includes routine checks that are part of other Processes. For example, verifying the serial number of a desktop PC when a User logs an Incident. Audit is a periodic, formal check.

Version (Service Transition) A Version is used to identify a specific Baseline of a Configuration Item. Versions typically use a naming convention that enables the sequence or date of each Baseline to be identified. For example Payroll Application Version 3 contains updated functionality from Version 2.

Vision A description of what the Organization. intends to become in the future. A Vision is created by senior management and is used to help influence Culture and Strategic Planning.


• • •••



Vital Business Function (VBF) (Service Design) A Function of a Business Process which is critical to the success of the Business. Vital Business Functions are an important consideration of Business Continuity Management, IT Service Continuity Management and Availability Management.

Vulnerability A weakness that could be exploited by a Threat. For example an open firewall port, a password that is never changed, or a flammable carpet. A missing Control is also considered to be a Vulnerability.

Warm Standby Synonym for Intermediate Recovery.

Warranty (Service Strategy) A promise or guarantee that a product or Service will meet its agreed Requirements. See Service Validation and Testing, Service Warranty.

Work in Progress (WIP) A Status that means Activities have started but are not yet complete. It is commonly used as a Status for Incidents, Problems, Changes etc.

Work Instruction A Document containing detailed instructions that specify exactly what steps to follow to carry out an Activity. A Work Instruction contains much more detail than a Procedure and is only created if very detailed instructions are needed.

Workaround (Service Operation) Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record.

Workload The Resources required to deliver an identifiable part of an IT Service. Workloads may be Categorized by Users, groups of Users, or Functions within the IT Service. This is used to assist in analyzing and managing the Capacity, Performance and Utilization of Configuration Items and IT Services. The term Workload is sometimes used as a synonym for Throughput.


• • • ••



• • • ••

B-1

Appendix B: ITIL V3 Practice Examination

In this section you can take a practice ITIL Foundations v3 examination. Doing well on this examination does not guarantee that you will pass the certification examination. However, it should give you a good indication of the areas that require further study.

1. What is the best description for the ITIL V3 core?

a. An operations lifecycle

b. An IT Management lifecycle

c. A Service lifecycle

d. An Infrastructure lifecycle

2. Which aspect of Service Design is missing from the following list?

– The design of services

– The design of Service Management systems and tool

– The design of technology architecture and management systems

– The design of the processes required

a. The design of functions

b. The design of Service Level Agreements

c. The design of applications

d. The design of measurement systems, methods, and metrics

3. Which of the following roles is responsible for identifying opportunities for improvement?

– 1. Service Owner

– 2. Continual Service Improvement (CSI) Manager

– 3. Process Owner

a. 1 and 2 only

b. 1 and 3 only

c. All of the above

d. 2 and 3 only

B-2 IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••



4. Learning and improvement is the primary concern of which of the following elements of the Service Lifecycle?

a. Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement

b. Service Strategy, Service Transition, and Service Operation

c. Service Operation and Continual Service Improvement

d. Continual Service Improvement

5. Which of the following statements is the most appropriate approach to carrying out Service Operations?

a. The internal IT view is most important as Service Operations has to monitor and manage the infrastructure.

b. Service Operations should maintain a balance between an internal IT view and an external business view.

c. The external business view is the most important because Service Operations is the place where value is realized and the customer obtains the benefit of the services.

d. IT Operations does not take an internal or external view as they execute processes defined by Service Design.

6. Which of the following statements about the Service Desk are correct?

– 1. The Service Desk is a function that provides a means of communication between IT and its users for all operational issues.

– 2. The Service Desk is always the owner of the Incident Management process.

a. 2 only

b. 1 only

c. All of the above

d. None of the above

7. How does an organization use resources and capabilities in creating value?

a. They are used to create value in the form of output for Production Management.

b. They are used to create value in the form of goods and services.

c. They are used to create value to the IT organization for Service Support.

d. They are used to create value to the IT organization for Service Delivery.

©Copyright IBM Corp. 2009 IT Infrastructure Library (ITIL) Foundations v3 B-3

• • •••



8. In which core publication can you find detailed descriptions of the following items?

– Service Portfolio Management

– Demand Management

– Financial Management

a. Service Operations

b. Service Strategy



9. Which of the following statements best describes the role of communication during Service Operation?

a. Communication is defined as part of all processes and is performed in Service Operation.

b. Communication is a separate process that must be defined and executed with Service Operation.

c. Good communication is essential for successful Service Operation, just as it is for any other phase of the lifecycle.

d. Communication is more important in Service Operation than in any other stage of the Service Lifecycle.

10. A Process Owner is responsible for which of the following items?

a. Purchasing tools to support the process

b. Ensuring that targets specified in an SLA are met

c. Carrying out activities defined in the process

d. Monitoring and improving the process

11. For what purpose is Demand Management primarily used?

a. Increase customer value

b. Eliminate excess capacity needs

c. Increase the value of IT

d. Align business with IT cost


• • • ••



12. Which of the following statements is not an advantage of organizing Continual Service Improvement (CSI) using the RACI model?

a. Facilitates clear communication and workflow practice across all parties involved in the CSI program

b. Clarifies the roles and responsibilities of individual in the CSI program that might otherwise be overlapping and confusing

c. Identifies where internal Service Level Agreements (SLAs) can be established to implement CSI

d. Provides a clear focus for matching the CSI processes to financial planning

13. Which of the following statements are objectives of the Release and Deployment Management process?

– 1. To ensure there are clear release and deployment plans

– 2. To ensure that skills and knowledge are transferred to operations and support staff

– 3. To ensure there is minimal unpredicted impact on production services

– 4. To provide cost justifiable IT capacity that is matched to the needs of the business

a. 1, 2, and 3 only

b. All of the above

c. 1 and 3 only

d. 1, 3 and 4 only

14. Which of the following questions is not answered by Service Portfolio Management?

a. How should the resources and capabilities be allocated?

b. What opportunities are there in the market?

c. Why should a customer buy these services?

d. What are the pricing or chargeback models?


• • •••



15. Which of the following statements are not included in Access Management?

– 1. Verifying the identity of users requesting access to services

– 2. Setting the rights or privileges of systems to permit access to authorized users

– 3. Defining security policies for system access

– 4. Monitoring the availability of systems that users should have access to

a. 2 and 4 only

b. 1 and 3 only

c. 2 and 3 only

d. 1 and 2 only

16. What task is not the responsibility of Application Management?

a. Documenting and maintaining the technical skills required to manage and support applications

b. Managing applications through their lifecycle

c. Assisting in the decision to build or buy new software

d. Developing operational functionality required by the business

17. If something cannot be measured, it should not be documented within which of the following items?

a. The Glossary of Terms

b. A Service Level Agreement

c. An Incident Management record

d. A Configuration Item (CI)

18. What is the purpose of the Request Fulfillment process?

a. Dealing with Service Requests from the users

b. Making sure all requests within an IT organization are fulfilled

c. Ensuring fulfillment of Change Requests

d. Making sure the Service Level Agreement is met


• • • ••



19. Which of the following areas can technology help to support during the Service Transition phase of the lifecycle?

– 1. Data mining and workflow tools

– 2. Measurement and reporting systems

– 3. Release and Deployment technology

– 4. Process Design

a. 1, 2, and 3 only

b. 1, 3, and 4 only

c. 2, 3, and 4 only

d. All of the above

20. Which of the following statements is correct about good practice?

a. It can be used to drive an organization forward.

b. It is something that is in wide industry use.

c. It is always documented in international standards.

d. It is always based on ITIL.


• • •••



Practice Examination Answer Key

The Correct answers to the following questions appear in bold text.

1. What is the best description for the ITIL V3 core?

a. An operations lifecycle

b. An IT Management lifecycle

c. A Service lifecycle

d. An Infrastructure lifecycle

2. Which aspect of Service Design is missing from the following list?

– The design of services

– The design of Service Management systems and tool

– The design of technology architecture and management systems

– The design of the processes required

a. The design of functions

b. The design of Service Level Agreements

c. The design of applications

d. The design of measurement systems, methods, and metrics

3. Which of the following roles is responsible for identifying opportunities for improvement?

– 1. Service Owner

– 2. Continual Service Improvement (CSI) Manager

– 3. Process Owner

a. 1 and 2 only

b. 1 and 3 only

c. All of the above

d. 2 and 3 only


• • • ••



4. Learning and improvement is the primary concern of which of the following elements of the Service Lifecycle?

a. Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement

b. Service Strategy, Service Transition, and Service Operation

c. Service Operation and Continual Service Improvement


5. Which of the following statements is the most appropriate approach to carrying out Service Operations?

a. The internal IT view is most important as Service Operations has to monitor and manage the infrastructure.

b. Service Operations should maintain a balance between an internal IT view and an external business view.

c. The external business view is the most important because Service Operations is the place where value is realized and the customer obtains the benefit of the services.

d. IT Operations does not take an internal or external view as they execute processes defined by Service Design.

6. Which of the following statements about the Service Desk are correct?

– 1. The Service Desk is a function that provides a means of communication between IT and its users for all operational issues.

– 2. The Service Desk is always the owner of the Incident Management process.

a. 2 only

b. 1 only

c. All of the above

d. None of the above

7. How does an organization use resources and capabilities in creating value?

a. They are used to create value in the form of output for Production Management.

b. They are used to create value in the form of goods and services.

c. They are used to create value to the IT organization for Service Support.

d. They are used to create value to the IT organization for Service Delivery.


• • •••



8. In which core publication can you find detailed descriptions of the following items?

– Service Portfolio Management

– Demand Management

– Financial Management

a. Service Operations

b. Service Strategy



9. Which of the following statements best describes the role of communication during Service Operation?

a. Communication is defined as part of all processes and is executed in Service Operation.

b. Communication is a separate process that needs to be defined and executed with Service Operation.

c. Good communication is essential for successful Service Operation, just as it is for any other phase of the lifecycle.

d. Communication is more important in Service Operation than in any other stage of the Service Lifecycle.

10. A Process Owner is responsible for which of the following items?

a. Purchasing tools to support the process

b. Ensuring that targets specified in an SLA are met

c. Carrying out activities defined in the process

d. Monitoring and improving the process

11. For what purpose is Demand Management primarily used?

a. Increase customer value

b. Eliminate excess capacity needs

c. Increase the value of IT

d. Align business with IT cost


• • • ••



12. Which of the following statements is not an advantage of organizing Continual Service Improvement (CSI) using the RACI model?

a. Facilitates clear communication and workflow practice across all parties involved in the CSI program

b. Clarifies the roles and responsibilities of individual in the CSI program which might otherwise be overlapping and confusing

c. Identifies where internal Service Level Agreements (SLAs) can be established to implement CSI

d. Provides a clear focus for matching the CSI processes to financial planning

13. Which of the following statements are objectives of the Release and Deployment Management process?

– 1. To ensure there are clear release and deployment plans

– 2. To ensure that skills and knowledge are transferred to operations and support staff

– 3. To ensure there is minimal unpredicted impact on production services

– 4. To provide cost justifiable IT capacity that is matched to the needs of the business

a. 1, 2, and 3 only

b. All of the above

c. 1 and 3 only

d. 1, 3, and 4 only

14. Which of the following questions is not answered by Service Portfolio Management?

a. How should the resources and capabilities be allocated?

b. What opportunities are there in the market?

c. Why should a customer buy these services?

d. What are the pricing or chargeback models?


• • •••



15. Which of the following statements are not included in Access Management?

– 1. Verifying the identity of users requesting access to services

– 2. Setting the rights or privileges of systems to permit access to authorized users

– 3. Defining security policies for system access

– 4. Monitoring the availability of systems that users should have access to

a. 2 and 4 only

b. 1 and 3 only

c. 2 and 3 only

d. 1 and 2 only

16. What task is not the responsibility of Application Management?

a. Documenting and maintaining the technical skills required to manage and support Applications

b. Managing applications through their lifecycle

c. Assisting in the decision to build or buy new software

d. Developing operational functionality required by the business

17. If something cannot be measured, it should not be documented within which of the following items?

a. The Glossary of Terms

b. A Service Level Agreement

c. An Incident Management record

d. A Configuration Item (CI)

18. What is the purpose of the Request Fulfillment process?

a. Dealing with Service Requests from the users

b. Making sure all requests within an IT organization is fulfilled

c. Ensuring fulfillment of Change Requests

d. Making sure the Service Level Agreement is met


• • • ••



19. Which of the following areas can technology help to support during the Service Transition phase of the lifecycle?

– 1. Data mining and workflow tools

– 2. Measurement and reporting systems

– 3. Release and Deployment technology

– 4. Process Design

a. 1, 2, and 3 only

b. 1, 3, and 4 only

c. 2, 3, and 4 only

d. All of the above

20. Which of the following statements is correct about good practice?

a. It can be used to move an organization forward.

b. It is something that is in wide industry use.

c. It is always documented in international standards.

d. It is always based on ITIL.

• • • ••

I

Tivoli Professional Certification

“As an individual, becoming a Tivoli Certified Professional has helped me to progress further in my career and gain job satisfaction. To the company, it has helped build up the confidence and trust to the customer. At the end of the day, you win, the company wins, and the customer wins.”

Special Offer for Having Taken This CourseNow through 31 January 2009: For having completed this course, you are entitled to a 15% discount on your next exam at any Thomson Prometric testing center worldwide. Use this special promotion code when registering online or by telephone to receive the discount: 15CSWR. (This offer might be withdrawn. Check with the testing center as described later in this section.)

Reasons for Certification• It is a demonstration of value to your customer through increased overall

performance with shorter time cycles to deliver applications.

• Technical certifications assist technical professionals to obtain more visibility to potential customers.

• Differentiate your skills and knowledge from other non-IBM Certified professionals.

Role-based CertificationAll IBM certifications are based on job roles. They focus on a job a person must do with a product, not just the product’s features and functions. The job roles used by Tivoli Professional Certification include:

• IBM Certified Advanced Deployment Professional

• IBM Certified Deployment Professional

• IBM Certified Administrator

• IBM Certified Solution Advisor

• IBM Certified Specialist

• IBM Certified Operator

II IT Infrastructure Library (ITIL) Foundations v3 ©Copyright IBM Corp. 2009

• • • ••

Tivoli Professional Certification


When to Attempt a Certification ExamAfter completing this course, you should review the test objectives and sample test on the IBM Certification Web site (URL follows) that correspond with the exam you want to take. Exams are based on real-world and hands-on experience for the specific certification role. As an example, for the Deployment Certifications a general guideline is to play a major role in at least two product deployments, so that you have as much hands-on experience working with the product as possible before you attempt a deployment exam. Exam questions are written by experts in the deployment of this product and most of the material covered is taken from their experience working with the product in real world commercial environments. You will find supplemental readings and other study material on the Web site as well.

Location and CostAll IBM certification exams are available at Thomson Prometric testing centers worldwide. In addition, testing is offered at a discount or for free at many IBM conferences and events, including many Tivoli User Group (TUG) meetings. Exam costs vary in different parts of the world. See the Thomson Prometric Web sites for the exact cost at the testing center you plan to use.

IBM employees receive a special discount if they take an exam using the PRIME tool at any IBM location.

A PRIME proctor is required and not all locations have proctors. For more information and a current list of proctors, see the PRIME URL that follows.

Sources of Additional Information• The Tivoli Certification Program

http://www.ibm.com/certify/ or e-mail at [email protected]

• The Tivoli Certification e-Newsletter (sent out monthly)Subscribe at [email protected]

• Tivoli Certification Study Guideshttp://www.redbooks.ibm.com (search for “certification study guide”)

• Tivoli Support Technical Exchange Callshttp://www.ibm.com/software/sysmgmt/products/support/supp_tech_exch.html

• Tivoli Certification Study GroupsSend an e-mail inquiry to [email protected]

• Thomson Prometric testing centershttp://www.prometric.com

• IBM PRIME testing and proctor information (IBM employees only)http://w3-103.ibm.com/software/xl/portal/viewcontent?type=doc&srcID=XT&docID=P101658X09146A52

itil book from ibm, it service management

Documents

trademarks of ibm corporation

permission of ibm corporation

ibm products

tivoli products

ibm customer

planet tivoli

tivoli enterprise

tivoli ready