Innholdsfortegnelse. IT-Servicedesk og Incident håndtering i MRFK Bakgrunn:

Transkript

1 IT-Servicedesk og Incident håndtering i MRFK Bakgrunn: Bakgrunnen for dette dokumentet er å skape en felles forståelse for nivå av servicenivået vi skal gi til brukerne våre i MRFK, og fokus på IT-Servicedesk funksjonen og Incident prosessen. Herunder vektlegges ITIL-teori for å underbygge forståelsen av IT Servicedesk og hendelseshåndtering i Møre og Romsdal fylkeskommune. Innholdsfortegnelse IT-Servicedesk og Incident håndtering i MRFK... 1 Bakgrunn... 1 Funksjonen IT Servicedesk:... 2 Hendelses prosessen:... 3 Definisjon på Incident Management (Hendelses håndtering):... 3 Formål med hendelses håndtering:... 3 Mål med hendelses håndtering:... 3 Omfanget av Incident Management:... 3 Forskjellen mellom Incident/hendelse & Service Request:... 4 Eskalering av Service Request:... 4 Incident (hendelses) modell, prosess aktiviteter:... 4 Status på hendelser og tjenesteforespørsler:... 8 Eskaleringsnivåer i Møre og Romsdal fylkeskommune:... 8 Oversikt over personell med fast tilhørighet i support linje: linje resursser utenfor IT-seksjonen:... 9 IT-personell tilhørende skoler tilknyttet IT-seksjonen/Driftsgruppene: Sakskø/Team i Pureservice vs Driftsgruppe: Vaktordning pr. uke: Sakskøer i Pureservice: Sjekklister/Knowledge mmgt: Support roller på IT-serviceDesk: Referanser:

2 Funksjonen IT Servicedesk: IT Servicedesk er den funksjonen som sluttbrukerne i Møre & Romsdal Fylkeskommune, heretter kalt MRFK, kontakter og samhandler med på daglig basis. Dette er den mest kritiske funksjonen fra ett sluttbrukerperspektiv, da IT-Support (Servicedesk) er den eneste funksjonen innenfor ITtjenesteleveransene som sluttbruker kommuniserer med direkte. IT Servicedesk i MRFK fungerer som et enkelt kontaktpunkt (SPOC) mellom tjenesteyter (IT- Seksjonen) og brukerne. Rollen til funksjonen IT Servicedesk er å styre hendelser (incidents) og tjeneste forespørsler (service requests), og skal også håndtere kommunikasjon med brukerne. IT Servicedesk er en samlende funksjon innenfor Incident-prosessen og blir også brukt av alle andre prosesser. Det primære målet for IT Servicedesk er å gjenopprette normal drift for en tjeneste så raskt som mulig og dermed minimere den negative effekten på kjerne produksjonen vår. Man sikrer at optimale nivåer av service, kvalitet og tilgjengelighet opprettholdes. "Normal tjeneste operasjon" er her definert som tjenestedrift innenfor Service Level Agreement (SLA) grenseverdier. Hovedaktiviteten til IT Servicedesk er å samhandle med sluttbrukere. En samhandling er her definert som enhver form for interaksjon med IT Servicedesk, f.eks gjennom en telefon samtale, direkte e- post, walk-in, SMS, eller IT Servicedesk sikrer at all samhandling er riktig identifisert og logget. Hver samhandling skal resultere i en sak i IT Servicedesk systemet, Pureservice. Det er viktig at alle relevante opplysninger blir registrert. Alle IT-ansatte i MRFK skal logge så godt som mulig i Pureservice, både ved mottak av saker pr. telefon og i eskaleringssituasjoner, dialog med sluttbruker og ved feilsøking og løsning av sak. Ved innmelding av hendelse eller tjenesteforespørsel, skal også innmelder/sluttbruker søke å beskrive aktuell problemstilling så godt som mulig, og ved bestillinger bruke bestillingskjema som ligger i selvbetjeningsportlen; Pureservice fungerer som en kunnskapsbase, både for IT-personell og sluttbrukere, og detaljerte rapporter om incidenter, statistikker og gjentatte hendelser ligger her, som en konsekvens av god saksdokumentering. FAQ-databasen i OTRS utgjør i hovedsak denne kunnskapsdatabasen i Møre og Romsdal fylkeskommune. Knowledge modulen i Pureservice er forsinket, men er estimert klar for oss sommer En Pureservice-sak er kategorisert på type hendelse og prioriteres basert på effekt og feilsituasjon. Disse interaksjonene kan være en av fire grunnleggende typer: Hendelser (Incident): En uforutsett svikt til en IT tjeneste eller en reduksjon i kvaliteten på en IT tjeneste. Tjenesteforespørsler (Service Requests): En forespørsel om tilgang til en tjeneste som på forhånd er definert i tjenestekatalog. 2

