All writingAnalytics and BI · 6 min read

Self-serve analytics is a staffing decision, not a licence purchase

Every BI rollout ends with a few people building for everyone else. The mistake is treating that as a training failure rather than a fact to design around.

Apache SupersetPower BIsemantic layerdbtlineageAnalytics and BIGovernanceProfessional servicesPublic sectorSaaS

A company buys seats for everyone. Licences for the whole organisation, a launch email, a lunchtime training session with a slide saying "you now have access to all your data". Within a couple of quarters, a handful of people are building nearly everything anyone looks at. The rest have a channel where they ask those few for numbers.

Nobody has done anything wrong. The tool works. The data is there. What has failed is the assumption underneath the purchase: that the barrier between a business user and an answer is a login screen.

It is not. The barrier is knowing which of the revenue tables is the one finance signs off, knowing that the churn definition changed in March, knowing that the region field is populated by sales reps and is wrong for roughly the accounts that matter most. That knowledge lives in people. Buying licences does not distribute it.

The distribution is always the same shape

Across enough BI rollouts you stop being surprised by it. A small number of people produce most of the artefacts that get looked at. A slightly larger group edits filters on what those people built. Everyone else consumes, and when they need something new they ask a human. This holds whether the tool is Power BI, Superset, or something the team wrote themselves. It holds in small SaaS companies and in large public sector departments alike.

The standard response is to treat this as a training problem. Run more sessions. Make a certification. Gamify report creation. This works for a while, because the people who were going to become builders were always going to become builders, and the training gave them a reason to start. Then the numbers settle back to the same shape, and the department concludes that its users are not data literate.

Buying licences distributes access. It does not distribute the knowledge of which table finance actually signs off.
The pattern, stated plainly

They are usually fine. The person in accounts receivable understands ageing better than any analyst does. What they do not have, and should not be expected to acquire, is a working model of the warehouse schema, the join grain, and which of the date columns means what. Asking them to hold that alongside their actual job is asking them to do a second job badly.

What to design instead

If the distribution is going to look like that regardless, design for it deliberately rather than discovering it once the rollout has already gone quiet. Three things change.

01
Curate a modelled layer, not a raw oneThe thing business users touch should be a small number of wide, well named, tested tables built in dbt with a semantic layer on top, where metrics are defined once and every tool reads the same definition. Not the warehouse. The warehouse is a workshop, not a shop floor.
02
Name an analyst per functionNot a central BI team that takes tickets. A person who sits with finance, or with operations, whose job includes knowing what that function actually asks and building it before it is asked twice. The embedded analyst is the self-serve layer for most of the organisation, and pretending otherwise just makes the queue invisible.
03
Certify a small set and let the rest rot visiblyA handful of datasets and dashboards marked as maintained, owned, and tested. Everything else clearly marked as somebody's working sketch. The failure mode is not too few dashboards, it is too many of unknown provenance, so that nobody trusts any of them.

The three changes that survive contact with an actual rollout.

Two-column diagram. Left: every business user pointed at a tangle of raw warehouse tables with no agreed definitions, and the arrows converging on the handful of people who can read the schema. Right: the same users pointed at a small certified set, one dataset per function, each marked as owned, sitting on a semantic layer above the same unchanged warehouse. — The same population, two designs. Only one of them admits where the work actually happens.

The objections, taken seriously

This sounds like recentralising

It is, partly, and that is the uncomfortable bit. The decentralisation promise of self-serve BI was mostly a licensing argument dressed as an operating model. What is worth decentralising is the question and the judgement about what to do with the answer. What is worth centralising is the definition. Those are different things and the industry has spent years conflating them.

A board split down the middle. The left side, decentralise, holds the question worth asking, what to do about the answer, and who owns the decision it feeds, with a note that the person in accounts receivable understands ageing better than any analyst. The right side, centralise, holds what a metric means, which revenue table finance signs off, and the certified set, with a note that changing a definition becomes a code review. — Sort each item before arguing about the operating model. Almost every disagreement about self-serve is really about which side something belongs on.

Our power users like having raw access

Then give it to them. The argument is not that raw access should be revoked. It is that raw access should not be the plan for the majority. Keep a lane for the analysts and the few finance people who genuinely write SQL, and stop measuring rollout success by how many of the remaining seats logged in this month.

Would AI assistants change this

They change who can write the query. They do not change who knows which table is right, and a natural language interface pointed at an unmodelled warehouse produces confident answers from the wrong table faster than a human ever could. If anything, the case for a curated modelled layer gets stronger, because it becomes the thing that constrains what an assistant can reach. The failure mode moves from "I could not build it" to "I built it and it was wrong and nobody noticed", which is worse.

Where this advice is wrong

There are organisations where the raw-access-for-everyone model does work. They tend to be small, technical, and homogeneous: an analytics-heavy company where most staff have written SQL at some point and the schema fits in one head. If that is you, a semantic layer and a certification process is ceremony you do not need yet. Build it when the second person asks why two dashboards disagree, not before.

The other case where this is wrong is when the real problem is upstream. If the source data is genuinely bad, no amount of curation at the presentation layer helps, and building a beautiful certified model on top of an unreliable pipeline just moves the argument to a nicer room. Fix the ingestion and the tests first. That is less satisfying to launch and more likely to matter.

How to tell which situation you are in

Count the builders Not licences, not logins. How many distinct people created a dashboard that someone else opened in the last quarter. If it is a handful in an organisation of hundreds, the tool is not the constraint.
Ask where the questions actually go Look at the chat channels. If the volume of "can someone pull me" requests is steady or growing after a BI launch, that is the real interface, and it deserves to be designed rather than tolerated.
Check whether two dashboards disagree Pick a headline metric and find every place it appears. If the numbers differ, the missing piece is a shared definition, not more seats.
See who maintains what Take your most-viewed dashboards and name the owner of each. If you cannot name owners for most of them, the estate is already drifting and the next reorganisation will orphan the rest.

None of this requires replacing the BI tool. Most of the rollouts that stall have perfectly adequate software. What they lack is a small curated layer, a named person per function, and the willingness to say out loud that self-serve was always going to be served by somebody.