What roles a user has used

[Former Member]

At our company, people move around a lot.  Typically they get given additional roles, but old roles don't get removed.  I have been tasked to trim our users roles.  So my question is, "Is there any way to determine what roles have been needed by the user in say the last year?"  As an alternative, what is the best way to determine what TCodes they actually use?

Neal

[tobiasharmes]

Hi Neal.

There is no "show me the roles used" option build in SAP standard. But there is a "show me the transaction used". Look into ST03N (Workload Monitor), switch to Expert Mode, select a time range on the left top hand (e.g. double click "today"), then bottom left hand transaction profile -> Standard.

Or just run SWNC_COLLECTOR_GET_AGGREGATES in SE37:

Import-Parameter Value Meaning

COMPONENT TOTAL All application servers

PERIODTYPE M month, alternative W = Week

PERIODSTRT 01092014 first day of workload

Then export table USERTCODE.

With this list you can make further queries together, maybe in combination with table AGR_USERS and AGR_1251 (Filter on object S_TCODE).

Cheers, Tobias

[former_member82556]

I find the easiest way is to run the  action usage report in GRC 10 (Access Management->Role Mining-> Action Usage) which shows the transaction usage.

You can also get similar results from SM19/SM20 if it's configured correctly.

[Former Member]

So, I had great hopes for GRC10.  Sadly, it only reports transactions that can cause SOD's.  I have to know everything that is used!

Neal

[Former Member]

It looks like SM19 and SM20 are not configured in our system.

[Former Member]

If you have time, then another gemstone is to assign license classification to roles and the user inherits the highest role classification assigned to them.

Then (here comes the trick!) you use the license classification of assigned roles to distribute the costs of the system internally for the users to the role owners' cost centers.

Then you just wait... they will come of their own accord to request that roles are removed... 🙂

Again here, you must build roles and maintain SU24 in such a way that you have job roles at the single role level and there is no "piggy backing" (role A only works if role B is assigned as well). The roles must be able to survive and function on their own as well.

Cheers,

Julius

[Former Member]

Julius,

When you say "assign license classification to roles" are you refering to US930-USERTYP?  This is on the last tab of SU01.

Neal

[Former Member]

Nope. I am referring to PFCG -> Role -> Go to -> Assignment of Price List Category. You can use that for license measurement and (internal) cost distribution as well.

Cheers,

Julius

[Former Member]

As long as SU24 is well maintained, then removing roles can be easy as there are less "authorization surfers". Typically the "common role for all users" is the biggest problem.

But if you have relatively qualitative roles and Su24 well maintained, then a "coverage analyser" has worked very well for me (as Tobias indicated, you need to code it on your own or find partners who specialize in such concept conversions without disruptions.

Another cool trick is to license users via role classification and the user classification is inherited, and distribute the costs internally based on the assigned roles. As long as the roles can survive on their own (SU24!!), then you can assign system costs via role assignments and if role owners don't want the cost of the role which accesses their data assigned to the user, then they will contact you instead or you having to take best guesses.

However a "coverage analysis" will typically let you find the "movers and leavers" depending on how you build the roles.

Tapping into HR movements about users is also generally a good idea, depending on how qualitative the HR data is and whether all users are there (consultants? SYSTEM users? Test users? etc.. you might not want to automate this process, but good reporting is very useful....).

Cheers,

Julius

[Former Member]

I'll review all of your helpful answers over the next week an get back to you on what worked for me and what didn't.

[Former Member]

To see what transaction codes a user has actually used, look in the audit log - SM20. Depending on your policy they may be kept for a long time - we have ours going back to day 1. Reporting on them over long periods isn't quick, unfortunately - I have in the past undertaken the very same analysis you are looking to do, and it can be painful!

Once you have the list of transactions used, mapping them to corresponding roles is easier, but of course there isn't necessarily a 1-1 mapping. If a user has access to one transaction via several roles, you need to do further analysis to decide which to keep and which can be removed. There may be roles that you can remove even though they contain used transactions, if those transactions are also in other roles. How easy this process is will depend on how you structure your roles. The less overlap, the easier it will be,

This isn't a simple project, and you won't know until you are well into it exactly how much you'll be able to clean up. May a little, maybe a lot.

We're glad we did it, bit we only did it for selected users, not for everyone, so it wasn't a monster project...

Steve.

[mvoros]

Steve Rumsby wrote:

To see what transaction codes a user has actually used, look in the audit log - SM20. Depending on your policy they may be kept for a long time - we have ours going back to day 1. Reporting on them over long periods isn't quick, unfortunately - I have in the past undertaken the very same analysis you are looking to do, and it can be painful!

I would suggest to use a better tool for this. Load those files into something that is better in crawling logs (e.g. Splunk) and then report from there.

Cheers

[Former Member]

Steve,

How do I get to that?  It seems to be saying that there is nothing there.

Neal

[Former Member]

Auditing might not be enabled - check in SM19. I'd be surprised if it wasn't enabled in a production system, but might not be in DEV/QA systems.

Steve.