3 Problem: Engen definert prosess for problem mmgt i Møre og Romsdal fylkeskommune. I tillegg vil IT-Servicedesk opptre proaktivt og spille en viktig rolle i Event Management gjennom overvåking av IT-miljøet. Hendelses prosessen: Grunnleggende regel for problemstillingsforståelse: Spør hva brukeren ønsker å oppnå - aldri bare løse problemet. Det kan være en enklere måte, eller andre anbefalte løsninger. Definisjon på Incident Management (Hendelses håndtering): Hendelseshåndterings prosessen (Incident management) er ansvarlig for å minimere skadevirkningene ved et avvik i en tjeneste ved å konsentrere seg om å gjenopprette sluttbrukertjenesten til normal drift så raskt som mulig. Hendelser blir rapportert til IT Service Desk via; sluttbrukere, teknisk personale og event prosessen (Zabbix, ControlUp, Cisco Prime, Microsoft SCCM). Hendelseshåndtering (incident) er prosessen for å håndtere alle "hendelser", som kan inkludere: Feil Spørsmål Generelle henvendelser til IT Formål med hendelses håndtering: Hensikten med hendelseshåndtering (Incident management) er å sikre at optimalt nivå på service, kvalitet og tilgjengelighet opprettholdes. Mål med hendelses håndtering: De primære mål for hendelseshåndtering er å: Gjenopprette normal drift på en tjeneste så raskt som mulig. Minimere negativ innvirkning av en hendelse. Oppdage og løse hendelser. Justere IT-aktivitet til organisatoriske prioriteringer. Identifisere potensielle forbedringer av tjenestene Identifisere behov for flere tjenester eller krav til opplæring. Omfanget av Incident Management: Incident management omfatter enhver hendelse som forstyrrer, eller som kan forstyrre, en tjeneste. Dette inkluderer hendelser kommunisert av sluttbrukerne gjennom Service Desk eller hendelser 3

