Voor al degenen die willen samenwerken ...

Pieter Pauwels van de Universiteit Gent maakte mij attent op volgend You Tube filmpje: 
https://www.youtube.com/watch?v=bhVPOdcpmc0&feature=youtu.be 

Een paar interessante definities op een rij om in het achterhoofd te houden:

co-ordination = AVOID GAPS and overlap in team members work
co-operation = obtain MUTUAL BENEFIT by sharing work
collaboration = ACHIEVED RESULTS which could not be accomplished alone

knowlegde = information about a subject
skills = using what I know in a situation
behaviour = the I use my skills - what you see me do

En als ik een beetje mag stoefen: bij de vervangingsnieuwbouw van AZ St Maarten zijn we aardig op weg naar samenwerking en het ontwikkelen van het gewenste gedrag.

Wat BIM dichter bij de praktijk zou kunnen brengen

Vooraleer ik van wal steek met mijn idee, een vergelijking om e.e.a. te duiden.

Stel je voor dat elke boekhouder zijn eigen werkwijze uitdenkt. Dit impliceert dat je door de jaren heen kennis over je bedrijf opbouwt a.d.h.v. de methodiek van die ene specifieke boekhouder.

Wens je van boekhouder te veranderen, dan kan je die kennis niet gewoon eventjes overzetten want die nieuwe boekhouder werkt al jaar en dag volgens zijn, ook zelf bedachte doch andere werkwijze en wenst dit uiteraard niet te veranderen voor één klant.

Voor de overheid is het al helemaal een ramp want zij moeten jaarrekeningen controleren die opgesteld zijn volgens duizend en één verschillende manieren.

Bench marking ? Forget it.

Kafka, denk je ? Wel, dit is exact wat er op de werkvloer in de bouwsector gebeurt.

Dus wat stel ik voor ? Een rekeningstelsel voor de bouwsector. 

In 2008 stapte ik met dit idee naar het Instituut voor de Aanmoediging van Innovatie door Wetenschap en Technologie in Vlaanderenen en kreeg een subsidie toegewezen onder de vorm van een IWT KMO Innovatieproject (nr 080429). 

Ondertussen zijn we acht jaar verder, zijn er nieuwe normen en wordt het rekeningstelsel in de praktijk getest. Eerst bij het project "Dageraad" (een relatief klein privé project dat bij de oplevering verkocht werd aan individuele kopers maar waar we van voor de aankoop van de grond het rekeningstelsel konden testen), nu bij de vervangingsnieuwbouw van AZ St Maarten te Mechelen (een mega project van ca. 105.000m² en een investeringsbudget van 340 miljoen euro, waarbij de link met exploitatie belangrijk is maar waar het testen van de methodiek pas begon nadat het ontwerpproces afgerond was).

Zeer simpel voorgesteld ziet dit er als volgt uit:

Bij het opslaan van data dient men telkens vier aspecten in beschouwing te nemen:

• DEVELOPMENT
  Dit handelt over vloeroppervlaktes: bruto versus netto, privatief versus collectief, per gebruiksfunctie, per verdieping, etc.
  Kapstok hierbij is de NBN EN 15221-6 Metingen van oppervlakte en ruimte in facility management. Maar gezien deze naar de praktijk toe te vaag blijft, vullen we die best aan met de gebruiksfuncties en ruimtebenamingen uit het Bouwbesluit.
  Voor de fans van SfB: tabel 0 blijkt in de praktijk niet echt te werken.
• OBJECT
  Dit handelt over functies en life cycle cost.
  Kapstok hierbij is de NEN 2699 Begripsomschrijvingen en indeling m.b.t. investerings- en exploitatiekosten van onroerende zaken. Ook hier moeten we een link leggen naar een andere norm om dichter bij de praktijk te komen, nl. de verdere onderverdeling van tabel 1 van de BB-SfB (plus).
• MATERIAL
  Dit handelt over materialen.
  Kapstok hierbij is de STABU bestekssystematiek. En ook hier dien ik de Nederlanders gelijk te geven: tabel 2 en 3 van de SfB werkt eenvoudigweg niet als je een vlot aankoopbeleid uit de grond wilt stampen.
