The three-numbers meeting, and how to end it

You know the meeting. Three departments, three revenue figures for the same period, and forty minutes spent reconciling numbers instead of making the decision the meeting was called for. Someone proposes buying a better BI tool. The organization has usually done that once already.

The tool is not the problem. The problem is that the definition of 'revenue' lives in people’s heads and in the WHERE clauses of forty different queries, each written by a different analyst under a different set of assumptions about refunds, intercompany transfers and recognition timing.

Definitions are code, and should be treated that way¶

A metric definition is business logic. Like all business logic it should be written once, reviewed, version controlled, tested, and consumed identically everywhere. When it lives instead in a saved query, a spreadsheet formula and a dashboard filter, you have three implementations that will drift, not because anyone is careless, but because three people improved them independently.

That is what a semantic layer is for. Define net revenue once, in code, with its filters and its joins and its documented edge cases. Every consumer (the BI tool, the API, the finance export, the spreadsheet) resolves through it. When the definition changes, it changes in one reviewed commit, dated, with the reason attached.

The sequence that works¶

1. 1.Inventory the metrics actually used in decisions. It is usually between fifteen and forty, not the hundreds on your dashboards.
2. 2.Find the conflicts. For each metric, collect every existing implementation and diff them. This step is uncomfortable and it is where the value is.
3. 3.Get a human owner per metric. Not a team: a person, named, who arbitrates the definition.
4. 4.Implement once, in version control, with tests asserting the edge cases the conflicts revealed.
5. 5.Route every consumer through it, and delete the old implementations. This is the step organizations skip, and skipping it means you have added a fourth number.

Delete more dashboards than you build¶

Most analytics estates carry hundreds of dashboards, of which a handful are opened weekly. The rest are not harmless: they impose maintenance cost, they break silently, and they give people a way to find a number that supports a position without anyone noticing which definition it used.

Instrument usage, publish the list, and delete anything unopened for ninety days with a clear restoration path. In our experience roughly 70% goes, and nobody asks for most of it back.

Put the number where the work happens¶

The final step is the one that changes behavior. A governed metric on a dashboard is available; the same metric inside the purchasing screen at the moment someone decides how much to order is operational. Reverse ETL, embedded panels, or simply a well-placed figure in the transactional system; the delivery mechanism matters less than the principle that insight should arrive where the decision is made, not where the reporting lives.