Question:
Hi,
We have an requirement from the auditors that a configurer should not be able to view business data e.g. financial data in PRD. -- is this a reasonal requirement?
I did a few hours research here and they are all too theoritical to me, can you tell me:
1. is this a reasonable requirement? why? I ask them how they support users, I was told they should work with the users or create a copy of the user
2. what should be given to a developer in PRD? and functional configurer?
I would appreciate some detailed approach, such as standard role names, objects....
Answer:
This seems to be a two part issue:
(1) Should a person have dev/config authorities in PROD ? NO!
As a basic principle, I've always held that development/ config activities should be confined to the DEV box and hence should have no business in PROD (but see exception below). Consequently, any functional user support person should have display only in PROD for the module/area they support. Thus it is quite proper for a support person to view e.g. financial data if that is the area they support. For sure such a person should have authorities to be able to do all that a user can do in TEST & DEV (within their module/area of support) so that a user problem can be replicated, analysed etc. And if after analysis there's a config change required, this should be done in DEV and transported/tested through the system landscape.
The above relies on having a number of support people who are split along module lines. Where there are only a few support people their authorities will necessarily be more widespread - but not to compromise the basic principle of no dev or config in PROD.
The only exception would be a "Fireman" id which has extensive authorities (rather like SAP_ALL) and can be used in PROD only on approval from a nominated business person and only in dire emergencies.
(2) Should a support person be able to see financial data in PROD ?
YES ! providing that support person has display only as noted above.
Also, what do the auditors believe such a support person is looking at or playing with in TEST when they're trying to replicate/resolve a problem? Yes I know the data may be out of date but then this depends upon your refresh policy.
Hope this helps you.
Answer:
Thanks Bazza, this is fantastic!
Now can you throw more lights on technical details? I assume the roles for the areas a support person have, I should create them based on SAP standard menu? e.g. FI, I import them and then make activities to display only? But since some authorisations will need change as well this may take a little while to configure a correct set of roles for one area only.
What is your experience on that?
Answer:
Yes whichever way you go will take time and a thorough analysis to be correct.
As to the menu structure I believe this should follow the same pattern as used by the real 'business users'.
I've experienced PROD support Roles delineated by module, thus we have Roles called e.g. FISUPPD, MMSUPPD, COSUPPD etc. These contain all the display only transactions that the business uses for the module concerned plus reports. Note that as one can't predict where a problem will occur, these Roles should also contain 'all' organisational levels. If a transaction is all embracing - i.e. contains update and display, this is included but with the relevant authorisation object(s) set for display only. HR can be tricky, often businesses are a bit concerned about HR data - but then do they want support or not ? Personally I believe all business data is confidential to the business and don't see any distinction between HR and other data - indeed financial or planning data is more useful to a competitor than how much an accounts clerk earns !
I'm not sure about your comment "..some authorisations will need change as well..." - a support person in PROD should not have the ability to change business data.
All this is premised on a 'support person' being distinct from a business 'super user'. In this context, a 'super user' would need all the active Roles of the group/area (s)he is responsible for whereas a support person (as far as PROD is concerned) merely has to be able, via display, to follow the trail of the problem so as to understand it and replicate it in TEST where the support person can play and resolve it.
Hope this helps you.
Answer:
this is great!
I know high level discussion has been discussed quite many times now, anyone has any more input about how actually you build the roles e.g FI? this is a bit tricky as we cannot limit to one area only.