IT Service Management

Transkript

1 IT Service Management Forelesning uke 10 Innhold Change Management "Not every change is an improvement, but every improvement is a change" Hensikt og mål Innovasjon og forbedring. Svare på endrede forutsetninger, maksimere forretningsverdiene, og rette tjenester i tråd med forrentingstategiene. Rette feil, og redusere antall henvendelser. Minimere påvirkning og omfang av endringer, så risikoen reduseres. Ha standardiserte prosesser for endringer, så endringer kan gjennomføres raskere og mer effektivt over tid. Holde oversikt og bokføring over alle endringer. Alle endringer registeres i CMDB. "Change is not only likely, it s inevitable." -- Barbara Sher Omfang Definisjon på endring i ITIL: Innføring, endring, eller utfasing av en autorisert, planlagt, eller supportert tjeneste, tjenestekomponent, eller tjenestedokumentasjon. Andre ting: Man bør avgjøre og definere hva som skal inkluderes i en Change Management prosess eller ikke. (F.eks. service på printere, bytte av like komponenter) 1

2 Forrentningsverdier Gjøre endringer som kan øke produktiviten til brukerne. Gjøre endringer som kan redusere driftkostnader. Gjøre endringer som er i tråd med forrentingstategier. Gjennom en standardiserte prosesser gjøre endringer raskere. Gjøre risikovurderinger. Føre logg over alle endringer slik at man kan lære av feil, og finne feil raskere. "It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change." -- Charles Darwin Typer av endringer Standardendringer -- Forhåndsgodkjente endringer. Kriseendringer -- Endringer som må behandles raskt og med høyest prioriet. Normalendringer -- alt det andre ;) Standardendringer Klart definerte endringer. Oppgavene for å utføre endringen er godt kjent, dokumentert og verifisert. Godkjenning er så og si gitt på forhånd. Endringen har lav risiko og vel kjente konsekvenser. Eksempler: Nettverkkobling, Bestiling av telefon, Passordendringer, Flytting av kontor. Kriseendinger Endringer som er avhenging av en enklere og raskere behandlingsprosess. Dokumentasjon kan tillates i ettertid av selve endringen. Bør holdes til et absolutt minimum. Eksempler: Omkobling og re-ruting pga. nettverksutfall, Sikkerhetspatching pga. angrep, Flytting eller endring av tjenester pga. brann, tyveri, eller naturkatastrofer. 2

3 Request For Change Alle endringer kommer inn som en Request For Change. RFCer kan komme fra: Problem Management (feilrettig, forslag på fikser) Brukere (bestillinger, nye behov) Lovgivning (Sarbanes-Oxley, EUs Datalagringsdirektiv) Leverandører (nye versjoner, patcher, utfasinger) Stategiendringer (Oppkjøp, fusjoner) IT-personale (dokumentasjon, forbedringer) 3

4 4

5 Aktivitet: Raising and Recording changes En RFC må registeres i et system på samme måte som Incidents. En RFC-registrering bør minst inneholde: Unik identifikator Beskrivelse av endringen Begrunnelser for endringen. Eierskap Problem og kjente feil (known error) som den er knyttet til Relevante CI er Estimater på tid og ressurser. Aktivitet: Review the Request for Change Filtering. Etter identifisering bør det foretas en filtrering av RFCer som ser ut til å være: Upraktiske, og ugjennomførbare endringer Duplikat av tidligere registrerte RFC Ikke ferdigfylte RFC - f.eks. med manglende budsjettgodkjennelse, manglende beskrivelser, etc. Alle avviste RFC bør sendes tilbake til den som har gjort henvendelsen med en begrunnelse av hvorfor den er avvist. (Rutiner for klager bør eksistere) Aktivitet: Assess and evaluate the change Risikokategorisering Gjøre en sjapp risikoanalyse og kategorisere hvilke konsekvenser denne endringen vil ha for et forretningsperpektiv og fra et IT-perspektiv. Evaluering Basert på risiko og fordeler gi en vurdering av om denne endringer er fordelaktig eller ikke. Prioritering Sett i forhold til andre RFCer, bør denne endringen komme før eller etter. Planlegging En vurdering av når denne endringen kan gjennomføres. Tilbakerullingsplan Hvordan gjøres en tilbakerulling til den gamle konfigurasjonen om denne endringen skulle feile? Aktivitet: Authorize the Change De nødvendige autorisasjoner for endringen må hentes inn. Dette kan være system-eiere, kunder, gruppe av brukere, fagforeninger, og ledelse, helt avhengig av foretakets organisering og størrelse. 5

6 Aktivitet: Co-ordinating Change implementation Bestemme tidspunkt for når endringen skal gjennomføres (dette bør gjøres når det vil ha minst påvirking på selve tjenesten) Koordinere og informere parter som vil bli påvirket, spesielt Service Desk må være godt informert. Aktivitet: Review and close Change Record Etter at endringen er implementert og gjennomført, må det gjøres en evaluering av om endringen har oppfylt hensikten i RFCen. Er den som gjorde henvendelsen fornøyd med endringen? Uforutsette konsekvenser må kartlegges og registeres. Relevante Incident, Problem, og Known Errors må lukkes eller oppdateres. The Seven Rs Of Change Management Who RAISED the change? What is the REASON for the change? What is the RETURN from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test, and implementation of the change? What is the RELATIONSHIP between this change and other changes? Roller: Change Manager Change manager er eier av prosessen, og således sørger for at prosessen følges. Mottar og filterer RFCer. Gir autorisasjon for mindre endringer. Koordinerer og leder Change Advisory Board (CAB) møter Fastsetter og planlegger endringstidspunkter. Koordinerer change/build/test/implementasjon Gjør evalueringer av endringer etter gjennomføring og lukker RFCer 6

7 Roller: Change Advisory Board (CAB) Change Advisory Board gir råd og innspill til Change Manager, og hjelper med å forankre avgjørelser og godkjennelser av endringer. Konsulteres ved større og viktige endringer. Vil kunne bestå av kunder, ledere, ansattrepresentanter, fagforeningsrepresentanter, tjenesteansvarlig, systemansvarlig, teknikkere og eksperter, ekserne representanter, leverandører, Service Desk, Sikkerhetsansvarlig, etc. Sammensettning kan være forskjellig fra gang til gang, avhenging av hvilken endring som skal vurderes. Sammensettningen bør være god balanse mellom forskjellige syn - både interne og eksterne. Det bør være en form for forhåndsavtalte kriteringer for å evalutere og autorisere endringer. Roller: Emergency CAB (ECAB) Et subsett av Change Advisory Board. Sammensettningen avhenger av den spesifikke endringen. Den bør bestå av så få folk som mulig, som samtidig har autoritet nok til å ta kriseavgjørelser. Utfordringer Passe på at folk følger prosedyrene. For dårlige Configuration Management prosesser. Press fra ledelsen om å bare få det gjort. Mangel på standardendringer. Store organisasjoner gjør endringsstyring vanskeligere. 7