Connectors and logical groups

[Former Member]

Hi All,

So I just have a general question regarding the logical
groups.  So in a project that Im
currently working on it was suggested to create a logical group to include all
connectors from all modules (one logical group with ECC, BI, …) and the idea at
the end is to have only one Rule set to rule “all modules”.  Now my concern about this is that in previous
projects I have always created connectors and logical groups according to
modules (ex. one logical group that include ECC prod, ECC Dev, then another
logical group for BI, etc).  Can someone
give me their opinion on this? Can we really just create one group and apply rule
set to all modules?

[Colleen · Accepted solution]

Hi Jonathan

I currently take the approach/view point of creating a logical group for the component (E.g All ECC systems are on one and all BW on another).

My main reasoning for this is that the Logical Group is used to define the actions/permission for a Function. Actions and Permission translate to transactions and authorisations objects which are different across components.

Also, an action in one system may not contribute to a risk in another. In addition, if you have a complex system landscape whereby you have multiple ERP systems you may have split FI and HR to different components. So, maintaining employee data in one system could contribute to a risk but that same access in the finance side may not - depends on how you process executes and how it's split across the components.

The drawback I see in my approach is if all my logical systems have the same action for a function, then I have to define it each time. E.g if I want to add SU01 as an Action in a Function for ECC, PI and BW then I'd have to add 3 entries. But that can easily be resolved via mass upload.

I think this questions (or slight variation) has come up in other posts. But it's a valuable to discussion to get everyone's view point as there are a few different ways. Part of the approach will depend on how complex your system landscape is and scope of functionality. At the same time, you also have to consider system growth (new components, new modules, etc).

Regards

Colleen

[Former Member · Accepted solution]

Thanks, this information was very helpful, I have seen similar questions but never a "no don't do it" or "yes" so I guess it is possible but is more about perspective than anything else.  Thanks for the reply.