A practical look at roles and testing, and why SAP authorization is an exciting entry point for career starters. A guest article by Carsten Rieck. Reading time approx. 8 to 10 minutes.
SAP systems control central business processes in many companies – from procurement and production through to accounting and sales. Sensitive data is processed in these systems and business-critical transactions are carried out. This makes the following question all the more important:
Who is actually allowed to do what in the system?
At first glance, this question seems simple, but in practice it is one of the central questions in every SAP project and in the ongoing operation of an SAP system. This is exactly where SAP Security and SAP Authorizations come into play. Both terms are often mixed up or even used interchangeably in everyday life, although they have different focal points. While SAP Security is more concerned with the technical security of systems, SAP Authorizations deal with which users are actually allowed to execute which transactions, apps and functions in the system.
Authorizations play a central role especially in SAP projects, in particular in S/4HANA transformations. When moving from SAP ERP (R/3 or ECC) to S/4HANA, not only technical foundations change, but also structures and user interfaces. New data models, simplified table structures and, above all, the use of SAP Fiori with role-based apps mean that existing authorization concepts cannot simply be adopted 1:1. Roles must be adjusted, in some cases newly created, and more strongly aligned with business processes.
The topic of authorizations is not only relevant in projects, but accompanies an SAP system throughout its entire lifecycle: from implementation through operation to governance, compliance and automation topics.
In practice, it also becomes clear: processes can be implemented perfectly from both a business and technical perspective; if users ultimately do not have the appropriate authorizations, tests do not work, business processes come to a standstill and, in the worst case, the go-live of a project is jeopardized. Authorizations are therefore not a purely IT or security topic, but an important component of every SAP project and every transformation.
At the same time, the authorization environment is a very exciting field of activity for career starters. Hardly any other area offers such deep insights into business processes, organizational structures and the collaboration between business departments, IT and project management. Anyone working in SAP authorizations not only learns technology, but very quickly understands how a company and its processes really function behind the scenes.
The difference between SAP Security and SAP Authorization
In the SAP environment, the terms SAP Security and SAP Authorization (=authorizations) are often mentioned together or even used interchangeably in everyday life. In fact, however, they describe two different areas with different tasks and focal points.
Put simply, the difference can be summarized as follows:
- SAP Security deals with the technical security of systems.
- SAP Authorization deals with which users are allowed to execute which functions and business processes in the system.
SAP Security primarily includes technical and system-related topics. These include, for example, securing interfaces, applying security patches, system hardening, user types, emergency users (e.g. firefighter users), logging, monitoring, as well as securing RFC connections and background users. The goal of SAP Security is to protect the system itself from unauthorized access or technical attacks and to minimize security risks at system level.
SAP Authorization, on the other hand, is much closer to a company’s business processes. Here, the focus is on questions such as:
- Is a user allowed to create purchase orders and post invoices?
- Is a user allowed to change deliveries or only display them?
- Which Fiori apps is a user allowed to use?
- Is a user allowed to perform certain sensitive activities that are critical from a compliance perspective?
These authorizations are assigned in SAP in the form of roles that contain transactions, Fiori catalogs, organizational values (e.g. company code or plant) and other authorization objects. The aim is that each user receives exactly the authorizations they need for their daily work. No more and no less. This principle is often referred to as the “need-to-know” or “need-to-do” principle.
In practice, SAP Security and SAP Authorization work closely together. While SAP Security technically secures the system, the authorization concept ensures that users within the system can only execute functions that correspond to their role in the company. Both areas are therefore central building blocks for a secure and at the same time operational SAP system.
Especially in S/4HANA projects, it is important to distinguish between these two areas, as they are often the responsibility of different teams but must be closely coordinated within the project; particularly in test phases, in the handling of emergency users or in the preparation of the go-live.
Why authorizations are so important in projects
In SAP projects – especially in S/4HANA implementations or system conversions – authorizations play a much greater role than many expect at the beginning of a project. While at the start of a project the focus is often on processes, data migration or technical topics, the topic of authorizations is often only perceived as critical in later project phases; usually when the test phases begin. The reason for this is that, as part of a transformation, not only does the system usually change technically, but processes are also adjusted or redesigned.
At the latest during the test phases, especially in the User Acceptance Test (UAT), the topic of authorizations becomes very visible. In this phase, business departments test the business processes in the system. In order to test their processes realistically, they need suitable roles with the corresponding authorizations. If these authorizations are not available or are only partially available, processes cannot be fully tested. This leads to delays, additional coordination effort and, in the worst case, risks to the planned go-live date.
A typical scenario from project practice looks like this:
At the beginning of the test phase, testing is carried out with very extensive authorizations. When testing later takes place with the actual roles, authorization errors suddenly occur. This creates significant time pressure shortly before go-live, because roles have to be adjusted at short notice and tested again.
In addition to pure functionality, compliance and audit requirements also play an important role.
Pragmatic handling of authorizations in testing
In many SAP projects, a typical dilemma arises in the area of authorizations:
On the one hand, business departments need to start testing as early as possible so that business processes can be validated and errors identified in good time. On the other hand, the role and authorization concept is often not yet fully developed at this point, as many detailed requirements only become visible during the course of testing.
In practice, this often leads to two unfavorable extremes:
Either testing is carried out with very extensive authorizations so that business departments can work without interruption. In this case, however, authorization problems are only identified very late, when testing is carried out with the actual roles. Or tests are repeatedly blocked due to missing authorizations, which leads to frustration in the business departments and delays in the project.
In practice, a pragmatic approach has proven effective:
Business departments test their processes as early as possible with the intended roles so that realistic results are achieved. At the same time, so-called reference users or users with extended authorizations are used for selected users. These serve to prevent tests from being completely blocked if individual authorizations are still missing in the role model.
At the same time, authorization errors are systematically logged and evaluated. Whenever a user cannot perform an action due to missing authorizations, this is analyzed and documented. On this basis, roles can be adjusted in a targeted manner and gradually improved. After each test cycle, the collected findings are incorporated into the role and authorization concept.
Tests provide insights into missing authorizations, roles are adjusted, and in the next test cycle they are checked again. Step by step, a role model develops that both works from a business perspective and meets compliance requirements.
What is particularly important here is the organizational integration into the project. Authorizations should not be handled in isolation by a single team, but understood as part of the test strategy, process definition and go-live preparation. In successful projects, business departments, test management, project management and the authorization team therefore work closely together.
This pragmatic approach helps to resolve the dilemma between not yet fully developed roles and early test phases, while at the same time ensuring that authorizations are not only addressed shortly before go-live, but are continuously considered and improved throughout the entire course of the project.
Why SAP Authorization is a good entry point into the SAP world
For many career starters, the question arises as to which area they should enter in the SAP world. In addition to classic modules such as FI, MM or SD, the area of SAP Authorization and SAP Security is initially less visible for many, but offers a very good and versatile entry point into the SAP project world.
A major advantage in the authorization environment is that you very quickly come into contact with different areas of a company. You operate here at the interface between business departments, IT, SAP Basis, audit/revision and project management.
Another advantage is that authorizations play a role in almost every SAP project – regardless of whether it is a new implementation, a system conversion, a rollout or an S/4HANA transformation. Career starters therefore have the opportunity to get involved in projects early on, support test phases, analyze roles and contribute to the implementation of authorization concepts. In doing so, you not only work technically in the system, but also coordinate closely with business departments and learn to understand requirements and translate them into roles and authorizations.
For career starters, the authorization environment is therefore a good combination of:
- technical and process understanding,
- project work,
- communication with various stakeholders,
- as well as topics relating to governance, risk and compliance.
Anyone working in this environment not only learns how SAP works technically, but above all how business processes, organization and IT interact within a company.
Many experienced SAP experts started their careers in the authorization environment.
How to get started – and what to expect in practice?
Entry often takes place via junior positions, trainee programs or initial practical experience as a working student. Technical prior knowledge is helpful, but not essential. More important is a basic understanding of processes and the willingness to familiarize yourself with new topics.
In day-to-day work, you typically support the analysis of authorization errors, the creation and maintenance of roles (e.g. in PFCG), in test phases and in coordination with business departments. Especially in projects, the work is closely linked to tests and go-live preparations.
The environment is varied, but also demanding: many topics require coordination, and especially during project phases things can become hectic. At the same time, this offers rapid learning progress and deep insights into business processes.
In the long term, this opens up a wide range of development opportunities; for example towards SAP Security, Identity & Access Management (IAM) or project and process roles.
About the author
Carsten Rieck has been working in the SAP environment for many years, focusing on SAP Authorizations, SAP Security and Governance, particularly in S/4HANA transformation projects.
In various projects, he has worked at the interface between business departments, IT and project management and has, among other things, developed authorization concepts, role models as well as governance and recertification processes and implemented them in projects.
Today, his focus is primarily on the organizational and project-related implementation of authorization and security topics in S/4HANA transformations – particularly in test phases, during go-live preparation and in governance and compliance topics.