There's a recurring conversation I have with operating leaders that goes roughly like this. We have an ERP, they say. We've spent enormous amounts of money on it. It's the backbone of the company. Why do we still need a separate system to track strategic execution? Shouldn't the ERP do that?
The short answer is that the ERP cannot do that, will never do that, and was not designed to do that. The longer answer is that asking it to do that is a category error — like asking your accounting system to do customer support, or asking your CRM to run payroll. The ERP is a system of record for transactions. Strategic execution isn't a transaction. It's a forward-looking commitment about how the company intends to spend its capacity, and the ERP has no native vocabulary for that.
Why the ERP is structurally backward-looking
An ERP is exquisitely good at counting things that have already happened and binding them to accounts. An invoice arrives, gets approved, gets paid, gets reconciled against a PO, gets posted to a GL account. A salary runs on payroll, gets coded to a cost centre, lands in a department's actuals. A purchase requisition gets approved, becomes a PO, becomes a goods receipt, becomes an invoice. Every one of these is a transaction with a precise moment, a precise amount and a precise counterparty. The ERP records them with religious fidelity.
This is the design intent. The ERP is the system of record for what already happened, denominated in money, organised by chart of accounts. It is structurally incapable of describing strategic execution, for the simple reason that strategy is forward-looking and the ERP is backward-looking by design. You cannot make a backward-looking system answer a forward-looking question, no matter how elaborate the customisation. The gap shows up in three predictable ways.
The ERP knows cost, not commitment
A salary appears as a recurring debit. The ERP knows the amount, the cost centre, the GL code, the employee ID. What it doesn't know — and has no field for — is whether that head is funding the strategic platform rebuild, absorbed in business-as-usual maintenance, or split across three initiatives in proportions that change every two weeks. The strategic commitment lives in someone's head, on a planning slide, in a project allocation spreadsheet. The ledger sees the cost. The strategy sees the bet. Nothing joins them, and the join is exactly what the CFO is being asked for when somebody wants to know what strategic priority a given headcount is funding.
You can build elaborate cost centre hierarchies to try to mimic this. Many companies have. The hierarchies get out of date the first time someone is borrowed for a project, which is approximately week two.
The ERP knows projects, not outcomes
If your ERP has a project accounting module, it gives you hours, burn, billable utilisation, capitalisable costs. It does not give you the strategic objective that the project is supposed to move. The link is conventionally maintained by a project code that maps to a strategic theme in a separate spreadsheet — and that spreadsheet is always six weeks out of date, owned by an FP&A analyst who inherits the maintenance job and would rather be doing anything else.
So the project tracking and the outcome tracking live in two systems with a manual bridge between them. When the bridge breaks, which it always does, the question "what strategic objective is this project contributing to" becomes a research project rather than a query. By the time you have the answer, the underlying reality has changed.
The ERP knows actuals, not the work in flight
The most painful version of the gap. Reds, yellows, slips, blocked initiatives, capacity that's quietly being absorbed by BAU when it was supposed to be on a strategic bet — none of this shows up in the ledger until it becomes an invoice. By the time the ERP notices a strategic initiative is failing, the failure is already in the books. The cost has been incurred. The capacity is gone. The lesson, if there is one, is being learned from a historical record rather than from a live signal.
This is why financially well-run companies still discover, halfway through a quarter, that a strategic initiative has been silently underdelivering for two months. The financial close was clean. The actuals were on plan. The strategic execution underneath the actuals was not, and the ERP had no way to see it.
What sits above the ERP
The execution layer is the missing piece, and it sits above the ERP, not inside it. It models objectives, initiatives, teams, capacity and dependencies as a live graph. It joins to the ERP for cost — every initiative resolves to teams, every team resolves to headcount, every headcount carries a cost from the ledger — without trying to be the ledger itself. The ERP keeps doing what it's good at, which is recording transactions with religious fidelity. The execution layer does what the ERP was never designed to do, which is hold the forward-looking commitments and surface the live state of the work that's supposed to deliver them.
The two systems together give you something neither can give you alone: cost grounded in the ledger, strategy grounded in commitments, and a live join between them that updates as the work moves. That join is the thing the CFO has been asking for, the thing the CEO needs in the portfolio review, the thing the board would actually find useful in the operating review.
The Vindaris view
Don't ask the ERP to run the strategy. It can't, and the years that have been burned trying to make it do so are a sunk cost that has taught the industry exactly one thing: the layers want to be separate. Put the execution layer above the ERP, let it own the forward-looking graph of objectives and initiatives and capacity, let the ERP keep owning the backward-looking record of cost. Let each system do its job, and connect them at the seam where cost meets commitment.
The companies that figure this out first will look, from the outside, like they have a better operating system than everyone else. They will. It's just that it isn't an ERP.