Kvalitetssikringssystemer i IKT Agder

Størrelse: px

Begynne med side:

Download "Kvalitetssikringssystemer i IKT Agder"

Margrethe Hovland
8 år siden
Visninger:

1 Kvalitetssikringssystemer i IKT Agder Kvalitetssikringssystemer 1

2 Innholdsfortegnelse 1 KVALITETSSIKRINGSSYSTEMER I IKT AGDER INCIDENT MANAGEMENT CHANGE MANAGEMENT PROBLEM MANAGEMENT RUTINE FOR HÅNDTERING AV RFC FOR EKSTERNE KONSULENTER...5 Kvalitetssikringssystemer 2

3 1 Kvalitetssikringssystemer i IKT Agder Med ca brukerkontoer i Active Directory har IKT Agder innsett behovet for en systematisk tilnærming til IT-drift for å gi alle disse brukerne en forutsigbar og god kvalitet på ITtjenestene de er avhengige av for å løse sine daglige gjøremål. For å løse våre oppgaver har vi derfor valgt å benytte oss av IT Infrastructure Library (ITIL), som er et bibliotek og rammeverk utviklet for å kvalitetssikre alle sider av IT-arbeidet. Foreløpig har vi innført 3 prosesser i ITIL-rammeverket: 1. management 2. Change management 3. Problem management I tillegg forbereder vi innføring av Service Asset and Configuration Management. 1.1 INCIDENT MANAGEMENT Denne prosessen skal håndtere feil og hendelser som påvirker den daglige IT-driften. Målet med incident management er å gjenopprette normal drift fortest mulig. Sakens omfang definerer prioritet i en skala fra 1 til 4. I henhold til vår SLA-avtale med våre kunder har prioritet 4 liten påvirkning for det daglige arbeidet, mens prioritet 1 angir at det kan være fare for liv og helse. «management service request» håndterer bestilling av ny tjeneste og IT-relaterte innkjøp. «management request for Access» håndterer bestilling av tilgang til f.eks. et filområde eller et fagsystem. I incident management-prosessen er det bestemt at vår servicedesk skal være vårt «Single Point of Contact». Prosessens forskjellige faser illustreres i figuren nedenfor: 1 Management 1.1 Identification & registration 1.2 Major? No 1.3 Initial Diagnosis 1.4 Functional Escalation 1.5 No Invetisgation & Diagnosis 1.6 Resolution & Recovery 1.7 Closure End Yes Yes 1.9 Major Procedure 1.8 Functional Escalation 2/3 level 1.2 CHANGE MANAGEMENT Change management-prosessen skal ivareta kvalitet og sikkerhet ved gjennomføring av endringer. Behovet for endring kan oppstå som et resultat av en hendelse (incident) eller som en løsning på et problem. I begge tilfeller må fylles ut en «Request for Change (RFC)». Dersom denne tilfredsstiller de krav som er nødvendig så vil RFC en godkjennes av Change Manager (CM) ved mindre Kvalitetssikringssystemer 3

4 komplekse endringer, eller av Change Advisory Board dersom det gjelder mer komplekse endringer. Hasteendringer skyldes gjerne en kritisk hendelse som en må få løst fort. Stor endring er en endring som er kostbar og krever mye ressurser. Her skal CM sjekke at nødvendige ressurser er satt av før saken sendes videre i prosessen. Normal endring er en ny endring som ikke har vært foretatt før. Standard endring er normal endring som er godkjent og kan gjenbrukes. Disse trenger ikke ny godkjennelse. De ulike fasene av change-prosessen er vist i figuren nedenfor. Change Management 2.14 Haste endringer Haste RFC 2.1 Registrer og kategoriser 2.2 Risiko og påvirknings vurdering 2.3 Kategori Stor 2.4 CM godkjenning 2.5 Planlegging, test og tidsfesting av endring 2.6 CAB godkjenning 2.7 Distribusjon og implementering 2.8 Suksess? 2.9 Overvåking og rapportering 2.10 Suksess? 2.11 Behov for PIR? Lukk RFC Standard (eller mindre?) Normal 2.15 Standard endringer 2.13 Backout 2.12 Post Implementation Review 1.3 PROBLEM MANAGEMENT Et problem er definert som den ukjente bakenforliggende årsaken til en eller flere hendelser. Problem management ivaretar informasjon om problemer, midlertidige løsninger og løsninger. Problem management bidrar til å hjelpe alle andre prosesser med å finne den virkelige årsaken til at en hendelse inntreffer ( root cause analyser). Hensikten med problem management er å: Minimere effekten på organisasjonen når det gjelder hendelser og problemer forårsaket av IT-infrastrukturen eller IT-tjenester. Forhindre gjentakende hendelser knyttet til problem(ene). Identifisere root cause til en eller flere hendelser og deretter å igangsette handlinger for å korrigere situasjonen. Servicedesk og andre teknikere kan merke hendelser som «possible problem» i vårt Service Management System (BMC Footprints). Problem manager vil vurdere disse sakene og avgjøre om det er et problem som skal behandles videre i problem-prosessen eller en enangshendelse som behandles videre i incident og/eller change-prosessene. De forskjellige fasene i prosessen er vist på figuren nedenfor: 4 Problem Management 4.1 Identifiser 4.2 Registrer 4.3 Finn underliggende årsak 4.4 Anbefal løsning 4.5 Opprett RFC 4.6 Overvåk og lukk Problem End Possible Problem Major Change Management Kvalitetssikringssystemer 4

5 1.4 RUTINE FOR HÅNDTERING AV RFC FOR EKSTERNE KONSULENTER 1. Ansvarlig hos IKT Agder (tekniker, prosjektleder osv.) fyller ut RFC-skjema med alt som vedkommende har kjennskap til. 2. Det pre-utfylte skjemaet sendes til den eksterne konsulenten som skal utføre endringen. 3. Den eksterne konsulenten kompletterer skjemaet, spesielt det som handler om beskrivelse av hvordan endringen skal gjøres, rollback plan, testprosedyrer osv. 4. Den eksterne konsulenten sender skjemaet, dokumentasjon og eventuelle skript o.l. tilbake til ansvarlig hos IKT Agder. 5. Ansvarlig i IKT Agder oppretter RFC i Footprints med seg selv som forespørrer og legger ved skjema og annet som ble mottatt av ekstern konsulent. 6. Saken sendes til godkjenning og ansvarlig hos IKT Agder melder om resultatet til ekstern konsulent. 7. Når RFC er godkjent kan arbeide begynne. Kvalitetssikringssystemer 5

Like dokumenter

Itil-prosesser. NIF-ITs arbeid med utbedring av feilen

Itil-prosesser. NIF-ITs arbeid med utbedring av feilen Innhold NIF-IT 1 NIF-IT 1.1 Service Level Agreement (SLA) 1.2 Support (SPOC) 1.3 Request Fulfillment 1.4 Incident Management 1.5 Problem Management 1.6 Supplier Management 1.7 Change Management 1.8 Release