When nothing else helps: Restart

The findings are crucial when redesigning an authorization concept. These are divided into different risk levels. In turn, it is also relevant how quickly the risks can be eliminated.

An example of a defect is system parameters that do not have the correct setting. The RSPARAM report shows the system parameters. Settings such as the general system logging can be displayed here, which must generally be activated, as otherwise laws are violated (high risk, but can be rectified promptly).

Settings relating to password length and complexity or the control of SAP standard users can also be checked there and corrected if necessary.

Another example is the assigned authorizations. Here, too, we may find critical authorizations that are associated with a high risk. For example, the authorization object S_SCD0 with the activity 06.

This authorization object can be used to delete change documents (erasure ban). This would violate HGB in a financially relevant system.

What is really critical?

The risk assessment of the assigned authorizations depends on many factors. One factor is, of course, legally critical authorizations as shown in the example above.

These authorization issues are relatively easy to assign to a risk level. However, there are also risks that are company-dependent. Here, it must be analyzed in advance exactly where risk-relevant company data exists.

For example, a bank that conducts its banking business outside of SAP and only routes its internal cash flows via SAP does not consider the internal financial system to be as critical. Another example would be a chemical company that stores its recipes in SAP.

This company would consider this to be very critical and therefore classify it as a very high risk. Risks must therefore be defined on a company-specific basis.

Company-specific risk catalog

The effort required to rectify identified authorization problems can be very high under certain circumstances. This is usually related to the authorization structure.

It becomes difficult, for example, if authorization roles have been set up too coarsely or too granularly. Inconsistencies also occur if a defined authorization concept is not consistently adhered to.

A detailed preliminary analysis by experts is required to determine whether deficiencies and inconsistencies in the existing authorization system can be corrected or whether the system is better set up from scratch.

The question then is: Are the time and costs for a correction higher than for a redesign of the system?

Steps of the redesign

A redesign requires a high level of commitment from employees. In particular, the authorization administrators and the specialist department are heavily involved. This means a high additional workload for employees in addition to their day-to-day business.

External companies are also often brought in, which results in additional costs for such a project. If there is a need to redesign the authorization concept, the costs should be as low as possible.

To do this, we look at how the redesign can be implemented, what risks are involved and which SAP on-board tools can be used. Specialized software can supplement the SAP on-board tools in many places or fully automate some process steps.

This can further reduce the effort involved. The possible use of such software should be considered.

Step 1:

As part of an authorization redesign, you should first take a close look at the existing documentation for any existing authorization concept and supplement it if necessary.

This documentation should also define naming conventions, user administration (e.g. maternity leave) and the creation of roles via the profile generator, for example.

The major challenge when creating an authorization concept is to weigh up the various aspects: On the one hand, all important points should be included. On the other hand, points that change frequently should not be written down in too much detail.

Step 2:

The next step is to carry out an authorization check in the systems. Unfortunately, this is only possible to a very limited extent using the SAP on-board tools. This is due to technical restrictions and standard reports containing errors.

Step 3:

This is followed by the implementation phase, in which three questions are decisive: WHAT does a user have to do in the SAP system, HOW does he have to do it and WHERE does he have to do it?

The "what" is usually mapped via the transaction. The "how" is regulated via the corresponding field values (e.g. "Read" or "Change" activities).

The "where" is controlled via so-called organizational units. This means the company code in which postings are to be made. The question of what a user is allowed to do, i.e. which transaction they need, can be answered with a work center analysis.

This means that you sit down with each employee of the company and go through individual transactions that the user requires and make a note of them.

This is a very time-consuming process. To speed up this process, you can make use of the information available in the system. There are three main methods for this:

1. via transaction ST03N. At this point, the system records which transaction has been called up by which user. In most cases, the information is available from the last three months in the SAP system.

Tip: The time frame can be extended to around 14 months. This way, transactions are also taken into account for the annual financial statements.

2. the favorites created by the user can also be used for further analysis. Rarely used Z* or Y* transactions that are not shown in the ST03 analysis are often stored here. The favorites can be read centrally via a table. Table: SMEN_BUFFC

3. transactions that a user had in their old roles (table AGR_1251 and table AGR_USERS). This information can also be used. However, it should be noted that the old roles often contain too many transactions.

