on 09-01-2017 8:46 AM - last edited on 02-04-2024 12:16 AM by postmig_api_4
Hello Team,
Our company has multiple release code and release group.
For each release code and group combination we have a single role.
The number of roles are increasing with the creation of new release codes/release groups.
Is there a way or different strategy this is being handles in other organizations?
Can we create a custom table to add users with new release code/group to avoid multiple role craetion. What are the risks associated with this?
The first thing that you have to understand is what a release code actually is. It is basically a key to unlock a door.
Imagine now an apartment building, each apartment has usually its own individual key, the release code.
The caretaker service has a general key, one key to open any door.
The question is now, which kind of key do you want to give to your tenants?
If each tenant should have its own individual key - then this means for each release code 1 role
If all tenants would be okay that each of them has the general key - then you can create just 1 role and add all release codes to this role.
The tenants would actually not even realize this if nobody tells them. The release code is a mandatory field in the release transaction and not searchable. So the approver knows basically the code which was told to him. Even better if all was supported with approval workflows and the approvers would not need to go to the normal transactions.
Actually, the team who is building the roles is not really in the lead in this activity which is purely based on the setup of the purchasing release strategy. If "general key for all" would be wanted then the whole release strategy setup could be done differently. Of course it would be best if MM consultants had some knowledge on role creation and their company specific concepts but also the authorization team could consult with the MM guys if they understood how a release strategy works. Unfortunately purchasing release strategy is the supreme discipline of MM consultants, and because of that even more difficult to understand from non-MM-consultant, but maybe it can help you to read my blog https://blogs.sap.com/2015/01/04/purchasing-release-strategy-an-expanded-explanation-and-a-gps-throu... to get a step into this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It is a big and very detailed blog.I had to read it more than once so I can understand how it works behind the scene.
I have some understanding now and have set up a meeting with our Production Support team handling the release strategy.I will try to understand the current strategy being followed in our organization and if they want to change/ optimize it .
With the current little understanding I had it seems they do not want to touch it /change it 🙂
Authorization Group concept, just wonder? I mean restrict the tables on Authorization groups level through criticial Authorization Objects S_TABU_DIS & S_TABU_NAM.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
can't we go with Master and Derived Role concept or may be restrict the user base on Authorization Group concept, just wonder?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Rizwan,
Release code and group are not an organization field . We can change them into org field but it will not bring the role count down.
We will still have to create a new role for new combination of release code and release group.
Can you please explain how we can utilize the authorization group concept in this scenario?
User | Count |
---|---|
82 | |
10 | |
10 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.