Revisionsstyring kontra versionsstyring: hvad er den reelle forskel?

Sådan fungerer det

1. Vælg ét ord til jeres eget register, og hold op med at genforhandle det

   Beslut »revisionslog« eller »versionshistorik« for jeres organisations register, sæt det i registrets egen titel og kolonneoverskrifter, og gå videre. At lade forskellige teams tale forbi hinanden med forskelligt ordforråd om identiske rækker spilder mere tid, end selve valget er værd.

2. Giv hver revision sin egen række, aldrig et optalt felt

   I eksempeldiagrammet er hver revision sin egen Fil-formede række med sit eget nummer, tildelt i »Tildel postnummer og link dokumentet«, frem for en tæller, I overskriver. Byg jeres log på samme måde: en ændring er en ny registrering, ikke en redigering af den forrige.

3. Registrér, hvad der ændrede sig i posten, ikke bare at noget gjorde

   »Registrér før-og-efter-beskrivelse, forfatter og dato« er den række, det er værd at kopiere ordret: navngiv feltet eller klausulen, dens gamle værdi, dens nye værdi, hvem der lavede ændringen, og hvornår. En dateret række, der ikke siger, hvad der flyttede sig, er ikke en revisionspost, det er et tidsstempel.

4. Verificér posten mod dokumentet, før I lukker den

   »Sammenlign logposten med den implementerede ændring« og dens »Verificeret mod dokumentet?«-port findes, fordi poster og dokumenter glider fra hinanden: en beskrivelse skrevet, før redigeringen var færdig, eller en redigering, der gik længere end anmodningen sagde. Send uoverensstemmelsen tilbage til den side, der er forkert, før I lukker rækken.

5. Lad loggen registrere sig selv, hvor dokumentet allerede lever i QueryChart

   Er det styrede dokument selv et QueryChart-diagram, registrerer dets ændringslog allerede, hvem der ændrede hvilket felt, og hvad det blev ændret fra og til, ved hver redigering, uden opsætning. I behøver ikke håndføre revisionsrækkerne ovenfor som en separat tabel: se /features/version-control.

Ofte stillede spørgsmål

Er en »revision« det samme som en »version«?

I det meste sprogbrug, ja: de to ord beskriver den samme underliggende registrering, og at skifte mellem dem ændrer intet ved mekanikken. Hvor en reel forskel viser sig, er den en forskel i korn: en revision er som regel den enkelte daterede ændring, og en version er som regel den resulterende tilstand af hele dokumentet, når den ændring er anvendt: i diagrammet ovenfor er hver række en revision, og det dokument, der kommer ud i den anden ende, er den gældende version.

Bør jeg kalde min log en »revisionslog« eller en »versionshistorik«?

Hvad end jeres organisation, standard eller software allerede bruger: ISO 9001-dokumentation siger typisk »revision«, mens de fleste SaaS-produkter siger »version« (QueryChart inklusive, på /features/version-control), og konsistens inden i jeres eget register betyder langt mere end hvilket navneord, I vælger. Kør ikke begge udtryk parallelt for samme artefakt.

Betyder denne skelnen noget for et audit?

Ikke på den måde, folk forventer. En auditor tjekker, at hver ændring er dateret, tilskrevet og hentbar, ikke hvilket navneord der navngiver registret. Det, der betyder mere, er ikke at sammenblande »revisionsstyring« med det fulde dokumentstyringslivsforløb: se /da/guides/saadan-laver-du-en-dokumentstyringsproces for forskellen mellem at nummerere en ændring og styre et dokument fra ende til anden.

Hvor betyder denne nuance faktisk noget i praksis?

Mest direkte i en selvstændig ændringslog eller et revisionsregister: et artefakt, hvis hele formål er at liste daterede, individuelle poster, hvilket »revision« beskriver mere præcist end »version« gør. Se /da/guides/saadan-laver-du-en-revisionshistorik-for-dokumenter for at bygge én, og /da/guides/hvad-er-versionsstyring for den bredere definition, denne side antager.