← Systeem & patronen
Systeem & patronen · Kaart 26 van 38

Het systeemongeval

Soms is er geen schuldige. Soms produceert het systeem zelf de ramp, omdat het te complex verweven en te strak gekoppeld is om nog te overzien.

De reflex: na een ramp zoeken we de schuldige die het liet gebeuren. · De systeemblik: in complexe, vast gekoppelde systemen is het ongeval een eigenschap van de architectuur, niet van één mens.

Herken je dit?

In een verdeelstation gaat op een warme middag een storing spelen die niemand meteen begrijpt. Een beveiliging heeft ingegrepen, maar het beeld op het scherm klopt niet met wat de operator verwacht. Ondertussen loopt er onderhoud aan een ander veld, staat een meetsignaal op storing waardoor de operator één indicatie mist, en is de collega die de installatie het beste kent net op pauze. Elk van die dingen is op zich niets — onderhoud gebeurt dagelijks, een meetsignaal valt wel vaker uit, pauzes horen erbij. Maar samen vormen ze een situatie die niemand zo had voorzien, en waarin de operator een beslissing moet nemen op basis van een beeld dat maar half klopt.

Achteraf, in het onderzoek, is de verleiding groot om te wijzen: de operator had het kunnen zien, het onderhoud had niet gepland mogen worden, het meetsignaal had gemaakt moeten zijn. Elk voor zich waar. Maar de eerlijke conclusie is ongemakkelijker: geen van die dingen was op zichzelf een fout die tot een ongeval leidt. Het was de manier waarop ze op dat ene moment op elkaar inwerkten. Dat is de kernspanning van deze kaart: soms is er geen schuldige die het liet gebeuren, maar produceert de architectuur van het systeem zelf de ramp — omdat het te complex verweven en te strak gekoppeld is om nog te overzien.

Als de architectuur zelf het ongeval maakt

Het idee van het systeemongeval — Perrow noemde het een normal accident — draait om twee eigenschappen die samen giftig zijn. De eerste is interactieve complexiteit: onderdelen kunnen op onverwachte, onzichtbare manieren op elkaar inwerken, zodat een gebeurtenis in de ene hoek iets doet in een andere hoek waar niemand de verbinding zag. De tweede is vaste koppeling: als die onverwachte interactie eenmaal begint, plant hij zich snel en zonder speling voort. Bij elkaar zorgen ze ervoor dat kleine, op zich onschuldige afwijkingen zich combineren tot een situatie die niemand kan begrijpen op het moment dat het telt.

Het woord “normal” is bewust gekozen en bewust ongemakkelijk. Perrow bedoelt niet dat zulke ongevallen vaak gebeuren, maar dat ze een normale, te verwachten eigenschap zijn van een bepaald soort systeem. Niet een afwijking die je met genoeg discipline kunt uitbannen, maar een ingebouwde mogelijkheid die volgt uit hoe het systeem in elkaar zit. Zolang je een systeem bouwt dat tegelijk complex verweven en strak gekoppeld is, bouw je de kans op zo’n ongeval mee in. Je kunt hem verkleinen, maar niet wegdefiniëren door harder te zoeken naar de schuldige.

Het klassieke voorbeeld is de kernongeval bij Three Mile Island in 1979, de casus waarop Perrow zijn theorie bouwde. Daar viel geen enkel groot ding uit. Een klep die dichtgemeld werd maar openstond, een indicator die het verkeerde suggereerde, operators die volkomen logisch handelden op basis van wat ze zagen — en die reeks kleine, op zich beheersbare dingen werkte zo op elkaar in dat de bemanning de situatie urenlang verkeerd begreep. Niet omdat ze incompetent waren, maar omdat het systeem hun een beeld gaf dat klopte met een andere werkelijkheid dan de echte. De ramp zat niet in één fout; hij zat in de interactie.

Voor de energiesector is dat geen ver-van-je-bed-verhaal. Een modern elektriciteitsnet is bij uitstek een interactief complex, steeds strakker gekoppeld systeem: duizenden componenten, geautomatiseerde beveiligingen die op elkaar reageren, marktprocessen die vermogen verschuiven, en een groeiend aantal decentrale bronnen die het gedrag minder voorspelbaar maken. De grote cascade-storingen — waarin het uitvallen van één verbinding via beveiligingen en overbelasting binnen minuten hele regio’s meesleept — zijn schoolvoorbeelden van systeemongevallen. Geen enkele operator wilde het, geen enkele component was de boosdoener; het was het geheel dat kantelde.

De psychologie erachter

Als er geen schuldige is, waarom zoeken we er dan toch altijd een? En hoe kan het dat vakbekwame mensen een situatie collectief verkeerd begrijpen? De inzichten hieronder verklaren waarom het systeemongeval zo moeilijk te zien én zo moeilijk te aanvaarden is.

