jump to navigation

Governance, Risk and Compliance – Holistic approach and GRC architecture September 12, 2007

Posted by Jari Tavi in : Differentiation , trackback Jari Tavi

There are certain industry analysts that whenever they write something, I grab the research and read it carefully myself. These analysts include names like Andy Kyte and Debbie Wilson from Gartner, Andrew Bartels from Forrester and Mickey North Rizza from AMR in addition to almost 10 other analysts.

Last week, I noticed a research alert from Gartner, named “The Governance Work Stream for Enterprise Platform Migration”, dated October 29th 20087 – wow, quite a fancy title. My expectations were pretty high as Mr. Andy Kyte was the author.

After first cursory read through of the paper, I felt a bit confused as the study brings up lots of challenges in the area of GRC (“Governance, Risk and Compliance”), but on the other hand, after reading it again, everything is mostly based on common sense – and I am a believer when the common sense is there.

Actually once more, this paper links pretty well to the idea of Business Process Improvement, which I have touched in couple of my other blog entries (here and here). This approach that Mr. Kyte has in his study brings up few topics which make me believe more and more that the GRC must be solved from the process point of view with a holistic approach to the whole value chain, not only the “silos of processes” or “governance alone”.

Silos of processes is a very common approach whenever a traditional ERP system is in place, providing tools for functions (e.g. Finance, A/P, A/R departments etc.) instead of targeting to cover the whole “tree of processes”. As an example, another Gartner publication uses the Order-to-Cash (“O2C”) process tree as an example, and the challenge in solving that whole tree is that the O2C includes six (6) level two processes and, which is even more important, 52 level three sub-processes! So, building governance for this process tree alone would require understanding almost 60 processes and their needs and requirements. A very similar situation can be found also in other areas, like in Purchase-to-Pay.

Mr. Kyte addresses these things in a very constructive and realistic manner in his paper, and he tells to:

  • Slowly and constantly rise the bar
  • Build a culture for governance
  • Single governance process is not necessarily desirable, but still, all elements of “inventory” must work with the governance program
  • Build a network of sponsorship
  • Well, you should read the paper yourself, but all the details in Mr. Kyte’s study make me believe even more that the GRC architecture is a point which entails a huge risk of trying to build something that will never scale up with the operations.

    In my opinion, the only practical way of building a truly scalable and agile GRC architecture includes following the design rules:

  • Take a holistic approach to the processes and focus on best and next practices and the governance at the same time, not as isolated problems.
  • Make sure that the process tools truly scale up with your organization’s needs. First impression may not be true when you try international rollout to dozens of countries with different local legislative and governance issues (remember the holistic approach).
  • Make an early decision to improve operations step-by-step, try avoiding “big bang projects” and instead take smaller, measurable steps.
  • Measure your success with KPI’s.
  • Be ready to adapt to changes, design for change and prepare to integrate with governance policies that the program office possibly introduces.
  • But most importantly: Build the culture and commit the team and sponsors to it!
  • So in short: Think Big, start small, to be able to grow based on the demand.
  • One of the steady challenges in areas of GRC and process improvement, as demonstrated in the area of Enterprise Purchase-to-Pay, is the challenge of fragmented sub-processes, and this easily takes the direction towards everybody protecting their own silos of operations. This leads to the governance program’s program manager to put some of the important things, as Mr. Kyte expresses, to a “too hard” a box – and this is an unacceptable situation. In my opinion, this puts even more pressure towards specialized, holistic packaged solutions instead of generic business process engines or tailored ERP process workflows.

    One part of the governance, as stated by Mr. Kyte, is the establishment of policies, and this is an important finding, as policies are a key to business rules, and business rules are a key to automation, and automation is The Key to scalable and agile processes with good governance. True GRC does not require an explicit workflow, but instead it requires automated testing of business rules as part of the automation and workflow processes. Best practices should be implemented in such way that automation takes care of almost everything, and we must remember that workflow is not truly a mode of automation but it is only computer-assisted manual labor.

    There are certain processes, in mostly departmental level, that suit well to be run by generic workflow or BPM platforms, but the more governance and compliance related issues are involved, harder it is to find the expertise, commitment and sponsorship from the company or even from a Systems Integrator (“SI”) that creates generic solutions. What we must remember is that for example the Purchase-to-Pay area alone requires discipline and subject expertise for development and maintenance from the following areas, at minimum, especially when working in an international environment:

  • Local legislation
  • International legislation
  • Book keeping standards (US GAAP, IFRS, local GAAP etc)
  • Tax standards and legislation
  • Tax practices
  • Rollout and/or Internationalization (languages, user management etc)
  • Tracking of changes in legislation and practices (IFRS, SOX etc)
  • Usability for large rollouts (ease of use, acceptance)
  • Reporting requirements
  • Auditing requirements (SOX, SAS70, 2006/43/EC etc)
  • Records retention requirements
  • Capture and data quality, data cleansing, validation and enrichment
  • Automation requirements (2-way is NOT enough)
  • Change management of the whole ”package”
  • And this list is not by all means a complete list.

    So, in short, Mr. Kyte has, once again, been able to express so well the biggest concerns in building a governance culture, which I cannot help but to agree with. On the other hand, a practical implementation may take lots of design, proven and scalable architecture and, in my opinion, requires a holistic approach to processes as a foundation for success.

    GRC: “Business Rules rules!” Automation makes the difference!