Nine out of ten posts on LinkedIn talk about Digital transformation and Cloud innovations today. While there is a lot of focus on digital transformation initiatives and products, majority of organisations are still lacking the foundation for taking the giant leap into embracing the big change.

Many SAP customers have started or yet to start their arduous journeys towards S/4 HANA transformation. While S/4 HANA is natural evolution to the good old ECC considering SAP’s strategy and roadmap, significant efforts and focus should be put on the “Road to S/4 HANA” evaluation than the actual conversion/upgrade. There is still a significant path to be traversed by a typical SAP customer considering their heavy investment since the R/3 days, legacy custom codes, home-grown applications, security roles, GRC and controls implementation etc.

In this article, I want to emphasize on how important it is to evaluate and transform Application security in the new S/4 HANA environment, considering added security administration, complexity and vulnerability in S/4 HANA landscape owing to enhanced financial core processes, direct access to HANA database views/tables and associated Fiori app access opening up the world on mobile. S/4 HANA Security transformation considerations and evaluations can be summarized with a set of some basic questions and pointers:

• Is GRC upgrade and enhancement part of the S/4 HANA implementation roadmap?
• How will the existing roles and authorization objects change based on new Tcodes and table structures in S/4 HANA? What is the overall effort?
• Are there new access risks or changes to the existing access risks?
• S/4HANA setup needs inherent access to associated Fiori apps and HANA database views/tables. How will these additional systems be provisioned “in-tandem” to ensure complete and consistent provisioning?
• How will elevated access be managed in S/4HANA, HANA database and Fiori systems?
• Will roles exist as a system specific composite or single role (as they used to be) or templatized in a role group with roles spawning in S/4 application, Fiori and HANA database in tandem

Moving to S/4 HANA means that the new architecture will have to be integrated into the company’s existing GRC and Access control environment. The existing GRC access control needs to be enabled for user provisioning and risk analysis in HANA database and Fiori gateway system. SAP has enabled GRC 10.1 and later versions with ability to perform risk analysis and user provision in HANA database. With Fiori and HANA coming into picture with the application core, end users will need additional security roles in these systems. Enabling provisioning functionality to these systems is imperative to ensure consistent end-user experience. The GRC workflows and configuration needs to include additional systems in the automated user provisioning.

A real-life example can be quoted here. A “Buyer” (Purchaser) in a supply chain setup is a critical position and may require access to many business functions like sourcing, contracts, maintain/create catalogs etc. He may also have reporting access to certain reports and dashboards. The access map for a Buyer in an SAP S/4 HANA environment may look like below:

The user who performs Buyer role gets access to front end Fiori apps. The associated backend application roles need to be assigned in the S/4 HANA system to this user ID. As he may also need access to reporting/factsheet apps, he will require access to specific tables and views in the HANA database. The same user ID needs access to relevant roles in Fiori, core application and HANA database at the same time for the access to work seamlessly.

 With the S/4 HANA transformation, the existing GRC needs to be upgraded to 10.1 version and following needs to be considered:

1. New systems namely Gateway (hosts Fiori) and HANA Database/s needs to be added as a managed system in GRC
2. Configuration to add these systems in MSMP/BRF+ workflows to enable auto role provisioning
3. Ruleset to be considered for upgrade with new Tcodes and Authorization objects
4. Roles re-design to accommodate changes to Business processes owing to change in S/4 tcode and table structures

One of the key design decisions when choosing to migrate to S/4 HANA, is whether to keep the existing role design and incorporate the necessary Fiori content or start again – thereby creating a new set of roles. Whichever path is chosen, there will be a unique set of advantages and disadvantages to be considered.

Keeping the existing role design may be advantageous if a lot of effort has been invested in ensuring roles are audit compliant and risk free. However, this will require obsolete transactions to be identified and replaced and extensive analysis to be performed to map in the service authorisations required to use Fiori. Start from scratch means Fiori Catalogs can be used to pull through the authorisations required for each app to work.

This will save effort but will require familiarity with the Fiori launchpad designer to customise Catalogs – and the new roles will need to be reassessed to ensure that they are free of Segregation of Duties risks.

S/4 HANA emphasizes simplicity by introducing simple data model, consolidated business processes and straightforward architecture.

While the end goal is to achieve simplification, better user experience and increased performance, the “Road to S/4 HANA” analysis should lay clear emphasis on existing SAP landscape, past investments on security design and GRC systems, customizations and Z tcodes, home-grown applications, integration points etc. The plan for migration should be a well though process and decision than a simple upgrade or a “lift & shift”.