Defining the SAP Cloud ERP Solutions and Implementation Methods

Most cloud applications have services delivered by the provider of the application, which are typically detailed in the Service Level Agreement (SLA). However, the architecture and services offered vary based on whether the cloud applications are SaaS (Software as a Service) or managed cloud services.

SaaS applications are completely managed by the service provider and come ready to use, including all updates, bug fixes, and overall maintenance, and are typically multi-tenant. 

SAP's Cloud ERP SaaS offering is SAP S/4HANA Cloud Public Edition, which is installed in an SAP data center. There is also a package of additional licenses and tools that accompany the core ERP software to help customers get the most out of their solution.

In a managed cloud service, the service provider has control over the cloud infrastructure and is fully responsible for its operation, maintenance, monitoring, availability, and support, and the infrastructure is typically single-tenant. In addition to the SLA, there's an additional document describing detailed roles and responsibilities of the customer and the service provider. Certain services are negotiable, where the customer may choose to perform a task themselves, or request the cloud provider perform the task on their behalf for an additional fee.

SAP's Cloud ERP managed cloud services offering is SAP S/4HANA Cloud Private Edition. The managed cloud services are delivered by Enterprise Cloud Services (ECS), and the software is hosted on an Infrastructure as a Service (IaaS) that can live in an SAP data center, or a third party data center partner. We refer to these data center partners as hyperscalers, which include, Microsoft Azure, Amazon Web Services, Google Cloud, and Alibaba Cloud. There is also a package of additional licenses and tools that accompany the core ERP software to help customers get the most out of their solution.

The decision of which Cloud ERP solution to select often depends on the degree of standardization versus the degree of flexibility required by a customer in their enterprise software, and the implementation method.

A two-tier ERP strategy is when a company uses different ERP systems (either from the same vendor or different vendors) at different layers of the organization.

There are several possible two-tier ERP scenarios, but a common model is where Tier 1 serves as the global backbone running administrative ERP processes (e.g. finance) and Tier 2 is tailored for localized business needs, a subsidiary, or a smaller business unit.

This allows an organization to standardize on Tier 1 to meet functional and budgetary requirements, while maintaining flexibility with the business functions in Tier 2.

With SAP S/4HANA Cloud Public Edition, an organization can quickly deploy the public cloud for a subsidiary, while keeping the total cost of ownership low. This approach offers agility to the subsidiary, while the tight integration with SAP S/4HANA (on premise) or SAP S/4HANA Cloud Private Edition deployed for the headquarters will ensure a high degree of visibility into the data and operations of the subsidiary.

Market drivers to adopt a two-tier ERP

• Onboarding new acquisitions quickly
• Standardizing subsidiaries on a harmonized platform
• Preparing for an anticipated divestiture
• Adapting to new Processes or entirely new Business Models
• Centralizing services like finance or procurement
• Extending the supply chain control with business partners
• Expanding through Joint Ventures
• Adapting to evolving geo-political situations
• Preparing for changing data residency regulations

There are three common examples of two-tier ERP scenarios:

• Headquarter and Subsidiary
• Central Service
• Supply Chain Ecosystem

Building an effective two-tier ERP strategy is about more than just integration scenarios. It's critical to conduct a thorough analysis of the functionality necessary for each subsidiary or satellite, and the strategy must define how the interdependence of the organizations will affect the business processes AND the reporting strategies.

For example, the reporting strategy for intercompany transactions and enterprise-level reporting should be defined up front. In addition, master data management will follow integrated process requirements, and therefore should also be planned for early in an implementation project. Last, change enablement is multi-dimensional, because there are new systems that require sufficient end-user training, and potential changes to business processes with the interdependence between organizational entities.