Brent Van Dyck wrote:
Keep in mind the project was for an HCM implementation where there's already hardly any connection between tcodes and authorization values so it may have made more sense in that context than it would in a classic SD/MM.
That is correct - but it still exceeds "horrible" beyond imaginable boundaries if you try to split the fields of the objects into different roles and expect it to work or that there will be less roles.
In the case of HCM and also BW the auths admin needs to know more about the data and organization than what classic ERP auths admins can get away with. That is why they take longer to migrate away from manual profiles and have a greater tendency to have manual authorizations inserted into roles - which could however also be achieved by maintaining fields proposed without values and at least proposing those (such as activity type fields) which are known.
But splitting cube / characteristics / key figures or infotype / personel group / auth code into different roles can only go wrong.
Another mistake some "value role experts" sometimes make is that they don't want Su24 proposals in PFCG because they don't understand them. So what they do is that they clean out the SU24 tables completely... Well... the side affect of that is that all SU24 check indicators flagged as "no check" suddenly become alive in their system although there are mostly good reasons not to have the checks active.
Cheers,
Julius