Building the buyer side RISE counter TCO model.

SAP almost always brings a TCO model to the RISE conversation. The model is professional. It is often well constructed. It is also built to support the conclusion that RISE is the lowest total cost path forward. Buyers who try to negotiate against the SAP model on its own terms lose the negotiation in the model, before the commercial conversation even begins. The defence is a buyer side counter TCO model, built independently, owned by the finance function, calibrated to the buyer's actual cost structure, and engineered to surface the variables that the SAP model softens. The counter model is the most important single artefact the buyer team produces during a RISE engagement. It is also the artefact that produces the most consistent commercial movement, because it forces the conversation into the buyer's analytical frame rather than the seller's.

01.Why the SAP TCO model is not a baseline

SAP TCO models are built by experienced consultants using a refined template. The template captures every category of cost in a brownfield or on premise alternative, including infrastructure, licences, maintenance, hosting, headcount, and the implementation overhead of any major SAP release. The model is internally consistent and the numbers are defensible inside the assumptions used.

The problem is not the model's quality. It is the model's purpose. The model is designed to make the RISE case look strong. The assumptions chosen for brownfield costs are often at the upper end of reasonable ranges. The assumptions chosen for RISE costs are often at the lower end. The combination produces a TCO comparison where RISE wins by a wide margin.

The buyer team cannot use the SAP model as a baseline. The model embeds the conclusion in its assumptions. Negotiating against the model means accepting the assumptions, which means accepting the conclusion. The only viable approach is to build an independent model from scratch using the buyer's own data.

The independent model does not have to disprove the SAP model. It has to produce a defensible alternative number. Once the alternative number exists, the negotiation moves from the SAP model's conclusion to the difference between the two numbers, which is a far more productive conversation.

02.Defining the scope of the counter model

The first decision is scope. The counter model covers the same workloads, the same time horizon, and the same cost categories as the SAP model. The horizon is typically seven years to match a RISE term. The workloads include the full SAP estate that would move to RISE, plus the adjacent systems whose costs are affected by the decision.

The cost categories include infrastructure, software licences, maintenance, hosting, internal headcount, third party support, security, compliance, disaster recovery, and implementation. The model also includes the categories the SAP model often understates, such as integration cost with non SAP systems, the cost of any required parallel operation during a conversion, and the cost of training the operational team on the new RISE service model.

The scope decision matters because any cost the buyer excludes from the counter model is a cost the SAP model can claim is included in RISE. The counter model defends the brownfield position by accounting for every cost that brownfield actually carries, even costs that the operations team takes for granted.

Once scope is agreed, the model is built in three parallel workstreams: the brownfield case, the RISE case, and a sensitivity workstream that flexes the assumptions in both. The three workstreams share the same template and the same time horizon so the outputs can be compared line by line.

03.Sourcing the buyer side data

The single largest difference between the SAP model and the counter model is the source of the cost data. The SAP model uses industry benchmark numbers. The counter model uses the buyer's actual numbers. The difference matters because industry benchmarks tend to be generous on the brownfield side and conservative on the RISE side. Actual numbers are the only defensible input.

Actual numbers come from the buyer's existing accounting system, the existing infrastructure tooling, and the existing operations contracts. The work to extract them is non trivial. Infrastructure spend needs to be allocated to the SAP estate. Headcount needs to be allocated based on actual time spent supporting SAP versus other systems. Licence cost needs to reflect the buyer's actual entitlements rather than a list price.

The data extraction is typically the longest single workstream in building the counter model. Three to six weeks of effort is normal for an enterprise of any complexity. The investment pays off because every subsequent conversation about the model rests on data the buyer can defend with internal references.

When data is missing or unreliable, the model uses ranges rather than point estimates. The range based approach is more honest, and it gives the buyer team flexibility during negotiation. A point estimate that turns out to be wrong undermines credibility. A range that turns out to be wider than necessary simply narrows during the negotiation.

04.Modelling the RISE case independently