Once this information about all users has been determined and analyzed from the system, it must be filtered and evaluated. The risk here is that information is either forgotten or misinterpreted.

The use of an additional software product can be very helpful at this point. Once this has been carried out for all users and departments, you can start to structure the corresponding authorization roles according to subtasks of the departments and add the corresponding transactions.

Care must be taken to ensure that the roles are subsequently assigned to responsible persons (data owners). The authorization roles should therefore be as module-independent as possible.

One of the biggest challenges here is to determine which tasks the individual departments have to perform outside their area of responsibility.

The area of responsibility here refers to the SAP module. For example, finance employees work in both a COModule and an HCM module.

After this project step, all roles were created in relation to the corresponding specialist areas with the transactions. In the next step, the roles created must now be defined.

The how and where questions must be clarified. Here, too, the specialist area is very closely involved and there are various options for defining the roles created.

One option is to draw on the experience of the specialist department employees and define the roles accordingly. However, as it often becomes very technical when defining the roles, you very quickly reach your limits here.

The next option is to use trace information (ST01) that is generated in the SAP system. After activation, the results can be read out and used for role specification. However, this option is considered to be very time-consuming.

As a great deal of experience is required to define the roles and the standard tools are only of limited help, experience shows that in most cases the roles are defined with too many rights.

The area of controlling poses a particular challenge. Companies usually have several hundred cost centres that need to be separated into organizational roles.

Risk: roles with excessive rights

The result after manual role definition is usually still incomplete and imprecise. An important point when defining roles: Under no circumstances should SU24 maintenance be omitted when defining the field values.

SU24 is used to set the default values for the profile generator (PFCG). A properly maintained SU24 considerably simplifies and accelerates the subsequent administration of authorization roles.

This also increases the quality of the authorization roles. This step should therefore be considered in any case. However, the manual effort involved is so high that special software should be used.

Quality and safety through SU24 care

As a final step before going live, a very intensive test of the roles must be carried out. The entire test scenario should be planned in detail and monitored by the project members.

To this end, test protocols must be created in advance to guide the employee and allow the results to be recorded. The test results must be implemented promptly by the authorization administration.

Once the initial test results have been corrected, further tests are carried out. This process must be carried out until there are no more authorization errors.

A negative test must also be carried out. This tests whether users can do something that they should not actually do. For example, booking in a different company code.

This negative test is often not carried out. There is therefore a risk that roles with too many authorizations are not recognised and not adjusted.

Once the very time-consuming and tedious test scenario has been completed, the roles can now be transported to the production system and assigned to the individual users.

Before a new authorization concept goes live, detailed planning must also be available here. It is not recommended to convert all users at the same time.

It is recommended to convert one or two users from each area. This allows you to see whether not all steps were taken into account in the upstream test and whether this could lead to authorization problems. A so-called "fallback scenario" (the user gets their old role back) must be planned or mapped using special software.

Three to four months after project completion, the old authorization roles can be deleted from the system.

The prerequisite is, of course, that the new roles are functional. Finally, it should be noted that the processes defined in advance in the concept must be adhered to. This is the only way to ensure that the new authorization concept, which has now been painstakingly developed, is retained.

Conclusion: If there are serious deficiencies in an SAP authorization concept, a redesign is often the most efficient solution. However, the redesign is time-consuming and risky.

Here, special software can help to minimize effort and risks. This results in both higher quality and lower costs. Specialist software can also be used to control and support day-to-day business.

Tip 1

There are cases in which an authorization concept may need to be completely redesigned because a "quick tidy-up" only improves the situation in the short term.

Tip 2

If the level of detail in authorization concepts is too high, a great deal of maintenance work is required. Software solutions can help with this.

Tip 3

Both the maintenance of authorization concepts and auditing can be mapped using special software.

Tip 4

Regularly create a mass download of the changed roles. This allows you to access an older version of the roles at any time. It happens from time to time that time-consuming role changes are overwritten in the heat of the moment.

Tip 5

There is a risk that employees will be severely impaired in their daily work due to a lack of authorizations.

Tip 6

When using appropriate software, it is important to ensure that it is based on standard SAP functions, so that companies do not become dependent on special solutions that make manual maintenance of authorizations impossible.