8 things about business intelligence worth your time

Business intelligence is the function that turns what a company recorded about its own operations into things people act on. Everything about how well it works is decided by two choices that sound administrative: what gets built once and reused, and who is allowed to answer a question without asking the data team.

Get those wrong and you have a group of skilled people writing the same query for the fourth time while a queue of requests grows behind them.

What to take away

The output of a working intelligence function is decisions, not deliverables. Count what changed, not what shipped.
Build once, in a shared layer, and point everything at it. Query-per-request does not survive growth.
The request queue is a symptom. Read what people ask for repeatedly and turn it into something they can answer themselves.

Reporting, analysis, and a request that is neither

Three kinds of work arrive at the same team, and they have different economics.

Three kinds of BI work

Reporting

Question: Known, repeated
Value: Reliability
Output: Built once
Risk: Needs monthly care

Analysis

Question: New, once
Value: Judgment
Output: A paragraph
Risk: Becomes reporting

Support

Question: Ad hoc number
Value: Unblocking
Output: One-off answer
Risk: No natural end

Reporting answers a known question repeatedly. The value is in reliability and in nobody having to think. Reporting should be built once and then left alone, and if a report needs attention every month, it is not finished.

Analysis answers a new question once. The value is in judgment, and the output is usually a paragraph rather than a chart. Analysis does not become reporting just because someone liked it.

Support is somebody needing a number to get on with their day. It looks like the least important of the three and it is the one that consumes the team, because each request is small enough to say yes to and there is no natural end to them.

Track which of the three your team spends its hours on. Most teams find support is the majority, and that discovery is what justifies building the self-serve path that removes it.

The layer that has to exist

Somewhere between raw tables and the things people look at, there has to be one place where a business concept is defined in code. What counts as an active account, a completed order, a qualified opportunity. Defined once, computed once, referenced everywhere.

Without it, every chart carries its own copy of the logic, and copies drift. The drift is silent and it surfaces in a meeting, which is the most expensive possible moment for it to surface.

With it, three things get easier. A definition change happens in one place and propagates. A new person can read what a term means rather than reverse engineering a query. And when two numbers disagree, the question becomes which one skipped the layer, which is answerable in minutes.

The rule that keeps it healthy: nothing published to a general audience is allowed to define a governed concept for itself. If a chart needs a concept the layer does not have, that is a request to extend the layer, not a reason to work around it.

Self-serve, honestly

Self-serve is sold as giving everyone access to the data. That version fails predictably: people are handed tables, no two of them count the same thing, and the data team spends more time adjudicating than it saved.

What actually works is narrower and more useful. Self-serve means a person can answer a question that has already been anticipated, using concepts that are already defined, without writing anything. Filtering a governed metric by dimensions that were prepared for it. Changing a date range. Splitting by a segment somebody has already modeled.

That is a smaller promise and it covers most of what people actually want, which is nearly always a variation on a question the team has answered before.

Two things make it work. Genuine self-service means the prepared paths cover the common questions, which you learn by reading your own request queue rather than by guessing. And there has to be an obvious route for the questions self-serve cannot handle, so people ask instead of building something private and wrong.

Reading the request queue

The queue is the best product research the function has, and most teams treat it as a chore.

The same question asked by different people is a missing prepared path.
Requests that arrive right before a recurring meeting are a missing report.
A request for raw rows usually means a modeled concept is missing, not that the person wants rows.
Urgent requests clustering around one team means that team has no view of its own work.
A question nobody can answer without a week of work is a data gap. Record it, because it will be asked again.

Categorize for a month. The pattern that emerges tells you what to build with more authority than any roadmap conversation.

What people do after they export

Watch a number leave your system. Almost every one of those steps is a small piece of extract, transform, and load being done by hand.

The step someone performs in a spreadsheet after exporting is a missing feature in your modeled data. It is the most reliable signal available for what the function should build next.

Common versions: joining your number to something the company holds elsewhere, reallocating a total across a hierarchy that only exists in someone's head, or applying an adjustment that is really a business rule nobody wrote down. All three are candidates for the shared layer, and all three are currently being done differently by every person doing them.

Banning the export does not work and is not the point. The point is to notice it.

How the function fails

It measures itself by output. Dashboards delivered, tickets closed, queries written. None of these say whether anything changed. The harder and better question is which decisions were made differently, and it is answerable if you ask the people who made them.

It becomes a service desk. Every request answered individually, nothing built for reuse, and a queue that grows exactly as fast as the company does.

It builds for an imagined user. A page designed for how someone should work rather than how they do work gets opened twice. Watch what is actually used, and retire what is not.

It sits downstream of everything and upstream of nothing. If the teams building source systems change events and schemas without telling anyone, the function spends its life repairing. Getting into those conversations early is worth more than any modeling improvement.

It cannot say no. A function that accepts every request has, in practice, no priorities, and the work that would remove whole categories of request never gets started.

A realistic starting sequence

Log every request for a month, categorized as reporting, analysis, or support.
Take the handful of concepts that appear across the most requests and define them once, in code, in a shared place.
Rebuild the most-used existing report on top of those definitions, and retire the old one rather than leaving both.
Prepare filterable paths for the two or three questions that were asked most often.
Publish where numbers come from and what they exclude, next to the numbers.
Re-log requests for a month and compare. The support share is the measure of whether any of this worked.

Common questions

Should the team be central or embedded in each business unit?

Both arrangements work and both fail in known ways: central teams get distant from the questions, embedded ones produce definitions that diverge. The arrangement matters less than whether there is one shared definition layer, which is what actually prevents the divergence.

How do we handle a request we think is the wrong question?

Answer the question asked, then say what you would have looked at instead and why. Refusing to answer costs you the relationship, and answering silently costs the company the better analysis.

What do we do about the spreadsheet somebody maintains by hand?

Find out what it does that your system does not. It usually encodes a real business rule nobody has written down. That rule belongs in the shared layer, after which the spreadsheet retires itself.

How do we know if any of this is working?

Watch for absences: fewer meetings derailed by which number is right, fewer one-off requests for things that were asked last month, faster answers to where a figure came from. Those are observable without inventing a score for them.