Coming up with a suitable role design

[HDSmith]

Wonder if any of you security experts out there can help.

I currently maintain profiles for an ECC 6.0 system but we still work with old-style authorisations and profiles as this was how it was designed when the system went live 15 years ago.

However, we're now embarking on a huge roll-out to other companies within our business bringing them all onto our system - they will be created as new company codes within the system and therefore will require new authorisations to reflect the new users within the system.

My intention is to go role-based as it didn't seem to make any logical sense to try and continue with the old profiles, however I'm not sure on the best design. I don't know yet how these new companies operate or their individual businesses processes but I was caught up in the dilemma of how to create the roles.

My first thought was to match a SAP role with a job role - create a common SAP role for a particular job (ie Purchaser) which contains the common objects, then create derived roles from here ie. "Purchaser company 001", "Purchaser company 002" etc. etc. so the individual purchasers cannot purchase for another company, but I make use of the common system objects in the role to prevent duplication if I create multiple roles for each company.

However I wasn't sure whether the "building blocks" approach was more advantageous - similar to how we've got our current profiles, we have a profile for "Create/Change Purchase Order", "Perform a GR" etc. etc and then combine these into a composite profile. The advantage of this I thought was it allows us to grant individual transactions and tasks to a person without giving them too much else. Of course the downside is that there will be LOTS of roles and perhaps adds to the complexity of the design.

Alot may depend on the nature of how the companies operate (ie. do people with the same job title do exactly the same job or are there differences ?) but I just wondered whether anyone could offer me any advice on how to get started with the best design that would be the most efficient to maintain and expand on in the future.

Many Thanks!!

Helen

[Al.]

Hi Helen,

This is a big question! One recommendation I would make is to run a search on the security forum with "role design" as your keywords. There are a lot of posts that cover this and you will see some healthy debate!

There will never be consensus on what makes the best role design but by the look of it you are asking the right questions.

The first think I would say is to keep it simple. You should be designing with support in mind, not speed of deployment.

Secondly, it pays now to get hold of a copy of the proposed SAP org structure so you know roughly (to the nearest 50 is good enough) how many org elements you will have for things like company code, plant, purch org, sales org etc. It's not a dead cert but often is the way that when companies are introduced onto a system then they are forced to adopt the business processes as they already exist. If this is true for your organisation (and there is no reason why it shouldn't be) then you should be OK with performing any calcs with similar restriction requirements that you currently have.

Thirdly, hook up with the change management team and see what they are doing around organisational design. When doing a consolidation project it is a great opportunity to get some commonality into roles and jobs that people perform. This can then be reflected in a users access and drive your design decisions.


Onto role build...I am not a great exponent of the task based approach but if you already have a well functioning design that you can leverage (your profile build) then that could expedite things by building at the task level and creating derived roles for organisational level differences. What you need to consider is the number of roles that you will need to build if you take this approach. If you have the org units data you can perform some calcs like:

Sales: 30 master roles, 20 sales orgs = 600 roles
Procurement: 10 master roles, 50 permutations of plant and purch org = 500 roles
Finance: 25 master roles, 10 company codes = 250 roles etc, etc

They are very rough and ready but will give you an idea of what the build is going to look like. A lot of people claim that task based roles are better for SOD's but in general that is absolute nonsense because the important SOD is when it's allocated to the user. You could have a role for each transaction which would be perfect for SOD's but no good when you assign them all to a user. If you take a job approach then you will be going through the same SOD process, though the initial resolution and design with job based roles will usually take longer. On the flip side, my experience is that the maintenance overhead is lower but other experienced consultants who's opinion I value disagree with that.

From the job role approach, if you have consistent jobs from an Org Design point of view then this makes it much easier. In reality an accountant in company 1 will not do too much different than an accountant in company 2 despite what they tell you. There is nothing to stop you defining an "Accountant" job and taking a risk based approach on the differences in transactions that may or may not be used. If you have a well defined company organisational structure then you can use that as the framework for your jobs and work down from there.

Doing a job based design takes longer than task based to do it properly but has other benefits further down the line.

