Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
lukekrogh
Explorer
Authorizations are such an integral part of an SAP environment. Unfortunately, not many have noticed the subtle changes that have impacted migrating from SAP ERP to SAP S/4HANA. Despite the lack of coverage, these authorization evolution elements are apparent to anyone who has to use the new system almost immediately. How has authorization changed between SAP ERP and SAP S/4HANA? Let's investigate.

The History of Authorization in SAP ERP


Initially built in 1993, SAP ERP was designed to be an Enterprise Resource Planning (ERP) system that utilized three distinct layers: database, application, and presentation. It was designed to be flexible and scalable, supporting multiple Database Management Systems. Authorization in this first release used client-server authorizations, but this eventually evolved into a system that limited access to a particular set or subset of applications for a user group. Transaction codes in this early iteration of SAP ERP were annotated. The transaction name would give a clue as to which department used it; for example, financial transactions would use the prefix F before the rest of the transaction name. Applications had further delineated what they could do, so users could quickly tell the difference between a display and an update function.

SAP NetWeaver was the next step in SAP ERP's evolution. This iteration of SAP was built to work alongside other systems. NetWeaver's ability to integrate Java-based code alongside existing SAP applications made it a powerful addition to any business. In keeping with this goal, NetWeaver's authorization system encompassed access privileges to those third-party plugins and applications.

In 2011, SAP released SAP S/4HANA, which evolved the ERP system further. SAP S/4HANA simplified the data model and all related processes while offering real-time analytics and massive extensibility. The system was eventually adapted for architectures with the SAP Business Warehouse (BW) release in 2012. SAP S/4HANA is distinctly different from other ERPs in that it offers businesses a relational database management system (RDBMS). The RDBMS allows SAP to provide functionality such as real-time insights at every level of an organization. The authorization and security layers in SAP S/4HANA are similar to those used in SAP ERP, although adapted for this massively scaled-up rollout.

Deployment Models for SAP S/4HANA


SAP S/4HANA has several different deployment routes, with each one appealing to a different type of company. They also have other methods of allowing access to applications and layers within SAP S/4HANA. Usually, when deploying S/4HANA, businesses have to consider the tradeoff between the level of flexibility and standardization. Generally, standardized deployments have low flexibility but are compatible with a wider variety of third-party applications. Non-standardized implementations, on the other hand, offer the business a lot of scope in what it can do, but it may be required to customize its integrations with the core SAP systems.

Types of Installs


Traditional users of SAP ERP will recognize the on-premise of installation readily. On-premise installs were originally the only way for SAP to be installed, but with the advent of cloud computing and SaaS, it has seen a drop-off in popularity. An on-premise solution offers the most flexibility with the least amount of standardization of apps and services. The business itself may choose to operate their on-premise install or prefer to have a third-party business operate it for them. If the company decides to have a third-party infrastructure operator, they are still responsible for the cybersecurity of the installed systems. Software-as-a-Service systems deal with security themselves. Infrastructure-as-a-Service allows the business to implement added flexibility and advanced security and authorization.

The least flexible approach is the cloud installation of SAP S/4HANA. This standardized system allows for a wider variety of integration between third-party providers and the SAP backbone. As an SaaS solution, the cloud provider manages authorization and security. SAP allows complete flexibility with cloud providers, allowing businesses to choose their own and not be limited by SAP's offerings. User access boils down to a simplified group-based access model within a cloud deployment. Security models will not be required to design roles for the organization anymore but rather work out how to provision those user groups with the correct data. If a business wants more customization, it may have to examine the existing cloud deployment options and choose one that balances flexibility and standardization.

Moving Forward Into the New Generation of SAP


Most on-premise solutions are dated, and businesses realize that they can't get the type of performance they would prefer from these installations. Luckily, because of the sheer volume of cloud deployments, enterprises aren't limited in what they can do with their SAP installation. Instead, they have access to the scalability and flexibility of an on-premise installation alongside the power and easy integration from standardized cloud deployments. It's a win-win situation. However, authorization and security are vastly different in this online cloud environment. Because of the sensitivity of these systems, many standardized deployments focus on keeping things simple, which means less complex user groups and permissions. A business's security department should look at the happy balance between custom user groups, licenses, and cloud access when shifting to a Cloud SAP S/4HANA deployment.
1 Comment
Labels in this area