Skabelon til dokumentversionsstyring

Sådan fungerer det

1. Fastlæg jeres konvention for decimaltal og hele tal

   Beslut, og skriv ned, at udkastversioner får et decimaltal, og udstedte versioner får et helt tal, eller vælg en anden konvention, hvis jeres afviger. Selve ordningen betyder mindre, end at den er formuleret én gang og bliver brugt overalt, hvor et versionsnummer optræder, herunder i sidehoved, sidefod og registret.

2. Beslut, hvad der tæller som en ny reviewrunde

   Fastsæt reglen bag 'Optæl den mindre version': skal hver rettelsesrunde hæve nummeret, eller kun en gengivelse af udkastet, når ændringerne er indarbejdet? Teams, der optæller ved hver kommentartråd, ender med udkast i tyverne; teams, der kun optæller ved gengivelse, holder tallet meningsfuldt.

3. Fastsæt reglen for, hvad der udløser en hovedversion

   Formel godkendelse er den udløser, dette diagram bruger ved 'Tildel hovedversion 1.0', men nogle organisationer hæver også hovedtallet ved en gennemgribende omskrivning, selv uden en fuld gengodkendelse. Vælg én regel, og brug den konsekvent, for en blandet regel er præcis dét, der får versionsnumre til at holde op med at betyde noget.

4. Definér, hvad der sker med en erstattet version

   Ved 'Markér den forrige version som erstattet' skal I beslutte, hvor den tidligere version befinder sig bagefter: arkiveret i registret med sin erstatningsdato, eller fjernet fra den styrede placering, men opbevaret i en fast periode. Begge dele kan forsvares; et udokumenteret svar kan ikke.

5. Beslut, hvordan en ændring efter publicering nummereres

   Ved 'Genåbn dokumentet ved den næste version' skal I fastlægge, om en ændring af et gældende dokument genstarter den mindre-version-udkastcyklus ved det næste hele tal, eller genoptager decimaltal ud fra det seneste hovedtal. Det er den regel, de fleste teams glemmer at skrive ned, indtil den anden revision allerede er i gang.

Ofte stillede spørgsmål

Hvad er forskellen på en mindre og en større dokumentversion?

En mindre version, skrevet som et decimaltal, for eksempel 0.1 eller 0.2, markerer et udkast, der stadig er i intern review og ikke er godkendt til brug. En hovedversion, skrevet som et helt tal, for eksempel 1.0 eller 2.0, markerer en version, en godkender faktisk har underskrevet, og som er publiceret på den styrede placering. Skellet findes, så en henvisning til 'version 2' altid betyder et udstedt dokument, aldrig et udkast, der tilfældigvis er i sin anden reviewrunde.

Skaber hver runde med reviewkommentarer et nyt versionsnummer?

Det er en regel, jeres organisation fastsætter, ikke noget, selve nummereringsordningen bestemmer af sig selv. Mange teams optæller kun den mindre version, når et udkast gengives til endnu en reviewrunde, ikke ved hver enkelt kommentar, så tallet forbliver en meningsfuld optælling af udkastrunder frem for af rettelser.

Hvad sker der med en version, når den er erstattet, bliver den slettet?

Nej. En erstattet version markeres som sådan i versionshistorikregistret og opbevares normalt i en fastsat opbevaringsperiode, fordi den er dokumentationen for, hvad der var gældende på en given dato. Den trækkes tilbage fra den styrede placering, så ingen ved en fejl arbejder ud fra den, men slettes den helt, fjerner det den dokumentation, en auditor eller en hændelsesundersøgelse senere kan få brug for.

Hvordan adskiller dette sig fra en dokumentstyringsproces eller en revisionslog?

Dokumentstyringsprocessen på /da/templates/dokumentstyring-proces er hele det livsforløb, et dokument gennemgår (anmodning, udkast, review, godkendelse, udstedelse, distribution og periodisk review), og denne skabelon forudsætter, at det livsforløb allerede findes. En revisionslog er et fladt register over enkelte ændringer: hvem der redigerede hvad og hvornår. Dette diagram ligger mellem de to: det er kun mekanikken, der afgør, hvilket nummer (mindre eller større) et dokument har krav på at bære på hvert tidspunkt i det livsforløb.