Business intelligence: what it is and how the stack fits together

The Tuesday pipeline review begins like most other months. The marketing dashboard shows 340 leads from last week, but the sales team reports only 290. The meeting pauses for twenty minutes to determine why two systems monitoring the same funnel produced different results. Both figures are technically accurate according to their respective platforms. This discrepancy in business intelligence is the primary issue.

Business intelligence consists of the tools and methods used to convert raw company data into actionable figures. This process includes the pipelines that gather data, the models that structure it, and the dashboards that display it. These systems are descriptive because they explain past events instead of forecasting future ones. This work requires consistent and agreed-upon definitions for all metrics.

Business intelligence consists of the tools and methods used to convert raw data, such as orders, tickets, page views, and stock movements, into information that people can use to make decisions. This process includes the systems that collect data, the models that organise it, the reports that display it, and the routines people follow to use these resources; the term is used broadly. A business intelligence system might refer to a single manual spreadsheet or a large data warehouse that supports dozens of automated dashboards. This wide range of definitions makes it difficult to discuss the subject clearly.

Shipshape Data builds data and AI systems for clients. Business intelligence is usually the first thing we inherit rather than the first thing we design.

We find that problems rarely originate within the dashboard. The issues usually exist in the data sources. This happens when three departments use three different definitions for an active customer. It also occurs when a semantic layer is missing, which leads every analyst to write their own version of the same calculation. We also see failures in self-service rollouts where two hundred people receive a query tool without any shared definitions for the data they are analysing.

This guide explains the definition of business intelligence and the components of a functional data stack. It describes the differences between reporting and analytics and explains why self-service business intelligence leads to governance issues as it scales. The text also covers the purpose of a semantic layer, the reasons organisations often omit it, and the relationship between business intelligence, data science, and artificial intelligence systems.

The definition of business intelligence

Business intelligence remains a well-established concept when marketing jargon is stripped away. It consists of examining both historical and present data and delivering it promptly so that an individual can act. Examples are revenue by region, orders that missed delivery windows, and product lines showing declining margins. The process does not incorporate predictions. It depicts current facts or the data state as of the latest update.

Descriptive by design

The narrow focus is deliberate. A finance director does not need a model to forecast revenue for the next quarter when the current revenue figures remain unreliable. Business intelligence's role is to guarantee descriptive accuracy before tackling more complex tasks. A company that cannot answer "how many customers do we have" confidently should not employ a model to predict how many customers it will have next year.

Older than the term suggests

The term business intelligence has been used by people since the 1980s. It referred to decision-support systems long before dashboards became common. The basic concept stays the same, although the technical infrastructure has evolved. Cloud warehouses have taken the place of on-premise servers, and drag-and-drop tools have taken the place of manual SQL reports. Data refresh cycles have shifted from monthly intervals to near real-time. Despite these changes, the fundamental goal of identifying what happened and who needs the information stays constant.

The stack underneath every dashboard

The dashboard constitutes the visible part of the project, yet it accounts for the smallest portion of the work required.

A series of components underpins this process. When any segment of the system fails, the data produced becomes unreliable. This problem is frequently spotted in meetings. Our guide to business intelligence architecture details the entire process thoroughly. Below is a summary of the main points.

Sources, the pipeline, and the warehouse

Everything begins with source systems: the CRM, the ERP, the support desk, the website. A pipeline extracts data from those systems and loads it into a central location, usually a cloud data warehouse or lakehouse, on a schedule that can range from nightly to near-instant depending on how much the business is willing to pay for freshness. This portion of BI overlaps heavily with data engineering. That overlap is precisely why weak plumbing appears downstream as an incorrect number, not as a system error that triggers an alert.

The modelling layer nobody notices until it is missing

Raw data is rarely ready for reporting when it is first collected. Analysts must carry out tasks such as joining order tables to customer tables and calculating margins from cost and price fields stored in separate systems. They also need to define time periods like "this month" for businesses that use fiscal calendars instead of standard ones. This data modelling makes up the majority of the work in business intelligence, yet it is the part that executives see the least when they look at a finished chart.

Visualisation, the part everyone judges the whole stack by

