Management Information Without Buying a BI Platform

Most of the effort in management reporting goes on assembly rather than interpretation. The numbers already exist. They are in the CRM, in the accounting system, in whatever operational system runs the actual work, and in two spreadsheets on somebody's desktop. The job is finding them, agreeing which version wins, and explaining why three figures that describe the same thing disagree. That takes days rather than hours, and by the time it is settled the month being reported on is comfortably gone, so the thinking gets done last and in a hurry.

It is an integration problem wearing a reporting costume, which is why buying a reporting product frequently does not fix it.

Why the pack takes days

The same word means different things in different systems. A customer in the CRM is a company record somebody created during a sales conversation. A customer in the accounting system is a sales ledger account with a credit limit. They overlap, they are not the same population, and neither is the list the operations team uses. Revenue has at least three legitimate definitions in a mid-market business: deals marked won, value invoiced, and value recognised in the period. All three are correct. They answer different questions, and a pack that mixes them silently produces a number that is true of nothing.

The definitions are not written down. They live in the method of whoever builds the pack, reproduced by hand each month. Which is why the pack degrades when that person is on leave, and why nobody can fully explain last March's figures.

The join between systems is made by a person, from scratch, every month. Matching the CRM company to the ledger account is done by eye, with judgement applied where the trading name and the registered name differ. That judgement is recorded nowhere, so next month it is made again, possibly differently.

The data is incomplete in ordinary ways. A closed deal with no reason recorded. Work delivered but not yet invoiced. A project with no hours logged because the person logging them was busy delivering. That is normal operating life, and the pack has to say so rather than smooth it out.

A new platform moves the problem rather than removing it

Reporting platforms are good products and this is not an argument against the category. It is an argument about sequence. Whatever you buy still has to be told which definition of revenue wins, still needs the join between the CRM company and the ledger account, and still needs somebody to decide what an absent number means. That work is unavoidable and it is most of the effort, which is why implementations run long: the months go on definitions, not on software.

What the purchase adds is a further copy of your data to keep current, a second place where the definition of a customer is encoded, and one more system that breaks when a field changes upstream. You have bought somewhere to put the answer, which is not the same as having the answer.

The alternative is to do the definitional work once, record it, and run it where the data already is. Then the figure, the record behind it and the trail between them are one thing in the systems you already run, rather than three things to reconcile before anyone trusts the pack.

What good looks like: assembled inputs, flagged gaps

The useful capability is duller than a dashboard and worth more. Approved inputs are assembled on a schedule from sources your finance lead has signed off. What is missing, stale or in conflict is flagged rather than quietly averaged. Anomalies are detected against rules you agreed in advance, not against a model's impression of what looks normal.

One rule earns its place above the others: incomplete coverage is never reported as zero activity. A blank shown as a zero is the most expensive error in management reporting because it is invisible. A director reads zero as "nothing happened" when it meant "nothing was recorded", and decides on that basis. So a figure covering most but not all of the population says so, and names the accounts it could not include.

The second thing worth building is the list of questions the pack raises. Not conclusions. The figures that moved outside their usual range, the two sources that disagree, the accounts where the data is too thin to support a view. That list is what turns a monthly reading exercise into a meeting where something gets decided.

Every figure traceable to its source, including the gaps

Each number should link back to the records that produced it. Click the pipeline figure and see the deals behind it. Click the revenue line and see the invoices. Click the gap and see which accounts are missing.

That single property changes the management meeting more than any chart does. The recurring argument about whether a number is right takes two minutes instead of a fortnight, because somebody opens the underlying records in front of everyone. What is left is the discussion about what to do, which is the discussion the meeting was called for.

The boundary: faster to the data, not an opinion about it

This gets you to the underlying data faster. It does not tell you what your numbers mean, and that boundary is deliberate rather than a limitation being hedged.

Interpretation depends on things held in no system: a customer's verbal commitment, a decision taken last week, a judgement about whether a slow quarter is seasonality or the start of something. And a figure in a management pack is a statement someone has to be able to stand behind.

So the ladder for this work sits low and stays there. Assembling approved inputs, reconciling them, flagging conflicts and linking every figure to its source are read and draft actions. Preparing the summary and the questions it raises is a draft for a person to approve. Interpreting the result, restating a position or adjusting a record are human actions with a named owner. Where a pack leaves the business, to a lender, an investor or the board, a named person who can stand behind the figures signs it off, and the system's job is to get them to the underlying numbers faster rather than to replace that signature.

To be plain: we give no financial, tax, legal or accounting advice. Nothing we build determines VAT or any other tax treatment, posts to a ledger or another controlled financial record, or adjusts a financial position. Those belong to your finance team and your accountant, and what we build reflects the boundary they set.

What we would actually build

A management-information assembly capability running against the CRM, the accounting system and the operational systems you already have. It gathers the approved inputs, applies the definitions you have agreed and recorded, identifies what is missing, stale or in conflict, prepares the summary and the questions, detects anomalies against your rules, and links every conclusion back to its basis.

The recorded definitions are the part that outlasts everything else. Even if you later buy a reporting platform or change accounting system, the agreed definition of a customer and of revenue, and the rules for the join between systems, are the asset. Most businesses have never written them down, which is the actual reason the pack takes days.

This sits in our AI for Business Operations pack, and a standard wave activates two capabilities in a department rather than the full catalogue. Where your existing systems already do a job adequately, we configure what you have and say so.

How you would know it worked

• Elapsed time from period close to the pack being circulated.
• The number of figures with no traceable source, which should fall towards zero and stay there.
• The number of reconciliation queries raised in the meeting, as distinct from decisions taken.
• Whether the pack can be produced to the same standard when the person who normally builds it is away. That is the real test, and it is the one most businesses fail today.

Take those measurements before anything is built, because a baseline captured afterwards is a negotiation rather than a measurement. Each quarterly wave of the AI Accelerator programme is measured against the baseline it started from, and every wave ends in a decision that includes stopping.

The next step

Before any of this, there is a cheaper piece of work worth doing. Take last month's pack and try to trace three figures back to the records that produced them. How long that takes, and how many people you have to ask, is a fair proxy for the whole problem.

We do that exercise properly as a short, fixed-scope assessment with no obligation: what your systems already hold, where the definitions conflict, and what could be assembled reliably without buying anything. Book a diagnostic and you will get a straight answer about what is worth building, including the answer that your existing systems, configured properly, already cover it. For where reporting work belongs in a wider plan, see the case for one department at a time.