180 likes | 339 Views
Forelesning 23: ITIL Change management. TDT4285 Planlegging og drift av IT-systemer Våren 2006 Anders Christensen, IDI. Change prosessen innen ITIL. En av de viktigeste og mest sentrale prosessene i ITIL. Alt som endrer status i en CI i CMDB er ’mat’ for Change mgmt.
E N D
Forelesning 23: ITIL Change management TDT4285 Planlegging og drift av IT-systemer Våren 2006 Anders Christensen, IDI TDT4285 Planl&drift IT-syst
Change prosessen innen ITIL • En av de viktigeste og mest sentrale prosessene i ITIL. • Alt som endrer status i en CI i CMDB er ’mat’ for Change mgmt. • Change mgr må ha mest mulig oversikt i både bredde og dybde og tid TDT4285 Planl&drift IT-syst
Forholdet til andre prosesser 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
Målsetning • Sørge for at endringene forgår i en strukturert, dokumentert og planmessig prosess. • Balansere mellom fleksibilitet (tillate endringer) og stabilitet (videreføre det bestående) TDT4285 Planl&drift IT-syst
Roller • Change manager • Change coordinator • Change Advisory Board (CAB) • Change mgr, Service Level mgr, repr/service desk, repr/problem mgmt, linjeledelse, forretningsdrift, brukerrepr, repr/utviklere, systemansvarlige, repr/leverandører • CAB/Emergency Commitee (CAB/EC) • Bare de mest sentrale personene i CAB. TDT4285 Planl&drift IT-syst
Rejection, possibly new RFC RFC submission, Recording Aktiviteter 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
Registering av en RFC • Identifikasjonsnummer • Referanser til problemer/kjente feil • Beskrivelse og ref til berørte CI’er • Begrunnelse for endringen • Nåværende og fremtidig versjon av CI som skal endres • Navn og kontaktinfo den som forslår RFC’en • Dato • Overslag over ressursbruk og tidsestimater TDT4285 Planl&drift IT-syst
Akseptering Aksepteringen av en RFC har som mål å filtrere ut endringsforslag som er ufullstendige, upraktiske, umulige, uklare osv. TDT4285 Planl&drift IT-syst
Ytterligere info i en RFC • Kategoriseringsdata og prioritet • Overslag over omfang og innvirkning på omgivelsene • Anbefalingene fra Change mgr • Historikk med bl.a tid for akseptering og autorisering • Planer for backup • Vedlikeholdskrav • Implementasjonsplan • Info/rolleliste over de som skal gjennomføre endringen • Tidspunkt for gjennomføring av endringen • Tidspunkt for evalueringen • Testresultater og observerte problemer • Dersom endringen er forkastet, begrunnelse for hvorfor • Informasjon om scenarier og evaluering TDT4285 Planl&drift IT-syst
Prioritet: Lav (kan utsettes) Normal Høy (foran annet) Urgent (hastesak) Kategorisering: Lav impact Betydelig impact Stor impact Klassifisering TDT4285 Planl&drift IT-syst
Tre godkjennelser: Finansiell (har vi råd, og kost/nytte?) Teknisk (er det både gjennomførbart og lurt? Forretningsmessig (er det hensiktsmessig for kundene og leveransen?) Forward Schedule of Change (FSC): oversikt over planlagte endringer CAB bør behandle: Uautoriserte endringer Autoriserte endringer som gikk utenom CAB RFC for review av CAB Åpne og lukkede endringer Review av gjennomførte endringer Planlegging og godkjennelse TDT4285 Planl&drift IT-syst
Nøkkelbegreper: Iterativ prosess Utprøving på testlab Helhet: SW, HW, dokumentasjon, prosedyrer ... RFC er planen som styrer endringen Koordinering Bygge Teste Gjennomføre TDT4285 Planl&drift IT-syst
Det bør gjennomføres Post-implementation review (PIR) i etterkant av endringen. Dette gjennomføres eller styres av CAB. Ble hensikten oppnådd ved gjennomføringen av denne endringen? Hva er (om relevant) brukertilfredsstillelsen? Har man oppdaget noen bieffekter av denne endringen? Klarte man å holde seg innen budsjett på utstyr, arbeidstid og klokketid? Videre oppfølging bør vurderes. Evaluering TDT4285 Planl&drift IT-syst
Standard endringer • Dersom endringene er små, strukturerte, oversiktlige og hyppige, bør man vurdere å forhåndsgodkjenne en standard endring. • Std endringer er som ’maler’ eller prosedyrer, der bestemte handlinger i bestemte situasjoner er godkjent uten ytterligere behandling. • Disse logges, men Change mgr er ikke involvert i det enkelte tilfellet. TDT4285 Planl&drift IT-syst
Hasteendringer • Ved behov for hasteendinger kan ’alle’ forsinkende ledd gås utenom ... • ... men prosedyrene for dette må være relevant definert for organisasjonen på forhånd: • CAB/EC er et subsett av CAB som er lettere å sammekalle • Change mgr kan ta beslutninger på ’fullmakt’ • Testing, registrering etc kan utføres i ettertid • Viktig: at alle snarveier blir evaluert i ettertid TDT4285 Planl&drift IT-syst
Rapporter: Antall endringer pr tidsenhet totalt og pr CI Oversikt over opphav til endringer og RFC. Antall vellykkede endringer Antall back-outs Antall incidents som kan relateres til endringer Grafer og trendanalyse Ytelseindikatorer: Antall endringer gjennomført pr tidsenhet Gj.snittlig tid for å gjennomføre en endring Antall forkastede endringer Antall incidents som kan relateres til endringer Antall back-outs Kostnadene knyttet til endringene Andel endringer som er innenfor tidsplaner og budsjett Rapportering TDT4285 Planl&drift IT-syst
Input og output FSC FSC RFC Triggers for andre proc Change mgmt CMDB Historikk Annet: f.eks PSA capacity plan Rapporter TDT4285 Planl&drift IT-syst