Sådan sporer du ændringer i en SOP

Kort fortalt

• En revisionshistorikpost har brug for fem felter: den berørte SOP/trin, hvad der ændrede sig og hvorfor, ikrafttrædelsesdatoen, forfatteren og den version, den erstatter.
• Sikkerhedskritiske trin følger en hastereviewvej; alt andet følger den almindelige reviewcyklus.
• Tjek loggen for en verserende post mod samme SOP, før I udarbejder en ny: to åbne poster giver to konkurrerende versionsnumre.
• At afslutte en post låser dens dato, godkender og versionsnumre, så registreringen ikke lydløst kan omskrives senere.
• For en diagrambaseret SOP registrerer QueryCharts ændringslog automatisk hver feltvise redigering. Se /features/version-control.

Registreringen er en post, ikke en rettelsesmarkering

»Track changes« er Word- og Google Docs-sprog: en kommentarboble og en gennemstregning, der lever inde i selve filen. En SOP, der låner udtrykket, men ikke mekanismen, ender med sin ændringshistorik spredt over mailtråde og track changes-kopier, ingen har flettet sammen, og en procesejer, der ikke med sikkerhed kan sige, hvad der ændrede sig i den seneste revision, hvornår, eller hvorfor. At spore en ændring i en SOP betyder noget snævrere og mere holdbart: en dateret post i en revisionshistoriklog, der registrerer, hvad der ændrede sig, hvem der ændrede det, hvornår, hvorfor, og hvilken version den erstatter.

Hver post har brug for de samme felter, uanset hvem der skriver den, eller hvad der ændrede sig: den berørte SOP og trin, en beskrivelse i klart sprog af ændringen og årsagen til den, ikrafttrædelsesdatoen, forfatteren, og det præcise versionsnummer, posten erstatter (det felt, de fleste logge overser). En ændring af et sikkerhedskritisk trin får en hastereviewvej frem for at vente bag den almindelige kø, og før udarbejdelsen begynder, bliver selve loggen tjekket: har den allerede en verserende post mod netop denne SOP? To åbne poster mod samme procedure giver to kandidatversionsnumre, hvilket er et problem, loggen skal løse, før nogen kan stole på den.

En diagrambaseret SOP bygget i QueryChart har ikke brug for en håndført log til de felter, en revisionshistorik findes for at fange. Hver redigering af diagrammet er allerede registreret automatisk, felt for felt, i dets Versionshistorik-panel: åbn det, og en Sammenlign versioner-visning viser præcis, hvad der ændrede sig mellem to vilkårlige gemte versioner, og hvem der ændrede det, og ét klik gendanner en tidligere uden at miste, hvad der kom bagefter. Den manuelle post herunder betyder stadig noget, hvor SOP'ens indhold lever uden for diagrammet, eller hvor en standard navngiver en revisionshistoriklog som sit eget artefakt; se /features/version-control for, hvad den indbyggede version gør under overfladen, uden at nogen vedligeholder den i hånden.

Én foreslået ændring, sporet til en afsluttet post

En enkelt foreslået ændring af en SOP, sporet række for række fra det øjeblik, den identificeres, til den afsluttede logpost, der navngiver den version, den erstatter.

