Problem Management – IT-avdelingens Criminal Minds!

Vil du lykkes med Problem Management, nytter det ikke å sitte på hver sin tue og skylde på hverandre. Dere må jobbe smartere, dere må jobbe mer sammen! Har du noen gang hørt om et etterforskningsteam som består av én person?

ITIL har etter hvert blitt et svært utbredt rammeverk som beskriver hvordan arbeidet i IT-avdelinga kan organiseres. Noen av de mest grunnleggende prosessene i ITIL er Incident Management og Problem Management.

  • Incident Management handler om å gjøre en tjeneste, som er utilgjengelig, tilgjengelig for brukeren igjen så raskt som mulig
  • Problem Management handler om å analysere hvorfor det kunne skje og forhindre at det skjer igjen.

Med andre ord, kan man si at Incident handler om å rette feil, mens Problem handler om å lære av feil og unngå at feilen skjer igjen.

Analogi til politiarbeid
Jeg synes det er et ganske tydelig skille mellom Incident og Problem, men av og til føler jeg meg litt alene, for jeg opplever ofte at de eneste forskjellene på behandlingen av disse to svært ulike sakstypene er at de behandles i ulike moduler i saksbehandlingsverktøyet, samt at problemsakene har en tendens til å bli liggende urørt i lang tid. Jeg ser med andre ord ikke noe tydelig skille. Om det i ITIL-rammeverket ikke er meningen at det skal være et tydelig skille, så tror jeg ikke de hadde valgt å beskrive det som to separate prosesser!

Jeg sitter da igjen med to spørsmål jeg ønsker å dele mine tanker om:
1. Hvorfor sliter mange i IT-bransjen med å forstå forskjellen på Incident og Problem Management?
2. Hvorfor tror mange i IT-bransjen at Problem Management er en jobb man gjør alene, og ikke i team?

La oss trekke en analogi til politiarbeid. Nå er det ikke slik at jeg har så veldig peiling på hvordan politiet arbeider, så da baserer jeg meg på hvordan det blir skildret på TV. Nærmere bestemt i serien Criminal Minds.

criminalminds
Skjermdump: Criminal Minds på CBS

Incident vs problem
Jeg ser på Criminal Minds-teamet som et slags Problem team. De skal ikke løse de individuelle politisakene, men grave seg ned i detaljene for å se sammenhengene mellom grusomhetene, og finne ut hvorfor det går en gjerningsmann rundt å begår slike ugjerninger. Og det med ett mål for øyet, unngå at det skjer igjen! Akkurat på samme måte skal Problem Management etterforske hvorfor det renner inn incidents til Service Desk, og sørge for at det tar slutt.

Lære mer om IT Service Management? Delta på et ITIL-kurs hos Steria Academy!

Å jobbe i team
Har du noen gang sett på Criminal Minds, og sett at de jobber alene? Antageligvis ikke, for det gjør de ikke. Criminal Minds består av et sett med eksperter, som har sine spesialfelter. De er styrt av en etterforskningsleder, la oss kalle denne personen for Problem Manager. Teamet møtes ofte for å diskutere, før hver og en i teamet får tydelige oppgaver, av lederen, som de utfører i par eller på egenhånd. Deretter møtes de igjen, for å diskutere sine funn i fellesskap. På den måten graver de i informasjon, kaster ut tanker og forslag om hvem de er på utkikk etter, og ca 40 minutter ut i episoden har de funnet ut hvem gjerningsmannen er. For et samarbeid!

Tenk om vi i IT-bransjen hadde satt av tid til å jobbe slik, i stedet for å sitte på hver vår tue å klø oss i hodet. Eller å ha en sak i et saksbehandlingsverktøy som blir kastet frem og tilbake mellom de ulike fagmiljøene. Det er selvfølgelig ingen som finner feil hos seg selv, for det er jo et nederlag, er det ikke?

Bemann opp analyseteamet i problemsaker som om det var Criminal Minds
Når vi driver med årsaksanalyse i problemsaker, da skal vi ikke sette en stakkars forfjamset tekniker på saken, og la han seile sin egen sjø. Nei, vi skal tenke som i Criminal Minds, vi skal sette sammen en gruppe med eksperter. Ekspertene, de skal ledes av en Problem Manager eller Problem Coordinator, som har kunnskap og erfaring med å fasilitere en rotårsaksanalyse.

