IT CHANGE MANAGEMENT Enterprise Change Management Process

Preparing to load PDF file. please wait...

0 of 0
100%
IT CHANGE MANAGEMENT Enterprise Change Management Process

Transcript Of IT CHANGE MANAGEMENT Enterprise Change Management Process

UCSF IT Change Management

Enterprise Change Management Process Version 4.0 | 11/17/2020

IT CHANGE MANAGEMENT
Enterprise Change Management Process

VERSION: 4.0

REVISION DATE: 11/17/20

Page i

UCSF IT Change Management

Enterprise Change Management Process Version 4.0 | 11/17/2020

Contents
About this Process Document.............................................................1
1.1 Intended Audience ...................................................................................1 1.2 Assumptions ............................................................................................1
Change Management .........................................................................2
2.1 Change Management Description ...........................................................2 2.2 Change Management Objectives ............................................................2 2.3 When to Submit a Change Request ........................................................2 2.4 When a Change Request is Not Required...............................................3 2.5 Types of Changes....................................................................................3 2.6 Major Activities within Change Management...........................................4
UCSF Change Management Organizational Hierarchy......................6
Roles and Responsibilities..................................................................7
4.1 Operational Roles ....................................................................................7 4.2 Supporting Roles .....................................................................................9
Requesting a Change .......................................................................10
5.1 Submitters ..............................................................................................10 5.2 Information Required to Create a Change request................................10 5.3 Review and Approval .............................................................................11 5.4 Status and Status Transitions................................................................14
Implementing the Change.................................................................15
6.1 Change the Status .................................................................................15 6.2 Enter the Actual Start Time....................................................................15 6.3 Document activity in the Work Log ........................................................15
Closing a Change .............................................................................16
7.1 Update the Result Codes.......................................................................16 7.2 Work Log................................................................................................16 7.3 Update the Configuration Item...............................................................16 7.4 Enter the Actual End Time .....................................................................16 7.5 Post Implementation Review .................................................................16 7.6 Close the ticket ......................................................................................17
Limited Change/Blackout & Heightened Alert-Critical Event Windows18
8.1 Limited Change/Blackout /Heightened Alert-Critical Event Description 18 8.2 Obtaining Initial Approval .......................................................................18 8.3 Submitting a Limited Change/Blackout Window Request .....................18 8.4 Notification of Window ...........................................................................19

Page ii

UCSF IT Change Management

Enterprise Change Management Process Version 4.0 | 11/17/2020

8.5 Submitting a Change Request during a Window ...................................19 Measuring Success...........................................................................20 Reporting ........................................................................................... 21 Definitions .........................................................................................22 Process Advisory Team / Governance .................................23
Document Version Control ..............................................................................24

Page iii

About this Process Document
1.1 Intended Audience
The document should be read by anyone working within the UCSF Enterprise Change Management process. It should be used to maintain a standard set of practices so that anyone impacted by the practice (customers and providers) have common expectations.
1.2 Assumptions
• Only authorized individuals can perform change management functions, as explicitly outlined in the proceeding change management policy. In the absence of specific requirements thereunder, no undefined action may be taken without prior approval from the Service Transition Process Manager/Change Manager. Furthermore, no authorized or unauthorized individuals may intentionally or unintentionally circumvent the change policy whatsoever, without getting prior approval from the Service Transition Process Manager/Change Manager.
The change management policy is a living document, which is continuously subject to revisions. At times the change management policy might not be in sync with the functional automated control. Therefore management will notify UCSF employees and HCL members of a change management process; addition subtracted or modified in expressed writing via email. Management may reinforce the change in policy during CAB and ECAB meetings, as all change in policy notifications will be fully binding as to if they have been already inserted into the change policy.
• Standard Change Requests are only authorized to be used for the purpose they were approved. • A single, common Enterprise change management process is adopted and applied by each
business (ITS, Medical Center, SOM). • The change management process assumes a tool-agnostic approach. The process was not
designed around the capabilities of any specific tool set, but requires any tool used by UCSF to support the process. • Appropriateness of the change was vetted before a change request is created. Any change that is submitted in the change management system is assumed to be an approved change by the business or application owner. • The number and type of approvals required by workflow in the change management system are dependent on the risk level of the change. • The intent of the change management system is to manage change. Separate ITIL processes such as Incident, Request, and Release and Deployment Management should be managed by systems that integrate with Change Management. • An implementer (assignee) cannot approve their own change. • The individual listed as the assignee on the change is expected to be the person actually implementing the change. In cases where a cross-team, collaborative effort is required to implement, the assignee is the person responsible for coordinating the implementation activities. • A change request cannot go to Work In Progress (WIP) status before the Planned Start Date/Time. A change request is required for any change to production. The business may predefine instances where a change request is not required, but the overriding assumption is that any change to production requires a change request even if the implementer is certain that “there is no risk and the change will not impact anything.” Perceived impact does not affect the requirement.
Page 1

