| In deze reeks artikelen staat de wereld van projecten in de fysieke buitenruimte centraal. In eerdere artikelen ging het over de informatiebehoefte bij aanvang van zulke projecten en over de wijze waarop zij vervolgens worden uitgevoerd. Het derde artikel gaat over de dossiervorming. |
Op veel DIV-afdelingen zijn de opleverdossiers van grote projecten oorzaak van achterstanden.
| In deze reeks artikelen staat de wereld van projecten in de fysieke buitenruimte centraal. In eerdere artikelen ging het over de informatiebehoefte bij aanvang van zulke projecten en over de wijze waarop zij vervolgens worden uitgevoerd. Het derde artikel gaat over de dossiervorming. |
Op veel DIV-afdelingen zijn de opleverdossiers van grote projecten oorzaak van achterstanden. Deze dossiers bestaan uit stukken van aannemers welke vaak ontvangen zijn via directievoerders, stukken van ingehuurde ingenieursbureaus en/of stukken uit de eigen organisatie. Vaak is onduidelijk uit welke hoek documenten afkomstig zijn, waar deze gevonden kunnen worden, wie de eigenaar van de informatie is, wat de status is, et cetera; met alle problemen van dien.
Of kan het ook anders? Laten we eerst even terug gaan naar het doel van een project in de ruimtelijke omgeving. Door nieuwbouw of aanpassing willen we een wijziging in de openbare ruimte realiseren binnen een bepaald budget en binnen een bepaalde termijn. Dit gebeurt projectmatig, waarbij verschillende rollen ingevuld moeten worden, bijvoorbeeld ambtelijk opdrachtgever(s), ambtelijk opdrachtnemer(s), marktpartij(en) en beherende organisatie(s). Zij gaan aan de slag om dit te bewerkstellen. Achteraf kunnen twee vragen gesteld worden:
- De verantwoordingsvraag – Waarom heeft het project zoveel geld gekost? Waarom duurde het zolang? Was het resultaat ook hetgeen gevraagd werd?
- De situatievraag – Wat is nu de actuele situatie van de openbare ruimte?
De verantwoordingsvraag
De verantwoordingsvraag gaat over de formele communicatie binnen het project. Wie heeft wat wanneer en waarom besloten? In de traditionele praktijk wordt vaak getracht dit achteraf te reconstrueren. Een sisyfusarbeid: iedere keer als je denkt dat het je gelukt is, na veel inspanningen, kom je erachter dat je niet alles hebt en je eigenlijk opnieuw kunt beginnen. Mij staan de vele inventarisatieklussen voor de geest, waarbij – hoe goed ik het ook gedaan had – het gevormde dossier nooit kon voldoen bij de rechter, omdat bepaalde onderdelen ontbraken.
Willen we dit slimmer aanpakken dan is het van belang om vooraf helder te hebben:
- wie welke rol heeft,
- wie met wie communiceert,
- wie welke bevoegdheden heeft,
- et cetera.
In de relatie tussen de markt en de directievoerder wordt bij grote organisaties steeds meer gebruik gemaakt van de open standaard VISI.1 Hiermee kan bij een bouwproject een ‘interactiekaart’ getekend worden, waarin vastgelegd wordt wie met wie waarover communiceert. Ook biedt VISI een uniforme terminologie om de status van transacties vast te leggen; van verzoek via uitvoering naar acceptatie. Wanneer deze standaard goed ondersteund wordt door hard- en software, levert dit een compleet communicatiedossier op, waardoor tijdens én achteraf het project duidelijk is waarom welke afwijkingen van het contract zijn ontstaan.
Ook in de relatie tussen de ambtelijke opdrachtgever en de directievoerder wordt nu op sommige plaatsen VISI ingezet om de communicatielijnen helder in beeld te krijgen, zonder dat er sprake is van doorgeslagen bureaucratie. Vooraf wordt afgesproken wie welke rol en verantwoordelijkheid heeft en op basis daarvan beslissingen mag nemen. In de praktijk betekent dit vaak dat de formeel verantwoordelijkheden veel minder informatie krijgen, omdat zij in het systeem alleen toegang krijgen tot de informatie die zij nodig hebben voor het nemen van besluiten.
VISI kan ook helpen in de relatie tussen de (toekomstig) beheerders en de directievoerders. Al voordat contracten op de markt worden gezet, wordt op grote lijnen overeenstemming bereikt en vastgelegd over de op te leveren producten.
Op deze manier zijn alle formele lijnen vooraf in kaart gebracht, is duidelijk wie waarvoor verantwoordelijk is en kan zodoende het communicatiedossier worden opgebouwd en ontsloten.
De situatievraag
Dan rest ons de situatievraag. Dit betreft ‘het technisch dossier’. In de traditionele werkwijze komt deze als volgt tot stand. De aannemer levert de eerste versie van het dossier op bij het opleveren van het nieuwe/gewijzigde object. Dit dossier is een afgeleide van een (3D-) model waarmee de aannemer heeft gewerkt tijdens de realisatie. Het model zelf wordt meestal niet meegeleverd. Vooraf is namelijk afgesproken dat een tekeningenlijst opgemaakt moet worden met een set bijbehorende documenten.
Na de oplevering van de tekeningen door de aannemer worden deze door de directievoerder doorgezet naar de beheersorganisatie(s), al dan niet aangevuld met eigen opleverdocumenten. De beheerders brengen de documentatie onder in hun beheersystemen. Tot recent bestond dit systeem meestal uit kasten met ordners, maar steeds vaker wordt er gebruik gemaakt van GIS-beheersystemen. Nu verschillen die systemen onderling vanwege de vaak verschillende informatiebehoeftes van de aannemer en de beheerders. Bijvoorbeeld, de beheerders van de brug hebben een andere behoefte dan de beheerders van de weg die erop ligt, of dan de beheerders van de tram die eroverheen rijdt.
En dan gaan we er nog eenvoudigweg vanuit dat toekomstige gebruikers alleen de beherende organisaties zijn. Bij toekomstige grote veranderingen duikt er weer een andere behoefte op zoals we dat in deel één van deze reeks2 uitgebreid besproken hebben. Ook gaan we hier nog voorbij aan de behoeftes van de toekomstige historische onderzoeker.
Weg met het opleverdossier, sluit de datacirkel!
Het grootste probleem van het traditionele opleverdossier is het denken in termen van opleverdossiers. Het zou helpen als we uitgaan van één waarheid. Iedere rol (aannemer, ingenieur, beheerder, ambtelijk opdrachtgever, burger, bestuurder of historisch onderzoeker) heeft toegang tot een en dezelfde dataset die de representatie is van de fysieke werkelijkheid. Een werkelijkheid die periodiek naast klein dagelijks onderhoud ook grote aanpassingen behoeft, die passen in de totale levenscyclus van de fysieke ruimte. Iedereen heeft op basis van zijn/haar rol een filter op deze data, zodat hij/zij alleen die data ziet, die voor deze rol relevant is en/of waarvoor toestemming wordt verleend.
Dit betekent onder meer dat we bij aanvang van een project aan degene die werkzaamheden moet uitvoeren, toegang verlenen tot de virtuele representatie van de werkelijkheid. Hij of zij moet vervolgens bij beëindiging van de werkzaamheden ook de wijzigingen in de virtuele representatie doorvoeren. De uitvoerder is dus niet alleen verantwoordelijk voor het doorvoeren van wijzigingen in de fysieke werkelijkheid, maar ook voor het doorvoeren van wijzigingen in de virtuele werkelijkheid. Vooraf worden hierover afspraken gemaakt.
Omdat er bij het ophalen van de startsituatie en het vastleggen van de nieuwe, gewijzigde situatie gebruik gemaakt wordt van één virtuele werkelijkheid, spreken we ook wel van een ‘gesloten datacirkel’.
Afspraken over (de aanlevering van) data
Uiteraard zullen er vooraf afspraken gemaakt moeten worden over de structuur van de data oftewel het datamodel. Als uitgangspunt geldt het gebruik van standaarden; er wordt niets verzonnen.
Zo worden de fysieke objecten beschreven conform de Basiskaart Grootschalige Topografie (BGT) en het Informatiemodel Geografie (IMGeo).3 Hieraan kunnen beheergegevens gekoppeld worden conform het Informatiemodel Beheer Openbare Ruimte (IMBOR).4
Daarmee samenhangend is er een landelijke afsprakenset over de naamgeving van objecttypen: de Conceptenbibliotheek Nederland (CB-NL)5, die je als organisatie kunt verfijnen in een objectentypenbibliotheek (OTL).6 Denk concreet aan termen als ‘brug’, ‘brugdek’, et cetera tot op moertjes- en boutjesniveau.
Er moeten ook afspraken gemaakt worden over hoe de gewijzigde data aangeleverd kunnen worden. Het is immers onwaarschijnlijk dat alle betrokken partijen in één informatiesysteem samenwerken. De gewijzigde dataset is vaak vele GB’s groot en uitermate complex, waarbij de integraliteit (de samenhang tussen de verschillende informatieobjecten) geborgd moet zijn. De dataset kan daarom enkel en alleen opgeleverd worden door deze ‘in te pakken’ in een virtuele container. Een veel toegepaste standaard hiervoor is COINS (Constructieve Objecten en de INtegratie van Processen en Systemen).7
Deze afspraken maken mogelijk dat diverse vakgebieden eenvoudig kunnen samenwerken, waarbij ze zich allemaal baseren op een en hetzelfde datamodel, waarbij elke branche zijn eigen verfijning heeft die te koppelen is aan een groter gedeelde representatie van de werkelijkheid.
Afspraken vastleggen en borgen
Over (de oplevering van) de data moeten dus afspraken gemaakt worden, waarvan de navolging getoetst moet worden. De opdrachtgever dient akkoord te gaan met de geleverde data. Zo niet, dan vraagt hij om aanvullingen en/of correcties. Dit proces van aanlevering, toetsing en accordering van datacontainers vraagt om formele communicatie. Dit is waar de verantwoordingsvraag en de situatievraag elkaar raken. Deze communicatie kan eveneens ingericht worden met behulp van VISI, waarbij ook de dossieropbouw geregeld kan worden.
Bij steeds meer grote projecten wordt zodoende als onderdeel van het contract vastgelegd welke informatie beschikbaar komt aan de aannemer, welke gewijzigde data in welke vorm aangeleverd moeten worden en op welke wijze de communicatie verloopt. Deze set afspraken is beter bekend onder de naam ILS, Informatie Leverings Specificatie.8
Slotvraag
In steeds meer organisaties is het traditionele opleverdossier voltooid verleden tijd of zal het binnenkort tot het verleden gaan behoren. Dit roept ook een aantal vragen op. Wat betekent het voor het beheer van datasets als traditionele opleverdossiers niet meer worden geleverd? Wie gaat dit archiveren? Gaan we dit nog wel archiveren? Wat betekent dit voor toekomstige gebruikers van de data? Kunnen we over tien, twintig of vijftig jaar nog over deze data beschikken en wat moeten we daarvoor regelen? Daarover in het laatste deel van dit vierluik meer.
Theo.Kremer@amsterdam.nl, Theo Kremer is informatiespecialist bij het Ingenieursbureau van de gemeente Amsterdam
Noten
1 Er kan de nodige verwarring ontstaan rondom de naam ‘VISI’. Dit is zowel de naam van de open standaard (zie https://www.crow.nl/thema-s/bouwwerkinformatie/visi) als de naam van een commercieel, veelgebruikt software-product (zie https://www.bakkerspees.nl/product/visi). In dit artikel wordt de open standaard bedoeld.
2 Kremer, Theo (2017), ‘Grondstof informatie’. In: Od #7, oktobernovember 2017.
3 https://www.geonovum.nl/onderwerpen/bgt-imgeo-standaarden
4 https://www.crow.nl/thema-s/management-openbare-ruimte/imbor
5 https://www.youtube.com/watch?v=EdyemfiKVaY
6 Zie als voorbeeld: https://otl.rws.nl/
