Du har en hændelsesrapport. Hvad nu? Denne anden artikel om hændelser, viser vejen til effektiv hændelsesstyring uden at bruge unødigt meget tid på det.
I denne artikel vil jeg gøre mit bedste for at hjælpe dig med hændelsesstyring, at oprette en hændelseshåndteringsproces samt at analysere og implementere den viden, du får fra din hændelsesrapporteringsproces. Det er en opfølgning på min seneste artikel “Sådan oprettes hændelsesrapportering“. Jeg anbefaler på det kraftigste, at du læser artiklen før denne – medmindre du allerede har hændelserapportering på plads.
Igen dykker vi ned i de to standarder, der dækker emnet: ISO 27002, ISO 45001. (Disse standarder er gode at læse for en mere dybdegående forståelse af hændelsesstyring)
I den sidste del af artiklen vil jeg give dig en trin-for-trin guide til, hvordan du omsætter tanke til handling og opretter en hændelsesstyringsproces ved hjælp af Gluus forretningsprocesstyringsplatform.
Så – en hændelsesrapport er landet i nogens indbakke. Hvad sker der så? Det er her, hændelsesstyring kommer ind i billedet.
Først skal vi forstå hændelsen. Dette starter med at finde den grundlæggende årsag. Hvad skete der – og vigtigst af alt – hvorfor skete hændelsen? Bevæbnet med disse oplysninger kan vi begynde arbejdet med at forhindre nye lignende hændelser.
ISO 45001 har en fin beskrivelse af årsagsanalyse:
“Analyse af årsag refererer til den praksis omkring at udforske alle de mulige faktorer i forbindelse med en hændelse eller manglende overensstemmelse ved at spørge, hvad der skete, hvordan det skete, og hvorfor det skete, at give input til, hvad der kan gøres for at forhindre det i at ske igen.”
Og følgende: “Denne analyse kan identificere flere medvirkende fejl, herunder faktorer relateret til kommunikation, kompetence, træthed, udstyr eller procedurer.”
Som du måske husker fra artiklen om rapportering af hændelser, har vi oprettet en formular i Gluu for at indsamle så mange oplysninger som muligt. Hvis du senere indser, at du ikke har nok oplysninger til at forhindre gentagelser, kan du gå tilbage og opdatere formularen, så du sikre dine behov fremadrettet.
Når den sande årsag er fundet kan man foretage korrigerende foranstaltninger. Dette skal ifølge ISO 45001: “.. være af proportional i forhold til virkningerne eller de potentielle virkninger af de hændelser eller afvigelser, der er opstået.”
At have en hændelseshåndteringsproces er ikke målet, men det giver en klar måde at arbejde på for alle og kræves af standarderne. Dette er den hændelserapportering proces, som vi har fra vores sidste artikel. Det er den første del af vores samlede hændelsesstyringsflow:
For at gå fra rapportering til analyse og ledelse tilføjer jeg to nye hændelseshåndteringsprocesser til dette: ‘Analyser HSE-hændelse’ og ‘Analyser IT-hændelse’. Grundlaget er imidlertid det samme. Dermed ser processen sådan ud:
Da begge analyseområder har forskellige roller til at fuldføre opgaven, giver det mening at oprette dem som underprocesser til denne proces; ellers dette proceskort ende med at være for stort til at overskue. Bemærk, at jeg holder dem adskilt, da forskellige roller vil arbejde med dem og anvende forskellige analysemetoder.
Når den egentlige årsag er fundet, skal udføres korrigerende handlinger. Dette skal ifølge ISO 450001: “.. være af passende i forhold til virkningerne eller de potentielle virkninger af de hændelser eller afvigelser, der er opstået.”
Korrigerende handlinger er handlinger, der forhindre, at de præcise uønskede hændelser sker igen ved enten at fjerne (eller forbedre) den egentlige årsag til problemet. Uden at gøre unødigt meget.
I Gluu kan vi behandle det som en separat underproces for både HSE og IT, da aktiviteter, den organisatorisk eskalering, ændringer m.m. kræver forskellige roller og (potentielt) arbejdsinstruktioner.
ISO-standarderne foreslår i fællesskab:
Denne handling kan antage mange forskellige former. Nogle er mere effektive end andre. Lad os se på de overordnede principper for gennemførelsen af de ændringer, der er nødvendige for at imødekomme risikoen.
HSE-området har princippet om “Hierachy of controls” til at prioritere initiativerne.
Kernen i hændelsesstyring er et mål om at forhindre gentagelser. Men du har brug for en afbalanceret løsning. I den ene ende kan du helt fjerne faren, hvilket vil være meget effektiv, da ingen vil støde på situationen igen. På den anden side kan du acceptere faren som den er og beskytte dig kolleger fra at komme i for meget kontakt med den. Den logiske konklusion for effektivt at forebygge ulykker er derfor, at fjerne alle farer. Men er det altid muligt? Næppe.
Lad os sige, at du arbejder med off-shore olieboring: Arbejdsområdet har i sin natur en masse risici der ikke kan elimineres, uden at forhindre udførelsen af det faktiske arbejde.
Fra et IT-perspektiv kan du lukke for adgangen til e-mail for at forhindre phishing e-mail problemer. Dette kan være meget effektivt, men det ville også sænke effektiviteten for dine kolleger. I virkeligheden kan du installere software til at scanne alle indgående e-mails og stopper så mange ondsindede e-mails som muligt.
Hændelsesstyring handler også om at vælge en afbalanceret tilgang.
For både HSE og IT virker det meget rimeligt, at løsningen ikke må være værre end problemet. Så hvordan finder du den balance, hvor nedsættelse af risikoen ikke kan retfærdiggøres ud fra et forretningsmæssigt perspektiv?
Her kan du anvende “ALARP” princippet (As Low As Reasonably Practicable). Selv om begrebet stammer fra arbejdsmiljø, er begrebet væsentligt for alle former for risikostyring:
Inden for IT skal du acceptere, at dine kolleger skal bruge intranettet, og at de skal logge på VPN’en udefra. Og at deres adgangskode nogle gange er navnet på deres hund 🙂
Dette bør ikke forhindre dem i at bruge netværket.
En simpel afhjælpningsstrategi er at stille krav til længden og kompleksiteten af deres adgangskode. Og hvor ofte de skal ændre det. Dette kræver ikke en masse ressourcer og reducerer risikoen betydeligt. Så navnet på deres hund plus nogle specielle tegn 🙂
Så hvor passer disse kontroller ind i vores hændelseshåndteringsproces? I Gluu definerer vi to underprocesser for hvert arbejdsområde, da arbejdsinstruktioner og roller er forskellige.
Den mest hensigtsmæssige person til at gennemføre ændringer er den tilsynsførende eller linjelederen, da de har det daglige praktiske kendskab til området.
Som nævnt i “Sådan implementeres hændelsesrapportering” er det vigtigt at holde strømmen af hændelsesrapporter stabil. Aktiviteten “Implementer korrigerende handlinger” bør også indeholde feedback (et pænt “Tak”) til den person, der rapporterede det.
Det er nemt at føje den sidste aktivitet til rollen “Linjeleder” i Gluu.
Jeg håber, du lærte noget om hændelseshåndtering, rapportering og oprettelse af en hændelseshåndteringsproces. Hvis du mener det alvorligt, så vil jeg gerne tilbyde dig et gratis og personligt feedbackmøde, hvor jeg kan hjælpe dig videre på din vej. Du kan booke et møde direkte i min kalender her.
IndholdsfortegnelseMålsætningTestBetingelserResultater Målsætning Test, om stilarterne også mangler på nye sider Test Udgiv disse sider, og…
I dette webinar vil vi diskutere og give dig en introduktion til de vigtigste produkthøjdepunkter…
Undersøgelser viser, at de fleste ERP-implementeringer slår fejl. Et konsulentfirma har analyseret mere end 1.000…
Deltag i vores webinar, og find ud af, hvordan du tydeligt differentierer din D365-implementeringsforretning -…
I denne nytårsspecial får du et overblik over forretningsfordelene ved de nøglefunktioner, som vi har…
Gluu leverer Business Process Management til mennesker. Det betyder rigtige forretningsbrugere, der bruger processer til…