8.2    SAP S/4HANA Versions

SAP S/4HANA Enterprise Management is available in two major flavors: on-premise and cloud. From a functionality perspective, there are some divisions in the different versions available for the cloud version, such as the SAP S/4HANA Marketing Cloud or the SAP S/4HANA Project Services Cloud, but we’ll be focusing on the SAP S/4HANA Enterprise Management Cloud in this section, which covers scenarios from logistics, financials, and project management.

Let’s now dive into the SAP S/4HANA, on-premise edition, before moving on to SAP S/4HANA Cloud and the hybrid of the two. In the following section, we’ll provide criteria for choosing between your different deployment options.

8.2.1    SAP S/4HANA, Deployed On-Premise

The SAP S/4HANA, on-premise edition, is the entire SAP ERP scope with simplifications in several core areas. This has already been covered in earlier chapters, including an overview in Chapter 2, and discussion of finance (FI) and logistics functionality in Chapter 3 and Chapter 4, respectively. For the on-premise edition, the release cycle for new functionality is on an annual basis and can be deployed on-premise or on cloud with the IaaS model.

The first decision for the client is to choose the right SAP S/4HANA product version: on-premise SAP S/4HANA or SAP S/4HANA Cloud. When making this decision, the client should consider the following primary aspects:

• Licensing model
  The SAP S/4HANA, on-premise edition, follows the traditional licensing model. For SAP S/4HANA Cloud, the pricing follows subscription-based licensing, per the SaaS model.
• Range of functionality
  So far, the on-premise version has the complete set of functions from SAP Business Suite/SAP ERP, although not all of them use simplified code or the SAP Fiori frontend. SAP S/4HANA Cloud covers specific business processes for marketing line of business (LoB) and the professional services industry, while SAP S/4HANA Enterprise Management covers scenarios for a digital core, including FI, Controlling (CO), Procurement, Sales and Distribution (SD), Manufacturing, Plant Maintenance (PM), Project System (PS), and SAP Project Lifecycle Management (PLM). The scope of functions for SAP S/4HANA Cloud will be enhanced on a quarterly basis.
  Therefore, a customer who needs the full-blown SAP ERP functionality for its business beyond what is provided by SAP S/4HANA Cloud needs to opt for the on-premise version or wait for SAP S/4HANA Cloud to reach the state where it can cater to these functionalities.
• Standardization versus flexibility
  The on-premise version provides complete flexibility to do any customization to the standard solution, as is required by the customer’s business processes. SAP S/4HANA Cloud, on the other hand, provides limited ability for customization. Thus, this edition is suited to those organizations that have the strategy to adopt standardized processes. Thus, they can adhere to the functionalities provided by SAP S/4HANA Cloud.
• IT strategy in terms of usage of SaaS
  The IT strategy for some of the major organizations is to adopt a SaaS model for all their IT solutions, even their ERP solutions. This might potentially drive them to adopt SAP S/4HANA on-premise if the first premise in terms of functionality is met.
• Infrastructure and operations
  For the on-premise edition, the client has complete control of the infrastructure, deployment, and maintenance schedule. For SAP S/4HANA Cloud, SAP provides the system and any service-level agreements around the nonfunctional requirement. They also have to test the delta functions every quarter for a fixed number of days before the updates are applied. Thus, the customer has no control over accepting the versions upgrade. This has some advantage in terms of less maintenance, but companies need to plan for the resource and effort for this continuous testing every quarter.
• Implementation approach and time lines
  The implementation for SAP S/4HANA Cloud is much faster due to the standardized process configurations, which include SAP Best Practices for implementation. Both new and existing SAP ERP customers need to only do data migration, which is aided by migration tools and templates for different data objects. Deep technical skills aren’t needed. For the on-premise implementation—both for the migration scenario and the new implementation scenario—the technical knowledge and skills are mandatory for the team because there will be customer-specific scenarios and considerable customization. The time lines for the SAP S/4HANA adoption are also longer.
• Costs
  Costs are affected by several factors, including the reduced implementation time lines. However, because SAP S/4HANA Cloud is a SaaS model, the product licensing costs and the infrastructure and operational costs decrease. Because SAP S/4HANA Cloud has fewer customization capabilities, it also has the advantage of less maintenance overhead. Apart from the licensing model, the infrastructure investment and maintenance overhead can also be tackled through an IaaS adopted for the on-premise edition.

There can be certain constraints as well in terms of SAP S/4HANA Cloud adoption. Following are the three main constraints:

