Sometimes you have an idea that resonates with others but you do not realize the complete requirements until you have exactly what you asked for. Such is the case when GRC Access Control 10 was being developed. I made a request to have the SAP user statistics data summarized into GRC Access Control along with some analysis reports. At the time SAP supported an older process of Reverse Business Engineering (RBE) functionality which we used to support multiple metrics. These reports included inactive transactions, unused roles, transactions most used, and more. Later our business provided requirements using the RBE data to automatically remove roles when a user had not executed a transaction within a role for a specific number of days. We also used this for our quarterly user access review and SOD analysis to determine if roles were no longer relevant or if an SOD violation could be resolved through the removal of an inactive role assignment.
To perform our consolidated user access review we manually exported the RBE data into a Microsoft Access database from each individual SAP system. Some companies also do this by sending the data directly into a BW InfoCube. Once we had this consolidated data we could fulfill the user metrics and related reporting requirements. Since the SAP statistics data is summarized into monthly periods, we only performed this process once a month. Although the batch jobs were scheduled to create the RBE data files, there was still a day of work to summarize all of our production systems into the Access database.
With the enhancements coming in GRC 10 and the delivery of several of our influence items, we built a business case to become a GRC Access Control ramp-up customer. Fortunately, SAP delivered the Action Usage functionality which imports the transactional activity into GRC Access Control. This was exactly what we asked for but, unfortunately not the best solution. We started out performing the same process of exporting data to MS Access but only from GRC.
SAP scheduled a follow up meeting to see how we liked the new functionality. We shared our metrics reporting, user access review process, role metrics details and SOD reduction efforts. Having consolidated data helped us but it was not the best long term solution if we still needed to perform processing in MS Access. We documented detailed requirements and these were delivered in GRC 10.1.
I now sympathize with our business users who provide us functionality requests. Sometimes you do not know phase 2 requirements until you have actually used a system. In the past I have prototyped solutions before documenting the requirements. Sharing story boards and high level process flows would have been helpful here. Once you have an improvement idea, you need to take the next step and document the requirements. When someone only has an idea it leaves room for interpretation. When there are detailed requirements, there are tangible deliverables. Now that we have been using the Action Usage process for multiple GRC processes, additional requirements are being noted.
Across the many GRC 10 and 10.1 implementations there must be other customers that also use the Action Usage data. What are some ways that you are currently using it? Do you use it for UAR? Remediation of SOD risks? Validation before applying a mitigating control? Forensic activity? If you are using this data, how would you improve the process? What reports or functions do you think still need additional development? I am looking forward to your feedback.
