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

Transkript

1 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 & Deployment + Validation & Testing 1.9 Knowledge Management Våre leveranser - De korte beskrivelsene med prosesskart! Itil-prosesser Service Level Agreement (SLA) Gjeldende SLA som alle prosesser jobber ut i fra/er organisert rundt; Feilklasse Mål for svartid Mål for Løsningstid NIF-ITs arbeid med utbedring av feilen 1. Kritisk feil 15 min 2 timer skal arbeide med feilrettingen løpende inntil feilen er utbedret, eventuelt til en tilfredsstillende midlertidig løsning er etablert for angjeldende bruker(e) 2.Alvorlig feil 1 time 4 timer skal arbeide med feilrettingen inntil feilen er utbedret, eventuelt til en tilfredsstillende midlertidig løsning er etablert for angjeldende bruker(e) 3.Moderat 3 timer 3 dager skal arbeide med feilrettingen løpende innenfor regulær arbeidstid. 4.Mindre feil 4 timer I løpet av neste Feilrettingen skjer etter nærmere avtale mellom NIF-IT og Kunden arbeidsdag Tilbakemeldingsfrist

2 Oppfylles ved å sette hendelsesstatus til en annen status enn Ny, det vil si til: Under arbeid, Til verifisering, Avventer Problem/Endring, Avventer Bruker, Avventer Ekstern, Løst eller Lukket, innen gitte tidsfrister (se tabell). Velger man hendelsesstatus Lukket direkte uten å lagre først, oppfylles også tilbakemeldingsfristen. Løsningsfrist Oppfylles ved at hendelsesstatus settes til Lukket eller Løst innen gitte tidsfrister (se tabell ovenfor). Pausing av løsningsfrist Hendelsesstatus Avventer bruker eller avventer ekstern setter SLA for løsningsfrist til pause. Tiden vil da ikke fortsette å løpe igjen før hendelsen får en annen status igjen (bortsett fra status Lukket eller Løst). Dersom bruker svarer pr e-post på en hendelse med status Løst, vil den automatisk settes til Under arbeid, og tiden vil dermed løpe igjen. SLA-Nivå/Feil klasser Beskrivelse 1. Kritisk feil - Et kritisk problem avbryter ordinær bruk av tjenesten. Organisasjonsdriften står i fare fordi ordinære operasjoner i et eller flere virksomhetskritiske systemer ikke fungerer. 2. Alvorlig feil - Et alvorlig problem påvirker bruk av en tjeneste. Brukerne kan fortsatt arbeide, men med begrenset ytelse. Risiko for organisasjonsdriften er begrenset. 3.Moderat feil - Liten til moderat påvirkning for brukerne. Risiko for organisasjonsdriften er liten. Oppetid påvirkes ikke. 4.Mindre feil - Meget liten betydning for brukerne. Problemet har status?løses når tiden tillater det?. Support (SPOC) Support er brukernes kontaktpunkt også kalt SPOC (Single Point of Contact) til NIF-IT, (selv om vi i tillegg har brukere som henvender seg til Service Desk for HW-support). Support tar imot, registrerer og kategoriserer alle typer henvendelser - og ruter disse videre til riktig mottaker. Support skal også fungere som et knutepunkt mellom brukerne og de øvrige prosessene. Input Henvendelser fra brukere Supportleder: disponering av budsjett/økonomi og personell som tilhører support Saksbehandler: kan avvise saker/henvendelser som ikke er omfattet av avtalte tjeneste-leveranser Leveranse Tjenesten gjenopprettet til avtalt nivå, så snart som mulig - med minimal forstyrrelse for brukeren Brukerundersøkelser KONTINUERLIG: Overvåkning av køene (telefon og e-post) KONTINUERLIG: Sørg for at innsender blir oppdatert (automatisert rutine for de fleste forhold) Motta sak via telefon, e-post eller systemer (saker fra webportal håndteres automatisk) Sørge for at saken er komplett; Inkludert: Info om innsender/bruker Prioritering (Priority = Impact + Urgency) I = Impact (skala = 1-5) U = Urgency (skala = 1-5) 1 = Et kritisk system utilgjengelig 1 = 2 timer 2 = Et alvorlig system utilgjengelig 2 = 4 timer 3 = Deler av kritisk/alvorlige systemer utilgjengelig 3 = 3 dager 5 = Ikke kritisk/alvorlig funksjonalitet utilgjengelig 4= 1 uke 5 = Rammer produksjon til enkeltbruker 5 = Etter?Best effort?, dato estimeres Kategori C hva saken gjelder System C registrere rett løsning og kategori Sak registreres initielt som en Incident SK fordeler sak til rett saksbehandler; Incident Management, Request Fulfillment eller Annen prosess eller avdeling Request Fulfillment Request Fulfillment (RF) behandler bestillinger fra brukere og utfører Standard Changes

