

Official logo of Basque Country's public health care service: Osak

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 



Atmosphere of azure electric sky, with water, slope,

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Projectversterking 

Nieuw Softwareproject / Modernisering 

Productivity (Agile Analytics)

Onze expertises

Over ons

Nieuws

Contact

Succes! Je bent toegevoegd aan onze e-maillijst.

Abonneer u op onze e-maillijst en we houden u op de hoogte van nieuws en publicaties van ZEN Software

Abonneer op de nieuwsbrief van ZEN Software

1080_Zen-software-kantoor-3 (1).webp

1200_Zen-software-kantoor-3 (1).webp

1920_Zen-software-kantoor-3 (1).webp

2048_Zen-software-kantoor-3 (1).webp

256_Zen-software-kantoor-3 (1).webp

384_Zen-software-kantoor-3 (1).webp

3840_Zen-software-kantoor-3 (1).webp

640_Zen-software-kantoor-3 (1).webp

750_Zen-software-kantoor-3 (1).webp

828_Zen-software-kantoor-3 (1).webp

thumbnail_Zen-software-kantoor-3 (1).webp

Zen-software-kantoor-3 (1).webp

Projectversterking

1080_Frame 27 (1).webp

1200_Frame 27 (1).webp

256_Frame 27 (1).webp

384_Frame 27 (1).webp

640_Frame 27 (1).webp

750_Frame 27 (1).webp

828_Frame 27 (1).webp

thumbnail_Frame 27 (1).webp

Frame 27 (1).webp

- Maak softwareprocessen inzichtelijk met harde data in plaats van onderbuikgevoelens.  
       
- Identificeer structurele knelpunten in de workflow en achterhaal waar werkplezier en efficiëntie verloren gaan.  
      
- Optimaliseer je delivery-cyclus door het toepassen van bewezen frameworks zoals DORA en SPACE, waardoor je gericht stuurt op resultaat.  
      
- Realiseer duurzame verbeteringen door kleine, veilige stappen te zetten die de stabiliteit en productiviteit van je team direct verhogen.  

Engineering Metrics & Continuous Improvement

Continuous, Improvement

1080_logos-new.webp

1200_logos-new.webp

1920_logos-new.webp

2048_logos-new.webp

256_logos-new.webp

384_logos-new.webp

640_logos-new.webp

750_logos-new.webp

828_logos-new.webp

thumbnail_logos-new.webp

logos-new.webp

- Wij bieden hands-on ondersteuning aan jouw development-team, variërend van het oplossen van dagelijkse technische uitdagingen tot het optimaliseren van complexe CI/CD-architecturen.  
       
- Diepgaande expertise in toonaangevende platformen zoals GitLab, GitHub, Bitbucket en Azure DevOps – geen tool is ons te complex.  
      
- Maximaliseer de doorloopsnelheid van je delivery pipelines door eliminatie van wachttijden, zodat jouw team vaker en betrouwbaarder kan releasen.

Ontwikkelaarsondersteuning

Software ontwikkelen met behulp van AI en rekening houden met AVG, NIS2 en DORA compliance

ar1vht.webp

Zodra je een coding agent aan je codebase hangt, raak je drie regimes tegelijk. Niet omdat AI apart gereguleerd is, maar omdat het bestaande regels raakt op plekken waar je ontwikkelstraat er nooit eerder mee te maken had.

Zodra je een coding agent aan je codebase hangt, raak je drie regimes tegelijk.

Niet omdat AI apart gereguleerd is — de AI Act is een verhaal op zich — maar omdat AI-tooling bestaande regels raakt op plekken waar je ontwikkelstraat er nooit eerder mee te maken had. Je stuurt code naar een derde partij. Je haalt afhankelijkheden binnen die niemand handmatig gekozen heeft. Je verandert wie of wat een productiewijziging voorstelt.

*Dit artikel gaat over de engineeringkant. Het is geen juridisch advies — voor de precieze reikwijdte in jouw situatie heb je je eigen jurist of compliance officer nodig.*

Hier zit meteen verwarring, en die is bij ZEN extra voelbaar omdat wij beide betekenissen dagelijks gebruiken.

- **AVG** — de Nederlandse implementatie van de GDPR. Gaat over persoonsgegevens: welke je verwerkt, waarom, en waar ze terechtkomen.
- **NIS2** — Europese richtlijn over cyberbeveiliging voor essentiële en belangrijke entiteiten. Legt de nadruk op risicobeheer, ketenverantwoordelijkheid en het melden van incidenten. De Nederlandse omzetting heeft vertraging opgelopen; check de actuele stand voordat je op een datum plant.
- **DORA** — hier twee dingen. De **Digital Operational Resilience Act** geldt voor de financiële sector en gaat over ICT-risico’s en je afhankelijkheid van externe ICT-dienstverleners. En **DORA-metrics** zijn de vier leverstatistieken uit DevOps-onderzoek. Ze hebben niets met elkaar te maken, en in een vergadering waar zowel compliance als engineering zit, is dat vijf minuten uitleg waard.

