Eindrapportage - Aanbesteding en follow-up bij medeoverheden

Augustus 2023

Vergadering: Forum Standaardisatie 13 december 2023

Agendapunt: 4A3

Documentnummer: FS-20231213.4A3

Download hier de PDF versie van dit vergaderstuk. Wij kunnen de digitale toegankelijkheid van het PDF bestand niet garanderen.

Rechten: CC0 publieke domein verklaring

Inhoudsopgave

1. Inleiding
   • Aanleiding
   • Doelen van het onderzoek
   • Onderzoeksvragen
   • Gehanteerde methodiek
   • Leeswijzer
2. De start van het aanbestedingsproces
   • Teamopbouw
   • Opstellen aanbestedingsdocumenten
3. Offertes en gunning
   • De Nota van Inlichtingen
   • Beoordeling en gunning
4. Implementatie en beheer
   • Implementatie
   • Beheerfase
5. Conclusies en aanbevelingen
   • Beantwoording onderzoeksvragen
   • Conclusies en aanbevelingen

Bijlage A Geïnterviewde personen

Bijlage B Onderzochte aanbestedingen

1. Inleiding

1.1 Aanleiding

Dit jaar heeft Bureau Forum Standaardisatie ervoor gekozen om het onderzoek naar open standaarden in GDI-voorzieningen, dat jaarlijks als onderdeel van de Monitor Open Standaarden wordt uitgevoerd, anders vorm te geven. Veel van de centrale voorzieningen die in het verleden zijn onderzocht, scoren de afgelopen jaren steeds beter als het gaat om de compliancy aan de relevante open standaarden van de ‘pas toe of leg uit’-lijst. Gecombineerd met de gedachte dat een dergelijk onderzoek ook (administratieve) lasten voor de beheerders van de voorzieningen met zich meebrengt, is gezocht naar een mogelijke andere invulling van het onderzoek naar het gebruik van standaarden.

Als gevolg hiervan is PBLQ gevraagd een onderzoek vorm te geven dat verdiepend is op het aanbestedingenonderdeel dat ook jaarlijks terugkeert in de Monitor. Bij dit onderzoek wordt gekeken of de juiste open standaarden door overheden bij ICT-aanbestedingen worden uitgevraagd. Er is voor gekozen om hier nader onderzoek naar te doen, door de rol van open standaarden in het hele aanbestedingsproces te bekijken. Onderwerp van het onderzoek zijn aanbestedingen van decentrale overheden, omdat deze in de Monitor de afgelopen jaren minder aandacht hebben gekregen.

Het onderzoeken van hoe standaarden een plek in een aanbesteding krijgen, en welk effect dat heeft op de standaarden die uiteindelijk geleverd worden, kan helpen het beleid en de instrumenten van het Forum verder aan te scherpen. Een andere doelstelling is om met dit onderzoek het belang van open standaarden en het werk van het Forum bij decentrale overheden onder de aandacht te brengen.

1.2 Doelen van het onderzoek

Specifiek zijn er voor dit onderzoek drie doelstellingen gedefinieerd die aansluiten op en voortvloeien uit het bestaande aanbestedingenonderzoek.

Leren over de opvolging van aanbestedingen

Met het huidige aanbestedingenonderzoek wordt in kaart gebracht in hoeverre de relevante open standaarden van de pas-toe-of-leg-uit-lijst worden uitgevraagd – met zichtbare ontwikkeling over tijd in percentages en verdeling Rijk-medeoverheden – en is voor de departementen uitgezocht in hoeverre het niet gebruiken van open standaarden in jaarverslagen wordt uitgelegd. Er is bestaat echter nog een witte vlek rondom de werkelijke levering: krijgen aanbestedende diensten wat ze uitgevraagd hebben, waar zijn verbeterslagen te halen, verschilt dit per standaard of soort aanbesteding? Het onderzoek kan daarmee lessen opleveren voor beleid en uitvoering.

De scope verbreden naar decentrale overheden

Buiten het domein van de Rijksoverheid valt nog veel kennis over de adoptie van open standaarden op te doen. In de Monitor is tot op heden minder sterk gefocust op decentrale overheden. Inzicht uit onderzoek en geleerde lessen kunnen hier relatief veel waarde toevoegen. Een neveneffect van deze aanpak is dat de bekendheid van het Forum en van open standaarden op decentraal niveau verder worden vergroot.

Het Forum voorzien van meer informatie en context uit de praktijk

De Monitor biedt nuttige inzichten over de uitvoering van het beleid op open standaarden. Dit geldt ook voor de opvolging van ICT-aanbestedingen met open standaarden. Het is waardevol om geleerde lessen uit de praktijk aan het Forum voor te leggen.

1.3 Onderzoeksvragen

In samenspraak met de opdrachtgever zijn de volgende onderzoeksvragen geformuleerd:

• Hoe wordt in het proces van de aanbesteding gekomen tot de wensen en eisen a.v. open standaarden?
• Speelden deze een voorname rol in de selectie van een leverancier?
• Hoe heeft de leverancier in de aanbieding aangegeven te voldoen aan de eisen en wensen a.v. open standaarden?
• Is er door de aanbestedende dienst gecontroleerd of de juiste standaarden zijn geleverd, en op welke wijze gebeurt dat?
• Welke standaarden zijn geleverd bij de implementatie van de aanbestede oplossing?
• Welke standaarden zijn niet of in onvoldoende mate geleverd?
• Wordt er gemotiveerd waarom eventueel niet voldaan is aan de eisen en wensen a.v. open standaarden, en/of beschreven hoe hier op termijn alsnog aan voldaan kan worden?
• Wat zijn de gevolgen van het niet voldoen aan de eisen en wensen a.v. open standaarden?
• Hoe wordt de opgedane kennis in het proces van aanbesteding, implementatie en gebruik binnen de organisatie geborgd?
• Welke lessen zijn te trekken uit zowel het proces als het resultaat voor het uitvragen en leveren van open standaarden in nieuwe aanbestedingen?

1.4 Gehanteerde methodiek

Voor de uitvoering van dit onderzoek zijn de volgende stappen doorlopen:

• Er is gestart met het opstellen van een lijst van criteria waaraan de te onderzoeken aanbestedingen zouden moeten voldoen. Dit zijn:
  • Implementatie: de aanbestede oplossing is al geïmplementeerd
  • Cloud: een gedeelte van de aanbestedingen betreft een cloud-oplossing
  • Spreiding bestuurslagen: een mix van aanbesteders uit verschillende decentrale bestuurslagen (gemeenten, provincies en waterschappen) en samenwerkingsverbanden
  • Score: een mix tussen aanbestedingen waar veel en weinig open standaarden zijn uitgevraagd
  • Omvang aanbesteder: een mix tussen kleine, middelgrote en grote aanbesteders op basis van inwoneraantal
  • Toetsbare standaarden: een groot aantal toetsbare standaarden in de aanbestedingen
  • ‘Outward facing’: waar mogelijk aanbestedingen met een gebruikerscomponent
  • Bijzondere standaarden: waar mogelijk een aantal aanbestedingen met standaarden voor geo, bouw, bodem en/of water, en niet alleen de beveiligingsstandaarden
