Sådan implementeres hændelsesrapportering (1/2)

I denne artikel vil jeg gøre mit ypperste for at forberede dig på håndtering af (uforudsete) hændelser. Jeg formoder, at dit mål er, at reducere konsekvenserne og hindre at de nogensinde sker igen.

I den første del af artiklen vil jeg introducerer dig til overvejelserne omkring hændelser og i den anden del selve hændelses rapporteringen. Du vil også lære at indsamle værdifulde erfaringer fra dine kolleger, så I kollektivt undgår at begå de samme fejl igen og igen.

Undervejs vil vi søge inspiration fra hændels-rapportering inden for de ISO standarder, der er på området: Arbejdsmiljøledelse (ISO 45001) og informationssikkerhed (ISO 27002).

Endelig vil jeg give dig en trinvis vejledning i, hvordan du laver en hændelsesrapporterings-proces i Gluu.

Hvad er hændelser, uoverensstemmelser og afvigelser egentligt?

For nemheds skyld tager vi et helikopterperspektiv på emnet. Der er masser af definitioner og i denne artikel vil overveje dem alle med henblik på at skabe en brugbar proces.

Processen litteratur og ISO standarder har følgende definitioner vi kan bruge:

• Manglende overensstemmelse
  “Manglende opfyldelse af et krav”
• Afvigelse
  “Afvigelse fra en godkendt instruktion eller etableret standard”
• Hændelse
  “Operationel hændelse, som ikke er en del af standard driften”
• Uoverensstemmelse
  “mangel, der gør et produkts kvalitet uacceptabel, ubestemt eller ikke i overensstemmelse med bestemte krav”

Ovenstående synes at have en fællesmængde (ja – det er her, vi forenkle en smule):

1. Der sker en ikke-planlagt hændelse,
2. En planlagt hændelse sker ikke.

“Uoverensstemmelse”, i dette tilfælde, er mere produktorienteret og beskriver effekten af den uønskede hændelse snarere end årsagen. Ser man ud over selve produktet kunne effekten af en uønsket hændelse være menneskelig skade, compliance problemer eller blot missede chancer.

Hændelser i sundhedssektoren (normalt kaldet “utilsigtede hændelser”) er både dyre, skadelige og kan til en vis grad forebygges.

“Skøn viser, at i høj indkomst lande, bliver så mange som 1 ud af 10 patienter yderligere skadet, mens de modtager hospitalsbehandling. Skaden kan være forårsaget af en række forskellige utilsigtede hændelser, men fælles for dem er, at cirka 50% af dem kan forebygges.”

WHO

Alle kan blive enige om, at ulykker skal forebygges. Men hvis ingen ønsker ulykke, hvorfor kommer der så ikke hændelserapporteringer?

Desværre er der er flere faktorer, der forhindre effektiv hændelserapportering. Nedenfor kigger vi på de vigtigste årsager til at hændelserapportering er sværere end det burde være.

Hvorfor undlade at hjælpe dine kolleger?

Hvem ønsker at være den idiot, der indrømmer, at der skete en træls hændelse?

“Du gjorde hvad for noget ?!?”

I en beskyldnings-kultur ønsker ingen at indrømme, at de lavede en fejl.
Hvis hændelsen ikke direkte påvirkede nogen – hvorfor så rapportere det og udstille sig selv i et negativt lys?

Husk: Når du begynder med et hændelsesrapporterings-system, skal virksomheden samtidigt fremme en kultur omkring åbenhed og tillid. Hændelser skal ses som potentiale for organisatorisk læring mere end individers fejl.

IT kan hjælpe med sikre anonymitet og dermed fjerne potentielle sanktioner mod den der indberetter. Men det er i modstrid med målet om at skabe en åbenhedskultur, hvor alle arbejder hen imod systematiske forbedringer.

Ledelsen skal stå i spidsen for denne kulturelle forandring og acceptere hændelser som potentiale til innovation og forbedring. For mere om dette emne, kan du læse Harvard Business Reviews “The failure-tolerant leader”.

Fejl er – trods alt – bedre end gentagne fejl.

Det er for svært at rapportere en hændelse

Hvis processen med at rapportere en hændelse er for besværlig, er der en god chance for, at den ikke bliver rapporteret overhovedet. Alle, der foretager analyser af hændelses, ønsker flere data, men husk, at alle medarbejdere i frontlinjen har travlt. Hvis hændelsen ikke rapporteres kort efter at den skete, går medarbejderne blot videre til det næste punkt på dagsordenen.