De regels zijn niet nieuw. Wat verandert, is waar ze raken.

Voorheen liep je code van je repository naar je pipeline naar productie, allemaal binnen grenzen die je zelf had getrokken. Met een coding agent gaat er een deel van die code — en soms de context eromheen — naar een dienst die je niet beheert. Dat is geen ramp, maar het is wel een verwerking en een afhankelijkheid, en beide moet je kunnen benoemen.

De kernvraag is niet “gebruiken we AI” maar “wat sturen we mee”.

Code zelf is meestal geen persoonsgegeven. Maar de context eromheen kan dat wel zijn: een testfixture met echte klantnamen, een stack trace met e-mailadressen, een databasedump waar iemand snel iets in wilde opzoeken, een logfile die je erbij plakt om een bug uit te leggen.

Wat je praktisch wilt weten:

- **Welke tooling stuurt wat naar buiten?** IDE-plugins, CI-integraties en agents verschillen sterk in wat ze meesturen.
- **Waar staat de verwerking?** Regio en subverwerkers doen ertoe, net als bij elke andere clouddienst.
- **Wordt jouw invoer gebruikt voor training?** Dat is bij zakelijke abonnementen meestal uit te zetten, maar het is een bewuste keuze die iemand moet maken en vastleggen.
- **Staan die tools in je verwerkingsregister?** Als AI-tooling breed gebruikt wordt maar nergens genoteerd staat, is dat het eerste gat dat opvalt.

NIS2: je AI-leverancier zit nu in je keten

NIS2 legt veel nadruk op de beveiliging van je toeleveringsketen. Een AI-codeerassistent die schrijftoegang heeft tot je repository’s, of die in je pipeline draait, is onderdeel van die keten.

Dat betekent dat de vragen die je al aan andere leveranciers stelt, hier ook gelden: welke toegang heeft dit, wat gebeurt er bij een storing of een compromittering aan hun kant, en hoe merken wij dat?

Er komt één ding bij dat specifiek is voor AI-tooling: **afhankelijkheden die niemand gekozen heeft.** Als een agent een package voorstelt en dat komt door de review, dan is er een leverancier aan je keten toegevoegd door een model. Dat is precies het soort beslissing dat NIS2 zichtbaar wil hebben, dus laat je dependency-scanning en je goedkeuringsroute voor nieuwe packages niet ongemoeid als het volume omhoog gaat.

DORA: aantoonbaarheid, niet alleen beleid

Val je onder de Digital Operational Resilience Act, dan verschuift de lat van “we hebben beleid” naar “laat maar zien”.

Je moet kunnen laten zien welke ICT-diensten van derden je gebruikt, welke risico’s daaraan hangen en hoe je systeem zich houdt als er iets misgaat. Een AI-codeerdienst die betrokken is bij het maken van je productiecode, hoort in dat overzicht thuis.

De praktische consequentie is documentatie die niet los van je systeem staat: welke tooling betrokken was bij een wijziging, wie hem heeft goedgekeurd, en dat je controles daadwerkelijk gedraaid hebben. Dat is geen extra administratie als je het uit je pipeline haalt — en een hoop werk als je het achteraf met de hand moet reconstrueren.

Vier dingen die alle drie de regimes tegelijk bedienen, en die geen van drieën echt duur zijn:

1. **Leg vast welke AI-tooling waar draait en wat hij mag.** Eén overzicht, met toegang en verwerkingslocatie erbij. Dit is het document dat je bij elke audit als eerste nodig hebt.
2. **Markeer AI-ondersteunde wijzigingen.** Een vlag op PR-niveau volstaat. Het maakt zowel je risicogesprek als je effectmeting mogelijk — en zonder is beide giswerk.
3. **Automatiseer je controles in de pipeline.** Dependency-scanning, secret-detectie, policy-checks op infrastructuur. Als de hoeveelheid code omhoog gaat, is dit het enige wat meeschaalt; handmatige review doet dat niet.
4. **Bewaar het bewijs dat die controles gedraaid hebben.** Niet omdat een toezichthouder het mooi vindt, maar omdat “we scannen altijd” geen antwoord is en een pipelinelog dat wel is.