• Uit een longlist van aanbestedingen uit 2018 tot en met 2021, veelal afkomstig uit de Monitors maar met enkele aanvullingen, is een shortlist samengesteld waaraan later in het proces nog extra aanbestedingen zijn toegevoegd.
• Op basis van de shortlist zijn 83 personen (22 aanbestedingen) benaderd met het verzoek om mee te werken aan dit onderzoek.
• Er zijn in totaal 15 gesprekken gevoerd over 10 aanbestedingen, waaronder: 4 van gemeenten, 4 van gemeentelijke samenwerkingsverbanden, 1 provincie, 1 waterschap, en 4 leveranciers.
  Daarnaast heeft 1 gemeentelijk samenwerkingsverband een schriftelijke reactie gestuurd. De groep respondenten betreft een samenstelling van voornamelijk projectleiders, functioneel beheerders, informatiemanagers, inkoopadviseurs, IT-architecten en enkele directeuren.
• Op basis van deze gesprekken is een analyse gemaakt hoe partijen in de verschillende fases van het aanbestedingsproces met standaarden omgaan.
• Tot slot is deze rapportage opgesteld en in concept besproken met de

Beperkingen van het onderzoek

Een van de doelen van dit onderzoek was het verkrijgen van inzicht in de wijze waarop decentrale overheden omgaan met standaarden in aanbestedingen. In dit rapport schetsen we daar een beeld van op basis van een beperkt aantal gesprekken met aanbestedende diensten en leveranciers. Dit onderzoek is daarmee kwalitatief van aard. Er is er gesproken met een brede en diverse groep overheden en leveranciers. Het is geen representatieve steekproef.

Toch kunnen we niet uitsluiten dat het resultaat gekleurd wordt doordat de partijen die bereid waren met ons te spreken, ook de partijen waren die het gebruik van standaarden al tot een bepaalde hoogte geprofessionaliseerd hebben.

1.5 Leeswijzer

De indeling van deze rapportage volgt het proces van een aanbesteding. Dat betekent dat de inhoud is ingedeeld in drie fases, zoals hieronder schematisch is weergegeven. Het procesmodel is met name bedoeld als kapstok om de bevindingen te structureren; het model beschrijft een ideaalproces. Daarbij moet dus niet vergeten worden dat een werkelijk aanbestedingsproces vaak grilliger verloopt met overlap of stappen terug, en dat er natuurlijk altijd ontwikkelingen buiten dit proces van invloed zijn.

De hoofdstukken 2, 3 en 4 beschrijven de rol van standaarden per fase. Hieronder volgt eerst een beknopte toelichting van wat er procesmatig per fase in een aanbesteding gebeurt.

Fase 1: Start aanbestedingsproces (Hoofdstuk 2)

Op het moment dat bij een decentrale overheid besloten wordt dat een project moet worden aanbesteed, start het aanbestedingsproces. Zo’n besluit volgt bijvoorbeeld omdat een contract verloopt, een huidige oplossing niet voldoet of er in algemeenheid behoefte is aan een nieuwe functionaliteit. Bij de start wordt er een team samengesteld om wensen en eisen te definiëren en/of later de offertes te beoordelen. Zie voor meer informatie Hoofdstuk 2.1.

Vanaf dan start het proces om aanbestedingswensen en -eisen te concretiseren, om op basis daarvan de relevante aanbestedingsdocumenten te kunnen opstellen. Hiertoe wordt informatie uit verschillende bronnen opgehaald. In sommige gevallen volgt eerst een marktverkenning. Soms doet men andere analyses van de situatie of van verwachte gevolgen. Hoe deze fase verloopt wordt beschreven in Hoofdstuk 2.2.

Daarna volgt de aankondiging van de betreffende aanbesteding. Dit gebeurt onder andere op het platform TenderNed, waar basisinformatie en de aanbestedingsdocumentatie beschikbaar worden gesteld aan de markt. Het belangrijkste document is het Programma van Eisen (PvE), wat naast functionele ook non-functionele eisen dicteert. Het gebruik van (open) standaarden behoort tot de laatste categorie. Andere aanbestedingsdocumenten zijn bijvoorbeeld:

• Beschrijvingen van de situatie (technische architectuurdocumentatie, lijsten van huidige oplossingen, etc.)
• Brondocumenten ter informatie (bijvoorbeeld de GIBIT)
• Visie-/beleidsstukken ter informatie
• Een beoordelingsmatrix voor de offertes
• Het Uniform Europees Aanbestedingsdocument, waarin inschrijvers hun financiële toestand en geschiktheid moeten aangeven
• Een conceptovereenkomst
• Andere te tekenen overeenkomsten, zoals op Maatschappelijk Verantwoord Ondernemen of dataverwerking

Fase 2: Offertes en gunning (Hoofdstuk 3)

Vanaf de officiële aankondiging is de markt op de hoogte (dit gebeurt uiteraard ook via informele wegen), en kunnen geïnteresseerde partijen hun vragen stellen, om een zo’n goed mogelijk beeld te krijgen wat er wordt verwacht. Om te voorkomen dat hierin informele informatie een oneerlijke rol zou kunnen spelen, dienen deze vragen gesteld en beantwoord te worden op een transparante wijze: via de Nota van Inlichtingen (NvI). Zie hiervoor Hoofdstuk 3.1.

De NvI wordt met vragen en antwoorden voor iedereen zichtbaar gepubliceerd. Het kan voorkomen dat er meerdere rondes van de Nota van Inlichtingen nodig zijn om alle vragen op te helderen, ook deze versies worden dan publiek zichtbaar. Soms wordt documentatie van de aanbestedende dienst daarop aangepast of gecorrigeerd en opnieuw geüpload.

Hierna sluit de aanbesteding, en start de aanbestedende dienst met het analyseren en beoordelen van de ingezonden offertes (en andere benodigde documenten). Hierop wordt één inschrijvende leverancier de aanbesteding gegund. De gunning wordt vervolgens publiekelijk bekend gemaakt. Deze fase wordt beschreven in Hoofdstuk 3.2.

Fase 3: Implementatie en beheer (Hoofdstuk 4)

Na de gunning start de implementatiefase, vaak aangevangen met een kick-off tussen de aanbestedende dienst en de gekozen leverancier. Gewoonlijk worden op dit moment nadere afspraken gemaakt en start de ontwikkeling van de oplossing. Voor dit gedeelte zie Hoofdstuk 4.1. Na testen, implementatie en livegang start de beheerfase van de oplossing. Hiermee eindigt het aanbestedingsproces en wordt de oplossing in regulier beheer genomen. Eventueel volgt nog een evaluatie. Deze fase wordt kort beschreven in Hoofdstuk 4.2.

Conclusies en aanbevelingen (Hoofdstuk 5)

Dit rapport eindigt met een gestructureerde beantwoording van de onderzoeksvragen op basis van de bevindingen uit de hoofdstukken 2, 3 en 4. Hierna worden enkele algemene conclusies getrokken en lessen opgetekend.

2. De start van het aanbestedingsproces

Uit de gesprekken met zowel aanbestedende partijen als leveranciers blijkt dat aanbestedingen met een ICT-component op verschillende wijzen kunnen starten, maar dat ze meestal een vergelijkbaar stramien doorlopen. In dit hoofdstuk kijken we naar de start van dat proces, de samenstelling van het team dat de aanbesteding begeleidt en het opstellen van het Programma van Eisen (PvE).

2.1 Teamopbouw

