IBM Global Change Management Process 15-OCT-2018 v3.2

IBM Global Technology Services
Global
Change Management
Process
Document Owner: Sebastian Blanco Manley/Costa Rica/IBM
Author: Sebastian Blanco Manley/Costa Rica/IBM
Document Revision Number: 3.2
Revision Date: 10-OCT-2018
Effective Date: 15-OCT-2018

Revision 3.2 Global Change Management Process
Table of Contents
1 Document Control ............................................................................................................................... 4
1.1 Summary of Changes ............................................................................................................... 4
1.2 Document Approvers ................................................................................................................ 5
1.3 Document Review Plans .......................................................................................................... 5
1.4 How to Find the Latest Revision of this Document................................................................... 6
1.5 Document Distribution and Notification .................................................................................... 6
2 Description & Client Value ................................................................................................................. 7
2.1 Summary .................................................................................................................................. 7
2.1.1 Overview ................................................................................................................................... 7
2.1.2 Objectives ................................................................................................................................. 7
2.2 Client Value .............................................................................................................................. 8
2.2.1 Performance / Quality ............................................................................................................... 8
2.2.2 Expertise and Innovation .......................................................................................................... 8
2.2.3 Adaptability & Flexibility ............................................................................................................ 8
2.2.4 Risk Management ..................................................................................................................... 8
2.2.5 Financial ................................................................................................................................... 8
3 Scope .................................................................................................................................................... 9
3.1 Inclusions .................................................................................................................................. 9
3.2 Exclusions ................................................................................................................................. 9
3.3 Multi-Provider Integration ....................................................................................................... 10
3.4 Environment and Audience .................................................................................................... 10
4 Roles and Responsibilities .............................................................................................................. 11
4.1 Customer Liaison .................................................................................................................... 11
4.2 Change Analyst ...................................................................................................................... 11
4.3 Change Manager .................................................................................................................... 13
4.4 Integrated Service Manager ................................................................................................... 14
4.5 Change Assessor ................................................................................................................... 15
4.6 Change Advisory Board Member ........................................................................................... 15
4.7 Emergency Change Advisory Board Member ........................................................................ 16
4.8 Change Authority .................................................................................................................... 16
4.9 Separation of Duties Aggregate Matrix .................................................................................. 16
5 Workflow Diagram Notation ............................................................................................................. 17
6 Activity Workflow .............................................................................................................................. 18
6.1 Activity Workflow Diagram ...................................................................................................... 18
6.2 Activity Workflow Narrative ..................................................................................................... 18
7 Task Workflow for Review Request For Change (RFC) ................................................................ 20
7.1 Task Workflow Diagram ......................................................................................................... 20
7.2 Task Workflow Narrative ........................................................................................................ 20
8 Task Workflow for Document and Assess Change ....................................................................... 27
9 Task Workflow for Coordinate Change Build & Test..................................................................... 37
10 Task Workflow for Authorize Change .......................................................................................... 41
11 Task Workflow for Coordinate Change Deployment .................................................................. 51
12 Task Workflow for Review and Close Change ............................................................................ 54
© IBM Corporation, 2018 Page 2 of 89


13 Task Workflow for Monitor, Track & Report Changes................................................................ 58
14 Task Workflow for Maintain Standard Change List .................................................................... 65
15 Service Provider Integration Data flow ........................................................................................ 68
15.1 Integration Roles and Responsibilities ................................................................................... 68
15.1.1 Service Provider Process Focal ........................................................................................ 68
15.2 Integration Data Flow Diagram ............................................................................................... 68
15.3 Integration Data Flow Narrative .............................................................................................. 69
15.4 Integration Measurements ...................................................................................................... 72
16 Controls and Measurements ......................................................................................................... 74
16.1 Control Points ......................................................................................................................... 74
16.2 Measurements ........................................................................................................................ 75
16.2.1 Output Metrics ................................................................................................................... 76
16.2.2 KPIs ................................................................................................................................... 76
17 Process Interdependencies .......................................................................................................... 78
18 Standards & Policies...................................................................................................................... 81
18.1 Applicable Standards .............................................................................................................. 81
18.2 Policies ................................................................................................................................... 81
19 Artifacts and Deliverables ............................................................................................................. 83
20 Glossary .......................................................................................................................................... 84
End of Document ...................................................................................................................................... 89

1 Document Control
1.1 Summary of Changes

Revision
Number Revision Date Author or Editor Nature of Change
2.0 2015-Aug-17 Jabe Hickey Initial pRAM Release Prior versions were stored in
ITUP
2.01 2016-Mar-04 Brett Singletary Updated with recommendations from BCR
2.02 2016-Jun-13 Soumitro Chatterjee Updated measurements section with definitions

2.03 2017-Jan-12 Melissa Ortiz Updated adding the ISM Role to section 5, reviewed
by the Global Process Leader
2.04 2017-Jan-16 Bastian Lorek Flowcharts updated to reflect ISM role
3.0 2017-Apr-16 Melissa Ortiz Approved my Global SMEs and SIAM Project Lead
 Updated inputs and outputs structure and in-
Sebastian Blanco Man- cluded process interdependencies on activity
ley narratives, updated description and scope
based on request from IT Risk & Compliance
team
 Modified specific responsibilities to remove
duplicates within a same role
 Listed examples of functional roles for every
Change Management role
 Removed Change Administrator role and
moved responsibilities under Change Manager
 Updated format on activity workflows
 Updated wording on control point CHGCP1 to
mention Change Record Logging policy
Updated Environment and Audience to address audit
conditions
3.1 2017-Sep-18 Sebastian Blanco Man- Updated ITIL trademark attribute
ley

Revision
Number Revision Date Author or Editor Nature of Change
3.2 2018-Oct-10 Sebastian Blanco Man-  Updated 16.1 Control Points to include man-
ley datory metrics.
 Updated verbiage on 16.2 to clarify distinction
between mandatory and recommended met-
rics
 Added a new section under Scope, 3.3 Multi-
Service Provider Integration and 15 Service
Provider Integration Data flow
 Removed the Integrated Service Manager role
from activities:
o 1.5 Reject RFC
o 2.2 Request Change Implementation
Window
o 2.4 Schedule Change
 Included GTS Service Provider Integration
Policy on missing activities
 Updated text on section 3.3 Multi-Provider In-
tegration
 Updated table on 15.3 Integration Narrative to
show Criteria instead of When/Why
 Added section 15.1 Integration Roles and Re-
sponsibilities. Added Service Provider Process
Focal role
1.2 Document Approvers

