HP/DEUTSCHE BANK Work Instructions

Service Management
Change Management

Hewlett-Packard / DEUTSCHE BANK

L5 / Change Initiator Work Instruction– Emergency Change

Service Management
Change Management
Revision 1.0
15/Jul/2015

REVISION HISTORY

REVISION REVISION DATE APPROVED BY REVISED BY DESCRIPTION

V1.0 15/Jul/2015

Important Confidentiality Notice

This document contains confidential and proprietary information of Hewlett-Packard Development Company, L.P (HP). This document
or any information contained in it may not be disclosed to any third-party without the express written consent of HP. HP and the HP
logo are registered trademarks of Hewlett-Packard Development Company, L.P. HP is an equal opportunity employer and values the
diversity of its people.

© 2013 Hewlett-Packard Development Company, L.P.

Ver 01.00 Nov 2013 Page 1 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

Table of Contents
1 INTRODUCTION.................................................................................................3
1.1 Scope.............................................................................................................................................3
1.2 Target Audience............................................................................................................................3
1.3 Document Objectives....................................................................................................................3
2 ROLES AND RESPONSIBILITIES...........................................................................4
2.1 Change Initiator.............................................................................................................................4
2.2 Change Implementer.....................................................................................................................4
2.3 Change Reviewer...........................................................................................................................4
3 GCM SYSTEM.....................................................................................................6
3.1 Logging into GCM..........................................................................................................................6
3.2 GCM Portal....................................................................................................................................6
4 EMERGENCY CHANGE........................................................................................9
4.1 Emergency Change Definition...........................................................................................................9
4.2 Criteria for Emergency Change.....................................................................................................9
4.3 Raising the Emergency RFC.........................................................................................................10
4.4 Approving the Emergency RFC....................................................................................................10
4.5 Implementing the Emergency Change.............................................................................................11
4.6 Closing the Emergency RfC..........................................................................................................11
4.7 Emergency Change Advisory Board (ECAB).................................................................................12

Ver 01.00 Nov 2013 Page 2 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

1 Introduction

1.1 Scope
This document applies to all Group staff, external staff and vendors supporting the Group’s business operations who are
involved in changes to the Group’s IT Production Environment.

The Change Management (CM) process applies to all changes to applications and infrastructure in the IT Production
Environment. The IT Production Environment includes Production, Disaster Recovery, Controlled Test/UAT and
Development systems and networks which are defined as IT assets.

The process covers changes implemented by all personnel, including those implemented by external vendors or service
providers, whether executed remotely or on site.

1.2 Target Audience

All Deutsche Bank Group staff, external staff and contracted vendors who are involved in requesting, planning, managing,
authorizing and/or undertaking changes to the Group’s production IT environment.

1.3 Objectives
This document details the work instructions for GCM initiators, and staff under the GCM Global Support Model. This will
assist in raising emergency changes and move them across different phases on the GCM tool, Remedy. The document will
help ensure that the RfCs raised are technically sound and adhere to Change Management and ISO policies and standards.
The Change Management KOP document should still be reviewed by all staff.

Ver 01.00 Nov 2013 Page 3 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

2 Roles and Responsibilities

2.1 Change Initiator
The Change Initiator is any individual who submits or ‘initiates’ a Request for Change.  They are overall responsible for the
RFC from inception to conclusion.

The Initiator is responsible for:

• Specifying the activity details, providing sufficient and relevant information on the change.

o Where Non-Prod is the calculated risk, understands that the change will not be reviewed by the Change
Management group and acknowledges his responsibility for permitting the classification of such.

• Ensuring the change does not conflict with any published change restrictions or major events and ensuring no
conflicts against the affected/dependent Configuration Items, if the schedule is known.

• Ensuring appropriate testing details are referenced and available for review by accountable parties, and, where
appropriate, attaching the UAT sign-off report. 

• Adding or ensuring addition of appropriate Approvers, Verifiers or Notifiees.

2.2 Change Implementer