In alle situaties start het proces van de aanbestedende dienst met het samenstellen van een multidisciplinair team dat zich richt op de uitvoering van de aanbesteding. Het team is verantwoordelijk voor het opstellen van een Programma van Eisen en de verdere begeleiding van het gehele traject tot en met de gunning. De volgende rollen zijn altijd herkenbaar in dit team: naast een projectleider (die soms extern wordt ingehuurd) bevat het team medewerkers die expertise hebben op het gebied van inkoop (soms heel specifiek van het inkopen van ICT) en van het beoogd gebruik en de gewenste functionaliteit (superusers, maar ook functioneel beheerders van de applicaties). Daarnaast bevatten de teams tegenwoordig ook altijd leden met specifieke kennis van de ICT-kaders, eisen en wensen die bij de aanbestedende dienst gelden. Vaak gaat het om medewerkers van het CIO-office, de afdeling informatiemanagement en/of de ICT-afdeling.

Het aantal mensen met kennis en ervaring op gebied van informatiemanagement en informatieprocessen varieert – soms betreft dit alleen een informatieadviseur, vaak worden ook architecten en specialisten met kennis van de huidige ICT betrokken. In de meeste gevallen gaat het om interne medewerkers van de aanbestedende dienst. In slechts een enkel geval bleek het nodig om specialistische kennis apart in te huren voor de begeleiding van de aanbesteding.

In algemene zin valt dus op dat bij het samenstellen van het team dat de aanbesteding begeleidt, rekening is gehouden met het belang van eisen die betrekking hebben op de meer technische aspecten (waaronder standaarden) uit het Programma van Eisen.

Uit gesprek

IT-architect: “Bij grote aanbestedingen komen ze niet meer om ons heen.”

Het werken met een team waarin de verschillende disciplines vertegenwoordigd zijn, wordt in de verschillende gesprekken gezien als een groot goed. Een voordeel van deze manier van werken is dat de verschillende belangen bij een aanbesteding goed belicht kunnen worden in het Programma van Eisen. Een aantal gesprekspartners geeft aan dat die belangen soms in strijd met elkaar kunnen zijn. Denk aan eisen ten aanzien van functionaliteit of gebruiksgemak en aan de andere kant eisen ten aanzien van de beveiliging of de juiste toepassing van standaarden. Het team heeft dan een afweging te maken. Die afweging wordt beïnvloed door de individuele kennis, belangen en overtuigingskracht

van de afzonderlijke teamleden en de onderlinge interactie. Bij wisselende teamsamenstellingen kunnen de keuzes dan ook verschillend uitpakken, waardoor in sommige gevallen eisen ten aanzien van standaarden minder hard of niet worden opgenomen.

Uit gesprek

Medewerker Inkoop: “Bij een volgende aanbesteding vond de functioneel beheerder eenzelfde mate van beveiliging niet nodig. De projectleider ging daar toen in mee.”

2.2 Opstellen aanbestedingsdocumenten

Zoals hiervoor aangegeven vraagt de aanbesteding van een technische oplossing om een afweging tussen functionele en technische eisen. Daarnaast spelen er natuurlijk zaken als prijs en benodigde capaciteit, tijd of overtuigingskracht. De eisen worden samengebracht in het Programma van Eisen.

Om invulling te geven aan het Programma van Eisen maken de gesproken aanbestedende diensten als basis meestal gebruik van een set generieke eisen en wensen. Ze werken aan een document dat bestaat uit verschillende bouwblokken. Vaak wordt daarbij gebruik gemaakt van bouwblokken uit eerdere aanbestedingen. Deze worden aangevuld met informatie van de teamleden en geconsulteerde afdelingen, waarbij de samenwerking en verhoudingen mede bepalend zijn (zie vorige paragraaf). In sommige gevallen laten aanbestedende diensten begeleiden door adviesbureaus die gespecialiseerd zijn in contracten en aanbestedingen. Ook dan wordt er gewerkt vanuit een standaard-bestek.

Daarnaast wordt geput uit een breed scala aan bronnen en bestaande kaders, zowel interne als externe. Voor het bepalen en uitvragen van standaarden worden vaak de volgende bronnen genoemd:

• Eerdere documenten van aanbestedingen die opnieuw gebruikt worden. Deze zijn handig omdat de afwegingen daarin al gemaakt zijn. Het risico is dat ze niet langer actuele eisen bevatten, en/of niet helemaal van toepassing zijn.
• Enkele respondenten hebben genoemd dat ze eerst een interne analyse uitvoeren om tot non-

functionele eisen te komen voor de gewenste oplossing. Dit kan bijvoorbeeld door het doen van een impactanalyse of het intekenen van de gewenste situatie op een architectuurplaat.

• De respondenten beroepen zich in de meeste gevallen op informatie en tooling afkomstig van een

koepel: VNG, IPO of de Unie van Waterschappen.

• Van de VNG gebruikt men vaak de Gemeentelijke Inkoop bij IT Toolbox (GIBIT). Dit zijn uniforme voorwaarden voor technische aanbestedingen, met een checklist van ‘gemeentelijke kwaliteitsnormen ICT’ en een overeenkomstengenerator. Beide geven de mogelijkheid om te filteren t.b.v. een specifieke situatie.
  • Daarnaast verwijzen aanbestedende diensten vaak naar de Gemeentelijke Modelarchitectuur (GEMMA): een landelijke referentiearchitectuur voor gemeenten die, net als de Common Ground-principes, meer als richtlijn dan als over te nemen voorwaarde dient.
  • Onderdeel van De Informatiebeveiligingsdienst (IBD) is een schakelpunt met landelijke cybersecuritypartijen en opsteller van richtlijnen.
  • De Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG) van de IBD wordt soms als bron genoemd.
• Aangezien we maar één provincie en één waterschap hebben gesproken kunnen we moeilijk aangeven welke informatiebronnen daar het meest worden De volgende zijn in de twee gesprekken de revue gepasseerd:
  • De Algemene Rijksinkoopvoorwaarden bij IT‑overeenkomsten (ARBIT).
  • Het
  • De Algemene Waterschapsvoorwaarden bij IT-overeenkomsten (AWBIT).
  • De Cybersecurity Implementatierichtlijn (CSIR). Deze is speciaal ontwikkeld om objecten als waterzuiveringsinstallaties, gemalen, bruggen, keringen en sluizen te beveiligen.
• De Baseline Informatiebeveiliging Overheid (BIO) komt vaak voor in aanbestedingen als normenkader. Een respondent vindt de BIO te abstract om direct toe te passen op een gemeentelijk project.
  • De Inkoopeisen Cybersecurity Overheid (ICO) dienen soms als een specifiekere toepassing: deze uitwerking kan gezien worden als een algemene en kleinere GIBIT en wordt soms genoemd.
• Het Centrum Informatiebeveiliging en Privacybescherming (CIP) heeft enkele tools ontwikkeld op bovenstaande documenten.
  • De ICO-Wizard, een invultool op de
  • De Privacy Baseline, een variant op de
  • Twee zelfbeoordelingstools: het Privacy Self Assessment (PriSA) en het BIO Self Assessment (BIO-SA). Deze zijn niet door respondenten genoemd.
• Het Forum Standaardisatie wordt vaak in aanbestedingsdocumenten als bron
  • Dit geldt vooral voor de pas-toe-of-leg-uit-lijst die meestal integraal wordt opgenomen, maar geen verdere specificering krijgt. De aanbestedende partij vraagt dan om standaarden van de lijst te gebruiken “voor zover van toepassing”.
  • Enkele respondenten geven aan de beslisboom van het Forum te gebruiken ter specificering. Ze ervaren dit als waardevol.
