Documente Academic
Documente Profesional
Documente Cultură
Change Management
Copyright: SIPC
Name
Role
Experience with Tools
Copyright: SIPC
<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
<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
Financial Impact
People Impact • Potential impact if change implemented
assessment
unsuccessfully 24x7 service or service
Service
(if you cannot determine Service degraded unavailable in prime
Assessment financial impact) • Potential impact if change NOT implemented
No Impact
in prime hours1 unavailable in non-
hours or during an
prime hours
Determine agreed SAR window
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
Applicable (Dept / Floor / Building / Site)
>300
>50K + >100
or • An estimate of financial impact such as revenue
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
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
Classified as Critical
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
<300
experienceNot during theOR change or 42 3 3 2
window, impact outside the window is
Applicable (Dept / Floor / Building / Site)
>300
considered
>50K + on the
>100 ‘Extent of orImpact’
OR (Main site/Mutiple 3 3 2 1
•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)
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
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
Scenario 2:
Additional Guidelines:
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
Previous history of success
Other factors influencing assessment: None
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
<300
1 Not OR or 42 3 3 2
Applicable (Dept / Floor / Building / Site)
>300
or
>50K + >100
2 OR (Main site/Mutiple
sites/Country/Region/Multiple
3 3 2 1
or >100K + >0 Countries)
>1000
3 >50K + >300
OR or
(Global/Multiple Regions)
3
2 1 1
Classified as Critical
4 or >100K + >100
OR Service (URL) 2
or >500K + >0
This text can be copied into that field, then choose one of the highlighted items for
each bullet.
---------
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.
• 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.
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)
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
• 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
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)
• EU ECAB
• AM ECAB
– Start time all 20.00/21:00 GMT
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
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
End Approve
and Plan
To
End Build and
Test
Process
Authorise
Detailed instructions are available
and
in the Quick Reference Guide.
Implement
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
• 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
For Internal use by Shell GSP-ChM-48
ChM Process - High Level Summary
Monitor
Register and
Change Requested Change
Assess
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)
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
Required Deliverables:
Test Phase •Test Plan (template available)
•Test Scripts (template available)
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
Required Deliverables:
•Test Results (template available)
Implement •Final Acceptance Test Signoff (template
available)
Approve
• Final authorisation to and Plan
promote changes to
production
Build and
• Execution of the Test
implementation plan
Authorise and
Implement
Required Deliverables:
•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
For Internal use by Shell
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.
Yes
Close Phase
Approve
• Post implementation and Plan
review completed
• Final documentation
created and change Build and
ticket is closed Test
Authorise and
Implement
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.
Note : All scenarios are available in the reference section of this pack
C11.8c
Required Deliverables:
FINISH
•Production Verification signoff (template
available)
• 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
• 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)
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)
Compliance Checklist
Testing
Email Signoffs
Global Livelink
Copyright: SIPC
• https://sww-
knowledge.shell.com/knowhow/livelink.exe?func=ll&objId=89605657&objA
ction=browse&sort=name
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/
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 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
GCR00140622
Change tested
before
Implementation
OR
Website Focal Point Anita Bettis Give input on scripts, approve acceptance testing
Quality
Tip: Make
sure you
identify all
the steps
needed in
your plan
Yes
end of
process
• 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
Quality Tip:
Make sure the test
script has all the
steps listed in
enough detail to
ensure thorough
testing.
5.0 Recommendation
• Based on Test Results, select
recommendation to move
change through to Production
environment or not.
When completing the Final Acceptance Testing Signoff Template, you only need to
complete one of the two sections.
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).
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”
• 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.
For Internal use by Shell GSP-ChM-120
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-
knowledge.shell.com/knowhow/livelink.exe?func=ll&objId=51161919&objA
ction=browse&sort=name
For Internal use by Shell GSP-ChM-121
Change Management
• Business Compliance
– http://sww.shell.com/downstream/it/delivery/bam/compliance.html
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.
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.
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
Scenario#6: Projects where the Build & Test assignees are AD&P or CoB Project Resources.
SoD can be met. A Compensating Control is not required.
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.
• Back to list of Scenarios
For Internal use by Shell GSP-ChM-131
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.
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:
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
What happens?
What happens?
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
• 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?