INFORMATION AND EDUCATIONAL TECHNOLOGY

Transcription

1 INFORMATION AND EDUCATIONAL TECHNOLOGY IET Change Management Process Model This document describes the IET Change Management Process. The process seeks to minimize business risk during a change to a service, service component, or supporting infrastructure. This document may be used by: UC Davis colleges, functional units and customers who want to understand generally accepted good practices for IET Change Management. Organizations that want to align with the IET Change Management process model. Note: Some elements of this model are specific to the IET implementation in the ServiceNow change management system. Page: 1 of 15

2 Table of Contents Process overview...3 Objective...3 Value to customers...3 Scope...3 Out of Scope...4 Process roles...5 Change Management process model...6 Risk Levels and Lead Times...9 Change Management Flow based on Risk Levels...11 LEAD TIMES...11 Change categories, Change Types and workflows...12 Change Categories...12 Planned Changes...12 Emergency changes...12 Change Advisory Boards...12 Architecture Review Board (ARB/TCAB)...12 Deployment CAB (DCAB)...13 Emergency CAB (ECAB)...13 IMPLEMENTATION ISSUES...13 Appendix...15 Appendix B required documentation...15 Page: 2 of 15

3 PROCESS OVERVIEW IET Change Management is a systematic approach that defines the process and implements the procedures for recording and tracking the details of the service environment as it undergoes change. Maintain high quality service to customers Maintain the integrity of the IT production environment Provide effective communications about all changes Provide a single set of procedures, a change management tracking system and a common database for managing change Ensure all changes are tested appropriately, based on risks such as their complexity, possible impact, and ability to be backed out Provide an approval process to manage and administer all changes Improve the effectiveness of change management processes, procedures and tools over time OBJECTIVE The overall objective of Change Management is to make sure that all changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. VALUE TO CUSTOMERS Change management value can be summarized in two main benefits. The business is protected from any negative effects related to change The business gets the improvements that they need SCOPE The addition, modification, or removal of services or service components will be subject to the change management process. This includes, but is not limited to: Application software Application servers Communications equipment and software Databases or components supporting data storage and retrieval Facilities and environmental components used in connection with the delivery of IT Services Global software pushes System Hardware System Software Network infrastructure components supporting hosted services Page: 3 of 15

4 OUT OF SCOPE Changes which have significantly wider impact than service changes or day to day operational tasks required for service and system operations: Application changes to development environments Build-out of servers/environments that are not part of current production or test environments and to which changes would in no way affect or impact production or test environments. The modification of existing, or the creation of new, software plans and procedures relevant to the running, support, and maintenance of systems and services File restores, data modifications, user managed application or infrastructure modifications which do not affect the functionality, data structure, or modify the output of a managed system Changes at an operational level such as repair to printers or other routine service components Addition, deletion, or modifications performed at the individual workstation level. Changes with significantly wider impacts than service changes, e.g. departmental organization changes, policies, and business operations Changes to web site content which are controlled via departmental policies and procedures Page: 4 of 15

5 PROCESS ROLES Each person who interfaces with the IET Change Management process has a role and associated responsibilities that must be executed in order for the changes to be successfully implemented: Role Description The Change Approver reviews the Request For Change (RFC) using a risk based perspective. The change approver role may be performed by an authorized manager, supervisor, technical lead, or approval board. The change approver cannot be the same person as the Change Requestor. More than one change approver may be required for a change request, depending on risk, impact and urgency of the change. Responsibilities include: Change Approver Reviewing all change documentation Confirming that all required assessments (risk, impact, technical, business, operational) are complete Verifying that testing has been completed Verifying that production support is aware of the change Verifying that back-out plans have been developed Approval or rejection of the RFC The Change Requester is the person who creates RFC s for IT service components. Change Requester The responsibilities of the Change Requester are to: Provide appropriate information to the required Change Approvers Ensure that the RFC is provided to the support staff so it can be entered into the Change Management Tracking System, and that it meets the qualifications for the change request, based on the risk level of the change. Obtain proper approval for Emergency Changes. Ensure that the change is Implement by Change Implementer(s) consistent with the approved plan and RFC The Change Implementer in each support organization is the resource for change execution and is responsible for the installation and deployment of a change or change task. Change Implementer(s) Responsibilities include: Participate in the assessment and planning of the change CAB attendance Implementing the change Providing status of all changes in progress Remediating and backing out a change if necessary Updating the RFC records with appropriate information and status Closing assigned tasks within the scheduled date/time of the change Page: 5 of 15

