Odds are, when you started this whole compliance thing, you did so because you “had greatness thrust upon you.” You got pulled in because auditors found problems with IT and you had to address it.
Further, odds are the errors they found were in one or more of the following six areas: User Access Management, Change Management, Code and Release Management, Configuration Management, Resolution Management and Service Level Agreements. Sure, there are lots and lots of places problems can come up. There are lots and lots of things auditors look at. Certainly some of their findings will be in other areas. In the main though, the vast majority of the issues we see come in these six areas.
I don’t believe this is an accident, either. If you’ve ever been in a shop that can’t manage their users, struggles with managing change, have troubles with stabilizing their configuration, creates “one-off” solutions via development or has poor resolution and service level agreement standards, you know how painful it can be. The business is probably beating IT up day in and day out over these issues. IT struggles to gain and maintain credibility. New projects don’t get approved because the business doesn’t trust the IT organization to deliver. In the worst of these cases, people start looking for silver bullets in the form of reorganizations or outsourcing. These audit issues simply confirm for the business and the Board of Directors, IT doesn’t know what its doing. But is that really true? No, of course not, but it’s certainly an easy conclusion to jump to if you don’t know any better.
A 2007 study by the IT Process Institute (www.itpi.org) found that well defined controls in these six areas correspond to predicting the top performing IT organizations, and that the lack of these controls conversely predict the lowest performing IT organizations. When we talk about performing, we’re not just talking about getting the job done – we’re talking about radical, bottom-line differences between the high and low performers.
The difference between the high and low performers, again according to ITPI, is enormous. High performing organizations manage and deliver on more projects with fewer staff. They manage a significantly greater number of servers per administrator. They experience fewer outages and return to service more quickly when they do experience outages. They deploy changes more effectively. They are better, stronger and more agile than their low performing counterparts.
For practitioners in compliance and governance, this has a very real implication – we can drive the organization to deliver higher value at a lower cost while making it more compliant and more agile. Holy cow! Think about that for a minute – If I came to you and said I can cut your costs, improve your performance and make you more agile as an organization for a limited investment of money and a willingness to address cultural issues, and could back that up with studies demonstrating what I’m saying, how would you react? More importantly, how many organizations would walk away when that proposition is on the table?
But how much value, you ask? Let’s take just one area noted above. Jack Keen and Bonnie Digrius, in their book Making Technology Investments Profitable, determined a typical public enterprise could boost share prices by 3% simply by improving the rate of successful project delivery. Translated into terms we all can understand, this seemingly meager amount, for a company with a $2B market capitalization, results in $60M for the corporate investment coffers. This massive boost comes from the accelerating cumulative effects of successful control. Deliver more projects that improve the products and overall business in a shorter period of time and you’ll create more value for the organization.
Over the next few installments, we will develop a roadmap which can help take you from being a cost-center compliance organization to a value generating governance organization. We’ll start by looking at what each of these controls mean, what they do and why they are important. Then, we’ll explore how you can bring them into your environment and make them a living, breathing part of your organization. It’s a fun ride.
Friday, November 2, 2007
Wednesday, October 17, 2007
Yes, but is it any good?
Process Management is the application of knowledge, skills, tools, techniques and systems to define, visualize, measure, control, report and improve processes with the goal to meet customer requirements profitably.
~Wikipedia Entry for Process Management, October 2007
In the last two installments, we’ve talked about how to analyze and create process, and how exceptions play a major role in processes. Now we need to ask ourselves what it takes to make a good process.
At the core, a process is about creating a reliable, repeatable outcomes. To do this, we need to develop a good process, certainly, but what else needs to happen? Well, staff needs to use the process and find it makes their lives easier and less disruptive. This is a case where both the “carrot” and the “stick” can be utilized to get the desired outcome. The “carrot” is in streamlining the process down to only the most necessary activities to achieve the desired outcome. That is, reducing the work on people’s plates to give them more time to focus on valuable activities. If your processes create bureaucracy, people will find ways around them. In some big environments, I’ve seen an almost underground economy of favor trading and process dodging emerge because the stated processes were too burdensome to be effective. Once your processes have been appropriately “right-sized”, though you can start considering the “stick” side of the equation – meaning that at some point it becomes necessary to attach consequences to not adhering to processes. The simplest illustration of this comes with the speed laws on the roads. If you knew there was no one monitoring or enforcing the laws, how likely would you be to consistently follow the law? Safety and conservation aside, most people would be screaming down the road as fast as their engines could carry them. If management practices within your organization don’t address (or worse, subversively encourage) ignoring procedures, then your problems run deeper and you’ll need to work with other parts of the organization to implement broader cultural change. We’ll talk about that further down the road.
To “right-size” the process, we need to look at several elements. Though there are many questions you can ask about a process, some of the most important ones can be summarized: Is this the best place I can put a process to get the outcome I need? Is there a place closer to the input that I can place this activity? Do I understand all of the required inputs to the process and how they will be used or transformed by the process? Do I understand who uses my output and how? Have I made the process as simple and straight-forward as possible? Do I understand the exceptions to the process? Could I explain the process to someone who doesn’t understand the specific details of the work I’m doing without going over their head? Have I cut out elements of the process which don’t make sense, don’t specifically deliver on the intended outcome or which consume resources without adding value?
Like any project, the goal of our processes is to deliver a product which is of good quality (a healthy outcome), which can be executed quickly and at the lowest possible cost and/or highest possible return on our investment of time.
Okay, here comes the “boring” part. To work this stuff out, you need to start by creating a process flow. We’ve talked enough about this in the previous installments, but lets go over it once again just to make sure – start with your input, and proceed through evaluating each decision point that occurs in the process. You need to begin critically analyzing these decisions points. Do they have all the necessary inputs? Does the result directly lead to or assist the development of the desired outcome? How long does it take to resolve each step? Why does it take that long? A good way to get this information is to go right to the people responsible for executing the process and talking to them. Have them walk you through the process. For that matter, do the process a few times yourself so that you understand exactly what the folks have to do. This is important, because often the processes an organization uses contains hidden steps, which are only revealed through this practice of getting into the trenches. Those hidden steps add up pretty quickly in terms of bureaucracy and time consumed, so understanding why they are there (are they actually hidden requirements, for example) helps in engineering a more effective process.
Now, you’ve worked through your process. You understand the constituent inputs, outputs, processing steps and exceptions. You know who gives you input and who uses your output. Now what? Measure it. You will need to establish some methods of ensuring that the process is doing what you want in the timeframe that you want. This is accomplished by establishing some key metrics to regularly evaluate the outcomes. For example, let’s say one of the processes you are developing revolves around resolving help desk cases in a timely fashion. To do this, you’ll need to define what timely looks like, then measure your outcomes against this criteria to see how you’re performing. Establishing these metrics may very well involve more than just your part of the organization. How long should a customer wait for a help desk case to get resolved? If you’re answer is “it depends”, do you think you would benefit if the customer had a say in the matter?
Over the last few installments, we’ve talked about establishing emergency solutions, getting them up and running and functioning in the way you need them to.
But the road doesn’t end there. Actually, its just the beginning. You’ve tackled the “C” in GRC – Compliance. Compliance is the first step to developing a truly world class IT organization. The “R”, Risk Management, and the “G”, Governance, are also key to creating and maintaining a powerful IT organization that delivers value to its customers. The next series of installments will discuss taking your compliance efforts a step further to help your organization manage risk and improve overall performance.
~Wikipedia Entry for Process Management, October 2007
In the last two installments, we’ve talked about how to analyze and create process, and how exceptions play a major role in processes. Now we need to ask ourselves what it takes to make a good process.
At the core, a process is about creating a reliable, repeatable outcomes. To do this, we need to develop a good process, certainly, but what else needs to happen? Well, staff needs to use the process and find it makes their lives easier and less disruptive. This is a case where both the “carrot” and the “stick” can be utilized to get the desired outcome. The “carrot” is in streamlining the process down to only the most necessary activities to achieve the desired outcome. That is, reducing the work on people’s plates to give them more time to focus on valuable activities. If your processes create bureaucracy, people will find ways around them. In some big environments, I’ve seen an almost underground economy of favor trading and process dodging emerge because the stated processes were too burdensome to be effective. Once your processes have been appropriately “right-sized”, though you can start considering the “stick” side of the equation – meaning that at some point it becomes necessary to attach consequences to not adhering to processes. The simplest illustration of this comes with the speed laws on the roads. If you knew there was no one monitoring or enforcing the laws, how likely would you be to consistently follow the law? Safety and conservation aside, most people would be screaming down the road as fast as their engines could carry them. If management practices within your organization don’t address (or worse, subversively encourage) ignoring procedures, then your problems run deeper and you’ll need to work with other parts of the organization to implement broader cultural change. We’ll talk about that further down the road.
To “right-size” the process, we need to look at several elements. Though there are many questions you can ask about a process, some of the most important ones can be summarized: Is this the best place I can put a process to get the outcome I need? Is there a place closer to the input that I can place this activity? Do I understand all of the required inputs to the process and how they will be used or transformed by the process? Do I understand who uses my output and how? Have I made the process as simple and straight-forward as possible? Do I understand the exceptions to the process? Could I explain the process to someone who doesn’t understand the specific details of the work I’m doing without going over their head? Have I cut out elements of the process which don’t make sense, don’t specifically deliver on the intended outcome or which consume resources without adding value?
Like any project, the goal of our processes is to deliver a product which is of good quality (a healthy outcome), which can be executed quickly and at the lowest possible cost and/or highest possible return on our investment of time.
Okay, here comes the “boring” part. To work this stuff out, you need to start by creating a process flow. We’ve talked enough about this in the previous installments, but lets go over it once again just to make sure – start with your input, and proceed through evaluating each decision point that occurs in the process. You need to begin critically analyzing these decisions points. Do they have all the necessary inputs? Does the result directly lead to or assist the development of the desired outcome? How long does it take to resolve each step? Why does it take that long? A good way to get this information is to go right to the people responsible for executing the process and talking to them. Have them walk you through the process. For that matter, do the process a few times yourself so that you understand exactly what the folks have to do. This is important, because often the processes an organization uses contains hidden steps, which are only revealed through this practice of getting into the trenches. Those hidden steps add up pretty quickly in terms of bureaucracy and time consumed, so understanding why they are there (are they actually hidden requirements, for example) helps in engineering a more effective process.
Now, you’ve worked through your process. You understand the constituent inputs, outputs, processing steps and exceptions. You know who gives you input and who uses your output. Now what? Measure it. You will need to establish some methods of ensuring that the process is doing what you want in the timeframe that you want. This is accomplished by establishing some key metrics to regularly evaluate the outcomes. For example, let’s say one of the processes you are developing revolves around resolving help desk cases in a timely fashion. To do this, you’ll need to define what timely looks like, then measure your outcomes against this criteria to see how you’re performing. Establishing these metrics may very well involve more than just your part of the organization. How long should a customer wait for a help desk case to get resolved? If you’re answer is “it depends”, do you think you would benefit if the customer had a say in the matter?
Over the last few installments, we’ve talked about establishing emergency solutions, getting them up and running and functioning in the way you need them to.
But the road doesn’t end there. Actually, its just the beginning. You’ve tackled the “C” in GRC – Compliance. Compliance is the first step to developing a truly world class IT organization. The “R”, Risk Management, and the “G”, Governance, are also key to creating and maintaining a powerful IT organization that delivers value to its customers. The next series of installments will discuss taking your compliance efforts a step further to help your organization manage risk and improve overall performance.
Thursday, September 27, 2007
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.
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.
Thursday, September 20, 2007
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.
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.
Wednesday, August 8, 2007
Great, Now What??
Putting Together a Plan of Attack
In the last installment, we talked about a common way most of us fall into the world of governance, control and audit activities – through a bad audit. In this episode, we’ll look at the steps you should take to get the issue under control. First off, remember that this initial period is pretty stressful. You can go a long way simply by not letting them see you sweat. Oh, don’t get me wrong, you can sweat buckets, but you don’t want to do it in front of your management or their management. You have control. You have a plan.And that plan is pretty
straightforward. Ask yourself what you can do right now to correct the errors and exceptions that were found as part of the audit. Correcting issues demonstrates an understanding of the issue. It gets the “data” fixed and gives some assurance that another audit of the same materials would not be as painful. This is akin to stabilizing your patient. Once your “patient” is stable, though, the real work begins.
Why did the problem happen in the first place? At the core, most problem that lead to audit findings aren’t because people are unwilling or unable to follow directions, or be because they want to cause problems – even when people admit to working around the process. No, most problems are caused by bad process – the work flow that allows a particular work activity to be accomplished isn’t doing what it needs to in an effective, efficient or timely manner.
So how do you deal with this?
Process is, thankfully, a fairly straight-forward activity to get our arms around, but does take some understanding of the basics to feel comfortable with. Let’s take a case study of a problem I was presented with early in my career.
My organization had recently gone through an audit, and the CIO was in my cube wanting to know why we had so many problems with our user accounts. It was the first I had heard of the issue (I know, my bad), but I was determined to get ahead of the problem.
As we looked through the report from the auditors, we found a lot of issues with user access. We had users long departed from the company who had access to our ERP system. We had users that had changed departments, but who still had access related to their old job role. We had users with application administration privileges that shouldn’t even have access to the system. Obviously, something had gone wrong.
When we take a step back, we’re really talking about a set of processes here -- User Access Termination, User Access Transfers, User Access Creation and Appropriate Access Reviews. These four processes form the basis of most user access management controls. Somehow, these four processes weren’t doing what we needed them to do – manage and report on user access in a way that assures an effective control environment. Put in simpler terms, we couldn’t prove we had control of our environment, and the evidence demonstrated we didn’t.
So, how are we going to scope our work to be successful? For each of the audit points you are facing, you need to address the immediate data issues related to the specific finding. Once underway, you can then take a step back and start analyzing the process to determine what went wrong and why. For management, your plan for each audit point becomes very straightforward – gain immediate control, then deep dive to prevent the problem from occurring again in the future.
In the next episode, we’ll talk more about analyzing processes and creating effective controls to assure processes are doing what you need them to.
In the last installment, we talked about a common way most of us fall into the world of governance, control and audit activities – through a bad audit. In this episode, we’ll look at the steps you should take to get the issue under control. First off, remember that this initial period is pretty stressful. You can go a long way simply by not letting them see you sweat. Oh, don’t get me wrong, you can sweat buckets, but you don’t want to do it in front of your management or their management. You have control. You have a plan.And that plan is pretty
straightforward. Ask yourself what you can do right now to correct the errors and exceptions that were found as part of the audit. Correcting issues demonstrates an understanding of the issue. It gets the “data” fixed and gives some assurance that another audit of the same materials would not be as painful. This is akin to stabilizing your patient. Once your “patient” is stable, though, the real work begins.
Why did the problem happen in the first place? At the core, most problem that lead to audit findings aren’t because people are unwilling or unable to follow directions, or be because they want to cause problems – even when people admit to working around the process. No, most problems are caused by bad process – the work flow that allows a particular work activity to be accomplished isn’t doing what it needs to in an effective, efficient or timely manner.
So how do you deal with this?
Process is, thankfully, a fairly straight-forward activity to get our arms around, but does take some understanding of the basics to feel comfortable with. Let’s take a case study of a problem I was presented with early in my career.
My organization had recently gone through an audit, and the CIO was in my cube wanting to know why we had so many problems with our user accounts. It was the first I had heard of the issue (I know, my bad), but I was determined to get ahead of the problem.
As we looked through the report from the auditors, we found a lot of issues with user access. We had users long departed from the company who had access to our ERP system. We had users that had changed departments, but who still had access related to their old job role. We had users with application administration privileges that shouldn’t even have access to the system. Obviously, something had gone wrong.
When we take a step back, we’re really talking about a set of processes here -- User Access Termination, User Access Transfers, User Access Creation and Appropriate Access Reviews. These four processes form the basis of most user access management controls. Somehow, these four processes weren’t doing what we needed them to do – manage and report on user access in a way that assures an effective control environment. Put in simpler terms, we couldn’t prove we had control of our environment, and the evidence demonstrated we didn’t.
So, how are we going to scope our work to be successful? For each of the audit points you are facing, you need to address the immediate data issues related to the specific finding. Once underway, you can then take a step back and start analyzing the process to determine what went wrong and why. For management, your plan for each audit point becomes very straightforward – gain immediate control, then deep dive to prevent the problem from occurring again in the future.
In the next episode, we’ll talk more about analyzing processes and creating effective controls to assure processes are doing what you need them to.
Welcome
Gov *er* nance
"A method or system of government or management."
Welcome to Easygov-IT.org. Easygov (as I’m going to call it for short) is a blog devoted to governing and controlling IT environments in ways that make sense, add value and allow the organization to drive forward. In short – making IT governance EASY.
I started this site for two reasons. First, governance is a complex and often daunting task to the uninitiated – and unlike a lot of areas in IT, there isn’t a lot wiggle room for making errors and finding your way through the process when the auditors come knocking. Secondly, most of the places that say they want to help you understand governance do so with a hefty price tag attached. After years of learning, experiencing and taking the resources of the internet, it was time I gave back. The best way for me to do that is to share my experiences and information with others.
First, a little background. For the last several years, I have been at the forefront of the companies I have worked for in addressing IT audits, IT controls and IT governance. These have included stints in both the service and the manufacturing sectors – which each have their own rules – and for both public and private firms. Annual revenues for these companies run in the $1-10B range. This combination of organizations has given me a unique opportunity to see a wide variety of audit issues, and work with a large group of people to evaluate situations and effectively address problems.
If you’ve read this far, I’m assuming you have an interest in IT governance, and a desire to make use of the tools and services IT governance can provide your organization. Just as likely, if you’ve stumbled across this page its because you’ve gone through an audit of some type, you got dinged, the board is up in arms and senior management is breathing down your neck to find solutions. Been there. Got the scars. So let’s start with rule number one of the governance game.
Don’t Panic.
There is a lot to do. There is a lot to keep track of. For most organizations, its more than a single person can handle – but that’s why they pay us the big bucks. We’re going to do two things to help make you successful. First, we’re going to define where your effort needs to go and secondly we’ll look at building a good governance team around you – even if they are just your peers.
In the next installment, we’ll discuss how to scope your work to make you successful.
"A method or system of government or management."
Welcome to Easygov-IT.org. Easygov (as I’m going to call it for short) is a blog devoted to governing and controlling IT environments in ways that make sense, add value and allow the organization to drive forward. In short – making IT governance EASY.
I started this site for two reasons. First, governance is a complex and often daunting task to the uninitiated – and unlike a lot of areas in IT, there isn’t a lot wiggle room for making errors and finding your way through the process when the auditors come knocking. Secondly, most of the places that say they want to help you understand governance do so with a hefty price tag attached. After years of learning, experiencing and taking the resources of the internet, it was time I gave back. The best way for me to do that is to share my experiences and information with others.
First, a little background. For the last several years, I have been at the forefront of the companies I have worked for in addressing IT audits, IT controls and IT governance. These have included stints in both the service and the manufacturing sectors – which each have their own rules – and for both public and private firms. Annual revenues for these companies run in the $1-10B range. This combination of organizations has given me a unique opportunity to see a wide variety of audit issues, and work with a large group of people to evaluate situations and effectively address problems.
If you’ve read this far, I’m assuming you have an interest in IT governance, and a desire to make use of the tools and services IT governance can provide your organization. Just as likely, if you’ve stumbled across this page its because you’ve gone through an audit of some type, you got dinged, the board is up in arms and senior management is breathing down your neck to find solutions. Been there. Got the scars. So let’s start with rule number one of the governance game.
Don’t Panic.
There is a lot to do. There is a lot to keep track of. For most organizations, its more than a single person can handle – but that’s why they pay us the big bucks. We’re going to do two things to help make you successful. First, we’re going to define where your effort needs to go and secondly we’ll look at building a good governance team around you – even if they are just your peers.
In the next installment, we’ll discuss how to scope your work to make you successful.
Subscribe to:
Posts (Atom)