The RISE case in the counter model is built from the bottom up rather than from the SAP proposal down. The buyer team starts with the workloads, calculates the FUE count and consumption volumes the workloads imply, applies the unit prices from the SAP proposal, and produces a total annual cost.

The bottom up build is important because it surfaces assumptions the SAP proposal embeds. The proposal assumes a specific FUE count. The bottom up build may suggest a different count. The proposal assumes a specific BTP consumption volume. The bottom up build may suggest the volume is too high or too low. Each difference is a negotiation point.

The RISE case also models the costs that sit outside the RISE subscription. Implementation cost. Internal headcount required to manage the RISE service. Integration cost with the non SAP estate. Cost of any third party support contracts that continue alongside RISE. The total RISE cost in the counter model is the subscription plus these adjacent costs, not the subscription alone.

The counter model surfaces a number for RISE that is typically twenty to forty percent higher than the number SAP presents. The difference is not a manipulation. It is the cost the buyer will actually incur, including the categories the SAP proposal does not address.

05.The brownfield baseline as a defensible alternative

The brownfield baseline is the second half of the counter model. The baseline reflects what the buyer would actually spend if the decision were to remain on the current platform for the full seven year horizon. The baseline is not the cost of recreating the current estate from scratch. It is the run rate cost of operating the current estate, with realistic assumptions about the hardware refresh cycles, software upgrades, and operational headcount that the estate already consumes.

The brownfield baseline often includes investments the buyer was already planning, such as a hardware refresh or a database upgrade. Those investments should be in the baseline because they would happen with or without the RISE decision. Including them prevents the SAP model from claiming the investments as a RISE benefit.

The baseline also includes the cost of staying current on SAP releases, the cost of maintenance and support at the current tier, and the cost of any compliance work that the buyer is required to do regardless of platform. The baseline is the true cost of the status quo, which is what the RISE decision is actually being compared against.

Once both cases are modelled, the comparison is a single number per year for seven years, expressed on a cash basis, an income statement basis, and a present value basis. Each view produces a different result. Each result is a negotiating asset.

06.Using the counter model in the negotiation

The counter model is delivered to SAP early in the negotiation, before the first round of pricing concessions. The delivery is not a fight. It is a recalibration. The buyer presents the model, walks through the assumptions, and invites SAP to challenge any specific number. The exercise positions the buyer as the analytical lead in the conversation, which changes the dynamics for every subsequent round.

SAP will push back on the model. The pushback usually focuses on the assumptions in the RISE case rather than the brownfield baseline. The buyer team holds the line on the assumptions that have been validated internally and concedes only on assumptions where the SAP data is genuinely stronger. The concessions are calibrated to the discipline that the model is the buyer's, not SAP's, and changes to the model require buyer side review.

Once the model is accepted as the basis for the conversation, the negotiation is no longer about whether RISE is cheaper. It is about how to close the gap the counter model has identified. The closure can take many forms: a deeper discount, a longer term, a different bundling, a delayed indexation. Each form is a different commercial outcome that maps directly to a line item in the model.

The counter model also continues to serve after signing. The model is the baseline against which actual RISE costs are tracked. Year over year, the actual costs are compared to the modelled costs, and any variances are flagged for review. The post signature use of the model is the foundation of any disciplined RISE optimisation programme.

Negotiating against the SAP model on its own terms means losing the negotiation in the model, before the commercial conversation begins. The counter model moves the analytical frame.

07.Conclusion

The buyer side counter TCO model is the analytical backbone of a serious RISE negotiation. The model takes weeks to build, requires data from across the organisation, and demands a level of accounting discipline that often surprises the operations team. The investment pays off many times over because the model changes the centre of gravity in every subsequent commercial conversation. The buyer who walks into a RISE negotiation without a counter model is negotiating inside the seller's frame. The buyer who walks in with a counter model is negotiating in the buyer's frame. The shift in frame is, in our experience, the single most reliable predictor of the size of the discount stack the negotiation ultimately produces.