Self-Service vs Centralised BI: Choosing an Operating Model

"Should we go self-service or keep BI centralised?" gets asked as if it were a values question, tribal even, data democracy against a guarded central team. It is not. It is an operating-model decision, and like any operating model it comes with a headcount bill, a governance surface, and a failure mode. Choose it on those terms and the answer usually stops being an argument.

It is an operating model, not a belief

When I am asked to fix reporting in an asset-heavy operation, ERP, EAM, CAFM feeding a warehouse, the presenting complaint is rarely "we lack tools". It is "finance and operations quoted two different availability numbers in the same meeting" or "a report takes six weeks and by then nobody cares". Those are symptoms of an operating model, specifically of who is allowed to build what, against which definitions, and who carries the pager when a number is wrong.

So frame the decision the way you would frame any capability you have to staff and fund. Every model on the table answers three questions: how fast can the business get a new report, how confident is everyone that two reports agree, and how many analysts you must hire and retain to sustain it. Change one answer and you have changed all three. That is the trade you are actually making.

Reject both pure versions first

Before comparing options, throw out the two extremes, because they are the ones people argue about and the ones nobody should run.

Pure centralisation, where a single BI team builds every report, produces numbers everyone trusts and a backlog nobody can clear. The team becomes a queue. Requests wait weeks, urgent questions get answered in shadow spreadsheets anyway, and the "single source of truth" quietly forks in the corridors. You bought consistency and paid for it in speed and relevance.

Pure self-service, where anyone connects to anything and builds whatever, produces the opposite. Reports appear in hours and half of them disagree. Five people build "asset availability" five ways, each defensible, none reconciled, and the executive meeting turns into a debate about whose query was right instead of what to do. You bought speed and paid for it in trust.

Four models, five criteria

Between the two extremes sit two workable models. Here are all four scored against the five things that actually decide the outcome: time to a new report, consistency of numbers, analyst headcount required, risk of contradictory figures, and how well the model survives your best analyst leaving.

Two entries deserve a note. Fully devolved looks cheap on headcount because the analysts are not on the BI org chart, they are the operations planner who spends half her week in spreadsheets and the engineer who maintains "his" dashboard. That cost is real, it is just hidden. And on turnover, managed self-service wins precisely because the shared logic lives in a governed model, not in one person's head, so when the builder leaves, the page is rebuildable against a definition that still exists.

Where I draw the line for most operations

For most asset-heavy operations I recommend managed self-service on certified models, and the reason is the turnover row above as much as the speed. But "managed self-service" means nothing until you say exactly where the governed line sits, so here it is, without hedging.

• The central team owns the semantic model. Tables, relationships, and every shared measure, availability, MTTR, PM compliance, backlog, live in a governed model that one team maintains and versions.
• The central team owns security and definitions. Row-level security, access, and the written meaning of each metric are central responsibilities, not something a report author sets casually.
• The business builds report pages against that model. Analysts and department champions build visuals, pages, and their own local views on top of the certified model, freely and fast.
• Nobody connects to source tables directly. This is the line. No report author points at the EAM database or the warehouse raw tables. If it is not in the certified model, you request it, you do not route around it.

That single rule, build on the model, never on the source, is what keeps speed and consistency in the same room. It is also why the governance layer is worth naming and reusing across teams, which I cover in how I structure workspaces and pipelines.

What makes self-service actually viable

Managed self-service is not a licence switch. It is a set of capabilities you have to stand up first, and skipping any one of them quietly turns your managed model back into a devolved free-for-all.

• A trained champion per department. One named person per business area who knows the certified model, builds most of that team's pages, and is the first line of support. Without champions, every question lands back on the central team and you have rebuilt the backlog.
• A definitions catalogue. A written, findable list of what each metric means and how it is calculated. When someone asks "what counts as downtime here", the answer is a link, not a meeting. If a measure of adoption matters to you, that catalogue is also where usage data starts to mean something.
• A request-intake process. A single, visible front door for "I need a new field in the model" or "I need a new certified measure", triaged and prioritised, so demand on the central team is managed rather than ambient.
• Office hours. A recurring, predictable slot where the central team helps champions, unblocks builds, and reviews new pages. Cheap to run, and it is what keeps the community building correctly instead of drifting.

A twelve-month transition

You do not flip from a centralised backlog to managed self-service in a sprint. This is the staged path I use, roughly a year, with something concrete to measure at each stage so you know whether to proceed or hold.

Months 1 to 3: certify the core.

Build one certified semantic model for your highest-traffic domain, maintenance and asset performance is the usual choice. Agree and publish the definitions catalogue for its top ten metrics. Measure: number of shared measures certified, and whether two teams now quote the same number for the metric they used to argue about.

Months 4 to 6: recruit and train champions.

Name one champion per department, train them on the certified model, and stand up office hours and the request-intake front door. Central team still builds most pages, but champions shadow every build. Measure: champions in place versus departments, and central backlog age, which should start falling as intake replaces ad-hoc asks.

Months 7 to 9: hand over page building.

Champions now build their own pages on the certified model with central review. Direct connections to source tables are actively deprecated and cut off. Measure: share of new reports built by the business rather than central, and time-to-first-report, which should drop from weeks to days. Watch the contradiction rate; if it rises, you handed over before the definitions were solid.

Months 10 to 12: run it as a service.

Central team shifts from building reports to running the platform, model, security, catalogue, office hours, review. Formalise a certification path so business-built pages can be promoted to trusted. Measure: certified-content usage against total, adoption by active users, and central-team time spent on platform versus firefighting. A healthy end state has most reporting built by the business, on a model owned by the centre, with contradictions rare and traceable.

A note on where I stand, and the bottom line

A disclaimer, since I name a specific line: I sell integration and BI operating-model work, so read the recommendation with that in mind. I have no vendor relationship steering it. The managed self-service line, central owns the model, business owns the pages, nobody touches source tables, is the one I have watched hold up across ERP, EAM, and CAFM estates, and it is the one I would run whether or not there was a project in it for me.

So do not argue self-service against centralised as a value. Decide where the governed line sits, staff the capabilities that hold it, and move in stages you can measure. Get the definitions right first, and the rest of it, including a sane KPI tree, follows. If you want the vendor-neutral framing, Microsoft's Power BI adoption roadmap and the Gartner IT glossary are both reasonable places to align terms with stakeholders.