itilv3 intermediate - itpreneurscampus.itpreneurs.com/itpreneurs/lpengine/itil...intermediate the...

Introduction, Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Request Fulfilment, Service Evaluation, Knowledge Management, Technology and Implementation Management, Exam Preparation Guide, Introduction, Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Request Fulfilment, Service Evaluation, Knowl-edge Management, Technology and Implementation Management, Exam Preparation Guide, Introduction, Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Request Fulfilment, Service Evaluation, Knowledge Management, Technology and Implementation Management, Exam Preparation Guide,

®

STUD

ENT

HAN

DBO

OK

Versi

on 1

.2

REFERENCE MATERIAL

Service Transition

ITILv3Intermediate

The information contained in this classroom material is subject to change without notice. This material contains proprietary information that is protected by copyright. No part of this material may be photocopied, reproduced, or translated to another language without the prior consent of ITpreneurs Nederland B.V.

© Copyright 2010 by ITpreneurs Nederland B.V. All rights reserved.

ITIL® Qualification Scheme Copyright © 2007 APM Group. All rights reserved. Glossaries/Acronyms © Crown Copyright Office of Government Commerce. Reproduced with the permission of the Controller of HMSO and the Office of Government Commerce.

The language used in this course is US English. Our sources of reference for grammar, syntax, and mechanics are The Chicago Manual of Style, The American Heritage Dictionary, and the Microsoft Manual of Style for Technical Publications.

ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the

Office of Government Commerce, and is Registered in the U.S. Patent and Trademark Office. ITIL®V3 - Published for the Office of Government Commerce under license from the Controller of Her Majesty’s Stationery Office © Crown Copyright 2007. The Swirl logo™ is a Trade Mark of the Office of Government Commerce. The OGC logo® is a Registered Trade Mark of the Office of Government Commerce. All content in italics and quotes ©Crown Copyright 2007 Reproduced under licence from OGC.

All infographics © Crown Copyright 2007 Reproduced under licence from OGC, unless otherwise noted.

EXIN, the Examination Institute for Information Science, is a global, independent IT examination provider offering qualification programs for ISO/IEC 20000, ISO/IEC 27000, ITIL®, MOF, ASL, BiSL, TMap® and SCP. It’s EXIN’s mission to improve the quality of the IT sector, the IT professionals and the IT users, by means of independent testing and certification.

Contents

iii

Course INTroduCTIoN .................................. 10Student and Instructor Introductions ............... 11Unique Nature of The Course .......................... 11Course Learning Objectives ............................13Exam Requirements ........................................14

Course AgeNdA (Refer to the Workbook)

uNIT 1: serVICe TrANsITIoN ......................... 171.1 Service Transition as a Practice ................181.2 Service, Its Value Proposition, and its

Composition ...............................................201.3 Functions, Processes, and Roles ..............221.4 Purpose, Goals, and Objectives ...............271.5 Scope of Service Transition and its

Processes ..................................................291.6 Position of Service Transition Within the

Service Lifecycle ........................................331.7 Potential Value to the Business .................38

iv

uNIT 2: serVICe TrANsITIoN PrINCIPLes .......................................... 40

2.1 Purpose, Goals, and Objectives ...............412.2 Concept of Service and

Role of Utilities, Warranties, Capabilities, and Resources ......................43

2.3 Key Policies and Best-Practice Principles .............................49

2.4 Group/Individual Exercise ..........................572.5 Sample Test Question ...............................57

uNIT 3: serVICe TrANsITIoN ProCesses .......................................... 58

3.1 Objectives of the Processes ......................593.2 Transition Planning and Support ..............593.2.1 Purpose, Goals, and Objectives ............603.2.2 Scope and Value to the Business ..........613.2.3 Policies, Principles,

and Basic Concepts ...................................623.2.4 Process Activities, Methods, and

Techniques ................................................703.2.5 Trigger, Inputs, and Outputs ..................783.2.6 KPIs ........................................................793.3 Change Management ................................803.3.1 Purpose, Goals, and Objective ...............813.3.2 Scope and Value to the Business ..........81

v

3.3.3 Policies, Principles, and Basic Concepts ...................................88

3.3.4 Process Activities, Methods, and Techniques ..............................................100

3.3.5 Triggers, Inputs, Outputs, and Inter-process Interfaces ........................... 118

3.3.6 KPIs and Metrics .................................1273.4 Service Asset and Configuration

Management ............................................1313.4.1 Purpose, Goals, and Objectives ...........1313.4.2 Scope and Value to the Business ........1333.4.3 Policies, Principles, and

Basic Concepts ........................................1353.4.4 Process Activities, Methods,

and Techniques .......................................1533.4.5 Trigger, Inputs, and Inter-process

Interfaces .................................................1823.4.6 KPIs and Metrics .................................1843.5 Release and

Deployment Management .......................1873.5.1 Purpose, Goals, and Objectives ..........1873.5.2 Scope and Value to the Business ........1893.5.3 Policies, Principles, and

Basic Concepts ........................................1913.5.4 Process Activities, Methods, and

Techniques ..............................................202

vi

3.5.5 Trigger, Inputs, Outputs, and Inter-process Interfaces ....................231

3.5.6 KPIs and Metrics .................................2343.6 Service Validation and Testing ................2363.6.1 Purpose, Goal, and Objectives ............2373.6.2 Scope and Value to the Business ........2383.6.3 Policies, Principles, and


Techniques ..............................................2683.6.5 Triggers, Inputs, Outputs,

and Inter-process Interfaces ....................2753.6.6 KPIs and Metrics .................................2793.7 Evaluation Process ..................................2833.7.1 Purpose, Goals, and Objective ............2833.7.2 Scope and Value to the Business ........2843.7.3 Policies, Principles, and


Techniques ..............................................2863.7.5 Triggers, Inputs, and Output ................2893.7.6 KPIs and Metrics .................................2903.8 Knowledge Management .........................2913.8.1 Purpose, Goals, and Objectives ..........2923.8.2 Scope and Value to the Business ........293

vii

3.8.3 Policies, Principles, and Basic Concepts ........................................295

3.8.4 Process Activities, Methods, and Techniques ..............................................300

3.8.5 Inter-process Interfaces ........................3133.8.6 KPIs and Metrics .................................3153.9 Group/Individual Exercise ........................3193.10 Sample Test Questions ..........................319

uNIT 4: serVICe TrANsITIoN reLATed ACTIVITIes ........................ 320

4.1 Goal .........................................................3214.2 Managing Communications and

Commitment ............................................3214.3 Managing Organizational and

Stakeholder Change ................................3334.3.1 Organizational and Service Transition

Roles and Responsibilities ......................3374.3.2 Planning and Implementing

Organizational Change ............................3444.3.3 Assessing and Monitoring

Organizational Readiness and Change Progress .....................................353

4.3.4 Methods, Practices, and Techniques Used to Manage Change ........................357

4.4 Stakeholder Management .......................3674.5 Group/Individual Exercise ........................377

viii

4.6 Sample Test Question .............................377

uNIT 5: orgANIzINg for serVICe TrANsITIoN ........................................ 378

5.1 Goals .......................................................3795.2 Service Transition Roles and

Responsibilities ........................................3805.2.1 Generic Roles .......................................3805.2.2 Specific Roles .......................................3825.3 Organizational Context for Service

Transition .................................................4135.4 Relationship of Service Transition with

Other Lifecycle Phases ............................4175.5 Group/Individual Exercise ........................4205.6 Sample Test Question .............................420

uNIT 6: TeChNoLogy CoNsIderATIoNs ... 4216.1 Goals .......................................................4226.2 Service Transition Technology

Requirements ..........................................4226.2.1 Knowledge Management Tools ............4256.2.2 Collaboration.........................................4266.2.3 Configuration Management System .....4296.3 Group/Individual Exercise ........................4336.4 Sample Test Question .............................433

ix

uNIT 7: ImPLemeNTINg ANd ImProVINg serVICe TrANsITIoN ....................... 434

7.1 Goals .......................................................4357.2 Stages of Introducing

Service Transition ....................................4357.2.1 Justification ...........................................4377.2.2 Design ...................................................4397.2.3 Managing Cultural Change, Risks,

and Beneficial Values ..............................4437.3 CSFs and KPIs ........................................4457.4 Challenges and Risks Affecting

New or Changed Services .......................4487.5 External Factors Affecting the

Approach to Service Transition ...............4517.6 Group/Individual Exercise ........................4597.7 Sample Test Question .............................459

uNIT 8: exAm PrePArATIoN guIde (Refer to the Workbook)Appendix A: Case Study .............................460Appendix B: Mind Map Exercise ..................483Appendix C: Glossary ................................. 486Appendix d: Syllabus ..................................638Appendix e: Answers (N/A)

10Copyright © 2010, ITpreneurs Nederland B.V. All rights reserved.

Table of Contents

ITIL v3 Intermediate Certification Level | ST | Course Introduction

Course INTroduCTIoNService Transition is one of the five courses that are part of the ITIL Intermediate Lifecycle stream. The ST course helps you understand and implement ITIL best practices related to Service Transition as a practice, purpose, goals, objectives and scope of Service Transition and Its Processes, the position of Service Transition within the Service Lifecycle, the Service Transition processes, Service- Transition related –activities, organizing for Service Transition, technology considerations, and implementation and improving Service Transition.

While going through the course, you may come across the following challenges:

y Difficulty in understanding the concepts taught because applying “best practices” is unfamiliar territory.

y Overcoming the influence of “too much experience” in your current way of operating and any changes required with ITIL v3.

To overcome these challenges during the training program, you should list down your expectations from the course, which may range from passing the exam to wanting to implement the Changes in your organization. Discuss these expectations with your instructor when you get access to them so that at the end of the program, you will have the skills to apply your new practical experience back at the workplace.


Table of Contents


sTudeNT ANd INsTruCTor INTroduCTIoNsGet to know the other participants, and your instructor. Feel free to ask your instructor about their experience and background in IT and IT Infrastructure Library (ITIL®).

Please introduce yourselves by stating: y Your name and profession. y Your role and background in IT. y Your familiarity with ITIL. y What you expect to learn over the next few days.

uNIQue NATure of The CourseThis training course is delivered through a unique blend of self-paced and instructor-supported learning and high intensity, fast paced classroom delivery.

This e-learning provides an intuitive and learner centric method to learn the key concepts and theory of the ITIL v3 Intermediate Course. Innovative use of e-learning for the theoretical components of the course allows you to study in your own time at your own pace.

Interactive Classroom sessions are focused on practical application of the material you learn through exercises, quizzes, assignment and group discussions. The classroom sessions would also provide a re-cap of the course content covered in Elearning. This classroom training is not designed in the traditional mode of “technical training,” where the instructor presents lecture on slide after slide. Instead, you are expected to


Table of Contents


participate in the learning experience through many discussions and exercises and the sharing of practical experiences. This is to ensure that you internalize the learning, as required, to sit for your final examination successfully, and to apply your new practical experience back at the workplace.

It is critical therefore, that you spend some time on the self-paced elearning to understand the key concepts required for this level, and for this course. Your knowledge of the contents will be directly proportionate to the benefits you will derive from the classroom sessions, since the practical exercises assume prior knowledge of content.

Please note that Exam preparation training is included in the classroom workshop as well in e-learning.

Your student kit for this training courseware consists of three components:

elearning course: Contains the theoretical components of the course along with Sample Test Questions at the end of each unit. Each unit may end with Sample Test Questions. These questions have been created based on the same format as the certification exam.

The last unit in the e-learning is the Exam Preparation Guide (EPG). EPG contains important tips to help you prepare your exam, and two mock exams for practice. Elearning also consists of a Summary Map, in the form of a detailed Mind Map to recap the course outline and recall the course in an easy manner.


Table of Contents


student reference material: Contains all the concepts that the Elearning covers (except for EPG). Students can use the Reference Material to study each evening, after class, to prepare for the final exam.

student Workbook: Contains the “Course Agenda” of all course variants offered by ITpreneurs and all the classroom exercises (including Sample Test Questions) and the Mock Exams students have to attempt in class. Answers to these questions are given in Answers: Appendix E at the end of the Workbook.

Course LeArNINg oBjeCTIVesAt the end of this training, you will have gained the knowledge and skills to:

y Understand the importance of the Service Management as a Practice concept.

y Understand the importance of the principles, purpose, and objectives of Service Transition.

y Learn how all processes in Service Transition interact with other Service Lifecycle processes.

y Recognize the subprocesses, activities, methods, and functions used in each ITIL Service Transition process.

y Recognize the roles and responsibilities within Service Transition and the activities and functions required to achieve operational excellence.

y Learn how to measure Service Transition.


Table of Contents


y Understand the technology and implementation considerations surrounding Service Transition.

y Outline the challenges, Critical Success Factors (CSFs), and Risks associated with Service Transition.

exAm reQuIremeNTsCourse Prerequisites:

y For the Capability courses, there is no minimum mandatory experience requirement but 2 to 4 years’ professional experience working in IT Service Management is highly desirable.

y For the Lifecycle courses, there is no minimum experience requirement but basic IT literacy and around 2 years’ IT experience are highly desirable.

exam requirements: y duration: 1.5 hours; should the exam not be written in

the student’s first language, an extra 30 minutes will be granted along with the use of a dictionary

y Questions: Eight multiple-choice questions; each question with four answer options: one that is worth 5 marks, one that is worth 3 marks, one that is worth 1 mark, and one that is a distracter and receives no marks

y format: Closed-book, online, or paper-based examination y Pass score: 28/40 or 70% y distinction score: Not defined yet


Table of Contents


y Contact hours: 21-hour formal training with Accredited Training Organization (ATO)

y Personal study hours: 21 hours; must read “The Royal Case Study” to be able to do the exercise

useful Tips for Writing the exam: y Review the syllabus in your course material. y Use the syllabus to focus your study within the identified

chapters in the core ITIL books to prepare for these exams.

y The exam is written to a depth where you not only need to have a strong core competency in the ITIL v3 best practice, but also, you need to be able to apply this knowledge in practical scenarios.

y Read the question CAREFULLY. y Remember that there will be qualifiers such as NOT and

BEST. y Make note of the unique business situation presented –

this scenario may point you in the direction of the “best” answer from the list.

y As far as possible, try to eliminate the incorrect distracter question by using your ITIL theory and assessment of the provided information.

y Use your ITIL theory to assist with answering the question and selecting the best remaining answers from which to choose.


Table of Contents


y Because this exam is gradient marked, you will most likely find very close similarities with the remaining answers.

y If you are stuck on a question, skip it and move to the next one.

y As you progress through the exam, you will pick up the rhythm of the structure and the language of the questions.

y When in doubt, guess – you will not lose marks for providing the wrong answer.


Table of Contents

ITIL v3 Intermediate Certification Level | ST | Service Transition

Unit 1: Service tranSitionoverviewService Transition is required for all types of organizations because each organization displays some transition or the other. In conjunction with other Lifecycle phases, Service Transition helps deliver and manage Changes in an organization. Service Transition helps deliver Services that meet business needs, are cost-effective and efficient, with minimum Risk and maximum optimization.

However, Service Transition requires the effective use of management skills to manage knowledge, organization, and transition in all situations. Each Change can make or break an organization’s success. As a result, Service Transition streamlines the transition process and makes the Changes effective and efficient to minimize Risks and delays. Service Transition does not end with the Service going live. It works in conjunction with Service Operations to support Services early in their Lifecycle.

This unit discusses the Service Transition phase of the Service Lifecycle. It explains the concept of Service Management as a practice, its value proposition and composition, and its functions, processes, and roles. It also explains how Service Transition benefits the business as a whole.

At the end of the unit, you will be familiar with the processes and functions of the Service Transition phase and its value in managing Changes in an organization.


Table of Contents


Unit Learning objectivesAt the end of this unit, you will be able to:

y Understand Service Transition as a practice. y Understand Service, its value proposition and it

composition. y Describe the functions, processes and roles of Service

transition. y Understand the purpose, goals, and objectives of Service

Transition. y Define the scope of Service Transition and its Processes y Understand the position of Service Transition within the

Service Lifecycle y Describe the potential value to the business

1.1 Service tranSition aS a Practice“Service Management is a set of specialized organizational capabilities for providing value to customers in the form of Services.”

(Source: Service Transition book)

Specialized capabilities What, according to you, are the “specialized capabilities” of an organization?

The “specialized capabilities” of an organization are the capabilities that make the organization unique in the competitive market.


Table of Contents


example of Specialized capabilitiesAn automobile industry’s specialized capability will be the unique way in which the industry develops capabilities to overcome the challenge of smaller scale and financial capital. In the 1950s, Toyota developed this unique capability in production engineering, Operations Management, and Supplier Management to compensate for its inability to afford large inventories, make components, produce raw materials, or own companies that produce them. This specialized capability made Toyota take over the American automobile industry and till today, Toyota continues to be a world market leader in the production of automobiles.

capabilities and resourcesWhat is the difference between capabilities and resources?

Resources are typically an organization’s holdings.

Capabilities are typically experience-driven and information-based abilities.

If resources are an organization’s property or holding, can you say that both resources and capabilities lie with the organization’s employee?

Yes, you can. Here is how. When you first recruit a person in an organization, that person is a resource (we often refer to people as resources). However, on the first day of a new job, that


Table of Contents


person is not fully functional in the job role. The new employee is not aware of processes, organizational requirements, specific business knowledge, and so on. It is only after several months on the job that the employee becomes experienced, acquires information, and becomes fully functional. At this point, the employee becomes part of the capability of the company.

Both resources and capabilities are types of Service Assets. Organizations use these assets to provide goods and Services. This process of providing goods and Services creates value.

As a result, you can say that Service Management is the art of transforming available resources into valuable Services by making full use of the organization’s capabilities.

1.2 Service, itS vaLUe ProPoSition, and itS comPoSitionService — “A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and Risks.”



Table of Contents


Manager

(Operations)

Manager

(Strategy)

I believe services are means of

delivering value by facilitating outcom

es customers w

ant to achieve w

ithout the ownerships of specific

costs and risks.

Well, services facilitate outcom

es by having a positive effect on activities, objects and tasks, to create conditions for better perform

ance. As a result, the probability of desired outcom

es is higher.

No, they cannot, but w

hat they can do is let the provider take ow

nership. That’s really w

hy it is a service. If customers

manage it all by them

selves, they w

ouldn’t need a service would they?

I must ask, do you have a definition

for services?

What w

ould that mean in operational

terms? G

ive me a few

handles.

But w

ithout the ownership of costs

and risks? Custom

ers cannot wish

them aw

ay.

Aha! B

ecause the provider is specialized w

ith capabilities for dealing w

ith those costs and risks.

And also because the provider can

possibly spread those costs and risks across m

ore than one customer.

Yes, and also because the customer

would rather specialize in those

outcomes.

Let’s write a book on service

managem

ent!!

(A casual conversationat the water cooler)

Adopted from a conversation about the definition and meaning of services

© C

rown C

opyright 2007 Reproduced under licence from

OG

C


Table of Contents


Good ServiceWhat, according to you, is “good Service?”

Note that Service is a value proposition that makes it possible to achieve specific outcomes by improving the performance of associated tasks and reducing the effect of constraints.

examples of ServiceBusiness focus, technology focus, and crossover functions, such as e-mail, are all types of Services.

1.3 FUnctionS, ProceSSeS, and roLeSFunctionWhat is a function in the context of ITIL?

According to ITIL, a function is a unit that has special capabilities to perform particular types of work to produce specific outcomes. A function also has the specialized resources needed to generate the outcomes. Specialized capabilities include an organization’s methods and body of knowledge while specialized resources include various roles with expert knowledge.

What do functions do?

Functions: y Provide structure and stability to organizations. y Are self-contained units of organizations, with their own

capabilities and resources.


Table of Contents


y Rely on processes for cross-functional coordination and control.

y Have their own knowledge base, built from experience. y Can result in functional silos if there is a lack of

coordination or an inward focus.

Processa process is a set of structured activities designed to accomplish a specific objective. There are clearly defined inputs, activities, and results, along with documented process roles and a continual improvement loop. What is important to note is that the processes within Service Management are at the core of creating value for the stakeholders in an organization.


Table of Contents


SuppliersActivity 1

Activity 2

Activity 3

Custom

er

Desired

outcome

Service control and quality

Trigger

Data, inform

ation,and know

ledgeProcess

Adopted from a basic process ©

Crow

n Copyright 2007 R

eproduced under licence from O

GC


Table of Contents


What do processes do?Processes:

y Create value for all stakeholders. y Take one or more inputs and turn them into defined

outputs. y Include all the roles, responsibilities, tools, and

management controls (measures and metrics) to deliver the outputs.

Process control is the activity of planning and regulating a process, with the objective of performing the process in an effective, efficient, and consistent manner.

ITIL is very specific around the concept of a process as a closed-loop system. What defines a closed-loop system is that it is self-corrective and self-reinforcing. Open-loop systems are designed for purpose and do not respond well to Changes while the feedback loop in closed-loop systems allows for corrections.

An example of this concept from Service Strategy is a furnace. A furnace is designed to work extremely well; however, without thermostatic control, it cannot respond to a change in temperature. The thermostat allows this to become a closed-loop system to regulate heat output based on changes in weather.


Table of Contents


People often mistake functions for processes. A process is a systematic series of actions directed to some end. In fact, well-defined processes improve the efficiency and performance of a function. Take the example of Capacity Management. People often think it is a process name. However, Capacity Management is simply an organizational capability that follows a specific set of processes and work methods.

Process characteristicsSome common characteristics of processes are:

y Can be measured and are performance driven. y Deliver individually identifiable and countable results. y Deliver and meet their customer or stakeholder

expectations. y Are triggered by a specific event.

rolea role is the set of responsibilities, activities, and authorities defined in a process and assigned to a person or team. It is correct to say that roles exist within functions. Each role has an associated accountability and is responsible for a specific outcome. When all roles within a function work effectively, the function can generate its target outcome successfully.

The categorization of functions, processes, and roles depends on the organization’s structure and design. In a large organization, a Capacity Manager process could also be a Capacity Manager job on an organization chart. On the other hand, in a smaller or


Table of Contents


differently structured organization, it could simply be recognized as a documented Capacity Management process with the process role of Capacity Manager mapped to a standard IT job function.

Remember RACI from your Foundation training?r Responsiblea Accountablec Consultedi Informed

RACI is an authority matrix that can be used within organizations to indicate roles and responsibilities in relation to processes and activities.

An accountability matrix, such as a RACI chart, created as per ITIL best practices, will clearly let every team member know who is supposed to do what and can be used to identify activity overlaps and gaps within the documented ITIL processes.

a c t i v i t Y i n W o r K B o o K

1.4 PUrPoSe, GoaLS, and oBjectiveSPurposeThe purpose of Service Transition includes:

y Plan and manage the capacity and resources required to package, build, test, and deploy a Release into production.

y Establish the Service according to specified customer and


Table of Contents


stakeholder requirements y Provide a consistent and accurate framework to evaluate

the capability of the Service and the associated Risks before releasing and deploying a Service.

y Ensure the integrity of all identified Service Assets and configurations throughout the Service Transition Lifecycle.

y Provide well-organized, repeatable build and installation mechanisms that can be used to deploy Releases to the test and production environments. These mechanisms can also be rebuilt if you need to restore a Service.

y Ensure that the Service is managed, operated, and supported in agreement with the requirements and constraints defined within Service Design.

y Provide knowledge and information so that effective decisions can be made to efficiently promote a Release from the test environment into production.

GoalsThe following are the goals of Service Transition:

y Set customer expectations of the performance and use of the new or changed Service. In addition, Service Transition provides information on how the new or changed Service can be used to enable business Change.

y Reduce deviations in actual performance from the predicted performance of transitioned Services.


Table of Contents


y Reduce Known Errors and minimize the associated Risks when the new or changed Services are transitioned to production.

y Ensure that the Service can be used in agreement with the requirements and constraints defined within the Service requirements.

objectivesThe objectives of Service Transition are:

y Plan and manage the resources to transition a new or changed Service into production per predicted cost, quality, and time estimates.

y Ensure minimal, unpredicted Impact on the production Services, operations, and support organization.

y Increase the satisfaction of customers, users, and Service Management staff with respect to Service Transition practices, which includes new or changed Service Deployment, communications, Release documentation, training, and knowledge transfer.

y Ensure the proper use of Services and underlying applications and technology solutions.

y Provide clear and detailed plans that help the customer and the business change projects align their activities with Service Transition plans.

1.5 ScoPe oF Service tranSition and itS ProceSSeS


Table of Contents

ITIL v3 Intermediate Certification Level | ST | Service TransitionC

ontinual Service Im

provement

Change M

anagement (4.2)

RFC1RFC2

RFC3RFC4

RFC5R

FC6

Service A

sset and Configuration M

anagement (4.3)

BLBL

BLBL

BLBL

BL

Service Transition Planning and Support (4.1)

Oversee m

anagement of organization and stakeholder change (5)

Evaluation of a Change or Service (4.6)

E1E2

E3

ServiceStrategy

ServiceDesign

Plan andpreparerelease

Build andtest

Servicetesting and

pilots

Plan andprepare fordeploym

ent

Transfer,deploy,retire

Review andclose service

transition

ServiceO

peration

Early Life Support

Service Validation and Testing (4.5)

Release and Deployment

Managem

ent (4.4)Knowledge Managem

ent (4.7)

ITIL process in thispublication that supportsthe whole service life cycle

Other ITIL core

publicationFocus of activityrelated toService Transition

Point to Evaluate the Service Design

Point to capture Baseline

Request for ChangeR

FC

BL E

Adapted from the scope of Service transition © Crown Copyright 2007 Reproduced under licence from

OG

C


Table of Contents


Scope of Service transitionThe scope of Service Transition is:

y Manage and coordinate processes, systems, and functions to package, build, test, and deploy a Release into production.

y Ensure that all new or changed Services fulfill the requirements of customers and stakeholders.

However, you may also come across some Service Changes that are not included in Service Transition. For example, you may not perform activities related to Release, build, test, and acceptance planning when you transfer a set of Services from one organization to another.

Service Transition manages the testing of processes in the Service Lifecycle.

Service Level Management (SLM) enables you to meet customer expectations and manage them during Service Transition. Incident and Problem Management enable you to handle Incidents and Problems during testing, pilot, and deployment activities. However, some activities are not included in the Service Transition scope.


Table of Contents


example of activities not included in the Service transition ScopeMinor modifications to the production Services and environment. For example, replacement of a failed PC or printer or installation of standard software on a PC or server or for a new user.

Ongoing Continual Service Improvement (CSI) that does not affect Services or the Service Provider’s capability to deliver Services. For example, Request Fulfilment activities that are driven from Service Operations are not included in the Service Transition scope.

Service transition ProcessesThe two types of Service Management processes that Service Transition uses are:

y Processes that support the Service Lifecycle: Processes such as Change Management, SACM, and Knowledge Management are critical during transition. However, they also affect and support all other Lifecycle stages.

y Processes within Service transition: Processes such as Transition Planning and Support, Release and Deployment Management, Service Testing and Validation, and Evaluation are included in the Service Transition phase.


Table of Contents


1.6 PoSition oF Service tranSition Within the Service LiFecYcLe

a c t i v i t Y i n W o r K B o o K

Adapted from itiL core © Crown Copyright 2007 Reproduced under licence from OGC

ContinualService

Improvement ServiceTransition

ServiceDesign

ServiceOperation

ServiceStrategy


Table of Contents


Purpose of each Lifecycle PhaseIn this scenario, we have seen how each phase in the Service Lifecycle has a purpose. For example, if there is no Strategy, how does the Service Provider know that it is doing the right things and that there is an ROI for the customer?

If you do not have a Design, how do you provide the right Utility and Warranty for your Services?

If you do not have Transition, how are you managing Changes, assessing Impact, conducting the appropriate level of testing, and so on?

If you do not have Operation, how will you handle Incidents in a timely way, find root causes, and so on?

And if you do not improve (CSI), how will you prevent your Services from degrading over time? In addition, IT will cease to contribute effectively to the business.

Service transition inputsIn the Service Lifecycle, Service Transition is positioned between Service Design and Service Operations. As a result, all the major day-to-day operations and interfaces are within these stages. However, Service Transition also interfaces with other stages of the Service Lifecycle. These interactions are defined by the input and output that flow between the different stages.


Table of Contents


The inputs received by Service Transition from Service Strategy influence the overall approach, structure, and constraints in the Service Transition stage. Some of the inputs include:

y “Service Portfolio y Customer portfolio y Contract portfolio y Service Lifecycle model y Policies y Strategies y Constraints y Architectures y Service Transition requirements y Service Management Plan (as required by ISO/IEC

20000)”


components of Service design PackagesService Design plays an important role in initiating the work elements in Service Transition. In other words, Service Design provides the Service Design Packages (SDPs) that need to be transitioned. The SDPs include the following components:

y “Service definition y Service structure (including core and supporting Services) y Financial/economic/cost model (with Total Cost of

Ownership/Total Cost of Utilization)


Table of Contents


y Capacity/resource model – combined with performance and availability

y Service Management integrated process model (as in ISO/IEC 20000)

y Service Operations model (includes support resources, escalation procedures and critical situation handling procedures)

y Design and interface specifications y Release design y Deployment plan y Acceptance Criteria – at all levels at which testing and

acceptance have been foreseen y Requests for Change (RFCs) to instigate required

Changes to the environment within which the Service functions or will function”


request for changeThe main input, which is the Request for Change (RFC) that initiates the action, comes through Service Design. However, the RFC may also come directly from customers, through a strategy Change or from audit or CSI. The inputs from CSI are suggestions to improve the transition policy, practices, and processes, which are based on different feedback from audit and stakeholders. These suggestions are collated using various methods, such as stakeholder surveys.


Table of Contents


Service transition outputsService Operation, on the other hand, provides inputs to the testing and Service acceptance team. Service Operation verifies whether the Service fulfills the stakeholder’s requirements before delivery.

The outputs of Service Transition are received by Service Operation and the customers or users who use the Services that Service Transition delivers.

Some of the outputs of Service Transition include: y “Approved Service Release Package and associated

deployment packages y Updated Service package or Service bundle that defines

the end-to-end Service(s) offered to customers y Updated Service Portfolio and Service Catalogue y Updated contract portfolio y Documentation for a transferred or decommissioned

Service”


The outputs of Service Transition to CSI include suggestions on Changes that help improve the processes within Service Design, Service Transition, Service Strategy, business, and Relationship Management.


Table of Contents


1.7 PotentiaL vaLUe to the BUSineSSa c t i v i t Y i n W o r K B o o K

Service transition’s value to the Service ProviderService Transition, if followed efficiently, improves the Service Provider’s ability to manage high volumes of Changes and Releases. Service Transition enables the Service Provider to:

y Align the new or changed Service with the business requirements and operations of the customer.

y Ensure that the new or changed Service maximizes the value to the customer’s business operations.

value of Service transitionService Transition adds value to the business by improving:

y “The ability to adapt quickly to new requirements and market developments (‘competitive edge’)

y Transition management of mergers, de-mergers, acquisitions and transfer of Services

y The success rate of Changes and Releases for the business

y The predictions of Service levels and Warranties for new and Changed Services

y Confidence in the degree of compliance with business and governance requirements during Change


Table of Contents


y The variation of actual against estimated and approved resource plans and budgets

y The productivity of business and customer staff because of better planning and use of new and Changed Services

y Timely cancellation or changes to maintenance contracts for hardware and software when components are disposed or de-commissioned

y The understanding of the level of Risk during and after change, e.g. Service outage, disruption and re-work.”



Table of Contents

ITIL v3 Intermediate Certification Level | ST | Service Transition Principles

uNIT 2: serVICe TrANsITIoN PrINCIPLesoverviewService Transition provides guidance and process activities for transitioning Services to the operational environment. Service Transition includes the broader, long-term Change Management role and Release and Deployment practices. As a result, it considers the Risks, benefits, delivery mechanisms, and support of ongoing operational Services. It also provides guidance on designing and implementing the Service and ensures that the Service delivers in accordance with the planned strategy.

In addition, Service Transition manages the complexity of Changes to Services and Service Management processes and prevents undesired consequences while allowing innovation. It also transfers the control of Services between customers and Service Providers.

This unit discusses the key policies and best-practice principles that aid effective Service Transition. It also explains the concept of Service and the role of Utilities, Warranties, capabilities, and resources in delivering the Service.

unit Learning objectivesAt the end of this training, you will be able to:

y Define the concept of Service and the role of Utilities, Warranties, capabilities, and resources in delivering a Service.


Table of Contents


y Describe the key policies and best-practice principles that aid effective Service Transition.

2.1 PurPose, goALs, ANd oBjeCTIVesEach organization needs to transition its designed Services into operations. Service Transition provides the required information to ensure that the Service Design solutions achieve their expectations. Consequently, each organization needs to follow some key Service Transition principles and implement common best practices to ensure the effective transition of Services. Service Transition principles are the same for all organizations. However, different organizations may modify the approach based on their requirements, size, distribution, culture, and resources.

Organizations can achieve this by improving and streamlining the Service Transition processes that a business organization uses to support the deployment of IT.

Purpose:The purpose of Service Transition includes:

y Plan and manage the capacity and resources needed to package, build, test, and deploy a Release into the live environment and launch the Service stated in the customer and stakeholder requirements.

y Provide a steady and exact framework for assessing the Service capability and Risk profile before the release or deployment of a new or changed Service.


Table of Contents


y Establish and sustain the integrity of all identified Service Assets and configurations as they grow through the Service Transition stage.

y Provide excellent knowledge and information so that Change, Release, and Deployment Management can accelerate effective decisions about release promotion through the test environments and into production.

y Provide efficient repeatable build and installation mechanisms for deployment of Releases to the test and production environments and be restored Services needs to be restore.

y Ensure that the Service are managed, operated, and supported according to the requirements and constraints specified within the Service Design.

goals:The following are the goals of Service Transition:

y Set customer expectations on how the performance and use of a new or changed Service can enable business Change.

y Enable the business Change project or customer to integrate a Release into its business processes and Services.

y Reduce variations in the predicted and actual performance of transitioned Services.

y Reduce the Known Errors and minimize the Risks from transitioning the new or changed Services into production.


Table of Contents


y Ensure that the Service can be used in accordance with the requirements and constraints specified within the Service requirements.

objectives:The following are the objectives of Service Transition:

y Plan and manage resources to effectively establish a new or changed Service into production within the calculated cost, quality, and time estimates.

y Ensure a lower degree of unexpected Impact on the production Services, operations, and support organization.

y Increase the satisfaction of customers, users, and Service Management staff with the Service Transition practices, including deployment of the new or changed Service, communications, Release documentation, training, and knowledge transfer.

y Increase correct use of Services and their underlying applications and technology solutions.

y Provide clear and complete plans that allow the customer and business Change projects to align their activities with the plans of Service Transition.

2.2 CoNCePT of serVICe ANd roLe of uTILITIes, WArrANTIes, CAPABILITIes, ANd resourCes


Table of Contents


Custom

ersAdapted from service assets required to deliver services to the business ©

Crown Copyright 2007 Reproduced under licence from O

GC

Businessenvironm

ent

Influence

Bundle of assets

Coordinate,control anddeploy

Value create

Generate returns

on assets consumed

Assets consum

edCategoriesof assets

Goods or

Services

Capabilities

Resources

People

Knowledge

Processes

Organization

Managem

ent

Information

Applications

Infrastructure

Financial capital

Customers


Table of Contents


service Transition PrinciplesService Transition principles help you understand what a Service is and how the Service enables you to improve the business value of an organization. These principles are the foundation of Service Transition and are evolved and strengthened with the help of Service Strategy considerations.

ITIL defines Service value within a business environment as consisting of customers and contracts. The Service Provider or organization owns and controls various tangible and intangible assets. The organization then converts these assets into Services that the customers can use. When converting resources into Services, the organization uses knowledge, skills, experience, processes, systems, and technologies. These resources are intangible assets called capabilities.

A C T I V I T y I N W o r K B o o K


Table of Contents


return onassets

Performance potential

Performance

of serviceassets

return onassets

Capability to serve

Cost to serve

Risks

Com

pensationAsset incom

e

Unused capacity

Dem

and

service levelsdelivered

Performance

of customer

assets

Adapted from services provide value by increasing the performance of custom

er assets and removing risks

© Crown Copyright 2007 Reproduced under licence from

OG

C

Value = Potential increased + risks reducedValue Com

pensationro

A = Compensation/Cost to serve


Table of Contents


AssetsAnother term used to refer to assets is capabilities or resources, depending on the context in which the organization is using the assets. An organization provides Services to deliver value to customers. On the other hand, a Business Unit may also use Services to deliver value to one or more Business Units or its subunits. The Business Units that deliver these Services are known as Service Providers or Service Units and those that use the Services are known as customers or Business Units.

utility and WarrantyThe concepts of Utility and Warranty are important to understand the customer’s perspective of Service value.

service utilityService Utility is the functionality that a product or Service offers to meet a particular need. Utility is often summarized as “what it does.” Service Utility meets customer expectations and needs and removes the existing constraints in a business. It also improves the performance of customer assets and meets business requirements.


Table of Contents


example of use of utilityA good example of the use of Utility is in the lending division of a bank. The Utility of a credit-check Service of the lending division of a bank allows the lending process, which can be considered a customer asset, to decide the creditworthiness of borrowers. This Utility also ensures that the bank approves loan applications quickly, with minimum Risk from the borrowers.

service WarrantyWarranty is a promise or guarantee that the Service will be available and meet customer expectations. In other words, Utility is what the customer gets and Warranty is how it is delivered.

Warranty is provided in terms of Service availability and capacity. It ensures that:

y Customer assets receive Utility continuously, even if at degraded Service levels, through major disruptions or disasters.

y The value-creating potential of customer assets is secure.

Although these characteristics of Warranty are valid for all the Services of an organization, one characteristic may be considered more critical than the others in specific situations. However, in most situations, the important value proposition for Services is high-availability, continuity, and security.


Table of Contents


Service Utility and Warranty together help define the Service Level Package (SLP) that, in turn, is used to create the service design Package (sdP). Within service Transition, the sdP is the plan on which a new or changed service is developed, tested, and transitioned into the live environment.

2.3 Key PoLICIes ANd BesT-PrACTICe PrINCIPLesTo define and implement a formal policy for Service Transition, ITIL states:

“A formal policy for Service Transition should be defined, documented, and approved by the management team, who ensure that it is communicated throughout the organization and to all relevant suppliers and partners.”



other guidelines and Principles In addition to the principles discussed in class, you must follow some other guidelines and principles while defining and implementing a formal policy for Service Transition. Some of these principles and guidelines are:

y Use processes that integrate teams. In addition, blend competencies while maintaining clear lines of accountability and responsibility.


Table of Contents


y Deliver Changes in Releases. y Address deployment issues at an early stage in the

Release Design and Release Planning stages.

Moreover, sponsors and decision-makers who develop the policy must show their commitment to others when adapting and implementing the policy. They must also show their commitment when delivering predicted outcomes from any Change in Services.

ITIL defines the policy for implementing Changes to Services through Service Transition as:

“All changes to the Service Portfolio or Service Catalogue are implemented through Change Management and the changes that are managed by the Service Transition Lifecycle stage are defined and agreed.”



other guidelines and Principles In addition to the principles discussed in the class, you must follow some other guidelines and principles while implementing Changes to Services through Service Transition. Some of these principles and guidelines are:

y Design each Release Package such that it is governed by an RFC that has been raised via Change Management. This helps you control and trace all Releases.


Table of Contents


y Use standardized methods and procedures for the efficient and prompt handling of all Changes. This helps minimize the Impact of Change-related Incidents on business continuity, Service quality, and rework.

y Record all updates to Changes and Releases against Service Assets and/or Configuration Items (CIs) in the Configuration Management System (CMS).

ITIL defines the policy to adopt a common framework and standards as:

“Base Service Transition on a common framework of standard re-usable processes and systems to improve integration of the parties involved in Service Transition and reduce variations in the processes.”



ITIL defines the policy to maximize the reuse of established processes and systems as:

“Service Transition processes are aligned with the organization’s processes and related systems to improve efficiency and effectiveness and where new processes are required, they are developed with re-use in mind.”




Table of Contents


ITIL defines the policy to align Service Transition plans with business needs as:

“Align Service Transition plans and new or Changed Service with the customer and business organization’s requirements in order to maximize value delivered by the Change.”



Principles of service Transition Plans Alignment with Business NeedsWhen you implement the policy to align Service Transition plans with business needs, you need to consider the following principles:

y “Monitor and measure the use of the Services and underlying applications and technology solutions during deployment and early life support to ensure that the Service is well established before transition closure.

y Compare the actual performance of Services after a transition against the predicted performance defined in Service Design with the aim of reducing variations in Service capability and performance.”


ITIL states the policy to establish and maintain relationships with stakeholders as:


Table of Contents


“Establish and maintain relationships with customers, customer representatives, users, and suppliers throughout Service Transition in order to set their expectations about the new or Changed Service.”



ITIL states the policy to establish effective controls and disciplines as:

“Establish suitable controls and disciplines throughout the Service Lifecycle to enable the smooth transition of Service Changes and Releases.”



ITIL defines the policy to provide systems for knowledge transfer and decision support as:

“Service Transition develops systems and processes to transfer knowledge for effective operation of the Service and enable decisions to be made at the right time by competent decision makers.”




Table of Contents


Principles for Knowledge Transfer and decision supportIn addition, you need to follow some principles when you implement the policy to provide systems for knowledge transfer and decision support. Some of the principles are:

y Provide easy access to quality information. This reduces the time spent on searching information, mainly during critical activities, such as handling a major Incident.

y Create and share a definitive source of information across the Service Lifecycle and with stakeholders to improve information quality and reduce the overhead of maintaining information.

y Provide consolidated information to enable Change, Release, and Deployment Management to improve the decision-making process for promoting a Release from the test environment to production.

ITIL states the policy for planning Release and Deployment packages as:

“Release Packages are planned and designed to be built, tested, delivered, distributed, and deployed into the live environment in a manner that provides the agreed levels of traceability, in a cost-effective and efficient way.”




Table of Contents


other PrinciplesSome other principles when implementing the policy to plan Release and deployment packages are:

y Assess and manage the Risks of backing out or remediating a failed Release.

y Measure the success and failure of the Releases packages with the aim of improving effectiveness and efficiency while optimizing costs.

ITIL states the policy to anticipate and manage course corrections as follows:

“Train staff to recognize the need for course corrections and empower them to apply necessary variations within prescribed and understood limits.”



ITIL states the policy to proactively manage resources across Service Transitions as:

“Provide and manage shared and specialist resources across Service Transition activities to eliminate delays.”




Table of Contents


ITIL defines the policy to manage resources across Service Transitions as:

“Establish suitable controls and disciplines to check at the earliest possible stage in the Service Lifecycle that a new or Changed Service will be capable of delivering the value required.”



ITIL defines the policy to assure the quality of the new or changed Service as:

“Verify and validate that the proposed changes to the operational Services defined in the Service and Release definitions, Service model, and Service Design Package can deliver the required Service requirements and business benefits.”



other Principles to Assuring Quality of New or Changes serviceSome more principles that you must adhere to when assuring the quality of a new or changed Service are:

y The management and delivery of test design and execution should be done independently from the Service designer and developer. This increases the


Table of Contents


effectiveness of testing and meets any “segregation of duty” requirements.

y The evaluation of Service Design and the new or changed Service should be done independently to identify the Risks that should be managed and mitigated during the build, test, deployment, and use of the Service.

y The Problem and Configuration Management processes should be implemented across the Service Lifecycle. This measures and reduces the Known Errors caused when you deploy the Releases into production

ITIL defines and implements a formal policy to proactively improve quality during Service Transition, as follows:

“Proactively plan and improve the quality of the new or Changed Service during transition.”



2.4 grouP/INdIVIduAL exerCIseRefer to the Workbook to do the exercise.

2.5 sAmPLe TesT QuesTIoNRefer to the Workbook to do the question.


Table of Contents

ITIL v3 Intermediate Certification Level | ST | Service Transition Processes

uNIT 3: serVICe TrANsITIoN ProCessesoverviewEach organization aims for successful Service Transition. To achieve this success, the IT department develops appropriate capabilities and processes to transition new and changed Services into operations, ensuring that it effectively meets customer requirements while controlling the Risks of failure and disruption. In other words, Service Transition processes help build and deploy new or changed Services successfully. These processes also ensure that you perform Changes to Services in a systematic and coordinated way.

unit Learning objectivesAt the end of this training, you will be able to:

y Identify the Transition Planning and Support process. y Demonstrate the Change Management process. y Describe the Service Asset and Configuration

Management (SACM) process. y Describe the Release and Deployment Management

process. y Analyze the Service Validation and Testing process. y Describe the Evaluation process. y Describe the Knowledge Management process


Table of Contents


3.1 oBjeCTIVes of The ProCessesThis unit discusses the processes and activities on which effective Service Transition depends. These include both Lifecycle processes and those contained within Service Transition. You can achieve effective Service Transition by planning, implementing, and optimizing the Service Transition processes for the successful transition of Services to operations.

objectives: y To build and deploy IT Services. y To ensure that Changes in Services and Service

Management processes are coordinated efficiently.

3.2 TrANsITIoN PLANNINg ANd suPPorToverviewEach organization usually has a defined process to handle technology Changes. However, some organizations do not have a defined process to handle the transition of Services from design to operation. As a result, after organizations design Services, they need to transition them into live operations. To do this successfully, they not only need to plan how to do it but also how to support the Services. The Transition Planning and Support process enables organizations to support Services to operations successfully.


Table of Contents


3.2.1 PurPose, goALs, ANd oBjeCTIVesPurpose:

y Make sure that capacity and resources are well planned to package a release, and build, release, test, deploy, and establish the new or changed Service into production.

y Provide assistance to Service Transition teams and resources.

y Plan the Changes required such that the integrity of all identified customer Assets, Service Assets, and configurations is maintained as they evolve through Service Transition.

y Make sure that the right stakeholders and decision makers are informed about the issues, Risks, and deviations of Service Transition.

y Manage activities across projects, suppliers, and Service teams, as required.

goals: y Plan and coordinate the resources to make sure that the

Service Strategy requirements encoded in Service Design are realized in Service Operations effectively.

y Recognize, manage, and control failure and disruption Risks across all activities of transition.


Table of Contents


objectives: y Plan and coordinate the resources to establish

successfully a new or changed Service into production within the predicted cost, quality, and time estimates.

y Ensure that all parties adopt the common framework of standard reusable processes and supporting systems to improve the effectiveness and efficiency of integrated planning and coordination activities

y Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with Service Transition plans.

3.2.2 sCoPe ANd VALue To The BusINessscopeThe scope of Service Transition Planning and Support activities is:

y Incorporate design and operation requirements into the transition plans.

y Manage and operate Transition Planning and Support activities.

y Maintain and integrate Service Transition plans across the customer, Service, and contract portfolios.

y Manage Service Transition progress, Changes, issues, Risks, and deviations.

y Review all the Service Transition and Release and Deployment plans for quality.


Table of Contents


y Manage and operate the transition processes, supporting systems, and tools.

y Communicate with customers, users, and stakeholders. y Monitor and improve the performance of Service

Transition.

Value to the BusinessThe effective use of Transition Planning and Support improves:

y The Service Provider’s ability to handle high volumes of Changes and Releases across the customer base.

y The alignment of Service Transition plans with the customer, supplier, and business Change project plans.

3.2.3 PoLICIes, PrINCIPLes, ANd BAsIC CoNCePTsA C T I V I T y I N W o r K B o o K

service design Package ContentsService Design, together with customers, external and internal suppliers, and other relevant stakeholders, develops the design of the Service and records and documents it in a Service Design Package (SDP). The SDP includes information such as:

y “The Applicable Service Packages, (e.g. Core Service Package, Service Level Package)


Table of Contents


y The Service specifications y The Service models y The Architectural design required to deliver the new or

Changed Service including constraints y The Definition and design of each Release Package y The Detailed design of how the Service components will

be assembled and integrated into a Release Package y Release and deployment plans y The Service Acceptance Criteria (SAC)”


The Service Transition team requires all this information included in the SDP.

In the previous unit, you learned about various policies that support Service Transition.

In addition to those policies, the Change, Configuration, and Knowledge Management policies also support Service Transition. However, this unit discusses only the Release policy in detail.

release PolicyYou must define the Release policy for one or more Services. The Release policy includes:

y “The unique identification, numbering, and naming conventions for different types of Release together with its description


Table of Contents


y The roles and responsibilities involved at each stage in the Release and deployment process

y The expected frequency for each type of Release y The approach for accepting and grouping Changes into

a Release, e.g. how enhancements are prioritized for inclusion

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

y How the Configuration Baseline for the Release is captured and verified against the actual Release contents, e.g. hardware, software, documentation, and knowledge

y Exit and entry criteria and authority for acceptance of the Release into each Service Transition stage and into the controlled test, training, disaster recovery, and production environments

y Criteria and authorization to exit the Early Life Support (ELS) and handover to Service Operations”


release unit PrinciplesA Release with different types of Service Assets might include many people from the same as well as different organizations. As a result, you must define roles and responsibilities for the handover and acceptance of a Release. However, you can also modify these responsibilities according to specific transitions. You must define the main roles and responsibilities for handover to


Table of Contents


ensure that everyone understands and meets expectations. This also ensures that they not only understand their level of authority but also that of others involved in the Release and Deployment process.

example of a responsibility matrixRefer to the table given below. The table shows an example of a responsibility matrix for an organization that supports client/server applications. The matrix enables you to identify gaps and overlaps. You can also plan and assign typical roles for the future.

“example responsibility matrix for release points during service Transition

Development Controlled test

Release to production Production

Class of object

Released from Accepted by

Authority to Release to live

Accepted and supported by

Purchased package

Application development manager

Test manager Change manager

Operations manager

Customized modules



Operations manager

Physical database Changes


Database administrator

Change manager

Database administrator

Server Server builder Server manager

Change manager

Server manager


Table of Contents




Desktop build (e.g. a new application)

Desktop development manager


Desktop support manager

Desktop application (already built and within operational constraints)

Desktop development manager


Desktop support manager, Change manager


Desktop computers Logistics Desktop

support

Desktop support manager, Change manager


Desktop Service

Service development

Desktop support

Service Level Management (SLM), Desktop support manager, Change manager

SLM, Desktop support manager


Table of Contents




Release/Change authorization

Development manager Test manager

Release manager, Test manager, Operations manager, Desktop support Service, Desk user at each site, Customer stakeholder, Change manager

Service Desk users”


All the Releases must have a unique identifier that Configuration Management and documentation standards use. You must also define Release types because this will enable you to set customer and stakeholder expectations about the planned Releases.

release TypesThe different types of Releases are:

y major releases: Contain a lot of new functionality. Some of the new functionalities are helpful to eliminate temporary fixes to Problems. A major upgrade or Release surpasses all earlier minor upgrades, Releases, and emergency fixes.


Table of Contents


y minor releases: Contain small enhancements and fixes. The organizations might have already issued some of these fixes as emergency fixes. A minor upgrade or Release surpasses all earlier emergency fixes.

y emergency releases: Contain corrections to a small number of Known Errors. At times, they might also contain an enhancement to meet a high-priority business requirement.

A Release policy can also state that you can issue only strict emergency fixes in between formally planned Releases of enhancements and nonurgent corrections.

The given table shows an extract of a Service Release policy for a retail organization:

“extract from a service release policy for a retail organization

SERVICE Release definition*

Naming/Numbering

Frequency/Occurrence

Release Window

Store Service

Type A

Type B or C

Emergency

SS_x

SS_1.x or SS_1.1.x

SS_1.1.1.x

Annual (Feb)

Quarterly

As required

Wednesday 01.00–04.00 hours

Not holiday weekends

Not 1 September to 31 January


Table of Contents


SERVICE Release definition*

Naming/Numbering

Frequency/Occurrence

Release Window

e-store web Service

Type A

Type B and C

Emergency

ESWnnn_x

ESWnnn_1.x

ESWnnn_1.1.x

6 months

Monthly

As required

01.00–02.00 hours

Not holiday weekends

Not 1 October to 10 January

e-store delivery Service

Type A

Type B

Type C

Emergency

ESDnnn_x

ESDSnnn_1.x

ESDnnn_1.1.x

ESDnnn_1.1.1.x

6 months

Quarterly

Monthly

As required

01.00–02.00 hours

Highest level of authorization required during holiday weekends

*Release definitions

Type A Something that Impacts the whole system/Service

Type B A Release that will Impact part of the system, e.g. single sub-system or sub-Service

Type C Correction to a single function

Emergency A Change required to restore or continue Service to ensure the Service Level Agreement (SLA) is maintained”



Table of Contents


3.2.4 ProCess ACTIVITIes, meThods, ANd TeChNIQuesTransition strategyEach organization must decide on the most appropriate approach to Service Transition. This decision should be based on the size and nature of the core and supporting Services and the number and frequency of Releases required. Also, while making decisions, it is important to consider any special needs of the users, for example, whether the organization requires a phased roll-out over an extended period of time. The Service Transition strategy describes the overall approach to organize Service Transition and allocate resources.

service Transition AspectsSome of the aspects to consider when you organize Service Transition are:

y “Purpose, goals, and objectives of Service Transition y Context, for example Service customer, contract portfolios y Scope – What do you include and exclude in the scope y Applicable standards, agreements, legal, regulatory, and

contractual requirements y Organizations and stakeholders involved in transition y Framework for Service Transition y Criteria:

o Entry and exit criteria for each Release stage


Table of Contents


o Criteria to stop or re-start transition activities o Success and failure criteria

y Identification of requirements and content of the new or Changed Service:

o Services to be transitioned with target locations, customers and organizational units

o Release definitions o Applicable SDP including architectural design o Requirements for environments to be used, locations,

organizational and technical o Planning and managing environments, for example,

commissioning and decommissioning y People:

o Assigning roles and responsibilities including approvals

o Assigning and scheduling training and knowledge transfer

y Approach o Transition model including the Service Transition

Lifecycle stages o Plans for managing Changes, assets, configurations

and knowledge � Baseline and evaluation points � Configuration audit and verification points


Table of Contents


� Points where Requests for Change should be raised

� Use of Change windows o Transition estimation, resource and cost planning o Preparation for Service Transition o Evaluation o Release packaging, build, deployment, and ELS o Error handling, correction and control o Management and control – recording, progress

monitoring, and reporting o Service performance and measurement system o Key Performance Indicators (KPI) and improvement

targets y Deliverables from transition activities including mandatory

and optional documentation for each stage o Transition plans o Change and Configuration Management plan o Release policy, plans and documentation o Test plans and reports o Build plans and documentation o Evaluation plan and report o Deployment plans and reports


Table of Contents


o Transition closure report o Schedule of milestones o Financial requirements – budgets and funding”.


Configuration BaselinesYou can use Configuration Baselines to fix a point in time that enables people to refer to and apply Changes easily and clearly. If there is any variance in the proposed Service scope, you must request and manage the Service Strategy requirements and the Service Design baseline through Change Management.

At a minimum, the design and transition teams and stakeholders should accept that they could operate and support Service Design and all the Release Units according to the predicted constraints and environment.

You must plan the Release and Deployment activities in stages because you might not know the details of the deployment at the initial stages. You must develop each Service Transition plan using an already proven Service Transition model, wherever possible. Although Service Design provides the initial plan, the planner allocates specific resources to the Service Transition activities. The planner also modifies any plan to suit any new circumstances. An example is the planner will have to plan for the situation that arises when a test specialist leaves the organization.


Table of Contents


Tasks and Activities included in a service Transition PlanA Service Transition plan describes the tasks and activities required to release and deploy a Release into the test environments and then production. These include:

y “Work environment and infrastructure for the Service Transition

y Schedule of milestones, handover and delivery dates y Activities and tasks to be performed y Staffing, resource requirements, budgets and timescales

at each stage y Issues and Risks to be managed y Lead times and contingency”


Transition deploymentTo deploy the transition by the specified date, the Service Transition planner must allocate resources to each activity and keep track of resource availability. In cases when the resources are not available, the planner might need to review other transition activities and change priorities as required. However, the planner must discuss these Changes with Change and Release Management because they might affect other Changes that are dependent on or a prerequisite of the Release.


Table of Contents


To deploy a Release into production across distributed environments and locations successfully, it is important to have good planning and management. You must maintain an integrated set of transition plans linked to lower-level plans, such as Release, build, and test plans. You must integrate these plans with the Change schedule and Release and Deployment plans. Service Transition can manage and coordinate its resources, such as resource allocation, utilization, budgeting, and accounting, if you establish proper and accurate plans at the beginning.

service Transition Plan ActivitiesThe overarching Service Transition plan must include the following milestone activities:

y Acquire Release components. y Package the Release, and build, test, deploy, evaluate,

and proactively improve the Service through Early Life Support (ELS).

y Build and maintain the Services and IT infrastructure, systems, and environments and the measurement system to support the transition activities.

According to Project Management best practices, you must manage several Releases and deployments as a program and each important deployment as a project. Dedicated staff can carry out the actual deployment. However, a team can be put together to perform this activity as part of broader responsibilities, such as operations. You can deliver the elements of the deployment through external suppliers. These suppliers can deliver the bulk of the deployment effort.


Table of Contents


example of the Bulk delivery of a deployment effortImplementation of an off-the-shelf system, such as an IT Service Management support tool

deployment stepsThe steps you must consider when you plan deployments include the elements that constitute that Service, such as people, application, hardware, software, documentation, and knowledge. Consequently, the deployment contains subdeployments of each type of element that constitutes the Service.

service Transition PlannerThe Service Transition planner must do a quality review of all Service Transitions and Release and Deployment plans. Where possible, the planner must also include a contingency plan based on experience and not because of pressure from the supplier. The lead times may vary seasonally, and you must include this in the planning, especially for long time-frame transitions. In this transition, the lead times may vary between transition stages or between different user locations.


Table of Contents


Tasks of the service Transition Planner The Service Transition planner must verify plans and ask the following questions before starting the Release and Deployment of a Service:

y “Are these Service Transition and Release plans up to date?

y Have the plans been agreed and authorized by all relevant parties, e.g. customers, users, operations and support staff?

y Do the plans include the Release dates and deliverables and refer to related Change requests, Known Errors and Problems?

y Have the Impacts on costs, organizational, technical and commercial aspects been considered?

y Have the Risks to the overall Services and operations capability been assessed?

y Has there been a compatibility check to ensure that the CIs that are to be released are compatible with each other and with CIs in the target environments?

y Have circumstances changed such that the approach needs amending?

y Were the rules and guidance on how to apply it relevant for current Service and Release Packages?

y Do the people who need to use it understand and have the requisite skills to use it?


Table of Contents


y Is the Service Release within the SDP and scope of what the transition model addresses?

y Has the Service Design altered significantly such that it is no longer appropriate?

y Have potential Changes in business circumstances been identified?”


3.2.5 TrIgger, INPuTs, ANd ouTPuTsA C T I V I T y I N W o r K B o o K

Trigger The trigger for a Service Transition is an authorized Request for Change (RFC).

InputsThe inputs for Service Transition are:

y Authorized RFC y SDP y Release Package definition and design specification y Service Acceptance Criteria (SAC)

outputsThe outputs for Service Transition are:

y Transition strategy y Integrated set of Service Transition plans


Table of Contents


3.2.6 KPIs A C T I V I T y I N W o r K B o o K

KPIs The following are the primary KPIs for Transition Planning and Support:

y “The number of Releases implemented that met the customer’s agreed requirements in terms of cost, quality, scope, and Release schedule, which is expressed as a percentage of all Releases

y Reduced variation of actual vs. predicted scope, quality, cost and time

y Increased customer and user satisfaction with plans and communications that enable the business to align their activities with the Service Transition plans

y Reduction in number of issues, Risks, and delays caused by inadequate planning

y Improved Service Transition success rate through improved scope and integration of the planning activities

y Better management information on the predicted vs. actual performance and cost of Service Transition

y Improved efficiency and effectiveness of the processes and supporting systems, tools, knowledge, information and data to enable the transition of new and Changed Services, e.g. sharing tool licenses


Table of Contents


y Reduction in time and resource to develop and maintain integrated plans and coordination activities

y Project and Service team satisfaction with the Service Transition practices”


3.3 ChANge mANAgemeNToverviewOrganizations might need to change IT Service Delivery for various reasons. The client, whether internal or external, might want to reduce costs, increase the efficiency of existing systems, reduce errors, or adapt to changed work circumstances. Each reason requires some Changes in the IT system. Changing an existing system is a Risk because the Changes might lead to errors, breakdowns, or business loss.

It is imperative that you manage these Changes in a well-defined, planned manner to:

y Reduce Risk exposure. y Minimize the severity of any Impact or disruption. y Correctly implement the Change at the first attempt.

If you manage Changes using a planned approach, you will be able to save money and time for your organization.


Table of Contents


3.3.1 PurPose, goALs, ANd oBjeCTIVePurpose:

y To use standardized methods and procedures to handle Changes efficiently and promptly

y To record all Changes to Service Assets and Configuration Items (CIs) in the Configuration Management System

y To optimize and reduce business Risk

goals: y Respond to changing customer business needs while

increasing the value of the IT Service and reducing Incidents, disruption, and rework.

y Respond to business and IT Change requests.

objective: y Ensure that you record, evaluate, authorize, prioritize,

plan, test, implement, document, and review Changes in a controlled manner.

3.3.2 sCoPe ANd VALue To The BusINessYou can define Change in several ways. The definition of Service Change is:

“The addition, modification, or removal of authorized, planned or supported Service or Service component and its associated documentation.”



Table of Contents


scopeThe Change Management process includes the addition, modification, or removal of supported Services or Service components across the entire Service Lifecycle. Organizations define the Changes that are within the scope of their Service Change process. Those outside the scope might include Changes such as departmental organization, policy, and business changes at an operational level, such as repair to printers or other routine Service components.


Table of Contents


Manage thebusiness

Manage thebusiness

processes

Service Operations

Service portfolio

Manage IT services

Manage thesuppliers' business

Manage

externalservices

External operations

SupplierService Provider

Business

Strategicchange

Tacticalchange

Operationalchange

servicechange

Manage

businessoperations

Adapted from scope of change and release managem

ent for services ©


GC


Table of Contents


Value to BusinessHere is how you can define the Change Management process to add value to your organization:

y Prioritize business and customer Change proposals. y Respond to business and customer Change proposals. y Implement Changes that meet Service requirements. y Optimize costs when implementing Changes. y Meet governance, legal, contractual, and regulatory

requirements. y Reduce the number of failed Changes and, consequently,

reduce instances of Service disruption, defects, and rework.

y Deliver Change promptly to meet business timelines. y Track Changes to learn from past errors/Incidents. y Contribute to better estimations of quality, time, and cost of

Change. y Assess the Risks associated with the transition of Services

(introduction or disposal). y Aid in the productivity of staff by minimizing disruptions

due to high levels of unplanned or emergency Change and, consequently, maximize Service availability.


Table of Contents


y Reduce the Mean Time to Restore Service (MTRS) via quicker and more successful implementations of corrective Changes.

y Liaise with the business Change process to identify opportunities for business improvement.

All organizations rely heavily on IT Services and IT infrastructure. An organization might need to spend a lot of time on assessing the Impact of an IT Change on the business, managing the Incidents caused by Changes, identifying recurring Problems, and so on. As a result, ensuring that Service disruptions and Incidents are minimal can result in considerable cost savings for an organization.

Changes TypesA predefined Change scope usually includes the following three types of Changes:

y strategic Changes: Cover the long-term planning and control over the quality, stability, and flexibility of the Service. The Service Strategy team usually brings in these Changes.

y Tactical Changes: Guarantees and maintains the quality, stability, and flexibility of Services. It manages Service levels, costs, availability, capacity, and contingency planning.


Table of Contents


y operational Changes: Achieves the quality, stability, and flexibility of Services. It helps manage Incidents, Problems, Changes, software Releases, and the configuration of the hardware and software elements of the infrastructure.

Each organization counts on having reliable IT Services to perform its day-to-day functions. In fact, reliability and business continuity are two cornerstones of the success and survival of any organization. Service and infrastructure Changes can have an adverse Impact on the business by causing Service disruption.

reliance on IT servicesThe reliance on IT Services is getting so complicated that you might have to spend a considerable amount of time on activities such as:

y “Assessing business change impact on IT y Analyzing the Service change impact on business y Notifying parties that get affected y Recording accurate change, configuration, release and

deployment records y Managing incidents caused by change and resolving

them”

(Source: Service Transition Book)


Table of Contents


Poor Change management IndicatorsThe top-five indicators of poor Change Management are:

y “Unauthorized Changes (above Zero is unacceptable) y Unplanned outages y A low change success rate y A high number of emergency changes y Delayed project implementations”


mean Time To repair (mTTr) and mean Time to restore service (mTrs)All high-performing IT organizations have the lowest MTTR. They view Change Management as a safety net, preventing them from being low performers. Achieving a success rate of over 70 percent is possible only when you implement preventive and detective controls.

MTRS is a measure of how quickly and effectively you restore a Service, component, or CI to normal working after a failure.

mTrs formulaYou can calculate MTRS by using this formula:

MTRS (hours) = Total downtime (hours)/Number of Service breaks


Table of Contents


Most organizations now prefer MTRS to MTTR because MTRS is less ambiguous.


definition of PolicyWe can define a policy as a written statement of a plan of action adopted by an organization to guide its decision-making processes. With respect to Change Management, we can define a policy as a plan to identify all possible Changes in an organization and their probable consequences.

examples of Policies that support Change management

y Inculcate a culture of Change Management across the organization to have zero tolerance for unauthorized Change.

y Ensure that the Service Change Management process aligns with business, project, and stakeholder Change Management processes.

y Prioritize Changes, for example, innovation versus preventive versus detective versus corrective Change.


Table of Contents


examples of Policies that support Change management

y Establish accountability and responsibilities for Changes through the Service Lifecycle.

y Segregate duty controls. y Establish a single focal point for Changes to minimize

the probability of conflicting Changes and potential disruption to the production environment.

y Prevent unauthorized users from having access to the production environment.

y Integrate the Change Management process with other Service Management processes to establish traceability of Change, detect unauthorized Change, and identify Change-related Incidents.

y Define enforcement and authorization for exceptions to Change windows.

y Define performance criteria and evaluate the Risks of all Changes that Impact Service capability.

y Define performance measures, such as efficiency and effectiveness, for the process.


Table of Contents


Principles of Change management ProcessesKey Design and Planning Considerations

You must take into account the following key design and planning considerations for Change Management processes:

y Define the requirements, for example, compliance with relevant legislation, industry codes of practice, standards, and organizational practices.

y Implement an approach to eliminate unauthorized Change.

y Identify and classify: o Change document identifiers. o Change document types, templates, and expected

content. o Change Impact, Urgency, and priorities.

y Define organizational roles and responsibilities, such as: o Taking care of stakeholder accountabilities and

responsibilities. o Having an approach for conducting independent

testing and evaluation of Change. o Defining the Change authorization details, such as

the levels of authorization and rules that govern decision-making and actions.

o Defining the structure of advisory boards, for example, the Change Advisory Board (CAB) and the Emergency CAB (ECAB).


Table of Contents


y Communicate with stakeholders: o Schedule Changes and Releases to enable

stakeholders to plan their activities. o Inform all stakeholders of Changes, Change

schedules, and Release plans. y Group and relate Changes into one build, Release, or

baseline Release by linking several child RFCs to a master RFC.

y Follow procedures to: o Define Change authorization policies, rules, and

procedures. o Define procedures to raise an RFC, including the

preparation and submission of a Change proposal. o Define the process to track and manage Change

Requests. o Define the process to ensure Change Requests are

promptly Impact assessed and evaluated. o Define the process to detect dependencies and

incompatibilities between Changes. o Define the process to verify the implementation of a

Change. o Define the process to oversee and evaluate

deliverables from Change and Release implementations.

o Define the process to review Changes regularly to identify trends and improvements.


Table of Contents


y Interface with other Service Management processes, such as Service Level Management (SLM) and Capacity Management, for Impact assessment and review.

y Define the approach to interface Change, Release, and Configuration Management with the Problem and Incident Management processes to measure and reduce Change-related Incidents.

y Identify appropriate Configuration Management interfaces to:

o Provide quality information for Impact assessment and reporting.

o Identify high-Risk, high-Impact CIs. o Capture CIs, Configuration Baselines, and Releases. o Capture related deliverables.

Change requestA Change Request is any type of formal communication that seeks to alter one or more CIs. This request comes to you in several forms, such as an RFC document, a Service Desk call, or a project initiation document.

In addition, different Changes might require different types of Change Requests. You need to ensure that appropriate procedures and forms are available to cover the anticipated requests. At each stage in the Change Management process, try to delegate authorization. This will ensure the effective implementation of Change Management.


Table of Contents


Implementing the Change management ProcessThe basic procedures to implement the Change Management process in an organization are:

y Change process model: Includes defined workflows, a chronological sequence of steps, roles and responsibilities, timelines, and escalation procedures.

y standard Change procedure: Includes defined triggers and tested and documented tasks, Risk evaluation data, set processes and workflows, approved budget, and authorization.

y remediation plan: Includes back-out plans for reversible Changes or remediation approaches for irreversible Changes.

standard ChangeA Standard Change is a Change to a Service or infrastructure that you do on a regular basis. A set and approved Change Management procedure authorizes the steps for these Changes.


Table of Contents


examples of standard Changes y Upgrading a PC to use standard or budgeted

software y Provisioning IT equipment for new employees within

an organization y Desktop move for a single user y Low-impact, routine application Changes to handle

seasonal variation

A delegated authority will grant approval for each Standard Change.

elements of a standard ChangeThe crucial elements of a Standard Change are:

y There is a defined trigger to initiate the RFC. y The tasks are well known, documented, and proven. y Authority is effectively given in advance. y Budgetary approval will typically be preordained or within

the control of the Change requester. y The Risk is usually low and always well understood.


Table of Contents


After you have decided on the approach to manage all Standard Changes, you must develop the following and communicate them to all concerned personnel, to ensure smooth and consistent process Change:

y Standard Change processes y Associated Change workflows

Another helpful task is to identify all Standard Changes early on, when building the Change Management process. This promotes efficiency and avoids high levels of supervision and resistance to the Change Management process.

Finally, all Changes, including Standard Changes, must have details of the Change recorded.


Table of Contents


“example of types of requests by service lifecycle stage

Type

of

Cha

nge

with

Ex

ampl

es

Doc

umen

ted

Wor

k Pr

oced

ures

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sitio

n

Serv

ice

Ope

ratio

n

Con

tinua

l Se

rvic

e Im

prov

emen

t

Request for Change to Service Portfolios

New portfolio line item

To predicted scope,

Business Case, baseline

Service Pipeline

Service Change

Management _


Table of Contents


Type

of

Cha

nge

with

Ex

ampl

es

Doc

umen

ted

Wor

k Pr

oced

ures

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sitio

n

Serv

ice

Ope

ratio

n

Con

tinua

l Se

rvic

e Im

prov

emen

t

Request for Change to Service or Service Definition

To existing or planned service attributes

Project change that impacts Service Design, for example, forecasted warranties

Service improvement

Service Change

Management_


Table of Contents


Type

of

Cha

nge

with

Ex

ampl

es

Doc

umen

ted

Wor

k Pr

oced

ures

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sitio

n

Serv

ice

Ope

ratio

n

Con

tinua

l Se

rvic

e Im

prov

emen

t

Project Change Proposal

Business Change

No Impact on service

or design baseline

Project Change Management procedure

User access Request

User access procedure


Table of Contents


Type

of

Cha

nge

with

Ex

ampl

es

Doc

umen

ted

Wor

k Pr

oced

ures

Serv

ice

Stra

tegy

Serv

ice

Des

ign

Serv

ice

Tran

sitio

n

Serv

ice

Ope

ratio

n

Con

tinua

l Se

rvic

e Im

prov

emen

t

Operational Activity

Tuning (within specification/constraints)

Re-boot hardware on failure if no impact on other services Planned maintenance”

Local procedure (often pre-authorized



Table of Contents


3.3.4 ProCess ACTIVITIes, meThods, ANd TeChNIQues

A C T I V I T y T I m e


Table of Contents


Adapted from example process flow

for a normal change


OG

C

Create

RFC

Change proposal

(optional)

ReviewR

FC

Assess and evaluate change

AuthorizeC

hange ready for decision

ready for evaluation

requested

authorized

scheduled

implem

ented

closed

Plan updates

Co-ordinate changeim

plementation*

Review

and closechange record

Initiator

Changem

anagement

ChangeAuthority

Changem

anagement

Evaluation report

AuthorizeC

hange proposal

Work orders

Work orders

Changem

anagement

Record theR

FC

*Includes build and test the change


Table of Contents


Assess and

evaluate RF

C

Authorize

and Schedule

Change

Co-ordinate

changeim

plementation*

Review


Create and

review R

FC

standard

deploym

ent request

(where the deploym

entprocess is tried and tested)

role

Initiator

Change

managem

ent

Change

Authority

Change

managem

ent

Work orders

Deploym

ent change proposal(from

a template)

closed*Includes build and test the change

requested

ready for decision

scheduled

implem

ented

Adapted from exam

ple process flow for standard deploym

ent request ©


GC


Table of Contents


Adapted from example process flow

for standard operational change request ©


GC

Review


Assign for W

ork

Create R

FC

role

Initiator

Change

managem

ent

requested

implem

ented

closed


Table of Contents


subactivities of the Normal Change request ProcessThe process to execute a normal Change Request includes the following subactivities:

y Reviewing the RFC and Change proposal, which includes: o Filter Changes such as incomplete or wrongly routed

Changes. y Assessing and evaluating the Change, which includes:

o Establish the appropriate level of Change authority. o Establish relevant areas of interest, that is, who

should be involved in the CAB. o Assess and evaluate the business justification,

Impact, costs, benefits, and Risks of the Change. o Request an independent evaluation of the Change.

y Authorizing the Change, which includes: o Communicate the decision to all stakeholders,

particularly the initiator of the RFC. y After planning updates and coordinating the Change

implementation, the Change is reviewed and closed, which includes:

o Collate the Change documentation, for example, baselines and evaluation reports.


Table of Contents


o Review the Change and Change documentation. o Close the Change document.

y When performing all these activities, be sure to gather, record, and report all the information in the CMS.

Change request InitiatorAn individual or organizational group can raise Change Requests. Regardless of the initiator, you need to log, review, and assess all Change Requests as part of Change Management.

Change ProposalTo do so, you will need a Change form or Change proposal with a full description of and the reason for the Change. In the Change form or proposal, you need to record all information related to the RFC, such as its priority.

Assessing and evaluating the ChangeAs the process progresses, you will add information including the authorities involved in authorizing, assessing, and evaluating the Change. You may also add work orders to implement the Change. You should also maintain and update all information related to RFCs in the CMS.

Now, we will discuss the various procedures you follow to log and review RFCs.


Table of Contents


Log a Change requestLet us first discuss how to log a Change Request because this is the first activity you perform after receiving a Change Request.

Different organizations follow different procedures to log Change Requests. You can submit a Change Request in a document or through e-mail or any Web-based application. You should log RFCs and allocate a unique identification number to each RFC to ensure RFC tracking. Ideally, you should use an integrated Service Management tool to log the RFCs. This type of tool also helps store the complete data as well as the relationships between all assets and CIs, enabling you to assess the Impact on other Services easily.

review Change requestsAfter logging the Change Request, you must review and filter out any unwanted requests that are not feasible for implementation, are incomplete, or have been accepted or rejected earlier..

You must return the rejected requests to the initiator along with reasons for the rejection. The initiator can request the Change again through the correct management channels.

Assess Change requestsYou need to assess Change Requests to identify their Impact on other Services, CIs, business operations, current Change schedules, resource requirements, continuity plans, security plans, and Service Operation practices.


Table of Contents


You should assess and categorize the associated Risks to prevent disruptions to the business or to the delivery of Services.

evaluate Change requestsAfter assessing the Risks and Impacts of the Change, the assessors also evaluate whether or not to approve the Change based on its Impact, Urgency, Risks, benefits, and costs.

Prioritize ChangeBased on the assessment results and the Urgency and Impact of the Change, you need to prioritize the Change. The Change initiator will suggest the initial Impact and Urgency, but they may change in the Change authorization process.

remediation ApproachesRemediation approaches, including back-out plans for reversible Changes and alternative remediation approaches for irreversible Changes, are an essential element of a Change. It is important for you to document these remediation approaches in the RFC.

seven rs of Change management methodsThe “seven Rs” of the Change Management process help you assess and evaluate the Impact of a Change on Services. The answers to the seven questions constituting the seven Rs help you understand the Risks and benefits of the Change to the live Service. This also helps deliver the Change, as expected.


Table of Contents


The seven Rs of the Change Management process are: y “Who RAISED the Change? y What is the REASON for the Change? y What is the RETURN required from the Change? y What are the RISKS involved in the Change? y What RESOURCES are required to deliver the Change? y Who is RESPONSIBLE for the build, test, and

implementation of the Change? y What is the RELATIONSHIP between this Change and

other Changes?”


After assessing the Change, you should prioritize it before implementing it.


Table of Contents


example of Change Priorities for Changes That you Need to fix or Improve services

Priority Corrective Change enhancement Change

Immediate

Changes that involve high Risk, disrupt Service Delivery, lead to revenue losses, or require immediate action

NA

HighChanges that have a severe Impact on prime users or an Impact on a large number of users simultaneously

Changes that meet legislative requirements, satisfy short-term market opportunities or public requirements, or support initiatives for business growth

Medium

Changes that do not have a severe effect but need correction before the next scheduled Release

Changes required for planned business initiatives and maintaining business viability


Table of Contents


Priority Corrective Change enhancement Change

Low

Changes that are necessary but can wait for the next scheduled Release

Changes that enhance the usability of an existing Service or lead to the addition of new capability to a Service

Authorize ChangesAfter logging and reviewing Changes, you need to authorize them.

You must obtain authorization from the defined authorities in your organization before implementing a Change. The organization should define the Change authorization hierarchy to authorize Changes.

In addition, each authorization level may include delegated authority based on some predefined parameters of assessment, such as the type, size, or Risk of the Change.

The authorizing hierarchy also includes the Change Advisory Board (CAB) and can include the Board of Directors. This is to help assess the Impact of the Change in terms of cost, benefits, and associated Risks and authorize it, if appropriate.

Let us look at an example of a Change authorization hierarchy.


Table of Contents


Adapted from exam

ple of a change authorization model

© C

rown C


OG

C

Com

munications,

decisions and actions

Com

munications,

escalation for R

FCs,

risks, issues

Change authority

Exam

ples of configuration level im

pacted

Business

executive board

ITm

anagement board

CA

B or

emergency C

AB

Local authorization

High cost/risk

change – requiresdecision from

executives

Change im

pacts multiple

services or organizational divisions

Change w

hich impacts

only local or service group

Standard change

Level 1

Level 2

Level 3

Level 4


Table of Contents


Coordinate Change ImplementationAfter Change authorization, you need to coordinate the Change implementation.

Coordinating Change Requests includes tracking and coordinating them. Change Management coordinates the Change implementation while technical specialists implement the Change.

Remedial procedures must be prepared and documented in advance. If any error occurs, you can activate these procedures with minimal Impact to the Service. It is mandatory that you test the Change before implementing it. You do further testing after the implementation to test for usual or future situations.

It is a good idea to use formal methods, such as work orders, to pass authorized Changes to the relevant technical groups for implementation.

review and Close ChangeAfter you coordinate a Change, you need to review and close it. To do so, you need to:

y Collate the Change documentation, for example, baselines and evaluation reports.

y Review the Change(s) and Change documentation. y Close the Change document.


Table of Contents


record ChangeAfter implementing the Change, you must record all the relevant information and send the report to the management team for review and evaluation. When reviewing the Change, you must also look at any Incidents that might arise because of the Change.

Post-Implementation reviewDuring the review process, that is, the post-implementation review (PIR), you must:

y Confirm that the Change has met its objectives. y Ensure that the stakeholders and initiator are satisfied with

the Change. y Ensure that there have been no unexpected side effects.

In a small organization, you need not conduct large-scale PIRs and can, instead, implement a spot review to verify Changes. In a big organization, spot reviews are also helpful to monitor many small Changes.

Change Advisory Board CAB members usually review new or changed Services after a predefined period. Their main aim is to ensure that the Change has met its objectives and has not affected or disrupted other Services. If the Change has not met its objectives, the CAB members raise a Request that you may need to request a revised RFC to initiate another Change. However, if the Change is successful, you close the RFC in the logging system.


Table of Contents


After implementing a Change or Service, you conduct a PIR only after a predefined period to analyze whether or not the Change has met its proposed objectives. Because the organization conducts the PIR on a large scale, it involves the CAB members.

A normal review takes place after implementing a Change. You usually conduct this review on a smaller scale than the PIR.

PIr findingsA PIR establishes that:

y The Change has met its objectives. y Users and customers are happy with the Change. y The Change does not have an unexpected or undesirable

affect on other Services. y Resource utilization was per the estimated resource

requirement. y Release and Deployment of the Change was as

scheduled. y The implementation of the Change was per schedule. y The remediation plan was functioning correctly, when

needed.


Table of Contents


emergency ChangesAt times, your organization might require emergency Changes. Before implementing these Changes, you should design and test them to avoid Impacts that are greater than that of the original Incident. You must also document the details of the emergency Changes for future analysis.

Aspects of emergency ChangesNot all RFCs raised in an organization are of the same Priority. An emergency Change is the highest-priority Change in an organization. For any emergency Change, you need to evaluate, assess, reject, or approve it within a short period. You need to consider the following aspects of implementing emergency Changes:

y Conditions for implementing emergency Changes: It is important to construct and design emergency Changes cautiously, and you may document details retrospectively if it is not possible to document them at the time. You consider a Change an emergency only if it is essential for the organization, such as the repair of an error, and only if the error is negatively affecting the business to a high degree. Emergency Changes are usually disruptive and are less likely to be successful. As a result, you need to minimize the number of emergency Changes.


Table of Contents


y Authorization of emergency Changes: You must follow the correct authorization channels for an emergency Change. In an emergency, CAB members might not be able to hold a meeting. In this situation, the ECAB members authorize the Change. However, you might not need their approval in all situations, such as an operational repair (for example, mainframe and large servers).

y Implementation of emergency Changes: After authorization from the ECAB members, you need to send the Change Request to the relevant technical team to build the Change. You must also test the Change, if possible, before implementing it. It is important to compare the cost to test the emergency Change against the cost of the failure of the emergency Change. You might need to have iterative attempts to come up with an effective fix if the first or subsequent attempts fail. After testing and implementation, you need to document all the relevant details for future reference.

y Guidelines for implementing emergency Changes: You need to follow the normal Change procedure to implement emergency Changes as well. The only exceptions are that instead of CAB members, ECAB members authorize the Change. You can then reduce or bypass testing and defer the documentation phase.


Table of Contents


failure to resolve a reported errorYou may also come across situations where the implemented Change fails to resolve the reported error. In these situations, you may have to attempt to fix the Change multiple times. The Change Management team must also ensure that the attempts do not disrupt business Services. The team follows the correct procedures to fix the Change.

However, if the Change Management team is unable to rectify the error after multiple attempts, you should analyze the situation by answering questions such as:

y Did you identify, analyze, and diagnose the error correctly? y Did you test the proposed resolution adequately? y Did you implement the solution correctly?

Testing and Implementing ChangeTo test and implement the Change correctly, you can stop the Service partially, withdraw access for some users, or suspend the Service for a specific duration.

You must also document and update all actions for future reference. However, sometimes, you might not be able to do so because of the Urgency. In this case, record the essential updates and then complete the documentation after you implement the Change successfully.


Table of Contents


3.3.5 TrIggers, INPuTs, ouTPuTs, ANd INTer-ProCess INTerfACes


TriggersSome examples of Changes that can trigger the Change Management process are:

y Strategic Changes: These Changes aim to achieve specific objectives with respect to predefined parameters, such as organization Change, sourcing model Change, and legal or regulatory Change.

y Change to Multiple Services: These Changes to planned Services or Services in the Service Catalogue trigger the Change Management process. Examples are Changes to the Service Catalogue, Service Package, and Service definitions and characteristics.

y Operational Change: These Changes aim to affect operations. Examples are access requests or requests to move an IT asset across locations.

y Continual Improvement Changes: These Changes aim to deliver continual improvement, for example, Changes to processes.


Table of Contents


InputsLet us now move on to inputs. The primary input for the Change Management process is an RFC. Other inputs include:

y “Policy and strategies for change and release y Request for Change y Change proposal y Plans – change, transition, release, deployment, test,

evaluation and remediation y Current change schedule and PSO y Current assets or configuration items, e.g. baseline,

service package, release package y As – planned configuration baseline y Test results, test report and evaluation report.”



Table of Contents


outputsThe key outputs of the process are:

y Rejected RFCs y Approved RFCs y Changes in Services and configurations y Change schedule y Revised Projected Service Outage (PSO) y Authorized Change plans y Change decisions and actions y Change documents and records y Change Management reports


Table of Contents


Change M

anagement

Raise & record

change request

Configuration

Managem

ent

Assess change

Configuration M

anagement System

Approve/reject change

Coordinate change

implem

entation*

Review

changeC

lose change

Release and deploynew

/changed CIs

Reports & audits

Identifyaffected

items

Update records

Capture

release andenvironm

entbaselines

Audit items

Check

records updated

* Includes build and test where applicable

Adopted from request for Change w

orkflow and key interfaces to Configuration m

anagement


OG

C


Table of Contents


Interface with other ProcessesTo conclude, you should implement the Change Management process in synchronization with various other interfaces within an organization because of the Impact of the proposed Change. Some of these interfaces are:

y Business Change processes y Program and project management y Internal and external sourcing and partnering entities

service management ProcessesIn addition to these interfaces, various Service Management processes might require Change Management from time to time and may be exposed to the Impacts of various Changes. Some of these processes are:

y Asset and Configuration Management y Problem Management y IT Service Continuity Management y Security Management y Capacity and Demand Management


Table of Contents


examples of strategic Change y “Change after analyzing business, customer, and user

activity patterns y Addition of new Services to the market space y Updates to the Service Portfolio, customer portfolio,

or contract portfolio y Change in the sourcing model y Technology innovation”


examples of Changes to multiple services y “Release Package y Capacity and resource requirements y Service level requirements y Warranties y Utilities y Cost of utilization y Service Assets y Acceptance criteria y Predicted quality of Service y Predicted performance


Table of Contents


examples of Changes to multiple services y Predicted value y Organizational design y Stakeholder and communications plans y Physical Change in the environment, for example,

buildings y Measurement system y Plans, such as capacity, IT Service Continuity

Management (ITSCM), Change, transition, test, Release, and deployment plans

y Decommissioned/retired Services y Procedures, manuals, and Service Desk scripts”


Interface of the service Change ProcessYou might also come across situations where the proposed Change will affect the other parts of the organization on a wider scale. To avoid this, the Service Change process must interface with the other processes involved.

Program and project management must work together to align all the processes and people involved in Service Change initiatives. The Change effort also improves based on how closely you align the processes. The Change Management team might attend project-related meetings.


Table of Contents


The partnership agreement between the entities involved in the Change process should clearly define the roles and responsibilities of each entity and how much influence each of them can have on the Change process. You must also check how well you align the Change processes and the tools in the organization. If the supplier is responsible for the operational Service, conflicts might arise.

Change Process entitiesThe different entities involved in the Change process might include internal or external vendors and suppliers that provide new or changed Services. To manage the Change process efficiently, you must ensure that:

y You maintain a good relationship between the entities. y You assess how well the partners manage the Change

process. y Service Providers follow the same Change Management

process as the organization they work with. Some organizations also refer the RFCs to Service Providers for estimates prior to approval.

Interfaces with other service management ProcessesNow, let us see how the Change Management process interfaces with other Service Management processes.


Table of Contents


Change management and Asset and Configuration managementThe CMS provides accurate information about CIs and assets, helping stakeholders and staff evaluate and assess the Impact of the proposed Change. The CMS also lists the assets and CIs that the Change will affect.

Change Management and Problem Management

Problem Management interfaces with Change Management by raising RFCs to implement Workarounds and to fix Known Errors. Many RFCs originate from Problem Management. They play an important role in CAB meetings.

Change Management and ITSCM

You can update many procedures and plans in IT Service Continuity Management (ITSCM) through Change Management. This is necessary to ensure accuracy and to inform stakeholders of all Changes.

Change Management and Security Management

RFCs also originate from Security Management. You need to follow the Change Management process to implement these Changes. Security is also a key contributor to the CAB (to discuss security issues).


Table of Contents


Change Management and Capacity and Demand Management

Sometimes, poorly managed demand increases costs and Risks for Service Providers. Capacity Management assesses the proposed Changes against Service capacity. Capacity Management also submits RFCs that you process through Change Management.

3.3.6 KPIs ANd meTrICsKPIs and metricsKPIs are measurable metrics used to help an organization define and measure progress toward organizational goals. All Change Management KPIs must have a specific meaning. This is because, while you can easily count the number of Incidents that generate Changes, it is more valuable to be able to identify trends and measure their Impact by looking at their underlying cause. Over time, you will also be able to measure the speed and effectiveness of your response to business needs for Changes.

In the Change Management process, KPIs help analyze patterns and reasons for requested Changes. When implemented correctly, KPIs and metrics help you measure the Impact of Changes on the organization.


Change management Process KPIsLet us now understand how the KPIs implemented in your organization help you analyze Change Requests to spot trends.


Table of Contents


The KPIs applicable to the Change Management process are: y Number of implemented Changes to Services that meet

customer requirements y Benefits of Change comparing favorably to the costs of

Change y Fewer disruptions to Services, defects, and less rework y Fewer unauthorized Changes y Smaller backlog of Change Requests y Fewer unplanned Changes and emergency fixes y Improved Change success rate y Fewer Changes where remediation is invoked y Fewer failed Changes y Less time to implement each Change per Urgency/Priority/

Change type y Percentage accuracy in Change estimate y Fewer Incidents related to Changes

Each organization has its own set of measures for Change.


Table of Contents


examples of Types of measures in organizations y Output measures:

o Number of disruptions, Incidents, Problems, and errors caused by failed Changes

o Number of incorrect Change specifications o Deficient Impact assessment o Number of unauthorized business/customer

Changes by business/IT/customer/user asset/CI type

o Reduced time, effort, and cost to make Changes and release them

o Amount of Service or application rework caused by inadequate Change specification

o Improved predictions of time, quality, cost, Risk, resource, and commercial Impact

o Improved Impact analysis and Change scheduling

o Fewer unauthorized Changes y Workloads

o Frequency of Change o Volume of Change


Table of Contents


examples of Types of measures in organizations y Process measures

o Satisfaction with the speed, clarity, and ease of use

o Number and percentage of Changes that follow formal Change Management procedures

o Ratio of planned to unplanned Changes o Ratio of accepted to rejected Change Requests o Number of Changes recorded and tracked using

automated tools o Reduced time to execute a Change o Employee utilization o Cost against budget

Remember that all measures vary between organizations and over time, as the Change process matures.


Table of Contents


3.4 serVICe AsseT ANd CoNfIgurATIoN mANAgemeNToverviewThe SACM process helps maintain information about the CIs required to deliver an IT Service. No organization can be totally efficient or effective unless it manages its assets well. This is particularly true for assets that are vital for business operations.

This process supports the business by providing accurate information and control across all assets and relationships that make up an organization’s infrastructure.

The SACM process is responsible for both the Configuration Management and the Asset Management process.

3.4.1 PurPose, goALs, ANd oBjeCTIVesUnless you know what IT assets you have and the current state they are in, any IT governance you claim is built on sand. With good Asset and Configuration Management, you can take business Risks and use your resources more effectively.

Purpose: y Identify, control, and account for Service Assets and CIs,

protecting and ensuring their integrity across the Service Lifecycle.

y Identify, control, record, report, audit, and verify Service Assets and CIs, including versions, baselines, components, their attributes, and their relationships.


Table of Contents


y Account for, manage, and protect the integrity of Service Assets and CIs throughout the Service Lifecycle by ensuring the use of authorized components and by making authorized Changes.

y Protect the integrity of Service Assets and CIs throughout the Service Lifecycle.

y Ensure the integrity of the assets and configurations required to control Services and IT infrastructure by establishing and maintaining an accurate and complete CMS.

y Use the CMS to manage large and complex IT Services and infrastructures.

goals: y Support the control objectives and requirements of the

business and the customer. y Support efficient and effective Service Management

processes by providing accurate configuration information, enabling people to make the right decision at the right time, for example, to authorize Changes and Releases and resolve Incidents and Problems faster.

y Minimize the number of quality and compliance issues caused by the improper configuration of Services and assets.

y Optimize Service Assets, IT configurations, capabilities, and resources.


Table of Contents


objectives: y Define and control the components of Services and

infrastructure. y Maintain accurate configuration information on the

historical, planned, and current states of Services and infrastructure.

3.4.2 sCoPe ANd VALue To The BusINessscope of the Asset management ProcessThe scope of the Asset Management process includes:

y Covering Service Assets across the entire Service Lifecycle.

y Providing a complete inventory of assets, listing the personnel responsible for their control, and including asset inventory maintenance.

y Being responsible for the entire Lifecycle management of IT and Service Assets, from acquisition through to disposal.

scope of Configuration managementThe scope of Configuration Management includes:

y Ensuring that the components, including a complete Service, system, or product, are identified, baselined, and maintained and that configuration Changes are controlled.


Table of Contents


y Ensuring that Releases into controlled environments and their operational use occur only after receiving formal approval.

y Providing a Configuration Model of Services Assets and infrastructure by recording the relationships between them.

scope of sACmThe scope of SACM includes:

y Covering non-IT assets, the work products used to develop Services, and the CIs required to support Services not formally classified as assets.

y The connects it shares with internal and external Service Providers with regard to assets such as shared assets and CIs that need to be controlled.

Value to BusinessMaking optimal use of SACM improves the overall Service performance of an organization. This also optimizes the costs and Risks that poorly managed assets, such as Service outages, fines, incorrect license fees, and failed audits, cause.

The value and benefits of a Configuration Management Database (CMDB) are immense. You can only achieve the accuracy and strength of the CMDB through effective Change Management to which the entire organization adheres.


Table of Contents


The SACM process adds value by accurately representing a Service, Release, or environment that enables you to:

y Effectively forecast and plan Changes. y Assess, plan, and deliver Changes and Releases. y Resolve Incidents and Problems within Service level

targets. y Deliver Service levels and Warranties. y Adhere to standards and legal and regulatory obligations,

resulting in fewer instances of nonconformance. y Explore better business opportunities that help

demonstrate control over assets and Services. y Trace Changes from requirements. y Identify the cost of a Service.


Basis of an sACm Policy An SACM policy finds its basis in the organization’s business drivers, contractual and Service Management requirements, and compliance with applicable laws and regulations such as Sarbanes-Oxley and related standards. The SACM policy is closely associated with Change and Release and Deployment Management policies.


Table of Contents


example of the Basis of an sACm PolicyAn organization’s asset policy might be applicable to specific asset types or Services such as desktops.

Laying out a strong SACM policy is easier said than done because it involves detailed consideration of the significant costs and resource implications of implementing SACM. It means that the organization needs to make some strategic decisions and lay out priorities.

Any office has a host of distributed environments, shared Services, and individual Service components that exist within various Services and configuration structures. A Change to the network might affect one person’s work and business process.


Table of Contents


Customer

Banking core service

Service level

package

Contract

Service portfolio

Serviced by

E-banking support service

ApplicationApplication

hosting service

Technical infrastructure

service

AvailabilityUser

experienceBusiness

logicM

essagingData

servicesW

eb services

Network topology

AuthenticationNetwork service

Supported byHosted

Uses

Adapted from exam

ple of a logical configuration model


OG

C


Table of Contents



Need for a Configuration modelAny IT Service Desk is responsible for managing a range of assets and CIs. A model provides an easy-to-use method to record the relationships among all Services, assets, and infrastructures in a single, common representation.

The IT Service Management team and others such as the Human Resources team, the Finance department, suppliers, and customers also use this single representation.

There are always numerous ways and software products to catalog all the computers, software, and ways to use the computers and Services. However, instead of using four or five different products to manage your IT, each with its modeling or cataloging structure, why not just have one “model” that all the concerned departments can use? This is exactly what the Configuration Model does.

The CIs and related configuration information can be at varying levels of detail within the Configuration Model.


Table of Contents


example of Varying Levels of CIs and Configuration InformationThe Configuration Model can give an overview of all the Services or provide a detailed picture of all Service component specifications. The specifics of which elements go into the Configuration Model depend on organizational need. However, all organizations have a constant need to balance the level of detail and maintainability costs with organizational and business value when deciding the final levels of CIs to record and maintain.

Application of Configuration managementYou should apply Configuration Management at a more detailed level, where the Service Provider requires tight control, traceability, and coupling of CIs throughout the Service Lifecycle.

Most organizations puzzle over a couple of questions when talking about SACM:

y How to actually implement SACM? y Where to begin implementing SACM?

A good place to start is by laying down a strong SACM policy with clear objectives, scope, Critical Success Factors (CSFs), and principles.



Table of Contents


Configuration ItemsCIs are assets, Service components, or any other item that the Configuration Management process controls. The CIs may vary widely in complexity, size, and type. They could range from an entire Service or system, including all hardware, software, documentation, and support staff, to a single software module or minor hardware component. You can group them or manage them together. It is important to follow established selection criteria to select CIs.

example of grouped CIsGrouping a set of components into a Release

sACm policies: y Ensure that the Asset and Configuration Management

operational costs and resources are commensurate with potential Risks to Services.

y Fulfill the need to deliver corporate governance requirements, for example, software asset management and Sarbanes-Oxley.

y Fulfill the need to deliver the capability, resources, and Service Warranties, as defined by SLAs and contracts.

y Fulfill the requirement for available, reliable, and cost-effective Services.


Table of Contents


y Fulfill the requirement for clear economic and performance criteria for interventions that reduce costs or optimize Service Delivery, for example, lower maintenance costs.

y Apply whole-life cost appraisal methods. y Transform from “find-and-fix” reactive maintenance to

“predict-and-prevent” proactive management. y Fulfill the requirement to maintain adequate asset

and configuration information for internal and external stakeholders.

y Define the level of control and requirements for traceability and auditability.

y Implement the application of continual improvement methods to optimize Service levels, assets, and configurations.

y Provide accurate asset and configuration information for other business and Service Management processes.

y Provide the integration of Asset and Configuration Management with other processes.

y Provide migration to a common Asset and Configuration Management system architecture.

y Define the level of automation required to reduce errors and costs.


Table of Contents


Principles of the sACm frameworkTo develop an effective SACM framework, it is important that you consider some key principles against which to develop and maintain assets. Some typical principles that you must follow are:

y Ensure that the operations, costs, and resources of Asset and Configuration Management are commensurate with potential Risks to Services.

y Fulfill all corporate governance requirements, such as Software Asset Management or Sarbanes-Oxley.

y Deliver capability, resources, and Service Warranties as defined by SLAs and contracts.

y Make Services available, reliable, and cost effective. y Lay out specific economic and performance criteria for

use in interventions that reduce costs or optimize Service Delivery.

y Apply whole-life cost appraisal methods. y Transform the Service Desk’s philosophy from find-and-

fix reactive maintenance to predict-and-prevent proactive management.

y Maintain adequate asset and configuration information for internal and external stakeholders.

y Ensure the levels of control and requirements to facilitate tracing and auditing.

y Apply continual improvement methods to optimize Service levels, assets, and configurations.


Table of Contents


y Provide accurate asset and configuration information to other business and Service Management processes.

Categories of CIsThe different categories of CIs are:

y service Lifecycle CIs: Provide a broad view of the Service Provider’s Services, how the Service Providers deliver the Services, the benefits and costs of the Services, and when they will be realized. Some common CI types are business cases, Service Management plans, Service Lifecycle plans, SDPs, Release and Change plans, and test plans.

y service CIs: Consist of: o Service Capability assets: Management, organization,

processes, knowledge, and people o Service Resource assets: Financial, capital, systems,

applications, information, data, infrastructure and facilities, and people

o Service Model o Service Package o Release Package o Service Acceptance Criteria


Table of Contents


y organization CIs: Consist of both the documentation required to define the characteristics of a CI and the other documentation — constituting CIs in their own right — that needs to be controlled. Some examples of organizational CIs are the organization’s business strategy or other policies internal to the organization but independent of the Service Provider, regulatory or statutory requirements, and products shared between multiple groups.

y Internal CIs: Consist of CIs delivered by individual projects, including tangible assets, such as data centers, and intangible assets, such as the software required to deliver and maintain the Service and infrastructure.

y external CIs: Include external customer requirements and agreements, Releases from suppliers or subcontractors, and external Services.

y Interface CIs: Deliver an end-to-end Service across a Service Provider Interface (SPI).

Configuration management systemA CMS is a set of tools and databases that you use to manage an IT Service Provider’s configuration data.

You need this set of tools and databases to manage large and complex IT Services and infrastructure, Service Assets, and Configuration Management items.


Table of Contents


The CMS provides reliable, quick, and easy access to accurate configuration information because it:

y Enables stakeholders and staff to assess the Impact of proposed Changes and track Changes in workflow.

y Ensures that you identify the correct asset and Service component versions for Release to the appropriate party or into the correct environment.

y Is updated during the Change cycle.

The CMS holds all CI-related information within the defined scope. It maintains relationships among all Service components and any related Incidents, Problems, Known Errors, and Change and Release documentation.


Table of Contents


Portal

Change and releaseView

Schedules/plansC

hange Request

Status Change

Advisory Boardagenda and m

inutes

Asset managem

entView

Financial Asset, AssetStatus R

eports, AssetStatem

ents and Bills,Licence M

anagement,

Asset performance

Configuration LifeCycle View

Project configurationsService Strategy,

Design, Transition,

Operations

configurationbaselines and changes

TechnicalConfiguration

View

Service ApplicationsApplication

Environment Test

Environment

Infrastructure

service desk ViewU

ser assetsU

ser configuration,C

hanges, Releases,

Asset and Configuration

item and related

incidents, problems,

workarounds, changes

Knowledge

Processing Layer

Information

Integration Layer

data and Inform

ation sources and

Tools

Query and

Analysisreporting

Performance m

anagement

Forecasting, Planning, Budgetingm

odelingm

onitoring Scorecards, D

ashboards Alerting

Business/Custom

er/Supplier/User – Service – Application – Infrastructure m

apping

Service PortfolioService Catalogue

Service Model

Integrated CmdB

Service ReleaseService Change

Com

mon Process, D

ata, and Inform

ation Model

Schema

Mapping

Meta Data

Managem

entD

atareconciliation

Data

synchronizationExtract, Transform

, Load

Mining

data IntegrationPlatform

Configuration Tools

E.g. Storage Database

Middlew

are Netw

orkM

ainframe

Distributed D

esktopM

obile

Software

Configuration

Managem

ent

Discovery,Asset

Managem

entand audit

tools

enterpriseApplications

Access Managem

entH

uman R

esourcesSupply C

hainM

anagement

Custom

er Relationship

Managem

ent

Project D

ocument

Filestore

Project Software

Definitive M

edia Library

Definitive D

ocument

Library

Definitive M

ultimedia

Library 1

Definitive M

ultimedia

Library 2

structured

Physical CM

DBs

CM

DB1

CM

DB2

CM

DB3

search, Browse, store, retrieve, update, Publish, subscribe, Collaborate

Quality

managem

ent ViewAsset and

Configuration

Managem

ent Policies, Processes,

Procedures, forms,

templates, checklists

Presentation Layer

Adapted from example of a Configuration m

anagement system

© C

rown Copyright 2007 R


GC


Table of Contents


Cms ContentsThe figure shows how the CMS covers data in various layers termed knowledge, information, presentation, and so on. This data might come from various CMDBs, which together form a consolidated or integrated CMDB.

Establishing an integrated CMDB is a key area and challenge for any organization.

Before we learn more about an integrated CMDB and multiple CMDBs, let us understand the difference between a CMDB and an Asset Management system. The key difference is that the CMDB contains the relationships between CIs, such as hardware and software, which are missing in an Asset Management system.

Establishing these relationships between components for an end-to-end business Service is the primary challenge that any organization implementing ITIL faces.

Typically, the CMS contains configuration data and information combined into an integrated set of views for different stakeholders throughout the Service Lifecycle. As a result, it is important that you base this data on appropriate Web, reporting, and database technologies, providing flexible and powerful visualization and mapping tools and interrogation and reporting facilities.

Organizations are probably already using some elements of SACM such as maintaining records in spreadsheets or local databases. Some of these elements may also be used in the overall CMS.


Table of Contents


A quick way to transfer this existing data into the CMS is using automated tools to input and update the CMDB. Tools such as discovery, inventory, and audit tools help populate the CMDB. Subsequently, these tools help you compare actual “live” configurations with past records in the CMDB.

CmdB elementsSome other elements that go into creating a CMDB are:

y secure Library: A collection of software, electronic, or document CIs with restricted access. This is often used to control and release components throughout the Service Lifecycle.

y secure store: A location within SACM that warehouses IT assets. This can play an important role in providing security and continuity to IT assets.

y definitive media Library (dmL): A secure library of all media CIs, which stores master copies of versions that already have quality assurance. It also contains master copies of all purchased (with license information) or developed software. Ideally, it must contain a physical store, such as a fireproof safe, to hold all master copies. A DML lays the foundation for the Release and Deployment Management process.

Next, let us understand how an integrated CMDB helps increase the efficiency of SACM.


Table of Contents


Integrated CmdBWhen a CMDB is used in support of ITIL best practices, it is the cornerstone of IT Service Support. It provides a centralized view of IT data that is essential to deliver consistent, reliable, effective, and efficient Services to customers.

It is a fact that when IT systems or applications fail, the business suffers. As a result, it is only natural that organizations are demanding better visibility into the Services that IT provides to the business.

A key element that offers this visibility is a dashboard. A CMDB dashboard provides a quick status report of the CMDB environment using graphs, charts, and tables that summarize information and track Changes in the application environment over time. Dashboards provide a real-time and historical window into critical business applications and Services. This information is useful to improve the performance of any Service Desk.

Another important element is the Asset Management system. Assets are most vulnerable during periods of Change. You may be planning a mass deployment of refreshed computers or images. Effective Asset Management enables lower support, software delivery, and backup costs. A critical part of any CMDB is the Asset Management view. This view, which is appropriate for managing assets, provides the Service Desk with information that might be confidential.


Table of Contents


Yet another important element is the Service Desk view. The Service Desk view of the CMDB provides information that is useful for the Service Desk to track Incidents, requests, and so on for analyzing, and improving performance.

dm

LP

hysical CIs

dm

L and Cm

dB

Electronic C

Is

Information about the C

Is

Build new

Release

Test new Release

Distribute new

Release to live locations

Implem

ent new R

elease

Release R

ecord

BD

MC

Adapted from The relationship betw

een the definitive m

edia Library and the Configuration m

anagement d

atabase ©

Crow

n Copyright 2007 R


GC


Table of Contents


relationship Between dmL and CmdBNow that you know what a DML is, let us look at the relationship between the DML and the CMDB in SACM. You define the exact configuration of the DML during the planning activities of the SACM process. This includes:

y The medium, physical location, hardware, and software to be used. If kept online, some Configuration Management support tools incorporate document or software libraries that can be regarded as a logical part of a DML.

y Naming conventions for file-storage areas and physical media.

y Environments supported, for example, the test and live environments.

y Security arrangements to submit Changes, issue documentation and software, and implement backup and recovery procedures.

y The scope of the DML, for example, source code, object code from controlled builds, and associated documentation.

y Archive and retention periods.


Table of Contents


The definition also includes capacity plans for the DML and procedures to:

y Monitor growth in size. y Conduct an audit. y Ensure protection for the DML from erroneous or

unauthorized Change, for example, entry and exit criteria for items.

Additional Tools to Create CmdBSome additional tools used to create a CMDB are:

y definitive spares: An area set aside for the secure storage of definitive hardware spares. It is important to maintain these spare components and assemblies at the same level as comparative systems within the controlled test or live environment.

y Configuration Baseline: A configuration of a Service, product, or infrastructure that has been formally reviewed and agreed to. This serves as the basis for future activities and you can change this only through formal Change procedures. It captures the structure, content, and details of a configuration and represents a set of related CIs. Establishing a baseline helps:

o Mark a milestone in the development of a Service, for example, a Service Design baseline.


Table of Contents


o Build a Service component from a defined set of inputs.

o Change or rebuild a specific version at a later date. o Assemble all relevant components in readiness for a

Change or Release. o Provide the basis for a configuration audit and back

out, for example, after a Change. y snapshot: The image of the current state of a CI

or environment, recorded in the CMS. You may not necessarily review and agree upon a snapshot formally. It is just a documentation of a state that might contain faults and unauthorized CIs. For example, when you establish a snapshot after an installation by using a discovery tool and later compare it to the original Configuration Baseline, the snapshot:

o Enables Problem Management to analyze evidence about a situation related to the time when Incidents actually occurred.

o Facilitates system restore to support security-scanning software.



Table of Contents


Adapted from Typical Configuration managem

ent activity model


OG

C

feedback

Requirements

Design,M

aintenance,Release,Deploym

ent,O

perations plans

Physical CIs,Test resultsAudit/discoverytools

Change andConfigurationRecords andDocum

entation

RFC/change to CI

Configuration

Managem

ent Plan, C

ontractM

anagement

and Planning

ConfigurationIdentification

ConfigurationControl

StatusAccounting

and Reporting

Verificationand Audit

Control

Policy, Standards,Strategy,Service Portfolio,C

ustomer Portfolio,

Contract Portfolio,

Contract requirem

ents

Planning, managem

ent resources, time

Managem

ent support Working relationships

Resources, facilities, C

MS and tools Training

and Guidance

Updated R

FC, updated C

I

Status Record/R

eportC

onfiguration information

and Performance

Action items

Confidence in service

and infrastructure

CI Identification, nam

ing, labeling, data and docum

entation Baseline and R

elease Id


Table of Contents


The Configuration model ProcessThe process to create a Configuration Model ideally starts when you create a Configuration Management plan for a project, Service, or group of Services. Next, you need to identify the configuration information and document it in a Configuration Management plan. After finalizing the configuration plan, you need to follow configuration control mechanisms and ensure that any Changes to CIs, versions, locations, and ownership are recorded. Then, you need to maintain the Status Accounting and Reporting process. Finally, you need to verify and audit the configuration to ensure that the customer’s environment matches that of the CMS.

The type of Configuration Model we just saw is often used when there are many parties or suppliers. In this case, activities need to be established to obtain configuration information and data from third parties.

Configuration management TasksConfiguration Management essentially consists of the following four tasks:

y Identification – specify, identify, and include all IT components in the CMDB.

y Control – manage each CI and identify the people authorized to change it.


Table of Contents


y Status – record the status of all CIs in the CMDB and maintain this information.

y Verification – conduct reviews and audits to ensure the accuracy of the information contained in the CMDB.

Let us start by discussing a Configuration Management plan.

The Configuration management Plan A Configuration Management plan provides an overview of the organization, activities, overall tasks, and objectives of Configuration Management. It documents the level of Configuration Management required for the selected Service or project.

Most often, organizations create a Configuration Management plan for a project, Service, or group of Services, such as network Services. These plans define specific Configuration Management activities within the overall SACM strategy. You must note that there is no standard blueprint for SACM. Together, the management and Configuration Management teams must decide what level of Configuration Management is required for the selected Service or project. This level is documented in the Configuration Management plan.

Next, let us look at the contents of the Configuration Management plan.


Table of Contents


Contents of a Configuration management Plan A Configuration Management plan typically defines the context and purpose of the plan, its scope and requirements, applicable policies and standards, and Configuration Management information.

The plan should also contain information about the Asset and Configuration Management system and tools, the reference implementation plan, and the relationship management and control of suppliers and subcontractors.

Selecting and applying processes and procedures to perform SACM activities is also part of the Configuration Management plan.


Table of Contents


“Example of Asset and Configuration Management Plan ContentsThe contents of a typical Configuration Management plan are:

y “Context and purpose y Scope: This provides information such as:

o Applicable Services o Environment and infrastructure information o Geographical locations

y Requirements: This contains details, such as: o Link to policy or strategy o Link to business, Service Management, and

contractual requirements o Summarize requirements for accountability,

traceability, and auditability o Link to requirements for the CMS

y Applicable policies and standards: These provide information about:

o Policies o Industry standards, such as ISO/IEC 20000,

ISO/IEC 19770-1 o Internal standards relevant to Configuration

Management, such as hardware standards or desktop standards


Table of Contents


y Configuration Management organization: This lists: o Roles and responsibilities o Change and configuration control boards o Authorization- for establishing. baselines,

Changes, and Releases y Asset and CMS and tools y Selection and application of processes and

procedures to perform SACM activities, such as: o Configuration identification o Version management o Interface management o Supplier Management o Configuration Change Management o Release and deployment o Build management o Establishing and maintaining Configuration

Baselines o Maintaining the CMS o Reviewing the integrity of configurations and the

CMS (verification and audit)


Table of Contents


y Reference Implementation plan, e.g. data migration and loading, training and knowledge transfer plans.

y Relationship management and interface controls with for example:

o With financial Asset Management o With projects o With development and testing o With customers o With SPIs o With operations, including the Service Desk

y Relationship management and control of suppliers and subcontractors”



Table of Contents


End UserCom

putingService

DML

DefinitiveM

edia Library

IA InternalApplication

Service

UAUser/AccountM

anagement

INInfrastructure

Service

ITServices

ConfigurationIdentification

EUC5 EUCUser/AccessM

anagement

EUC6EUC

Infrastructure

EUC4EUC

Hardware

EUC3Rem

oteW

orking

EUC2 ServiceM

anagement

and Support

EUC1EUC

Release

EUC1–01EUCRelease Package

Specification

EUC1–02EUC

Release Baseline

EUC1–03EUC

Installation

EUC4–01EUC

Device

end user Computing sLr V3.0

end user Computing sLA V2.0

‘As specified’baseline

‘As released’baseline

‘As installed’baseline

service Catalogue4.0

Example of

documentation

for a CI

Adopted from exam

ple configuration breakdown for an end-user com

puting service ©

Crow

n Copyright 2007 R


GC

parent/childrelationship

uses/usedby relationship

Key

Documentation that represents

a CI is shown in bold.


Table of Contents


Location(Physicaland logical)

ABCM

anagedVirtual System

ServiceCatalogue

Examples of CI

baselines anddocum

entation

Initial configuration baseline RFCs - linked to relevant CIs

ABC1Physical

Sub-SystemABC2

Host Operating

SystemABC3Virtual

Sub-SystemABC4

SystemM

anagement

ABC5M

odel andSettings

ABC6Capabilities

ABC7Statistics &

Performance

Managem

entABC8

SupportABC9

SupportService

ABC11Physical

Assembly

ABC21 HostO

perating System

Installation

ABC31Logical

Assembly

ABC41Configuration &

Software Deploym

ent Manager

ABC42O

prerations &Event M

anager

ABC43Capacity &ResourceM

anager

ABC44Storage

Managem

ent

ABC45Backup &Recovery

managem

ent

A111Physical

Sub-SystemA211

Host Operating

SystemA311Virtual

Sub-SystemA312

SystemM

anagement

A313M

odel andSettings

A314Capabilities

Virtual sub-system exam

ple: Server stack, storage stackPhysical assem

bly examples: Physical com

puter, hard disc, SAN,network card, switches.Logical assem

bly examples: guest operation system

, utilities,m

iddleware, system software, applications

Keyparent/child

Other relationships

e.g. installed on, useslocated, supported, hosted

- Virtual model

- Configuration settings

- Capacity plan

- Collated statistics- Perform

ance baseline

- Support Access- Diagnostics

- Agreement

- Design specification- Prim

ary ownerIEtc.

Adapted from example configuration breakdow

n for a managed Virtual system

©


GC


Table of Contents


factors to Plan Configuration IdentificationLet us start by discussing the factors that you need to consider when planning the configuration identification process. To plan configuration identification, you must first:

y Identify the selection process for classes, types of assets, and CIs.

y Identify the process to group and define the identified elements by appropriate characteristics, such as Warranties for a Service. This ensures that all elements are manageable and traceable throughout their Lifecycle. The identification process also includes only predetermined levels of CIs to:

o Achieve a balance between information availability, the right level of control, and the resources and effort needed to support it.

o Facilitate the management of Change, control over Incidents and Problems, or control over assets that can be independently moved, copied, or changed.

o Facilitate Incident resolution in emergencies. For example, most organizations do not store data on consumables. However, some organizations find it worth retaining data on keyboards, for example, the United Nations, which supports many different languages.


Table of Contents


y Determine and document the approach to identification by defining naming conventions and labeling all the assets or Service components of interest across the Service Lifecycle and the relationships between them.

y Define the roles and responsibilities of the owner or custodian of the CI type at each stage of its Lifecycle.

factors That Influence Naming ConventionsAn appropriate naming convention is crucial for the success of any CMDB. All individual CIs should have a unique name. You must decide this name while accounting for some important factors, such as existing corporate or supplier naming/numbering structures.

The naming convention should include the management of: y “Hierarchical relationships between CIs within a

configuration structure y Hierarchical or subordinate relationships in each CI y Relationships between CIs and their associated

documents y Relationships between CIs and Changes y Relationships among CIs, Incidents, Problems, and

Known Errors”



Table of Contents


Activities of the Configuration Identification ProcessThe typical activities in the configuration identification process are:

y Defining and documenting criteria to select CIs and their components

y Assigning specific attributes to CIs such as: o A unique identifier o A CI type o A name/description o A version, for example, file, build, baseline, and

Release o A unique location o A supply date o License details, for example, expiry date o An owner/custodian o Status o Supplier/source o Related document masters o Related software masters o Historical data, for example, the audit trail o Relationship type o Applicable SLA

y Selecting the CI based on documented criteria


Table of Contents


“Configuration documentation for assets and responsibilities through the service lifecycle

Service lifecycle stage

Examples of service

lifecycle assets and

CIs im

pacted

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service

Improvem

ent

Service

Strategy

Portfolios – service contract, customer

Service Strategy

requirements

Service lifecycle model

A C C R C


Table of Contents



Examples of service


CIs im

pacted

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service

Improvem

ent

Service

Design

Service package (including SLA)

Service Design package,

e.g. service model,

contract, supplier’s

Service Management

Plan, process interface

definition, customer

engagement plan

Release policy

Release package

definition

I A C R C


Table of Contents



Examples of service


CIs im

pacted

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service

Improvem

ent

Service

Transition

Service Transition model

Test plan

Controlled environments

Build/installation plan

Build specification

Release plan

Deployment plan

CMS

SKMS

Release package

Release baseline

Release documentation

Evaluation report

Test report

I C A R C


Table of Contents



Examples of service


CIs im

pacted

Service Strategy

Service Design

Service Transition

Service Operation

Continual Service

Improvem

ent

Service

Operations

Service Operations model

Service support model

Service desk

User assets

User documentation

Operations

documentation

Support documentation

I C C A/R R

Continual

Service

Improvement

CSI model

Service improvement plan

Service reporting process

A/C A/C A/C R A

R=Responsible, A=Accountable, C=Consulted, I=Informed”



Table of Contents


relationship Between CIsIdeally, the Configuration Model must define the relationship between all identified CIs in each structure. This relationship describes how all identified CIs work together to deliver the Service. The CMS has information about this relationship. The relationships between CIs help provide dependency information, such as data if a CI is part of another CI, a CI is connected to another CI, or a CI is installed on another CI.

These relationships are also the mechanism to associate RFCs, Incident records, Problem records, Known Errors, and Release records with the Services and the IT infrastructure CIs to which they refer. You must include all these relationships in the CMS.


Table of Contents


Adapted from exam

ple of service lifecycle configuration levels and baseline points, represented by thenumbered triangles

© Crown Copyright 2007 Reproduced under licence from O

GC

Define Customer/Business

Requirements

Validate Service Packages, O

fferings, and Contracts

Define Service Requirem

entsService Acceptance Test

Service Operational

Readiness TestDesign Service Solution

Design Service ReleaseService Release Package Test

Component and

Assembly Test

Develop Service Solution

1a

2a

3a

4a

5a5b

4b

2b

1b

Service Com

ponentBuild and

Test

Internal and External Suppliers

Level 1

Level 2

Level 3

Level 4

Level 5

Levels of Configuration and Testing

Baseline Point

Deliveries from Internal and

External Suppliers

Service Review Criteria/Plan• C

ontract, Service Package, SLP, SPI

Service Acceptance Criteria/Plan• SLR• D

raft SLAService Operational Criteria/Plan

• SDP including:

• Service Model

• Capacity and

resource plansService Release Test Criteria and Plan

• Release D

esign• R

elease plan

BL

3b


Table of Contents


Configuration BaselinesAnother key task in the process to create a complete and structured CMS is to identify Configuration Baselines. You must demarcate these baselines by way of a formal agreement at specific points. You then use this agreement as a departure point for the formal control of a configuration.

example of Configuration BaselinesAn approved description of a Service that includes internally consistent versions of requirements, requirement traceability matrices, design, specific Service components, and user documentation

Now, let us discuss configuration control.

Configuration ControlConfiguration control is a system that makes sure that the mechanisms that monitor CIs, while maintaining a record of Changes, versions, locations, and custodianship/ownership, are adequate.

If you do not control physical or electronic assets, components, and configuration data and information, there will be a mismatch with the physical world. In fact, you must ensure that you do not add, modify, replace, or move a CI without making an entry in appropriate controlling documentation or following a specified procedure.


Table of Contents


organizational PoliciesEach organization must have policies in place that cover:

y License control – to make sure of the absence of unlicensed use and software wastage

y The Change Management process y Version control over Service Assets, software and

hardware versions, images/builds, and Releases y Access control, for example, to facilities, storage areas,

and the CMS y Build control, including the use of build specifications from

the CMS to perform a build y Promotion and migration of electronic data and information y Taking a Configuration Baseline of assets or CIs before

performing a Release – this is used to subsequently check against actual deployment

y Deployment control, including distribution y Installation y Maintaining the integrity of the DML



Table of Contents


factors That Influence CIsA number of procedures can change a CI. You must review and align these CIs with CI types, where possible, because standardization prevents errors. In addition, during the planning stage, it is important to design an effective configuration control model. You must implement this model in a manner that allows staff to easily locate and use the associated training products and procedures. There must be a control plan for each Configuration Management tool. You must align this plan with the overall configuration control model.

It is important to pass control from the project or supplier to the Service Provider at the scheduled time, with accurate configuration information, documentation, and records. Further, it is important to make and signoff a comprehensive checklist covering the Service Provider, information requirements, supplier information, and organizational information.

Supplier agreements should contain provisions to conduct SACM. It is also important to establish and maintain control methods during the development Lifecycle to ensure that the configuration data is complete and consistent. These methods might include baselines on transitions, defined audit policies, and audit intervals. You should implement these Changes as a deliverable of the new or changed Service.


Table of Contents


Adapted from example of asset and configuration item

lifecycle ©


GC

Configuration

Managem

ent

Application Release

Configuration

Managem

entR

eleaseM

anagement

AcceptedInstalled

Withdraw

nR

egistered


Table of Contents


Asset and CI LifecycleAs you can see in the Asset and CI Lifecycle diagram, each asset or CI needs to be in one or more discreet states to progress well. The significance of each state is directly related to the usage of that asset or CI in that particular state. Typically, a range of states will be relevant to an individual asset or CI.

Status accounting and reporting ensures that all configuration data and documentation is recorded as each asset or CI progresses through its Lifecycle.

Status reporting provides current and historical data related to each CI. This enables the tracking of Changes to CIs and similar activities.

Asset and CI PhasesThe different phases of the asset and CI Lifecycle are:

y development or draft: In this stage, the CI is under development and you should not rely on it.

y Approved: In this stage, the CI is used as a basis for further work.

y Withdrawn: In this stage, a CI is no longer in use, either because it is no longer fit for purpose or because there is no further use for it.

It is important to define the manner in which the CI moves from one stage to another. In the asset and CI Lifecycle diagram you just saw, an application Release may be Registered, Accepted, Installed, or Withdrawn.


Table of Contents


After every Lifecycle status Change, update the CMS with the reason, date-time stamp, and person who performed the Change. The planning activities should also establish any attributes that you need to update at each state.

Now, let us understand the purpose of configuration status accounting and reporting.

Configuration statusConfiguration status accounting and reporting ensures the recording of all configuration data and documentation as each asset or CI progresses through its Lifecycle. This means that as the CI changes from a state such as Development, Test, Live, or Withdrawn to another state, its status is recorded in the status report.

You create configuration status records during the configuration identification and control activities. These records not only manage the evolving configuration efficiently but also enable visibility and traceability. Configuration Management requires some reports. These might vary based on requirements.


Table of Contents


example of Configuration management Based on requirementsYou can create reports that cover individual CIs, a complete Service, or the complete Service Portfolio. Some examples of reports include a list of product configuration information included in a specific Configuration Baseline, a list of CIs and their baselines, and details of the current revision status and Change history.

The organization’s Financial Management process often requires status reports of assets for a Business Unit or software license holdings for budgeting, accounting, and charging purposes.

Contents of recordsRecords typically include:

y Service configuration information, such as identification number, title, effective dates, version, status, Change history, and its inclusion in any baseline.

y Service or product configuration, such as design or build status.

y Status of the Release of new configuration information. y Changes implemented and in progress. y Results from quality assurance tests to update the

configuration records.


Table of Contents


Typical Configuration reports Typical configuration reports include:

y Product configuration information included in a specific Configuration Baseline.

y CIs and their Configuration Baselines. y Details of the current revision status and Change history. y Status reports on Changes, waivers, and deviations. y Details of the status of delivered and maintained products

concerning part and traceability numbers. y Revision status. y Reports on the unauthorized usage of hardware and

software. y Unauthorized CIs detected. y Variations from the CMS to physical audit reports.

Configuration status Accounting and reporting Activities To support and enable an efficient Configuration Management process, the organization should perform configuration status accounting and reporting activities throughout the Service Lifecycle. Typical activities include:

y Maintaining configuration records through the Service Lifecycle and archiving them according to agreements,


Table of Contents


relevant legislation, best- practice standards, such as ISO 9001, or a Quality Management System.

y Managing the recording, retrieval, and consolidation of the current configuration status and the status of all preceding configurations to confirm information correctness, timeliness, integrity, and security.

y Ensuring that the status of items under Configuration Management is available throughout the Lifecycle, for example, you follow access, Change, build, and Release controls appropriately.

y Recording Changes to CIs, from receipt to disposal. y Ensuring proper documentation of Changes to

Configuration Baselines. You can do this by consolidating the evolving configuration states of CIs to form documented baselines at designated times or under defined circumstances.


Table of Contents


examples of service Assets and Configuration reports

y Status reports on Changes, waivers, and deviations y Details of the status of delivered and maintained

products related to part and traceability numbers y Revision status y Reports on the unauthorized use of hardware and

software y Unauthorized CIs detected y Variations from the CMS in physical audit reports

Verification and Audit ProcessThe verification and audit process helps:

y Ensure conformity between the baselines and the actual business environment.

y Verify the physical existence of CIs in the organization, DML, and spares stores, verify the functional and operational characteristics of CIs, and check that the records in the CMS match the physical infrastructure.

y Check that Release and configuration documentation is present before a Release.


Table of Contents


Audit TimingYou must consider audits at the following times:

y Soon after Changes to the CMS y Before and after Changes to IT Services y Before a Release or installation to make sure that the

environment is as expected y After recovery from disasters and after a “return to normal”

(You should include this audit in contingency plans.) y At planned intervals y At random intervals y In response to the detection of any unauthorized CIs

3.4.5 TrIgger, INPuTs, ANd INTer-ProCess INTerfACesA C T I V I T y I N W o r K B o o K

The SACM process captures an organization’s asset portfolio details, such as asset configurations, contractual terms and conditions, and ownership and financial attributes. A comprehensive, centralized Asset Management process can make accurate, up-to-date information available, as needed, for harvesting and reusing assets and for the asset allocation, budgeting, and chargeback of IT Services to meet business goals.


Table of Contents


Trigger Inputs such as Change Requests, purchase orders, acquisitions, and Service Requests trigger updates to Asset and Configuration Management information.

InputsThe following are the inputs of the SACM process:

y Change Requests y Purchase orders y Acquisitions y Service Requests

Interfaces with other ProcessesSACM interfaces with the following processes:

y Change management – identifies the Impact of proposed Changes

y financial management – captures key financial information, such as costs, depreciation methods, owners and users (for budgeting and cost allocation), and maintenance and repair costs

y ITsCm – creates awareness of the assets that business Services depend on and control over key spares and software

y Incident/Problem/error management – provides and maintains key diagnostic information and maintains and provides data to the Service Desk


Table of Contents


y Availability management – detects points of failure

3.4.6 KPIs ANd meTrICsKPIs and metricsKPIs help an organization define and measure progress toward organizational goals. All SACM KPIs must have a specific meaning.

As with all other processes, it is important to monitor and report the performance of SACM and take appropriate action to improve it. SACM is the central support process facilitating the exchange of information with other processes.

However, SACM acts as an underlying engine for other processes in the Service Lifecycle. As a result, it is important to measure the contribution of Service Asset and Management to these parts of the Lifecycle and the overall KPIs directly affecting the customers.


Types of measuresEach organization has its own set of measures for Asset and Configuration Management.


Table of Contents


examples of the Types of measures used Within organizations

y “Percentage improvement in maintenance scheduling over the life of an Asset (not too much, not too late)

y Degree of alignment between provided maintenance and business support

y Number of Assets identified as the cause of Service failures

y Improvement in the speed of Incident Management to identify CIs and restore Services

y Impact of Incidents and Errors affecting a particular CI type, for example, from particular suppliers or development groups, for use in improving IT Services

y Percentage reuse and redistribution of under-utilized resources and Assets

y Degree of alignment of insurance premiums with business needs

y Ratio of used licenses against paid-for licenses; this should be close to 100%

y Average cost per user for licenses, which results in achieving more effective charging options


Table of Contents


y Achieved accuracy in budgets and charges for the Assets that each customer or Business Unit utilize

y Percentage reduction in the business Impact of outages and Incidents caused by a poor Asset and Configuration Management process

y Improved audit compliance”

“Other measures include: y “Increased quality and accuracy of Asset and configuration

information y Fewer errors caused by people working with out-of-date

information y Shorter audits as quality Asset and configuration

information is easily accessible y Reduction in the use of unauthorized hardware and

software, non-standard and variant builds that increase complexity, support costs and Risk to the business Services

y Reduction in the average time and cost of diagnosing and resolving Incidents and Problems (by type)

y Improvement in time to identify poor-performing and poor-quality Assets

y Occasions when the ‘configuration’ is not as authorized


Table of Contents


y Changes that were not completed successfully or caused errors because of poor Impact assessment, incorrect data in the CMS, or poor version control

y Exceptions reported during configuration audits y Value of IT components detected in use y Reduction in Risks due to early identification of

unauthorized Change”


3.5 reLeAse ANd dePLoymeNT mANAgemeNToverviewThe Release and Deployment Management process builds, tests, and delivers the capability to provide the Services that Service Design specifies as necessary to meet stakeholder requirements and deliver the intended objectives.

3.5.1 PurPose, goALs, ANd oBjeCTIVesPurpose:The purpose of Release and Deployment Management are:

y Define and agree to Release and Deployment plans with customers and stakeholders.

y Ensure that each Release Package consists of a set of related and compatible assets and Service components.


Table of Contents


y Ensure that you maintain the integrity of a Release Package and its components throughout transition activities and record them accurately in the CMS.

y Ensure that it is possible to track, install, test, verify, and/or uninstall or back out all Release and Deployment packages, as appropriate.

y Manage organization and stakeholder Change during Release and Deployment activities.

y Record and manage deviations, Risks, and issues related to a new or changed Service and take the necessary, corrective action.

y Transfer knowledge appropriately to enable customers and users to use the Service optimally.

y Transfer skills and knowledge to operations and support staff to enable them to effectively and efficiently deliver, support, and maintain the Service according to required Warranties and Service levels.

goals: y Deploy Releases into production. y Establish the effective use of Services to deliver value to

the customer. y Hand the Services over to Service Operations.

objectives: y Ensure the presence of clear and comprehensive Release

and Deployment plans that enable the customer and


Table of Contents


business Change projects to align their activities with these plans.

y Ensure that a Release Package is built, installed, tested, and deployed efficiently to a deployment group or target environment successfully and on schedule.

y Ensure that a new or changed Service and its enabling systems, technology, and organization are capable of delivering the agreed Service requirements, that is, Utilities, Warranties, and Service levels.

y Ensure that there is minimal unpredicted Impact on the production Services, operations, and support organization.

y Ensure that customers, users, and Service Management staff are satisfied with the Service Transition practices and outputs, for example, user documentation and training.

3.5.2 sCoPe ANd VALue To The BusINessscopeRelease and Deployment Management includes all the processes, systems, and functions necessary to package, build, test, and deploy Release components into the live production environment. This process is also responsible for training end users and operating staff, as well as circulating documentation on the newly deployed Release or the Services it supports. By educating end users, Release Management aims to protect the live environment.

In addition, Release and Deployment Management sets up all


Table of Contents


Services specified in the Service Delivery Package (SDP) before handing the Service over to Service Operations.

Value to the BusinessWith a well-planned and implemented Release and Deployment process, you can reduce the Service costs of your organization significantly. On the other hand, a poorly designed Release or Deployment process can force IT personnel to spend significant amounts of time on troubleshooting Problems and managing complexity. It can also result in crippling the environment and degrading the live Services.

If you plan and implement the Release and Deployment correct, you can make a significant difference to an organization’s Service costs. Effective Release and Deployment Management enables the Service Provider to add value to the business. The process helps:

y Deliver Change faster, at optimal cost and minimal Risk. y Enable the use of the new or changed Service by

customers and users in a manner that supports business goals.

y Contribute to meet audit requirements for traceability through Service Transition.

y Improve consistency in the implementation approach across the business Change, Service teams, suppliers, and customers.


Table of Contents


3.5.3 PoLICIes, PrINCIPLes, ANd BAsIC CoNCePTs

Adopted from sim

plified eaxmple of release units for an IT service


OG

C

IT Service A

A1A2

A3

A2.1A2.2

A2.3

A2.1.1


Table of Contents


release and deployment management PolicyAs you saw earlier, the goal of Release and Deployment Management is to deploy Releases into production and establish the effective use of the Service to deliver value to the customer. An important concept in this process is managing what you call a Release Unit.

A Release Unit is that portion of a Service or IT infrastructure that is normally released together according to the organization’s Release policy.

release unitA Release Unit typically is a collection of infrastructure items. These items, when packaged together, perform a useful function.

examples of release unitsLaptops, operating systems and applications, or an enterprise-wide application

While the size of the unit might vary, depending on the type(s) or item(s) of Service Assets or Service components, such as software and hardware, you must aim to decide the most appropriate Release Unit level for each Service Asset and component. For example, to make sure that an application has been thoroughly tested, your organization might decide that the Release Unit for business-critical applications is the complete application.


Table of Contents


factors for the Appropriate Level of release unitsYou just worked out a way to classify Releases. Let us quickly look at some factors that you must take into account when deciding the appropriate level for Release Units:

y The amount of Change necessary for releasing and deploying a Release Unit

y The amount of resources and time required to build, test, distribute, and implement a Release Unit

y The complex nature of interfaces between the proposed unit and the rest of the Services and IT infrastructure

y Availability of storage capacity in the build, test, distribution, and live environments

Identifying releasesYou must make sure that you identify all Releases uniquely per the scheme defined in the Release policy. The Release identification process includes a reference to the CI that it represents along with a version number consisting of two or three parts.

Principles of Common release and deployment optionsLet us look at some common Release and Deployment options that Service Design considers during transition:

y Big bang versus phased y Push versus pull y Automation versus manual


Table of Contents


y Release Packages y Baselines

You just defined the pros and cons of various Release and Deployment approaches. Let us look at each approach in detail.

* Additional Workstations

Adopted from options for ‘big bang’ and phased rollout


OG

C

Release Policy

Release 1

Release 2

Release 3

1234*5*

123456*

7*

1234567

8*

Initial Launch‘Big Bang’ roll-out

Phased roll-out


Table of Contents


release and deployment ApproachesThe Big Bang Approach

As the name suggests, the big-bang approach aims to deploy a new or changed Service to all users in one operation, that is, to launch the Release all at once. You need this approach to introduce an application Change across the organization to ensure the consistency of the Service.


Table of Contents


A phased roll-out across several geographical locations

Head O

ffice

Branch 1

Branch 2

Branch 3

Month

12

34

56

7 8

Release 1

Release 2

Release 3

Release 1R

elease 1

Release 1

Release 2R

elease 2

Release 2

Release 3

Adopted from Phased deploym

ent across geographical locations©


GC


Table of Contents


The Phased Approach

The phased approach is a diametrically opposite approach to the big bang approach. In this, you deploy the device initially to a part of the user base and then repeat the operation for subsequent parts of the user base via a scheduled rollout plan.

The Push and Pull Approach

Complementing the big-bang and phased approaches are the push and pull techniques. In the push approach, you deploy the Service component from the center and push it out to target locations. Pull, on the other hand, relies on users to download the software to their location at their chosen time. Because some users might never download the software, an organization could choose to eventually push a Release to get all users to the same level, for example, an anti-virus update.

As far as Service Deployment is concerned, delivering updated Service components to all users, in either big-bang or phased form, constitutes a push. This is because you deliver the new Service to the users at a time not chosen by them, that is, you push the Service into the users’ environment.

Automation Versus Manual

Another factor to plan and define is how the Service will be released and deployed. There are two ways to do this, either use an automated mechanism for Release and Deployment or perform the process manually. While an automated mechanism may be more error free, it might need time and effort to develop and, consequently, might not always be a viable option. However,


Table of Contents


a manual mechanism needs more monitoring and Impact measurement, which might make the process slow and error prone. In addition, too many manual activities lead to delays in executing the Release.

User

documentation

Application

Release U

nit

Databasechange

Web C

lientC

entral serversoftw

areR

eleasedocum

entationS

SA

SS

B

Custom

erS

ervice A

SS

AU

1

SS

AU

2

SS

AU

3

SS

AU

4

Release P

ackage A

9 V1.0

Adapted from exam

ple of a release package © Crown Copyright 2007 Reproduced under licence from

OG

C


Table of Contents


Variations of the Phased ApproachSome variations of the phased approach include the:

y Phased delivery of portions of the Service to the live environment. However, the application affects all the end users simultaneously, that is, while the deployment is done in phases, it is actually activated for all users simultaneously. Examples include incremental Changes to a shared application.

y Gradual deployment of each Release across the entire population of end users. Examples include deployment at one geographical location at a given time.

y Deployment of different types of Service elements in separate phases. Examples include first deploying the hardware Changes, followed by user training, and then deploying the new or changed software.

y Deliberate variations in the adoption of a combination of all these approaches in light of actual deployment experience.


Table of Contents


examples of release and deployment ActivitiesSome examples of Release and Deployment activities that you can automate to a specific degree are:

y Automated builds that decrease build and recovery times

y Automated processes to load and update data y Automated Configuration Baseline procedures y Discovery and installation software that ensures that

the target environment is at the anticipated level y Discovery tools aid Release planning y Automatic updating of user and license information in

the CMS


Table of Contents


Adopted from Architecture elem

ents to be built and tested ©


GC

Current Baseline (as-is)

Business/Organization

Architecture

Service Architecture

ApplicationArchitecture

Technology Architecture

Product Architecture manipulated by

supported by

delivery, feedbackand m

onitoring

releasePackage

Target Baseline (to-be)

BuildandTest

ServicePortfolio

Information and

Data Architecture

BA ro1

sA ro1

AA ro1

TA ro1

Business/Organization

Architecture

Service Architecture

Application Architecture

Technology Architecture

Product Architecture manipulated by

supported by

delivery, feedbackand m

onitoring

ServicePortfolio

Information and

Data Architecture

UsingUsing


Table of Contents


Release Packages and Baselines

It is a benchmark used as a reference point. In case of a new or changed Release, it is the trusted state of an item.

Baselining a Release and placing it under the control of the Configuration Management process ensures that there is consistency in all further Changes to the Release. Usually, each Release consists of a Release Package, which is baselined. You may design a Release Package as a single Release Unit or a structured set of Release Units.

It is important to build the Release Package in a standard, controlled, and reproducible way in line with the solution design defined in the SDP. You might need to rebuild this package further in the Release and Deployment process.


3.5.4 ProCess ACTIVITIes, meThods, ANd TeChNIQuesrelease and deployment Plan ActivitiesThe Release and Deployment plan aims to derive a sound set of guidelines to transit the Release into production and subsequent deployment, scalable from small organizations to large multinationals. After the Release and Deployment plan is defined, pass or fail criteria for the plan should be specified.


Table of Contents


Build and Test Planning stage The next stage is the build and test planning stage. This stage establishes an approach to build, test, and maintain controlled environments before production. A popular approach in this regard is the Service V-Model.

It is useful to link Release and Deployment plans to the overall Service Transition plan and adopt the selected Release and Deployment model. You must aim to derive a set of guidelines that are scalable so that both small and large Changes as well as small or large organizations can use them to follow the Release procedure. The Change Management process authorizes the Release and Deployment plan.

release and deployment management stepsThe main steps involved in Release and Deployment Management are:

y Planning: This is the first step in which you need to: o Create Release and Deployment plans. Some of the

important elements to be included in the Release plan are:

� Scope and content of the Release� Risk assessment and Risk profile of the

Release� The organizations and stakeholders

affected by the Release� Approval authority for Change Requests


Table of Contents


(stakeholders and organizations) for the Release

� Release team details � Details of how to approach stakeholders

and deployment groups to determine the:• Strategy for delivery and deployment• Resources for Release and

Deployment• Amount of Change that the Release

can absorb o Define pass/fail criteria for each authorization point

through Release and Deployment. o Build and test by maintaining controlled environments

before production. o Plan pilots to test the Service with a small part of the

user base. o Plan Release packaging and build activities. o Create the deployment plan. o Develop the logistics and delivery plans. o Check the financial and commercial aspects

before adding the deployment and activities to the deployment plans.


Table of Contents


y Preparation for build, test, and deployment: Before authorizing the build and test stage, you must:

o Validate the Service Design and the Release design against the requirement for the new or changed Service.

o Validate Service and Release Design against the requirement for a new or changed Service offering.

o Record, track, and measure any Risks and issues against the Service Assets and CIs within the Service package.

o Prioritize actions and make sure that they can be resolved within the time frame.

o Produce a validation report and associated results for Service Evaluation.

y Building and testing: To do so, you need to: o Consider Release and build documentation, such

as contract agreements, purchase requests and ordering, Request Fulfilment, goods inward and delivery, and health and safety guidelines.

o Acquire and test input CIs and components, such as Services and Service Assets.

o Build Release packaging in a standard, controlled, and reproducible way in line with the solution defined.

o Ensure effective build and management of the test environments.


Table of Contents


y Service testing and pilots: Coordinate the testing activities through test management. To do so, you need to:

o Simulate Service rehearsals. o Plan and prepare for the Service rehearsals. o Deliver the rehearsal (do). o Check and document the activities and feedback for

the Service rehearsal. o Take necessary actions following the rehearsal (act). o Run pilots.

y Planning and preparing for deployment: Develop plans and prepare for deployment. Prepare the deployment group for deployment and the organization and people for organizational Change.

y Transfer, deployment, and retirement: In this step, you need to:

o Transfer financial assets. o Transfer/transition the business and organization. o Deploy processes and materials. o Deploy Service Management capacity. o Transfer the Service. o Deploy the Service. o Decommission and ensure Service retirement. o Remove redundant assets.


Table of Contents


y Verify deployment: When the deployment activities are complete, it is important that you verify users, Service Operations, and other staff and stakeholders who are capable of using or operating the Service.

y ELS: Plan and provide ELS to ensure the transition of the new or changed Service to Service Operations in a controlled manner and establish the new Service capability and resources.

y Review and close a deployment. y Review and close Service Transition: This is the last step

in which you need to perform a formal review to finalize that Service Transition is complete.

Release Criteria

Release and Deployment plans are linked to the overall Service Transition plan. Even in a single organization, Release and Deployment must be scalable because the extent of the Impact on the organization might vary from an Impact on one specialist team to a global Impact on all users.

Each Release must have a defined set of minimum pass/fail criteria. Defining these criteria falls under the scope of the Service Transition process. You must define criteria for each authorization point through the Release and Deployment stage.


Table of Contents


Build and Test stageDuring the build and test stages, you need to effectively manage Services and infrastructure that can significantly affect the build and test of a technology-enabled Service and its underlying technology infrastructure.

Next, let us look at some of the advantages of running a pilot.

Advantages of Running a Pilot

Having a group of end users try the Service before its full deployment has immense benefits. The level of pilot testing you want to perform depends on the size and scope of your migration project. For larger projects, a formal, carefully planned pilot is essential. For a project of any size, it is good to have selected end users to test the system before full deployment.

Pilot Scope

You must determine the scope of any pilot used in testing. If the scope is too large, you will not be able to deliver the Service at the required speed and with the required flexibility. In fact, a pilot with a large scope will effectively turn out to be the first rollout.

In some situations, it makes sense to run a range of pilots on the Service or Change. These could be different pilots for different geographical locations, different user groups, and so on. Multiple pilots provide the Service Desk with data on benefits and pass/fail situations for a range of users. The Service Desk can analyze this data and roll out the best solution.


Table of Contents


Some of the factors to consider are: y The speed and cost of running multiple pilots y The diverse nature of the organization y Trial options y The inclusion or exclusion of specific user groups

Pass/Fail Criteria

It is important to publish pass/fail criteria to relevant stakeholders well in advance to set expectations correctly.

example of a Pass situation y All tests are completed successfully. y The evaluation report and the RFC for build and test

are signed off.


Table of Contents


examples of fail situations y The build test does not allow the process to move

to the next stage because of insufficient resources. For example, consider a case where an automated build cannot take place. In this case, the resource requirement becomes error prone and expensive. Another example is the testing phase identifies a shortage of funds to deliver the proposed design in the operations phase.

y Service Operation does not support particular Service attributes.

y Service Design does not conform to Service Operation standards for technologies, protocols, regulations, and so on.

y The Service cannot be delivered within the design constraints’ boundaries.

y Service acceptance criteria are not met. y The documents mandatory for going to the next stage

are not signed off. y Both the Service Knowledge Management System

and the CMS are not updated. This could be because of a manually intensive process.

y Incidents, Problems, and Risks are higher than expected.


Table of Contents


Build and Test PlanAfter pass/fail criteria are established, you need to create a build and test plan. This includes:

y Listing the activities required to build, test, and maintain controlled environments before production.

y Building the controlled test environments. y Creating build plans from the SDP, design specifications,

and environment configuration requirements. y Managing logistics, lead times, and build times to set up

environments. y Checking the build and related procedures. y Setting up the build and test activities. y Allocating resources, roles, and responsibilities to perform

key activities, such as: o Security procedures and checks o Technical support o Creating build and test environments o Running test databases and test data o Software Asset and license management o Configuration Management – configuration audit,

build, and baseline management y Laying down and agreeing to the build exit and entry

criteria


Table of Contents


Configuration Levels for Build and Testing

“Level Requirements and design Build/deliverable Validation and

testing

Level 1

Customer/business

Needs

Structured definition

of contract

requirements

Customer contract

(based on Service

Portfolio, SLP)

Service test and evaluation

Determines whether a service can enable the users and customers to use the service to support their

business needs (is fit for purpose and fit for use).

Level 2 Service

requirements

Service requirement

specifications and

SAC, traceable back

to the contract

requirements

Service capability and

resources to deliver

against the SLA and

service requirements

Service test

Test the Service Acceptance Criteria are met. Includes validation of service performance against the service level requirements and SLA in pilots, deployment and early life support.


Table of Contents



testing

Level 3 Service

solution

SDP, Service model,

service environments

Solution/system

required to deliver the

service capability;

includes the Service

Management and

Service Operations

systems and

capabilities

Service operational readiness test

To evaluate the integration and operation of the service capability and resources. It verifies that the

target deployment organization and people are prepared to deploy and operate the new or changed

service in the live environment, e.g. deployment team, Service Operations, customers, users and other

stakeholders. Tests include scenario-based testing such as simulation and service rehearsal.


Table of Contents



testing

Level 4 Service release

Release package

Service release test

A test that the service components can be integrated correctly and that the release can be installed, built

and tested in the target environments. Service release testing includes non-functional testing that can be performed at this level.


Table of Contents



testing

Level 5 Component

and assemblies

Component and

assembly test

specification

Component or

assembly of

components

Component and assembly test

Test that a service component or assembly of components matches its detailed specification.

Components or assemblies are tested in isolation, with a view to their delivering as specified, in terms of inputs generating expected outputs. Evidence of component quality or testing earlier in the chain maybe obtained for test evidence, from both internal and external suppliers.”



Table of Contents


release and deployment environmentsThe types of environments, both logical and physical, required during Release and Deployment include:

y Build environment — used to compile or assemble the Release Package or Service Assets.

y Unit test environment — used to verify the functionality, performance, recovery, and usability characteristics of an individual Service component, such as an online procedure.

y Assembly test environment — used to verify the functionality, performance, recovery, and usability of an assembly or individual Service component.

y Integration environment — used to build and integrate Service components.

y System test environment — used to test all aspects of the integrated Service architecture, including application and technical infrastructure. Substantial user acceptance testing is also executed in this environment.

y Service Release test environment — used to install, build, and test a Release Package in a controlled environment. This type of environment is often combined with the system test environment.


Table of Contents


y Service Operations readiness test environment — used to test the Service and Service Unit capabilities before promotion into the live environment. This type of environment might include a Service Management acceptance test, some operational acceptance tests, and user acceptance tests of the end-to-end Service.

y Business simulation environments. y Service Management simulation environments. y Training environments — might include an established test

database that can be used as a safe and realistic training environment.

y Pilot environments — might include conference room pilots.

y Backup and recovery environments — might include the disaster recovery process.

After the build and test planning stage for the controlled environments is completed, pilots are planned.

In the next stage, the Release packaging and build plan needs to be prepared.


Table of Contents


release Packaging and Build Plan Planning the Release packaging and build activities includes activities to develop the mechanisms, plans, or procedures for:

y Checking entry/exit criteria. y Ensuring appropriate communications with stakeholders

by: o Getting and maintaining the list of contacts and their

details. o Informing them of the proposed Changes, the

expected benefits, and how these benefits will help the organization and staff.

y Instructing people in training workshops and transferring knowledge.

y Setting up Services and Service Assets. y Finalizing schedules by:

o Setting delivery schedules and handling any Changes/delays in agreement with all concerned people.

o Confirming logistics, delivery procedures, and checklists.

o Scheduling controlled transition environments, facilities, and tools for:

� Acquiring Service Assets and components. � Release packaging, building, and testing.


Table of Contents


y Creating procedures and mechanisms using available Configuration Management, Release, content/electronic publishing, and other tools to:

o Build, copy, promote, distribute, audit, install, and activate a Release.

o Manage software licenses, digital rights, and Intellectual Property Rights (IPR).

y Switching systems and users from the current applications and technology to the new or changed Service.

y Creating the Service Management capability and resources for:

o Site surveys. o Bringing Service information up to date. o Creating and preparing management systems and

other operational systems. o Managing and handling the predicted capacity

required for support. o Managing the controlled environments including

procedures to scale up capacity, if required. o Recording and providing the information to be

created and/or updated during transition. o Installing the new or changed Service ready for

activation. o Transitioning a Service, Service team, or organization. o Decommissioning and/or disposing of Service Assets

and components.


Table of Contents


o Retiring Services. o Evaluating the readiness of a target deployment

group (customers, users, and Service Operations staff) to receive a Release.

o Setting and agreeing upon exit criteria.

You conduct deployment planning, followed by logistics and delivery planning, in the next stage. Financial or commercial planning takes place only in the last stage.

Questions and Answers When Planning deployment“Deployment question Examples

What needs to be deployed?

Do you have a good understanding of the service and release that is being deployed?

What are the components that make up the release package? What are the business drivers for the deployment? Is it required to meet a critical business need?

Who are the users?

Which users are affected by the deployment? What language do they use?

Do they need any special training?


Table of Contents


“Deployment question Examples

Are there location dependencies?

Are there any holidays, shut-downs or other interruptions to normal business at this location?

What level of detail needs to be recorded, e.g. building, floor, room?

Where are the users?

Are all the users and systems local to the deployment, or are some remote, and how will this affect the logistics?

Who else needs to be prepared well in advance?

Do the service desk and support staff need training? Are there any access issues to be solved – security or physical?

When does the deployment need to be completed?

Does the deployment need to be completed by a certain date and time or can it be completed by following a flexible schedule?

Why is the deployment happening?

Is the deployment needed to fix a problem or is it required for some new functionality that has been requested, and do the users understand what is coming?

What are the critical success factors and exit criteria?

How will you know that the deployment has been successful? Who will authorize the deployment? How will you know when the deployment is finished?


Table of Contents


“Deployment question Examples

What is the current capability of the service provider?

What are the current services, processes and Service Management capability – capacity, financial aspects, current systems and infrastructure?


financial and Commercial Planning AspectsYou need to check the financial and commercial aspects before the deployment and add activities to the deployment plans, where necessary. You need to check:

y Whether you have sufficient funds available as working capital to deliver to customer expectations

y Whether you have all the necessary contracts and licenses.


Table of Contents


y Whether you have funding available for the supporting systems to manage the Service.

y Whether Intellectual Property (IP) concerns, such as the full range of IP, its ongoing ownership, and its usage have been addressed. This includes:

o Software created by one of the parties. o User manuals and other documentation.


Table of Contents


RFCD1

RFCD2

Manage Changes

Manage deployment/decommission/transfer for each target group

Authorize deployment start Authorize activation Deployment Postimplementation review

Change/transferfinancial assets

Transfer/transitionbusiness andorganization

Deploy processes and knowledge

Deploy servicemanagement

capability

Transfer Services

Deploy Services

Deploy applications,

data, information

Deploy infrastructureand facilities

Assess readiness of target group

Plan and prepare for deployment

Decommission,retire and redeploy

service assets

Test deploymentreadiness and

activate the service

Review and closedeployment

Remediate/back-out release

BL1 BL2 BL3

Request for Change that governs the deployment

Baseline point

RFC

BL

Adapted from example of a set of deployment activities © Crown Copyright 2007 Reproduced under licence from OGC


Table of Contents


release and deployment PlanningRelease and Deployment planning includes all the planning and preparation activities to prepare a deployment group for deployment, effectively preparing the organization and its people for organizational Change. At this stage, you develop a detailed implementation plan, including assigning individuals to specific activities, during the actual deployment stage.

Criteria for a deployment group or environmentBefore you plan and prepare a target deployment group or environment, make sure that you have met the following minimum entry criteria:

y Made the deployment stakeholders feel confident and committed to the Service Release and own their aspects of deployment.

y Made sure that the senior management, customers, and business and Service Provider teams accept the deployment costs, and understand the management, organization, and people implications of the Release as well as all required process Changes.

deployment PreparationTo prepare for deployment, you:

y Assess each deployment group’s readiness to receive and implement a Release Package.


Table of Contents


y Identify gaps that need filling. y Plan the activities required to deploy, transfer, or

decommission/retire Services or Service Assets, including the transfer of a Service or Service Unit as well as move and disposal activities.

Let us discuss assessment now.

AssessmentAlthough you should perform the deployment readiness assessment activity early in the transition, you must revisit it periodically and feed the assessment results into detailed implementation plans for the target deployment group.

Issues and risks of deploymentThis readiness activity involves several steps. At the onset, you must identify all issues and Risks involved in delivering the current Services, which might affect the deployment. The issues and Risks include:

y Lack of dedicated internal resources and external supplier resources.

y Lack of training, skills, and awareness. y Unplanned or late Changes in requirements.

Next, you must take into account all anticipated Impacts, organizational structure, the environment of the new or changed Services, direct customers and users, partners, and suppliers.


Table of Contents


After identifying all anticipated Impacts, you move on to assess financial implications, such as the current required working capital, the status of new and changed contracts, the validity of licenses, Intellectual Property Rights (IPRs), and digital rights.

other AspectsYou must also assess:

y The applicable financial aspects and assets such as: o Already available working capital and required

working capital o New or changed contracts, licenses, IPR, and digital

rights y The applicable health, safety, security, and environmental

regulations y The current capability of business customers and users to

use and gain value from the new or changed Service y The current Service, Service capability, and resources

used, including: o Service structure o Service dynamics o Service metrics and reports, including Warranties

and Service levels achieved


Table of Contents


y The current Service Management capability and resources, including:

o Differences from the prerequisites for deployment, such as inadequate licensing arrangements or network bandwidth

o Current operations and support resources, such as tools and people

o Support resources and workloads o Performance reports and improvement plans o Ability to predict and track actual Incident and

Problem volumes during deployment y Defining requirements to alter the new or changed Service

or underlying solution y Organizational readiness, including:

o Role, resource, and skills gap o Training needs o Ability to assign competent individuals to appropriate

roles o Motivation and empowerment, for example, whether

the current organization and culture encourage the application of the required skills with the right leadership and commitment

o Readiness of customers, users, Service Provider staff, and other stakeholders, such as suppliers and partners


Table of Contents


y Applications, information, and data, including: o Access to secret, restricted, or confidential

applications, information, documents, and data o User and support staff knowledge and experience

y Infrastructure and facilities, including: o Difficult access o Intermediate and final storage and stores for definitive

hardware and media o IT equipment space and capacity requirements

y Electromagnetic interference (EMI) and radio frequency interference (RFI) requirements

y Air quality requirements y Weight and false floor loadings y Network considerations y Environmental requirements related to equipment, health,

safety, and security

As the next step, you develop plans and prepare for deployment by assigning specific resources to perform deployment and ELS activities. While developing these plans, you identify and assess Risks specific to the deployment group by using the Service Model to identify business- and Service-critical assets that have the highest Risk of causing disruption.


Table of Contents


Activities during deployment Planning and PreparationThe activities you perform include:

y Develop Risk mitigation plans. y Develop transfer/transition, upgrade, conversion, disposal,

and retirement plans. y Plan logistics and delivery such as:

o Prepare Service Assets and components for deployment, establishing how and when they can be delivered and confirming that delivery been successfully achieved and recorded.

o Prepare sites according to applicable health, safety, security, and environmental regulations and requirements.

y Tailor processes, procedures, and knowledge, for example, incorporate language translation and timeframe adjustments.

y Transfer knowledge and train stakeholders on how to use, benefit, manage, support, and operate the new or changed Service. To do this, you:

o Identify essential and potential recipients of training such as customers, users, ITSM, the Service Desk, support, operations, deployment teams, and projects.

o Update the Service Desk with knowledge of the target deployment group and its environment.


Table of Contents


y Communicate the following to the people involved: o The Changes and their expected benefits. o How the Changes affect the organization and staff.

y Make any emergency Changes in continuity plans and procedures.

y Mobilize Service Operations and the support organization. y Mobilize users to be ready to use the Service. y Perform any additional activities identified from the

assessment.

Verification of deployment PlanThe next step is to verify the detailed deployment plans, perform any deployment readiness tests, and raise an RFC for authorization through Change Management. This ensures that the Service is ready for deployment.


3.5.5 TrIgger, INPuTs, ouTPuTs, ANd INTer-ProCess INTerfACesA C T I V I T y I N W o r K B o o K

TriggerThe Release process starts with the receipt of an approved RFC to deploy a production-ready Release Package. Deployment starts with the receipt of an approved RFC to deploy a Release


Table of Contents


Package to a target deployment group or environment, such as a Business Unit, customer group, or Service Unit. This triggers the deployment process.

InputsLet us now move on to inputs. A primary input for Release and Deployment Management is an authorized RFC. Other inputs include:

y “Authorized RFC y Service Level Packages (SLP) y SDP, including Service model and SAC y IT Service continuity plan and related business continuity

plan y Service Management and operations plans and standards y Technology and procurement standards and catalogues y Acquired Service Assets and components and their

documentation y Build models and plans y Environment requirements and specifications for build,

test, Release, training, disaster recovery, pilot, and deployment

y Release Policy and Release design from Service Design y Release and deployment models including template plans y Exit and entry criteria for each stage of Release and

deployment”



Table of Contents


outputsSome key outputs of the Release process are:

y “Release and deployment plan y Completed RFCs for the Release and deployment

activities y Service notification y Updated Service catalogue with the relevant information

about the new or Changed Service y New tested Service capability and environment

including SLA, other agreements and contracts, Changed organization, competent and motivated people, established business and Service Management processes, installed applications, converted databases, technology infrastructure, products and facilities

y New or Changed Service Management documentation y Service package that defines the requirements from the

business/customer for the Service y An SLP that defines the Service level requirements, e.g.

hours of Service, business critical Services, data and periods, Service level targets

y An SLA, underpinning OLAs and contracts y Service model that describes the structure and dynamics

of how the Service is operated and managed y New or Changed Service reports y Tested continuity plans


Table of Contents


y Complete and accurate CI list with an audit trail for the CIs in the Release Package and also the new or Changed Service and infrastructure configurations

y Service capacity plan that is aligned to the relevant business plans

y Deployment ready Release Package (baselined) –for future deployments

y Service Transition Report”


Inter-Process InterfacesTo conclude, the deployment process is complete after a handover of the new or changed Service to Service Operations. This transfer takes place only after the successful completion of the PIR of the deployment process conducted within the Change Management process.

3.5.6 KPIs ANd meTrICsKPIs and metricsAs with all other processes, it is important to monitor and report the performance of Release and Deployment Management. You must take appropriate action to improve the performance.

KPIs related to the Release and Deployment Management process can be divided into customer or business KPIs or Service Provider KPIs. Let us first understand customer or business KPIs.


Table of Contents


examples of Customer or Business KPIs y Increased customer and user satisfaction in relation

to delivered Services y Fewer Incidents, as measured against a Service y Minimal or reducing deviation from the Service

performance that customers require y Reduced customer dissatisfaction

examples of service Provider KPIs y Reduction in the number of resources and the cost of

fixing and diagnosing Incidents and Problems in both the deployment and production processes

y Greater use of the common standards framework, reusable processes, and supporting documentation of Service Transition

y Reduction in the number of discrepancies identified in configuration audits as compared to other organizations



Table of Contents


3.6 serVICe VALIdATIoN ANd TesTINgoverviewWhen you implement a Service Change, it is necessary to evaluate its effectiveness. The Change should fulfill user expectations to avoid instances of mismatches between customer expectations and Service Delivery. To do this, you need to validate and test the Service before you implement it to ensure that it is fit for use and delivers value for money.

Because each organization aims to meet customer requirements by providing quality Service, ITIL includes a process known as Service Validation and Testing. This process helps you fulfill expectations for any new or changed Service by providing quality assurance.

By implementing the Service Validation and Testing process, you will be able to reduce:

y Incidents and failures after Service delivery. y Calls to the Service Desk for clarification and Service

support. y Unresolved Problems and errors. y Cost involved in fixing errors. y Instances of ineffectively used Services that are not

delivering the desired value.

Testing and Validation is a new process introduced in ITIL v3. ITIL v2 covered some aspects of Release testing within the Release Management process. ITIL v3 gives more detailed guidance.


Table of Contents


A major addition is the details of various testing stages during Service Transition and descriptions of their testing approaches. You must remember that Testing and Validation is a key area within Service Management. In fact, lack of Testing and Validation might lead to the impression that the Service itself is inefficient. As a result, it is important to implement best practices in this area and improve overall Service Delivery.

3.6.1 PurPose, goAL, ANd oBjeCTIVesPurpose:The purpose of Service Validation and Testing includes:

y Plan and implement a process that will provide objective evidence that the Service Change will fulfill the customer’s business and stakeholder needs and deliver the appropriate level of Service.

y Provide quality assurance for the Service and its components.

y Identify and address all the issues, errors, and Risks in Service Transition.

goal:The ultimate goal of the Service Validation and Testing process is to enable the fulfillment of a customer’s business requirements.

objectives:The following are the objectives of Service Validation and Testing:

y Provide a Service that meets customer expectations.


Table of Contents


y Validate that a Service is fit for use without any constraints, and meets the specified terms and conditions of the customer.

y Ensures the correct definition of stakeholder requirements and corrects any errors as early in the Lifecycle as possible because it will be much more expensive to remedy them once the new or changed Service is in production.

3.6.2 sCoPe ANd VALue To The BusINessscope of service Validation and TestingUsually, a Service Provider is responsible for delivering, operating, and/or maintaining customer or Service Assets at specified levels of Warranty under a Service agreement. To do this successfully, you need to coordinate with suppliers, customers, and partners to validate and test a Service.

You use the Service Validation and Testing process throughout the Service Lifecycle to:

y Ensure Service quality. y Meet customer requirements. y Deliver the Service successfully.

To do this, you need to understand factors such as process interfaces and organizational interfaces, which will define the limits of the Service that you have to test.


Table of Contents


TestingThe following are associated with testing:

y Testing is applicable to in-house and developed Services, hardware, software, or knowledge-based Services and includes the testing of new or changed Services and Service components.

y Testing directly supports the Release and Deployment process by ensuring that you perform the appropriate and necessary tests at various levels in the build and deploy activities.

uses of service Validation and TestingYou use Service Validation and Testing to:

y Deliver and maintain Services within a specified Warranty level and Service agreement.

y Ensure the quality and timely delivery of a Service that meets all the requirements of a successful Service Release.

y Understand the suppliers’, customers’, and partners’ requirements clearly to validate and test the Service. Service Validation and Testing happens within a limit that the process and organization specify.

y Test the new or changed Service in the target Business Unit, Service Unit, deployment group, or environment.


Table of Contents


Value to BusinessIf the new or changed Service meets all the requirements and has had a successful Release, it has a positive effect on the business of the Service Provider as well as the customer. On the other hand, if the Service fails to deliver as expected, it might lead to losses in business, revenue, reputation, and time.

When you implement Service Validation and Testing, it enables you to ensure the expected quality and assure the customer that the new or changed Service will deliver the expected results. The assurance level, however, differs based on the complexity of business requirements and the environment of organizations.



Table of Contents


Adopted from service m

odels describe the structure and dynamics of a service


OG

C

Service Model

Configuration of

service assets(Service D

esign)

Service Operation

Activities, events and interactions (Service D

esign)

(Structure)

(Dynam

ics)


Table of Contents


PoliciesThere are various policies, principles, and basic concepts that you need to apply for the successful execution of the Service Validation and Testing process.

service Validation and Testing PoliciesLet us start with policies. The various policies included in Service Validation and Testing are:

y Service quality policy: The organization’s management defines quality. Service Strategy defines four quality parameters: level of excellence, value for money, conformance with specifications, and meeting or exceeding expectations. You have to meet one or more of these parameters to measure the quality of the Service. These parameters will help you evaluate how well you have designed the Service.

y Risk policy: Each organization, customer, business, or Service Unit has different perspectives of Risks and their management. Consequently, having a Risk policy in place ensures that the validation and testing team can control and minimize all types of Risks, such as availability, security, continuity, and capacity Risks.

y Service Transition policy: Each organization should define a policy to help its senior management manage all Changes to Services through Service Transition. You require this policy to align Service Transition plans with business needs using a standard framework. This policy


Table of Contents


also includes principles that will guide you to handle all activities related to Service Changes with respect to Service Transition principles.

y Release policy: The testing approach that you will follow for a Service depends on the type and frequency of Releases. As a result, it is important that you define a Release policy to state the frequency and type of the Releases, based on which you can use specific reusable test models or automated testing to improve efficiency.

y Change Management policy: This policy might allow substitution late in the Change schedule. If this is the case, you might require more testing to test the new combination that will be released together. The additional testing defined in the testing policy will verify and validate the Service again to avoid any gaps with requirements.

y The testing policy helps you:

o Create a test library and maintain reusable test data, test cases, test scripts, and test models to improve the efficiency of the team.

o Integrate testing into the project and Service Lifecycle to reduce defects, consequently reducing Incidents.

o Follow a Risk-based testing approach to reduce Risks in the Service.

o Interact with stakeholders on a continuous basis to understand their requirements and implement Changes, if any, based on their feedback to improve the Service.


Table of Contents


o Implement test measurements and monitoring systems to improve the efficiency and effectiveness of Service Validation and Testing.

o Adopt automated testing tools and systems to handle complex Services, such as Services distributed across locations or Services affecting business critical applications. Automated testing tools are also helpful when you have time constraints.

y Service Transition policy: This policy helps the senior management:

o Define, document, and approve a policy for Service Transition that all the departments of an organization can implement.

o Manage all the Changes to Services through Service Transition.

o Implement a standard framework for Service Transition, which constitutes reusable processes and systems, to improve efficiency and reduce varied results.

o Adopt and introduce existing or new processes and systems in the organization, which you can reuse to improve efficiency and effectiveness.

o Align Service Transition plans with business requirements and manage Service Changes to improve effectiveness and business value.


Table of Contents


o Adopt and maintain a relationship with stakeholders to understand their requirements for the new or changed Service.

o Apply a controlled and disciplined process to manage Service Changes and Releases.

o Develop systems and processes for knowledge transfer, which helps you function properly.

o Plan and design Release Packages to deliver Services in a low-cost and effective way.

o Manage and apply course corrections. o Manage all the resources across Service Transition

to avoid delays. o Validate the Service Change early in the Service

Lifecycle to ensure that the Service Change meets all the expectations.

o Evaluate and ensure that the new or changed Service functions and performs as expected.

o Plan and improve the quality of new or changed Services during Service Transition.


Table of Contents


Part 7Shipping

Part 10Authorize shipm

entPShip item

spurchased

Obtain final

confirmation

Provideconfirm

ation details

Present costw

ith shipping and tax

Presentshipping options

Part 5Assistance

Part 2Selection

Part 1Shopping

Present searchableand navigable catalogue

Search and sort

Assist shopperin selecting

Assist shopperin closing

Com

pleteorder

Initiate customer

satisfaction follow

-up

Part 11

Part 6 Maintain cart

contents

Provideshopping cart

Assign salesspecialist

Answer

questions

91012 1113

14

13 8 3 2 145

7 6

Payment processing

Special offers

(3rd party service)

Part 8C

alculateshipping andtax inform

ation

(3rd party service)

Part 9Subm

it detailsto shipper

(3rd party service)

Part 3 R

ecomm

endations

Part 4R

atings

Adapted from dynamics of a service m

odel © Crown Copyright 2007 Reproduced under licence from

OG

C


Table of Contents


Inputs to Testing and ValidationThe starting point for Testing and Validation is defining a test strategy. This documents the overall approach to organize, test, and allocate testing resources. You might choose to apply this at the macro level to the entire organization, a specific set of Services, or even an individual Service.

Before developing this test strategy, you must involve the applicable stakeholders. It is only after taking their inputs and agreement that you must go ahead with a final plan.

design of Test ApproachThe test approach is designed by:

y Using the SDP to determine test requirements and models.

y Optimizing the test coverage in relation to the Risk and Impact of the Change and resources.

y Using the acceptance criteria to create entry and exit criteria for the levels of the Service V-Model.

y Translating Risks and issues into test requirements.

Project managers should be involved to ensure that testing is integrated into project plans and so on.

Test strategy scopeThe overall test strategy should cover the:

y Purpose, goals, and objectives of Service testing y Scope


Table of Contents


y Test process y Test metrics y Service Operation plan y Service Management plan y SPIs y Test approach y Criteria y People requirements y Environment requirements y Deliverables

After you have a test strategy in place and have laid down the testing policy, the next step is to actually design the test plan. To do this, a key element is the input you get from Service Design.

Input comes from the Service Package, which includes one or more SLPs and reusable components. SLP plays a very important role in test planning and design because it provides Utility and Warranty parameters based on the customer’s requirement, assets, and Patterns of Business Activity (PBAs).

service design InputAn SLP is an input to Service Design. This typically has information on the attributes of a Service. The attributes characterize the form and function of a Service. The Testing and Validation process


Table of Contents


checks if these attributes are providing the expected outcome. The Service Design inputs play a key role in choosing a Service Model, which you use to plan, design, implement, and test the Service.

service model PrincipleThe Service Model is an important concept that you need to apply for the successful execution of Service Validation and Testing. The Service Model enables you to:

y Define the structure or the overall design of a Service, such as the configuration of Service Assets.

y Describe the dynamics of the Service such as activities, Events, and instructions that help create value.

service structureThe structure of the Service depends on customer requirements. It defines the supporting Services and assets required as part of the final product. When you validate and test the new or changed Service, you will test it against these requirements and verify whether you have met the customer’s expectations.


Table of Contents


Contractual obligations

Copyrights, patents

and trademarks

Utility score (index)

Capability constraints

Standards and regulations

Other

constraints

Resource

constraints

Values and ethics

Warranty score (index)

Cost constraints

Solutions space

Adapted from design constraints of a service ©


GC


Table of Contents


service model usesYou can also use the Service Model to define the additional features of the Service. These may be in the form of interactions such as self-service menu options that help communicate and coordinate between Service users and Service agents and might vary depending on the business and demand of the customer.

When you validate and test the Service, you will refer to the SDP to map the constraints and customer requirements to the final product. The Service should completely map to the requirements when you make the final delivery to the customer.

Service Design defines the Service Model. It uses process maps, workflow diagrams, queuing models, and activity patterns to define the model. Service Transition evaluates these models and approves them for use. You can also use these models to develop test models and plans.

Test modelA test model includes a test plan and test scripts that define the testing approach to test each element, Release test conditions, predicted results, and test cycles. The details in the test model enable you to ensure that whenever you repeat the tests on a Service, you do it efficiently and effectively.

As a result, a test model should be well structured and enable you to:

y Trace elements to the requirements or design stage. y Audit tests.


Table of Contents


y Change and maintain test elements.

As you progress in the Service Design phase, you can use the updated Service Design and Release plan to define the specific requirements and validation and test conditions, cases, and mechanisms to be tested.

examples of Test models

“Test model Objective/target deliverable Test conditions based on

Service contract test model

To validate that the customer can use the service to deliver a value proposition.

Contract requirements. Fit for purpose, fit for User criteria.

Service requirements test model

To validate that the service provider can/has delivered the service required and expected by the customer

Service requirements and Service Acceptance Criteria.

Service level test model

To ensure that the service provider can deliver the service level requirements, and service level requirements can be met in the production environment, e.g. testing the response and fix time, availability, product delivery times, support services.

Service level requirements, SLA, OLA.


Table of Contents



Service test model

To ensure that the service provider is capable of delivering, operating and managing the new or changed service using the ‘as-designed’ service model that includes the resource model, cost model, integrated process model, capacity and performance model etc.

Service model.

Operations test model

To ensure that the Service Operations teams can operate and support the new or changed Service/service component including the service desk, IT operations, application management, technical management. It includes local IT support staff and business representatives responsible for IT service support and operations. There may be different models at different release/test levels, e.g. technology infrastructure, applications.

Service model, Service Operations standards, processes and plans.


Table of Contents



Deployment release test model

To verify that the deployment team, tools and procedures can deploy the release package into a target deployment group or environment within the estimated timeframe. To ensure that the release package contains all the service components required for deployment, e.g. by performing a configuration audit.

Release and deployment design and plan.

Deployment installation test model

To test that the deployment team, tools and procedures can install the release package into a target environment within the estimated timeframe.

Release and deployment design and plan.

Deployment verification test model

To test that a deployment has completed successfully and that all service assets and configurations are in place as planned and meet their quality criteria.

Tests and audits of ‘actual’ service assets and configurations.”



Table of Contents


Validation and Testing PerspectivesWhen you test and validate the Service, you must ensure that you coordinate with other team members and stakeholders for their feedback. The feedback and overall perspectives of the people involved in the implementation of the Service differs based on whether the person is using, delivering, managing, or operating the Service. This helps you focus on the key requirement areas and validate and test the Service efficiently.

To align the testing and validation phase with the different perspectives of various roles, the SDP defines the test entry and exit criteria:

y “Service Design – functional, management, and operational

y Technology design y Process design y Measurement design y Documentation y Skills and knowledge”



Table of Contents


Now, when you have to start the Service acceptance testing, you will first verify the Service requirements. The Service details are based on customer requirements. The customers, Service Providers, and other stakeholders sign-off the Service requirements, acceptance criteria, and Service acceptance test plan before you start building the Service. The stakeholders can be the business customer or customer representatives, users of the Service, suppliers, Service Providers, or Service Units.

Perspectives of roles in service ChangeNow, let us discuss why it is important to consider the perspective of all the roles involved in the implementation of the Service Change. To start with, let us discuss the importance of the perspectives of business users and customers.

Importance of PerspectivesThe perspectives of business users and customers are important to the success of the Service. They are important because they allow you to:

y Have a defined way of measuring the acceptability of the Service.

y Plan for the resources and level of expertise required to undertake Service acceptance.


Table of Contents


Perspective of service ProvidersFeedback from the Service Provider helps you:

y Be involved with the business prior to testing to avoid surprises during Service acceptance.

y Ensure the quality of the Service. This plays a key role in influencing the Business Units about the quality, reliability, and usability of the Service even before the Service goes live.

y Deliver and maintain robust acceptance test facilities per business requirements.

y Understand how the acceptance test fits into the business Service or product development testing activity.

Perspective of end users Within the Customer’s BusinessYou must conduct a user acceptance test (UAT) after building a Service. This is to ensure that the customer checks and verifies the Service before accepting it. You must test the Service in an environment that closely resembles the live operational environment. The testing helps you determine whether the Service is meeting the customer’s expectations.

It is necessary to define the testing details and scope in the user test and UAT plans, which the stakeholders should agree to at the start of the process.


Table of Contents


end usersThe end users within the customer’s business will:

y Test the functional requirements of the Service to ensure that it meets the end users’ expectations.

y Perform tests on Service Management activities, such as the ability to use the Service Desk, respond to diagnostic scripts, Incident Management, Request Fulfilment, and Change Request Management.

You must ensure that you set the expectations of the customers at the beginning of these tests. This is to avoid any early testing dissatisfaction. You must explain to the customers that this is just a test and that it is possible the Service will not perform as expected in all aspects.

Perspective of operations and service ImprovementThe operations staff must ensure that they deliver all the IT staff requirements to the customer before deployment. The feedback from the operations staff helps you:

y Set up technological facilities before delivering the new or changed Service.

y Provide the relevant staff skills, knowledge, and resources to support the Service after it goes live.

y Arrange for supporting processes and resources, such as Service Desk and second- or third-line support.

y Consider business and IT continuity. y Provide access to documentation and the SKMS.


Table of Contents


Application of Testing modelNow, after knowing the perspectives of the various roles involved in the Service implementation, you need to apply the appropriate testing model and thoroughly test the Service by considering the perspectives.

You must test all the components and assets of the Service separately using a specific test model. In addition, each of the components must have an associated acceptance test in addition to the overall acceptance criteria of the Service.

All the Service Models and associated Service deliverables are supported by their own reusable test model. You can use this test model during deployment and in future testing. The test model helps you ensure quality at an early stage instead of waiting for feedback at the end.


Table of Contents


Adapted from Exam

ple of service V-m

odel ©


GC

Define C

ustomer/

Business R

equirements

Validate Service P

ackages, O

fferings and contracts

Define S

ervice R

equirements

Service A

cceptanceTest

Service O

perational R

eadiness TestD

esign Service

Solution

Design S

erviceR

eleaseS

ervice Release

Package Test

Com

ponent and A

ssembly Test

Develop S

erviceS

olution

1a

2a

3a

4a

5a5b

4b

2b

1b

Service Com

ponentBuild and Test

Internal and external suppliers

Level 1

Level 2

Level 3

Level 4

Level 5

Levels of configuration and testing

Baseline point

Deliveries from

internal and external suppliers

Service R

eview C

riteria/Plan

• Contract, S

ervice Package, S

LP, SP

I

Service A

cceptance Criteria/P

lan

• SLR

• Draft S

LAS

ervice Operational C

riteria/Plan

• SD

P including:• S

ervice Model

• Capacity and resource plans

Service R

elease Test C

riteria and Plan

• Release D

esign• R

elease plan

BL

3b


Table of Contents


example of a Test modelThe Service V-Model helps you:

y Develop Service Validation and Testing early in the Service Lifecycle.

y Organize CI levels and their validation and testing activities across the Lifecycle stages.

y Map the types of tests to each development stage.

The Service V-Model gives an example of the way testing levels in Service Transition can be mapped to their corresponding stages of Service requirements and design.

In the Service V-Model: y The left side of the diagram represents the Service

requirements specification down to detailed Service Design.

y The right side of the diagram represents the validation activities you perform against the specifications defined on the left.

Each stage on the left has a corresponding activity on the right. As a result, you must start the Service validation and acceptance test planning with the definition of Service requirements. The customer who signs off the Service requirements will also sign off the Service acceptance criteria and test plan.


Table of Contents


design ConsiderationsService test design aims to develop test models and test cases that measure the correct things to establish whether the Service meets the customer’s requirements and if it is within the specified constraints.

It is important that you adopt a structured approach to design the tests. This will assist you to prioritize testing for the right things. You must ensure that the test models are well structured and repeatable to facilitate auditability and maintainability.

Consequently, some design considerations are applicable for Service test models, test cases, and test scripts. These include:

y “Business/Organization: o Alignment with business Services, processes and

procedures o Business dependencies, priorities, criticality and

Impact o Business cycles and seasonal variations o Business transaction levels o The numbers and types of users and anticipated

future growth o Possible requirements due to new facilities and

functionality o Business scenarios to test the end to end Service


Table of Contents


y Service architecture and performance: o Service Portfolio/structure of the Services, e.g.

core Service, supporting and underpinning supplier Services

o Options for testing different type of Service Assets, utilities and Warranty, e.g. availability, security, continuity

o Service level requirements and Service level targets o Service transaction levels o Constraints o Performance and volume predictions o Monitor, model, and measurement system that

explains the need and importance for the new or changed Service

y Service Release test environment requirements y Service Management:

o Service Management models, e.g. capacity, cost, performance models

o Service Operations model

o Service Support model

o Changes in requirements for Service Management information

o Changes in volumes of Service users and Transactions


Table of Contents


y Application information and data: o Validating that the application works with the

information/databases and technical infrastructure o Functionality testing to test the behavior of the

infrastructure solution and verify: i) no conflicts in versions of software, hardware or network components; and ii) common infrastructure Services used according to the design.

o Access rights set correctly. y Technical infrastructure:

o Physical Assets – do they meet their specifications? o Technical resource capacity, e.g. storage, processing

power, power, network bandwidth o Spares – are sufficient spares available or ordered

and scheduled for delivery? Are hardware/software settings recorded and correct?”


Aspects of designing service TestsSome of the aspects that you need to consider when designing Service tests are:

y Finance – you need to consider if the agreed budget is adequate and whether the expenditure had exceeded the budget.


Table of Contents


y Documentation – you need to consider and check if all the necessary documentation is available or scheduled for production, is it practicable, and is it in the correct format, such as checklists and Service Desk scripts.

y Supplier of the Service, Service Asset, and component – you need to consider the internal or external interfaces.

y Build – you need to consider whether the Service, Service Asset, or component be built into a Release Package and test environment.

y Testable – you need to consider if the Service is testable with the resources, time, and facilities available or obtainable.

y Traceability – you need to consider the type of traceability available back to the requirements.

y Time and place of testing – you need to consider an appropriate time and place to test. In addition, you must check if you require any unusual conditions under which you want to run and test a Service.

y Remediation – you need to consider plans to remediate or back out a Release through the environments.


Table of Contents


Issues during designing the management and maintenance of Test dataYou must consider the following relevant issues when designing the management and maintenance of test data:

y Separate test data from any live data, including the steps to ensure that test data is not mistaken for live data when being used and vice versa.

y Include data protection regulations that will help you in situations where you use live data to generate a test database.

y Back up test data and restore it to a known baseline to enable repeatable testing.

y Predict the volatility of test data, environments, processes, and procedures to build and tear down the test environment for various testing needs.

y Balance cost and benefit because test environments populated with relevant data are expensive to build and maintain. As a result, you must balance the benefits in terms of Risk reduction to business Services against the cost of provision.

You can use any of the following types of tests to verify that the Service meets user and customer requirements as well as Service Provider requirements for managing, operating, and supporting the Service.


Table of Contents


Nonfunctional TestsService testing can include many nonfunctional tests. You can conduct these tests at several test levels to help build confidence in the Service Release. These tests include:

y “Usability testing y Accessibility testing y Process and procedure testing y Knowledge transfer and competence testing y Performance, capacity and resilience testing y Volume, stress, load and scalability testing y Availability testing y Backup and recovery testing y Coherency testing y Compatibility testing y Documentation testing y Regulatory and compliance testing y Security testing y Logistics, deployability and migration testing y Coexistence and compatibility testing y Remediation, continuity and recovery testing y Configuration, build and installability testing y Operability and maintainability testing”



Table of Contents


Types of TestingThere are several types of testing from different perspectives:

y Service requirements and structure testing – you do this testing from the perspectives of Service Providers, users, and customers.

y Service level testing – you do this testing from the perspectives of Service level managers, operations managers, and customers.

y Warranty and assurance tests – you do this testing to check if the Service is fit for use.

y Usability – you do this testing from the perspectives of users and maintainers.

y Testing of contracts and regulations. y Testing of compliance. y Testing of Service Management. y Operational tests – you do this testing to check the

systems and Services. y Regression testing.




Table of Contents


3 Verify test planand test designs

Authorized R

FC (w

ith impact and resource

assessment) E

valuated design (SD

P, SA

C)

Service evaluation (E

2, En)

Test Managem

ent

2 Plan and

design tests4 P

repare testenvironm

ent5 P

erform tests

(see next fig)6 E

valuate exitcriteria and report

7 Test clean upand closure

Revise tests to deliver required results

Adapted from

example of a validation and testing process

© C

rown C


OG

C


Table of Contents


Activities of the Testing ProcessAs shown in the diagram, several activities are involved in the testing process. However, you do not perform these activities in sequence; you might perform them in parallel. For example, you can start testing even before completing the test design.

The important activities in the testing process are: y Validation and test management: In this sequence of

activities, you: o Plan, control, and report activities through the test

stages of Service Transition. o Manage issues, mitigate Risks, and implement the

Changes identified from the testing activities. These Changes can delay the implementation and create dependencies that you must manage.

y Plan and design test: You plan and design in the early Service Lifecycle phases. To plan and design, you need to:

o Plan resources such as hardware, networking, and staff.

o Identify business and customer requirements, such as raw material.

o Plan for supporting Services and their support features, such as access and security.

o Create schedules and get approval for them. o Define the timelines and place for Service Delivery. o Define financial requirements.


Table of Contents


y Verify the test plan and test design by: o Ensuring that the test model delivers appropriate test

coverage for the Risk profile of the Service. o Ensuring that the test model covers the key integration

aspects and interfaces. o Ensuring that the test scripts are accurate and

complete. y Prepare the test environment: You must define the design

plan of the initial test environment. You can prepare the test environments by using the:

o Services of the build and test environment resource. o Release and Deployment processes.

y Perform tests: In this activity, you need to: o Use manual or automated techniques and procedures

to perform the tests. o Record the results of the tests. Even if a test fails,

you must document the result along with the reason for the failure.

o Follow the test plan and scripts for testing, whenever possible.

o Resolve and document the Incident or issue when a part of the test fails. The person who is testing that part of the Service should resolve the issue and test it again.


Table of Contents


y Evaluate exit criteria and exit report: When you evaluate the exit criteria and report, you need to:

o Compare the predicted results to the actual results. o Interpret the results in terms of pass/fail, Risk to the

business, Risk to the Service Provider, or Change in expected cost.

o Collate the test metrics and summarize the results of the tests.

o Evaluate the exit criteria based on the performance of the Service and client feedback. The Service must meet the customer’s technology and quality requirements.

o Ensure that Configuration Baselines have been recorded in the CMS.

y Perform test clean-up and closure: In this activity, you need to:

o Clean or initialize the test environments. o Identify improvements that can be input to design,

build, and decision parameters or future testing policies and procedures.


Table of Contents


Adapted from example of perform test activities © Crown Copyright 2007 Reproduced under licence from OGC

Testmanagement

SKMS/CMS

StartSDP – Portfolios,

Models,Architecture, SAC

Test Strategy Test standards Re-useabletest models

Prepare test model

Perform tests and record

results

Incident/Issue/risk

Resolve incidents/issues and

mitigate risks

Exit criteria met?

End

CMS

Issue/ RiskManagement

Incident andproblem

Management

Change andconfigurationmanagement

No

No

Yes

Yes


Table of Contents


Validation and Test management

The activities in Validation and Test Management also include the following subactivities:

y Plan test resources. y Prioritize and schedule what is to be tested and when. y Manage Incidents, Problems, errors, nonconformance,

Risks, and issues. y Process and document incoming Known Errors. y Monitor progress and collate feedback from validation and

test activities. y Manage Incidents, Problems, errors, nonconformance,

Risks, and issues during transition. y Implement Changes to reduce errors going into

production. y Record the Configuration Baseline. y Collect, analyze, report, and manage test metrics.

Test metricsYou must use test metrics to:

y Measure the test process and manage and control the testing activities.

y Determine the progress of testing, the earned value, and the outstanding testing. The test manager uses this data to estimate the duration of the testing.

y Help the management prioritize, schedule, and manage Risk.


Table of Contents


y Provide information to estimate and schedule future Releases.

output of the Perform Tests ActivityThe output of the testing process includes:

y Reports with details of testing along with cross-references to the test model, test cycles, and conditions.

y Data on Problems, errors, issues, nonconformances, and Risks that you have to resolve.

y Data for resolved Problems, Known Errors, and related Changes.

y A sign-off document.

guidelines to Prepare the Test environmentUse Service Management best practices to actively maintain and protect test environments. For significant Changes, you should consider updating the test data.

3.6.5 TrIggers, INPuTs, ouTPuTs, ANd INTer-ProCess INTerfACesA C T I V I T y I N W o r K B o o K

TriggersThe triggers for the testing phase are scheduled activities on a:

y Release plan y Test plan


Table of Contents


y Quality assurance plan

InputsThe inputs for the process include:

y The Service Package: It consists of a core Service Package and reusable components, that is, supporting Services. It also defines Utilities and Warranties for the delivered Services. You can use the Service Package to map the requirements to the SLP.

y SLP: An SLP plays an important role in test planning and design because it provides Utility and Warranty based on the customer’s requirements, assets, and PBAs.

y Service Provider interface definitions: They define the process interfaces and organizational interfaces that you can use to test the Service efficiently.

y SDP: It defines the customer requirements for the Service along with the Service Model and Service Operations plan. It includes:

o Operation models, support resources, escalation procedures, and critical situation-handling procedures.

o Capacity/resource model and plans along with performance and availability aspects.

o Financial/economic/cost models with Total Cost of Ownership (TCO) and Total Cost of Utilization (TCU).

o Service Management model, for example, an integrated process model as in ISO/IEC 20000.


Table of Contents


o Design and interface specifications. y Release and Deployment plans: They define the order in

which you need deploy, build, and install Release Units. y Acceptance criteria: It consists of specific requirements for

testing at all levels. y RFCs: They are Requests for a new Service or a Change

in an existing Service.

outputsThe output from the process is the test report that you need to forward to the Service Evaluation team. This report includes all the information relevant to the testing phase, such as details of the testing environment and test results.

Based on the outputs, you can evaluate the Service only after a specific duration of the Service going live. At that time, you can compare the predicted performance to the actual performance of the Service. If the Service is functioning as expected, the evaluation is successful. You then send a report to Change Management along with a suggestion to remove the ELS from the Service and make it a normal operation.

A test report includes: y The base configuration structure of the testing

environment.


Table of Contents


y Details of the tests along with the requirements and constraints.

y Test results. y The analysis of the results, for example, a comparison of

the actual performance with the expected performance and a report of the Risks identified during the testing phase.

y The updated data and other information that is to be added to the SKMS, for example, errors and Workarounds, testing techniques, and analysis methods.

y The test’s Incident, Problem, and error records. y Data or suggestions to improve the testing process or the

Service Design output documentation process. y Information on customers, suppliers, partners, and

stakeholders.

Inter-Process InterfacesThe Service Validation and Testing process supports all the steps of the Release and Deployment phase in Service Transition. You align the testing strategy to work with all other Lifecycle stages to improve the quality of the Service. Some of these interfaces are:

y service design: This interface ensures that you can test the design. For example, you can test the hardware and software, Service elements that you reuse, third-party access rights, or delivered Service elements.


Table of Contents


y Continual service Improvement (CsI): This interface ensures that you work continuously to improve the Service and test plans.

y service operation: This interface uses maintenance tests to ensure that Services are effective. You will need to maintain these tests to handle innovation and environmental Changes.

y service strategy: This interface ensures that you test the Services within the specified cost and time using limited resources.

3.6.6 KPIs ANd meTrICsA C T I V I T y I N W o r K B o o K

KPIs and metricsKPIs and metrics help you measure the effectiveness and efficiency of the process. KPIs in the Service Validation and Testing process help you analyze the effectiveness of testing.

Now that we have seen the KPIs used in your organization, let us understand how KPIs help you analyze validation and testing reports to identify trends.

Analyze Validation and Testing reports Primary and secondary KPIs are applicable to Service Validation and Testing, as follows:

y The primary KPIs include the indicators that you can use


Table of Contents


to judge the effectiveness of testing in delivering Services that affect the business of the organization.

y The secondary KPIs include KPIs to measure the effectiveness and efficiency of the testing process.

KPIs Applicable to service Validation and TestingThe primary KPIs applicable to Service Validation and Testing are:

y Validate the Service early to correct it in case of any discrepancies.

y Reduce Incidents and errors that contribute to new Service Transitions after deployment.

y Interact more efficiently with customers and Business Units.

y Reduce delays in testing to avoid affecting the business adversely.

y Understand the new or changed Service. y Allocate roles and responsibilities to customers, users, and

Service Providers when implementing a Service Change. y Sign-off on cost, effort, and user or customer

requirements, for example, at the time of user acceptance testing.


Table of Contents


other Primary KPIsIn addition to the primary KPIs given above, there are other primary KPIs to measure the economic effectiveness of the testing process. These KPIs include:

y “Test planning, preparation, and execution rates y Incident, Problem, and Event rates y Issue and Risk rate y Problem resolution rate y Resolution effectiveness rate y Stage containment – analysis by Service Lifecycle stage y Repair effort percentage y Problems and Changes by Service Asset or CI type y Late Changes by Service Lifecycle stage y Inspection effectiveness percentage y Residual Risk percentage y Inspection and testing return on investment (ROI) y Cost of unplanned and unbudgeted overtime to the

business y Cost of fixing errors in live operation compared to fixing

errors early in the Lifecycle. y Operational cost improvements associated with reducing

errors in new or changed Services.”



Table of Contents


secondary KPIsThe secondary KPIs for measuring the testing function and process are:

y “Control effort and cost to set up a testing environment y Minimize effort required to find defects, that is the number

of defects compared with testing resources applied y Reduction of repeat errors. Feedback from testing ensures

that corrective action within design and transition (through CSI) prevents mistakes repetition in subsequent Releases or Services.

y Reduce error/defect rate in later testing stages or production

y Re-use of testing data y Percentage Incidents linked to errors detected during

testing and Released into live y Percentage errors at each Lifecycle stage y Number and percentage of errors that could have been

discovered in testing y Testing Incidents found as percentage of Incidents

occurring in live operations y Percentage of faults found in earlier assessment stages,

since there is always an increase in the remedial costs in later stages of transition

y Number of Known Errors documented in earlier testing phases”



Table of Contents


Testing measures the ability of a Service to perform as required in a simulated or actual environment and focuses on measurement. You must ensure that you separate the measures related to the testing process from the errors introduced into Services and systems. The main aim of testing is to deliver Services that are beneficial and reduce the chances of failure. You must be careful in identifying errors during the testing phase because rectifying errors after deployment involves more effort and cost.

3.7 eVALuATIoN ProCessoverviewEvaluation is a process that supplements Change Management by evaluating whether a Change to a Service provides the desired results, for example, performance is acceptable, it provides value for money, and so on.

3.7.1 PurPose, goALs, ANd oBjeCTIVePurpose:The purpose of Service Evaluation is to provide a consistent and standardized method to determine the performance of a Service Change by comparing existing and proposed Services. The process assesses the actual performance of a Change against the predicted performance of the proposed Change. After the assessment, the process then records or manages deviations, if any.


Table of Contents


goals:The goals of Service Evaluation are:

y Define stakeholder expectations correctly. y Provide accurate information to the Change Management

team. y Ensure that you do not implement Changes that adversely

affect Services and introduce Risks.

objective:The objective of this process is to analyze all the intended and unintended effects of a Service Change and provide quality outputs. This assists Change Management in approving the Service Change. Service Evaluation reviews and judges whether the performance of a Service Change is acceptable.

3.7.2 sCoPe ANd VALue To The BusINessscopeThe scope of Service Evaluation includes:

y Evaluating the new or changed Services that Service Design defined during deployment and before the final transition to Service Operation.

y Comparing the actual performance of the Service with respect to the proposed performance. This helps keep realistic expectations.


Table of Contents


role of service evaluationService Evaluation plays a key role in providing useful information to Service Providers to:

y Help ensure that expectations set are realistic. y Check if the performance of a Service meets expected

standards.

Value to BusinessThe Service Evaluation process can improve business value by establishing the use made of resources in terms of delivered benefit. This information will focus more on the value of future Service development and Change Management. This process also helps the CSI stage of the Service Lifecycle analyze future improvements to the Change process and predict and measure Service Change performance.


Policies of the service evaluation ProcessThe policies that apply to the Service Evaluation process are:

y Evaluate Service Designs or Service Changes before transitioning them.

y Ensure that the customer or customer representative manages any deviation between the predicted and actual


Table of Contents


performance by accepting the Change although the actual performance differs from the predicted performance, rejecting the Change, or requiring the implementation of a new Change with a revised, predicted performance agreed in advance. The customer or customer representative is not allowed other outcomes of evaluation.

y Do not perform an evaluation without a customer engagement package.

Principles of the service evaluation ProcessThe principles that guide the Service Evaluation process are:

y The intended and unintended effects of a Change should be identified and their consequences understood and considered.

y A Service Change should be evaluated fairly, consistently, openly, and objectively.

Service Evaluation uses the Plan–Do–Check–Act (PDCA) model to ensure consistency across all evaluations.

3.7.4 ProCess ACTIVITIes, meThods, ANd TeChNIQuesA C T I V I T y I N W o r K B o o K


Table of Contents


Test PlanIn a test plan, you can:

y Define the scope of the test plan and the process to perform the test.

y Define where to store the results of the test. The results will reflect the actual performance after implementing the Change.

y Define the approving authority. y Define a plan to stabilize the Service. y Include the qualification and validation plan to handle

situations when the Change is affecting any other Service.

evaluation report ContentsThe evaluation report contains:

y Risk profile: Includes the residual Risk left after implementing a Change and after applying countermeasures.

y Deviations report: States the difference between predicted and actual performance after implementing a Change.

y Qualification statement: States whether the Change has affected the Service in a way that cannot be qualified. It follows the review of qualification test results and the qualification plan.


Table of Contents


y Validation statement: States whether the Change has affected the Service in a way that cannot be validated. It follows the review of validation test results and the validation plan.

y Recommendation: Includes a suggestion to the Change Management team by the Service Evaluation team to approve or reject the Change.

Change effectsThe intended effects of a Change are often beneficial. On the other hand, unintended effects are difficult to predict and measure and are not beneficial to the business. You must analyze the Service Change, customer requirements, and SDP in detail to understand the proposed effect of any Change.

The Change document should clearly define the intended effect of the Change and the plan to implement the Change effectively. If it is unclear, you must stop the Service Evaluation process and send a proposal to the Change Management team for this.

You may also come across Changes that might have associated adverse effects on Services. For example, when you implement SOX-compliant procedures, they provide legal compliance benefits but have adverse effects on efforts and costs.

At times, Service Changes might also lead to unintended effects. You can understand the Impact of these effects if you provide the complete details of the Service Change and discuss them with the stakeholders, users, management, and financers.


Table of Contents



evaluating ChangeYou must evaluate the Change from different perspectives to understand the intended and unintended effects of a Change accurately. Each organization wants the intended effect to be beneficial. Consequently, the intended effect should always match the acceptance criteria.

On the other hand, unintended effects are often not beneficial. Sometimes, they might have an adverse effect on other Services, users, and network traffic. You cannot measure the unintended effects and might not even see these effects until the pilot stage, during production, or after implementation.

3.7.5 TrIggers, INPuTs, ANd ouTPuTA C T I V I T y I N W o r K B o o K

TriggersService Evaluation is triggered by the following factors:

y “Evaluation request from Service Transition manager or Change Management

y Activity on Project Plan”



Table of Contents


InputsThe key inputs for this process are:

y “Service Package y SDP and SAC y Test results and report”


outputThe output of this process is the evaluation report that you generate for Change Management.

3.7.6 KPIs ANd meTrICsKPIs and metricsKPIs and metrics help you measure the effectiveness and efficiency of the process. In Service Evaluation, KPIs help you minimize Service Incidents and failed designs.


service evaluation KPIsNow that we have seen the KPIs used in your organization, let us understand the Service Evaluation KPIs.

Service Evaluation KPIs are of the following types: y “Customer/business KPIs:

o Variance from Service performance required by customers (minimal and reducing)


Table of Contents


o Number of Incidents against the Service (low and reducing)

y Internal KPIs include: o Number of failed designs that have been transitioned

(zero) o Cycle time to perform an evaluation (low and

reducing)”


3.8 KNoWLedge mANAgemeNToverviewEach organization strives to deliver a quality Service or process. However, you can achieve this only if you have complete knowledge of the Service or process. You also need to ensure that you share your knowledge with other staff and customers to help resolve Incidents and errors promptly and efficiently. This requires you to capture and store important data systematically. You can retrieve and analyze this data to gain knowledge and wisdom, which enables you to take informed decisions and improve Service quality. This set of activities, in which you capture, store, and reuse data and information, is known as Knowledge Management.

Knowledge, in the context of Service Transition, includes stakeholder identity, Risks, expected performance levels, resource details, and schedules. The quality and importance of knowledge depends on the accessibility, quality, and method of


Table of Contents


continuously updating the knowledge source and data for staff.

Knowledge Management is a process that you use through the entire Service Lifecycle. It is not only critical during the transition stage but also influences and supports other stages. It involves activities to make data and information easily available and accessible. Each stage of the Service Lifecycle captures and stores data for easy retrieval, when required.

3.8.1 PurPose, goALs, ANd oBjeCTIVesPurposeThe purpose of Knowledge Management is to store information systematically so that the right people can retrieve it at the right time. With Knowledge Management, knowledge remains inside the system and the organization utilizes it to take informed decisions to improve Service quality.

goalsThe goals of Knowledge Management are:

y Provide reliable and accurate information throughout the Service Lifecycle.

y Ensure that your organization delivers quality. y Improve decision-making skills.


Table of Contents


objectivesThe objectives of Knowledge Management are:

y Improve the Service Provider’s efficiency and quality of Service, increase user satisfaction, and reduce Service costs.

y Improve the staff’s knowledge of the Service, enabling them to understand the benefits and use of the Service.

y Ensure that the Service Providers have clear and adequate knowledge of the:

o Users of the Service o Utilization of the Service o Service Delivery constraints o Customer’s difficulty in realizing the benefits expected

from the Service

3.8.2 sCoPe ANd VALue To The BusINessscope of Knowledge managementKnowledge Management covers the complete Service Lifecycle. You use Knowledge Management in all phases of the Lifecycle and at every stage. As a result, you can say that the scope of Knowledge Management extends to the management of knowledge and the information and data captured at each stage of the Service Lifecycle from which knowledge is created.


Table of Contents


The Knowledge Management process excludes the capture, maintenance, and use of asset and configuration data, which is dealt with in SACM.

Organizations frequently use Knowledge Management in the Service Transition phase of the Lifecycle.

examples Where successful Transition depends on Knowledge management

y A clear understanding of the new or changed Service among the users, Service Desk, support staff, and suppliers, including knowledge of errors signed off before deployment, to facilitate their roles within that Service.

y Knowledge of the use of the Service and the reason for discontinuing earlier versions of the Service.

y Definition of acceptable Risk and confidence levels associated with Service Transition, for example, measuring and acting appropriately on testing results.


Table of Contents


Implementing servicesIn Service Transition, you can use Knowledge Management to assist in the successful implementation of Services. To do this, you can:

y Introduce and apply new approaches to control and manage knowledge during Service Transition.

y Improve knowledge transfer, which helps in effective Service Transition.

y Train stakeholders on new or changed Services. y Record and document the errors, faults, and Workarounds

detected during Service Transition. y Capture details during the implementation and testing

phase. y Refer to existing documentation on Service development,

testing, and training. y Conform to legislative requirements, such as SOX, and

standards such as ISO 9000 and ISO/IEC 20000. y Help in decision-making on sharing information with the

management.



Table of Contents


Information

Knowledge

Wisdom

Who, w

hat,w

hen, where?

How

?

Why?

Context

data

Understanding

Adapted from The flow

from data to w

isdom ©


GC


Table of Contents


dIKW modelYou can use the Data–to–Information–to–Knowledge–to–Wisdom (DIKW) structure to explain Knowledge Management. In the DIKW informational hierarchy, each layer adds some attributes over the previous one.

y Data: “Data is a set of discrete facts about Events” (Source: Service Transition book). Most organizations have databases or Service Management and Configuration Management tools/systems to store data in a structured format. Knowledge Management helps you record accurate data, analyze, synthesize, and transform data into information, and identify and collate relevant data and the corresponding resources.

y Information: It provides context to the data. Information is mostly stored in semi-structured formats in documents, e-mail, and multimedia elements. Knowledge Management enables you to manage information efficiently to ensure that relevant information is captured, easily accessible, and reusable. This helps you prevent mistakes or duplicate work.


Table of Contents


y Knowledge: It is context based and composed of the experiences, ideas, and insights of individuals and the analysis results of data and information. Knowledge is dynamic, and you can create new knowledge by synthesizing existing knowledge. Knowledge Management enables you to transform knowledge into a reusable format and use it as input to enhance decision-making processes in organizations.

y Wisdom: It is your final judgment, which you create using your knowledge and experiences. It deals with the future, and you can apply this wisdom to deal with your day-to-day operations.


Table of Contents


Configuration

Managem

ent Databases

Decisions

Service Know

ledge Managem

ent System

Configuration M

anagement System

Adopted from relationship of the Cm

dB,the Cms and the sKm

s ©


GC


Table of Contents


service Knowledge management systemThe SKMS deals with managing knowledge in an organization. It is a central, logical repository or Configuration Management System (CMS) and Configuration Management Database (CMDB) that stores the data and knowledge of all the people in an organization. An SKMS also includes:

y Staff experience y Details of user numbers, behavior, and organizational

performance figures y Supplier and partner requirements, abilities, and

expectations y Usual and expected user skill levels


3.8.4 ProCess ACTIVITIes, meThods, ANd TeChNIQuesKnowledge management strategyYou should use an overall strategy for Knowledge Management. The strategy should fit within the overall organizational environment. Each organization has a unique environment with a different purpose, culture, size, skills, and experience. Consequently, each organization will have a different set of needs and issues that you need to address using a Knowledge Management strategy. This strategy must aim to address the real needs and issues of the organization.


Table of Contents


You should establish Knowledge Management within Service Transition or within IT Service Management (ITSM) if your organization lacks this approach. However, ensure that the Knowledge Management you establish covers IT staff, users, third-party support, and others who are likely to contribute or benefit from this knowledge pool.

Activities of a Knowledge management strategyA Knowledge Management strategy must address:

y Planned organizational Changes, such as changes in roles and responsibilities

y Plans to establish roles and responsibilities and changes in funds

y Policies, processes, procedures, and methods related to Knowledge Management

y Technology and other resource requirements y E-measures of performance y The governance model

Identifying Information and data One of the Knowledge Management strategies is knowledge identification, capture, and maintenance. You can use this strategy to identify information and data that can be included as part of a relevant knowledge pool. To do this, you must:

y Identify the knowledge in your organization that will be useful.


Table of Contents


y Implement a systematic process that organizes and manages information that improves staff skills.

y Collate all the information and knowledge using processes and workflows.

y Generate new knowledge using existing knowledge and experiences.

y Use and capture information and knowledge acquired from external sources, such as databases, Web sites, employees, suppliers, and partners.

Knowledge TransferNow, after collecting and storing all the relevant knowledge, how will your staff access this vast knowledge pool in your organization?

You must plan strategically to ensure that the relevant people can retrieve, share, and utilize the knowledge pool. For your staff to access the knowledge, you must allow knowledge transfer at specific stages of the Service Lifecycle. This helps implement Services efficiently.

However, it is a challenge to transfer knowledge from one part of the organization to another. This complex and important activity is important because you want a department to access and use the knowledge of another department of the organization. The knowledge must be easy to use. You can observe the knowledge transfer by monitoring the change in performance brought about by knowledge at individual or unit level.


Table of Contents


You should conduct a gap analysis of the knowledge within your organization by interviewing the staff. You should correlate their responsibilities to their observed knowledge to fill gaps, if any. This is a difficult task and, consequently, you must deploy skilled and experienced staff to complete it. The result of the gap analysis forms the basis for improving the knowledge transfer.

The traditional method of transferring knowledge was through classroom training and documents. In addition, in most cases, you impart training to a representative of a department, and this person then passes on the knowledge to other team members.

Techniques of Knowledge TransferYou can also use other, appropriate techniques to transfer knowledge. Some of the techniques you can consider when transferring knowledge are:

y Learning styles: Each person learns in different ways, and you must ensure that you use the most suited method to transfer knowledge. For example, some people might want hands-on experience for learning while some might learn better with simulations and under supervision. The learning styles might vary based on the age, culture, attitude, and personality of learners. IT staff must ensure that they consider these points when sharing knowledge with other departments, such as graphic designers, sales team, and performers.


Table of Contents


y Knowledge visualization: You can use diagrams, images, photographs, and storyboards to improve knowledge transfer. This helps you focus on actual learning based on the experiences, attitudes, expectations, perspectives, and values of staff members. You can also use animations to enhance the knowledge transfer. For example, you can use animations to explain a change in hardware location even when there is no change in functionality.

y driving behavior: Knowledge transfer helps you ensure that the staff is able to deliver in all situations and under pressure. You can implement some procedures for the team to follow to ensure consistency and for the required escalations. These procedures also enable you to identity their appropriateness and determine deviations, if any. Some examples of such procedures are Change process models and Service Desk scripts.

y seminars, Webinars, and advertising: You can share knowledge by conducting seminars. These formal gatherings can enhance and improve knowledge with multiple people providing valuable inputs. You can also use Webinars or Internet or intranet portals to share knowledge. In addition, you can retain this information online for subsequent use. Advertising helps you share knowledge in an interesting way. People will look at these advertisements on Services or processes and try to implement them at their workplace.


Table of Contents


y journals and newsletters: You must establish regular communication channels between departments and locations. This helps in knowledge transfer in smaller chunks, which is easier to retain and absorb. You can design these journals and newsletters to target specific teams or make them globally acceptable and distribute them at periodic intervals to share knowledge and information.

example of Importance of Knowledge TransferKnowledge transfer is essential for all teams in an organization.

example of the Importance of Knowledge TransferFor example, the Service Desk must have the required knowledge and understanding during the transition of any Service into support. The support team will rely on the Release Management team for information on Known Errors. In addition, this team will check with the technical support team for Known Error scripts. The support team will also need to maintain and use information from HR, facilities, and other supporting Services.


Table of Contents


steps to ensure effective data and Information managementThere are a number of key steps to ensure effective Data and Information Management.

step 1The first step is to consider how data is to be used. Knowledge is based on underlying data and information. To manage knowledge well, you need to know how to use the data and information. For this, you must know:

y The type of knowledge necessary for decision-making. y The type of external and internal conditions you need to

monitor. The conditions can range from end-user demand to legal requirements to weather forecasts.

y The type of data or information you want to capture and store in the database and the type that you want to reject.

y The expense involved in capturing and managing data and the benefits this will bring to your organization. You must also consider the negative Impact the data overload might have on knowledge transfer.

y Policies, legislations, standards, and other requirements. y Intellectual property rights and copyright issues.


Table of Contents


step 2After understanding how to use data and information for Knowledge Management, you must be clear about your expectations from successful Data and Information Management. It will deliver:

y Conformance with legal and other requirements, for example, company policy and codes of professional conduct.

y Defined forms of data and information that an organization can easily use.

y Current, complete, and valid data and information. y Data and information that you can dispose of, as required. y The capability to share information and data with people,

when required.

step 3The third step is to establish data and information requirements. To do this, you must plan and implement the Data and Information Management process according to the policies and procedures of your organization. Often, data is collected without clear understanding of how it will be used. This might eventually lead to unnecessary costs to the organization. You must consider some key points to establish data and information requirements. Some of these points are:

y Understand and document the type of data and information you need along with reasons to store this data, for example, technical, project, organizational, Service Management process based, agreements, operations,


Table of Contents


or any other information. You must understand that it is expensive to collect and maintain data, and you must collect it only when required.

y Use consistent and common formats to enhance an understanding of content.

y Define data protection, privacy, security, ownership, agreement restrictions, rights of access, intellectual property, and patent requirements with the stakeholders.

y Define access rights to data and information and the importance of these access rights at different times. For example, it will be more important and appropriate if you access payroll information just the day before the monthly payroll rather than on any other day.

y Make any Changes to Knowledge Management by following Change Management.

step 4Step 4 involves defining an appropriate information architecture. You do this to manage data and deliver the relevant information to everybody. The key steps to define the information architecture are:

y Create and update a Service Management information model that helps you deliver information in a flexible, cost-effective, and timely manner.

y Define systems that enhance information sharing and maintain the integrity of data and information.


Table of Contents


y Adopt existing, globally accepted data classification schemes that can be changed according to Service Management needs. In the absence of existing schemes, design a data-classification scheme that you can use for the Service Management organization.

Procedures and requirementsEach organization also has to define Data and Information Management procedures for the efficient functioning of Knowledge Management. Some of the key points that you should consider when setting up these procedures and requirements are:

y Identify the Service Lifecycle data and information that you need to collect.

y Define procedures to maintain the data and information and share it with others who need them.

y Store and retrieve data and information. y Allocate roles and responsibilities for the information you

require from other teams. y Define access rights and authority to manage and

maintain the data and information. In addition, manage the information’s security, integrity, and consistency.

y Define a proper backup and recovery system for the data and information. This should include the re-establishment of the ability to use the knowledge, not just re-establish the database.


Table of Contents


y Define requirements to review with the changing demands of the technology, organizations, policies, and security.

y Define a system to deal with the collection and retention of data and information.

Performance ImprovementAn organization can use these defined procedures to enhance its performance. The organization can:

y Define a system to capture, store, and retrieve data from relevant sources.

y Manage the storage and movement of data and information according to the organization’s legislation.

y Archive information in accordance with the Data and Information Management plan and organizational policy.


Table of Contents


Adapted from service know

ledge managem

ent system©


GC

Portal

IT governance

Service PortfolioReports

ContinualIm

provement

Risks and Issues

Quality

managem

ent ViewPolicies, Processes,Procedures, form

s,tem

plates, checklists

services ViewDashboard Service Catalogue, Utilities and W

arranties, Service Bundles/

Packages, Service Reports

Asset andConfiguration

ViewFinancial Asset

CMS inform

ationStatus Reports CM

DB data Definitive Sources

self service ViewService and

Product CatalogueContacts, FAQ

s My

assets – Procurement,

Install, Move, Add,

Change processingand m

onitoring

Knowledge

Processing Layer

data and Information

sources and Tools

Query and

Analysisreporting

Performance m

anagement

Forecasting, Planning, Budgeting m

odellingm

onitoring Scorecards, Dashboards

Alerting

Comm

on Process, Dataand Inform

ation Model

Schema

Mapping

Meta Data

Managem

entData

reconciliationData

synchronizationExtract,

Transform, Load

Mining

Application,system

andInfrastructurem

anagement

Event andAlert M

anagement

Legacysystem

s


Access Managem

entHum

an ResourcesSupply ChainM

anagement

Customer Relationship

Managem

entstructured

Document

StoreDB

definitive media

LibrarySoftware Docum

entationM

ulti-media

CMDB2


service desk andsupport View

Service Catalogue,Custom

ers, Users,Stakeholders, AssetsIncidents, Problem

s,Changes, Releases,

ConfigurationsPerform

ancePresentation

LayerLearning andTraining View

CMDB

CMDB1

unstructured

File Store

data Integration

service Knowledge

managem

ent Base

Information

Integration Layer


Table of Contents


Implementing an sKmsYou must have appropriate knowledge sharing in place to provide Services to customers across time zones, work cycles, and geographies. As a result, you must establish an SKMS that can be shared, updated, and used by its operating entities, partners, and customers.

Implementing an SKMS helps reduce the maintenance and management costs of Services. It also increases the efficiency of operational management procedures and reduces the Risks that arise from a lack of proper mechanisms. You must also align all the training and knowledge-related material with the business perspective. You can include the following materials:

y The terminology used in business language and how the IT terminology is translated.

y The business processes and where they are underlaid by IT.

y Any SLAs and supporting agreements and contracts that would change because of the new Service Transition. This is especially important for the Service Desk analysts whose target for supporting transition is to sustain Service. If the classifications are accurate, this will facilitate the entire process.

For the Service Transition team to acquire knowledge of the Service, they must spend time with the development team, test some processes, or be at the receiving end of the Service Transition to understand the business perspective.


Table of Contents



3.8.5 INTer-ProCess INTerfACesA C T I V I T y I N W o r K B o o K

It is important for Knowledge Management to ensure that you understand and accept its benefits within the entire organization. Effective Knowledge Management depends on the committed support and delivery of those working in and around ITSM.

Interfaces with other ProcessesKnowledge Management interfaces with other stages of the Service Lifecycle in the following ways:

y Service Operations: Knowledge Management records and analyzes all the errors detected during transition. This knowledge, along with that of error existence, its consequences, and its Workarounds, is made available to Service Operations in an easy-to-use fashion. The staff involved in effective interface between Knowledge Management and Service Operations are:

o Operations staff: The front-line Incident Management staff, the Service Desk, and the second-line support team capture the everyday ITSM data. If they do not capture the data and understand their responsibilities, Knowledge Management will not be effective. In most organizations, support analysts are reluctant to record their actions fully because they


Table of Contents


feel that this can undermine their position within the organization by resolving issues without them. The key to successful Knowledge Management is to change their attitude to appreciate the benefits of this process to individuals and the organization.

o Problem Management staff: These employees will be the key users of the collected knowledge. In addition, they are responsible for the normalization of data capture by developing and maintaining scripts that support data capture within Incident Management.

o Service Transition staff: These employees capture the relevant data throughout the Lifecycle phases. Consequently, they must collect it accurately and completely. Service Transition staff capture data and information that is:

� “Relevant to adaptability and accessibility of the Service as designed, to be fed back, via CSI, to Service Design

� ‘Course corrections’ and other adaptations to the design required during transition. Awareness and understanding of these will make subsequent transitions easier.”



Table of Contents


3.8.6 KPIs ANd meTrICsKPIs and metricsKPIs and metrics help you measure the effectiveness and efficiency of the process. KPIs in the Knowledge Management process help you store and share data and knowledge effectively and accurately.


Now that we have seen the KPIs used in your organization, let us understand the Knowledge Management KPIs.

Knowledge management KPIsYou might not be able to measure the value of knowledge; however, you must analyze and measure how much better the organization is faring because of Knowledge Management. This is important because it justifies the expenditure involved in supporting Knowledge Management.

To measure the value of Knowledge Management, you can have different parameters according to the perspective of the business, customer, or Service Provider.


Table of Contents


Influences of Knowledge managementLet us now look at how Knowledge Management influences business and satisfies customers. Good Knowledge Management:

y Reduces the “user error” category because of the targeted knowledge transfer. It also reduces training costs in an organization.

y Reduces Incidents, Problems, and errors, effectively reducing resolution time because of targeted training and available information on appropriate Workarounds.

y Improves customer experience by resolving queries quickly and without any additional support.

y Minimizes the transition time of the Services and reduces the duration of providing ELS.


Table of Contents


Before

After

100

90807060504030201000

Impact of B

etter Know

ledge Transfer

Adopted from Contribution of know

ledge to effectiveness of support staff ©


GC


Table of Contents


Analyzing the Value of Improved Knowledge Transfer and Its BenefitsYou can determine the value of improved knowledge transfer and the benefit it had for the staff by analyzing the:

y “Incidents and lost time categorized as ‘lack of user knowledge’

y Average diagnosis and repair time for faults fixed in-house y Incidents related to new or Changed Services fixed with

the help of knowledge base”


Knowledge Management might not be totally responsible for the improvement of these attributes, but good Knowledge Management should influence trends in these areas.

The performance of the support team after the transition determines the quality of the knowledge transfer. A more proactive method is to get feedback from your team after the training to check their understanding. You can do this with the help of questionnaires or tests.

Now, let us discuss how to evaluate the effectiveness of good Knowledge Management on Service Providers.


Table of Contents


effectiveness of Knowledge managementYou can judge the effectiveness of Knowledge Management by checking the:

y Usage of the knowledge base, which you can measure by verifying the number of accesses to the SKMS and the average time taken to find the relevant information.

y Errors reported by the staff or detected during audit. If no errors are reported, it implies that no one used Knowledge Management.

y Staff involvement in discussion forums to provide and share knowledge and information.

y Level of information reuse, such as the reuse of existing procedures, test designs, and Service Desk scripts.

y Level of satisfaction with training courses, newsletters, and Web briefings.


3.10 sAmPLe TesT QuesTIoNsRefer to the Workbook to do the questions.


Table of Contents

ITIL v3 Intermediate Certification Level | ST | Service Transition Related Activities

uNIT 4: serVICe TrANsITIoN reLATed ACTIVITIesoverviewService Transition supports the Transition Planning and Support, Change Management, Service Asset and Configuration Management (SACM), Release and Deployment Management, Service Validation and Testing, Evaluation, and Knowledge Management processes. In addition, Service Transition supports and is supported by some other activities, such as:

y Communications – you should effectively communicate the implications, benefits, and usage of IT Services to the concerned people for successful Service Transition.

y Organizational and stakeholder change – because of the holistic nature of the Change that forms the basis of Service Transition, organizations do not just transform their IT Services, but the organizations themselves might undergo a Change to use the new and changed Services.

You design Service Transition activities as part of results-oriented processes that focus on improving the transition process. These activities enable you to educate and prepare employees for the Change. In addition, you can manage and control the Changes efficiently using these activities.

We will discuss each of these activities in detail in the subsequent sections.


Table of Contents


unit Learning objectivesAt the end of this unit, you will be able to:

y Understand the goal of Service-Transition-related activities.

y Understand the value of managing communications and commitment.

y Manage organizational and stakeholder change. y Apply the concept of Stakeholder Management to make

decisions in a business situation.

4.1 goALgoalThe goal of Service Transition-related activities is to provide a high-level view of the communications and stakeholder management activities that support Service Transition. These activities are an essential part of, or strong contributors to, Service Transition. Traditionally, communications has been a weakness in Service Transition. Because of a weak communications process, organizations do not share an understanding of the implications, benefits, and usage of IT Services.

4.2 mANAgINg CommuNICATIoNs ANd CommITmeNT



Table of Contents


Identification of stakeholders in the Transition PhaseA Service Change affects many people. Consequently, you might require appropriate stakeholder buy-in to complete the transition successfully. You must establish the individual’s importance and position in the entire transition process. You must identify:

y People who already support the transition. They can be “managed” at the acceptance stage. Because these people do not need to be convinced about the transition, there is no need to spend time on “converting” them to support the transition.

y People who strongly oppose and resist transition. These people will probably not respond to persuasion. As a result, you should not spend time on convincing them because your efforts will most probably be unsuccessful.

y People who can understand the need for transition and would welcome it. These people are between two extremes — the ones who support the transition completely and the ones who oppose it completely. You must concentrate on these people.

service Transition TeamPurpose

Often, organizations spend valuable time on talking to people who are supportive of the transition. This is because speaking to sympathetic and supportive people is easier, and you always get positive feedback from them. However, the Service Transition team needs to focus on people who are on the middle ground


Table of Contents


regarding transition support. Converting them to full supporters will go a long way in paving the path to make the transition acceptable across the organization.

The Service Transition team is familiar with the task of changing attitudes and converting cultures, and it holds no threat for them. You must help ease the situation for people who are new to the transition process. The transition team must understand the importance of its work and the effect the work has on others. Consequently, it must tailor its approach according to the audience profile.

Goal

The ultimate goal of the Service Transition team is: y To build enthusiasm for and commitment to the Change. y To ensure that stakeholders understand the expectations

from the Change and the Impact of the Change.

As a result, a two-way communication channel between the team and the customers is essential for successful transition. Stakeholder management utilizes considerable amounts of labor. Almost 50% of staff efforts are involved in this task during transition in an organization.

Communications PlanningAfter establishing strategies for successful Change and understanding and encouraging the commitment levels required within the organization, the Service Transition team must ensure the availability of a detailed communications plan.


Table of Contents


This plan must target information where it will be most effective. When sharing information related to a Change during the transition process, keep the following considerations in mind for each statement:

y The style to deliver all the information together or in segments over a period. If you plan to release the information in segments, you must know the components you will require for that. In addition, you must know the sequence and time for delivering the message.

y The delivery medium, tone, and style of delivering the message. For example, you need to consider if you want to use a tone that is upbeat, cautious, or optimistic.

y The actions you must take before the communication, which enables everyone to understand and accept the information given.

y The stage and the method to involve groups that will share information with other levels in the organization.

y The success of the information sharing to overcome communication barriers in this Service Transition, for example, cultural differences, large team size, and additional requirements and efforts to communicate with geographically dispersed personnel.

y Communication of the needs of other stakeholders in the project such as decision-makers, opinion leaders, system users, internal and external regulatory bodies, and other individuals affected by the implementation of the new Service Transition.


Table of Contents


Adapted from example of communications strategy and plan contents © Crown Copyright 2007 Reproduced under licence from OGC

Communication strategy

CommunicationPlan

Ownership

Style

Delivery mechanisms

Competences – skills, training

Other related ongoing activities

Audiences internal and externalInvolve staff at all levels (stakeholder and operations)

Ensure the right message meets the right people at the right time!

Monitor audience feedback

Timescales

Key success factors

removing barriers of resistance – building partnerships


Table of Contents


The diagram shows an overview of the key elements that you must consider when planning for effective communication.

Key elements for effective CommunicationFor an effective communication strategy, you must establish surveys and measures to monitor the response of the people involved on a regular basis. The results of the surveys and measures:

y Give feedback for the process. y Include the response of the people after or during the

Change. At this point, you might have individuals who need personal contact from the Service Transition team to maintain their comfort level and accept the process completely.


Table of Contents


Comm

unication Path

Perform G

ap Analysis

Current StatePredicted State

Define the vision and team

chartersO

btain leadership team

buy-in

Develop work packages and reporting tools

Establishcontributing

groups

DefineCom

munications

PlanBaseline

AS-IS/ define pilot phasesIndividual /team

targets agreed Plan how toget to targets and obtainfeedbackPerform

, review and reportReview whole

process

Adapted from example com

munication path ©


GC


Table of Contents


The diagram shows the sequence of Events or the communication path to plan the communication process.

Communication methodsSome common communication methods you can use are:

y Large workshops: You can conduct workshops if you want to deliver a clear and consistent message to the target audience on the overall Service Transition approach. This should ideally be at the beginning of the communication strategy to create understanding, ownership, and excitement within the teams.

y Organization newsletters: You can use this medium to reiterate the message you already delivered to the team. However, you must use this method to reinforce an already delivered message and not when sharing information for the first time.

y Training sessions: Roles and processes change often as part of Service Transition. Consequently, you must focus on target trainees and provide them enough time to grasp the new or changed way of working.

y Team meetings: These are helpful to Service Transition team leaders who will make sure that they reinforce any messages in their weekly meetings. The employees or the team might feel comfortable with this type of meeting because they are in their own comfort zone and with the people they work with daily. As a result, they are more likely to ask questions and get a better understanding of the process.


Table of Contents


y Face-to-face interactions: The key stakeholders involved in the transition process must take out time to visit their staff in their work environment. This will help set a positive example of the support by the senior management. In addition, the employees can ask questions regarding their position and the process.

y Q&A feedback postings: This method enables the employees to raise questions and provide feedback anonymously. You can do this by putting up boards and mailboxes for the feedback.

y Corporate intranets: You can upload information on the corporate intranet to share information and communicate with the transition team.

y Reinforcement memos: The senior management must circulate memos to reinforce key information or share updates on implementation activities. This updates and informs people who are not involved in all stages of Service Transition.


Table of Contents


y Posters/roadmaps: This medium provides good quality, colorful communication that shows implementation activities, progress, or general updates. This helps keep the communication alive and delivers a consistent message.

y Advice notes with pay slips: You can attach key information to pay slips because this ensures 100% communication updates to the team.

y Z-cards/encapsulated reference cards: This is in the form of small credit cards or small-sized documents that hold important information. The employees need to carry these cards or documents in their wallets or purses at all times during the transition process.


Table of Contents


Service Transition

Plan serviceTransition

Perform (do)

review (Check)

Close (Act)

Business Case

Service Transition Statem

ent of Work

Service Managem

ent planO

rganisation models

Service Transition team

chartersM

anagement Sponsors

Team and skill

assessment

Change M

anagement

process initiatedProfile and aw

arenessassessm

ent on cultural valuesJoint verification planC

omm

unications planR

eviewed legal /

contract /com

mercial bases

Risk m

anagement

strategy

Perform Service

TransitionKick O

ffInitiate C

omm

unications PlanInitiate Service Transition processes and w

ork flowInitiate Supplier / Partneractivity and reportingM

anage customer

relationshipsInitiate legal / contractm

anagement

Assess, review and

manage risks

Establish quality m

anagement checks for

all processes during service transition

Evaluate quality and act upon discrepanciesPerform

regular custom

er and team

reviews involved in

service transitionR

efine service transitionprocesses and solutionsbased on SLAs etc andcom

municate

Maintain the

managem

ent of change in all areasTest escalation processesEnsure transition is w

ithin scope and cost m

odelsM

aintain risk m

anagement throughout

Review

organizational andcultural changesValidate SLAs are m

etPerform

customer and team

reviews for feedback and

lessons learntProduce post im

plementation

review report for change

managem

entSign off contract and costm

odelsO

btain business sign off forService TransitionD

efine plan for ongoingC

ontinual ServiceIm

provement

Adopted from exam

ple of service Transition steps for outsourcing ©


GC


Table of Contents


Change modelsChange Models enable you to communicate with people about their expectations from each Service or Change. The diagram shows an example of a Change Model that you use to transition Services from an organization to a commercial Service Provider. The diagram shows a situation where there is a total organizational Change, that is, there are Changes in management, processes, and staffing, although most of the staff might transfer to a new Service Provider organization. To set appropriate expectations during Service Transition, you must have access to a set of Service, Change, and transition models that is easy to communicate.

It is important that you update people about the progress of the Change, good or bad, to help motivate them.

job CharacteristicsThe important characteristics of any job are:

y “Feedback from the job y Autonomy y Skill variety y Task identity y Task significance”



Table of Contents


Purpose of job CharacteristicsThese characteristics enable the staff to achieve:

y “Knowledge of the actual results of work activities y Experienced responsibility for outcomes of work y Experienced meaningfulness of the work”


If you have all these job characteristics, you achieve high internal work motivation.

Everyone in the team will engage themselves if they see progress in the Change process. You must also communicate and celebrate short-term wins to motivate the team.

4.3 mANAgINg orgANIzATIoNAL ANd sTAKehoLder ChANge


managing organizational and stakeholder ChangeAccording to the agreed design, Service Transition implements a new or changed Service effectively and makes the functions of organizations different from what they were earlier. An organizational Change can be of any type. It can be as small as the movement of staff to new premises or major Changes in the nature of business or a change from the face-to-face retail mode of business to Web-based trading.


Table of Contents


You cannot avoid Change because it is an important part of organizational development and growth. An organization can never progress without Change. A Change might occur in phases or unexpectedly, affecting some or all of the organization, its people, and its culture.

At times, the efforts put in for organizational Change fail because you do not manage and monitor them efficiently throughout the Change process. These failures then result in an increase in resistance, dissatisfaction among employees, and costs. It is never easy to implement Change; it takes much longer than planning for it. You also face a lot of resistance during the transition process. Consequently, efficient managers understand the implications of Change and its processes and plan accordingly. The organization might face the risk of losing disillusioned staff. This will have a negative Impact on the organization in terms of unsatisfied staff leaving without proper handover. This might lead to the loss of knowledge and the introduction of Risks in the organization.

When you do not manage and control Change properly, it creates confusion and chaos in the organization. Change cannot happen without the support of people. As a result, business managers and Change agents must understand the emotional Impact the Change would have on people and accordingly support and manage it. A lot of research has been done on the emotional Impact of Change on the people of the organization.


Table of Contents


T i m e

shock

avoidance

external blame

self blame optim

um perform

ance

acceptance

Adopted from

The emotional cycle of change

© C

rown C


OG

C


Table of Contents


emotional Cycle of ChangeThe diagram shows the emotional cycle that people or employees go through before accepting any type of Change in their organization.

When initially told about the Change, people get a degree of shock before trying to avoid the Change. However, after this stage, people start blaming the initiators of the Change and the Service Transition team. After this stage, they start blaming themselves when a sense of insecurity and the threat that the situation poses sinks in. At this stage, performance is at its lowest. Consequently, the faster the Service Transition team can get the team through the cycle, the quicker it will be for the people to move from the acceptance stage to the optimum performance stage.

As part of the Service Transition team, you might have to spend a lot of time listening to peoples’ concerns and resolving them. However, this ultimately results in engaging them in the process and improving their performance at the earliest.

You must openly communicate with your team through these stages of transition. This encourages the team to move from low energy to high energy, involve itself, and show a positive attitude toward the Change. As already stated, all individuals, at different levels and speeds, follow this cycle. As a result, you must understand each person’s need and support the person through the cycle. The team, in turn, will be committed to Service Transition.


Table of Contents


Ingredients of ChangeThe five main ingredients of Change are:

y Necessity y Vision y Plan y Resources y Competence

If you do not establish the necessity, people will resist a lot. If you do not have a vision, employees will be confused. If you do not have a plan, there will be chaos in the activities and transition. If there is a lack of resources, employees will be frustrated. If you do not have competence, employees will be afraid of failure. Consequently, you must establish management commitment to take proper care of these Change requirements.

4.3.1 orgANIzATIoNAL ANd serVICe TrANsITIoN roLes ANd resPoNsIBILITIesservice Transition rolesThe managers and executives involved in implementing a Change are responsible for managing the Change and the associated transition. Managers must have full awareness of the Change and should communicate openly and honestly with the rest of the team involved in the transition. They must also listen to any concerns and try to resolve them for smooth transition. This must happen if the Change is significant enough to affect the organization. The management board and executives must have


Table of Contents


proper controls in the organization. In addition, they must update and caution others about any barriers and manage the transition accordingly by forming a clear and strategic vision.

factors for successful ChangeSome factors that initiate a successful Change at the organization level are:

y “Leadership for the Change y Organization adoption y Governance process y Organization capabilities y Business and Service performance measures y A strong communication process with regular opportunity

for staff feedback”


Service Transition does not manage the overall business and technical Change in an organization. However, the Service Transition process owner or manager is the key stakeholder in the process. In addition, the process owner or manager must be proactive enough to report issues and Risks to Change leaders during situations such as when Service Operation is not able to keep the Services functioning because of the volume of Change.


Table of Contents


organizational AdoptionOrganizational adoption is part of the Change Management process, which occurs at two levels — individual and organizational. As a result, you must understand the organizational culture and the people involved. The culture of the organization and the people involved might vary based on:

y “Business culture - this may be different depending on the industry, geography, etc.

y Culture of customer organization y Culture of Service Provider/IT organization y Culture of Supplier organization y Individual personalities, especially of senior managers and

Change champions”


Change elements in service TransitionStrategy and design are responsible for the cultural and organization assessment and Change design. However, some transitions might require the team to change their behavior and attitudes for successful implementation. As a result, you must understand the Change elements in a transition correctly. It is also critical to assess the Risks and success involved in the transition process. Service Transition is involved in the early stages of the Lifecycle to assess and incorporate these elements in the design and build of the organizational Change.


Table of Contents


During Service Transition, you might have to change the attitude of people across the Lifecycle for efficient and successful transition. These people include:

y “Service Transition staff y Customers y Users y Service Operations staff y Suppliers y Key stakeholders”



Table of Contents


example of the use of simple messages in service TransitionService Transition focuses on simple messages at a time to ensure consistency in the Change implementation process.

For example, Service Transition helps everyone: y “Understand the need for knowledge and effective

knowledge transfer y Understand the importance of making decisions at the

right speed and on time y Understand the need to complete and review

Configuration Baselines in a timely manner y Apply more effective Risk assessment and

management methods for Service Transition y Follow the deadlines for submitting Changes and

Releases”


service Transition responsibilitiesService Design assesses the IT organization’s capability and capacity to transition new or changed Services. On the other hand, Service Transition:

y Performs a quality check to determine if the organization and stakeholders are ready for the Change.


Table of Contents


y Identifies any issues and Risks related to the organizational Change, for example, Risks identified during testing, pilots, deployment, and Early Life Support (ELS).

y Ensures that the organizational Change adheres to the plans.

y Ensures that the Change is relevant to the current situation.

y Ensures that the Change delivers the expected organization, capabilities, and resources.

y Ensures that customers, users, and Service Operations staff adopt the Changes. If they accept the Changes, they will ensure that they implement the Changes successfully.

According to anecdotal evidence, if 70% of the people accept the Change, everyone considers the Change an established behavior. However, if the adoption rate is lower than this, the organization might revert to its old ways of working. The actual ratio is influenced by the degree of involvement of the staff in a Change, for example, some important members of a team can majorly influence the acceptance or rejection of a Change.

requirements for successful service TransitionThe essential requirements for successful Service Transition are:

y Need an organized, competent, and well-motivated team to build, test, deploy, and operate the Service.


Table of Contents


y Rely on changing the organization and people. As a result, you must focus on key aspects, such as competency assessment and development, recruiting, skills development, knowledge transfer, team building, process improvements, and resource deployment. However, if Service Transition finds a gap in any of the capabilities, it provides appropriate inputs to the people involved in the relevant areas, for example, Project Management, Service Design, and Continual Service Improvement (CSI).

y Determine and establish values and drivers to manage the Change effectively. Each organization is different; consequently, the process of transition will also be different for each organization.

organizational CultureOrganizational culture is determined by the following, which is shared by the employees in an organization:

y Ideas y Corporate values y Beliefs y Practices y Behavior y Customs

Culture can support or resist an implementation. During Service Transition, you must understand the type of culture that exists in the organization and how the culture will affect the planned Change.


Table of Contents


To review the Service Strategy and Service Design deliverables, you must ask yourself some questions. Let us look at the key question.


4.3.2 PLANNINg ANd ImPLemeNTINg orgANIzATIoNAL ChANge


Planning and Implementing organizational ChangeMany designs for managing organizational Change, such as the famous McKinsey 7S model, do not consider the people affected by the Change. Project Managers in IT departments focus more on technical activities. They often ignore the Changes required for the organization or individuals. Because a Change affects many people, the Project Managers should ensure that the project plans include all the organizational Change activities.

requirements to manage organizational ChangeTo manage an organizational Change, the stakeholders and IT teams involved in Change Management must understand the requirements. They must be able to identify:

y The strategic drivers, personalities, and policy Changes of the business and organization.

y The Problems that the proposed Change will solve.


Table of Contents


y The deliverables of the new or changed Service. y The appearance of the new or changed Service. y The modifications required in current objectives. y The objectives of the Change, as defined by the

management and the process, and how to judge success throughout organization levels.

y The processes, templates, decision points, and systems to be used and the level of reporting data required to make decisions.

y The people who will be involved in the process and those who were there earlier but are no longer required.

y The people affected within and outside the organization. y The constraints present, including the type, range,

and flexibility time slots, equipment, staff, and supplier availability.

y The planned timescale. y The person or process that can help plan the

implementation. y The skills and measures that need to be considered. y The effect on “normal” life. y The consequential Changes, such as Changes to

business methods.

As part of the quality assurance and implementation process, you can inspect the stakeholders and IT teams to understand and clarify their expectations of these aspects.


Table of Contents


organizational Change ProductsTo accomplish the organization transformation completely, a change from the current state to a new state requires a change in a combination of elements. The Service Design Package (SDP) defines the required Service. In fact, many outputs from the Service Strategy and Service Design Lifecycle stages assist in the management of organizational Change during Service Transition. The work products that are the outputs from the Service Strategy and Service Design Lifecycle stages are:

y “Stakeholder map y Current organization and capability assessment y Current and required competency model and competency

assessments y Constraints (including organization, capability, resources) y Service Management process model y Policies, processes and procedures y Roles and responsibility definitions, e.g. a RACI

(Responsible, Accountable, Consulted, Informed) matrix y Relationship management y Communication Plan y Supplier framework, especially where multiple suppliers

are involved”



Table of Contents


“example of rACI matrix for managing change

Role R

esponsibility

Change sponsor,

e.g. business and IT leaders

Change enabler,

e.g. process ow

ners, Service ow

ners

Change agent,

e.g. team leader

instructing change

Change target,

e.g. individual perform

ing the change

Articulate a vision for the business and service change in their domain

A/R A/R C I

Recognize and handle resistance to change

A/R A A C

Initiate change, understand the levers for change and the obstacles

A/R A/R C C

Manage change and input to change plan

A/R A/R C C


Table of Contents


Role R

esponsibility

Change sponsor,


Change enabler,

e.g. process ow

ners, Service ow

ners

Change agent,

e.g. team leader

instructing change

Change target,


ing the change

Input to design of target organization or structure, etc

A/R A/R C

Set up a system for communicating change

A/R A/R C

Steer change A/R A A C

Mobilize the organization A/R C C C

Mobilize their department, unit, team

A/R A/R C

Lead workshops and group analysis of the current processes

A/R A/R


Table of Contents


Role R

esponsibility

Change sponsor,


Change enabler,

e.g. process ow

ners, Service ow

ners

Change agent,

e.g. team leader

instructing change

Change target,


ing the change

Run effective meetings A/R A/R A/R A/R

Solve problems in groups A/R A/R A/R”


The following table shows an example of a RACI matrix that helps you manage Change during the Service Lifecycle that supports Service Transition activities

In the table, the “R,” which stands for responsibility, has more than one occurrence. This indicates that the responsibility is hierarchical in nature and strategic, tactical, and operational responsibilities are required. In these instances, the occurrences on the left focus more on management. The occurrences on the right focus more on delivery.


Table of Contents


Validation of organizational Change ProductsService Transition checks whether the organizational Change products and Services are fit for purpose. For large-scale Changes, such as mergers, acquisitions, and outsourcing, you must include validation of the approach for:

y “Career development – Are succession plans being built? Do individuals have an understanding of their progression prospects?

y Performance evaluation at organization, team and individual level – Are regular reviews conducted? Is the documentation formal, and is there demonstration of a consistent approach?

y Rewards and compensation – Is there a net benefit to people affected by the Change?

y Recruitment and selection – Where there is any shortfall in any roles required, is there a fair and consistent process to selection, including the process of internal movement as well as selection from the external market?”



Table of Contents


“example of organization work-products from the build stage Organization ModelNew or changed organizational structureCareer development structureReward and compensation structurePerformance evaluation structurePerformance measurement structureCompetency listCompetency/activity matrixTarget job, role, staffing and competence requirements matrixJob definition and designRole definitions and descriptionsStaffing plan


Table of Contents


Competency model detailed designIndividualIndividual assessmentCompetency assessment (including role and skill assessment)Performance assessmentPerformance enhancement needs assessmentLearning needs assessmentEducation and trainingLearning approachLearning test approachPerformance enhancement designLearning definition and designCourse definitionPerformance enhancement support designPerformance enhancement support plan”


The table lists the typical work products that the Service Transition team depends upon.


Table of Contents


4.3.3 AssessINg ANd moNITorINg orgANIzATIoNAL reAdINess ANd ChANge Progress

“Organizational role and skills assessment checklist

Check EvidenceIs there an assessment of the number of staff required and their current skill levels? Plan

Is there a documented vision/strategy to address any Risks in each area, for example, in case of resource shortfalls, start hiring actions, subcontract, or outsource the whole area?

Vision/strategy

Have the generic roles and interactions throughout Service Transition been reviewed?

Roles and responsibilities interaction matrix

Are specific roles and measures defined? Performance measures by role

Have the skills for each area, that is, content, application, technical, and business, been defined?

Skills requirements for each area

Is there an assessment of the organization’s personnel against requirements?

Assessment report


Table of Contents


Have personnel from areas in the organization other than the areas covered by Service Transition been considered?

Assessment report

Have the requirements for both the development and maintenance that support business needs been considered?

Requirements

Has the level of Risk that relates to the support available for specific areas been documented in addition to the areas that cannot be supported and the assumptions that apply to the analysis?

Risk assessment report”


The table depicts a checklist that you can use to assess the role and skill requirements during Service Transition.


Table of Contents


“Example of a feedback surveyAspect ResponseService Transition meetings are properly managed and run effectively.I have a clear idea of what is expected of me during this Service Transition.I am confident that I can successfully accomplish the assigned Service Transition work.My manager encourages me to exchange ideas about how to work better and/or improve the current processes.My manager is willing to listen to my concerns and ideas and pursue them on my behalf.The Service Transition communication methods, frequency, and content meet my needs.The atmosphere during Service Transition is friendly, helpful, and open.There is sufficient effort being made to get and evaluate the opinions and thinking of all members of the Service Transition team.I clearly understand the operational needs of this Service Transition.The work that I am responsible for will meet the Service Transition and operational needs of business users.


Table of Contents


Aspect ResponseThe job requirements allow me to balance my workload and personal life.I believe real actions and Service Transition management considerations will result from my feedback captured from surveys.”


survey resultsTo implement a Service Transition program effectively, you should perform regular checks and surveys at many levels of the organization. The table shows a feedback survey that you can use for both individuals and the teams involved.

Survey results enable you to determine the progress made through Service Transition. They help you determine the employee commitment status and identify areas for improvement. You can use this survey at various milestones within the transition journey. The employees of the organization feel that their opinions are important during the critical time, as they progress through the Service Transition program. You can increase the positive engagement of the new processes by “taking the majority with you.”

After you have the survey results, you should: y Analyze and understand the responses obtained during

the survey. y Address and fix issues, wherever required, as soon as


Table of Contents


possible. y Inform respondents to the survey about the Changes that

result from their feedback. This is the only way to make your staff ensure that their feedback matters and achieves improvements.

y Identify improvements in the post-implementation review (PIR) of the Service Change often and feed it into CSI.

4.3.4 meThods, PrACTICes, ANd TeChNIQues used To mANAge ChANgemanaging organizational ChangeAt times, senior executives tend to skip the need for organizational Change. Instead, they prefer passing their own directives to manage Changes. This approach is detrimental to the organization and not effective.


Table of Contents


ITIL recommended guidelinesITIL recommends specific guidelines that you can follow to manage Changes.

Per the ITIL guidelines, you should: y “Establish a baseline and vision. y Develop a communication strategy and check that

communications are understood. y Identify Impact on other Services, processes, systems and

people not involved in Service Transition Identify Impact on customers/users and other stakeholders.

y Be able to articulate and communicate why are we making this Change.

y Identify new skills/knowledge required. y Consider development requirements and how these

requirements will be addressed – training, coaching, and mentoring.

y Promote the right culture. y Promote organizational discipline. y Integrate HR support. y Put the right people in the right role/job. y Help people to manage stress. y Encourage people to think that the situation can be

improved – it generally can be.


Table of Contents


y Provide easy access to information about the Change. y Ensure new or Changed documentation/instructions are

concise and understandable for the target audience.”


Per ITIL guidelines, you should not: y “Try to micro-manage everything. y Put minor Changes through bureaucratic processes. y Forget the agreed degree of exposure to Risk – in many

circumstances the business is taking commercial Risks as a deliberate policy, but IT and others stand to undermine the business justifications and policies by trying to remove Risk from their component of a business Change

y Focus solely on the IT – all components of a Service must be transitioned.

y Forget the people. y Over-complicate things – they are harder for people to

understand. y Ignore the after effects of failed Changes on people. y Neglect the costs of transition.” y Succumb to inertia – instead re-assess validity and

relevance of the Service or Change. y Pretend that there will be no losers.”



Table of Contents


other guidelinesIn addition to these ITIL guidelines, you can use J. P. Kotter’s approach to manage Changes or transformations. This approach includes eight steps that you can use to identify gaps in managing transformations in your organization. Each of these steps is an iterative stage, and you need to check the understanding of people at each communication Event.


strategies for successful organizational ChangeYou can apply various strategies to ensure the successful implementation of organizational Changes. Kotter and Schlesinger (1979) suggested various strategies to manage organizational Change. You can use these strategies to:

y Assess the Service Design approach. y Manage Changes during Service Transition. y Identify the Risks associated with organizational Change.

Let us now discuss each of the strategies that Kotter and Schlesinger suggested.

strategies of Kotter and schlesingereducation and commitment – it is important to educate and provide information to people about a Change and its associated implications as part of early planning activities. The earlier you communicate and discuss the pros and cons of the plan, the higher the possibilities of a successful Change implementation.


Table of Contents


Participation and involvement – in addition to implementing the strategy of education and commitment, you should involve people and encourage them to participate in implementing Changes. You should also ensure that there is an effective monitoring and review of managers to assess the Impact of Change on Service Transition. This ensures that people understand the need for Change and overcome resistance to implementing the Change. At times, even after ensuring participation and involvement, you might find that people tend to revert to previous work practices. You call this “Change fatigue,” which is expected at various stages of the Service Transition process. To overcome this problem, you need to monitor the Impact of Changes regularly.

facilitation and support – the people managing the Change should be ready to address the queries and apprehensions of other people about the Change. You should accept the expressed resistance of people as a positive trend because it indicates that employees are involved in the Change and can be motivated and convinced to accept it.

To facilitate and support people in implementing Changes, you should perform a skills gap analysis and train people on any new process before implementation.


Table of Contents


The manager needs to: y Promote the benefits of the Change. y Reiterate the objectives of the Change. y Communicate the vision of the organization and the value

of the contributions of the employees in this respect. y Identify any hidden issues that have not been expressed

and handle these issues effectively to avoid secret, subversive activities.

Negotiation and agreement – a Critical Success Factor (CSF) of any Change implementation is the agreement of the concerned people. Consequently, managers should be prepared to negotiate, either formally or informally, to gain the agreement of the people. Service Transition plays a vital role in ensuring agreement after each Service Lifecycle stage. In case there is an expected negative Impact on individuals, managers should involve the unions and HR departments to gain the acceptance of the people.

manipulation and co-operation – at times, negotiations are ineffective in gaining the acceptance of people. In such situations, to ensure the participation of people who oppose the Changes, you might need to either make them privy to restricted information or buy them off by offering additional rewards. For example, this strategy is specifically applicable in situations when the Service Provider changes and there is a possibility of noncooperation by the key staff who have irreplaceable knowledge and experience.


Table of Contents


explicit and implicit coercion – you might come across situations in which coercion is the only appropriate mechanism to ensure the participation of people in the Change implementation. This strategy involves the associated costs and might lead to conflicts with the existing values and beliefs of the organization. Consequently, if you need to implement this strategy, you need to ensure that people with strong leadership skills and the knowledge and ability to handle possible problems are involved.

other strategies for successful organizational ChangeIn addition to these strategies suggested by Kotter and Schlesinger, managers commonly use some other methods to successfully implement organizational Change. Usually, managers:

y Reward desirable behavior and discourage inappropriate behavior that is detrimental to Service Transition.

y Identify the points of dislike of concerned people in the current system and attempt to address the issues.

y Hold informal meetings to discuss the issues associated with the Change and understand peoples’ viewpoints to avoid entrenched attitudes.

y Reinforce the vision of the Change and play a role model for the Change. This might act as a positive agent for the Change.

y Identify individuals who can gain the support of people by applying peer group pressure and persuade people that the Change is good for the organization.


Table of Contents


y Use the Pareto Principle of 80:20, in which you can move to the next phase when 80% of the people accept the Change. The remaining 20% will follow consequently.

y Share positive Changes and celebrate success to encourage people to accept the Change.

reasons for resisting organizational ChangeWhen a Change is implemented in an organization, people might resist it for various reasons. Rosabeth Moss Kanter identified 10 reasons for people resisting Change in organizations and optional strategies to promote positive Change enablers. Service Transition staff can apply these strategies associated with specific reasons to understand how to handle resistance issues from individuals during Service Transition.

The 10 reasons are: y Loss of control – in the process of implementing the

Change, when you move people from a familiar process to a new, unknown one, they feel that they have lost control of the situation and, consequently, resist the Change. To overcome this problem, involve the people in the decision-making process. Explain the business benefits and the Return on Investment (ROI) to communicate how the proposed Service Transition will support business needs.


Table of Contents


y excessive personal uncertainty – when a new Change is proposed, people might resist the Change because they are uncertain about their role and its benefits. To address their concerns, explain the need for the Change, its implications at both the business and the individual level, and an estimation of the uncertainty period after implementing the Change.

y Avoidance of surprises – surprise Changes may result in resistance. As a result, give people the opportunity to think through the implications of the Change.

y The difference effect – at times, people resist Changes because they fear that a new Change might disrupt the existing traditional identities that they have built based on their work, role, job, and corporate name. To address this fear, managers should only make the required Changes and retain the existing, familiar symbols as far as possible.

y Loss of face – people usually resist Changes because they have to move from one competency to another. Consequently, when implementing Changes, managers should acknowledge an individual’s existing competence and then let the individual participate in the decision-making process of the Change with respect to the new set of competencies. Managers can also implement this by jointly setting personal objectives along with the concerned person.


Table of Contents


y fear around competence – some people resist Change because they believe that they cannot adopt the new ways of working. The solution for this is to provide the required training and coaching before implementing the new system or process. This instills an enhanced level of confidence in the people, communicates the need for personal responsibility for their career development, and encourages them to accept the Change.

y ripples – at times, Changes have a ripple effect on related areas of the organization, and it is not always possible to accurately predict the effects. Consequently, during the planning phase, managers should encourage people to think widely and divergently and identify all probable as well as improbable possibilities while predicting the outcome of the planned Change. This helps minimize the ripple effect of Changes.

y Increase in workload – a common effect of any Change is an increase in workload. To address this concern, managers should address and acknowledge the additional workload of people and reward them, if possible.

y Past resentments – people might also resist a proposed Change if it is associated with an individual or organization with whom they have some existing grievances. To address this type of situation, managers should encourage people to voice their resentments and then repair or remove them.


Table of Contents


y real threats – there are times when a Change might lead to a negative Impact on the individual, and consequently, the individual resists the Change. To address such real threats, managers should discuss the threat with the concerned individual and then involve the individual in resolving the threat.

4.4 sTAKehoLder mANAgemeNT


stakeholder management Stakeholder management is a CSF for the success of Service Transition. When you implement any Changes to new or existing Services, you must:

y Meet stakeholder requirements to be successful in the transition.

y Actively involve the stakeholders involved in the Change at all stages of the process to understand their requirements.

y Set stakeholder expectations of the Change.

If you do not identify all the stakeholders in a Change process, the people who are not involved in the process will be unaware of the Change and will not support it. In addition, stakeholders who are not involved in the Change will not be able to register their concerns and expectations.


Table of Contents


stakeholder management strategyThe stakeholder management strategy of Service Design:

y Defines stakeholders. y Describes the interests and influences of the stakeholders. y Defines the level of engagement due to the project or

program. y Identifies the information that needs to be communicated. y Describes the system to process feedback.


Table of Contents


Adopted from Potential stakeholders © Crown Copyright 2007 Reproduced under licence from OGC

Top management Government

Suppliers (services) Business areas

Business partners Operational staff

Press and media Trade unions

Customers

Suppliers (products)

Audit

Shareholders

Programme and project teams

Stakeholder Management


Table of Contents


The diagram shows the potential stakeholder in an organization.

effective service TransitionFor effective Service Transition, you must categorize the stakeholders. However, you must ensure that the categories you choose are recognizable and not abstract.

examples of stakeholder Categorization y Users/beneficiaries y Providers

You can further break down each category, if required. You can have the same individuals in different categories.

example of a recognizable CategoryEmployees based in one geographical location

example of an Abstract CategoryMembers of the public who support human rights

stakeholder differentiationEach stakeholder has different interests in the Change implementation.


Table of Contents


example of the Varied Interests of stakeholders Some stakeholders think about how a particular Change affects their working environment while some want to influence the Changes in the way they handle their customers.

“Example stakeholder map

Stakeholders

Strategic direction

Financial

Operational

changes

Interface with

customers

Public safety

Com

petitive position

Business Partner

Project teams

Customers

Press and media

Trade unions

Staff

Regulatory bodies



Table of Contents


You can use a stakeholder matrix, as given in the diagram, to map the different stakeholders to their interests in Service Transition, its activities, and its outcomes. Service Transition must always work together with Service Design to ensure the accurate mapping of stakeholders to their interests and expectations.

stakeholder AnalysisA stakeholder analysis helps you understand the requirements and interests of the stakeholders and the Impact of the Change on the stakeholders. The influence and Impact of the stakeholders can be rational and justifiable or emotional and unfounded. However, you must consider the stakeholders’ feedback seriously because they can affect the Change process and, consequently, Service Transition.

stakeholder map and AnalysisYou can also reuse many elements from the stakeholder map and analysis. For example, when you have many projects that deliver into a shared Service and infrastructure, the stakeholders can be the same. The stakeholders can also include the business sponsor, the Service Operations Manager, the Service Management head, and the Change Advisory Board (CAB) members.


Table of Contents


Communication ChannelsYou can ensure that the communication channels are targeted as required by using the stakeholder analysis. In addition, the messages, media, and levels of details must reflect the needs of the key stakeholders. The communications channels must also include those stakeholders who are not involved directly in the transition process. At times, you might need to work through partners, industry groups, regulatory bodies, and so on. Consequently, when you have one communication approach that covers all these areas, you can deliver a more consistent and stronger message than you could have done when you operate at a functional level.

method to Analyze stakeholdersOne method to analyze stakeholders is by understanding each stakeholder’s importance to Service Transition and the possible Impact of the Change on them. Finally, “plot” stakeholders on a matrix, as shown in the given diagram.


Table of Contents

ITIL v3 Intermediate Certification Level | ST | Service Transition Related ActivitiesH

ighM

ediumLow

Importance of the stakeholders to

Change Assurance and Service Technology

Adopted from Power im

pact matrix ©


GC


Table of Contents


Power Impact matrixUsing this matrix, you can describe the activities that Service Transition should adopt.

example of Activities that service Transition should AdoptYou must give “high” importance to the Service Change if it is a business sponsor, and according to the scale and opportunities for any ROI, you can give “low,” “medium,” or “high” importance to the Impact of the new or changed Service.

The position of the stakeholders in the matrix can change as the Service Package progresses through the Lifecycle. Consequently, you must perform the stakeholder analysis again, especially when you do detailed planning for Service Transition. If the stakeholders are responsible, they can and must enhance and sometimes alter the course of Service Transition per the requirement.

Many stakeholders come and go during the Service Lifecycle. However, the key stakeholders, such as the sponsors of the Change, should ideally remain constant throughout. Nevertheless, you must maintain adequate records and documentation to enable effective handover when there is a replacement of individuals. This is judged according to the business Risk and cost.


Table of Contents


Some stakeholders can participate in advisory or assurance roles while some can assess the realization of the benefits and still others can contribute to audits.

“Example commitment planning chart

Key players Not Committed

No resistance

Helps it happen

Makes it happen

Departing director of customer X O

Chair of board of Service provider O X

New director of Service provider OX

Customer O X

Your managers O X

Your staff O XService Strategy team OX

Suppliers O XServices Operations O X”



Table of Contents


The table shows an example of a commitment plan. The table shows the current commitment level of individuals and groups. In addition, it shows how to change this commitment for successful transition.

Each individual is rated with an “O” to specify his or her current position, and an “X” to specify the degree of commitment to you from him or her. At times, the individuals need to step back, for example, in this table, the departing director of the customer might need to hand over the leadership role.




Table of Contents

ITIL v3 Intermediate Certification Level | ST | Organizing for Service Transition

uNIT 5: orgANIzINg for serVICe TrANsITIoNoverviewAll related activities in a process need not be limited to only one, specific organizational unit. For example, you can implement Service Asset and Configuration Management (SACM) in various departments of your organization, such as Service Operation, Application Management, Network Management, systems development, and even non-IT departments, such as procurement.

You need to execute various processes and their associated activities throughout the organization. Consequently, you must map these activities to existing IT departments/sections. The process manager for each department must coordinate and organize these activities and processes.

Various roles are involved in the delivery of any process or Service. As a result, after developing detailed procedures and work instructions for any process, the organization maps roles and responsibilities to the various activities of the process. You must also define the roles and responsibilities associated with any new or changed process very clearly. This is a Critical Success Factor (CSF) for any type of process implementation.


y Understand the goals of organizing for Service Transition. y Organize specific Service Transition roles and responsibilities.


Table of Contents


y Understand generic roles. y Identify and coordinate process activities, methods, and

techniques. y Determine the triggers, inputs, outputs, and interprocess

interfaces. y Understand the relationship of Service Transition with

other Lifecycle phases.

5.1 goALsgoalsThe goals of organizing for Service Transition is to:

Discuss the roles and responsibilities involved in Service Transition and Service-Transition-focused capabilities.

Understand the possible Service Transition organizational structures and their applicability to different circumstances.

Analyze the organizational context for Service Transition and the relationship of Service Transition with other Lifecycle phases.

Understand the organizing roles and responsibilities of each Service Transition process.

Understand the relationship of Service Transition with other Lifecycle processes.


Table of Contents


5.2 serVICe TrANsITIoN roLes ANd resPoNsIBILITIesdefining and Allocating roles and responsibilitiesYou must define and allocate responsibility for each process and Service to deliver the Service effectively. The team involved in the process and Service Delivery must correctly understand their responsibilities toward Service Transition. However, you might not necessarily dedicate a person for each process or Service.

Service Transition includes both generic roles as well as specific ones.

5.2.1 geNerIC roLes


The two generic roles involved in Service Transition are Process Owner and Service Owner.

Process owner roles and responsibilitiesThe Process Owner ensures that all activities defined within the process are employed. The Process Owner:

y Defines the process strategy. y Assists with process design. y Ensures the availability of appropriate and current process

documentation.


Table of Contents


y Defines appropriate policies and standards for use throughout the process.

y Performs regular audits of the process to ensure compliance with policy and standards.

y Reviews and updates the process strategy periodically to ensure that it is still accurate.

y Communicates process information or Changes, as required, to ensure awareness.

y Provides process resources to support the activities required throughout the Service Management Lifecycle.

y Ensures that process technicians have the desired knowledge and critical understanding of technical and business issues to deliver the process, and identify their role in the process.

y Reviews opportunities to improve the efficiency and effectiveness of processes.

y Addresses issues with the execution of the process. y Provides input to the ongoing Service Improvement Plan

(SIP).

service owner roles and responsibilitiesThe Service Owner is responsible for the initiation, transition, and ongoing maintenance and support of the Service. The Service Owner is accountable to the IT director or Service Management director for Service Delivery. The Service Owner:

y Acts as the prime customer contact for all Service-related enquiries and issues.


Table of Contents


y Ensures that ongoing Service Delivery and support satisfy customer demands.

y Identifies opportunities for Service improvements, communicates with customers, and raises a Request for Change (RFC) for assessment, if appropriate.

y Liaises with the appropriate Process Owners throughout the Service Management Lifecycle.

y Solicits the required data, statistics, and reports for analysis and facilitates effective Service monitoring and performance.

5.2.2 sPeCIfIC roLes


Table of Contents


Planning and Support

Change andSAC

M

ServiceKnow

ledgeM

anagement

Service Test M

anagement

ServiceTransitionM

anager

Service M

anagement

Office/IT Planning

Performance

and Risk

EvaluationTest Support

Test Team 1

Test Team 2

Release

Team1

Release

Team2

Build and TestEnvironm

entM

anagement

Release

Packagingand Build

Release

Packagingand Build

Deploym

entTeam

Early LifeSupport

Early LifeSupport

a Independent of Release and Deployment.

b Independent of Service Test Managem

ent.c Includes m

onitoring incidents and problems, problem

managem

ent, raising RFCs, reporting performance and risk assessm

ent.

May be appointed for a specific release

Can be done by a different team

in the service provider organization

Permanent service transition roles

Includes capacityand resource m

anagement

Reports to Service Provider D

irector

a

Deploym

entTeam

bcc

Release and

Deploym

ent

Adopted from exam

ple of an organization for service Transition ©


GC


Table of Contents


Service Transition Roles and Responsibilities Many people, roles, and processes are involved in Service Transition. You must actively manage the processes and understand the roles involved in effectively delivering IT Services within an organization. An important understanding is the allocation of the Service Transition Manager role for this process.

The specific roles and responsibilities mentioned below relate mainly to Service Transition. However, other processes within the Service Management Lifecycle can also use these roles to some extent.

You can allocate some of these responsibilities to one person based on the size of your organization and the scope of the Service being transitioned. However, you must allocate the Service test management and physical testing to resources that are independent of other functions or processes.

Service Transition ResponsibilitiesAll the staff involved in Service Transition must:

y Identify and raise Risks and issues. These Risks and issues might directly relate to their process area or may have been observed from within or outside Service Transition.

y Be aware of and understand the context of the business in which they are working. In addition, they must understand the customer’s business needs of the Services they are providing.


Table of Contents


y Be aware of the projects under way and the expected Service Delivery of those projects, including the future Impact on their area of responsibility.

y Follow the published standards for documentation and the Change, Asset and Configuration, Incident, Problem, and Knowledge Management processes. Where predefined standards do not exist, the staff must raise this as a Risk as early as possible.

specific roles and responsibilities of service TransitionThe specific roles and responsibilities of Service Transition are:

y “Service Transition management y Planning and support y Service Asset and Configuration Management and

Change Management y Performance and Risk evaluation y Service Knowledge Management y Service test management y Release and deployment y Release packaging and build y Deployment y Early life support (ELS) y Build and test environment management”



Table of Contents


Let us now look at each of these activities and the roles involved in them in detail.

service Transition managementThe Service Transition Manager manages and controls the everyday activities of the Service Transition team. The Service Transition Manager:

y Plans and manages the overall Service Transition delivery, including Continual Service Improvement (CSI).

y Manages and coordinates the Service Transition functions. y Budgets and accounts for the Service Transition team’s

activities and resources. y Acts as the prime interface for the senior management

for activities such as Service Transition planning and reporting.

y Makes recommendations to the business and IT regarding the decisions to release and deploy a Service into production.

y Ensures the use of all organizational policies and procedures throughout transition.

y Ensures that the final Service meets the customer and stakeholder requirements defined in Service Design.

Planning and supportService Transition Managers might not be involved in planning and support. In some organizations, they consolidate these activities into an overall Service Management office or IT


Table of Contents


planning responsibility. However, it is important to perform this role regardless of the location of the person in the organization. This activity supports the Service Transition teams and people.

Planning and support: y Defines the requirements, processes, and tools for

transition planning and support. y Maintains and integrates lower-level plans to establish the

overall, integrated transition plans, which include planned versus actual.

y Maintains and monitors the progress of Service Transition Changes, issues, Risks, and deviations, which includes action tracking and Risk mitigation.

y Maintains records and provides management information on resource use, project/Service Transition progress, and budgeted and actual expenditure.

y Manages and coordinates requests for resources. y Coordinates Service Transition activities across projects,

suppliers, and Service teams, as required. y Publishes Service Transition performance statistics and

identifies key improvement areas. y Undertakes formal quality reviews of the Service Transition

and Release and Deployment plans and agreed transition activities according to the Quality Management plan.

y Manages support for tools and Service Transition processes.

y Communicates with stakeholders.


Table of Contents


sACm and Change managementService Design is responsible for designing appropriate baselines for a Service. In addition, it identifies the relevant assets and Configuration Items (CIs) with inputs from the business change manager(s) and others who are responsible for delivering Services and maintaining business continuity.

During the initial stages of a project, the program or project office: y Administers the Configuration Management process. y Maintains copies of the documentation relevant to the CIs. y Controls the Release of CIs, following appropriate

approvals. y Transfers responsibility to Service Transition for the

Configuration Management of CI documentation. The program or project does this at defined release points for a Service and Service package.

Configuration Management Staff Roles

You must define and allocate responsibilities to individuals to review and approve assets and CIs across the Service Lifecycle and during deployment. You must develop role specifications for the Change Management, Service Asset, and Configuration Management teams. It is important to assign the Configuration Manager and other key roles at the earliest because these can be involved in the implementation. For some operational activities, Configuration Management requires staff who adopt a diligent approach and pay due attention to detail.


Table of Contents


The roles involved are: y Service Asset Manager:

o Works to achieve the overall objectives agreed with the IT Services Manager. In addition, the Service Asset Manager implements the organization’s Service Asset Management policy and standards.

o Evaluates efficiency and effectiveness within existing Asset Management systems and the design, implementation, and management of new/improved systems. In addition, this role estimates and plans the work and resources involved and monitors and reports progress against plan.

o Identifies the scope of Asset Management processes, functions, the items that you should control, and the information that you should record. In addition, the role develops Asset Management standards, plans, and procedures.

o Initiates an awareness campaign to win support for new Asset Management procedures. In addition, the role approves and communicates to the staff any Changes to Asset Management methods and processes before implementing them. The Service Asset Manager also plans, publicizes, and oversees the implementation of new Asset Management systems.

o Arranges staff recruitment and training.


Table of Contents


o Manages the evaluation of proprietary Asset Management tools and recommends the best tool that meets the organization’s budget, resource, timescale, and technical requirements.

o Manages and implements the Asset Management plan, principles, and processes.

o Agrees upon naming conventions to maintain the unique identity of assets.

o Ensures that the staff comply with identification standards for object types, environments, processes, Lifecycles, documentation, versions, formats, baselines, Releases, and templates.

o Plans interfaces with the Change Management, Problem Management, Network Management, Release Management, computer operations, logistics, finance, and administration functions.

o Plans and manages the population of the asset database, central libraries, and tools and ensures regular housekeeping of the asset database.

o Provides reports such as management reports, Impact analysis reports, and Asset status reports.

o Initiates actions that help secure funds to enhance infrastructure and staffing levels to cope with growth and change.


Table of Contents


o Assists auditors to audit the Asset Management team activities to check for compliance with laid-down procedures and ensures that the team takes corrective action.

y Configuration Manager: o Works to achieve the overall objectives agreed

with the IT Services Manager and implements the organization’s Configuration Management policy and standards.

o Evaluates efficiency and effectiveness within the existing Configuration Management System (CMS) and the design, implementation, and management of new/improved systems. In addition, the Configuration Manager role estimates and plans the work and resources involved and monitors and reports progress against plan.

o Agrees to the scope of Configuration Management processes, functions, items that are to be controlled, and information that is to be recorded. The Configuration Manager also develops Configuration Management standards, plans, and procedures.


Table of Contents


o Initiates an awareness campaign to win support for new Configuration Management procedures and approves and communicates to the staff any Changes to Configuration Management methods and processes before implementing them. The Configuration Manager also plans, publicizes, and oversees the implementation of the new CMS.

o Arranges staff recruitment and training. o Manages the evaluation of proprietary Configuration

Management tools and recommends the best tool that meets the organization’s budget, resource, timescale, and technical requirements.

o Manages and implements the Configuration Management plan, principles, and processes.

o Agrees upon naming conventions to maintain the unique identity of CIs.

o Ensures that the staff comply with identification standards for object types, environments, processes, Lifecycles, documentation, versions, formats, baselines, Releases, and templates.

o Proposes and/or agrees to interfaces with the Change Management, Problem Management, Network Management, Release Management, computer operations, logistics, finance, and administration functions.


Table of Contents


o Plans the population of the CMS, manages the central libraries, tools, common codes, and data, and ensures regular housekeeping of the CMS.

o Provides reports such as management reports, Impact analysis reports, and configuration status reports.

o Initiates actions that help secure funds to enhance the infrastructure and staffing levels to cope with growth and change.

o Assists auditors to audit the activities of the Configuration Management team to check for compliance with laid-down procedures and ensures that the team takes corrective actions.

y Configuration Analyst: o Defines the scope of the Asset and Configuration

Management processes, functions, items that should be controlled, and information that should be recorded.

o Develops Asset and Configuration Management standards, plans, and procedures.

o Builds capacity among the Asset and Configuration Management specialists and other staff for principles, processes, and procedures.

o Supports the creation of the Asset and Configuration Management plans and principles and their implementation.


Table of Contents


o Creates Asset and Configuration Management processes and procedures, which include CI registration procedures, access controls, and privileges. Along with this, the role defines the correct roles and responsibilities in the Asset and Configuration Management plans and procedures.

o Agrees upon naming conventions to maintain the unique identity of CIs.

o Ensures that the developers and configuration system users comply with identification standards for object types, environments, processes, Lifecycles, documentation, versions, formats, baselines, Releases, and templates.

o Mediates with the configuration administrator/librarian and manages the population of the Asset and Configuration Management system. In addition, the role manages the central libraries, common codes, and data and ensures regular housekeeping of the Asset and Configuration Management system.

o Facilitates the Asset and Configuration Management system to carry out an Impact assessment for RFCs and ensures that the implemented Changes are as authorized. In addition, the role creates Change records, Configuration Baselines, and package release records to specify the effect of an authorized Change on CIs. The role also ensures that any changes to Change authorization records are subjected to Change Management procedures


Table of Contents


and that the Asset and Configuration Management system is updated when a Change is implemented.

o Uses the Asset and Configuration Management system to identify other CIs affected by a fault that is affecting a CI.

o Plans and performs configuration audits to evaluate if a physical IT inventory is consistent with the Asset and Configuration Management system and initiates any necessary corrective action.

o Creates and populates project libraries and the CMS. In addition, the Configuration Analyst checks items and groups of items into Configuration Management tools.

o Accepts and distributes baselined products from third-party stakeholders.

o Builds system baselines for promotion and Release. o Ensures that project status information and status

accounting records and reports are maintained. o Monitors and records Problems or test Incidents and

maintains a database for collecting and reporting on metrics.

y Configuration Administrator/Librarian: Controls and manages all the master copies of software, assets, and documentation CIs registered with Asset and Configuration Management. The major responsibilities of this role are:

o “Control the receipt, identification, storage, and withdrawal of all supported CIs


Table of Contents


o Provide information on the status of CIs o Number, record, store, and distribute Asset and

Configuration Management issues”


The Configuration Administrator/Librarian also: y “Assists Asset and Configuration Management to prepare

the Asset and Configuration Management Plan y Creates an identification scheme for Configuration

Management libraries and the Definitive Media Library (DML)

y Creates an identification scheme for Assets and the Definitive Spares (DS)

y Creates libraries or other storage areas to hold CIs y Assists in the identification of products and CIs y Maintains current status information on CIs y Accepts and records the receipt of new or revised

configurations into the appropriate library y Archives superseded CI copies y Holds the master copies y Administers configuration control process:

o Distributes Change requests to individual team members for Impact assessment

o Validates completeness of change requests o Routes Change requests to appropriate authority for

approval


Table of Contents


o Progresses and tracks Change requests through to completion

o Reports on Change requests o Records decisions about Change requests o Issues copies of products for review, Change,

correction or information when authorized o Maintains a record of all copies issued o Notifies holders of any Changes to their copies o Collects and retains information that will assists in the

assessment of what CIs are impacted by a product Change

y Produces configuration status accounting reports y Assists in conducting configuration audits y Liaises with other configuration libraries where CIs are

common to other systems”

(Source: Service Transition book) y CMS/Tools Administrator:

o Assesses proprietary Asset and Configuration Management tools and advocates the one that meets the organization’s budget, resource, timescale, and technical requirements. It also creates proprietary tools to produce effective Asset and Configuration Management environments in terms of databases, software libraries, workflows, and report generation.


Table of Contents


o Monitors the performance and capacity of the existing Asset and Configuration Management system, suggests opportunities for enhancement, and undertakes standard housekeeping and fine-tuning under Change control.

o Mediates with the Configuration Analyst and Administrator/Librarian on the population of the Asset and Configuration Management system. The role provides technical administration and support for the Asset and Configuration Management system, central libraries, common codes of tools, and data and undertakes regular technical housekeeping of the Asset and Configuration Management system.

o Ensures the integrity and operational performance of the CMS.

y Change Manager: o Accepts, logs, and allocates a priority level to all

RFCs and rejects the impractical ones. o Prepares all RFCs for a Change Advisory Board

(CAB) meeting, issues the agenda, and circulates all RFCs to CAB members before meetings to allow for prior consideration.

o Determines the participants of meetings, who receive specific RFCs based on the nature of the RFC, the required Changes, and their areas of expertise.

o Convenes urgent CAB or Emergency CAB (ECAB) meetings for all urgent RFCs.


Table of Contents


o Heads all CAB and ECAB meetings. o Authorizes acceptable Changes after considering

the advice of the CAB or ECAB. o Issues Change schedules through the Service Desk. o Mediates with all necessary parties to coordinate

Change building, testing, and implementation. o Updates the Change log with all progress records. o Reviews all implemented Changes to ensure that

they have met their objectives. o Reviews all outstanding RFCs waiting for

consideration or action. o Analyzes Change records to determine any trends or

apparent Problems that occur and seeks rectification by relevant parties.

o Closes RFCs. o Brings out regular and accurate management reports.

y Performance and Risk Evaluation Manager: o Utilizes Service Design and Release Packages to

develop an evaluation plan to input to Service testing. o Identifies Risks and issues associated with all aspects

of Service Transition through Risk workshops. o Brings out evaluation reports to input to Change

Management.


Table of Contents


y Service Knowledge Management: Requires effective and authoritative ownership within an organization. As a result, the Knowledge Management Process Owner role, who designs, delivers, and maintains the Knowledge Management strategy, process, and procedures, is crucial.

o Knowledge Management Process Owner: The Knowledge Management Process Owner: � Ensures compliance with the organization’s

policies and processes. � Architects knowledge identification, capture, and

maintenance. � Identifies, controls, and stores information that is

relevant to the Services provided and that is not available by any other means.

� Ensures updates for controlled knowledge items. � Ensures the efficient accessibility of all knowledge

items to those who need them. � Monitors the publicity of knowledge information to

check for duplication of information, is recognized as a central source of information, and so on.

� Advises business and IT personnel on Knowledge Management matters, including policy decisions on storage, value, worth, and so on.


Table of Contents


y Service Test Manager: Is responsible for handling the test support and test team(s) functions for specific Service Transition. The role reports to the Service Transition Manager. Separate people should perform the Service Test Manager role and the Release and Deployment Manager role. It is important that you do not combine these roles so that you always have independent testing and test verification. The Service Test Manager:

o “Defines the test strategy o Designs and plans testing conditions, test scripts, and

test data sets to ensure appropriate and adequate coverage and control

o Allocates and oversees test resources, ensuring that they adhere to the test policies

o Provides management reporting on test progress, test outcomes, success rates, issues, and Risks

o Conducts tests as defined in the test plans and design o Records, analyses, diagnoses, reports, and

manages test Events, Incidents, Problems, and retest dependent on agreed criteria

o Manages test environment requirements o Verifies tests conducted by Release and deployment

teams o Administers test Assets and components”



Table of Contents


y Release and Deployment Manager: Manages all aspects of the end-to-end Release process. The Release and Deployment Manager and the Service Test Manager report to the Service Transition Manager. It is important that you do not combine these roles so that you always have independent testing and test verification. In addition to the above responsibilities, the Release and Deployment Manager:

o Plans, designs, builds, configures, and tests all the software and hardware required to create a Release Package. The Release Package is used to deliver or make Changes to the designated Service.

o Manages all aspects of the end-to-end Release process.

o Ensures that the Service Knowledge Management System (SKMS) and CMS are up to date.

o Coordinates the build and test environment and Release teams.

o Ensures that all teams follow the set policies and procedures of the organizations.

o Reports Release progress to the management. o Builds Service Release and Deployment policies and

plans. o Manages the design, build, and configuration of the

Release Package. o Ensures Release Package acceptance, including

business sign-off.


Table of Contents


o Manages Service rollout planning, including the deployment method.

o Manages Release Package testing to the set criteria for acceptance.

o Signs off the implementation Release Package. o Manages communication, preparation, and training. o Ensures audits for hardware and software before

and after the implementation of Release Package Changes.

o Manages hardware installations, both new and upgraded.

o Ensures the storage, traceability, or auditability of controlled software, in both centralized and distributed systems.

o Manages the Release, distribution, and installation of packaged software.

y Release Packaging and Build Manager: Establishes requirements, designs, builds, tests, deploys, operates, and optimizes to deliver applications and infrastructure that meet Service Design requirements. The Release Packaging and Build Manager:

o Sets the final Release configuration, for example, knowledge, information, hardware, software, and infrastructure.

o Creates the final Release delivery package.


Table of Contents


o Tests the final delivery before the product is tested independently.

o Establishes and reports Known Errors that are not yet resolved and Workarounds.

o Provides input to the final implementation sign-off process.

y Deployment staff: Have the following responsibilities: o “Deals with the final physical delivery of the Service

implementation. o Coordinate Release documentation and

communications, including training and customer, and Service Management and technical Release notes

o Plan the deployment in conjunction with Change and Knowledge Management and SACM

o Provide feedback on the effectiveness of the Release o Provide technical and application guidance and

support throughout the Release process, including Known Errors and Workarounds

o Record deployment metrics to ensure that they are within agreed Service Level Agreements (SLAs).”



Table of Contents


y Early Life Support staff: Are considered a vital part of the Release and Deployment phase. ELS should start before a Service is operational. The ELS staff:

o Provide IT Service and business functional support before a Service is finally accepted by Service Operations.

o Ensure the delivery of proper support documentation. o Furnish Release acceptance for ELS. o Provide initial support for Incidents and errors

detected within a new or changed Service. o Adapt initial usage elements, such as

� User documentation and support documentation, including Service Desk scripts.

� Data management, including archiving. o Introduce activities for a new or changed Service. o Manage the formal transition of the Service to the

Service Operations and CSI phases of the Service Lifecycle.

o Monitor Incidents and perform Problem Management during Release and Deployment along with raising RFCs, when required.

o Create initial performance reporting and assess performance-based Service Risk.


Table of Contents


y Build and Test Environment Management: Ensures that the relevant people have the required environments, test data, and versioned software, when required. This role coordinates the use of testing resources to ensure their maximal use. In addition to the above responsibilities, the Build and Test Environment staff:

o “Ensure and builds Service infrastructure and application as per design specification

o Plan acquisition, builds, implements, and maintains Information and Communications Technology (ICT) infrastructure

o Ensure that the build delivery components are from controlled sources

o Develop an integrated application software and infrastructure build

o Deliver appropriate build, operations, and support documentation for the build and test environments prior to handover to Service Operations

o Build, deliver, and maintain required testing environments.”



Table of Contents


Configuration Control BoardThe Configuration Control Board ensures and employs the dominant intention and policies of Configuration Management throughout the Service Management Lifecycle and with specific consideration to all aspects of the complete Service. The Configuration Control Board:

y “Defines and controls the Service Configuration Baselines in terms of core and support Services, applications, information, Service, technical, and infrastructure-ensuring that they meet the requirements defined in the Service Design

y Reviews Changes in the Service configuration for compliance with standards, contractual, and internal requirements

y Creates requirement Changes for Service configuration to comply with contract Change requests”


However, in some organizations, the Configuration Control Board is combined with Change. This provides a holistic view of the current and proposed Services and Service Models and enables better control, Change evaluation, Impact assessment, and understanding.


Table of Contents


The Change AuthorityThe Change authority can be a role, person, or group of people that provides formal authorization for each Change.

You can judge the authorization levels for a particular type of Change by its type, size, or Risk.

example of Authorization LevelsIn a large enterprise, you might need to get authorization for Changes that affect several, distributed sites from a higher-level Change authority, such as a Global Change Board or the Board of Directors.

At times, the organizational culture also dictates the Change authorization. If the organization has a hierarchical structure, it may impose many levels of Change authorization while flatter structures allow for a more streamlined approach.

You might also have a degree of delegated authority within an authorization level.


Table of Contents


example of delegated AuthorityWhen you delegate authority to a Change Manager according to preset parameters relating to:

y “Anticipated business Risk y Financial implications y Scope of the Change, (e.g. internal effects only, within

the finance Service, specific outsourced Services).”


The CABThe CAB supports the authorization of Changes and assists Change Management in the assessment and prioritization of Changes. Potential members include:

y “Customer(s) y User manager(s) y User group representative(s) y Applications developers/maintainers y Specialists/technical consultants y Services and operations staff, e.g. Service Desk, test

management, IT Service Continuity Management (ITSCM), security, capacity

y Facilities/office Services staff (where Changes may affect moves/accommodation and vice versa)


Table of Contents


y Contractor’s or third parties’ representatives, e.g. in outsourcing situations

y Other parties as applicable to specific circumstances (e.g. police if traffic disruptions likely, marketing if public products affected).”


It is important to emphasize that the CAB: y “Will be composed according to the Changes being

considered y May vary considerably in make-up even across the range

of a single meeting y Should involve suppliers when that would be useful y Should reflect both users’ and customers’ views y Is likely to include the Problem manager and Service level

manager and customer relations staff for at least part of the time.”


Test supportThis team provides independent testing for all components delivered as part of Service Transition. Other factors to note about test support are:

y “The Change manager is responsible for ensuring that tests are developed appropriate to approved Changes and that agreed testing strategy and policy is applied to all Changes.


Table of Contents


y Test analysts carry out the tests as set out in the testing plans and/or Service package.

y The developer/supplier is responsible for establishing the root cause of test failures – the fault in the Service component that made the test fail. For complex situations, this may require collaboration between testing staff and development/build/supplier personnel. It should always be accepted as a possibility that faults can lie within the testing design as well as within design/development.

y Service Design will design the test, as an element of the overall Service Design. For many Services, standard tests will exist, perhaps contained within the transition model chosen as already accepted as appropriate for the type of new or Changed Service under consideration.

y Customers and users perform customer and user acceptance testing. Such user resource should be able to cover the full range of user profile and requirements, and adequately sign off the conformance of a new or Changed Service. Users will already have played a major role in helping to design the acceptance testing approaches during the design phase. Defines the test strategy”



Table of Contents


release and deployment managerThe Release and Deployment Manager delegates some responsibility to the relevant Release team subprocess. Items that are delegated are:

y Service documentation, including Service Portfolios, Service Catalogues, SLAs, Operational Level Agreements (OLAs), and Underpinning Contracts (UCs)

y In-house creation of application programs y Software developed by vendors, including customized

software, standard, off-the-shelf software, and Utility software

y Hardware and its specifications y System software provided by the supplier y Assembly instructions, documentation, and user manuals

The Release and Deployment Manager also manages all deliverables, right from their purchase or development to their configuration and implementation.

Interface of Release Packaging and Build Managers with Other Functions

To perform all their responsibilities efficiently, Release Packaging and Build Managers interface with other functions, such as:

y “Security management y Test management y Change Management and Service Asset and

Configuration Management


Table of Contents


y Capacity Management y Availability Management y Incident Management y Quality Management”



5.3 orgANIzATIoNAL CoNTexT for serVICe TrANsITIoN


Table of Contents


Organization

ABC

BusinessO

perationsProgram

and Project

Managem

ent

Project/Program

Support O

ffice

Project Changeand Configuration

Managem

ent

Project 1Project 2

Project 3

RFCs fromprojects, form

alhandover of CIs

ServiceDesign

Planningand Support

ServiceTransition

ServiceO

perations

IT ServicesO

rganization

Suppliers

RFCs formal

handover of CIs

Service Changeand Configuration

Managem

ent

ServiceKnowledge

Managem

ent

ServiceRelease andDeploym

ent

Service TestM

anagement

Adapted from exam

ple of service Transition organization and its interfaces ©


GC


Table of Contents


The given diagram depicts an example of a Service Transition organization and its interfaces. Service Transition Organization and its Interfaces

To implement a successful and effective Service Transition process, it is important to define interfaces and handover points with respect to Service Transition, other organizational units, and third parties. To ensure compliance with Service Design requirements, SLAs, and contracts for the delivery of Services, Service Transition requires Change initiations and Service Asset and components delivery from programs, projects, Service Design, and suppliers.

You must clearly define all interfaces with projects and business operations. In the Service Management Lifecycle, it is important to clearly understand that neither element can work in isolation. Projects must be clear about Service Design, Transition, and Operation requirements and delivery objectives and vice versa.


Table of Contents


• Service Transition Managem

ent• Planning and Support• Change and SACM• Evaluation• Service Knowledge M

anagement

• Service Validation and Test• Release and Deploym

ent

SM

PO

C = S

erviceM

anagement P

oint of Contact

Program

me and

Project D

irector

Project S

upport

CB

Project A

Service P

ortfolio Managem

ent

Service P

rovider D

irector

SM

PO

C

Service

Operations

Service D

esk

TechnicalA

rchitectureand

Managem

ent

Application

Architecture

andM

anagement

Service

Architecture

andM

anagement

Service D

esign

Service Transition

IT Operations

Control

FacilitiesM

anagement

Adapted from

organizational interfaces for a service Transition

© C

rown C


OG

C


Table of Contents


A successful service Transition Process You must maintain mutual cooperation, respect, and understanding to ensure the optimized delivery of new or changed Services to customers. Interactions among programs, projects, Service Management elements, business, customers, and users play a vital role in implementing a successful Service Transition process, as depicted in the given diagram.

5.4 reLATIoNshIP of serVICe TrANsITIoN WITh oTher LIfeCyCLe PhAses

Flow of experience and support

Service TransitionService Design Service Operation

Adopted from flow of experience © Crown Copyright 2007 Reproduced under licence from OGC

relationship of service Transition with other Lifecycle PhasesAlthough Service Transition appears to be a separate stage in the Lifecycle, it is important to understand that Service Transition cannot work alone. It exists to deliver the concepts documented within Service Design to Service Operations for day-to-day management. Consequently, if there is no design and operation, Service Transition has no purpose of its own.


Table of Contents


You can define Service Transition by taking inputs from the organization’s strategy and from the new or changed Services that it has helped to transition into live operations. Consequently, Service Transition is dependent on its relationship with “upstream areas.”

service Transition staffThe staff in most organizations deliver the tasks that are relevant to multiple Lifecycle stages. Consequently, the skills and experience of the Service Transition and Service Operation staff are valuable in the stages upstream of their normal focus.

In particular, Service Transition depends on the appropriate experience of the Service Operations staff to deliver most of the knowledge required to make key decisions.

When Service Design initiates a correct transition approach, and when, within Service Transition, you assess the approach for continued viability, Service Transition and Service Operation could be the best subject matter experts. In addition, Service Transition and Service Operation provide input to assess and evaluate the design’s initial and ongoing viability.

The Service Operation team is involved in Design and Operations tasks directly via the population of the SKMS with precedents and experiences detected through Incident-Problem-error cycles. This facilitates effective Service Transition and results in informed and correct decision-making.

To utilize the knowledge gained through experience, the staff can be fully or partially allocated from operations tasks to support


Table of Contents


a design exercise and then follow that Service through Service Transition. The staff then move to supporting the new or changed Services, which they have been designing and implementing in the live environment through ELS.

Process CommunicationThe Service capabilities that require testing and acceptance with transition are established and approaches and measures are set within design. As stated earlier, the Service Transition staff are involved in this activity, directly, through formal secondment, or through consultation and expert advice.Most elements initiated or perfected during Service Transition are established, becoming key elements within Service Operation.

service Transition InputsDuring transition, you detect the testing Incidents that reveal errors within the new or changed Service. The types of errors and their resolution give you direct input to the Service Operations procedures for supporting the new or changed Service when used live. The inputs from Service Transition affect most areas of the operations stage.


Table of Contents


example of shared Processes with operationsThe testing phase shares processes with operations, probably with some variations in procedure, such as if the testing phase wants to accommodate different requirements and Risk environments to analyze and rectify errors in the test and live environments.

In situations where new or changed Services throw up errors during testing and if these errors do not affect the Release of the Service, the errors are released into the live Known Error Database (KEDB). You also need to pass a notification to CSI through the SKMS.




Table of Contents

ITIL v3 Intermediate Certification Level | ST | Technology Considerations

uNIT 6: TeChNoLogy CoNsIderATIoNsoverviewTechnology plays a major role in Service Transition. As a result, you should use specific technology design mechanisms to maintain and maximize benefit from that technology.

You can provide technology support to Service Transition in two ways:

y Implement enterprise-wide tools to support the systems and processes within which Service Transition delivers support.

y Implement tools specifically to support Service Transition or its components.


y Understand the goals of technology considerations for Service Transition.

y Identify technology requirements. y Apply Knowledge Management tools. y Review collaborative activities. y Analyze the given business situation to identify the

Configuration Management System (CMS) functions required.


Table of Contents


6.1 goALsgoalsThe following are the goals of technology considerations:

y Deliver constructive support for effective Service Transition.

y Discuss the technology considerations for Service Transition.

y Discuss the technology requirements for the support and integration of Service Transition in the Service Lifecycle.

At the end of the unit, you will be familiar with the technology considerations and requirements for Service Transition.

6.2 serVICe TrANsITIoN TeChNoLogy reQuIremeNTssupport systems of service TransitionTo ensure effective and successful Service Transition, you need to implement various systems, technologies, and tools such as IT Service Management (ITSM) technologies and tools.

Some of the systems that provide automated support for the overall management of Service Transition are:

y “ITSM systems: o Enterprise frameworks that provide integration

capabilities to integrate and link in the Configuration Management Database (CMDB) or tools


Table of Contents


o System, network and Application Management tools o Service dashboards and reporting tools

y Specific ITSM technology and tools that cover: o Service Knowledge Management System (SKMS) o Collaborative, content management, workflow tools o Data mining tools o Extract, load and transform data tools o Measurement and reporting systems o Test management and testing tools o Database and test data management tools o Copying and publishing tools o Release and deployment technology o Deployment and logistics systems and tools”


Tools for Change management, Configuration management, and release managementIn addition, various tools support and assist Change Management, Configuration Management, and Release Management. Some of these tools are:

y “Configuration Management Systems (CMS) and tools y Version control tools y Document-management systems


Table of Contents


y Requirements analysis and design tools, systems architecture and CASE (Computer Assisted Software Engineering) tools, which can facilitate Impact analysis from a business perspective

y Database management audit tools to track physical databases

y Distribution and installation tools y Comparison tools for software files, directories, databases y Build and Release tools that provide listings of input and

output Configuration Item (CIs) y Installation and de-installation tools that provide listings of

CIs installed y Compression tools to save storage space y Listing and Configuration Baseline tools, for example full

directory listings with date–time stamps and check sums y Discovery and audit tools that are also known as

“inventory” tools y Detection and recovery tools where the build is returned to

a known state y Visualization, mapping and graphical representations with

drill down y Reporting tools including those that access objects from

several databases, providing integrated reports across systems”



Table of Contents


6.2.1 KNoWLedge mANAgemeNT TooLsA C T I V I T y I N W o r K B o o K

Knowledge management ToolsEach organization needs to track and maintain records. Knowledge Management tools help you electronically maintain records and documents, enabling you to manage information.

Documents differ from records in that they are evidence of intentions while records are evidence of activities. As a result, Knowledge Management includes document management, records management, and content management.

ITIL defines document management as:

“The set of capabilities to support the storage, protection, archiving, classification and retirement of documents and information.”


ITIL defines records management as:

“The set of capabilities to support the storage, protection, archiving, classification, and retirement of records.”


ITIL defines content management as:

“The capability that manages the storage, maintenance, and retrieval of documents and information of a system or website. The result is often a knowledge Asset represented in written words,


Table of Contents


figures, graphics and other forms of knowledge presentation.”


example of Knowledge servicesSome examples of Knowledge Services that support content management are:

y “Web publishing tools y Web conferencing, wikis, and blogs y Word processing y Data and financial analysis y Presentation tools y Flow-charting y Content management systems y Publication and distribution”


6.2.2 CoLLABorATIoNA C T I V I T y I N W o r K B o o K


Table of Contents


CollaborationYou can define collaboration as the process of sharing implicit knowledge and working together to fulfill set goals and objectives.

Groups of people spread across the globe choose to form communities to communicate, collaborate, and share knowledge.

Community featuresSome of the common features of communities are:

y They are facilitated online through an intranet or extranet. y They often elect a leader to manage and run the

community. y They include a group of subject matter experts to

contribute and evaluate knowledge assets within the community.

y Communities provide a host of Services and functions, such as:

o Community portals o E-mail alias management o Focus groups o Intellectual property, best practices, work examples,

and template repository o Online events and net shows

y Successful communities have rewards and recognitions for the contribution of valuable knowledge assets by community members.


Table of Contents


Knowledge sharingIt is important for the senior management to actively participate in communities to create an environment that encourages knowledge sharing and collaboration. This enables knowledge sharing for a successful Service Transition practice.

In any collaboration Service, there is usually a huge contribution of knowledge assets from members and subject matter experts. To manage these knowledge assets, you can implement workflow management. In this approach, you use predefined workflows or processes to create, modify, enhance, communicate, and approve knowledge assets.

services of Workflow managementSome of the typical Services that workflow management offers are:

y Workflow design y Routing objects y Event Services y Gate keeping at authorization checkpoints y State transition Services

Let us consider the example of a Request for Change (RFC) to understand the benefit of implementing workflow management in Service Transition.


Table of Contents


example of an rfCAn RFC is a knowledge asset that goes through a workflow, enabling you to create, modify, assess, estimate, approve, and deploy a Change. In this example, the workflow helps you achieve the expected results of the Change.

6.2.3 CoNfIgurATIoN mANAgemeNT sysTem


Table of Contents


Portal

Change and releaseView

Schedules/plansC

hange Request

Status Change

Advisory Boardagenda and m

inutes

Asset managem

entView

Financial Asset, AssetStatus R

eports, AssetStatem

ents and Bills,Licence M

anagement,

Asset performance

Configuration LifeCycle View

Project configurationsService Strategy,

Design, Transition,

Operations

configurationbaselines and changes

TechnicalConfiguration

View

Service ApplicationsApplication

Environment Test

Environment

Infrastructure

service desk ViewU

ser assetsU

ser configuration,C

hanges, Releases,

Asset and Configuration

item and related

incidents, problems,

workarounds, changes

Knowledge

Processing Layer

Information

Integration Layer

data and Inform

ation sources and

Tools

Query and

Analysisreporting

Performance m

anagement

Forecasting, Planning, Budgetingm

odelingm

onitoring Scorecards, D

ashboards Alerting

Business/Custom

er/Supplier/User – Service – Application – Infrastructure m

apping

Service PortfolioService Catalogue

Service Model

Integrated CmdB

Service ReleaseService Change

Com

mon Process, D

ata, and Inform

ation Model

Schema

Mapping

Meta Data

Managem

entD

atareconciliation

Data

synchronizationExtract, Transform

, Load

Mining

data IntegrationPlatform

Configuration Tools

E.g. Storage Database

Middlew

are Netw

orkM

ainframe

Distributed D

esktopM

obile

Software

Configuration

Managem

ent

Discovery,Asset

Managem

entand audit

tools


Access Managem

entH

uman R

esourcesSupply C

hainM

anagement

Custom

er Relationship

Managem

ent

Project D

ocument

Filestore

Project Software

Definitive M

edia Library

Definitive D

ocument

Library

Definitive M

ultimedia

Library 1

Definitive M

ultimedia

Library 2

structured

Physical CM

DBs

CM

DB1

CM

DB2

CM

DB3


Quality

managem

ent ViewAsset and

Configuration

Managem

ent Policies, Processes,

Procedures, forms,

templates, checklists

Presentation Layer

Adapted from example of a Configuration m

anagement system

© C

rown Copyright 2007 R


GC


Table of Contents


Configuration management ToolFor Configuration Management, you should ideally use a software tool that is capable of maintaining a CMS. You should record and maintain details of all CIs and their relationships in the CMS. At times, based on business requirements, you may also need to integrate several tools to have an automated solution for Configuration Management across platforms. An example of this type of integrated tool is a federated CMDB. In an ideal situation, any CMDB is linked to the Definitive Media Library (DML). Some examples of situations in which the automated update of the CMS is useful include the transfer of software across libraries, for example, when software moves from development to test, to live, and so on and for Changes in Service Catalogues and Release distributions.

Cms featuresThe CMS that you implement should prevent Changes to CIs without prior authorization by Change Management. Ensure that the status of all changed CIs is automatically updated, for example, live and archive. In addition, the CMS should provide the following features:

y Security controls to limit access to CIs y Support for CIs of varying complexity, such as CIs for

systems, Releases, single hardware items, or software modules

y Hierarchy and network relationships between CIs, including parent CIs and child CIs


Table of Contents


y Unconstrained addition and deletion of CIs y Automatic checking and validation of input data y Automatic establishment and determination of all

relationships when new CIs are added y Support for CIs with different model numbers, version

numbers, and copy numbers y Automatic identification of affected CIs when there is an

Incident, Problem, Known Error, or RFC for any CI y Integration of Problem Management data within the CMS y Automatic updating and recording of the changed version

number of a CI y Maintenance of the history of all CIs y Support for the management and use of Configuration

Baselines y Easy CMS interrogation and reporting facilities, such as

trend analysis y Easy, flexible, and effective reporting tools to facilitate

configuration audits and Impact analysis y Graphical depiction of models and maps of interconnected

CIs, including relationships

Tools for Lifecycle stagesIdeally, you should use the same ITSM tool to control all stages of the Lifecycle. However, if this is not possible, the ITSM infrastructure Configuration Management tool should enable the automatic transfer of Configuration Management information from a software development CMS into the CMS.


Table of Contents


It can be beneficial if you integrate the individual tools and solutions with the main Service Management system or CMS. In addition, you can automate the initial discovery of CIs and their relationships and configuration audits to enhance the efficiency and effectiveness of Configuration Management. These tools are helpful to determine the installed hardware and software and the way applications are planned with infrastructure. In situations where the DML is not integrated with the CMDB, you may consider automating the comparison of the contents of the DML with those of the Configuration Management Database (CMDB).





Table of Contents

ITIL v3 Intermediate Certification Level | ST | Implementing and Improving Service Transition

uNIT 7: ImPLemeNTINg ANd ImProVINg serVICe TrANsITIoNoverviewService Transition helps you transfer control of Services between customers and Service Providers. At times, you may need to implement Service Transition in a situation where it does not exist currently. These situations might arise when you establish a new Service Provider. On the other hand, when you have existing Service Providers, you need to ensure that the Service Providers implement mechanisms to:

y Improve Service. y Establish effective and efficient improvement plans based

on the business benefit.

A new or improved Service Transition process leads to significant organizational Change. In addition, it improves the Services that the Service Provider delivers.


y Understand the goals of implementing Service Transition. y Demonstrate the stages of introducing Service Transition

to an organization. y Analyze the Critical Success Factors (CSFs) and Key

Performance Indicators (KPIs) of a Service Transition implementation.


Table of Contents


y Identify the challenges and Risks that affect the probable viability of new and changed Services.

y Identify the external factors that affect the approach to Service Transition.

7.1 goALsgoalsThe goals of this unit are:

y Deal with the implementation and improvement of Service Transition in an organization.

y Cover the stages of introducing Service Transition to an organization.

y Discuss the CSFs, KPIs, and challenges involved in implementing and improving Service Transition.

At the end of the unit, you will be familiar with the basic concepts and challenges involved in implementing and improving Service Transition. In addition, you will be familiar with the stages of introducing Service Transition to an organization.

7.2 sTAges of INTroduCINg serVICe TrANsITIoN


Table of Contents


Where are w

e now?

Where could w

e be?

What shall w

e do?

Implem

ent the im

provement plans

Evaluate new perform

ance

Com

pare with best practice,

legislation, policy etc.

Consider constraints

– time

– money

– resources

Develop plans, schedule

and allocate resources

Monitor and review

Adapted from Steps to im

proving Service Transition processes ©


GC


Table of Contents


Improving service TransitionMost Service Provider organizations are continuously involved in Service improvement. To do this, they assess their current approach to Service Transition processes and try to establish the most effective and efficient improvements that will provide the maximum business benefit.

Let us see how to improve the Service Transition processes.

stages of Introducing service TransitionThe stages of introducing Service Transition to an organization are similar to the stages of introducing other Services to an organization. The stages are:

y Justify Service Transition.

y Design Service Transition.

y Introduce Service Transition.

We will cover each of these stages in detail in the subsequent subtopics.

7.2.1 jusTIfICATIoNA C T I V I T y I N W o r K B o o K


Table of Contents


justifying service TransitionService Transition enables you to improve the Service Provider’s ability to deliver quality Services to the business. They are the link between the design and day-to-day operations. However, you may not be able to justify Service Transition to customers because it is not always visible. As a result, when you implement Service Transition, you must ensure that you:

y Set up Service Transition in a way that helps you quantify and measure the benefits of this process.

y Justify a balance between the Impact to the business, which could be either negative or positive, and the cost, which is in terms of money and staff resources.

Addressing service Transition Cost IssuesWhen you gather details of the current Service Transition cost, you address issues such as:

y “Cost of failed Changes y Extra cost of actual transition compared with budgeted

costs y Errors found in live running that could have been detected

during test transition”



Table of Contents


7.2.2 desIgNfactors for designing service TransitionWhen designing Service Transition, you need to consider various factors, such as:

y Applicable standards and policies y Relationships y Budgets and resources

Let’s discuss these factors now.

Applicable standards and PoliciesPolicies, standards, and legislations can shape the design of Service Transition. The factors that you need to consider include independence and visible accountability requirements, such as controlling financial sector companies or within legislation, for example, Sarbanes-Oxley (SOX).

relationshipsService Transition must work and maintain relationships with various entities, such as:

y other internal support services: Service Transition might need to work with other areas that transition the other elements of a business Change, for example HR, facilities management, telecommunication, production control, education, and training. Consequently, for successful Service Transition, you must:

o Use the processes that are designed to support these relationships.


Table of Contents


o Define the responsibility and ownership of each component in the Service Package.

y Program and Project management: You can manage many transitions if programs, projects, and Service Transition perform their role diligently. However, you must define appropriate roles, responsibilities, and collaboration among programs, projects, and Service Transition. Everyone within the organization must agree to these responsibilities. To ensure effective and successful transition, you should:

o Involve the Service Transition staff in defining key program and project milestones and timelines. To do this, you need to set up Service Transition for this role. For example, if there is a Release at the end of the month, Service Transition must allocate resources to the baseline and ensure the timely Release of the Service Package. In addition, Service Transition must ensure that the Service Package meets the quality parameters that the customer defined.

o Combine transitions and Releases across projects to make the best use of available resources.

o Define and maintain an approach to deal with ongoing tasks for Service improvement. Service Transition must deliver, schedule, combine, and share resources per requirements.

o Define proper escalation channels that help the organization deliver a Service successfully.


Table of Contents


y Internal development teams and external suppliers: You must define and maintain proper communication channels between internal teams and external suppliers to deal with the defects, Risks, and issues detected during the transition process, for example, errors found during testing.

y Customers/users: You must communicate with customers and users regularly to ensure that the transitioned Service meets their business requirements. You can map the communication at the transition stage with the requirements identified at the design stage and the communication you had with the customer. At times, the communication with customers is routed through Service or account management or Service Level Management (SLM). However, you need to identify and design these channels into the Service Transition processes.

y other stakeholders: During Service Transition, you may need to interface with other stakeholders too. You must, consequently, identify situations, including disaster recovery scenarios, and liaise with IT Service Continuity Management (ITSCM), as appropriate. Some other factors you need to consider are:

o IT factors, such as networks, IT security, and data management

o Internal organization factors that are outside the scope of IT, such as facilities management, HR, and physical security


Table of Contents


o External factors with respect to the organization, such as landlords, police, and regulatory bodies

Budget and resourcesYou must identify, address, and control the financial source. All the tasks included in the successful transition of Services should benefit the organization. If not, you must revisit and revise these tasks. All these tasks require funding; consequently, you must establish a strategy that caters to this area. Costing and funding is an important and critical part of design. You must involve the transition team and customers when defining the cost. This will also help you analyze the business Risk that may arise because of budget and resources.

You must establish an approach to control funds in the transition process through the following:

y funding approach: This approach should consider: o Testing environments: Most organizations do not

include and control testing groups, including specialist testing aspects, such as usability testing, during transition. As a result, you must establish, maintain, and manage the relationship and authority to engage and allocate resources per the requirement. Managing the test environment is an expensive and important aspect in many organizations.

o Service Capacity Management and Service Knowledge Management Systems (SKMSs): These functions particularly require funding for technology and skills to improve their effectiveness.


Table of Contents


y resources: You also need to address and control resources during Service Transition. You must allocate staff and central infrastructure, such as central test data and network resources, as appropriate. Inappropriate funding and allocation of resources can cause huge losses to the organization during the support of the Services.

7.2.3 mANAgINg CuLTurAL ChANge, rIsKs, ANd BeNefICIAL VALuesIntroducing service Transition It is not advisable to introduce new transition practices in projects already under execution because this may unnecessarily disrupt the Service. However, if you have a transition that is causing many Problems to the Service, it would become relevant to force a Change.

You can introduce any new transition practices and techniques by capturing “in-flight” initiatives and aligning them with the new approach. With these new procedures, you must adjust the projects in the design and transition stages at the acceptance, test, or go-live stage. To do this successfully, you must consider, design, and possibly test the new procedures during the design stage.


Table of Contents


Cultural ChangeIn an organization, cultural Change can occur because of various reasons, such as formalization of procedures or implementation of new formal processes for transition. Most of the time, you can see that the staff working in any department are resistant to Change.

Consequently, you must: y Gain the support of the transition staff by explaining to

them the need for the Change and the benefit it would have on the individual and the organization.

y Ensure that such cultural Change programs address all stakeholders during and after the transition.

risks of service TransitionThere are various Risks and benefits involved in transitioning a Service. You must not take any decisions for Service Transition without understanding these factors. Some Risks you must consider for Service Transition are:

y “Alienation of support staff y Excessive costs to the business y Unacceptable delays to business benefits”



Table of Contents


Benefits of service TransitionYou need to measure the Changes, Risks, and beneficial values that require a baseline of the current situation. The measures that add value to Service Transition include:

y “Customer and user satisfaction y Reduced Incident and failure rates for transitioned

Services y Reduced cost of transitioning”


7.3 Csfs ANd KPIsA C T I V I T y I N W o r K B o o K

Csfs

Each organization strives to continually improve the quality of Service based on business requirements and, at the same time, make it cost effective. To do so, you should consider some CSFs for Service Transition:

y Understand and manage the perspectives of stakeholders to ensure effective Risk Management.

y Maintain contacts and manage the relationships between all entities during Service Transition.

y Integrate Service Transition with the processes and disciplines of the other Service Lifecycle stages that affect Service Transition.


Table of Contents


y Understand the inherent dependencies between legacy and new systems, including human elements.

y Automate processes to reduce cycle time and eliminate errors.

y Create and maintain an easily accessible knowledge pool. y Develop good-quality systems, tools, processes, and

procedures to manage a Service Transition practice. y Implement good Service Management and IT

infrastructure tools and technology. y Appreciate and exploit the cultural and political

environment. y Understand the Service, technical configurations, and their

dependencies. y Understand the processes, procedures, skills, and

competencies required to manage a Service Transition practice.

y Develop a workforce with the appropriate knowledge, skill sets, and Service culture.

y Define specific roles and their responsibilities. y Create an environment that fosters knowledge sharing. y Create and implement an improved cycle time to deliver

Change with minimum deviations in time, cost, and quality predictions.

y Ensure improved customer and user satisfaction ratings during Service Transition.


Table of Contents


y Demonstrate that the benefits of establishing and improving the Service Transition practice and processes outweigh the associated costs.

y Effectively communicate the organization’s approach to Risk Management during Service Transition activities.

y Understand and analyze the Risks that have impacted or may impact the successful Service Transition of the Services in the Service Portfolio.

KPIsThe primary KPIs are:

y “The number of Releases implemented that met the customer’s agreed requirements in terms of cost, quality, scope, and Release schedule, which is expressed as a percentage of all Releases

y Reduced variation of actual vs. predicted scope, quality, cost and time

y Increased customer and user satisfaction with plans and communications that enable the business to align their activities with the Service Transition plans

y Reduction in number of issues, Risks, and delays caused by inadequate planning

y Improved Service Transition success rate through improved scope and integration of the planning activities

y Better management information on the predicted vs. actual performance and cost of Service Transition


Table of Contents


y Improved efficiency and effectiveness of the processes and supporting systems, tools, knowledge, information and data to enable the transition of new and Changed Services, e.g. sharing tool licenses

y Reduction in time and resource to develop and maintain integrated plans and coordination activities

y Project and Service team satisfaction with the Service Transition practices”


7.4 ChALLeNges ANd rIsKs AffeCTINg NeW or ChANged serVICesA C T I V I T y I N W o r K B o o K

Challenges to successful service TransitionWithin e-business, IT not only supports the primary business processes but is also part of the primary business processes themselves. In addition, the complexity of Services across the supply chain is increasing. As a result, Service Providers face a wide range of challenges when implementing new Services or Changes.

Some of the common challenges to successful Service Transition are:

y Enable a huge customer group and all stakeholder groups, including almost every business process and Service that Service Transition impacts.


Table of Contents


y Manage multiple contacts, related processes, and relationships through Service Transition.

y Manage the lack of integration in the processes and disciplines that impact Service Transition, such as finance, engineering, and human resources.

y Manage the inherent differences between legacy systems and new elements, resulting in unknown dependencies.

y Maintain a balance between a stable production environment and Services that keep changing according to business needs.

y Maintain a balance between practical options (pragmatism) and organizational formalities (bureaucracy).

y Create an environment that promotes standardization, simplification, and knowledge sharing.

y Enable business Change and contribute to business Change programs.

y Establish leaders to lead the Changes and improvements. y Establish “who is doing what, when, and where” and “who

should be doing what, when, and where.” y Foster a culture that encourages people to collaborate and

work effectively. y Develop standard performance measures and

measurement methods across projects and suppliers. y Make sure that the quality of delivery and support matches

the business use of new technology.


Table of Contents


y Make sure that the Service Transition time and budget is not impacted by Events earlier in the Service Lifecycle.

y Understand the different stakeholder perspectives that underpin effective Risk Management.

y Understand and assess the balance between managing Risk and taking Risks because this affects the overall strategy of the organization and the potential mismatch between project Risks and business Risks.

y Evaluate the effectiveness of reporting in relation to Risk Management and corporate governance.

risks to service TransitionWhen you implement the Service Transition practice, you should identify the potential Risks to planned Services as well as to Services in transition. To identify the implementation Risks in Service Transition, perform a baseline assessment of current Service Transitions and planned projects.

Some of the common implementation Risks are: y “Change in accountabilities, responsibilities and practices

of existing projects that de-motivate the workforce y Alienation of some key support and operations staff y Additional unplanned costs to Services in transition y Resistance to Change and circumvention of the processes

due to perceived bureaucracy y Excessive costs to the business due to overly Risk averse

Service Transition practices and plans


Table of Contents


y Knowledge sharing (as the wrong people may have access to information)

y Lack of maturity and integration of systems and tools resulting in people ‘blaming’ technology for other shortcomings

y Poor integration between the processes- causing process isolation and a silo approach to delivering ITSM

y Loss of productive hours, higher costs, loss of revenue, or even business failure as a result of poor Service Transition processes”


7.5 exTerNAL fACTors AffeCTINg The APProACh To serVICe TrANsITIoNA C T I V I T y I N W o r K B o o K

difficulties While Implementing service TransitionSome difficult conditions in which you might have to implement Service Transition are:

y “Short timescale y Restricted finances y Restricted resource availability-not enough people or lack

of test environments, inadequate tools etc. y Absence of anticipated skills sets y Internal political difficulty, staff disincentives, such as:


Table of Contents


o Redundancy/outsourcing or similar threats o Difficult corporate culture of confrontational

management style o Internal rivalries and competitiveness o External difficulties, such as weather, political

instability, post-disaster, legislation”


Identifying Problems and risksAfter you anticipate potential Problems, you can identify measures to resolve and include them in the Service Package. You can also plan the route through transition within the transition model, as you would do for any other anticipated Risks and Problems.

However, most of these difficulties and Problems might be unanticipated because some of them arise due to changed circumstances. Consequently, you may have to adapt an “on-the-fly” approach. We will discuss some of the difficult situations where you might have to adapt, modify, or compromise some or all elements of this approach to resolve Problems.

A common element in most situations is ensuring that you understand the situation clearly. If you are clear about what is to be done, you will be able to handle the situation successfully. You might also come across more-difficult situations, where you have to prioritize and focus on specific aspects of the Service and customer base. However, delivering these aspects might require you to compromise other areas of the Service.


Table of Contents


One such difficult situation is when the implementation of a new or changed Service is more important than accuracy and smoothness. In other words, a situation might be so critical that you might have to implement a new or changed Service, regardless of the disruption it causes to the business. Risk Management takes the final decision in these situations and, consequently, general Risk Management principles apply in such cases.

factors of success during a service Transition ImplementationSome of the key factors that can assist you in this situation are:

y Empower the staff to take appropriate levels of Risk. In unstable industries, you must implement Service Transition such that it reflects the corporate Risk culture and does not suppress business Risk decisions.

y Define and share accurate deadlines for Service Transition delivery. In most cases, organizations build “safety margins,” which means that the product is delivered early even when there was scope for improvement. Sometimes, the staff might feel that there is some buffer when, in fact, there is not, resulting in missed deadlines. As a result, you must be very clear and honest when it comes to sharing timelines and schedules with your team.

y Identify the Service Transition components that must be available on the cut-off date and the components that you can add at a later stage.


Table of Contents


y Identify the level of independence and dependency of the components. In addition, you must identify the components that are required but are not initially on the “essentials” list.

y Identify the users, customers, locations, and other components in Service Transition that must be in place by the cut-off date.

y Identify and share the Impact of a failed Service, such as Impact on business, money, lives, reputation, and political embarrassment.

Crisis management rulesTo cope with such difficult situations, you must have some understanding of basic crisis management. The rules of crisis management are very different from those of normal, everyday management. According to writer Larry Niven, you can survive and reassure your staff if you are aware of the first two laws of crisis management.

The two rules are: y “Rule 1: Don’t panic. y Rule 2: A good crisis manager makes decisions instantly

and acts on them. If they later turn out to have been correct, so much the better, but speed is often more important than efficiency in a crisis situation.”



Table of Contents


factors of success in CrisesSuccess during crises depends on:

y empowerment and belief in organizational support: Your team must know of the organization’s empowerment levels and must believe that the organization will support them and not blame them for the crisis.

y open and rapid authorization channels: The organization must have agreed steps and actions when the channels do not function. For example, the organization can have increased delegated authority, escalation, or alternative support channels.

y Implementation of appropriate procedures after identification of risks: After identifying Risks, you must follow appropriate procedures to mitigate them so that the flexibility and speed of the Service are not constrained.

factors of success in Times of restricted resourcesAt times, you might face a situation when you have restricted resources or when the resources are in short supply. You must understand the situation, believe in yourself, know what to measure, and stick to your decision to deliver successfully. Some factors you can consider in this type of situation are:

y Identify the most important parameter in the situation, which could be speed, low cost, or any other parameter.

y Establish an applicable hierarchy of measures.


Table of Contents


y Build in the appropriate parameters. For example, if money is the parameter, involve budget holders and business decision-makers in the process.

y Ensure that the staff are aware of the requirements and document them. Implement a mechanism to ensure that the staff is informed quickly about Changes to the stated requirements.

Critical safety services You might also have to deliver critical safety Services in high-risk environments. IT Services that support and deliver Services that are critical are hospital services, emergency services, call taking, flood control, and aircraft “fly-by-wire.” Consequently, you must include extra security and foolproof approaches with additional features, such as:

y Appropriate documentation: This is important because it most often includes counter-signatures and extra checks on stage approval. However, if you include excessive documentation, it can be counter-productive. You can find high Risk in time-restricted situations, such as emergency services coordination. As a result, you might need to carefully balance safety and speed. In these situations, some major factors are skill and experience and/or extensive training of staff.

y Accuracy: Ensure that accuracy takes more priority over speed.


Table of Contents


y Testing: Implement rigorous testing for a longer time and collect and maintain detailed data within the Configuration Management System (CMS).

y Assessment of safety measures: Ensure that an accepted authority accurately assesses the safety measures.

y establishment of a sign-off authority: Ensure that a sign-off authority is established and that this authority is not influenced by unwanted pressures, such as company profit or staff bonuses, as opposed to Risk to human life.

y Involvement of more people for critical tasks: At times, you might have to involve multiple people to complete tasks successfully. For example, you require simultaneous confirmation by two trained officers to launch nuclear weapons.

y establishment of authority that has “veto” rights: You must establish an authority with “veto” rights, who can control and stop the implementation of any Service. For example, one of the dozen team members involved in the launch of a space shuttle can stop the launch by giving a “no-go” message.

Customer TypesYou must understand that there is no such thing as a bad customer. However, at times, you work with difficult customers who do not understand their roles clearly, so they act in a way that hinders successful implementation.


Table of Contents


Some type of customers: y Get too involved in the details of how things are done,

instead of judging by the Service delivered. y Do not make decisions or select options that suit their

business needs. y Do not provide adequate staff and resources for smooth

and effective Service Transition, for example, the customers do not provide data and staff to assess the transitioned Service or to effect user testing.

Improvements in handling difficult CustomersYou can improve situations with difficult customers by increasing the awareness and education of:

y “Customers y Users y Transition staff, with respect their patience and diplomacy

skills y Account management working with the customers to

reassure customers and ascertain their requirements y Careful budgetary control, so that customers can see the

value returning for their investment of staff time and other resources”



Table of Contents





ITIL v3 Intermediate Certification Level | ST | Case Study

Table of Contents

TheroyAL

ChAo PhrAyAhoTeL

The hoTeL ChALLeNges org. ChArT

mANAgemeNT & sTAff

Disclaimer: Any resemblance to real persons, living or dead, is purely coincidental.



Table of Contents

TheroyAL

ChAo PhrAyAhoTeL

The Royal Chao Phraya Hotel (nicknamed the Royal) is a city hotel situated on the banks of the Chao Phraya river in Bangkok.

Built in 1983 by the Chinese-Thai businessman, Teck-Wee Lim (Harry Lim to his friends), its 32 floors have been a fixture on the city skyline for almost 25 years. The Royal is modeled after its neighbor, the historic Oriental Hotel. Its dominance on the five-star hotel market is increasingly challenged by many newcomers, such as the Peninsular (1998) and the Royal Orchid Sheraton (remodeled in 2001), some with the backing of multinational brands.

As the competition has grown over the past 10 years, it is becoming more difficult to achieve the occupancy rate that the hotel is used to while maintaining its target room rates, which vary from $145 to $445.

Despite the newfound rivalry, the Royal is well appreciated by its guests, many of whom are repeat business customers.

As a rule of thumb, from May through October, the guests are mostly business visitors while November through April and most weekends tend to be dominated by tourists. The Royal has always had a considerable advantage over other five-star hotels through



Table of Contents

its connection with the Sephan Taksin Conference Center.

This is because the Revenue per Available Room (RevPar) from conference attendees is, on an average, 30-50% higher than that from regular hotel guests. This is especially true when conferences are organized for medical, legal, insurance, or IT professionals, who spend up to three times the amount a regular hotel guest does on lodging and ancillary services.

As a city hotel, the Royal depends on good access to public transport. It is less than 100 yards from Bangkok’s upscale sky train service (BTS), which allows guests to reach the most attractive parts of the city comfortably, quickly, and safely. It also has its own boat service offering guests river tours as well as trips to more exotic parts of the city, such as the floating market.



Table of Contents

FACTSHEET

Rooms 340

Standard 130

Sky View 80

Sky Executive 130

The average guest stays 3.5 days at the hotel.

} Suites 30

FACILITIES

Rating:

Business center, restaurants, bar, fitness center with sauna and spa, and outdoor pool

Signature restaurant Heavenly 33

Lobby bar Sugar Reef

Gentlemen’s smoking club Harry’s

Four restaurants Leased to outside companies



Table of Contents

PERSONNEL

Over 200 people work at the hotel, with only the front desk employing 70 people, 24 of whom work in shifts in guest services and reception.

The average staff attrition is 30% per year. So, on an average, a complete replacement of personnel is seen every 3 years. Of course, in reality, a core team of employees has worked at the hotel for many years. In fact, 32 staff members have celebrated over 20 years of service at the Royal.

The BusINess ChALLeNges ThAT LeAd To IT ChALLeNges

serVICe QuALITyThe General Manager (James) recently sponsored a thesis project on service quality from the Hospitality School of the University of Queensland at the hotel. The results were a shock to the management. In the1month that the project ran, 73 critical incidents resulting in unhappy guests were discovered.

The students found that 50% of the complaints concerned discrepancies in guest expectations and services offered. 35% were actual service failures, such as over-booking or the incorrect



Table of Contents

fulfillment of a guest’s request; and about 13% were described as “demanding guests” whose requests were excessive and whose judgment was harsh, even by objective, fair standards.

James and the Manager - Rooms Division (Dimitri) are particularly concerned about the 85% of complaints that were considered avoidable. Further analysis has revealed that 50% of these complaints originated in the early stages of the stay and, consequently, meant revenue was lost because clients opted to shorten their stay or cancel altogether.

The report also found that the Royal, while employing a number of gifted and highly motivated personnel, did not have a structured Service Recovery or Compensation plan. In fact, some of the complaints were because of the guests’ perception that some of them were treated differently (better) when they complained about similar incidents.

NeW forms of ComPeTITIoNThe Royal has made its mark as a city hotel, but its leading competitors from the chains are winning some of its clients by assembling different tourist experiences from their various Thai hotels into one package.

For example, some clients are spending 3 days in Bangkok and then a number of days in the luscious countryside of Chiang Mai with its vibrant local markets and elephant treks or perhaps one of the islands such as Ko Samui or Ko Phi Phi.

Conference guests traveling with their spouse or entire family are particularly attracted to this offering. The Royal’s management is



Table of Contents

actively looking at how new services can be introduced into the portfolio to combat this erosion of the valuable repeat/conference guests.

sCALABILITy Another challenge for the Royal is partially due to its own successful collaboration with the Saphan Taksin Conference Center. Building on the success of the past 10 years, Saphan Taksin has recently decided to expand its conference facility by 70%. This will lead to a peak demand for accommodation in excess of 1,100 rooms. The Royal has the land and the financial means to expand, but this type of move requires investment from the holding company. While James is concerned that the Royal hasn’t really analyzed this new development sufficiently, the hotel owner (Harry) is convinced that Saphan Taksin will never achieve its goal of attracting so many more new conference guests.



Table of Contents

The royAL’s resPoNse To BusINess ANd IT ChALLeNges

The KIosK soLuTIoNTo help handle the increase in guest traffic while improving guest experience, the Royal has decided to install and commission kiosks to provide guests with a self-service capability. The kiosks will enable guests to book services at the spa, book a scuba lesson in the pool, get printed information, such as maps and coupons to local restaurants etc, end so on.

The new system uses the guest’s room entry card extensively. The rationale is that guests must have their room key to be able to get into their room. So, in almost all situations in the hotel, it is reasonable to expect the guest to have their room card with them. The most important aspect of the card is that it authenticates who the guests are. The cards will also have the capability to have new or updated information written to them by the kiosk hardware. While this is a great advance for the Royal, kiosks rely on IT so there are many issues that need to be thought through before they go live.

Through a previous hotel loyalty program, customers were given paper coupons for using additional services around the pool, like the sauna or for free meals and drinks. Unfortunately, the customers kept losing these paper coupons on a frequent basis and complained that there must be a better way to manage these perks of membership. The use of room cards combined with the kiosk functionality should be the solution to this situation.



Table of Contents

In addition to kiosks, the Royal wants to allow guests who are using their laptops in their rooms (an ever-increasing number) to be able to do all the functions that are available from the kiosk. One big difference between the two situations is that when using a laptop, there is no way to update the guest room access card, although the application can link the ordered services to a particular room.



Table of Contents

NoN-esseNTIAL reAdINg BACKgrouNd INformATIoN

hoW IT ALL BegANTHE OWNER

TeCK-Wee LIm (hArry)

Harry Lim made his money as a silk trader in the 1970s. His original business was based on trading in cheap and cheerful clothing aimed at the tourists passing through Bangkok. His company’s success accelerated when Ralph Lauren signed up one of his textile factories in Udon Thani to produce suits, under contract to the Lauren brand, for export to the US. Since then, Harry hasn’t looked back.

In 1981, one of his creditors had severe financial difficulties and to clear his debt, Harry took on the Royal Chao Phraya Hotel as payment. At the time, the Royal was a partially completed hotel at a superb location. Harry financed the completion of the hotel and threw open the Royal in 1983.

Harry is a very cautious and astute businessman. He does not really understand the intricacies of the hospitality industry, so he works on the simple premise that quality works. “The guest is always right, so get the right guest and treat them right, and you will be successful.” Harry does not like spending on things that are not visible to the customer. As a result, while his Gentlemen’s Smoking club is ostentatious, with leather chairs, teak finishing, and gold trimmings, there has been little investment in supporting infrastructure, such as IT applications.



Table of ContentsTh

e or

g. C

hA

rT

TECK-W

EE LIM

(HAR

RY) O

wner

AKKARAT LIM

(JAMES) G

eneral Manager

DIM

ITRI VAN

RIJN

(DIM

ITRI) M

anager

Room

s Division

CH

E ING

LESIAS

(CH

E) Manager

Food & Beverage

KIET APILUKTO

YANU

NT

(PAP) M

anager

Engineering

KANYA U

NG

VICH

IAN

(NEE) M

anager

Sales & Marketing

SUVAR

NA

Manager

Recreational Services

KATSUSH

I FUJIYAM

A

Manager

Finance

STU M

ILLER

Manager

Hum

an Resources

DAN

IAL KIDW

AI

(DA

N) M

aintenance

Chief

ISABEL O’H

ARA

Front Office and

Business Center H

ead

MAR

Y SANC

HEZ

Executive

Housekeeper

JUAN

ITA

SANC

HEZ

Accountant

YVETTE

LERO

UX

Chef

JEAN

Assistant

Chef



Table of Contents

The mANAgemeNT

The geNerAL mANAger AKKArAT LIm (jAmes)James is Harry’s second son. It was always Harry’s intent for James to take on the hotel business. After attending the Harrow School in Bangkok, James went on to study at the International Hotel and Tourism Industry Management School in Bangkok. On completion, he attended the New York University’s Preston Robert Tisch Center for Hospitality, Tourism, and Sports Management, where he graduated with MSc Honors in 1997.

James has inherited his Thai mother’s free spirit. His mother, Isra Sangsirithorn (everyone calls her Elle), was raised on the Thai island of Ko Pha Ngan and has always been an extrovert lover of life, somewhat balancing her husband’s more-cautious, introvert character.

James is now 36 and keen to escape his father’s yoke and really modernize the hotel. James, who can sense the winds of change in the industry, is now actively challenging the natural thrift of Mr. Lim, which helped build the Royal Chao Phraya Hotel.

His comparative youth, modern outlook, and the islanders’ love of enjoying the moment makes it somewhat frustrating for him to keep his plans for expansion and personnel changes in check.



Table of Contents

mANAger — rooms dIVIsIoNdImITrI VAN rIjNThe biggest job at the Royal is arguably that of Manager — Rooms Division. Harry knew early on that he needed real expertise to take on this task and has always filled it with Dutch graduates from the well-respected Maastricht Hotel Management School in Holland.

Dimitri is the fourth graduate from the school to take on this role. He is typically Dutch in his focus on being practical and pragmatic. He also believes that it is important to be very close to his employees, through his empowered and collaborative approach to management. That doesn’t always work in the traditional Asian culture, and Dimitri is often at odds with Harry, who doesn’t ever trust employees who aren’t family. The staff, frequently from the rural province of Isan, don’t quite know what to make of the eccentric Dutchman and his unusual style!

mANAger — food ANd BeVerAgeChe IgLesIAs Che is a flamboyant man of Cuban descent, whose parents fled to Florida in the 1960s. Preferring the slow rhythm of the tropics, he is a natural counter-balance to the ever-energetic Dimitri. Harry and Che share a love for cigars and believe that spending lavishly on guests is key to success. Che has not had any formal training in this role and, as a result, does not make use of regular F&B metrics, such as the Pour/Cost percentage1 for efficiency in the bar.



Table of Contents

Che has grown through the ranks after settling in Bangkok while on a post-graduation, sabbatical world tour. He worked as a waiter and short-order cook in Miami while working his way through his BBA at the University of Miami. This limited exposure to the business and strong support from Harry has enabled Che to muddle through as F&B Manager. His day begins a little later than that of all other personnel and a siesta is always on the schedule, — “why kill yourself working today when you will only miss the party tomorrow?”

mANAger — eNgINeerINgKIeT APILuKToyANuNT (PAP)Pap is a cautious engineer who graduated from the prestigious Chulalongkong University. He is a very good technical engineer who takes his work seriously. He believes passionately in quality but, as a result, some of his tasks take longer to complete than guests expect. Pap hasn’t traveled outside of the country other than on vacation, and he isn’t very comfortable with English or conversing with foreign guests.

Like many Thai, Pap does not like any form of confrontation. Consequently, he sometimes finds himself promising things to guests or colleagues to avoid an issue and then being “unavailable” in the event that he cannot deliver on the promise.

Dimitri and James would like to bring in someone who is more comfortable dealing with international guests to work with Pap. To some extent, Dan Kidwai, the Maintenance chief with his experience in South East Asia is a help. However, he prefers to



Table of Contents

stick to his beloved machines rather than to engage with guests. The problem is that Pap would see that as a loss of face, and because he is Elle’s cousin, he has significant support.

1. The pour cost percentage is determined by dividing the cost of goods sold by sales (portion cost/selling price). Consequently, a 20% pour cost means that it costs the taxpayer $.20 to generate $1.00 of liquor sales, which translates to a gross profit margin of 80% and a markup on cost of 400%.



Table of Contents

mANAger — mArKeTINg ANd sALesKANyA uNgVIChIAN (Nee) Nee is a young, well-connected, confident professional. She originally studied finance but quickly found out that she has flair with customers. She studied economics at Harvard in the United States and received an MBA in Europe.

Her family consists of well-connected traders, and Nee has successfully tapped into their network of friends and relatives to ensure a steady stream of clients for the Royal. In addition, many of her former classmates are active in the medical, legal, and IT sectors. These contacts give her access to lucrative conference and banquet events.

mANAger — reCreATIoNAL serVICessuVArNASuvarna is the darling of the Royal. She just appeared at Harry’s door one day, confidently asking for a chance to set up a small massage facility. This has since grown into a significant recreational facility. No one seems to know her full name or how old she really is. “It didn’t seem polite to ask,” Harry is fond of saying.

Suvarna is charming and elegant; she is a former champion swimmer who learned her trade at the prestigious Tettucio spa in Montecatini, Italy. Her next ambition is to set up a fully equipped daycare center, but Harry does not see the need for such innovation. “Crying babies would just disturb the other guests



Table of Contents

and our own staff would probably bring all their children from the provinces and crowd the place up.”

mANAger — humAN resourCessTu mILLerStu is a colorful American who moved to Thailand with his partner in 2001, after 9/11. The tragedy in New York altered his view of the meaning of life. He wanted to tone down his existence in the fast lane, and Thailand seemed a good place to go. Ultimately, Stu wants to move to one of the islands and open his own resort. He somehow finds it difficult to escape the trendy excitement of Bangkok, even though, after New York, it still seems provincial in many ways.

Stu has a PhD in education and feels a little underutilized in his current role, but it is a good job and he likes the interplay of cultures that make up his portfolio.

mANAger — fINANCeKATsushI fujIyAmAFujiyama-san is Japanese and a trained accountant who has worked in many different fields, including IT and education, before settling in his current role. Fujiyama-san met Harry many years ago in Tokyo when Harry was negotiating an export deal with a Japanese importer and Fujiyama-san was the negotiator. Harry was so impressed, he made an offer that “could not be refused,” and Fujiyama-san has now worked at the Royal for 6 years.



Table of Contents

While Fujiyama-san is serious and conscientious about his tasks, he also loves to have fun outside of the office. He can often be found with Che and Harry at the Amadis, an upscale Karaoke bar, or at one of the prestigious sake bars, such as Wasabi, in town.

The sTAff

froNT offICe ANd BusINess CeNTer heAd IsABeL o’hArA Responsible for the front office, including the lobby, Isabel plays a key role at the Royal. In fact, her energy and love of technology is what made both Harry and James give her additional charge of the business center and the coffee shop, which James envisages as an informal chill-out zone for the business guests and the young, techno-savvy tourists. A whirlwind of energy, she is literally wherever the action is, and as some might say, if there is no action, she creates it!

Isabel believes in personal attention and keeping tight control over every customer interaction. No detail is too small to escape her notice, so much so that her team is now happy for her to take on the responsibility of every decision because their initiative seems unwanted. Small wonder then that she is exhausted at the end of the day and wonders how much more she can manage just by herself! Advice she has received includes adjusting her intense approach or face a possible burnout. These days, she



Table of Contents

barely has time for jazz and is usually too tired for scuba diving, her favorite leisure activities.

Chef ANd AssIsTANT ChefyVeTTe Leroux ANd jeAN Madame Yvette Leroux is an institution at the Royal. She can literally change the mood at any time, especially if her decisions are not accepted. Mme. Yvette is a gifted chef and a master of several types of cuisine. “Food,” she proclaims, “can be cooked by anyone, but only the French make it divine.” The management is only too happy to humor her, given the mouth-watering food she conjures up, including her unbeatable range of pastries.

But, Che knows how many anxious moments she gives her team as she ponders and broods over her menu till the last moment, and then spews forth the list of provisions she needs. The fresh seafood, vegetables, and fruits that she insists on are purchased from the local market at Saphan Mai, an hour away. This has led to a popular local tradition called the Royal Grand Prix.



Table of Contents

THE ROYAL GRAND PRIX

A group of local vendors, preselected through years of experience, is on a state of high alert. The hotel van, with Mme. Yvette’s young assistant — Jean — pacing, cell phone in hand, is on standby. The moment the phone rings and the instructions are noted, the vendors swing into action and the loading frenzy begins.

Within minutes, the van is loaded and Jean’s speed on the Royal Grand Prix is unrivalled. There is a discreet betting ring that lays odds on how long it will take Jean to make it back to the hotel. There was even talk of turning this into a professional race till the otherwise easy-going police nipped such ideas in the bud.

Jean, with Che’s tacit support, has made some not-so-subtle suggestions about making this a weekly, and not a daily, ritual — not least because of the expense. However, till now, no action has been taken to resolve this issue.

Knowing he is facing a formidable adversary, Che is quietly pushing for the upgrade of the coffee shop, offering a variety of food that can be served quickly and Wi-Fi areas for the business guest. At least publicly, Madame Yvette remains unconcerned about the threat from the coffee shop and the other “fast-food” ideas of James.



Table of Contents

exeCuTIVe houseKeePermAry sANChezThe elder of the two Sanchez sisters, Mary is a perfectionist who is intolerant of any sloppiness. Her white-glove inspections would do credit to a drill sergeant of the Marine Corps — one reason why the entire staff trembles in her presence.

Nobody doubts her integrity; however, it is her impossibly high standards that often terrify the housekeeping team.

Mary has a passion for flowers, her favorite being the rare Parrot flower, and counts the elderly gardener, with whom she has coffee at 11 am every day, as among her few friends. Very thorough with her planning, control, and instructions, she is at her wits’ end with the increasing number of complaints about housekeeping. No amount of repeated instructions or scolding seems to make a difference to the personnel.

ACCouNTANTjuANITA sANChezJuanita Sanchez is the younger, fun-loving sister of Mary. Juanita’s encouraging manner goes a long way to energize the young people at the Royal with her natural leadership qualities. The confidant of many of the younger girls, including and especially in Housekeeping, she is often caught between two contradictory influences. On the one hand is her loyalty and affection for her older sister, and on the other is her growing concern that the quality of service for which Housekeeping was known is slipping.



Table of Contents

Much better with people and figures than her elder sister, she is contemplating a formal course in management (apart from her basic qualification in accounting) because she feels that qualifications, savvy, and experience are never enough in an increasingly competitive world.

Juanita is a firm friend of the Business Center Head, Isabel O’Hara, who has not only helped her explore technology, but with whom she spends time as a student, learning all things fun, educational, and practical online.

mAINTeNANCe ChIef dANIAL KIdWAI (dan)Dan is a stocky, quiet, 37-year old, who loves to work with machinery. As his seniority increases, he resents the time he needs to spend in meetings and drafting memos and seeks every opportunity to get his hands “dirty.” He is happiest with a flask of tea and his tool kit.

However, he is smart enough to realize that growth means that he either sets up his own “shop” or he grows in the hotel hierarchy. With a big, extended family dependent on him, the former option is more risky.

His grandparents migrated from Dhaka, Bangladesh, to Myanmar, and finally reached Thailand. He has come up the hard way, and educated himself at night school, leading to an Engineering diploma, while working during the day.



Table of Contents

He has worked for several establishments, including a business center in Indonesia, a hotel in Thailand, and a resort in Malaysia.

He is respected by his staff for his mechanical skill and his ability to insulate them from the management. In turn, the management respects Dan’s ability to get along with his people, and his “noiseless” ability to get things done. Despite his quiet demeanor, he is very effective at negotiating with vendors.

Dan likes listening to folk songs in his mother tongue, Bangla, and enjoys playing football on the weekend. When not wearing overalls, simple cottons are his preferred mode of dress.


ITIL v3 Intermediate Certification Level | ST | Mind Map Exercise

Table of Contents

mINd mAP exerCIseThis exercise will assist you in recalling the information you have learned. Please do the exercise as outlined here for the most effective result.

1. Draw a circle on the center of the page. In the circle, write the subject that will be mapped.

2. Draw a smaller circle a short distance from the first. In this circle, write a key concept related to the subject. A list of the possible key concepts is given below. All these options should be explored as part of the exercise. Feel free to add additional concepts not included in the list.

3. Draw a line connecting the subject to the key concept.4. Continue to map key concepts to the main subject. Do

this as a brainstorming exercise, recalling as many key concepts related to the subject as you can remember. Do not refer to your Student Handbook for help.

5. Draw a line next to your key concept and describe that concept as much as you can. Draw as many lines as necessary to describe the concept. Do this for each key concept you have mapped.

6. Open your book and compare your mind map to the content in the Student Handbook.

7. Using a different pen or marker, fill in the gaps in your mind map.



Table of Contents

Key CoNCePTs y Objective y Scope y Principles y Concepts y Activities y Metrics y Challenges y Value to Business y Inputs y Outputs y Triggers y Tools y Critical Success Factors y Risks y Relationships



Table of Contents

Description

Description

Description

Key Concept

5

6

Key Concept

4

Key Concept

1

Key Concept

2 3


ITIL v3 Intermediate Certification Level | ST | Glossary

Table of Contents

Glossary of Terms and

DefinitionsITIL® V3 Glossary, v01, 30 May 2007

AcknowledgementsWe would like to express our gratitude and acknowledge the contribution of stuart rance and Ashley hanna of hewlett-Packard in the production of this

glossary.

Note for readers

This glossary may be freely downloaded.

see http://www.get-best-practice.co.uk/glossaries.aspx for details of licence terms

ITIL ® is a registered Trade mark, and a registered Community Trade mark of the office of

government Commerce, and is registered in the u.s. Patent and Trademark office



Table of Contents

ITIL® glossary of Terms, definitions

ATerm Definition

Acceptance

Formal agreement that an IT Service, Process, Plan, or other Deliverable is complete, accurate, Reliable and meets its specified Requirements. Acceptance is usually preceded by Evaluation or Testing and is often required before proceeding to the next stage of a Project or Process.

See Service Acceptance Criteria.

Access Management

(Service Operation) The Process responsible for allowing Users to make use of IT Services, data, or other Assets. Access Management helps to protect the Confidentiality, Integrity and Availability of Assets by ensuring that only authorized Users are able to access or modify the Assets. Access Management is sometimes referred to as Rights Management or Identity Management.



Table of Contents

Account Manager

(Service Strategy) A Role that is very similar to Business Relationship Manager, but includes more commercial aspects. Most commonly used when dealing with External Customers.

Accounting

(Service Strategy) The Process responsible for identifying actual Costs of delivering IT Services, comparing these with budgeted costs, and managing variance from the Budget.

Accredited

Officially authorised to carry out a Role. For example an Accredited body may be authorised to provide training or to conduct Audits.

Active Monitoring

(Service Operation) Monitoring of a Configuration Item or an IT Service that uses automated regular checks to discover the current status.

See Passive Monitoring.

Activity

A set of actions designed to achieve a particular result. Activities are usually defined as part of Processes or Plans, and are documented in Procedures.

Agreed Service Time

(Service Design) A synonym for Service Hours, commonly used in formal calculations of Availability. See Downtime.



Table of Contents

Agreement

A Document that describes a formal understanding between two or more parties. An Agreement is not legally binding, unless it forms part of a Contract.

See Service Level Agreement, Operational Level Agreement.

Alert

(Service Operation) A warning that a threshold has been reached, something has changed, or a Failure has occurred. Alerts are often created and managed by System Management tools and are managed by the Event Management Process.

Analytical Modelling

(Service Strategy) (Service Design) (Continual Service Improvement) A technique that uses mathematical Models to predict the behaviour of a Configuration Item or IT Service. Analytical Models are commonly used in Capacity Management and Availability Management.

See Modelling.



Table of Contents

Application

Software that provides Functions that are required by an IT Service. Each Application may be part of more than one IT Service. An Application runs on one or more Servers or Clients.

See Application Management, Application Portfolio.

Application Management

(Service Design) (Service Operation) The Function responsible for managing Applications throughout their Lifecycle.

Application Portfolio

(Service Design) A database or structured Document used to manage Applications throughout their Lifecycle. The Application Portfolio contains key Attributes of all Applications. The Application Portfolio is sometimes implemented as part of the Service Portfolio, or as part of the Configuration Management System.

Application Service Provider (ASP)

(Service Design) An External Service Provider that provides IT Services using Applications running at the Service Provider’s premises. Users access the Applications by network connections to the Service Provider.



Table of Contents

Application Sizing

(Service Design) The Activity responsible for understanding the Resource Requirements needed to support a new Application, or a major Change to an existing Application. Application Sizing helps to ensure that the IT Service can meet its agreed Service Level Targets for Capacity and Performance.

Architecture

(Service Design) The structure of a System or IT Service, including the Relationships of Components to each other and to the environment they are in. Architecture also includes the Standards and Guidelines which guide the design and evolution of the System.

Assembly

(Service Transition) A Configuration Item that is made up from a number of other CIs. For example a Server CI may contain CIs for CPUs, Disks, Memory etc.; an IT Service CI may contain many Hardware, Software and other CIs.

See Component CI, Build.



Table of Contents

Assessment

Inspection and analysis to check whether a Standard or set of Guidelines is being followed, that Records are accurate, or that Efficiency and Effectiveness targets are being met.

See Audit.

Asset

(Service Strategy) Any Resource or Capability. Assets of a Service Provider include anything that could contribute to the delivery of a Service. Assets can be one of the following types: Management, Organisation, Process, Knowledge, People, Information, Applications, Infrastructure, and Financial Capital.

Asset Management

(Service Transition) Asset Management is the Process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle. Asset Management is part of an overall Service Asset and Configuration Management Process.

See Asset Register.

Asset Register

(Service Transition) A list of Assets, which includes their ownership and value. The Asset Register is maintained by Asset Management.



Table of Contents

Attribute

(Service Transition) A piece of information about a Configuration Item. Examples are name, location, Version number, and Cost. Attributes of CIs are recorded in the Configuration Management Database (CMDB).

See Relationship.

Audit

Formal inspection and verification to check whether a Standard or set of Guidelines is being followed, that Records are accurate, or that Efficiency and Effectiveness targets are being met. An Audit may be carried out by internal or external groups.

See Certification, Assessment. Authority Matrix Synonym for RACI.

Automatic Call Distribution (ACD)

(Service Operation) Use of Information Technology to direct an incoming telephone call to the most appropriate person in the shortest possible time. ACD is sometimes called Automated Call Distribution.



Table of Contents

Availability

(Service Design) Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance, and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service.

Availability Management

(Service Design) The Process responsible for defining, analysing, Planning, measuring and improving all aspects of the Availability of IT Services. Availability Management is responsible for ensuring that all IT Infrastructure, Processes, Tools, Roles etc are appropriate for the agreed Service Level Targets for Availability.

Availability Management Information System (AMIS)

(Service Design) A virtual repository of all Availability Management data, usually stored in multiple physical locations.

See Service Knowledge Management System.



Table of Contents

Availability Plan

(Service Design) A Plan to ensure that existing and future Availability Requirements for IT Services can be provided Cost Effectively.

BBack-out Synonym for Remediation.

Backup (Service Design) (Service Operation) Copying data to protect against loss of Integrity or Availability of the original.

Balanced Scorecard

(Continual Service Improvement) A management tool developed by Drs. Robert Kaplan (Harvard Business School) and David Norton. A Balanced Scorecard enables a Strategy to be broken down into Key Performance Indicators. Performance against the KPIs is used to demonstrate how well the Strategy is being achieved. A Balanced Scorecard has 4 major areas, each of which has a small number of KPIs. The same 4 areas are considered at different levels of detail throughout the Organisation.



Table of Contents

Baseline

(Continual Service Improvement) A Benchmark used as a reference point. For example:

An ITSM Baseline can be used as a starting point to measure the effect of a Service Improvement Plan

A Performance Baseline can be used to measure changes in Performance over the lifetime of an IT Service

A Configuration Management Baseline can be used to enable the IT Infrastructure to be restored to a known Configuration if a Change or Release fails



Table of Contents

Benchmark

(Continual Service Improvement) The recorded state of something at a specific point in time. A Benchmark can be created for a Configuration, a Process, or any other set of data. For example, a benchmark can be used in:

Continual Service Improvement, to establish the current state for managing improvements.

Capacity Management, to document Performance characteristics during normal operations.

See Benchmarking, Baseline.

Benchmarking

(Continual Service Improvement) Comparing a Benchmark with a Baseline or with Best Practice. The term Benchmarking is also used to mean creating a series of Benchmarks over time, and comparing the results to measure progress or improvement.

Best Practice

Proven Activities or Processes that have been successfully used by multiple Organisations. ITIL is an example of Best Practice.



Table of Contents

Brainstorming

(Service Design) A technique that helps a team to generate ideas. Ideas are not reviewed during the Brainstorming session, but at a later stage. Brainstorming is often used by Problem Management to identify possible causes.

British Standards Institution (BSI)

The UK National Standards body, responsible for creating and maintaining British Standards. See http://www.bsi-global.com for more information.

See ISO.

Budget

A list of all the money an Organisation or Business Unit plans to receive, and plans to pay out, over a specified period of time.

See Budgeting, Planning.

Budgeting

The Activity of predicting and controlling the spending of money. Consists of a periodic negotiation cycle to set future Budgets (usually annual) and the day-to-day monitoring and adjusting of current Budgets.



Table of Contents

Build

(Service Transition) The Activity of assembling a number of Configuration Items to create part of an IT Service. The term Build is also used to refer to a Release that is authorised for distribution. For example Server Build or laptop Build.

See Configuration Baseline.

Build Environment

(Service Transition) A controlled Environment where Applications, IT Services and other Builds are assembled prior to being moved into a Test or Live Environment.

Business

(Service Strategy) An overall corporate entity or Organisation formed of a number of Business Units. In the context of ITSM, the term Business includes public sector and not-for-profit organisations, as well as companies. An IT Service Provider provides IT Services to a Customer within a Business. The IT Service Provider may be part of the same Business as their Customer (Internal Service Provider), or part of another Business (External Service Provider).



Table of Contents

Business Capacity Management (BCM)

(Service Design) In the context of ITSM, Business Capacity Management is the Activity responsible for understanding future Business Requirements for use in the Capacity Plan.

See Service Capacity Management.

Business Case

(Service Strategy) Justification for a significant item of expenditure. Includes information about Costs, benefits, options, issues, Risks, and possible problems.

See Cost Benefit Analysis.

Business Continuity Management (BCM)

(Service Design) The Business Process responsible for managing Risks that could seriously impact the Business. BCM safeguards the interests of key stakeholders, reputation, brand and value creating activities. The BCM Process involves reducing Risks to an acceptable level and planning for the recovery of Business Processes should a disruption to the Business occur. BCM sets the Objectives, Scope and Requirements for IT Service Continuity Management.



Table of Contents

Business Continuity Plan (BCP)

(Service Design) A Plan defining the steps required to Restore Business Processes following a disruption. The Plan will also identify the triggers for Invocation, people to be involved, communications etc. IT Service Continuity Plans form a significant part of Business Continuity Plans.

Business Customer

(Service Strategy) A recipient of a product or a Service from the Business. For example if the Business is a car manufacturer then the Business Customer is someone who buys a car.

Business Impact Analysis (BIA)

(Service Strategy) BIA is the Activity in Business Continuity Management that identifies Vital Business Functions and their dependencies. These dependencies may include Suppliers, people, other Business Processes, IT Services etc.

BIA defines the recovery requirements for IT Services. These requirements include Recovery Time Objectives, Recovery Point Objectives and minimum Service Level Targets for each IT Service.



Table of Contents

Business Objective

(Service Strategy) The Objective of a Business Process, or of the Business as a whole. Business Objectives support the Business Vision, provide guidance for the IT Strategy, and are often supported by IT Services.

Business Operations

(Service Strategy) The day-to-day execution, monitoring and management of Business Processes.

Business Perspective

(Continual Service Improvement) An understanding of the Service Provider and IT Services from the point of view of the Business, and an understanding of the Business from the point of view of the Service Provider.

Business Process

A Process that is owned and carried out by the Business. A Business Process contributes to the delivery of a product or Service to a Business Customer. For example, a retailer may have a purchasing Process which helps to deliver Services to their Business Customers. Many Business Processes rely on IT Services.



Table of Contents

Business Relationship Management

(Service Strategy) The Process or Function responsible for maintaining a Relationship with the Business. BRM usually includes:

Managing personal Relationships with Business managers

Providing input to Service Portfolio Management

Ensuring that the IT Service Provider is satisfying the Business needs of the Customers

This Process has strong links with Service Level Management.

Business Relationship Manager (BRM)

(Service Strategy) A Role responsible for maintaining the Relationship with one or more Customers. This Role is often combined with the Service Level Manager Role.

See Account Manager.



Table of Contents

Business Service

An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the Business.

The term Business Service is also used to mean a Service that is delivered to Business Customers by Business Units. For example delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful delivery of Business Services often depends on one or more IT Services.

Business Service Management (BSM)

(Service Strategy) (Service Design) An approach to the management of IT Services that considers the Business Processes supported and the Business value provided.

This term also means the management of Business Services delivered to Business Customers.

Business Unit

(Service Strategy) A segment of the Business which has its own Plans, Metrics, income and Costs. Each Business Unit owns Assets and uses these to create value for Customers in the form of goods and Services.



Table of Contents

CCall

(Service Operation) A telephone call to the Service Desk from a User. A Call could result in an Incident or a Service Request being logged.

Call Centre

(Service Operation) An Organisation or Business Unit which handles large numbers of incoming and outgoing telephone calls.

See Service Desk.

Call Type

(Service Operation) A Category that is used to distinguish incoming requests to a Service Desk. Common Call Types are Incident, Service Request and Complaint.

Capability

(Service Strategy) The ability of an Organisation, person, Process, Application, Configuration Item or IT Service to carry out an Activity. Capabilities are intangible Assets of an Organisation.

See Resource.



Table of Contents

Capability Maturity Model (CMM)

(Continual Service Improvement) The Capability Maturity Model for Software (also known as the CMM and SW-CMM) is a model used to identify Best Practices to help increase Process Maturity. CMM was developed at the Software Engineering Institute (SEI) of Carnegie Mellon University. In 2000, the SW-CMM was upgraded to CMMI® (Capability Maturity Model Integration). The SEI no longer maintains the SW-CMM model, its associated appraisal methods, or training materials.



Table of Contents

Capability Maturity Model Integration (CMMI)

(Continual Service Improvement) Capability Maturity Model® Integration (CMMI) is a process improvement approach developed by the Software Engineering Institute (SEI) of Carnegie Melon University. CMMI provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes. See http://www.sei.cmu.edu/cmmi/ for more information.

See CMM, Continuous Improvement, Maturity.

Capacity

(Service Design) The maximum Throughput that a Configuration Item or IT Service can deliver whilst meeting agreed Service Level Targets. For some types of CI, Capacity may be the size or volume, for example a disk drive.



Table of Contents

Capacity Management

(Service Design) The Process responsible for ensuring that the Capacity of IT Services and the IT Infrastructure is able to deliver agreed Service Level Targets in a Cost Effective and timely manner. Capacity Management considers all Resources required to deliver the IT Service, and plans for short, medium and long term Business Requirements.

Capacity Management Information System (CMIS)

(Service Design) A virtual repository of all Capacity Management data, usually stored in multiple physical locations.

See Service Knowledge Management System.

Capacity Plan

(Service Design) A Capacity Plan is used to manage the Resources required to deliver IT Services. The Plan contains scenarios for different predictions of Business demand, and costed options to deliver the agreed Service Level Targets.

Capacity Planning (Service Design) The Activity within Capacity Management responsible for creating a Capacity Plan.



Table of Contents

Capital Expenditure (CAPEX)

(Service Strategy) The Cost of purchasing something that will become a financial Asset, for example computer equipment and buildings. The value of the Asset is Depreciated over multiple accounting periods.

Capital Item

(Service Strategy) An Asset that is of interest to Financial Management because it is above an agreed financial value.

Capitalization

(Service Strategy) Identifying major Cost as capital, even though no Asset is purchased. This is done to spread the impact of the Cost over multiple accounting periods. The most common example of this is software development, or purchase of a software license.

Category

A named group of things that have something in common. Categories are used to group similar things together. For example Cost Types are used to group similar types of Cost. Incident Categories are used to group similar types of Incident, CI Types are used to group similar types of Configuration Item.



Table of Contents

Certification

Issuing a certificate to confirm Compliance to a Standard. Certification includes a formal Audit by an independent and Accredited body. The term Certification is also used to mean awarding a certificate to verify that a person has achieved a qualification.

Change

(Service Transition) The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc.

Change Advisory Board (CAB)

(Service Transition) A group of people that advises the Change Manager in the Assessment, prioritisation and scheduling of Changes. This board is usually made up of representatives from all areas within the IT Service Provider, the Business, and Third Parties such as Suppliers.



Table of Contents

Change Case

(Service Operation) A technique used to predict the impact of proposed Changes. Change Cases use specific scenarios to clarify the scope of proposed Changes and to help with Cost Benefit Analysis.

See Use Case.

Change History

(Service Transition) Information about all changes made to a Configuration Item during its life. Change History consists of all those Change Records that apply to the CI.

Change Management

(Service Transition) The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.



Table of Contents

Change Model

(Service Transition) A repeatable way of dealing with a particular Category of Change. A Change Model defines specific pre-defined steps that will be followed for a Change of this Category. Change Models may be very simple, with no requirement for approval (e.g. Password Reset) or may be very complex with many steps that require approval (e.g. major software Release).

See Standard Change, Change Advisory Board.

Change Record

(Service Transition) A Record containing the details of a Change. Each Change Record documents the Lifecycle of a single Change. A Change Record is created for every Request for Change that is received, even those that are subsequently rejected. Change Records should reference the Configuration Items that are affected by the Change. Change Records are stored in the Configuration Management System.

Change Request Synonym for Request for Change.



Table of Contents

Change Schedule

(Service Transition) A Document that lists all approved Changes and their planned implementation dates. A Change Schedule is sometimes called a Forward Schedule of Change, even though it also contains information about Changes that have already been implemented.

Change Window

(Service Transition) A regular, agreed time when Changes or Releases may be implemented with minimal impact on Services. Change Windows are usually documented in SLAs.

Charging

(Service Strategy) Requiring payment for IT Services. Charging for IT Services is optional, and many Organisations choose to treat their IT Service Provider as a Cost Centre.

Chronological Analysis

(Service Operation) A technique used to help identify possible causes of Problems. All available data about the Problem is collected and sorted by date and time to provide a detailed timeline. This can make it possible to identify which Events may have been triggered by others.



Table of Contents

CI Type

(Service Transition) A Category that is used to Classify CIs. The CI Type identifies the required Attributes and Relationships for a Configuration Record. Common CI Types include: hardware, Document, User etc.

Classification

The act of assigning a Category to something. Classification is used to ensure consistent management and reporting. CIs, Incidents, Problems, Changes etc. are usually classified.

Client

A generic term that means a Customer, the Business or a Business Customer. For example Client Manager may be used as a synonym for Account Manager.

The term client is also used to mean:

A computer that is used directly by a User, for example a PC, Handheld Computer, or Workstation.

The part of a Client-Server Application that the User directly interfaces with. For example an email Client.



Table of Contents

Closed

(Service Operation) The final Status in the Lifecycle of an Incident, Problem, Change etc. When the Status is Closed, no further action is taken.

Closure (Service Operation) The act of changing the Status of an Incident, Problem, Change etc. to Closed.

COBIT

(Continual service Improvement) Control Objectives for Information and related Technology (COBIT) provides guidance and Best Practice for the management of IT Processes. COBIT is published by the IT Governance Institute. See http://www.isaca.org/ for more information.

Code of Practice

A Guideline published by a public body or a Standards Organisation, such as ISO or BSI. Many Standards consist of a Code of Practice and a Specification. The Code of Practice describes recommended Best Practice.

Cold Standby Synonym for Gradual Recovery.

Commercial off the Shelf (COTS)

(Service Design) Application software or Middleware that can be purchased from a Third Party.



Table of Contents

Compliance

Ensuring that a Standard or set of Guidelines is followed, or that proper, consistent accounting or other practices are being employed.

Component

A general term that is used to mean one part of something more complex. For example, a computer System may be a component of an IT Service, an Application may be a Component of a Release Unit. Components that need to be managed should be Configuration Items.

Component Capacity Management (CCM)

(Service Design) (Continual Service Improvement) The Process responsible for understanding the Capacity, Utilisation, and Performance of Configuration Items. Data is collected, recorded and analysed for use in the Capacity Plan.

See Service Capacity Management.

Component CI

(Service Transition) A Configuration Item that is part of an Assembly. For example, a CPU or Memory CI may be part of a Server CI.



Table of Contents

Component Failure Impact Analysis (CFIA)

(Service Design) A technique that helps to identify the impact of CI failure on IT Services. A matrix is created with IT Services on one edge and CIs on the other. This enables the identification of critical CIs (that could cause the failure of multiple IT Services) and of fragile IT Services (that have multiple Single Points of Failure).

Computer Telephony Integration (CTI)

(Service Operation) CTI is a general term covering any kind of integration between computers and telephone Systems. It is most commonly used to refer to Systems where an Application displays detailed screens relating to incoming or outgoing telephone calls.

See Automatic Call Distribution, Interactive Voice Response.

Concurrency A measure of the number of Users engaged in the same Operation at the same time.

Confidentiality (Service Design) A security principle that requires that data should only be accessed by authorised people.



Table of Contents

Configuration

(Service Transition) A generic term, used to describe a group of Configuration Items that work together to deliver an IT Service, or a recognizable part of an IT Service. Configuration is also used to describe the parameter settings for one or more CIs.

Configuration Baseline

(Service Transition) A Baseline of a Configuration that has been formally agreed and is managed through the Change Management process. A Configuration Baseline is used as a basis for future Builds, Releases and Changes.

Configuration Control

(Service Transition) The Activity responsible for ensuring that adding, modifying or removing a CI is properly managed, for example by submitting a Request for Change or Service Request.

Configuration Identification

(Service Transition) The Activity responsible for collecting information about Configuration Items and their Relationships, and loading this information into the CMDB. Configuration Identification is also responsible for labelling the CIs themselves, so that the corresponding Configuration Records can be found.



Table of Contents

Configuration Item (CI)

(Service Transition) Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs.

Configuration Management

(Service Transition) The Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI. Configuration Management is part of an overall Service Asset and Configuration Management Process.



Table of Contents

Configuration Management Database (CMDB)

(Service Transition) A database used to store Configuration Records throughout their Lifecycle. The Configuration Management System maintains one or more CMDBs, and each CMDB stores Attributes of CIs, and Relationships with other CIs.

Configuration Management System (CMS)

(Service Transition) A set of tools and databases that are used to manage an IT Service Provider’s Configuration data. The CMS also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users. The CMS includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items and their Relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management Processes.

See Configuration Management Database, Service Knowledge Management System.



Table of Contents

Configuration Record

(Service Transition) A Record containing the details of a Configuration Item. Each Configuration Record documents the Lifecycle of a single CI. Configuration Records are stored in a Configuration Management Database.

Configuration Structure

(Service Transition) The hierarchy and other Relationships between all the Configuration Items that comprise a Configuration.

Continual Service Improvement (CSI)

(Continual Service Improvement) A stage in the Lifecycle of an IT Service and the title of one of the Core ITIL publications.

Continual Service Improvement is responsible for managing improvements to IT Service Management Processes and IT Services. The Performance of the IT Service Provider is continually measured and improvements are made to Processes, IT Services and IT Infrastructure in order to increase Efficiency, Effectiveness, and Cost Effectiveness.

See Plan-Do-Check-Act.



Table of Contents

Continuous Availability

(Service Design) An approach or design to achieve 100% Availability. A Continuously Available IT Service has no planned or unplanned Downtime.

Continuous Operation

(Service Design) An approach or design to eliminate planned Downtime of an IT Service. Note that individual Configuration Items may be down even though the IT Service is Available.

Contract A legally binding Agreement between two or more parties.

Contract Portfolio

(Service Strategy) A database or structured Document used to manage Service Contracts or Agreements between an IT Service Provider and their Customers. Each IT Service delivered to a Customer should have a Contract or other Agreement which is listed in the Contract Portfolio.

See Service Portfolio, Service Catalogue.



Table of Contents

Control

A means of managing a Risk, ensuring that a Business Objective is achieved, or ensuring that a Process is followed. Example Controls include Policies, Procedures, Roles, RAID, door-locks etc. A control is sometimes called a Countermeasure or safeguard.

Control also means to manage the utilization or behaviour of a Configuration Item, System or IT Service.

Control Objectives for Information and related Technology (COBIT)

See COBIT.



Table of Contents

Control perspective

(Service Strategy) An approach to the management of IT Services, Processes, Functions, Assets etc. There can be several different Control Perspectives on the same IT Service, Process etc., allowing different individuals or teams to focus on what is important and relevant to their specific Role. Example Control Perspectives include Reactive and Proactive management within IT Operations, or a Lifecycle view for an Application Project team.

Control Processes

The ISO/IEC 20000 Process group that includes Change Management and Configuration Management.

Core Service

(Service Strategy) An IT Service that delivers basic Outcomes desired by one or more Customers.

See Supporting Service, Core Service Package.

Core Service Package (CSP)

(Service Strategy) A detailed description of a Core Service that may be shared by two or more Service Level Packages.

See Service Package.



Table of Contents

Cost

The amount of money spent on a specific Activity, IT Service, or Business Unit. Costs consist of real cost (money), notional cost such as people’s time, and Depreciation.

Cost Benefit Analysis

An Activity that analyses and compares the Costs and the benefits involved in one or more alternative courses of action.

See Business Case, Net Present Value, Internal Rate of Return, Return on Investment, Value on Investment.

Cost Centre

(Service Strategy) A Business Unit or Project to which Costs are assigned. A Cost Centre does not charge for Services provided. An IT Service Provider can be run as a Cost Centre or a Profit Centre.

Cost Effectiveness

A measure of the balance between the Effectiveness and Cost of a Service, Process or activity, A Cost Effective Process is one which achieves its Objectives at minimum Cost.

See KPI, Return on Investment, Value for Money.



Table of Contents

Cost Element

(Service Strategy) The middle level of category to which Costs are assigned in Budgeting and Accounting. The highest level category is Cost Type. For example a Cost Type of “people” could have cost elements of payroll, staff benefits, expenses, training, overtime etc. Cost Elements can be further broken down to give Cost Units. For example the Cost Element “expenses” could include Cost Units of Hotels, Transport, Meals etc.

Cost Management

(Service Strategy) A general term that is used to refer to Budgeting and Accounting, sometimes used as a synonym for Financial Management

Cost Type

(Service Strategy) The highest level of category to which Costs are assigned in Budgeting and Accounting. For example hardware, software, people, accommodation, external and Transfer.

See Cost Element, Cost Type.



Table of Contents

Cost Unit

(Service Strategy) The lowest level of category to which Costs are assigned, Cost Units are usually things that can be easily counted (e.g. staff numbers, software licences) or things easily measured (e.g. CPU usage, Electricity consumed). Cost Units are included within Cost Elements. For example a Cost Element of “expenses” could include Cost Units of Hotels, Transport, Meals etc.

See Cost Type.

Countermeasure

Can be used to refer to any type of Control. The term Countermeasure is most often used when referring to measures that increase Resilience, Fault Tolerance or Reliability of an IT Service.

Course Corrections

Changes made to a Plan or Activity that has already started, to ensure that it will meet its Objectives. Course corrections are made as a result of Monitoring progress.



Table of Contents

CRAMM

A methodology and tool for analysing and managing Risks. CRAMM was developed by the UK Government, but is now privately owned. Further information is available from http://www.cramm.com/

Crisis Management

The Process responsible for managing the wider implications of Business Continuity. A Crisis Management team is responsible for Strategic issues such as managing media relations and shareholder confidence, and decides when to invoke Business Continuity Plans.

Critical Success Factor (CSF)

Something that must happen if a Process, Project, Plan, or IT Service is to succeed. KPIs are used to measure the achievement of each CSF. For example a CSF of “protect IT Services when making Changes” could be measured by KPIs such as “percentage reduction of unsuccessful Changes”, “percentage reduction in Changes causing Incidents” etc.



Table of Contents

Culture

A set of values that is shared by a group of people, including expectations about how people should behave, ideas, beliefs, and practices.

See Vision.

Customer

Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group who defines and agrees the Service Level Targets. The term Customers is also sometimes informally used to mean Users, for example “this is a Customer focussed Organisation”.

Customer Portfolio

(Service Strategy) A database or structured Document used to record all Customers of the IT Service Provider. The Customer Portfolio is the Business Relationship Manager’s view of the Customers who receive Services from the IT Service Provider.

See Contract Portfolio, Service Portfolio.



Table of Contents

D

Dashboard

(Service Operation) A graphical representation of overall IT Service Performance and Availability. Dashboard images may be updated in real-time, and can also be included in management reports and web pages. Dashboards can be used to support Service Level Management, Event Management or Incident Diagnosis.

Data-to-Information-to-Knowledge-to-Wisdom (DIKW)

A way of understanding the relationships between data, information, knowledge, and wisdom. DIKW shows how each of these builds on the others.



Table of Contents

Definitive Media Library (DML)

(Service Transition) One or more locations in which the definitive and approved versions of all software Configuration Items are securely stored. The DML may also contain associated CIs such as licenses and documentation. The DML is a single logical storage area even if there are multiple locations. All software in the DML is under the control of Change and Release Management and is recorded in the Configuration Management System. Only software from the DML is acceptable for use in a Release.

Deliverable

Something that must be provided to meet a commitment in a Service Level Agreement or a Contract. Deliverable is also used in a more informal way to mean a planned output of any Process.



Table of Contents

Demand Management

Activities that understand and influence Customer demand for Services and the provision of Capacity to meet these demands. At a Strategic level Demand Management can involve analysis of Patterns of Business Activity and User Profiles. At a Tactical level it can involve use of Differential Charging to encourage Customers to use IT Services at less busy times.

See Capacity Management. Deming Cycle Synonym for Plan Do Check Act.

Dependency The direct or indirect reliance of one Process or Activity upon another.

Deployment

(Service Transition) The Activity responsible for movement of new or changed hardware, software, documentation, Process, etc to the Live Environment. Deployment is part of the Release and Deployment Management Process.

See Rollout.

Depreciation

(Service Strategy) A measure of the reduction in value of an Asset over its life. This is based on wearing out, consumption or other reduction in the useful economic value.



Table of Contents

Design

(Service Design) An Activity or Process that identifies Requirements and then defines a solution that is able to meet these Requirements.

See Service Design.

Detection

(Service Operation) A stage in the Incident Lifecycle. Detection results in the Incident becoming known to the Service Provider. Detection can be automatic, or can be the result of a User logging an Incident.

Development

(Service Design) The Process responsible for creating or modifying an IT Service or Application. Also used to mean the Role or group that carries out Development work.

Development Environment

(Service Design) An Environment used to create or modify IT Services or Applications. Development Environments are not typically subjected to the same degree of control as Test Environments or Live Environments.

See Development.

Diagnosis

(Service Operation) A stage in the Incident and Problem Lifecycles. The purpose of Diagnosis is to identify a Workaround for an Incident or the Root Cause of a Problem.



Table of Contents

Diagnostic Script

(Service Operation) A structured set of questions used by Service Desk staff to ensure they ask the correct questions, and to help them Classify, Resolve and assign Incidents. Diagnostic Scripts may also be made available to Users to help them diagnose and resolve their own Incidents.

Differential Charging

A technique used to support Demand Management by charging different amounts for the same IT Service Function at different times.

Direct Cost

(Service Strategy) A cost of providing an IT Service which can be allocated in full to a specific Customer, Cost Centre, Project etc. For example cost of providing non-shared servers or software licenses.

See Indirect Cost.

Directory Service

(Service Operation) An Application that manages information about IT Infrastructure available on a network, and corresponding User access Rights.

Do Nothing

(Service Design) A Recovery Option. The Service Provider formally agrees with the Customer that Recovery of this IT Service will not be performed.



Table of Contents

Document

Information in readable form. A Document may be paper or electronic. For example a Policy statement, Service Level Agreement, Incident Record, diagram of computer room layout.

See Record.

Downtime

(Service Design) (Service Operation) The time when a Configuration Item or IT Service is not Available during its Agreed Service Time. The Availability of an IT Service is often calculated from Agreed Service Time and Downtime.

Driver Something that influences Strategy, Objectives or Requirements. For example new legislation or the actions of competitors.



Table of Contents

E

Early Life Support

(Service Transition) Support provided for a new or Changed IT Service for a period of time after it is Released. During Early Life Support the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional Resources for Incident and Problem Management.

Economies of scale

(Service Strategy) The reduction in average Cost that is possible from increasing the usage of an IT Service or Asset.

See Economies of Scope.

Economies of scope

(Service Strategy) The reduction in Cost that is allocated to an IT Service by using an existing Asset for an additional purpose. For example delivering a new IT Service from existing IT Infrastructure.

See Economies of Scale.



Table of Contents

Effectiveness

(Continual Service Improvement) A measure of whether the Objectives of a Process, Service or Activity have been achieved. An Effective Process or Activity is one that achieves its agreed Objectives.

See KPI.

Efficiency

(Continual Service Improvement) A measure of whether the right amount of resources have been used to deliver a Process, Service or Activity. An Efficient Process achieves its Objectives with the minimum amount of time, money, people or other resources.

See KPI.

Emergency Change

(Service Transition) A Change that must be introduced as soon as possible. For example to resolve a Major Incident or implement a Security patch. The Change Management Process will normally have a specific Procedure for handling Emergency Changes.

See Emergency Change Advisory Board (ECAB).



Table of Contents

Emergency Change Advisory Board (ECAB)

(Service Transition) A sub-set of the Change Advisory Board who make decisions about high impact Emergency Changes. Membership of the ECAB may be decided at the time a meeting is called, and depends on the nature of the Emergency Change.

Environment

(Service Transition) A subset of the IT Infrastructure that is used for a particular purpose. For Example: Live Environment, Test Environment, Build Environment. It is possible for multiple Environments to share a Configuration Item, for example Test and Live Environments may use different partitions on a single mainframe computer. Also used in the term Physical Environment to mean the accommodation, air conditioning, power system etc.

Environment is also used as a generic term to mean the external conditions that influence or affect something.

Error

(Service Operation) A design flaw or malfunction that causes a Failure of one or more Configuration Items or IT Services. A mistake made by a person or a faulty Process that impacts a CI or IT Service is also an Error.



Table of Contents

Escalation

(Service Operation) An Activity that obtains additional Resources when these are needed to meet Service Level Targets or Customer expectations. Escalation may be needed within any IT Service Management Process, but is most commonly associated with Incident Management, Problem Management and the management of Customer complaints. There are two types of Escalation, Functional Escalation and Hierarchic Escalation.

eSourcing Capability Model for Client Organizations (eSCM-CL)

(Service Strategy) A framework to help Organisations guide their analysis and decisions on Service Sourcing Models and Strategies. eSCM-CL was developed by Carnegie Mellon University.

See eSCM-SP.

eSourcing Capability Model for Service Providers (eSCM-SP)

(Service Strategy) A framework to help IT Service Providers develop their IT Service Management Capabilities from a Service Sourcing perspective. eSCM-SP was developed by Carnegie Mellon University.

See eSCM-CL.



Table of Contents

Estimation

The use of experience to provide an approximate value for a Metric or Cost. Estimation is also used in Capacity and Availability Management as the cheapest and least accurate Modelling method.

Evaluation

(Service Transition) The Process responsible for assessing a new or Changed IT Service to ensure that Risks have been managed and to help determine whether to proceed with the Change.

Evaluation is also used to mean comparing an actual Outcome with the intended Outcome, or comparing one alternative with another.

Event

(Service Operation) A change of state which has significance for the management of a Configuration Item or IT Service.

The term Event is also used to mean an Alert or notification created by any IT Service, Configuration Item or Monitoring tool. Events typically require IT Operations personnel to take actions, and often lead to Incidents being logged.



Table of Contents

Event Management

(Service Operation) The Process responsible for managing Events throughout their Lifecycle. Event Management is one of the main Activities of IT Operations.

Exception Report

A Document containing details of one or more KPIs or other important targets that have exceeded defined Thresholds. Examples include SLA targets being missed or about to be missed, and a Performance Metric indicating a potential Capacity problem.

Expanded Incident Lifecycle

(Availability Management) Detailed stages in the Lifecycle of an Incident. The stages are Detection, Diagnosis, Repair, Recovery, Restoration. The Expanded Incident Lifecycle is used to help understand all contributions to the Impact of Incidents and to Plan how these could be controlled or reduced.

External Customer

A Customer who works for a different Business to the IT Service Provider.

See External Service Provider, Internal Customer.



Table of Contents

External Metric

A Metric that is used to measure the delivery of IT Service to a Customer. External Metrics are usually defined in SLAs and reported to Customers.

See Internal Metric.

External Service Provider

(Service Strategy) An IT Service Provider which is part of a different Organisation to their Customer. An IT Service Provider may have both Internal Customers and External Customers.

See Type III Service Provider. External Sourcing Synonym for Outsourcing.

F

Facilities Management

(Service Operation) The Function responsible for managing the physical Environment where the IT Infrastructure is located. Facilities Management includes all aspects of managing the physical Environment, for example power and cooling, building Access Management, and environmental Monitoring.



Table of Contents

Failure

(Service Operation) Loss of ability to Operate to Specification, or to deliver the required output. The term Failure may be used when referring to IT Services, Processes, Activities, Configuration Items etc. A Failure often causes an Incident.

Failure Modes and Effects Analysis (FMEA)

An approach to assessing the potential Impact of Failures. FMEA involves analysing what would happen after Failure of each Configuration Item, all the way up to the effect on the Business. FMEA is often used in Information Security Management and in IT Service Continuity Planning.

Fast Recovery

(Service Design) A Recovery Option which is also known as Hot Standby. Provision is made to Recover the IT Service in a short period of time, typically less than 24 hours. Fast Recovery typically uses a dedicated Fixed Facility with computer Systems, and software configured ready to run the IT Services. Immediate Recovery may take up to 24 hours if there is a need to Restore data from Backups.

Fault Synonym for Error.



Table of Contents

Fault Tolerance

(Service Design) The ability of an IT Service or Configuration Item to continue to Operate correctly after Failure of a Component part.

See Resilience, Countermeasure.

Fault Tree Analysis (FTA)

(Service Design) (Continual Service Improvement) A technique that can be used to determine the chain of Events that leads to a Problem. Fault Tree Analysis represents a chain of Events using Boolean notation in a diagram.

Financial Management

(Service Strategy) The Function and Processes responsible for managing an IT Service Provider’s Budgeting, Accounting and Charging Requirements.

First-line Support

(Service Operation) The first level in a hierarchy of Support Groups involved in the resolution of Incidents. Each level contains more specialist skills, or has more time or other Resources.

See Escalation. Fishbone Diagram Synonym for Ishikawa Diagram.



Table of Contents

Fit for Purpose

An informal term used to describe a Process, Configuration Item, IT Service etc. that is capable of meeting its Objectives or Service Levels. Being Fit for Purpose requires suitable Design, implementation, Control and maintenance.

Fixed Cost

(Service Strategy) A Cost that does not vary with IT Service usage. For example the cost of Server hardware.

See Variable Cost.

Fixed Facility

(Service Design) A permanent building, available for use when needed by an IT Service Continuity Plan.

See Recovery Option, Portable Facility.

Follow the Sun

(Service Operation) A methodology for using Service Desks and Support Groups around the world to provide seamless 24 * 7 Service. Calls, Incidents, Problems and Service Requests are passed between groups in different time zones.

Fulfilment

Performing Activities to meet a need or Requirement. For example by providing a new IT Service, or meeting a Service Request.



Table of Contents

Function

A team or group of people and the tools they use to carry out one or more Processes or Activities. For example the Service Desk.

The term Function also has two other meanings

An intended purpose of a Configuration Item, Person, Team, Process, or IT Service. For example one Function of an Email Service may be to store and forward outgoing mails, one Function of a Business Process may be to dispatch goods to Customers.

To perform the intended purpose correctly, “The computer is Functioning”

Functional Escalation

(Service Operation) Transferring an Incident, Problem or Change to a technical team with a higher level of expertise to assist in an Escalation.



Table of Contents

G

Gap Analysis

(Continual Service Improvement) An Activity which compares two sets of data and identifies the differences. Gap Analysis is commonly used to compare a set of Requirements with actual delivery.

See Benchmarking.

Governance

Ensuring that Policies and Strategy are actually implemented, and that required Processes are correctly followed. Governance includes defining Roles and responsibilities, measuring and reporting, and taking actions to resolve any issues identified.

Gradual Recovery

(Service Design) A Recovery Option which is also known as Cold Standby. Provision is made to Recover the IT Service in a period of time greater than 72 hours. Gradual Recovery typically uses a Portable or Fixed Facility that has environmental support and network cabling, but no computer Systems. The hardware and software are installed as part of the IT Service Continuity Plan.



Table of Contents

Guideline

A Document describing Best Practice, that recommends what should be done. Compliance to a guideline is not normally enforced.

See Standard.

H

Help Desk

(Service Operation) A point of contact for Users to log Incidents. A Help Desk is usually more technically focussed than a Service Desk and does not provide a Single Point of Contact for all interaction. The term Help Desk is often used as a synonym for Service Desk.

Hierarchic Escalation

(Service Operation) Informing or involving more senior levels of management to assist in an Escalation.



Table of Contents

High Availability

(Service Design) An approach or Design that minimises or hides the effects of Configuration Item Failure on the Users of an IT Service. High Availability solutions are Designed to achieve an agreed level of Availability and make use of techniques such as Fault Tolerance, Resilience and fast Recovery to reduce the number of Incidents, and the Impact of Incidents.

Hot Standby Synonym for Fast Recovery or Immediate Recovery.

I

Identity

(Service Operation) A unique name that is used to identify a User, person or Role. The Identity is used to grant Rights to that User, person, or Role. Example identities might be the username SmithJ or the Role “Change manager”.

Immediate Recovery

(Service Design) A Recovery Option which is also known as Hot Standby. Provision is made to Recover the IT Service with no loss of Service. Immediate Recovery typically uses mirroring, load balancing and split site technologies.



Table of Contents

Impact

(Service Operation) (Service Transition) A measure of the effect of an Incident, Problem or Change on Business Processes. Impact is often based on how Service Levels will be affected. Impact and Urgency are used to assign Priority.

Incident

(Service Operation) An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.

Incident Management

(Service Operation) The Process responsible for managing the Lifecycle of all Incidents. The primary Objective of Incident Management is to return the IT Service to Users as quickly as possible.

Incident Record

(Service Operation) A Record containing the details of an Incident. Each Incident record documents the Lifecycle of a single Incident.



Table of Contents

Indirect Cost

(Service Strategy) A Cost of providing an IT Service which cannot be allocated in full to a specific Customer. For example Cost of providing shared Servers or software licenses. Also known as Overhead.

See Direct Cost.

Information Security Management (ISM)

(Service Design) The Process that ensures the Confidentiality, Integrity and Availability of an Organisation’s Assets, information, data and IT Services. Information Security Management usually forms part of an Organisational approach to Security Management which has a wider scope than the IT Service Provider, and includes handling of paper, building access, phone calls etc., for the entire Organisation.

Information Security Management System (ISMS)

(Service Design) The framework of Policy, Processes, Standards, Guidelines and tools that ensures an Organisation can achieve its Information Security Management Objectives.

Information Security Policy

(Service Design) The Policy that governs the Organisation’s approach to Information Security Management.



Table of Contents

Information Technology (IT)

The use of technology for the storage, communication or processing of information. The technology typically includes computers, telecommunications, Applications and other software. The information may include Business data, voice, images, video, etc. Information Technology is often used to support Business Processes through IT Services.

Infrastructure Service

An IT Service that is not directly used by the Business, but is required by the IT Service Provider so they can provide other IT Services. For example Directory Services, naming services, or communication services.

Insourcing Synonym for Internal Sourcing.

Integrity

(Service Design) A security principle that ensures data and Configuration Items are only modified by authorised personnel and Activities. Integrity considers all possible causes of modification, including software and hardware Failure, environmental Events, and human intervention.



Table of Contents

Interactive Voice Response (IVR)

(Service Operation) A form of Automatic Call Distribution that accepts User input, such as key presses and spoken commands, to identify the correct destination for incoming Calls.

Intermediate Recovery

(Service Design) A Recovery Option which is also known as Warm Standby. Provision is made to Recover the IT Service in a period of time between 24 and 72 hours. Intermediate Recovery typically uses a shared Portable or Fixed Facility that has computer Systems and network Components. The hardware and software will need to be configured, and data will need to be restored, as part of the IT Service Continuity Plan.

Internal Customer

A Customer who works for the same Business as the IT Service Provider.

See Internal Service Provider, External Customer.

Internal Metric

A Metric that is used within the IT Service Provider to Monitor the Efficiency, Effectiveness or Cost Effectiveness of the IT Service Provider’s internal Processes. Internal Metrics are not normally reported to the Customer of the IT Service. See External Metric.



Table of Contents

Internal Rate of Return (IRR)

(Service Strategy) A technique used to help make decisions about Capital Expenditure. IRR calculates a figure that allows two or more alternative investments to be compared. A larger IRR indicates a better investment.

See Net Present Value, Return on Investment.

Internal Service Provider

(Service Strategy) An IT Service Provider which is part of the same Organisation as their Customer. An IT Service Provider may have both Internal Customers and External Customers.

See Type I Service Provider, Type II Service Provider, Insource.

Internal Sourcing

(Service Strategy) Using an Internal Service Provider to manage IT Services.

See Service Sourcing, Type I Service Provider, Type II Service Provider.



Table of Contents

International Organization for Standardization (ISO)

The International Organization for Standardization (ISO) is the world’s largest developer of Standards. ISO is a non-governmental organization which is a network of the national standards institutes of 156 countries.

Further information about ISO is available from http://www.iso.org/

International Standards Organisation

See International Organization for Standardization (ISO)

Internet Service Provider (ISP)

An External Service Provider that provides access to the Internet. Most ISPs also provide other IT Services such as web hosting.

Invocation

(Service Design) Initiation of the steps defined in a plan. For example initiating the IT Service Continuity Plan for one or more IT Services.

Ishikawa Diagram

(Service Operation) (Continual Service Improvement) A technique that helps a team to identify all the possible causes of a Problem. Originally devised by Kaoru Ishikawa, the output of this technique is a diagram that looks like a fishbone.



Table of Contents

ISO 9000

A generic term that refers to a number of international Standards and Guidelines for Quality Management Systems.

See http://www.iso.org/ for more information.

See ISO.

ISO 9001 An international Standard for Quality Management Systems.

See ISO 9000, Standard.

ISO/IEC 17799

(Continual Service Improvement) ISO Code of Practice for Information Security Management.

See Standard.

ISO/IEC 20000 ISO Specification and Code of Practice for IT Service Management. ISO/IEC 20000 is aligned with ITIL Best Practice.

ISO/IEC 27001

(Service Design) (Continual Service Improvement) ISO Specification for Information Security Management. The corresponding Code of Practice is ISO/IEC 17799.

See Standard.



Table of Contents

IT Directorate

(Continual Service Improvement) Senior Management within a Service Provider, charged with developing and delivering IT services. Most commonly used in UK Government departments.

IT Infrastructure

All of the hardware, software, networks, facilities etc. that are required to Develop, Test, deliver, Monitor, Control or support IT Services. The term IT Infrastructure includes all of the Information Technology but not the associated people, Processes and documentation.

IT Operations

(Service Operation) Activities carried out by IT Operations Control, including Console Management, Job Scheduling, Backup and Restore, and Print and Output Management.

IT Operations is also used as a synonym for Service Operation.

IT Operations Control

(Service Operation) The Function responsible for Monitoring and Control of the IT Services and IT Infrastructure.

See Operations Bridge.



Table of Contents

IT Operations Management

(Service Operation) The Function within an IT Service Provider which performs the daily Activities needed to manage IT Services and the supporting IT Infrastructure. IT Operations Management includes IT Operations Control and Facilities Management.

IT Service

A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer’s Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.

IT Service Continuity Management (ITSCM)

(Service Design) The Process responsible for managing Risks that could seriously impact IT Services. ITSCM ensures that the IT Service Provider can always provide minimum agreed Service Levels, by reducing the Risk to an acceptable level and Planning for the Recovery of IT Services. ITSCM should be designed to support Business Continuity Management.



Table of Contents

IT Service Continuity Plan

(Service Design) A Plan defining the steps required to Recover one or more IT Services. The Plan will also identify the triggers for Invocation, people to be involved, communications etc. The IT Service Continuity Plan should be part of a Business Continuity Plan.

IT Service Management (ITSM)

The implementation and management of Quality IT Services that meet the needs of the Business. IT Service Management is performed by IT Service Providers through an appropriate mix of people, Process and Information Technology.

See Service Management.

IT Service Management Forum (itSMF)

The IT Service Management Forum is an independent Organisation dedicated to promoting a professional approach to IT Service Management. The itSMF is a not-for-profit membership Organisation with representation in many countries around the world (itSMF Chapters). The itSMF and its membership contribute to the development of ITIL and associated IT Service Management Standards. See http://www.itsmf.com/ for more information.



Table of Contents

IT Service Provider

(Service Strategy) A Service Provider that provides IT Services to Internal Customers or External Customers.

IT Steering Group (ISG)

A formal group that is responsible for ensuring that Business and IT Service Provider Strategies and Plans are closely aligned. An IT Steering Group includes senior representatives from the Business and the IT Service Provider.

ITIL

A set of Best Practice guidance for IT Service Management. ITIL is owned by the OGC and consists of a series of publications giving guidance on the provision of Quality IT Services, and on the Processes and facilities needed to support them. See http://www.itil.co.uk/ for more information.

J

Job Description

A Document which defines the Roles, responsibilities, skills and knowledge required by a particular person. One Job Description can include multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by one person.



Table of Contents

Job Scheduling

(Service Operation) Planning and managing the execution of software tasks that are required as part of an IT Service. Job Scheduling is carried out by IT Operations Management, and is often automated using software tools that run batch or online tasks at specific times of the day, week, month or year.

K

Kano Model

(Service Strategy) A Model developed by Noriaki Kano that is used to help understand Customer preferences. The Kano Model considers Attributes of an IT Service grouped into areas such as Basic Factors, Excitement Factors, Performance Factors etc.

Kepner & Tregoe Analysis

(Service Operation) (Continual Service Improvement) A structured approach to Problem solving. The Problem is analysed in terms of what, where, when and extent. Possible causes are identified. The most probable cause is tested. The true cause is verified.



Table of Contents

Key Performance Indicator (KPI)

(Continual Service Improvement) A Metric that is used to help manage a Process, IT Service or Activity. Many Metrics may be measured, but only the most important of these are defined as KPIs and used to actively manage and report on the Process, IT Service or Activity. KPIs should be selected to ensure that Efficiency, Effectiveness, and Cost Effectiveness are all managed.

See Critical Success Factor.

Knowledge Base

(Service Transition) A logical database containing the data used by the Service Knowledge Management System.

Knowledge Management

(Service Transition) The Process responsible for gathering, 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.

See Data-to-Information-to-Knowledge-to-Wisdom, Service Knowledge Management System.



Table of Contents

Known Error

(Service Operation) A Problem that has a documented Root Cause and a Workaround. Known Errors are created and managed throughout their Lifecycle by Problem Management. Known Errors may also be identified by Development or Suppliers.

Known Error Database (KEDB)

(Service Operation) A database containing all Known Error Records. This database is created by Problem Management and used by Incident and Problem Management. The Known Error Database is part of the Service Knowledge Management System.

Known Error Record

(Service Operation) A Record containing the details of a Known Error. Each Known Error Record documents the Lifecycle of a Known Error, including the Status, Root Cause and Workaround. In some implementations a Known Error is documented using additional fields in a Problem Record.



Table of Contents

L

Lifecycle

The various stages in the life of an IT Service, Configuration Item, Incident, Problem, Change etc. The Lifecycle defines the Categories for Status and the Status transitions that are permitted. For example:

The Lifecycle of an Application includes Requirements, Design, Build, Deploy, Operate, Optimise.

The Expanded Incident Lifecycle includes Detect, Respond, Diagnose, Repair, Recover, Restore.

The lifecycle of a Server may include: Ordered, Received, In Test, Live, Disposed etc.

Line of Service (LOS)

(Service Strategy) A Core Service or Supporting Service that has multiple Service Level Packages. A line of Service is managed by a Product Manager and each Service Level Package is designed to support a particular market segment.

Live (Service Transition) Refers to an IT Service or Configuration Item that is being used to deliver Service to a Customer.



Table of Contents

Live Environment

(Service Transition) A controlled Environment containing Live Configuration Items used to deliver IT Services to Customers.

M

Maintainability

(Service Design) A measure of how quickly and Effectively a Configuration Item or IT Service can be restored to normal working after a Failure. Maintainability is often measured and reported as MTRS.

Maintainability is also used in the context of Software or IT Service Development to mean ability to be Changed or Repaired easily.

Major Incident

(Service Operation) The highest Category of Impact for an Incident. A Major Incident results in significant disruption to the Business.

Managed Services

(Service Strategy) A perspective on IT Services which emphasizes the fact that they are managed. The term Managed Services is also used as a synonym for Outsourced IT Services.



Table of Contents

Management Information

Information that is used to support decision making by managers. Management Information is often generated automatically by tools supporting the various IT Service Management Processes. Management Information often includes the values of KPIs such as “Percentage of Changes leading to Incidents”, or “first time fix rate”.

Management of Risk (MoR)

The OGC methodology for managing Risks. MoR includes all the Activities required to identify and Control the exposure to Risk which may have an impact on the achievement of an Organisation’s Business Objectives.

See http://www.m-o-r.org/ for more details.

Management System

The framework of Policy, Processes and Functions that ensures an Organisation can achieve its Objectives.

Manual Workaround

A Workaround that requires manual intervention. Manual Workaround is also used as the name of a Recovery Option in which The Business Process Operates without the use of IT Services. This is a temporary measure and is usually combined with another Recovery Option.



Table of Contents

Marginal Cost

(Service Strategy) The Cost of continuing to provide the IT Service. Marginal Cost does not include investment already made, for example the cost of developing new software and delivering training.

Market Space

(Service Strategy) All opportunities that an IT Service Provider could exploit to meet business needs of Customers. The Market Space identifies the possible IT Services that an IT Service Provider may wish to consider delivering.

Maturity

(Continual Service Improvement) A measure of the Reliability, Efficiency and Effectiveness of a Process, Function, Organisation etc. The most mature Processes and Functions are formally aligned to Business Objectives and Strategy, and are supported by a framework for continual improvement.

Maturity Level A named level in a Maturity model such as the Carnegie Mellon Capability Maturity Model Integration.



Table of Contents

Mean Time Between Failures (MTBF)

(Service Design) A Metric for measuring and reporting Reliability. MTBF is the average time that a Configuration Item or IT Service can perform its agreed Function without interruption. This is measured from when the CI or IT Service starts working, until it next fails.

Mean Time Between Service Incidents (MTBSI)

(Service Design) A Metric used for measuring and reporting Reliability. MTBSI is the mean time from when a System or IT Service fails, until it next fails. MTBSI is equal to MTBF + MTRS.

Mean Time To Repair (MTTR)

The average time taken to repair a Configuration Item or IT Service after a Failure. MTTR is measured from when the CI or IT Service fails until it is Repaired. MTTR does not include the time required to Recover or Restore. MTTR is sometimes incorrectly used to mean Mean Time to Restore Service.

Mean Time to Restore Service (MTRS)

The average time taken to Restore a Configuration Item or IT Service after a Failure. MTRS is measured from when the CI or IT Service fails until it is fully Restored and delivering its normal functionality.

See Maintainability, Mean Time to Repair.



Table of Contents

Metric

(Continual Service Improvement) Something that is measured and reported to help manage a Process, IT Service or Activity.

See KPI.

Middleware

(Service Design) Software that connects two or more software Components or Applications. Middleware is usually purchased from a Supplier, rather than developed within the IT Service Provider.

See Off the Shelf.

Mission Statement

The Mission Statement of an Organisation is a short but complete description of the overall purpose and intentions of that Organisation. It states what is to be achieved, but not how this should be done.

Model

A representation of a System, Process, IT Service, Configuration Item etc. that is used to help understand or predict future behaviour.

Modelling

A technique that is used to predict the future behaviour of a System, Process, IT Service, Configuration Item etc. Modelling is commonly used in Financial Management, Capacity Management and Availability Management.



Table of Contents

Monitor Control Loop

(Service Operation) Monitoring the output of a Task, Process, IT Service or Configuration Item; comparing this output to a predefined norm; and taking appropriate action based on this comparison.

Monitoring

(Service Operation) Repeated observation of a Configuration Item, IT Service or Process to detect Events and to ensure that the current status is known.

N

Near-Shore

(Service Strategy) Provision of Services from a country near the country where the Customer is based. This can be the provision of an IT Service, or of supporting Functions such as Service Desk.

See On-shore, Off-shore.

Net Present Value (NPV)

(Service Strategy) A technique used to help make decisions about Capital Expenditure. NPV compares cash inflows to cash outflows. Positive NPV indicates that an investment is worthwhile.

See Internal Rate of Return, Return on Investment.



Table of Contents

Notional Charging

(Service Strategy) An approach to Charging for IT Services. Charges to Customers are calculated and Customers are informed of the charge, but no money is actually transferred. Notional Charging is sometimes introduced to ensure that Customers are aware of the Costs they incur, or as a stage during the introduction of real Charging.

O

Objective

The defined purpose or aim of a Process, an Activity or an Organisation as a whole. Objectives are usually expressed as measurable targets. The term Objective is also informally used to mean a Requirement.

See Outcome. Off the Shelf Synonym for Commercial Off the Shelf.



Table of Contents

Office of Government Commerce (OGC)

OGC owns the ITIL brand (copyright and trademark). OGC is a UK Government department that supports the delivery of the government’s procurement agenda through its work in collaborative procurement and in raising levels of procurement skills and capability with departments. It also provides support for complex public sector projects.

Office of Public Sector Information (OPSI)

OPSI license the Crown Copyright material used in the ITIL publications. They are a UK Government department who provide online access to UK legislation, license the re-use of Crown copyright material, manage the Information Fair Trader Scheme, maintain the Government’s Information Asset Register and provide advice and guidance on official publishing and Crown copyright.

Off-shore

(Service Strategy) Provision of Services from a location outside the country where the Customer is based, often in a different continent. This can be the provision of an IT Service, or of supporting Functions such as Service Desk.

See On-shore, Near-shore.



Table of Contents

On-shore

(Service Strategy) Provision of Services from a location within the country where the Customer is based. See Off-shore, Near-shore.

Operate

To perform as expected. A Process or Configuration Item is said to Operate if it is delivering the Required outputs. Operate also means to perform one or more Operations. For example, to Operate a computer is to do the day-to-day Operations needed for it to perform as expected.

Operation

(Service Operation) Day-to-day management of an IT Service, System, or other Configuration Item. Operation is also used to mean any pre-defined Activity or Transaction. For example loading a magnetic tape, accepting money at a point of sale, or reading data from a disk drive.

Operational

The lowest of three levels of Planning and delivery (Strategic, Tactical, Operational). Operational Activities include the day-to-day or short term Planning or delivery of a Business Process or IT Service Management Process.

The term Operational is also a synonym for Live.



Table of Contents

Operational Cost

Cost resulting from running the IT Services. Often repeating payments. For example staff costs, hardware maintenance and electricity (also known as “current expenditure” or “revenue expenditure”).

See Capital Expenditure. Operational Expenditure (OPEX)

Synonym for Operational Cost.

Operational Level Agreement (OLA)

(Service Design) (Continual Service Improvement) An Agreement between an IT Service Provider and another part of the same 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. For example there could be an OLA

between the IT Service Provider and a procurement department to obtain hardware in agreed times

between the Service Desk and a Support Group to provide Incident Resolution in agreed times.

See Service Level Agreement.



Table of Contents

Operations Bridge

(Service Operation) A physical location where IT Services and IT Infrastructure are monitored and managed.

Operations Control Synonym for IT Operations Control.

Operations Management Synonym for IT Operations Management.

Opportunity Cost

(Service Strategy) A Cost that is used in deciding between investment choices. Opportunity Cost represents the revenue that would have been generated by using the Resources in a different way. For example the Opportunity Cost of purchasing a new Server may include not carrying out a Service Improvement activity that the money could have been spent on. Opportunity cost analysis is used as part of a decision making processes, but is not treated as an actual Cost in any financial statement.

Optimise

Review, Plan and request Changes, in order to obtain the maximum Efficiency and Effectiveness from a Process, Configuration Item, Application etc.



Table of Contents

Organisation

A company, legal entity or other institution. Examples of Organisations that are not companies include International Standards Organisation or itSMF. The term Organisation is sometimes used to refer to any entity which has People, Resources and Budgets. For example a Project or Business Unit.

Outcome

The result of carrying out an Activity; following a Process; delivering an IT Service etc. The term Outcome is used to refer to intended results, as well as to actual results.

See Objective.

Outsourcing

(Service Strategy) Using an External Service Provider to manage IT Services.

See Service Sourcing, Type III Service Provider.

Overhead Synonym for Indirect cost



Table of Contents

P

Pain Value Analysis

(Service Operation) A technique used to help identify the Business Impact of one or more Problems. A formula is used to calculate Pain Value based on the number of Users affected, the duration of the Downtime, the Impact on each User, and the cost to the Business (if known).

Pareto Principle

(Service Operation) A technique used to prioritise Activities. The Pareto Principle says that 80% of the value of any Activity is created with 20% of the effort. Pareto Analysis is also used in Problem Management to prioritise possible Problem causes for investigation.

Partnership

A relationship between two Organisations which involves working closely together for common goals or mutual benefit. The IT Service Provider should have a Partnership with the Business, and with Third Parties who are critical to the delivery of IT Services.

See Value Network.



Table of Contents

Passive Monitoring

(Service Operation) Monitoring of a Configuration Item, an IT Service or a Process that relies on an Alert or notification to discover the current status. See Active Monitoring.

Pattern of Business Activity (PBA)

(Service Strategy) A Workload profile of one or more Business Activities. Patterns of Business Activity are used to help the IT Service Provider understand and plan for different levels of Business Activity.

See User Profile.

Percentage utilisation

(Service Design) The amount of time that a Component is busy over a given period of time. For example, if a CPU is busy for 1800 seconds in a one hour period, its utilisation is 50%

Performance A measure of what is achieved or delivered by a System, person, team, Process, or IT Service.

Performance Anatomy

(Service Strategy) An approach to Organisational Culture that integrates, and actively manages, leadership and strategy, people development, technology enablement, performance management and innovation.



Table of Contents

Performance Management

(Continual Service Improvement) The Process responsible for day-to-day Capacity Management Activities. These include Monitoring, Threshold detection, Performance analysis and Tuning, and implementing Changes related to Performance and Capacity.

Pilot

(Service Transition) A limited Deployment of an IT Service, a Release or a Process to the Live Environment. A Pilot is used to reduce Risk and to gain User feedback and Acceptance.

See Test, Evaluation.

Plan

A detailed proposal which describes the Activities and Resources needed to achieve an Objective. For example a Plan to implement a new IT Service or Process. ISO/IEC 20000 requires a Plan for the management of each IT Service Management Process.



Table of Contents

Plan-Do-Check-Act

(Continual Service Improvement) A four stage cycle for Process management, attributed to Edward Deming. Plan-Do-Check-Act is also called the Deming Cycle.

PLAN: Design or revise Processes that support the IT Services.

DO: Implement the Plan and manage the Processes.

CHECK: Measure the Processes and IT Services, compare with Objectives and produce reports

ACT: Plan and implement Changes to improve the Processes.

Planned Downtime

(Service Design) Agreed time when an IT Service will not be available. Planned Downtime is often used for maintenance, upgrades and testing.

See Change Window, Downtime.

Planning An Activity responsible for creating one or more Plans. For example, Capacity Planning.



Table of Contents

PMBOK

A Project management Standard maintained and published by the Project Management Institute. PMBOK stands for Project Management Body of Knowledge. See http://www.pmi.org/ for more information.

See PRINCE2.

Policy

Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.

Portable Facility

(Service Design) A prefabricated building, or a large vehicle, provided by a Third Party and moved to a site when needed by an IT Service Continuity Plan.

See Recovery Option, Fixed Facility.

Post Implementation Review (PIR)

A Review that takes place after a Change or a Project has been implemented. A PIR determines if the Change or Project was successful, and identifies opportunities for improvement.



Table of Contents

Practice

A way of working, or a way in which work must be done. Practices can include Activities, Processes, Functions, Standards and Guidelines.

See Best Practice.

Prerequisite for Success (PFS)

An Activity that needs to be completed, or a condition that needs to be met, to enable successful implementation of a Plan or Process. A PFS is often an output from one Process that is a required input to another Process.

Pricing (Service Strategy) The Activity for establishing how much Customers will be Charged.

PRINCE2

The standard UK government methodology for Project management. See http://www.ogc.gov.uk/prince2/ for more information.

See PMBOK.

Priority

(Service Transition) (Service Operation) A Category used to identify the relative importance of an Incident, Problem or Change. Priority is based on Impact and Urgency, and is used to identify required times for actions to be taken. For example the SLA may state that Priority2 Incidents must be resolved within 12 hours.



Table of Contents

Proactive Monitoring

(Service Operation) Monitoring that looks for patterns of Events to predict possible future Failures.

See Reactive Monitoring.

Proactive Problem Management

(Service Operation) Part of the Problem Management Process. The Objective of Proactive Problem Management is to identify Problems that might otherwise be missed. Proactive Problem Management analyses Incident Records, and uses data collected by other IT Service Management Processes to identify trends or significant Problems.

Problem

(Service Operation) A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.

Problem Management

(Service Operation) The Process responsible for managing the Lifecycle of all Problems. The primary Objectives of Problem Management are to prevent Incidents from happening, and to minimise the Impact of Incidents that cannot be prevented.



Table of Contents

Problem Record

(Service Operation) A Record containing the details of a Problem. Each Problem Record documents the Lifecycle of a single Problem.

Procedure

A Document containing steps that specify how to achieve an Activity. Procedures are defined as part of Processes.

See Work Instruction.

Process

A structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management Controls required to reliably deliver the outputs. A Process may define Policies, Standards, Guidelines, Activities, and Work Instructions if they are needed.

Process Control

The Activity of planning and regulating a Process, with the Objective of performing the Process in an Effective, Efficient, and consistent manner.



Table of Contents

Process Manager

A Role responsible for Operational management of a Process. The Process Manager’s responsibilities include Planning and co-ordination of all Activities required to carry out, monitor and report on the Process. There may be several Process Managers for one Process, for example regional Change Managers or IT Service Continuity Managers for each data centre. The Process Manager Role is often assigned to the person who carries out the Process Owner Role, but the two Roles may be separate in larger Organisations.

Process Owner

A Role responsible for ensuring that a Process is Fit for Purpose. The Process Owner’s responsibilities include sponsorship, Design, Change Management and continual improvement of the Process and its Metrics. This Role is often assigned to the same person who carries out the Process Manager Role, but the two Roles may be separate in larger Organisations.

Production Environment Synonym for Live Environment.



Table of Contents

Profit Centre

(Service Strategy) A Business Unit which charges for Services provided. A Profit Centre can be created with the objective of making a profit, recovering Costs, or running at a loss. An IT Service Provider can be run as a Cost Centre or a Profit Centre.

Pro-forma A template, or example Document containing example data that will be replaced with the real values when these are available.

Programme

A number of Projects and Activities that are planned and managed together to achieve an overall set of related Objectives and other Outcomes.

Project

A temporary Organisation, with people and other Assets required to achieve an Objective or other Outcome. Each Project has a Lifecycle that typically includes initiation, Planning, execution, Closure etc. Projects are usually managed using a formal methodology such as PRINCE2.

Projected Service Outage (PSO)

(Service Transition) A Document that identifies the effect of planned Changes, maintenance Activities and Test Plans on agreed Service Levels.



Table of Contents

Projects IN Controlled Environments (PRINCE2)

See PRINCE2

Q

Qualification

(Service Transition) An Activity that ensures that IT Infrastructure is appropriate, and correctly configured, to support an Application or IT Service.

See Validation.

Quality

The ability of a product, Service, or Process to provide the intended value. For example, a hardware Component can be considered to be of high Quality if it performs as expected and delivers the required Reliability. Process Quality also requires an ability to monitor Effectiveness and Efficiency, and to improve them if necessary.

See Quality Management System.



Table of Contents

Quality Assurance (QA)

(Service Transition) The Process responsible for ensuring that the Quality of a product, Service or Process will provide its intended Value.

Quality Management System (QMS)

(Continual Service Improvement) The set of Processes responsible for ensuring that all work carried out by an Organisation is of a suitable Quality to reliably meet Business Objectives or Service Levels.

See ISO 9000.

Quick Win

(Continual Service Improvement) An improvement Activity which is expected to provide a Return on Investment in a short period of time with relatively small Cost and effort.

See Pareto Principle.



Table of Contents

R

RACI

(Service Design) (Continual Service Improvement) A Model used to help define Roles and Responsibilities. RACI stands for Responsible, Accountable, Consulted and Informed.

See Stakeholder.

Reactive Monitoring

(Service Operation) Monitoring that takes action in response to an Event. For example submitting a batch job when the previous job completes, or logging an Incident when an Error occurs.

See Proactive Monitoring.

Reciprocal Arrangement

(Service Design) A Recovery Option. An agreement between two Organisations to share resources in an emergency. For example, Computer Room space or use of a mainframe.



Table of Contents

Record

A Document containing the results or other output from a Process or Activity. Records are evidence of the fact that an Activity took place and may be paper or electronic. For example, an Audit report, an Incident Record, or the minutes of a meeting.

Recovery

(Service Design) (Service Operation) Returning a Configuration Item or an IT Service to a working state. Recovery of an IT Service often includes recovering data to a known consistent state. After Recovery, further steps may be needed before the IT Service can be made available to the Users (Restoration).

Recovery Option

(Service Design) A Strategy for responding to an interruption to Service. Commonly used Strategies are Do Nothing, Manual Workaround, Reciprocal Arrangement, Gradual Recovery, Intermediate Recovery, Fast Recovery, Immediate Recovery. Recovery Options may make use of dedicated facilities, or Third Party facilities shared by multiple Businesses.



Table of Contents

Recovery Point Objective (RPO)

(Service Operation) The maximum amount of data that may be lost when Service is Restored after an interruption. Recovery Point Objective is expressed as a length of time before the Failure. For example a Recovery Point Objective of one day may be supported by daily Backups, and up to 24 hours of data may be lost. Recovery Point Objectives for each IT Service should be negotiated, agreed and documented, and used as Requirements for Service Design and IT Service Continuity Plans.

Recovery Time Objective (RTO)

(Service Operation) The maximum time allowed for recovery of an IT Service following an interruption. The Service Level to be provided may be less than normal Service Level Targets. Recovery Time Objectives for each IT Service should be negotiated, agreed and documented.

See Business Impact Analysis.

Redundancy

Synonym for Fault Tolerance.

The term Redundant also has a generic meaning of obsolete, or no longer needed.



Table of Contents

Relationship

A connection or interaction between two people or things. In Business Relationship Management it is the interaction between the IT Service Provider and the Business. In Configuration Management it is a link between two Configuration Items that identifies a dependency or connection between them. For example Applications may be linked to the Servers they run on, IT Services have many links to all the CIs that contribute to them.

Relationship Processes

The ISO/IEC 20000 Process group that includes Business Relationship Management and Supplier Management.

Release

(Service Transition) A collection of hardware, software, documentation, Processes or other Components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, Tested, and Deployed as a single entity.

Release and Deployment Management

(Service Transition) The Process responsible for both Release Management and Deployment.



Table of Contents

Release Identification

(Service Transition) A naming convention used to uniquely identify a Release. The Release Identification typically includes a reference to the Configuration Item and a version number. For example Microsoft Office 2003 SR2.

Release Management

(Service Transition) The Process responsible for Planning, scheduling and controlling the movement of Releases to Test and Live Environments. The primary Objective of Release Management is to ensure that the integrity of the Live Environment is protected and that the correct Components are released. Release Management is part of the Release and Deployment Management Process.

Release Process

The name used by ISO/IEC 20000 for the Process group that includes Release Management. This group does not include any other Processes.

Release Process is also used as a synonym for Release Management Process.



Table of Contents

Release Record

(Service Transition) A Record in the CMDB that defines the content of a Release. A Release Record has Relationships with all Configuration Items that are affected by the Release.

Release Unit

(Service Transition) Components of an IT Service that are normally Released together. A Release Unit typically includes sufficient Components to perform a useful Function. For example one Release Unit could be a Desktop PC, including Hardware, Software, Licenses, Documentation etc. A different Release Unit may be the complete Payroll Application, including IT Operations Procedures and User training.

Release Window Synonym for Change Window.



Table of Contents

Reliability

(Service Design) (Continual Service Improvement) A measure of how long a Configuration Item or IT Service can perform its agreed Function without interruption. Usually measured as MTBF or MTBSI. The term Reliability can also be used to state how likely it is that a Process, Function etc. will deliver its required outputs.

See Availability.

Remediation (Service Transition) Recovery to a known state after a failed Change or Release.

Repair (Service Operation) The replacement or correction of a failed Configuration Item.

Request for Change (RFC)

(Service Transition) A formal proposal for a Change to be made. An RFC includes details of the proposed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change itself.

Request Fulfilment

(Service Operation) The Process responsible for managing the Lifecycle of all Service Requests.



Table of Contents

Requirement

(Service Design) A formal statement of what is needed. For example a Service Level Requirement, a Project Requirement or the required Deliverables for a Process.

See Statement of Requirements.

Resilience

(Service Design) The ability of a Configuration Item or IT Service to resist Failure or to Recover quickly following a Failure. For example, an armoured cable will resist failure when put under stress.

See Fault Tolerance.

Resolution

(Service Operation) Action taken to repair the Root Cause of an Incident or Problem, or to implement a Workaround.

In ISO/IEC 20000, Resolution Processes is the Process group that includes Incident and Problem Management.

Resolution Processes

The ISO/IEC 20000 Process group that includes Incident Management and Problem Management.



Table of Contents

Resource

(Service Strategy) A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT Service. Resources are considered to be Assets of an Organisation.

See Capability, Service Asset.

Response Time

A measure of the time taken to complete an Operation or Transaction. Used in Capacity Management as a measure of IT Infrastructure Performance, and in Incident Management as a measure of the time taken to answer the phone, or to start Diagnosis.

Responsiveness

A measurement of the time taken to respond to something. This could be Response Time of a Transaction, or the speed with which an IT Service Provider responds to an Incident or Request for Change etc.

Restoration of Service See Restore.

Restore

(Service Operation) Taking action to return an IT Service to the Users after Repair and Recovery from an Incident. This is the primary Objective of Incident Management.



Table of Contents

Retire

(Service Transition) Permanent removal of an IT Service, or other Configuration Item, from the Live Environment. Retired is a stage in the Lifecycle of many Configuration Items.

Return on Investment (ROI)

(Service Strategy) (Continual Service Improvement) A measurement of the expected benefit of an investment. In the simplest sense it is the net profit of an investment divided by the net worth of the assets invested.

See Net Present Value, Value on Investment.

Return to Normal

(Service Design) The phase of an IT Service Continuity Plan during which full normal operations are resumed. For example, if an alternate data centre has been in use, then this phase will bring the primary data centre back into operation, and restore the ability to invoke IT Service Continuity Plans again.



Table of Contents

Review

An evaluation of a Change, Problem, Process, Project etc. Reviews are typically carried out at predefined points in the Lifecycle, and especially after Closure. The purpose of a Review is to ensure that all Deliverables have been provided, and to identify opportunities for improvement.

See Post Implementation Review.

Rights

(Service Operation) Entitlements, or permissions, granted to a User or Role. For example the Right to modify particular data, or to authorize a Change.

Risk

A possible Event that could cause harm or loss, or affect the ability to achieve Objectives. A Risk is measured by the probability of a Threat, the Vulnerability of the Asset to that Threat, and the Impact it would have if it occurred.

Risk Assessment

The initial steps of Risk Management. Analysing the value of Assets to the business, identifying Threats to those Assets, and evaluating how Vulnerable each Asset is to those Threats. Risk Assessment can be quantitative (based on numerical data) or qualitative.



Table of Contents

Risk Management The Process responsible for identifying, assessing and controlling Risks.

See Risk Assessment.

Role

A set of responsibilities, Activities and authorities granted to a person or team. A Role is defined in a Process. One person or team may have multiple Roles, for example the Roles of Configuration Manager and Change Manager may be carried out by a single person.

Rollout

(Service Transition) Synonym for Deployment. Most often used to refer to complex or phased Deployments or Deployments to multiple locations.

Root Cause (Service Operation) The underlying or original cause of an Incident or Problem.

Root Cause Analysis (RCA)

(Service Operation) An Activity that identifies the Root Cause of an Incident or Problem. RCA typically concentrates on IT Infrastructure failures.

See Service Failure Analysis. Running Costs Synonym for Operational Costs



Table of Contents

SScalability

The ability of an IT Service, Process, Configuration Item etc. to perform its agreed Function when the Workload or Scope changes.

Scope

The boundary, or extent, to which a Process, Procedure, Certification, Contract etc. applies. For example the Scope of Change Management may include all Live IT Services and related Configuration Items, the Scope of an ISO/IEC 20000 Certificate may include all IT Services delivered out of a named data centre.

Second-line Support

(Service Operation) The second level in a hierarchy of Support Groups involved in the resolution of Incidents and investigation of Problems. Each level contains more specialist skills, or has more time or other Resources.

Security See Information Security Management Security Management

Synonym for Information Security Management

Security Policy Synonym for Information Security Policy



Table of Contents

Separation of Concerns (SoC)

(Service Strategy) An approach to Designing a solution or IT Service that divides the problem into pieces that can be solved independently. This approach separates “what” is to be done from “how” it is to be done.

Server

(Service Operation) A computer that is connected to a network and provides software Functions that are used by other computers.

Service

A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

Service Acceptance Criteria (SAC)

(Service Transition) A set of criteria used to ensure that an IT Service meets its functionality and Quality Requirements and that the IT Service Provider is ready to Operate the new IT Service when it has been Deployed.

See Acceptance.



Table of Contents

Service Analytics

(Service Strategy) A technique used in the Assessment of the Business Impact of Incidents. Service Analytics Models the dependencies between Configuration Items, and the dependencies of IT Services on Configuration Items.

Service Asset Any Capability or Resource of a Service Provider.

See Asset. Service Asset and Configuration Management (SACM)

(Service Transition) The Process responsible for both Configuration Management and Asset Management.

Service Capacity Management (SCM)

(Service Design) (Continual Service Improvement) The Activity responsible for understanding the Performance and Capacity of IT Services. The Resources used by each IT Service and the pattern of usage over time are collected, recorded, and analysed for use in the Capacity Plan.

See Business Capacity Management, Component Capacity Management.



Table of Contents

Service Catalogue

(Service Design) A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.

See Contract Portfolio. Service Continuity Management

Synonym for IT Service Continuity Management.

Service Contract

(Service Strategy) A Contract to deliver one or more IT Services. The term Service Contract is also used to mean any Agreement to deliver IT Services, whether this is a legal Contract or an SLA.

See Contract Portfolio.

Service Culture

A Customer oriented Culture. The major Objectives of a Service Culture are Customer satisfaction and helping the Customer to achieve their Business Objectives.



Table of Contents

Service Design

(Service Design) A stage in the Lifecycle of an IT Service. Service Design includes a number of Processes and Functions and is the title of one of the Core ITIL publications.

See Design.

Service Design Package

(Service Design) Document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement.

Service Desk

(Service Operation) The Single Point of Contact between the Service Provider and the Users. A typical Service Desk manages Incidents and Service Requests, and also handles communication with the Users.

Service Failure Analysis (SFA)

(Service Design) An Activity that identifies underlying causes of one or more IT Service interruptions. SFA identifies opportunities to improve the IT Service Provider’s Processes and tools, and not just the IT Infrastructure. SFA is a time constrained, project-like activity, rather than an ongoing process of analysis. See Root Cause Analysis.



Table of Contents

Service Hours

(Service Design) (Continual Service Improvement) An agreed time period when a particular IT Service should be Available. For example, “Monday-Friday 08:00 to 17:00 except public holidays”. Service Hours should be defined in a Service Level Agreement.

Service Improvement Plan (SIP)

(Continual Service Improvement) A formal Plan to implement improvements to a Process or IT Service.

Service Knowledge Management System (SKMS)

(Service Transition) A set of tools and databases that are used to manage knowledge and information. The SKMS includes the Configuration Management System, as well as other tools and databases. The SKMS stores, manages, updates, and presents all information that an IT Service Provider needs to manage the full Lifecycle of IT Services.

Service Level

Measured and reported achievement against one or more Service Level Targets. The term Service Level is sometimes used informally to mean Service Level Target.



Table of Contents

Service Level Agreement (SLA)

(Service Design) (Continual Service Improvement) An Agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple Customers.

See Operational Level Agreement.

Service Level Management (SLM)

(Service Design) (Continual Service Improvement) The Process responsible for negotiating Service Level Agreements, and ensuring that these are met. SLM is responsible for ensuring that all IT Service Management Processes, Operational Level Agreements, and Underpinning Contracts, are appropriate for the agreed Service Level Targets. SLM monitors and reports on Service Levels, and holds regular Customer reviews.

Service Level Package (SLP)

(Service Strategy) A defined level of Utility and Warranty for a particular Service Package. Each SLP is designed to meet the needs of a particular Pattern of Business Activity.

See Line of Service.



Table of Contents

Service Level Requirement (SLR)

(Service Design) (Continual Service Improvement) A Customer Requirement for an aspect of an IT Service. SLRs are based on Business Objectives and are used to negotiate agreed Service Level Targets.

Service Level Target

(Service Design) (Continual Service Improvement) A commitment that is documented in a Service Level Agreement. Service Level Targets are based on Service Level Requirements, and are needed to ensure that the IT Service design is Fit for Purpose. Service Level Targets should be SMART, and are usually based on KPIs.

Service Maintenance Objective

(Service Operation) The expected time that a Configuration Item will be unavailable due to planned maintenance Activity.

Service Management

Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.



Table of Contents

Service Management Lifecycle

An approach to IT Service Management that emphasizes the importance of coordination and Control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continuous Improvement of IT Services.

Service Manager

A manager who is responsible for managing the end-to-end Lifecycle of one or more IT Services. The term Service Manager is also used to mean any manager within the IT Service Provider. Most commonly used to refer to a Business Relationship Manager, a Process Manager, an Account Manager or a senior manager with responsibility for IT Services overall.

Service Operation

(Service Operation) A stage in the Lifecycle of an IT Service. Service Operation includes a number of Processes and Functions and is the title of one of the Core ITIL publications.

See Operation.



Table of Contents

Service Owner (Continual Service Improvement) A Role which is accountable for the delivery of a specific IT Service.

Service Package

(Service Strategy) A detailed description of an IT Service that is available to be delivered to Customers. A Service Package includes a Service Level Package and one or more Core Services and Supporting Services.

Service Pipeline

(Service Strategy) A database or structured Document listing all IT Services that are under consideration or Development, but are not yet available to Customers. The Service Pipeline provides a Business view of possible future IT Services and is part of the Service Portfolio which is not normally published to Customers.



Table of Contents

Service Portfolio

(Service Strategy) The complete set of Services that are managed by a Service Provider. The Service Portfolio is used to manage the entire Lifecycle of all Services, and includes three Categories: Service Pipeline (proposed or in Development); Service Catalogue (Live or available for Deployment); and Retired Services.

See Service Portfolio Management, Contract Portfolio.

Service Portfolio Management (SPM)

(Service Strategy) The Process responsible for managing the Service Portfolio. Service Portfolio Management considers Services in terms of the Business value that they provide.

Service Potential

(Service Strategy) The total possible value of the overall Capabilities and Resources of the IT Service Provider.

Service Provider

(Service Strategy) An Organisation supplying Services to one or more Internal Customers or External Customers. Service Provider is often used as an abbreviation for IT Service Provider.

See Type I Service Provider, Type II Service Provider, Type III Service Provider.



Table of Contents

Service Provider Interface (SPI)

(Service Strategy) An interface between the IT Service Provider and a User, Customer, Business Process, or a Supplier. Analysis of Service Provider Interfaces helps to coordinate end-to-end management of IT Services.

Service Provisioning Optimization (SPO)

(Service Strategy) Analysing the finances and constraints of an IT Service to decide if alternative approaches to Service delivery might reduce Costs or improve Quality.

Service Reporting

(Continual Service Improvement) The Process responsible for producing and delivering reports of achievement and trends against Service Levels. Service Reporting should agree the format, content and frequency of reports with Customers.

Service Request

(Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

See Request Fulfilment.



Table of Contents

Service Sourcing

(Service Strategy) The Strategy and approach for deciding whether to provide a Service internally or to Outsource it to an External Service Provider. Service Sourcing also means the execution of this Strategy.

Service Sourcing includes:

Internal Sourcing - Internal or Shared Services using Type I or Type II Service Providers.

Traditional Sourcing - Full Service Outsourcing using a Type III Service Provider.

Multivendor Sourcing - Prime, Consortium or Selective Outsourcing using Type III Service Providers.

Service Strategy

(Service Strategy) The title of one of the Core ITIL publications. Service Strategy establishes an overall Strategy for IT Services and for IT Service Management.



Table of Contents

Service Transition

(Service Transition) A stage in the Lifecycle of an IT Service. Service Transition includes a number of Processes and Functions and is the title of one of the Core ITIL publications.

See Transition.

Service Utility

(Service Strategy) The Functionality of an IT Service from the Customer’s perspective. The Business value of an IT Service is created by the combination of Service Utility (what the Service does) and Service Warranty (how well it does it).

See Utility.

Service Validation and Testing

(Service Transition) The Process responsible for Validation and Testing of a new or Changed IT Service. Service Validation and Testing ensures that the IT Service matches its Design Specification and will meet the needs of the Business.

Service Valuation

(Service Strategy) A measurement of the total Cost of delivering an IT Service, and the total value to the Business of that IT Service. Service Valuation is used to help the Business and the IT Service Provider agree on the value of the IT Service.



Table of Contents

Service Warranty

(Service Strategy) Assurance that an IT Service will meet agreed Requirements. This may be a formal Agreement such as a Service Level Agreement or Contract, or may be a marketing message or brand image. The Business value of an IT Service is created by the combination of Service Utility (what the Service does) and Service Warranty (how well it does it).

See Warranty.

Serviceability

(Service Design) (Continual Service Improvement) The ability of a Third Party Supplier to meet the terms of their Contract. This Contract will include agreed levels of Reliability, Maintainability or Availability for a Configuration Item.

Shift

(Service Operation) A group or team of people who carry out a specific Role for a fixed period of time. For example there could be four shifts of IT Operations Control personnel to support an IT Service that is used 24 hours a day.



Table of Contents

Simulation modelling

(Service Design) (Continual Service Improvement) A technique that creates a detailed Model to predict the behaviour of a Configuration Item or IT Service. Simulation Models can be very accurate but are expensive and time consuming to create. A Simulation Model is often created by using the actual Configuration Items that are being modelled, with artificial Workloads or Transactions. They are used in Capacity Management when accurate results are important. A simulation model is sometimes called a Performance Benchmark.

Single Point of Contact

(Service Operation) Providing a single consistent way to communicate with an Organisation or Business Unit. For example, a Single Point of Contact for an IT Service Provider is usually called a Service Desk.

Single Point of Failure (SPOF)

(Service Design) Any Configuration Item that can cause an Incident when it fails, and for which a Countermeasure has not been implemented. A SPOF may be a person, or a step in a Process or Activity, as well as a Component of the IT Infrastructure.

See Failure.



Table of Contents

SLAM Chart

(Continual Service Improvement) A Service Level Agreement Monitoring Chart is used to help monitor and report achievements against Service Level Targets. A SLAM Chart is typically colour coded to show whether each agreed Service Level Target has been met, missed, or nearly missed during each of the previous 12 months.

SMART

(Service Design) (Continual Service Improvement) An acronym for helping to remember that targets in Service Level Agreements and Project Plans should be Specific, Measurable, Achievable, Relevant and Timely.

Snapshot

(Service Transition) The current state of a Configuration as captured by a discovery tool.

Also used as a synonym for Benchmark.

See Baseline. Source See Service Sourcing.



Table of Contents

Specification

A formal definition of Requirements. A Specification may be used to define technical or Operational Requirements, and may be internal or external. Many public Standards consist of a Code of Practice and a Specification. The Specification defines the Standard against which an Organisation can be Audited.

Stakeholder

All people who have an interest in an Organisation, Project, IT Service etc. Stakeholders may be interested in the Activities, targets, Resources, or Deliverables. Stakeholders may include Customers, Partners, employees, shareholders, owners, etc. See RACI.

Standard

A mandatory Requirement. Examples include ISO/IEC 20000 (an international Standard), an internal security Standard for Unix configuration, or a government Standard for how financial Records should be maintained. The term Standard is also used to refer to a Code of Practice or Specification published by a Standards Organisation such as ISO or BSI.

See Guideline.



Table of Contents

Standard Change

(Service Transition) A pre-approved Change that is low Risk, relatively common and follows a Procedure or Work Instruction. For example password reset or provision of standard equipment to a new employee. RFCs are not required to implement a Standard Change, and they are logged and tracked using a different mechanism, such as a Service Request.

See Change Model. Standard Operating Procedures (SOP)

(Service Operation) Procedures used by IT Operations Management.

Standby

(Service Design) Used to refer to Resources that are not required to deliver the Live IT Services, but are available to support IT Service Continuity Plans. For example a Standby data centre may be maintained to support Hot Standby, Warm Standby or Cold Standby arrangements.

Statement of requirements (SOR)

(Service Design) A Document containing all Requirements for a product purchase, or a new or changed IT Service.

See Terms of Reference.



Table of Contents

Status

The name of a required field in many types of Record. It shows the current stage in the Lifecycle of the associated Configuration Item, Incident, Problem etc.

Status Accounting

(Service Transition) The Activity responsible for recording and reporting the Lifecycle of each Configuration Item.

Storage Management

(Service Operation) The Process responsible for managing the storage and maintenance of data throughout its Lifecycle.

Strategic

(Service Strategy) The highest of three levels of Planning and delivery (Strategic, Tactical, Operational). Strategic Activities include Objective setting and long term Planning to achieve the overall Vision.

Strategy (Service Strategy) A Strategic Plan designed to achieve defined Objectives.

Super User

(Service Operation) A User who helps other Users, and assists in communication with the Service Desk or other parts of the IT Service Provider. Super Users typically provide support for minor Incidents and training.



Table of Contents

Supplier

(Service Strategy) (Service Design) A Third Party responsible for supplying goods or Services that are required to deliver IT services. Examples of suppliers include commodity hardware and software vendors, network and telecom providers, and Outsourcing Organisations.

See Underpinning Contract, Supply Chain.

Supplier and Contract Database (SCD)

(Service Design) A database or structured Document used to manage Supplier Contracts throughout their Lifecycle. The SCD contains key Attributes of all Contracts with Suppliers, and should be part of the Service Knowledge Management System.

Supplier Management

(Service Design) The Process responsible for ensuring that all Contracts with Suppliers support the needs of the Business, and that all Suppliers meet their contractual commitments.

Supply Chain

(Service Strategy) The Activities in a Value Chain carried out by Suppliers. A Supply Chain typically involves multiple Suppliers, each adding value to the product or Service.

See Value Network.



Table of Contents

Support Group

(Service Operation) A group of people with technical skills. Support Groups provide the Technical Support needed by all of the IT Service Management Processes.

See Technical Management.

Support Hours

(Service Design) (Service Operation) The times or hours when support is available to the Users. Typically this is the hours when the Service Desk is available. Support Hours should be defined in a Service Level Agreement, and may be different from Service Hours. For example, Service Hours may be 24 hours a day, but the Support Hours may be 07:00 to 19:00.

Supporting Service

(Service Strategy) A Service that enables or enhances a Core Service. For example a Directory Service or a Backup Service.

See Service Package.

SWOT Analysis

(Continual Service Improvement) A technique that reviews and analyses the internal strengths and weaknesses of an Organisation and the external opportunities and threats which it faces SWOT stands for Strengths, Weaknesses, Opportunities and Threats.



Table of Contents

System

A number of related things that work together to achieve an overall Objective. For example:

A computer System including hardware, software and Applications.

A management System, including multiple Processes that are planned and managed together. For example a Quality Management System.

A Database Management System or Operating System that includes many software modules that are designed to perform a set of related Functions.

System Management

The part of IT Service Management that focuses on the management of IT Infrastructure rather than Process.

T

Tactical

The middle of three levels of Planning and delivery (Strategic, Tactical, Operational). Tactical Activities include the medium term Plans required to achieve specific Objectives, typically over a period of weeks to months.



Table of Contents

Tag

(Service Strategy) A short code used to identify a Category. For example tags EC1, EC2, EC3 etc. might be used to identify different Customer outcomes when analysing and comparing Strategies. The term Tag is also used to refer to the Activity of assigning Tags to things.

Technical Management

(Service Operation) The Function responsible for providing technical skills in support of IT Services and management of the IT Infrastructure. Technical Management defines the Roles of Support Groups, as well as the tools, Processes and Procedures required.

Technical Observation (TO)

(Continual Service Improvement) A technique used in Service Improvement, Problem investigation and Availability Management. Technical support staff meet to monitor the behaviour and Performance of an IT Service and make recommendations for improvement.

Technical Service Synonym for Infrastructure Service.

Technical Support Synonym for Technical Management.



Table of Contents

Tension Metrics

(Continual Service Improvement) A set of related Metrics, in which improvements to one Metric have a negative effect on another. Tension Metrics are designed to ensure that an appropriate balance is achieved.

Terms of Reference (TOR)

(Service Design) A Document specifying the Requirements, Scope, Deliverables, Resources and schedule for a Project or Activity.

Test

(Service Transition) An Activity that verifies that a Configuration Item, IT Service, Process, etc. meets its Specification or agreed Requirements.

See Service Validation and Testing, Acceptance.

Test Environment

(Service Transition) A controlled Environment used to Test Configuration Items, Builds, IT Services, Processes etc.



Table of Contents

Third Party

A person, group, or Business who is not part of the Service Level Agreement for an IT Service, but is required to ensure successful delivery of that IT Service. For example a software Supplier, a hardware maintenance company, or a facilities department. Requirements for Third Parties are typically specified in Underpinning Contracts or Operational Level Agreements.

Third-line Support

(Service Operation) The third level in a hierarchy of Support Groups involved in the resolution of Incidents and investigation of Problems. Each level contains more specialist skills, or has more time or other Resources.

Threat

Anything that might exploit a Vulnerability. Any potential cause of an Incident can be considered to be a Threat. For example a fire is a Threat that could exploit the Vulnerability of flammable floor coverings. This term is commonly used in Information Security Management and IT Service Continuity Management, but also applies to other areas such as Problem and Availability Management.



Table of Contents

Threshold

The value of a Metric which should cause an Alert to be generated, or management action to be taken. For example “Priority1 Incident not solved within 4 hours”, “more than 5 soft disk errors in an hour”, or “more than 10 failed changes in a month”.

Throughput

(Service Design) A measure of the number of Transactions, or other Operations, performed in a fixed time. For example 5000 emails sent per hour, or 200 disk I/Os per second.

Total Cost of Ownership (TCO)

(Service Strategy) A methodology used to help make investment decisions. TCO assesses the full Lifecycle Cost of owning a Configuration Item, not just the initial Cost or purchase price. See Total Cost of Utilization.

Total Cost of Utilization (TCU)

(Service Strategy) A methodology used to help make investment and Service Sourcing decisions. TCU assesses the full Lifecycle Cost to the Customer of using an IT Service. See Total Cost of Ownership.



Table of Contents

Total Quality Management (TQM)

(Continual Service Improvement) A methodology for managing continual Improvement by using a Quality Management System. TQM establishes a Culture involving all people in the Organisation in a Process of continual monitoring and improvement.

Transaction

A discrete Function performed by an IT Service. For example transferring money from one bank account to another. A single Transaction may involve numerous additions, deletions and modifications of data. Either all of these complete successfully or none of them is carried out.

Transition

(Service Transition) A change in state, corresponding to a movement of an IT Service or other Configuration Item from one Lifecycle status to the next.



Table of Contents

Transition Planning and Support

(Service Transition) The Process responsible for Planning all Service Transition Processes and co-ordinating the resources that they require. These Service Transition Processes are Change Management, Service Asset and Configuration Management, Release and Deployment Management, Service Validation and Testing, Evaluation, and Knowledge Management.

Trend Analysis

(Continual Service Improvement) Analysis of data to identify time related patterns. Trend Analysis is used in Problem Management to identify common Failures or fragile Configuration Items, and in Capacity Management as a Modelling tool to predict future behaviour. It is also used as a management tool for identifying deficiencies in IT Service Management Processes.

Tuning

The Activity responsible for Planning Changes to make the most efficient use of Resources. Tuning is part of Performance Management, which also includes Performance Monitoring and implementation of the required Changes.



Table of Contents

Type I Service Provider

(Service Strategy) An Internal Service Provider that is embedded within a Business Unit. There may be several Type I Service Providers within an Organisation.

Type II Service Provider

(Service Strategy) An Internal Service Provider that provides shared IT Services to more than one Business Unit.

Type III Service Provider

(Service Strategy) A Service Provider that provides IT Services to External Customers.

U

Underpinning Contract (UC)

(Service Design) A Contract between an IT Service Provider and a Third Party. The Third Party provides goods or Services that support delivery of an IT Service to a Customer. The Underpinning Contract defines targets and responsibilities that are required to meet agreed Service Level Targets in an SLA.



Table of Contents

Unit Cost

(Service Strategy) The Cost to the IT Service Provider of providing a single Component of an IT Service. For example the Cost of a single desktop PC, or of a single Transaction.

Urgency

(Service Transition) (Service Design) A measure of how long it will be until an Incident, Problem or Change has a significant Impact on the Business. For example a high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the financial year. Impact and Urgency are used to assign Priority.

Usability

(Service Design) The ease with which an Application, product, or IT Service can be used. Usability Requirements are often included in a Statement of Requirements.

Use Case

(Service Design) A technique used to define required functionality and Objectives, and to Design Tests. Use Cases define realistic scenarios that describe interactions between Users and an IT Service or other System.

See Change Case.



Table of Contents

User

A person who uses the IT Service on a day-to-day basis. Users are distinct from Customers, as some Customers do not use the IT Service directly.

User Profile (UP)

(Service Strategy) A pattern of User demand for IT Services. Each User Profile includes one or more Patterns of Business Activity.

Utility

(Service Strategy) Functionality offered by a Product or Service to meet a particular need. Utility is often summarised as “what it does”.

See Service Utility.

V

Validation

(Service Transition) An Activity that ensures a new or changed IT Service, Process, Plan, or other Deliverable meets the needs of the Business. Validation ensures that Business Requirements are met even though these may have changed since the original Design.

See Verification, Acceptance, Qualification, Service Validation and Testing.



Table of Contents

Value Chain

(Service Strategy) A sequence of Processes that creates a product or Service that is of value to a Customer. Each step of the sequence builds on the previous steps and contributes to the overall product or Service.

See Value Network.

Value for Money

An informal measure of Cost Effectiveness. Value for Money is often based on a comparison with the Cost of alternatives.

See Cost Benefit Analysis.

Value Network

(Service Strategy) A complex set of Relationships between two or more groups or organisations. Value is generated through exchange of knowledge, information, goods or Services.

See Value Chain, Partnership.

Value on Investment (VOI)

(Continual Service Improvement) A measurement of the expected benefit of an investment. VOI considers both financial and intangible benefits.

See Return on Investment.



Table of Contents

Variable Cost

(Service Strategy) A Cost that depends on how much the IT Service is used, how many products are produced, the number and type of Users, or something else that cannot be fixed in advance.

See Variable Cost Dynamics.

Variable Cost Dynamics

(Service Strategy) A technique used to understand how overall Costs are impacted by the many complex variable elements that contribute to the provision of IT Services.

Variance

The difference between a planned value and the actual measured value. Commonly used in Financial Management, Capacity Management and Service Level Management, but could apply in any area where Plans are in place.

Verification

(Service Transition) An Activity that ensures a new or changed IT Service, Process, Plan, or other Deliverable is complete, accurate, Reliable and matches its Design Specification.

See Validation, Acceptance, Service Validation and Testing.



Table of Contents

Verification and Audit

(Service Transition) The Activities responsible for ensuring that information in the CMDB is accurate and that all Configuration Items have been identified and recorded in the CMDB. Verification includes routine checks that are part of other Processes. For example, verifying the serial number of a desktop PC when a User logs an Incident. Audit is a periodic, formal check.

Version

(Service Transition) A Version is used to identify a specific Baseline of a Configuration Item. Versions typically use a naming convention that enables the sequence or date of each Baseline to be identified. For example Payroll Application Version 3 contains updated functionality from Version 2.

Vision

A description of what the Organisation intends to become in the future. A Vision is created by senior management and is used to help influence Culture and Strategic Planning.



Table of Contents

Vital Business Function (VBF)

(Service Design) A Function of a Business Process which is critical to the success of the Business. Vital Business Functions are an important consideration of Business Continuity Management, IT Service Continuity Management and Availability Management.

Vulnerability

A weakness that could be exploited by a Threat. For example an open firewall port, a password that is never changed, or a flammable carpet. A missing Control is also considered to be a Vulnerability.

WWarm Standby Synonym for Intermediate Recovery.

Warranty

(Service Strategy) A promise or guarantee that a product or Service will meet its agreed Requirements.

See Service Validation and Testing, Service Warranty.

Work in Progress (WIP)

A Status that means Activities have started but are not yet complete. It is commonly used as a Status for Incidents, Problems, Changes etc.



Table of Contents

Work Instruction

A Document containing detailed instructions that specify exactly what steps to follow to carry out an Activity. A Work Instruction contains much more detail than a Procedure and is only created if very detailed instructions are needed.

Workaround

(Service Operation) Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record.

Workload

The Resources required to deliver an identifiable part of an IT Service. Workloads may be Categorised by Users, groups of Users, or Functions within the IT Service. This is used to assist in analysing and managing the Capacity, Performance and Utilisation of Configuration Items and IT Services. The term Workload is sometimes used as a synonym for Throughput.


ITIL v3 Intermediate Certification Level | ST | Syllabus

Table of Contents

© Crown Copyright 2008 Reproduced under license from OGC The ITIL Intermediate Qualification_Service Transition Certificate_v3.1.doc – 29 July 2008 Version 3.1 (Status – Live) Document owner – Chief Examiner

document Control Informationdocument details

document Name The ITIL Intermediate Qualification: Service Transition Certificate_v3.1

Purpose of Document

Provide a detailed syllabus for the ITIL Intermediate Qualification: Service Transition Certificate

Document Version Number 3.1

Document Status LiveDocument Owner Chief ExaminerPrepared By V3 Examination PanelDate of First Draft July 2007 Date Approved 29 July 2008 Approved By Chief ExaminerNext scheduled review date



Table of Contents


Version historyVersion Number

date Approved

Change/reasons for Change/Comments

3.0 23 June 2008 New Document

3.1 29 July 2008

Qualification name changed from “ITIL Expert Qualification” to “ITIL Intermediate Qualification” Sentence inserted under “Learning Objectives” to make consistent with other Lifecycle Syllabuses Insertion of “Terminology” table Change to pass mark and scoring system

Distribution ListVersion Name Title/Company3.0 All ITIL EIs and ATOs3.1 All ITIL EIs and ATOs



Table of Contents


Professional Qualifications for ITIL® PrACTICes for serVICe mANAgemeNT: INTermedIATe LIfeCyCLe sTreAm

The ITIL Intermediate Qualification: Service Transition Certificate SYLLABUS

The Swirl logo™ is a Trade Mark of the Office of Government Commerce ITIL® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries



Table of Contents


The ITIL INTermedIATe QuALIfICATIoN: serVICe TrANsITIoN CerTIfICATeThe ITIL Intermediate Qualification: Service Transition Certificate is a free-standing qualification, but is also part of the ITIL Intermediate Lifecycle stream, and one of the modules that leads to the ITIL Expert in IT Service Management Certificate. The purpose of this training module and the associated exam and certificate is, respectively, to impart, test, and validate the knowledge on industry practices in service Management as documented in the ITIL Service Transition publication.

Target group The main target group for the ITIL Intermediate Qualification: Service Transition Certificate includes, but is not restricted to CIOs, CTOs, managers, supervisory staff, team leaders, designers, architects, planners, IT consultants, IT audit managers, IT security managers, service test managers and ITSM trainers.

The course covers the management and control of the activities and techniques within the service Transition stage, but not the detail of each of the supporting processes.This course syllabus may also be of interest to:

y Individuals who require a detailed understanding of the ITIL Service Transition phase of the ITIL core Lifecycle and how it may be implemented to enhance the quality of IT service provision within an organisation



Table of Contents


y IT professionals working within or about to enter a Service Transition environment and requiring a detailed understanding of the processes, functions and activities involved

y Individuals seeking the ITIL Expert in IT Service Management for which this qualification is one of the prerequisite modules

y Individuals seeking progress towards the ITIL Master in IT Service Management for which the ITIL Expert is a prerequisite

Learning objectivesCandidates can expect to gain competencies in the following upon successful completion of the education and examination components related to this certification:

y Introduction to Service Transition y Service Transition Principles y Management and control of all Service Transition activities y Service Transition Related activities around

communications, commitment and organisational change y Organising Service Transition y Control and coordination of Service Transition technology

related activities y Analysis, justification and selection of the implementation

approaches, challanges, critiical success factors and risks



Table of Contents


In addition the training for this certification should include examination preparation, including a mock examination opportunity. Prerequisite entry CriteriaCandidates wishing to be trained and examined for this qualification must already hold the ITIL Foundation Certificate in IT Service Management (the V3 Foundation or V2 Foundation plus Bridge Certificate) which shall be presented as documentary evidence to gain admission. eligibility for examinationTo be eligible for the ITIL Intermediate Qualification Service Transition examination, candidates shall fulfil the following requirements:

y At least 21 contact hours (hours of instruction, excluding breaks, with an Accredited Training Organisation (ATO) or an accredited e-learning solution) for this syllabus, as part of a formal, approved training course/scheme

y There is no minimum requirement but a basic IT literacy and around 2 years IT experience are highly desirable

y Hold the ITIL V3 Foundation Certificate in IT Service Management or ITIL V2 Foundation plus the bridging certificate



Table of Contents


y It is recommended that students should complete at least 21 hours of personal study by reviewing the syllabus and the Service Transition book in preparation for the examination

Level of difficultyAll ITIL Service Management certifications use the Bloom’s taxonomy in both the construction of the learning units and in the examination which is based on this syllabus.

A learning taxonomy is a scale of the degree of difficulty in the learning process. These levels apply to the cognitive, affective and psychomotor domains of learning but in the ITIL Qualification Scheme, we deal only with the cognitive sphere.

Bloom defines six levels of learning in the COGNITIVE domain which are both sequential and cumulative. They move from the simple to the complex. This implies that in order to achieve the sixth level of learning, for example, the instructor must ensure that the previous five levels have been mastered.

The KNOWING level: Here the student is able to bring to mind or remember the appropriate material. The behavioural tasks associated with this level tax the student’s memory and include such tasks as defining, recalling, listing, recognizing, describing and naming.



Table of Contents


The COMPREHENDING stage: Here the student is able to understand or grasp the meaning of what is being communicated and make use of the idea without relating it to other ideas or materials and without seeing the fullest possible meaning or translation of the idea. Behavioural tasks at this level would include stating in the students own words, giving examples of, illustrating, inferring, summarizing and interpreting. These actions involve the knowing which has taken place at the first level.

The APPLYING level: Here the student should be able to use ideas, principles and theories in new, particular and concrete situations. Behavioural tasks at this level involve both knowing and comprehension and might include choosing appropriate procedures, applying principles, using an approach or identifying the selection of options.

The ANALYZING level: This is the fourth level of learning described by Bloom. At this level the student is able to break down a communication (rendered in any form) into constituent parts in order to make the organization and significance of the whole clear. Breaking down, discriminating, diagramming, detecting, differentiating and illustrating are important behavioural tasks at this level and can be seen to include the previous levels of knowing, comprehending and applying. Here the significance of the constituent parts of an entity are examined in order to understand the whole more fully.



Table of Contents


The SYNTHESIS level: At this level the student is able to put back together again the various parts or elements of a concept into a unified organization or whole. This putting together again and making sense of small parts is a crucial factor in intelligence and learning. Behavioural tasks at this level would include creating, writing, designing, combining, composing, organizing, revising and planning. This level of learning in order to occur must include the first four levels – knowing, comprehending, analyzing and applying. This level of learning is probably the most intense and exciting for student and teacher alike.

The EVALUATING phase: In this phase the student is able to arrive at an overview and to judge the value and relative merit of ideas or procedures by using appropriate criteria. At this level of learning the student will be able to compare, judge, appraise, justify, criticize and contrast theories, procedures, methods and concepts. This level involves mastery of the five previous levels of knowing, comprehending, applying analyzing and synthesizing.

For the purposes of the ITIL Qualifications Scheme, the Blooms level will appear in each syllabus module to identify the highest level of cognitive difficulty that course content should deliver to meet the learning outcome and competence to meet the examination level of difficulty.

The following table illustrates the use of the taxonomy in ITIL professional qualifications.



Table of Contents


Bloom Levels and taxonomy

used by ITIL certification

Intellectual activity in learning outcome and exam proficiency

Knowing Comprehending

ITIL Service Management

Foundation Level stream

(includes V2 – V3 Foundation

Bridge certification

The ability to recall, recite, name, and understand the meaning of ITIL terminology and basic practice fundamentals.

Vernacular examples used in Syllabus:

Understand; Describe; Identify



Table of Contents





Applying Analyzing


Lifecycle Stream

Capability Stream

Managing Across the Lifecycle

The ability to use the practices and concepts in a situation or unprompted use of an abstraction. Can apply what is learned in the classroom, in workplace situations. Can separate concepts into component parts to understand structure and can distinguish between facts and inferences.


Analyze; Demonstrate; Apply; Distinguish; Justify; Produce; Decide



Table of Contents





Synthesis Evaluate


Managing Across the Lifecycle – level 5 only

ITIL Service Management Professional – Advanced

Series

The ability to create patterns or structure from composite elements to achieve a new meaning or outcome. Can make judgement, weigh options of ideas and elements to justify and support an argument or case.


Evaluate; Justify; Summarize; Plan; Modify; Manage; Control

Intermediate stream qualifications will examine according to the Bloom level assigned to each syllabus learning unit within each of the Service Lifecycle and Service Capability streams. This means that a student must be prepared to be tested up to and including that level for any question related to that learning unit or units.



Table of Contents


The examination format of complex multiple choice will offer a scenario and questions with a corresponding series of possible answers. Each is constructed to test a student’s competency up to and including the bloom level associated to the syllabus learning unit that the question is mapped to. Instructors should ensure that the module curriculum offers discussion, practical exercises and instruction that will satisfy the competency needed to meet the exam level of difficulty.

The intermediate modules are expected to provide a practical level of proficiency for a student to be able to utilize the knowledge learned in their work environment. The examinations test a level of proficiency that allows students to apply the knowledge learned in the course to correctly select the correct sequence of possible answers.

service Transition syllabusThe ITIL Intermediate Qualification: Service Transition is awarded to those who complete the following seven units of study and successfully pass the relevant multiple choice examination. The units cover the topics listed (section numbers from the book are included, with indicative contact study-hours).



Table of Contents


ITIL sL: sT01 Level of difficulty – up to B l o o m level 2

Introduction to service TransitionThis unit introduces the candidate to the concepts and terminology in the field of Service Management in general and the main goals and objectives of Service Transition.To meet the learning outcomes and examination level of difficulty, the candidates must be able to understand and describe:

y Service Transition as a practice (ST 2.1) y Service, its value proposition and value

composition (ST 2.2) y Functions, Processes and Roles (ST 2.3) y The purpose, goals and objectives of

Service Transition (ST 2.4.1) y The scope of Service Transition (ST

2.4.2) and the types of processes used by Service Transition (ST 2.4.6)

y The position of Service Transition within the service lifecycle , the interfaces, inputs and outputs (ST 2.4.5)

y Potential value to business (ST 2.4.3) The recommended minimum study period for this unit is 2.5 hours.



Table of Contents



service Transition Principles This unit covers the basic guiding principles of Service Transition.

To meet the learning outcomes and examination level of difficulty, the candidates must be able to understand, describe, identify, demonstrate, apply, distinguish, produce, decide or analyze:

y The concept of service and role of utilities, warranties,capabilities and resources in delvering the service (ST 3.1)

y The key policies and best practice principles that aid effective Service Transition (ST 3.2.1 – 3.2.14)

The recommended minimum study period for this unit is 2.0 hours.



Table of Contents



service Transition ProcessesThis unit covers the managerial and supervisory aspects of the ITIL processes covered in the Service Transition stage (but excludes the day to day operation of the processes which are primarily covered in the Release, Control and Validation module).


y Transition Planning and Support (ST 4.1) y Change Management (ST4.2) y Service Asset and Configuration

Management (ST 4.3) y Release and Deployment Management

(ST 4.4) y Service Validation and Testing (ST 4.5) y Evaluation (ST 4.6) y Knowledge Management (ST 4.7)




Table of Contents



service Transition related activities This unit provides a high-level view of the communications and stakeholder management activities which support Service Transition in addition to the processes covered in ST03.


y Managing Communications and Commitment (ST 5.1)

y Managing Organizational and Stakeholder Change (ST 5.2)

o Organisational roles, responsibilities (ST 5.2.2) and Service Transitions Roles within organisational change (ST 5.2.3)

o Planning and Implementing organisational change, and the outputs from other lifecycle stages which assist with managing organisational change (ST 5.2.5 – ST 5.2.6)



Table of Contents



o Assessing organisational readiness for and monitoring progress of organisational change (ST 5.2.7 – ST 5.2.8)

o Methods, practices and techniques used in managing change (ST 5.2.10)

y Stakeholder Management (ST 5.3)




Table of Contents



organising for service Transition This unit considers the roles and responsibilities appropriate within Service Transition and the Service Transition focused capabilities. It will also cover possible Service Transition organisational structures and their applicability to different circumstances.


y Service Transition Roles and Responsibilities (ST 6.1, 6.3)

y Organizational context for Service Transition (ST 6.2)

y The relationship of Service Transition with other lifecycle phases (ST 6.4)




Table of Contents



Consideration of Technology This unit covers technology considerations for Service Transition.


y Technoogy requirements for Service Transition that support Service Transition as a whole and, support Service Transition’s integration into the whole lifecycle (ST 7)




Table of Contents



Implementation and improvement of service Transition This unit covers the implementation and improvement of Service Transition in an organisation.


y The stages of introducing Service Transition to an organisation (ST 8.1), including:

o Justification (ST 8.1.1) o Design (ST 8.1.2) o Management of cultural change

and risks and beneficial values (ST 8.1.3 - 8.1.5)

y Measurements through anaylsing critical success factors and key performance indicators (ST 9.2)



Table of Contents



y Challenges, pre-requisites for success and risks that affect the likely viability of new and changed services. (ST 9.1, 9.2, 9.3)

y Challenges facing service transition (ST 9.1) and the external factors that affect the approach to service transition (ST 9.4)


ITIL sL: sT08

summary, exam Preparation and directed studies This unit summarises the material covered in the previous units and prepares candidates for the examination. It is likely that most course providers will wish to offer, and review, at least one mock examination opportunity.




Table of Contents


Terminology that students would expected to understand after the course Terminology marked with an * is expected to be known from the Foundation Certificate

Assembly test

Asset management

Attribute

Audit

Back-out

Baseline

Benchmark*

Big bang

Build

Business value

Capability

Change advisory board (CAB) *

Change authorisation

Change initiator

Change management



Table of Contents


Change model*

Change schedule

Component test

Configuration item (CI)*

Configuration management*

Configuration management database (CMDB) *

Configuration management system (CMS) *

Contract test

Course corrections*

Cultural change

Data*

Definitive media library (DML) *

Deployment*

Early life support (ELS) *

Emergency change*

Emergency change advisory board (ECAB) *

Emotional cycle of change

Evaluation



Table of Contents


Exit criteria

Impact*

Information*

Integration test

Knowledge*

Knowledge management (KM) *

Knowledge transfer

Load testing

Organisational change

Package*

Pilot

Pull

Push

Recoverability

Regression test

Relationship*

Release*

Release and deployment management (RAD) *



Table of Contents


Release unit

Release window

Remediation*

Request for change (RFC)*

Re-use

Review

Risk*

Secure library

Secure store

Service asset and configuration management

(SACM) *

Service design package (SDP) *

Service knowledge management base (SKMB)

Service knowledge management system

(SKMS)*

Service operational readiness test (SORT)

Service provider interface test (SPI)

Service rehearsal



Table of Contents


Service release test

Service test

Stakeholder*

Stakeholder management

Stakeholder map

Standard change*

Status accounting

Stress testing

Test model

Testing*

Urgency*

Utility*

Validation

Verification

version

Warranty*

Wisdom*



Table of Contents


Note:Lecture and exercisesMeeting the learning objectives of this syllabus can be assisted through the use of practical exercises during the delivery of an accredited course. It is recommended that course providers make use of exercises to enhance the reinforcement of the learning objectives in this syllabus. To aid course providers, there are areas within each learning unit whose learning objective include such phrases as “illustrate, discuss, use examples”, etc, which may be considered as opportunities to introduce practical course exercises. These are not mandated areas for practical exercises, but provided as suggestions for use by course providers.

Learning outcomes Following the completion of this unit, the candidate will know:

y Understanding of the importance of Service Management as a Practice concept and Service Transition Principals, Purpose and Objective

y How all processes in ITIL Service Transition interact with other Service Lifecycle Processes

y What are the sub-processes, activities, methods and functions used in each of the ITIL Service Transition processes



Table of Contents


y The roles and responsibilities within ITIL Service Transition and the activities and functions to achieve operational excellence

y Explain how to measure ITIL Service Transition y Understanding of technology and implementation

considerations surrounding ITIL Service Transition y Challenges, Critical Success Factors and Risks associated

to ITIL Service Transition

format of the examination

Type

Eight (8) multiple choice, scenario-based, gradient scored questions. Each question will have 4 possible answer options, one of which is worth 5 marks, one which is worth 3 marks, one which is worth 1 mark, and one which is a distracter and achieves no marks.

Duration

Maximum 90 minutes for all candidates in their respective language (Candidates sitting the examination in a language other than their first language have a maximum of 120 minutes and are allowed to use a dictionary)

Prerequisite

ITIL V3 Foundation Certificate or ITIL V2 Foundation plus Bridge Certificate and completion of an accredited Course from an ITIL Accredited Training Provider



Table of Contents


Supervised YesOpen Book NoPass Score 28/40 or 70%Distinct ion Score TBC

Delivery Online or Paper Based Examination

Criteria of Training Competence This syllabus can only be delivered to target groups by an accredited provider / trainer. Any provider/trainer must hold the following qualifications to be eligible to provide this syllabus:

Criteria eligibility degree of proficiency validationAccredited Training Organization

RequiredThe company shall be registered and in good standing with the Official Accreditor

ITIL Service Transition Certification

RequiredInstructor must present a valid certificate issued by an accredited Examination Institute

ITIL V3 Expert Certification

RequiredInstructor must present a valid certificate issued by an accredited Examination Institute



Table of Contents


---------------------

e N d o f

d o C u m e N T ---------------------