• Regulatory compliance might compel the data to be on-premise, or the data might not be able to be taken outside the country, requiring in-country hosting of the data center.
• Organizations have security concerns about the data being in the cloud, in the public domain, beyond the organization’s firewall.
• The size of the database may be too large for the currently available cloud options for SAP HANA.

The second concern is gradually getting changed to certain precautionary steps the customer should take, and, of course, the cloud providers have to follow standard security processes to be certified for productive usage by customers. Apart from the standard security features related to user authorization and authentication, data security and privacy controls in SAP products are available irrespective of being on-premise or in the cloud. From a physical security perspective, SAP data centers comply with the latest telecommunications industry standards, such as ANSI/TIA/EIA-942 Tier III or higher.

The summary of what the SaaS, PaaS, and IaaS offerings mean for the customer is shown in Table 8.1.

IaaS	PaaS	SaaS	Service Model	Control over Cloud Service
		Applications	SaaS: Consumed by end user, delivered through internet	Limited user-specific configuration and customization No control over software release and update No control over underlying platform and infrastructure
	Operating system and middleware runtime	Operating system and middleware runtime	PaaS: Application deployed on managed services	Control over application deployed Control over application-specific configuration on hosting environment No control over underlying infrastructure
Server, storage, and network	Server, storage, and network	Server, storage, and network	IaaS: Computing resources available at lowest infrastructure component level	Control over application, operating system, and updates Limited control over network No control over underlying physical infrastructure

Table 8.1    SaaS, PaaS, and IaaS Options Summary

After choosing the relevant product version, there are more decisions to be made. The on-premise version can be deployed on the cloud or on-premise with options for multiple deployment models (the terms were explained in greater detail in Chapter 6):

• Multiple Components One System (MCOS)
  In the same SAP HANA server, multiple SAP HANA databases along with the System ID (SID) can be configured (e.g., development and quality environments).
• Multiple Components One Database (MCOD)
  Multiple SAP components are running on the same SAP HANA database.
• SAP HANA Multitenant Database Containers (MDC)
  Multiple tenant databases are isolated in the same SAP HANA system.
• Virtualization using smaller virtual machines (VMs)
  Smaller VMs are used within the SAP HANA system, or logical partitioning (LPar) is used.

Figure 8.2 shows the decision tree for choosing the SAP S/4HANA deployment.

Figure 8.2    Decision Tree for SAP S/4HANA Deployment

There can even be a combination or a stacking option for these deployment models. Some options are provided by the specific hardware, including the processor. For example, IBM Power machines with its proprietary processors can provide an MDC on top of a VM (virtual machine).

The customer’s SAP HANA-related existing infrastructure setup, the database size requirements, and the nonfunctional requirements all affect the choice of deployment models for SAP S/4HANA. For example, your choice may be influenced by the following:

