The Role of Data Analytics in Driving Business Growth

The board meeting spent on reconciliation

Two functions present the same month and the figures differ. The next forty minutes are spent establishing which is right, and the decision the meeting existed to make is deferred. Nobody has done anything wrong: sales counted orders at confirmation, finance counted them at invoice, and both extracts were built by capable people solving a local problem.

This is the characteristic analytics failure in a scaling business, and it is not a reporting failure but a definitional one. Every extract, spreadsheet or dashboard built on an unresolved definition adds another place the disagreement can surface, which is why a better reporting tool so often makes the meeting longer.

Growth conceals its own cost

Revenue growth is the least diagnostic number a leadership team looks at, because it aggregates over the very differences that determine whether the growth is worth having.

Consider the mix effect, which is routinely mistaken for margin erosion. If a lower-margin product line grows faster than the rest of the business, group gross margin falls even though not one product’s margin has moved. The correct response (sell more of something else, or reprice) is entirely different from the response to genuine margin erosion, which is a cost or discounting problem. Businesses that look only at the group number frequently diagnose the wrong one and treat it energetically.

A metric without an owned definition is an opinion

The unglamorous foundation of useful analytics is a small set of definitions that are written down, owned by a named person, and implemented in exactly one place. Where is gross margin calculated: in the ERP, in the reporting layer, or in the spreadsheet the commercial team actually uses? If the answer is all three, they will diverge, because each will be amended by a different person under a different deadline.

This is why the semantic layer question is a governance question wearing technical clothing. The value is not that the calculation happens centrally; it is that changing it requires someone with the authority to change it, and leaves a trace.

Analytics that changes a decision, and analytics that decorates one

The most useful discipline before building anything is to write down four things: the decision, the person who makes it, how often they make it, and the values at which they would act differently.

The fourth is the filter that removes most requests. If a metric could take any plausible value and nobody would behave differently, it is describing the business rather than running it. That is not worthless (context has value), but it should be built cheaply, reviewed rarely, and never confused with the reports the business is operated from.

Cost to serve is where most of the answer is hiding

Many growing businesses understand margin at product level and almost nothing at customer or order level. Yet the differences there are usually larger, because they are driven by behaviour rather than by cost price: order frequency and size, delivery profile, returns and credit notes, expedited freight, the volume of manual intervention a particular account generates, and payment behaviour.

The objection is legitimate: allocating shared cost is arbitrary, and precision is unattainable. The way through is to accept that and change the goal. Allocate on two or three defensible drivers, hold the method constant, and use the output for ranking rather than for absolute truth. Knowing reliably which quartile of customers destroys margin is worth far more than knowing any single customer’s cost to serve to the penny.

This is the territory where data and commercial intelligence stops being reporting and starts changing pricing, terms and account management.

Forecasting is a management routine, not a prediction contest

Forecast accuracy is a poor objective, because it can be improved by forecasting conservatively and is therefore easy to game. The value of forecasting is the conversation it forces about assumptions.

The mechanism that makes it work is to record the assumptions alongside the number: conversion, lead time, price, attrition, capacity. When the actual arrives, interrogate the assumption that was wrong rather than adjusting the total. Over a few cycles this produces something more useful than accuracy, which is a shared and improving model of how the business behaves, held by the people who run it.

The counter-argument: you may not need a warehouse yet

The reflex answer to poor reporting is a data platform. It is often premature, and occasionally harmful. A warehouse built over inconsistent source data does not fix the inconsistency; it industrialises it, distributes it faster, and adds a layer between the business and the transactions where the truth lives.

The sequence that tends to hold is less exciting: fix the definitions, fix the source data hygiene in the ERP, retire the reports nobody uses, and only then centralise. The businesses that get most from a platform are those whose ERP was already trustworthy, which is an uncomfortable finding, because the platform is the part with a demonstration and the hygiene is the part with none.

There is a genuine exception. Where data must be combined across systems that will never merge (commerce, ERP and a warehouse system, or several entities after acquisitions), centralising early is correct, because no amount of source hygiene resolves that.

From a report that lands once to a routine that keeps working

Analysis is a snapshot. A margin review finds a pricing gap, the gap is closed, and eleven months later it has reopened through supplier price changes, new SKUs and local discounting. The analysis was correct; the value evaporated, because a leak that reopens monthly is not fixed by a document.

The remedy is to convert the questions worth asking repeatedly into monitored routines with an owner, a cadence and a threshold that triggers action, and to tie each exception back to the transactions that caused it, so the conversation is about evidence rather than about whether the report is right. That is exactly the reasoning behind the software arm of the group: some problems are better solved once, in software, than rediscovered every year.