Change Implementers are responsible for performing a change.  Implementation teams must oversee and provide full
governance and closure of tasks as well as to any work being implemented by external contractors or vendors working
under their supervision.

The Change Implementer is responsible for:

• Review of all technical information relating to a RFC Task.

• Ensuring all pre & post deployment, verification, and rollback plans are included as necessary.
Ensuring resource availability for implementation of the task.

• Approving the change or promoting the task accordingly when all implementation and backout details are
assessed and appropriately complete.

• Performing the task once the RFC is fully approved and at the scheduled time.
• Closing the task(s) once the change is validated.

2.3 Change Reviewer

The GCM Reviewer is the first in line to approve an RFC. The Reviewer is generally the Initiator’s approving manager or
representative management group.
The GCM Reviewer:
• Reviews & validates the change, ensuring all required detail is present.
• Updates the RFC, if need be, ensuring detail is understandable and of good quality.
• Validates the calculated risk and ensures that where the change risk is Non-Prod, that it truly meets the conditions of
such.

Ver 01.00 Nov 2013 Page 4 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

• Ensures, where appropriate, testing detail is referenced and UAT sign-off report attached.
• Verifies that the schedule is appropriate with no conflicts to major events.
• Validates that the change adheres to any Change Restriction guidelines.
• Approves or rejects the ticket accordingly.

Ver 01.00 Nov 2013 Page 5 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