4 oppdaget og rapportert fra Event management prosessen. Forskjellen mellom Incident/hendelse & Service Request: Selv om både Hendelser og ServiceRequest er en dialog med IT-servicedesk, er de ikke like. En tjenesteforespørsel er vanligvis noe som er planlagt, mens en hendelse vanligvis er en uforutsett hendelse. For eksempel er en anmodning om en ny PC forventet, og er en planlagt service. En svikt i en PCs harddisk er en uventet avbrudd i tjenesten. Eskalering av Service Request: Bestillingsskjema for brukere (nyansatte) er etablert for alle skoler og for sentraladministrasjonen i Møre og Romsdal fylkeskommune. Skjemaene finnes i selvbetjeningsportalen; Request forfilment, altså rutine for oppfølging av bestillingskjemaene finnes her: For skolene er det viktig at det følges med i IKT-skolenavn team-køen, og at slike bestillinger eskaleres raskt til IT-Servicedesk. Incident (hendelses) modell, prosess aktiviteter: Incident modellen i Møre og Romsdal fylkeskommune består av: 1-Incident Identifikasjon En hendelse må påvises for å starte hendelseshåndterings prosessen. Incident identifikasjon vil overvåke viktige komponenter slik at hendelser eller potensielle hendelser oppdages så tidlig som mulig i hendelseshåndterings prosessen. Det er viktig å skille mellom hendelse, og ServiceRequest, forespørsel om ny IT tjeneste, og andre endringshenvendelser (change), før man jobber med forespørsler som en hendelse. 2-Incident Logging Alle hendelser må identifiseres, tidfestes, og logges. Dette er ansvaret til Service Desk funksjonen (førstelinje), men vil bli delt av alle grupper som er tildelt ansvar i hendelsesprosessen. Ved telefonsamtaler fra sluttbruker til IT Service Desk skal alltid følgende registreres: Registrere informasjon om når hendelsen inntraff, grundig problembeskrivelse og hvor mange ganger problemet har oppstått. Tilby løsningen hvis mulig og avslutte saken. Dersom hendelsen gjentar seg vil det bli gjenstand for Problem Management prosessen. I slike tilfeller kontakt teknisk ansvarlig for løsningen i IT-seksjonen. 4

5 3-Incident Kategorisering En av de første aktivitetene i Incident Logging, basert på ITIL teorien, er å kategorisere hendelsen som vil tilrettelegge for ytterligere overvåking, rapportering og eskalering. Denne kategoriseringen tjener også til å kontrollere at den rapporterte hendelsen faktisk ikke er en Service Request som skal videreformidles til Request Fulfillment prosessen. En kategori og underkategori blir ofte brukt til å gi bedre støtte til gruppen og / eller prosesser som skal følges. Kategorisering av hendelser kan også gjentas som en del av "hendelse/incident lukking" aktivitet hvor det er funnet at de opprinnelige kategoriseringer var feil. I Møre og Romsdal fylkeskommune har vi følgende kategorier på IT i Pureservice: Praktisk bruk av kategorier: Figur 1: På en sak, justerers kategorioppsettet som vist til høyre. Figur2: Relevant kategori velges, og man trykker lagre. Skolene i Møre og Romsdal fylkeskommune har følgende kategorioppsett: IT-Servicedesk sentralt og tilhørende driftsgrupper har følgende kategorioppsett: 4-Incident prioritering En prioritetskode må tildeles hver hendelse, iflg ITIL teorien, noe som til daglig gjøres i Pureservice ved å velge prioritet, (se siste avsnitt i dette kapittelet). Denne prioriteringskoden vil bestemme hvordan hendelsen er håndtert av både støtteverktøy og støttepersonell. Prioritering må ta hensyn til en kombinasjon av: Haster - knyttet til tidsrammen som sluttbrukeren krever Incident skal løses. - Lav: brukeren forventer hendelsen løses innenfor 5 arbeidsdager. - Normal: brukeren forventer hendelsen løses innen 2 arbeidsdager. 5

6 - Høy: brukeren forventer hendelsen løses innen 3 arbeidstimer. - Kritisk: brukeren kan forvente at hendelsen påbegynt innen 15 minutter. Omfang - direkte relatert til den negative effekten for organisasjonen som helhet og bør defineres innenfor SLA (Service Level Agreement). En indikasjon på virkningen er ofte (men ikke alltid) det antall sluttbrukere som blir berørt. Lav: 1-3 brukere Medium: 4-9 brukere Høy: 10 eller flere brukere Prioritets - matrise: første sammenfatter "Matrix verdi" for haster og konsekvens Omfang \ Prioritet Manuell (0) Lav (1) Normal (2) Høy (3) Kritisk (4) Lavt omfang (1) N/A, manual 1+1 = = = = 5 Medium omfang (3) N/A, manual 3+1 = = = = 7 Høy konsekvens (5) N/A, manual 5+1 = = = = 9 Finn så korrekt prioritet i tabellen under: Prioritet Beskrivelse Matrise Verdi Mål - løsningstid *) 1 Kritisk minutter 2 Alvorlig arbeids timer 3 Normal arbeids dag 4 Lav <=3 5 arbeids dager 5 Bestilling n/a Følger normal aktivitet pr. tjeneste. *) vurdering av problemet og SLA (hvis tilgjengelig), og en individuell vurdering. I Pureservice så er kritikalitet knyttet til aktuell sak (hendelse/bestilling), og man velger prioritering ved opprettelse/identifisering av sak. Sunn fornuft bør alltid legges til grunn. Praktisk bruk av prioritet i Pureservice: Figur 3: Prioritering velges av saksbehandler i menyen til venstre på aktuell sak (hendelse/tjenesteforespørsel). 6