3 Input Bestillinger fra brukere (via SD) leder; Allokere ressurser/bemanning til å overholde SLA med en forsvarlig arbeidsmengde pr saksbehandler. Saksbehandler; bruke?sunn fornuft? ved vurdering av sakene/situasjonene Leveranse Rask behandling av bestillinger Sum av tid medgått i åpne saker, responstid (snitt per måned) Motta sak fra Incident Management Saksbehandler: Registrér/oppdater Service Request Saksbehandler: Behandle Service Request [? 2. linje påkrevd] Tildele sak til 2. linje for videre behandling [? Behov for ekstern leverandør] Saksbehandler: Følg opp leverandør [? RfC nødvendig] Saksbehandler: Fyll ut RfC sammen med kunden Saksbehandler: Informer kunden om utfallet av Service Request Lukk sak [? 2. linje påkrev?.] = les HVIS "#" = les GÅ TIL

4 Incident Management Incident Management (IM) håndterer avbrudd i tjenester som ikke er planlagt. IM skal gjøre de nødvendige tiltak for å få brukerne produktive så raskt som mulig. Fokuset er å utføre godkjente standard endringer eller å få til en midlertidig løsning (workaround) Input Incident fra SPOC, Incident fra overvåkningssystemer leder; Allokere ressurser/bemanning til å overholde SLA med en forsvarlig arbeidsmengde pr saksbehandler. Saksbehandler; bruke?sunn fornuft? ved vurdering av sakene/situasjonene. Leveranse Tjenesten gjenopprettet til avtalt nivå, så snart som mulig - med minimal forstyrrelse for brukeren Sum av tid medgått i åpne saker, Responstid (snitt per måned) Motta sak som er registrert i Support-prosessen [? Service Request] #'Service Request ' Tildel sak til riktig ressurs Input: Kompetansekart og oversikt over tigjengelighet Analysér Incident

5 Saksbehandler vurderer INC, og registrerer/oppdaterer/behandler INC [? 2. linje] Sett saken til 2. linje [? Behov for ekstern leverandør] Følg opp ekstern leverandør [? Saksbehandler finner ikke løsning] #'Opprett/Knytt til Problem' [? Workaround] Implementere midlertidig evt. permanent løsning Informer Bruker Oppdater INC med evt. Ny informasjon fra Bruker Verifisere med innsender av sak at løsningen er tilfredsstillende [? Løsning er ikke tilfredsstillende] #'Analysere Incident' [? Problem] Opprett/Knytt til Problem Informer/Oppdater/Lukk INC Sørg for at nødvendig dokumentasjon er registrert i KB (Knowledge Base = Wiki) Problem Management Problem Management skal finne årsaker til problemer og utarbeide varige løsninger Input Problemer registrert av IM. Problemer registrert av proaktive PM?s (Product Managers). Problemer fanget opp av overvåkningssystemer.

6 leder; Allokere ressurser/bemanning til å overholde SLA med en forsvarlig arbeidsmengde pr saksbehandler. Saksbehandler; bruke?sunn fornuft? ved vurdering av sakene/situasjonene Leveranse Varige løsninger på problemer som resulterer i færre og mindre feilsituasjoner Antall Incidents per system Motta Problem Sørg for at saken er komplett; Inkludert: Category/Subcategory Problem state Description Relevante Incidents Start vurdering av Problem [? Problem kritisk eller alvorlig] Innkall til ECAB Utfør Root cause analyse [? Workaround finnes] Dokumenter Workaround Opprett/oppdater Known Error Base Beslutt løsning [? RfC nødvendig] Lag RfC; Send til Change Management [? Problem løst] Oppdater problem med løsning [? Problem ikke løst] #'Start vurdering av Problem' [? Major problem] Utfør major problem review Lukk problem i SNC

7

8 Supplier Management Supplier Management sørger for: at kompetansehull i NIF-IT er dekket med underleverandører avtaler med underleverandører oppfølging av alle avtaler og begrenser leverandørkostnad Input Service Catalog Kompetansematrisen Manglende UC-er Leveranse Viktige kompetansehull dekket av relevante leverandører Underleverandører som gir best leveranse Underpinning Contracts (UC) UC-brudd At UC-er er oppdaterte og dekker viktige kompetansehull Godkjenning av leverandører utenfor prosjekter Bestemme standard for UC-er Ikke relevant Change Management Change Management?s hovedmål er å videreutvikle stabile tjenester, og beskytte brukerne mot endringer utført av IT. Input RfC fra: Request Fulfillment, Problem Management, Andre prosesser eller avdelinger leder; Allokere ressurser/bemanning til å overholde SLA med en forsvarlig arbeidsmengde pr saksbehandler. Kan stanse utførelsen av en endring dersom denne strider imot change policy eller det er stor risiko for at det gir en dårligere tjenestekvalitet. Saksbehandler; bruke?sunn fornuft? ved vurdering av sakene/situasjonene. Leveranse Vellykkede endringer, Endringer som ikke feiler eller rulles tilbake Prosent vellykkede endringer Change policy Change policy skal sikre rutiner for håndtering, prioritering og risikoanalyse av endringer. Prioritet defineres ved å legge sammen impact og urgency. Summen av disse utgjør da grunnlag for prioritering. Se Process under Support for Impactog Urgency skala. En RfC som registreres i Service-Now, skal minst inneholde følgende opplysninger: Short Description: Kort og konsis beskrivelse av endringen. Description: Hva, hvordan og hvorfor ønskes endring utført. Hva skal vi gjøre, hvordan skal endringen utføres og hvorfor. Urgency: Hvor mye haster det? Impact: Verdi for potensiell risiko ved endring. Hva kan påvirkers dersom endring feiler. Work hours: Estimert antall interne arbeidstimer Cost: Estimert eksterne kostnader, f. eks innkjøp av nødvendig hardware, konsulenttimer

