Before
Each area with its own number
- Reports are assembled by hand from several databases and spreadsheets.
- The same metric changes definition by department.
- Almost anyone can export; there is no record of who queried what.
Method
From source to metric
First we agree what each number means. Then we unify it and publish a dashboard people can use. Software exists so that rule holds: the same in the database, on the panel, and in the report.
What to measure
I agree the meaning of each metric with the people who use it and the people who decide. Without that, a dashboard only speeds up the error.
Inventory of databases, APIs, and files. The source system is not rewritten: it is exposed with agreed fields and frequency.
One rule
I unify and clean so the dashboard and the report do not contradict each other. The debate is the problem, not which spreadsheet is true.
Quality checks, ranges, and a reusable model. The rule does not depend on the engine (Airflow, Spark, or Celery).
Show it to decide
I publish the dashboard where people work: clear, usable, with what each role needs.
Apache Superset or Power BI on already-consolidated data. Not a file circulating by email.
Keep it running
If a load fails, it is flagged. The number does not sit only on a chart: it supports operations.
Retries, query and export logs, and an alert if the job does not finish.
Each person sees what they are allowed to see. Queries are logged. If an update fails, someone is told.
In practice
When data exists and the rule does not
The pattern is institutional. Information lives in several systems; the figure changes with whoever calculates it; exports leave no trail.
After
One rule, visible and logged
- One definition per entity, identical on the dashboard and in the export.
- The panel lives in the working system, with identity-based access.
- Queries are logged. If a job fails, the system alerts.
What remains One rule, visible on the dashboard and in the export, with a query log. The debate is the problem, not which spreadsheet is true.