Lukardi > Case study > Retail industry > Reorganization of SAP and SoD powers
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,
The implemented model of the concept functions smoothly in the departments that took part in the project. After Finance, it was time for a similar project in the HR Department. We are currently implementing a project to reorganize authority and SoD in the Purchasing area. We are pleased with the client's confidence and the implementation of best practices in more departments and SAP systems."
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