CM Training Module

DS BAM Global Processes
Change Management
Copyright: SIPC
For Internal use by Shell

Local Logistics
• Fire exits and meeting locations in the event of an alarm

• Facilities
For Internal use by Shell GSP-ChM-2

Agenda for Training
• Welcome/Introductions
• Change Management Overview
• Change Management Details
• ServiceCenter
• Deliverables
– Compliance Checklist
– Testing Deliverables
– Email Signoffs
– Global Livelink
• Reports

Welcome and Introductions
Name
Role
Experience with Tools
Copyright: SIPC

Change Management (ChM) Process
• Description: To manage production changes to services in a standardised
way in order to maximise awareness and minimise risks
• Goal: Ensure standardised, prompt and efficient handling of all Changes
and minimise the impact of change-related incidents
• Benefits
• Increased visibility and communication of Changes to IT staff, business and
users affected
• Better use of resources, prioritisation of effort and planning of Changes
• Mitigate risk of implementation with proper planning
• Allows for trend analysis of recurring application changes
• Better streamlined process and information for initiating Changes
• Reduced adverse impact of Changes on the IT services and Service Levels by
improved impact and risk assessment

Logical Support Model with Change Activities
“Manage”
“Do”
Change
SUPPORT DESK (SD) • Review change logs
• Solve application SD tickets from SD • Identify analyse & prioritise changes
• Restore IT service
• Chair Change Advisory Board
• Update Knowledge Database
• If not resolved, escalate/route to DLV queues • Ensure compliance to change control
processes and procedures
APPLICATION DELIVERY GROUPS (DLV) • Coordinate and supervise all Change
• Solve DLV tickets from SD activities from start to finish (assessing,
• Restore IT service
planning, building, testing, implementing,
reviewing)
• Update Knowledge Database
• If not resolved, escalate to Vendor(s) • Coordinate issues concerning the
• Implement enhancement requests change
• Perform post implementation review
(PIR) / Quality Controls

ChM Process - What defines a Change?
• Change
– Simply stated, it is any modification to an asset or to the
configuration of an asset
• Emergency Changes
– A change without the appropriate lead time
• Lead Time is based on Impact Level of Change
• Enforced by the ServiceCenter
– Ranges from 3 (Level 3) to 14 (Level 1) calendar days
– A change outside the agreed ‘Change Window’ (if defined)

– A change implemented without all required deliverables, signoffs
and approvals in place will be considered an Emergency

ChM Process - Samples of changes requiring a
change ticket
• Permanent change/addition/deletion to a scheduled job (e.g.
Control M, Microsoft Scheduler)
• Running a data load manually
• Master Data changes outside the normal application process ie.
SQL updates
• Code changes
• Changes in regard to what a groups role or profile can or can not
do. This is not the addition of users
• Textual Content Changes. Ie. Web page updates unless you
have a front end tool.
• Reboot of a server by application staff

ChM Process - Samples of Application changes
NOT requiring a change ticket
• New user ID’s in SAP
• Password resets
• Manual initiation (one time) of existing batch job during
allowable window
• Using functionality within the application:
– Processing a transaction where additional authority is not required
– Modifying data

ChM Process - Infrastructure changes
• An infrastructure change is any modification to:

– operating system core (network)
– implementation of (security) patches, updates or upgrades
– configuration parameter changes (like virtual memory settings)
– changes in any OS supporting application (like event monitoring
tools, anti virus software)
– modification of the component hardware itself (like replacing a
hard disk)
• The creation or removal of user accounts is not a change

ChM Process - Infrastructure changes
• Scheduled server or network component reboots, and starting and stopping of
services, should be considered a (pre-approved L4) change, and therefore
suppressing related events through Event Management
– When result of an Incident/Situation: reboots and restarts of services can be managed and
documented through an incident ticket.
• Addition and/or removal of a printer(s) to/from the system should also be

considered a (pre-approved L4) change.
– Changing printer queues can be managed through an incident ticket
• Individual changes to a single client desktop as result of incident resolution

can be managed outside the change process with an incident ticket (e.g.
software install or disk replacement in case of damage)
• For file servers, moving a share location or making a share available also
qualifies as a (pre-approved L4) change

Risk Assessment Matrix (RAM)
• Purpose: To provide a consistent method for assessing impact of changes across
Shell
• Using the RAM matrix is required for all changes
• Use the assessed impact level provided as guidance in determining your final
assessment.
– Change Owner can adjust the suggested impact assessment but must be able to support
the assessment with valid reasons
• Impact field in Service Center Ticket will be used to ‘document’ answers to RAM
questions
• When using the RAM, there are three key areas to be considered:
1. Extent of Impact: What would be the financial impact OR number of people impacted if
the change were not to go ahead or if it were unsuccessful
2. Potential Business Risk: What is the potential business risk during the implementation of
the change
3. Additional Guidelines: Consider what other factors would increase or decrease the
impact level of the change

2. Potential Business Risk: What is the potential business risk
Risk Assessment Matrix during the implementation of the change
(Potential) Extent of Impact Potential Business Risk (During

Potential Riskchange window )
planned
Business
People Impact
Financial Impact
assessment
24x7 service or service
Service
(if you cannot determine Service degraded unavailable in prime
No Impact 1 unavailable in non-
Assessment financial impact) in prime hours hours or during an
prime hours
Determine agreed SAR window
Financi People
+
al Loss Affected
<300
Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
OR (Main site/Mutiple 3 3 2 1
sites/Country/Region/Multiple
or >100K + >0 Countries)
>1000
OR or 3
>50K + >300 (Global/Multiple Regions)
2 1 1
Classified as Critical
or >100K + >100
OR Service (URL) 2
or >500K + >0
Additional Guidelines:
1. Extent of Impact: What would be the financial impact OR
number of people impacted if the change were not to go ahead Factors that would increase change level
or if it were unsuccessful. If $ impact unable to be determined, Inexperienced staff
then use People Impact Assessment column Unique change never executed before in the specific environment
Potential impact to reputation, safety and compliance
Factors that could decrease change level
3. Additional Guidelines: Consider what other factors would Previous history of success
increase or decrease the impact level of the change

RAM Pre Approved Level 4 Changes
Potential Riskchange window)
planned
Business
People Impact
Financial Impact
assessment
Service
No Impact unavailable in non-
Assessment financial impact) in prime hours1 hours or during an
prime hours
Financi People
+
al Loss Affected
<300
Not OR or 42 3 3 2
>300
or
>50K + >100
>1000
OR or 3
>50K + >300 (Global/Multiple Regions)
2 1 1
or >100K + >100
OR Service (URL) 2
or >500K + >0
Note – PAL 4 only, otherwise would be Level 3.

Assessment could be used to support approval for
fuure PAL4.

RAM Extent of Impact (1)
1 2 3 4
(Potential) Extent of Impact
What to Consider:
Potential Business Risk (During
Potential Riskchange window )
planned
Business
Financial Impact
People Impact • Potential impact if change implemented
assessment
unsuccessfully 24x7 service or service
Service
Assessment financial impact) • Potential impact if change NOT implemented
No Impact
in prime hours1 unavailable in non-
hours or during an
prime hours
Financi
al Loss
+
People
Affected
• Potential impact if unplanned outage occurs
<300 If financial impact is known, use Financial Impact
1 Not OR or 4 2
Column, otherwise 3 3
use People Impact 2
Assessment
>300
>50K + >100
or • An estimate of financial impact such as revenue
2 OR (Main site/Mutiple
3 lost, people
dollars 3 costs (contractors
2 1
can’t work).
or >100K + >0 Countries) Ask your BSM, customers, application specialist if $
>1000 impact is unknown.
3 OR or 3
>50K + >300 (Global/Multiple Regions) Examples:
2 1 1
OR
Service (URL)
• no potential
2 financial impact and number of users
or >100K + >100
4 or >500K + >0
potentially impacted <300 – Line 1
• If change could cause an outage, stopping Retail
Credit Card transactions, therefore the potential
loss is over $500K, line 4

RAM Potential Bus. Risk (2)
1 2 3 4
What to Consider:
Potential Riskchange window)
planned
Business
• Potential impact to the business
People Impact
while
Financial Impact
the change is being madeassessment
Service
• WhatAssessment
the user would experience while (if you cannot determine
financial impact)
No Impact
Service degraded
in prime hours1
unavailable in non-
unavailable in prime
hours or during an
prime hours
the change is being made
Financi People
+
• Only what the customer would
al Loss Affected
<300
experienceNot during theOR change or 42 3 3 2
window, impact outside the window is
>300
considered
>50K + on the
>100 ‘Extent of orImpact’
•or If >100K
change+ is being
>0 made during a sites/Country/Region/Multiple
Countries)
standard outage/maintenance >1000
OR or 3
window’
>50K +then the
>300 column ‘no impact’
(Global/Multiple Regions)
can be used Classified as Critical

