Sådan styrer du SOP-revisioner

Kort fortalt

• Fastlæg nummereringssystemet før registrets første post: at omnummerere et levende bibliotek senere ødelægger hver krydshenvisning og hver oplæringsregistrering, der citerede det gamle nummer.
• Sæt reviewintervaller efter risiko, ikke efter én fælles årsdag for hver SOP, uanset hvad den styrer.
• Navngiv én ejer for hele revisionsregistret, adskilt fra enhver enkelt SOP's forfatter eller godkender.
• Registrér et review, der ikke fandt noget at ændre, som sin egen daterede post: en auditor stikprøvekontrollerer for bevis på review, ikke bevis på ændring.
• Fang dubletter af åbne poster, før de kolliderer, ellers ender samme SOP med to kandidatversionsnumre.
• QueryCharts egen ændringslog og Sammenlign versioner-visning, på /features/version-control, giver selve registret samme slags historik, det beder hver SOP om at føre.

Registret er større end nogen enkelt post

En revisionshistoriklog kan vise elleve fejlfrie poster og stadig være grunden til, at et auditfund bliver skrevet: fordi post nummer tolv aldrig fik et nummer, da to SOP-forfattere åbnede den samtidig, eller fordi ingen kan sige, om sidste marts' planlagte review faktisk fandt sted. Organisationer, der skriver SOP'er, er som regel gode til at beskrive, hvad der ændrede sig i en given post. Det, der går galt, er registret omkring de poster: nummereringssystemet, det interval, hver SOP skal revieweres inden for, og hvem der er ansvarlig, når det ene eller det andet glider.

Begreberne bliver brugt løst, og det er værd at skille dem ad, før vi går videre. En revision er én dateret post: en ændring af en SOP's indhold, logget med en forfatter og en årsag. Dens version er det nummer, den post giver, det, der er stemplet på den aktuelle udstedte kopi. Revisionsstyring er at styre den rækkefølge af poster over tid; det sidder inden i den bredere praksis dokumentstyring, som også styrer distribution og tilbagetrækning. Denne side handler om at drive registret som helhed; for mekanikken bag at logge én enkelt ændring, se /da/guides/saadan-sporer-du-aendringer-i-en-sop.

Diagrammet herunder er én revision, der bevæger sig gennem det register, fra det øjeblik en ændring identificeres, til det øjeblik SOP'en genudstedes, på tværs af fem baner: Procesejer, SOP-forfatter, Reviewer, Godkender, Dokumentansvarlig. QueryChart holder sine egne diagrammer under samme slags styring: hver gemning skriver til en ændringslog med en feltvis diff af, hvem der ændrede hvad, en Sammenlign versioner-visning sætter to vilkårlige revisioner side om side, og en forældet gendannes med ét klik: alt sammen gennemgået på /features/version-control.

Én post, fra identifikation til genudstedelse

En enkelt revisionsanmodning bevæger sig gennem fem baner (fra Procesejer til Dokumentansvarlig) og bliver registrets næste nummererede post.

1. En ændring identificeres og triageres efter risiko

   Starten er en hændelse, »Ændring af en SOP identificeret«, efterfulgt af »Beskriv den foreslåede ændring og årsagen til den«, før nogen udarbejder en post. »Berører ændringen et sikkerhedskritisk trin?« er registrets egen risikotriage, der afgør, om denne post får et hastereview eller den almindelige cyklus.

2. Dirigering, et dublettjek, så udkastet

   »Markér posten til hastereview« eller »Send posten gennem den almindelige reviewcyklus« sætter tempoet, derefter fanger »Har revisionshistorikken allerede en verserende post for denne SOP?« en anden åben post, før den kolliderer med den første. Først derefter bliver »Udarbejd revisionshistorikposten: dato, ændringsresumé, forfatter, erstattet version« skrevet og indsendt.

