Skabelon til dokumentrevisionslog
En skabelon til dokumentrevisionslog, også kaldet en ændringslog: følg en ændring af et hvilket som helst styret dokument fra anmodning over en verserende post, implementering og verifikation til en afsluttet, dateret registrering.
Hvad er skabelon til dokumentrevisionslog?
En dokumentrevisionslog, undertiden kaldet en ændringslog, er den selvstændige registrering, der besvarer et andet spørgsmål end dokumentets egen revisionshistorik. Det er ikke 'hvad siger den aktuelle version', men 'hvad skete der, hvem gjorde det, og hvornår, på tværs af hvert dokument et kvalitetssystem styrer'. Den findes adskilt fra den enkelte fil, fordi et dokumentregister, en auditor eller en procesejer har brug for at se ændringsaktivitet på tværs af snesevis af politikker, procedurer, formularer og arbejdsinstruktioner på én gang, i stedet for at åbne hver enkelt og scrolle til dens egen historiktabel. I dette diagram er det selve logposten, ikke dokumentet, der bevæger sig gennem processen: en ændring anmodes, åbnes som en verserende post, implementeres, beskrives, verificeres og lukkes.
Livsforløbet har en port, før noget skrives, og et tjek bagefter. En ændring åbnes kun som en verserende post, når nogen har godkendt den til logføring, og den lukkes kun, når en reviewer har sammenlignet posten med det, der faktisk blev implementeret. Det verifikationstrin findes, fordi en log kun er så troværdig som dens svageste post: en før-og-efter-beskrivelse, ingen har tjekket mod det virkelige dokument, er ikke mere værd end en uverificeret påstand, og en auditor, der senere stikprøvekontrollerer poster, har ingen måde at kende en tjekket fra en utjekket.
Dette er ikke den fulde dokumentstyringsworkflow (udarbejdelse, faglig gennemgang og formel underskrift, før et dokument udstedes), og det er ikke bundet til én bestemt dokumenttype som en standardprocedure. Det er den hovedbog, der ligger ved siden af et hvilket som helst styret dokument, uanset hvad der styrer dokumentets egen udarbejdelse og godkendelse, og som registrerer hver ændring, der foretages af det bagefter: hvem anmodede om den, hvem implementerede den, hvad ændrede sig, og om ændringen blev verificeret. Brug den som selve loggen, ikke som en erstatning for den godkendelse, der oprindeligt bemyndigede ændringen.
Hvad dette flowchart dækker
I denne skabelon
- Fem swimlanes for de personer, der berører en revision (Anmoder, Logejer, Forfatter, Reviewer og Auditor) fordelt på fem faser: Anmodning, Log (verserende), Implementering, Verifikation og Log (afsluttet).
- Indgang og port: en ændring anmodes mod et styret dokument og indsendes med en årsag og det navngivne måldokument, hvorefter beslutningen 'Ændring godkendt til logføring?' enten åbner en verserende post eller afslutter anmodningen ved 'Anmodning afvist, ikke logført'.
- Selve den verserende post: 'Opret en verserende logpost', giv den et postnummer koblet til dokumentet, og tildel ændringen til en forfatter, så en ændring findes i loggen, før den findes i dokumentet.
- Implementering og dokumentation: forfatteren implementerer ændringen i dokumentet, hvorefter 'Registrér før-og-efter-beskrivelse, forfatter og dato' fanger, hvad der ændrede sig, hvem der ændrede det, og hvornår, den post, der lader nogen rekonstruere ændringen uden at åbne dokumentets egen historik.
- Verifikation: reviewer sammenligner posten med den implementerede ændring, og beslutningen 'Verificeret mod dokumentet?' enten lukker posten eller sender videre til 'Uoverensstemmelse i dokumentet eller logposten?', som sender rettelsen tilbage til genimplementering eller tilbage til korrektion af posten, i stedet for altid at antage, at forfatteren tog fejl.
- Afslutning og audit: 'Luk logposten', giv anmoderen besked, og en periodisk audit stikprøvekontrollerer afsluttede poster i Auditor-banen frem for at gennemgå hver eneste.
Hvornår du skal bruge skabelonen
- I har brug for én samlet log, der sporer ændringer på tværs af mange styrede dokumenter (politikker, procedurer, formularer, tegninger, skabeloner) frem for en revisionshistorik indlejret separat i hver enkelt fil.
- Jeres nuværende ændringslog er en løs kolonne tilføjet til et regnearksregister, og I vil have den modelleret som sit eget livsforløb med en port før logføring og et tjek før afslutning.
- En auditor eller procesejer bliver ved med at spørge, hvornår en ændring blev lavet, hvem der lavede den, og om den blev tjekket, og i dag er det ærlige svar, at det ligger spredt i mailtråde.
- I opsætter ændringssporing for en dokumenttype uden sin egen formelle udarbejdelses- og godkendelsesworkflow (en referencetabel, en leverandørliste, en politik) og har brug for en let log frem for en fuld dokumentstyringsproces.
Sådan fungerer det
Omdøb banerne til jeres egne roller
Erstat Anmoder, Logejer, Forfatter, Reviewer og Auditor med de roller, I faktisk har. I et lille team er logejeren og reviewer ofte samme person; behold dem som én bane i stedet for at tegne et review, der aldrig sker. Kan mere end én person forfatte en ændring, så behold Forfatter som en rolle frem for at navngive enkeltpersoner, så diagrammet overlever personaleudskiftning.
Beslut, hvad der tæller som en logbar ændring
Ikke enhver redigering kræver en post: at rette en slåfejl er noget andet end at ændre en kontrolgrænse. Sæt en tærskel ved beslutningen 'Ændring godkendt til logføring?', for eksempel at væsentlige ændringer af omfang, ansvar, tal eller krav logføres, mens formaterings- eller stavefejl ikke gør, og skriv tærsklen ned, for 'væsentlig' er det ord, enhver diskussion om denne beslutning ender ved.
Fastlæg jeres postnummereringsordning
Ved 'Tildel postnummer og link dokumentet' skal I beslutte, om postnumre løber pr. dokument, ændring #4 til denne politik, eller som én løbende sekvens på tværs af hele loggen. Nummerering pr. dokument læses bedre inde i et enkelt dokuments egen historik; én løbende sekvens er lettere at søge i og rapportere på tværs af hele registret.
Skriv standarden for før-og-efter
'Registrér før-og-efter-beskrivelse, forfatter og dato' er kun brugbar, hvis hver post lever op til samme standard. Kræv den tidligere ordlyd eller værdi, den nye ordlyd eller værdi, hvem der lavede ændringen, og datoen, i den rækkefølge, så en auditor, der stikprøvekontrollerer poster, læser samme form for registrering hver gang, uanset hvem der skrev den.
Fastlæg, hvad verifikationen faktisk tjekker
Giv reviewer en konkret test ved 'Sammenlign logposten med den implementerede ændring': åbn dokumentet, find ændringen, og bekræft, at postens før-og-efter-tekst matcher det, der faktisk står. Et tjek, der kun korrekturlæser logposten, er ikke verifikation mod dokumentet.
Definér jeres regel for stikprøveudtagning ved audit
'Stikprøvekontrollér afsluttede poster ved periodisk audit' kræver en angivet hyppighed og stikprøvestørrelse, for eksempel ti poster i kvartalet eller hver post over et defineret risikoniveau, fastsat i jeres auditprogram frem for besluttet ad hoc, hver gang nogen beder om dokumentation.
Ofte stillede spørgsmål
Hvad er en dokumentrevisionslog?
Det er en kronologisk registrering af hver ændring, der er foretaget af et styret dokument, adskilt fra selve dokumentet: hvem anmodede om ændringen, hvem implementerede den, en før-og-efter-beskrivelse af hvad der ændrede sig, datoen, og om den blev verificeret mod det faktiske dokument. Nogle organisationer kalder samme registrering en ændringslog; begge betegnelser beskriver en løbende historik over ændringer frem for dokumentets aktuelle indhold.
Er en dokumentrevisionslog det samme som en ændringslog?
Ja, i den forstand at begge beskriver en løbende registrering af ændringer frem for aktuelt indhold. 'Revisionslog' bruges mest i kvalitets- og regulatoriske sammenhænge knyttet til et bestemt styret dokument; 'ændringslog' bruges bredere, fra en enkelt politik til en fælles referencetabel. Denne skabelon modellerer det generiske livsforløb bag begge betegnelser: anmodning, verserende post, implementering, verifikation, afsluttet post.
Hvordan adskiller dette sig fra et dokuments egen versionshistorik?
Et dokuments versionshistorik ligger normalt inde i selve filen eller dens metadata og viser rækkefølgen af nummererede versioner, der er udstedt. En revisionslog er et separat register, der kan dække mange dokumenter på én gang, og som registrerer selve ændringsaktiviteten (hvem rørte hvad og hvornår) frem for kun det resulterende versionsnummer. Mange organisationer holder begge dele: dokumentet bærer sit versionsnummer og sin ikrafttrædelsesdato, og loggen bærer fortællingen om hver ændring, der frembragte dem.
Hvem bør verificere en logført ændring?
Nogen andre end den, der implementerede den. Formålet med beslutningen 'Verificeret mod dokumentet?' er et uafhængigt tjek af, at før-og-efter-beskrivelsen i posten faktisk matcher det, der ændrede sig i dokumentet, ikke en second opinion fra den samme person, der skrev begge dele. I et meget lille team kan det være logejeren frem for en dedikeret reviewer, men det bør ikke være forfatteren, der tjekker sin egen post.
