Lecture no 20: ITIL Change management

1. Lecture no 20: ITIL Change management TDT4285 Planlegging og drift av IT-systemer Spring 2009 Anders Christensen, IDI TDT4285 Planl&drift IT-syst

2. Change prosessen in ITIL • It is one of the most central and most important ITIL processes • Everything that changes a status in a CI in CMDB in ITIL • Change mgr should have a good broad overview, some in-depth knowlegde in key areas, and know lots of the local history. TDT4285 Planl&drift IT-syst

3. Relationship to other processes Incident mgmt Release mgmt Problem mgmt Service level mgmt Change mgmt Capacity mgmt Config. mgmt IT service cont mgmt Availability mgmt TDT4285 Planl&drift IT-syst

4. Goal • Ensure that all changes are performed in a structured, documented and well-planned process. • Balance between flexibility (what needs to be done right now) and stability (so that changes does not break anything. TDT4285 Planl&drift IT-syst

5. Rôles • Change manager • Change coordinator • Change Advisory Board (CAB) • Change mgr, Service Level mgr, repr/service desk, repr/problem mgmt, management, business rep, user reps, development rep, system administrators, vendor reps. • CAB/Emergency Commitee (CAB/EC) • Only the most essential members of CAB. TDT4285 Planl&drift IT-syst

6. Rejection, possibly new RFC RFC submission, Recording Activities Acceptance; filtering RFCs Classification, category and priority Yes Urgent procedures Urgent? Configuration mgmt processes info and monitors the status of CIs Planning; Impact and Resources Build Test Coordination No Start back-out plan Implement Working Evaluation and Close TDT4285 Planl&drift IT-syst

7. Registration of an RFC • Identification number • References to problems and known errors • Description and references to CIs involved • Rationale for the change • Current and future CIs that will be changed • Name and contact info for the person that suggested the RFC • Date etc • Overview of resource usage and time estimates TDT4285 Planl&drift IT-syst

8. Acceptance The process of accepting an RFC, has as its goal to filter out proposed changes that are incomplete, impractival, impossible, too expensive, unclear, that is untimely (must wait to a better time), or that has unwanted consequences. TDT4285 Planl&drift IT-syst

9. Further information in an RFC • Data on categorization and priority • Estimate on how it will affect the rest of the system • Recommendations from change mgr • History of the handling of this RFS, including acceptance and autorization • Plans for backup • Requirements for maintenance • Plan for implementation • Roles for the implementation phase, including casts • Timing for the implementation • Timing for evaluation • Test results and observed problems • If the change is rejected, a reason why • Information on scenarios and evaluation TDT4285 Planl&drift IT-syst

10. Priority: Low (postponable) Normal High Urgent (must do now) Categories Low impact Significant impact Great impact Classification TDT4285 Planl&drift IT-syst

11. Three levels of acceptance: Financial (can we affort this? Cost/benefit?) Technical (is it doable and is it smart to do it?) Business (is it constructive compared to focus of what we do as an organization?) Forward Schedule of Change (FSC): overview over future, planned changes CAB should discuss: Unautorized changes Autorized changes that shortcut the CAB RFCs for review in CAB Changes that is open or that was recently closed. Review of changes that have been implemented. Planing and acceptance TDT4285 Planl&drift IT-syst

12. Key notions: Iterative process Should be tested in a laboratory Holistic view: SW, HW, docs, procedures etc… RFC is the plan that controls the changes No change without a RFC (for exceptions: see below) Coordination Build Test Implement TDT4285 Planl&drift IT-syst

13. There should be a Post-implementation Review (PIR) after the completion of the change. This must be governed by the CAB. Was the goals for the change achieved? What is (if relevant) the satisfaction of the users? Was any side effects discovered after this change? Was the change on budget and on time? Are there any points to follow up? Evaluation TDT4285 Planl&drift IT-syst

14. Standard changes • For small, structured, frequent, trivial and easily understandable changes, it is possible to give acceptance in advance – as a standard change. • Std chg are like templates or procedures which are to be used in certain, predefined situations with-out further process. • Std chg must be logged, but Change mgr is not involved in each specific case. TDT4285 Planl&drift IT-syst

15. Emergency changes • If absolutely necessary, every non-essential, non-technical stage can be circumvented … • … but the procedures for such must be defined for the organization in advance: • CAB/EC is a sub-set of CAB and it is easier to arrange for a meeting • Change mgr can make decisions by himself • Testing, documentation etc can be done post factum. • Important: all shortcuts must be evaluated afterwards. TDT4285 Planl&drift IT-syst

16. Reports: Number of changes pr time unit and pr CI Overview of origin for changes and RFCs No of successful changes No of back-outs No of incidents that can be related to changes Graphs and trends Performance indicators: No of changes pr time unit. Avg time to perform a change No of rejected changes No of incidents that can be related to changes No of back-outs Costs related to changes Share of changes that is within time and budget Reporting TDT4285 Planl&drift IT-syst

17. Input and output FSC FSC RFC Triggers for other proc Change mgmt CMDB History Other: e.g. PSA Capacity plan Reports TDT4285 Planl&drift IT-syst