Zobbe Consult
       
       
      Keep IT simple & smart
       
Skip Navigation Links
Forside
ITIL og StandarderExpand ITIL og Standarder
LederExpand Leder
KursisterExpand Kursister
ProcesejereExpand Procesejere
YdelserExpand Ydelser
DiverseExpand Diverse
Skip Navigation LinksForside > Procesejere > Alfabetisk proces oversigt > Incident Management Login

Incident Management

Introduktion

Denne beskrivelse er ikke lavet helt færdig!
Incident management processen har til formål at sikre at Incidents bliver løst hurtigt. En Incident er: "En uplanlagt afbrydelse af en IT service eller en reduktion i kvaliteten. En fejl i en CI som senere kan betyde en afbrydelse eller en reduktion i kvaliteten er også en Incident".
(Mangler: noget om Incident models)

Input

Det primære input til Incident processen er primært information om den enkelte Incident samt dokumentation der skal bruges til at løse Incidenten

  • Information om Incidenten (Se under Information)

Output

Output fra processen er primært "Løste Incidents". Hertil kommer diverse rapporteringer.

Procedurer og Aktiviteter

Proceduren: Incident

Dette er proceduren til at håndtere normale Incidents. Proceduren trigges af en Incident.

Trigger:

Incident

Opdagelse af Incident

At der er opstået et Incident kan opdages af mange forskellige. De primære kilder er:

  • Brugeren der ringer/emailer/.. til Service Desk for at få registreret Incidenten
  • IT tekniker der opdager en fejl under hans arbejde
  • Under udførelse af Event management processens aktiviteter (evt. af automatisk af et overvågnings system) konstateres at et Incident er opstået.

Ansvarlig: Incident manager

Incident registrering og katagorisering

Incidenten resistreres (forhåbentligt i en form for Service management system). Hvis registreringen sker direkte af bruger eller tekniker foretager Service Desk en kvalitets sikring af registreringen.
Ud fra de registrerede oplysninger tildeles Incidenten en katagori (F.eks. HW->Printer->Netværksprinter)
Det undersøges om der er en "Incident model" (en standard procedure) til håndtering af denne Incident (normalt ud fra katagorien). Hvis der er en "Incident model" så

  • undersøges det om der i modellen står beskrevet krav til yderligere informations indsamling og denne information indsamles
  • Proceduren ("Incident modellen") følges til den videre behandlings af denne Incident

