Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Roles on DEV, QA, PRD (Plzz Suggest)

Former Member
0 Kudos

Hi All,

I am stuck in grounding some decisions, please suggest me:

We are implementing SCM-APO in our company....For consultants and BA's I designed a tailored SAP_ALL role(tailoring system auth.) on SANDBOX so that they can do all the R&D work.

My question is how should I go ahead with roles on DEV, QA&PRD(future boxes).

1)Should I insist consultants/developers to define there tcodes/standard SAP delivered roles.

2)My company have no big resources, so I should keep in mind that I am not restricting them narrow.

3)What kind of strategy companies follow, when they are in similar situation? how they design there security on diff boxes?

4)What things I should keep in mind when designing roles on DEV, QA, PRD.

5)I should see that I am meeting SOX standards when I am doing this.

One of my manager was suggesting me to break SAP_ALL in to composite roles, so that with little resources we can manage the things. He was also suggesting like

Production Box---only display or run report...

QA box---No configuration change access....

Dev box--all the development and configure kind of access..

I was an administrator before all this decision making security work is making me crazy.....please suggest me guys on this..............

I like challeges but looking for some helping hand........

Thanks alot..!

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

There are two things - 1. SAP Client Role 2. User Role

You can restrict the configuration change access by the SAP Client role on the system level. For this, use the transaction 'SCC4'.

This would ensure that no user can change the configuration even if he has the role. This has to be done for all the clients other than the Golden Client.

Regarding the consultants/developers, the approach generally followed is (same as suggested by you) -

1. In the development/golden client, give the change access for all the transactions required by the developer/consultant.

2. In QAS/PRD give display authorizations for the transactions required by the developer/functional (spro display has to be given to functionals).

I guess the best approach would be to ask the consultants the transactions they need in the systems. Question them if they require Basis/Admin transactions anywhere and if required give only restricted access.

Once the system is setup and the consultants start working, they would definitely need more access (the ones they hadn't anticipated earlier) and you can give them as required (trace using SU53).

And again, this depends on the client but in one of my earlier projects, the client made sure that 'critical' accesses (like 'posting documents') are not given to the consultant in Production. If need be (for some ticket), the access was given for a day or two.

Hope this helps you to some extent.

-Neha

3 REPLIES 3

Former Member
0 Kudos

Hi,

There are two things - 1. SAP Client Role 2. User Role

You can restrict the configuration change access by the SAP Client role on the system level. For this, use the transaction 'SCC4'.

This would ensure that no user can change the configuration even if he has the role. This has to be done for all the clients other than the Golden Client.

Regarding the consultants/developers, the approach generally followed is (same as suggested by you) -

1. In the development/golden client, give the change access for all the transactions required by the developer/consultant.

2. In QAS/PRD give display authorizations for the transactions required by the developer/functional (spro display has to be given to functionals).

I guess the best approach would be to ask the consultants the transactions they need in the systems. Question them if they require Basis/Admin transactions anywhere and if required give only restricted access.

Once the system is setup and the consultants start working, they would definitely need more access (the ones they hadn't anticipated earlier) and you can give them as required (trace using SU53).

And again, this depends on the client but in one of my earlier projects, the client made sure that 'critical' accesses (like 'posting documents') are not given to the consultant in Production. If need be (for some ticket), the access was given for a day or two.

Hope this helps you to some extent.

-Neha

Former Member
0 Kudos

hi Anil Kumar,

we are facing similar problems too few years ago.. here is what we've done :

for DEV consist of 2 clients : customizing client and sandbox client

we open SAP_ALL into consultant so that they can do developing etc.

for QA consist of a client

we restrict the roles for the prototype of roles we will implement in PRD for users. and for consultant we are providing a user consist of SAP_ALL. Users will test their access in this role (with the sample master data exist). Once all user access is OK, download role to file and upload it to DEV, so that for the next you are defining role from DEV and transport it to QA or PRD using transport request or download/ upload.

please note : don't use the exact (the right value) master data at this client!

for PRD client

we are defining the right role for users, and defining a single user for consultant (temporary user) that is assigned SAP_ALL. periodically (once a day) we are monitoring what they do on this day.

if you are concerning in fact that they can monitor critical data in PRD, try to 'blur' your actual master data until the time consultant is leaving your company. at this point, you can correct the exact (critical) master data into the right value.

don't forget to erase all consultant users and unecessary users from all your client whenever it no longer be used, and keep monitoring your user access day-by-day (cause this is our responsibility as admin)

hope it helps.

rgds

alfonsus guritno

Former Member
0 Kudos

Thanks Guys