Naarmate ik vroeger in het proces betrokken wordt, hoe meer ik besef dat verschillende benamingen en benaderingen van de bouwkost door de verschillende partners onze efficiëntie in de bouw ernstiger belemmert dan op het eerste zicht lijkt. Dit begint met de raad van bestuur die een nieuw project lanceert maar eindigt ook daar met feedback over het rendement van hun investering. En in deze “loop” loopt het dus fout waarbij de raad van bestuur de draad kwijt geraakt. Hierbij een voorstel om dit te counteren.
Jaren geleden volgde ik een one-on-to-one workshop over Excel bij Henk Vlootman. Hierbij stelde hij m.b.t. het database denken – nodig om correct met Excel aan de slag te gaan – het begrip “lijst” tegenover het begrip “systeemvariabele”. De eersten zijn geldig voor elk project, de laatste worden per project vastgelegd en binnen dit project consequent toegepast.
Het is dus zaak om voor elk bouwproject, van in het begin de “systeemvariabelen” vast te leggen en deze consequent door iedereen en tijdens de hele levenscyclus van het gebouw te gebruiken.
Het enige classificatie systeem dat beantwoord aan de ISO 12006-2:2015 Building construction — Organization of information about construction works — Part 2: Framework for classification en aandacht schenkt aan “identification” is Cuneco Classification System (CCS) uit Denemarken. Doch, zoals elk theoretisch systeem heeft het wat “tweaking” nodig om in de praktijk helemaal werkbaar te zijn.
CCS gaat voorbij aan het feit dat een complex in meerdere fasen uitgevoerd kan worden die bovendien mogelijk elk een eigen financieel model hebben. Daarom is het belangrijk om naast het begrip “Stage” dat RIBA plan of work 2020 introduceert (en een “lijst” vormt want voor alle projecten gelijk) er ook een systeemvariabele komt die dit identificeert. De bijhorende codering kan dan met [P]# starten, gevolgd door een uniek nummer en eenduidige omschrijving van het deelproject of “phase”. Bv. aan de ene zijde van het ziekenhuis wordt een huisartsenwachtpost gerenoveerd en tegelijk wordt aan de andere kant van de site een gloednieuwe polikliniek opgetrokken. Dit levert dan bv.[P]#HWP enerzijds en [P]#POLI anderzijds. Of de bijhorende kosten onder activatie dan wel onder exploitatie vallen, wordt best in een andere parameter vastgelegd maar is een problematiek die buiten dit artikel valt.
Een volgende onderscheid die we in de datastroom wensen te kunnen maken, betreft het gebouw dat we aan het ontwerpen, bouwen dan wel aan het onderhouden zijn. CCS noemt dit “entity” en gebruikt hiervoor [E]#. Bv. onze huisartsenwachtpost bestaat enerzijds uit een aanpassing van het gebouw waar de spoed in gevestigd is en een stuk nieuwbouw. We gaan derhalve [E]#SPOED en [E]#HAP hebben. We zouden dit ook [E]#HWP kunnen noemen maar de kans is groot dat er in de mondelinge communicatie spraakverwarringen ontstaan doordat de ene het heeft over het deelproject huisartsenwachtpost en de andere enkel het nieuwe gebouw huisartsenwachtpost bedoelt. Zeker als het over geld gaat, kan de discussie dan onnodig bitsig worden.
Next in de lijst, zijn de bouwlagen. CCS gebruikt hiervoor “storey” en de code dient te starten met [S]#. Belangrijke vraag: waar stopt de ene en waar begint de andere? Vanuit Nederland, waar men toch verder staat met BIM dan wij, maakt men het onderscheid aan de onderzijde van de dragende plaat. Derhalve behoort de fundering tot de onderste bouwlaag. Bouwlagen onder de grond, krijgen doorgaans de notering [S]#91, [S]#92, … De dakplaat met bijhorende waterdichting bovenop de 1ste verdieping, behoort derhalve tot [S]#02. Doch het verlaagde plafond eronder blijft tot [S]#01 behoren.
Binnen in een gebouw, kunnen we ook een groepering van ruimtes willen kunnen afbakenen omdat bv. deze betaald gaan worden door dokters daar waar andere ruimtes een algemene last van het ziekenhuis zijn. CCS noemt dit “zone” en gebruikt de code [Z]#. In ons voorbeeld zou dit dan bv. [Z]#DRS en [Z]#ZH kunnen zijn.
Uiteraard willen we ook “room by room” kunnen werken en willen we data- maar ook de bijhorende geldstromen per lokaal kunnen beheersen. Een ruimte omringd door muren noemt CCS een “built space” waarbij de code start met [B]#. Echter, in bv. een open landschapsbureau en zeker bij exploitatie, wilt men ook de aparte werkplekken kunnen definiëren. CCS hanteert hiervoor het begrip “activity space” waarbij de code start met [A]#.
Naarmate we meer datastromen uit het BIM model gaan trekken om er verdere bewerkingen op los te laten, is het belangrijk dat we met z’n allen - t.e.m. de raad van bestuur die het hele boeltje financiert ! - de zaken op eenzelfde manier benoemen, dezelfde "ankerpunten" in het project hebben.
Het is m.a.w. bijzonder sterk af te raden om te gaan freewheelen met de invulling van de systeemvariabelen doorheen het project. Wat niet wil zeggen dat je van in het begin alles piekfijn uitgedokterd moet hebben. Dit is onmogelijk in een organisch proces dat het ontwerpen-bouwen-onderhouden van gebouwen is. Echter, ze moeten wél centraal en op een voor iedereen vlot bereikbare plek bijgehouden worden. Hence in eerste instantie op een groupware maar ook in het BIM protocol / uitvoeringsplan.
Nu nog enkel de discipline in onszelf vinden om ze consequent overal te gaan toepassen en zodoende de andere partners in het proces het leven wat gemakkelijker te maken.
#innovation #BouwData #henkvlootman #5D #BIM #CCS #BIMprotocol #BIMuitvoeringsplan #discipline
LinkedIn
Twitter
)