Sådan versionsstyrer du en SOP
SOP-versionsstyring betyder at nummerere hver procedurerevision, sende sikkerhedskritiske ændringer gennem praktisk genoplæring og en underskrevet tjekliste i stedet for læs-og-kvitter, og udfase den kopi, den erstatter.
SOP-versionsstyring er disciplinen, der binder hver procedurerevision til et nummer, en godkendelsesregistrering og et genoplæringskrav, så ingen operatør nogensinde udfører et sikkerhedskritisk trin efter en erstattet kopi.
Kort fortalt
- Nummerér hver SOP-revision, og tryk den på hver side: nummeret er dét, en oplæringsregistrering og et auditspor begge peger på.
- Send sikkerhedskritiske ændringer gennem en dokumenteret sikkerhedskonsekvensvurdering og praktisk genoplæring, ikke læs-og-kvitter.
- En underskrevet kompetencetjekliste er bevis for genoplæring; en læsekvittering er kun bevis for, at nogen åbnede filen.
- De to reviewveje (sikkerhedskritisk og almindelig) mødes stadig i ét trin: markér den forrige revision som erstattet.
- QueryCharts ændringslog og Sammenlign versioner-visning (/features/version-control) viser, hvem der ændrede hvilket felt, uden et separat register.
En forældet SOP er ikke et arkiveringsproblem
En SOP er ikke en registrering af, hvad der generelt bør ske: det er den præcise rækkefølge, nogen på vagt lige nu følger, hvilket er grunden til, at versionsstyring af en SOP bærer en risiko, en politik eller en regnearksskabelon ikke gør. En forældet revision af et marketingoplæg koster nogen en eftermiddags omarbejde. En forældet revision af en lockout-tagout-procedure eller en tjekliste til batchfrigivelse koster nogen deres hånd, eller sender et ikke-konformt parti ud, fordi en operatør, der gør præcis det, sedlen på væggen siger, gør præcis det, processen bad om, selv når sedlen er to revisioner bagud.
Generel dokumentversionsstyring, gennemgået på /da/guides/versionsstyring-af-dokumenter, spørger om, hvilken fil der er gældende, og hvem der godkendte den. SOP-versionsstyring stiller ét spørgsmål mere for hver ændring: hvem skal genoplæres, før de udfører trinnet anderledes, og hvordan beviser I det. Et tal, der optælles i et register, stopper ikke en operatør i at køre den gamle metode; kun en gennemført, dateret, underskrevet oplæringsregistrering knyttet til det nye revisionsnummer gør det, hvilket er grunden til, at en styret SOP's godkendelsesworkflow (se den styrede SOP-skabelon) skal aflevere videre til et genoplæringstrin i stedet for at stoppe ved »godkendt«.
Diagrammet herunder forgrener sig præcis på den vurdering (»Berører ændringen et sikkerhedskritisk trin?«), fordi de to svar kræver forskellig dokumentation. En sikkerhedskritisk ændring sendes gennem en dokumenteret sikkerhedskonsekvensvurdering, en QA-gated godkendelse og praktisk genoplæring med en underskrevet kompetencetjekliste; en ikke-sikkerhedskritisk ændring får et almindeligt egnethedsreview og læs-og-kvitter. At smelte de to sammen til én vej, eller behandle en læsekvittering som bevis for kompetence på et sikkerhedskritisk trin, er det auditfund, denne proces findes for at forhindre. QueryCharts egen versionshistorik (se /features/version-control) giver et QA-team en ændringslog og en Sammenlign versioner-visning til at tjekke, at hver revision faktisk fulgte denne vej, uden et parallelt regnearksregister, der glider fra det, diagrammet siger skete.
Den sikkerhedskritiske forgrening, trin for trin
En SOP-ændring, der bevæger sig fra anmodning gennem beslutningen, der sender den enten ind i et sikkerhedsreview og praktisk genoplæring eller et almindeligt review og en læsekvittering.
En anmodning logget mod en revision
»SOP-ændring foreslået« starter kæden, og derefter binder »Indsend ændringsanmodning med årsag« og »Log anmodningen mod den aktuelle SOP-revision« anmodningen til en specifik version, før »Vurder den driftsmæssige konsekvens af den foreslåede ændring« begynder: intet her har endnu vurderet ændringen, kun registreret, hvad den er, og hvad den erstatter.
Forgreningen, der afgør, hvor krævende det bliver
»Berører det et sikkerhedskritisk trin?« forgrener processen: et Ja-svar sender den ind i »Gennemfør dokumenteret sikkerhedskonsekvensvurdering« og derefter »Indsend ændringspakken til QA-godkendelse«, gated af endnu en »Godkendt?«-beslutning, der afviser lige tilbage til sikkerhedsvurderingen frem for forbi den.
Praktisk genoplæring over for et almindeligt review
Godkendte sikkerhedskritiske ændringer går videre til »Planlæg obligatorisk praktisk genoplæring« og »Gennemfør praktisk oplæring, og underskriv kompetencetjekliste« (en superviseret, underskrevet gennemgang, ikke en læsekvittering), mens Nej-grenen kører »Gennemfør almindeligt egnethedsreview« ind i sin egen »Indsend ændringspakken til godkendelse« og »Godkendt?«-gate.
Begge veje mødes i én registeropdatering
Den almindelige vej ender stadig i »Distribuer den opdaterede SOP til læs-og-kvitter« og »Læs og kvittér for den nye version«, og begge veje mødes ved »Opdater SOP-registret, og markér den forrige revision som erstattet«, før »Publicer den nye revision som den aktuelle, styrede version« gør den gældende.
Sådan fungerer det
Fastlæg SOP-nummereringssystemet før den første revision
Tildel hver SOP et id og en revision med et helt tal, trykt i sidehovedet på hver side sammen med ikrafttrædelsesdatoen og godkenderen. Beslut dette én gang, for at omnummerere senere ødelægger hver genoplæringsregistrering og hvert auditspor, der citerede det gamle nummer.
Log anmodningen mod den revision, den ændrer
Åbn en anmodning med det præcise trin, der ændres, og årsagen (en hændelse, en nærved-hændelse, en afvigelse), før nogen rører udkastet. Skriv det ind i et diagrams kolonne Bokstekst, og brug Linje til til at pege den på den række, der logger anmodningen mod den aktuelle revision, så anmodningen bindes til en version i stedet for at flyde frit.
Tving den sikkerhedskritiske beslutning frem eksplicit
Giv workflowet en Beslutning-række, der spørger, om et sikkerhedskritisk trin er berørt, med to navngivne grene i kolonnen Linjetekst. Send »Ja« ind i en dokumenteret sikkerhedskonsekvensvurdering og »Nej« ind i et almindeligt egnethedsreview; lad aldrig en anmoder eller godkender springe spørgsmålet over ved en antagelse.
Lås den sikkerhedskritiske vej bag praktisk genoplæring, ikke kvittering
Efter godkendelse skal I planlægge obligatorisk praktisk oplæring og kræve en underskrevet kompetencetjekliste, før ændringen kan gå i drift. En række, der kun siger »læs og kvittér«, hører til på den almindelige vej, ikke den sikkerhedskritiske: hold de to som separate rækker, så skellet overlever en senere omrokering.
Lad begge veje mødes i én registeropdatering
Uanset hvilken gren en ændring tog, skal den sendes ind i én Fil-formet række, der opdaterer SOP-registret og markerer den forrige revision som erstattet, før den nye publiceres som gældende. Ét sammenløbspunkt betyder ét sted at tjekke, at hver vej faktisk når frem til udfasning af den gamle kopi.
Bekræft hver berørt operatør, ikke kun dem på vagtplanen
Før publicering skal I krydse genoplæring eller kvittering af mod hver vagt og hver kontraktør, trinnet berører, ikke kun det team, der tilfældigvis var på stedet, da ændringen blev godkendt. En overset nattevagt er det fund, der bliver ved med at gå igen hver auditcyklus.
Faldgruber du skal undgå
Læs-og-kvitter på et sikkerhedskritisk trin
En læsekvittering beviser, at nogen åbnede filen, ikke at de kan udføre trinnet sikkert. Send i stedet enhver ændring af et sikkerhedskritisk trin gennem praktisk genoplæring og en underskrevet kompetencetjekliste, som i »Gennemfør praktisk oplæring, og underskriv kompetencetjekliste«.
En afvist ændring går ind i reviewet igen, ikke kun udkastet
Det er fristende at løkke »Godkendt?« lige tilbage til anmodningstrinnet, så en afvist ændring kan omformuleres og genindsendes. På den sikkerhedskritiske vej skal I i stedet sende afvisningen tilbage til »Gennemfør dokumenteret sikkerhedskonsekvensvurdering« (præcis som dette diagram gør), så et revideret udkast bliver vurderet for sikkerhed igen, ikke bare skrevet om og genindsendt.
Én registerpost, der ikke navngiver vagten
»Opdater SOP-registret, og markér den forrige revision som erstattet« er kun sandt, når hver berørt vagt og kontraktør har genoplært eller kvitteret, ikke når dagvagten har. Navngiv den population, trinnet når ud til, ellers bliver et natholds mandskab ved med at køre den tilbagetrukne version.
Lav jeres egen proces for SOP-ændringsstyring
Åbn eksemplet på SOP-ændringsstyring som jeres eget diagram, fastlæg jeres nummereringssystem, og hold den sikkerhedskritiske forgrening intakt, så genoplæring forbliver obligatorisk frem for valgfri.
Relaterede guides
Ofte stillede spørgsmål
Er SOP-versionsstyring forskellig fra generel dokumentversionsstyring?
Ja, på én bestemt måde: en SOP's versionsstyring skal svare på, hvem der skal genoplæres, før den nye revision træder i kraft, ikke bare hvilken kopi der er gældende. Generel dokumentversionsstyring (gennemgået på /da/guides/versionsstyring-af-dokumenter) styrer nummerering, godkendelse og tilbagetrækning for ethvert styret dokument. En SOP tilføjer et kompetencespørgsmål under det: et optalt revisionsnummer stopper ikke en operatør i at køre den gamle metode, før vedkommende er genoplært i den nye, så versionsstyringsregistreringen for en SOP skal bære en oplærings- eller kvitteringsstatus sammen med det sædvanlige godkendelsesspor.
Hvordan bør en sikkerhedskritisk SOP-ændring dirigeres anderledes end en mindre én?
En sikkerhedskritisk ændring (hvor det at gøre trinnet forkert risikerer personskade, et ikke-konformt produkt eller en overtrædelse af lovkrav) kræver en dokumenteret sikkerhedskonsekvensvurdering, en QA-gated godkendelse og praktisk genoplæring med en underskrevet kompetencetjekliste, før den kan gå i drift. En ikke-sikkerhedskritisk ændring kan gå gennem et almindeligt egnethedsreview, almindelig godkendelse og læs-og-kvitter. At sende begge gennem den samme lette vej er, hvordan en formuleringsjustering og en ændring af et lockout-trin ender med at blive holdt til den samme dokumentationsstandard, som er for lidt til den ene og for meget til den anden.
Er en oplæringsregistrering det samme som versionsstyring for en SOP?
Nej: de svarer på forskellige spørgsmål, og en SOP-proces har brug for begge dele. Versionsstyring sporer, hvilken revision der er gældende, hvem der godkendte den, og hvad den erstattede; en oplæringsregistrering sporer, hvem der har demonstreret kompetence på den revision. QueryCharts versionshistorik på /features/version-control dækker det første: en ændringslog med feltvise diffs, en Sammenlign versioner-visning og gendannelse. Den underskrevne kompetencetjekliste, en sikkerhedskritisk ændring kræver, beskrevet ovenfor, dækker det andet, og de to skal henvise til det samme revisionsnummer, ellers kan en auditor ikke se, om den oplærte person matcher den gældende procedure.
Hvad er den minimumsdokumentation, en auditor forventer for en SOP-revision?
Et revisionsnummer og en ikrafttrædelsesdato trykt på dokumentet, en registrering af hvem der godkendte det og hvornår, en dokumenteret årsag til ændringen bundet til den anmodning, der startede den, og (for alt sikkerhedskritisk) en dateret, underskrevet kompetenceregistrering, der navngiver, hvem der blev genoplært, og på hvilken version. For selve SOP-dokumentets dirigerings- og godkendelsesmekanik, se den styrede SOP-skabelon; for det snævrere spørgsmål om, hvad der ændrede sig mellem to revisioner, se /da/guides/saadan-sporer-du-aendringer-i-en-sop.
