Acht veelvoorkomende misvattingen over het managen van verandering

Telkens wanneer ik verandermanagement voor fabriekspersoneel vermeld, krijg ik over het algemeen een van de verschillende voorspelbare reacties. Degenen met kennis van zaken zullen de verordening OSHA 1910.119(a)(2) aanhalen en me vertellen dat ze geen "gedekt proces" zijn, dus het is niet op hen van toepassing - over het algemeen met een grote zucht van verlichting. Een andere veelgehoorde reactie is:“We hebben een procedure voor het beheer van tekeningen, maar we lopen zo ver achter dat het jaren zou duren en middelen die we niet hoeven in te halen.” Anderen zullen me nog steeds vertellen dat ze een prima procedure hebben voor hun managers om kleine projecten en wijzigingen goed te keuren. En sommigen zullen schaapachtig denken aan de centen en stuivers die de asbak van hun auto vullen.

Dus, wat is management of change (MOC)? Terugkerend naar de bron, OSHA 1910.119(l)(1) stelt de vereisten voor MOC als volgt:"De werkgever zal schriftelijke procedures opstellen en implementeren om wijzigingen te beheren (behalve voor "vervangingen in natura") om chemicaliën, technologie, apparatuur en procedures; en wijzigingen aan faciliteiten die een gedekt proces beïnvloeden.

Die korte beschrijving bestrijkt veel territorium, maar aangezien het uitsluitend werd uitgevaardigd om de procesveiligheid te verbeteren, beperkt het de juridische toepasbaarheid tot "gedekte processen". Lezers wiens faciliteiten voldoen aan de OSHA-vereisten van een "gedekt proces" zijn zich terdege bewust van de gedetailleerde vereisten van MOC. Dat moet wel, anders zouden ze nog steeds niet actief zijn. En hopelijk weten jullie allemaal dat veel van de ergste industriële ongevallen in de recente geschiedenis de oorzaak zijn van het mislukken van het MOC-proces. Sommige bronnen geven aan dat maar liefst 80 procent van de ernstige zware ongevallen in de industrie verband houdt met ongecontroleerde verandering. Men kan MOC dus zien als een soort levensverzekering die loont door ongevallen te voorkomen.

Maar dit artikel is niet gericht op de fijne kneepjes van MOC voor gedekte processen. En het is niet alleen gericht op veiligheid. Waarom hebben we het dan over MOC als het niet "verplicht" is voor uw branche? Kortom, het is omdat elk bedrijf, ongeacht de wettelijke vereisten, potentiële verliezen moet beheersen. En MOC, op de juiste manier toegepast, is een uitstekend, kosteneffectief verliespreventieproces voor bijna elk bedrijf. Het is de perfecte aanvulling op uw verlieseliminatieprocessen. En we willen ook allemaal veilig en milieuvriendelijk zijn, toch?

Houd er rekening mee dat MOC alleen wijzigingen aanbrengt in bestaande zaken. Het ontwerpen van nieuwe processen of faciliteiten is een heel ander vraagstuk. En we moeten er voor de MOC-discussie van uitgaan dat het prestatieniveau van het bestaande systeem, zo niet adequaat, in ieder geval bekende en bekende deugden en ondeugden heeft.

Dus, wat is MOC in niet-regulerende termen en voor wie is het echt van toepassing? Laten we met deze eenvoudige definitie werken:MOC is een proces voor het voorkomen of verminderen van bedrijfsverliezen - inclusief verslechtering van veiligheid, gezondheid of milieu - als gevolg van wijzigingen die zijn aangebracht in de manier waarop u uw faciliteit of uw processen bouwt, exploiteert, beheert of repareert. Afgezien van de wettelijke vereisten, is er geen bedrijf dat van plan is concurrerend te blijven en het zich kan veroorloven om geen geschikt MOC-proces te hebben. Kortom, MOC is logisch voor de veiligheid en het is financieel zinvol. Is een MOC-proces zinvol voor uw bedrijf?

Wat is een 'verandering'?
“Het moeilijkste onderdeel van veranderingsmanagement is het herkennen van verandering.” Het belangrijkste uitgangspunt van het programma is om voor de organisatie duidelijk te definiëren wat een 'verandering' is die u wilt managen. Of eenvoudiger:welke verandering valt onder het MOC-proces en welke niet? Een gebrek aan duidelijke definitie verlamt de effectiviteit van een MOC-programma, wat zowel onnodige analyseverlamming uitlokt als mazen creëert voor degenen die het proces willen omzeilen.

