Flowchart for ændringsstyring i procesanlæg (MOC, PSSR, udløb)

Sådan fungerer det

1. Omdøb banerne, så de passer til jeres anlæg

   Erstat Anmoder, MOC-koordinator, Teknisk ansvarlig, Risikoteam, Godkendende leder og Drift med de roller, jeres anlæg reelt har. De fleste steder deler det tekniske ansvar op efter fag — proces, mekanisk, el, styring og instrumentering — så beslut, om det er én bane eller flere. Hold koordinatoren adskilt fra den teknisk ansvarlige: den ene kører processen og rykker for registret, den anden bærer det ingeniørmæssige skøn. Rejser entreprenører og eksterne håndværkere ændringer hos jer, så skriv det, for en bane, der hedder Anmoder og i praksis kun betyder egne ansatte, er præcis den vej, entreprenørmodifikationer slipper uden om processen.

2. Skriv testen for identisk udskiftning ned

   'Identisk udskiftning?' er den ene kasse, der kan tage en ændring helt ud af processen, så den kræver skrevne kriterier frem for skøn. Definér identisk som ens i specifikation, materiale, klassificering, producentens designforudsætning og installeret konfiguration, og udpeg derefter, hvem der er kompetent til at anvende testen — at finde en tilsvarende reservedel i lagersystemet er ikke en ingeniørmæssig afgørelse. Udgåede komponenter er der, hvor de fleste anlæg mister grebet: når den oprindelige enhed ikke længere produceres, er leverandørens nærmeste aktuelle model en ændring, og det bør stå på blanketten frem for at være overladt til den, der har mest travlt.

3. Fastlæg rutereglen for risikogennemgang

   Lav 'Hvilket niveau for risikogennemgang?' om til en tabel frem for en samtale. Lav risiko kan være en dokumenteret tjekliste for ændringsrisici udfyldt af to kompetente personer. Mellem risiko er en what-if eller en struktureret what-if med tjekliste. Høj risiko — alt, der rører et kemikalie, en interlock, et aflastningssystem, en reguleringsfilosofi eller en sikker driftsgrænse — går til en faciliteret HAZOP med den oprindelige analyse åben foran teamet. Udpeg, hvem der fastlægger niveauet, og kræv, at begrundelsen bliver registreret ved siden af beslutningen.

4. Offentliggør godkendelsesmatrixen

   Godkendelsen skal følge faren, ikke prisen. Skriv ned, hvem der må godkende en permanent ændring med lav risiko, hvem der skal godkende alt, der påvirker en sikkerhedsinstrumenteret funktion, en aflastningsdimensionering eller et driftsvindue, og hvem der skriver under på en ændring, der ændrer sikkerhedsrapporten. Giv svaret 'Mere arbejde krævet' reelle tænder: det sender ændringen tilbage til 'Dokumentér det tekniske grundlag' frem for at blive givet som en betinget godkendelse, hvis betingelser ingen bagefter ejer.

5. Gør PSSR til en fysisk gennemgang med en lukket handlingsliste

   En sikkerhedsgennemgang før opstart, der kan gennemføres ved et skrivebord, er ingen sikkerhedsgennemgang. Tjeklisten skal bekræfte, at udførelsen svarer til designet, at drifts-, vedligeholds- og nødprocedurer findes og er ajour, at de folk, der skal køre ændringen, er oplært, og at handlingerne fra risikogennemgangen er lukket frem for tildelt. Beslut, hvem der må erklære gennemgangen bestået, hold vedkommende uden for det team, der har bygget ændringen, og send enhver udestående handling tilbage gennem 'Luk PSSR-handlingerne'.

6. Sæt ejer på hver udløbsdato, gå diagrammet igennem og udgiv det

   Giv hver midlertidig ændring en navngiven ejer og en dato, registret rejser før den indtræffer, ikke efter. Aftal derefter, hvad den maksimale levetid for en midlertidig ændring er, og om en akut ændring skal gennem den fulde proces inden for dage eller uger. Gå til sidst det færdige diagram igennem med et driftshold, en vedligeholdsleder, den teknisk ansvarlige og den, der godkender ændringer, ret det til det, de faktisk gør, og udgiv den revision — behold de tidligere, så enhver, der åbner den senere, kan se, hvilken version de læser.

Ofte stillede spørgsmål

Hvilke trin består en ændringsstyringsproces (MOC) af?

Foreslå ændringen og log den i MOC-registret; screen den mod testen for identisk udskiftning, så identiske udskiftninger forlader flowet som vedligehold; klassificér resten som permanent, midlertidig eller akut, og giv de midlertidige en udløbsdato og en fjernelsesplan; dokumentér det tekniske grundlag; kør en risikogennemgang dimensioneret efter risikoen, fra en tjekliste for ændringsrisici over en what-if-analyse til en fuld HAZOP; vurder påvirkningen af sikkerhedssystemer, driftsgrænser og sikkerhedsrapporten, og registrér handlingerne; godkend på det niveau, faren kræver; opdatér procedurer, tegninger og P&ID’er; oplær alle berørte, også vedligehold og entreprenører; bestå en sikkerhedsgennemgang før opstart; gennemfør ændringen og start op; luk derefter sagen med dokumentationen gemt, eller — for en tidsbegrænset ændring — gennemgå den ved udløb og enten gør den permanent eller fjern den. For en dansk risikovirksomhed følger kravet af Seveso-reglernes krav til sikkerhedsledelsessystemet, som netop skal omfatte styring af ændringer; den amerikanske PSM-standard, som mange koncernprocedurer er bygget over, er mere eksplicit og kræver, at den skrevne procedure dækker det tekniske grundlag, påvirkningen af sikkerhed og sundhed, ændringer i procedurer, ændringens tidsperiode og kravene til godkendelse. Dette diagram er den liste omsat til en vej med porte.

