Regelmatig lees ik over incidenten die voorkomen hadden kunnen worden als er een goed Management of Change (MOC) proces was gevolgd. Toch wordt het MOC proces nog wel eens gezien als vooral veel administratief gedoe. Terwijl het juist een essentieel fundament vormt voor een veilige operatie. Mijn ervaring is: elke wijziging telt.

Wat is MOC?

MOC staat voor Management of Change, oftewel: het beheersen van wijzigingen binnen een organisatie. Daarbij gaat het niet alleen om technische aanpassingen, maar ook om veranderingen in procedures, onderhoudsstrategieën, software, leveranciers of personeelsbezetting – bijvoorbeeld een nieuwe operator of het inschakelen van een externe contractor.

• Het verplaatsen van een afsluiter
• De implementatie van nieuwe software
• Het vervangen van materiaalsoorten
• Aanpassingen in procescondities

Als het gaat om organisatorische wijzigingen spreken we ook wel van MOOC (Management of Organisational Change). Denk hierbij aan veranderingen in structuur, rollen, processen of cultuur – zoals:

• Reorganisaties of outsourcing
• Verschuiving van verantwoordelijkheden
• Samenvoegen van teams
• Wisselingen in sleutelrollen

Ook deze veranderingen kunnen directe veiligheidsrisico’s met zich meebrengen, zoals kennisverlies, onduidelijkheid over verantwoordelijkheden of gebrekkige overdracht.

Wat kan er misgaan zonder MOC proces?

Zes grote industriële rampen – van Flixborough (1974) tot Deepwater Horizon (2010) – laten zien hoe risicovol het is om wijzigingen niet goed te managen. In alle gevallen werden veranderingen doorgevoerd, zonder formele risicoanalyse of betrokkenheid van de juiste experts.

Bij Flixborough werd een tijdelijke bypass-leiding geplaatst zonder technische beoordeling. Toen die faalde, vielen er 28 doden. In Texas City paste men bij het opstarten van een unit een alternatieve procedure toe die niet was geëvalueerd, met een explosie als gevolg. Bij Phillips 66 Pasadena ontstond een gaswolk tijdens onderhoud, doordat wijzigingen in het leidingsysteem niet goed waren gecommuniceerd enbeheerst.

Chevron Richmond koos ervoor om een sterk gecorrodeerde leiding niet te vervangen – een ogenschijnlijk passief besluit, maar wél een afwijking van normaal onderhoudsbeleid die het risicoprofiel veranderde. En bij Deepwater Horizon werden onder tijdsdruk technische keuzes gemaakt zonder MOC-proces, wat leidde tot een blowout en uiteindelijk elf doden.

Bij Esso Longford Gas Plant in Australië, vielen in 1998 twee doden en acht gewonden,  waarbij het ontbreken van een MOOC proces een rol speelde. Organisatorische factoren zoals onvoldoende training, onervaren personeel en het wegvallen van technisch leiderschap droegen bij aan het incident.

In al deze gevallen werd er afgeweken van ‘normaal’ – procedureel, technisch of organisatorisch – zonder formele risicobeoordeling.

Wat is het doel van een MOC proces?

De kern van het MOC-proces is om bij elke wijziging – groot of klein – vooraf de risico’s in kaart te brengen en te beoordelen of deze voldoende zijn afgedekt. In mijn ervaring worden grote wijzigingen meestal wel goed gemanaged in een MOC proces. De valkuil zit vaak in de kleinere aanpassingen. Juist die worden nogal eens niet of onvoldoende beoordeeld, met onverwachte en soms verstrekkende gevolgen.

Waarom een MOC proces toepassen?

Voor veel industriële organisaties is een MOC proces wettelijk verplicht. Maar ook als dat niet zo is, blijft het een waardevol instrument. Zonder MOC proces leidt een wijziging al snel tot verhoogde veiligheidsrisico’s, onverwachte kosten, vertragingen of operationele verstoringen.

Door een MOC proces toe te passen:

