Job role design - transaction role and auth object role

[Former Member]

Hi all, please kindly comment following job role design:

(1) transaction role:

Keep transactions in single job role to represent business processes in different application areas, e.g.MM: maintain PR, PO, OA.   CO: maintain cost center, internal order   HR: maintain org structure, personnel management.
The single job role will only keep role menu, object S_TCODE and inactivated all other application related authorization objects.

(2) authorization role

Keep application component related authorzation objects except S_TCODE in single job role by different application area, e.g. Objects of MM_B, MM_E, MM_G in MM role. Objects of K_CCA, K_CSKS_SET in CO role.  Objects of HR in HR role.
Then maintain org level of MM, CO, HR roles for different companies, e.g. Company A MM role, company A CO role, company A HR role, company B MM role.;....

User will be assigned transaction role + auth object role.   For example, user of company A to perform MM and CO functions will be assigned
with MM transaction role + company A MM role + company A CO role.

Please let me know the pros and cons of above design.  Thanks.

Regards,

Donald

* I can see the disadvantage of this design is during SAP upgrade (SU25), revised of authorization object will not reflect in authorization role

[Colleen]

I'm not a fan of split role concept as it makes it difficult to restrict level of activity in a role as an authorisation with organisational fields typically contains activity field for create, change, delete, etc

I prefer using imparting and derived role concept.

How would you manage a display only situation? Do you then have a set of authorisation roles with display only?

[Former Member]

Hi Donald,

The Authorization matrix is designed as per company policy. To design a role in PFCG, you need to add Transaction code and others authorization objects also. You need to ask the business people (Business Process Owner) to provide the requirement. You then create and test in development server and implement into production server. But as per my experience, better to create role as per small tasks like

