Business intelligence: what it is and how to turn data into decisions

If you're here looking for what business intelligence is, you're probably not after the textbook definition. You're here because your company keeps data in five different places, someone spends three days a month assembling a spreadsheet for the management meeting, and that spreadsheet arrives late with numbers nobody entirely trusts. Business intelligence exists for exactly that.

This guide explains what business intelligence is without the vendor gloss: what it does under the hood, which questions it answers well, which it doesn't, how to get to a dashboard someone actually uses, and which mistakes leave half of these projects as a pretty report nobody opens.

What is business intelligence, and how is it different from "running reports"?

Business intelligence is the set of processes and tools that pull data out of the systems the company already works in, unify it under agreed definitions, and present it so decisions can be made from it. Three parts: collect, unify, present. Miss one and it isn't BI.

The difference from "running reports" lies in the first two. Every ERP, CRM or invoicing tool has a reporting module: it gives you what lives inside that system, using that system's definitions. That's useful and not to be dismissed. The trouble starts when the question crosses systems: how much real margin did customer X leave once you count returns, shipping and support hours? That answer doesn't live in any one system; it lives in four, under four different definitions of "customer".

A typical example. In a company running both an ERP and a CRM, sales says 40 deals closed and finance says 34. Neither is lying. Sales counts when the customer confirms; finance counts when the invoice is issued. Without BI, that discrepancy gets re-litigated in every meeting. With BI it gets settled once: you decide what "closed deal" means, implement that definition in a single place, and both teams look at the same number.

The value of business intelligence isn't the chart. It's that you stop arguing about which of the two numbers is the right one.

How does a business intelligence system actually work?

Tools come and go, but the architecture is always the same four-link chain:

• Ingestion. Connectors pulling data from the ERP, the CRM, the website, the support desk, the logistics files. It can run nightly or near real time; nightly is almost always enough.
• Storage. A data warehouse where everything lands together, with history. This is the piece people forget to budget for, and without it there are no year-on-year comparisons.
• Transformation. This is where business logic gets applied: what counts as an active customer, how a discount is allocated, which orders are excluded. It turns data into metrics and eats the most hours.
• Visualisation. The dashboard the user sees. It's the tip of the iceberg — the part shown in demos and the part with the least work behind it.

The ratio surprises a lot of executives: in a typical BI project, ingestion and transformation take roughly 70-80% of the effort, and visualisation the rest. When a vendor shows you spectacular dashboards in the first meeting, they're showing you the cheap 20%. The expensive part is making the numbers inside them true.

There's a fifth element that isn't technical and decides the outcome: who owns each metric. If nobody owns the definition of "gross margin", that definition decays within six months. That's data governance, and the minimum viable version should be built alongside the BI work, not after it.

Which questions does business intelligence answer well — and which not?

Getting this straight saves a lot of disappointment. BI is excellent at describing what happened and comparing it; it's poor at predicting and useless at deciding for you.

| Type of question | Example | Does BI solve it? | |---|---|---| | Descriptive | How much did we sell by product family and channel last quarter? | Yes, this is its core case | | Comparative | Which branches are below target, and since when? | Yes | | Diagnostic | Which customers concentrate our returns, and on which product? | Yes, with the detail properly modelled | | Operational alert | Tell me when stock of an A-class item drops below threshold | Yes, via scheduled reports | | Predictive | Which customers will churn next quarter? | No — that's predictive analytics or machine learning | | Prescriptive | What price should I quote on this order? | No — that needs optimisation models |

Confusing predictive with descriptive burns the most budget. Nobody buys a demand-forecasting system thinking it's a dashboard, but plenty of people buy a dashboard expecting it to forecast. The good news: BI done properly is the prerequisite for predictive analytics. Models need clean history and stable definitions — precisely what the transformation layer produces.

How do you get from spreadsheets to a dashboard people use?

The route that works doesn't start by picking a tool. It starts by picking a decision.

| Phase | What happens | Typical duration | |---|---|---| | 1. Target decision | Pick 1 recurring, badly-informed decision (e.g. the weekly margin review) | 1 week | | 2. Metrics and definitions | Define the 8-12 metrics behind that decision, each with an owner and a written formula | 1-2 weeks | | 3. Sources and quality | Trace where each metric comes from and what's broken at source | 2-3 weeks | | 4. Model and load | Warehouse, ingestion and transformation for those metrics only | 3-5 weeks | | 5. Dashboard | Design it with whoever will use it, not for whoever signs it off | 1-2 weeks | | 6. Adoption | Retire the old spreadsheet, train, measure real usage | ongoing |