2 1 1
or >100K + >100
OR Service (URL) 2
Examples:
or >500K + >0
• Change is being made after business

hours, but requires an outage – column 3 SAR – Service Availability Request. A specific
period of time the customer has requested no
• Application is 24x7, change is being changes to occur, such as month end close.
made during planned outage window –
column 1
RAM Additional Guidelines (3)
Factors that would increase change level
Inexperienced staff
Unique change never executed before in the specific environment
Previous history of success
What to Consider:
• Other factors that may increase or decrease your assessment
• Items above are suggestions, you may have other factors that influence the
assessment. Document these in the Impact field of your Change Ticket
Examples:
• A specific change is done monthly, it is assessed as a Level 2. The previous
history of success MAY warrant decreasing the impact assessment value
• The change could impact an external interface, therefore potentially impacting
our reputation, therefore you may want to increase the impact assessment

RAM – How to use it
1 2 3 4
(Potential) Extent of Impact Potential
Potential Business Business
Risk (During Riskchange window )
planned
People Impact
Financial Impact
assessment
(if you cannot determine Service
Service degraded unavailable in prime
Assessment financial impact) No Impact 1 unavailable in non-
in prime hours hours or during an
Determine prime hours
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
1st. Determine Potential Extent of Impact (row) Additional Guidelines:

2nd. Determine Potential Business Risk (column).
Inexperienced staff
3rd Look for the intersecting point is the suggested Unique change never executed before in the specific environment
impact assessment. Potential impact to reputation, safety and compliance
Then, consider additional factors that may Previous history of success
influence assessment (up or down).
This is your final impact assessment. For Internal use by Shell GSP-ChM-19
RAM – Let’s practice
1 2 3 4
Risk (During Riskchange window)
planned
People Impact
Financial Impact
assessment
Assessment financial impact) No Impact unavailable in non-
in prime hours1 hours or during an
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
Scenario 1: Additional Guidelines:

Potential Financial Impact is >$500K if an outage Inexperienced staff
occurs Unique change never executed before in the specific environment
The application service is 24x7 Potential impact to reputation, safety and compliance
Other factors influencing assessment: None Factors that could decrease change level

RAM – Let’s practice
1 2 3 4
planned
People Impact
Financial Impact
assessment
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0


Risk Assessment Matrix – Let’s practice
1 2 3 4
planned
People Impact
Financial Impact
assessment
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0


RAM – Test Your Skills
1 2 3 4
planned
People Impact
Financial Impact
assessment
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0

Potential financial impact is >$50K and 450 users if Inexperienced staff
change is not successful Unique change never executed before in the specific environment
Application service is 24x7 but change is being Potential impact to reputation, safety and compliance
made during an agreed outage window
Other factors influencing assessment: None
RAM - Test Your Skills
1 2 3 4
planned
People Impact
Financial Impact
assessment
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
Scenario 2:
Potential financial impact is >$50K and 450 users if Factors that would increase change level
change is not successful Inexperienced staff
Unique change never executed before in the specific environment
Application service is 24x7 but change is being Potential impact to reputation, safety and compliance
made during an agreed outage window Factors that could decrease change level
Other factors influencing assessment: None

1 2 3 4
planned
People Impact
Financial Impact
assessment
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
Scenario 3: Emergency Change

Potential financial impact is >$50K and 220 users Factors that would increase change level
if change is not successful Inexperienced staff
Application service is 24x7 but no outage Unique change never executed before in the specific environment
expected
Other factors influencing assessment: Re- Previous history of success
occurring change, with detailed working
instructions, history of success For Internal use by Shell GSP-ChM-25
1 2 3 4
planned
People Impact
Financial Impact
assessment
agreed SAR window
Financi People
+
al Loss Affected
<300
1 Not OR or 42 3 3 2
>300
or
>50K + >100
3 3 2 1
>1000
3 >50K + >300
OR or
3
2 1 1
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
Scenario 3: Emergency Change

Potential financial impact is >$50K and 220 users Factors that would increase change level
if change is not successful Inexperienced staff
Application service is 24x7 but no outage Unique change never executed before in the specific environment
expected
Other factors influencing assessment: Re- Previous history of success
occurring change, with detailed working
instructions, history of success For Internal use by Shell GSP-ChM-26
RAM - How to document in Service Center
Impact tab Requirement for change ticket
The information used to determine impact on the Risk Assessment Matrix is to be

stored on the Impact tab in the change ticket, in the Impact description field.
This text can be copied into that field, then choose one of the highlighted items for
each bullet.
---------
 Financial Impact: >50K >100K >500K

 People Impact: >0 >100 <300 >300 >1000
 Business Risk: No impact Degraded in prime Unavailable in non-prime 24x7 or
unavailable in prime/duringSAR
 Other factors:
(e.g. inexperienced staff, unique change, history of success.)

Lead Time explained
Sufficient lead time must be available upon closing the Plan
Phase to implement a normal change.
• For example, if impact level = 3, then your change must be out of the
Plan Phase a minimum, 3 days (72 hours) prior to the planned start
date. The lead time is calculated from the closing of the plan phase to
the planned start date/time
EXAMPLE: To implement a change on Saturday at 10:00 am, your
change ticket must move through the phase as follows:
DAY Tuesday Wednesday Thursday Friday Saturday Monday-Friday
Plan Build Build-Implement Implement Close
Must be Must be in Need to move Must be in Change is Close Service

in the build by through Build, Implement implemented Center ticket within
plan 10:00 am Test and into Phase and at 10:00 am 5 business days
phase Implement have all
Phase approvals

What to watch out for on Lead Time
The following fields, will impact your lead time and the status of the change
(normal or emergency).
• Impact Level (Level 1, 2, 3)
– Impact Level cannot be changed after Assess phase.
• Planned Start and Planned End

– Cannot be changed after Plan phase
• Changes to the above field (after the phases indicated) can only be made
by having Change Coordinator (via DS IT BAM GLOBAL CHANGE
mailbox) move the ticket back to the Assess or Plan phase.

ChM Process - Roles and Responsibilities
• Change Owner: Coordinate and supervise a specific change from start
to finish
• Change Assignees: Develop, build, test, or implement a specific
change (Segregation of Duties)
• Change Approvers: Assess, check for conflict and approve changes
• Change Coordinator
• Manage all Changes across their specific BAM region
• Convene and manage Change Advisory Board (CAB)
• Regional Change coordinator leads
• AMR - Shirley Connell
• APM – Shirley Connell
• EUA - Eric Hardie
• Change Manager: Regional leaders for Change Management
• AMR - Nancy Malke
• APM - Suganthi Subramaniam
• EUA - Klara van Noord

Segregation of Duties (SoD)
Per SOx, it is required to have segregation of tasks between staff making a

change. “Two pairs of eyes” are required for all changes.
Key Points
– At least 2 people required
– Developer (build assignee) cannot promote to production (implement assignee)
– Revtrac can only be used as implement assignee
– “Third Party” can be used as an assignee but requires entry of name
– If SOD cannot be achieved compensating control required (email template
available)

Segregation of Duties (SoD) – Changes where SoD
requirements cannot be met
Service Center will not allow the Build and Implement Assignee to be the same. In the situation where the
Developer (Build Assignee) must move the change into Production themselves (e.g. change can only
be made in production, or no other resources available to assist with change), the following steps need
to be taken:
1) In Implement phase, select 3rd Party from down list in Assignee field
2) In Implement phase, enter ‘Refer CC’ in the Assignee Reference field
3) Ensure necessary Compensating Control email is stored in GLL folder for change
Options:
1) Individual email for each change and store in the change folder
2) Identify common occurrences and have blanket email stored that is copied into each change folder when
change is executed

SOD Exception

ChM Process - Key Acronyms
• RFC – Request for Change. A formal appeal of change in the production
environment
• CAB – Change Advisory Board. Committee that is convened to review and approve
change tickets throughout the change management process
– XCAB – Cross CAB. Infrastructure and application combined CAB for Level 1 &
2 Prime/Essential app changes
– App CAB – Application CAB. CAB for all other Level 1 & 2 changes and all
Level 3 changes (no infrastructure changes)
• ECAB – Emergency Change Advisory Board. When urgent problems arise, there
may not be time to convene the full CAB. For these cases an emergency
committee should be identified with authority to make emergency decisions
• CNL – Change Notification Letter. A template to be completed by the end of the
test phase to communicate Level 1 and Level 2 change implementations to the
customers

