Voorbeeld van risicobeoordeling volgens ISO 12100 klinkt voor veel teams nog steeds als een nette tabel invullen en klaar. Dat is precies de valkuil. De slechtste risicobeoordeling is niet rommelig, maar verzorgd: scores, normen, opmerkingen en een eind-PDF dat iedereen het prettige gevoel geeft dat het onderwerp afgehandeld is. Alleen kijkt ISO 12100 niet naar de esthetiek van je bestand. ISO 12100 kijkt naar iets veel ongemakkelijkers: is het veiligheidsproces echt doorlopen, logisch onderbouwd en aantoonbaar vastgelegd?
Daar gaat het vaak mis. Een Excel-bestand bewaakt geen denklijn. Het dwingt je niet van machinegrenzen naar echte taken te gaan. Het vraagt niet vanzelf door op een gevaarlijke situatie. Het waarschuwt niet dat een beschermingsmaatregel zelf een secundair risico kan creëren. En het houdt al helemaal niet vanzelf een audit trail bij waarmee je later nog kunt uitleggen wie iets heeft gewijzigd, waarom een risico acceptabel werd verklaard of op basis waarvan voor een veiligheidsfunctie precies PL d is gekozen.
De echte vraag is dus niet of een risicobeoordeling in Excel kan. Natuurlijk kan dat. De echte vraag is harder: kan jouw werkwijze een proces afdwingen dat je technisch, logisch en auditmatig kunt verdedigen? Dáár zit het verschil tussen een tabel en engineering.
Excel is geen documentatie van de risicobeoordeling
Laten we de mythe meteen slopen. ISO 12100 eist geen Excel. ISO 12100 eist documentatie van de risicobeoordeling. Dat is iets anders. Een Excel-bestand kan een werkinstrument zijn. Een kladblok. Een plek waar het team observaties verzamelt. Soms zelfs een prima tussenstap. Maar een bestand vol regels en cijfers is nog geen verdedigbare documentatie van de risicobeoordeling.
Waarom niet? Omdat documentatie niet alleen moet tonen wat er is ingevuld, maar ook waarom. Je moet achteraf kunnen reconstrueren welke aannames zijn gebruikt, welke machinegrenzen golden, welke taken zijn bekeken, welke gevaarlijke situaties en gevaarlijke gebeurtenissen zijn meegenomen, hoe het risico is geschat, welke beschermingsmaatregel is gekozen, in welke volgorde die maatregel is toegepast en hoe het restrisico is beoordeeld.
Een goede documentatie van de risicobeoordeling laat minimaal dit zien:
- het beoogde gebruik en het redelijkerwijs voorzienbare misbruik;
- de grenzen van de machine, inclusief gebruik, ruimte, tijd en toegang;
- de concrete taken van operator, onderhoud en service;
- het gekoppelde gevaar per taak en per zone;
- de gevaarlijke situatie en waar relevant de gevaarlijke gebeurtenis;
- de initiële risicobeoordeling en de argumentatie daarachter;
- de gekozen beschermingsmaatregel volgens de volgorde van ISO 12100;
- het eventuele secundair risico na invoering van de maatregel;
- de herbeoordeling en het restrisico;
- wie welke beslissing heeft genomen en wanneer.
Dat laatste punt wordt structureel onderschat. Een keurige tabel zonder besluitspoor oogt professioneel, maar blijft inhoudelijk broos. Je ziet de eindstand, niet de redenering. En precies die redenering moet overeind blijven als er later vragen komen vanuit CE, een interne review, een klant of na een incident.
Voorbeeld van risicobeoordeling volgens ISO 12100: waar het meestal misgaat
De meest voorkomende fout is niet dat teams geen gevaren zien. De meest voorkomende fout is dat ze te snel naar oplossingen springen. Van gevaar rechtstreeks naar afscherming, procedure of instructie, alsof de volgorde in ISO 12100 slechts formaliteit is. Dat is ze niet.
De norm vraagt een vaste logica: eerst inherent veilig ontwerp, daarna technische beschermingsmaatregelen, pas daarna informatie voor gebruik. In de praktijk zie je vaak het omgekeerde. Er staat een risico in de lijst, iemand noteert afscherming plus instructie, en iedereen schuift door. Dat voelt efficiënt. Het is vaak ook inhoudelijk te dun.
Een tabel bewaakt die logica niet. Een tabel zegt niet dat je de machinegrenzen nog niet scherp hebt. Een tabel merkt niet op dat onderhoud heel andere blootstelling kent dan normaal gebruik. Een tabel herinnert je niet aan de vraag of de gekozen beschermingsmaatregel de toegang bij storingen lastiger maakt. Daardoor lijkt het proces compleet terwijl het in werkelijkheid gaten heeft.
En dat is precies het verraderlijke. Rommel valt op. Schijnprofessionaliteit niet.
Secundair risico: daar vallen de meeste documenten door de mand
Een beschermingsmaatregel sluit het verhaal niet af. Een beschermingsmaatregel verandert het risicolandschap. Wie daar niet opnieuw naar kijkt, beschrijft maar de helft van de werkelijkheid.
Secundair risico is geen detail voor perfectionisten. Het is de stresstest van je risicobeoordeling. Want juist hier blijkt of je echt naar de interactie tussen mens, machine, energie en proces hebt gekeken.
Mechanisch voorbeeld: de afscherming verlaagt het ene risico en vergroot het andere
Stel: op een verpakkingsmachine is er regelmatig contact met een bewegend deel. Het oorspronkelijke letsel is relatief beperkt, bijvoorbeeld schaafwonden of lichte kneuzingen. Het team plaatst een beweegbare afscherming met vergrendeling. Op papier lijkt dat een duidelijke verbetering. Tijdens automatisch bedrijf is de toegang tot de gevarenzone beperkt. Klaar, toch?
Nee. Na de wijziging blijkt dat een operator bij reinigen of het verhelpen van een opstopping dieper moet reiken, door een smallere opening moet werken en in een onnatuurlijke houding moet manoeuvreren. Het oorspronkelijke mechanische risico is misschien gedaald, maar er ontstaat een nieuw probleem met bereikbaarheid, zicht en ergonomie. In een zwaardere variant kan een grote of slecht ondersteunde afscherming zelfs leiden tot stoten, beknelling of snijgevaar aan hand of vingers.
Dat is secundair risico. Niet theoretisch. Gewoon werkvloerrealiteit.
Voorbeeld uit besturing: een correcte veiligheidsfunctie die omzeiling uitlokt
Neem een situatie waarin een veiligheidsfunctie correct is ontworpen: openen van de afscherming stopt de gevaarlijke beweging, automatische herstart is geblokkeerd en hervatten kan alleen via handmatige reset. Technisch klopt het. Maar wat doet die logica met het echte werk?
Als elke kleine interventie langer duurt, operators uit hun ritme haalt en extra stappen vraagt voordat productie hervat mag worden, ontstaat een gevaarlijke druk richting omzeiling. Dan krijg je gedrag dat je in de tabel zelden terugziet maar op de vloer wél: reset zonder zonecontrole, routineus bevestigen, pogingen om beveiligingen te overbruggen of informele werkafspraken om tijd te winnen.
De fout zit dan niet per se in de veiligheidsfunctie zelf. De fout zit in het invoeren ervan zonder te toetsen wat die keuze doet met menselijk gedrag en de werkvolgorde. Een systeem kan technisch correct zijn en operationeel tóch onveilig uitpakken.
Elektrisch voorbeeld: selectieve potentiaalvereffening die het geheel verslechtert
Ook elektrisch gaat het vaak subtiel mis. Iemand ziet een risico op elektrische schok en besluit een deel van de machine extra te beveiligen met potentiaalvereffening. Goede bedoeling. Slechte uitvoering als dat alleen fragmentarisch gebeurt.
Wanneer potentiaalvereffening slechts voor één deel van het systeem wordt aangebracht, zonder het hele referentieniveau van de installatie mee te nemen, kan juist een grotere kans op potentiaalverschillen ontstaan. Bij een fout of overgangstoestand raakt een persoon die twee delen tegelijk aanraakt mogelijk in een ongunstiger scenario dan vóór de zogenoemde verbetering.
Dat is de harde les: een beschermingsmaatregel die los van het systeem is bedacht, kan het systeem als geheel onveiliger maken.
Wat verbindt deze voorbeelden? In alle gevallen deed iemand iets dat op het eerste gezicht logisch leek: een afscherming plaatsen, besturingslogica aanscherpen, potentiaalvereffening toevoegen. Het probleem was niet dat er een maatregel kwam. Het probleem was dat niemand serieus controleerde wat die maatregel deed met de rest van de keten mens-machine-proces-energie.
Audit trail is geen luxe, maar bewijs van denken
Veel teams behandelen audit trail als iets voor later. Iets voor een audit. Iets administratiefs. Dat is een misvatting. In een risicobeoordeling is audit trail het bewijs dat de uitkomst niet uit de lucht is komen vallen.
De eindversie van een document toont alleen het resultaat. Audit trail toont de route ernaartoe. En juist die route vertelt of beslissingen consistent zijn genomen, of eerder gemaakte aannames zijn herzien, of na een beschermingsmaatregel opnieuw is beoordeeld en of een secundair risico echt is gezien in plaats van weggeschreven.
Drie situaties waarin dit pijnlijk duidelijk wordt:
- Een risico gaat van middel naar laag, maar niemand kan na een maand nog uitleggen waarom. Was er een nieuwe maatregel? Is de taak anders afgebakend? Of is de score aangepast om het document af te ronden?
- Een gevaarlijke situatie is als acceptabel aangemerkt, maar zonder spoor van de argumentatie. Was de blootstelling zeldzaam, het effect beperkt en de taak strikt gecontroleerd? Of was de uitkomst gewoon numeriek laag en daarmee politiek handig?
- Bij een veiligheidsfunctie staat ISO 13849 en PL d vermeld, maar de logica ontbreekt. Welke functie betreft het? Wat wordt bewaakt? Welke beweging wordt gestopt of verhinderd? Waarom precies dit prestatieniveau?
Zonder audit trail kun je achteraf nauwelijks onderscheid maken tussen een doordachte engineeringbeslissing en cosmetisch bijwerken van een tabel. En laten we eerlijk zijn: in veiligheidsprojecten gebeurt beide. Daarom moet het systeem het onderscheid zichtbaar maken.
Een overschreven cel in Excel bewaart de eindtoestand, niet de reden. Een losse opmerking is geen besluitlogica. En een mooi PDF is al helemaal geen technisch geheugen van het project.
Voorbeeld van risicobeoordeling volgens ISO 12100: één machine, zestien gevaarlijke situaties
Laten we het concreet maken. Stel een geautomatiseerd verpakkingsstation met gevaarlijke bewegingen, operatorinterventies, het verhelpen van opstoppingen, onderhoudswerk, toegang tot elektrische en pneumatische energie en meerdere veiligheidsfuncties die afhangen van de besturingslogica. Dit is geen abstracte machine. Dit is precies het soort installatie waar een oppervlakkige beoordeling keurig oogt en toch tekortschiet.
In een serieus uitgewerkte analyse kom je dan niet uit op twee of drie algemene regels. Je krijgt zestien afzonderlijke gevaarlijke situaties: dertien taaksituaties en drie gevaarlijke gebeurtenissen volgens de logica van ISO 12100. Denk aan kleine interventies tijdens bedrijf, het verhelpen van opstoppingen, afstellen van beveiligingen, functionele tests, het afschakelen van energie, vervanging van slijtdelen, storingsdiagnose en gebeurtenissen zoals onbedoelde start, uitworp van objecten en het vrijkomen van pneumatische energie.
Wat maakt zo'n voorbeeld waardevol?
Omdat het laat zien dat je geen machine in algemene zin beoordeelt. Je beoordeelt concrete interacties tussen mens en machine:
- bij een specifieke taak;
- in een specifieke zone;
- met een specifiek gevaar;
- onder specifieke toegangsvoorwaarden.
Dat klinkt vanzelfsprekend, maar precies hier vallen veel documenten stil. Er staat dan één regel met mechanisch gevaar of gevaarlijke beweging, terwijl de echte risicoverdeling totaal anders ligt. Niet de aanwezigheid van beweging is vaak het hoofdprobleem, maar de toegang tijdens interventie, storing of diagnose.
Wat liet de analyse in de praktijk zien?
Ten eerste dat het zwaartepunt van het risico niet zat in normaal automatisch bedrijf, maar in het moment waarop iemand de gevarenzone betreedt of beïnvloedt. Kleine ingrepen tijdens productie, storingen verhelpen en foutdiagnose bleken kritischer dan het algemene machinebeeld deed vermoeden.
Ten tweede bleek dat niet elke gevaarlijke situatie dezelfde behandeling nodig had. Sommige scenario's waren als laag risico verdedigbaar te accepteren, maar alleen omdat frequentie, taakomvang, voorspelbaar effect, uitvoeringscondities en gebruikersrol scherp waren afgebakend. Niet omdat een score toevallig gunstig uitviel.
Ten derde waren meerdere situaties simpelweg niet geloofwaardig af te handelen met afscherming plus instructie. Daar moest de documentatie van de risicobeoordeling echt inhoud leveren: welke veiligheidsfunctie reduceert het risico, wat doet die functie precies, wanneer wordt gevaarlijke beweging geblokkeerd, wanneer is handmatige reset verplicht en waarom is de gekozen betrouwbaarheid passend. Daar hoort ook de koppeling bij naar ISO 13849 als de functie daarop steunt.
Ten vierde werd pas met een volledig besluitspoor zichtbaar waarom sommige risico's acceptabel waren en andere naar risicoreductie gingen. Zonder audit trail blijft dat verschil vaak onzichtbaar en oogt alles even overtuigend, terwijl de onderbouwing in werkelijkheid sterk varieert.
Hoe een verdedigbare risicobeoordeling volgens ISO 12100 er echt uitziet
Een goed voorbeeld begint niet met invulvelden. Het begint met afbakening. Wat is het beoogde gebruik? Wie gebruikt de machine? Welke grenzen gelden? Welke taken worden in de praktijk echt uitgevoerd, ook de lastige en informele? Welke gevaren horen daarbij? Welke gevaarlijke situatie of gevaarlijke gebeurtenis volgt daaruit?
Daarna pas komt de risicobeoordeling zelf. En ook die stopt niet na de eerste inschatting. De volgorde hoort zichtbaar te zijn:
- initiële beoordeling van het risico;
- besluit of reductie nodig is;
- keuze van de beschermingsmaatregel in de juiste volgorde volgens ISO 12100;
- controle op secundair risico;
- herbeoordeling na de wijziging;
- vastlegging van het restrisico en de argumentatie voor acceptatie.
Als een document die keten niet laat zien, dan is het geen sterk voorbeeld van documentatie van de risicobeoordeling. Dan is het een lijst met resultaten zonder bewijs van proces.
En juist dat proces maakt later het verschil. Niet alleen voor de auditor, maar ook voor je eigen team. Want machines veranderen. Taken verschuiven. Operators vinden kortere routes. Onderhoud ontdekt beperkingen die in ontwerp nooit zijn gezien. Zonder stevige documentatie moet je telkens opnieuw raden waarom eerdere keuzes zijn gemaakt.
De kern: geen cosmetica, maar techniek
Een nette tabel is prettig. Een duidelijk PDF is handig. Maar veiligheid van machines wordt niet beslist door opmaak. Wie serieus werkt volgens ISO 12100, moet meer leveren dan een geloofwaardig ogend einddocument. Je moet kunnen aantonen dat je van machinegrenzen naar taken bent gegaan, van taak naar gevaar, van gevaar naar gevaarlijke situatie, van maatregel naar secundair risico en van herbeoordeling naar restrisico.
Dat is de maatstaf. Niet of het bestand professioneel oogt, maar of de logica klopt en overeind blijft zodra iemand doorvraagt.
Dus als je zoekt naar een Voorbeeld van risicobeoordeling volgens ISO 12100, zoek dan niet naar de mooiste tabel. Zoek naar een voorbeeld waarin beslissingen terug te leiden zijn, beschermingsmaatregelen in context staan en het systeem na elke wijziging opnieuw kritisch is bekeken. Alles daaronder is administratie. Geen engineering.