Er zijn veel definities van verandering uit veel verschillende bronnen. Het is de verantwoordelijkheid van de locatieleiding om verandering te definiëren in termen die in overeenstemming zijn met de zakelijke belangen en eventuele precedenten op het gebied van regelgeving. Welke risico's wilt u beheersen en welke soorten veranderingen, indien niet beheerst, vergroten die risico's? Alleen dan kunnen die activiteiten die redelijkerwijs als "veranderingen" kunnen worden gedefinieerd, duidelijk worden geïdentificeerd, en als ze eenmaal zijn geïdentificeerd, moeten ze worden overgebracht in de meest eenvoudige en duidelijke taal die mogelijk is.
Hoewel een beetje rommelig, is het gebruik van lijsten of tabellen met voorbeelden is vaak nodig om de punten over te brengen. Houd er rekening mee dat een "verandering" niet in een stuk hardware hoeft te gebeuren om in aanmerking te komen. Software, procedures en procesparameters zijn allemaal voorbeelden van niet-hardwarewijzigingen die vaak rigoureus moeten worden gecontroleerd.

Wanneer het om hardware gaat, verwijst het OSHA 1910-brondocument schuin naar een wijziging als geen "Replacement in Kind" (RIK) en definieert RIK verder als "een vervanging die voldoet aan de ontwerpspecificaties". RIK verwijst in het algemeen naar apparatuur of componenten die identiek zijn in vorm, pasvorm en functie (aangeduid als de F3). Maar er is meer te veranderen dan deze zeer beperkte op hardware gebaseerde benadering. De OSHA-definitie van verandering verwijst ook naar technologie, procedures en chemicaliën (ruimer geïnterpreteerd als grondstoffen). Het is duidelijk dat meer dan alleen hardware wordt omvat in de definitie van "verandering". Ik heb ontdekt dat de beste formele definitie die wordt gebruikt voor "verandering" in het MOC-proces wordt gevonden in een verduidelijking gepubliceerd in OSHA 3313:"Verandering is een wijziging of aanpassing aan een component, variabele of eigenschap binnen een bestaand systeem (behalve die binnen duidelijk gedefinieerde grenzen of verantwoordelijkheden).”

Aangezien elk bedrijf verschillende risicogebieden heeft en verschillende toleranties voor ongewenste gevolgen, is het aan elk bedrijf om risico's te beoordelen en zijn tolerantie voor ongecontroleerde veranderingen te definiëren. Een paar (maar zeker niet allesomvattende) voorbeelden van het soort veranderingen dat een bedrijf wil doorvoeren zijn:

