This website is not affiliated with, sponsored by, or approved by SAP AG.
5 posts • Page 1 of 1
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.
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.
Everything Al wrote.
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:
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
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 !
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 ...
5 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests