There is a long history of building and implementing large software suites with the goal of integrating multiple processes, functions and even disciplines into an interconnected whole. Many assume that a whole suite works better and ensures that there are fewer systems to learn, interact with and maintain. There is also the attraction of “one-stop shopping” and “single throat to choke” in terms of managing vendors. The vendor motivation is incremental revenue and greater customer “stickiness.”
The downside is that these hefty, monolithic application suites are difficult and expensive to implement or change. Theoretically, the idea of integrated workflow, dashboards, reporting and data makes sense and offers substantial value, but often reality is quite different, as these claims do not always pan out. When discrete functions, such as Governance, Risk and Compliance (GRC), are obtained as a module added to a large software suite, there are likely to be inherent compromises. Sometimes these modules are applications acquired originally from other vendors and made to adapt to a suite. With this approach, the promise of full integration is rarely achieved. Sometimes modules are created by generalists or teams that lack deep expertise in GRC or with experience in only one area of the GRC alphabet. The vendor team may understand risk, but not have adequate grounding in governance or compliance.
There are countless accounts of organizations trying to make a general-purpose adaptation of GRC fit their specific needs and processes. Many times, custom routines, scripting or applets need to be created to achieve necessary functionality. Sometimes manual workaround processes or intervention procedures need to be implemented. Expensive consultants and professional services teams need to be put to work. Even with custom software development and manual workarounds, there are many times when a general-purpose module will simply not perform the necessary functions. In these situations, the efforts and software are abandoned in lieu of a solution with a better fit. Ask around about “failed GRC projects,” and you will find professionals all too willing to describe their battle wounds, mistakes and wasted time and money in trying to make a general-purpose module of a large software suite meet their GRC needs.
Just on the risk side, one of the more common pitfalls of GRC as a module of a large enterprise software suite is the lack of an integrated risk register. A workaround might be to track these in a large spreadsheet, which has obvious downsides. A generalized GRC module also often makes it difficult to document where the risks exist and where documentation for those risks can be found. The ability to quantify risk eludes most general solutions, as does the ability to control performance or gain greater insights around risk.
Despite a common user interface across all functions, large software suites are often too complex to fully learn, so most users acquire a mastery of only some functionality. Multiple studies show that often only 20% of features and functionality might be actually utilized by common users. Power users tap into more. Partially this is a result of hidden features or a non-intuitive way that they can be used. With added GRC functionality, customers may simply not know about a feature or find that it is far too difficult to use. History always shows that when software is too difficult to use or understand, employees will turn to other means to get their jobs done. This condition commonly affects GRC solutions that are too general, inflexible or inadequate.
Two increasingly important success factors for GRC solutions are flexibility and evolution. Laws, regulations and requirements are constantly changing. New ones are added, and existing ones get updated. At the same time, GRC practices also change. Part of the great challenge of GRC is to figure out what each organization needs to do to comply with these rules. Compliance is often not clear cut, and organizations may evolve the way they interpret the requirements and how to meet them. Organizations in multiple geographic locations and multiple industries face added complexity with different rules applying to different areas and markets. Solutions must be able to enable the diversity and adapt to the frequently changing aspects of GRC.
Managing risk is an even grayer area. Risk is always a judgment call and requires weighing business efficiency and effectiveness against exposure for loss, litigation or damages. There is always an invisible fulcrum set by each organization for the proper balance between risk on one hand and cost and value on the other. GRC solutions must enable organizations to set up the procedures and processes to best support these determinations while also being able to adjust them over time in accordance with changing risk decisions. GRC solutions that are not created with change and evolution in mind—particularly when workarounds have to be used—can make it difficult for organizations to readily make adjustments.
Maturity is another factor that should be accommodated by a GRC solution. Most risk and compliance organizations grow in maturity over time. Professional organizations offer models with growth curves, assessments, education and instruction to help evolve practices of GRC. A GRC solution should not only enable evolving practices for maturity, but, ideally, also directly help organizations in their efforts to mature. In other words, solutions need to provide flexibility, but the best ones will also help organizations mature by offering features and attributes that practitioners can gradually take on to elevate and mature the way they work.
Of course, one aspect of the changing nature of GRC is the growing magnitude and difficulty it presents to organizations. There are more laws and regulations. Changes occur more quickly at the same time that businesses themselves are changing. Keeping up with GRC is difficult and expensive. Workloads increase. One way to evaluate a GRC solution is in terms of how much time it saves teams. One particularly promising approach to time savings is the use of AI, especially GPT. Used correctly, AI can help ingest and review volumes of new legal and regulatory documentation and automatically create new policies and procedures or modify existing ones. Organizations without such automation will fall steadily behind in their GRC practices, incurring greater risk as well as staff burnout and dissatisfaction.
Another important consideration for a GRC solution is having access a robust content library for the latest legal conventions, templates and reports covering any geography or industry in which a company conducts business. The solution should not only make these readily available, but also make it easy to integrate with these content sources.
Adding GRC on to an existing enterprise software suite does seem to be a compelling proposition, but the pitfalls and problems often completely overshadow any possible advantages. Often these difficulties are not always obvious, and they may not surface until well into an implementation. Once under way, bigger is not often better for GRC.
About the author: Anthony Stevens is the CEO & Co-Founder of AI-powered GRC platform 6clicks . Anthony is a former Partner and Chief Digital Officer at KPMG. He is also the author of Chasing Digital: A Playbook for the New Economy. Before KPMG, Anthony held senior executive roles for publicly listed and private businesses and was the founder and non-executive director of several high-growth technology startups.
Anthony has a Bachelor of Commerce, a Bachelor of Information Systems, and a Masters of Commercial Law from the University of Melbourne and was named Young Executive of the Year in 2011 by AFR BOSS.
Edited by
Erik Linask