7 5-Initiell Diagnose Initiell diagnose er utføres vanligvis av førstelinje der hendelsen er meldt til IT Servicedesk. Ved vil spørsmål til sluttbruker være viktig, og logging av all tilgjengelig informasjon om hendelsen. Initiell støtte innebærer: Løse Hendelse basert på kunnskap og / eller erfaring. Løse Hendelser med Pureservice som hjelper IT-servicedesk med å finne en løsning blant tidligere uhell, problem, kjente feil, kunnskapsdatabase. Hvis mulig, vil IT Support vakt løse hendelsen på første diagnose uten hjelp fra andre støttegrupper, og vil deretter lukke hendelsen. 6-Incident Eskalering En hendelse som ikke kan løses innenfor fristene til førstelinje (IT-servicedesk) vil bli videresendt til "neste-in-line"-støtte. Denne opptrappingen innebærer en overføring av ansvaret for videre undersøkelser. IT Servicedesk førstelinje skal til enhver tid spore hendelsens fremgang, holde sluttbrukere informert, og for å verifisere vellykket løsning. Saker skal eskaleres til rett driftsvakt, driftsgruppe, altså team i Pureservice. De to eskaleringsstiene er funksjonelle og hierarkisk eskalering: Funksjonell eskalering oppstår når flere ferdigheter er pålagt for å løse en hendelse, basert på tid, prioritet og / eller kunnskap tilgjengelighet. Hierarkisk eskalering oppstår når høyere myndighet må gjøres tilgjengelig for beslutningstaking, basert på effekt og tid. Førstelinje skal utføre den første diagnose og fokusere på å løse en hendelse eller oppfylle en tjeneste forespørsel, så snart som mulig. Service Management Support Tools: søkefunksjon i Pureservice, bruk av sjekklister og diagnostiseringsverktøy. Her er det viktig å holde seg oppdatert på FAQ-databasen i OTRS, og Journalen i OTRS skal alle holde seg oppdatert på. En hendelse bør aldri eskaleres direkte fra 1. linje til 3. linje. (Se Eskaleringsnivåer i MRFK i neste avsnitt). Det eneste unntaket er når en større hendelse inntreffer. Ved større hendelser vil (brann, tyveri, vannskade, eller annet som som påvirker mange tjenester/brukere) vil IT Driftsleder, evt. ITsjef i IT Seksjonen avgjøre hvilke resurser som må settes av og hendelsen kan overdras til tjenesteeier i IT-seksjonen umiddelbart. Sakseier til enhver tid har samlet eierskap til hendelsen, som betyr at de er ansvarlige for å identifisere problemet, holde kunden oppdatert når det trengs, og til slutt lukke hendelsen. Tar det mer en 3 dager å løse en sak, skal bruker/bestiller ha tilbakemelding, så for det er identifisert at sak tar lang tid, fortrinnsvis ha løst og lukket saken i Pureservice. 7

