Auteur: Joep Ottenhoff
Eerst begrijpen, dan bouwen.
Hoe systeemanalyse zorgt voor een grip op scope, functies en raakvlakken.
Binnen Systems Engineering is een uitgebreide systeemanalyse aan het begin van een project cruciaal. Toch zien we in de praktijk dat systeemanalyse wordt overgeslagen of te laat wordt opgepakt met als een onduidelijke projectscope, gemiste raakvlakken en discussies over verantwoordelijkheden tot gevolg. Dit artikel is bedoeld voor eenieder die meer grip willen krijgen op de context, afbakening en functies van hun systeem. We nemen je mee in de verschillende stappen om tot een gedegen systeemanalyse te komen met in elke stap een praktijkvoorbeeld uit een dijkversterkingsproject!
Wat is je ''systeem'' eigenlijk? Het System of Interest
Voordat je iets kunt analyseren, moet je weten wát je analyseert. Dat klinkt voor de hand liggend, maar in de praktijk is het afbakenen van het System of Interest (SoI) een van de lastigste stappen. Het SoI is het systeem waar jouw project zich op richt, niet meer, niet minder.
Tegelijk bestaat dat systeem nooit in een vacuüm. Het maakt deel uit van een groter geheel: het System of Systems (SoS). Door die bredere context expliciet te maken, begrijp je beter welke bijdrage jouw systeem levert en welke prestaties daarvoor nodig zijn.
Voorbeeld dijkversterking:
Het SoI is de te versterken dijk inclusief de bijbehorende constructies (bekleding, berm, kern). Het SoS omvat het bredere watersysteem: polders, gemalen, sluizen, waterlopen en aangrenzende dijktrajecten die samen het waterveiligheidssysteem vormen. Het versterken van jouw dijk kan effect hebben op het hele System of Systems.
De wereld om het systeem heen: systeemcontext
Jouw systeem raakt allerlei andere systemen. Sommige van deze systemen vallen onder het beheer van het project, anderen absoluut niet. Het in kaart brengen van die omgeving is wat we de systeemcontext noemen. Daarbinnen maken we ondersheid tussen twee typen:
- Contextsystemen: systemen buiten de projectopdracht waarmee het SoI wel interacteert. Als project heb je er geen zeggenschap over, maar ze beïnvloeden jouw systeem, en vice versa, wel.
- Enabling systems: systemen die nodig zijn om het SoI te laten functioneren, zoals beheersystemen, monitoringstools of het wegennet voor onderhoud.
Een contextdiagram maakt deze relaties visueel. Dat is niet alleen handig voor jezelf en het project maar het is bijvoorbeeld ook een prima gespreksstarter met stakeholders die allemaal hun eigen stukje van de puzzel kennen.
Een contextdiagram maakt deze relaties visueel. Dat is niet alleen handig voor jezelf en het project maar het is bijvoorbeeld ook een prima gespreksstarter met stakeholders die allemaal hun eigen stukje van de puzzel kennen.
Voorbeeld dijkversterking
Contextsystemen zijn onder andere het spoor dat over de dijk loopt, de kabels en leidingen in de dijkzone, en de bebouwing aan de teen (voet) van de dijk. Enabling systems zijn bijvoorbeeld de beheerdatabase van de waterbeheerder en de transportroutes voor materieel. In een contextdiagram zie je in één oogopslag hoe druk (interacties met andere systemen) het eigenlijk is rondom 'jouw' dijk.
Waar stopt jouw verantwoordelijkheid? De projectgrens
De projectgrens bepaalt wat wél en niet binnen de scope van het project valt. Dat lijkt een contractuele kwestie, maar het is minstens net zo'n technisch vraagstuk. Het is belangrijk dat de technisch manager, omgevingsmanager en contractmanager hier samen over nadenken.
Start met een functionele afbakening en focus hierbij vooral op wat het systeem moet kunnen? Werk dit vervolgens later uit met een tekening/kaart/spinnenweb o.i.d. Let ook op de grijze zones: soms zijn aanpassingen buiten de formele projectgrens technisch onvermijdelijk en dreigt zo de scope van het project snel uit te breiden. Het is belangrijk om als project deze scope sterk te bewaken aangezien deze impact heeft op bijvoorbeeld de raming en planning van een project.
Voorbeeld dijkversterking
De projectgrens omvat het dijklichaam zelf, maar de nieuwe fietsbrug aan de noordkant valt er formeel buiten. Toch moet de fundering van die brug worden meegenomen in het ontwerp — anders verzakt de brug na de dijkversterking. Dit soort 'buitengrens-issues' vroegtijdig benoemen voorkomt discussies (en claims) later in het project.
Wat moet het systeem doen? Functionele analyse en de FBS
Nu we weten wát het systeem is en waar het opereert, is de volgende vraag: wat moet het doen? De functionele analyse geeft antwoord op die vraag. Door functies te benoemen en logisch te ordenen, van abstract naar steeds concreter, bouw je een Functional Breakdown Structure (FBS) op.
De FBS is meer dan een opsomming van functies. Het is de kapstok waaraan je ontwerp, verificatie en systeemintegratie ophangt. Functies koppel je aan objecten, en vanuit die koppeling formuleer je functionele eisen.
Voorbeeld dijkversterking
Op het hoogste niveau heeft de dijk de functie 'keren van buitenwater'. Die valt uiteen in subfuncties als 'afvoeren van neerslag', 'weerstaan van golfbelasting' en 'beperken van kwelstroming'. Elke subfunctie leidt tot concrete eisen aan onderdelen zoals de bekleding, de berm of het drainagesysteem. Zo mis je niets en weet iedereen wat van wie verwacht wordt.
Waar raken subsystemen elkaar? Interne raakvlakken
Systemen bestaan bijna altijd uit subsystemen en die subsystemen kunnen elkaar beinvloeden. Soms fysiek (een verbinding, een aansluiting), soms logisch (datauitwisseling, aansturing) en soms via mensen (wie bedient wat?). Deze raakvlakken zijn een veelvoorkomende bron van fouten en misverstanden, zeker als verschillende disciplines of aannemers betrokken zijn.
De N²-methode (ook wel N-kwadraat matrix) is een effectieve manier om deze raakvlakken overzichtelijk in kaart te brengen. In een matrix zet je alle subsystemen uit op twee assen en breng je per combinatie de interacties in kaart.
Voorbeeld dijkversterking
Het raakvlak tussen het dijklichaam en de kabelleiding die er doorheen loopt, is een klassiek voorbeeld. Wie is verantwoordelijk voor de mantelbuizen? Wat zijn de eisen aan de omhulling? En hoe verloopt de afstemming als de leidingbeheerder zijn net wil aanpassen tijdens de bouw? In de N²-matrix maak je dit soort raakvlakken expliciet, zodat niemand voor verrassingen komt te staan.
De kwaliteit ''meetbaar'' maken: integrale aspecten (RAMSSHE€P)
Een systeem dat 'gewoon functioneert' is nog niet per se een goed systeem. Denk ook aan: hoe betrouwbaar is het? Hoe beschikbaar? Hoe onderhoudbaar? En hoe veilig? Dit zijn de zogenaamde RAMS-aspecten, en deze bepalen in grote mate hoe het systeem presteert over zijn gehele levenscyclus.
Afhankelijk van het project kunnen ook andere integrale aspecten een rol spelen, zoals toekomstbestendigheid (klimaatadaptatie!), operabiliteit of cybersecurity van meet- en regelsystemen (RAMSSHEEP)
Voorbeeld dijkversterking
Een dijk moet niet alleen nú voldoen aan de veiligheidsnorm — hij moet dat over 50 jaar ook nog doen. Dat vraagt om keuzes in materiaalkeuze (onderhoudbaarheid), inspectie-intervallen (beschikbaarheid) en faalmechanismen (betrouwbaarheid). Veiligheid is daarbij niet alleen waterveiligheid: ook bijvoorbeeld de constructieveiligheid tijdens de bouwfase (denk aan instabiliteit van taluds bij grondverzet) valt hieronder.
Tot slot: iteratief werken loont
Systeemanalyse is geen eenmalige exercitie die je aan het begin van een project netjes afvinkt. Het is een iteratief en multidisciplinair proces. Inzichten veranderen, de context verschuift en aannames blijken soms onjuist.
De sleutel? Vroeg starten, visueel werken (contextdiagrammen, FBS, N²-matrix) en aannames expliciet maken. Juist door aannames bespreekbaar te maken, voorkom je dat ze later voor verrassingen zorgen.
Een stevig fundament van systeemanalyse betaalt zich terug gedurende het hele project — in minder scopediscussies, betere raakvlakbeheersing en een ontwerp dat daadwerkelijk doet wat het moet doen.
