Incidentmeldingen die op de werkvloer echt worden ingevuld

Het formulier is het probleem niet. Het meldmoment wel.

De meeste bedrijven hebben geen probleem met incidentmeldingen. Ze hebben een probleem met melden op het moment zelf.

Iemand ziet iets. Een bijna-ongeval bij een laadperron, een oogdouche die over datum is, een tijdelijke slangreparatie waarvan vier maanden geleden iedereen vond dat die tijdelijk was. En dan? Diegene heeft handschoenen aan. Staat naast een installatie. Het formulier staat op een desktop ergens in het kantoor, of het is een papieren lijst in een map bij de ingang. Dus de melding komt later, of in een ingekorte versie, of helemaal niet.

Dat is de hele mislukking. Niet de taxonomie, niet de categorieën, niet het dashboard. Het gat tussen iets zien en iets vastleggen.

Wil je dus meer en betere meldingen, begin daar en werk naar buiten toe.

Wat een bruikbare incidentmelding echt nodig heeft

Er is altijd de verleiding om het formulier compleet te maken. Elk veld, elke categorie, elke dropdown, zodat de data achteraf schoon is. En dan vult niemand het in, want het kost twintig minuten en degene die meldt is niet degene die iets aan die schone data heeft.

Hou de melding kort op het punt van vastleggen, en laat de detaillering in de opvolging gebeuren. In de praktijk betekent dat:

Wat er gebeurde, in de woorden van de melder zelf. Vrije tekst. Geen categorie. Mensen beschrijven dingen nauwkeurig als je ze normaal laat praten, en slecht als je ze laat kiezen uit een lijst die ze niet herkennen.
Waar. Locatie, installatie, unit. Specifiek genoeg dat een ander ernaartoe kan lopen.
Wanneer. Automatisch een timestamp, daar vraag je niet naar.
Een foto. Eén foto haalt het grootste deel van de ruis weg die geschreven beschrijvingen veroorzaken. Dit is verreweg het waardevolste veld op het hele formulier.
Hoe erg, ongeveer. Een simpele schaal. Geen risicomatrix op het moment van melden.
Wie het moet weten. Eén veld, of automatische routering op basis van locatie.

Al het andere, classificatie, oorzaakanalyse, de koppeling naar een scenario of een bowtie, wordt toegevoegd door iemand die daar de tijd en het mandaat voor heeft. Dat is niet de operator die op de installatie staat.

De opvolging is waar melden zich terugbetaalt

Een melding die nergens heen gaat, leert iedereen dat melden nergens heen gaat. Een paar van die ervaringen en de meldingsbereidheid zakt, en die daling ziet er in je cijfers uit als een verbetering.

Het deel dat ertoe doet is dus wat er ná de melding gebeurt:

Hij landt bij iemand met een naam. Niet bij een mailbox, niet bij een afdeling. Een eigenaar met naam.
Er staat een datum bij. Corrigerende maatregelen zonder datum zijn wensen.
De melder hoort iets terug. Ook als het antwoord is: we hebben ernaar gekeken, we veranderen niets, en dit is waarom. Juist dan.
Hij wordt afgesloten met bewijs. Een foto van de reparatie, een afgetekende procedure, een uitgevoerde controle. Afsluiten zonder bewijs is iemand die op een knop drukt.
Terugkerende meldingen behandel je als één ding. Vijf losse meldingen over dezelfde koppeling zijn geen vijf incidenten. Het is één probleem dat vijf keer gemeld wordt, en dat je het vijf keer binnenkrijgt is zelf de bevinding.

Waar melden raakt aan je andere verplichtingen

Dit is het stuk dat in de meeste implementaties wegvalt, en het is precies het stuk dat je tijdens een inspectie geld en tijd kost.

Een incidentmelding is vaak het eerste geschreven signaal dat iets in je gedocumenteerde systeem niet meer klopt. Een wijziging die nooit verwerkt is. Een generieke maatregel uit 2013 die niet meer overeenkomt met wat er daadwerkelijk staat. Een procedure die een stap beschrijft die niemand meer uitvoert.

