AI & Data
One number,
one definition, one owner
Most BI programmes produce dashboards nobody opens and four versions of revenue. We start from the decisions being made each week, define every metric once in a semantic layer, and measure adoption as ruthlessly as we measure query performance.
Overview
One definition per metric, and a report someone actually opens on Monday morning.
Reporting projects fail on definition, not on visualisation. When finance, sales and operations each calculate active customer differently, no amount of chart design fixes the meeting. The first deliverable is a metric register with an owner and an agreed formula for every measure that appears on a board pack or a weekly operations review.
After that, the work is a semantic layer that enforces those definitions, models tuned for the questions people actually ask, and a small number of well-built reports rather than four hundred inherited ones. We routinely retire more dashboards than we create, and adoption rises when we do, which surprises people every time.
We design for the Monday-morning reader as well as the analyst. That means a report that loads in under three seconds, states its refresh time, shows a comparison rather than a bare number, and links to row-level detail when someone disagrees with it — because someone always does, and the report that survives that argument is the one that gets used.
- 412 to 39
- Dashboards in the catalogue after a retirement programme
- 2.4s
- Median report load time across the Halden Group executive suite
- 68%
- Weekly active use among the target audience at 90 days
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Metric definition and semantic layer
Every measure defined once, versioned and reviewed, then served through a semantic layer so Power BI, a notebook and an API return the same figure. Disagreements move from meetings into a pull request.
Report and dashboard design
Layouts built around the decision, using comparison, variance and threshold rather than a wall of tiles. We cap a dashboard at what fits on one screen and push everything else into drill-through.
Self-service enablement
Curated datasets with documented columns, certified so business users can build their own views without recreating metric logic. Training goes to the people who will actually build, not to a room.
Performance and cost tuning
Aggregate tables, incremental refresh and query result caching, aimed at the reports with real traffic. We instrument usage first, because tuning a report nobody opens is a common and expensive habit.
Operational and embedded reporting
Near-real-time operational views for warehouse, contact centre or trading floor, plus embedded analytics inside your own product with row-level security tied to the tenant and to your identity provider.
Adoption measurement and retirement
Usage telemetry by report and by user, reviewed monthly. Reports with no viewers for 60 days are retired with notice, which keeps the catalogue small enough for people to find the right thing quickly.
Deliverables
What you get
- Metric register with named owners, agreed formulas and change history
- Semantic layer models serving BI tools, notebooks and APIs consistently
- Core report suite designed around named weekly and monthly decisions
- Certified self-service datasets with column-level documentation
- Row-level security model tied to your identity provider
- Usage telemetry with a monthly review and retirement process
Stack
What we build it with
- Power BI
- Looker
- dbt Semantic Layer
- Cube
- Apache Superset
- Metabase
- Tableau
- Snowflake
- BigQuery
- DuckDB
- PostgreSQL
- Python
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Decision inventory
We list the recurring decisions and the meetings where they happen, then work backwards to the measures those meetings need. Reports without a decision do not get built.
Metric reconciliation
Competing definitions surfaced side by side with the numbers each one produces, then resolved by a named owner. Expect this to be uncomfortable and worth it.
Semantic layer build
Definitions implemented once with tests comparing output against the agreed figures, so drift in a model shows up as a failing test rather than as a complaint.
Report build and pilot
A small suite built with the people who will read it, reviewed inside their actual meeting rather than in a demo session, and revised before wider release.
Adopt, measure, retire
Usage tracked from launch, with monthly sessions to fix the reports being used and remove the ones that are not, until the catalogue stabilises.
When this is the wrong engagement
If your underlying data is not yet modelled or trusted, BI will simply present the same disputed numbers more attractively, and the data engineering work has to come first.
FAQ
Questions we get asked
- We already have Power BI. Do we need to change tools?
Usually not. Tool choice accounts for a small share of the problems we are asked to fix; inconsistent definitions, slow models and unmanaged sprawl account for most of it. We work inside Power BI, Looker or Tableau, and will say plainly if the tool is the real constraint.
- How do you handle disagreements about what a metric means?
By making them visible and assigning an owner. We show both definitions with the numbers they produce, document the difference, and one named person decides. The register records who decided and when, so the argument does not restart each quarter with new participants.
- Is self-service a good idea?
Within limits. Self-service works on certified datasets where metric logic is already fixed and users are building views, not redefining measures. Give people raw tables and you get the same four versions of revenue in a new format, only harder to find and harder to correct.
- How do you measure whether this worked?
Weekly active users against the intended audience, time from question to answer, and the number of reports that survive a retirement review. We agree those targets before the build starts, and report against them at 30, 60 and 90 days whether or not they look good.
Related