Understanding Security Authorizations in SAP APO
Executive Summary
- APO security goes across applications.
- We cover the basic model of APO security.
- This includes master data security and Planning Book security.
Introduction to APO Security
SAP security is considered “robust,” but it is quite a time consuming to understand and configure. You will learn how security works in APO.
Background into APO Security
While researching the book “Bill of Materials in Excel, Planning, ERP and PLM/BMMS Software,” I compared what I believe the best security model I have seen in the BOM management software application called Arena Solutions with SAP. The level of sophistication and capabilities between Arena Solutions and SAP were very significant. Recently I was not able to meet very elementary requirements at a client on an APO implementation, and it is clear that security is a major shortcoming, which requires updating and improvement on the part of SAP.
The requirements I am analyzing span the following areas:
- Planning Book Security: This includes things like:
- Keeping planners out of the planning book while the planning runs are being performed.
- Preventing some planners from changing or deleting the selection profiles of other planners.
- Master Data Security: This includes things like:
- Controlling who can change master data fields on the product location master.
Understanding SAP APO Master Data Security
Master data security is set up with a combination of roles assigned to any number of transactions. Once a role is created, a role can be assigned to another role, allowing nesting, enabling the roles to be maintained with less maintenance than would be required if this functionality did not exist.
Nesting in the Authorization
Below, one can see that a role can be assigned to other roles. This allows the roles to be defined narrowly and then assigned flexibly to a broader user role – such as production planner, inventory planning, etc. For instance, some of these planners can be provided with master data transaction access, and some not.
These roles can make changes to different aspects of things. These roles have already been created and can be assigned to a role that contains many roles. The “macro” roles are then assigned to a user (notice the user tab in this role). This provides many to many security setup capabilities.
The Standard Roles APO Ships With
APO ships with several standard roles that can be used for implementations.
A Security Model Built Around Transactions
SAP can set security at two levels.
- The Transaction
- The Authorization Object
Setting security at the transaction is the easiest, most straightforward, and also the most maintainable. This is the detailed authorization screen below.
For instance, APO can restrict by Selection Profiles — which are the master data selections in the Planning Book. However, would anyone actually do this?
It would create a maintenance nightmare. Secondly, it is unknown if this would stop the planner from merely create new Selection Profiles – simply circumventing the security that had been applied.
Planning Book Security
The same problem of a lack of detail in the security setting affects planning books as well. Because the planning book is a transaction – for instance /SAPAPO/SNP94 – is one of the planning books, it means that once a planner is assigned to a planning book, they can adjust any object – product location, resource, etc.
The planning books (the main user interface for SAP SNP and SAP DP, — but not PP/DS) are controlled by Selection Profiles, which control what is viewed – and can be changed in the planning book. Each Selection Profile can be set up with various objects, which controls what the planning book shows.
The following objects are available to add to a Selection Profile.
Here you can see that APO security’s only ability is to add a transaction to a role. Examples of transactions are shown in the screenshot above. There is no further delineation below the transaction, and this is the problem. This means that any planner can change any Selection Profile once in the planning book – whether they created them or not. The other planners that rely upon this Selection Profile would never know unless they opened the Selection Profile and checked – which they would tend not to do.
However, these are simply different transactions assigned to the user roles that would use the transactions.
Conclusion
SAP APO’s security only provides an expansive level of control over the system. The authorization objects on some things — such as Selection Profiles are too onerous to maintain — and not actually truly restrictive for a planning intent on getting around the security. Even the average client will have requirements, which are too heavy for APO’s security model to handle. Because of the overly broad security available within APO, there is a strong incentive to either reduce the authorizations below what they could be. Either removing planners entirely from all master data transactions or giving too much access — and asking the planners/users not to change certain data. This is not really security at all — it would be filed under the category of “hope.”