• Het Nationaal Cybersecuritycentrum (NCSC) heeft een aantal richtlijnen ontwikkeld, die een enkele keer in een Programma van Eisen voorkomen. Eén onderzochte aanbesteding bevat hiervoor een Een voorbeeld is de ICT-beveiligingsrichtlijn voor webapplicaties.

Tot slot wordt soms gebruikt gemaakt van een marktconsultatie, voorafgaand aan de start van de aanbesteding. Daarin wordt marktpartijen gevraagd wat zij van belang achten, en wat een aanbestedende dienst van de markt mag verwachten.

Het samenbrengen van deze kaders - waarbij verschillen moeten worden afgewogen en de toepasbaarheid op de gewenste oplossing moeten worden bestudeerd, is vaak lastig. Respondenten geven aan dat er veel informatie bestaat van allerhande partijen en dat het veel tijd en moeite vergt om dit samen te brengen tot een samenhangend geheel. 
Vooral het actueel houden wordt daarbij als een moeilijkheid ervaren.

Uit gesprek

Informatieadviseur: “Na verloop van tijd zijn in het basisdocument met inkoop steeds meer bronnen terechtgekomen. Eigendom en beheer van dit document is grijs gebied.”

Het gevolg van deze veelheid aan broninformatie is dat aanbestedende diensten vaak liever te veel dan te weinig eisen in de aanbestedingsdocumenten opnemen. Dit leidt soms tot irritatie bij leveranciers, omdat die vinden dat lang niet alle opgenomen standaarden relevant en toepasselijk zijn voor de gewenste oplossing. Volgens gesproken leveranciers missen aanbestedende partijen soms de kennis en expertise om een gerichte vertaalslag te maken van de algemene kaders naar de specificaties van de oplossing.

Uit gesprek

Leverancier: “Je vraagt een Rolls- Royce, maar je zoekt eigenlijk naar een degelijke Volkswagen.”

De algemene uitdaging bij het uitvragen kan als volgt worden samengevat: hoe vraag je als aanbestedende dienst een oplossing uit waarin je de levering van standaarden conform de gestelde eisen, op de juiste prioritering, zo waarschijnlijk mogelijk maakt? Iets vragen betekent namelijk niet dat het te krijgen is. En hele harde eisen toevoegen, kan ook de ruimte wegnemen voor andere effectieve middelen om eenzelfde te bereiken.

Partijen maken hierin hun eigen afwegingen. Dat kan soms ook betekenen dat ze afwijken van de bestaande kaders. Zo worden sommige relevante standaarden niet gevraagd als ze verwachten dat de markt die niet kan leveren, of als ze deze zelf geen waarde vinden toevoegen.

Uit gesprek

Projectleider: “Bijvoorbeeld IPv6 en ODF, ik zie niet in waarom we deze zouden uitvragen, en ik verwacht ook niet dat ze echt geleverd worden.”

Hoe de uiteindelijke eisen en wensen ten aanzien van standaarden landen in het programma van eisen kan sterk verschillen. We zien de volgende vormen terugkomen:

• Een eis om te voldoen aan bestaande kaders, met een verwijzing daarnaar. Zo wordt vaak verwezen naar de GIBIT, of naar de ‘pas toe of leg uit’-lijst van het Forum Standaardisatie.
• Een eis ten aanzien van het gebruik van een concrete standaard of een set aan Standaarden. Bijvoorbeeld een opsomming van de relevante beveiligingsstandaarden.
• In aanvulling op bovenstaande zijn in een enkel geval eisen gesteld aan de wijze waarop aangetoond moet worden dat voldaan wordt. Daarmee wordt de eis verder geconcretiseerd.

Uit gesprek

IT-architect: “We hebben een addendum gemaakt op de ARBIT. Met daarbij een invulformulier waarmee een leverancier kan aangeven hoe voldaan wordt aan de eisen.”

In de aanbestedingsdocumentatie zien we deze verschillende vormen gecombineerd terugkomen. Meestal somt de aanbestedende dienst een kort lijstje met een aantal specifieke standaarden op, en wordt daarnaast geëist dat de leverancier aan een algemeen kader voldoet.

Daarnaast ziet men een trend om vaker gebruik te maken van meer open vragen, zoals:

• Vragen hoe de leverancier van plan is om het achterliggende doel van een standaard of een set standaarden (bijvoorbeeld interoperabiliteit met andere systemen) te bereiken, nog los van de harde eis voor het gebruik van een specifieke standaard. Deze vragen ondervangen bijvoorbeeld het probleem dat een leverancier wel de letter volgt (de standaard implementeert), maar toch de achterliggende wens (bijvoorbeeld interoperabiliteit) niet invult.
• Vragen over hoe de leverancier op termijn denkt te voldoen aan (nieuwe) relevante standaarden en hoe de leverancier denkt om te gaan met standaarden die niet eenvoudig in te passen zijn.

Ten slotte kan worden opgemerkt dat het soort oplossing dat wordt aanbesteed, bijvoorbeeld cloud of on-premise, geen wezenlijke invloed heeft op de manier waarop en het type standaarden dat wordt uitgevraagd. De huidige inrichting van het ICT-landschap van een aanbestedende dienst heeft wel invloed op de (koppel)standaarden die gebruikt kunnen worden. De legacy die is opgebouwd met oudere systemen beperkt de mogelijkheid om nieuwe standaarden te gebruiken als deze systemen niet backward compatible zijn. Dit komt vaak pas in de implementatiefase aan het licht.

3. Offertes en gunning

In deze fase is de aanbesteding met het PvE uitgezet en is het aan leveranciers om een offerte uit te brengen. Leveranciers krijgen de mogelijkheid tot het stellen van vragen voordat de offertes definitief gemaakt worden. Wanneer de uitgebrachte offertes eenmaal door de aanbestedende dienst ontvangen zijn, start de beoordeling, en wordt overgegaan op gunning.

3.1 De Nota van Inlichtingen

Uit de gevoerde gesprekken komt naar voren dat leveranciers weinig gebruik maken van de mogelijkheid om vragen te stellen. Daarvoor worden de volgende redenen gegeven:

• Vaak zijn de eisen en wensen ten aanzien van standaarden dusdanig dat leveranciers er eigenlijk geen vragen over De standaarden zijn vaak bekend en vormen daarmee zelden een drempel, of de eisen en wensen zijn onvoldoende specifiek en laten daarmee ruimte voor interpretatie om zo te voldoen aan de eisen en wensen.
• Een tweede beeld dat naar voren kwam is dat het maar beperkt zin heeft om vragen te stellen omdat bij leveranciers de verwachting is dat de aanbestedende dienst geen aanvullende informatie kan verstrekken. Eén leverancier geeft aan alleen vragen te stellen als gestelde eisen niet verenigbaar met elkaar zijn. Dat kan gebeuren als de aanbestedende dienst te weinig gericht eisen aan het bestek toevoegt, dus zonder oog te hebben voor de relevantie.

Uit gesprek

Leverancier: “9 van de 10 keer krijg je niks zinnigs terug op een vraag, soms blijkt dat de klant gewoon een oude aanbesteding heeft gekopieerd en geplakt.”

