ChaRM V/s SNOW

SNOW Change Control ServiceNow Workflow (QA)

New QA
Assess Authorize Scheduled Implement Review Closed
CRQ

Once all the

Move Assess QA CR Move the QA CR to Once the QA CR is Move the QA CR to
Deliverable to state Authorize state approved
TR moved to QA
Review state
approvers have
approved
• GxP Risk Assessment • Present in CCRB • Sequential approvals • TR movement • IQ Testing • Sequential approvals • The QA CR gets
• Supplier Assessment • Get approval to move in SNOW through Release • Functional Testing in SNOW closed.
• Other Project to QA Manager/ Basis Team • UAT Testing • Automatically PROD
Deliverables (VP, TP, • TSR CR is created
URS, FRA, FS, CS, DS • VSR
etc)
• Informal Testing
SNOW Change Control ServiceNow Workflow (PROD)

• For Production Only changes, the flow of “New Prod change” is initiated directly.
• Following are the different phases a change is progressed through in ServiceNow:

New PROD
Assess Authorize Scheduled Implement Review Closed
CRQ

Once all the

Move the PROD CR to Move the PROD CR to Once the PROD CR is Move the PROD CR to
Update the PROD CR TR moved to PROD approvers have
Assess state Authorize state approved Review state
approved
• VAL SME Reviews the • CR state is changes • Sequential approvals • TR movement • IQ Testing • Sequential approvals • The PROD CR gets
PROD CR in SNOW through Release • TSR in SNOW closed.
• Provides • In CAB Approval Manager/ Basis Team • VSR
confirmation to stage, present the CR
update the CR state in CAB meeting
Schedule: QA and Production deployment for SNOW Changes

Internal CCRB Deployment

FOR QA
• On Monday and • On Planned Date
Changes Wednesday

CAB Deployment
FOR PROD
• On Thursday • On Next
Changes Thursday

CAB Deployment
FOR PROD
• On Tuesday • On Same
Changes Thursday

• For changes to be deployed on a different day request to be raised at CCRB when presenting change
• For Urgent P1/P2 issue , leverage the High Priority Request Process ( Both QA and PROD Changes)
 SNOW Release Management
QA Change requests
• Once the change request is approved in CCRB and it is in Schedule state, Release Manager sends the Release package
(emails the Basis team) to move the TRs from Test to Quality environment
• Basis team moves the TRs and reverts on the status of the TR movement (Success/Failure)
• Release Manager changes the change requests state from Schedule to Implement
• Changes are now in QA environment

PROD Change requests

• Once the change request is approved in CAB and it is in Schedule state, Release Manager sends the Release package
(emails the Basis team) to move the TRs from Quality to Production environment
• Basis team moves the TRs and reverts on the status of the TR movement (Success/Failure)
• Release Manager changes the change requests state from Schedule to Implement
• Changes are now in PROD environment
 ChaRM
Transport Flow
Flow of Transport in ChaRM

Normal Change is Developer TR is locked. Tester / User BT QMD verified List of approved TR released
created after RFC creates the Functional moves change the evidences and changes is into
Approval and transport and testing /UAT after successful documents as per extracted by production
released to after 1st level of testing in QA the change impact Basis team to by Basis
Created

To be tested

Production
Successfully

Prod Import

Imported into
testing is done

Tested

Requested

Authorized for
development

development by testing, move the Test evidences / and initial build CAB List
Application TR from Impacted assessment
Impacted Friday – Pre

Import
responsible development to documents are
documents are BT QMD CAB-Call
In

QA ( to be tested revised
attached authorizes the Tuesday –
stage) . change to BT Defend
QMD authorized changes in CAB
for Import before Call and
09:30 p.m. IST for approved list is
next Thursday sent to Basis
deployment
Thursday – TR
released into
production

Note: The urgent change workflow can be used in case of P1 or P2 incidents. The goal is to allow fast remediation or
prevention of service loss. Successful testing of the solution must be performed before transport to production, but
documentation can be created and approved after correction of the incident.
Release Management in ChaRM
Normal Change TR movement from Development to Quality
• Once the RFC is approved and normal change workflow is created by application responsible, developer starts
the development by creating the Transport. The TR state is changeable in Dev system.
• Developer then moves the transport from development to Quality/Test System (in To be Tested stage) . The
transport is locked.
• Transport Status in the Test System is updated to "Transport of Copies Imported“
• Tester then login to perform the testing in Quality. The Transport system type is ‘Test System’
• Testing is done in Quality and evidences are attached for BT QMD approval for release in production.
• Once testing is done and change is moved into ‘successfully tested’ step, TR is in ‘released’ stage. The change is
moved for BT QMD authorization for production import

Normal Change TR movement from Quality to Production

• Once the change request is approved by BT QMD, the changes are approved in Tuesday, CAB . Release Manager
sends the Release package (emails the Basis team) to move the TRs from Quality to Production environment
• Basis team moves the TRs and reverts on the status of the TR movement (Success/Failure)
• Release Manager changes the change requests state from Authorized for Import to Imported in Production
• Changes are now in PROD environment
ChaRM – TRANSPORT SCHEDULE NORMAL AND GENERAL CHANGES
Data For
March and
April