Warning: what you are about to read is a gross oversimplification of Governance, Risk, and Compliance (GRC) issues in your organization. Obviously if *I* knew everything about the internal workings of *your* business, your GRC initiatives have already failed. Unless of course you work with me, in which case we should head to lunch soon. I'm getting hungry.
I've been reading quite a bit lately about Governance, Risk, and Compliance (GRC) -- specifically here, here (registration required), and here (paywall). I'm not going to go into all of the excruciatingly boring details, but suffice it to say, businesses today generate a lot of risk, and most of them haven't really 'brought it' in terms of managing that risk. People seeing things they shouldn't see, or worse, doing things they shouldn't do has become a moderately cooler (in the no-longer-hot way) topic than it was when Sarbanes-Oxley was first passed (back when my mom was still wrangling SAP systems), but it isn't any less important, and it certainly isn't any easier.
What makes managing (and hopefully mitigating) this risk so hard? The one number that really stood out to me was responding organizations had an average of 215 systems to support. That’s absolutely abysmal. And you just know that each one of those has been customized far too much. What organization could honestly say that they can track that complexity, and that all of that complexity adds to the overall value of the company?
So how did we get here? We got here because IT has let the business down by forgetting what our initial charge was -- to simplify. Simplify the processes and workflows that create the unnecessary variability that creates risk. Automate what we can. Double check the work.
I think the first step in truly minimizing risk at the corporate level is to go back to those original principals and apply them to our current landscapes. Simplify application portfolios so we don't use two tools for the same job. Simplify those applications so that we can make sure they do what they are meant to, and not do what they aren't meant to.
When we look at what's left, we absolutely have to be serious about knowing what we have. GRC isn't about stopping the business from being flexible and creating value; it's about doing it safely and securely. It's about knowing how processes work, and being certain who is able to do what. It's also about finding out when that didn't happen, and improving from there. Applications that can help you do those things, across the entire enterprise, are worth the investment.
I think this need for GRC as a discipline (and not just as a software solution), also makes a strong argument for taking certain applications to the cloud. Due diligence is hugely important here, but the cloud, generally speaking, can be just as safe as an on-premise deployment, and successful Software as a Service (SaaS) vendors are responsible for the lion’s share of maintaining and reporting on access and security (meaning you don’t have to – at least not as much). Also, because SaaS is so heavily geared towards configuration rather than customization, things which need to be tracked and controlled are, at the very least, limited in scope. A lot of these arguments apply far beyond your GRC initiative as well.
Can you realistically cut out half of your application portfolio? No, but you should have the extreme in mind when you go through the process. Be aggressive, but don’t get yourself fired. Can’t do much good there.
Another bit of advice? Don’t try to make this purely a “business intelligence” or “internal audit” initiative. Real, actual executive sponsorship is a very nice-to-have for most IT projects, but it is absolutely critical for one’s that inherently this “not sexy.”
So, if you have a rampant GRC problem in your organization (and chances are you do) I highly recommend limiting the software you have to control, let others control it where you can, and find a unified solution that helps you manage the rest in the right way.