Daarnaast leeft bij een aantal partijen het beeld dat leveranciers eigenlijk altijd aangeven te kunnen voldoen aan de eisen en wensen. Het stellen van vragen maakt dan meestal weinig uit, en kan zelfs vanuit tactisch oogpunt onhandig zijn omdat het antwoord het mogelijk ingewikkelder kan maken om aan te geven dat aan de eisen en wensen voldaan wordt.

3.2 Beoordeling en gunning

Na de fase van de Nota van Inlichtingen worden de offertes uitgebracht en moeten deze beoordeeld worden door de aanbestedende dienst. Net als bij het opstellen van het PvE maken de meeste aanbestedende diensten gebruik van een multidisciplinair team. De verschillende onderdelen van de offertes worden door verschillende disciplines beoordeeld.

In de gesprekken die wij hebben gevoerd komt naar voren dat in deze fase geen enkele offerte sneuvelt op basis van de eisen en wensen ten aanzien van standaarden.

Een belangrijke reden daarvoor is dat partijen bijna altijd aangeven te kunnen voldoen aan de gestelde eisen en wensen. Aanbestedende diensten zeggen daar wel eens twijfels over te hebben, bijvoorbeeld als partijen in het verleden niet konden voldoen, en nu opeens aangeven wel te kunnen voldoen. Tegelijkertijd wordt aangegeven dat in deze fase het minder van belang is om de uitspraken van partijen te toetsen; dat komt na gunning. In deze fase is vooral van belang dat de leverancier zich in zijn/haar aanbod committeert aan de gestelde eisen en wensen.

Uit gesprek

IT-architect: “De BIO is uitgebreid en leveranciers vinken snel aan dat ze voldoen. Gemeenten hebben toch geen capaciteit om te controleren.”

Tot slot geldt dat voor een deel van de vragen nauwelijks mogelijk is om te controleren of eraan voldaan wordt. Dat geldt bijvoorbeeld voor een eis als “u voldoet aan de relevante standaarden”. Zonder nadere specificatie is op voorhand niet aan te geven of wordt voldaan, noch door de leverancier in het aanbod, noch door de aanbestedende dienst bij het controleren van dat aanbod.

Dit is niet alleen lastig voor aanbestedende diensten, maar ook voor leveranciers. Zo kwam in een gesprek naar voren dat het vervelend is voor leveranciers die hun best doen de juiste standaarden te implementeren (en daar geld en capaciteit aan besteden), om te verliezen van leveranciers waarvan bekend is dat ze eigenlijk niet voldoen, maar die wel een vinkje hebben gezet bij alle eisen. Het kan het beeld oproepen dat je als beste jongetje van de klas gestraft wordt. Overigens zijn er in dit onderzoek geen voorbeelden gevonden waarbij leveranciers tegen de uitslag van aanbestedingen in beroep zijn gegaan door het starten van een gerechtelijke procedure.

Uit gesprek

Projectleider: “Er werd gedreigd met gerechtelijke stappen: het bedrijf had het openbare proof-of-concept van de winnende concurrent getest op gebruik van de gevraagde veiligheidsstandaarden, en geconcludeerd dat daaraan niet werd voldaan.”

4. Implementatie en beheer

Vanaf gunning start de fase waarin de oplossing gerealiseerd wordt. In dit hoofdstuk kijken we naar de rol van open standaarden in de implementatiefase, en in de opvolgende beheerfase.

4.1 Implementatie

Na gunning start het implementatietraject meestal met een kick-off tussen de leverancier en het team dat de implementatie begeleidt. Hierin zit vaak overlap met het team dat het PvE heeft geschreven en beoordeeld. Aangezien hier de praktische uitvoering wordt besproken ligt de focus op werkbaarheid, gebruiksvriendelijkheid en op het technisch functioneren van de oplossing. Als een oplossing nog niet helemaal voldoet aan de eisen en wensen – bijvoorbeeld ten aanzien van het gebruik van standaarden – worden afspraken gemaakt over hoe en wanneer wel wordt voldaan. Een leverancier geeft aan dat het langslopen van de eisen en wensen, en de wijze waarop daaraan voldaan wordt, vooral in de eerste fase gebeurt. De aandacht voor open standaarden is in zijn ervaring later in de implementatie minder aanwezig.

De gesproken aanbestedende diensten gebruiken verschillende manieren om in de eerste fase tot livegang te controleren op compliancy aan standaarden.

• Ten eerste zijn de standaarden ten behoeve van koppelingen relatief makkelijk te testen: in de meeste gevallen werkt een functie simpelweg niet als de koppelstandaard niet goed geïmplementeerd is. In feite is dit vooral een indirecte controle doordat bij implementatie blijkt dat iets niet werkt.
• Ten tweede geeft een gemeente aan pentesten uit te voeren om veiligheidsmaatregelen - waaronder standaarden daarvoor - te controleren zodra de oplossing geïmplementeerd
• Als laatste wordt gebruik gemaakt van tooling zoals nl. Respondenten zeggen dat aan deze laatste optie ook nadelen kleven. De tooling geeft een goede eerste indicatie waar op gelet moet worden, maar er is nog steeds veel kennis benodigd om die indicatie op waarde te schatten.

Uit gesprek

Leverancier: “Bij de start maken we met iedere klant een projectplan dat we later kunnen gebruiken bij het testen in de acceptatiefase en de decharge.”

De meeste van de gesproken partijen geven aan dat ze beperkt dit soort testen in deze fase uitvoeren. Soms wordt het initiatief door de leverancier genomen. Die wil na afloop van een implementatieproject decharge verleend krijgen. Ten behoeve hiervan stelt deze leverancier een acceptatieplan op waarin per onderdeel wordt opgeschreven of de leverancier de eisen uit de aanbesteding is nagekomen.

Maar het minutieus nagaan of elke eis op open standaarden in de levering wordt nagekomen lijkt in de onderzochte aanbestedingen zelden te gebeuren. Zelfs aanbestedende diensten die aangeven het gebruik en uitvragen van standaarden goed te hebben geborgd, geven toe dat hier nog aanzienlijke verbeterpunten liggen. Er komen in de gesprekken een aantal redenen hiervoor terug:

• Het gebrek aan tijd en kennis om dit soort controles goed uit te voeren bij het team.
• Bij de implementatie worden – net zoals bij het opstellen van het PvE – pragmatische afwegingen gemaakt. De focus ligt dan vaak op het werkend krijgen van het systeem en het meenemen van de gebruikers daarin en daarmee minder op de overige eisen uit het PvE.
• De betrokkenheid van andere mensen dan die de eisen hebben opgesteld.  Dit geldt nog sterker voor de beheerfase, zie paragraaf 4.2.

Uit gesprek

Informatieadviseur: “Wij zijn grote voorstander van standaardisatie, maar het is soms een hele kluif om standaarden te kennen en toe te passen.”

Als tijdens deze fase gebreken worden geconstateerd dan gaat het meestal over interpretatieverschillen over de eisen uit het PvE. Bij een enkele aanbestedende dienst ging het daarbij ook over standaarden, maar de meeste geschillen raakten aan andere eisen. Soms kiest een aanbestedende dienst om de harde lijn aan te houden en het volledige te blijven eisen. Verschillende respondenten geven aan dat dit op managementniveau gesteggel met de uitvoerder opleverde over kosten, en dat het zoeken naar een exacte uitvoering van iedere wens veel extra tijd kostte. Een andere geïnterviewde geeft aan dat zijn organisatie niet de capaciteit heeft om aanbestedingen erg te vertragen of op te blazen.