AI-tooling introduceert zelden een nieuw regime. Het verplaatst bestaande verplichtingen naar je ontwikkelstraat, waar ze eerder niet zaten.

AVG gaat over wat je meestuurt. NIS2 gaat over wie er in je keten zit, inclusief de afhankelijkheden die een model heeft voorgesteld. DORA gaat over of je het kunt aantonen.

Alle drie komen ze uit op hetzelfde punt: weten wat er gebeurt in je pipeline, en dat kunnen laten zien. Dat is precies de reden dat meten geen compliance-oefening is maar gewoon goed engineeringwerk — en waarom het, nu code goedkoop wordt, het deel is dat ertoe doet.

Wat dertig minuten wachten per engineer per dag echt kost

ajet8k.webp

Een half uur per dag. Zo weinig lijkt het. Maar reken het door en het is €5.000 per engineer per jaar, of een half miljoen euro bij honderd engineers — geld dat op geen enkele regel van je P&L staat en dat niemand ooit heeft goedgekeurd.

Een half uur per dag. Zo weinig lijkt het.

Je wacht op een build. Je wacht tot iemand je pull request bekijkt. Je wacht op een omgeving die vrijkomt, op een goedkeuring, op een pipeline die twaalf minuten doet over iets wat in twee zou moeten. Niemand noteert het, want het voelt niet als tijd die je kwijtraakt. Het voelt als het werk.

Reken het door en het is €5.000 per engineer per jaar. Bij honderd engineers een half miljoen euro. Elk jaar, en op geen enkele regel van je P&L.

Er zit geen truc in. Je kunt hem zelf natrekken met je eigen cijfers:

- Een half uur per werkdag is **2,5 uur per week**.
- Bij ongeveer **220 werkbare dagen** per jaar is dat **110 uur per engineer per jaar**.
- Reken je met een belaste kostprijs van zo’n **€45 per uur**, dan kom je op **€4.950** — afgerond €5.000.
- Honderd engineers: **€495.000 per jaar**.

Vul gerust je eigen tarief in. Het punt verandert niet: dit is geen randverschijnsel, het is een salarispost ter grootte van een klein team, en er staat geen factuur tegenover.

Als je erop gaat letten, blijkt het bijna nooit één groot blok te zijn. Het zijn kleine stukjes die zich opstapelen:

- **Wachten op builds en tests.** Een pipeline van acht minuten die je vijf keer per dag draait, is veertig minuten. Draait hij niet betrouwbaar, dan draai je hem vaker.
- **Wachten op review.** Meestal de grootste post, en bijna nooit apart gemeten. Je pull request staat klaar; je collega zit in een meeting.
- **Wachten op omgevingen.** Één staging, drie teams.
- **Wachten op goedkeuring.** Iemand moet een vinkje zetten en die iemand heeft vandaag iets anders te doen.
- **De verborgen kosten van het schakelen.** Dit is de pijnlijkste. Vijftien minuten wachten kost je zelden vijftien minuten: je begint aan iets anders, en de weg terug naar waar je was kost nog eens tien.

Cloudkosten zie je, want er komt een factuur. Licenties zie je, want er komt een factuur. Wachttijd komt van niemand, dus komt hij nergens binnen.

Er is ook geen moment waarop iemand een besluit neemt. Niemand heeft ooit goedgekeurd dat de pipeline acht minuten duurt; hij is er in de loop van twee jaar naartoe gegroeid, stap voor stap, en elke afzonderlijke stap was verdedigbaar.

En de mensen die er het meest last van hebben, zijn precies de mensen die het het minst snel melden. Wachten voelt niet als een probleem dat je escaleert. Het voelt als hoe het werk nu eenmaal is.

Dit is het deel dat de meeste teams verrast.

Als code sneller geschreven wordt, wordt er niet minder gewacht — er wordt méér gewacht. Meer wijzigingen bereiken sneller de wachtrij voor review. Meer pull requests concurreren om dezelfde reviewers. Meer builds vechten om dezelfde runners. De bottleneck verdwijnt niet, hij verschuift naar de plek waar geen model bij kan.

Dat is precies waarom code goedkoper maken de kosten niet wegneemt maar concentreert. We hebben dat argument uitgewerkt in [onze kijk op AI in softwareontwikkeling](/ai-solutions): zodra schrijven niet langer je beperking is, wordt alles eromheen je beperking — en dan pas blijkt of je dat ooit gemeten hebt.

Je hoeft hier geen groot programma voor op te tuigen. Drie dingen brengen het grootste deel in beeld:

