The developing contractor: tear down the wall

Partijen die zowel ontwikkelen als bouwen hebben een unieke positie. Ze hebben grip op het hele proces, van de eerste schets tot de laatste steen. Die horizontale integratie zou een krachtig voordeel moeten zijn.

In de praktijk is dat zelden zo.

OMRT sprak de afgelopen maanden, in samenwerking met de TU Delft, met meer dan een dozijn Nederlandse ontwikkelende bouwers over hun softwarelandschap en hun visie op de toekomst. Het patroon was consistent: er is een opeenstapeling van knelpunten die zich opstapelen bij elke overgang, elke fasewisseling, elke overdracht naar een nieuw team. En het kost meer dan de meeste bedrijven beseffen.

Fragmentatie begint eerder dan je denkt

Het voor de hand liggende wrijvingspunt is de overdracht van ontwerp naar bouw. Maar voor ontwikkelende bouwers begint het probleem ruim daarvoor.

Het ontwerpteam van een ontwikkelende bouwer werkt door verschillende fases heen, van schetsontwerp via voorlopig naar definitief ontwerp, en wisselt daarbij vaak tussen modelleringstools naarmate het project zich ontwikkelt. Het traject van een vroege massastudie in schetssoftware zoals Forma naar een volledig uitgewerkt model in Revit kent veel overgangen. Elke overgang betekent dat data opnieuw moet worden opgebouwd, aannames opnieuw moeten worden gemaakt en context opnieuw moet worden vastgesteld.

Tegen de tijd dat het project intern wordt overgedragen, pakt het bouwteam het op in zijn eigen BIM-omgeving, naast ERP- en calculatiesystemen. Maar er is nog steeds geen live verbinding tussen deze werelden. Informatie moet handmatig worden overgetypt, en de kennis die in eerdere ontwerpfases is opgebouwd, verdampt eigenlijk.

Een vestigingsdirecteur bij een grote ontwikkelende bouwer omschreef dit als de schuttingmethode: het ontwikkelteam rondt zijn werk af en gooit het resultaat over de schutting naar de bouwer. Wat aan de andere kant landt, is op zijn best onvolledig.

De knelpunten: wat de interviews opleverden

Deze opgestapelde fragmentatie leidt tot concrete en kostbare problemen. In onze gesprekken kwamen vier patronen steeds terug.

Dubbel werk en dataverlies. 

Het bouwteam moet geometrie en specificaties die het ontwerpteam al heeft vastgelegd opnieuw interpreteren. Hoeveelheden en kostendata uit ontwerpmodellen worden handmatig overgezet naar financiële en planningssoftware. Een ontwikkelmanager beschreef hoe elk project dezelfde inspanning vraagt: opnieuw opbouwen wat het ontwerpteam al had opgebouwd, in een ander systeem, zonder garantie dat de cijfers kloppen.

Een keten van frustratie. 

Het heen-en-weer dat erop volgt is duur. De bouwer gaat terug naar het ontwerpteam voor verduidelijking. De ontwerpers voelen dat hun beslissingen verkeerd worden gelezen. De ontwikkelaar zit ertussenin en moet twee werelden verzoenen die nooit goed met elkaar verbonden zijn. Meerdere geïnterviewden gaven aan dat het ontbreken van gestandaardiseerde data-uitwisseling tussen afdelingen tot blijvende wrijving leidt, zelfs binnen één organisatie.

Tragere projectcycli. 

Eén ontwikkelende bouwer noemde als doel het terugbrengen van de projectduur met 30 tot 40 procent. Maar dat is onmogelijk wanneer elke handmatige overdracht en bijbehorende correctieronde weken toevoegt. Elke overgang tussen teams, fases of tools is opnieuw een hindernis die genomen moet worden voordat de bouw kan beginnen.

Beperkte feedbackloops maken het erger

Meerdere ontwikkelende bouwers beschreven het ontbreken van gestructureerde feedback van de bouwplaats terug naar het ontwikkelteam. Lessen over maakbaarheid, levertijden van materialen of kostenoverschrijdingen uit het ene project bereiken zelden het volgende.

