IT- Servicedesk og Incident håndtering i MRFK

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- Support funksjonen og Incident prosessen. Herunder vektlegges ITIL- teori for å underbygge forståelsen av IT Service og hendelseshåndtering i Møre og Romsdal fylkeskommune. Innholdsfortegnelse IT- Servicedesk og Incident håndtering i MRFK... 1 Funksjonen IT Servicedesk:... 2 Hendelses prosessen:... 3 Mål med hendelses håndtering:... 3 Omfanget av Incident Management:... 3 Forskjellen mellom Incident/hendelse & Service Request:... 4 Verdi for MRFK ved å fokusere på Incident Management prosessen:... 4 Incident (hendelses) modell, prosess aktiviteter:... 4 Eskaleringsnivåer i Møre og Romsdal fylkeskommune:... 7 Oversikt over personell med fast tilhørighet i support linje: linje resursser utenfor IT- seksjonen:... 8 IT- personell tilhørende skoler tilknyttet IT- seksjonen/driftsgruppene:... 9 Sakskøer i OTRS: Sjekklister i OTRS: 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 IT- tjenesteleveransene 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 Support er å styre hendelser (incidents) og tjeneste forespørsler (service requests), og skal også håndtere kommunikasjon med brukerne. IT Support er en kritisk funksjon innenfor Incident- prosessen og blir også brukt av alle andre prosesser. Det primære målet for IT Support (Servicedesk) er å gjenopprette normal drift for en tjeneste så raskt som mulig og dermed minimere den negative effekten på virksomheten. 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 OTRS/web. IT Servicedesk sikrer at all samhandling er riktig identifisert og logget. Hver samhandling skal resultere i en sak i IT Servicedesk systemet, OTRS. Det er viktig at alle relevante opplysninger blir registrert. Alle IT- ansatte i MRFK skal logge så godt som mulig i OTRS, både ved mottak av saker pr. telefon og i eskaleringssituasjoner, dialog med sluttbruker og ved feilsøking og løsning av sak. OTRS 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. En OTRS- 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 Service eller en reduksjon i kvaliteten på en IT Service. Tjenesteanmodninger (Service Requests): En forespørsel om tilgang til en tjeneste som på forhånd er definert i tjenestekatalog. Spørsmål / forespørsel om informasjon: En forespørsel fra en bruker om informasjon om en tjeneste. Tilbakemelding: Brukeren ønsker å gi tilbakemeldinger, både positive (komplimenter) og negativ (klager) om IT- tjenesten I tillegg vil IT- Support (Servicedesk) opptre proaktivt og spille en viktig rolle i Event Management gjennom overvåking av IT- miljøet. 2

3 Hendelses prosessen: Grunnleggende regel for feilsøking: 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 Service Desk / IT- Support via; sluttbrukere, teknisk personale og event prosessen (Zabbix). Incident Management 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 oppdaget og rapportert fra Event Management prosessen. 3

4 Forskjellen mellom Incident/hendelse & Service Request: Selv om både Hendelser og ServiceRequest er en dialog til IT Support, 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. Verdi for MRFK ved å fokusere på Incident Management prosessen: Incident Management er en av de viktigste IT- prosessene. Det er ofte en av de første prosessene for å implementere ITIL og/eller tjenesteorientert IT arkitektur. Den er svært synlig for organisasjonen og kan umiddelbart gi organisatorisk verdi. Etter gjennomføringen vil Incident Management markere og begrunne andre prosesser på områder som trenger oppmerksomhet, som f.eks Problem håndtering og Endringshåndtering. Mer om dette ligger på Intranett under Støttefunksjoner + IT + IT- tjeneste orientert arkitektur. Verdien av Incident Management inkluderer: Evnen til å oppdage og løse hendelser resulterer i høyere tilgjengelighet av tjenesten. Evnen til å tilpasse IT- aktiviteten til organisasjonen. Evnen til å identifisere potensielle forbedringer i tjenestene. Proaktiv identifisering av systemforbedringer. Redusere virksomhetens forstyrrelser når hendelser oppstår. Administrere data og informasjon (til kunnskap). Bedre personalutnyttelse og effektivitet. Sikrer at hendelser blir registert i OTRS, for oversikt og evt. problem management. Mer nøyaktig CMDB (Configuration Management Database) informasjon. (For oss i IT- Seksjonen i MRFK betyr dette generell dokumentasjon, både i OTRS og WIKI, i tillegg til en oversikt over hendelser pr. CI (configuration item)) 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. 4