Prime/Essential CABs - Quick View
DS GSAP/CCAP (preCAB) XCAB
Scope Scope
DS GSAP and Critical CAP L1, L2, L3 Prime, Essential
changes L1, L2 changes
Reviewed Reviewed
Application changes, in scope Application changes, in scope
infrastructure changes and release infrastructure changes and release
bundles. bundles
Attendees (DS BAM) Attendees (DS BAM)
CAB Chair, Change Coordinator, DS CAB Chair, Change Coordinator, COB
GSAP Landscape Manager, COB XCAB Focal Points, Release Owner,
XCAB Focal Points, Release Owner Release Coordinator
Attendees (Infrastructure) Attendees (Infrastructure)
ITS representative(s) ITS representatives, CSC (US only)
Frequency Frequency
Once a week Once a week

Prime/Essential CAB Agenda
(DS GSAP/CCAP and XCAB)
• Approval of prior CAB minutes
• Release Announcements
• Release Approvals
• Infrastructure Changes - review risk and impact of each change
• Application Changes – review risk and impact of each change
• Qualified and Unsuccessful Changes since prior CAB (Application/Infrastructure)
• Review future ‘high impact’ or ‘high visibility’ changes (application and infrastructure)
• Review prior weeks relevant Application SIPs/CAIs caused by a change
• Review prior weeks relevant Infrastructure SIPs/CAIs caused by a change
• Exception reports
– Emergencies since prior CAB
– Still Open Changes (application only)
• Actions
• Any other business

Role Description for COB XCAB Focal Point
As a result of the formation of the XCAB there is now a requirement for a role from the
delivery team, COB XCAB Focal Point
• Role Description
– To review all upcoming changes under their area of responsibility. Providing approval or
disapproval as appropriate
– To have an overall view and understanding of systems within the particular COB
• Focal Points assigned by COB – see next slide

BM COB XCAB Focal Points
COB Name (Lead=Bold) Specific Focus
B2B Liese Edwards CSC
B2B Michelle Cope Lubes Pricing
B2B Jason Chen ATS
DSF Jo-Ling Wong East
DSF Jack Mwaniki MI
DSF Rashida Bawahir ITS
DSF Robert Laing EU, backup
DSF Bartosz Sajkowski EU
ERP Janice Ooi
ERP Paul Ganzenmuller SAP - ERP
ERP Jubal Samico SAP - LA
ERP Thomas Kreuzberger SAP - Austria
ERP Chee Siang Tan SAP - Marine
ERP Nina Falck SAP - Interface
ERP Johan van der Meijden SAP
(GSAP)
- Chemicals GSAP
ERP Peter Schenkels SAP - Chemicals GSAP BW
ERP Gary Gansky SAP - Chemicals CAP
ERP Diane Fry JDE - AP
ERP Astrid Brustad JDE - EU
ERP Hector Gonzalez JDE - LA
ERP Tran-Quoc Tich SUN - AP
ERP Milan Musec SUN - EU
ERP Emile Van Den HoogenSAP EU and Lead Backup
MSD Rene Jansen
MSD James Dumensil
RTL Bert Reimer Site Systems
RTL Henk van Gaalen Cards & Loyalty
RTl Paula Mousighi Cards & Loyalty
RTL Francis Wong Network and Marketing
RTL Chik Chea Network and Marketing, Backup

Application CAB – Quick View
Application CAB
Scope:
• L3 changes for Prime, Essential changes
• All level application changes for Consumption,
Maintenance and Unmapped
Reviewed:
• Application changes
Attendees (DS BAM):
• Change Coordinator, Change Owners
Frequency:
• Weekly
• 2 CABS per week (1 AP/EU time zone, 1 EU/AM
time zone)

Application CAB Agenda
• Approval of prior CAB minutes

• Application Changes – review risk and impact of each change
• Previous weeks changes
– Emergencies since prior CAB
– Unsuccessful Changes
– Qualified Changes
• Any other business

ECAB for Emergency Changes
ECAB
Scope: All application emergencies for all tiers, and all
levels (L1, L2, L3)
Reviewed: Application changes (and BAM executed
infrastructure changes)
Attendees (DS BAM)*: CAB Chair, Change
Coordinator, COB XCAB Focal Points/Landscape
Managers, Change Owners, Support Team Lead,
Release Manager (ERP), Application Specialist,
Process Focal Point
Frequency: 1 ECAB but 2 meetings per day to cover
time zones.
*Suggested attendees, need to attend based on impact
of emergency change being represented

ECAB Requirements
• Requests for Emergency Change should be directed to the ‘DS IT BAM Global
Change’ Mailbox (See following slides for timings and deadlines)
– “ECAB” should be stated at the beginning of the Subject field, and marked as ‘High
Priority’
– Requests must be submitted by:

• Delivery/Team lead or delegate
• Application Specialist (Where defined)
• COB Focal Point (Landscape Manger)
• Change Owners (with prior approval)
– Include a valid Business Case / Impact Analysis
• If an Emergency occurs that impacts business continuity and therefore must be

implemented before the next ECAB, it can be approved verbally by the
delivery/team lead or delegate and implemented. This approval should then be
confirmed via e-mail and Emergency should be submitted for discussion at the next
ECAB.

ECAB Timings (summer/winter time)
• The AP/EU and EU ECABs will be split into 2 x 30 minute timeslots, the first timeslot
for DS GSAP Emergencies and the second for all other COB’s. This will be reflected in
the Meeting request with two dial-in times. All meetings are held virtually.
• AP/EU ECAB
– Start time DS GSAP – 06.00/07.00 GMT
– Start time all others – 06.30/07:30 GMT
– Cut-off for submission 04.00/05.00 GMT
– Agenda sent 05.00/06.00 GMT
• EU ECAB
– Start time DS GSAP 13.00/14.00 GMT
– Start time all others 13.30/14:30 GMT
• AM ECAB
– Start time all 20.00/21:00 GMT

Change Management Details

Copyright: SIPC

ChM Process - SwimLane
OP IT BAM - Change Management Process
C11.8a,c
Change Ticket Plan Change C11.11e
initiated from Record & Determine activities, Move to
START Assess Build Phase Prepare change Review
Problem, Incident C11.2a resources & time for
Change Owner
Ticket or Request change Verify Documentation Implementation.

Build, Test and is Complete.
Mgmt Change successful
operational Verify Support and
Implementation. & accepted? Notify
Move to Handover procedures
Determine outage Stakeholders. Verify
N Test Phase are complete
against sign off for
Verify Staff Training. Handover. Record
implementation Level 1 or
L4 or Create CNL
window.
2? change closure
Emergency Level 4 or
Y Create: Change Plan, details. On failure
Change Emergency ?
Data Conversion Plan conduct PIR
process Y
(if applicable) N
C11.2f Submit to Submit to

CAB CAB
Monitor & Review Change
Coordinator
C11.1a
Change
C11.11e
Review change Inform change
N completeness request closure
C11.6a to I&P team,
and quality C11.7a monitor status
Y
Reject Change,
change owner
CAB
N Approved? END
to decide on Approved?
resolve/close
N
Y
Build Change Implement Review

All Build activities according the Change. Implementation.
Change Assignee
Y Test Change
change plan. record & revoke SOD compliant?
According the
Impact of the change determines C11.7a additional Record non
test plan / test
the level of testing as described access granted. compliancy details.
scripts, compare
in the test plan. Verify assets. If Notify change
test results with
Segregation of Duty must be UAT change is not manager and Line
expect and
shown between Environments Approved? successful back manager.
accept/reject test
and Roles. out change. Record
results together
Create: Test Plan & Test scripts Record unauthorized
with Change
for Test Phase Implementation implementations.
owner. Create:
Test Results C11.2f details
C11.8a C11.6a
C11.1a C11.7a
IT Systems
Change C11.2a C11.2a Change

C11.2a Log
Log GLL C11.2f C11.2f

ChM Process - High Level Summary
Register and Monitor

Change Requested Change
Assess
End Approve
and Plan
To
End Build and
Test
Process
Authorise
Detailed instructions are available
and
in the Quick Reference Guide.
Implement
Change Accept and

Close
Implemented


Assess
Approve
• Formal submittal of and Plan
Request for Change
• Change is
assessed to Build and
determine impact to Test
production and
Configuration
Management Authorise and
Implement
Change Accept and

