How to benchmark RISE against your own data centre cost.

Almost every RISE with SAP business case begins with a comparison against the cost of running SAP on owned infrastructure. The comparison is almost always wrong, because the internal benchmark almost always understates the real cost of the owned data centre. The understatement is not deliberate. It is the natural consequence of how internal cost accounting allocates infrastructure to applications. The result is a comparison that makes RISE look cheaper than it actually is, which lets the RISE business case clear approval thresholds it should not. A defensible internal benchmark requires a different methodology, one that loads every cost the data centre incurs onto the SAP estate at the appropriate share. The methodology is straightforward. The discipline to apply it consistently is what separates a benchmark that holds up at the audit committee from one that quietly loses credibility in year three.

01.Why most internal SAP cost benchmarks are too low

Internal infrastructure cost accounting was designed for a world where applications were stable and infrastructure was shared across many workloads. The accounting allocates direct costs to the application that uses them and allocates shared costs by simple percentages or fixed allocations that do not reflect actual usage.

The result for SAP is consistent. The direct infrastructure for the SAP estate, the dedicated database servers and the SAP specific storage, is correctly attributed to SAP. The shared infrastructure, the network backbone, the shared identity services, the security operations centre, the backup and recovery infrastructure, the disaster recovery site, is allocated to SAP at a fraction of what SAP actually consumes. Labour is the worst offender. The DBA team that spends sixty percent of its time on SAP is allocated to SAP at twenty percent because that is what the cost centre methodology defaulted to a decade ago.

When this understated baseline is compared to a RISE proposal that includes everything in a single all in price, RISE looks attractive. The comparison is not measuring what it claims to measure. The comparison is measuring an internal cost allocation that was never designed to support a buy versus build decision.

The first job of a defensible benchmark is to rebuild the internal SAP cost from the bottom up, on a usage basis, with every shared cost loaded at the share SAP actually consumes. The rebuild typically increases the internal SAP cost by thirty to forty percent against the cost reported by general ledger allocation. The rebuild also produces a number the CFO can defend.

02.Build the labour model from time tracking, not from allocation

Labour is the largest hidden cost in the SAP estate. The internal benchmark needs a labour build that captures the fully loaded cost of every person who spends material time on SAP, prorated by their actual share. The build is bottom up. It starts with a list of the people who touch the SAP estate and their fully loaded cost, including salary, benefits, employer taxes, allocated overhead, and tooling licences. The build then assigns each person a share of time on SAP based on time tracking, on team manager confirmation, or on direct interview.

The roles to include are SAP basis administrators, SAP DBAs, SAP security administrators, the network engineers who maintain the SAP network segment, the storage engineers who maintain the SAP storage, the backup engineers, the disaster recovery engineers, the help desk staff who handle SAP tickets, and the SAP focused security operations analysts. Each role contributes a different share. Each share is recorded with the basis for the estimate.

Indirect labour also belongs in the build. Procurement effort spent on SAP infrastructure renewals, legal effort spent on SAP infrastructure contracts, facilities effort spent on SAP cage maintenance, audit effort spent on SAP SOX controls. Each of these is small individually. In aggregate, they add a measurable percentage to the loaded internal cost.

The labour build is the part of the benchmark that most internal teams skip or rush. It is also the part that produces the largest correction to the headline cost. A SAP estate that the general ledger reports as costing two million in labour typically costs three to three and a half million when the labour is rebuilt from the bottom up.

03.Capture the full hardware and facility cost on a depreciation aware basis

Hardware cost for SAP needs to be captured as the annual cost of using the hardware, not as the cost of buying the hardware. The annual cost includes depreciation against a realistic useful life, the cost of capital tied up in the asset, the maintenance contract for the hardware, the cost of spares held against the hardware, and the cost of the eventual refresh.

Depreciation is the largest line. A realistic useful life for SAP hardware is four to five years, not the seven year tax life that some accounting policies default to. Using the tax life understates annual depreciation and makes the owned model look cheaper than it is in operational reality.

Cost of capital is the second line. Capital tied up in the SAP estate carries an opportunity cost equal to the firm's weighted average cost of capital. The opportunity cost is rarely shown in operational reports but is real. The benchmark should apply the firm's WACC against the net book value of the SAP infrastructure for each year of the comparison.

