One number, one definition, one place to see it

A semantic layer sits between your warehouse tables and every tool that queries them. It holds the definition of each metric — the calculation, the filters, the grain, the time treatment — and exposes it by name. A dashboard asks for "gross margin by product by month" and receives a number computed by the definition everyone agreed to.

We implement this with dbt metrics, Looker's modelling layer, or a governed set of views depending on your stack, and we treat the definitions as code: version controlled, reviewed, tested and documented. Changing a definition is a visible event with a changelog, not something that quietly happens in one person's report.

Every metric has a business owner — a person, not a department — who is accountable for its definition. When a question arises about what "active customer" means, there is somebody to ask, and the answer is written down. This sounds bureaucratic and takes about a day per metric to establish. It removes a category of organisational friction that costs far more.

The most common failure is a dashboard with forty charts that nobody reads because it takes ten minutes to find anything. A dashboard is a piece of communication, and it should answer a specific question for a specific person.

We design by role. An executive view holds five to seven numbers with trend and variance against target, readable in fifteen seconds on a phone. A functional head view holds their domain with drill-down to the transaction. A control-room view is a single screen, high contrast, readable from four metres, refreshing continuously. An analyst workspace is deliberately flexible with a governed dataset underneath.

We also design for the negative case. A dashboard should make problems visible without requiring anyone to hunt: variances beyond threshold highlighted, stale data flagged rather than shown silently as current, and exception lists rather than a demand to scan a table for anomalies.

The best dashboard has a fundamental weakness: someone must remember to open it. In most organisations, most people do not. So we push as well as pull.

A daily digest goes out at 7 AM on WhatsApp or email with yesterday's key numbers and any exceptions, formatted to be read on a phone in thirty seconds. Threshold alerts fire when something needs attention — a plant below target, a customer crossing credit limit, a pipeline that failed. A weekly pack lands on Monday morning with trend and commentary slots for the owner to fill in.

The behavioural effect of this is significant and consistently reported by clients: conversations start from shared, current information rather than from someone's recollection. It also drives dashboard usage upward, because the digest creates the question that sends someone to the detail.

Dashboards report history. The questions that matter are usually about the future: will we hit the month, what will demand look like next quarter, what does the current run rate imply for the year.

We build forecasting into the analytics layer where it is genuinely useful — demand by product and region, production and yield, energy consumption, collections and cash position, and inventory requirement. Methods are chosen for the data rather than for novelty: classical time-series models with seasonality handle most business series well, and machine learning is applied where there are genuine multivariate drivers to exploit.

Crucially, we always present forecasts with intervals rather than a single number, and we track forecast accuracy over time. A forecast whose historical accuracy nobody measures is a guess with a chart attached.

For our manufacturing clients the highest-value analytics joins operational data with commercial data. Energy per tonne by product and by shift. Downtime attributed to a reason code and costed. Yield variance broken into its components. Quality results linked back to the raw material lot and the operating conditions at the time.

This requires plant data alongside ERP data in the same modelled layer, which is why our BI practice and our data engineering practice are the same team. A dashboard that shows production is mildly useful; one that shows production, its energy cost, its yield loss and its margin contribution together is what changes decisions.

For control rooms we build Grafana displays reading from time-series storage with sub-second refresh, alongside the analytical layer for historical work. Different tools for different latency requirements, one set of definitions across both.

Power BI is the pragmatic default for most Indian mid-market companies: licensing is affordable, Excel-literate users adapt quickly, and integration with Microsoft 365 is seamless. Its weakness is governance at scale, which is manageable with discipline.

Looker is stronger where the semantic layer matters most and where many analysts need controlled freedom, but it is expensive. Metabase and Superset are excellent open-source options when budget is constrained and someone can run them. Grafana is unmatched for operational and time-series displays and poor for business reporting. Tableau remains superb for exploratory analysis by skilled users.

We are not a reseller for any of these and have no incentive beyond fit. Most of our clients end up with two: one for business reporting and one for operational monitoring, on a shared semantic foundation.