3. Reviewer og godkender tjekker begge nummeret

   »Reviewer tjekker posten mod den aktuelle SOP-tekst« kan sende udkastet tilbage ved »Kommentarer, der skal afklares før godkendelse?«; »Godkender tjekker posten mod SOP-masterdokumentet og den version, den erstatter« er et andet, uafhængigt tjek mod det samme erstattede nummer, og en afvisning løkker tilbage til den samme opdateringsrække som en reviewerkommentar.

4. Registerejeren afslutter og genudsteder

   »Registrér den godkendte post som endelig i revisionshistorikken« låser rækken, før »Opdater SOP'ens versionsnummer og ikrafttrædelsesdato« og »Træk den erstattede version tilbage eller arkivér den« kører, og slutter ved »SOP genudstedt i den nye version«: alle fire ejet af Dokumentansvarlig.

Sådan fungerer det

1. Fastlæg nummereringssystemet før den første post

   Beslut én gang, om udstedte revisioner får hele tal (1, 2, 3) eller et hovedversion.mindre-version-system, der skiller udkast fra udstedte kopier, og skriv reglen ned. Omnummerér aldrig et levende register for at rette en gammel uoverensstemmelse: en omnummereret rækkefølge ugyldiggør hver krydshenvisning, hver oplæringsregistrering og hvert tidligere auditspor, der citerede det gamle nummer.

2. Sæt reviewintervaller efter risiko, ikke efter én fælles regel

   En sikkerhedskritisk SOP fortjener et kortere interval end en lavrisiko-SOP; diagrammets egen gren »Berører ændringen et sikkerhedskritisk trin?« er samme triage anvendt på en enkelt ændring, og reviewkadencen fortjener samme logik. Skriv intervallet ind i selve SOP-sidehovedet som en forfaldsdato, så det ikke afhænger af, at nogen husker en politik.

3. Navngiv en ejer for hele registret

   En SOP's forfatter udarbejder dens post, og dens godkender underskriver den, men ingen af dem er ansvarlige for registret som helhed: for den post, der er tre uger forsinket, eller den SOP, hvis reviewdato ingen satte. Giv den opgave til én navngiven rolle, typisk en dokumentansvarlig eller kvalitetschef, og lad dem jagte det, der er forsinket.

4. Registrér et review uden ændringer som sin egen post

   Når et planlagt review bekræfter, at en SOP stadig er korrekt, skal I skrive det fund ind i registret med datoen og reviewerens navn, på samme måde som en faktisk revision ville blive logget. En log, der kun vokser, når indholdet ændrer sig, læses af en auditor som et dokument, ingen har kigget på, siden det blev skrevet.

5. Fang dubletposter, før de kolliderer

   Før I udarbejder en ny post, skal I tjekke, om SOP'en allerede har en verserende: registrets spørgsmål »Har revisionshistorikken allerede en verserende post for denne SOP?« findes, fordi to forfattere, der arbejder ud fra samme masterkopi, er almindeligt nok til at planlægge omkring. Flet ændringerne, eller sekvensér posterne, så loggen aldrig skal forene to kandidatversionsnumre for ét dokument.

Faldgruber du skal undgå

• At omnummerere for at rette en gammel uoverensstemmelse

  Når revision 4 først er blevet citeret i en oplæringsregistrering eller en leverandørmappe, betyder det at ændre den til 4.1 for at passe til et pænere system nu, at det samme datointerval svarer til to forskellige tal. Beslut systemet én gang, og styr derefter undtagelser i stedet for at omstrukturere rækkefølgen for at rumme dem.

• Én fælles 12-måneders reviewdato for hver SOP

  At reviewe hver procedure på samme årsdag giver en stak, ingen har tid til at læse grundigt, og review bliver et gummistempel. Spred intervallerne efter risiko, på samme måde som diagrammets sikkerhedskritiske gren gør for en enkelt ændring, så en reviewer faktisk har tid til hver enkelt.