Your organisation might employ dashboard tools such as Power BI, Tableau, or Looker. These tools sit on top of your data and present modelled information in a format that a person can review quickly. This is the most visible part of the system. However, when a figure is incorrect, this layer is rarely the source of the error. A well-designed dashboard that relies on an ungoverned data model will simply deliver incorrect information in a convincing way.

Reporting and analytics are not the same job

Most business intelligence teams use these two words interchangeably. Treating them as synonyms often leads to cluttered dashboards.

Reporting answers a known question, repeatedly

Reporting describes past events on a fixed schedule and in a prearranged format. Examples include weekly regional sales, monthly headcount, and daily fulfilment scorecards. The questions remain constant while the data updates. The value of a report lies in its consistency. By using the same definitions and filters, the same people can trust the same figures. This prevents them from debating the meaning of the data every time they receive it.

Analytics answers a question nobody has asked yet

Analytics functions as an investigative process. It pinpoints the reasons for churn increasing in the north region during March. It determines which of the twelve marketing channels produced closed deals instead of merely new leads. This work is exploratory and typically consists of one-off tasks. The final output gives an answer to a specific question rather than creating a recurring product.

The financial impact of confusion

If you mix up these two tasks, you will encounter one of two problems. In the first scenario, each analytical question turns into a permanent dashboard. This causes the business intelligence team to maintain hundreds of reports that are seldom used. In the second scenario, recurring reports are handled as one-off requests. This forces an analyst to rebuild the same report each month rather than doing more valuable work. A team that knows which specific task it is performing at any moment will be more efficient. They will waste less effort than a team that treats "make me a dashboard" as the answer to every request.

The semantic layer: where BI stops arguing with itself

This article started due to a specific error. The marketing department reported 340 units, whereas the sales department reported 290 units. This was not purely a data quality problem. Both systems held accurate information. The discrepancy arose from the definitions used to decide what counts as a lead and when it should be counted. A semantic layer is intended to resolve this kind of inconsistency.

One definition, used everywhere

A semantic layer sits between the raw modelled data and the tools that query it. It stores business definitions centrally. This includes the definition of an active customer, the revenue calculation, and the specific date field used for orders when multiple tables contain date information. All reports, dashboards, and ad hoc queries use these shared definitions. Users do not create separate versions of this logic in their individual tools.

Reasons most organisations avoid this process

Creating a semantic layer is a slow process that yields no visible results for several months. It does not produce a dashboard that can be shared or screenshotted. Instead, it establishes standardised rules that support other systems. For this reason, it is often the first task cut when a business intelligence project faces a tight deadline. The consequences of skipping this step do not appear immediately. They usually appear much later, for example when a new employee creates a report using a different definition of a customer. These errors often remain unnoticed until leadership spots conflicting growth figures within the same reporting document.

A semantic layer is simple to build, yet it is one of the few ways to stop five people from producing five different versions of the same metric.

What good looks like

A semantic layer works well when it is managed by someone authorised to reject metrics that do not match agreed definitions. It should be versioned like code to track changes and integrated so that business intelligence tools query it directly instead of bypassing it. When implemented poorly, a semantic layer turns into a static document in a shared drive that accurately described definitions in 2024 but has not been updated since.

Self-service BI and the governance problem it creates

Companies adopted self-service tools to address a specific bottleneck. Business users often waited weeks for the BI team to create reports that they could have completed in an afternoon using the correct software. This approach works. However, it creates a new issue once it becomes successful. This problem is rarely discussed during the sales process.

The specific bottleneck that it eliminates

Marketing analysts do not need to wait for a central team with a large backlog when they have drag-and-drop tools linked to governed data. They can answer questions the same day instead of waiting for the next sprint. This approach is more efficient for simple questions that use clean data. There is no need to involve a specialist for these routine tasks.

The issue this creates without being noticed

Two hundred people building their own reports will make two hundred different decisions about how to define terms such as "revenue" or "active user" if there is no semantic layer. Without this layer, self-service BI increases the fragmentation it was meant to fix. This leads to more contributors and less clarity about who created specific definitions.

Governance that does not undo the point of self-service

