Question:
Hi ALL
Has anyone had any previous involvement with anything like my following scenario or suggestions on Pros and Cons?
My Company has six company codes in R3 4.6C, not using role based menu access.
Currently working on a project to implement role based menu access and review access requires.
Because of the six company codes, to reduce the volume of roles (excess maintenance for changes) we're considering implementing the following:
Create only one role for a process excluding the company code and controlling auth objects from the role.
Example:
A person processing Accounts Payable in any company code will be allocated three roles:
*The Accounts Payable role (auth objects for company code and controlling removed to another role) and;
*a role with the all the auth objects for (their) company code and controlling access and;
*a role with their company's cost centre access.
Thank you advance for any advice.
Cheers
Allison
Answer:
I've experience of both the 'split' scenario (separating what someone can do - functional Role and where they can do it - Organisational Role) and the 'inclusive' scenario (including all that a user needs to do their job in their Role). In the circumstance you outline, suppose that there were 6 accounts payable staff - one for each company AND each doing a standard process; you would have one Role for the Acc/Pay function held by each plus 6 company code Roles - the appropriate Role held by each - i.e. 7 Roles in the system. If you followed the more normal course "give a person the Role they need to do the job" you would have 6 Roles each of which would incorporate the company code. Multiply this across the many functions in an entity and you can see that the 'inclusive' option leads to a much lesser number of Roles overall. But you are now on the road to 'personalising' Roles which I don't like. You also have to be clear in your Role naming conventions i.e. "Acc/Pay Co.1", "Acc/Pay Co.2" etc. Now, what happens when a person does cross company (or cross organisational) functions? What happens when new/changed organisation units are introduced? In the 'split' scenario one just creates an appropriate new organisational Role (ideally derived from a master) and applies it to the relevant user(s) - much simpler to maintain.
I believe that this 'split' philosophy is quite appropriate for an entity with a large number of organisational units. The key is to document the rationale for opting for the 'split' (or the 'inclusive') scenario so that future security maintainers will follow the structure.
Hope this helps
_________________
Best Regards
Bazza
Answer:
This is what derived roles are for (Yes Mr. Jarboe we know you hate them). Split roles are not necessary and just make a confusing hash out of roles. You should be able to look at a role and know what it does and for which organizational entities it does them.
Answer:
Well you could have one role with all the BUK objects an 01 activity code, one with 02 activity code, one with 03 activity code. Then you could have one that has 01 for posting and 03 for master data etc. etc. etc.
Absurd isn't it. Some companies just say we'll make it all 01 and we'll assume that there are enough other objects that 01 on a BUK object won't be sufficient.
That is when you wind up buying some stupid Virsa-like tool to see if somewhere in your mess of combinations someone hasn't received too much authority inadvertently. Except that the tool will be configured in a half assed way and you'll run around like rats on a treadmill but never getting anywhere.
Let's just keep digging holes and falling in why don't we.
Answer:
One abining rule to all security Keep it Simple!.
Segregating Co code to a separate role will then lead to separate roles for plants , separate roles for Business area, separate roles for Vendors and the list goes on.. It is no simple. and it ends up loading the memory with superfilous authorizations that would be collapsed into one authorization if the data was in one role.
It is one of the "cleaver" things ( no offense) people dream up that will not outlive the developer (and that may happen when your backfill duing vaction has to make a change).
Answer:
Oh no Mr. Jarboe. Some folks just take all the organization objects and stick them altogether in one role.
People who have done this (separate organizational roles) are rank amateurs and should be mocked and villified. It is totally indefensible.
I know folks who have walked into this situation and have proposed alternatives but the resident powers that be can't acknowledge how utterly stupid it was so they make them continue to work with the load of crap.