• Ingen post for det review, der ikke ændrede noget

  Et register med poster kun dér, hvor indholdet ændrede sig, ligner for en auditor et dokument, ingen har åbnet, siden det blev udstedt. Log reviewdatoen og fundet »ingen ændring nødvendig« som sin egen linje, adskillelig fra en faktisk revision, men ikke mindre reel.

• Et register uden én samlet ejer

  Når enhver SOP-forfatter kan åbne en ny post, og ingen overvåger registret som helhed, går både dubletudkast og oversete reviewdatoer upåagtet hen, indtil et audit finder dem. Det fulde dokumentlivsforløb omkring dette problem (inklusive hvem der ejer masterregistret) er gennemgået på /da/templates/dokumentstyring-proces.

Byg jeres eget SOP-revisionsregister

Start fra dette diagram, og QueryChart sporer hver gemning i en ændringslog, I kan sammenligne og gendanne.

Byg jeres eget SOP-revisionsregister

Relaterede guides

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

Ofte stillede spørgsmål

Hvad er forskellen på en SOP's revision og dens version?

En revision er den daterede post: en ændring af SOP'ens indhold, logget med en forfatter og en årsag. Dens version er det nummer, den post giver, det, der er stemplet på den aktuelle udstedte kopi. I praksis bliver ordene brugt om det samme, men selve registret er organiseret omkring revisioner: hver række er én, og versionen er den tilstand, SOP'en er i, efter den seneste er godkendt. QueryCharts egen versionshistorik, på /features/version-control, bruger »version« på samme måde: et nummereret, sammenligneligt øjebliksbillede, en gemning producerer.

Hvor ofte bør en SOP revieweres?

Der findes ikke ét interval, der passer til enhver procedure: det rigtige svar afhænger af, hvor meget et trins fejl ville koste. En sikkerhedskritisk eller myndighedsvendt SOP bliver typisk revieweret årligt eller oftere; en lavrisiko-administrativ én kan trygt gå to til tre år mellem reviews. Det, der betyder mere end det præcise tal, er, at hver SOP har ét, skrevet ind i sit sidehoved som en forfaldsdato, frem for overladt til den, der tilfældigvis bemærker, at det er forsinket.

Hvem bør eje SOP-revisionsregistret?

Nogen adskilt fra enhver enkelt SOP's forfatter eller godkender: som regel en dokumentansvarlig eller kvalitetschef, den rolle, diagrammet ovenfor giver sin egen bane til at afslutte hver godkendt post. Forfatteren og godkenderen er hver især ansvarlige for én revision; registret har brug for én person, der er ansvarlig for helheden: at jagte forsinkede reviews, fange dubletposter og holde nummereringssystemet stabilt.

Tæller et review, der ikke finder noget at ændre, stadig?

Ja, og det har brug for sin egen registrering for at bevise det. En auditor, der stikprøvekontrollerer et revisionsregister, leder efter bevis på, at et review skete til tiden, ikke bevis på, at SOP'en ændrede sig: en procedure, der er korrekt som skrevet, bør forblive urevideret i årevis. Log reviewdatoen og fundet »ingen ændring nødvendig« som en dateret post, ellers læses hullet mellem revisioner som forsømmelse i stedet for stabilitet.

Hvordan adskiller dette sig fra at spore hver enkelt ændring i en SOP?

At spore en enkelt ændring er på postniveau: hvad der ændrede sig, hvem der ændrede det, og hvad det erstattede, hvilket er emnet for /da/guides/saadan-sporer-du-aendringer-i-en-sop. At styre SOP-revisioner er på registerniveau: det nummereringssystem, hver post skal følge, det reviewinterval, hver SOP skal leve op til, og den navngivne ejer, der er ansvarlig, når det ene eller det andet svigter. Et register kan logge hver enkelt ændring perfekt og stadig være dårligt styret, hvis ingen ejer tidsplanen. For det fyldigere sæt af styringspraksisser ud over denne side, se /da/guides/best-practice-for-sop-versionsstyring.