Close
Implemented

Service Center Valid Reason Codes Quality Tip:
Make sure
you choose
the best
Reason for
Change
• Valid choices for BAM Global Change Management Process are highlighted above
• If INRC, INRD or INRO is chosen, an Incident ticket must exist & be associated with the change
ticket; RCR is chosen, problem ticket needs to be associated instead.
• If any part of the change involves data conversion activities, CON must be chosen
• If other reasons are chosen, CAB approval will be delayed until corrected
• Will provide BAM metrics on types of implemented changes
Monitor
Register and
Assess
• Formal approval of Approve and Plan

Request for Change to
proceed to planning
• Formal Planning of
Build and
change including
Test
technical & functional
requirements, data
conversion and test
plans Authorise and
Implement
Change Accept and

Implemented Close

ChM Process - Approval & Plan Phase
The Change Owner will :
Change Owner • Open the Plan phase, by closing the previous

Plan Change phase in ServiceCenter
• Complete Compliance Checklist
No Data
Conversion
Change?
The Change Owner will:
• Ensure the Data Conversion Plan is produced
Yes
• Indicate ‘reason for change’ is “Conversion” in
ServiceCenter
Record Change
Change Owner as a Conversion Required Deliverables (Templates available):
• Test Plan
• Test Script
Next Phase: • Compliance Checklist
Build • Data Conversion Plan (if applicable)

Assess
Approval
• Creation of test scripts in and Plan
line with requirements
• Execution of formal
testing, documentation of Build and Test
results, and user
acceptance sign-off
• Build is NOT only coding
Authorise and
Implement
Change Accept and

Close
Implemented

ChM Process - Build & Test Phase
Change Owner Initiate Build The Change Owner will:

Phase • Open the Build Phase (close previous
phase) in ServiceCenter
• Ensure Test Plan is Finalized
• Finalize Test Scripts for Unit, FAT and PV
Required Deliverables:
Test Phase •Test Plan (template available)
•Test Scripts (template available)

ChM Process - Build & Test Phase
• Application Specialist Coordinates User Acceptance
Change Assignee Perform Test testing
Application Specialist In • Change Requestor / Business Owner will execute the
Test Environment test scripts in the test environment
Change Requestor
C11.7a • Change Owner and User
Record Actual review test results. If test
Change Assignee Results, Test Results results are accepted
(evidenced by FAT signoff)
Record Defects the change will move
forward.
Resolve
Change Owner Results No • Draft the Change Notification Letter
Issues and
Accepted and determine the CNL distribution list
Retest
•Required for Level 1 and Level 2
Yes Changes
•As needed for Level 3
Prepare Change Create CNL
•Test Results (template available)
Implement •Final Acceptance Test Signoff (template
available)
For Internal use by Shell •CNL GSP-ChM-53


Assess
Approve
• Final authorisation to and Plan
promote changes to
production
Build and
• Execution of the Test
implementation plan
Authorise and
Implement
Change Accept and

Close
Implemented

ChM Process - Authorise & Implement
Initiate The Change Owner will:
Implement • Open the Implement Phase (close previous phase) in
Phase ServiceCenter
• The change is put onto the CAB agenda
• Prime/Essential changes will go before the XCAB
Change Owner
• All other Level 1 or 2, and all Level 3 to App CAB
Submit to C11.8a
• The CAB reviews the readiness for Implementation
CAB • If rejected, the Change Owner is informed of the
decision. The Change Owner can then resubmit the
change or cancel the change request
CAB • If approved,
Approval • send CNL (if necessary) to the customer to inform
Change Approver Process them about the change implementation
• Determine Assignee for Implementation (Different
from Build Assignee for SoD) Notify delivery
manager by email of exceptions – template
available
•BAM AssetCenter CI Request Signoff (If
Change Owner Pre-Implementation applicable - template available)
Activities •Operational Acceptance (Transition to Support)
C11.11e
will be evidenced by Delivery team approval in
ServiceCenter GSP-ChM-55
ChM Process - Authorise & Implement
Change Assignee Implement • Change Assignee implements the
Change change by following the
Implementation Plan
• As part of the promotion to
production, record any special
Additional Record access rights granted, as well as
Access Access removed once the implementation
granted Rights is over.
• If the change is not successful,

Backout Change backout plan is invoked
Change No Successful • If back out plan fails, an incident is
documented
Yes
Close Phase

Change Requested Register and Monitor

Change
Assess
Approve
• Post implementation and Plan
review completed
• Final documentation
created and change Build and
ticket is closed Test
Authorise and
Implement
Change Accept and Close

Implemented

ChM Process - Accept & Close Phase
• The change ticket must be closed with an
Change Owner appropriate completion code
Review
Change Assignee Implementation 1. Successful
2. Unsuccessful – change backed out
3. Qualified – change implemented but
resulting issues
• Verify the details regarding granting and

Change Assignee revoking of temporary access rights for the
Segregation of
Duties change
Change Owner
• Verify segregation of duties.
Change Manager C11.3d
Change Assignee • If the change failed, conduct Post

Success of Implementation Reviews. Notify stakeholders
Change Owner Implementation if there are any incidents caused by the
change

SOD Scenarios
Scenario Description Solution
1 This is the most common example of a change where at least 2 assignees are A
available & SoD can be met.
2 Single Person support for an application. This is ongoing. SoD cannot be met. B
A Compensating Control is required.
3 A change can only be made straight into the production environment. There is B
no test environment. SoD cannot be met. A Compensating Control is required.
4 A one-off case where one person needs to do build, test & implementation C
activities. SoD cannot be met. The Delivery Manager needs to be notified of
this.
5 A Third Party organisation provides all support, including implementation. SoD D
within the 3rd Party organisation can be met.
6 Projects where the Build & Test assignees are AD&P or CoB Project D
Resources.
7 A Third Party organisation provides all support, including implementation. SoD E

within the 3rd Party organisation cannot be met. A Compensating Control is
required.
8 A change to an application needs to be applied by a GITI member. F
Note : All scenarios are available in the reference section of this pack

ChM Process - Acceptance & Closure Phase
Verify • Verify that Production Verification sign off

Change Owner Acceptance has been obtained from requestor
C11.8c
Record • Verify that all actions related to the change

Change Assignee closure have been closed and all mandatory
information is completed
FINISH
•Production Verification signoff (template
available)

ChM Process – Deliverables and Signoff Matrix

ChM Process - Emergency Change
Process used is same as normal change with the following differences
• Complete all deliverables and signoffs as per a normal change but can be done
post-implementation. Must be completed within 5 business days after
implementation.
• An emergency change may be implemented without full approval but remaining
approvals must be obtained retrospectively. At a minimum, emergency pre-
approval email must be provided as evidence if approvals in Service Center not
done in advance
• EAPR approval group must be used in place of normal CAB approval
group

ChM Process – Pre-Approved Level 4 (PAL4)
• Pre-Approved, low impact, frequently occurring change.
• Process exists for securing approval, once approved, a Level 4 Change
Record can be used for the specific type of change
• Level 4 Pre Approval Process Criteria
– Occurs at least four times a year.
– Evidence of success as a Level 3 change in ServiceCenter on at least 3
occasions
– Approvals will be required from:
• Business (evidenced by FAT signoff)
• Delivery Lead (evidenced by OA signoff)
• Change Management (evidenced by PV signoff)
– A Model Record will be set up in ServiceCenter which will be referenced for the
actual Level 4 changes
• Model Record will require deliverables, signoffs & approvals as for a normal change

Level 4 Pre Approval Process Steps
• Refer to Pre-Approved Level 4 Process document available on website

• Change Owner
– Create a Model Record in ServiceCenter
– Complete a Level 4 Pre Approval Request Form
– Obtains Delivery Lead approval
– Send to Change Management Team
• Change Coordinators
– Review requests
– 2 week turnaround for approval from Change Coordinator Leads
– Closes Model Record with new status ‘5’ ensuring all deliverables and signoffs
have been obtained

Using a Level 4 - Key Points
• Level 4 Changes must have gone through the Level 4 Pre-Approval

Process (PAL4).
• Level 4 Changes is created from an existing Model Record
• The Change ticket has no lead time requirements
• The Change does not require representation at a CAB Meeting
• Only one approval (GLBDSXBAMCAB) required at the Implement Phase,
automatically added
• No additional documentation (such as test plan, test results, etc.) is
required
• One Signoff required: Production Verification (Close Phase).
• A separate GLL folder per change ticket is not required. The PAL4 record,
known as the Parent Record (Model Record), will have a folder in GLL.