- **Splits je lead time op in fases.** Eén getal van commit tot productie verbergt precies wat je zoekt. Zodra je schrijven, wachten op review, testen en uitrollen apart ziet, springt de grootste post er meteen uit.
- **Meet review-latency apart.** De tijd tussen “klaar voor review” en “iemand kijkt ernaar”. In de meeste teams is dit de grootste enkele post, en bijna nergens staat hij op een dashboard.
- **Meet de doorlooptijd van je pipeline, niet alleen of hij slaagt.** Slagingspercentage zegt niets over de tijd die je eraan kwijt bent.

Meet een maand voordat je iets verandert. Zonder nulmeting kun je achteraf niet aantonen dat je iets verbeterd hebt, en dan wint degene met de sterkste mening.

De ingrepen zijn zelden spectaculair, en dat is precies waarom ze blijven liggen.

- **Spreek een reviewtermijn af.** “Pull requests onder de 300 regels worden binnen 24 uur bekeken” haalt vaak meer weg dan welke technische ingreep ook.
- **Maak je pull requests kleiner.** Kleinere wijzigingen worden sneller bekeken, en de wachttijd daalt harder dan de omvang.
- **Versnel je pipeline met caching en parallelle tests.** Acht minuten naar drie is over honderd engineers een aanzienlijk bedrag.
- **Geef elke wijziging een eigen omgeving** in plaats van te wachten op de gedeelde staging.
- **Haal goedkeuringen weg die niets tegenhouden.** Een vinkje dat altijd gezet wordt, is geen controle maar vertraging.

Halveer je die dertig minuten, dan haal je bij honderd engineers een kwart miljoen euro per jaar terug. Dat is geen besparing die je hoeft te bevechten in een budgetronde — je hoeft alleen te weten dat hij er is.

Wachttijd is de grootste kostenpost die niemand op zijn begroting heeft staan.

Een half uur per engineer per dag is €5.000 per jaar per persoon en een half miljoen bij honderd. Het staat op geen factuur, niemand heeft het goedgekeurd, en het groeit vanzelf terwijl je nergens op let.

En zodra AI het schrijven versnelt, wordt dit het enige dat er nog toe doet. Meet het voordat je erin investeert, anders weet je straks alleen dat je sneller code produceert — niet of je sneller iets oplevert.

DORA-metrics lezen als AI de helft van je commits schrijft

aq0mfl.webp

Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde. Zodra een flink deel van je code niet meer met de hand geschreven wordt, verschuift wat elk van die metrics je vertelt — en de naïeve lezing wijst precies de verkeerde kant op.

Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde.

Zodra een flink deel van je code niet meer met de hand geschreven wordt, verschuift wat elk van die metrics je vertelt. Sommige gaan omhoog zonder dat er iets verbeterd is. Eén wordt plotseling veel belangrijker dan de rest. En de naïeve lezing — “onze deployment frequency stijgt, dus het gaat goed” — wijst precies de verkeerde kant op.

De vier DORA-metrics meten je **software delivery**, niet je productiviteit. Dat onderscheid is altijd al belangrijk geweest, maar met AI in de mix wordt het bepalend.

- **Deployment frequency** — hoe vaak je naar productie brengt.
- **Lead time for changes** — hoe lang het duurt van commit tot productie.
- **Change failure rate** — welk deel van je wijzigingen problemen veroorzaakt.
- **Time to restore** — hoe snel je herstelt als het misgaat.

Geen van deze vier meet hoeveel code je schrijft. Dat was ooit een detail. Nu is het de kern: code schrijven is niet langer je bottleneck, dus een metric die code-volume negeert is precies wat je nodig hebt.

Deployment frequency stijgt. Dat zegt minder dan je denkt.

Dit is de metric die het snelst beweegt als je AI-tooling invoert, en de metric die het makkelijkst misleidt.

Meer wijzigingen komen sneller klaar, dus er gaan meer wijzigingen naar productie. Je grafiek gaat omhoog. Iemand zet hem in een presentatie.

Maar deployment frequency meet beweging, geen vooruitgang. Als de extra deploys bestaan uit wijzigingen die niemand gevraagd heeft, of uit correcties op wijzigingen van vorige week, dan is je grafiek een teller van activiteit. Kijk er dus nooit naar zonder de change failure rate ernaast te leggen. Stijgen ze samen, dan is er geen winst — dan is er alleen meer verkeer.

Lead time: de code-fase krimpt, de rest niet

Lead time for changes is een optelsom: nadenken, schrijven, reviewen, testen, wachten op goedkeuring, uitrollen.

AI verkort betrouwbaar precies één van die stappen. De rest blijft staan waar hij stond.