Lederen bør alltid etablere et analyseteam, minimum bestående av:

  • Én person fra Service Desk som er godt kjent med sakene som er relatert til problemet. Hun vil kunne bidra med å fortelle mye om hvordan brukerne opplever situasjonen, feilmeldinger, workarounds som fungerer, etc. Samtidig mener jeg også vi må bli flinkere til å involvere alle de flinke folka på Service Desk. De trenger en pust i bakken av og til de også. Deltagelse i en slik prosess gir mye innsikt, og kanskje det kan gi en ekstra motivasjonsboost.
  • Én «ekspert» (driftspersonell, utviklere, systemforvaltere) fra hvert av fagområdene som kan tenkes å være berørt (Etter hvert som områder kan avkreftes å være medvirkende årsak, kan disse ekspertene trekkes ut av det videre arbeidet)

Som Problem Manager skal du heller ikke være redd for å involvere underleverandører og kunde. Jeg har gjort det ved flere anledninger, med stor suksess.

Analyseteamet bør først møtes for å få en felles forståelse av problemet de står ovenfor og starte å analysere hvorfor problemet eksisterer. Etter hvert som årsaksanalysen skrider frem, vil det være behov for å få sjekket ut om årsakene man har kommet frem til er reelle, eller om de kan forkastes. Dette arbeidet er det ofte naturlig at ekspertene gjør hver for seg eller i par, og at resultatene presenteres i neste møte, før man fortsetter arbeidet med årsaksanalysen. Hvor mange ganger man trenger å møtes, kommer an på hvor kompleks problemstillingen er, men ofte vil man komme langt i løpet av to-tre møter, med litt faktasjekk mellom møtene.

På denne måten jobber analyseteamet med problemsaken inntil man har funnet rotårsakene til problemet. Deretter bruker analyseteamet funnene i årsaksanalysen til å identifisere de tiltakene som er mest effektive for å løse problemet.

Når det er gjort, kan analyseteamet i mange tilfeller oppløses, og Problem Manager vil sørge for at det allokeres ressurser til å gjennomføre de identifiserte tiltakene.

Gjør dere ikke som i Criminal Minds når dere etterforsker hvorfor noe har gått galt i din organisasjon? Da vil jeg på det sterkeste anbefale å starte med det. Hvordan gjør man det? Jobb mer sammen! Kanskje det også vil gjøre det tydeligere for de ansatte hva som er forskjellen på Incident og Problem.

Lære mer om IT Service Management? Delta på et ITIL-kurs hos Steria Academy!

 

2 kommentarer om “Problem Management – IT-avdelingens Criminal Minds!

  1. Dette høres kjent ut. Det er slik jeg også tenker, derfor er mottoet til Problem her i CTO «Sammen er vi best», nettopp fordi teamarbeide er den mest effektive metoden for å få løst problemer der årsakene ikke er så tydlige i utgangspunktet. Da må man som du sier analysere litt og prate sammen, få frem mulige «stier å følge», evntuelt også eliminere bort noe. Det gjør vi når det er «småproblemer», med noen deltagere fra aktuelle avdelinger, eller også fra eksterne levrandører….(Steria 😉 Ved større problemer, kjører vi RCA(Root Cause Analysis) med mange avdelinger involvert, for å få frem flest mulige rotårsaker, for dermed også å kunne identifisere flere tiltak som må til for å unngå samme type feil. Det er jo alltid flere enn én rotårsak.

    Når det gjelder forskjellen på Incident og Problem, så er jo den for meg veldig tydelig, men for andre kan jeg skjønne at det ikke er slik. Vi har jo de tilfellene der Incidentprosessen ikke finner feilen, så overføres undersøkelsene til Problemprosessen, som igjen finner ut at det må en endring til for å løse incidentene/problemet. Og hvis man da heller ikke har en workaround som funker, så blir jo incidentene liggende til problemet er løst….via Problem og en endring.
    Det som da er en utfordring er jo hvor smidig endringsprosessen er. Den må fungere på en god måte slik at det ikke tar for lang tid å få frem en løsning. Tar det for lang tid vil det si at tjenesten til berørte brukere blir lenge ute, og det vil også påvirke hvor aktive folk vil være til å melde inn mulig problemer, da de ser at «ingenting skjer»…..og hva er da vitsen!

    Men sammen er vi best Espen 🙂

  2. Er det ikke åpenbart at man ikke har tid til problemene på grunn av alle incidentene? 😉
    Bra blogginnlegg! Det er selvsagt slik det burde være, enhver csi managers våte drøm.

Legg inn en kommentar