Vous êtes sur la page 1sur 8

Change Management Emergency or Latent Change Procedure

Change Management
Emergency and Latent Change Procedure

Version 1.1

1
Change Management Emergency or Latent Change Procedure

Table of Contents
1.0 About This Document .................................................................................................................... 3
1.1 Document Objective .................................................................................................................. 3
1.2 Summary ................................................................................................................................... 3
1.3 Target Outcomes....................................................................................................................... 3
2.0 Emergency Change Procedure Map ............................................................................................. 4
3.0 Latent Change Procedure Map ..................................................................................................... 5
4.0 Emergency Change Procedure ..................................................................................................... 6
5.0 Latent Change Procedure ............................................................................................................. 7
6.0 Change Approving Authorities ...................................................................................................... 8
5.0 Questions and Comments............................................................................................................. 8

Revision History
Author Version Description Date
Steve Lane 1.0 Document Creation January 20, 2014
Gemma Tungul
Sandy Stout
Gemma Tungul 1.0 Update Document links to Sharepoint June 4, 2014
Site 2010
Ken Merkel 1.1 Update document information to September 18, 2015
Sandy Stout current procedure and update links
Gemma Tungul within.
Caroline Schulte
Sandy Stout 1.1 Update links within Feb. 4, 2016

2
Change Management Emergency or Latent Change Procedure

1.0 About This Document

1.1 Document Objective


The Change Management Emergency and Latent Change Procedure document provides information on
how to process Emergency or Latent changes.

1.2 Summary
Emergency or Latent change is used to resolve an identified Incident or Problem, or in some cases, to
prevent an incident or problem from happening
The procedures below will be used to process changes depending on the urgency of the change which
can be submitted in two different ways.

1. Emergency Change (See 4.0 Emergency Change Procedure)


This type of change would be completed during business hours with normal change requirements
but normal lead times and Change Board requirements do not apply. Change Management
approval and Service Owner or an Alternate Change Approving Authority approval is required
prior to implementation. A ticket must be created prior to implementation.

2. Latent Change (See 5.0 Latent Change Procedure)


This type of change could be completed during business hours or outside of business hours and
is only used when, due to the urgency of the situation, the change needs to be implemented
immediately. A ticket must be created after the change has been implemented, and approval
from the Service Owner or an Alternate Change Approving Authority must be attached to the
ticket.

Where applicable, Emergency and Latent change request records should ultimately be related to an
Incident or Problem record.

For more information check the Change Board Terms of Reference.

1.3 Target Outcomes


Provide the standardized procedure for Emergency and Latent Changes.

3
Change Management Emergency or Latent Change Procedure

2.0 Emergency Change Procedure Map

4
Change Management Emergency or Latent Change Procedure

3.0 Latent Change Procedure Map

5
Change Management Emergency or Latent Change Procedure

4.0 Emergency Change Procedure


Change Coordinator or Change Implementer
1. Creates a change request (CR) using the change “Class” of Emergency.
2. Ensures the following information has been added to the work info:
 Risk Assessment
 Service Impact Assessment
 Install Plan
 Back out Plan
 Test Plan
 Communication Plan
 Scheduled start and end dates
3. Submits the CR for review and approval by the Change Manager.
4. Contacts their Change Manager to inform them of the change.

Change Manager
5. Reviews the change request for its completeness.
6. Approves the CR, and moves forward for Emergency Change approval.
7. Contacts the Change Approving Authority advising them the change is waiting their approval.
8. The Emergency Change Approving Authority reviews and approves the change (either in ITSM or
by email).
9. Ensures the approval is in the ticket.
10. Change request is moved to scheduled.

Change Coordinator or Change Implementer


11. Change is implemented.
12. Updates the change request with actual start and end dates and an Install Results entry in the
Work Info.
13. Moves the ticket forward for final review.
14. Change Manager performs a Post Implementation Review (PIR) on the change and closes the
ticket.

Note: If change is chosen to be communicated then follow the normal Change Management
Communication Procedure.

6
Change Management Emergency or Latent Change Procedure

5.0 Latent Change Procedure


Change Coordinator or Change Implementer
1. Contacts the Change Approving Authority for approval.
2. Once approval is received the change is implemented.
3. Once the change is implemented, creates a change request (CR) using the change “Class” of
Latent.
4. Ensures the following information has been added to the work info:
 Change Approving Authority approval
 An entry identifying what was done and why.
 An Install Results entry.
5. Adds the actual start and end dates to the CR.
6. Moves the CR forward for final review.
7. Change Manager performs a Post Implementation Review (PIR) on the CR and closes the CR.

7
Change Management Emergency or Latent Change Procedure

6.0 Change Approving Authorities


The Emergency or Latent Change Approving Authorities are as follows:

1. The Service Owner of the team implementing the Change.


2. If the Service Owner is unavailable, then the Team Director/Manager of the team implementing the
Change.
3. If the Team Director/Manager is unavailable, then the Team Lead.
4. If the Team Lead is unavailable, and the change must be implemented to restore a critical service,
then the decision to proceed is left to _SA CIM Team (Corporate Incident Management).

5.0 Questions and Comments


Questions or comments about this document in general can be directed to the ICT Change Management
via email at ict.change@gov.ab.ca.

Vous aimerez peut-être aussi