What exactly information does the management want?

There are a few approaches you can take.

SAP Job Description: For each job (highest level role. composite, etc) we have a description that describes in Business Speak what that job allows a user to do. It avoids as much SAP jargon as possible. Any person from the business could look at the description and get a picture of what that person should be doing on SAP. This is what gets signed off at the highest level and it is the security, functional and internal audit guys that are responsible to ensure that the role meets this spec.

Transaction Breakdown: For Internal Audit Management the job is broken down into it's constituent transactions and Internal Audit (and usually Functional Team) will look at this at a high level to ascertain that the required functionality is being met by transactional access. Where sensitive transactions are identified the granular breakdown is used.

Granular Breakdown: This is the level at which restrictions are reported. It is here that object level restrictions are documented. Any transactions that are deemed sensitive will have information pertaining to the restrictions included here.

In Practice this is all contained within one document, any changes to the roles are contained within this document.

A point to make is that by listing transactions to your management team, you will not give them an accurate indication of users access by giving them a list of transactions!

If you want to get lists of transactions you can use the following tables.

AGR_USERS
AGR_TCODES
AGR_1252 (Lists Org Levels)
AGR_1251

-------------------------------------------------------

Comments on Authorisation concept

Above all KEEP IT SIMPLE!!!!!!

Composites are NOT simple. they require a lot more time to discren what is wrong and which piece must be fixed. and then you have to test EVERY role the component is used in not just the set tied to the user.

Base you role on "everything the user must have to do their job", Granted some user have more that one job, but a "Vendor Invoice processor" should be the same all over a centralized company.

Further, composites cause the user to load several redundant authorizatons which slows logon time, require you to have a bigger machine than needed, and the list goes on.

It would be best you could go one step further and avoid the use of composites.

1) they lead to users having far more than they need
2) they are not suited to different sites which have big differences in the number of employees but still need to do the same roles - eg in a larger company users' roles are much smaller and vice-versa
3) they are a pain to maintain
4) they do not bring great enough benefits

You will realized these things after using and maintaining composites for some period of time.

If you have used composites, get rid it.

You'll never missed them!

SAP Basis Reference Books:
SAP Basis Components, System Administration, Security, ALE and iDoc Books

Back to Basis Menu:
SAP BC (Basis Components) Hints and Tips

Return to :-
SAP ABAP/4 Programming, Basis Administration, Configuration Hints and Tips