Auorization group for old programs without any documentation

Question: Hi all my friends,

Our company has no authorization checks for Z* programs before, the manager asked me to set authorization check for all the several hundred programs without any documentations.

What I proposed is using authorization group. After several days efforts, I got a list that can tell which programs was executed by whom in the past 6 months through log analysis.
Problem is that we can't classify these programs into paticular roles, for no documentations exist at all, we don't know their purpose. So we will generate a role for every user, i.e, if we have 300 SAP users who use Z* program, then 300 roles should be created. Do you think whether it's reasonable? Besides the high workload for BASIS team, is there any other problem for this solution?
Thanks a lot!

Answer:
Ohh... Have you noticed anything strange happening in your system or IT costs as a % of turnover since the first of the several hundred reports were released for productive use?

Your starting point is a good one, but granting a user a report just because they ran it once in the last six months, is NO reason to let them keep running it.

Step 1: Check the development classes to see whether they can give you a clue. I assume not, from the sound of things.

Step 2: Reports are one thing, transactions are another. I assume your users are starting the reports from SA38 etc, but you still need to check which reports are being called by Z* & Y* transactions. Use SE93, as I assume there are few.

Step 3: Go to TRDIR table and select the reports with a SUBC = 1 (executable report). Those are the ones which can be executed from SA38 etc.

Step 4: Take SA38 and run RSUSR002 searching for Object 1 = S_PROGRAM Action SUBMIT for #* auth group and then again for ZZBLOCKED auth group. Make any required adjustments so that only super users (and some support staff from the sound of things) have the auth group ZZBLOCKED.

Step 5: Take all reports which have NOT been used in the past 6 months and give them the auth group ZZBLOCKED or similar. DO NOT GO FAR AWAY FROM YOUR PHONE OR PC!!

Step 6: Take the remaining reports which are SUBC = 1 and have been used to an Excel Sheet.

Step 7: Take a look at the names of the reports just for information. You should not rely on that to do a thorough job, but save them to Excel and try to sort a little bit.

Step 8: Now take the users which have been using those reports and try (if you can via user groups or your knowledge of them) to sort them into functions or roles in the system. (If you have always been good about PFCG and have good SoD, you could (have) use(d) the user master records for short cut here...)

Step 9: Now match the sheets from 6, 7 & 8 and try to come up with a draft for the groups for the reports. Particularly, try to match the groups to the roles (should you have any) and give them an approriatly deigned name, such as Z_FI_BALANCES.

(Side note: there may be reports being used because a consultant "sold" a few hours to you by "writing" a fancy balance sheet report for you... - too late?)

You should have a bit of a picture now, but it could also be completely wrong, so now the hardwork starts...

If you have several hundred reports in PROD, you may well have only a few hundred reports in DEV and particularly TEST system!

Step 10: Refresh your TEST system fro PROD, and then look at the code of each of the reports and run them in test to see what they do. Make any ammendments to your list as required.

Step 11: I recommend this step here already, as in the absence of documentation and what you discribed, you will need to look at the code anyway. Any report (during the above testing) which produces a screen offering some thing like TABLE, will need an S_TABU_DIS etc check for example. A report which offers a sellection of COMPANY CODE, will need an appropriate *_BUK object check if you have more than one. A report which offers a table update, or just performs one without offering, will require a check which is appropriate for what the report is doing. Furthermore, you can reports such as RSRSCAN1 etc for looking for powerfull statements in the ABAP. If strings such as USR02, or *USER* or INSERT REPORT or XXPASS occur, let us know! Ask your developers for more... hmmm...

Step 12: When the reports have auth groups as required, either put them into your roles for the different functions (just kidding!) or create roles (also kidding!)... I guess you are going to create profiles? One for each group.

Step 13 <- Perfect : Then assign those groups to the users (via the assignment of the profiles (or roles or changes to roles if applicable) which used the reports and then use RSCSAUTH to place the auth groups on the reports. STAY NEAR THE PHONE AND PC!!!

Step 14: Anyone who complains about "I can´t z_bla_bla_bla" has to prove that they need and are authorized to z_bla_bla_bla.

Then start looking for a standard bla_bla_bla too.... (but that is a different chapter).

When the "intensive care" period is over (could be several weeks or months - but start anyway), you need to create Z* transactions which call those reports and take SA38 etc away from the end users....

But that is a different chapter. Read the site for lots of infos and also corrections and improvements to first attempts to answer, such as the above.

Hope that helps,
Ned

Answer:
Hi Ned,

Thank you very much for your quick response and deliberated explanations.

Your instructions listed above is actually what we have been doing these days. The program RSUSR002 you told me is very helpfu. I'll try to research.

Answer:
And be thankfull that you have such a manager!