Lately I've had occasion to talk with some of the early adopters of our new user provisioning toolset, including both people submitting the requests and role approvers who have received access requests for their approval. Activity in the toolset is picking up, due at least in part to staffing reductions. After the dust has settled, someone still has to approve time and expenses, as just one example, and if time keepers were being utilized but were let go, a decision has to be made to either name a new time keeper or allow personnel to enter their own time, all of which can entail changes to users' security in the production client. Requisition and purchasing release authority levels may need similar reviews.
I am seeing new concerns about extending access such as time entry and time approval to additional users. One role approver explained her reluctance to approve such role requests; apparently time was being entered incorrectly by some users, either by mistake or intentionally, resulting in payroll changes that had to be backed out and corrected, which I could envision as a burdensome process to be sure, and potentially high risk if time was intentionally entered inaccurately. Someone who was terminated who never entered vacation time taken could result in a large fraudulent payout of accrued vacation pay.
Many questions came to mind: Had the users been properly trained on both time entry and time approval? Are the time entry results being properly reviewed for anomalies before the payroll run? Are supervisors ensuring that absences are being recorded accurately before the time is approved? How many of the people who were trained on the oversight and monitoring procedures have left the company, whether voluntarily or involuntarily? In short, who is left minding the store?
Every time we consider a security role redesign, the issue of acceptance of risk comes up for discussion. Certainly there is no one-size-fits-all answer across organizations, sometimes even across business segments within an organization. Management has to decide what risks are worth accepting and take steps to mitigate them through monitoring or other controls. I remember a long-ago discussion with our then-corporate controller, who has since retired. He spelled it all out in an effort to prevent confusion among the key stakeholders: the company had made the conscious decision that most users will have more access than they need to do their day-to-day jobs. If users are doing things in SAP that they are not authorized to do, they must be counseled and, if it repeats, disciplined up to and including dismissal. Certainly high risk access should be appropriately restricted, but he deemed it unreasonable to expect security to prevent every possible mistaken entry and negative consequence. If security was locked down that tightly, the company would need an expensive army of security analysts to build out individualized roles for our 50,000+ production users and another army for all the role assignment changes.
Several years have passed since that discussion, and no doubt, some of the people who understood the importance of management oversight and monitoring are no longer with the company. I suggest that changes of staffing levels should prompt a review of not only access levels, but also the controls, and my hope is that such a review is already underway in organizations that have had lot of staffing changes. Personnel newly charged with supervisory oversight, monitoring, and approval may require an overview of the controls environment, so that they understand the critical role they play in having the SAP landscape produce accurate data and compliant financial statements. My recommendation is cautionary: just don't think that locked-down SAP security is the only tool in the shed. Managerial oversight and monitoring can also be important parts of a successful controls environment, but only when regularly and conscientiously exercised by well-trained personnel.
