Bij het onderhandelen over maatwerksoftwareprojecten zijn de meest gangbare eenheden waarop partijen A en B afstemmen «personeelsdagen» : hoeveel ingenieurs, hoeveel dagen, tegen welk tarief. Dit model werkt goed wanneer de eisen stabiel zijn en de leveringsgrenzen duidelijk zijn; zodra de regels ter plaatse vaak veranderen, AI‑tools de programmeerefficiëntie verhogen, maar partij A toch blijft afgaan op «personeelsstapel», ontstaan er conflicten — partij B vindt dat de eisen uitdijen, terwijl partij A denkt: «er is niet minder personeel ingezet, maar er is ook niet meer gedaan».
Beleidsindicatie: van verkopen van personeelsaantallen naar verkopen van resultaten
In september 2026 publiceerde het Ministerie van Industrie en Informatietechnologie het «Implementatieplan voor de speciale actie “Kunstmatige Intelligentie + Software”», waarin herhaaldelijk wordt gesproken over het bevorderen van een transformatie van het softwareproductiemodel en de ontwikkeling van «Model-as-a-Service» en «Agent-as-a-Service», met als doel om tegen 2028 in belangrijke sectoren benchmarktoepassingen van agent‑software te creëren. Het document ontkent maatwerkontwikkeling niet, maar geeft een duidelijke richting aan: bij het beoordelen van de waarde van software wordt steeds meer gekeken naar de concrete resultaten, in plaats van alleen naar het aantal personeelsdagen dat is ingezet .
Voor bedrijven die ERP-, MES-, CRM- of branchesystemen ontwikkelen, betekent dit dat als in het contract nog steeds alleen staat: «XX personen × XX dagen», men na de implementatie gemakkelijk vastloopt in discussies als «de code is klaar, maar de bedrijfsprocessen werken niet». Een duurzamere manier van formuleren is om de levering op te splitsen in verifieerbare zakelijke resultaten .
Zakelijke logica: mijlpalen moeten concreter zijn dan personeelsdagen
Zet het project om van «betaling per fase» naar «betaling per mijlpaal»; elke mijlpaal moet tegelijkertijd voldoen aan vier voorwaarden:
- Bedrijfsscenario’s : wie gebruikt het, welke handelingen worden hiermee opgelost (bijvoorbeeld «magazijnmedewerker scant barcode bij binnenkomst» in plaats van «module voor binnenkomst voltooid»).
- Datavastlegging : welke masterdata, statusvelden en toegangsrechten zijn betrokken, en wat zijn de bemonsteringsregels.
- Acceptatietestscript : met gegeven testgegevens, welke processen moeten worden doorlopen en welke documenten of rapporten moeten worden gegenereerd.
- Uitzonderingsbehandeling : hoe reageert het systeem bij mislukking, wie heeft het recht om aanpassingen door te voeren en of er sporen worden achtergelaten.
Mijlpalen mogen niet langer zijn dan 2–4 weken per stuk; te lang en je keert terug naar «zwarte doos‑ontwikkeling». Typisch voorbeeld van opsplitsing: masterdata en toegangsrechten → sluiting van kerndocumenten → rapportages en afstemming → interfaces en omschakeling naar productie.
Ontwerpprincipe: scope, wijzigingen en «intelligente assistentie» in het contract opnemen
AI‑geassisteerd coderen, automatisch testcases genereren, intelligente documenten aanvullen—dit verandert de hoeveelheid personeelsdagen voor dezelfde functionaliteit, maar verandert niet automatisch de bedrijfscomplexiteit . In het contract en de specificaties van de eisen wordt daarom aanbevolen om apart op te nemen:
- Scope‑baseline : lijst met functies + lijst van zaken buiten de scope (Out of Scope); wijzigingen moeten via een wijzigingsformulier gaan.
- Regels voor prijsberekening van wijzigingen : nieuwe mijlpalen worden gewaardeerd op basis van «scenario + acceptatietestscript», in plaats van tijdelijk extra personeelsdagen toe te voegen.
- Grenzen van intelligente assistentie : welke fasen kunnen worden versneld met AI (codegeneratie, conceptdocumenten), en welke moeten nog steeds handmatig worden goedgekeurd (veiligheid, compliance, externe toezeggingen).
- Toewijzing van kennis en documentatie : wie bezit de procesdocumenten, configuraties en scripts, om te voorkomen dat er na de levering een breuk ontstaat in de operationele ondersteuning.
Implementatie van ontwikkeling: automatisering van acceptatie en observabiliteit
Om «resultaatgerichtheid» uitvoerbaar te maken, moet de technische kant drie zaken ondersteunen:
- Acceptatietests in de database : elk mijlpaal krijgt een set geautomatiseerde of semi‑geautomatiseerde tests, die herhaaldelijk kunnen worden uitgevoerd.
- Isolatie van omgeving en data : UAT‑omgevingsgegevens kunnen worden gereset, om te voorkomen dat iets «alleen in de demo‑omgeving werkt».
- Observabele logs : cruciale handelingen hebben auditlogs, zodat bij geschillen kan worden nagegaan wie wat heeft aangepast.
Als het project intelligent agents of een regelengine bevat, moet de acceptatie worden uitgebreid met een steekproefmechanisme : willekeurig invoeren van grenscasussen om te controleren of weigeringen, escalaties naar menselijk toezicht en toegangsbeperkingen voldoen aan het ontwerp, in plaats van alleen te kijken of «het kan chatten».
Drie veelvoorkomende soorten geschillen en preventie
Geschil nummer één: «Alle functies zijn gedaan, waarom gebruikt de bedrijfsvoering ze niet?» — Preventie: koppel mijlpalen aan werkzaamheden per functie en trainingsregistratie; tijdens de acceptatie loopt men ter plaatse langs de werkplekken, niet alleen demonstreren met PPT.
Geschil nummer twee: «Waarom moet ik extra betalen voor een kleine aanvraag?» — Preventie: schrijf in het wijzigingsformulier duidelijk welke mijlpalen, scripts en deadlines worden beïnvloed, en laat beide partijen ondertekenen voordat er wordt doorontwikkeld.
Geschil nummer drie: «AI heeft de efficiëntie verhoogd, kunnen we dan de personeelsdagen verminderen?» — Preventie: het contract onderscheidt «implementatiekosten» van «bedrijfscomplexiteit»; de winst van efficiëntieverhoging kan worden weergegeven in de totale prijs of de doorlooptijd, maar de acceptatiecriteria worden niet versoepeld.
Pilotadvies: begin met één gesloten module
Wacht niet op een volledig systeem om het contract te herschrijven. Kies een module die in 2–3 weken kan worden gesloten (zoals in- en uitgaande goederen, werkbonnen, kostenvergunningen), en gebruik een nieuw sjabloon om een aanvullend contract te ondertekenen: vermeld scenario’s, scripts, uitzonderingen en betalingsmomenten. Na succesvolle doorloop kan het vervolgens op het hele project worden uitgerold. Om te beoordelen of het gelukt is, kijk naar of het aantal wijzigingsformulieren is afgenomen en daarmee de tijd voor discussies is verminderd , en naar of de slagingsgraad van de UAT‑testen is gestegen , in plaats van te kijken hoeveel personeelsdagen partij B minder heeft gerapporteerd. Als de pilotmodule goed gekozen is, zal het contract voor het hele project veel overtuigender zijn.
Personeelsdagen verdwijnen niet van de ene dag op de andere, maar ze veranderen van «enige prijseenheid» naar «referentie voor kostenraming». Mijlpalen en acceptatietests in het contract opnemen is de basisvaardigheid waarmee maatwerksoftware in het kader van «Kunstmatige Intelligentie + Software» nog steeds betrouwbare resultaten kan leveren.
Samenwerking met vaste totaalprijzen en agile iteraties
Mijlpaalacceptatie sluit agile niet uit: elke Sprint kan nog steeds demonstrabele incrementele resultaten leveren, maar betaling en officiële acceptatie hangen aan een grotere mijlpaal. Bij contracten met vaste totaalprijzen moet vooral duidelijk worden gemaakt «waar de scope wordt bevroren» — na welke evaluatie extra eisen via een wijzigingsformulier moeten worden ingediend, om mondelinge toevoegingen van functionaliteit te voorkomen. Voor modules met intelligente agents wordt aanbevolen om aparte mijlpalen te accepteren op basis van «regelversie + doorstroompercentage van steekproeven», in plaats van alles samen te binden met de lancering van het hele systeem.
Branchecijfers tonen aan dat ongeveer een derde van softwareprojecten faalt vanwege onduidelijke eisen en acceptatiecriteria, en niet vanwege de technische realisatie zelf. Eerst vastleggen «wat ‘voltooid’ betekent» in het contract is waardevoller dan discussiëren over hoeveel programmeurs AI heeft vervangen. Bij de volgende projectbeoordeling kan men eerst vragen: als morgen alle medewerkers van partij B op vakantie zijn, kunnen we dan aan de hand van het script beoordelen of de huidige mijlpaal voldoet — als het antwoord ontbreekt, betekent dit dat de acceptatie nog niet duidelijk genoeg is gedefinieerd. Mijlpalen in het contract opnemen is geen moeilijkheid voor partij B, maar een manier om beide partijen op dezelfde pagina te laten discussiëren over «is het nu echt af?». Vooral bij projecten waar AI de efficiëntie duidelijk verhoogt, is het des te belangrijker om dit van tevoren duidelijk te maken.