Informatielevering in de uitvraag: waar moet je aan denken?

24-02-2020
Op 13 februari 2020 werkte een groep vertegenwoordigers van overheden, softwareleveranciers en adviesbureaus samen aan het thema “Advieswerkzaamheden en toepassing”. Naar aanleiding van de startbijeenkomst over IMBOR, OTL en ILS. In dit blog deel ik de resultaten van en de aanbevelingen uit deze werksessie. Wil je meedenken of ben je benieuwd hoe we hiermee verder gaan? Je leest het onderaan de blog. Veel leesplezier.


Realistische prijs bepalen voor data-uitwisseling is uitdaging

Tijdens de werksessie werd het al vrij snel duidelijk: op het gebied van data-uitwisseling tijdens projecten is het voor opdrachtnemers een hele uitdaging om vooraf een realistische prijs te bepalen. Gevolg: tijdens het project ontstaan discussies omdat onduidelijk is wie verantwoordelijk is voor welke informatie en data. Dit komt vaak omdat de randvoorwaarden van data-uitwisseling voorafgaand aan het contact niet duidelijk zijn. We stelden onszelf en de deelnemers de vraag:

“Welke informatie heeft opdrachtnemer nodig om een goede prijs voor de opdracht te bepalen?”

Na heel wat brainstormen kunnen we de belangrijkste zaken onderverdelen in 6 categorieën:
  1. Samenwerking en kennis 
  2. Open standaarden
  3. Data-uitvraag
  4. Dataleveringen 
  5. Datavalidatie
  6. Datastructuur

We maakten per categorie een eerste aanzet van de randvoorwaarden die soms nog onduidelijk zijn of ontbreken bij contracten, als het gaat om data-uitwisseling. Ben je ook benieuwd naar de stappen die je kunt zetten om meer duidelijkheid te creëren op dit gebied? Hieronder zet ik ze uiteen.

1. Samenwerking en kennis

  • Kennis medewerkers opdrachtgever
    • Wat is het kennisniveau van de organisatie van de opdrachtgever als het gaat om uitwisselen van projectinformatie/data?
  • Vereiste kennis van opdrachtnemer
    • Geef aan welke kennis vereist is bij de organisatie en/of het projectteam van de opdrachtnemer. In hoeverre dient de opdrachtnemer een gesprekspartner te zijn op het gebied van semantisch modelleren, gerelateerde open standaarden en dataleveringen?
  • Samenwerkingsomgeving
    • Welke applicaties / online samenwerkingsomgeving stelt de opdrachtgever ter beschikking? Met een VISI applicatie kun je goed afspraken maken en je samenwerking organiseren; daarnaast is een omgeving nodig waarin je samen de “Digital Twin” kunt bekijken en de uitgewisselde data met veel detail kunt verifiëren en valideren.

2. Open standaarden

  • Welke standaarden zijn van toepassing?
    • Geef aan welke standaarden worden gebruikt. In de ILS staat welke informatie in welk formaat moet worden uitgewisseld. Dit formaat is waar mogelijk een open standaard. Areaalgegevens met geo-informatie worden bijvoorbeeld uitgewisseld met COINS/ICDD; samenwerkingsinformatie met VISI; 3D modellen met IFC.
  • Impact op ICT
    • De eisen aan de informatielevering hebben mogelijk gevolgen voor de ict-middelen van de opdrachtnemer. Denk hierbij aan vragen zoals: Welke impact heeft de informatielevering op het ict-landschap van de Opdrachtnemer? Welke open standaarden moet de leverancier van de opdrachtnemer aan kunnen?

3. Data-uitvraag

  • Kwantificeer je data-uitvraag
    • Hoeveel data wil je terug krijgen als opdrachtgever? Wanneer een referentie/voorbeeld meegeleverd wordt van een datalevering, kan de opdrachtnemer de tijd en kosten die hiermee gemoeid zijn beter inschatten. Denk hierbij aan een referentiemodel van bijvoorbeeld één wegvak, een kunstwerk of iets anders in het projectgebied.
  • Zorg voor voldoende voorbeelden van datasets
    • Lever naast een testdataset ook de OTL as-is areaaldataset met daarbij een overzicht van gebreken. Natuurlijk kan het zo zijn dat er gegevens ontbreken, welke tijdens het project ingevuld gaan worden. Door in de uitvraag aan te geven welke aanvullingen worden verwacht tijdens het project kan de opdrachtnemer een betere inschatting maken van de te maken aanvullingen.
  • Overlegstructuur informatiemanagement
    • Wat is de frequentie van overleggen over informatiemanagement in het project. Welke kennishouders zijn hierbij betrokken?

