Revisionsstyring kontra versionsstyring: hvad er den reelle forskel?
Revisionsstyring og versionsstyring er nær-synonymer, de fleste praktikere bruger i flæng. Denne side navngiver den ene reelle nuance mellem dem uden at opfinde en forskel, der ikke reelt findes i praksis.
Revisionsstyring og versionsstyring er to navne for den samme underliggende praksis (at spore daterede ændringer af et dokument over tid), og den forskel, der findes, er en nuance i vægtning, ikke to konkurrerende systemer.
Kort fortalt
- »Revisionsstyring« og »versionsstyring« beskriver samme praksis; de fleste praktikere bruger de to udtryk i flæng uden tab af betydning.
- Hvor en reel nuance findes: en revision er som regel den enkelte daterede ændringspost, en version er som regel den resulterende tilstand af hele dokumentet.
- Byg ikke to logge for én idé: én versionshistorik, kaldet det ene eller det andet navn, er nok.
- QueryCharts gratis versionshistorik (ændringslog, Sammenlign versioner, gendannelse) fungerer ens, uanset hvilket ord jeres organisation foretrækker: se /features/version-control.
- Denne nuance betyder mest for en selvstændig ændringslog; se /da/guides/saadan-laver-du-en-revisionshistorik-for-dokumenter for at bygge én.
Én registrering, beskrevet på to måder
En kvalitetschef spørger, om deres register skal hedde en »revisionslog« eller en »versionshistorik«, og får tre selvsikre, modstridende svar fra tre kolleger. Alle tre beskriver det samme dokument. Det er ikke et terminologihul, det er værd at rette: det er et tegn på, at begge ord udfører reelt arbejde i samme sætning, og blot navngiver forskellige kornstørrelser af samme aktivitet, ikke to forskellige aktiviteter.
Kornstørrelsen er den ene skelnen, det er værd at holde fast i. »Revision« er det mere naturlige ord for en enkelt dateret, tilskrevet ændring: det, en række i en ændringslog registrerer. »Version« er det mere naturlige ord for den resulterende tilstand af hele dokumentet, efter den ændring er anvendt: det, en læser åbner og læser. En revision er et skridt; en version er, hvor skridtene er nået til. Diagrammet herunder hedder en dokumentrevisionslog af præcis den grund: hver række i det er én revision, og »den gældende version« er simpelthen, hvad dokumentet er, når dets seneste revision er lukket.
Dette er et snævrere spørgsmål end de andre parringer i denne klynge. Ændringsstyring og dokumentstyring er reelt bredere processer, der bruger versionering som én mekanisme inden i sig: se /da/guides/versionsstyring-kontra-aendringsstyring og /da/guides/versionsstyring-kontra-dokumenthaandtering for dem. Revisionsstyring og versionsstyring er ikke den slags par: de fleste praktikere, de fleste standarder og de fleste stykker software bruger de to ord i flæng uden tab af betydning, og QueryCharts egen gratis versionshistorik (en ændringslog, en Sammenlign versioner-visning, gendannelse med ét klik, på /features/version-control) fungerer identisk, uanset hvilket navneord jeres organisation foretrækker.
Er det den generelle definition, I faktisk kom efter, dækker /da/guides/hvad-er-versionsstyring den fuldt ud. Denne side antager den definition og svarer på det snævrere spørgsmål under den: betyder ordvalget noget, og hvor.
En revisionslog, række for række
Se en enkelt ændring bevæge sig gennem fem baner som en dateret, tilskrevet revision, og se, hvor loggen holder op med at tale om posten og begynder at tale om dokumentets gældende version.
En anmodning, før den er en revision
Diagrammet åbner ved »Ændring anmodet mod et styret dokument«, går videre til »Indsend ændringsanmodningen med årsag og måldokument«, og når frem til porten »Ændring godkendt til logføring?«: et »Nej« her ender ved »Anmodning afvist, ikke logført« i stedet for nogensinde at blive til en post.
At åbne posten, ikke at redigere dokumentet
»Opret en verserende logpost« starter registreringen, »Tildel postnummer og link dokumentet« giver denne revision sit eget id adskilt fra dokumentets, og »Tildel ændringen til en forfatter« navngiver, hvem der skal lave den: det er loggen, der får en række, før noget ved selve dokumentet er ændret.
Ændringen, så et tjek mod sin egen beskrivelse
»Implementér ændringen i dokumentet« og »Registrér før-og-efter-beskrivelse, forfatter og dato« er selve revisionen; »Sammenlign logposten med den implementerede ændring«, »Verificeret mod dokumentet?« og »Uoverensstemmelse i dokumentet eller logposten?« fanger en uoverensstemmelse mellem, hvad posten påstår, og hvad dokumentet viser.
At lukke posten producerer den gældende version
»Luk logposten« og »Giv anmoderen besked om, at ændringen er gennemført« afslutter denne revision, »Stikprøvekontrollér afsluttede poster ved periodisk audit« er, hvordan loggen optjener tillid over tid, og »Revisionslogpost afsluttet og klar til audit« er den tilstand, en læser nu ville kalde dokumentets gældende version.
Sådan fungerer det
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.
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.
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.
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.
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.
Faldgruber du skal undgå
To logge for én idé
At føre et separat »revisionsregister« og et separat »versionshistorik-regneark« for samme dokument garanterer, at de to bliver uenige, første gang nogen opdaterer kun det ene. Før én log; kald den, hvad end navn jeres organisation foretrækker.
At behandle ordforrådsdebatten som selve leverancen
En time brugt på at beslutte, om en kolonne skal hedde »Revision« eller »Version«, er en time ikke brugt på at registrere de før-og-efter-værdier, en auditor eller en kollega faktisk har brug for. Vælg et af ordene, og log feltet.
At springe verifikation over, fordi posten »selvfølgelig« matcher
»Verificeret mod dokumentet?« findes, fordi posten og dokumentet nogle gange er uenige: beskrivelsen blev udarbejdet, før redigeringen var færdig, eller redigeringen gik længere end anmodningen. At springe tjekket over gør loggen til en hensigt frem for en registrering.
At slette en forkert post i stedet for at rette den med en ny
En revisionspost, der viser sig at være forkert, bør rettes med en ny, dateret post, der siger det, ikke fjernes. En revisionslog, der mangler sine egne fejl, holder op med at være troværdig, i det øjeblik nogen bemærker, at noget mangler.
Byg jeres egen revisionslog i QueryChart
Hvert diagram i QueryChart holder denne registrering automatisk, uanset hvilket ord I bruger om den: åbn ét, og se ændringsloggen selv.
Relaterede guides
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.
