Ontruimingsplan software laten maken

Wat ontruimingsplan software is (en waarom een documentmap dit niet oplost)

De meeste organisaties hebben het plan wél, maar kunnen niet aantonen dat de versie aan de muur, de versie bij de receptie en de versie in de BHV-map dezelfde zijn. Ontruimingsplan software maakt van het plan een gestructureerde dataset in plaats van een tekstbestand: gebouwen, verdiepingen, sectoren, rollen, voorzieningen en procedures zijn afzonderlijke objecten die je kunt koppelen, versioneren en publiceren.

Drie kernpunten

• Eén bron voor tekst én tekening. De hoofdstukindeling volgens NEN 8112 en de ontruimingsplattegronden volgens NEN 1414-1 komen uit dezelfde gegevens. Verplaats je een nooduitgang of een blusmiddel, dan signaleert het systeem welke plattegronden en welke procedureteksten opnieuw vastgesteld moeten worden.
• Rollen in plaats van namen in de lopende tekst. NEN 8112 beschrijft taken bij een ontruiming per functie, onder meer voor medewerkers, het meldpunt alarmmeldingen en de leidinggevende BHV. In het systeem leg je die taken vast bij de rol, en koppel je daar personen aan; personeelsverloop raakt dan de bezettingslijst, niet het plan zelf.
• Aantoonbaarheid. Elke wijziging, vaststelling en oefening krijgt een datum, een verantwoordelijke en een versienummer. Bij een controle laat je in één overzicht zien welke versie sinds wanneer geldt en wie hem heeft vastgesteld.

Het proces begint niet bij schermen, maar bij de sectorindeling

Ontwerpers willen meteen wireframes maken; bij ontruimingsplannen is dat de verkeerde volgorde. Zolang niet vaststaat hoe het gebouw is opgedeeld en wie welke sector afloopt, bouw je schermen op drijfzand. Wij werken daarom in vier stappen, net als bij elk ander maatwerk softwaretraject.

1. Inventarisatie met het hoofd BHV en facility. We lopen de bestaande plannen door, inventariseren de gebouwen, de sector- en verdiepingsindeling, de rollen en de bestaande bronnen: bouwkundige tekeningen in DWG of IFC, de melderlijst van de brandmeldinstallatie en de bezettingsgegevens uit HR of toegangscontrole.
2. Datamodel en normcheck. We modelleren gebouw, bouwlaag, sector, vluchtroute, voorziening, rol, taak en oefening als losse entiteiten. Daarna toetsen we of de verplichte onderdelen uit de richtlijn van NEN 8112 en de eisen van NEN 1414-1 aan de tekeningkant allemaal een plek hebben.
3. Bouwen in korte iteraties. Eerst het beheer van gebouwgegevens en plattegronden, daarna de planonderdelen en de publicatie, ten slotte de oefen- en revisiemodule. Na elke iteratie test een ploegleider BHV met echte gebouwgegevens, niet met demodata.
4. Uitrol, revisieronde en overdracht. We migreren de bestaande plannen, doorlopen één volledige revisieronde per locatie en leveren het systeem op met beheerdocumentatie en een ingerichte autorisatiestructuur.

Zes functionaliteiten die in vrijwel elk ontruimingsplansysteem terugkomen

Elke organisatie denkt dat haar situatie uniek is. Dat klopt voor de inhoud, niet voor de functionaliteit: onderstaande zes blokken zien we bijna altijd terug, alleen de invulling verschilt.

• Planopbouw volgens een vaste indeling. Hoofdstukken, procedures en taken per rol, met standaardteksten op organisatieniveau en locatiespecifieke afwijkingen daaronder.
• Plattegrondbeheer. Onderleggers uit AutoCAD of BIM, waarop vluchtroutes, nooduitgangen, blusmiddelen, EHBO-middelen en verzamelplaatsen als objecten worden geplaatst met de symboolsystematiek van NEN 7010, zoals NEN 1414-1 voorschrijft voor ontruimingsplattegronden en bereikbaarheidskaarten.
• Rol- en bezettingsbeheer. Hoofd BHV, ploegleiders, ontruimingsploeg, meldpunt alarmmeldingen en verzamelplaatscoördinator, inclusief bezetting per dagdeel en signalering van onderbezette sectoren.
• Oefenmodule. Plannen van een ontruimingsoefening, scenario vastleggen, tijden per sector registreren en knelpunten uit de evaluatie omzetten in concrete acties met een eigenaar en einddatum.
• Revisie- en versiebeheer. Wijzigingsvoorstellen, goedkeuring door een aangewezen vaststeller, automatisch versienummer en een overzicht van welke plattegronden opnieuw geprint en opgehangen moeten worden.
• Publicatie en offline beschikbaarheid. Print-PDF's op schaal voor lijsten aan de muur, een beknopte kaart voor de BHV-map en een mobiele weergave die ook werkt als het netwerk uitvalt.

Vier toepassingen waarin de eisen echt verschillen

