System of Record, or System of Execution

A system of record captures what happened. A system of execution is where the decision actually gets made. Most SAP organizations are excellent at the first and partial at the second, and the gap is filled by a shadow spreadsheet layer that carries across an S/4HANA migration unless it is corrected beforehand.

Ask a CIO whether the business runs SAP and the answer is yes. Ask whether the business runs on SAP and the answer gets longer.

The distance between those two answers is where most of the unrealized value in an SAP organization sits.

Two systems, one license

A system of record captures what happened. Transactions post, documents generate, the month closes, the auditors are satisfied, reporting is accurate. Judged this way, most SAP environments are healthy. Uptime is good, the data is there, the integrations hold.

A system of execution is different. It is where the decision actually gets made. The planner accepts what the system proposes, because the proposal is right. The buyer releases the requisition the system generated. The scheduler runs the sequence the system produced. The number in SAP is the number the business acts on.

Most SAP organizations are excellent systems of record and partial systems of execution. That gap appears in no IT metric. It appears in the shadow layer.

The shadow layer

Every SAP-run manufacturer has one. A planning spreadsheet that takes an extract, applies logic that exists nowhere in the system, and produces the numbers the team actually works to. A database somebody built years ago and maintained personally until they left. A weekly meeting where the SAP output is reviewed and then adjusted before anyone acts on it.

The shadow layer is not a discipline problem. It is a rational response to a system whose output people learned not to trust. At some point SAP proposed something wrong. A parameter was stale, master data was incomplete, a lead time was fiction. A planner corrected it manually and was right. That happened often enough to become a habit, the habit became a process, and the process became the way the business runs.

The costs are real and none of them appear in the IT budget.

• Decisions get made on data nobody governs.
• Improvements made in SAP never reach the decision, because the decision is being made outside SAP.
• Institutional knowledge concentrates in individuals rather than in the system.
• Licensed capability that would have addressed the original problem stays switched off, because nobody trusts it enough to turn it on.

The last one is the expensive part. The organization pays for capability, then pays people to work around it.

Why this lands on the CIO and the CFO at the same time

The instinct is to treat this as a business process issue. It is. The consequence still lands on the technology function.

When the shadow layer runs the business, the value case for the SAP organization cannot be demonstrated. Availability and cost per user are the metrics left, and neither speaks the language the board uses to talk about enterprise value. That is a weak position in any budget cycle. It is a much weaker one heading into an S/4HANA migration.

It also makes the migration riskier. Moving to S/4HANA moves the system of record. It does not automatically move the decision. If the shadow layer travels across, the business has funded a technical upgrade and preserved the execution gap. The capabilities are newer. The spreadsheets still run the plan.

The window before a migration is the best moment to correct this, and the most commonly missed. Fixing execution first means what migrates is a business already running on the system rather than alongside it.

What closing the gap actually takes

Not new software. The functionality is already licensed. Closing the gap is three things.

1. ‍Master data that can be trusted. Lead times, lot sizes, safety stocks and planning parameters that reflect how the business operates now, rather than what was loaded at go-live. Unglamorous, and the foundation of everything above it.‍
2. Capability switched on and genuinely used. Standard SAP functionality replacing spreadsheet logic, configured to the way the business actually plans, with the planners involved in setting it rather than trained on it afterwards.‍
3. Governance that outlives the project. Parameters drift. Without clear ownership, a review cadence, and someone accountable for keeping settings aligned to reality, the shadow layer rebuilds. This is why one-time data cleanups do not hold.

None of that happens in a workshop. It happens alongside the business teams, inside the system, while the business is running.

One long-established equipment manufacturer worked through exactly this sequence while preparing for S/4HANA. Offline work in Excel, custom transactions and third-party tools were limiting visibility, and master data fields had been repurposed in ways that restricted future capability. Documenting current processes against the SAP standard, piloting the standard process on real operational scenarios and establishing reporting and oversight produced a 14% Days On Hand improvement, capacity evaluation and material availability checking performed inside SAP, and a measurable reduction in reliance on spreadsheets and third-party tools.

The migration then moved a business that was already running on the system.

The question worth asking

Not whether the organization is on the current release. Ask instead: for the decisions that determine service, inventory and margin, is the system producing the answer the business acts on, or producing an input to a spreadsheet that produces the answer?

If it is the second, the value in that organization has not been realized. It is still there. It is not a licensing question, and the next upgrade will not solve it.

The 12-question self-assessment is a fast way to see how much of the decision-making in your environment currently happens outside the system.

Quantify what your SAP environment could be delivering. Request an executive conversation.