Skabelon til dokumentversionsstyring
En skabelon til dokumentversionsstyring, der viser, hvordan et udkast bevæger sig gennem mindre versioner (0.1, 0.2...) og review, først får et helt tal ved formel godkendelse, og hvordan senere revisioner erstatter den version, de afløser.
Hvad er skabelon til dokumentversionsstyring?
Et versionsnummer er den forkortede kode, der fortæller alle, hvilken kopi af et dokument de sidder med, og om den kan stoles på. Konventionen i denne skabelon er den, de fleste kvalitets- og dokumentstyringssystemer bruger: et decimaltal, 0.1, 0.2, 0.3 og så videre, markerer et udkast, der stadig er i intern review, mens et helt tal, 1.0, 2.0, 3.0, markerer en version, der faktisk er godkendt og udstedt. Reglen er let at formulere og let at bryde i praksis, for intet forhindrer nogen i af gammel vane at kalde et udkast det næste hele tal, hvilket er præcis den forveksling, en nummereringsordning skal forhindre.
Dette diagram er ikke selve dokumentstyringens livsforløb. Anmodning, udkast, formel godkendelse, publicering og periodisk review (hele det forløb, et dokument gennemgår fra ende til anden) er dokumentstyringsprocessen på /da/templates/dokumentstyring-proces, og denne skabelon forudsætter, at det forløb allerede findes omkring den. Det, dette diagram isolerer, er én mekanik inde i det livsforløb: hvordan selve versionsnummeret bevæger sig, og det er bevidst smallere end en revisionslog. At registrere, hvem der ændrede hvilken linje og hvornår, hører til i et fladt ændringsregister; dette diagram beskæftiger sig kun med, hvilket nummer et dokument har krav på at bære på hvert tidspunkt i sit liv.
Nummereringen stopper ikke ved første publicering. Et publiceret dokument, der har brug for endnu en ændring, går tilbage gennem den samme review- og godkendelsescyklus ved den næste version i stedet for at starte som et nyt dokument, og den version, det erstatter, markeres som erstattet i stedet for at blive slettet, så alle, der senere åbner en gammel gemt eller printet kopi, med det samme kan se, at den ikke længere er gældende.
Hvad dette flowchart dækker
I denne skabelon
- Fem swimlanes for de personer, der berører et versionsnummer (Forfatter, Reviewer, Versionsansvarlig, Godkender og Læser) fordelt på fem faser: udkast, intern review, revision, godkendelse samt publiceret og gældende.
- Udkastnummerering: et nyt dokument tildeles udkastversion 0.1, før det nogensinde bliver rundsendt, så den første kopie, nogen ser, allerede bærer et sporbart nummer.
- Review- og optællingssløjfen: beslutningen 'Kræves der ændringer?' sender et udkast gennem 'Optæl den mindre version' og 'Ret udkastet i forhold til kommentarerne', før det går tilbage til nyt review, så 0.1 bliver til 0.2, 0.2 bliver til 0.3, og selve nummeret registrerer, hvor mange runder et udkast har været igennem.
- Hovedversionsporten: 'Godkendt til udstedelse?' er den eneste beslutning i diagrammet, der fører til, at der tildeles et helt tal. Et afvist udkast føres tilbage ind i den mindre-version-cyklus i stedet for alligevel at blive udstedt.
- Publicering og erstatning: versionshistorikregistret opdateres, den godkendte version publiceres på den styrede placering, og den version, den erstatter, markeres som erstattet, alt sammen før en læser overhovedet åbner den nye kopi.
- Sløjfen efter publicering: beslutningen 'Ønskes der ændring efter publicering?' sender et gældende dokument tilbage ind i den samme review- og godkendelsescyklus ved den næste version, i stedet for at behandle et gældende dokument som uforanderligt.
Hvornår du skal bruge skabelonen
- I designer eller dokumenterer en versionsnummereringsordning og har brug for at vise (ikke bare påstå) forskellen mellem en udkastrevision og en udstedt version.
- Reviewere bliver ved med at henvise til et ikke-udstedt udkast, som var det den godkendte version: for eksempel ved at behandle tredje reviewrunde, som var det en formel udgivelse, fordi begge på et tidspunkt er blevet kaldt 'version 3'.
- I skal beslutte, hvor grænsen for hovedversion ligger (ved formel godkendelse, ved en gennemgribende omskrivning af indholdet eller efter en fast udgivelseskalender), og vil have et konkret eksempel at argumentere ud fra, før I fastlægger reglen.
- I skal forklare en auditor eller en ny dokumentansvarlig, hvorfor en erstattet version stadig kan findes i registret i stedet for at være slettet helt.
- I konfigurerer regler for versionsnummerering i et dokumenthåndteringssystem eller et skabelonbibliotek og vil have mekanikken kortlagt, før I bygger den.
Sådan fungerer det
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.
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.
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.
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.
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.
Hvor denne proces passer ind
I de fleste virksomheder følger denne proces efter Flowchart for dokumentstyring og sender videre til Beslutningstræ for dokumentgodkendelse.
Den er ét trin i Dokumentstyring.
Trin 1: Flowchart for dokumentstyring
Flowchart for dokumentstyring med baner for forfatter, faglig reviewer, godkender, dokumentansvarlig og slutbrugere: udkast, godkendelse, udstedelse og periodisk review.
Trin 2: Skabelon til dokumentversionsstyring Du er her
En skabelon til dokumentversionsstyring, der viser, hvordan et udkast bevæger sig gennem mindre versioner (0.1, 0.2...) og review, først får et helt tal ved formel godkendelse, og hvordan senere revisioner erstatter den version, de afløser.
Trin 3: Beslutningstræ for dokumentgodkendelse
Beslutningstræ for godkendelse af dokumenter: redaktionel eller indholdsmæssig ændring, obligatoriske reviewere efter dokumenttype, ekstra godkender og læst-og-forstået ved frigivelse.
Trin 5: Flowchart for gennemgang og godkendelse af politikker
