Ændringshistorik • tekniske beslutninger • dokumentation

Historik over tekniske beslutninger
med kontekst for ændringer i maskinprojektet

I maskinsikkerhedsdokumentation er slutresultatet alene ikke nok. Du skal kunne genskabe beslutningen: hvem ændrede opgavestatus, hvornår beslutningen om risikoreduktion blev registreret, hvorfor restrisikoen blev vurderet som acceptabel, og hvilken version af erklæringen der var gældende på det tidspunkt. Safety Software viser et audit trail, der er koblet direkte til risikovurderingen, reduktionstiltagene og erklæringerne, i stedet for at lade ændringskonteksten drukne i regneark, Word-filer og mapper fulde af PDF'er.

Se audit trail i projektet Hvad registrerer systemet
Audit trail og beslutningshistorik

Til teams, der ikke bare skal vise resultatet, men også vejen frem til det

Et audit trail har først værdi, når det er koblet direkte til det ingeniørfaglige arbejde.

Safety Software registrerer historikken dér, hvor beslutningerne faktisk bliver taget: ved opgavestatusser, risikoreduktion, iterationer af restrisiko, erklæringer, bilag og adgangsbeslutninger.

1 akse
kronologisk beslutningshistorik i rapporten for risikovurderingsdokumentationen
▲ UP
Kontekst ændringer
hvem, hvornår, hvad der blev ændret, og hvorfor — koblet til de tekniske beslutninger i maskinprojektet
▲ UP
KMS
kryptering af følsomme felter i historikken for risikoreduktion, når KMS er aktiveret
▲ UP 
status_historik:
  område: opgave ISO 12100
  før: til gennemgang
  efter: godkendt
  person: Anna K.
  tid: 2026-05-13 10:42
  note: ingen yderligere farer
Historik over opgavestatusser

En ændring i opgavestatus forsvinder ikke bare i en overskrevet celle.

I risikovurderingen arbejder teamet med opgaver, operationer, farekilder og scenarier. Når en bruger ændrer status, kan systemet gemme oplysninger om den forrige og den nye tilstand, personen, tidspunktet og den tekniske note.

Så viser rapporten ikke kun den aktuelle projektvisning. Den viser også, hvordan beslutningen udviklede sig, og om den pågældende del af vurderingen bevidst blev lukket, suppleret eller sendt videre til yderligere risikoreduktion.

  • opgave- eller operationsstatus med ændringshistorik
  • person, dato og beskrivelse af ændringen
  • overførsel af konteksten til risikovurderingsdokumentationen
Risikoreduktion

Beslutningen om en beskyttelsesforanstaltning skal have sit eget spor.

Ved risikoreduktion er det ikke nok at vide, at der blev anvendt et værn, en forrigling, en procedure eller en advarsel. Det afgørende er også, hvem der vurderede foranstaltningens effekt, om der opstod sekundære farer, og hvad resultatet blev efter reduktionen.

Modulet til historik for risikoreduktion registrerer hændelser ved den konkrete fare og vurdering. Dermed kan du genskabe selve beslutningsforløbet: reduktionstrin, resultat, inputdata, bruger og tidspunkt for ændringen.

  • beslutninger for trinene i risikoreduktionen
  • oplysninger om sekundære farer og restrisiko
  • kobling mellem hændelsen og den konkrete fare
risikoreduktion:
  fare: indføringszone
  trin: teknisk foranstaltning
  hændelse: beslutning_gemt
  resultat: effektiv reduktion
  kontekst: måling af sikkerhedsafstand
restrisiko:
  iteration: 2
  metode: HRN
  resultat: 12
  kategori: lav
  acceptabel: ja
  note: ekstra værn + rengøringsinstruktion
Iterationer af restrisiko

Restrisiko er en beslutning, ikke det sidste afsnit i rapporten.

Når reduktionstiltagene er gennemført, kan teamet vende tilbage til vurderingen og registrere en ny iteration af restrisiko: metode, resultat, kategori, acceptabilitet og note.

Det er vigtigt ved moderniseringer, konstruktionsændringer og gennemgange efter audit. Hvis beslutningen bliver udfordret senere, hjælper systemet med at vise ikke kun den endelige vurdering, men også tidligere forsøg, korrektioner og begrundelser.

  • løbende iterationer af resultatet efter reduktion
  • resultat, kategori og acceptabilitet for restrisiko
  • teknisk note gemt sammen med beslutningen
Erklæringer og adgang til ressourcer

Det handler ikke kun om risikovurdering. Vigtige dokumenthændelser skal også kunne spores.

I erklæringsmodulet registreres hændelser knyttet til oprettelse af udkast, opdatering, udstedelse af erklæringer og erstatning af tidligere versioner. Separat kan systemet også registrere beslutninger om adgang til ressourcer samt hændelser knyttet til bilag.

Det erstatter ikke producentens organisatoriske procedure, men det giver et stærkt fundament: historikken ligger ikke spredt i mails, filnavne og kommentarer i chatten.

  • historik over udkast, udgivelser og erstatninger af erklæringer
  • hændelser for bilag og filer
  • registrering af beslutninger om adgang til ressourcer
erklæring:
  hændelse: declaration.issued
  dokument: EU-overensstemmelseserklæring
  version: 3
  erstatter: version 2
  status: udstedt

