A travel company has thousands of dashboards, several conflicting definitions of the same metric, and a large BI bill. Diagnose it.

What actually happened

Each of these is a symptom of the same cause: metric logic living in dashboards rather than in a shared layer.

• An analyst needed a number, could not find a trustworthy existing dashboard, and built one — encoding their own interpretation of the metric.
• The dashboard was used once, and never deleted, and still refreshes on a schedule.
• The next analyst repeated the process, because discovery is harder than rebuilding.

Sprawl, inconsistency and cost are one problem with three visible faces.

The diagnosis to run

• Usage data per dashboard: last viewed, viewer count, refresh frequency. The typical finding is that a large majority have not been opened in months and are still refreshing.
• Cost attribution per dashboard and per query, ranked by cost multiplied by frequency — the single most expensive query is usually a small share of spend while a cheap one running constantly dominates it.
• Definition overlap: how many distinct SQL expressions compute the same named metric.

The interventions in order

1. Turn off scheduled refresh for unopened dashboards. Immediate cost reduction, no governance debate required, and reversible.
2. Certify a small set of dashboards built on shared definitions, and make them the discoverable default.
3. Move metric logic into a semantic layer, so new dashboards compose definitions rather than reimplement them.
4. Archive by inactivity with an owner notification, so removal is automatic rather than negotiated.

What not to do

Do not restrict dashboard creation. Restriction moves the work to spreadsheets, where it is invisible and worse. The goal is to make the governed path the easy one, not to close the ungoverned path.