Facility cost is the third line. Power, cooling, floor space, physical security, and facility management each carry a cost that is allocated to the SAP estate at the share of capacity SAP consumes. Power and cooling are usually the largest. Modern SAP HANA workloads are power hungry. A realistic power and cooling load for an SAP HANA cluster is between twenty and forty kilowatts continuous. At enterprise data centre rates, that is between twenty and fifty thousand dollars per year per cluster, before the floor space allocation.

04.Include the disaster recovery, backup, and security infrastructure at their real share

Disaster recovery infrastructure is often a separate facility maintained at significant cost. The cost is allocated to the production applications it protects. For SAP, the allocation should reflect the share of DR capacity SAP consumes. The share is typically high because SAP recovery requirements are demanding and SAP databases are large.

Backup infrastructure follows the same logic. The backup tier sized to handle SAP HANA full and incremental backups, plus the retention storage to hold them for compliance windows, is a meaningful share of the backup environment. The benchmark allocates this share to the SAP estate.

Security infrastructure deserves explicit attention. The SAP estate consumes identity services, endpoint protection on the administrator workstations, vulnerability scanning, log aggregation, security incident response, and compliance reporting. Each of these has a cost. The cost is allocated to the SAP estate at the share SAP consumes.

The discipline of including these shared infrastructure costs at their real share is what produces a benchmark that the CFO will defend. A benchmark that excludes these costs is comparing an incomplete internal picture to a complete RISE picture. The comparison is unfair to the owned model and produces a misleading conclusion.

05.Project the benchmark forward across the same seven year window

The RISE proposal is for seven years. The internal benchmark needs to project the owned cost across the same seven years on a consistent basis. The projection captures the hardware refresh cycle, the expected labour cost increase, the expected facility cost increase, and the expected software licence and maintenance trajectory.

The hardware refresh is the largest single capital event in the projection. A realistic refresh assumes the SAP estate is renewed once during the seven year window, with the timing tied to vendor end of life or to a known performance ceiling. The refresh cost is the new hardware cost less the residual value of the old hardware, plus the migration cost.

Labour cost increase tracks the firm's wage inflation, typically three to five percent per year for technical roles. The increase is applied to the labour line each year of the projection.

Facility cost increase tracks energy prices and lease escalation. Energy prices have been volatile and the projection should include a reasonable assumption for the seven year window, with a sensitivity case for upside and downside.

The forward projection on the owned side often shows that the cost is rising faster than the buyer expected. The rise sometimes makes the RISE comparison more favourable. Sometimes it makes the comparison less favourable, because the RISE escalators outpace the owned cost rise. Either way, the projection produces a fair comparison rather than a snapshot comparison.

06.Compare on consistent scope, consistent SLA, and consistent risk allocation

The final discipline is to make the comparison on consistent scope and consistent SLA. The RISE proposal includes a specific scope of managed services and a specific SLA. The owned model needs to be scoped to deliver the same set of services at the same SLA. If the owned model currently delivers less, the benchmark needs to load the cost of bringing the owned model up to the RISE scope and SLA.

Common gaps include twenty four by seven coverage, defined recovery time objectives, defined patching cadence, defined security monitoring, and defined performance management. The owned model in many enterprises does not formally commit to these. The RISE contract does. The benchmark needs to load the cost of formal commitment on the owned side so the comparison is apples to apples.

Risk allocation also matters. The RISE contract transfers operational risk to SAP for the in scope items. The owned model retains the risk. A defensible benchmark applies an explicit risk premium to the owned model to reflect the cost of bearing the risk, or it documents that the buyer accepts the risk without pricing it. Either approach is acceptable. Silent acceptance of the risk without documentation is not, because it produces a benchmark that is not honest about the trade off the comparison is asking the executive sponsor to make.

An internal benchmark that ignores fully loaded labour, depreciation, and power and cooling is not a benchmark. It is a confirmation bias machine that always makes RISE look cheaper.

07.Conclusion

A defensible internal benchmark of SAP infrastructure cost against a RISE proposal is one of the highest leverage analyses a buyer team can produce. The benchmark either confirms that the RISE business case is strong on its own terms or reveals that the case depends on understatement of the alternative. Either outcome is valuable. A RISE deal that survives a fair benchmark is a RISE deal worth doing. A RISE deal that only survives an unfair benchmark is a deal that will create regret in year four or five. The methodology described above is procedural and time consuming. It is also the only methodology that produces a comparison the CFO can defend to the audit committee, that the audit committee can defend to the board, and that the board can stand behind across the full seven year contract life. The work is worth doing once, properly, before any large RISE commitment is approved.