290 likes | 427 Views
Click this icon for Audio. Change Management FOR University Medical Group Saint Louis University. Agenda. Change Management Defined Process Overview Monitoring Q & A.
E N D
Click this icon for Audio Change Management FOR University Medical Group Saint Louis University
Agenda • Change Management Defined • Process Overview • Monitoring • Q & A
Change Management - Process of executing and documenting changes that ensures a highly available, consistent, and stable computing environment. Ensure standardization across all sites and departments, as well as ensures that all necessary parties are contacted, informed and approve each change request. Each requested change is recorded and properly tracked to completion. All changes are controlled to provide reasonable assurance that significant changes are authorized and appropriately tested before being moved to production. Definitions
Definitions Functional Manager (FM) – Responsible for the technical operation of the system or application Business Process Owner (BPO) – End user of the system or it’s non-technical manager. Key Controls (CM #) - Denotes the key process controls within Change Management identified and approved by the University. Change Control Board (CCB) – Formal group of FM, BPO and other key stakeholders responsible for approving, scheduling or rejecting high or urgent changes Change Control Manger (CCM) – Responsible for facilitating the process. Is the first point of contact for each Change and can assist throughout the process. Change Management Team (CMT) – Formal group of FM, systems application managers and other technical personnel responsible for managing the Change Remedy Management System (Remedy) – Request tracking system used to record and document the Change for the CM process
CONTROLS CM1 A formalized documented system for tracking and reporting CM2 A formalized documented system for approval CM3 Changes meeting Project criteria must go to Project Office or Senior Management for Approval/Management CM4 Change Request must have all required documentation CM5 Change Request must have an Assessment Analysis CM6 Change Request must have Testing Environment CM7 Change Requests must have Testing documentation CM8 Change Requests must have Production Approval CM9 Change Request must have Production documentation CM10 Change Request must have documentation of users and process owner approval CM11 Version Control must be documented and maintained CM12 Scheduled Service Reviews of Changes made to the Applications
Business Case Impact & Risk Analysis Change Build Form Back Out Plan Test Plan & Checklist Communication Plan Implementation Plan Acceptance Form Closure Form Forms See CM Desk Top Procedures for more information
Process Overview For Change Management
Life Cycle For a more detailed outline see the CM Desktop Procedures
IT Functional Manager: Creates a Change Request in Remedy Inputs Requestor Log-in information Selects Functional Group to manage Change Step One: Initiate Request CM Control #1
Initiating Change Request in Remedy FM will give brief description of the change request in these fields. FM will select his group here FM will input the SLUNET ID of the requestor: additional information will auto-populate.
Step Two: Manage Change Review CM CONTROL # 2 and 3 Functional Manager: • Submit the Change Request to CCM for review: • Selects “CCB” in the Service field • Submits the Business Case Form with the Requestor • Performs initial risk assessment • Completes Risk Matrix • Completes CCB Review • Determines if this is an emergency • Selects the proper Priority code: “Urgent”
Risk Management Tools For Functional Manager After selecting “CCB” in the Service field for review: tabs for performing risk and impact analysis' will appear.
Risk Management Tools For Functional Manager RISK MATRIX The Risk of the Change will automatically be determined after the FM completes these few questions: simply press the “Calculate Risk” button. (The Risk Classification will also auto-populate in the Assessment tab.) Note the hyperlink “View Required Documentation”
Risk Management Tools For Functional Manager Change Classification -- Required FormsRequest PhaseHighlighted Documentation listed below is required for Medium and High Risk changes:1.0 Initiate1.1 Remedy Change Request (always required)2.0 Change Review2.1 Business Case3.0 Change Assessment3.1 Communications Plan3.2 Training Plan (as needed)3.3 Support Plan (as needed)3.4 Risk and Impact Analysis3.5 Change Build Form3.6 Backout Plan4.0 Testing4.1 Test Plan5.0 Approve / Implement5.1 Acceptance Form5.2 Implementation Plan6.0 Change Closure6.1 Close-Out / Sign Off Sample of Required Forms for Medium and High Changes “View Required Documentation”
Risk Management Tools For Functional Manager Risk Classifications • Four classifications of Risk: • Low • Medium • High • Urgent • Managed by one or more of four entities • Change Control Board • Change Control Manager • Departmental Functional Manger • ITS Project Office • All Risk Assessments Reviewed by Change Control Manager
Low/Medium Risk Changes A Change will be assigned to the Functional Manager if: For Example: • If the change requires immediate (emergency) attention • If the change requires no “down time” • If the change has no interrupt to service • Reference: Change Management Risk and Impact Matrix for furtherdetails
A Change will be assigned to the CCB if: For Example: If the change has multiple system dependencies If the change does not require immediate attention If the change requires “downtime” If the change has interruption to services High Risk Changes • Reference: Change Management Risk and Impact Matrix for furtherdetails
ITS Project Office - Managed Changes A Change will be assigned to the Project Office if: • The budget of the project is over $25,000 of non-labor expenses • It involves staff from 3 or more ITS departments one or more of the following: • It involves more than 300hrs ITS effort • A work schedule that is longer than 3 months • External labor greater than 100 hrs • The project schedule is highly constrained An ITS project is a defined, approved, temporary effort to produce a unique product or service in support of the University mission. • Reference: slu.edu/x11183.xml for further details
Documenting “Emergency” changes FM can override the Risk Matrix, and note circumstance below. In the case of an emergency Change, records must be completed post-implementation. FM will select “Urgent” in the Priority field, and fill out the remaining documentation.
Risk Management Tools For Functional Manager CCB REVIEW The CCB Review questions are forwarded directly to the CCB and CCM: They will assist all stakeholders in managing Medium to High risk Changes.
Attaching Supporting Documentation CCB Attachments Labeled “CM Attachments” There is also a Hyperlink to CM documentation. The FM or their designee can attach any documentation on this tab: including confidential material (see right).
Risk Management Tools For Functional Manager Assessment The final task in the initial Risk and Impact analysis is to input a start and end date for the Change under the Assessment tab. (can be adjusted later). DON’T FORGET TO SAVE YOUR WORK !!!
Step Three: Change Assessment CM CONTROL # 4 and 5 • Functional Manager, CCM or CCB: • Reviews and begins approval process • Performs a detailed risk assessment • Impact & Risk Analysis Form • Gathers requirements and plans resources • Identifies personnel involved • Develops material and documentation • Change Build Form • Back Out Plan Form
Step Four: Testing CM Control # 6 and 7 • Functional Manger, CCM or CCB: • Creates a Test Plan and Test Plan Checklist • Identify test cases, scenarios and scripts • Specify test environment requirements • Identify document standards for testing • and production environment • Test Plan • Completes other forms as required by Functional Manager, CCM or CCB: • Communication Plan • Training Plan • Support Plan
Step Five: Approve & Implement CM CONTROL # 8,9 and 10 • Functional Manager: • Creates an Implementation Plan • Implementation Form • Functional Manager, CCB, CCM and/or Business Process Owner: • Reviews all work against requirements and schedule • Risk & Impact Analysis • Back Out Plan • Change Build Form • Test Plan & Checklist • Communicates and Implement Change • Implementation and Communication Forms revisited • Acceptance Form (CCB, CCM and BPO approval)
Step Six: Change Closure CM CONTROL # 10 and 11 • Functional Manager, CCM or CCB: • Confirms Version Control with Requester • Review all forms for correct documentation • Finalize Plans and Validates • Closure Form
Functional Manager, CCB, CCM and Business Process Owner will review reports for the following areas on pre-determined schedule. Segregation of Duties Analysis Reconciliation of CM logs to configuration logs Documentation supporting implementation of CM Reporting CM CONTROL 12
CONCLUSION For Additional Information Please contact the Quality Assurance Office: qaoffice@slu.edu