RISE with SAP Options for Cloud and On-Premise Systems

⇨ There are significant differences in the key drivers involved in choosing between a cloud-based or on-premise system.

⇨ Organizations should make this choice based on specific business and functional areas, such as financials, logistics, and human resources.

⇨ Users should research potential Add-Ons to help with the effort required to retire legacy systems.

RISE with SAP

The beauty of the RISE with SAP is that you can mix and match cloud-based and on-premise systems. You don’t have to decide on the “or.” It can be a mixture of both worlds. Starting from pure public cloud-solutions as SAP SuccessFactors, organizations can end up in a full-blown hyperscaler-based private cloud on-premise-like solution.

Cloud-First Strategy

If you value scalability, security, and up-to-date technology, the cloud option should always be your choice, when available. Although it enforces standardization with limited modifications, it offers virtually unlimited possibilities for system configuration (customization). One of the key advantages of cloud solutions is their scalability, allowing resources to be easily added or removed as needed, based on fluctuating demand.

Besides scalability, cloud computing also provides robust security features to protect customer data from potential threats. SAP employs a variety of security measures, such as firewalls, encryption, and access controls to safeguard customer information. Moreover, cloud computing enables companies to access the latest applications and software updates nearly in real-time, ensuring that they remain current. This serves as the foundation for the two other benefits: You are always secure and scalable with the newest version in use.

On-Prem First Strategy

If you really want to own your data or are required by law to process all data in-house, there is no alternative to the on-prem option. It is not better or worse than the cloud solution. The thing you have to consider is updating the entire system stack regularly, implementing security measures, and scaling up and down according to your needs. Rejecting modification requests is not so easy simply because you can. All of this comes at a price.

On the other hand, it is your system, your performance, and your speed. You don’t rely on an abstract layer of servers, network, storage, or sub-suppliers, among others. You own it, you run it, and you are accountable for doing so.

In Conclusion

Whichever way you choose, you will be on the safe side using the standard provided by SAP. It may also vary for different application areas. Near-real-time systems, such as warehousing and production, might perform better on your dedicated server, while sales data could potentially work more effectively on a globally distributed cloud platform.

SAP Systems and Modules Based on the Business and Functional Areas

Financials

Aside from legal or company-specific rules, there is no need to use an on-premises solution. All financial modules are available in cloud-based ERP solutions. Whether it is accounting, financial close, financial operations, advanced financial operations, cost management, or profitability analysis, all modules meet the requirements of a modern company. They are available in many languages and cater to nearly every legal context worldwide.

Logistics

Conversely to financials, logistics relies more on the core of your industry than on legal requirements. It involves the methods of selling, sourcing, and converting. Logistics often requires near-real-time processing and, frequently, 24/7 availability. The selection of modules depends on pre-consulting and solution scoping, as well as the level of detail desired.

For example, consider material configuration: Do you use a single product in many variations (like a car), or is it more a collection of similar materials (like different types of watches)? The best strategy here is to research in two directions: First, seek the best functional solution outside your industry, learning configuration from the automotive industry rather than from your competitors. Second, investigate the best technical setup in similar businesses. For instance, learn from neighboring warehouse providers about their experiences and insights with or without cloud-powered ERP setups.

Human Resources / Human Capital Management

This is a challenging aspect: SAP has a clear strategy to use a cloud-based system, which is supported by SuccessFactors and their many useful functions. However, when it comes to payroll, SAP still uses the “old” R/3-based HR-PY functions, which have been transformed into S/4HANA and are based on a small server hosted by SAP. This is good news from a security standpoint because your most important data is kept isolated from the cloud.

However, it is also a downside because SAP has not made progress in moving toward a truly cloud-based HR/4HANA world with a new code stack and improved functionalities. For example, if you work in a specialized HR-Payroll industry such as temp work, you may need to enhance the standard functionalities. Overall, unlike other modules, it is recommended to use the system as it is.

Cross-Applications, Basis, and Security Functions

SAP offers suitable solutions for various needs, whether in a cloud-based or on-prem system, in standard configuration and pricing. However, newly integrated products lack integration in the straightforward transport scheme as known from the S/4HANA core.

This leads to a slight administration overhead, such as if one needs to implement a system change into BTP and the corresponding function into S/4HANA. When using S/4HANA, this is done automatically through ChaRM (Change Request Management), but it is not widely available for BTP.

SAP needs to improve its security support for their customers. An ABAP code profiler is available, but it is quite expensive, and there is no such tool for BTP and other cloud products. The SAP authorization concept is unbeatable, in my opinion.

Many software providers cannot assign authorizations on organizational structures and levels, but with SAP, you can authorize a single function, account, one or more companies, order types, or a mixture of them. It is crucial to consider authorizations from the beginning. In summary, based on the decisions made for business applications, there may be a significant downside to the functional setup.

The Use of SAP Add-Ons

SAP Add-Ons are meant, in this context, to be third-party software components that add specific features and functions to SAP systems, such as S/4HANA. They are developed using the same technical stack as the SAP system, such as ABAP components.

The downside of such enhancements is that they add technical complexity to your system, right from the start. Every upgrade and new function must be compatible with both the SAP system and the Add-On. Additionally, you must consider if the Add-On adheres to your security coding guidelines, as well as whether the supplier will remain in business as long as your SAP system. You must also consider whether the version you purchased will be replaced by a newer, more expensive suite that you only use a small portion of. In general, it is best to avoid add-ons if possible.

The “Add-On” approach has been available for many years through SAP BTP. This setup allows for easy plug-and-play functionality, as well as complete disposal, parallel run, and encapsulation in case of retirement or replacement. Unfortunately, few suppliers have taken advantage of this “keep-the-core-clean” approach.

The Retirement of the Old Systems

Depending on the use case, there may be a need to access old data for various reasons such as short-term lookup of single records to find mistakes, reporting purposes, and legal requirements. For reporting, monthly balances or already-built aggregates can be used, while for legal reasons, the required shelf life should be determined for relevant data records to be stored.

Based on experience and best practice, the following recommendations can be made:

• Nonproductive systems, including development and quality assurance, can be erased about one month after the point of no return.
• High availability, dual data center, and continuous backup can also be removed from production systems at this time.
• A separate golden copy of tax- and audit-relevant systems should be kept, while personal data can be deleted one year after the point of no return while keeping tax- and audit-relevant information.

System upgrades are necessary to avoid running out of support or security risks. After two fiscal years with the new system, tax- and audit-relevant systems can be shut down and all other supporting systems, including the golden copy, can be deleted. For the remaining retention period, the system should be upgraded once a year, and personal data should be deleted. Finally, after the retention period, all data, including backups, backups of backups, and cold standby, should be checked and deleted.