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.
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.