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.
En revisionshistorik for dokumenter er artefaktet (en tabel med version, dato, forfatter, beskrivelse og verifikator), som en versionsstyringspraksis producerer og holder nøjagtig.
Kort fortalt
- Revisionshistorikken er artefaktet (en tabel); versionsstyring er praksissen, der holder den nøjagtig.
- Minimumskolonner: version, dato, forfatter, beskrivelse, henvisning til forrige version, verificeret af.
- Append-only: ret en forkert post med en ny række, aldrig ved at redigere den gamle.
- En post, ingen tjekkede mod den faktiske redigering, er en påstand, ikke en registrering.
- QueryChart genererer dette automatisk via sin ændringslog, se /features/version-control.
Tabellen er en registrering, ikke disciplinen
En revisionshistorik er den tabel, de fleste læsere straks ser for sig: et versionsnummer, en dato, navnet på den, der lavede ændringen, en kort beskrivelse af, hvad der ændrede sig, og ofte navnet på den, der reviewede den. Det er et artefakt: rækker i en tabel, som regel siddende på dokumentets egen forside. Versionsstyring er den anden ting, der producerer de rækker: praksissen med aldrig at redigere et styret dokument uden at skrive én, aldrig at omskrive en post bagefter, og at lade en anden end redaktøren tjekke posten mod redigeringen. Et dokument kan bære en fuld-udseende revisionshistorik og stadig ikke have reel versionsstyring bag sig, hvis ingen nogensinde har tjekket en eneste række mod, hvad der faktisk ændrede sig.
Behandl revisionshistorikken som et separat objekt fra det dokument, den beskriver, ikke et afsnit indeni det. Dokumentet ændrer sig; loggen gør kun ét: vokser. Hver post har brug for et versionsnummer, en dato, en forfatter, en beskrivelse i klart sprog af, hvad der ændrede sig og hvorfor, en henvisning til den version, den erstatter, og (den kolonne, de fleste håndbyggede tabeller udelader) hvem der verificerede posten mod den faktiske redigering. Spring den sidste kolonne over, og loggen er et sæt uverificerede påstande: en forfatters gengivelse af sin egen ændring, arkiveret af den samme person, der lavede den.
Diagrammet herunder gennemgår en generisk proces for revisionslogposter (seksten rækker på tværs af fem baner), hvor det, der bevæger sig gennem processen, er selve logposten, ikke dokumentet. En anmodning åbner en verserende post, en forfatter gennemfører ændringen og arkiverer en før-og-efter-beskrivelse, en reviewer sammenligner den beskrivelse med den faktiske redigering, før noget lukkes, og en auditor stikprøvekontrollerer afsluttede poster senere. Det sammenligningstrin er dét, et håndlavet regneark næsten aldrig har, fordi der ikke er nogen, hvis job det eksplicit er at udføre det. QueryChart erstatter den håndbyggede tabel helt: hver redigering af et diagram fanges i en ændringslog med feltvise før/efter-værdier og redaktørens navn, synlig i en Sammenlign versioner-skærm, på /features/version-control. Ingen skal skrive posten, for den er registreringen af, hvad der faktisk blev redigeret, ikke en selvrapportering.
Seksten rækker, fem baner, én logpost
Se en enkelt revisionslogpost bevæge sig fra anmodning til en verificeret, auditstikprøvet lukning (de kolonner, en håndbygget tabel som regel springer over) lagt ud som en proces.
En anmodning, endnu ikke en post
Startrækken er »Ændring anmodet mod et styret dokument« (en hændelse, ikke en opgave), efterfulgt af »Indsend ændringsanmodningen med årsag og måldokument«, som navngiver det præcise dokument og årsagen, før noget bliver logget. »Ændring godkendt til logføring?« afgør, om en verserende post overhovedet åbner.
Posten åbner, før redigeringen gør
Først efter godkendelse dukker »Opret en verserende logpost« op, som en Fil-række frem for en note i nogens indbakke. »Tildel postnummer og link dokumentet« og »Tildel ændringen til en forfatter« sker begge i banen Logejer, før banen Forfatter starter: posten findes som en registrering, før et eneste ord i dokumentet ændrer sig.
Verifikation, ikke bare en beskrivelse
»Implementér ændringen i dokumentet« flytter arbejdet ind i banen Forfatter, og »Registrér før-og-efter-beskrivelse, forfatter og dato« arkiveres som sin egen række frem for foldet ind i redigeringen. »Sammenlign logposten med den implementerede ændring« og »Verificeret mod dokumentet?« kræver derefter, at Revieweren tjekker postens ord mod den faktiske redigering, før nogen stoler på nogen af dem.
En uoverensstemmelse, så afslutning og audit
»Uoverensstemmelse i dokumentet eller logposten?« sender et fejlet tjek tilbage til »Implementér ændringen i dokumentet« eller »Registrér før-og-efter-beskrivelse, forfatter og dato«, alt efter hvad der var forkert. En verificeret post når frem til »Luk logposten«, »Giv anmoderen besked om, at ændringen er gennemført« og »Stikprøvekontrollér afsluttede poster ved periodisk audit«, før Slut, »Revisionslogpost afsluttet og klar til audit«, med »Anmodning afvist, ikke logført« som den anden udgang, tilbage øverst.
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.
Faldgruber du skal undgå
Loggen som en hukommelsesprøve
At skrive posten dage efter redigeringen gør en registrering til en rekonstruktion. Åbn den verserende post, når ændringen godkendes, og arkivér før-og-efter-beskrivelsen samme dag, redigeringen lander, ikke ud fra, hvad nogen husker uger senere.
At redigere historikken på stedet
At rette række tre i et regneark for at fikse en forkert beskrivelse ødelægger selve dét, en revisionshistorik findes for: bevis for, hvad der blev registreret hvornår. Tilføj en ny række i stedet; /da/guides/saadan-sporer-du-aendringer-i-en-sop og /da/guides/saadan-styrer-du-sop-revisioner dækker denne append-only-disciplin specifikt for SOP'er.
En log, ingen tjekker mod dokumentet
En tabel med en Version- og Beskrivelse-kolonne, men intet verifikationstrin, er et sæt påstande, ikke en registrering. Giv sammenligningen sin egen række med sin egen ejer, på samme måde som »Sammenlign logposten med den implementerede ændring« gør i diagrammet ovenfor, ellers er loggen kun så pålidelig som forfatterens hukommelse.
At forveksle loggen med den proces, der producerer den
En revisionshistorik registrerer, hvad der ændrede sig; den afgør ikke, hvem der må godkende en ændring, eller hvor erstattede kopier lever: det er dokumentstyring, gennemgået fuldt ud på /da/templates/dokumentstyring-proces. Byg begge dele, men hold dem som separate artefakter.
Byg jeres egen revisionslog
Åbn diagrammet for revisionslogposter som jeres egen skabelon, læg jeres egne dokumenttyper i banerne, og lad QueryCharts ændringslog føre den verificerede historik i stedet for et regneark.
Relaterede guides
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.
