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

Ulykker sker næsten aldrig uden varsel. Alle har på et tidspunkt prøvet en nærved-ulykke: Du faldt næsten på din cykel og ramte kantstenen – men heldigvis gjorde du det ikke. Du sukker i lettelse, lærer af det og går videre. I en virksomhedsindstilling gælder den samme logik. I dette tilfælde giver hændelsesrapportering din virksomhed mulighed for at lære og måske forhindre fremtidige ulykker.

I denne artikel vil jeg gøre mit bedste for at forberede dig på uforudsete hændelser. Jeg formoder, at dit mål er at reducere deres effekt og forhindre, at de nogensinde vil ske igen.

Endelig vil jeg give dig en trinvis vejledning i, hvordan du opretter en hændelsesrapporteringsproces i Gluu.

Hvad er hændelser, afvigelser eller afvigelser egentligt?

For nemheds skyld vil vi anlægge en tilgang på højt plan til emnet. Der er masser af definitioner inden for feltet, og denne artikel vil tage dem i betragtning og bruge dem til 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 ved en egenskab, der gør et produkts kvalitet uacceptabel, ubestemt eller ikke i overensstemmelse med bestemte krav”

Ovenstående synes at holde et par egenskaber (ja – det er her, vi forenkle en smule):

1. En uplanlagt begivenhed sker,
2. En planlagt begivenhed sker ikke.

Uoverensstemmelsen, i dette tilfælde, er produktorienteret og beskriver effekten af den uønskede hændelse snarere end årsagen. Ser man ud over det faktiske produkt effekten af en uønsket begivenhed er alt fra nær misser, menneskelig skade og ulykker, overholdelse spørgsmål til tabte muligheder.

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

“Skøn viser, at i I-lande kommer op mod 1 af 10 patienter til skadet mens de modtager hospitalsbehandling. Skaderne er forårsaget af en række utilsigtede hændelser, hvor ca. 50% kunne have været forhindret med korrekt forebyggelse.”

Hvem

Alle kan blive enige om, at ulykker skal forebygges. Hvis ingen ønsker ulykke så hvorfor ikke rette hændelse håndtering ske hver gang?

Desværre er der er flere faktorer, der hindre effektiv indberetning af hændelser.

Nedenfor er et dybt ind i tre af de vigtigste årsager til, at indberetning af hændelser er vanskeligere end det burde være.

Hvorfor undlade at hjælpe dine kolleger?

Hvem ønsker at være den idiot, der indrømmer, at der var en uønsket hændelse?

I en beskyldnings-kultur ønsker ingen at indrømme, at de lavede en potentiel 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 opretter 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 ved at sikre anonymitet og fjerne potentielle sanktioner for den der indberetter. Men det er i modstrid med målet om at skabe en åbenhedskultur, hvor alle arbejder hen imod et fælles mål om systematisk forbedring.

Ledelsen skal stå i spidsen for denne kulturelle forandring og omfavne 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 hændelsesanalyser, ønsker flere data, men husk, at medarbejdere i frontlinjen har travlt med bier. Hvis hændelsen ikke rapporteres kort efter at det skete, går medarbejderne blot videre til det næste punkt på deres todoliste.

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

En desillusioneret person

At finde en balance mellem at få nok data til at forstå hændelsen og gøre processen let nok til at sikre, at den er afsluttet, er afgørende for at få de nødvendige data.

Brugervenligheden er afgørende for at få data overhovedet.

Intet svar eller effekt af hændelsesrapporten

Med hensyn til enhver indsats er det vigtigt at se, at dit input spørgsmål. Hvis der er en fornemmelse af, at ledelsen bare vil ignorere de rapporterede hændelser, chancerne er, at fremtidige hændelser ikke vil blive rapporteret.

At sige “tak” for rapporten, anmelde, når det 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ændelsesrapporter hjælpe hele virksomheden.

Igen – uden indberetning af hændelser 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 vejledning i, hvordan du skal rapportere hændelser i Gluu

Den snusfornuftige tilgang

Lad os et øjeblik lægge ISO-standarderne og alle de smarte ord til side. Hvad handler det egentlig om?

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

Heldigvis har de fleste mennesker også evnen til at hjælpe med deres sunde fornuft. Drej på kontakten eller finde nogen, der ved, hvordan man.

Efter “Puuh – jeg er glad for ingen døde” – øjeblikket er vi nødt til at rydde opog sørge for at det ikke sker igen.

