This post is a slight adaptation of an old post of mine on the BPX Community of SAP on the 2nd of May of 2007. Almost years have passed by, but most companies are still far away from reaching the described state, so what I describe is still very actual.
The originating question was: What kind of framework or approach do you use when trying to implement GRC in an organization? At that time I was still working for one of the Big 4. Here is the response:
“Each company has a different approach to GRC. However, you can divide them in two broad categories: tactical and strategic approaches to GRC.
Tactical: many companies, mostly those still struggling with SOX, buy technology for solving niche problems (SODs, automating controls for decreasing sox costs, documentation tools for control frameworks, etc). Often the need for a quick fix make it impossible to broaden the discussion around the integrated GRC message. It is not uncommon to find corporations using SAP GRC in India and China and Approva in the United States. Or even companies starting to implement GRC Process Controls without having exploited the configurable controls already inherent in their SAP systems. In summary it is a chaotic situation characterized by individual activism (at country/ division/personal level) in which companies tend to create GRC silos inside the company itself. The right approach to take is an organizational one: Is there somebody in the organization (at the CxO level) interested in harmonizing and sponsoring the GRC discussion? Is the CIO on board? If yes then you should care about a GRC framework, if no, it is wasted time in my experience, because the tactical forces will disrupt the cohesive GRC approach and frameworks.
Strategic: There are very few of them at the moment but they are increasing lately. These companies are willing to broaden the discussion about the GRC message and are interested in a GRC framework/approach. What does a GRC framework/approach contain:
- Define the path forward (Where do we want to be in 4 years from now?)
- Provides a clear view for how GRC integrates into core business processes (Yes, this means working with business people to collect GRC requirements, not just automating something in the backoffice and running off. I do not know how many failed SOD projects I have seen in the last year because they were only technology driven)
- Identifies where risk and compliance management procedures can be automated (And above all where it does not make sense)
- An understanding of how information technology should play a critical role in risk management, proactive compliance, and adherence to standards and policies.
- Maximize the use of existing assets and investments (ex: SAP configurable controls, sap reports, etc)
These companies are clearly not only strategic, but they have realized that GRC should be approached with a combination of tactical (pilot projects) and strategic (what do SOX 404, FDA, Basel II, Loi Financiere, Turnbull, etc.. have in common and how can we leverage common GRC processes and IT infrastructure?)
I think it is also beneficial to distinguish between the GRC message as a business message and the SAP GRC message wich is still mainly technology driven. They are definitely interconnected, because they enable themselves mutually, but you need to make sure you have the right people in the projects on both sides. As an example, if you are implementing the SAP Risk Management component there is a technical part to the implementation of the module but there is also a fundamental business part in creating the processes and understanding around operational risk management in the company so that those numbers and risk estimates that go into the tool make business sense and are lived as part of the day to day business. For that you need industry experts on supply-chain risk management or procurement for example.”
Scary. Almost three years old and still actual.
About the Author
Gregory Guglielmetti is the Managing Partner of SECUDE Global Consulting in Switzerland since November 2008. Prior to joining SECUDE Global Consulting, Gregory was a Manager at Deloitte Consulting where he helped develop the EMEA Governance Risk & Compliance practice. He spent several years selling and managing projects for Deloitte Enterprise Risk Services Group in areas such as Process Controls, SOX 404 readiness programs, and SAP Security. He is also co-authored the book ‘SAP Authorization System’ (SAP Press, 2003). Gregory is CISA certified and spent the early part of his career with PricewaterhouseCoopers Consulting. He holds an MS degree in Computer Science from ETH Zurich.
