The model first, then the reports

You recognise it in the meeting

Sales has a revenue figure and finance has one. The first ten minutes go on which number is right. In a smaller company it is the project lead saying a project made money and the accountant saying, after the quarter, that it did not.

Usually neither one is a calculation error. Sales counts on order date, finance on invoice date. The CRM has the customer twice, under two names. Margin in the sales report is before supplier rebates; in the month-end close it is after. The month-end close is the anchor, but nobody ever wrote down that the rest of the business follows that definition. So every report decided for itself.

That is what is missing: not a better report, but a model underneath.

What a business data model is

A business data model is an agreement on meaning, kept in a place where every report reads it. An agreement like that is a rule someone without a BI background can read. For a trading company, say: revenue counts on invoice date, credit notes count as negative, in euros excluding VAT. The total reconciles to the general ledger. A project business has a different rule, with work in progress in it. Which is why the agreement is written down per company, in the documentation you are handed and in the model that works it out.

The model has four layers: Extraction, Data warehouse, Definitions & KPIs and Reporting. The first layer collects the data from every system that holds figures. The data warehouse is where that data comes together, modelled on how your business works. The third layer is the agreement: the same customer list, the same product master, one definition per term, worked out there and nowhere else. Reporting sits on top and only reads.

That is the difference from how it usually goes. In most reporting the definition of revenue sits in a formula inside the report. The only person who can read that formula is the one who built it. A second report gets a second formula. We write the agreement down first, work it out in one place and let the reports only read from there. Who settles it when sales and finance disagree is agreed in the first week.

What it gives you

Every report shows the same number. The board, the sales manager and the controller look at the same revenue, because it is worked out in one place only. The meeting above goes back to being about what you do with the number.

A new system is a connection, not a rebuild. Add a web shop or switch accounting packages and it connects to the model. The definitions and the reports stay where they are.

The figures stop moving after month-end. What is settled when the month closes stays settled. A correction made later in a source system no longer changes the closed month, so the board does not get a different March figure in April than it got in March.

A new question is a question to the model, not a new report. Revenue per product group, margin per customer group, volumes per site: the model already knows those terms, so a new angle is a new report on the same definitions, with no new formula. That holds for readers from outside too, a supplier, a customer, a shareholder: each gets exactly their slice of the same number. What that looks like in practice is on the cases page.

It is yours. The model sits in your own environment, the definitions are written down in plain language and the documentation is the same one we use while building. Another party can take it over. What it is exactly and what you are handed is on Business Data Models & Reporting.

The detour: a canonical data model

What we build here has a name in systems integration. A canonical data model is a standard form of the terms a business works with, which every system connects to. Canonical here means the standard form: the shape the business itself uses when it talks about customer, product and order, regardless of how the ERP or the CRM stores it.

That canonical model is the core of a business data model. Connecting a new system is therefore an addition: it translates once to the standard form and the rest stays where it is. Record the definitions and calculation rules on top of that and you have reporting that gives the whole organisation the same insight.

It only stays right if someone keeps it that way

A model is an agreement at a moment in time. The business keeps moving. A field is added in the accounting package, a supplier starts sending its file in a different format, management decides in the third quarter that project margin should be calculated differently.

If nobody is watching, something quiet happens. The overnight refresh fails and the numbers stay at last week. Or the field changes and the number changes with it and nobody sees. And as soon as the model stops being right, the first colleague builds an Excel next to it, with a definition of their own. Then you are back at fifteen translations.

That is why maintenance belongs with it. That is what our Managed BI Services are: we see a failed refresh before you miss it, we see a field change in a source system. Whatever breaks is fixed within one working day by someone who built the model. It costs €150 to €300 a month, depending on the size of the model. Cancellable monthly. A new definition or a new source is development work and is quoted separately, so you know up front what the monthly amount covers.

What it costs and where you start

A business data model costs around €3,935, €8,350 or €19,250 with us, depending on the number of systems and the size of the reporting. Which of the three it is for you is settled at the end of the Business Data Scan: a week in which we map your systems and definitions, ending in an action plan with a fixed figure. That week is ours; from you it takes a few conversations.

If you already have Power BI, the scan starts with what is there: which definitions sit in the formulas and who can still read them. The model goes underneath; whatever is usable stays.

The first question in that week is how many definitions of revenue are in circulation at your company. The scan costs €1,200 and the result is yours, including if nothing follows.