We reserve all rights in this document and in the information contained therein. Reproduction, use or disclosure to third parties without express authority is strictly forbidden.
ABB Ltd; 2014
ABB IS Service & Supply Integration
Change Management
Process Operations Manual
We reserve all rights in this document and in the information contained therein. Reproduction, use or disclosure to third parties without express authority is strictly forbidden.
ABB Ltd; 2014
Contents
1. Introduction ....................................................................................................................6
Purpose of the document ..............................................................................................6
Audience.......................................................................................................................6
2. Change Management process ........................................................................................6
Definition......................................................................................................................6
Scope ............................................................................................................................6
Process Inputs and Outputs ..........................................................................................7
Related Processes .........................................................................................................7
Process Objectives........................................................................................................7
Roles and Responsibilities............................................................................................8
Principles and Policies................................................................................................12
Change Types .............................................................................................................12
Environment Scope ....................................................................................................16
Change Creation .........................................................................................................16
Approvals ...................................................................................................................17
Change Evaluation and Assessment ...........................................................................18
Change Planning.........................................................................................................20
Lead Time...................................................................................................................24
Change Development .................................................................................................24
Change Testing ...........................................................................................................24
Change Priority...........................................................................................................25
Change Outages..........................................................................................................25
Change Freeze ............................................................................................................26
Change Advisory Board (CAB) .................................................................................26
Emergency Change Procedure....................................................................................32
Post Implementation Review......................................................................................34
Change Closure ..........................................................................................................34
Notifications ...............................................................................................................35
Change Management Process Flows & Workflows ...................................................36
ADONIS Level 4 Process Flow .................................................................................36
SNOW Workflows per change type ...........................................................................37
3. Reporting (KPIs + SLAs).............................................................................................49
4. Tower Specifics .............................................................................................................50
EUC ............................................................................................................................50
EUS.............................................................................................................................50
Core Software Platform (CSP) ...................................................................................50
Network ......................................................................................................................50
5. Stakeholders ..................................................................................................................50
6. Templates ......................................................................................................................50
RFC Template ............................................................................................................50
Functional Specification .............................................................................................50
Change Test Results ...................................................................................................51
Implementation plan ...................................................................................................51
Backup Plan................................................................................................................51
Point of No return details ...........................................................................................51
Communication Plan ..................................................................................................51
Backout plan ...............................................................................................................51
CAB Readiness Checklist...........................................................................................51
CAB Agenda & Minutes ............................................................................................51
Deployment Verification Plan ....................................................................................51
Post Implementation Review......................................................................................51
Weekly CAB meetings ...............................................................................................51
7. Vocabulary ....................................................................................................................52
8. External References......................................................................................................53
Process Policy Document – Change Management .....................................................53
Change Management workflows in SNOW ...............................................................53
Change Management – Stakeholders list ...................................................................53
1. Introduction
Purpose of the document
The purpose of this document is to explain Change Management process defined and implemented within
ABB IS RUN. It describes definitions, scope, policies, activities, roles & responsibilities and many other
practicalities that will help understand and run Change Management process from operational perspective.
This document outlines the operating guidelines for daily activities and processes used by all Change
Management stakeholders.
Audience
This document is intended to be used by ABB IS RUN personnel and Service Suppliers. Specifically Service
Suppliers will be responsible to align their internal working practices to this document in regards to handling
Changes.
2. Change Management process
Definition
A Change is defined as the addition, modification or removal of an authorized, planned or supported service or
Configuration Item (CI). Changes may occur due to introduction of a new service, modification to an existing
service or termination of an existing service in an IT Infrastructure or for fixing a problem in an existing
system.
Change Management helps organizations understand and work to minimize risks of changes to the IT
environment. It is essentially a process for managing the people-side of change.
Scope
Change Management process can be used to track and manage all IT infrastructure changes. A software
application change may include enhancements/modifications to existing applications to address identified
problems, address business needs or any other requirement. Similarly a hardware change may include changes
to computing devices, network components, storage devices and other hardware Configuration Items (CI) to
replace malfunctioning hardware, increase hardware capacity or other requirements. In other words, changes to
all Configuration Items will be governed by this process.
Process Inputs and Outputs
Related Processes
Process Input to Change Management Output from Change Management
Incident Management
Trigger for Change
Report on incidents arising out
of the failed changes
Approvals, Risk Assessment and
control of change required to be
implemented for incident
resolution.
Problem Management
Trigger for Change
Report on problems arising out
of the failed changes
Approvals, Risk Assessment and
control of change required to be
implemented for problem
resolution.
Service Asset and
Configuration
Management
CI Verification Information on changes to CIs for
updates of CMDB
Knowledge Management Input for process improvement Change Reports
Service Catalogue
Management
Service Requests Updates to Service Catalogue
Table 1Related Processes
Process Objectives
The goal of Change Management process is to maintain the integrity of the controlled IS environment. Change
Management is the “gateway” through which every change must pass on its way to the controlled environment.
Change Management process primarily aims at ensuring the implementation of changes with minimum risk to
the business.
The objectives of Change Management process are:
• Ensure efficient and prompt handling of changes
• Provide accurate and regular information about all planned changes
Change
Management
process
Updated CMDB
PIR Reports
Approved and Implemented
Change Documentation
Other Processes
PIR Reports
Business Requirements
Change Policies
CI Data from CMDB
• Ensure consistent procedures for change implementation to minimize the risk of failure
• Minimize Incidents resulting from the introduction of Changes
• Ensure risk and impact analysis to assess risk of changes and minimize risk of implementation
• Monitor and track the lifecycle of all changes
• Ensure proper categorization of changes and that proper procedures are followed for each type of change
• Reduce bureaucracy without compromising on controls for implementation of changes
Roles and Responsibilities
This section describes roles and responsibilities within Change Management process.
Change Requester (ABB, Service Provider)
This role is part of current ADONIS process. The Change Requester is the person who creates the change
request and submits it for further processing.
Major responsibilities include:
Creating and submitting a Change Request with accurate and detailed level of information
Obtaining additional information, as needed, for submitted Change Requests
Working with the OTL Change Coordinator to resolve any data inconsistencies with the request
Identifying parties to be notified and defining notification criteria
Testing and verifying Change was implemented according to request
Process Role Organizational Role ServiceNow Field
Change Requester (ABB,
Service Provider)
Service Providers\ABB IS
RUN
Requested by
OTL Change Coordinator (ABB)
This role is part of current ADONIS process. The OTL Change Coordinator is responsible for seeing that
Change Manager and other specialists bring the Change to a close.
Major responsibilities include:
Monitoring the lifecycle of an assigned Change
Verifying the supporting documentation accompanying the Change Record is complete
Assisting Change Requester with change creation
Performing Change Assessment (based on questions and answers)
Confirming Change Planning done by BTL Change Manager
Assisting Change Requester with test implementation when required
Chairing CAB/ECAB meetings
Conducting Post Implementation Review to verify implementation when required
Managing escalations relating to a Change
Making sure all required stakeholders are notified about the change
Process Role Organizational Role ServiceNow Field
OTL Change Coordinator
(ABB)
IS Tower Service
Coordinator
Change Task Assignment
Group/
Change Task Assigned To
BTL Change Manager (Service Provider)
This role is part of current ADONIS process. BTL Change Manager is responsible for carrying out various
activities in order to implement the change.
Major responsibilities include:
Planning and coordinating technical execution of the Change
Implementing/developing fully authorized Change
Attempting to resolve any issues with the implementation/development
Creating Functional and Technical Specifications
Performing unit & integration testing after Change implementation/development
Conducting Post Implementation Review to verify implementation when required
Updating manuals and operating instructions when applicable
Documenting Change implementation/development results (Post Rollout Documentation)
Verifying proper authorizations have been obtained and documented in the Change Record prior
to scheduling the change
Coordinating the implementation/development of the Change
Backing out an unsuccessful Change, if required
Verifying the update of the CMDB to reflect the implemented Change
Process Role Organizational Role ServiceNow Field
BTL Change Manager
(Service Provider)
Service Provider Change Assignment Group/
Change Assignee
OTL Change SME (ABB)
This role is part of current ADONIS process. OTL Change SME is the one responsible to technically review
and assess the change before it goes to production environment.
Major responsibilities include:
Reviewing functional specifications created by BTL Change Manager
Reviewing change before change deployment from technical point of view
Updating transport numbers, if required
Setting Post Rollout Documentation requirement, if necessary
Making sure required documentation is in place
Process Role Organizational Role ServiceNow Field
OTL Change SME (ABB) Subject Matter Expert Change Task Assignment
Group/
Change Task Assigned To
BTL Deployment Manager (Service Provider)
This role is part of current ADONIS process. BTL Deployment Manager performs the day-to-day management
of the deployment activities.
Major responsibilities include:
Defining implementation approach for deployment activities
Confirming that deployments are carried out on schedule
Implementing authorized Changes to the production environment
Carrying out the deployment plan to its completion
Attempting to resolve any issues arising during the deployment
Executing the Change remediation procedures, in case of a failure during one of the
implementation procedures
Updating manuals and operating instructions when applicable
Raising updates to CMDB for CI status changes
Verifying the Configuration Information is updated as appropriate
Process Role Organizational Role ServiceNow Field
BTL Deployment Manager
(Service Provider)
Service Provider Change Task Assignment
Group/ Change Task
Assignee
CI Owner
This role is part of current ADONIS process. Service Owner is responsible for individual Business Service.
Major responsibilities include:
Being the owner of Business Service in SNOW
Evaluating and approving changes during Pre-Approval, Functional Approval and for SOX related
changes
Process Role Organizational Role ServiceNow Field
CI Owner System/Application Owner Service Owner based on
Business Service
SD&A Approver
This role is not part of current ADONIS process. In case where changes are processed which impact ABB IS
RUN customers, the SD&A function shall be involved in the approval process before the change is deployed
into production. This approach ensures consistent decision making processes and allows for a pro-active
communication towards the ABB IS RUN customers.
Major responsibilities include:
Evaluating and approving changes (emergency, major & minor with Critical/High risk) before change
deployment
Manages Client Relationship and Business interface
Acts as a Single Point of Contact for communication to and from Business stakeholders
Process Role Organizational Role ServiceNow Field
SD&A Approver SD&A Managers Approver Group member
Technical Service Owner (ABB)
This role is not part of current ADONIS process. Technical Service Owner holds the responsibility for
managing the Tower Control.
Major responsibilities include:
Being accountable for Tower Control changes
Approving Changes during CAB\ECAB meeting
Process Role Organizational Role ServiceNow Field
Technical Service Owner
(ABB)
Tower Control Lead Change Task Assignment
Group/ Change Task
Assignee
Change Process Manager (ABB)
This role is not part of current ADONIS process. Change Process Manager holds operational responsibility for
managing the whole process.
Major responsibilities include:
Suggesting improvements to Change Management process
Reporting on the Key Performance Indicators (KPIs) to evaluate the effectiveness and efficiency of
the process
Ensuring all relevant staff have the required training on the process and are aware of their role in the
process
Process Role Organizational Role ServiceNow Field
Change Process Manager
(ABB)
SSI Change Task Assignment
Group/ Change Task
Assignee
Matrix
Detailed RACI is described Process Policy Document – Change Management.
Principles and Policies
All Principles and Policies have been described in Process Policy Document – Change Management. Most
important ones have been described in below sections.
Change Types
Classification of changes into different types is required for an efficient and effective Change Management
process primarily because of the following reasons:
All changes are not equal and need to be treated differently
Differentiation between changes that have different levels of risk has to be made and Change
Management process needs to achieve a balance between “change lifecycle times” and “controls for
risk mitigation”. This can be achieved by having different workflows for each class of change
Simple and Standard changes should be easy to implement and should not go through multiple levels
of approvals
Changes with different levels of risk to the controlled environment have different pre-deployment
requirements for risk control and mitigation
The following change types have been defined:
Change type Change Category
Request for Change (RFC) RFC – Major Change
Request for Change (RFC) RFC – Minor Change
Request for Change (RFC) RFC – Minor Operational Change
Standard Change Standard Change
Emergency Change Emergency Change
Emergency Change Expedited Change
Incident-initiated Change Incident-initiated Change – Major
Incident-initiated Change Incident-initiated Change – Minor
Table 2 Change Types
NOTE: The differentiation between categorizing a Change Type as minor or major occurs through the
completion of a structured Change Evaluation and Assessment.
The Emergency Change type is further categorized as Emergency Change or Expedited Change. The
differentiation is based on the definitions in the Emergency Change Categorization Policy.
Change Type/Tower CSP EUC Hosting Network
Standard Delete a Shared
mailbox.
There are no standard changes
implemented in Service
Catalogue as of yet. These could
be:
- Software packaging
- Addition of Network Printer in
the office
There are no standard
changes implemented
in Service Catalogue
as of yet.
There are no standard
changes implemented in
Service Catalogue as of
yet.
Minor OU creation on
every Country sub-
OU.
Software distribution in one
country or region by Wipro with
ABB involved in its specification.
Add new VM capacity
(RAM, Drive,
storage).
Cisco Prime installation.
Minor (Operational) Add a new DNS
record.
Software distribution in one
country or region by Wipro
without ABB involved in
specification.
Additional full
backup done of the
Server on AO request.
Skybox amendment.
Major New GPO deployed
globally.
Printing outage in whole country.
Worldwide deployment of a
software that significantly affects
user.
Desktops and is integrating with
other systems.
Core Network switch
upgrade in DC
(requiring device
downtime).
WAN/LAN
takeover/cutover.
Emergency Disable a non-
announced (by MS)
new feature from
O365 (. Sway).
Critical security patch
distribution.
Hotfix for O365 client software
following recent update.
VM Disc extension to
1 TB due to no free
space on SQL
instance.
Router exchange due to
failure.
Router reboot.
Change of configuration.
Table 3 Change Types examples
Standard Change
A pre-approved change which has the following characteristics:
Frequently performed and implementation for such a change that is simple and routine
Known and low risk but may include downtime
Proven implementation record – has been processed at least 5 times
Uses a fixed execution plan or is fully automated
Execution during standard maintenance windows unless otherwise agreed
Standard Change must be approved by CAB as routine in order to be included in the standard changes
catalogue
RFC Minor Change
A Minor change usually has the following characteristics:
Do not add any new bigger elements or functionality to the existing services
Should have no or very low impact to the user’s or business’ functionality
Is predictable and has a proven track record
NOTE: The categorization of a Minor or Major Change in ABB depends on a structured Change Evaluation
and Assessment.
RFC Minor Operational Change
A Minor change can be marked as Operational Change which has the following characteristics:
Typically no requirements engineering therefore no functional specification & review phase
Do not require ABB’s involvement during requirements gathering
Daily operational changes to keep infrastructure running (not business originated)
Mostly requested by Service Suppliers and ABB SMEs
Requiring only review and acceptance by SME for technical aspects and timeline
NOTE: The categorization of a Minor or Major Change in ABB depends on a structured Change Evaluation
and Assessment.
RFC Major Change
A Major Change usually has any of the following characteristics:
Has a high impact or risk to end-users or business functionality
Different levels and types of testing are required for implementation
Requires CAB process
The change is less predictable or has high risk
These are usually application enhancements, major bug fixes or projects
NOTE: The categorization of a Minor or Major Change depends on a structured Change Evaluation and
Assessment.
Incident-Initiated Change
An Incident-Initiated Change usually has the following characteristics:
It is required to resolve an Incident and can only be raised from a preceding Incident ticket
Follows all required steps within the full Change Management workflow, including all required
approvals and a controlled development, testing and deployment
NOTE: Incident-Initiated change is triggered from Incident and subject to categorization of a Minor or Major
Change based on structured Change Evaluation and Assessment.
Emergency Change
An Emergency Change usually has the following characteristics:
Result from Severity 1 Incidents and/or Problems
Required to repair an error in an IT Service that could negatively impact the business to a high degree
Changes are unplanned and are to have a short lead time to restore IT Services, whilst following the
workflow based approval process
Must always be confirmed by ABB IS RUN by the responsible Tower Control (Single Tower) or
Lead Tower Control (Cross-Tower)
Will be subject to a deployment approval by an Emergency Change Advisory Board (ECAB) in
advance of deployment, rather than a standard single tower or E2E Change Advisory Board (CAB)
NOTE: Emergency Change is subject to categorization of a Minor or Major Change based on structured
Change Evaluation and Assessment.
More information can be found under Emergency Change Process section.
Definition of Single vs. Cross Tower Change
Single Tower Changes: Are Changes where the change implementation is confined to a single Tower, even if
the service itself impacts across multiple Towers.
Single Tower Minor/Major Changes: Global Technology Operations has overall accountability for
the change process. For Single Tower Minor/Major Changes the Tower will execute the process and
retain responsibility for the end to end management of the change with SSI only being involved by
exception.
Single Tower Emergency Changes: Tower will execute the process and retain responsibility for the
end to end management of the change, which includes authorization for build and for production
deployment. SSI would be actively involved in Major Incident resolution and as such will provide a
communication platform acting as ECAB and authorizing change deployment to production for Major
Incidents. For all other Single Tower emergency changes, SSI may be engaged by tower in case of
escalation or arbitration is required. SSI will always be engaged for PIR process step.
Cross Tower Changes: Occur when significant involvement from more than one Tower is required to effect
the change.
Cross Tower Minor/Major Changes: Global Technology Operations have overall accountability for
the change processing, for Cross Tower Minor/Major changes the Lead Tower will execute the
process and retain responsibility for the end to end management of the change, which includes
authorization for build and for production deployment. In addition to that, SSI will hold accountability
for chairing E2E CAB that will review Cross Tower Major changes before the final authorization for
deployment is provided.
Cross Tower Emergency Changes: The Lead Tower will execute the process and retain
responsibility for the end to end management of the change, which includes authorization for build
and for production deployment. SSI would be actively involved in Major Incident resolution and as
such will provide a communication platform acting as ECAB and authorizing change deployment to
production for Major Incidents. For all other Cross Tower emergency changes, SSI may be engaged
by lead tower in case of escalation or arbitration is required. SSI will always be engaged for PIR
process step.
NOTE: This section has been copied from Process Policy Document – Change Management document.
Handling Cross-Tower Changes
Where multiple Towers (multiple service-offerings from different tower) are involved in processing the
change, one change ticket and additionally multiple tasks and approvals per change phase shall be triggered.
Tasks & Approvals are automatically triggered based on service-offerings selected on change record.
It is ABB Change Coordinator’s responsibility to confirm change as cross-tower during Change Assessment
phase.
Where Towers require multiple Change tasks or approvals in the same change phase, the Change tasks or
approvals must be assigned to the individual process roles responsible for performing that particular task
within a Tower.
Where multiple Towers are required to perform the same task or approval, the Change must not progress to the
next phase unless all Towers have completed their tasks.
The accountabilities and responsibilities for coordinating the cross-tower Change are following the agreed
principles for technical change coordination (Supplier) as well as the change coordination and technical
validation (ABB).
Environment Scope
The environment that is within the scope of Change Management process is called the Controlled
Environment. The changes to be implemented in the below mentioned list of controlled environments shall
have the approval from Change Management process:
Production
There are four implementation paths available for changes depending on the technical environments involved
in the change which can be selected while processing the change. The implementation path for a change,
selected when the change is initially logged, influences the workflow required to process the change in the
service management tool.
The following implementation paths are available for Minor/Major Changes:
Dev - QA - Prod (Auto Transport)
Dev - QA - Prod (Manual Transport)
Dev – Prod
Prod
Where a full implementation path through the Development and QA environments is selected to get to
production, additional development, testing, transport and approval tasks are required – likely to be used for
application changes and more complex infrastructure changes. Where a reduced implementation path straight
to the production environment is selected, fewer tasks are required – likely to be used for the majority of
infrastructure changes.
NOTE: Implementation path is usually set on Business Service level. However, it can be also selected or
updated manually.
Creation
Anybody may identify the need for a change. However, creation of Change must be initiated only
when proper justification exists, stating a change is required
Change Requester may or may not be an authorized Change Initiator (Change ticket creator). If not,
Change Requester will contact the authorized Change Initiator for initiation of Change
All members of the SNOW support groups are authorized to initiate Change Request
All SNOW mandatory information (fields) related to Change must be complete
Change can be submitted at any time as per the requirement
It may also be initiated due to proactive management by the IT support staff who realizes that a
change is required to a CI to keep it working efficiently
NOTE: Filled RFC Template should be attached to SNOW ticket during change creation.
Every change request must be approved before it can be implemented in the controlled environment. Each
approval will be time-stamped and recorded in Change record.
In case the approver is not available, he may delegate the approval authority to another approver and the
Change Management system will send a notification to the alternate approver about the delegation of approval
rights.
The following table lists the approval matrix for each type of change.
Change
Type/Category
Standard
Change
Approval
Pre-
Approval
Financial
Approval
Functional
Approval
UAT
Approval
SOX
Approval
Technical
Approval
SD&A
Appro
val
CAB/ECAB
Approval
Test in
Prod
Standard - x - - - - - x* - - x
Minor - x* x* x x x* x x** - x
Major - x* x* x x x* x x CAB x
Request
for
Change
(RFC) Minor
(Oper
ational
)
- x* - - - - x - - x
Emergen
cy
Emerg
ency
- x* - x x - - - ECAB x
Minor - x* - - x - x x** - xIncident-
Initiated
Major - x* - - x - x x CAB x
Responsible ATL Service
Owner
ATL IS
Manager
CI Owner
(Service
Owner in
SNOW)
Requester/
OTL
Change
Coordinat
or
CI Owner
(Service
Owner in
SNOW)
Change
SME
SD&
A
Mana
ger
CAB Group Requester/
OTL
Change
Coordinat
or
Table 4 Approvals' table
x* - optional
x** - for critical/high risk changes
approvers modification
It is possible to manually add additional approvals (individual names & groups) for future phases existing in
the defined workflow. This activity should be performed by BTL Change Manager during Change Planning
phase. ABB OTL Change Coordinator has ability to add additional approvals even after Change Planning is
completed.
Approvals that are generated automatically (based on change types) needs to be processed regardless of
additional approvals created.
Evaluation and Assessment
The categorization of a Change as Minor or Major depends on a structured Change Evaluation and
Assessment.
All non-standard changes must be assessed. The output of the change assessment is reflected by the sign off by
OTL Change Coordinator.
The formula in the table below should be used by Change Coordinator to assess the type of a change. From
each category, select the rating that best describes the change.
Cost, Complexity, Infrastructure – will be rated against a scale 1 – 5 each will earn a score of up to
five points each, depending on selection
Organization, Availability, Integrity – will be rated against a scale 1 – 5 but points will be doubled,
earning a score of up to ten points for each, depending on selection
Category
Organization
(Impact)
Cost
(Likelihood)
Availability
(Likelihood)
Integrity
(Impact)
Complexity
(Likelihood)
Infrastructure
(Likelihood)
Question Which target group
is affected by the
change request?
What are the expected
estimated costs for this
change?
What is the expected
downtime of the
affected service?
To what extend does the
change has impact to
critical functionality?
What is the
complexity of the
change?
What is planned
implementation path
for this change?
Risk
Rate\Weight for
Change Types
X2 x1 X2 X2 X1 X1
Risk
Rate\Weight for
Impact &
Likelihood
x1 x1 x2 x1 x1 x1
1 One PG or One Country Function < 1 kUSD No downtime expected No critical functionality
Simple maintenance
work with usually 1
technical team
involved
DEV-QA-PROD
2 One PG or One Local Division -
Downtime within
agreed maintenance
window
One non-critical
functionality
(documentation)
- DEV-PROD
3
One BU or One
Country or a
Function
< 10 kUSD
Downtime within
additional
maintenance window
Multiple non-critical
functionality
Medium complexity
with usually more than
1 team involved
-
4
One Region, One
Division or two or
more Bus
- - One critical functionality (orders) - -
5 Whole ABB Group > 10 kUSD Downtime during daily operation All critical functionality
Complex
implementation with
multiple teams
involved
PROD
Table 5 Change Evaluation and Assessment Matrix
The total number of points are summed, and the rating below is used to define the change as Major or Minor
Change.
8-27 Minor ChangeChange Evaluation
and Assessment Rating 28-40 Major Change
Table 6 Change Type rating
Minor Operational Change
Minor Changes that do NOT require ABB’s involvement in requirements gathering can become Operational
Changes. This involvement is determined as part of SNOW Change ticket task: ChgM 020 - Change
Assessment.
Table 7 Operational Change screenshot from SNOW
Cross-tower Change
During Change Evaluation & Assessment, ABB Change Coordinator should also evaluate whether change will
be processed as Single or Cross Tower.
Risk
Risk is made up of two parts: the likelihood (probability) of something going wrong, and the negative impact
(consequences) if it does.
Risk = Impact x Likelihood
Impact – A risk, by its very nature, always has a negative impact. However, the size of the impact varies in
terms of cost and impact on technology and business.
Likelihood – A risk is an event that "may" occur. The likelihood (probability) of it occurring can low, medium
or high.
Each of the questions from Change Evaluation & Assessment questionnaire has an effect on Impact (2
questions) & Likelihood (4 questions) of the change:
All five criteria (Organization, Cost, Integrity, Complexity, Infrastructure) earn a score of up to five
points each, depending on selection
The points for the Availability are doubled, earning a score of up to ten points for each, depending on
selection
The total number of points are summed and the rating below is used to define the Impact & Likelihood of the
Change.
Low 2-4
Medium 5-6Impact
High 7-10
Low 5-10
Medium 11-16Likelihood
High 17-25
Table 8 Change Impact & Likelihood rating
Overall Risk of the change is automatically calculated from Impact & Likelihood based on below matrix.
Likelihood\Impact Low Medium High
High Medium High Critical
Medium Low Medium High
Low Low Low Medium
Table 9 Overall risk rating based on Impact & Likelihood
Low
Medium
High
Risk
Critical
Table 10 Risk values
Likelihood & Impact values can be manually overwritten by OTL Change Coordinator & BTL Change
Manager after Change Assessment phase but before Change Technical Approval.
Upgrade or downgrade of the risk can take place when initial Change Evaluation & Assessment based on
questionnaire was not accurate or incorrect. Decision for upgrade/downgrade of the risk must be carefully
evaluated by both OTL Change Coordinator & BTL Change Manager.
IMPORTANT: Upgrading the risk to High/Critical will have an effect of additional approval as major &
minor changes assessed as High or Critical risk will be approved by SD&A!
Planning
The change plan of a change contains details about implementation, back-out and validation of the change. The
minimum level of detail of this plan depends on the change category and is described in this document.
The following information must be provided when planning a change:
A full description of the change, in language understandable by both ABB and Service Providers,
including content such as: the resources used, the change window (including planned outage) in which
to be implemented, list of all affected CIs, affected locations by the change, all expected costs, all
expected service and technical disruptions, stakeholder communication and approval requirements.
The planned timelines for the change, including start date (when development work will begin), end
date (when the change deployment will finish) and the date the change is requested to be completed
by the Requestor
Information whether outage is required in order to deploy the change to production environment
NOTE: Change Planning should be performed in SNOW Change ticket task: ChgM 110 - Change Planning.
Where the processing of a change requires additional steps and approvals which are not planned as per the
standard workflow for this Change type and category, ad-hoc Change tasks and approvals shall be created. Ad-
hoc Change tasks and approvals shall only be created and triggered by the responsible Change Manager.
Every ad-hoc Change task and approval shall be considered as an exception and must be explicitly documented
in the change ticket along with the name of person making the decision, date and time of the action and
mandatory explanation of the rationale behind.
Such change shall be reviewed on a regular basis by Single and Cross-tower Change Coordinators to assure
quality on the Change Implementation process.
Ad-hoc Change tasks and approvals shall not be created or modified anymore once the Change has been
authorized for deployment.
Each change requires at least one CI that is being affected during change implementation. If there is more than
one CI affected, all Affected CIs must be registered in change record.
NOTE: New task creation is restricted after deployment authorization.
The below table summarizes required, optional and not-required plans for Major, Minor & Operational
Changes.
Change Plan Description Major
Changes
Minor
Changes
Operational
Changes
Test Results
(Task ChgM 170
& 180a)
Changes should be tested as long in advance as is
reasonably possible before implementation. This should
include:
Functional-/Development Test
Integration testing
User Acceptance Testing
Regression testing
Required Required Required
Implementation
plan
(Task ChgM
110)
The Implementation plan should contain detailed
instructions about the implementation of the change. The
instructions are at such level of details that they are
understandable for the change implementer and minimize
the risk of mistakes.
Required Required Required
Backup Plan
(Task ChgM
110)
A backup may be necessary to enable a successful back-
out of the change. The implementation plan must contain
information if a backup is required. The back-up plan
describes if and how this backup must be made. May be
part of Implementation plan document.
Required
(if backup
created)
Required
(if backup
created)
Optional
Point of No
return details
(Task ChgM
110)
The change implementation plan may contain a point of no
return. When the point of no return is reached, back-out of
the change is not possible without invoking incident
management. May be part of Backout plan document.
Required Optional Optional
Communication
Plan
(Task ChgM
110)
The communication plan describes who is being informed
when the change is executed successfully and
unsuccessfully.
Required Optional Optional
Backout plan
(Task ChgM
110)
The backout plan must contain information about the
backout of the change. Should be prepared in advance.
Informal planning of the backout is only acceptable for
emergency changes.
The change record must contain sufficient details of
the back out plan so that any technician skilled in the
subject matter of the change is able to perform a
successful back out.
The circumstances under which the back out plan will
be invoked must be clearly specified in the change
record.
The estimated time that is required for back out must be
specified in the change record.
The change window must include the implementation
time plus the estimated back out time.
When due to the nature of a change backout is impossible
this must be clearly stated in the backout plan. Changes
where backout is impossible must be considered as high
risk.
Required Optional Optional
Deployment
Verification Plan
(Task ChgM
110)
The Deployment Verification Plan contains the
instructions to validate the outcome of the change. This
validation plan is executed within the change window and
is intended to discover possible issues caused by the
change. The validation enables the possibility to backout
the change in case of issues. May be part of
Implementation plan document.
Required Optional Optional
CAB Readiness
Checklist
(Approval
ChgM 205a)
CAB Readiness Checklist will allow to evaluate Change
Plan, Impact to the environment, Change Test, Business
Assessment Checks, Impact to customer and IT
organization.
Required Not
required
Not required
Table 11 Change Plans table for RFCs and Incident-initiated changes
Emergency Changes
The following information must be provided when planning for an Emergency Change:
A full description of the change, in language understandable by both ABB and Service Providers,
including content such as: the resources used, the change window (including planned outage) in which
to be implemented, list of all affected CIs, affected locations by the change, all expected costs, all
expected service and technical disruptions, stakeholder communication and approval requirements.
Emergency Change justification
The planned timelines for the change, including start date (when development work will begin), end
date (when the change deployment will finish).
Information whether outage is required in order to deploy the change to production environment
The below table summarizes required, optional and not-required plans for Emergency Changes:
Emergency Change
Change
Plans Description
Initial Planning (Prior to
ECAB and Deployment)
Retrospective
Documentation (After
Deployment)
Test Results Changes should be tested as far in
advance as is reasonably possible
before implementation. This should
include:
Functional-/Development
Test
Integration testing
User Acceptance Testing
Regression testing
Optional Optional
Change Plan
(Task ChgM
110)
The Implementation plan should
contain detailed instructions about
the implementation of the change.
The instructions are at such detail
level that they are understandable
for the change implementer
and minimize the risk of mistakes.
Required Required
Backup Plan
(Task ChgM
110)
A backup may be necessary to
enable a successful back-out of the
change. The implementation plan
must contain information if a
Optional Optional
backup is required. The back-up
plan describes if and how this
backup must be made. May be part
of Implementation plan document.
Point of No
return details
(Task ChgM
110)
The change implementation plan
may contain a point of no return.
When the point of no return is
reached, back-out of the change is
not possible without invoking
incident management. May be part
of Backout plan document.
Optional N/A
Communicati
on Plan
(Task ChgM
110)
The communication plan describes
who is being informed when the
change is executed successfully and
unsuccessfully.
Required
(if downtime required)
N/A
Backout Plan
(Task ChgM
110)
The backout plan must contain
information about the backout of
the change. Should be prepared in
advance. Informal planning of the
backout is only acceptable for
emergency changes.
The change record must contain
sufficient details of the back out
plan so that any technician
skilled in the subject matter of
the change is able to perform a
successful back out.
The circumstances under which
the back out plan will be
invoked must be clearly
specified in the change record.
The estimated time that is
required for back out must be
specified in the change record.
The change window must include
the implementation time plus the
estimated back out time.
When due to the aspects of a
change backout is impossible this
must be clearly stated in the
backout plan. Changes where
backout is impossible must be
considered as high risk.
Required (Draft Version) Required (Final Version)
Deployment
Verification
Plan
(Approval
ChgM 230a)
The Deployment Verification Plan
contains the instructions to validate
the outcome of the change. This
validation plan is executed within
the change window and is intended
to discover possible issues caused
by the change. The validation
enables the possibility to backout
the change in case of issues. May
be part of Implementation plan
document.
Optional Required
Table 12 Change Plans table for Emergency Changes
Time
A Lead Time is the latency between the initiation and planned start of the deployment.
NOTE: Currently not implemented in SNOW.
Development
Phase on which the development works is being carried out by the Service Provider for the change. This phase
includes technical specification preparation and development.
Where the implementation path of a change is not straight to Production – it moves through the Development
and/or QA environments – there may be a need to document requirements for the ‘transport’ of the developed
change between environments.
These transport requirements should be sufficiently detailed and specific for the performing Service Provider
to understand and carry out, and be clear enough for ABB IS to identify and coordinate.
Change Development activities must be registered in SNOW under “ChgM 150 – Change Development” task.
Testing
Changes should be tested as far in advance as is reasonably possible before implementation. This should
include:
Functional-/Development Test
o Internal development, unit test done by developer
o SNOW Change Task: ChgM 170 Functional-/Development Test
Integration Testing
o Main purpose of that test is to make sure that development completed by the developer meets
the requirement presented in Functional Specification
o SNOW Change Task: ChgM 170 Functional-/Development Test
User Acceptance Testing
o UAT phase acts as final verification of the requested change and confirmation of proper
functionality of the system. Should be done by Requester or Service Coordinator
o SNOW Change Task: ChgM 180a – UAT
Regression Testing
ECAB
Readiness
Checklist
(Approval
ChgM 205a)
ECAB Readiness Checklist will
allow to evaluate Change Plan,
Impact to the environment, Change
Test, Business Assessment Checks,
Impact to customer and IT
organization.
Required N/A
Emergency
Change
Justification
It should be clearly described the
reason for change to be handled as
an Emergency Change. Part of
Implementation Plan.
Required Required
o Regression testing is a type of testing that seeks to uncover new bugs, or regressions, in
existing functional and non-functional areas of a system after changes such as enhancements,
patches or configuration changes have been made to it
o To be performed only for major, risky changes
o SNOW Change Task: ChgM 180a – UAT
Change Test Results template should be used to register results of testing.
Priority
Priority is defined as something that is more urgent or important than other things. Purpose of Change Priority
is to separate more important/urgent changes from others.
Change Priority should be set by OTL Change Coordinator based on his best knowledge and judgment of the
importance of the change.
The following values have been defined for Change Priority: Low, Medium and High.
NOTE: Change Priority is not dependent on any other change related field and has no effect on change
management workflow.
Outages
The following outage procedures are intended to provide centralized scheduling, tracking and communication
of planned and unplanned outages to IT infrastructure. The procedures apply to any planned and unplanned
outages to current infrastructure, including but not limited to servers, critical hosting and operations services
(such as E-Mail, Web, DNS, DHCP, and databases) and any and all infrastructure services.
Outage
Planned outage (=planned downtime) is the time for scheduled maintenance during which a system cannot be
used for normal productive operations and is used for Change deployment related activities.
It is BTL Change Manager’s responsibility (together with OTL Change Coordinator) to agree planned outage
window with Service\Application Owner of the affected service. Planned outage window must be agreed
during change planning and approved at least 5 days before change deployment.
Planned outages must be registered in change ticket by BTL Change Manager latest during Change Planning
phase. The following information is mandatory:
Planned Start Date
Planned End Date
What services are affected
Percentage of the outage (100% if whole system will not be available)
NOTE: If planned outage window has been exceeded by Change Implementer, unplanned outage should be
registered.
Outage
Unplanned outage is the time during which a system cannot be used for normal productive operations due to
unforeseen failure in hardware/software components.
From Change Management point of view unplanned outage should be registered by OTL Change Coordinator
if planned downtime window has been extended during change implementation.
Freeze
Change Freeze is the time period during which an organization wants to avoid any changes in the controlled
environment because of business criticality.
NOTE: Currently not implemented in SNOW.
Advisory Board (CAB)
Purpose
The Change Advisory Board (CAB) represents a structured body that evaluates and assesses proposing
changes to the controlled environment.
The CAB shall ensure that:
Impact analysis of the proposed changes is performed
Change requests are fully reviewed for technical and financial implications
Scheduling decisions are made in a timely and efficient fashion and are communicated to all the
relevant stakeholders
Change Advisory Board (CAB) as a role in change management process is a group of associates who have the
decision making authority for implementation approval of changes. The CAB comprises of representatives
from business, change coordinators, change managers and technical support teams (SMEs). This group
participates in the scheduled CAB meetings and takes decisions on presented change requests.
Key Rules
SNOW is the authoritative source of information for change requests
All CAB relevant change requests are presented to the CAB for approval prior to implementation
CAB requires a time prior to change implementation to review the changes
Change request not having complete information required for CAB review is not placed on CAB
agenda
CAB Approvals is done through “ChgM 205a – CAB Approval” for Major Changes
Change request scheduled for CAB review needs to have its representation
& ECAB Entry Criteria for a Change
CAB Entry criteria ECAB Entry criteria
All required change plans must be
completed and attached to SNOW
Change Ticket
Change Initiator must be confident that
the proposed Emergency Change is fit for
purpose and has been accepted as an
Emergency by ABB Service Coordinator
CAB Readiness Checklist must be filled
in (part of Implementation Plan) and
attached to SNOW Change Ticket
Change Ticket must be assigned to CAB
assignment group close of business
(COB) the day before CAB meeting
All required change plans must be
completed and attached to SNOW
Change Ticket
CAB Readiness Checklist must be filled
in (part of Implementation Plan) and
attached to SNOW Change Ticket
Change Ticket must be assigned to CAB
assignment group before ECAB meeting
Table 13 CAB/ECAB Entry criteria
Meeting Format
To keep the meeting short, effective and consistent the following meeting format is described below:
1) Call in. Participants call in to determine if there is proper representation for the
Changes being reviewed. If there is no representative to address questions, the change will remain in a
pending state until the next CAB meeting.
2) Present and discuss changes on the report to CAB members. CAB Chair presents changes for CAB.
Members discuss each change and perform proper risk assessment analysis.
3) Approval. When it is determined that the concerns or conflicts no longer exist with a presented
change, the CAB will approve the change. Change requests requiring a lengthy discussion, or
determined not to be properly planned, will be left in a pending state and the discussion taken off-line.
4) Create and post CAB Agenda & Minutes showing all reviewed changes after the CAB meeting.
Decision Process
The outcome of each CAB meeting should be decision whether discussed Change has been approved or
rejected. These are all possible scenarios:
Approved – Change has met all criteria’s for approval and it can be approved for production rollout.
Conditionally Approved - Change has not met all criteria’s for approval but can still proceed to
production rollout only after specific condition is fulfilled. Change Coordinator must clearly state
under which condition Change can proceed to production rollout.
Rejected – Change has not been approved and is permanently rejected. Decision should be
documented, Change record should be closed with proper information.
Rescheduled – If Change cannot be approved on the CAB meeting due to various reasons (.
downtime not approved, lack of documentation, risk not mitigated, etc.), it should be postponed for
another CAB meeting. Evaluation Management task should be rejected – Change will reverse to
previous stage. It can be resubmitted back to CAB once ready.
Decision should be documented in CAB Agenda & Minutes , SNOW Change Record and stored on Group IS
Infrastructure RUN Collaboration Portal under Weekly CAB Meetings section.
file:///C:/Users/PLPIKRA/Desktop/Group%20IS%20Infrastructure%20RUN%20Collaboration%20Portal
file:///C:/Users/PLPIKRA/Desktop/Group%20IS%20Infrastructure%20RUN%20Collaboration%20Portal
Readiness Checklist
The following questionnaire should be used by the Change Advisory Boards to assess Technical and Business
risk and decide whether the Change will be authorized for deployment or not. Below checklist is to support
(not force) decision making process.
Assessment
Type
Assessment
Category
Criteria Check (Y/N)
Is the change risk set correctly?
Is the estimated implementation time realistic?
Is the backout plan detailed enough?
Change Plan
Has the change plan been correctly designed and
developed?
Is there sufficient capacity within the IT environment to
execute the change successfully?
Are the implications to disaster recovery taken into
account?
Impact to the
environment
Are the security implications taken into account?
Technical
Change Test Is the test plan properly documented?
Is the impact on business operations taken into account?Business
Assessment
Checks Is the change fully described?
Is the change scheduled within the maintenance or
authorized change window?
Is the change window long enough to cover all change
activities including a possible back-out?
Business
Impact to
customer and
IT
organization
Are the stakeholders informed of the change?
Table 14 CAB Readiness Checklist
NOTE: This checklist is part of Implementation Plan document.
Types & Scope
The following CAB types have been defined in ABB organization:
Single Tower CAB
o Applicable for major changes classified as Single Tower Major Changes
End 2 End CAB (E2E CAB)
o Applicable for major changes classified as Cross Tower Major Changes
Emergency Single Tower CAB (ECAB)
o Applicable for minor and major changes classified as Emergency Single Tower Changes
Emergency End 2 End CAB
o Applicable for minor and major changes classified as Emergency Cross Tower Changes
Schedule
CAB Type Tower
Name
CAB Chair CAB Timing
EUC IS EUC Service
Coordinator
Every WED 13:00-14:00 CET
Network IS Network Service
Coordinator
Every WED 14:00-15:00 CET
Hosting IS Hosting Service
Coordinator
Not yet live
Single Tower CAB
CSP IS CSP Service
Coordinator
Every WED 16:00-17:00 CET
End 2 End CAB Cross
Tower
IS SSI Service
Coordinator
Every THU 14:00-15:00 CET
EUC IS EUC Service
Coordinator
Ad-hoc
Network IS Network Service
Coordinator
Ad-hoc
Hosting IS Hosting Service
Coordinator
Ad-hoc
Emergency Single
Tower CAB
CSP IS CSP Service
Coordinator
Ad-hoc
Emergency E2E CAB Cross
Tower
IS SSI Service
Coordinator
Ad-hoc
Additional Cross
Tower CAB*
Cross
Tower
IS SSI Service
Coordinator
Every FRI 14:00- 15:00 CET*
Table 15 CAB Types
*Additional CAB placeholder - only used in case of need.
Tower CAB
Single Tower CAB Decision by: Technical Service Owner
Scope
Single Tower Major Changes
Schedule
Weekly
Agenda
Review and assess changes that are CAB-relevant
Approve/reject Changes for deployment
Change statistics of the week (CAB report)
Continuous CAB improvements (whenever necessary)
Membership
The CAB should be as small as possible, to facilitate quick decision making but it must include
representatives from all the relevant teams. These representatives participate in the scheduled weekly
CAB meetings and support decisions on presented change requests. CAB chair will arrange for
appropriate attendees to be invited. All attendees to the CAB have a consulting role.
CAB Chair= IS Tower Change Coordinator (mandatory)
Technical Service Owner (mandatory)
Change Manager (mandatory)
SD&A Manager (mandatory)
CI Owner (optional)
Subject Matter Experts (optional)
Approval
All changes will be reviewed and assessed against CAB entry criteria
o All mandatory change plans must be completed and attached to SNOW Change
Ticket
o CAB Readiness Checklist must be filled in and attached to SNOW Change Ticket
Final decision will be made by Technical Service Owner (can be delegated)
o Business Representative overwrites Business Service Owner (SSI)
o Business Service Owner overwrites Technical Service Owner (Tower Control)
o Technical Service Owner overwrites Lead tower Service Provider
o Lead tower Service Provider overwrites Supporting tower Service Provider
Table 16 Single Tower CAB description
2 End CAB (E2E CAB)
End 2 End CAB (E2E CAB) Decision by: Business Service Owner (SSI)
Scope
Cross Tower Emergency Major Changes
Schedule
Weekly
Agenda
Review and assess changes that are CAB-relevant
Approve/reject Changes for deployment
Change statistics of the week (CAB report)
Continuous CAB improvements (whenever necessary)
Membership
The CAB should be as small as possible, to facilitate quick decision making but it must include
representatives from all the relevant teams. These representatives participate in the scheduled weekly
CAB meetings and support decisions on presented change requests. CAB chair will arrange for
appropriate attendees to be invited. All attendees to the CAB have a consulting role.
CAB Chair=SSI Change Coordinator (mandatory)
IS Tower Change Coordinator (mandatory)
Technical Service Owner (mandatory)
Change Manager (mandatory)
SD&A Manager (mandatory)
CI Owner (optional)
Subject Matter Experts (optional)
Approval
All changes will be reviewed and assessed against CAB entry criteria
o All mandatory change plans must be completed and attached to SNOW Change
Ticket
o CAB Readiness Checklist must be filled in and attached to SNOW Change Ticket
Final decision will be made by Business Service Owner (SSI)
o Business Representative overwrites Business Service Owner (SSI)
o Business Service Owner overwrites Technical Service Owner (Tower Control)
o Technical Service Owner overwrites Lead tower Service Provider
o Lead tower Service Provider overwrites Supporting tower Service Provider
Table 17 End 2 End CAB description
Single Tower CAB (ECAB)
Emergency Single Tower CAB (ECAB) Decision by: Technical Service Owner
Scope
Single Tower Emergency Minor Changes
Single Tower Emergency Major Changes
Schedule
Ad-hoc
Agenda
Review and assess Emergency Changes that are CAB-relevant
Approve/reject Changes for deployment
Membership
The ECAB should be as small as possible, to facilitate quick decision making but it must include
representatives from all the relevant teams. If Emergency Change is to fix S1 Incident and
Technical/Business Bridge meeting is already established, ECAB meeting can be organized during
the same call. All attendees to the ECAB have a consulting role.
CAB Chair=IS Tower Change Coordinator (mandatory)
Technical Service Owner (mandatory)
Change Manager (mandatory)
SD&A Manager (mandatory)
CI Owner (optional)
Subject Matter Experts (optional)
Approval
All changes will be reviewed and assessed against ECAB entry criteria
o All mandatory change plans must be completed and attached to SNOW Change
Ticket
o CAB Readiness Checklist must be filled in and attached to SNOW Change Ticket
Final decision will be made by Technical Service Owner (can be delegated)
o Business Representative overwrites Business Service Owner (SSI)
o Business Service Owner overwrites Technical Service Owner (Tower Control)
o Technical Service Owner overwrites Lead tower Service Provider
o Lead tower Service Provider overwrites Supporting tower Service Provider
Table 18 Emergency Single Tower CAB description
End 2 End CAB (E2E ECAB)
Emergency End 2 End CAB (E2E ECAB) Decision by: Business Service Owner(SSI)
Scope
Cross Tower Emergency Minor Changes
Cross Tower Emergency Major Changes
Schedule
Ad-hoc
Agenda
Review and assess Emergency Changes that are CAB-relevant
Approve/reject Changes for deployment
Membership
The ECAB should be as small as possible, to facilitate quick decision making but it must include
representatives from all the relevant teams. If Emergency Change is to fix S1 Incident and
Technical/Business Bridge meeting is already established, ECAB meeting can be organized during
the same call. Only if all required participants are present on the meeting. All attendees to the ECAB
have a consulting role.
CAB Chair=SSI Tower Change Coordinator (mandatory)
Technical Service Owner (mandatory)
Change Manager (mandatory)
SD&A Manager (mandatory)
CI Owner (optional)
Subject Matter Experts (optional)
Approval
All changes will be reviewed and assessed against ECAB entry criteria
o All mandatory change plans must be completed and attached to SNOW Change
Ticket
o CAB Readiness Checklist must be filled in and attached to SNOW Change Ticket
Final decision will be made by Business Service Owner (SSI)
o Business Representative overwrites Business Service Owner (SSI)
o Business Service Owner overwrites Technical Service Owner (Tower Control)
o Technical Service Owner overwrites Lead tower Service Provider
o Lead tower Service Provider overwrites Supporting tower Service Provider
Table 19 Emergency End 2 End CAB description
Change Procedure
Change definition
A Change shall be considered as an Emergency Change when the Change is required to be implemented
immediately to prevent ABB from being open to significant risk. Any Emergency Change must always be
confirmed by ABB IS RUN either as an Emergency Change or as an Expedited Change before being
processed.
An Emergency Change is triggered through the service management tool and shall only be raised by ABB IS
Suppliers or ABB IS RUN.
categorization & confirmation
An Emergency Change must be confirmed by the responsible Tower Control (single tower) or Lead Tower
Control (cross-tower). The confirmation of an Emergency Change happens in the service management tool by
completing a dedicated Emergency Change confirmation task.
The following policies shall apply to get confirmation of an Emergency Change:
Any authorized IS Supplier or ABB IS RUN raises an Emergency Change during the logging phase
When logging the Emergency Change in the service management tool the reason, the justification as
well as the purpose of the change shall be documented
The reason, justification should reference the criteria for confirming an Emergency Change as
described in the Emergency Change and Expedited Change Confirmation Criteria Policy
Tower Control (single-tower) or Lead Tower Control (cross-tower) shall be accountable and
responsible for assessing and evaluating the Emergency Change details including provided change
documentation and either will confirm or reject the Emergency Change.
The confirmation of an Emergency Change shall have the following three possible outcomes:
Confirmed as Emergency Change
Confirmed as Expedited Change
Rejected as Emergency Change
The criteria for confirming an Emergency Change as an Emergency Change shall be:
Active Major Incident
Active Severity 1 Incident
The criteria for confirming an Emergency Change as an Expedited Change shall be:
A Change is required to avoid an Incident and the required implementation time of the change falls
below the lead times for the default change type.
Changes that are required – no relationship to an Incident - and the required implementation time of
the change falls below the lead times for the default change type.
Examples:
Legal requirement
Business need
VIP requesting a change
Security threats
Change Implementation Policy
An Emergency Change shall be implemented through a streamlined change lifecycle ensuring quick
progression through development, testing, approval and deployment phases, followed by retrospective
documentation, regression testing, assessment and a second approval phase.
The Emergency Change lifecycle leverages ad-hoc decision making processes controlled by the Emergency
Change Advisory Board (ECAB). The retrospective phases of the lifecycle are controlled by the default
Change Advisory Board (CAB) to ensure the assessment of the Emergency Change without immediate time
pressure and with a focus on the long-term sustainability and quality aspects of the Emergency Change.
Both categories of an Emergency Change (confirmed Emergency Change and confirmed Expedited Change)
shall be managed through the same Emergency Change process.
Any Emergency Change shall be subject to a deployment approval by an Emergency Change Advisory Board
(ECAB) in advance of deployment, rather than a standard single tower or E2E Change Advisory Board (CAB).
Changes
Retrospective Changes are changes to Services\CIs that were modified\added without following normal change
management procedures. A Retrospective Change may result from an automated action, such as a patch
applied by the system, or a server restart initiated by an event monitoring system.
Finally, a Retrospective Change may also be an unauthorized Change detected automatically by the system or
manually by system administrator.
In all cases the Retrospective Change must be recorded in ITSM tool and processed as normal through proper
change workflow based on the change type.
Change can only be logged as Retrospective Change by Change Coordinators during Change Assessment
phase. Retrospective Change attribute disables the validation for Planned Rollout Start & End Dates. It allows
to enter dates in the past in order to log when change has been implemented in the target system.
Retrospective Change flag can be applied to the following change types: Major, Minor and Emergency.
Note: When due to the urgency of Emergency changes the change record cannot be created prior to the
execution of the change, a retrospective change must be created afterwards. Evidence of the authorization
(email, call details, names of the change approver) must be documented in the change record immediately after
change implementation.
Implementation Review
A Post Implementation Review (PIR) can be carried out to review whether a completed change has met its
stated objectives. A PIR aims to review and capture metrics which can be used to learn from, and continually
improve, the processes.
The PIR will capture a summary of the outcome of the change – the result, any unexpected side-effects,
whether the change was backed-out– including a detailed analysis of anything that went wrong, Requestor and
stakeholder feedback for the change, and any lessons learned that can be taken forward for future
implementations.
PIR should be performed for:
All Major Changes
All Failed Changes
All Escalated Changes
All Emergency Changes
All Changes upon request from Single, Cross-tower and Emergency Change Coordinator
Random sample for up to 5% of successful Minor Changes
Random sample for up to 2% of successful Standard Changes
Post Implementation Review Development activities must be registered in SNOW under “ChgM 250 – Post
Implementation Review” task. PIR template should be filled in and attached to SNOW ticket.
Closure
The final closure of a Change Request is triggered as soon as all related tasks are completed (including Post
Implementation Review, if applicable). Any Change ticket when being closed requires the allocation of a
Change Closure Code in order to describe the state of the Change upon closure. BTL Change Manager’s
responsibility is to select proper closure code and pass it to ABB OTL Change Coordinator for verification.
ABB OTL Change Coordinators will be able to overwrite values (closure codes) up to 7 days after closure. If
no action will be taken by ABB OTL Change Coordinators, Change will be automatically closed with the
closure code selected by BTL Change Manager.
Change Closure Codes are:
Successful
o Implemented as per approved plan and executed within time frame
o Result was as expected and no backout necessary
o No side effects were noticed post implementation
o Failed flag: NO
Successful with problems
o Implemented as per approved plan but outside of authorized time frame (based on planned
dates in SNOW), such deviation should be authorized by ABB or
o Implemented with authorized deviation (unusually minor) to the plan, required to achieve
expected results, within approved time frame
o Result was as expected and no backout necessary
o Failed flag: NO
Failed with outage
o Implemented but resulting in an incident
o Result was not as expected
o Implemented not as per approved plan (deviations not approved by ABB)
o Failed flag: YES
Failed with no outage
o Implemented but not resulting in an incident
o Result was not as expected
o Implemented not as per approved plan (deviations not approved by ABB)
o Failed flag: YES
Rejected
o Not implemented as it was rejected by the approver before implementation started
o Failed flag: NO
Aborted
o Not implemented as it was cancelled by the requester before implementation started
o Failed flag: NO
The objective of notification is to ensure the responsible role within the process is notified of the occurrence of
any event that requires further action by that role within the process. Standard automated notification (. via
email) is available in SNOW. In some situations additional notification is required.
The following notifications have been enabled in SNOW PROD:
Notification Name
Change Aborted
Change assigned to me
Change Pending SME Review
Change requires Evaluation
Change Task assigned to my group
Confirm Change Schedule
Emergency Change Confirmation
Pending Closure - Supplier
Pending Closure - ABB
Table 20 SNOW PROD Notifications
Management Process Flows & Workflows
Level 4 Process Flow
Figure 1 High level Change Management Level 4 process flow
The Change Management process contains 10 detailed (Level 5) sub-processes:
1) Change Logging
2) Change Planning
3) Change Build and Test Authorization
4) Change Build and Test Coordination
5) Change Deployment Authorization
6) Change Deployment
7) Post-Implementation Review
8) Change Closure
9) Emergency Change coordination
10) Single and Cross Tower Change Coordination and Escalation
Detailed Change Management Level 4 & 5 process flows are described in ADONIS tool.
Workflows per change type
All workflows described in below sections are configured in SNOW Change Management module. Tasks are
triggered accordingly based on change type and flags set manually and automatically during change execution.
Sub-Process SNOW Phase Responsible Task/Approv
al/Function
Required
Documentation
Change Logging ChgM 010a – Pre Approval Service Owner
Group
Approval Filled RFC
Template
Change Logging ChgM 020 - Change
Assessment
Change
Coordinator Group
Task Filled RFC
Template
Change Logging ChgM 050 - Functional
Specification
Change Manager
Group
Task Functional
Specification
Change Logging ChgM 070 - SME feedback Change SME
Group
Task N/A
Change Logging ChgM 095 - Emergency
Change Confirmation
Change
Coordinator Group
Task N/A
Change Planning ChgM 110 - Change
Planning
Change Manager
Group
Task All required
Change Plans
Change Planning ChgM 120 - Change Plan
Confirmation
Change
Coordinator Group
Task N/A
Change Build and
Test Authorization
ChgM 130a - Financial
Approval
Financial Approval
Group
Approval N/A
Change Build and
Test Authorization
ChgM 140a - Functional
Approval
Service Owner
Group
Approval N/A
Change Build and
Test Coordination
ChgM 150 - Change
Development
Change Manager
Group
Task Change Test
Results,
Implementation
plan
Change Build and
Test Coordination
ChgM 160 – Manual
Transport
Deployment
Manager Group
Task N/A
Change Build and
Test Coordination
ChgM 170 – Functional-
/Development Test
Change Manager
Group
Task Change Test
Results
Change Build and
Test Coordination
ChgM 180a - UAT Requester/Change
Coordinator Group
(based on Business
Service setup)
Approval Change Test
Results
Change Deployment
Authorization
ChgM 190a – SOX
Approval
Service Owner
Group
Approval N/A
Change Deployment
Authorization
ChgM 200 – Technical
Approval
SME Group Task All required
Change Plans,
CAB report
Change Deployment
Authorization
ChgM 203a – SD&A
Approval
SD&A Group Approval N/A
Change Deployment
Authorization
ChgM 205a – CAB/ECAB
Approval
CAB Group Approval All required
Change Plans,
CAB report
Change Deployment ChgM 210 – Change
Deployment
Change Manager
Group
Task Implementation
plan
Change Deployment ChgM 220 – Finalize
Change Development
Change Manager
Group
Task N/A
Change Deployment ChgM 230a - Test in
Production
Requester/Change
Coordinator Group
(based on Business
Service setup)
Approval Change Test
Results
Change Deployment ChgM 240 - Post Rollout
Documentation
Change Manager
Group
Task N/A
Emergency Change
Coordination
ChgM 245 - Retrospective
EC Approval by E2E CAB
Change Advisory
Board
Approval All required
Change Plans,
CAB report
Post-Implementation
Review
ChgM 250 - Post
Implementation Review
Change
Coordinator Group
Task Post
Implementation
Review
Change Closure ChgM 260 - Service
Catalogue Record
Change
Coordinator Group
Task N/A
Change Closure ChgM 280 – Close Change Change Manager/
Change
Coordinator Group
Function N/A
Table 21 List of all possible tasks in SNOW
Table 22 List of all tasks/approvers/functions implemented in SNOW tool
Detailed description of all tasks.
Step ChgM 010a Pre Approval Executed by: Service Owner Group
Description This approval is dependent on Pre-Approval Flag set on Business Service level. Its purpose is to
evaluate whether change make sense and change process should start.
Inputs Change Record
Outputs Approved/Rejected Change Record
Attachments N/A
Step ChgM 020,
ChgM 100 Change Assessment Executed by: Change Coordinator Group
Description Assess the risk and impact of the change. The following activities to be done as part of this task:
Verify that filled in RFC Template is attached to SNOW Change Ticket
o If not – ask Change Requester to provide the document
Fill-out and Execute Risk Assessment through “Risk Assessment” questionnaire
configured in SNOW tool. This will determine where change is classified as Major or
Minor
Set “Planned Rollout Start & End Dates”, if known
Select Implementation path (if not automatically set on Business Service)
Set Cross-tower change Flag (if change should be treated as Cross-tower)
o Affected services must be added
Set Operational Change flag, if required
Set Post Implementation Review flag (if required)
Set SOX flag (if change is SOX relevant)
Provide Risk Explanation if risk is higher than Low
Inputs Filled in RFC Template
Outputs Evaluated Change Record
Attachments Filled in RFC Template
Step ChgM 050 Functional Specification Executed by: Change Manager Group
Description Prepare Functional Specification that will be base for development. The following activities to be
done as part of this task:
Fill-out Functional Specification using pre-defined template and attach to SNOW Change
Ticket
Estimate Cost of the change (put 0 if development is part of the contract)
Set/Update “Planned Rollout Start & End Dates”
Set Post Rollout Documentation flag (additional task will be triggered after rollout)
Inputs Change Record
Outputs Functional Specification doc
Attachments Functional Specification doc
Step ChgM 070 SME feedback Executed by: Change SME Group
Description Review Functional Specification from technical point of view. The following activities to be done
as part of this task:
Review (update if required) and approve Functional Specification document prepared by
Change Manager Group
Inputs Functional Specification
Outputs Reviewed/Revised Functional Specification doc
Attachments Reviewed/Revised Functional Specification doc
Step ChgM 095 Emergency Change Confirmation Executed by: Change Coordinator Group
Description Evaluate whether the change can be processed as an Emergency.
The criteria for confirming an Emergency Change as an Emergency Change shall be:
Active Major Incident
Active Severity 1 Incident
The criteria for confirming an Emergency Change as an Expedited Change shall be:
A Change is required to avoid an Incident and the required implementation time of the
change falls below the lead times for the default change type.
Changes that are required – no relationship to an Incident - and the required
implementation time of the change falls below the lead times for the default change type.
Inputs Change Record
Outputs Approved/Rejected Emergency Change
Attachments N/A
Step ChgM 110 Change Planning Executed by: Change Manager Group
Description Perform Change Planning to be performed by Change Manager Group. The following activities to
be done as part of this task:
Prepare Change Plans & attach to change record using pre-defined template
Set Post Rollout Documentation Flag, if required
Set Planned Rollout Start & End Dates if not yet known
Set Affected Locations
Set all affected Configuration Item(s)
Enter outage information, if required
Add any additional tasks/approvals for future phases, if required
Inputs Change Record
Outputs Change Plans created and attached to SNOW Change Ticket
Attachments Filled in RFC Template, All required change plans
Step ChgM 120 Change Plan Confirmation Executed by: Change Coordinator Group
Description Change Plan Confirmation to be performed by Change Coordinator Group. The following activities
to be done as part of this task:
Update “Planned Rollout Start & End Dates”
Review Change Plans
Additional tasks/approvals can be created for future phases
Inputs Change Plans
Outputs Confirmed Change Plans
Attachments All required Change Plans
Step ChgM 130a Financial Approval Executed by: Financial Approval Group
Description Review the cost estimates and approve/reject Change from financial point of view.
NOTE: This approval is triggered based on threshold set on Business Service.
Inputs Estimated Cost
Outputs Approved/Rejected Change
Attachments N/A
Step ChgM 140a Functional Approval Executed by: Service Owner Group
Description Review the change from Functional point of view. The following activities to be done as part of this
task:
Review Approve Functional Specification document prepared by Change Manager Group
Inputs Functional Specification doc
Outputs Approved Functional Specification doc
Attachments Reviewed/Revised Functional Specification doc
Step ChgM 150 Change Development Executed by: Change Manager Group
Description Document development including internal development testing. The following activities to be done
as part of this task:
Develop Change
Perform functional testing in development environment
o Fill-out Change Test Results template
Document all transports needed to bring change into production
Set Actual Start & End Time of the deployment
Make sure Implementation plan is created (use template) and attached to SNOW Change
ticket
Inputs Functional Specification doc
Outputs Developed Change
Attachments Change Test Results, Implementation plan
Step ChgM 160 Manual Transport Executed by: Deployment Manager Group
Description Document transport of changes from development to testing environment. All transports numbers to
be updated, if required.
Document all transports needed to bring change into production
o Use SNOW task functionality to document Transport #
Inputs Developed Change
Outputs Change migrated/transported to testing environment
Attachments N/A
Step ChgM 170 Functional-/Development Test Executed by: Change Manager Group
Description Perform internal development test in QA environment.
Perform functional testing in development environment
o Fill-out Change Test Results template
Inputs Developed Change
Outputs Change Test Results
Attachments Change Test Results
Step ChgM 180a UAT Executed by: Requester or Change Coordinator Group
Description Perform User Acceptance Testing in QA environment. The following activities to be done as part of
this task:
Document test results in QA environment
o Fill-out Change Test Results template
Inputs Developed Change
Outputs Change Test Results
Attachments Change Test Results
Step ChgM 190a SOX Approval Executed by: Service Owner Group
Description Provide approval/rejection for PROD rollout.
NOTE: This task is triggered only if SOX flag has been set.
Inputs Tested Change
Outputs Approved/Rejected Change
Attachments N/A
Step ChgM 200a Technical Approval Executed by: Change SME Group
Description Perform technical validation of the change. The following activities to be done as part of this task:
Make sure that all necessary plans (based on the change type) are attached to SNOW
Change Ticket
If required, set Post Rollout Documentation flag (additional task will be triggered after
rollout)
NOTE: Technical Approval is applicable for both minor and major changes
Inputs Tested Change
Outputs Approved/Rejected Change
Attachments All required change plans
Step ChgM 203a SD&A Approval Executed by: SD&A Manager
Description Review & approve the change from business perspective. The following activities to be done as part
of this task:
Validate that Planned Start & End implantation dates (including downtime) are approved
by the business
NOTE: SD&A Approval is applicable for all Major & Minor changes with risk=Critical/
High.
Inputs Tested Change
Outputs Approved/Rejected Change
Attachments All required change plans
Step ChgM 205a CAB/ECAB Approval Executed by: CAB Group
Description Perform CAB approval of the change. The following activities to be done as part of this task:
Make sure that all necessary plans (based on the change type) are attached (contact SME
for that task)
Change to presented & evaluated on CAB meeting
o The result of CAB meeting is the decision whether change is approved/rejected
If required, set Post Rollout Documentation flag (additional task will be triggered after
rollout)
NOTE: CAB/ECAB is only applicable for major changes
Inputs Tested Change
Outputs Approved/Rejected Change
Attachments All required change plans
Step ChgM 210 Change Deployment Executed by: Deployment Manager Group
Description Transfer Changes from DEV/QA to PROD. The following activities to be done as part of this task:
Install Change on PROD system
Attach rollout related documentation (including Implementation plan)
Put Actual Start and End dates based on Change Deployment
Inputs Approved Change
Outputs Deployed Change
Attachments Updated Implementation plan
Step ChgM 220 Finalize Development Executed by: Change Manager Group
Description Perform additional deployment activities that could not be performed during production rollout.
NOTE: This task is triggered only if appropriate/corresponding flag has been set.
Inputs Approved & partially Deployed Change
Outputs Deployed Change in full scope
Attachments N/A
Step ChgM 230a Test in Production Executed by: Requester or Change Coordinator Group
Description Perform test on PROD to verify that implementation change works as expected in production
environment.
Inputs Deployed Change
Outputs Change verified in the PROD system
Attachments Change Test Results
Step ChgM 240 Post Rollout Documentation Executed by: Change Manager Group
Description Post Rollout Documentation to be included into Change Ticket.
NOTE: This task is triggered only if appropriate/ corresponding flag has been set.
Inputs Deployed Change
Outputs Documented Change
Attachments Updated Implementation plan
Step ChgM 250 Post Implementation Review Executed by: Change Coordintor Group
Description Post Implementation Review to be performed.
Post Implementation Review template to be filled in.
NOTE: This task is triggered only if appropriate/corresponding flag has been set.
Inputs Deployed Change
Outputs Post Implementation Review doc
Attachments Post Implementation Review doc
Step ChgM 260 Service Catalogue Record Executed by: Change Coordinator Group
Description Provide all relevant Change data to Service Catalog Management.
NOTE: This task is triggered only if appropriate/corresponding flag has been set. When the flag is
triggered email to CH-SDI@ should be send!
Inputs Deployed Change
Outputs Service Catalogue Record updated
Attachments N/A
Step ChgM 280 Close Change Executed by: Deployment Manager & Change Coordinator Group
Description Once all approvals/tasks are completed, change will go into Pending Closure phase.
BTL Change Manager to select proper closure code and send to ABB for review
OTL Change Coordinator to review closure code proposed by BTL Change Manager
o If review is not performed within 7 days, change is closed automatically with
closure code proposed by BTL Change Manager
OTL Change Coordinator to review (and update if required) Actual Start & End dates
proposed by Deployment Manager during phase 210 Change Deployment
Inputs Deployed Change
Outputs Change record closed
Attachments N/A
mailto:CH-SDI@
Change Management workflows
Below table describes all steps required to process Major Change for PROD implementation path in SNOW.
Table 23 Major Change (implementation path: PROD)
Change Management workflow
Below table describes all steps required to process Minor Change for PROD implementation path in SNOW.
Table 24 Minor Change (implementation path: PROD)
Minor Change Management workflow
Below table describes all steps required to process Minor Operational Change for PROD implementation path
in SNOW.
Table 25 Operational Minor Change (implementation path: PROD)
Change Management workflow
Below table describes all steps required to process Standard Change for PROD implementation path in SNOW.
Table 26 Emergency Change Management
-Initiated Major Change Management workflow
Below table describes all steps required to process Incident-Initiated Major Change for PROD implementation
path in SNOW.
Table 27 Incident-Initiated Major Change (implementation path: PROD)
-Initiated Minor Change Management workflow
Below table describes all steps required to process Incident-Initiated Minor Change for PROD implementation
path in SNOW.
Table 28 Incident-Initiated Minor Change (implementation path: PROD)
3. Reporting (KPIs + SLAs)
KPI
No.
KPI Name Description Purpose
1. % of changes not
implemented on time.
Changes that should have been
implemented but are still outstanding or
Changes that have taken more than
scheduled duration.
To assess the process efficiency.
2. % of emergency
changes.
Percentage of opened, emergency
changes relative to the total number of
changes opened in a given time period.
To assess the instability to
operations due to emergency
changes.
3. Average change
closure duration for
each class of change.
Average amount of time (. in days)
between the registration of changes and
their closure.
To measure the operations
efficiency.
4. % of changes rejected
by CAB.
Percentage of changes rejected by CAB
relative to the total number of changes
that were reviewed by the CAB.
To identify the process weakness
in terms of people not providing
complete and correct details while
submitting the Change.
5. % of unauthorized
changes.
Percentage of changes that did not follow
the process.
To assess the process efficiency.
Table 29 KPIs for Change Management
SLA
No.
SLA Name Description Measurement Methodology
1. Failed Change ratio The change was not
implemented as it was planned
out to be: any unintended
consequences, of any kind, are
defined to be failure here
counted for.
Valid Population (Y026): Total number of
closed change tickets built and/or tested
and/or deployed by Supplier in a specific
region in the Measurement Window
Failure Condition (X026): Tickets closed
with a failure closure code.
2. Ratio of Changes
causing Incident(s)
A failed change does not have
to lead to incidents, but if so
these are here counted for.
Valid Population (Y028): Total number of
closed change tickets built and/or tested
and/or deployed by Supplier in a specific
region in the Measurement Window
Failure Condition (X028):
Closed change tickets which resulted in one
or more Incidents opened.
Table 30Contractual SLAs for Change Management
NOTE: SLA information have been copied from contract files.
4. Tower Specifics
EUC
EUC Tower to fill-in additional details relevant only for this tower.
EUS
EUS Tower to fill-in additional details relevant only for this tower.
Core Software Platform (CSP)
CSP Tower to fill-in additional details relevant only for this tower.
Network
Network Tower to fill-in additional details relevant only for this tower.
5. Stakeholders
Change Management stakeholders list can be found here.
6. Templates
Change templates are complementing and supporting the Change Management process.
All templates provided for the Change Management process are owned by the IS RUN organization and as
such may be modified as required by operational practice. Please always refer to IS RUN for the latest signed
off Change Management Templates.
RFC Template
Change Management RFC - TEMPLATE
Functional Specification
Change Management Functional Specification - TEMPLATE
Change Test Results
Change Management Test Results - TEMPLATE
Implementation plan
Change Management Change Plans - TEMPLATE
Backup Plan
Change Management Change Plans - TEMPLATE
Point of No return details
Change Management Change Plans - TEMPLATE
Communication Plan
Change Management Change Plans - TEMPLATE
Backout plan
Change Management Change Plans - TEMPLATE
CAB Readiness Checklist
Change Management Change Plans - TEMPLATE
Agenda & Minutes
Change Management CAB Agenda & Minutes - TEMPLATE
Verification Plan
Change Management Test Results - TEMPLATE
NOTE: The CM Test Results template to be used for Deployment Verification.
Implementation Review
Change Management Post Implementation Review - TEMPLATE
CAB meetings
Weekly CAB meetings
7. Vocabulary
Term Definition
Backout Recovery to a known state after a failed Change. Synonym to Remediation.
Backout Plans Plans for performing remediation (such as, how to backout of a Change if it does
not install or work properly).
Change The addition, modification or removal of anything that could have an effect on IT
services. The scope may include IT services, Configuration Items, processes,
documentation and so forth.
Change Advisory
Board (CAB)
A group of people that support the assessment, prioritization, authorization and
scheduling of changes. A change advisory board is usually made up of
representatives from: all areas within the IT service provider; the business; and
third parties such as Service Providers.
The CAB is closely related to the Emergency Change Advisory Board (ECAB).
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.
Configuration
Item (CI)
A Component that needs to be managed in order to deliver an IT Service.
Information about each CI is recorded in a configuration record within the
Configuration Management database and is maintained throughout its lifecycle by
Configuration Management. CIs are under the control of Change Management.
CIs typically include IT services, hardware, software, buildings, people and
formal documentation such as process documentation and SLAs.
Deployment The activity responsible for the movement of new or changed hardware, software,
documentation, process and so forth to the live environment.
Emergency
Change Advisory
Board (ECAB)
A subset of the Change Advisory Board that makes decisions about high-impact
emergency Changes. Membership of the ECAB may be decided at the time a
meeting is called and depends on the nature of the emergency Change.
Failure Loss of ability to operate to specification, or to deliver the required output. The
term failure may be used when referring to IT services, processes, activiti
