From Data Lake to Decision Layer

Finance teams are told to move onto the governed platform, and they do — for reporting. Then the reforecast lands, two defensible versions of gross margin exist, and someone has to sit in a review and answer for one of them. That person builds their version where they control every input.

The data lake did not fail on capability. It failed to answer a governance question: who is accountable for this number when the system and the spreadsheet disagree? Until that has an answer, more platform will not help.

What actually happened

Polymath’s founder ran global human capital planning inside a private CPG business of roughly $2–3 billion in revenue that had since gone public on the TSX, and later sat in the Office of the CEO. Payroll ran across approximately 21 countries. The workforce P&L was above $200 million. The same figures that drove the reforecast also fed the business health reporting that went to the board.

The environment was not primitive: SAP as the transactional backbone, a cloud data environment, Power BI in front of it, and Workday Adaptive Planning as the workforce planning layer. On paper the numbers were available.

The planning refresh took about five days. The operating cadence did not wait for it. Actuals landed early in the week and the refresh finished at the end of it, by which point the meeting that needed the refreshed figure had already sat on the Wednesday — on a spreadsheet, because the spreadsheet was available and the system’s answer was not. Once a decision has been taken on the spreadsheet number, the spreadsheet becomes the record, and the offline version sits one month further from the system every time it happens.

He moved the planning refresh from five days to two. Very little of that came from the tool. Most of it came from removing the steps in the middle: an extract re-cut by hand every cycle, position data arriving in three shapes and reconciled before it could be loaded, compensation assumptions confirmed by email and retyped. Two days was what remained once the process feeding the model stopped being rebuilt from scratch.

The second change mattered more and took considerably longer. The function held workforce forecast accuracy at about 98% against that P&L, and that did not come from the planning tool either. It came from treating position definitions, compensation assumptions, vacancy logic, hiring timing and payroll integration as a governed process with named owners and a reconciliation path — the way HR-related financial controls are governed: initiator, reviewer, approver, documented decision rights, a defined exception route. He had owned those controls for about eight years and worked with auditors to build, test and remediate them. The team applied the format to a forecast instead of an expenditure.

That is what made the figure usable at board level. A board does not ask whether a number is fast. It asks who stands behind it and what moved since last quarter — and in a listed company it asks on the record.

The tool made the number fast. The control structure made it trusted. Only the second one stopped people rebuilding it in Excel.

That sequence — decisions first, decision rights second, tooling last — is the order Polymath now runs for clients, and it is the order the rest of this paper sets out.

Why it happens

Every enterprise has an approval framework for money. Thresholds, initiator, reviewer, approver, segregation of duties, an authority matrix setting out who may commit the company to what. It is documented, tested and audited. A journal entry has a named approver.

Almost no enterprise has the equivalent for numbers.

Ask who approves the gross margin figure in the board pack and you will be told who produces it. Production and accountability are not the same thing. The analyst who builds the report does not carry the consequence of it being wrong in front of the board. The executive who carries that consequence has no authority over the pipeline that produced it.

That gap produces an entirely predictable behaviour, and it is not resistance.

When two versions of a number are both defensible — different timing, a different treatment of an intercompany elimination, a different vacancy assumption — somebody has to choose between them. There is no mechanism for making that choice. The governance council meets monthly; the reforecast is on Thursday. So the person who will be asked “why did this move?” makes the choice themselves, in the only environment where they can see and change every input.

Excel is not a technology preference. It is an accountability workaround for missing decision rights over data.

This is also why the standard remedies underperform. A better semantic layer defines the field more precisely, which narrows the range of defensible answers without deciding between the ones that remain. A data catalogue records who maintains a field — a maintainer, not an approver. A training programme addresses a skills gap that was never the constraint. Each is useful. None of them names who answers for the number on Thursday.

It explains the direction of drift, too. Each month the offline version absorbs judgements the system never sees, until the two disagree by an amount somebody has to explain. In a public company, that explanation happens outside the building.

The strongest objection

The best case against this argument: we already have data governance, it has not solved the problem, and more governance is not the answer.

That is fair, and largely true of governance as usually implemented. Most data governance programmes govern artefacts — fields, lineage, definitions, catalogues — on a monthly cadence, staffed by people with no authority over any operating decision. That is documentation, not control, and it should not be expected to change behaviour.

What we propose is narrower and considerably less comfortable. Not a governance function: a small number of named executives accountable for specific numbers, with the authority to settle a definition and an exception path they can use at operating speed.

The second objection is the better one: some of that spreadsheet work is correct. It is. Scenario exploration, sensitivity testing, a question nobody anticipated — Excel is the right tool for those and always will be. The distinction is not between spreadsheets and platforms. It is between a spreadsheet used to explore a question and a spreadsheet that has quietly become the system of record. The first is analysis. The second is an undocumented control.

The method