1. Hvad der registreres, før noget andet

   Diagrammet starter ved »Ændring af en SOP identificeret«, derefter »Beskriv den foreslåede ændring og årsagen til den« (SOP'en, trinnet, hvad der ændres, hvorfor, og ikrafttrædelsesdatoen), før »Berører ændringen et sikkerhedskritisk trin?« afgør, hvilken reviewvej posten tager.

2. Hastesporsopdelingen og dublettjekket

   En sikkerhedskritisk ændring bliver »markeret til hastereview«, mens alt andet »sendes gennem den almindelige reviewcyklus«; begge rammer derefter »Har revisionshistorikken allerede en verserende post for denne SOP?«, før »Udarbejd revisionshistorikposten: dato, ændringsresumé, forfatter, erstattet version« skrives som en Fil-række.

3. To tjek, før en post kan stoles på

   »Reviewer tjekker posten mod den aktuelle SOP-tekst« kommer først; »Kommentarer, der skal afklares før godkendelse?« løkker en uafklaret post tilbage gennem SOP-forfatteren til et nyt review, og først derefter tjekker godkenderen den mod »SOP-masterdokumentet og den version, den erstatter«.

4. Afsluttet, og derefter lukkes den gamle version

   »Registrér den godkendte post som endelig i revisionshistorikken« låser dato, godkender og versionsnumre, før SOP'ens eget versionsnummer og ikrafttrædelsesdato opdateres, og »Træk den erstattede version tilbage eller arkivér den« afslutter den post, den nye erstattede.

Sådan fungerer det

1. Registrér de fem felter på hver post

   Skriv den berørte SOP og trin ned, hvad der ændrede sig og hvorfor, ikrafttrædelsesdatoen, forfatteren og det præcise versionsnummer, denne post erstatter. En post uden den erstattede version efterlader et hul i loggen, ingen kan lukke bagefter.

2. Send sikkerhedskritiske ændringer ind på hastesporet

   Spørg, om ændringen rører et sikkerhedskritisk trin, før den går til review. Gør den det, skal I markere den til hastereview frem for at lade den stå i kø bag rutineændringer; gør den ikke, skal I sende den gennem den almindelige reviewcyklus.

3. Tjek for en verserende post, før I udarbejder

   Gennemsøg loggen for en post, der allerede er åben mod samme SOP, før I starter en ny. To åbne poster mod samme procedure giver to kandidatversionsnumre: koordinér med den anden forfatter, eller sekvensér ændringerne i stedet for at udarbejde parallelt.

4. Lås posten, når den er godkendt

   Registrér den godkendte post som endelig, opdater derefter SOP'ens versionsnummer og ikrafttrædelsesdato, og træk den version, den erstatter, tilbage. En post, der forbliver redigerbar efter godkendelse, er ikke en registrering, det er et udkast med en godkenders navn på.

5. Lad ændringsloggen stå for registreringen for en diagrambaseret SOP

   Er selve SOP'en et QueryChart-flowchart, kan I springe den manuelle log over for alt, der fanges på diagrammet: hver redigering er allerede sporet felt for felt. Åbn Versionshistorik, brug Sammenlign versioner til at se, hvad der ændrede sig mellem to gemte versioner, og gendan en tidligere med ét klik. Se /features/version-control.

Faldgruber du skal undgå

• Posten uden en erstattet version

  En revisionshistorikpost, der registrerer, hvad der ændrede sig, men ikke hvilken version den erstattede, kan ikke rekonstrueres til en tidslinje senere. Gør den erstattede version til et obligatorisk felt, før udarbejdelsen begynder, ikke en valgfri note.

• To åbne poster for én SOP

  To forfattere, der starter revisionshistorikposter for samme SOP i samme uge, giver to konkurrerende versionsnumre. Tjek for en verserende post, før I udarbejder, og koordinér frem for at forsone kollisionen, efter begge er blevet godkendt.

• Rettelsesmarkeringer i stedet for en log

  Track changes-filer, der sendes rundt over mail, spreder den faktiske rækkefølge af hvem-ændrede-hvad-hvornår ud over indbakker. En dateret logpost, eller et diagrams egen ændringslog, er en registrering; en rettelsesmarkeret vedhæftning, der ligger i nogens indbakke, er ikke.

• At forveksle én post med hele programmet

  At få én enkelt post rigtig retter ikke et nummereringssystem, der glider, eller et reviewinterval, ingen sporer: det er styringslaget på /da/guides/saadan-styrer-du-sop-revisioner. Denne side handler om én post; den handler om kadencen på tværs af dem alle.

Byg jeres SOP's revisionshistoriklog

Tag revisionshistorikloggen som jeres eget diagram, fastlæg de felter, jeres poster registrerer, og lad Versionshistorik spore hver redigering automatisk derfra.

Byg jeres SOP's revisionshistoriklog

Relaterede guides

• Sådan styrer du SOP-revisioner
• Best practice for SOP-versionsstyring
• Sådan laver du en revisionshistorik for dokumenter

Ofte stillede spørgsmål

Er »track changes« det samme som versionsstyring for en SOP?

Ikke helt. »Track changes« er dokumentredigeringssprog for indbyggede rettelsesmarkeringer og kommentarer inde i én fil. Versionsstyring for en SOP er praksissen med at give hver godkendt tilstand af proceduren sin egen identificerede version og holde en registrering af, hvad der ændrede sig mellem dem; en revisionshistorikpost er, hvordan den registrering bliver skrevet ned. Se /da/guides/versionsstyring-af-sop for det fyldigere skel.

Hvad skal en revisionshistorikpost registrere?

Fem ting, uanset hvem der skriver den: den berørte SOP og trin, en beskrivelse i klart sprog af ændringen og årsagen til den, ikrafttrædelsesdatoen, forfatteren og det præcise versionsnummer, posten erstatter. Den manglende erstattede version er det klart hyppigste hul i en revisionshistoriklog.

Går alle SOP-ændringer gennem samme review?

Nej. En ændring af et sikkerhedskritisk trin følger en hastereviewvej frem for at stå i kø bag rutineændringer, mens alt andet går gennem den almindelige cyklus. Begge veje mødes i samme dublettjek, før udarbejdelsen begynder: er der allerede en verserende post åben mod denne SOP?

Hvordan adskiller dette sig fra generelt at styre SOP-revisioner?

Denne side handler om mekanikken bag én post: de felter, den har brug for, reviewopdelingen, dublettjekket. Nummereringssystemet, reviewintervallet og hvem der ejer tidsplanen på tværs af hver SOP er styringslaget, gennemgået på /da/guides/saadan-styrer-du-sop-revisioner.

Erstatter QueryChart den manuelle log?

For en diagrambaseret SOP, ja, for alt der fanges på selve diagrammet: hver feltvise redigering registreres automatisk i Versionshistorik, med en Sammenlign versioner-visning og gendannelse med ét klik. Se /features/version-control. En manuel log er stadig værd at føre, hvor SOP'ens indhold lever uden for diagrammet, eller hvor en standard navngiver en revisionshistoriklog som sit eget artefakt, som det fyldigere livsforløb i den styrede SOP-skabelon.