Det undersøges om denne Incident (normalt ud fra katagorien) er et Service request. Hvis der er et "Service request" så følges følges Service request processen til den videre behandling (Incidenten lukkes ved at sætte status til "Lukket" og "Lukke kode/katagori" til Service request

Udførende: Service Desk medarbejder

Ansvarlig: Incident manager

Prioritering

Incidenten prioriteres (ud fra Impact og Urgency) (Se værktøj MANGLER)
Hvis Incidenten er en Major Incident nedsættes en tastforce til at udføre resten af aktiviteterne i processen

Udførende: Service Desk medarbejder

Ansvarlig: Incident manager

Major Incident?

Konstatere om Incidenten er en Major Incident?

Ansvarlig: Incident manager

Diagnose

Der ledes efter en løsning/omgåelse af problemet (work around) så normal service kan genetableres.
Undersøgelsen foretages i første omgang af Service desk men eskaleres evt. 2./3. Level ved behov (manglende viden/erfaring/kundskaber eller manglende tid)

Ansvarlig: Incident manager

Løsning

Den under Diagnose fundne løsning/omgåelse af problemet udføres (evt. ved at rejse en RFC og lade Change mangement processen styre gennemførelsen af ændringen)

Ansvarlig: Incident manager

Lukning

Service desk underretter bruger om resultatet af behandlingen af Incidenten og lukker Incidenten hvis brugeren igen har fået "normal" service niveau.

Udførende: Service Desk medarbejder

Ansvarlig: Incident manager

Proceduren: Major Incident

Dette er proceduren til at håndtere store forretningskritiske Incidents.

Trigger:

Major Incident

Indkaldelse af taskforce

Så hurtigt som muligt at indkalde de bedst kvalificerede til at løse Incidenten

Diagnose

Der ledes efter en løsning/omgåelse af problemet (work around) så normal service kan genetableres.
Undersøgelsen foretages struktureret

Løsning

Den under Diagnose fundne løsning/omgåelse af problemet udføres (evt. ved at rejse en RFC og lade Change mangement processen styre gennemførelsen af ændringen)

Lukning

Det oprindelige Incident lukkes

Proceduren: Incident, hirakisk eskalation

Ledelsesmæssig eskalation af Incidents.
Proceduren trigges af Incidents der kræves Ledelsens bevogenhedf, f.eks. fordi:

  • brugerne klager over behandlingen af Incidenten
  • der er riciko for at Incidenten ikke bliver løst inden for den aftalte løsningstid
Trigger:

Behov for ledelsesmæssig bevågenhed f.eks.:

  • Incidenten kan ikke løses inden for aftalt tid
  • Brugeren/kunden klager over løsningstiden af en Incident

Informer relevante personer

Ved behov informeres relevante personer samt ved bruger/kunde klager

Tildel ekstra ressourcer

Ledelsen orienteres

Når en Service desk medarbejder bliver bekendt med behovet for ledelsesmæssig bevogenhed af en Incident orienteres lederen for Service Desken samt evt. lederen for den medarbejder der behandler Incidenten.

Udførende: Service Desk medarbejder

Ledelsen vurdere Incidenten

Ledelsen vurdere om der er behov for yderligere:

  • Tildeling af ressourcer til løsning
  • Information til interessenter

Information

Information internt i Incident processen er primært Incident records.

  • Incident(erne) gemmes, meget gerne i en CMDB (CMS) således at der kan komme relationer til andre CIer. Hver Incident indeholder blandt andet:
    • Unikt navn/nummer
    • Status (f.eks. Aktiv, Venter på bruger information, Venter på ekstern leverandør, Løst, Lukket)
    • Beskrivelse af symptomer
    • Bruger der rapporterede Incidenten (rel)
    • Kontaktmetode til bruger (f.eks tlf. eller mail)
    • Evt. brugere/grupper der er berørt af Incidenten (rel)
    • Medarbejder der har registreret Incidenten (rel)
    • Tidspunkt for registreringen
    • Katagori (typisk i 2-3 niveauer)
    • Prioritet (Impact og Urgency)
    • Infrastruktur komponenter (relation til andre CIer)
    • Ansvarlig gruppe/person for behandlingen (CI)
    • Aktioner udført (hvad, resultat, af hvem samt hvornår)
    • Evt. relateret Problem
    • Evt. relateret Knawn Error
    • Evt. relateret Change
    • Løsnings tidpunkt
    • Lukke kode/katagori
    • Lukke tidspunkt
    Historik bør gemmes på Incidents
    Arbejdet med registreringen af Information i Incidents bør understøttes af et Service Management værktøj (med en CMDB). Værktøjet skal f.eks. Gøre det nemmere at:
    • Slå op i erfaringsdatabasen (Known error DB) for at finde en løsning til Incidentet
    • Få en aktuel status på hvilke åbne Incidents der er, hvem der skal løse dem og om de overholder tidsfristerne i SLAen
    • Med brugeren som indgang finde hvilke Incidents denne bruger har rapporteret
    • Med et stykke udstyr som indgang se hvilke Incidents udstyret har været berørt af

Under behandling af Incidents er der behov for information fra andre processer, dette gælder primært:

  • Erfarings database (f.eks. Known error DB fra Problem management processen)
  • Åbne Problem records
  • Generel information om infrastrukturen (CMDB og anden dokumentation)

Evaluering

Her følger en række overordnede udsagn.
Prøv at tage stilling til om de passer med jeres it organisation. Dette kan f.eks. gøres ved for hvert udsagn at være: "Fuldstændig enig", "Næsten enig", "Lidt enig" og "Uenig".

Ønsker du at få præsenteret alle udsagnene, ikke kun de overordnede, i et skema med mulighed for maturity beregning skal du foretage login

Links