Three details that make the difference:

• One decision, not one department. "BI for finance" is an infinite scope. "The weekly margin committee decides using this" is a quarter's worth of work.
• Definitions before connectors. Start by wiring up systems and you'll end up with plenty of data and no metric anyone can stand behind.
• Kill the old spreadsheet. If the previous report survives, people keep using it and you now have two truths instead of one. Phase 6 isn't training, it's withdrawal of the substitute.

On phase 5: the most common mistake is designing a dashboard with 40 indicators so nothing is missing. A panel with 40 metrics informs no decision; it forces you to hunt. Eight well-chosen metrics, each with a comparison and a threshold, cut the meeting in half.

What does a business intelligence project cost, and how long does it take?

It depends on how messy the sources are, not on company size. Two companies with identical revenue can differ by a factor of three if one has a clean ERP and the other has fifteen years of parallel spreadsheets.

The real cost lines, usually in this order:

• Modelling and transformation hours. The bulk of it. This is where you pay down the debt in your source systems.
• Business hours. The people who know what each field means have to spend time on it. If their calendars aren't cleared, the project stalls.
• Infrastructure and licences. A cloud warehouse for a mid-sized company costs less than people fear; per-user licences on the visualisation layer cost more than expected once you scale to 80 people.
• Maintenance. Between 15% and 25% of the initial effort, every year. Source systems change, and the pipelines change with them.

On timing, a first dashboard answering a concrete decision should be in production within two or three months. If someone promises two weeks, they're plugging a tool into the ERP and calling it BI; if someone proposes nine months before the first screen, they're building a full corporate warehouse before demonstrating any value. Both extremes fail, for opposite reasons.

What sinks a BI project?

The patterns repeat with boring regularity:

• Choosing the tool before the questions. The platform comparison is the most entertaining conversation and the least decisive. All the major options do the same thing for 90% of cases.
• Modelling "everything, just in case". Loading 300 tables because they might be needed someday multiplies maintenance without producing a single decision.
• Mistaking access for adoption. Sixty people holding a licence doesn't mean anyone opens the dashboard. Measure weekly active users; it's the only honest indicator.
• Leaving quality for later. One wrong figure on a dashboard feeds distrust for months. Better to show fewer metrics and have all of them survive an audit.
• Not touching the process. If the meeting runs exactly as it did with the spreadsheet, BI has only changed the format. Value appears when the decision changes pace or criteria.

That last one is the same pattern we describe in why AI pilots fail: the technology works, but nobody changed how people work around it.

Business intelligence or artificial intelligence?

They don't compete — they sequence. BI tells you what happened and why; AI helps you anticipate or execute. And the order matters, because AI inherits the quality of whatever data you feed it.

In practice, if your company still argues about which sales figure is correct, investing in predictive models is building the roof before the pillars. It's the data before AI argument applied to a very specific case: the transformation layer a BI project builds is exactly the asset that later feeds a demand forecast or a churn-risk model.

The sensible sequence for a mid-sized company usually runs: agreed definitions → a warehouse with reliable history → dashboards in genuine use → a first predictive case on that same foundation. Each step reuses the previous one, and none requires throwing away what you built.

Frequently asked questions

Are business intelligence and business analytics the same thing?

They overlap heavily and most vendors use them interchangeably. Where a distinction is drawn, business intelligence leans towards describing and monitoring what has happened, while business analytics leans towards exploring why and what might happen next. The underlying data foundation is the same.

Do I need a data warehouse, or can I just connect the tool to my ERP?

Direct connection is fine for exploring and for single-system reports. The moment you need to cross sources, keep history or apply your own business logic, the warehouse stops being optional: without it, the logic gets duplicated in every report and drifts out of sync.

How many metrics should a dashboard have?

Between 6 and 12 on the main view, each with a comparison and a threshold. Everything else belongs in drill-down layers. A panel that makes you hunt for the relevant metric has already lost its purpose.

Can you do business intelligence without an internal technical team?

Yes, provided someone on the business side has the authority to settle definitions and the time to do it. The technical work outsources fine; agreeing what each metric means can't be delegated outside the company, because it's a business decision.

Business intelligence isn't a software project — it's the decision that everyone will look at the same number. If you recognise the symptoms in this guide in your own company (reports arriving late, figures that don't reconcile, a critical spreadsheet that depends on one person), the audit is a way to put on paper what data you have, where it lives, and which decisions you could inform first. And if you'd rather talk it through first, let's talk.