My understanding is that SAP user roles are difficult to design properly, and the review of user authorizations and access rights is equally challenging. I thought that I could use analytics to identify instances where a user had performed transactions that constituted a potential separation of duties (SOD) issues in the FI component and support management in their reviews to identify roles that were not designed properly. The analysis utilized an Excel file (SOD Matrix) which listed thousands of incompatible TCodes (e.g., Enter outgoing customer invoice (FB60) and enter journal entries (FB01) to conceal them). I also enhanced this analysis to include searching for cases where a user employed two or more User IDs (duplicate user Ids) to perform incompatible duties. I hoped that management would see this as a valuable tool to use as part of their ongoing monitoring of user roles.
The analytics were fun to develop and worked as designed: identifying transactions where users had performed incompatible actions based on the SOD matrix list. However, this is where my problems began. Management didn’t see the value in the analytics for several reasons.
Management understanding of the potential issue. First, they want to know if any users had ‘entered’ the incompatible combinations or were just able to do so. Given that I was analyzing actual transactions, the obvious answer was ‘Yes.’ Once we got past the notion that the analytics identified real transactions not just the ability to use a TCode, the next question was, “Did they do anything wrong?” I will work on developing analytics which identify specific cases where incompatible TCodes were used for the same customer and within ‘X’ days, for example, but my concern is that the user role, as designed, allows the user to perform incompatible actions that could be fraudulent, whether they have done so or not. The fraud triangle (Pressure, Opportunity, and Rationalization) identifies the lack of separation of duties as an increased fraud risk. The ability to enter incompatible TCodes presents the user with an opportunity to commit fraud.
Management trust in user roles. Management stated that the user roles allowed the users to enter the identified TCodes, so it was OK. This was particularly disturbing because the purpose of the analytics was to assess whether the user roles were designed properly (or not). Of course, the user roles allowed the user to enter the TCodes, if not we would have a much bigger problem, but management should be considering whether the roles should allow them to do this. Also, what about users who were using two or more User IDs to enter the transactions – which implies they have two or more roles.
Management challenged the criteria. They stated that the combination of TCodes was not an SOD issue. I fully agree that management is responsible for the design of controls and that if they believe that a user entering certain TCode combinations, for example FB01 and FB60, is not an SOD issue then I will accept that. However, just because they do not see FB01/FB60 as an SOD does not mean that they should discount the value of the analytics. Monitoring the SOD results would allow them to ensure that other incompatible TCode combinations were not occurring or that the users with the ability to enter these combinations of TCodes should be able to do so. (Note: it did not help that I could not remember where I had obtained the SOD matrix.XLSX file. If you have a valid source for SOD TCodes please let me know).
Early in my career I was told that the sender of a message is responsible for how the user receives and interprets the message. I did not understand or believe this initially, but I do now. Therefore, I did not do an adequate job of explaining the intent, use and value of analytics as part of an ongoing review of SOD issues. Management was too focused on whether it made them look bad or did not understand the issue. I had a similar problem with duplicate invoices. Management stated that they had recovered the money, so it was not a duplicate payment. My purpose for identifying duplicates was to identify control gaps that allowed invoices to be paid twice (weak preventive controls). Recovery of duplicate payments too effort and in many cases relied on the vendor to inform us that they had been paid twice. Improving the preventive controls was easy once you knew where the gaps were and how to address them.
Lesson-learned – analytics are only of useful if management (or the client) sees the value of the results and if they help them make better decisions. No matter how complicated, elegant, or interesting the analytics are to the developer, the ultimate user must see them as worthwhile.