6 Role Description The Architecture Review Board provides assessments of changes for consistency with IT architectural standards, future direction and governance requirements. Architecture Review Board (ARB) Responsibilities Include: Evaluate projects and related changes requests for compliance to established architectural criteria and business objectives Communicating architectural requirements and compliance checklists to projects in advance of development and change activities Providing guidance to project stakeholders to meet architectural conformance requirements Approval / rejection of proposed architectural changes The Change Advisory Board (CAB) authorizes and approves or rejects changes before they are implemented and assists with the prioritization, coordination and scheduling of changes. Change Advisory Board (CAB) Responsibilities: Establish change management standards, policies and procedures Review changes for compliance to Change Management process requirements Oversee change schedule risks Establish the forward schedule of changes (FSC) Define change classifications Standard, Comprehensive (Normal), Emergency Review failed changes to ensure corrective actions are implemented Authorize emergency change procedures Provide change management reporting for continual improvement CHANGE MANAGEMENT PROCESS MODEL The IET Change Management process model illustrates the standard flow of activities. The actual steps followed will be determined by the change classification. Depending on the classification, some activities will be bypassed or enhanced. (See below for Change Classifications and Workflow details). Page: 6 of 15

7 Change Entry in ServiceNow (RFC) The key objective of the Change Entry is to capture information about all change requests to be considered for implementation to any IT production system, prior to the changes being made. In addition, this activity provides a standard method of capturing change requests through ServiceNow, the standard system of record for IT changes together with the data concerning those changes. Capture all change requests Create change record Ensure complete documentation Provide a central point for input of change requests Determine / assign risk level of change request Provide lead time standards for change requests based on risk level Communicate change requests to affected parties ARB Assessment ARB assessment provides technical and business reviews to ensure compliance with campus standards. Ensure the change meets the requirements of the business Ensure the test plan is appropriate Ensure the back-out plan is complete Ensure the change is technically feasible Ensure software distribution plan is provided and complete Ensure the change is compatible with the system / application plans Determine the technical impact on and interfaces with other applications Page: 7 of 15

8 Update change records CAB Assessment CAB assessment ensures change management process requirements are satisfied and changes are ready for operational deployment. Validate the lead time is being honored Determine how the change fits in with business plans Determine impact on business partners Ensure user acceptance test plan is appropriate Assess conflicts with currently planned changes and environmental changes Determine the business impact on and interfaces with other applications Update change records Ensure documentation, procedures, and training plan is provided Preliminary Change Scheduling Determine current change schedule Approve, reject, or reschedule change Schedule changes Resolve scheduling conflicts Update change records Update Master Schedule / Calendar Monitor and Test Ensure test plan compliance Validate testing completion (stress testing and user acceptance testing) Assess test activities and results compared to standards Update change records Final Change Scheduling Ensure completeness of prior activities Make 'go / no-go' decision for each change Determine final priorities Update Change Calendar Monitor Install Verify readiness for installation Install changes into production Approve or disapprove Emergency Changes Update inventory as necessary Update change records Page: 8 of 15

9 Change Management Reporting Changes bypassing the process Number of Emergency Changes Testing adequacy Provide information to users of the Change Management process Identify changes that affect service delivery Develop corrective actions RISK LEVELS AND LEAD TIMES Risk levels are established to help evaluate uncertainty in these areas of concern: Financial impact of the change Prior experience with the type of change The degree of difficulty in managing the change The technical complexity of the change GUIDANCE TO ASSESS RISK Risk Level 1- HIGH RISK/HIGH IMPACT Affects multiple groups on campus, a college, or a supported facility The change is difficult or impossible to back out Risk Level 2 HIGH RISK/MODERATE IMPACT Changes affect a significant part of the customer s business Is hard to back out (but back-out procedures have been identified), The change can be tested Similar changes have been done successfully in the past Risk Level 3 MODERATE RISK/ MODERATE IMPACT The change affects a small part of the business Is relatively easy to back out Has been tested Similar changes have been done before successfully Risk Level 4: LOW RISK/MODERATE IMPACT Page: 9 of 15

10 The change would have little effect on business (i.e., non-intrusive changes to individual applications that have no impact on other applications / systems, such as generating reports from a data warehouse) Is simple to back out Can be easily tested Similar changes have been done many times before Risk Level 5: LOW RISK/LOW IMPACT Maintenance changes required to maintain system functionality but which need to be communicated to stakeholders Can be easily tested Back-out is easily done and non-intrusive to customers Changes of this time are routinely done Repeatable changes that have prior approval Page: 10 of 15

