How to reduce the business impact of a role redesign project
In this article, we will explore technical and practical ways to reduce the impact of an SAP role redesign project on your business.
Table of Contents
What is a role redesign?
A Role redesign, also sometimes referred to as security redesign or role remediation, refers to significant changes to SAP roles that impact the authorizations of SAP users.
What triggers a role remediation project?
There are various reasons why organizations decide to embark on a role redesign project, including:
- Changes in the organizational structure,
- Use of SAP standard roles,
- System upgrades,
- Migrations to SAP S/4HANA,
- Over-authorized users,
- Segregation of Duty (SoD) conflicts,
- Legal requirements,
- The desire to simplify role administration.
Often it is a combination of some of the above factors, which trigger the need for a complete role redesign project.
On the plus side, a properly executed role redesign project often provides multiple benefits, including:
- Simplified role administration,
- Remediation of SoD conflicts
- Properly authorized users
Why a security redesign impacts your business?
The main reason why some organizations shy away from, or at least, delay role redesign projects is that such projects can be time-consuming and expensive. That is true not only for the SAP security teams but also for business users. Traditional role redesign projects heavily involve business users and analysts to help with the role design as well as testing. By involving business users, you distract them from their day-to-day job, which takes a toll on their productivity.
Additionally, the business is likely going to take a second hit when it is time to go live with the new roles. Any gaps or missing authorizations that testers missed or overlooked during acceptance testing will disrupt the workflow of business users, leading to more lost productivity and work for role administrators.
Many organizations have either accepted the cost of a role redesign and the impact on its business, or they have delayed such projects and decided to accept the risk that comes with incorrectly authorized users.
The good news is, there is a middle ground. In other words, you can successfully execute a role redesign project with only minimal or no impact on your business. Continue reading to learn how!
How to reduce the business impact of a role redesign project
Traditionally, roles in SAP contain the following authorizations data:
- Organizational fields with its organizational values (i.e., Company code, Purchasing organization, etc.)
- Authorization Objects (i.e., transactions VA01, function modules, etc. )
- Authorization fields with is values (i.e., Activity 03 for Display)
As a result, a role could authorize a user to have display access (Activity 03) to transaction VA03 for company code 1000. Of course, this is a simplified view on a role design, but it helps to illustrate the concept.
When your organization tasks you with redesigning roles, business analysts often provide answers to such questions as:
- What transactions does user XYZ need access to?
- What authorizations does the user need? Display or change?
- What company code is the user booking to?
The answers to these and other questions often build the base of your role design concept. The problem is that obtaining that information for a large group of users is time-consuming and error-prone. Additionally, business users tend to err on the side of more authorizations when providing input to business analysts.
What many security admins don’t or only partially realize is that the answers to all of the above questions are available in the database of your SAP system. You just have to know where to look. In other words, by retrieving the required information directly from SAP, you minimize the disruption caused by designing new roles on your business users.
Of course, once you have built the new roles or made changes to existing ones, you have to test them. So-called user acceptance testing (UAT) is another time-consuming phase of traditional role redesign projects that has the potential to negatively impact the productivity of your business users.
Gathering authorization data
Statistical trace data – ST03N
One treasure trove of information related to transaction execution activity is the Workload Monitor. You can get to it via transaction ST03N. Among many other things, it shows you the users transaction execution activity. Using that information, you can analyze what transactions your users executed over the past few months. The exact timeframe depends on your system configuration. By default, your SAP system retains three month’s worth of usage data, unless you changed the configuration.
We generally recommend accumulating between three to six month’s worth of usage data to get a good overview of what transactions your users use.
By the way, if you have SAP Access Control, you can get the same information from GRC’s Action Usage Report (table GRACACTUSAGE).
The next step is to optimize your roles by merging SU24 proposals. You have maintained your SU24, right? If not, that is probably something you should do next. By bringing in SU24 proposals, you have taken the first step to populate your roles with authorization fields and values. Unfortunately, not all the objects you need in your roles are available via SU24. So, the next step is to find out what fields and values you need to properly authorize your users, including organizational values.
Authorization fields and values
ST03N does not include authorization objects below the TCODE level. As a result, we have to leverage other trace sources, such as ST01, to get an idea of what authorization fields and values are required for the roles we are trying to build. Additionally, you will have to determine the proper organizational fields and values for each user. For the latter, you can retrieve the necessary information from a variety of tables, based on the type of data you need.
For instance, if you are building a role to authorize users to change purchasing documents, you can look at table EKKO for information about what users made changes to purchasing documents and what the associated org fields were.
Based on that information, you can fine-tune your roles and make sure your users are properly authorized based on the relevant organizational values.
How to test role changes in production
Once you have built new roles as part of your redesign project you have to test them. Unfortunately, SAP offers very limited tools to automate that process beyond individual trace files. But analyzing those traces for hundreds or thousands of users without proper reporting and gap analysis is not feasible. Instead, you can leverage the so-called Productive Test Simulation (PTS), which is part of the Xiting Authorizations Management Suite (XAMS).
Using this technology, role administrators can test new roles in a production environment without negatively affecting end-users. To accomplish that, the XAMS leverages standard SAP reference users.
Let’s say you wanted to test the new roles you created for user Joe. Via the XAMS, in production, you would create a reference user, assign the new roles to that reference user and then assign the reference user to Joe.
Why use a reference user you may ask? The answer is simple – anytime the SAP kernel performs an authority check, it does it against the reference user first – if there is a reference user assigned. If that authority check fails, then the SAP kernel performs the same authority check against the dialog user. If that authority check succeeds, SAP logs a return code 0. With the help of the XAMS, you can analyze those return codes and quickly export roles containing the missing authorizations. Using the exported roles, you can fine-tune your new roles in development and transport the changes up to production.
How to automate role creation and testing
While the above steps surrounding the creation of new roles help you to gather the required information to build proper roles in SAP, they are time-consuming and error-prone. As a result, the steps are impractical if your goal is to build roles for more than a handful of users. The good news is, you don’t have to perform those steps manually! To automate and simplify all the tasks I have described above, you can leverage the power of the Xiting Authorizations Management Suite (XAMS).
Learn how to automate role testing
In a nutshell, the XAMS:
- Streamlines the analysis and processing of trace data,
- Instantly identifies missing SU24 proposals,
- Enables role administrators to build roles based on statistical trace data and via a drag-and-drop interface,
- Automatically enriches the created roles with business data, including the required organizational fields and values,
- Simulates new roles based on user activity in production to identify any missing authorization fields and values. We call that the Productive Test Simulation (PTS),
- Replicate individual roles across organizational units,
- And much more.
To learn more about the XAMS and its powerful features, check out our solution page.