8 Status på hendelser og tjenesteforespørsler: En sak i Pureservice (hendelse, tjenesteforespørsel eller problem) har følgende statuser: STATUS FORKLARING Ny Tildelt Under arbeid Venter intern Venter ekstern Venter sluttbruker Løst Lukket Sak er urørt og hånteres av 1. linje Enten eskalert til driftsgruppe eller og/eller person Saksbehandling pågår Venter på interne avklaringer Venter på eksterne avklaringer Venter på info fra sluttbruker Er løst, normalisert tjenestegrad. Brukes når klar løsning forefinnes. Systemteknisk så er det mulig for sluttbruker å gjennåpne sak ved svare på epost knyttet til saken i en tidsbegrenset periode etter at den har fått status løst. Lukket, uansett løsningsgrad, og brukes der løsning ikke finnes, eller svar har uteblitt så sak ikke kunne løses. Systemteknisk så kan ikke sak gjennåpnes etter at sak har fått status lukket. Svar på sak vil da åpne opp en ny sak i Pureservice. Ved avslutning av sak skal det beskrives så godt som mulig hva løsningen innebar og evt. info som er viktig for videre bruk av tjenesten. Eskaleringsnivåer i Møre og Romsdal fylkeskommune: 1. Linje: ServiceDesk Supervisor, Servicedesk 1 og Servicedesk 2, samt Morgenvakt. Morgenvakt har support fra Fra til består 1. linje av Servicedesk Supervisor, Servicedesk 1 Servicedesk 2. Det siste vil si at IT seksjonen har tre personer på supportvakt på 1. linje. Har ansvar for at saker ikke blir liggende ubesvart over 24 timer. 2. Linje: Nettverksvakt og Windows vakt, men også rollen 2. Linje support i ordinær linje, samt driftsgruppemedlemmer i og utenfor IT Seksjonen, og Tjenesteeiere. Med Tjeneste eier menes leder for prosess/avdeling/seksjon som bruker enkelte IT Tjenester. 3. Linje: Tung spesial kompetanse, og da fortrinns vis eksterne partnere/konsulenter. Første linje eskalerer til andre linje, som evt. kontakter tredje linje. Det skal ikke under noen omstendighet skje at 1. linje eskalerer direkte til 3. linje. God identifisering, logging og bruk av sjekklister (Faq fra OSS modulen i OTRS og Wiki) er grunnleggende prinsipper. I tillegg, overstiger individuelle saker mer en 20 åpne saker for en rådgiver, så kontaktes IT Driftsleder for håndterings rådgivning. Oversikt over personell med fast tilhørighet i support linje: Eskaleringsnivå Navn Kommentar Første og andrelinje support Brit-Inger Monsås IT-Servicedesk dag til dag ansvar, Visma drift Første og andre linje support Are Skotnes Tech SCCM, Antivirus, klientdrift, Problem mmgt. Første og andre linje support Olav Berge Apple produkter, Cisco Videokonferanse og IP-telefoni Første linje support Vegard Øvrelien IKT lærling Første linje support Benjamin Miguel Gjevik IKT lærling 8

