Self-service BI sounds straightforward until you look at the Power BI report stack you've built over the years. Multiple reports, overlapping KPIs, different semantic models, and business users still coming back for new variations. Somehow, every new analytical need seems to lead to another dashboard.
It's like a traffic jam where everyone is being sent down the same road. Instead of building more roads, perhaps we need to understand where people want to go and give them different routes. That's how I've started thinking about self-service BI.
In my recent BI Bits edition,The Definition of Self-Service BI Needs an Update, I explored why giving users more ways to build reports isn't enough. But what does that mean for an established BI environment? If I were to rethink self-service across an existing Power BI report stack today, what would I actually do differently?
Inside this article
- How did we end up with so many reports?
- Deciding what to keep, redirect, or enable
- 3 analytical products and 3 traps to avoid
- Who owns what in a self-service environment?
- How do we stop the report stack from growing back?
- How do we know self-service is actually working?
Start With the Portfolio, Not the Technology
Most reporting portfolios don't become difficult to maintain because someone made one big architectural mistake. They grow gradually.
A regional variation becomes a separate report, a new requirement introduces another KPI calculation, and a quick solution built for one team eventually becomes something the business depends on. Each decision may have made sense at the time, but years later, we're maintaining the combined result.
That's why I'd start by understanding the existing report stack before deciding what self-service capabilities to introduce. Power BI Admin tools and usage data can help map reports, semantic models, dependencies, and consumption patterns.
But I'd also want to understand what users do after opening a report. Are they making decisions from it, exporting data to finish their analysis, or requesting changes because the existing solution doesn't give them enough flexibility?
WHAT USAGE TELLS US
Usage metrics tell us what happens inside Power BI.
WHAT WE NEED TO UNDERSTAND
Understanding self-service starts with what users do after opening the report.
I'd then organise the portfolio around analytical products, connecting related reports and semantic models to the business needs they serve. A shared product registry and asset inventory would give us a starting point for identifying overlap, ownership gaps, and opportunities to reuse what already exists.
The point isn't to document every asset for the sake of it. It's to understand where our existing BI investment can support more business needs without continuously expanding the report stack.
Decide What Needs to Change, Not Just What Needs to Stay
The tempting next step is to look for duplicate reports, check usage numbers, and start building a list of what to consolidate or retire. I probably would have approached it that way earlier in my career.
But I've learned that two reports showing similar KPIs aren't necessarily solving the same business problem, and a report with limited usage isn't automatically one the business can live without. I'd approach this differently now. For each analytical product, I'd sit down with the business owner and understand why its reports exist in their current form.
01
Why was a separate regional version needed?
02
Why are users exporting data instead of working within the report?
03
Why does the same team keep requesting small variations?
Those conversations often reveal that the problem isn't the number of reports, but the way we're trying to meet different needs through reports alone.
This is where I'd apply the KEEP / REDIRECT / ENABLE approach from BI Bits. Some reports should stay, some requirements could be redirected towards controlled exports or alerts, and others might be better served by enabling users to explore approved semantic models themselves.
Not every report needs to disappear. Not every request needs another report. And not every analytical need should depend on the BI team.
From Portfolio Assessment to Implementation
This is where I'd avoid turning the assessment into a long list of reports to rebuild or retire. I'd select a small implementation wave across a few analytical products, each with a different problem to solve. The idea is to make meaningful changes within the existing BI delivery cycle, not launch a separate transformation programme that competes with everything else the team is already maintaining.
Consolidate
3 regional reports. Similar KPIs. Different business needs?
Enable
Regular Excel exports. A need for more flexible analysis.
Automate
Daily dashboard checks. An opportunity to deliver exceptions.
For Product ABC, where three regional reports share similar KPIs, consolidation might look like the obvious next step. But I've learned not to confuse similar-looking reports with genuinely duplicated logic. I'd compare business definitions, semantic models, RLS, and downstream dependencies before deciding what can be brought together.
Consolidating reports before understanding why they became separate in the first place.
We could end up with one report that's harder to maintain and still doesn't meet everyone's needs.
For Product DEF, where users regularly export data to Excel, I'd first understand what happens after the export. If they need filtered records, controlled extraction might be enough. If they're building recurring calculations and views, access to an approved semantic model could be more useful.
Treating Build permissions as the self-service solution.
Once users build on a shared model, we also need clear ownership, approved KPIs, access rules, and expectations around refreshes, changes, and support. Otherwise, we're simply moving the maintenance problem outside the BI team's immediate visibility.
For Product GHI, where users open a dashboard every morning to check exceptions, I'd test whether alerts could remove that routine. But I'd run the new experience alongside the report and validate it through real business cycles.
Assuming that automating the notification means we've improved the process.
If alerts miss important exceptions, reach the wrong people, or leave users without a way to investigate, we've made the experience less reliable rather than more useful.
I'd manage all three changes through the normal Jira or Azure DevOps backlog and release process, with an agreed business outcome, affected dependencies, and a validation point before retiring or replacing anything. The analytical product inventory should be updated as part of that delivery process, not through a separate documentation exercise.
Don't just prove that three solutions work. Learn what it takes to develop, validate, and support them before scaling across the portfolio
What Actually Changes for the Business and the BI Team?
One thing I've learned is that giving business users more flexibility doesn't automatically reduce the BI team's workload. If every business-created report eventually becomes something developers are expected to troubleshoot and maintain, we've simply added another reporting layer.
Self-service only changes the way we work when both sides understand what they can expect from each other.
I'd make those responsibilities clear as part of the rollout, not leave users to discover them when something breaks:
Business users
Local analysisExplore approved data, create team-specific analysis, and maintain their local reporting needs
Analytical product owners
Shared requirementsPrioritise shared requirements and decide when local analysis should become an officially supported capability
BI developers
Supported solutionsMaintain shared KPIs, semantic models, security, performance, and centrally supported solutions
But documenting responsibilities isn't enough. I'd introduce the new approach through short, product-specific sessions with business users: show them what they can already do independently, where to find approved data, how to request access, and when a requirement should come back to the product owner. I'd also give them a clear route to request support or propose that a useful local solution becomes part of the official product.
That last point matters. A report created by one sales team might eventually be used across several regions. Once people start depending on it, ownership and support expectations need to change.
I'd rather make that transition deliberate than wait until the original creator leaves and everyone assumes the BI team owns the report. For me, the shift is about giving the business more room to work independently while making the BI team's responsibilities clearer and not simply transferring report development from one group to another.
Make Self-Service Part of the Normal BI Workflow
The real test comes after the first implementation wave, when business requests start coming in again. It's easy to agree on a better approach during a portfolio review and then fall back into the familiar routine: a user requests a dashboard, we discuss the requirements, and development begins.
Unless we change that routine, the report stack will eventually grow back into the same problem.
I'd introduce a few checks into the existing Jira or Azure DevOps intake process. Before accepting a new development request, the analytical product owner and BI team should assess how the business need can be supported using what we've already built.
Before We Build
5 checks to make before adding another reporting asset.
Is the requirement already covered by an existing solution?
Reuse it or address what's preventing the user from using it.
Does the user need flexibility beyond the current report?
Assess controlled exports or self-service through an approved semantic model.
Does the requirement introduce shared KPIs or business logic?
Extend the existing analytical product rather than recreate the logic elsewhere.
Is a new reporting experience genuinely needed?
Build it within the relevant analytical product.
Does it represent a distinct analytical responsibility?
Assess whether a new analytical product and owner are justified.
I wouldn't expect business users to navigate the report portfolio or understand which semantic model supports which dashboard.
The problem, the intended users, and what they need to do with the information.
The right analytical solution, rather than simply delivering the format that was requested.
Any new assets should then enter the product inventory through the normal development and release process. For me, this is where self-service starts becoming sustainable. Not because we've introduced another approval process, but because we're making better decisions about what deserves development effort before adding something new to maintain.
How Would I Know It's Actually Working?
A successful rollout doesn't necessarily mean successful self-service. You can retire reports, publish reusable semantic models, and enable more users without making much difference to how the business operates.
The real test is whether the same work now takes less effort from both the business and the BI team.
Start with a baseline before implementation, then measure each analytical product against the problem it was meant to solve:
3 Products. 3 Different Measures of Success.
Report consolidation
Duplicated KPI logic, reconciliation issues, and maintenance hours
Less effort keeping regional solutions aligned, without losing necessary functionality.
Self-service analysis
Repeat export requests, manual extracts, and recurring report enhancements
Users complete their analysis without repeatedly returning to BI for small changes.
Alerts and workflows
Routine report checks, missed exceptions, and actions taken
Less time spent looking for problems, without missing the ones that matter.
Review these outcomes after a few real business cycles, not immediately after deployment. A drop in report views might signal poor adoption for one product and a successful shift towards alerts for another. That's why portfolio-wide usage figures alone can be misleading: the same metric can tell a completely different story depending on what the analytical product was designed to achieve.
Don't measure self-service by how much you've enabled. Measure how much unnecessary work you've eliminated.
Closing Thoughts
Having worked on enterprise BI environments for years, I've seen how easily a reporting portfolio grows while nobody really questions whether the way we're delivering analytics still makes sense.
We keep improving dashboards, adding requirements, and building new solutions, but rarely find the time to revisit what we've already created. Eventually, maintaining that portfolio starts taking time away from improving it.
For me, being an Analyst in Action is about recognising when the next step isn't to build something new, but to challenge how we're solving the problem in the first place. Earlier in my career, another dashboard request would have sent me straight into Power BI.
Today, I'm more interested in whether we can meet that need through something we've already built. Because sometimes the most valuable BI work is making sure the business doesn't need to come back to us for the same thing again.
Comments
Join the discussion below (GitHub login required), or share your thoughts on LinkedIn . Iām most active there.