Data analysis & reporting

The report gives one number of active customers. The sales manager has another in their system. Both can be right: sales counts contracts in force today, finance counts everyone invoiced in the past year. If the report doesn’t say which definition it uses, the meeting will be about the number instead of the customers.

That is not a reporting bug, and it can’t be fixed in the report. It is fixed by someone deciding what the word means and writing it down where the report gets its definition.

The order we work in

1. Define the key figures first. In writing, and approved by the people who will use them. It is the dull step, and everything built afterwards counts on it.
2. Build on a modelled data source, not on direct extracts from production systems. An extract is a copy from a given date, and it needs an owner and a refresh routine so it doesn’t turn into an old truth.
3. Automate the refresh, so the report fetches new figures itself instead of someone pasting them in before the meeting.
4. Keep the history, so you can follow a trend and not just a snapshot.

Fewer reports, not more

Before we build a new report, we want to know which ones exist, who opens them and what happens next. A report nobody looks at still costs: it has to be refreshed, its definitions kept consistent, and it confuses people when it shows something different from the new one. We are happy to help retire the ones that aren’t used, after checking they aren’t needed for an audit or a decision made once a year.

The data comes from databases and data warehouses. How fresh the figures are depends on how the flows into it are built, and there is more on that under real-time data.