Uit gesprek

Functioneel beheerder: “De standaard was alleen geïmplementeerd voor uitwisseling, maar we konden er zelf geen bestanden mee registreren.”

In de meeste gevallen wordt er samen naar een oplossing gezocht. Pragmatisme voert hierbij de boventoon. In tegenstelling tot de vorige fases is hierbij minder aandacht voor de specifieke (juridische) eisen die in het bestek hebben gestaan. Een voorbeeld dat we hebben teruggehoord is dat een deel van de oplossing nog niet helemaal klaar was. Er is toen voor gekozen om de deadline voor livegang aan te houden maar een component later toe te voegen. De meerkosten worden dan meestal gedeeld. De belangrijkste les is dat het open gesprek tussen een leverancier en de klant het beste werkt. Daarbij is vooral van belang dat dit gesprek vroeg in het traject opgestart wordt, en dat het doel voorop staat.

Uit gesprek

Functioneel beheerder: “We hadden de eis dat de software moest kunnen printen. Die werd ingevuld door een omslachtige conversie optie waarna we het bestand via een ander programma konden afdrukken.”

Aanbestedende partijen zitten niet op discussies en uitstel te wachten. Gesteggel over interpretatie zorgt ervoor dat de aanbestedende dienst hun aanbestedingsdocumentatie verder proberen aan te scherpen of dicht te timmeren. Je ziet dat de uitvoeringsfase (met controle) en de startfase (met het opstellen van eisen) elkaar daarmee continu voeden. Het Programma van Eisen moet ruimte laten voor het open gesprek en tegelijkertijd specifiek genoeg anticiperen op de offerte- en uitvoeringsfases. Daarbij zal mindere controle in de implementatie daarna de effectiviteit van een volgend Programma van Eisen verlagen, omdat inschrijvers dan minder verwachten hun antwoorden te hoeven bewijzen. De vraag uit hoofdstuk 2 blijft dus essentieel: ‘hoe vraag je als aanbestedende dienst een oplossing uit waarin je de levering van de eisen, op de juiste prioritering, zo waarschijnlijk mogelijk maakt?’

4.2 Beheerfase

In deze fase is het proces van de aanbesteding en de implementatie afgerond. Daarmee is de borging van het gebruik van standaarden aangekomen in het reguliere beheerproces van de gehele set aan ICT-middelen. De transitie van ontwikkeling naar beheer betekent dat de verantwoordelijkheden verschuiven. In het doorlopende proces van beheer en beveiliging kunnen standaarden die achterblijven of wegvallen worden opgemerkt. In de interviews zijn daar eigenlijk geen voorbeelden van naar voren gekomen.

De betrokkenheid van andere mensen betekent wel een complicerende factor bij het controleren van de standaarden. In de beheerfase lijkt er bij geen onderzochte aanbesteding nog aandacht voor het periodiek controleren op eisen uit het PvE. Ten eerste zijn er geen inkopers meer betrokken die op de juridische plicht hameren voor leveranciers om beloofde standaarden te leveren. Ten tweede is er sprake van een hoog verloop binnen de organisatie: aanbestedingen zijn vaak langdurige trajecten, waardoor de mensen die de eisen hebben opgesteld vertrokken kunnen zijn als erop gecontroleerd moet worden. Dit is genoemd in een groot aantal gesprekken.

Uit gesprek

Leverancier: “Gemeenten controleren amper, en hebben vaak te weinig kennis of expertise.”

5. Conclusies en aanbevelingen

5.1 Beantwoording onderzoeksvragen

Op basis van de voorgaande hoofdstukken kunnen de onderzoeksvragen als volgt worden beantwoord.

Vraagstelling Antwoord

Hoe wordt in het proces van De wensen en eisen t.a.v. open standaarden worden ingebracht door de aanbesteding gekomen de informatieadviseur in het (multidisciplinaire) aanbestedingsteam. tot de wensen en eisen Deze persoon wordt geacht kennis van de relevante ICT-kaders met t.a.v. open standaarden? daarin open standaarden te hebben. Er zijn uiteenlopende kaders om uit te putten. Vooral de hulpmiddelen van de koepels (VNG, IPO of Waterschapshuis) worden vaak genoemd. Aanbestedende diensten geven aan dat de belangrijkste uitdaging erin bestaat om de relevante en toepasselijke standaarden uit de diverse kaders te bepalen. Het maken van die afweging vergt speciale expertise. Een drietal keer is aangegeven dat de aanbestedende dienst ter ondersteuning van het selectieproces gebruik maakt van de beslisboom van het Forum, maar deze is ook niet alomvattend.

Speelden open Open standaarden spelen geen doorslaggevende rol in de keuze van standaarden een voorname een specifieke leverancier of oplossing. Dat komt onder meer doordat rol in de selectie van een leveranciers in de regel aangeven aan de eisen en wensen van open leverancier? standaarden te voldoen. Het is dus geen gegeven waar leveranciers onderscheidend ten opzichte van elkaar in zijn. Het feit dat leveranciers doorgaans aangeven te voldoen betekent overigens niet dat dit in de praktijk ook altijd zo is.

Hoe heeft de leverancier in In alle onderzochte aanbestedingen hebben leveranciers aangegeven te de aanbieding aangegeven zullen voldoen aan de wensen en eisen t.a.v. open standaarden. De te voldoen aan de eisen en leverancier volgt de uitvraagstructuur van het programma van eisen. Er wensen t.a.v. open zijn verschillende manieren waarop aanbestedende partijen eisen en standaarden? wensen met open standaarden in het programma van eisen uitvragen. Dat varieert tussen het opnemen van een eis om te voldoen aan bepaalde kaders tot een eis ten aanzien van het gebruik van een specifieke standaard. In een enkel geval wordt van leveranciers gevraagd om toe te lichten hoe ze aan de eisen gaan voldoen.

Is er door de Er vindt geen grondige controle door aanbestedende diensten plaats of aanbestedende dienst de uitgevraagde standaarden ook zijn geleverd. Tijdens de gecontroleerd of de juiste aanbestedingsfase vertrouwt de aanbestedende dienst op de standaarden zijn geleverd, (juridische) waarborg van de aanbestedingsdocumenten waarin de en op welke wijze gebeurt leverancier aangeeft te voldoen aan uitgevraagde standaarden. dat?

Na gunning wordt tijdens de implementatiefase niet expliciet toegezien of de standaarden worden geleverd die zijn toegezegd. Een pragmatische aanpak om de oplossing werkend te krijgen, staat voorop. Indirect wordt wel op het juiste gebruik van standaarden toegezien. Voor koppelstandaarden blijkt in het praktisch gebruik of de standaard goed is geïmplementeerd door na te gaan of de informatie op een juiste manier binnenkomt. De controle op de implementatie van beveiligingsstandaarden volgt uit reguliere beveiligingstesten (zoals penetratietesten) die soms worden gedaan

