Root Cause Analysis

download deze column als pdf

	Ik vind deze column een aanrader
	1085 personen hebben deze column positief beoordeeld

In een onderzoek naar de geschiedenis van asset management wees zo maar iemand[1] me op het belang van het ongeval op de Piper Alpha voor de ontwikkeling van asset management. Voor wie het niet meer weet of niet heeft meegemaakt: de Piper Alpha was een boorplatform in de Noordzee, dat op 8 juli 1988 compleet verloren ging na een explosie en brand. Hierbij kwamen 167 mensen om het leven. Om de oorzaak te achterhalen stelde de Britse regering een onderzoekscommissie in. Deze kwam in 1990 met het befaamde Cullen report. Alhoewel het rapport zelf lastig te achterhalen is[2], bestaat er wel een video op Youtube[3] waarin een lid van de onderzoekscommissie in een presentatie van ongeveer 45 minuten uitlegt wat er precies misging. Middels een zeer nuchtere maar tegelijkertijd ook zeer indringende analyse wordt het verhaal verteld. Het incident wordt afgepeld van de directe oorzaak naar de reden waarom die oorzaak bestond, waarom de oorzaak gevaarlijk kon worden, waarom het gevaar zich kon ontwikkelen tot een acute noodsituatie en waarom die noodsituatie uiteindelijk uitmondde in een verschrikkelijke ramp. Met andere woorden, een werkelijk excellent voorbeeld van een Root Cause Analysis. Dat geeft tegelijkertijd ook wel een dubbel gevoel. Aan de ene kant zit je te kijken naar een stukje uitstekend vakmanschap (de analyse), maar tegelijkertijd is het wel de analyse van een ongeval waarbij vele doden vielen. Ik had de indruk dat de presentator het er zelf af en toe ook moeilijk mee had.

Om het verhaal even kort samen te vatten: het ongeval begon met gaslekkage uit een pomp waarvan de veiligheidsklep vervangen was bij routinematig onderhoud door een slechts handvast gedraaide flens. Dat vrijgekomen gas explodeerde vrijwel onmiddellijk. Na deze explosie werd de noodstop geactiveerd, wat theoretisch tot een isolatie van de fout zou moeten leiden. Alleen, door de explosie werd ook een oliepijpleiding beschadigd, waarbij een nieuwe brand ontstond. Die brand zou ook nog wel uit zichzelf zijn uitgebrand, ware het niet dat twee nabijgelegen platforms olie naar de brand bleven pompen. De hitte van het vuur zorgde er uiteindelijk voor dat 2 grote gasleidingen het begaven. De enorme hoeveelheid gas die toen vrijkwam zorgde voor een vuurzee die het gehele platform omhulde[4]. Hiermee was alles verloren.

De grote vraag, die in de presentatie ook gesteld wordt, is waarom een pomp in bedrijf genomen wordt die in onderhoud was. De reden is uiteraard dat men niet wist dat die in onderhoud was. Men wist dat er (ander) onderhoud gepland was aan dezelfde pomp, maar ook dat dat nog niet begonnen was. Toen een andere pomp in storing raakte, was de verleiding dus erg groot om de uit bedrijf genomen pomp maar snel weer in dienst te nemen, anders zou de productie gestopt moeten worden. Dat de pomp absoluut niet in bedrijf genomen mocht worden, had wel op het werkformulier gestaan, maar dat was niet expliciet overgedragen aan de wacht, omdat die bezig was. Het was alleen achtergelaten ter ondertekening. Er was geen verwijzing naar het onderhoud van de veiligheidsklep in de onderhoudsorder voor de pomp zelf, net zoals er geen verwijzing was naar het onderhoud van de pomp in de order voor de veiligheidsklep. Op de onderhoudsorder voor de pomp was te zien dat het onderhoud nog niet begonnen was, en een inbedrijfname zou dus zonder al te veel problemen moeten kunnen. Omdat het ontbreken van de veiligheidsklep niet duidelijk zichtbaar was (op enige afstand van de pomp, afgeschermd door andere objecten) werd dit ook niet duidelijk bij de werkzaamheden om de pomp weer gereed te maken.

Dit kan als een ongelukkige samenloop van omstandigheden gezien worden. Net toevallig een storing aan een pomp, terwijl 2 onderhoudswerkzaamheden tegelijkertijd aan de andere pomp uitgevoerd zouden moeten worden. Van die werkzaamheden was er één toevallig nog niet begonnen (als dit wel het geval was geweest dan had men niet geprobeerd de pomp in bedrijf te nemen) terwijl de ander toevallig niet was afgerond binnen de normale shift. Bovendien was de tijdelijke voorziening die bij die werkzaamheden was aangebracht niet duidelijk waarneembaar vanaf de pomp. Een samenloop van 4 toevalligheden dus, met een astronomisch kleine kans…. .of toch niet?