“Bureaukrati er kunsten at gøre det mulige umuligt”

En desillusioneret person

At finde en fin balance mellem at få nok data til at forstå hændelsen og gøre processen let nok til at sikre, at den er gennemført, er afgørende for succes.

Brugervenligheden af rapporteringssystemet er derfor afgørende.

Intet svar eller effekt af indrapportering

For enhver indsats er det vigtigt, at se et resultat. Hvis der er blot en lille mavefornemmelse om, at ledelsen vil ignorere de rapporterede hændelser, forsvinder chancerne for fremtidige indrapporteringer.

At sige “tak” for rapporten, og huske at give besked når den bliver håndteret (eller endda gennemført) er en enkel, effektiv og billig måde at vise påskønnelse. Taknemmelighed behøver ikke at være monetær, især når hændelsesrapportering hjælper hele virksomheden.

Igen – uden hændelsesrapportering fra medarbejderne er der ingen data til at forhindre fremtidige ulykker. Så hold disse kulturelle faktorer i baghovedet.

Lad os nu se på en mulig løsning!

En trinvis vejledning i hændelsesrapportering i Gluu

Den snusfornuftige tilgang

Lad os et øjeblik lægge ISO-standarderne og alle de smarte ord på hylden. Hvad handler det hele egentlig om?

De fleste mennesker har en god mavefornemmelse. Når der hænger en ledning ud fra væggen og siger mærkelige lyde, er det noget de fleste bemærker.

Heldigvis har de fleste mennesker også evnen til at afhjælpe problemet med deres sunde fornuft: Sluk for kontakten eller find nogen der ved hvordan man gør det.

Efter “Puuh – jeg er glad for ingen døde” – øjeblikket skal der ryddes op og sikres at det ikke sker igen.

Hele denne artikel omhandler det at lære af andre folks erfaring. ISO-standarderne er blot en formalisering af sund fornuft og erfaring.

To hovedtyper af hændelser

For at komme ned på et faktisk procesniveau vil vi prøve at at dykke ned i to meget forskellige typer af hændelser for at se på forskelle og fællestræk og hvad vi kan lære af dem.

Følgende er to meget forskellige hændelse typer, der kan forekomme i enhver organisation. Hver er omfattet af sin egen ISO standard:

• Hændelser inden for arbejdsmiljø (HSE)
  (ISO 45001)
  En hændelse, der ikke forårsager skade, men har potentialet til forårsage personskade, tab af ejendom/materiel eller person-ulykker under lignende forhold. For eksempel manglende hjelme på en byggeplads. I sig selv er det ikke en ulykke, men på grund af det farlige miljø er beskyttelse nøglen til at forebygge ulykker.
• Hændelser indenfor informationssikkerhed
  (ISO 27002)
  I modsætning til et faktisk brud på datasikkerheden betyder en IT-hændelse ikke nødvendigvis at data kompromitteres. Betyder det blot, at data er truet. For eksempel har en organisation, der succesfuldt hindre et IT-angreb, oplevet en hændelse, men ikke et brud.

Baseret på ideer fra ISO-standarderne vil vi skabe en hændelsesrapporterings proces i Gluu.

Første skridt: Undgå, at hændelsen bliver en ulykke

Første aktivitet bør altid være, at stoppe (hvis det er muligt) hændelsen i at udvikle sig til en ulykke. Lad mig give et par eksempler.

Hvad skal man overveje for HSE hændelser?

Undgå, at hændelsen bliver en ulykke

HSE hændelser kræver oftest fysisk indgriben:

• Hænger el-stikket halvvejs ude?
  – sæt det ind igen.
• Er en maskine ude af kontrol?
  – sluk for den.
• Sæbe på skibsdækket?
  – vask det bort.

Husk at du skal passe på dig selv!

Barrikadér om muligt området og forsøg at forhindre dine kollegers adgang, for dermed at afværge eventuel personskade.

Hvad skal man overveje ifm. it-hændelser?
Cyber-kriminalitet er sværere at opdage. Der er sjældent at der rent faktisk er tyveknægte i serverrummet. Hindring kan ske på mange måder – hvis det overhovedet er muligt.

Du kan måske forhindre at phishing e-mails bliver videresendt (eller sende en advarsels e-mail til alle).
Hvis du har mistanke om, at nogen har root passwordet, kan det være et oplagt tidspunkt at skifte det.

Sådan gør du i Gluu

Baseret på artiklen “How to do simple process mapping” har jeg lavet en proces: “Rapportér hændelse”. Det forventede resultat af processen er: “Hændelsesrapportering udført”.