Welke standaarden zijn Over het algemeen worden de meeste door de aanbestedende dienst geleverd bij de uitgevraagde standaarden ook geleverd, ook al wordt daar niet expliciet implementatie van de en stelselmatig op toegezien. In dit onderzoek kunnen daarom geen aanbestede oplossing? uitspraken worden gedaan over specifieke standaarden die in mindere Welke standaarden zijn niet mate worden geleverd. Wel kan in algemene zin worden gezegd dat of in onvoldoende mate leveranciers de geëiste kaders niet altijd minutieus volgen of naar eigen geleverd? interpretatie gebruiken. ODF en IPv6 zijn voorbeelden van standaarden die wel in lijsten en kaders staan opgenomen (en dus als zodanig worden gevraagd), maar lang niet altijd worden geleverd, soms ook omdat de aanbestedende dienst er geen gebruik van maakt.

Wordt er gemotiveerd Er zijn in dit onderzoek geen gevallen aangetroffen waarin de waarom eventueel niet leverancier beredeneerd afwijkt van een eis t.a.v. open standaarden. Er voldaan is aan de eisen en zijn wel gevallen gehoord waarin tijdens de implementatiefase wensen t.a.v. open interpretatieverschillen tussen de aanbestedende dienst en de standaarden, en/of leverancier ontstaan over de wijze van implementatie. Soms is de beschreven hoe hier op geëiste standaard wel naar de letter gebruikt, maar is de beoogde termijn alsnog aan voldaan uitkomst daarmee niet bereikt. De beste oplossing is om er via een kan worden? open gesprek samen uit te komen door te kijken of de leverancier naar de geest van de wensen van een aanbestedende partij kan leveren.

Wat zijn de gevolgen van Een juiste implementatie van de uitgevraagde standaard of het niet voldoen aan de informatiemodel is vaak cruciaal voor het goed werken van de beoogde eisen en wensen t.a.v. open oplossing. Er kunnen meningsverschillen ontstaan wat de juiste standaarden? implementatie inhoudt. Daar moet vaak in een iteratief proces tussen de partijen worden uitgekomen. Er zijn in dit onderzoek geen aanbestedingen gevonden waar men er onderling niet is uitgekomen.

Hoe wordt de opgedane Er zijn bij de onderzochte aanbestedingen geen lessen ontleend aan de kennis in het proces van manier waarop standaarden in het aanbestedingsproces worden aanbesteding, uitgevraagd. Lessen of verbeteringen worden hoofdzakelijk implementatie en gebruik gesuggereerd naar aanleiding van aanbestedingen waar achteraf binnen de organisatie onvrede over bestaat, bijvoorbeeld vanwege een geschil met de geborgd? leverancier. In die gevallen wordt nagedacht hoe het aanbestedingsproces in de toekomst beter kan worden ingericht, bijvoorbeeld door nog explicieter over de eisen te zijn in het programma van eisen. Zulke verbeteringen leiden tot nieuwe versies van een bouwblokkendocument dat bij de start van nieuwe aanbestedingen ter hand wordt genomen.

5.2 Conclusies en aanbevelingen

Bij deze laatste paragraaf is het goed de beperkingen van dit onderzoek in acht te nemen. We hebben slechts een beperkt aantal partijen bevraagd. Ondanks onze inzet om zo’n divers mogelijke groep aan interviewpartners te spreken (zie paragraaf 1.4 voor selectiegronden) kan niet worden uitgesloten dat de partijen die bereid waren het gesprek aan te gaan ook de partijen zijn die dit onderwerp van belang vinden. Dit kan de uitkomsten mogelijk (mede)beïnvloeden en is goed om mee te nemen bij het waarderen van de beschreven conclusies en aanbevelingen.

De eerste bevinding is dat alle gesproken partijen aangeven het belangrijk te vinden om (open) standaarden in aanbestedingen uit te vragen. De aanbestedende diensten begrijpen wat de voordelen zijn om met open standaarden te werken. Interoperabiliteit en leveranciersonafhankelijkheid worden als belangrijkste argumenten genoemd.

Daarnaast worden (open) standaarden ook steeds beter in het reguliere aanbestedingsproces geborgd. Dat is af te leiden uit een aantal zaken. In de eerste plaats wordt er steeds meer gewerkt in multidisciplinaire teams waarin expliciet kennis van informatieprocessen en informatiemanagement wordt betrokken, bijvoorbeeld via rollen als de informatieadviseur, architect of security-officer. In de tweede plaats is er een grote bekendheid van aanbestedende diensten met bestaande kaders en richtlijnen waarin (open) standaarden staan opgenomen. Deze worden in aanbestedingsdocumenten overgenomen, waardoor open standaarden hier automatisch deel van uitmaken. Dit moet overigens niet zijn doel voorbijstreven als aanbestedende diensten uit gemak de kaders integraal opnemen in de aanbestedingsdocumentatie. Leveranciers klagen dat zo’n ongerichte strategie al snel zorgt voor onverenigbare eisen in de praktijk die leveranciers niet kunnen nakomen.

In de laatste plaats wordt de kennis en expertise van rollen als de CIO, CISO en informatiemanagers steeds vaker buiten het formele aanbestedingsproces betrokken, bijvoorbeeld na gunning tijdens de implementatiefase. Ook dit zorgt ervoor dat het werken met open standaarden in nieuwe ICT- oplossingen steeds gangbaarder wordt.

Niet alleen aan de kant van de aanbestedende dienst wordt het belang van open standaarden herkend. Ook leveranciers spreken dit uit en gebruiken open standaarden in de producten die ze

aanbieden. Dit volgt onder meer uit het feit dat geen van de onderzochte aanbestedingen is afgevallen op non-conformiteit aan de uitgevraagde standaarden. Het is voor leveranciers normaal geworden om deze te leveren.

Samengevat kan worden gesteld dat uitvragen en leveren van open standaarden in aanbestedingen door decentrale overheidspartijen steeds beter wordt geborgd.

Beperkingen en uitdagingen

Dat betekent niet dat het altijd goed gaat. Er bestaan verschillen in de mate waarin het goed uitvragen van standaarden bij partijen geborgd is. Dit heeft vooral vandoen met de volwassenheid en professionaliteit van de organisatie. Grote organisaties hebben vaak meer middelen, kennis en expertise om dit goed aan te pakken dan kleinere. Daarnaast zijn er enkele algemene uitdagingen waar alle partijen tegenaan lopen.

De belangrijkste uitdaging voor een aanbestedende dienst is om bij de uitvraag van een nieuwe oplossing de levering van standaarden conform de gestelde eisen, op een juiste prioritering, zo waarschijnlijk mogelijk te maken. Dit klinkt evident, maar is complexer dan het lijkt. Het voorschrijven van de juiste eisen in de aanbestedingsdocumenten vraagt om specifieke vaardigheden bij de aanbestedende partij. Het vraagt onder meer om kennis over standaarden, kennis over welke standaarden in welke situatie relevant zijn en een inschatting of het gevraagde ook door de markt geleverd kan worden. Het toevoegen van aanvullende eisen sorteert daarin niet altijd het gewenste effect. Aanvullende eisen kunnen in sommige gevallen zelfs de ruimte voor leveranciers wegnemen om met andere middelen hetzelfde doel (effectiever en efficiënter) te bereiken. Daarnaast hebben aanvullende eisen niet het gewenste effect als een aanbestedende dienst niet kan controleren of ze worden geleverd. Dan ontstaat het risico dat leveranciers per definitie in hun aanbieding aangeven te voldoen.

Een inzicht uit het onderzoek is dat het gebruik van standaarden niet te veel als einddoel moet worden neergezet. Het werken met standaarden is complexer dan het aflopen van een vinkenlijstje.

