Managing “Exceptations”

So far, we’ve talked about how we got in this compliance position and started to discuss how we get out of it. Now, we need to dive into some of the things that can get in your way.

Whenever we talk about process, it’s generally pretty easy to work through the details of what should happen. As I mentioned in the last article, the key to developing processes is understanding the inputs, understanding the work to be accomplished and understanding the output is and how it will be used. In addition we have these things called exceptions. By far, these are the most difficult part of process management – both because exceptions tend to challenge our notions of how to do things right, and because they are the source of most discontent when developing processes.

First let’s set the stage over why exceptions are so important. Simply, healthy processes generate healthy outcomes – and exceptions have to be part of the process in order to have equally healthy outcomes. You can think of processes in much the same way you think of a production line. Each station on the line expects to receive specific input, perform a specific piece of work and pass that on to the next station in the line. But what happens if the input is bad? If we haven’t planned for the input possibly being bad, we either produce a bad product or we delay production while we stop the line to address the issue. Unplanned exceptions create unplanned work, and unplanned work often turns into poorer quality and/or more expensive work.

Detecting exceptions is generally pretty easy. At each decision point in the process, you want to note the applicable business rules and possible directions the work can take. You reach an exception during this process when you can clearly call out a separate instance where the business rule does not apply in the same way. For example, if all widgets are checked for quality and discarded or sent down the line except blue widgets, then an exception exists. Once you have the exception noted, go back and reevaluate your process to ensure there is no better point to have the decision about the exception made. Continuing the widget example, if the next step creates exceptions for yellow, green and red widgets, perhaps I need to move the process of determining the color of the widgets to a different point on the line.

Start by understanding the difference between valid and invalid exceptions. For example, lets say you’re developing a change management process. The goal of the process is to ensure changes don’t introduce problems or destabilize the environment. Often change management uses some form of peer review to validate the appropriateness of the change. However, one valid exception may exist around the amount of time necessary to review an emergency change. The questions you have to pose include understanding what risk this exception creates, and how do you prevent the exception from becoming the de facto process? To do this, we want to consider the use of compensating controls. Compensating controls are designed to make up for the lack of a normal control. In this case, we want a compensating control which ensures the process won’t get abused. So what if we had to have CIO (or higher) sign-off on emergency change controls? In many cases, the number of emergency controls would diminish significantly. Developers would need to plead their case to the CIO and the CIO would take responsibility for the implementation. Compensating controls often revolve around using an increasing level of approval instead of the normal rigor.

Now that you know your process and your exception management practice, you should write them down! To often, I’ve seen organizations scramble to put together a document for auditors defining how a process works and the end product isn’t really ready for presentation. Since you’ve just completed 80% of that effort in defining and understanding the process, documenting it seals the work up and provides you something in the event you are undergoing an audit. We’ll talk more soon about what you want to include in a process document.

In the end, managing exceptions is a delicate balance. Exceptions often end up addressing critical components to an environment – either in a business or technical sense. We don’t want to shut them down, because that hurts the business in the long run. At the same time, uncontrolled exceptions can significantly disrupt normal operations, which also hurts the business. The best thing we can do is plan for the exceptions and how they will be managed to minimize impacts and gain the value maximum value from the exception itself.

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.