RETAIL INDUSTRY

Reorganization of SAP and SoD powers

SAP Security

RETAIL INDUSTRY

Customer Profile

Retail company

The leader of the convenience store chain in Poland, offering quick shopping close to home. With a wide assortment, innovative solutions and services, the brand responds to customers' daily needs, combining convenience with modernity.

Challenges

The client faced several SAP entitlement management issues including:

Lack of control over the content of roles (roles "swelled", i.e. new transactions were constantly assigned, no owner, no cyclical verification of roles)

A large number of SoD conflicts, and thus a high level of danger, i.e., the possibility of doing damage to the company through vested powers well beyond daily work duties

Analysis

During the SoD audit performed with the SAST Authorization Management tool, we found that on the production system (S4) the number of conflicts was far too high than the organization's risk tolerance threshold. Given the agile nature of the project and the close collaboration with business users, we focused on the quality of SAP authorization reorganization rather than the speed of jumping to the next stages of the project and production takeoff. After more than a year, we finished the project in all areas of Finance or around Finance, including: Accounting, Controlling, Business Control, and Treasury.

The key stage was certainly the moment when the new Entitlement Concept was created and the processes and so-called "ownership" (eng. Ownership) of the new SAP roles were implemented. This was a crucial stage, as it should be taken into account that in many companies the responsibility for the content of SAP roles (transactions, reports, tables, activity values) is transferred from Business to IT. We are aware that this should not be the case, right? That's why seeing the client's enthusiasm on the Business side to learn about the most important issues and best practices in the division and management of privileges certainly gave the entire project team wings.

The project in Finance was successfully completed,

Bernadeta Szwarc

Project Manager / Lukardi S.A.

Key information about the project

Project stages

Analysis

Concept and configuration

Testing phase

Manufacturing startup

Implementation

Stage 1: Analysis

The project to reorganize the authority and SoD is a conceptual project. It is necessary to think properly about what we want to achieve in the project, which risks are acceptable and which ones we need to get rid of. Therefore, phase one - the ANALYSIS PHASE - is the most important phase of the project. You should focus on what you see in the SAP system (read: current status of roles vs. transactions used, reports, tables displayed and edited) and start discussions at which representatives from the business side and SAP administrators from the technical side will be present. Each participant should come out of such a workshop with basic SAP security knowledge and specific tasks.

To verify "AS IS" (current state) we used the SAST Authorization Management tool, which allows, among other things:

report of transactions and reports used during the time period of interest

transaction consumption report for the role (answers questions: what we definitely don't need to include in the role)

report of currently assigned roles to users (just like SUIM, but there is more design-useful data)

SoD report on specific users/groups with descriptions of risks

The above reports are our starting point in any project. Let's find out what the situation is, WHO has access to WHAT and WHEN they used (critical) permissions.

Stage 2: Concept and configuration

In the next phases of the project once we "know what we have", what we want in the project and what we should not have access to on the system in SAP, we can focus on conceptual and configuration work. After a period of meetings, analysis, joint workshops, negotiations ("I don't use these transactions, but it might come in handy", "I don't suppose you'll take away the permissions I need for my work?") this is often already pure pleasure.

Stage 3: Testing

For the testing phase, a suitable testing environment is an important issue, i.e., it is worth thinking about a fresh copy of the production system, so that testing representatives from the business side can fully (or at least very roughly) test the new roles before transferring them to the production system.

Stage 4: Production launch

The final phase is the handover and joint discussion (very important) of the created Entitlement Concept. Make sure that the convention and nomenclature are clear to business and technical users, and that responsibility for managing the concept is clearly separated and assigned. We organize the production launch in two stages, first a pilot, that is, assigning new permissions to some users. Hypercare takes about two weeks. After a successful pilot, the rest of the users can start working with the new permissions. With this model, we were able to avoid stalling or disrupting a critical business process during the last phase of the project.

Effects of the project

Workshops and joint tests with business users enabled knowledge transfer in both directions (Business - IT) and started joint activities for the future on SAP security issues

Implemented new procedures to seal SAP entitlement management processes

Implemented the Entitlement Concept as the document "that lives" i.e. is the main reference for Business and IT when managing SAP entitlements

Minimized access to critical authorizations in the FI area

SoD conflicts minimized

Product

Before the project

After the project

Departmental Entitlement Concepts

0

5

Owners of departmental/area SAP roles

0

21

Max. number of transactions in roles

750

50

Number of SoD % conflicts statistically in participating departments

100%

30%*

*eliminated 70% SoD conflicts.

Summary

In addition to the above-mentioned results, it was certainly a big improvement to "reign in" SAP roles and identify owners responsible for new roles. Sometimes to start reorganization efforts we are deterred by the build-up of clutter and forget the simplest solutions. The simplest solution to reorganizing SAP roles: give access to the minimum required.  

On the other hand, we noticed a kind of psychological comfort for Keyusers who witnessed the revocation of critical privileges from people outside the financial area. In addition to the corrective action of revoking privileges, we implemented a preventive control, that is, we secured critical transactions and tables in the SoD matrix, which, as a rule, in the future would not allow an administrator to add defined critical privileges to roles outside the financial area. 
 

Your Needs
Our Support
Lets Talk!

Your needs, our support.
Lets Talk!

Your needs, our support. Let's talk