Operating model implications of RISE versus brownfield.

The financial comparison between RISE with SAP and brownfield S/4HANA is the conversation that gets the airtime. The operating model comparison is the one that decides whether the deal works after signature. The two architectures imply different team structures, different run book ownership, different incident response cadence, different change management rules, and a different posture toward the vendor. A buyer who signs RISE without redesigning the operating model arrives at year two with a team that no longer fits the architecture, and a brownfield organisation that walks into a RISE renewal without reading the operating model implications will sign for capabilities it cannot consume. This article documents the operating model shifts that follow the architecture choice, and what to design before the contract is signed.

Team structure shifts toward service management

A brownfield S/4HANA team sits inside the buyer organisation and owns the system end to end. Basis administrators tune the database, manage the kernel, schedule the upgrades. Infrastructure engineers manage the hosting, the storage, the network. Functional consultants own the configuration. Developers maintain the custom code estate. The team is large, technical, and accountable for the system performance.

A RISE operating model shifts the team toward service management. The hosting layer is owned by SAP. The basis layer is owned by SAP. The kernel and the patching schedule are owned by SAP. The buyer team becomes the demand side, defining what the business needs, holding SAP accountable to the service definition, and integrating the SAP delivery into the broader IT operating model. The basis administrator role contracts. The service manager role expands. The skill mix moves from deep technical SAP capability to contract literacy, service measurement, and integration management.

The buyer who signs RISE without redesigning the team carries duplicate capability for several quarters and overpays. The buyer who redesigns the team without preserving enough internal SAP expertise loses the ability to challenge SAP when service is poor. The balance is to keep enough SAP technical depth to evaluate what SAP delivers, and to invest in the service management capability that ensures SAP delivers it.

Run book ownership splits across the boundary

In brownfield, the buyer owns one run book. Every operational procedure, from the start of day check to the disaster recovery test, is internal. The team knows the system, runs the script, owns the result. The run book reflects the buyer environment.

In RISE, the run book splits across the SAP boundary. SAP owns the procedures that touch the hosting, the database, the kernel, the upgrade cycle. The buyer owns the procedures that touch the functional configuration, the custom code in BTP extensions, the integration layer, and the business process. The two run books have to interlock. When something breaks in production, the team has to know which side owns the procedure and which side owns the fix. A poorly defined boundary creates ambiguity that extends every incident.

The buyer should document the run book boundary inside the RISE contract or the service definition document. Every procedure the team currently performs should be classified as SAP owned, buyer owned, or jointly owned, and the joint procedures should specify the handoff. The work is unglamorous and it prevents the worst operational pain in year one.

Incident response cadence changes

A brownfield incident response works at the speed of the internal team. The basis administrator sees the alert, opens the system, diagnoses the issue, applies the fix. The response time is bounded by team skill and team capacity, not by external coordination.

A RISE incident response works at the speed of the SAP service desk for any incident that touches the SAP managed layer. The internal team opens the ticket, hands the diagnosis to SAP, waits for the response, validates the fix. The end to end response time includes the SAP service desk cycle. For a routine incident the time is acceptable. For a critical incident the time can be longer than the brownfield baseline, particularly during early life when both sides are learning the boundary.

The buyer who signs RISE should negotiate critical incident SLAs that reflect the business impact, not the SAP default. A retail buyer with peak season exposure needs faster response during peak. A manufacturer with shift critical processes needs response that aligns with shift change. The default SLA in the RISE proposal rarely matches the buyer reality. The negotiation is the time to fix it.

Change management gains a vendor handoff

Change management in brownfield is internal. The change advisory board approves the change, the basis team executes, the team verifies. The process is owned, the timeline is internal, the risk is internal.

Change management in RISE introduces a vendor handoff for any change that touches the SAP managed layer. A kernel patch is scheduled by SAP. An infrastructure change is scheduled by SAP. An upgrade is scheduled jointly with constraints from SAP. The buyer change advisory board now negotiates with the SAP change calendar, not just with internal stakeholders. The change capacity of the internal organisation is constrained by the SAP cadence, and the SAP cadence is sometimes constrained by the buyer business calendar in only partial ways.

The buyer should negotiate change window protections inside the RISE contract that align with the business calendar. Black out windows for retail peak. Quiet windows for financial close. Specific exclusions for known critical periods. Without the protections, SAP will schedule changes on its own calendar and the buyer will find itself accommodating the SAP cycle rather than the other way around.

Vendor governance becomes a primary discipline

Brownfield vendor governance is light. SAP is a software vendor, the buyer pays maintenance, the relationship is transactional. The buyer occasionally calls SAP for support on a specific incident, and otherwise the relationship runs in the background.

RISE vendor governance is heavy. SAP is now a service provider with operational responsibility for production, with a multi year commitment, with a service definition that has to be measured and enforced. The buyer needs a vendor governance function with the discipline to hold SAP accountable. Quarterly business reviews. Service measurement dashboards. Escalation paths. Contract amendment processes. The function does not exist in many brownfield buyer organisations and has to be built before RISE signature, not after.

The buyer who underinvests in vendor governance discovers in year two that SAP has set the operating cadence and the buyer is accepting what is delivered rather than directing it. The buyer who invests in vendor governance from day one keeps the leverage and the visibility that justifies the original signature.

Integration management becomes a new responsibility

The integration layer in brownfield runs on infrastructure the buyer owns and manages. The buyer team knows the topology, the failure modes, the performance characteristics. Integration incidents are diagnosed inside the team.

The integration layer in RISE sits at a boundary the buyer does not fully own. SAP provides the inbound and outbound interfaces. The buyer provides the connecting systems. The integration runs across a boundary that requires joint diagnosis when it fails. The buyer team has to gain depth in the RISE integration patterns, in the BTP integration suite, in the monitoring tools that span the boundary. The capability has to be built and resourced.

The buyer should plan a dedicated integration capability that owns the boundary, monitors both sides, and coordinates with SAP when joint diagnosis is required. The capability is not free. It is a real headcount and tooling investment that the operating model needs to fund.

Conclusion

The architecture choice between RISE and brownfield is also an operating model choice, and the operating model choice has consequences that arrive after signature and persist for years. A team designed for brownfield does not run RISE well. A team designed for RISE does not run brownfield well. The buyer who treats the architecture decision as a software decision pays a delivery tax for the duration of the term. The buyer who designs the operating model alongside the architecture builds an organisation that fits the decision. The work happens before signature, or it happens painfully after. The choice is whether to do it deliberately or learn it the hard way.