Change Management
2.1 Change Management Description
Change Management is the process to manage the introduction of any enhancement, modification, update, installation, or removal of any hardware, software, interface, or database, or document that will impact the existing production environment. It ensures that only approved modifications to the environment are implemented. The change process should provide high visibility and open lines of communication between functional teams and the business. It should provide common expectations and ensure accountability.
2.2 Change Management Objectives
2.2.1 Primary Objectives The primary objectives of change management are:
• To protect the UCSF infrastructure environment • To control the introduction of changes to the production environment • To ensure the outcome of the change meets expectations
2.2.2 Operational Objectives The operational objectives of a change management program are:
• Assess the impact associated with all changes • Design to calculate the potential impact a change could have on the UCSF production environment • Design questions to confirm, or in some cases define the type of change that is taking place • Define the level of approval required for a change • Minimize any negative impact resulting from a change • Communicate all changes to affected groups • Act as a method of accountability • Measure and track all changes to the production environment • Meet contractual or regulatory requirements • Meet or exceed IT audit requirements • Meet or exceed IT Service Level Agreements
2.3 When to Submit a Change Request
A change request should be submitted for all enhancements, updates, maintenance, relocations, installs, de-installs of managed configured items in the UCSF production environment including: • Resource or System Account • Moves, Adds, Changes and Deletes – Changes to system configuration. • Schedule Changes – Requests for creation, deletion, or revision to job schedules, back-up
schedules or other regularly scheduled jobs managed by IT. • System hardware • System software • Network hardware including cabling, connectors, adapters, etc. • Network software including configuration settings • Database including table adds, deletes, re-organization, or maintenance as well as database
content. • Applications • Telephony • Adding, deleting or revising security groups
Page 2

• File permission change • Documentation such as Business Continuity Plans, Policy and Procedures, Maintenance
agreements, Service Level and Operational Level Agreements (SLAs and OLAs). • For a documented, critical priority incident in an open status
• A change should be submitted for anything that results in a change to the configuration. This ensures that all configuration changes (planned and unplanned) are documented in one place.
• A change should be submitted if rebooting a device is required to restart one service when other services are running, or when all services on a device are stopped and a reboot is required to restart.
2.4 When a Change Request is Not Required
There are many IT tasks performed either by IT or by the end users that do not fall under the process and procedures of Change Management. Tasks that are outside the initial scope of the Enterprise Change Management process include: • Changes to non-production elements or resources • Changes made within the daily administrative process. Examples of daily administrative tasks include but are not limited to:
- Password resets of non-critical user accounts - User add/deletes - User modifications
 Adding, deleting or revising AD or Unix group changes  File permission change - Desktop support tasks (software installs/un-installs such as Word, Excel, etc.) • For other departmental Director approved changes to production, which individual department determines as unnecessary to track via change request, they are to be documented in a knowledgebase article, signed off by Director, with notification to Enterprise Change Manager and IT Service Management Department Leadership, who will review the request.
The Change Advisory Board (CAB) may modify the scope periodically to include items in the scope of the Enterprise Change Management process.
2.5 Types of Changes
2.5.1 Standard A change that is part of the daily routine, is considered low risk, and has a predictable outcome may be pre-approved. The business objective for a Standard, Pre-approved change is to ensure that Standard changes receive an appropriate level of review while also minimizing restrictions. The criteria for standard, pre-approved changes are, as follows:
• The change must be a repetitive, Standard activity. Examples can include (but are not limited to): o Regularly scheduled, recurring therapeutic server reboots o Firewall adds o Regularly scheduled maintenance activities
• The change’s calculated risk level must equal Low. • The change must meet lead time requirements. • The change must initially be represented in CAB.
o Pre-approved changes will not require the same level of scrutiny as other changes but must be presented at CAB for approval to convert a change to Standard.
Page 3

