Take care of data before SAP S/4HANA migration

An SAP S/4HANA migration is a complex undertaking that involves many moving parts, including deployment choice and data migration strategy.

Data security is one aspect of an SAP S/4HANA migration that should not be overlooked or taken lightly. Data is often described as the "crown jewels" of any ERP system, and it should receive appropriate attention as organizations plan to move from legacy SAP systems to S/4HANA, according to Rajesh Rengarethinam, vice president of engineering at Appsian.

In the second part of this two-part series examining ERP data security issues, Rengarethinam discusses some of the data security issues involved in an SAP S/4HANA migration.

Dallas-based Appsian provides ERP security services primarily for SAP and Oracle PeopleSoft systems, including access control, compliance and audit, and threat protection.

What are some data security issues that organizations need to think about as they plan an SAP S/4HANA migration?

Rajesh Rengarethinam

Rajesh Rengarethinam: The first thing people need to decide is the deployment model: on premises, private cloud, public cloud or a hybrid approach. Once that is done, the second step is to see what kind of data needs to be available for different user types. That's where the contextual attributes or access control play a major role. If you look at the different user types coming in, they could be from different organizations or within the same organization, and they could be from user types such as people who want to look at the vendor information or customer information, contractual information. Depending on all those things, and where they are coming in and what time of day they need to access the data, determines the kind of controls you set and data exposure that you want them to have, particularly if it's in the cloud.

Does an SAP S/4HANA migration give organizations an opportunity to review their data and processes?

Rengarethinam: Yes, the migration is a checkpoint to see how much data or business processes that they have in their systems actually make sense. Generally, the legacy ERP systems were done way back, but now as the practices evolve, there are some practices that are not in step with what the business is actually doing. For the migration, you have to define each of those business practices so business owners can make sure that only the right practices are being migrated. Whatever is out of step with what the business is doing can all be rejected or made obsolete. The same thing applies to the data itself. From a master data point of view or from a transactional data point of view, the legacy ERP has a lot of information that S/4HANA doesn't even need because it simplifies the data model so much in financial processes and the material management processes. All that redundant data that was in the ERP system can now be trimmed down, and it also makes the processes run more efficiently. Also, the amount of data that you now have to migrate becomes considerably less. The migration forces people to link the data and the processes so that only the ones that are needed get migrated to the S/4HANA system.

So there's some pain with the complexity of the migration, but there will be gain with cleaned up data and better data security?

Rengarethinam: S/4HANA on its own has simplified the data model so much that there's less redundancy and people see only the data that they need to see through the views that they have. In the SAP ECC Materials Management [MM] screen, there's a lot of data there and a lot may not be needed for every user. There are rules in MM where you define which views the user needs to access, but in S/4HANA, the apps are more user-focused and personas are much more fine-tuned for what they expose to the user. You can define what kind of data you want this particular user to view without making the user navigate through the myriad of tabs and views that are available for the transaction. This definitely enhances the user experience, and the business owner has more control over who's accessing the data and what data is stored in the system.

What are the data security concerns in an S/4HANA deployment on the cloud, which opens up the 'crown jewels' data to the mobile world?

Rengarethinam: There are two aspects to this. One, now that the data is in the cloud, it's no longer within your firewall and more access points are open. Now there are user types coming in from external sources, and you have to establish these personas within the access points so that you know exactly what kind of data is being exposed to the users that are coming in. That determines the way you define the roles and also the way in which data is taken from the application and delivered to users. This means you have to have some kind of protection on the [user interface] layer in terms of defining how you want the data to be viewed by different personas. On the database layer level -- the way the data is going to be stored -- you have to make sure that any sensitive data is either encrypted or masked and exposed only to the right user at the right time. This makes the security a little bit trickier to define, but on the other hand, more people are now able to access data that was previously contained. You just have to define multiple roles in order to make sure that the exposure is restricted to the bare minimum.

What steps should organizations take to ensure data security in an S/4HANA migration?

Rengarethinam: You have to make sure that you know the type of data that you want to expose and migrate to the S/4HANA system. That will define the deployment model -- and choosing the right deployment model is key. After you've done that, make sure that all the business processes are reviewed and that only the most relevant business processes are being migrated. From a data retention point of view, look at all the master data and transaction data within the system and trim down the redundant data structures and any data that's being repeated in multiple tables and data structures so that you only migrate the most essential data. Finally, make sure that people have the right view to the data, either at the database level, the application level, and the UI level, and define those security levels appropriately at those three levels so people have the right access to the right data at the right time.