MM(PO Release release level, MIGO, Movement types,PR, change, display create etc. Then create composite roles for every users and these tasks into composite role as per business requirements.

Thanks

Asad

[OttoGold]

You can bill a lot for such a monster, right? How many roles you end up with? 10 000? 100 000? How do you do it? Manually? I doubt it. Direct updates on standard tables? Good luck

[Former Member]

Hi Donald,

I'm sure technically you can make it work and can probably result in a very efficient implementation. However, apart from the SU25 feature, the biggest concern I have with this type of design is the difficulty to document it accurately and efficiently also will be difficult for future support.

By using your proposed method, you are not utilising the inbuilt system documentation method of using SU24. Once you need to document manually outside of the system it will be difficult to ensure high accuracy unless you have very strict change control processes. In addition, it will be difficult to support for future support person not involved in the initial design.

think about:

- run SUIM to find which role contains Transaction A with ability to modify Document type B and Sales org C

- ability to use where used in the role for a object to see which transactions are affected,

- I assume your goal is to minimise the number of roles, but to satisfy segregation of duties issues you may be forced to create more roles.

regards,

John

[Former Member]

Hi Collean, Asaduzzaman and John,

Thanks for your quick responses.  I summarize the feedback as below:

Pros:
Minimize number of job roles

Cons:
Problem on SU25 job role upgrade
Create more roles to satisfy segregation of duties
Difficult to document accurately and for future support

Hopefully more input from professionals who have implemented similar job role design.

Thank you once again.

Regards,
Donald

[Former Member]

Donald Yau Wing Lee wrote:


Pros:
Minimize number of job roles

This is not true. If you attempt to split the transaction start authorizations, basic access authorizations, activity type controls and org.level sets between roles... then you will end up with more roles per user than what there are fleas in the armpits of a thousand camels.

Avoid value role concepts at all costs. It always goes wrong.

Cheers,

Julius

[OttoGold]

This caught my eye:

Cons: Create more roles to satisfy segregation of duties

Is it possible that you started this concept from the GRC side and not from the PFCG/ SU24 side? I am also very much interested in knowing if you invented this yourself (if yes, then based on what experience or advise or documentation) or you're sold that monster (if so, what is the reasoning / sales pitch)?

cheers Otto

[Colleen]

Were us professionals insufficient or did you want more professionals to contribute? Or did you want someone to support your proposal?

[Former Member]

Colleen Lee wrote: .. Or did you want someone to support your proposal?

Hi Colleen,

This is only a discussion and I wish more professionals comment on the design.  Thanks.

Regards,

Donald 

[Former Member]

I would think that you have enough comments (with experience) for the discussion to be statistically relevant already. How much more are you expecting?

I also doubt that someone on a kamikaze trip is going to show up any time soon and argue that it is a good idea... besides which folks who believe in value role concepts are most likely illiterate anyway...   (they certainly don't hang out here on SCN..).

Cheers,

Julius

[Former Member]

Julius von dem Bussche wrote:

I would think that you have enough comments (with experience) for the discussion to be statistically relevant already. How much more are you expecting?

Hi Julius,

Yes, I'm happy with the comments from all experience professionals.  This is a really fruitful discussion.

Regards,

Donald

[jurjen_heeck]

Hi Donald,

I am afraid this concept is moving too far away from the SAP standards. You have listed the cons fairly accurately. The actual value of the only pro you have listed is very subjective. With good automation skills and role building experience large numbers of roles are -if named systematically- fairly easy to maintain.

The 'future support' con weighs in heavily as all the standard SAP reports and best practices for authorization analysis will stop working. Guarding possible SOD conflicts looks almost impossible to me with this setup so a good auditor (i.m.o.) should disapprove it completely.

As an experienced security consultant I would actually refuse to set up SAP authorizations in this way. If decreasing the amount of roles is your goal I, like John, think that'll fail as well.

Just my two cents,

Jurjen

[Former Member]

Exactly. I also refuse to work on such designed projects (except for doing "what went wrong audits") and even refuse to sell them our software as I do not want to be associated with it in any way.

Cheers,

Julius

[OttoGold]

This idea often comes from externals that can see that the project can cost less time (which they either don't tell and bill the full monster or they can't sell with a price over XX) and by the time the customer realizes the support cost is far higher than a reimplementation of that mess, they're long gone.

[Colleen]

I Only learned about split role concepts when I arrived at a client site to clean the mess up

[Colleen]

Yes. I always attempt to push as much deliverables into project side to get a good solution as support budgets can't afford it! I've worked the support side enough to see the mess that was cheap, short-sided, let's get this over the line approach.

[jurjen_heeck]

That is exactly my 'drive'. I got to know SAP as an administrator at first and went on with consulting & projects later. I know what the burden of low-budget projects can cause for the support crew.

Not on my watch 😉

[Former Member]

Jurjen Heeck wrote:

I am afraid this concept is moving too far away from the SAP standards. 

I've actually known SAP to recommend this design strategy. On a previous project we had 2 SAP authorization experts fly in for two days to assist with the start of the authorization design and their recommendation was to use the split concept as described in this thread.

In the end we still set it up task based (as the other SAP systems in the landscape already had a task-based conecept) but I've always wondered how it would have been if we had given it a go.

On a side note, I doubt it's really as horrible as it is being depicted in this thread. 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.

[Former Member]

It is very tempting to ask you to give us their names... 😉

But we all learn from mistakes. PwC in Germany and Switzerland also tried it based on ppt. file success for a while but have distanced them selves from it (except for PwC from North Carolina in the US who are not open to new ideas which are actually old facts).

I heard that there will also be some recommendations from SAP and TechEd "do's and don'ts" presentations with statistics from fails this year.

But if you think about it a bit then it is actually clear  - you cannot split the start and myriad of cross-component and activities and org.levels from another. And how many times the user has the access does not matter much....

--> so pull it from the entry point as much as you can and you have more robust job roles and where-used-lists for the 7k application objects if you want to change something. It works fine. You can upgrade in 1 day. You can make mass changes via SU24 proposals and simulate the affect on roles. You can do a lot of funky things which are very scalable and reusable, also in the long run.

Cheers,

Julius

[Former Member]

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

[Colleen]

I also wonder if in the HCM solution it was more than likely ESS/MSS and they were relying on P_PERNR to exclude user activity on own account. Still sounds like a headache to restrict PLOG and P_ORGIN* objects to differentiate between read and write

Role maintenance aside, in other modules, split role concept is a headache when users can jump between transactions via menus. Run a report for Vendor line items and then drill into Vendor Master Data. You are further relying on an S_TCODE restriction!

Was split concept something pre-PFC when minimising profile build and it's just hung around in some areas? My exposure to it was due to a non-SAP group claiming they could do SAP. I just thought they tried to apply their own product specialty's security model to SAP. It was easier to completely rebuild the security then work our how to clean it up. Part of the issue, they never designed the security to factor in system growth. They build the security around one specific module and then suddenly they expanded functionality on the system and the model was no longer appropriate.

Cheers

Colleen/Mikki

[OttoGold]

I would open a customer message to say that I was sent a pair of MM junior consultants but my project is a security one There is no other way forward.

This will ruin the customer in the long run and damage the overall security starting with the day when one person makes a mistake (or a newcomer joins the team and starts doing the work it is supposed to be done which is much more likely to happen).

[Former Member]

Hi Donald,

I've been resisting the urge to reply on this as you already have some great answers from some very knowledgeable people.

If I was to sum this approach up in one word it would be: Avoid

Back in the days when I did more audit work, this approach was very often accompanied by security issues caused by role growth, authorisation inheritance, people not understanding the solution etc, etc.  I've also had the pleasure of fixing a good number of implementations where this has caused users to have much more access than required.  For ECC it is a disaster zone.

There are a few comments on HCM and BW - while it is certainly not my preferred approach, it can work and be sustainable with suitable support but there is a skills overhead that doesn't often work if support is being provided by a generic security pool.

I feel strongly enough about this to say to my team that recommending this approach to a client is a disciplinary offence.  Fortunately they know better!

Cheers

[OttoGold]

All the people recommending this approach I've met in my life (ok, I am not around for 15 years...) were salespeople or "consultants" working for companies that provide tools to build these things. So they're selling the "concept" that cannot work without their tools -> hand in glove.

- lock-in for the customer (you cannot use this "concept" without some automation which means you cannot abandon the tools and keep the roles)

- fast project with their templates and "mess generators"

[Former Member]

Ah the joys of Securinfo

[Former Member]

Alex Ayers wrote:

If I was to sum this approach up in one word it would be: Avoid
...   
... I feel strongly enough about this to say to my team that recommending this approach to a client is a disciplinary offence.  Fortunately they know better!

Hi Alex,

I only implemented ECC job roles twice (one in year 1999 when role was called activity group and one in 2007) and both followed PFCG standard.  I learnt the split role concept from forum discussion in year 2000 and I realized the writer may still love to build security profile directly and dislike PFCG. Since we received recommendation to use split role in order to reduce number of job roles, I need comment from professionals because I have no experience on supporting "split role".

I'm really appreciated all the comments from experience professionals:

Colleen, Asaduzzaman, Otto, John, Julius, Jurjen, Brent

Thank you all.

Regards,

Donald

[Colleen]

Hi Donald

Since we received recommendation to use split role in order to reduce number of job roles

As part of their recommendation did they run the numbers on their justification and also mentions the drawbacks (i.e. SoD issues, access creep) that have been discussed in this thread? You might benefit in hearing what they have to say. If they cannot explain how those risks are eliminated then you will also be in a better position to determine how sound their advise is and whether you should reject it. Take some of the points raised in this thread and put them as questions to those who made the recommendation.

Curious to know who made the recommendation on a topic that appeared to be a 'flavour' of building role design from 15 years ago? A lot has changed since then.

Regards

Colleen

[Former Member]

Donald Yau Wing Lee wrote:

Since we received recommendation to use split role in order to reduce number of job roles, I need comment from professionals because I have no experience on supporting "split role".

I'm really appreciated all the comments from experience professionals: 

The great thing about these fora is that we can all share our experiences 🙂

The comment about my team wasn't aimed at your consideration of this approach, more that I would not want them to advise a client to do that.

[Former Member]

Hi Alex and all others,

Thanks for all comments and I think it is time to wrap up this discussion.  Below is my summary on using split role concept:

Pros:
Minimize number of job roles (may be.... cross your fingers)

Cons:
Not SAP standards
Problem on SU25 job role upgrade
Create more roles to satisfy segregation of duties
Difficult to document accurately and for future support
May cause security issue by role growth and authorization inheritance..

Regards,

Donald