BIMcollab Twin | Ruimtelijke structuur aan basis van documentbeheer

Hoe moeten we onze mappenstructuur inrichten? Die vraag is mij honderden keren gesteld voor evenveel projecten en vastgoedportefeuilles. En blijkbaar is er aardig wat onzekerheid over het inrichten van databases. Ik snap het wel, want data opslaan en (vooral) terugvinden is lastig. Waarschijnlijk weten mensen dat ik ‘iets doe’ met databases en krijg ik de vraag. Daarom deel ik hier graag onze visie op documentmanagement.

Eerst even back to basics; als we het hebben over een ‘mappenstructuur’, praten we eigenlijk over Document Management Systemen, ook wel DMS-oplossingen genoemd. Die DMS’en zijn gebouwd in databases met een gebruikersinterface die vaak is gemaakt in de vorm van de vertrouwde mappenstructuur van Windows. Gewoon omdat iedereen die grafische weergave begrijpt. In een vorige versie van BIMcollab Twin hadden wij die Windows-mappenstructuur ook nagebootst, maar het was al gauw duidelijk dat we hier vanaf moesten. We hoorden dat klanten steeds maar discussies en onduidelijkheden hadden over het opbergen van documenten en data over gebouwinformatie.

Metadata en filters

Daarnaast diende zich een nieuwe uitdaging aan. Afgelopen jaren is er een toenemend aantal 3D-modellen en wij willen dat klanten de informatie uit die modellen ook kunnen opslaan in het DMS. Data is multi-dimensioneel: iedere stakeholder heeft een andere kijk op de data en verwacht dus een andere boomstructuur/mappenstructuur. Dit is bij 3D modellen nog veel meer aan de orde. Daarom werkt één mappenstructuur niet, maar heb je meerdere metadata velden nodig waarop je kan zoeken en filteren. Maar 3D-modellen bevatten héél veel informatie en die wordt niet gepresenteerd in een Windows-mappenstructuur. Dus hoe konden we al die data op een laagdrempelige manier ontsluiten en ook nog eens combineren met een DMS? Als oplossing hiervoor hebben we in de huidige versie van BIMcollab een ‘raamwerk’ ontwikkeld met metadata en filters in plaats van mappen. Alle documenten, data en geometrische data worden opgeslagen op het platform en met behulp van die metadata en filters kunnen gebruikers de gewenste bestanden snel en intuïtief terugvinden.

Ruimtelijke structuur

Eigenlijk gebruiken we dus überhaupt geen mappen meer. Deze oplossing komt dus uit het gebouw zelf, namelijk uit de ruimtelijke structuur van het gebouw dat in feite ‘slechts’ een grafische weergave is van het gebouw. De ruimtelijke structuur van het gebouw (locatie, site, gebouw en verdiepingen) is de kapstok waaraan alle documenten en data in de database(structuur) hangen. Ons platform geeft in feite een weergave van die ruimtelijke structuur. Die structuur is bovendien herkenbaar voor alle betrokkenen van het gebouw en dus kunnen zij er intuïtief mee werken. Als er al een mappenstructuur is in de database (waar ik mee begon) dan is die default zichtbaar voor klanten. Sowieso is die niet leidend voor het opslaan van data over het gebouw(model). De structuur is volgend aan het gebouw op basis van de informatie uit het IFC-infrastructuur.

Legio mogelijkheden

Dit inzicht hebben we inmiddels geïmplementeerd op ons platform dat nu meer dan drie jaar operationeel is. Het DMS en de 3D-objecten bevinden zich in dezelfde databasestructuur in het open (database)model. Hoe werkt het? Alle typen documenten en bestanden kunnen worden ge-upload naar het DMS en het systeem koppelt die bestanden direct aan de ruimtelijke structuur van het gebouw.

Klanten kunnen IFC- en Revit-bestanden uploaden naar de cloud en als het systeem alle data, geometrie en documenten in de database heeft geïmporteerd, ontstaan legio mogelijkheden. Zo kan onze online viewer (ontwikkeld met DeltaPi) de geometrie tonen in een browser. Het DMS kan relaties leggen tussen documenten en 3D-objecten waardoor je direct inzicht hebt in de gekoppelde documenten en communicatie als je een 3D-object selecteert. Die 3D-objecten zijn op basis van parameterwaarden te bekijken in de online viewer (ontwikkeld met DeltaPi. Bovendien kunnen werkpakketten, die voorheen enkel uit tekeningen bestonden, worden aangevuld met 3D-objecten. Ook zijn alle documenten en het 3D-model ook mobiel op locatie te ontsluiten in de field app (ontwikkeld met BEECOT). De toekomst is aan de Augmented Reality (AR) waarvoor we momenteel ook functionaliteit ontwikkelen.

Zoeken wordt vinden

Kortom; denk vandaag de dag dus niet meer in termen van databases of mappenstructuren. Denk liever aan het resultaat dat je wilt zien en op welke informatie je wilt inzoomen. Als je documenten over de voordeur zoekt, kijk dan niet bij de V van voordeur, want misschien heeft een collega deze opgeslagen bij de I van ingang of de D van deuren. Klik dus liever op de voordeur in je 3D-model. Creëer hiervoor een systeem dat je intuïtief brengt naar het document dat je op een bepaald moment wilt raadplegen. Het is wel een precies werkje om dit voor elkaar te boksen. Dus zou je dat natuurlijk ook kunnen uitbesteden.