DE PSYCHOLOGIE
Het normale ongeval. Charles Perrow bouwde in Normal Accidents (1984) zijn theorie op de analyse van Three Mile Island. Zijn kernstelling: wanneer een systeem tegelijk interactief complex en vast gekoppeld is, zijn ernstige ongevallen onvermijdelijk een normale systeemeigenschap. De onvoorziene interacties tussen op zich kleine fouten stapelen zich sneller op dan iemand ze kan begrijpen, en de vaste koppeling laat geen tijd om te herstellen. De consequentie is verstrekkend: voor sommige systemen kun je de veiligheid niet garanderen door beter je best te doen, omdat de kwetsbaarheid in het ontwerp zelf zit.

DE PSYCHOLOGIE
Latente condities. James Reason liet in Human Error (1990) en Managing the Risks of Organizational Accidents (1997) zien dat grote ongevallen zelden ontstaan uit één actieve fout. Ze ontstaan doordat latente condities — verborgen zwakheden in ontwerp, planning, onderhoud en organisatie — jarenlang sluimeren en op een kwaad moment samenvallen met een lokale trigger. Zijn beeld van de opeengestapelde kaaslagen met gaten die toevallig op één lijn komen te staan, maakt hetzelfde punt als Perrow: de oorzaak is verdeeld over het systeem en de tijd, niet geconcentreerd in de persoon die er op het laatste moment bij stond.

DE PSYCHOLOGIE
Normalisatie van afwijking. Diane Vaughan toonde in The Challenger Launch Decision (1996) hoe de ramp met de spaceshuttle niet ontstond uit onwil, maar uit een cultuur waarin kleine afwijkingen stap voor stap normaal werden. Signalen die achteraf alarmerend lijken, werden binnen de context van dat moment redelijk uitgelegd — elke afzonderlijke beslissing was verdedigbaar. Vaughans begrip “normalization of deviance” verklaart waarom de bouwstenen van een systeemongeval van binnenuit niet als gevaarlijk voelen: de mensen erin doen wat in hun wereld logisch en toegestaan is.

Wat je er wel mee kunt

De boodschap van het systeemongeval is niet dat je machteloos bent. Ze is dat je je energie op de goede plek moet zetten. Zoeken naar de ene schuldige na een complexe verstoring levert vrijwel niets op: je vervangt een naam en het systeem dat de val opzette, blijft staan. De vruchtbaardere vraag is welke interacties je systeem gevaarlijk maken, en hoe je die kunt vereenvoudigen, ontkoppelen of zichtbaar maken voordat ze zich combineren.

Praktisch begint dat bij het serieus nemen van de kleine, op zich onschuldige dingen: het meetsignaal dat al weken op storing staat, het onderhoud dat toevallig samenvalt met een krappe belasting, de indicator waarvan iedereen weet dat hij soms iets anders aanwijst dan de werkelijkheid. Op zichzelf zijn het geen incidenten, dus ze halen zelden de aandacht. Maar het zijn precies de bouwstenen die een systeemongeval nodig heeft. Ze wegwerken vóórdat ze samenvallen, is effectiever dan achteraf uitzoeken hoe ze samenvielen.

Verminder daarnaast waar het kan de complexiteit en de koppeling zelf. Kun je een proces zo inrichten dat de onderdelen minder onverwacht op elkaar inwerken? Kun je ergens speling terugbrengen zodat een beginnende cascade tijd krijgt om op te vallen? En zorg dat operators een beeld hebben dat ook klopt als het misgaat: veel systeemongevallen gaan mis omdat de mensen erin de situatie verkeerd begrepen, niet omdat ze verkeerd handelden. Betere, eerlijkere informatie — ook over wat het systeem níét zeker weet — is vaak meer waard dan nog een procedure.

Verander tot slot de manier waarop je onderzoek doet. Een onderzoek dat stopt zodra het een “menselijke fout” heeft gevonden, mist per definitie het systeemongeval, want de interactie die de val opzette, ligt vóór en rondom die ene handeling. Vraag daarom niet alleen wat er misging, maar ook waarom het handelen op dat moment logisch was voor de mensen die erbij stonden — en welke omstandigheden hun een verkeerd beeld gaven. Kijk bovendien naar de keren dat een vergelijkbare samenloop nét goed afliep: daar zie je vaak dezelfde kwetsbaarheid, alleen zonder de laatste tegenvaller die het deze keer wél liet ontsporen. Die bijna-gebeurtenissen zijn je goedkoopste blik op de architectuur voordat die je een keer echt verrast.

