1

Incident Management processen Definition på et Incident:

Målgruppen for processen: Medarbejdere, studerende og gæster på AU Ejerskab for processen: System- og procesejer: Thomas Degn Nielsen, Supportchef ARFA Principper for processen 1) Én fælles incident proces og én fælles service request proces. Nødvendigt af hensyn til

samarbejdet mellem front- og backoffice. Lokale justeringer i ét supportcenter må ikke afvige fra fælles hovedproces.

2) Alle sager skal registreres, også dem, man har med hjem fra besøg hos brugerne. Der indføres kvik- eller autosager for at undgå tidsspilde ved registrering af simple sager. Registrering danner grundlag for simple servicemål (fx antal åbne sager og gennemsnitlig løsningstid), som anvendes til interne forbedringer i processerne.

3) Brugeren skal opleve personlig kontakt ved alle henvendelser til AU IT. a. Ikke en anonym automatmail med et intetsigende sagsnummer, men en personlig

kontakt, når sagen påbegyndes. b. Hvis en løsning trækker ud / leveringstid er længere end forventet, kontaktes

brugeren. c. Når sagen er løst kontaktes brugeren – i starten blot for at bekræfte, at sagen er

løst, senere med opfordring til evaluering.

4) Tydeligt ansvar for brugerens henvendelse. Vi skal kommunikere, at vi tager imod henvendelsen og tager ansvar for den – også hvis den skal henvises til andre VD-områder.

5) Bestillinger af udstyr skal understøttes af et indkøbskatalog med standardvarer. Standardisering implementeres gennem frivillighed (standardvaren på lager, specialvaren med leveringstid).

6) Når udstyr skal udleveres til brugeren tilbydes opstillingshjælp.

En ikke-planlagt afbrydelse af en service eller en forringelse i kvalitet af en service. Formålet med processer er at genoprette servicen så hurtigt som muligt.

Eksempel: en printer virker ikke, en computer kan ikke tænde, der er ingen forbindelse til en server.

2

Skriftlige henvendelser

3

Telefoniske- og personlige henvendelser

4

Kviksager og Nilex sagsskabeloner

Procesaktivitet Beskrivelse Start Processen startes af en henvendelse fra en slutbruger eller et event.

Kviksager og skabeloner

Kviksager anvendes til at registrere sager fra studerende, som har henvendt sig personligt og hvor det ikke er vigtigt for AU IT at vide hvem der har fået hjælpe. Det kan fx være hjælp til opsætning af Eduroam. Sagsskabeloner anvendes til sager fra medarbejdere, hvor vi har behov for at kunne koble sag og bruger. Sagsskabelonerne gør det muligt at prædefinere en række oplysninger som sagens kategori og prioritet mv.

Modtagelse og registrering/Opgave registreret (Incident modtages og registreres i Nilex)

Opgaven modtages via - Mail - Web - Telefon - Personligt fremmøde - (Alarmer fra overvågningssystemer er ikke i scope)

Mail eller web Incident registreres automatisk med følgende oplysninger om bruger eller anmelder. Brugeroplysninger (Hvis brugeren selv henvender sig)

- Navn, Mailadresse, Telefonnummer, Kontor, Brugernavn, Afdeling, AU ID Anmelder (Hvis henvendelsen er lavet på vegne af en bruger)

- Navn, Mailadresse, Telefonnummer Telefon eller personligt fremmøde Incident modtages via telefon eller personligt fremmøde og brugerens stamdata søges frem og påføres sagen. Sagen gives en sigende overskrift. Hvis brugeren har kontaktet den forkerte supportafdeling modtages opgaven og sendes videre til den rette afdeling så opgaven kan løses.

Procesaktivitet Beskrivelse Prioritering Telefoniske- og personlige henvendelser prioriteres på lige fod med skriftlige henvendelser.

- Kan sagen løses hurtigt: løs den. - Kan sagen ikke løses hurtigt: skriv den ind i Nilex.

Tage fra bunken (Incident tages fra bunken over uløste opgaver)

Opgaven tages fra bunken over uløste opgaver og læses igennem inden de næste trin foretages. Det betyder, at man tager imod brugerens henvendelse og spørger ind til brugerens problem så den basale fejlbeskrivelse kan laves.

Kategorisering (Incident kategoriseres efter område og type)

Kategorisering er en klassificering af fejlen, som bruges til at synliggøre, hvilket problem henvendelsen drejer sig om. Herudover skal kategorisering bruges til:

- Lave spørgeguides baseret på kategori. - Analysere fejl og tendenser.