• GROUPWARE
  Een sharepoint is zo mogelijk nog belangrijker dan een BIM model. Immers, niet alle data kunnen in een BIM genoteerd worden. Maar alle data uit een BIM model kunnen wel op een sharepoint ter beschikking gesteld worden van de betrokken keypartners.
  Kapstok hierbij is kolom A van tabel 4 van de BB-SfB. Het is niet perfect maar mits wat boerenlogica best bruikbaar.

En om zeker te zijn dat we allemaal dezelfde definities hanteren, is er de terminologie geformuleerd door TU Delft in het kader van het Bouwbesluit.

Wat ons rest, is er gewoon mee aan de slag te gaan.

Waarom BIM in de praktijk zo moeilijk is

De laatste dagen voer ik een interessante mailcorrespondentie met Dr. Ir. Pieter Pauwels, Dept. of Architecture and Urban Planning, Universiteit Gent.

De key vraag die hierbij opduikt, is: "Waarom is BIM in de praktijk zo moeilijk ?". Mijn antwoord zal vermoedelijk niet met open armen onthaald worden maar het is helaas de pijnlijke waarheid.
Het belangrijkste struikelblok is dat de meeste bouwwerken opgetrokken worden via het design-bid-build principe en dat onderhoud buiten beschouwing wordt gelaten (immers, het project dient direct na oplevering met zo een groot mogelijk winstmarge verkocht te worden – een ontwikkelaar is bij het gebruik geen betrokken partij). 

Hieraan zijn twee aspecten verbonden die academisch onderzoek vragen – en dat speelt ook binnen de verschillende partijen / afdelingen die DBFM projecten realiseren:

1. Er is een leger advocaten die zijn brood verdient door de conflicten tussen het “design” team en het “build” team op de spits te drijven. En als het een DBFM project betreft, is het wel een baas die met een zak vol bonussen zwaait op het einde van het jaar, een zak die verdeeld wordt onder de managers van diverse afdelingen die, binnen het DBFM project, tegengestelde belangen hebben.

2. Elk bedrijf in de bouwsector (of zelfs een afdeling van een concern dat DBFM projecten realiseert) werkt aan meerdere projecten tegelijk. Prioriteit voor dit bedrijf / die afdeling is om al zijn werknemers continue van fulltime job te voorzien. Bouwprojecten zijn alles behalve continue zaken: het PvE & ontwerp bouwt langzaam op, kent een gigantische piek bij het bouwen en eindigt in het min of meer continue ritme van facility management. Dit resulteert dat projecten binnen eenzelfde bedrijf vaak doorgegeven worden, net om bij een constant aantal medewerkers die pieken te kunnen opvangen. Bij deze overdracht gaat telkens informatie verloren. Immers, niet alles kan in data omgezet worden. De chemie en wisselwerking tussen mensen in een projectteam is in niets te vatten maar moet bij elke wisseling terug opgepakt, bijgewerkt worden. En dit vraagt tijd en dus geld.

M.a.w. zolang de conflict cultuur en het wisselen van medewerkers aan een project niet stopt, maakt BIM geen schijn van kans.

STABU in Vlaanderen ?

In Nederland heeft STABU al decennia lang zijn nut bewezen in de aannemerswereld. 

Maar net zoals er voor tabel 1 van de SfB er nood is aan een Belgische en Nederlandse variant, lijkt dit ook voor STABU het geval te zijn omdat er toch een verschil is in terminologie tussen beide gebieden. 

Overheidsinstanties (zowel adviesinstanties als onderwijs) laten dit ongemoeid omdat de Vlaamse bouwwereld dit zgn. niet wil. Maar is dit wel zo ?

Kan er geen werkgroep gevormd worden die alvast de titels van de STABU hoofdstukken en paragrafen naar een Vlaams werkbaar iets omzet ? 
Ieder kan dan zijn eigen, bestaand bestek dan gewoon in dit frame inschuiven. 

Het zou het leven van véél calculatoren een pak simpeler maken.

Anyone who wants to join me in this quest ?