Som nævnt, er hændelserapportering alles ansvar. For at give alle adgangen (og dermed pligten) til at rapportere hændelser, vil rollen “Almindelig medarbejder” sikre, at alle medarbejdere har adgang.

Selv med de bedste intentioner og en god portion sund fornuft ved ingen hvordan man håndterer alt. Specielle situationer kræver oftest specialiseret viden.

Når rolle “almindelige medarbejder” har forhindret hvad umiddelbart kan forhindres, bør ansvaret overdrages til en person med viden indenfor området. En linjeleder kan slukke for en maskine uden at forårsage yderligere skade.

Som med alt andet i her livet er ingen ansvarlig udover deres evner.

Opdeling af aktiviteterne mellem to roller sikrer at yderligere eskalering forhindres.

Andet trin: Sikre dokumentation

Nu, hvor en yderligere eskalering af ulykken er blevet forhindret, skal vi sørge for, at situationen ikke opstår igen. Vi skal derfor kunne forstå hvad der skete og hvorfor.
Dette starter med indsamling af alle oplysninger omkring den aktuelle hændelse.

Ifølge ISO 45001 er målet at: “evaluere … behovet for korrigerende foranstaltninger for at fjerne den eller de grundlæggende årsager til hændelsen eller uoverensstemmelsen, således at den ikke gentager sig eller forekommer andre steder…”.
ISO 27002 har to prioriteter:

1. “Viden fra analyse og løsning af informationssikkerhedshændelser bør anvendes til at reducere sandsynligheden for eller virkningen af fremtidige hændelser.”
2. “Identifikation, indsamling, erhvervelse og bevarelse af oplysninger, som kan tjene som bevis.”

Sidstnævnte punkt i ISO 27002 er tiltænkt en potentiel retssag, som vi ikke vil se på i denne artikel.

Fælles for begge er behovet for korrekt hændelsesrapportering med henblik på at forhindre en gentagelse: Alle tilgængelige oplysninger skal sikres til efterfølgende analyseres – hvis det er muligt under de givne omstændigheder. Sikring af dokumentation kan komme i konflikt med at forhindre eskalering af hændelsen, da man undervejs kan komme til at dække eller ødelægge værdifuld dokumentation. Dog virker det som en rimelig afvejning at prioritere at hindre en ulykke over dokumentation – især hvis der er ild i din kollega.

Det er umuligt at lave en udtømmende liste over hvilke informationer der skal sikres. Her bør du overveje alt fra skærmbilleder, lyd, fotos til logfiler – alt tæller.

Sådan gør du i Gluu

Overordnet er arbejdsinstruktionen ligetil: “Sikre alle de oplysninger du kan”. Med tiden lærer organisationen af både årsager og (negative) virkninger og vil løbende kunne forbedre arbejdsinstruktionen.

Hændelsesrapportering kræver, som alle andre processer, løbende revisioner for at kunne vejlede bedst i den virkelige verden.

Det er generelt en dårlig idé, at den samme rolle har to aktiviteter lige efter hinanden. Oftest bør de kombineres for at skabe et bedre overblik.

I dette tilfælde er aktiviteterne og arbejdsinstruktionerne tematisk meget forskellige, hvorfor to separate aktiviteter giver mening:

Aktiviteten “Sikre oplysninger” skal indeholde følgende opgaver til linjelederen for at indsamle nok oplysninger:

• Billeder / skærmbilleder af hændelsen (visuel)
• Beskrivelse af, hvad der er sket (tekst)

“Secure information” opgaven i Gluu

Den sidste opgave: “Udfyld hændelsesrapporten” er lavet i Gluus formularbygger, der kan indsamle brugerinput på struktureret vis.

ISO 27002 (afsnit 16.1.2) har visse krav til kategoriseringen.
Vi kan tilføje nogle velovervejede kategorier til HSE formularen vel vidende, at flere årsager kan tilføjes senere.

ISO 27002 formularen i Gluu

ISO 45001 formularen i Gluu

For at afslutte processen vil vi tilføje et endpoint (grøn cirkel) for at illustrere, at den observerede hændelse nu er blevet rapporteret – hvilket var vores ønskede procesresultat til at begynde med.

Fra hændelsesrapportering til hændelsesstyring

I et bredere perspektiv er der mere vi kan gøre end blot at rapportere. Med korrekt hændelsesrapportering kan vi se på håndtering og styring. Hvordan dette gøres, kan du se i næste del af denne artikel: Sådan implementerer I hændelsesstyring