Production Only Changes
• https://sww-
knowledge.shell.com/knowhow/livelink.exe?func=ll&objId=74480703&objA
ction=Open&viewType=1&nexturl=%2Fknowhow%2Flivelink%2Eexe%3Ff
unc%3Dll%26objId%3D44496509%26objAction%3Dbrowse%26sort%3Dn
ame%26viewType%3D1Big Rules
– Still need FAT (the one accepting risk of no testing)
– SOD needs to be met, or need Compensating Control
– There are differences to the Test Plan Acceptance Criteria, Test systems and
Test Results (PV test only)

Help Aid - Guide for Changes Unable to be Tested Prior to
Implementation
• Covers changes that cannot be tested in a test or acceptance environment prior to
being implemented, such as
• Server reboot, hardware replacement / upgrade or master data update

that can only be done to production table
• Includes :
• How to update Assignee in ServiceCenter and SoD Compensating

Control Sign Off
• Documentation needed for Change Coordination Approval
– Still need FAT (the one accepting risk of no testing)
– SOD needs to be met, or need Compensating Control
– There are differences to the Test Plan Acceptance Criteria, Test systems and Test Results
(PV test only)
• Documentation needed upon Final Closure of ticket
• This Help Aid can be found at the BAM C&R Website

under ‘Guide for Changes Unable to be Tested Prior to Implementation’

Release Management Requirements for Change
Management
As part of our journey to provide Top Quartile Performance (TQP) in service
delivery for application management, DS IT implemented several global
processes based on an ITIL best practices and compliance requirements.
• One of the requirements is Release Management. If your delivery team is
onboarding with Release Management, the Change Management process
you have been trained on will remain with some minor procedural changes
• The following training pack, Release Management Requirements for
Change Management, will provide an overview of Release Management
and it requirements for Change Management: <https://sww-
ction=Open>

Quick Quiz: Change Management
• Change Tickets are necessary in all but the following situations
– Changes to batch jobs
– SAP Master Data
– Password resets
– Textual Content Changes
• Is Segregation of Duties required in Change Management?
Yes
• A Change Notification Letter is required for what level of changes?
Level 1 and Level 2 (optional for L3)
• All approvals are required prior to implementing an emergency change
(True/False)?
False (at a minimum at least approval from Delivery Lead)
• Level 2 changes require no lead time (True / False)?
False (requires minimum of 7 days)

Service Center
Copyright: SIPC

SC Assignment Group - Naming Convention
AMRDSXSAPSCASD - ERP - SAP - Supply Chain Application Support Desk
Component Guideline
Geographical AMR – Americas; EUA – Europe; APM - Asia Pacific; GLB – Global
Area of
Responsibility
Discipline DSX - Downstream
Function Name of the functional group supporting business portfolio
Remaining Type of support team:
characters
CHG - Change assignment group for that application or group of applications
APR - Change approver group for that application
EAPR – Emergency change approver group
CAB - Change Advisory Board for that application or group of applications
ASD - Application Service Desk (Incident and Triage)
DLV - Delivery team
OFF - Offshore team
PRB - Problem Management team (RCA)
This is the approved naming standard for DS assignment

groups used for Incident, Problem and Change
Service Center - Assignment Group Samples
Geographical Discipline Function Function Remaining Description
Area of (cont.) characters
Responsibility
GLB DSX B2B ES CHG Eserve Global Change
Assignment Group
GLB DSX B2B ES APR Eserve Global Change

Approval Group
AMR DSX MFG SCR CHG MFG - SCIPR – Change

Assignment Group
APM DSX RTL LLC CHG RETAIL Loyalty Change

Assignment Group
EUA DSX SAP AIM APR ERP SAP AIM Change

Approval Group
GLB DSX BAM CAB GLB Downstream BAM

Change Advisory Board
These are samples of assignment groups

Service Center Master Data update
• To Update ServiceCenter Master Data, such as adding new approver to

Service Center Approver group, please do following
– Complete form located at https://sww-
knowledge.shell.com/knowhow/livelink.exe?func=ll&objId=32316574&obj
Action=browse&sort=name
– Send completed form to “DS-Application-Support-Desk-Global SIPC-DFI” in
Global Address List
– Form will be reviewed by I&P team and sent to appropriate Change or Incident
Manager approval.
– After approval from Change or Incident Manager, form will be sent to ITSM
group for processing
– Notification will be sent back to requester upon completion of request or denial

ServiceCenter

Deliverables
Compliance Checklist
Testing
Email Signoffs
Global Livelink
Copyright: SIPC

New Quality Review
• https://sww-
ction=browse&sort=name
• External slide pack

• Recording of communications session
• Link to SME/Focal Point list

Compliance Checklist
• As changes enter production, there is a risk of impacting the application’s

compliance in the area of SOx, ISIP and Records Management. The
checklist:
– Will create the awareness that there may be an compliancy impact requiring
additional action.
– Contains prompting questions reminding the change owner of the ISIP, SOx,
and Records requirements.
– Is initiated in the Plan Phase to allow time to address the compliance
requirements
• Delivery Teams is responsible for reviewing all changes against the
Checklist
– Changes will not be approved without a Checklist deliverable
• Change Advisory Board (CAB) will look for the completed Compliance
Checklist. The Delivery Organization is responsible for accuracy of the
content.

Compliance Checklist deliverables – when required
• Compliance Checklist – refer to instructions specified on the template
• If answer is “yes” to the SOx question

– File the Control Owner Approval Email in same folder, if necessary
• If answer is “yes” to the ISIP question
– Complete the associated ISIP deliverables for compliancy (work with your
Application Compliance Focal Point) and file in Compliancy folder
• If answer is “yes” to the Records Management question
– Complete the associated RM deliverables for compliancy (work with your
Application Compliance Focal Point or your GRM/RIA SME) and store in
Compliancy folder

Sample email of the Control Owner Approval

Need help knowing what to do?
If you are unsure about SOx and ISIP compliancy, there are places you can
go for more information:
• Talk with your team lead or other team members that have been involved with ISIP and SOx
activities or have ISIP and SOx applications today
• Talk with your Delivery Team Focal points for ISIP and SOx Anchor Networks. They will have a
deeper level of knowledge to provide guidance and direction.
• Review the Application Compliance website - There is a variety of training resources available
http://sww.shell.com/downstream/it/delivery/bam/app_compliance/
If you are unsure about Records Management compliancy, there are places you
can go for more information:
• Talk with your team lead or other team members that have been involved with RM activities or
have RM relevant applications today
• Talk with your RFP (Records Focal Point). See
http://sww.shell.com/ethicsandcompliance/records/main/rfp_network.html for your RFP.
• Contact the functional mailbox DS RIA HelpLine.
• Review the GRM website - There is a variety of training resources available
http://sww.shell.com/ethicsandcompliance/records/

Testing
Copyright: SIPC

Testing in Change – The Whole Picture
Test strategy • Overall BAM Test Strategy
(reference document to guide with test plan creation)
Test Plan
Test Results
Test Script
• Compare test
Test Script
results against
Updated Scripts excepted
results
Test the Change Defects Report • Defects found
during testing
Test Report • Report with

results,
exceptions,
acceptance
Testing Documents Required for a Change
• Test Plan
– A detailed plan to explain why, when, how and by whom a change will be tested
• Test Results
– Test Scripts
• Sequential steps to be performed and the expected results compared with actual
results
– Defect Report
• Defects/Exceptions found during testing
– Test Report
• Summary of results including the test script pass/fail status, identified defects,
deviations from test plan and recommendation

Testing – Test strategy
• For BAM, the test strategy is already created for use as a reference
guide for developing your test plan (OP Test Strategy)
• It is a guide to develop the test plan and contains information on the
following:
- Stakeholders
- Business Risk Assessment
- Test Types
- Test Level
- Acceptance Criteria
- Organisation
- Test Infrastructure

Test Plan – what is it?
• Primary purpose of the test plan is to serve as a communication
document between the delivery team members in test roles and the
business.
• Key Components of the test plan include
– Evaluate the risk associated with the change and determine the
approach
– Notify the business of the plan and their role in testing
– Communicates to the business what is in and out of scope
– Provides justification for changes not meeting the standard BAM
minimum test levels of Unit, Acceptance and Production Verification

Test Plan – Step by Step
Introduction
Change ticket number
• The change ticket related to this test is: GCR00140622
• This ties the test plan document to the change ticket in Service Center which allows
an auditor to confirm the information matches the ticket being reviewed for
compliance.
GCR00140622