• Toevoeging van nieuwe procesapparatuur of kritisch bedrijfssysteem (inclusief software)
• “Niet in natura” vervanging van procesapparatuur of onderdelen
• Aanpassingen of kleine toevoegingen aan procesapparatuur
• Aanpassingen of kleine toevoegingen aan kritieke bedrijfssystemen (procedureel of software)
• Aanpassingen of kleine toevoegingen aan infrastructuur/niet-procesapparatuur
• Wijzigingen in procesbesturing en/of instrumentatie (inclusief besturingsstrategieën)
• Wijzigingen in specificaties of sourcing van technische MRO
• Veranderingen in de bedrijfslimieten van kritieke procesparameters (buiten de bereiken gespecificeerd in standaard bedrijfsprocedures [SOP's])
• Wijzigingen aan veiligheidssystemen (vergrendelingen, uitschakelingen, brand- of explosieonderdrukking, enz.)
• Revisies van standaard operationele procedures (inclusief noodprocedures)
• Veranderingen in de organisatiestructuur op siteniveau
• Wijzigingen in onderhoudsprocedures
• Wijzigingen in specificaties van grondstoffen/componenten of sourcing
• Wijzigingen of nieuwe aansluitingen op nutsvoorzieningen (lucht, elektriciteit, gas, water, stoom, etc.).
• Wijzigingen of nieuwe verbindingen met kritieke datanetwerken
• Wijzigingen in QA-procedures of kritische testapparatuur

Een paar uur hoogwaardige 'wat als'-brainstorming door een multidisciplinair team vroeg in het procesontwerp om de definities en voorbeelden te ontwikkelen die geschikt zijn voor uw bedrijf, zal enorme voordelen opleveren.

Hoe zit het met 'tijdelijke' wijzigingen?
Onthoud dit belangrijke concept om toe te passen bij het implementeren van MOC:Net zoals er niets ter wereld zo permanent is als een tijdelijke belasting, is er geen blijvendere verandering dan een "tijdelijke verandering" die aan het MOC-proces ontsnapte. De ervaring leert dat er eigenlijk alleen blijvende veranderingen zijn die van tijdelijke aard zijn totdat ze in oorspronkelijke staat zijn hersteld. Van alle ongecontroleerde veranderingen die optreden, zijn “tijdelijke” veranderingen de meest schadelijke en de meest voorkomende oorzaak van ongevallen en incidenten. Daarom mogen "tijdelijke" wijzigingen van een gecontroleerd systeem nooit worden uitgesloten van het MOC-proces.

Dus, wat moet ik doen om tijdelijke wijzigingen aan te pakken die moeten worden aangebracht om routinematige zaken uit te voeren, zoals een interlock-bypass om periodiek onderhoud uit te voeren? Als het echt routine is, dan heb je een permanente toestand van een periodieke afwijking van de SOP. En de juiste manier om daarmee om te gaan, is door de situatie als een permanente verandering te beschouwen en deze op te nemen in goedgekeurde procedures met passende waarborgen. Als iets bedoeld is als een niet-routinematige tijdelijke verandering, behandel het dan als een verandering. OSHA 3133 zegt in een verduidelijking:"MOC-procedure moet ervoor zorgen dat apparatuur en procedures aan het einde van een tijdelijke wijziging in hun oorspronkelijke staat worden teruggebracht." Geschiedenis en voorzichtigheid suggereren dat "tijdelijke" wijzigingen als "permanent" moeten worden beheerd, met speciale aandacht voor de MOC-procedure, omdat ze het grootste risico voor uw bedrijf vormen.

Acht veelvoorkomende misvattingen over MOC
1) “Maar ik breng geen echte wijziging aan. Ik maak het gewoon een beetje beter."
Als u het onderdeel/apparatuur/bedrijfssysteem niet precies zo achterlaat als voor aanvang van de werkzaamheden (uiteraard geen schade die het voorwerp uitmaakte van de reparatie), dan heeft u een wijziging aangebracht . Of de wijziging al dan niet onder de reikwijdte van uw MOC-proces valt, wordt bepaald door de criteria die in uw procedures zijn vastgelegd. De standaardbenadering die moet worden gevolgd, is aan te nemen dat elke wijziging in configuratie, vorm, pasvorm, functie, materialen of procedure onder MOC valt totdat een onderzoek van de criteria in de procedure het tegendeel uitwijst.

Naast ongecontroleerde "tijdelijke wijzigingen", zijn goedbedoelde kleine verbeteringen de op één na grootste oorzaak van incidenten die vallen onder de categorie mislukking-van-MOC. Zonder een grondige evaluatie van de totale operationele context en omgeving, wie zal zeggen dat "beter" op de ene manier niet echt veel, veel slechter is op een andere manier? Hetzelfde medicijn dat aan één patiënt wordt gegeven, kan een krachtige remedie zijn; voor een ander kan het een dodelijk gif zijn. Hetzelfde geldt voor goedbedoelde maar ongecontroleerde kleine "verbeteringen", met name materiaalvervangingen die bijzonder riskant zijn. Leer uw personeel op alle niveaus deze veelvoorkomende valkuil kennen, vermijden en streng handhaven. Niemand houdt ervan om mensen te straffen voor het overtreden van de regels, vooral niet als ze het doen in de geest van verbetering. Maar het is oneindig veel erger om een ​​familie te moeten vertellen dat iemand vanavond niet naar huis zal komen.

2) “Ik loop zo ver achter dat ik geen MOC kan beginnen. Ik zal al die niet-gereviseerde tekeningen nooit meer inhalen."
Documentbeheer is een proces dat een aanvulling vormt op een goed ontworpen MOC-proces en is vaak het eerste waar mensen aan denken als u het over MOC heeft. De noodzaak om documenten bij te werken is zeker een veelvoorkomend resultaat van een MOC en noodzakelijk voor de integriteit van uw processen en faciliteiten op de lange termijn, maar het is geen MOC. Het is slechts een veelvoorkomende uitkomst.

