Problemhåndtering - Problem management

Problemadministrasjon er prosessen som er ansvarlig for å administrere livssyklusen til alle problemer som oppstår eller kan oppstå i en IT-tjeneste. De viktigste målene for problemadministrasjon er å forhindre at problemer og resulterende hendelser skjer, å eliminere gjentatte hendelser og å minimere virkningen av hendelser som ikke kan forhindres. ITIL definerer et problem som årsak til en eller flere hendelser .

omfang

Problemadministrasjon inkluderer aktivitetene som kreves for å diagnostisere årsaken til hendelser som er identifisert gjennom Incident Management- prosessen, og for å bestemme løsningen på disse problemene. Det er også ansvarlig for å sikre at oppløsningen implementeres gjennom passende kontrollprosedyrer, spesielt Change Management og Release Management .

Problemadministrasjon vil også opprettholde informasjon om problemer og passende løsninger og løsninger, slik at organisasjonen er i stand til å redusere antall og innvirkning på hendelser over tid. I denne forbindelse har Problem Management et sterkt grensesnitt med Knowledge Management , og verktøy som den kjente feildatabasen vil bli brukt til begge deler. Selv om Incident Management og Problem Management er separate prosesser, er de nært beslektede og vil vanligvis bruke de samme verktøyene, og kan bruke lignende kategoriserings-, effekt- og prioriteringskodingssystemer. Dette vil sikre effektiv kommunikasjon når du håndterer relaterte hendelser og problemer.

Verdi for virksomheten

Problem Management jobber sammen med Incident Management og Change Management for å sikre at tilgjengeligheten og kvaliteten av IT-tjenestene økes. Når hendelser er løst, blir informasjon om oppløsningen registrert. Over tid brukes denne informasjonen til å øke hastigheten på oppløsningstiden og identifisere permanente løsninger, noe som reduserer antall og oppløsningstider for hendelser. Dette resulterer i mindre nedetid og mindre forstyrrelser i forretningskritiske systemer.

Prosessaktiviteter, metoder og teknikker

Problemadministrasjon består av to hovedprosesser:

Reactive Problem Management, som vanligvis utføres som en del av Service Operation
Proaktiv problemadministrasjon som er startet i Service Operation , men generelt drevet som en del av kontinuerlig service forbedring (CSI) .

Problemoppdagelse

Mistanke om eller oppdagelse av en årsak til en eller flere hendelser av Servicedisken , noe som resulterer i at en Problemregistrering blir reist - Service Desk kan ha løst hendelsen, men har ikke bestemt en endelig årsak og mistenker at den sannsynligvis vil komme igjen.
Analyse av en hendelse av en teknisk støttegruppe som avslører at et underliggende problem eksisterer, eller sannsynligvis vil eksistere.
Automatisert gjenkjenning av en infrastruktur eller applikasjonsfeil ved å bruke hendelses- / varslingsverktøy automatisk for å øke en hendelse som kan avsløre behovet for en problemoppføring .
En melding fra en leverandør eller entreprenør om at det eksisterer et problem som må løses.
Analyse av hendelser som en del av proaktiv problemadministrasjon: se-bulletiner, utgivelser, relevante papirer

Problemlogging

Alle relevante detaljer om problemet må registreres slik at det foreligger en full historisk oversikt. Dette må være dato og klokkeslett for å tillate passende kontroll og opptrapping. Det må gjøres en kryssreferanse til hendelsen (e) som startet "Problemregistreringen":

Tjenestedetaljer
Utstyrsdetaljer
Dato / klokkeslett opprinnelig logget
Prioritets- og kategoriseringsdetaljer
Hendelsesbeskrivelse
Detaljer for alle diagnostiske eller forsøkte gjenopprettingshandlinger.

Problemprioritering

Problemer kan kategoriseres etter alvorlighetsgrad og prioritet på samme måte som hendelser for å lette sporing av dem, med tanke på virkningen av de tilknyttede hendelsene og deres hyppighet av hendelser. Fra et infrastrukturperspektiv kan man spørre:

Kan systemet gjenopprettes, eller må det byttes ut?
Hvor mye vil det koste?
Hvor mange vil bli pålagt å løse problemet?
Hvor lang tid vil det ta å løse problemet?
Hvor mange ekstra ressurser vil være involvert?
Hva er virkningen av å ikke løse problemet?

Problemetterforskning og diagnose

