Hvad er versionsstyring af dokumenter og procedurer?
De fleste søgeresultater på "hvad er versionsstyring" går ud fra Git og kildekode. Denne side definerer det for dokumenter, SOP'er og processer i stedet, og skiller det fra revisionsstyring, ændringsstyring og dokumentstyring.
Versionsstyring af dokumenter viser, hvilken udgave der gælder, hvad der er ændret, og hvem der har godkendt den. Her handler det om procedurer og proceskort; kildekodeværktøjer som Git løser en anden del af versionsstyring.
Kort fortalt
- Versionsstyring = én gældende version, en fuld historik over hver tidligere, og en registrering af hvem der ændrede hvad: samme idé for dokumenter som for kode.
- Revisionsstyring er samme praksis under et andet navn; ændringsstyring og dokumentstyring er bredere processer, der bruger den som én del.
- QueryChart holder allerede denne historik for hvert diagram: en ændringslog, en Sammenlign versioner-visning og gendannelse med ét klik: se /features/version-control.
- Et udkasts mindre version (0.1, 0.2 …) rykker ved hver reviewcyklus; et helt hovedversionsnummer tildeles kun én gang, ved formel godkendelse.
- Versionerer I et specifikt objekt? Se /da/guides/versionsstyring-af-sop, /da/guides/versionsstyring-af-dokumenter eller /da/guides/versionsstyring-af-flowcharts.
Fra begreb til praksis
Én gældende version, alt andet er historik
Søg på "hvad er versionsstyring", og næsten hvert resultat går ud fra, at du styrer kildekode: commits, brancher, Git. Denne side handler om den ældre, mere ligetil brug af udtrykket: at styre versioner af dokumenter, standardprocedurer (SOP'er) og forretningsprocesser, ikke kode. Den underliggende idé er den samme i begge tilfælde: én gældende, autoritativ version; en fuldstændig historik over hver version, der gik forud; og en registrering af præcis hvem der ændrede hvad, og hvornår. Det eneste, der er forskelligt, er det objekt, der versioneres: papirarbejde i stedet for en kodebase.
Konkret betyder det, at hver redigering af et dokument giver en ny, nummereret version i stedet for at overskrive den sidste, så den forrige version forbliver hentbar i stedet for at forsvinde. I QueryChart findes det allerede for hvert diagram, du bygger: en ændringslog registrerer, hvem der ændrede hvilket felt, og hvad det blev ændret fra og til, en Sammenlign versioner-visning sætter to vilkårlige revisioner side om side, og at gendanne en gammel én er én enkelt handling frem for at skrive den om: se /features/version-control for hele billedet. Intet af det skal slås til; det kører på hvert diagram fra det øjeblik, det oprettes.
Revisionsstyring og versionsstyring er samme idé under to navne: begreberne bruges i flæng gennem det meste af feltet, og intet afgørende afhænger af, hvilket ord jeres organisation foretrækker. Ændringsstyring og dokumentstyring er noget andet: det er bredere styringsprocesser, der bruger versionering som én mekanisme, ikke synonymer for den. En proces for ændringsstyring (se /da/guides/saadan-laver-du-en-aendringsstyringsproces) afgør, om en ændring overhovedet skal ske (konsekvens, godkendelse, rollback), og versionsstyring er blot den måde, det godkendte resultat bliver nummereret og registreret på bagefter. En dokumentstyringsproces (/da/templates/dokumentstyring-proces, og hvordan-guiden på /da/guides/saadan-laver-du-en-dokumentstyringsproces) styrer et dokuments hele livsforløb (udkast, gennemgang, godkendelse, publicering og tilbagetrækning af den erstattede kopi fra hvert sted, den befandt sig) med versionsstyring som ét led i den, ikke det hele. De tre par får hver deres fulde sammenligning på /da/guides/versionsstyring-kontra-aendringsstyring, /da/guides/versionsstyring-kontra-dokumenthaandtering og /da/guides/revisionsstyring-kontra-versionsstyring; denne side skal blot vise, at de ikke er fire ord for det samme.
Ved du allerede, hvilket af disse objekter du versionerer, er det generelle svar ovenfor mindre nyttigt end det specifikke: se /da/guides/versionsstyring-af-sop for standardprocedurer, /da/guides/versionsstyring-af-dokumenter for styrede dokumenter generelt, eller /da/guides/versionsstyring-af-flowcharts hvis det, du versionerer, er selve procesdiagrammet. Alt herunder (definitionen i miniature, gennemgangen, hvordan-guiden) er det generelle tilfælde, de tre bygger videre på.
Se et versionsnummer blive tildelt, trin for trin
Ét dokument bevæger sig fra et decimalt udkast gennem review, godkendelse og publicering: se præcis hvor dets versionsnummer ændrer sig, og hvor det ikke gør.
Et udkast starter på 0.1, ikke 1.0
Diagrammet åbner med »Nyt dokument udarbejdet« og går direkte videre til »Tildel indledende udkastversion 0.1«: et decimaltal, for intet før den formelle godkendelse får et helt tal i dette system.
Reviewsløjfen rykker den mindre version
»Send udkast til intern review« og »Reviewer vurderer udkastet« fører til »Kræves der ændringer?«. Et Ja sender det gennem »Optæl den mindre version« (0.1 bliver til 0.2) og videre til »Ret udkastet i forhold til kommentarerne«, som løkker tilbage på en gren, der hedder »Nyt review«, lige så mange gange som udkastet har brug for.
Et helt tal er optjent, ikke antaget
»Indsend det endelige udkast til godkendelse« og »Godkender gennemgår det endelige udkast« fører til »Godkendt til udstedelse?«. En afvisning løkker tilbage til »Optæl den mindre version«; en godkendelse når frem til »Tildel hovedversion 1.0« og en Fil-formet række, »Opdater versionshistorikregistret«, der logger det.
Publicering trækker den gamle version tilbage på samme række
»Publicer den godkendte version« følges straks af »Markér den forrige version som erstattet«, så den tidligere revision trækkes tilbage, i samme øjeblik den nye går i drift. En læser, der ønsker en ændring, går ind igen ved »Genåbn dokumentet ved den næste version«; alle andre når frem til »Aktuel version forbliver gældende«.
Sådan fungerer det
Vælg én placering som den autoritative version
Enhver anden kopi (en PDF sendt ud over mail, en udskrift, en side gemt på et fælles drev) er en kopi af dén ene placering, ikke et andet original. Kan to steder begge hævde at være gældende, har I endnu ikke versionsstyring, uanset hvordan jeres nummerering ser ud.
Skil udkastnummerering fra udgivet nummerering
Brug decimaler til alt, der stadig er i review, og reservér hele tal til det, der faktisk er godkendt, på samme måde som 0.1 til 0.3 fører op til 1.0 i eksempeldiagrammet ovenfor. En reviewer, der citerer »kommentarerne på 0.3«, er derefter entydig om, hvilket udkast der menes.
Log hvem der ændrede hvad: ikke kun at noget blev ændret
Et datostempel alene fortæller en læser intet om, hvad der reelt flyttede sig. Registrér aktøren, feltet og værdien før og efter for hver redigering, hvilket er, hvad QueryCharts ændringslog gør automatisk for hvert diagram, uden nogen opsætning.
Gør to versioner sammenlignelige, ikke kun visbare
At kunne åbne version 3 og åbne version 5 er ikke det samme som at kunne se, hvad der ændrede sig mellem dem. QueryCharts Sammenlign versioner-visning sætter to vilkårlige revisioner side om side, så forskellen er dét, du ser på, ikke en gætteleg.
Behandl gendannelse af en gammel version som rutine, ikke en nødsituation
Hvis det at fortryde en dårlig redigering betyder, at nogen med databaseadgang skal træde til, findes jeres versionsstyring kun på papiret. At gendanne en tidligere version bør være en handling, enhver autoriseret redaktør selv kan udføre, i det øjeblik problemet opdages.
Faldgruber du skal undgå
Et filnavn, der spiller rollen som versionsnummer
»SOP_v2_FINAL_reviewed(1).docx« er ikke et versionssystem, det er et filnavn, der tilfældigvis indeholder cifre: intet sikrer, at tallet stiger, eller at to personer ikke laver deres egen »FINAL« samtidig. En version skal ligge i et system, der tildeler den, ikke i hvad en person tilfældigvis skriver, før filen gemmes.
En historik, der kun registrerer den aktuelle tilstand
At overskrive et dokument på stedet og kalde den gamle kopi »sikkerhedskopieret et sted« er ikke en versionshistorik, det er et håb. En reel historik holder hver tidligere version hentbar og sammenlignelig, ikke blot genfindelig for den, der husker, hvor den blev lagt.
At behandle »har et versionsnummer« som »er under kontrol«
Et nummer på et dokument fortæller dig, at det blev versioneret én gang; det fortæller dig ikke, at den gamle kopi blev trukket tilbage, at nogen godkendte ændringen, eller at nummeret overhovedet betyder det, du tror. Versionsstyring er nummereringen og loggen: dokumentstyring og ændringsstyring er det, der styrer processen omkring den.
At omdøbe ordforrådet i stedet for at rette praksissen
At standardisere jeres organisation på »revisionsstyring« frem for »versionsstyring«, eller omvendt, ændrer intet ved, om ændringer faktisk bliver sporet. De er samme praksis under to navne; den rettelse, der betyder noget, er loggen, ikke etiketten.
Se dit diagrams ændringslog i QueryChart
Hvert diagram i QueryChart holder allerede denne historik: opret ét, og åbn dets ændringslog for at se det selv.
Relaterede guides
Ofte stillede spørgsmål
Er versionsstyring det samme som revisionsstyring?
Ja, i praksis. De to udtryk beskriver samme underliggende idé (én gældende version plus en hentbar historik over hver tidligere), og forskellige organisationer, værktøjer og standarder foretrækker simpelthen det ene ord frem for det andet. Mekanikken ændrer sig ikke, uanset hvilket udtryk I bruger; se /da/guides/revisionsstyring-kontra-versionsstyring for hele sammenligningen.
Hvad er forskellen på versionsstyring og ændringsstyring?
Ændringsstyring afgør, om en ændring overhovedet skal ske: dens konsekvens, hvem der godkender den, hvordan den rulles tilbage, hvis den går galt. Versionsstyring er det, der registrerer resultatet, når den beslutning er truffet: det nye nummer, tidsstemplet, aktøren. En proces for ændringsstyring kan findes uden versionsstyring, dårligt, og versionsstyring uden ændringsstyring betyder blot, at ingen besluttede, om ændringen var en god idé, før den blev nummereret. Se /da/guides/versionsstyring-kontra-aendringsstyring og /da/guides/saadan-laver-du-en-aendringsstyringsproces for CAB- og rollback-mekanikken.
Fungerer versionsstyring på samme måde for dokumenter som for kode?
Kerneidéen er identisk (én autoritativ gældende version, en fuld historik over hvad der gik forud, en registrering af hvem der ændrede hvad), men mekanikken er forskellig. Versionsstyring af kode, som Git, er bygget op omkring at forgrene og flette sideløbende arbejdsspor; versionsstyring af dokumenter og processer er som regel lineær, ét udkast, der bevæger sig gennem review til én godkendt version, hvilket ligger tættere på det, denne side og eksempeldiagrammet beskriver.
Er QueryCharts audit trail slået til som standard?
Versionshistorikken, der er beskrevet på denne side (ændringslog, Sammenlign versioner, gendannelse) er gratis og kører automatisk på hvert diagram uden opsætning. QueryCharts compliance-audit trail, en hash-kædet registrering mappet til ISO 27001-, SOC 2- og HIPAA-kontroller, er en separat, betalt funktion, en organisation slår til bevidst. Den er ikke slået til som standard, og det er ikke noget, enhver konto allerede kører.
