Training of Change Management Process Phase II V02

CHANGE MANAGEMENT PROCESS
USER TRAINING
PHASE II EFFECTIVE 1ST AUGUST ‘14
NOC-Change Management Unit

SUMMARY KEY CHANGES
• Definition of Change Management as per high-level design (as per ITIL best
practice)
• Clearly defined integration points between Projects, Releases and Changes
• Clearly defined roles & responsibilities for Change Management across
multiple teams
• KPI reporting as per Asia Harmony
• Updated Approval Matrix
• Renewed Risk/Impact Questionnaire
• Overall Change Calendar
• Establish CAB (Change Advisory Board)
• Integration of Change Management with Incident Management and Release &
Deployment Management
2
THE ROLES OF THE PROCESS CAN BE DIVIDED IN THREE LEVELS
Executive Sponsor
Provides oversight for the Process
Strategic (CTO)
Change Management Ensures the process is rolled out and used within
the whole IT organization. Accountable for
Tactical Process Owner improvements
Approving deployment of changes based on

Change Authority
recommendations
Ensure that Change management process is

Change Manager effective, efficient, and followed
Change Owner Responsible for delivery of the Change

Operational
Responsible to conduct successful change activities
Change Coordinator within specific service group
Reviewing, assessing and evaluating the request for

Change Reviewer change
Change Requester Starting the Change Process by documenting the

proposal and/or the request for change
3 3
THE ROLES OF THE PROCESS CAN BE DIVIDED IN THREE LEVELS
Executive Sponsor CTO

Strategic
Change Management
Head of Change Management Unit
Tactical Process Owner
Change Authority Line Management & CAB

(refer to Approval Matrix)
Change Manager Head of Change Management Unit
Change Owner [TG Employee]

Operational
Team Leaders
Change Coordinator
Change Reviewer [TG Employee]
Change Requester [TG Employee]
4 4
CHANGE MANAGEMENT PROCESS OVERVIEW 5
The purpose of the Change Management process is to control the lifecycle of all IT changes,
enabling beneficial changes to be made with minimum disruption to IT services.
And so the Change Management process is limited to controlling the Changes not in delivery of
Changes
Change Build & Change

Change
Change Logging & Test Approval Deployment Change Review
Assessment &
Validation and Approval & & Closure
Planning
Coordination Coordination
The change is Assess potential Obtain the approval & Evaluate the design, Carry out a review to
recorded and initially impact on all services. coordinate the build build and test of the ensure actual
validated Planning of changes & test of the Change change. Obtain performance of the
deployment approval Change
Initial approval steps performed by different authorities:

• Prioritization Process (Projects)
• IT Service Owners (Service Requests) Led by Change Managers
• Platform Owners (Operational-related Changes)
5
SCOPE OF CHANGE MANAGEMENT IN DTAC 4
Change Category
Portfolio Management Change Severity

Emergency Change
Project Critical Change
Project Lite
*Service Request
Major Change
Normal Change
Change Minor Change

Management
Standard Change
• Service/Application/System Changes
• Service Improvement Plans
• Resolution of Problems/ Incidents
(Corrective Maintenance)
• Standard Changes
• Operational Improvements
• Preventive Maintenance
6
CHANGE CATEGORIES & SEVERITY 5
Change Category Change Severity/ Priority
Emergency Change Calculated based on Risk & Impact of

introducing this Change into the
A change that must be production environment.
introduced ASAP. Typically
Risk Impact Severity Approvers
to resolve a major incident. Critical Change
High High
Medium High Critical
Low High
Normal Change Major Change
High Medium Refer to
Medium Medium Major Approval
Addition, modification or Low Medium
Minor Change Matrix
removal of anything that High Low
could have an effect on IT Medium Low Minor
services. Low Low
Standard Change
Pre-authorized change that is
low risk, relatively common and
follows a known procedure or
work instruction.
7
CHANGE ADVISORY BOARD (CAB) MEMBERS 7
LIST OF MEMBERS FOR EACH TYPE OF CHANGE ADVISORY BOARD (CAB)
8
APPLICABLE MATRIX 8
4. Change
2. Change 3. Change Build 5. Change
1. Change Logging & Deployment
Assessment & & Test Approval Review &
Validation Approval &
Planning and Coordination Closure
Coordination
Project /Software
/Hardware Update or
Upgrade
Core Network
Transport/IP Network
BSC/RNC
BTS/Node B
Field Work and Facility
Standard Change
Preventive Maintenance*
Incident Management
Process
Risk & Impact Confirm “Test Result” Confirm “Test Result” in

Questionnaire before Deploy phase Deploy phase
Note
• No Installation/Uninstallation of any Software ( including Patch ) Or
• No Hardware upgrade /downgrade
9
New Change Process Flow 10
Review
Logging Plan Build & Test Deploy &Closed
- Change Title Preparation

- Related build Tasks - Deploy actual start -End - Updated Implement
- Required Reference ID (SPPM IM, PM)
- Build & test actual start –End - Test result/UAT - Related deploy Tasks result
- Change Requester , Owner
- Expect Deploy duration date - Confirmation test - Back out/Fallback Plan
- Objective and Reason of Change
- Cost’s estimated - Verify deploy date
- Change description
- Training and Communication - Configuration
- Change Category (assessment)
- LLD of change /Deployment Doc - PIR
- Attached R&I questionnaire
- Services Impact -CAB Comment - Description of Risk - Defect ?
- Target Plan ,Build&Test ,Deploy - Worst case scenario -CAB Comment
Reject
Reject
CO-DEPT CO CO
CO CO-DH CM CO CO-DH CM CO CM
CR CO & DIV Build Update
prepare Approve CAB prepare Approve CAB Deploy Close
Critical Logging Verify Approve Build Test result
Deploy
Design
(2.2) (3.2) (4.2)
*Release Trigger
Normal
CO-Unit
Major CO-UH CM CO CO-UH CO
CR CO & DEPT CO CO CM CO CM
Approve CAB Build Approve Update
Logging Verify Approve prepare prepare CAB Deploy Close
Build Test Deploy result
Design
CO-TL CO-TL CO CO-TL CO