Hele denne artikel handler om at lære af andre folks erfaringer. At se på ISO 45001-standarden og ISO 27002-standarden er netop det, da det er en formel, erfaringsbaseret tilgang til sund fornuft.

To hovedtyper af hændelser

For at komme til procesniveau er vi nødt til at dykke ned i to meget forskellige typer af hændelser for at se, hvad vi kan lære af dem.

Disse en 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 standard)
  En hændelse, der ikke forårsager skade, men har potentialet til forårsage personskade, tab af ejendom eller materiale eller ulykker under lignende forhold. For eksempel ikke iført en hjelm på en byggeplads. I sig selv er det ligegyldigt, men på grund af det farlige miljø er beskyttelse nøglen til at forebygge ulykker.
  
• hændelser indenfor IT-cybersikkerhed
  (ISO 27002)
  I modsætning til et faktisk brud på datasikkerheden betyder en cybersikkerhedshændelse ikke nødvendigvis, at oplysninger kompromitteres. Betyder det blot, at oplysninger er truet. For eksempel har en organisation, der med succes afviser et cyberangreb, oplevet en hændelse, men ikke et brud.

Baseret på viden fra ISO 27002 og ISO 45001 standarden, vil vi skabe en hændelsesrapporteringsproces i Gluu.

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

Den første aktivitet bør altid være at stoppe (hvis det er muligt) noget dårligt foregår. Lad mig give et par eksempler.

Hvad skal man overveje for HSE hændelser?

HSE hændelser kræver oftest fysisk indgriben:

• Hænger 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 undervejs!

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 maskerede mennesker raiding serverrummet. Indgriben kan ske på mange måder – hvis det overhovedet er muligt.

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

Sådan opsættes en rapporthændelsesproces i Gluu

Baseret på artiklen “How to do simple process mapping” har jeg oprettet en proces med navnet “Rapportér hændelse”. Målet for processen er enkelt: “Hændelsen er blevet rapporteret med succes”.

Som nævnt før er hændelse rapportering 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 der forhindres kan, bør ansvaret overdrages til en person med viden indenfor området. En linje manager kan slukke for en bulldozer uden at forårsage yderligere skade.

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

Opdeling af aktiviteterne mellem to roller sikrer forhåbentlig, at yderligere eskalering forhindres.

1. “Videnfra 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.”

Del to i ISO 27002 prioriteter er tiltænkt en potentiel retssag, som vi ikke vil se på i denne artikel.

Fælles for begge er behovet for korrekt rapportering med henblik på at forhindre gentagelse: Alle tilgængelige oplysninger skal sikres til efterfølgende analyse – hvis det er muligt under de givne omstændigheder. Dette kan være en anelse i konflikt med eskalering forebyggelse, da forebyggelse kan dække eller ødelægge værdifuld dokumentation. Men generelt virker det som en rimelig afvejning – især hvis der er ild i din kollega.

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

Overordnet er arbejdsinstruktionen meget ligetil: “Sikre alle de oplysninger du kan”. Med tiden lærer organisationen af både årsager og (negative) effekter og vil være i stand til at forbedre arbejdsinstruktionen på baggrund af disse erfaringer.

Proceshændelsesrapportering kræver løbende revisioner for korrekt at reflektere virkeligheden.

Det er generelt ikke en god idé, at den samme rolle har to aktiviteter lige efter hinanden. For nemheds skyld bør de kombineres for at skabe et bedre overblik.

I dette tilfælde er aktiviteterne tematisk meget forskellige, hvorfor det samme gælder deres arbejdsinstruktion. Så to separate aktiviteter giver mening.

Aktiviteten “Sikre oplysninger” bør omfatte følgende opgaver til Linjelederen for at indsamle nok oplysninger til senere analyse:

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

Den sidste aktivitetsopgave: “Udfyld hændelsesrapporten” er en Gluu function lavet i formgeneratoren, der kan indsamle input på predefineret og struktureret vis.

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

ISO 27002 og ISO 45001 standardformularer

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

Går fra rapportering af hændelser til håndtering af hændelser

Når man ser på det fra et helikopter perspektiv – er der endnu mere vi kan gøre. Nu, hvor hændelsesrapporteringen er på plads, er det tid til hændelsesstyring. For at se, hvordan dette gøres, skal du læse denne artikel Sådan håndteres hændelsesstyring.