Introduction
An SAP system in the cloud does not necessarily result in a cloud operating model. Numerous organizations switch to a different hosting environment without altering the ownership, support processes, development practices, or release procedures.
That results in another issue with SAP Cloud ERP. While SAP is responsible for a greater share of the underlying infrastructure and technical service, your IT organization remains in control of how the ERP enables business operations. The importance of architecture, security, integration, custom development, testing and business process ownership thus increases, not decreases.
This difference can create blind spots for teams moving from ECC or on-premise SAP S/4HANA to SAP S/4HANA Cloud. The uncertainty of ownership in the old model can cause problems, custom code can be in conflict with clean core, and project-based testing can fail to support repeated releases to the cloud. The operating model needs to change with the architecture.
The vision of SAP Cloud ERP is to shift IT responsibility from infrastructure to managing the ERP service, architecture, security, integrations, extensions, testing, and business processes. Your organization is responsible for getting the cloud ERP to perform reliably across the business, while SAP handles more of the technical groundwork.
What Is SAP Cloud ERP and What Does It Mean for IT?
SAP Cloud ERP is SAP’s cloud ERP approach, focused on the SAP S/4HANA Cloud deployment models, where more technical infrastructure responsibility is placed on SAP, but business processes, security, integrations, extensions, data, and governance remain owned by customers. Broadly speaking, SAP S/4HANA Cloud Public Edition and Private Edition are two separate deployment paths in this cloud ERP approach.
The key is that cloud ERP doesn’t just move the SAP system. It alters the customer-SAP interface.
In a classic ECC environment, the customer’s IT organization might handle the infrastructure capacity, transports, backups, upgrades, SAP technical administration, operating systems, and servers. Those tasks build a huge “wrapper” around the ERP application.
Cloud ERP takes some of that work off the customer’s plate. But the business system must still be run by the organization. Someone needs to determine how things happen, what integrations are essential, who gets access to the system, where to put custom logic, how releases will impact the business, and where technical problems will go between SAP and internal teams.
That distinction sets the groundwork for the new operating model.
Rethinking IT Responsibilities with SAP Cloud ERP
By dividing the IT roles between infrastructure management and application and business-service management, SAP Cloud ERP transforms the job of IT. The customer retains control of configuration, security, integrations, extensions, testing, data and business process decisions, and SAP manages the defined cloud service.
The exact boundary depends on the SAP edition and contractual service scope. So you should not expect all technical accountability to be passed on to SAP automatically.
In this case, a company might no longer need to manage the underlying database infrastructure. It still requires people who grasp the impact of database performance on applications, understand how integrations use the SAP services, and know how business processes operate across system boundaries.
The Responsibility Boundary Is More Important Than the Technology
Failing to have a clear owner for each responsibility is one of the reasons a cloud operating model does not work.
Assume a production problem: an external application is not able to create sales orders in SAP. The business process may be down, but the infrastructure is up. The root cause may be an API, authentication, integration flow, business configuration, authorization or external application.
In the old operating model, multiple teams could take that as an SAP issue. A cloud operating model requires another way. It should establish a business process ownership model, not responsibility in the ERP alone.
That is why service management is all the more relevant once you’ve moved to SAP Cloud ERP.
How Does Cloud ERP Impact SAP Development and Extensibility?
Clean core and future releases are a key IT concern when it comes to extension architecture in SAP Cloud ERP. Depending on the needs, SAP offers side-by-side extensibility on SAP Business Technology Platform, as well as developer extensibility and key user extensibility within SAP S/4HANA Cloud.
It’s a significant shift for those teams that spend a lot of time in ECC.
In classic SAP development, organizations could often embed custom logic directly in the ERP system. That can lead to dependencies of custom code on SAP objects over time. These dependencies then proved to be a headache in upgrades.
With Cloud ERP, the pressure is greater to decide where custom functionality will be deployed before development begins.
The Debate About SAP Customization Has Come to an End
The question now for architects is where an extension belongs.
A minor UI tweak might be good for key-user extensibility. Business requirements that have tight coupling may need to be extended by the developer through ABAP Cloud. A separate application with its own lifecycle gets a side-by-side architecture on SAP BTP.
In SAP’s current extensibility guidance, these approaches are clearly separated. Key user and developer extensibility are supported in SAP S/4HANA Cloud; side-by-side extensions can be deployed on SAP BTP.
That decision has an impact beyond development. It defines how software is deployed, tested, secured, integrated, owned, and maintained over time. Explore how SAP ERP supports manufacturing operations by connecting customer orders with production processes.
With Clean Core, the Development Operating Model Is Changed
Clean core is not an arbitrary developer guideline.
It is now a question of architectural governance.
According to SAP, clean-core extensibility is an approach that continues to enable extensions but keeps an application upgradeable. It describes on-stack and side-by-side approaches, and advises organizations not to alter the core of their ERP system needlessly but instead to add custom functionality in the right extension environments.
In an IT organization, this means that developers don’t receive requirements and begin writing ABAP; instead, they need to be involved in the requirements process.
The architecture process must first consider whether the standard functionality will meet the requirement. If not, the team should consider supported extension points and APIs, and select an approach to implementation.
This creates a new dynamic between the architects, the developers and the business teams.
SAP’s Clean Core Guide provides a good starting point for talking about these issues.
SAP BTP Is an Integral Part of the Operating Model
Extensions running alongside the ERP core can play a vital role in this architecture, and that’s where SAP Business Technology Platform can fit in.
That separation creates new challenges.
Now the organization must deal with BTP environments, application lifecycles, identity, connectivity, APIs, monitoring, costs, and ownership. Developers can also use technologies other than ABAP.
So, it’s not just another place for developers to build applications. It broadens the scope of the operating model that IT is responsible for governing.
Why Does Integration Matter More in SAP Cloud ERP?
Integration is gaining in significance because SAP Cloud ERP is part of a wider application landscape, not an ERP solution in itself. Core business processes can depend on APIs, integration services, identity providers, external applications or SAP BTP components.
Take a look at the typical order-to-cash workflow.
A customer record can come from a system, enter SAP S/4HANA Cloud, initiate logistics processing, generate billing data and be shared with payment or reporting systems outside of SAP. If any of these components in that chain fails, the business could be impacted even if the ERP itself is still up and running.
This alters the way IT should monitor and support SAP.
Monitor the Business Process, Not Just the Interface
An interface monitoring dashboard can report messages as successful or failed. That is not always sufficient to indicate whether the business process succeeded or failed.
An integration can, for instance, successfully pass a sales order, but then fail due to authorization, master data or downstream processing. A technical interface monitor could return a successful message even if the business process is not finished.
It is, therefore, necessary that the operating model monitor both the technical and the business-process levels.
Integration teams need to be aware of the interfaces that are required for critical processes, and failures in those interfaces need to be escalated to the business.
APIs are now part of the architecture, and each one needs an owner.
API Governance Is Also More Critical with Cloud ERP
Each key integration should have a clear owner for the source, target, authentication, data, monitoring, error handling and business process. These boundaries save support teams hours of time trying to figure out whether the issue is associated with SAP, BTP, an external platform, or the network connection between them.
SAP BTP and SAP Integration Suite can offer integration services between SAP and non-SAP systems. But the technology doesn’t tell you who is responsible for operating it.
It’s still up to your organization to define that ownership. For more information on SAP Integration Suite, see the SAP Integration Suite Guide.
What Is the Impact of SAP Cloud ERP on Security and Identity?
While SAP Cloud ERP moves infrastructure security closer to the cloud-service controls, customers still have critical application security and identity decisions to make. Organizations are still responsible for access, roles, authorizations, identity lifecycle, segregation of duties and security governance in their environment.
This distinction is important, as cloud hosting is no guarantee of secure application access.
Users may still get too much authorization. An integration may use inappropriate credentials, granting a role access to business functions the user may not need.
This operating model should, therefore, establish ownership and approval of access design.
Incorporating Security into the Architecture
In on-premises projects, security teams may not get involved until close to deployment. This approach is less effective for Cloud ERP projects. From the outset, security teams should shape the architecture by defining identity architecture, authentication, integration credentials, roles, and application access.
An example is an extension of SAP S/4HANA Cloud that is based on SAP BTP and requires multiple identity and authorization boundaries. Those boundaries must be taken into consideration in the design phase, before building and deployment.
Security is now a continuous operating responsibility, not a project checkpoint.
What Should the New SAP Cloud ERP Operating Model Be?
With SAP Cloud ERP, a robust operating model emphasizes responsibility for the business service instead of just the infrastructure component. It combines SAP service management with clear responsibility for architecture, security, integrations, extensions, data, testing and business processes.
The first step is to identify the existing operating model, and then determine the desired future operating model.
Record the current infrastructure, Basis, development, security, integration, data, testing, incident management and release management owners. Next, align each responsibility to the target SAP cloud service.
This exercise can often bring up issues of duplicated ownership and key missing areas.
Go Beyond Technical Silos and Transition to Service Ownership
An operating model should be established that links the technical teams to business capabilities.
For instance, the order-to-cash team must be familiar with the SAP process, integrations, critical extensions, monitoring needs and release dependencies. That team doesn’t have to be equipped with all the technical pieces, but it must have a clear pathway to the teams that are.
This approach to incident management is more effective as teams can focus on business impact instead of infrastructure symptoms.
Set Up Architecture Governance Before Development
There is also a need for increased governance of custom application development in Cloud ERP.
One of the decisions to be made in an extension review is whether a requirement is met by standard SAP functionality, configuration, on-stack development or a side-by-side extension.
This review should take place prior to development.
Such separation of standard functionality, supported extensions and decoupled applications is supported by SAP’s current clean-core guidance.
It’s not meant to stop customization. The intent is to design every customization deliberately.
Treat Test and Release Readiness as a Permanent Capability
The last change is related to organizational rhythm.
An on-premise organization can build its teams around projects and major upgrades. A cloud organization needs teams that constantly evaluate releases, integrations, security, extensions, and business-process changes.
This requires ongoing activities, not just checkpoints on projects.
The ownership and measurable outcomes for architecture reviews, release assessments, regression testing, security reviews, integration monitoring, and extension governance should all be clearly defined.
What Metrics Should IT Track Once It Has Switched to SAP Cloud ERP?
Availability of infrastructure is still useful but is not a comprehensive indicator of the health of a cloud ERP environment.
A better measurement model integrates technical and business indicators. For instance, IT can track critical business-process failures, integration errors, release-test coverage, security issues, extension compliance and incident resolution.
The intent is to relate technical operations to business performance.
An ERP environment can have very good infrastructure availability while a critical billing interface fails for several hours. On the other hand, if a technical warning is not related to a critical process, it may not have much business impact.
So, the measurement model should focus on the most critical services on which the business relies.
Common Operating Model Mistakes
Treating SAP Cloud ERP as Hosted ECC
The first wrong move is transferring the existing operating model to a new hosting model.
Cloud ERP brings new concepts of responsibility, release cycles, extension patterns, and integration architectures. Cloning all the old processes preserves old technical debt rather than fixing the causes that made the move to the cloud necessary.
Assuming SAP Owns Everything
While defined parts of the cloud service remain under SAP’s control, customers still have a great deal of control over key application and business functions.
Customers own security, integrations, extensions, testing, data, configuration, and business processes.
Bringing All Custom Development to the Cloud
Just because existing custom code works does not mean it is suitable for the target architecture.
It is important that teams evaluate custom developments before proceeding with them. Some code may need redesign, replacement, or retirement, especially if it creates an unnecessary dependency on SAP internals.
SAP’s existing guidance acknowledges that classic ABAP can still be found in Private Edition and on-premise environments, and ABAP Cloud offers a way to do upgrade-safe development.
Treating Integration as a Purely Technical Issue
Integration failures can easily turn into business-process failures.
Thus, the ownership of integration should be tied to the business processes that rely on each interface.
Leaving Testing Until Late in the Release Window
Late testing is more challenging with cloud releases.
For the critical business processes and integrations, organizations should create reusable regression coverage. That method allows teams to measure changes prior to production in a repeatable manner.
Conclusion
SAP Cloud ERP transforms the IT operating model as the customer is no longer responsible for managing all layers of the ERP environment. SAP assumes more of the responsibility for the underlying cloud service, and customer teams are responsible for architecture, business processes, security, integrations and extensions, data, testing, and release readiness. The result is not less technical work. It’s a new way of organizing technical accountability.
That transformation is gaining even more significance as organizations opt for clean-core development, SAP BTP extensions, API-based integration, and regular releases of SAP S/4HANA Cloud. Ownership issues can be avoided if addressed early, so that the old operating practices do not become part of the new architecture. To begin with, map your existing SAP responsibilities, then determine the new SAP service boundary, and assign ownership of each and every key business process and integration.
Frequently Asked Questions
What is SAP Cloud ERP and how does it function?
SAP Cloud ERP is SAP’s cloud ERP strategy based on the SAP S/4HANA Cloud deployment models. Public Edition has a standard SaaS model and Private Edition offers more flexibility in a managed cloud environment. Business processes, security, integrations, extensions, data and governance remain the property of the customer.
What impact does SAP Cloud ERP have on IT operations?
SAP Cloud ERP shifts the focus of IT away from infrastructure administration and towards application, service and business-process management. SAP has more of the technical piece of the puzzle under its control, while customer teams are in charge of architecture, security, integrations, extensions, testing, data and release readiness.
What is the difference between SAP Cloud ERP Public and Private Edition?
Public Edition is focused on standardization and has a major release every six months; Private Edition offers more flexibility with two-year major releases. Private Edition is additionally impacted by feature pack stacks in between major releases.
What is the difference between SAP Cloud ERP and SAP S/4HANA Cloud?
SAP S/4HANA Cloud is the foundation product of SAP’s Cloud ERP suite. SAP Cloud ERP refers to the overall offering, and SAP S/4HANA Cloud Public Edition and Private Edition are specific deployment models and product environments.
Is SAP Basis dead in the wake of SAP Cloud ERP?
With SAP Cloud ERP, some of the typical Basis administration is reduced, but it does not mean the end of SAP technical expertise. There are still skills required for technical teams in the areas of application operations, security, integrations, monitoring, troubleshooting, testing and lifecycle management. Emphasis moves from infrastructure administration to service and application operations.
What are the impacts of SAP Cloud ERP on custom ABAP development?
SAP Cloud ERP focuses more on ABAP Cloud, released APIs, supported extension points, and clean-core development. SAP offers developer extensibility and side-by-side solutions for various requirements, while classic ABAP will still be useful in certain Private Edition and on-premise scenarios.
Does SAP Cloud ERP need SAP BTP?
SAP BTP is not mandatory for all SAP Cloud ERP implementations. Organizations can, however, use BTP to extend and integrate the ERP side by side, and to automate and add functionality separately from the ERP core. BTP should be used where it adds value to the architecture.
What do companies need to do to prepare for SAP Cloud ERP?
The first step is for companies to map what they are currently responsible for and how it will align with the boundary of the cloud service they are looking for. They should then clarify ownership for business processes, security, integrations and extensions, testing, data and release management. Do this work prior to migration, not after technical deployment.