Vaak erft u bij het implementeren van MOC met een documentbeheerproces nogal wat rommel van degenen die u voorgingen:geen tekeningen, onnauwkeurige tekeningen, verouderde documenten.. . noem maar op. Als de situatie nijpend is, wordt u mogelijk gedwongen om prioriteit te geven aan uw corrigerende acties - als die zijn gebaseerd op het kritieke karakter van de systemen. Sommige zijn misschien niet nodig en zullen nooit worden gecorrigeerd. Zeker, een methode om vitale informatie te corrigeren wanneer deze wordt ontdekt, kan en moet gemakkelijk worden opgenomen in uw werkcontroleprocedures. Maar voeg de taak niet toe door slechte gewoonten voort te zetten.

Je kunt niet veranderen wat er in het verleden is gebeurd. Als de businesscase bestaat om fouten uit het verleden te corrigeren of te verminderen, doe dat dan. MOC gaat over toekomstige schadepreventie. Dus het enige dat elke organisatie kan doen, is nu beginnen met het implementeren van MOC. Vandaag is de dag om te stoppen met het creëren van nog meer problemen voor morgen. Een beknopt stukje volkswijsheid zegt:"Als je een echt groot gat moet opvullen, moet je eerst stoppen het dieper te graven." Hetzelfde geldt voor een kloof die is ontstaan ​​door een slechte MOC. Stop met het groter maken.

3) “Ik heb geen tijd om te wachten op de MOC-evaluatie. Dit is een noodgeval!”
Juist tijdens een calamiteit is de zelfdiscipline die wordt opgelegd door een beproefd MOC-proces het meest noodzakelijk. Wanneer een vliegtuig tijdens de vlucht een probleem heeft, doen de piloten niet het eerste dat in je opkomt. Liever halen ze de checklist tevoorschijn en denken ze, dan handelen ze. Als er een "noodgeval" is, zou u dat ook moeten doen. Zal deze "kleine wijziging" om een ​​vervanging toe te staan ​​echt zoveel downtime besparen in vergelijking met het krijgen van het juiste onderdeel? Kleine wijzigingen nemen vaak veel meer tijd in beslag dan verwacht.

Wees realistisch in uw inschatting van hoe lang, hoeveel geld en hoeveel risico deze "snelle omweg" werkelijk in beslag zal nemen. Het is goed om optimistisch te zijn in een noodsituatie. Het is het beste om op het ergste voorbereid te zijn. Zoals het gezegde luidt:"Als je in een lekkende boot ver op zee zit, kun je het beste naar de hemel bidden, maar naar de kust roeien." Is het risico voor uw bedrijf verbonden aan een “tijdelijke” bypass de besparingen op tijd waard? Kun je het risico echt tot een acceptabel niveau beheersen door middel van "speciale werkprocedures"?

Uit ongevallenrapporten blijkt dat overhaaste beslissingen, genomen onder druk, zonder een evenwichtige evaluatie, de oorzaak zijn geweest van veel ernstige problemen . Tijd om gedisciplineerd na te denken is geen verloren tijd. En als uw MOC-proces efficiënt is, zal het de voortgang niet onnodig belemmeren in het zeldzame geval dat het een echte noodsituatie is. Net zoals er een procedure is om een ​​noodwerkopdracht goed te keuren en af ​​te geven wanneer dat nodig is, zal een goede MOC-procedure een mechanisme hebben om echte noodsituaties aan te pakken. Maar dat mechanisme zou niet moeten zijn om de MOC te negeren. Sta geen opportuniteit toe tijdens een "noodgeval" om u klaar te stomen voor een grotere en ernstiger tweede noodsituatie. Maak een bom niet onschadelijk om alleen maar een landmijn te planten.