• If there are other applications that use the SAP HANA database, you might look at combining and sharing the infrastructure to minimize costs.
• If the database size is too large, then the resource sharing options won’t work out, at least for the productive environment. You might look at sharing the nonproductive environments, using one of the options (e.g., MDC/MCOD/MCOS) and virtualization or a combination of these options. The restrictions for such deployment options must be adhered to, as explained in Chapter 6. For example, there are products that can be deployed as MCOD for production, as per the whitelist provided in SAP Note 1661202. These restrictions don’t apply if each application is deployed on its own tenant database, but they do apply to deployments inside a given tenant database (in a MDC scenario).

  Note

  There are additional SAP notes for the different deployment scenarios (e.g. SAP Notes 2096000, 1681092, 2248291) and the SAP HANA Master Guide should be referred to while deciding the right deployment option for a combination of applications (http://help.sap.com/hana/SAP_HANA_Master_Guide_en.pdf).

The deployment option can also be chosen based on SAP recommendations and considerations about the advantages and disadvantage of that option. For example, SAP recommends using MDC for all the MCOS scenarios where it fits and also for MCOD because MDC supports most of the MCOD scenarios. On the other hand, all the SAP HANA applications deployed using MDC will share the same SAP HANA database. As a result, any SAP HANA database upgrade will impact all the applications at the same time. In addition, the High Availability/Disaster Recovery (HA/DR) configuration will impact all the tenant databases because they are part of the same SAP HANA database.

Another example is that SAP supports multiple SAP HANA databases on the same system (the MCOS scenario), even for the production environment, but only for scale-up or single-host scenarios. For this option, sizing has to be done carefully, and proper volume testing is important before going live because contention for the system resources by the different components using the same system may lead to poor performance in production (see SAP Note 1681092). Your choice may also be influenced by the following:

• The underlying infrastructure from existing vendors and the scalability options for those hardware. Depending on their maximum available size, the workload can be virtualized so that proper resource sharing happens.
• Nonfunctional requirements (NFRs) play an important role on the choice of deployment model. Some examples are listed here:
  • Responsiveness: This may determine whether any cloud deployment is an option for the productive environment. For high responsiveness, on-premise is the preferred option.
  • HA/recovery time objective (RTO)/recovery point objective (RPO): Certain options are better from a HA requirement point of view. If cloud providers can’t cater to availability, say, more than 99.5%, or if such Service Level Agreements (SLAs) could have high cost impact, having the system on-premise might be the best choice. Another example of a cost-optimized HA option occurs when the system on which the secondary server is running can be shared with the nonproductive instances.
  • Disaster Recovery (DR): The option to have the DR set up in the cloud while the workload runs on-premise is a cost effective one. Alternatively, your cloud partner should be able to provide and maintain a DR solution, if the actual solution is also hosted on cloud.

For an organization that wants to use IaaS for the on-premise deployment of SAP S/4HANA, there are several options along with the management functions on top of these infrastructure services. The cloud vendors normally offer unmanaged IaaS, managed IaaS, or managed PaaS. The different type of services are shown in Figure 8.3.

Figure 8.3    Service Options for IaaS and PaaS: Managed and Unmanaged

8.2.2    SAP S/4HANA Cloud

This version of SAP S/4HANA is equivalent to a SaaS model and is maintained and operated by SAP in SAP’s infrastructure. SAP S/4HANA Cloud is again available in two flavors:

• Public version
• Private version

SAP S/4HANA Cloud, public option, has limited flexibility in terms of customization. It doesn’t allow modification of standard objects but allows limited extension. SAP S/4HANA Cloud, private option, allows a similar level of modification but more flexibility in terms of usage. For example, for the public version, the processes are only accessible through SAP Fiori apps. Thus, the challenge lies in the fact that functionalities available on simplified code without an SAP Fiori app won’t be available on the public cloud. However, for the private version of the same product, these other processes are accessible through SAP GUIs.

The snapshot of major processes available in SAP S/4HANA Cloud is covered in Chapter 2. Table 8.2 provides an overview for the different cloud editions; there are features and functions added an enhanced with each quarterly release. The 1608 version included line of business (LoB) solutions as part of SAP S/4HANA Enterprise Management Cloud.

	SAP S/4HANA Enterprise Management Cloud	SAP S/4HANA Professional Services Cloud	SAP S/4HANA Marketing Cloud
Features	Edition for main ERP scenarios: Streamlined procure-to-pay Accelerated plan-to-product Optimized order-to-cash Manufacturing (production planning and execution) HR connectivity Core finance	Edition for the professional services industry: Project services Streamlined procure-to-pay Sales order processing Various analytics Core human resources Core finance (subset of SAP S/4HANA Enterprise Management Cloud)	Edition for the marketing line of business now full scope of SAP Hybris Marketing: Consumer and customer Analytics and segmentation Campaign management Marketing recommendation, planning, and executive dashboard
Features (Cont.)	Project services Advanced ATP Contains LoB cloud solutions		Offer management with loyalty
Countries supported	17 supported country versions	US, DE, AU, CA, CN, UK, HU, NL, SG, BE	Country independent
Languages	EN, DE, FR, ES, RU, CN, JA, PT, NL, HU	EN, DE, FR, ES, RU, CN, JA, PT, NL, HU	EN, DE, FR, ES, RU, CN, JA, PT, NL, HU
Integrations	SAP Ariba, SAP Hybris, SAP Hybris Cloud for Customer, and SAP SuccessFactors	SAP Ariba and SAP SuccessFactors	SAP Hybris, SAP Hybris Cloud for Customer

Table 8.2    Overview of SAP S/4HANA Cloud Features

Note

More details regarding the features for each release can be found at http://help.sap.com/s4hana.

However, before we discuss the private and public cloud options in detail, let’s first take a look at some items you should consider before deciding if your landscape and your business are ready for SAP S/4HANA Cloud.

Initial Considerations

You may start by asking yourself the following questions:

• Are all types of workload cloud ready?
• How do we analyze the workload to check for cloud readiness?

There are methods to analyze the workload that cloud providers such as IBM or Microsoft can use to help organizations determine the feasibility. Some of the examples of the workload traits that determine their readiness for cloud adoption are shown in Table 8.3.

Not Ready for Cloud	Possibly Ready for Cloud	Ready for Cloud
Sensitive data High degree of customization Not virtualized software Complex processes and transactions Regulatory constraints Complex software licensing Tight integration with other on-premise systems	Information intensive Isolated workloads Mature workloads Non-production systems Batch processing	Analytics Infrastructure storage Industry applications Disaster recovery Development, test, and training environments Infrastructure compute Business processes (e.g., CRM, HR, etc.) Industry vertical application Web hosted apps Collaboration Office applications

Table 8.3    Workload Cloud Readiness Analysis Sample

What about cloud adoption for SAP ERP, which is, for many organizations, the core transactional system supporting mission-critical business processes? Enterprise software such as SAP ERP is often at the core of the organization’s business processes. Although these solutions don’t see the type of seasonal variability experienced by other solutions, such as e-commerce sites, there are still demands for periodic scalability (e.g., testing environment for a project duration). Many of the other business drivers also hold good for these ERP solutions. There are some additional factors as shown in Figure 8.4, which show how the standard non-differentiating processes can be moved to the cloud while differentiating solutions requiring heavy customization stays on-premise or in a private cloud. The other influencing factor is the regulatory compliance applicable for the organization, including country-specific rules.

The trend shows quite a move toward a hybrid adoption pattern for solutions such as SAP ERP. Before we discuss the hybrid model, however, we need to look at both the private and public cloud.

Figure 8.4    Cloud Decision Influencers for SAP ERP Solutions

Private Cloud

The advantages of private cloud deployment are as follows:

• The same level of security is used as with on-premise because the environment is set up only for one customer and isn’t shared.
• While initial investment is required to build the infrastructure, the advantage is in the ability to effectively use that infrastructure (e.g., rapid provisioning, etc.) and reuse existing hardware.
• This is a good option especially for an IT landscape that has a large number of systems and requires high-volume transactions with close integration with other systems.
• A few partners, such as IBM and HP, offer services to build a private cloud environment.

From an SAP S/4HANA perspective, this is just different model, but the same rules apply as for on-premise. In addition, the private cloud needs to use SAP-supported hardware and supported virtualization techniques.

Public Cloud

The advantages of a public cloud deployment are as follows:

• Cost savings is one of the major advantages for the public cloud option. There’s no need to invest on infrastructure, and no upfront initial investment for capital expenditure (capex) is required; rather, it’s a pay-for-usage model.
• This is a good model for all customers (even startups or individuals) unless there are other concerns or constraints as mentioned earlier.
• Many public cloud offerings are available for SAP S/4HANA from SAP as well as partners such as IBM, Amazon Web Services (AWS), and Microsoft Azure.

From the SAP S/4HANA point of view, the cloud service needs to have official support status from SAP. From an overall perspective, however, the management requirement for the cloud infrastructure, the customer’s responsibility, and the cloud vendor’s responsibility should be clearly determined.

8.2.3    Hybrid Model

As mentioned earlier, all workloads aren’t the right fit for the cloud. More often than not, organizations have to take a middle path and choose a hybrid model to optimize the cost and time benefits versus other considerations. In addition, while an organization can have a road map to take all the applications to cloud, this can be a multiyear journey.

For SAP S/4HANA adoption for cloud, some organizations want to have the nonproduction on the cloud but the production on-premise. For some others, they want their SAP Business Warehouse (SAP BW) on the SAP HANA system in the cloud but want their SAP S/4HANA either on-premise or on a private cloud because critical business processes may have responsiveness requirements that need a data center in a physically closer location or may require a high-bandwidth connectivity. This will have a cost implication and may act as a deterrent to be on the cloud. Figure 8.5 shows examples of the different scenarios where the environments of an SAP solution can be deployed all on-premise, on the cloud, or using a hybrid model.

Figure 8.5    Example of a Hybrid Cloud Scenario

There can be several other use cases for hybrid cloud scenarios. The following list is a representative set and not exhaustive:

• Integration of legacy and new landscape
• Have the systems of engagement on the cloud while the system of record remains on premise, for example, SAP Fiori or SAP Gateway on SAP HANA Cloud Platform, which connects to a backend SAP S/4HANA, on-premise
• Offload the variable load, for example, a testing server or an upgrade project requiring a parallel landscape to the cloud
• For a IT landscape with multiple SAP instances, the smaller instances (which should be closer to standard SAP solutions) can move to SAP S/4HANA Cloud, while larger ones with more customization can be on-premise. There can be several such combinations of the two-tier ERP landscape, including the possibility to combine SAP S/4HANA solutions and non-SAP HANA SAP ERP solutions.