Removing access goes against the goal of self-service. A more effective solution puts a semantic layer and a small group of certified datasets in front of the self-service tools. This lets users explore data from a shared foundation instead of using raw tables with many unclear columns. You should certify the most important metrics while keeping other data open for exploration. You must also review the created reports regularly. Do not assume users will always follow best practices. This approach applies the discipline of data governance to the specific situation where a company provides query access to many people at once.

Where BI ends and data science begins

People often view business intelligence and data science as different stages on the same technical scale. These fields are related, yet they address different types of questions. Confusing the two disciplines often leads to business intelligence teams receiving requests that their specific tools cannot fulfil.

Looking back versus looking forward

Business intelligence is descriptive. It explains past events. Data science uses predictive and prescriptive methods to explain what is likely to happen or what actions to take. A dashboard that shows which customers left during the previous quarter exemplifies business intelligence. A model that assigns a score to current customers based on their likelihood of lapsing next quarter is data science. This process depends on statistical or machine learning methods that standard business intelligence tools do not include.

Where the two areas actually coincide

These two fields share a foundation, making the practical distinction between them less clear. Predictive models rely on the quality of their input data. This data typically comes from the same warehouse and semantic layer used by the business intelligence stack. If a company has not established basic reporting, its data is usually not clean enough for a model to produce useful results. Consequently, data science projects built on an unstable business intelligence foundation often produce poor results without showing obvious signs of failure. Our guide to data engineering versus data science explains where these roles diverge and how they remain connected.

A test worth applying before commissioning either

If the question is "what happened", it is a business intelligence problem. The solution is a dashboard, a defined metric, or better data modelling. If the question is "what will happen" or "what should we do", it requires a data science approach. Additional dashboards will not solve those problems. Many requests that start as "can we get an AI to do this" are actually reporting requests. A proper business intelligence stack would already provide those answers.

What changes when AI sits on top of BI

Natural language querying allows users to ask a chatbot for specific data, such as sales figures for a particular region and time period, and receive a response in plain text. This method removes the need to open a dashboard. While the technology functions, it also adopts the flaws of the underlying business intelligence system. These issues often occur without providing any clear indication to the user.

The model answers confidently either way

If you ask an AI assistant for last month's revenue, the system must know how your business defines that term. It needs to know if you mean gross or net revenue, booked or recognised revenue, and which entities to include. If that definition is stored in three different places with three different answers, a person reading a report might notice an incorrect figure and verify the data. A language model does not perform that check. It provides a clear and confident number based on whichever definition it located first. It does not indicate that the underlying figure was inconsistent.

Why the semantic layer matters more here, not less

You should build a semantic layer even if your business stakeholders have not requested one. An AI layer used for business intelligence is only reliable if the underlying definitions are unified and governed. Artificial intelligence models cannot determine if a number is ambiguous. The model will answer a question using any data provided. It will express the same level of confidence regardless of whether the metric is verified or disputed.

What this does not mean

You do not need to delay using AI-assisted BI until every business metric is perfectly governed. Few organisations achieve that level of consistency. You should instead identify which metrics the AI layer is permitted to use when answering questions. Keep any disputed metrics away from the AI until they have been resolved.

Where to start

Do not begin by looking for a dashboard tool. Instead, choose the two or three metrics that cause the most disagreement in your organisation, such as the lead count mentioned earlier. Trace each of these metrics back to its source. Determine how many different calculation methods are currently in use and identify the people responsible for them.

Performing that exercise honestly usually identifies the actual problem faster than evaluating tools. The issue is rarely a lack of charts. Instead, it is a lack of agreement. You should write down the definition, assign an owner, and create the smallest possible semantic layer for those specific metrics before you expand. You can then decide which questions require reporting, which require analytics, and which are actually requests for predictive models disguised as business intelligence requests.

Effective business intelligence consists of basic data management that supports all other functions, including artificial intelligence. You may need to evaluate if your current data structure can support AI tools. You may also find that different departments present conflicting data in meetings. If these issues occur, talk to us. We prefer to help you establish correct data definitions now rather than see incorrect processes automated and expanded.

If your reporting no longer meets your needs, you can use our data consulting services for assistance.

Frequently asked questions