Data engineering · Modelling, metrics and reporting
The same question, the same answer, everywhere
A modelled layer where each important number is defined once, with reporting built on top, so revenue means the same thing in finance, sales and the board pack, and a meeting about the figures becomes a meeting about the business.
Where this starts
The meeting about whose number is right
When two departments bring different figures for the same thing, the rest of the meeting goes on reconciling them rather than deciding anything. The cause is almost never an error. Each report defines revenue, active customer or margin slightly differently inside its own query, and nobody can see the difference without reading every one of them.
What we usually find
- Three versions of revenue, each defensible and none agreed
- Business logic buried inside individual report queries
- A board pack assembled by hand every month
- Reports that take days to produce and minutes to dispute
- Dashboards nobody opens because nobody trusts them
- A new question that takes a fortnight to answer
Our position
A metric defined in two places is two metrics. The fix is not a better dashboard; it is deciding once and writing it down where every report reads from.
What the work covers
Defined once, used everywhere
The modelling is the unglamorous half and the half that matters. Reporting built on an agreed model is quick to produce and hard to argue with.
Agreeing definitions
Working with finance, sales and operations to settle what each core metric means, awkward edge cases included, and recording the decision with an owner.
Dimensional modelling
Facts and dimensions structured around how the business actually asks questions, so a new report is an act of assembly rather than fresh engineering.
A metrics layer
Each metric defined once in code, versioned and tested, and read by every report rather than reimplemented inside each one.
History that holds
Changes to customers, products and territories recorded over time, so last year’s figures stay as they were rather than silently restating.
Reporting built for decisions
Dashboards designed around the decision they support, with each definition a click away, and the reports that duplicate or contradict them retired.
Self-service within limits
Business users able to answer their own questions from governed definitions, without being able to invent a fourth version of revenue.
How the numbers stay agreed
Definitions under version control
Agreement on a definition decays unless the definition itself is protected. These keep it protected.
- Versioned logic
- Every change to a metric or model reviewed and versioned, so a movement in a number can be traced to a decision and a person.
- Logic tests
- Assertions that totals reconcile, keys are unique and relationships hold, run against every change to the model.
- Impact first
- The reports affected by a model change listed before it ships, so nobody is surprised by a figure moving on a Monday.
- Documentation
- Definitions published from the model itself, so the documentation cannot drift from what is actually being calculated.
- Report usage
- Which reports are opened, and by whom, so the unused ones are retired and the estate stays small enough to trust.
What you are left holding
- Written, owned definitions for the metrics that matter
- A modelled layer every report reads from
- History that does not silently restate
- Dashboards built around decisions, definitions attached
- A smaller report estate, with duplicates retired
Bring us the two reports that disagree
Tracing why they differ is usually the quickest way to show what an agreed model would change.