Wie denkt dat één sjabloon voor alle gebouwen volstaat, heeft nog nooit een zorglocatie en een distributiecentrum naast elkaar gelegd.

Zorginstellingen

Hier evacueer je verminderd zelfredzame personen meestal niet naar buiten, maar horizontaal naar een aangrenzend brandcompartiment. Het systeem moet daarom per bed of kamer een actuele bezettings- en mobiliteitsindicatie tonen en per compartiment de opvangcapaciteit bewaken.

Onderwijs

Leslokalen wisselen van bezetting per uur. Een koppeling met het roosterpakket maakt het appèl op de verzamelplaats werkbaar: de docent krijgt de klassenlijst van dat moment, niet een statische lijst.

Multi-tenant kantoren

In een verzamelgebouw bestaat één gebouwontruimingsplan naast aparte BHV-organisaties per huurder. De software moet gedeelde onderdelen centraal beheren en huurderspecifieke delen afschermen, met duidelijke afspraken over wie wat vaststelt.

Industrie en logistiek

Grote hallen, gevaarlijke stoffen en wisselende aanwezigheid van derden vragen om sectorindeling per hal, aanvullende scenario's en registratie van aanwezige uitzendkrachten en bezoekers. Vaak bouwen we dit als onderdeel van een breder maatwerk softwarelandschap.

Afbakening: dit is geen crisisalarmeringssysteem

Deze twee typen software worden bijna altijd door elkaar gehaald, en dat leidt tot verkeerde verwachtingen in een offerteaanvraag.

Wat deze pagina wel dekt: het opstellen, beheren en actueel houden van het ontruimingsplan van een gebouw. Dus de hoofdstukindeling volgens NEN 8112, de plattegronden volgens NEN 1414-1, de sectorindeling, de bezetting van BHV-rollen, de oefeningen met evaluatie en de revisie na verbouwing. De uitkomst is een systeem waarin per gebouw, verdieping en sector aantoonbaar klopt wat er in het plan staat.

Waar u anders moet zijn: gaat het om het live afhandelen van een incident, met alarmering van hulpverleners, opschaling naar een crisisteam, logboekvoering tijdens de melding en koppeling met een meldkamer, dan is dat crisis- en incidentmanagementsoftware. Ook een BHV-opleidingsadministratie met certificaatgeldigheid of een RI&E-toepassing valt hierbuiten. Die systemen bouwen wij eveneens, maar de functionele opzet draait daar om de tijdlijn van één incident, en hier om de juistheid van een plan dat er altijd moet liggen.

Technologie: saaie keuzes zijn hier de juiste keuzes

Bij veiligheidssoftware is voorspelbaarheid belangrijker dan de nieuwste framework-hype. We werken met een stack die over tien jaar nog te onderhouden is.

• TypeScript en React voor de beheeromgeving
• Node.js of .NET voor de backend, afhankelijk van uw beheerorganisatie
• PostgreSQL met PostGIS voor plattegrondcoördinaten en sectorvlakken
• SVG-rendering van plattegronden, schaalvast voor print
• Inlezen van DWG- en IFC-bestanden als onderlegger
• Server-side PDF-generatie voor lijstversies
• REST- of GraphQL-API voor koppelingen
• SSO via Microsoft Entra ID of SAML
• Progressive web app met offline cache voor de BHV-map
• Docker en CI/CD met geautomatiseerde tests
• Hosting in een Nederlands of Europees datacenter
• Auditlogging op databaseniveau

Security is bij ontruimingsplannen geen bijzaak

Een ontruimingsplan bevat gebouwinformatie die u niet zomaar op een openbare URL wilt hebben staan, en tegelijk moet het bij een calamiteit direct bereikbaar zijn. Die spanning lossen we expliciet op.

• Rolgebaseerde autorisatie tot op locatie- en sectorniveau
• Meervoudige authenticatie voor beheerders en vaststellers
• Volledige auditlog van wijzigingen, goedkeuringen en publicaties
• Versleuteling in transport en op schijf
• Afgeschermde deelbaarheid van plattegronden met externe partijen, met vervaldatum op de link
• AVG-proof omgang met persoonsgegevens van BHV'ers en, in de zorg, met mobiliteitsindicaties van cliënten
• Back-up en herstelprocedure met periodieke hersteltest
• Offline noodkopie die bruikbaar blijft bij stroom- of netwerkuitval

Waarom organisaties dit laten bouwen in plaats van kopen

Standaardpakketten bestaan en zijn voor een enkel kantoorpand vaak prima. Maatwerk wordt interessant zodra u meerdere locaties beheert, koppelingen nodig hebt met HR, rooster of toegangscontrole, of een eigen goedkeuringsstructuur hebt die niet in een pakket past.

Situatie	Standaardpakket	Maatwerk
Eén locatie, weinig wijzigingen	Meestal voldoende	Zelden nodig
Tientallen locaties, centrale regie	Loopt vast op uitzonderingen	Sterk
Koppeling met rooster, HR of BMI	Beperkt	Volledig in te richten
Eigen vaststellings- en revisieproces	Aanpassen aan het pakket	Proces blijft leidend

