What does it mean? Do you have a uniform model to manage SAP Security or for each project you have to do it from scratch, wishing that it will be at least similar to the one already done, maybe from others in the past?
Let's discover in this article if the centralized management SAP Security is better or worse. Are there one or multiple orchestra directors?
SAP Security in your company
My idea is that in a company there should be a dedicated team that takes care of SAP security. Clearly the team depends from the company's dimension.
It can be made of one person that partially takes care of managing SAP authorizations and/or more in general the security other than other activities or a proper team of specific resources.
I think that the presence of people trained on the subject inside the company is essential. Sure I'm not expecting to find a guru on the subject in all realities. But at least he has to know the logics.
Delegating anything outside (including the covernance) is in my opinion unthinkable and risky. While it could be correct to outsource the system maintenance, meaning having an AMS SAP Security service.
If the supplier on duty proposes me something, I want to know what it's about in the short term and mainly in the long term. Will I have consequences on the choice made in the future? He's proposing something that solves a certain problematic but maybe it could cause difficulties in the future.
How is it possible to know or be critical (in a constructive way) if you don't know what you're talking about?
The same way I don't consider correct that the security is delegated to the various module functions. For example, the purchasing area and warehouse roles are managed by who takes care, in the IT, of the MM (Material Management) SAP module inside the company.
Why I think it's wrong:
- Delegating everything outside the company, including the model governance, can lead to a loss of know-how in the company on the topic (but how to prepare to an AMS?)
- Also from the supplier point of view this is a problem. I find myself at times explaining trivial concepts, to do anything, because the company lost any tipe of knowledge. This makes everything extremely complex and long to actuate. Including things that should be taken for granted.
- The applicative IT modules must manage the processes of competence and concentrate on their job. They can't also take care of SAP Security too. Sure, they're of great help and have to support the security but not substitute it. Why?
Here are some examples: - It's not their job, we can't ask all the applicative to know the use of the generated profile (PFCG transaction) in every aspect. Sure, anybody could use it. But managing how a model works or not isn't for everyone
- Some conflicts can emerge. What do I mean? Immagine that the IT person of the finance area (FI) creates some roles in his area. These specific roles, of the FI area, could also contain roles from other modules, MM, SD, WM etc.. Sap is an integrated system. What do you expect it to do? Should it confront with each module contact person/colleague to understand how to manage them? What happens is that an sensible authorization object in the MM area also present in the FI roles has to be valued maybe with * (asterisk) nullifying other segregations made by MM roles if assigned to the same user. In SAP authorizations sum up.
- The example above can lead to the creation of custom authorization objects to avoid conflict situations, especially if the above model is active since a long time.
- Every applicative thinks its own way. Do you create a transaction? What naming do we choose? It could differ by area. Just like the type of the transaction itself. In fact there are different methods to creare a transaction that recalls a program or a query
SAP Security for projects
Often a company thinks on the basis of projects, on new activities to carry out. But is it correct to do it for the SAP Security management too? I don't think so.
What do I mean?
During a SAP installation and configuration project in a company (also that was a project, more or less close in time) an authorization concept was defined. Let's not talk about if it was valid or not. Following that new project are born:
- Automatic warehouse management
- Activation of the CO-PA module
- Activation of the treasury
- Introduction of RPA logics
- Updating of the SAP S/4HANA system
- Etc...
These activities are often followed by internal staff but also by suppliers to who (when you remember to do it) you assign the management of authorizations, for that specific project.
I'm referring to that specific moment.
Here, if there isn't a common and shared model (especially with a supplier) there's the risk of creating n authorization models inside the system. One per object.
Sometimes I hear people say: The roles named ZTR* are the ones created during the treasury project. The roles that begin with ZCOMP* where COMP stands for the name of the company are the ones made at the beginning of the project. And so on.
Will this work? Not in my opinion.
There must be only one orchestra director for SAP Security. Regardless of the projects that are being carried out by the company.