Dat betekent dat je meldingen een route nodig hebben naar twee andere processen:

Management of change. Beschrijft de melding een wijziging, tijdelijk of niet, dan moet die de MOC-route in. Niet elke melding is MOC-waardig, en elke melding als wijzigingsvoorstel behandelen begraaft het proces. Maar de meldingen die het wél zijn, moeten daar betrouwbaar terechtkomen en niet omdat iemand er toevallig aan denkt.

Je geschreven systeem. Laat het incident een gat zien tussen wat je documentatie zegt en wat er in het veld gebeurt, dan sluit dat gat zichzelf niet. We moeten schrijven wat we doen en we moeten doen wat we schrijven, en een incidentmelding is vaak de goedkoopste vroege waarschuwing die je krijgt dat die twee uit elkaar zijn gelopen.

Voor Seveso-inrichtingen loopt die verbinding via je VBS en, waar het het veiligheidsrapport raakt, de actualisatiecyclus in. Dat inspecties van DCMR of de Nederlandse Arbeidsinspectie ongemakkelijk worden, komt zelden door het incident zelf. Het komt doordat het incident bekend was, gemeld was, en er geen naspeurbare lijn ligt van de melding naar wat er als gevolg daarvan veranderd is. Die lijn is wat je moet kunnen laten zien. Generieke tooling stopt meestal bij de melding en laat je die lijn met de hand trekken, en dat is waarom generieke safety management software tekortschiet voor Seveso III bedrijven.

Een paar dingen die je meldcultuur stilletjes slopen

Op het meldmoment naar een oorzaak vragen. Mensen gaan gokken of censureren zichzelf. Je krijgt slechtere data en soms minder meldingen, want niemand wil een collega beschuldigen in een tekstvak.
Aantallen meldingen als prestatie-indicator per team. Het aantal gaat omlaag. Meer gebeurt er niet.
Bijna-ongevallen laten voelen als papierwerk met gevolgen. Bijna-ongevallen zijn gratis informatie. Maak ze duur en ze komen niet meer binnen.
Een apart systeem per locatie. Zesentwintig sites met zesentwintig manieren van melden betekent dat je het patroon niet ziet dat op drie ervan opduikt.
Een formulier geschreven door de mensen die de data lezen. Laat iemand van de werkvloer het invullen waar jij bij staat, in de kleding die hij normaal aanheeft, op de plek waar hij normaal staat. Binnen tien minuten haal je de helft van de velden eruit.

Wat je deze week kunt controleren

Hier heb je geen project voor nodig. Pak je laatste twintig incidentmeldingen en check drie dingen:

Hoeveel tijd zit er tussen de gebeurtenis en het invoeren van de melding? Is dat structureel meer dan een dag, dan zit het probleem in het vastleggen, niet in de bereidheid.
Hoeveel zijn er afgesloten, en daarvan: hoeveel zijn afgesloten met iets dat je aan een inspecteur kunt laten zien?
Hoeveel beschrijven een situatie die eigenlijk MOC in had gemoeten, en dat niet deed?

Die drie antwoorden vertellen je meer over je meldproces dan welk dashboard dan ook.

Een korte, eerlijke volgende stap

Software maakt je niet compliant, en een goed formulier maakt een locatie niet veilig. Wat een tool wel kan doen: de wrijving weghalen op het moment van vastleggen, de opvolging zichtbaar houden, en de lijn bewaken tussen een melding en wat er door die melding veranderd is. Daar is Capptions voor gebouwd: formulieren en workflows die je zelf inricht, corrigerende maatregelen met een eigenaar en een datum, en bewijs dat aan de afsluiting hangt.

Wil je weten of dat past bij hoe jullie locaties nu al werken, dan is een demo van onze schermen niet het handige startpunt. Je laatste twintig meldingen en je huidige formulier wel. Neem die mee, dan kunnen we vrij snel zeggen of dit je helpt of dat wat je hebt al goed genoeg is.