Resultatet av en etterforskning av et problem vil være en grunnårsaksdiagnose eller en RCA-rapport. Oppløsningen skal være summen av riktig nivå av ressurser og ferdigheter som brukes til å finne den. Det finnes en rekke nyttige problemløsningsteknikker som kan brukes til å hjelpe diagnosen og løste problemer.

Configuration Management System (CMS) må brukes til å fastslå innvirkningsnivået og å hjelpe til med å finne feilpunktet.
Den kjente feildatabasen eller KEDB bør åpnes og kontrolleres for å finne ut om problemet har oppstått tidligere, i så fall bør en løsning allerede være på plass.
Den kronologiske analysen, hendelsene som utløste problemet, vil bli sjekket i kronologisk rekkefølge for å få en tidslinje over hendelsene. Hensikten er å se hvilken hendelse som utløser neste hendelse og så videre, eller å utelukke noen mulige hendelser.

The Pain verdianalyse inneholder et bredere syn på virkningen av en hendelse eller et problem på virksomheten. I stedet for å analysere antall hendelser / problemer av en bestemt type i et bestemt tidsintervall, fokuserer teknikken på inngående analyse av hvilket nivå av smerte som er forårsaket av virksomheten av disse hendelsene / problemene. En formel for å beregne nivået av smerte bør ta hensyn til:

antall personer som er berørt
varigheten av nedetid som er forårsaket
kostnadene for virksomheten

Den Kepner og Tregoe metode brukes for å undersøke dypere forankret problemer. De definerte følgende stadier:

definere problemet
beskriver problemet i form av identitet, plassering, tid (varighet) og størrelse (innvirkning)
etablere mulige årsaker
teste den mest sannsynlige årsaken
verifisere den virkelige årsaken

Pareto-analyse eller Pareto-diagram er en teknikk for å skille viktige potensielle årsaker fra trivielle problemer. Følgende trinn bør tas:

Lag en tabell som viser årsakene og frekvensen i prosent
Ordne radene i avtagende rekkefølge etter årsakenes betydning (den viktigste årsaken først)
Legg til en kumulativ prosentkolonne i tabellen
Lag et stolpediagram med årsakene, i rekkefølge etter prosentandelen av total
Tegn en linje på 80% på Y-aksen, og slipp deretter linjen i skjæringspunktet med X-aksen. Fra diagrammet kan du se de viktigste årsakene til nettverksfeil. Disse bør målrettes først.

Nettverksfeil
Årsaker	Andel av totalt	Beregning%
Nettverkskontroller	35	0 + 35% = 35%
Filkorrupsjon	26	35% + 26% = 61%
Server OS	6	61% + 6% = 67%

Kjent feiloppføring

Etter at etterforskningen er fullført og en løsning (eller til og med en permanent løsning) er funnet, må en kjent feiloppføring heves og plasseres i den kjente feildatabasen for å identifisere og løse andre lignende problemer. Hovedformålet er å gjenopprette den berørte tjenesten så snart som mulig med minimal innvirkning på virksomheten.

En god praksis ville være å heve en kjent feiloppføring så tidlig i etterforskningen som mulig; når en løsning er vellykket testet eller en årsak er identifisert.

Stor problemanmeldelse

En god praksis er å ha en gjennomgang av alle større problemer. Men det gir kostnader. Gjennomgangen bør undersøke:

De riktige trinnene tatt
Problemene som oppstod under implementeringen av løsningen
Behovet for å forbedre
Forhindre gjentagelse av ytterligere lignende hendelser
Tredjepart / leverandør / leverandør involvert i implementeringen

Kunnskapen som er lært fra gjennomgangen, bør innlemmes i en tjenestegjennomgang med forretningskunden for å sikre at kunden er klar over tiltakene og planene for å forhindre fremtidige lignende hendelser. Dette bidrar til å forbedre kundetilfredsheten og forsikre virksomheten om at Service Operations håndterer store hendelser på en ansvarlig måte og aktivt arbeider for å forhindre fremtidig gjentakelse.

Se også

Referanser

The New Rational Manager - Beskriver KT-problemløsning og beslutningstaking (PSDM)
Offord, Paul (2011). RPR: En problemdiagnostiseringsmetode for IT-profesjonelle . Essex, England: Advance Seven Limited. ISBN 978-1-4478-4443-3 .

Languages

In other projects