environment must occur when no test bed is available. Every change will have a test or validation plan in place. implementation requires risk analysis and approval. All Changes to the production environment will be made within agreed Change windows. Any exceptions will be agreed and communicated. To ensure that service downtime to implement changes is done during agreed and communicated timeframes. Reduces impact to the users and allows them to plan their work according to communicated service outage windows. All changes that impact service capability will be assessed for performance and risk and resources needed to implement the Change. Based on the assessment, categorization will be used to identify the level of authorization required for a Change. To ensure that a Change is assigned a category. This will provide the information required to define the level of authorization. Provides increased customer availability and ensures proper authorization levels for changes Standard Changes must be implemented the accepted and established procedure. All Standard Changes will be recorded in the Change logging system. Standard Change processes and associated Change workflows should be developed and communicated to ensure that such Changes are efficiently processed to support the organization’s business needs. Ensures efficient and prompt handling of Change requests. Improves customer service levels All Emergency Changes will be reviewed at the CAB in retrospect. Assessing the effectiveness of an Emergency Change. To ensure there is effective oversight and review of Emergency Changes and proper communication. Every Change will receive a post implementation review. All less than successful changes will receive a more extensive review. Clarify the responsibility of the CAB to perform Post Implementation Review for all Changes after they have been implemented. Assures that all Changes are reviewed for learning opportunities after they are implemented. Change Management metrics and management reports will be provided to Management and Customers in accordance with outlined procedures and agreements. Assessing performance measures (e.g., efficiency and effectiveness) of the Change Management process. Communicates Incidents and Problems as a result of a Change Provides trend analysis Identifies opportunities for improvement
7.0 Emergency Change An Emergency Change is a change that must be introduced as soon as possible; for example, to resolve a Major Incident or implement a critical security patch. The Change Management Process includes a specific procedure for handling Emergency Changes. 8.0 Standard Change Standard Changes are changes that are repeatable, occur frequently, and are proven to be low risk. A pre-defined workflow will be established, approved by the CAB and subsequently followed. Approved Standard Changes are not reviewed by the CAB. Record and Review Process This section describes the Record and Review Process. Record and Review Process Flow 1.0 Record and Review Process Activity Descriptions D.1.1 Emergency Change? Purpose To determine if the Change is an Emergency. If the Change is an emergency, events will be handled by the separate Emergency Change Process Decision Yes – Go to 8.0 Emergency Change Process No – Go to 1.1 Create Change Record 1.2 Create Change Record Purpose To ensure all Changes are appropriately recorded in the ITSM Tool. Requirement Statement When recording a Change Record, it is the responsibility of Tier 1 to correctly complete all of the required information. Input Request for Change
No – Go to 1.6 Notify Requestor 1.5 Notify Requestor Purpose To inform the Requestor that the RFC has been rejected. Requirement Statement When advising the Requestor of the outcome of their RFC, it is the responsibility of the Change Coordinator, Change Manager and Tier 1 to provide them with the required information. Input Change Record Procedure or Work Instruction Steps Contact the Requestor and inform them that their RFC has been rejected Note that an RFC will not be reopened. A new RFC must be submitted Update the Change Record Output Notification to Requestor Updated Change Record Metric Number of rejected RFCs 1.6 Notify Requestor Purpose To inform the Requestor that the RFC has been accepted. Requirement Statement When advising the Requestor of the outcome of their RFC, it is the responsibility of the Change Coordinator, Change Manager and Tier 1 to provide them with the required information. Input Change Record Procedure or Work Instruction Contact the Requestor and inform them that their RFC has been accepted Change status of the Change Record to Accepted Output Notification to Requestor Updated Change Record Metric Number of accepted RFCs D.1.7 Standard Change? Purpose To determine if this is a standard pre-approved change using the compiled list of standard pre-approved changes.
D.7.9 Test Successful? Purpose To determine the success of the test. Decision Logic Yes – Go to 7.11 Coordinate Change Implementation No – Go to D.7.10 Continue Building Change? D.7.10 Continue Building Change? Purpose To determine if the Emergency Change should continue being built in the event of an unsuccessful test. Decision Logic Yes – Go to 7.6 Prepare Change & Remediation Plan, if Possible No – Go to D.7.1 Convene OIT CAB 7.11 Coordinate Change Implementation Purpose To ensure that the Emergency Change can be implemented at a reasonable time given the circumstances. Requirement Statement When implementing an Emergency Change, it is the responsibility of the Change Coordinator to coordinate the Change without impacting the business and without conflict with Changes in the Change Schedule. Change Record or Approved Emergency Change Test Results Procedure or Work Instruction Verify no conflicting changes on schedule Resolve any conflict based on Priority of all conflicting changes Attempt to identify new target dates if conflicts occur, given the urgency of the Change Schedule an official production date and update the Change Schedule. Update the Change Record Output Updated Change Schedule Updated Change Record Metric 7.12 Deploy Change
7.0 Emergency Change Process RACI Matrix An authority matrix is a tool used to help understand which parties need to be involved in changes and their level of involvement. Process Roles Activities Within Process Change Mgmt Process Owner Change Manager Change Coordinator CAB ECAB Change Tester Change Implementer User Tier 1 7.1 Convene OIT ECAB A R C C C I I 7.2 Assess Impact, Risk, Timing, and Urgency A R R/C C C C C I 7.3 Record Change if Time Allows A R C C/I D.7.4 Emergency? A R C C C I D.7.5 Approved? A R C I I I 7.6 Prepare Change & Remediation Plan, if Possible A R C C/I C/I I D.7.7 Time for Testing? A R C C C I 7.8 Conduct Emergency Testing A C C R C I D.7.9 Test successful? A R C C I D.7.10 Continue Building Change? A R C C C C/I I 7.11 Coordinate Change Implementation A C R C I I 7.12 Deploy Change A C C R I I D.7.13 Produced Expected Results? A R C C I