5 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. For hver bevegelse, logging, informasjon, eskaleringsinformasjon og lukking, så skal medgått tid registeres i OTRS. 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. 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 kategoriserer vi hendelsene etter IT tjeneste. I dette legges at hver IT tjeneste er en kategori i OTRS. Mer info i IT- : Tjenesteorientert- arkitektur/it- Tjenestekatalog 4- Incident prioritering En prioritetskode må tildeles hver hendelse, iflg ITIL teorien, noe som til daglig gjøres i OTRS ved å velge omfang, (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. - Høy: brukeren forventer hendelsen løses innen 3 arbeidstimer. - Kritisk: brukeren forventer hendelsen løst 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 5

6 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 Høy arbeids timer 3 Normal arbeids dag 4 Lav <=3 5 arbeids dager *) vurdering av problemet og SLA (hvis tilgjengelig), og en individuell vurdering. I OTRS så er kritikalitet knyttet til aktuell tjeneste, og man velger omfang ved opprettelse/identifisering av sak, slik at prioritering blir satt automatisk. Det er likevel viktig å ha klart for seg hvordan dette fungerer, og at man kan overstyre OTRS sin automatiske prioritering, hvis man leser nødvendighet for det. Sunn fornuft bør alltid legges til grunn. 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 service management support verktøy (OTRS) som hjelper service desk 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. 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, 6

7 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økeløsninger i OTRS, 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 Sjef og/eller IT Driftsleder 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 OTRS. Eskaleringsnivåer i Møre og Romsdal fylkeskommune: 1. Linje: ServiceDesk Primær, ServiceDesk Sekundær og ServiceDesk WalkIn, samt Morgenvakt. Morgenvakt har support fra Fra til består 1. linje av ServiceDeksk Primær, ServiceDesk Sekundær ServiceDesk WalkIn. Det siste vil si at IT seksjonen har tre personer på supportvakt på 1. linje. 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 Helpdesk/Brukerstøtte, 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 Jonas Berg Halås IKT lærling 7

8 Første linje support Erlend Westad IKT lærling Første linje support Jonas Midtbø Ephorte, vakter Andre linje support Andry Strømmen Andrianjafintrimo Fast 2.linje ressurs, IT- servicedesk, Problem mmgt 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 Øyvind Rakvåg Nettverk, IDM, NetCTRL,driftsvakter vakter elæringsansvarlig Asle Klock elæring, kursaktivitet Prosjektledelse Kjersti Mostervik Harstad Prosjektledelse Ledelse Driftsaktivitets-, driftsgruppeledelse, IT- servicedesk ansvar, backup for IT- sjef Ledelse Øverste IT- leder i MRFK. 2. linje resursser utenfor IT- seksjonen: Oversikt over Systemeiere med organisatorisk tilhørighet utenfor IT- seksjonen som ligger i OTRS, 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 Skoleadministrasjon Guttorm Vik Fagsystem Skole Ekstens, Vigo, Otto Vurdering og Fravær Gry Hansen Fagsystem Skole Skolearena LMS Learning Management Gry Hansen Fagsystem Skole Fronter system Bildedatabase Elin J. Lyngstad Fagsystem Fotoware Informasjon Spørreundersøkelser Inger Johanne Fagsystem Questback Moene Informasjon WEB- portaler Gjøran Sæther IT Infrastruktur EzPublish FDV Forvaltning, Drift og Leif Ståle Halås Fagsystem bygg Facilit Vedlikehold Prosjektstyring Rigmor Olsen Fagsystem bygg Holthe Prosjektsenter Ekstern koordinering - BYVE Oddleif Gustad Fagsystem bygg Eksterne leverandør saker Elektronisk billettering Arild Westad / Rune Stene Fagsystem - Samferdsel Fara 8

