Question:
Hello,
I am trying to put together numbers for a managment presentation on SAP Security adminsitration headcount, I wondered if you could help provide some numbers from other companies.
I am looking for numbers of users, complexity of environment (systems, clients, modules, roles) and number of Security Administrators carrying out production support.
3 production support FTE's for...
R/3 (14 clients)
- 5400 users
- FI/CO/SD/MM/PP/ (includingHR)
- HR (51 master, 3000 derrived)
- master & derrived role concept (184 master, 7000 derriveds)
BW (4 clients)
- 2500 users
- Web reporting/Portal integration
- 115 composite roles, 215 single
- restriction to hierarchy nodes
Any information you can provide to help me make some estimates would be much appreciated, if you post a response and would like my consolidated numbers please leave me a note.
Rgds
Paul
Answer:
Depends on the level of expertice of the administrator. anywhere from 1 to 3 would be required.
However your specification you listing would indicate you need to streamline you roles and rethink your Security strategy and further minimize your maintenance.
You would be furhter ahead having one role per person.
5400 users
7000 derriveds role plus 3000 HR roles?
Answer:
Paul, I will send you our stats in a private note...
John Jarboe,
I am unsure how some of us can possible streamline our strategies, when we did not devise them, nor are we at the level to influence the business owners who required them in the first place. The roles must functionally separate what our customers want separated, or SOX says must be separated, and then we must organizationally separate based on our business requirements as well. HR requires that I separate by personell area and by org unit, there for, I have 25 derivations of every role, plus structural auths for org units. Suzy in Houston gets 3 derivations of every role her position allows, and Freddie in DesMoine gets 4 derivations of every role his position allows, etc. The owners of MM and PP ask that I derive their roles by plant. I have 30 plants, and 15 MM/PP roles...the math gets nutty. SD wants them done by Sales Area, etc. I also have had to create some custom stuff for billing blocks, delivery blocks, contracts, BOM auth groups, etc.
Any feedback you can provide on alternative models would be greatly appreciated. We have inherited a complex model, and can't negotiate our way out of it. On the flip side, the business isn't too keen on supplying the resources to support it.
Answer:
Paul:-
As John says - anywhere from 1 to 3 BUT I would say never 1 because you need holiday/illness cover so that points to 2 at least. This assumes a stable system with minimal changes - it is a base point only. If your system has only recently been implemented there's sure to be a surge of "O is isn't how we thought" and this will undoubtedly bring requirements for change so an initial 'bulge' in numbers may well be needed. Similarly when/if the business re-organises additional security people may be needed. I believe the general principle should be to keep the number of people with system security access as low as possible so that consistency and control can be maintained.
McGuest:-
There's no easy way to make amends when a complex security structure has been inherited and when the business doesn't want to invest in the effort. You can only plug away at the system 'owner' or 'module owners' with such things as what effort it takes to make a 'simple' change accross the complexity of Roles and try to get them to understand that if structured better, Roles could be maintained in less time and with less people (= money and efficiency savings). Or if because of the complexity there are sometimes errors when making changes - use this to get (say) Internal Audit on your side to recommend restructuring. Additionally how possible is it that the very complexity of your present structure may actually result unwittingly in breaches of normal segregation of powers in SAP. It is worth making the effort and being a pain now 'cos you'll surely be in trouble if/when the system is upgraded.
Best of luck to you both.
Answer:
Thanks.
What we have found is that due to the global nature of our company, we create derrived roles for countries however they are not neccesarily needed. This is beacuse role assignments are processed by our Help Center so by having these roles created in advance, if a user needs them it is available.
We are now having to break our master roles down due to SoX issues which is adding to complexity.
If anyone else is willing to share the numbers they have experienced it would be much appreciated.
Rgds
Paul
Answer:
Streamlining your processes IS your responsibility and is the add-value you deliver to the company, level has nothing to do with it sound cost-to-benefit rations and supporting data reigns ( how do you expect to GET to a highr level if you are not improving processes) inheriting a mess and living with it is still a mess. Custome WANTS are not at issue nor should they be entertained, SOX and Risk assessment does.
Any contol must first meet risk based analysis, private data concerns and governmantal requirement. nothing more.
I recently assisted a company with much the same mess and they have gone from 1400 roles to 37, yes it helps to have a business champion but that is your responsibility to "sell" the need.
Answer:
Hello All,
I would like to add couple of points to this discussion by agreeing with the responses from others.
I strongly feel that the number of security admins required for any SAP security landscape to be maintained will depend not only on the SAP landscape (systems,cleints, modules and users) but also on the status/ stage of current SAP security practice.
'Stage/status' is the compliance to certain standards (if your company is PUBLIC listed in US, then SOX compliance).
What I am trying to say is if you are planning for SAP security redefinitions/reimplementation, you may definitely need more resources.
As per my past experience in SAP security redefinitions, you definitely need 5 full time admins for 6 months (again it depends on how you plan to redefine the security like R/3 first and then BIW etc).
If it is just PROD support - regular issues like user master creation, role assignment and issue fixings, I think 3 admins definitely required with almost 8 Hrs (or even more) of continuous work load. (1 for BIW and 2 for SAP R/3)
Again it depends on the approval policy and procedures you have.
Hope I made myself clear to you.
If you need further details or docs on security definitions, please feel free to write to me.
Regards
Rokkam
Answer:
As per my past experience in SAP security redefinitions, you definitely need 5 full time admins for 6 months (again it depends on how you plan to redefine the security like R/3 first and then BIW etc).
If it is just PROD support - regular issues like user master creation, role assignment and issue fixings, I think 3 admins definitely required with almost 8 Hrs (or even more) of continuous work load. (1 for BIW and 2 for SAP R/3)
This is where it gets murky, I have recently worked on a redesign project to get a company SOX compliant, we had 3 FTE's on security for a couple of months servicing a user population of 16000 covering R/3, BW, APO, SEM, CRM.
That goes down to 2 FTE's in prod support with Basis admin as contingency for user mapping.
On the other hand I did some work where there were 8 FTE's just suooprting a population of 4000 users & we were rushed off our feet.
It all comes down to successful role definition. SOX does not mean you need to split your roles into component parts & create more admin, it means your design should reflect what are generally good risk management principles. In the last 12 months, the firms I have seen with major SOX issues have been those who didn't do their build properly in the first place.