11 CHANGE MANAGEMENT FLOW BASED ON RISK LEVELS LEAD TIMES Lead times are established for planning and scheduling changes based on risk levels. The requested change implementation date must be based on the lead time required for the assigned risk level Emergency Submitted after change has been implemented, if possible approved via Emergency CAB Urgent Approved via Emergency CAB Risk Level 1 - Must be submitted 3 days prior to ARB meeting. Risk Level 2 - Must be submitted 3 days prior to ARB meeting. Risk Level 3 - Must be submitted no later than 3 days prior to implementation. Risk Level 4 - Must be submitted no later than 3 days prior to implementation. Risk Level 5 - Pre-approved routine changes must be submitted 0 days prior to implementation. Page: 11 of 15

12 CHANGE CATEGORIES, CHANGE TYPES AND WORKFLOWS CHANGE CATEGORIES Two categories of changes are established as follows: Planned - Changes that follow the standard change management process and are reviewed, approved and scheduled in advance. Emergency Changes that are required as a result of unforeseen events for which planning is not feasible to avoid service disruptions/outages. Note: See the IET Change Management ServiceNow Implementation.docx document for a description of the workflows implemented in ServiceNow to process these change types. PLANNED CHANGES Planned changes are categorized as Standard and Normal. Standard: changes are pre-authorized changes that are generally low risk, commonly done and have a pre-established and approved procedure or work instruction to perform the change. Normal: Any change that is not a Standard or Emergency type change. EMERGENCY CHANGES Emergency changes are required to restore normal services to campus customers after an unexpected service disruption or to prevent a priority 1 or 2 incident from occurring. CHANGE ADVISORY BOARDS A Change Advisory Board is a body that exists to assist Change Management in the assessment (impact/risk), prioritization, and scheduling of changes. Members ensure that all changes are adequately assessed from a business, technical, deployment and emergency viewpoint. Emphasis is placed on balancing Client business needs with the risks and effects of services interruptions. ARCHITECTURE REVIEW BOARD (ARB/TCAB) Purpose The Architecture Review Board (or Technical Change Advisory Board) consists of specific technical and business experts that can assess and validate changes proposed for risk, impact, and need going into the production environment. Page: 12 of 15

13 Scope Reviews all RFCs flagged for ARB/TCAB review to assess and validate their technical feasibility Ensures RFCs are adequately assessed for cross boundary systems, apps, Geos, Domains etc. impacts Ensures documentation and plans for testing/mitigating cross boundary impacts are identified Assesses the change for scheduling impacts DEPLOYMENT CAB (DCAB) Purpose The Deployment Change Advisory Board (DCAB) evaluates the readiness and gives approval of any change to be introduced into the managed environment. Scope Makes decisions on Service, Implementation and Operational readiness and the final decision on the actual release date Ensures all changes in the scope of the CAB comply with defined Change Management Processes Ensures that post implementation emergency changes (meeting defined criteria) to the managed environments in the scope of this body are justified, and that corrective action is being taken Tracks all expiration dates of all Standard Change approvals Verifies risk associated with change is correct EMERGENCY CAB (ECAB) Purpose The Emergency Change Advisory Board (ECAB) evaluates the readiness and gives approval of any emergency and urgent changes to be introduced into the managed environment. The ECAB meets via in an Ad-hoc manner to evaluate changes immediately upon receipt of the RFC. Scope Makes decisions on Service, Implementation and Operational readiness and the final decision on the actual release date Ensures all changes in the scope of the CAB comply with defined Change Management Processes Ensures that post implementation emergency changes (meeting defined criteria) to the managed environments in the scope of this body are justified, and that corrective action is being taken IMPLEMENTATION ISSUES Page: 13 of 15

14 See IET Change Management ServiceNow Implementation.docx document for implementation issues. Page: 14 of 15

15 APPENDIX The appendix contains addition exhibits and standards used to support the Change Management Process (Beta) APPENDIX B REQUIRED DOCUMENTATION In addition to the required fields in the ServiceNow, additional documentation is required. The following table outlines the artefacts that are required for each approval. Required Artifacts Impact Assessment Technical Design Test Plan ARB Deployment CAB Emergency CAB Risk Assessment Implementation Plan Back Out Plan Validation Plan Test Results Communication Plan Implementation Plan Impact Assessment Back Out Plan High priority Incident Record Post Deployment Post Implementation Review Any other required artifacts per the request of the ECAB or TCAB Page: 15 of 15