KPI tree and definitions
Decomposing the outcome into the drivers somebody can actually influence, and agreeing what each one means.
AI Capabilities & Services
Business Analysis & Decision Intelligence
Turn operational data into dashboards and decisions leaders can act on.
The problem
Most organisations are not short of dashboards. They are short of dashboards that change a decision. A report that shows what happened, without saying what it means or who should do something, gets opened on the first of the month and closed again. Meanwhile the questions that actually run the business — which customers are worth keeping, which cost is drifting, which branch is the outlier — get answered in a spreadsheet by whoever has time.
Who this is for
- Executives and business-unit headsA small number of measures that actually move the outcome they own
- Finance and commercial teamsMargin, mix and cost seen together rather than in three separate reports
- Operations managersThe exception surfaced daily, not discovered in the monthly pack
What people use it for
Customer and product profitability
Margin after the costs usually left out — returns, service, discounting and cost to serve.
Exception and variance reporting
Alerting on what is unusual for that branch, product or period rather than against a flat target.
Decision support for a specific choice
Pricing, capacity, network or portfolio decisions modelled with the trade-offs made explicit.
What it needs to work
- Your transactional systems — ERP, CRM, POS, operational databases
- The decisions you want supported, named specifically
- Whoever can settle a definition when two departments disagree
- Existing reports, which show what people already rely on and what they quietly ignore
How it works
-
Start from the decision
Which recurring decision is this for, who makes it, how often, and what they currently use. A metric with no decision behind it does not get built.
-
Build the KPI tree
The outcome broken into drivers, each with a definition, an owner and a source. This is where most disagreements surface.
-
Model and validate
The numbers built from source and reconciled against what finance already publishes, so the first meeting is not spent arguing about totals.
-
Design for the decision
Each view answers one question and states the action. Anything that does not change what somebody does is left out.
-
Put it where the decision happens
In the meeting, the daily routine or the operational system — not in a portal people must remember to visit.
How we deliver it
-
Decision and data discovery
Interviews with the people who make the decisions, and an honest look at whether the data supports the question.
-
Definitions workshop
Getting the disagreements into one room and out of the reports. This is usually the highest-value day of the engagement.
-
Build one decision end to end
One KPI tree, one set of views, in production and used, before the next is started.
-
Extend and hand over
Further areas on the same pattern, with your analysts building and us reviewing.
Where it runs
- On your existing BI platform — Power BI, or whatever your team already runs
- Embedded into an operational system where the decision is actually made
- Scheduled distribution where the decision is periodic rather than continuous
Security and governance
- Every measure has a written definition, an owner and a source
- Figures reconcile to the system of record, and differences are documented not hidden
- Access by role, with sensitive measures restricted at the data layer not the dashboard
- Changes to a definition are versioned and announced to the people who use it
Timeline
One decision, end to end, is the unit worth planning around. Where the data exists and the definitions are agreed, that is weeks. Where finance and operations mean different things by the same word, the definitions workshop comes first, and it is not a delay — it is the work.
What you receive
- A documented KPI tree with owners and definitions
- Working dashboards designed around decisions, not around available fields
- Reconciliation evidence against your system of record
- A written interpretation guide — what each view means and what to do about it
- Training for the analysts who will extend it
Related work
Published projects where we did this.
What this does not do
This does not make the decision, and it will not create agreement where none exists — it makes the disagreement explicit, which is usually more useful and occasionally less comfortable. It also cannot measure something you do not record: where a driver of the outcome is not captured anywhere, the honest answer is to start capturing it, not to model around the gap.
Questions we are asked
We already have dashboards. What is different?
Most start from available data and show what can be shown. These start from a decision somebody makes on a schedule and work backwards. The test is whether anything changes on a Monday because of what the view said.
Do you replace our BI tool?
No. We build on whatever your team already operates. Changing tool is a cost with no analytical benefit unless the current one genuinely cannot do the job.
About the figures on this page
This page describes capability and method. It does not publish accuracy figures, throughput numbers or delivery dates, because those depend on your data, your systems and your scope — and a number published here would be wrong for most readers. You get them, in writing and against your own data, at scoping.
A first call is a technical conversation, not a pitch: what you have, what you need, and whether this is the right approach at all.
Built on the Unified Intelligence Layer
Every InsAI product runs on the same four-stage backbone.
- 1
Data Integration
ERP · IoT · BIM · CRM
- 2
AI Models & Predictive Engines
Forecasting, detection, optimization
- 3
Automation & AI Agents
Acting on predictions, end to end
- 4
Real-time Dashboards & Decision Systems
From the floor to the boardroom
Business Analysis & Decision Intelligence
Turn operational data into dashboards and decisions leaders can act on.