1. Test Assignment
1.1 Customer –The Who
– Customer Name, Title AND Business Unit
– This connects your customer to the change
1.2 Assignment – The What

– Describe the request as the customer described it to you
Copy the
– Change Description or Functional specification can be used for description
this section from Service
– This makes it clear to all parties what you are asked to do Centre
– Helps you to understand your risk areas

1. Test Assignment continued…
1.3 Documentation
List the documents that have been used to create the test plan and any additional system
documentation (functional specifications, user guides, technical specifications, etc). If such
documents exist, insert a link to the application’s Global Live Link folder. The template already has
OP Test Strategy as default because it was used to create the test plan template
• DS Test Strategy Do not remove this link or replace it with N/A
• <Additional documents as needed> or <URL>

2. Test Approach
22.1 Introduction
The Matrix below is a guide that has been designed to assist with defining the test
approach. Knowing the change impact level will assist in determining the test
approach. The test approach should include the test types (see section 2.2) and the
levels of testing (see section 3.1). The DS Test Strategy should be used as a more
detailed guide for defining the approach.

2. Test Approach continued…
2.2 Test types - Quality attributes

• Select “Yes” for test types being
executed, “No” for test types not being
executed
• This indicates to your client how you are
testing the change to mitigate or lower
the risk of it being put into production
with issues
• Must select at least one type
• The types selected must correspond to
the activities executed in your test
scripts

3. Acceptance
3.1 Test Levels with Exit Criteria
This section is used to indicate when each test level is successfully completed. This allows you to
determine when the next level of testing can start.
– Exit criteria must be given for each test level
– Mandatory section, the template is already filled in with the 3 Levels. All that needs to be
completed is the exit criteria for each
– Justifications have to be included if any levels are excluded for this change (ie. Change can
only happen in the production environment)
Change tested
before
Implementation
OR
Change made directly

into Production without
previous testing

3. Acceptance continued ….
3.2 Signoffs
• Identifying Information should include name and prefer business unit
• Minimum sign offs are as indicated in the template
• Reminder.. This is a plan, if the names change later, updating the plan is not
necessary

4. Test Organization
4.1 Relationships with other Parties
• List of all parties outside the immediate support team that are required for testing
and their responsibilities (EG. Business, Vendor, etc)
Party Name Required level of input
Website Focal Point Anita Bettis Give input on scripts, approve acceptance testing
Project Manager Andy Blatchford Execute acceptance testing
4.2 Roles, Responsibilities and Competences

• List individuals from the immediate support team who will be involved in testing
• All fields must be populated. Change owner, test manager, test analyst and defect
manager
Name Role in Change/Testing
Keith Goodall Change Owner SC Change Ticket Creator

Keith Goodall Test Manager Coordinate Test Activities
Keith Goodall Test Analyst Exe & Doc Test Script / Results
Keith Goodall Defect Manager
Coordinator Defect Activities
All 4 Names may be the same, depending on the scenarios.

5. Test Environment
5.1 Test Environment
• Acceptance/Test environment should be representative of the production
environment. If acceptance test is not being done then list the production
environment
– Hardware
– Software
– Master Data
5.2 Test Data

• Indicate the method of data manipulation
– Data Collecting
– Data Maintenance
– Data Cleansing
• Indicate “No data collection required”, “No data maintenance required”, “No
data cleansing required” if the mentioned method is not applicable.

6. Implementation Plan
Quality
Tip: Make
sure you
identify all
the steps
needed in
your plan

start of
7. Defect Management process
• Description of how identified defects enter defect

will be recorded and managed to
resolution
investigate defect
• All problems found during test

execution must be recorded using the
approved template or test tool Unique
defect, needs
No
when defect:
solved? - is a duplicate
- turns out not to be a defect
Yes - is postponed
• The flowchart should NOT be
fix defect
removed
• Remember ANY AND ALL defects retest
found during Acceptance testing are

to be recorded in the defect report
No
Retest OK?
Yes
end of
process

Test Results: Test Scripts, Defect and Test Report
• Test Script
– The Test Script is a detailed description of how to perform a test
– They describe the sequential test steps to be performed, transactions, data to
be used and the expected results
– Test Scripts are required for Acceptance Testing only
• If the change can only be tested in production, then a Production Verification script is
required. Unit Testing Scripts are optional
• Defect Report
– Defects need to be recorded if a problem is discovered while executing an
acceptance test script
– Used for tracking defects to its resolution
• Test Report
– The Test Report provides an overview of the test results for the change

Test Results: Test Scripts
During build phase:
• Download new test script template from C&R web site
• Enter header information
• Enter detailed steps and expected results
[Check Script] check the

completeness of the information [Insert Script] creates a
inserted in the respective Test Script new Test Script
worksheet

Test Results: Test Scripts (Defect Found)
During test phase:
• Execute Test Scripts & Record Actual Results
• Multiple Test Scripts should be added as tabs to the Excel spreadsheet
• Document defects in defect report

Test Results: Test Scripts (Re-test, Passed)
After testing is complete:
• Verify content of script to ensure all required fields are completed (recommend executing
macro)
• Add all versions to GLL. Latest version should be uploaded last
Quality Tip:
Make sure the test
script has all the
steps listed in
enough detail to
ensure thorough
testing.

Test Results: Defect Report
• Defects found during acceptance testing must be recorded in a defect report
• Each defect must include reference to the test script, detailed description of defect,
date reported, name of person reporting the defect, and severity
• If no defects are found, the Defect Summary section of the Test Report should
indicate that no defects were identified during testing
• Supporting documentation (test script results, test report, and information in
Signoffs) must be consistent with Defect Reports
(Check Defect) check the completeness of
The information inserted in the Defect Report
(Updated Defect) will populate defect

ID and Test Script Name if there is defect
In the test script(s) worksheet

Test Results: Test Report
1.0 Test Results
• List of scripts with Pass/Fail status
2.0 Defect Summary

• Total number of defects
found and status

3.0 Acceptance
• Confirmation of test levels
meeting Acceptance Criteria
4.0 Compliance to test plan

• State if tests deviated from
those specified in test plan
• Select option from drop down
5.0 Recommendation
• Based on Test Results, select
recommendation to move
change through to Production
environment or not.

Test Results: Demo

Quality Assurance – SOx Audits Samples
Control Sub-Process QA Process
No.
C11.2 Change Request Initiation and C11.2f – validate that changes have been correctly logged and determine
Control whether any unauthorized changes were implemented.
C11.2g - Removal of any access granted to implement a change
C11.2h – Verify segregation of duties
C11.3 Emergency Changes C11.3b – Verify emergency changes performed in line with documented
procedures. Sign-off prior to implementation; approval for emergency; sign-
off of successful implementation.
C11.3d - Removal of any access granted to implement an emergency
change
C11.5 Application Test Plan C11.5b – testing sign-off verifying testing was done in accordance with
formally documented test strategy.
C11.6 Testing of Changes C11.6c – Sign-off completed for FAT
C11.6e – Verify Expected test results were documented
C11.6f - Verify testing was performed in line with test plan
C11.6g – Verify sign-offs to confirm that actual test results were compared
to expected results and that exceptions were formally documented and
tracked to resolution.
C11.9 Data Conversion C11.9b – Verify sign-off in place for conversion activities and that conversion
was performed in accordance with the Data Conversion Plan.
C11.13 Problem Management C11.13b – Verify that problem management logs are reviewed by the
business on a regular basis.
C11.13c – Verify that problem management is performed in line with
documented procedures.
This reflects a sampling of the items
for review by the QA team
Non - Compliance
• Results of audits will be reported to Delivery Leads on a
monthly basis (Business Performance Review)
• Action plan to correct non-compliance will be developed with
the staff
• Action will need to be taken to correct the non-compliance so
that it passes future audits

Signoffs
Copyright: SIPC

FAT Signoff Template
ChM PROCESS UPDATES
When completing the Final Acceptance Testing Signoff Template, you only need to
complete one of the two sections.
For Case 1, extract this section,

delete remaining text in body of
email then send to Business User
for Signoff
For Case 2, extract this section,

delete remaining text in body of
email then send to Business User
for Signoff