Document approval is maintained in the repository and can be found at: https://w3-
01.ibm.com/services/pram/oslc/assets/4634F4E6-D688-1924-9094-46E2DC024BBC/*
1.3 Document Review Plans

Necessary reviews and updates to this document are defined below:
 According to a regularly scheduled review cycle
 As required to correct or enhance information content

1.4 How to Find the Latest Revision of this Docu-

ment
The latest revision of this document may be obtained as follows:
 IT Service Provider Personnel: https://w3.ibm.com/services/pram/oslc/assets/4634F4E6-
D688-1924-9094-46E2DC024BBC/*
1.5 Document Distribution and Notification

 Printed copies are for reference only and are not controlled.
 Obtain and use only the current, approved document.

2 Description & Client Value
2.1 Summary
2.1.1 Overview
The purpose of the Change Management process is to achieve the controlled and successful introduction
of changes to an IT system or environment. Success is measured in function of the completeness of
change implementation, the adherence to the plan (in terms of time, effort, result), and the avoidance of
unplanned disruptions to the target system or environment. The process also ensures that the appropriate
details of Configuration Item changes are reflected in the Configuration Management System by the re-
sponsible process.
A Change is defined as the addition, modification or removal of any Configuration Item (CI). This typically
includes hardware, network devices, and virtual assets such as virtual servers or storage, system and
application software, environmental facilities and associated documentation.
This includes also logical changes to CI status, for example changing the CI status of a CI that already
has been physically installed (i.e. service activation).
A Request for Change (RFC), for which Change Request is an established synonym, is the means for
documenting a proposed change. RFC’s can be triggered for a wide variety of reasons, from a wide varie-
ty of sources. Reasons could be, but are not limited to:
 Addition of a new function (e.g. install application)
 Updating an existing function (e.g. new application version)
 Capacity increase (e.g. add disk space)
 Security update (e.g. implement security patch)
 Incident resolution (e.g. replace malfunctioning part)
 Problem resolution (e.g. change communication settings)
 Scheduled reboot of a server to resolve an incident
 Service activation and deactivation (decommissioning)
The actual change activity is documented by means of a Change Record. The Change Record refer-
ences the Configuration Items that are being modified by the change and is created once the RFC has
been reviewed and accepted by Change Management.
Depending on the situation, a reboot of a server requires change management control. If a change is re-
quired it must be determined when the incident resolution approach is made (Incident Management).
Global processes provide the primary requirements for execution teams. However, Client Management
must also source any customer specific contractual requirements that may require a process variation
(typically additional actions or requirements) or a process exception (if a global process control point can-
not be deployed) to be created.
2.1.2 Objectives
This section lists the Process Objectives, which are specific targets to be hit by the process. The objec-
tives of this process are listed below:
 Ensure Changes are introduced in a timely and controlled manner

 Ensure proposed Changes are not approved nor introduced without an accurate assess-
ment of their costs, availability of service, risk, and other effects
 Minimize Incidents resulting from the introduction of Changes
 Improve Service quality
 Ensure appropriate balance is maintained between the business need to deploy innova-
tion and the need to maintain the stability of IT service
2.2 Client Value

This section covers key aspects of the value added by utilizing a robust Change Management process
throughout its entire lifecycle. These key aspects of the process provide reliability and business continuity
for the success of an organization. Some of these key aspects are defined by:
2.2.1 Performance / Quality

Client Value can be expressed in the following terms for Performance / Quality:
◦ Provide guidance to generate auditable evidence of Change Management activities
◦ Assign accountability to one single party that will be responsible for escalation and notification of
change records
◦ Create actions based on identified failed changes
◦ Notify all concerned parties involved
◦ Improve visibility of the process across the enterprise
▪ Define tasks and roles for each Change Management Activity
2.2.2 Expertise and Innovation

None
2.2.3 Adaptability & Flexibility

Client Value can be expressed in the following terms for Adaptability & Flexibility:
◦ Provide guidance to identify and apply different type of changes
◦ Provide guidance to deal with urgent changes and changes that can’t comply with lead times
2.2.4 Risk Management

Client Value can be expressed in the following terms for Risk Management:
◦ Improve classification of change risk by using technical and business assessment
2.2.5 Financial
None

3 Scope
The scope of the process is defined by a series of activities and tasks outline within this document. They
cover the lifecycle of the Change Management process end-to-end.The process is triggered by a RFC
(Request for Change) that may be originated from other processes.
Additionally, the scope is also defined by the following inclusions and exclusions, and applies in the speci-
fied environment and has the intended audience as specified below:
3.1 Inclusions
 Planning, coordination and communications for Normal, Standard and Emergency
changes
 Establishing customer-agreed recurring Change Windows and proposing one-time only
time-frames during which to deploy changes
 Maintaining the Forward Schedule of Change (FSC)
 Enforcement of standard methods, policies and procedures from submission of a Re-
quest for Change through Review & Close Change
 Establishing regular meetings and communication schedules to evaluate proposed
changes and schedules
 Coordination of the deployment of authorized changes
 Maintenance of open channels of communications to promote smooth transition when
changes take place
 Identifying and analyzing change failures
Visibility and communication of changes to both business and support staff
Global processes provide the primary guidance for execution teams. However, the Customer Security
Document (CSD) documents additional requirements and specific contractual obligations. It is important
that the CSD is checked to determine whether a process variation or exception is required.
Consult governing policy and/or customer requirements from Client Management for consideration of lo-
cal regulatory and customer specific requirements on privacy restrictions including, additional approval
requirements for access to sensitive personal information (SPI) and for obtaining required credentials,
such as certifications and/or security clearance, on-boarding restrictions, access restrictions, etc.
3.2 Exclusions
 Creating and recording Requests for Change (originating process)
 Verifying requestor's entitlement to request changes and whether request is in scope of
contract/budget (Request Fulfillment)
 Costing/Billing for new services (Request For Service process)
 Requirements Management (Request For Service process)
 Creation of new or revised functionality (Request For Service process)
 User ID changes and administration (Logical Identity and Access Management)

 Building the packaging for the delivery of new or revised functionality (Release Manage-
ment)
 Technical implementation, such as preparation, installation, distribution and remedia-
tion/back out if necessary (Deployment Management)
 Updating CI data (Configuration Management)
 Updating asset data (Asset Management)
 Performing Root-Cause-Analysis for failed changes and tracking actions against recur-
rence (Problem Management)
3.3 Multi-Provider Integration

In a multi-provider environment, the need for clearly defined process interfaces is critically important. In a
GTS-led contract, whenever other IBM services are delivered alongside Infrastructure Services managed
services, the interfaces or ‘touch-points’ between the GTS process and the Service Provider (SP) process
must be described in the Integration Data Flow section of this document.
In a multi-provider environment for the management of changes:
 Service Providers initiated changes are reviewed for acceptance / rejection
 Change schedule information is exchanged between the Service Provider and GTS
 Service Providers are informed on the authorization of their changes or changes with tasks as-
signed to them
 Service Providers changes requiring attention are analyzed for potential actions
The Process Integration Manual document provides additional details to support process in-
tegration with IBM Service Providers. The Process Integration Manual for this process is
published in pRAM as a supporting document to the process / service flow.
3.4 Environment and Audience

 GTS IS Accounts across all Geos
 Geo / Market process leads, Account Management team, Delivery Teams, Transition &
Transformation teams

4 Roles and Responsibilities

The roles involved in this process, and the responsibilities associated with those roles, are listed in the
following sections:
 Responsibilities include, but are not limited to, those listed for each role
 Roles are meant as logical groupings of tasks. They are not intended to match any particular
organizational structures or formal functional roles
 Several roles may be performed by the same individual
 A role may be split up among several individuals
4.1 Customer Liaison

The Customer Liaison serves as the primary liaison between the customer (not the user) and the IT or-
ganization and promotes interaction between the two. This role helps the customer identify the most ap-
propriate point of contact within the IT organization and helps clarify communication between the two par-
ties.
This role may be performed by multiple functional roles, for example:
 Delivery Process Executive (DPE)
 Service Integration Leader (SIL)
 Business Program Manager – Service Management Process Integration
 Service Coordinator – Change Management
Specific responsibilities in the Change and Release Management processes include:

 Coordinating and communicating change/release related aspects between the IT organi-
zation and the customer
 Negotiating end-user down time and change/release scheduling/rescheduling with cus-
tomer
 Attending the CAB meetings in order to review and advise on changes/releases of certain
change risk
4.2 Change Analyst

The Change Analyst is the individual within a support group that accepts responsibility to coordinate a
given change from taking ownership through closure. This includes coordination across support groups. It
may include coordinating multiple related changes when a change undertaking requires multiple change
records.
 Network Service Specialist
 Technical Operations Analyst
 Infrastructure Specialist
 Application Database Administrator

Specific responsibilities include:

 Working with other stakeholders to ensure that the tasks are resolved/completed effec-
tively
 Creating or updating records to show that activities have been carried out per process
 Receiving, reviewing and analyzing assignments to perform process activities and mak-
ing sure they are resolved/completed as required by the process
 Engaging appropriate analysts/specialists as needed to complete assigned activities
 Initiating escalations related to assigned activities
 Evaluating effectiveness of completed assignments
 Accepting/rejecting Requests for Change from the queue of RFCs of their own support
group and requesting complementary information from the Requestor, as required
 Notifying Requestor in case of a rejected Request for Change
 Documenting a Change Record with all required information based on the accepted Re-
quest for Change
 Performing initial assessment of priority, impact to IT services, failure probability and
change risk
 Working with the Release/Deployment Managers to obtain a suitable Change/Release
deployment schedule and confirmation of support group resource availability
 Notifying the Change Manager and the Customer Liaison, and ISM where required, in
case of detected scheduling conflicts
 Determining the need for technical and business change assessments and providing
business and/or technical information as required
 Reviewing assessment results and making updates to the Change Record details if
needed
 Assigning the right Change Assessors and Change Authority to a change and obtaining
authorization
 Participating in CAB meetings to represent proposed changes
 Monitoring and reviewing activities of teams and functions that build, test and deploy the
change to ensure that the work is carried out correctly and in a timely manner
 Conducting Post-Implementation Review with relevant roles/functions, including the Re-
questor for customer concurrence
 Ensuring that Deployment Management roles correctly document deployment results in-
cluding any required incident documentation
 Ensuring correct documentation of change validation and change outcome (successful
vs. failed)
 Closing change records
 Notifying the Change Manager in case of unsuccessful or unauthorized changes or the
ISM for multi service delivery environment
 Recording a new Request for Change as needed if follow-up work is required after the re-
lease/change deployment (if not already done by Deployment Management)
 The Change Analyst may act as the Deployment Specialist, deploying or implementing
the change

 The Change Analyst is accountable and has the responsibility for documenting, updating
and completing a Change from assignment to re-assignment/closure
 The Change Analyst is accountable and responsible to invoke other processes (i.e. de-
ployment management) and engage other Change Analysts/support groups to perform
parallel activities, as required
 The accountability for the coordination of the change activities between multiple Change
Analyst/support groups is that of the Change Analyst
4.3 Change Manager

The Change Manager ensures that the Change Management process is executed and is accountable for
day-to-day management and the integrity of the process. He/she is the main coordinator within this pro-
cess and is the focal point regarding changes for the IT organization.
 Business Programs Manager: Change Management

 Acting as focal point for process execution to the IT organization and other stakeholders
 Building upon the defined Process Framework to provide process lifecycle management
 Performing/coordinating day to day process management
 Providing input for process improvement and facilitating process improvement implemen-
tation as applicable
 Identifying and submitting process exceptions and deviations for review and approval
 Being accountable for creation and maintenance of process/procedure documentation
required for approved variation and deviation of standard processes/procedures and ad-
ditional procedures, as needed
 Ensuring that the standard procedures are communicated to practitioners
 Utilizing the appropriate reporting management system to provide process performance
reports, trending, and analysis
 Following defined escalation path when needed, as defined in the escalation policy
 Monitoring and tracking process execution activities to identify, initiate and manage re-
quired action to meet service level agreements
 Taking appropriate action in case of negative process performance trends
 Owning, maintaining and publishing the authorized Forward Schedule of Change and
Projected Service Outage - as applicable (PSO)
 Identifying requests for change or changes that have not been acted upon in a timely
manner and taking appropriate action
 Taking corrective action or escalating in case of issues with the interfaced processes, Re-
lease Management and Deployment Management when the performance of the Change
Management process is impacted or related SLAs are at risk

 Preparing list of successful and failed changes closed for review at CAB meeting
 Preparing the CAB meeting, including inviting of participants, creating of agenda, creation
and circulation of Forward Schedule of Change and Projected Service Outage (PSO) - as
applicable
 Chairing the Change Advisory Board (CAB) and Emergency Change Advisory Board
(ECAB) meetings
 Ensuring all applicable changes on the Forward Schedule of Change are reviewed
 Ensuring that authorized changes are communicated in a timely manner
 Owning and maintaining the Standard Changes List
 Generating process-related reports and communicating them to subscribed stakeholders
 Assisting in overseeing current status of change records and tracking progress
 Assisting in notifying stakeholders when action from them is needed and tracking action
completion
 Assisting in applying escalation procedures when action item status requires it
4.4 Integrated Service Manager

In the Multi Service Delivery Structure, the Integrated Service Manager may also act as a requester on
behalf of other service providers.

 Overseeing the execution of multi service provider changes
 Communicating to other service providers any compliance issues and risks based on the
agreed Change Management Procedure and policies
 Participating in CAB Meetings to review and assess High Risk, Major and Critical category
Changes
 Participating in ECAB Meetings to review and assess multi-service provider emergency
changes
 Escalating any issues that arise from a multi-service provider environment to Change Man-
ager and Change Analyst as required
 Responding and managing issues escalated by other process managers
 Assisting resolution of conflicts in the FSC, while negotiating adjustments across multi-
service providers
 Assessing and Approving multi service provider major and critical changes
 Providing input to Change Manager for assignment/reassignment for multi-service provider
changes

4.5 Change Assessor

The Change Assessor role performs technical and business change assessments from the viewpoint of
an area of expertise. There may be multiple Change Assessors assessing a single change.
 Network Service Specialist
 Technical Operations Analyst
 Infrastructure Specialist
 Application Database Administrator
 Delivery Process Executive (DPE)
 Service Integration Leader (SIL)

 Performing business assessment of changes of certain change risk level regarding im-
pact and risk to the business environment of the customer(s)
 Performing technical change assessment regarding impact and risk to the IT services
provided to the customer(s)
 Reviewing all elements of the Change Plan
 Verifying that the implementation schedule and the Projected Service Outage (PSO) is
acceptable to the affected support groups/functions/customers
 Verifying that the implementation schedule is not in conflict with schedule constraints
(e.g. change freeze periods, other change activities)
 Providing timely documentation of their position by formally signing-off a proposed
change or by communicating their reason for not signing-off to the coordinating Change
Analyst
4.6 Change Advisory Board Member

A Change Advisory Board (CAB) is a body that assists in the prioritization, assessment and schedul-
ing of some of the proposed Normal Changes and that advises the Change Authority whether those
changes should be authorized. In addition, the CAB may review the list of failed changes and may
request raising a Problem to obtain RCA about frequent or repeating change failures (if not already
done by Incident Management).
The CAB Member has the same duties as the Change Assessor role, except that it does not have to
formally sign-off a change, only to make a recommendation. The CAB Member may also be required
to review the list of failed changes.
If urgency does not allow for a proposed change to be reviewed at the regular Change Advisory
Board meeting, the members of the CAB can alternatively be invoked as Change Assessors.

4.7 Emergency Change Advisory Board Member

An Emergency Change Advisory Board (ECAB) is a body that assists in the assessment and scheduling
of Emergency Changes and that advises the Change Authority whether those changes should be author-
ized.
The ECAB Member has the same duties as the Change Assessor role, except that it does not have to
formally sign-off a change, only to make a recommendation.
The ECAB is an optional body, ECAB Member an optional role.
4.8 Change Authority

The Change Authority has the power to make the final decision whether a change is authorized or reject-
ed for implementation. The Change Authority may consist of an individual, a manager, an executive, or a
team of people. The appropriate Change Authority will be dependent upon the type, risk and organiza-
tional scope of a proposed change.
 DPE

 Weighting the opinions and positions of the Change Assessors and the Change Advisory
Board
 Reviewing technical and business assessment results
 Reviewing impact and risk to the IT services delivered to the customer and to the cus-
tomer’s business environment
 Reviewing results of change/release tests
 Ensuring that the implementation schedule and the Projected Service Outage (PSO) has
been accepted by the customer(s)
 Reviewing that all relevant concerns or issues have been handled or mitigated
 Making a timely decision whether a proposed change is authorized or rejected, recording that
decision and communicating it to relevant roles
4.9 Separation of Duties Aggregate Matrix

Use this link to access the centralized SOD (Separation of Duties) Matrix for this process:
https://w3.ibm.com/services/pram/oslc/assets/424721AD-B3EE-E101-7205-E4E827D4CD84/*

5 Workflow Diagram Notation

The following workflow diagram notation represents the main standards, as defined by Business Process
Model and Notation (BPMN), for use creating and interpreting workflow diagrams in this document.
Activities (Tasks, Steps) Events (Start, End, Connectors)
Notates the start of a workflow

Notates activities
Activity
and tasks
Notates intermediate events
including on-page references
Activity with Notates an activity with Notates the end of a workflow

Task Flow associated task flow
Notates a call FROM an off-page
Notates an activity or workflow which does not return
Activity with task with an associated Notates a call TO an off-page
Business Rule business rule – KPI, workflow which does not return
control point, or policy
Notates a call to an
external workflow, which Sequence
Call Activity
executes, then returns Lines
and continues to the
next activity Notate the execution
order of activities
Gateway (Decision Box)
Splits the flow and Swimlane

follows only one of
two or three paths Notates responsibility
Role
for activities and tasks

6 Activity Workflow
Processes are described at two (2) levels; a) Activity, and b) Task. The Activity Workflow diagram and
associated narrative are an articulation of the overall (end-to-end) process. Each activity in the Activity
Workflow decomposes into a Task Workflow. A Task Workflow is an articulation of the overall (end-to-
end) work performed for the associated Activity. Process Activities and Tasks are focused on the “What”
is done level of description. The “How” level of description is not appropriate for processes, and is the
main focus of procedures.
6.1 Activity Workflow Diagram

The Activity Workflow Diagram is a visual articulation of the end-to-end process. It should articulate a
clear architecture of the main functions of the Process which will be the framework for driving the task
flow process decomposition chapter(s) that follows this chapter.
Change Management Top Level Diagram
2.0 Document 5.0 Coordinate

3.0 Coordinate 4.0 Authorize 6.0 Review &
Start 1.0 Review RFC and Assess Change
& Buid Test Change Close Change
Change Management
Change Deployment
7.0 Monitor, 8.0 Maintain

Track & Report Standard End
Changes Change List
6.2 Activity Workflow Narrative

The Activity Workflow Narrative, which accompanies the Activity Workflow Diagram, is a textual articula-
tion of the end-to-end process.
ID Description
1.0 Review RFC (Request For Change)

RFCs originate from multiple processes, such as Request Fulfillment, Incident Management, Prob-
lem Management, Configuration Management, Availability Management, Request for Services
(RFS) and others.
RFCs for new services or those outside standard maintenance are received from the Request Ful-
fillment process or RFS process which has verified entitlement, determined new/adjusted scope
and completed financial assessment prior to submitting to Change Management process.
2.0 Document and Assess Change
This activity describes the steps related to creating the change plan, scheduling, assigning asses-
sors and authority, gathering technical and business impact assessments.

ID Description
3.0 Coordinate a Change Build & Test

This activity describes the steps related to coordinating the change build and test steps and ad-
vancing for authorization.
4.0 Authorize Change
This activity describes the steps related to the review and final decision to authorize or reject nor-
mal and emergency changes.
5.0 Coordinate Change Deployment
This activity describes the steps related to monitoring and coordinating the change deployment of a
normal, standard or emergency change.
6.0 Review & Close Change
The activity describes the steps related to the review and closure activities for an attempted or de-
ployed change.
7.0 Monitor, Track and Report Changes
This activity is run in parallel with 1.0 – 6.0 to monitor the change management process for overall
forward progress, identifying changes requiring action, recording and performing action(s) and then
notification of action(s) as needed.
8.0 Maintain Standard Change List
This activity describes the steps required to revalidate and update the Standard Changes List, e.g.
update, addition or removal.

7 Task Workflow for Review Request For

Change (RFC)
7.1 Task Workflow Diagram

The Task Workflow Diagram is a visual articulation of an end-to-end Activity of the process.
Review Request for Change (RFC)
1.3 Obtain
Yes Additional
Information
1.1 Receive 1.7 Create Change

1.6 Determine
Start Request for No Yes Record
Change
Change Type
CHGCP1
Change Analyst
1.2 Additional Info 1.4 RFC Acceptable?

Needed?
No
CHG 2.0
1.5 Reject RFC
Originating Process
7.2 Task Workflow Narrative

The Task Workflow Narrative, which accompanies the Task Workflow Diagram, is a textual articulation of
an end-to-end Activity of the process.
Role ID Description

Role ID Description
Change 1.1 Receive Request For Change

Analyst Monitor for and receive incoming RFC
Inputs:
a) Process Interdependencies
None
b) Operative & Informative Information
 Notification of new RFC
Outputs:
 Third Party Supplier
None
Policies
 Policy - Change Accountability Policy
 Policy – GTS Service Provider Integration
Controls & Measurements

None
Change 1.2 Additional Info Needed?
Analyst Determine if additional information is needed to continue processing the RFC.
 If Yes, proceed to CHG 1.3 Obtain Additional Information
 If No, proceed to CHG 1.4 RFC Acceptable?
Inputs:
None
None
Outputs:
None
None
Policies
 Policy – Request for Change Details

None

Role ID Description
1.3 Obtain Additional Information

Obtain information needed to continue processing the RFC and update the RFC.
This could involve either sending the request back to the Requestor for more in-
formation or by requesting the information directly. If the Requestor fails to pro-
vide the required information, the RFC will be rejected.
Inputs:
 Request Fulfillment
 Incident Management
 Problem Management
 Availability Management
 Configuration Management
 Request for Service (RFS)
None
Outputs:
None
None
Policies
None

None

Role ID Description
1.4 RFC Acceptable?

Determine if the RFC is acceptable.
 If Yes, proceed to CHG 1.6 Determine Change Type
 If No, proceed to CHG 1.5 Reject RFC
Note: The change is rejected because it falls outside of acceptable policy. This
may be for a number of reasons, including:
 The change is unreasonable or impractical
 The requested change is already under consideration
 The record for an emergency change type is only created at this stage if time
permits. Else, the emergency change record can be created and processed
after the change implementation. At least basic non-electronic records are to
be made during emergency change activities in order to record the change
accurately.
 As required per the change notification policy, notify stakeholders (e.g. if
emergency change, urgent normal change, etc.).
Inputs:
None
 Submitted Request for Change (RFC)
Outputs:
 Release Management
 Standard Change Record
 Normal Change Record
 Emergency Change
Policies
 Policy - Change Record Logging
 Policy - Change Notification
 Policy - Change Type
 Policy - Standard Change
 Policy - Change Risk and Lead Time

 Control Points - (CHGCP1) Ensuring Changes are Recorded

Role ID Description
Change 1.5 Reject RFC

Analyst Reject the proposed change and notify the originating process about the rejec-
tion. Provide all data and information about why the change was rejected.
Information should be provided concerning how to appeal the rejection.
When an escalation is in place or a record of interest exists in the multi-service
provider environment, the Integrated Service Manager will be responsible to notify
the rejection to the appropriate parties.
Inputs:
None
None
Outputs:
None
 Rejected RFC
Policies
 Policy - GTS Service Provider Integration Policy

None
Proceed to Originating Process

Role ID Description
Change 1.6 Determine Change Type

Analyst Determine the Change Type.
Refer to the Change Type Policy and ensure the correct change type is used.
There are three types of change.
 Standard
 Normal
 Emergency
For Emergency change: process controls are not sacrificed. The process model
for this change type is optimized to be fast enough and yet ensure the appropriate
extent of activities.
Inputs:
None
None
Outputs:
None
None
Policies
 Policy – Change Type

None

Role ID Description
Change 1.7 Create Change Record

Analyst Create a Change Record (CR) from the RFC. Ensure that any originating RFC
record is linked with the Change Record (e.g. Service Request, Incident, Problem
records, etc.).
For an emergency change or an urgent normal change, record the valid justifica-
tion per change type policy.
Proceed to CHG 2.0 Document and Assess Change
Inputs:
None
None
Outputs:
 Request Fulfillment
None
Policies
 Policy - Change Record Logging

 Control Point - CHGCP1

8 Task Workflow for Document and Assess

Change

Document and Assess Change
Release
Management CHG 5.0
Deploy Standard
2.1 Perform Management
Preliminary 2.4 Schedule 2.7 Engage
Change Analyst
Start Normal No
Assessment & Change Customer Liason
Create Change Plan
2.3 Which 2.5 Change 2.6 Meets
Process to CHG 3.0
Type? Customer Data?
provide Emergency Yes
Window?
Signed-Off
2.9 Assign Change 2.12 Receive &
2.10 Submit CR for
Assessor & Document
Assessment
Authority Assessment
2.13 Proceed
Based on
Assessments
Reassess
2.11 Perform
Assessor
Change
Change
Assessment(s)
CHGCP3
Customer
Liaison
2.8 Obtain
Agreement on
Schedule
2.2 Request Change

Reschedule
Implementation
Change Analyst
Reschedule
from CHG 2.7
Reschedule
from CHG 4.10

Role ID Description

Role ID Description
Change Ana- 2.1 Perform Preliminary Assessment & Create Change Plan
lyst Based on the information provided in the RFC, confirm the urgency of the
change. Assess the impact and failure probability of the change and assign the
change risk from it. Update the priority of the change, which is comprised of im-
pact and urgency. Change type, change risk and change priority define the spe-
cific process model to be followed, which affects the route through the process
and the level of detail the process activities are performed. Therefore, each sub-
sequent assessment will review the impact, failure probability and priority.
Create and record the Change Plan. Seek collaboration from other roles as
needed. The Change Plan is key information to be reviewed by the various
Change Assessor stakeholders during assessment.
Record any target change delivery window (due date) if specified by the Reques-
tor.
Based on the Change Plan, create change implementation tasks for the change
and assign them to the appropriate support groups.
Inputs:
None
 Standard CR
 Normal CR
 Emergency change
Outputs:
None
None
Policies
 Policy - Standard Change
 Policy - Change Priority
 Policy - Change Window
 Policy - Change Plan
 Policy - Change Type

 Control Point - (CHGCP2) Change Prioritization (Impact and Urgency factors)
 Control Point - (CHGCP3) Change Risk Categorization (impact and failure
probability factors)

Role ID Description
Change Ana- 2.2 Request Change Implementation Window

lyst Request a suitable change implementation window from the change stake-
holders and deployment specialist (implementer), avoiding conflicts with al-
ready scheduled changes or schedule constraints as indicated on the For-
ward Schedule of Change.
If a change needs to be packaged into a release or if it represents a release in-
voke the Release Management process for schedule coordination (release cal-
endar).
Agree on a realistic change implementation window with the Deployment Special-
ist (implementer) – and the Release Manager as appropriate – and request their
formal confirmation and resource commitment. Include the needed change infor-
mation in the request.
In the multi-service provider environment, additional steps may be taken by the
Integrated Service Manager to request information regarding the change imple-
mentation window.
Emergency Changes do not require formal interaction or commitment from the
Deployment Specialist (implementer). However, they are consciously scheduled
in direct coordination with the implementing support group(s) working the underly-
ing incident.
Note: This activity is also an entry point for a reschedule.
Rescheduling notification may be received from one of the following:
 Assess & Evaluate Change sub-process due to assessment feedback
 Deployment Management due to scheduling conflicts
 Coordinate Change Build and Test sub-process due to extended test cycle
 Authorize Change sub-process due to reschedule decision from authorization
phase
Inputs:
 Deployment Management
 Notification of need to reschedule
 Forward schedule of Change (FSC)
Outputs:
 Request to Deployment Specialist (Implementer)
 Request to Release Manager (Optional)
Policies
 Policy - Change Schedule Conflicts/Rescheduling
 Policy - Change Schedule Constraints Notification Policy
 Policy - GTS Service Provider Integration Policy

None

Role ID Description
Change 2.3 Which Process to Provide Window?

Analyst Release or Deployment Management provide change implementation windows
for Change Management
If Release Management, proceed to the Plan Deployment Program Activity in the
Release Management Process
If Deployment Management, proceed to the Plan Deployment Program Activity in
the Deployment Management Process.
Note: The Release and Deployment processes communicate with each other and
with Change Management in parallel to reach consensus on a viable change im-
plementation window.
Change 2.4 Schedule Change
Analyst Update the change record with the agreed change implementation window. Also
update the change implementation tasks assigned to the support group(s) with
the committed scheduling information.
Standard changes should be updated by this task to indicate that they are pre-
authorized without having to go through assessment and authorization.
Inputs:
None
 Commitment to time and resources for change implementation
Outputs:
 Scheduled Change
Policies
 Policy – Change Type
 Policy – Change Risk and Lead Time
 Policy – Change Window
 Policy – Change Schedule Conflicts/Rescheduling
 Policy – Change Escalation
 Policy – Change Schedule Constraints Notification

None

Role ID Description
Change 2.5 Change Type?

Analyst Proceed based upon the change type.
▪ If Emergency Change is required, proceed to 2.9 Assign Change Asses-
sor(s) & Authority
▪ If Standard Change is required, proceed to CHG 5.0 Coordinate Change
Deployment sub-process
▪ If it is a Normal change, proceed to 2. 6 Meets Customer Date?
Change 2.6 Meets Customer Date?
Analyst Determine if the scheduled implementation date meets the Customer expected
due date, if any was indicated in the RFC.
 If Yes, proceed to CHG 2.9 Assign Change Assessor(s) & Authority
 If No, proceed to CHG 2.7 Engage Customer Liaison
Inputs:
None
None
Outputs:
None
None
Policies
 Policy - Change Schedule Constraints Notification

None

Role ID Description
Change Ana- 2.7 Engage Customer Liaison

lyst Change Analyst engages the Customer Liaison requesting their assistance in
communicating and resolving schedule issues with the Customer and respective
Release and/or Deployment Specialist (implementer)
Inputs:
None
None
Outputs:
None
Policies
 Policy - Change Escalation
 Policy - Change Schedule Constraints Notification

None
Customer Li- 2.8 Obtain Agreement on Schedule
aison Customer Liaison will facilitate resolution of scheduling issues amongst the re-
quired stakeholders. Note that certain tasks within Assess and Evaluate sub-
process are executed again to obtain an agreeable schedule.
Proceed to CHG 2.4 Schedule Change
Inputs:
None
None
Outputs:
None
 Commitment to time and resources for change implementation
Policies
None

None

Role ID Description
Change Ana- 2.9 Assign Change Assessor(s) & Authority

lyst Assign appropriate Change Assessors and Change Authority.
Inputs:
None
None
Outputs:
None
 Updated CR
Policies
 Policy – Change Assessment
 Policy Change Authorization

None
Change 2.10 Submit CR for Assessment
Analyst Submit the CR for assessment(s)
Inputs:
None
None
Outputs:
None
None
Policies

None

Role ID Description
Change 2.11 Perform Change Assessment(s)

Assessor The change is reviewed and assessed from both a technical and business impact
perspective. The assessment results are recorded – either the change is signed-
off or any concerns/issues are raised. The results are communicated to the
Change Analyst.
Inputs:
None
 Notification to Perform Assessment
 Change Record
 CMDB Information
Outputs:
None
 Notification of Completed Assessment
 CR Updated with Assessment Results
Policies
 Policy – Change Assessment

 Control Point – (CHGCP3) Change Risk Categorization (Impact and failure
probability factors)

Role ID Description
Change Ana- 2.12 Receive and Document Assessment Results

lyst Receive all assessment results and review them for any concerns/issues. As re-
quired, work to answer concerns and resolve issues. As needed, update the
Change Plan. Highlight remaining issues that might be important for the change
authorization/rejection decision.
Inputs:
None
 Notification of Completed Assessments
Outputs:
None
 Updated Normal CR
Policies
 Policy - Change Assessment

None

Role ID Description
Change Ana- 2.13 Proceed Based on Assessments

lyst Determine next step based on the assessment results and any corresponding
Change Plan updates.
 If there are no open issues, proceed to CHG 3.0 Coordinate Change Build
and Test
 If rescheduling is required, return to 2.2 Request Change Implementation
Window
 If re-assessment is required, return to 2.11 Perform Change Assessment(s)
Inputs:
None
None
Outputs:
None
None
Policies
 Policy - Change Schedule Conflicts/Rescheduling
 Policy - Change Assessment
 Policy - Change Authorization

None

9 Task Workflow for Coordinate Change Build &

Test

Coordinate Change Build & Test
3.3 Engage Release

3.1 Coordinate 3.5 Submit for
Start Yes Mgmt & Monitor
Change Build & Test Authorization
Progress
3.2 Part of a Release?
CHG 4.0
Change Analyst
No Yes
3.4 Test Successful &
on Scheduled?
No
CHG 2.2

Role ID Description

Role ID Description
Change Ana- 3.1 Coordinate Change Build and Test

lyst Coordinate and oversee any needed activities for the change build and testing to
ensure that those are performed in a timely manner, in line with the planned
schedule.
The extent of build and test activity may vary greatly, depending on the nature of
the change.
The actual activities of change build and testing will not necessarily be performed
by the Change Analyst. They may be the responsibility of other functions or roles.
The Change Analyst is responsible to ensure that work is assigned as appropri-
ate.
Inputs:
None
 Change Record
Outputs:
None
 Normal CR (tested)
 Emergency Change (tested)
Policies
 Policy – Change Testing

None
Determine if the change is part of a Release.
 If Yes, proceed to CHG 3.3 Engage Release Management and Monitor
Progress
 If No, proceed to CHG 3.4 Test Successful & on Schedule?

Role ID Description
Change Ana- 3.3 Engage Release Management and Monitor Progress

lyst Pass the change to the Release Management process for inclusion in a release
package.
Monitor release build, test and verification to ensure that release change is pro-
gressing in a timely manner.
This is the Design & Build Release and the Test and Verify Release sub-
processes of Release Management.
After completion of the Test and Verify Release sub-process, Release Manage-
ment notifies Change Analyst of release build and test completion status. This
includes whether the release package test was successful or cannot be provided
within the needed timeframe.
Receive status notification from Release Management of completed release build
and test activity.
Inputs:
None
 Change associated with a Release
Outputs:
a) Process Interdependencies:
 Notification of release test completion status
 Change incorporated into release package(built & tested)
Policies
 Policy – Change Notification

None
3.4 Test Successful & on Schedule?
Based on the result of the individual change test, the release test completion sta-
tus and time, determine if testing was successful and there have been no impacts
to the deployment schedule due to iterative build and test cycles.
A Yes implies a “GO” decision and the change is advanced. A No determination
implies a “NO GO” decision and routes the change back to be rescheduled and
re-assessed.
 If Yes, proceed to CHG 3.5 Submit for Authorization
 If No proceed to CHG 2.2 Request Change Implementation Window

Role ID Description
Change Ana- 3.5 Submit for Authorization

lyst Advance the change and submit a request for authorization to the Change Au-
thority. In case of Emergency change, notify the Change Manager or delegate if
required.
Inputs:
None
None
Outputs:
None
 Request for Authorization to Change Authority
 Notification to Change Manager or delegate if required (if Emergency
Change)
Policies
 Policy - Change Authorization
 Policy - Change Advisory Board Meetings
 Policy - Change Notification Policy

None
Proceed to CHG 4.0 Authorize Change

10 Task Workflow for Authorize Change

Authorize Change
Start No No
Change Manager
4.1 Emergency
Change? 4.4 CAB Review
Required?
Yes Yes
4.2 Invoke 4.7 Chair Change

4.5 Produce Forward 4.6 Prepare for CAB
Emergency CAB as Advisory Board
Schedule of Changes Meeting
needed Meeting
4.9 Authorize or 4.13 Wait for all

Reject Change Chgs in Release
CHGCP4 Authorized
Yes
Change Authority
Yes No
4.11 Part of a Release? CHG 5.0

4.10 Change
Authorized?
Change Advisory
Board Member
4.8 Review and No

Advise on Changes
E-CAB Board
Member
4.3 Review and

Advise on Change
4.15 Cancel Change

No & Notify
Stakeholders
4.12 Reschedule
Change Analyst
Required?
Yes
End
4.14 Notify
Stakeholders of
Rescheduling
CHG 2.2

Role ID Description
Change 4.1 Emergency Change?

Manager Is the change type emergency?
 If Yes, proceed to CHG 4.2 Invoke Emergency CAB as Needed
 If No, proceed to CHG 4.4 CAB Review Required?
4.2 Invoke Emergency CAB as Needed
Make arrangements for the emergency CAB to meet. Notify all participants and
make all necessary preparations for the meeting to take place efficiently.
Note: If emergency CAB does not exist or is not needed as per policy, then pro-
ceed to CHG 4.9 Authorize or Reject Change.
Inputs:
None
Triggers
 Notification from Change Analyst
Outputs:
None
None
Policies

None

Role ID Description
ECAB Board 4.3 Review and Advise on Changes

Member Follow emergency CAB agenda and structure in reviewing of emergency change
and advice on authorization.
Proceed to CHG 4.9 Authorize or Reject Change
Inputs:
None
None
Outputs:
None
None
Policies

None
Change 4.4 CAB Review Required?
Manager ▪ If Yes, proceed to CHG 4.5 Produce Forward Schedule of Changes
▪ If No, proceed to CHG 4.9 Authorize or Reject Change

Role ID Description
4.5 Produce Forward Schedule of Changes

Prior to scheduled CAB meetings, produce a Forward Schedule of Change. En-
sure all planned changes that are submitted for authorization are on the FSC.
Inputs:
None
 New Scheduled Change
 Change Records
 Availability Plan / SLAs
Outputs:
None
 FSC (Forward Schedule of Changes)
Policies
 Policy – Change Schedule Conflicts/Rescheduling
 Policy – Change Advisory Board Meetings

None

Role ID Description
Change 4.6 Prepare for CAB meeting

Manager Make arrangements for the CAB to meet. Notify all participants and make all nec-
essary preparations for the meeting/call to take place efficiently.
Compile list of Failed changes since the last CAB meeting. Failed changes are
reviewed on the CAB.
Note: Depending on local needs and organization, the CAB meeting might also
be split into several meetings/calls.
Inputs:
None
 FSC (Forward Schedule of Changes)
Outputs:
None
 CAB Agenda & Information
 Notification to Invitees
 Failed change list
Policies

None

Role ID Description
4.7 Chair Change Advisory Board Meeting

Chair and facilitate CAB meeting/call adhering to the CAB guidelines.
Proceed to CHG 4.8 Review and Advise on Changes
Note: Account may host one CAB meeting or separate CAB meetings.
Inputs:
None
 Scheduled CABCAB Agenda & Information
 FSC
 Failed Change list
Outputs:
None
None
Policies

None

Role ID Description
Change Advi- 4.8 Review and Advise on Changes

sory Board The Change Advisory Board (CAB) body assists in the assessment, prioritization
Member and scheduling of some of the proposed normal changes and advises the
Change Authority whether those changes should be authorized.
The Change Advisory Board (CAB) body may review failed changes that were
closed since the last CAB meeting.
Changes that failed with unexpected negative business impact may be reviewed,
which includes review of any provided Root Cause Analysis from Problem Man-
agement, which has been initiated through Incident Management. The CAB may
recommend additional preventive actions to Problem Management.
Changes that failed without unexpected negative business impact may be re-
viewed to determine if a RCA request to Problem Management is warranted. If
yes, the CAB recommends raising a failed change RCA request to Problem Man-
agement. The Change Manager will route such request on behalf of the CAB.
Inputs:
None
Outputs:
 CAB Statement of Advice
 Optional: Failed Change RCA Requests to Problem Management
 Optional: Action Item Recommendations to Problem Management
Policies
 Policy – Change Advisory Board Meetings

None

Role ID Description
Change 4.9 Authorize or Reject Change

Authority The Change Authority performs the final decision whether a change is authorized
or rejected for implementation and ensures the Change Analyst is informed. If
rejected, it determines if it is to be cancelled or rescheduled.
Inputs:
None
 Request for Authorization to Change Authority
 Change Record
Outputs:
None
 CR (Authorized, Rejected or Cancelled)
 Notification to Change Analyst
Outputs:
None
None
Policies
 Policy – Change Authorization
 Policy – Change Separation of Duties

 Control Point – (CHGCP4) Appropriate Change Authorization
4.10 Change Authorized?
 If Yes, proceed to CHG 4.11 Part of a Release?
 If No, proceed to CHG 4.12 Reschedule Required?
 If Yes, proceed to CHG 4.13 Wait for all Changes in Release Authorized
 If No, proceed to CHG 5.0 Coordinate Change Deployment
Change 4.12 Reschedule Required?
Analyst Based on the decision notification received from the Change Authority, determine
route.
 If Yes, proceed to CHG 4.15 Cancel Change & Notify Stakeholders
 If No, proceed to CHG 4.14 Notify Stakeholders of Rescheduling

Role ID Description
Change Au- 4.13 Wait for all Changes in Release Authorized

thority The authorization decision is to be made for all changes in a release package as
a single entity. Wait until all change records of the same release have been up-
dated with the decision before moving on to deployment of the change/release
package. This avoids premature or incomplete deployment start.
Proceed to CHG 5.0 Coordinate Change Deployment
Change 4.14 Notify Stakeholders of Rescheduling
Analyst Submit a notification to stakeholders that the change has been rejected and is
being rescheduled. This includes but is not limited to implementing groups and
the Requestor from the originating process.
Inputs:
None
None
Outputs:
None
 Notification of need to reschedule
Policies

None
Proceed to CHG 2.2 Request Change Implementation Window

Role ID Description
4.15 Cancel Change & Notify Stakeholders

Submit a notification to the stakeholders that the change has been rejected and
cancelled. This includes but is not limited to implementing groups and the reques-
tor from the originating process.
Close the CR as cancelled.
Inputs:
None
None
Outputs:
None
 Notification of cancelled change
Policies
 Policy – Change Notification

None
Proceed to End of Authorize Change Sub-Process

11 Task Workflow for Coordinate Change De-

ployment

Coordinate Change Deployment

Change Analyst
5.1 Submit 5.2 Monitor 5.3 Receive Results

Start
Deployment Request Deployment Status from Deployment
CHG 6.0

Role ID Description

Role ID Description
Change 5.1 Submit Deployment Request

Analyst The work of deploying a change is part of the Deployment Management process.
Submit the Change Record to Deployment management for implementation.
Note: there is no requirement for a separate deployment request record.
Inputs:
None
 Start date and time of change
 Normal/Standard CR
 Emergency change
Outputs:
 Submitted deployment request
Policies
None

None
Change 5.2 Monitor Deployment Status
Analyst The Change Analyst monitors progress of Deployment Management checking
that change is started on time, progressing as planned and any Remediation Plan
is applied for unsuccessful implementations.
Inputs:
None
None
Outputs:
None
Policies
None

None

Role ID Description
5.3 Receive Results from Deployment

Receive notification from Deployment Management process of final completion
status of the change and validation result.
Inputs:
 Notification from Deployment Management
 Updated Normal/Standard CR with completion status and validation result
 Completion status and validation result for Emergency Change
Outputs:
None
None
Policies
 Policy - Change Validation and Completion

None
Proceed to CHG 6.0 Originating Process

12 Task Workflow for Review and Close Change

Review and Close Change

Change Analyst
6.1 Post 6.2 Complete 6.3 Close Change

Start Implementation Change Record
Review Documentation CHGCP5
End

Role ID Description

Role ID Description
Change 6.1 Post Implementation Review

Analyst Conduct the Post-Implementation-Review (PIR):
Verify that Deployment Management has clearly documented the result of the
executed Validation Plan in the change record. For successful changes this only
requires entering the correct successful closure code and actual completion time.
Contact involved Deployment Specialist to clarify as needed.
Contact the relevant stakeholders, including as needed the Requestor of the
change and customers/end-users. Collect their input about the outcome of the
implemented or attempted change, i.e. success versus non-success.
If the change was requested to solve an Incident or Problem, the respective role
of Incident or Problem Management acts as Requestor of the change. This role
determines which and how related Incident or Problem records should be updat-
ed to reflect the effect of change and reports this to the respective process.
If the change failed causing an incident, ensure that the incident has been rec-
orded and that Incident Management will invoke Problem Management for root-
cause-analysis as required.
Collect any ideas for improvement of deploying like changes and communicate
those to the relevant stakeholders for consideration.
Determine if any follow-up Requests for Change are required and ensure they are
submitted.
Inputs:
 Notification from Deployment Management
 Updated Normal/Standard CR with completion status and validation result
 Completion status and validation result for Emergency Change
Outputs:
 Change outcome information
Policies
 Policy – Change Review and Closure

None

Role ID Description
Change 6.2 Complete Change Documentation

Analyst Ensure that the change record contains the appropriate and correct change out-
come documentation. For successful changes this only requires entering the cor-
rect successful closure code and actual completion time. Based on the infor-
mation from the PIR, complement or adjust the documentation as required. Up-
date the change record with the correct closure code reflecting success/non-
success.
Identify if the change needs to be considered unauthorized according to process
policy, and if so, document this in the change record.
If the change was incomplete, ensure it is clearly documented what was not de-
ployed.
Inputs:
None
 Change outcome information
Outputs:
None
 CR with outcome documentation / closure code
Policies
 Policy – Change Authorization
 Policy – Change Review and Closure

None

Role ID Description
Change 6.3 Close Change Record

Analyst Close the change record. Notify change closure to the originating process.
Proceed to: End sub-process / process
Inputs:
None
 Change Record with closure code
Outputs:
None
 Change Record closed
Policies
None

 Control Points – (CHGCP5) Timely Change Closure
Proceed to End of Review and Close Change Sub-Process

13 Task Workflow for Monitor, Track & Report

Changes

Monitor, Track & Report Changes
No
7.3 Determine 7.6 Notify

7.2 Review CR Status 7.5 Record and
Start No Action for CR of Yes Stakeholders as
& ID CRs of Interest Perform Action
Interest Needed
7.1 Is this a request for 7.4 Requires Action?

a report?
7.11 Generate &

Yes Yes Communicate
Report
Change Manager
7.10 Define and

7.7 Analyze Report
Build Standard End
Request
Report
7.8 Standard Report?
Yes
7.12 Communicate
No No
and Close Request
Service Level
7.9 Candidate for Management
Standard Report?

Role ID Description
Change 7.1 Is this a Request for a Report?

 If Yes, proceed to CHG 7.7 Analyze Report Request
Manager
 If No, proceed to CHG 7.2 Review CR Status and ID Change Records of
interest

Role ID Description
7.2 Review CR Status & ID CRs of Interest

This is a continuous process and repeats after each iteration.
Scan Status of Change Records
The status of changes is periodically monitored as they progress through the pro-
cess steps.
Identify Change Records of Interest
From the collection of records, select those that require attention and may require
immediate action to promote progression of the change. Selection should include
records that have an extended period of inactivity, have progressed too slowly, or
are in jeopardy of missing target schedules.
Inputs:
None
 Calendar
 Change Records
Outputs:
None
 Change Records of interest
Policies

None

Role ID Description
Change 7.3 Determine Action for CR of Interest

Manager From those records of interest selected, collect detailed information to gain a
deeper understanding of the change. Verify current status by contacting the re-
sources actively working on the change. The Integrated Service Manager may be
contacted if there are multiple service providers.
Collected information should include any issues or conditions that are hindering
progress. With this information, a decision should be made whether or not to initi-
ate an action.
Inputs:
None
 Change records of interest
Outputs:
None
 Change Issues Information
Policies
 Policy – Change Priority

None
7.4 Requires Action?
▪ If Yes, proceed to CHG 7.5 Record and Perform Action
▪ If No, proceed to CHG 7.2 Review CR Status & ID CRs of Interest

Role ID Description
Change 7.5 Record and Perform Action

Manager Initiate action to address the undesirable conditions that exist or are likely to exist
if no action is taken. Possible actions include the following: escalation, transfer to
another resource, and increasing the priority.
Timely and complete communication is key to this activity. When the action is
complete, update the record with the latest status.
Inputs:
None
 Change Issues Information
Outputs:
None
 Updated CR (Action Item Detail)
Policies

None

Role ID Description
7.6 Notify Stakeholders As Needed

If the actions warrant an active notification to stakeholders, issue the notification
using appropriate vehicles.
Proceed to End (this iteration of Monitor, Track and Report Changes)
Inputs:
None
 Updated CR (Action Item Detail)
Outputs:
None
 Notification of Action
Policies
None

None
7.7 Analyze Report Request
Review the request to examine the report requirements.
7.8 Standard Report?
Determine if this report is standard and can be generated.
 If Yes, proceed to CHG 7.11 Generate & Communicate Report
 If No, proceed to CHG 7.9 Candidate for Standard Report?
Change 7.9 Candidate for Standard Report?
Manager Determine if the requested report should become a standard report based on cur-
rent standard report list and the report requirements.
 If Yes, proceed to CHG 7.10 Define & Build Standard Report
 If No, proceed to CHG 7.12 Communicate to Requestor and Close Re-
quest

Role ID Description
7.10 Define & Build Standard Report

Based on the input report request, generate the new standard report.
Inputs:
None
 Report Request
 New Report Design
Outputs:
None
 Standard Report
Policies
None

None
7.11 Generate & Communicate Report
Based on the input report request, generate the report from the existing standard
report design and the wanted data sources.
For established periodic reports, a report request may not be required as trigger
each time. Generate the report per established reporting calendar.
Inputs:
None
 Calendar
 Report Request
Outputs:
None
 Report Communication
Policies
None

None
Proceed to End

Role ID Description
Change 7.12 Communicate to Requestor and Close Request

Manager Notify the requested report is not standard and/or cannot be built.
Inputs:
None
 Nonstandard report request
Output:
a) Process Dependencies
 Service Level Management
 Communication to requestor
Policies
None

None
Proceed to Service Level Management Process

Proceed to End of Monitor, Track & Report Changes Sub-Process

14 Task Workflow for Maintain Standard Change

List

Maintain Standard Change List

Change Manager
8.1 Receive Standard 8.3 Communicate

8.2 Update Standard
Start Change Update Updated Standard End
Change List
Request Change List

Role ID Description

Role ID Description
Change 8.1 Receive Standard Change Update Request

Manager Receive a Standard Change Update Request. Verify that the request for a new
standard change is not already on the Standard Changes List. Verify that the
change meets the requirements for Standard Changes.
Review failed standard change to see if it should be removed from the Standard
change list
Inputs:
None
 Standard Change Update Request
 Failed Standard Change
 Standard Changes List
 Standard Change Record
Outputs:
None
 Reviewed new or updated standard change request
Policies
 Policy – Standard Change

None

Role ID Description
Change 8.2 Update Standard Change List

Manager Assign a unique ID to the new Standard Change and add it to the Standard
Changes List, including all required details about the Standard Change.
For removals update the Standard Change List to indicate the removal of the
Standard Change.
Inputs:
None
 Reviewed new or updated standard change request
Outputs:
None
 Updated Standard Changes List
Policies
 Policy – Standard Change
 Policy – Change Separation of Duties

None
8.3 Communicate Updated Standard Change List
Communicate the Updated Standard Change List to the requestor, as well as to
other stakeholders as needed.
Proceed to End of Maintain Standard Change List Sub-Process
END

15 Service Provider Integration Data flow

 Service Provider Integration into GTS processes is described by the interfaces between the
GTS processes and the Service Providers Processes. These interfaces are defined as the
input and the output that are exchanged between the GTS process and the Service Provider
process for each activity or task of the GTS process that can interface with the Service Pro-
vider process. The Service Provider Integration Data Flow diagram and associated narrative
are an articulation of the highest level of integration between processes. The variation and
details of the integration of a service provider into GTS processes is de-scribed in the integra-
tion manual applicable to the Service Provider.
 This section applies only to accounts that have enabled the end to end service integration for
the Change Management process.
15.1 Integration Roles and Responsibilities

The roles involved in the integration of service providers into the process, and the responsibilities
associated with those roles, are listed in the following sections:
 Responsibilities include, but are not limited to, those listed for each role
 Roles are meant as logical groupings of tasks. They are not intended to match specific
organizational structures or formal job roles
 Several roles may be performed by the same individual
 A role may be split up among several individuals
15.1.1 Service Provider Process Focal

The Service Provider Process Focal can act as a stakeholder by requesting assistance on any given
change or submitting a change to GTS. This role may also participate in the implementation of a change,
acting as a support group and point of escalation for activities that require higher level of expertise.
Responsibilities include:
 Engaging appropriate analysts/specialists as needed to complete assigned activities
 Accepting/rejecting Requests for Change from the queue of RFCs of their own support group
and requesting complementary information from the Requestor, as required
 Notifying Requestor in case of a rejected Request for Change
 Documenting a Change Record with all required information based on the accepted Request
for Change
 Notifying the Change Manager and the Customer Liaison, and ISM where required, in case of
detected scheduling conflicts
 Determining the need for technical and business change assessments and providing busi-
ness and/or technical information as required
15.2 Integration Data Flow Diagram

 The Integration Workflow Diagram is a visual articulation of the interfaces between the GTS
global process activities and the service provider process activities. It includes:
 A reference line of the process activities subject to integration
 Swim lanes representing the process roles receiving or sending process data
from or to the Service provider focal
 An I/O swim lane for data input and data output associated with each pro-
cess activity in relation with the service provider process.
Integration Data Flow

Process Activities
Management
Change
7 Monitor, track & report

1.0 Review RFC 2.0 document & assess change 4.0 Authorize Change
change
Change Analyst
Integrated Service
Manage / Change
Manager
Chang Receiv Chang Notify Cancel

Accept e and Chang Collect
e Schedu e Stakeh Chang
ance / Docum e ed
implem led authori olders e and
RFC reject
I/O
ent record informa

entatio Chang zation of Notify
decisio Assess of tion on
n e decisio Resche Stakeh
n ment interest issue
window n duling olders
Results
Input to 1.0 Output from 1.0 Input to 2.0 Output to 2.0 Input to 2.0 Input from 4.0 Input to 7.0 Output from 7.0
SP Change Focal
15.3 Integration Data Flow Narrative

 The Integration Data Flow Narrative, which accompanies the Integration Data Flow Diagram,
is a textual articulation of the exchange of input and output between the service provider focal
and the process roles for activities requiring such exchanges.
Process Activity Input or Output From Role To Role Description

or Task
1.0 Review RFC - Input SP Process Focal Change Analyst / Input
Integrated Service
1.1 Receive ▪ Service Re-

Change Request Manager / quest, Incident

Change Manager Record, Problem
Record, etc
Criteria
A change is re-
quested by the
Service Provider in
the GTS managed
environment
Output Integrated Service SP Process Focal Output
Manager / ▪ Change Record
Change Manager ▪ Criteria A
change has been
requested by the
Service Provider
Criteria is met for
opening a change
1.0 Review RFC - Input SP Process focal Integrated Service Input
Manager /
1.5 Reject RFC ▪ Change Reject
Change Manager
status
Criteria
A Request for
change from the SP
is not accepted
Output Change Analyst / SP Process focal Output
Integrated Service
▪ Change Reject
Manager /
status
Change Manager
Criteria
A Request for
change from GTS
is not accepted
2.0 Document and Input SP Process focal Integrated Service Input
assess change - Manager /
▪ Change Win-
2.2 Request Change Manager
dow Information
Change
Criteria
Implementation
Window ▪ A GTS change
is impacting the
Service Provider
A Service Provider
change is impacting
GTS
Output Integrated Service SP Process focal Output
Manager / ▪ Notification of
Change Manager change reschedule
▪ Forward
Schedule of
Change
Criteria
▪ A GTS change

is impacting the
Service Provider
A Service Provider
change is impacting
GTS
2.0 Document and Output Change Analyst / SP Process focal Output
assess change - Integrated Service ▪ Scheduled
2.4 Schedule Manager / Change
Change Change Manager Criteria
▪ Once change
window has been
agreed to
Input SP Process focal Integrated Service Input
Manager /
▪ Scheduled
Change Manager
Change
Criteria
Once change win-
dow has been
agreed to
2.0 Document and Output Change Analyst / SP Process focal Output
assess change – Integrated Service
▪ Completed as-
2.12 Receive and Manager
sessments
Document
Criteria
Assessment
Results Deliver assessment
results (tech-
nical/business)
Input SP Process focal Integrated Service Input
Manager /
▪ Completed as-
Change Analyst
sessments
Criteria
Receive assess-
ment results (tech-
nical/business)
4.0 Authorize Input SP Process focal Change Analyst Input
Change - 4.9
▪ Change author-
authorize or
ization / rejection
Reject Change
Criteria
▪ A Service Pro-
vider is impacted by
the GTS change
▪ A Service Pro-
vider is an actor of
the GTS change
A service provider
has submitted an
accepted change
4.0 Authorize Output Change Analyst SP Process focal Output
Change - 4.14
▪ Email, chat
Notify and/or any other

Stakeholders of means of commu-

Rescheduling nication informing
of rescheduled
change
Criteria
▪ A change rec-
ord has been re-
viewed during the
CAB Meeting and
decided to be re-
scheduled
4.0 Authorize Output Change Analyst SP Process focal Output
Change -4.15
▪ Email, chat
Cancel Change
and/or any other
and Notify means of commu-
Stakeholders nication informing
cancelled change
Criteria
▪ Change record
is no longer re-
quired and is can-
celled
7.0 Monitor, Track Input SP Process focal Change Manager Input
& Report Change
▪ List of changes
- 7.3 Determine
requiring action
Action for CR of Criteria
Interest ▪ A change is not
progressing as ex-
cepted and an ac-
tion from the SP is
necessary
Output Change Manager SP Process focal Output
▪ Actions con-
cerning change(s)
Criteria
▪ A change is
not progressing as
excepted and an
action from the SP
is necessary
15.4 Integration Measurements

The integration Measurements section list:
 The metrics from the process or service flow document that are to be provided by the Service
Provider.
Metric ID Metric Name Description
SP-CH02 Closed Count of closed changes

Changes

SP-CH05 % Emergency Percentage of emergency changes

changes
SP-CH07 % Failed Percentage of failed changes
Changes

16 Controls and Measurements
16.1 Control Points

Control Points are points identified by the Process Owner within an application, system, or business pro-
cess to manage risks in support of delivering business value-add and meeting compliance objectives.
The following table outlines the Control Points identified for this process and related measurements man-
dated to evidence control over the process.
CP CP Name Risk & Description Type Category Associated Man-
ID datory Measure-
ments
CHG Change Rec- Risk: Need to ensure an au- Compliance Preventive CH02 - # Closed
CP1 ord Logging thorized change record is Changes
available before a change is
executed, Customer Sat,
Contractual requirement.
Description: Ensuring
Changes are accurately
Recorded as defined by the
Change Record Logging Pol-
icy
Role: Change Analyst
Evidence: Change record
CHG Change Priori- Risk: Change categorization Compliance Preventive CH02 - # Closed
CP2 tization (Im- required to meet time frame, Changes
pact and Ur- Customer Sat, wrong
gency factors) timeframes, System outage,
Financial Penalty.
Description: Ensure Change
is installed per prioritized def-
inition.
Evidence: Change Record
CHG Change Risk Risk: Change categorization Compliance Preventive CH02 - # Closed
CP3 Categorization required to meet time frame, Changes
(impact and Customer Sat, wrong
failure proba- timeframes, System outage,
bility factors) Financial Penalty.
risk based on impact and
failure probability is docu-
mented.

CP CP Name Risk & Description Type Category Associated Man-

ID datory Measure-
ments
CHG Appropriate Risk: Customer Sat, wrong Compliance Preventive CH04 - % Unau-
CP4 Change Au- timeframes, System outage, thorized Changes
thorization Financial Penalty.
CH01 - % Failed
Description: Ensure Change Changes
has the correct authorization
prior to implementation.
CHG Timely Risk: Customer Sat, possible Compliance Detective CP02 - # Closed
CP5 Change Clo- rework due to not knowing Changes
sure the issue is closed. Would
not stop the business if not
closed timely, other control.
record is closed with proper
closure information within
required timeframe.
16.2 Measurements
Measurement is a collection of data showing a trend (Do) toward an objective regularly updated (Plan)
and associated with a feedback loop (Check) for an action (Act).
 Input metrics (examples: preventive, anticipate impact on final results)
 Operational metrics (examples: preventive, operations monitoring, anticipate impacts on final results)
 Output metrics (examples: final results, after the facts, usually some are selected as KPIs)
Note: Any measurements not specifically listed in 16.1 are considered to be optional, however highly rec-
ommended to track. These are designed to support efficient management of the process.

16.2.1 Output Metrics

Output metrics are the measuring of a process performance characteristic towards an objective.
Metric Metric Name Description Frequency SLA

ID
Number of failed chang- Monthly None
es*
Percent-
/ Total number of chang-
age of failed
es by category or /
chang-
workgroup.
es per chang Failed changes are de-
e failure cate fined within the Change
gory/workgro Review and Closure Poli-
CH07 up cy.
Monthly None
Number of rescheduled
changes* / Total number
of closed changes
Percent- *Changes that were fully

age of resch approved but got re-
eduled chan scheduled prior to the
CH08 ges scheduled start
16.2.2 KPIs
A metric that is used to help manage a process, IT service or activity.
Metric Metric Name Description Frequency SLA

ID

CH01 Number of failed changes Monthly None

KPI Percentage *
of failed / Total number of closed
changes changes.
Failed changes are de-
fined within the Change
Review and Closure Poli-
cy.
CH02 Monthly None
KPI Num-
ber of closed
changes Count of closed changes
CH03 Percent- Monthly None

KPI age of except Number of exception
ion (urgent, changes* / Total number
expedited) of closed changes
changes
* Any type of change that
doesn’t meet lead time
based on policy.*
CH04 Number of Unauthorized Monthly None

KPI Percent- changes*
age of unaut / Total number of closed
horized chan changes
ges * Change made to the IT
infrastructure that violates
defined and agreed
Change policies.
Change was implemented
without proper approvals.*
CH05 Monthly None
KPI Percent- Number of Emergency
age of emerg changes* / Total number
en- of closed changes
cy changes
* An emergency change is
a change that needs to be
implemented immediately
in order to resolve a pro-
duction incident of priority
1, where outage of a ser-
vice component is immi-
nent, or has occurred, the
change therefore cannot
comply with the lead
times and gets special
change process handling.
CH06 Monthly None

KPI Percent- Number of changes re-
age of chang sulting in incidents / Total
es resulting i number of closed chang-
n incidents es

17 Process Interdependencies
This section contains the related / interdependent Processes for this process.
Processes are interdependent when a deliverable from one process is required to enable execution or to
achieve process objectives in the other process.
The table represents an aggregate by activity and task of all the interdependent process inputs (including
triggers) and outputs.
Activity / Task ID Interdependent Input Output
/ Task
Process
1.3 Request Fulfillment Submitted Request Change record

for Change (RFC)
1.3 Incident Management Submitted Request Change record
for Change (RFC)
1.3 Problem Management Submitted Request Change record
for Change (RFC)
1.3 Availability Management Submitted Request Change record
for Change (RFC)
1.3 Configuration Management Submitted Request Change record
for Change (RFC)
1.3 Request for Service (RFS) Submitted Request Change record
for Change (RFC)
1.4 Release Management Request Change record (Standard,
Normal, Emergency)
1.7 Incident Management Change Record Relation to Incident (If ap-
plicable)
1.7 Problem Management Change Record Relation to Problem (If ap-
plicable)
1.7 Request Fulfillment Change Record Relation to SR (If applica-
ble)
2.2 Deployment Management Notification of need to Request to Deployment
reschedule Specialist
Forward Schedule of
Change (FSC)
2.2 Release Management Notification of need to Request to Release Man-
reschedule ager
Forward Schedule of
Change (FSC)
2.4 Deployment Management Commitment to time Scheduled Change
and resources for
change implementa-
tion
2.4 Release Management Commitment to time Scheduled Change
and resources for


/ Task
Process
change implementa-
tion
2.7 Deployment Management Scheduled Change Escalation/Notification
2.7 Release Management Scheduled Change Escalation/Notification
3.3 Release Management Change associated Notification release test of
with a Release completion status
Change incorporated into
release package(built &
tested)
4.8 Incident Management CAB CAB Statement of Advice
Optional: Failed Change
RCA Requests to Problem
Management
Optional: Action Item Rec-
ommendations to Problem
Management
4.8 Problem Management CAB CAB Statement of Advice
Optional: Failed Change
RCA Requests to Problem
Management
Optional: Action Item Rec-
ommendations to Problem
Management
5.1 Deployment Management Start date and time of Submitted deployment re-
change quest
Normal/Standard CR
Emergency change
5.2 Deployment Management Change Request Change Request Status
5.3 Deployment Management Notification from De- Updated Change Record
ployment Manage-
ment
Updated Nor-
mal/Standard CR
with completion sta-
tus and validation
result
Completion status
and validation result
for Emergency
Change
6.1 Incident Management Notification from De- Change outcome infor-
ployment Manage- mation


/ Task
Process
ment
Updated Nor-
mal/Standard CR
tus and validation
result
Completion status
for Emergency
Change
6.1 Deployment Management Notification from De- Change outcome infor-
ment
Updated Nor-
mal/Standard CR
tus and validation
result
Completion status
for Emergency
Change
6.1 Problem Management Notification from De- Change outcome infor-
ment
Updated Nor-
mal/Standard CR
tus and validation
result
Completion status
for Emergency
Change
7.12 Service Level Management Nonstandard report Communication to reques-
request tor

18 Standards & Policies
18.1 Applicable Standards

This section identifies any standards that apply to the execution of this process.
 ITIL (ITIL® is a Registered Trade Mark of Axelos)
18.2 Policies
This section contains a summary of the policies related to this process.
Policy Name Description
Request For Describes the minimum requirements for a requestor to submit a Request for Change
Change Details (RFC) to Change Management, so that expectations for input information are consist-
Policy ently set.
Change Accounta- For each Change Record, accountability must be established, so as to effectively
bility Policy manage a Change through its lifecycle irrespective of geographical and/or organiza-
tional boundaries.
Change Notification The objective of notification is to ensure the responsible role within the process is noti-
Policy fied about further action required by them, or to communicate relevant information.
Change Record Describes when creation of a Change Record is required and what minimum infor-
Logging Policy mation is required.
Change Type Poli- Defines the Change Types.
cy
Standard Change This policy sets rules how to identify, manage, and make use of standard changes.
Policy The purpose of the standard change is to improve efficiency and effectiveness of day-
to-day operations and reduce the burden on the change analysts, authority and CAB,
allowing them to focus on more complex and higher risk changes. Effective use of
standard changes will reduce bureaucracy and improve efficiency.
Change Priority Guidance for change prioritization and its relevance for treatment and scheduling of
Policy changes.
Change Risk and Determine the risk for change severity and the lead time required to safely execute the
Lead Time Policy change.
Change Window Defines governance of Change Windows and defines related terminology and key
Policy time-frames.
Change Schedule The purpose of this policy is to enable IBM to use received information in order to
Constraints Notifi- identify constraints on the schedule for IBM managed changes that may arise from
cation Policy customer specific change schedule constraints. IBM makes such change schedule
constraint information available to its relevant personnel.
Change Plan Policy The change plan contains details about implementation, validation and remediation of
the change. The minimum level of detail of this plan depends on the change risk and
is described in this document
Change Schedule This policy is used to identify and resolve change scheduling conflicts, prevent delays
Con- in the change management process and enhance change management results and

Policy Name Description

flicts/Rescheduling performance in the Production environment.
Policy
Change Assess- Provides details and guidance related to technical and business assessments of nor-
ment Policy mal changes
Change Testing Testing changes is critical to ensure successful implementation.
Policy
Change Authoriza- Provides guidance for authorizing changes, defines an unauthorized change, de-
tion Policy scribes change authorization model, describes customer representation related to au-
thorization, and defines and describes change endorsement.
Change Advisory Change Advisory Board meeting guidelines.
Board (CAB) Meet-
ings Policy
Change Validation Defines responsibility and documentation of the change deployment validation activity
and Completion and the target time for completion status notification
Policy
Change Review Defines the scope of Post-Implementation-Review activity and the target time for
and Closure Policy change review and closure.
Change Escalation The objective of escalation is to provide additional attention and visibility to issues and
Policy to invoke adequate levels of management to resolve them.
Change Separation The purpose of this policy is to set forth requirements for establishing and maintaining
of Duties Policy adequate separation of duties (SOD) for managing a change.

19 Artifacts and Deliverables

This chapter identifies the artifacts and deliverables created, used by, and produced by this process.
Name Use Type Roles Description
Unique Mandatory Output from: Artifact Responsible Every request for change must be
Change documented with a unique change
Review Request For Change
Record record number. Information in-
Document and Assess cluded within the change record
Change must meet the criteria listed on the
Change Record Logging Policy.
Coordinate Change Build &
Test
Authorize Change
Review and Close Change
Forward Mandatory Input to: Deliv- Modified By A document that lists all upcoming
Schedule of erable changes and their planned imple-
2.2 Request Change Imple-
Change mentation dates, as well as the
mentation Window
estimated implementation dates of
4.7 Chair Change Advisory longer-term changes.
Board Meeting
Mandatory Output from:

4.5 Produce Forward Sched-
ule of Changes

20 Glossary
This section is a glossary that defines any uncommon terms used in this document.
Term Definition
Activity An activity is a specific collection of tasks organized around a commonly understood

result, typically executed in a prescribed sequence
Actual Change The time frame between the actual start of the first change implementation task and the
Implementation actual end of the last change implementation task of an executed or attempted change.
Window
Artifacts A formal work product that:
1) is produced, modified, or used by a task,
2) defines an area of responsibility,
3) is subject to version control.
Authorized The time frame between the scheduled start and scheduled end time of an authorized
Change Window change.
Authorized For- A document that lists all upcoming authorized changes with their authorized change im-
ward Schedule of plementation windows.
Change
BAB The BAB is a GTS Executive sponsored global board that owns the design, communica-
tion, and implementation of the GTS Business Architecture. To ensure consistency with
contractual performances and Client value, the main architecture components under the
authority of the board include: 1) GTS process map, 2) Service structure and service
catalog, and 3) Process Based Service Model (PBSM).
Back-out An activity that restores a service or other configuration item to a previous baseline.
Back-out is used as a form of remediation when a change or release is not successful.
(ITIL® V3 Glossary)
(ITIL® is a Registered Trade Mark of Axelos)
Back-out Plan See Remediation Plan.
BPMN Acronym: Business Process Model and Notation, is a graphical representation for speci-
fying business processes in a business process model.
Build The activity of assembling a number of configuration items to create part of an IT ser-
vice. The term is also used to refer to a release that is authorized for distribution – for
example, server build or laptop build. (ITIL® 2011 Glossary)
Change A change is defined as the addition, modification or removal of any Configuration Item
(CI).
Change Advisory A group of people that support the prioritization, assessment, scheduling and authoriza-
Board (CAB) tion of changes of some change risk level.
Change Class The means to describe what the logical kind of operation is that a change is performing
on a Configuration Item. One of the following: addition, upgrade, refresh, move, remov-
al, other
Change Delivery The time frame between the earliest and latest time the customer requests the change
Window to be implemented and delivered. The end of this time frame represents the due date
from customer perspective.

Term Definition
Change Freeze A period of time for which no changes are to be scheduled in order to promote a stable
Period IT environment.
Change Imple- A task that performs actual change deployment, validation, remediation or back-out.
mentation Task
Change Model A repeatable way of dealing with a particular kind of change. A change model defines
the specific steps that will be followed for a change of this kind. The change model in-
cludes all relevant Change Plan details.
Change Plan The set of Implementation Plan, Validation Plan and Remediation Plan for a change.
Change Record 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 reference
the Configuration Items that are affected by the Change. Change Records may be
stored in the Configuration Management System or elsewhere in the Service Knowledge
Management System. (ITIL® V3 Glossary)
Change Request A formal proposal for a Change to be made. An RFC may include details of the pro-
posed Change and may be recorded on paper or electronically. The term RFC is often
misused to mean a Change Record, or the Change itself.
Note: "Change Request" and "Request for Change" are synonymous.
(ITIL® V3 Glossary)
Change Risk A value that indicates the magnitude of risk assessed for a proposed change. Changes
are often categorized by their Change Risk for reporting purposes.
Note: “Change Risk” and “Change Risk Level” are synonymous.
Change Sched- A period of time reserved by another party during which the IT service provider is not
ule Constraint permitted to schedule changes. E.g. a Change Freeze Period or any activity already
planned by the customer that will make changes by the IT service provider impossible.
Change Type There are three types of changes: Normal, Emergency Standard. Refer to the Change
Type policy.
Change Window A regular, agreed time when changes or releases may be implemented with minimal
impact on services. Change windows are usually documented in service level agree-
ments.
Note: “Change Window” and “Maintenance Window” are synonymous.
Configuration A component that needs to be managed in order to deliver an IT Service. Information
Item (CI) about each CI is recorded in a configuration record within the Configuration Manage-
ment System and is maintained throughout its lifecycle by Configuration Management.
CIs are defined by Configuration Management and under the control of Change Man-
agement.
Control Point Control Points are points identified by the Process Owner within an application, system,
or business process to manage risks in support of delivering business value-add and
meeting compliance objectives.
Deliverable An output from a process that has a value, material or otherwise, to a customer or other
stakeholder.

Term Definition
Emergency A subgroup of the change advisory board that makes decisions about emergency
Change Advisory changes. Membership may be decided at the time a meeting is called, and depends on
Board (ECAB) the nature of the emergency change.
Failure Loss of ability to operate to specification, or to deliver the required output. The term fail-
ure may be used when referring to IT services, processes, activities, configuration items
and so forth. A failure often causes an Incident. (ITIL® V3 Glossary)
Forward Sched- A document that lists all upcoming changes and their planned implementation dates, as
ule of Change well as the estimated implementation dates of longer-term changes.
Impact A measure of the effect of an Incident, Problem, or Change on business processes. Im-
pact is often based on how service levels are affected. Impact and urgency are used to
assign priority. (ITIL® V3 Glossary)
Impact Assess- Various analyses made by stakeholders concerning the impact of a proposed Change
ment Request. Typically, an impact assessment may include the views of Availability Man-
agement, Capacity Management, Security Management and other teams.
Incident An unplanned interruption to an IT service or a reduction in the quality of an IT service.
Failure of a Configuration Item that has not yet impacted service is also an Incident, for
example, failure of one disk from a mirror set. (ITIL® V3 Glossary)
Incident Record A record containing the details of an Incident. Each Incident record documents the
Lifecycle of a single Incident. (ITIL® V3 Glossary)
Input Metric Input metrics are measurements prior to execution of the first process activity.
Interdependent Processes are interdependent when a deliverable from one process is required to ena-
Processes ble execution or to achieve process objectives in the other process.
KPI Acronym: Key Performance Indicator, 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. (ITIL® V3 Glossary)
Maintenance See Change Window definition.
Window
Note: “Change Window” and “Maintenance Window” are synonymous.
Measurements Measurement is a collection of data showing a trend (Do) toward an objective regularly
updated (Plan) and associated with a feedback loop (Check) for an action (Act).
Normal Change A change that follows the normal change process and complies with the lead times.
Operational Met- Operational metrics (example: Operations Monitoring) measure process behavior during
ric process execution.
Output Metric Output metrics are the measuring of a process performance characteristic towards an
objective.

Term Definition
Policy Formally documented management expectations and intentions. Policies are used to
direct decisions, and to ensure consistent and appropriate development and implemen-
tation of processes, standards, roles, activities, IT infrastructure etc. (ITIL® V3 Glossary)
A statement of business choice that explains how a process-level decision is made.
Post- A review that takes place after a change or a project has been implemented. It deter-
Implementation- mines if the change or project was successful, and identifies opportunities for improve-
Review (PIR) ment. (ITIL® V3 Glossary)
Pre-production An IT environment that is not in productive business use by the customer but that has a
Environment configuration equivalent to the productive environment for a given reason. Possible rea-
sons for use may be to have an environment for testing releases to production, replicat-
ing incidents or testing operational/infrastructure/security systems.
Priority 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. (ITIL® V3 Glossary)
Problem A cause of one or more Incidents. The cause is not usually known at the time a Problem
record is created and the Problem Management process is responsible for further inves-
tigation. (ITIL® V3 Glossary)
Problem Record A Record containing the details of a Problem. Each Problem Record documents the
Lifecycle of a single Problem. (ITIL® V3 Glossary)
Projected Service A document that identifies the effect of planned changes, maintenance activities and
Outage (PSO) test plans on agreed service levels. The PSO contains details of changes to agreed
SLAs and service availability because of the current Forward Schedule of Change, in
addition to planned downtime from other causes such as planned maintenance and data
backup. The PSO may be produced jointly with other processes, such as Service Level
Management, Availability Management and IT Service Continuity Management. (ITIL®
V3 Glossary)
Remediation Actions taken to recover after a failed change or release. Remediation may include
back-out, invocation of service continuity plans, or other actions designed to enable the
business process to continue. (ITIL® V3 Glossary)
Remediation Plan A plan for performing remediation.
Request for A formal proposal for a Change to be made. An RFC includes details of the proposed
Change (RFC) Change and may be recorded on paper or electronically. The term RFC is often misused
to mean a Change Record, or the Change itself.
Note: "Change Request" and "Request for Change" are synonymous. (ITIL® V3 Glossa-
ry)

Term Definition
Requestor In the context of change Management, “Requestor” refers to the individual who has
submitted a Request for Change (RFC) to Change Management. This is not the end-
user. Those would need to contact the Service Desk to place requests.
Risk A possible event that could cause harm or loss, or affect the ability to achieve objec-
tives. 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. (ITIL® V3 Glossary)
Risk Assessment Analyzing the value of assets to the business, identifying threats to those assets and
evaluating how vulnerable each asset is to those threats. Risk Assessment can be
quantitative (based on numerical data) or qualitative. (ITIL® V3 Glossary)
Scheduled The time frame between the scheduled start of the first change implementation task and
Change Imple- the scheduled end of the last change implementation task of a scheduled change.
mentation Win-
dow
SLA Acronym: Service Level Agreement, 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. (ITIL® V3 Glossary)
Stakeholder A stakeholder is anyone who has a vested interest in the results of a task. These stake-
holders represent organizational and functional entities other than those already identi-
fied.
Responsibilities
Participation in information-gathering or requirements-gathering
Analysis results
Troubleshooting results
Plans that may impact the work done by the stakeholder
Standard Chang- The managed list of Change Requests that are considered to be of Standard change
es List type.
Task A unit of work a role may be asked to perform.
A task is the smallest unit of work within an activity flow. It is role-assignable - that is, it
can be performed by one individual acting in one defined role
Urgency A measure of how long 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
does not affect the business until the end of the financial year. Impact and urgency are
used to assign priority. (ITIL® V3 Glossary)
Urgent Change Urgent changes are a condition of normal changes. While not meeting the criteria of an
(expedited) Emergency Change, an urgent change cannot comply with the lead time due to a vital
business need for change. An urgent normal change will still go through the entire pro-
cess, although the speed at which it is planned, scheduled, assessed, built, tested and
authorized is much faster.

Term Definition
Validation Plan A Validation Plan contains the instructions to validate the outcome of a change to de-
termine success/non-success against predefined success criteria.
Note: Validation Plan is sometimes also called “Post-Implementation Test Plan”.
End of Document

IBM Global Change Management Process 15-OCT-2018 v3.2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM Global Change Management Process 15-OCT-2018 v3.2

Uploaded by

Copyright:

Available Formats

IBM Global Technology Services

Document Owner: Sebastian Blanco Manley/Costa Rica/IBM

Author: Sebastian Blanco Manley/Costa Rica/IBM

Document Revision Number: 3.2

Revision Date: 10-OCT-2018

Effective Date: 15-OCT-2018

© IBM Corporation, 2018 Page 2 of 89

12.1 Task Workflow Diagram ......................................................................................................... 54

© IBM Corporation, 2018 Page 3 of 89

1.1 Summary of Changes

2.02 2016-Jun-13 Soumitro Chatterjee Updated measurements section with definitions

© IBM Corporation, 2018 Page 4 of 89

1.2 Document Approvers

1.3 Document Review Plans

© IBM Corporation, 2018 Page 5 of 89

1.4 How to Find the Latest Revision of this Docu-

1.5 Document Distribution and Notification

© IBM Corporation, 2018 Page 6 of 89

2 Description & Client Value

© IBM Corporation, 2018 Page 7 of 89

2.2 Client Value

2.2.1 Performance / Quality

2.2.2 Expertise and Innovation

2.2.3 Adaptability & Flexibility

2.2.4 Risk Management

© IBM Corporation, 2018 Page 8 of 89

© IBM Corporation, 2018 Page 9 of 89

3.3 Multi-Provider Integration

3.4 Environment and Audience

© IBM Corporation, 2018 Page 10 of 89

4 Roles and Responsibilities

4.1 Customer Liaison

Specific responsibilities in the Change and Release Management processes include:

4.2 Change Analyst

© IBM Corporation, 2018 Page 11 of 89

Specific responsibilities include:

© IBM Corporation, 2018 Page 12 of 89

4.3 Change Manager

 Business Programs Manager: Change Management

Specific responsibilities include:

© IBM Corporation, 2018 Page 13 of 89

4.4 Integrated Service Manager

Specific responsibilities include:

© IBM Corporation, 2018 Page 14 of 89

4.5 Change Assessor

Specific responsibilities include:

4.6 Change Advisory Board Member

© IBM Corporation, 2018 Page 15 of 89

4.7 Emergency Change Advisory Board Member

4.8 Change Authority

Specific responsibilities include:

4.9 Separation of Duties Aggregate Matrix

© IBM Corporation, 2018 Page 16 of 89

5 Workflow Diagram Notation

Activities (Tasks, Steps) Events (Start, End, Connectors)

Notates the start of a workflow

Activity with Notates an activity with Notates the end of a workflow

Gateway (Decision Box)

Splits the flow and Swimlane

for activities and tasks

© IBM Corporation, 2018 Page 17 of 89

6.1 Activity Workflow Diagram

2.0 Document 5.0 Coordinate

7.0 Monitor, 8.0 Maintain