På sigt kan kategoriseringen bruges til at prioritere mellem systemer og services og danne grundlag for dokumentation på kendte fejl. Alt efter kategorisering kan der komme yderligere spørgsmål som skal besvares. Kategorisering (under udarbejdelse)

Er det et Service Request?

Sagstype angives - Incident (fejl) - Service Request (ikke fejl):

Procesaktivitet Beskrivelse

Hvis henvendelsen er et Request fortsætter opgaven jf. Service Request processen. Medmindre der er konkrete procesbeskrivelser af et Request skal Incident flowet anvendes fordi de skal igennem samme procestrin. Pt. vil det kun være indkøb, der fortsætter som Service Requests. Der skelnes mellem sagstyper fordi henvendelserne skal behandles forskelligt.

Prioritering (Incident prioriteres)

Hvis en givet sags løsning er akut skal en sag i Nilex følges op af et opkald/SMS til den relevante medarbejder og/eller teamleder. Spørg supportkoordinatoren eller supportchefen, hvis der er tvivl om prioriteten.

Første diagnose (Helpdesk vurderer om incident er set før og om der findes en kendt løsning)

Der søges i vidensdatabaser efter en kendt løsning eller et tilsvarende incident. ARFA, ST, HE og BSS benytter en række forskellige opslagsværker. Hvis henvendelsen er skriftlig kan det være nødvendigt at kontakte brugeren for at få yderligere oplysninger til fejlsøgning. Er henvendelsen telefonisk eller personlig stilles diagnosen sammen med brugeren. Findes der ikke en kendt løsning fortsættes med tildeling til en fra samme afdeling, en gruppe i samme afdeling eller en anden afdeling. Ved beskrivelse af problem kan det være nødvendigt at spørge ind til flere ting: HVAD er problemet?

- Hvilke komponenter? - Hvilke symptomer?

HVOR optræder problemet?

- Fysisk lokation? - Logisk lokation?

Procesaktivitet Beskrivelse

HVEM oplever problemet? - Hvilke(n) bruger(e)? - Hvilke(n) enhed(er)?

HVORNÅR optræder problemet?

- Udløsende handling? - Tidspunkt og varighed?

Opgave opdateret

Opgaven gemmes i tilfælde af at andre kolleger skal overtage den. Hvis henvendelsen er telefonisk eller personlig sendes en kvitteringsmail til brugeren.

Kan opgaven løses i support? (Der tildeles funktionelt til relevante 2. level / 3. level enhed)

Jeg kan løse opgaven: Fortsæt til Undersøgelse og Diagnose. Jeg kan ikke løse opgaven: Opgaven tildeles til den relevante funktion eller eskaleres til en leder. Den funktionelle tildeling til Drift, System og Udvikling eller Stab anvendes, hvis Support ikke kan løse problemet. Den er understøttet af en eskalationsmatrix, hvor ansvarsområder er beskrevet. Se eskalationsmatrix. Hvis opgaven skal varetages af et andet vicedirektørområde end AU IT ekspederes sagen videre og brugeren får besked om at opgaven er videregivet (sammen med ansvaret). Det vurderes om der er behov for en hierarkisk eskalation til en leder. En hierarkisk eskalation startes typisk af kundeklager, ved brud (eller muligt brud) på aftaler, osv. Det er muligt at angive en person som sagsejer, således at ejeren i support, kan se alle sager uanset hvilken afdeling sagen er tildelt.

Procesaktivitet Beskrivelse Det er supporten, der ejer opgaven.

Undersøgelse og diagnose (Undersøgelse med efterfølgende diagnose)

Der gennemføres en undersøgelse med efterfølgende diagnose, som løser brugerens problem eller hjælper brugeren videre. Det er vigtigt, at dokumentere hvilke løsninger/hvilken fejlsøgning der har været foretaget således at andre evt. kan fortsætte med opgaven. Hvis der ikke findes en løsning eller det tager længere tid fx fordi der skal laves en større fejlretning sættes status til afventer og brugeren informeres.

Løsning (Løsning implementeres)

Løsning implementeres og der gives besked til brugeren, således at brugeren kan efterprøve løsningen. Det sikres, at løsningen er dokumenteret i sagens note- eller løsningsfelt – nyeste kommentar indsættes altid øverst. Herefter markeres opgaven som løst og sagen stilles tilbage sagejeren.

Lukning (Incident lukkes efter løsning er implementeret)

Inden sagen lukkes helt sikres det at løsningen er skrevet ind i sagens note- eller løsningsfelt og at brugeren har fået et fyldestgørende svar. Det er supportens ansvar at følge op på sager klar til lukning dagligt. Hvis løsningen ikke er behørigt dokumenteret sendes opgaven retur til den tekniker, der har haft opgaven. Hvis løsningen er i orden får brugeren mail om at sagen er afsluttet og derfor lukkes. Brugeren kan herefter henvende sig, hvis løsningen ikke er tilfredsstillende. Sker dette genåbnes opgaven. Se statuskoder