De omslag: van schuldige zoeken naar architectuur begrijpen

De verschuiving zit in waar je na een complexe verstoring naar kijkt.

  • Van één oorzaak naar een samenloop — stop met zoeken naar de fout die het deed en breng in kaart welke op zich onschuldige dingen op elkaar inwerkten. De verklaring zit in de combinatie, niet in één component.
  • Van schuldige naar architectuur — vraag niet wie het liet gebeuren, maar welke eigenschappen van het systeem dit soort samenloop mogelijk maakten. Een naam vervangen verandert de architectuur niet.
  • Van incidenten tellen naar bouwstenen wegnemen — richt je op de kleine, sluimerende afwijkingen die geen incident zijn maar wel de grondstof van een systeemongeval. Ze verdwijnen zelden vanzelf.
  • Van meer lagen naar minder verwevenheid — begrijp dat je niet elk complex systeem veilig maakt door er controles bovenop te stapelen; soms is vereenvoudigen en ontkoppelen de enige echte winst.

Waarom dit ertoe doet voor veiligheid

Zolang je gelooft dat elk ongeval een schuldige heeft, blijf je na elke verstoring hetzelfde doen: onderzoeken wie het deed, die persoon aanspreken of vervangen, en concluderen dat het nu is opgelost. Maar bij een systeemongeval verandert dat helemaal niets aan de kans dat het opnieuw gebeurt, want de val stond niet in de mens maar in het systeem. Erkennen dat sommige ongevallen een eigenschap van de architectuur zijn, is geen vrijbrief — het is de voorwaarde om je aandacht te verleggen naar de plek waar je echt iets kunt veranderen.

Voor een netbeheerder wordt dit alleen maar urgenter. Het net wordt complexer, voller en strakker gekoppeld, en tegelijk hangen er steeds meer geautomatiseerde systemen aan die op elkaar reageren op manieren die niemand volledig overziet. Dat is precies het recept van Perrow. De enige serieuze verdediging is niet de belofte dat het nooit meer misgaat, maar het nuchtere werk van complexiteit verminderen waar het kan, koppeling losser maken waar het telt, en de sluimerende bouwstenen wegruimen voordat ze op één lijn komen te staan.

Soms is er geen schuldige. Er is een architectuur die, gegeven genoeg tijd, precies dit ongeval een keer moest produceren — en de enige echte vraag is of je dat wilt zien voordat het gebeurt.

Wat je hieraan hebt

Na deze kaart herken je het systeemongeval: een ramp die niet uit één fout voortkomt maar uit de onverwachte interactie van kleine, op zich onschuldige afwijkingen in een complex en strak gekoppeld systeem. Je weet waarom de zoektocht naar één schuldige daarbij vrijwel niets oplevert, en waar je je aandacht wél op richt: op de verwevenheid, de koppeling en de sluimerende bouwstenen. En je begrijpt waarom vakbekwame mensen een situatie collectief verkeerd kunnen begrijpen — niet uit onkunde, maar omdat het systeem hun een beeld gaf dat niet klopte.

In deze kaart lees je

  • Wat een systeemongeval is: interactieve complexiteit plus vaste koppeling maken de ramp tot een normale systeemeigenschap.
  • Waarom kleine, op zich onschuldige afwijkingen samen een situatie vormen die niemand kan overzien.
  • Hoe latente condities en normalisatie van afwijking de bouwstenen leveren die van binnenuit niet gevaarlijk voelen.
  • Waarom de zoektocht naar één schuldige de architectuur ongemoeid laat — en wat je in plaats daarvan doet.

REFLECTIEVRAAG
Denk aan een verstoring in jouw omgeving die achteraf op één fout werd teruggebracht. Welke kleine, op zich onschuldige dingen speelden er tegelijk mee — en zijn die daarna weggeruimd, of staan ze er nog?

Verdieping & bronnen

De basis onder deze kaart, voor wie verder wil lezen:

  • Charles Perrow (1984) — Normal Accidents: Living with High-Risk Technologies: interactieve complexiteit en vaste koppeling als bron van het systeemongeval.
  • James Reason (1990) — Human Error: actieve fouten, latente condities en het gatenkaasmodel.
  • James Reason (1997) — Managing the Risks of Organizational Accidents: hoe latente zwakheden zich in de tijd opstapelen.
  • Diane Vaughan (1996) — The Challenger Launch Decision: normalisatie van afwijking als sluipend proces.

Goede toegankelijke aanvullingen: de Skybrary-artikelen over Normal Accident Theory en het Swiss cheese model, en Richard Cook (1998) — How Complex Systems Fail, een kort en veelgelezen essay over waarom complexe systemen zelden aan één oorzaak bezwijken.