Hvad tæller som en identisk udskiftning?

En identisk udskiftning er en enhed, der er identisk med den, den erstatter, i specifikation, materiale, klassificering og designforudsætning — samme del, efter samme tegning, monteret på samme måde. Alt andet er en ændring og går ind i MOC-processen, uanset hvor lille eller billig den ser ud. Skellet betyder noget, fordi det er den eneste legitime udgang af processen, og det er der, de fleste MOC-systemer lækker. Almindelige eksempler, der ikke er identiske, uanset hvad lageret kalder dem: en pumpe med en anden løbehjulsdiameter eller en anden tætningsløsning, en pakning i et erstatningsmateriale, en ventil med anden trim eller en anden fejlsikker stilling, en sikkerhedsventil sat om til et nyt tryk, et instrument med et andet måleområde eller en anden fejlreaktion, og et skift af firmware- eller softwareversion i en controller. To praktiske regler hjælper: kræv, at afgørelsen bliver registreret med navnet på den kompetente person, der traf den, og auditér afgørelserne om identisk udskiftning frem for kun ændringerne, for det er dem, der aldrig kom ind i processen, som ingen kigger på.

Hvad er en sikkerhedsgennemgang før opstart (PSSR), og hvornår kræves den?

En sikkerhedsgennemgang før opstart — PSSR, pre-startup safety review — er den sidste kontrol, før et nyt eller ændret anlæg tages i brug. Den bekræfter fire ting: at udførelsen og udstyret svarer til designspecifikationen, at drifts-, vedligeholds- og nødprocedurer findes og er tilstrækkelige, at risikogennemgangen er gennemført, og at dens anbefalinger er lukket eller implementeret, og at alle, der skal betjene eller vedligeholde ændringen, er oplært. Den amerikanske PSM-standard kræver udtrykkeligt en PSSR for nye anlæg og for ændrede anlæg, hvor ændringen var væsentlig nok til at kræve en opdatering af procesikkerhedsoplysningerne; for en dansk risikovirksomhed er porten ikke bundet til en bestemt paragraf, men følger af sikkerhedsledelsessystemets egen procedure for styring af ændringer — og skal derfor være skrevet ind hos jer, ellers findes den ikke. Grunden til, at den er tegnet som en beslutning med en løkke frem for en signaturkasse, er, at det er den port, der ligger under det største kommercielle pres: ændringen er bygget, stoppet er slut, og anlægget skal i drift. I dette diagram går en gennemgang med udestående handlinger tilbage til 'Luk PSSR-handlingerne' og tages om, så den eneste vej videre er igennem den.

Hvor længe må en midlertidig ændring blive siddende?

Kun så længe den udløbsdato, der blev aftalt, da den blev godkendt — og derfor bliver datoen sat allerede ved klassificeringen frem for overladt til senere. Mange anlæg sætter loft over midlertidige ændringer ved næste planlagte stop eller ved en fast periode som seks måneder og kræver, at alt, der overlever sit loft, bliver godkendt på ny som en permanent ændring gennem den fulde proces. Fejlmønsteret er velkendt og ensartet: en midlertidig modifikation bliver monteret under pres, presset går over, ingen ejer fjernelsen, tegningerne viser stadig den oprindelige opbygning, og år senere planlægger nogen en afspærring ud fra en tegning, der ikke længere beskriver anlægget. To ting forhindrer det. Hver midlertidig ændring har en navngiven ejer frem for en afdeling, og registret rejser gennemgangen før udløbsdatoen frem for at rapportere overskridelsen bagefter. I dette diagram har 'Stadig nødvendig ved udløbsdatoen?' præcis to grene — gør den permanent, eller fjern den og retabler den oprindelige tilstand. Stiltiende forlængelse er ikke en af mulighederne.

Hvad er forskellen på ændringsstyring (MOC) og it-ændringsstyring?

De deler et ord og næsten intet andet, og at bruge den ene som erstatning for den anden er en reel fare. It-ændringsstyring i ITIL-forstand, som er dækket af flowchartet på /da/templates/aendringsstyring-itil-proces, styrer ændringer i en driftssat service. Den spørger, om ændringen giver nedetid, om den kan rulles tilbage, hvornår ændringsvinduet er, og om CAB har godkendt den. Ændringsstyring i procesikkerhedsmæssig forstand styrer modifikationer af anlæg, kemikalier, driftsgrænser, styresystemer, procedurer og bemanding et sted, hvor det kan komme mennesker til skade. Den spørger, om ændringen ændrer en fare, om en aflastningsdimensionering eller en interlock stadig holder, om sikkerhedsrapporten stadig er gyldig, og om operatørerne er oplært før opstart. Et CAB har ingen kompetence til at svare på nogen af de spørgsmål. De to processer overlapper ét sted, der er værd at nævne: en ændring i et styresystem eller et sikkerhedsinstrumenteret system bliver ofte rejst i en it- eller automationskø og skal også gennem MOC. Hvor det sker, så gør MOC til myndigheden og it-registreringen til planlægningsartefaktet — ikke omvendt.