CR CO CO CO CO CM
Minor Approve Approve Build prepare Approve Update
Logging Verify prepare Deploy Close
Design Build Test Deploy result
CO-UH CO
CR CO Approve CO CM
incident Update
Emergency
Logging Verify Deploy Deploy Close

result
CO-UH CO CM CO
CR CO CO CO CM
Project Approve Build E-CAB Update Close
Logging Verify Prepare Deploy
Design Test result
incident CO
CO CO CM
Standard
CR Update
Logging Verify Deploy Close
result
CO
CR CO
Verify CO CM
Logging Update Close
Project /Check Deploy result
10 CR = Change Requester | CO = Change Owner | CM = Change Management Unit

conflict
APPROVAL MATRIX
Refer to Approval Matrix file. Completed Completed
within Wed within Wed
Normal Change for CAB on for CAB on
Friday Friday
Assessment & Planning Build & Test Deployment
Risk level
Level 1 Level 2 Level 1 Level 2 Level 1 Level 2
Div. Head
Critical Dept. Head or Dept. Head CAB (B) Dept. Head CAB (D)
No*
Major Unit Head Dept. Head Unit Head CAB (B) Unit Head CAB (D)
Team Lead Team Leader Team Leader

Team Team Team
Minor or No or No or No
Lead Lead Lead
AD AD / AO AO
* Not require for department that direct report to CTO (without Division Head)
Emergency Change
Change type
Level 1 Level 2 Level 1 Level 2 Level 1 Level 2
Unit Head
Emergency (Incident) No No No No No
(2nd Tier)
Emergency (Project) No Unit Head

Dept. Head No No No E-CAB
Standard Change
Change type
Pre-registration Level 1 Level 2 Level 1 Level 2 Level 1 Level 2
required Standard
- Incident No No No No No No*
- Non incident
11
CHANGE MANAGEMENT PROCESS 10
Logging Plan Build & Test Deploy Review &Closed
( SM7 & Email ) ( Email ) (Email ) ( SM7) ( SM7)
Responsible Action on
Description
by Email SM7
Complete Risk & Impact Change Complete “Risk & Impact Questionnaire“
Questionnaire Requester
To get Change ID Change Open and Save to RFC