9 Potensiell risiko og negative konsekvenser: Hva kan potensielt gå galt og hvilke systemer/ hardware påvirker det? Dokumenteres i work notes i SNC. Rollback plan: Eventuell rollback plan, og hvorfor det eventuelt ikke er mulig eller nødvendig. Dokumenteres i Work notes i SNC. Category og Subcategory: Både category og subcategory skal registreres. Annen informasjon: Annen informasjon som er relevant og som kan hjelper Change Manager i behandling og prioritering av endringene. CAB-møte (Change Advisory Board) avholdes hver onsdag, klokken 13:00 på Ullevål, med følgende deltagere: Change Manager Problem Manager Release & Deploy Manager 100% ansvarlig (løsning/produkt) Testleder? samt ved behov innkalles andre ressus/relevante personer. CAB gjennomgår alle endringer med impact=3 eller høyere, og beslutter videre arbeid med disse. Motta RfC Sørg for at RfC er komplett Vurdér RfC i henhold til Change Policy [? Impact => 2] Case Handler med skill 3 eller 4 kan beslutte endring [? Impact =< 3] Rådfør med Change Advisory Board (CAB) [? Endring er godkjent] Utarbeid et endringsoppdrag Bestem tidsbehov for endring Legg tidsluke for endring inn i Endringskalender Varsle alle impliserte om endring Tildel sak til riktig ressurs Send endringsoppdrag til #'Release & Deployment + Validation & Testing' Etter implementering: Gjennomfør en etterkontroll (PIR) PIR = Post Implementation Review Sørg for at alle impliserte er informert [? Etterkontroll feiler] Behandle saken i henhold til Sunn Fornuft [? Endring ikke er godkjent] Gi innsender av RfC en god forklaring på avslaget

10 Release & Deployment + Validation & Testing Release & Deployment sørger for utrulling og endring av funskjonalitet. Validation & Testing sørger for testing av ny eller endret funksjonalitet. Input Release & Deployment: Endringsoppdrag fra Change Management Validation & Testing: Implementerte endringer fra Release & Deployment leder; Allokere ressurser/bemanning til å overholde SLA med en forsvarlig arbeidsmengde pr saksbehandler. Nedlegge veto mot enhver endring som ikke tilfredsstiller definerte krav/kriterier.

11 Saksbehandler; bruke?sunn fornuft? ved vurdering av sakene/situasjonene. Output Release & Deployment: Releaser som ikke feiler Validation & Testing: Feil funnet i Releaser Release & Deployment: Antall endringer, Antall endringer som feiler Validation & Testing: Antall feil funnet Motta endringsoppdrag (fra #?Change Management?) Koordiner med Change-eier/Prosjekt-eier hva/når change skal implementeres Oppdater Release Plan Vurdér om implementering kan aksepteres [?Akseptanse feilet] Beslutt neste steg/tiltak [?Akseptanse ok] Implementer til riktig miljø [?Release feilet] Beslutt neste steg/tiltak [?Release ok] Test/Verifiser Release [?Test / Verifikasjon feilet] Beslutt neste steg/tiltak [? Flere miljøer] #'Vurdér om implementering kan aksepteres' Oppdater dokumentasjon/release Plan Informer alle parter om at endring er i produksjon Send til #PIR (Change Management)

12 Knowledge Management Knowledge Management (KM) skal sørge for å inspirere til effektiv kunnskapsdeling Har ansvaret for wiki-en og sørger for at denne brukes aktivt Holder oversikt over kompetanse på relevante tjenester, systemer og områder? ansvarlig for kompetansekartet (hvor hver og en skal sørge for å holde egen kompetanse på systemer og løsninger oppdatert) Input Kunnskap Skal stille krav til linjen om å stille ressurser til disposisjon for å oppnå sin leveranse. Har ansvaret for den interne kompetansebyggingen. Kan trekke inn ressurser (med spisskompetanse på enkeltområder) for å gjennomføre opplæringstiltak/kompetanseoverføring, booke fasiliteter m.v. Output Relevant kunnskap i bruk

13 Relevant kompetanse i NIF-IT Antall treff (sideoppslag) i wiki-en Total kompetansescore Ingen definert) Suksesskriteriene er øket samarbeid og motivasjon i alle ledd av organisasjonen, med kompetente og engasjerte medarbeider i alle ledd som evner å ta ansvar for et utviklende miljø under mottoet?frihet og ansvar skaper entusiastiske og inkluderende medarbeidere?