BI Was Supposed to Fix This. It Didn't.

briq Research · April 22, 2026

Every time the business asks for a new report, it's a three-week engineering project. Because the data lives in six places. BI promised to fix this. It moved the problem.

Every time the business asks for a new report, it's a three-week engineering project. Because the data lives in six places.

If you lead technology at a construction firm, you've lived through three waves of promises about this. Each one was supposed to fix data fragmentation. Each one moved the problem instead of solving it.

Wave one was systems consolidation. The pitch in the 2000s was that a single ERP would eliminate the fragmentation by holding everything in one place. A handful of firms tried it. Most abandoned it halfway through. Construction is too operationally diverse for one system to hold the work of the field, the office, the accounting team, and the C-suite in a single schema. The ERPs that survived ended up owning accounting and little else. The PM systems, the scheduling tools, the field data tools, the document management systems, the estimating tools all stayed separate. The data stayed fragmented.

Wave two was business intelligence. Instead of forcing the data into one system, BI promised to leave the systems in place and unify the reporting layer on top of them. Extract, transform, load. Move data out of the source systems, into a warehouse, into a model, into a dashboard. For a while this looked like the answer. Every mid-sized and up firm built a BI team, stood up a warehouse, and started producing dashboards.

What happened next is the thing nobody in the vendor pitches warned you about. BI didn't eliminate the fragmentation. It moved the problem to the pipeline layer. The business still had fragmented source data. Your BI team became the people responsible for reconciling it every time a new question came up. Every new report is a new ETL project. Every schema change in a source system breaks something downstream. Every department wants a dashboard, and every dashboard requires weeks of data engineering to build and maintain. The backlog of BI requests at most construction firms today is longer than it was before BI existed.

Wave three was the data lake and then the data warehouse modernization. This wave is still playing out. The pitch is that modern cloud warehouses and lakehouses can absorb data at scale, handle schema drift, and let the business self-serve. Some of this is true. The warehouses are better. The tooling is better. The economics are better. But the structural problem has not changed. The data still originates in fragmented source systems that don't know about each other. Unifying it in a warehouse gives you a place where all the fragmentation is visible at once. That is not the same as resolving the fragmentation.

Here's the pattern you can see if you've lived through all three waves. Each wave promised to fix the problem by collecting the data somewhere new. ERP collected it in one database. BI collected it in a warehouse. Cloud data platforms collect it in a lake. The collection is not the problem. The problem is that the data means different things in different systems, updates on different cadences, and represents different moments of reality. Moving it doesn't fix it. It just changes which team is responsible for reconciling it.

What actually fixes fragmentation is reasoning across systems, not moving data between them. A system that can look at the PM system and the ERP at the same time, understand that the percent complete in one should drive the revenue recognition in the other, and make the two agree continuously. A system that can read a change order in the PM tool and the budget in the ERP and flag the discrepancy at the moment it emerges. A system that can pull a vendor invoice, a PO, and a delivery receipt from three different places and reconcile them without moving any of them into a warehouse first.

This is a different architectural pattern than BI. BI is a downstream pattern. Data flows from source to warehouse to dashboard, and humans ask questions at the end. Reasoning across systems is an upstream pattern. Questions get answered at the source, continuously, without the data ever having to be extracted and consolidated. The warehouse is no longer on the critical path.

For construction IT leaders, the practical implication is this. The three-week-per-report problem does not get solved by adding more data engineers, buying a better BI tool, or modernizing the warehouse again. Those investments will keep the existing model alive. They will not change the shape of the backlog. Changing the shape of the backlog requires a different layer, one that sits across the systems rather than downstream of them.

The firms that figure this out next are going to stop having a BI backlog. Not because they get faster at building reports. Because the business stops needing as many reports, once the source systems are reasoning in agreement with each other in real time. The problem BI was supposed to solve finally stops being a problem, because it's solved by a different category of tool.