Skabelon til SOP-revisionshistorik
En skabelon til SOP-revisionshistorik: hvordan en foreslået ændring af en SOP bliver til en dateret logpost, tjekkes mod verserende ændringer, reviewes, godkendes og afsluttes med den version, den erstatter.
Hvad er skabelon til SOP-revisionshistorik?
En revisionshistorik er det register, der besvarer ét spørgsmål for en SOP: hvad blev ændret, hvornår, hvem lavede ændringen, hvem godkendte den, og hvilken version erstatter den nuværende. Det er et selvstændigt dokument adskilt fra selve SOP'en: proceduren beskriver, hvordan arbejdet udføres i dag, mens revisionshistorikken er den append-only-registrering af hver version, der kom før den. Auditorer og nye procesejere læser loggen først, fordi det er den hurtigste måde at fastslå, om proceduren foran dem er den styrede, aktuelle version, eller noget en reviewer glemte at opdatere.
Dette diagram modellerer loggen som sin egen arbejdsgang frem for som en fodnote til SOP-godkendelsen. En foreslået ændring tjekkes mod sikkerhedskritikalitet for at afgøre, om den skal gennem hastereview eller almindeligt review, og tjekkes derefter mod selve loggen: hvis en anden post for samme SOP allerede er åben, koordineres de to ændringer, så loggen aldrig skal forene to poster, der gør krav på samme versionsnummer. Først derefter producerer udarbejdelsen selve logposten (dato, ændringsresumé, forfatter og det versionsnummer, den erstatter), hvilket er grunden til, at trinnene for udarbejdelse og afslutning bruger Fil-formen frem for Proces: det er de øjeblikke, hvor noget rent faktisk skrives ind i registret, ikke blot føres videre.
Dette er ikke SOP-dokumentets egen godkendelsesworkflow, som er den styrede SOP-skabelon på /da/templates/styret-sop-skabelon: den side sender procedurens indhold gennem udarbejdelse, review og underskrift. Dette er det register, som den arbejdsgang skriver en post til, hver gang den producerer en ny version. Det er også smallere end generel dokumentstyring, som styrer udarbejdelse, udstedelse, distribution og periodisk review for enhver type styret dokument på /da/templates/dokumentstyring-proces; dette diagram dækker kun selve loggen: dokumentet, der navngiver, hvad der ændrede sig, og hvilken version det erstattede.
Hvad dette flowchart dækker
I denne skabelon
- Fem faser øverst (Ændring identificeret, Logpost udarbejdet, Review, Godkendelse og Log afsluttet) parret med fem baner for de roller, der berører en revisionshistorikpost: Procesejer, SOP-forfatter, Reviewer, Godkender og Dokumentansvarlig.
- Indgang og rutning: en ændring identificeres og beskrives, hvorefter beslutningen 'Berører ændringen et sikkerhedskritisk trin?' sender den til hastereview eller almindeligt review, før udarbejdelsen starter.
- Et tjek for dubletposter før udarbejdelse: 'Har revisionshistorikken allerede en verserende post for denne SOP?' sender videre til at koordinere med ejeren af den åbne post, så to ændringer af samme SOP aldrig logges som to konkurrerende revisioner.
- Selve posten, udarbejdet og senere afsluttet med Fil-formen frem for Proces: dato, ændringsresumé, forfatter og det versionsnummer, den erstatter, indsendt til review og derefter til godkendelse.
- En reviewsløjfe: 'Kommentarer, der skal afklares før godkendelse?' sender posten tilbage til SOP-forfatteren til opdatering og nyt review, i stedet for at tvinge godkenderen til at afvise den direkte.
- Godkendelse og afslutning: beslutningen 'Godkendt?' sender enten posten tilbage til bearbejdning ved Afvist, eller lader dokumentansvarlig registrere den som endelig, opdatere SOP'ens versionsnummer og ikrafttrædelsesdato og arkivere den version, den erstattede.
Hvornår du skal bruge skabelonen
- I opsætter en revisionshistorik for SOP'er og vil have en struktur, der adskiller indgang, udarbejdelse, review, godkendelse og afslutning frem for ét åbent 'tilføj en række'-trin.
- To personer kan foreslå ændringer af samme SOP samtidig, og I har brug for et kontrolpunkt, der opdager en dubletpost, før den når godkendelse som to konkurrerende revisioner.
- I skal vise en auditor, hvordan en bestemt linje i revisionshistorikken opstod: hvem foreslog ændringen, hvem gennemgik den, hvem godkendte den, og hvilken version den erstattede.
- I adskiller revisionshistorikken fra selve SOP-godkendelsesworkflowet, fordi den samme log skal registrere ændringer foreslået mod én SOP af mere end én ejer over dens levetid.
Sådan fungerer det
Omdøb banerne til jeres rigtige roller
Erstat Procesejer, SOP-forfatter, Reviewer, Godkender og Dokumentansvarlig med de titler, I faktisk bruger. I et lille team er SOP-forfatteren og procesejeren ofte samme person: slå de baner sammen i stedet for at lade en stå tom; udfører en kvalitetsleder både reviewet og underskriften, så slå i stedet Reviewer og Godkender sammen.
Fastlæg testen for sikkerhedskritikalitet
Skriv ned, hvad der sender en ændring til hastereview, i stedet for at overlade 'Berører ændringen et sikkerhedskritisk trin?' til individuel vurdering: en ændring af et lockout-trin, et kritisk kontrolpunkt eller et lovpligtigt tjek bør altid kvalificere, og alt andet går som standard i den almindelige cyklus.
Fastsæt de felter, hver logpost skal indeholde
Ved udarbejdelsestrinnet skal I fastlægge de præcise felter, jeres register har brug for: postdato, SOP-nummer, et ændringsresumé i klart sprog, forfatter og det versionsnummer, der erstattes. Hold felterne identiske for hastede og almindelige poster, så loggen forbliver ensartet, uanset hvilken vej der producerede den.
Beslut, hvordan en dubletpost løses
Fastsæt reglen bag 'Har revisionshistorikken allerede en verserende post for denne SOP?': skal den anden ændring vente på, at den første afsluttes, blive lagt sammen med samme post, eller blive logget separat med en note, der krydshenviser til den anden? Alle tre virker, så længe loggen aldrig ender med to poster, der gør krav på samme versionsnummer.
Fastsæt jeres regel for versionsnummerering og ikrafttrædelsesdato
Fastlæg, hvordan versionsnumre optælles (hele tal for udstedte revisioner og decimaltal for udkast er almindeligt), og hvor meget varsel ikrafttrædelsesdatoen kræver, så dokumentansvarlig kan opdatere masterregistret og udfase den erstattede kopi, før den træder i kraft.
Ofte stillede spørgsmål
Hvad er en SOP-revisionshistorik?
Det er det daterede register, der lister hver version af en SOP, og hvad der ændrede sig mellem dem: postens dato, hvem der foreslog ændringen, et resumé af hvad der ændrede sig, hvem der gennemgik og godkendte den, og det versionsnummer, den erstattede. Det er adskilt fra SOP'ens egen godkendelsesunderskrift: SOP'en registrerer, hvem der godkendte den aktuelle version, revisionshistorikken registrerer rækkefølgen af versioner, der bragte den dertil.
Hvordan adskiller dette sig fra SOP'ens egen godkendelsesworkflow?
Den styrede SOP-skabelon på /da/templates/styret-sop-skabelon sender selve procedurens indhold gennem udarbejdelse, review og godkendelse og producerer én aktuel, underskrevet version. Dette diagram er det register, som den arbejdsgang skriver til, hver gang den producerer en ny version: den append-only-historik over datoer, forfattere, resuméer og erstattede versionsnumre, holdt som sit eget dokument, så rækkefølgen overlever uafhængigt af selve dokumentet.
Hvorfor tjekke for en verserende post, før man udarbejder en ny?
Fordi to personer kan foreslå ændringer af samme SOP inden for samme reviewcyklus uden at vide af hinanden, og hvis begge poster når godkendelse uafhængigt af hinanden, ender loggen med to rækker, der hver gør krav på at erstatte samme version. Ved at tjekke i starten, før udarbejdelsen, koordineres den anden ændring ind i den første post, i stedet for at blive opdaget som en konflikt under godkendelsen.
Skal enhver SOP-ændring gennem hastevejen?
Nej. Hastevejen findes til ændringer af sikkerhedskritiske trin, hvor intervallet mellem identifikation af ændringen og dens ikrafttræden skal være kort. Alt andet (præciseringer, formatering, ikke-kritiske proceduremæssige ændringer) bør gå gennem den almindelige reviewcyklus, for sender man alt gennem hastevejen, undergraver det formålet med at have to spor.
