In this blog I want to share with you the recent experiences we had with a customer who had issues with the security authorisations in their SAP ERP systems. The client had implemented multiple modules in SAP R/3 4.6B sixteen years ago. During this period there were several changes that negatively impacted on their ability to maintain and manage their SAP authorisations model:
- The systems underwent upgrades to R/3 4.7 and then ERP 6.0 without any explicit analysis to examine the impact of the upgrades on the model and associated authorisation roles.
- During the upgrades the roles were subject to very limited testing and, when issues were encountered, very wide ranging access was granted to allow the upgrade projects to remain on-schedule.
- The evolving business structure of the customer was not reflected in the authorisations. Thus, role naming conventions were inappropriate, role assignments were confusing and inappropriate levels of access were granted to individuals who worked across multiple departments.
- No use had been made of new authorisations functionality made available in SAP R/3 4.7 and SAP ERP that aimed to simplify the creation and maintenance of an SAP authorisations model.
- Very little documentation existed that described the purpose of each role and the access granted. This led to business users approving inappropriate levels of access to their team members when additional access was required.
We placed a technical consultant onsite for a short assignment to work with both the business and IT to gain a full understanding of the issues affecting the assignment SAP authorisations, the maintenance of SAP authorisation roles and the governance of processes for new starts, internal transfers and leavers. We documented the existing processes and also gathered hard statistics for users, roles and role authorisation role changes.
As an output we delivered a document that recorded the existing processes, the issues and risks and our recommendations as to how to efficiently address the areas of concern. The document was written in plain English terms in order that the findings could be made available to a wider business audience. This allowed our customers Internal IT team to engage effectively with their business and to receive support, both financial and testing resource, for a follow-on exercise to address the main areas of concern. The document was seen as a crucial enabler for the discussions between IT and the business and it’s accessibility to a non-technical audience helped the business to understand the value case for investing in the follow-on corrective work.
With approval from IT, and buy-in from the business, we proceeded with a joint exercise with our client to design a new authorisations model. This was deemed the most appropriate approach given the collective issues with the existing authorisation roles. The customers’ business was structured in such a way that we could approach the redesign on a business function by business function basis with consideration given to common access requirements across all modules.
We ran a series of workshops with support personnel and key users to establish the access requirements across each model. A series of matrices recorded the access requirements mapping the transactional access, access types and underlying object access to groups of users performing common functions.
The access was reduced down to a granularity that balanced:
- The ability to provision the minimum level of access users required to perform their jobs effectively, against
- The minimum number of roles to reduce the ongoing role maintenance efforts
This process was repeated across all business functions and an overall authorisations model produced. Where appropriate we made use of structural authorisations, composite roles and reference users to ensure the model and its technical implementation was as efficient as possible.
The model design was documented as the project progressed with documentation for each role also being produced to enable the business to correctly assess the whether each role was appropriate for assignment to new starts and internal transfers in future. Of course, documentation of this nature can date as soon as it is produced so we adjusted supporting procedures and quality checks to ensure that future technical changes are accompanied by documentation updates.
With the role design finalised the client proceeded with creating the individual roles of which the model was comprised. Absoft were happy to take an advisory role for this task as it built up the client’s familiarity with maintaining their roles and their associated documentation. Where specific issues were encountered we would take a hands on approach and assist the client ensuring that their own personnel gained from our knowledge along the way.
The project moved into a period of quality assurance testing and the business users became involved to ensure that the roles were fit for purpose. The testing ensured that users were able to access the required functionality as well as ensuring that access was not granted to transactions, activities and data that was not appropriate. The key users worked with the users who were responsible for approving new access to ensure that they were familiar with the model design for their area and that they fully understood the implications of assigning individual roles as well as the implications of assigning groups of roles. To verify that the model as a whole did not grant any unintentional sensitive access we used an Absoft developed segregation of duties tool to ensure that sensitive transactions, and sensitive combinations of transactions, were protected.
The cutover to the new authorisations model was planned and implemented over the course of a weekend with key users involved to perform verification tests over the course of the weekend. Additional support was made available for the first days of the new model implementation but very few issues arose which is testament to the efforts that were put in to the design and testing phases of the project.
The key takeaways and learning experiences from this project were:
- Obtaining the buy-in from the business was essential to the success of the project They were equally invested as our client’s IT organisation and the project successfully delivered tangible benefits to both groups with a model that provisioned appropriate levels of access to all users, that was understood by those that owned it and that would offer reduced maintenance costs going forward.
- Translating the technicalities of the authorisation model design into a language that was easily accessible and digestible by the business community accelerated their understanding of the project and allowed them to become engaged and invested at an early stage.
- Teaming an Absoft technical consultant with the clients own IT staff allowed both groups to benefit from the experience of the other. This reduced the time to complete the project and allowed the client to perform many of the tasks themselves which increased their understanding and reduced their costs.
For more information about the topics covered in our blog, contact Absoft today via: info@absoft.co.uk or T: +44 1224 707088 to speak with our SAP consultants.
