Sådan laver du en revisionshistorik for dokumenter
Sådan bygger du en revisionshistorik for dokumenter: de nødvendige kolonner, hvorfor loggen er en separat, append-only registrering adskilt fra dokumentet, og det verifikationstrin, håndlavede tabeller ofte springer over.
Sådan fungerer det
Adskil loggen fra dokumentet
Sæt revisionshistorikken i sit eget artefakt (en tabel på forsiden eller et selvstændigt register), aldrig som et afsnit begravet i brødteksten. Dokumentet ændrer sig; loggen er den eneste af de to, der må kun vokse.
Fastlæg kolonnerne før den første post
Versionsnummer, dato, forfatter, en beskrivelse i klart sprog af, hvad der ændrede sig og hvorfor, en henvisning til den version, den erstatter, og hvem der verificerede posten. Udelad et af de to sidste, og der er ingen måde at skelne en tjekket registrering fra en forfatters selvrapportering.
Åbn posten før redigeringen, ikke bagefter
Log en verserende post (nummer, dokumentlink, tildelt forfatter) i det øjeblik en ændring godkendes, før nogen åbner filen. En post skrevet bagefter er rekonstrueret fra hukommelsen, hvilket er præcis den fejltilstand, en log findes for at forhindre.
Skriv ned, hvad der ændrede sig, ikke at noget ændrede sig
»Opdaterede afsnit 4« er ikke en beskrivelse; »ændrede godkendelsestærsklen fra 3.500 kr. til 14.000 kr. i afsnit 4« er. Registrér før-og-efter i klare vendinger, forfatterens navn og datoen, så en læser kan rekonstruere ændringen uden at åbne dokumentets egen historik.
Verificér posten mod den faktiske redigering
Lad en anden end forfatteren sammenligne den loggede beskrivelse med, hvad der faktisk ændrede sig i dokumentet, før posten lukkes. Er de uenige, skal I finde ud af, om det er dokumentet eller posten, der er forkert: at rette posten er ikke altid et tilbageskridt for forfatteren.
Stikprøvekontrollér afsluttede poster: reviewe ikke hver eneste
Byg et periodisk audit, der tjekker en stikprøve af afsluttede poster mod deres dokumenter, på en tidsplan, der hører hjemme i auditprogrammet frem for et ad hoc-tjek. Det er dét, der gør loggen til noget, I kan stole på uden selv at genverificere den.
Ofte stillede spørgsmål
Hvad er forskellen på en revisionshistorik og versionsstyring?
En revisionshistorik er artefaktet: tabellen med version, dato, forfatter, beskrivelse og verifikator. Versionsstyring er praksissen, der holder den tabel ærlig: reglen om, at intet redigeres uden en post, at poster aldrig omskrives bagefter, og at en anden end forfatteren tjekker den ene mod den anden. I kan have en revisionshistorik med svag versionsstyring bag: tabellen findes, men ingen verificerer nogensinde en række mod den faktiske redigering.
Hvilke kolonner har en revisionshistorik-tabel brug for?
Versionsnummer, dato, forfatter, en beskrivelse i klart sprog af, hvad der ændrede sig og hvorfor, en henvisning til den version, den erstatter, og (den, de fleste håndbyggede tabeller springer over) hvem der verificerede posten mod den faktiske redigering. En række uden den sidste kolonne er en forfatters selvrapportering, ikke en tjekket registrering.
Bør en revisionshistorik redigeres for at rette en fejl i en gammel post?
Nej. Tilføj en ny række, der retter registreringen, frem for at omskrive den gamle; loggen er kun så troværdig, som dens append-only-historik er intakt. Var det forkerte dokumentet frem for posten, hører rettelsen hjemme i en ny dokumentrevision, ikke en omskrevet logrække.
Er et håndført regneark nok til en revisionshistorik, eller har jeg brug for software?
Et regneark virker, indtil nogen redigerer en række i stedet for at tilføje en, hvilket er svært at forhindre og let at overse. QueryCharts versionshistorik skriver den tilsvarende log automatisk: en ændringslog med feltvise før/efter-værdier og redaktørens navn for hver revision, synlig i en Sammenlign versioner-skærm og gendannelig på et hvilket som helst punkt, på /features/version-control. Diagrammet ovenfor viser den manuelle version af samme disciplin (en anmodning, en arkiveret beskrivelse, et verifikationstrin), uanset hvilket værktøj der kører det.