Hvad skal du kunne vise, når nogen spørger til historikken bag beslutningerne?

Et audit trail er først nyttigt, når det forbinder hændelsen med den tekniske kontekst. En ændringsdato alene er ikke nok.

Det skal være på plads
Det får du i Safety Software
Person og tid
Hvem udførte ændringen, hvornår og i hvilket område af projektet.
Bruger-ID, brugernavn og tidspunkt for hændelsen registreres ved beslutningshændelser.
Beslutningens genstand
Ikke bare en generel beskrivelse, men den konkrete opgave, fare, foranstaltning, erklæring eller ressource.
Hændelser kobles til vurderingen, faren, reduktionstrinnet, erklæringen, bilaget eller ressourcen.
Teknisk kontekst
Begrundelse, resultat, kategori, acceptabilitet, note eller inputdata for metoden.
Hændelsesdata og data fra iterationer af restrisiko gemmes sammen med historikposten.
Rapportering
Mulighed for at vise historikken i dokumentationen — ikke kun i administrationspanelet.
Afsnittet med audit trail i risikovurderingsdokumentationen samler statusser, reduktion og iterationer på én tidsakse.
Datasikkerhed
Adgangskontrol og beskyttelse af følsomme felter i historikken.
Data fra sporet for risikoreduktion kan gemmes i krypterede felter, når KMS-support er aktiveret.

Forskellen viser sig efter nogle måneder — ikke den dag dokumentet bliver underskrevet.

Kvalitativ sammenligning af det, der typisk er tilbage efter tekniske beslutninger i et regneark, i en filmappe og i et struktureret audit trail.

Forskellen viser sig efter nogle måneder — ikke den dag dokumentet bliver underskrevet. — dane tabelaryczne
niveau for sporbarhed (0-6) Regneark Filmappe Safety Software
Mulighed for at genskabe beslutningen 1 2 6
Kobling til teknisk evidens 1 2 5

Beslutningshistorikken skal løbe parallelt med processen — ikke skrives på til sidst.

Det mest troværdige audit trail bliver skabt under arbejdet: når opgavestatus ændres, en reduktionsforanstaltning registreres, restrisikoen vurderes igen, en erklæring udstedes, eller der træffes beslutning om adgang til en ressource.

Beslutningshistorikken skal løbe parallelt med processen — ikke skrives på til sidst. Os czasu z 5 wydarzeniami compliance. 1 — ændring af status for opgave eller operation 1 opgavestatus 2 — beslutning om risikoreduktion og sekundære farer 2 reduktion 3 — iteration af restrisiko med resultat og note 3 restrisiko 4 — udstedelse eller erstatning af erklæring 4 erklæring 5 — dokumentationsrapport med tidsakse for beslutninger 5 rapport

Det her er ikke bare en hændelsesliste til administratoren. Det er projektets tekniske hukommelse.

Et veldrevet audit trail gør det muligt at gå tilbage til beslutninger efter modernisering, reklamation, audit eller udskiftning af den projektansvarlige.

Hvis man senere ikke kan genskabe, hvem der vurderede restrisikoen som acceptabel — og på hvilket grundlag — mister dokumentationen en stor del af sin bevisværdi.
Safety Software
beslutningshistorik i risikovurdering
Et audit trail fritager ikke producenten for ansvar. Det hjælper med at vise, at beslutningen ikke var tilfældig, men kom ud af en struktureret proces.
Safety Software
teknisk dokumentation og overensstemmelse

De mest stillede spørgsmål om audit trail

Betyder et audit trail, at hver beslutning automatisk er korrekt?
Nej. Systemet vurderer ikke selv, om en teknisk beslutning er korrekt, og det overtager ikke producentens ansvar. Dets opgave er at skabe orden i historikken: hvem traf beslutningen, hvornår, hvad den gjaldt, og i hvilken kontekst den blev taget.
Dækker ændringshistorikken kun risikovurderingen?
Den er stærkest i risikovurdering, risikoreduktion og restrisiko, men applikationen registrerer også hændelser for erklæringer, bilag og beslutninger om adgang til ressourcer.
Kommer audit trail med i risikovurderingsdokumentationen?
Ja. Dokumentationsmodulet kan bygge et afsnit med audit trail ud fra historikken over opgavestatusser, hændelser i risikoreduktionen og iterationer af restrisiko og vise hændelserne som en klar tidsakse med teknisk kontekst.
Kan historikken slettes?
Systemet viser et struktureret spor af arbejdet i projektet og hjælper med at genskabe konteksten bag tekniske beslutninger. Omfanget af den synlige historik, rettighederne og den måde data præsenteres på, kan afhænge af systemkonfigurationen og brugerrollen. Vi kommunikerer ikke et uforanderligt register. Vi kommunikerer bedre sporbarhed af beslutninger end i regneark, PDF-filer og dokumenter sendt pr. mail.

Stop med at basere projekthistorikken på filnavne og teamets hukommelse.

Håndter risikovurdering, risikoreduktion, restrisiko, erklæringer og dokumentation i én samlet proces, hvor beslutninger efterlader et tydeligt spor.

Aktivér audit trail i projektet

Den bedste test er enkel: én maskine, én teknisk ændring og et forsøg på at genskabe, hvem der ændrede hvad, hvornår og hvorfor.

Praktiske artikler om risikovurdering, maskindirektiver og compliance — som støtte til denne produktside.