PPT
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
508
On Slideshare
507
From Embeds
1
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 1

http://www.slideshare.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI Tett kobling mellom Config og Change, nesten så tett at det kan intergreres
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI Her er det viktig at change mgr har en god teknisk forståelse både av systemet og av bedriftens business-perspektiv . I CAB bør det sitte et bredt utvalg av representanter, mens i CAB/EC bør det reduseres, eller man kan forsøke å styrke den med spesielt nødvendige personer i forhold til det problemet som man skal angripe.
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI Den skal også ta endringsforslag som er useriøse.
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI Kategoriseringen kan sies å ha noe med kopling å gjøre, hvor omfattende og hvor tett koblet er endringen til resten av systemet.
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI Målet er ikke at snarveiene skal gjøre det enklere, snarere tvert om, det skal være mer bry å gå snarveiene, men det skal være mulighet for det slik at du kan komme fort (men ikke enkelt) i mål dersom du trenger det. Dessuten har man også konseptet med uautoriserte endringer .
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI Rapporter er for ekstern bruk, Ytelsesindikatorer er mer for intern bruk.
  • TDT4285 Planl&drift IT-syst 1. April 2008 Anders Christensen, IDI

Transcript

  • 1. Lecture no 23: ITIL Change management TDT4285 Planlegging og drift av IT-systemer Spring 2008 Anders Christensen, IDI 1. April 2008 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.
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 3. Relationship to other processes 1. April 2008 TDT4285 Planl&drift IT-syst Change mgmt Release mgmt Config. mgmt Problem mgmt Incident mgmt Capacity mgmt Availability mgmt IT service cont mgmt Service level mgmt
  • 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.
    1. April 2008 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.
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 6. Activities 1. April 2008 TDT4285 Planl&drift IT-syst RFC submission, Recording Acceptance; filtering RFCs Configuration mgmt processes info and monitors the status of CIs Classification, category and priority Urgent? Planning; Impact and Resources Coordination Build Test Implement Working Evaluation and Close Rejection, possibly new RFC Start back-out plan Urgent procedures Yes No
  • 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
    1. April 2008 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.
    1. April 2008 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
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 10. Classification
    • Priority:
    • Low (postponable)
    • Normal
    • High
    • Urgent (must do now)
    • Categories
    • Low impact
    • Significant impact
    • Great impact
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 11. Planing and acceptance
    • 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.
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 12. Coordination
    • 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)
    1. April 2008 TDT4285 Planl&drift IT-syst Build Test Implement
  • 13. Evaluation
    • 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?
    1. April 2008 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.
    1. April 2008 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.
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 16. Reporting
    • 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
    1. April 2008 TDT4285 Planl&drift IT-syst
  • 17. Input and output 1. April 2008 TDT4285 Planl&drift IT-syst Change mgmt RFC CMDB FSC Other: e.g. PSA capacity plan FSC History Reports Triggers for other proc