Wilt u de mogelijkheden bespreken voor uw gebouwenportefeuille, neem dan contact met ons op.

Veelgestelde vragen

Is een ontruimingsplan wettelijk verplicht?

De Arbowet verplicht werkgevers doeltreffende maatregelen te treffen op het gebied van eerste hulp, brandbestrijding en evacuatie van werknemers, en artikel 15 regelt de bedrijfshulpverlening. Daarnaast kan een ontruimingsplan worden geëist vanuit het brandveilig gebruik van het gebouw of vanuit een vergunning. Hoe het plan eruit moet zien is niet in de wet dichtgetimmerd; NEN 8112 geeft daarvoor de leidraad. Software neemt die verplichting niet weg, maar maakt wel aantoonbaar dat u eraan voldoet.

Voldoet software vanzelf aan NEN 8112?

Nee, een systeem kan hooguit afdwingen dat u niets overslaat. NEN 8112 is een leidraad die een hoofdstukindeling en taken per rol als richtlijn geeft, waaronder die van medewerkers, het meldpunt alarmmeldingen en de leidinggevende BHV. Wij bouwen die structuur in als verplichte velden en controles, zodat een plan niet gepubliceerd kan worden zolang onderdelen ontbreken. De inhoudelijke juistheid blijft de verantwoordelijkheid van uw eigen BHV-organisatie of adviseur.

Kan het systeem ook ontruimingsplattegronden genereren?

Ja, dat is bij de meeste projecten juist de kern. NEN 1414-1 beschrijft hoe vluchtwegen en veiligheidsvoorzieningen op ontruimingsplattegronden en bereikbaarheidskaarten worden weergegeven en stelt eisen aan inrichting en ontwerp. Wij plaatsen de voorzieningen als data-objecten op een onderlegger uit DWG of IFC en genereren daaruit schaalvaste print-PDF's. Een eindcontrole door iemand die de norm kent, blijft verstandig.

Hoe gaat de software om met verminderd zelfredzame personen?

Voor die groep is horizontale evacuatie naar een aangrenzend brandcompartiment vaak het uitgangspunt in plaats van naar buiten vluchten. Het systeem houdt dan per kamer of bed een actuele bezetting bij met een mobiliteitsindicatie, en bewaakt de opvangcapaciteit per compartiment. Die gegevens zijn privacygevoelig, dus ze worden strikt geautoriseerd en beperkt bewaard. In de praktijk is dit het onderdeel dat het meeste overleg vraagt tussen zorg, facility en de functionaris gegevensbescherming.

Kunnen we koppelen met de brandmeldinstallatie?

Uitlezen van de melderlijst en de groepenindeling van een brandmeldinstallatie volgens NEN 2535 is technisch mogelijk en helpt om sectoren in het plan gelijk te houden aan de installatie. Wij raden aan die koppeling read-only te houden, zodat het beheersysteem nooit iets terugschrijft naar veiligheidsinstallaties. Voor de ontruimingsalarminstallatie volgens NEN 2575 gebruiken we hooguit de zone-indeling als referentie. Sturing van installaties valt buiten de scope van dit type software.

Hoe worden ontruimingsoefeningen vastgelegd?

In de oefenmodule plant u de oefening, legt u het scenario vast en registreert u per sector de tijden en de terugkoppeling van de ontruimingsploeg richting het meldpunt alarmmeldingen. Na afloop registreert u het appèl op de verzamelplaats en de knelpunten uit de evaluatie. Elk knelpunt wordt een actie met een eigenaar en een einddatum, zodat de volgende oefening begint met de openstaande punten van de vorige. Zo ontstaat een dossier dat u bij een audit direct kunt tonen.

Wat gebeurt er na een verbouwing?

Dat is precies het moment waarop plannen in de praktijk verouderen. Het systeem start een revisieronde: gewijzigde bouwlagen worden gemarkeerd, betrokken plattegronden en procedureteksten komen op een takenlijst en de vaststeller krijgt een goedkeuringsverzoek. Pas na goedkeuring krijgt het plan een nieuw versienummer en volgt een printlijst met de plattegronden die fysiek vervangen moeten worden. Zonder die stap hangen er nog maanden oude tekeningen aan de muur.

Werkt het systeem ook zonder netwerk?

Ja, dat is een harde eis bij dit soort software. We leveren de gebruikersomgeving als progressive web app met een offline cache, zodat BHV'ers hun sectorkaart en takenlijst op hun telefoon houden bij stroom- of netwerkuitval. Daarnaast blijft er altijd een actuele papieren versie in de BHV-map, gegenereerd vanuit hetzelfde systeem. Digitale beschikbaarheid vervangt de papieren noodkopie niet, maar zorgt er wel voor dat beide dezelfde versie zijn.