The Devil's in the Details

So, how do you analyze processes? How do you make something that works without being cumbersome?

From a governance perspective (and really, from a data security and efficiency perspective as well), you want processes which are as simple as you can make them. Remember, you're here to run a business not create a bureaucracy. The best way to run an efficient business is by using efficient processes. Analyzing a process comes down to really four basic elements which you need to understand and organize; 1.) Inputs. 2.) Work to Accomplish. 3.) Outputs. 4.)Exceptions. At the core, the issue that tumbles most processes comes from how exceptions are managed. We will look more at managing exceptions in our next episode.

Putting this into action with the issues I described in my last entry, we can start to create a more comprehensive approach to addressing our audit findings. First, as I pointed out previously, we need to stabilize our patient. Whatever the specifics of the issue, you need to gain immediate control of it. In my case, that meant working through all the user ID’s to understand which users had access that shouldn’t and performing the normal work steps to change their access. I absolutely enlisted help (and when you find yourself dealing with audit issues, getting help usually is pretty easy… tell management who you need and for what, and you usually can get them or a substitute). The business analysts responsible for each business area worked with me to determine who should (and should not) have access to each functional area within the ERP application. We worked together to get change controls filed and the access changes made. We worked with the system administration staff to ensure admin access rights were limited to a single account. In otherwords, we brought immediate (if costly) order to the environment and addressed the issues top on the auditors checklist. I say costly because this sort of emergency remediation detracts from other work people would be doing. Its unplanned and urgent and makes us look like we don’t know what we are doing. Okay, truth told, at the time I didn’t. I was winging it. But, I knew I never wanted to be in the same position again.

Once we had issues nailed down, we needed to make sure they didn’t come up again. Process by process, we went through the details to understand what went wrong. In the case of the terminations, we found we didn’t have the right inputs – the operations team didn’t know when someone was terminating . We worked with the HR organization and found they were anxious about releasing termination information because of previous breaches of trust by another part of the organization. As a group, we developed a new ethics code for our operations staff that clearly addressed HR’s concerns, who in turn agreed to provide termination information to operations. 90 days later, we reviewed where we were at and found we had successfully managed the termination of almost 50 people without error!

Access creep issues (where people move departments and keep both their new access and their old access) can be tough to manage. In our case, we didn’t really have a process, so we had to start from scratch. Using our four elements of process design, we determined that we needed to have an authority regularly review access to functional areas of the systems and from that correct the access. Our input to that process would be a list of everyone who had access to each functional area of the application. Our process would e a monthly review of access by the functional area business analyst. Our output would be a list of users with greater than expected access, which would then be used as the input to a second process to determine if the user genuinely needs that access and if so how to incorporate the result into a functional role in our access hierarchy. Again, 90 days later (after a couple of initial glitches) and we had identified a small group of users with significant access, but also determined it was appropriate for their jobs, so we ended up creating new access roles to cover these folks – which protected us later if someone asked for Joe to be set up the same as Amy, and made sure we captured what this access profile looked like in the event Amy up and left.

In both these cases, we modified or build a process based on the four elements – we determined what inputs were needed, evaluated and created procedures for each of the work elements which had to occur, determined what the final outputs would be and where appropriate we handled the exceptions – in these cases the exceptions were inputs to another process. Each process is kept simple and easy to follow. This modularity allows use a greater degree of freedom, because we always know where one process stops and the next begins. These processes are easy to document and demonstrate, and the next time the auditors show up we have an easy way of demonstrating what we do, how we do it and what the results are. That’s called transparency, and let me tell you from my own experience an auditor who comes in and sees this level of materials – mind you kept simple and straightforward – will be much easier to work with and much more likely to keep an open mind working with you than one who sees a sloppy environment with little or no accurate documentation.