9 Andre linje support Jonas Midtbø Ephorte, driftsvakter Andre linje support Andry Strømmen Andrianjafintrimo Fast 2.linje ressurs Windowsgruppen, IT-serviceDesk, Tannhelse Andre linje support Asbjørn Jørgensen Print, innkjøp klientutstyr, Avviksystem Andre linje support Torstein Mittet Citrix, AD, MS Server, driftsvakter Andre linje support Ståle Inge Muri Fagapplikasjoner Tannhelse, Citrix, driftsvakter Andre linje support Gjøran Sæther IDM, Alfresco, Ezpublish, Backup, Nettverk, driftsvakter Andre linje support Gudmund Oterhals Lagring, backup, nettverk, driftsvakter Andre linje support Andreas Høydalsvik Nettverk, Alfresco, IDM, NetCTRL, driftsvakter Andre linje support Øyvind Rakvåg Nettverk, IDM, NetCTRL,driftsvakter Andre Linje support Rune Stene Samordnet Kommunikasjon (Voice og Video) Ikke involvert I support til daglig Eilen Amundsgård Integrasjonsarkitekt Prosjektledelse Kjersti Mostervik Harstad Prosjektledelse Ledelse Driftsaktivitets-, driftsgruppeledelse, IT-servicedesk eierskap, Nestleder og backup for IT-sjef Ledelse Dagfinn Grønvik Øverste IT-leder i MRFK. 2. linje resursser utenfor IT-seksjonen: Oversikt over Systemeiere med organisatorisk tilhørighet utenfor IT-seksjonen som ligger i Pureservice, og er å betrakte som 2. linje personell, ihht til overnevnte beskrivelse av eskaleringsnivåer i MRFK. Det vil være med utgangspunkt i tjenestebeskrivelser lokalisert på wiki.mrfylke.no, at vi har detaljert informasjon om prosedyrer på wiki, eller faq i OTRS, som skal følges, eller er relevante. Tjeneste Navn Virksomhetsområde Kommentar ERP Økonomi Siv Talstad Hansen Sentraladministrasjonen Visma ERP HR Gunnar Malme Sentraladministrasjonen Visma ERP E-Handel Torgeir Riksfjord Sentraladministrasjonen Visma Saksbehandling/Dokumentarkiv Ruth Wenche Sentraladministrasjonen Ephorte Stavik/Elisabeth L. Flemmen Skoleadministrasjon Knut Erik Rød og Fagsystem Skole Ekstens, Vigo, Otto Anders Aarøe Vurdering og Fravær Gry Hansen, Tor Fagsystem Skole Skolearena Pettersen og Anders Aarøe LMS Learning Management system Gry Hansen, Tor Fagsystem Skole It`s Learning Pettersen og Anders Aarøe Hjernen og Hjertet Harald J. Tomren og Fagsystem - Skole Helene Loe Arntsen Bildedatabase Elin J. Lyngstad Fagsystem Informasjon Fotoware Spørreundersøkelser Inger Johanne Moene Fagsystem Kommunikasjon Questback WEB-portaler Gjøran Sæther IT Infrastruktur EzPublish FDV Forvaltning, Drift og Vedlikehold Leif Ståle Halås Fagsystem bygg Facilit Prosjektstyring Rigmor Olsen Fagsystem bygg Holthe Prosjektsenter Ekstern koordinering BYVE Oddleif Gustad Fagsystem bygg Eksterne leverandør saker Elektronisk billettering Arild Westad / Toril Karlsnes Viken Fagsystem Samferdsel Fara Holdeplassregister Arild Westad / Toril Karlsnes Viken Fagsystem Samferdsel Trapeze 9

10 Avvikssystem Martin Hauge Fagsystem Generelt Risk Manager elæring Elin J. Lyngstad/Ingvild Fagsystm Kommunikasjon n/a D. Sæther IT-personell tilhørende skoler tilknyttet IT-seksjonen/Driftsgruppene: Tabellen under viser IT-personell tilknyttet skoler, som deltar fult ut som driftsgruppemedelemmer i to av IT-seksjonens driftsgrupper, og er å betrakte som 2. linje ressurser på IT tjenester som Klientadministrasjon/Tykkeklienter samt Nettverk. Tjeneste Navn Tilhørende skole Driftsgruppe Klientadministrasjon Ronny Tjelle Romsdal VGS Klientdrift/Brukerstøtte (Permisjon) Klientadministrasjon John Helge Grevstad Ulstein VGS Klientdrift/Brukerstøtte Windows Tommy Skalstad Fylkesbiblioteket Windows (Tannhelse) Nettverk Jørgen Søvik Ålesund VGS Infrastruktur (Permisjon) Nettverk Paul Haavin Kristiansund VGS Infrastruktur Nettverk Andreas Høydalsvik Ørsta VGS Infrastruktur Nettverk Jo Gjeldnes Surnadal VGS Infrastruktur Sakskø/Team i Pureservice vs Driftsgruppe: -IT Servicedesk (Hovedkøen): Her legges alle saker som ikke er blitt eller blir eskalert til de to andre driftsgruppene, og som faller inn under Driftsgruppen Klient-Brukerstøtte. SCCM saker, applikasjonsforespørsler, klientsaker/forespørsler (både WinPC og Mac), samt epost problematikk faller naturlig inn her. Tre roller tilknyttet IT-seksjonen har ansvaret for denne køen, Morgenvakt, Servicedesk 1 og Servicedesk 2. - IT Bestillinger: Arbeidskø for IT-Servicedesk, der bestillinger (Servicerequests), innen brukerkontoer, tilganger og personlig IT-utstyr. - IT-Infrastruktur: Her legges alle saker som tilhører driftsgruppen Infrastruktur - Nettverk. Her går eskalerte saker knyttet til Videokonferanse, IP-telefoni, WAN, LAN, Routing, Switching, VmWare, Lagring. Alfresco. Ukentlig rullering av infrastruktur vakt-rolle, som har ansvaret for saksflyt i køen. -IT-Windows: Her legges saker som naturlig tilhører driftsgruppen Infrastruktur Windows. Tannhelse applikasjons saker (Opus, Romexis), Ephorte saker skal inn i denne køen. Tilsvarende gjelder for Visma. Alt som går på Citrix, AD, Windows server skal også inn i denne gruppen. Ukentlig rullering av Windows vakt-rolle, som har ansvaret for saksflyt i køen. - Pakkeproduksjon/Klientdrift: Her legges bestillinger av nye applikasjonspakker, spørsmål knyttet til tykkeklienter, hardware, avtaler, feilmeldinger og problemstillinger knyttet til applikasjoner i Appkatalogen, spørsmål av generell klientdriftskarakter. Køen har fått definert fast vaktordning, hvo ukedagene er fordelt på teamets medlemmer. 10

11 - SamKom: Her legges support og utviklingssaker som er knyttet til Samordnet Kommunikasjon;Jabber IP-telefoni, Video konferanse, CUCM-infrastruktur, bestilinger av IP-telefoni tjenester. Saker følges opp av Nettverksvakten og fordeles i SamKom teamet. Rolledefinisjon Driftsgruppe og driftsgruppe-vakt: Den som har vakt på sakskø/team i Pureservice, har det overordnede ansvaret for fremdrift og aktiviteter frem mot endelig løsning på saker. Saker som blir liggende i kø ved ukeslutt, overtaes av neste vakt, og rapportering skjer hver Fredag etter angitte parametre for hver vakt. Vaktordning pr. uke: Alle driftsdisipliner (Infrastruktur, Windows og Klientdrift) har egen vakt, med representant fra tilhørende driftsgruppe. Morgenvakt må være pålogget og klar til å ta imot support telefoner kl Morgenvakten avløses av Servicedesk Supervisor på telefonvakt og Servicedesk 1 på køvakt for IT-servicedesk kl , med unntak av Mandager hvor Morgenvakt har support frem til Sakskøer i Pureservice: Tabellen under viser hvilke sakskøer/team vi har i supportsystemet (Pureservice) i Møre og Romsdal fylkeskommune, og hvilke sakstyper som skal inn i hver enkelt sakskø. Alle eposter sendt til support@mrfylke.no havner i køen IT-seksjonen, med unntak for ansatte ved skoler listet opp i tabellen under. Ansatte ved disse skolene, vil ved sending av epost til support@mrfylke.no få sin sak inn i køen som gjelder aktuell skole. Skolens IT-funksjon vil evt. flytte saken over til andre relevante køer ved behov. Kønavn/teamnavn Tilhørende sakstyper Kommentar IT-servicedesk Hovedkøen all epost sendt til IT Servicedesk i MRFK support@mrfylke.no og innmeldinger via IT-Infrastruktur Saker knyttet til nettverk (WAN/LAN), Driftsgruppe Nettverk internett, VPN, lagring, backup, Alfresco, Unix-driftssaker, Videokonferanse, IP-telefoni, NetCTRL. IT-Windows Saker knyttet til tynnklient/citrix, serverdrift, Fagsystemer Tannhelse, ephorte, Avvikssystem, Driftsgruppe Windows Dette er køen driftsvakten for Windowsgruppen er dispatcher for igjennom driftsvakten. IT-Windows Citrix Citrix saker Driftsgruppe Windowsdrift IT-Windows Exchange Epost saker Driftsgruppe Windowsdrift IT-Windows Print Print saker Driftsgruppe Windowsdrift IT-Windows ephorte Sak-/Arkiv saker Driftsgruppe Windowsdrift IT-Windows Utdanningapp Saker knyttet til Driftsgruppe Windowsdrift Utdanningsapplikasjoner, som håndteres av IT-seksjonen IT-Windows Tannhelseapp Saker knyttet til Tannhelse Driftsgruppe - Windowsdrift IT-SamKom Saker knyttet til Videokonferanse, IPtelefoni, Jabber Driftsgruppe Infrastruktur; CUCMteam IT-Bestillinger Servicerequester som tar tid Driftsgruppe ITservicedesk/klientdrift IT-Pakkeproduksjon/klientdrift Saker knyttet til pakkeproduksjon, appkatalogen og klientdrift Driftsgruppe ITservicedesk/klientdrift Atlanten Borgund Fagerlia Fræna 11

12 Gjermundnes Kristiansund Molde Rauma Romsdal Sunndal Surnadal Tingvoll Ulstein Volda Ålesund Ørsta BYVE Facilit, Holthe Prosjektsenter, Ekstern koordinering BYVE Se Fagsystem bygg i Dokumentsenter Saksbehandling/Dokumentarkiv (ephorte) Se Fagsystem Generelt i Systemeiere HRM ERP HR (Visma Lønn, Reiseregning) Se Fagsystem Generelt i Grafisk Fotoware Se Fagsystem Generelt i Samferdsel Fara, Trapeze Se Fagsystem Samferdsel i Utdanning Fronter, Extens, Vigo, Vigo-voksen, Vurdering og Fravær, Se Fagsystem Skole i Økonomi Visma Økonomi/Faktura Se Fagystem Generelt i Sjekklister/Knowledge mmgt: I FAQ databasen til OTRS finnes sjekklister sortert pr. IT-tjeneste for 1. Linje support, med løsningsforslag og evt. hva som skal følge av info før eskalering til 2. Linje support (teknisk ansvarlig eller tjenesteeier). Køvakter sjekker ved ukestart om det har kommet nye sjekklister i FAQ-databasen i OTRS. Dette gjøres under menyvalget FAQ + Journal i OTRS. Support roller på IT-serviceDesk: Rolle Servicedesk Supervisor Servicedesk Sekundær Servicedesk WalkIn Morgenvakt Definisjon Primær fokus på telefonvakt, men også Pureservice køene, hovedansvar for logging, kategorisering og initell diagnose og evt. løsning på telefon saker. Primær fokus på Pureservice køene og kvalitet mottatte epost saker i Pureservice; logging, kategorisering og initell diagnose, samt lukke saker. Primær fokus på walk-in support, inn/ut levering av personlig IT-utstyr, og help-runner for onsite support på fylkeshuset. Backup telefonsupport og sakskø oppfølging. Har en fast instruks: 12

13 Referanser: Sjekkliste morgenvakt Endringshåndtering i MRFK Problemhåndtering i MRFK SupportKalender Sjekkliste større hendelser (Major incident rutine) IT dokumentasjonsoppbygging I Møre og Romsdal fylkeskommune IT-servicedesk i Møre og Romsdal fylkeskommune IT-Servicedesk - Rutineindex Eskaleringsgrunnlag, Skoler, IT og Utdanning: skommune.pdf Molde, IT-Driftsleder/nestleder IT Møre og Romsdal fylkeskommune 13