BAM AssetCenter CI Request Signoff
If the Change Owner or delegate should identify that there are associated CMDB
updates the following is required:
• Signoff from the Configuration Coordinator validating and approving the associated
CMDB updates.
• Email must include a clear reference to the correct change ticket, header
information with the sender and date, and clear indication of what is being approved
• Email must be uploaded into the deliverables folder in Global LiveLink.
• The BAM AssetCenter CI request template must be used and should be submitted it
to the Configuration Coordinator for approval via the Configuration Management
functional mailbox (DS IT BAM Global Configuration Management)
• The Configuration Management Comments field of the Assets tab must have the
following:
• Statement Indicating that this change requires an update to the CMDB, and
• The GLL reference link to the completed BAM AssetCenter CI Request
Template (the link will be provided by Configuration Coordinator in the signoff).

Change Mgt Process – Configuration
Management Comments
Link will be provided by

Configuration Coordinator via
the “approval email” signoff
Note: If you do not have a CMDB update, you still need to indicate this in the
comments field “This change does not require an update to CI attributes
as recorded in the CMDB”

BAM AssetCenter CI Request Signoff – cont.

Data Conversion Signoff
If reason for change is “Conversion”, the following is required:
• Email that clearly indicates that the data conversion was carried out in accordance with the Data
Conversion Plan must exist in Global Livelink
• The email must include a clear reference to the correct change ticket, header information with
the sender and date, and clear indication of what is being approved
• The name of the person providing the sign-off must be accurately documented in the Change
Ticket on the Implement sub tab of the Access/Sign-offs tab

Production Verification Signoff
• Email that clearly indicates appropriate knowledge of the change (promoted as expected,
promoted with issues, or backed out with restoration of the environment) must exist in Global
Livelink
• The email must include a clear reference to the correct change ticket, header information with
the sender and date, and clear indication of what is being approved
• The name of the person providing the sign-off must be accurately documented in the Change
Ticket on the Close Info tab

Pre-Approval of Emergency Change
• If approval cannot be provided before the planned start of the
implementation in the change ticket, an emergency pre-approval email
must be obtained from the Delivery/Team Lead and placed in the Signoffs
folder in GLL (cannot be stored in Service Center)

Note about signoffs for approved RevTrac
Applications
• If the change is being made for approved SAP applications that utilize the RevTrac
system, an additional email is not necessary for the Final Acceptance Test and
Production Verification signoffs
• These applications have an approval structure built-in that complies with the signoff
process
• Link to approved applications that can use RevTrac for FAT and PV signoffs:
https://sww-
knowledge.shell.com/knowhow/livelink.exe?func=ll&objId=53920188&objAction=Op
en

Global LiveLink
Copyright: SIPC

ChM Tool – Global LiveLink
• All DS application documentation will be populated in Team
Working 1 (TW1) instance of LiveLink
• All Application Documentation will reside in each application
support area by COB
• Path to folders in LiveLink:
 Enterprise
 Downstream
 Downstream Functions
 IT
Business Applications Management
COB (Example; Applications Support – Manufacturing)

ChM Tool – Global LiveLink
Each sub-folder will require standard documentation. Documents in
the folder are placeholders for your documentation.
-> Change Management
-> 2007 Changes
-> <enter change ticket number here> Short description
o 1.0 – Test Plan
o 2.0 – Test Results
o 3.0 – Change Plan
o 4.0 – Data Conversion Plan
o 5.0 – Compliance Checklist
-> 6.0 – Sign-Offs
-> Related Technical Documents

Reports
Copyright: SIPC

Reporting Dashboard
By Class of Business (COB) and Region
• QA Data
– Individual results of all QA audits (charts and data)
• BPR
– Total and Emergency Changes (S)
– Successful Changes (S)
• Weekly Reports
– Emergency Changes as a Percent of Total Changes (S)
– Emergency Changes (D)
– Successful Changes as a Percent of Total Changes (S)
– Unsuccessful and Qualified Changes (D)
– All Changes Implemented (D)
• Exception/Compliance Reports
– Open 5-Days After Implementation (S) and (D)
• All (all COBs and all Regions)
– Total and Emergency Changes by COB (Monthly)
– Successful Changes by COB (Monthly)
– Total and Emergency Changes (13 Months)
– Successful Changes (13 Months)
Link: http://sww-sopus-bamdashboard.americas.shell.com/
Updated each Tuesday afternoon with prior week data.
Global Livelink
BPR (by Month)
• BPR slides
• Backed Out Changes Details
• Closed Ticket detail
• Emergency Changes Detail
• Qualified Changes Details
• Change Audit Report
• QA Audit data
• QA COB Trends
Exception/Compliance Reports
• Current Report – Summary – Count of Tickets still Open
• Current Report – Ticket’s open more than 5 days past implementation
• Monthly QA Noncompliance
Link: https://sww-
ction=browse&sort=name
Change Management
Additional Reference Information

Copyright: SIPC

Additional References
• BAM Home Page

– http://sww.shell.com/downstream/it/delivery/bam/
• Change & Release Web Site

– http://sww.shell.com/downstream/it/delivery/bam/change/
• Business Compliance
– http://sww.shell.com/downstream/it/delivery/bam/compliance.html
• Service Center Demo - Change Management - Step by Step Screen Shots

Available on the C&R Web Page (Change Management Demo)
• Change Management Mailbox (DS IT BAM Global Change)
• Test/QA Mailbox (DS IT BAM GLOBAL TEST & QA)

BAM Change and Release Website

Solution A
Scenario #1: This is the most common example of a change where at least 2
assignees are available.
SoD can be met. A Compensating Control is not required.
Phase Assignee Assignee Ref
Build Person1 <blank>
Test Person1 <blank>
Implement Person2 or REVTRAC <blank>
• Back to list of Scenarios

Solution B
Scenario #2: Single Person support for an application. This is ongoing.
SoD cannot be met. A Compensating Control is required. (Not valid for SOx applications)
Scenario # 3: A change can only be made straight into the production environment. There is
no test environment.
SoD cannot be met. A Compensating Control is Required.
Implement 3RD PARTY Refer CC

SoD Compensating
Control Email Template
Compensating Control: An email from the CoB Delivery Manager, indicating the:
•Application name
•Reason why SoD cannot be met
•Acknowledgment that the associated risk is known
•Reason why the risk is acceptable
•Time period for which this applies
This email will need to be copied to the GLL Change Management folder for the application’s
changes for the year that this Compensating Control applies.

Solution C
Scenario #4: A one-off case where one person needs to do build, test & implementation activities.
SoD cannot be met. The Delivery Manager needs to be notified of this. (Not valid for SOx
applications)
Implement Person1 Refer CC
After implementation, the implementer needs to notify their Delivery Manager of the situation as to
why they had to do Build, Test & Implement activities. This should be via email.
This email will need to be copied to the GLL Change Management folder for the change
prior to the change being closed.
SoD Compensating
Control Email Template

Solution D
Scenario #5: A Third Party organisation provides all support, including implementation.
SoD within the 3rd Party organisation can be met. A Compensating Control is not required.
Scenario#6: Projects where the Build & Test assignees are AD&P or CoB Project Resources.

Build 3RD PARTY Co. name (person 1) or Project(person 1)
Test 3RD PARTY Co. name (person 1) or Project(person 1)
Implement 3RD PARTY Co. name (person 2) or Project(person 2)
Note: ONLY if Build AND Implement Assignee = 3rd Party, complete the following in the Implement sub
tab of the Access/Sign-Offs tab in ServiceCenter:

Solution E
Scenario #7: A Third Party organisation provides all support, including implementation. SoD within the 3rd Party
organisation cannot be met. A Compensating Control is required. (Not valid for SOx applications)

Build 3RD PARTY Co. name (person 1)
Test 3RD PARTY Co. name (person 1)
Implement 3RD PARTY Refer CC Co. name (person 1)
Note: ONLY if Build AND Implement Assignee = 3rd Party, complete the following in the Implement sub tab of the
Access/Sign-Offs tab in ServiceCenter:
Compensating Control: An email from the CoB Delivery Manager, indicating the: SoD Compensating
•Application name Control Email Template
•Reason why SoD cannot be met
•Acknowledgment that the associated risk is known
•Reason why the risk is acceptable
•Time period for which this applies
This email will need to be copied to the GLL Change Management folder for the application’s changes for the year
that this Compensating Control applies.
Solution F
Scenario #8: If a change to an application needs to be applied by a GITI member. For example, some SAP
instances do not use REVTRAC but have KL Operations apply the change in production. This would work for
non-SAP applications as well.

Build Person 1
Test Person 1
Implement 3rd PARTY GITI KL Ops (person name)
Note: ONLY if Build AND Implement Assignee = 3rd Party, complete the following in the Implement sub tab of the
Access/Sign-Offs tab in ServiceCenter:
Back to list of Scenarios