• Any Standard change that causes an unplanned outage goes under immediate review and possibly pulled from being Standard. 2.5.2 Normal
A Normal change is one that is submitted, fully documented, and approved at the IT Director level (if required) and below and has an implementation date that allows discussion at the next regularly scheduled CAB meeting.
2.5.3 Expedited An Expedited change is one that does not have a scheduled implementation date that allows discussion at the next scheduled CAB. An Expedited Change will need to be reviewed and approved electronically.
2.5.4 Emergency A change that is directly related to a critical priority incident and that must be implemented in order to restore service is an Emergency change. Emergency changes are auto-approved based on the following criteria • The change is related to a high or critical priority incident • The related incident is in a non-closed status
2.5.5 Latent A change that is logged after implementation and did not follow the Change Management process. A PIR is required for latent changes and must be reviewed with Group Manager. A Latent change is also known as an unauthorized change!
2.6 Major Activities within Change Management
2.6.1 High level Process Map
2.6.2 Request a Change A change must be recorded in the change management system. It can be initiated within the incident management process, through a formal request in a request management system, through email, project, problem record or any other method where a need for a modification to the production environment is required. The result is a numbered Change Management Record (CMR) in a change management system.
Page 4

2.6.3 Approve Modifications to the environment should only be implemented after the change is approved through a formal approval process. In some cases, changes may be pre-approved. In most cases, changes will need to be reviewed and approved by a peer and manager. With exception of Emergency Changes, which are pre-approved, all other changes are to be reviewed and approved by CAB or ECAB.
2.6.4 Schedule Approved changes should be added to a Change Calendar so IT resources and customers can plan for upcoming modifications to the environment.
2.6.5 Implement The change should be implemented within the approved window. Modifications should be limited to only those move/add/change/delete activities that were reviewed and approved. Modifications outside of the scope of the approval should not be made. Once the change has been made and validated, the assignee should place the change request in a “Closed Pending Review” or “Closed” status.
2.6.6 Review The Change Manager should review closed changes to ensure that changes were implemented as scheduled and that they produced the expected results. A regular review will ensure a continual improvement in the quality of changes.
Page 5

UCSF Change Management Organizational Hierarchy
Page 6

Roles and Responsibilities
This section describes the roles and responsibilities to be performed by the individuals participating in the Change Management process.
4.1 Operational Roles
4.1.1 Change Requestor
An IT requestor may open a change request directly. A non-IT requestor must open a request ensuring that the details of the change are accurate and appropriately reflect what is required. The person initiating the change must have a clear rationale for the change’s purpose and be able to clearly articulate that in the request or change request.
4.1.2 Assignee
The person who will be executing the change (the Assignee) is ultimately responsible for successfully completing the change, as well as:
• Submit or update the change management system’s Change Management record with all required information.
• Allot sufficient time for analysis, stakeholder approvals and notifications before the Planned Implementation Start Date.
• Provide detailed and accurate documentation for all proposed changes. • Coordinate and schedule changes to occur during maintenance windows, whenever possible. • Obtain technical Peer Review and other required approvals prior to the implementation time. • Represent the change to the CAB or ECAB as appropriate or alternatively, arrange for someone who can
adequately represent the change to attend. The delegate must be familiar enough with the details of the change to answer any of the questions asked during the CAB. • Facilitates the review of an expedited change by alerting all required parties to the change, scheduling and facilitating the change review, and ensuring that the Change is set to scheduled status prior to its implementation time. • Ensure that any tasks within the change are completed as planned by the task assignee. • Implement the change as planned (no more, no less), including validation, and close the change before the scheduled end date/time if able to do so, but, no later than 24 hours of the Change execution. • Update the change request with installation notes, status changes, and results. • Update any Configuration Items (CIs) in the CMDB that may arise as a result of a change. • Participate in a Post Implementation Review (PIR) for all emergency changes and changes that were BackedOut, Incomplete, Completed with Issues, or Latent Changes.
4.1.3 Peer Reviewer
The peer reviewer is someone on the Assignee’s team with equal knowledge of the environment where the Change will take place. The peer has the following responsibilities:
• Review the details of the change plan to ensure the technical steps planned are complete and change is correct.
• Review the back out and validation plans to ensure there is sufficient detail to be effective. • Represent the change during CAB or ECAB if the Assignee is unable to do so. The peer must be familiar
enough with the change to answer any of the questions that may be asked during CAB. • Back up the assignee during the actual implementation.
4.1.4 Group Manager
Typically, the technical supervisor or team lead has the role of the Group Manager, and has the following responsibilities:
• Review all changes for the Assignment Group for accuracy and approve those that meet scheduling and resource requirements.
• Ensure that the plan includes the requirements for communicating the change to stakeholders. • Represent the change during CAB or ECAB if the Assignee and Peer are unable to do so. The Group Manager
must be familiar enough with the change to answer any of the questions that may be asked during CAB. • Work with the Change Manager when required to coordinate or validate a change’s planned implementation
schedule.
Page 7
ChangeChange RequestCabAssigneeRequest