3 GCM System
3.1 Logging into GCM
• Go to the GTO TS Production Change Management site (https://crds.gto.intranet.db.com/new/cm/index.html) |
Tools | GCM
• Click on appropriate regional mid-tier server link. (Log in is automatic through WebSSO. If log in does not occur
automatically, you may use LDAP authentication - email address & password.)

3.2 GCM Portal

• Access point for all GCM related actions/activities
• Quick Search and Help available
• Welcome screen provides instructions, announcements and links to support contacts and training materials

Ver 01.00 Nov 2013 Page 6 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

3.2.1 Create
• New RFC – method of creating a new Request for Change (RFC)
• Change Catalogue – contains Standard Change Templates (SCTs) and Preparation for Change (PFC) templates
• New Operating Request – method of creating an Operating Request (OPR) – no risk change

3.2.2 Manage
• My Requests – all requests created by logged-in user available here
• My Approvals – requests pending approval by the logged-in user’s group(s) are available here
• My Implementations – requests pending planning, implementation or closure by the logged-in user’s group(s)
are available here
• My Verifications – requests pending Verification by the logged-in user may be found here
Note: Additional filter options exist within each of the above for further drill-down capability.

3.2.3 Links
• Open Event Calendar – will open the Change Management Event Calendar
• Open ITSM Portal – will open the ITSM Portal (various ticketing systems available)
• Open dbRIB – global reporting system

3.2.4 Templates
• My Templates – display of all templates created by the logged-in user
• Shared Templates – search and display of available/shared GCM templates

3.2.5 Searches
• An RFC or other request type may be found by:
o Entering the request number in the ‘Quick Search’ field at the top of the GCM Portal and clicking Enter
or clicking ‘Quick Search’ located under the Searches link in the margin
• More detailed searching is possible by clicking ‘Search Request-Task’ or ‘Search Request-Task-CI’ under the
Searches link
Note: dbRIB is also a recommended tool for searching and reporting.

3.2.6 Preferences
• Change My Location – area for logged-in user to change/set their location settings
• My Email Subscriptions – area for logged-in user to change email settings
• My Preferred Email – area where logged-in user may change/specify an alternate mailing address

3.2.7 Groups & Users

• Manage Groups/Users – area where logged-in user may manage the groups of which they are the manager or
request membership to groups

Ver 01.00 Nov 2013 Page 7 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

• Lookup Group – a search area allowing a user to search for a group via a group member or search for group
members based upon a group name

Ver 01.00 Nov 2013 Page 8 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

4 Emergency Change

4.1 Emergency Change Definition

An Emergency Change is an incident-driven change required to be performed in order to recover, or to avoid, imminent
negative impact to production service availability, integrity or quality.

Note: Upon selection of Emergency, an Initiator will be required to supply an Emergency Reason, an Emergency
Justification statement, a valid incident in the Related Incident Ticket field and also must supply a sponsoring Director or
Managing Director, requested on the Risk tab.

4.2 Criteria for Emergency Changes

An Emergency Change is an incident-driven change required to be performed in order to recover or to avoid imminent
negative impact to production service availability, integrity or quality (including those that are confirmed would result in
business reputational damage).
For the purposes of this document, Emergency Changes raised in order to avoid an imminent negative production impact
will be referred to as ‘Proactive Emergency Changes’ and those raised to recover production services will be referred to as
‘Retrospective Emergency Changes’.
Proactive Emergency Changes can only be undertaken where there is technical evidence of the a negative production
impact. The impact must be occurring within 24 hours of the incident notification (48 hours if the incident notification
occurs on a Friday or Saturday) and identification of the required change activities. In these cases, Emergency Changes:
 Must be raised prior to the change implementation window, unless the change is required to be performed to avoid a
production impact in the next 60 minutes.
 Must be approved by at least the Reviewer, unless the change is required to be performed to avoid a production impact
in the next 60 minutes.
 Do not require to be fully approved before implementation, but must be fully approved and closed within 3 business
days from the end time of the RFC.

Retrospective Emergency Changes undertaken as a reactive response to an actual service impact (e.g. in order to recover
or stabilize a failed or severely degraded service) must be raised within 24 hours of the change implementation, must be
fully approved and closed within 3 business days from the end time of the RFC.
Emergency Changes can only be raised in relation to an appropriate Incident ticket of dbSymphony Severity Critical, S1, S2
or S3. Incident tickets should be raised in dbSymphony.
Where MAXIMO is the contractually required incident ticket system, then a MAXIMO Priority 1, 2, 3 or 4 incident ticket is
required.
In all cases the related incident reference must be recorded in the appropriate field within the RFC.
Note: For Incidents raised in a system other than DBSymphony e.g. MAXIMO, a screenshot of the associated Incident
Ticket must be attached to the RFC. This is required for transparency, where the GTO TS Production Change Controllers do
not have the capability to access and validate Incidents raised in systems other than dbSymphony.

Ver 01.00 Nov 2013 Page 9 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

4.3 Raising (Initiating) the Emergency RFC

4.3.1 Proactive Emergency Changes
The Change Initiator must raise the RFC in GCM as soon as possible to ensure that change management process
governance can be undertaken.
Proactive Emergency Changes, where time is of the essence, should be raised with ‘Planned’ Tasks to avoid delays in
having the Implementer promote the RFC Tasks to a Reviewed state.
Normal MD Approval requirements (see section Error! Reference source not found.) apply to Proactive Emergency
hanges.
If the emergency change is being raised for implementation by IBM (MITSA contract), then IBM Incident Management
(+49 69 910 6645 5555) must be contacted and informed of the change prior to the change implementation. If no Maximo
incident ticket is available, a screenshot of the dbSymphony incident ticket must be provided to IBM Incident
Management.

4.3.2 Retrospective Emergency Changes

A Retrospective Emergency Change must be raised no later than 1 business day post completion of the change
implementation.
MD Approval requirements (see section Error! Reference source not found.) still apply to Retrospective Emergency
hanges, however, there are two ways in which the MD Approval group(s) may be included. The MD approval group(s) may
be added as Change Notifiers (i.e. the MD approval group(s) will be notified of the Emergency RFC but will not be
explicitly required to approve it) or the MD approval group(s) may be added as an/a Approver(s).
If the emergency change is being raised for implementation by IBM (MITSA contract), then IBM Incident Management
(+49 69 910 6645 5555) must be contacted and informed of the change prior to the change implementation. If no Maximo
Ticket number is available, a screenshot of the dbSymphony incident ticket must provided to IBM Incident Management.

4.4 Approving an Emergency RFC

10.3.1 Proactive Emergency Changes

Proactive Emergency Changes RFC tickets must be approved by at least the Reviewer, unless the change is required to be
performed to avoid a production impact in the next 60 minutes.
Full RFC ticket approval prior to the implementation start time is not mandatory for Emergency Changes. However,
appropriate efforts should be made to gain as many of the required approvals before the implementation.

10.3.2 Retrospective Emergency Changes

Retrospective Emergency Change RFC tickets must be fully approved within 3 business days of the Emergency Change end
time.

4.5 Implementing the Emergency Change

There are a number of situations where an Implementer may be requested to implement an Emergency Change before an
RFC ticket has been created. These include:

Ver 01.00 Nov 2013 Page 10 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

 Where there is a current production service impact and the change is required to be executed in order to restore
service.
 Where there is an imminent (e.g. within next 60 minutes) production service impact and raising the RFC ticket would be
detrimental to the ongoing avoidance activities.

In these cases, i.e. where the Change Implementer does not have an RFC to reference, then:
 The Change Implementer may take verbal authorization from a designated GT Production Incident Manager (where an
Incident Manager is actively involved in managing the associated production service impact).
 Where a GT Production Incident Manager is not involved, the Change Implementer may accept an email request to
perform the change on the basis that the email request :
o Contains the detail of the change required to be performed.
o Contains the corresponding IN number
o Contains the reason the RFC ticket cannot be raised.
o Contains confirmation or evidence that a production service impact will occur in the next 24 hours (48hours at
weekends) if the change is not implemented.
o Is copied to the Change Requestor’s Line Manager and an associated Director/MD for their area.

In a situation where the Change Implementer has any concerns around the validity or technical/operational viability of
the change being requested via email, then they should escalate these concerns immediately to their supervisor/line
manager or ‘Manager on Duty’.
Where IBM are the implementer of the Emergency Change, it is the responsibility of the IBM implementer to ensure the
IBM Incident Management team has been informed of the change prior to executing implementation activities. Note:
Where the GT Retail Manager on Duty (MoD) requirement/process exists, the Emergency change must be approved by
the MoD before implementation, and the email approval of the MoD must be attached to the Emergency RFC.

4.6 Closing the Emergency RFC

The Change Implementer must enter the actual start and end times when the change was implemented, and close each
task.
The Emergency Change RFC ticket must be fully approved and closed within 3 business days of the change end time.

4.7 Emergency Change Advisory Board (eCAB)

The eCAB exists to ensure that all emergency changes being implemented within the next 24 hours are valid and adhere
to the emergency criteria/requirements stipulated above. Overall, it exists to prevent invalid emergencies from taking
place.
Change Controllers review all RFCs with an Urgency of Emergency, including those in Draft status. Checks performed
include:
 The presenece of an Incident number in the “Related Incident Ticket” field within GCM.
 The Incident is of a Severity 3 or greater level.
 The Incident description correlates to the description within the RFC.

o Where the Incident reference from a supported Incident management tool cannot be validated, a screen shot of the
incident must be attached to the RFC.

Ver 01.00 Nov 2013 Page 11 of 12

For internal use only

 HP/DEUTSCHE BANK Work Instructions
Service Management
Change Management

 The presence of testing evidence, where applicable.

 The presenece of necessary approvers on the GCM ticket.

When approving proactive emergency RFCs (production impact within 24 hours or 48 hours if notification occurs on
Friday or Saturday) the following checks in addition to the above are performed:
 Presence of technical evidence of the impact occurring in the form of one of the following:
o Screen shots of monitoring or diagnostic applications or toolsets (i.e. Tivoli, Geneos, HP Sym, etc.)
o Output from automated or manually run application health check scripts, diagnostic check commands or
application/system dumps.
o Vendor generated Incident tickets, cases, and/or analysis
 Change reviewer has approved the change (if production impact is within the next 60 minutes, this is not required).

If any of the above is not met, the RFC is either Rejected or Cancelled.

L5 Emergency
Change.pptx

Ver 01.00 Nov 2013 Page 12 of 12

For internal use only