Test Plan – 2. Test Approach Test Types
Test Types Description
Data Conversion Converting a MS Access database to MS SQL
database, change in database structure
Functional Validation that the change meets to requirements given

by the business
Regression Confirming the change has not introduced a new

defect
Load/Stress Identifying upper boundaries of system (EG. Number of

concurrent users or transactions)
Performance Confirming response times meets expectations
Security Insures groups of users can or cannot access the

application or modules within the application
Interface Testing the communication between multiple

systems

Test Plan – 2. Test Approach Test Levels
Test Levels Concepts

Group of test activities that are organized and managed together.
They are linked to the phases (development, test or production)
IE. Unit testing, Acceptance Testing, Production Verification

Unit Testing
• Testing code to ensure it adheres to requirements
• Normally done in a development environment by a developer
• Considered White box testing (low level testing - testing of separate
components EG. individual code tests, modular tests)
• No formal documentation is required by the Change Process. Some
delivery teams might require documentation during Unit testing but the
standard change process does not.
• No formal defect management is required by the Change Process

Acceptance Testing
• Confirming that the functionality of the change is working to a level where it
is acceptable to be migrated into a production environment
• Normally done in acceptance environment
• Testing is done by a business representative
• Considered Black Box Testing (Also known as functional testing. Black-
box test design treats the system as a "black-box", so it doesn't explicitly
use knowledge of the internal structure for testing)
• ALL defects found must be documented and tracked to resolution using
the defect report. You must document the status of ALL defects (fixed,
closed, open not resolved etc…) The concept is ANY AND ALL defects
found are recorded in the defect report once Acceptance testing has
started
• Formal documents are required (acceptance test scripts, test report and
signoffs)

Production verification
• Verification that the approved change has migrated to the production
environment
• Production verification test script is only required when Acceptance testing
has been waived with a justification
• Production Verification Signoff is required once test is completed

Test Results: Test Scripts
• The test script is a detailed description of how to perform a test:

• The purpose of a test script is to ensure the testing is done in a consistent
manner each time the test is run
• They describe the sequential test steps to be performed, transactions,
data to be used and the expected results
• The data captured from running the test script includes the actual test
script results, pass/fail status and any defects discovered
• Test Scripts are required for Acceptance Testing only.
– If the change can only be tested in production, then a Production Verification
script is required. Unit Testing Scripts are optional.

This Test Report provides an overview of the test results for the
change:
• Describes whether the test results meet the acceptance criteria
and offers a basis for formal business Sign-off
• The template includes:
– the test script names with Status and Date of Executions
– defect summary information
– information on acceptance criteria
– information on compliance to test plan
– a recommendation for moving to production
• Supporting documentation (test script results, defect report)

must be consistent with Test Report

Test Results: Defect Report
Defects need to be recorded if a problem is discovered while executing an

acceptance test script:
• Defects need to be captured in an automated tool or in the provided Excel
templates
– If automated tools are used to capture defects then place link to defects in the
test results document, defect report tab
– Include guest account log on information
• The template should be used as a central repository to manage and report

all defects
• The defect manager should consider limiting access to the central
repository
• Used for tracking defects to its resolution

Team Exercise

ChM - Scenario 4
You are planning to implement an upgrade to an application

which has about 200 users and will require an outage during
non business hours. (Assume a problem/incident ticket has
been opened)
What level change do you think it would be?
What happens?
Consider the process flow, ticket/s created, approvals

and people involved

ChM - Scenario 4 possible solution
Assume problem/incident ticket opened as Level 3.
Register & Assess:
Change Owner (usually Team Lead) opens a change ticket (CT) as soon as possible.
Approve & Plan:
Change Owner starts the planning (resourcing, time required, when to implement, outage
required, and data conversion if applicable)
Close the Plan phase.
Build & Test:
Change assignee completes test plan and test results documents.
Development activities occur outside the Change Mgt process. Change Owner attends the
CAB to review the planning. The change is prepared for move into test environment.
Testing is performed and UAT organised and sign off obtained from business. CO closes
B&T phase.

Authorise & Implement:

Change Coordinator reviews the CT for quality of information & places on CAB agenda.
Assume CC approves.
Change Owner attends the CAB to discuss the change. CAB assesses readiness for move
to prod, ensuring all documentation and signoffs (Operational Acceptance and Data
Conversion if applicable) completed, transition to support done, CNL ready. Assume CAB
approves. Move to prod (SOD applies, i.e. implementer not developer)
Close A&I phase
Change Owner sends CNL to customers if necessary.
Removal of access to production if necessary.
Accept & Close:
Change Owner closes Implement phase.
Verify acceptance with business. (Close Authorise phase).
Close CT.

ChM - Scenario 5
There is a late night call out to the delivery team. Application

X is down and it’s near the closing cycle and this application
is critical to this processing.
What type of change do you think this would be?
What happens?
Consider the process flow, ticket/s created, approvals

and people involved

ASSIGNEE:
Creates an incident ticket.
Creates a related emergency change ticket (may be done after)
Seeks mandatory approval from the ECAB (minimum Delivery lead via email)
Builds change
Tests change
Second individual moves change to production to ensure SOD.
Obtains email approval from ECAB member.
Receives Change ticket approval
Confirms all deliverables and signoffs are complete
Closes CT

Time to “Make it Real”
• List the top three similarities and differences between the new
global Change Management process and your current process
(what you do today)
• What additional information do you need regarding the new
process from us or your SME? (Is something missing)
• What actions do you need to take to prepare for “Go Live” and
follow these processes going forward?

CM Training Module

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CM Training Module

Transféré par

Droits d'auteur :

Formats disponibles

DS BAM Global Processes

For Internal use by Shell

• Fire exits and meeting locations in the event of an alarm

For Internal use by Shell GSP-ChM-2

For Internal use by Shell GSP-ChM-3

For Internal use by Shell

For Internal use by Shell GSP-ChM-6

For Internal use by Shell GSP-ChM-7

– A change outside the agreed ‘Change Window’ (if defined)

For Internal use by Shell GSP-ChM-8

For Internal use by Shell GSP-ChM-9

For Internal use by Shell GSP-ChM-10

• An infrastructure change is any modification to:

For Internal use by Shell GSP-ChM-11

• Addition and/or removal of a printer(s) to/from the system should also be

• Individual changes to a single client desktop as result of incident resolution

For Internal use by Shell GSP-ChM-12

For Internal use by Shell GSP-ChM-13

(Potential) Extent of Impact Potential Business Risk (During

For Internal use by Shell GSP-ChM-14

Note – PAL 4 only, otherwise would be Level 3.

For Internal use by Shell GSP-ChM-15

For Internal use by Shell GSP-ChM-16

can be used Classified as Critical

• Change is being made after business

For Internal use by Shell GSP-ChM-18

1st. Determine Potential Extent of Impact (row) Additional Guidelines:

Scenario 1: Additional Guidelines:

For Internal use by Shell GSP-ChM-20

Scenario 1: Additional Guidelines:

For Internal use by Shell GSP-ChM-21

Scenario 1: Additional Guidelines:

For Internal use by Shell GSP-ChM-22

Scenario 2: Additional Guidelines:

For Internal use by Shell GSP-ChM-24

Scenario 3: Emergency Change

Scenario 3: Emergency Change

The information used to determine impact on the Risk Assessment Matrix is to be

 Financial Impact: >50K >100K >500K

For Internal use by Shell GSP-ChM-27

DAY Tuesday Wednesday Thursday Friday Saturday Monday-Friday

Plan Build Build-Implement Implement Close

Must be Must be in Need to move Must be in Change is Close Service

For Internal use by Shell GSP-ChM-28

• Planned Start and Planned End

For Internal use by Shell GSP-ChM-29

For Internal use by Shell GSP-ChM-30

Per SOx, it is required to have segregation of tasks between staff making a

For Internal use by Shell GSP-ChM-31

For Internal use by Shell GSP-ChM-32

For Internal use by Shell GSP-ChM-33

For Internal use by Shell GSP-ChM-34

DS GSAP/CCAP (preCAB) XCAB

For Internal use by Shell GSP-ChM-35

For Internal use by Shell GSP-ChM-36

• Focal Points assigned by COB – see next slide

For Internal use by Shell GSP-ChM-37

For Internal use by Shell GSP-ChM-38

For Internal use by Shell GSP-ChM-39

• Approval of prior CAB minutes

• Any other business

For Internal use by Shell GSP-ChM-40

For Internal use by Shell GSP-ChM-41

– Requests must be submitted by: