One source, every desk, before anyone gets in.

Every company I've walked into has more reports than it has answers. The reports disagree, everyone knows which ones to distrust, and a meaningful share of several people's weeks goes to rebuilding a view that already exists somewhere — because finding the trustworthy version is harder than remaking it.

That's not a tooling problem, and it doesn't get solved by buying a better visualization layer. It's an architecture problem and a governance problem, in that order.

Start with the metric, not the dashboard

The first move is always definitional, and it's the one most reporting projects skip because it's slow and political. A KPI framework means deciding what each number means, at what grain, scoped to what population, computed from which source — and then publishing it from one place so the definition and the number can't drift apart.

Service is the canonical example, and it's the one I worked through in detail at this company: three fill rate definitions — line, unit and dollar — scoped to stocked items only, with special-order items tracked separately on lead-time attainment. That story is its own case study, because settling it was the precondition for the planning process working at all.

The general rule underneath it: a metric is a contract, not a chart. Grain, scope, source and owner, written down. If those four aren't fixed, you don't have a KPI — you have a number that happens to be on a screen, and it will be recomputed differently by the next person who needs it.

Then the data model

Underneath the reporting sits a dimensional model — a star schema over the operational reality: order lines and stock status as facts, with product, customer, warehouse, vendor, date and sales rep as conformed dimensions.

The word doing the work there is conformed. When product means the same thing in the service report, the inventory report and the sales report, cross-functional questions become joins instead of projects. When it doesn't — when each report has its own idea of what a product hierarchy is — every question that spans two functions turns into a reconciliation exercise, and that reconciliation is a large share of what your analysts actually do all day.

This is also where you inherit the ERP's real shape rather than its documented one: the fields nobody populates, the flags that mean something different in each branch, the codes that were repurposed years ago. The dimensional model is where those get resolved once, deliberately, instead of being rediscovered by every person who writes a query.

Then an architecture that survives its users

Two layers, and the split matters more than either layer:

• A fast layer — DuckDB over batch-refreshed Parquet files. Analytical queries return immediately, and because each session reads its own snapshot rather than hitting a shared connection, concurrency stops being something you defend against.
• A governed layer — SQL Server, with a build-and-publish pipeline between the two and version control over the transformation code.

The concurrency point came out of an actual failure. The first version read live from SQL, and two people running sessions simultaneously produced a cache collision that corrupted both. The fix wasn't defensive coding — it was moving to batch-refreshed local files, which dissolved the problem by design. Internal tooling has to survive people using it at the same time on a Monday morning, and architecture is a better answer to that than discipline.

The version control piece is unglamorous and load-bearing. Reporting code that lives in someone's personal namespace leaves when they do — I found exactly that, with a production repository sitting under a former employee's account, and migrating it into a proper team namespace was one of the first governance items. If your reporting can't be rebuilt from a repository, you don't have a platform. You have a person.

Then the delivery layer, which is the easy part

Once the definitions and the model exist, what you put on top is a genuinely open choice, and I'd rather fit the tool to the company than the reverse. Tableau or Power BI where a licence and a user base already exist and self-serve exploration is the goal. Streamlit where the thing needed is not a dashboard but an application — a workbench a planner works inside, with logic and write-back, not just visualization. At this company that meant a hub-and-spoke Streamlit platform for the operational tooling, with the governed layer underneath available to whatever else the business wanted to point at it.

What matters is that the semantics live below the visualization tool, not inside it. Metric definitions buried in a workbook's calculated fields are definitions you'll have to litigate again the first time someone builds a second workbook.

Then somebody has to own it

Platforms decay without an owner, so part of this work was organizational: pitching, funding and standing up a dedicated BI and AI enablement function — a manager, analysts, and a mandate framed as "we are builders, not order-takers" rather than a ticket queue.

Two things about that pitch are worth repeating. It was self-funding, built on not backfilling a vacant developer role, non-renewing a third-party analytics vendor, and automating away recurring manual work — which is a far easier case to make than net new headcount. And reporting sat under operations rather than under IT, because the constraint was never technical capability; it was proximity to the decisions the numbers are supposed to inform.

What transfers

The sequence, which is the part people get backwards. Definitions, then the dimensional model, then the architecture, then the visualization tool, then the owner. Almost every failed reporting program I've seen started at step four — buy the tool, build dashboards, discover the numbers disagree, and end up with a more expensive version of the same argument.

Nothing above is distribution-specific. The facts and dimensions change with the business; the failure mode and the order of operations don't.