Aanbestedende diensten doen er goed aan om het uitvragen van standaarden in de context van de bedoeling van de oplossing te beschrijven. Dat vraagt om het nader beschrijven van de bedoeling: met welk breder doel wil je standaarden gebruiken? Een aanbestedende dienst kiest bijvoorbeeld voor een specifieke koppelstandaard, met als doel om interoperabiliteit met systeem X, Y, Z te bereiken.

Door deze werkwijze wordt de standaard in verband gebracht met de doelstelling die ermee wordt nagestreefd, waarmee leveranciers beter kunnen bepalen wat ze daarin kunnen aanbieden en wat niet. De conclusie die hieruit kan worden afgeleid: standaarden zijn een middel om een bredere doelstelling te behalen, en moeten in relatie hiertoe worden uitgelegd en uitgevraagd in de aanbesteding.

In het onderzoek zijn verschillende mooie voorbeelden genoemd hoe je dat als aanbestedende dienst in de praktijk kan doen. Een voorbeeld is een combinatie van open en gesloten vragen in het Programma van Eisen. Een ander is het helder maken en omschrijven wat het achterliggende doel is van het uitvragen van een standaard is. Ten slotte helpt ook het open gesprek tussen de aanbestedende dienst en een leverancier (na gunning) aan het begin van de implementatiefase om de geest van de oplossing en gebruik van standaarden daarbinnen over het voetlicht te brengen.

Variëteit aan informatiebronnen en kaders

Bij het uitvragen van open standaarden in aanbestedingen wordt volop gebruikt gemaakt van bestaande informatiebronnen en kaders. Veel van de gesproken partijen geven aan dat het een extra uitdaging is om uit de veelheid aan kaders, bronnen en lijstjes met standaarden een juiste selectie te maken. Onder paragraaf 2.2 staat opgesomd welke informatiebronnen in de praktijk allemaal worden gebruikt. In zekere mate bestaat er ook overlap in informatie tussen de kaders. Het is voor aanbestedende diensten moeilijk om de inhoud van al deze kaders te kennen en de laatste ontwikkelingen te volgen, terwijl ze voor hun gevoel ieder relevant en belangrijk zijn.

Al met al resulteert dit in een situatie waarin aanbestedende diensten tijd en moeite moeten steken in het samenbrengen en combineren van al deze informatie. Het meest sprekende voorbeeld in dit verband is de provincie Zeeland die als gevolg van de verscheidenheid een addendum heeft opgesteld waarin diverse elementen zijn samengebracht. Dit kan echter niet van alle partijen worden verwacht, omdat het specifieke kennis en tijd vergt. De algemene conclusie luidt daarom dan ook dat aanbestedende diensten worstelen met het bepalen van relevantie uit de grote hoeveelheid aan kaders en informatiebronnen waar standaarden in terugkomen.

Aanbevelingen voor Forum Standaardisatie

Het feit dat aanbestedende diensten diverse andere kaders en informatiebronnen dan de pas-toe-of- leg-uit-lijst gebruiken, is ook relevant voor Forum Standaardisatie. Het Forum wil bekendheid van de eigen open standaarden bij decentrale overheden vergroten. Daarom strekt het tot aanbeveling dat ze daarvoor niet alleen eigen communicatiekanalen inzet, maar de bekendheid daarnaast via andere kanalen moet promoten. De belangrijkste zijn de koepels (VNG, IPO en het Waterschapshuis) en het NCSC.

De tweede aanbeveling luidt dat Bureau Forum Standaardisatie meer zichtbaarheid en ruchtbaarheid kan geven aan de eigen hulpmiddelen voor decentrale overheden. Concreet gaat het om (1) de beslisboom op de website die helpt bij het bepalen van de relevante standaarden voor een bepaalde oplossing en (2) de handreiking ‘open standaarden bij ICT’ waarin de mogelijkheden staan benoemd hoe overheden kunnen toetsen op conformiteit aan gestelde eisen. Beide instrumenten zijn waardevol gegeven de algemene uitdagingen waar decentrale overheden in het aanbestedingsproces bij het uitvragen van standaarden tegenaan lopen. Maar de instrumenten zijn bij deze partijen maar in beperkte mate tot niet bekend. Hier is dus nog zeker een potentieel te benutten.

Bijlage A Geïnterviewde personen

Datum	Organisatie	Rol of functie
24-5-2023	Gemeente Moerdijk	Functioneel beheerder openbare ruimte
30-5-2023	Gemeente Maastricht	Functioneel beheerder
1-6-2023	Gemeente Oss /RBL BNO	Inkoper ICT
1-6-2023	Gemeente Oss /RBL BNO	IT-architect
5-6-2023	Provincie Zeeland	IT-architect
12-6-2023	Samenwerking A2- gemeenten	Strategisch adviseur I&A
12-6-2023	Werkorganisatie De BUCH	Informatieadviseur
12-6-2023	Gemeente Delft (I.s.m. Pijnacker-Nootdorp)	Projectleider
14-6-2023	Werkmaatschappij 8KTD (& Tytsjerksteradiel)	Projectleider / adviseur Informatie & Organisatie
14-6-2023	Gemeente Maastricht	Projectleider
22-6-2023	Waterschap Hollandse Delta	Inkoopadviseur
23-6-2023	Metaobjects	Directeur / medeoprichter
23-6-2023	Coöperatie Dimpact	Adviseur ICT & innovatie
27-6-2023	Gemeente Lelystad	Informatiemanager
27-6-2023	Gemeente Lelystad	Adviseur IT-architectuur
6-7-2023	Betawerk	Lead developer
18-7-2023	Genetics	Directeur / medeoprichter
19-7-2023	xxlnc	Afdelingsdirecteur

Bijlage B Onderzochte aanbestedingen

Aanbestedende dienst	Onderwerp volgens TenderNed	Startdatum volgens TenderNed	Aantal gevoerde gesprekken	Link TenderNed
Werkmaatschappij 8KTD	ICT-applicaties Belastingen, Financiën (optioneel), BAG, Burgerzaken, GBA-V en VOA en gegevensdistributie(centrum)	1-10-2018	1	Klik
Gemeente Maastricht	Vervanging corporate website gemeente Maastricht	Medio 2019	3	Klik
Gemeente Oss /RBL BNO	Europees Openbare aanbesteding leerlingvolgsysteem	1-1-2021	2	Klik
Gemeente Moerdijk	Beheer Openbare Ruimte (BOR) systeem Gemeente Moerdijk	1-11-2020	1	Klik
Gemeente Delft (I.s.m. Pijnacker-Nootdorp)	Vervanging VTH- vergunningensoftware i.v.m. invoering Omgevingswet voor de gemeente Delft en gemeente Pijnacker-Nootdorp	15-4-2020	2	Klik
Coöperatie Dimpact UA	Open Inwoner Platform	Eind 2021	1	Klik
Waterschap Hollandse Delta	Purchase 2 Pay oplossing	15-7-2019	1	Klik
Provincie Zeeland	Systeem voor zaakgericht werken	15-7-2019	2	Klik
Werkorganisatie De BUCH	Integraal Systeem Sociaal Domein (Regie- en Backofficefunctionaliteit in éénsysteem)			Klik
Gemeente Lelystad	Belastingapplicatie	1-9-2021	1	Klik
Samenwerking A2- gemeenten	Aanbesteding Burgerzaken- applicatie GRSA2	Medio 2020	0 (schriftelijke reactie)	Klik