4. Dataleveringen

  • Frequentie en omvang dataleveringen
    • Wat is de (verwachte) frequentie van dataleveringen? En op welk moment gebeuren de dataleveringen? Wordt er tijdens alle dataleveringen hetzelfde verwacht? Deze vragen zijn projectspecifiek. Bij een onderhoudscontract is één datalevering per maand van alle data voldoende, terwijl een realisatieproject wellicht object gerelateerde dataleveringen vereist.
  • Hoe wordt de dataset geleverd?
    • Benoem in je contract op welke manier en in welk formaat de initiële dataset geleverd wordt bij de start van het contract. Tip: Lever data op eenzelfde manier aan zoals je deze ook terug wilt ontvangen.

5. Data verificatie- en validatie

  • Datacontrole
    • Wees als opdrachtgever duidelijk op welke manier de data gecontroleerd wordt: Wat is de procedure? Hoe lang is de doorlooptijd? Hoe gebeurt de controle (wel of niet automatisch)? Wanneer de opdrachtnemer voorafgaand weet welke 'checklist' wordt gehanteerd, kan de opdrachtnemer vóór het aanleveren van de data zelf de controle uitvoeren: wel zo makkelijk!
  • Terugmelding fouten datalevering
    • Wanneer tijdens een controle van een datalevering fouten worden geconstateerd door opdrachtgever: hoe worden deze fouten terug gemeld naar opdrachtnemer? Middels welk formaat wordt dit gedaan: PDF, CVS, Linked Data?
  • Datavalidatie
    • Verder is het aan te raden om een uitgewerkte datavalidatie mee te geven aan opdrachtnemer door middel van een UX-design of andere visualisatie.

Datastructuur

  • Hoeveel versies van de OTL worden verwacht?
    • Geef aan hoeveel verschillende versies er worden verwacht van de OTL tijdens het project.
  • Verwachte kosten voor wijzigingen OTL opnemen in contract.
    • Wat zijn de verwachte kosten voor de wijzigingen?
  • Voorwaarden opnemen voor meerwerk aanpassen OTL structuur.
    • Geef aan wanneer er meerwerk mag worden ingediend door opdrachtnemer als de structuur veranderd van de OTL. Hierbij kan bijvoorbeeld onderscheid worden gemaakt in soorten wijzigingen:
  1. Andere hoofdstructuur van OTL: vraagt om aanpassing van je hele bestandsstructuur.
  2. Uitbreiden structuur extra objecttype, waarde of uitbereiding van een lijst.
  3. Extra informatie toevoegen bij object: als de opdrachtnemer méér gegevens moet inwinnen bij een object, dan kost dat tijd en dus geld.
  • Versiemanagement van OTL
    • Geef aan op welke manier je wijzigingen gaat doorgeven. Zorg daarnaast voor een duidelijke track-and-trace van je wijzigingen in de OTL structuur.

Opdrachtgevers: uniformeer!

Uit de werkgroep volgde ook de volgende oproep voor opdrachtgevers: Uniformeer jullie uitvragen als het gaat om data-uitwisseling! Op deze manier weten opdrachtnemers wat ze kunnen verwachten en krijgen opdrachtgevers een realistische prijs. De volgende stap? Het opstellen van generieke functionele eisen voor in de vraagspecificatie!

Heb jij aanvullingen voor de lijst met uitgangspunten of denk je graag mee over de verdere uitwerking? Neem contact met me op: lotte.bekendam@crow.nl óf meld je aan voor de eindbijeenkomst van het traject op 26 maart 2020.

Groet,
Lotte Bekendam - CROW
 

Reacties

Er zijn nog geen reacties op dit bericht
Abonneer
 Security code
Scroll naar boven