• Voorkom je mogelijk levensbedreigende risico’s
• Maak je de risico’s van de door jou geplande wijziging inzichtelijk en kun je van tevoren de mitigerende maatregelen bedenken, budgetteren en tijdig implementeren of besluiten de wijziging toch maar niet door te voeren
• Voorkom je onnodige kosten, vertragingen en rework
• Borg je interne en externe compliance
• Bevorder je risicobewustzijn in de organisatie. Het MOC proces verplicht medewerkers om bewust stil te staan bij de consequenties van hun keuzes.
• Documenteer je wat er is gewijzigd en waarom
• Faciliteer je het leren van fouten. Door goede documentatie en terugkoppeling kun je toekomstige wijzigingen beter aanpakken.

Hoe ziet een goed MOC-proces eruit?

In de praktijk zie ik veel variatie, maar succesvolle organisaties hebben een aantal elementen gemeen. Hieronder mijn persoonlijke best practices:

• MOC is verankerd aan het begin van elk project.
  Zonder goedgekeurde MOC – inclusief handtekeningen van alle relevante disciplines – kan een wijziging niet worden doorgevoerd.
• Er is een duidelijke procesbeschrijving, zodat voor iedereen helder is wanneer en hoe een wijziging moet worden aangemeld, beoordeeld en goedgekeurd.
• Er is een multidisciplinaire MOC-commissie die (twee)wekelijks bijeenkomt. Hierin zitten o.a. experts op het gebied van procesveiligheid en HSE, een process engineer, een onderhoud/reliability engineer en een productievertegenwoordiger.
• De projectleider meldt wijzigingen vooraf aan, inclusief een ingevulde risico-checklist. Per risico wordt aangegeven of het relevant is en – indien van toepassing – hoe het wordt beheerst.
• In de vergadering licht de projectleider de wijziging mondeling toe. De commissie stelt vragen en beoordeelt of de risico’s voldoende onder controle zijn. Zijn er nog onduidelijkheden, dan wordt de projectleider gevraagd dit verder uit te zoeken en terug te komen met aanvullende informatie.
• Pas na goedkeuring – inclusief ondertekening door alle disciplines – mag de wijziging worden uitgevoerd. Eventuele openstaande punten moeten voor in gebruikname zijn geïmplementeerd.
• Alle disciplines die zitting hebben in de MOC-commissie worden voor ingebruikname gevraagd na te gaan of de wijziging volgens afspraak is uitgevoerd en of de beoogde risico’s zijn gemitigeerd. Zij tekenen vervolgens voor goedkeuring van de wijziging na implementatie.
• Een wijziging wordt na een jaar geëvalueerd. Wat ging goed, en wat kan beter, zowel inhoudelijk als m.b.t. het gevolgde proces.
• Het MOC proces wordt ondersteund met de juiste software, hetgeen consistentie en traceerbaarheid verhoogt.

Wat kun je leren van de praktijk?

De lessen die ik geleerd heb zijn de volgende:

• Pas een MOC proces toe op het juiste moment in een project. Als dit te vroeg wordt gedaan en nog helemaal niet duidelijk is of het project doorgaat is de MOC weinig efficiënt (de kans is groot dat je relatief veel tijd besteed aan projecten die niet doorgaan). Als je de MOC te laat uitvoert, is er meestal heel weinig ruimte voor aanpassingen en is de MOC weinig effectief.
• Richt een light proces in voor kleine wijzigingen, je voorkomt daarmee dat je met een kanon op een mug schiet, maar zorgt er wel voor dat een wijziging door de juiste experts beoordeeld wordt.
• Behandel juist ook tijdelijke wijzigingen in het MOC proces
• Gebruik lessons learned actief. Voeg een stap toe waarin bij een nieuwe wijziging eerst wordt gekeken naar eerdere vergelijkbare wijzigingen en bijbehorende evaluaties.

Hoe werkt het MOC proces bij jullie?

Hoe wordt het MOC proces binnen jullie organisatie toegepast? Wat werkt goed, en waar zit ruimte voor verbetering?