Hoe ziet het probleem er op de werkvloer uit?
Een calculator maakt een begroting in een spreadsheet of een gespecialiseerd calculatiepakket. Die begroting wordt geaccordeerd. Vervolgens typt iemand de relevante regels over naar het planningssysteem, en later nog een keer naar het inkoopsysteem. Drie invoermomenten, drie kansen op een tikfout. Als de opdracht tussentijds wijzigt, begint de ronde opnieuw. De projectleider werkt met een versie van de begroting die drie weken oud is. De inkoper bestelt op basis van een hoeveelheid die net is bijgesteld. De opzichter op de bouwplaats heeft een uitdraai die niet klopt met wat er uiteindelijk is besteld. Dit is geen uitzondering. Dit is hoe de meeste middelgrote aannemers vandaag werken.
Waarom lossen standaardpakketten dit niet op?
Er zijn genoeg pakketten op de markt die beweren dit probleem op te lossen. De realiteit is weerbarstiger. Grote ERP-systemen zijn gebouwd voor processen die breder zijn dan de bouw en vereisen maanden aan configuratie, zware implementatietrajecten en blijvende licentiekosten. Bouweigen pakketten zijn soms sterk in calculatie maar mager in projectbeheer, of andersom. Koppelvlakken tussen pakketten bestaan op papier, maar in de praktijk zijn ze fragiel: een update bij leverancier A breekt de integratie met leverancier B, en niemand merkt het totdat er een factuur niet klopt. De organisatie past zich aan het systeem aan, in plaats van andersom. Mensen bouwen workarounds in Excel naast het pakket. En zo ontstaat de situatie die iedereen herkent: het systeem staat er, maar de data loopt er omheen.
Wat kost dit patroon concreet?
De schade is moeilijk in een getal te vangen, maar de aard ervan is duidelijk. Meerwerk wordt te laat gesignaleerd omdat het niet zichtbaar is in het systeem. Inkooporders worden te vroeg of te laat geplaatst omdat de planning en de inkoop los van elkaar leven. Nacalculatie is arbeidsintensief omdat de werkelijke kosten niet automatisch terugvloeien naar de begroting. En managementrapportages zijn altijd een dag te laat, omdat iemand de cijfers eerst handmatig moet samenvoegen. Voor een aannemer met twintig lopende projecten telt dat snel op. Niet in spectaculaire incidenten, maar in sluipende marge-erosie op elk project.
Wanneer is het zinvol om het systeem opnieuw te bouwen?
Niet elke organisatie moet haar kernsysteem vervangen. Als een bestaand pakket goed genoeg werkt en de workarounds beheersbaar zijn, is het slimmer om AI Workers in te zetten die het overtypen en het samenvoegen van data automatiseren. Maar als de organisatie merkt dat ze het systeem aan het omzeilen is op de cruciale momenten, als de calculatie, de planning en de inkoop structureel in aparte werelden leven, dan is de keuze voor een volledig nieuw, domein-specifiek kernsysteem het overwegen waard. Niet als een meerjarig IT-project, maar als een gerichte vervanging die in maanden live gaat, met de bouwlogica ingebakken vanaf het begin. Dat is wat een Digital Twin voor de bouw kan zijn: geen aanpassing van een generiek pakket, maar een systeem dat is gebouwd op de manier waarop een aannemer daadwerkelijk werkt.
Wat verandert er als de data wel samenkomt?
Als calculatie, planning en inkoop vanuit dezelfde databron werken, valt er een hoop overleg weg dat nu alleen bestaat om versies op elkaar af te stemmen. Een wijziging in de begroting propageert direct naar de inkoopbehoefte. De projectleider ziet de actuele marge zonder een rapport op te vragen. Meerwerk wordt gesignaleerd op het moment dat het ontstaat, niet drie weken later bij de factuur. Dat zijn geen kleine verbeteringen in comfort, dat zijn beslissingen die eerder worden genomen, met betere informatie. In een sector waar marges smal zijn en de arbeidsmarkt krap blijft, is dat het verschil tussen een winstgevend project en een project dat ternauwernood break-even draait.