Procesaktivitet Beskrivelse

Slut Opgaven er afsluttet.

Bilag 1: Eskalationsmatrix for AU Organisation Primære opgaver Grupper og sagstyper

Support 1. Level Helpdesk (Dispatch) Arbejdsopgaver er besvarelse og registrering af henvendelser til IT afdelingen. Der eskaleres videre til 1. level Back Desk, såfremt henvendelse ikke er set før. Ejerskab for alle henvendelser ligger her. 2. Level Back Desk Ansvarlig for opgaver der ikke løses i 1. Level

• ARTS Support o ARTS Emdrup o ARTS Indkøb o ARTS Aarhus

• BSS - support o BSS Bartholins Allé o BSS Fuglesangs Alle o BSS Herning o BSS Indkøb

• He - Support o HE Bartholin o HE Indkøb o HE Skejby o HE Tandlægeskolen

• ST - support o ST Foulum o ST Indkøb o ST Roskilde o ST Aarhus

Drift 3. Level

Ansvarlig for alle opgaver der tildeles fra support

Drift Generelle Applikationer Systemer der leveres bredt til brugere på AU.

• File services • Print services • Licens services

Organisation Primære opgaver Grupper og sagstyper • Deployment/Image håndtering • Software pakkekonstruktion • Special setups/ labs • Directory Services - AD, LDAP, integration på tværs mellem

systemer • IDM - fælles Identity Management • Mail og kalender/Exchange • SharePoint

Drift Administrative Applikationer Applikationer, der bruges eller ejes af en specifik administrativ gruppe, f.eks. økonomi eller au studier.

• Regnskabssystem - Navision drift og back-end support • HR (ikke applikations support) • ScanJour/Captia • LMS: Blackboard, Aula • STADS/EDDI - 2. level • Web - drift af Typo3 CMS, LMS og andre web systemer • Selvbetjening – sager vedr. mitAU.dk eller online formularer

Drift Netværksteam Netværk, f.eks. firewall, ikke standard netværksløsninger, VPN, net til nye bygninger. Teamet håndter er ikke ADSL.

• Wireless LAN - Planlægning, Performance optimering, Hardware, Software

• Sikkerhed - Firewall, Content filtrering, VPN, Tufin, Intern sikkerhed

• LAN - Planlægning, Performance optimering, Hardware, Software • Backbone - Planlægning, Performance sikring, Hardware, Software,

Organisation Primære opgaver Grupper og sagstyper Linje leje kontakt og kontrakter med ISPer

• Management & overvågning - Planlægning, appl. vedligehold, service kontrakter på udstyr, certifikat styring

Drift Skyen Interne AU services som f.eks. backup, serverovervågning, (virtuelle)servere.

• Datacenter/serverrum - Drift og vedligehold af datacenterlokationer, herunder køling, UPS styring, udbygning

• Virtualiseringsplatform - Planlægning, optimering, udvikling og drift af Vmware ESX miljø til server virtualisering

• Storageplatform - Planlægning, optimering, udvikling og drift af al storage til fælles it og til dels forsknings it

• Telefoni - Al drift og udvikling af AU’s telefonsystemer, analoge, digitale og IP telefoner

• Netservices - Vedligehold, udvikling og drift af al netværk infrastruktur og opkoblingspunkter for bygningerne

• Backup - Drift og udvikling af centralt backup miljø • Driftsovervågning og Management - Vedligehold og udvikling af

indrapporteringssystem til fejlmeldinger og driftsstatus Drift – stab

• Change Management - Etablering af Change Management retningslinjer og varetagelse af samme

• Driftindkøb • Afklaring af arkitekturspørgsmål fra Drift.

Bilag 2: Statuskoder

Statuskode I systemet Beskrivelse

Registreret Åben Henvendelse fra bruger er modtaget. Sagen er registreret i Nilex Tildelt Åben Sagen er tildelt, men løsning er ikke påbegyndt. I gang Åben Statuskode sættes når der arbejdes på en fejlanalyse eller et SR er ved at blive gennemført. Afventer leverandør Åben Incidents der er sendt til løsning hos leverandør. Afventer bruger Venter Incidents der afventer oplysninger/respons fra bruger inden en løsning kan identificeres Løst Klar til lukning Når workaround eller permanent løsning er implementeret sættes statuskode til sag løst. Lukket Lukket Efter kvalitetssikring af Incident beskrivelsen lukkes sagen.