Dat betekent dat je totale lead time veel minder daalt dan je verwacht — en dat de verhouding binnen die optelsom scheeftrekt. Waar schrijven vroeger misschien een derde van de doorlooptijd was, is het nu een fractie, en is wachten op een reviewer of op een pipeline verhoudingsgewijs veel dominanter geworden.

Dat is geen tegenvaller, dat is de meest bruikbare informatie die je uit deze metric kunt halen. Splits je lead time op in fases zodra je AI serieus inzet. Zonder die opsplitsing zie je één getal dat licht verbetert; mét die opsplitsing zie je precies waar je volgende uur winst ligt.

Change failure rate wordt je belangrijkste getal

Als code goedkoop wordt om te maken, wordt het duur om te vertrouwen.

Dat maakt de change failure rate de metric waar je het scherpst op moet letten. Niet omdat AI-code per se slechter is — dat argument is grotendeels achterhaald — maar omdat er méér van komt, sneller, en met minder mensen die elke regel echt gelezen hebben.

Twee dingen om in de gaten te houden. Ten eerste een stijging die samenvalt met je AI-invoering: dat is het signaal dat je snelheid je controlemechanismen voorbij is gelopen. Ten tweede, en subtieler, een change failure rate die *gelijk blijft* terwijl je deployment frequency verdubbelt. Dat betekent in absolute zin twee keer zoveel incidenten. Percentages verhullen dat.

Time to restore verandert nauwelijks — en dat is het punt

Van de vier metrics is dit degene die het minst reageert op AI-tooling, en juist daarom is hij zo informatief.

Herstellen na een incident hangt af van je observability, je runbooks, je rollback-mechanismen en of de juiste persoon bereikbaar is. Een model dat sneller code schrijft, raakt daar niets van.

Dus als je deployment frequency omhoog gaat, je lead time daalt en je time to restore blijft precies waar hij was, dan heb je de risicokant van je systeem niet meegeschaald met de snelheidskant. Dat is een prima situatie om in te zitten zolang je het wéét, en een uitstekende manier om verrast te worden als je het niet meet.

DORA blijft belangrijk, maar het is niet meer voldoende. Drie aanvullingen die in een AI-zware workflow het meeste opleveren:

- **Review-latency.** De tijd tussen “klaar voor review” en “gereviewd”. Dit is in de meeste teams inmiddels de grootste enkele post in je lead time, en hij wordt zelden apart bijgehouden.

- **Rework-ratio.** Welk deel van je wijzigingen binnen bijvoorbeeld twee weken alweer aangeraakt wordt. Stijgt dit terwijl je sneller levert, dan produceer je herstelwerk in plaats van vooruitgang.

- **Aandeel AI-ondersteunde wijzigingen.** Je hoeft niet elke regel te herleiden, maar zonder enige indicatie kun je geen enkele uitspraak doen over wat AI je gebracht heeft. Zelfs een grove markering op PR-niveau maakt het verschil tussen meten en gokken.

Begin met een nulmeting vóór je AI-tooling breed uitrolt. Zonder die basislijn kun je achteraf niets aantonen, en precies dát is waar de meeste discussies over AI-investeringen op stuklopen: iedereen heeft een mening, niemand heeft een grafiek van ervoor.

Splits daarna je lead time op in fases, en zet review-latency en rework-ratio ernaast. Bekijk change failure rate altijd in absolute aantallen naast het percentage.

Dit is precies het soort meting waar onze Agile Analytics-engine voor gebouwd is: DORA en SPACE naast elkaar, met de fases uitgesplitst, zodat je ziet waar je doorlooptijd werkelijk heen gaat in plaats van één samengevat getal.

AI verandert je DORA-metrics niet. Het verandert wat ze betekenen.

Deployment frequency wordt gevoeliger voor ruis. Lead time verbetert minder dan verwacht, en verschuift van schrijven naar wachten. Change failure rate wordt je belangrijkste signaal. Time to restore beweegt nauwelijks, en verraadt daarmee of je risicobeheersing is meegegroeid.

Lees ze samen, in absolute aantallen zowel als percentages, met je lead time opgesplitst. Dan meet je wat AI werkelijk heeft opgeleverd — in plaats van te vieren dat de grafiek omhoog loopt.

Projectversterking

EngineeringMetrics&ContinuousImprovement

Ontwikkelaarsondersteuning

Gerelateerd Nieuws & Artikelen

Software ontwikkelen met behulp van AI en rekening houden met AVG, NIS2 en DORA compliance

Wat dertig minuten wachten per engineer per dag echt kost

DORA-metrics lezen als AI de helft van je commits schrijft