Een geïnterviewde wees op een fundamentele leemte: er is geen mechanisme dat data van de bouwplaats terugvoedt naar de eerdere ontwerp- en begrotingsfases. Het gevolg is dat dezelfde fouten zich tussen projecten herhalen, en dat de kennis van de bouwer over wat daadwerkelijk maakbaar is, nooit terechtkomt bij de mensen die de ontwerpbeslissingen nemen.

Dit is de grootste gemiste kans voor ontwikkelende bouwers. Zij beschikken over uitvoeringskennis die externe ontwerpteams simpelweg niet hebben. Kunnen aangeven dat het iets korter maken van een overspanning aanzienlijk staal bespaart, is iets wat een geïntegreerd intern team kan doen, maar een extern ontwerpteam dat geïsoleerd werkt niet. Die kennis, op het juiste moment toegepast, leidt tot gebouwen die sneller te realiseren zijn, kostenefficiënter en daadwerkelijk beter maakbaar.

Hoe integratie eruitziet

Ontwikkelende bouwers die hier voorbij komen, beschrijven een fundamenteel ander proces. Ontwerpdata stroomt continu door elke fase heen, zonder her-invoer, zonder opnieuw opbouwen, zonder verlies.

Meerdere bouwers waarmee we spraken investeren fors in het verbinden van ontwerp- en uitvoeringsomgevingen. Eén koppelt parametrische ontwerptools direct aan 4D-planningssoftware, zodat informatie uit ontwerpstudies doorstroomt naar planning op de bouwplaats en cyclustijd-benchmarking, en omgekeerd. Een ander heeft een eigen huizenconfigurator gebouwd die parametrische input automatisch omzet in 3D-modellen en tekeningen, waardoor een grote bibliotheek aan voorgetekende woningtypes overbodig wordt.

De strategische ambitie achter deze inspanningen is over het algemeen consistent. Meerdere ontwikkelende bouwers noemden doelen om 60 tot 80 procent van hun projecten via gestandaardiseerde, conceptmatige aanpakken te realiseren.

Maar de grootste winst zit niet alleen in snelheid of kostenbesparing. Het gaat om het vermogen om beslissingen te nemen met het volledige beeld voor ogen. Wanneer het bouwteam ziet dat een constructieve keuze de kosten opdrijft, voedt dat inzicht direct terug naar het model. De ontwikkelaar ziet de financiële gevolgen in real time, en afwegingen tussen kosten, duurzaamheid en maakbaarheid worden zichtbaar voordat het echte problemen worden.

De muur is vooral organisatorisch, niet technisch

De tools om dit mogelijk te maken bestaan. De barrière is zelden technisch. Meerdere geïnterviewden waren daar duidelijk over: de uitdaging zit in mensen één proces laten volgen. Interne politiek, cultuurweerstand en inconsistentie in het werken met templates verhinderen adoptie, zelfs als de technische infrastructuur er staat.

Een innovatiemanager omschreef het als een governanceprobleem en niet als een IT-probleem. Een ander benadrukte hoe belangrijk het is om eerst aan te tonen dat een nieuwe tool kan repliceren wat teams al vertrouwen, voordat je nieuwe mogelijkheden introduceert: eerst repliceren, dan innoveren.

Voor de ontwikkelende bouwer betekent het slopen van de muur een organisatorische verschuiving naar gedeelde omgevingen, continue datastromen en feedbackloops die ook daadwerkelijk sluiten. De bedrijven die dit goed aanpakken, zullen niet alleen sneller zijn. Ze zullen structureel beter worden in het omzetten van elk project in een leermoment voor het volgende.

Dit artikel is gebaseerd op onderzoek dat OMRT heeft uitgevoerd in samenwerking met de TU Delft, op basis van interviews met achttien Nederlandse vastgoedontwikkelaars, ontwikkelende bouwers en ontwikkelende beleggers.