Het combineren van een Dynamisch Aankoopsysteem (DAS) met een softwarebroker kan een sterke inkoopconstructie zijn voor standaardsoftware, licenties en aanverwante dienstverlening. Maar de constructie wordt vaak te gemakkelijk voorgesteld als een eenvoudige manier om snel en goedkoop software te kopen.
Dat is onjuist.
Een DAS en een softwarebroker lossen twee verschillende problemen op. Het DAS organiseert mededinging en toegang tot de markt. De broker kan vervolgens marktkennis, licentie-expertise, administratieve ondersteuning en commerciële inkoopkracht leveren. Zodra die functies door elkaar gaan lopen, ontstaan aanbestedingsrechtelijke en governance-risico's.
Mijn oordeel is daarom positief, maar onder voorwaarden: een broker kan binnen een DAS een nuttige marktintermediair zijn, maar mag niet de concurrentie vervangen die het DAS juist moet organiseren.
1. Wat een DAS juridisch eigenlijk is
Artikel 2.48 Aanbestedingswet 2012 bepaalt dat een aanbestedende dienst een DAS kan instellen voor gangbare aankopen van werken, leveringen of diensten waarvan de kenmerken wegens de algemene beschikbaarheid op de markt aan de behoeften van de aanbestedende dienst voldoen. De wet bepaalt bovendien dat bij de instelling van het DAS de niet-openbare procedure wordt toegepast, met uitzondering van de inschrijvingsfase.[1]
Dat sluit aan bij artikel 34 van Richtlijn 2014/24/EU. Daarin wordt een DAS omschreven als een volledig elektronisch systeem voor courant beschikbare aankopen, dat gedurende de volledige geldigheidsduur openstaat voor iedere ondernemer die aan de selectiecriteria voldoet.[2]
Dat laatste is essentieel.
Een DAS is geen gesloten raamovereenkomst met een vooraf geselecteerd aantal leveranciers. Het systeem blijft gedurende zijn looptijd open voor nieuwe ondernemers die aan de voorwaarden voldoen.
De Nederlandse Aanbestedingswet werkt dit verder uit. Bij de instelling toetst de aanbestedende dienst onder meer uitsluitingsgronden en geschiktheidseisen en laat hij ondernemers die aan de voorwaarden voldoen toe tot het systeem.[1] Voor een concrete opdracht binnen het DAS moeten de toegelaten ondernemers worden uitgenodigd om een inschrijving in te dienen.[1]
Dat betekent dat het DAS zelf het mechanisme vormt waarmee concurrentie wordt georganiseerd.
2. Waarom software en licenties goed bij een DAS kunnen passen
Standaardsoftware heeft een aantal kenmerken die goed aansluiten bij het DAS-concept.
Denk aan:
standaard SaaS-licenties;
kantoorsoftware;
ontwerp- en engineeringsoftware;
securitysoftware;
database- en developmenttools;
aanvullende licenties;
tijdelijke licenties;
standaard onderhoud;
standaard support;
uitbreidingen van bestaande software.
De behoefte is vaak fluctuerend. Vandaag zijn bijvoorbeeld 250 licenties nodig, volgend jaar 400 en een jaar later misschien 300.
Daarnaast verandert de markt snel. Nieuwe licentiemodellen, cloudabonnementen, bundels en prijsstructuren verschijnen voortdurend.
Daarmee ontstaat precies het soort situatie waarin een DAS voordelen kan bieden: je hoeft niet bij het instellen van het systeem alle toekomstige concrete aankopen tot op productniveau vast te leggen.
Maar hier zit meteen een grens.
Niet iedere softwareopdracht is geschikt voor een DAS.
Een complexe ERP-transformatie, maatwerkontwikkeling of een opdracht waarbij de oplossing nog gezamenlijk met de markt moet worden ontwikkeld, is niet zonder meer een "gangbare aankoop" in de zin van artikel 2.48.[1][2]
Mijn praktische vuistregel:
Hoe meer je weet wat je wilt kopen en hoe volwassener en breder de markt, hoe interessanter een DAS wordt. Hoe meer je samen met de markt moet ontdekken wat je eigenlijk nodig hebt, hoe minder geschikt een DAS wordt.
3. Waar de softwarebroker daadwerkelijk waarde kan toevoegen
Een broker kan een probleem oplossen dat bij software bijzonder groot is: de markt is enorm versnipperd.
Een organisatie kan honderden softwareproducten gebruiken. Iedere fabrikant heeft eigen:
licentievoorwaarden;
kortingsstructuren;
resellerkanalen;
volumemodellen;
abonnementsvormen;
renewalvoorwaarden;
supportmodellen;
prijsindexaties.
Een goede broker kan die markt ontsluiten.
De broker kan bijvoorbeeld:
1. de behoefte vertalen naar een concrete softwarevraag;
2. controleren welke licentievorm passend is;
3. meerdere geautoriseerde distributiekanalen benaderen;
4. marktprijzen vergelijken;
5. volumekortingen benutten;
6. alternatieve licentiemodellen identificeren;
7. licentieadministratie verzorgen;
8. renewaldata bewaken;
9. ongebruikte licenties signaleren;
10. rapporteren over de totale software-uitgaven.
Dat is niet slechts theoretisch.
Een recent voorbeeld is de aanbesteding van Alliander. Alliander publiceerde in 2025 een Europese openbare aanbesteding voor een raamovereenkomst met een softwarebroker voor de levering van standaardsoftwarelicenties en aanverwante dienstverlening. De geraamde waarde bedroeg €3 miljoen, terwijl in de publicatie een maximale waarde van €350 miljoen voor de raamovereenkomst werd genoemd.[3]
Een ander interessant voorbeeld is de gemeente Dronten. Daar werd een softwarebroker gecontracteerd die verantwoordelijk is voor het leveren van licenties en/of gebruiksrechten en dienstverlening rond software. De broker moet een breed assortiment kunnen leveren en fungeren als centraal aanspreekpunt. De geraamde waarde van de raamovereenkomst bedroeg €20 miljoen.[4]
De gemeente Halderberge koos eveneens voor een raamovereenkomst met één softwarebroker. In de aanbestedingspublicatie wordt de broker nadrukkelijk omschreven als intermediair en strategisch partner, deskundige en belangenbehartiger richting de softwaremarkt.[5]
Dat laatste is interessant, maar ook gevaarlijk.
Hoe meer strategische invloed de broker krijgt, hoe zwaarder de governance moet worden ingericht.
4. De belangrijkste correctie: een broker is geen concurrentiemechanisme
Hier moet een onderscheid worden gemaakt dat in de praktijk gemakkelijk wordt vertroebeld.
Stel:
Gemeente X heeft een DAS voor software.
Broker A is toegelaten.
Gemeente X heeft 500 Microsoft-licenties nodig.
Broker A vraagt vervolgens bij Microsoft-resellers drie prijzen op.
Je zou kunnen zeggen:
Er zijn drie offertes opgevraagd, dus er is concurrentie.
Dat is te kort door de bocht.
De aanbestedingsrechtelijk relevante concurrentie binnen het DAS vindt plaats tussen de tot het DAS toegelaten ondernemers die voor de betreffende opdracht worden uitgenodigd.[1][2]
De drie resellers die de broker vervolgens benadert, zijn niet noodzakelijk de deelnemers aan het DAS.
Dat zijn twee verschillende concurrentielagen:
Laag 1
Aanbestedende dienst → toegelaten DAS-deelnemers.
Laag 2
DAS-deelnemer/broker → eigen distributie- en leveranciersnetwerk.
Laag 2 kan commerciële meerwaarde opleveren. Maar laag 2 vervangt laag 1 niet.
Dat is een fundamenteel punt.
Als de aanbestedende dienst een opdracht binnen het DAS aan alle relevante toegelaten ondernemers uitzet, kan een broker vervolgens zijn eigen distributieketen benutten om zijn aanbieding commercieel samen te stellen.
Maar als de opdrachtgever feitelijk alleen de broker benadert en zegt:
Zoek voor ons drie leveranciers en geef ons de goedkoopste,
dan is de vraag of het DAS nog daadwerkelijk als aanbestedingsmechanisme functioneert.
Je hebt dan mogelijk een brokerconstructie met een cosmetisch DAS gecreëerd.
Dat zou ik nadrukkelijk vermijden.
5. De meest interessante variant: DAS + meerdere brokers
Als je concurrentie maximaal wilt benutten, is er een nog interessantere constructie denkbaar.
Je kunt een DAS instellen waarin meerdere softwarebrokers kunnen worden toegelaten, mits zij aan de vooraf vastgestelde selectievoorwaarden voldoen.
Bij een concrete behoefte worden vervolgens alle voor de categorie toegelaten deelnemers uitgenodigd.
Daarmee krijg je bijvoorbeeld:
Organisatie
↓
DAS categorie "standaardsoftware"
↓
Broker A
Broker B
Reseller C
Softwareleverancier D
↓
concrete uitvraag
↓
beste aanbieding
Dan concurreert de broker zelf op de opdracht.
Dat is naar mijn oordeel aanbestedingsrechtelijk en economisch sterker dan één exclusieve broker, tenzij er zwaarwegende redenen zijn om voor één broker te kiezen.
De keerzijde is administratieve complexiteit.
Je moet dan bijvoorbeeld bepalen:
wie welke software mag leveren;
hoe autorisaties worden gecontroleerd;
hoe fabrikantspecifieke voorwaarden worden behandeld;
hoe marges worden vergeleken;
hoe support wordt geregeld;
wie verantwoordelijk is voor licentiecompliance.
Daarom is één broker niet per definitie verkeerd.
Maar dan moet je de keuze voor één broker functioneel en economisch kunnen verdedigen.
6. Het gevaar van vendor lock-in
Software is geen gewone commodity.
Een aanbestedende dienst kan vandaag een ogenschijnlijk concurrerende aankoop doen en zichzelf daarmee voor jaren vastzetten.
Voorbeeld:
Een organisatie koopt een softwarepakket voor €100.000.
De initiële prijs is scherp.
Maar vervolgens ontstaan:
hoge migratiekosten;
verplichte onderhoudscontracten;
proprietary interfaces;
gesloten dataformaten;
hoge exitkosten;
vendor-specifieke kennis;
jaarlijkse prijsverhogingen.
Na vijf jaar blijkt overstappen vrijwel onmogelijk.
Dan was de initiële aanbesteding misschien succesvol, maar het contractmanagement niet.
Daarom dienen softwareaanbestedingen niet alleen op aanschafprijs te worden beoordeeld.
Kijk naar Total Cost of Ownership (TCO):
aanschaf + implementatie + licenties + onderhoud + support + beheer + integratie + migratie + exit.
Een broker kan hier juist waarde toevoegen, omdat hij licentie- en marktkennis kan inbrengen.
Maar opnieuw: de opdrachtgever moet zelf de regie houden.
7. De harde les uit de recente rechtspraak
De meest relevante waarschuwing komt wat mij betreft uit het vonnis van de Rechtbank Den Haag van 23 december 2025, ECLI:NL:RBDHA:2025:27115.[6]
De zaak ging over aanbestedingen van standaardprogrammatuur en gerelateerde dienstverlening.De rechtbank verplichtte de Staat de aanbestedingen te staken totdat de voorwaarden waren aangepast omdat sprake was van disproportionele voorwaarden en omdat de procedures anders niet aan de geldende wet- en regelgeving voldeden.[6]
Bijzonder relevant voor softwarebrokers is de discussie over het sublicentiemodel.
De Staat wilde werken met een constructie waarbij de reseller contracteerde met de aanbestedende dienst, terwijl de softwarerechten via de fabrikant/vendor konden lopen.
De resellers voerden aan dat fabrikanten niet bereid waren hun medewerking te verlenen aan de voorgestelde sublicentiestructuur.
De rechtbank maakte daar een zeer belangrijke observatie:
de Staat had onvoldoende marktonderzoek gedaan om aannemelijk te maken dat vendors daadwerkelijk bereid waren de standaardprogrammatuur onder het gekozen sublicentiemodel aan te bieden.[6]
Dat is een les die rechtstreeks toepasbaar is.
Je kunt niet volstaan met:
Volgens onze broker kan dit.
Je moet weten:
Kan de markt dit daadwerkelijk leveren onder de voorwaarden die wij gaan voorschrijven?
Dat vraagt om serieus marktconsultatie- en marktonderzoek.
8. Positief gebruik van een broker: zo zou ik het inrichten
Ik zou de verantwoordelijkheden expliciet scheiden.De aanbestedende dienst bepaalt:
de behoefte;
de functionele eisen;
de technische randvoorwaarden;
security-eisen;
privacy-eisen;
architectuur;
licentiebudget;
gunningscriteria;
contractvoorwaarden;
risicotolerantie.
De broker adviseert over:
marktontwikkelingen;
licentievarianten;
beschikbaarheid;
prijsniveaus;
volumekortingen;
alternatieve leveranciers;
renewal;
licentieoptimalisatie.
De broker mag niet zelfstandig bepalen:
welke leverancier de opdrachtgever nodig heeft;
welke fabrikant wordt bevoordeeld;
welke alternatieve oplossingen niet worden onderzocht;
welke commerciële marge redelijk is;
welke aanbieder uiteindelijk wordt geselecteerd.
Die laatste beslissingen moeten onder de governance van de opdrachtgever vallen.
9. De grootste valkuil: belangenverstrengeling
Een broker kan tegelijk:
adviseren;
leveren;
commissie ontvangen;
korting ontvangen;
reseller zijn;
fabrikantrelaties onderhouden.
Dat maakt transparantie essentieel.
Ik zou daarom contractueel eisen dat de broker inzicht geeft in:
inkoopprijs;
verkoopprijs;
opslag;
kortingen;
rebates;
eventuele vendor incentives;
referral fees;
resellerbonussen;
overige financiële voordelen.
Anders kan de opdrachtgever onmogelijk beoordelen of:
€1.000.000 aan software
daadwerkelijk marktconform is.
Een broker die zegt:
Ik heb de beste prijs geregeld
moet dat kunnen bewijzen.
Niet met een PowerPoint, maar met controleerbare marktinformatie.
10. Praktijkvoorbeeld: Saxion
Saxion is een interessant aanvullend voorbeeld.
In de aanbestedingspublicatie uit 2025 beschrijft Saxion dat het ongeveer 200 verschillende softwareapplicaties gebruikt. Het contractbeheer voor licentie- en IT-gerelateerde overeenkomsten is gecentraliseerd binnen Leveranciers- en Contractmanagement. Saxion koopt sommige licenties via SURF en organiseert voor andere licenties afzonderlijke Europese of meervoudig onderhandse aanbestedingen.[7]
Saxion wilde met een softwarebroker een aanvullend inkoopkanaal voor standaardsoftware creëren.[7]
Dat vind ik een veel sterkere benadering dan:
Alles moet voortaan via de broker.
Een broker hoeft namelijk niet het volledige software-inkoopmodel over te nemen.
Je kunt verschillende kanalen naast elkaar laten bestaan:
SURF;
DAS;
broker;
Europese aanbesteding;
raamovereenkomst;
directe fabrikantrelatie waar rechtmatig en noodzakelijk.
Dat voorkomt dat de broker een monopolistische positie krijgt binnen de organisatie.
11. Wanneer een DAS beter is dan een broker
Voor sommige softwarecategorieën zou ik juist géén broker centraal stellen.
Bijvoorbeeld wanneer:
de fabrikant zelf rechtstreeks levert;
slechts enkele geautoriseerde resellers bestaan;
de licentievoorwaarden fabrikantgebonden zijn;
de marktprijs transparant is;
de opdracht strategisch belangrijk is;
directe vendoronderhandeling noodzakelijk is.
Een DAS kan dan rechtstreeks met relevante marktpartijen concurreren.
Andersom kan een broker zeer nuttig zijn bij:
honderden verschillende standaardproducten;
veel kleine licentieaankopen;
sterk fluctuerende behoeften;
veel verschillende resellers;
ingewikkelde kortingsstructuren;
veel renewals;
hoge administratieve lasten.
De keuze moet dus voortkomen uit de economische en marktstructuur, niet uit de wens om één aanbestedingsmodel overal op toe te passen.
12. Mijn grootste bezwaar tegen de standaard-brokerconstructie
Er is één fundamenteel risico dat naar mijn mening onvoldoende wordt onderkend.
De broker kan de organisatie afhankelijker van de markt maken terwijl hij tegelijkertijd beweert de markttoegang te verbeteren.
Dat klinkt paradoxaal, maar het kan gebeuren.
De organisatie besteedt eerst de brokerfunctie aan.
Vervolgens laat zij de broker alle software inkopen.
Daarna heeft de organisatie steeds minder eigen kennis over:
prijzen;
fabrikanten;
licentievoorwaarden;
alternatieven;
marktontwikkelingen;
contractuele risico's.
Na enkele jaren weet alleen de broker nog hoe het geheel werkt.
Dan heb je geen ontzorging meer.
Dan heb je kennisuitbesteding.
Dat is iets heel anders.
Daarom dient contractmanagement expliciet te voorkomen dat de broker een black box wordt.
13. Mijn aanbevolen model
Voor een overheidsorganisatie die veel standaardsoftware aanschaft, zou ik de volgende architectuur serieus onderzoeken:
-
DAS
▶ voor de concurrentie en toegang tot de markt.
Softwarebroker(s)
▶ als gespecialiseerde marktintermediair en mogelijke DAS-deelnemer.
Directe fabrikantrelaties
▶ waar dat economisch, technisch of juridisch noodzakelijk is.
Strategische software
▶ via afzonderlijke aanbesteding wanneer de aard en complexiteit daarom vragen.
Contract- en licentiemanagement
▶ intern bij de opdrachtgever, eventueel ondersteund door de broker maar niet volledig uitbesteed.
Dat geeft een veel gezondere verhouding tussen markt, broker en opdrachtgever.
14. Checklist voor de aanbestedende dienst
Voor je deze constructie toepast, zou ik minimaal de volgende vragen beantwoorden:
Is de software daadwerkelijk een gangbare aankoop in de zin van artikel 2.48?[1]
Is een DAS inhoudelijk geschikter dan een raamovereenkomst?
Welke categorieën software worden onderscheiden?
Welke ondernemers kunnen redelijkerwijs toetreden?
Worden alle relevante toegelaten deelnemers voor concrete opdrachten uitgenodigd?[1]
Is de broker zelf deelnemer aan het DAS of wordt hij afzonderlijk gecontracteerd?
Wie is juridisch de leverancier?
Wie verleent het gebruiksrecht?
Wie is verantwoordelijk voor licentiecompliance?
Wie bepaalt de productkeuze?
Wie bepaalt de prijs?
Welke marge mag de broker rekenen?
Zijn rebates en vendor incentives transparant?
Is voldoende marktonderzoek uitgevoerd?
Zijn leveranciers daadwerkelijk bereid de gewenste constructie te leveren?
Hoe wordt vendor lock-in voorkomen?
Hoe wordt TCO beoordeeld?
Hoe wordt exit geregeld?
Hoe worden security en privacy geborgd?
Hoe wordt voorkomen dat kennis volledig bij de broker terechtkomt?
Conclusie
Het positieve gebruik van een softwarebroker binnen een DAS is goed verdedigbaar en kan economisch zeer interessant zijn, maar alleen wanneer de rollen scherp worden gescheiden.
Het DAS moet de mededinging organiseren.
De broker moet de markt ontsluiten.
De opdrachtgever moet de behoefte en governance bepalen.
Het contractmanagement moet de prestaties, prijzen, licenties, risico's en afhankelijkheden controleren.
De grootste fout zou zijn om te denken:
De broker vraagt meerdere offertes op, dus wij hebben concurrentie.
Dat is onvoldoende.
De betere gedachte is:
Wij organiseren concurrentie via het DAS en gebruiken de broker vervolgens om de complexe softwaremarkt efficiënter, deskundiger en transparanter te ontsluiten.
Dat verschil is juridisch én economisch wezenlijk.
De recente uitspraak van de Rechtbank Den Haag maakt bovendien duidelijk dat bij standaardsoftware niet alleen moet worden gekeken naar wat de aanbestedende dienst juridisch op papier kan voorschrijven. Er moet worden onderzocht of de markt het voorgeschreven model daadwerkelijk kan leveren.[6]
Daarmee kom ik op een harde aanbeveling: doe vooraf een serieus marktonderzoek naar de softwareketen, resellerstructuur, fabrikantvoorwaarden en licentiemodellen. Ontwerp daarna pas het DAS en de brokerfunctie.
Wie eerst de broker kiest en daarna probeert de aanbestedingsconstructie eromheen te bouwen, draait de volgorde om.
Dat is precies hoe je uiteindelijk een juridisch kwetsbare én economisch ondoorzichtige software-inkoop creëert.
Bronnen
[1] Aanbestedingswet 2012, artikelen 2.48–2.50.
De wettelijke bepalingen over instelling, toelating en het plaatsen van opdrachten binnen een DAS.
[2] Richtlijn 2014/24/EU, artikel 34 – Dynamische aankoopsystemen.
De Europese basis voor het DAS: courant beschikbare aankopen, volledig elektronisch en gedurende de looptijd open voor iedere ondernemer die aan de selectiecriteria voldoet.
[3] TenderNed – Alliander N.V., Software Broker, procedure T152531.
Europese openbare procedure voor een raamovereenkomst met een softwarebroker voor standaardsoftwarelicenties en aanverwante dienstverlening. Geraamde waarde €3 miljoen; maximale waarde €350 miljoen.
[4] Gemeente Dronten – Softwarebroker.
Gegunde Europese aanbesteding voor één softwarebroker als centraal aanspreekpunt voor softwarelicenties en dienstverlening; geraamde en maximale waarde €20 miljoen.
[5] Gemeente Halderberge – Softwarebroker.
Aanbesteding voor één softwarebroker als intermediair en strategisch partner richting de softwaremarkt. De publicatie beschrijft tevens de rol bij een toekomstbestendig en beheersbaar applicatielandschap.
[6] Rechtbank Den Haag, 23 december 2025, ECLI:NL:RBDHA:2025:27115.
Relevant vonnis over aanbestedingen van standaardprogrammatuur en gerelateerde dienstverlening. De rechtbank oordeelde onder meer dat de Staat onvoldoende had onderbouwd dat vendors bereid waren standaardprogrammatuur onder het voorgeschreven sublicentiemodel aan te bieden en verlangde gedegen marktonderzoek.
[7] Saxion – Softwarebroker (levering standaardsoftware).
Aanbestedingspublicatie waarin Saxion beschrijft dat het circa 200 softwareapplicaties gebruikt, licentie- en contractmanagement heeft gecentraliseerd en een softwarebroker wil inzetten als aanvullend inkoopkanaal voor standaardsoftware.
[8] PIANOo – Dynamisch aankoopsysteem.
Algemene uitleg over het DAS en de toepassing ervan in het Nederlandse aanbestedingsproces.
[9] Regionale Uitvoeringsdienst Limburg Noord – Softwarebroker.
Praktijkvoorbeeld van een softwarebroker voor het doorleveren van vrij verkrijgbare softwarelicenties, standaard onderhoudscontracten en gerelateerde dienstverlening en advisering.
Bronkritische opmerking: [1], [2] en [6] zijn de zwaarste bronnen voor de juridische analyse. [3], [4], [5], [7] en [9] zijn vooral praktijkvoorbeelden.
