Best practice for SOP-versionsstyring
Best practice for SOP-versionsstyring ud over generel dokumentstyring: lås sikkerhedskritiske revisioner bag obligatorisk genoplæring, hold én ejer pr. SOP, udfas erstattede kopier overalt, og sæt reviewintervaller efter risiko.
Best practice for SOP-versionsstyring er de disciplinner, der er specifikke for standardprocedurer (en genoplæringsport på sikkerhedskritiske revisioner, én ansvarlig ejer for selve SOP'en, tilbagetrækning fra hvert anvendelsessted, og reviewintervaller sat efter driftsmæssig risiko), lagt oven på generel dokumentversionsstyring.
Kort fortalt
- Lås en sikkerhedskritisk revision bag praktisk genoplæring og et underskrevet kompetencetjek, ikke læs-og-kvitter: se /da/templates/sop-aendringsstyring-proces.
- Navngiv én ansvarlig ejer for selve SOP'en, uafhængig af hvem der udarbejdede den seneste revision.
- Træk en erstattet SOP tilbage fra hvert anvendelsessted (mapper ved arbejdsstationen, opslagstavler, fælles drev), ikke kun registret.
- Sæt reviewintervallet efter driftsmæssig risiko, ikke en flad årlig dato anvendt ens på hver SOP.
- QueryCharts ændringslog og Sammenlign versioner-visning, på /features/version-control, giver jer hvem-ændrede-hvilket-felt-dokumentationen uden ekstra proces.
Fire disciplinner en generisk tjekliste springer over
Denne side antager, at mekanikken allerede kører. Har jeres revisionshistoriklog stadig brug for et workflow (hvem udarbejder en post, hvem reviewer den, hvem skriver under), er det gennemgået på /da/guides/saadan-sporer-du-aendringer-i-en-sop, og den kadence, der holder poster i bevægelse til tiden, er på /da/guides/saadan-styrer-du-sop-revisioner. Det, ingen af de sider spørger om, er, om praksissen er nogen god, når den først kører, og for en SOP specifikt betyder »god« noget snævrere, end det gør for en politik eller en regnearksskabelon.
/da/guides/best-practice-for-dokumentversionsstyring dækker den generelle disciplin (et stabilt id, én autoritativ placering, et reviewinterval med en navngiven ejer), og hver af de regler gælder stadig for en SOP. Det ekstra er, at en SOP fortæller nogen, hvordan de fysisk skal udføre en opgave, så en revision, der ændrer proceduren, ændrer, hvad en person gør med sine hænder, ikke bare hvad en fil siger. Fire praksisser følger af den forskel, og en generisk dokumenttjekliste har ingen grund til at nævne nogen af dem: en kompetenceport, før en sikkerhedskritisk revision går i drift, ejerskab fastgjort til SOP'en frem for til hvem der sidst udarbejdede den, tilbagetrækning der når arbejdsstationen og ikke kun registret, og et reviewinterval sat efter risiko frem for en flad kalenderdato.
Tre af de fire dukker direkte op i den revisionshistoriklog, der gennemgås herunder: en sikkerhedskritisk gren, der dirigerer nogle poster anderledes end andre, et tjek for en dublet, der allerede er åben på samme SOP, og et tilbagetrækningstrin, der skal nå den kopi, der er i brug, ikke kun loggen. Den fjerde (én ansvarlig ejer) er en regel om, hvem der er navngivet på registreringen, frem for noget en diagramfigur håndhæver. QueryCharts egen versionshistorik giver en dokumentansvarlig samme slags dokumentation for selve diagrammet: en ændringslog med feltvise diffs, en Sammenlign versioner-visning og gendannelse med ét klik, alt sammen gratis og slået til som standard, beskrevet i fulde detaljer på /features/version-control.
Hvor praksisserne dukker op i en reel log
Samme 18-rækkers revisionshistoriklog, to tidligere guides har gennemgået, læst her for, hvad den gør rigtigt omkring ejerskab, dirigering og tilbagetrækning.
Ejeren flager risiko, før nogen udarbejder
Startrækken er en hændelse (»Ændring af en SOP identificeret«), og banen Procesejer beskriver ændringen og dens årsag, før Beslutning-rækken »Berører ændringen et sikkerhedskritisk trin?« sender den ned ad en af to veje.
Én post pr. SOP, ikke én pr. redaktør
»Har revisionshistorikken allerede en verserende post for denne SOP?« tjekker for en dublet undervejs, og »Koordinér med ejeren af den verserende post« fletter eller sekvenserer den frem for at lade to åbne poster give to kandidatversionsnumre.
Review og godkendelse tjekker posten, ikke kun udkastet
Godkenderens række tjekker posten »mod SOP-masterdokumentet og den version, den erstatter«, ikke kun udkastet, og en afvist »Godkendt?«-gren vender tilbage til den samme omarbejdningsrække, en reviewers åbne kommentar ville bruge.
Lås den, og træk den så tilbage overalt
»Registrér den godkendte post som endelig i revisionshistorikken« låser dato, godkendernavn og versionsnumre, så rækken ikke lydløst kan omskrives, og derefter skal »Træk den erstattede version tilbage eller arkivér den« nå den printede kopi ved arbejdsstationen, ikke kun denne logpost, før SOP'en genudstedes.
Sådan fungerer det
Tilføj en genoplæringsport til sikkerhedskritiske revisioner
Send enhver revision, der rører et sikkerhedskritisk trin, til praktisk genoplæring og en underskrevet kompetencetjekliste, før den går i drift, ikke læs-og-kvitter. /da/templates/sop-aendringsstyring-proces viser porten som en QA-godkendelsesgren, der blokerer idriftsættelse, indtil hver berørt operatør har skrevet under.
Navngiv én ansvarlig ejer pr. SOP
Sæt ejerens navn på selve SOP-registreringen, i et felt adskilt fra forfatteren af enhver enkelt revision. Ejerskabet bør overleve en personaleændring eller en overdragelse af udarbejdelsen; er »ejeren« blot den, der sidst redigerede filen, er ingen ansvarlig for dokumentet gennem hele dets liv.
Byg en tilbagetrækningstjekliste efter anvendelsessted
List hvert sted, en revision når ud til, før I udsteder den (mappen ved arbejdsstationen, opslagstavlen, det fælles drev, introduktionsmappen), og kryds hver af dem af, når den erstattede kopi tages ned. En registerpost markeret »trukket tilbage« med en printet kopi stadig på væggen er ikke trukket tilbage.
Trin reviewintervaller efter risiko, ikke en flad kalender
Giv en sikkerhedskritisk SOP et kortere interval end en lavrisiko-administrativ én; at stemple hvert dokument med samme årlige dato gør review til en formalitet, ingen har tid til at gøre grundigt. Sæt intervallet, når SOP'en udstedes, ikke når registret tilfældigvis flager det.
Bevis praksissen med ændringsloggen, ikke kun registret
Åbn Sammenlign versioner på diagrammet for at se præcis hvilket felt der ændrede sig, fra hvilken værdi, og hvem der godkendte det, i stedet for at stole på revisionshistorikloggens egen gengivelse af sig selv. QueryChart fører denne gratis versionshistorik på hvert diagram: se /features/version-control.
Faldgruber du skal undgå
En underskrift, der beviser intet
En læs-og-kvitter-kvittering beviser, at nogen åbnede filen, ikke at de kan udføre den nye metode korrekt. Reservér den til lavrisiko-ændringer, og kræv praktisk genoplæring med en underskrevet tjekliste, hvor som helst trinnet er sikkerhedskritisk.
Ejerskab, der skifter med hver redigering
Hvis ansvaret som standard falder på den, der sidst rørte udkastet, efterlader en forfatter, der stopper, SOP'en helt uden ejer. Tildel ejerrollen én gang, på SOP'en, og opdater den bevidst, frem for at lade forfatterskab glide ind i den.
Trukket tilbage i registret, levende på væggen
At markere en revision som erstattet i loggen gør intet ved den laminerede kopi, der er tapet op ved arbejdsstationen. Gennemgå jeres egen tilbagetrækningsliste, før I stoler på den: de kopier, I finder, er dem, processen missede.
Ét interval for hver SOP uanset risiko
En flad årlig reviewdato gør højrisiko-SOP'er til lavprioriteret papirarbejde og lavrisiko-SOP'er til spildt reviewkapacitet. Trin intervallet efter det, SOP'en styrer, ikke efter hvornår det tilfældigvis forfalder.
Byg jeres egen SOP-revisionshistoriklog
Åbn eksemplet på SOP-revisionshistorik som jeres eget diagram, og tilpas den sikkerhedskritiske gren, ejerfeltet og reviewintervallet til jeres egne SOP'er.
Relaterede guides
Ofte stillede spørgsmål
Er SOP-versionsstyring forskellig fra generel dokumentversionsstyring?
Mekanikken er den samme (et stabilt id, én autoritativ kopi, et reviewinterval), og /da/guides/best-practice-for-dokumentversionsstyring dækker dem. Det, der er forskelligt, er konsekvensen af et hul: en SOP fortæller nogen, hvordan de fysisk skal udføre en opgave, så en forældet eller ikke-tilbagetrukket kopi ændrer, hvad en person faktisk gør, hvilket er grunden til, at SOP-praksis tilføjer en genoplæringsport og et anvendelsesstedstjek for tilbagetrækning, en politik eller en formular ikke har brug for.
Hvornår har en revision brug for genoplæring i stedet for læs-og-kvitter?
Når ændringen berører et sikkerhedskritisk trin: alt, hvor det at gøre det på den gamle måde forårsager personskade, et ikke-konformt produkt eller en overtrædelse af lovkrav. /da/templates/sop-aendringsstyring-proces dirigerer det tilfælde gennem en QA-gated godkendelse og obligatorisk praktisk genoplæring med en underskrevet kompetencetjekliste; alt andet kan gå gennem det lettere læs-og-kvitter-spor.
Bør SOP-ejeren og SOP-forfatteren være samme person?
Ikke nødvendigvis, og at holde dem adskilt er som regel den mere holdbare ordning. Forfatteren udarbejder en given revision; ejeren er ansvarlig for SOP'en gennem hver revision, den nogensinde vil få, inklusive dem udarbejdet af en anden, efter den oprindelige forfatter er gået videre.
Er SOP-versionsstyring det samme som SOP-ændringsstyring?
Nej. Versionsstyring er, hvordan I identificerer og sporer revisioner; ændringsstyring er den workflow-port, en foreslået ændring passerer gennem, før den bliver til én. /da/guides/versionsstyring-kontra-aendringsstyring dækker den generelle skelnen, og for SOP'er specifikt er /da/templates/sop-aendringsstyring-proces den ændringsstyringsport, der producerer den version, denne sides praksisser derefter styrer.
