{"id":1791,"date":"2026-06-15T08:00:00","date_gmt":"2026-06-15T06:00:00","guid":{"rendered":"https:\/\/datastorms.eu\/?p=1791"},"modified":"2026-07-08T10:01:36","modified_gmt":"2026-07-08T08:01:36","slug":"wie-is-verantwoordelijk-voor-het-systems-engineering-plan","status":"publish","type":"post","link":"https:\/\/datastorms.eu\/nl\/2026\/06\/15\/wie-is-verantwoordelijk-voor-het-systems-engineering-plan\/","title":{"rendered":"Wie is verantwoordelijk voor het systems engineering plan?"},"content":{"rendered":"

De systems engineer of SE-co\u00f6rdinator van het uitvoerende projectteam stelt het systems engineering plan doorgaans op. Deze persoon vertaalt de projecteisen, de gekozen SE-aanpak en de afspraken met de opdrachtgever naar een werkbaar document dat het hele team houvast biedt. De verantwoordelijkheid ligt daarmee primair bij de opdrachtnemer, maar de opdrachtgever speelt een onmisbare rol bij vaststelling en toetsing. In dit artikel beantwoorden we de meest gestelde vragen rondom eigenaarschap, goedkeuring en onderhoud van het systems engineering plan.<\/p>\n

Wie stelt het systems engineering plan doorgaans op?<\/h2>\n

Het systems engineering plan wordt doorgaans opgesteld door de systems engineer of SE-co\u00f6rdinator aan de kant van de opdrachtnemer. Deze persoon heeft de technische en methodische kennis om de SE-aanpak te beschrijven, de verificatiestrategie te bepalen en de rollen binnen het project te defini\u00ebren. In grotere projecten kan een SE-manager of lead engineer deze taak op zich nemen, ondersteund door het projectteam.<\/p>\n

De opsteller werkt het plan uit op basis van de contractuele eisen, de van toepassing zijnde SE-standaarden zoals de Leidraad SE of INCOSE-richtlijnen, en de specifieke kenmerken van het project. Het gaat niet om een generiek document dat je eenmalig invult, maar om een levend plan dat de werkelijke aanpak beschrijft. Dat vraagt inhoudelijke betrokkenheid van iemand die het project en de methodiek goed kent.<\/p>\n

In de praktijk zien we dat het opstellen van het SE-plan regelmatig belandt bij iemand die er naast zijn andere taken weinig tijd voor heeft. Het resultaat is dan een document dat meer op papier klopt dan dat het de dagelijkse werkwijze stuurt. Juist daarom loont het om het opstellen serieus te beleggen bij een aangewezen eigenaar met voldoende mandaat en tijd. Wil je weten hoe Datastorms<\/a> teams hierbij ondersteunt? Bekijk dan wat ons platform voor jouw project kan betekenen.<\/p>\n

Wat is het verschil tussen opstellen en goedkeuren?<\/h2>\n

Opstellen betekent het inhoudelijk uitwerken van het systems engineering plan: de aanpak, de methoden, de rollen en de afspraken. Goedkeuren betekent formeel akkoord geven op dat plan, waarmee de goedkeurende partij bevestigt dat het plan voldoet aan de gestelde eisen en de overeengekomen werkwijze. Opstellen is een inhoudelijke taak; goedkeuren is een formele verantwoordelijkheid.<\/p>\n

In de meeste projecten stelt de opdrachtnemer het plan op en keurt de opdrachtgever het goed. De goedkeuring is niet louter een formaliteit. Door het plan te accorderen, committeert de opdrachtgever zich aan de beschreven aanpak en geeft hij aan dat de gekozen SE-methodiek past bij de projectdoelstellingen. Een plan dat zonder inhoudelijke toetsing wordt goedgekeurd, biedt later weinig houvast bij discussies over scope, verificatie of oplevering.<\/p>\n

Naast de opdrachtgever kan ook een interne kwaliteitsmanager, een SE-reviewboard of een onafhankelijke toetser betrokken zijn bij de goedkeuring. In complexe infrastructuurprojecten of publieke aanbestedingen zijn meerdere goedkeuringslagen gebruikelijk. Het is verstandig om in het plan zelf vast te leggen wie welke goedkeuring verleent en op welk moment in het project.<\/p>\n

Welke rol heeft de opdrachtgever in het SE-plan?<\/h2>\n

De opdrachtgever heeft een drieledige rol in het systems engineering plan: hij stelt de kaders, toetst het plan op conformiteit met de contractuele eisen en keurt het formeel goed. Daarnaast kan de opdrachtgever specifieke SE-eisen opleggen, zoals het gebruik van bepaalde verificatiemethoden, rapportageformats of traceabilityvereisten die de opdrachtnemer moet verwerken.<\/p>\n

In sommige projecten gaat de betrokkenheid van de opdrachtgever verder. Hij participeert dan actief in SE-reviews, beoordeelt verificatierapporten of neemt deel aan systeemacceptatietesten. Dit is met name het geval bij overheidsprojecten of grote infrastructuuropgaven waarbij de opdrachtgever zelf ook SE-competenties in huis heeft.<\/p>\n

Een veelgemaakte fout is dat de opdrachtgever het SE-plan behandelt als een contractueel af te vinken document. Dat ondermijnt de waarde ervan. Een opdrachtgever die inhoudelijk betrokken is bij de totstandkoming van het plan, vergroot de kans dat het plan daadwerkelijk aansluit op de projectdoelstellingen en later als sturingsinstrument wordt gebruikt in plaats van als bureauladedocument.<\/p>\n

Hoe wordt verantwoordelijkheid belegd bij ontbrekende SE-expertise?<\/h2>\n

Als SE-expertise ontbreekt binnen het projectteam, wordt de verantwoordelijkheid voor het systems engineering plan vaak tijdelijk belegd bij een externe SE-adviseur of ingehuurd specialist. Een andere optie is om de verantwoordelijkheid neer te leggen bij de projectmanager of lead engineer, aangevuld met begeleiding vanuit een SE-kennispartner of via een platform dat de methodiek ondersteunt.<\/p>\n

Ontbrekende SE-expertise is een re\u00ebel probleem in veel organisaties. Niet elk bedrijf heeft een fulltime systems engineer in dienst, maar dat betekent niet dat SE-principes buiten beeld hoeven te blijven. In de praktijk zijn er drie gangbare oplossingen:<\/p>\n