We run six steps, in this order. The first diagnoses; the middle three are architecture. We hold the sequence, because it matters more than any individual step.

1. We inventory the decisions, not the datasets. We list the recurring decisions your Record-to-Report cycle is actually accountable for: reforecast changes, margin action, inventory exposure, workforce cost, pricing and capital allocation. We cap the list at ten to fifteen. The trade-off we accept: real decisions get left off, and that is correct — a complete list produces a catalogue nobody reads. Skip this and you govern the data you happen to hold rather than the decisions that matter.
2. We name an accountable executive for each number. Not a data steward. An executive who will answer for that figure in a review and who can settle a definitional dispute without convening a committee. We treat decision rights over a measure as specifically as decision rights over spend, and we assign them to a person. The trade-off we accept: this is a political act rather than a technical one, and it surfaces disagreements the current ambiguity is hiding. That is why we do it early. Skip it and definitions drift back within two quarters.
3. We write each measure the way you would write a control. Definition, source of record, timing, reconciliation path, named initiator, reviewer and approver, and what happens when there is an exception. Your finance team already knows how to do this; the format exists for expenditure. We write it once, then have the planning model, the board pack and the statutory schedule draw from that definition. Skip it and you have a measure dictionary, which is documentation rather than control.
4. We give each owner an exception path they can use at operating speed. Every real control has one. If the only available route for handling an anomaly is to export the data and adjust it offline, then the export is the exception path — undocumented, unreviewed and permanent. We design a real one: who may override, on what basis, recorded where, reviewed by whom. This is the step most programmes skip, and in our experience it is the one that decides the outcome.
5. We move one existing routine onto the layer before building more of it. We take the monthly business review or the reforecast meeting, run it from the governed numbers with the accountable owner in the room, and hold the line for a full quarter. The trade-off we accept: the first two sessions are worse than the spreadsheet version. Skip it and adoption never arrives, because nothing forced it.
6. We keep Excel, and we say so out loud. We name scenario work, sensitivity analysis and ad hoc investigation as legitimate spreadsheet territory. The trade-off we accept: leadership teams want a clean prohibition. We do not give them one, because prohibition drives the practice underground, where you can no longer see which decisions are being taken on it.

Cycle time still matters. A governed number that arrives after the meeting loses to a spreadsheet that arrives before it, every time. But we treat speed as a necessary condition, not the remedy. Steps two through four are the remedy, and they are architectural rather than analytical: they fix where a measure is defined, who may change it, and what everything downstream inherits. We build that context once and reuse it across the enterprise. We start in Record-to-Report, where the close already forces a precision the rest of the reporting estate never has to reach.

Evidence and measures

A governed measure, written the way a financial control is written:

Five measures worth tracking over ninety days. None of them requires a new system:

— Refresh cycle time for the planning number, measured against the decision cadence it is meant to serve.

— Number of offline versions of the top ten measures currently in circulation.

— How many people can reproduce each measure unaided — the target is more than one, and not the same person for all ten.

— Elapsed time from a variance being identified to that variance being explained. — Proportion of review meetings where the first ten minutes go on reconciling rather than deciding. This is the most honest indicator on the list.

If those five move, the operating model changed. If the only thing that moved is the number of dashboards, it did not.

How Polymath solves this

We do not start with the data estate. We start with a short pass across your Record-to-Report cycle, establishing for the ten or fifteen figures your executives actually decide on where each is authoritatively produced, who may change its definition, and what happens when two versions appear in the same room. That map is usually the first time an organization has seen its own decision rights over measures written down. We deliver it as a specification, not a dashboard, and we run it as Foundational Architecture.

We work inside your cycle rather than beside it. We write each measure specification with the controller and the planning lead who will have to live with it, build it into the platforms you already have, and test it against a real reforecast. Then we hand the next cycle to the people who own it and step back.

What compounds is the specification. Once a measure has an authoritative source, a named approver and a documented exception route, your teams inherit it rather than re-derive it: the planning model stops rebuilding it, the board pack stops carrying a private version, your control environment gets evidence it used to reconstruct by hand, and the next platform you buy is configured against definitions that already exist rather than argued out again. By the tenth measure the argument about definitions has already been had, and nobody is paid to have it twice.

What it costs to do nothing

The visible cost is labour: analysts rebuilding numbers that already exist somewhere. It is real, and it is the smallest part of this.

The second cost is decision latency. A reforecast that cannot be trusted on presentation gets re-checked, and the re-check takes longer than the reforecast did. In a business managing inventory exposure or workforce cost against a moving demand picture, the delay is the expense: a hiring decision deferred by a month, an inventory position held a month too long.

The third compounds. Offline versions accumulate judgement the system never sees, and the gap widens quietly until it is large enough to require an explanation. In a public company, that explanation is not an internal conversation.

More platform will not settle this. It is a question of who is accountable for a number — and that is answerable this quarter, without a platform decision. It is where we start.