Wat de analyse kristalhelder maakt is dat het geen samenloop was, maar een ongeval dat erop wachtte om plaats te vinden. Het systeem voor het beheer van onderhoudsorders was er juist voor bedoeld om dit soort samenlopen te vermijden, maar het werd niet gebruikt zoals het bedoeld was. Dat kwam weer omdat er niet getraind werd op het juiste gebruik. Men leerde het on-the-job, waardoor fout gebruik doorgegeven werd in plaats van gecorrigeerd. De cultuur was erin geslopen dat de formulieren getekend moesten zijn (een compliance cultuur), niet dat men de volgende ploeg moest informeren over de risicotoestand van het platform.

Deze onachtzaamheid voor risico bleek veel fundamenteler dan alleen het systeem voor onderhoudsorders. Er was wel een brandschot tussen olie en gas, maar die was niet explosieveilig. Voor een olieplatform (wat het oorspronkelijk was) wel te begrijpen, maar op een gasplatform is het explosiegevaar minstens zo groot als het brandgevaar. Bij de koppeling van meerdere platforms was niet nagedacht over (of althans niet getraind op handelen bij) calamiteiten op een ander platform. Van de gasleidingen was bekend dat een breuk tot een oncontroleerbare brand zou leiden, maar er waren geen aanvullende maatregelen genomen om het risico te verminderen. De beheersmaatregel die wel bestond, een automatische sprinkler installatie, was daarentegen juist op handmatige bediening gezet om de veiligheid van duikers te waarborgen die opgezogen zouden kunnen worden door de waterpompen. Een terecht zorgpunt, maar in de balans een maatregel die meer risico veroorzaakte dan het oploste, zonder aanvullende acties. Ook was het personeel niet getraind op wat te doen in het geval van calamiteiten. Toen de ramp zich voltrok, wachtte de meesten op helikopters om hen op te halen, terwijl allang duidelijk was dat die niet meer konden landen op het platform. Maar ook tijdens de ramp werd de instructie om via het water te evacueren niet gegeven. De samenvattende conclusie was dan ook dat er een totaal gebrek aan systematische aandacht was voor de grote risico’s die verbonden waren met de oliewinning op de Noordzee.

Het rapport over het ongeval werd gepubliceerd in 1990. Het bevatte vele aanbevelingen, die in de daarop volgende jaren allen geïmplementeerd werden. Mogelijk de belangrijkste was de Safety Case, waarmee aangetoond moest worden dat de veiligheid van het te gebruiken systeem redelijker wijze gegarandeerd was. Hiervoor is een goed risicobewustzijn nodig. De Piper Alpha kan dus gezien worden als het begin van risicodenken binnen asset management. Voor 1990 vindt je nauwelijks iets over risico in de asset management literatuur, terwijl het nu algemeen erkend wordt als een van de pijlers, zoals ook blijkt uit de aandacht voor risicomanagement in de norm ISO55000.

Dat het risicodenken echt het onderscheidende van asset management is zien we elke dag in de praktijk. Veel organisaties die asset management willen invoeren kunnen het niet laten op een gegeven moment te roepen al lang aan asset management doen en dat het dus niets nieuws is. Voor wat betreft kosten/baten afweging valt daar wel wat voor te zeggen, al kan je de nodige vraagtekens plaatsen bij de waarde die aan bepaalde baten wordt toegekend. Maar in de risicoanalyse vallen deze ontkenners genadeloos door de mand. Niet voldoen aan bepaalde regels wordt met droge ogen als bron van het risico gepresenteerd: de auto is onveilig omdat die niet door de APK komt. Soms kost het de nodige overtuigingskracht, maar uiteindelijk valt kwartje wel dat oorzaak en gevolg hier toch echt andersom liggen: de auto komt niet door de APK omdat de auto onveilig is. Maar pas als deze omslag van compliance denken naar risico denken is gemaakt kan je echt beginnen met asset management.

Ype Wijnia is partner bij AssetResolutions B.V., een bedrijf dat hij samen met John de Croon heeft opgericht. Periodiek geven ze in deze column hun visie op een aspect van asset management. De columns staan gepubliceerd op de website van AssetResolutions, http://www.assetresolutions.nl/nl/column

[1] De persoon was John Woodhouse, locatie de 9th World Conference On Engineering Asset Management

[2] Er is geen digitale versie beschikbaar

[3] Brain Appleton op https://www.youtube.com/watch?v=S9h8MKG88_U ,

[4] Voor de overgang van oliebrand naar gasbrand, zie https://www.youtube.com/watch?v=pHriwdaEbms op 6.00 minuten

<< terug naar overzicht