Requester
Change request information Change Complete email template for plan Logging change Information
Requester Submit to Change Owner
Perform assessment change request Change Owner • Verify and updated change request • Verify and updated change request
base on • Submit email to change’s approval base on • Submit to change’s approval
• Change Request Information approval matrix
Completeness
• The parties involved for the
execution of the change
• Risk and Impact of Change
including financial consequence
, Business service impact,
regulatory and security impact.
Change’s Approval for Plan base on Change Owner’s Approve or reject the Change Request Approve or reject the Change Request
change request’s information Approval If approved , automatic next phase to “ RFC Build &
test prepare”
Inform Change Managment Change Owner Submit email to Change Management Team -
Preparation for “Build & test “ Change Owner Start preparation for “Build & test “ Start preparation for “Build & test “
phase Change Owner can assign to new Change Owner Change Owner can assign to new Change Owner (if
(if need…) need…)
12
Description
by Email SM7
Preparation for build and test Change Owner Complete email template • Fill-in to Complete change for build & test
Low level design or build & test scope document information
Submit email to change Owner ’s approval base • Attached “Low Level Design” (Or build and test
on approval matrix scope document
• Next phase to submit change’s approval
Perform assessment overall of Change Owner ’s Approve or reject the Change Request • Click Approve or Reject RFC
change request base on Approval **After approve , automatic next phase according
• Build & test and Deployment to workflow eg. “RFC build&test CAB review”
scope and timeline
• Risk& impact
• cost estimate
Inform Change Management Team Change Owner Submit email to Change Management Team -
• CAB approval , if required Change • Arrange CAB for approval. • If required CAB approval , will arrange CAB for
• Inform Change Owner to start Management • Inform Change Owner to start “Build &Test” approval., then updated CAB’s MOM and next
“Build &Test” Activity Team Activity after CAB approval Phase
• For non CAB RFC , it will automatic next phase
to “Build &Test phase”
• Complete Build and Test activity Change Owner • Complete Build and Test activity • Complete Build and Test activity
• Submit “Testing Result or UAT or • Submit “Testing Result/OAT/UAT” email to • Attached file Testing Result or UAT or OAT
OAT ” as evident for Change Management Team • Click next phase to “ RFC Deploy prepare”
Completeness phase.
Preparation for “Deploy “ phase Change Owner Start preparation for “Deploy“ Start preparation for “Deploy“
Change Owner can assign to new Change Owner Change Owner can assign to new Change Owner (if
(if need…) need…)
-
13
Description
by Email SM7
Complete Deployment preparation Change Owner - • Fill-in to complete Deployment preparation’s
‘s information for approval Information
• Next phase to submit change Owner’s approval
Perform assessment of the change Change’s Owner - Click “Approve” or “Reject RFC”
request for Deployment Approval After approve , automatic next phase according to
• Approve or reject the change workflow eg. “RFC Deploy CAB review”
request
If required CAB approval , will Change - If required CAB approval , will arrange CAB for
arrange CAB meeting for Deploy Management approval., then updated CAB’s MOM and next
then updated CAB MOM Change Team Phase
Owner For non CAB RFC , it will automatic next phase to
“Deploy Implementation phase”
• Start “Deploy” activity Change Owner - Update “Implementation Result”
• Update “Implementation Result”
Verify with Change Owner and Change - • Post Implementation Review (PIR)“
updated “Post Implementation Management • Updated RFC Defect (if need)
Review (PIR)“ Team • Close RFC
Closed RFC
14
Sample : Email template
I. Change Information:
Change ID: : <Requester’s Ticket >
Category : <..Change Category..>
Title : <Change title>
Project ID : <Required Project ID reference, If need>
Scope of Change and related work : <Scope of change>
Description of change : <Description of change >
Build & Test Target Start : <required date time>
Build & Test Target End : <required date time>
Deployment Target start : <required date time >
Deployment Target End : <required date time >
Estimate Cost (Thai Bath) : <Cost estimate for build test and deployment >
II. Change Requester and Owner information
Requester's Name : <Requester’s name>

Requester's Team : <Requester’s Team>
Requester's Unit : <Requester’s Unit>
Requester’s Department : <Requester’s Department>
Change Owner Name : <Owner’s name>
Change Owner's Team : <Owner’s Team>
Change Owner's Unit : <Owner’s Unit>
Change Owner's Department : <Owner’s Department>
Internal Approval Name : < Approval Name1 >
: < Approval Name2 ,if need >
15
Sample : Email template
Project ID : <Required Project ID reference, If need>
Description of Change <required Description>
Build & Test Plan Start : <required date time>
Build & Test Plan End : <required date time>
Deployment Plan start : <required date time >
Deployment Plan End : <required date time >
Training and Communication Plan : <Required date time>
Estimate Cost (Thai Bath) : <Cost estimate for build test and deployment >

Requester's Unit : <Requester’s Unit>
Requester’s Department : <Requester’s Department>
16
ASIA HARMONY: CHANGE MANAGEMENT PROCESS
Process KPI
CSFS, KPIS
CSFs KPIs
A. A repeatable 1. % rejected RFCs
process for changes 2. % unauthorised changes
3. % time to make changes
B. Quick and accurate 1. % emergency changes
changes 2. % emergency changes causing incidents
3. % changes requiring back out
C. Protect Service 1. service outages caused by changes
2. % changes activated outside core time
3. % changes causing Incidents
D. Show efficiency and 1. % efficiency improvement based on number of RFCs processed
effectiveness results 2. % accuracy of change estimates
3. cost of failed changes
4. % changes implemented on time
5. % cost of handling a change
18
Q&A
Change Management
(User Training)
TRAINING OBJECTIVES
 Create common understanding of the newly designed Change Management

process
 Familiarization with the language and terminology being used
 Ask questions for clarification
 Confirmation of your understanding
 Understanding of your role and how it will be impacted
21
Introduction to Asia Harmony

TO REALISE FUTURE GROWTH, WE MUST IMPROVE THE WAY WE WORK BY
ENSURING DEEPER BUSINESS AND CUSTOMER FOCUS, AND STRONGER
COHESION THROUGHOUT THE ORGANISATION
• Create stronger cohesion to significantly improve go to

market readiness and customer responsiveness
• Ensure focus and agility to drive organisational
excellence
• Establish clear roles and responsibilities to enable
effective collaboration across divisions
23
WHAT IS ASIA HARMONY
• Enable High Performance

• Increased AD Efficiency
WHY • Reduced AM turnaround
• Increased transparency
• Prepare for Asian industrialization
• Learning and collaboration cross BU
• Implementation of key IT processes

• Service Catalogue
WHAT
• Roles and decision rights
• Formalized and standardized forums
• Standardized measurements
• BU involvement at all levels and management

buy-in and commitment
• Realistic scope and timeline
HOW • Focus on implementation
• Best practice and knowledge sharing cross BU
• Consultancy support
24
Scope and benefits of ASIA Harmony
Service strategy • Implement the right project at

Service Portfolio the right time
Prioritization Process Management • Reduce TTM
• Control TCO
Service Design
Service Level • Control TCO
Management • Manage service expectations
Service Transition • Control of different

Change Release&Deployment
environments & services
Management Management • Reduce TTM
• Reduce # of incidents
Service Operation • Reduce # of repeat incidents

• Increase availability of services
Incident Management Problem Management
• Reduce MTTR
25
HIGH LEVEL OVERVIEW OF ACTIVITIES PER PROCESS
• Build common process competence

within project team
• Low Level Design (5-6 Weeks)
– Workshops to adjust low level design
– Design governance and roles
– KPI Design and implementation
• Implementation (2-4 Weeks)
– Training and guidance
– Tool adjustments
– Measurement and validation
– Set up governance
• Early Life Support (4 Weeks)
– Measure and improve
– Retrain if necessary
26
OVERALL PROJECT APPROACH
Cross BU
Deployment
Validation High Level Low Level Implementation
& ELS (Early
Assessment Design Design Planning
Life Support)
L1 & L2 L3 & L4
May ‘13 July ‘13 Feb – May May – June
DTAC Change Management
We’re
here
today
27
SUMMARY KEY CHANGES
• Definition of Change Management as per high-level design (as per ITIL best
practice)
• Clearly defined integration points between Projects, Releases and Changes
• Clearly defined roles & responsibilities for Change Management across
multiple teams
• KPI reporting as per Asia Harmony
• Updated Approval Matrix
• Renewed Risk/Impact Questionnaire
• Overall Change Calendar
• Establish CAB (Change Advisory Board)
• Integration of Change Management and Incident Management
• Readiness for future integration with Release & Deployment Management
28
Process Purpose
CHANGE MANAGEMENT PURPOSE
• Change:
– the addition, modification or removal of anything that could have an
effect on services
• Purpose:
– the purpose of the Change Management process is to control the
lifecycle of all changes, enabling beneficial changes to be made with
minimum disruption to services
30
HIGH-LEVEL OVERVIEW
– AS PER HIGH LEVEL DESIGN
Project Management
Effect
Realization
3-6 month
Go G1 D0 D1 D2 D3 D4 D5 Ro Product
Retirement
Idea Roadmap Roadmap

Capturing Creation Validation Initiation Analysis Execution Launch Close-Out Monitoring Screen-Out
Service Portfolio & Prioritization Mgmt SPPM
Service Level Management SLM
Change Management
Release & Deployment Management
CAB Close
Chartered
Service & Project Approval Change
Portfolio
Service Catalogue
Design, Build & Test Activities Deployment Approval, Tracking &
managed within project (PPM) Monitoring tracked within SM7
31
WHAT THAT MEANS…
Projects Change
Objective Initiates and Manages the Provides approval

manages projects Design, Build and for deployment of
Test activities Changes
“ID” Project ID (PID) Change Record (TBA)
Tool PPM SM7
• Provides PID • Release Team maps PID • Change Requester

to Release to Release ID (as raises an RFC in SM7
Team design, build & test and indicates the
progresses) corresponding
Release ID
32
IN SCOPE
– Solutions for new or changed to services (including the functional

requirements, resources and capabilities needed and agreed upon)
– Management Information Systems and tools needed for the management
and control of services
– Technology and Management architectures required to provide the services
– All configuration items supporting prod environments, whether these are
physical or virtual, e.g. (virtual) servers, networks, applications, (virtual)
storage, agreements, contracts
– Building and testing of change; handling business requests is not in scope of
current Change Management process implementation
33
CHANGE MANAGEMENT PROCESS OWNER
Responsibilities Skills / Mandate

• Is accountable for the overall quality of the process  Strategic orientation, managing vision and
and oversees the management of and compliance purpose and global mind-set
with the processes, procedures, data models,
policies, and technologies associated with the IT  Ability to build enduring partnerships and
business process. teamwork across multiple areas of the company
• Is responsible for ensuring that a process is fit for and with external constituents
purpose and for ensuring that all activities within  Developing organizational capabilities
the process are performed.
• Is also responsible for the sponsorship, overall  Steadfastly pushes self and others for results
mission, design, and Change Management of the  Strong influencing and communications skills
process and its metrics.
 Commitment to Continuous Improvement
• Communicating the process mission, goals and
objectives to all stakeholders  10-15 years of change management related
• Resolving any cross-functional (departmental) experience
issues  General management experience
• Reporting on the effectiveness of the process to
senior management
• Initiates process review and any improvement
activities
34
CHANGE MANAGER

• Ensures that the Change Management process is followed • Leadership skills
and adhered too within timeframes
• Ensures that Change Management information is • Decision making skills and proficient in problem
communicated to all stakeholders solving
• Develops, implements and reviews existing Change
Management Strategy and Policies • Analytical skills
• Monitors the Critical Success Factors (CSF) and the Key • Stakeholder management
Performance Indicators (KPI) ensuring that performance
targets are met • Ability to effectively ‘bridge’ the gap between
• Analyzes the process to identify bottlenecks and business and IT
opportunities for improvement
• Produces the reports about the process Key Performance • Excellent planning skills
Indicators (KPI) • Ability to negotiate with internal suppliers and
• Facilitating and Chairing (Emergency) Change Advisory Board vendors
meetings
• Maintaining communication with Approval Bodies, Project – Experienced in ITIL.
Management Office and Release Management
– Ability to improve the process and its related
• Maintaining the Change Schedule and the Projected Service
Outages reports supporting tools
• Monitoring change build, test, plans and schedules
• Verifying the Post Implementation Review and closure of
changes
35
CHANGE OWNER

• Responsible for the delivery of the Change i.e. • Managerial skills
that the change meets requirements and the • Experienced in project management
planning • Analytical skills
• Coordinating the Change plans and schedules • Stakeholder management
• Maintaining communication with the Change • Ability to negotiate with internal and external
Manager individuals
• Ensuring that the change meets the – Experienced in ITIL Change Management
requirements
– Knowledge of IT infrastructure management
• Reporting status and presenting findings to the
Change Advisory Board – Ability to identify needed improvements to the
process and its related supporting tools
• Preparing, assisting in and documenting the
Post Implementation Review
• Note: change owner can also be the project
manager
36
CHANGE COORDINATOR

• This role is the "point person" within a Support – Experienced in ITIL Change Management.
Group that is responsible for all changes – Ability to manage the requirements, the designing,
assigned to their group building and testing changes including all
• Responsible for assigning them to the documentation
appropriate individuals within the Support • Knowledge of IT infrastructure management
Group and monitoring the status and progress • Stakeholder management
towards executing the specific assigned
activities – Experienced in system development
• Responsible for verifying that activities have
been successfully completed
37
CHANGE REVIEWER

• Reviewing, assessing and evaluating the change • Thorough knowledge of the field which is
proposal assessed / evaluated e.g. applications, networks,
• Deciding on support of the proposal storage
• Taking responsibility of made decisions
38
CHANGE AUTHORITY
Responsibilities
• Approving the Deployment of Changes based on recommendations from Change Reviewers
• Approving of standardized changes
39
CHANGE REQUESTER
Responsibilities
• Starting the Change Process by documenting the proposal and/or change request ticket
• Providing additional information, if necessary
• Maintaining communication with the Change Owner
• Closing change tickets and proposing specific changes to be included on the Standard Change List
40
Process Activities
1.0 LOGGING
CHMA 1.0 Change Logging & Validation
Technology Categorize the change

Requester
Service Release & Change Request

Service Level Web Portal
Priority &
Portfolio Mgt
Incident Mgt Problem Mgt Deployment
Mgt
Management (Scope, Type, Item)
and prioritize the
The Change Record is validated to change.
ensure that it is a valid Change
CHMA
(scope, verified requester, …). Standard
Change
2.5
CHMA 1.1 CHMA 1.2 CHMA 1.3 CHMA 1.5
Record Initial Determine Change Categorize & CHMA

Validate RFC 2.1
Change Information Type Prioritize
Status: Status:
Change Owner
Submitted Definitions & Standrad Category List & Priority Classified

List required data
Change List matrix
Emergency Change
Invalid
RFC
CHMA
6.1
CHMA 1.4
Initial Change Corrected

Determine if the Inform Requester CHMA
record is
RFC
Change is Cancelled/Rejected
RFC
5.2
created from Standard, Normal

or Emergency. If needed, inform the
information
Requester to provide
received or
more information.
submitted.
Otherwise, cancel the
42
42 RFC if it is invalid.
CHANGE LOGGING DATA
Key Change Logging Fields

• Unique reference number
• Date/time recorded
• Name/department/phone/location of Requester
• Name/department/phone/location of change initiator
• Requester Group
• Change Owner
• Change Owner Group
• Service the Request for Change relates to
• Summary of the Request for Change
• Change Type
• Target Date
• Status
• Source of the Channel
• Attachment: Risk & Impact Questionnaire and/or UAT/OAT documents
• Related Project unique reference number (if applicable)
• Related Incident unique reference number (if applicable)
• Related Problem unique reference number (if applicable)
* For future consideration by DiGi

43
43
2.0 CHANGE ASSESSMENT & PLANNING
CHMA 2.0 Change Assessment & Planning
To consider
whether it is CHMA
1.5
Change Owner
worthwhile to Standard Change
CHMA 2.1
CHMA
accept the risks, CHMA 2.5
CHMA
1.5 Assess Change Plan Change
Risk Questionnaire
before start of the CHMA
5.2 Status:
3.1
Change Calendar Planned
design of the RfC.

Change Approver
CHMA 2.2
Assess the Authorize Change

Create a more precise schedule based
Not authorized
Risk & Impact on the target date, the risk level and the
of the Low Level Design of the Change, as well
Change. as the resources available, the build, test
Change Coordinator
Authorized CHMA 2.3

and deployment of the Change.
Monitoring Design
Monitoring the creation a

Corrective
actions breakdown of the Change into
Work Orders required to build
Change Reviewer
CHMA CHMA 2.4

3.2
Approve Low Level
Design and deploy the Change.
RDM process
produce the
Design of the Assure that no information is
Change and the missing or that there isn’t a
Inter Process
Release &
related
Deployment
Mgt lack of clarity.
Deployment Plan.
44
3.0 CHANGE BUILD & TEST APPROVAL & COORDINATION
CHMA 3.0 Change Build and Test Approval & Coordination
CHMA
Initiate activities to build theCorrective 4.2
Coordinate tests and require
change and involve RDM. Actions
the UAT sign-off.
Change Owner
CHMA 3.1 CHMA 3,3 CHMA 3.4

Standard
CHMA Change CHMA
Determine Change
2.5 Build Coordination Test Coordination 4.1
Authorization Status:
Build in
Authorization matrix Progress
Depending on the nature Review the Change Record

Approved
Change
of the Change, identify the CHMA 3.2 and its underlying documents
appropriate stakeholders on each relevant area to
Change Approver
Authorize Change
required to approve the proceed with the

Build & Test activities. Authorization.
Corrective Change
Actions Cancelled
RDM process
CHMA CHMA
2.3 5.2 proceeds to Build &
Test the Change.
Inter processes
Release &
Deployment
Mgt
45
4.0 CHANGE DEPLOYMENT APPROVAL & COORDINATION
CHMA 4.0 Change Deployment Approval & Coordination
CHMA 4.1 CHMA 4.3

Change Owner
CHMA CHMA CHMA

Schedule Change Coordinate Change
3.4 5.1 5.1
Deployment Deployment
Status:
Change Calendar Status: Completed
Scheduled
Update the Change

Schedule with the target Deployment
Coordinate and monitor the deployment
implementation date.
CHMA 4.2 approved to ensure that the Change is carried out
Approve Change within schedule and meets its objectives.
Change Approver
Deployment
Rescheduling
required
Approval Matrix
Corrective
The CAB is convened to Actions Change
Cancelled
provide final approval of RDM process
the Change. CHMA
3.3
CHMA
5.2
proceeds to deploy
Amendments, if any, are the Change.
routed back to RDM
Inter Process
process to address. Release &

Deployment
Mgt
46
RISK ASSESSMENT
Refer to the Risk/Impact Questionnaire file.
RfC Risk and Impact Questionnaire - V1.0

Risk Score 0 0 0
Major Major Critical

RfC No.: High
Minor Major Major

Requestor Name: Medium
Minor Minor Major

Department/Division: Low Impact score
Low Medium High

RfC Submission Date:
Risk/Impact Assessor:
Instructions.
Pl ease, fi l l the two bel ow tabl es wi th the i nformati on rel ated to the rati ng (both Ri sk Score and Impact score), the
descri pri on of the mi ti gati on acti on and the rel ated mi ti gati on effecti veness (Ri sk Score onl y), to automati cal l y
defi ne the Change Severi ty.
1 0.00 0
Risk of Failure
Relative Risk Rating Criteria Mitigation Action Mitigation Eff
Rating
Weight Low Risk (1) Medium Risk (2) High Risk (3) Description None (0) Weak (1)
Change Deployment
Between 30min and 2h Not available or >2h to
Rollback plan 10% <30min to rollback the change
to rollback the change rollback the change
In the event of a failure in implementing the change, can services be restored Max a small excess is
10% Yes No or Not Sure
within the allotted change window? forseen
Rollout approach 10% Pilot or single work group Partial Full
Delivery Schedule 10% Flexible Moderate Compressed

How easy is for the implementer to verify that the change was completed
10% Easy Medium Complex
successfully?
Change Complexity
What is the estimate duration time of the change implemetation ? 10% < 6 months 6months - 1 year > 1 year
How many integrated systems are involved or impacted? 10% 1-2 3-4 >=5
Technological solution 10% Existing New in this company New in the industry
Involved Parties
How many product vendors are involved? 10% 0 to 2 3 to 4 > =5
Extensive experience with Some experience with Minimal or no experience with
Implementer experience 10%
similar implementation similar implementation similar implementation
Impact of Failure
Relative Rating Criteria
Note: the following questions relates to the situation for which the RfC has to Rating Relative Impact Score
Weight Low Impact (1) Medium Impact (2) High Impact (3)
be re-deployed in case of failure.
Cost Impact - What would be the cost of re-deploying the change? 30% < 200K THB 200K -500K THB >500K THB 0.00
Customer impact - What would the total number of end-users dissatisfied? 35% <10% 10% to 25% >25% 0.00
Brand impact - What would be the impact on the company's reputation? 35% None - Low Some High - Very High 0.00
Total Impact Score 0.00
T G Change Management Risk Quest ionnaire V1.0

Regulations and information as provided herein shall be deemed as property of Total Access Communication Public Company Limited.
Modification, publication and any other means without permission from the Company are prohibited.
47
5.0 CHANGE REVIEW & CLOSURE
CHMA
Check5.0 Change the
whether Review & Closure
implementation is
undertaken according
CHMA CHMA CHMA CHMA
to the deployment 4.3 Ensures1.4that all
2.2information
3.2 isCHMA
4.2 When the Change Requester is
plan. captured in the Change Record fully satisfied with the
Corrective and check the quality of the data. implementation of the Change the
Actions
CHMA
Required
Change Record can be closed.
Status:
Change Owner
4.3
CHMA 5.1 CHMA 5.2 CHMA 5.3 Closed
Update Change End

Review Deployment Close Change
Record
CHMA
CHMA 5.4
6.4
Changes Post-implementation
tagged for PIR review
Provide the Deployment

Results and other Release Examine how the Change was
Inter processes
Information to Change handled throughout its entire

Release &
Deployment
Mgmt for necessary lifecycle to capture improvement
Mgt
updates and follow-up. opportunities and lessons learned.
48
6.0 that
Validate EMERGENCY
the Change isCan
HANGE HANDLING
Emergency Change and needs to be
implemented in an expedited
CHMA 6.0 Emergency Change Handling
manner.
Note: Emergency Change must be

introduced ASAP, usually to fix a major
Change Manager
incident. CHMA 6.1
CHMA Confirm Emergency

1.2 Change
Convene the (E)CAB to provide approval
of the Change.
Change Authority
Note: (E)CAB can consist of Tech Leads,

(Emergency)
No CHMA 6.2 Change Manager and other key stakeholders

Approve
Emergency
as required.
Change?
Yes
Change Owner
CHMA 6.3 CHMA 6.4

Identify & Assign
Emergency
Monitor
Implementation
Work closely with RDM
CHMA
5.1
Resources
process to ensure the
RDM process Emergency Change is
Ensure the right people proceeds to deploy implemented as required.
Management
Deployment
the Change.
Release &
are identified and Release & Note: Upon successful

deployed to analyze Deployment Mgt
implementation, proceed to
and implement the review and close (CHMA 5.0)
Change.
49
Process Interfaces
PROCESS INTERFACES
Change Management receives output from other Processes Change Management deliver inputs to other Processes
Process Receive from Reasons Inputs to Reasons
Incident 1. Incidents that triggered RFC Change management helps to reduce 1. Notification of Changes 1.This helps the Incident Management
Management 2. Incidents that triggered Emergency RFC business impact while resolving incident 2. Forward Schedule of Change Team to plan their support resources
that requires configuration/changes within
the production environment.
Problem 1. RFC Problem management will trigger RFC 1. Problem Record Know Errors, problem records and new
Management before deploying any workaround solution/ 2. Known Errors RFC can be triggered during/after any
permanent solution as a mean to reduce Change Management discussion and
business impact review meetings
Release and 1. Release Records 1. If release planning is done earlier, similar 1. Approved RFCs This ensures that changes are properly
Deployment 2. RFC updates RFCs can be bundled as a release package, 2. Closed RFCs reviewed and tested before release and
Management 3. Bundled RFCs which reduces the approval time during deployment to increase change success
CAB review meeting rate
2. Release management provides release
progress updates to Change management
to ease Change Coordination activity
Service Level NA NA NA NA
Management
Service and Project 1. RFC This ensures changes are properly 1. RFC Changes that exceeds their threshold in
Portfolio evaluated for risks, resources, cost, which terms of cost are forwarded to the Service
Management reduce the risks and impact to business & Project Portfolio Management
while launching new services or projects.
51
Standard Change Registration

STANDARD CHANGE REGISTRATION STEPS
•Complete “Standard Change Registration Form”

•Complete “Risk & Impact Questionnaire”
Requester •Submit all documents to Unit Head for Internal approval
•Perform assessment of the request based on...

•Correct and Completeness
•Low Risk & Low Impact
Requester’s Unit •No service disturbance (except Standard for Incident)
Head •Approve or Reject the request
•Perform assessment of the request (based on match criteria to Standard Change definition)
Change •Approve or Reject the request
Management
Process Owner
•Update the “Standard Change List” document

Change •Publish the latest update
Management
Team
STANDARD CHANGE REGISTRATION FORM
Requester’s Information Technical Support Information

Name <Requester’s name> Implementation Procedure
Team <Requester’s Team>
<Describe implementation steps>
Unit <Requester’s Unit>
Department <Requester’s Department> Fall Back Plan
Email Address <Requester’s email address> <Describe fall back plan>
Phone Number <Requester’s phone number> Post Implementation Verification (Service
Approver Name <Requester’s Unit Head name> Verification)
<Describe post implementation verification
Effected Service
methodology>
Service Name Service Class Service Disturbance
Additional Information
<Service Name 1> <Gold > <Describe service disturbance> N/A
<Service Name 2> <Gold> <Describe service disturbance>
Change Information
Title <Change Title>
Change Description <Description of Change activities>
Purpose <Objective of this Change activity>
Estimate Change Implementation <1 Hour 30 minutes>
Time
Process Policies
CHANGE MANAGEMENT POLICIES (1 OF 10)
• The Change Manager is accountable for the effective and efficient process execution
– The assigned Change Manager shall make time available to ensure the process is executed in
the most effective and efficient way
56
• Senior Management, via the Process Owner, is committed to the process by means of making
required resources (financial, technical and people) available
– To ensure that the process will not be adversely impacted by the lack of resources
57
• Change Management shall be performed in accordance with the documented Change

Management process and procedures
– When execution is performed as documented, it will guarantee the desired objectives are
being met the way the process was designed. If objectives are not being achieved and/or
KPI thresholds exceeded, the improvement suggestions will be based on the actual way
the process is executed.
58
• Every Change implementation will have a tested Back-Out plan

– To ensure that every change can be reverted in case for any reason the change needs to be cancelled
59
• All changes are required to follow, and are subject to the authority of, the Change Management
process
– Changes create risks to the organization and service quality in particular. The Change
Management process has been designed to process as many changes as needed while
minimizing the risk
60
• Every Change Request will be recorded and for Significant and Major changes there will be an
associated Change Proposal
– Change Requests need to be recorded to enable the organization to track and monitor the
change request throughout its whole lifecycle, as well as ensuring that historical data on all
changes is available and performance of the process can be measured
61
• Every Change implementation will have a Test Plan prior to deployment

– This policy is to ensure tests will be conducted following a pre-defined plan, minimizing the
amount of risk of non-working components and functionalities during and/or after
deployment
62
• There will be an impact and risk assessment for all Change Requests
– This policy will establish tha
– t the right amount of attention to understand what this change will impact or how it will
be impacted by outside factors.
– The risk level determines which change authority shall be assigned
63
• There will be segregation of duties in order to prevent

the potential conflict of interest. The following roles may
not be combined:
– Change Manager and Change Owner
– Change Owner and Change Authority
– Change Manager and “person who deploys”
64
• Every change will have a Change Owner

– A Change Owner ensures the lifecycle of every change ticket is monitored and coordinated,
and Change coordinator ensures somebody is responsible for the execution of specific
change related tasks.
65
Implementation Readiness
WHAT DOES GO-LIVE (19 MAY) LOOK LIKE?
• Start reporting Changes based on the KPIs defined for Asia Harmony
• Design, Build & Test activities will follow the Release & Deployment
Management process
• This will serve as input to Change Management to raise an RFC (CRQ)
Note: Release & Deployment Management process goes live on <TBA>
67
AFTER 19 MAY…
• Continual Improvement
• Documented in gap analysis & improvement plan
• Covers people, process, tools
• Appoint owners & target dates
• Continued reporting (weekly, monthly)
• Continued communication
• Communications channels
• Central repository for process documents
68
Email template
•Complete “Risk & Impact Questionnaire“
•Open RFC ticket on SM7 and save to get reference ID Category : <..Change Category..>
(using system in Deploy phase ) Title : <Change title>
Change •Complete email template Project ID : <Required Project ID reference, If
need>
Requester •Submit email to change owner Scope of Change and related work : <Scope of change>
Description of change : <>
Project Plan Start Date : <required date time>
Project Plan End Date : <required date time>
•Perform assessment base on… Build & Test Target Start : <required date time>
•Change Request Information Completeness Build & Test Target End : <required date time>
Deployment Target start : <required date time >
•The parties involved for the execution of the change Deployment Target End : <required date time >
•Risk and Impact of Change including financial consequence , Business service Estimate Cost (Thai Bath) : <Cost estimate for build test and
Change Owner impact, regulatory and security impact. deployment >
•Submit email for Internal approve base on change category in “Approval matrix” *** Please submit “Test result” for Normal Minor Change and Emergency
(project) to Change Management Team.

•Perform assessment overall of change request….
Change Owner Requester's Unit : <Requester’s Unit>
Approve Requester’s Department : <Requester’s Department>
•Submit email to Change management team Change Owner's Unit : <Owner’s Unit>
•Start preparation for “Build & test “ Change Owner's Department : <Owner’s Department>
Change Owner *Change Owner can assign change if to new Change Owner (if need…)
69
•Complete email template for Build and Test Email template

•Low level Design Or Project’s Mile stone I. Change Information:
Change Owner •Submit email to Internal approve base on change category in “Approval matrix” Change ID: : <Requester’s Ticket >
Project ID : <Required Project ID reference, If
need>
Description of Change <required Description>
•Perform assessment overall of change request base on….
Project Plan Start Date : <required date time>
•Build & test and Deployment timeline Project Plan End Date : <required date time>
Change Owner •Risk& impact and cost estimate

Build & Test Start : <required date time>
Build & Test End : <required date time>
Approve •Approve or reject the change request Deployment Target start : <required date time >
Deployment Target End : <required date time >
Training and Communication Plan : <Required date time>
Estimate Cost (Thai Bath) : <Cost estimate for build test and
deployment >
•Submit email to Change Management team *** Please submit “Test result” for Normal Minor Change and Emergency
(project) to Change Management Team.
Change Owner
•Perform assessment of the request (based on match criteria of each Change Requester's Team : <Requester’s Team>
category) Requester's Unit : <Requester’s Unit>

•If required CAB approve , arrange to CAB for Build & Test Requester’s Department : <Requester’s Department>
Change
Management •Updated CAB result to document
•Inform result to Requester and Owner Change Owner Name : <Owner’s name>
Team

•Complete Build and Test activity
•Submit “Testing Result ” email to Change Management Team as evident for Internal Approval Name : < Approval Name1 >
Change Owner Completeness phase. : < Approval Name2 ,if need >
70
• Complete Deployment Information in RFC ticket (SM7)

• Preparation of Deploy
Change Owner • Submit for Internal approve base on change category “Approval matrix” base on Change SM7
• Perform assessment of change request for Deployment

Change
• Approve or reject the change request
Owner
Approve
• If RFC required CAB approve , arrange to CAB for Deploy approval

• Updated CAB result to document
Change
Management • Public result to Requester and Owner
Team
• Start Deployment
• Updated “Implement result” in SM7 and next to “RFC Closure”
Change Owner
• Verify with Change Owner and updated “Post Implementation Review (PIR)“
Change • Closed RFC
Management
Team
71

Training of Change Management Process Phase II V02

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Training of Change Management Process Phase II V02

Uploaded by

Copyright:

Available Formats

CHANGE MANAGEMENT PROCESS

NOC-Change Management Unit

Approving deployment of changes based on

Ensure that Change management process is

Change Owner Responsible for delivery of the Change

Reviewing, assessing and evaluating the request for

Change Requester Starting the Change Process by documenting the

Executive Sponsor CTO

Change Authority Line Management & CAB

Change Manager Head of Change Management Unit

Change Owner [TG Employee]

Change Reviewer [TG Employee]

Change Requester [TG Employee]

Change Build & Change

Initial approval steps performed by different authorities:

Portfolio Management Change Severity

Change Minor Change

Change Category Change Severity/ Priority

Emergency Change Calculated based on Risk & Impact of

Field Work and Facility

Risk & Impact Confirm “Test Result” Confirm “Test Result” in

- Change Title Preparation

CO-TL CO-TL CO CO-TL CO

Logging Verify Deploy Deploy Close

10 CR = Change Requester | CO = Change Owner | CM = Change Management Unit

Team Lead Team Leader Team Leader

Emergency (Project) No Unit Head

To get Change ID Change Open and Save to RFC

Sample : Email template

II. Change Requester and Owner information

Requester's Name : <Requester’s name>

Sample : Email template

II. Change Requester and Owner information

Requester's Name : <Requester’s name>

 Create common understanding of the newly designed Change Management

Introduction to Asia Harmony

• Create stronger cohesion to significantly improve go to

• Enable High Performance

• Implementation of key IT processes

• BU involvement at all levels and management

Service strategy • Implement the right project at

Service Transition • Control of different

Service Operation • Reduce # of repeat incidents

• Build common process competence

May ‘13 July ‘13 Feb – May May – June

DTAC Change Management

Idea Roadmap Roadmap

Service Portfolio & Prioritization Mgmt SPPM

Service Level Management SLM

Release & Deployment Management

Objective Initiates and Manages the Provides approval

“ID” Project ID (PID) Change Record (TBA)

Tool PPM SM7

• Provides PID • Release Team maps PID • Change Requester

– Solutions for new or changed to services (including the functional

Responsibilities Skills / Mandate

Responsibilities Skills / Mandate

Responsibilities Skills / Mandate

Responsibilities Skills / Mandate

Responsibilities Skills / Mandate

CHMA 1.0 Change Logging & Validation

Technology Categorize the change

Service Release & Change Request

CHMA 1.1 CHMA 1.2 CHMA 1.3 CHMA 1.5