Standardising a metric across business units reads like a modelling problem and is almost entirely a negotiation. The data work is the easy half; it is also the half most programmes plan for.
What follows is how to run the other half.
Start by accepting that some differences are legitimate
The instinct when you find five definitions of the same metric is that four of them are wrong. Usually two or three of them are genuinely defensible for the way that unit operates, and one or two are historical accidents nobody has revisited.
Opening the conversation with "we are standardising this" puts everyone in a position where agreeing means admitting their number was wrong. You will get compliance in the meeting and a parallel spreadsheet within a month.
The better opening is narrower: we need one number that is comparable across units for group-level decisions; you keep whatever you need locally, and we write down the relationship between them. That is a much easier thing to say yes to, and it is also more honest, because it is what actually happens.
Run the definition workshop with the people who argue about it
Not their delegates. The people who produce the number and the people who are held accountable for it, in the same room, for one metric at a time.
Four questions settle most of it:
- What exactly is being counted? Surprisingly often the disagreement is about inclusion rules — does a cancelled item count, does an internal transfer count, does a partial period count.
- At what grain? Per transaction, per day, per site, per unit. Aggregations that look equivalent frequently are not.
- As at when? A metric measured at period end and the same metric measured as a rolling average are different metrics wearing the same name.
- Who decides if this changes? If the answer is "we all would", the definition will drift again within a year.
Write the answers down in the meeting, out loud, and get explicit agreement before moving on. A definition everyone nodded at is not agreed.
Allow local variants — but make them derivations, not alternatives
Where a unit needs its own version, define it as a stated transformation of the group metric rather than as an independent calculation. "Group utilisation, excluding contracted maintenance windows" is a variant you can reconcile. A separately implemented "local utilisation" is a second source of truth that will diverge.
The test is simple: can you get from the group number to the local number by a rule you can write in one sentence? If yes, it is a variant. If no, you have two metrics and they should have two names.
What goes in the KPI dictionary
Per metric, and kept somewhere the business can actually find:
- Plain-language definition — what it means, for someone who does not know the data model
- Precise calculation, including inclusion and exclusion rules
- Grain and time basis
- Source systems and fields it derives from
- Named owner — a person, not a department
- Refresh cadence, and how to tell whether it is current
- Documented local variants, each with its derivation rule
- Date of last change, and who agreed it
The last two are what make the dictionary survive. A dictionary with no change history becomes untrusted the first time someone remembers it saying something different.
Implement it once, in the semantic layer
The agreement only holds if the agreed calculation exists in exactly one place that every report reads from. If each dashboard re-implements the measure, you have documented a standard rather than enforced one, and drift resumes immediately — just more slowly and less visibly than before.
Version-control the model. A definition change should be a reviewable commit with a name attached to it, not an edit somebody made in a workbook on a Friday afternoon.
Sequence it by argument, not by ease
The temptation is to standardise the easy metrics first to build momentum. It builds the wrong kind — the easy ones were never contested, so nothing is proven.
Start with one metric that is genuinely argued about and matters. Getting that agreed, implemented and visibly used is what makes the next twenty possible. Twenty-seven standardised KPIs is a real outcome; twenty-seven uncontested ones would not have been worth the programme.
What you get for it
Not primarily speed, although the reporting does get faster. What you get is leadership meetings that start at the decision rather than at the reconciliation — and a reporting estate where adding the next metric is a day of modelling instead of a negotiation you have already had.