[thx4allthefish]

Everything Al wrote.

Plus:

I have been doing designing of concepts for rollout in other companies/countries for more than a decade now and I ended up preferring the job-based role design.

There are mainly two reasons for this:

1. I will firmy bind the role concept to HR-OM - by building up the organisational structure of the company in PPOME using organisational elements (for interitance of basis-roles, that all users need, like SU3) as well as positions. In the next step I bind the roles to the positions. I do this to avoid having to maintain on a single-user basis, since the operations I work in tend to exchange users from one organisation to another (e. g. Purchaser company A goes to help out in company B for 6 month and such - plus, we are having over 50 apprentices who switch departments every 2 month) - which would cause me to do user-maintenance on a daily basis and 8 hours a day, which I cannot afford (I have 1500 active users). In PPOME I can drag and drop the users from one position to another (or various others) assigning a valid-from/valid-to date to the assignment and let the daily BATCH-PFUD do the rest. I have this combined with a CUA.
2. Other countries. If you are facing a massive roll-out, please find out, how many countries will be covered and what is designed with languages. Will all have access in English to your central system, or will they be working in their native language? If native, please consider that you will have to translate the roles and titles to the native language in order to ease maintenance of foreign users = possible helpdesk for user-issues (passwords etc. in the foreign country or, if they send you a hardcopy of a SU53 in Chinese, they should be able to read the role name in Chinese ... not many of those people speak or read English). If you go for the task based role design, you might have one hell of a lot of translations to do ... since roles (titles) are created in the logon-language of the creator, you will face many many hours in transactions SE63.

Do not fix your gaze on derived roles or composites unless you have a clearer picture on what is going to be the organisational structure etc. Composites or derived is more of a tool - you can decide whether or which one to use after you have an idea of what you want to do.

If I can think of more, I'll be back

[HDSmith]

Thanks to both of you, your replies were very useful.

I have a little bit of time before the authorisations phase will kick off so it gives me some space to play around with the profile generator and think about things a bit more. I am leaning towards the job-based roles at the moment as I feel that going back to task level profiles would be cumbersome to maintain in the future and result in alot of profiles in the system.

Just wondering - if I went for job based roles and there was an instance where you had 5 purchasers for example, 4 of them had exactly the same job role, but the fifth had an additional couple of transactions to the others for some reason. How would you tackle this ? My first thought would be to check whether the extra transactions are a business risk to others, if not I would include this in the purchasing SAP role and the other 4 users just simply wouldn't use it even though they technically have access.

But if I had to add an extra transaction to someone and them only, would you just create an individual role for that particular transaction and then assign it to the user ? I am just trying to get my head around how I handle these exceptions when/if they occur (I have been on projects before where they say that all jobs are identical - but then you get a BUT....)

I think alot of my questions come from the fact that I am not yet sure how all these companies operate (we're still in the blueprinting phase) - so once I have some more info from each of the module teams that may make it easy for me to make a decision.

Thanks again !

Helen

[thx4allthefish]

But if I had to add an extra transaction to someone and them only, would you just create an individual role for that particular transaction and then assign it to the user ? I am just trying to get my head around how I handle these exceptions when/if they occur (I have been on projects before where they say that all jobs are identical - but then you get a BUT....)

Basically, I am going this way ... in a way. Since I use HR-position-based role assignment, if the differing transactions were business critical or sensitive, I would create a separate role which I would attach to a new position. I would then assign the user to that position (in addition to the one s/he already holds). I would do this only if I lost an argument with management.

There are, however, rules for me: I fight everybody who does not adapt to the thought, that a role should be a system-technical mirror of a job-description like the rest of the SAP applications are a reflection of a company's business processes. If the said transactions, whilst still business critical or sensible, would be part of the job-description 'purchaser', I would start to argue that they should go into that role/job description - because: if the one individual granted access to those, falls out of the window, gets eaten by a dragon or something - who, please would take over? etc.

Thankfully, I am good at arguing in this here company (since 2003, 1500 users) I have only about a dozen users that hold more than one position ...