Heeft u regelmatig storingen waarvoor een tijdelijke oplossing nodig is, moet u constant middernacht onderdelen vervangen om te herstellen van een onverwachte storing, of constant procesaanpassingen om instabiele componenten of grondstoffen op te vangen? Dan is je uitdaging niet om MOC te negeren of om een ​​MOC-proces te ontwerpen dat anarchie ondersteunt. In plaats daarvan moet u uw inspanningen richten op het elimineren van deze situaties door het implementeren van een effectief proces voor analyse van de oorzaak van storingen (RCFA) en programma's voor preventief onderhoud/voorspellend onderhoud om de chronische storingen te elimineren. Richt u vervolgens op het corrigeren van de tekortkomingen in uw MRO-processen om ervoor te zorgen dat u altijd over de juiste onderdelen beschikt. En ten slotte moet u uw proces stabiliseren met standaard werkprocedures en kwalificatieprogramma's voor materiaalleveranciers.

4) "Het doorsturen van dit formulier voor goedkeuring duurt zo lang dat we nooit iets voor elkaar kunnen krijgen."
Een effectief MOC-proces vereist een passend niveau van goedkeuring en communicatie. Slecht ontworpen MOC-goedkeuringsprocedures verwarren de noodzaak om op de hoogte te worden gesteld van een wijziging nadat deze plaatsvindt, met de noodzaak om een ​​wijziging goed te keuren voordat deze plaatsvindt. De vereiste goedkeuringsniveaus moeten zowel geschikt zijn voor de wijziging als voor het potentiële risico dat ermee gepaard gaat. Ze moeten ook flexibel genoeg zijn om op de situatie toegesneden te kunnen worden. Minimaliseer het aantal goedkeurders en zorg dat ze de juiste zijn. Uw MOC-proces kan dan veilig worden gestroomlijnd.

5) "Maar mijn gebiedsmanager moet al fondsen goedkeuren voor wijzigingen."
Verwar de autoriteit om een ​​beslissing te nemen niet met het bezit van de kennis die nodig is om die beslissing te nemen. Niet alle veranderingen, en vaak de meest kritische, gaan zelfs door de goedkeuring van de financiering. Vaak zijn de personen die het meest competent zijn om het risico van een wijziging of de technische validiteit van een wijziging in te schatten, niet de area manager, maar de operators, monteurs, supervisors of ingenieurs die er het meest vertrouwd mee zijn.

Zelfs als de manager is zeer competent, het komt zelden voor dat één persoon competent is in alle aspecten of gevolgen van een bepaalde verandering. In een effectief MOC-proces is het de verantwoordelijkheid van de manager om ervoor te zorgen dat de juiste aangewezen middelen worden betrokken bij een evenwichtige evaluatie van de voorgestelde wijziging. Goedkeuringsbevoegdheid is ondergeschikt aan competentie om te evalueren en een goed uitgebalanceerd team zal consistenter goede resultaten geven dan afhankelijk te zijn van één slim persoon.

6) “We zijn een magazijn / lichte productie / data centrum / reparatie faciliteit. … We hebben niets dat gevaarlijk kan zijn.”
Onthoud dat MOC een proces is voor het voorkomen of beperken van alle potentiële, door uzelf veroorzaakte zakelijke verliezen die verband houden met een verandering. Er zijn andere verliezen dan alleen procesveiligheid. Het is een verlies als u door een ongecontroleerde procesverandering een gewaardeerde klant verliest vanwege een besmet of defect product. Het is een verlies als uw datacenter uitvalt en het oplossen van problemen enkele uren in plaats van minuten duurt, omdat elektrische tekeningen de veranderingen niet hebben bijgehouden. Het is een verlies als de automatische stapelaar defect is en u het product niet kunt verzenden, omdat een vervanging van een onderdeel om middernacht een "kleine wijziging" vereist, waardoor het enige vervangende onderdeel dat u op voorraad heeft niet meer past. Het is een verlies als een ongedocumenteerde wijziging aan de besturingssoftware ervoor zorgt dat uw automatische testmachine uitvalt wanneer de nieuwste beveiligingspatch is geïnstalleerd. Dit zijn allemaal echte voorbeelden en de lijst is eindeloos. Hoewel het potentieel voor veranderingen om gevaarlijke situaties in uw omgeving te creëren klein is, hebben we allemaal iets te verliezen wanneer onze faciliteit of processen falen in hun primaire missies.

