PRM-IT v3.0 Reference Library

PRM-IT V3 Reference Library - Consolidated
PRM-IT Version 3.0

April, 2008
PRM - IT
IBM Process Reference Model for IT
Sequencing the DNA of IT Management
Copyright Notice
Copyright © April, 2008 IBM Corporation, including this documentation and all software. All rights
reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM
Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License
Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a
retrieval system, or translated into any computer language, in any form or by any means, electronic,
mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of
IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other
reproductions of any machine-readable documentation for your own use, provided that each such
reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are
granted without prior written permission of IBM Corporation. The document is not intended for
production and is furnished “as is” without warranty of any kind. All warranties on this document are
hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose.
Note to U.S. Government Users—Documentation related to restricted rights—Use, duplication or
disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.
Trademarks
IBM, the IBM logo, the On Demand Business logo, Tivoli, the Tivoli logo, and WebSphere are
trademarks or registered trademarks of International Business Machines Corporation in the United
States, other countries or both.
The following are trademarks of IBM Corporation or Tivoli Systems Inc.: IBM, Tivoli, AIX, Cross-Site,
NetView, OS/2, Planet Tivoli, RS/6000, Tivoli Certified, Tivoli Enterprise, Tivoli Ready, TME. In
Denmark, Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.
IT Infrastructure Library® and ITIL® are registered trademarks of the UK’s Office of Government
Commerce.
© Crown copyright material is reproduced with the permission of the Controller of HMSO and
Queen's Printer for Scotland.
Capability Maturity Model® and CMM® are registered in the U.S. Patent and Trademark Office by
Carnegie Mellon University, CMM IntegrationSM is a service mark of Carnegie Mellon University, and
CMMI® is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.
Control Objectives for Information and related Technology® (COBIT) and Information Systems Audit
and Control Association® are trademarks of the Information Systems Audit and Control Association
(ISACA) and the IT Governance Institute.
Other company, product, and service names may be trademarks or service marks of others.
Notices
References in this publication to Tivoli Systems or IBM products, programs, or services do not imply
that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to
these products, programs, or services is not intended to imply that only Tivoli Systems or IBM
products, programs, or services can be used. Subject to valid intellectual property or other legally
protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service
can be used instead of the referenced product, program, or service. The evaluation and verification
of operation in conjunction with other products, except those expressly designated by Tivoli Systems
or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent
applications covering subject matter in this document. The furnishing of this document does not give
you any license to these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A.
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -i
About this book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -i
General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-1

Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-1
Introducing the IBM Process Reference Model for IT . . . . . . . . . . . . . . . . . . . . . . GIM-2
Growth targets at risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-2
Beyond ITIL: Driving IT management process excellence . . . . . . . . . . . . . . . . . GIM-4
Dimensions of IT management process excellence. . . . . . . . . . . . . . . . . . . . . . GIM-4
Principles and design points for the model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-6
Design points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-6
Alignment with ITIL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-7
Alignment with other reference frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-8
A first look at the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-12
The context and scope of PRM-IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-13
Drilling into the model: The process categories . . . . . . . . . . . . . . . . . . . . . . . . GIM-14
The processes for the business of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-15
Mapping PRM-IT processes to ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-16
The value of this process reference model . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-17
How to use this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-18
Model Categories and Processes in IDEFØ . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-19
[A0] Manage IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-20
Model Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-20
Viewpoint of the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-20
The context for the business of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-20
[A1] Governance and Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-23
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-23
[A11] IT Governance and Management System Framework . . . . . . . . . . . . . . GIM-24
[A12] IT Governance and Management System Capabilities. . . . . . . . . . . . . . GIM-25
[A13] IT Governance and Management System Operation . . . . . . . . . . . . . . . GIM-27
[A14] IT Governance and Management System Evaluation . . . . . . . . . . . . . . GIM-28
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-28
[A2] Customer Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-29
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-29
[A21] Stakeholder Requirements Management . . . . . . . . . . . . . . . . . . . . . . . . GIM-30
[A22] Service Marketing and Sales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-31
[A23] Service Catalog Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-32
[A24] Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-34
[A25] Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-35
[A26] IT Customer Transformation Management . . . . . . . . . . . . . . . . . . . . . . . GIM-37
[A27] Customer Satisfaction Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-38
[A3] Direction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-40
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-40
[A31] IT Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-41
[A32] IT Research and Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-42
[A33] Architecture Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-43
[A34] Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-45
[A35] Product Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-47
[A36] Portfolio Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-48
[A37] Program and Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-50
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • 1
•
•
This material may not be reproduced in whole or in part without the prior written permission of IBM.
[A4] Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-52
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-52
[A41] Solution Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-53
[A42] Solution Analysis and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-54
[A43] Solution Development and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-56
[A44] Solution Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-57
[A45] Solution Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-58
[A5] Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-60
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-60
[A51] Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-61
[A52] Release Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-63
[A53] Deployment Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-65
[A54] Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-67
[A55] Asset Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-70
[A6] Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-73
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-73
[A61] Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-74
[A62] Service Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-76
[A63] Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-77
[A64] Event Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-78
[A65] Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-80
[A66] Problem Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-81
[A67] Identity and Access Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-82
[A7] Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-85
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-85
[A71] Compliance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-86
[A72] Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-87
[A73] Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-88
[A74] Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-90
[A75] Facilities Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-91
[A76] IT Service Continuity Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-93
[A8] Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-95
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-95
[A81] Financial Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-96
[A82] Supplier Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-97
[A83] Service Pricing and Contract Administration. . . . . . . . . . . . . . . . . . . . . . GIM-98
[A84] Workforce Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-99
[A85] Knowledge Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-101
[A0] Manage IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-1

Model Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-1
Viewpoint of the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-1
The context for the business of IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-1
Context and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-4
[A1] Governance and Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-8
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-8
[A2] Customer Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-11
[A3] Direction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-17
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-17
[A4] Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-23
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-23
[A5] Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-28
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-28
•
•
2 • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
[A6] Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-33
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-33
[A7] Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-38
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-38
[A8] Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-44
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-44
PRM-IT High Level Node Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-49
[A1] Governance and Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-1
[A11] IT Governance and Management System Framework . . . . . . . . . . . . . . . . . A1-4
[A111] Define IT Governance Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-8
[A112] Define IT Management Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-9
[A113] Establish IT Management Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-10
[A114] Establish IT Management Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-11
[A12] IT Governance and Management System Capabilities . . . . . . . . . . . . . . . . A1-14
[A121] Establish IT Governance Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-18
[A122] Establish IT Process Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-20
[A123] Establish IT Organizational Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . A1-22
[A124] Establish IT Management Information Capabilities. . . . . . . . . . . . . . . . . A1-24
[A125] Establish IT Operational Environment Capabilities. . . . . . . . . . . . . . . . . A1-26
[A126] Establish IT Measurement and Control Capabilities . . . . . . . . . . . . . . . . A1-28
[A13] IT Governance and Management System Operation . . . . . . . . . . . . . . . . . A1-30
[A131] Produce IT Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-34
[A132] Operate IT Governance and Management System Controls . . . . . . . . . A1-35
[A133] Monitor, Analyze and Report IT Outcomes. . . . . . . . . . . . . . . . . . . . . . . A1-37
[A14] IT Governance and Management System Evaluation . . . . . . . . . . . . . . . . . A1-39
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-39
[A141] Collate IT Management System Outcomes . . . . . . . . . . . . . . . . . . . . . . A1-43
[A142] Analyze IT Governance and Management System Performance. . . . . . A1-44
[A143] Audit IT Governance and Management . . . . . . . . . . . . . . . . . . . . . . . . . A1-46
[A144] Communicate IT Governance and Management System Performance . A1-47
PRM-IT A1 Node Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-49
[A2] Customer Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-1
[A21] Stakeholder Requirements Management . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-4
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-4
[A211] Establish Stakeholder Requirements Management Framework. . . . . . . . A2-7
[A212] Capture Stakeholder Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-8
[A213] Transform Needs into Stakeholder Requirements . . . . . . . . . . . . . . . . . . A2-8
[A214] Monitor and Report Stakeholder Needs and Requirements . . . . . . . . . . A2-10
[A215] Evaluate Stakeholder Requirements Management Performance. . . . . . A2-11
[A22] Service Marketing and Sales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-12
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-12
[A221] Establish Service Marketing and Sales Framework . . . . . . . . . . . . . . . . A2-17
[A222] Analyze Market Wants and Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-18
[A223] Create Marketing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-20
[A224] Execute Marketing Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-22
[A225] Manage Opportunities and Forecast Sales. . . . . . . . . . . . . . . . . . . . . . . A2-23
[A226] Consult and Propose Services Solutions . . . . . . . . . . . . . . . . . . . . . . . . A2-24
[A227] Negotiate and Close Services Opportunity . . . . . . . . . . . . . . . . . . . . . . . A2-26
[A228] Analyze and Report Marketing and Sales Results . . . . . . . . . . . . . . . . . A2-27
[A229] Evaluate Service Marketing and Sales Performance . . . . . . . . . . . . . . . A2-28
•
•
•
•
[A23] Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-29
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-29
[A231] Establish Service Catalog Management Framework . . . . . . . . . . . . . . . A2-33
[A232] Define Service Package Catalog Requirements. . . . . . . . . . . . . . . . . . . A2-34
[A233] Build and Maintain Service Catalog Content . . . . . . . . . . . . . . . . . . . . . A2-35
[A234] Create and Maintain Service Catalog Views. . . . . . . . . . . . . . . . . . . . . . A2-36
[A235] Publish Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-38
[A236] Monitor, Analyze and Report Service Catalog . . . . . . . . . . . . . . . . . . . . A2-39
[A237] Evaluate Service Catalog Management Performance . . . . . . . . . . . . . . A2-40
[A24] Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-41
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-41
[A241] Establish Service Level Management Framework . . . . . . . . . . . . . . . . . A2-47
[A242] Develop Service Level Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-48
[A243] Create and Maintain Service Level Agreements. . . . . . . . . . . . . . . . . . . A2-50
[A244] Monitor and Report Service Level Achievements . . . . . . . . . . . . . . . . . . A2-53
[A245] Conduct Service Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-56
[A246] Formulate Service Improvement Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . A2-58
[A247] Evaluate Service Level Management Performance . . . . . . . . . . . . . . . . A2-61
[A25] Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-62
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-62
[A251] Establish Demand Management Framework . . . . . . . . . . . . . . . . . . . . . A2-67
[A252] Value and Classify Business Demands . . . . . . . . . . . . . . . . . . . . . . . . . A2-68
[A253] Consolidate Business Demand Patterns and Forecasts. . . . . . . . . . . . . A2-69
[A254] Forecast Service Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-70
[A255] Identify and Plan Demand Management Initiatives. . . . . . . . . . . . . . . . . A2-72
[A256] Assess and Report Demand Management Outcomes . . . . . . . . . . . . . . A2-75
[A257] Evaluate Demand Management Performance . . . . . . . . . . . . . . . . . . . . A2-77
[A26] IT Customer Transformation Management . . . . . . . . . . . . . . . . . . . . . . . . . A2-78
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-78
[A261] Establish IT Customer Transformation Management Framework . . . . . A2-83
[A262] Understand IT Customer Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-84
[A263] Identify IT Customer Transformation Opportunities . . . . . . . . . . . . . . . . A2-85
[A264] Develop IT Customer Transformation Proposal . . . . . . . . . . . . . . . . . . . A2-86
[A265] Enable and Promote IT Customer Capability Adoption . . . . . . . . . . . . . A2-88
[A266] Optimize IT Customer Benefit Realization . . . . . . . . . . . . . . . . . . . . . . . A2-90
[A267] Evaluate IT Customer Transformation Management Performance . . . . A2-92
[A27] Customer Satisfaction Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-93
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-93
[A271] Establish Customer Satisfaction Management Framework . . . . . . . . . . A2-97
[A272] Capture Customer Satisfaction Data . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-99
[A273] Analyze Customer Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-99
[A274] Manage Customer Satisfaction Issue Resolution . . . . . . . . . . . . . . . . . A2-102
[A275] Assess Customer Satisfaction Patterns . . . . . . . . . . . . . . . . . . . . . . . . A2-103
[A276] Communicate Customer Satisfaction Management Results. . . . . . . . . A2-104
[A277] Evaluate Customer Satisfaction Management Performance . . . . . . . . A2-105
PRM-IT A2 Node Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-106
[A3] Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-1
[A31] IT Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-4
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-4
[A311] Establish IT Strategy Process Framework . . . . . . . . . . . . . . . . . . . . . . . . A3-8
[A312] Understand Business Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-9
[A313] Determine IT Strategic Potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-10
•
•
•
•
[A314] Develop IT Strategy Initiatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-12
[A315] Consolidate and Communicate IT Strategy . . . . . . . . . . . . . . . . . . . . . . A3-14
[A316] Monitor and Assess IT Strategy Effectiveness . . . . . . . . . . . . . . . . . . . . A3-15
[A317] Evaluate IT Strategy Process Performance . . . . . . . . . . . . . . . . . . . . . . A3-16
[A32] IT Research and Innovation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-17
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-17
[A321] Establish IT Research and Innovation Framework . . . . . . . . . . . . . . . . . A3-20
[A322] Identify IT Research and Innovation Candidates . . . . . . . . . . . . . . . . . . A3-21
[A323] Qualify Candidates and Define IT Research and Innovation Projects . . A3-22
[A324] Perform IT Research and Innovation Project . . . . . . . . . . . . . . . . . . . . . A3-23
[A325] Promote IT Research and Innovation Results . . . . . . . . . . . . . . . . . . . . A3-25
[A326] Evaluate IT Research and Innovation Performance . . . . . . . . . . . . . . . . A3-26
[A33] Architecture Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-27
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-27
[A331] Establish Architecture Management Framework . . . . . . . . . . . . . . . . . . A3-32
[A332] Review Overall Environment and Architecture . . . . . . . . . . . . . . . . . . . . A3-33
[A333] Create and Maintain Architecture Models. . . . . . . . . . . . . . . . . . . . . . . . A3-34
[A334] Define and Maintain Architecture Baselines and Roadmaps . . . . . . . . . A3-36
[A335] Promote Architecture Transition Initiatives . . . . . . . . . . . . . . . . . . . . . . . A3-38
[A336] Govern Architecture Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-39
[A337] Evaluate Architecture Management Performance . . . . . . . . . . . . . . . . . A3-41
[A34] Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-42
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-42
[A341] Establish Risk Management Framework . . . . . . . . . . . . . . . . . . . . . . . . A3-46
[A342] Identify Threats, Vulnerabilities and Risks . . . . . . . . . . . . . . . . . . . . . . . A3-47
[A343] Assess Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-48
[A344] Define Risk Mitigation Plans and Countermeasures. . . . . . . . . . . . . . . . A3-49
[A345] Enact and Operate Risk Countermeasures . . . . . . . . . . . . . . . . . . . . . . A3-50
[A346] Assess and Report Risk Mitigation Results . . . . . . . . . . . . . . . . . . . . . . A3-51
[A347] Evaluate Risk Management Performance . . . . . . . . . . . . . . . . . . . . . . . A3-52
[A35] Product Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-53
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-53
[A351] Establish Product Management Framework . . . . . . . . . . . . . . . . . . . . . . A3-58
[A352] Formulate Product Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-58
[A353] Plan and Control Product Lifecycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-60
[A354] Initiate and Oversee Product Realization . . . . . . . . . . . . . . . . . . . . . . . . A3-62
[A355] Guide Product Transition and Operation . . . . . . . . . . . . . . . . . . . . . . . . A3-64
[A356] Monitor and Assess Product Performance . . . . . . . . . . . . . . . . . . . . . . . A3-66
[A357] Evaluate Product Management Performance . . . . . . . . . . . . . . . . . . . . . A3-67
[A36] Portfolio Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-68
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-68
[A361] Establish Portfolio Management Framework . . . . . . . . . . . . . . . . . . . . . A3-73
[A362] Inventory IT Projects and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-74
[A363] Create and Maintain IT Portfolio Categories. . . . . . . . . . . . . . . . . . . . . . A3-75
[A364] Assess and Prioritize IT Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-76
[A365] Make IT Portfolio Decisions and Commitments . . . . . . . . . . . . . . . . . . . A3-78
[A366] Conduct IT Portfolio Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-80
[A367] Communicate IT Business Value and IT Portfolio Performance. . . . . . . A3-81
[A37] Program and Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-83
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-83
[A371] Establish Program and Project Management Framework . . . . . . . . . . . A3-87
[A372] Manage Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-88
[A373] Define and Initiate Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-90
[A374] Plan Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-91
•
•
•
•
[A375] Track and Report Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-92
[A376] Control Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-94
[A377] Close Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-95
[A378] Evaluate Program and Project Management Performance . . . . . . . . . . A3-96
[A4] Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-1
[A41] Solution Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-4
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-4
[A411] Establish Solution Requirements Framework . . . . . . . . . . . . . . . . . . . . . . A4-9
[A412] Refine and Verify Business Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-10
[A413] Document and Analyze Solution Requirements . . . . . . . . . . . . . . . . . . . A4-12
[A414] Validate Solution Requirements with Stakeholders . . . . . . . . . . . . . . . . A4-15
[A415] Manage Solution Requirements Baseline. . . . . . . . . . . . . . . . . . . . . . . . A4-17
[A416] Evaluate Solution Requirements Performance . . . . . . . . . . . . . . . . . . . . A4-18
[A42] Solution Analysis and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-19
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-19
[A421] Establish Solution Analysis and Design Framework. . . . . . . . . . . . . . . . A4-23
[A422] Create Conceptual Solution Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-24
[A423] Identify and Select Solution Components . . . . . . . . . . . . . . . . . . . . . . . . A4-26
[A424] Create Detailed Solution Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-28
[A425] Validate Solution Design with Stakeholders . . . . . . . . . . . . . . . . . . . . . . A4-30
[A426] Evaluate Solution Analysis and Design Performance. . . . . . . . . . . . . . . A4-31
[A43] Solution Development and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-32
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-32
[A431] Establish Solution Development and Integration Framework . . . . . . . . . A4-36
[A432] Define Solution Development and Integration Plan . . . . . . . . . . . . . . . . A4-37
[A433] Prepare Solution Development and Integration Environment. . . . . . . . . A4-38
[A434] Acquire or Create Solution Components . . . . . . . . . . . . . . . . . . . . . . . . A4-39
[A435] Integrate Solution Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-41
[A436] Refine and Tune Integrated Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-43
[A437] Verify Integrated Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-44
[A438] Evaluate Solution Development and Integration Performance . . . . . . . . A4-46
[A44] Solution Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-47
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-47
[A441] Establish Solution Test Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-51
[A442] Develop Solution Test Strategy and Plans . . . . . . . . . . . . . . . . . . . . . . . A4-52
[A443] Prepare and Manage Solution Test Environment . . . . . . . . . . . . . . . . . . A4-54
[A444] Perform Solution Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-55
[A445] Analyze and Report Solution Test Results . . . . . . . . . . . . . . . . . . . . . . . A4-56
[A446] Evaluate Solution Test Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-57
[A45] Solution Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-59
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-59
[A451] Establish Solution Acceptance Framework. . . . . . . . . . . . . . . . . . . . . . . A4-64
[A452] Create Solution Acceptance Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-65
[A453] Define Solution Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-66
[A455] Certify Solution Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-69
[A456] Package Certified Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-70
[A457] Evaluate Solution Acceptance Performance. . . . . . . . . . . . . . . . . . . . . . A4-71
[A5] Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-1
•
•
•
•
[A51] Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-4
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-4
[A511] Establish Change Management Framework. . . . . . . . . . . . . . . . . . . . . . A5-10
[A512] Create and Record Change Request . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-12
[A513] Accept and Categorize Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-13
[A514] Assess Change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-15
[A515] Authorize and Schedule Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-17
[A516] Coordinate Change Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-19
[A517] Review and Close Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-21
[A518] Monitor and Report Change Management . . . . . . . . . . . . . . . . . . . . . . . A5-22
[A519] Evaluate Change Management Performance. . . . . . . . . . . . . . . . . . . . . A5-24
[A52] Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-25
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-25
[A521] Establish Release Management Framework . . . . . . . . . . . . . . . . . . . . . A5-30
[A522] Plan Release Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-32
[A523] Design and Build Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-35
[A524] Test and Verify Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-37
[A525] Monitor and Report Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-39
[A526] Review and Close Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-41
[A527] Evaluate Release Management Performance . . . . . . . . . . . . . . . . . . . . A5-42
[A53] Deployment Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-43
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-43
[A531] Establish Deployment Management Framework . . . . . . . . . . . . . . . . . . A5-48
[A532] Plan Deployment Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-49
[A533] Prepare Deployment Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-52
[A534] Perform Transition Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-53
[A535] Perform Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-56
[A536] Verify Deployment and Activate Service. . . . . . . . . . . . . . . . . . . . . . . . . A5-59
[A537] Review and Close Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-61
[A538] Monitor and Report Deployment Program . . . . . . . . . . . . . . . . . . . . . . . A5-62
[A539] Evaluate Deployment Management Performance . . . . . . . . . . . . . . . . . A5-64
[A54] Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-65
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-65
[A541] Establish Configuration Management Framework . . . . . . . . . . . . . . . . . A5-71
[A542] Identify Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-72
[A543] Control Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-74
[A544] Report Configuration Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-76
[A545] Verify and Audit Configuration Items . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-77
[A546] Evaluate Configuration Management Performance . . . . . . . . . . . . . . . . A5-79
[A55] Asset Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-80
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-80
[A551] Establish Asset Management Framework . . . . . . . . . . . . . . . . . . . . . . . A5-84
[A552] Ready and Control Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-85
[A553] Control Asset Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-87
[A554] Monitor, Audit and Reconcile Asset Records . . . . . . . . . . . . . . . . . . . . . A5-88
[A555] Oversee Asset Contracts and Financials . . . . . . . . . . . . . . . . . . . . . . . . A5-90
[A556] Retire and Dispose of Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-91
[A557] Report Asset Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-92
[A558] Evaluate Asset Management Performance . . . . . . . . . . . . . . . . . . . . . . A5-93
[A6] Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-1
[A61] Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-4
[A611] Establish Request Fulfillment Framework. . . . . . . . . . . . . . . . . . . . . . . . . A6-9
•
•
•
•
[A612] Receive and Approve Service Request . . . . . . . . . . . . . . . . . . . . . . . . . A6-11
[A613] Fulfill or Route Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-13
[A614] Close Service Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-15
[A615] Own, Monitor, Track and Communicate Service Requests . . . . . . . . . . A6-17
[A616] Evaluate Request Fulfillment Performance. . . . . . . . . . . . . . . . . . . . . . . A6-20
[A62] Service Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-21
[A621] Establish Service Execution Framework. . . . . . . . . . . . . . . . . . . . . . . . . A6-26
[A622] Schedule and Adjust Workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-28
[A623] Assign and Control Delivery Resources . . . . . . . . . . . . . . . . . . . . . . . . . A6-30
[A624] Deliver Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-32
[A625] Monitor and Report Service Execution Operations. . . . . . . . . . . . . . . . . A6-34
[A626] Evaluate Service Execution Performance. . . . . . . . . . . . . . . . . . . . . . . . A6-35
[A63] Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-36
[A631] Establish Data Management Framework . . . . . . . . . . . . . . . . . . . . . . . . A6-41
[A632] Plan Data Portfolio Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-42
[A633] Acquire and Prepare Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-44
[A634] Control, Deploy and Maintain Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-45
[A635] Backup and Restore Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-48
[A636] Dispose of Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-49
[A637] Monitor and Report Data Management Operations . . . . . . . . . . . . . . . . A6-51
[A638] Evaluate Data Management Performance . . . . . . . . . . . . . . . . . . . . . . . A6-52
[A64] Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-53
[A641] Establish Event Management Framework . . . . . . . . . . . . . . . . . . . . . . . A6-57
[A642] Detect and Log Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-60
[A643] Filter Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-61
[A644] Correlate Events and Select Response . . . . . . . . . . . . . . . . . . . . . . . . . A6-62
[A645] Resolve Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-63
[A646] Close Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-65
[A647] Evaluate Event Management Performance . . . . . . . . . . . . . . . . . . . . . . A6-66
[A65] Incident Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-67
[A651] Establish Incident Management Framework. . . . . . . . . . . . . . . . . . . . . . A6-72
[A652] Identify and Log Incident. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-74
[A653] Classify Incident and Provide Initial Support. . . . . . . . . . . . . . . . . . . . . . A6-75
[A654] Investigate and Diagnose Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-76
[A655] Resolve Incident and Recover Service . . . . . . . . . . . . . . . . . . . . . . . . . . A6-78
[A656] Close Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-79
[A657] Own, Monitor, Track and Communicate Incidents . . . . . . . . . . . . . . . . . A6-80
[A658] Evaluate Incident Management Performance. . . . . . . . . . . . . . . . . . . . . A6-81
[A66] Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-82
[A661] Establish Problem Management Framework . . . . . . . . . . . . . . . . . . . . . A6-86
[A662] Detect and Log Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-88
[A663] Categorize and Prioritize Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-90
[A664] Investigate and Diagnose Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-91
[A665] Resolve Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-93
[A666] Close and Review Problem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-95
[A667] Monitor, Track and Report Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-96
[A668] Evaluate Problem Management Performance . . . . . . . . . . . . . . . . . . . . A6-99
[A67] Identity and Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-100
[A671] Establish Identity and Access Management Framework . . . . . . . . . . . A6-104
[A672] Evaluate and Verify Identity and Access Request . . . . . . . . . . . . . . . . A6-106
[A673] Create and Maintain Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-107
[A674] Provide and Maintain Access Rights . . . . . . . . . . . . . . . . . . . . . . . . . . A6-108
[A675] Monitor and Report Identity and Access . . . . . . . . . . . . . . . . . . . . . . . . A6-110
[A676] Evaluate Identity and Access Management Performance . . . . . . . . . . A6-111
•
•
•
•
PRM-IT A6 Node Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-112
[A7] Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-1
[A71] Compliance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-4
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-4
[A711] Establish Compliance Management Framework . . . . . . . . . . . . . . . . . . . A7-7
[A712] Identify Compliance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-8
[A713] Assess Compliance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-9
[A714] Define Compliance Controls Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-10
[A715] Implement Compliance Controls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-11
[A716] Audit and Report Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-12
[A717] Evaluate Compliance Management Performance . . . . . . . . . . . . . . . . . A7-14
[A72] Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-15
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-15
[A721] Establish Security Management Framework . . . . . . . . . . . . . . . . . . . . . A7-20
[A722] Produce and Maintain Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . A7-21
[A723] Analyze Security Threats, Vulnerabilities and Risks. . . . . . . . . . . . . . . . A7-22
[A724] Classify Information Asset Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-24
[A725] Plan and Implement Security Practices . . . . . . . . . . . . . . . . . . . . . . . . . A7-25
[A726] Operate Security Protection Mechanisms. . . . . . . . . . . . . . . . . . . . . . . . A7-26
[A727] Monitor, Assess, Audit and Report Security . . . . . . . . . . . . . . . . . . . . . . A7-28
[A728] Evaluate Security Management Performance . . . . . . . . . . . . . . . . . . . . A7-31
[A73] Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-32
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-32
[A731] Establish Availability Management Framework . . . . . . . . . . . . . . . . . . . A7-36
[A732] Determine Availability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-38
[A733] Formulate Availability and Recovery Design Criteria . . . . . . . . . . . . . . . A7-39
[A734] Define and Implement Availability Targets and Related Measures . . . . A7-40
[A735] Monitor, Analyze and Report Availability . . . . . . . . . . . . . . . . . . . . . . . . A7-42
[A736] Investigate Unavailability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-43
[A737] Produce Availability Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-44
[A738] Evaluate Availability Management Performance . . . . . . . . . . . . . . . . . . A7-46
[A74] Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-47
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-47
[A741] Establish Capacity Management Framework . . . . . . . . . . . . . . . . . . . . . A7-51
[A742] Model and Size Capacity Requirements. . . . . . . . . . . . . . . . . . . . . . . . . A7-53
[A743] Monitor, Analyze and Report Capacity Usage . . . . . . . . . . . . . . . . . . . . A7-56
[A744] Supervise Tuning and Capacity Delivery . . . . . . . . . . . . . . . . . . . . . . . . A7-58
[A745] Produce and Maintain Capacity Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-61
[A746] Evaluate Capacity Management Performance . . . . . . . . . . . . . . . . . . . . A7-63
[A75] Facilities Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-65
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-65
[A751] Establish Facilities Management Framework . . . . . . . . . . . . . . . . . . . . . A7-70
[A752] Plan Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-71
[A753] Manage Facility Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-73
[A754] Operate and Maintain Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-75
[A755] Evaluate Facilities Management Performance . . . . . . . . . . . . . . . . . . . . A7-76
[A76] IT Service Continuity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-78
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-78
[A761] Establish IT Service Continuity Management Framework . . . . . . . . . . . A7-82
[A762] Identify Business Service Continuity Requirements . . . . . . . . . . . . . . . . A7-84
[A763] Create and Maintain IT Service Continuity Strategy . . . . . . . . . . . . . . . . A7-85
[A764] Create and Maintain IT Service Continuity Plan . . . . . . . . . . . . . . . . . . . A7-87
•
•
•
•
[A765] Prepare IT Service Continuity Capability . . . . . . . . . . . . . . . . . . . . . . . . A7-89
[A766] Execute IT Service Continuity Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-91
[A767] Evaluate IT Service Continuity Management Performance . . . . . . . . . . A7-93
[A8] Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-1

Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-1
[A81] Financial Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-4
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-4
[A811] Establish Financial Management Framework . . . . . . . . . . . . . . . . . . . . . . A8-9
[A812] Perform Financial Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-10
[A813] Plan and Control Budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-12
[A814] Perform Financial Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-14
[A815] Administer Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-18
[A816] Audit Financials. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-20
[A817] Evaluate Financial Management Performance . . . . . . . . . . . . . . . . . . . . A8-22
[A82] Supplier Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-23
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-23
[A821] Establish Supplier Management Framework . . . . . . . . . . . . . . . . . . . . . A8-27
[A822] Manage Portfolio of Suppliers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-29
[A823] Manage Supplier Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-31
[A824] Manage Procurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-33
[A825] Evaluate Supplier Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-35
[A826] Provide Supplier Product and Service Information . . . . . . . . . . . . . . . . . A8-37
[A827] Evaluate Supplier Management Performance . . . . . . . . . . . . . . . . . . . . A8-38
[A83] Service Pricing and Contract Administration . . . . . . . . . . . . . . . . . . . . . . . . A8-39
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-39
[A831] Establish Service Pricing and Contract Administration Framework . . . . A8-42
[A832] Collect Pricing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-44
[A833] Provide Price Alternatives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-45
[A834] Administer Customer Contract/ Agreement . . . . . . . . . . . . . . . . . . . . . . A8-46
[A835] Monitor Pricing Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-49
[A836] Evaluate Service Pricing and Contract Administration Performance . . . A8-50
[A84] Workforce Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-51
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-51
[A841] Establish Workforce Management Framework . . . . . . . . . . . . . . . . . . . . A8-55
[A842] Forecast and Plan Workforce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-56
[A843] Administer Human Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-58
[A844] Manage Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-59
[A845] Evaluate Workforce Management Performance . . . . . . . . . . . . . . . . . . . A8-61
[A85] Knowledge Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-62
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-62
[A851] Establish Knowledge Management Framework . . . . . . . . . . . . . . . . . . . A8-65
[A852] Create and Maintain Knowledge Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . A8-66
[A853] Acquire Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-68
[A854] Evaluate and Structure Knowledge. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-69
[A855] Disseminate Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-70
[A856] Monitor, Assess and Report Knowledge Status . . . . . . . . . . . . . . . . . . . A8-71
[A857] Evaluate Knowledge Management Performance . . . . . . . . . . . . . . . . . . A8-72
IDEFØ Node Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-1

A0 – Manage IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-2
A1 – Governance and Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-3
•
•
•
•
A2 – Customer Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-4
A3 – IT Direction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-6
A4 – Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-9
A5 – Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-11
A6 – Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-13
A7 – Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-15
A8 – Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-17
IDEFØ Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1

A0: Manage IT – Context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-2
A0: Manage IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-3
A1 Governance and Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-4
A11 IT Governance and Management System Framework . . . . . . . . . . . . . . . . . D-5
A12 IT Governance and Management System Capabilities . . . . . . . . . . . . . . . . . D-6
A13 IT Governance and Management System Operation. . . . . . . . . . . . . . . . . . . D-7
A14 IT Governance and Management System Evaluation . . . . . . . . . . . . . . . . . . D-8
A2 Customer Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-9
A21 Stakeholder Requirements Management. . . . . . . . . . . . . . . . . . . . . . . . . . . D-10
A22 Service Marketing and Sales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-11
A23 Service Catalog Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-12
A24 Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-13
A25 Demand Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-14
A26 IT Customer Transformation Management . . . . . . . . . . . . . . . . . . . . . . . . . D-15
A27 Customer Satisfaction Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-16
A3 Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-17
A31 IT Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-18
A32 IT Research and Innovation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-19
A33 Architecture Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-20
A34 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-21
A35 Product Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-22
A36 Portfolio Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-23
A37 Program and Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-24
A4 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-25
A41 Solution Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-26
A42 Solution Analysis and Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-27
A43 Solution Development and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-28
A44 Solution Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-29
A45 Solution Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-30
A5 Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-31
A51 Change Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-32
A52 Release Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-33
A53 Deployment Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-34
A54 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-35
A55 Asset Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-36
A6 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-37
A61 Request Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-38
A62 Service Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-39
A63 Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-40
A64 Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-41
A65 Incident Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-42
A66 Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-43
A67 Identity and Access Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-44
A7 Resilience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-45
A71 Compliance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-46
•
•
•
•
A72 Security Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-47
A73 Availability Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-48
A74 Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-49
A75 Facilities Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-50
A76 IT Service Continuity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-51
A8 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-52
A81 Financial Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-53
A82 Supplier Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-54
A83 Service Pricing and Contract Administration . . . . . . . . . . . . . . . . . . . . . . . . D-55
A84 Workforce Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-56
A85 Knowledge Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-57
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-1
•
•
•
•
•
•
•
•
•
•
•
•
Preface
The IBM Process Reference Model for Information Technology (PRM-IT) is a generic
representation of the processes involved across the complete IT management domain. It
contains a foundational examination of the IT process topic. It is for this reason the
graphical image of the DNA double helix over the basic building block of a cell is used.
About this book

As a reference manual, this book provides a detailed examination of the process categories
that comprise the full model. It is not intended to be read in a sequential fashion.
Each reference manual begins with a summarization of the category, and then further
considers each process in turn and the activities within each process.
Details are provided for:
The definition of each activity
Each control, input and output
The sources and destinations of each control, input, and output (thereby showing
the model linkages)
The full IDEF0 diagram for each category and each process is included.
The final page is a breakdown of the PRM-IT node tree for this category.
Intended audience
An understanding of the full range of the processes relevant to IT in any business is of value
to those within the IT function responsible for the specification, creation, and delivery of IT
services (whether at the CIO or IT executive level), and who consider the direction and
overall management of IT. Or, individuals who work within any of its competencies, needing
to interface with other parts of the IT value chain or value net.
Equally, the stakeholders in the business of this IT capability will benefit from greater insight
into how IT serves them. This insight will enable them to better influence IT decisions and
activities, to their ultimate benefit.
Next steps
PRM-IT is a powerful management tool for purposes of investigating and identifying areas
for improvement. PRM-IT also provides a proven starting-point for the design and
implementation of new and upgraded IT management capabilities.
IBM IT consultants, architects, and specialists in global services who, working from this
common base, are equipped with a full range of methods, techniques, and tools to assist
its customers achieve their purposes.
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • i
•
•
•
•
ii • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
General Information
Purpose
This book provides general information describing the processes identified in IBM’s Process
Reference Model for IT (PRM-IT) version one. PRM-IT describes the processes for exploiting IT in
support of a business or enterprise. The processes described comprise Level A of the overall
reference framework, Unified Process Framework for IT (UPF-IT).
Figure 1. Unified Process Framework for IT (UPF-IT)
The reference model is a tool that can be employed in a variety of ways, like process scoping and
assessment, and as a base for design and implementation. The model is IBM intellectual capital
and is provided under normal copyright provisions.
Outlined in this book is the underlying integrated IDEFØ1 model, which contains every process, its
child activities, and the relationships between them. This book does not describe a method to apply
this reference artifact.
A companion book set, the Reference Manual Library, expands on this general information by
including the IDEFØ modeling. The library includes a model glossary, containing a definition of
each activity and relationship item to the process definitions described.
1. FIPS 183: Integration Definition for Function Modeling, December 1993.

•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • GIM - 1
•
•
Introducing the IBM Process Reference Model for IT
Growth targets at risk

Executives are increasingly concerned that traditional sources of earnings growth cannot deliver
the results necessary to reach announced profit targets across the next five years. Initial plans to
reach those targets through incremental improvements in top and bottom-line performance are
showing signs of weakness.
Several years of cost cutting and rollouts of productivity initiatives now leave little room for further
material improvement of operating margins at most firms. After years of cost-cutting and efficiency
campaigns, business leaders in companies of every size and across the industry spectrum are
refocused on top line growth—and they are seeing innovation as the means to achieve it. With
globalization, commoditization, and technological advances, all forcing significant change on the
business, these organizations are being compelled to act in order to gain a competitive advantage.
They know that exponential growth lies ahead for those who can lead the innovation movement
and seize opportunities to differentiate themselves.
IBM’s Global CEO Study 20062 was conducted to understand how CEOs view innovation, to
capture current insights, and to learn what is on their innovation agendas. The study indicates that
CEOs are expanding the innovation horizon. In fact, there is a categorical shift toward a more
expansive and unconventional view of innovation, as well as a need for a greater mix of innovation
types. While CEOs still believe that product, service, and operational innovations are important,
they feel that innovation must also be applied to a company’s very core to the way it does business.
Based on this study, three key considerations emerged for CIOs:3
Deep business model innovation is critical
Product, service, and operational innovations remain important, but competitive pressures
have pushed business model innovation much higher on the CEO’s innovation agenda.
Companies that can substantially change how they add value to their own or other
industries differentiate themselves and gain a competitive edge. It is important to note the
CEOs consider the IT organization as an important part of the enterprise. When the CEO’s
talk about deep business model innovation, they are including the CIO’s domain.
External collaboration is indispensable
CEOs stressed the overwhelming importance of collaborative innovation, not just internally
across traditional silos, but also externally beyond company walls. Business partners and
customers were cited as top external sources for innovative ideas.
Innovation can be ignited by business and technology integration
Technology can enable and drive innovation. But to truly capitalize on technology’s
potential and unleash an organization’s creative energy, technology know how must be
combined with its business and marketing insights. CEOs view consistent business and
technology integration as crucial to innovation.
CEOs were also asked to identify their top ten inhibitors to innovation. 2 shows the results. It is
apparent that the majority of issues reside somewhere inside CEO’s own organizations, including
the IT organization controlled by the CIO. Culture, budget, people and process were cited as some
of the most significant hurdles. The last two internal items should be of particular interest to CIOs.
2. The IBM Global CEO Study 2006. Survey 05 765 CEOs. See http://www-935.ibm.com/services/us/gbs/bus/html/
bcs_ceostudy2006.html?re=bcsstrategychange
3. "CEOs are expanding the innovation horizon: important implications for CIOs." CIO perspectives from the IBM
Global CEO Study. See http://www-935.ibm.com/services/us/imc/html/cio-implica-
tions.html?ca=WMYS&re=GTSHub#-2
•
•
GIM- 2 • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
CEOs identified Inflexible physical and IT infrastructure and Insufficient access [to
information] as two of the top ten obstacles to innovation.
External Internal
Government and other Unsupportive culture
legal restrictions and climate
Limited funding for
Economic uncertainty investment
Inadequate enabling Internal workforce issues

technologies
Process immaturity
External workforce issues
Inflexible physical and IT

infrastructure Within CIOs'
direct control
Insufficient access
to information
40 30 20 10 0 0 10 20 30 40
(Percent of respondents)
Figure 2. Top ten inhibitors to innovation
All too often, it is not just the physical infrastructure which is inflexible, but the IT organization itself.
Clearly, the IT organization needs to become more agile and flexible to support and enable the
business goals of the CEO. And for the organization, the path to flexibility and innovation starts
with a robust enterprise architecture, including process standardization. While that might seem like
a dichotomy, the patchwork collection of internal tools, ad hoc processes, and non-standard
interfaces are what make many IT infrastructures inflexible. By adopting standards, the amount of
time required for integration of new resources, and integrating with new business partners, is
actually decreased, providing faster time to value.
At a high level, one could view the IT business model as the interaction of people, processes, and
technology for the purpose of achieving specified business goals. The IT organization is
responsible for a number of technical processes, and each requires a specific degree of interaction
with the business. Each is executed by one or more people, often from different parts of the
organization. If the processes are not adequately aligned to the needs of the business, achieving
business goals can be difficult. With customer centricity as a guiding principle, the processes can
be redefined, changing the way IT works within the company and increasing IT’s ability to innovate
in ways that positively impact the business.
To assist IT organizations in this critical challenge, IBM developed the Process Reference Model
for IT.
•
•
•
•
Beyond ITIL: Driving IT management process excellence

The Information Technology Infrastructure Library (ITIL) was developed by the United Kingdom’s
Office of Government Commerce (OGC), with the input of many organizations, including IBM,
beginning in the late 1980s. ITIL V2, developed largely in the late 1990s, gained worldwide
prominence for its treatment of service management and influenced the establishment of the ISO/
IEC 20000 standards.
ITIL is very much aimed at identifying best practices. ITIL describes a systematic approach to
creating a service oriented culture and practice for IT service management. The ITIL library
emphasizes the central importance of meeting business requirements economically.
In May 2007, ITIL V3 was released at the culmination of a several year project involving global
consultation (on requirements and strategy for the revision) and contribution to the ultimate
content. Now known just as 'ITIL,' rather than the original words behind the acronym, V3 has used
the organizing concept of the Service Lifecycle to strengthen the description of the contribution that
service management can and should make to delivering value from IT services.
The increased emphasis that this gives to understanding the implications of managing services as
early as possible, and preferably as a key strategic criterion, is perhaps the major added value of
V3. Nevertheless, IT organizations will need to look beyond ITIL to understand the full set of IT
management process disciplines that are central to delivering on the growth agenda. There are
considerations beyond service management that must be tackled in parallel. These considerations
include identification of optimal IT contributions to business processes, establishing and managing
architectures, application development and maintenance, and infrastructure development and
maintenance.
In the PRM-IT model, IBM has supplemented the content of ITIL V3 based on its extensive IT
Management experience across the full range of IT considerations—experience from managing
thousands of IT environments, both large and small. The Process Reference Model for IT identifies
the set of IT management processes required to move beyond a singular cost focus to principled
decision making that accounts for changing business and technology conditions while managing
existing systems complexity.
Dimensions of IT management process excellence

From cost to beyond: The portfolio lens
The most accomplished firms at IT management treat the function as less an art than a science, a
standardized set of activities that can be measured and improved upon over time. Process
frameworks are valuable tools, having already proven effective in many other business domains,
such as manufacturing, accounting, or customer service, to name a few. To optimize
organizational routines, it is necessary to identify and document the processes involved and their
associated activities: where they start and stop, what they include and exclude, how they interact
with one another, what resources are being allocated, and whether the investment in those
resources is paying off. A process model for IT management provides a frame of reference against
which an organization can assess whether it is doing the right things and whether it is doing those
things right.
There are currently a variety of process frameworks and quality management systems for
managing IT. Some of the more popular IT-specific frameworks include IT Infrastructure Library
(ITIL); the Software Engineering Institute’s System Engineering Capability Maturity Model (CMMI);
and Control Objectives for Information and Related Technology (CobiT). Others such as Six
Sigma, ISO 9000, and the Malcolm Baldrige Award are often leveraged in IT as part of a firm-wide
initiative. Meta Group has categorized the frameworks in terms of their intended application:
understanding a broad process change or understanding how to streamline a process. Both
application categories are predominantly focused on driving operational efficiencies in the IT
function.
•
•
•
•
CobiT – provides tools to

assess and measure the
eSCM – describes best
IT processes in a business
practices in IT service provision
sourcing relationships
Baldrige Award – assessment

of seven aspects of process
implementation and results
ITIL – a framework of best
practice guidance for IT service
management
ISO 9000 – requirements on the

design of processes involved in
design and delivery
CMMI – consists of best

practices that address product
development and maintenance
Six Sigma – uses root cause

analysis to identify process
improvements
Figure 3. Frameworks for IT process excellence
PRM-IT evolves IT management process frameworks beyond operational efficiency to investment

optimization. Using a portfolio lens, PRM-IT provides a reference process framework for managing
the investment of people and resources in business technology initiatives intended to materially
increase profitable revenue growth.
CobiT – provides tools to

assess and measure the
eSCM – describes best
IT processes in a business
practices in IT service provision
sourcing relationships
Baldrige Award – assessment

of seven aspects of process
implementation and results
ITIL – a framework of best
practice guidance for IT service
management
ISO 9000 – requirements on the CMMI – consists of best

design of processes involved in practices that address product
design and delivery development and maintenance
Portfolio
PRM-IT:
A process framework for
Six Sigma – uses root cause managing the investment of
analysis to identify process
people and resources in
improvements
business technology initiatives
intended materially to
increase profitable revenue growth.
Figure 4. Adding PRM-IT to the process frameworks
•
•
•
•
Principles and design points for the model

Guiding principles
One key concept of the new process reference model is that IT can be viewed as an essential
component of any business, and that it can be managed as an asset.
The basic hypotheses, or guiding principles, underlying the new process model are:
1. Regardless of organization or technology, there is a fundamental set of processes
necessary to manage any information technology environment.
2. These processes do not exist or function in isolation, but in fact they interrelate and interact
with one another.
3. There is no single, verifiable correct process decomposition or any means of demonstrating
that a particular treatment of IT processes is always superior to any alternative treatment.
Implementation specific context will always be required to make those judgments.
4. Nevertheless, the well established processes from ITIL represent a de facto standard for
the subset of IT processes, which are known as Service Management.
Design points
PRM-IT is designed to satisfy key design characteristics. These include:
The model is comprehensive
Exhaustive efforts have been made to re-examine the entire IT structure of a business and
design this model so that no fundamental process has been overlooked or excluded. It
should be noted that not every IT entity within every business must engage in every
process described in this model. For example, if a business does not sell its IT services,
internally or externally, it need not be concerned with processes involved in pricing and
contract management for those services. On the other hand, the nature of this model is
comprehensive; we believe that all IT-related processes have been included in this model.
The model is holistic
This model does not treat processes as separate entities, but rather indicates the
interaction and interfaces among them. In any IT delivery structure, the fundamental
processes affect one another. They do not function in isolation. One process might provide
an input to another and receive output from yet another. Changes in one process will have
an effect on other processes, and that effect must be taken into consideration whenever
such changes are contemplated.
The model is neutral with regard to technologies and organizational structure
This model is designed so it can be applied to any IT entity, thus avoiding any implicit
assumptions or biases associated with specific technologies, organizational constructs, or
management theories. By identifying those elements fundamental to any and all
environments, this model provides a common basis for assessment, comparison, process
improvement and management system design, including tool development and selection.
This model is scalable
This model can be applied to any business of any size, from a small, neighborhood branch
office, to the largest IT outsourcing operation. What happens, in terms of IT, in all of these
environments is the same. Only the scale of what happens, how it happens, and who
executes what happens is different.
This model is flexible
This model is not the final word—it is a starting point. Its structure is not rigid but dynamic.
The developers of this model recognize that no two businesses are alike, and any process
model for IT management must be tailored to each business. This model is, therefore,
•
•
•
•
designed so that you can build on it, order it, and customize it to suit your specific IT
environment or situation.
It is not directly implementable
The corollary from all the characteristics is that the model represents a set of foundational
building blocks, which must be developed, populated, and clothed in order to reach the
state required for implementable processes. The nature of reference artifacts means that
they are generic, rather than specific. (See figure 1 “Unified Process Framework for IT
(UPF-IT)” on page 1 for a representation of this positioning.)
There is no preferred place to start
Or, put another way, there is no prescribed sequence to work on process design or
improvement. Using the Pareto principle or a similar approach will help identify the
processes most in need of improvement or that will have the biggest impact on supporting
IT's mission.
The model helps in two ways: first, it provides a concise summary of each selected process
and, second, for those selected processes, it identifies the significant related processes
and points of interaction.
Alignment with ITIL

The model is based on some additional design principles in order to achieve alignment with ITIL
service management.
Explicit process treatments in ITIL V3 are the basis for the equivalent PRM-
IT process
The majority of topics identified in ITIL V3 as a process provide an explicit treatment of the process.
In these cases, key definitions available in the ITIL Glossary4 have been used within the PRM-IT
overall process definition. Further, the activities listed in ITIL have been used for the PRM-IT
activities (within the limitations of engineering them within the IDEF0 notation).
Conversely, there are many considerations covered in best practice documents that are not
relevant to a formal process model, and so they are not included. In particular, this model does not
cover the organizational and process implementation topics covered in the ITIL books.5
PRM-IT provides a formal treatment of the more conceptual process

descriptions in ITIL V3
The strength of the treatment of a number of process topics in ITIL V3 comes from its introduction
of key concepts relating to those processes, and how they contribute to the overall service life
cycle. The process content in these cases is less explicit. For these, PRM-IT provides rigorous
process decomposition and modeling that extends and supplements the ITIL treatment, in a
manner consistent with its principles and precepts.
ITIL processes are presented in a single integrated model, resolving

interfaces between them and with other IT processes
The ITIL best practices, including V3, were not developed from a formal process perspective. For
V2, they were developed by largely independent teams, without a formal architecture. This was
4. The ITIL V3 Glossary can be downloaded from the OGC Best Management Practice Web site at http://www.best-
management-practice.com/officialsite.asp?FO=1230366&action=confirmation&tdi=575004
5. IBM's Component Business Model for the Business of IT provides an organizational context for IT undertakings
as a basis for determining opportunities for investment and improvement.
•
•
•
•
stated as a factor in the inconsistencies which were logged as part of the requirements gathering
phase of ITIL V3.
In spite of this, the industry guidance to the ITIL V3 developers did not place a high priority on
building the V3 books from this kind of foundation, and so a formal ITIL model still does not exist.
PRM-IT provides such a model, covering service management as part of its examination of the full
scope of IT.
In consequence, PRM-IT provides resolutions for any inconsistencies in inputs and outputs
between ITIL processes and, in some cases, fill gaps.
(The outcome of following these alignment design principles is summarized in “Mapping PRM-IT
processes to ITIL” on page 16.)
Alignment with other reference frameworks

PRM-IT is designed to be complementary to serveral other bodies of knowledge, which have
significant contribution to IT management
CMMI
Capability Maturity Model® Integration (CMMI) is a process improvement approach for system
engineering and software engineering. It originates from the Software Engineering Institute of the
Carnegie Mellon University.6
This body of work incorporates several models and provides guidance and assessment on
processes from several perspectives. For PRM-IT, the design point was to ensure that each of the
process areas identified (as required) to achieve Level 3 maturity could be found in PRM-IT.
For reference, these are:
Table 1:
Level Focus Process Areas
– Requirements Management (REQM)
– Project Planning (PP)
– Project Monitoring & Control (PMC)
Basic Project
2 (Managed) – Supplier Agreement Management (SAM)
Management
– Measurement & Analysis (MA)
– Process & Product Quality Assurance (PPQA)
– Configuration Management
– Requirements Development (RD)
– Technical Solution (TS)
– Product Integration (PI)
– Verification (VER)
– Validation (VAL)
Process
3 (Defined) – Organizational Process Focus (OPF)
Standardization
– Organizational Process Definition (OPD)
– Organizational Training (OT)
– Integrated Project Management (IPM)
– Risk Management (RSKM)
– Decision Analysis & Resolution (DAR)
Because maturity levels are cumulative, achievement of Level 3 maturity requires Level 2
attainment also. Level 1 is the start point, and so has not requirements.
6. See http://www.sei.cmu.edu/cmmi/general/index.html for more information on CMMI.

•
•
•
•
COBIT
COBIT®, published by the IT Governance Institute (ITGI) and promoted through the ISACA
(previously known as the Information Systems Audit and Control Association), is a reference body
of knowledge that aims to bridge across control requirements, technical issues, and business
risks.7 It supports the increasing requirements for businesses to comply with regulations and to
manage risks, and thereby contributes to IT governance.
COBIT presents a detailed set of control objectives used to test the degree of governance
embedded into IT activities. The control objectives are organized into 34 processes, across four
domains:
Plan and Organise (PO)
Acquire and Implement (AI)
Deliver and Support (DS)
Monitor and Evaluate (ME)
It has a comprehensive assessment and maturity scheme as the basis for evaluation. Each control
objective maps to one or more PRM-IT processes, with the result that these frameworks are
complementary.
eSourcing Capability Model

The eSourcing Capability Models, one for service providers and one for client organizations, were
developed by a consortium led by Carnegie Mellon University's Information Technology Services
Qualification Center (ITSqc).8
The eSourcing Capability Model for Service Providers (eSCM-SP) was developed specifically to
provide a set of best practices and quality standards for service providers. It is composed of 84
practices associated with successful sourcing relationships. Each practice in the eSCM-SP is
distributed along three dimensions: Sourcing Life-cycle (Phases), Capability Areas, and Capability
Levels as shown in Table 1.
Table 1. Distribution of eSCM Practices by Sourcing Life-cycle Phase, Capability Area, and
Capability Level.
Level
Phase Capability Area Totals
2 3 4
51 Ongoing Knowledge Management 3 4 1 8
People Management 3 7 1 11
Performance Management 3 3 5 11
Relationship Management 3 4 1 8
Technology Management 4 1 1 6
Threat Management 6 1 0 7
21 Initiation Contracting 9 2 0 11
Service Design and Deployment 6 2 0 8
Service Transfer (in) 2 0 0 2
8 Delivery Service Delivery 7 1 0 8
4 Completion Service Transfer (out) 2 1 1 4
Totals 48 26 10 84
Within each practice is a set of activities that should be documented and performed to ensure the
practice objectives are met. The model organization reduces the risk of sourcing failure and
7. See http://www.isaca.org/template.cfm?Section=COBIT6
8. See http://itsqc.cmu.edu/
•
•
•
•
encourages continual improvement. The model also provides a capability determination method
for systematically assessing and improving an organization's capabilities.
The eSCM model's structure complements existing quality models such as ISO-9000, BS 15000,
ISO 17799, the CMMs®, COBIT® and COPC-2000®, so they can be implemented in parallel with
these other frameworks.
Additionally, the eSCM practice activities can all be found within PRM-IT V3.
Component Business Model for the Business of IT

IBM has used the Component Business Modelling approach to create a model that describes the
full scope of the IT business in a single perspective. In other words, aspects of process,
organization, resourcing, and business contribution are treated in combination rather than
individually. The result is a model, CBM-BoIT, ideally suited to strategic decision making on IT
investment. CBM-BoIT uses the PRM-IT set of activities (one level of decomposition beyond the
processes introduced in this book) to describe the work performed in each component and thereby
ensures consistency between these alternative yet complementary perspectives.
The proceeding is a brief introduction to this approach:9
Introduction
Component Business Modelling (CBM) is a technique for modelling an enterprise as non-
overlapping components in order to identify opportunities for innovation and improvement. The
modelling is of the business itself, not of applications or technology. CBM is complementary to
process modelling techniques. A business process can be interpreted in CBM as a collaboration
among a network of business components. Conversely, from a process perspective, a business
component is a closely related group of sub-processes (activities).
CBM models a business as a set of business components. A business component is a part of an
enterprise that has the potential to operate independently, in the extreme case as a separate
company, or as part of another company. A business component is a logical view of part of an
enterprise that includes the resources, people, technology and know-how necessary to deliver
some value. The key characteristic of a business component is that a user of its services does not
have to be aware of how the component works.
A business component map is a tabular view of the business components in the scope of interest.
The columns of the table represent business competencies and the rows represent accountability
levels. The business components are rectangles within the table. Normally each rectangle is within
only one cell of the table. A business competency is a large business area with characteristic skills
and capabilities, for example, product development or supply chain. An accountability level
characterises the scope and intent of activity and decision making. The three levels used in CBM
are directing, controlling and executing.
CBM-BoIT
The CBM-BoIT business component map was created from the perspective of the role within an
enterprise having overall responsibility for the investment and use of information technology.
Typically, this role is referred to as Chief Information Officer (CIO) or Chief Technology Officer
(CTO). This perspective is important in that it establishes the scope of components and activities
defined within the map. The map was designed to be stand alone, meaning that it could be applied
to a company whose sole business was IT services. When applied within a different context, there
may be extraneous or duplicate components which can be eliminated.
The map is technologically agnostic, meaning that it does not assume any specific type of
hardware or software. Rather, it takes the perspective that the IT function can be defined in a
similar manner to any other component of the enterprise, and should be managed using the same
9. Further information on CBM-BoIT is available at http://www-935.ibm.com/services/us/imc/pdf/g510-6163-compo-

nent-business-models.pdf
•
•
•
•
business disciplines. Definitions of specific architectures or technologies must be done within

context, and will affect a number of components accordingly.
International Standard for Process Description

The IBM Process Reference Model for IT has been designed to align with the International
Standard for Process Reference Models. The ISO IEC 24774 standard10 is a technical report
describing guidelines for process descriptions in the context of life cycle management and software
and systems engineering. This technical report is designed to encourage consistency in standard
process reference models. It describes the need for process reference models to include Title,
Purpose, Outcomes, and Activities to provide an objective list of assessable items.
Title: The title of a process is a short noun phrase intended to summarize the scope of the
process, identify the principal concern of the process, and distinguish it from other
processes within the scope of a process model.
Purpose: The purpose should succinctly capture in a single sentence the goal or objective
of performing the process. It should describe some tangible benefit to the stakeholders.
Outcomes: The outcomes express multiple observable results expected from successfully
carrying out the process
Activities: Rather than describing the results of executing a process, activities describe a
set of actions that might be undertaken to execute the process.
Generally, purpose statements are similar from model to model. Here is an example of a purpose
statement. "The purpose of the Incident Management process is to respond to incidents in order
to restore agreed services within agreed service level limits."
Outcomes do vary from model to model. One view of outcomes, that has been taken by some
international standards work, is to take each activity and identify what the evidence is when the
activity has occurred. Here is an example of written outcomes using this approach:
Outcomes: As a result of the successful implementation of the Incident Management process:
An Incident Management strategy is developed
Incidents are recorded, identified, and classified
Incidents are analyzed and assessed to identify acceptable solutions
Here is another example with differing outcomes:
IT service interruptions are restored to users within agreed service levels
IT service availability is sustained at agreed service levels
Workarounds to resolve similar service interruptions are created
Potential improvements to services are identified
These examples demonstrate a difference in approach to the definition of outcomes. In the first
example, the outcomes listed would provide evidence that the activities are being carried out. In
the second example, the outcomes are focused on the business reason for carrying out the
activities in the first place. Because the IBM Process Reference Model is focused on the business
of IT, it is written in the second style, giving preference to the outcomes that describe business
reasons for carrying out the process.
10. See ISO/IEC TR 24774:2007 at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnum-

ber=41544
•
•
•
•
A first look at the model
A first look at the model

Model purpose
The IBM Process Reference Model for IT (PRM-IT) is an integrated collection of the processes
involved in using information technology (IT) to assist businesses in carrying out many or all of their
fundamental purposes. It describes, at a generic level, the activities that are performed in order
that IT provides value to the stakeholding business or businesses.
For most of these businesses, this use of IT has been a means to improve the business processes
that underpin their value propositions to the industry segments they serve. For others, IT services
have been major value propositions in their own right. As the reach and range of IT-based solutions
and services has extended and become, to all intents and purposes, pervasive, these two uses of
IT have converged.
So, as IT exploitation becomes synonymous with business success, the basis of this model is to
describe IT undertakings as if a business in its own right, and to apply the same business process
description techniques to it as for any other business.
Viewpoint of the model

The focal point for all IT activities, and the executive accountable for IT value, is the CIO.
Accordingly, PRM-IT considers the work done within IT from this perspective.
It is only from this vantage point that all aspects of IT are visible. Within IT, all other viewpoints can
see only a subset of the complete picture.
There are two main perspectives from the CIO’s viewpoint:
1. Control over IT activities.
• Such control can be direct, in that the activities are performed by the in-house IT
department.
• Some activities can be performed within parts of the business, but under the guidance of
IT-developed or owned standards. A typical example is that of users within a business
division developing applications, using technology and techniques established by IT.
• Many activities can be assigned to one or more third parties, covering the range from
complete outsourcing through limited IT service out-tasking.
2. Representing the IT endeavor to its stakeholders and to the wider operating environment.
These interested parties provide the context in which the IT business operates.
•
•
•
•
The context and scope of PRM-IT
The context and scope of PRM-IT

The model focuses on all potential activities that could occur within the box Manage IT, but also
recognizes that many of its workings rely upon interactions with other parties (external agents).
Figure 5. Comprehensive and effective activity sets in PRM-IT
•
•
•
•
Drilling into the model: The process categories
Drilling into the model: The process categories

PRM-IT presents a framework that uses eight process categories:
A–1 A–5
Governance and Transition
Management System • Control, deployment, and reporting of
• How IT ensures it is able to function all changes and technology
effectively – its control mechanisms resources
A–2 A–6
Customer Relationships Operations
• Representing IT to its customers and • Fulfillment and suppor for IT services
meeting their needs and users
A–3 A–7
Direction Resilience
• Strategic decision making of IT in • Continued readiness and integrity of
support of the business the IT services
A–4 A–8
Realization Administration
• Design, development, and • Underpinning back-office
maintenance of all classes of IT management of the IT function
solutions
Figure 6. PRM-IT process categories
The categories convey several concepts:

1. The categories with no internal shading contain the primary processes, which produce and
deliver the service needed by the customer of IT.
2. The most useful decomposition of the primary activities assumes a create, deploy, operate,
and maintain approach. Thus producing this sequence:
a. Realization
b. Transition
c. Operations
d. Resilience
3. The shaded categories contain the supporting processes which facilitate the success of the
primary processes.
4. The supporting processes are best split into those which focus on the result that IT must
achieve, namely Customer Relationships and Direction, and those that describe the
underpinning setup and ongoing maintenance of the IT functional capability: Governance
and Management System, and Administration.
•
•
•
•
The processes for the business of IT
The processes for the business of IT

PRM-IT contains a total of 46 processes across the eight categories.
A–1 Governance and Management System A–5 Transition

IT Governance and Management System Framework Change Management
IT Governance and Management System Capabilities Release Management
IT Governance and Management System Operation Deployment Management
IT Governance and Management System Evaluation Configuration Management
Asset Management
A–2 Customer Relationships

A–6 Operations
Stakeholder Requirements Management
Request Fulfillment
Service Marketing and Sales
Service Execution
Service Catalog Management
Data Management
Service Level Management
Event Management
Demand Management
Incident Management
IT Customer Transformation Management
Problem Management
Customer Satisfaction Management
Identify and Access Management
A–3 Direction
A–7 Resilience
IT Strategy
Compliance Management
IT Research and Innovation
Security Management
Architecture Management
Availability Management
Risk Management
Capacity Management
Product Management
Facilities Management
Portfolio Management
IT Service Continuity Management
Program and Project Management
A–8 Administration
A–4 Realization
Financial Management
Solution Requirements
Supplier Management
Solution Analysis and Design
Service Pricing and Contract Administration
Solution Development and Integration
Workforce Management
Solution Test
Knowledge Management
Solution Acceptance
Figure 7. PRM-IT processes
PRM-IT Version 3 has a complete further level of decomposition of these processes, into 309
activities. The interactions between all the categories, processes, and activities are modeled in
over 700 inputs, outputs, controls, and nearly four thousance individual links.
Every process is described in “Model Categories and Processes in IDEFØ” on page 19. For each,
this book includes a listing of the activities that comprise it.
Full details of the activities, inputs, outputs, and controls that characterize the relationships among
processes and activities, are available in the PRM-IT Reference Library.
•
•
•
•
Mapping PRM-IT processes to ITIL
Mapping PRM-IT processes to ITIL

This shows how the ITIL alignment (described earlier) is achieved. Details are further provided.

IT Governance and Management System Framework Change Management
IT Governance and Management System Capabilities Release Management
IT Governance and Management System Operation Deployment Management
IT Governance and Management System Evaluation Configuration Management
Asset Management

A–6 Operations
Stakeholder Requirements Management
Request Fulfillment
Service Marketing and Sales
Service Execution
Service Catalog Management
Data Management
Event Management
Demand Management
Incident Management
IT Customer Transformation Management
Problem Management
Identify and Access Management
A–3 Direction
A–7 Resilience
IT Strategy
Compliance Management
IT Research and Innovation
Security Management
Availability Management
Risk Management
Capacity Management
Product Management
Facilities Management
IT Service Continuity Management
Program and Project Management
A–4 Realization
Supplier Management
Solution Analysis and Design
Service Pricing and Contract Administration
Solution Test
Solution Acceptance
Figure 8. Key ITIL links
Directly aligned processes

Twenty nine processes are shown in green text and preceded by the Â symbol. For these
processes, there is an identical or nearly identical named process in ITIL.
As an example of variation, consider Identity and Access Management. The ITIL process is called
Access Management. In our judgment, the concept of identity is a foundation of Access
Management. The ITIL chapter makes significant reference to identity. In the absence of its being
explicitly considered elsewhere in ITIL V3, these two items have been modeled here in a single
process.
Processes with implicit ITIL content

PRM-IT processes shown in red are implicity represented as processes in ITIL books. ITIL covers
concepts and practices relevant to the purpose and scope as defined in PRM-IT. For instance,
Appendix B.2 “Product Managers” in the ITIL Service Strategy book, relates directly with PRM-IT
as the Product Management process.
•
•
•
•
The value of this process reference model
The value of this process reference model

Who can benefit from this book?
In any given organization, everyone from the top to the bottom, needs to understand the impact
that information has on the business. How information is processed is a major determinant for how
well the business operates and consequently how well the business is able to satisfy its customers.
Indeed, it is a truism that without customer satisfaction, there will be no business.
This book is designed for the managers of an organization who want to take a serious look at how
information supports their business and can be used to make that business prosper. It is designed
for those who are responsible for designing and managing the information systems that will support
the goals and objectives of the business. Finally, the book is designed to give some help to
everyone in a given business to understand the importance of information and information
technology to the success of their work.
To our clients
The new process model for IT management provides clients with a starter set; an entry point for
looking at their organization and determining what their IT delivery mechanisms are doing, versus
what they need to be doing. Also, it can serve as a tool to examine those activities that are not
working well and see if they are implementing the necessary processes to begin with. This model
can help our clients discover what they need to do, in terms of IT, and help them organize around
those needs, including organizing their business transformation initiatives. In short, the new
process reference model for the business of IT can help our clients move toward finding out what
they need to do to optimize the value of IT to their business by understanding which things they
themselves should be doing, which things they might outsource, and how these must interact to
be successful.
To IBM
The new process model is the basis for a powerful assessment that we can use to determine what
our customers are doing, versus what they need to be doing, and how well they are doing those
things. It is an opportunity to add value to the customer relationship. For example, when helping a
client develop an IT strategy, the use of this model can point out to the client all the processes that
are influenced by that strategy. As a result, the use of this model can provide a springboard for
working with the client and providing downstream services to optimize those processes.
In addition, the model can be used to increase the knowledge base of our own practitioners,
augmenting their skills as we provide our services. It can also provide us a better base from which
to design and build products. For example, before writing a new application to manage information
technology, the model can be used to determine what processes and activities are involved.
Finally, the new model is the next evolutionary step in process model thinking as it applies to the
management of IT. It is unique and leading edge. It reinforces IBM's leadership position in
providing guidance and assistance to clients in the management of IT.
•
•
•
•
How to use this book

The next chapters of this book provide descriptions of each process, organized by category.
However, it is important to note that these groupings, and their labels, are somewhat arbitrary. We
have provided one logical grouping, but it is not the only grouping possible. The model is really a
starter set. It is a collection of building blocks that can be reordered and reshuffled to create a
model that is applicable to your unique situation.
The process model (introduced in this book and presented in complete form in the related
Reference Manual) is your starting point. In order to proceed, certain concepts, constraints, rules,
and terminology need to be understood and taken into account. In other words, one must
recognize this model for what it is, as well as for what it is not.
This model is not intended to be implemented directly
The model focuses on what to do, not how to do it. One cannot take this model and apply it
without modification. This model provides a starting point from which to build a process
model customized to a given business.
This model is not the final answer
The authors make no pretense of having discovered the best solution for every situation.
We feel, however, that what we have provided are those elements that should be present
regardless of how they are ordered. Regardless of how you pick and choose among the
process categories and processes, it is important to make sure that any given process
receives the inputs and outputs it needs to perform its function. Where a process gets
those inputs and outputs could well change, depending on a particular implementation. So,
use this book as a design guide for building your own process model, not as the final
answer to all.
This model is dynamic, not sequential—it is not a flow chart
Because this is a book (a two dimensional medium) it was obviously necessary to put the
model down on paper in some kind of logical order. This does not mean that the processes
contained in this model must function in that order, so do not let your thinking be
constrained by the fact that processes and their activities are listed in a certain order on a
given page of the book. You can rearrange these processes. The sequence of activities
might change, but the relationships among the processes will not. In actual
implementation, there can be multiple iterations of given processes or portions of those
processes, and these iterations might happen in parallel, rather than in sequence.
However, what process needs to be done remains the same, regardless of the number of
iterations or sequence.
This model is not an organizational chart
This model should not be viewed as an organizational construct. We have not delineated
process owner roles and responsibilities in this work.
One final thought

Keep in mind that there are no technology solutions to management problems. Automating a poor
management process only makes undesirable things happen faster. The successful management
of any IT environment depends on sound management processes, and the appropriate use of
enabling technologies.
•
•
•
•
Model Categories and Processes in IDEFØ
Model Categories and Processes in IDEFØ

The decomposition of the model, using IDEFØ numbering:

A11 IT Governance and Management System Framework A51 Change Management
A12 IT Governance and Management System Capabilities A52 Release Management
A13 IT Governance and Management System Operation A53 Deployment Management
A14 IT Governance and Management System Evaluation A54 Configuration Management
A55 Asset Management
A–6 Operations
A21 Stakeholder Requirements Management
A61 Request Fulfillment
A22 Service Marketing and Sales
A62 Service Execution
A23 Service Catalog Management
A24 Service Level Management A63 Data Management
A25 Demand Management A64 Event Management
A26 IT Customer Transformation Management A65 Incident Management
A27 Customer Satisfaction Management A66 Problem Management
A67 Identify and Access Management
A–3 Direction
A–7 Resilience
A31 IT Strategy
A71 Compliance Management
A32 IT Research and Innovation
A72 Security Management
A33 Architecture Management
A73 Availability Management
A34 Risk Management
A74 Capacity Management
A35 Product Management
A75 Facilities Management
A36 Portfolio Management
A76 IT Service Continuity Management
A37 Program and Project Management
A–4 Realization
A81 Financial Management
A41 Solution Requirements
A82 Supplier Management
A42 Solution Analysis and Design
A83 Service Pricing and Contract Administration
A43 Solution Development and Integration
A84 Workforce Management
A44 Solution Test
A85 Knowledge Management
A45 Solution Acceptance
Figure 9. PRM-IT categories and processes in IDEFØ structure
The naming convention is that each main branch represents a category, and each of the items
listed within it is a process.
This chapter examines each category and process in turn, moving in IDEFØ identification
sequence.
(While this identification is not particularly significant at the level of detail in this book, it is provided
for consistency with the Reference Library.)
•
•
•
•
[A0] Manage IT
[A0] Manage IT
Model Introduction
which underpin their value propositions to the industry segments they serve. For others, IT
services have been major value propositions in their own right. As the reach and range of IT-based
solutions and services has extended and become, to all intents and purposes, pervasive, these
two uses of IT have converged.
PRM-IT is independent of organizational design and makes no assumptions about the chain,
network or mesh of IT business entities -– or the nature of their inter-relationships (such as
contractual, partnership, joint venture) -– by which the IT service is provided to the primary
businesses. Each of these IT business entities will need to understand both the activities they
undertake to contribute to IT service provision and (perhaps increasingly) the interfaces they have
with related parties.
Viewpoint of the Model

The focal point for all IT activities, and the executive accountable for IT value, is the CIO. In some
IT undertakings, these accountabilities are assigned to an executive body that has CIO-role
responsibilities. Accordingly, PRM-IT considers the work done within IT from the CIO or CIO-role
perspective.
It is only from this vantage point that all aspects of IT for the IT business entity within scope are
visible. Elsewhere within that IT business entity, all other viewpoints can see only a subset of the
complete picture.
There are two main perspectives from the CIO's viewpoint:
department.
• Many activities can be assigned to one or more third-parties, covering the range from
2. Representing the IT undertaking to its stakeholders and to the wider operating
environment. These interested parties provide the context in which the IT business
operates.
The context for the business of IT

IT does not operate in a vacuum; it has relationships of varying kinds with a variety of other parties.
In modeling terms, these parties are known as external agents.
•
•
•
•
[A0] Manage IT
PRM-IT contains five kinds of generic external agents:

1. The Business
2. Customers
3. Users
4. Suppliers
5. External Environment
The nature of the interactions between IT and each external agent is described in detail later.
The Business
The Business is the owner of the IT undertaking. It provides the underlying funding for IT and
receives from IT a corresponding return, in the form of value against the criteria which the business
sets.
The Business provides resources to and exercises control over IT, beyond the financial aspect.
It establishes the container in which each section of the business operates: manufacturing,
distribution, IT, and others. Each such section probably has some degree of freedom to set
its own tenor (or style) of operation, but each must conform to the overall management
system and governance.
Beyond this, IT might rely wholly or partly upon other, similarly common aspects of the
business infrastructure. Key examples here include finance and accounting, and workforce
management.
The Business is the ultimate arbiter over the direction and the performance scorecard of IT.
Customers
In contrast to the broad nature of The Business, the external agent, Customers, reflects that each
IT service has an individual customer, or a collective set of them.
The role of the Customer covers aspects that specify and guide the makeup of the services, such
as:
Providing requirements that can eventually be satisfied by an IT service.
Commissioning development of new or updated solutions. The agreement for this, and for
the levels of service using the solution, can be formally or informally contracted, depending
on the customer-provider relationship.
Interactions relating to satisfaction (or otherwise) with delivered IT services.
The model does not differentiate between internal and external customers. The interactions
depicted in the model cover both cases. In particular, the Customer can themselves be another IT
service provider, perhaps in the role of a prime contractor to the ultimate customers or of a service
integrator in a multi-sourcing arrangement.
Users
This external agent is involved in the interactions with each of the services provided by IT.
Primarily, the interactions are related to receiving service through initiating and providing
data to individual transactions, and generalized services (such as e-mail and Internet
access).
Additionally, users will interact with support services (manually or electronically) for:
• Requests for advice and guidance
• Interruption to service (PC hardware failure, for example)
User interactions occur only within the specifications of agreed services. The Customer role is
needed to commission and confirm new or extended services.
•
•
•
•
[A0] Manage IT
Suppliers
No IT function can provide 100 percent of the value delivered in their portfolio of IT services. At
some point in each value chain, there will be dependencies on one or more Suppliers. Suppliers,
in this context, are organizations outside the control of the CIO and with whom the primary linkage
is in the form of a supply agreement, formally or informally. The supply agreement can be for
products, services, or both. In return for this supply, there will need to be a corresponding payment,
which is usually of a monetary kind.
PRM-IT does not indicate the points when the value chain will invoke a supply agreement, it does
acknowledge that an agreement will be required. Similarly, while it is likely that most agreements
will be with suppliers external to the business, it is possible that some suppliers might be sister
organizations in the wider business.
External Environment
The policies, practices, methods and techniques the IT undertaking uses are subject to many other
influences and constraints beyond the external agents thus far mentioned. Collectively, the term
External Environment is used to convey these influences and constraints.
Examples of agents of this type are:
Governments
Regulatory agencies
Industry trends
• The industry segments of the business
• The IT industry in general
IT management frameworks and techniques, such as published best practice and bodies of
knowledge
In general, the External Environment has a strong influence over an individual IT undertaking. In
contrast, it is relatively unlikely, though possible, for the reverse to be true.
Model Composition
This model is composed of these process categories:
A1 Governance and Management System
A2 Customer Relationships
A3 Direction
A4 Realization
A5 Transition
A6 Operations
A7 Resilience
A8 Administration
•
•
•
•
[A1] Governance and Management System
Description
Purpose
The Governance and Management System process category defines a structure of relationships
and processes to direct and control the IT undertaking. These processes must establish the
capability to achieve the information technology (IT) goals. The governance and management
system must add value by balancing risk versus return across IT and all processes.
The category defines, establishes, operates, and improves upon a management framework for
conducting IT activities. The management framework outlines, as an example, the management
model, guiding principles, methods, organization design, information framework, process
structure, policies and practices to guide the IT organization towards its stated goals. Once the
management framework is defined and implemented, a continuous evaluation process will be
executed to make possible better decision making by executives on whether the business model
is succeeding or should be modified to achieve the objectives better.
Governance considers and sets the fundamental direction for the management framework.
Governance is a decision rights and accountability framework for directing, controlling, and
executing IT endeavors in order to determine and achieve desired behaviors and results.
Governance involves defining the management model and creating the governing or guiding
principles. This includes:
Who makes directing, controlling, and executing decisions, and defines the ultimate
authority (final arbiter)
How the decisions will be made, and the procedures for escalation and arbitration
What information will be required to make the decisions
The frequency of decision making must be executed or revisited
The required decision making mechanisms
How exceptions will be handled
How decisions will be communicated to the concerned parties
How the results of the implemented governance should be reviewed and improved
Rationale
The Governance and Management System process category ensures that a framework is in place
to integrate processes, technologies, people, and data in a manner consistent with the IT goals.
This category also monitors the framework against the broader enterprise goals and quality
metrics. When specific goals and quality metrics are consistently unmet, decisions will be made
regarding the overall framework and whether it will be modified or restructured to ensure future
success.
Value
Integrates and coordinates the workings of IT
Enables informed and effective decision making
Establishes responsibility for the implementation of a set of coherent, integrated
capabilities that enables IT
Optimizes strategic, tactical, and operational effectiveness of IT
Ensures continuous improvement
•
•
•
•
Processes
This process category is composed of these processes:
A11 IT Governance and Management System Framework
A12 IT Governance and Management System Capabilities
A13 IT Governance and Management System Operation
A14 IT Governance and Management System Evaluation
[A11] IT Governance and Management System Framework

Purpose
The purpose of the IT Governance and Management System Framework process is to lay the
foundation for building the governance and management of an IT organization or undertaking,
taking into account such factors as vision, values, goals, and overall business objectives. Further,
it establishes guiding principles (or a management philosophy) based on those factors.
This framework plays a key role in aligning the IT entity with the overall approach of the business.
To be effective, the IT management system must focus on cultural as well as business aspects.
This process does not identify the priorities of the business, but rather the approach to operating
the various IT projects and processes in a coordinated fashion, that will manage their progress and
health.
Outcomes
As a result of the successful implementation of this process:
Clear, unambiguous objectives and roadmaps for the overall IT Governance and
Management System are set
Overall IT governance meets the objectives provided by the owning business
The IT management system aligns with the overall business management system
Management system directions are transformed into a functional, workable, and
implementable management system
Scope
The framework for IT will be established within an overall governance and management framework
set by the business. It adds IT-relevant characteristics to relevant aspects of the business
framework and any items unique to IT undertakings.
Scope
Includes
Specifying:
– Management models
– Guiding principles
– Policies and standards
– Measurement and control approaches, such as CIO dashboard, balanced
scorecard
– Quality management approaches
– Defining critical success factors
•
•
•
•
Generating a list of decision areas and issues, and selecting decision options based
on guiding principles, values, and assumptions
Responding to any identified gaps between the current baseline and the desired
framework
Communicating direction
Excludes
Identifying gaps between the current governance and management baseline and the
desired framework (IT Governance and Management System Evaluation)
Priorities and decisions on the business results of IT (Portfolio Management)
IT strategy for the business (IT Strategy)
Activities
This process is composed of these activities:
A111 Define IT Governance Framework
A112 Define IT Management Goals
A113 Establish IT Management Policies
A114 Establish IT Management Practices
[A12] IT Governance and Management System Capabilities

Purpose
The purpose of the IT Governance and Management System Capabilities process is to define,
establish, and deploy an ecosystem for governing and managing an IT organization (or
undertaking) in order that IT undertakings proceed within the philosophies and controls set by the
parent business. It recognizes that this is not a one-off undertaking, but will be exercised at any
time to create capability adjustments both small and large-scale.
Outcomes
The desired scope for governance is established over a defined set of key decisions, with
clear assignment of decision rights and accountability to appropriate organization units and
roles.
A management system that is consistent with the direction of information technology and
with the enterprise as a whole, and is in control of all IT activities.
The management system is both effective and efficient, ensuring the integrated and
coordinated workings of IT.
A set of coherent, integrated capabilities that enable and empower IT activities is
established
•
•
•
•
Scope
This process uses a simple model of a management system to illustrate the activities, and their key
inputs and outputs, which will start with the directional frameworks and build a functioning
management ecosystem. Many other models of a management system exist; the one used here
can be summarized as follows:
Governance aspects dictate the overall shape of the capabilities
There are four main components in a management system: process, organization,
(management) information, tools
A management system is made effective by equipping it with measurement and control
capabilities, built from aspects of all the components listed in item two
Includes
Defining information technology management system requirements and key indicators
Building capabilities to realize the specified management models
Creating instruments that conform to policies and standards, such as:
– Methods
– Measurement and control capabilities
– Quality management system
– Continual improvement techniques
Organization design in relation to IT, such as:
– Structure, behaviors, enablers
– Roles and responsibilities definitions
– Process structure
– Implementation or change transition plans, including schedule
Excludes
Development of IT solutions for management system needs these compete for
resources alongside other needs (Portfolio Management)
Activities
A121 Establish IT Governance Capabilities
A122 Establish IT Process Capabilities
A123 Establish IT Organizational Capabilities
A124 Establish IT Management Information Capabilities
A125 Establish IT Operational Environment Capabilities
A126 Establish IT Measurement and Control Capabilities
•
•
•
•
[A13] IT Governance and Management System Operation

Purpose
The purpose of the IT Governance and Management System Operation process is to operate and
run the management system to satisfy the overall Business’ needs.
Outcomes
The balance of strategic, tactical, and operational effectiveness of IT is optimized
Informed and effective decisions are made
The workings of IT are integrated and coordinated
Conditions are established to best ensure that key measurements can be and are met
Scope
This process does not direct what IT activities should be performed to reflect the priorities of the
Business (see A3 Direction category of processes). It does, however, oversee monitoring and
control of the collected IT projects and processes, and makes corrective adjustments where
needed.
Includes
Measurement and control, such as:
– Issues management
– CIO dashboard
– Balanced scorecard
Steering IT workings within the tolerances set by Governance
Regulating the execution of IT processes
Excludes
Priorities and decisions on the business results of IT (a business responsibility, with
participation from the processes in the Direction category)
Regulating IT services and solutions (processes in the Direction category)
Activities
A131 Produce IT Measurements
A132 Operate IT Governance and Management System Controls
A133 Monitor, Analyze and Report IT Outcomes
•
•
•
•
[A14] IT Governance and Management System Evaluation
Purpose
The purpose of the IT Governance and Management System Evaluation process is to review and
assess the execution and implementation of the IT governance and management system, and to
identify potential improvements to it.
Outcomes
The overall health of the IT governance and management system is visible to the key
stakeholders of the IT endeavor
Key measurements are effective in guiding the realization of IT goals
Potential problems with the management system are identified and resolved before their
impact results in other problems (for example, customer dissatisfaction)
There is a continual focus on the identification of improvement opportunities to the IT
governance and management system
Scope
This process monitors the measurements from all IT processes in order to ensure that the system
is functioning in the manner intended.
It provides the ability to audit all (or any part of) the IT governance and management system.
Includes
Validating the adherence to management system rules
Identifying continuous improvement actions
Quality management assessment
Assessing the execution of IT processes
Excludes
Making changes to the IT Management ecosystem (IT Governance and Management
System Framework, IT Governance and Management System Capabilities, depending
on the scale of change)
Activities
A141 Collate IT Management System Outcomes
A142 Analyze IT Governance and Management System Performance
A143 Audit IT Governance and Management
A144 Communicate IT Governance and Management System Performance
•
•
•
•
[A2] Customer Relationships
Description
Purpose
The Customer Relationships process category gives IT service providers a mechanism to
understand, monitor, perform and compete effectively in the marketplace they serve. Through
active communication and interaction with customers, this process category provides the IT
enterprise with valuable, current information concerning customer wants, needs, and
requirements. Once these requirements are captured and understood, the process category
ensures that an effective market plan is created to bring the various IT services and capabilities to
the marketplace.
Use of a Service Catalog contributes to effective communication with customers, and also provides
everyday usage details to approved users of services. In support of delivering these services,
service level agreements (SLAs), underpinning contracts (UCs), and operational level agreements
(OLAs) are planned, created, implemented, monitored, and continuously improved in this process
category. A sound understanding of the real demand for services, categorized by the mix of user
communities, helps ensure the vitality of SLAs and underpins achievement of targets.
As the dependence of business activities on technology-based support grows, assistance is
needed to help customers understand and exploit the transformation potential from technology.
While the IT services are in operation, customer satisfaction data is continuously gathered,
monitored, and recorded to enhance IT service capabilities and IT's presence in the enterprise.
The governance and implementation details of each process will depend on the essential nature
of the relationship with customers, most obviously indicated by whether they are internal or
external. For an IT provider solely serving internal customers there can be little or no flexibility in
the choice of marketplace. (ITIL uses the term Market Space, defined as “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.”11)
This marketplace selection decision occurs in the Direction category; here, the customer-facing
implications of those decisions are addressed and can result in more than one implementation of
each process depending on the market complexity.
Rationale
The Customer Relationships process category ensures that the IT enterprise is effective in the
marketplace, whether internal or external. Through active market research, the IT services are kept
current with the dynamic wants, needs, requirements, and demand level of customers.
Furthermore, customer satisfaction data is gathered and reported in order to find areas of the IT
services that require improvement. Overall, this process category provides a means for the IT
enterprise to understand customer requirements, market IT services to customers, ensure and
monitor the quality of the delivered IT services, and contribute to the maximization of business
value from technology usage.
Value
Improves communication and understanding of customer wants and needs
Identifies new market opportunities
Coordinates the marketing and selling of IT services
Establishes clear service level expectations
11. ITIL V3 Glossary

•
•
•
•
Highlights areas within IT services delivery requiring improvement

Identifies updates to IT services for greater effectiveness in meeting customer
requirements
Guides customers in understanding where and how technology can transform their
business
Enhances customer satisfaction and loyalty
Processes
A24 Service Level Management
A25 Demand Management
A26 IT Customer Transformation Management
A27 Customer Satisfaction Management
[A21] Stakeholder Requirements Management

Purpose
The purpose of the Stakeholder Requirements process is to capture, classify, qualify, promote, and
maintain requirements for IT services, from the business and for the management of IT activities.
This also involves providing information on the status of all requirements throughout their life cylce.
Definition of 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.”12
Outcomes
IT service stakeholders provide input concerning individual services or collections of
services
An agreement can be defined between IT customers and providers concerning an IT
service and IT service components
Implemented requirements are justified
IT service management can better meet the stated needs and expectations of customers
Scope
This process is the starting point for the translation of customer needs, typically expressed in
business terms, into functional requirements (in IT terms) that can be acted on by other processes.
It begins with recognizing, verbalizing, and documenting needs. It ends with an established set of
feasible and measurable requirements that is maintained until the requirements are satisfied,
changed, or rejected.

•
•
•
•
Includes
Handling requirements in support of business capabilities
Handling requirements in support of infrastructure capabilities
Initial feasibility analysis to confirm requirements
Customer validation of requirements statements
Tracking and communicating the status of requirements
Excludes
Order taking (Service Marketing and Sales)
Detailed requirements analysis for any application or service (Solution Requirements)
Activities that deliver solutions and services for the agreed requirements (Realization
category of processes beyond Solution Requirements)
Activities
A211 Establish Stakeholder Requirements Management Framework
A212 Capture Stakeholder Needs
A213 Transform Needs into Stakeholder Requirements
A214 Monitor and Report Stakeholder Needs and Requirements
A215 Evaluate Stakeholder Requirements Management Performance
[A22] Service Marketing and Sales

Purpose
The purpose of Service Marketing and Sales process is two fold:
Marketing – To understand the marketplace served by the providers of IT, to identify
customers, to market to them, to generate marketing plans for IT services, and support the
selling of IT services
Sales – To match up customer wants and needs with IT service capabilities, and to sell
appropriate IT services
Outcomes
Existing and potential customers have visibility and understanding of IT capabilities
Awareness of IT services and capabilities is stimulated
Customer and marketplace trends and opportunities are understood
IT service contracts are established at the optimum price point for both customer and
provider
The IT organization is promoted as the IT service provider of choice
Scope
The process addresses marketing to both general and specific customer needs. It involves working
with current internal and external customers as well as identifying potential customers. It supports
the marketing and selling of both current services and potential solutions and services.
•
•
•
•
Includes
Understanding the market, customer segmentation, the opportunities and the
competitive (to the IT service provider) threats
Developing the list of prospects
Generating marketing and sales collateral; communicating the features, advantages,
and benefits for unique buying criteria
Negotiating and closing sales within pricing guidance and rules
Excludes
Deciding to commission service and solution extensions (Portfolio Management)
Developing solutions and services (Realization category of processes)
Implementing solutions (Transition category of processes)
Preparing contracts (Service Pricing and Contract Administration)
Establishing pricing guidance and rules (Service Pricing and Contract Administration)
Activities
A221 Establish Service Marketing and Sales Framework
A222 Analyze Market Wants and Needs
A223 Create Marketing Plan
A224 Execute Marketing Plan
A225 Manage Opportunities and Forecast Sales
A226 Consult and Propose Services Solutions
A227 Negotiate and Close Services Opportunity
A228 Analyze and Report Marketing and Sales Results
A229 Evaluate Service Marketing and Sales Performance
[A23] Service Catalog Management

Purpose
The purpose of the Service Catalog Management process is to provide an authoritative source of
consistent information on all agreed services and ensure that it is widely accessible to those who
are approved to view this information.
Outcomes
Customers and approved users trust the published service catalog as the authoritative
description of the services available to them
Accurate information on all operational services and those being prepared to be run
operationally (details, status, interfaces and dependencies) is maintained and updated in
the service catalog
Role-based views of the Service Catalog are created and maintained in order for each role
(such as customers, end users, service management support personnel) to understand
service definitions and use the information effectively
•
•
•
•
The services catalog is aligned and consistent with the Service Provider and Customer
needs
Scope
The primary output of the process is the Service Catalog itself. It includes a strategic view that
allows the service manager, customers, and IT executives to see the list of services and their
status (for example: available, soon to be available, or soon to be retired), and detailed service
characteristics for negotiation, financial or strategic planning. It also contains a tactical view that
allows IT end-users to request services available to them. Additional information will be available
to personnel involved in the provision of the services represented in the catalog in order to facilitate
the consistent, effective and efficient delivery of those committed services.
Includes
Entering and updating service definitions
Navigation support
View management
Service selection and transaction tracking
Education on how to use the Service Catalog
Excludes
Negotiating and closing Service Agreements (Service Marketing and Sales)
Creating service level agreements (Service Level Management)
Request management, user entitlement authorization and execution workflow
(Request Fulfillment)
Activities
A231 Establish Service Catalog Management Framework
A232 Define Service Package Catalog Requirements
A233 Build and Maintain Service Catalog Content
A234 Create and Maintain Service Catalog Views
A235 Publish Service Catalog
A236 Monitor, Analyze and Report Service Catalog
A237 Evaluate Service Catalog Management Performance
•
•
•
•
[A24] Service Level Management

Purpose
The purpose of the Service Level Management process is to ensure that the service delivered to
customers matches or exceeds the agreed, committed service quality characteristics.
Definition of service level agreement (SLA): “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."13
Outcomes
Both the providers of IT service and their customers have a clear, unambiguous and
consistent expectation of the quality of service to be delivered and received
Service commitments are achievable
Service attainments against targets are reported accurately and in a timely fashion to all
defined service stakeholders
Service quality is revived in an agreed way following any service level breach
Opportunities for continual service improvement are identified and, where cost-justified,
realized
Scope
This process addresses life cycle management of service level agreements. It covers negotiation
of them with IT customers, monitoring service level achievements against targets, performing
service reviews, and initiating service improvement plans.
Includes
Establishing strong relationships with customers based on mutual trust
Implementing SLAs from feasibility through monitoring, renewing, and improving
Integrating the service characteristics of domain specialist processes (such as
Availability, Capacity, and others)
Evaluation of IT transactional service performance in relation to business services and
their requirements
Creation and maintenance of operational level agreements (OLAs) with providers
further along the service supply chain, and consideration of resulting requirements for
and performance defined in underpinning contracts (UCs)
Reporting to customers on any aspect of service level attainment, including reviewing
variation from target
Oversight of the implementation (by other processes) of Service Improvement Plans
related to service level quality
Excludes
Making decisions on requests from customers for new services and functionality
(Portfolio Management)

•
•
•
•
Primary responsibility for contractual relationships with either customers or suppliers

(Supplier Management)
Pricing the elements within the service catalog and specific SLAs (Service Pricing and
Contract Administration)
Technical work to implement changes to any service component or operational
procedures relating to service improvements (as appropriate: many individual
processes, Change Management, Portfolio Management)
Activities
A241 Establish Service Level Management Framework
A242 Develop Service Level Relationships
A243 Create and Maintain Service Level Agreements
A244 Monitor and Report Service Level Achievements
A245 Conduct Service Review
A246 Formulate Service Improvement Plan
A247 Evaluate Service Level Management Performance
[A25] Demand Management

Purpose
The purpose of the Demand Management process is to understand the patterns of the customers’
business behaviors and relate those patterns to the impact on the supply of IT services. The intent
of this process is to synchronize the consumption (demand) with the capacity (supply) of IT
resources.
The benefit of demand management is to maximize the business value (value defined as benefit
minus cost of the business process or business service) from the investment in IT resources.
(Capacity Management focuses on the behavior of those IT resources; Demand Management
understands and influences the behavior of IT resource consumers.)
Outcomes
IT understands defined and tracked patterns of business activity (user profiles and
geographic distribution)
Patterns of consumption are identified
Service level package14 recommendations are provided to Service Level Management
Instances of insufficient and excess capacity are minimized
Consumption and production of service capacity are synchronized
Demand policies and incentives are defined (both positive and negative)
Scope
This process understands the expected business behavior of all demand sources across all
customers, both at an individual customer level and collated to represent the overall impact on IT.
It translates demand from business terms into IT service terms (such as consumption units). It
14. See the PRM-IT Glossary and the ITIL V3 Glossary

•
•
•
•
identifies gaps and misalignment between demand and supply, and proposes policies and
incentives designed to minimize or close the gaps.
Includes
Definition of high-level strategy and policy to influence demand
Consideration of all mechanisms that can influence demand, including:
– Rewards
– Penalties
– Service availability restrictions
– On demand capacity allocation
Investigation of both internal and external inhibitors to demand
Recommendations for IT resource investment (when demand management measures
are unable to reduce demand to fit within available supply)
Translation of patterns of business activity into IT service consumption
Recommendations on cost and price elasticity
Excludes
Implementation of demand influencing activities, such as policies and incentives
(Capacity Management, Service Pricing and Contract Administration)
Service portfolio content definition (Portfolio Management)
Service catalog content update (Service Catalog Management)
Investment decisions (Portfolio Management)
IT resource consumption monitoring and reporting (Service Execution, Capacity
Management)
Activities
A251 Establish Demand Management Framework
A252 Value and Classify Business Demands
A253 Consolidate Business Demand Patterns and Forecasts
A254 Forecast Service Demand
A255 Identify and Plan Demand Management Initiatives
A256 Assess and Report Demand Management Outcomes
A257 Evaluate Demand Management Performance
•
•
•
•
[A26] IT Customer Transformation Management

Purpose
The purpose of the IT Customer Transformation Management process is to assist customers in the
transformation of their business throughout the life cycle; from the genesis of transformation ideas
through the measurement and optimization of the benefits from implemented transformation.
While this process primarily exists to support technology-based transformation, a customer might
request assistance under this process for other kinds of transformation (a quality improvement
program, using an approach like LEAN).
Outcomes
Transformation opportunities, both incremental and more foundational, are identified and
prioritized
Customers and the business are encouraged to adopt transformational capabilities
The IT organization contributes to the exploitation of transformational capabilities by
guiding and overseeing their introduction
The benefits achieved by transformation are defined, measured, analyzed, improved and
controlled
Reports indicating both benefits missed as well as further, unanticipated benefit potential
inform transformation leadership teams
Scope
Includes
Being able to deal with each identified customer in a manner relevant to their
individual needs
Gaining sufficient understanding of the customer's business in order to contribute at
the desired level
Where appropriate:
– Establishing joint working arrangements with the designated customer
representatives
– Providing business modeling and business case development skills and capabilities
– Supporting transformation based on cultural and procedural change that is not
(significantly) technology based
Contributing to the cultural changes and other organizational change management
efforts needed for successful transformation
Benefit measurement and reporting
Excludes
Decision making on the portfolio impact (for example, new services) resulting from
transformation proposals (Portfolio Management)
Direct development of information technology solutions and services (Realization
category of processes)
Activities
A261 Establish IT Customer Transformation Management Framework
•
•
•
•
A262 Understand IT Customer Context

A263 Identify IT Customer Transformation Opportunities
A264 Develop IT Customer Transformation Proposal
A265 Enable and Promote IT Customer Capability Adoption
A266 Optimize IT Customer Benefit Realization
A267 Evaluate IT Customer Transformation Management Performance
[A27] Customer Satisfaction Management

Purpose
The purpose of the Customer Satisfaction Management process is to determine if customers are
satisfied, and the degree of their satisfaction with the services, solutions, and offerings from the
providers of IT. In addition to this determination, the process aims to proactively predict what the
customer satisfaction will be, and then to determine what must be done to maintain or, where
appropriate, enhance satisfaction and customer loyalty.
Definition of customer satisfaction: An expression of perceived actual service received versus
expected (committed) service.
Outcomes
Customer satisfaction and loyalty will be sustained and enhanced
Customer satisfaction can be measured and tracked
Early signs of customer dissatisfaction can be addressed and resolved before major issues
emerge
Causes of customer dissatisfaction are remedied
Scope
This process is active throughout the service life cycle. It begins at the first contact with a customer
as part of the effort to determine wants and needs, and continues through either creating a satisfied
customer or with the monitoring of remedial actions to correct any problems leading to customer
dissatisfaction. It encompasses the entirety of IT services, solutions and offerings (the IT service
catalog).
Includes
Identifying customer types and classes
Understanding:
– Customer expectations
– Customer perceptions
Analysis of the current services catalog
Ongoing identification of the key factors contributing to customer satisfaction and
loyalty or dissatisfaction
Development and maintenance of measurements of satisfaction and loyalty
Collection and analysis of such measurements
Planning, directing, and monitoring of efforts to remedy customer dissatisfaction, as
well as to increase satisfaction, on both a proactive and reactive basis
•
•
•
•
Communicating constraints and decision criteria agreed with customers transparently

to users
Excludes
Fulfillment of specific customer requirements (handled through Service Marketing and
Sales)Execution of specific corrective actions for resolving issues (any other process,
depending on the issue)
Ongoing activities for managing service agreements and service level attainment
(Service Level Management)
Activities
A271 Establish Customer Satisfaction Management Framework
A272 Capture Customer Satisfaction Data
A273 Analyze Customer Satisfaction
A274 Manage Customer Satisfaction Issue Resolution
A275 Assess Customer Satisfaction Patterns
A276 Communicate Customer Satisfaction Management Results
A277 Evaluate Customer Satisfaction Management Performance
•
•
•
•
[A3] Direction
[A3] Direction
Description
Purpose
The Direction process category provides guidance on the external technology marketplace, aligns
the IT outcomes to support the business strategy, minimizes risk exposures, and manages the IT
Architecture and IT Portfolio. Using the business strategy, related business requirements, and
overall technology trends as key inputs, this process category creates an IT Strategy within the
manageable constraints of the existing IT architecture and portfolio. In addition to the IT strategy,
the IT Portfolio and IT Architecture are planned, created, implemented, monitored, and
continuously improved within this process category. Items put forward for inclusion in the IT
Portfolio are managed throughout their life cycle using product management approaches well
established in many industries.
The IT portfolio includes all items managed to deliver the IT Strategy, including, but not limited to,
the services published to clients through the Service Catalog, internal services executed within the
IT organization, and new and established development initiatives. Moreover, the process category
supplies the IT organization with a Project Management process to manage initiatives driven by
the IT Strategy, such as development projects. Finally, risks to the IT organization, such as those
posed by regulatory requirements, are prioritized and managed through risk mitigation plans.
Rationale
Through a business aligned IT strategy, IT architecture and IT portfolio, this process category
ensures that the IT enterprise is aligned with the overall business direction. Using these artifacts,
the IT organization will have the capability to clearly communicate to its customers the value of the
services they provide, while mitigating the overall risk posture. This process category also instills
basic project management discipline and controls.
Value
Aligns IT endeavors to business goals and strategy
Identifies and explains new trends and directions in the technology marketplace
Triggers new initiatives to meet dynamic business and technology requirements
Incorporates new technology trends into IT strategy and plans
Establishes architectural guidelines and standards for solutions and services in order to
enhance consistency, reuse, and overall value across the range of capabilities, balancing
the need for individual solution optimization
Mitigates IT and business risks efficiently and effectively
Translates the initiatives into a mix of products (services, solutions) which will be managed
through their life cycle from vision and business case to value measurement and retirement
Optimizes the allocation of IT resources through Portfolio Management
Articulates the value of IT's contribution to the business
Ensures methodical project management processes and controls for improved quality and
predictability
Processes
A31 IT Strategy
•
•
•
•
[A3] Direction

A34 Risk Management
[A31] IT Strategy
Purpose
The purpose of the IT Strategy process is to set the direction for the outcomes to be achieved by
the use of information technology, ensuring that it supports the business and business strategy to
the level desired and funded.
It exists “To set the goals, and decide on areas of change,”15 for IT capability to support the
business strategy.
Definition of an IT Strategy: The collection of goals, policies, and plans that specify how an IT
organization should function over a specific period.
Outcomes
As a result of successful implementation of the IT Strategy process:
The business has an understanding and appreciation of the potential value of information
technology to the business. Examples are’s role in providing the business with the
capability to achieve competitive advantage, and ensuring the ability to readily respond to
changes in the business environment
All aspects of information technology strategy (such as infrastructure, applications and
services) are aligned with the business strategy, and regularly examined to maintain that
alignment
Information technology strategy is cost effective, appropriate, realistic, achievable,
business-focused, balanced, and timely
Clear and concrete short term goals (which are then to be translated into operational plans)
can be derived from and are traceable back to specific long term plans.
Scope
The IT strategy should address long and short-term objectives, business direction and its impact
on IT, the IT culture, communications, information, people, processes, technology, development,
and partnerships.
Includes
Interacting with business strategy
Setting strategic goals for IT
Creating overarching guidance for specific IT functional areas
Understanding the value, both the overall classes and the specific targets, which the
business requires IT to provide or support
Generating preliminary value propositions for the actual and proposed IT contributions
to the business
15. Source: IBM Academy of Technology Study AR221 (2004), “Enterprise Architecture in the era of on demand”.
Definition of strategy.
•
•
•
•
[A3] Direction
Excludes
The creation of the first level of plans to realize the strategy (Portfolio Management,
Product Management)
The creation, recommendation, and adoption of IT architectures for the next layers of
detail, like hardware and software (Architecture Management)
Adjusting the way that the IT undertaking organizes and runs itself to realize the
strategy (IT Governance and Management System category of processes)
Activities
A311 Establish IT Strategy Process Framework
A312 Understand Business Strategy
A313 Determine IT Strategic Potential
A314 Develop IT Strategy Initiatives
A315 Consolidate and Communicate IT Strategy
A316 Monitor and Assess IT Strategy Effectiveness
A317 Evaluate IT Strategy Process Performance
[A32] IT Research and Innovation

Purpose
The IT Research and Innovation process exists to identify new developments in technology,
methods and solutions that have potential to create business value. It conducts research on the
applicability and benefit of new approaches and technologies, and promotes the use of viable,
innovative concepts in support of business objectives.
General definitions of:
Research: (Noun) Scholarly or scientific investigation or inquiry (Verb) To study something
thoroughly to present it in a detailed, accurate manner
Innovation:
1.The act of introducing new things or methods
2.Innovation = creative idea + implementation
Outcomes
As a result of successful implementation of this process:
The business is fully aware of marketplace, industry and technology trends, and the
potential impact of these forces
Business value is created through the qualification and staging of the most appropriate
advances and innovations in technology, methods and solutions
Business objectives are met with improved quality and reduced cost as a result of the
identification and promotion of viable innovative solutions for operational usage
•
•
•
•
[A3] Direction
Scope
The process covers any selected combination of internal, external and cooperative efforts in any
part of the range of research and innovation activities.
Includes
Identification of areas or fields to be researched
Responding to research requests and identifying relevant developments within
monitored fields of interest
Monitoring, understanding, and promoting:
– Market and industry trends
– Emerging technologies
– Technology-enabled solutions
– Methods and techniques for exploiting technology and solutions
– Solution strategies
– Organizing the storage and retrieval of research results
Excludes
Decisions on adopting innovative technologies and solutions for productive use
Actual development and deployment of solutions for productive use (Realization and
Transition processes)
Project Management (Program and Project Management)
Activities
A321 Establish IT Research and Innovation Framework
A322 Identify IT Research and Innovation Candidates
A323 Qualify Candidates and Define IT Research and Innovation Projects
A324 Perform IT Research and Innovation Project
A325 Promote IT Research and Innovation Results
A326 Evaluate IT Research and Innovation Performance
[A33] Architecture Management

Purpose
The Architecture Management process exists to create, maintain, promote and govern the use of
IT architecture models and standards, across and within business change programs. IT
Architecture thus helps the stakeholder community coordinate and control their IT related activities,
in pursuit of common business goals.
Definition of IT architecture: “An overarching set of rules of construction, suitable for a defined
range of external circumstances. Usually includes a definition of the parts permitted for use in the
design, together with a specification of how the parts can be used within specific implementations
and the range of values for which the part is valid.”16
16. Source: IBM Academy of Technology Study AR221 (2004), “Enterprise Architecture in the era of on demand,”
page 15.
•
•
•
•
[A3] Direction
Outcomes
From the boardroom to the desktop, all elements of business and IT solutions receive
governance and guidance that has enhanced flexibility, consistency, integration, and reuse
All information systems and information technology infrastructure exhibit improved
manageability characteristics
The exploitation of IT across the enterprise is effective and efficient
Scope
An effective enterprise architecture (EA) should encompass:
An architecture
• This is the way our projects should be engineered.
• An EA provides a specification of the business and IT architecture models that must be
adopted by change programs and projects. This includes the overall business,
application, data, services, infrastructure architectures, and together with the principles
and guidelines needed to ensure these models are exploited properly.
Governance
• An EA must be flexible and evolve constantly if it is to support the business changes
needed by an organization wanting to innovate and transform itself. Architectural
governance has two aspects: ensuring that the architecture's specifications are adhered
to (or formal exceptions granted), and ensuring that the architecture evolves in step with
business demands.
Transition Planning
• These are the projects we should do and this is their scope.
• An EA needs a collection of processes and tasks designed to support the selection and
scoping of the right projects aimed at realizing the EA vision. The processes should be in
concert with the business-as-usual business and IT project prioritization planning
processes.
Includes
Business Architecture (BA)
– The relationships and interactions between the various business units, at
appropriate levels of decomposition
Information Systems (IS) Architecture
– The business-dependent aspects of IT; the automated parts of BA
Information Technology (IT) Architecture
– The business-independent aspect of IT; the underlying IT infrastructure
The architecture must consistently support several viewpoints across these three areas:
The applications viewpoint ensuring functionality can track through the layers. For
example, enabling an architect to link business activities and processes to
applications and transaction management services
The data viewpoint – ensuring an architect approach to information. For example,
linking business entities to data definitions and into database technologies
User viewpoint – facilitating the identification and support of an enterprise's user
groups (whether internal or external, private or corporate), including the definition of
how they are to be supported at the IS (user interface) and IT (interface technology)
levels
•
•
•
•
[A3] Direction
The architecture must be:
Maintained – An enterprise needs to keep its architecture fresh and vital, reacting to
changes in the businesses strategy as well as changes in technology through a vitality
process. In all probability, this will include the identification of new or changes to
existing standards through a selection process
Used and controlled – It is necessary to actively ensure that solution projects conform
to the constraints of the architecture (while still assuring their ability to meet the
project's business requirements) through a conformance process. Inevitably, there will
be occasions when there is a conflict between the project's needs and the
architecture, requiring an exception process
Communicated – To be effective, the architecture must be understood by those who
are required to use it, through the use of a communication process
Excludes
Portfolio Management, in which specific change programs are identified, prioritized,
and managed to completion
Requirements specification, in which specific business requirements are identified and
translated into specifications (Solution Requirements)
Solution design, in which specific IT systems are designed to meet particular business
or IT operational needs
Solution delivery and operation, including the procurement, commissioning and
operation of IT components and systems
Enterprise systems management, responsible for planning and execution of day-to-
day management of the installed IT infrastructure
Activities
A331 Establish Architecture Management Framework
A332 Review Overall Environment and Architecture
A333 Create and Maintain Architecture Models
A334 Define and Maintain Architecture Baselines and Roadmaps
A335 Promote Architecture Transition Initiatives
A336 Govern Architecture Usage
A337 Evaluate Architecture Management Performance
[A34] Risk Management

Purpose
The Risk Management process exists to identify risks associated with the activities of the IT
endeavor and to make measured, appropriate responses to mitigate, ignore, avoid or transfer
those risks in line with the desired level of risk tolerance.
The definition of risk is “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.”17

•
•
•
•
[A3] Direction
Outcomes
All of the activities carried out within IT support the desired risk posture while providing the
maximal benefit
The business and IT are able to appropriately respond to threats and opportunities
Minimal risk exists in the fulfillment of fiduciary responsibilities to stakeholders of the
business
Scope
This process provides the overall framework in which risks are handled. Other processes within IT
work in conjunction with this process to ensure that specific risk areas are adequately responded
to and covered.
Risks occur from a variety of internal and external sources, and cover the range of strategic,
tactical, and operational activities. Consideration of risk covers the potential opportunity from a risk
outcome happening in addition to the more traditional consideration of possible downside
outcomes.
Includes
External risk sources18 such as:
– Financial: Interest rates, foreign exchange, credit
– Strategic: Competition, industry and customer changes, mergers and acquisition
integration
– Operational: Regulations, Culture, Board Composition
– Hazard: Natural events, environment, contracts
Internal risk sources:
– Employees
– Information systems
– Accounting controls
– Cash flow
– Research and development
– Facilities
Risk workshops
Mitigation strategies
Excludes
Identification of compliance requirements and controls (Compliance Management)
Security-specific risk management (Security Management), though overall decision
making is part of this process
Implementation and operation of the recommended risk controls (responsibility of the
target IT processes)
Business Continuity Management (Business responsibility in conjunction with IT
Service Continuity Management)
18. Taken from A Risk Management Standard. The Institute of Risk Management. 2002
•
•
•
•
[A3] Direction
Activities
A341 Establish Risk Management Framework
A342 Identify Threats, Vulnerabilities and Risks
A343 Assess Risk
A344 Define Risk Mitigation Plans and Countermeasures
A345 Enact and Operate Risk Countermeasures
A346 Assess and Report Risk Mitigation Results
A347 Evaluate Risk Management Performance
[A35] Product Management

Purpose
The purpose of the Product Management process is to guide any IT product (such as an
application, an infrastructure component, an IT service, documentation, or combination thereof)
throughout its life cycle from inception to retirement and to be the ultimate owner of that product.
Definition of Product: an application, asset, tool, or IT assembly that will be used in the delivery of
a set of IT services to IT customers.
Outcomes
Robust, resilient products meet the IT service needs of IT customers
Evolving IT products meet business needs
Adequate resources are provided to carry out product development and support needs
Each product has a long-term vision and direction
Scope
Product Management involves oversight through the entire life of a product.19 This process will
make the case for allocation of resources to this product (and hence its inclusion into the portfolio)
and then provide stewardship over the efforts to create, launch, operate, maintain and finally retire
the product. It will measure product value against objectives throughout the life cycle, and make
recommendations for any modification of the product within the overall portfolio.
Designation as a product does not indicate the make-up of solutions and services that will be
managed. It acts purely as the unit of management for this process. A product could be developed
that becomes the basis for, or contributes to, many services. The converse is also possible.
This process has a symbiotic relationship with Portfolio Management; put another way, they could
be seen as two sides of a coin. Whereas Portfolio Management takes an aggregate, balancing
view across all IT activities, Product Management exists to champion the case for each IT solution,
service or general capability which is managed as a product. In many cases, the Portfolio
Management process will trigger a product life cycle by making a high-level, conceptual decision
to pursue an opportunity area. Product Management is then responsible for developing the
concept through to productive use while under the overall decision-making authority of Portfolio
Management.
19. See ITIL V3 Service Strategy, Appendix B2 for further discussion

•
•
•
•
[A3] Direction
Includes
Product vision
Long-term product requirements management (as opposed to Solution Requirements,
which manages requirements for a specific release)
Product marketing and launch
Ownership of the content that is included in the Service Catalog
Oversight of ongoing product development and enhancement
Approval authority over product change requests
Initiation of necessary change requests to bring a new product release into production
Product assessment and improvement
Product retirement
Excludes
Development (Realization category of processes)
Product sales (Service Marketing and Sales)
Project management
Activities
A351 Establish Product Management Framework
A352 Formulate Product Concept
A353 Plan and Control Product Lifecycle
A354 Initiate and Oversee Product Realization
A355 Guide Product Transition and Operation
A356 Monitor and Assess Product Performance
A357 Evaluate Product Management Performance
[A36] Portfolio Management

Purpose
The purpose of the Portfolio Management process is to decide the content of and resource
allocation for the set of IT investments. It includes both long-term and large-scale, as well as short-
term limited-scope opportunities, based on the strategic intent and priorities of the business.
This includes assessing all undertakings that consume resources (such as applications, services,
and IT projects) in order to understand their value to the IT organization.
Definition of Portfolio: The set of development projects and ongoing delivery services that are part
of the IT budget.
Outcomes
Customers participate in defining the IT Portfolio
The strategic fit of IT investments to business intent and priorities is very well matched
Business needs correlate very closely to IT expenditures
•
•
•
•
[A3] Direction
The portfolio meets business needs

The business receives maximum value from the IT Portfolio
Scope
Provide for the continuous identification, evaluation, selection, control, and life cycle management
of the aggregate collection of IT investments
Includes
Cognizance of key business drivers to influence investment decisions
Decisions on what programs and projects to fund, often in conjunction with any
business or customer stakeholders
Application portfolio management
Identification of in-sourced, out-sourced, business, and infrastructure applications and
services to be included in the portfolio
Determination of value obtained or projected from portfolio items
Excludes
Execution of projects (Program and Project Management)
Asset management
Delivery of services (Operations category of processes)
Activities
A361 Establish Portfolio Management Framework
A362 Inventory IT Projects and Services
A363 Create and Maintain IT Portfolio Categories
A364 Assess and Prioritize IT Portfolio
A365 Make IT Portfolio Decisions and Commitments
A366 Conduct IT Portfolio Review
A367 Communicate IT Business Value and IT Portfolio Performance
A368 Evaluate Portfolio Management Performance
•
•
•
•
[A3] Direction
[A37] Program and Project Management

Purpose
The purpose of Program and Project Management is to plan and oversee programs and projects
in support of their objectives.
The definition of a project is a team-based effort to meet specific objectives within a defined period
of time.
The definition of a program is a long-term endeavor undertaken to implement a strategy or mission
to meet business or organizational goals. A program is realized through multiple projects and
ongoing activity.
Outcomes
Projects are completed by the committed target date and within the allocated budget
Stakeholder value is maximized through continuous evolution with stakeholders of project
parameters (scope, budget, time lines, quality) as necessary
The risk within the customer's business environment is reduced through precisely defined
projects with clearly identified and managed risks
Programs controlling multiple projects achieve maximization of value through coordination
of trade-offs between requirements and solution space, and of incremental project
completion and delivery
Productivity is increased by a clear definition of roles, responsibilities, and deliverables,
which result in faster startup through the use of knowledge management, less rework, and
more productive time available to the project
Project resource commitments are clearly separated from operational workload demands
Customer and project teams form more quickly and use common terminology, facilitated by
clearer communication
• Customer satisfaction increases through visibility of the project plans, schedule, and
actual performance against the project objectives
Scope
Programs and projects are similar in that they both require planning and oversight. However, they
are different in a number of ways. Projects are a temporary endeavor with a simple management
structure, whereas programs are long-term, have a more complex management structure (typically
involving a steering committee), and are carried out by a number of projects. In addition, the
success or failure of a program is more likely to affect the bottom line of a business.
The same activities apply to both Program and Project Management, but with differing scope and
time scales. Activities within the Program and Project Management process can be classified into
four basic groups:
1. Defining and initiating
2. Planning
3. Executing, monitoring and controlling
4. Closing
A project usually consists of a series of phases, known as the project life cycle, and these groups
of process activities can be applied to each phase individually or to a set of multiple phases.
Therefore, these groups do not necessarily correspond to the phases of the project life cycle. For
example, in a waterfall project, executing and controlling activities can be completed in the design
phase of a project, alongside or followed by planning activities for the development phase.20
•
•
•
•
[A3] Direction
The activities described represent a broad model for Project Management activities, which is
largely applicable to both projects and programs alike. A program is realized through multiple
projects and ongoing activity.
Includes
Identifying program and project goals
Establishing clear and achievable objectives
Balancing the competing demands for quality, scope, time, cost factors and resources
Creating project plans
Program and project status reporting to stakeholders
Reconciling the specifications, plans, and approach to the different concerns and
expectations of various stakeholders
Running joint projects with any external agent (such as business, customers,
suppliers):
– Such projects might need to establish agreed standards and conventions
– Alternatively, in the case of multi-supplier projects, there can be reporting
responsibilities to the prime contractor while in-house practices apply within each
contractor's scope
Excludes
Performance and delivery activities (many process categories carry out this work)
Promotion of the end result to production (Deployment Management, usually within a
program or project context)
20. IBM WWPMM Concepts.

•
•
•
•
[A4] Realization
[A4] Realization
Description
Purpose
The Realization process category exists to create solutions that will satisfy the requirements of IT
customers and stakeholders, including both the development of new solutions and the
enhancements or maintenance of existing ones. Development includes options to build or buy the
components of that solution, and the integration of them for functional capability.
This process category encompasses the engineering and manufacturing of information technology
products and services and includes the making or buying of solutions, systems, integration, and
extensions to existing solutions. Maintenance and end-of-life shutdown activities (requiring
solution adjustment) are also addressed in this category.
The basic unit of work is assumed to be a project. However, these projects can vary from quite
small and of short duration to very large and long-term. The processes act together, often
iteratively and in parallel, in a project-driven context to create information technology solutions for
specific sets of stakeholder requirements.
Many engineering disciplines are relevant to the achievement of successful outcomes for these
projects. Examples of such disciplines include:
Performance engineering
Test engineering
Requirements engineering
Rationale
The Realization process category addresses a broad range of systems and service synthesis
activities, including integration of hardware components, software and network components,
applications development, and other modifications to the computing infrastructure. This process
category accommodates all levels of the solution's configuration (individual parts, subassemblies,
distributed components, among others) and component types (hardware, software, printed
documentation, skills, architectures and designs, training).
Value
Lays the foundation for the business to receive value from its investment in IT by creating
solutions that meet customer requirements
Ensures that standards and principles (such as buy or build guidelines) are followed
Provides fully integrated solutions with predictable performance characteristics
Obtains full stakeholder agreement that solutions are ready for deployment
Produces high quality work products
Processes
A44 Solution Test
•
•
•
•
[A4] Realization
[A41] Solution Requirements

Purpose
The purpose of the Solution Requirements process is to provide “a systematic approach to finding,
documenting, organizing, and tracking a system's changing requirements,”21 so that an agreed
understanding is reached as to what the solution should do.
Definition of solution requirement: “A condition or capability to which the system must conform.”22
Outcomes
Stakeholder agreement on high-level requirements is achieved before the solution is
designed, developed, and deployed
Detailed requirements are evolved iteratively with solution design, development, and
testing
Trade-offs between requirements and solution are managed to maximize stakeholder value
An accurate understanding of solution requirements exists, enhancing the probability that
the correct solution will be created
Customer, stakeholder, and user requirements are clearly defined and documented
Traceability is maintained between requirements and solution specifications derived from
them
Rework due to incorrect or misunderstood requirements is minimized
Scope
This process focuses on translating or elaborating agreed customer (business) requirements and
IT stakeholder-generated requirements or constraints into solution-specific terms, within the
context of a defined solution project or program.
It includes establishing operational requirements engineering approaches. Examples often cited
include IEEE 830 Recommended practice for software requirements specifications, IEEE Software
Engineering Body of Knowledge, CMMI and the ITIL V-model (ITIL Service Transition). 23
Includes
Business context modeling
Collecting, understanding, validating, formalizing and documenting solution
requirements
Clarifying, analyzing, and refining the requirements from the Stakeholder
Requirements Management process
Ongoing management of requirements for this solution
The complete Solution Requirements taxonomy, including:
– Functional requirements
– Non-functional requirements, under headings such as Service Management and
Compliance
– Deployment requirements (packaging, education, and training)
– Usability requirements
– Change cases and scalability requirements
21. IBM Rational Unified Process

23. See ITIL Service Design, p167
•
•
•
•
[A4] Realization
– Testing requirements
– Stakeholder acceptance criteria
– Solution life cycle requirements, including solution shutdown and retirement
Risk and feasibility analysis of requirements
Requirements baseline generation and traceability audits
Service management considerations
Business modeling discipline and requirements management discipline
Excludes
Translation from requirements to design specification (Solution Analysis and Design)
The life cycle management of customer wants and needs through agreed, prioritized
business requirements (Stakeholder Requirements Management)
Configuration Management
Activities
A411 Establish Solution Requirements Framework
A412 Refine and Verify Business Context
A413 Document and Analyze Solution Requirements
A414 Validate Solution Requirements with Stakeholders
A415 Manage Solution Requirements Baseline
A416 Evaluate Solution Requirements Performance
[A42] Solution Analysis and Design

Purpose
The Solution Analysis and Design process exists to create a fully documented design from the
agreed solution requirements, describing the behavior of solution elements, the acceptance
criteria, and agreed measurements.
Outcomes
Solution designs optimize the trade-offs between requirements and constraints
Stakeholder agreement on high-level solution design is achieved before major investments
in solution development is done
Reuse of existing solution designs and components minimizes time-to-implementation and
improves solution quality
Flexible and effective designs reduce the total cost of ownership over the complete solution
life cycle
Scope
Design of all aspects of the solution necessary to meet stakeholder requirements.
•
•
•
•
[A4] Realization
Includes
Creating and managing design baselines (specifications baseline, component
architecture baseline) throughout the full range of the solution life cycle including
solution shutdown and retirement
Ensuring solution design compliance with the business and IT architectures
Identification and consideration of constraints, such as budget, and making cases for
constraint relief or seeking guidance when a sound solution design is not achievable
against those constraints
Creating different solution architectural views (component model, operational model,
deployment model, data model)
Evaluating trade-offs (such as financial cost alternatives) and making design and
sourcing approach decisions (make versus buy versus reuse)
Making architecture exception requests
Modeling, simulation, and prototyping
Design of all required solution elements (application, infrastructure, process,
organization, data, training, deployment, technology, testing)
Systems operation and management design, such as significant event definition,
monitoring data definitionHigh and low level design
Ensuring cross-functional participation in design acceptance from service
management disciplines
Excludes
Enterprise architecture (Architecture Management)
Requirements management (Stakeholder Requirements Management, Solution
Requirements)
Procurement (Supplier Management)
Activities
A421 Establish Solution Analysis and Design Framework
A422 Create Conceptual Solution Design
A423 Identify and Select Solution Components
A424 Create Detailed Solution Design
A425 Validate Solution Design With Stakeholders
A426 Evaluate Solution Analysis and Design Performance
•
•
•
•
[A4] Realization
[A43] Solution Development and Integration

Purpose
The Solution Development and Integration process exists to bring together all of the elements
specified by the solution design, regardless of whether they are to be created or acquired, and to
complete their customization, configuration, and integration.
Outcomes
Agreed solutions are produced to approved specifications, on time, within budget and
generally maximizing stakeholder value
Frequent demonstrations of capabilities to stakeholders are done to provide feedback on
requirements, other specifications, and implemented assets
Lessons learned are fed to key stakeholders so requirements and other specifications can
be evolved as necessary
Solutions are ready for testing and examination of solution capabilities
All necessary elements exist to support Solution Management (life cycle, maintenance,
known errors, documentation, best practice guidance, and others)
All solution components are identified and tracked
Solution characteristics are fully verified before Solution Acceptance activities
Scope
Includes
Establishing development standards
Development of new functionality
Integration of new and existing functionality
Use of all design elements
Prototyping
Creating alpha, beta, and general availability versions of solutions
Making any procured elements available to the solution development and integration
team. These can come from external or internal providers
Working in conformance with agreed version control policies and procedures for
solution elements, at whatever level of assembly or integration
Excludes
Testing (unit testing is considered to be in the Solution Test process, even if performed
by the implementer or builder)
Solution pilot and deployment (Deployment Management)
Asset Management
Administration of version control (includes Configuration Management of elements
within the solution during the development phase)
Called change management version control (CMVC) in CMMI
•
•
•
•
[A4] Realization
Activities
A431 Establish Solution Development and Integration Framework
A432 Define Solution Development and Integration Plan
A433 Prepare Solution Development and Integration Environment
A434 Acquire or Create Solution Components
A435 Integrate Solution Components
A436 Refine and Tune Integrated Solution
A437 Verify Integrated Solution
A438 Evaluate Solution Development and Integration Performance
[A44] Solution Test

Purpose
The Solution Test process exists to validate prior to deployment that the solution and its features
conform to design specifications and requirements. It also verifies that interim work products exist
and conform to standards.
Testing is performed throughout the entire life cycle of the solution, including post-deployment.
Outcomes
Solution functionality is verified and documented
The actual characteristics and behavior of the solution are well known. Any differences with
the solution requirements and agreed design specifications are reported.
Solution defects are identified before the decision is made to migrate to the production
environment
Developers and stakeholders receive thorough quantitative and qualitative assessments of
solution quality. (It is intended that the developers and stakeholders take some action as a
result of having received this information.)
Stakeholder expectations match solution characteristics.
Scope
The ITIL Service Transition book provides useful discussion and examples. See the discussions
around the service V-model.24
Includes
All types of testing, such as:
– Unit testing
– Integration testing
– Acceptance testing
– Usability testing
– Operability testing
– Security testing
– Regression testing
Test case development
24. ITIL Service Transition, figures 4.21 and 4.30

•
•
•
•
[A4] Realization
Generating test results

Managing the documentation of the test results
Satisfying the requirements of the test management checklist
Excludes
Fixing errors (depending on the nature of the error, this could involve any combination
of Solution Requirements, Solution Analysis and Design, Solution Development and
Integration)
Design for testability (Solution Analysis and Design)
Knowledge management
Gaining acceptance (Solution Acceptance)
Piloting (Deployment Management)
Auditing (Solution Acceptance)
Activities
A441 Establish Solution Test Framework
A442 Develop Solution Test Strategy and Plans
A443 Prepare and Manage Solution Test Environment
A444 Perform Solution Test
A445 Analyze and Report Solution Test Results
A446 Evaluate Solution Test Performance
[A45] Solution Acceptance

Purpose
The purpose of the Solution Acceptance process is to validate that the proposed solution, either
as individual artifacts or in its complete form, meets acceptance criteria at defined checkpoints
Outcomes
Stakeholders agree before deployment that all requirements have been met
The solution's capability to meet service level agreements is validated
Transition of the solution into live service presents minimum risk
The production environment remains stable and predictable after incorporating this solution
Those responsible for delivering service and support are properly prepared to do so
Scope
ITIL defines acceptance as: “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.” 25

•
•
•
•
[A4] Realization
This process operates throughout and beyond the lifetime of a solution realization project. An
instance of examining the acceptance of a service can be triggered post-deployment, perhaps as
part of a pilot rollout.
Includes
Periodic review of solution project performance to date and status in respect of
solution acceptance criteria
Involvement of all relevant stakeholders, such as:
– Solution customer
– Solution developer
– Provider of service for the solution once deployed—this includes operational staff
as well as management
– Interested parties in relation to non-functional concerns, like security, compliance,
conformance to architectural and development guidelines)
– Users
Assisting in the development of approved solution plans and commitments
Obtaining the customer perspective on prototype work products and accepted
solutions
Working with the customer to facilitate acceptance of the solution
Working with the customer to facilitate acceptance of solution shutdown and
retirement
Documenting how the confirmed requirements are met in the accepted solution and in
interim milestones
Identifying and tracking of all acceptance review results and issues
Excludes
Testing (Solution Test)
Providing education and training (Deployment Management)
Establishing service levels (Service Level Management)
Activities
A451 Establish Solution Acceptance Framework
A452 Create Solution Acceptance Plan
A453 Define Solution Acceptance Criteria
A454 Perform Solution Acceptance Review
A455 Certify Solution Acceptance
A456 Package Certified Solution
A457 Evaluate Solution Acceptance Performance
•
•
•
•
[A5] Transition
[A5] Transition
Description
Purpose
The Transition category of processes exists to support any aspect related to a life cycle status
change in solutions and services. The processes provide defined and repeatable approaches to
planning, effecting and recording these transitions and can be applied to all stages of the life cycle.
They also serve to maintain control over the Information Technology (IT) resources that are subject
to such status changes. Further, the processes in this category provide vital enabling information
to other process areas related to the management of IT. Using these processes, developments in
IT capabilities supporting the stakeholding businesses and customers achieve their desired
operational status from which value can be derived.
Rationale
A transition can vary in scope and scale from a roll out of a major solution to a large population of
users across multiple geographic territories to the installation of a fix or patch to a single
configuration item or the controlled update of an individual software module during development.
Transition instances can also be triggered by changes in the service provider arrangements,
whether or not there is also a change in service capabilities and characteristics. Any modification
to a known set of resources carries with it some risk of failure and so, whatever the motivation for
the transition, there is a need to ensure that approaches which minimize that risk are followed and
that information about the state of resources is maintained.
Value
Improves the speed of innovation while balancing the business need for stability in the IT
infrastructure
Controls and maintains accurate information on the infrastructure, applications, and
services
Implements solutions that provide new functionality, eliminates the root causes of defects
or performs tuning actions without business disruption
Enables gradual and measured improvements in the way that changes are introduced into
complex and interdependent live environments
Supports the efficiency and effectiveness of other processes by providing accurate
information on managed elements (configuration items (CIs), managed objects, among
others)
Processes
A51 Change Management
A52 Release Management
A53 Deployment Management
A54 Configuration Management
•
•
•
•
[A5] Transition
[A51] Change Management

Purpose
The purpose of the Change Management process is to achieve the successful introduction of
changes to an IT system or environment. Success is measured as a balance of the timeliness and
completeness of change implementation, the cost of implementation, and the minimization of
disruption caused in the target system or environment. The process also ensures that appropriate
details of changes to IT resources (assets, CIs) are recorded.
Basically, a change is anything that alters the status of a configuration item (CI). This typically
includes anything that adds to, deletes from, or modifies the IT environment. The definition of a
change is the addition, modification or removal of approved, supported or baselined hardware,
network, software, application, environment, system, desktop build or associated documentation.
A change request (for which RFC is an established synonym) is the means for documenting
proposed change and actual change activity in IT resources or capabilities. Change requests can
be triggered for a wide variety of reasons, from a wide variety of sources. Change requests can be
concerned with any part of the infrastructure or with any service or activity.
Outcomes
As a result of the successful implementation of the Change Management process:
Changes are introduced in a timely and controlled manner
Proposed changes are not approved nor introduced without an accurate assessment of
their costs and other effects
Incidents resulting from the introduction of changes are minimized
Service quality is measurably improved
Appropriate balance is maintained between the business need to deploy innovation and the
need to maintain the stability of IT service
Scope
Change Management typically begins with the creation of a Change Request (RFC). The change
request documents details of the proposed change in order to support a range of business and
technical assessments, leading to approval (or rejection) and ultimately to application of the
change.
The Change Management process represents a pattern of activities and work flow, which can be
implemented over a range of contexts. The most prominent contexts include operations and
development. Operations Change Management and Development Change Management are
similar in a number of ways, including recording of all change requests, assessment of all change
requests prior to approval, a team-based approach to change approval, and review of change
effectiveness. However, they are different in a number of ways:
Development Change Management addresses changes proposed to a system under
development. These changes may include requests for new functionality, patches, or
redevelopment. In contrast, Operations Change Management focuses on changes to
operational CIs in the entire IT infrastructure. These changes can include capacity tuning,
asset transfer, and system resets.
Changes are assessed and approved using a team. Each context typically has its own
change board and membership, addressing different types of changes, and using different
assessment criteria. In development, the team is often known as the Change Control
Board; in ITIL, the term Change Advisory Board is used. A higher level board can be
established to ensure integration of changes across contexts.
Change Management can appear in other contexts besides operations and development. There
can be a single implementation of the Change Management process or several, with each
•
•
•
•
[A5] Transition
implementation covering the scope of a defined context. Factors such as size of the organization
and different start and end points defining a change can lead to multiple implementations of
change management, with each following the process principles and pattern described but
employing procedures and decision criteria customized for their context.
This process establishes classification and categorization schemes to assist with change
assessment activities. It also defines the implementation approaches that will be assigned to
approved changes in order to standardize the supervisory control levels, consistent with the
assessment recommendations. ITIL, in the context of managing production environments, uses
the term Change Model for these schemes.
Definition of Change Model: “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).”26
Examples of change models:
A standard change is “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.”27
An emergency change is “A Change that must be introduced as soon as possible. For
example to resolve a Major Incident or implement a Security patch.”28
For software development, there will frequently be different change types based on the
impact to the overall system, and hence requiring different levels of approval, such as
architectural change as compared with scope change, and change that is local to one
component.
Some activities in the process require examination of several or all changes collectively rather than
on an individual basis. For example, scheduling changes for implementation requires
consideration of the other changes planned for the same dates and target environments in order
to identify conflicts.
Includes
Planned changes, standard changes (pre-approved by policy), and emergency
changes (policy exception request)
Establishing both recurring and one-time only schedules (change windows) during
which changes can be performed without negatively affecting commitments, such as
project schedules, projected availability, or SLA commitments
Enforcement of standard methods and procedures from request for change through
post implementation review
Establishing regular meetings and communication schedules to evaluate proposed
changes and schedules
Control and management coordination of the implementation of those changes that
are subsequently approved
Maintenance of open channels of communications to promote smooth transition when
changes take place

•
•
•
•
[A5] Transition
Increased visibility and communication of changes to both business and support staff
Excludes
Requirements Management (Stakeholder Requirements Management)
Creation of new or revised functionality (Realization category processes)
Building the packaging for the delivery of new or revised functionality (Release
Management)
Technical implementation, such as distribution, preparation, installation, and back out
if necessary (Deployment Management)
Configuration Management, although the interface to this process must be managed
Asset Management, although the interface to this process must be managed
Business transformation and organizational change (IT Customer Transformation
Management)
Activities
A511 Establish Change Management Framework
A512 Create and Record Change Request
A513 Accept and Categorize Change
A514 Assess Change
A515 Authorize and Schedule Change
A516 Coordinate Change Implementation
A517 Review and Close Change
A518 Monitor and Report Change Management
A519 Evaluate Change Management Performance
[A52] Release Management

Purpose
The purpose of the Release Management process is to prepare and finalize release packages that
are fit for deployment so that optimal business value will be attained when deployment occurs.
Definition of release: “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.” 29
Outcomes
As a result of the successful implementation of the Release Management process:
Release packages – whether supporting new business capability, improvement in cost
performance, or other advances in service quality - form the basis for deployment
Deployment risks to existing service quality are minimized
Customer and user satisfaction upon release deployment is increased
All implications to the parties involved in deploying or receiving a release are identified and
validated prior to the deployment event

•
•
•
•
[A5] Transition
Only authorized releases are introduced into the live environment
Scope
Release Management spans the planning and direction of the rollout of software, hardware, and
operational processes including related documentation, and operating procedures. The changes
that comprise the release are managed by Change Management, and their inclusion in the release
can be determined by time, technology interdependencies, target, risk mitigation, organization,
scale (multiple copies) or service dependencies. The design of the release will need to consider
how rollout is achieved. For example, whether or not the release can be requested by a user using
a self-service selection and then installed automatically and transparently.
Includes
Release design, creation, and testing
– For example, implementation scripts
Specifying the deployment model for a release. The deployment model provides a
template of the activities and plans from which specific deployment instances can be
customized for geography, scale, local conditions, and other factors
Checking and testing training materials and incorporating them into the deployment
model
Verification of successful release package installation, including ensuring that the
integrity of function has been maintained
Roll back (also known as back out) mechanisms and procedures
Excludes
Solution Realization (creation of functionality, usage procedures, training materials,
and any other release deliverable) (Realization category)
Testing of solution functionality (Solution Test)
Management of change requests (Change Management)
Deployment of release packages (Deployment Management)
Activities
A521 Establish Release Management Framework
A522 Plan Release Strategy
A523 Design and Build Release
A524 Test and Verify Release
A525 Monitor and Report Release
A526 Review and Close Release
A527 Evaluate Release Management Performance
•
•
•
•
[A5] Transition
[A53] Deployment Management

Purpose
The purpose of the Deployment Management process is to place releases and other desired
changes into their target environments, and to activate them in order that the functionality and
operational improvements they contain can create their intended value.
Definition of Deployment: “movement of new or changed hardware, software, documentation,
Process, etc to the Live Environment.”30
The other desired changes includes transferring the responsibility for any subset of an IT
endeavor’s operations from ownership by one service provider to another, while maintaining
service continuity. For certain such transfers, deployment involves managing the effective transfer
of resources necessary to deliver the service. Resources include staff, technology infrastructure,
and intellectual capital.
Outcomes
As a result of the successful implementation of the Deployment Management process:
New capability is introduced on a timely basis, and with minimized risk, disruption and cost
Transfers of service responsibility are effected on a timely basis, and with minimized risk,
disruption and cost
All parties involved in a deployment (for example, users of the capabilities being deployed,
service providers performing the deployment) are appropriately prepared, trained and
skilled to ensure successful deployment
In the event of failures during deployment, contingency plans ensure the expected level of
service quality is delivered
Scope
Deployment Management is primarily triggered by an instruction to roll out any approved
combination of software, related hardware, documentation, and operating procedures to one or
more defined targets (for example: systems, user groups) within constraints such as cost and time.
An alternative trigger for the instantiation of Deployment Management relates to the transfer of the
responsibility for one or more services between providers or across business or organizational
boundaries. At the other end of the scale, the implementation work related to a change which
impacts a single CI is also performed by this process.
The completion of each deployment is indicated when the stakeholders affirm that the expected
outcomes of a deployment are achieved and a business-as-usual operational service state has
been attained.
Includes
Deployment planning and co-ordination with affected parties
Identification of resources (hardware, software, processes and procedures, and staff)
to be deployed, or to be transferred between service providers
Creating capabilities and procedures to support deployment activities, and to verify
the readiness of and account for resources impacted
Creating a plan for continuity of service
Execution of the deployment plan, including:
– Electronic distribution of software and other soft-copy items

•
•
•
•
[A5] Transition
– Invoking logistical movements for physical items

– Installing technical resources
– Activating the desired configuration
– Testing the installation against defined criteria (as provided in the Release Package
and Change)
– Back out of installed items, when needed
– Delivering training
– Providing initial user assistance
Assessment of readiness to begin service delivery, and for handover to business-as-
usual
Management of risks and issues related to the deployment activities.
Excludes
Logistics and movement of physical assets (Asset Management)
Preparation and commissioning of the supporting environment (Facilities
Management)
Accounting for capital transfers and deployment expenditures (Financial
Management)
Program and project management techniques (Program and Project Management)
Achievement of business benefits from new functionality (IT Customer Transformation
Management)
Updates to the CMS (Configuration Management)
Knowledge and skill transfer (Knowledge Management)
Activities
A531 Establish Deployment Management Framework
A532 Plan Deployment Program
A533 Prepare Deployment Capabilities
A534 Perform Transition Administration
A535 Perform Deployment
A536 Verify Deployment and Activate Service
A537 Review and Close Deployment
A538 Monitor and Report Deployment Program
A539 Evaluate Deployment Management Performance
•
•
•
•
[A5] Transition
[A54] Configuration Management

Purpose
The purpose of the Configuration Management process is to maintain the integrity of the
configuration items (CIs) employed in, or related to, IT systems and infrastructure in either a
development or operational context, and to provide accurate information about CIs and their
relationships.
Configuration Management emerged out of complementary needs within both IT development and
IT operations. IT development needs to maintain the integrity of evolving development artifacts in
a development project. Similarly, IT operations should maintain the integrity of CIs that have been
made operational.
Definition of a configuration item: “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.”31
Outcomes
All configuration items within IT systems and infrastructure are accurately identified and
cataloged
All configuration items are adequately tracked and controlled
Authorized requests to obtain CIs from secure libraries or stores (or to return them) are
satisfied promptly and accurately
Accurate configuration information is provided in response to informational requests
Any exceptions between configuration records and the corresponding CIs are identified
and corrected
In development projects: development CIs in multiple development streams are controlled
and coordinated
Scope
Relationship with Asset Management
To properly understand Configuration Management, it is necessary to understand its relationship
with Asset Management. Asset Management keeps track of things of value (assets) to an IT
organization, whether that value is financial, technical, or otherwise, throughout the asset's entire
life cycle. That life cycle stretches from the time the asset is ordered or commissioned to the time
when it is retired and disposed.
At various stages in an asset's life cycle, the usage of that asset can cause it to become a part of
some larger object requiring management (for example, a processor is added to a pool of
processors allocated to a particular task) or it can be split into a number of parts at smaller
granularity (for example, a physical server is operated as several virtual servers). Similarly, an ERP
system licensed from a vendor might represent one or a handful of assets to be tracked (for
financial or contract management purposes), whereas it can represent hundreds of modules which
must be identified individually. For example, for local customization, problem determination, or
maintenance patch application purposes.

•
•
•
•
[A5] Transition
The characteristic of these events is that the asset has been applied to some defined purpose,
typically through any or all of the Solution Development and Integration process, the Release
Management process and the Deployment Management process. At these times, those parts
become configuration items (CIs) and are managed by Configuration Management. Configuration
Management focuses on the internal and external relationships of a CI and addresses the
configuration needs of a stage in an asset's life cycle.
For instance, during development of a software asset, Configuration Management might be used
for source code control of the components that make up that asset. Another instance is when a
system becomes operational within the IT infrastructure. In that instance, Configuration
Management is used to maintain operational information about that CI and its relationships to other
CIs in the IT infrastructure. The two most widely recognized uses of Configuration Management
are development Configuration Management and operations Configuration Management.
Configuration Management in Development and Operations
Configuration Management addresses the needs of both IT development and IT operations. The
characteristics of these domains are similar,32 yet also have differences. Similarities include:
Both development and operations focus on the various configuration items that make up
their domains. In development, these include evolving hardware, software, and
documentation that constitute an IT system being developed. In operations, these include
fully developed hardware, software, and documentation that have been deployed and made
operational within the IT infrastructure.
Both development and operations maintain information about CIs and their relationships.
On a regular basis, that information is checked for accuracy against the actual
configuration items and inaccurate information is corrected.
Differences between development Configuration Management and operations Configuration
Management include:
IT development maintains the integrity of development CIs primarily by controlling the CIs
themselves, whereas IT operations maintains the integrity of operational CIs by controlling
information about the CIs.
Check-in/check-out of IT development CIs is a normal practice in Configuration
Management for IT development. (There is a distinct difference in how check-in and check-
out is performed for electronic as opposed to physical CIs.) IT operations does not perform
check-in/check-out of CIs.
IT operations focuses on controlling updates to information about CIs. Significant
information about CIs must be manually maintained. In contrast, information about
development CIs is primarily obtained from the CI itself.
Development CIs (such as software and hardware components and document chapters)
are typically smaller-grained than operational CIs (such as PCs, applications, servers, and
others).
The configuration management system for IT development (often called a source code
control system) is typically maintained separately from the configuration management
system for IT operations, and the technology and procedures used by each system is
usually different.
The CIs that make up an operational IT infrastructure are typically also considered assets.
However, most CIs in a development project are not considered to be assets because their
value to the IT organization is considered too small (or too intangible) to track. For this
reason, a development project might have few assets tracked by Asset Management other
than the overall system under development.
32. Industry examples of this can be seen in ISO/IEC 15288 Systems and Software Engineering - System Life Cycle
Processes and ISO/IEC 12207 Systems and Software Engineering - Software Life Cycle Processes.
•
•
•
•
[A5] Transition
The similarities in Configuration Management between IT development and IT operations are

sufficient to define a single process at a high level. The differences between IT development and
IT operations are significant only at a lower level of the process.
Common Data
In practical terms, Asset Management and Configuration Management carry out their activities
using data about these assets and CIs, which is largely common to them both, though each has
some attributes and relationships not significant to the other. Successful implementation of both
processes requires joint work on their data models and clear rules (that is, governance) on which
process owns any shared attribute.
Types of CIs
The ITIL definitions of asset and of configuration item include a range of types of IT elements which
can fall under Configuration Management. Whether an implementation covers all or just some of
these types, it is likely that there will be some process aspects that are dependent on the needs of
different component types. Consideration of a few examples illustrates this:
Each hardware item is a candidate for both configuration and asset management, though
probably at different levels of granularity. An IT organization will want to keep track of that
hardware item throughout its life cycle from the standpoint of Asset Management. At the
same time, when that system is operational, Configuration Management might be
interested in internal hardware components (which are CIs) as well as other CIs that have
some operational relationship to this CI. Hardware items cannot usually be cloned.
Software components might have no record in the asset register. They can be subject to
tight access controls (for example, to avoid erroneous multiple update during development)
and at the same time they can be cloned to create as many instances as needed within
limitations such as license counts. Larger software elements, such as applications can be
both a CI as well as an asset.
The process will also need to take into account the arrangement of the set of internal and external
service providers and establish appropriate interfaces with the Configuration Management process
of those service providers.
Includes
Establishing naming conventions for configuration items and relationships
Designing, creating, populating, and updating the Configuration Management System
(CMS)
Managing movements into and out of secure libraries
Supporting configuration item audits
Identifying configuration item interdependencies
Linking configuration item changes to specific change requests (RFCs)
Defining and reporting configuration baselines
Excludes
Inventory tracking (Asset Management)
Procurement of configuration items (Supplier Management)
Tuning and installing configuration items (Capacity Management, Deployment
Management)
Assets that are not CIs, such as:
– Items ordered but not received
– Items no longer in operation
•
•
•
•
[A5] Transition
– Bulk inventory
– Assets not operationally managed
Activities
A541 Establish Configuration Management Framework
A542 Identify Configuration Items
A543 Control Configuration Items
A544 Report Configuration Status
A545 Verify and Audit Configuration Items
A546 Evaluate Configuration Management Performance
[A55] Asset Management

Purpose
The purpose of the Asset Management process is to control all assets owned by the IT endeavor
throughout their life cycle and to maintain accurate information about them in an Asset Register.
The aspects of asset control under this purpose include inventory, contractual (licensing,
maintenance), ownership and location
ITIL provides the following definitions:
Asset: “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, Organisation, Process, Knowledge, People, Information, Applications,
Infrastructure, and Financial Capital.”33
Asset Register: “A list of Assets, which includes their ownership and value. The Asset
Register is maintained by Asset Management.”34
The definition of asset is much broader than those in widespread usage within the IT industry.35 In
this model, many of the types identified are controlled by other processes specialized for the
management issues that pertain to them.
Items Management, Organization, Process are the subject of the IT Governance and
Management System category of processes
Knowledge Management is a process in its own right
People are recruited, developed, and assigned to responsibilities by the Workforce
Management process
Financial Capital is under the custodianship of the Financial Management process, with
interfaces to this process where Asset activities have an impact on financial valuation (for
example, by a decision to dispose of an asset or to transfer ownership to a new owner).
The technology object types Information, Applications, Infrastructure are all covered by this
process, where each individual item can qualify for any of the asset control purposes in scope. For
example, it is not unusual for accessories for PCs (such as keyboards, mice) to be excluded from
asset control.

35. See HTTP://en.wikipedia.org/wiki/IT_asset_management
•
•
•
•
[A5] Transition
Outcomes
As a result of the successful implementation of the Asset Management process:
Value is maximized from technology assets over their lifetime
Assets are provided in an accurate and timely manner to supply, movement or other
requests
Accurate and timely information about technology assets supports informed IT decision
making, at both strategic and tactical levels
Exposure to risks relating to IT assets is minimized
IT assets are managed in compliance with legal, industry and corporate standards and
requirements
Governance of assets drives the right trade-offs in investments in asset and usage of
assets
Scope
Asset Management has dual responsibilities:
1. To control each asset from initial creation (such as receipt from suppliers) through all life
cycle events (such as change of location, transfer of ownership, change of use) until
eventual retirement or disposal.
2. To identify, collect, maintain, control, and report inventory and financial information about IT
assets throughout their life cycle
Includes
License management (including software license compliance)
Lease and maintenance administration of each asset
Inventory management (includes physical components and specifications)
Allocation of available assets to meet approved requests
Physical logistics (such as transportation) of assets
Retirement of outdated assets
Triggering requisition for the procurement of additional assets (for example, if a policy
of maintaining minimum inventory stock levels for standard, frequently needed asset
item is in place)
Financial life cycle of assets (including valuation)
Excludes
Risk Management
Contract and Supplier Management (including Procurement) (Supplier Management)
Configuration Management (logical relationships)
Managing the security of an asset (Facilities Management, Security Management)
•
•
•
•
[A5] Transition
Activities
A551 Establish Asset Management Framework
A552 Ready and Control Asset
A553 Control Asset Information
A554 Monitor, Audit and Reconcile Asset Records
A555 Oversee Asset Contracts and Financials
A556 Retire and Dispose of Asset
A557 Report Asset Information
A558 Evaluate Asset Management Performance
•
•
•
•
[A6] Operations
[A6] Operations
Description
Purpose
This category contains the operational service processes that enable daily IT activities using
available infrastructure, applications, and services to meet service level agreements (SLAs) and
business objectives. Responsibility for delivery of service sits here. Managing contact and
communications with users (for example, service requests) is an important function as these
processes sense and respond to day-to-day aspects of operations and events, quickly and
correctly to address any incidents and problems that might arise.
Rationale
The Operations category comprises all the activities and measures necessary to enable and
maintain the intended and committed use of the infrastructure, applications, and services. The
processes in this category require close integration to function effectively. Operational plans and
workload balancing are augmented by constant operational monitoring throughout service
delivery. This operational data is used by many processes to identify, analyze, and quickly resolve
any anomalies. The Operations category is also the focal point for receiving and responding to a
wide variety of user service requests. This process category is vital to operating organizational
constructs such as a Service Desk or an Operations Bridge or an Operations Center. Problem
Management is included in this category because of its dependence on incident management
information.
Value
Operates, manages, and maintains an end-to-end infrastructure to facilitate the delivery of
the services to the business, meeting all of the agreed to requirements and targets
Provides sense and respond correction and optimization for any fluctuations within the
designed operating characteristics of the IT infrastructure, applications, and services
Provides a focal point for reliable, robust, secure, and consistent delivery of service,
minimizing potential negative impact on the efficiency and effectiveness of business
processes
Establishes responsibility for user contact, service requests and other interactions,
improving communications and customer perception of service quality
Provides the designed level of integrity for data at all stages of its life cycle, including
protection of business (and IT) data from accidental loss
Ensures that any faults or issues are recognized and appropriately addressed
Processes
A63 Data Management
A64 Event Management
A65 Incident Management
A66 Problem Management
A67 Identity and Access Management
•
•
•
•
[A6] Operations
[A61] Request Fulfillment

Purpose
The purpose of the Request Fulfillment Process is to receive service requests from users and route
each request to the appropriate process for handling. Some service requests are handled by the
Request Fulfillment Process, whereas many others are routed to other processes for fulfillment.
Request Fulfillment can be the contact management process for an implementation of an IT
Service Desk (or equivalent).
Definition of service request: “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.”36
Outcomes
As a result of the successful implementation of the Request Fulfillment Process:
User and customer satisfaction is enhanced
User requests to the IT organization are successfully received and processed for fulfillment
or other appropriate handling
Requests are accurately and appropriately routed to the correct process and correct
service provider for handling (fulfillment)
Service level targets for service desk responsiveness and quality are achieved
Users receive accurate and timely communication concerning the status of their service
requests
Scope
At the initial receipt of a service request from a user, the nature of the request and information
within it has to be established. Many such service requests can be dealt with by the set of activities
within this process. Other service requests, once initially assessed, will be beyond the capability of
this process to perform the primary added-value work needed by those requests and will be
passed on to other, more specific processes. This process will interact at the process framework
level with the specific processes to determine which types of service requests should be handled
by which processes. Over time, the range of service requests which can be directly fulfilled is likely
to increase.
Examples of interactions are:
Incidents are routed to the Incident Management process
Service requests assessed as standard changes are passed directly to other appropriate
processes
Other, more significant change requests are transferred to the Change Management
process
Wherever the service request is dealt with, this process retains ownership of the service request
on the user's behalf and is responsible for achievement of service level targets relating to service
requests.
This process provides the primary interface point for users of IT services with the service provider.
Includes
Receipt and management of service requests relating to:

•
•
•
•
[A6] Operations
Incidents
Standard changes (such as deployment of standard software)
Identity
Access rights
Security service requests
Information, advice, guidance
User satisfaction interactions
Complaints
Items which are assessed to be change requests (rather than standard changes) can be
routed to Change Management
Excludes
Those interactions between the business (and other customers) and the IT service
provider that consider the status, scope or coverage of the overall service provision
agreements. (Service Level Management)
The direct fulfillment of those service requests which are dealt with by other
processes. Where such fulfillment workings require direct contact between IT service
provider staff performing those processes and users, then those activities are part of
those processes. An example of this would be interacting with a user as part of
deploying a PC (Deployment Management)
Establishing entitlement limits for user communities against each service
(Combination of Service Marketing and Sales, and Service Level Management)
Granting access rights (found in Identity and Access Management)
Installing standard technical components (Deployment Management)
Activities
A611 Establish Request Fulfillment Framework
A612 Receive and Approve Service Request
A613 Fulfill or Route Service Request
A614 Close Service Request
A615 Own, Monitor, Track and Communicate Service Requests
A616 Evaluate Request Fulfillment Performance
•
•
•
•
[A6] Operations
[A62] Service Execution

Purpose
The purpose of the Service Execution process is to deliver operational services to IT customers,
by matching resources to commitments and employing the IT infrastructure to conduct IT
operations.
Definition of 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.”37
Outcomes
Services are delivered in a reliable, robust, secure, and consistent manner
Services are provided within service level targets
Resources needed to operate IT services are managed effectively and efficiently
Consumable resources used to deliver services are supplied in a timely manner
Up-to-date service metric information is available
Scope
This process is responsible for the scheduling, operation and execution of the IT-based services
which have been committed to customers. These services are of many types, including business
transaction and batch processing, and also many types of self-service functionality offered as
standard services to users.
Service Execution applies the resources made available to it through Deployment Management to
the dynamic mix of workload demands. It makes adjustments to resource allocations within the
tolerances provided and specified in the solution design.
Includes
Understanding, creation, and maintenance of operational schedules
Starting, stopping, and other operational resource management actions on system
components, applications and other services
Monitoring of system resources
Detecting events and sending significant events to Event Management
Understanding and maintenance of operational status
Managing production workloads from submission through delivery of results and from
service start to service close
Excludes
Correlating and processing significant events (Event Management)
Operational security (Security Management)
Data management, backup, and recovery (Data Management)

•
•
•
•
[A6] Operations
Activities
A621 Establish Service Execution Framework
A622 Schedule and Adjust Workload
A623 Assign and Control Delivery Resources
A624 Deliver Service
A625 Monitor and Report Service Execution Operations
A626 Evaluate Service Execution Performance
[A63] Data Management

Purpose
The purpose of the Data Management process is to ensure that all data necessary in providing and
supporting business and operational services is available for use and is actively managed from
creation and introduction until final disposal or destruction.
Outcomes
Data life cycle management policies and governance capabilities are effectively provided
Data life cycle management services are sustained in order to meet or exceed service level
commitments
Legal, regulatory, and business requirements are met for data privacy, quality, and retention
The accessibility, performance, cost, and value characteristics of data are established,
managed and optimized throughout the full life cycle
The integrity of data at all stages of its life cycle is ensured, including protection of business
(and IT) data from accidental loss and destruction
Scope
Management of the full life cycle of both externally acquired and enterprise generated data, as well
as information about that data.
Includes
Managing data as a portfolio and the overall plan for the portfolio’s elements
Cataloging and controlling all data types, such as:
– Business data
– Journals and logs
– Program libraries
– Systems management data
Accepting and cataloguing new data
Planning and control of data placement, retention, and disposalData backup and
restoration of data to prior states
•
•
•
•
[A6] Operations
Excludes
Information management activities:
– Data typing and classification (Architecture Management)
– Content management (Business responsibility, as part of each business process)
Change management
Access control and security protection (Identity and Access Management, Security
Management)
Activities
A631 Establish Data Management Framework
A632 Plan Data Portfolio Lifecycle
A633 Acquire and Prepare Data
A634 Control, Deploy and Maintain Data
A635 Backup and Restore Data
A636 Dispose of Data
A637 Monitor and Report Data Management Operations
A638 Evaluate Data Management Performance
[A64] Event Management

Purpose
The purpose of the Event Management process is to identify and prioritize infrastructure, service,
business process and security events, and to establish the appropriate response to those events,
especially responding to conditions that could lead to potential faults or incidents.
Definition of event: “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.”38
Outcomes
As a result of the successful implementation of the Event Management process:
Service quality is sustained and improved
Incidents are detected early
The time between event occurrence and detection is minimized
Appropriate actions are taken in response to events, in order to resolve some without
manual response
Responses to understood faults are started with minimal delay
Scope
Event Management is accomplished through scanning monitoring data and from this collecting,
evaluating, responding to, and reporting events throughout the business.

•
•
•
•
[A6] Operations
Not all events require a response, only those deemed significant events. Typically, a response to
a significant event involves either a predefined response or the creation of an incident in the
Incident Management process.
Includes
Providing both real time and historical event information to other IT processes, to
facilitate service quality improvement and resource availability
Providing similar information relating to the automated aspects of business processes
for business analysis
Correlation and filtering of events, to identify alert notifications and other conditions
Examination and analysis of individual events in isolation as well as events in context
with other events
Creation of incidents from event information
Capture, logging and administration of data generated by the activities within this
process
Excludes
System monitoring – Monitoring all things that happen related to a system, whereas
event management identifies meaningful changes of state that can represent faults.39
System monitorig takes place in Service Execution and Data Management.
Activities
A641 Establish Event Management Framework
A642 Detect and Log Event
A643 Filter Event
A644 Correlate Events and Select Response
A645 Resolve Event
A646 Close Event
A647 Evaluate Event Management Performance
39. ITIL Service Operation, 36

•
•
•
•
[A6] Operations
[A65] Incident Management

Purpose
The purpose of the Incident Management process is to focus on the restoration of a service
affected by any real or potential interruption which has impact upon the quality of that service.
Definition of incident: “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.”40
Outcomes
As a result of the successful implementation of the Incident Management process:
Following interruptions, IT service is rapidly restored
IT service availability is sustained at a high level
Potential improvements to services may be identified
Normal service operation is defined here as working within agreed service level targets.
Scope
The management of the life cycle of incidents (including reception, logging, acknowledgement,
classification, response, tracking and reporting) for all components involved in the provision of IT
service.
Includes
Incidents reported by users or discovered within the IT organization by automation or
people
Handling (automatically or with human assistance) of system events that have been
identified as incidents by the Event Management process
Creation of workarounds
– While service restoration has the highest priority, consideration has to be made of
the risk that a workaround could exacerbate the original incident. For example,
certain virus infections might spread beyond their initial scope if a simple service
restoration is put into effect
Implementation of workarounds (with Change Management, where required by the
change policy)
Participation within the procedures (typically involving several processes working in
conjunction) defined for handling major incidents
Excludes
Monitoring (Service Execution, Data Management)
Responding to business-as-usual perturbations in the running of services (Event
Management)
Service requests (Request Fulfillment)
IT Resilience – ensuring the continued readiness and integrity of the IT services
(Resilience category processes)

•
•
•
•
[A6] Operations
Activities
A651 Establish Incident Management Framework
A652 Identify and Log Incident
A653 Classify Incident and Provide Initial Support
A654 Investigate and Diagnose Incident
A655 Resolve Incident and Recover Service
A656 Close Incident
A657 Own, Monitor, Track and Communicate Incidents
A658 Evaluate Incident Management Performance
[A66] Problem Management

Purpose
The purpose of the Problem Management process is to resolve problems affecting the IT service,
both reactively and proactively. Problem Management finds trends in incidents, groups those
incidents into problems, identifies the root causes of problems, and initiates change requests
(RFCs) against those problems.
Definition of problem: “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.”41
Outcomes
The number and adverse impact of incidents and problems is minimized
Potential incidents are prevented
Recurrence of incidents is prevented
The management of incidents is more effective and efficient
The productivity of support staff is improved
For example, by improving Service Desk first time fix rate
An effective problem management process maximizes system availability, improves service levels,
reduces costs, and improves customer convenience and satisfaction.
Scope
The process is primarily concerned with establishing the root cause of an incident and its
subsequent resolution and prevention. The reactive function is to solve problems relating to one or
more incidents. The proactive function is to identify and solve problems before incidents occur.
Effective problem management requires the identification and classification of problems, root
cause analysis, and resolution of problems. The problem management process also includes the
formulation of recommendations for improvement, maintenance of problem records, and review of
the status of corrective actions.

•
•
•
•
[A6] Operations
Includes
Root cause analysis and identification
Solution (and workaround) definition and selection
Submission of change requests (RFCs)
Appropriate prioritization of resources required for resolution based on business need
Contribution to the collective problem resolution knowledge base
Excludes
Identification, creation and resolution of incidents (Incident Management)
Actual implementation of the resolution of a problem. Problem Management initiates
their resolution through Change Management and participates in the Post
Implementation Review (PIR)
Knowledge management methodology (Knowledge Management)
Activities
A661 Establish Problem Management Framework
A662 Detect and Log Problem
A663 Categorize and Prioritize Problem
A664 Investigate and Diagnose Problem
A665 Resolve Problem
A666 Close and Review Problem
A667 Monitor, Track and Report Problems
A668 Evaluate Problem Management Performance
[A67] Identity and Access Management

Purpose
The purpose of the Identity and Access Management process is to establish and maintain a
registry of IT user identities and their associated access rights for each service. The registry
provides a key reference for the authorization or rejection by the Security Management process of
service usage attempts.
The process provides the ability to control and track who has access to data and services. It
contributes to achieving the appropriate confidentiality, availability, and integrity of the
organization’s data.
ITIL definition of identity: “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.”42 This definition is narrower than those
established in ISO standards relating to security. For the purposes of this process, the user might
not be directly linked to one or more persons; it can take the form of an IT product or system for
which access rights must be established and tracked, and for which an identity is therefore
established.43

43. ISO/IEC 15408-1, Information technology – Security techniques – Evaluation criteria for IT security. “Part 1: Intro-
duction and general model.” Widely known as the Common Criteria.
•
•
•
•
[A6] Operations
Definition of rights: “Entitlements, or permissions, granted to a user or role. For example, the right
to modify particular data, or to authorize a change.”44
Outcomes
As a result of the successful implementation of the Identity and Access Management process:
An accurate and complete identity registry and associated rights is maintained
There is a definitive source so that decisions can be made allowing users have access to
information and the services they need while unauthorized access attempts are denied
Authorized access to data and services is aligned with security policies
Records of access attempts can be audited
The data necessary to demonstrate compliance in relation to service and information
access is available
Scope
This process operates within the set of controls described by the IT Security Policy, which itself
takes direction from the Business Security Policy. The users for whom (or which) an identity is
registered include not only those outside the IT organizational entity but also all resources involved
in running the IT capability itself. Levels of control of identities and access rights will vary
depending upon the scope of access required and the level of potential harm (fraud) from malicious
access.
Access policies can be dynamic, reflecting the need to vary access rights depending on the time
of day or the role being performed. The process must recognize that the authority to give access
rights, or even to delegate the authority to give access rights, is a normal activity for many users.
Includes
An identity schema aligned with business and security policies
Establishment and maintenance of identities
Establishment and maintenance of access rights
Translation of business rules for roles and group authorities so as to enact then within
the identity schema
Access to the registry for those processes providing affiliated security services, like
physical access (Facilities Management)
Raising warnings or revoking access rights when access attempt thresholds are
breached
Excludes
Definition, implementation, and operation of authentication mechanisms (Security
Management)
Enforcement of access rights (Security Management)
Definition of the rules for business role and group authorities – defined by the
business
Physical security and access (Facilities Management)
Security policies – defined by the business and Security Management

•
•
•
•
[A6] Operations
Activities
A671 Establish Identity and Access Management Framework
A672 Evaluate and Verify Identity and Access Request
A673 Create and Maintain Identity
A674 Provide and Maintain Access Rights
A675 Monitor and Report Identity and Access
A676 Evaluate Identity and Access Management Performance
•
•
•
•
[A7] Resilience
[A7] Resilience
Description
Purpose
The Resilience category of processes describes the analysis and proactive planning required to
enable resilient infrastructure, applications, and services. Resilience is here defined as the ability
to absorb conditions or faults without service failure and the ability to quickly return to a previous
good condition. Each process covers a range of activities from handling everyday adjustments as
required by service operations through anticipating the potential future demands upon its specific
domain.
In order to accomplish their collective mission, all processes require input from a wide range of
other processes, including such items as architectural information, problem and known error
information, solution designs, scheduled projects and changes, as well as operational monitoring
data. Resilience processes use this input to establish ongoing resilience capabilities, ensuring
service level attainment and customer satisfaction while controlling costs.
Rationale
All of the processes in this category analyze information from a variety of sources and then
generate proactive plans to minimize risks associated with the potential failure of any component
(or group of components) or human actor used to deliver services. The processes in this category
are also responsible for ensuring compliance with (internal and external) laws and regulations,
internal policies and procedures, as well as maintaining defined levels of security on information
and IT services.
Value
Ensures compliance with all security and regulatory considerations and requirements,
reducing both IT and business risk
Establishes proactive plans to ensure that infrastructure and application-based services
are reliable, robust, secure, consistent and facilitate the efficient and effective support of
business processes
Provides the means to monitor both current IT system availability as well as to project
future capacity requirements, improving IT's ability to support business direction
Establishes responsibility for operation, management and maintenance of all physical
facilities necessary to deliver services to the business
Provides assurance that agreed to IT Services will continue to support business
requirements in the event of a catastrophic disruption to the business environment
Processes
•
•
•
•
[A7] Resilience
[A71] Compliance Management

Purpose
The purpose of the Compliance Management process is to ensure adherence to laws and
regulations, internal policies, procedures, and stakeholder commitments.
Outcomes
Regulatory, audit, and other internal compliance is ensured and demonstrated
Legal liabilities and related productivity losses consequential upon any compliance breach
are avoided
The reputation and value of the brand of the businesses that IT serves is protected
Scope
Integrity (sound operating) and compliance as an outcome across all of the IT endeavor's
undertakings.
Includes
Consideration of internal and external regulations, standards and legal obligations
impacting the business where they could require IT support. For example:
– Privacy regulations
– Laws such as Sarbanes Oxley
– Industry standards and guidelines such as ISO 27001 (ISO17799), COSO and
CobiT
Specification of compliance controls needed within IT services and solutions and also
within other IT processes
Internal and external audit readiness preparations
Compliance audits
Excludes
Setting internal policies (IT Governance and Management System Framework)
Modification to IT services and solutions to establish compliance controls (through
Realization and Deployment categories)
Modification to other IT processes (through IT Governance and Management System
categories)
Operation of the defined compliance controls within the transactions of the IT
endeavor. This responsibility becomes part of the activity of each relevant IT process
Activities
A711 Establish Compliance Management Framework
A712 Identify Compliance Requirements
A713 Assess Compliance Requirements
A714 Define Compliance Controls Plan
A715 Implement Compliance Controls
A716 Audit and Report Compliance
A717 Evaluate Compliance Management Performance
•
•
•
•
[A7] Resilience
[A72] Security Management

Purpose
The purpose of the Security Management process is to establish and operate security controls and
protections over all IT assets and services in order to conform to overall business security as well
as IT-specific requirements. It includes activities to mitigate the risk posed by malicious outsiders
and insiders, and to decrease vulnerabilities in the IT services, systems and processes that would
make it easier for such malicious parties to succeed.
Outcomes
As a result of the successful implementation of the Security Management process:
The confidentiality, integrity, and accessibility of information meets agreed requirements:
• Information is available for approved purposes
• Access (whether internal or external) to protected items can be validated and tracked
• Information and systems are protected from unauthorized access and any attacks
IT services and infrastructure meet external security requirements from service level
agreements, contracts, and legislative dictates
IT security aligns with the business' overall security requirements
The reputation of the business as secure and trustworthy is protected
Scope
The process covers the life cycle of security concerns, including planning, operational measures,
evaluation, and audit. It will identify IT security threats, vulnerabilities, and risks in order to develop
an overall approach to counter and handle them that is aligned with business security
requirements. It will operate security protections and mechanisms which meet the desired level of
confidentiality, availability and integrity for information and IT services.
Includes
Information security policy
Specification of information security controls including asset use, access,
documentation, and information controls and overseeing their establishment
Operation of controls and measures such as:
– Credential operations
– Perimeter defense
– Intrusion detection
– Secure coding standards
– Key and encryption management
– Separation of duties
– Application isolation
Identification of IT security incidents
Management of supplier and partner access to services and systems
Compliance enforcement measures (related to security)
Excludes
Establishment and maintenance of identities and access rights (Identity and Access
Management)
Health and safety (Business responsibility, with contribution from Facilities
Management)
•
•
•
•
[A7] Resilience
Business security management, including trust management as it relates to business

processes (Business responsibility)
Identification of privacy requirements (within the scope of Compliance Management)
Activities
A721 Establish Security Management Framework
A722 Produce and Maintain Security Policy
A723 Analyze Security Threats, Vulnerabilities and Risks
A724 Classify Information Asset Security
A725 Plan and Implement Security Practices
A726 Operate Security Protection Mechanisms
A727 Monitor, Assess, Audit and Report Security
A728 Evaluate Security Management Performance
[A73] Availability Management

Purpose
The purpose of Availability Management is to match the availability of the IT services against the
current and future identified needs of the business or to exceed them. Availability Management
enhances the availability of services by planning long-term service availability, measuring and
monitoring service availability, and formulating service availability design criteria that meet
requirements.
Definition of availability: “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.”45
Outcomes
As a result of the successful implementation of the Availability Management process:
IT infrastructure provides a consistent level of availability that enables the business to meet
its current and future objectives
Availability related incidents and problems are minimized
The provided level of availability is cost justified and optimized
Scope
ITIL defines components of availability to be:
Reliability – “A measure of how long a Configuration Item or IT Service can perform its
agreed Function without interruption.”46
Maintainability – "A measure of how quickly and Effectively a Configuration Item or IT
Service can be restored to normal working after a Failure. Maintainability is also used in the

•
•
•
•
[A7] Resilience
context of Software or IT Service Development to mean ability to be Changed or Repaired

easily."47
Serviceability – "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."48
Includes
Availability needs and requirements
Identification of capabilities needed to meet requirements
New and existing IT services
Ensuring that availability provision of underlying services and suppliers in support of
primary IT services is factored in
Considering all aspects of IT service delivery and support that could impact availability
(training, tools)
Excludes
Business Continuity Management or disaster recovery (Business responsibility along
with IT Service Continuity Management)
Direct handling of service failures (Incident Management)
Approval of capabilities needed to meet requirements (Portfolio Management)
Creation of capabilities needed to meet requirements (Realization category of
processes)
Managing suppliers (Supplier Management)
Activities
A731 Establish Availability Management Framework
A732 Determine Availability Requirements
A733 Formulate Availability and Recovery Design Criteria
A734 Define and Implement Availability Targets and Related Measures
A735 Monitor, Analyze and Report Availability
A736 Investigate Unavailability
A737 Produce Availability Plan
A738 Evaluate Availability Management Performance

•
•
•
•
[A7] Resilience
[A74] Capacity Management

Purpose
The purpose of Capacity Management is to match the capacity of the IT services and infrastructure
to the current and future identified needs of the business. Capacity Management focuses on the
complete spectrum from design and planning of service capacities through the operational aspects
of service capacity.
Definition of Capacity: “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.”49
Outcomes
As a result of the successful implementation of the Capacity Management process:
IT always has the capacity to meet the expected (agreed) current and future identified
needs of the business
Scalability requirements of the business are understood and accommodated
Incidents caused by lack of capacity are averted
The cost of capacity acquisition is reduced by planning and optimizing capacity usage.
Scope
The process covers a wide range: understanding service requirements, determining component
capacities, the design and deployment of capacity, and meeting expectations. It collects and
analyzes data that is relevant to application and infrastructure utilization and performance for the
purpose of determining whether there are potential problems and issues that need to be
addressed.
ITIL defines three focus areas which are addressed by Capacity Management. Each uses the
primary activities of the process decomposition in differing ways, to differing end results.
Business Capacity Management
• This focus area is responsible for ensuring that the impacts of future business
requirements for IT services upon IT resources are considered, planned, and
implemented in a timely fashion
Service Capacity Management
• This focus area is the management of the performance of the IT services used by the
customers. It is responsible for ensuring that service performance is monitored,
measured, and reported; and meets business requirements and agreements
Component Capacity Management
• This focus area is the management of the performance, utilization, and capacity of
individual technical components possessing finite resources
Includes
All aspects of the Performance Management discipline
Interfacing with Demand Management on Service Demand Forecasts
Component capacity management (both as it affects in-house service operations and
with consideration of impacts to and requirements upon service partners)
High-level service capacity monitoring

•
•
•
•
[A7] Resilience
Determining the requirements for space and other facilities that will result from
capacity proposals and plans
Excludes
Low-level system capacity monitoring (Service Execution)
Generalized human resource management (Workforce Management)
Designing and implementing the facilities needed to support capacity plans (Facilities
Management)
Activities
A741 Establish Capacity Management Framework
A742 Model and Size Capacity Requirements
A743 Monitor, Analyze and Report Capacity Usage
A744 Supervise Tuning and Capacity Delivery
A745 Produce and Maintain Capacity Plan
A746 Evaluate Capacity Management Performance
[A75] Facilities Management

Purpose
The purpose of the Facilities Management process is to create and maintain a physical
environment that houses IT resources and to optimize the capabilities and cost of that
environment.
Definition of Facilities Management: “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”.50
Outcomes
As a result of the successful implementation of the Facilities Management process:
The physical environment within which information technology resources perform supports
operational needs
Availability of IT systems is protected from physical threats (including environmental,
security, continuity)
Facility requirements are analyzed, planned for, and met in a timely and cost-effective
manner
Scope
Includes
Physical facilities planning and implementation (physical planning) – space, power,
HVAC, physical cables and connectors, physical security implementation, protection
(such as sprinklers, halon systems, badge readers, security personnel)

•
•
•
•
[A7] Resilience
Physical logistics (receipt, staging, moving)

Physical environment for all information and communications technology
– For example, participating in the design of racks and cabling
Physical access management to IT facilities
Safety
Managing incidents concerning facilities, and interfacing with Incident Management
when both IT and Facilities components are involved
Excludes
Asset Management
Business resilience and continuity (Business responsibility, in conjunction with IT
Corporate facilities (buildings, maintenance, catering, mail delivery, desks, lights)
unless associated with a secure data center (Business responsibility)
Security of corporate facilities, such as office buildings, factories (Business
responsibility)
IT security policies and practices (Security Management)
Media management (see Data Management) but would include physical
transportation and security of media
Management of suppliers (Supplier Management)
Activities
A751 Establish Facilities Management Framework
A752 Plan Facilities
A753 Manage Facility Request
A754 Operate and Maintain Facilities
A755 Evaluate Facilities Management Performance
•
•
•
•
[A7] Resilience
[A76] IT Service Continuity Management

Purpose
The purpose of the Service Continuity Management process is to ensure that agreed IT services
will support business requirements in the event of a disruption to the business, based on the
committed recovery schedule.
Definition of IT Service Continuity Management: “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.”51
Outcomes
As a result of the successful implementation of the IT Service Continuity Management process:
A set of IT Service Continuity and IT Recovery plans are created, maintained, and tested
that support the organization’s overall Business Continuity Plans
Business continuity targets can be met through the recovery of agreed IT services and
technical facilities to agreed time scales, under Change Management control
Regulatory requirements for IT service continuity are met
Business vitality and functions are maintained at agreed levels
Scope
The process fulfils its mission through risk reduction measures, controlled recovery options, and
restoration facilities.
Includes
Service capability for prioritized, critical business processes, and their attendant
support requirements. Examples include:
– IT application services
– Organizational procedures
– Consideration of facilities
– Consideration of IT Services provided by business partners
Specification of service continuity solutions
Definition of circumstances and thresholds for continuity invocation
Contributing to proactive prevention of IT disruptions (by identifying and analyzing
risks, and sharing the analysis)
Control of continuity solution invocation in the event of disruption
Testing of the continuity solution
Excludes
Normal operational fluctuations (Service Execution, Event Management)
Minor technical faults that are covered by Incident Management
Deliberate business strategy changes and long term risks such as business
diversification or restructuring (IT Strategy)

•
•
•
•
[A7] Resilience
Responsibility for identification and prioritization of critical business processes

(performed in a business impact analysis by the Business Continuity Management
process: outside the scope of this model)
Development and implementation of service continuity solutions (once agreed by
Portfolio Management, these solutions are treated as any other solution through
Realization and Transition)
Contractual arrangements with third parties (Supplier Management)
Activities
A761 Establish IT Service Continuity Management Framework
A762 Identify Business Service Continuity Requirements
A763 Create and Maintain IT Service Continuity Strategy
A764 Create and Maintain IT Service Continuity Plan
A765 Prepare IT Service Continuity Capability
A766 Execute IT Service Continuity Plan
A767 Evaluate IT Service Continuity Management Performance
•
•
•
•
[A8] Administration
[A8] Administration
Description
Purpose
The Administration process category brings together the processes that look after many of the non-
technical resources: people, finances, and contracts, among others that support IT service
delivery. It builds a sound foundation for the IT business, which other processes can deliver the IT
services for the parent business.
Rationale
The processes in this category help build and manage the necessary infrastructure for controlling
IT resources (such as hardware, software, and people). These processes are a necessary part of
any endeavor's management system and contain the fundamental management building blocks of
any organizational entity; namely, people management, financial and administrative management,
pricing and contract management, and skills management. Failure in any of these areas of
management could lead to the failure of the IT entity of the business. Without these processes,
there would be no ability to accomplish the information technology mission of the business,
regardless of the technology available.
Value
Contributes to managing the business and finances of IT with an approach and discipline
consistent with the business practices employed by the rest of the enterprise
Provides accurate and up-to-date financial information to facilitate management controls
Manages contracts and relationships with internal and external suppliers of products and
services, optimizing the value and quality of service and support
Attracts and retains a highly-skilled workforce to ensure that business needs can be met
through IT
Enables innovation through the capture and dissemination of knowledge
Processes
•
•
•
•
[A8] Administration
[A81] Financial Management

Purpose
The purpose of the Financial Management process is to ensure that financial controls and
procedures are in place to effectively predict and control IT budgets, enable business decisions,
and ensure that legal, corporate and regulatory compliance is maintained. The outputs from the
Financial Management process also enable benchmarking and business case analysis to support
organizational decision making.
Outcomes
IT financial controls are established and enforced
Operational data is transformed into financial information and management actions
Compliance is ensured with legal, industry, and corporate standards and procedures
Benchmarking and other financial comparisons are enabled
IT portfolio decisions are assisted on investment by providing detailed business cases and
by providing financial input to decision support
IT budgets are effectively predicted and controlled
Scope
IT finance is focused on budgeting, accounting and (optionally) charging for IT resources
Includes
Budgeting – capital and operational
Accounting – including accounts receivable (AR) and accounts payable (AP)
Charging
– Metering, rating and billing
Cost models and accounting systems
Resource types:
– Labor
– Products
– Services (inbound and outbound)
Decision Support
Financial analysis and reporting
Collecting financial data
Operational data collection requirements for financial purposes
Design and implementation of accounting systems
Analysis and control of the impact of chargebacks (influences on user and customer
behavior)
Paying internal and external invoices and bills
Financial management (depreciation) of assets
Excludes
Asset management (including life cycle management)
Resource usage data collection
•
•
•
•
[A8] Administration
– Systems and services (Service Execution)

– Time recording and labor claiming (any process, especially Program and Project
Management)
Service, solution, and offering pricing (Service Pricing and Contract Administration)
Contract management (Service Pricing and Contract Administration)
Excludes
Asset management (including lifecycle management)
– Systems and services
– Time recording and labor claiming
Service, solution, and offering pricing
Contract management
Procurement
Activities
A811 Establish Financial Management Framework
A812 Perform Financial Modeling
A813 Plan and Control Budgets
A814 Perform Financial Accounting
A815 Administer Charging
A816 Audit Financials
A817 Evaluate Financial Management Performance
[A82] Supplier Management

Purpose
The purpose of the Supplier Management process is to manage interactions with suppliers and
partners formally by selecting them based on their ability to meet identified requirements, and
managing performance against the agreed commitments.
Outcomes
Attitudes and behaviors are promoted that encourage mutual success
Procurement and delivery of products and services are optimized for maximum value
across supplier relationships
Obligations are met as efficiently and effectively as possible by both parties in the
relationship
Optimal value is achieved for costs in maintaining supplier relationships
Scope
Involves all aspects of managing relationships with suppliers and outsourcers and of the
procurement of assets and services. Addresses the complete supplier and procurement life cycle
from strategic considerations to tactical considerations, and to operational considerations.
•
•
•
•
[A8] Administration
Includes
Agreement on joint architecture and risk controls
Negotiation and enforcement of contracts
Supplier evaluation, selection, and relationship management
Supplier performance review, including:
– Benchmarking
– Terms and conditions conformance
Procurement (placing the order), both against established contracts and for off-the-
shelf items
Internal and external suppliers
Formalizing the operational level agreement (OLA) items, where they are to be fulfilled
by an external supplier, within an underpinning contract (UC)
Excludes
– Establishing the substance of OLA items which relate to a supplier
– OLA and UC service monitoring
Physical logistics (Facilities Management)
Product and services requirements and specifications (from Solution Design, for
example)
Activities
A821 Establish Supplier Management Framework
A822 Manage Portfolio of Suppliers
A823 Manage Supplier Contracts
A824 Manage Procurement
A825 Evaluate Supplier Performance
A826 Provide Supplier Product and Service Information
A827 Evaluate Supplier Management Performance
[A83] Service Pricing and Contract Administration

Purpose
The purpose of the Service Pricing and Contract Administration process is to establish a pricing
mechanism for the IT entity to sell its services to internal or external customers, and to administer
the contracts associated with selling those services.
Outcomes
Prices are set that reflect the charging policies of the IT organization
Pricing is aligned to achieve business objectives
Requests for pricing are satisfied in a responsive manner
Customer contracts and agreements are administered effectively and efficiently
•
•
•
•
[A8] Administration
Scope
This process applies if the decision is made to charge for IT services. It encompasses defining a
pricing method, establishing prices, managing the resulting contracts, tracking the effect of pricing
on how well the service or solution is being accepted by the customer, and examining proposals
and contract continuation.
Includes
Defining the charging pricing algorithm
Providing standard prices for IT services
Providing pricing alternatives (such as fixed, time and materials, and flexible terms
and conditions)
Monitoring impact on user and customer behavior and making appropriate
adjustments
Excludes
Metering (Service Execution, Data Management)
Billing (Financial Management)
– Initiating pricing negotiations (Service Marketing and Sales)
Activities
A831 Establish Service Pricing and Contract Administration Framework
A832 Collect Pricing Data
A833 Provide Price Alternatives
A834 Administer Customer Contract/ Agreement
A835 Monitor Pricing Effects
A836 Evaluate Service Pricing and Contract Administration Performance
[A84] Workforce Management

Purpose
The purpose of the Workforce Management process is to provide the optimal mix of staffing
(resources and skills) in order to deliver the agreed IT services at the negotiated service levels and
commitments.
Outcomes
An appropriately skilled and motivated workforce is attracted and retained
Staffing and skills meet needs of the business, including required technical and business
skills, both on a day-to-day basis and over time
Compliance with all workforce-related legal and regulatory requirements and with
corporate practices is ensured
A succession strategy for leadership and critical skills is enabled
Workforce management information is provided to support informed decision making on
sourcing strategy
•
•
•
•
[A8] Administration
Scope
Any aspect of managing the human resources available and necessary for the IT endeavor to fulfill
its obligations, including workload, skills, and personnel.
Includes
Acquiring, hiring, retaining, developing, firing, retiring
Introducing and orienting new resources to the workplace
Skills management
Workforce management, including capacity planning and forecasts
Work and job design, including roles and responsibilities
Skills development and training
Performance evaluation
Employee communications
Workforce task management
The execution of corporate human resources (HR) activities in relation to the IT
workforce
Representing human resource issues relating to the IT workforce to corporate HR
Excludes
Establishing corporate HR policies and their deployment beyond IT
Setting overall budgets for workforce
Payroll and benefits administration
HR systems (part of Portfolio Management and Solution Development and
Deployment, in support of the business' HR processes)
Managing the workforce of service providers
Setting sourcing strategy
Activities
A841 Establish Workforce Management Framework
A842 Forecast and Plan Workforce
A843 Administer Human Resources
A844 Manage Skills
A845 Evaluate Workforce Management Performance
•
•
GIM- 100• IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
[A8] Administration
[A85] Knowledge Management

Purpose
The purpose of the Knowledge Management process is to focus on capturing and exploiting the
information and knowledge needed by personnel to work effectively.
Definition of Knowledge Management: “The Process responsible for gathering, analysing, storing
and sharing knowledge and information within an Organisation. The primary purpose of
Knowledge Management is to improve Efficiency by reducing the need to rediscover
knowledge”.52
Outcomes
Organizational and individual knowledge and skills are improved
All areas of IT are assisted in providing optimized IT end-to-end business services
Technologies are leveraged for capture, location, and dissemination of knowledge and
expertise
Communities of practice are able to optimize the use of organizational knowledge
Innovation is promoted and enabled
Scope
The process emphasizes controlled but efficient access to assets across the organization,
ensuring consistency and reuse as appropriate to take advantage of best practices and enable
innovation.
Includes
Management of IT knowledge and directly related business knowledge, including:
– The full range of knowledge from technical to services
– Knowledge gained from external sources as well as from internal activities
– Interfaces to support any other IT process such as Incident Management
– Life cycle management of knowledge, from development through retirement
– Content management for knowledge data across all media and access
mechanisms in which it resides
Working with other IT processes so that the relevant knowledge in their data and
information repositories is made available and is actively managed
Linkage to business-side Knowledge Management (if a program exists)
Coordination with skills building and learning activities
Knowledge linkage with service providers and suppliers
Knowledge linkage with customers
Intellectual property management, such as patents and external publications
Excludes
Understanding and acting on the knowledge (outcome management is the
responsibility of all other IT processes)
Establishing and operating the data and information repositories associated with
individual IT processes; for example, the Configuration Management database

•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) •GIM - 101
•
•
[A8] Administration
General Knowledge Management for the business

Content management for business Web-based data (responsibility of the business,
with support from Data Management)
Activities
A851 Establish Knowledge Management Framework
A852 Create and Maintain Knowledge Plan
A853 Acquire Knowledge
A854 Evaluate and Structure Knowledge
A855 Disseminate Knowledge
A856 Monitor, Assess and Report Knowledge Status
A857 Evaluate Knowledge Management Performance
•
•
GIM- 102• IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
[A0] Manage IT
Model Introduction
which underpin their value propositions to the industry segments they serve. For others, IT
services have been major value propositions in their own right. As the reach and range of IT-based
solutions and services has extended and become, to all intents and purposes, pervasive, these
two uses of IT have converged.
PRM-IT is independent of organizational design and makes no assumptions about the chain,
network or mesh of IT business entities -– or the nature of their inter-relationships (such as
contractual, partnership, joint venture) -– by which the IT service is provided to the primary
businesses. Each of these IT business entities will need to understand both the activities they
undertake to contribute to IT service provision and (perhaps increasingly) the interfaces they have
with related parties.
Viewpoint of the Model

The focal point for all IT activities, and the executive accountable for IT value, is the CIO. In some
IT undertakings, these accountabilities are assigned to an executive body that has CIO-role
responsibilities. Accordingly, PRM-IT considers the work done within IT from the CIO or CIO-role
perspective.
It is only from this vantage point that all aspects of IT for the IT business entity within scope are
visible. Elsewhere within that IT business entity, all other viewpoints can see only a subset of the
complete picture.
There are two main perspectives from the CIO's viewpoint:
department.
• Many activities can be assigned to one or more third-parties, covering the range from
2. Representing the IT undertaking to its stakeholders and to the wider operating
environment. These interested parties provide the context in which the IT business
operates.
The context for the business of IT

IT does not operate in a vacuum; it has relationships of varying kinds with a variety of other parties.
In modeling terms, these parties are known as external agents.
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • A0 - 1
•
•
PRM-IT contains five kinds of generic external agents:
1. The Business
2. Customers
3. Users
4. Suppliers
5. External Environment
The nature of the interactions between IT and each external agent is described in detail later.
The Business
The Business is the owner of the IT undertaking. It provides the underlying funding for IT and
receives from IT a corresponding return, in the form of value against the criteria which the business
sets.
The Business provides resources to and exercises control over IT, beyond the financial aspect.
It establishes the container in which each section of the business operates: manufacturing,
distribution, IT, and others. Each such section probably has some degree of freedom to set
its own tenor (or style) of operation, but each must conform to the overall management
system and governance.
Beyond this, IT might rely wholly or partly upon other, similarly common aspects of the
business infrastructure. Key examples here include finance and accounting, and workforce
management.
The Business is the ultimate arbiter over the direction and the performance scorecard of IT.
Customers
In contrast to the broad nature of The Business, the external agent, Customers, reflects that each
IT service has an individual customer, or a collective set of them.
The role of the Customer covers aspects that specify and guide the makeup of the services, such
as:
Providing requirements that can eventually be satisfied by an IT service.
Commissioning development of new or updated solutions. The agreement for this, and for
the levels of service using the solution, can be formally or informally contracted, depending
on the customer-provider relationship.
Interactions relating to satisfaction (or otherwise) with delivered IT services.
The model does not differentiate between internal and external customers. The interactions
depicted in the model cover both cases. In particular, the Customer can themselves be another IT
service provider, perhaps in the role of a prime contractor to the ultimate customers or of a service
integrator in a multi-sourcing arrangement.
Users
This external agent is involved in the interactions with each of the services provided by IT.
Primarily, the interactions are related to receiving service through initiating and providing
data to individual transactions, and generalized services (such as e-mail and Internet
access).
Additionally, users will interact with support services (manually or electronically) for:
• Requests for advice and guidance
• Interruption to service (PC hardware failure, for example)
User interactions occur only within the specifications of agreed services. The Customer role is
needed to commission and confirm new or extended services.
•
•
A0 - 2 • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
Suppliers
No IT function can provide 100 percent of the value delivered in their portfolio of IT services. At
some point in each value chain, there will be dependencies on one or more Suppliers. Suppliers,
in this context, are organizations outside the control of the CIO and with whom the primary linkage
is in the form of a supply agreement, formally or informally. The supply agreement can be for
products, services, or both. In return for this supply, there will need to be a corresponding payment,
which is usually of a monetary kind.
PRM-IT does not indicate the points when the value chain will invoke a supply agreement, it does
acknowledge that an agreement will be required. Similarly, while it is likely that most agreements
will be with suppliers external to the business, it is possible that some suppliers might be sister
organizations in the wider business.
External Environment
The policies, practices, methods and techniques the IT undertaking uses are subject to many other
influences and constraints beyond the external agents thus far mentioned. Collectively, the term
External Environment is used to convey these influences and constraints.
Examples of agents of this type are:
Governments
Regulatory agencies
Industry trends
• The industry segments of the business
• The IT industry in general
IT management frameworks and techniques, such as published best practice and bodies of
knowledge
In general, the External Environment has a strong influence over an individual IT undertaking. In
contrast, it is relatively unlikely, though possible, for the reverse to be true.
•
•
•
•
Context and Interfaces

PROJECT: PRM-IT V3 MODEL COMMENTS: VERSION: 3.0 PAGE COMMENTS: MODELLER: CFB/JRM CONTEXT:
SECURITY: IBM Intellectual Property IBM Process Reference Model for IT
Top
FILENAME: PRMITV30.IDD
MODIFY DATE: 14/01/08 07:45 PM C Copyright IBM Corporation, 2008, All Rights Reserved
IT Function
Information
and Interests The
Business
External
Environment
Business
Input
Business Funding
Business
Environment Governance
Information
IT Governance
and Management
System Results IT Strategy
Manage IT
Business Output
Supplier Input
A0
Customer Output
Supplier
Output Customers
Suppliers
Customer Input
User Output
User
Input
Users
NODE: A-0 TITLE:

Manage IT - Context CURRENT PAGE:
Figure 1. PRM-IT A-0 (Context) Diagram
Process Details
Controls
Environment Information (From: outside the model)
General knowledge that exists relative to the business' primary overall industry
segments and the IT industry, such as:
– Business information
– Technical information
– Government information
Business Governance (From: outside the model)
– Includes business drivers
Inputs
Business Funding (From: outside the model)
Defines the overall planned budget effort (people, money) for all planned services and
activities in IT.
Business Input (From: outside the model)

•
•
•
•
The various input items from the business to the IT provider that shape or direct the IT
service. Examples of such inputs include:
– Guidance
– Instructions
– General commentary and information about business operating conditions
Supplier Input (From: outside the model)
The complete set of items from suppliers to the IT undertaking. The set includes:
– Bids
– Procured items (assets, consumables, services)
– Invoices
– Product and support information
User Input (From: outside the model)
The collection of all information and items a user generates and sends to the IT
undertaking in furtherance of their need to receive the committed service. Examples
include:
– Sequences that invoke transactions or other kinds of services (typically from an
application). They might be accompanied by user data.
– Contact, through human or electronic channels, which represent:
Requests for information
Expressions of any apparent fault (which might become an incident)
Service requests
Customer Input (From: outside the model)
Interactions from any customer of IT to any IT process related to any aspect of the life
cycle related to the establishment and performance of the IT product; that is, the
services and solutions. The interactions include:
– Needs and requirements
– Contracting for IT services
– Establishing service level targets, and reviewing achievement against those targets
– Participation in testing and other acceptance activities
– Payments
– Satisfaction input
Outputs
IT Function Information and Interests (To: outside the model)
Any information about the workings such as current capabilities and future directions,
which the IT undertaking makes available to the industry at large.
IT Governance and Management System Results (To: outside the model)

A stakeholder report of the IT Management System's outcomes, effectiveness and
efficiency, and other key performance indicators, such as the quality results.
IT Strategy (To: outside the model A1 A2 A4 A5 A7 A8)

A consolidated statement of IT initiatives. Includes a summary of changes to IT
capabilities and a summary of each strategic IT initiative. Also includes a statement of
planned and required changes to the IT Portfolio and IT Plan. The IT Sourcing
Strategy would be included.
•
•
•
•
Business Output (To: outside the model)

The interactions from the collective IT endeavor to the businesses which relate to the
any aspect of the life cycle related to the establishment and performance of the IT
product; that is, the services and solutions. The interactions include:
– Assessment of actual and potential value from IT
– Business demand classifications, forecast consolidations and proposed demand
interventions
– Compliance certifications
Customer Output (To: outside the model)
The interactions from the collective IT undertaking to any IT customer, in connection
with any aspect of the life cycle related to the establishment and performance of the IT
product; that is, the services and solutions. The interactions include:
– Validation of requirements
– Marketing and sales materials, such as proposals
– Service level agreement life cycle
– Invoices for services rendered
– Any aspect of customer satisfaction
User Output (To: outside the model)
The collection of all service deliverables which the IT undertaking generates and
delivers to the user to meet the committed service. Examples include:
Processing of business transactions (in whole or in part) through IT system-
provided means.
The delivery of relevant outputs, such as:
– Transaction completion status
– Data resulting (for example, delivery of an e-mail message)
Contact through human or electronic channels, which satisfy or resolve:
– Requests for information
– Expressions of any apparent fault (which might become an incident)
– Service requests
Supplier Output (To: outside the model)
Represents all interactions from the IT undertaking to any supplier. Constituents
include:
– Bid requests
– Purchase orders
– Payments
– Other communications
•
•
•
•
Model Composition
This model is composed of these process categories:
A3 Direction
A4 Realization
A5 Transition
A6 Operations
A7 Resilience
A8 Administration
Business Environment
Business Governance Information
Management C2 C1
System Business
Strategy
SLAs OLAs UCs

Governance Service
Catalog
and O2
Management IT Governance
System and Management
IT Management IT Research System Results
A1 Ecosystem Guidance
Service Level Package IT Business
Market Analysis IT Portfolio Contribution and
Capabilities
I5 Customer
Customer Input
Relationships
IT Plan
A2
Project Charter
Stakeholder O4
Requirements Direction Business Output
Business and
Project Proposal IT Models
A3
Project Plan O3
Solution Design IT Strategy

Product Package Architecture Baselines
and Roadmaps Solution_
Realization Accepted
I2
Business CI Requisition
Input
A4
Change Schedule O5
Solution Realization Solution Solution_ Customer Output
Results and Issues Plans and Change
Deployed Information
Commitments
Transition
CIs Configuration
Information
Operational
A5 Monitoring Data
Asset Deployment CI Data O6
Items and Data Update Package Identity and User Output
Access Rights
Register
Change Operations
Incident
Request
Compliance Plans
Service Metric Data
and Controls
I4 Incident and Reports
User A6 Information Security Policy
Input Service Request_ Asset Information
Authorized
O7
Supplier
Resilience Output
Problem
Information
Service Resilience
Plans
IT Budget
A7
Administration
I3 A8
Supplier Input Underpinning
Contracts
IT Financial
Reports
I1
Business Funding
NODE: A0 TITLE:
Manage IT CURRENT PAGE:
Figure 2. PRM-IT A0 Diagram
•
•
•
•
Description
Purpose
capability to achieve the IT undertaking's goals. The governance and management system must
add value by balancing risk versus return across IT and all processes.
conducting IT activities. The management framework will outline, as an example, the management
executed to enable better decision making by executives as to whether the business model is
succeeding or should be modified to achieve the objectives better.
Governance is a decision rights and accountability framework for directing, controlling and
Governance involves defining the management model and creating governing or guiding
Who makes directing, controlling, and executing decisions, including defining the ultimate
How the decisions will be made, including escalation and arbitration procedures
What information is required to make the decisions
With what frequency decisions must be made or revisited
What decision making mechanisms should be required
How decisions are communicated to concerned parties
How the governance results should be reviewed and improved
Rationale
to integrate processes, technologies, people, and data in a manner that is consistent with IT goals.
The category also monitors the framework against the broader enterprise goals and quality
metrics. When specific goals and quality metrics are consistently unmet, decisions will be made as
to whether the overall framework will be modified or restructured to ensure future success.
Value
•
•
•
•
Controls
Business Management System
The management system in place to govern the workings of the overall business.
Business Strategy
The business strategy stated in terms of strategic intent, roadmap, drivers, objectives and
policies.
General knowledge that exists relative to the business' primary overall industry segments
and the IT industry, such as:
• Business information
• Technical information
• Government information
IT Budget (From: A8)
The planned IT funding broken down in relevant ways, such as activities and milestones
per period, to reflect the contents of the IT plan.
IT Strategy (From: A3)
A consolidated statement of IT initiatives. Includes a summary of changes to IT capabilities
and a summary of each strategic IT initiative. Also includes a statement of planned and
required changes to the IT Portfolio and IT Plan. The IT Sourcing Strategy would be
included.
Inputs
• Guidance
• Instructions
• General commentary and information about business operating conditions
Underpinning Contracts (From: A8)
Content of contracts with suppliers, including terms and conditions, service level
agreements (SLAs), among others. Covers both the actual contract itself, and information
about it that is available as input for supplier evaluation and to other internal processes,
such as financial management.
Information Technology Infrastructure Library (ITIL) defines underpinning contract as “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.”1
IT Financial Reports (From: A8)
All reports on financial data of IT for different stakeholders. Covers a wide range of reports
from outlining projected costs through after-the-fact financial analyses.
Compliance Plans and Controls (From: A7)
The authoritative and comprehensive statement of:
The items for which compliance is required
1. ITIL V3 Glossary
•
•
•
•
The means (policies, data specifications, procedures, techniques, tools) to achieve

compliance
The definition of required compliance metrics and reports by which conformance will
be able to be demonstrated for required scrutiny
It will be the major vehicle for communications and guidance on compliance efforts.
IT Research Guidance (From: A3)
Guidance and recommendations about which trends and innovations should or should not
be adopted. In other words, a summary of overall research results.
IT Portfolio (From: A3)
A central repository containing all the IT resources and assets, projects, and services
controlled and managed by the IT organization, departments, and functions.
Architecture Baselines and Roadmaps (From: A3)
Provides an agreed, published statement of the required architecture at a moment in time.
Includes statements to assist in selection and evaluation of appropriate implementations of
specified architecture building blocks.
Market Analysis (From: A2)
A document that evaluates the current service requirements, market segmentation, current
customer profiles, and the current typical IT service provider scope to discern general
trends and directions in the current IT service marketplace.
Outputs
A stakeholder report of the IT Management System's outcomes, effectiveness and
efficiency, and other key performance indicators, such as the quality results.
IT Management Ecosystem (To: A2 A3 A4 A5 A6 A7 A8)
To paraphrase a dictionary definition: the complex of management system elements, their
physical implementation, and all their interrelationships in the unit of space that is the
domain of the IT function. Its fundamental purpose is to provide an environment that is
supportive of the carrying out of all of the IT activities defined elsewhere in this model.
Processes
•
•
•
•

Description
Purpose
the marketplace.
each process depending of the market complexity.
Rationale
Value
2. ITIL V3 Glossary
•
•
•
•

requirements
business
Controls
IT Management Ecosystem (From: A1)
Business Strategy
policies.
included.
Security Policy (From: A7)
The statement of the types and levels of security over information technology resources
and capabilities that must be established and operated in order for those items to be
considered secure. It provides management direction into the allowable behaviors of the
actors working with the resources and exercising the capabilities. It defines the scope of
management and specifies the requirements for the security controls.
Business and IT Models (From: A3)
Representations of relevant aspects of the business' activities, in model formats, and with
or without the inclusion of related IT factors.
IT Plan (From: A3)
The set of approved projects and associated schedule, operating plan, service level
management commitments, and resource allocation commitments and adjustments for a
defined fiscal or planning cycle.
Inputs
•
•
•
•
Interactions from any customer of IT to any IT process related to any aspect of the life cycle
related to the establishment and performance of the IT product; that is, the services and
solutions. The interactions include:
• Needs and requirements
• Contracting for IT services
• Establishing service level targets, and reviewing achievement against those targets
• Participation in testing and other acceptance activities
• Payments
• Satisfaction input
• Guidance
• Instructions
an SLA.”3
Service Metric Data and Reports (From: A6)
Significant service delivery event logs, volume and other measurement data relating to how
effectively and efficiently services are provided by IT. This data, which is available as
requested both in raw format and as structured reports, is a component of all operations
information and is the basis for service level reporting.
Incident Information (From: A6)
Information about one or more incidents. Can range from full details of an individual
incident through collated and summarized information about sets of incidents.
Problem Information (From: A6)
Information about one or more problems. Can range from full details of an individual
problem through to collated and summarized information about sets of problems. Can be
provided both as formal reports (such as documents to customers describing root cause,
contributing factors and corrective actions) and informally as structured data for other
processes to analyze for their own purposes.
3. ITIL V3 Glossary
•
•
•
•
Service Resilience Plans (From: A7)

The collection of plans produced by the individual processes involved in ensuring the
resilience within service management. Processes contributing are:
• Compliance Management
• Security Management
• Availability Management
• Capacity Management
• Facilities Management
• IT Service Continuity Management (See the definition of the plan output from each
individual process for more details.)
Change Information (From: A5)
The full scope of information is covered. This could be about an individual detail within a
particular change through ad hoc or pre-determined reporting on a set of changes.
Solution Plans and Commitments (From: A4)
The collective overall information on both the development plan for the solution and the
content of the solution as it progresses from concept to reality.
• Plans: Sets of committed solution phases, activities, tasks and milestones together with
time frame.
• Commitments: Sets of requirements, designs and other deliverables, such as test cases.
Product Package (From: A3)
A description of the product that details how it is to be iteratively assembled, integrated and
deployed, as well as the status of the product itself as it migrates through the various
stages of realization, deployment and operation.
Outputs
The interactions from the collective IT undertaking to any IT customer, in connection with
any aspect of the life cycle related to the establishment and performance of the IT product;
that is, the services and solutions. The interactions include:
• Validation of requirements
• Marketing and sales materials, such as proposals
• Service level agreement life cycle
• Invoices for services rendered
• Any aspect of customer satisfaction
The interactions from the collective IT endeavor to the businesses which relate to the any
aspect of the life cycle related to the establishment and performance of the IT product; that
is, the services and solutions. The interactions include:
• Assessment of actual and potential value from IT
• Business demand classifications, forecast consolidations and proposed demand
interventions
• Compliance certifications
SLAs, OLAs, UCs (To: A3 A4 A5 A6 A7 A8)
The agreements that represent the interlinked set of commitments for the service utility and
warranty that is to be provided to one or more customers. The agreement between the
customer and the organizational unit that directly provides the service is known as a
service level agreement (SLA) and is visible to the customer. The agreements that
represent the commitments of the collective set of internal organizational units and external
•
•
•
•
entities to provide identified sub-components of the overall service are known as

operational level agreements (OLAs). OLAs are not usually visible to the customer.
Contractual statements of the commitments by external entities are known as underpinning
contracts (UCs).
ITIL definition of these terms:
• SLA: “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.”4
• OLA: “An Agreement between an IT Service Provider and another part of the same
Organisation. 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.”5
• UC: “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.”6
These agreements can be in a draft or finalized status.
Service Catalog (To: A3 A5 A6 A7 A8)
Catalog of all services offered for delivery by the IT service provider. Portions of it can be
used as a means of communication to the customers, but there are also sections that
describe details (usually not published outside the delivery organization) of how each
service is provided.
ITIL defines Service Catalog as: “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.”7
Change Request (To: A5)
Change requests (also known as RFCs) are the means for submitting proposed change
and actual change activity in the environment. Change requests can be triggered for a wide
variety of reasons, from a broad spectrum of sources. They can be concerned with any part
of the environment or with any service or activity.
Stakeholder Requirements (To: A3 A4 A7)
The qualified needs for IT services that are to be progressed through the Portfolio process
for decision making.
These needs might be in a form suitable for direct translation into solution requirements
and should include stakeholders' acceptance criteria.
Service Level Package (To: A3 A4 A7 A8)
Details of the expected implications to the service utility and warranty which will result from
agreement with the relevant business units on the demand management approaches under
which the service will be provided. ITIL definition: “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.”8
4. ITIL V3 Glossary
5. ITIL V3 Glossary
6. ITIL V3 Glossary
7. ITIL V3 Glossary
8. ITIL V3 Glossary
•
•
•
•
Project Proposal (To: A3)

A formal statement of an idea being put forward for consideration that includes the
business case for the proposed IT investment.
Market Analysis (To: A1 A3)
Incident (To: A6)
A fault in IT service and infrastructure that has been reported, or an event that could cause
an interruption to one or more services. Incidents can be created using either manual or
automated mechanisms. An incident reported by a user begins as a service request and
becomes an incident once it is determined that a fault is being reported.
Processes
•
•
•
•
[A3] Direction
[A3] Direction
Description
Purpose
architecture and IT portfolio. Using the business strategy, related business requirements, and
the IT portfolio and IT architecture are planned, created, implemented, monitored, and
portfolio are managed throughout their life cycle using product management approaches well
The IT portfolio includes all items managed to deliver the IT strategy, including, but not limited to,
the services published to clients through the service catalog, internal services executed within the
the IT strategy, such as development projects. Finally, risks to the IT organization, such as those
Rationale
Through a business aligned IT strategy, IT architecture and IT portfolio, the process category
Value
enhance consistency, reuse and overall value across the range of capabilities, balancing
Optimizes the allocation of IT resources through portfolio management
predictability
•
•
•
•
[A3] Direction
Controls
Market Analysis (From: A2)
SLAs, OLAs, UCs (From: A2)
contracts (UCs).
9. ITIL V3 Glossary
•
•
•
•
[A3] Direction

an SLA.”12
• The items for which compliance is required
• The means (policies, data specifications, procedures, techniques, tools) to achieve
compliance
• The definition of required compliance metrics and reports by which conformance will be
able to be demonstrated for required scrutiny
Inputs
Service Catalog (From: A2)
Business Strategy
policies.
Stakeholder Requirements (From: A2)
Service Level Package (From: A2)

•
•
•
•
[A3] Direction
Pattern of Business Activity.” 14
• Guidance
• Instructions
Solution_ Deployed (From: A5)
The new or adjusted solution in live status, ready for useful work within its target
environment, and reflecting the outcome of the deployment activities.
The deployed solution includes documentation, procedures, training materials, support
guidance as well as the primary solution contents.
Configuration Information (From: A5)
The information on any individual configuration item (CI) or collection of CIs, which is made
available using standard reports or to meet individual requests.
Project Proposal (From: A2 A5)
Solution Design (From: A4)
Solution design, including conceptual, macro, and micro designs, together with identified
issues and risks, and formally validated and approved (signed off) by the key stakeholders.
It not only covers all the functional and non-functional requirements of the solution, but also
the design for meeting the compliance reporting requirements applicable to the solution.

•
•
•
•
[A3] Direction
time frame.
Outputs
IT Business Contribution and Capabilities
Information to the business on the products of IT (the services and solutions), on the status
of the IT assets and infrastructure employed in the delivery of the IT products, and on the
contribution (value) to the business which the IT product makes.
IT Strategy (To: outside the model A1 A2 A4 A5 A7 A8)
included.
IT Portfolio (To: A1 A2 A4 A8)
IT Plan (To: A2 A4 A5 A6 A7 A8)
Project Charter (To: A4)
A document issued by or created on behalf of the sponsor to describe the project’s
objectives. It provides the project manager with the authority to apply organizational
resources to project activities.
Business and IT Models (To: A2 A4 A7 A8)
IT Research Guidance (To: A1 A2 A8)
Project Plan (To: A4 A5)
The set of the work plans, plus other plans including management plan, human resource
plan, technical environment, project quality, communications management, and others.
Architecture Baselines and Roadmaps (To: A1 A2 A4 A5 A6 A7 A8)
Product Package (To: A2 A5)
•
•
•
•
[A3] Direction
Processes
A31 IT Strategy
A34 Risk Management
•
•
•
•
[A4] Realization
[A4] Realization
Description
Purpose
extensions to existing solutions. Maintenance and end of life shutdown activities (requiring solution
adjustment) are also addressed in this category.
iteratively and in parallel, in a project driven context to create information technology solutions for
Test engineering
Rationale
Value
Controls
•
•
•
•
[A4] Realization
IT Plan (From: A3)

included.
contracts (UCs).
Business Strategy
policies.

•
•
•
•
[A4] Realization

Inputs
Project Charter (From: A3)
A document issued by or created on behalf of the sponsor to describe the project’s
Project Plan (From: A3)
compliance

•
•
•
•
[A4] Realization
Asset Deployment Items and Data (From: A5)

Information about specific asset availability and requisition status, and also the actual asset
items being offered up for deployment.
CIs (From: A5)
CIs are the technical (in its broadest sense) components, including assemblies of more
granular components, upon which IT service is based. The relevant extract from the ITIL
definition of Configuration Item is: “Any Component that needs to be managed in order to
deliver an IT Service.... CIs typically include IT Services, hardware, software, buildings,
people, and formal documentation such as Process documentation and SLAs.” 19
Solution Realization Results and Issues (From: A4)
The collection of summary level history and status of Solution Realization activities and
work products throughout their life cycle. Typically used to establish and update
organizational performance benchmarks (estimates versus actual), transmit quality
information, and other heuristics related to Solution Realization processes.
Outputs
Solution_ Accepted (To: A5)
The Solution which has been approved by the stakeholder community, and is now ready to
be deployed.
CI Requisition (To: A5)
A request for one or more CIs to be made available so that they can be worked upon. In a
development environment, this might be a request to check-out solution components from
a version-controlled configuration library.
CI Data Update Package (To: A5)
The details of modifications to any existing CIs that must be validated and captured in the
CI master data. The modifications can include:
• Attributes
• Relationships
Solution Design (To: A3 A5 A6 A7 A8)
Solution Plans and Commitments (To: A2 A3 A5 A6 A7)
time frame.
Solution Realization Results and Issues (To: A4)

•
•
•
•
[A4] Realization

Processes
A44 Solution Test
•
•
•
•
[A5] Transition
[A5] Transition
Description
Purpose
change in Solutions and Services. The processes provide defined and repeatable approaches to
planning, effecting and recording these transitions, and can be applied to all stages of the life cycle.
They also serve to maintain control over the Information Technology resources, which are subject
to other process areas related to the management of IT. Through these processes, developments
in IT capabilities supporting the stakeholding businesses and customers achieve their desired
Rationale
Value
infrastructure
services
Implements solutions that provide new functionality, eliminates the root causes of defects,
information on managed elements (CIs, managed objects, and others)
Controls
IT Plan (From: A3)
•
•
•
•
[A5] Transition
included.
contracts (UCs).

•
•
•
•
[A5] Transition
compliance
Inputs
Solution_ Accepted (From: A4)
be deployed.
CI Requisition (From: A4)
time frame.
Project Plan (From: A3)
Product Package (From: A3)
CI Data Update Package (From: A4 A6 A7)
• Attributes
• Relationships
•
•
•
•
[A5] Transition

an SLA.”24
Service Request_ Authorized (From: A6)
The communication of a service request which has completed screening and is being
passed to one or more other processes for actual fulfillment. It includes control information
from the screening (assessment) such as priority assigned and committed completion
target.
Change Request (From: A2 A3 A4 A6 A7)
Outputs
Change Schedule (To: A6 A7)
As defined in ITIL: “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.” 25
Solution_ Deployed (To: A3 A4 A6 A7)

•
•
•
•
[A5] Transition
Change Information (To: A2 A3 A6 A7)

Configuration Information (To: A3 A4 A6 A7)
Incident (To: A6)
Asset Information (To: A7 A8)
Could be reports, covering multiple asset items, or just the specific information on an
individual asset.
Project Proposal (To: A3)
Asset Deployment Items and Data (To: A4)
CIs (To: A4)
deliver an IT Service.... CIs typically include IT Services, hardware, software, buildings,
Processes

•
•
•
•
[A6] Operations
[A6] Operations
Description
Purpose
communications with users (service requests) is an important function as these processes sense
and respond to day-to-day aspects of operations and events, quickly and correctly to address any
incidents and problems that might arise.
Rationale
The Operations category comprises the activities and measures necessary to enable and maintain
the intended and committed use of the infrastructure, applications, and services. The processes in
this category require close integration to function effectively. Operational plans and workload
balancing are augmented by constant operational monitoring throughout service delivery. This
operational data is used by many processes to identify, analyze, and quickly resolve any
anomalies. The Operations category is also the focal point for receiving and responding to a wide
variety of user service requests. This process category is vital to operating organizational
constructs such as a service desk, an operations bridge, or operations center. Problem
information.
Value
processes
Controls
Change Schedule (From: A5)
implemented.” 27
•
•
•
•
[A6] Operations

IT Plan (From: A3)
contracts (UCs).

•
•
•
•
[A6] Operations

compliance
Inputs
time frame.
Incident (From: A2 A5 A7)
User Input (From: outside the model)
The collection of all information and items a user generates and sends to the IT
undertaking in furtherance of their need to receive the committed service. Examples
include:
•
•
•
•
[A6] Operations
• Sequences that invoke transactions or other kinds of services (typically from an

application). They might be accompanied by user data.
• Contact, through human or electronic channels, which represent:
Service requests
Outputs
User Output (To: outside the model)
The collection of all service deliverables which the IT undertaking generates and delivers to
the user to meet the committed service. Examples include:
• Processing of business transactions (in whole or in part) through IT system-provided
means.
• The delivery of relevant outputs, such as:
Transaction completion status
Data resulting (for example, delivery of an e-mail message)
• Contact through human or electronic channels, which satisfy or resolve:
Service requests
Identity and Access Rights Register (To: A7)
The records that provide the current (and perhaps historical) values for identities and for
access rights. This collective register is generated by actions related to identity life cycle
management (enrollment, provisioning and user self-care), identity controls (access and
privacy controls, single sign-on), identity federation (sharing user authentication and
attribute information between trusted Web services applications), and identity foundation
services (directory and workflow).
Service Metric Data and Reports (To: A2 A7 A8)
Operational Monitoring Data (To: A7)
Information relating to the overall item-by-item outcomes and status of the IT operational
service. This can include measurements of resource utilization, transaction volumes,
processing status, and others.
•
•
•
•
[A6] Operations
Incident Information (To: A2 A7)

Problem Information (To: A2 A7)
Service Request_ Authorized (To: A5 A7)
target.
• Attributes
• Relationships
Processes
A63 Data Management
•
•
•
•
[A7] Resilience
[A7] Resilience
Description
Purpose
domain.
Rationale
and IT services.
Value
business processes
Controls
Identity and Access Rights Register (From: A6)
•
•
•
•
[A7] Resilience
IT Plan (From: A3)

included.
contracts (UCs).

•
•
•
•
[A7] Resilience

Business Strategy
policies.
Inputs
Change Schedule (From: A5)
implemented.” 36
Operational Monitoring Data (From: A6)
processing status, and others.
Incident Information (From: A6)
Problem Information (From: A6)

•
•
•
•
[A7] Resilience

Asset Information (From: A5)
individual asset.
time frame.
Service Request_ Authorized (From: A6)
target.

•
•
•
•
[A7] Resilience
• Guidance
• Instructions
Outputs
The interactions from the collective IT endeavor to the businesses which relate to the any
aspect of the life cycle related to the establishment and performance of the IT product; that
• Assessment of actual and potential value from IT
• Business demand classifications, forecast consolidations and proposed demand
interventions
• Compliance certifications
Compliance Plans and Controls (To: A1 A3 A4 A5 A6 A8)
compliance
Security Policy (To: A2 A3 A4 A6 A8)
Service Resilience Plans (To: A2 A3 A5 A6)
• Attributes
• Relationships
•
•
•
•
[A7] Resilience
Incident (To: A6)

Processes
•
•
•
•
[A8] Administration
[A8] Administration
Description
Purpose
The Administration process category brings together the processes that look after many of
the non-technical resources, such as people, finances, contracts, and others that support
IT service delivery. It which builds a sound foundation for the IT business upon which other
processes can deliver the IT services that the parent business needs.
Rationale
The processes in this category help build and manage the necessary infrastructure for
controlling IT resources (such as hardware, software, and people). These processes are a
necessary part of any endeavor's management system and contain the fundamental
management building blocks of any organizational entity; namely, people management,
financial and administrative management, pricing and contract management, and skills
management. Failure in any of these areas of management could lead to the failure of the
IT entity of the business. Without these processes, there would be no ability to accomplish
the information technology mission of the business, regardless of the technology available.
Value
through IT
Controls
included.
•
•
•
•
[A8] Administration

contracts (UCs).

•
•
•
•
[A8] Administration
Business Strategy
policies.
Inputs
IT Plan (From: A3)
compliance
Asset Information (From: A5)
individual asset.
• Guidance
• Instructions
•
•
•
•
[A8] Administration

Interactions from any customer of IT to any IT process related to any aspect of the life cycle
related to the establishment and performance of the IT product; that is, the services and
solutions. The interactions include:
• Needs and requirements
• Contracting for IT services
• Establishing service level targets, and reviewing achievement against those targets
• Participation in testing and other acceptance activities
• Payments
• Satisfaction input
Supplier Input (From: outside the model)
The complete set of items from suppliers to the IT undertaking. The set includes:
• Bids
• Procured items (assets, consumables, services)
• Invoices
• Product and support information.
Business Funding (From: outside the model)
activities in IT.
Outputs
The interactions from the collective IT undertaking to any IT customer, in connection with
any aspect of the life cycle related to the establishment and performance of the IT product;
that is, the services and solutions. The interactions include:
IT Budget (To: A1 A2 A3 A5 A7)
Supplier Output (To: outside the model)
Represents all interactions from the IT undertaking to any supplier. Constituents include:
• Bid requests
• Purchase orders
• Payments
• Other communications
Underpinning Contracts (To: A1 A2 A3 A5)

•
•
•
•
[A8] Administration
an SLA.”43
IT Financial Reports (To: A1 A3 A5 A6)
Processes

•
•
•
•
[A8] Administration
PRM-IT High Level Node Tree

A0 – MANAGEMENT OF THE BUSINESS OF IT
A1 IT Governance and Management System
A13 IT Governance and Management System Operations
A3 Direction
A31 IT Strategy
A34 Risk Management
A36 IT Portfolio Management
A4 Realization
A44 Solution Test
A5 Transition
A6 Operations
A61 Request Filfillment
A63 Data Management
•
•
•
•
[A8] Administration
A0 – MANAGEMENT OF THE BUSINESS OF IT

A7 Resilience
A75 Facility Management
A8 Administration
Figure 3. Model Node Tree, with Categories and Processes
•
•
•
•
[A1] Governance and Management
System
Description
Purpose
capability to achieve the information technology (IT) goals. The governance and management
system must add value by balancing risk versus return across IT and all processes.
conducting IT activities. The management framework outlines, as an example, the management
executed to make possible better decision making by executives on whether the business model
is succeeding or should be modified to achieve the objectives better.
Governance is a decision rights and accountability framework for directing, controlling, and
Governance involves defining the management model and creating the governing or guiding
Who makes directing, controlling, and executing decisions, and defines the ultimate
How the decisions will be made, and the procedures for escalation and arbitration
What information will be required to make the decisions
The frequency of decision making must be executed or revisited
The required decision making mechanisms
How decisions will be communicated to the concerned parties
How the results of the implemented governance should be reviewed and improved
Rationale
to integrate processes, technologies, people, and data in a manner consistent with the IT goals.
This category also monitors the framework against the broader enterprise goals and quality
metrics. When specific goals and quality metrics are consistently unmet, decisions will be made
regarding the overall framework and whether it will be modified or restructured to ensure future
success.
•
•
•
•
Value
Controls
Business Strategy
IT Budget (From: A8 A81 A813)
IT Strategy (From: A3 A31 A315)
Inputs
Underpinning Contracts (From: A8 A82 A823)
IT Financial Reports (From: A8 A81 A813 A814 A815)
Compliance Plans and Controls (From: A7 A71 A714)
IT Research Guidance (From: A3 A32 A325)
IT Portfolio (From: A3 A36 A365)
Architecture Baselines and Roadmaps (From: A3 A33 A334)
Market Analysis (From: A2 A22 A222)
Outputs
IT Management Ecosystem (To: A2 A21 A211 A22 A221 A23 A231 A24 A241 A25 A251
A26 A261 A27 A271 A3 A31 A311 A32 A321 A33 A331 A34 A341 A342 A343 A35 A351
A36 A361 A37 A371 A4 A41 A411 A42 A421 A43 A431 A44 A441 A45 A451 A5 A51 A511
A75 A751 A76 A761 A8 A81 A811 A82 A821 A83 A831 A84 A841 A85 A851)
•
•
•
•
Processes
Environment Business Business IT Strategy IT Budget

Regulations and Information Management Strategy C4
Standards C5
C3 System C2
External Models C1 External Benchmarks
and Practices O2
IT Management
I8 Ecosystem
Market Analysis
I2
Underpinning IT Governance
Contracts Framework
I4 IT Management
Compliance Plans System Framework
and Controls
IT Governance
IT Service Provider
and
Value Profile/D1 Management
System
FrameworkA11
IT Quality Management IT Governance

Framework Capabilities
IT Management
IT Governance System Capabilities
I7
and
Architecture Baselines
and Roadmaps
Management
System
I5
IT Research
Capabilities
A12 IT Quality System
Guidance Capabilities
I6
IT Portfolio IT Measurements
Operational
Measures and Results
Individual Process
Results and Reports
IT Governance
and IT Management
Management Action Items
Program and System
Project Reports/D2
Service Achievement Operation A13
Reports/D4
IT Management System IT Quality System
I3 Reports Reports
IT Financial
Reports
IT Governance
Business Evaluation IT Control Results
and
Feedback
Management
I1 System
Business Evaluation A14
Input
Individual
Process
Evaluations O1
IT Governance IT Governance
IT Governance
Customer Satisfaction and Management and Management
System Evaluation and Management
Results and Trends/D1 Audit Results
System Results
NODE: A1 TITLE:
Governance and Management System CURRENT PAGE:
Figure 1. Governance and Management System Diagram
•
•
•
•

Purpose
The purpose of the IT Governance and Management System Framework process is to lay the
foundation for building the governance and management of an IT organization or undertaking,
taking into account such factors as vision, values, goals, and overall business objectives. Further,
it establishes guiding principles (or a management philosophy) based on those factors.
This framework plays a key role in aligning the IT entity with the overall approach of the business.
To be effective, the IT management system must focus on cultural as well as business aspects.
This process does not identify the priorities of the business, but rather the approach to operating
the various IT projects and processes in a coordinated fashion, that will manage their progress and
health.
Outcomes
Clear, unambiguous objectives and roadmaps for the overall IT Governance and
Management System are set
Overall IT governance meets the objectives provided by the owning business
The IT management system aligns with the overall business management system
Management system directions are transformed into a functional, workable, and
implementable management system
Scope
Includes
Specifying:
– Management models
– Guiding principles
– Policies and standards
– Measurement and control approaches, such as CIO dashboard, balanced
scorecard
– Quality management approaches
Defining critical success factors
Generating a list of decision areas and issues, and selecting decision options based
on guiding principles, values, and assumptions
Responding to any identified gaps between the current baseline and the desired
framework
Communicating direction
Excludes
Identifying gaps between the current governance and management baseline and the
desired framework (IT Governance and Management System Evaluation)
•
•
•
•
Priorities and decisions on the business results of IT (Portfolio Management)

IT strategy for the business (IT Strategy)
Controls
Regulations and Standards
External official rules (typically driven by government) that call for business compliance, as
well as established good practice standards from formal and informal bodies. Includes:
• Generally accepted accounting principles
• Legal requirements, such as Sarbanes-Oxley and its COSO (Framework for Financial
Management)
Business Strategy
policies.
included.
Inputs
External Models and Practices
External information from the industry (from individual enterprises, from academia, and
from industry watchers) describing models, practices, and trends in IT management
system topics.
an SLA.”1
compliance
1. ITIL V3 Glossary
•
•
•
•
IT Service Provider Value Profile (From: A31 A313)
A model of the offerings and services desired by the business, incorporating value provided
by the IT Business. Expresses in a form that profiles the IT Business as an IT Service
Provider in the style (and with the required attributes) desired by the business. An example
of suitable styles is provided by the Commodity, Utility, Partner, Enabler model.
IT Quality System Reports (From: A14 A144)
Reports specifically focused on the quality management system used within IT and
indicating its conclusions on the effectiveness of, and any need for improvement in, the
overall quality management system.
IT Governance and Management System Evaluation (From: A14 A144)
An assessment of the overall performance of the IT Management and Governance System
against the targets set in the IT Management System Framework and in the IT Governance
Model, and an identification of possible process improvement areas.
IT Governance and Management Audit Results (From: A14 A143)
The findings, conclusions, and recommendations of any audit (formal or informal, internal
or external) carried out into any or all of the IT Governance and Management System.
Outputs
IT Governance Framework (To: A112 A113 A114 A12 A121 A14 A142 A143)
The guiding principles, the statements of intent, and the objectives that together shape and
set the direction for the implementation of IT governance.
IT Management System Framework (To: A12 A122 A123 A124 A125 A126 A13 A132 A133
A14 A142 A143)
The logical structure describing the strategic (vision, mission, value proposition, guiding
principles), organizational (organizational mechanisms, roles, accountabilities), process
(activities, work flows, inputs, outputs), and technology (software, hardware) goals, policies
and practices for managing the overall IT function.
IT Quality Management Framework (To: A12 A121 A122 A123 A124 A125 A126)
and practices for quality management across the overall IT function.
Activities
•
•
•
•
Business Business Regulations and

IT Strategy
Strategy Management Business Standards
System Management C4 C1
C3
C2 Policies
Business
Governance
Capabilities
I10
Define IT
IT Governance Governance
O1
and Management Framework IT Governance
Audit Results
A111 Framework
IT Quality
I1
Management
External Models O3
Business Goals
and Practices
Goals IT Quality Management
I4 Framework
Compliance Plans
and Controls Define IT
Management
I2
Market Analysis Goals
A112
IT Management
System Goals
I5
IT Quality
IT Service Provider
Management
Value Profile/D1
Policies
Business
Establish IT
Management Management
Practices Policies
I8
IT Quality System A113 IT Management
Reports System Policies
IT Quality
Management
I9 Practices
IT Governance
and Management
System Evaluation Establish IT
Management
Practices
I3
Underpinning A114
Contracts
I7 IT Management
System Practices O2
IT Research IT Management
Guidance System Framework
I6
and Roadmaps
NODE: A11 TITLE:

IT Governance and Management System Framework CURRENT PAGE:
Figure 2. A11 IT Governance and Management System Framework
•
•
•
•
[A111] Define IT Governance Framework

Description
Creates the principles and tenets for the governance of IT, setting the direction for how governance
capabilities will be established as an integral part of the overall IT Management Ecosystem. The
IT Governance Framework will be constrained and controlled by the overall scheme of governance
from the business as well as regulations, standards, compliance controls, and external models and
practices.
Controls
Business Strategy
policies.
included.
Management)
Inputs
Business Governance Capabilities
The charters, structures, roles and responsibilities, decision making mechanisms and
measurement capabilities, which are used for governance across the overall business
within IT.
The findings, conclusions, and recommendations of any audit (formal or informal, internal
or external) carried out into any or all of the IT Governance and Management System.
External information from the industry (from individual enterprises, from academia and
from industry watchers) describing models, practices and trends in IT management system
topics.
compliance
IT Management System Practices (From: A114)
High-level practices that have been defined in detail for the management system of the IT
endeavor. Once these have been put in place (that is, made operational), they represent an
implementation of the policies.
•
•
•
•
IT Management System Policies (From: A113)

High-level courses of action and guiding principles for the IT function that are required in
order for it to achieve its goals.
IT Management System Goals (From: A112)
Statements of purpose to direct the management system of the IT endeavor, and which
reflect and support the overall goals of the Business.
Outputs
IT Governance Framework (To: A112 A113 A114 A12 A121 A14 A142 A143)
[A112] Define IT Management Goals

Description
Establishes the fundamental tenets, aims, and fundamental directions of the IT Management
System. These will usually address a range of topics, such as customer service, financial
measures, productivity, quality, turn around times, contribution to the community, among others.
Controls
IT Governance Framework (From: A11 A111)
Business Strategy
policies.
Business Management Policies
Policies of the Business that have a bearing on the IT function. They include fundamentals
such as statements of the core values of the business through explicit policies, which must
be followed (for example, in external relations).
included.
Inputs
Business Goals
Goals of the Business.
customer profiles, and the current typical IT service provider scope. The purpose is to
discern general trends and directions in the current IT service marketplace.
A model of the offerings and services desired by the business, which incorporates the
value provided by the IT Business. The model should express, in a form that profiles the IT
Business as an IT Service Provider, and in the style (and with the required attributes)
desired by the business. An example of suitable styles is provided by the Commodity,
Utility, Partner, and Enabler model.
•
•
•
•
Outputs
IT Quality Management Goals (To: A113 A114)
The goals, specifically related to quality management, which will drive the implementation
and operation of quality management approaches for the IT function.
IT Management System Goals (To: A111 A113 A114)
[A113] Establish IT Management Policies

Description
Identifies and creates clearly articulated courses of action and guiding principles that direct policies
in shaping and influencing the development, deployment and operation of the IT Management
System. These policies mandate behaviors and achievements with regard to IT goals, values,
priorities, and key performance measurements.
Controls
Management)
Policies of the Business that have a bearing on the IT function. They include fundamentals
such as statements of the core values of the business through explicit policies, which must
be followed (for example, in external relations).
included.
Inputs
IT Quality Management Goals (From: A112)
•
•
•
•

compliance
topics.
Outputs
IT Quality Management Policies (To: A114)
order for it to achieve its quality management goals.
IT Management System Policies (To: A111 A114)
[A114] Establish IT Management Practices

Description
Identifies and specifies the ways and means for the operation of the IT Management System that
embodies the IT management system policies. Such practices specify the methods employed to
implement policies.
At a business level they will normally represent standard ways of operating that need to be followed
by the whole company.
Other influences, and in some cases constraints, to the selection and design of IT Management
System Practices can come externally, from standard or best practice. Depending on the
relationships with suppliers, certain contractual terms can also dictate the practices that must be
employed.
•
•
•
•
This activity will operate in conjunction with the establish the process framework activity that is part
of each content-specific IT process. As an example, practices will be established within specific
disciplines such as the handling of changes and problems, or planning capacity requirements.
Controls
IT Quality Management Goals (From: A112)
Management)
included.
Inputs
IT Quality Management Policies (From: A113)
order for it to achieve its quality management goals.
IT Management System Policies (From: A113)
compliance
•
•
•
•

topics.
Business Management Practices
Practices dictated by the Business that have a bearing on the equivalent items framed for
the IT function.
an SLA.”2
Outputs
IT Quality Management Practices
High-level practices for quality management that have been defined in detail for the IT
function so as to implement its quality policies.
IT Management System Practices (To: A111)
High-level practices that have been defined in detail for the management system of the IT
endeavor. Once these have been put in place (that is, made operational), they represent an
implementation of the policies.
2. ITIL V3 Glossary
•
•
•
•
[A12] IT Governance and Management System

Capabilities
Purpose
The purpose of the IT Governance and Management System Capabilities process is to define,
establish, and deploy an ecosystem for governing and managing an IT organization (or
undertaking) in order that IT undertakings proceed within the philosophies and controls set by the
parent business. It recognizes that this is not a one-off undertaking, but will be exercised at any
time to create capability adjustments both small and large-scale.
Outcomes
The desired scope for governance is established over a defined set of key decisions, with
clear assignment of decision rights and accountability to appropriate organization units and
roles.
A management system that is consistent with the direction of information technology and
with the enterprise as a whole, and is in control of all IT activities.
The management system is both effective and efficient, ensuring the integrated and
coordinated workings of IT.
A set of coherent, integrated capabilities that enable and empower IT activities is
established
Scope
This process uses a simple model of a management system to illustrate the activities, and their key
inputs and outputs, which will start with the directional frameworks and build a functioning
management ecosystem. Many other models of a management system exist; the one used here
can be summarized as follows:
Governance aspects dictate the overall shape of the capabilities
There are four main components in a management system: process, organization,
(management) information, tools
A management system is made effective by equipping it with measurement and control
capabilities, built from aspects of all the components listed in item two
Includes
Defining information technology management system requirements and key indicators
Building capabilities to realize the specified management models
Creating instruments that conform to policies and standards, such as:
– Methods
– Measurement and control capabilities
– Quality management system
– Continual improvement techniques
Organization design in relation to IT, such as:
– Structure, behaviors, enablers
– Roles and responsibilities definitions
– Process structure
•
•
•
•
– Implementation or change transition plans, including schedule
Excludes
Development of IT solutions for management system needs these compete for
resources alongside other needs (Portfolio Management)
Controls
IT Quality Management Framework (From: A11)
IT Management System Framework (From: A11)
included.
Inputs
topics.
•
•
•
•

The findings, conclusions and recommendations of any audit (formal or informal, internal or
external) carried out into any or all of the IT Governance and Management System.
Outputs
IT Governance Capabilities (To: A122 A123 A124 A125 A126 A13 A131 A132 A133 A14
A141 A142 A143 A144)
The set of instruments that contribute the required governance characteristics to the overall
IT Management Ecosystem. These will include:
• Governance structures and charters
• Decision rights and their assignment to roles
• Decision-making processes and procedures for a specified list of decisions
• Metrics and indicators for the aspects of IT management under governance
IT Management System Capabilities (To: A13 A131 A132 A133 A14 A141 A142 A143
A144)
The foundational constituents of the IT Management Ecosystem. The elements explicitly
identified are:
• Process
• Organization
• Management information
• Tools and systems
• Measurement and control instruments
IT Quality System Capabilities (To: A13 A131 A132 A133 A14 A141 A142 A143 A144)
The foundational components for the operation of the IT quality management system. The
elements explicitly identified here are:
• Process
• Organization
• Information
• Tools, mechanisms and systems
Activities
•
•
•
•
IT Governance IT Quality Management IT Management IT Strategy IT Budget

Framework Framework System Framework
I6 C4 C5
C3 C1 C2
IT Governance
and Management
Audit Results
I5 Establish IT
O1
and Management Capabilities
System Evaluation IT Governance
A121 Capabilities
I2
Architecture Baselines O2
and Roadmaps IT Process IT Management
Establish Capabilities System Capabilities
I1
External Models
IT Process
and Practices Capabilities
A122
IT Organizational
Capabilities
Establish IT
Organizational
I3 Capabilities
IT Research
Guidance
A123 IT Management
Information
Capabilities
Establish IT
Management
Information
I7 Capabilities
IT Portfolio A124
IT Operational
Environment
Establish IT Capabilities
Operational
Environment
Capabilities
A125
IT Measurement
Establish IT and Control
Capabilities
Measurement
and Control
Capabilities O3
IT Quality System
I4 A126 Capabilities
IT Quality System
Reports
NODE: A12 TITLE:

IT Governance and Management System Capabilities CURRENT PAGE:
Figure 3. A12 IT Governance and Management System Capabilities
•
•
•
•
[A121] Establish IT Governance Capabilities

Description
Builds the decision making and accountability mechanisms and capabilities. It establishes the
preferred behaviors to support those items which ensure the desired level of governance is
achieved. The activity will work on aspects such as:
Define governance structures and charters
Define roles and responsibilities within the structures
Define the processes to be followed within the structures
Define the metrics and decision making mechanisms for governance
Define governance tools, such as models, dashboards, and standards
Controls
included.
Inputs
topics.
•
•
•
•
IT Operational Environment Capabilities (From: A125)

The mechanisms (for example: methods, systems, procedures) which, when implemented
in the context provided by the management system process, organization and information,
provide the operational capabilities for the IT Management System.
IT Management Information Capabilities (From: A124)
The informational aspects of the capabilities the IT function will be managed. These
include the specification of the entities, attributes, and relationships of IT management
information, both for the fundamental resources (such as hardware) and for the control
information, like process measurements.
IT Organizational Capabilities (From: A123)
The structure, behaviors, and enablers for the organization dimension of the IT
management system. Includes:
• IT Roles and Responsibilities
• IT Organization Unit Structures and Relationships
• Motivational schemes, such as incentives
• Implementation of enablers (such as Communities of Practice)
IT Process Capabilities (From: A122)
The models and further elaborations of the processes within IT and of their interactions
with processes operated by stakeholders. The development of the capabilities progresses
through several levels of elaboration, from specification and reference to operational and
finally to implemented. They include:
• Activities
Decision pointsWorkflows, including
Policy impacts
Sequencing
Parallelization
• Role mapping (to activities)
Outputs
IT Governance Capabilities (To: A122 A123 A124 A125 A126 A13 A131 A132 A133 A14
A141 A142 A143 A144)
•
•
•
•
[A122] Establish IT Process Capabilities

Description
Oversees and controls the creation and setup of the processes needed within the IT endeavor.
Works in conjunction with the establish the framework activity of each individual process, taking a
cross-IT view.
Controls
IT Governance Capabilities (From: A12 A121)
included.
Inputs
topics.
•
•
•
•

Outputs
IT Process Capabilities (To: A121 A123 A124 A125 A126)
• Activities
• Workflows, including
Decision points
Policy impacts
Sequencing
Parallelization
•
•
•
•
[A123] Establish IT Organizational Capabilities

Description
Establish the basic structure covering roles, responsibilities, accountability, processes, among
others, that make up an effective organization. Works in conjunction with the establish the
framework activity of each individual process, taking a cross-IT view.
Controls
included.
Inputs
Activities
Workflows, including
– Decision points
– Policy impacts
– Sequencing
– Parallelization
Role mapping (to activities)
•
•
•
•

topics.
Outputs
IT Organizational Capabilities (To: A121 A122 A124 A125 A126)
•
•
•
•
[A124] Establish IT Management Information Capabilities

Description
Creates and maintains the informational aspect of the capability that is required for the
management of the IT function. Works in conjunction with the establish the framework activity of
each individual process, taking a cross-IT view. It considers aspects such as:
Information required for the management system to operate
Ownership and responsibilities for such information
Data relationships, schema, and other models
Data currency and life cycle
Controls
Governance structures and charters
Decision rights and their assignment to roles
Decision-making processes and procedures for a specified list of decisions
Metrics and indicators for the aspects of IT management under governance
included.
Inputs
IT Roles and Responsibilities
IT Organization Unit Structures and Relationships
Motivational schemes, such as incentives
Implementation of enablers (such as Communities of Practice)
•
•
•
•
Activities
Workflows, including
– Decision points
– Policy impacts
– Sequencing
– Parallelization
Role mapping (to activities)
topics.
Outputs
IT Management Information Capabilities (To: A121 A122 A123 A125 A126)
•
•
•
•
[A125] Establish IT Operational Environment Capabilities

Description
Oversees and controls the creation and maintenance of the requisite capabilities (systems, tools,
mechanisms) for the delivery of the services of the IT function. The capabilities bring together the
process, organization, and information elements into practical, usable abilities and mechanisms.
Works in conjunction with the establish the framework activity of each individual process, taking a
cross-IT view. Examples of such capabilities would include:
Application and infrastructure development methods
The means by which management communications are disseminated and acted upon.
Controls
included.
Inputs
•
•
•
•

• Activities
Decision points
Policy impacts
Sequencing
Parallelization
topics.
Outputs
IT Operational Environment Capabilities (To: A121 A122 A123 A124 A126)
•
•
•
•
[A126] Establish IT Measurement and Control Capabilities

Description
Provides the capabilities required to measure and control the key aspects of the IT function's
operations to manage them effectively. Works in conjunction with the establish the framework
activity of each individual process, taking a cross-IT view. In addition, it provides a pattern
(template) for quality management that is to be embedded within each process.
Controls
Inputs
•
•
•
•
• Activities
– Decision points
– Policy impacts
– Sequencing
– Parallelization
topics.
Outputs
IT Measurement and Control Capabilities
Capabilities to provide the appropriate measurements and controls to the IT function's
undertakings. Examples include:
• Adecision right (manager approval step in a process)
• Abusiness event log
• Amonitor on configuration parameter
• Arecord of employee training
IT Quality System Capabilities (To: A13 A131 A132 A133 A14 A141 A142 A143 A144)
• Process
• Organization
• Information
• Tools, mechanisms, and systems
•
•
•
•

Purpose
The purpose of the IT Governance and Management System Operation process is to operate and
run the management system to satisfy the overall Business’ needs.
Outcomes
The balance of strategic, tactical, and operational effectiveness of IT is optimized
Informed and effective decisions are made
The workings of IT are integrated and coordinated
Conditions are established to best ensure that key measurements can be and are met
Scope
This process does not direct what IT activities should be performed to reflect the priorities of the
Business (see A3 Direction category of processes). It does, however, oversee monitoring and
control of the collected IT projects and processes, and makes corrective adjustments where
needed.
Includes
Measurement and control, such as:
– Issues management
– CIO dashboard
– Balanced scorecard
Steering IT workings within the tolerances set by Governance
Regulating the execution of IT processes
Excludes
Priorities and decisions on the business results of IT (a business responsibility, with
participation from the processes in the Direction category)
Regulating IT services and solutions (processes in the Direction category)
Controls
IT Quality System Capabilities (From: A12 A126)
• Process
• Organization
• Information
•
•
•
•
IT Management System Capabilities (From: A12)

identified are:
• Process
• Organization
included.
Inputs
Operational Measures and Results
Any measure or result from any IT process that might be relevant to the measurement, and
control activities of the overall IT management system.
Program and Project Reports (From: A37)
The body of information ranging from formal, regular and summarized, through informal, ad
hoc, and detailed about any aspect of program and project status, and plans. It is available
to any process with a need to know.
Service Achievement Reports (From: A24 A244)
One or more reports about how well the service levels have been achieved and which
compare IT's actual service level results achieved against the service level standards and
any specific service level targets negotiated with customers. The reports can include
details of service impacts both directly measured and an assessment of business impact.
Some sections will be for customer distribution and others can be for service provider
receipt only.
•
•
•
•
Customer Satisfaction Results and Trends (From: A27 A276)

A report summarizing current customer satisfaction results and historical data. Can be
used to identify trends.
Outputs
IT Measurements (To: A133)
The measurements and key indicators produced by combining measures and results from
individual sources to create an IT-wide view of IT activities. Individual processes can
access relevant measurements as part of their normal operation.
IT Management Action Items
The invoked actions designed to keep the operation of the overall IT management system
within established tolerances, or in exceptional circumstances, to return it to being within
those tolerances. Action items can include anything from directives and instructions
through general guidance and suggestions.
IT Management System Reports (To: A14 A141)
The results and interpretations of the IT Management System outcomes, including key
performance indicators.
IT Control Results (To: A131 A133 A14 A141)
An indication of the direct outcomes, and any associated consequences that result from the
application of any IT management controls.
Activities
•
•
•
•
IT Management IT Quality System IT Governance IT Portfolio IT Budget IT Management

Capabilities Capabilities IT Strategy
System Capabilities C1 C6 System Framework
C2 C4 C7
C3 C5
I1
Operational
I3
Service Achievement
Reports/D4
I2
Program and Produce IT
Project Reports/D2 Measurements O1
IT Measurements
I4
IT Financial
Reports A131
I5
Customer Satisfaction
IT Management
Results and Trends/D1
Control Items
Operate IT
Governance O2
and IT Management
System Controls
A132
O4
IT Control Results
Monitor,
Analyze and
Report IT O3
IT Management System
Outcomes
Reports
A133
NODE: A13 TITLE:

IT Governance and Management System Operation CURRENT PAGE:
Figure 4. A13 IT Governance and Management System Operation
•
•
•
•
[A131] Produce IT Measurements

Description
Gathers, collates, and assembles the measurements required by the IT function for the effective
operation of the IT Management System. Working on operational data from individual processes,
it combines these and creates IT-wide measurements. Measurements triggering action or warning
tolerances are flagged.
Controls
identified are:
• Process
• Organization
• Process
• Organization
• Information
included.
Inputs
Any measure or result from any IT process that might be relevant to the measurement, and
control activities of the overall IT management system.
•
•
•
•

details of service impacts — both directly measured and an assessment of business
impact. Some sections will be for customer distribution and others can be for service
provider receipt only.
IT Control Results (From: A13 A132)
Outputs
IT Measurements (To: A133)
IT Management Control Items (To: A132)
The identification of IT management system measurements that are approaching or
exceeding established limits which indicate a potential need for overall management
system intervention.
[A132] Operate IT Governance and Management System

Controls
Description
This activity monitors for conditions that could potentially require overall management attention. In
such cases, it would carry out the identification (analysis) and formulation (planning) of necessary
control actions with the objective to correct out-of-line situations. Approaches such as issue
management might be used to formalize these efforts, applying defined control actions to the
activities within the IT function. Ultimately improving performance and meeting the needs of the
overall IT undertaking.
Controls
•
•
•
•

identified are:
• Process
• Organization
• Process
• Organization
• Information
included.
Inputs
IT Management Control Items (From: A131)
The identification of IT management system measurements that are approaching or
exceeding established limits which indicate a potential need for overall management
system intervention.
Outputs
IT Management Action Items
The invoked actions designed to keep the operation of the overall IT management system
within established tolerances, or in exceptional circumstances, to return it to being within
those tolerances. Action items can include anything from directives and instructions
through general guidance and suggestions.
IT Control Results (To: A131 A133 A14 A141)
•
•
•
•
[A133] Monitor, Analyze and Report IT Outcomes

Description
This activity analyzes the results in the IT management system measurements and produces
required reports, both regularly and as necessary on an exception or request basis. These
reports provide an overall view of the workings of the IT function.
Controls
identified are:
• Process
• Organization
• Process
• Organization
• Information
included.
•
•
•
•
Inputs
IT Measurements (From: A13 A131)
Outputs
IT Management System Reports (To: A14 A141)
•
•
•
•
Purpose
The purpose of the IT Governance and Management System Evaluation process is to review and
assess the execution and implementation of the IT governance and management system, and to
identify potential improvements to it.
Outcomes
The overall health of the IT governance and management system is visible to the key
stakeholders of the IT endeavor
Key measurements are effective in guiding the realization of IT goals
Potential problems with the management system are identified and resolved before their
impact results in other problems (for example, customer dissatisfaction)
There is a continual focus on the identification of improvement opportunities to the IT
governance and management system
Scope
This process monitors the measurements from all IT processes in order to ensure that the system
is functioning in the manner intended.
It provides the ability to audit all (or any part of) the IT governance and management system.
Includes
Validating the adherence to management system rules
Identifying continuous improvement actions
Quality management assessment
Assessing the execution of IT processes
Excludes
Making changes to the IT Management ecosystem (IT Governance and Management
System Framework, IT Governance and Management System Capabilities, depending
on the scale of change)
Controls
• Process
• Organization
• Information
•
•
•
•

identified are:
• Process
• Organization
included.
Inputs
External Benchmarks
A representation of the effectiveness, efficiency or other metric of the workings of a survey
or other sample group of businesses or functions within them.
IT Management System Reports (From: A13 A133)
•
•
•
•

details of service impacts — both directly measured and an assessment of business
impact. Some sections will be for customer distribution and others can be for service
provider receipt only.
Business Evaluation Feedback
Any feedback, formal or informal, from non-IT parts of the overall business which is relevant
to evaluating the performance of the IT management system.
Individual Process Evaluations
A collection of metrics which describe the effectiveness and efficiency of an individual
process.
Outputs
IT Quality System Reports (To: A11 A113 A114 A12 A122 A123 A124 A125 A126)
IT Governance and Management System Evaluation (To: A11 A113 A114 A12 A121 A122
A123 A124 A125 A126)
IT Governance and Management Audit Results (To: A11 A111 A12 A121 A144)
•
•
•
•
Activities
A144 Communicate IT Governance and Management System Performance
MODIFY DATE: 14/01/08 07:45 PM C C op yr igh t IB M C or p or at i on , 200 8, A l l R i gh ts R eserv ed
IT Management IT Quality System IT Governance IT Management IT Governance IT Budget IT Portfolio IT Strategy Business
System Capabilities Capabilities Capabilities System Framework Framework C1 Management
C7 C8
C3 C2 C4 C5 C6 System
C9
I2
Reports
I4
IT Financial
Reports Collate IT
I8
Management
Customer Satisfaction System
Results and Trends/D1 Outcomes
A141
I3
IT Control Results Collated IT
Management System
I7
Outcomes
Individual Analyze IT
Process Governance and
Evaluations
Management
I5
Service Achievement
System
Reports/D4 Performance
A142
IT Management and
I1 Governance System
External Benchmarks Performance Analysis
Audit IT
Governance
I6
Business Evaluation
and O3
Feedback and Management
A143 Audit Results
IT Governance and Management

Communicate IT
Audit Request Governance and O1
Management IT Quality System
Compliance Reports
Audit Reports/D1
System
O2
Performance IT Governance
IT Financial A144 and Management
Audit Reports/D1 System Evaluation
NODE: A14 TITLE:

IT Governance and Management System Evaluation CURRENT PAGE:
Figure 5. A14 IT Governance and Management System Evaluation
•
•
•
•
[A141] Collate IT Management System Outcomes

Description
Gathers all relevant information that is needed in order to be able to assess the overall
effectiveness of the management system.
Controls
identified are:
• Process
• Organization
• Process
• Organization
• Information
Inputs
IT Management System Reports (From: A13 A133)
process.
•
•
•
•
any specific service level targets negotiated with customers. The reports can include details
of service impacts — both directly measured and an assessment of business impact. Some
sections will be for customer distribution and others can be for service provider receipt only.
Outputs
Collated IT Management System Outcomes (To: A142 A143)
Collection of all the Management System Assessments into an easy to use format for
further analysis.
[A142] Analyze IT Governance and Management System

Performance
Description
Examines the IT control and performance results to determine how effectively the management
system enables the achievement of the enterprise IT goals, policies, and strategies. The analysis
focuses on the effectiveness, efficiency and related aspects, which indicate the health of the
management system, rather than the value that IT provides for the business (considered in the IT
Direction process).
Specifically, it evaluates the performance of the IT Management System, aiming to identify aspects
of the overall process that require improvement, such as the foundation and interfaces of the
process, activity definitions, key performance metrics, the state of supporting automation, as well
as the roles and responsibilities and skills required. Insights and lessons learned from direct
observation and data collected on process performance are the basis for improvement
recommendations.
Controls
identified are:
• Process
• Organization
• Process
•
•
•
•
• Organization
• Information
included.
Inputs
Collated IT Management System Outcomes (From: A141)
further analysis.
External Benchmarks
A representation of the effectiveness, efficiency or other metric of the workings of a survey
or other sample group of businesses or functions within them.
Outputs
IT Management and Governance System Performance Analysis (To: A143 A144)
Conclusions on the effectiveness (strengths, improvement areas) of the IT Management
and Governance System.
•
•
•
•
[A143] Audit IT Governance and Management

Description
Carries out a thorough examination of the setup and activity of the governance and management
of IT to check that:
The implementation conforms to the constraints set by the parent business and by external
regulations (so that it is capable of achieving the desired results)
The operational workings (for example, measurements, control actions, key decisions)
have been enacted in compliance with the structures and mechanisms in place.
The methods and rules which dictate the audit proceedings will be established first, and will be
influenced by the terms of reference for the audit and whether the auditing body is external or
internal.
In many cases, audits require that management system workings (which provide evidence of
whether conformance can be demonstrated) will need to be organized into the formats and
structures required by the auditors.
Controls
identified are:
• Process
• Organization
• Process
• Organization
• Information
•
•
•
•

Inputs
IT Management and Governance System Performance Analysis (From: A142)
Collated IT Management System Outcomes (From: A141)
further analysis.
IT Governance and Management Audit Request
Invocation of an audit of all or part of the IT Governance and Management System by a
suitably authorized person or body. Also contains the terms of reference for the audit.
Compliance Audit Reports (From: A716)
Documents communicating the results of individual process compliance and mitigation
audits.
IT Financial Audit Reports (From: A816)
Financial audits include validation that accounting rules are being accurately followed and
that costs are aligned with the engagement and client objectives.
Outputs
IT Governance and Management Audit Results (To: A11 A111 A12 A121 A144)
[A144] Communicate IT Governance and Management System

Performance
Description
Communicates the results of the assessment of the IT Management System.
Controls
identified are:
• Process
• Organization
•
•
•
•
• Process
• Organization
• Information
Inputs
IT Management and Governance System Performance Analysis (From: A142)
Outputs
IT Quality System Reports (To: A11 A113 A114 A12 A122 A123 A124 A125 A126)
IT Governance and Management System Evaluation (To: A11 A113 A114 A12 A121 A122
A123 A124 A125 A126)
•
•
•
•
PRM-IT A1 Node Tree
PRM-IT A1 Node Tree
A1 – GOVERNANCE AND MANAGEMENT SYSTEM

Communicate IT Governance and Management System
A144
Performance
Figure 6. A1 Governance and Management System Node Tree
•
•
•
•
PRM-IT A1 Node Tree
•
•
•
•
Description
Purpose
the marketplace.
each process depending on the market complexity.
Rationale
Value
1. ITIL V3 Glossary
•
•
•
•
requirements
business
Controls
Business Strategy
Security Policy (From: A7 A72 A722)
Business and IT Models (From: A3 A33 A333)
IT Plan (From: A3 A36 A365)
Inputs
Incident Information (From: A6 A65 A657)
Problem Information (From: A6 A66 A667)
Change Information (From: A5 A51 A518)
Solution Plans and Commitments (From: A4 A41 A42 A422 A425 A43 A432 A44 A442 A45
A452)
Product Package (From: A3 A35 A353 A354 A355)
Outputs
Customer Output (To: outside the model A276)
SLAs, OLAs, UCs (To: A22 A223 A226 A227 A244 A245 A246 A25 A254 A26 A265 A27
A73 A732 A734 A74 A741 A742 A743 A744 A745 A75 A751 A76 A762 A763 A764 A766
A8 A81 A814 A815 A82 A823 A83 A834 A84 A842)
Service Catalog (To: A21 A213 A22 A222 A223 A224 A226 A236 A24 A242 A243 A25
A81 A812 A83 A831 A833 A834)
•
•
•
•
Change Request (To: A5 A51 A512)
Stakeholder Requirements (To: A214 A22 A222 A26 A264 A3 A35 A352 A36 A364 A365
A4 A41 A413 A7 A73 A732)
Service Level Package (To: A22 A226 A23 A233 A234 A24 A243 A246 A256 A3 A35 A354
A355 A4 A41 A412 A413 A42 A422 A423 A7 A74 A742 A744 A8 A83 A833 A834)
Project Proposal (To: A3 A34 A342 A35 A352 A36 A364)
Market Analysis (To: A1 A11 A112 A113 A21 A211 A223 A23 A232 A25 A252 A26 A262
A3 A31 A313 A34 A343 A35 A352 A36 A364 A365)
Incident (To: A537 A6 A65 A652)
Processes
MODIFY DATE: 14/01/08 07:45 PM C C op yr igh t I B M C or p or at i on , 2 008, A l l R i gh ts R eser v ed
IT Management IT Strategy IT Portfolio Architecture Baselines Security Policy IT Plan IT Budget Business and Business
Ecosystem C5 C9 and Roadmaps C6 IT Models Strategy
C1 C8 C4 C7 C3
C2 Customer
Needs
I9
Service Resilience O8
Plans
Project Proposal
I2 Stakeholder
Customer Input Requirements
Customer Directions O6
and Intentions
Management Stakeholder
A21 Requirements
I5 Services
IT Research Services O9
Customer Agreement Proposal
Guidance Market Analysis
Organization
Service
Marketing and
Marketing Sales Reports
Sales Leads
and Sales
Service Pricing Customer Inputs to A22 IT Industry
and Contract Sales Transactions Customer Knowledge
Information/D1 Profiles Service Level
Service Catalog Communication
Usage Data Service
I10 Catalog O5
Change Service Review Change
Information Management Results Request
O4
I7 Consolidated Business Service
Incident A23 Business Demand
Information Customer Review Demand Baselines Catalog
Value Classification and Forecasts
I12 Input
Product Package Service O3
Level SLAs OLAs UCs
I6 Management O2
Service Metric Data Business Output
and Reports Service Level A24 Business Demand
Reports/D1 Requirements Business Activity Patterns Optimization Service Level Package
and User Profiles Service Achievement Recommendations
I4 Business Demand Reports Demand O1
Underpinning Characteristics
Management Customer Output
Contracts
I8
Problem A25 Service Demand Forecasts
Information IT Customer Capability
Adoption Interventions
Market Data IT Customer IT Customer Capability
I1 Transformation Adoption Plan
Environment IT Customer Benefit
Management Realization Report
Information
A26 IT Customer
I11
Solution Transformation Themes
Business
Plans and and Evaluation Principles
Metrics IT Customer Capability Customer
Commitments Current Adoption Events Customer Customer Satisfaction
Satisfaction Customer
Business Climate Issue Communications
I3 Input Issue Feedback Satisfaction
O10
Business Management Incident
Input
A27
Customer
Satisfaction Customer Satisfaction
Issue Results and Trends
NODE: A2 TITLE:
Customer Relationships CURRENT PAGE:
Figure 1. A2 Customer Relationships Diagram
•
•
•
•
Purpose
The purpose of the Stakeholder Requirements process is to capture, classify, qualify, promote, and
maintain requirements for IT services, from the business and for the management of IT activities.
This also involves providing information on the status of all requirements throughout their life cylce.
Definition of 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.”2
Outcomes
IT service stakeholders provide input concerning individual services or collections of
services
An agreement can be defined between IT customers and providers concerning an IT
service and IT service components
Implemented requirements are justified
IT service management can better meet the stated needs and expectations of customers
Scope
This process is the starting point for the translation of customer needs, typically expressed in
business terms, into functional requirements (in IT terms) that can be acted on by other processes.
It begins with recognizing, verbalizing, and documenting needs. It ends with an established set of
feasible and measurable requirements that is maintained until the requirements are satisfied,
changed, or rejected.
Includes
Handling requirements in support of business capabilities
Handling requirements in support of infrastructure capabilities
Initial feasibility analysis to confirm requirements
Customer validation of requirements statements
Tracking and communicating the status of requirements
Excludes
Order taking (Service Marketing and Sales)
Detailed requirements analysis for any application or service (Solution Requirements)
Activities that deliver solutions and services for the agreed requirements (Realization
category of processes beyond Solution Requirements)
2. ITIL V3 Glossary
•
•
•
•
Controls
included.
Inputs
Customer Needs
An expression in the customer's terms of their wants, needs, and aspirations for IT service,
in both functional and non-functional ways.
Service Catalog (From: A2 A23 A235)
IT Industry Knowledge (From: A22 A228)
Information about the IT industry (in general) and competitive IT service providers (in
particular) which has been created as a by-product of marketing and sales activities.
3. ITIL V3 Glossary
•
•
•
•
Outputs
A4 A41 A413 A7 A73 A732)
Activities
A213 Transform Needs into Stakeholder Requirements
Market IT Portfolio Security Policy

IT Management IT Strategy
Analysis C4
Ecosystem C2 C3
C1 C5
Establish
Stakeholder
Requirements Stakeholder Requirements
Management Management Framework
Framework
A211 Stakeholder
Needs
I1
Customer
Needs Capture
Stakeholder
Infrastructure Needs
Needs
A212
Feasibility
I4
Request
IT Industry
Knowledge
Transform
Needs into O1
I3 Stakeholder Stakeholder
Service Requirements Requirements
Catalog A213
I2 Stakeholder Needs_
IT Research Disqualified Monitor and
Guidance Report Stakeholder Needs and
Requirements Report
Stakeholder
Feasibility Needs and
Guidance Requirements
A214
Stakeholder
Requirements Evaluate
Status Update Stakeholder Stakeholder
Requirements Requirements
Evaluation
Stakeholder Requirements Performance
Management Activity Data A215
NODE: A21 TITLE:

Stakeholder Requirements Management CURRENT PAGE:
Figure 2. A21 Stakeholder Requirements Management
•
•
•
•
[A211] Establish Stakeholder Requirements Management Framework
[A211] Establish Stakeholder Requirements Management

Framework
Description
A framework and guidelines for Stakeholder Requirements Management are developed based on
business and IT strategy. The tasks in this activity include:
Understanding the requirements and specifications for Stakeholder Requirements
Management practices
Enacting the strategy for Stakeholder Requirements Management automated support
Defining evaluation criteria for Stakeholder Requirements Management solutions and
services
Establishing the framework for Stakeholder Requirements Management by defining and
implementing practices and systems that support process activities
Determining skill requirements for the staff and assigning staff based on these systems
Finally, the structure and process of Stakeholder Requirements Management including escalation
responsibilities have to be communicated to the process users.
The establishment of the process framework also includes the continuous improvement of
Stakeholder Requirements Management, meaning the consideration of the Stakeholder
Requirements Management process evaluation and the implementation of recommended
improvement actions.
Controls
included.
Inputs
Stakeholder Requirements Management Evaluation (From: A215)
An assessment of the overall performance of the process against the targets set in the
process framework and an identification of possible process improvement areas.
Outputs
Stakeholder Requirements Management Framework (To: A212 A213 A214 A215)
The framework that governs how the process operates to capture, track, and communicate
stakeholder needs and requirements.
•
•
•
•
[A212] Capture Stakeholder Needs

Description
This activity involves soliciting needs from stakeholders of IT services. This solicitation can occur
through methods such as telephone calls, surveys, or other techniques. Such solicitation can be
proactive to anticipate needs that stakeholders might not yet have recognized.
Controls
Stakeholder Requirements Management Framework (From: A211)
Inputs
Customer Needs
An expression in the customer's terms of their wants, needs, and aspirations for IT service,
in both functional and non-functional ways.
Conditions where a gap in the current infrastructure exists and requires assistance to be
filled. (Includes input such as security requirements from Security Management.)
Outputs
Stakeholder Needs (To: A213)
Conditions describing any stakeholder need for services.
Stakeholder Requirements Management Activity Data (To: A215)
Data resulting from all work carried out by each process activity. Examples would be
volumes, timings, resources used, success and error rates, interfaces invoked, rework,
customer feedback, priorities.
[A213] Transform Needs into Stakeholder Requirements

Description
This activity involves transforming needs from customers and other stakeholders into acceptable
stakeholder requirements. For example, interpreting requests and putting them into a form
whereby providers of IT services can develop a solution and its acceptance criteria, establish
priorities, and obtain agreement from the originator on the interpretation.
Controls
•
•
•
•
Inputs
Stakeholder Needs (From: A212)
Conditions describing any stakeholder need for services.
IT Industry Knowledge (From: A22 A228)
Feasibility Guidance
Could be either or both of:
• A mechanism to evaluate and qualify customer needs
• A feasibility report on a specific set of expressed potential requirements
Outputs
Feasibility Request
A request which expresses the desire to qualify a customer need using a structured needs
evaluation framework. This request could be handled by many processes, including IT
Portfolio Management, IT Research and Innovation, Solution Requirements, Solution
Analysis and Design.
A4 A41 A413 A7 A73 A732)
Stakeholder Needs_ Disqualified (To: A214)
Needs that do not have the proper business justification or are assessed as beyond
technical feasibility.
4. ITIL V3 Glossary
•
•
•
•
[A214] Monitor and Report Stakeholder Needs and Requirements
[A214] Monitor and Report Stakeholder Needs and

Requirements
Description
The service provider's interpretation of the stakeholder needs and requirements is communicated
to the originator and any other relevant, interested parties using a report. The communication of
the report ensures the stakeholder's acceptance of the needs and requirements interpretation.
Controls
Inputs
Stakeholder Requirements (From: A2 A21 A213)
Stakeholder Needs_ Disqualified (From: A213)
Needs that do not have the proper business justification or are assessed as beyond
technical feasibility.
Stakeholder Requirements Status Update
Notifications from any process which addresses these requirements as to their status,
especially when there it changes in some way.
Outputs
Stakeholder Needs and Requirements Report
Document outlining the IT service provider's interpretation of the customers' and other
stakeholders' service needs and requirements. It also provides information about the status
and progress of individual or sets of needs or requirements.
•
•
•
•
[A215] Evaluate Stakeholder Requirements Management Performance
[A215] Evaluate Stakeholder Requirements Management

Performance
Description
The evaluation of the performance of the process' aims at identifying areas of the overall activities
that require improvement. For example, the foundation and interfaces of the process, all activities,
their accomplishment, their degree of automation, as well as the roles and responsibilities including
the respective skills. The bases for the improvements are the insights and the lessons learned from
the observations and analysis of activity accomplishments and results.
Controls
Inputs
Stakeholder Requirements Management Activity Data (From: A212 A213 A214)
Outputs
Stakeholder Requirements Management Evaluation (To: A211)
•
•
•
•
Purpose
The purpose of Service Marketing and Sales process is two fold:
Marketing – To understand the marketplace served by the providers of IT, to identify
customers, to market to them, to generate marketing plans for IT services, and support the
selling of IT services
Sales – To match up customer wants and needs with IT service capabilities, and to sell
appropriate IT services
Outcomes
Existing and potential customers have visibility and understanding of IT capabilities
Awareness of IT services and capabilities is stimulated
Customer and marketplace trends and opportunities are understood
IT service contracts are established at the optimum price point for both customer and
provider
The IT organization is promoted as the IT service provider of choice
Scope
The process addresses marketing to both general and specific customer needs. It involves working
with current internal and external customers as well as identifying potential customers. It supports
the marketing and selling of both current services and potential solutions and services.
Includes
Understanding the market, customer segmentation, the opportunities and the
competitive (to the IT service provider) threats
Developing the list of prospects
Generating marketing and sales collateral; communicating the features, advantages,
and benefits for unique buying criteria
Negotiating and closing sales within pricing guidance and rules
Excludes
Deciding to commission service and solution extensions (Portfolio Management)
Developing solutions and services (Realization category of processes)
Implementing solutions (Transition category of processes)
Preparing contracts (Service Pricing and Contract Administration)
Establishing pricing guidance and rules (Service Pricing and Contract Administration)
Controls
•
•
•
•
included.
SLAs, OLAs, UCs (From: A2 A24 A243)
contracts (UCs).
5. ITIL V3 Glossary
•
•
•
•
Inputs
Customer Organization
Information about the organization of each customer. This will include organizational
structure details and, in particular, identify the positions and individuals who are
stakeholders in each service.
Customer Inputs to Sales Transactions
Customer wants, needs, or general requests around a specific sales opportunity.
Customer Directions and Intentions
Information from customers, whether expressly or implicitly stated within other
communications, which indicates the customers' strategies, plans, wish lists, or other
intentions on the subject of IT service.
Sales Leads (From: A224 A26 A264)
A notice that there might be a potential customer for one or more IT provider services.
Service Pricing and Contract Information (From: A83)
Ranges from generic to specific:
• Services and price list (the complete service price model)
• Standard terms and conditions
• Individual actual and proposed terms and conditions for a specific customer
Market Data
A collection of qualitative and quantitative data items which describe the current and
potential future state of the IT service provider marketplace.
6. ITIL V3 Glossary
7. ITIL V3 Glossary
•
•
•
•
Service Level Package (From: A2 A25 A255)
Outputs
A3 A31 A313 A34 A343 A35 A352 A36 A364 A365)
Marketing and Sales Reports (To: A23 A234 A25 A255 A273 A275 A835)
Reports indicating the outcomes of marketing and sales efforts, and that compare the
current sales and marketing execution to the market plan.
Services Proposal (To: A227 A834)
A document outlining a potential services solution to meet a specific set of customer needs.
Services Agreement (To: A23 A233 A234 A834)
A contractual agreement between IT provider and customer with the intent to exchange a
set of committed deliverables from the provider for a price to be paid by the customer,
under a set of agreed terms and conditions.
Customer Profiles (To: A225 A26 A262 A27 A271)
The body of knowledge about each customer as a result from marketing and sales
activities.
IT Industry Knowledge (To: A21 A213)
8. ITIL V3 Glossary
9. ITIL V3 Glossary
•
•
•
•
Activities
Service Resilience IT Portfolio IT Plan IT Strategy IT Budget Architecture Baselines SLAs OLAs UCs
IT Management Plans C4 C6 and Roadmaps
Ecosystem C3 C7 C8
C1 C5
C2
Prioritized Market
Establish Wants and Needs
I1
Service Service Marketing
Stakeholder
Requirements Marketing and Sales
I8 and Sales Framework
Market Data Framework
A221
Analyze O2
Market Market Analysis
I9
Wants Service
Service Market
Catalog and Needs Market Initiative
A222 Outcomes Proposal
Plan
Create O1
I4
Marketing Project Proposal
IT Research
Guidance Plan Customer Selling
I10 A223 Information Services
Customer Satisfaction Market Execute Marketing
Results and Trends Segmentation and Sales
Marketing Collateral
I2 Plan
Customer
Organization A224 Sales Plan
Manage
Opportunities IT Financial Modeling
I6
Sales Leads
and Forecast Request/S1
I5 SalesA225
and Intentions
Consult and
Services
Propose Proposal
I11 Services
Service Level Package O5
Solutions Services
A226
Agreement
IT Financial Sales Negotiate
Opportunity
Modeling Analysis/D1 and Close O7
I3 Services IT Industry
Customer Inputs to Knowledge
Sales Transactions Opportunity
A227 Analyze
and Report
O6
Sales Marketing Customer
Outcomes and Sales Profiles
I7
Service Pricing
Results Evaluate
A228
and Contract Service
Information/D1 Marketing O3
Service Marketing and and Sales Marketing and
Sales Activity Data Sales Reports
Performance
A229
Service
Marketing
and Sales
Evaluation
NODE: A22 TITLE:
Service Marketing and Sales CURRENT PAGE:
Figure 3. A22 Service Marketing and Sales
•
•
•
•
[A221] Establish Service Marketing and Sales Framework

Description
Based on the business and IT strategy, guidelines and a framework for service marketing and
sales have to be developed. The following tasks belong to this activity:
Understanding the requirements and specifications for service marketing and sales
management
Defining the strategy for service marketing and sales management tools and capabilities,
and how they should be sourced. For example, should they be developed in-house or rely
more on vendor capabilities
Defining evaluation criteria for service marketing and sales management solutions and
services
Establishing the framework for service marketing and sales management by defining and
Determining skill requirements based on these systems for the staff, and assigning staff
Finally, the structure and process of service marketing and sales management including escalation
The establishment of the process framework also includes the continuous improvement of service
marketing and sales management; that is, the consideration of the Service Marketing and Sales
process evaluation and the implementation of recommended improvement actions.
Controls
•
•
•
•
included.
Inputs
Service Marketing and Sales Evaluation (From: A229)
An analysis of service marketing and sales activity data providing an understanding of the
current success or failure of the process, and an identification of potential process
improvements.
Market Segmentation (From: A222)
Customer grouping based on common service consumption patterns.
Outputs
Service Marketing and Sales Framework (To: A222 A223 A224 A225 A226 A227 A228
A229)
The overall scheme of policies, practices, plans, processes, and procedures designed to
govern and optimize all activities for Service Marketing and Sales.
[A222] Analyze Market Wants and Needs

Description
The IT service provider marketplace is analyzed for wants, needs, trends and directions. General
marketplace patterns (including competitive alternative sources of IT service provision), potential
new research and development areas as well as current customer service requirements are
positioned and structured against the current IT provider service offerings. The outcome is a
prioritized set of service oriented market wants and needs, as well as general analysis of
marketplace trends and directions.
Controls
Service Marketing and Sales Framework (From: A221)
Inputs
•
•
•
•

potential future state of the IT service provider marketplace.Market Data
ITIL defines Service Catalog as: "A database or structured Document with information
deliverables, prices, contact points, ordering and request Processes."10
Customer Selling Information (From: A225)
General data on the customer such as contact name, address, position title, organization
name, customer number, and more.
Outputs
A3 A31 A313 A34 A343 A35 A352 A36 A364 A365)
Service Marketing and Sales Activity Data (To: A229)
The metrics defined in the Service Marketing and Sales Framework and populated by all
work performed within the process, as the basis to evaluate performance of the process.
Prioritized Market Wants and Needs (To: A223)
A comprehensive set of capabilities the marketplace is seeking from an IT service provider,
prioritized according to business justification.
Market Segmentation (To: A221)
Customer grouping based on common service consumption patterns.

•
•
•
•
[A223] Create Marketing Plan

Description
This activity creates a service-oriented market plan through analysis of a prioritized set of
marketplace wants and needs, as well as documented customer service requirements. The market
plan is used as the basis of a structured approach for targeting communications to potential
customers.
As service initiative proposals are generated to address gaps in the market plan, they become
project proposals.
Controls
contracts (UCs).
Inputs

12. Both ITIL V3 Glossary
•
•
•
•
Prioritized Market Wants and Needs (From: A222)

A comprehensive set of capabilities the marketplace is seeking from an IT service provider,
prioritized according to business justification.
Outputs
Service Initiative Proposal
A document describing a potential new service, the gap it will fill in the current IT service
portfolio, and the initiative that will be required to put the service in place. This document
includes a business case.
Market Plan (To: A224 A225 A228 A232)
A document that structures the approach to target customers with the current and under
development IT service offerings.

•
•
•
•
[A224] Execute Marketing Plan
[A224] Execute Marketing Plan

Description
The execution of the market plan involves structured, targeted communication of specific
messages to specific market segments, promoting the IT provider's services. This can include
publishing and advertising (formally and informally) these services.
Controls
Inputs
Market Plan (From: A223)
Outputs
Services Marketing and Sales Collateral (To: A225 A226)
Items used to promote the proposed solution to a customer.
Market Outcomes (To: A228)
The results of efforts to create market awareness and thereby generate demand for the IT
service provider's portfolio of solutions. An example would be the number of articles which
reference the provider's services.
Sales Leads (To: A22 A225)

•
•
•
•
[A225] Manage Opportunities and Forecast Sales
[A225] Manage Opportunities and Forecast Sales

Description
This activity identifies, qualifies, tracks, and manages all IT service sales opportunities in support
of the market plan. Its primary responsibility is to provide a streamlined sales process that focuses
on high-priority, high-value opportunities while also ensuring that all potential sales, across the
entire customer base, are being addressed. This activity also produces sales forecasts.
Controls
Services Marketing and Sales Collateral (From: A224)
Customer Profiles (From: A22 A228)
activities.
Inputs
Sales Leads (From: A224 A26 A264)
Outputs
Sales Plan (To: A226 A227 A228)
The plan put in place to manage customer sales interaction with an intention of growing
and streamlining the sales pipeline.
Customer Selling Information (To: A222 A226 A227)
Sales Opportunity (To: A226 A228)
A qualified sales lead, in which a customer has expressed interest for one or more IT
services and would like an understanding of how the services might specifically apply to its
environment and for what price.
•
•
•
•
[A226] Consult and Propose Services Solutions

Description
This activity is responsible for working with customer prospects to understand their specific needs
and IT service opportunities, and then communicating how current service offerings can potentially
fulfill those needs. Once the opportunity has been properly qualified, the result is a proposal that
details how the prospective customer's needs will be met with one or more of the IT provider's
service solutions.
Controls
Sales Plan (From: A225)
contracts (UCs).

•
•
•
•
Inputs
Services Marketing and Sales Collateral (From: A224)
Sales Opportunity (From: A225)
IT Financial Modeling Analysis (From: A812)
The outcome of the request for modeling the financial implications of any aspect of the IT
undertakings.
Outputs
IT Financial Modeling Request (To: A812)
A request for financial modeling to be performed so that the financial implications of a
potential proposal relating to IT resources and capabilities can be understood. Any process
can originate this type of request.

•
•
•
•
Services Proposal (To: A227 A834)

[A227] Negotiate and Close Services Opportunity

Description
This activity manages services proposals from the point they are delivered to potential customers.
It is responsible for acknowledging client feedback related to the proposal including, but not limited
to, content, legal terms and conditions, and pricing. Adjustments can be made to the proposal
based on customer feedback. The activity produces a signed contract or a closed opportunity.
Controls
contracts (UCs).
responsibilities of both parties.” 22

•
•
•
•
Inputs
Services Proposal (From: A22 A226)
Outputs
Services Agreement (To: A23 A233 A234 A834)
Sales Outcomes (To: A228)
The final determination of the sales process, whether the sale closed or was rejected by
the customer.
[A228] Analyze and Report Marketing and Sales Results

Description
This activity compares actual marketing and sales results to the market plan, and reports
achievement metrics which describe the effectiveness of marketing and sales execution for a given
reporting period.
Controls
Inputs
Market Outcomes (From: A224)
The results of efforts to create market awareness and thereby generate demand for the IT
service provider's portfolio of solutions. An example would be the number of articles which
reference the provider's services.
•
•
•
•
Sales Outcomes (From: A227)

The final determination of the sales process, whether the sale closed or was rejected by
the customer.
Sales Opportunity (From: A225)
Outputs
IT Industry Knowledge (To: A21 A213)
Customer Profiles (To: A225 A26 A262 A27 A271)
activities.
Marketing and Sales Reports (To: A23 A234 A25 A255 A273 A275 A835)
[A229] Evaluate Service Marketing and Sales Performance

Description
The evaluation of Service Marketing and Sales Process performance identifies all areas that need
improvement; such as the foundation and interfaces of the process, activity definitions, key
performance metrics, the state of supporting automation, as well as the roles and responsibilities
and skills required. Insights and lessons learned from direct observation and data collected on
process performance are the basis for improvement recommendations.
Controls
Inputs
Service Marketing and Sales Activity Data (From: A222 A223 A224 A225 A226 A227
A228)
Outputs
Service Marketing and Sales Evaluation (To: A221)
An analysis of service marketing and sales activity data providing an understanding of the
improvements.
•
•
•
•
Purpose
The purpose of the Service Catalog Management process is to provide an authoritative source of
consistent information on all agreed services and ensure that it is widely accessible to those who
are approved to view this information.
Outcomes
Customers and approved users trust the published service catalog as the authoritative
description of the services available to them
Accurate information on all operational services and those being prepared to be run
operationally (details, status, interfaces and dependencies) is maintained and updated in
the service catalog
Role-based views of the Service Catalog are created and maintained in order for each role
(such as customers, end users, service management support personnel) to understand
service definitions and use the information effectively
The services catalog is aligned and consistent with the Service Provider and Customer
needs
Scope
The primary output of the process is the Service Catalog itself. It includes a strategic view that
allows the service manager, customers, and IT executives to see the list of services and their
status (for example: available, soon to be available, or soon to be retired), and detailed service
characteristics for negotiation, financial or strategic planning. It also contains a tactical view that
allows IT end-users to request services available to them. Additional information will be available
to personnel involved in the provision of the services represented in the catalog in order to facilitate
the consistent, effective and efficient delivery of those committed services.
Includes
Entering and updating service definitions
Navigation support
View management
Service selection and transaction tracking
Education on how to use the Service Catalog
Excludes
Negotiating and closing Service Agreements (Service Marketing and Sales)
Creating service level agreements (Service Level Management)
Request management, user entitlement authorization and execution workflow
(Request Fulfillment)
Controls
Marketing and Sales Reports (From: A22 A228)
•
•
•
•

included.
Inputs
Services Agreement (From: A22 A227)
Service Catalog Usage Data
Data relating to the access and usage of the service catalog. Examples would be:
• Numbers of read accesses, by user
• Number of enquiries by customers for new or extended services
• Service requests submitted through the catalog mechanism
The data can be used directly for service catalog content and delivery analysis; indirectly to
contribute to understanding which services customers are using, the environmental
conditions under which the services operate, and the quality of the service. This data can
be used for service improvement and in customer relationship management.
•
•
•
•

Outputs
A81 A812 A83 A831 A833 A834)

•
•
•
•
Activities
IT Management IT Strategy Market Analysis IT Portfolio IT Budget Change Management Marketing and
Ecosystem Framework/D3 Sales Reports
C4 C2 C5 C6
C3 C1
Establish
Service Service Catalog
Catalog Management
I2
Customer Management Service Package Framework
Organization Framework Specific Catalog
A231 Requirements
Define
O1
Service
Change
Market Plan/D1 Package Request
Catalog
Requirements
Catalog Presentation A232
Service Catalog
I5 Requirements Build and Content
Product Package
I3
Service Description Maintain
Change Service
Information Catalog
Content Service Catalog
A233 Views
Create and
Maintain
I1
Services Service
Agreement Catalog Views
Target Market
Segment Requirements A234
Publish
I7 Service O2
Service Level Package Service
Catalog Catalog
A235
Monitor,
Analyze and Service Catalog
Reports
I4 Report
Service Catalog Service
Usage Data
Catalog
A236
Evaluate
Catalog Management
Management Evaluation
Service Catalog Management Performance
Activity Data A237
I6
Results and Trends
NODE: A23 TITLE:

Service Catalog Management CURRENT PAGE:
Figure 4. A23 Service Catalog Management
•
•
•
•
[A231] Establish Service Catalog Management Framework
[A231] Establish Service Catalog Management Framework

Description
This activity incorporates applicable elements from the IT Management Ecosystem, including
policies and governance process for maintaining the catalog content and usage. It is within this
activity that:
Interfaces and relationships to other processes are identified
Information inputs and outputs are identified
Guidelines for service catalog classification and prioritization are defined
Sources and receivers of information necessary for Service Catalog Management to be
effective are identified
The structure and meta model for the service catalog are established
Tool requirements are documented
Roles and responsibilities (including the role of the process owner) must be tailored to
meet the requirements of the organization and must be assigned
Skill requirements are identified and training is requested if needed
It specifies measurements used by stakeholders for catalog management evaluation, and
recommends initiatives for continual improvement.
Controls
included.
Inputs
Service Catalog Management Evaluation (From: A237)
Outputs
Service Catalog Management Framework (To: A232 A233 A234 A235 A236 A237)
The logical structure describing the strategic (vision, mission, value proposition),
organizational (organizational mechanisms, roles, accountabilities), process (activities,
work flows, inputs, outputs), and technology (software, hardware) practices for the Service
Catalog Management process.
•
•
•
•
[A232] Define Service Package Catalog Requirements

Description
This activity collects and analyzes Service Catalog Design Requirements, as provided by:
Service Marketing and Sales: go to market plans and sales initiatives
Service Portfolio Management: service offerings direction and guidance
Product Management: presentation requirements for each service offering specification
The requirements are validated with stakeholders for completeness, consistency, and verifiability.
This activity also maintains the service catalog requirements repository and reports requirement
status as needed.
Controls
Service Catalog Management Framework (From: A231)
Inputs
Catalog Presentation Requirements
Requirements for the style, content and usability of the service catalog. They include
expectations, service level commitments, efficient searching, and ordering organized for
each user community.
Outputs
Service Package Specific Catalog Requirements (To: A233 A234)
Each service package can have customizations for different environments, industries, or
integration with technologies. These requirements must be captured and incorporated into
the solution.
•
•
•
•
Service Catalog Management Activity Data (To: A237)

[A233] Build and Maintain Service Catalog Content

Description
This activity determines the scope of service catalog content for sales to external clients and
utilization by end-users, once specific services are installed for a client. It develops the service
catalog specifications from requirements already identified, and creates and maintains standard
templates for service descriptions. The service descriptions (including standards, terms and
conditions, available levels of service, and others) are loaded into the Service Catalog. The activity
also establishes and enforces editing and archiving rules, authorities and accountability of the
content, and regularly validates the accuracy of catalog content with service owners and IT
Management using the governance defined in the process framework.
Controls
Service Package Specific Catalog Requirements (From: A232)
the solution.
Change Management Framework (From: A511)
The policies, procedures, organizational roles and responsibilities and other information
under which the Change Management process will operate to meet its mission and goals.
Inputs
Service Description
A service description includes both the capabilities (utility) and the non-functional
properties (warranty). Non-functional properties include performance, payment, price,
availability (both temporal and locative), obligations, rights, security, trust, quality,
discounts, and penalties.
•
•
•
•

Service Catalog Reports (From: A236)
Service Catalog Reports contain information about:
• Usage patterns, volumes, and trends for the overall Service Catalog and each defined
view
• Each service, such as update history, client activations and customizations, defect
reports, user questions, or other relevant data about the service sent by the user
communities
Outputs
Service Catalog Content (To: A234 A235)
The Service Catalog contains at least the following information:
• Descriptions written in terms familiar to the requestor
• Interactive forms with pricing and categorization
• Components, prerequisites, recommended accessories
• Authorization, escalation, and notification policies
• Delivery processes for optimal quality, speed, efficiency
• Internal and external cost structures and pricing
• Service level and operating level standards
• Reporting on demand, usage, and customizations
[A234] Create and Maintain Service Catalog Views

Description
This activity defines preferred access and navigation patterns by user community and role. It
establishes search, view, and update schema and mechanisms for use by administrators and
users. The activity also maintains the library of active and inactive searches and views based on
client and sales utilization. Finally, this activity verifies catalog integrity and performance of all
views (through testing, inspection, simulation and load testing).
Controls
Service Package Specific Catalog Requirements (From: A232)
the solution.

•
•
•
•

Inputs
Service Catalog Content (From: A233)
Target Market Segment Requirements
Requirements for specific industries, user communities, or executive sponsors are used to
tailor or customize the description of the services.
which the service will be provided. ITIL definition: "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." 27
Outputs
Service Catalog Views (To: A235)
The Service Catalog provides relevant views for all user communities. It should include at a
minimum, however, perspectives from the business manager (customer), administrator,
and the final user.

•
•
•
•
[A235] Publish Service Catalog

Description
This activity maintains comprehensive version control and coordination across service catalog
instances in development, test, and production environments. It establishes and communicates
schedules for refresh of remote or replicated catalog versions, and provides appropriate access
mechanisms to catalog content, for customers, users, providers, and suppliers. The activity also
provides for training and support to customers, users, providers, and suppliers, in proper use of the
Service Catalog.
Finally, the activity provides appropriate notifications to the appropriate user community of
changes to catalog entries, including line items, content, terms and conditions, decommissioning,
and more.
Controls
Inputs
Service Catalog Views (From: A234)
The Service Catalog provides relevant views for all user communities. It should include at a
minimum, however, perspectives from the business manager (customer), administrator,
and the final user.
Service Catalog Content (From: A233)
Outputs
A81 A812 A83 A831 A833 A834)
•
•
•
•
[A236] Monitor, Analyze and Report Service Catalog

Description
This activity supports both the ad hoc query data analysis activity and scheduled standard reports
activity by delivering standard reporting and a mechanism to request and receive ad hoc query
results. The Content Change activity and associated authorization audit trails are tracked and
summarized on a regular basis for business compliance.
The activity also generates usage statistics (including access and browsing patterns), and provides
reports with which to analyze the effectiveness of the transitions among order generation, service
design, request fulfillment, and service level agreement processes.
Controls
Inputs
Service Catalog Usage Data
Data relating to the access and usage of the service catalog. Examples would be:
– Numbers of read accesses, by user
– Number of enquiries by customers for new or extended services
– Service requests submitted through the catalog mechanism

•
•
•
•
The data can be used directly for service catalog content and delivery analysis;
indirectly to contribute to understanding which services customers are using, the
environmental conditions under which the services operate, and the quality of the
service. This data can be used for service improvement and in customer relationship
management.
Outputs
Service Catalog Reports (To: A233)
Service Catalog Reports contain information about:
Usage patterns, volumes, and trends for the overall Service Catalog and each defined
view
Each service, such as update history, client activations and customizations, defect
reports, user questions, or other relevant data about the service sent by the user
communities
[A237] Evaluate Service Catalog Management Performance

Description
This activity collects service execution, performance statistics, and result data for comparison
against defined performance measures. Additionally, this activity captures lessons learned from
process execution and identifies areas of potential process improvement and framework
adjustments. This activity also provides input to the framework activity of this process and to the
IT Governance and Management processes.
Controls
Inputs
Service Catalog Management Activity Data (From: A232 A233 A234 A235 A236)
Outputs
Service Catalog Management Evaluation (To: A231)
•
•
•
•
Purpose
The purpose of the Service Level Management process is to ensure that the service delivered to
customers matches or exceeds the agreed, committed service quality characteristics.
Definition of service level agreement (SLA): “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."30
Outcomes
Both the providers of IT service and their customers have a clear, unambiguous and
consistent expectation of the quality of service to be delivered and received
Service commitments are achievable
Service attainments against targets are reported accurately and in a timely fashion to all
defined service stakeholders
Service quality is revived in an agreed way following any service level breach
Opportunities for continual service improvement are identified and, where cost-justified,
realized
Scope
This process addresses life cycle management of service level agreements. It covers negotiation
of them with IT customers, monitoring service level achievements against targets, performing
service reviews, and initiating service improvement plans.
Includes
Establishing strong relationships with customers based on mutual trust
Implementing SLAs from feasibility through monitoring, renewing, and improving
Integrating the service characteristics of domain specialist processes (such as
Availability, Capacity, and others)
Evaluation of IT transactional service performance in relation to business services and
their requirements
Creation and maintenance of operational level agreements (OLAs) with providers
further along the service supply chain, and consideration of resulting requirements for
and performance defined in underpinning contracts (UCs)
Reporting to customers on any aspect of service level attainment, including reviewing
variation from target
Oversight of the implementation (by other processes) of Service Improvement Plans
related to service level quality

•
•
•
•
Excludes
Making decisions on requests from customers for new services and functionality
Primary responsibility for contractual relationships with either customers or suppliers
(Supplier Management)
Pricing the elements within the service catalog and specific SLAs (Service Pricing and
Contract Administration)
Technical work to implement changes to any service component or operational
procedures relating to service improvements (as appropriate: many individual
processes, Change Management, Portfolio Management)
Controls
included.
Business Strategy
policies.
Inputs
•
•
•
•
• IT Service Continuity Management
(See the definition of the plan output from each individual process for more details.)
Customer Review Input
Any feedback from the customer with regard to service levels and their attainment,
including their prioritization of improvement suggestions.
Service Level Requirements
Requirements with regard to service levels that are requested by the customer and which,
if agreed, will have to be attained by the service provider.
Significant service delivery event logs, volume, and other measurement data relating to
how effectively and efficiently services are provided by IT. This data, which is available as
Service Resilience Reports
The collection of reports produced by the individual processes which are involved in
ensuring the resilience within service management. Processes contributing are:

•
•
•
•
(See the definition of the report output from each individual process for more details.)
These reports detail the volumes, attainments, issues outstanding and other characteristics
detailing the performance and contribution to the overall delivery of service. They include
efficiency reviews and audit reports.
an SLA.”32
Service Demand Forecasts (From: A25 A254)
Agreed predictions of the IT service demand that will be driven if the expected level of
business activity occurs. They are usually arranged by periods against a standard
calendar.
Outputs
A8 A81 A814 A815 A82 A823 A83 A834 A84 A842)

•
•
•
•
contracts (UCs).
Service Level Communication
Information which helps each stakeholder (particularly customers) in service level
management activities to understand the scope, context and specific roles and
responsibilities for carrying them out. It helps promote general awareness of services.
Service Review Results (To: A242 A243 A246 A25 A256 A27 A273 A356)
The outcome from a review of service level attainment. This might include:
• Exceptions and violations with regard to target and actual service delivery
• Determination of responsibility for non-attainment
• Identification of penalties incurred
Service Achievement Reports (To: A13 A131 A14 A141 A245 A246 A25 A255 A256 A27
A273 A275 A365 A366 A735 A736 A744)
details of service impacts – both directly measured and an assessment of business impact.
receipt only.
Customer Satisfaction Issue (To: A27 A274)
Any determination of a customer satisfaction issue. Can be either direct form a customer,
or prompted by any IT staff member in carrying out other processes.

•
•
•
•
Activities
MODIFY DATE: 14/01/08 07:45 PM C C op yr igh t IB M C or p or at ion , 2008 , A l l R i gh ts Re serv ed
IT Management IT Strategy IT Portfolio IT Budget Business Security Policy
Ecosystem C3 C5 Strategy C4
C2
C1 C6
Establish
I11 Service Level
Underpinning Service Level
Contracts
I2 Framework
Customer A241
Organization Service Level
Stakeholder
I1 Register
Service Develop
O2
Catalog Service Service Level
I8 Level Communication
Product Package Relationships
I3 A242 Service Level
Service Pricing Feasibility Request
and Contract Create and
Information/D1
I6 Maintain
Service Level Service Level O1
Requirements SLAs OLAs UCs
Agreements
A243
Availability and
Recovery Design
Criteria/D1
Monitor and
Report O4
Service Level
Feasibility Response Service Level Service Achievement
Reports
I15 Achievements
Service Demand Forecasts O5
A244
I14 Customer
Service Level Package Satisfaction
I9
Conduct Issue
Service Metric Data Service
and Reports O3
Review Service Review
Service Request
Reports/D1 A245 Results
Projected Service Outage/D1
I10 Formulate
Service Resilience Service
Reports/D1 Service Improvement Plan
I4
Improvement
Service Resilience Plan
Plans A246
I13
Customer Satisfaction Evaluate
Results and Trends
I7 Service Level Service Level
Incident Management Management
Information Evaluation
I12 Service Level Performance
Problem Management A247
Information Activity Data
I5
Customer Review
Input
Service Provider
Review Input
NODE: A24 TITLE:
Service Level Management CURRENT PAGE:
Figure 5. A24 Service Level Management
•
•
•
•
[A241] Establish Service Level Management Framework

Description
To establish the framework necessary to manage the Service Level process, these activities must
be addressed:
IT Governance must be engaged to ensure that roles and responsibilities, priority levels in
business and IT terms, and escalation procedures are defined and documented
The appointment of a process owner and other defined roles has to be addressed
The scope of service level management has to be defined, including a detailed life cycle for
the process
A service monitoring plan must be documented that establishes monitoring tool
requirements, identifies monitoring capabilities, and facilitates the implementation of
monitoring tools to meet the requirements
The structure of a service catalog and respective service level agreements have to be
defined, including the process for additions and changes
There must be documented and published review procedures for all Service Level
Management documentation
Finally, the structure and process of the service level management have to be communicated.
The establishment of the Service Level Management Framework also includes the continuous
improvement of service level management. That is, the consideration of the Service Level
Management process evaluation, and the implementation of recommended improvement actions.
Controls
included.
Inputs
•
•
•
•
an SLA.”37
Service Level Management Evaluation (From: A247)
Outputs
Service Level Management Framework (To: A242 A243 A244 A245 A246 A247)
The framework that contains all relevant information about the structure of the Service
Level Management process. It guides the operation of the process, and includes the
following information:
• Classes of agreements under which SLAs can be established, indicating attributes to be
included and the desired range of values for each
• Norms for working relationships with SLA stakeholders
• General approach for working with other processes to:
Establish SLA feasibility
Set targets
Ensure supply of measurements
• Procedures to be followed to investigate and correct any breach of committed targets
• High-level plans for improvement
[A242] Develop Service Level Relationships

Description
This activity establishes and maintains a register of the stakeholders (actors) who have roles to
perform in one or more of the aspects of the Service Level Management process. The register has
a particular focus on the customer stakeholders but also considers service provider stakeholders.
Beyond ensuring that the register is complete and up to date, this activity addresses developing
the relationships among stakeholders so that they are properly briefed on their roles and
responsibilities. It promotes general service awareness and understanding as a foundation for
specific service level workings. It engenders good working relationships and trust between the
stakeholders, addressing any relationship issues that arise.
Controls
Service Level Management Framework (From: A241)
Classes of agreements under which SLAs can be established, indicating attributes to
be included and the desired range of values for each
Norms for working relationships with SLA stakeholders
General approach for working with other processes to:
– Establish SLA feasibility
– Set targets

•
•
•
•
– Ensure supply of measurements

Procedures to be followed to investigate and correct any breach of committed targets
High-level plans for improvement
Business Strategy
policies.
Inputs
Service Review Results (From: A24 A245)
Outputs
Service Level Communication
Information which helps each stakeholder (particularly customers) in service level
management activities to understand the scope, context and specific roles and
responsibilities for carrying them out. It helps promote general awareness of services.
Service Level Stakeholder Register (To: A243 A244 A245 A246)
A record of the customer contacts (positions, names) that have a role to play in one of more
of the activities that comprise the service level management life cycle. This information can
also be useful for other customer relationship purposes.
Service Level Management Activity Data (To: A247)
Any data about the accomplishment of process activities relevant to the evaluation of the
overall service level management process.

•
•
•
•
[A243] Create and Maintain Service Level Agreements

Description
Based on the services in the Service Catalog and on (customer) requirements (gathered through
an open dialog and feedback process) service level agreements (SLAs) will be defined.
The proposed service level targets will be aligned to the requirements as well as the service
delivery capabilities and plans (availability, capacity, performance). Service delivery can be in-
house or external, or a combination. An understanding of the relationship of cost components to
the proposed targets must also be established.
The documentation of the SLAs includes a description of the services and the respective quality
levels (as defined in the Service Catalog or with variations for a defined set of customer contexts
and scope of requirements), as well as defined key targets.
The SLAs will then be negotiated with the customers so that the content can be finalized, and finally
the service level agreement can be set up between the service provider and the customer.
If modifications, additions, or improvements are necessary, the SLAs have to be updated and
maintained.
Where appropriate and necessary to ensure service delivery that meets SLAs, operational level
agreements (OLAs) are established with both internal service providers and with external service
providers. For the latter, the OLA terms will often be formalized through the Supplier Management
process in a contract (known in ITIL as an Underpinning Contracts) with the external service
provider.
Controls
Service Level Stakeholder Register (From: A242)
A record (of the customer contacts) with a role to play in one or more of the activities that
comprise the Service Level Management life cycle. This information can also be useful for
other customer relationship purposes.
Set targets
Business Strategy
policies.
•
•
•
•

Inputs
an SLA.”40
Service Level Requirements
Requirements with regard to service levels that are requested by the customer and which,
if agreed, will have to be attained by the service provider.
Availability and Recovery Design Criteria (From: A733)
General solution design principles that enhance service availability and recovery. This
information is used to create or update solutions so that they are more resilient.

•
•
•
•
Service Level Feasibility Response

The assessment by specific IT processes (often those in Service Management) on the
feasibility of achieving successful delivery of service against a postulated service level
target or commitment.
calendar.
Service Improvement Plan (From: A246)
A plan and roadmap for improving service levels. For example, if service levels are not
attained or if service levels have to be changed. It is based on service level reviews, and
customer and service provider improvement suggestions.
Outputs
Service Level Feasibility Request
A request to specific IT processes (often those in the Resilience category) to assess the
feasibility of successful delivery of service against a postulated service level target or
commitment.

•
•
•
•
A8 A81 A814 A815 A82 A823 A83 A834 A84 A842)
contracts (UCs).
[A244] Monitor and Report Service Level Achievements

Description
This activity examines monitored data from service delivery and statistics related to specific service
level targets, and creates reports on service level attainment. These reports include insights based
on data directly from the service provider organization, as well as from direct customer feedback
(positive and negative). Service achievement reports are produced for both customers (business
units or external customers) and IT management use.
Controls

•
•
•
•
contracts (UCs).
Set targets
Inputs
Service Request Reports (From: A615)
Any reports that reflect the status of service requests with the purpose to control the quality
of service fulfillment, the compliance with existing SLAs, for planning purposes and as a
basis for improvements.

•
•
•
•
Projected Service Outage (From: A515)

As defined in ITIL: “A Document that identifies the effect of planned Changes, maintenance
Activities and Test Plans on agreed Service Levels.” 48
The collection of reports produced by the individual processes which are involved in
ensuring the resilience within service management. Processes contributing are:
(See the definition of the report output from each individual process for more details.)
Outputs
Service Achievement Reports (To: A13 A131 A14 A141 A245 A246 A25 A255 A256 A27
A273 A275 A365 A366 A735 A736 A744)
receipt only.

•
•
•
•
[A245] Conduct Service Review

Description
The purpose of this activity is to use service achievement reports to reveal and assess existing and
potential gaps between target and actual service delivery or service level achievements.
SLAs and actual service delivery results are regularly reviewed and compared, often in formal
review meetings. These reviews include assessment of customer feedback in order to encompass
both the measured results of service attainment as well as the customer's service quality
perceptions. Where needed in relation to non-attainment of commitments, responsibilities are
allocated and resulting penalties are identified.
Trending should be summarized and used as input to both the reconsideration of service level
agreements and to Service Level Management maintenance activities.
Controls
contracts (UCs).

•
•
•
•
Classes of agreements under which SLAs can be established, indicating attributes to

be included and the desired range of values for each
Norms for working relationships with SLA stakeholders
General approach for working with other processes to:
– Establish SLA feasibility
– Set targets
– Ensure supply of measurements
Procedures to be followed to investigate and correct any breach of committed targets
High-level plans for improvement
Inputs
receipt only.
Service Provider Review Input
Prioritized improvement suggestions for service level attainment by the service provider;
meaning the service delivery units and responses to the feasibility of adopting customer or
service level manager suggestions.
Outputs
Service Review Results (To: A242 A243 A246 A25 A256 A27 A273 A356)
Exceptions and violations with regard to target and actual service delivery
Determination of responsibility for non-attainment
Identification of penalties incurred
•
•
•
•
[A246] Formulate Service Improvement Plan

Description
Assessment from service level results, customer feedback, and service delivery units, with regard
to improvement suggestions, provides the input for creating and formulating the Service Level
Improvement Plan. It focuses on recommendations for SLA compliance improvements and specific
target modifications as a precursor to adjusting service provision, monitoring, or the individual
agreement.
Prior to finalizing the service improvement plan, more feedback from the service provider (the
service delivery units) must be gained and become part of the plan in order to be aligned with the
service delivery capabilities.
The service improvement plan should be tracked and maintained regularly.
Controls
operational sevel agreements (OLAs). OLAs are not usually visible to the customer.
contracts (UCs).
• SLA: "An Agreement between an IT Service Provider and a Customer. The SLA
multiple IT Services or multiple Customers."52
• OLA: "An Agreement between an IT Service Provider and another part of the same
responsibilities of both parties." 53

•
•
•
•

Set targets
Inputs
receipt only.
calendar.

•
•
•
•

Service Provider Review Input
Prioritized improvement suggestions for service level attainment by the service provider,
i.e. the service delivery units, and responses as to the feasibility of adopting customer or
service level manager suggestions.
Outputs
Service Improvement Plan (To: A243)
A plan and roadmap for improving service levels. For example, if service levels are not
attained or if service levels have to be changed. It is based on service level reviews, and
customer and service provider improvement suggestions.
•
•
•
•
[A247] Evaluate Service Level Management Performance

Description
This governance activity includes the evaluation of the performance of the Service Level
Management process and aims at the improvement of the overall process. That is, the foundation
and interfaces of the process, all activities, their accomplishment, the adaptability of the process,
as well as the roles and responsibilities including the respective skills.
Basis for the improvements are insights and lessons learned from the observations and analysis
of activity accomplishments and results.
Basically, the improvements should lead to more efficiency in the process; for example, better
management of service levels.
Controls
Set targets
Inputs
Service Level Management Activity Data (From: A242 A243 A244 A245 A246)
Outputs
Service Level Management Evaluation (To: A241)
process framework, and an identification of possible process improvement areas.
•
•
•
•
Purpose
The purpose of the Demand Management process is to understand the patterns of the customers’
business behaviors and relate those patterns to the impact on the supply of IT services. The intent
of this process is to synchronize the consumption (demand) with the capacity (supply) of IT
resources.
The benefit of demand management is to maximize the business value (value defined as benefit
minus cost of the business process or business service) from the investment in IT resources.
(Capacity Management focuses on the behavior of those IT resources; Demand Management
understands and influences the behavior of IT resource consumers.)
Outcomes
IT understands defined and tracked patterns of business activity (user profiles and
geographic distribution)
Patterns of consumption are identified
Service level package56 recommendations are provided to Service Level Management
Instances of insufficient and excess capacity are minimized
Consumption and production of service capacity are synchronized
Demand policies and incentives are defined (both positive and negative)
Scope
This process understands the expected business behavior of all demand sources across all
customers, both at an individual customer level and collated to represent the overall impact on IT.
It translates demand from business terms into IT service terms (such as consumption units). It
identifies gaps and misalignment between demand and supply, and proposes policies and
incentives designed to minimize or close the gaps.
Includes
Definition of high-level strategy and policy to influence demand
Consideration of all mechanisms that can influence demand, including:
– Rewards
– Penalties
– Service availability restrictions
– On demand capacity allocation
Investigation of both internal and external inhibitors to demand
Recommendations for IT resource investment (when demand management measures
are unable to reduce demand to fit within available supply)
Translation of patterns of business activity into IT service consumption
Recommendations on cost and price elasticity
56. See the PRM-IT Glossary and the ITIL V3 Glossary

•
•
•
•
Excludes
Implementation of demand influencing activities, such as policies and incentives
(Capacity Management, Service Pricing and Contract Administration)
Service portfolio content definition (Portfolio Management)
Service catalog content update (Service Catalog Management)
Investment decisions (Portfolio Management)
IT resource consumption monitoring and reporting (Service Execution, Capacity
Management)
Controls
contracts (UCs).
responsibilities of both parties."58

•
•
•
•

Business Strategy
policies.
Inputs
receipt only.
•
•
•
•

Business Activity Patterns and User Profiles
Business activity patterns reflect the typical workload profile from one or more business
activities. User profiles are collations of business activity patterns to reflect that most users
are actors within several business processes, and these combinations vary depending on
organization design. Refer to the ITIL Glossary and to the Service Strategy book for further
reading.
Business Demand Characteristics
Data from business units and customers describing the characteristics of business
demand. The characteristics focus on information about the demand in the context of
business strategy (to support evaluation and classification).
Business Metrics
Metrics (measurements, key performance indicators) on business performance. They are
provided by the business whether or not the underlying data is managed by IT solutions.
A452)
timeframe.
Outputs
Business Demand Value Classification (To: A253)
A scheme for classifying each business demand stream as a basis for making decisions in
the event of demand exceeding supply and the results of performing the classification,
particularly to include the business value characteristic.
Consolidated Business Demand Baselines and Forecasts
Agreed statement of the combination of the expected business demand for the normal
(typical) pattern of business, and of the future predictions of business demand for IT
service, usually arranged by periods against a standard calendar.
Business Demand Optimization Recommendations (To: A256)
Statements of opportunities for influencing business demand by identifying the most likely
lever (or levers), that could achieve a result, plus outline plan suggestions for their
implementation. Levers can have impact directly on a business process, the quality of the
IT-provided service, or both.
•
•
•
•
Service Demand Forecasts (To: A24 A243 A246 A255 A256 A742 A745)
calendar.
Activities
A257 Evaluate Demand Management Performance
IT Management IT Portfolio Business Business and SLAs OLAs UCs Service IT Plan
Ecosystem C5 Strategy IT Models Catalog C3
C1
C4 C7 C6 C2
Establish
I3
Demand Demand Management
Market Analysis
Management Framework
I6 Framework
IT Research A251
Guidance
Value and
Classify O1
Business Demand
I8 Business Value Classification
Business
Business Demand Demands
A252 Demand
Characteristics
Baselines
I9 Consolidate
Business Business O2
Consolidated Business
Metrics Demand Demand Baselines
Patterns and and Forecasts
I10 Service
Forecasts Demand O6
A253 Service Demand Forecasts
Results and Trends Baselines
I7 Forecast O4
Business Project Proposal
Business Activity Patterns
and User Profiles
Demand Service
Forecasts Demand
Capacity Baselines IT Financial Modeling
and Profiles/D1 Request/S2
A254
I5 Service O3
Service Resilience Demand Identify and Business Demand
Plans Models Plan Optimization
Demand Recommendations
Service Price Model/D1
I4 Management
Marketing and O5
Sales Reports Initiatives Service Level Package
A255
I11 Assess and
Solution Demand Management
Plans and Report
Outcomes Report
Commitments Demand
I2 Management
Service Achievement Outcomes
Reports A256
IT Financial
Modeling Analysis/D2 Evaluate
Demand Demand
Service and Management Management
Evaluation
Resource Tuning Demand Management Performance
Directives/D1 Activity Data A257
Capacity Reports/D1
I1
Service Review
Results
NODE: A25 TITLE:

Demand Management CURRENT PAGE:
Figure 6. A25 Demand Management

•
•
•
•
[A251] Establish Demand Management Framework
[A251] Establish Demand Management Framework

Description
This activity defines the way Demand Management is to be managed and controlled. It defines the
rules by which each relevant business unit, customer or other stakeholder interacts with this
process, and determines how it interfaces with other related processes within IT.
The activity facilitates the creation of a Demand Management Framework, which is essential in
ensuring that business demands can be synchronized in an agreed manner with IT service
capacity.
It creates and maintains the scope, policies, standards, responsibilities, and procedures of
the Demand Management process. This includes defining and implementing rules of
operation and other governance aspects (including conflict resolution), determining
relationships with other processes, and creating specifications of the process inputs and
outputs.
It also carries out the assignment of roles and responsibilities.
This is not a one-off activity, but should be undertaken periodically to ensure that the framework
remains suitable for the business. It also takes into account any changes to the size of the
organization, service levels, business, IT strategies, and operational plans.
Controls
Inputs
Demand Management Evaluation (From: A257)
An analysis of activity data for Demand Management, providing an understanding of the
improvements.
Outputs
Demand Management Framework (To: A252 A253 A255 A256 A257)
The set of structures describing the strategic (vision, mission, value proposition),
work flows, inputs, outputs), and technology (software, hardware) practices for managing
demand.
•
•
•
•
[A252] Value and Classify Business Demands

Description
This activity focuses on two linked work items:
It defines a value-driven classification scheme for business demands. In other words, it will
establish a set of criteria against which each demand from the business for IT service can
be evaluated. Some examples of items to be considered:
• Criticality for demand to be satisfied, and in what manner. Should service be excellent,
or is adequate sufficient?
• The classification scheme categories themselves. These would usually cover a
spectrum from must have to nice to have.
Performing the valuing and classifying work—along with the relevant stakeholders for each
demand item—for each identified business demand.
A critical success factor for this activity is that all appropriate stakeholders for each demand are
properly involved in the collection, analysis, and decisions.
Controls
Demand Management Framework (From: A251)
demand.
Business Strategy
policies.
Inputs
Business Demand Characteristics
Data from business units and customers describing the characteristics of business
demand. The characteristics focus on information about the demand in the context of
business strategy (to support evaluation and classification).
Demand Management Outcomes Report (From: A256)
Information about the success (or otherwise) of the Demand Management activities across
several aspects:
• Representing business demand in IT service consumption units
• Identifying supply and demand gaps
• Recommending interventions to realign demand to match supply
•
•
•
•
Outputs
Business Demand Value Classification (To: A253)
Demand Management Activity Data (To: A257)
[A253] Consolidate Business Demand Patterns and Forecasts

Description
This activity collaborates with the agreed sources of business demand data in order to build a
comprehensive understanding of the overall demand. Tasks to be performed can include:
Collect Business Demand Patterns
• Techniques such as Business Activity Modeling (as described in the ITIL Service
Strategy book) might be relevant for this.
Translate Business Demand Patterns (into the agreed, common format)
Analyze Business Demand (for example, understand the types of demand and the
confidence levels in the data, for customers of IT, both internal and external)
Forecast Business Demand
Communicate the patterns and forecasts to agreed recipients (taking account of the
sensitivity of the information)
Controls
Business Demand Value Classification (From: A25 A252)
demand.
Inputs
Business Metrics
•
•
•
•

reading.
several aspects:
Outputs
Business Demand Baselines (To: A254 A256)
An agreed statement of the expected business demand for the normal (typical) pattern of
business. A baseline is "A Benchmark used as a reference point." 62
Business Demand Forecasts (To: A254 A256)
Agreed predictions of business demand for IT service, usually arranged by periods against
a standard calendar.
[A254] Forecast Service Demand

Description
This activity translates the agreed business forecasts into the consumption units for the IT services
that satisfy each of the business demands. Each service can have its own scheme of consumption
units (perhaps used as a basis for comparison of supply and demand within that particular service)
and there will be an overall scheme of service units to support the creation of an IT-wide forecast,
including identification of divergence between demand and supply.
Tasks performed within this activity include:
Identify Service Demand Patterns
Baseline Service Demand Patterns
Analyze Service Demand (for example, to identify any differences between demand and
supply)
Model Service Demand, with particular focus on which business variables have significant
impact on IT service demand sensitivity
Collate Service Demand Forecasts

•
•
•
•
Controls
contracts (UCs).
deliverables, prices, contact points, ordering and request Processes." 66

•
•
•
•
Inputs
Business Demand Baselines (From: A253)
Business Demand Forecasts (From: A253)
Capacity Baselines and Profiles (From: A743)
Collective representations of current (and projected) capacity for selected groups of assets
and resources, as well as patterns of consumption by various consumers.
Outputs
Service Demand Baselines (To: A255)
An agreed statement of the IT Service demand that will be driven by the expected business
demand for the normal (typical) pattern of business. A baseline is "A Benchmark used as a
reference point." 68
Service Demand Forecasts (To: A24 A243 A246 A255 A256 A742 A745)
calendar.
Service Demand Models (To: A255)
Analysis of the relationships between typical business activity patterns and the
consequential demand for IT service.
[A255] Identify and Plan Demand Management Initiatives

Description
This activity analyzes any misalignment between demand for and supply of IT services. For any
gaps identified in this way, it determines whether demand management measures have the
potential to help close them. It formulates a prioritized set of recommendations (agreed with the
business) for demand optimization, recognizing that the measures which will influence demand
can require coordinated focus within the business and in Capacity Management, and can involve
a combination of incentives and penalties (typically pricing). When an approach for demand
optimization has been finalized, a plan of action to implement the demand influencers is created
and communicated to all relevant parties.
Controls
Service Demand Baselines (From: A254)
An agreed statement of the IT Service demand that will be driven by the expected business
demand for the normal (typical) pattern of business. A baseline is "A Benchmark used as a
reference point." 69

68. ITIL Glossary
69. ITIL Glossary
•
•
•
•

demand.
Inputs
calendar.
Service Demand Models (From: A254)
Analysis of the relationships between typical business activity patterns and the
consequential demand for IT service.
reading.
Service Price Model (From: A833)
The service price model describes all inputs needed (for example, service model,
measures, service levels, customer) to derive a price for a delivered service. It is often
presented as a multidimensional matrix, with one dimension for each input. It describes as
output one price for each combination.
•
•
•
•
A452)
timeframe.
several aspects:
receipt only.
undertakings.
Outputs
potential proposal relating to IT resources and capabilities can be understood. Any
process can originate this type of request.
Business Demand Optimization Recommendations (To: A256)

•
•
•
•

[A256] Assess and Report Demand Management Outcomes

Description
This activity examines the service performance against both the expected business demand
forecast and the set of demand management influencers which have been implemented. It
determines the degree of success in closing any gaps between supply and demand, and
communicates the results to relevant parties. In particular, it assesses the effectiveness of any
demand management initiatives which have been in operation, and the likely factors which led to
success (or failure).
Controls
demand.
Inputs
Business Demand Optimization Recommendations (From: A25 A255)
calendar.
Business Demand Baselines (From: A253)
Business Demand Forecasts (From: A253)

•
•
•
•
A452)
timeframe.
receipt only.
Service and Resource Tuning Directives (From: A744)
Ranges from traditional performance tuning through capacity and workload allocation
adjustments.
Capacity Reports (From: A74 A743)
Information about the results and outcomes observed and achieved relating to all aspects
of capacity. Reports include:
• Performance and capacity results
• Workload analysis
• Forecasts and predictions
Outputs
Demand Management Outcomes Report (To: A252 A253 A255)
several aspects:
•
•
•
•
[A257] Evaluate Demand Management Performance

Description
This governance activity includes the evaluation of the performance of the Demand Management
process and aims at identifying improvement areas of the overall process. For example, the
foundation and interfaces of the process, all activities and their accomplishment, the adaptability
of the process, as well as the roles, responsibilities, and related skills.
In addition, the Demand Management process is to be evaluated against the goals and measures
to understand its influence on overall IT improvements.
The basis for the improvements are insights and lessons learned from the observations and
analysis of activity accomplishments and results.
Controls
demand.
Inputs
Demand Management Activity Data (From: A252 A253 A254 A255 A256)
Outputs
Demand Management Evaluation (To: A251)
An analysis of activity data for Demand Management, providing an understanding of the
improvements.
•
•
•
•
Purpose
The purpose of the IT Customer Transformation Management process is to assist customers in the
transformation of their business throughout the life cycle; from the genesis of transformation ideas
through the measurement and optimization of the benefits from implemented transformation.
While this process primarily exists to support technology-based transformation, a customer might
request assistance under this process for other kinds of transformation (a quality improvement
program, using an approach like LEAN).
Outcomes
Transformation opportunities, both incremental and more foundational, are identified and
prioritized
Customers and the business are encouraged to adopt transformational capabilities
The IT organization contributes to the exploitation of transformational capabilities by
guiding and overseeing their introduction
The benefits achieved by transformation are defined, measured, analyzed, improved and
controlled
Reports indicating both benefits missed as well as further, unanticipated benefit potential
inform transformation leadership teams
Scope
Includes
Being able to deal with each identified customer in a manner relevant to their
individual needs
Gaining sufficient understanding of the customer's business in order to contribute at
the desired level
Where appropriate:
– Establishing joint working arrangements with the designated customer
representatives
– Providing business modeling and business case development skills and capabilities
– Supporting transformation based on cultural and procedural change that is not
(significantly) technology based
Contributing to the cultural changes and other organizational change management
efforts needed for successful transformation
Benefit measurement and reporting
Excludes
Decision making on the portfolio impact (for example, new services) resulting from
transformation proposals (Portfolio Management)
Direct development of information technology solutions and services (Realization
category of processes)
•
•
•
•
Controls
contracts (UCs).
included.

•
•
•
•
Business Strategy
policies.
Inputs
activities.
Market Data
IT Customer Capability Adoption Events
Notable milestones (both successes and failures) in the customer's adoption of
transformational capability.

•
•
•
•

Business Metrics
Current Business Climate
Information about the state of the customer's business. Includes business metrics and
projections directly relating to the customer as well as directional statements such as press
releases, annual reports, and other articles.
A452)
timeframe.
Outputs
IT Customer Capability Adoption Interventions
Any actions or efforts designed to promote the adoption of transformational capabilities.
Examples of such interventions include:
• Communications
• Training programs
• General consultancy and assistance into better, deeper or broader usage of the
capability
IT Customer Capability Adoption Plan (To: A266)
The overall plan for enabling and promoting capability adoption. This ranges from
customer-wide items such as general awareness and communications through training
programs customized to local needs, and possibly the provision of individual guidance and
consultancy.
IT Customer Transformation Themes and Evaluation Principles (To: A244 A245 A246 A263
A312 A363)
A statement of the general headings under a customer's business operations that might be
transformed together with a set of evaluation principles which can be used to prioritize
alternative transformation candidates.
IT Customer Benefit Realization Report (To: A264 A265 A266)
A report describing the benefits realized by the customer from the adoption of
transformational capabilities. Different types of reports are possible, including:
• Timetable for changes in realized benefit (typically as penetration advances)
• Comparison of actual against plan
• Indication and analysis of missed or additional benefit exploitation opportunities
•
•
•
•
Activities
IT Management IT Strategy IT Budget IT Portfolio Business IT Plan SLAs OLAs UCs
Ecosystem C3 C6 C4 Strategy C5 C1
C2 C7
I5
Market Data Establish IT
I3 Customer
Market Analysis Transformation IT Customer Transformation
Management
I1 Framework
Customer A261
Profiles IT Customer
Understand Context
IT Customer
Context IT Customer
Transformation
I11 A262 Candidates
Current
Business Climate
Identify IT O5
Customer IT Customer
I9 Transformation Transformation Themes
Customer Directions and Evaluation Principles
and Intentions Opportunities
A263
I8
IT Research Develop IT O6
I4 Guidance Customer Sales Leads
Stakeholder O1
Requirements
Transformation Project Proposal
Proposal
Project Plan/D1 A264 IT Financial Modeling
IT Financial Request/S3
Modeling Analysis/D3 Enable and
I12 O2
Solution Promote IT IT Customer Capability
Plans and Customer Adoption Interventions
Commitments Capability
I7 O3
IT Customer Capability IT Customer Capability
Adoption
A265 IT Customer Capability
Adoption Events Enabling Requirements Adoption Plan
Knowledge Assets/D3
I2 Optimize IT O4
Service Customer IT Customer Benefit
Catalog Benefit Realization Report
Realization
Proposed A266
I6 IT Customer Capability
Service Resilience Adoption Improvements Evaluate IT
Plans Customer IT Customer
Transformation Transformation
I10 Evaluation
Business IT Customer Transformation Performance
A267
Metrics Management Activity Data
NODE: A26 TITLE:

IT Customer Transformation Management CURRENT PAGE:
Figure 7. A26 IT Customer Transformation Management
•
•
•
•
[A261] Establish IT Customer Transformation Management Framework
[A261] Establish IT Customer Transformation Management

Framework
Description
A framework and guidelines for IT customer transformation management are developed based on
business and IT strategy. The following tasks belong to this activity:
Understanding the requirements and specifications for IT customer transformation
management practices. These will need to accommodate a range of possible customer
interface styles, such as supplier, partner or enabler
Establishing the framework for stakeholder requirements management by defining and
Based on these systems, determining skill requirements for the staff and assigning staff
Defining evaluation criteria for IT customer transformation management solutions and
services
Finally, the structure and process of IT customer transformation management including escalation
responsibilities have to be communicated to the process users. The establishment of the process
framework also includes the continuous improvement of IT customer transformation management;
that is, the consideration of the IT Customer Transformation Management process evaluation and
the implementation of recommended improvement actions.
Controls
included.
Inputs
IT Customer Transformation Management Evaluation (From: A267)
Outputs
IT Customer Transformation Management Framework (To: A262 A263 A264 A265 A266
A267)
The conceptional structure describing the strategic (vision, mission, value proposition),
customer transformation.
•
•
•
•
[A262] Understand IT Customer Context
[A262] Understand IT Customer Context

Description
An understanding of the customer's business context is an essential prerequisite to contributing to
any transformational initiatives. This activity examines information about the customer's business
from many sources in order to understand the key business drivers and imperatives.
Controls
IT Customer Transformation Management Framework (From: A261)
Business Strategy
policies.
Inputs
Market Data
activities.
Outputs
IT Customer Context (To: A263)
A digest summarizing and analyzing the customer's business activities and the key
business drivers and imperatives which influence the direction of that business. Includes
consideration of the main uses of information technology within that business and in
comparison with industry competitors and leaders.
IT Customer Transformation Management Activity Data (To: A267)
•
•
•
•
[A263] Identify IT Customer Transformation Opportunities

Description
This activity reviews existing exploitation of information technology by each customer against what
might be possible, and works to identify opportunities for incremental or large-scale transformation.
Specific aspects include:
Analyze current customer usage of technology-enabled business capabilities
Formalize customer directions and intentions into themes and evaluation principles
Review the art-of-the-possible for business capability opportunities
Identify viable innovation candidates
Controls
Inputs
IT Customer Context (From: A262)
A digest summarizing and analyzing the customer's business activities and the key
business drivers and imperatives which influence the direction of that business. Includes
consideration of the main uses of information technology within that business and in
comparison with industry competitors and leaders.
IT Customer Transformation Themes and Evaluation Principles (From: A24 A243 A26
A266)
•
•
•
•
Outputs
A363)
IT Customer Transformation Candidates (To: A264)
A list of possible transformational opportunity areas for the customer. It will usually be
categorized against key business drivers.
[A264] Develop IT Customer Transformation Proposal

Description
Transformation proposals (usually having a significant information technology constituent) are
taken from initial inception through consideration of initial business case and overview of how the
transformational content might be created.
This work will involve aspects such as:
Select and review the candidates based on business direction and imperatives
Build the proposal content in terms of what the innovation would be, how it would impact
the business operation (for example, by modeling business process changes), and an
outline of how it might be done
Develop ROI or other form of business case
Draft a program or project outline. Suggest schedule of (1) project timing, (2) benefit time
scales
Transformation proposals might need to be updated during the life cycle of approved development
projects in order to reflect changed circumstances and actual experience. In particular, experience
of preparing for and implementing transformational capabilities (for example, in a pilot rollout)
might indicate that adjustments or modifications are needed to achieve optimal benefit.
The nature of the proposal development work will depend on the relationship between the
customer and the IT service provider. In partnership cases, the customer might look to the IT
provider as the expert in business transformation modeling. In other cases, the customer might
require more minimal assistance; for example, to provide technical input.
Controls
IT Customer Transformation Themes and Evaluation Principles (From: A26 A263)
•
•
•
•

Inputs
IT Customer Transformation Candidates (From: A263)
A list of possible transformational opportunity areas for the customer. It will usually be
categorized against key business drivers.
undertakings.
IT Customer Capability Enabling Requirements (From: A265)
Statement of requirements for additional or modified materials, training, and communication
programs, and other enablers that enhance the rate and degree of adoption of
transformational capabilities.
Outputs
A formal statement of an idea being put forward for consideration that includes the business
case for the proposed IT investment.


•
•
•
•
[A265] Enable and Promote IT Customer Capability Adoption

Description
Work to prepare for and then directly support the adoption of changes to business processes,
whether technology-enabled or not, can begin as soon as a transformation proposal is accepted.
It might continue until the changes have become embedded within the customer's operations and
culture (this might be described as business-as-usual) and until such time as no further benefit
from further adoption is considered possible or a focus area.
This activity includes:
Identifying the required adoption support needs
Creating and managing a plan for business capability adoption. For example:
• The management of organization change
• Communication
• Training.
Performing and executing the plan
Providing, as needed, advice and guidance on business capability usage
Monitoring progress against key milestones
Revision of the adoption plan to reflect the learnings from existing benefit realization
assessments
Identification of modifications or extensions to the capability adoption requirements to
enhance capability adoption
Controls
contracts (UCs).
•
•
•
•
Inputs
Project Plan (From: A3 A37 A374)
The set of the work plans, plus other plans including management plan , human resource
plan , technical environment, project quality, communications management, and others.
A452)
timeframe.
IT Customer Capability Adoption Events
Notable milestones (both successes and failures) in the customer's adoption of
transformational capability.
Knowledge Assets (From: A85 A855)
Any information from knowledge management that fulfills a knowledge request.

•
•
•
•
Proposed IT Customer Capability Adoption Improvements (From: A266)
Suggestions for improvements (changes, extensions) to the existing adoption support
plan. This is based on lessons learned from existing adoption, and how well the mooted
benefits have been realized.
Outputs
Any actions or efforts designed to promote the adoption of transformational capabilities.
Examples of such interventions include:
• Communications
• Training programs
• General consultancy and assistance into better, deeper or broader usage of the
capability
IT Customer Capability Adoption Plan (To: A266)
programs customized to local needs and possibly the provision of individual guidance and
consultancy.
IT Customer Capability Enabling Requirements (To: A264)
Statement of requirements for additional or modified materials, training, and
communication programs, and other enablers that enhance the rate and degree of
adoption of transformational capabilities.
[A266] Optimize IT Customer Benefit Realization

Description
Tracking results to identify the actual business benefit achieved, and the assessment of benefit
versus plan to identify additional benefit potential; and remedial adoption support needed to close
benefit realization gaps.
The activity includes:
Measuring actual business benefits and reporting them
Identifying variances in benefits achieved versus planned
Diagnosing causes of benefit gaps
Identifying opportunities for benefit greater than planned
Proposing improvements to business capability adoption
•
•
•
•
Controls
IT Customer Capability Adoption Plan (From: A26 A265)
programs customized to local needs and possibly the provision of individual guidance and
consultancy.
Inputs
Business Metrics
Outputs
A312 A363)

•
•
•
•

Proposed IT Customer Capability Adoption Improvements (To: A265)
Suggestions for improvements (changes, extensions) to the existing adoption support plan.
This is based on lessons learned from existing adoption, and how well the mooted benefits
have been realized.
[A267] Evaluate IT Customer Transformation Management

Performance
Description
The evaluation of the performance of the process aims at identifying areas of the overall process
which require improvement. For example, the foundation and interfaces of the process, all
activities, their accomplishment, their degree of automation, as well as the roles and
responsibilities including the respective skills. The bases for the improvements are the insights and
the lessons learned from the observations and analysis of activity accomplishments and results.
Controls
Inputs
IT Customer Transformation Management Activity Data (From: A262 A263 A264 A265
A266)
Outputs
IT Customer Transformation Management Evaluation (To: A261)
•
•
•
•
Purpose
The purpose of the Customer Satisfaction Management process is to determine if customers are
satisfied, and the degree of their satisfaction with the services, solutions, and offerings from the
providers of IT. In addition to this determination, the process aims to proactively predict what the
customer satisfaction will be, and then to determine what must be done to maintain or, where
appropriate, enhance satisfaction and customer loyalty.
Definition of customer satisfaction: An expression of perceived actual service received versus
expected (committed) service.
Outcomes
Customer satisfaction and loyalty will be sustained and enhanced
Customer satisfaction can be measured and tracked
Early signs of customer dissatisfaction can be addressed and resolved before major issues
emerge
Causes of customer dissatisfaction are remedied
Scope
This process is active throughout the service life cycle. It begins at the first contact with a customer
as part of the effort to determine wants and needs, and continues through either creating a satisfied
customer or with the monitoring of remedial actions to correct any problems leading to customer
dissatisfaction. It encompasses the entirety of IT services, solutions and offerings (the IT service
catalog).
Includes
Identifying customer types and classes
Understanding:
– Customer expectations
– Customer perceptions
Analysis of the current services catalog
Ongoing identification of the key factors contributing to customer satisfaction and
loyalty or dissatisfaction
Development and maintenance of measurements of satisfaction and loyalty
Collection and analysis of such measurements
Planning, directing, and monitoring of efforts to remedy customer dissatisfaction, as
well as to increase satisfaction, on both a proactive and reactive basis
Communicating constraints and decision criteria agreed with customers transparently
to users
Excludes
Fulfillment of specific customer requirements (handled through Service Marketing and
Sales)Execution of specific corrective actions for resolving issues (any other process,
depending on the issue)
•
•
•
•
Ongoing activities for managing service agreements and service level attainment
(Service Level Management)
Controls
contracts (UCs).

•
•
•
•
included.
Inputs
activities.
receipt only.
Customer Satisfaction Input
Feedback (solicited or unsolicited) from customers regarding IT performance. This is used
to measure and manage customer satisfaction issues and trends.
Customer Issue Feedback
The responses and other feedback from the customer providing more information into the
issue they have expressed and into their perception on the success or otherwise of
attempts to address open issues.
Customer Satisfaction Issue (From: A24 A245 A53 A537 A61 A613 A615)
Outputs
Customer Output (To: Outside-the-Model A276)
The interactions from the collective IT endeavor to any IT customer which relate to the any
aspect of the lifecycle related to the establishment and performance of the IT product; that
•
•
•
•

Any information from problem resolution (proactively or reactively) that can help to improve
the overall service delivery. For example, there could be a finding that a specific service
part or component frequently generates problems and a determination that a modification
to the procedures used to operate the service would remove the incident-inducing
circumstances.
Customer Satisfaction Results and Trends (To: A13 A131 A14 A141 A22 A222 A23 A236
A24 A244 A25 A253 A356 A365 A525 A526)
Activities
IT Portfolio IT Management IT Strategy Service

SLAs OLAs UCs
Ecosystem Catalog
C5 C4 C1 C2
C3
I4
Customer
Organization
Establish
Customer Customer Satisfaction
Framework
I1 Satisfaction
Customer Management
Profiles Framework Customer
A271 Satisfaction
Data_
Customer Unsolicited
Satisfaction Capture
Targets Customer
I5
Customer
Satisfaction
Satisfaction DataA272 Customer
Input Satisfaction
Analysis
Customer Satisfaction Analyze O2
Data_ Solicited
I2 Customer Incident
Service Review Satisfaction
Results O1
A273
Product Performance Manage Issue Communications
Assessment/D1 Customer
I7 Customer Satisfaction
Customer
Satisfaction Issue Resolution
Satisfaction Issue Directives
Issue Resolution Customer
A274 Satisfaction
Assess Patterns
I6 Customer
Issue Feedback Patterns
Customer A275
Satisfaction Issue Communicate
Resolution Response
Customer O3
I3 Satisfaction Customer Satisfaction
Service Achievement Management Results and Trends
Reports ResultsA276
Marketing and
Sales Reports/D1
Evaluate
Customer Customer
Satisfaction Satisfaction
Management
Management Performance
Activity Data A277
NODE: A27 TITLE:

Customer Satisfaction Management CURRENT PAGE:
Figure 8. A27 Customer Satisfaction Management
•
•
•
•
[A271] Establish Customer Satisfaction Management Framework

Description
To establish the framework necessary to manage the Customer Satisfaction process, these
considerations should be addressed:
Policies, standards and guidelines must be created and used to identify customers and
customer segments for analysis
Intervals and approved methods specified for obtaining valid customer satisfaction data
Policies and direction provided for customer satisfaction issue identification and resolution
Guidance and direction on analysis methods and trend identification principles
Documented and accessible procedures for communicating customer satisfaction
assessment results
Finally, the structure and process for Customer Satisfaction Management have to be
communicated.
The establishment of the Customer Satisfaction Management Framework also includes the
continuous improvement of the process; that is, the regular review of process evaluations and the
implementation of recommended improvement actions.
Controls
included.
contracts (UCs).

•
•
•
•
Inputs
activities.
Customer Satisfaction Management Evaluation (From: A277)
Outputs
Customer Satisfaction Framework (To: A272 A273 A274 A275 A276 A277)
customer satisfaction.
Customer Satisfaction Targets (To: A273 A276 A277)
The targets (goals) for customer satisfaction against which the actual customer results will
be measured.

•
•
•
•
[A272] Capture Customer Satisfaction Data

Description
This activity receives, stores, and aggregates customer satisfaction data for further analysis. Such
data includes solicited or obtained through formal mechanisms, as well as any unsolicited
communications, received directly from customers, with regard to their satisfaction.
Controls
Customer Satisfaction Framework (From: A271)
Inputs
Customer Satisfaction Input
Feedback (solicited or unsolicited) from customers regarding IT performance. This is used
to measure and manage customer satisfaction issues and trends.
Outputs
Customer Satisfaction Data_ Unsolicited (To: A273 A275)
Any feedback, typically ad hoc and unprompted, from a customer that expresses their level
of satisfaction with any aspect of the IT service provision.
Customer Satisfaction Data_ Solicited (To: A273 A275)
Data obtained from service provider initiated collection of satisfaction data. Examples
would include forms put in front of users after system interactions, regular review meetings
between customer and provider.
Customer Satisfaction Management Activity Data (To: A277)
[A273] Analyze Customer Satisfaction

Description
This activity addresses the processing and assessment of customer satisfaction data in order to
identify:
Satisfaction results for the immediate reporting period
Trends in satisfaction attainment
Underlying issues not yet explicitly expressed by any customer
The results of this analysis might warrant immediate attention, in which case an Incident is created
Controls
Customer Satisfaction Targets (From: A271)
be measured.
•
•
•
•

contracts (UCs).
Inputs
Customer Satisfaction Data_ Unsolicited (From: A272)

•
•
•
•
Customer Satisfaction Data_ Solicited (From: A272)

Product Performance Assessment (From: A356)
A summary of the product's current level of achievement with regard to commitments made
in the product plan. Includes assessments of both quantitative and qualitative factors and
the overall value of the product.
receipt only.
Outputs
Customer Satisfaction Analysis (To: A274 A275 A276)
The results of analyzing customer satisfaction data, and including trends and implicit
issues.
•
•
•
•
[A274] Manage Customer Satisfaction Issue Resolution
[A274] Manage Customer Satisfaction Issue Resolution

Description
This activity formulates and coordinates IT actions to resolve customer dissatisfaction, and keeps
customers informed on the status of issue resolutions.
This activity also ensures appropriate notification and communications take place with IT
management and staff on issues and progress.
Controls
Inputs
Customer Satisfaction Analysis (From: A273)
issues.
Customer Satisfaction Issue (From: A24 A245 A53 A537 A61 A613 A615)
Customer Issue Feedback
The responses and other feedback from the customer providing more information into the
issue they have expressed and into their perception on the success or otherwise of
attempts to address open issues.
Customer Satisfaction Issue Resolution Response
Responses from any IT process to directives for the resolution of a customer satisfaction
issue. Examples of responses would be action plans, and action outcomes.
Outputs
Customer Satisfaction Issue Communications (To: A276 A614 A615)
Information provided to customers about any aspect of a satisfaction issue, covering
analysis of causes, committed plans to address, and progress to issue resolution.
Customer Satisfaction Issue Resolution Directives (To: A276)
Instructions or requests to any IT process for the resolution of a customer satisfaction
issue, under the coordination of an overall issue resolution plan.
•
•
•
•
[A275] Assess Customer Satisfaction Patterns
[A275] Assess Customer Satisfaction Patterns

Description
This activity performs additional in-depth investigation of satisfaction data, and derives trending
information in order to identify any underlying satisfaction patterns.
Both positive and negative patterns might be highlighted for subsequent communication.
Controls
Inputs
issues.
Customer Satisfaction Data_ Unsolicited (From: A272)
Customer Satisfaction Data_ Solicited (From: A272)
receipt only.
Outputs
Customer Satisfaction Patterns (To: A276)
Identification of patterns of satisfaction which might require attention from the IT service
provider before the dissatisfaction occurs.
•
•
•
•
[A276] Communicate Customer Satisfaction Management Results
[A276] Communicate Customer Satisfaction Management

Results
Description
This activity provides summary reports of:
Customer satisfaction attainment and trends
Current customer satisfaction issues, and any resolution plans associated with each
The reports will be used with both customers and IT management, perhaps with variations
depending on the recipients.
Controls
be measured.
Inputs
Customer Satisfaction Patterns (From: A275)
Identification of patterns of satisfaction which might require attention from the IT service
provider before the dissatisfaction occurs.
Customer Satisfaction Issue Communications (From: A27 A274)
Customer Satisfaction Issue Resolution Directives (From: A274)
Instructions or requests to any IT process for the resolution of a customer satisfaction
issue, under the coordination of an overall issue resolution plan.
issues.
Outputs
Customer Satisfaction Results and Trends (To: A13 A131 A14 A141 A22 A222 A23 A236
A24 A244 A25 A253 A356 A365 A525 A526)
•
•
•
•
[A277] Evaluate Customer Satisfaction Management Performance
[A277] Evaluate Customer Satisfaction Management

Performance
Description
The evaluation of process performance identifies areas that need improvement, such as the
foundation and interfaces of the process, activity definitions, key performance metrics, the state of
supporting automation, as well as the roles and responsibilities and skills required. Insights and
lessons learned from direct observation and data collected on process performance are the basis
for improvement recommendations.
Controls
be measured.
Inputs
Customer Satisfaction Management Activity Data (From: A272 A273 A274 A275 A276)
Outputs
Customer Satisfaction Management Evaluation (To: A271)
•
•
•
•
PRM-IT A2 Node Tree
PRM-IT A2 Node Tree
A2 – CUSTOMER RELATIONSHIPS
A213 Transform Needs Into Stakeholder Requirements
•
•
•
•
PRM-IT A2 Node Tree
Figure 9. A2 Customer Relationships Node Tree
•
•
•
•
PRM-IT A2 Node Tree
•
•
•
•
[A3] Direction
Description
Purpose
Architecture and IT Portfolio. Using the business strategy, related business requirements, and
the IT Portfolio and IT Architecture are planned, created, implemented, monitored, and
Portfolio are managed throughout their life cycle using product management approaches well
The IT portfolio includes all items managed to deliver the IT Strategy, including, but not limited to,
the services published to clients through the Service Catalog, internal services executed within the
the IT Strategy, such as development projects. Finally, risks to the IT organization, such as those
Rationale
Through a business aligned IT strategy, IT architecture and IT portfolio, this process category
Value
enhance consistency, reuse, and overall value across the range of capabilities, balancing
Optimizes the allocation of IT resources through Portfolio Management
predictability
Controls
•
•
•
•
Inputs
Business Strategy
Solution_ Deployed (From: A5 A53 A536)
Configuration Information (From: A5 A54 A544)
Project Proposal (From: A2 A22 A25 A255 A26 A264 A33 A5 A51 A515)
Solution Design (From: A4 A42 A425)
A452)
Outputs
IT Business Contribution and Capabilities
IT Strategy (To: outside the model A1 A11 A111 A112 A113 A114 A12 A121 A122 A123
A811 A82 A83 A831 A84 A841 A842 A85 A851 A852)
IT Portfolio (To: A1 A12 A122 A123 A124 A125 A126 A13 A131 A132 A133 A14 A142 A2
A366 A4 A42 A421 A8 A81 A811 A82 A822 A83 A831 A85 A852)
IT Plan (To: A2 A22 A221 A25 A254 A255 A26 A264 A265 A31 A314 A366 A4 A41 A411
A844)
Project Charter (To: A33 A333 A334 A37 A372 A373 A4 A41 A412 A414)
Business and IT Models (To: A2 A25 A253 A254 A32 A322 A323 A334 A34 A342 A344
IT Research Guidance (To: A1 A11 A114 A12 A122 A123 A124 A125 A126 A2 A21 A213
A22 A222 A25 A252 A26 A263 A31 A313 A33 A332 A333 A8 A84 A844)
Project Plan (To: A265 A34 A343 A344 A372 A375 A376 A377 A4 A41 A412 A5 A51 A514
A52 A522 A53 A532)
•
•
•
•
Architecture Baselines and Roadmaps (To: A1 A11 A114 A12 A121 A122 A123 A124 A125
A844 A85 A852)
Product Package (To: A2 A23 A24 A243 A5 A52 A522)
Processes
A31 IT Strategy
A34 Risk Management
Environment IT Management Underpinning Security Policy Market Analysis SLAs OLAs UCs Compliance Plans
Contracts IT Budget
Information Ecosystem C7 C2 and Controls
Technology C4 C6 C5 C1 IT Service Provider
C3 C8
Capabilities Value Profile
and Trends
I2 O1
Business IT Business
Strategy IT Strategy
IT Capability IT Business Value Contribution and
Initiatives
Outlines Potential Capabilities
IT Strategy
O2
IT Strategy
A31 Industry Models

and Standards
Security IT Research
IT Research Viable
Plan/D2 Requests and Innovation
Innovation O8
I9 A32 IT Research
Solution_ Guidance
Deployed
I7
Service Resilience Architecture O7
Plans Management Business and
IT Models
I12
Solution Design
A33 Risk Assessment O10
and Mitigation Plans Architecture Baselines
I13 and Roadmaps
Solution IT Strategy Risk
Plans and O5
Architectural Implications Management Change
Commitments
Request
I10 Business
Configuration Risk Posture
Information A34 O11
Product Package
I11 Product
Project Proposal Management
I4 O3
Service Level Package IT Portfolio
A35 IT Business
Value Report
O6
Product Proposal
I8 Portfolio Project Charter
Change Management
Information
I6 O4
Program IT Plan
IT Financial A36
Reports Charter
Program Program
I1 Plan
Service Portfolio Decision and IT Portfolio
and Project
O9
Catalog Resource Allocation Performance Report Management Project Plan
I3
Stakeholder A37
Business
Requirements Project
I5 Management
Business Program and
Framework
Input Project Reports
NODE: A3 TITLE:
Direction CURRENT PAGE:
Figure 1. A3 Direction Diagram
•
•
•
•
[A31] IT Strategy
[A31] IT Strategy
Purpose
The purpose of the IT Strategy process is to set the direction for the outcomes to be achieved by
the use of information technology, ensuring that it supports the business and business strategy to
the level desired and funded.
It exists “To set the goals, and decide on areas of change,”1 for IT capability to support the
business strategy.
Definition of an IT Strategy: The collection of goals, policies, and plans that specify how an IT
organization should function over a specific period.
Outcomes
As a result of successful implementation of the IT Strategy process:
The business has an understanding and appreciation of the potential value of information
technology to the business. Examples are’s role in providing the business with the
capability to achieve competitive advantage, and ensuring the ability to readily respond to
changes in the business environment
All aspects of information technology strategy (such as infrastructure, applications and
services) are aligned with the business strategy, and regularly examined to maintain that
alignment
Information technology strategy is cost effective, appropriate, realistic, achievable,
business-focused, balanced, and timely
Clear and concrete short term goals (which are then to be translated into operational plans)
can be derived from and are traceable back to specific long term plans.
Scope
The IT strategy should address long and short-term objectives, business direction and its impact
on IT, the IT culture, communications, information, people, processes, technology, development,
and partnerships.
Includes
Interacting with business strategy
Setting strategic goals for IT
Creating overarching guidance for specific IT functional areas
Understanding the value, both the overall classes and the specific targets, which the
business requires IT to provide or support
Generating preliminary value propositions for the actual and proposed IT contributions
to the business
Excludes
The creation of the first level of plans to realize the strategy (Portfolio Management,
Product Management)
1. Source: IBM Academy of Technology Study AR221 (2004), “Enterprise Architecture in the era of on demand”.
Definition of strategy.
•
•
•
•
[A31] IT Strategy
The creation, recommendation, and adoption of IT architectures for the next layers of
detail, like hardware and software (Architecture Management)
Adjusting the way that the IT undertaking organizes and runs itself to realize the
strategy (IT Governance and Management System category of processes)
Controls
Technology Capabilities and Trends
Available external data, both uncoordinated and already analyzed, of world class IT
technologies available, declining, and emerging.
an SLA.”2
Inputs
Business Strategy
policies.
2. ITIL V3 Glossary
•
•
•
•
[A31] IT Strategy

IT Portfolio Performance Report (From: A36 A367)
A management report describing the actual results of IT portfolio management activities in
terms of value realized, balance achieved, and degree of strategic alignment.
IT Strategy Architectural Implications (From: A33 A333)
An assessment of the implications of architecture changes on the IT Strategy; stated in
terms of potential (positive and negative) changes to the value of IT and its alignment to
desired business capabilities. For example, it can detail the potential need for compromise
on two conflicting aspects of the strategy; only one (or other) of which can be satisfied by
the architecture.
Viable Innovation (From: A32 A325)
Any innovations that seem viable to be adopted by the IT service provider in order to
enhance the service to the business (IT Architecture, the IT Portfolio, IT Strategy). The
information provided will include analysis and assessment of the potential impact to the
business, and to the parameters of the IT service provision, stated in terms of ideas, value
and viability.
Outputs
IT Service Provider Value Profile (To: A11 A112 A113 A314)
A811 A82 A83 A831 A84 A841 A842 A85 A851 A852)
included.
IT Capability Outlines (To: A314 A33 A332)
A specification of the desired capabilities of the IT entity, stated in a way that is
independent to specific implementations of its services, processes, people, tools,
organization, and technology. Capabilities should be stated in a consistent form, as in “the
ability to perform service X within the specified service level Y.”
•
•
•
•
[A31] IT Strategy
IT Business Value Potential (To: A312)

Statement of potential technology impact on the business strategy, stated in terms of added
value, time scales, potential investment costs and business change assessment.
IT Strategy Initiatives (To: A315 A33 A333 A35 A352 A36 A364)
An outline charter for each strategic IT initiative, stated in terms of scope of change,
stakeholders, benefits, time scales and costs. The scope of change is stated in terms of
changes to the architecture baseline.
IT Research Requests (To: A32 A322)
Requests from within the business or from any other IT process that trigger the
identification and selection of research candidates.
Activities
IT Management Technology Underpinning IT Budget Security Policy

Market Analysis
Ecosystem Capabilities Contracts C6
C4 C5
C2 and Trends C3
C1
Establish IT
Process Process Framework
I1 Framework
Business A311 Business Strategic
Strategy Wants and Needs
O6
IT Research
Understand Requests
IT Customer Business
Transformation Themes O1
and Evaluation Principles/D1
Strategy IT Service Provider
A312 Business Aligned Value Profile
IT Goals O4
IT Business Value
Determine IT Potential
I8
IT Research
Strategic
Guidance Potential
O3
I6 A313 IT Capability
IT Strategy Outlines
Architectural Implications
Develop IT O5
I5 Strategy
Architecture Baselines IT Strategy
and Roadmaps Initiatives Initiatives
A314
I2
Strategic IT Value Consolidate
IT Portfolio
Propositions O2
and
IT Strategy
Communicate
I3 IT Strategy
A315
IT Plan IT Strategy
I7 Assessment
Viable Monitor and
Innovation Assess IT
Strategy
Effectiveness
A316
Evaluate IT
Process
Process Evaluation
I4 IT Strategy Process Performance
IT Portfolio Activity Data A317
Performance Report
NODE: A31 TITLE:

IT Strategy CURRENT PAGE:
Figure 2. A31 IT Strategy
•
•
•
•
[A31] IT Strategy
[A311] Establish IT Strategy Process Framework
[A311] Establish IT Strategy Process Framework

Description
Define and maintain a framework of policies and procedures that guides and governs the behavior
of the IT Strategy processes. Incorporate mandatory elements from the IT Management
Ecosystem.
Define a set of metrics to be used by each process for measurement and reporting of performance.
Review process evaluations based on analysis of current performance, and approve
recommendations for improvements. Refine the metrics to drive vitality and cost take out.
Incorporate updated metrics and process change recommendations into the framework and
communicate the changes.
Controls
Inputs
IT Strategy Process Evaluation (From: A317)
Quantitative and qualitative analysis of the performance of the IT Strategy processes
against the evaluation framework. Incorporates recommendations for changes to the
framework and changes to the metrics.
Outputs
IT Strategy Process Framework (To: A312 A313 A314 A315 A316 A317)
A specification of the framework and metrics for measuring and managing the IT Strategy
processes and incorporating any mandated elements required by the overall IT
management system. Incorporates governance, reporting, standards, methods and review
criteria.
•
•
•
•
[A31] IT Strategy
[A312] Understand Business Strategy
[A312] Understand Business Strategy

Description
Develop and maintain an understanding of the business strategy. Analyze the business strategy
and establish the financial implications in quantifiable terms that can be used to develop financial
benefits for IT related changes. Compare the potential value of IT with the business objectives and
incorporate this insight into a specification of the wants and needs of the business.
Establish priorities for change.
Agree to the understanding and insight with key business stakeholders.
Communicate the strategic wants and needs of the business.
Watch for business strategy changes and evaluate their implications on the IT strategy. Changes
can arise for a variety of reasons, ranging from mergers and acquisitions, through disruptive
changes to the value chain, to legislation or technology change.
Controls
IT Strategy Process Framework (From: A311)
criteria.
Inputs
Business Strategy
policies.
IT Business Value Potential (From: A31 A313)
Outputs
Business Strategic Wants and Needs (To: A313)
Statement of strategic ambition, objectives, priorities and intent of the business.
IT Strategy Process Activity Data (To: A317)
•
•
•
•
[A31] IT Strategy
[A313] Determine IT Strategic Potential

Description
Develop and maintain a model of IT capabilities. Associate the capability model with the
architecture baseline, service catalog, and associated cost metrics.
Determine the fit or gap between current IT capabilities and the strategic wants and needs of the
business.
Determine the fit or gap between current IT capabilities and market analysis of world class and
emerging IT service provision.
Identify new opportunities presented by emerging technologies. Identify threats of declining
technologies.
Assess the impact on IT capabilities of architecture changes, IT research, IT portfolio performance
and IT strategy effectiveness.
Analyze the financial and business implications of the business strategy, opportunities and threats
and develop a value analysis of potential changes to the IT capabilities. Select cost effective
opportunities and refine the IT capability model. Prepare value statements for the potential value
of IT, in a form appropriate for the business, and also a form appropriate for a service provider (to
support external benchmarking and sales).
Document the IT goals, required IT capabilities and potential IT value, showing alignment of IT to
the business.
Controls
criteria.
an SLA.”3
3. ITIL V3 Glossary
•
•
•
•
[A31] IT Strategy
IT Strategy Assessment (From: A316)

Assessment of the effectiveness of the IT Strategy, stated in terms of completeness and
coverage of IT strategy implementation (when compared to the strategic intent). Includes
lessons learned about the strategy initiatives and recommendations for change.
Inputs
Business Strategic Wants and Needs (From: A312)
Statement of strategic ambition, objectives, priorities and intent of the business.
IT Strategy Architectural Implications (From: A33 A333)
the architecture.
Outputs
IT Service Provider Value Profile (To: A11 A112 A113 A314)
IT Business Value Potential (To: A312)
Business Aligned IT Goals (To: A314 A315)
Statement of IT goals and objectives. Includes coverage of guiding principles, policies,
strategic assumptions, and technology principles.
IT Capability Outlines (To: A314 A33 A332)
•
•
•
•
[A31] IT Strategy

[A314] Develop IT Strategy Initiatives

Description
Develop and maintain a list of strategic IT initiatives, based on the strategic potential of IT.
Evaluate the current IT portfolio, service catalog and IT plan to ensure alignment with the IT
capabilities. Use the fit and gap analysis to identify additions or changes to the IT initiatives.
Evaluate the current architecture and innovation opportunities to identify new initiatives or improve
existing initiatives.
Refine the strategic IT initiatives to take into account cost constraints and IT strategy effectiveness.
Develop an outline charter for each IT strategy initiative, showing scope of change and
incorporating estimates for time and cost. Develop an overall value statement for the strategic IT
initiatives.
Obtain business and IT approvals, and secure necessary changes to IT budgets.
Controls
Business Aligned IT Goals (From: A313)
criteria.
•
•
•
•
[A31] IT Strategy
Inputs
IT Capability Outlines (From: A31 A313)
and viability.
Outputs
IT Strategy Initiatives (To: A315 A33 A333 A35 A352 A36 A364)
Strategic IT Value Propositions (To: A315)
A statement of value, scope and time scale for each strategic IT initiative.
•
•
•
•
[A31] IT Strategy
[A315] Consolidate and Communicate IT Strategy
[A315] Consolidate and Communicate IT Strategy

Description
Develop and maintain a network for championing the IT strategy.
Assemble a communications package based on the content and value of the strategic IT initiatives.
Identify events for communicating the strategy and obtain agreement from stakeholders to
participate at their events. Identify other means, such as Web lectures and the enterprise Internet,
for communicating the IT strategy.
Prepare a tailored communications package for each delivery vehicle and communicate the
strategy. Obtain and summarize feedback.
Controls
criteria.
Inputs
Business Aligned IT Goals (From: A313)
IT Strategy Initiatives (From: A31 A314)
Strategic IT Value Propositions (From: A314)
A statement of value, scope and time scale for each strategic IT initiative.
Outputs
A811 A82 A83 A831 A84 A841 A842 A85 A851 A852)
included.
•
•
•
•
[A31] IT Strategy
[A316] Monitor and Assess IT Strategy Effectiveness
[A316] Monitor and Assess IT Strategy Effectiveness

Description
Develop assessment criteria for effectiveness of IT, taking into account IT strategy assessment
framework.
Perform regular assessments of IT portfolio performance, comparing effectiveness of the portfolio
against the desired outcome of the IT strategy. Prepare an assessment report and recommend
changes to the strategy.
Measure process performance and create process activity data. Incorporate strategy effectiveness
criteria and assessment metrics into the performance results.
Controls
included.
criteria.
Inputs
Outputs
IT Strategy Assessment (To: A313 A314 A315)
•
•
•
•
[A31] IT Strategy
[A317] Evaluate IT Strategy Process Performance

Description
Develop a dashboard or model for analyzing and reporting on the performance of the IT Strategy
processes. Incorporate the IT Strategy process framework metrics into the model.
Using process activity data, evaluate the results of IT Strategy process performance and
incorporate into the dashboard. Assess performance of each process and also of the overall IT
Strategy process. Identify potential for process improvement. Recommend changes to processes
and process metrics baselines.
Controls
criteria.
Inputs
IT Strategy Process Activity Data (From: A312 A313 A314 A315 A316)
Outputs
IT Strategy Process Evaluation (To: A311)
Quantitative and qualitative analysis of the performance of the IT Strategy processes
against the evaluation framework. Incorporates recommendations for changes to the
framework and changes to the metrics.
•
•
•
•
Purpose
The IT Research and Innovation process exists to identify new developments in technology,
methods and solutions that have potential to create business value. It conducts research on the
applicability and benefit of new approaches and technologies, and promotes the use of viable,
innovative concepts in support of business objectives.
General definitions of:
Research: (Noun) Scholarly or scientific investigation or inquiry (Verb) To study something
thoroughly to present it in a detailed, accurate manner
Innovation:
1.The act of introducing new things or methods
2.Innovation = creative idea + implementation
Outcomes
The business is fully aware of marketplace, industry and technology trends, and the
potential impact of these forces
Business value is created through the qualification and staging of the most appropriate
advances and innovations in technology, methods and solutions
Business objectives are met with improved quality and reduced cost as a result of the
identification and promotion of viable innovative solutions for operational usage
Scope
The process covers any selected combination of internal, external and cooperative efforts in any
part of the range of research and innovation activities.
Includes
Identification of areas or fields to be researched
Responding to research requests and identifying relevant developments within
monitored fields of interest
Monitoring, understanding, and promoting:
– Market and industry trends
– Emerging technologies
– Technology-enabled solutions
– Methods and techniques for exploiting technology and solutions
– Solution strategies
– Organizing the storage and retrieval of research results
Excludes
Decisions on adopting innovative technologies and solutions for productive use
Actual development and deployment of solutions for productive use (Realization and
Transition processes)
•
•
•
•
Project Management (Program and Project Management)
Controls
included.
Business Strategy
policies.
Inputs
IT Research Requests (From: A31 A313 A33 A332 A333)
Outputs
Viable Innovation (To: A31 A314 A35 A352 A36 A364)
and viability.
A22 A222 A25 A252 A26 A263 A31 A313 A33 A332 A333 A8 A84 A844)
•
•
•
•
Activities
A321 Establish IT Research and Innovation Framework
A323 Qualify Candidates and Define IT Research and Innovation Projects
IT Management IT Budget Business IT Strategy IT Portfolio

Ecosystem C4 Strategy C1 C5
C3 C2
Establish IT
Research and IT Research and
Innovation Innovation Framework
Framework IT Research and
A321
Innovation Candidates
I2 Identify IT
IT Research Research and
Requests Innovation
IT Research
Candidates Project
A322 Charter
I3
Technology Request for
Capabilities Qualify IT Research
and Trends Candidates Capabilities
and Define IT
Research and
IT Research
I1 Innovation and Innovation
Business and ProjectsA323 Project Results
IT Models IT Research
Capabilities Perform IT Project Charter/S2
I4 Research and
Solution_ Innovation
Deployed
Project O2
A324
IT Research
Program and Guidance
Project Reports/D3
IT Research and
Rejected IT Research Promote IT
and Innovation Candidates Research and
Innovation Watch List
Innovation O1
Viable
Results Innovation
A325
Evaluate IT
Research and IT Research
Innovation and Innovation
Evaluation
IT Research and Innovation Performance
Activity Data A326
NODE: A32 TITLE:

IT Research and Innovation CURRENT PAGE:
Figure 3. A32 IT Research and Innovation
•
•
•
•
[A321] Establish IT Research and Innovation Framework
[A321] Establish IT Research and Innovation Framework

Description
Based on the business’ strategic goals, policies, and the IT strategy, this activity establishes the
base for IT research and innovation in the business by defining the research strategic goals and
objectives, as well as the critical success factors.
This includes that some policies are defined and orientation is given about securing research
results, about what kind of research is necessary and appropriate, which external sources can be
used, what criteria have to be applied for funding research projects, and more. These tasks have
to be revisited regularly.
The establishment of the IT research and innovation framework also includes the consideration of
the IT Research and Innovation process evaluation and the implementation of recommended
Controls
included.
Business Strategy
policies.
Inputs
IT Research and Innovation Evaluation (From: A326)
An analysis of IT research and innovation activity data providing an understanding of the
improvements.
Outputs
IT Research and Innovation Framework (To: A322 A323 A324 A325 A326)
The procedural, organizational and other management mechanisms through which the
process will operate. Includes:
• Strategic goals for IT research and innovation
• Policies and orientation that apply to IT research and innovation
• Collection of evaluation criteria for qualifying and selecting research projects
•
•
•
•
[A322] Identify IT Research and Innovation Candidates

Description
The basis for any research and innovation activities is thorough understanding of business and IT
strategies, models, and the IT services that have to be delivered. The first task in this activity
facilitates understanding beginning with the service enablers (technology, processes,
organization).
The actual identification of research areas can be of a proactive or reactive mode:
Triggered by a research request from within the business or any other process within IT
(reactive mode). These research requests are accepted if the research topic relates to the
service enablers.
Regular market and competitors watch: proactive mode, based on the watch list (approved
in the Qualify Candidates and Define Research Projects activity).
Analysis of current IT trends: best practices, innovations, emerging and new technologies,
among others (proactive mode, candidates for the watch list).
The result of this activity will be the suggestions for the right research areas, suggestions for a
watch list of potentially important technologies, and the identification of starting points for
innovation.
Based on this research, candidates will be identified and preselected.
Controls
IT Research and Innovation Framework (From: A321)
Inputs
IT Research Requests (From: A31 A313 A33 A332 A333)
IT Research and Innovation Watch List (From: A323 A324)
List of research topics not leading to a research project but are potential candidates; their
future development needs to be watched.
•
•
•
•
Outputs
IT Research and Innovation Candidates (To: A323)
Any topics that have been identified as potential candidates for research projects or the
watch list.
IT Research and Innovation Activity Data (To: A326)
Any data about the accomplishment of process activities that supports the evaluation of the
overall IT Research and Innovation process. For example, data about how much value the
research results bring to the business.
[A323] Qualify Candidates and Define IT Research and

Innovation Projects
Description
During this activity a prioritized and approved list of research projects is created based on the
identified research topics and suggested research candidates from the Identify Research and
Innovation Candidates activity.
The activity consists of these tasks:
Investigate and evaluate identified research topics and suggested research candidates with
regard to predefined evaluation criteria (see “[A321] Establish IT Research and Innovation
Framework” on page 43).
Decide on research candidates based on the evaluation results. For example:
• Adopt research topics: select and define research projects on a high level
• Approve research topics for the watch list
• Eliminate candidates from research
Prioritize adopted research projects
Define research project scope, objectives, and approach in detail
Obtain funding for research projects and request or allocate resources
Controls
Business Strategy
policies.
included.
•
•
•
•
Inputs
IT Research and Innovation Candidates (From: A322)
Any topics that have been identified as potential candidates for research projects or the
watch list.
Outputs
Request for IT Research Capabilities
Request for capabilities and resources needed to carry out a research project. Examples
include request for human resources, request to procure items, request to develop
solutions as support for the research project, and more.
IT Research Project Charter (To: A324 A325)
Description for research projects containing the following for each research project:
• Rationale for research project including evaluation results for project according to the
evaluation criteria
• Detailed definition of scope
• Project objectives
• Project approach
Rejected IT Research and Innovation Candidates (To: A325)
Research candidates that are not chosen to become research projects or part of the watch
list.
IT Research and Innovation Watch List (To: A322 A325)
[A324] Perform IT Research and Innovation Project

Description
Performing research projects consists of tasks according to the respective research project
objectives and scope:
Organizing and collecting research information
If applicable, developing and executing a prototype according to the research topic (proof of
concept)
Assessing and evaluating research information and prototype
Drawing conclusions and formulating propositions for innovation or changes, nonviable
concepts or new candidates for the watch list according to the research results
•
•
•
•
Controls
IT Research Project Charter (From: A323)
evaluation criteria
Inputs
IT Research Capabilities
Capabilities and resources that are needed to carry out a research project.
Outputs
A document issued by or created on behalf of the sponsor to describe the project's
IT Research and Innovation Project Results (To: A325)
The outcomes of performing research and innovation projects. They will range from the
base facts (data) through findings to conclusions about the feasibility and viability of each
candidate item.
IT Research and Innovation Watch List (To: A322 A325)
•
•
•
•
[A325] Promote IT Research and Innovation Results

Description
This activity contains the promotion of all research results:
For completed research projects, the documented research results including guidance and
recommendations for trends and innovations that should be adopted have to be reported
and further distributed so that decisions about future actions can be taken.
Rejected research projects have to be communicated.
Research topics that are not yet carried out in the form of a research project, but that will be
posted to the watch list of research topics, have to be communicated too.
Controls
IT Research Project Charter (From: A323)
evaluation criteria
Inputs
IT Research and Innovation Project Results (From: A324)
The outcomes of performing research and innovation projects. They will range from the
base facts (data) through findings to conclusions about the feasibility and viability of each
candidate item.
Rejected IT Research and Innovation Candidates (From: A323)
Research candidates that are not chosen to become research projects or part of the watch
list.
IT Research and Innovation Watch List (From: A323 A324)
Outputs
A22 A222 A25 A252 A26 A263 A31 A313 A33 A332 A333 A8 A84 A844)
Viable Innovation (To: A31 A314 A35 A352 A36 A364)
•
•
•
•
and viability.
[A326] Evaluate IT Research and Innovation Performance

Description
The evaluation of the performance of the IT Research and Innovation process aims at the
improvement of the overall process. That is, the foundation and interfaces of the process, all
responsibilities including the respective skills. Additionally, the evaluation aims at the overall
performance and results of research itself.
The basis for the improvements is insights and lessons learned from the observations and analysis
Basically, the improvements should lead to more efficiency in the process, and provide more useful
and valuable research results.
Controls
Inputs
IT Research and Innovation Activity Data (From: A322 A323 A324 A325)
Outputs
IT Research and Innovation Evaluation (To: A321)
An analysis of IT research and innovation activity data providing an understanding of the
improvements.
•
•
•
•
Purpose
The Architecture Management process exists to create, maintain, promote and govern the use of
IT architecture models and standards, across and within business change programs. IT
Architecture thus helps the stakeholder community coordinate and control their IT related activities,
in pursuit of common business goals.
Definition of IT architecture: “An overarching set of rules of construction, suitable for a defined
range of external circumstances. Usually includes a definition of the parts permitted for use in the
design, together with a specification of how the parts can be used within specific implementations
and the range of values for which the part is valid.”4
Outcomes
From the boardroom to the desktop, all elements of business and IT solutions receive
governance and guidance that has enhanced flexibility, consistency, integration, and reuse
All information systems and information technology infrastructure exhibit improved
manageability characteristics
The exploitation of IT across the enterprise is effective and efficient
Scope
An effective enterprise architecture (EA) should encompass:
An architecture
• This is the way our projects should be engineered.
• An EA provides a specification of the business and IT architecture models that must be
adopted by change programs and projects. This includes the overall business,
application, data, services, infrastructure architectures, and together with the principles
and guidelines needed to ensure these models are exploited properly.
Governance
• An EA must be flexible and evolve constantly if it is to support the business changes
needed by an organization wanting to innovate and transform itself. Architectural
governance has two aspects: ensuring that the architecture's specifications are adhered
to (or formal exceptions granted), and ensuring that the architecture evolves in step with
business demands.
Transition Planning
• These are the projects we should do and this is their scope.
• An EA needs a collection of processes and tasks designed to support the selection and
scoping of the right projects aimed at realizing the EA vision. The processes should be in
concert with the business-as-usual business and IT project prioritization planning
processes.
Includes
Business Architecture (BA)
4. Source: IBM Academy of Technology Study AR221 (2004), “Enterprise Architecture in the era of on demand,”
page 15.
•
•
•
•
– The relationships and interactions between the various business units, at

appropriate levels of decomposition
Information Systems (IS) Architecture
– The business-dependent aspects of IT; the automated parts of BA
Information Technology (IT) Architecture
– The business-independent aspect of IT; the underlying IT infrastructure
The architecture must consistently support several viewpoints across these three areas:
The applications viewpoint ensuring functionality can track through the layers. For
example, enabling an architect to link business activities and processes to
applications and transaction management services
The data viewpoint – ensuring an architect approach to information. For example,
linking business entities to data definitions and into database technologies
User viewpoint – facilitating the identification and support of an enterprise's user
groups (whether internal or external, private or corporate), including the definition of
how they are to be supported at the IS (user interface) and IT (interface technology)
levels
The architecture must be:
Maintained – An enterprise needs to keep its architecture fresh and vital, reacting to
changes in the businesses strategy as well as changes in technology through a vitality
process. In all probability, this will include the identification of new or changes to
existing standards through a selection process
Used and controlled – It is necessary to actively ensure that solution projects conform
to the constraints of the architecture (while still assuring their ability to meet the
project's business requirements) through a conformance process. Inevitably, there will
be occasions when there is a conflict between the project's needs and the
architecture, requiring an exception process
Communicated – To be effective, the architecture must be understood by those who
are required to use it, through the use of a communication process
Excludes
Portfolio Management, in which specific change programs are identified, prioritized,
and managed to completion
Requirements specification, in which specific business requirements are identified and
translated into specifications (Solution Requirements)
Solution design, in which specific IT systems are designed to meet particular business
or IT operational needs
Solution delivery and operation, including the procurement, commissioning and
operation of IT components and systems
Enterprise systems management, responsible for planning and execution of day-to-
day management of the installed IT infrastructure
Controls
Security Plan (From: A72 A725)
A consolidated view and documentation of the resources, approach, procedures and
assets to be protected together with a definition of the security practices and controls which
will be enacted in order to fulfill the security policy. It covers both technical capabilities (for
•
•
•
•
example, firewalls, encryption) and non-technical considerations (such as segregation of

duties, training needs, user responsibilities).
Industry Models and Standards
From the industry segment of the business and from the IT industry itself:
• Models of ways of operating and design
• Formal and informal standards that must be considered in any architectural work
Inputs
included.
Business Strategy
policies.
•
•
•
•

A452)
timeframe.
Business Input (From: Outside-the-Model)
• Guidance
• Instructions
Project Charter (From: A3 A324 A354 A36 A365)
Outputs
A844 A85 A852)
IT Strategy Architectural Implications (To: A31 A313)
the architecture.
•
•
•
•

Activities
IT Management IT Budget IT Portfolio Industry Models Security Policy Security

Ecosystem C2 and Standards C5 Plan/D2
Security C6 C1
C4 C3
Management
Framework/D4
I1
IT Strategy
Establish
Architecture Architecture Management
I10 Framework
Business A331
Input
Review O5
Overall IT Research
I6 Environment Requests
Business
Strategy and Architecture
Architecture Need
A332
I2 Architecture_
IT Capability Current State
Outlines Create and
Maintain O4
I4 IT Strategy
IT Research Architecture Architectural Implications
Guidance Models A333 O1
I3
Business and
IT Strategy
Initiatives
Architecture_ Define and IT Models
Future Maintain O3
I5 Architecture Architecture Baselines
Technology
Baselines and and Roadmaps
Capabilities
and Trends Roadmaps
A334 Architecture
Transition
I11 Promote Initiatives
Project Charter Architecture O2
Project Proposal
Transition
Security Directives/D1 Initiatives
A335
Business and IT Models
Update Package/D1 Govern Configuration
Information Request/S2
Architecture
I7
Solution Design
Usage
A336 Architecture
Compliance Decision
I8 Architecture_
Solution Exception
Evaluate
Plans and Architecture Architecture
Commitments Management
I9 Activity Data Performance
Configuration A337
Information
NODE: A33 TITLE:

Architecture Management CURRENT PAGE:
Figure 4. A33 Architecture Management
•
•
•
•
[A331] Establish Architecture Management Framework

Description
This activity puts in place an Architecture Management Framework (AMF), and continuously
maintains its fitness for purpose.
While primarily addressing the ways and means in which the Architecture Management process
itself will operate, an AMF also ensures the architecture is maintained and actively and
appropriately used by the enterprise's change programs. It includes an organizational structure,
documenting the responsibilities of various governance bodies; together with a set of processes
used by these bodies to ensure the health and usage of the architecture.
The AMF can take many forms, often dependant on the overarching organizational structure and
culture of the business. For example, it might be appropriate to adopt a strongly controlled
approach within a centralized corporate culture, or a federated, trust based approach within a
federated enterprise. In general, it is necessary for the AMF to be active, rather than passive. For
example: ensuring conformance reviews are scheduled and held, and actively communicating the
architecture to its stakeholders and users.
There are two distinct objectives for the AMF:
Managing the architecture itself
Managing the use of the architecture
The first requires a focus on its vitality (executed in activity Review Overall Environment and
Architecture) and communication. The second focuses on conformance to the architecture, and
managing exceptions (executed in Govern Architecture Usage).
Controls
Inputs
Security Management Framework (From: A721)
security.
•
•
•
•
Architecture Management Evaluation (From: A337)

Assessment of the effectiveness and efficiency of the architecture management process.
Includes identification of areas for process improvement.
Outputs
Architecture Management Framework (To: A332 A333 A334 A335 A336 A337)
The organizational structure and processes deployed to ensure the architecture is
effectively and efficiently established, maintained and used.
[A332] Review Overall Environment and Architecture

Description
Establishing the gap between the business' existing IT environment and planned architecture
vision (if one exists), and the combined business and IT strategies.
This vitality activity can also be influenced by the practical experiences of the programs' ability to
conform to the existing architecture. For example, if an unexpected number of development
programs are unable to conform to the architecture, then it might be that the architecture requires
refinement.
Controls
Architecture Management Framework (From: A331)
Inputs
included.
• Guidance
•
•
•
•
• Instructions
Business Strategy
policies.
Architecture_ Exception (From: A336)
An allowed deviation within a solution design from the architecture, providing input to the
collection of architecture processes which ensure vitality.
Outputs
Architecture Need (To: A333)
An identified shortfall in the existing (or envisioned) IT environment that can be addressed
by some architectural instrument.
Architecture_ Current State (To: A335 A336)
A description of the business' overall approach to the structuring and implementation of its
IT systems and solutions.
Architecture Management Activity Data (To: A337)
Metrics on the performance of the architecture management processes, such as the
frequency or magnitude of allowed exceptions, enabling the effectiveness of the process to
be determined.
[A333] Create and Maintain Architecture Models

Description
This activity addresses the identification, description, and publication of the business' preferred
approaches to the design of its IT systems and solutions. A prerequisite to this is the existence of
an adequate representation of the business undertaking for which a technology-enabled approach
is being examined. Where necessary, this activity participates in business-owned efforts to provide
such business models.
Architecture is often formulated within a standard architecture framework, intended to ensure the
support of all aspects of the IT systems and solution design. There are many available frameworks
(those available from The Open Group (TOGAF), FEAF, and IBM), all of which attempt to embrace
a number of factors:
1. Business dependent and business independent IT building blocks (BBs) – sometimes
referred to as an IS Architecture and IT Architecture, respectively. These BBs are specified
to be the preferred BBs for use throughout the IT organization. Business dependent BBs
will, for example, include a preferred application architecture, data architecture, and
standard approaches for user support. Business independent IT BBs focus on
•
•
•
•
documenting standard IT software and hardware components, upon which the IS

architecture will be supported.
2. Standard constructions of BBs – as well as a simple catalog of parts, the architecture will
provide standard patterns, documenting how the BBs are to be put together in order to
solve common IT design challenges.
3. Other guidance, such as architecture principles, that provides additional insights and
controls in the use of the architecture.
Good practice suggests that this activity focuses on the specification of the preferred BBs and
patterns for their use in design. A separate activity is responsible for the identification of preferred
implementations of these BBs and patterns, including guidance on when and how to choose
between different permitted implementations of the same BB.
Controls
Inputs
Architecture Need (From: A332)
An identified shortfall in the existing (or envisioned) IT environment that can be addressed
by some architectural instrument.
Business Strategy
policies.
•
•
•
•

Security Directives (From: A725)
The directive to take action, or the action to be taken, so that the protections which
implement the desired security practices are properly operated.
Outputs
IT Strategy Architectural Implications (To: A31 A313)
the architecture.
Architecture_ Future (To: A334 A335 A336)
A structured description of the preferred business approaches to the design and
implementation of its IT systems and solutions. Generally published as a specification of
architecture building blocks, together with recommended standard constructions of those
building blocks.
be determined.
[A334] Define and Maintain Architecture Baselines and

Roadmaps
Description
An architecture baseline is a complete statement of the required architecture (in terms of its
specification and permitted implementations) as defined at a given moment in time.
There can, therefore, be any number of architecture baselines. For example, a long running project
might be required to conform to an architecture baseline published at some time in the past, while
a new project can be governed by the architecture's currently published baseline. Also, it can be
appropriate to publish architectures intended for use at some future date. For instance, it can be
helpful to indicate that building block implementations permitted today can be withdrawn from the
catalog on some future date.
Within an architecture baseline, each building block will have one or more permitted
implementations, as well as a full listing of all implementations existing within the current running
IT environment. It is helpful for the architecture to publish roadmaps (also known as route-maps),
in which all existing and possible future implementations are categorized, according to the
architecture preferences. For example, if some implementations are to be actively
•
•
•
•
decommissioned, then they can be categorized as sunset; whereas those which are to be actively
encouraged would be tagged as strategic.
Controls
This activity ensures that viable instances of both baselines and roadmaps are always available.
Inputs
Architecture_ Future (From: A333)
building blocks.
included.
Business and IT Models Update Package (From: A412)
Additional information about business and IT models obtained as a by-product of detailed
investigation under the Solutions Requirements process.
Outputs
A844 A85 A852)
•
•
•
•

be determined.
[A335] Promote Architecture Transition Initiatives

Description
If the business wants to actively pursue the implementation of the architecture, then it will be
appropriate for it to actively identify, scope, and propose initiatives that will help to realize it. These
initiatives can then be considered and prioritized along side all other requests for IT portfolio
consideration, particularly those from the business.
The specification of a transition initiative generally includes high level statements on the scope,
purpose, business benefit, costs, and project outline. It must subsequently be detailed into a formal
proposal, before being considered and accepted as a funded program of change.
Controls
Inputs
building blocks.
Architecture_ Current State (From: A332)
Outputs
Architecture Transition Initiatives
A brief proposal, recommending the implementation of one (or more) aspects of the
envisioned architecture. Typically defined in outline, with broad statements on scope,
benefits and business case, costs, dependencies, and project timeline.
be determined.
•
•
•
•
[A336] Govern Architecture Usage

Description
It is generally necessary to actively ensure the architecture is used, and used appropriately. In
some corporate cultures, this conformance can be possible through trust and delegated authority
to those involved in the design of IT solutions, while in others, it can be necessary to establish
formal conformance processes that are exercised at key milestones within the project and
technology life cycles.
It will not always be possible for a design to follow the guidance of the architecture. Sometimes
business requirements can preclude conformance, or there can be conflicting requirements in the
architecture. In these cases a formal exception to the architecture will be requested and
processed.
Note that exceptions can indicate a need to enhance the architecture itself. See vitality in the
activity “Review Overall Environment and Architecture.”
Controls
Inputs
building blocks.
Architecture_ Current State (From: A332)
A452)
timeframe.
•
•
•
•
Outputs
Configuration Information Request (To: A54 A544)
Any request for information about one or more configuration items. Many IT processes will
make such requests.
Architecture Compliance Decision
A statement or report recording the architectural compliance (including permitted
exceptions) of a solution design.
be determined.
Architecture_ Exception (To: A332)
An allowed deviation within a solution design from the architecture, providing input to the
collection of architecture processes which ensure vitality.
•
•
•
•
[A337] Evaluate Architecture Management Performance

Description
This activity focuses on monitoring the effectiveness of, and suggesting improvements for, the
Architecture Management Framework.
Without this activity, it is probable that architecture will not provide the optimum business benefit.
Success depends on its continuous evolution, in step with the enterprise's own evolution, as well
ensuring its effective use throughout the IT organization.
Controls
Inputs
Architecture Management Activity Data (From: A332 A333 A334 A335 A336)
be determined.
Outputs
Architecture Management Evaluation (To: A331)
Assessment of the effectiveness and efficiency of the architecture management process.
Includes identification of areas for process improvement.
•
•
•
•
Purpose
The Risk Management process exists to identify risks associated with the activities of the IT
endeavor and to make measured, appropriate responses to mitigate, ignore, avoid or transfer
those risks in line with the desired level of risk tolerance.
The definition of risk is “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.”5
Outcomes
All of the activities carried out within IT support the desired risk posture while providing the
maximal benefit
The business and IT are able to appropriately respond to threats and opportunities
Minimal risk exists in the fulfillment of fiduciary responsibilities to stakeholders of the
business
Scope
This process provides the overall framework in which risks are handled. Other processes within IT
work in conjunction with this process to ensure that specific risk areas are adequately responded
to and covered.
Risks occur from a variety of internal and external sources, and cover the range of strategic,
tactical, and operational activities. Consideration of risk covers the potential opportunity from a risk
outcome happening in addition to the more traditional consideration of possible downside
outcomes.
Includes
External risk sources6 such as:
– Financial: Interest rates, foreign exchange, credit
– Strategic: Competition, industry and customer changes, mergers and acquisition
integration
– Operational: Regulations, Culture, Board Composition
– Hazard: Natural events, environment, contracts
Internal risk sources:
– Employees
– Information systems
– Accounting controls
– Cash flow
– Research and development
– Facilities
Risk workshops
5. ITIL V3 Glossary
6. Taken from A Risk Management Standard. The Institute of Risk Management. 2002
•
•
•
•
Mitigation strategies
Excludes
Identification of compliance requirements and controls (Compliance Management)
Security-specific risk management (Security Management), though overall decision
making is part of this process
Implementation and operation of the recommended risk controls (responsibility of the
target IT processes)
Business Continuity Management (Business responsibility in conjunction with IT
Controls
included.
Business Strategy
policies.
Inputs
•
•
•
•

Business Risk Posture
The capability of the business to tolerate varying levels of risk. It includes business
guidance on how to choose which risks to accept and which need mitigation.
Program Plan (From: A37 A372)
The overall plan for the delivery of the program. It will not describe specific details of any
individual part of the work, but will focus on aspects such as:
• The structure of the set of projects which constitute the program
• The measurements and reports by which the program will be managed
• The program's governance and communication plans
Outputs
Risk Assessment and Mitigation Plans (To: A36 A364 A37 A374 A712 A714)
The recommendations as to the acceptability or otherwise of the risk factors of any
undertaking (such as project, external development) and the risk limitation measures
selected to reduce the impact of unacceptable risk occurrence.
•
•
•
•
Activities
A343 Assess Risk
A346 Assess and Report Risk Mitigation Results
IT Management Business Technology Security Policy Security
IT Strategy
Ecosystem Strategy Capabilities C3 Plan/D2
C2
C6 C4 and Trends C1
C5
Security Establish
Management Risk Risk Management
Framework/D1
I5
Framework
A341
Project Proposal
Identify
Threats, Identified Risks
Vulnerabilities
I2 and Risks
Business and A342 Risk Assessment
IT Models
Assess
I1 Risk
Market Analysis
A343
I4 O1
Risk Mitigation
Business Risk Assessment
Define Risk Plans Definition
Risk Posture and Mitigation Plans
Mitigation
I6 Plans and
Program
Plan
Counter-
measures
A344
Enact and
Risk Interventions
I7
Operate Risk and Indicators
Project Plan Counter-
measures
I3 A345
Solution Design
Assess and Risk Mitigation

Report Risk Assessment Reports
I8
Program and
Mitigation
Project Reports ResultsA346
Security Reports/D1
Individual Evaluate
Process
Evaluations/D1 Risk Risk
Evaluation
Risk Management Performance
Activity Data A347
NODE: A34 TITLE:

Risk Management CURRENT PAGE:
Figure 5. A34 Risk Management
•
•
•
•
[A341] Establish Risk Management Framework

Description
Based on the business, IT strategy, and the overall IT Management Ecosystem, a framework for
risk management has to be developed. The tasks in this activity include:
Understanding the goals and objectives for the contribution of risk management to the IT
endeavor
Defining the strategy for risk management approaches and capabilities (including tools),
and how they should be sourced. For instance, should they be developed in-house or rely
more on vendor capabilities
Establishing the decision making capabilities (for example, the algorithms and evaluation
criteria for assessing risk), and the authorities for progressing the results of risk
assessment
Determining skill requirements for the staff, and assigning staff
Ensuring the framework for risk management is deployed and operational, including
relevant communication and guidance to process users.
The establishment of the process framework also includes the continuous improvement of risk
management. For example, the consideration of the Risk Management process evaluation and the
Controls
Business Strategy
policies.
included.
Inputs
security.
•
•
•
•
Risk Management Evaluation (From: A347)

Outputs
Risk Management Framework (To: A342 A343 A344 A345 A346 A347)
A risk management model that allows identification, definition, and assessment of risks,
and the implementation and operation of risk mitigation and avoidance activities.
[A342] Identify Threats, Vulnerabilities and Risks

Description
An analysis of any chosen domain focusing on risk, such as any aspect of the business or any
change program or project. It will examine items such as Business and IT Models, business
policies, regulatory requirements, marketplace information, and IT Management System elements.
The outcome of this analysis identifies current risks and vulnerabilities that the business or change
activity faces.
Controls
Risk Management Framework (From: A341)
Inputs
Risk Interventions and Indicators (From: A345)
The actions taken, either directly or implicitly through the controls previously put in place,
which aim to modify or determine the events or their outcome so that risk exposures are
minimized. In some cases these will be 'Key Risk Indicators' which should be monitored
against thresholds rather than directly requiring risk intervention.
•
•
•
•
Outputs
Identified Risks (To: A343 A722)
Areas in the business where there is a potential for realization of unwanted, adverse
consequences if an event or a given set of events occurs.
Risk Management Activity Data (To: A347)
[A343] Assess Risk

Description
An assessment of identified risks through categorization, impact analysis, quantification and
qualification, and prioritization based on severity and probability. Based on this assessment, the
business risk posture is updated to reflect the current risk assessment.
Controls
Inputs
Identified Risks (From: A342)
•
•
•
•

Risk Mitigation Assessment Reports (From: A346)
Information about the outcomes of risk mitigation activities, indicating both successes and
risk items which require improved treatment.
Outputs
Risk Assessment (To: A344 A346)
Sets of categorized, quantified, and prioritized risks for which the IT endeavor will need to
consider putting in place risk avoidance and mitigation plans.
[A344] Define Risk Mitigation Plans and Countermeasures

Description
Based on the Risk Assessment, a plan is developed to effectively manage these risks. The plan
includes:
A strategy for risk avoidance and mitigation
Action plans, prioritized recommendations, compliance mechanisms, and development of
metrics to achieve the desired risk tolerance
Controls
Inputs
Risk Assessment (From: A343)
•
•
•
•

Outputs
Risk Mitigation Plans Definition (To: A345 A346)
Definition of the Risk Mitigation plans required to be implemented to minimize exposures
and vulnerabilities.
[A345] Enact and Operate Risk Countermeasures

Description
The selected risk avoidance and mitigation countermeasures are put into effect and carried out.
The measures can be one-time, periodical, or continuously active. Implementation will require
communication with employees, and active monitoring and measurement.
Controls
Inputs
Risk Mitigation Plans Definition (From: A344)
•
•
•
•

Outputs
Risk Interventions and Indicators (To: A342 A346)
[A346] Assess and Report Risk Mitigation Results

Description
Risk mitigation plan execution and internal controls are monitored and analyzed to determine their
impact and effectiveness. Exposures and findings that are discovered during the assessment will
be documented and communicated.
Controls
Risk Mitigation Plans Definition (From: A344)
Inputs
Risk Interventions and Indicators (From: A345)
Risk Assessment (From: A343)
•
•
•
•
Security Reports (From: A72 A727)

The reports from auditing and other analyses of IT security monitoring data.
process.
Outputs
Risk Mitigation Assessment Reports (To: A343)
Information about the outcomes of risk mitigation activities, indicating both successes and
risk items which require improved treatment.
[A347] Evaluate Risk Management Performance

Description
that require improvement. For example, the foundation and interfaces of the process, all activities,
their accomplishment, their degree of automation, as well as the roles and responsibilities including
the respective skills. The bases for the improvements are the insights and the lessons learned from
Controls
Inputs
Risk Management Activity Data (From: A342 A343 A344 A345 A346)
Outputs
Risk Management Evaluation (To: A341)
•
•
•
•
Purpose
The purpose of the Product Management process is to guide any IT product (such as an
application, an infrastructure component, an IT service, documentation, or combination thereof)
throughout its life cycle from inception to retirement and to be the ultimate owner of that product.
Definition of Product: an application, asset, tool, or IT assembly that will be used in the delivery of
a set of IT services to IT customers.
Outcomes
Robust, resilient products meet the IT service needs of IT customers
Evolving IT products meet business needs
Adequate resources are provided to carry out product development and support needs
Each product has a long-term vision and direction
Scope
Product Management involves oversight through the entire life of a product.7 This process will
make the case for allocation of resources to this product (and hence its inclusion into the portfolio)
and then provide stewardship over the efforts to create, launch, operate, maintain and finally retire
the product. It will measure product value against objectives throughout the life cycle, and make
recommendations for any modification of the product within the overall portfolio.
Designation as a product does not indicate the make-up of solutions and services that will be
managed. It acts purely as the unit of management for this process. A product could be developed
that becomes the basis for, or contributes to, many services. The converse is also possible.
This process has a symbiotic relationship with Portfolio Management; put another way, they could
be seen as two sides of a coin. Whereas Portfolio Management takes an aggregate, balancing
view across all IT activities, Product Management exists to champion the case for each IT solution,
service or general capability which is managed as a product. In many cases, the Portfolio
Management process will trigger a product life cycle by making a high-level, conceptual decision
to pursue an opportunity area. Product Management is then responsible for developing the
concept through to productive use while under the overall decision-making authority of Portfolio
Management.
7. See ITIL V3 Service Strategy, Appendix B2 for further discussion

•
•
•
•
Includes
Product vision
Long-term product requirements management (as opposed to Solution Requirements,
which manages requirements for a specific release)
Product marketing and launch
Ownership of the content that is included in the Service Catalog
Oversight of ongoing product development and enhancement
Approval authority over product change requests
Initiation of necessary change requests to bring a new product release into production
Product assessment and improvement
Product retirement
Excludes
Development (Realization category of processes)
Product sales (Service Marketing and Sales)
Project management
Controls
included.
contracts (UCs).
•
•
•
•
Inputs
and viability.
A452)
• Commitments: Sets of requirements, designs and other deliverables, such as test
cases.Plans: Sets of committed solution phases, activities, tasks and milestones
together with timeframe.
8. ITIL V3 Glossary
9. ITIL V3 Glossary
•
•
•
•

Pattern of Business Activity."11
Portfolio Decision and Resource Allocation (From: A36 A365)
An allotment or apportionment of financial and other resources (possibly from both the
business and IT) to develop or refine the product vision and product life cycle definition and
plan or for any project proposal not related to a specific product. The financial allotment
includes consideration of both capital and expense funds.
Outputs
and actual change activity in the environment. Change requests can be triggered for a
wide variety of reasons, from a broad spectrum of sources. They can be concerned with
any part of the environment or with any service or activity.
Product Proposal (To: A36 A364)
A product idea being put forward for consideration. A high-level evaluation and
documentation of a product's (or change in a product's characteristics) impact on and fit
with the IT Portfolio, addressing elements such as the market opportunity, technical and

•
•
•
•
integration benefits, risks, costs and potential returns, improving service, competitive
positioning, value, lifespan, among others.
Activities
A354 Initiate and Oversee Product Realization
IT Management IT Strategy Business and IT Budget SLAs OLAs UCs

Ecosystem C3 IT Models C5
C2
C4 C1
I11
Portfolio Decision and
Resource Allocation
I1
Market Analysis
I3 Establish
IT Strategy Product Product
Initiatives
I4 Management Management
Framework Framework
Viable
Innovation IT Financial Modeling
A351
Request/S4
I9
Service Formulate
Catalog Product O3
Product Proposal
I2 Concept Product Vision
Project Proposal
A352
I10
Stakeholder Plan and O2
Requirements Control Product Package
IT Financial Product Product Lifecycle
Modeling Analysis/D4 Definition and Plan
Lifecycle
A353
I6
Service Resilience
Product Lifecycle
Plans Initiate and
Milestone Achievement Portfolio Approval Request
Oversee
I5
Solution
Product
Plans and Realization
A354 Project Charter/S1
Commitments
Guide
Solution Realization Product
Results and Issues/D1 Product
Realization Status O1
I7 Transition
Service Level Package Change
and Request
I8 Operation
Change A355
Information
Product Introduction Monitor and
and Usage Status Assess
Service Review Results/D1 Product Performance
Product Assessment
Performance
A356
Results and Trends/D3 Evaluate
Product Product
Problem Management
Information/D1
Product Performance
A357
Management
Activity Data
NODE: A35 TITLE:

Product Management CURRENT PAGE:
Figure 6. A35 Product Management
•
•
•
•
[A351] Establish Product Management Framework

Description
Create an overall framework for how Product Management will be carried out. This includes
process goals, policies, procedures, tool enablement, metrics, inter-process relationships, role
responsibilities, industry research, and other tasks that define the constraints within which Product
Management will be performed.
Controls
Inputs
Product Management Evaluation (From: A357)
Quantitative and qualitative analysis of the performance of Product Management process
and activities as defined in the Product Management Framework. It also incorporates
recommendations for changes to the framework, the process, and to the metrics.
Outputs
Product Management Framework (To: A352 A353 A354 A355 A356 A357)
A specification of the framework and metrics for managing and measuring the Product
Management process and activities, and incorporating any mandatory elements required
by the overall IT Management System. Incorporates process governance, polices,
standards, methods, reporting and evaluation criteria.
[A352] Formulate Product Concept

Description
Define the long-term vision and high-level capabilities of the product. Develop business cases and
obtain necessary resource commitments. Define product differentiation and key messaging about
the product.
The activity evaluates and documents (at a high level) the market opportunity, potential technical
and manufacturing approaches and risks, cost and schedule estimates, and financial impact. A
final step is making an assessment of the concept and a decision to proceed to the Develop
Definition and Project Plan phase, or to cancel.
Controls
Product Management Framework (From: A351)
included.
•
•
•
•

Inputs
and viability.
undertakings.

•
•
•
•

Outputs
Product Proposal (To: A36 A364)
positioning, value, life span, among others.
Portfolio Approval Request
A request directed to the IT Portfolio Management process for a decision or commitment,
related to a given product's position or milestone achievements within the stages of its life
cycle.
Product Vision (To: A353)
A shared perspective on the future possibilities of a product or group of related products.
Includes context elements such as markets and market share, customers, technologies
and projected technology advances, competitors and product differentiators, cost and
return parameters. Provides a touchstone for product plans and life cycle events.
Product Management Activity Data (To: A357)
[A353] Plan and Control Product Lifecycle

Description
Match product commitments against schedules and resources. Plan contents of product versions.
Determine schedules and plans for new releases. Identify priorities concerning requirements and
responses. Determine product variations. Define packaging approach. Identify key interfaces with
other products. Control product progress against plan.
Controls
•
•
•
•
Inputs
Product Vision (From: A352)
A shared perspective on the future possibilities of a product or group of related products.
Includes context elements such as markets and market share, customers, technologies
and projected technology advances, competitors and product differentiators, cost and
return parameters. Provides a touchstone for product plans and life cycle events.
A452)
timeframe.
Product Lifecycle Milestone Achievement (From: A354 A355)
Information and status of the product's progression through declared life cycle milestones
for realization, transition and operation.
Outputs
cycle.
Product Lifecycle Definition and Plan (To: A354 A355 A356)
A plan that guides and controls a given product's evolution and transition through all
phases of the product life cycle. The plan addresses milestones related to requirements
coverage, realization and integration activities, product version and release schedules,
•
•
•
•
funding and resource assumptions, as well as relationships to IT Strategy and IT Portfolio

directions. Also covers retirement and disposal.
[A354] Initiate and Oversee Product Realization

Description
Provide resources for the development and introduction of the product. Plan and provide resources
needed for development cycles. If this is a service, create the service package. Collaborate with
project management to ensure product release meets requirements. Authorize acceptance of
completed product. Introduce the product into the IT community.
Controls
contracts (UCs).

•
•
•
•
Inputs
Product Lifecycle Definition and Plan (From: A353)
A452)
timeframe.
Outputs
cycle.

•
•
•
•
Product Realization Status (To: A355)
Detailed information about the progress of projects underway to create or change the
product.
Product Lifecycle Milestone Achievement (To: A353)
[A355] Guide Product Transition and Operation

Description
Ensure proper deployment and eventual retirement of the product. Promote integration of the
product within IT services. Ensure satisfactory testing and pilots. Identify and target key customers
of the product. Interface with marketing and sales. Ensure support over all active releases.
Controls
contracts (UCs).
•
•
•
•
Inputs
Product Realization Status (From: A354)
Detailed information about the progress of projects underway to create or change the
product.
Outputs
cycle.
Product Introduction and Usage Status (To: A356)
Detailed information about the progress of projects underway to deploy or retire the
product, as well as information about current usage and acceptance.
Product Lifecycle Milestone Achievement (To: A353)

•
•
•
•
[A356] Monitor and Assess Product Performance

Description
Collect product metrics and analyze to identify relevant aspects of product performance against
commitments in the product plan. Identify opportunities for improving the product. Determine the
value of the product to the IT organization and the business. Identify tangible and intangible value
of the product.
Controls
Inputs
Product Introduction and Usage Status (From: A355)
Detailed information about the progress of projects underway to deploy or retire the
product, as well as information about current usage and acceptance.
Outputs
cycle.
Product Performance Assessment (To: A273 A352 A353)
•
•
•
•

[A357] Evaluate Product Management Performance

Description
This activity determines how well product management was carried out versus its objectives.
Metrics defined by the process framework are collected and analyzed. In addition, other sources
of feedback, such as anecdotal feedback, are collected, and assessments are carried out as called
for by the process framework. All of this goes into making recommendations for improving the
process framework, and those recommendations are provided to the Establish Product
Management Framework activity.
Controls
Inputs
Product Management Activity Data (From: A352 A353 A354 A355 A356)
Outputs
Product Management Evaluation (To: A351)
Quantitative and qualitative analysis of the performance of Product Management process
and activities as defined in the Product Management Framework. It also incorporates
recommendations for changes to the framework, the process, and to the metrics.
•
•
•
•
Purpose
The purpose of the Portfolio Management process is to decide the content of and resource
allocation for the set of IT investments. It includes both long-term and large-scale, as well as short-
term limited-scope opportunities, based on the strategic intent and priorities of the business.
This includes assessing all undertakings that consume resources (such as applications, services,
and IT projects) in order to understand their value to the IT organization.
Definition of Portfolio: The set of development projects and ongoing delivery services that are part
of the IT budget.
Outcomes
Customers participate in defining the IT Portfolio
The strategic fit of IT investments to business intent and priorities is very well matched
Business needs correlate very closely to IT expenditures
The portfolio meets business needs
The business receives maximum value from the IT Portfolio
Scope
Provide for the continuous identification, evaluation, selection, control, and life cycle management
of the aggregate collection of IT investments
Includes
Cognizance of key business drivers to influence investment decisions
Decisions on what programs and projects to fund, often in conjunction with any
business or customer stakeholders
Application portfolio management
Identification of in-sourced, out-sourced, business, and infrastructure applications and
services to be included in the portfolio
Determination of value obtained or projected from portfolio items
Excludes
Execution of projects (Program and Project Management)
Asset management
Delivery of services (Operations category of processes)
•
•
•
•
Controls
included.
Business Strategy
policies.
compliance
Inputs
Risk Assessment and Mitigation Plans (From: A34)
Product Proposal (From: A35 A352)
•
•
•
•

and viability.
Outputs

•
•
•
•
A366 A4 A42 A421 A8 A81 A811 A82 A822 A83 A831 A85 A852)
IT Business Value Report
The contribution to the business from an information technology investment, usually
expressed in economic terms.
Program Charter (To: A37 A372)
A document issued by or created on behalf of the sponsor to describe the program's
objectives. It provides the program manager with the authority to apply organizational
resources to set up and run program activities.
A844)
IT Portfolio Performance Report (To: A31 A313 A316 A364 A365 A366)
Portfolio Decision and Resource Allocation (To: A35 A352 A353 A366 A813)
•
•
•
•
Activities
A361 Establish Portfolio Management Framework
IT Management Business Architecture Baselines Compliance Plans IT Strategy
Ecosystem Strategy and Roadmaps and Controls
C2
C4 C3 C1 C5
Establish
Portfolio Portfolio
Project Framework
Information
Framework
A361
I10
Service
Inventory IT Project
Proposal
Projects and and IT Portfolio
Catalog Additional
Service Categories
Services Inventory
Information
IT Customer IT Request
Transformation Themes A362 Portfolio
and Evaluation Principles/D2 Baseline
I6 Create and
IT Strategy Maintain IT
Initiatives O3
I5 Portfolio Program
Project Proposal Categories Charter
A363
Assess O4
I3 Project Charter
Product Proposal and Proposed
I8 IT Portfolio
Service Resilience Prioritize
Targets
Plans IT Portfolio O1
A364
IT Portfolio
I7 Make IT
Viable
Innovation Portfolio
I2 Decisions
Risk Assessment
and Mitigation Plans and O5
I11 Commitments IT Plan
Stakeholder IT Portfolio
Requirements A365
Review
I4 Conduct IT Results
Market Analysis
I1 Portfolio O7
IT Budget Portfolio Decision and
Review Resource Allocation
Communicate
A366 IT Business O2
Workforce IT Business
Management Value and IT Value Report
Information/D2 Portfolio
Service Pricing and O6
Contract Information/D2
Performance
A367 IT Portfolio
I12 Performance Report
Program and
Project Reports Evaluate
Service Achievement
Reports/D1
Portfolio Portfolio
I9 Evaluation
IT Financial Performance
Reports Portfolio Management A368
Activity Data
Business Metrics/D1
NODE: A36 TITLE:

Portfolio Management CURRENT PAGE:
Figure 7. A36 Portfolio Management
•
•
•
•
[A361] Establish Portfolio Management Framework
[A361] Establish Portfolio Management Framework

Description
The IT Portfolio Management Framework is established by understanding the business and IT
strategies, determining the strategic priorities and assumptions for IT investments (focus areas to
allocate resources). Further, it defines the strategic, organizational, process, and technology
disciplines for managing the IT Portfolio, in line with the overarching governance from the IT
Management Ecosystem. The disciplines are documented in a conceptional structure called the IT
Portfolio Management Framework, which is used to communicate the framework contents to the
organization.
Controls
Business Strategy
policies.
compliance
included.
Inputs
Portfolio Management Evaluation (From: A368)
The effectiveness and efficiency of the process activities and practices performed in
managing the IT portfolio.
Outputs
Portfolio Management Framework (To: A362 A363 A364 A365 A366 A367 A368)
the IT portfolio.
•
•
•
•
[A362] Inventory IT Projects and Services
[A362] Inventory IT Projects and Services

Description
This activity creates and maintains an itemized record of all IT projects and IT services that IT
resources have been allocated or are being consumed.
Controls
Portfolio Management Framework (From: A361)
the IT portfolio.
Inputs
Project Information
Project information includes charter, description, budget and schedule performance and
outlook.
Outputs
Project and Service Inventory
The itemized record of projects and services for which IT resources are being consumed or
are being proposed.(To: A363 A365 A366)
Portfolio Management Activity Data (To: A368)
Performance and quality data regarding activities performed in managing the IT portfolio.

•
•
•
•
[A363] Create and Maintain IT Portfolio Categories
[A363] Create and Maintain IT Portfolio Categories

Description
Based on the strategic priorities and assumptions related for the use of IT within the business, this
activity creates and maintains the categorization schema to be applied to the IT Portfolio. The
categories assist management in assessing the coverage of current and proposed services and
projects, and their relative contribution to the maximization of value, balance, and strategic
alignment.
Controls
the IT portfolio.
Inputs
Project and Service Inventory (From: A362)
are being proposed.
Outputs
IT Portfolio Categories (To: A364 A366 A367)
Key project and asset characteristics and parameters that are used to ensure strategic
alignment with business priorities and to manage risk through diversity of investments.
IT Portfolio Baseline (To: A364)
The initial or starting point of the IT portfolio.
•
•
•
•
[A364] Assess and Prioritize IT Portfolio

Description
This activity enables the consistent evaluation and adjustment of the IT Portfolio. For each IT
project and the majority of IT assets, a unique value is determined in terms of risk and return,
followed by an overall ranking of relative value contribution.
Using this data, IT managers (and the business) can ensure their investment and portfolio
decisions consider the observed or projected values of specific projects and assets, and improve
the predictability of anticipated returns.
Controls
IT Portfolio Categories (From: A363)
the IT portfolio.
Inputs
IT Portfolio Baseline (From: A363)
Product Proposal (From: A35 A352)
•
•
•
•

and viability.
Outputs
Proposal Additional Information Request
A request to provide additional information for a proposed project in order to effectively
perform portfolio management activities.
Proposed IT Portfolio Targets (To: A365)
The set of performance targets set for the IT portfolio including economic, strategic
alignment, and balance.
•
•
•
•
[A365] Make IT Portfolio Decisions and Commitments

Description
This is the portfolio gating mechanism, which means that management confirms the IT Portfolio
targets. It approves accepted project charters and provisions resources, cancels projects and de-
commits resources, approves the IT plan and authorizes funding for IT operations. The aggregate
of these decisions establishes the contents of the IT Portfolio, and the detail of them represents
the IT Plan. The IT plan provides the basis for the day-to-day management of IT.
Controls
the IT portfolio.
Inputs
Proposed IT Portfolio Targets (From: A364)
The set of performance targets set for the IT portfolio including economic, strategic
alignment, and balance.
are being proposed.
Workforce Management Information (From: A84 A842 A843 A844)
Profiles of current managed workforce including performance reviews, skills, training and
compensation.
•
•
•
•

receipt only.
IT Portfolio Review Results (From: A366)
The level of performance achieved to-date of the IT portfolio against target and planned
adjustments necessary to close any performance shortfalls or to exploit performance
opportunities.
Outputs
Proposal Additional Information Request
A request to provide additional information for a proposed project in order to effectively
perform portfolio management activities.
Program Charter (To: A37 A372)
A366 A4 A42 A421 A8 A81 A811 A82 A822 A83 A831 A85 A852)
A844)
Portfolio Decision and Resource Allocation (To: A35 A352 A353 A366 A813)
•
•
•
•
[A366] Conduct IT Portfolio Review

Description
The IT Portfolio Review identifies any strategic imperatives based on the business strategy and
priorities, checks project priorities, and evaluates portfolio balance and alignment. The Portfolio
Review determines corrections to the mix of projects and in adjustments to the portfolio gating
mechanism, to better maximize the portfolio and to reflect the desired balance and alignment.
Controls
the IT portfolio.
Business Strategy
policies.
included.
Inputs
business and IT) to develop or refine the product vision and product life cycle 16
definition and plan or for any project proposal not related to a specific product. The financial
allotment includes consideration of both capital and expense funds.
are being proposed.
•
•
•
•

receipt only.
Outputs
IT Portfolio Review Results (To: A365 A367)
opportunities.
[A367] Communicate IT Business Value and IT Portfolio

Performance
Description
This activity communicates the results of the IT Portfolio Review by reporting actual performance
achieved against the portfolio targets, and by demonstrating IT business value realized.
The reports produced are a key element in aligning business and IT goals and objectives, as well
as in determining the effectiveness of the IT Management System and IT strategies.
Controls
the IT portfolio.
•
•
•
•
Inputs
IT Portfolio Review Results (From: A366)
opportunities.
Business Metrics
Outputs
IT Business Value Report
The contribution to the business from an information technology investment, usually
expressed in economic terms.
IT Portfolio Performance Report (To: A31 A313 A316 A364 A365 A366)
[A368] Evaluate Portfolio Management Performance
Description
This activity analyzes activity data from all the Portfolio Management activities for efficiency and
effectiveness, identifies opportunities for improvement, and recommends changes to the IT
Portfolio Management Framework to enhance overall performance.
Controls
the IT portfolio.
Inputs
Portfolio Management Activity Data (From: A362 A363 A364 A365 A366 A367)
Outputs
Portfolio Management Evaluation (To: A361)
The effectiveness and efficiency of the process activities and practices performed in
managing the IT portfolio.
•
•
•
•
Purpose
The purpose of Program and Project Management is to plan and oversee programs and projects
in support of their objectives.
The definition of a project is a team-based effort to meet specific objectives within a defined period
of time.
The definition of a program is a long-term endeavor undertaken to implement a strategy or mission
to meet business or organizational goals. A program is realized through multiple projects and
ongoing activity.
Outcomes
Projects are completed by the committed target date and within the allocated budget
Stakeholder value is maximized through continuous evolution with stakeholders of project
parameters (scope, budget, time lines, quality) as necessary
’s business environment is reduced through precisely defined projects with clearly identified
and managed risks
Programs controlling multiple projects achieve maximization of value through coordination
of trade-offs between requirements and solution space, and of incremental project
completion and delivery
Productivity is increased by a clear definition of roles, responsibilities, and deliverables,
which result in faster startup through the use of knowledge management, less rework, and
more productive time available to the project
Project resource commitments are clearly separated from operational workload demands
Customer and project teams form more quickly and use common terminology, facilitated by
clearer communication
• Customer satisfaction increases through visibility of the project plans, schedule, and
actual performance against the project objectives
Scope
Programs and projects are similar in that they both require planning and oversight. However, they
are different in a number of ways. Projects are a temporary endeavor with a simple management
structure, whereas programs are long-term, have a more complex management structure (typically
involving a steering committee), and are carried out by a number of projects. In addition, the
success or failure of a program is more likely to affect the bottom line of a business.
•
•
•
•
The same activities apply to both Program and Project Management, but with differing scope and
time scales. Activities within the Program and Project Management process can be classified into
four basic groups:
1. Defining and initiating
2. Planning
3. Executing, monitoring and controlling
4. Closing
A project usually consists of a series of phases, known as the project life cycle, and these groups
of process activities can be applied to each phase individually or to a set of multiple phases.
Therefore, these groups do not necessarily correspond to the phases of the project life cycle. For
example, in a waterfall project, executing and controlling activities can be completed in the design
phase of a project, alongside or followed by planning activities for the development phase.21
The activities described represent a broad model for Project Management activities, which is
largely applicable to both projects and programs alike. A program is realized through multiple
projects and ongoing activity.
Includes
Identifying program and project goals
Establishing clear and achievable objectives
Balancing the competing demands for quality, scope, time, cost factors and resources
Creating project plans
Program and project status reporting to stakeholders
Reconciling the specifications, plans, and approach to the different concerns and
expectations of various stakeholders
Running joint projects with any external agent (such as business, customers,
suppliers):
– Such projects might need to establish agreed standards and conventions
– Alternatively, in the case of multi-supplier projects, there can be reporting
responsibilities to the prime contractor while in-house practices apply within each
contractor's scope
Excludes
Performance and delivery activities (many process categories carry out this work)
Promotion of the end result to production (Deployment Management, usually within a
program or project context)
Controls
compliance
21. IBM WWPMM Concepts.

•
•
•
•
included.
Inputs
Program Charter (From: A36 A365)
A452)
timeframe.
Business Project Management Framework
The implementation within the parent business of a project management framework. This
will usually provide most, if not all, of the framework for managing IT projects.
Outputs
Program Plan (To: A34 A344 A373 A374 A375 A376 A377 A378)
A52 A522 A53 A532)
•
•
•
•
Program and Project Reports (To: A13 A131 A324 A34 A345 A346 A36 A365 A366 A716)
Activities
A371 Establish Program and Project Management Framework
A372 Manage Program
A373 Define and Initiate Project
A374 Plan Project
A375 Track and Report Project
A376 Control Project
A377 Close Project
A378 Evaluate Program and Project Management Performance
IT Strategy IT Management Compliance Plans Skills Plan/D1

C2 Ecosystem and Controls
C3 C1
I5
Business
Project Establish
Management
Framework
Program and Program
Project and Project
Management
I1
Framework
A371
Program Program
Charter Status
Report
Program Change Manage
Request Program
O1
Program
Project Plan
A372
Definition
I2
Define and
Project Charter Initiate
Project
A373
Workforce
Management Plan
Project O2
Information/D1
Project Project Project Plan
Status Tracking
A374 Report Report
Project
Change Request Track and Implementation
I3 Progress Data/S2
Risk Assessment Report
and Mitigation Plans Project
I4
Solution A375 Control
Plans and Project
Commitments
Project Directives
Project
Project Events Completion
Project Directive A376 Report
Outcomes
Close
Project O3
Program and
Change Project Reports
Implementation A377 Evaluate
Communication/D4 Program and Program
Project and
Project
Performance Evaluation
Program and
Project Management A378
Activity Data
NODE: A37 TITLE:

Program and Project Management CURRENT PAGE:
Figure 8. A37 Program and Project Management
•
•
•
•
[A371] Establish Program and Project Management Framework

Description
Based on the business and IT strategy, architectural models, guidelines, and a framework for
project management have to be developed. The tasks in this activity include:
Understanding the requirements and specifications for project management
Defining the strategy for project management tools and capabilities, and how they should
be sourced. For example, should they be developed in-house or rely more on vendor
capabilities
Defining evaluation criteria for project management solutions and services
Establishing the framework for project management by defining and implementing
practices and systems that support process activities
Finally, the structure and process of project management including escalation responsibilities have
to be communicated to the process users.
This activity can be triggered by any decision for joint program or project working with any external
party in order that a clear, unambiguous and agreed framework is established.
The establishment of the process framework also includes the continuous improvement of project
management; that is, the consideration of the Project Management process evaluation and the
Controls
included.
compliance
Skills Plan (From: A84 A844)
Projection of skills needed, including indicating where training is required. For skills
identified to be developed through external means, this represents a requisition to
procurement.
•
•
•
•
Inputs
Business Project Management Framework
The implementation within the parent business of a project management framework. This
will usually provide most, if not all, of the framework for managing IT projects.
Program and Project Management Evaluation (From: A378)
Outputs
Program and Project Management Framework (To: A372 A373 A374 A375 A376 A377
A378 A411)
projects and programs.
[A372] Manage Program

Description
The direction, supervision and control of all aspects of the life cycle of a program of inter-connected
projects. This activity focuses on the coordination and prioritization across projects, departments,
and entities to insure that resource contention is managed from a global focus, while leaving
individual project control to the other activities within this process. Some aspects which distinguish
program management include:
Manage Steering Committee – Projects typically have simple management structures.
Programs, on the other hand, involve a more complex governance primarily because
programs are typically close to the heartbeat of the business. For this reason, a program
will have something like a steering committee that involves executives from various
organizations. Keeping the steering committee informed, staffed, and participating is a
major aspect of program management.
Promote Program Environment – A program manager must often work both inside and
outside of his domain in order to remove barriers that may endanger the program's
success. This involves identifying issues and obtaining agreement with other executives
and teams to remove those barriers and can involve working outside the company.
Plan and Coordinate Program Projects – This is probably the closest to project
management, since it is the chopping up of a program into parts and managing those parts.
It is different, however, in that those projects often do not have a similar management
chain, and those projects might not have a definite end.
Obtain and Manage Program Resources – Financial management of programs might have
to conform to specific regulatory policies. There is typically more money (and other
resources) involved in a program, and they often involve many other types of expenditures
than those faced by projects. CFOs are typically very involved in the financial management
of programs.
Review Program Progress – This is also somewhat similar to project management, except
that projects must constantly be evaluated concerning how well they further the goals of the
program. This involves review of those projects, aligning projects with program goals, and
adjusting or removing projects that no longer meet the program manager's needs. Some
work that has been going on for a long time might be ended because specific goals have
been reached, such as when the program is trying to achieve a culture change.
•
•
•
•
Controls
Program and Project Management Framework (From: A371)
Inputs
Program Charter (From: A36 A365)
Program Change Request
A request to modify or adjust any aspect of an established program. Requests are usually
processed under a requirements or change control procedure in order to ensure
appropriate and auditable responses.
Project Completion Report (From: A377)
Communication between the delivery organization and the sponsor indicating that the work
committed within the project is completed. Provides evidence that all terms of the
agreement have been satisfied and all work has been completed.
Project Tracking Report (From: A375)
Detailed project management information which is indicates the status, in terms of
schedule, quality, risks and costs, of the project against plan.
Outputs
Program Status Report
A snapshot of the progress, status, and issues relating to an established program.
Program Plan (To: A34 A344 A373 A374 A375 A376 A377 A378)
Program and Project Management Activity Data (To: A378)
•
•
•
•
[A373] Define and Initiate Project
[A373] Define and Initiate Project

Description
The activities that are used to understand objectives and scope, shape the target solution (which
might be larger than the current project) and the project to a level that allows planning activities.
Agreement is reached on the objectives of the project, the scope of the project is established, the
initial organization is defined, responsibilities are assigned, and the assessment of situational
factors is documented.
Controls
Inputs
compensation.
Project Directives (From: A376)
Instructions or changes made to bring future performance of the project into line with the
plans and procedures.
Outputs
Project Definition (To: A374)
The document that describes the shape of the project and includes:
• The objectives and scope
• The stakeholders and proposed organization with responsibilities
• The major risks associated with the project
•
•
•
•
[A374] Plan Project
[A374] Plan Project

Description
Detailed work and risk plans are drawn up, the organization is confirmed, and staff assignments
are made. No significant amount of resource can be expended on the project (that is, execution
does not begin) until clear plans are in place and authorization to proceed has been received at
the end of this activity.
Controls
Inputs
Project Definition (From: A373)
The document that describes the shape of the project and includes:
• The objectives and scope
• The stakeholders and proposed organization with responsibilities
• The major risks associated with the project
compensation.
Project Change Request
A request to change some document or aspect of the project that has been placed under
change control. An accepted change request may result in one or more change orders.
A452)
timeframe.
Project Directives (From: A376)
•
•
•
•
[A374] Plan Project

Outputs
A52 A522 A53 A532)
[A375] Track and Report Project

Description
This activity collects and disseminates information about the current state of projects and sub-
projects, and their performance against plans and future projections of achievement or risk.
Project reports summarize status and any issues.
Controls
Inputs
A452)
timeframe.
Project Events (From: A41 A42 A43 A44 A45)
s opinion, are important to support the management of the project.
•
•
•
•
[A374] Plan Project
Project Directive Outcomes

The outcomes of actions taken in response to instructions or changes from project
management made to bring future performance of the project into line with the plans and
procedures.
Change Implementation Communication (From: A51 A516)
Information used to coordinate and implement a change. It can reflect either or both the:
• Status of the overall change as a result of carrying out previous instructions
• Instructions for the next stages of implementation
This dual nature is required to reflect incremental progress towards completion of a multi-
stage implementation, especially when the outcome of one or more steps did not meet
expectations in all respects.
Outputs
Implementation Progress Data (To: A51 A516 A537)
The record of each incremental activity performed as part of the implementation of a
change or release.
Project Status Report
A report, prepared to schedule or request, by the top-level project manager for the line of
business management. It documents the status, progress and accomplishments, and
forecasts for the end of the project. General categories include:
• Health status summary
• Resources
• Earned value indicators
• Accomplishments
• Quality, issue, risk, change, and compliance incident summaries
Project Tracking Report (To: A372 A374 A376 A377)
•
•
•
•
[A376] Control Project
[A376] Control Project

Description
This activity invokes appropriate governance, disciplines, techniques, and actions to ensure the
success of the project.
Approved standard project management methods are applied and executed to manage to the
project plan.
Controls
Inputs
Outputs
Project Directives (To: A373 A374)
•
•
•
•
[A377] Close Project
[A377] Close Project

Description
This activity addresses the use of formal and consistent disciplines to end projects. The sponsors
and stakeholders reach a consensus and agree that the project has run its course and can be
ended.
A project completion report is produced to capture lessons learned.
Controls
Inputs
Outputs
Project Completion Report (To: A372)
Communication between the delivery organization and the sponsor indicating that the work
committed within the project is completed. Provides evidence that all terms of the
agreement have been satisfied and all work has been completed.
•
•
•
•
[A378] Evaluate Program and Project Management Performance

Description
Controls
Inputs
Program and Project Management Activity Data (From: A372 A373 A374 A375 A376 A377)
Outputs
Program and Project Management Evaluation (To: A371)
•
•
•
•
PRM-IT A3 Node Tree
PRM-IT A3 Node Tree
A3 – DIRECTION
A31 IT Strategy
A321 Establish IT Research and Innovating Framework
Qualify Candidates and Define IT Research and Innovation
A323
Projects
A34 Risk Management
A343 Assess Risk
A346 Assess Risk Mitigation Results
A354 Inititate and Oversee Product Realization
•
•
•
•
PRM-IT A3 Node Tree
A3 – DIRECTION
A361 Establish IT Portfolio Management Framework
A372 Manage Program
A374 Plan Project
A377 Close Project
Figure 9. A3 Direction Node Tree
•
•
•
•
[A4] Realization
Description
Purpose
extensions to existing solutions. Maintenance and end-of-life shutdown activities (requiring
solution adjustment) are also addressed in this category.
iteratively and in parallel, in a project-driven context to create information technology solutions for
Test engineering
Rationale
Value
Controls
•
•
•
•
Business Strategy
Inputs
Asset Deployment Items and Data (From: A5 A55)
CIs (From: A5 A54 A543)
Outputs
Solution_ Accepted (To: A5 A52 A523 A53 A533)
CI Requisition (To: A5 A54 A543)
CI Data Update Package (To: A5 A54 A542 A543)
Solution Design (To: A3 A33 A336 A34 A343 A344 A45 A454 A5 A51 A514 A52 A523 A54
A7 A72 A723 A73 A734 A736 A75 A752 A76 A764 A8 A84 A844)
Solution Plans and Commitments (To: A2 A25 A255 A256 A26 A265 A3 A33 A336 A35
A6 A62 A621 A7 A73 A732 A74 A742)
Solution Realization Results and Issues (To: A354 A4 A41 A412 A413 A414 A415 A42
A422 A423 A424 A425 A43 A432 A433 A434 A435 A436 A437 A44 A442 A443 A444
A445 A45 A452 A454 A455)
•
•
•
•
Processes
A44 Solution Test
IT Management Architecture Baselines Security Policy Business IT Portfolio IT Strategy Security IT Plan SLAs OLAs UCs
Ecosystem and Roadmaps C8 Strategy C3 C4 Plan/D3 C2 C5
C6 C1 C7
I1
Project Charter Solution
Requirements
I3 Baseline
Project Plan
Solution
I4 Requirements O6
Stakeholder Solution
Requirements Plans and
A41 Solution Analysis and
Commitments
I6 Design Results
Compliance Plans Solution and Issues O7
and Controls Requirements Solution Realization
Results and Results and Issues
Issues Solution
I5 Analysis and
Service Level Package
Design O5
Solution Design Solution Solution Design
A42 Development
Request
I2 and Integration
Business and Results
IT Models Solution Design and Issues
I8 Package
Configuration Solution
Information
I9
Development O1
Asset Deployment and Change
Items and Data Integration Request
A43 Solution O3
Test CI Requisition
Results
I10 Solution O4
and Issues
CIs Assembly CI Data
Solution Update Package
Test
I7
Solution_ Solution
Deployed Test
A44 Report
Security Risk Solution Acceptance

Assessment/D1 Review Results
Solution and Issues
Acceptance
Operational O2
Documentation/D7 A45 Solution_
Accepted
I11
Solution Realization Project
Results and Issues Events/S1
NODE: A4 TITLE:
Realization CURRENT PAGE:
Figure 1. A4 Realization Diagram
•
•
•
•
Purpose
The purpose of the Solution Requirements process is to provide “a systematic approach to finding,
documenting, organizing, and tracking a system's changing requirements,”1 so that an agreed
understanding is reached as to what the solution should do.
Definition of solution requirement: “A condition or capability to which the system must conform.”2
Outcomes
Stakeholder agreement on high-level requirements is achieved before the solution is
designed, developed, and deployed
Detailed requirements are evolved iteratively with solution design, development, and
testing
Trade-offs between requirements and solution are managed to maximize stakeholder value
An accurate understanding of solution requirements exists, enhancing the probability that
the correct solution will be created
Customer, stakeholder, and user requirements are clearly defined and documented
Traceability is maintained between requirements and solution specifications derived from
them
Rework due to incorrect or misunderstood requirements is minimized
Scope
This process focuses on translating or elaborating agreed customer (business) requirements and
IT stakeholder-generated requirements or constraints into solution-specific terms, within the
context of a defined solution project or program.
It includes establishing operational requirements engineering approaches. Examples often cited
include IEEE 830 Recommended practice for software requirements specifications, IEEE Software
Engineering Body of Knowledge, CMMI and the ITIL V-model (ITIL Service Transition). 3
Includes
Business context modeling
Collecting, understanding, validating, formalizing and documenting solution
requirements
Clarifying, analyzing, and refining the requirements from the Stakeholder
Requirements Management process
Ongoing management of requirements for this solution
The complete Solution Requirements taxonomy, including:
– Functional requirements
– Non-functional requirements, under headings such as Service Management and
Compliance

3. See ITIL Service Design, p167
•
•
•
•
– Deployment requirements (packaging, education, and training)

– Usability requirements
– Change cases and scalability requirements
– Testing requirements
– Stakeholder acceptance criteria
– Solution life cycle requirements, including solution shutdown and retirement
Risk and feasibility analysis of requirements
Requirements baseline generation and traceability audits
Service management considerations
Business modeling discipline and requirements management discipline
Excludes
Translation from requirements to design specification (Solution Analysis and Design)
The life cycle management of customer wants and needs through agreed, prioritized
business requirements (Stakeholder Requirements Management)
Controls
Business Strategy
policies.
included.
•
•
•
•
contracts (UCs).
Inputs
compliance
4. ITIL V3 Glossary
5. ITIL V3 Glossary
6. ITIL V3 Glossary
•
•
•
•
Outputs
Solution Requirements Baseline (To: A42 A422 A423 A44 A442 A444 A45 A453 A712)
Established according to prescribed organizational standards, it is a baseline of all the
Solution Requirements work products currently under Configuration Management.
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
Solution Requirements Results and Issues (To: A412 A413 A414)
The collection of summary level history and status of Solution Requirements activities and
work products. Typically used to establish and update organizational performance
benchmarks (estimates versus actual), transmit quality information, and other heuristics
related to Solution Realization processes.
Project Events (To: A375)
The notification of events that, in the project manager's opinion, are important to support
the management of the project.
Activities
7. ITIL V3 Glossary
•
•
•
•
IT Management IT Plan IT Strategy Business Architecture Baselines Security Policy SLAs OLAs UCs
Ecosystem C5 C6 Strategy and Roadmaps C3 C7
C1 C4 C2
Program and Solution

Project Management Requirements
Framework/D1 Framework
Change/D2 Establish
I1 Solution
Project Charter Business and IT Models
I2
Requirements Update Package
Project Plan Framework A411
I5
Service Level Package Refine and
Verify Rejected
I6 Business Stakeholder
Business and Solution Requirements
IT Models
Context Stakeholder
A412 Scope and
I3 Context Requirements
Stakeholder Proposed Information
Requirements Conditions Request
of Satisfaction Solution
Document and Requirements
I4
Analyze Stakeholder
Compliance Plans Solution Validation
and Controls Requirements Accepted Request
A413 Solution Conditions
Prototype of Satisfaction O3
Requirements_
Work Products Solution Solution
Validated
Requirements Validate Requirements
Results and
Solution Issues
Requirements
Stakeholder
with Solution
Validation Stakeholders Project
Response Plan O2
A414
Solution
Solution Plans and
Requirements Commitments
Solution Defect List Manage
Requirements Solution O1
Baseline Requirements Solution
Change
Request
Baseline Requirements
A415 Baseline
Change Proposal
I7
Solution Realization
Results and Issues
Evaluate
Solution Solution
Evaluation
Solution Requirements Performance
Activity Data A416
NODE: A41 TITLE:

Solution Requirements CURRENT PAGE:
Figure 2. A41 Solution Requirements
•
•
•
•
[A411] Establish Solution Requirements Framework
[A411] Establish Solution Requirements Framework

Description
The purpose of this activity is to establish the project specific Solution Requirements Framework
by tailoring, in a prescribed way, the organization-wide framework (organization-wide set of
procedures, standards and templates related to Solution Requirements management and
engineering), and to define specific performance goals, measurements and targets.
Controls
included.
Inputs
Solution Requirements Evaluation (From: A416)
The collection of summary level history and status of Solution Requirements Framework.
Typically used to establish and update organizational performance benchmarks (estimates
versus actual), transmit quality information, and other heuristics related to Solution
Realization processes.
Outputs
Solution Requirements Framework (To: A412 A413 A414 A415 A416)
Common, organization-wide Solution Requirements set of standards, procedures, and
templates.
•
•
•
•
[A412] Refine and Verify Business Context

Description
The purpose of this activity is to refine the overall business context into the project-related solution
context and understanding, and to verify (verification ensures that you created it right) this refined
context with all solution stakeholders.
Controls
compliance
Solution Requirements Framework (From: A411)
templates.
Business Strategy
policies.
contracts (UCs).
8. ITIL V3 Glossary
•
•
•
•
Inputs
Change (From: A51 A515)
A change, triggered by a change request, which has successfully completed assessment
and has subsequently been authorized for implementation. The authorization includes
details of schedule options and any implementation conditions, such as the decision to
include the change within the scope of a planned release.
Solution Requirements Results and Issues (From: A41 A412 A413 A414 A415)
Solution Requirements Change Proposal (From: A415)
Proposed changes to the business context resulting from changes in solution requirements
baseline.
9. ITIL V3 Glossary
•
•
•
•
Outputs
Business and IT Models Update Package (To: A334)
Additional information about business and IT models obtained as a by-product of detailed
investigation under the Solutions Requirements process.
Rejected Stakeholder Requirements
The part of solution requirements formally rejected by the solution provider, with or without
prior approval of the stakeholders.
Solution Scope and Context (To: A413)
Solution framing and surroundings defined by the business and system environments.
Solution Requirements Activity Data (To: A416)
The collection of detailed and summary level history and status of Solution Requirements
activities. Typically used to establish and update organizational performance benchmarks
(estimates versus actual), transmit quality information, and other heuristics related to the
Solution Requirement process.
[A413] Document and Analyze Solution Requirements

Description
The purpose of this activity is to create the initial set of Solution Requirements by identifying
sources and stakeholders, soliciting input from them, and capturing it for the purpose of classifying
and categorizing the obtained information into requirements categories.
Controls
templates.
included.
•
•
•
•

contracts (UCs).
Inputs
Solution Scope and Context (From: A412)
Solution framing and surroundings defined by the business and system environments.
compliance

•
•
•
•
Prototype Work Products
Reduced scale or function deliverables used to explore feasibility or suitability of some
aspect of the solution.
Solution Requirements Defect List (From: A414)
Formal list of discrepancies between documented and formalized solution requirements
and solution intentions as perceived by the key stakeholders (customer).
Outputs
Stakeholder Requirements Information Request
Solicitation of requirements information from the stakeholders, usually for clarification or
expansion of stakeholder requirements already registered.
Proposed Conditions of Satisfaction (To: A414)
Documented Conditions of Satisfaction as understood and formally proposed by the
solution provider.
Solution Requirements (To: A414)
Documented, analyzed and expanded (formalized) solution requirements.
•
•
•
•
[A414] Validate Solution Requirements with Stakeholders

Description
The purpose of this activity is to validate (validation ensures that you have created the right thing)
the Solution Requirements with all solution stakeholders.
The requirements should be complete, comprehensive, testable, and include the conditions of
satisfaction while noting any observed defects.
This activity also produces an early iteration of the solution project plan.
Controls
templates.
contracts (UCs).
Inputs
Proposed Conditions of Satisfaction (From: A413)
Documented Conditions of Satisfaction as understood and formally proposed by the
solution provider.
Solution Requirements (From: A413)
Documented, analyzed and expanded (formalized) solution requirements.

•
•
•
•

Solution Requirements Stakeholder Validation Response
Solution validation responses as communicated by the stakeholders. Covers both the
positive and negative cases, with the latter being considered a defect.
Outputs
Solution Requirements Stakeholder Validation Request
A request to stakeholders for review, confirmation and formal sign-off of solution
requirements.
Solution Project Plan
The overall project plan augmented by solution-specific content as a result of completion of
requirements validation.
Accepted Conditions of Satisfaction (To: A415)
Established earlier Conditions of Satisfaction formally accepted and signed off by the key
stakeholders (especially the customer).
Solution Requirements_ Validated (To: A415)
Solution scope, context and entire taxonomy of requirements formally validated and
approved (signed off) by the key stakeholders.
Solution Requirements Defect List (To: A413)
Formal list of discrepancies between documented and formalized solution requirements
and solution intentions as perceived by the key stakeholders (customer).
•
•
•
•
[A415] Manage Solution Requirements Baseline
[A415] Manage Solution Requirements Baseline

Description
The purpose of this activity is to assure that the Solution Requirements come under Configuration
Management, and are controlled as a collection (a baseline) for all status changes throughout the
duration of the project. Techniques used should be in agreement with the overall organization
procedures and standards for general Configuration Management.
Controls
Accepted Conditions of Satisfaction (From: A414)
Established earlier Conditions of Satisfaction formally accepted and signed off by the key
stakeholders (especially the customer).
templates.
Inputs
Solution Requirements_ Validated (From: A414)
Solution scope, context and entire taxonomy of requirements formally validated and
approved (signed off) by the key stakeholders.
Solution Requirements Baseline Change Request
Outputs
Solution Requirements Baseline (To: A42 A422 A423 A44 A442 A444 A45 A453 A712)
Solution Requirements Change Proposal (To: A412)
Proposed changes to the business context resulting from changes in solution requirements
baseline.
•
•
•
•
[A416] Evaluate Solution Requirements Performance

Description
The purpose of this activity is to evaluate performance of the project-specific Solution
Requirements Framework against early defined performance criteria and measurements, to
provide input into the organization-wide framework (for overall evaluation purposes), and to identify
potential improvements to the Solution Requirements process.
Controls
templates.
Inputs
Solution Requirements Activity Data (From: A412 A413 A414 A415)
Outputs
Solution Requirements Evaluation (To: A411)
The collection of summary level history and status of Solution Requirements Framework.
Typically used to establish and update organizational performance benchmarks (estimates
versus actual), transmit quality information, and other heuristics related to Solution
•
•
•
•
Purpose
The Solution Analysis and Design process exists to create a fully documented design from the
agreed solution requirements, describing the behavior of solution elements, the acceptance
criteria, and agreed measurements.
Outcomes
Solution designs optimize the trade-offs between requirements and constraints
Stakeholder agreement on high-level solution design is achieved before major investments
in solution development is done
Reuse of existing solution designs and components minimizes time-to-implementation and
improves solution quality
Flexible and effective designs reduce the total cost of ownership over the complete solution
life cycle
Scope
Design of all aspects of the solution necessary to meet stakeholder requirements
Includes
Creating and managing design baselines (specifications baseline, component
architecture baseline) throughout the full range of the solution life cycle including
solution shutdown and retirement
Ensuring solution design compliance with the business and IT architectures
Identification and consideration of constraints, such as budget, and making cases for
constraint relief or seeking guidance when a sound solution design is not achievable
against those constraints
Creating different solution architectural views (component model, operational model,
deployment model, data model)
Evaluating trade-offs (such as financial cost alternatives) and making design and
sourcing approach decisions (make versus buy versus reuse)
Making architecture exception requests
Modeling, simulation, and prototyping
Design of all required solution elements (application, infrastructure, process,
organization, data, training, deployment, technology, testing)
Systems operation and management design, such as significant event definition,
monitoring data definitionHigh and low level design
Ensuring cross-functional participation in design acceptance from service
management disciplines
Excludes
Enterprise architecture (Architecture Management)
•
•
•
•
Requirements management (Stakeholder Requirements Management, Solution

Requirements)
Controls
included.
Inputs
A452)
timeframe.
Solution Requirements Baseline (From: A41 A415)
•
•
•
•
Solution Design Request (From: A52 A523 A53 A533)
A formal communication that authorizes and triggers the Solution Analysis and Design
process (usually beginning at the conceptual design level).
Security Risk Assessment (From: A723)
A detailed analysis of the current and projected security risk factors facing the enterprise.
Outputs
Solution Analysis and Design Results and Issues (To: A422 A423 A424)
The collection of summary level history and status of Solution Design activities and work
products. Typically used to establish and update organizational performance benchmarks
(estimates versus actual), transmit quality information, and other heuristics related to
Solution Development processes.
• Attributes
• Relationships
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.

•
•
•
•
A7 A72 A723 A73 A734 A736 A75 A752 A76 A764 A8 A84 A844)
Solution Design Package (To: A425 A43 A432 A434 A435 A436 A437 A44 A442)
The collection of all the work products created during solution design.
Activities
A425 Validate Solution Design With Stakeholders
IT Management IT Plan IT Strategy IT Portfolio Security Architecture Baselines
Ecosystem C5 C6 C4 Plan/D3 and Roadmaps
C1 C3 C2 Reusable Solution Analysis and
Components Design Framework
I5 IT Financial Modeling
Business and
IT Models Request/S5
IT Financial Establish
Modeling Analysis/D5 O2
Solution Change
Availability and
Recovery Design
Analysis and Request
Criteria/D2 Design Solution Design
I3 Framework Additional
Service Level Package A421 Information Request
I2 Solution Configuration
Solution Design_ Information
Requirements Conceptual Request/S3
Baseline
Create
Conceptual
I1 Solution O5
Solution
Plans and Design Solution
Commitments A422 Plans and
Solution Commitments
I4 Component
Solution Design Specifications
Request
Identify and
I6 Select
Solution Realization Solution O1
Results and Issues Components Solution Analysis and
A423 Design Results
Configuration and Issues
Baseline O3
Report/D1 Create
CI Requisition
I7 Detailed
Configuration Solution O4
Information Design CI Data
A424 Update Package
Prototype
Work
O7
Products/D1 Validate Solution Design
I8 Solution Package
Security Risk Design O6
Solution Design
Assessment/D1 With
Stakeholders
A425 Solution Design
Solution Design Change Proposal Stakeholder
Solution
Acceptance
Design
Stakeholder
Evaluate Request
Acceptance Solution Solution Analysis
Response Analysis and Design
and Design Evaluation
Solution Analysis Performance
and Design A426
Activity Data
NODE: A42 TITLE:

Solution Analysis and Design CURRENT PAGE:
Figure 3. A42 Solution Analysis and Design
•
•
•
•
[A421] Establish Solution Analysis and Design Framework
[A421] Establish Solution Analysis and Design Framework

Description
Establish the project-specific framework for Solution Analysis and Design, and define specific
performance goals, measurements, and targets. The procedure for establishing this framework is
by tailoring the organization-wide framework of procedures, standards, and templates related to
analysis and design management and engineering.
Controls
included.
Reusable Components
Parts (engineering parts) from the set of components identified for future reuse by the
Architecture Management process.
Inputs
Solution Analysis and Design Evaluation (From: A426)
The collection of summary level history and status of the Solution Analysis and Design
Framework. Typically used to establish and update organizational performance
related to Solution Development processes.
Outputs
Solution Analysis and Design Framework (To: A422 A423 A424 A425 A426 A733)
work flows, inputs, outputs), and technology (software, hardware) practices for solution
analysis and design.
•
•
•
•
[A422] Create Conceptual Solution Design

Description
The purpose of this activity is to create a high level view (architectural view) of the solution design
for the purpose of determining the overall shape of the solution.
Controls
Solution Analysis and Design Framework (From: A421)
Inputs
undertakings.
A452)
timeframe.

•
•
•
•
Solution Design Request (From: A52 A523 A53 A533)

Solution Analysis and Design Results and Issues (From: A42 A422 A423 A424 A425)
Solution Design Change Proposal (From: A425)
Proposed changes to the solution design resulting from review of solution design work
products with stakeholders against the solution requirements.
Outputs
Solution Design Additional Information Request
Solicitation to the stakeholders for additional information required to complete the solution
design (further clarification of requirements).
make such requests.
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
Solution Design_ Conceptual (To: A423)
High level view (architectural view) of the solution, including initial versions of component
model, operational model, high-level architectural overview, and architectural decisions.
•
•
•
•
Solution Analysis and Design Activity Data (To: A426)
The collection of summary level history and status of Solution Analysis and Design
[A423] Identify and Select Solution Components

Description
The purpose of this activity is to create a detailed, component-by-component view (engineering
view) of the solution design. The overall functionality of the solution is assigned to discrete,
identifiable functional engineering elements. Solution components are selected to meet those
specifications, in conjunction with approved architectures. Any outstanding issues are also
identified and communicated.
Controls
Reusable Components
Inputs
Solution Design_ Conceptual (From: A422)
High level view (architectural view) of the solution, including initial versions of component
model, operational model, high-level architectural overview, and architectural decisions.

•
•
•
•

Configuration Baseline Report (From: A54 A542 A543)
A point-in-time snapshot of a portion of a CMDB which is relevant to one or more purposes
from other IT management processes. This can include past, current and future-projected
instances.
Outputs
Solution Component Specifications (To: A424)
Formal specification for all the solution components prepared in a prescribed way in
agreement with organization-wide procedures and standards.
make such requests.
•
•
•
•
[A424] Create Detailed Solution Design

Description
Create a low level view (engineering view) of the Solution Design for the purpose of further
breaking down the overall functionality of the solution into functional engineering elements and
determining relationships between them.
Controls
Reusable Components
Inputs
Solution Component Specifications (From: A423)
Formal specification for all the solution components prepared in a prescribed way in
agreement with organization-wide procedures and standards.
•
•
•
•
Outputs
make such requests.
• Attributes
• Relationships
Solution Design Package (To: A425 A43 A432 A434 A435 A436 A437 A44 A442)
•
•
•
•
[A425] Validate Solution Design with Stakeholders

Description
Validate the solution design (conceptual, macro, and micro) with all the relevant stakeholders. To
validate ensures that you created the right thing.
Controls
Inputs
Solution Design Package (From: A42 A424)
Solution Design Stakeholder Acceptance Response
A formal acceptance and sign off or rejection by stakeholders of solution design.
Outputs
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
A7 A72 A723 A73 A734 A736 A75 A752 A76 A764 A8 A84 A844)
•
•
•
•
Solution Design Stakeholder Acceptance Request
A request to stakeholders for review, confirmation and formal sign-off of solution design.
Solution Design Change Proposal (To: A422 A423 A424)
[A426] Evaluate Solution Analysis and Design Performance

Description
The performance evaluation of the process aims at identifying areas of the overall process that
require improvement. For example, the foundation and interfaces of the process, all activities, their
accomplishment, their degree of automation, as well as the roles and responsibilities including the
respective skills. The bases for the improvements are the insights and the lessons learned from
Controls
Inputs
Solution Analysis and Design Activity Data (From: A422 A423 A424 A425)
Outputs
Solution Analysis and Design Evaluation (To: A421)
The collection of summary level history and status of the Solution Analysis and Design
Framework. Typically used to establish and update organizational performance
related to Solution Development processes.
•
•
•
•
Purpose
The Solution Development and Integration process exists to bring together all of the elements
specified by the solution design, regardless of whether they are to be created or acquired, and to
complete their customization, configuration, and integration.
Outcomes
Agreed solutions are produced to approved specifications, on time, within budget and
generally maximizing stakeholder value
Frequent demonstrations of capabilities to stakeholders are done to provide feedback on
requirements, other specifications, and implemented assets
Lessons learned are fed to key stakeholders so requirements and other specifications can
be evolved as necessary
Solutions are ready for testing and examination of solution capabilities
All necessary elements exist to support Solution Management (life cycle, maintenance,
known errors, documentation, best practice guidance, and others)
All solution components are identified and tracked
Solution characteristics are fully verified before Solution Acceptance activities
Scope
Includes
Establishing development standards
Development of new functionality
Integration of new and existing functionality
Use of all design elements
Prototyping
Creating alpha, beta, and general availability versions of solutions
Making any procured elements available to the solution development and integration
team. These can come from external or internal providers
Working in conformance with agreed version control policies and procedures for
solution elements, at whatever level of assembly or integration
Excludes
Testing (unit testing is considered to be in the Solution Test process, even if performed
by the implementer or builder)
Solution pilot and deployment (Deployment Management)
Asset Management
Administration of version control (includes Configuration Management of elements
within the solution during the development phase)
– Called change management version control (CMVC) in CMMI
•
•
•
•
Controls
included.
Inputs
A452)
timeframe.
deliver an IT Service. ... CIs typically include IT Services, hardware, software, buildings,
people, and formal documentation such as Process documentation and SLAs." 22
•
•
•
•
Outputs
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
Solution Development and Integration Results and Issues (To: A432 A433 A434 A435
A436)
The collection of summary level history and status of Solution Development and Integration
activities and work products. Typically used to establish and update organizational
performance benchmarks (estimates versus actual), transmit quality information, and other
heuristics related to Realization processes.
• Attributes
• Relationships
Solution Assembly (To: A44 A443 A444 A45 A456 A542 A543)
The collection of all the work products created during solution development and integration,
including prototypes or implementation of parts of a solution for evaluation and analysis
purposes.
Activities

•
•
•
•
IT Management Architecture Baselines IT Strategy IT Plan
Ecosystem and Roadmaps C3 C4
C1 C2
Establish Solution Development

Solution and Integration Plan Solution Development
Development and Integration
I1
Solution
and Integration Framework
Framework Request O3
Plans and Solution Development Change
A431 for Product
Commitments and Integration Environment Request
or Service/S1
Define
Solution O1
I2 Solution
Solution Design Allocated Development Plans and
Package Asset Items/D1 and Integration
I3 Commitments
Asset Deployment Plan A432 Prepare O5
Items and Data CI Data
Solution
Update Package
I5 Development
Solution_ and Integration
Deployed
Environment
I6 A433 Solution
CIs Acquire or Asset Deployment
Components
Inquiries
Create O4
and Requisitions/S1
Solution CI Requisition
I4 Components O6
Solution Realization A434 Solution
Results and Issues Solution_
Assembly
Integrate Integrated
Solution
Components
A435
O2
Solution_ Solution
Refine Tuned Development
and Tune and Integration
Integrated Results
Solution Solution_ and Issues
A436 Verified
Verify
Integrated
Solution Solution
Solution Verification
Verification Request
A437
Results
Evaluate
Solution
Development
Solution Development and
and Integration
Integration Activity Data Performance
A438
Solution
Development
and Integration
Evaluation
NODE: A43 TITLE:
Solution Development and Integration CURRENT PAGE:
Figure 4. A43 Solution Development and Integration
•
•
•
•
[A431] Establish Solution Development and Integration Framework
[A431] Establish Solution Development and Integration

Framework
Description
Establishes the general and the project specific Solution Development and Integration Framework
by tailoring, in a prescribed way, the organization-wide framework (organization-wide set of
procedures, standards, and templates related to Solution Development and Integration
Management and Engineering), and to define specific performance goals, measurements and
targets.
Controls
included.
Inputs
Solution Development and Integration Evaluation (From: A438)
Formal evaluation of the performance of the project specific activities against the defined
performance criteria and measurements within the Solution Build Framework.
Outputs
Solution Development and Integration Framework (To: A432 A433 A434 A435 A436 A437
A438)
Common, organization-wide Solution Development and Integration policies, standards,
procedures and templates.
•
•
•
•
[A432] Define Solution Development and Integration Plan

Description
The purpose of this activity is to develop a Solution Development and Integration Plan that details
the standards, methods, techniques, technologies, environments, and development and
integration tasks related to a specific Solution Design Package. These are employed to create
iterations of solution assemblies (builds) as the solution is constructed and integrated. The activity
includes planning time frames and resources required.
Controls
Solution Development and Integration Framework (From: A431)
Inputs
A452)
timeframe.
Solution Development and Integration Results and Issues (From: A43 A433 A434 A435
A436 A437)
Outputs
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
•
•
•
•
Request for Product or Service (To: A822 A823 A824)

Information about required products and services that are needed by any IT process - but
especially Solution Build and Solution Test. It will be used within the activities of selecting
and managing the right portfolio of suppliers and respective supplier contracts, or to initiate
actual procurement.
Solution Development and Integration Plan (To: A433 A434 A435 A436 A437)
Formally defined following a prescribed, organization-wide procedure, set of tasks and
activities together with a time frame required to perform solution development and
integration. Usually a part of a larger project plan.
Solution Development and Integration Activity Data (To: A438)
The collection of detailed history and status of Solution Development and Integration
[A433] Prepare Solution Development and Integration

Environment
Description
The purpose of this activity is to prepare the solution development environment and integration
environment by either creating it from scratch or by modifying an existing one. It includes
generating solution element and development and integration element information as necessary
for seamless integration.
Controls
Common, organization-wide solution development and integration policies, standards,
Inputs
Solution Development and Integration Plan (From: A432)
Allocated Asset Items (From: A552)
The assignment and delivery (if appropriate) of identified IT assets to fulfill asset
requisitions.
•
•
•
•
A436 A437)
Outputs
• Attributes
• Relationships
A436)
Asset Deployment Inquiries and Requisitions (To: A55)
Requests for information about assets needed as part of deploying solutions, requisitions
for allocation of assets and notifications to trigger the delivery or distribution of these
resources.
Solution Development and Integration Environment (To: A434 A435 A436)
The entire infrastructure required to complete the solution build process, including the
tools, supporting work products (scaffolding), and physical configuration control repository
for the solution work products.
[A434] Acquire or Create Solution Components

Description
The purpose of this activity is to obtain all the elements (or their substitutes) of the solutions from
predetermined sources within a specific time frame. It can achieve this by purchasing or leasing
pre-existing components from an external source, by in-house development, or by custom
development from a specific developer. It includes putting the components into the build
environment and updating Configuration Management.
•
•
•
•
Controls
Inputs
Solution Development and Integration Environment (From: A433)
requisitions.
people, and formal documentation such as Process documentation and SLAs."23
A436 A437)
Outputs
• Attributes
• Relationships
for allocation of assets and notifications to trigger the delivery or distribution of these
resources.

•
•
•
•

A436)
Solution Components (To: A435)
All the work products, acquired or built in-house, required to complete the solution build,
which will remain as integrated parts of the solution (opposite to supporting parts).
[A435] Integrate Solution Components

Description
The purpose of this activity is to assemble all of the components into the solution in a
predetermined way, within the specific time frames called for in the solution plans and
commitments. The integration work performed in this activity includes the broad range of
components necessary for solution acceptance, such as:
Hardware components
Software modules
Installation scripts
Operating procedures
Education
It further includes putting the newly integrated components into the cumulative development
environment and updating Configuration Management records to reflect the results of integration
and migration.
Controls
Inputs
Solution Components (From: A434)
All the work products, acquired or built in-house, required to complete the solution build,
which will remain as integrated parts of the solution (opposite to supporting parts).
•
•
•
•

requisitions.
A436 A437)
Outputs
• Attributes
• Relationships
A436)
Solution_ Integrated (To: A436)
Completely assembled solution ready to be moved from the development and integration
environment into the test environment. Usually includes work products and features
required to support solution testing and acceptance.
•
•
•
•
[A436] Refine and Tune Integrated Solution

Description
The purpose of this activity is to further improve the assembled and integrated solution by refining
and fine-tuning the overall solution; both the individual solution components and connections
between them.
It includes putting the tuned solution into the cumulative development environment and updating
Configuration Management records to reflect the results of tuning and iterative builds.
Controls
Inputs
Solution_ Integrated (From: A435)
Completely assembled solution ready to be moved from the development and integration
environment into the test environment. Usually includes work products and features
required to support solution testing and acceptance.
requisitions.
A436 A437)
Outputs
• Attributes
•
•
•
•
• Relationships
A436)
Solution_ Tuned (To: A437)
Integrated solution after refining and fine tuning the overall solution as well as solution
components and connections between them. Performed according to a prescribed,
organization-wide procedure.
[A437] Verify Integrated Solution

Description
The purpose of this activity is to verify (verification ensures that you built it right) the Integrated
Solution with all solution stakeholders. Verification includes using techniques such as code review
and static analysis.
Once verification is obtained, it includes putting the newly integrated components into the
cumulative development environment and updating Configuration Management records to reflect
stakeholder concurrence with the solution.
Controls
Inputs
Solution_ Tuned (From: A436)
Integrated solution after refining and fine tuning the overall solution as well as solution
components and connections between them. Performed according to a prescribed,
organization-wide procedure.
•
•
•
•
Solution Verification Results

Formal list of the entire positive (successful) and negative (deviations) from the standards
and procedures identified during the verification process.
Outputs
• Attributes
• Relationships
Solution_ Verified
Integrated solution after verification by all the relevant stakeholders with all the verification
issues (deviations from standards and procedures) formally resolved.
A436)
Solution Verification Request
Formal request to verify (verification ensures that you built it right) the integrated solution by
all the relevant stakeholders.
•
•
•
•
[A438] Evaluate Solution Development and Integration Performance
[A438] Evaluate Solution Development and Integration

Performance
Description
The purpose of this activity is to evaluate performance of the project-specific activities against the
defined performance criteria and measurements within the Solution Build Framework, and to
provide input into the organization-wide framework.
Controls
Inputs
Solution Development and Integration Activity Data (From: A432 A433 A434 A435 A436
A437)
Outputs
Solution Development and Integration Evaluation (To: A431)
Formal evaluation of the performance of the project specific activities against the defined
performance criteria and measurements within the Solution Build Framework.
•
•
•
•
[A44] Solution Test
[A44] Solution Test
Purpose
The Solution Test process exists to validate prior to deployment that the solution and its features
conform to design specifications and requirements. It also verifies that interim work products exist
and conform to standards.
Testing is performed throughout the entire life cycle of the solution, including post-deployment.
Outcomes
Solution functionality is verified and documented
The actual characteristics and behavior of the solution are well known. Any differences with
the solution requirements and agreed design specifications are reported.
Solution defects are identified before the decision is made to migrate to the production
environment
Developers and stakeholders receive thorough quantitative and qualitative assessments of
solution quality. (It is intended that the developers and stakeholders take some action as a
result of having received this information.)
Stakeholder expectations match solution characteristics.
Scope
The ITIL Service Transition book provides useful discussion and examples. See the discussions
around the service V-model.24
Includes
All types of testing, such as:
– Unit testing
– Integration testing
– Acceptance testing
– Usability testing
– Operability testing
– Security testing
– Regression testing
Test case development
Generating test results
Managing the documentation of the test results
Satisfying the requirements of the test management checklist
Excludes
Fixing errors (depending on the nature of the error, this could involve any combination
of Solution Requirements, Solution Analysis and Design, Solution Development and
Integration)
24. ITIL Service Transition, figures 4.21 and 4.30

•
•
•
•
[A44] Solution Test
Design for testability (Solution Analysis and Design)

Knowledge management
Gaining acceptance (Solution Acceptance)
Piloting (Deployment Management)
Auditing (Solution Acceptance)
Controls
included.
Inputs
A452)
timeframe.
Solution Assembly (From: A43)
purposes.
•
•
•
•
[A44] Solution Test

Outputs
Solution Test Results and Issues
The collected set of documentation that describes the fit-for-purpose characteristics of all
of the Solution Test activity work products, and any issues identified as a result of executing
the Solution Test process.
• Attributes
• Relationships

•
•
•
•
[A44] Solution Test
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
Solution Test Report (To: A45 A454)
The collected test data, results and analysis of the solution and environment under
consideration. Includes test cases and defective test cases.
Activities
A443 Prepare and Manage Solution Test Environment
IT Management IT Plan IT Strategy Security Architecture Baselines

Ecosystem C4 C3 Plan/D3 and Roadmaps
C1 C5 C2
I1
Solution Establish
Plans and Solution Test
Commitments Solution Test
Framework Request Framework
I3 A441 for Product O4
Solution Design or Service/S2 Change
Package Solution Request
Test Strategy
and Plans
Develop O5
Existing Solution Test Solution
Test Cases Strategy and Plans and
I7
Configuration Plans Test Commitments
Information Environment
A442 Specifications
Solution Solution Test Information Request/S4
Requirements Test Environment
Baseline Cases Prepare and
Manage Solution Test
Solution Test Environment Baseline O3
I5
CI Requisition
Solution_ Environment
Deployed A443
O2
Solution CI Data
I8 Update Package
Solution Realization Test
Results and Issues Results
Perform
Solution Test
I2 O1
Solution Solution
Solution
Assembly A444 Test
Test
Issues Results
and Issues
I4 Analyze and
CIs Report
Solution Test O6
Results Solution
Test
I9
A445 Report
Security Risk
Assessment/D1
Evaluate
Solution Test Solution
Test
A446
Solution Test
Activity Data
NODE: A44 TITLE:

Solution Test CURRENT PAGE:
Figure 5. A44 Solution Test

•
•
•
•
[A44] Solution Test
[A441] Establish Solution Test Framework
[A441] Establish Solution Test Framework

Description
The purpose of this activity is to tailor in a prescribed way the organization-wide IT Management
Framework (policies, standards, procedures, templates related to Solution Test Management and
engineering) and to define specific goals, measurements, and targets.
Controls
included.
Inputs
Solution Test Evaluation (From: A446)
The effectiveness and efficiency of the practices performed in executing the Solution Test
process.
Outputs
Solution Test Framework (To: A442 A443 A444 A445 A446)
workflows, inputs, outputs), and technology (software, hardware) practices to be used in
achieving the objectives of the Solution Test process.
•
•
•
•
[A44] Solution Test
[A442] Develop Solution Test Strategy and Plans

Description
The purpose of this activity is to develop a project solution-specific approach to Solution Testing
(consistent with overall IT practices) and to create the Solution Test (quality control) Project Plan.
This activity creates the specifications for all test environments that will be used to test the solution
(or solution components), as well as the test cases to be used.
When necessary, this activity also identifies new products or services required to support and
complete the test strategies and plans.
Controls
Solution Test Framework (From: A441)
Inputs
A452)
timeframe.
Existing Test Cases
Any relevant, previously-defined and exercised test case that is identified as relevant to the
particular solution for which testing is being planned. These test cases are managed under
the Knowledge Management process.
•
•
•
•
[A44] Solution Test
Solution Test Issues (From: A445)

Any additional issues identified during test results analysis that need to be recognized and
perhaps addressed.
Outputs
A6 A62 A621 A7 A73 A732 A74 A742)
time frame.
Request for Product or Service (To: A822 A823 A824)
actual procurement.
make such requests.
Solution Test Strategy and Plans (To: A443 A444 A445 A446)
A description of the strategies to be employed and the (sub) project plan which identifies
the approach, activities and tasks, responsibilities, and schedule for testing various aspects
of the solution as it is designed, built and integrated.
Test Environment Specifications (To: A443)
Based on the requirements and design of each solution and on the selected, customized
test strategy and plans, this is a specification of the test environment that will support the
required testing.
Solution Test Cases (To: A443 A444)
The collection of test cases; that is, the description of what is to be tested, why, how
(including sample data), and the expected outcomes from the testing.
Solution Test Activity Data (To: A446)
Performance and quality data regarding activities performed in executing the Solution Test
process.
•
•
•
•
[A44] Solution Test
[A443] Prepare and Manage Solution Test Environment

Description
The purpose of this activity is to prepare the Solution Test Environment by either creating it from
scratch or by modifying an existing one. It includes Configuration Management of solution
elements, Build Environment elements, and test cases.
Controls
Inputs
Solution Test Strategy and Plans (From: A442)
Test Environment Specifications (From: A442)
Based on the requirements and design of each solution and on the selected, customized
test strategy and plans, this is a specification of the test environment that will support the
required testing.
Solution Test Cases (From: A442)
Solution Assembly
purposes.(From: A43)
perhaps addressed.
•
•
•
•
[A44] Solution Test
Outputs
make such requests.
Solution Test Environment Baseline (To: A445)
A reference point specification of the functional environment used to support testing of a
specific solution.
Solution Test Environment (To: A444)
The functional environment constructed and allocated to support testing of a specific
solution.
process.
[A444] Perform Solution Test

Description
The purpose of this activity is to test the partially or fully assembled solution in a way according to
the Solution Test Strategy and Plans within the specified time frame, and to document the results.
It includes putting the integrated solution into the test environment and providing updated
Configuration Management data.
Controls
Inputs
Solution Test Environment (From: A443)
The functional environment constructed and allocated to support testing of a specific
solution.
Solution Test Cases (From: A442)
•
•
•
•
[A44] Solution Test

purposes.
perhaps addressed.
Outputs
• Attributes
• Relationships
Solution Test Results (To: A445)
The outcomes (results) of applying the selected test cases to the Solution Build Package.
process.
[A445] Analyze and Report Solution Test Results

Description
The purpose of this activity is to review the documented results of testing activities and to formally
report the findings, conclusions, and any additional issues identified during testing along with any
recommendations.
These results become part of the solution's overall collection of documentation and project records.
Controls

•
•
•
•
[A44] Solution Test

Inputs
Solution Test Environment Baseline (From: A443)
A reference point specification of the functional environment used to support testing of a
specific solution.
Solution Test Results (From: A444)
The outcomes (results) of applying the selected test cases to the Solution Build Package.
Outputs
Solution Test Issues (To: A442 A443 A444)
perhaps addressed.
Solution Test Report (To: A45 A454)
process.
[A446] Evaluate Solution Test Performance

Description
The purpose of this activity is to evaluate performance of the project-specific Solution Test (quality
control) activities against defined performance criteria and measures, and to provide input to the
IT Management System Framework.
Controls
•
•
•
•
[A44] Solution Test
Inputs
Solution Test Activity Data (From: A442 A443 A444 A445)
process.
Outputs
Solution Test Evaluation (To: A441)
The effectiveness and efficiency of the practices performed in executing the Solution Test
process.
•
•
•
•
Purpose
The purpose of the Solution Acceptance process is to validate that the proposed solution, either
as individual artifacts or in its complete form, meets acceptance criteria at defined checkpoints
Outcomes
Stakeholders agree before deployment that all requirements have been met
The solution's capability to meet service level agreements is validated
Transition of the solution into live service presents minimum risk
The production environment remains stable and predictable after incorporating this solution
Those responsible for delivering service and support are properly prepared to do so
Scope
ITIL defines acceptance as: “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.” 27
This process operates throughout and beyond the lifetime of a solution realization project. An
instance of examining the acceptance of a service can be triggered post-deployment, perhaps as
part of a pilot rollout.
Includes
Periodic review of solution project performance to date and status in respect of
solution acceptance criteria
Involvement of all relevant stakeholders, such as:
– Solution customer
– Solution developer
– Provider of service for the solution once deployed—this includes operational staff
as well as management
– Interested parties in relation to non-functional concerns, like security, compliance,
conformance to architectural and development guidelines)
– Users
Assisting in the development of approved solution plans and commitments
Obtaining the customer perspective on prototype work products and accepted
solutions
Working with the customer to facilitate acceptance of the solution
Working with the customer to facilitate acceptance of solution shutdown and
retirement
Documenting how the confirmed requirements are met in the accepted solution and in
interim milestones
Identifying and tracking of all acceptance review results and issues

•
•
•
•
Excludes
Testing (Solution Test)
Providing education and training (Deployment Management)
Establishing service levels (Service Level Management)
Controls
contracts (UCs).
included.

•
•
•
•

Inputs
A452)
timeframe.
Solution Test Report (From: A44 A445)
purposes.
Operational Documentation (From: A855)
The subset of knowledge assets that represent the set of material, both externally provided
and internally generated, required to support the development, deployment, operation, and
maintenance of solutions and services.
• ITIL uses the term Operational Document Library to refer to an implementation of this
output.
Outputs
Solution Acceptance Review Results and Issues (To: A452 A453 A455)
The collected set of documentation describing the fit-for-purpose characteristics of the
Solution Acceptance work products, and any issues identified as a result of executing
solution acceptance reviews.
•
•
•
•
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
• Attributes
• Relationships
be deployed.
Activities
•
•
•
•
IT Management Architecture Baselines IT Strategy IT Plan SLAs OLAs UCs
Ecosystem and Roadmaps C4 C5 C3
C1 C2
Establish
Solution
Solution Acceptance
Acceptance Framework
Framework
A451 Solution
Acceptance
Plan
I1
Create O2
Solution Solution Solution
Plans and Acceptance Plans and
Commitments Plan A452 Commitments
Solution
Acceptance
Criteria
Define
I5 Solution
Solution
Requirements Acceptance
Baseline Criteria
A453
I2
Solution
Test
Report Perform
Solution O1
Solution Acceptance
I4 Acceptance Review Results
Solution Design Review and Issues
A454
Certify Solution Acceptance

I8 Solution Certification
Results and Issues
Acceptance O3
A455 CI Data
Update Package
Package
I7 Certified
Operational O4
Documentation/D7 Solution Solution_
A456 Accepted
I6
Security Risk
Assessment/D1
Evaluate
Configuration
Audit Report/D3
Solution Solution
Acceptance Acceptance
Evaluation
I3
Solution Acceptance Performance
Activity Data A457
Solution
Assembly
NODE: A45 TITLE:

Solution Acceptance CURRENT PAGE:
Figure 6. A45 Solution Acceptance
•
•
•
•
[A451] Establish Solution Acceptance Framework
[A451] Establish Solution Acceptance Framework

Description
The purpose of this activity is to tailor in a prescribed way the organization-wide IT Management
Framework (policies, standards, procedures, templates related to Solution Acceptance
management and engineering), and to define specific goals, measurements and targets.
Controls
included.
Inputs
Solution Acceptance Evaluation (From: A457)
The effectiveness and efficiency of the practices performed in executing the Solution
Acceptance process.
Outputs
Solution Acceptance Framework (To: A452 A453 A454 A455 A456 A457)
work flows, inputs, outputs), and technology (software, hardware) practices to be used in
achieving acceptance of the proposed solution.
•
•
•
•
[A452] Create Solution Acceptance Plan

Description
The purpose of this activity is to develop a project solution-specific approach to solution
acceptance and to create the Solution Acceptance Project Plan, in accordance with existing IT
standards and approved methods.
The solution acceptance plan should include provisions to thoroughly address any residual
solution development results and issues.
Controls
Solution Acceptance Framework (From: A451)
Inputs
A452)
timeframe.
Solution Acceptance Review Results and Issues (From: A45 A454)
Outputs
A6 A62 A621 A7 A73 A732 A74 A742)
timeframe.
Solution Acceptance Plan (To: A453 A454 A455)
The (sub) project plan which identifies the approach, activities and tasks, responsibilities,
and schedule for presenting the proposed solution to the stakeholder community for
evaluation and acceptance. Includes identification of stakeholders.
•
•
•
•
Solution Acceptance Activity Data (To: A457)

Performance and quality data regarding activities performed in executing the Solution
Acceptance Process.
[A453] Define Solution Acceptance Criteria

Description
The purpose of this activity is to determine and document the final criteria to be used by the
stakeholder community in evaluating the solution against the Solution Requirements Baseline and,
if necessary, the ability to tolerate known defects in a production implementation.
Controls
Solution Acceptance Plan (From: A452)
contracts (UCs).

•
•
•
•
Inputs
Outputs
Solution Acceptance Criteria (To: A454)
The complete set of criteria that the stakeholder community will use to certify their
acceptance of the solution produced.
For the special case of 'Solution' that is a 'Service', ITIL defines Service Acceptance
Criteria as: “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.”34
Acceptance Process.
[A454] Perform Solution Acceptance Review
Description
The purpose of this activity is to evaluate the tested solution against its acceptance criteria, and to
produce a detailed and thorough analysis of both the resultant solution and its associated
operational documentation.
Any recognized security vulnerabilities and risks should be highlighted in the review results.
Controls
Inputs

•
•
•
•

contracts (UCs).
Solution Acceptance Criteria (From: A453)
The complete set of criteria that the stakeholder community will use to certify their
acceptance of the solution produced.
For the special case of 'Solution' that is a 'Service', ITIL defines Service Acceptance
Criteria as: “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.”38
A452)
timeframe.
Solution Test Report (From: A44 A445)

•
•
•
•

output.
Outputs
Solution Acceptance Review Results and Issues (To: A452 A453 A455)
Acceptance Process.
[A455] Certify Solution Acceptance

Description
The purpose of this activity is to create a formal checkpoint and documentation of stakeholder
acceptance of the as-built solution.
Once consensus is achieved, the accepted solution can be packaged ready for handover and then
begin its migration through Change Management processes to the next environment tier (for
example, from development to test).
Controls
Inputs
•
•
•
•

Configuration Audit Report (From: A545)
The outcomes of a configuration audit. The outcomes cover both status of configuration
items and audit trails of changes to configuration items, such as logs of identities of the
persons making such changes.
Outputs
Solution Acceptance Certification (To: A456)
The record (document) containing the formal certification by authorized, designated
stakeholders that the solution meets acceptance criteria.
Acceptance Process.
[A456] Package Certified Solution

Description
This activity exists to bring together all the solution components (such as modules, builds,
procedures, documentation) which comprise the certified solution in a single physical or logical
package. Packaging ensures that the recipients of the accepted solution either directly receive all
the solution components or are provided with a bill-of-material together with details of how to obtain
the components, or some combination thereof.
Controls
Inputs
Solution Acceptance Certification (From: A455)
The record (document) containing the formal certification by authorized, designated
stakeholders that the solution meets acceptance criteria.
purposes.
Outputs
• Attributes
• Relationships
be deployed.
•
•
•
•

Acceptance Process.
[A457] Evaluate Solution Acceptance Performance

Description
The purpose of this activity is to evaluate the performance of the Solution Acceptance process
activities against defined performance criteria and measures, and to provide input to the IT
Management System Framework.
Controls
Inputs
Solution Acceptance Activity Data (From: A452 A453 A454 A455 A456)
Acceptance Process.
Outputs
Solution Acceptance Evaluation (To: A451)
The effectiveness and efficiency of the practices performed in executing the Solution
Acceptance process.
•
•
•
•
PRM-IT A4 Node Tree
PRM-IT A4 Node Tree
A4 – REALIZATION
A425 Validate Solution Design with Stakeholders
A44 Solution Test
A443 Prepare and Mange Solution Test Environment
Figure 7. A4 Realization Node Tree

•
•
•
•
[A5] Transition
Description
Purpose
change in solutions and services. The processes provide defined and repeatable approaches to
planning, effecting and recording these transitions and can be applied to all stages of the life cycle.
They also serve to maintain control over the Information Technology (IT) resources that are subject
to other process areas related to the management of IT. Using these processes, developments in
IT capabilities supporting the stakeholding businesses and customers achieve their desired
Rationale
Value
infrastructure
services
Implements solutions that provide new functionality, eliminates the root causes of defects
information on managed elements (configuration items (CIs), managed objects, among
others)
Controls
SLA, OLA, UCs (From: A2 A24 A243)
Environment Information (From: Outside-the-Model)
•
•
•
•
Inputs
Solution_ Accepted (From: A4 A45 A456)
CI Requisition (From: A4 A42 A423 A424 A43 A433 A434 A44 A444)
A452)
CI Data Update Package (From: A4 A42 A424 A43 A433 A434 A435 A436 A437 A44 A444
A7 A75 A753 A754)
Service Request_ Authorized (From: A6 A61 A613)
Change Request (From: A2 A23 A232 A3 A35 A355 A4 A42 A422 A43 A432 A44 A442
A74 A744 A745 A75 A752 A754 A76 A765 A766)
Outputs
Change Schedule (To: A514 A516 A517 A52 A522 A525 A54 A543 A545 A6 A63 A632
A66 A665 A7 A74 A744 A745 A75 A752 A753)
Solution_ Deployed (To: A3 A32 A4 A43 A433 A44 A443 A6 A62 A63 A634 A64 A641 A7
A76)
Change Information (To: A2 A23 A233 A235 A3 A35 A355 A513 A514 A515 A516 A517
A764)
Configuration Information (To: A3 A33 A336 A4 A42 A422 A423 A424 A44 A442 A443 A51
Asset Information (To: A54 A543 A7 A71 A713 A72 A724 A8 A81 A812 A814 A815)
Asset Deployment Items and Data (To: A4 A43 A51 A52 A522 A523 A524 A53 A534)
CIs (To: A4 A43 A434 A44 A444)
Processes
•
•
•
•
Service IT Strategy SLAs OLAs UCs IT Management Architecture Baselines IT Plan Compliance Plans IT Budget Environment
Catalog Ecosystem and Roadmaps Regulations
C3 C5 C2 and Controls C8 Information
C4 C6 C1 C9 and Standards/D3
C7
O7
Project Proposal
I12
Change
Request
Change O3
Management Change
I3 Information
Solution Design
A51 Change Implementation

Release Communication
I6 Acceptance
Product Package Release O1
Change Change Schedule
Strategy
Solution Design
Release Request/S1
I4
Management
Solution
Plans and A52 O2
Commitments Implementation
Release Solution_
Progress Data Deployed
Acceptance Release
I10
Request
Service Resilience
Plans
Release Notice Deployment O5
Management Incident
I1
Solution_
Accepted A53 Customer
Asset Deployment
Satisfaction Issue/S2
Operational Inquiries
Schedules/D2 and Requisitions O9
CIs
I5 Configuration
Project Plan Configuration
Management Baseline Report
I7 O4
CI Data Configuration
Update Package A54 Information
I2
CI Requisition O8
Asset Deployment
Configuration Items and Data
Information Asset
Request Management
I11
Service Request_ O6
Authorized A55 Asset Information
I8
Underpinning
Contracts
I9
IT Financial
Reports
NODE: A5 TITLE:
Transition CURRENT PAGE:
Figure 1. A5 Transition Diagram
•
•
•
•
Purpose
The purpose of the Change Management process is to achieve the successful introduction of
changes to an IT system or environment. Success is measured as a balance of the timeliness and
completeness of change implementation, the cost of implementation, and the minimization of
disruption caused in the target system or environment. The process also ensures that appropriate
details of changes to IT resources (assets, CIs) are recorded.
Basically, a change is anything that alters the status of a configuration item (CI). This typically
includes anything that adds to, deletes from, or modifies the IT environment. The definition of a
change is the addition, modification or removal of approved, supported or baselined hardware,
network, software, application, environment, system, desktop build or associated documentation.
A change request (for which RFC is an established synonym) is the means for documenting
proposed change and actual change activity in IT resources or capabilities. Change requests can
be triggered for a wide variety of reasons, from a wide variety of sources. Change requests can be
concerned with any part of the infrastructure or with any service or activity.
Outcomes
As a result of the successful implementation of the Change Management process:
Changes are introduced in a timely and controlled manner
Proposed changes are not approved nor introduced without an accurate assessment of
their costs and other effects
Incidents resulting from the introduction of changes are minimized
Service quality is measurably improved
Appropriate balance is maintained between the business need to deploy innovation and the
need to maintain the stability of IT service
Scope
Change Management typically begins with the creation of a Change Request (RFC). The change
request documents details of the proposed change in order to support a range of business and
technical assessments, leading to approval (or rejection) and ultimately to application of the
change.
The Change Management process represents a pattern of activities and work flow, which can be
implemented over a range of contexts. The most prominent contexts include operations and
development. Operations Change Management and Development Change Management are
similar in a number of ways, including recording of all change requests, assessment of all change
requests prior to approval, a team-based approach to change approval, and review of change
effectiveness. However, they are different in a number of ways:
Development Change Management addresses changes proposed to a system under
development. These changes may include requests for new functionality, patches, or
redevelopment. In contrast, Operations Change Management focuses on changes to
operational CIs in the entire IT infrastructure. These changes can include capacity tuning,
asset transfer, and system resets.
Changes are assessed and approved using a team. Each context typically has its own
change board and membership, addressing different types of changes, and using different
assessment criteria. In development, the team is often known as the Change Control
Board; in ITIL, the term Change Advisory Board is used. A higher level board can be
established to ensure integration of changes across contexts.
•
•
•
•
Change Management can appear in other contexts besides operations and development. There
can be a single implementation of the Change Management process or several, with each
implementation covering the scope of a defined context. Factors such as size of the organization
and different start and end points defining a change can lead to multiple implementations of
change management, with each following the process principles and pattern described but
employing procedures and decision criteria customized for their context.
This process establishes classification and categorization schemes to assist with change
assessment activities. It also defines the implementation approaches that will be assigned to
approved changes in order to standardize the supervisory control levels, consistent with the
assessment recommendations. ITIL, in the context of managing production environments, uses
the term Change Model for these schemes.
Definition of Change Model: “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).”1
Examples of change models:
A standard change is “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.”2
An emergency change is “A Change that must be introduced as soon as possible. For
example to resolve a Major Incident or implement a Security patch.”3
For software development, there will frequently be different change types based on the
impact to the overall system, and hence requiring different levels of approval, such as
architectural change as compared with scope change, and change that is local to one
component.
Some activities in the process require examination of several or all changes collectively rather than
on an individual basis. For example, scheduling changes for implementation requires
consideration of the other changes planned for the same dates and target environments in order
to identify conflicts.
Includes
Planned changes, standard changes (pre-approved by policy), and emergency
changes (policy exception request)
Establishing both recurring and one-time only schedules (change windows) during
which changes can be performed without negatively affecting commitments, such as
project schedules, projected availability, or SLA commitments
Enforcement of standard methods and procedures from request for change through
post implementation review
Establishing regular meetings and communication schedules to evaluate proposed
changes and schedules
Control and management coordination of the implementation of those changes that
are subsequently approved
1. ITIL V3 Glossary
2. ITIL V3 Glossary
3. ITIL V3 Glossary
•
•
•
•
Maintenance of open channels of communications to promote smooth transition when

changes take place
Increased visibility and communication of changes to both business and support staff
Excludes
Requirements Management (Stakeholder Requirements Management)
Creation of new or revised functionality (Realization category processes)
Building the packaging for the delivery of new or revised functionality (Release
Management)
Technical implementation, such as distribution, preparation, installation, and back out
if necessary (Deployment Management)
Configuration Management, although the interface to this process must be managed
Asset Management, although the interface to this process must be managed
Business transformation and organizational change (IT Customer Transformation
Management)
Controls
included.
contracts (UCs)
4. ITIL V3 Glossary
•
•
•
•
compliance
A point-in-time snapshot of a portion of a CMDB that is relevant to one or more purposes
from other IT management processes. This can include past, current, and future projected
instances.
Inputs
A74 A744 A745 A75 A752 A754 A76 A765 A766)
5. ITIL V3 Glossary
6. ITIL V3 Glossary
7. ITIL V3 Glossary
•
•
•
•
Operational Schedules (From: A621)

The overall schedule for individual work items and when they are processed. Examples are
start and stop times of specific applications, availability of specific services and
infrastructure services (file transfer).
The set of work plans. Work plans can include management, human resource, technical
environment, project quality, communications management, among others.
Implementation Progress Data (From: A375 A52 A523 A524 A53 A535 A536 A635)
change or release.
Release Acceptance Request (From: A52 A524)
A request for final approval from Change Management for a release to be able to proceed
to rollout. The request will be accompanied by evidence of the release having passed its
acceptance criteria.
Outputs
A764)
for allocation of assets, and notifications to trigger the delivery or distribution of these
resources.
Change Implementation Communication (To: A375 A52 A522 A523 A524 A53 A535 A536
A54 A542 A543 A635 A655 A665)
Information used to coordinate and implement a change.It can reflect either or both the:
•
•
•
•
A66 A665 A7 A74 A744 A745 A75 A752 A753)
implemented.” 8
• Attributes
• Relationships
Release Acceptance (To: A52 A524 A525)
The notification of approval that the release can proceed to its rollout activities.
Change (To: A412 A516 A517 A518 A52 A522 A53 A532 A54 A543 A753)
Activities
A514 Assess Change
8. ITIL V3 Glossary
•
•
•
•
IT StrategyIT Management Compliance Plans Service Architecture Baselines Configuration

IT Plan SLAs OLAs UCs
C5 Ecosystem and Controls Catalog and Roadmaps Baseline Report
C2 C3
C6 C7 C1 C4 C8
Change Management
Framework
Establish
Change
Management Change
I1 Change Request_
Framework Request_ Rejected
Change A511 Create Recorded
Request
and Change Assessment
Record Information Request
Change_
Change Categorized
I3 Request O1
Project Plan A512 Project Proposal
I4 Accept Projected Service Outage
Solution Design
and
I6
Categorize O5
Configuration Change Schedule
Information Change
A513 Change_ O9
Assessed Change
Assess O8
Change Release
Change Assessment Acceptance
Information O4
A514
I2 Change Implementation
Asset Availability
Operational
Information/D1 Authorize Communication
Schedules/D2
and
I5 Schedule O3
Asset Deployment Change Asset Deployment
Items and Data A515
Asset Requisition Standard Inquiries
Status/D1 Change Coordinate and Requisitions
Change
O7
I8 Implement CI Data
Release ation
A516 Update Package
Acceptance Change_
Request Change_ Review Closed
Implemented and O6
Close Incident
I7 Change Asset Data
Implementation A517 Update Package/S2
Progress Data Monitor and
Report O2
Change Change
Change Status and Management Information
Information Request
A518 Evaluate
Change Change
Deployment
Reports/D2
Change Management Performance Evaluation
Service Request Activity Data A519
Reports/D1
NODE: A51 TITLE:

Change Management CURRENT PAGE:
Figure 2. A51 Change Management
[A511] Establish Change Management Framework

Description
This activity defines the way Change Management will be managed and controlled. It defines the
rules by which Changes can be allowed to flow through the Change Management Process, and
takes into account other functions that will be affected by the Change Management process, such
as Configuration Management.
This activity facilitates the creation of a Change Management Framework, which is essential in
ensuring that changes that are introduced to a live environment are done so with mitigated risk,
and with minimal or no disruption.
It creates and maintains the scope, policies, standards, responsibilities, and procedures of
the Change Management process. This includes defining change models, determining
relationships with other processes, change request specifications, and the composition of
the change advisory board (CAB).
It also carries out the assignment of roles and responsibilities.
This is not a one-off activity. It should be undertaken periodically to ensure that the framework
remains suitable for the business, and it should take into account changes to the size of the
organization, service levels, business, IT strategies, and operational plans.
•
•
•
•
Controls
included.
compliance
contracts (UCs)
9. ITIL V3 Glossary
•
•
•
•
Inputs
Change Management Evaluation (From: A519)
Outputs
Change Management Framework (To: A233 A234 A512 A513 A514 A515 A516 A517 A518
A519 A611 A641)
The policies, procedures, organizational roles and responsibilities, and other information
[A512] Create and Record Change Request

Description
The activity of formulating and storing the information about any proposed or after-the-fact change.
The request will contain a defined outline of informational sections which have been established
as necessary in order for it to be progressed into assessment and the further activities of Change
Management. Information can vary depending upon the context, scale, and potential impact of the
requested change.
Controls
Inputs
A74 A744 A745 A75 A752 A754 A76 A765 A766)
Outputs
Change Management Activity Data (To: A519)
Change Request_ Recorded (To: A513 A518)
The details of a change request, captured in a document or other format defined by the
Change Management Framework.

•
•
•
•
[A513] Accept and Categorize Change

Description
This activity begins with the examination of the change request to determine if it can be accepted
for consideration. To accept a change request all required information must be logged; omitted or
incomplete information can cause a change request to be returned. The return of the change
request will usually indicate that the request can be re-submitted if the missing or inadequate
information is provided. After initial acceptance, the change request is categorized. Categorizing
consists of identifying whether the change request fits categories such as:
Standard change typically pre-approved
Normal change requiring control using the designed, preferred Change Management
process and procedures
Exception change (such as an emergency change) requiring Change Management control
but under non-preferred circumstances
ITIL suggests that each categorization can have an associated change model, defined as: “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).”12
Finally, the change request is assigned to the appropriate roles, functions or teams, to evaluate the
change.
Change requests that are out of scope or not within policy are rejected. In these cases, the
submitter might be guided to present their request as a new requirement.
Standard changes are sent for implementation.
The remaining change requests are marked for assessment, and routed according to their
content and categorization.
Controls

•
•
•
•
Inputs
Change Request_ Recorded (From: A512)
Outputs
Change Request_ Rejected
Any change request which has been rejected, and sent back to the requestor. Reasons for
rejection include:
• Lack of authorization or funding
• The change requested is beyond the scope of Change Management (for example, it is a
new requirement)
• The change request is incomplete or in error
• The change request has been assessed as having too high a risk and needs rework
Change_ Categorized (To: A514 A518)
The change request, which has completed acceptance, is now recognized as a change.
The categorization indicates the types and levels of assessment needed.
Standard Change (To: A516)
Those changes that have been pre-approved for deployment. They include well known and
proven tasks, and have limited (and well understood) or no impact on the integrity of the
target context, such as the infrastructure. These changes will also have all entitlement
issues, like financial approvals, and licensing already resolved.
Implementation can be either user-driven or managed by the IT function. Examples
include:
• Installation of printer drivers from a pre-installed library on a PC
• Downloading and installation of software or fixes from vendor sites
• Upgrading a laptop to a larger hard drive
•
•
•
•
[A514] Assess Change

Description
This activity analyzes each change to determine its impact on existing and planned CIs as well as
the impact on resources required to build and deploy the change. This involves identifying the
appropriate change model for handling the change, scheduling a CAB meeting if specified by the
change model, and obtaining a complete set of analysis results and issues.
In this activity, the impact of a change is evaluated from both the IT and business perspectives,
ensuring that the change can be successfully implemented with a minimal impact to committed
services and still meet business requirements.
This activity allocates priority based on urgency, and if the change is for the resolution of a problem,
the priority will also reflect projected impact. Assessment often assigns impact categorization
classes such as minor, significant, or major.
Controls
contracts (UCs).

•
•
•
•

instances.
Change Schedule (From: A5 A51 A515 A516)
implemented.”17
Inputs
Change_ Categorized (From: A513)
Change Assessment Information
Any information about the potential impact or risks relating to a change, including input
from the business and from any other relevant process within IT.
Asset Availability Information (From: A552)
Details of the ability of the subject IT asset or assets to be made available for deployment
or development use. The details will include:
• Quantities
• Specifications
• Dates
• Locations.
Outputs
Request for Change Assessment Information Request
A request to any relevant party to provide information that will contribute to the assessment
of a change.

•
•
•
•

resources.
Change_ Assessed (To: A515 A518)
The change, including the collection of assessment recommendations.
[A515] Authorize and Schedule Change

Description
This activity represents a decision checkpoint against the change based on impact. It examines
the analysis results from Assess Change and determines whether to approve the change.
If approved, the change deployment approach and targeted change deployment schedule are
determined for the change. Approval types can include financial, technical, and business, all of
which can be considered by any body approving the change. The manner in which the change is
approved will depend on the organization structure, but formal approval will be obtained for each
change from the change authority (CA). This can be Change Management, Service Management,
or some other nominated person or group.
If a solution does not exist, one can be requested (through Project Proposal) before the change is
approved. If a solution does exist, a change can then be scheduled.
The activity for scheduling a change takes into account the Change Schedule, eliminating conflict
between differing changes, and assigning appropriate resources accordingly. Approved changes
can be subsequently scheduled into target releases, in line with the policy for determining releases.
The result is an updated Change Schedule, containing details of all approved changes and their
implementation dates, along with the Projected Service Availability document, containing details of
changes to agreed service level agreements and service availability.
Controls
contracts (UCs).
•
•
•
•
Inputs
Change_ Assessed (From: A514)
Asset Requisition Status (From: A552)
The acknowledgement, including status information such as expected dates, that a
requisition for one or more assets has been received and processed.
Outputs
Change Request_ Rejected
Any change request which has been rejected, and sent back to the requestor. Reasons for
rejection include:
• Lack of authorization or funding
• The change requested is beyond the scope of Change Management (for example, it is a
new requirement)
• The change request is incomplete or in error
• The change request has been assessed as having too high a risk and needs rework
Projected Service Outage (To: A244 A734)
Activities and Test Plans on agreed Service Levels.” 21
A66 A665 A7 A74 A744 A745 A75 A752 A753)

•
•
•
•
implemented.” 22
resources.
Change (To: A412 A516 A517 A518 A52 A522 A53 A532 A54 A543 A753)
[A516] Coordinate Change Implementation

Description
This activity takes an approved change and coordinates its implementation. If the approved
change involved creating or updating a solution, then the solution components must first be built
and supplied by Solution Realization.
Approved changes are made available primarily through Release Management, but some changes
are implemented through assignment by the Change Manager (within Change Management). This
determination is made by Change Management policies and the appropriate change model.
Change Management monitors the actual deployment of the change, as carried out by Deployment
Management.
Controls
instances.
Inputs
implemented.”23

•
•
•
•

Standard Change (From: A513)
Those changes that have been pre-approved for deployment. They include well known and
proven tasks, and have limited (and well understood) or no impact on the integrity of the
target context, such as the infrastructure. These changes will also have all entitlement
issues, like financial approvals, and licensing already resolved.
Implementation can be either user-driven or managed by the IT function. Examples
include:
• Installation of printer drivers from a pre-installed library on a PC
• Downloading and installation of software or fixes from vendor sites
• Upgrading a laptop to a larger hard drive
available using standard reports or to meet individual requests. (From: A52 A524)Release
Acceptance Request
change or release.
Outputs
A66 A665 A7 A74 A744 A745 A75 A752 A753)
implemented.”24
Release Acceptance (To: A52 A524 A525)
The notification of approval that the Release can proceed to its rollout activities.
Change Implementation Communication (To: A375 A52 A522 A523 A524 A53 A535 A536
A54 A542 A543 A635 A655 A665)

•
•
•
•

resources.
• Attributes
• Relationships.
Asset Data Update Package (To: A553)
All status and detail changes to an asset after the initial creation. Includes lease, license,
maintenance changes and, at end of life, disposal notification. An additional example is a
change in standard currency exchange rates from the IT Financial Management process.
Change_ Implemented (To: A517 A518)
The history and record of the change implementation activity which has culminated in the
completion of the change related to the change request. It also includes the case of a failed
implementation, with any back out results.
[A517] Review and Close Change

Description
This activity contains the tasks involved in reviewing all implemented changes, after a predefined
period has elapsed or another review trigger has been activated. It ensures that the change has
had the desired effect and met its objectives, and that users and customers are content with the
results, or to identify any shortcomings. The review activity determines whether the implementation
plan and the back-out plan worked correctly, and whether the change was implemented on time
and to cost. It determines whether any follow up action (such as the creation of a new change
request) is required.
A formal close of the change is performed. The closure of a change includes updating other
process areas of the status of the change.
Controls
•
•
•
•
Inputs
Change_ Implemented (From: A516)
implemented.”25
Outputs
Change_ Closed (To: A518)
The change having completed all parts of the change life cycle, and reached closed status.
[A518] Monitor and Report Change Management

Description
This activity is responsible for looking over all changes, whether active or closed, and being able
to provide information on the status and details of one or many changes. The other activities in
Change Management each update change data maintained in change records, defined in ITIL as:
“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.”26
The information can be provided in an ad hoc manner or using predetermined reports. This scope
is inclusive of the other parts of Change Management. In addition, it examines detailed information
and summary statistics about the volumes, success rates, and issues with the workings of changes
outside this process:
The deployment activities coordinated by Change Management
Standard changes (so those changes not requiring direct Change Management
coordination)

•
•
•
•
Controls
Inputs
Change_ Closed (From: A517)
The change having completed all parts of the change life cycle, and reached closed status.
Change_ Implemented (From: A516)
Change_ Assessed (From: A514)
Change_ Categorized (From: A513)
Change Request_ Recorded (From: A512)
Change Status and Information Request
A request for the current status of a change within the control of Change Management.
Deployment Reports (From: A538)
Report about how well deployments are progressing or have been completed.
Outputs
A764)
•
•
•
•
[A519] Evaluate Change Management Performance

Description
This activity describes the tasks required to assess the efficiency and effectiveness of the Change
Management process. It includes the capture of information on change records, the relationship
with other process areas, and the suitability of procedures and training. It is used as a basis to
ensure the Change Management process remains fit for purpose and identifies where changes to
the process might be required. Examples of topics addressed include:
Assessing the Change Advisory Board (CAB) and its effectiveness
Analyzing policies and procedures
Analyzing rejected change requests
Analyzing change failures
Analyzing change successes
Controls
Inputs
Change Management Activity Data (From: A512 A513 A514 A515 A516 A517 A518)
Outputs
Change Management Evaluation (To: A511)
•
•
•
•
Purpose
The purpose of the Release Management process is to prepare and finalize release packages that
are fit for deployment so that optimal business value will be attained when deployment occurs.
Definition of release: “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.” 27
Outcomes
As a result of the successful implementation of the Release Management process:
Release packages – whether supporting new business capability, improvement in cost
performance, or other advances in service quality - form the basis for deployment
Deployment risks to existing service quality are minimized
Customer and user satisfaction upon release deployment is increased
All implications to the parties involved in deploying or receiving a release are identified and
validated prior to the deployment event
Only authorized releases are introduced into the live environment
Scope
Release Management spans the planning and direction of the rollout of software, hardware, and
operational processes including related documentation, and operating procedures. The changes
that comprise the release are managed by Change Management, and their inclusion in the release
can be determined by time, technology interdependencies, target, risk mitigation, organization,
scale (multiple copies) or service dependencies. The design of the release will need to consider
how rollout is achieved. For example, whether or not the release can be requested by a user using
a self-service selection and then installed automatically and transparently.
Includes
Release design, creation, and testing
– For example, implementation scripts
Specifying the deployment model for a release. The deployment model provides a
template of the activities and plans from which specific deployment instances can be
customized for geography, scale, local conditions, and other factors
Checking and testing training materials and incorporating them into the deployment
model
Verification of successful release package installation, including ensuring that the
integrity of function has been maintained
Roll back (also known as back out) mechanisms and procedures
Excludes
Solution Realization (creation of functionality, usage procedures, training materials,
and any other release deliverable) (Realization category)

•
•
•
•
Testing of solution functionality (Solution Test)

Management of change requests (Change Management)
Deployment of release packages (Deployment Management)
Controls
implemented.”28
contracts (UCs).

•
•
•
•
compliance
instances.
Inputs
Release Acceptance (From: A51 A516)

•
•
•
•

A452)
timeframe.
be deployed.
Outputs
Solution Design Request (To: A42 A422)
resources.
•
•
•
•

• Attributes
• Relationships
Release Strategy (To: A523 A524 A525 A526 A53 A532 A533 A534 A535 A536 A537
A538)
The overall approach that will guide the release through its complete life cycle, and into
deployment. It includes the plan for creating a release, including the definition of the set of
changes which are collected within it, and also the release test plan.
Release Notice (To: A53 A534 A535)
The notices and other communications material, about a release, that is made available to
both users and IT staff impacted by the release. Contents will range from general
awareness announcements through specific details, such as training schedules and plans,
to actual release documentation and training material. They are updated as experience is
gained about the release.
Release (To: A53 A532 A533 A535 A536)
The packaging of one or more solutions along with all the materials (scripts,
documentation, for example) needed for successful deployment.
In ITIL, Release is defined as “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.”33
change or release.
Release Acceptance Request (To: A51 A516 A525)
Activities

•
•
•
•
Compliance Plans IT Plan IT Management Service Architecture Baselines Configuration SLAs OLAs UCs Change Schedule
and Controls C6 Ecosystem Catalog and Roadmaps Baseline Report C4
C7 C2 C3 C5 C8 C1
Release
Management
Framework
I8
Project Plan
I12
Establish O2
Release Asset Deployment
Service Resilience
Inquiries
Plans Management and Requisitions
I4
Framework
A521 O7
Product Package Implementation
Progress Data
Plan
I3 Release
Change O4
Strategy Release
Strategy
I7 A522
Operational O1
Solution Design
Schedules/D2
Request/S1
I6 Design and
Solution Build
Plans and
Commitments
Release O3
CI Data
I5 A523 Update Package
Solution Design
O8
I10
Solution_ Release Release
Accepted _Built Test and Acceptance
Operational Verify Request
Documentation/D9 Release O6
Release
I11 A524
Configuration O5
Information Release Notice
I9 Release
Asset Deployment Revision Request Monitor and
Items and Data Report
I2 Release
Release Release Reports
Acceptance
A525
Deployment
Reports/D1
Review and
Close Release_
Closed
Release
Results and Trends/D2 A526
I1 Release Review Results Evaluate

Change Implementation Release Release
Communication Management Management
Evaluation
Release Management Performance
Activity Data A527
NODE: A52 TITLE:

Release Management CURRENT PAGE:
Figure 3. A52 Release Management
[A521] Establish Release Management Framework

Description
A framework and guidelines for Release Management are developed based on business and IT
strategy. The tasks in this activity include:
Understanding the requirements and specifications for Release Management practices
Enacting the strategy for Release Management automated support
Defining evaluation criteria for Release Management solutions and services
Establishing the framework for Release Management by defining and implementing
Finally, the structure and process of Release Management including escalation responsibilities
have to be communicated to the process users.
The establishment of the process framework also includes the continuous improvement of Release
Management, meaning the consideration of the Release Management process evaluation and the
Controls
•
•
•
•

compliance
Inputs
Release Management Evaluation (From: A527)
Outputs
Release Management Framework (To: A522 A523 A524 A525 A526 A527)
This framework describes:
• Types of releases
• Naming and other release conventions
• Release policies and procedures
• Definitive Media Library (DML) specifications
• Roles and responsibilities
• Scheduling policies
• Process review schedule.
This framework provides governance information for the other activities in Release
Management.
•
•
•
•
[A522] Plan Release Strategy

Description
This activity determines the strategy for how each release is defined and then brought into
existence in a state ready for deployment. It includes understanding the constituents of the release
(from one or more Service Packages) and then considering the impact of the one or more
authorized changes, which relate to the release contents in order to create the overall plan for the
release. The planning covers building, testing and verifying the release (including the possible
need for pilot deployments), as well as establishing a model for how the finalized release should
be deployed.
Controls
Release Management Framework (From: A521)
Management.
instances.

•
•
•
•

contracts (UCs).
implemented.”38
Inputs

•
•
•
•

A452)
timeframe.
Release Review Results (From: A526)
Analysis of release usage, with identification of successes and areas for release
improvement.
Release Reports (From: A525)
Reports showing the outcome of the release implementations.
Release Revision Request (From: A524)
Identification of a need to re-plan a release following the outcomes of test and acceptance
work.
Outputs
resources.
Release Strategy (To: A523 A524 A525 A526 A53 A532 A533 A534 A535 A536 A537
A538)
The overall approach which will guide the release through its complete lifecycle, and into
Release Management Activity Data (To: A527)
•
•
•
•
[A523] Design and Build Release

Description
This activity determines what needs to be built for the release and how it will be assembled and
deployed. During this activity, the release build, installation, and rollback scripts are designed at a
high level. In addition, software and hardware components are obtained for the build activity and
the test environment is put in place.
After the release has been designed, this activity builds the scripts and other aspects needed to
assemble and to deploy the release. This includes
Creating the build environment
Creating build, install, and rollback scripts
Placing software in the DML
Creating support, training, and deployment documentation
Updating the CMS with information about the release package
Controls
Release Strategy (From: A52 A522)
The overall approach which will guide the release through its complete lifecycle, and into
Management.
instances.
Inputs
•
•
•
•
be deployed.
output.
Release Revision Request (From: A524)
work.
Outputs
resources.
change or release.
•
•
•
•

• Attributes
Release _BuiltRelationships. (To: A524 A526)
The release ready for testing.
[A524] Test and Verify Release

Description
This activity takes the built release package and tests to determine if installation, configuration, and
rollback work properly. If successful, the release is ready for deployment. If not, the release must
go through another round of either design or build, and a subsequent retesting.
After testing, the release package is either accepted or rejected.
Controls
Management.
instances.
Inputs
Release _Built (From: A523)
•
•
•
•

Outputs
resources.
change or release.
Release Acceptance Request (To: A51 A516 A525)
Release (To: A53 A532 A533 A535 A536)
entity.”39
Release Revision Request (To: A522 A523)
work.

•
•
•
•
[A525] Monitor and Report Release

Description
This activity monitors the progress of the release as it might be updated and throughout its
deployment instances, and produces the required reporting. The reports provide both users and IT
staff with the communications material such as general awareness, training schedules and plans,
actual release documentation, and training content.
Controls
Management.
contracts (UCs).

•
•
•
•
implemented.”43
Inputs
Release Acceptance Request (From: A52 A524)
Outputs
Release Notice (To: A53 A534 A535)
Release Reports (To: A522 A523 A526)

•
•
•
•
[A526] Review and Close Release

Description
This activity examines the information relating to the usage of a release in order to identify what
has worked well and what has not. For the latter, it works to identify improvements in any aspect
of the release. These aspects can include:
Success rates from deploying the release
Efficiency, in both people and technical resource, in deploying the release
User feedback on missing and erroneous documentation and usage guidance
This activity includes checking the actual performance and outcomes of the new or changed
service against the requirements.
When the Release Strategy indicates that a particular release is to be closed (in other words, no
longer be available for deployment), this activity will perform the tasks associated with achieving
that objective.
Controls
Management.
Inputs
Release _Built (From: A523)
Outputs
•
•
•
•
• Attributes
• Relationships
Release_ Closed
Information and technical content related to the closure of a release.
Release Review Results (To: A522)
Analysis of release usage, with identification of successes and areas for release
improvement.
[A527] Evaluate Release Management Performance

Description
This activity looks at the performance of the Release Management process and identifies
improvement opportunities for the Release Management Framework. This includes examining:
Adequacy of release management resources
Rejected or failed releases
Trends in the effectiveness and efficiency in managing releases
Release Management policies and procedures
Controls
Management.
Inputs
Release Management Activity Data (From: A522 A523 A524 A525 A526)
Outputs
Release Management Evaluation (To: A521)
•
•
•
•
Purpose
The purpose of the Deployment Management process is to place releases and other desired
changes into their target environments, and to activate them in order that the functionality and
operational improvements they contain can create their intended value.
Definition of Deployment: “movement of new or changed hardware, software, documentation,
Process, etc to the Live Environment.”44
The other desired changes includes transferring the responsibility for any subset of an IT
endeavor’s operations from ownership by one service provider to another, while maintaining
service continuity. For certain such transfers, deployment involves managing the effective transfer
of resources necessary to deliver the service. Resources include staff, technology infrastructure,
and intellectual capital.
Outcomes
As a result of the successful implementation of the Deployment Management process:
New capability is introduced on a timely basis, and with minimized risk, disruption and cost
Transfers of service responsibility are effected on a timely basis, and with minimized risk,
disruption and cost
All parties involved in a deployment (for example, users of the capabilities being deployed,
service providers performing the deployment) are appropriately prepared, trained and
skilled to ensure successful deployment
In the event of failures during deployment, contingency plans ensure the expected level of
service quality is delivered
Scope
Deployment Management is primarily triggered by an instruction to roll out any approved
combination of software, related hardware, documentation, and operating procedures to one or
more defined targets (for example: systems, user groups) within constraints such as cost and time.
An alternative trigger for the instantiation of Deployment Management relates to the transfer of the
responsibility for one or more services between providers or across business or organizational
boundaries. At the other end of the scale, the implementation work related to a change which
impacts a single CI is also performed by this process.
The completion of each deployment is indicated when the stakeholders affirm that the expected
outcomes of a deployment are achieved and a business-as-usual operational service state has
been attained.
Includes
Deployment planning and co-ordination with affected parties
Identification of resources (hardware, software, processes and procedures, and staff)
to be deployed, or to be transferred between service providers
Creating capabilities and procedures to support deployment activities, and to verify
the readiness of and account for resources impacted
Creating a plan for continuity of service

•
•
•
•
Execution of the deployment plan, including:

– Electronic distribution of software and other soft-copy items
– Invoking logistical movements for physical items
– Installing technical resources
– Activating the desired configuration
– Testing the installation against defined criteria (as provided in the Release Package
and Change)
– Back out of installed items, when needed
– Delivering training
– Providing initial user assistance
Assessment of readiness to begin service delivery, and for handover to business-as-
usual
Management of risks and issues related to the deployment activities.
Excludes
Logistics and movement of physical assets (Asset Management)
Preparation and commissioning of the supporting environment (Facilities
Management)
Accounting for capital transfers and deployment expenditures (Financial
Management)
Program and project management techniques (Program and Project Management)
Achievement of business benefits from new functionality (IT Customer Transformation
Management)
Updates to the CMS (Configuration Management)
Knowledge and skill transfer (Knowledge Management)
Controls
•
•
•
•
contracts (UCs).
compliance
Inputs

•
•
•
•

Release Notice (From: A52 A525)
Release (From: A52 A524)
entity.”49
be deployed.
target.

•
•
•
•

Outputs
A76)
resources.
• Attributes
• Relationships.
change or release.
Activities
A534 Perform Transition Administration
•
•
•
•
IT Plan IT Management Compliance Plans IT Budget Release SLAs OLAs UCs Deployment
C3 Ecosystem and Controls C5 Strategy Management
C2 C6 C1 C4
Framework
I10 Deployment
Project Plan Program Plan
Establish
I1
Service Deployment
Catalog Management
I5 Framework O3
Change A531 Solution Design
Request/S1
Plan
O5
Deployment Asset Deployment
I6
Service Resilience
Program Inquiries
Plans and Requisitions
A532 Deployment
Capabilities
Prepare
I9 Deployment
Operational
Schedules/D2 Capabilities Deallocated Assets/S1
I7 A533
Solution_
Accepted Perform Asset Data
I3 Transition Update Package/S3
Release Notice
I11
Asset Deployment
Administration Security Work Request/S1
Items and Data A534 Identity and Access
Work Request/S1
Perform
I12
Configuration
Deployment
O6
Information CI Data
A535 Update Package
I8 Deployment Verify O7
Service Request_ Solution_
Items Installed Deployment Implementation
Authorized
and Activate Progress Data
Service O1
A536 Solution_
Review Deployed
I4 and Close O2
Release Deployment Incident
Rework Need Deployment
O4
Security Response/D3 Customer
A537
Identity and Satisfaction Issue/S2
Monitor and Deployment
Access Response/D2
Report Reports
I2
Deployment
Change Implementation Deployment Program
Communication Records A538
Evaluate
Deployment
Management
Deployment Management
Activity Data
Performance
A539
Deployment
Management
Evaluation
NODE: A53 TITLE:
Deployment Management CURRENT PAGE:
Figure 4. A53 Deployment Management
[A531] Establish Deployment Management Framework

Description
This activity involves creating or updating the Deployment Management Framework. It addresses:
Policies and procedures
Roles and responsibilities
Technical standards
Deployment models
Process measurements and controls
Process review schedule.
This framework provides governance information for the other activities in Deployment
Management.
Controls
•
•
•
•

compliance
Inputs
Deployment Management Evaluation (From: A539)
An analysis of deployment management activity data providing an understanding of the
current success or failure of the deployment management process, and an identification of
potential process improvements.
Outputs
Deployment Management Framework (To: A532 A533 A534 A535 A536 A537 A538 A539)
This framework describes the policies, procedures, organizational roles and
responsibilities, and other information under which the Deployment Management process
will operate to meet its mission and goals.
Management.
[A532] Plan Deployment Program

Description
In this activity, the deployment plan details are generated concerning specifically what will be done
during deployment. This includes:
Assignment of individuals to specific activities
Detailed sequence of events
Specifications of requirements (number, type) for assets to be ordered and delivered as
part of each deployment event
Identification of the CIs installed, changed, and removed
Multi-site plans
Restoration plans
Plans for communicating the deployment to stakeholders
Generating release notes for users
Deployment plan details will vary depending upon the type of deployment. Deployment types
include:
Rollouts involving site preparation, siting and installation of physical machinery, and other
activities requiring on-site availability of deployment personnel
Software distribution, both
•
•
•
•
• Pushed from a deployment control point

• Pulled for example, by a user invoking a download and install
Education and training events in support of technology introduction
Transfer of responsibility between providers (with or without any alteration in service
content or quality)
Controls
Deployment Management Framework (From: A531)
Management.
contracts (UCs).

•
•
•
•
Inputs
entity.”54

•
•
•
•
Outputs
Deployment Program Plan (To: A533 A534 A535 A536 A537 A538)
The set of plans for achieving the deployment of an identified set of information technology
capabilities. Items covered include:
• Specification of coordinated deployment tasks and procedures to move new or changed
hardware, software, documentation, process, to the target environment
• Rollout timetables for deployments that are repeated, and associated logistical plans
• Identifying personnel resources necessary to achieve each deployment event, and
obtaining commitments for their availability
The deployment program will cover aspects such as locations, target systems, dates,
persons affected (both users and IT service provider staff), required communications, and
training plan.
Deployment Management Activity Data (To: A539)
Deployment Records (To: A538)
A set of records containing the details of each deployment program and each deployment
instance within that program.
[A533] Prepare Deployment Capabilities

Description
This activity prepares the Deployment Capabilities required for a given deployment. Examples
include:
Training staff to be able to execute deployment tasks
Creating a facility for volume pre-installation of base software prior to delivery to the
ultimate destination
Customizing standard release or solution materials to target site needs
Controls
Deployment Program Plan (From: A532)
hardware, software, documentation, process to the target environment
training plan.
Management.
•
•
•
•

Inputs
be deployed.
entity.”55
Outputs
Deployment Capabilities (To: A534 A535 A536)
Combination of knowledge, skills, experience, processes, systems and technologies
required to deploy new or changed deployment objects into the target environment.
[A534] Perform Transition Administration

Description
In this activity, the administrative and other tasks of a preparatory nature for the transition to the
desired deployment status are performed. The tasks include:
Requisitioning hardware and software assets for deployment
Making logistical arrangements
Executing transfers of ownership

•
•
•
•
The activity ensures that appropriate data on assets is provided to the Asset Management process
to reflect their updated status. Items impacted include location, financial status (support contracts),
and ownership.
Controls
training plan.
Management.
contracts (UCs).

•
•
•
•
Inputs
Deployment Capabilities (From: A533)
Deployment Rework Need (From: A536)
The identification that any parts of the deployment plan need to be reworked prior to the
capability reaching full service status. Everyday changes in business operations within the
organization that is the target of deployment can be the cause of such a need. For
example, changes in staff since plan creation.
Outputs
resources.
Deployment Items (To: A535)
The collection of items that are ready for deployment and for which all title and ownership
information reflects the imminent deployment into the target environment. These items are
instances of what ITIL calls Service Assets, defined as “Any Capability or Resource of a
Service Provider.”59

•
•
•
•
[A535] Perform Deployment

Description
This activity performs the physical, technical, and other tasks (such as delivering training and
registering users) which move the capabilities being deployed from not deployed to deployed. It
includes:
Distribution and installation of hardware and software, ensuring appropriate data is
provided for asset and configuration updates
Customization, where needed, of:
• CIs to reflect their specific usage context
• Identity and access records (by initiating updates using the Identity and Access
Management process)
• Security mechanisms (also using update requests, to the Security Management
process)
Removal of redundant services and assets, (processes, procedures and tools).
Introduction of new or changed processes to the service provider teams responsible for
Service Management activities.
Perform deployment has fulfilled its responsibilities when the capability being deployed is ready for
verification and activation.
Controls
training plan.
Management.
Inputs
•
•
•
•
Deployment Items (From: A534)

The collection of items that are ready for deployment and for which all title and ownership
information reflects the imminent deployment into the target environment. These items are
instances of what ITIL calls Service Assets, defined as “Any Capability or Resource of a
Service Provider.”60
entity.”61
target.
Security Response (From: A726)
The result of processing a security request. The result will reflect a range of possibilities,
depending on the nature of the service request:
• For a protection request the protections put in place
• For an access authorization request the success or failure of the request
Identity and Access Response (From: A673 A674)
The result of processing an identity and access request. The result will reflect a range of
possibilities, depending on the nature of the request:
• For an identity request actions taken to create, maintain, or delete the identity
• For an access (rights) request the success or failure of the request, with relevant
information describing the status of access rights
Deployment Rework Need (From: A536)

•
•
•
•
• Instructions for the next stages of implement

Outputs
Deallocated Assets (To: A552)
Assets that are no longer deployed to specific owners. These assets are free to be
allocated to new owners.
Security Work Request (To: A72)
A Security Request originating from another process.
Identity and Access Work Request (To: A67)
An identity and access request originating from another process.
• Attributes
• Relationships
change or release.
Solution Installed (To: A536)
A solution under deployment for which all tasks required to achieve deployment status have
been completed other than final activation.
•
•
•
•
[A536] Verify Deployment and Activate Service

Description
This activity verifies the integrity of the solution under deployment and transitions the new changed
service to Service Operations.
Integrity testing can include the following items:
Service assets and capabilities are in place
Documentation updates are completed
Learning material has been made available to stakeholders
Users are prepared to operate the new or changed service
Measurements and reporting systems are established.
Transition to full service status can include a defined period as early life support; defined by ITIL
as “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.”62
Controls
training plan.
Management.
contracts (UCs).

•
•
•
•
Inputs
Solution Installed (From: A535)
A solution under deployment for which all tasks required to achieve deployment status have
been completed other than final activation.
entity.”66
Outputs

•
•
•
•
• Attributes
• Relationships.
change or release.
A76)
Deployment Rework Need (To: A534 A535)
[A537] Review and Close Deployment

Description
This activity reviews the tasks completed during deployments and determines that all objectives of
the deployment plan were met. A management plan is established for outstanding risks, issues,
incidents and known errors before the deployment is closed. Deployment is completed with a
handover of the support to Service Operations.
Controls
training plan.
•
•
•
•

Management.
Inputs
change or release.
Incident (From: A2 A27 A273 A5 A51 A516 A53 A536 A61 A613 A62 A625 A63 A637 A64
A644 A646 A67 A675 A7 A72 A75 A754)
Outputs
[A538] Monitor and Report Deployment Program

Description
This activity ensures that the overall set of deployment programs and all of the deployment
instances within each program are monitored throughout their entire life cycles.
Aspects include:
Maintaining currency and integrity of data on deployments
Monitoring status and deployment impact on service level agreements
Identification of any requirement for deployment instance: reprioritization or escalation
Communicating status and progress to stakeholders and support groups
•
•
•
•
Controls
training plan.
Management.
contracts (UCs).

•
•
•
•
Inputs
Deployment Records (From: A532 A533 A534 A535 A536 A537)
Outputs
Deployment Reports (To: A518 A525 A526 A532)
[A539] Evaluate Deployment Management Performance

Description
This activity looks at the performance of the Deployment Management process and determines if
changes to the Deployment Management Framework should be recommended. This includes
examining:
Adequacy of release management resources
Rejected or failed deployments
Deployment Management policies and procedures
Controls
Management.
Inputs
Deployment Management Activity Data (From: A532 A533 A534 A535 A536 A537 A538)
Outputs
Deployment Management Evaluation (To: A531)
An analysis of deployment management activity data providing an understanding of the
current success or failure of the deployment management process, and an identification of
potential process improvements.
•
•
•
•
Purpose
The purpose of the Configuration Management process is to maintain the integrity of the
configuration items (CIs) employed in, or related to, IT systems and infrastructure in either a
development or operational context, and to provide accurate information about CIs and their
relationships.
Configuration Management emerged out of complementary needs within both IT development and
IT operations. IT development needs to maintain the integrity of evolving development artifacts in
a development project. Similarly, IT operations should maintain the integrity of CIs that have been
made operational.
Definition of a configuration item: “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.”70
Outcomes
All configuration items within IT systems and infrastructure are accurately identified and
cataloged
All configuration items are adequately tracked and controlled
Authorized requests to obtain CIs from secure libraries or stores (or to return them) are
satisfied promptly and accurately
Accurate configuration information is provided in response to informational requests
Any exceptions between configuration records and the corresponding CIs are identified
and corrected
In development projects: development CIs in multiple development streams are controlled
and coordinated
Scope
Relationship with Asset Management
To properly understand Configuration Management, it is necessary to understand its relationship
with Asset Management. Asset Management keeps track of things of value (assets) to an IT
organization, whether that value is financial, technical, or otherwise, throughout the asset's entire
life cycle. That life cycle stretches from the time the asset is ordered or commissioned to the time
when it is retired and disposed.
At various stages in an asset's life cycle, the usage of that asset can cause it to become a part of
some larger object requiring management (for example, a processor is added to a pool of
processors allocated to a particular task) or it can be split into a number of parts at smaller
granularity (for example, a physical server is operated as several virtual servers). Similarly, an ERP
system licensed from a vendor might represent one or a handful of assets to be tracked (for
financial or contract management purposes), whereas it can represent hundreds of modules which

•
•
•
•
must be identified individually. For example, for local customization, problem determination, or
maintenance patch application purposes.
The characteristic of these events is that the asset has been applied to some defined purpose,
typically through any or all of the Solution Development and Integration process, the Release
Management process and the Deployment Management process. At these times, those parts
become configuration items (CIs) and are managed by Configuration Management. Configuration
Management focuses on the internal and external relationships of a CI and addresses the
configuration needs of a stage in an asset's life cycle.
For instance, during development of a software asset, Configuration Management might be used
for source code control of the components that make up that asset. Another instance is when a
system becomes operational within the IT infrastructure. In that instance, Configuration
Management is used to maintain operational information about that CI and its relationships to other
CIs in the IT infrastructure. The two most widely recognized uses of Configuration Management
are development Configuration Management and operations Configuration Management.
Configuration Management in Development and Operations
Configuration Management addresses the needs of both IT development and IT operations. The
characteristics of these domains are similar,71 yet also have differences. Similarities include:
Both development and operations focus on the various configuration items that make up
their domains. In development, these include evolving hardware, software, and
documentation that constitute an IT system being developed. In operations, these include
fully developed hardware, software, and documentation that have been deployed and made
operational within the IT infrastructure.
Both development and operations maintain information about CIs and their relationships.
On a regular basis, that information is checked for accuracy against the actual
configuration items and inaccurate information is corrected.
Differences between development Configuration Management and operations Configuration
Management include:
IT development maintains the integrity of development CIs primarily by controlling the CIs
themselves, whereas IT operations maintains the integrity of operational CIs by controlling
information about the CIs.
Check-in/check-out of IT development CIs is a normal practice in Configuration
Management for IT development. (There is a distinct difference in how check-in and check-
out is performed for electronic as opposed to physical CIs.) IT operations does not perform
check-in/check-out of CIs.
IT operations focuses on controlling updates to information about CIs. Significant
information about CIs must be manually maintained. In contrast, information about
development CIs is primarily obtained from the CI itself.
Development CIs (such as software and hardware components and document chapters)
are typically smaller-grained than operational CIs (such as PCs, applications, servers, and
others).
The configuration management system for IT development (often called a source code
control system) is typically maintained separately from the configuration management
system for IT operations, and the technology and procedures used by each system is
usually different.
The CIs that make up an operational IT infrastructure are typically also considered assets.
However, most CIs in a development project are not considered to be assets because their
value to the IT organization is considered too small (or too intangible) to track. For this
71. Industry examples of this can be seen in ISO/IEC 15288 Systems and Software Engineering - System Life Cycle
Processes and ISO/IEC 12207 Systems and Software Engineering - Software Life Cycle Processes.
•
•
•
•
reason, a development project might have few assets tracked by Asset Management other
than the overall system under development.
The similarities in Configuration Management between IT development and IT operations are
sufficient to define a single process at a high level. The differences between IT development and
IT operations are significant only at a lower level of the process.
Common Data
In practical terms, Asset Management and Configuration Management carry out their activities
using data about these assets and CIs, which is largely common to them both, though each has
some attributes and relationships not significant to the other. Successful implementation of both
processes requires joint work on their data models and clear rules (that is, governance) on which
process owns any shared attribute.
Types of CIs
The ITIL definitions of asset and of configuration item include a range of types of IT elements which
can fall under Configuration Management. Whether an implementation covers all or just some of
these types, it is likely that there will be some process aspects that are dependent on the needs of
different component types. Consideration of a few examples illustrates this:
Each hardware item is a candidate for both configuration and asset management, though
probably at different levels of granularity. An IT organization will want to keep track of that
hardware item throughout its life cycle from the standpoint of Asset Management. At the
same time, when that system is operational, Configuration Management might be
interested in internal hardware components (which are CIs) as well as other CIs that have
some operational relationship to this CI. Hardware items cannot usually be cloned.
Software components might have no record in the asset register. They can be subject to
tight access controls (for example, to avoid erroneous multiple update during development)
and at the same time they can be cloned to create as many instances as needed within
limitations such as license counts. Larger software elements, such as applications can be
both a CI as well as an asset.
The process will also need to take into account the arrangement of the set of internal and external
service providers and establish appropriate interfaces with the Configuration Management process
of those service providers.
Includes
Establishing naming conventions for configuration items and relationships
Designing, creating, populating, and updating the Configuration Management System
(CMS)
Managing movements into and out of secure libraries
Supporting configuration item audits
Identifying configuration item interdependencies
Linking configuration item changes to specific change requests (RFCs)
Defining and reporting configuration baselines
Excludes
Inventory tracking (Asset Management)
Procurement of configuration items (Supplier Management)
Tuning and installing configuration items (Capacity Management, Deployment
Management)
Assets that are not CIs, such as:
•
•
•
•
– Items ordered but not received

– Items no longer in operation
– Bulk inventory
– Assets not operationally managed
Controls
implemented.”72
compliance
Inputs

•
•
•
•

A7 A75 A753 A754)
• Attributes
• Relationships
Configuration Information Request (From: A336 A422 A423 A424 A442 A443 A664)
make such requests.
Asset Information (From: A5 A55 A553)
individual asset.
Outputs
CIs (To: A4 A43 A434 A44 A444)
Configuration Baseline Report (To: A423 A51 A514 A516 A52 A522 A523 A524)
instances.

•
•
•
•
Activities
Service IT Management Architecture Baselines Change Schedule Compliance Plans
Catalog Ecosystem and Roadmaps and Controls
C1
C2 C4 C5 C3
Establish
Asset Management
Framework/D1 Configuration Configuration Management
I4 Management Framework
Solution Design Framework
A541
Solution
Assembly/D1
Identify O4
Configuration Change
I1 Items Request
Change
Information
Identified
A542 CIs
I5
CI Data
Update Package
Control O2
I3
Change Configuration Configuration
I6 Items Baseline Report
CI Requisition
I8
Asset Information
O1
A543 CIs
I2 CI
Change Implementation Information
Report
Communication O3
Configuration
I7 Configuration
Configuration Status Information
Information A544
Request
Verify and Configuration

Audit Audit Report
Configuration Configuration
Audit Request
Items
A545
Configuration Audit
Asset Action Request
Reconciliation Evaluate
Data/D1 Configuration Configuration
Evaluation
Configuration Management Performance
A546
Activity Data
NODE: A54 TITLE:

Configuration Management CURRENT PAGE:
Figure 5. A54 Configuration Management
•
•
•
•
[A541] Establish Configuration Management Framework

Description
The framework for Configuration Management should be consistent with business and IT models
and strategies, as well as general IT guidelines and practices.
The tasks in this activity include:
Understanding the requirements of the overall IT Management System for Configuration
Management
Defining the strategy, policies, and conventions for controlling configuration items,
including:
• Creation of configuration baselines
• License control
• Version numbering and control
• Identification of approved procedures that may make changes to the CMS
• Identification of procedures related to workspaces, branching, and merging
• Generic naming conventions
• Generic configuration item status codes
• Attributes necessary for all CI types
• CI control procedures, such as check-in/check-out procedures
• Generic information and integration standards for all CMDBs within the CMS
It should be noted that specific practices for individual CI types are defined in Identify Configuration
Items.
Designing, championing, and overseeing the implementation of Configuration Management
solutions
Defining ownership and relationships within the Configuration Management System (CMS).
Within an operations context, the CMS represents all CIs within the IT infrastructure. Within
a development context, the CMS represents all artifacts used to create the system under
development.
Identifying roles and responsibilities, determining skill requirements for the staff and
assigning staff
Defining process metrics and practices for collecting those metrics
Establishing two-way agreements with other parties where there is a mutual requirement
for configuration information and control.
Finally, the structure and process for Configuration Management (including procedures and tools)
must be communicated to the process users and stakeholders.
The establishment of the Configuration Management Framework also includes the continuous
improvement of Configuration Management. For example, the consideration of the Configuration
Management process evaluation and the implementation of recommended improvement actions.
•
•
•
•
Controls
Service Catalog
service is provided.(From: A2 A23 A235)
Inputs
Asset Management Framework (From: A551)
under which the Asset Management process will operate to meet its mission and goals.
Configuration Management Evaluation (From: A546)
Outputs
Configuration Management Framework (To: A542 A543 A544 A545 A546 A551)
The information and artifacts which represent the purposes of the process and the means
by which the process will operate to satisfy them.
[A542] Identify Configuration Items

Description
This activity defines the types of configuration items under the control of Configuration
Management. This might be done during the initial population of a CMDB within the Configuration
Management System (CMS) or when a new type of CI is identified for inclusion within the CMS.
This discovery can be done manually or automatically.
As a result of design at either the architectural level or within a particular solution, a new CI type
can be generated that should be reflected within the CMS schema.
Once a new type of CI is identified, a number of steps might need to occur, including:
Creating specific naming conventions for this CI type
Creating specific labeling conventions

•
•
•
•
Defining attributes for the CI type

Defining documentation for the CI type
Defining relationships to other CI types
Defining specific control procedures
This information is stored in the Configuration Identification Practices.
Each of the decisions can result in an update to or modification of the CMS schema, resulting in a
proposal to update the CMS.
Controls
Configuration Management Framework (From: A541)
Inputs
purposes.
A7 A75 A753 A754)
• Attributes
• Relationships
CI Information (From: A543)
The definitive configuration information about each and every managed configuration item.
The collection of this information is represented by the concept of a CMDB.
•
•
•
•
Configuration Audit Action Request (From: A545)

A request for some corrective action to be taken to reflect the outcomes of configuration
audit.
Outputs
instances.
Identified CIs (To: A543)
The set of CI types, with details of their:
• Attributes
• Relationships
• Structures in which they are expected to participate
Configuration Management Activity Data (To: A546)
[A543] Control Configuration Items

Description
All transactions with the CMS are carefully controlled so that only authorized access is allowed.
The functionality of a CMS can vary based on the context in which it works. For example, in an
operations context, the CMS stores information about CIs within the IT infrastructure and
transactions with the CMS will include creating new CI records, deleting CI records, and updating
existing CI records. In a counter example, within a software development context, the CMS stores
an electronic version of the CI itself and transactions with the CMS will include creating or deleting
CIs within the build structure as well as checking in and checking out CIs for development work.
Regardless of the context, all transactions (whether additions, deletions, cloning or branching,
merging, or modifications) are recorded in the CMS.
As noted previously, CI transactions can include information about CIs or could be electronic
versions of the CIs themselves (if the CIs are software modules in a development environment).
Submitted CI transactions are validated, and then checked for proper authorization. Specific
operational procedures might already be approved for specific types of transactions with the CMS.
(For example, service desk personnel might have authority to update records within an operations
CMS, or developers within a software development project might have such authority within a
development CMS.) Non-typical requests can be routed to a person to obtain proper authorization
or rejected outright, based upon policy.
During processing of the transaction, relevant linkages to other CIs and to any other information,
such as change requests, will also be defined, checked and recorded.
New configuration baselines can be generated based on configuration management practices. A
baseline might be created within an operations context to help restore a set of CIs to a known
stable state if a change or release fails. In a development context, a baseline represents a known
state of a system under development to which the project could return if necessary.
•
•
•
•
Controls
Identified CIs (From: A542)
The set of CI types, with details of their:
• Attributes
• Relationships
• Structures in which they are expected to participate
implemented.”76
Inputs
A7 A75 A753 A754)
• Attributes
• Relationships
purposes.
individual asset.

•
•
•
•

audit.
Outputs
instances.
CIs (To: A4 A43 A434 A44 A444)
CI Information (To: A542 A544 A545)
[A544] Report Configuration Status

Description
This activity makes CI and CMS information available to any authorized requestor. The information
can range from detailed attributes and relationships to summarized information. It can cover an
individual CI or a collection of CIs. It can be essentially unformatted raw data or predetermined
reports. Finally, it can be provided in line with a planned schedule or in response to an individual
request.
Controls
Inputs

•
•
•
•
Configuration Information Request (From: A336 A422 A423 A424 A442 A443 A664)
make such requests.
audit.
Outputs
[A545] Verify and Audit Configuration Items

Description
This activity determines how well the contents of the CMS match an audit target, such as a
development baseline or the IT infrastructure. This configuration audit checks to make sure the CI
information matches the physical reconciliation data, that naming conventions are followed, that
the DML and DHS agree with the CI, and that change requests match the composition of the CI.
The audit takes place on a regular basis, as stipulated by the Configuration Management Plan, or
as requested by the Configuration Manager or other authorized personnel. Audits can help verify
the effects of approved changes and can help identify unauthorized changes.
There are two contexts in which a configuration audit might take place. In both instances, the audit
determines whether the contents of the CMS match some known collection of CIs. The first context
is an operations context, and the purpose of the audit is to determine if the contents of the CMS
matches the existing CIs in the IT infrastructure. The second context is a development context, and
the purpose of the audit is to determine if the development baseline contains all development CIs
in the CMS. The audit takes place on a regular basis, as stipulated by the Configuration
Management Plan, or as requested by the Configuration Manager or other authorized personnel.
Controls
implemented.”78

•
•
•
•

compliance
Inputs
Configuration Audit Request (From: A554 A716)
A request for any aspect of the collected configuration information to be audited against the
actual, real managed object.
Asset Reconciliation Data (From: A554)
Data collected during auditing and inspection of assets. Typically includes location,
condition and verification results.
Outputs
Configuration Audit Report (To: A455 A554 A716)
people making such changes.
Configuration Audit Action Request (To: A542 A543 A544)
audit.
•
•
•
•
[A546] Evaluate Configuration Management Performance

Description
This activity analyzes the Configuration Management process and its effectiveness. This includes:
Identifying suggested improvements to the Configuration Management Plan
Analyzing CI requests to determine how to improve the processing of such requests
Analyzing CI information errors to determine how to improve the quality of information
received
Analyzing stakeholder needs
All of this analysis is used to create a Configuration Management Performance Evaluation. This
will be a key input when updating the Configuration Management Framework.
Controls
Inputs
Configuration Management Activity Data (From: A542 A543 A544 A545)
Outputs
Configuration Management Evaluation (To: A541)
•
•
•
•
Purpose
The purpose of the Asset Management process is to control all assets owned by the IT endeavor
throughout their life cycle and to maintain accurate information about them in an Asset Register.
The aspects of asset control under this purpose include inventory, contractual (licensing,
maintenance), ownership and location
ITIL provides the following definitions:
Asset: “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, Organisation, Process, Knowledge, People, Information, Applications,
Infrastructure, and Financial Capital.”79
Asset Register: “A list of Assets, which includes their ownership and value. The Asset
Register is maintained by Asset Management.”80
The definition of asset is much broader than those in widespread usage within the IT industry.81 In
this model, many of the types identified are controlled by other processes specialized for the
management issues that pertain to them.
Items Management, Organization, Process are the subject of the IT Governance and
Management System category of processes
Knowledge Management is a process in its own right
People are recruited, developed, and assigned to responsibilities by the Workforce
Management process
Financial Capital is under the custodianship of the Financial Management process, with
interfaces to this process where Asset activities have an impact on financial valuation (for
example, by a decision to dispose of an asset or to transfer ownership to a new owner).
The technology object types Information, Applications, Infrastructure are all covered by this
process, where each individual item can qualify for any of the asset control purposes in scope. For
example, it is not unusual for accessories for PCs (such as keyboards, mice) to be excluded from
asset control.
Outcomes
As a result of the successful implementation of the Asset Management process:
Value is maximized from technology assets over their lifetime
Assets are provided in an accurate and timely manner to supply, movement or other
requests
Accurate and timely information about technology assets supports informed IT decision
making, at both strategic and tactical levels
Exposure to risks relating to IT assets is minimized
IT assets are managed in compliance with legal, industry and corporate standards and
requirements
Governance of assets drives the right trade-offs in investments in asset and usage of
assets

81. See HTTP://en.wikipedia.org/wiki/IT_asset_management
•
•
•
•
Scope
Asset Management has dual responsibilities:
1. To control each asset from initial creation (such as receipt from suppliers) through all life
cycle events (such as change of location, transfer of ownership, change of use) until
eventual retirement or disposal.
2. To identify, collect, maintain, control, and report inventory and financial information about IT
assets throughout their life cycle
Includes
License management (including software license compliance)
Lease and maintenance administration of each asset
Inventory management (includes physical components and specifications)
Allocation of available assets to meet approved requests
Physical logistics (such as transportation) of assets
Retirement of outdated assets
Triggering requisition for the procurement of additional assets (for example, if a policy
of maintaining minimum inventory stock levels for standard, frequently needed asset
item is in place)
Financial life cycle of assets (including valuation)
Excludes
Risk Management
Contract and Supplier Management (including Procurement) (Supplier Management)
Configuration Management (logical relationships)
Managing the security of an asset (Facilities Management, Security Management)
Controls
compliance
•
•
•
•

Management)
Inputs
Asset Deployment Inquiries and Requisitions (From: A433 A434 A51 A514 A515 A516 A52
A522 A523 A524 A53 A534)
resources.
target.
an SLA.”82
Outputs
Asset Deployment Items and Data (To: A4 A43 A51 A52 A522 A523 A524 A53 A534)
individual asset.

•
•
•
•
Activities
IT Management Architecture Baselines IT Budget Regulations Compliance Plans
Ecosystem and Roadmaps C4 and Standards/D3 and Controls
C2 C3 C5 Asset Management
C1 Framework
Configuration
Management
Asset Asset Allocated
Framework/D1
Establish Availability Requisition Asset Items
Asset Information Status
I3 Management O1
Service Request_ Framework Asset Deployment
Authorized A551
Items and Data
Deallocated
Ready
Assets
and Asset Replenishment
Asset
Requisition
Control Request
Asset Asset Asset_
Asset/D1 A552 Retired
Distribution
Instruction Control
O2
I1 Asset Asset Asset Asset Information
Asset Deployment Availability Information Register
Inquiry Configuration
Inquiries
Audit Request/S1
and Requisitions A553
Monitor,
I2
Configuration
Audit and Asset
Reconcile Reconciliation
Information Asset
Data
Asset Data Operational Asset
Update Package Data Records
A554 Asset Audit
Configuration
Oversee Action Request
Audit Report/D1
Asset
I5 Contracts
IT Financial
Reports and Asset Contracts
Financials and Financial Data
Asset Information A555 Asset_
or Report Request
Retire
Disposed
and
Dispose
of Asset
Asset Retirement A556
and Disposal Data Asset Retirement
and Disposal Instructions Report
Asset
Asset Reports
Information
A557
Asset_ Reactivated
Evaluate
Asset
Management
I4 Asset Management Performance
Underpinning Activity Data A558
Contracts
Asset
Asset
Management
Licenses
Evaluation
NODE: A55 TITLE:
Asset Management CURRENT PAGE:
Figure 6. A55 Asset Management
•
•
•
•
[A551] Establish Asset Management Framework
[A551] Establish Asset Management Framework

Description
of the Asset Management process and its activities.
Incorporate mandatory elements from the IT Management Ecosystem.
Define a set of metrics to be used by each process for measuring and reporting performance.
recommendations for improvements. Refine the metrics to encourage process vitality and cost
effectiveness.
Controls
Management)
Inputs
Asset Management Evaluation (From: A558)
Assessment results for the Asset Management process and its activities, including process
performance metrics and the identification of potential process improvement items.
Outputs
Asset Management Framework (To: A541 A552 A553 A554 A555 A556 A557 A558 A751)
•
•
•
•
[A552] Ready and Control Asset

Description
Prepare assets that are to be made available to users. This includes receiving the asset either from
an asset provider or from the recycling of existing assets.
Prior to deployment, respond to inquiries concerning the status of the asset (such as whether it has
been shipped from the vendor or not). Prepare assets for deployment (such as installing IT
approved images, appropriate asset ID tags, among others). Allocate assets to specific users or
sites, based on distribution instructions, and transfer assets to their appropriate locations.
Determine when to retire an asset.
Controls
Asset Contracts and Financial Data (From: A555)
Business records about an asset and related financial information. This includes data such
as asset records, vendor information, asset costs and current value, tax data.
Inputs
target.
Deallocated Assets (From: A535)
Assets that are no longer deployed to specific owners. These assets are free to be
allocated to new owners.
Asset (From: A82 A824)
Each asset that has completed the procurement process (business now holds the title) and
is available for productive deployment. During its useful life, it is managed by the Asset
Management process.
Asset Requisition
The placement of an order for one or more specified assets (or asset types) to be delivered
or otherwise made available for productive use.
Asset Availability Inquiry
A planning inquiry to establish the outlook for the availability of specified IT assets for
productive use.
•
•
•
•
Asset Distribution Instruction

The formal trigger for IT assets, probably already reserved for this purpose, to be
distributed. The instruction would include details such as:
• Date
• Location
• Quantity
• Specification
• Personnel involved and contact details.
Asset_ Reactivated (From: A556)
An asset that was previously retired, but has been brought back into active service.
Asset Retirement and Disposal Data (From: A556)
Data that describes the disposition and status of assets slated for retirement and disposal.
Asset Audit Action Request (From: A554)
A request to perform some action based on the findings of an asset audit. This can include
instructions such as to locate a known asset or to reassign it.
Asset Register (From: A553)
The complete set of records in asset information repositories.
Outputs
Asset Availability Information (To: A514)
Details of the ability of the subject IT asset or assets to be made available for deployment
or development use. The details will include:
• Quantities
• Specifications
• Dates
• Locations
Asset Requisition Status (To: A515)
The acknowledgement, including status information such as expected dates, that a
requisition for one or more assets has been received and processed.
Allocated Asset Items (To: A433 A434 A435 A436)
requisitions.
Asset Replenishment Request (To: A824)
A trigger to indicate that additional quantities of an asset are required in order to meet
existing or anticipated requisitions.
Asset_ Retired (To: A556)
An asset that is to be removed from service. Such an asset will be in a storage location
(such as the Definitive Hardware Store or DHS) until it is either restored (recovered) for
active use or disposed.
Asset Operational Data (To: A553)
Relevant individual data values describing the specifics of the current state of an asset.
Examples include:
• Location
• Owner
• Maintenance contract end date
• Original purchase price
•
•
•
•
Asset Retirement and Disposal Instructions (To: A556)

Directives concerning assets slated for retirement and disposal.
Asset Management Activity Data (To: A558)
Data resulting from all work carried out by each process activity, used to support the
evaluation of the overall Asset Management process.
[A553] Control Asset Information

Description
Maintain asset data model and create, update, or delete asset information based on update data
provided by various sources. These sources include other processes that provide administration
and support of assets and configuration items (such as Incident Management, Problem
Management, and Configuration Management).
Manage the repository or set of repositories containing asset information. Carry out actions that
reconcile issues with asset records. Asset information includes assets within the entire asset life
cycle, including received assets, active assets, retired assets, and disposed assets.
Make available information about specific assets.
Controls
Inputs
Asset Operational Data (From: A552)
Relevant individual data values describing the specifics of the current state of an asset.
Examples include:
• Location
• Owner
• Maintenance contract end date
• Original purchase price
Asset Data Update Package (From: A516 A534 A535 A652 A753 A754)
Asset Information or Report Request
A request to obtain information about a deployed asset. This request specifies whether the
information should be in a formal report or simply provided asset data. It covers a range of
request types, such as:
• Need for information on an individual asset
• A scheduled report
• A request for an asset analysis report.
•
•
•
•

Outputs
individual asset.
Asset Register (To: A552 A554 A555 A556 A557)
[A554] Monitor, Audit and Reconcile Asset Records

Description
Monitor IT assets to determine their overall health or status. Areas of interest include meeting
licensing requirements, whether assets are sufficiently up to date, and compliance with security
requirements, among others.
In addition, more formal auditing is performed to ensure that data in asset information repositories
corresponds to assets in the physical environment. Audits match discovered inventory information
with existing assets. Reconcile discrepancies between information repositories and the physical
environment by either updating data in the information repositories or requesting changes to the
physical environment. Also, the findings of an audit might result in a request for an audit of the IT
configuration.
Controls
compliance
Inputs
•
•
•
•
Asset Information or Report RequestThe complete set of records in asset information

repositories.
person(s) making such changes.
Asset Licenses
A documented permission to use an asset or set of assets. The license can contain specific
terms and conditions, including details such as the number of users, any rights to copy and
distribute, and the license period.
Outputs
Asset Replenishment Request (To: A824)
Configuration Audit Request (To: A545)
Asset Reconciliation Data (To: A545)
Data collected during auditing and inspection of assets. Typically includes location,
condition and verification results.
Asset Audit Action Request (To: A552 A553 A555)
•
•
•
•
[A555] Oversee Asset Contracts and Financials

Description
Manage and control all asset contracts and related records. This includes lease agreements,
leasing schedules, tax data, and financial data. Manage financial aspects of assets, including asset
costs, current value, depreciation, and tax determination. Conduct negotiations concerning terms
and warranties. Correlate underpinning contracts to asset records (including lease agreements
and schedules, tax data, and financial information). Provide financial information concerning the
need to retire assets.
Controls
compliance
Inputs
Asset Licenses
A documented permission to use an asset or set of assets. The license may contain
specific terms and conditions, including details such as the number of users, any rights to
copy and distribute, and the license period.
an SLA.”83

•
•
•
•

Outputs
Asset Contracts and Financial Data (To: A552 A553 A554 A557 A814 A825)
[A556] Retire and Dispose of Asset

Description
Collect assets scheduled for retirement and disposal. Return assets to storage (such as the
Definitive Hardware Store or DHS). Some retired assets will be restored to active use, while others
will be disposed of.
Prepare assets for disposal by removing data and harvesting any useful or recyclable components.
Recycle designated assets by making them available for reuse (see Ready and Control Asset).
Once properly prepared, transfer assets to be disposed to a disposal site for final processing.
Notify the asset status of all assets being retired or disposed.
Controls
Inputs
Asset_ Retired (From: A552)
An asset that is to be removed from service. Such an asset will be in a storage location
(such as the Definitive Hardware Store or DHS) until it is either restored (recovered) for
active use or disposed.
Asset Retirement and Disposal Instructions (From: A552 A554 A555)
Outputs
Asset_ Disposed
Assets that have reached the end of their useful lifecycle and have been removed from
service and inventory. Disposal can involve selling, scrapping or recycling.
•
•
•
•
Asset_ Reactivated (To: A552)

An asset that was previously retired, but has been brought back into active service.
Asset Retirement and Disposal Data (To: A552 A553 A555)
[A557] Report Asset Information

Description
Receive and process requests for asset reports. These can include ad hoc reports or standard
reports. Design (if needed), generate, and disseminate asset reports as per request.
Controls
Inputs
Asset Information or Report Request
Outputs
Asset Reports
Ad hoc or standard reports describing assets. These reports may describe one or more
selected assets or may summarize data about a set of assets, or possibly all assets.
•
•
•
•
[A558] Evaluate Asset Management Performance

Description
This activity assesses the performance of the Asset Management process activities against
defined performance criteria and measures, and provides input to the IT Management System
Framework.
The evaluation of process performance identifies areas that need improvement. This might include
the foundation and interfaces of the process, activity definitions, key performance metrics, the state
of supporting automation, as well as the roles and responsibilities and skills required. Insights and
Controls
Inputs
Asset Management Activity Data (From: A552 A553 A554 A555 A556 A557)
Outputs
Asset Management Evaluation (To: A551)
Assessment results for the Asset Management process and its activities, including process
performance metrics and the identification of potential process improvement items.
•
•
•
•
PRM-IT A5 Node Tree
A5 – TRANSITION
A514 Assess Change
•
•
•
•
A5 – TRANSITION
Figure 7. A5 Transition Node Tree
•
•
•
•
•
•
•
•
[A6] Operations
Description
Purpose
communications with users (for example, service requests) is an important function as these
processes sense and respond to day-to-day aspects of operations and events, quickly and
correctly to address any incidents and problems that might arise.
Rationale
The Operations category comprises all the activities and measures necessary to enable and
maintain the intended and committed use of the infrastructure, applications, and services. The
processes in this category require close integration to function effectively. Operational plans and
workload balancing are augmented by constant operational monitoring throughout service
delivery. This operational data is used by many processes to identify, analyze, and quickly resolve
any anomalies. The Operations category is also the focal point for receiving and responding to a
wide variety of user service requests. This process category is vital to operating organizational
constructs such as a Service Desk or an Operations Bridge or an Operations Center. Problem
information.
Value
processes
Controls
•
•
•
•
Inputs
A452)
A644 A646 A67 A675 A7 A72 A75 A754)
User Input (From: Outside-the-Model)
Outputs
User Output (To: Outside-the-Model)
Identity and Access Rights Register (To: A674 A675 A7 A72 A726 A727 A75 A754)
Service Metric Data and Reports (To: A2 A24 A244 A7 A71 A716 A8 A81 A814 A815 A83
A832)
Operational Monitoring Data (To: A62 A623 A625 A63 A634 A637 A64 A642 A65 A654
A655 A66 A662 A7 A73 A735 A74 A743)
Incident Information (To: A2 A24 A244 A61 A613 A615 A652 A653 A654 A655 A656 A66
A662 A7 A72 A726 A73 A736 A74 A744 A75 A754)
Problem Information (To: A2 A24 A244 A245 A356 A61 A613 A615 A65 A653 A654 A656
A662 A663 A664 A665 A666 A7 A73 A736 A74 A744 A76 A764)
Service Request_ Authorized (To: A5 A53 A535 A55 A552 A62 A622 A63 A67 A7 A72
A75)
•
•
•
•
Processes
A63 Data Management
IT Management SLAs OLAs UCs Service Compliance Plans Architecture Baselines IT Financial Security Policy
IT Plan Change Schedule
Ecosystem Catalog and Controls and Roadmaps Reports C8 Customer
C6 C4 C2
C5 C9 C3 C1
C7 Satisfaction
I7 Issue/S1
User O1
Input Service User Output
Service Request Request
Response
I2 Request
Change Fulfillment
Information O7
Service Request_
Work Authorized
Requests A61
Service Execution Operational Service
Work Requests_ Project Proposals
Work Metric Data and Reports
Completed
Data Input Service
I5 Execution
Solution
Plans and O4
Operational
Commitments
A62 Monitoring Data
IT Administration
I1 Data Lifecycle Support Data
Solution_ and Requests
Deployed
Request Data
Data_ Derived O3
Management Service Metric Data
I8
Service Resilience and Reports
Data
Plans A63 Management
Metric Data O9
Service and Reports Change
Resilience Data Event Request
Directives/D1
Security
Management O8
Monitoring Data/D1 CI Data
Update Package
A64
Event Event Resolution

I6 Incident Directive
Incident Management
Incident_ Resolved
O5
A65 Incident
Information
Problem
Management
I3 O6
Configuration A66 Problem
Information Information
Identity and O2
Access Identity and
Management Access Rights
A67 Register
I4
Solution Design
Security Security
Identity and Access
Plan/D1 Directives/D2
Identity and Access Monitoring Data
Work Request
NODE: A6 TITLE:
Operations CURRENT PAGE:
Figure 1. A6 Operations Diagram
•
•
•
•

Purpose
The purpose of the Request Fulfillment Process is to receive service requests from users and route
each request to the appropriate process for handling. Some service requests are handled by the
Request Fulfillment Process, whereas many others are routed to other processes for fulfillment.
Request Fulfillment can be the contact management process for an implementation of an IT
Service Desk (or equivalent).
Definition of service request: “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.”1
Outcomes
As a result of the successful implementation of the Request Fulfillment Process:
User and customer satisfaction is enhanced
User requests to the IT organization are successfully received and processed for fulfillment
or other appropriate handling
Requests are accurately and appropriately routed to the correct process and correct
service provider for handling (fulfillment)
Service level targets for service desk responsiveness and quality are achieved
Users receive accurate and timely communication concerning the status of their service
requests
Scope
At the initial receipt of a service request from a user, the nature of the request and information
within it has to be established. Many such service requests can be dealt with by the set of activities
within this process. Other service requests, once initially assessed, will be beyond the capability of
this process to perform the primary added-value work needed by those requests and will be
passed on to other, more specific processes. This process will interact at the process framework
level with the specific processes to determine which types of service requests should be handled
by which processes. Over time, the range of service requests which can be directly fulfilled is likely
to increase.
Examples of interactions are:
Incidents are routed to the Incident Management process
Service requests assessed as standard changes are passed directly to other appropriate
processes
Other, more significant change requests are transferred to the Change Management
process
Wherever the service request is dealt with, this process retains ownership of the service request
on the user's behalf and is responsible for achievement of service level targets relating to service
requests.
This process provides the primary interface point for users of IT services with the service provider.
1. ITIL V3 Glossary
•
•
•
•
Includes
Receipt and management of service requests relating to:
Incidents
Standard changes (such as deployment of standard software)
Identity
Access rights
Security service requests
Information, advice, guidance
User satisfaction interactions
Complaints
Items which are assessed to be change requests (rather than standard changes) can be
routed to Change Management
Excludes
Those interactions between the business (and other customers) and the IT service
provider that consider the status, scope or coverage of the overall service provision
agreements. (Service Level Management)
The direct fulfillment of those service requests which are dealt with by other
processes. Where such fulfillment workings require direct contact between IT service
provider staff performing those processes and users, then those activities are part of
those processes. An example of this would be interacting with a user as part of
deploying a PC (Deployment Management)
Establishing entitlement limits for user communities against each service
(Combination of Service Marketing and Sales, and Service Level Management)
Granting access rights (found in Identity and Access Management)
Installing standard technical components (Deployment Management)
Controls
contracts (UCs).
•
•
•
•
Inputs
Service Request (From: A65 A653)
A request to perform a standard and straightforward IT task for a user. Service requests are
tasks that are within the scope of existing IT services.
ITIL definition: “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.”6
2. ITIL V3 Glossary
3. ITIL V3 Glossary
4. ITIL V3 Glossary
5. ITIL V3 Glossary
6. ITIL V3 Glossary
•
•
•
•
Outputs
Service Request Response
The interim and final outcomes of the service request, which can be many aspects,
including:
• The information requested by the user
• A request for more information or an acknowledgement of a milestone within the request
processing
• Status of the work effort triggered by the request, including plans to address the work
items contained in the request
A75)
target.
an interruption to service. Incidents can be created using either manual or automated
mechanisms. An incident reported by a user begins as a user contact and becomes an
incident once it is determined that a fault is being reported.
•
•
•
•
Activities
IT Management IT Plan Service SLAs OLAs UCs
Ecosystem C3 Catalog C2
C1 C4 Request Fulfillment
Framework
Change Management Establish

Framework/D2
I5 Request
Solution Design Fulfillment
Framework O2
A611
Service
I3 Request
Service Resilience Service Request_
Security Plan/D5 Response
Plans Rejected
I1
Receive and
Service Request Approve
I4
Configuration
Service
Information Request O5
A612 Service Request_
Incident
Fulfilled
Service Request_
Approved Fulfill or
Knowledge
Assets/D2 Route O4
Service Change
Request
Operational Request Service Request
A613 Routing Information
Documentation/D2
O3
Service Request Service Request_
Service Request_
Fulfillment Information Closed Authorized
I6 Close
Problem Service
Information Request
I2 O1
A614 Customer
Change
Information Satisfaction
Service Issue/S1
Own, Monitor, Request
Status
Track and Service
Communicate Request
I7
Service Reports
Incident Requests
A615
Information
Service Request
Customer Satisfaction Escalation
Issue Communications/D1
Evaluate
Request Request
Service Request
Fulfillment
Status Input Fulfillment Evaluation
Performance
Request Fulfillment A616
Activity Data
NODE: A61 TITLE:

Request Fulfillment CURRENT PAGE:
Figure 2. A61 Request Fulfillment
•
•
•
•
[A611] Establish Request Fulfillment Framework

Description
This activity consists of tasks that establish the base for any request or contact for assistance. This
includes several different topics that have to be handled:
Determine the structure of the logical entity that is the service request center. This should
be a single point of contact (SPOC), regionally, locally dispersed, or virtual.
Define in which format inbound and outbound communication will be done. Meaning, how
users can contact the IT service provider (telephone, fax, e-mail, Internet) and how the
request fulfillment process communicates with the users.
Determine the categorization of service requests (standard changes, incidents, service
contacts, contacts for advice, and more) and define priorities. Allowance must be made for
users submitting requests which, when examined, are determined to be in a category
different from that suggested by the user.
Collect the technology requirements for tooling of request fulfillment. Select and implement
tools including relevant procedures. Technology requirements will reflect the range of
media (described earlier) and the mix of self-help and service provider delivery.
Determine which requests can be fulfilled within this process and which requests (once
authorized) are to be transferred to other processes.
Set measurable targets that relate to the agreed SLAs.
Based on these specifications define skill requirements for the staff (contact handlers) and,
if necessary, determine training requirements.
Finally, communicate the structure and process of request fulfillment to the users.
Controls
7. ITIL V3 Glossary
•
•
•
•
Inputs
Request Fulfillment Evaluation (From: A616)
The result of the evaluation of the Request Fulfillment process, including any identification
of potential process improvement areas.
Outputs
Request Fulfillment Framework (To: A612 A613 A614 A615 A616)
The framework that contains all relevant information about the structure of the Request
Fulfillment process. For example:
• Structure of the request fulfillment center (often known as or linked to a service desk)
• Technology support
• Request routing tables and completion details of request completion targets and
commitments
• Format of information transfer
• Categorization and prioritization aspects for service requests
It defines the records which should be kept for each service request containing all relevant
details across the life cycle of the request. Information in a record includes data relevant to
service provider analysis as well as the details directly relevant to the requestor.
•
•
•
•
[A612] Receive and Approve Service Request

Description
When a user makes a request for service using one of the available channels (such as by calling
a service desk, by sending an e-mail or by completing a self-service dialog), the request is
examined and checked to see if it passes the criteria for acceptance. If not, it is rejected.
Typical tasks include:
Checking completeness and accuracy of user information
Confirming user entitlement to have the request processed, and perhaps defining a class of
service for the request
Calling up and confirming relevant configuration information.
In order to be able to follow up on the service request later, a reference number is typically
assigned to the request and the contact details are stored in a repository (tool or database,
depending on the selected tooling for request fulfillment). If the request is rejected, this decision
and the reasons are communicated to the user.
Once accepted, the request is classified, meaning that the request handler performs a request
assessment. This includes understanding and analyzing the request content so that a
categorization is possible as well as a prioritization of the request (based on the rules defined in
the request fulfillment framework). Additionally, all relevant information about the request is
documented in the request details.
Controls
example, firewalls, and encryption) and non-technical considerations (such as segregation
of duties, training needs, user responsibilities).
Request Fulfillment Framework (From: A611)
commitments
•
•
•
•
contracts (UCs).
Inputs
Service Request (From: A65 A653)
Service Request Escalation (From: A615)
Information about a service request that has not been fulfilled in ways that meets
satisfaction criteria and which requires escalation.
8. ITIL V3 Glossary
9. ITIL V3 Glossary
•
•
•
•
Outputs
Service Request_ Rejected
A service request that is not accepted as falling into one of the pre-defined categories for
requests or which fails the entitlement tests. An example of this would be a new
requirement for functionality (for which the user should be guided to invoke the Stakeholder
Requirements process).
Service Request_ Approved (To: A613 A615)
A service request which has met the classification and entitlement rules and which includes
all the information needed for fulfillment. It is ready to be fulfilled or routed.
Request Fulfillment Activity Data (To: A616)
Any data about the accomplishment of process activities that support the evaluation of the
overall Request Fulfillment process.
[A613] Fulfill or Route Service Request

Description
Depending on the request assessment, the service request can be satisfied within this process
(within the remit established by the Request Fulfillment Framework) or routed to other processes.
If the service request is to be fulfilled within the capabilities of this process (for example, by
providing information or guidance), the response to the request will be created and documented
and sent to the user. Either the service request is resolved (the user is satisfied), or the request
handler escalates the issue. The latter can lead to a reconsideration of the request fulfillment
approach or to a transfer to other processes (if the request cannot be fulfilled in a satisfying way
by the request handler).
If the service request has to be transferred to another process, the request item will be assigned
depending on categorization (for example, to Incident Management) or prioritization of the request.
This means that the request including all relevant information and documentation (detailed
description, any advice, guidance) is routed and the receiving process is notified about the
assigned request item.
If the service request is resolved, a check can be made with the user concerning their satisfaction
with the resolution, and all relevant information is updated, culminating with marking the service
request as ready for closure.
Controls
commitments
•
•
•
•

Inputs
Service Request_ Approved (From: A612)
output.
Outputs
Service Request Fulfilled
A service request that has been fulfilled within the Request Fulfillment process or in the
processes to which it had been routed. Is either the actual fulfillment itself (for example,
service usage guidance), or just information about the work carried out elsewhere (such as
notification of incident resolution or confirmation of software download and installation).

•
•
•
•

A75)
target.
Service Request Routing Information (To: A614 A615)
Details of how the work represented by the service request has been assessed and
planned for fulfillment by or to be passed to one or more other processes. The details
include:
• The request classification, including the cases where the request has been re-classified
as an incident or a change request
• The process and specific team or individual where the work has been assigned
Service Request Fulfillment Information (To: A614 A615)
Information about a service request that has been successfully fulfilled.
[A614] Close Service Request

Description
This activity describes the tasks involved in reviewing service requests that have been marked for
closure. It checks that the service request has had the desired effect and met its objectives, and
that users and customers are content with the results, or to identify any shortcomings. It further
examines the work undertaken to fulfill the request and ensures that all data required by the
request fulfillment framework is fully and properly captured. The activity determines whether any
follow-up action (such as the update of request handling documentation) is required and if not, a
formal close of the service request is performed.
Controls
•
•
•
•
commitments
Inputs
Service Request Routing Information (From: A613)
include:
Service Request Fulfillment Information (From: A613)
Service Request Status Input
Details, from any process involved in processing the service request, on status and plan to
complete the work involved. It can include a request to obtain more information or some
form of acknowledgement from the user.
Service Request Status (From: A615)
The status of a service request (received, work in progress, resolved, or closed). Used to
communicate the information to the user (originator of the request).
Outputs
Service Request_ Closed (To: A615)
A service request for which all fulfillment activities have been completed and information
about the fulfillment has been captured.
•
•
•
•
[A615] Own, Monitor, Track and Communicate Service Requests

Description
Throughout the period of request handling and fulfillment the service request status is monitored
for several reasons:
It must be ensured that the status of the request can be communicated to the originating
user at any time.
The status of the request must be known in order to initiate escalation (according to
existing escalation management policies and guidelines) if the current fulfillment status
breaches agreed SLAs.
Monitoring the request status not only relates to individual requests, but also to all requests
collectively so that the overall compliance with SLAs for request fulfillment as a service or part of
a service can be controlled.
Analysis and reporting on the service requests will be carried out on a predetermined basis
(weekly, monthly, and when exceptions are indicated) in order to control the quality of request
fulfillment, the compliance with existing SLAs, for planning purposes and as a basis for
improvements.
Examples of reports to be produced include:
The number, categories, and sources of requests
The elapsed time until requests are fulfilled
The workload per request or per staff member
Analysis of patterns of potentially avoidable requests that might have been caused through
incorrect or inadequate user understanding of service characteristics and features
There will be reports about the availability of the request fulfillment center and the overall
compliance with SLAs. Basically, the reports serve as a measure to check if the service requests
are handled in a way that complies with the agreed targets.
These reports and their analysis will also help to do some trend analysis and forecasting with
regard to service requests, relevant for the planning of staffing and other request fulfillment related
topics. The output of this process will also be available to the knowledge management process with
the objective of enhancing the effectiveness and efficiency of request fulfillment.
Controls
commitments
•
•
•
•
contracts (UCs).
Inputs
Service Request_ Closed (From: A614)
A service request for which all fulfillment activities have been completed and information
about the fulfillment has been captured.
Service Request Routing Information (From: A613)
include:
Service Request Fulfillment Information (From: A613)
Service Request_ Approved (From: A612)

•
•
•
•

Service Request Status Input
Details, from any process involved in processing the service request, on status and plan to
complete the work involved. It can include a request to obtain more information or some
form of acknowledgement from the user.
Outputs
Service Request Status (To: A614)
The status of a service request (received, work in progress, resolved, or closed). Used to
communicate the information to the user (originator of the request).
Service Request Reports (To: A244 A518 A616)
Service Request Escalation (To: A612)
Information about a service request that has not been fulfilled in ways that meet satisfaction
criteria and which requires escalation.
•
•
•
•
[A616] Evaluate Request Fulfillment Performance

Description
The evaluation of the performance of the Request Fulfillment process aims at identifying
improvement areas of the overall process, such as the foundation and interfaces of the process,
all activities, their accomplishment, their degree of automation as well as the roles and
responsibilities including the respective skills.
Basis for the improvements are insights and lessons learned that are gained from the reports and
their analysis. Basically, the improvements should lead to more efficiency and a better compliance
with the SLAs.
Controls
• Technology support{ Structure of the request fulfillment center (often known as or linked
to a service desk)
commitments
Inputs
Request Fulfillment Activity Data (From: A612 A613 A614 A615)
Outputs
Request Fulfillment Evaluation (To: A611)
The result of the evaluation of the Request Fulfillment process, including any identification
of potential process improvement areas.
•
•
•
•

Purpose
The purpose of the Service Execution process is to deliver operational services to IT customers,
by matching resources to commitments and employing the IT infrastructure to conduct IT
operations.
Definition of 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.”17
Outcomes
Services are delivered in a reliable, robust, secure, and consistent manner
Services are provided within service level targets
Resources needed to operate IT services are managed effectively and efficiently
Consumable resources used to deliver services are supplied in a timely manner
Up-to-date service metric information is available
Scope
This process is responsible for the scheduling, operation and execution of the IT-based services
which have been committed to customers. These services are of many types, including business
transaction and batch processing, and also many types of self-service functionality offered as
standard services to users.
Service Execution applies the resources made available to it through Deployment Management to
the dynamic mix of workload demands. It makes adjustments to resource allocations within the
tolerances provided and specified in the solution design.
Includes
Understanding, creation, and maintenance of operational schedules
Starting, stopping, and other operational resource management actions on system
components, applications and other services
Monitoring of system resources
Detecting events and sending significant events to Event Management
Understanding and maintenance of operational status
Managing production workloads from submission through delivery of results and from
service start to service close
Excludes
Correlating and processing significant events (Event Management)
Operational security (Security Management)
Data management, backup, and recovery (Data Management)

•
•
•
•
Controls
contracts (UCs).
Inputs
target.

•
•
•
•

Work Requests
An unqualified request for processing services involving IT resources. To be accepted for
processing, it must contain sufficient detail in order to match it against the list of existing
services and to determine the characteristics (parameters) of this specific request. Work
requests can range from highly granular individual interactions (pressing a function key on
a PC) to a large clump of work (a long running batch job, perhaps with many dependent
steps and subsequent, dependent jobs).
Work Data Input
The data that is submitted along with a work request and which has not yet been
processed (so that it becomes managed data). It could have been captured in many ways
of which keyboard, magnetic card reader, barcode reader, RFID tag are just some
examples.
A452)
timeframe.
Service Resilience Directives (From: A72 A74 A76)
The collection of commands, instructions or other requests from Resilience processes to
the Operations processes which will lead to an improvement in, or correction of, any aspect
of service.
•
•
•
•
Incident_ Resolved (From: A65 A655)

An incident for which a workaround or fix has been successfully applied.
Event Resolution Directive (From: A64 A645)
The set of commands or instructions to resource controlling activities which have been
selected so that the event causing conditions will be resolved.
Operational Monitoring Data (From: A6 A62 A622 A623 A624 A63 A633 A634 A635 A636)
processing status, among others.
Data (From: A63 A634)
All the data items which are being managed within the IT endeavor, and which are made
available for processing or other purposes in line with service commitments.
Outputs
Work Requests_ Completed
The results, in terms of data and any confirmation responses, returned to the work
requestor upon completion of the triggering request for work to be performed by the IT
operational service. This output represents the fundamental item for which the customer is
paying; that is, the processing of transactions whether real time or batched.
Can include negative outcomes, such as unsuccessful processing, resource authorization
failure, and resource insufficiency.
Operational Service Project Proposals
Proposals, from the Framework activities within the Operations category, for project
funding. The proposals will go to the Portfolio Management process for decision. The
proposal content will be for purposes such as:
• To establish additional or improved capabilities for performing any activities or tasks
within the process
• To satisfy the operational needs of new technical solutions coming on-stream
• To improve any relevant aspect of service performance
Service Execution Metric Data and Reports
Significant service execution event logs, volume and other measurement data relating to
how effectively and efficiently service execution has been performed. This data, which is
available as requested both in raw format and as structured reports, is a component of all
Operations Information and is the basis for service level reporting.
A655 A66 A662 A7 A73 A735 A74 A743)
Information relating to the overall item-by-item outcomes and status of the IT operation
IT Administration Support Data and Requests
Covers requests for supply of new or additional consumable materials and relevant data
reporting on consumption and usage of the consumables (tapes, paper, toner, forms, and
others), which might be required for charging.
•
•
•
•

Data_ Derived (To: A63 A634)
Any informational item created or modified as part of the workings of any business process
and which is to be managed within an IT service. Data could be specific information like
order numbers, invoice numbers, receipts, inventory change data, and could be received in
batches or in individual transactions. It can relate to business processes, or be relevant to
the management of the IT endeavor.
Data Lifecycle Request (To: A63 A632 A634 A636)
The identification of any need for a lifestyle management action of any data item as part of
productive usage of that data.
Activities
Architecture Baselines SLAs OLAs UCs IT Plan IT Management Skills Inventory/D1 O5
and Roadmaps C2 C3 Ecosystem Change
C4 C1 Request
O3
Operational Service
I9 Project Proposals
Solution Design
Service Execution
Framework
I5
Establish
Solution Service
Plans and Execution Operational
Commitments
Framework Schedules
I2 A621 Work Requests_
Change Integrated Rejected
Information Solution Capabilities Work Schedule
I6 and Operational Procedures
Service Resilience Schedule
Plans O10
and Adjust Data Lifecycle
I10 Workload Request
Solution_ Recovered
Deployed Service A622 Work Item O7
I3 Schedule Consumables IT Administration
Work Status Work
Order Support Data
Requests Item
I1 and Requests
Service Request_ Assign and Security Work Request/S2
Authorized Delivery Control
Resources Delivery O2
Operational Delivery Resources_ Identity and Access
Documentation/D1 Resources Assigned Work Request
I11 A623
Incident_ Resolved Delivery Maintenance and O9
Resources_ Replenishment Schedule Data_ Derived
Recovered Resource
I7 Status Deliver
Service Service
Resilience O1
Directives/D1 Work Requests_
Completed
I14 A624
Data O6
Consumption Operational
Data Monitoring Data
I8 Delivery Work Item_ Monitor and
Configuration Resources_ Multi Phase Report
Information Released Service O4
Security Service Execution
Response/D1 Execution Metric Data and Reports
I12 Maintenance and Operations
Event Resolution Replenishment Data A625 O8
Directive Incident
Resource Evaluate
I13
Operational Adjustments Service Service Execution
Monitoring Data Execution Evaluation
Service Execution
I4 Activity Data
Performance
A626
Work
Data Input
Identity and
Access Response/D1
NODE: A62 TITLE:

Service Execution CURRENT PAGE:
Figure 3. A62 Service Execution
•
•
•
•
[A621] Establish Service Execution Framework

Description
This is the activity of defining and documenting the rules and policies governing day-to-day service
execution activities. The purpose of this activity is the creation of a working framework geared to
deliver agreed services to the customer of information technology. All services must meet
expected quality, be within budget, and in such a way as to produce a high degree of customer
satisfaction while keeping to the IT strategy.
Controls
contracts (UCs).

•
•
•
•
Skills Inventory (From: A844)

Repository for current and planned skills.
Maintenance and Replenishment Schedule (From: A625)
The time, date, quantity and other related information relating to the maintenance of
delivery resources and to the re-supply of consumable materials.
Inputs
A452)
timeframe.
Solution Capabilities and Operational Procedures
The capabilities and operational procedures deployed as part of current solutions. These
might require further development and tuning in order to reach optimal effectiveness as
part of Service Execution.
(Subset of Solution Deployed.)
output.
Service Execution Evaluation (From: A626)
A report or data providing measurements, trending and metrics on the health and
performance of Service Execution. Includes identification of potential process improvement
areas.
•
•
•
•
Outputs
within the process
Service Execution Framework (To: A622 A623 A624 A625 A626)
The overall scheme of documents, plans, processes, and procedures designed to govern
and optimize all activities for Service Execution. The framework includes:
• Operational Procedures
• Service Execution Plan
Operational Schedules (To: A51 A515 A52 A521 A522 A53 A532 A622 A623 A624 A625
A743)
Service Execution Activity Data (To: A626)
[A622] Schedule and Adjust Workload

Description
This activity operates at both a macro and micro-level to prepare work schedules, and to
preprocess work items where necessary so that they are ready for actual processing. It operates
in concert with the activity that ensures the delivery resources can be matched to the demands of
the flow of work in an optimal fashion.
Controls
Service Execution Framework (From: A621)
•
•
•
•

Inputs
Work Requests
An unqualified request for processing services involving IT resources. To be accepted for
processing, it must contain sufficient detail in order to match it against the list of existing
services and to determine the characteristics (parameters) of this specific request. Work
requests can range from highly granular individual interactions (pressing a function key on
a PC) to a large clump of work (a long running batch job, perhaps with many dependent
steps and subsequent, dependent jobs).
target.
Recovered Service Status
Status information on the recovered service.
of service.
Work Item_ Multi Phase (From: A624)
A partially-completed output created by Deliver Services that flows internally within the
process. The output would signify that other service execution activities would need to be
started. An example of this complex work item is a payroll application: a new employee is
added, the new employee can create a new work item to add a new person to an enterprise
employee directory. The directory update service is triggered by the payroll addition
service.
Resource Status (From: A623)
Information pertaining to the status of any IT resource that is used in the provision of
service. The status could be available, not available, failing, over-utilized, approaching peak
usage, and would include actual status and predictive information for ensuring adequate
availability of resources at all times. This also includes Resource Commit Failure.
Outputs
Rejected Work Requests
Notification that the request does not comply with work request acceptance criteria, and
therefore was rejected.
Data Lifecycle Request (To: A63 A632 A634 A636)
The identification of any need for a life cycle management action of any data item as part of
A655 A66 A662 A7 A73 A735 A74 A743)
•
•
•
•
Integrated Work Schedule (To: A623 A624)

A consolidation of all individual work item schedules (planned out sequence of work) based
on resources, commitments, skills and available services.
Work Item Schedule (To: A623 A624)
Control information on the combination of the work item, the required IT resources, and the
timing parameters and instructions which enable matching of work demands with resource
supply.
Work Item (To: A624)
The basic unit of work of an IT service or work request, ready to be processed.
[A623] Assign and Control Delivery Resources

Description
This activity assigns, monitors, and adjusts IT delivery resources on a real-time basis against the
current mix of workload that has been requested. It applies the appropriate resources, from those
available and within their capacity and other operational characteristic limitations, to be ready to
deliver and execute those workload requests. It also works to optimize the output capability of each
resource by, for example, carrying out resource housekeeping and maintenance when indicated.
Controls
Integrated Work Schedule (From: A622)
Maintenance and Replenishment Schedule (From: A625)
Inputs
Work Item Schedule (From: A622)
supply.
Delivery Resources
Technological and people resources which can be utilized in the process of delivering IT
services to the organization.
•
•
•
•
Delivery Resources_ Recovered

Any IT delivery resources which have been restored to normal (or acceptable) operational
capability as a result of incident resolution.
of service.
• For a protection request – the protections put in place
• For an access authorization request – success or failure of the request
Resource Adjustments (From: A625)
Adjustments to IT technical resources that might be required to optimize service execution
as a result of analysis of the service execution data, workload, and so forth.
Delivery Resources_ Released (From: A624)
Resources (tapes, storage devices, networks, LANS, programs, data stores, processors,
memory) that have been used in the process of performing operational services but are
now available for re-assignment to other work.
Outputs
Consumables Order
An order for materials used up in the process of providing agreed-to services. Materials like
paper, magnetic tape, printer toner or ribbons, and others are included.
A655 A66 A662 A7 A73 A735 A74 A743)
Delivery Resources_ Assigned (To: A624)
All IT resources required and available to perform the required service.
•
•
•
•
Maintenance and Replenishment Data (To: A625)

Information pertaining to maintenance activities and to restocking consumable resources.
This data could include resource name, amount replenished, location, vendor, and other
information.
Resource Status (To: A622)
Information pertaining to the status of any IT resource that is used in the provision of
service. The status could be available, not available, failing, over-utilized, approaching peak
usage, and would include actual status and predictive information for ensuring adequate
availability of resources at all times. This also includes Resource Commit Failure.
[A624] Deliver Service

Description
This activity processes work items through the series of value-added actions which constitute the
requested service. It employs the appropriate combination of human and technology resources
necessary to perform those actions. It delivers the work results, both final data and processing log,
to the specified destinations.
Controls
Work Item Schedule (From: A622)
supply.
Integrated Work Schedule (From: A622)
Inputs
Delivery Resources_ Assigned (From: A623)
All IT resources required and available to perform the required service.
Work Item (From: A622)
The basic unit of work of an IT service or work request, ready to be processed.
•
•
•
•

Work Data Input
The data that is submitted along with a work request and which has not yet been
processed (so that it becomes managed data). It could have been captured in many ways
of which keyboard, magnetic card reader, barcode reader, RFID tag are just some
examples.
Identity and Access Response (From: A673 A674)
The result of processing an identity and access request. The result will reflect a rnage of
• For an identiy request – actions taken to create, maintain, or delete the identity
• For an access (rights) request – the success or failure of the request, with relevant
Outputs
Data_ Derived (To: A63 A634)
The results, in terms of data and any confirmation responses, returned to the work
requestor upon completion of the triggering request for work to be performed by the IT
operational service. This output represents the fundamental item for which the customer is
paying; that is, the processing of transactions whether real time or batched.
Can include negative outcomes, such as unsuccessful processing, resource authorization
failure, and resource insufficiency.
A655 A66 A662 A7 A73 A735 A74 A743)
Work Item_ Multi Phase (To: A622)
A partially-completed output created by Deliver Services that flows internally within the
process. The output would signify that other service execution activities would need to be
started. An example of this complex work item is a payroll application: a new employee is
added, the new employee can create a new work item to add a new person to an enterprise
•
•
•
•
employee directory. The directory update service is triggered by the payroll addition
service.
Delivery Resources_ Released (To: A623)
Resources (tapes, storage devices, networks, LANS, programs, data stores, processors,
memory) that have been used in the process of performing operational services but are
now available for re-assignment to other work.
[A625] Monitor and Report Service Execution Operations

Description
Examines all monitoring data from the operational delivery tasks within Service Execution and
analyzes it against targets to identify any requirement for intervention. Intervention possibilities
include within-guidelines resource adjustments and signaling to invoke Incident Management for
circumstances that cannot be addressed within this process.
The analysis also provides the basis for reporting (as defined by the framework). These reports
could include attainments, trending, and the identification of current and potential issues, as well
as the production of the service metric data required by many Service Management processes.
Controls
• Service Execution Plan.
Inputs
Maintenance and Replenishment Data (From: A623)
Information pertaining to maintenance activities and to restocking consumable resources.
This data could include resource name, amount replenished, location, vendor, and other
information.
Outputs
Maintenance and Replenishment Schedule (To: A621 A623)
Consumption Data
Usage statistics for consumable supplies reported with each use and intended to be the
basic information that would lead the IT organization to know when consumables are
nearing depletion so the material can be re-supplied without disruption to processing.
•
•
•
•
Service Execution Metric Data and Reports

Significant service execution event logs, volume and other measurement data relating to
how effectively and efficiently service execution has been performed. This data, which is
available as requested both in raw format and as structured reports, is a component of all
Operations Information and is the basis for service level reporting.
Resource Adjustments (To: A623)
Adjustments to IT technical resources that might be required to optimize service execution
as a result of analysis of the service execution data, workload, and so forth.
[A626] Evaluate Service Execution Performance

Description
This activity evaluates the current performance of the Service Execution process against the
established Service Execution Framework. Specific feedback is provided to the Service Execution
Framework to help tune the overall effectiveness and efficiency of Service Execution.
The evaluation of process performance identifies areas that need improvement; such as the
Controls
• Service Execution Plan.
Inputs
Service Execution Activity Data (From: A621 A622 A623 A624 A625)
Outputs
Service Execution Evaluation (To: A621)
A report or data providing measurements, trending and metrics on the health and
performance of Service Execution. Includes identification of potential process improvement
areas.
•
•
•
•

Purpose
The purpose of the Data Management process is to ensure that all data necessary in providing and
supporting business and operational services is available for use and is actively managed from
creation and introduction until final disposal or destruction.
Outcomes
Data life cycle management policies and governance capabilities are effectively provided
Data life cycle management services are sustained in order to meet or exceed service level
commitments
Legal, regulatory, and business requirements are met for data privacy, quality, and retention
The accessibility, performance, cost, and value characteristics of data are established,
managed and optimized throughout the full life cycle
The integrity of data at all stages of its life cycle is ensured, including protection of business
(and IT) data from accidental loss and destruction
Scope
Management of the full life cycle of both externally acquired and enterprise generated data, as well
as information about that data.
Includes
Managing data as a portfolio and the overall plan for the portfolio’s elements
Cataloging and controlling all data types, such as:
– Business data
– Journals and logs
– Program libraries
– Systems management data
Accepting and cataloguing new data
Planning and control of data placement, retention, and disposalData backup and
restoration of data to prior states
Excludes
Information management activities:
– Data typing and classification (Architecture Management)
– Content management (Business responsibility, as part of each business process)
Change management
Access control and security protection (Identity and Access Management, Security
Management)
•
•
•
•
Controls
contracts (UCs).
compliance

•
•
•
•

implemented.”27
Inputs
target.
Data_ Derived (From: A62 A624)
Data Lifecycle Request (From: A62 A622)
of service.

•
•
•
•

Outputs
within the process
Data Management Metric Data and Reports (To: A632 A634)
Significant event logs, volume and other measurement data relating to how effectively and
efficiently data and storage work has been performed. This data, which is available as
requested both in raw format and as structured reports, is a component of all Operations
Information and is a basis for service level reporting.
• Attributes
• Relationships
A655 A66 A662 A7 A73 A735 A74 A743)
Data (To: A62 A623 A635 A636)
•
•
•
•
Activities
Architecture Baselines IT Management IT Plan Compliance Plans SLAs OLAs UCs Change Schedule
and Roadmaps Ecosystem C3 and Controls C2
I6 C1 C6
C5 C4
Service Resilience
Plans O1
Operational Service
Project Proposals
I7 Establish
Service
Resilience Data
Directives/D1 Management Data
Framework Management
I5 Data Lifecycle Framework
Change A631
Management
Information Plan
Plan Data Security Request/S1
Portfolio
I9 Lifecycle
Solution Design O3
A632 Acquire and CI Data
Prepare Data_ Update Package
Data_ External
Prepared
Data
A633
Data
I10 Control, Resource
Solution_ Deploy Catalog
Deployed
and
I3 Maintain
Data_ Derived O6
I4
Data Data
A634
Data Lifecycle Implementation
Request Backup Progress Data/S1
and
Restore
Security Data Backed Up Data
Response/D2 A635 and Manifest
I2
Operational Dispose Data_ Disposed
Monitoring Data Data_ Restored of Data O4
I8 Operational
Configuration Monitoring Data
Information A636
I11 Disposal Notification Monitor and
Event Resolution O5
Backup Restore Report Incident
Directive
Request Request Data
I1
Management
Service Request_ Operations
Authorized A637
O2
Evaluate Data
Change Data Management
Implementation Metric Data
Communication/D1
Management
and Reports
Performance
Data Management A638
Activity Data Data
Management
Evaluation
NODE: A63 TITLE:

Data Management CURRENT PAGE:
Figure 4. A63 Data Management
•
•
•
•
[A631] Establish Data Management Framework

Description
of the Data Management process and its activities.
Incorporate mandatory elements from the IT Management Ecosystem.
Define a set of measures to be used by each process for measurement and reporting of
performance.
effectiveness.
Controls
Inputs
Data Management Evaluation (From: A638)
Outputs
within the process
Data Management Framework (To: A633 A634 A635 A636 A637 A638)
The Data Management Framework guides the operation of the process, and includes the
• Classes of data (relevant for data management, to indicate factors such as backup
scope and frequency)
•
•
•
•
• Data life cycle models

• General approach to what storage media types will be used for which classes of data
• Instructions for data retention that implement Corporate policies and controls (which
themselves include the impact of regulatory requirements)
• Capacity Management plans that affect Data Management
• Data Management requirements based on existing SLAs
[A632] Plan Data Portfolio Lifecycle

Description
Identify each candidate collection of data.
Determine the life cycle management requirements and characteristics of each candidate.
Analyze the current portfolio of data and data practices to identify suitable existing practices and
needs for new and modified life cycle practices.
Plan the life cycle management scheme for each collection of data.
Controls
compliance
contracts (UCs).

•
•
•
•
implemented.”31
Inputs
of service.
Data Management Metric Data and Reports (From: A63 A637)

•
•
•
•
Outputs
Data Lifecycle Management Plan (To: A633 A634 A635 A636 A637)
The specification of the life cycle management plan for each class or type of data, allowing
for the possibility that an individual collection of data could have unique life cycle
management requirements. The life cycle plan will cover aspects such as:
• Media types to be used, for each activity level of data (such as currency)
• Archive parameters
• Backup plan
• Selection of data sensitivity classification
Data Management Activity Data (To: A638)
[A633] Acquire and Prepare Data

Description
Obtain or receive a data collection (per schedule).
Convert, transform or otherwise prepare (extract, clean up) the data.
Package the data.
Controls
Data Lifecycle Management Plan (From: A632)
• Backup plan
Data Management Framework (From: A631)
•
•
•
•
Inputs
Data_ External
Data sourced and obtained from outside the current service coverage. Examples of this
would include:
• Reference data, from external providers, such as postal coding schemes
• Transaction data from external partners, such as banks
Outputs
A655 A66 A662 A7 A73 A735 A74 A743)
Data_ Prepared (To: A634)
Data that has been collected (acquired) and prepared (filtered, grouped, reordered,
rearranged) to match the planned usage. Prepared data is ready to be placed (deployed)
onto its target media and managed throughout its life cycle.
[A634] Control, Deploy and Maintain Data

Description
The site or place the data is located, which invokes the Security process for applying the required
protections.
Catalog the data, and maintain it with other life cycle activities for which notification is received.
Maintain the data's operational characteristics throughout its deployment.
Migrate data when indicated by policy. The types of migration include from one technology to
another, and across locations and system images.
Archive data.
Controls
• Backup plan
•
•
•
•
Inputs
Data_ Prepared (From: A633)
Data that has been collected (acquired) and prepared (filtered, grouped, reordered,
rearranged) to match the planned usage. Prepared data is ready to be placed (deployed)
onto its target media and managed throughout its life cycle.
Data_ Derived (From: A62 A624)
Data Management Metric Data and Reports (From: A63 A637)
•
•
•
•
Disposal Notification (From: A636)

Notification that one or more collections of data have been disposed of and are no longer
accessible.
Data_ Restored (From: A635)
Availability of data for productive or other use as a result of restoring it.
Outputs
Security Request (To: A726)
System or external request to secure IT resources or validate authority for access.
• Secure IT resources: identifies one or more specific resources which need to be
included in the security protection scheme, or need to have their level and means of
protection adjusted
• Request to access: a communication soliciting access to a particular resource or class of
resources
• Attributes
• Relationships.
A655 A66 A662 A7 A73 A735 A74 A743)
Data Resource Catalog (To: A635 A636)
The master record of the location and disposition of every data collection under data
management. Depending on the policy choices as specified within the framework, it can
include usage records such as space employed and lists of users (people, programs) by
time and date.
Data (To: A62 A623 A635 A636)
•
•
•
•
[A635] Backup and Restore Data

Description
This activity provides for the local and remote backup and restoration of data from one storage
medium to another. It includes replication of data from like storage to like storage and is primarily
used to satisfy availability and disaster recovery requirements.
Controls
• Backup plan
Inputs
Data Resource Catalog (From: A634)
time and date.
Backup Request
Service Requests from any user or other process that a backup be taken.
Restore Request
Service Requests from any user or other process for a data restore to be performed.
•
•
•
•

Outputs
change or release.
Backed Up Data and Manifest (To: A765 A766)
The data which is the result of taking a backup, in whatever format (for example,
compressed, incremental) which has been selected as the basis for any subsequent
restore action, plus the indexes and inventories (the manifest) of the content with regard to
specific file placement on backup media.
A655 A66 A662 A7 A73 A735 A74 A743)
Data_ Restored (To: A634)
Availability of data for productive or other use as a result of restoring it.
[A636] Dispose of Data

Description
Destroy or delete the data so that it is no longer stored and cannot again be accessed. The
disposal technique will vary in terms of completeness of data destruction in line with the
designation of data sensitivity.
Provide notification so that the data resource catalog can be updated to reflect the disposal.
Controls
• Backup plan
•
•
•
•

Inputs
Data Resource Catalog (From: A634)
time and date.
Outputs
Data_ Disposed
The data that has been taken out of active management. Depending on how it has been
stored, it can include the associated media; for example, paper or microfiche records.
A655 A66 A662 A7 A73 A735 A74 A743)
Disposal Notification (To: A634)
Notification that one or more collections of data have been disposed of and are no longer
accessible.
•
•
•
•
[A637] Monitor and Report Data Management Operations

Description
Monitor all aspects of Data Management, including:
State changes of each and every collection of data
Matching data status against policies in case action is required (for example, to trigger
migration of data between media)
Identify activity which has resulted in data not matching its expected operational characteristics
and raise incidents as necessary.
Create data management metrics, including trend data, and reports. Reports can be regular or ad
hoc, as circumstances occur.
Controls
• Backup plan
Inputs
Outputs
•
•
•
•
Data Management Metric Data and Reports (To: A632 A634)

[A638] Evaluate Data Management Performance

Description
This activity is designed to measure the effectiveness and efficiency of different aspects of the
Data Management process, by ensuring that all the necessary information necessary for its
management is available for making informed decisions related to the process.
The evaluation of process performance identifies areas that need improvement. This includes the
Controls
Inputs
Data Management Activity Data (From: A632 A633 A634 A635 A636 A637)
Outputs
Data Management Evaluation
process framework and an identification of possible process improvement areas.(To: A631)
•
•
•
•

Purpose
The purpose of the Event Management process is to identify and prioritize infrastructure, service,
business process and security events, and to establish the appropriate response to those events,
especially responding to conditions that could lead to potential faults or incidents.
Definition of event: “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.”32
Outcomes
As a result of the successful implementation of the Event Management process:
Service quality is sustained and improved
Incidents are detected early
The time between event occurrence and detection is minimized
Appropriate actions are taken in response to events, in order to resolve some without
manual response
Responses to understood faults are started with minimal delay
Scope
Event Management is accomplished through scanning monitoring data and from this collecting,
evaluating, responding to, and reporting events throughout the business.
Not all events require a response, only those deemed significant events. Typically, a response to
a significant event involves either a predefined response or the creation of an incident in the
Incident Management process.
Includes
Providing both real time and historical event information to other IT processes, to
facilitate service quality improvement and resource availability
Providing similar information relating to the automated aspects of business processes
for business analysis
Correlation and filtering of events, to identify alert notifications and other conditions
Examination and analysis of individual events in isolation as well as events in context
with other events
Creation of incidents from event information
Capture, logging and administration of data generated by the activities within this
process
Excludes
System monitoring – Monitoring all things that happen related to a system, whereas
event management identifies meaningful changes of state that can represent faults.33
System monitorig takes place in Service Execution and Data Management.

•
•
•
•
Controls
contracts (UCs).
Inputs
33. ITIL Service Operation, 36

•
•
•
•

Security Monitoring Data (From: A72 A726)
Information relating to the overall item-by-item outcomes from, and status of, security. This
can include details of access requests, authentications processed, attacks received and
warning thresholds triggered.
Identity and Access Monitoring Data (From: A67 A673 A674)
Data produced during or about the processing performed against identities and access
right records. In addition to item-by-item outcomes, the data can include measurements of
resource utilization, transaction volumes, processing status, among others.
Outputs
within the process
•
•
•
•

• Attributes
• Relationships.
Event (To: A643 A65 A654 A66 A662)
Details of individual and collective events. They are available to any Service Management
process for investigation, diagnosis and other analytical purposes on a real-time or
historical basis.
ITIL defines Alert as: “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.”37
Event Resolution Directive (To: A62 A622 A623 A624 A63 A634 A635)
Activities
A643 Filter Event
A645 Resolve Event
A646 Close Event

•
•
•
•
IT Management IT Plan Architecture Baselines SLAs OLAs UCs Change Management

I7
Ecosystem C4 and Roadmaps Framework/D1
Solution Design C3
C1 C2
I2 O1
Solution_ Operational Service
Deployed Project Proposals
Establish
Event
I3 Management Event
Change Management
Framework Framework
Information A641
I4
Service Resilience Detect
Plans and O5
Event
Log Event
Event_
I1 A642 Significant
Operational
Monitoring Data Filter Event
I5 O2
Security Change
Monitoring Data/D1 Request
I6
A643 Event_
Configuration
Processed
Information
I8 Correlate
O4
Identity and Access Events and
Monitoring Data Incident
Select
Response
Event_ A644
Escalated
Resolve O6
Event Directive
Event_
Analysis Event_ Ready for
Updates Derived A645
Closure
O3
CI Data
Close Event Update Package
Event_
Closed
A646
Evaluate
Event Event
Evaluation
Event Management Performance
Activity Data A647
NODE: A64 TITLE:

Event Management CURRENT PAGE:
Figure 5. A64 Event Management
[A641] Establish Event Management Framework

Description
Based on the business and IT strategy and the architectural models, guidelines and a framework
for Event Management have to be developed. The tasks in this activity include:
Understanding the requirements and specifications for Event Management
Defining the strategy for event solutions over and above those provided within individual
solutions. For example, should they be developed in-house or rely more on vendor
capabilities
Defining evaluation criteria for event solutions and services
Establishing the framework for Event Management by defining and implementing practices
and systems that support process activities
Based on these capabilities, determining skill requirements for the staff and assigning staff
Finally, the structure and process of Event Management, including escalation responsibilities, has
to be communicated to the process users.
The establishment of the process framework also includes the continuous improvement of Event
Management: the consideration of the Event Management process evaluation and the
•
•
•
•
Controls
contracts (UCs).
Inputs

•
•
•
•
Event Management Evaluation (From: A647)
Outputs
within the process
Event Management Framework (To: A642 A643 A644 A645 A646 A647)
Includes the following:
• Specification of what makes an event
• Specification of what makes a significant event
• Identification of significant events that can be processed (responded to), and what those
procedures are
• Practices for logging and filtering events
• Definition of the event life cycle
•
•
•
•
[A642] Detect and Log Event

Description
In this activity, monitoring data from various system resources are input and converted into events.
Monitoring data can be generated by a vast number of system resources. The data might be
generated by a resource or by a monitor of that resource. This data is used to identify status
changes to resources.
Many system resources generate monitoring data that is not indicative of a fault. This activity
monitors that data in order to identify all potential events contained in the data. Events generated
by this activity are also recorded. This information includes information about Managed Objects
(MOs) related to events and might be necessary for the resolution of incidents, problems,
reviewing SLAs, or other service management purpose.
Controls
Event Management Framework (From: A641)
procedures are
Inputs
Event Analysis Updates
Any additional data added to (but not modifying) the primary data of a logged event as a
result of other IT processes carrying out their investigations. Examples of such processes
would be Incident, Capacity and Availability Management.
Event_ Derived (From: A644)
A new event created as a result of correlation across multiple events, usually signifying
some new out-of-tolerance conditions requiring action.
•
•
•
•
Outputs
Event (To: A643 A65 A654 A66 A662)
historical basis.
logged.”41
Event Management Activity Data (To: A647)
customer (of this process) feedback, priorities.
[A643] Filter Event

Description
The stream of logged events is examined and filtered to identify only those abnormal events for
which a response is needed. These remaining events, designated as significant events, indicate
an abnormal state of an MO. This set of significant events requires a response from either Event
Management activities or from the Incident Management process. This activity is also responsible
for determining the appropriate time frame for event resolution.
Controls
procedures are
Inputs
Event (From: A64 A642)
historical basis.
logged.”42

•
•
•
•
Event_ Escalated (From: A644)

An event, or set of events, that requires re-examination and filtering as a result of event
processing or correlation. This is typically indicated by increasing the priority classification.
Outputs
Event_ Significant (To: A644)
Unsolicited, (formatted), significant information which must be communicated from a
managed object for the purpose of meeting a management objective.
An Alert is an example of a significant event. It is defined by ITIL as: “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.”43
[A644] Correlate Events and Select Response

Description
This activity eliminates duplicate events, correlates multiple events, and throttles processing of
repeated events. The criticality of the event is assessed to determine if it should be escalated.
Correlated events are either routed for handling within Incident Management or preferably,
designated for automated resolution within the scope of Event Management. The Event
Management Framework identifies rules used to determine how to process various categories of
significant events. This can include opening an incident, changing the status or severity of an
event, dropping an event, or sending the event for automated recovery (Resolve Events).
Controls
procedures are
Inputs
Event_ Significant (From: A643)
Unsolicited, (formatted), significant information which must be communicated from a
managed object for the purpose of meeting a management objective.
An Alert is an example of a significant event. It is defined by ITIL as: “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.”44

•
•
•
•
Outputs
Event_ Processed (To: A645)
An event which has been analyzed for cause of out-of-tolerance conditions and led to its
creation for which a plan, within the scope of Event Management, has been formulated to
resolve those conditions.
Event_ Ready for Closure (To: A646)
The complete audit trail of an event and all states of processing through its life cycle.
Event_ Derived (To: A642)
A new event created as a result of correlation across multiple events, usually signifying
some new out-of-tolerance conditions requiring action.
Event_ Escalated (To: A643)
An event, or set of events, that requires re-examination and filtering as a result of event
processing or correlation. This is typically indicated by increasing the priority classification.
[A645] Resolve Event

Description
During this activity, events are flagged as ready for closure. Some events will have required no
direct resolution action; others will have. In the latter case, this can mean that the fault has been
corrected, and so closure is straightforward.
However, it can also be that the fault still exists and so an incident notification is needed.
Depending upon the design of the Event Management solution, events of this type could be closed
immediately or remain open until the relevant Service Management processes indicate readiness
for closure.
In either case, when the event is closed the success or otherwise of its resolution is indicated.
Controls

•
•
•
•
procedures are
Inputs
Event_ Processed (From: A644)
An event which has been analyzed for cause of out-of-tolerance conditions and led to its
creation for which a plan, within the scope of Event Management, has been formulated to
resolve those conditions.
Outputs
Event Resolution Directive (To: A62 A622 A623 A624 A63 A634 A635)
• Attributes
• Relationships
Event_ Ready for Closure (To: A646)
•
•
•
•
[A646] Close Event
[A646] Close Event

Description
During this activity, events that went through Resolve Events are closed. Typically, this means that
the fault has been corrected. However, it can also be that the fault still exists. In either case, the
event is closed and the success of its resolution is indicated.
Controls
procedures are
Inputs
Event_ Ready for Closure (From: A644 A645)
Event Analysis Updates
Any additional data added to (but not modifying) the primary data of a logged event as a
result of other IT processes carrying out their investigations. Examples of such processes
would be Incident, Capacity and Availability Management.
Outputs
Event_ Closed
The event audit trail and life cycle with the addition of any information from the event
closure activity.
•
•
•
•
[A647] Evaluate Event Management Performance

Description
Performance evaluation of the Event Management process aims to identify overall areas requiring
improvement. For example, the foundation and interfaces of the process, all activities, their
accomplishment, their degree of automation, as well as the roles and responsibilities including the
respective skills. Basis for improvements are the insights and lessons learned from the
observations and analysis of activity accomplishments and results.
In this activity, the performance of the Event Management process is analyzed and reported. The
following are included in the analysis:
Number and type of events
Event trends
Event resolution trends
Event detection effectiveness
Event filtering rules
Event processing scripts
Event management life cycle
Controls
procedures are
Inputs
Event Management Activity Data (From: A642 A643 A644 A645 A646)
Outputs
Event Management Evaluation (To: A641)
•
•
•
•

Purpose
The purpose of the Incident Management process is to focus on the restoration of a service
affected by any real or potential interruption which has impact upon the quality of that service.
Definition of incident: “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.”45
Outcomes
As a result of the successful implementation of the Incident Management process:
Following interruptions, IT service is rapidly restored
IT service availability is sustained at a high level
Potential improvements to services may be identified
Normal service operation is defined here as working within agreed service level targets.
Scope
The management of the life cycle of incidents (including reception, logging, acknowledgement,
classification, response, tracking and reporting) for all components involved in the provision of IT
service.
Includes
Incidents reported by users or discovered within the IT organization by automation or
people
Handling (automatically or with human assistance) of system events that have been
identified as incidents by the Event Management process
Creation of workarounds
– While service restoration has the highest priority, consideration has to be made of
the risk that a workaround could exacerbate the original incident. For example,
certain virus infections might spread beyond their initial scope if a simple service
restoration is put into effect
Implementation of workarounds (with Change Management, where required by the
change policy)
Participation within the procedures (typically involving several processes working in
conjunction) defined for handling major incidents

•
•
•
•
Excludes
Monitoring (Service Execution, Data Management)
Responding to business-as-usual perturbations in the running of services (Event
Management)
Service requests (Request Fulfillment)
IT Resilience – ensuring the continued readiness and integrity of the IT services
(Resilience category processes)
Controls
contracts (UCs).

•
•
•
•
Inputs
processing status, etc.
A644 A646 A67 A675 A7 A72 A75 A754)
an interruption to one ore more services. Incidents can be created using either manual or
historical basis.
logged.”49

•
•
•
•
Outputs
• Attributes
• Relationships
Incident_ Resolved (To: A62 A656 A657)
A662 A7 A72 A726 A73 A736 A74 A744 A75 A754)
Service Request (To: A61 A612)

•
•
•
•
Activities
A656 Close Incident
IT Plan IT Management SLAs OLAs UCs
C3 Ecosystem C2
C1
I7
Solution Design
Establish
I5 Incident Incident
Service Resilience Management Management
Plans Framework
Framework
A651 Incident_
Logged Asset Data
I2 Identify Update Package/S1
Incident and Log O1
Incident CI Data
Update Package
A652
I6
Classify O5
Configuration Incident and Service Request
Information Provide Initial Incident_
Incident_ Support Classified Incident_
Needing A653 Resolution
Reclassification Plan
Operational Investigate
Documentation/D3 and
Diagnose O2
Knowledge
Incident Change
A654 Request
Assets/D1
Resolve
Incident and O3
I1 Recover Incident_ Resolved
Operational
Monitoring Data Service
A655
Incident_
I4 Incident_ Incident
Resolution Unsuccessful
Change Close Closed Communication
Information Incident to User
I8
Problem
Information A656
I3 Own,
Event
Change Monitor,
O4
Implementation Track and Incident
Communication/D3 Communicate Information
Incidents
A657
Evaluate
Incident
Request for Management
Incident Status
and Information Incident Management Performance
Activity Data A658
Incident
Management
Evaluation
NODE: A65 TITLE:

Incident Management CURRENT PAGE:
Figure 6. A65 Incident Management
•
•
•
•
[A651] Establish Incident Management Framework

Description
of the Incident Management process and its activities.
Incorporate mandatory elements from the IT management ecosystem.
Define a set of metrics to be used by each process for measurement and reporting of performance.
effectiveness.
Controls
contracts (UCs).

•
•
•
•
Inputs
Incident Management Evaluation (From: A658)
An analysis of how well the Incident Management process was performed. This can also
include suggested areas for modifications to the Incident Management Framework.
output.
Outputs
Incident Management Framework (To: A652 A653 A654 A655 A656 A657 A658)
The set of policies and procedures for performing the Incident Management process,
including data items such as:
• Priority and severity classification schemes
• Resolution targets
• Tables identifying teams to be assigned, by system or service

•
•
•
•
[A652] Identify and Log Incident
[A652] Identify and Log Incident

Description
To detect or acknowledge incidents from other activities, record basic details about the incident,
notify Configuration Management and Asset Management processes as necessary. Also, to alert
support groups as necessary.
Controls
Incident Management Framework (From: A651)
Inputs
A644 A646 A67 A675 A7 A72 A75 A754)
Outputs
• Attributes
• Relationships
Incident Management Activity Data (To: A658)
Incident_ Logged (To: A653 A657)
An identified incident that has been saved in a database.
•
•
•
•
[A653] Classify Incident and Provide Initial Support

Description
Determine the impact, urgency and priority of logged incidents.
Identify the reasons for the incident, using initial diagnosis
Compare to Problems and Known Errors
Correlate with other Incidents
Assess related configuration details
If the incident is assessed as no trouble found, it is transferred to the Request Fulfillment process
as a Service Request. Incidents exceeding a defined threshold of impact and urgency are
categorized as Major Incidents and the appropriate procedure is invoked.
Controls
Inputs
Incident_ Logged (From: A652)
Incident_ Needing Reclassification (From: A654 A657)
An incident that requires to be moved to a different classification, perhaps to a different
team.
Incident_ Resolution Unsuccessful (From: A655)
An incident for which a workaround or fix was not provided or was unsuccessful. Normally,
an incident should eventually yield a workaround or a fix for that incident. However, in some
situations, no workaround or fix works to resolve the incident.
•
•
•
•
Outputs
Service Request (To: A61 A612)
Incident_ Classified (To: A654 A657)
An incident that has been assigned a classification. The classification helps narrow the
realm of possibilities for resolving the incident. For instance, the classification can be based
on platform, type of problem, component, or other information.
Incident_ Resolution Plan (To: A655 A657)
An incident for which a resolution plan has been created or obtained. Subsequently (and
beyond this activity), the resolution plan has to be applied and the outcome verified with the
user.
[A654] Investigate and Diagnose Incident

Description
This activity assesses Incidents and all data associated with them in order to identify appropriate
responses and actions, and to formulate Incident Resolution Plans.
Actions can include identifying workarounds, reclassifying the incident based on further analysis,
and updating Incident records.
Controls
Inputs
Incident_ Classified (From: A653)

•
•
•
•

output.
Covers the full scope of information about one or many changes, from individual detail
within a particular change through ad hoc or pre-determined reporting of a set of changes.
historical basis.
logged.”55
Outputs
Incident_ Resolution Plan (To: A655 A657)
user.
Incident Needing Reclassification (To: A653)
team.

•
•
•
•
[A655] Resolve Incident and Recover Service

Description
This activity takes actions necessary to resolve the incident and restore service using an existing
solution work around or, alternatively, raising a change request (RFC) to effect a new solution.
It also prompts any action necessary to recover the service to committed levels of delivery.
Controls
Inputs
Incident_ Resolution Plan (From: A653 A654)
user.
output.
Outputs
•
•
•
•
Incident_ Resolved (To: A62 A656 A657)

Incident_ Resolution Unsuccessful (To: A653)
An incident for which a workaround or fix was not provided or was unsuccessful. Normally,
an incident should eventually yield a workaround or a fix for that incident. However, in some
situations, no workaround or fix works to resolve the incident.
[A656] Close Incident

Description
This activity examines the case history of an Incident which has reached resolved status. It
ensures that all required incident documentation has been completed, including details of cause,
resolution, outcome and effort expended. It reviews the original classification against whatever root
cause information is available to determine the classification accuracy. In line with policy, it obtains
stakeholder agreement with resolution activity and status.
Controls
Inputs
Outputs
Incident_ Communication to User
Communications with a user about the status or progress of an incident. Could be to
provide status information or to solicit additional data or request some user action as part
of diagnosis.
•
•
•
•

Incident_ Closed (To: A657)
The finalization of all data related to an incident, including structured data which supports
analysis of incident causes, patterns, costs and resolution effectiveness.
[A657] Own, Monitor, Track and Communicate Incidents

Description
This activity ensures that the Incident is managed throughout its entire life cycle. It examines the
data and status changes (noted in other activities within the Incident Management process) as
recorded in Incident Records, defined in ITIL as: “A Record containing the details of an Incident.
Each Incident record documents the Life cycle of a single Incident.”56
Aspects of the activity include:
Monitoring status and incident impact on service level agreements
Incident reclassification and escalation if necessary
Maintaining incident information
Communicating status and progress to stakeholders and support groups
Controls
Inputs
Incident_ Closed (From: A656)
The finalization of all data related to an incident, including structured data which supports
analysis of incident causes, patterns, costs and resolution effectiveness.
Incident_ Resolution Plan (From: A653 A654)
user.
Incident_ Classified (From: A653)
Incident_ Logged (From: A652)

•
•
•
•
Request for Incident Status and Information

Notification of the need for information about incidents.
Outputs
Incident_ Communication to User
Communications with a user about the status or progress of an incident. Could be to
provide status information or to solicit additional data or request some user action as part
of diagnosis.
A662 A7 A72 A726 A73 A736 A74 A744 A75 A754)
Incident_ Needing Reclassification (To: A653)
team.
[A658] Evaluate Incident Management Performance

Description
The purpose of this activity is to evaluate the performance of the Incident Management process
activities against defined performance criteria and measures, and to provide input to the IT
Management System framework.
Controls
Inputs
Incident Management Activity Data (From: A652 A653 A654 A655 A656 A657)
Outputs
Incident Management Evaluation (To: A651)
An analysis of how well the Incident Management process was performed. This can also
include suggested areas for modifications to the Incident Management Framework.
•
•
•
•

Purpose
The purpose of the Problem Management process is to resolve problems affecting the IT service,
both reactively and proactively. Problem Management finds trends in incidents, groups those
incidents into problems, identifies the root causes of problems, and initiates change requests
(RFCs) against those problems.
Definition of problem: “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.”57
Outcomes
The number and adverse impact of incidents and problems is minimized
Potential incidents are prevented
Recurrence of incidents is prevented
The management of incidents is more effective and efficient
The productivity of support staff is improved
For example, by improving Service Desk first time fix rate
An effective problem management process maximizes system availability, improves service levels,
reduces costs, and improves customer convenience and satisfaction.
Scope
The process is primarily concerned with establishing the root cause of an incident and its
subsequent resolution and prevention. The reactive function is to solve problems relating to one or
more incidents. The proactive function is to identify and solve problems before incidents occur.
Effective problem management requires the identification and classification of problems, root
cause analysis, and resolution of problems. The problem management process also includes the
formulation of recommendations for improvement, maintenance of problem records, and review of
the status of corrective actions.
Includes
Root cause analysis and identification
Solution (and workaround) definition and selection
Submission of change requests (RFCs)
Appropriate prioritization of resources required for resolution based on business need
Contribution to the collective problem resolution knowledge base
Excludes
Identification, creation and resolution of incidents (Incident Management)

•
•
•
•
Actual implementation of the resolution of a problem. Problem Management initiates

their resolution through Change Management and participates in the Post
Implementation Review (PIR)
Knowledge management methodology (Knowledge Management)
Controls
contracts (UCs).

•
•
•
•
Inputs
implemented.”61
historical basis.
logged.”62

•
•
•
•
Outputs
A662 A663 A664 A665 A666 A7 A73 A736 A74 A744 A76 A764)
Activities
IT Plan IT Management IT Financial Architecture Baselines SLAs OLAs UCs
C4 Ecosystem Reports and Roadmaps C3
C1 C5 C2
I7
Service Resilience
Plans
Establish
Problem Problem
I8 Management
Solution Design
Framework
A661
I3 Detect
Incident and Log
Information Problem
Problem
Supplier Product Configuration
A662
and Service Information
Information/D1 Categorize Request/S1
Service Resilience and Problem_
Reports/D2 Prioritize Prioritized
I6 Problem
Configuration A663
Information
I2 Investigate
Operational and Known
Monitoring Data Error
Diagnose
I4 Problem
Event A664
I5 Problem_ Resolve
Change Diagnosed O1
Information Problem Change
Major Request
Operational Problem
Documentation/D4 A665 Review
Service Outage Results Service
Analysis/D1 Problem_ Problem_
Problem_
Close and Improvement
Reprioritization Further Investigation Input
I1 Request Resolution Review
Request
Change Schedule Problem
Problem_
A666 Closed
Change
Implementation Monitor, O2
Communication/D2 Track and Problem
Report Information
Request for Problems
Problem Status A667
and Information Evaluate
Problem
Management
Performance
Activity Data
Problem
Management
Evaluation
NODE: A66 TITLE:
Problem Management CURRENT PAGE:
Figure 7. A66 Problem Management
•
•
•
•
[A661] Establish Problem Management Framework

Description
This activity identifies resources necessary for the total process to function as desired and
designed. It is within this activity that:
Guidelines for problem classification and prioritization are defined
Sources and receivers of information necessary for Problem Management to be effective
are identified
Successful process measurement criteria are documented
Service levels with regard to Problem Management have to be taken into account during this
activity. Finally, the structure and process of Problem Management have to be communicated to
those concerned.
Controls
contracts (UCs).

•
•
•
•
Inputs
Problem Management Evaluation (From: A668)
Outputs
Problem Management Framework (To: A662 A663 A664 A665 A666 A667 A668)
The framework that contains all relevant information about the structure of the Problem
Management process; that is, the strategic goals and policies for Problem Management,
the definition of supporting technology, measurements, among others.

•
•
•
•
[A662] Detect and Log Problem

Description
Whether it is for proactive problem handling or reactive problem activities, this activity ensures that
monitoring, analysis, and notification mechanisms are implemented to detect problems. Once
detected, problems are fully recorded and linked to the associated incidents. Incidents provide the
primary source for problem detection; the activity includes further ways to identify problems:
Notification from suppliers
Feedback from the service desk or technical support groups
Proactive approaches like trend analysis.
Problem detection and logging can include both automated and manual activities. The result of this
activity is the formal creation of a problem, with the relevant details captured in a problem record.
Controls
Problem Management Framework (From: A661)
Inputs
Supplier Product and Service Information (From: A826)
Information about the items (products or services) that can be supplied by the suppliers in
the portfolio, like the catalog of orderable supply items, including:
• Prices
• Service levels
• Supply options (suppliers can provide supply items)
Covers both external and internal suppliers. An example of an internal supplier: Facility
supplier indicates lead-time and costs for equipping a new workspace.
•
•
•
•
historical basis.
logged.”66
Outputs
Problem Management Activity Data (To: A668)
overall Problem Management process.
Problem (To: A663 A667)
As defined in ITIL: “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.”67

•
•
•
•
[A663] Categorize and Prioritize Problem

Description
This activity ensures that problems are classified to enable appropriate analysis and resolution. It
further takes into account the severity of problems that can be encountered, and the potential
impact to business goals. The result of this activity is a prioritized problem.
Controls
contracts (UCs).
Inputs
Problem (From: A662)

•
•
•
•

Problem_ Reprioritization Request (From: A667)
In the course of monitoring and tracking problems there could be a need to lower or raise
the priority of an individual problem due to a change in the business impact. The problem
is referred for reprioritization.
Outputs
Problem_ Prioritized (To: A664 A667)
A problem for which the category and priority are understood and recorded in the problem
record. ITIL has the following definitions for these terms:
• Category is defined as “A named group of things that have something in common.”72
• Priority is defined as “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.”73
[A664] Investigate and Diagnose Problem

Description
Investigate and Diagnose Problem includes activities for root cause analysis, creating
workarounds where possible, and recording a known error. This activity must ensure that
workarounds are in place and effective, and that sufficient analysis and diagnosis has ensued to
complete the root cause analysis. The result of this activity will be:
The creation of a known error record that describes the diagnosis and available
workarounds
An updated problem record that indicates the diagnosed problem
Controls

•
•
•
•
Inputs
Problem_ Prioritized (From: A663)
Information about the items (products, services) that can be supplied by the suppliers in the
portfolio, like the catalog of orderable supply items including
• Prices
• Service levels
• Supply options, (suppliers can provide these supply items)
output.
Service Outage Analysis (From: A736)
The results from identifying root causes of service outage, assessing the effectiveness of
service availability, and identifying key recommendations for improving availability. There is
a corresponding technique described in the ITIL Service Delivery, Availability Management
book.
Problem_ Further Investigation Request (From: A665)
In the process of resolving a known error, if additional problems are identified, a request is
made for additional root cause analysis.
Outputs
make such requests.
Known Error (To: A665 A666 A667)
As defined in ITIL: “A Problem that has a documented Root Cause and a Workaround.
Known Errors are created and managed throughout their Life cycle by Problem
Management. Known Errors may also be identified by Development or Suppliers.”76

•
•
•
•

Problem_ Diagnosed (To: A665)
A problem for which the root cause is understood.
[A665] Resolve Problem

Description
This activity ensures the resolution of known errors (that is, problems for which the root cause is
fully understood). This includes the search for a solution, the implementation planning of resolution
actions to eliminate known errors (initiating an RFC or a Project Proposal), and tracking the
successful implementation of the change to the infrastructure. The submission of an RFC or
Project Proposal is a result of this activity. The error resolution has to be documented in the
problem and known error records.
Controls
contracts (UCs).

•
•
•
•
Inputs
Known Error (From: A664 A665)
Problem_ Diagnosed (From: A664)
implemented.”81
Outputs
Known Error (To: A665 A666 A667)

•
•
•
•
Problem_ Resolution (To: A666 A667)

Actions taken to repair permanently a known error or implement a workaround.
Problem_ Further Investigation Request (To: A664)
In the process of resolving a known error, if additional problems are identified, a request is
made for additional root cause analysis.
[A666] Close and Review Problem

Description
This activity includes closing problems, ensuring that known error records have been updated, and
performing reviews for major problems. Each problem record is checked for completeness so that
other processes have the appropriate information available.
For example, incident management could need to close or update incidents as a result of
the problem resolution and closure.
For each major problem, a review will be conducted and the results incorporated in
communication, training, and reviewing the service.
Controls
Inputs
Problem_ Resolution (From: A665)
Outputs
Service Improvement Input
Any information from problem resolution (proactively or reactively) that can help to improve
the overall service delivery. For example, there could be a finding that a specific service
part or component frequently generates problems and a determination that a modification

•
•
•
•
to the procedures used to operate the service would remove the incident-inducing
circumstances.
Major Problem Review Results (To: A668)
The analysis and outcome of reviewing those problems classified as major. This
classification can reflect a variety of reasons, such as:
• Service impact
• Problem duration
• Cost and efficiency to achieve resolution and closure
Review outputs will reflect these topics.
Problem_ Closed (To: A667)
The finalization of all data related to a problem. This includes structured data, which
supports analysis of problem causes, patterns, costs and resolution effectiveness.
[A667] Monitor, Track and Report Problems

Description
This activity is responsible for examining all information about all problems, using the records
updated by the other activities within the Problem Management process. ITIL defines a Problem
Record as “A Record containing the details of a Problem. Each Problem Record documents the
Life cycle of a single Problem.”84
The ongoing monitoring and tracking of the handling of problems and known errors must be
accomplished to report on service level attainment with regard to problem management. The
reports and relevant statistics are created mainly based on problem record data. It could also take
into account feedback from customers.
This monitoring and reporting activity has to be done regularly, but can also be initiated by a special
request. It might result in problems being reprioritized and might prompt further root cause analysis
and the development of new resolution plans. An additional result of this activity is problem
information that is used in service reviews.
Controls

•
•
•
•

contracts (UCs).
Inputs
Problem_ Closed (From: A666)
The finalization of all data related to a problem. This includes structured data, which
supports analysis of problem causes, patterns, costs and resolution effectiveness.
Problem_ Resolution (From: A665)
Problem_ Prioritized (From: A663)
Problem (From: A662)
Request for Problem Status and Information
Request for information with regard to overall problem status and service level attainment
with regard to problem management.

•
•
•
•
Outputs
A662 A663 A664 A665 A666 A7 A73 A736 A74 A744 A76 A764)
Problem_ Reprioritization Request (To: A663)
In the course of monitoring and tracking problems, there could be a need to lower or raise
the priority of an individual problem due to a change in the business impact. The problem is
referred to reprioritization.
•
•
•
•
[A668] Evaluate Problem Management Performance

Description
This activity is responsible for the ongoing assessment and management of the Problem
Management process, according to predetermined criteria. It is responsible for managing and
reporting process measurements at regularly scheduled intervals. Also, the generation of any
improvement opportunity areas that might be necessary to facilitate meeting business objectives.
Basis for the improvements are insights and lessons learned from the observations and analysis
Basically, the improvements should lead to more efficiency in the process (better Problem
Management).
Controls
Inputs
Major Problem Review Results (From: A666)
The analysis and outcome of reviewing those problems classified as major. This
classification can reflect a variety of reasons, such as:
• Service impact
• Problem duration
• Cost and efficiency to achieve resolution and closure
Problem Management Activity Data (From: A662 A663 A664 A665 A666 A667)
Outputs
Problem Management Evaluation (To: A661)
•
•
•
•

Purpose
The purpose of the Identity and Access Management process is to establish and maintain a
registry of IT user identities and their associated access rights for each service. The registry
provides a key reference for the authorization or rejection by the Security Management process of
service usage attempts.
The process provides the ability to control and track who has access to data and services. It
contributes to achieving the appropriate confidentiality, availability, and integrity of the
organization’s data.
ITIL definition of identity: “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.”92 This definition is narrower than those
established in ISO standards relating to security. For the purposes of this process, the user might
not be directly linked to one or more persons; it can take the form of an IT product or system for
which access rights must be established and tracked, and for which an identity is therefore
established.93
Definition of rights: “Entitlements, or permissions, granted to a user or role. For example, the right
to modify particular data, or to authorize a change.”94
Outcomes
As a result of the successful implementation of the Identity and Access Management process:
An accurate and complete identity registry and associated rights is maintained
There is a definitive source so that decisions can be made allowing users have access to
information and the services they need while unauthorized access attempts are denied
Authorized access to data and services is aligned with security policies
Records of access attempts can be audited
The data necessary to demonstrate compliance in relation to service and information
access is available
Scope
This process operates within the set of controls described by the IT Security Policy, which itself
takes direction from the Business Security Policy. The users for whom (or which) an identity is
registered include not only those outside the IT organizational entity but also all resources involved
in running the IT capability itself. Levels of control of identities and access rights will vary
depending upon the scope of access required and the level of potential harm (fraud) from malicious
access.
Access policies can be dynamic, reflecting the need to vary access rights depending on the time
of day or the role being performed. The process must recognize that the authority to give access
rights, or even to delegate the authority to give access rights, is a normal activity for many users.
Includes
An identity schema aligned with business and security policies

93. ISO/IEC 15408-1, Information technology – Security techniques – Evaluation criteria for IT security. “Part 1: Intro-
duction and general model.” Widely known as the Common Criteria.
•
•
A6 - 100• IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
Establishment and maintenance of identities

Establishment and maintenance of access rights
Translation of business rules for roles and group authorities so as to enact then within
the identity schema
Access to the registry for those processes providing affiliated security services, like
physical access (Facilities Management)
Raising warnings or revoking access rights when access attempt thresholds are
breached
Excludes
Definition, implementation, and operation of authentication mechanisms (Security
Management)
Enforcement of access rights (Security Management)
Definition of the rules for business role and group authorities – defined by the
business
Physical security and access (Facilities Management)
Security policies – defined by the business and Security Management
Controls
compliance
contracts (UCs).
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) •A6 - 101
•
•
Inputs
Identity and Access Work Request (From: A535 A62 A624)
target.

•
•
•
•

Outputs
The records which provide the current (and perhaps historical) values for identities and for
Identity and Access Monitoring Data (To: A64 A642 A675 A727)
an interruption to one ore more services. Incidents can be created using either manual or
Activities
A673 Create and Maintain Identity
•
•
•
•
IT Plan IT Management Business Identity Rules Compliance Plans SLAs OLAs UCs Security Policy
C4 Ecosystem and Controls C3 C5
C2 C1
I7
Solution Design
Establish
Identity and Identity and
I6 Access Access Management
Security Management Framework
Plan/D1 Framework
I2 A671
Service Request_ Evaluate and
Authorized Verify Identity
and Access
Identity and Request Identity
Access Request A672 Request
I1
Identity and Access
Work Request
Create and O1
Maintain Identity and
Access Rights
Identity Register
A673
Identity and
I5
Access Request Access Response
Security Provide and
Directives/D2
Maintain
Access
I4
Configuration Rights
A674 O3
Information
Incident
Monitor and
Report Identity and
Access Reports
I3 Identity and
Security Access
Monitoring Data/D1 A675
O2
Identity and Access
Request for Identity and Access Monitoring Data
Identity and Access Directives Evaluate
Information
Identity and
Access
Identity and Management
Access Management Performance
Activity Data A676
Identity and
Access Management
Evaluation
NODE: A67 TITLE:

Identity and Access Management CURRENT PAGE:
Figure 8. A67 Identity and Access Management
[A671] Establish Identity and Access Management Framework

Description
This activity defines a framework of policies, procedures, organizational roles and responsibilities,
and other information under which the Identity and Access Management process will operate to
meet its mission and goals. It is within this activity that:
Sources and receivers of information necessary for Identity and Access Management to be
effective are identified
Successful process measurement criteria are documented
Service levels with regard to Identity and Access Management have to be taken into account
during this activity. Finally, the structure and process of Identity and Access Management have to
be communicated to those concerned.
•
•
•
•
Controls
Business Identity Rules
Set of rules that will be used to determine if identity requests and access requests will be
approved. Part of Business Security Policies and Plans.
compliance
contracts (UCs).

100.ITIL V3 Glossary
•
•
•
•

Inputs
Identity and Access Management Evaluation (From: A676)
An assessment of the overall performance of the process and of its activities against the
targets set in the Identity and Access Management process framework. It includes
identification of potential process improvement items. This may also include proposed
modifications to the Identity and Access Management Framework.
Outputs
Identity and Access Management Framework (To: A672 A673 A674 A675 A676)
The policies, guidelines, plans, procedures, organizational roles and responsibilities and
other information under which the Identity and Access Management process will operate to
meet its mission and goals.
[A672] Evaluate and Verify Identity and Access Request

Description
This activity evaluates and verifies the identity of the person listed in each request and verifies that
a reasonable substantiation is provided for the access to a system or application. This activity also
verifies that the request has been approved by a legitimate approver.
Controls
Identity and Access Management Framework (From: A671)
•
•
•
•
Inputs
Identity and Access Request
Service Request to create or modify an identity record for a user and to provide access to
systems, data and applications.
Outputs
Identity Request (To: A673)
A form of Service Request to enroll, provision or change a given user's identity
characteristics and which evaluated, verified and accepted for processing.
Access Request (To: A674)
An access request that has been evaluated and verified. Each access request is
associated with a verified user identity.
Identity and Access Management Activity Data (To: A676)
resources used, success and error rates, interfaces invoked, rework, customer feedback,
priorities.
[A673] Create and Maintain Identity

Description
This activity will create new identity records in the identity database and will perform edits and
deletes to existing identity records.
Controls
Inputs
Identity Request (From: A672)
A form of Service Request to enroll, provision or change a given user's identity
characteristics and which evaluated, verified and accepted for processing.
Identity and Access Directives (From: A675)
Individual or collective commands, instructions or other requests to modify or adjust
identities or the access rights register. Such directives are usually the result of monitoring
patterns of identity and access behavior as well as from security monitoring data.
•
•
•
•
Outputs
Identity and Access Response (To: A535 A624)
The result of processing an identity and access request. The result will reflect a range of
• For an identity request – actions taken to create, maintain, or delete the identity
information describing the status of access rights.
Access Request (To: A674)
priorities.
[A674] Provide and Maintain Access Rights

Description
This activity provides the access rights based on predefined policies and regulations. It updates
the identity records to reflect the updated access rights and confirms that the access rights have
been implemented.
Access rights can be removed as well as granted. Accordingly, this activity will restrict or revoke
rights in order to execute policies and decisions made by appropriate authorities.
Controls
•
•
•
•
Inputs
Identity and Access Rights Register (From: A6 A67 A673 A674)
Access Request (From: A672 A673)
Identity and Access Directives (From: A675)
Outputs
Identity and Access Response (To: A535 A624)
The result of processing an identity and access request. The result will reflect a rnage of
• For an identiy request – actions taken to create, maintain, or delete the identity
priorities.
•
•
•
•
[A675] Monitor and Report Identity and Access

Description
This activity includes logging, tracking and auditing access to systems and applications. This
activity also includes the recurring validation of identity records for currency. Finally, this activity
will produce regular and ad hoc reports.
Controls
Inputs
Request for Identity and Access Information
A request from another process or from a customer or user for information on some aspect
of one or more identities and their registered access rights, including historical data.
Outputs
Identity and Access Reports
These reports contain a summary of identity and access records, and the amount and type
of identity and access transaction completed (additions, changes, deletions) in a given
timeframe.
•
•
•
•

priorities.
Identity and Access Directives (To: A673 A674)
[A676] Evaluate Identity and Access Management Performance

Description
This activity assesses the performance of the Identity and Access Management activities against
defined performance criteria and measures. The evaluation of process performance identifies
areas that need improvement. This might include the foundation and interfaces of the process,
activity definitions, key performance metrics, the state of supporting automation, as well as the
roles and responsibilities and skills required. Insights and lessons learned from direct observation
and data collected on process performance are the basis for improvement recommendations.
Controls
Inputs
Identity and Access Management Activity Data (From: A672 A673 A674 A675)
priorities.
Outputs
Identity and Access Management Evaluation (To: A671)
An assessment of the overall performance of the process and of its activities against the
targets set in the Identity and Access Management process framework. It includes
identification of potential process improvement items. This may also include proposed
modifications to the Identity and Access Management Framework.
•
•
•
•
PRM-IT A6 Node Tree
PRM-IT A6 Node Tree
A6 – OPERATIONS
A63 Data Management
A643 Filter Event
A645 Resolve Event
A646 Close Event
A656 Close Incident
•
•
•
•
PRM-IT A6 Node Tree
A6 – OPERATIONS
A673 Creae and Maintain Identity
Figure 9. A6 Operations Node Tree
•
•
•
•
PRM-IT A6 Node Tree
•
•
•
•
[A7] Resilience
Description
Purpose
domain.
Rationale
and IT services.
Value
business processes
Controls
Business Strategy
•
•
•
•
Inputs
A452)
Outputs
Business Output (To: Outside-the-Model)
Compliance Plans and Controls (To: A1 A11 A111 A113 A114 A3 A36 A361 A37 A371 A4
A632 A67 A671 A715 A716 A72 A725 A76 A763 A8 A81 A811)
Security Policy (To: A2 A21 A213 A24 A243 A3 A31 A314 A33 A331 A332 A333 A34 A341
A725 A726 A727 A73 A732 A75 A752 A76 A763 A8 A82 A822 A85 A852)
Service Resilience Plans (To: A2 A22 A221 A24 A243 A246 A25 A255 A26 A265 A266 A3
A632 A64 A641 A65 A651 A66 A661)
Processes
•
•
•
•
IT Strategy IT Management IT Plan SLAs OLAs UCs Environment Identity and Service IT Budget Business
I3 C3 Ecosystem C5 Regulations Information Access Rights Catalog Industry Risk, Threats C9 Strategy
C2 Register O6
Service Metric Data C6 C7 C4 and Vulnerabilities C8
and Standards/D1 C1 Change
and Reports
Request
I17 O4
Business Service Resilience
Input Plans
I14 Business
Business and Compliance Continuity
IT Models Certification Policies
Compliance
Management O1
Business Output
I11 O2
Asset Information Business Security Compliance Plans
A71
I12 Policies and Plans and Controls
Security Plan O7
Solution Design Incident
Security
I1 Management O3
Architecture Baselines Security Policy
and Roadmaps
A72
Security Availability
Security Reports Security
Work Request Plan Monitoring Data
Availability
I7 Management
Stakeholder
Requirements Service Resilience
A73 Reports
I5
Incident Capacity
Availability Reports Service
Information
Reports Resilience
I15
Service Request_ Capacity Directives
Authorized
I4 Management
Operational
Monitoring Data
A74
Facilities
I13 Capacity Plan Plans and
Solution
Facilities Specifications
Plans and
I16
I2
Change Schedule CI Data
A75 Update Package
I6
Problem
Information
I9 IT Service
Change Continuity
Information
Management
IT Service
I10
A76 Continuity
Configuration Plan
Information
I8
Solution_
Deployed
NODE: A7 TITLE:
Resilience CURRENT PAGE:
Figure 1. A7 Resilience Diagram
•
•
•
•
Purpose
The purpose of the Compliance Management process is to ensure adherence to laws and
regulations, internal policies, procedures, and stakeholder commitments.
Outcomes
Regulatory, audit, and other internal compliance is ensured and demonstrated
Legal liabilities and related productivity losses consequential upon any compliance breach
are avoided
The reputation and value of the brand of the businesses that IT serves is protected
Scope
Integrity (sound operating) and compliance as an outcome across all of the IT endeavor's
undertakings.
Includes
Consideration of internal and external regulations, standards and legal obligations
impacting the business where they could require IT support. For example:
– Privacy regulations
– Laws such as Sarbanes Oxley
– Industry standards and guidelines such as ISO 27001 (ISO17799), COSO and
CobiT
Specification of compliance controls needed within IT services and solutions and also
within other IT processes
Internal and external audit readiness preparations
Compliance audits
Excludes
Setting internal policies (IT Governance and Management System Framework)
Modification to IT services and solutions to establish compliance controls (through
Realization and Deployment categories)
Modification to other IT processes (through IT Governance and Management System
categories)
Operation of the defined compliance controls within the transactions of the IT
endeavor. This responsibility becomes part of the activity of each relevant IT process
Controls
included.
•
•
•
•

Business Strategy
policies.
Management)
Inputs
• Guidance
• Instructions
individual asset.
Outputs
Compliance Certification
Formal declaration by the accountable executive of adherence to regulatory requirements.
A632 A67 A671 A715 A716 A72 A725 A76 A763 A8 A81 A811)
•
•
•
•

compliance
Activities
IT Management Business IT Strategy Regulations Security Policy
Ecosystem Strategy C1 and Standards/D1
C4 C5
C2 C3
Business
Compliance
Plan
Establish
I2 Compliance Compliance Management
Business Management Framework
Input
Framework Compliance
A711 Requirements
Identify
Solution Compliance Compliance
Requirements Requirements Requirements_
Baseline/D1 Assessed
A712
I3 Assess
Business and
IT Models
Compliance
I4
Requirements
Asset Information A713
Define
Compliance O2
Compliance Plans
Controls Plan and Controls
Risk Assessment
and Mitigation Plans/D1 A714 Compliance
Operational
Capabilities
I1 Implement
Service Metric Data Compliance
and Reports Controls Configuration
Audit Request/S2
Individual A715
Process Compliance
Evaluations/D2 Audit Invocation
Audit and
Report
I5 O1
Security Reports
Compliance Compliance
A716 Certification
Compliance
Evaluate Audit Reports
Program and
Project Reports/D1 Compliance Compliance
Configuration Evaluation
Audit Report/D2
Compliance Management Performance
Activity Data A717
NODE: A71 TITLE:

Compliance Management CURRENT PAGE:
Figure 2. A71 Compliance Management
•
•
•
•
[A711] Establish Compliance Management Framework

Description
Based on the business and IT strategy and the policies and practices embodied within the IT
management system, guidelines and a framework for Compliance Management have to be
developed. The tasks in this activity include:
Determining the requirements for the way compliance management process will be
consistent with the overall business compliance approach
Establishing the framework for Compliance Management by defining and implementing
practices, procedures, and systems that support process activities
Defining the strategy for Compliance Management tools and capabilities, and how they
should be sourced. For instance, should they be developed in-house or rely more on
vendor capabilities
Defining evaluation criteria for Compliance Management solutions and services
Finally, the structure and process of Compliance Management, including escalation
responsibilities, have to be communicated to the process users.
Compliance Management. For example, the consideration of the Compliance Management
Controls
Business Strategy
policies.
included.
Management)
Inputs
Business Compliance Plan
The compliance requirements determined by the business, derived by examination across
the span of its activities and details of the specifications and implementations of
corresponding compliance plans.
•
•
•
•
Compliance Management Evaluation (From: A717)

Outputs
Compliance Management Framework (To: A712 A713 A714 A715 A716 A717)
under which the Compliance Management process will operate to meet its mission and
goals.
[A712] Identify Compliance Requirements

Description
This activity seeks out and collates the requirements for compliance. The requirements can be
derived from several sources, including:
The business, through the Business Compliance Plan
External regulations and standards (with particular applicability to the design and operation
of IT solutions)
Internal IT policies
Controls
Compliance Management Framework (From: A711)
goals.
Inputs
Management)
•
•
•
•

undertaking (such as projects, external development) and the risk limitation measures
Outputs
Compliance Requirements (To: A713)
The necessary conditions and actions needed to adhere to external regulations or
standard practices and also to requirements established by the business through activities
such as audit and oversight.
Compliance Management Activity Data (To: A717)
[A713] Assess Compliance Requirements

Description
Assessment of identified compliance requirements to establish exactly which of the potential
compliance aspects must be put into effect, and to what degree. In a fashion similar to Risk
Assessment, it includes evaluating the costs of compliance against the consequences of
noncompliance. The output will be the base from which all compliance controls are built.
Controls
goals.
Inputs
included.
•
•
•
•
Compliance Requirements (From: A712)

The necessary conditions and actions needed to adhere to external regulations or
standard practices and also to requirements established by the business through activities
such as audit and oversight.
individual asset.
Compliance Audit Reports (From: A716)
audits.
Outputs
Compliance Requirements_ Assessed (To: A714 A716)
Sets of categorized, quantified, and prioritized compliance items that the IT endeavor must
address. Also includes any compliance requirements for which noncompliance has been
assessed, with decision reasons and analysis of likely consequences.
[A714] Define Compliance Controls Plan

Description
The compliance controls that must be put into effect are specified and designed. Compliance
controls identified here must be consistent with the overall business compliance plan and also
provide the basis by which the IT executives will be able to attest (certify) that the IT endeavor has
met compliance requirements specific to IT undertakings.
Controls
goals.
Inputs
Compliance Requirements_ Assessed (From: A713)
•
•
•
•

Outputs
A632 A67 A671 A715 A716 A72 A725 A76 A763 A8 A81 A811)
compliance
[A715] Implement Compliance Controls

Description
The overseeing of the development and deployment of defined compliance controls. The outcome
is that the compliance controls are in operation across all relevant IT activities.
Controls
goals.
Inputs
compliance
•
•
•
•
Outputs
Compliance Operational Capabilities (To: A716)
The set of capabilities which implement the various controls required to adhere to specific
regulatory or more informally generated requirements.
[A716] Audit and Report Compliance

Description
Compliance control activities and outcomes are monitored and analyzed for progress and
certification. Exposures and findings that are discovered during the audit will be documented and
communicated to ensure compliance. Where required, conformance will be formally certified: for
example, SOX Attestation. Reports are produced on any aspect of compliance workings.
Controls
Compliance Operational Capabilities (From: A715)
The set of capabilities which implement the various controls required to adhere to specific
regulatory or more informally generated requirements.
compliance
Compliance Requirements_ Assessed (From: A713)
goals.
Inputs
process.
•
•
•
•

person(s) making such changes.
Outputs
Configuration Audit Request (To: A545)
Compliance Audit Invocation
A directive to all processes that are required to operate under the risk and compliance
controls for evidence which will be examined to identify whether and how well those
controls are being operated.
Compliance Certification
Formal declaration by the accountable executive of adherence to regulatory requirements.
Compliance Audit Reports (To: A143 A713)
audits.
•
•
•
•
[A717] Evaluate Compliance Management Performance

Description
requiring improvement. This covers the foundation and interfaces of the process, all activities, their
accomplishments, their degree of automation, as well as the roles and responsibilities including the
respective skills. The bases for improvements are insights and the lessons learned from the
observations and analysis of activity accomplishments and results.
Controls
goals.
Inputs
Compliance Management Activity Data (From: A712 A713 A714 A715 A716)
Outputs
Compliance Management Evaluation (To: A711)
•
•
•
•
Purpose
The purpose of the Security Management process is to establish and operate security controls and
protections over all IT assets and services in order to conform to overall business security as well
as IT-specific requirements. It includes activities to mitigate the risk posed by malicious outsiders
and insiders, and to decrease vulnerabilities in the IT services, systems and processes that would
make it easier for such malicious parties to succeed.
Outcomes
As a result of the successful implementation of the Security Management process:
The confidentiality, integrity, and accessibility of information meets agreed requirements:
• Information is available for approved purposes
• Access (whether internal or external) to protected items can be validated and tracked
• Information and systems are protected from unauthorized access and any attacks
IT services and infrastructure meet external security requirements from service level
agreements, contracts, and legislative dictates
IT security aligns with the business' overall security requirements
The reputation of the business as secure and trustworthy is protected
Scope
The process covers the life cycle of security concerns, including planning, operational measures,
evaluation, and audit. It will identify IT security threats, vulnerabilities, and risks in order to develop
an overall approach to counter and handle them that is aligned with business security
requirements. It will operate security protections and mechanisms which meet the desired level of
confidentiality, availability and integrity for information and IT services.
Includes
Information security policy
Specification of information security controls including asset use, access,
documentation, and information controls and overseeing their establishment
Operation of controls and measures such as:
– Credential operations
– Perimeter defense
– Intrusion detection
– Secure coding standards
– Key and encryption management
– Separation of duties
– Application isolation
Identification of IT security incidents
Management of supplier and partner access to services and systems
Compliance enforcement measures (related to security)
•
•
•
•
Excludes
Establishment and maintenance of identities and access rights (Identity and Access
Management)
Health and safety (Business responsibility, with contribution from Facilities
Management)
Business security management, including trust management as it relates to business
processes (Business responsibility)
Identification of privacy requirements (within the scope of Compliance Management)
Controls
included.
contracts (UCs).
1. ITIL V3 Glossary
2. ITIL V3 Glossary
•
•
•
•
Management)
Business Security Policies and Plans
This is the overall set of security directives from the business, establishing the context for
protection of business assets and information. It is often known as an Enterprise Security
Program.
Inputs
compliance
individual asset.
Security Work Request (From: A535 A623 A624)
3. ITIL V3 Glossary
•
•
•
•

target.
Facilities Plans and Specifications (From: A75 A752)
Specifications, designs and plans for the IT facilities to support the provision of IT service.
Outputs
of the environment or with any service or activity. (To: A537 A6 A65 A652)Incident
A725 A726 A727 A73 A732 A75 A752 A76 A763 A8 A82 A822 A85 A852)
Service Resilience Directives (To: A62 A622 A623 A63 A632)
of service.
Security Monitoring Data (To: A64 A642 A67 A675 A727 A73 A735)
Security Plan (To: A33 A334 A335 A336 A34 A344 A345 A346 A42 A422 A423 A424 A44
A442 A612 A613 A67 A671 A75 A752 A76 A764 A843)
Security Reports (To: A346 A71 A716 A723 A725)
•
•
•
•
Activities
Business Security Regulations IT Management IT Strategy IT Plan SLAs OLAs UCs Identity and
Policies and Plans and Standards/D1 Ecosystem C2 C3 Access Rights
C7 C5 C1 C4
Register
C6
Establish
I8 Security Security
Change Management
Information
Management
Framework
Framework
A721
Produce and
Maintain O3
Security Policy
Security Security
Identified
Risks/D1 PolicyA722 Security Risk Assessment
Risk Analysis
Analyze Security Information Asset
I4
Threats, Security Classification
and Roadmaps Vulnerabilities O6
and Risks Security Plan
A723
I3 O4
Solution Design Classify Service
Information Resilience
Operational Directives
Documentation/D5 Asset O1
Security Procedures
Security and Infrastructure Change
A724 Request
Security Directives
Security
I2 Plan and Response
Asset Information Implement
I1
Security
Compliance Plans Practices
A725 Security O5
and Controls Violation Security
I10 Operate Monitoring Data
Facilities Security
Plans and Protection O2
Specifications Security
Request Mechanisms Incident
I9 A726
Service Request_ Monitor,
Authorized Assess, O7
I6
Security Audit and Security Reports
Work Request Report
I7 Security
A727
Incident
Information
Evaluate
Security Security
I5 Security Management Evaluation
Activity Data
Performance
Configuration A728
Information
Identity and Access
Monitoring Data/D1
NODE: A72 TITLE:

Security Management CURRENT PAGE:
Figure 3. A72 Security Management
•
•
•
•
[A721] Establish Security Management Framework

Description
The purpose is define and maintain a framework of policies and procedures that guides and
governs the behavior of the Security Management process and its activities. Incorporate
mandatory elements from the Management Ecosystem, and define a set of metrics to be used by
each process for measurement and reporting of performance. It also must review the process
evaluation based on analysis of current performance, and approve recommendations for
improvements. Finally, to refine the metrics to encourage process vitality and cost effectiveness,
an to incorporate updated metrics and process change recommendations into the framework and
Controls
Management)
Program.
included.
Inputs
Security Management Evaluation (From: A728)
Outputs
Security Management Framework (To: A331 A341 A722 A723 A724 A725 A726 A727
A728 A751 A761)
security.
•
•
•
•
[A722] Produce and Maintain Security Policy

Description
This activity creates the overall statement of the aims and objectives for the security that is to be
established and operated in relation to IT services and resources, and maintains its currency as
circumstances change for both the IT service provider and its customer set. It works within the
limits set for the security policy of the parent business, modifying or extending its coverage to
include aspects specific to information technology.
Controls
security.
Inputs
Management)
Program.
Identified Risks (From: A342)
Outputs
A725 A726 A727 A73 A732 A75 A752 A76 A763 A8 A82 A822 A85 A852)
Security Management Activity Data (To: A728)
•
•
•
•
[A723] Analyze Security Threats, Vulnerabilities and Risks

Description
Identify security threats, determine risks and vulnerabilities which effect the IT organization or that
IT can affect, and recommend mitigating changes based on this analysis.
Controls
security.
Management)
Program.
contracts (UCs).
4. ITIL V3 Glossary
5. ITIL V3 Glossary
•
•
•
•
agreed Service Level Targets in an SLA.”
Inputs
output.
Outputs
Security Risk Assessment (To: A42 A424 A425 A44 A444 A445 A45 A454 A455)
Security Risk Analysis (To: A724 A725)
The results and recommendations of an in-depth study of the threats, vulnerabilities and
risk factors to be mitigated by security practices and protection mechanisms.
•
•
•
•
[A724] Classify Information Asset Security
[A724] Classify Information Asset Security

Description
Develop a security classification scheme for information assets by examining the inventory. The
scheme identifies the required level of security for each categorization.
Controls
security.
Inputs
Security Risk Analysis (From: A723)
individual asset.
Outputs
Information Asset Security Classification (To: A725)
The level of protection to be established and operated against each category of information
assets. It includes:
• Identification of ownership requirements
• Handling and labeling procedures
•
•
•
•
[A725] Plan and Implement Security Practices

Description
This activity establishes the Security plan. It defines and creates an appropriate security
infrastructure and procedures, translates actions in the plan to security directives, and
communicates them. It also makes request changes in the environment to realize the Security
plan.
Controls
security.
Program.
Inputs
Information Asset Security Classification (From: A724)
The level of protection to be established and operated against each category of information
assets. It includes:
• Identification of ownership requirements
• Handling and labeling procedures
Security Risk Analysis (From: A723)
•
•
•
•

compliance
Outputs
Security Plan (To: A33 A334 A335 A336 A34 A344 A345 A346 A42 A422 A423 A424 A44
A442 A612 A613 A67 A671 A75 A752 A76 A764 A843)
Security Directives (To: A333 A334 A67 A673 A674)
Security Procedures and Infrastructure (To: A726 A727)
The collected design, components, policies and direction which together establish an
infrastructure to be put into place for security management.
[A726] Operate Security Protection Mechanisms

Description
This activity puts in place prescribed security controls and procedures throughout all aspects of IT,
both in terms of the IT organization and by activating the security protections within IT solutions
and services.
Applying the mechanisms involves the full range of education and training, installing new systems,
and testing to make sure that security controls and procedures work properly.
This activity actuates and monitors the full range of security measures and capabilities, responding
to service or resource access authorization requests in addition to noting security violations and
initiating incidents when necessary.
Real-time intrusion detection sensing and immediate responses are an important part of the
function of this activity.
•
•
•
•
Controls
Security Procedures and Infrastructure (From: A725)
security.
contracts (UCs).
6. ITIL V3 Glossary
7. ITIL V3 Glossary
8. ITIL V3 Glossary
•
•
•
•
Inputs
Security Request (From: A634)
System or external request to secure IT resources or validate authority for access.
• Secure IT resources: identifies one or more specific resources which need to be
included in the security protection scheme, or need to have their level and means of
protection adjusted
• Request to access: a communication soliciting access to a particular resource or class of
resources
Outputs
Security Response (To: A535 A623 A624 A634)
• For a protection request - the protections put in place
• For an access authorization request - success or failure of the request
Security Monitoring Data (To: A64 A642 A67 A675 A727 A73 A735)
Security Violation (To: A727)
An event (an activity or state) that is inconsistent with defined security practices and
requires further inspection and evaluation.
[A727] Monitor, Assess, Audit and Report Security

Description
This activity addresses reviewing security controls and mechanisms and determining whether they
appropriately and effectively implement security policies and procedures as described in the
Security Management Framework and the Security plan.
Controls
Security Procedures and Infrastructure (From: A725)
•
•
•
•

security.
contracts (UCs).
9. ITIL V3 Glossary
•
•
•
•
Inputs
Security Violation (From: A726)
An event (an activity or state) that is inconsistent with defined security practices and
requires further inspection and evaluation.
Outputs
Security Reports (To: A346 A71 A716 A723 A725)
•
•
•
•
[A728] Evaluate Security Management Performance

Description
The evaluation of Security Management process performance identifies areas that need
improvement; such as the foundation and interfaces of the process, activity definitions, key
performance metrics, the state of supporting automation, as well as the roles and responsibilities
and skills required. Insights and lessons learned from direct observation and data collected on
process performance are the basis for improvement recommendations.
Controls
security.
Inputs
Security Management Activity Data (From: A722 A723 A724 A725 A726 A727)
Outputs
Security Management Evaluation (To: A721)
•
•
•
•
Purpose
The purpose of Availability Management is to match the availability of the IT services against the
current and future identified needs of the business or to exceed them. Availability Management
enhances the availability of services by planning long-term service availability, measuring and
monitoring service availability, and formulating service availability design criteria that meet
requirements.
Definition of availability: “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.”12
Outcomes
As a result of the successful implementation of the Availability Management process:
IT infrastructure provides a consistent level of availability that enables the business to meet
its current and future objectives
Availability related incidents and problems are minimized
The provided level of availability is cost justified and optimized
Scope
ITIL defines components of availability to be:
Reliability – “A measure of how long a Configuration Item or IT Service can perform its
agreed Function without interruption.”13
Maintainability – "A measure of how quickly and Effectively a Configuration Item or IT
Service can be restored to normal working after a Failure. Maintainability is also used in the
context of Software or IT Service Development to mean ability to be Changed or Repaired
easily."14
Serviceability – "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."15
Includes
Availability needs and requirements
Identification of capabilities needed to meet requirements
New and existing IT services
Ensuring that availability provision of underlying services and suppliers in support of
primary IT services is factored in
Considering all aspects of IT service delivery and support that could impact availability
(training, tools)

•
•
•
•
Excludes
Business Continuity Management or disaster recovery (Business responsibility along
with IT Service Continuity Management)
Direct handling of service failures (Incident Management)
Approval of capabilities needed to meet requirements (Portfolio Management)
Creation of capabilities needed to meet requirements (Realization category of
processes)
Managing suppliers (Supplier Management)
Controls
contracts (UCs).

•
•
•
•

included.
Inputs

•
•
•
•

A452)
timeframe.
Outputs
Availability Plan (To: A75 A752)
A forward-looking plan aimed at improving the overall availability of the IT infrastructure
within cost constraints.
Availability Reports (To: A736 A737)
Statistics expressed on how well the IT Infrastructure has met the needs of the business in
availability terms. Might be included in Service achievement reports.
Activities
•
•
•
•
IT Strategy IT Management Service Security Policy Solution Analysis and SLAs OLAs UCs IT Plan
C4 Ecosystem Catalog C1 Design Framework/D1 C3 C5
C2 C6
I5 Establish
Stakeholder Availability Availability Management
Requirements Management Framework
Framework
A731
Determine
I3 Availability
and Roadmaps
Requirements
A732
Business Impact Formulate

Assessment Availability
Availability Availability and
I11
Requirements
and Recovery
Solution Recovery Design
Design Criteria Criteria
Plans and A733 Availability
Commitments Targets
Projected Service Outage/D2 Define and
Implement
I1 Availability
Security Targets and
Monitoring Data
Related Availability Metrics
I4 Measures Model
Solution Design A734
Monitor,
I10
Analyze
Operational
Monitoring Data and Report
Availability O3
A735 Availability
Reports
I6
Configuration
Information
Service Achievement Investigate Service Outage
Reports/D2 Unavailability Analysis
Supplier Product and O1
Service Information/D2 Change
A736 Request
Produce
I7 Availability
Change O2
Information Plan Availability
I2 A737 Plan
Incident Evaluate
Information Availability Availability
I8 Management
Problem Management
Information Availability Management Evaluation
Performance
Operational Documentation/D6 Activity Data A738
I9
Facilities
Plans and
Specifications
NODE: A73 TITLE:
Availability Management CURRENT PAGE:
Figure 4. A73 Availability Management
[A731] Establish Availability Management Framework

Description
Based on the business, IT strategy, and the architectural models, guidelines and a framework for
Availability Management have to be developed. The tasks in this activity include:
Understanding the requirements and specifications for availability management
Defining the strategy for availability management tools and capabilities, and how they
vendor capabilities
Specifying the data model for an Availability Management Information System:
• Defined by ITIL as: “A virtual repository of all Availability Management data, usually
stored in multiple physical locations.”20
Defining evaluation criteria for availability management solutions and services
Establishing the framework for Availability Management by defining and implementing
Determining skill requirements for the staff, and assigning staff based on these systems
Finally, the structure and process of Availability Management including escalation responsibilities

•
•
•
•
Availability Management. For example, the consideration of the Availability Management process
evaluation and the implementation of recommended improvement actions.
Controls
included.
Inputs
Availability Management Evaluation (From: A738)
An analysis of how well the Availability Management process was performed. This can also
include proposed modifications to the Availability Management Framework.
Outputs
Availability Management Framework (To: A732 A733 A734 A735 A736 A737 A738)
The set of policies, procedures and mechanisms for performing the Availability
Management process.

•
•
•
•
[A732] Determine Availability Requirements

Description
This activity addresses the translation of business user and IT stakeholder requirements into
quantifiable availability terms and conditions and targets, and then into availability-specific
requirements that eventually contribute to the Availability Plan.
Controls
Availability Management Framework (From: A731)
Management process.
contracts (UCs).
These agreements can be in a draft or finalized status.UC: “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.”24

•
•
•
•
Inputs
Business Impact Assessment
An appraisal of the impact of service unavailability on the business.
A452)
timeframe.
Outputs
Availability Management Activity Data (To: A738)
Results and metrics that describe the results of performing the Availability Management
process.
Availability Requirements (To: A733 A734)
An examination of the requirements for availability as expressed by the various
stakeholders. As there might be some contention between these, this process must
establish the definitive set of availability requirements which will influence solution and
service development and operation.
[A733] Formulate Availability and Recovery Design Criteria

Description
This activity endeavors to understand the vulnerabilities to failure of a given IT infrastructure
design, and to present design criteria that optimize the availability characteristics of solutions in the
IT environment, including recovery capabilities.
Controls
Management process.
•
•
•
•
Inputs
Availability Requirements (From: A732)
Outputs
process.
Availability and Recovery Design Criteria (To: A243 A422 A734 A764)
[A734] Define and Implement Availability Targets and Related

Measures
Description
This activity is responsible for the negotiation of achievable availability targets with the business,
based on business needs and priorities balanced with current IT capabilities and capacity. Both
business application and IT infrastructure elements should be taken into consideration as targets
are set.
In parallel, the activity represents availability measurement needs (through the Availability Plan) so
that appropriate measurement and reporting capabilities can be established and ready to support
monitoring and reporting of availability achieved against the targets.
Finalizing targets and associated mechanisms in place usually requires a cycle of feasibility
interactions rather than being completed in a single pass.
Controls
Management process.
contracts (UCs).
•
•
•
•
Inputs
Availability Requirements (From: A732)
Projected Service Outage (From: A515)
Activities and Test Plans on agreed Service Levels.”28
Outputs
process.
Availability Targets (To: A735 A737)
Objectives for service availability, typically focusing on service unavailability and business
impact.
Availability Metrics Model (To: A735 A737)
The range of availability metrics and areas of reporting that are used to describe service
availability.

•
•
•
•
[A735] Monitor, Analyze and Report Availability

Description
This activity supports continuous monitoring and analysis of operational results data and
comparison with service achievement reporting to identify availability trends and issues.
Configuration information is used to generate detailed service component availability reporting as
well as a perspective on overall service availability.
Controls
Availability Metrics Model (From: A734)
availability.
Availability Targets (From: A734)
impact.
Management process.
Inputs
receipt only.
• Prices
• Service levels
• Supply options, (suppliers can supply these supply items)
•
•
•
•
Outputs
process.
Availability Reports (To: A736 A737)
[A736] Investigate Unavailability

Description
The detailed investigation by this activity is performed to identify the underlying causes (not just
the symptoms) of any single incident, or set of related incidents, which have resulted in significant
service unavailability.
The Service Outage Analysis' resultant recommendations might raise one of more RFCs to
address these underlying causes.
Controls
Management process.
Inputs
Availability Reports (From: A73 A735)
receipt only.
•
•
•
•

• Prices
• Service levels
output.
Outputs
Service Outage Analysis (To: A664 A737)
book.
process.
[A737] Produce Availability Plan

Description
This activity generates the consolidated Availability Plan that summarizes resource availability
optimization decisions and commitments for the planning period. It includes availability profiles,
availability targets, availability issues descriptions, historical analyses of achievements with regard
to targets summaries, and documents useful lessons learned. The Availability Plan is a
comprehensive record of IT's approach and success in meeting user expectations for IT resource
availability.
Controls
Availability Metrics Model (From: A734)
availability.
•
•
•
•

Management process.
Inputs
Availability Targets (From: A734)
impact.
Service Outage Analysis (From: A736)
book.
Availability Reports (From: A73 A735)
Outputs
Availability Plan (To: A75 A752)
process.
•
•
•
•
[A738] Evaluate Availability Management Performance

Description
The evaluation of Evaluate Availability Management process performance identifies areas that
need improvement. For example, the foundation and interfaces of the process, activity definitions,
key performance metrics, the state of supporting automation, as well as the roles and
responsibilities and skills required. Insights and lessons learned from direct observation and data
collected on process performance are the basis for improvement recommendations.
Controls
Management process.
Inputs
Availability Management Activity Data (From: A732 A733 A734 A735 A736 A737)
process.
Outputs
Availability Management Evaluation (To: A731)
An analysis of how well the Availability Management process was performed. This can also
include proposed modifications to the Availability Management Framework.
•
•
•
•
Purpose
The purpose of Capacity Management is to match the capacity of the IT services and infrastructure
to the current and future identified needs of the business. Capacity Management focuses on the
complete spectrum from design and planning of service capacities through the operational aspects
of service capacity.
Definition of Capacity: “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.”29
Outcomes
As a result of the successful implementation of the Capacity Management process:
IT always has the capacity to meet the expected (agreed) current and future identified
needs of the business
Scalability requirements of the business are understood and accommodated
Incidents caused by lack of capacity are averted
The cost of capacity acquisition is reduced by planning and optimizing capacity usage.
Scope
The process covers a wide range: understanding service requirements, determining component
capacities, the design and deployment of capacity, and meeting expectations. It collects and
analyzes data that is relevant to application and infrastructure utilization and performance for the
purpose of determining whether there are potential problems and issues that need to be
addressed.
ITIL defines three focus areas which are addressed by Capacity Management. Each uses the
primary activities of the process decomposition in differing ways, to differing end results.
Business Capacity Management
• This focus area is responsible for ensuring that the impacts of future business
requirements for IT services upon IT resources are considered, planned, and
implemented in a timely fashion
Service Capacity Management
• This focus area is the management of the performance of the IT services used by the
customers. It is responsible for ensuring that service performance is monitored,
measured, and reported; and meets business requirements and agreements
Component Capacity Management
• This focus area is the management of the performance, utilization, and capacity of
individual technical components possessing finite resources
Includes
All aspects of the Performance Management discipline
Interfacing with Demand Management on Service Demand Forecasts

•
•
•
•
Component capacity management (both as it affects in-house service operations and

with consideration of impacts to and requirements upon service partners)
High-level service capacity monitoring
Determining the requirements for space and other facilities that will result from
capacity proposals and plans
Excludes
Low-level system capacity monitoring (Service Execution)
Generalized human resource management (Workforce Management)
Designing and implementing the facilities needed to support capacity plans (Facilities
Management)
Controls
contracts (UCs).
Organization. An OLA supports the IT Service Provider's delivery of IT Services to

•
•
•
•
included.
Inputs
A452)

•
•
•
•
timeframe.
• Commitments: Sets of requirements, designs and other deliverables, such as test cases
implemented.”35
Outputs
Capacity Reports (To: A256 A744)
of service.
Capacity Plan (To: A742 A743 A744 A75 A752)
The approach that will be taken to satisfy resource requirements. The plan is configurable,
meets performance expectations and has the required commitment to implement. It
includes:
• SLA recommendations
• Threshold and alarm definitions
Activities

•
•
•
•
IT Management IT Strategy IT Plan Service SLAs OLAs UCs

Ecosystem C3 C4 Catalog C2
C1 C5
Establish
I4 Capacity
Change Capacity Management
Information Management Framework
I8
Framework
A741
Solution
Plans and
Commitments
Model and Capacity
Requirements
I2 Size Capacity
Architecture Baselines Requirements
and Roadmaps A742
Capacity Models
and Results
Monitor,
O1
Analyze Capacity
I3 and Report Operational Reports
Configuration Capacity Schedule
Information Usage Directives O2
A743 Change
Capacity Delivery
Request
I5 Resource Reallocation
Operational Capacity Baselines Directives
Monitoring Data and Profiles
Operational Supervise Costing and
Schedules/D1 Tuning and Charging Request/S1
Capacity
I9
Service Level Package Delivery
Service Demand Forecasts/D1 A744 Service and
Service Achievement Resource Tuning O3
Reports/D3 Directives Service
Tuning and Resilience
I1 Produce and
Incident Capacity Delivery Directives
Information Allocation Maintain
Outcomes Capacity Plan O4
Capacity Plan
I6 A745
Problem
Information
I10
Evaluate
Change Schedule Capacity Capacity Management
I7
Facilities Capacity Management Performance
Plans and Activity Data A746
Specifications
NODE: A74 TITLE:

Capacity Management CURRENT PAGE:
Figure 5. A74 Capacity Management
[A741] Establish Capacity Management Framework

Description
Based on the business, IT strategy, architectural models and guidelines, a framework for Capacity
Management has to be developed.
Some particular items for Capacity Management are:
Identify the IT resources that will provide the Performance and Capacity services. If a
centralized, dedicated team is required and not already in place, then it must be formed by
pooling labor fragments from more general IT service support groups.
Training is a critical step for establishing performance and capacity services due to
constant technology change, key linkages with business directions, and the need for good
communication and project management skills.
Establish the basis for a capacity database to contain the business, technical, services and
resource information related to capacity. This involves tool selection and deployment, and
the establishment of data management for the performance and capacity data. It also
involves specifying the data model for a Capacity Management Information System.
• Defined by ITIL as: “A virtual repository of all Capacity Management data, usually stored
in multiple physical locations.” 36

•
•
•
•
Determination of appropriate SLAs and SLRs with the business is required. Establishment
of reports against those SLAs and SLRs is required. Definition of IT services to meet the
SLAs and SLRs is also required with estimated financial impacts for labor and IT
resources.
Formal linkage with the processes and tools for Incident, Problem, Change, and Release
Management, and the Service Desk need to be established. This, too, includes the creation
of templates and models for each.
Capacity Management. For example, this includes the consideration of the Capacity Management
Controls
included.
contracts (UCs).

•
•
•
•
Inputs
Capacity Management Evaluation (From: A746)
Outputs
Capacity Management Framework (To: A742 A743 A744 A745 A746)
work flows, inputs, outputs), information (entities, attributes, relationships) and technology
(software, hardware) practices for managing capacity.
[A742] Model and Size Capacity Requirements

Description
Modeling involves performance and capacity prediction through estimation, trend analysis,
analytical modeling, simulation modeling and benchmarking. Modeling can be performed for all or
any layer of the IT solution including the business, application and technology infrastructure.
Application sizing is a technique that predicts the service level requirements for response times,
throughput, and batch elapsed times. It also predicts resource consumption and cost implications
for new or changed applications. It predicts the effect on other interfacing applications. It is
performed at the beginning of the solution life cycle and continues through the development,
testing and implementation phases. Application sizing has a strong correlation with performance
engineering.
Performance engineering is a technique that focuses on the assessment, establishment, and
integration of performance planning processes and performance engineering methods within the
development life cycle and implementation of prepackaged software. Performance engineering
can aid in planning for effective use of existing resources, making informed equipment purchase
decisions, and addressing potential performance risks and exposures more quickly. To improve
strategic planning and reduce development costs, performance engineering methods and
practices can be incorporated into the application development and business planning processes.
Understanding application design implications, system requirements, capabilities and costs early
in the application development process improves project planning to help ensure success. Using
these processes also helps your staff continually improve system performance, reduce costs, and
increase productivity and user satisfaction.
Modeling and sizing are used to determine performance and capacity requirements. These
requirements are met by the formulation and implementation of policies. Establishing and
maintaining Performance and Capacity Management policies involves administration of pools of
specific computing resources by managing policies for how resources are reserved, whether
overbooking is allowed, how resources are monitored, and so forth. Resource-specific policies

•
•
•
•
depend on the characteristics that are associated with particular resource types. For example,
storage systems have different characteristics (space allocated, striping, access control) than
networks (bandwidth allocation, packet loss rate). A policy framework provides a general,
formalized way of controlling such customization and variability within a system through the use of
policies.
Controls
Capacity Management Framework (From: A741)
Capacity Plan (From: A74 A745)
includes:
Inputs
contracts (UCs).

•
•
•
•
A452)
timeframe.
calendar.
Outputs
Capacity Requirements (To: A744 A745)
Detailed forecasts of the IT resource capacity needed to satisfy projected workloads and
service level commitments while maintaining acceptable utilization and load factors.
For example, they can include: CPU processing power, storage space, and network
bandwidth.

•
•
•
•
Capacity Models and Results (To: A743 A744)

Qualitative and quantitative algorithms and projections used to track and predict IT
resource capacity and usage patterns.
Capacity Management Activity Data (To: A746)
[A743] Monitor, Analyze and Report Capacity Usage

Description
Monitors should be established on all the components and for each of the services. The data
should be analyzed using, wherever possible, expert systems to compare usage levels against
thresholds. The results of the analysis should be included in reports, and recommendations made
as appropriate.
There is a fundamental level of data collection and reporting necessary in any environment before
capacity and performance services can be established.
Monitors and Data Collection and Reporting suites might be required at many levels, including but
not limited to, the operating system, the database, the transaction processor, middleware, network,
Web Services, and end-to-end (user) experience.
Controls
contracts (UCs).

•
•
•
•
includes:
Inputs
Capacity Models and Results (From: A742)
adjustments.
Outputs
Capacity Reports (To: A256 A744)

•
•
•
•
• Forecasts and predictions (To: A254 A255 A744 A745)Capacity Baselines and Profiles
[A744] Supervise Tuning and Capacity Delivery

Description
Outputs from monitoring, analyzing, and reporting activities are examined and actions to tune
individual resources or to re-balance the available capacity are planned and initiated through
Change and Release Management. They can also be performed through the Service Desk in the
case of simple requests to other support groups or self-help for users. Some recommendations
might involve changes in the way that the users use the IT systems. This can include simple
recommendations, like moving discretionary workloads to off-peak periods or performing a
business function using a more efficient IT service path. Other changes can take the form of
balancing services, changing concurrency levels, and adding or removing resources. The cycle
then begins again, monitoring any changes made to ensure they have had a beneficial effect and
collecting the data for the next day, week, or month.
Service and resource tuning enables effective utilization of IT resources by identifying inefficient
performance, excess or insufficient capacity, and making recommendations for optimization. It can
balance the need to maintain service while reducing capacity capability to reduce the cost of
service.
Understanding the combined performance impact of various components within a complex
infrastructure is needed to accurately differentiate symptoms from actual problems. This level of
understanding provides the most accurate baseline for future planning. Analysis and tuning can
reduce support costs by identifying performance and availability problems, often before they
impact your business operations or users. Using this information, decisions can be made to better
allocate resources to those areas with the highest business priority.
Recommendations can be made to improve the performance of off-the-shelf applications or unique
in-house business applications.
This activity examines the monitored workload demand for servers, middleware, and applications
under management. It can sense if performance has degraded and determine what actions need
to be taken, either by provisioning and configuring servers, operating systems, middleware,
applications, storage, and network devices.
It can be reactive in response to unpredictable business activity. For example, the existing
infrastructure provisioning is inadequate relative to increased demand. It can also be done
reactively, if a dependent IT infrastructure component is faulty or not working to its expected
performance specification. Based on examining performance of resources over time, it can choose
to adjust thresholds and warning levels.
The activity can be performed proactively. For example, workload policies are enforced to limit or
increase the amount of resources consumed by a particular application or business function.
Limitations and constraints can be applied to contain IT processing costs or differentiate the level
of service received by one business function over another. Increases in capacity capability can be
applied to manage unexpected increases in workload demand.
In summary, this activity makes decisions and performs or requests actions that will result in a
better match between resource supply and demand.
•
•
•
•
Increasingly, the management of resource demand is being automated or semi-automated.

Typically, workloads to be managed are expressed in a technology independent manner or
virtualized for subsequent mapping onto a physical IT infrastructure. The tools that manage
resource demand in this way are said to be performing orchestration or choreography.
Controls
contracts (UCs).
includes:
• Threshold and alarm definitions.

•
•
•
•
Inputs
Capacity Requirements (From: A742)
bandwidth.
Capacity Reports (From: A74 A743)
Capacity Models and Results (From: A742)
receipt only.

•
•
•
•
implemented.”52
Outputs
Costing and Charging Request (To: A833)
An inquiry about (or an estimate of) the cost or charge related to a particular IT service or
cluster of services.
Operational Schedule Directives
Desired changes and adjustments to operational schedules, used to optimize the workload
throughput or other characteristic within a finite capacity. Sometimes a part of a general
Service Resilience Directive.
Capacity Delivery Resource Reallocation Directives
Desired changes and adjustments to resource allocations for the purpose of optimizing
available capacity against demand. Sometimes a part of a general Service Resilience
Directive.
Service and Resource Tuning Directives (To: A256 A743 A745)
adjustments.
Tuning and Capacity Delivery Allocation Outcomes (To: A745)
The results of tuning and capacity delivery allocation activities upon balancing resource
supply with workload demand. Some actions will be considered sufficiently permanent to
influence the overall capacity plan.
[A745] Produce and Maintain Capacity Plan

Description
The objective of this activity is to develop, maintain, test and revise alternative approaches in
satisfying various enterprise-shared resource requirements. It delivers the capacity plan that
addresses the customer's resource requirements. This plan is configurable, meets performance
expectations, and has the required commitment to implement.
The inputs to this activity are forecast assumptions, forecast projections, and subject matter expert
recommendations. The controls for this activity are financial constraints, hardware constraints,
performance policies, resource standards and definitions, and strategy and direction. The
deliverables from this activity are the agreed capacity plan, alternative solutions, and an optimized
resource solution.
The Capacity Plan will detail existing usage of critical IT resources under management. Typically,
for servers this involves reporting and trend analysis for CPU, I/O, memory, storage, and the
network interfaces. The Capacity Plan can also include correlation of IT resource usage to IT

•
•
•
•
applications (services) and business usage patterns. Similarly, planned business activity and IT
application changes and deployments might be factored into forecasts for IT resource
requirements.
Controls
contracts (UCs).
Inputs
Capacity Requirements (From: A742)
bandwidth.

•
•
•
•

adjustments.
Tuning and Capacity Delivery Allocation Outcomes (From: A744)
The results of tuning and capacity delivery allocation activities upon balancing resource
supply with workload demand. Some actions will be considered sufficiently permanent to
influence the overall capacity plan.
calendar.
implemented.”56
Outputs
Capacity Plan (To: A742 A743 A744 A75 A752)
includes:
[A746] Evaluate Capacity Management Performance

Description
Measurements include the definition, collection of measurements, the analysis, and the review and
reporting for Capacity Management. Primarily, the data provides a mechanism to identify and
reduce process incidents and problems, propagate best practices as a means for continuous
improvement, and to maintain or improve customer satisfaction. Measurement data is also

•
•
•
•
commonly used to evaluate performance against service level agreement (SLA) objectives and to
provide billing and credit information.
There are a number of external factors that can contribute to substandard Capacity Management.
However, the measurements are focused on the results of activities within the scope of this
process.
The effectiveness and efficiency measurements for Capacity Management are described. Note
that the order of the measurements listed does not necessarily indicate their order of importance.
The percentage of IT resources under management for which a standard, pre-defined set
of performance and capacity data is routinely collected, summarized and reported on for
trends and exceptions.
The timely production and distribution of accurate standard reports. In order to assure the
timely delivery of reports, report timeliness is calculated as a percentage of standard
reports delivered on or before the commitment date.
Capacity Planner Productivity: Work units per analyst where work units are normalized
measurements of workload taking into account various server support variables like
maturity, complexity, and seasonal variability.
Number of escalations per month, raised by Incident or Problem Management. Escalations
are defined as severity one incidents where the root cause has been determined to be
within the scope of Capacity Management.
Proactive Capacity Planning for planning timeliness and accuracy. The capacity plan is
accepted and maintained in a timely manner and approved recommendations from the
capacity plan for hardware or software upgrades are implemented and validated for
efficacy and cost.
The percentage of performance and capacity service level agreements achieved in a
specified period of time.
The accuracy of tuning benefits predicted.
Controls
Inputs
Capacity Management Activity Data (From: A742 A743 A744 A745)
Outputs
Capacity Management Evaluation (To: A741)
•
•
•
•
Purpose
The purpose of the Facilities Management process is to create and maintain a physical
environment that houses IT resources and to optimize the capabilities and cost of that
environment.
Definition of Facilities Management: “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”.57
Outcomes
As a result of the successful implementation of the Facilities Management process:
The physical environment within which information technology resources perform supports
operational needs
Availability of IT systems is protected from physical threats (including environmental,
security, continuity)
Facility requirements are analyzed, planned for, and met in a timely and cost-effective
manner
Scope
Includes
Physical facilities planning and implementation (physical planning) – space, power,
HVAC, physical cables and connectors, physical security implementation, protection
(such as sprinklers, halon systems, badge readers, security personnel)
Physical logistics (receipt, staging, moving)
Physical environment for all information and communications technology
– For example, participating in the design of racks and cabling
Physical access management to IT facilities
Safety
Managing incidents concerning facilities, and interfacing with Incident Management
when both IT and Facilities components are involved
Excludes
Asset Management
Business resilience and continuity (Business responsibility, in conjunction with IT
Corporate facilities (buildings, maintenance, catering, mail delivery, desks, lights)
unless associated with a secure data center (Business responsibility)

•
•
•
•
Security of corporate facilities, such as office buildings, factories (Business

responsibility)
IT security policies and practices (Security Management)
Media management (see Data Management) but would include physical
transportation and security of media
Management of suppliers (Supplier Management)
Controls
Management)
contracts (UCs).

•
•
•
•
included.
Program.
Inputs
includes:
Availability Plan (From: A73 A737)
target.

•
•
•
•

implemented.”61
IT Service Continuity Plan (From: A76 A764)
A formal, documented plan describing procedures to be adhered to in order to facilitate the
recovery and restoration of critical business services. Includes a possible need for new
capabilities to meet service continuity requirements.
Outputs
• Attributes
• Relationships
Facilities Plans and Specifications (To: A72 A723 A726 A73 A737 A74 A745 A753 A754
A76 A764)

•
•
•
•
Activities
A751 Establish Facilities Management Framework
SLAs OLAs UCs IT Management IT Strategy Business Security Business Regulations IT Plan IT Budget Security Policy Identity and
Ecosystem Policies and Plans Facilities and Standards/D1 C8 C2 Access Rights
C5 C6 C7
C4 C9 Plan C3 Register
I10 C1
Change
Information
Asset Management
Framework/D2
Establish
Supplier Management Facilities Facilities
Framework/D1 Management Management
Framework Framework
IT Service Continuity A751
Management Framework/D1
Security
Management Plan
Framework/D2 O4
Facilities Facilities
I7
Plans and
Solution Design
Specifications
I3 Facilities
Procedures
Security Plan
and Schedules
I11 A752
IT Service Facility Request
Continuity
Manage Response
Plan Facility
I9 Request Facility
Configuration Request
A753 Fulfillment
Information O1
Plan
I6 Change
and Roadmaps Request
Facility O3
I1 Request CI Data
Capacity Plan Exceptions Update Package
Operate and
I2 Asset Data
Availability
Maintain Update Package/S4
Plan Facilities
I8 A754
Change Schedule
Facility O2
I4 Request_ Incident
Service Request_ Qualified Facility
Authorized Facility
Incident_
Request
Evaluate Closed
Change/D3 Facilities Facilities
I5 Evaluation
Incident Facilities Management
Performance
Information Activity Data A755
Facility
Incident
NODE: A75 TITLE:

Facilities Management CURRENT PAGE:
Figure 6. A75 Facilities Management
•
•
•
•
[A751] Establish Facilities Management Framework

Description
This activity defines and documents the rules, policies, standards, guidelines and practices
governing day-to-day IT facility operations. The scope includes managing assets, service levels,
suppliers of service (internal and third party), physical security, and IT continuity in accordance with
corporate policies and plans.
Controls
contracts (UCs).
included.

•
•
•
•
Inputs
Supplier Management Framework (From: A821)
The framework that contains all relevant information about the structure of the Supplier
Management process, meaning the practices for supplier management and procurement.
This includes evaluation criteria for selection and evaluation of suppliers, and relevant
systems.
IT Service Continuity Management Framework (From: A761)
The conceptional structure describing the strategic (vision, mission, value proposition,
policies), organizational (organizational mechanisms, roles, accountabilities), process
(activities, work flows, inputs, outputs, procedures), information (data model, management
reports) and technology (software, hardware) practices for managing IT service continuity.
security.
Facilities Management Evaluation (From: A755)
Outputs
Facilities Management Framework (To: A752 A753 A754 A755)
The policies, guidelines, plans, procedures and targets for the workings of the Facilities
Management process.
[A752] Plan Facilities

Description
This activity is the ongoing effort to plan new buildings or updates to existing buildings and other
facilities so they efficiently provide the physical infrastructure (electric, water, backup power,
security, cabling) to support IT service level requirements. This activity should be closely aligned
with the business strategy, regulations and standards, as well as IT plans.
Controls
Facilities Management Framework (From: A751)
Management process.
Program.
•
•
•
•
Business Facilities Plan

The plan, established by the Business, describing the quantity, locations, and other Facility
items that enable it to operate.
Management)
Inputs
includes:
•
•
•
•
Availability Plan (From: A73 A737)
implemented.”65
Facility Request Exceptions (From: A753)
This is an ad hoc request that does not conform to the current plans, but is within the
overall remit of the facility framework. It can potentially be addressed by some additional
facility planning.
Outputs
Facilities Plans and Specifications (To: A72 A723 A726 A73 A737 A74 A745 A753 A754
A76 A764)
Facilities Procedures and Schedules (To: A754)
Documentation on facilities procedures, facilities availability, and use of facility
infrastructure for IT and the user community. This information is available to Knowledge
Management, for it to determine which parts (if any) are needed to be available to the IT
processes.
Facility Request (To: A753)
A request for Facility changes that conform to the framework or the plans for the facility.
Facilities Management Activity Data (To: A755)
[A753] Manage Facility Request

Description
This activity evaluates facility requests, formulates the plans on how they will be fulfilled, and
manages the request through completion.
Controls

•
•
•
•

Management process.
Inputs
implemented.”66
Facility Request (From: A752)
A request for Facility changes that conform to the framework or the plans for the facility.
Facility Request_ Qualified (From: A754)
A need for a facility request to be re-planned as a result of an operation or maintenance
activity producing a result out of line with the plan.
Outputs
Facility Request Response
The fulfillment of the Facility Request and information about it, including:
• Description of the request
• Notification to the requestor as to how the request was addressed
• Updates to CI information and asset information
• Attributes
• Relationships
Facility Request Fulfillment Plan (To: A754)
The plan (instructions, specifications) for the fulfillment of the facility request using normal
facility operation or maintenance.

•
•
•
•
Facility Request Exceptions (To: A752)

This is an ad hoc request that does not conform to the current plans, but is within the
overall remit of the facility framework. It can potentially be addressed by some additional
facility planning.
[A754] Operate and Maintain Facilities

Description
This activity addresses the tasks that perform the work required to achieve efficient day-to-day
running of the IT facilities, as well as raising requests for new facility elements and considering
facilities-related incident information.
Controls
Facilities Procedures and Schedules (From: A752)
Documentation on facilities procedures, facilities availability, and use of facility
infrastructure for IT and the user community. This information is available to Knowledge
Management, for it to determine which parts (if any) are needed to be available to the IT
processes.
Management process.
Inputs
Facility Request Fulfillment Plan (From: A753)
The plan (instructions, specifications) for the fulfillment of the facility request using normal
facility operation or maintenance.
Facility Incident
An external event resulting in a real or suspected failure of one or many components of the
facility, and the related notification and information about the incident.
• Facility incidents might be handled separately (for example, by the business) from the IT
Incident Management process
•
•
•
•
Outputs
• Attributes
• Relationships
Facility Incident_ Closed
Information about the facility incident life cycle and outcome, including:
• Notification to the requestor that the request was addressed
• Feedback to any relevant IT processes, such as supplier management, workforce
management, financial management
Facility Request_ Qualified (To: A753)
A need for a facility request to be re-planned as a result of an operation or maintenance
activity producing a result out of line with the plan.
[A755] Evaluate Facilities Management Performance

Description
This is the continuing activity of monitoring the current IT Facilities Management Performance. It
utilizes established facilities measures (as defined by the process framework). This activity is
conducted in order to make key measurements of the health of the facility management system,
as well as factors other than measurements, that might indicate a need for change in the facility
management system.
The evaluation of process performance identifies areas that need improvement; such as the
supporting automation, and the roles and responsibilities and skills required. Insights and lessons
learned from direct observation and data collected on process performance are the basis for
improvement recommendations.
•
•
•
•
Facilities Management FrameworkControls (From: A751)

Management process.
Inputs
Facilities Management Activity Data (From: A752 A753 A754)
Outputs
Facilities Management Evaluation (To: A751)
•
•
•
•
Purpose
The purpose of the Service Continuity Management process is to ensure that agreed IT services
will support business requirements in the event of a disruption to the business, based on the
committed recovery schedule.
Definition of IT Service Continuity Management: “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.”67
Outcomes
As a result of the successful implementation of the IT Service Continuity Management process:
A set of IT Service Continuity and IT Recovery plans are created, maintained, and tested
that support the organization’s overall Business Continuity Plans
Business continuity targets can be met through the recovery of agreed IT services and
technical facilities to agreed time scales, under Change Management control
Regulatory requirements for IT service continuity are met
Business vitality and functions are maintained at agreed levels
Scope
The process fulfils its mission through risk reduction measures, controlled recovery options, and
restoration facilities.
Includes
Service capability for prioritized, critical business processes, and their attendant
support requirements. Examples include:
– IT application services
– Organizational procedures
– Consideration of facilities
– Consideration of IT Services provided by business partners
Specification of service continuity solutions
Definition of circumstances and thresholds for continuity invocation
Contributing to proactive prevention of IT disruptions (by identifying and analyzing
risks, and sharing the analysis)
Control of continuity solution invocation in the event of disruption
Testing of the continuity solution
Excludes
Normal operational fluctuations (Service Execution, Event Management)
Minor technical faults that are covered by Incident Management

•
•
•
•
Deliberate business strategy changes and long term risks such as business
diversification or restructuring (IT Strategy)
Responsibility for identification and prioritization of critical business processes
(performed in a business impact analysis by the Business Continuity Management
process: outside the scope of this model)
Development and implementation of service continuity solutions (once agreed by
Portfolio Management, these solutions are treated as any other solution through
Realization and Transition)
Contractual arrangements with third parties (Supplier Management)
Controls

•
•
•
•

contracts (UCs).
included.
Industry Risk Threats and Vulnerabilities
Known risks, threats and vulnerabilities which exist from other organizations in the same
business sector, and environmental risk.
Business Continuity Policies
Rules and guidelines used to assist in the determination of critical business services, and
in the determination of potential risks, threats, and vulnerabilities.
Inputs
compliance

•
•
•
•
Outputs
of service.
IT Service Continuity Plan (To: A75 A752 A765 A766)
Activities
•
•
•
•

IT Strategy IT Management Service Business Industry Risk, Threats Security Policy Security Plan SLAs OLAs UCs
IT Plan
C6 Ecosystem Catalog Continuity and Vulnerabilities C3
C8 C1 C5
C4 C2 Policies
C7
C9
Security Establish IT
Management
Framework/D3
Service
Continuity IT Service Continuity
Management Business Service
Framework Continuity
A761 Requirements
Identify
Business
Service IT Service
Continuity Continuity
I5 Policies and
Architecture Baselines Requirements IT Service Continuity
A762 Strategy
and Roadmaps Create and Risk Reduction
Maintain IT Design Criteria
Service
I3 Continuity
Compliance Plans
and Controls
Strategy
A763
I7
Configuration IT Service
Information Continuity
Requirements Create and
I2 Maintain IT O3
Change Service IT Service
Continuity
Plan
Plan A764 IT Service
Availability and Continuity
Recovery Design Capability
Criteria/D3 Prepare IT O1
I1 Service Change
Facilities Request
Plans and
Continuity
O2
Specifications Capability Service
A765 Operational
I6 Continuity Resilience
Solution Design Infrastructure Directives
I4 Execute IT
Problem Normality
Information
Service Notification
I8 Continuity
Solution_ IT Service PlanA766
Deployed Continuity IT Service Continuity
Solution Test and Evaluate IT
Operational Audit Results
Documentation/D8 Service IT Service
Backed Up Data Management
IT Service Continuity Management Evaluation
and Manifest/D1
Continuity Notification A767
Activity Data
Change/D1
NODE: A76 TITLE:

IT Service Continuity Management CURRENT PAGE:
Figure 7. A76 IT Service Continuity Management
[A761] Establish IT Service Continuity Management Framework

Description
Based on the business and IT strategy and models, guidelines and a framework for IT Service
Continuity Management have to be developed. The tasks in this activity include:
Understanding and developing the business strategy and legal and self-imposed
regulations with regard to service continuity
Establishing the framework for Service Continuity Management by defining and
Finally, the structure and process of IT Service Continuity Management including continuity
The establishment of the process framework also includes the continuous improvement of IT
Service Continuity Management. For example, the consideration of the IT Service Continuity
•
•
•
•
Controls
included.
Inputs
security.
IT Service Continuity Management Evaluation (From: A767)
Assessment results for the IT Service Continuity Management process and it activities,
including process performance metrics and the identification of potential process
improvement items.
Outputs
IT Service Continuity Management Framework (To: A751 A762 A763 A764 A765 A766
A767)

•
•
•
•
[A762] Identify Business Service Continuity Requirements

Description
This activity identifies those business services which are critical for the ability of an organization to
survive. In carrying out the activities associated with the identification of these services, relevant
IT support processes, such as Problem Management, are also identified as these too form a
service in supporting the business.
The activity continues with an impact analysis that identifies what will happen in the result of the
loss, or degradation, of one or more of those critical business services.
Further, an assessment is made to identify risks and determine the vulnerability of each business
service.
This activity culminates in a set of Business Service Continuity requirements.
Controls
Industry Risk Threats and Vulnerabilities
Known risks, threats and vulnerabilities which exist from other organizations in the same
business sector, and environmental risk.
Inputs
contracts (UCs).

•
•
•
•
Outputs
Business Service Continuity Requirements (To: A763)
The results of a business impact analysis, with identified risks, threats, and vulnerabilities.
IT Service Continuity Management Activity Data (To: A767)
evaluation of the overall IT Service Continuity Management process.
[A763] Create and Maintain IT Service Continuity Strategy

Description
This activity is responsible for identifying risk reduction measures for the business services
identified, and to establish what countermeasures and recovery options exist to support these
services should they be adversely affected.
It takes into account the types of risks that might be encountered, and the potential costs involved
for each recovery option.
The result of this activity is an agreed IT Service Continuity Strategy and a set of IT service
continuity requirements.
Controls

•
•
•
•

contracts (UCs).
Inputs
Business Service Continuity Requirements (From: A762)
The results of a Business Impact Analysis, with identified risks, threats, and vulnerabilities.
compliance
IT Service Continuity Test and Audit Results (From: A765)
Data (or reports) detailing the success or failure of a planned, or unplanned, test of the IT
Service Continuity Plan.
Outputs
IT Service Continuity Risk Reduction Design Criteria
Identification of approaches which, if adopted in the design of the solution and in its
implementation as a service, would reduce overall continuity risk.

•
•
•
•
IT Service Continuity Policies and Strategy (To: A764 A765 A766)

The guiding statements which direct the IT Service Continuity preparations, maintenance
of readiness and actual invocation. For example, they include rules that must be adhered to
in the event of either a test or an invocation of the IT Service Continuity Plan.
IT Service Continuity Requirements (To: A764)
Includes details of prioritization of Capacity, Availability, and other Service Level items that
must be satisfied by the IT Service Continuity Capability.
[A764] Create and Maintain IT Service Continuity Plan

Description
This process is responsible for identifying:
The infrastructure (people, processes, technology) necessary to support the required
services in the event that the continuity is invoked.
The actions that would then be taken to result in successful invocation of the IT Service
Continuity Plan.
It is also responsible for the ongoing maintenance of the plan and takes into account changes to
critical business services and changes to the infrastructure that these business processes use.
This process culminates in the creation of the IT Service Continuity Plan, which is then placed
under change control and also forms part of the Business Continuity Plan.
Controls
IT Service Continuity Policies and Strategy (From: A763)
•
•
•
•
contracts (UCs).
Inputs
IT Service Continuity Requirements (From: A763)
Includes details of prioritization of Capacity, Availability, and other Service Level items that
must be satisfied by the IT Service Continuity Capability.

•
•
•
•

output.
IT Service Continuity Test and Audit Results (From: A765)
Outputs
IT Service Continuity Plan (To: A75 A752 A765 A766)
[A765] Prepare IT Service Continuity Capability

Description
This process ensures that an invocation of the IT Service Continuity Plan results in the ability to
recover and restore required services to a predetermined level, and in a predetermined time frame.
It has the responsibility for ensuring that all plans are tested regularly, both on a planned and
unplanned basis; that the process passes audit requirements; and that the results from tests are
captured and fed back to other processes to ensure that the IT Service Continuity Plan remains fit
for purpose.
Controls
•
•
•
•
Inputs
IT Service Continuity Solution
The technical solution which will provide the infrastructure for continuity testing and
invocation.
output.
Backed Up Data and Manifest (From: A635)
Outputs
IT Service Continuity Capability (To: A766)
The combination of infrastructure and human resources (associated process and
organization) which IT can invoke the IT Service Continuity Plan.
IT Service Continuity Test and Audit Results (To: A763 A764)
•
•
•
•
[A766] Execute IT Service Continuity Plan

Description
This process is responsible for implementing the IT Service Continuity Plan, according to
predetermined criteria. It is responsible for maintaining business operations for an unspecified
amount of time, and for ensuring a controlled restoration to normal service.
Controls
contracts (UCs).
Inputs
IT Service Continuity Capability (From: A765)
The combination of infrastructure and human resources (associated process and
organization) which IT can invoke the IT Service Continuity Plan.

•
•
•
•

output.
Backed Up Data and Manifest (From: A635)
Continuity Notification
An urgent, formal command to invoke the IT Service Continuity Plan.
Outputs
Operational Continuity Infrastructure
The IT Service Continuity Solution in live state, ready for delivering the planned level of
operational service, and all relevant details about it so that the regular set of processes can
perform their work, within the limitations of that continuity solution.
Normality Notification
A notification that critical business services have been stabilized to a condition that reflects
the new normal operation, following a period of operating under continuity status.
•
•
•
•
[A767] Evaluate IT Service Continuity Management Performance

Description
This process evaluates the performance of the Service Continuity Management process. It aims to
identify areas of the overall process requiring improvement. This means the foundation and
interfaces of the process, its activities, their accomplishment, their degree of automation, as well
as the roles and responsibilities including the respective skills. Target for evaluations also includes
the continuity suppliers and supply items.
The basis for the improvements is the insights and lessons learned from the observations and
Controls
Inputs
IT Service Continuity Management Activity Data (From: A762 A763 A764 A765 A766)
Outputs
IT Service Continuity Management Evaluation (To: A761)
Assessment results for the IT Service Continuity Management process and it activities,
including process performance metrics and the identification of potential process
improvement items.
•
•
•
•
PRM-IT A7 Node Tree
PRM-IT A7 Node Tree
A7 – RESILIENCE
A751 Establish Facility Management Framework
•
•
•
•
PRM-IT A7 Node Tree
A7 – RESILIENCE
Figure 8. A7 Resilience Node Tree
•
•
•
•
PRM-IT A7 Node Tree
•
•
•
•
[A8] Administration
Description
Purpose
The Administration process category brings together the processes that look after many of the non-
technical resources: people, finances, and contracts, among others that support IT service
delivery. It builds a sound foundation for the IT business, which other processes can deliver the IT
services for the parent business.
Rationale
The processes in this category help build and manage the necessary infrastructure for controlling
IT resources (such as hardware, software, and people). These processes are a necessary part of
any endeavor's management system and contain the fundamental management building blocks of
any organizational entity; namely, people management, financial and administrative management,
pricing and contract management, and skills management. Failure in any of these areas of
management could lead to the failure of the IT entity of the business. Without these processes,
there would be no ability to accomplish the information technology mission of the business,
regardless of the technology available.
Value
through IT
Controls
Environment Information (From: Outside-the-Model)
Business Strategy
Inputs
•
•
•
•
Customer Input (From: Outside-the-Model)
Supplier Input (From: Outside-the-Model)
Business Funding (From: Outside-the-Model)
Outputs
Customer Output (To: Outside-the-Model)
IT Budget (To: A1 A12 A121 A123 A125 A13 A131 A132 A133 A14 A142 A2 A22 A221
A844)
Supplier Output (To: Outside-the-Model)
Underpinning Contracts (To: A1 A11 A114 A2 A24 A241 A243 A3 A31 A313 A5 A55 A555
A81 A813 A814 A824 A825 A826)
IT Financial Reports (To: A1 A13 A131 A14 A141 A3 A36 A365 A366 A5 A55 A555 A6 A66
A661 A816 A82 A822 A824 A825)
Processes
•
•
•
•
IT Strategy IT Portfolio SLAs OLAs UCs Security Policy IT Management Service Business Architecture Baselines
and Roadmaps Environment
C4 C3 C6 C1 Ecosystem Catalog Strategy
Business C2 Information
C7 C5 C9
Accounting C8
Framework
I5 Technology
Business Capabilities
Input and Trends/D1
I1 Regulations and
Standards/D2 O3
IT Plan Supplier Supplier
Payments Output
I12
Financial
Management O2
Business Funding IT Budget
A81 Customer O5
I3 Charges or Request to Purchase IT Financial
Compliance Plans Cost Data Invoices Supplier for Information Orders Reports
and Controls
Supplier
I4 Contract
Asset Information Management Requirements
O4
Customer Payment Underpinning
I10 A82 Contracts
Customer Input
Purchase Order Status
I7 Asset
Business and
IT Models Service
Supplier
Invoices Pricing and
I9 Contract O1
Service Level Package Customer Output
I2 Administration
Service Metric Data Items_ Information From A83
and Reports Procured Suppliers
Service Pricing and
I11 Contract Information
Supplier Input Workforce Skills Plan
I6 Management
Solution Design Workforce
Management
A84 Information
I8
IT Research
Guidance
Advanced Practices
Knowledge
Knowledge_ Management Knowledge
Internal and Assets
External
A85
Knowledge
Request
NODE: A8 TITLE:
Administration CURRENT PAGE:
Figure 1. A8 Administration Diagram
•
•
•
•
Purpose
The purpose of the Financial Management process is to ensure that financial controls and
procedures are in place to effectively predict and control IT budgets, enable business decisions,
and ensure that legal, corporate and regulatory compliance is maintained. The outputs from the
Financial Management process also enable benchmarking and business case analysis to support
organizational decision making.
Outcomes
IT financial controls are established and enforced
Operational data is transformed into financial information and management actions
Compliance is ensured with legal, industry, and corporate standards and procedures
Benchmarking and other financial comparisons are enabled
IT portfolio decisions are assisted on investment by providing detailed business cases and
by providing financial input to decision support
IT budgets are effectively predicted and controlled
Scope
IT finance is focused on budgeting, accounting and (optionally) charging for IT resources
Includes
Budgeting – capital and operational
Accounting – including accounts receivable (AR) and accounts payable (AP)
Charging
– Metering, rating and billing
Cost models and accounting systems
Resource types:
– Labor
– Products
– Services (inbound and outbound)
Decision Support
Financial analysis and reporting
Collecting financial data
Operational data collection requirements for financial purposes
Design and implementation of accounting systems
Analysis and control of the impact of chargebacks (influences on user and customer
behavior)
Paying internal and external invoices and bills
Financial management (depreciation) of assets
•
•
•
•
Excludes
Asset management (including life cycle management)
– Systems and services (Service Execution)
– Time recording and labor claiming (any process, especially Program and Project
Management)
Service, solution, and offering pricing (Service Pricing and Contract Administration)
Contract management (Service Pricing and Contract Administration)
Controls
included.
contracts (UCs).
1. ITIL V3 Glossary
2. ITIL V3 Glossary
3. ITIL V3 Glossary
•
•
•
•

Business Strategy
policies.
Management)
an SLA.” 5
Inputs
Business Accounting Framework
Details of the business-wide financial framework, including the required interfaces with the
IT Financial Framework.
4. ITIL V3 Glossary
5. ITIL V3 Glossary
•
•
•
•

activities in IT.
compliance
individual asset.
Customer Payment
Customer payment describes the incoming cash flow (real or virtual) from a customer. It is
either the information about a customer payment (from the business' accounts receivable
process) or could be the actual payment.
Supplier Invoices
Invoices from the suppliers for products and services delivered to IT.
compensation.
Purchase Order Status (From: A82 A824)
Status of orders (necessary to track the orders).
Outputs
Supplier Payments (To: A816)
Payments to suppliers, triggered by supplier invoices, for services delivered to IT.
A844)
A661 A816 A82 A822 A824 A825)
•
•
•
•
Customer Charges or Invoices (To: A814 A816)

Customer charges or invoices describe how much a customer is being charged or billed for
the usage of IT in a certain period of time.
Cost Data (To: A816 A83 A832)
Describes the cost aligned with defined criteria. Typical criteria: by service, by customer,
and by cost unit.
Activities
Business IT Strategy Regulations and IT Management IT Portfolio Service Underpinning

Service Pricing and SLAs OLAs UCs
Strategy C1 Standards/D2 Ecosystem C2 Catalog Contracts
Contract Information C3
C7 C4 C5 C9
C6 C8
I1
Business
Accounting
Framework Establish
I4 Financial
Compliance Plans Management Framework
and Controls Framework
A811
IT Financial Modeling Perform

Request
Financial
I2
IT Plan Modeling IT Financial
Modeling Analysis
I3 A812
Business Funding
Plan and O2
Portfolio Decision and Control IT Budget
O3
Resource Allocation/D1 Budgets
IT Financial
I10
A813 Reports
Individual IT Process Perform

Activity Data Financial O1
Supplier
Accounting Service Payments
I6 Accounting
A814 O5
Data
Customer Payment
Budget Variance Cost Data
I8
Supplier Administer
Invoices Charging
I9
Workforce O4
Management Customer
Information A815
Charges or
Invoices
I5 Audit IT Financial
Asset Information Financials Audit Reports
Asset Contracts and

Financial Data/D1 A816
Evaluate
I7
Service Metric Data Financial Financial
and Reports Management Management
Evaluation
Performance
Financial Management A817
Activity Data
NODE: A81 TITLE:

Financial Management CURRENT PAGE:
Figure 2. A81 Financial Management
•
•
•
•
[A811] Establish Financial Management Framework

Description
To establish the framework necessary to perform Financial Management, the following activities
must be addressed:
A financial management strategy has to be defined, balancing the goals and the effort
expended for Financial Management
The scope of Financial Management has to be defined including a detailed life cycle for the
process, taking legal requirements and audit guidelines into account
Financial Management has to be integrated into the balanced scorecard (or similar
performance management) method of IT evaluation
Measurements have to be defined that characterize how Financial Management helps to
improve the overall performance of IT
Documented and published review procedures must be accessible for all financial
management practices
The appointment of a process owner and other defined roles for process management
should be addressed
All individual frameworks for budgeting, IT accounting, and chargeback or service pricing
have to be integrated
Finally, the structure and process of Financial Management have to be communicated effectively
to all participants and stakeholders.
The establishment of the Financial Management Framework also includes the continuous
improvement of financial management. That is, the analysis of the Financial Management process
evaluations and the implementation of recommended improvement actions.
Controls
Business Strategy
policies.
included.
Management)
•
•
•
•
Inputs
Business Accounting Framework
Details of the business-wide financial framework, including the required interfaces with the
IT Financial Framework.
compliance
Financial Management Evaluation (From: A817)
A report describing the performance against the process quality measures, legal
requirements, and fraud detection.
Outputs
Financial Management Framework (To: A812 A813 A814 A815 A816 A817 A831)
The overall strategy and definition for financial management, such as the procedural,
organizational and other management mechanisms through which the process will
operate. Includes:
• Strategic goals for the management of IT finances
• Policies and orientation that apply to operating the various aspects of IT finances
• Collection of evaluation criteria for qualifying and assessing the financial aspects of any
investment under consideration
[A812] Perform Financial Modeling

Description
This activity carries out financial modeling in order to determine the likely financial outcomes for a
wide range of propositions under consideration. These propositions can be limited to the
management of IT finances or be linked to proposals relating to the reach and range of support for
the business, infrastructure developments, service variations or any other consideration for which
the costs and benefits need to be represented in financial terms. Many requests will require
innovation in the modeling approaches employed, in order to satisfy requests which differ in some
way from requests previously considered.
The book ITIL Service Strategy, describes some general types of modeling that could be
performed,6 including:
Service Valuation – to identify the funding needed for a particular service, both the cost to
the service provider and a view of the value added, in order to arrive at an overall cost to
the customer that satisfies both provider and customer
6. See ITIL V3 Service Strategy sections 5.1 and 5.2

•
•
•
•
Demand Modeling – to quantify the financial variations associated with demand

management proposals
Service Investment Analysis – to provide the financial analysis that will be needed as part
of any business case
Variable Cost Dynamics – to model and project the cost implications of different cost
strategies
Controls
Financial Management Framework (From: A811)
operate. Includes:
deliverables, prices, contact points, ordering and request Processes.” 7
Inputs
IT Financial Modeling Request (From: A226 A255 A264 A352 A422 A823 A824)
individual asset.
Service Accounting Data (From: A814)
Information about the cost, ROI and value of IT services provided (or to be provided), used
in financial reporting and for the allocation of costs and charges.
Outputs
Financial Management Activity Data (To: A817)
Any data about the correct accomplishment and of process activities that support the
evaluation of the overall Financial Management process (includes data gathered for legal
reasons or for fraud detection).
7. ITIL V3 Glossary
•
•
•
•
IT Financial Modeling Analysis (To: A226 A255 A264 A352 A422 A813 A814 A815 A823
A824)
undertakings.
[A813] Plan and Control Budgets

Description
Budgeting ensures that predicted costs are matched by the budget, and that early warnings are
given where this is not the case. Budgeting enables an organization to:
Predict the money required to run IT services for a given period
Ensure that actual spend can be compared with predicted spend at any point
Reduce the risk of overspending
Ensure that revenues will be available to cover predicted spend (where charging is in place)
Plan and Control Budgets is split into an initial activity and a recurring, ongoing activity.
Initially you have to establish the budgeting framework. This framework will be the base to plan and
control the IT Budgets. This framework consists of three parts:
Information model
• Cost and IT entity alignment model
• General thresholds
• Plan of IT performance and capacity development
• Plan of IT costs and bills for individual user
Process and workflow
• Definition of the budgeting process (zero based budgeting)
• Definition of the periods to check the budget
• Definition of the escalation paths if a threshold is exceeded
Tools
• Data analysis tool
• Reporting tool
There are two ongoing activities that are entangled with each other. In the planning part you
analyze, together with representatives from the business, the future trends for business
development, processes and activities. You use this data as input to define the future IT budget,
breaking it down to single IT entities, and the budget planned for these entities (starting with
hardware, software, personnel, among others). To be able to control the budget, these entities
have to be connected with context information; that is, how many person hours are planned for a
certain project, and how much capacity is needed for a certain application. You will get this data
from the IT plan.
This budget planning has to be aligned with the overall budget planning process. After the budget
is defined, it has to be approved.
This activity is revisited in a defined period, to adjust the IT budget planning to the changing
business needs.
Using the actual cost data and performance data as gathered in Perform Financial Accounting, you
measure periodically whether the cost and delivered capacity and performance are in line with the
plan data. This information is compiled into reports and delivered to the sponsors of IT.
If these reports show deltas bigger than the defined thresholds, you have to take counteractions:
Discussion of the deltas and their reasons with the sponsor
•
•
•
•
Replanning of the budget needed for this entity

Re-approving the budget for this entity or stopping of this entity
Addressing and discussing the topic of changing bills for IT
This activity is revisited in a defined period to analyze plan versus reality and start adjustments
where necessary.
Controls
operate. Includes:
an SLA.” 8
Inputs
undertakings.
activities in IT.
business and IT) to develop or refine the product vision and product life cycle definition,
8. ITIL V3 Glossary
•
•
•
•
and plan for any project proposal not related to a specific product. The financial allotment
compensation.
Individual IT Process Activity Data (From every process)
All defined process based measures (usage data) aligned with services and activities from
which relevant financial values can be extracted or derived.
Budget Variance (From: A814)
Budget Variance defines the delta between the planned budget and planned results, and
the actual spent effort and achieved results.
Outputs
A844)
A661 A816 A82 A822 A824 A825)
[A814] Perform Financial Accounting

Description
Financial Accounting accounts (tracks and records) for all costs incurred. It enables the attribution
of costs to customer service provided. It should aid investment, renewal decisions, and identify
poor value for money, but without going into more detail than required. For example, charge a fixed
amount for an agreed capacity. Identifies cost of changes, and performs ROI and cost-benefit
analysis.
Financial Accounting enables an organization to:
Account for the money spent in providing IT services
Calculate the cost of providing IT services to both internal and external customers
Perform cost-benefit or return-on-investment analyses
The goal of financial accounting is to understand:
What drives the IT costs
Whether IT delivers a good value for money
You have to start to analyze to what extent you want to analyze these topics and from which kind
of analysis your IT performance would improve most. That is, IT cost transparency, understanding
of cost driver, understanding IT process cost, understanding of linkage of business performance
and IT cost drivers, understanding service costs, and understanding platform costs.
•
•
•
•
Initially, you have to establish the financial accounting framework. Therefore, you identify and set
the scope of financial accounting and the accounting policy. Here you define:
Reports and structure needed to reach these goals
Business and IT events driving the IT costs
This is the base for the Financial Accounting Framework. This framework consists of different
parts:
Information model:
• Cost model – per cost unit, per system, per service, among others
• Cost drivers – from performance data
• Value model – service model and IT scorecard
Process and workflow as described later:
Tools: Focus of the tools is to gather the information from different sources and compile
reports automatically from this data, helping to answer the IT goals. The tools needed
come from these families:
• Data mining tools
• Data gathering tools fueled by the performance data
• Reporting tools provides the performance data
Requirements for the Financial Accounting Framework will also be derived from Service Pricing
and Contract Administration, as the pricing framework has to be represented in the accounting
framework, and also from the overall financial management strategy.
After the framework has been implemented, Financial Accounting is an ongoing activity. On a
regular basis:
Cost data has to be gathered
Performance data (like operational monitor data and labor data) have to be imported
The data has to be calculated, analyzed, and linked according to the information model
Reports on IT Performance (cost versus value) for the different stakeholders have to be
generated
Trends have to be identified and analyzed
Actual financial data are reported to perform budgeting
Besides these cost and value analysis related activities, Financial Accounting includes some
additional tasks:
Collect, check, and pay bills to the suppliers
Create financial reports, especially to serve legal requirements and requirements of
corporate finance, such as depreciation of assets
Support the investment appraisal process from a financial point of view
Controls
operate. Includes:
•
•
•
•
an SLA.” 9
contracts (UCs).
9. ITIL V3 Glossary
•
•
•
•
Inputs
undertakings.
Customer Payment
Customer payment describes the incoming cash flow (real or virtual) from a customer. It is
either the information about a customer payment (from the business' accounts receivable
process) or could be the actual payment.
Supplier Invoices
compensation.
individual asset.
Customer Charges or Invoices (From: A81 A815)
Outputs
A661 A816 A82 A822 A824 A825)
Supplier Payments (To: A816)
Service Accounting Data (To: A812 A815 A816)
•
•
•
•
Budget Variance (To: A813)

Budget Variance defines the delta between the planned budget and planned results, and
the actual spent effort and achieved results.
[A815] Administer Charging

Description
The main goal of this activity is to charge customers in order to recover the cost of the IT services
or perhaps to generate a profit from the services offered. The chargeback strategy is dependent
on the business and IT models. The strategic goals can vary between refinancing IT investments,
using chargeback to optimize the IT cost and value relationship from a business point of view, and
in generating profit from IT. In comparison to Perform IT Accounting where the cost structures were
the primary focus, and to the process Service Pricing and Contract Administration where defining
the price for the services is the primary focus, this activity focuses on billing the customers of IT
services delivered and receiving payment.Charging recovers in a fair way the cost of the IT
services and influences customer behavior where necessary.
Administer Charging is split into an initial activity to set up the chargeback framework and a
recurring activity to actually bill the clients and receive the money.
Initially, a chargeback framework has to be defined. For example:
Information model:
• The pricing strategy is an input from Service Pricing and Contract Administration
• The pricing model is an input from Service Pricing and Contract Administration
• User to IT client linkage (to align the bill for an individual user to the organization unit that
has to pay the bill)
Process:
• Definition of the charging and compensation process. Legal requirements to the process
and the bill and the way the bill is composed will differ due to organization form of the IT
shop and the company. For example, IT as internal department, IT as an own
organization, or IT services different legal organizations in different countries.
Tool:
• A chargeback tool gathers the usage data aligned to a user, links it to the prices for the
services, and calculates the bill for a user
After the framework is established, bills for the user have to be generated periodically. These bills
are based on the pricing model. The pricing model describes what data to measure to compile the
usage information of a service.
The first step is to gather the performance data that is linked to the customer. This is an input from
the Perform Accounting operating processes. Using the pricing model, a price for the complete IT
usage of a specific client is calculated.
This data has to be aggregated to the level of detail that is delivered to the costumer organization,
such as per cost unit or per department. Prior to delivery, the bill has to be checked for correctness.
After the bill has been delivered and depending on the chargeback and compensation process,
correct payment has to be checked.
If the bill differs from the customer's expectation, an exception process is needed:
To check the correctness of the bill
To correct the bill, if necessary
If correct and exceeding the expectation, to trigger exploration of the impact on the planned
IT budget
•
•
•
•
Controls
operate. Includes:
contracts (UCs).
Inputs

•
•
•
•

undertakings.
compensation.
individual asset.
Outputs
A661 A816 A82 A822 A824 A825)
Cost Data (To: A816 A83 A832)
and by cost unit.
Customer Charges or Invoices (To: A814 A816)
[A816] Audit Financials

Description
Examination of financial data (under defined criteria and guidelines) and the workings of the
financial management process is performed for the purpose of confirming conformance to
standards and practices. Additionally identifies irregularities and improvement opportunities. ITIL
defines an audit as “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.”16

•
•
•
•
Controls
operate. Includes:
Inputs
Supplier Payments (From: A81 A814)
Cost Data (From: A81 A815)
and by cost unit.
Customer Charges or Invoices (From: A81 A815)
Outputs
IT Financial Audit Reports (To: A143 A811 A817)
•
•
•
•
[A817] Evaluate Financial Management Performance

Description
This governance activity includes the evaluation of the performance of the Financial Management
process, and aims at identifying improvement areas of the overall process. For example, the
foundation and interfaces of the process, all activities and their accomplishment, the adaptability
of the process, as well as the roles and responsibilities, including the respective skills.
In addition, the Financial Management process is to be evaluated against the goals and measures
to understand its influence on overall IT improvements.
Due to the importance of correct financial data, there are additional process evaluations that have
to be performed. One example is:
The process has to be evaluated against legal requirements, from a process and process
output point of view; that is, the correctness of financial statements. In some industries and
countries, fraud detection is a mandatory part of the evaluation. It might be necessary, due
to legal requirements, for this evaluation be carried out by an independent third party.
Controls
operate. Includes:
Inputs
Financial Management Activity Data (From: A812 A813 A814 A815 A816)
Outputs
Financial Management Evaluation (To: A811)
A report describing the performance against the process quality measures, legal
requirements, and fraud detection.
•
•
•
•
Purpose
The purpose of the Supplier Management process is to manage interactions with suppliers and
partners formally by selecting them based on their ability to meet identified requirements, and
managing performance against the agreed commitments.
Outcomes
Attitudes and behaviors are promoted that encourage mutual success
Procurement and delivery of products and services are optimized for maximum value
across supplier relationships
Obligations are met as efficiently and effectively as possible by both parties in the
relationship
Optimal value is achieved for costs in maintaining supplier relationships
Scope
Involves all aspects of managing relationships with suppliers and outsourcers and of the
procurement of assets and services. Addresses the complete supplier and procurement life cycle
from strategic considerations to tactical considerations, and to operational considerations.
Includes
Agreement on joint architecture and risk controls
Negotiation and enforcement of contracts
Supplier evaluation, selection, and relationship management
Supplier performance review, including:
– Benchmarking
– Terms and conditions conformance
Procurement (placing the order), both against established contracts and for off-the-
shelf items
Internal and external suppliers
Formalizing the operational level agreement (OLA) items, where they are to be fulfilled
by an external supplier, within an underpinning contract (UC)
Excludes
– Establishing the substance of OLA items which relate to a supplier
– OLA and UC service monitoring
•
•
•
•
Physical logistics (Facilities Management)

– Product and services requirements and specifications (from Solution Design, for
example)
Controls
included.
Business Strategy
policies.
Management)
Inputs
contracts (UCs).
•
•
•
•
Supplier Invoices
Items_ Procured
Items received from a supplier in response to a formal purchase order.
Information From Suppliers
Any information that the suppliers can provide about themselves that supports the
selection and evaluation process for suppliers, including:
• Responses to RFIs, RFPs
• Vendor briefings
• Financial information
• Portfolio information
Outputs
Request to Supplier for Information
Any request for information from suppliers that directly goes to the suppliers, including:
• Portfolio information (which items can be supplied)
• RFIs
• RFPs
Contract Requirements
Contract requirements for communication to, and negotiation with, suppliers. The
requirements cover items such as specifications, quantities, delivery dates, desired terms
and conditions, maximum price.

•
•
•
•
Purchase Orders (To: A825)

Order for products or services to a supplier resulting from procurement requests, including
detailed information about the order. Also covers the negative case (if an item has to be
returned to the supplier).
A81 A813 A814 A824 A825 A826)
an SLA.” 20
Asset (To: A552)
Management process.
Purchase Order Status (To: A81 A814 A824)
Activities

•
•
•
•
Business IT Strategy IT Budget IT Management Regulations and IT Financial
Security Policy
Strategy IT Sourcing C3 C2 Ecosystem Standards/D2 Reports
C4
C6 Strategy C5 C7 C1
Supplier Management
Framework
Establish
I3 Supplier
Business and
IT Models
Management
Framework
I2 A821 O1
IT Portfolio Request to
Supplier
Portfolio Supplier for Information
Manage
I6 O2
Information From
Portfolio of
Contract
Suppliers Suppliers Requirements
Information A822 IT Financial Modeling
About Suppliers Request/S6
Manage
Request for
Product or Service
Supplier
O4
Contracts Underpinning
Contract A823 Contracts
O5
I1 Exceptions
Asset
SLAs OLAs UCs
Manage
I5 Procurement
Items_ O6
Purchase Purchase Order Status
Procured
Order
Status A824
IT Financial
Procurement O3
Modeling Analysis/D6
Exceptions Purchase
Asset Replenishment
Orders
Request/D1
Evaluate Supplier Performance
I4 Supplier Evaluation
Supplier
Invoices Performance
Supplier Performance A825
Asset Contracts and
Issue
Financial Data/D2 Supplier Product
Provide
and Service
Supplier Supplier Information
Performance Data Product and
Request for Service
Supply Capability
Information Unavailable Product Information
A826
and Service Exceptions
Evaluate
Supplier
Supplier Management
Supplier Management Performance Evaluation
Activity Data A827
NODE: A82 TITLE:

Supplier Management CURRENT PAGE:
Figure 3. A82 Supplier Management
[A821] Establish Supplier Management Framework

Description
Based on the business and IT strategy and model, guidelines and a framework for Supplier
Management have to be developed. The tasks in this activity include:
Understanding the sourcing strategy and legal and self-imposed regulations with regard to
suppliers
Defining the strategy for supplier relationships: should they be long-term or will the
business rely on ad hoc supplier selection
Defining evaluation criteria for suppliers, supplier relationships and performance
Defining and implementing practices and systems that support supplier management,
including procurement and the maintenance of respective catalogs
Finally, the structure and process of the supplier management including procurement have to be
communicated to the process users.
The establishment of the Supplier Management Framework also includes the continuous
improvement of supplier management. For example, the consideration of the Supplier
Management process evaluation and the implementation of recommended improvement actions.
•
•
•
•
Controls
Business Strategy
policies.
IT Sourcing Strategy
Strategic guidelines about what services or business components are core (in-sourced or
out-sourced) as far as this can influence the selection of suppliers for products and
services.
Management)
Inputs
Supplier Management Performance Evaluation (From: A827)
The result of the evaluation of the Supplier Management process, including identification of
potential process improvement items.
Outputs
Supplier Management Framework (To: A751 A822 A823 A824 A825 A826 A827)
systems.
•
•
•
•
[A822] Manage Portfolio of Suppliers

Description
This activity consists of the following tasks:
Understand service or product requirements as a prerequisite for selecting the appropriate
suppliers
Search for appropriate suppliers
Evaluate supplier candidates according to predefined criteria
Select and prioritize suppliers
Maintain supplier catalog with supplier information
Manage (actively) the supplier portfolio by regularly revisiting supplier portfolio, maintaining
and optimizing it according to the required services and products, as well as the supplier
relationship management framework
Manage supplier relationships to ensure optimal procurement ability
Controls
systems.
Inputs
Information About Suppliers
Any information about potential suppliers that supports the selection and evaluation
process for suppliers, including:
•
•
•
•
• Analyst reports and opinions

• Benchmark data
• Customer references
• Current relationship information
• Other publicly available information
Request for Product or Service (From: A432 A442)
actual procurement.
Unavailable Product and Service Exceptions (From: A826)
Information about exceptions (unavailability, permanent or temporary) of supply items that
can influence procurement or require that the portfolio of suppliers is adapted.
Supplier Performance Evaluation (From: A825)
Evaluation of suppliers with regard to the relationship, compliance with agreed contract
conditions including costs. Input for management of portfolio of suppliers.
Supplier Performance Issue (From: A825)
Exceptions or non-compliance of suppliers with regard to the agreed contracts that are
recognized during Evaluate Supplier Performance, and that are needed as input for
Manage Portfolio of Suppliers so that the supplier portfolio can be adapted if necessary.
Contract Exceptions (From: A823)
Exceptions or non-compliance of contracts that are recognized during Manage Supplier
Contracts, and that are needed as input for Manage Portfolio of Suppliers, so that the
supplier portfolio can be adapted if necessary.
Outputs
Request to Supplier for Information
Any request for information from suppliers that directly goes to the suppliers, including:
• Portfolio information (which items can be supplied)
• RFIs
• RFPs
Supplier Portfolio (To: A823 A824 A826)
List of potential suppliers. Includes information about each supplier (relationship) with
regard to supply items, existing contracts, and the interfaces to this supplier.
Supplier Management Activity Data (To: A827)
overall Supplier Management process.
•
•
•
•
[A823] Manage Supplier Contracts

Description
Supplier contract management is about:
Defining scope of supplier relationship
Negotiating contracts
Creating contracts
Administering contracts
Regularly optimizing supplier contract terms and conditions
Continuously auditing contract compliance
Controls
systems.
Management)
Inputs
Supplier Portfolio (From: A822)
actual procurement.
•
•
•
•

contracts (UCs).
undertakings.
Supplier Performance Issue (From: A825)
Procurement Exceptions (From: A824)
Exceptions during procurement (item no longer available from supplier) that can influence
the management of supplier contracts.
Outputs
Contract Requirements
Contract requirements for communication to, and negotiation with, suppliers. The
requirements cover items such as specifications, quantities, delivery dates, desired terms
and conditions, maximum price.
A81 A813 A814 A824 A825 A826)

•
•
•
•
an SLA.” 24
Contract Exceptions (To: A822)
Exceptions or non-compliance of contracts that are recognized during Manage Supplier
Contracts, and that are needed as input for Manage Portfolio of Suppliers, so that the
supplier portfolio can be adapted if necessary.
[A824] Manage Procurement

Description
Procurement is about placing orders for items that have been requested and authorized. Includes
hardware, software, services, external resources. The activities are:
Receiving procurement requests
Review procurement requests, and approve or reject them
Initiate procurement by selecting the appropriate supplier and placing the order
Tracking orders until delivery of ordered items
Receiving procured items upon delivery by suppliers
Maintaining valid information about the procured items received
Handling escalations if necessary (during the entire procurement process until the
potentially necessary return of ordered items)
Controls
an SLA.” 25
systems.

•
•
•
•

Management)
• Prices
• Service levels
Inputs
actual procurement.
Items_ Procured
Items received from a supplier in response to a formal purchase order.
undertakings.
Asset Replenishment Request (From: A552 A554)
Supplier Invoices
Unavailable Product and Service Exceptions (From: A826)
Supplier Performance Evaluation (From: A825)
Outputs
•
•
•
•
Asset (To: A552)

Management process.
Purchase Order Status (To: A81 A814 A824)
Purchase Orders (To: A825)
Procurement Exceptions (To: A823)
Exceptions during procurement (item no longer available from supplier) that can influence
the management of supplier contracts.
[A825] Evaluate Supplier Performance

Description
In order to be able to manage the supplier portfolio successfully, a regular evaluation of the supplier
performance has to take place. It will examine:
Information from and about the suppliers
Information about the compliance and service level attainment of suppliers according to the
agreed contracts
Information about how well procurement works with the suppliers
Based on this information the suppliers will be reviewed, the relationship to the suppliers will be
evaluated and the compliance of suppliers with agreed contract terms and conditions as well as
the agreed costs will be analyzed.
This performance assessment will result in recommendations by evaluating value and risks of the
suppliers for the business.
Controls
Purchase Orders (From: A82 A824)
an SLA.” 26
•
•
•
•

systems.
Inputs
Information About Suppliers
Any information about potential suppliers that supports the selection and evaluation
process for suppliers, including:
• Analyst reports and opinions
• Benchmark data
• Customer references
• Current relationship information
• Other publicly available information
Supplier Performance Data
Data from any IT process that relates to the performance of any supplied product or service
that contributes to that process
Outputs
Supplier Performance Evaluation (To: A822 A824)
Supplier Performance Issue (To: A822 A823)

•
•
•
•
[A826] Provide Supplier Product and Service Information

Description
This activity is about providing information about supply items, like establishing and maintaining a
supply item catalog (hardware, software, services, external resources) that contains information
about:
Supply items themselves
Potential suppliers for these items including supplier priorities and options
Supply item availability
This is a prerequisite for being able to handle procurement.
Controls
systems.
Inputs
an SLA.” 27
Request for Supply Capability Information
Request for information from any process within IT about the IT Service Provider's
arrangements and capability to obtain supply items.
Outputs
Supplier Product and Service Information (To: A662 A664 A735 A736 A824)
portfolio, like the catalog of orderable supply items, including:
• Prices
• Service levels

•
•
•
•

Unavailable Product and Service Exceptions (To: A822 A824)
[A827] Evaluate Supplier Management Performance

Description
The evaluation of the performance of the Supplier Management process aims at identifying areas
of the overall process that require improvement. For example, the foundation and interfaces of the
process, all activities, their accomplishment, their degree of automation, as well as the roles and
responsibilities including the respective skills. Target for evaluations are also the portfolio of
suppliers and supply items.
Controls
systems.
Inputs
Supplier Management Activity Data (From: A822 A823 A824 A825 A826)
Outputs
Supplier Management Performance Evaluation (To: A821)
The result of the evaluation of the Supplier Management process, including identification of
potential process improvement items.
•
•
•
•
Purpose
The purpose of the Service Pricing and Contract Administration process is to establish a pricing
mechanism for the IT entity to sell its services to internal or external customers, and to administer
the contracts associated with selling those services.
Outcomes
Prices are set that reflect the charging policies of the IT organization
Pricing is aligned to achieve business objectives
Requests for pricing are satisfied in a responsive manner
Customer contracts and agreements are administered effectively and efficiently
Scope
This process applies if the decision is made to charge for IT services. It encompasses defining a
pricing method, establishing prices, managing the resulting contracts, tracking the effect of pricing
on how well the service or solution is being accepted by the customer, and examining proposals
and contract continuation.
Includes
Defining the charging pricing algorithm
Providing standard prices for IT services
Providing pricing alternatives (such as fixed, time and materials, and flexible terms
and conditions)
Monitoring impact on user and customer behavior and making appropriate
adjustments
Excludes
Metering (Service Execution, Data Management)
Billing (Financial Management)
Initiating pricing negotiations (Service Marketing and Sales)
Controls
included.
•
•
•
•

contracts (UCs).
Inputs
and by cost unit.

•
•
•
•
Outputs
Service Pricing and Contract Information (To: A22 A226 A227 A24 A243 A365 A81 A813
A814 A815)
Activities
A834 Administer Customer Contract/ Agreement

•
•
•
•
IT Strategy IT Management IT Portfolio Service SLAs OLAs UCs

C1 Ecosystem C2 Catalog C4
C3 C5
Financial Establish Service Pricing and

Management Service Contract Administration
Framework/D1 Pricing and Framework
Contract
I1 Administration Pricing
Cost Data Framework Algorithm
A831 Pricing
Elements Pricing
Collect Data
Pricing Data
I3
Service Metric Data
and Reports A832 Service Price Model
Projected
Solution Cost
Provide O1
Costing and
Charging Request
Price Service Pricing and
Alternatives Contract Information
I2 Billing
A833
Service Level Package Options Proposed Customer
Contract Terms
Administer
Services Customer
Proposal/D1 Contract/
Services Service
Agreement/D1 Agreement Contract Terms
A834
Monitor
Marketing and Pricing
Sales Reports/D2 Effects
Pricing A835
Analysis
Evaluate
Service Service Pricing
Pricing and and Contract
Administration
Contract Evaluation
Service Pricing and Administration
Contract Administration A836
Activity Data
NODE: A83 TITLE:

Service Pricing and Contract Administration CURRENT PAGE:
Figure 4. A83 Service Pricing and Contract Administration
[A831] Establish Service Pricing and Contract Administration

Framework
Description
To establish the framework necessary to perform Service Pricing and Contract Administration, the
following activities must be addressed:
A service pricing and contract administration strategy has to be defined and be based on IT
strategy, the business, and IT models. It should reflect whether (and how) user behavior
and IT consumption should be influenced, and whether chargeback should be used as a
tool to communicate the value of IT. The pricing strategy should also integrate how
benchmarks with the market should be integrated.
It has to be determined whether prices are set by forecasting, simulation, or other methods.
Measurements have to be defined, to understand whether Service Pricing and Contract
Administration help to improve the overall performance of IT.
There must be documented and published review procedures for all service pricing and
contract administration documentation.
The appointments of a process owner and other defined roles have to be addressed.
An organizational entity has to be established to regularly revisit the negotiated contracts.
Finally, the structure and process of Service Pricing and Contract Administration have to be
communicated.
•
•
•
•
The establishment of the Service Pricing and Contract Administration Framework also includes the
continuous improvement of Service Pricing and Contract Administration. This means consideration
of the Service Pricing and Contract Administration process evaluation, and the implementation of
recommended improvement actions.
As billing is described in Administer Charging from Financial Management, it is very strongly
related to Service Pricing and Contract Administration. Service Pricing and Contract Administration
have to be carried out in order that the chargeback framework can be established in Financial
Management.
Controls
included.
Inputs
operate. Includes:
Service Pricing and Contract Administration Evaluation (From: A836)
Is a report combining how the process performance can be improved and how especially
the pricing model can optimize the overall IT usage.

•
•
•
•
Pricing Analysis (From: A835)

A summary of the effects and implications of current and proposed algorithms, price points
and service contract terms, used to provide feedback on pricing practices.
Outputs
Service Pricing and Contract Administration Framework (To: A832 A833 A834 A835 A836)
Describes the foundational framework for Service Pricing and Contract Administration,
including descriptions of the following aspects of the process:
• Strategic (vision, mission, value proposition)
• Organizational (organizational mechanisms, roles, accountabilities)
• Process (activities, workflows, inputs, outputs)
• Technology (software, hardware) practices for managing customer transformation
Pricing Algorithm (To: A833)
The formulas used to work with service pricing data to derive pricing alternatives for further
evaluation.
Pricing Elements (To: A832)
The objects, factors and practices to be considered in developing service prices and
contract terms.
[A832] Collect Pricing Data

Description
Based on chargeback strategy and the Service Catalog, the data sources to establish the pricing
have to be identified and assessed for completeness. Once the services with service classes and
levels are defined, all services measures have to be defined to measure the usage. This activity
includes gathering resource usage data from system logs and automatically or manually inputting
occasional charges for education or recurring charges for workstation rentals.
Controls
Pricing Elements (From: A831)
The objects, factors and practices to be considered in developing service prices and
contract terms.
Service Pricing and Contract Administration Framework (From: A831)
Inputs
and by cost unit.
•
•
•
•
Projected Solution Cost
Part of Solution Plans and Commitments, it provides anticipated costs of solutions before
any actual cost data is available.
Outputs
Pricing Data (To: A833)
The pricing data consist of all measures needed to measure the service usage. This is
input to the price model.
Service Pricing and Contract Administration Activity Data (To: A836)
Focuses on data needed to analyze how to improve the process performance.
[A833] Provide Price Alternatives

Description
This activity creates one or more service price models for the service proposition under
consideration. One important input is the chargeback strategy as defined in the framework. From
the goals you can derive how price and cost are related in the service price model. A main activity
here is to define the rule set by which the prices shall be calculated, and then apply this rule set to
perform the pricing.
Because the price model is an important regulator of the usage of IT, the IT strategy should have
an influence on setting the price. IT can be run as a cost center, distributing budgeted costs
equitably among customers, or as a profit center, focusing on prices, revenue, and profit. One price
list can be used for all customers or different price lists can be used for different customers, for
different levels of usage, or usage at different times. The prices can represent the cost for a
service, the value of a service, or can be strategic regulators. The costs per service are input from
the Perform IT Accounting activity in the Financial Management process.
Controls
Pricing Algorithm (From: A831)
The formulas used to work with service pricing data to derive pricing alternatives for further
evaluation.
•
•
•
•
Inputs
Pricing Data (From: A832)
The pricing data consist of all measures needed to measure the service usage. This is
input to the price model.
Costing and Charging Request (From: A744)
An inquiry about (or an estimate of) the cost or charge related to a particular IT service or
cluster of services.
Pricing Analysis (From: A835)
Outputs
Service Price Model (To: A255)
The service price model describes all inputs needed (for example, service model,
measures, service levels, customer) to derive a price for a delivered service. It is often
presented as a multidimensional matrix, with one dimension for each input. It describes as
output one price for each combination.
Billing Options (To: A834)
Describes different Service Price Models and how to choose between them.
[A834] Administer Customer Contract/ Agreement

Description
To administer contracts and agreements ensures that terms and conditions are respected by both
parties. Monitors ensure that data is current and accurate.
Initially, contracts and agreements are negotiated on the service level agreements that were
negotiated in the Create and Maintain Service Level Agreements activity of the process Service
Level Management. The SLAs are completed by adding a price per service and defining how the
price related service usage indicators are defined. For each indicator, process and tools to
measure the indicator have to be agreed to.
After these contracts and agreements have been established, they are revisited periodically to
ensure both parties still agree on the goals that led to these contracts (and the underlying pricing
model), or adapt the contracts to a new situation.

•
•
•
•
Controls
Billing Options (From: A833)
Describes different Service Price Models and how to choose between them.
contracts (UCs).
• ITIL definition of these terms:

•
•
•
•
Inputs
Services Proposal (From: A22 A226)
Outputs
Proposed Customer Contract Terms
Includes the agreed service level objectives, the corresponding service price model for one
customer, the customer specific additional terms and conditions (contract period) and,
often, planned usage data.
Service Contract Terms (To: A835)
Include the agreed service price model for one customer, and the specific additional terms
and conditions (contract period).

•
•
•
•
[A835] Monitor Pricing Effects
[A835] Monitor Pricing Effects

Description
This activity applies to revenue-flow and profit-and-loss analysis simulations, and to detailed
reports on service use by customers based on the various pricing alternatives offered. Here you
analyze whether a certain price model really changes the behavior of the users. This kind of an
analysis helps you to understand whether you match the goals set in the chargeback strategy, and
if the selected pricing model has the desired influence on the users’ behavior. To understand
whether the pricing leads to optimal IT costs, benchmarking with market data can be an additional
input.
Controls
Service Contract Terms (From: A834)
Include the agreed service price model for one customer, and the specific additional terms
and conditions (contract period).
Inputs
Reports which indicate the outcomes of marketing and sales efforts and which compare
the current sales and marketing execution to the market plan.
Outputs
Pricing Analysis (To: A831 A833)
•
•
•
•
[A836] Evaluate Service Pricing and Contract Administration Performance
[A836] Evaluate Service Pricing and Contract Administration

Performance
Description
This governance activity includes the evaluation of the performance of the Service Pricing and
Contract Administration process, and aims at identifying the improvement areas of the overall
process. For example, the foundation and interfaces of the process, all activities and their
accomplishment, the adaptability of the process, as well as the roles and responsibilities including
the respective skills.
In addition, the Service Pricing and Contract Administration process is to be evaluated against the
goals and measures to understand its influence on user behavior and on overall IT improvements.
Controls
Inputs
Service Pricing and Contract Administration Activity Data (From: A832 A833 A834 A835)
Outputs
Service Pricing and Contract Administration Evaluation (To: A831)
Is a report combining how the process performance can be improved and how especially
the pricing model can optimize the overall IT usage.
•
•
•
•
Purpose
The purpose of the Workforce Management process is to provide the optimal mix of staffing
(resources and skills) in order to deliver the agreed IT services at the negotiated service levels and
commitments.
Outcomes
An appropriately skilled and motivated workforce is attracted and retained
Staffing and skills meet needs of the business, including required technical and business
skills, both on a day-to-day basis and over time
Compliance with all workforce-related legal and regulatory requirements and with
corporate practices is ensured
A succession strategy for leadership and critical skills is enabled
Workforce management information is provided to support informed decision making on
sourcing strategy
Scope
Any aspect of managing the human resources available and necessary for the IT endeavor to fulfill
its obligations, including workload, skills, and personnel.
Includes
Acquiring, hiring, retaining, developing, firing, retiring
Introducing and orienting new resources to the workplace
Skills management
Workforce management, including capacity planning and forecasts
Work and job design, including roles and responsibilities
Skills development and training
Performance evaluation
Employee communications
Workforce task management
The execution of corporate human resources (HR) activities in relation to the IT
workforce
Representing human resource issues relating to the IT workforce to corporate HR
•
•
•
•
Excludes
Establishing corporate HR policies and their deployment beyond IT
Setting overall budgets for workforce
Payroll and benefits administration
HR systems (part of Portfolio Management and Solution Development and
Deployment, in support of the business' HR processes)
Managing the workforce of service providers
Setting sourcing strategy
Controls
included.
contracts (UCs).

•
•
•
•
Business Strategy
policies.
Management)
Inputs
Outputs
Skills Plan (To: A371 A843 A85 A852)
procurement.
Advanced Practices (To: A85 A853)
The knowledge and behaviors of leading practitioners that sets a benchmark for others to
reach and emulate. The practices will contain subject-matter content, but will also cover
techniques for content application and for mentoring.
Workforce Management Information (To: A365 A373 A374 A81 A813 A814 A815)
compensation.

•
•
•
•
Activities
A844 Manage Skills
Business IT Management IT Strategy SLAs OLAs UCs Security IT Budget Architecture Baselines
Regulations and C1
Strategy Ecosystem Plan/D4 and Roadmaps
Standards/D2 C2 C4
C7 C5 C3 C6
Business Workforce
Policies and Practices
Legal and
Regulatory Requirements
Establish
Workforce Workforce
External Workforce Management Management Framework
Frameworks
and Practices Framework
A841 O3
Workforce
Plan Information
I1
Forecast
IT Plan and Plan
Workforce Workforce
Adjustment
A842 Requisition
Administer
Deployed
Human Resource Human Workforce
Adjustment Resources Skill
A843 Requirements
Training
Labor Requirements
Inventory
Information
Manage
Skills O1
Skills Plan
I3
IT Research A844
Guidance
O2
Advanced Practices
I2
Solution Design Evaluate
Skills
Inventory Workforce Workforce Management
I4
Knowledge Performance
Workforce Management A845
Assets
Activity Data
NODE: A84 TITLE:

Workforce Management CURRENT PAGE:
Figure 5. A84 Workforce Management
•
•
•
•
[A841] Establish Workforce Management Framework

Description
Based on the business, IT strategy, and the architectural models, guidelines and a framework for
capacity management have to be developed. The tasks in this activity include:
Understanding the requirements and specifications for workforce management
Defining the strategy for workforce management tools and capabilities, and how they
vendor capabilities
Defining evaluation criteria for workforce management solutions and services
Establishing the framework for workforce management by defining and implementing
Finally, the structure and process of Workforce Management, including escalation responsibilities,
Workflows Management; that is, the consideration of the Workforce Management process
evaluation and the implementation of recommended improvement actions.
Controls
Legal and Regulatory Requirements
Requirements from governmental and other regulatory bodies to be applied to the
employment aspects of any business. An example would be Health and Safety legislation.
Business Workforce Policies and Practices
The workforce management policies and practices of the parent business.
included.
•
•
•
•
Inputs
External Workforce Frameworks and Practices
Relevant models, designs and operational characteristics of workforce management
approaches in peer businesses which could provide a basis for this IT Service Provider's
Workforce Management Framework.
Workforce Management Evaluation (From: A845)
Outputs
Workforce Management Framework (To: A842 A843 A844 A845)
[A842] Forecast and Plan Workforce

organizational (organizational mechanisms, roles, accountabilities), process (activities, work flows,
inputs, outputs), and technology (software, hardware) practices for managing customer
satisfaction.
Description
Create a workforce forecast plan based on the IT portfolio requirements of the business and the
current resource pool. Translate the workload associated with business requirements into skills
and time. Map the skills and time requirements to the available resource pool, and reconcile gaps
in the workforce plan.
Controls
Workforce Management Framework (From: A841)
included.
contracts (UCs).
•
•
•
•
Inputs
Labor Inventory Information (From: A843)
Repository for human resource allocations.
Outputs
compensation.
Skill Requirements (To: A844)
Forecast of human skills required to meet the demand for services in the IT Portfolio.
Workforce Plan (To: A843)
Forecast of human workload associated with business requirements or changes, and the
subsequent plan for IT resources in support of the demand.
Workforce Management Activity Data (To: A845)
The metrics defined in the Workforce Management Framework and populated by all work
performed within the process, as the basis to evaluate performance of the process.

•
•
•
•
[A843] Administer Human Resources

Description
Maintain staffing levels based on workforce plan (for example, hiring, promoting, demoting,
dismissing, assigning) to ensure a pool of personnel with the required skills. Perform performance
planning, evaluation, and compensation activities. Manage morale by assessing, understanding,
and improving the factors that influence morale and increase productivity.
Controls
procurement.
Inputs
Workforce Plan (From: A842)
Forecast of human workload associated with business requirements or changes, and the
subsequent plan for IT resources in support of the demand.
Human Resource Adjustment
The flow of acquired, realigned, and released human resources which represents the
workforce available for deployment.
Outputs
compensation.
Workforce Adjustment Requisition
The plans and requirements for adjustments (increase and decrease) in workforce
numbers and job profiles. Might be relevant to either or both of the business' workforce
management process and to the procurement process.
Deployed Workforce
Current IT human resource allocations.
•
•
•
•
Skill Requirements (To: A844)

Training Requirements (To: A844)
Statement of the purpose, timing and quantities of training needed to properly equip the
workforce for their current and future work assignments.
Labor Inventory Information (To: A842 A844)
[A844] Manage Skills

Description
Assess the type, level and quantity of skills necessary for the IT service provider to meet its
commitments. Identify skill increase (and decrease) actions so that the skills inventory will meet
the requirements. Define employee development and training needs in support of the workforce
plan and each employee's career aspirations. Oversee the fulfillment of skill programs.
Controls
Inputs
Skill Requirements (From: A842 A843)
Training Requirements (From: A843)
Statement of the purpose, timing and quantities of training needed to properly equip the
workforce for their current and future work assignments.
Labor Inventory Information (From: A843)
•
•
•
•

Outputs
compensation.
Skills Plan (To: A371 A843 A85 A852)
procurement.
Advanced Practices (To: A85 A853)
Skills Inventory (To: A621 A622 A842 A843)
•
•
•
•
[A845] Evaluate Workforce Management Performance

Description
Performance evaluation of Workforce Management process aims at identifying areas of the overall
process that require improvement. For example, the foundation and interfaces of the process, all
responsibilities including the respective skills. The bases for the improvements are the insights and
the lessons learned from the observations, and analysis of activity accomplishments and results.
Controls
Inputs
Workforce Management Activity Data (From: A842 A843 A844)
Outputs
Workforce Management Evaluation (To: A841)
•
•
•
•
Purpose
The purpose of the Knowledge Management process is to focus on capturing and exploiting the
information and knowledge needed by personnel to work effectively.
Definition of Knowledge Management: “The Process responsible for gathering, analysing, storing
and sharing knowledge and information within an Organisation. The primary purpose of
Knowledge Management is to improve Efficiency by reducing the need to rediscover
knowledge”.47
Outcomes
Organizational and individual knowledge and skills are improved
All areas of IT are assisted in providing optimized IT end-to-end business services
Technologies are leveraged for capture, location, and dissemination of knowledge and
expertise
Communities of practice are able to optimize the use of organizational knowledge
Innovation is promoted and enabled
Scope
The process emphasizes controlled but efficient access to assets across the organization,
ensuring consistency and reuse as appropriate to take advantage of best practices and enable
innovation.
Includes
Management of IT knowledge and directly related business knowledge, including:
– The full range of knowledge from technical to services
– Knowledge gained from external sources as well as from internal activities
– Interfaces to support any other IT process such as Incident Management
– Life cycle management of knowledge, from development through retirement
– Content management for knowledge data across all media and access
mechanisms in which it resides
Working with other IT processes so that the relevant knowledge in their data and
information repositories is made available and is actively managed
Linkage to business-side Knowledge Management (if a program exists)
Coordination with skills building and learning activities
Knowledge linkage with service providers and suppliers
Knowledge linkage with customers
Intellectual property management, such as patents and external publications

•
•
•
•
Excludes
Understanding and acting on the knowledge (outcome management is the
responsibility of all other IT processes)
Establishing and operating the data and information repositories associated with
individual IT processes; for example, the Configuration Management database
General Knowledge Management for the business
Content management for business Web-based data (responsibility of the business,
with support from Data Management)
Controls
Business Strategy
policies.
included.
Inputs
procurement.
Advanced Practices (From: A84 A844)
•
•
•
•
Knowledge_ Internal and External

All available internal and external formal or informal knowledge that might be relevant for
the business.
Knowledge Request
A request by a user for a knowledge asset to be available to them.
Outputs
Knowledge Assets (To: A265 A613 A652 A653 A654 A84 A844)
Activities
Business IT Management IT Strategy Technology IT Portfolio Architecture Baselines Security Policy
Strategy Ecosystem C3 Capabilities and Roadmaps C1
C4
C2 and Trends/D1 C5
C6
C7
Knowledge Establish
Management Knowledge
Methods and
Knowledge Management Framework
Techniques Management
Framework Infrastructure
A851
Knowledge
Plan
I1 Create and
Skills Plan Maintain
Knowledge Sources
Knowledge
and Categories Plan
I3
A852
Knowledge_ Knowledge_
Internal and Knowledge Items Unstructured
External Acquire Knowledge
Knowledge Acquisition Requests
I2
Advanced Practices Knowledge_
A853 Appraised and
Structured
Evaluate and Knowledge Submission

Response
Structure
Knowledge
A854
Knowledge
Gaps Disseminate O1
Knowledge Knowledge
Assets
I4 Operational
Documentation
Knowledge A855
Request
Monitor,
Knowledge Knowledge
Request Queue Assess and
Reports
Report
Knowledge Knowledge
Management Status
Feedback A856
Evaluate
Knowledge Knowledge
Evaluation
Performance
Knowledge
A857
Management
Activity Data
NODE: A85 TITLE:

Knowledge Management CURRENT PAGE:
Figure 6. A85 Knowledge Management
•
•
•
•
[A851] Establish Knowledge Management Framework

Description
This activity consists of three main tasks that establish the base for Knowledge Management in the
business:
1. Definition of Knowledge Management strategy has to be determined:
• What the strategic goals are for Knowledge Management

• What the strategic value of Knowledge Management is to the business
• How the value can be measured
• What knowledge is relevant for the business and necessary to stay competitive and
ahead of competition
• What knowledge sources are relevant (suppliers, partners, customers, internal
processes, among others)
• How to handle formal and informal knowledge
•
How to maintain a vital Knowledge Management in the business (motivation to
participate, avoidance of bureaucracy, avoidance of low value knowledge)
2. Planning and implementation of Knowledge Management:
•
Based on the Knowledge Management strategy a Knowledge Management Framework
has to be planned, designed and implemented, meaning the supporting technology has
to be defined and installed. This includes that rules and policies are implemented to
protect the knowledge of the business through management of access and security
3. Creation and maintenance of Knowledge Management capabilities. This includes:
• Continuous research and evaluation of Knowledge Management technology

• Ongoing access control for Knowledge Management system
• Establishment of knowledge domains and supporting organizational or informal
structures
• Provision of an effective and efficient structure to capture and store knowledge
• Definition of evaluation criteria for knowledge
• Establishment of knowledge sharing culture
• Management of intellectual property
Based on the outcome of these tasks, skill requirements for the staff have to be defined and, if
necessary, training requirements have to be determined.
Finally, the structure, process, and technology for Knowledge Management have to be
communicated to the process users.
The planning and implementation of the Knowledge Management Framework also includes the
continuous improvement of Knowledge Management. For example, the consideration of the
Knowledge Management process evaluation and the implementation of recommended
Controls
Business Strategy
policies.
•
•
•
•

included.
Inputs
Knowledge Management Methods and Techniques
Available (best practice) methods and techniques for knowledge management (processes,
structures) as an input when creating the Knowledge Management Framework.
Knowledge Management Evaluation (From: A857)
The result of the evaluation of the Knowledge Management process.
Outputs
Knowledge Management Framework (To: A852 A853 A854 A855 A856 A857)
The framework that contains all relevant information about the structure of the Knowledge
Management process (the strategic goals for knowledge management, the definition of
relevant knowledge, and knowledge sources)
Knowledge Management Infrastructure (To: A853 A854 A855 A856 A857)
Includes technology and organization (communities) to support the operation on this
process, and to enable all other processes to exploit this capability, such as:
• Technology specifications and implementations for knowledge management
• Organizational structures necessary for carrying out the knowledge management
process (both administrative structures as well as active participants in knowledge
management, like communities).
[A852] Create and Maintain Knowledge Plan

Description
This activity is responsible for determining the knowledge content needed to support the
undertaking of IT, and creating a plan to ensure that the right knowledge can be available when
needed by any aspect of the IT undertaking.
It will create the plan by understanding:
The direction that IT is taking – in both a technical and a customer positioning sense
General trends in knowledge aspects of the IT industry and of the industry of the parent
business
The specific skill areas that are being developed, and for which suitable knowledge will be
needed
The current strengths and weaknesses (gaps) in the available knowledge
The outcome of this will be used by the operational activities within the Knowledge Management
process to guide the acquisition and dissemination of knowledge.
•
•
•
•
Controls
Knowledge Management Framework (From: A851)
included.
Inputs
procurement.
Knowledge Sources and Categories
The meta-data aspects of the internal and external knowledge, such as:
• Potential knowledge sources
• Potential structure for knowledge
Knowledge Reports (From: A856)
Reports indicating the status and key performance indicators for the knowledge being
managed. They include identification of:
• Patterns and trends of usage
• Corresponding topics or items that could require additional or reduced focus in the
Knowledge Management Plan
Knowledge Request Queue (From: A855)
The entirety of knowledge requests that are as yet unsatisfied (because of time or
knowledge gaps).
Knowledge Gaps (From: A854)
Any gaps in relevant knowledge that have been identified.
•
•
•
•
Outputs
Knowledge Plan (To: A853 A854 A855 A856)
Indicates the subject areas in which knowledge is required, and the type of knowledge
items in those subjects. This includes guidance on knowledge subjects which are now
stabilized, and those which are becoming less important.
Knowledge Management Activity Data (To: A857)
overall Knowledge Management process.
[A853] Acquire Knowledge

Description
The acquisition of knowledge contains the development, capturing, and harvesting of
(unstructured) knowledge. This includes both formal and documented, informal and tacit
knowledge, and the acquisition of knowledge from all sources determined in the Knowledge
Management strategy.
Important for this activity are the identified gaps in knowledge and the analysis of queued
knowledge requests so that knowledge can systematically be captured according to the gaps and
requests.
Controls
Knowledge Plan (From: A852)
Knowledge Management Infrastructure (From: A851)
Inputs
Knowledge Items
Any item or unit of information that feeds into knowledge management, that is included in
any knowledge management repository and which belongs to one of the pre-defined
relevant knowledge areas.
Advanced Practices (From: A84 A844)
•
•
•
•
Outputs
Knowledge Acquisition Requests (To: A856)
An identification of a specific requirement to obtain a body of knowledge so that it is
available for any IT process activity.
Knowledge_ Unstructured (To: A854)
Knowledge that has been acquired but not yet has been evaluated and structured. Can be
documented or tacit knowledge.
[A854] Evaluate and Structure Knowledge

Description
This activity contains tasks to convert the unstructured knowledge into structured knowledge:
Valuing knowledge with regard to predefined evaluation and quality criteria (for example, to
indicate the degree of conformance with established standards)
Where the valuation indicates a knowledge item which has intrinsic value, activities relating
to intellectual capital protection (such as patent submission) will be triggered
Verifying and testing knowledge
Structuring knowledge to aid subsequent matching knowledge to search requests
Approving or rejecting knowledge for inclusion in knowledge assets
Making the knowledge available in the selected level of knowledge assets, and updating
any relevant search indexes
Confirming the knowledge submission outcome to the submitter
Additionally to maintain and enhance the knowledge base of the business, this activity also
addresses requirements to keep it current:
Regularly reviewing the knowledge base
Updating, archiving, or deleting knowledge
Identifying and communicating gaps and new knowledge areas
Controls
•
•
•
•
Inputs
Knowledge_ Unstructured (From: A853)
Knowledge that has been acquired but not yet has been evaluated and structured. Can be
documented or tacit knowledge.
Knowledge Request Queue (From: A855)
knowledge gaps).
Outputs
Knowledge Submission Response
Response to the evaluation of knowledge, such as approval, rejection, rework, and others.
Knowledge_ Appraised and Structured (To: A855 A856)
Knowledge that has been assessed according to predefined evaluation and quality criteria
(checking for relevance, testing, scrutinizing)
Knowledge that has been structured so that it can be published in any knowledge
management repository or otherwise made available to satisfy knowledge requests.
Knowledge Gaps (To: A852 A853 A856)
[A855] Disseminate Knowledge

Description
Covers the delivery of knowledge to users. It can include both proactively and reactively supplying
knowledge, for example:
Delivery of knowledge by publishing knowledge based on a certain schedule (proactive
mode)
Delivery of knowledge based on individual or group requests (reactive mode)
Controls
•
•
•
•
Inputs
Knowledge_ Appraised and Structured (From: A854)
Knowledge Request
A request by a user for a knowledge asset to be available to them.
Outputs
Knowledge Assets (To: A265 A613 A652 A653 A654 A84 A844)
Operational Documentation (To: A45 A454 A523 A613 A621 A651 A654 A655 A664 A723
A736 A764 A765 A766)
output.
Knowledge Request Queue (To: A852 A854)
knowledge gaps).
[A856] Monitor, Assess and Report Knowledge Status

Description
This activity monitors the usage, currency, completeness, and user satisfaction with the knowledge
managed by this process. It assesses the status of these characteristics against the Knowledge
Management Plan, and identifies patterns and trends of knowledge usage and requests, including
topics for which requests are satisfied only partially or not at all. It makes these assessments
available using reports, both regular and ad hoc.
Controls
•
•
•
•

Inputs
Knowledge Acquisition Requests (From: A853)
An identification of a specific requirement to obtain a body of knowledge so that it is
available for any IT process activity.
Knowledge_ Appraised and Structured (From: A854)
Knowledge Management Feedback
Feedback from any user of knowledge (the processes and the content) as to the
usefulness, completeness, accuracy or any other relevant aspect.
Outputs
Knowledge Reports (To: A852 A857)
[A857] Evaluate Knowledge Management Performance

Description
In order to control both the Knowledge Management process as well as the sharing and reuse of
knowledge in the business, this activity evaluates according to the measurements defined in the
Establish Knowledge Management Framework activity:
Review the effectiveness of the Knowledge Management process activities (acquiring,
evaluating, supplying knowledge)
Assess the effectiveness of Knowledge Management in the business by analyzing
knowledge sharing and submission, knowledge delivery, and knowledge usage by
establishing tracking and reporting mechanisms
The review and assessment results will be used to document the overall knowledge management
performance and to suggest improvement actions for the Knowledge Management processes, and
for the Knowledge Management Framework itself.
•
•
•
•
Controls
Inputs
Knowledge Reports (From: A856)
Knowledge Management Activity Data (From: A852 A853 A854 A855 A856)
Outputs
Knowledge Management Evaluation (To: A851)
The result of the evaluation of the Knowledge Management process.
•
•
•
•
PRM-IT A8 Node Tree
PRM-IT A8 Node Tree
A8 – ADMINISTRATION
A834 Administer Customer Contract Agreement
A844 Manage Skills
Figure 7. A8 Administration Node Tree
•
•
•
•
IDEFØ Node Tree

A11 IT Governance and Management System Framework A51 Change Management
A12 IT Governance and Management System Capabilities A52 Release Management
A13 IT Governance and Management System Operation A53 Deployment Management
A14 IT Governance and Management System Evaluation A54 Configuration Management
A–6 Operations
A24 Service Level Management A63 Data Management
A25 Demand Management A64 Event Management
A26 IT Customer Transformation Management A65 Incident Management
A27 Customer Satisfaction Management A66 Problem Management
A67 Identify and Access Management
A–3 Direction
A–7 Resilience
A31 IT Strategy
A34 Risk Management
A–4 Realization
A44 Solution Test
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • N-1
•
•
A0 – Manage IT
A0 – Manage IT
A3 Direction
A4 Realization
A5 Transition
A6 Operations
A7 Resilience
A8 Administration
•
•
N-2 • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
A1 – Governance and Management System
A1 – Governance and Management System
A1 – GOVERNANCE AND MANAGEMENT SYSTEM
Communicate IT Governance and Management System

A144
Performance
•
•
•
•
A2 – Customer Relationships
A213 Transform Needs Into Stakeholder Requirements
•
•
•
•
•
•
•
•
A3 – IT Direction
A3 – IT Direction
A3 – IT DIRECTION
A31 IT Strategy
A321 Establish IT Research and Innovating Framework
Qualify Candidates and Define IT Research and Innovation

A323
Projects
•
•
•
•
A3 – IT Direction
A3 – IT DIRECTION
A34 Risk Management
A343 Assess Risk
A346 Assess Risk Mitigation Results
A354 Inititate and Oversee Product Realization
A361 Establish IT Portfolio Management Framework
A372 Manage Program
A374 Plan Project

•
•
•
•
A3 – IT Direction
A3 – IT DIRECTION
A377 Close Project
•
•
•
•
A4 – Realization
A4 – Realization
A4 – REALIZATION
A425 Validate Solution Design with Stakeholders
•
•
•
•
A4 – Realization
A4 – REALIZATION
A44 Solution Test
A443 Prepare and Mange Solution Test Environment
•
•
N - 10• IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
•
A5 – Transition
A5 – Transition
A5 – TRANSITION
A514 Assess Change
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) •N - 11
•
•
A5 – Transition
A5 – TRANSITION
•
•
•
•
A6 – Operations
A6 – Operations
A6 – OPERATIONS
A63 Data Management
A643 Filter Event
A645 Resolve Event
•
•
•
•
A6 – Operations
A6 – OPERATIONS
A646 Close Event
A656 Close Incident
A673 Creae and Maintain Identity
•
•
•
•
A7 – Resilience
A7 – Resilience
A7 – RESILIENCE
•
•
•
•
A7 – Resilience
A7 – RESILIENCE
A751 Establish Facility Management Framework
•
•
•
•
A8 – Administration
A834 Administer Customer Contract Agreement
A844 Manage Skills
•
•
•
•
•
•
•
•
IDEFØ Diagrams
IDEFØ Diagrams
A0: Manage IT – Context A45 Solution Acceptance
A0: Manage IT
A1 Governance and Management System A5 Transition
A11 IT Governance and Management System A51 Change Management
Framework A52 Release Management
A12 IT Governance and Management System A53 Deployment Management
Capabilities A54 Configuration Management
A13 IT Governance and Management System A55 Asset Management
Operation
A14 IT Governance and Management System A6 Operations
Evaluation A61 Request Fulfillment
A2 Customer Relationships A63 Data Management
A21 Stakeholder Requirements Management A64 Event Management
A22 Service Marketing and Sales A65 Incident Management
A23 Service Catalog Management A66 Problem Management
A24 Service Level Management A67 Identity and Access Management
A26 IT Customer Transformation A7 Resilience
Management A71 Compliance Management
A27 Customer Satisfaction Management A72 Security Management
A3 Direction A74 Capacity Management
A31 IT Strategy A75 Facilities Management
A32 IT Research and Innovation A76 IT Service Continuity Management
A34 Risk Management A8 Administration
A35 Product Management A81 Financial Management
A36 Portfolio Management A82 Supplier Management
A37 Program and Project Management A83 Service Pricing and Contract
Administration
A4 Realization A84 Workforce Management
A41 Solution Requirements A85 Knowledge Management
A44 Solution Test
•
•
©Copyright IBM Corp. 4/24/08IBM Process Reference Model for IT (PRM-IT Version 3.0) D - 1 •
•
•
IDEFØ Diagrams
A0: Manage IT – Context
A0: Manage IT – Context

Top
IT Function
Information
and Interests The
Business
External
Environment
Business
Input
Business Funding
Business
Environment Governance
Information
IT Governance
and Management
System Results IT Strategy
Manage IT
Business Output
Supplier Input
A0
Customer Output
Supplier
Output Customers
Suppliers
Customer Input
User Output
User
Input
Users
NODE: A-0 TITLE:

Manage IT - Context CURRENT PAGE:
•
•
•
©Copyright IBM Corp. 4/24/08 IBM Process Reference Model for IT (PRM-IT Version 3.0) • D-2
•
This material may not be reproduced in whole or in part without the prior written permission of IBM
IDEFØ Diagrams
A0: Manage IT
A0: Manage IT
Business Environment
Business Governance Information
Management C2 C1
System Business
Strategy
SLAs OLAs UCs

Governance Service
Catalog
and O2
System and Management
IT Management IT Research System Results
A1 Ecosystem Guidance
Service Level Package IT Business
Market Analysis IT Portfolio Contribution and
Capabilities
I5 Customer
Customer Input
Relationships
IT Plan
A2
Project Charter
Stakeholder O4
Requirements Direction Business Output
Business and
Project Proposal IT Models
A3
Project Plan O3
Solution Design IT Strategy

Product Package Architecture Baselines
and Roadmaps Solution_
Realization Accepted
I2
Business CI Requisition
Input
A4
Change Schedule O5
Solution Realization Solution Solution_ Customer Output
Results and Issues Plans and Change
Deployed Information
Commitments
Transition
CIs Configuration
Information
Operational
A5 Monitoring Data
Asset Deployment CI Data O6
Items and Data Update Package Identity and User Output
Access Rights
Register
Change Operations
Incident
Request
Compliance Plans
Service Metric Data
and Controls
I4 Incident and Reports
User A6 Information Security Policy
Input Service Request_ Asset Information
Authorized
O7
Supplier
Resilience Output
Problem
Information
Service Resilience
Plans
IT Budget
A7
Administration
I3 A8
Supplier Input Underpinning
Contracts
IT Financial
Reports
I1
Business Funding
NODE: A0 TITLE:
Manage IT CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams

Environment Business Business IT Strategy IT Budget

Regulations and Information Management Strategy C4
Standards C5
C3 System C2
External Models C1 External Benchmarks
and Practices O2
IT Management
I8 Ecosystem
Market Analysis
I2
Underpinning IT Governance
Contracts Framework
I4 IT Management
Compliance Plans System Framework
and Controls
IT Governance
IT Service Provider
and
Value Profile/D1 Management
System
FrameworkA11
IT Quality Management IT Governance

Framework Capabilities
IT Management
IT Governance System Capabilities
I7
and
and Roadmaps
Management
System
I5
IT Research
Capabilities
A12 IT Quality System
Guidance Capabilities
I6
IT Portfolio IT Measurements
Operational
Individual Process
Results and Reports
IT Governance
and IT Management
Program and System
Project Reports/D2
Service Achievement Operation A13
Reports/D4
IT Management System IT Quality System
I3 Reports Reports
IT Financial
Reports
IT Governance
Business Evaluation IT Control Results
and
Feedback
Management
I1 System
Business Evaluation A14
Input
Individual
Process
Evaluations O1
IT Governance IT Governance
IT Governance
Customer Satisfaction and Management and Management
System Evaluation and Management
Results and Trends/D1 Audit Results
System Results
NODE: A1 TITLE:
Governance and Management System CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Business Business Regulations and

IT Strategy
Strategy Management Business Standards
System Management C4 C1
C3
C2 Policies
Business
Governance
Capabilities
I10
Define IT
O1
and Management Framework IT Governance
Audit Results
A111 Framework
IT Quality
I1
Management
External Models O3
Business Goals
and Practices
Goals IT Quality Management
I4 Framework
Compliance Plans
and Controls Define IT
Management
I2
Market Analysis Goals
A112
IT Management
System Goals
I5
IT Quality
IT Service Provider
Management
Value Profile/D1
Policies
Business
Establish IT
Practices Policies
I8
IT Quality System A113 IT Management
Reports System Policies
IT Quality
Management
I9 Practices
IT Governance
and Management
System Evaluation Establish IT
Management
Practices
I3
Underpinning A114
Contracts
I7 IT Management
System Practices O2
IT Research IT Management
Guidance System Framework
I6
and Roadmaps
NODE: A11 TITLE:

IT Governance and Management System Framework CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Governance IT Quality Management IT Management IT Strategy IT Budget

Framework Framework System Framework
I6 C4 C5
C3 C1 C2
IT Governance
and Management
Audit Results
I5 Establish IT
O1
and Management Capabilities
System Evaluation IT Governance
A121 Capabilities
I2
Architecture Baselines O2
and Roadmaps IT Process IT Management
Establish Capabilities System Capabilities
I1
External Models
IT Process
and Practices Capabilities
A122
IT Organizational
Capabilities
Establish IT
Organizational
I3 Capabilities
IT Research
Guidance
A123 IT Management
Information
Capabilities
Establish IT
Management
Information
I7 Capabilities
IT Portfolio A124
IT Operational
Environment
Establish IT Capabilities
Operational
Environment
Capabilities
A125
IT Measurement
Establish IT and Control
Capabilities
Measurement
and Control
Capabilities O3
IT Quality System
I4 A126 Capabilities
IT Quality System
Reports
NODE: A12 TITLE:

IT Governance and Management System Capabilities CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Quality System IT Governance IT Portfolio IT Budget IT Management

Capabilities Capabilities IT Strategy
System Capabilities C1 C6 System Framework
C2 C4 C7
C3 C5
I1
Operational
I3
Service Achievement
Reports/D4
I2
Program and Produce IT
Project Reports/D2 Measurements O1
IT Measurements
I4
IT Financial
Reports A131
I5
IT Management
Control Items
Operate IT
Governance O2
and IT Management
System Controls
A132
O4
IT Control Results
Monitor,
Analyze and
Report IT O3
Outcomes
Reports
A133
NODE: A13 TITLE:

IT Governance and Management System Operation CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Quality System IT Governance IT Management IT Governance IT Budget IT Portfolio IT Strategy Business
System Capabilities Capabilities Capabilities System Framework Framework C1 Management
C7 C8
C3 C2 C4 C5 C6 System
C9
I2
Reports
I4
IT Financial
Reports Collate IT
I8
Management
Customer Satisfaction System
Results and Trends/D1 Outcomes
A141
I3
IT Control Results Collated IT
Management System
I7
Outcomes
Individual Analyze IT
Process Governance and
Evaluations
Management
I5
Service Achievement
System
Reports/D4 Performance
A142
IT Management and
I1 Governance System
External Benchmarks Performance Analysis
Audit IT
Governance
I6
Business Evaluation
and O3
Feedback and Management
A143 Audit Results
IT Governance and Management

Communicate IT
Audit Request Governance and O1
Management IT Quality System
Compliance Reports
Audit Reports/D1
System
O2
Performance IT Governance
IT Financial A144 and Management
Audit Reports/D1 System Evaluation
NODE: A14 TITLE:

IT Governance and Management System Evaluation CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
MODIFY DATE: 14/01/08 07:45 PM C C op yr igh t I B M C or p or at i on , 2 008, A l l R i gh ts R eser v ed
IT Management IT Strategy IT Portfolio Architecture Baselines Security Policy IT Plan IT Budget Business and Business
Ecosystem C5 C9 and Roadmaps C6 IT Models Strategy
C1 C8 C4 C7 C3
C2 Customer
Needs
I9
Plans
Project Proposal
I2 Stakeholder
Customer Input Requirements
and Intentions
Management Stakeholder
A21 Requirements
I5 Services
IT Research Services O9
Customer Agreement Proposal
Guidance Market Analysis
Organization
Service
Marketing and
Marketing Sales Reports
Sales Leads
and Sales
Service Pricing Customer Inputs to A22 IT Industry
and Contract Sales Transactions Customer Knowledge
Information/D1 Profiles Service Level
Service Catalog Communication
Usage Data Service
I10 Catalog O5
Change Service Review Change
Information Management Results Request
O4
I7 Consolidated Business Service
Incident A23 Business Demand
Information Customer Review Demand Baselines Catalog
Value Classification and Forecasts
I12 Input
Product Package Service O3
Level SLAs OLAs UCs
I6 Management O2
Service Metric Data Business Output
and Reports Service Level A24 Business Demand
Reports/D1 Requirements Business Activity Patterns Optimization Service Level Package
and User Profiles Service Achievement Recommendations
I4 Business Demand Reports Demand O1
Underpinning Characteristics
Management Customer Output
Contracts
I8
Problem A25 Service Demand Forecasts
Information IT Customer Capability
Adoption Interventions
Market Data IT Customer IT Customer Capability
I1 Transformation Adoption Plan
Environment IT Customer Benefit
Management Realization Report
Information
A26 IT Customer
I11
Solution Transformation Themes
Business
Plans and and Evaluation Principles
Metrics IT Customer Capability Customer
Commitments Current Adoption Events Customer Customer Satisfaction
Satisfaction Customer
Business Climate Issue Communications
I3 Input Issue Feedback Satisfaction
O10
Business Management Incident
Input
A27
Customer
Satisfaction Customer Satisfaction
Issue Results and Trends
NODE: A2 TITLE:
Customer Relationships CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Market IT Portfolio Security Policy

IT Management IT Strategy
Analysis C4
Ecosystem C2 C3
C1 C5
Establish
Stakeholder
Requirements Stakeholder Requirements
Framework
A211 Stakeholder
Needs
I1
Customer
Needs Capture
Stakeholder
Needs
A212
Feasibility
I4
Request
IT Industry
Knowledge
Transform
Needs into O1
I3 Stakeholder Stakeholder
Service Requirements Requirements
Catalog A213
I2 Stakeholder Needs_
IT Research Disqualified Monitor and
Guidance Report Stakeholder Needs and
Requirements Report
Stakeholder
Feasibility Needs and
Guidance Requirements
A214
Stakeholder
Requirements Evaluate
Status Update Stakeholder Stakeholder
Evaluation
Stakeholder Requirements Performance
Management Activity Data A215
NODE: A21 TITLE:

Stakeholder Requirements Management CURRENT PAGE:
•
•
•
©Copyright IBM Corp. 4/24/08 IBM Process Reference Model for IT (PRM-IT Version 3.0) • D - 10
•
IDEFØ Diagrams
Service Resilience IT Portfolio IT Plan IT Strategy IT Budget Architecture Baselines SLAs OLAs UCs
IT Management Plans C4 C6 and Roadmaps
Ecosystem C3 C7 C8
C1 C5
C2
Prioritized Market
Establish Wants and Needs
I1
Service Service Marketing
Stakeholder
Requirements Marketing and Sales
I8 and Sales Framework
Market Data Framework
A221
Analyze O2
Market Market Analysis
I9
Wants Service
Service Market
Catalog and Needs Market Initiative
A222 Outcomes Proposal
Plan
Create O1
I4
Marketing Project Proposal
IT Research
Guidance Plan Customer Selling
I10 A223 Information Services
Customer Satisfaction Market Execute Marketing
Results and Trends Segmentation and Sales
Marketing Collateral
I2 Plan
Customer
Organization A224 Sales Plan
Manage
Opportunities IT Financial Modeling
I6
Sales Leads
and Forecast Request/S1
I5 SalesA225
and Intentions
Consult and
Services
Propose Proposal
I11 Services
Solutions Services
A226
Agreement
IT Financial Sales Negotiate
Opportunity
Modeling Analysis/D1 and Close O7
I3 Services IT Industry
Customer Inputs to Knowledge
Sales Transactions Opportunity
A227 Analyze
and Report
O6
Sales Marketing Customer
Outcomes and Sales Profiles
I7
Service Pricing
Results Evaluate
A228
and Contract Service
Information/D1 Marketing O3
Service Marketing and and Sales Marketing and
Sales Activity Data Sales Reports
Performance
A229
Service
Marketing
and Sales
Evaluation
NODE: A22 TITLE:
Service Marketing and Sales CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Strategy Market Analysis IT Portfolio IT Budget Change Management Marketing and
Ecosystem Framework/D3 Sales Reports
C4 C2 C5 C6
C3 C1
Establish
Catalog Management
I2
Customer Management Service Package Framework
Organization Framework Specific Catalog
A231 Requirements
Define
O1
Service
Change
Market Plan/D1 Package Request
Catalog
Requirements
Catalog Presentation A232
Service Catalog
I5 Requirements Build and Content
Product Package
I3
Service Description Maintain
Change Service
Information Catalog
Content Service Catalog
A233 Views
Create and
Maintain
I1
Services Service
Agreement Catalog Views
Target Market
Segment Requirements A234
Publish
I7 Service O2
Service Level Package Service
Catalog Catalog
A235
Monitor,
Analyze and Service Catalog
Reports
I4 Report
Service Catalog Service
Usage Data
Catalog
A236
Evaluate
Catalog Management
Service Catalog Management Performance
Activity Data A237
I6
Results and Trends
NODE: A23 TITLE:

Service Catalog Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
MODIFY DATE: 14/01/08 07:45 PM C C op yr igh t IB M C or p or at ion , 2008 , A l l R i gh ts Re serv ed
IT Management IT Strategy IT Portfolio IT Budget Business Security Policy
Ecosystem C3 C5 Strategy C4
C2
C1 C6
Establish
I11 Service Level
Underpinning Service Level
Contracts
I2 Framework
Customer A241
Organization Service Level
Stakeholder
I1 Register
Service Develop
O2
Catalog Service Service Level
I8 Level Communication
Product Package Relationships
I3 A242 Service Level
Service Pricing Feasibility Request
and Contract Create and
Information/D1
I6 Maintain
Service Level Service Level O1
Requirements SLAs OLAs UCs
Agreements
A243
Availability and
Recovery Design
Criteria/D1
Monitor and
Report O4
Service Level
Feasibility Response Service Level Service Achievement
Reports
I15 Achievements
Service Demand Forecasts O5
A244
I14 Customer
Service Level Package Satisfaction
I9
Conduct Issue
Service Metric Data Service
and Reports O3
Review Service Review
Service Request
Reports/D1 A245 Results
Projected Service Outage/D1
I10 Formulate
Service Resilience Service
Reports/D1 Service Improvement Plan
I4
Improvement
Service Resilience Plan
Plans A246
I13
Customer Satisfaction Evaluate
Results and Trends
I7 Service Level Service Level
Incident Management Management
Information Evaluation
I12 Service Level Performance
Information Activity Data
I5
Customer Review
Input
Service Provider
Review Input
NODE: A24 TITLE:
Service Level Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Portfolio Business Business and SLAs OLAs UCs Service IT Plan
Ecosystem C5 Strategy IT Models Catalog C3
C1
C4 C7 C6 C2
Establish
I3
Demand Demand Management
Market Analysis
I6 Framework
IT Research A251
Guidance
Value and
Classify O1
Business Demand
I8 Business Value Classification
Business
Business Demand Demands
A252 Demand
Characteristics
Baselines
I9 Consolidate
Business Business O2
Consolidated Business
Metrics Demand Demand Baselines
Patterns and and Forecasts
I10 Service
Forecasts Demand O6
A253 Service Demand Forecasts
Results and Trends Baselines
I7 Forecast O4
Business Project Proposal
Business Activity Patterns
and User Profiles
Demand Service
Forecasts Demand
Capacity Baselines IT Financial Modeling
and Profiles/D1 Request/S2
A254
I5 Service O3
Service Resilience Demand Identify and Business Demand
Plans Models Plan Optimization
Demand Recommendations
Service Price Model/D1
I4 Management
Marketing and O5
Sales Reports Initiatives Service Level Package
A255
I11 Assess and
Solution Demand Management
Plans and Report
Outcomes Report
Commitments Demand
I2 Management
Service Achievement Outcomes
Reports A256
IT Financial
Modeling Analysis/D2 Evaluate
Demand Demand
Service and Management Management
Evaluation
Resource Tuning Demand Management Performance
Directives/D1 Activity Data A257
Capacity Reports/D1
I1
Service Review
Results
NODE: A25 TITLE:

Demand Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Strategy IT Budget IT Portfolio Business IT Plan SLAs OLAs UCs
Ecosystem C3 C6 C4 Strategy C5 C1
C2 C7
I5
Market Data Establish IT
I3 Customer
Market Analysis Transformation IT Customer Transformation
Management
I1 Framework
Customer A261
Profiles IT Customer
Understand Context
IT Customer
Context IT Customer
Transformation
I11 A262 Candidates
Current
Business Climate
Identify IT O5
Customer IT Customer
I9 Transformation Transformation Themes
Customer Directions and Evaluation Principles
and Intentions Opportunities
A263
I8
IT Research Develop IT O6
I4 Guidance Customer Sales Leads
Stakeholder O1
Requirements
Transformation Project Proposal
Proposal
Project Plan/D1 A264 IT Financial Modeling
IT Financial Request/S3
Modeling Analysis/D3 Enable and
I12 O2
Solution Promote IT IT Customer Capability
Plans and Customer Adoption Interventions
Commitments Capability
I7 O3
IT Customer Capability IT Customer Capability
Adoption
A265 IT Customer Capability
Adoption Events Enabling Requirements Adoption Plan
Knowledge Assets/D3
I2 Optimize IT O4
Service Customer IT Customer Benefit
Catalog Benefit Realization Report
Realization
Proposed A266
I6 IT Customer Capability
Service Resilience Adoption Improvements Evaluate IT
Plans Customer IT Customer
Transformation Transformation
I10 Evaluation
Business IT Customer Transformation Performance
A267
Metrics Management Activity Data
NODE: A26 TITLE:

IT Customer Transformation Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Portfolio IT Management IT Strategy Service

SLAs OLAs UCs
Ecosystem Catalog
C5 C4 C1 C2
C3
I4
Customer
Organization
Establish
Customer Customer Satisfaction
Framework
I1 Satisfaction
Customer Management
Profiles Framework Customer
A271 Satisfaction
Data_
Customer Unsolicited
Satisfaction Capture
Targets Customer
I5
Customer
Satisfaction
Satisfaction DataA272 Customer
Input Satisfaction
Analysis
Customer Satisfaction Analyze O2
Data_ Solicited
I2 Customer Incident
Service Review Satisfaction
Results O1
A273
Product Performance Manage Issue Communications
Assessment/D1 Customer
I7 Customer Satisfaction
Customer
Satisfaction Issue Resolution
Satisfaction Issue Directives
Issue Resolution Customer
A274 Satisfaction
Assess Patterns
I6 Customer
Issue Feedback Patterns
Customer A275
Satisfaction Issue Communicate
Resolution Response
Customer O3
I3 Satisfaction Customer Satisfaction
Service Achievement Management Results and Trends
Reports ResultsA276
Marketing and
Sales Reports/D1
Evaluate
Customer Customer
Satisfaction Satisfaction
Management
Activity Data A277
NODE: A27 TITLE:

Customer Satisfaction Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A3 Direction
A3 Direction
Environment IT Management Underpinning Security Policy Market Analysis SLAs OLAs UCs Compliance Plans
Contracts IT Budget
Information Ecosystem C7 C2 and Controls
Technology C4 C6 C5 C1 IT Service Provider
C3 C8
Capabilities Value Profile
and Trends
I2 O1
Business IT Business
IT Capability IT Business Value Contribution and
Initiatives
Outlines Potential Capabilities
IT Strategy
O2
IT Strategy
A31 Industry Models

and Standards
Security IT Research
IT Research Viable
Plan/D2 Requests and Innovation
Innovation O8
I9 A32 IT Research
Solution_ Guidance
Deployed
I7
Service Resilience Architecture O7
Plans Management Business and
IT Models
I12
Solution Design
A33 Risk Assessment O10
and Mitigation Plans Architecture Baselines
I13 and Roadmaps
Solution IT Strategy Risk
Plans and O5
Architectural Implications Management Change
Commitments
Request
I10 Business
Configuration Risk Posture
Information A34 O11
Product Package
I11 Product
Project Proposal Management
I4 O3
Service Level Package IT Portfolio
A35 IT Business
Value Report
O6
Product Proposal
I8 Portfolio Project Charter
Change Management
Information
I6 O4
Program IT Plan
IT Financial A36
Reports Charter
Program Program
I1 Plan
Service Portfolio Decision and IT Portfolio
and Project
O9
Catalog Resource Allocation Performance Report Management Project Plan
I3
Stakeholder A37
Business
Requirements Project
I5 Management
Business Program and
Framework
Input Project Reports
NODE: A3 TITLE:
Direction CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A31 IT Strategy
A31 IT Strategy
IT Management Technology Underpinning IT Budget Security Policy

Market Analysis
Ecosystem Capabilities Contracts C6
C4 C5
C2 and Trends C3
C1
Establish IT
Process Process Framework
I1 Framework
Business A311 Business Strategic
Strategy Wants and Needs
O6
IT Research
Understand Requests
IT Customer Business
Transformation Themes O1
and Evaluation Principles/D1
Strategy IT Service Provider
A312 Business Aligned Value Profile
IT Goals O4
IT Business Value
Determine IT Potential
I8
IT Research
Strategic
Guidance Potential
O3
I6 A313 IT Capability
IT Strategy Outlines
Architectural Implications
Develop IT O5
I5 Strategy
Architecture Baselines IT Strategy
and Roadmaps Initiatives Initiatives
A314
I2
Strategic IT Value Consolidate
IT Portfolio
Propositions O2
and
IT Strategy
Communicate
I3 IT Strategy
A315
IT Plan IT Strategy
I7 Assessment
Viable Monitor and
Innovation Assess IT
Strategy
Effectiveness
A316
Evaluate IT
Process
Process Evaluation
I4 IT Strategy Process Performance
IT Portfolio Activity Data A317
Performance Report
NODE: A31 TITLE:

IT Strategy CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Budget Business IT Strategy IT Portfolio

Ecosystem C4 Strategy C1 C5
C3 C2
Establish IT
Research and IT Research and
Innovation Innovation Framework
Framework IT Research and
A321
Innovation Candidates
I2 Identify IT
IT Research Research and
Requests Innovation
IT Research
Candidates Project
A322 Charter
I3
Technology Request for
Capabilities Qualify IT Research
and Trends Candidates Capabilities
and Define IT
Research and
IT Research
I1 Innovation and Innovation
Business and ProjectsA323 Project Results
IT Models IT Research
Capabilities Perform IT Project Charter/S2
I4 Research and
Solution_ Innovation
Deployed
Project O2
A324
IT Research
Program and Guidance
Project Reports/D3
IT Research and
Rejected IT Research Promote IT
and Innovation Candidates Research and
Innovation Watch List
Innovation O1
Viable
Results Innovation
A325
Evaluate IT
Research and IT Research
Innovation and Innovation
Evaluation
IT Research and Innovation Performance
Activity Data A326
NODE: A32 TITLE:

IT Research and Innovation CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Budget IT Portfolio Industry Models Security Policy Security

Ecosystem C2 and Standards C5 Plan/D2
Security C6 C1
C4 C3
Management
Framework/D4
I1
IT Strategy
Establish
Architecture Architecture Management
I10 Framework
Business A331
Input
Review O5
Overall IT Research
I6 Environment Requests
Business
Strategy and Architecture
Architecture Need
A332
I2 Architecture_
IT Capability Current State
Outlines Create and
Maintain O4
I4 IT Strategy
IT Research Architecture Architectural Implications
Guidance Models A333 O1
I3
Business and
IT Strategy
Initiatives
Architecture_ Define and IT Models
Future Maintain O3
I5 Architecture Architecture Baselines
Technology
Baselines and and Roadmaps
Capabilities
and Trends Roadmaps
A334 Architecture
Transition
I11 Promote Initiatives
Project Charter Architecture O2
Project Proposal
Transition
Security Directives/D1 Initiatives
A335
Update Package/D1 Govern Configuration
Information Request/S2
Architecture
I7
Solution Design
Usage
A336 Architecture
Compliance Decision
I8 Architecture_
Solution Exception
Evaluate
Plans and Architecture Architecture
I9 Activity Data Performance
Configuration A337
Information
NODE: A33 TITLE:

Architecture Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A34 Risk Management
A34 Risk Management
IT Management Business Technology Security Policy Security
IT Strategy
Ecosystem Strategy Capabilities C3 Plan/D2
C2
C6 C4 and Trends C1
C5
Security Establish
Management Risk Risk Management
Framework/D1
I5
Framework
A341
Project Proposal
Identify
Threats, Identified Risks
Vulnerabilities
I2 and Risks
Business and A342 Risk Assessment
IT Models
Assess
I1 Risk
Market Analysis
A343
I4 O1
Risk Mitigation
Business Risk Assessment
Define Risk Plans Definition
Risk Posture and Mitigation Plans
Mitigation
I6 Plans and
Program
Plan
Counter-
measures
A344
Enact and
Risk Interventions
I7
Operate Risk and Indicators
Project Plan Counter-
measures
I3 A345
Solution Design
Assess and Risk Mitigation

Report Risk Assessment Reports
I8
Program and
Mitigation
Project Reports ResultsA346
Security Reports/D1
Individual Evaluate
Process
Evaluations/D1 Risk Risk
Evaluation
Risk Management Performance
Activity Data A347
NODE: A34 TITLE:

Risk Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Strategy Business and IT Budget SLAs OLAs UCs

Ecosystem C3 IT Models C5
C2
C4 C1
I11
Portfolio Decision and
Resource Allocation
I1
Market Analysis
I3 Establish
IT Strategy Product Product
Initiatives
I4 Management Management
Framework Framework
Viable
Innovation IT Financial Modeling
A351
Request/S4
I9
Service Formulate
Catalog Product O3
Product Proposal
I2 Concept Product Vision
Project Proposal
A352
I10
Stakeholder Plan and O2
Requirements Control Product Package
IT Financial Product Product Lifecycle
Modeling Analysis/D4 Definition and Plan
Lifecycle
A353
I6
Service Resilience
Product Lifecycle
Plans Initiate and
Milestone Achievement Portfolio Approval Request
Oversee
I5
Solution
Product
Plans and Realization
A354 Project Charter/S1
Commitments
Guide
Solution Realization Product
Results and Issues/D1 Product
Realization Status O1
I7 Transition
Service Level Package Change
and Request
I8 Operation
Change A355
Information
Product Introduction Monitor and
and Usage Status Assess
Service Review Results/D1 Product Performance
Product Assessment
Performance
A356
Results and Trends/D3 Evaluate
Product Product
Problem Management
Information/D1
Product Performance
A357
Management
Activity Data
NODE: A35 TITLE:

Product Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management Business Architecture Baselines Compliance Plans IT Strategy
Ecosystem Strategy and Roadmaps and Controls
C2
C4 C3 C1 C5
Establish
Portfolio Portfolio
Project Framework
Information
Framework
A361
I10
Service
Inventory IT Project
Proposal
Projects and and IT Portfolio
Catalog Additional
Service Categories
Services Inventory
Information
IT Customer IT Request
Transformation Themes A362 Portfolio
and Evaluation Principles/D2 Baseline
I6 Create and
IT Strategy Maintain IT
Initiatives O3
I5 Portfolio Program
Project Proposal Categories Charter
A363
Assess O4
I3 Project Charter
Product Proposal and Proposed
I8 IT Portfolio
Service Resilience Prioritize
Targets
Plans IT Portfolio O1
A364
IT Portfolio
I7 Make IT
Viable
Innovation Portfolio
I2 Decisions
Risk Assessment
and Mitigation Plans and O5
I11 Commitments IT Plan
Stakeholder IT Portfolio
Requirements A365
Review
I4 Conduct IT Results
Market Analysis
I1 Portfolio O7
IT Budget Portfolio Decision and
Review Resource Allocation
Communicate
A366 IT Business O2
Workforce IT Business
Management Value and IT Value Report
Information/D2 Portfolio
Service Pricing and O6
Contract Information/D2
Performance
A367 IT Portfolio
I12 Performance Report
Program and
Project Reports Evaluate
Service Achievement
Reports/D1
Portfolio Portfolio
I9 Evaluation
IT Financial Performance
Reports Portfolio Management A368
Activity Data
Business Metrics/D1
NODE: A36 TITLE:

Portfolio Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Strategy IT Management Compliance Plans Skills Plan/D1

C2 Ecosystem and Controls
C3 C1
I5
Business
Project Establish
Management
Framework
Program and Program
Project and Project
Management
I1
Framework
A371
Program Program
Charter Status
Report
Program Change Manage
Request Program
O1
Program
Project Plan
A372
Definition
I2
Define and
Project Charter Initiate
Project
A373
Workforce
Management Plan
Project O2
Information/D1
Project Project Project Plan
Status Tracking
A374 Report Report
Project
Change Request Track and Implementation
I3 Progress Data/S2
Risk Assessment Report
and Mitigation Plans Project
I4
Solution A375 Control
Plans and Project
Commitments
Project Directives
Project
Project Events Completion
Project Directive A376 Report
Outcomes
Close
Project O3
Program and
Change Project Reports
Implementation A377 Evaluate
Communication/D4 Program and Program
Project and
Project
Program and
Project Management A378
Activity Data
NODE: A37 TITLE:

Program and Project Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A4 Realization
A4 Realization
IT Management Architecture Baselines Security Policy Business IT Portfolio IT Strategy Security IT Plan SLAs OLAs UCs
Ecosystem and Roadmaps C8 Strategy C3 C4 Plan/D3 C2 C5
C6 C1 C7
I1
Project Charter Solution
Requirements
I3 Baseline
Project Plan
Solution
I4 Requirements O6
Stakeholder Solution
Requirements Plans and
A41 Solution Analysis and
Commitments
I6 Design Results
Compliance Plans Solution and Issues O7
and Controls Requirements Solution Realization
Results and Results and Issues
Issues Solution
I5 Analysis and
Service Level Package
Design O5
Solution Design Solution Solution Design
A42 Development
Request
I2 and Integration
Business and Results
IT Models Solution Design and Issues
I8 Package
Configuration Solution
Information
I9
Development O1
Asset Deployment and Change
Items and Data Integration Request
A43 Solution O3
Test CI Requisition
Results
I10 Solution O4
and Issues
CIs Assembly CI Data
Solution Update Package
Test
I7
Solution_ Solution
Deployed Test
A44 Report
Security Risk Solution Acceptance

Assessment/D1 Review Results
Solution and Issues
Acceptance
Operational O2
Documentation/D7 A45 Solution_
Accepted
I11
Solution Realization Project
Results and Issues Events/S1
NODE: A4 TITLE:
Realization CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Plan IT Strategy Business Architecture Baselines Security Policy SLAs OLAs UCs
Ecosystem C5 C6 Strategy and Roadmaps C3 C7
C1 C4 C2
Program and Solution

Project Management Requirements
Framework/D1 Framework
Change/D2 Establish
I1 Solution
Project Charter Business and IT Models
I2
Requirements Update Package
Project Plan Framework A411
I5
Service Level Package Refine and
Verify Rejected
I6 Business Stakeholder
Business and Solution Requirements
IT Models
Context Stakeholder
A412 Scope and
I3 Context Requirements
Stakeholder Proposed Information
Requirements Conditions Request
of Satisfaction Solution
Document and Requirements
I4
Analyze Stakeholder
Compliance Plans Solution Validation
and Controls Requirements Accepted Request
A413 Solution Conditions
Prototype of Satisfaction O3
Requirements_
Work Products Solution Solution
Validated
Requirements Validate Requirements
Results and
Solution Issues
Requirements
Stakeholder
with Solution
Validation Stakeholders Project
Response Plan O2
A414
Solution
Solution Plans and
Requirements Commitments
Solution Defect List Manage
Requirements Solution O1
Baseline Requirements Solution
Change
Request
Baseline Requirements
A415 Baseline
Change Proposal
I7
Results and Issues
Evaluate
Solution Solution
Evaluation
Solution Requirements Performance
Activity Data A416
NODE: A41 TITLE:

Solution Requirements CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Plan IT Strategy IT Portfolio Security Architecture Baselines
Ecosystem C5 C6 C4 Plan/D3 and Roadmaps
C1 C3 C2 Reusable Solution Analysis and
Components Design Framework
I5 IT Financial Modeling
Business and
IT Models Request/S5
IT Financial Establish
Modeling Analysis/D5 O2
Solution Change
Availability and
Recovery Design
Analysis and Request
Criteria/D2 Design Solution Design
I3 Framework Additional
Service Level Package A421 Information Request
Solution Design_ Information
Requirements Conceptual Request/S3
Baseline
Create
Conceptual
I1 Solution O5
Solution
Plans and Design Solution
Commitments A422 Plans and
Solution Commitments
I4 Component
Solution Design Specifications
Request
Identify and
I6 Select
Solution Realization Solution O1
Results and Issues Components Solution Analysis and
A423 Design Results
Configuration and Issues
Baseline O3
Report/D1 Create
CI Requisition
I7 Detailed
Configuration Solution O4
Information Design CI Data
A424 Update Package
Prototype
Work
O7
Products/D1 Validate Solution Design
I8 Solution Package
Security Risk Design O6
Solution Design
Assessment/D1 With
Stakeholders
A425 Solution Design
Solution Design Change Proposal Stakeholder
Solution
Acceptance
Design
Stakeholder
Evaluate Request
Acceptance Solution Solution Analysis
Response Analysis and Design
and Design Evaluation
Solution Analysis Performance
and Design A426
Activity Data
NODE: A42 TITLE:

Solution Analysis and Design CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management Architecture Baselines IT Strategy IT Plan
Ecosystem and Roadmaps C3 C4
C1 C2
Establish Solution Development

Solution and Integration Plan Solution Development
Development and Integration
I1
Solution
and Integration Framework
Framework Request O3
Plans and Solution Development Change
A431 for Product
Commitments and Integration Environment Request
or Service/S1
Define
Solution O1
I2 Solution
Solution Design Allocated Development Plans and
Package Asset Items/D1 and Integration
I3 Commitments
Asset Deployment Plan A432 Prepare O5
Items and Data CI Data
Solution
Update Package
I5 Development
Solution_ and Integration
Deployed
Environment
I6 A433 Solution
CIs Acquire or Asset Deployment
Components
Inquiries
Create O4
and Requisitions/S1
Solution CI Requisition
I4 Components O6
Solution Realization A434 Solution
Results and Issues Solution_
Assembly
Integrate Integrated
Solution
Components
A435
O2
Solution_ Solution
Refine Tuned Development
and Tune and Integration
Integrated Results
Solution Solution_ and Issues
A436 Verified
Verify
Integrated
Solution Solution
Solution Verification
Verification Request
A437
Results
Evaluate
Solution
Development
Solution Development and
and Integration
Integration Activity Data Performance
A438
Solution
Development
and Integration
Evaluation
NODE: A43 TITLE:
Solution Development and Integration CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A44 Solution Test
A44 Solution Test
IT Management IT Plan IT Strategy Security Architecture Baselines

Ecosystem C4 C3 Plan/D3 and Roadmaps
C1 C5 C2
I1
Solution Establish
Plans and Solution Test
Commitments Solution Test
Framework Request Framework
I3 A441 for Product O4
Solution Design or Service/S2 Change
Package Solution Request
Test Strategy
and Plans
Develop O5
Existing Solution Test Solution
Test Cases Strategy and Plans and
I7
Configuration Plans Test Commitments
Information Environment
A442 Specifications
Solution Solution Test Information Request/S4
Requirements Test Environment
Baseline Cases Prepare and
Manage Solution Test
Solution Test Environment Baseline O3
I5
CI Requisition
Solution_ Environment
Deployed A443
O2
Solution CI Data
I8 Update Package
Solution Realization Test
Results and Issues Results
Perform
Solution Test
I2 O1
Solution Solution
Solution
Assembly A444 Test
Test
Issues Results
and Issues
I4 Analyze and
CIs Report
Solution Test O6
Results Solution
Test
I9
A445 Report
Security Risk
Assessment/D1
Evaluate
Solution Test Solution
Test
A446
Solution Test
Activity Data
NODE: A44 TITLE:

Solution Test CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management Architecture Baselines IT Strategy IT Plan SLAs OLAs UCs
Ecosystem and Roadmaps C4 C5 C3
C1 C2
Establish
Solution
Solution Acceptance
Acceptance Framework
Framework
A451 Solution
Acceptance
Plan
I1
Create O2
Solution Solution Solution
Plans and Acceptance Plans and
Commitments Plan A452 Commitments
Solution
Acceptance
Criteria
Define
I5 Solution
Solution
Requirements Acceptance
Baseline Criteria
A453
I2
Solution
Test
Report Perform
Solution O1
Solution Acceptance
I4 Acceptance Review Results
Solution Design Review and Issues
A454
Certify Solution Acceptance

I8 Solution Certification
Results and Issues
Acceptance O3
A455 CI Data
Update Package
Package
I7 Certified
Operational O4
Documentation/D7 Solution Solution_
A456 Accepted
I6
Security Risk
Assessment/D1
Evaluate
Configuration
Audit Report/D3
Solution Solution
Acceptance Acceptance
Evaluation
I3
Solution Acceptance Performance
Activity Data A457
Solution
Assembly
NODE: A45 TITLE:

Solution Acceptance CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A5 Transition
A5 Transition
Service IT Strategy SLAs OLAs UCs IT Management Architecture Baselines IT Plan Compliance Plans IT Budget Environment
Catalog Ecosystem and Roadmaps Regulations
C3 C5 C2 and Controls C8 Information
C4 C6 C1 C9 and Standards/D3
C7
O7
Project Proposal
I12
Change
Request
Change O3
Management Change
I3 Information
Solution Design
A51 Change Implementation

Release Communication
I6 Acceptance
Product Package Release O1
Change Change Schedule
Strategy
Solution Design
Release Request/S1
I4
Management
Solution
Plans and A52 O2
Commitments Implementation
Release Solution_
Progress Data Deployed
Acceptance Release
I10
Request
Service Resilience
Plans
Release Notice Deployment O5
Management Incident
I1
Solution_
Accepted A53 Customer
Asset Deployment
Satisfaction Issue/S2
Operational Inquiries
Schedules/D2 and Requisitions O9
CIs
I5 Configuration
Project Plan Configuration
Management Baseline Report
I7 O4
CI Data Configuration
Update Package A54 Information
I2
CI Requisition O8
Asset Deployment
Configuration Items and Data
Information Asset
Request Management
I11
Service Request_ O6
Authorized A55 Asset Information
I8
Underpinning
Contracts
I9
IT Financial
Reports
NODE: A5 TITLE:
Transition CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT StrategyIT Management Compliance Plans Service Architecture Baselines Configuration

IT Plan SLAs OLAs UCs
C5 Ecosystem and Controls Catalog and Roadmaps Baseline Report
C2 C3
C6 C7 C1 C4 C8
Change Management
Framework
Establish
Change
Management Change
I1 Change Request_
Framework Request_ Rejected
Change A511 Create Recorded
Request
and Change Assessment
Record Information Request
Change_
Change Categorized
I3 Request O1
Project Plan A512 Project Proposal
I4 Accept Projected Service Outage
Solution Design
and
I6
Categorize O5
Configuration Change Schedule
Information Change
A513 Change_ O9
Assessed Change
Assess O8
Change Release
Change Assessment Acceptance
Information O4
A514
I2 Change Implementation
Asset Availability
Operational
Information/D1 Authorize Communication
Schedules/D2
and
I5 Schedule O3
Asset Deployment Change Asset Deployment
Items and Data A515
Asset Requisition Standard Inquiries
Status/D1 Change Coordinate and Requisitions
Change
O7
I8 Implement CI Data
Release ation
A516 Update Package
Acceptance Change_
Request Change_ Review Closed
Implemented and O6
Close Incident
I7 Change Asset Data
Implementation A517 Update Package/S2
Progress Data Monitor and
Report O2
Change Change
Change Status and Management Information
Information Request
A518 Evaluate
Change Change
Deployment
Reports/D2
Change Management Performance Evaluation
Service Request Activity Data A519
Reports/D1
NODE: A51 TITLE:

Change Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Compliance Plans IT Plan IT Management Service Architecture Baselines Configuration SLAs OLAs UCs Change Schedule
and Controls C6 Ecosystem Catalog and Roadmaps Baseline Report C4
C7 C2 C3 C5 C8 C1
Release
Management
Framework
I8
Project Plan
I12
Establish O2
Release Asset Deployment
Service Resilience
Inquiries
Plans Management and Requisitions
I4
Framework
A521 O7
Product Package Implementation
Progress Data
Plan
I3 Release
Change O4
Strategy Release
Strategy
I7 A522
Operational O1
Solution Design
Schedules/D2
Request/S1
I6 Design and
Solution Build
Plans and
Commitments
Release O3
CI Data
I5 A523 Update Package
Solution Design
O8
I10
Solution_ Release Release
Accepted _Built Test and Acceptance
Operational Verify Request
Documentation/D9 Release O6
Release
I11 A524
Configuration O5
Information Release Notice
I9 Release
Asset Deployment Revision Request Monitor and
Items and Data Report
I2 Release
Release Release Reports
Acceptance
A525
Deployment
Reports/D1
Review and
Close Release_
Closed
Release
Results and Trends/D2 A526
I1 Release Review Results Evaluate

Change Implementation Release Release
Communication Management Management
Evaluation
Release Management Performance
Activity Data A527
NODE: A52 TITLE:

Release Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Plan IT Management Compliance Plans IT Budget Release SLAs OLAs UCs Deployment
C3 Ecosystem and Controls C5 Strategy Management
C2 C6 C1 C4
Framework
I10 Deployment
Project Plan Program Plan
Establish
I1
Service Deployment
Catalog Management
I5 Framework O3
Change A531 Solution Design
Request/S1
Plan
O5
Deployment Asset Deployment
I6
Service Resilience
Program Inquiries
Plans and Requisitions
A532 Deployment
Capabilities
Prepare
I9 Deployment
Operational
Schedules/D2 Capabilities Deallocated Assets/S1
I7 A533
Solution_
Accepted Perform Asset Data
I3 Transition Update Package/S3
Release
I11 Notice
Asset Deployment
Administration Security Work Request/S1
Items and Data A534 Identity and Access
Work Request/S1
Perform
I12
Configuration
Deployment
O6
Information CI Data
A535 Update Package
I8 Deployment Verify O7
Service Request_ Solution_
Items Installed Deployment Implementation
Authorized
and Activate Progress Data
Service O1
A536 Solution_
Review Deployed
I4 and Close O2
Release Deployment Incident
Rework Need Deployment
O4
Security Response/D3 Customer
A537
Identity and Satisfaction Issue/S2
Monitor and Deployment
Access Response/D2
Report Reports
I2
Deployment
Change Implementation Deployment Program
Communication Records A538
Evaluate
Deployment
Management
Deployment Management
Activity Data
Performance
A539
Deployment
Management
Evaluation
NODE: A53 TITLE:
Deployment Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Service IT Management Architecture Baselines Change Schedule Compliance Plans
Catalog Ecosystem and Roadmaps and Controls
C1
C2 C4 C5 C3
Establish
Asset Management
Framework/D1 Configuration Configuration Management
I4 Management Framework
Solution Design Framework
A541
Solution
Assembly/D1
Identify O4
Configuration Change
I1 Items Request
Change
Information
Identified
A542 CIs
I5
CI Data
Update Package
Control O2
I3
Change Configuration Configuration
I6 Items Baseline Report
CI Requisition
I8
Asset Information
O1
A543 CIs
I2 CI
Change Implementation Information
Report
Communication O3
Configuration
I7 Configuration
Configuration Status Information
Information A544
Request
Verify and Configuration

Audit Audit Report
Configuration Configuration
Audit Request
Items
A545
Configuration Audit
Asset Action Request
Reconciliation Evaluate
Data/D1 Configuration Configuration
Evaluation
Configuration Management Performance
A546
Activity Data
NODE: A54 TITLE:

Configuration Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management Architecture Baselines IT Budget Regulations Compliance Plans
Ecosystem and Roadmaps C4 and Standards/D3 and Controls
C2 C3 C5 Asset Management
C1 Framework
Configuration
Management
Asset Asset Allocated
Framework/D1
Establish Availability Requisition Asset Items
Asset Information Status
I3 Management O1
Service Request_ Framework Asset Deployment
Authorized A551
Items and Data
Deallocated
Ready
Assets
and Asset Replenishment
Asset
Requisition
Control Request
Asset Asset Asset_
Asset/D1 A552 Retired
Distribution
Instruction Control
O2
I1 Asset Asset Asset Asset Information
Asset Deployment Availability Information Register
Inquiry Configuration
Inquiries
Audit Request/S1
and Requisitions A553
Monitor,
I2
Configuration
Audit and Asset
Reconcile Reconciliation
Information Asset
Data
Asset Data Operational Asset
Update Package Data Records
A554 Asset Audit
Configuration
Oversee Action Request
Audit Report/D1
Asset
I5 Contracts
IT Financial
Reports and Asset Contracts
Financials and Financial Data
Asset Information A555 Asset_
or Report Request
Retire
Disposed
and
Dispose
of Asset
Asset Retirement A556
and Disposal Data Asset Retirement
and Disposal Instructions Report
Asset
Asset Reports
Information
A557
Asset_ Reactivated
Evaluate
Asset
Management
I4 Asset Management Performance
Underpinning Activity Data A558
Contracts
Asset
Asset
Management
Licenses
Evaluation
NODE: A55 TITLE:
Asset Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A6 Operations
A6 Operations
IT Management SLAs OLAs UCs Service Compliance Plans Architecture Baselines IT Financial Security Policy
IT Plan Change Schedule
Ecosystem Catalog and Controls and Roadmaps Reports C8 Customer
C6 C4 C2
C5 C9 C3 C1
C7 Satisfaction
I7 Issue/S1
User O1
Input Service User Output
Service Request Request
Response
I2 Request
Change Fulfillment
Information O7
Service Request_
Work Authorized
Requests A61
Service Execution Operational Service
Work Requests_ Project Proposals
Work Metric Data and Reports
Completed
Data Input Service
I5 Execution
Solution
Plans and O4
Operational
Commitments
A62 Monitoring Data
IT Administration
I1 Data Lifecycle Support Data
Solution_ and Requests
Deployed
Request Data
Data_ Derived O3
Management Service Metric Data
I8
Service Resilience and Reports
Data
Plans A63 Management
Metric Data O9
Service and Reports Change
Resilience Data Event Request
Directives/D1
Security
Management O8
Monitoring Data/D1 CI Data
Update Package
A64

I6 Incident Directive
Incident Management
Incident_ Resolved
O5
A65 Incident
Information
Problem
Management
I3 O6
Configuration A66 Problem
Information Information
Identity and O2
Access Identity and
Management Access Rights
A67 Register
I4
Solution Design
Security Security
Identity and Access
Plan/D1 Directives/D2
Work Request
NODE: A6 TITLE:
Operations CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Plan Service SLAs OLAs UCs
Ecosystem C3 Catalog C2
C1 C4 Request Fulfillment
Framework
Change Management Establish

Framework/D2
I5 Request
Solution Design Fulfillment
Framework O2
A611
Service
I3 Request
Service Resilience Service Request_
Security Plan/D5 Response
Plans Rejected
I1
Receive and
Service Request Approve
I4
Configuration
Service
Information Request O5
A612 Service Request_
Incident
Fulfilled
Service Request_
Approved Fulfill or
Knowledge
Assets/D2 Route O4
Service Change
Request
Operational Request Service Request
A613 Routing Information
Documentation/D2
O3
Service Request Service Request_
Service Request_
Fulfillment Information Closed Authorized
I6 Close
Problem Service
Information Request
I2 O1
A614 Customer
Change
Information Satisfaction
Service Issue/S1
Own, Monitor, Request
Status
Track and Service
Communicate Request
I7
Service Reports
Incident Requests
A615
Information
Service Request
Customer Satisfaction Escalation
Issue Communications/D1
Evaluate
Request Request
Service Request
Fulfillment
Status Input Fulfillment Evaluation
Performance
Request Fulfillment A616
Activity Data
NODE: A61 TITLE:

Request Fulfillment CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Architecture Baselines SLAs OLAs UCs IT Plan IT Management Skills Inventory/D1 O5
and Roadmaps C2 C3 Ecosystem Change
C4 C1 Request
O3
Operational Service
I9 Project Proposals
Solution Design
Service Execution
Framework
I5
Establish
Solution Service
Plans and Execution Operational
Commitments
Framework Schedules
I2 A621 Work Requests_
Change Integrated Rejected
Information Solution Capabilities Work Schedule
I6 and Operational Procedures
Service Resilience Schedule
Plans O10
and Adjust Data Lifecycle
I10 Workload Request
Solution_ Recovered
Deployed Service A622 Work Item O7
I3 Schedule Consumables IT Administration
Work Status Work
Order Support Data
Requests Item
I1 and Requests
Service Request_ Assign and Security Work Request/S2
Authorized Delivery Control
Resources Delivery O2
Operational Delivery Resources_ Identity and Access
Documentation/D1 Resources Assigned Work Request
I11 A623
Incident_ Resolved Delivery Maintenance and O9
Resources_ Replenishment Schedule Data_ Derived
Recovered Resource
I7 Status Deliver
Service Service
Resilience O1
Directives/D1 Work Requests_
Completed
I14 A624
Data O6
Consumption Operational
Data Monitoring Data
I8 Delivery Work Item_ Monitor and
Configuration Resources_ Multi Phase Report
Information Released Service O4
Security Service Execution
Response/D1 Execution Metric Data and Reports
I12 Maintenance and Operations
Event Resolution Replenishment Data A625 O8
Directive Incident
Resource Evaluate
I13
Operational Adjustments Service Service Execution
Monitoring Data Execution Evaluation
Service Execution
I4 Activity Data
Performance
A626
Work
Data Input
Identity and
Access Response/D1
NODE: A62 TITLE:

Service Execution CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A63 Data Management
A63 Data Management
Architecture Baselines IT Management IT Plan Compliance Plans SLAs OLAs UCs Change Schedule
and Roadmaps Ecosystem C3 and Controls C2
I6 C1 C6
C5 C4
Service Resilience
Plans O1
Operational Service
Project Proposals
I7 Establish
Service
Resilience Data
Directives/D1 Management Data
Framework Management
I5 Data Lifecycle Framework
Change A631
Management
Information Plan
Plan Data Security Request/S1
Portfolio
I9 Lifecycle
Solution Design O3
A632 Acquire and CI Data
Prepare Data_ Update Package
Data_ External
Prepared
Data
A633
Data
I10 Control, Resource
Solution_ Deploy Catalog
Deployed
and
I3 Maintain
Data_ Derived O6
I4
Data Data
A634
Data Lifecycle Implementation
Request Backup Progress Data/S1
and
Restore
Security Data Backed Up Data
Response/D2 A635 and Manifest
I2
Operational Dispose Data_ Disposed
Monitoring Data Data_ Restored of Data O4
I8 Operational
Configuration Monitoring Data
Information A636
I11 Disposal Notification Monitor and
Event Resolution O5
Backup Restore Report Incident
Directive
Request Request Data
I1
Management
Service Request_ Operations
Authorized A637
O2
Evaluate Data
Change Data Management
Implementation Metric Data
Communication/D1
Management
and Reports
Performance
Data Management A638
Activity Data Data
Management
Evaluation
NODE: A63 TITLE:

Data Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Plan Architecture Baselines SLAs OLAs UCs Change Management

I7
Ecosystem C4 and Roadmaps Framework/D1
Solution Design C3
C1 C2
I2 O1
Solution_ Operational Service
Deployed Project Proposals
Establish
Event
I3 Management Event
Change Management
Framework Framework
Information A641
I4
Service Resilience Detect
Plans and O5
Event
Log Event
Event_
I1 A642 Significant
Operational
Monitoring Data Filter Event
I5 O2
Security Change
Monitoring Data/D1 Request
I6
A643 Event_
Configuration
Processed
Information
I8 Correlate
O4
Identity and Access Events and
Monitoring Data Incident
Select
Response
Event_ A644
Escalated
Resolve O6
Event Directive
Event_
Analysis Event_ Ready for
Updates Derived A645
Closure
O3
CI Data
Close Event Update Package
Event_
Closed
A646
Evaluate
Event Event
Evaluation
Event Management Performance
Activity Data A647
NODE: A64 TITLE:

Event Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Plan IT Management SLAs OLAs UCs
C3 Ecosystem C2
C1
I7
Solution Design
Establish
I5 Incident Incident
Service Resilience Management Management
Plans Framework
Framework
A651 Incident_
Logged Asset Data
I2 Identify Update Package/S1
Incident and Log O1
Incident CI Data
Update Package
A652
I6
Classify O5
Configuration Incident and Service Request
Information Provide Initial Incident_
Incident_ Support Classified Incident_
Needing A653 Resolution
Reclassification Plan
Operational Investigate
Documentation/D3 and
Diagnose O2
Knowledge
Incident Change
A654 Request
Assets/D1
Resolve
Incident and O3
I1 Recover Incident_ Resolved
Operational
Monitoring Data Service
A655
Incident_
I4 Incident_ Incident
Resolution Unsuccessful
Change Close Closed Communication
Information Incident to User
I8
Problem
Information A656
I3 Own,
Event
Change Monitor,
O4
Implementation Track and Incident
Communication/D3 Communicate Information
Incidents
A657
Evaluate
Incident
Request for Management
Incident Status
and Information Incident Management Performance
Activity Data A658
Incident
Management
Evaluation
NODE: A65 TITLE:

Incident Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Plan IT Management IT Financial Architecture Baselines SLAs OLAs UCs
C4 Ecosystem Reports and Roadmaps C3
C1 C5 C2
I7
Service Resilience
Plans
Establish
Problem Problem
I8 Management
Solution Design
Framework
A661
I3 Detect
Incident and Log
Information Problem
Problem
Supplier Product Configuration
A662
and Service Information
Information/D1 Categorize Request/S1
Service Resilience and Problem_
Reports/D2 Prioritize Prioritized
I6 Problem
Configuration A663
Information
I2 Investigate
Operational and Known
Monitoring Data Error
Diagnose
I4 Problem
Event A664
I5 Problem_ Resolve
Change Diagnosed O1
Information Problem Change
Major Request
Operational Problem
Documentation/D4 A665 Review
Service Outage Results Service
Analysis/D1 Problem_ Problem_
Problem_
Close and Improvement
Reprioritization Further Investigation Input
I1 Request Resolution Review
Request
Change Schedule Problem
Problem_
A666 Closed
Change
Implementation Monitor, O2
Communication/D2 Track and Problem
Report Information
Request for Problems
Problem Status A667
and Information Evaluate
Problem
Management
Performance
Activity Data
Problem
Management
Evaluation
NODE: A66 TITLE:
Problem Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Plan IT Management Business Identity Rules Compliance Plans SLAs OLAs UCs Security Policy
C4 Ecosystem and Controls C3 C5
C2 C1
I7
Solution Design
Establish
Identity and Identity and
I6 Access Access Management
Plan/D1 Framework
I2 A671
Service Request_ Evaluate and
Authorized Verify Identity
and Access
Identity and Request Identity
Access Request A672 Request
I1
Identity and Access
Work Request
Create and O1
Maintain Identity and
Access Rights
Identity Register
A673
Identity and
I5
Access Request Access Response
Security Provide and
Directives/D2
Maintain
Access
I4
Configuration Rights
A674 O3
Information
Incident
Monitor and
Report Identity and
Access Reports
I3 Identity and
Security Access
Monitoring Data/D1 A675
O2
Identity and Access
Request for Identity and Access Monitoring Data
Identity and Access Directives Evaluate
Information
Identity and
Access
Identity and Management
Access Management Performance
Activity Data A676
Identity and
Access Management
Evaluation
NODE: A67 TITLE:

Identity and Access Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A7 Resilience
A7 Resilience
IT Strategy IT Management IT Plan SLAs OLAs UCs Environment Identity and Service IT Budget Business
I3 C3 Ecosystem C5 Regulations Information Access Rights Catalog Industry Risk, Threats C9 Strategy
C2 Register O6
Service Metric Data C6 C7 C4 and Vulnerabilities C8
and Standards/D1 C1 Change
and Reports
Request
I17 O4
Business Service Resilience
Input Plans
I14 Business
Business and Compliance Continuity
IT Models Certification Policies
Compliance
Management O1
Business Output
I11 O2
Asset Information Business Security Compliance Plans
A71
I12 Policies and Plans and Controls
Security Plan O7
Solution Design Incident
Security
I1 Management O3
Architecture Baselines Security Policy
and Roadmaps
A72
Security Availability
Security Reports Security
Work Request Plan Monitoring Data
Availability
I7 Management
Stakeholder
Requirements Service Resilience
A73 Reports
I5
Incident Capacity
Availability Reports Service
Information
Reports Resilience
I15
Service Request_ Capacity Directives
Authorized
I4 Management
Operational
Monitoring Data
A74
Facilities
I13 Capacity Plan Plans and
Solution
Facilities Specifications
Plans and
I16
I2
Change Schedule CI Data
A75 Update Package
I6
Problem
Information
I9 IT Service
Change Continuity
Information
Management
IT Service
I10
A76 Continuity
Configuration Plan
Information
I8
Solution_
Deployed
NODE: A7 TITLE:
Resilience CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management Business IT Strategy Regulations Security Policy
Ecosystem Strategy C1 and Standards/D1
C4 C5
C2 C3
Business
Compliance
Plan
Establish
I2 Compliance Compliance Management
Business Management Framework
Input
Framework Compliance
A711 Requirements
Identify
Solution Compliance Compliance
Requirements Requirements Requirements_
Baseline/D1 Assessed
A712
I3 Assess
Business and
IT Models
Compliance
I4
Requirements
Asset Information A713
Define
Compliance O2
Compliance Plans
Controls Plan and Controls
Risk Assessment
and Mitigation Plans/D1 A714 Compliance
Operational
Capabilities
I1 Implement
Service Metric Data Compliance
and Reports Controls Configuration
Audit Request/S2
Individual A715
Process Compliance
Evaluations/D2 Audit Invocation
Audit and
Report
I5 O1
Security Reports
Compliance Compliance
A716 Certification
Compliance
Evaluate Audit Reports
Program and
Project Reports/D1 Compliance Compliance
Configuration Evaluation
Audit Report/D2
Compliance Management Performance
Activity Data A717
NODE: A71 TITLE:

Compliance Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Business Security Regulations IT Management IT Strategy IT Plan SLAs OLAs UCs Identity and
Policies and Plans and Standards/D1 Ecosystem C2 C3 Access Rights
C7 C5 C1 C4
Register
C6
Establish
I8 Security Security
Change Management
Information
Management
Framework
Framework
A721
Produce and
Maintain O3
Security Policy
Security Security
Identified
Risks/D1 PolicyA722 Security Risk Assessment
Risk Analysis
Analyze Security Information Asset
I4
Threats, Security Classification
and Roadmaps Vulnerabilities O6
and Risks Security Plan
A723
I3 O4
Solution Design Classify Service
Information Resilience
Operational Directives
Documentation/D5 Asset O1
Security Procedures
Security and Infrastructure Change
A724 Request
Security Directives
Security
I2 Plan and Response
Asset Information Implement
I1
Security
Compliance Plans Practices
A725 Security O5
and Controls Violation Security
I10 Operate Monitoring Data
Facilities Security
Plans and Protection O2
Specifications Security
Request Mechanisms Incident
I9 A726
Service Request_ Monitor,
Authorized Assess, O7
I6
Security Audit and Security Reports
Work Request Report
I7 Security
A727
Incident
Information
Evaluate
Security Security
I5 Security Management Evaluation
Activity Data
Performance
Configuration A728
Information
Identity and Access
Monitoring Data/D1
NODE: A72 TITLE:

Security Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Strategy IT Management Service Security Policy Solution Analysis and SLAs OLAs UCs IT Plan
C4 Ecosystem Catalog C1 Design Framework/D1 C3 C5
C2 C6
I5 Establish
Stakeholder Availability Availability Management
Requirements Management Framework
Framework
A731
Determine
I3 Availability
and Roadmaps
Requirements
A732
Business Impact Formulate

Assessment Availability
Availability Availability and
I11
Requirements
and Recovery
Solution Recovery Design
Design Criteria Criteria
Plans and A733 Availability
Commitments Targets
Projected Service Outage/D2 Define and
Implement
I1 Availability
Security Targets and
Monitoring Data
Related Availability Metrics
I4 Measures Model
Solution Design A734
Monitor,
I10
Analyze
Operational
Monitoring Data and Report
Availability O3
A735 Availability
Reports
I6
Configuration
Information
Service Achievement Investigate Service Outage
Reports/D2 Unavailability Analysis
Supplier Product and O1
Service Information/D2 Change
A736 Request
Produce
I7 Availability
Change O2
Information Plan Availability
I2 A737 Plan
Incident Evaluate
Information Availability Availability
I8 Management
Problem Management
Information Availability Management Evaluation
Performance
Operational Documentation/D6 Activity Data A738
I9
Facilities
Plans and
Specifications
NODE: A73 TITLE:
Availability Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Management IT Strategy IT Plan Service SLAs OLAs UCs

Ecosystem C3 C4 Catalog C2
C1 C5
Establish
I4 Capacity
Change Capacity Management
Information Management Framework
I8
Framework
A741
Solution
Plans and
Commitments
Model and Capacity
Requirements
I2 Size Capacity
Architecture Baselines Requirements
and Roadmaps A742
Capacity Models
and Results
Monitor,
O1
Analyze Capacity
I3 and Report Operational Reports
Configuration Capacity Schedule
Information Usage Directives O2
A743 Change
Capacity Delivery
Request
I5 Resource Reallocation
Operational Capacity Baselines Directives
Monitoring Data and Profiles
Operational Supervise Costing and
Schedules/D1 Tuning and Charging Request/S1
Capacity
I9
Service Level Package Delivery
Service Demand Forecasts/D1 A744 Service and
Service Achievement Resource Tuning O3
Reports/D3 Directives Service
Tuning and Resilience
I1 Produce and
Incident Capacity Delivery Directives
Information Allocation Maintain
Outcomes Capacity Plan O4
Capacity Plan
I6 A745
Problem
Information
I10
Evaluate
Change Schedule Capacity Capacity Management
I7
Facilities Capacity Management Performance
Plans and Activity Data A746
Specifications
NODE: A74 TITLE:

Capacity Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
SLAs OLAs UCs IT Management IT Strategy Business Security Business Regulations IT Plan IT Budget Security Policy Identity and
Ecosystem Policies and Plans Facilities and Standards/D1 C8 C2 Access Rights
C5 C6 C7
C4 C9 Plan C3 Register
I10 C1
Change
Information
Asset Management
Framework/D2
Establish
Supplier Management Facilities Facilities
Framework/D1 Management Management
Framework Framework
IT Service Continuity A751
Management Framework/D1
Security
Management Plan
Framework/D2 O4
Facilities Facilities
I7
Plans and
Solution Design
Specifications
I3 Facilities
Procedures
Security Plan
and Schedules
I11 A752
IT Service Facility Request
Continuity
Manage Response
Plan Facility
I9 Request Facility
Configuration Request
A753 Fulfillment
Information O1
Plan
I6 Change
and Roadmaps Request
Facility O3
I1 Request CI Data
Capacity Plan Exceptions Update Package
Operate and
I2 Asset Data
Availability
Maintain Update Package/S4
Plan Facilities
I8 A754
Change Schedule
Facility O2
I4 Request_ Incident
Service Request_ Qualified Facility
Authorized Facility
Incident_
Request
Evaluate Closed
Change/D3 Facilities Facilities
I5 Evaluation
Incident Facilities Management
Performance
Information Activity Data A755
Facility
Incident
NODE: A75 TITLE:

Facilities Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Strategy IT Management Service Business Industry Risk, Threats Security Policy Security Plan SLAs OLAs UCs
IT Plan
C6 Ecosystem Catalog Continuity and Vulnerabilities C3
C8 C1 C5
C4 C2 Policies
C7
C9
Security Establish IT
Management
Framework/D3
Service
Continuity IT Service Continuity
Management Business Service
Framework Continuity
A761 Requirements
Identify
Business
Service IT Service
I5 Policies and
Architecture Baselines Requirements IT Service Continuity
A762 Strategy
and Roadmaps Create and Risk Reduction
Maintain IT Design Criteria
Service
I3 Continuity
Compliance Plans
and Controls
Strategy
A763
I7
Configuration IT Service
Requirements Create and
I2 Maintain IT O3
Change Service IT Service
Continuity
Plan
Plan A764 IT Service
Availability and Continuity
Recovery Design Capability
Criteria/D3 Prepare IT O1
I1 Service Change
Facilities Request
Plans and
Continuity
O2
Specifications Capability Service
A765 Operational
I6 Continuity Resilience
Solution Design Infrastructure Directives
I4 Execute IT
Problem Normality
Information
Service Notification
I8 Continuity
Solution_ IT Service PlanA766
Deployed Continuity IT Service Continuity
Solution Test and Evaluate IT
Operational Audit Results
Documentation/D8 Service IT Service
Backed Up Data Management
IT Service Continuity Management Evaluation
and Manifest/D1
Continuity Notification A767
Activity Data
Change/D1
NODE: A76 TITLE:

IT Service Continuity Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
A8 Administration
A8 Administration
IT Strategy IT Portfolio SLAs OLAs UCs Security Policy IT Management Service Business Architecture Baselines
and Roadmaps Environment
C4 C3 C6 C1 Ecosystem Catalog Strategy
Business C2 Information
C7 C5 C9
Accounting C8
Framework
I5 Technology
Business Capabilities
Input and Trends/D1
I1 Regulations and
Standards/D2 O3
IT Plan Supplier Supplier
Payments Output
I12
Financial
Management O2
Business Funding IT Budget
A81 Customer O5
I3 Charges or Request to Purchase IT Financial
Compliance Plans Cost Data Invoices Supplier for Information Orders Reports
and Controls
Supplier
I4 Contract
Asset Information Management Requirements
O4
Customer Payment Underpinning
I10 A82 Contracts
Customer Input
I7 Asset
Business and
IT Models Service
Supplier
Invoices Pricing and
I9 Contract O1
Service Level Package Customer Output
I2 Administration
Service Metric Data Items_ Information From A83
and Reports Procured Suppliers
Service Pricing and
I11 Contract Information
Supplier Input Workforce Skills Plan
I6 Management
Solution Design Workforce
Management
A84 Information
I8
IT Research
Guidance
Advanced Practices
Knowledge
Knowledge_ Management Knowledge
Internal and Assets
External
A85
Knowledge
Request
NODE: A8 TITLE:
Administration CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Business IT Strategy Regulations and IT Management IT Portfolio Service Underpinning

Service Pricing and SLAs OLAs UCs
Strategy C1 Standards/D2 Ecosystem C2 Catalog Contracts
Contract Information C3
C7 C4 C5 C9
C6 C8
I1
Business
Accounting
Framework Establish
I4 Financial
Compliance Plans Management Framework
and Controls Framework
A811
IT Financial Modeling Perform

Request
Financial
I2
IT Plan Modeling IT Financial
Modeling Analysis
I3 A812
Business Funding
Plan and O2
Portfolio Decision and Control IT Budget
O3
Resource Allocation/D1 Budgets
IT Financial
I10
A813 Reports
Individual IT Process Perform

Activity Data Financial O1
Supplier
Accounting Service Payments
I6 Accounting
A814 O5
Data
Customer Payment
Budget Variance Cost Data
I8
Supplier Administer
Invoices Charging
I9
Workforce O4
Management Customer
Information A815
Charges or
Invoices
I5 Audit IT Financial
Asset Information Financials Audit Reports
Asset Contracts and

Financial Data/D1 A816
Evaluate
I7
Service Metric Data Financial Financial
and Reports Management Management
Evaluation
Performance
Financial Management A817
Activity Data
NODE: A81 TITLE:

Financial Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Business IT Strategy IT Budget IT Management Regulations and IT Financial
Security Policy
Strategy IT Sourcing C3 C2 Ecosystem Standards/D2 Reports
C4
C6 Strategy C5 C7 C1
Supplier Management
Framework
Establish
I3 Supplier
Business and
IT Models
Management
Framework
I2 A821 O1
IT Portfolio Request to
Supplier
Portfolio Supplier for Information
Manage
I6 O2
Information From
Portfolio of
Contract
Suppliers Suppliers Requirements
Information A822 IT Financial Modeling
About Suppliers Request/S6
Manage
Request for
Product or Service
Supplier
O4
Contracts Underpinning
Contract A823 Contracts
O5
I1 Exceptions
Asset
SLAs OLAs UCs
Manage
I5 Procurement
Items_ O6
Purchase Purchase Order Status
Procured
Order
Status A824
IT Financial
Procurement O3
Modeling Analysis/D6
Exceptions Purchase
Asset Replenishment
Orders
Request/D1
Evaluate Supplier Performance
I4 Supplier Evaluation
Supplier
Invoices Performance
Supplier Performance A825
Asset Contracts and
Issue
Financial Data/D2 Supplier Product
Provide
and Service
Supplier Supplier Information
Performance Data Product and
Request for Service
Supply Capability
Information Unavailable Product Information
A826
and Service Exceptions
Evaluate
Supplier
Supplier Management
Supplier Management Performance Evaluation
Activity Data A827
NODE: A82 TITLE:

Supplier Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
IT Strategy IT Management IT Portfolio Service SLAs OLAs UCs

C1 Ecosystem C2 Catalog C4
C3 C5
Financial Establish Service Pricing and

Management Service Contract Administration
Framework/D1 Pricing and Framework
Contract
I1 Administration Pricing
Cost Data Framework Algorithm
A831 Pricing
Elements Pricing
Collect Data
Pricing Data
I3
Service Metric Data
and Reports A832 Service Price Model
Projected
Solution Cost
Provide O1
Costing and
Charging Request
Price Service Pricing and
Alternatives Contract Information
I2 Billing
A833
Service Level Package Options Proposed Customer
Contract Terms
Administer
Services Customer
Proposal/D1 Contract/
Services Service
Agreement/D1 Agreement Contract Terms
A834
Monitor
Marketing and Pricing
Sales Reports/D2 Effects
Pricing A835
Analysis
Evaluate
Service Service Pricing
Pricing and and Contract
Administration
Contract Evaluation
Service Pricing and Administration
Contract Administration A836
Activity Data
NODE: A83 TITLE:

Service Pricing and Contract Administration CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Business IT Management IT Strategy SLAs OLAs UCs Security IT Budget Architecture Baselines
Regulations and C1
Strategy Ecosystem Plan/D4 and Roadmaps
Standards/D2 C2 C4
C7 C5 C3 C6
Business Workforce
Policies and Practices
Legal and
Regulatory Requirements
Establish
Workforce Workforce
External Workforce Management Management Framework
Frameworks
and Practices Framework
A841 O3
Workforce
Plan Information
I1
Forecast
IT Plan and Plan
Workforce Workforce
Adjustment
A842 Requisition
Administer
Deployed
Human Resource Human Workforce
Adjustment Resources Skill
A843 Requirements
Training
Labor Requirements
Inventory
Information
Manage
Skills O1
Skills Plan
I3
IT Research A844
Guidance
O2
Advanced Practices
I2
Solution Design Evaluate
Skills
Inventory Workforce Workforce Management
I4
Knowledge Performance
Workforce Management A845
Assets
Activity Data
NODE: A84 TITLE:

Workforce Management CURRENT PAGE:
•
•
•
•
IDEFØ Diagrams
Business IT Management IT Strategy Technology IT Portfolio Architecture Baselines Security Policy
Strategy Ecosystem C3 Capabilities and Roadmaps C1
C4
C2 and Trends/D1 C5
C6
C7
Knowledge Establish
Management Knowledge
Methods and
Knowledge Management Framework
Techniques Management
Framework Infrastructure
A851
Knowledge
Plan
I1 Create and
Skills Plan Maintain
Knowledge Sources
Knowledge
and Categories Plan
I3
A852
Knowledge_ Knowledge_
Internal and Knowledge Items Unstructured
External Acquire Knowledge
Knowledge Acquisition Requests
I2
Advanced Practices Knowledge_
A853 Appraised and
Structured
Evaluate and Knowledge Submission

Response
Structure
Knowledge
A854
Knowledge
Gaps Disseminate O1
Knowledge Knowledge
Assets
I4 Operational
Documentation
Knowledge A855
Request
Monitor,
Knowledge Knowledge
Request Queue Assess and
Reports
Report
Knowledge Knowledge
Management Status
Feedback A856
Evaluate
Knowledge Knowledge
Evaluation
Performance
Knowledge
A857
Management
Activity Data
NODE: A85 TITLE:

Knowledge Management CURRENT PAGE:
•
•
•
•
Accepted Conditions of Satisfaction – Asset
Glossary
A B C D E F H I K L M N O P R S T U V W
A magnitude of allowed exceptions, enabling the

effectiveness of the process to be determined.
Accepted Conditions of Satisfaction Architecture Management Evaluation
(From: A414, To: A415) (From: A337, To: A331)
Established earlier Conditions of Satisfaction formally Assessment of the effectiveness and efficiency of the
accepted and signed off by the key stakeholders architecture management process. Includes
(especially the customer). identification of areas for process improvement.
Access Request Architecture Management Framework
(From: A672 A673, To: A674) (From: A331, To: A332 A333 A334 A335 A336 A337)
An access request that has been evaluated and verified. The organizational structure and processes deployed to
Each access request is associated with a verified user ensure the architecture is effectively and efficiently
identity. established, maintained and used.
Advanced Practices Architecture Need
(From: A84 A844, To: A85 A853) (From: A332, To: A333)
The knowledge and behaviors of leading practitioners An identified shortfall in the existing (or envisioned) IT
that sets a benchmark for others to reach and emulate. environment that can be addressed by some
The practices will contain subject-matter content, but will architectural instrument.
also cover techniques for content application and for
mentoring. Architecture Transition Initiatives
(From: A335)
Allocated Asset Items
A brief proposal, recommending the implementation of
(From: A552, To: A433 A434 A435 A436)
one (or more) aspects of the envisioned architecture.
The assignment and delivery (if appropriate) of identified Typically defined in outline, with broad statements on
IT assets to fulfill asset requisitions. scope, benefits and business case, costs, dependencies,
Architecture Baselines and Roadmaps and project time line.
(From: A3 A33 A334, To: A1 A11 A114 A12 A121 A122 Architecture_ Current State
A123 A124 A125 A2 A22 A221 A31 A313 A314 A332 (From: A332, To: A335 A336)
A333 A335 A336 A36 A361 A4 A41 A411 A412 A413
A description of the business' overall approach to the
A42 A43 A431 A44 A441 A443 A45 A451 A5 A51
structuring and implementation of its IT systems and
A513 A514 A52 A522 A523 A524 A54 A541 A542
solutions.
A55 A551 A6 A62 A621 A63 A631 A64 A641 A66
A661 A663 A664 A665 A7 A72 A723 A73 A732 A734 Architecture_ Exception
A736 A74 A742 A743 A75 A752 A76 A763 A764 A8 (From: A336, To: A332)
A84 A842 A844 A85 A852)
An allowed deviation within a solution design from the
Provides an agreed, published statement of the required architecture, providing input to the collection of
architecture at a moment in time. Includes statements to architecture processes which ensure vitality.
assist in selection and evaluation of appropriate
implementations of specified architecture building blocks. Architecture_ Future
(From: A333, To: A334 A335 A336)
Architecture Compliance Decision
A structured description of the preferred business
(From: A336)
approaches to the design and implementation of its IT
A statement or report recording the architectural systems and solutions. Generally published as a
compliance (including permitted exceptions) of a solution specification of architecture building blocks, together with
design. recommended standard constructions of those building
blocks.
Architecture Management Activity Data
(From: A332 A333 A334 A335 A336, To: A337) Asset
Metrics on the performance of the architecture (From: A82 A824, To: A552)
management processes, such as the frequency or Each asset that has completed the procurement process
(business now holds the title) and is available for
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • -1
•
This material may not be reproduced in whole or in part without the prior written permission of IBM. •
Asset Audit Action Request – Asset Register
Asset Audit Action Request Asset Information

(From: A554, To: A552 A553 A555) (From: A5 A55 A553, To: A54 A543 A7 A71 A713 A72
A request to perform some action based on the findings A724 A8 A81 A812 A814 A815)
of an asset audit. This can include instructions such as to Could be reports, covering multiple asset items, or just
locate a known asset or to reassign it. the specific information on an individual asset.
Asset Availability Information Asset Information or Report Request
(From: A552, To: A514) (To: A553 A554 A557)
Details of the ability of the subject IT asset or assets to A request to obtain information about a deployed asset.
be made available for deployment or development use. This request specifies whether the information should be
The details will include: in a formal report or simply provided asset data. It covers
– Quantities a range of request types, such as:
– Specifications – Need for information on an individual asset
– Dates – A scheduled report
– Locations. – A request for an asset analysis report.
Asset Availability Inquiry Asset Licenses

(To: A552) (To: A554 A555)
A planning inquiry to establish the outlook for the A documented permission to use an asset or set of
availability of specified IT assets for productive use. assets. The license may contain specific terms and
conditions, including details such as the number of
Asset Contracts and Financial Data users, any rights to copy and distribute, and the license
(From: A555, To: A552 A553 A554 A557 A814 A825) period.
Business records about an asset and related financial
information. This includes data such as asset records, Asset Management Activity Data
vendor information, asset costs and current value, tax (From: A552 A553 A554 A555 A556 A557, To: A558)
data. Data resulting from all work carried out by each process
activity, used to support the evaluation of the overall
Asset Data Update Package Asset Management process.
(From: A516 A534 A535 A652 A753 A754, To: A553)
All status and detail changes to an asset after the initial Asset Management Evaluation
creation. Includes lease, license, maintenance changes (From: A558, To: A551)
and, at end of life, disposal notification. An additional Assessment results for the Asset Management process
example is a change in standard currency exchange and its activities, including process performance metrics
rates from the IT Financial Management process. and the identification of potential process improvement
items.
Asset Deployment Inquiries and Requisitions
(From: A433 A434 A51 A514 A515 A516 A52 A522 Asset Management Framework
A523 A524 A53 A534, To: A55) (From: A551, To: A541 A552 A553 A554 A555 A556
Requests for information about assets needed as part of A557 A558 A751)
deploying solutions, requisitions for allocation of assets, The policies, procedures, organizational roles and
and notifications to trigger the delivery or distribution of responsibilities and other information under which the
these resources. Asset Management process will operate to meet its
mission and goals.
Asset Deployment Items and Data
(From: A5 A55, To: A4 A43 A51 A52 A522 A523 A524 Asset Operational Data
A53 A534) (From: A552, To: A553)
Information about specific asset availability and Relevant individual data values describing the specifics
requisition status, and also the actual asset items being of the current state of an asset. Examples include:
offered up for deployment. – Location
– Owner
Asset Distribution Instruction
– Maintenance contract end date
(To: A552)
– Original purchase price.
The formal trigger for IT assets, probably already
reserved for this purpose, to be distributed. The Asset Reconciliation Data
instruction would include details such as: (From: A554, To: A545)
– Date Data collected during auditing and inspection of assets.
– Location Typically includes location, condition and verification
– Quantity results.
– Specification
Asset Register
– Personnel involved and contact details.
(From: A553, To: A552 A554 A555 A556 A557)
The complete set of records in asset information
repositories.
•
•
-2 • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
• This material may not be reproduced in whole or in part without the prior written permission of IBM.
Asset Replenishment Request – Billing Options
Asset Replenishment Request Availability Management Evaluation

(From: A552 A554, To: A824) (From: A738, To: A731)
A trigger to indicate that additional quantities of an asset An analysis of how well the Availability Management
are required in order to meet existing or anticipated process was performed. This can also include proposed
requisitions. modifications to the Availability Management Framework.
Asset Reports Availability Management Framework
(From: A557) (From: A731, To: A732 A733 A734 A735 A736 A737
Ad hoc or standard reports describing assets. These A738)
reports may describe one or more selected assets or The set of policies, procedures and mechanisms for
may summarize data about a set of assets, or possibly performing the Availability Management process.
all assets.
Availability Metrics Model
Asset Requisition (From: A734, To: A735 A737)
(To: A552) The range of availability metrics and areas of reporting
The placement of an 'order' for one or more specified that are used to describe service availability.
assets (or asset types) to be 'delivered' or otherwise
made available for productive use. Availability Plan
(From: A73 A737, To: A75 A752)
Asset Requisition Status A forward-looking plan aimed at improving the overall
(From: A552, To: A515) availability of the IT infrastructure within cost constraints.
The acknowledgement, including status information such
as expected dates, that a requisition for one or more Availability Reports
assets has been received and processed. (From: A73 A735, To: A736 A737)
Statistics expressed on how well the IT Infrastructure has
Asset Retirement and Disposal Data met the needs of the business in availability terms. Might
(From: A556, To: A552 A553 A555) be included in Service achievement reports.
Data that describes the disposition and status of assets
slated for retirement and disposal. Availability Requirements
(From: A732, To: A733 A734)
Asset Retirement and Disposal Instructions An examination of the requirements for availability as
(From: A552 A554 A555, To: A556) expressed by the various stakeholders. As there might
Directives concerning assets slated for retirement and be some contention between these, this process must
disposal. establish the definitive set of availability requirements
which will influence solution and service development
Asset_ Disposed and operation.
(From: A556)
Assets that have reached the end of their useful life cycle Availability Targets
and have been removed from service and inventory. (From: A734, To: A735 A737)
Disposal can involve selling, scrapping or recycling. Objectives for service availability, typically focusing on
service unavailability and business impact.
Asset_ Reactivated
(From: A556, To: A552)
An asset that was previously retired, but has been B
brought back into active service.
Backed Up Data and Manifest
Asset_ Retired (From: A635, To: A765 A766)
(From: A552, To: A556) The data which is the result of taking a backup, in
An asset that is to be removed from service. Such an whatever format (for example, compressed, incremental)
asset will be in a storage location (such as the Definitive which has been selected as the basis for any
Hardware Store or DHS) until it is either restored subsequent restore action, plus the indexes and
(recovered) for active use or disposed. inventories (the manifest) of the content with regard to
Availability and Recovery Design Criteria
(From: A733, To: A243 A422 A734 A764) Backup Request
General solution design principles that enhance service (To: A635)
availability and recovery. This information is used to Service Requests from any user or other process that a
create or update solutions so that they are more resilient. backup be taken.
Availability Management Activity Data Billing Options

(From: A732 A733 A734 A735 A736 A737, To: A738) (From: A833, To: A834)
Results and metrics that describe the results of Describes different Service Price Models and how to
performing the Availability Management process. choose between them.
•
•
•
Budget Variance – Business Governance Capabilities
Budget Variance Business Demand Characteristics

(From: A814, To: A813) (To: A25 A252)
Budget Variance defines the delta between the planned Data from business units and customers describing the
budget and planned results, and the actual spent effort characteristics of business demand. The characteristics
and achieved results. focus on information about the demand in the context of
business strategy (to support evaluation and
Business Accounting Framework classification).
(To: A81 A811)
Details of the business-wide financial framework, Business Demand Forecasts
including the required interfaces with the IT Financial (From: A253, To: A254 A256)
Framework. Agreed predictions of business demand for IT service,
usually arranged by periods against a standard calendar.
(To: A25 A253 A255) Business Demand Optimization Recommendations
Business activity patterns reflect the typical workload (From: A25 A255, To: A256)
profile from one or more business activities. User profiles Data from business units and customers describing the
are collations of business activity patterns to reflect that characteristics of business demand. The characteristics
most users are actors within several business processes, focus on information about the demand in the context of
and these combinations vary depending on organization business strategy (to support evaluation and
design. Refer to the ITIL Glossary and to the Service classification).
Strategy book for further reading.
Business Demand Value Classification
Business Aligned IT Goals (From: A25 A252, To: A253)
(From: A313, To: A314 A315) A scheme for classifying each business demand stream
Statement of IT goals and objectives. Includes coverage as a basis for making decisions in the event of demand
of guiding principles, policies, strategic assumptions, and exceeding supply and the results of performing the
technology principles. classification, particularly to include the business value
characteristic.
(From: A3 A33 A333, To: A2 A25 A253 A254 A32 A322 Business Evaluation Feedback
A323 A334 A34 A342 A344 A35 A352 A4 A41 A412 (To: A14 A142 A143)
A413 A42 A422 A7 A71 A712 A714 A8 A82 A821 Any feedback, formal or informal, from non-IT parts of
A822) the overall business which is relevant to evaluating the
Representations of relevant aspects of the business' performance of the IT management system.
activities, in model formats, and with or without the
inclusion of related IT factors. Business Facilities Plan
(To: A752)
Business and IT Models Update Package The plan, established by the Business, describing the
(From: A412, To: A334) quantity, locations, and other Facility items that enable it
Additional information about business and IT models to operate.
obtained as a by-product of detailed investigation under
the Solutions Requirements process. Business Funding
(From: Outside-the-Model, To: A8 A81 A813)
Business Compliance Plan Defines the overall planned budget effort (people,
(To: A711 A712 A714) money) for all planned services and activities in IT.
The compliance requirements determined by the
business, derived by examination across the span of its Business Goals
activities and details of the specifications and (To: A112)
implementations of corresponding compliance plans. Goals of the Business.
Business Continuity Policies Business Governance

(To: A76 A761 A762) (From: Outside-the-Model)
Rules and guidelines used to assist in the determination Includes Business Drivers
of critical business services, and in the determination of
potential risks, threats, and vulnerabilities. Business Governance Capabilities
(To: A111)
Business Demand Baselines The charters, structures, roles and responsibilities,
(From: A253, To: A254 A256) decision making mechanisms and measurement
An agreed statement of the expected business demand capabilities, which are used for governance across the
for the normal (typical) pattern of business. A baseline is overall business within IT.
“A Benchmark used as a reference point.”1
1. ITIL V3 Glossary
•
•
•
Business Identity Rules – Capacity Management Evaluation
Business Identity Rules most, if not all, of the framework for managing IT
(To: A671) projects.
Set of rules that will be used to determine if identity
requests and access requests will be approved. Part of Business Risk Posture
'Business Security Policies and Plans'. (To: A34 A343 A344)
The capability of the business to tolerate varying levels of
Business Impact Assessment risk. It includes business guidance on how to choose
(To: A732) which risks to accept and which need mitigation.
An appraisal of the impact of service unavailability on the
business. Business Security Policies and Plans
(To: A72 A721 A722 A723 A725 A75 A752)
Business Input This is the overall set of security directives from the
(From: Outside-the-Model, To: A1 A2 A3 A33 A332 A7 business, establishing the context for protection of
A71 A8) business assets and information. It is often known as an
The various input items from the business to the IT Enterprise Security Program.
provider that shape or direct the IT service. Examples of
such inputs include: Business Service Continuity Requirements
(From: A762, To: A763)
– Guidance
The results of a business impact analysis, with identified
– Instructions
risks, threats, and vulnerabilities.
– General commentary and information about business
operating conditions Business Strategic Wants and Needs
(From: A312, To: A313)
Statement of strategic ambition, objectives, priorities and
(To: A112 A113)
intent of the business.
Policies of the Business that have a bearing on the IT
function. They include fundamentals such as statements Business Strategy
of the core values of the business through explicit (To: A1 A11 A111 A112 A2 A24 A242 A243 A25 A252
policies, which must be followed (for example, in external A26 A262 A3 A31 A312 A32 A321 A323 A33 A332
relations). A333 A34 A341 A36 A361 A366 A4 A41 A412 A7 A71
A711 A8 A81 A811 A82 A821 A84 A85 A851)
Business Management Practices
The business strategy stated in terms of strategic intent,
(To: A114)
roadmap, drivers, objectives and policies.
Practices dictated by the Business that have a bearing
on the equivalent items framed for the IT function. Business Workforce Policies and Practices
(To: A841)
The workforce management policies and practices of the
(To: A1 A11 A14 A143 A144)
parent business.
The management system in place to govern the
workings of the overall business.
C
Business Metrics
(To: A25 A253 A26 A266 A367) Capacity Baselines and Profiles
Metrics (measurements, key performance indicators) on (From: A743, To: A254 A255 A744 A745)
business performance. They are provided by the Collective representations of current (and projected)
business whether or not the underlying data is managed capacity for selected groups of assets and resources, as
by IT solutions. well as patterns of consumption by various consumers.
Business Output Capacity Delivery Resource Reallocation Directives
(From: A2 A7, To: Outside-the-Model) (From: A744)
The interactions from the collective IT endeavor to the Desired changes and adjustments to resource
businesses which relate to the any aspect of the life allocations for the purpose of optimizing available
cycle related to the establishment and performance of capacity against demand. Sometimes a part of a general
the IT product; that is, the services and solutions. The Service Resilience Directive.
interactions include:
– Assessment of actual and potential value from IT Capacity Management Activity Data
– Business demand classifications, forecast (From: A742 A743 A744 A745, To: A746)
consolidations and proposed demand interventions Data resulting from all work carried out by each process
– Compliance certifications activity. Examples would be volumes, timings, resources
used, success and error rates, interfaces invoked,
Business Project Management Framework rework, customer feedback, priorities.
(To: A37 A371)
The implementation within the parent business of a Capacity Management Evaluation
project management framework. This will usually provide (From: A746, To: A741)
•
•
•
Capacity Management Framework – Change Request
An assessment of the overall performance of the process Change Assessment Information

against the targets set in the process framework and an (To: A514)
identification of possible process improvement areas. Any information about the potential impact or risks
relating to a change, including input from the business
Capacity Management Framework and from any other relevant process within IT.
(From: A741, To: A742 A743 A744 A745 A746)
The conceptional structure describing the strategic Change Assessment Information Request
(vision, mission, value proposition), organizational (From: A514)
(organizational mechanisms, roles, accountabilities), A request to any relevant party to provide information
process (activities, work flows, inputs, outputs), that will contribute to the assessment of a change.
information (entities, attributes, relationships) and
technology (software, hardware) practices for managing Change Implementation Communication
capacity. (From: A51 A516, To: A375 A52 A522 A523 A524 A53
A535 A536 A54 A542 A543 A635 A655 A665)
Capacity Models and Results Information used to coordinate and implement a change.
(From: A742, To: A743 A744) It can reflect either or both the:
Qualitative and quantitative algorithms and projections – Status of the overall change as a result of carrying
used to track and predict IT resource capacity and usage out previous instructions
patterns. – Instructions for the next stages of implementation
Capacity Plan This dual nature is required to reflect incremental
(From: A74 A745, To: A742 A743 A744 A75 A752) progress towards completion of a multi-stage
The approach that will be taken to satisfy resource implementation, especially when the outcome of one or
requirements. The plan is configurable, meets more steps did not meet expectations in all respects.
performance expectations and has the required Change Information
commitment to implement. It includes: (From: A5 A51 A518, To: A2 A23 A233 A235 A3 A35
– SLA recommendations A355 A513 A514 A515 A516 A517 A54 A542 A543
– Threshold and alarm definitions. A6 A61 A613 A615 A62 A621 A63 A632 A64 A641
A65 A654 A66 A662 A666 A7 A72 A721 A725 A73
Capacity Reports A731 A735 A736 A74 A741 A742 A743 A75 A751
(From: A74 A743, To: A256 A744) A76 A761 A764)
Information about the results and outcomes observed The full scope of information is covered. This could be
and achieved relating to all aspects of capacity. Reports about an individual detail within a particular change
include: through ad hoc or pre-determined reporting on a set of
– Performance and capacity results changes.
– Workload analysis
– Forecasts and predictions Change Management Activity Data
(From: A512 A513 A514 A515 A516 A517 A518, To:
Capacity Requirements A519)
(From: A742, To: A744 A745) Data resulting from all work carried out by each process
Detailed forecasts of the IT resource capacity needed to activity. Examples would be volumes, timings, resources
satisfy projected workloads and service level used, success and error rates, interfaces invoked,
commitments while maintaining acceptable utilization rework, customer feedback, priorities.
and load factors.
For example, they can include: CPU processing power, Change Management Evaluation
storage space, and network bandwidth. (From: A519, To: A511)
An assessment of the overall performance of the process
Catalog Presentation Requirements against the targets set in the process framework and an
(To: A232) identification of possible process improvement areas.
Requirements for the style, content and usability of the
service catalog. They include expectations, service level Change Management Framework
commitments, efficient searching, and ordering (From: A511, To: A233 A234 A512 A513 A514 A515
organized for each user community. A516 A517 A518 A519 A611 A641)
The policies, procedures, organizational roles and
Change responsibilities, and other information under which the
(From: A51 A515, To: A412 A516 A517 A518 A52 Change Management process will operate to meet its
A522 A53 A532 A54 A543 A753) mission and goals.
A change, triggered by a change request, which has
successfully completed assessment and has Change Request
subsequently been authorized for implementation. The (From: A2 A23 A232 A3 A35 A355 A4 A42 A422 A43
authorization includes details of schedule options and A432 A44 A442 A54 A542 A6 A61 A613 A62 A621
any implementation conditions, such as the decision to A64 A644 A65 A655 A66 A665 A7 A72 A725 A73
include the change within the scope of a planned A737 A74 A744 A745 A75 A752 A754 A76 A765
release. A766, To: A5 A51 A512)
•
•
•
Change Request_ Recorded – Compliance Audit Reports
Change requests (also known as RFCs) are the means The history and record of the change implementation
for submitting proposed change and actual change activity which has culminated in the completion of the
activity in the environment. Change requests can be change related to the change request. It also includes
triggered for a wide variety of reasons, from a broad the case of a failed implementation, with any back out
spectrum of sources. They can be concerned with any results.
part of the environment or with any service or activity.
CI Data Update Package
Change Request_ Recorded (From: A4 A42 A424 A43 A433 A434 A435 A436 A437
(From: A512, To: A513 A518) A44 A444 A45 A456 A51 A516 A52 A523 A526 A53
The details of a change request, captured in a document A535 A536 A6 A63 A634 A64 A645 A65 A652 A7 A75
or other format defined by the Change Management A753 A754, To: A5 A54 A542 A543)
Framework. The details of modifications to any existing CIs that must
be validated and captured in the CI master data. The
Change Request_ Rejected modifications can include:
(From: A513 A515) – Attributes
Any change request which has been rejected, and sent – Relationships.
back to the requestor. Reasons for rejection include:
– Lack of authorization or funding CI Information
– The change requested is beyond the scope of (From: A543, To: A542 A544 A545)
Change Management (for example, it is a new The definitive configuration information about each and
requirement) every managed configuration item. The collection of this
– The change request is incomplete or in error information is represented by the concept of a CMDB.
– The change request has been assessed as having
CI Requisition
too high a risk and needs rework
(From: A4 A42 A423 A424 A43 A433 A434 A44 A444,
Change Schedule To: A5 A54 A543)
(From: A5 A51 A515 A516, To: A514 A516 A517 A52 A request for one or more CIs to be made available so
A522 A525 A54 A543 A545 A6 A63 A632 A66 A665 that they can be worked upon. In a development
A7 A74 A744 A745 A75 A752 A753) environment, this might be a request to check-out
As defined in ITIL: “A Document that lists all approved solution components from a version-controlled
Changes and their planned implementation dates. A configuration library.
Change Schedule is sometimes called a Forward
CIs
Schedule of Change, even though it also contains
(From: A5 A54 A543, To: A4 A43 A434 A44 A444)
information about Changes that have already been
CIs are the technical (in its broadest sense) components,
implemented.” 2 including assemblies of more granular components,
Change Status and Information Request upon which IT service is based. The relevant extract from
(To: A518) the ITIL definition of Configuration Item is: “Any
Component that needs to be managed in order to deliver
A request for the current status of a change within the
an IT Service. ... CIs typically include IT Services,
control of Change Management.
hardware, software, buildings, people, and formal
Change_ Assessed documentation such as Process documentation and
(From: A514, To: A515 A518) SLAs.” 3
The change, including the collection of assessment
recommendations. Collated IT Management System Outcomes
(From: A141, To: A142 A143)
Change_ Categorized Collection of all the Management System Assessments
(From: A513, To: A514 A518) into an easy to use format for further analysis.
The change request, which has completed acceptance,
is now recognized as a change. The categorization Compliance Audit Invocation
indicates the types and levels of assessment needed. (From: A716)
A directive to all processes that are required to operate
Change_ Closed under the risk and compliance controls for evidence
(From: A517, To: A518) which will be examined to identify whether and how well
The change having completed all parts of the change life those controls are being operated.
cycle, and reached closed status.
Compliance Audit Reports
Change_ Implemented (From: A716, To: A143 A713)
(From: A516, To: A517 A518) Documents communicating the results of individual
process compliance and mitigation audits.
2. ITIL V3 Glossary 3. ITIL V3 Glossary
•
•
•
Compliance Certification – Configuration Management Framework
Compliance Certification Configuration Audit Action Request

(From: A71 A716) (From: A545, To: A542 A543 A544)
Formal declaration by the accountable executive of A request for some corrective action to be taken to reflect
adherence to regulatory requirements. the outcomes of configuration audit.
Compliance Management Activity Data Configuration Audit Report
(From: A712 A713 A714 A715 A716, To: A717) (From: A545, To: A455 A554 A716)
Data resulting from all work carried out by each process The outcomes of a configuration audit. The outcomes
activity. Examples would be volumes, timings, resources cover both status of configuration items and audit trails of
used, success and error rates, interfaces invoked, changes to configuration items, such as logs of identities
rework, customer feedback, priorities. of the person(s) making such changes.
Compliance Management Evaluation Configuration Audit Request
(From: A717, To: A711) (From: A554 A716, To: A545)
An assessment of the overall performance of the process A request for any aspect of the collected configuration
against the targets set in the process framework and an information to be audited against the actual, real
identification of possible process improvement areas. managed object.
Compliance Management Framework Configuration Baseline Report
(From: A711, To: A712 A713 A714 A715 A716 A717) (From: A54 A542 A543, To: A423 A51 A514 A516 A52
The policies, procedures, organizational roles and A522 A523 A524)
responsibilities and other information under which the A point-in-time snapshot of a portion of a CMDB that is
Compliance Management process will operate to meet relevant to one or more purposes from other IT
its mission and goals. management processes. This can include past, current,
and future projected instances.
Compliance Operational Capabilities
(From: A715, To: A716) Configuration Information
The set of capabilities which implement the various (From: A5 A54 A544, To: A3 A33 A336 A4 A42 A422
controls required to adhere to specific regulatory or more A423 A424 A44 A442 A443 A51 A513 A514 A516
informally generated requirements. A52 A523 A524 A53 A533 A534 A535 A545 A55
A553 A6 A61 A612 A62 A623 A63 A634 A635 A64
Compliance Plans and Controls A642 A65 A652 A653 A654 A66 A662 A67 A674 A7
(From: A7 A71 A714, To: A1 A11 A111 A113 A114 A3 A72 A724 A726 A727 A73 A735 A736 A74 A742
A36 A361 A37 A371 A4 A41 A412 A413 A5 A51 A511 A743 A744 A75 A752 A76 A764 A765 A766)
A52 A521 A53 A531 A54 A545 A55 A554 A555 A6 The information on any individual configuration item (CI)
A63 A632 A67 A671 A715 A716 A72 A725 A76 A763 or collection of CIs, which is made available using
A8 A81 A811) standard reports or to meet individual requests.
– The items for which compliance is required Configuration Information Request
– The means (policies, data specifications, procedures, (From: A336 A422 A423 A424 A442 A443 A664, To:
techniques, tools) to achieve compliance A54 A544)
– The definition of required compliance metrics and Any request for information about one or more
reports by which conformance will be able to be configuration items. Many IT processes will make such
demonstrated for required scrutiny requests.
It will be the major vehicle for communications and Configuration Management Activity Data
guidance on compliance efforts. (From: A542 A543 A544 A545, To: A546)
Compliance Requirements Data resulting from all work carried out by each process
(From: A712, To: A713) activity. Examples would be volumes, timings, resources
The necessary conditions and actions needed to adhere rework, customer feedback, priorities.
to external regulations or standard practices and also to
requirements established by the business through Configuration Management Evaluation
activities such as audit and oversight. (From: A546, To: A541)
Compliance Requirements_ Assessed An assessment of the overall performance of the process
(From: A713, To: A714 A716) against the targets set in the process framework and an
identification of possible process improvement areas.
Sets of categorized, quantified, and prioritized
compliance items that the IT endeavor must address. Configuration Management Framework
Also includes any compliance requirements for which (From: A541, To: A542 A543 A544 A545 A546 A551)
noncompliance has been assessed, with decision The information and artifacts which represent the
reasons and analysis of likely consequences. purposes of the process and the means by which the
process will operate to satisfy them.
•
•
•
Consolidated Business Demand Baselines and Forecasts – Customer Output
Consolidated Business Demand Baselines and Customer charges or invoices describe how much a
Forecasts customer is being charged or billed for the usage of IT in
(From: A25) a certain period of time.
Agreed statement of the combination of the expected
business demand for the normal (typical) pattern of Customer Directions and Intentions
business, and of the future predictions of business (To: A22 A225 A26 A263)
demand for IT service, usually arranged by periods Information from customers, whether expressly or
against a standard calendar. implicitly stated within other communications, which
indicates the customers' strategies, plans, wish lists, or
Consumables Order other intentions on the subject of IT service.
(From: A623)
An order for materials used up in the process of Customer Input
providing agreed-to services. Materials like paper, (From: Outside-the-Model, To: A2 A8)
magnetic tape, printer toner or ribbons, and others are Interactions from any customer of IT to any IT process
included. related to any aspect of the life cycle related to the
establishment and performance of the IT product; that is,
Consumption Data the services and solutions. The interactions include:
(From: A625) – Needs and requirements
Usage statistics for consumable supplies reported with – Contracting for IT services
each use and intended to be the basic information that – Establishing service level targets, and reviewing
would lead the IT organization to know when achievement against those targets
consumables are nearing depletion so the material can – Participation in testing and other acceptance
be re-supplied without disruption to processing. activities
Continuity Notification – Payments
(To: A766) – Satisfaction input
An urgent, formal command to invoke the IT Service
Continuity Plan. Customer Inputs to Sales Transactions
(To: A22 A226 A227)
Contract Exceptions Customer wants, needs, or general requests around a
(From: A823, To: A822) specific sales opportunity.
Exceptions or non-compliance of contracts that are
recognized during Manage Supplier Contracts, and that Customer Issue Feedback
are needed as input for Manage Portfolio of Suppliers, so (To: A27 A274)
that the supplier portfolio can be adapted if necessary. The responses and other feedback from the customer
providing more information into the issue they have
Contract Requirements expressed and into their perception on the success or
(From: A82 A823) otherwise of attempts to address open issues.
Contract requirements for communication to, and
negotiation with, suppliers. The requirements cover Customer Needs
items such as specifications, quantities, delivery dates, (To: A21 A212)
desired terms and conditions, maximum price. An expression in the customer's terms of their wants,
needs, and aspirations for IT service, in both functional
Cost Data and non-functional ways.
(From: A81 A815, To: A816 A83 A832)
Describes the cost aligned with defined criteria. Typical Customer Organization
criteria: by service, by customer, and by cost unit. (To: A22 A223 A225 A23 A232 A24 A242 A27 A271)
Information about the organization of each customer.
Costing and Charging Request This will include organizational structure details and, in
(From: A744, To: A833) particular, identify the positions and individuals who are
An inquiry about (or an estimate of) the cost or charge stakeholders in each service.
related to a particular IT service or cluster of services.
Customer Output
Current Business Climate (From: A2 A8, To: Outside-the-Model)
(To: A26 A262 A263) The interactions from the collective IT undertaking to any
Information about the state of the customer's business. IT customer, in connection with any aspect of the life
Includes business metrics and projections directly cycle related to the establishment and performance of
relating to the customer as well as directional statements the IT product; that is, the services and solutions. The
such as press releases, annual reports, and other interactions include:
articles. – Validation of requirements
– Marketing and sales materials, such as proposals
Customer Charges or Invoices – Service level agreement life cycle
(From: A81 A815, To: A814 A816)
– Invoices for services rendered
– Any aspect of customer satisfaction
•
•
•
Customer Payment – Data Lifecycle Management Plan
Customer Payment Customer Satisfaction Issue Resolution Directives

(To: A81 A814) (From: A274, To: A276)
Customer payment describes the incoming cash flow Instructions or requests to any IT process for the
(real or virtual) from a customer. It is either the resolution of a customer satisfaction issue, under the
information about a customer payment (from the coordination of an overall issue resolution plan.
business' accounts receivable process) or could be the
actual payment. Customer Satisfaction Issue Resolution Response
(To: A274)
Customer Profiles Responses from any IT process to directives for the
(From: A22 A228, To: A225 A26 A262 A27 A271) resolution of a customer satisfaction issue. Examples of
The body of knowledge about each customer as a result responses would be action plans, and action outcomes.
from marketing and sales activities.
Customer Satisfaction Management Activity Data
Customer Review Input (From: A272 A273 A274 A275 A276, To: A277)
(To: A24 A245 A246) Data resulting from all work carried out by each process
Any feedback from the customer with regard to service activity. Examples would be volumes, timings, resources
levels and their attainment, including their prioritization of used, success and error rates, interfaces invoked,
improvement suggestions. rework, customer feedback, priorities.
Customer Satisfaction Analysis Customer Satisfaction Management Evaluation
(From: A273, To: A274 A275 A276) (From: A277, To: A271)
The results of analyzing customer satisfaction data, and An assessment of the overall performance of the process
including trends and implicit issues. against the targets set in the process framework and an
Customer Satisfaction Data_ Solicited
(From: A272, To: A273 A275) Customer Satisfaction Patterns
Data obtained from service provider initiated collection of (From: A275, To: A276)
satisfaction data. Examples would include forms put in Identification of patterns of satisfaction which might
front of users after system interactions, regular review require attention from the IT service provider before the
meetings between customer and provider. dissatisfaction occurs.
Customer Satisfaction Data_ Unsolicited Customer Satisfaction Results and Trends
(From: A272, To: A273 A275) (From: A27 A276, To: A13 A131 A14 A141 A22 A222
Any feedback, typically ad hoc and unprompted, from a A23 A236 A24 A244 A25 A253 A356 A365 A525
customer that expresses their level of satisfaction with A526)
any aspect of the IT service provision. A report summarizing current customer satisfaction
results and historical data. Can be used to identify
Customer Satisfaction Framework trends.
(From: A271, To: A272 A273 A274 A275 A276 A277)
The conceptional structure describing the strategic Customer Satisfaction Targets
(vision, mission, value proposition), organizational (From: A271, To: A273 A276 A277)
(organizational mechanisms, roles, accountabilities), The targets (goals) for customer satisfaction against
process (activities, work flows, inputs, outputs), and which the actual customer results will be measured.
technology (software, hardware) practices for managing
customer satisfaction. Customer Selling Information
(From: A225, To: A222 A226 A227)
Customer Satisfaction Input General data on the customer such as contact name,
(To: A27 A272) address, position title, organization name, customer
Feedback (solicited or unsolicited) from customers number, and more.
regarding IT performance. This is used to measure and
manage customer satisfaction issues and trends.
D
Customer Satisfaction Issue
(From: A24 A245 A53 A537 A61 A613 A615, To: A27 Data
A274) (From: A63 A634, To: A62 A623 A635 A636)
Any determination of a customer satisfaction issue. Can All the data items which are being managed within the IT
be either direct form a customer, or prompted by any IT endeavor, and which are made available for processing
staff member in carrying out other processes. or other purposes in line with service commitments.
Customer Satisfaction Issue Communications Data Lifecycle Management Plan

(From: A27 A274, To: A276 A614 A615) (From: A632, To: A633 A634 A635 A636 A637)
Information provided to customers about any aspect of a The specification of the life cycle management plan for
satisfaction issue, covering analysis of causes, each class or type of data, allowing for the possibility that
committed plans to address, and progress to issue an individual collection of data could have unique life
resolution.
•
•
- 10 • IBM Process Reference Model for IT (PRM-IT Version 3.0) ©Copyright IBM Corp. 2008
•
Data Lifecycle Request – Delivery Resources_ Released
cycle management requirements. The life cycle plan will Data_ Derived
cover aspects such as: (From: A62 A624, To: A63 A634)
– Media types to be used, for each activity level of data Any informational item created or modified as part of the
(such as currency) workings of any business process and which is to be
– Archive parameters managed within an IT service. Data could be specific
– Backup plan information like order numbers, invoice numbers,
– Selection of data sensitivity classification receipts, inventory change data, and could be received in
batches or in individual transactions. It can relate to
Data Lifecycle Request business processes, or be relevant to the management
(From: A62 A622, To: A63 A632 A634 A636) of the IT endeavor.
The identification of any need for a life cycle Data_ Disposed
management action of any data item as part of (From: A636)
The data that has been taken out of active management.
Data Management Activity Data Depending on how it has been stored, it can include the
(From: A632 A633 A634 A635 A636 A637, To: A638) associated media; for example, paper or microfiche
Data resulting from all work carried out by each process records.
activity. Examples would be volumes, timings, resources Data_ External
used, success and error rates, interfaces invoked, (To: A633)
rework, customer feedback, priorities.
Data sourced and obtained from outside the current
Data Management Evaluation service coverage. Examples of this would include:
(From: A638, To: A631) – Reference data, from external providers, such as
An assessment of the overall performance of the process postal coding schemes
against the targets set in the process framework and an – Transaction data from external partners, such as
identification of possible process improvement areas. banks.
Data Management Framework Data_ Prepared

(From: A631, To: A633 A634 A635 A636 A637 A638) (From: A633, To: A634)
The Data Management Framework guides the operation Data that has been collected (acquired) and prepared
of the process, and includes the following information: (filtered, grouped, reordered, rearranged) to match the
– Classes of data (relevant for data management, to planned usage. Prepared data is ready to be placed
indicate factors such as backup scope and (deployed) onto its target media and managed
frequency) throughout its life cycle.
– Data life cycle models Data_ Restored
– General approach to what storage media types will (From: A635, To: A634)
be used for which classes of data Availability of data for productive or other use as a result
– Instructions for data retention that implement of restoring it.
Corporate policies and controls (which themselves
include the impact of regulatory requirements) Deallocated Assets
– Capacity Management plans that affect Data (From: A535, To: A552)
Management Assets that are no longer deployed to specific owners.
– Data Management requirements based on existing These assets are free to be allocated to new owners.
SLAs
– High-level plans for improvement Delivery Resources
(To: A623)
Data Management Metric Data and Reports Technological and people resources which can be
(From: A63 A637, To: A632 A634) utilized in the process of delivering IT services to the
Significant event logs, volume and other measurement organization.
data relating to how effectively and efficiently data and
storage work has been performed. This data, which is Delivery Resources_ Assigned
available as requested both in raw format and as (From: A623, To: A624)
structured reports, is a component of all Operations All IT resources required and available to perform the
Information and is a basis for service level reporting. required service.
Data Resource Catalog Delivery Resources_ Recovered

(From: A634, To: A635 A636) (To: A623)
The master record of the location and disposition of Any IT delivery resources which have been restored to
every data collection under data management. normal (or acceptable) operational capability as a result
Depending on the policy choices as specified within the of incident resolution.
framework, it can include usage records such as space
employed and lists of users (people, programs) by time Delivery Resources_ Released
and date. (From: A624, To: A623)
•
•
©Copyright IBM Corp. 2008 IBM Process Reference Model for IT (PRM-IT Version 3.0) • - 11
•
Demand Management Activity Data – Deployment Rework Need
Resources (tapes, storage devices, networks, LANS, A539)

programs, data stores, processors, memory) that have Data resulting from all work carried out by each process
been used in the process of performing operational activity. Examples would be volumes, timings, resources
services but are now available for re-assignment to other used, success and error rates, interfaces invoked,
work. rework, customer feedback, priorities.
Demand Management Activity Data Deployment Management Evaluation
(From: A252 A253 A254 A255 A256, To: A257) (From: A539, To: A531)
Data resulting from all work carried out by each process An analysis of deployment management activity data
activity. Examples would be volumes, timings, resources providing an understanding of the current success or
used, success and error rates, interfaces invoked, failure of the deployment management process, and an
rework, customer feedback, priorities. identification of potential process improvements.
Demand Management Evaluation Deployment Management Framework
(From: A257, To: A251) (From: A531, To: A532 A533 A534 A535 A536 A537
An analysis of activity data for Demand Management, A538 A539)
providing an understanding of the current success or This framework describes the policies, procedures,
failure of the process, and an identification of potential organizational roles and responsibilities, and other
process improvements. information under which the Deployment Management
process will operate to meet its mission and goals.
Demand Management Framework
This framework provides governance information for the
(From: A251, To: A252 A253 A255 A256 A257)
other activities in Deployment Management.
The set of structures describing the strategic (vision,
This framework provides governance information for the
mission, value proposition), organizational
other activities in Deployment Management.
(organizational mechanisms, roles, accountabilities),
process (activities, work flows, inputs, outputs), and Deployment Program Plan
technology (software, hardware) practices for managing (From: A532, To: A533 A534 A535 A536 A537 A538)
demand. The set of plans for achieving the deployment of an
Demand Management Outcomes Report identified set of information technology capabilities.
(From: A256, To: A252 A253 A255) Items covered include:
Information about the success (or otherwise) of the – Specification of coordinated deployment tasks and
Demand Management activities across several aspects: procedures to move new or changed hardware,
software, documentation, process, etc. to the target
– Representing business demand in IT service
environment
consumption units
– Rollout timetables for deployments that are repeated,
– Identifying supply and demand gaps
and associated logistical plans
– Recommending interventions to realign demand to
– Identifying personnel resources necessary to achieve
match supply
each deployment event, and obtaining commitments
Deployed Workforce for their availability
(From: A843) The deployment program will cover aspects such as
Current IT human resource allocations. locations, target systems, dates, persons affected (both
users and IT service provider staff), required
Deployment Capabilities communications, and training plan.
(From: A533, To: A534 A535 A536)
Deployment Records
Combination of knowledge, skills, experience,
(From: A532 A533 A534 A535 A536 A537, To: A538)
processes, systems and technologies required to deploy
new or changed deployment objects into the target A set of records containing the details of each
environment. deployment program and each deployment instance
within that program.
Deployment Items
(From: A534, To: A535) Deployment Reports
(From: A538, To: A518 A525 A526 A532)
The collection of items that are ready for deployment and
for which all title and ownership information reflects the Report about how well deployments are progressing or
imminent deployment into the target environment. These have been completed.
items are instances of what ITIL calls Service Assets,
Deployment Rework Need
defined as “Any Capability or Resource of a Service
(From: A536, To: A534 A535)
Provider.” 4 The identification that any parts of the deployment plan
Deployment Management Activity Data need to be reworked prior to the capability reaching full
(From: A532 A533 A534 A535 A536 A537 A538, To: service status. Everyday changes in business operations
within the organization that is the target of deployment
can be the cause of such a need. For example, changes
in staff since plan creation.
4. ITIL V3 Glossary
•
•
•
Disposal Notification – External Benchmarks
Disposal Notification – Practices for logging and filtering events

(From: A636, To: A634) – Definition of the event life cycle
Notification that one or more collections of data have
been disposed of and are no longer accessible. Event Resolution Directive
(From: A64 A645, To: A62 A622 A623 A624 A63 A634
A635)
E The set of commands or instructions to resource
controlling activities which have been selected so that
Environment Information the event causing conditions will be resolved.
(From: Outside-the-Model, To: A1 A2 A3 A5 A7 A8)
General knowledge that exists relative to the business' Event_ Closed
primary overall industry segments and the IT industry, (From: A646)
such as: The event audit trail and life cycle with the addition of any
– Business information information from the event closure activity.
– Technical information
Event_ Derived
– Government information
(From: A644, To: A642)
Event A new event created as a result of correlation across
(From: A64 A642, To: A643 A65 A654 A66 A662) multiple events, usually signifying some new out-of-
Details of individual and collective events. They are tolerance conditions requiring action.
available to any Service Management process for
Event_ Escalated
investigation, diagnosis and other analytical purposes on
(From: A644, To: A643)
a real-time or historical basis.
An event, or set of events, that requires re-examination
ITIL defines Alert as: “A change of state which has
and filtering as a result of event processing or
significance for the management of a Configuration Item
correlation. This is typically indicated by increasing the
or IT Service. The term Event is also used to mean an
priority classification.
Alert or notification created by any IT Service,
Configuration Item or Monitoring tool. Events typically Event_ Processed
require IT Operations personnel to take actions, and (From: A644, To: A645)
often lead to Incidents being logged.” 5 An event which has been analyzed for cause of out-of-
tolerance conditions and led to its creation for which a
Event Analysis Updates plan, within the scope of Event Management, has been
(To: A642 A646) formulated to resolve those conditions.
Any additional data added to (but not modifying) the
primary data of a logged event as a result of other IT Event_ Ready for Closure
processes carrying out their investigations. Examples of (From: A644 A645, To: A646)
such processes would be Incident, Capacity and The complete audit trail of an event and all states of
Availability Management. processing through its life cycle.
Event Management Activity Data Event_ Significant
Data resulting from all work carried out by each process Unsolicited, (formatted), significant information which
activity. Examples would be volumes, timings, resources must be communicated from a managed object for the
used, success and error rates, interfaces invoked, purpose of meeting a management objective.
rework, customer (of this process) feedback, priorities. An Alert is an example of a significant event. It is defined
Event Management Evaluation by ITIL as: “A warning that a threshold has been
(From: A647, To: A641) reached, something has changed, or a Failure has
occurred. Alerts are often created and managed by
An assessment of the overall performance of the process System Management tools and are managed by the
against the targets set in the process framework and an
identification of possible process improvement areas. Event Management Process.” 6
Event Management Framework Existing Test Cases

(From: A641, To: A642 A643 A644 A645 A646 A647) (To: A442)
Includes the following: Any relevant, previously-defined and exercised test case
that is identified as relevant to the particular solution for
– Specification of what makes an event
which testing is being planned. These test cases are
– Specification of what makes a significant event managed under the Knowledge Management process.
– Identification of significant events that can be
processed (responded to), and what those External Benchmarks
procedures are (To: A14 A142)
•
•
•
External Models and Practices – Financial Management Activity Data
A representation of the effectiveness, efficiency or other Information about the facility incident life cycle and
metric of the workings of a survey or other sample group outcome, including:
of businesses or functions within them. – Notification to the requestor that the request was
addressed
– Feedback to any relevant IT processes, such as
(To: A11 A111 A113 A114 A12 A121 A122 A123 A124
supplier management, workforce management,
A125 A126)
financial management
External information from the industry (from individual
enterprises, from academia and from industry watchers) Facility Request
describing models, practices and trends in IT (From: A752, To: A753)
management system topics. A request for Facility changes that conform to the
framework or the plans for the facility.
External Workforce Frameworks and Practices
(To: A841) Facility Request Exceptions
Relevant models, designs and operational (From: A753, To: A752)
characteristics of workforce management approaches in This is an ad hoc request that does not conform to the
peer businesses which could provide a basis for this IT current plans, but is within the overall remit of the facility
Service Provider's Workforce Management Framework. framework. It can potentially be addressed by some
additional facility planning.
F Facility Request Fulfillment Plan
(From: A753, To: A754)
Facilities Management Activity Data
(From: A752 A753 A754, To: A755) The plan (instructions, specifications) for the fulfillment of
the facility request using normal facility operation or
Data resulting from all work carried out by each process
maintenance.
activity. Examples would be volumes, timings, resources
used, success and error rates, interfaces invoked, Facility Request Response
rework, customer feedback, priorities. (From: A753)
Facilities Management Evaluation The fulfillment of the Facility Request and information
(From: A755, To: A751) about it, including:
An assessment of the overall performance of the process – Description of the request
against the targets set in the process framework and an – Notification to the requestor as to how the request
identification of possible process improvement areas. was addressed
– Updates to CI information and asset information.
Facilities Management Framework
(From: A751, To: A752 A753 A754 A755) Facility Request_ Qualified
The policies, guidelines, plans, procedures and targets (From: A754, To: A753)
for the workings of the Facilities Management process. A need for a facility request to be re-planned as a result
of an operation or maintenance activity producing a
Facilities Plans and Specifications result out of line with the plan.
(From: A75 A752, To: A72 A723 A726 A73 A737 A74
A745 A753 A754 A76 A764) Feasibility Guidance
Specifications, designs and plans for the IT facilities to (To: A213)
support the provision of IT service. Could be either or both of:
– A mechanism to evaluate and qualify customer
Facilities Procedures and Schedules needs
(From: A752, To: A754) – A feasibility report on a specific set of expressed
Documentation on facilities procedures, facilities potential requirements
availability, and use of facility infrastructure for IT and the
user community. This information is available to Feasibility Request
Knowledge Management, for it to determine which parts (From: A213)
(if any) are needed to be available to the IT processes. A request which expresses the desire to qualify a
customer need using a structured needs evaluation
Facility Incident framework. This request could be handled by many
(To: A754) processes, including IT Portfolio Management, IT
An external event resulting in a real or suspected failure Research and Innovation, Solution Requirements,
of one or many components of the facility, and the related Solution Analysis and Design.
notification and information about the incident.
– Facility incidents might be handled separately (for Financial Management Activity Data
example, by the business) from the IT Incident (From: A812 A813 A814 A815 A816, To: A817)
Management process. Any data about the correct accomplishment and of
process activities that support the evaluation of the
Facility Incident_ Closed overall Financial Management process (includes data
(From: A754) gathered for legal reasons or for fraud detection).
•
•
•
Financial Management Evaluation – Identity Request
Financial Management Evaluation and Access Management process framework. It includes

(From: A817, To: A811) identification of potential process improvement items.
A report describing the performance against the process This may also include proposed modifications to the
quality measures, legal requirements, and fraud Identity and Access Management Framework.
detection.
Identity and Access Management Framework
Financial Management Framework (From: A671, To: A672 A673 A674 A675 A676)
(From: A811, To: A812 A813 A814 A815 A816 A817 The policies, guidelines, plans, procedures,
A831) organizational roles and responsibilities and other
The overall strategy and definition for financial information under which the Identity and Access
management, such as the procedural, organizational Management process will operate to meet its mission
and other management mechanisms through which the and goals.
– Strategic goals for the management of IT finances
(From: A67 A673 A674, To: A64 A642 A675 A727)
– Policies and orientation that apply to operating the
Data produced during or about the processing performed
various aspects of IT finances
against identities and access right records. In addition to
– Collection of evaluation criteria for qualifying and item-by-item outcomes, the data can include
assessing the financial aspects of any investment measurements of resource utilization, transaction
under consideration volumes, processing status, among others.
H Identity and Access Reports

(From: A675)
Human Resource Adjustment These reports contain a summary of identity and access
(To: A843) records, and the amount and type of identity and access
The flow of acquired, realigned, and released human transaction completed (additions, changes, deletions) in
resources which represents the workforce available for a given time frame.
deployment. Identity and Access Request
(To: A672)
I Service Request to create or modify an identity record
for a user and to provide access to systems, data and
Identified CIs applications.
(From: A542, To: A543)
The set of CI types, with details of their: Identity and Access Response
(From: A673 A674, To: A535 A624)
– Attributes
The result of processing an identity and access request.
– Relationships The result will reflect a range of possibilities, depending
– Structures in which they are expected to participate on the nature of the request:
Identified Risks – For an identity request – actions taken to create,
(From: A342, To: A343 A722) maintain, or delete the identity
Areas in the business where there is a potential for – For an access (rights) request – the success or
realization of unwanted, adverse consequences if an failure of the request, with relevant information
event or a given set of events occurs. describing the status of access rights
Identity and Access Directives Identity and Access Rights Register

(From: A675, To: A673 A674) (From: A6 A67 A673 A674, To: A674 A675 A7 A72
A726 A727 A75 A754)
Individual or collective commands, instructions or other
requests to modify or adjust identities or the access The records that provide the current (and perhaps
rights register. Such directives are usually the result of historical) values for identities and for access rights. This
monitoring patterns of identity and access behavior as collective register is generated by actions related to
well as from security monitoring data. identity life cycle management (enrollment, provisioning
and user self-care), identity controls (access and privacy
Identity and Access Management Activity Data controls, single sign-on), identity federation (sharing user
(From: A672 A673 A674 A675, To: A676) authentication and attribute information between trusted
Data resulting from all work carried out by each process Web services applications), and identity foundation
activity. Examples would be resources used, success services (directory and workflow).
and error rates, interfaces invoked, rework, customer
Identity and Access Work Request
feedback, priorities.
(From: A535 A62 A624, To: A67)
Identity and Access Management Evaluation An identity and access request originating from another
(From: A676, To: A671) process.
An assessment of the overall performance of the process
Identity Request
and of its activities against the targets set in the Identity
(From: A672, To: A673)
•
•
•
Implementation Progress Data – Industry Risk Threats and Vulnerabilities
A form of Service Request to enroll, provision or change An incident that has been assigned a classification. The
a given user's identity characteristics and which classification helps narrow the realm of possibilities for
evaluated, verified and accepted for processing. resolving the incident. For instance, the classification can
be based on platform, type of problem, component, or
Implementation Progress Data other information.
(From: A375 A52 A523 A524 A53 A535 A536 A635,
To: A51 A516 A537) Incident_ Closed
The record of each incremental activity performed as (From: A656, To: A657)
part of the implementation of a change or release. The finalization of all data related to an incident,
including structured data which supports analysis of
Incident incident causes, patterns, costs and resolution
(From: A2 A27 A273 A5 A51 A516 A53 A536 A61 effectiveness.
A613 A62 A625 A63 A637 A64 A644 A646 A67 A675
A7 A72 A75 A754, To: A537 A6 A65 A652) Incident_ Logged
A fault in IT service and infrastructure that has been (From: A652, To: A653 A657)
reported, or an event that could cause an interruption to An identified incident that has been saved in a database.
one or more services. Incidents can be created using
either manual or automated mechanisms. An incident Incident_ Needing Reclassification
reported by a user begins as a service request and (From: A654 A657, To: A653)
becomes an incident once it is determined that a fault is An incident that requires to be moved to a different
being reported. classification, perhaps to a different team.
Incident Communication to User Incident_ Resolution Plan

(From: A656 A657) (From: A653 A654, To: A655 A657)
Communications to a user about the status or progress An incident for which a resolution plan has been created
of an incident. Could be to provide status information or or obtained. Subsequently (and beyond this activity), the
to solicit additional data or request some user action as resolution plan has to be applied and the outcome
part of diagnosis. verified with the user.
Incident Information Incident_ Resolution Unsuccessful

(From: A6 A65 A657, To: A2 A24 A244 A61 A613 A615 (From: A655, To: A653)
A652 A653 A654 A655 A656 A66 A662 A7 A72 A726 An incident for which a workaround or fix was not
A73 A736 A74 A744 A75 A754) provided or was unsuccessful. Normally, an incident
Information about one or more incidents. Can range from should eventually yield a workaround or a fix for that
full details of an individual incident through collated and incident. However, in some situations, no workaround or
summarized information about sets of incidents. fix works to resolve the incident.
Incident Management Activity Data Incident_ Resolved

(From: A652 A653 A654 A655 A656 A657, To: A658) (From: A65 A655, To: A62 A656 A657)
Data resulting from all work carried out by each process An incident for which a workaround or fix has been
activity. Examples would be volumes, timings, resources successfully applied.
rework, customer feedback, priorities. Individual IT Process Activity Data
(To: A813 A814 A815)
Incident Management Evaluation (From every process) All defined process based
(From: A658, To: A651) measures (usage data) aligned with services and
An analysis of how well the Incident Management activities from which relevant financial values can be
process was performed. This can also include suggested extracted or derived.
areas for modifications to the Incident Management
Framework. Individual Process Evaluations
(To: A14 A141 A346 A716)
Incident Management Framework A collection of metrics which describe the effectiveness
(From: A651, To: A652 A653 A654 A655 A656 A657 and efficiency of an individual process.
A658)
The set of policies and procedures for performing the Industry Models and Standards
Incident Management process, including data items such (To: A33 A332 A333)
as: From the industry segment of the business and from the
– Priority and severity classification schemes IT industry itself:
– Resolution targets – Models of ways of operating and design
– Tables identifying teams to be assigned, by system or – Formal and informal standards that must be
service considered in any architectural work
Incident_ Classified Industry Risk Threats and Vulnerabilities

(From: A653, To: A654 A657) (To: A76 A762)
•
•
•
Information About Suppliers – IT Customer Capability Adoption Interventions
Known risks, threats and vulnerabilities which exist from The planned IT funding broken down in relevant ways,
other organizations in the same business sector, and such as activities and milestones per period, to reflect
environmental risk. the contents of the IT plan.
Information About Suppliers IT Business Contribution and Capabilities
(To: A822 A825) (From: A3)
Any information about potential suppliers that supports Information to the business on the products of IT (the
the selection and evaluation process for suppliers, services and solutions), on the status of the IT assets
including: and infrastructure employed in the delivery of the IT
– Analyst reports and opinions products, and on the contribution (value) to the business
– Benchmark data which the IT product makes.
– Customer references IT Business Value Potential
– Financial information (From: A31 A313, To: A312)
– Current relationship information Statement of potential technology impact on the
– Other publicly available information. business strategy, stated in terms of added value, time
scales, potential investment costs and business change
Information Asset Security Classification assessment.
(From: A724, To: A725)
The level of protection to be established and operated IT Business Value Report
against each category of information assets. It includes: (From: A36 A367)
– Identification of ownership requirements The contribution to the business from an information
– Handling and labeling procedures technology investment, usually expressed in economic
terms.
(To: A82 A822 A823 A825) IT Capability Outlines
Any information that the suppliers can provide about (From: A31 A313, To: A314 A33 A332)
themselves that supports the selection and evaluation A specification of the desired capabilities of the IT entity,
process for suppliers, including: stated in a way that is independent to specific
– Responses to RFIs, RFPs implementations of its services, processes, people,
tools, organization, and technology. Capabilities should
– Vendor briefings
be stated in a consistent form, as in “the ability to
– Financial information perform service X within the specified service level Y.”
– Portfolio information.
IT Control Results
Infrastructure Needs (From: A13 A132, To: A131 A133 A14 A141)
(To: A212) An indication of the direct outcomes, and any associated
Conditions where a gap in the current infrastructure consequences that result from the application of any IT
exists and requires assistance to be filled. management controls.
(Includes input such as security requirements from
Security Management.) IT Customer Benefit Realization Report
(From: A26 A266, To: A263)
Integrated Work Schedule A report describing the benefits realized by the customer
(From: A622, To: A623 A624) from the adoption of transformational capabilities.
A consolidation of all individual work item schedules Different types of reports are possible, including:
(planned out sequence of work) based on resources, – Timetable for changes in realized benefit (typically as
commitments, skills and available services. penetration advances)
IT Administration Support Data and Requests – Comparison of actual against plan
(From: A62) – Indication and analysis of missed or additional
Covers requests for supply of new or additional benefit exploitation opportunities
consumable materials and relevant data reporting on IT Customer Capability Adoption Events
consumption and usage of the consumables (tapes, (To: A26 A265)
paper, toner, forms, and others), which might be required
Notable milestones (both successes and failures) in the
for charging.
customer's adoption of transformational capability.
IT Budget
(From: A8 A81 A813, To: A1 A12 A121 A123 A125 A13
(From: A26 A265)
A131 A132 A133 A14 A142 A2 A22 A221 A23 A233
A24 A241 A243 A26 A261 A3 A31 A314 A32 A321 Any actions or efforts designed to promote the adoption
A33 A331 A35 A353 A36 A365 A5 A53 A532 A55 of transformational capabilities. Examples of such
A551 A7 A75 A752 A812 A814 A816 A82 A821 A84 interventions include:
A842 A843 A844) – Communications
– Training programs
•
•
•
IT Customer Capability Adoption Plan – IT Governance and Management System Results
– General consultancy and assistance into better, IT Financial Audit Reports

deeper or broader usage of the capability (From: A816, To: A143 A811 A817)
Financial audits include validation that accounting rules
IT Customer Capability Adoption Plan are being accurately followed and that costs are aligned
(From: A26 A265, To: A266) with the engagement and client objectives.
The overall plan for enabling and promoting capability
adoption. This ranges from customer-wide items such as IT Financial Modeling Analysis
general awareness and communications through training (From: A812, To: A226 A255 A264 A352 A422 A813
programs customized to local needs and possibly the A814 A815 A823 A824)
provision of individual guidance and consultancy. The outcome of the request for modeling the financial
implications of any aspect of the IT undertakings.
IT Customer Capability Enabling Requirements
(From: A265, To: A264) IT Financial Modeling Request
Statement of requirements for additional or modified (From: A226 A255 A264 A352 A422 A823 A824, To:
materials, training, and communication programs, and A812)
other enablers that enhance the rate and degree of A request for financial modeling to be performed so that
adoption of transformational capabilities. the financial implications of a potential proposal relating
to IT resources and capabilities can be understood. Any
IT Customer Context process can originate this type of request.
(From: A262, To: A263)
A digest summarizing and analyzing the customer's IT Financial Reports
business activities and the key business drivers and (From: A8 A81 A813 A814 A815, To: A1 A13 A131 A14
imperatives which influence the direction of that A141 A3 A36 A365 A366 A5 A55 A555 A6 A66 A661
business. Includes consideration of the main uses of A816 A82 A822 A824 A825)
information technology within that business and in All reports on financial data of IT for different
comparison with industry competitors and leaders. stakeholders. Covers a wide range of reports from
outlining projected costs through after-the-fact financial
IT Customer Transformation Candidates analyses.
(From: A263, To: A264)
A list of possible transformational opportunity areas for IT Function Information and Interests
the customer. It will usually be categorized against key (To: Outside-the-Model)
business drivers. Any information about the workings - such as current
capabilities and future directions - which the IT endeavor
IT Customer Transformation Management Activity makes available to the industry at large.
Data
(From: A262 A263 A264 A265 A266, To: A267) IT Governance and Management Audit Request
Data resulting from all work carried out by each process (To: A143)
activity. Examples would be volumes, timings, resources Invocation of an audit of all or part of the IT Governance
used, success and error rates, interfaces invoked, and Management System by a suitably authorized
rework, customer feedback, priorities. person or body. Also contains the terms of reference for
the audit.
IT Customer Transformation Management Evaluation
(From: A267, To: A261) IT Governance and Management Audit Results
An assessment of the overall performance of the process (From: A14 A143, To: A11 A111 A12 A121 A144)
against the targets set in the process framework and an The findings, conclusions and recommendations of any
identification of possible process improvement areas. audit (formal or informal, internal or external) carried out
into any or all of the IT Governance and Management
IT Customer Transformation Management System.
Framework
(From: A261, To: A262 A263 A264 A265 A266 A267) IT Governance and Management System Evaluation
The conceptional structure describing the strategic (From: A14 A144, To: A11 A113 A114 A12 A121 A122
(vision, mission, value proposition), organizational A123 A124 A125 A126)
(organizational mechanisms, roles, accountabilities), An assessment of the overall performance of the IT
process (activities, work flows, inputs, outputs), and Management and Governance System against the
technology (software, hardware) practices for managing targets set in the IT Management System Framework
customer transformation. and in the IT Governance Model, and an identification of
possible process improvement areas.
IT Customer Transformation Themes and Evaluation
Principles IT Governance and Management System Results
(From: A26 A263, To: A264 A265 A266 A312 A363) (From: A1, To: Outside-the-Model)
A statement of the general headings under a customer's A stakeholder report of the IT Management System's
business operations that might be transformed together outcomes, effectiveness and efficiency, and other key
with a set of evaluation principles which can be used to performance indicators, such as the quality results.
prioritize alternative transformation candidates.
•
•
•
IT Governance Capabilities – IT Measurement and Control Capabilities
IT Governance Capabilities implementation, and all their interrelationships in the unit

(From: A12 A121, To: A122 A123 A124 A125 A126 of space that is the domain of the IT function. Its
A13 A131 A132 A133 A14 A141 A142 A143 A144) fundamental purpose is to provide an environment that is
The set of instruments that contribute the required supportive of the carrying out of all of the IT activities
governance characteristics to the overall IT Management defined elsewhere in this model.
Ecosystem. These will include:
IT Management Information Capabilities
– Governance structures and charters
(From: A124, To: A121 A122 A123 A125 A126)
– Decision rights and their assignment to roles
The informational aspects of the capabilities the IT
– Decision-making processes and procedures for a function will be managed. These include the
specified list of decisions specification of the entities, attributes, and relationships
– Metrics and indicators for the aspects of IT of IT management information, both for the fundamental
management under governance resources (such as hardware) and for the control
IT Governance Framework
(From: A11 A111, To: A112 A113 A114 A12 A121 A14 IT Management System Capabilities
A142 A143) (From: A12, To: A13 A131 A132 A133 A14 A141 A142
The guiding principles, the statements of intent, and the A143 A144)
objectives that together shape and set the direction for The foundational constituents of the IT Management
the implementation of IT governance. Ecosystem. The elements explicitly identified are:
IT Industry Knowledge – Process
(From: A22 A228, To: A21 A213) – Organization
Information about the IT industry (in general) and – Management information
competitive IT service providers (in particular) which has – Tools and systems
been created as a by-product of marketing and sales – Measurement and control instruments
activities.
IT Management System Framework
IT Management Action Items (From: A11, To: A12 A122 A123 A124 A125 A126 A13
(From: A13 A132) A132 A133 A14 A142 A143)
The invoked actions designed to keep the operation of The logical structure describing the strategic (vision,
the overall IT management system within established mission, value proposition, guiding principles),
tolerances, or in exceptional circumstances, to return it to organizational (organizational mechanisms, roles,
being within those tolerances. Action items can include accountabilities), process (activities, work flows, inputs,
anything from directives and instructions through general outputs), and technology (software, hardware) goals,
guidance and suggestions. policies and practices for managing the overall IT
function.
IT Management and Governance System
Performance Analysis IT Management System Goals
(From: A142, To: A143 A144) (From: A112, To: A111 A113 A114)
Conclusions on the effectiveness (strengths, Statements of purpose to direct the management system
improvement areas) of the IT Management and of the IT endeavor, and which reflect and support the
Governance System. overall goals of the Business.
IT Management Control Items IT Management System Policies

(From: A131, To: A132) (From: A113, To: A111 A114)
The identification of IT management system High-level courses of action and guiding principles for
measurements that are approaching or exceeding the IT function that are required in order for it to achieve
established limits which indicate a potential need for its goals.
overall management system intervention.
IT Management System Practices
IT Management Ecosystem (From: A114, To: A111)
(From: A1, To: A2 A21 A211 A22 A221 A23 A231 A24 High-level practices that have been defined in detail for
A241 A25 A251 A26 A261 A27 A271 A3 A31 A311 the management system of the IT endeavor. Once these
A32 A321 A33 A331 A34 A341 A342 A343 A35 A351 have been put in place (that is, made operational), they
A36 A361 A37 A371 A4 A41 A411 A42 A421 A43 represent an implementation of the policies.
A431 A44 A441 A45 A451 A5 A51 A511 A52 A521
A53 A531 A54 A541 A55 A551 A6 A61 A611 A62 IT Management System Reports
A621 A63 A631 A64 A641 A65 A651 A66 A661 A67 (From: A13 A133, To: A14 A141)
A671 A7 A71 A711 A712 A713 A72 A721 A73 A731 The results and interpretations of the IT Management
A74 A741 A75 A751 A76 A761 A8 A81 A811 A82 System outcomes, including key performance indicators.
A821 A83 A831 A84 A841 A85 A851)
To paraphrase a dictionary definition: the complex of IT Measurement and Control Capabilities
management system elements, their physical (From: A126)
•
•
•
IT Measurements – IT Quality Management Practices
Capabilities to provide the appropriate measurements IT Portfolio Categories

and controls to the IT function's undertakings. Examples (From: A363, To: A364 A366 A367)
include: Key project and asset characteristics and parameters
– A decision right (manager approval step in a process) that are used to ensure strategic alignment with business
– A business event log priorities and to manage risk through diversity of
– A monitor on configuration parameter investments.
– A record of employee training IT Portfolio Performance Report
IT Measurements (From: A36 A367, To: A31 A313 A316 A364 A365
(From: A13 A131, To: A133) A366)
The measurements and key indicators produced by A management report describing the actual results of IT
combining measures and results from individual sources portfolio management activities in terms of value
to create an IT-wide view of IT activities. Individual realized, balance achieved, and degree of strategic
processes can access relevant measurements as part of alignment.
their normal operation. IT Portfolio Review Results
IT Operational Environment Capabilities (From: A366, To: A365 A367)
(From: A125, To: A121 A122 A123 A124 A126) The level of performance achieved to-date of the IT
The mechanisms (for example: methods, systems, portfolio against target and planned adjustments
procedures) which, when implemented in the context necessary to close any performance shortfalls or to
provided by the management system process, exploit performance opportunities.
organization and information, provide the operational IT Process Capabilities
capabilities for the IT Management System. (From: A122, To: A121 A123 A124 A125 A126)
IT Organizational Capabilities The models and further elaborations of the processes
(From: A123, To: A121 A122 A124 A125 A126) within IT and of their interactions with processes
The structure, behaviors, and enablers for the operated by stakeholders. The development of the
organization dimension of the IT management system. capabilities progresses through several levels of
Includes: elaboration, from specification and reference to
operational and finally to implemented. They include:
– IT Roles and Responsibilities
– Activities
– IT Organization Unit Structures and Relationships
– Workflows, including
– Motivational schemes, such as incentives
à Decision points
– Implementation of enablers (such as Communities of
Practice) à Policy impacts
à Sequencing
IT Plan à Parallelization
(From: A3 A36 A365, To: A2 A22 A221 A25 A254 A255 – Role mapping (to activities)
A26 A264 A265 A31 A314 A366 A4 A41 A411 A42
A421 A43 A431 A44 A441 A45 A451 A5 A51 A511 IT Quality Management Framework
A52 A521 A53 A531 A6 A61 A611 A62 A621 A63 (From: A11, To: A12 A121 A122 A123 A124 A125
A631 A64 A641 A65 A651 A66 A661 A67 A671 A7 A126)
A72 A723 A725 A73 A731 A737 A74 A741 A742 The logical structure describing the strategic (vision,
A745 A75 A752 A76 A763 A764 A8 A81 A813 A84 mission, value proposition, guiding principles),
A842 A844) organizational (organizational mechanisms, roles,
The set of approved projects and associated schedule, accountabilities), process (activities, work flows, inputs,
operating plan, service level management commitments, outputs), and technology (software, hardware) goals,
and resource allocation commitments and adjustments policies and practices for quality management across the
for a defined fiscal or planning cycle. overall IT function.
IT Portfolio IT Quality Management Goals
(From: A3 A36 A365, To: A1 A12 A122 A123 A124 (From: A112, To: A113 A114)
A125 A126 A13 A131 A132 A133 A14 A142 A2 A21 The goals, specifically related to quality management,
A211 A213 A22 A221 A222 A223 A226 A23 A231 which will drive the implementation and operation of
A232 A233 A24 A241 A243 A25 A251 A254 A255 quality management approaches for the IT function.
A26 A261 A263 A27 A271 A31 A313 A314 A32 A322
A324 A33 A331 A366 A4 A42 A421 A8 A81 A811 A82 IT Quality Management Policies
A822 A83 A831 A85 A852) (From: A113, To: A114)
A central repository containing all the IT resources and High-level courses of action and guiding principles for
assets, projects, and services controlled and managed the IT function that are required in order for it to achieve
by the IT organization, departments, and functions. its quality management goals.
IT Portfolio Baseline IT Quality Management Practices

(From: A363, To: A364) (From: A114)
•
•
•
IT Quality System Capabilities – IT Service Continuity Plan
High-level practices for quality management that have List of research topics not leading to a research project
been defined in detail for the IT function so as to but are potential candidates; their future development
implement its quality policies. needs to be watched.
IT Quality System Capabilities IT Research Capabilities
(From: A12 A126, To: A13 A131 A132 A133 A14 A141 (To: A324)
A142 A143 A144) Capabilities and resources that are needed to carry out a
The foundational components for the operation of the IT research project.
quality management system. The elements explicitly
identified here are: IT Research Guidance
– Process (From: A3 A32 A325, To: A1 A11 A114 A12 A122 A123
A124 A125 A126 A2 A21 A213 A22 A222 A25 A252
– Organization
A26 A263 A31 A313 A33 A332 A333 A8 A84 A844)
– Information
Guidance and recommendations about which trends and
– Tools, mechanisms and systems innovations should or should not be adopted. In other
IT Quality System Reports words, a summary of overall research results.
(From: A14 A144, To: A11 A113 A114 A12 A122 A123 IT Research Project Charter
A124 A125 A126) (From: A323, To: A324 A325)
Reports specifically focused on the quality management Description for research projects containing the following
system used within IT and indicating its conclusions on for each research project:
the effectiveness of, and any need for improvement in,
– Rationale for research project including evaluation
the overall quality management system.
results for project according to the evaluation criteria
IT Research and Innovation Activity Data – Detailed definition of scope
(From: A322 A323 A324 A325, To: A326) – Project objectives
Any data about the accomplishment of process activities – Project approach.
that supports the evaluation of the overall IT Research
and Innovation process. For example, data about how IT Research Requests
much value the research results bring to the business. (From: A31 A313 A33 A332 A333, To: A32 A322)
Requests from within the business or from any other IT
IT Research and Innovation Candidates process that trigger the identification and selection of
(From: A322, To: A323) research candidates.
Any topics that have been identified as potential
candidates for research projects or the watch list. IT Service Continuity Capability
(From: A765, To: A766)
IT Research and Innovation Evaluation The combination of infrastructure and human resources
(From: A326, To: A321) (associated process and organization) which IT can
An analysis of IT research and innovation activity data invoke the IT Service Continuity Plan.
providing an understanding of the current success or
failure of the process, and an identification of potential IT Service Continuity Management Activity Data
process improvements. (From: A762 A763 A764 A765 A766, To: A767)
IT Research and Innovation Framework activity, used to support the evaluation of the overall IT
(From: A321, To: A322 A323 A324 A325 A326) Service Continuity Management process.
The procedural, organizational and other management
mechanisms through which the process will operate. IT Service Continuity Management Evaluation
Includes: (From: A767, To: A761)
– Strategic goals for IT research and innovation Assessment results for the IT Service Continuity
– Policies and orientation that apply to IT research and Management process and it activities, including process
innovation performance metrics and the identification of potential
process improvement items.
– Collection of evaluation criteria for qualifying and
selecting research projects. IT Service Continuity Management Framework
(From: A761, To: A751 A762 A763 A764 A765 A766
IT Research and Innovation Project Results
A767)
(From: A324, To: A325)
The conceptional structure describing the strategic
The outcomes of performing research and innovation
(vision, mission, value proposition, policies),
projects. They will range from the base facts (data)
organizational (organizational mechanisms, roles,
through findings to conclusions about the feasibility and
accountabilities), process (activities, work flows, inputs,
viability of each candidate item.
outputs, procedures), information (data model,
IT Research and Innovation Watch List management reports) and technology (software,
(From: A323 A324, To: A322 A325) hardware) practices for managing IT service continuity.
IT Service Continuity Plan

(From: A76 A764, To: A75 A752 A765 A766)
•
•
•
IT Service Continuity Policies and Strategy – Items_ Received
A formal, documented plan describing procedures to be A consolidated statement of IT initiatives. Includes a

adhered to in order to facilitate the recovery and summary of changes to IT capabilities and a summary of
restoration of critical business services. Includes a each strategic IT initiative. Also includes a statement of
possible need for new capabilities to meet service planned and required changes to the IT Portfolio and IT
continuity requirements. Plan. The IT Sourcing Strategy would be included.
IT Service Continuity Policies and Strategy IT Strategy Architectural Implications

(From: A763, To: A764 A765 A766) (From: A33 A333, To: A31 A313)
The guiding statements which direct the IT Service An assessment of the implications of architecture
Continuity preparations, maintenance of readiness and changes on the IT Strategy; stated in terms of potential
actual invocation. For example, they include rules that (positive and negative) changes to the value of IT and its
must be adhered to in the event of either a test or an alignment to desired business capabilities. For example,
invocation of the IT Service Continuity Plan. it can detail the potential need for compromise on two
conflicting aspects of the strategy; only one (or other) of
IT Service Continuity Requirements which can be satisfied by the architecture.
(From: A763, To: A764)
Includes details of prioritization of Capacity, Availability, IT Strategy Assessment
and other Service Level items that must be satisfied by (From: A316, To: A313 A314 A315)
the IT Service Continuity Capability. Assessment of the effectiveness of the IT Strategy,
stated in terms of completeness and coverage of IT
IT Service Continuity Risk Reduction Design Criteria strategy implementation (when compared to the strategic
(From: A763) intent). Includes lessons learned about the strategy
Identification of approaches which, if adopted in the initiatives and recommendations for change.
design of the solution and in its implementation as a
service, would reduce overall continuity risk. IT Strategy Initiatives
(From: A31 A314, To: A315 A33 A333 A35 A352 A36
IT Service Continuity Solution A364)
(To: A765) An outline charter for each strategic IT initiative, stated in
The technical solution which will provide the terms of scope of change, stakeholders, benefits, time
infrastructure for continuity testing and invocation. scales and costs. The scope of change is stated in terms
of changes to the architecture baseline.
IT Service Continuity Test and Audit Results
(From: A765, To: A763 A764) IT Strategy Process Activity Data
Data (or reports) detailing the success or failure of a (From: A312 A313 A314 A315 A316, To: A317)
planned, or unplanned, test of the IT Service Continuity Data resulting from all work carried out by each process
Plan. activity. Examples would be volumes, timings, resources
IT Service Provider Value Profile rework, customer feedback, priorities.
(From: A31 A313, To: A11 A112 A113 A314)
A model of the offerings and services desired by the IT Strategy Process Evaluation
business, which incorporates the value provided by the (From: A317, To: A311)
IT Business. The model should express, in a form that Quantitative and qualitative analysis of the performance
profiles the IT Business as an IT Service Provider, and in of the IT Strategy processes against the evaluation
the style (and with the required attributes) desired by the framework. Incorporates recommendations for changes
business. An example of suitable styles is provided by to the framework and changes to the metrics.
the Commodity, Utility, Partner, and Enabler model.
IT Strategy Process Framework
IT Sourcing Strategy (From: A311, To: A312 A313 A314 A315 A316 A317)
(To: A821) A specification of the framework and metrics for
Strategic guidelines about what services or business measuring and managing the IT Strategy processes and
components are core (insourced or outsourced) as far as incorporating any mandated elements required by the
this can influence the selection of suppliers for products overall IT management system. Incorporates
and services. governance, reporting, standards, methods and review
criteria.
IT Strategy
(From: A3 A31 A315, To: Outside-the-Model A1 A11 Items_ Procured
A111 A112 A113 A114 A12 A121 A122 A123 A124 (To: A82 A824)
A125 A13 A131 A132 A133 A14 A142 A2 A21 A211 Items received from a supplier in response to a formal
A22 A221 A23 A231 A24 A241 A26 A261 A27 A271 purchase order.
A316 A32 A321 A323 A33 A332 A334 A34 A341 A35
A352 A36 A361 A366 A37 A371 A4 A41 A411 A413 Items_ Received
A42 A421 A43 A431 A44 A441 A45 A451 A5 A51 Assets that have completed the procurement process
A511 A7 A71 A711 A713 A72 A721 A73 A731 A74 (business now holds the title) and are available for
A741 A75 A751 A76 A761 A8 A81 A811 A82 A83 productive deployment. During their useful life, they are
A831 A84 A841 A842 A85 A851 A852) managed by the Asset Management process.
•
•
•
Knowledge Acquisition Requests – Knowledge_ Unstructured
K Knowledge Management Methods and Techniques

(To: A851)
Knowledge Acquisition Requests Available (best practice) methods and techniques for
(From: A853, To: A856) knowledge management (processes, structures, etc.) as
An identification of a specific requirement to obtain a an input when creating the knowledge management
body of knowledge so that it is available for any IT framework.
process activity. Knowledge Plan
Knowledge Assets (From: A852, To: A853 A854 A855 A856)
(From: A85 A855, To: A265 A613 A652 A653 A654 Indicates the subject areas in which knowledge is
A84 A844) required, and the type of knowledge items in those
Any information from knowledge management that fulfills subjects. This includes guidance on knowledge subjects
a knowledge request. which are now stabilized, and those which are becoming
less important.
Knowledge Gaps
(From: A854, To: A852 A853 A856) Knowledge Reports
(From: A856, To: A852 A857)
Any gaps in relevant knowledge that have been
identified. Reports indicating the status and key performance
indicators for the knowledge being managed. They
Knowledge Items include identification of:
(To: A853) – Patterns and trends of usage
Any item or unit of information that feeds into knowledge – Corresponding topics or items that could require
management, that is included in any knowledge additional or reduced focus in the Knowledge
management repository and which belongs to one of the Management Plan
pre-defined relevant knowledge areas.
Knowledge Request
Knowledge Management Activity Data (To: A85 A855)
(From: A852 A853 A854 A855 A856, To: A857) A request by a user for a knowledge asset to be available
Any data about the accomplishment of process activities to them.
that support the evaluation of the overall “Knowledge
Management” process. Knowledge Request Queue
(From: A855, To: A852 A854)
Knowledge Management Evaluation The entirety of knowledge requests that are as yet
(From: A857, To: A851) unsatisfied (because of time or knowledge gaps).
The result of the evaluation of the “Knowledge
Management” process. Knowledge Sources and Categories
(To: A852)
Knowledge Management Feedback The meta-data aspects of the internal and external
(To: A856) knowledge, such as:
Feedback from any user of knowledge - the processes – Potential knowledge sources
and the content - as to the usefulness, completeness, – Potential structure for knowledge.
accuracy or any other relevant aspect.
Knowledge Submission Response
(From: A851, To: A852 A853 A854 A855 A856 A857) Response to the evaluation of knowledge, such as
The framework that contains all relevant information approval, rejection, rework, and others.
about the structure of the Knowledge Management
process (the strategic goals for knowledge management, Knowledge_ Appraised and Structured
the definition of relevant knowledge, and knowledge (From: A854, To: A855 A856)
sources). Knowledge that has been assessed according to
predefined evaluation and quality criteria (e.g. checking
Knowledge Management Infrastructure for relevance, testing, scrutinizing, etc.)
(From: A851, To: A853 A854 A855 A856 A857)
Knowledge that has been structured so that it can be
Includes technology and organization (communities) to published in any knowledge management repository or
support the operation on this process, and to enable all otherwise made available to satisfy knowledge requests.
other processes to exploit this capability, such as:
– Technology specifications and implementations for Knowledge_ Internal and External
knowledge management (To: A85)
– Organizational structures necessary for carrying out All available internal and external formal or informal
the knowledge management process (both knowledge that might be relevant for the business.
administrative structures as well as active
participants in knowledge management, like Knowledge_ Unstructured
communities). (From: A853, To: A854)
•
•
•
Known Error – Operational Measures and Results
Knowledge that has been acquired but not yet has been Market Data
evaluated and structured. Can be documented or tacit (To: A22 A222 A26 A262)
knowledge. A collection of qualitative and quantitative data items
which describe the current and potential future state of
Known Error the IT service provider marketplace.
(From: A664 A665, To: A665 A666 A667)
As defined in ITIL: “A Problem that has a documented Market Outcomes
Root Cause and a Workaround. Known Errors are (From: A224, To: A228)
created and managed throughout their life cycle by The results of efforts to create market awareness and
Problem Management. Known Errors may also be thereby generate demand for the IT service provider's
identified by Development or Suppliers.” 7 portfolio of solutions. An example would be the number
of articles which reference the provider's services.
L Market Plan
(From: A223, To: A224 A225 A228 A232)
Labor Inventory Information A document that structures the approach to target
(From: A843, To: A842 A844) customers with the current and under development IT
Repository for human resource allocations. service offerings.
Legal and Regulatory Requirements Market Segmentation
(To: A841) (From: A222, To: A221)
Requirements from governmental and other regulatory Customer grouping based on common service
bodies to be applied to the employment aspects of any consumption patterns.
business. An example would be Health and Safety
legislation. Marketing and Sales Reports
(From: A22 A228, To: A23 A234 A25 A255 A273 A275
A835)
M Reports indicating the outcomes of marketing and sales
efforts, and that compare the current sales and
Maintenance and Replenishment Data marketing execution to the market plan.
(From: A623, To: A625)
Information pertaining to maintenance activities and to
restocking consumable resources. This data could N
include resource name, amount replenished, location,
vendor, and other information. Normality Notification
(From: A766)
Maintenance and Replenishment Schedule A notification that critical business services have been
(From: A625, To: A621 A623) stabilized to a condition that reflects the new normal
The time, date, quantity and other related information operation, following a period of operating under
relating to the maintenance of delivery resources and to continuity status.
the re-supply of consumable materials.
Major Problem Review Results O

(From: A666, To: A668)
The analysis and outcome of reviewing those problems Operational Continuity Infrastructure
classified as major. This classification can reflect a (From: A766)
variety of reasons, such as: The IT Service Continuity Solution in live state, ready for
– Service impact delivering the planned level of operational service, and
– Problem duration all relevant details about it so that the regular set of
processes can perform their work, within the limitations
– Cost and efficiency to achieve resolution and closure
of that continuity solution.
Operational Documentation
Market Analysis (From: A855, To: A45 A454 A523 A613 A621 A651
(From: A2 A22 A222, To: A1 A11 A112 A113 A21 A211 A654 A655 A664 A723 A736 A764 A765 A766)
A223 A23 A232 A25 A252 A26 A262 A3 A31 A313
The subset of knowledge assets that represent the set of
A34 A343 A35 A352 A36 A364 A365)
material, both externally provided and internally
A document that evaluates the current service generated, required to support the development,
requirements, market segmentation, current customer deployment, operation, and maintenance of solutions
profiles, and the current typical IT service provider and services.
scope. The purpose is to discern general trends and
– ITIL uses the term Operational Document Library to
directions in the current IT service marketplace.
refer to an implementation of this output.

7. ITIL V3 Glossary (To: A13 A131)
•
•
•
Operational Monitoring Data – Problem Information
Any measure or result from any IT process that might be Portfolio Management Evaluation
relevant to the measurement, and control activities of the (From: A368, To: A361)
overall IT management system. The effectiveness and efficiency of the process activities
and practices performed in managing the IT portfolio.
Operational Monitoring Data
(From: A6 A62 A622 A623 A624 A63 A633 A634 A635 Portfolio Management Framework
A636, To: A62 A623 A625 A63 A634 A637 A64 A642 (From: A361, To: A362 A363 A364 A365 A366 A367
A65 A654 A655 A66 A662 A7 A73 A735 A74 A743) A368)
Information relating to the overall item-by-item outcomes The logical structure describing the strategic (vision,
and status of the IT operation service. This can include mission, value proposition), organizational
measurements of resource utilization, transaction (organizational mechanisms, roles, accountabilities),
volumes, processing status, among others. process (activities, work flows, inputs, outputs), and
Operational Schedule Directives the IT portfolio.
(From: A744)
Desired changes and adjustments to operational Pricing Algorithm
schedules, used to optimize the workload throughput or (From: A831, To: A833)
other characteristic within a finite capacity. Sometimes a The formulas used to work with service pricing data to
part of a general Service Resilience Directive. derive pricing alternatives for further evaluation.
Operational Schedules Pricing Analysis
(From: A621, To: A51 A515 A52 A521 A522 A53 A532 (From: A835, To: A831 A833)
A622 A623 A624 A625 A743) A summary of the effects and implications of current and
The overall schedule for individual work items and when proposed algorithms, price points and service contract
they are processed. Examples are start and stop times terms, used to provide feedback on pricing practices.
of specific applications, availability of specific services
and infrastructure services (file transfer). Pricing Data
(From: A832, To: A833)
Operational Service Project Proposals The pricing data consist of all measures needed to
(From: A62 A621 A63 A631 A64 A641) measure the service usage. This is input to the price
Proposals, from the Framework activities within the model.
Operations category, for project funding. The proposals
will go to the Portfolio Management process for decision. Pricing Elements
The proposal content will be for purposes such as: (From: A831, To: A832)
– To establish additional or improved capabilities for The objects, factors and practices to be considered in
performing any activities or tasks within the process developing service prices and contract terms.
– To satisfy the operational needs of new technical
solutions coming on-stream Prioritized Market Wants and Needs
(From: A222, To: A223)
– To improve any relevant aspect of service
performance A comprehensive set of capabilities the marketplace is
seeking from an IT service provider, prioritized according
to business justification.
P
Problem
Portfolio Approval Request (From: A662, To: A663 A667)
(From: A352 A353 A354 A355 A356) As defined in ITIL: “A cause of one or more Incidents.
A request directed to the IT Portfolio Management The cause is not usually known at the time a Problem
process for a decision or commitment, related to a given Record is created, and the Problem Management
product's position or milestone achievements within the Process is responsible for further investigation.” 8
stages of its life cycle.
Problem Information
Portfolio Decision and Resource Allocation (From: A6 A66 A667, To: A2 A24 A244 A245 A356 A61
(From: A36 A365, To: A35 A352 A353 A366 A813) A613 A615 A65 A653 A654 A656 A662 A663 A664
An allotment or apportionment of financial and other A665 A666 A7 A73 A736 A74 A744 A76 A764)
resources (possibly from both the business and IT) to Information about one or more problems. Can range
develop or refine the product vision and product life cycle from full details of an individual problem through to
definition and plan or for any project proposal not related collated and summarized information about sets of
to a specific product. The financial allotment includes problems. Can be provided both as formal reports (such
consideration of both capital and expense funds. as documents to customers describing root cause,
contributing factors and corrective actions) and
Portfolio Management Activity Data
(From: A362 A363 A364 A365 A366 A367, To: A368)
Performance and quality data regarding activities
performed in managing the IT portfolio. 8. ITIL V3 Glossary
•
•
•
Problem Management Activity Data – Product Package
informally as structured data for other processes to Problem_ Resolution

analyze for their own purposes. (From: A665, To: A666 A667)
Actions taken to repair permanently a known error or
Problem Management Activity Data implement a workaround.
(From: A662 A663 A664 A665 A666 A667, To: A668)
Any data about the accomplishment of process activities Procurement Exceptions
that supports the evaluation of the overall Problem (From: A824, To: A823)
Management process. Exceptions during procurement (item no longer available
from supplier) that can influence the management of
Problem Management Evaluation supplier contracts.
(From: A668, To: A661)
An assessment of the overall performance of the process Product Introduction and Usage Status
against the targets set in the process framework and an (From: A355, To: A356)
identification of possible process improvement areas. Detailed information about the progress of projects
underway to deploy or retire the product, as well as
Problem Management Framework information about current usage and acceptance.
(From: A661, To: A662 A663 A664 A665 A666 A667
A668) Product Lifecycle Definition and Plan
The framework that contains all relevant information (From: A353, To: A354 A355 A356)
about the structure of the Problem Management A plan that guides and controls a given product's
process; that is, the strategic goals and policies for evolution and transition through all phases of the product
Problem Management, the definition of supporting life cycle. The plan addresses milestones related to
technology, measurements, among others. requirements coverage, realization and integration
activities, product version and release schedules,
Problem_ Closed funding and resource assumptions, as well as
(From: A666, To: A667) relationships to IT Strategy and IT Portfolio directions.
The finalization of all data related to a problem. This Also covers retirement and disposal.
includes structured data, which supports analysis of
problem causes, patterns, costs and resolution Product Lifecycle Milestone Achievement
effectiveness. (From: A354 A355, To: A353)
Information and status of the product's progression
Problem_ Diagnosed through declared life cycle milestones for realization,
(From: A664, To: A665) transition and operation.
Product Management Activity Data
Problem_ Further Investigation Request (From: A352 A353 A354 A355 A356, To: A357)
(From: A665, To: A664) Data resulting from all work carried out by each process
In the process of resolving a known error, if additional activity. Examples would be volumes, timings, resources
problems are identified, a request is made for additional used, success and error rates, interfaces invoked,
root cause analysis. rework, customer feedback, priorities.
Problem_ Prioritized Product Management Evaluation
(From: A663, To: A664 A667) (From: A357, To: A351)
A problem for which the category and priority are Quantitative and qualitative analysis of the performance
understood and recorded in the problem record. ITIL has of Product Management process and activities as
the following definitions for these terms: defined in the Product Management Framework. It also
– Category is defined as “A named group of things that incorporates recommendations for changes to the
have something in common.” 9 framework, the process, and to the metrics.
– Priority is defined as “A Category used to identify the
Product Management Framework
relative importance of an Incident, Problem or
(From: A351, To: A352 A353 A354 A355 A356 A357)
Change. Priority is based on Impact and Urgency,
and is used to identify required times for actions to be A specification of the framework and metrics for
managing and measuring the Product Management
taken.” 10 process and activities, and incorporating any mandatory
Problem_ Reprioritization Request elements required by the overall IT Management
(From: A667, To: A663) System. Incorporates process governance, polices,
In the course of monitoring and tracking problems, there
could be a need to lower or raise the priority of an Product Package
individual problem due to a change in the business (From: A3 A35 A353 A354 A355, To: A2 A23 A24 A243
impact. The problem is referred to reprioritization. A5 A52 A522)
A description of the product that details how it is to be
iteratively assembled, integrated and deployed, as well
9. ITIL v3 Glossary as the status of the product itself as it migrates through
10. ITIL v3 Glossary
•
•
•
Product Performance Assessment – Project Definition
the various stages of realization, deployment and Program Change Request

operation. (To: A372)
A request to modify or adjust any aspect of an
Product Performance Assessment established program. Requests are usually processed
(From: A356, To: A273 A352 A353) under a requirements or change control procedure in
A summary of the product's current level of achievement order to ensure appropriate and auditable responses.
with regard to commitments made in the product plan.
Includes assessments of both quantitative and Program Charter
qualitative factors and the overall value of the product. (From: A36 A365, To: A37 A372)
A document issued by or created on behalf of the
Product Proposal sponsor to describe the program’s objectives. It
(From: A35 A352, To: A36 A364) provides the program manager with the authority to
A product idea being put forward for consideration. A apply organizational resources to set up and run
high-level evaluation and documentation of a product's program activities.
(or change in a product's characteristics) impact on and
fit with the IT Portfolio, addressing elements such as the Program Plan
market opportunity, technical and integration benefits, (From: A37 A372, To: A34 A344 A373 A374 A375
risks, costs and potential returns, improving service, A376 A377 A378)
competitive positioning, value, life span, among others. The overall plan for the delivery of the program. It will not
describe specific details of any individual part of the
Product Realization Status work, but will focus on aspects such as:
(From: A354, To: A355)
– The structure of the set of projects which constitute
Detailed information about the progress of projects the program
underway to create or change the product.
– The measurements and reports by which the
Product Vision program will be managed
(From: A352, To: A353) – The program's governance and communication plans
A shared perspective on the future possibilities of a
Program Status Report
product or group of related products. Includes context
(From: A372)
elements such as markets and market share, customers,
technologies and projected technology advances, A snapshot of the progress, status, and issues relating to
competitors and product differentiators, cost and return an established program.
parameters. Provides a touchstone for product plans and Project and Service Inventory
life-cycle events (From: A362, To: A363 A365 A366)
Program and Project Management Activity Data The itemized record of projects and services for which IT
(From: A372 A373 A374 A375 A376 A377, To: A378) resources are being consumed or are being proposed.
Data resulting from all work carried out by each process Project Change Request
activity. Examples would be volumes, timings, resources (To: A374)
rework, customer feedback, priorities. A request to change some document or aspect of the
project that has been placed under change control. An
Program and Project Management Evaluation accepted change request may result in one or more
(From: A378, To: A371) change orders.
An assessment of the overall performance of the process Project Charter
against the targets set in the process framework and an (From: A3 A324 A354 A36 A365, To: A33 A333 A334
identification of possible process improvement areas. A37 A372 A373 A4 A41 A412 A414)
Program and Project Management Framework A document issued by or created on behalf of the
(From: A371, To: A372 A373 A374 A375 A376 A377 sponsor to describe the project’s objectives. It provides
A378 A411) the project manager with the authority to apply
The logical structure describing the strategic (vision, organizational resources to project activities.
mission, value proposition), organizational Project Completion Report
(organizational mechanisms, roles, accountabilities), (From: A377, To: A372)
process (activities, work flows, inputs, outputs), and
technology (software, hardware) practices for managing Communication between the delivery organization and
projects and programs. the sponsor indicating that the work committed within the
project is completed. Provides evidence that all terms of
Program and Project Reports the agreement have been satisfied and all work has
(From: A37, To: A13 A131 A324 A34 A345 A346 A36 been completed.
A365 A366 A716)
Project Definition
The body of information ranging from formal, regular and (From: A373, To: A374)
summarized, through informal, ad hoc, and detailed
about any aspect of program and project status, and The document that describes the shape of the project
plans. It is available to any process with a need to know. and includes:
•
•
•
Project Directive Outcomes – Purchase Orders
– The objectives and scope Projected Service Outage

– The stakeholders and proposed organization with (From: A515, To: A244 A734)
responsibilities As defined in ITIL: “A Document that identifies the effect
– The major risks associated with the project of planned Changes, maintenance Activities and Test
Plans on agreed Service Levels.” 11
Project Directive Outcomes
(To: A375) Projected Solution Cost
The outcomes of actions taken in response to (To: A832)
instructions or changes from project management made Part of Solution Plans and Commitments, it provides
to bring future performance of the project into line with anticipated costs of solutions before any actual cost data
the plans and procedures. is available.
Project Directives Proposal Additional Information Request
(From: A376, To: A373 A374) (From: A364 A365)
Instructions or changes made to bring future A request to provide additional information for a
performance of the project into line with the plans and proposed project in order to effectively perform portfolio
procedures. management activities.
Project Events Proposed Conditions of Satisfaction
The notification of events that, in the project manager’s Documented Conditions of Satisfaction as understood
opinion, are important to support the management of the and formally proposed by the solution provider.
project.
Proposed Customer Contract Terms
Project Information (From: A834)
(To: A362) Includes the agreed service level objectives, the
Project information includes charter, description, budget corresponding service price model for one customer, the
and schedule performance and outlook. customer specific additional terms and conditions
(contract period) and, often, planned usage data.
Project Plan
(From: A3 A37 A374, To: A265 A34 A343 A344 A372 Proposed IT Customer Capability Adoption
A375 A376 A377 A4 A41 A412 A5 A51 A514 A52 Improvements
A522 A53 A532) (From: A266, To: A265)
The set of work plans. Work plans can include Suggestions for improvements (changes, extensions) to
management, human resource, technical environment, the existing adoption support plan. This is based on
project quality, communications management, among lessons learned from existing adoption, and how well the
others. mooted benefits have been realized.
Project Proposal Proposed IT Portfolio Targets
(From: A2 A22 A25 A255 A26 A264 A33 A5 A51 A515, (From: A364, To: A365)
To: A3 A34 A342 A35 A352 A36 A364) The set of performance targets set for the IT portfolio
A formal statement of an idea being put forward for including economic, strategic alignment, and balance.
consideration that includes the business case for the
proposed IT investment. Prototype Work Products
(To: A413 A414 A423 A424 A425)
Project Status Report Reduced scale or function deliverables used to explore
(From: A375) feasibility or suitability of some aspect of the solution.
A report, prepared to schedule or request, by the top-
level project manager for the line of business Purchase Order Status
management. It documents the status, progress and (From: A82 A824, To: A81 A814 A824)
accomplishments, and forecasts for the end of the Status of orders (necessary to track the orders).
project. General categories include:
– Health status summary Purchase Orders
– Resources (From: A82 A824, To: A825)
– Earned value indicators Order for products or services to a supplier resulting
from procurement requests, including detailed
– Accomplishments information about the order. Also covers the negative
– Quality, issue, risk, change, and compliance incident case (if an item has to be returned to the supplier).
summaries
Project Tracking Report
(From: A375, To: A372 A374 A376 A377)
Detailed project management information which is
indicates the status, in terms of schedule, quality, risks
and costs, of the project against plan. 11. ITIL V3 Glossary
•
•
•
Recovered Service Status – Release_ Closed
R Data resulting from all work carried out by each process

Recovered Service Status used, success and error rates, interfaces invoked,
(To: A622) rework, customer feedback, priorities.
Status information on the recovered service. Release Management Evaluation
(From: A527, To: A521)
(To: A11 A111 A113 A114 A55 A551 A71 A711 A712 An assessment of the overall performance of the process
A72 A721 A722 A723 A75 A752 A81 A811 A82 A821 against the targets set in the process framework and an
A823 A824 A84) identification of possible process improvement areas.
External official rules (typically driven by government) Release Management Framework
that call for business compliance, as well as established (From: A521, To: A522 A523 A524 A525 A526 A527)
good practice standards from formal and informal This framework describes:
bodies. Includes:
– Types of releases
– Generally accepted accounting principles
– Naming and other release conventions
– Legal requirements, such as Sarbanes-Oxley and its
– Release policies and procedures
COSO (Framework for Financial Management)
– Definitive Media Library (DML) specifications
Rejected IT Research and Innovation Candidates – Roles and responsibilities
(From: A323, To: A325) – Scheduling policies
Research candidates that are not chosen to become – Process review schedule.
research projects or part of the watch list. This framework provides governance information for the
other activities in Release Management.
(From: A412 A413 A414) Release Notice
The part of solution requirements formally rejected by (From: A52 A525, To: A53 A534 A535)
the solution provider, with or without prior approval of the The notices and other communications material, about a
stakeholders. release, that is made available to both users and IT staff
impacted by the release. Contents will range from
Release
general awareness announcements through specific
(From: A52 A524, To: A53 A532 A533 A535 A536)
details, such as training schedules and plans, to actual
The packaging of one or more solutions along with all the release documentation and training material. They are
materials (scripts, documentation, for example) needed updated as experience is gained about the release.
for successful deployment.
In ITIL, Release is defined as “A collection of hardware, Release Reports
software, documentation, Processes or other (From: A525, To: A522 A523 A526)
Components required to implement one or more Reports showing the outcome of the release
approved Changes to IT Services. The contents of each implementations.
Release are managed, Tested, and Deployed as a single
entity.” 12 Release Review Results
(From: A526, To: A522)
Release _Built Analysis of release usage, with identification of
(From: A523, To: A524 A526) successes and areas for release improvement.
Release Revision Request
Release Acceptance (From: A524, To: A522 A523)
(From: A51 A516, To: A52 A524 A525) Identification of a need to re-plan a release following the
The notification of approval that the Release can outcomes of test and acceptance work.
proceed to its rollout activities.
Release Strategy
Release Acceptance Request (From: A52 A522, To: A523 A524 A525 A526 A53
(From: A52 A524, To: A51 A516 A525) A532 A533 A534 A535 A536 A537 A538)
A request for final approval from Change Management The overall approach that will guide the release through
for a release to be able to proceed to rollout. The request its complete life cycle, and into deployment. It includes
will be accompanied by evidence of the release having the plan for creating a release, including the definition of
passed its acceptance criteria. the set of changes which are collected within it, and also
the release test plan.
Release Management Activity Data
(From: A522 A523 A524 A525 A526, To: A527) Release_ Closed
(From: A526)
Information and technical content related to the closure
12. ITIL V3 Glossary of a release.
•
•
•
Request for Identity and Access Information – Risk Interventions and Indicators
Request for Identity and Access Information – Categorization and prioritization aspects for service
(To: A675) requests.
A request from another process or from a customer or It defines the records which should be kept for each
user for information on some aspect of one or more service request containing all relevant details across the
identities and their registered access rights, including life cycle of the request. Information in a record includes
historical data. data relevant to service provider analysis as well as the
details directly relevant to the requestor.
Request for Incident Status and Information
(To: A657) Request to Supplier for Information
Notification of the need for information about incidents. (From: A82 A822)
Any request for information from suppliers that directly
Request for IT Research Capabilities goes to the suppliers, including:
(From: A323) – Financial information
Request for capabilities and resources needed to carry – Portfolio information (which items can be supplied)
out a research project. Examples include request for
– Standard terms and conditions
human resources, request to procure items, request to
develop solutions as support for the research project, – RFIs
and more. – RFPs
– Vendor briefings
Request for Problem Status and Information
(To: A667) Resource Adjustments
Request for information with regard to overall problem (From: A625, To: A623)
status and service level attainment with regard to Adjustments to IT technical resources that might be
problem management. required to optimize service execution as a result of
analysis of the service execution data, workload, and so
Request for Product or Service forth.
(From: A432 A442, To: A822 A823 A824)
Information about required products and services that Resource Status
are needed by any IT process - but especially Solution (From: A623, To: A622)
Build and Solution Test. It will be used within the Information pertaining to the status of any IT resource
activities of selecting and managing the right portfolio of that is used in the provision of service. The status could
suppliers and respective supplier contracts, or to initiate be available, not available, failing, over-utilized,
actual procurement. approaching peak usage, and would include actual
status and predictive information for ensuring adequate
Request for Supply Capability Information availability of resources at all times. This also includes
(To: A826) Resource Commit Failure.
Request for information from any process within IT about
the IT Service Provider's arrangements and capability to Restore Request
obtain supply items. (To: A635)
Service Requests from any user or other process for a
Request Fulfillment Activity Data data restore to be performed.
(From: A612 A613 A614 A615, To: A616)
Any data about the accomplishment of process activities Reusable Components
that support the evaluation of the overall Request (To: A421 A423 A424)
Fulfillment process. Parts (Engineering parts) the set of components
identified for future reuse by the Architecture
Request Fulfillment Evaluation Management process.
(From: A616, To: A611)
The result of the evaluation of the Request Fulfillment Risk Assessment
process, including any identification of potential process (From: A343, To: A344 A346)
improvement areas. Sets of categorized, quantified, and prioritized risks for
which the IT endeavor will need to consider putting in
Request Fulfillment Framework place risk avoidance and mitigation plans.
(From: A611, To: A612 A613 A614 A615 A616)
The framework that contains all relevant information Risk Assessment and Mitigation Plans
about the structure of the Request Fulfillment process, (From: A34, To: A36 A364 A37 A374 A712 A714)
for example: The recommendations as to the acceptability or
– Structure of the request fulfillment center (often otherwise of the risk factors of any undertaking (such as
known as or linked to a 'service desk') project, external development) and the risk limitation
– Technology support measures selected to reduce the impact of unacceptable
risk occurrence.
– Request routing tables and completion details of
request completion targets and commitments Risk Interventions and Indicators
– Format of information transfer (From: A345, To: A342 A346)
•
•
•
Risk Management Activity Data – Security Policy
The actions taken, either directly or implicitly through the Security Directives
controls previously put in place, which aim to modify or (From: A725, To: A333 A334 A67 A673 A674)
determine the events or their outcome so that risk The directive to take action, or the action to be taken, so
exposures are minimized. In some cases these will be that the protections which implement the desired security
'Key Risk Indicators' which should be monitored against practices are properly operated.
thresholds rather than directly requiring risk intervention.
Security Management Activity Data
Risk Management Activity Data (From: A722 A723 A724 A725 A726 A727, To: A728)
(From: A342 A343 A344 A345 A346, To: A347) Data resulting from all work carried out by each process
Data resulting from all work carried out by each process activity. Examples would be volumes, timings, resources
activity. Examples would be volumes, timings, resources used, success and error rates, interfaces invoked,
used, success and error rates, interfaces invoked, rework, customer feedback, priorities.
Security Management Evaluation
Risk Management Evaluation (From: A728, To: A721)
(From: A347, To: A341) An assessment of the overall performance of the process
An assessment of the overall performance of the process against the targets set in the process framework and an
against the targets set in the process framework and an identification of possible process improvement areas.
Risk Management Framework (From: A721, To: A331 A341 A722 A723 A724 A725
(From: A341, To: A342 A343 A344 A345 A346 A347) A726 A727 A728 A751 A761)
A risk management model that allows identification, The conceptional structure describing the strategic
definition, and assessment of risks, and the (vision, mission, value proposition), organizational
implementation and operation of risk mitigation and (organizational mechanisms, roles, accountabilities),
avoidance activities. process (activities, work flows, inputs, outputs), and
Risk Mitigation Assessment Reports security.
(From: A346, To: A343)
Information about the outcomes of risk mitigation Security Monitoring Data
activities, indicating both successes and risk items which (From: A72 A726, To: A64 A642 A67 A675 A727 A73
require improved treatment. A735)
Information relating to the overall item-by-item outcomes
Risk Mitigation Plans Definition from, and status of, security. This can include details of
(From: A344, To: A345 A346) access requests, authentications processed, attacks
Definition of the Risk Mitigation plans required to be received and warning thresholds triggered.
implemented to minimize exposures and vulnerabilities.
Security Plan
(From: A72 A725, To: A33 A334 A335 A336 A34 A344
S A345 A346 A42 A422 A423 A424 A44 A442 A612
A613 A67 A671 A75 A752 A76 A764 A843)
Sales Leads
A consolidated view and documentation of the
(From: A224 A26 A264, To: A22 A225)
resources, approach, procedures and assets to be
A notice that there might be a potential customer for one protected together with a definition of the security
or more IT provider services. practices and controls which will be enacted in order to
Sales Opportunity fulfill the security policy. It covers both technical
(From: A225, To: A226 A228) capabilities (for example, firewalls, encryption) and non-
technical considerations (such as segregation of duties,
A qualified sales lead, in which a customer has
training needs, user responsibilities).
expressed interest for one or more IT services and would
like an understanding of how the services might Security Policy
specifically apply to its environment and for what price. (From: A7 A72 A722, To: A2 A21 A213 A24 A243 A3
A31 A314 A33 A331 A332 A333 A34 A341 A342
Sales Outcomes
A343 A4 A41 A413 A6 A67 A671 A672 A673 A674
(From: A227, To: A228)
A675 A71 A712 A713 A723 A724 A725 A726 A727
The final determination of the sales process, whether the A73 A732 A75 A752 A76 A763 A8 A82 A822 A85
sale closed or was rejected by the customer. A852)
Sales Plan The statement of the types and levels of security over
(From: A225, To: A226 A227 A228) information technology resources and capabilities that
must be established and operated in order for those
The plan put in place to manage customer sales
items to be considered secure. It provides management
interaction with an intention of growing and streamlining
direction into the allowable behaviors of the actors
the sales pipeline.
working with the resources and exercising the
capabilities. It defines the scope of management and
specifies the requirements for the security controls.
•
•
•
Security Procedures and Infrastructure – Service Catalog Management Activity Data
Security Procedures and Infrastructure One or more reports about how well the service levels
(From: A725, To: A726 A727) have been achieved and which compare IT's actual
The collected design, components, policies and direction service level results achieved against the service level
which together establish an infrastructure to be put into standards and any specific service level targets
place for security management. negotiated with customers. The reports can include
details of service impacts — both directly measured and
Security Reports an assessment of business impact. Some sections will
(From: A72 A727, To: A346 A71 A716 A723 A725) be for customer distribution and others can be for service
The reports from auditing and other analyses of IT provider receipt only.
security monitoring data.
Service and Resource Tuning Directives
Security Request (From: A744, To: A256 A743 A745)
(From: A634, To: A726) Ranges from traditional performance tuning through
System or external request to secure IT resources or capacity and workload allocation adjustments.
validate authority for access.
– Secure IT resources: identifies one or more specific Service Catalog
resources which need to be included in the security (From: A2 A23 A235, To: A21 A213 A22 A222 A223
protection scheme, or need to have their level and A224 A226 A236 A24 A242 A243 A25 A254 A26
means of protection adjusted A264 A265 A266 A27 A271 A273 A3 A35 A352 A36
A362 A5 A51 A513 A52 A522 A53 A532 A54 A541 A6
– Request to access: a communication soliciting A61 A611 A612 A613 A7 A73 A731 A74 A742 A76
access to a particular resource or class of resources. A761 A8 A81 A812 A83 A831 A833 A834)
Security Response Catalog of all services offered for delivery by the IT
(From: A726, To: A535 A623 A624 A634) service provider. Portions of it can be used as a means
The result of processing a security request. The result of communication to the customers, but there are also
will reflect a range of possibilities, depending on the sections that describe details (usually not published
nature of the service request: outside the delivery organization) of how each service is
provided.
– For a protection request – the protections put in place
ITIL defines Service Catalog as: “A database or
– For an access authorization request – success or
structured Document with information about all Live IT
failure of the request
Services, including those available for Deployment. The
Security Risk Analysis Service Catalogue is the only part of the Service
(From: A723, To: A724 A725) Portfolio published to Customers, and is used to support
The results and recommendations of an in-depth study the sale and delivery of IT Services. The Service
of the threats, vulnerabilities and risk factors to be Catalogue includes information about deliverables,
mitigated by security practices and protection prices, contact points, ordering and request
mechanisms. Processes.”13
Security Risk Assessment Service Catalog Content

(From: A723, To: A42 A424 A425 A44 A444 A445 A45 (From: A233, To: A234 A235)
A454 A455) The Service Catalog contains at least the following
A detailed analysis of the current and projected security information:
risk factors facing the enterprise. – Descriptions written in terms familiar to the requestor
– Interactive forms with pricing and categorization
Security Violation – Components, prerequisites, recommended
(From: A726, To: A727) accessories
An event (an activity or state) that is inconsistent with – Authorization, escalation, and notification policies
defined security practices and requires further inspection
and evaluation. – Delivery processes for optimal quality, speed,
efficiency
Security Work Request – Internal and external cost structures and pricing
(From: A535 A623 A624, To: A72) – Service level and operating level standards
A Security Request originating from another process. – Reporting on demand, usage, and customizations
Service Accounting Data Service Catalog Management Activity Data
(From: A814, To: A812 A815 A816) (From: A232 A233 A234 A235 A236, To: A237)
Information about the cost, ROI and value of IT services Data resulting from all work carried out by each process
provided (or to be provided), used in financial reporting activity. Examples would be volumes, timings, resources
and for the allocation of costs and charges. used, success and error rates, interfaces invoked,
Service Achievement Reports
(From: A24 A244, To: A13 A131 A14 A141 A245 A246
A25 A255 A256 A27 A273 A275 A365 A366 A735
A736 A744) 13. ITIL V3 Glossary
•
•
•
Service Catalog Management Evaluation – Service Improvement Input
Service Catalog Management Evaluation A742 A745)

(From: A237, To: A231) Agreed predictions of the IT service demand that will be
An assessment of the overall performance of the process driven if the expected level of business activity occurs.
against the targets set in the process framework and an They are usually arranged by periods against a standard
identification of possible process improvement areas. calendar.
Service Catalog Management Framework Service Demand Models
(From: A231, To: A232 A233 A234 A235 A236 A237) (From: A254, To: A255)
The logical structure describing the strategic (vision, Analysis of the relationships between typical business
mission, value proposition), organizational activity patterns and the consequential demand for IT
(organizational mechanisms, roles, accountabilities), service.
technology (software, hardware) practices for the Service Description
Service Catalog Management process. (To: A233)
A service description includes both the capabilities
Service Catalog Reports (utility) and the non-functional properties (warranty).
(From: A236, To: A233) Non-functional properties include performance,
Service Catalog Reports contain information about: payment, price, availability (both temporal and locative),
– Usage patterns, volumes, and trends for the overall obligations, rights, security, trust, quality, discounts, and
Service Catalog and each defined view penalties.
– Each service, such as update history, client
Service Execution Activity Data
activations and customizations, defect reports, user
(From: A621 A622 A623 A624 A625, To: A626)
questions, or other relevant data about the service
sent by the user communities Data resulting from all work carried out by each process
Service Catalog Usage Data used, success and error rates, interfaces invoked,
(To: A23 A236) rework, customer feedback, priorities.
Data relating to the access and usage of the service
Service Execution Evaluation
catalog. Examples would be:
(From: A626, To: A621)
– Numbers of read accesses, by user
A report or data providing measurements, trending and
– Number of enquiries by customers for new or metrics on the health and performance of Service
extended services Execution. Includes identification of potential process
– Service requests submitted through the catalog improvement areas.
mechanism
The data can be used directly for service catalog content Service Execution Framework
and delivery analysis; indirectly to contribute to (From: A621, To: A622 A623 A624 A625 A626)
understanding which services customers are using, the The overall scheme of documents, plans, processes, and
environmental conditions under which the services procedures designed to govern and optimize all activities
operate, and the quality of the service. This data can be for Service Execution. The framework includes:
used for service improvement and in customer – Operational Procedures
relationship management. – Service Execution Plan.
Service Catalog Views Service Execution Metric Data and Reports
(From: A234, To: A235) (From: A62 A625)
The Service Catalog provides relevant views for all user Significant service execution event logs, volume and
communities. It should include at a minimum, however, other measurement data relating to how effectively and
perspectives from the business manager (customer), efficiently service execution has been performed. This
administrator, and the final user. data, which is available as requested both in raw format
and as structured reports, is a component of all
Service Contract Terms
Operations Information and is the basis for service level
(From: A834, To: A835)
reporting.
Include the agreed service price model for one customer,
and the specific additional terms and conditions (contract Service Improvement Input
period). (From: A666)
Any information from problem resolution (proactively or
Service Demand Baselines
reactively) that can help to improve the overall service
(From: A254, To: A255)
delivery. For example, there could be a finding that a
An agreed statement of the IT Service demand that will specific service part or component frequently generates
be driven by the expected business demand for the problems and a determination that a modification to the
normal (typical) pattern of business. A baseline is “A
Benchmark used as a reference point.” 14
Service Demand Forecasts
(From: A25 A254, To: A24 A243 A246 A255 A256 14. ITIL Glossary
•
•
•
Service Improvement Plan – Service Metric Data and Reports
procedures used to operate the service would remove to:

the incident-inducing circumstances. à Establish SLA feasibility
à Set targets
Service Improvement Plan
(From: A246, To: A243) à Ensure supply of measurements
A plan and roadmap for improving service levels. For – Procedures to be followed to investigate and correct
example, if service levels are not attained or if service any breach of committed targets
levels have to be changed. It is based on service level – High-level plans for improvement
reviews, and customer and service provider
improvement suggestions. Service Level Package
(From: A2 A25 A255, To: A22 A226 A23 A233 A234
Service Initiative Proposal A24 A243 A246 A256 A3 A35 A354 A355 A4 A41
(From: A223) A412 A413 A42 A422 A423 A7 A74 A742 A744 A8
A document describing a potential new service, the gap A83 A833 A834)
it will fill in the current IT service portfolio, and the Details of the expected implications to the service utility
initiative that will be required to put the service in place. and warranty which will result from agreement with the
This document includes a business case. relevant business units on the demand management
approaches under which the service will be provided.
Service Level Communication ITIL definition: “A defined level of Utility and Warranty for
(From: A24 A242) a particular Service Package. Each SLP is designed to
Information which helps each stakeholder (particularly meet the needs of a particular Pattern of Business
customers) in service level management activities to Activity.” 15
understand the scope, context and specific roles and
responsibilities for carrying them out. It helps promote Service Level Requirements
general awareness of services. (To: A24 A243)
Requirements with regard to service levels that are
Service Level Feasibility Request requested by the customer and which, if agreed, will
(From: A243) have to be attained by the service provider.
A request to specific IT processes (often those in the
Resilience category) to assess the feasibility of Service Level Stakeholder Register
successful delivery of service against a postulated (From: A242, To: A243 A244 A245 A246)
service level target or commitment. A record (of the customer contacts) with a role to play in
one or more of the activities that comprise the Service
Service Level Feasibility Response Level Management life cycle. This information can also
(To: A243) be useful for other customer relationship purposes.
The assessment by specific IT processes (often those in
Service Management) on the feasibility of achieving Service Marketing and Sales Activity Data
successful delivery of service against a postulated (From: A222 A223 A224 A225 A226 A227 A228, To:
service level target or commitment. A229)
The metrics defined in the Service Marketing and Sales
Service Level Management Activity Data Framework and populated by all work performed within
(From: A242 A243 A244 A245 A246, To: A247) the process, as the basis to evaluate performance of the
Any data about the accomplishment of process activities process.
relevant to the evaluation of the overall service level
management process. Service Marketing and Sales Evaluation
(From: A229, To: A221)
Service Level Management Evaluation An analysis of service marketing and sales activity data
(From: A247, To: A241) providing an understanding of the current success or
An assessment of the overall performance of the process failure of the process, and an identification of potential
against the targets set in the process framework, and an process improvements.
Service Marketing and Sales Framework
Service Level Management Framework (From: A221, To: A222 A223 A224 A225 A226 A227
(From: A241, To: A242 A243 A244 A245 A246 A247) A228 A229)
The framework that contains all relevant information The overall scheme of policies, practices, plans,
about the structure of the Service Level Management processes, and procedures designed to govern and
process. It guides the operation of the process, and optimize all activities for Service Marketing and Sales.
includes the following information:
– Classes of agreements under which SLAs can be Service Metric Data and Reports
established, indicating attributes to be included and (From: A6, To: A2 A24 A244 A7 A71 A716 A8 A81
the desired range of values for each A814 A815 A83 A832)
– Norms for working relationships with SLA
stakeholders
– General approach for working with other processes 15. ITIL V3 Glossary
•
•
•
Service Outage Analysis – Service Request Routing Information
Significant service delivery event logs, volume, and other – Standard terms and conditions
measurement data relating to how effectively and – Individual actual and proposed terms and conditions
efficiently services are provided by IT. This data, which is for a specific customer
available as requested both in raw format and as
structured reports, is a component of all operations Service Provider Review Input
information and is the basis for service level reporting. (To: A245 A246)
Prioritized improvement suggestions for service level
Service Outage Analysis attainment by the service provider, i.e. the service
(From: A736, To: A664 A737) delivery units, and responses as to the feasibility of
The results from identifying root causes of service adopting customer or service level manager
outage, assessing the effectiveness of service suggestions.
availability, and identifying key recommendations for
improving availability. There is a corresponding Service Request
technique described in the ITIL Service Delivery, (From: A65 A653, To: A61 A612)
Availability Management book. A request to perform a standard and straightforward IT
task for a user. Service requests are tasks that are within
Service Package Specific Catalog Requirements the scope of existing IT services.
(From: A232, To: A233 A234) ITIL definition: “A request from a User for information, or
Each service package can have customizations for advice, or for a Standard Change or for Access to an IT
different environments, industries, or integration with Service. For example to reset a password, or to provide
technologies. These requirements must be captured and standard IT Services for a new User. Service Requests
incorporated into the solution. are usually handled by a Service Desk, and do not
Service Price Model require an RFC to be submitted.” 16
(From: A833, To: A255)
Service Request Escalation
The service price model describes all inputs needed (for (From: A615, To: A612)
example, service model, measures, service levels,
Information about a service request that has not been
customer) to derive a price for a delivered service. It is
fulfilled in ways that meet satisfaction criteria and which
often presented as a multidimensional matrix, with one
requires escalation.
dimension for each input. It describes as output one
price for each combination. Service Request Fulfillment Information
(From: A613, To: A614 A615)
Service Pricing and Contract Administration Activity
Data Information about a service request that has been
(From: A832 A833 A834 A835, To: A836) successfully fulfilled.
Focuses on data needed to analyze how to improve the Service Request Reports
process performance. (From: A615, To: A244 A518 A616)
Service Pricing and Contract Administration Any reports that reflect the status of service requests
Evaluation with the purpose to control the quality of service
(From: A836, To: A831) fulfillment, the compliance with existing SLAs, for
planning purposes and as a basis for improvements.
Is a report combining how the process performance can
be improved and how especially the pricing model can Service Request Response
optimize the overall IT usage. (From: A61)
Service Pricing and Contract Administration The interim and final outcomes of the service request,
Framework which can be many aspects, including:
(From: A831, To: A832 A833 A834 A835 A836) – The information requested by the user
Describes the foundational framework for Service Pricing – A request for more information or an
and Contract Administration, including descriptions of acknowledgement of a milestone within the request
the following aspects of the process: processing
– Strategic (vision, mission, value proposition) – Status of the work effort triggered by the request,
– Organizational (organizational mechanisms, roles, including plans to address the work items contained
accountabilities) in the request
– Process (activities, workflows, inputs, outputs) Service Request Routing Information
– Technology (software, hardware) practices for (From: A613, To: A614 A615)
managing customer transformation Details of how the work represented by the service
request has been assessed and planned for fulfillment by
Service Pricing and Contract Information
or to be passed to one or more other processes. The
(From: A83, To: A22 A226 A227 A24 A243 A365 A81
details include:
A813 A814 A815)
– Services and price list (the complete service price
model) 16. ITIL V3 Glossary
•
•
•
Service Request Status – Services Proposal
– The request classification, including the cases where processes which will lead to an improvement in, or
the request has been re-classified as an incident or a correction of, any aspect of service.
change request
– The process and specific team or individual where Service Resilience Plans
the work has been assigned (From: A7, To: A2 A22 A221 A24 A243 A246 A25 A255
A26 A265 A266 A3 A35 A353 A354 A36 A364 A5 A52
Service Request Status A522 A523 A53 A532 A6 A61 A611 A62 A621 A63
(From: A615, To: A614) A632 A64 A641 A65 A651 A66 A661)
The status of a service request (received, work in The collection of plans produced by the individual
progress, resolved, or closed). Used to communicate the processes involved in ensuring the resilience within
information to the user (originator of the request). service management. Processes contributing are:
– Compliance Management
Service Request Status Input – Security Management
(To: A614 A615)
– Availability Management
Details, from any process involved in processing the
– Capacity Management
service request, on status and plan to complete the work
involved. It can include a request to obtain more – Facilities Management
information or some form of acknowledgement from the – IT Service Continuity Management
user. (See the definition of the plan output from each individual
process for more details.)
Service Request_ Approved
(From: A612, To: A613 A615) Service Resilience Reports
A service request which has met the classification and (To: A24 A244 A662)
entitlement rules and which includes all the information The collection of reports produced by the individual
needed for fulfillment. It is ready to be fulfilled or routed. processes which are involved in ensuring the resilience
within service management. Processes contributing are:
Service Request_ Authorized – Security Management
(From: A6 A61 A613, To: A5 A53 A535 A55 A552 A62 – Availability Management
A622 A63 A67 A7 A72 A75)
– Capacity Management
The communication of a service request which has
(See the definition of the 'report' output from each
completed screening and is being passed to one or more
other processes for actual fulfillment. It includes control
information from the screening (assessment) such as These reports detail the volumes, attainments, issues
priority assigned and committed completion target. outstanding and other characteristics detailing the
performance and contribution to the overall delivery of
Service Request_ Closed service. They include efficiency reviews and audit
(From: A614, To: A615) reports.
A service request for which all fulfillment activities have
Service Review Results
been completed and information about the fulfillment has
(From: A24 A245, To: A242 A243 A246 A25 A256 A27
been captured.
A273 A356)
Service Request_ Fulfilled The outcome from a review of service level attainment.
(From: A613) This might include:
A service request that has been fulfilled within the – Exceptions and violations with regard to target and
Request Fulfillment process or in the processes to which actual service delivery
it had been routed. Is either the actual fulfillment itself – Determination of responsibility for non-attainment
(for example, service usage guidance), or just – Identification of penalties incurred
information about the work carried out elsewhere (such
as notification of incident resolution or confirmation of Services Agreement
software download and installation). (From: A22 A227, To: A23 A233 A234 A834)
A contractual agreement between IT provider and
Service Request_ Rejected customer with the intent to exchange a set of committed
(From: A612) deliverables from the provider for a price to be paid by
A service request that is not accepted as falling into one the customer, under a set of agreed terms and
of the pre-defined categories for requests or which fails conditions.
the entitlement tests. An example of this would be a new
requirement for functionality (for which the user should Services Marketing and Sales Collateral
be guided to invoke the Stakeholder Requirements (From: A224, To: A225 A226)
process). Items used to promote the proposed solution to a
customer.
Service Resilience Directives
(From: A72 A74 A76, To: A62 A622 A623 A63 A632) Services Proposal
The collection of commands, instructions or other (From: A22 A226, To: A227 A834)
requests from Resilience processes to the Operations A document outlining a potential services solution to
meet a specific set of customer needs.
•
•
•
Skill Requirements – Solution Analysis and Design Activity Data
Skill Requirements agreed Service Level Targets in an SLA.”19

(From: A842 A843, To: A844) These agreements can be in a draft or finalized status.
Forecast of human skills required to meet the demand for
services in the IT Portfolio. Solution Acceptance Activity Data
(From: A452 A453 A454 A455 A456, To: A457)
Skills Inventory Performance and quality data regarding activities
(From: A844, To: A621 A622 A842 A843) performed in executing the Solution Acceptance
Repository for current and planned skills. Process.
Skills Plan Solution Acceptance Certification
(From: A84 A844, To: A371 A843 A85 A852) (From: A455, To: A456)
Projection of skills needed, including indicating where The record (document) containing the formal certification
training is required. For skills identified to be developed by authorized, designated stakeholders that the solution
through external means, this represents a requisition to meets acceptance criteria.
procurement.
Solution Acceptance Criteria
SLAs OLAs UCs (From: A453, To: A454)
(From: A2 A24 A243, To: A22 A223 A226 A227 A244 The complete set of criteria that the stakeholder
A245 A246 A25 A254 A26 A265 A27 A271 A273 A3 community will use to certify their acceptance of the
A35 A354 A355 A4 A41 A412 A413 A414 A45 A453 solution produced.
A454 A5 A51 A511 A514 A515 A52 A522 A525 A53
For the special case of solution that is a service, ITIL
A532 A534 A536 A538 A6 A61 A612 A615 A62 A621
defines Service Acceptance Criteria as: “A set of criteria
A63 A632 A64 A641 A65 A651 A66 A661 A663 A665
used to ensure that an IT Service meets its functionality
A667 A67 A671 A7 A72 A723 A726 A727 A73 A732
and Quality Requirements and that the IT Service
A734 A74 A741 A742 A743 A744 A745 A75 A751
Provider is ready to Operate the new IT Service when it
A76 A762 A763 A764 A766 A8 A81 A814 A815 A82
A823 A83 A834 A84 A842) has been Deployed.”20
The agreements that represent the interlinked set of Solution Acceptance Evaluation
commitments for the service utility and warranty that is to (From: A457, To: A451)
be provided to one or more customers. The agreement
between the customer and the organizational unit that The effectiveness and efficiency of the practices
directly provides the service is known as a service level performed in executing the Solution Acceptance
agreement (SLA) and is visible to the customer. The process.
agreements that represent the commitments of the Solution Acceptance Framework
collective set of internal organizational units and external (From: A451, To: A452 A453 A454 A455 A456 A457)
entities to provide identified sub-components of the
The conceptional structure describing the strategic
overall service are known as operational level
(vision, mission, value proposition), organizational
agreements (OLAs). OLAs are not usually visible to the
(organizational mechanisms, roles, accountabilities),
customer. Contractual statements of the commitments
by external entities are known as underpinning contracts
technology (software, hardware) practices to be used in
(UCs).
– SLA: “An Agreement between an IT Service Provider Solution Acceptance Plan
and a Customer. The SLA describes the IT Service, (From: A452, To: A453 A454 A455)
documents Service Level Targets, and specifies the The (sub) project plan which identifies the approach,
responsibilities of the IT Service Provider and the activities and tasks, responsibilities, and schedule for
Customer. A single SLA may cover multiple IT presenting the proposed solution to the stakeholder
Services or multiple Customers.”17 community for evaluation and acceptance. Includes
– OLA: “An Agreement between an IT Service Provider identification of stakeholders.
and another part of the same Organisation. An OLA
supports the IT Service Provider's delivery of IT Solution Acceptance Review Results and Issues
Services to Customers. The OLA defines the goods (From: A45 A454, To: A452 A453 A455)
or Services to be provided and the responsibilities of The collected set of documentation which describes the
“fit-for-purpose” characteristics of the Solution
both parties.”18
Acceptance work products and any issues identified as a
– UC: “A Contract between an IT Service Provider and result of executing solution acceptance reviews.
a Third Party. The Third Party provides goods or
Services that support delivery of an IT Service to a Solution Analysis and Design Activity Data
Customer. The Underpinning Contract defines (From: A422 A423 A424 A425, To: A426)
targets and responsibilities that are required to meet

•
•
•
Solution Analysis and Design Evaluation – Solution Development and Integration Environment
The collection of summary level history and status of A661 A662 A67 A671 A7 A72 A723 A73 A734 A736
Solution Analysis and Design activities. Typically used to A75 A752 A76 A764 A8 A84 A844)
establish and update organizational performance Solution design, including conceptual, macro, and micro
benchmarks (estimates versus actual), transmit quality designs, together with identified issues and risks, and
information, and other heuristics related to Solution formally validated and approved (signed off) by the key
Development processes. stakeholders. It not only covers all the functional and
non-functional requirements of the solution, but also the
Solution Analysis and Design Evaluation design for meeting the compliance reporting
(From: A426, To: A421) requirements applicable to the solution.
The collection of summary level history and status of the
Solution Analysis and Design Framework. Typically used Solution Design Additional Information Request
to establish and update organizational performance (From: A422)
benchmarks (estimates versus actual), transmit quality Solicitation to the stakeholders for additional information
information, and other heuristics related to Solution required to complete the solution design (further
Development processes. clarification of requirements).
Solution Analysis and Design Framework Solution Design Change Proposal
(From: A421, To: A422 A423 A424 A425 A426 A733) (From: A425, To: A422 A423 A424)
The logical structure describing the strategic (vision, Proposed changes to the solution design resulting from
mission, value proposition), organizational review of solution design work products with
(organizational mechanisms, roles, accountabilities), stakeholders against the solution requirements.
technology (software, hardware) practices for solution Solution Design Package
analysis and design. (From: A42 A424, To: A425 A43 A432 A434 A435
A436 A437 A44 A442)
Solution Analysis and Design Results and Issues The collection of all the work products created during
(From: A42 A422 A423 A424 A425, To: A422 A423 solution design.
A424)
The collected set of documentation describing the fit-for- Solution Design Request
purpose characteristics of the Solution Acceptance work (From: A52 A523 A53 A533, To: A42 A422)
products, and any issues identified as a result of A formal communication that authorizes and triggers the
executing solution acceptance reviews. Solution Analysis and Design process (usually beginning
at the conceptual design level).
Solution Assembly
(From: A43, To: A44 A443 A444 A45 A456 A542 A543) Solution Design Stakeholder Acceptance Request
The collection of all the work products created during (From: A425)
solution development and integration, including A request to stakeholders for review, confirmation and
prototypes or implementation of parts of a solution for formal sign-off of solution design.
evaluation and analysis purposes.
Solution Design Stakeholder Acceptance Response
Solution Capabilities and Operational Procedures (To: A425)
(To: A621) A formal acceptance and sign off or rejection by
The capabilities and operational procedures deployed as stakeholders of solution design.
part of current solutions. These might require further
development and tuning in order to reach optimal Solution Design_ Conceptual
effectiveness as part of Service Execution. (From: A422, To: A423)
(Subset of Deployed_ Solution.) High level view (architectural view) of the solution,
including initial versions of component model,
Solution Component Specifications operational model, high-level architectural overview, and
(From: A423, To: A424) architectural decisions.
Formal specification for all the solution components
prepared in a prescribed way in agreement with Solution Development and Integration Activity Data
organization-wide procedures and standards. (From: A432 A433 A434 A435 A436 A437, To: A438)
The collection of detailed history and status of Solution
Solution Components Development and Integration activities. Typically used to
(From: A434, To: A435) establish and update organizational performance
All the work products, acquired or built in-house, required benchmarks (estimates versus actual), transmit quality
to complete the solution build, which will remain as information, and other heuristics related to Realization
integrated parts of the solution (opposite to supporting processes.
parts).
Solution Development and Integration Environment
Solution Design (From: A433, To: A434 A435 A436)
(From: A4 A42 A425, To: A3 A33 A336 A34 A343 A344 The entire infrastructure required to complete the
A45 A454 A5 A51 A514 A52 A523 A54 A542 A6 A61 solution build process, including the tools, supporting
A611 A62 A621 A63 A632 A64 A641 A65 A651 A66
•
•
•
Solution Development and Integration Evaluation – Solution Requirements Results and Issues
work products (scaffolding), and physical configuration and other heuristics related to Solution Realization
control repository for the solution work products. processes.
Solution Development and Integration Evaluation Solution Requirements

(From: A438, To: A431) (From: A413, To: A414)
Formal evaluation of the performance of the project Documented, analyzed and expanded (formalized)
specific activities against the defined performance solution requirements.
criteria and measurements within the Solution Build
Framework. Solution Requirements Activity Data
(From: A412 A413 A414 A415, To: A416)
Solution Development and Integration Framework The collection of detailed and summary level history and
(From: A431, To: A432 A433 A434 A435 A436 A437 status of Solution Requirements activities. Typically used
A438) to establish and update organizational performance
Common, organization wide Solution Development and benchmarks (estimates versus actual), transmit quality
Integration policies, standards, procedures and information, and other heuristics related to the Solution
templates. Requirement process.
Solution Development and Integration Plan Solution Requirements Baseline

(From: A432, To: A433 A434 A435 A436 A437) (From: A41 A415, To: A42 A422 A423 A44 A442 A444
Formally defined following a prescribed, organization A45 A453 A712)
wide procedure, set of tasks and activities together with Established according to prescribed organizational
a time frame required to perform solution development standards, it is a baseline of all the Solution
and integration. Usually a part of a larger project plan. Requirements work products currently under
Configuration Management.
Solution Development and Integration Results and
Issues Solution Requirements Baseline Change Request
(From: A43 A433 A434 A435 A436 A437, To: A432 (To: A415)
A433 A434 A435 A436) Formal request following prescribed organizational
The collection of summary level history and status of procedure to change a baseline of the Solution
Solution Development and Integration activities and work Requirements work products currently under
products. Typically used to establish and update Configuration Management.
organizational performance benchmarks (estimates
versus actual), transmit quality information, and other Solution Requirements Change Proposal
heuristics related to Realization processes. (From: A415, To: A412)
Proposed changes to the business context resulting from
Solution Plans and Commitments changes in solution requirements baseline.
(From: A4 A41 A42 A422 A425 A43 A432 A44 A442
A45 A452, To: A2 A25 A255 A256 A26 A265 A3 A33 Solution Requirements Defect List
A336 A35 A353 A354 A37 A374 A375 A42 A422 A43 (From: A414, To: A413)
A432 A44 A442 A45 A452 A454 A5 A52 A522 A6 A62 Formal list of discrepancies between documented and
A621 A7 A73 A732 A74 A742) formalized solution requirements and solution intentions
The collective overall information on both the as perceived by the key stakeholders (customer).
development plan for the solution and the content of the
solution as it progresses from concept to reality. Solution Requirements Evaluation
– Plans: Sets of committed solution phases, activities, (From: A416, To: A411)
tasks and milestones together with time frame. The collection of summary level history and status of
– Commitments: Sets of requirements, designs and Solution Requirements Framework. Typically used to
other deliverables, such as test cases. establish and update organizational performance
benchmarks (estimates versus actual), transmit quality
Solution Project Plan information, and other heuristics related to Solution
(From: A414) Realization processes.
The overall project plan augmented by solution-specific
Solution Requirements Framework
content as a result of completion of requirements
(From: A411, To: A412 A413 A414 A415 A416)
validation.
Common, organization wide Solution Requirements set
Solution Realization Results and Issues of standards, procedures and templates.
(From: A4, To: A354 A4 A41 A412 A413 A414 A415
A42 A422 A423 A424 A425 A43 A432 A433 A434 Solution Requirements Results and Issues
A435 A436 A437 A44 A442 A443 A444 A445 A45 (From: A41 A412 A413 A414 A415, To: A412 A413
A452 A454 A455) A414)
The collection of summary level history and status of The collection of summary level history and status of
Solution Realization activities and work products Solution Requirements activities and work products.
throughout their life cycle. Typically used to establish and Typically used to establish and update organizational
update organizational performance benchmarks performance benchmarks (estimates versus actual),
(estimates versus actual), transmit quality information,
•
•
•
Solution Requirements Stakeholder Validation Request – Solution_ Installed
transmit quality information, and other heuristics related Any additional issues identified during test results
to Solution Realization processes. analysis that need to be recognized and perhaps
addressed.
Solution Requirements Stakeholder Validation
Request Solution Test Report
(From: A414) (From: A44 A445, To: A45 A454)
A request to stakeholders for review, confirmation and The collected test data, results and analysis of the
formal sign-off of solution requirements. Solution and environment under consideration. Includes
test cases, defective test cases.
Solution Requirements Stakeholder Validation
Response Solution Test Results
(To: A414) (From: A444, To: A445)
Solution validation responses as communicated by the The outcomes (results) of applying the selected test
stakeholders. Cover both the positive and negative cases to the Solution Build Package.
cases, with the latter being considered a 'defect'.
Solution Test Results and Issues
Solution Requirements_ Validated (From: A44)
(From: A414, To: A415) The collected set of documentation which describes the
Solution scope, context and entire taxonomy of “fit-for-purpose” characteristics of all of the Solution Test
requirements formally validated and approved (signed activity work products and any issues identified as a
off) by the key stakeholders. result of executing the Solution Test process.
Solution Scope and Context Solution Test Strategy and Plans

(From: A412, To: A413) (From: A442, To: A443 A444 A445 A446)
Solution framing and surroundings defined by the A description of the strategies to be employed and the
business and system environments. (sub) project plan which identifies the approach,
activities and tasks, responsibilities, and schedule for
Solution Test Activity Data testing various aspects of the solution as it is designed,
(From: A442 A443 A444 A445, To: A446) built and integrated.
Performance and quality data regarding activities
performed in executing the Solution Test process. Solution Verification Request
(From: A437)
Solution Test Cases Formal request to verify (verification ensures that “you
(From: A442, To: A443 A444) built it right”) the integrated solution by all the relevant
The collection of test cases, that is, the description of stakeholders.
what is to be tested, why, how (including sample data)
and expected outcomes of the testing. Solution Verification Results
(To: A437)
Solution Test Environment Formal list of the entire positive (successful) and
(From: A443, To: A444) negative (deviations) from the standards and procedures
The functional environment constructed and allocated to identified during the verification process.
support testing of a specific solution.
Solution_ Accepted
Solution Test Environment Baseline (From: A4 A45 A456, To: A5 A52 A523 A53 A533)
(From: A443, To: A445) The Solution which has been approved by the
A reference point specification of the functional stakeholder community, and is now ready to be
environment used to support testing of a specific deployed.
solution.
Solution_ Deployed
Solution Test Evaluation (From: A5 A53 A536, To: A3 A32 A4 A43 A433 A44
(From: A446, To: A441) A443 A6 A62 A63 A634 A64 A641 A7 A76)
The effectiveness and efficiency of the practices The new or adjusted solution in 'live' status, ready for
performed in executing the Solution Test process. useful work within its target environment, and reflecting
the outcome of the deployment activities.
Solution Test Framework The deployed solution includes documentation,
(From: A441, To: A442 A443 A444 A445 A446) procedures, training materials, support guidance as well
The conceptional structure describing the strategic as the primary solution contents.
(vision, mission, value proposition), organizational
(organizational mechanisms, roles, accountabilities), Solution_ Installed
process (activities, work flows, inputs, outputs), and (From: A535, To: A536)
technology (software, hardware) practices to be used in A solution under deployment for which all tasks required
achieving the objectives of the Solution Test process. to achieve deployment status have been completed other
than final activation.
Solution Test Issues
(From: A445, To: A442 A443 A444)
•
•
•
Solution_ Integrated – Supplier Management Framework
Solution_ Integrated An assessment of the overall performance of the process

(From: A435, To: A436) against the targets set in the process framework and an
Completely assembled solution ready to be moved from identification of possible process improvement areas.
the development and integration environment and into
the test environment. Usually includes work products Stakeholder Requirements Management Framework
and features required to support solution testing and (From: A211, To: A212 A213 A214 A215)
acceptance. The framework that governs how the process operates to
capture, track, and communicate stakeholder needs and
Solution_ Tuned requirements.
(From: A436, To: A437)
Integrated solution after refining and fine tuning the Stakeholder Requirements Status Update
overall solution as well as solution components and (To: A214)
connections between them. Performed according to a Notifications from any process which addresses these
prescribed, organization wide procedure. requirements as to their status, especially when there it
changes in some way.
Solution_ Verified
(From: A437) Standard Change
Integrated solution after verification by all the relevant (From: A513, To: A516)
stakeholders with all the verification issues (deviations Those changes which have been pre-approved for
from standards and procedures) formally resolved. deployment. They include well known and proven tasks,
and have no or limited (and well understood) impact on
Stakeholder Needs the integrity of the target context, such as the
(From: A212, To: A213) infrastructure. These changes will also have all
Conditions describing any stakeholder need for services. entitlement issues, like financial approvals, and licensing
already resolved.
Stakeholder Needs and Requirements Report Implementation can be either user-driven or managed by
(From: A214) the IT function. Examples include:
Document outlining the IT service provider's – Installation of printer drivers from a preinstalled
interpretation of the customers' and other stakeholders' library on a PC
service needs and requirements. It also provides – Download and installation of software or fixes from
information about the status and progress of individual or vendor sites
sets of needs or requirements.
– Upgrade of a laptop with a larger hard drive
Stakeholder Needs_ Disqualified
Strategic IT Value Propositions
(From: A213, To: A214)
(From: A314, To: A315)
Needs that do not have the proper business justification
A statement of value, scope and time scale for each
or are assessed as beyond technical feasibility.
strategic IT initiative.
Stakeholder Requirements
Supplier Input
(From: A2 A21 A213, To: A214 A22 A222 A26 A264 A3
(From: Outside-the-Model, To: A8)
A35 A352 A36 A364 A365 A4 A41 A413 A7 A73
A732) The complete set of items from suppliers to the IT
endeavor. The set includes:
The qualified needs for IT services that are to be
progressed through the Portfolio process for decision – Bids
making. – Procured items
These needs might be in a form suitable for direct – Invoices
translation into solution requirements and should include – Product and support information.
stakeholders' acceptance criteria.
Supplier Invoices
Stakeholder Requirements Information Request (To: A81 A814 A82 A824)
(From: A413) Invoices from the suppliers for products and services
Solicitation of requirements information from the delivered to IT.
stakeholders, usually for clarification or expansion of
stakeholder requirements already registered. Supplier Management Activity Data
(From: A822 A823 A824 A825 A826, To: A827)
Stakeholder Requirements Management Activity Any data about the accomplishment of process activities
Data that support the evaluation of the overall Supplier
(From: A212 A213 A214, To: A215) Management process.
activity. Examples would be volumes, timings, resources Supplier Management Framework
used, success and error rates, interfaces invoked, (From: A821, To: A751 A822 A823 A824 A825 A826
rework, customer feedback, priorities. A827)
The framework that contains all relevant information
Stakeholder Requirements Management Evaluation about the structure of the Supplier Management
(From: A215, To: A211) process, meaning the practices for supplier management
•
•
•
Supplier Management Performance Evaluation – Underpinning Contracts
and procurement. This includes evaluation criteria for

selection and evaluation of suppliers, and relevant
T
systems. Target Market Segment Requirements
Supplier Management Performance Evaluation (To: A234)
(From: A827, To: A821) Requirements for specific industries, user communities,
The result of the evaluation of the Supplier Management or executive sponsors are used to tailor or customize the
process, including identification of potential process description of the services.
improvement items. Technology Capabilities and Trends
Supplier Output (To: A31 A313 A32 A322 A323 A33 A333 A34 A341
(From: A8, To: Outside-the-Model) A342 A343 A85 A852)
Represents all interactions from the IT endeavor to any Available external data, both uncoordinated and already
supplier. Constituents include: analyzed, of world class IT technologies available,
declining, and emerging.
– Bid requests
– Purchase orders Test Environment Specifications
– Payments (From: A442, To: A443)
– Other communications Based on the requirements and design of each solution
and on the selected, customized test strategy and plans,
Supplier Payments this is a specification of the test environment that will
(From: A81 A814, To: A816) support the required testing.
Payments to suppliers, triggered by supplier invoices, for
services delivered to IT. Training Requirements
(From: A843, To: A844)
Supplier Performance Data Statement of the purpose, timing and quantities of
(To: A825) training needed to properly equip the workforce for their
Data from any IT process that relates to the performance current and future work assignments.
of any supplied product or service that contributes to that
process Tuning and Capacity Delivery Allocation Outcomes
(From: A744, To: A745)
Supplier Performance Evaluation The results of tuning and capacity delivery allocation
(From: A825, To: A822 A824) activities upon balancing resource supply with workload
Evaluation of suppliers with regard to the relationship, demand. Some actions will be considered sufficiently
compliance with agreed contract conditions including permanent to influence the overall capacity plan.
costs. Input for management of portfolio of suppliers.
Supplier Performance Issue U

(From: A825, To: A822 A823)
Exceptions or non-compliance of suppliers with regard to Unavailable Product and Service Exceptions
the agreed contracts that are recognized during Evaluate (From: A826, To: A822 A824)
Supplier Performance, and that are needed as input for Information about exceptions (unavailability, permanent
Manage Portfolio of Suppliers so that the supplier or temporary) of supply items that can influence
portfolio can be adapted if necessary. procurement or require that the portfolio of suppliers is
adapted.
Supplier Portfolio
(From: A822, To: A823 A824 A826) Underpinning Contracts
List of potential suppliers. Includes information about (From: A8 A82 A823, To: A1 A11 A114 A2 A24 A241
each supplier (relationship) with regard to supply items, A243 A3 A31 A313 A5 A55 A555 A81 A813 A814
existing contracts, and the interfaces to this supplier. A824 A825 A826)
Content of contracts with suppliers, including terms and
Supplier Product and Service Information conditions, service level agreements (SLAs), among
(From: A826, To: A662 A664 A735 A736 A824) others. Covers both the actual contract itself, and
Information about the items (products, services) that can information about it that is available as input for supplier
be supplied by the suppliers in the portfolio, like the evaluation and to other internal processes, such as
catalog of orderable supply items including financial management.
– Prices Information Technology Infrastructure Library (ITIL)
– Service levels defines underpinning contract as “a contract between an
– Supply options, (suppliers can supply these supply IT service provider and a third party. The third party
items) provides goods or services that support delivery of an IT
service to a customer. The underpinning contract defines
Covers both external and internal suppliers. An example
targets and responsibilities that are required to meet
of an internal supplier: Facility supplier indicates lead-
time and costs for equipping a new workspace. agreed service level targets in an SLA.” 21
•
•
•
User Input – Workforce Management Activity Data
User Input The basic unit of work of an IT service or work request,

(From: Outside-the-Model, To: A6) ready to be processed.
The collection of all information and items a user
generates and sends to the IT undertaking in furtherance Work Item Schedule
of their need to receive the committed service. Examples (From: A622, To: A623 A624)
include: Control information on the combination of the work item,
– Sequences that invoke transactions or other kinds of the required IT resources, and the timing parameters
services (typically from an application). They might and instructions which enable matching of work
be accompanied by user data. demands with resource supply.
– Contact, through human or electronic channels, Work Item_ Multi Phase
which represent: (From: A624, To: A622)
à Requests for information A partially-completed output created by Deliver Services
à Expressions of any apparent fault (which might that flows internally within the process. The output would
become an incident) signify that other service execution activities would need
à Service requests to be started. An example of this complex work item is a
payroll application: a new employee is added, the new
User Output employee can create a new work item to add a new
(From: A6, To: Outside-the-Model) person to an enterprise employee directory. The
The collection of all service deliverables which the IT directory update service is triggered by the payroll
endeavor generates and delivers to the user to meet the addition service.
committed service. Examples include:
– Processing of business transactions (in whole or in Work Requests
part) through IT system-provided means. (To: A62 A622)
– The delivery of relevant outputs, such as: An unqualified request for processing services involving
– Transaction completion status IT resources. To be accepted for processing, it must
contain sufficient detail in order to match it against the
– Data resulting (for example, delivery of an e-mail
list of existing services and to determine the
message)
characteristics (parameters) of this specific request.
– Contact through human or electronic channels, which Work requests can range from highly granular individual
satisfy or resolve: interactions (pressing a function key on a PC) to a large
à Requests for information clump of work (a long running batch job, perhaps with
à Expressions of any apparent fault (which might many dependent steps and subsequent, dependent
become an incident) jobs).
à Service requests
(From: A62 A624)
V The results, in terms of data and any confirmation
responses, returned to the work requestor upon
Viable Innovation completion of the triggering request for work to be
(From: A32 A325, To: A31 A314 A35 A352 A36 A364) performed by the IT operational service. This output
Any innovations that seem viable to be adopted by the IT represents the fundamental item for which the customer
service provider in order to enhance the service to the is paying; that is, the processing of transactions whether
business (IT Architecture, the IT Portfolio, IT Strategy). real time or batched.
The information provided will include analysis and Can include negative outcomes, such as unsuccessful
assessment of the potential impact to the business, and processing, resource authorization failure, and resource
to the parameters of the IT service provision, stated in insufficiency.
terms of ideas, value and viability.
Work Requests_ Rejected
(From: A622)
W Notification that the request does not comply with work
Work Data Input request acceptance criteria, and therefore was rejected.
(To: A62 A624) Workforce Adjustment Requisition
The data that is submitted along with a work request and (From: A843)
which has not yet been processed (so that it becomes The plans and requirements for adjustments (increase
managed data). It could have been captured in many and decrease) in workforce numbers and job profiles.
ways of which keyboard, magnetic card reader, barcode Might be relevant to either or both of the business'
reader, RFID tag are just some examples. workforce management process and to the procurement
Work Item process.
(From: A622, To: A624) Workforce Management Activity Data
(From: A842 A843 A844, To: A845)
The metrics defined in the Workforce Management
21. ITIL V3 Glossary Framework and populated by all work performed within
•
•
•
Workforce Management Evaluation – Workforce Plan
the process, as the basis to evaluate performance of the technology (software, hardware) practices for managing
process. customer satisfaction.
Workforce Management Evaluation Workforce Management Information
(From: A845, To: A841) (From: A84 A842 A843 A844, To: A365 A373 A374
An assessment of the overall performance of the process A81 A813 A814 A815)
against the targets set in the process framework and an Profiles of current managed workforce including
identification of possible process improvement areas. performance reviews, skills, training and compensation.
Workforce Management Framework Workforce Plan

(From: A841, To: A842 A843 A844 A845) (From: A842, To: A843)
The conceptional structure describing the strategic Forecast of human workload associated with business
(vision, mission, value proposition), organizational requirements or changes, and the subsequent plan for IT
(organizational mechanisms, roles, accountabilities), resources in support of the demand.
•
•
•

PRM-IT v3.0 Reference Library

Uploaded by

Copyright:

Available Formats

PRM-IT v3.0 Reference Library

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PRM-IT v3.0 Reference Library

Uploaded by

Copyright:

Available Formats

PRM-IT V3 Reference Library - Consolidated

PRM-IT Version 3.0

General Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GIM-1

[A0] Manage IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A0-1

[A1] Governance and Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1-1

[A2] Customer Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2-1

[A3] Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3-1

[A4] Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4-1

[A5] Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5-1

[A6] Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6-1

[A7] Resilience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7-1

[A8] Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A8-1

IDEFØ Node Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . N-1

IDEFØ Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1

About this book

Figure 1. Unified Process Framework for IT (UPF-IT)

1. FIPS 183: Integration Definition for Function Modeling, December 1993.

Introducing the IBM Process Reference Model for IT

Growth targets at risk

Inadequate enabling Internal workforce issues

Inflexible physical and IT

Figure 2. Top ten inhibitors to innovation

Beyond ITIL: Driving IT management process excellence

Dimensions of IT management process excellence

CobiT – provides tools to

Baldrige Award – assessment

ISO 9000 – requirements on the

CMMI – consists of best

Six Sigma – uses root cause

Figure 3. Frameworks for IT process excellence

PRM-IT evolves IT management process frameworks beyond operational efficiency to investment

CobiT – provides tools to

Baldrige Award – assessment

ISO 9000 – requirements on the CMMI – consists of best

Figure 4. Adding PRM-IT to the process frameworks

Principles and design points for the model

Alignment with ITIL

PRM-IT provides a formal treatment of the more conceptual process

ITIL processes are presented in a single integrated model, resolving

Alignment with other reference frameworks

6. See http://www.sei.cmu.edu/cmmi/general/index.html for more information on CMMI.

eSourcing Capability Model

Component Business Model for the Business of IT

9. Further information on CBM-BoIT is available at http://www-935.ibm.com/services/us/imc/pdf/g510-6163-compo-

business disciplines. Definitions of specific architectures or technologies must be done within

International Standard for Process Description

10. See ISO/IEC TR 24774:2007 at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnum-

A first look at the model

Viewpoint of the model

The context and scope of PRM-IT

Figure 5. Comprehensive and effective activity sets in PRM-IT

Drilling into the model: The process categories

Figure 6. PRM-IT process categories

The categories convey several concepts:

The processes for the business of IT

A–1 Governance and Management System A–5 Transition

A–2 Customer Relationships

Figure 7. PRM-IT processes

Mapping PRM-IT processes to ITIL

A–1 Governance and Management System A–5 Transition

Highlights areas within IT services delivery requiring improvement

Primary responsibility for contractual relationships with either customers or suppliers

A262 Understand IT Customer Context

Communicating constraints and decision criteria agreed with customers transparently

A33 Architecture Management

The portfolio meets business needs

Generating test results

Only authorized releases are introduced into the live environment