Many customers have been looking for the magic formula for their SAP Security Design. How can we give what is necessary but avoid Segregation of Duty conflicts and lots of maintenance work? This seems to be the magic question. This customer has tried many routes. The first was to use the SAP delivered roles. Certainly these have been developed with some insight to common tasks used by many companies. However, much to their surprise, these were quick and dirty roles developed to get quickly over the security hurdles in an implementation. As a result many SoD violations exist and in many cases the roles contain excessive access and make the maintenance process even harder.
The next magic formula sought out by this customer was to set up common job related roles. The idea was to match the access performed by people in the same job area so one role could be utilized by many people performing the same job. However over time many jobs are the same however, the activities often vary by person. There are many people who maybe assigned a job but get variable assignments for special projects or ad hoc activities as they arise. The standard role gets modified to meet these requirements and slowly but surely the number of roles grows because a special role is built for these situations to accommodate the individual needs. While some of these could be made a part of the standard role, many times they are unique and not appropriate for others. As a result, role creep sets in and now special activities or one-time assignments make the roles unique to the user. And the number of roles grows and grows and often gets to be more roles than users to maintain. Access limits may also make the roles different by job for the company codes or plant limitations that need to be added. One popular trend was to make a separate role for each plant or company code. Then each role was added to a person’s standard roles rather than making them unique to the users in that area. This has proven to be very complicated for some companies and creates some segregation of duty discovery issues.
The final approach taken was to have the business areas identify the major tasks that needed to be done and then organize roles based on the tasks the users needed. Many of the tasks could be equivalent to one transaction. This provided a lot of roles and the selection process for managers and users required quite a bit of training and intuition to make sure the right ones were selected for new users.
When the customer described their problems, there was a consultant ready for the answer. And after spending over $1 million, what the customer concluded is there are no “silver bullets” to solve these issues. There are just solid processes that need to be followed to create, change and test roles. And in most cases there wasn’t one right way, but a combination that was required.