Every department has its data, but no one has the full picture. Sales looks at the CRM, logistics at the ERP, marketing at five different tools — and every cross-functional question means someone spends days building a spreadsheet. According to Gartner, only 12 percent of companies have data of sufficient quality for AI applications. BigQuery on Google Cloud addresses exactly this problem: a central, maintenance-free data foundation that answers reports in seconds and feeds AI models from the same data.
The situation everyone knows and no one planned for
No company decides to scatter its data. It just happens. The ERP came fifteen years ago, the CRM eight years ago, the online store five years ago — plus the marketing tool, the ticketing system, and the spreadsheets that appeared somewhere between systems and never went away. Each system works fine on its own. Together, they create a situation where the simplest questions are the hardest to answer.
What does a customer cost us over the entire relationship? Which products are bought together, and how does that affect inventory planning? Why are returns rising in one region but not another? Each of these questions requires data from at least three systems. And in most companies, that means someone exports, copies, joins, and spends days building a report that is already outdated by the time it is finished.
The downstream costs of this situation are well documented. Depending on the survey, analysts spend between 45 and 80 percent of their time finding and preparing data rather than analyzing it. And for anything related to AI, this situation becomes disqualifying: according to Gartner, only 12 percent of companies have data of sufficient quality for AI applications, and 85 percent of failed AI projects cite data quality as the cause.
What a data foundation needs to deliver
The answer to scattered data is a central place where it converges and becomes queryable. The concept is not new — it used to be called a data warehouse, and it had a poor reputation: expensive to acquire, slow to build, rigid to operate, and already too small after two years.
Today's generation addresses exactly these pain points. BigQuery is Google Cloud's data foundation and operates serverless. That means there are no database servers to size, patch, or scale. Data is loaded, queries are run, and the platform handles everything underneath. A query across billions of rows takes seconds, whether it runs once a month or a hundred times a day. You pay for usage, not for reserved capacity. The principle is the same as the one we described in our article on serverless with Cloud Run — just applied to data rather than applications.
In practice, this represents a shift that should not be underestimated. The question is no longer whether the infrastructure can handle a query. The only question is whether the data is there and what you want to know. That sounds trivial, but it changes how an organization behaves. When answers take seconds instead of days, more questions get asked. And companies that ask more questions make better decisions.
Reporting and AI share the same path
The most common mistake in data initiatives is treating analytics and AI as separate projects. First we build the reporting, then we do AI later. In reality, both need the same foundation: clean, consolidated, current data in one place. Lay the foundation for one, and you already have it for the other.
BigQuery makes this connection particularly short. The same tables that power the management dashboard also feed the models. Machine learning functions are available directly in the database, and the connection to Vertex AI, Google Cloud's AI platform, is a well-defined path rather than an integration project. An example makes this concrete: a retailer consolidates orders, returns, and web behavior in BigQuery. First, this produces a report showing which products have above-average return rates. Then an analysis that identifies the drivers. And finally a model that predicts return risk before the order is placed. Three stages of maturity, one foundation, no system changes in between.
Why this sequence matters so much is something we have already explored from a different angle: AI initiatives almost never fail because of the algorithm — they fail because of the data foundation underneath. BigQuery is the infrastructure answer to exactly that problem.
What BigQuery does not solve
The honest part belongs here too. BigQuery answers the question of where your data comes together and how quickly it can be queried. It does not answer the question of whether your data is correct. If the ERP uses different customer IDs than the CRM, if product data exists in three versions, if no one knows which field holds the truth — those contradictions will simply be centrally available after loading, but they will still be there.
Two topics therefore belong alongside the platform. The first is the pipelines: automated, regular feeds that pull data from source systems instead of waiting for manual exports. The second is ownership: you need people who are responsible for the quality of specific data domains, and clear rules for what applies when there are conflicts. How to organize that ownership is something we covered in our article on data stewardship. Platform, pipelines, and ownership together form the foundation. Each element on its own remains incomplete.
How to get started without turning it into a major project
The worst way to build a data foundation is the two-year project that insists on connecting every source before answering the first question. Projects like that lose their supporters long before they deliver value.
The better approach starts with a question that no one can answer today and that someone in management genuinely cares about. For that one question, the two or three necessary sources are connected, the data is consolidated, and a first dashboard is built. That takes weeks, not years. The answer to the first question generates the second, and with each question the foundation grows toward where the real need lies. After a year, you have a data platform that is demonstrably in use — because it grew around real questions rather than around a diagram.
One practical note on data sovereignty: BigQuery runs in German and European regions as well, with the data boundaries we described in our article on the sovereign cloud. The question of whether your data is allowed to go there now has a solid answer.
What the path looks like in practice: from question to dashboard
A worked scenario shows how this unfolds. A retail company wants to know which customers are about to churn before they actually do. Today, that question cannot be answered — orders are in the ERP, customer behavior is in the online store, and service interactions are in the ticketing system. The path to a data foundation begins with exactly this one question, not with an architecture diagram.
In the first few weeks, the three sources are connected via pipelines and run automatically into BigQuery every day. A unified customer profile takes shape: order frequency, basket trends, returns, service contacts — all in one place, linked by customer ID. This is also where data quality immediately becomes visible: customers who exist under four different IDs across three systems now show up as a problem. That too is a result — an uncomfortable and valuable one.
From the customer profile, a simple dashboard emerges first: customers whose order frequency has dropped significantly compared to their own historical average. That is not yet AI, just straightforward arithmetic — and the sales team starts using it from the first week. The modeling stage comes afterward, on the same data, with better predictions. The point of this scenario: between the first question and the first usable result, weeks pass, not months. The organization learns from a real case, and every subsequent question builds on the foundation that is already there.
What role your team plays
A data foundation is not a purely technical project, and how roles are defined determines whether it lasts. Three roles carry the initiative. The business side asks the questions and judges whether the answers are right — only they can tell when numbers look plausible but are actually wrong. The data role builds the pipelines and the data models: table structures that can support the third and fourth question, not just the first. And the ownership role ensures that quality does not happen by accident: who maintains what, which source takes precedence when there are conflicts, how new fields are onboarded.
The third role is the one most often forgotten and most expensively missed. A foundation without clear ownership deteriorates just as reliably as a building without a caretaker. The good news here as well: none of this requires a large team. It requires clarity about who carries each of the three roles, and the willingness to take them seriously.
The first step is a question
If you want to know whether this topic is relevant for your organization, you do not need a three-month assessment. You need the one question your company cannot answer today, even though the data exists somewhere. Write it down. Count the systems where the answer is scattered. And estimate what it costs that no one is answering it.
That is exactly the question we use to start data projects: connect the sources, consolidate them in BigQuery, deliver the answer, then expand from there. Our own infrastructure runs on Google Cloud, as does that of several of our clients. You can find the starting point on our Google Cloud page. All analyses are available in our Google Cloud Insights.