Wat maakt een AI applicatie voor de bouw anders dan een generieke tool?
Generieke AI-tools, denk aan spreadsheet-assistenten of generieke chatbots, kennen de bouwlogica niet. Ze weten niet dat een kostensoort aan een fase gekoppeld moet zijn, dat een projectnummer over meerdere jaren doorloopt, of dat een meerwerk-post een eigen goedkeuringspad heeft. Ze produceren output die er goed uitziet, maar die een calculator of projectleider niet kan gebruiken zonder forse handmatige correctie. Een AI applicatie die in de bouw echt waarde levert, is gebouwd op het datamodel van de bouwoperatie: WBS-structuur, kostensoorten, contractvormen, faseringen. Zonder die basis is het een dure tekstgenerator.
Knelpunt 1: calculatie en uitvoering leven in gescheiden werelden
Het meest voorkomende patroon: de calculatie zit in een eigen systeem of Excel, de uitvoering registreert uren en materialen ergens anders, en de koppeling bestaat niet. Een AI-applicatie die op calculatiedata traint, mist dan de terugkoppeling vanuit de uitvoering. Ze kan nooit leren of een raming klopte, welke posten stelselmatig uitlopen en waar de marge weglekt. De oplossing is niet een betere AI-tool bovenop de bestaande silo's. De oplossing is een datamodel waarbij calculatie en uitvoering op hetzelfde projectnummer en dezelfde kostensoorten draaien. Pas als die koppeling er is, kan een AI-applicatie zinvolle suggesties geven, zoals een signaal dat een bepaalde kostensoort op vergelijkbare projecten altijd 15 tot 20 procent hoger uitvalt dan geraamd.
Knelpunt 2: projectdata is gefragmenteerd over systemen, e-mail en hoofd
In veel bouwbedrijven staat kritische projectinformatie verdeeld over het projectbeheersysteem, losse e-mailconversaties met onderaannemers, pdf-offertes, WhatsApp-berichten van de uitvoerder en de aantekeningen van de werkvoorbereider. Een AI-applicatie kan dit niet samenvoegen als er geen centrale structuur is. Het resultaat: de tool heeft altijd incomplete input en geeft onbetrouwbare output. De aanpak die werkt, is het vastleggen van een minimale set gestructureerde data per project, voor je begint met automatiseren. Dat betekent: elk contact, elke offerteversie, elke planningswijziging op een vaste plek met een vaste structuur. Niet per se één groot systeem, maar wel een helder datamodel waar de AI-applicatie op kan steunen.
Knelpunt 3: fasering en scopewijzigingen worden niet bijgehouden als data
Meerwerk, scopewijzigingen en herfaseringen zijn in de bouw dagelijkse realiteit. Maar in de meeste systemen worden ze bijgehouden als losse notities, aparte Excel-tabbladen of mondeling overgedragen aan de volgende ploeg. Een AI-applicatie die planningssuggesties doet of voortgangsrapportages genereert, heeft gestructureerde fasedata nodig: wat was het oorspronkelijke plan, wat is er gewijzigd, op welke datum en door wie geaccordeerd. Zonder die structuur genereert de AI output op basis van een verouderde scope en zit de projectleider alsnog achter de feiten aan. De oplossing: wijzigingsbeheer als verplicht onderdeel van het datamodel, niet als bijlage.
Wanneer is een AI applicatie voor de bouw de juiste keuze?
Een AI-applicatie werkt in de bouw als aan drie voorwaarden is voldaan. Eerste: projectnummers, kostensoorten en faseringen zijn consistent gedefinieerd en worden daadwerkelijk gebruikt door de hele organisatie. Tweede: calculatie en uitvoeringsdata zijn op hetzelfde datamodel aangesloten, zodat ramingen vergeleken kunnen worden met werkelijkheid. Derde: wijzigingen in scope en planning worden als gestructureerde data vastgelegd, niet als proza in een e-mail. Is aan die voorwaarden voldaan, dan kan een AI-applicatie snel waarde toevoegen: automatische signalen bij kostenafwijkingen, suggesties bij nieuwe calculaties op basis van historische projectdata, automatische samenvatting van projectstatus voor de opdrachtgever. Is aan de voorwaarden niet voldaan, dan is de prioriteit eerst de datastructuur, niet de AI-tool. Dat is geen comfortabele boodschap, maar het is de eerlijke.
Bouw je een AI applicatie op een bestaand systeem of begin je opnieuw?
Veel bouwbedrijven hebben al een ERP of projectbeheersysteem dat niet volledig aansluit op de operatie. De keuze is dan: bouw een AI-laag om het bestaande systeem, of vervang het kernsysteem en bouw AI er vanaf het begin in. De eerste aanpak werkt als het bestaande systeem de juiste data al vastlegt en de integratie haalbaar is. De tweede aanpak is zinvol als het bestaande systeem structureel tekortschiet en de organisatie bereid is om het datamodel opnieuw te definiëren. Bonsai werkt met beide aanpakken: AI Workers voor een laag bovenop bestaande systemen, of een volledig nieuw kernsysteem als de basis niet deugt. Welke aanpak past, hangt af van wat er al staat en wat de organisatie wil.