When this is the right call
These are the sentences that usually precede the enquiry:
- Revenue means something different in finance and in the product dashboard.
- SQL is copied between dashboards, so a fix has to be applied everywhere.
- Nobody can explain what a table contains without asking the person who made it.
- A schema change upstream breaks reports silently, days later.
What is different afterwards
- One definition per metric, in code, with the business logic visible.
- Tests that fail loudly in the pipeline instead of quietly in a board pack.
- Lineage from a dashboard number back to the source column.
- A modelling layer new analysts can read without a tour guide.
What you receive
- Layered dbt project: staging, intermediate and mart models with a documented convention.
- Metric definitions consolidated into a single semantic layer.
- Data tests for uniqueness, referential integrity, freshness and business rules.
- Generated documentation and lineage your team can browse.
- CI that runs build and tests on every pull request.
How it runs
- Inventory the definitionsCollect every existing version of the contested metrics and put the differences in front of the people who own them.
- Agree the canonical logicOne definition per metric, signed off by the business, written down before it is coded.
- Model in layersStaging for cleaning, intermediate for logic, marts for consumption. Each layer with one job, so changes stay local.
- Test and documentAssertions on the things that would actually hurt, and documentation written at the point of definition rather than afterwards.
- Migrate consumptionPoint reports at the modelled layer and retire the duplicated SQL behind them.
Who this suits
- Teams with a warehouse already in place but no trusted modelling layer.
- Companies where reporting disagreements have become a recurring meeting.
- Analysts who need to move faster than raw-table SQL allows.
Engagement: Project or ongoing retainer, depending on whether you have analysts to hand it to.