The first part of this blog was published a few weeks ago. We talked about the steps needed to maintain your company’s authorizations when you implement SAP support packages, and you need to replace T-Codes. This blog will continue on through the final steps.
Here’s a quick recap of the previous post: In certain SAP support package upgrades, some T-Codes get replaced with others. When this happens, and you need to replace T-Code A with T-Code B, some steps are required. The normal procedure goes like this:
1. Update user authorizations so they match the T-Code changes
1a. Identify who really used the old T-Codes
1b. Update user roles and authorizations according to actual usage
2. Update the relevant GRC rules and add the new T-Codes
Step 1a was described in detail in our former blog post: Part 1: Support Package Upgrade: How to Update SAP Authorization Roles. This blog will detail the additional required steps.
Step 1b: Update user roles and authorizations according to actual usage
You might think that the main task here is quite simple – just replace T-Code A with T-Code B in all authorization roles, and that’s it. Well, if you make sure to remember that there might be some changes in authorization objects too, this will do the trick, but it’s definitely not simple. You have to compare all the authorization objects that are used by T-Code A to the authorization objects that are used by T-Code B and see that they match. If not, when you take off T-Code A, you will have to replace the corresponding authorization objects of T-Code A with those in T-Code B as seen in the diagram below:
You can see that although some objects may remain the same (marked A2), some objects should be replaced (let’s hope that the authorization fields are at least the same), some objects are added for new functionality, and some are deleted. As we said, not a simple task at all.
However, there are two tricks that can make the task easier for you:
1. Having a matrix of “Who’s doing what” like the one that we presented in our former blog post: Identify who really used the old T-Codes. A matrix will allow you to focus only on the relevant users, which will often not be so many. Normally, the percentage of use is about 13%, so if 200 users have the ability to use T-Code A, in fact only 26 do use it.
2. Using Role Replacer. This is a tool in our SAP Authorizations Monitoring Suite that allows you to find the best alternative for a given role, based on certain criteria and requirements. I know that this requires you to have this tool in place, but this is really the quickest option. You can use the “Bulk replace” feature and finish the task in a fraction of the time that it will probably take manually.
Think we’re done? No, there’s another important step…
Step 2: Update the relevant GRC rules and add the new T-Codes
If your organization is obligated to GRC compliance, you’ll need to update your Segregation of Duties rules. These SoD rules are often managed through a dedicated tool – for example, ProfileTailor GRC or SAP GRC. Here, you have to find all the rules that contain T-Code A and replace it with T-Code B. Easy? Well, it depends how you’ve implemented the rules, but it will still be easier than the former step:
If your SoD rules are based on T-Codes – you’re safe. You just have to replace T-Code A with T-Code B in all the rules, and you’re done. If your SoD rules are based on groups of T-Codes, it will be even easier.
If your SoD rules include both T-Codes and Authorization Objects, then it’s similar to what we did in step 1b above. For the new T-Code B, you will have to see which authorization objects remain the same, which are changed and which are removed. It will be a bit less complicated though, as SoD rules don’t include all authorization objects, but only the most significant ones, like company codes and purchasing groups.
If you have included isolated authorization objects in your SoD rules – it will take some hard work to replace them. If this is the case, we advise you to refer to an SAP authorization consultant or contact us, and we’ll see how we can help you.
By the way, if you’re in the process of implementing SoD rules, don’t miss our most-read blog post about the concept of isolation: Making a separation between technical and business related authorization objects.
Done with steps 1 and 2? How did it go? Please share your experience with us in the comments below.
See how ProfileTailor Dynamics can help you put your authorizations in order.