7) “Maar MOC won vat niet elk mogelijk probleem op, dus waarom zou je het doen?”
Je hebt helemaal gelijk. Ondanks je beste inspanningen, zullen sommige problemen onopgemerkt aan je voorbij glippen. Maar hoeveel zullen er voorbij glippen als je geen MOC doet? Bij risicobeheer draait alles om het veranderen van de kansen om meer in uw voordeel te zijn. Dit argument gaat niet op - niet meer dan het argument dat sommige mensen gebruiken tegen airbags:"Ze kunnen worden geactiveerd en een ongeluk veroorzaken, dus ik zet ze uit." De statistieken ondersteunen die gedachtegang net zomin als het ontbreken van MOC.

Dus, wat als je een onbedoeld gevolg mist? Een waardevol bijkomend voordeel van MOC in complexe systemen is het uitvoeren van een RCFA. Als er nadelige gevolgen zijn van een wijziging en de oorzaak is niet direct waarneembaar, gaat de RCFA veel sneller als u een lijst heeft van alle opzettelijke wijzigingen die zijn aangebracht. En die tijd kan echt geld zijn. In één geval verminderde het onderzoeken van MOC-records weken van de tijd die nodig is om de oorzaak van een reeks storingen in procesinstallaties te vinden. Met $ 250.000 per dag aan vermeden verlies van uitvaltijd, had de MOC-inspanning een behoorlijk goed rendement op de investering, hoewel het probleem niet werd voorkomen.

8) “Dit is slechts een wijziging in de software/procedure. Het is niet alsof we een pijp aan het verwisselen waren of zo. We hoeven niet goed te keuren of te documenteren."
In een aantal bedrijfstakken hebben zich enkele zeer ernstige incidenten en ernstige verliezen voorgedaan als gevolg van software- of procedurewijzigingen die niet onderhevig waren aan MOC. Bovendien, alleen omdat een document of code is gewijzigd en de wijziging weerspiegelt, betekent niet dat de wijziging is gedocumenteerd. Ik weet dat opmerkingen in de code en revisievlaggen in het document de zoeker in staat stellen om naar wijzigingen te zoeken. Maar als er onverwachte problemen optreden omdat de software- of procedurewijziging niet adequaat is beoordeeld, wat heeft het dan voor zin?

Heeft u een productielijn gehad terwijl u wanhopig zocht door duizenden regels code op zoek naar de wijziging die de regeltechnicus twee maanden voor zijn vertrek naar een andere baan maakte? Vooral programmeurs en regeltechnici hebben de neiging om met software te "spelen" zonder rekening te houden met MOC. Dit geldt niet alleen voor uw procesbeheersing, maar ook voor uw kritische bedrijfssysteemsoftware. Als het potentiële risico bestaat en dit rechtvaardigt, behandel het wijzigen van een coderegel dan niet anders dan het opnieuw bedraden van een veiligheidsuitschakelsysteem; het zou hetzelfde niveau van controle en controle moeten krijgen.

Conclusie
Kortom, een goed ontworpen MOC-proces is een essentieel hulpmiddel voor het voorkomen van verlies voor elk bedrijf. Het is niet alleen voor bepaalde gevaarlijke industrieën. Het proces is van toepassing op elk bedrijf dat toekomstige verliezen als gevolg van de veranderingen van vandaag wil vermijden. MOC hoeft niet overweldigend of zo moeilijk te gebruiken te zijn dat het verandering remt. Het kan niet moeiteloos omissies uit het verleden compenseren, alleen uw toekomstige risico verminderen. Het is dus vandaag de dag om te beginnen met het ontwikkelen en implementeren van een effectief en efficiënt MOC-proces.

Dit artikel verscheen voor het eerst in de juli-editie van de nieuwsbrief van Life Cycle Engineering, RxToday.

Over de auteur:
Sam McNair is senior consultant bij Life Cycle Engineering (LCE). Als professionele ingenieur en gecertificeerde onderhouds- en betrouwbaarheidsprofessional, heeft Sam meer dan 32 jaar ervaring in discrete productie, chemische procesindustrieën, mijnbouw, machineprocessen, automatisering, luchtvaart, constructie en nutsbedrijven. Sam is gespecialiseerd in betrouwbaarheidsengineering met een focus op de integratie van onderhouds- en productiefuncties. Je kunt Sam bereiken via [email protected]. Ga voor meer informatie over Life Cycle Engineering naar www.LCE.com.