Works after all! Agile Authorization Management in S/4HANA

But S/4HANA authorization projects are subject to strong dynamics due to often initially unclear overall strategy and changing requirements. So how do you deal with this? Roozbeh Noori-Amoli, Deputy Head SAP Consulting at SAST SOLUTIONS, explains.

The topic here is the correct approach to authorization projects, starting with initial considerations that are made before setting up a project and ending with the identification of challenges and stumbling blocks in order to derive lessons learned. So, which elements play a fundamental role? In addition to the project itself, these are technical factors such as the underlying system architecture, tools used, but also organizational and compliance requirements. These provide an initial framework and significantly determine the choice of project approach and procedure as well as the authorization concept. Their interrelationships are often closely causally intertwined, and the human factor must not be missing from any consideration.

Before the project

The three key initial questions before the project begins are: which project approach, which project procedure, which authorization concept? First, the project approach: As with S/4HANA migration projects, a distinction can be made in authorization migration projects between the two extremes of greenfield and brownfield. Greenfield then means basically setting up everything from scratch, while brownfield means transferring the ERP world. This choice also depends on budget and resources, but often one starts with a greenfield approach, fills the gaps with proven processes from the old world and then speaks of the bluefield approach, also called selective data approach. Transformation here means converting the old roles and integrating new elements. This is often the happy medium, but still not always the optimal solution for every scenario. A concrete example: Sometimes a greenfield approach works with the adoption of proven processes, but a new definition of BPDs (Business Process Descriptions) for each process. Traces from the legacy systems are then used and transferred to fill in the information gaps, and this is accompanied by departmental workshops and tests to cover the gray areas. 

Classic vs. agile project management

Once this issue has been clarified, the groundbreaking decision must be made between a classic and agile project approach. Here, factors such as the actual business needs, project goals and security requirements, budget, time and personnel resources, but also organizational structures and processes such as the number of SAP users or the type and architecture of the system are important. In theory, this decision is often made dependent on the so-called magic triangle: If the project scope is fixed, but costs and time are variable, this indicates classic project management. However, if costs and time are fixed and the scope is variable, then an agile approach is recommended. Ultimately, it can be stated: If the mindset for it exists or can be built up, agile project management makes perfect sense. 

Authorization Concepts

The next consideration, the choice of authorization concept, basically boils down to the conflicting goals of minimizing risks and assigning authorizations versus standardizing processes, increasing transparency and minimizing administrative effort. Due to the large number of concepts and their varying suitability for specific scenarios, only two examples are given here to illustrate their diversity: In the case of an international organization with many identical parts of the company and recurring processes, the template role approach with derivations according to organizational units or the menu/value role concept work. In contrast, the 1 transaction - 1 role concept is recommended for a high security requirement and the desire for precise assignment of authorizations, a low number of transactions per user, and a system with few but different processes.

Challenges and Learnings

A successful S/4HANA authorization project is possible with appropriate expertise and careful planning - it is essential to determine the approach and stakeholder needs in advance. It is then important to schedule time for testing right from the start and to ensure detailed coordination between the test team, the training management team and the authorization team. It is helpful to have tool support, such as SAST SUITE, to ensure process testing.

Tackling S/4HANA authorization management in an agile and holistic way is made considerably easier by relying on partners like SAST SOLUTIONS and their SAST SUITE. With such a tool concept, responsible parties save both time and money by significantly reducing manual work. This is because the software improves analysis results, makes a recommendation as to whether a migration or a redesign of authorization roles makes more sense, and directly provides suggested values. In addition, obsolete or exchanged transactions are detected and suitable FIORI apps are identified.

From an organizational point of view, the human factor is particularly important to consider, as are the challenges posed by the switch to S/4HANA. Hardly anyone is eager for change and this transformation means: processes, transactions and the user experience change. A clean project policy and communication, so that end users feel picked up and accept innovations, is therefore crucial for project success. The strong dynamics of S/4HANA authorization projects due to frequently changing requirements are ideally met with an agile project management approach that is precisely tailored to the complexity of the challenges.

Dynamic, responsive, flexible: agile project management

Agile project management has great advantages here: Integration, regression and authorization tests, for example, are not considered separately, but are carried out in parallel. It offers fast response options to changed requirements and a continuous optimization process. Finally, it is important to plan for sufficient time and resources; the topic cannot simply be implemented alongside day-to-day business. The entire topic must be tackled together with the specialist departments at an early stage. After all, it is necessary to make cross-departmental decisions regarding role content and to create customer-specific catalogs and groups in order to avoid having to resort to the overloaded SAP standard.

Important lessons learned: away from the authorization team and towards one person responsible in each department. It makes sense to have tailored tool support; standard templates are needed for default roles for testing, as well as clean and SoD-free roles. Authorizations must not only be tested for functionality, but negative tests must also take place. The day-to-day business should absolutely remain guaranteed by a safe-go-live approach, then there is hardly anything standing in the way of a successful agile authorization project.