9 Holdeplassregister Arild Westad / Rune Stene Fagsystem - Samferdsel Trapeze Avvikssystem Martin Hauge Fagsystem Generelt Risk Manager 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 Klientadministrasjon John Helge Ulstein VGS Klientdrift/Brukerstøtte Grevstad Klientadministrasjon Richard Riise Ålesund VGS Klientdrift/Brukerstøtte Windows Joachim Vadseth Gjermundnes VGS Windows Nettverk Jørgen Søvik Ålesund VGS Infrastruktur Nettverk Paul Haavin Kristiansund VGS Infrastruktur Nettverk Andreas Ørsta VGS Infrastruktur Høydalsvik Nettverk Jo Gjeldnes Surnadal VGS Infrastruktur Nettverk Frank Henry Hansen Borgund VGS Infrastruktur Sakskø vs Driftsgruppe: - IT Seksjonen (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 Primær og ServiceDesk Sekundær. - Klientdrift: Alle PC/klient saker både hardware og software installert på tykke klienter skal inn i denne køen. ServiceDesk Sekundær er vakt på køen. Klientdrift starter opp med denne køen, etter prinsippet om å hente inn saker fra køen. ServiceDesk Sekundær og ServiceDesk WalkIn vaktene monitorer at saker ikke blir liggende i køen, men finner saksbehandler, og tildeler saker om det oppstår stillstand. Køen tilhører Klientdriftsteamet i Driftsgruppen Klient/Brukerstøtte. - 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. - Windows: Her legges saker som naturlig tilhører driftsgruppen Infrastruktur Windows. Tannhelse applikasjons saker (Opus, Romexis) skal inn her. Ephorte saker skal inn i denne køen. Tilsvarende 9

10 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. - Webutvikling: Her legges support og utviklingssaker som er knyttet til både interne og eksterne websider. (Internett og Intranett). Køen har epost varsling, men ikke en definert support vakt rolle. - SamKom: Her legges support og utviklingssaker som er knyttet til Samordnet Kommunikasjon; IP- telefoni, Video konferanse, CUCM- infrastruktur, bestilinger av IP- telefoni tjenester. Køen har epost varsling, men ikke en definert support vakt rolle. Rolledefinisjon Driftsgruppe og OTRS vakt: Den som har vakt på sakskø i OTRS, 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 køer med unntak av Klientdrift, Web- utvikling og SamKom har egen ukesvakt, 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 Primær på telefonvakt og ServiceDesk Sekundær på køvakt for IT- seksjonen kl , med unntak av Mandager hvor Morgenvakt har support frem til Sakskøer i OTRS: Tabellen under viser hvilke sakskøer vi har i supportsystemet (OTRS) 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 Tilhørende sakstyper Kommentar IT- seksjonen Hovedkøen all epost sendt til IT ServiceDesk i MRFK support@mrfylke.no IT- seksjonen: Infrastruktur Saker knyttet til nettverk Driftsgruppe Nettverk (WAN/LAN), internett, VPN, lagring, backup, Alfresco, Unix- driftssaker, Videokonferanse, IP- telefoni, NetCTRL. IT- seksjonen: klientdrift Nytt personlig IT utstyr, Driftsgruppe Klientdrift reinstallasjon av PC, feilsituasjoner på klient, nye applikasjoner på klienter i drift, og support/feil situasjoner på applikasjoner rullet ut på klienter. IT- seksjonen: Windows Saker knyttet til tynnklient/citrix, Driftsgruppe Windows serverdrift, Fagsystemer Tannhelse, ephorte, Avvikssystem, IT- seksjonen: Webutvikling Webutviklingssaker Driftsgruppe Infrastruktur IT- seksjonen; SamKom Saker knyttet til Videokonferanse, Driftsgruppe Infrastruktur; 10

11 IP- telefoni CUCM- team Skoler: Atlanten Skoler: Borgund Skoler: Fagerlia Skoler: Fræna Skoler: Gjermundnes Skoler: Kristiansund Skoler: Molde Skoler: Rauma Skoler: Romsdal Skoler: Romsdal::Internsaker Skoler: Sunndal Skoler: Surnadal Skoler: Tingvoll Skoler: Ulstein Skoler: Volda Skoler: Ålesund Skoler: Ørsta Systemeiere BYVE Facilit, Holthe Prosjektsenter, Ekstern koordinering - BYVE Se Fagsystem bygg i Systemeiere Dokumentsenter Saksbehandling/Dokumentarkiv (ephorte) Se Fagsystem Generelt i Systemeiere HRM ERP HR (Visma Lønn, Reiseregning) Se Fagsystem Generelt i Systemeiere::Info::Grafisk Fotoware Se Fagsystem Generelt i Systemeiere::Samferdsel Fara, Trapeze Se Fagsystem Samferdsel i Systemeiere::Utdanning Fronter, Extens, Vigo, Vigo- voksen, Vurdering og Fravær, Se Fagsystem Skole i Systemeiere::Økonomi Visma Økonomi/Faktura Se Fagystem Generelt i Sjekklister i OTRS: 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 Primær ServiceDesk Sekundær ServiceDesk WalkIn Morgenvakt Definisjon Primær fokus på telefonvakt, men også OTRS køene, hovedansvar for logging, kategorisering og initell diagnose og evt. løsning på telefon saker. Primær fokus på OTRS køene og kvalitet mottatte epost saker i OTRS; 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: 11

12 Referanser: Sjekkliste morgenvakt Endringshåndteri ng i MRFK Problemhåndterin g i MRFK SupportKalender Sjekkliste større hendelser (Major incident rutine) IT dokumentasjons- oppbygging I Møre og Romsdal fylkeskommune IT- servicedesk i Møre og Romsdal fylkeskommune Tjenesteorientert- arkitektur/it- tjenesteorientert- dokumentasjon Tjenesteorientert- arkitektur/it- tjenesteorientert- dokumentasjon G:\SupportKalender\Supportkalender MRFK.xlsx Tjenesteorientert- arkitektur/it- tjenesteorientert- dokumentasjon mune.pdf Molde, IT- Driftsleder, IT- Seksjonen, MRFK IT- Sjef, IT- Seksjonen, MRFK (Godkjent dokument) 12