Pravin Kothari

Collaboration is the last part of process automation.  We briefly touched on it when we discussed assessment.  Collaboration is an essential part of GRC because GRC is hardly black and white. GRC is all about different shades of gray.  Each organization has to decide for itself which shade of gray is appropriate in each case, whether the topic is compliance level, acceptable risk, or compensating control.  The process of coming up with an agreement around policy, procedures, controls, and risk require collaboration among different stakeholders including process owners from the business side.

Collaboration is a mature product category in its own right.  Lotus Notes was probably the first major software that started the category as we know it today.  In the last few years with the emergence of social networking and the maturity of portal technologies, many of the major software vendors started to use the term Enterprise 2.0 to describe a combination of collaboration, social networking, content management, unified communication and portal technologies.  It’s not the best use of our time here to do a deep dive on the various collaboration technologies.  You can read Wikipedia or Oracle and IBM’s middleware web sites as well as I can.  Instead, let’s dive into 2 questions specific to GRC and collaboration technologies:

1. What is unique to collaboration technologies when applied to GRC?
2. Why is a generic collaboration tools like SharePoint not sufficient for GRC use?  Why does a GRC tool requires integrated collaboration capabilities?

Collaboration and workflow are two separate technologies, even with workflow’s new fancy term “business process automation”.  Collaboration technologies are typically used where lots of people are involved and their interactions are more free formed.  There is usually no well defined end-to-end process involved, and there is little structure around task and data ownership.  In many cases, there are not even clearly defined objectives for the collaboration.  Wiki is a good example of that.  On the other hand, workflow is used for structure processes.  There is usually at least one well defined path for how different tasks and events should happen, who is responsible for each step in the workflow, and each workflow has a start and an end.  Workflow naturally fits into many of the business processes, especially transaction centric ones in most ERP applications.  In addition to collaboration and workflow, there is a third leg to this stool: document management.  Document management is for gathering, managing the lifecycle, and sharing documents for policies, process narratives, procedures and evidences.

GRC use cases require these three technologies to be equally well developed and integrated.  They need to work well together, not separately.  Most of the processes in GRC are procedural in nature, thus workflow is important; for example: incident management, control assessment, and policy approval.  However, many of the tasks or groups of tasks in these processes require a more collaborative interaction; for example: policy authoring, assessment of control, and determination of criticality and business impact.  In order to have a good user experience, a good GRC tool needs to integrate collaboration and workflow technologies together well.  Since many of these processes also involve documents such as policy and compliance reports, document management is also intertwined.  This is fairly unique among enterprise applications.  Only a few other applications have this unique combination of requirements.  Contract management and Product Lifecycle Management products come to mind.  So if you are shopping for a GRC application, look for good integration between workflow, collaboration, and document management capabilities.  As to what qualifies as “good” integration, that is a loaded question and require getting into the weeds on feature design.  We will selectively discuss various features going forward.

One of the most common questions I get is from SharePoint customers asking why they need GRC solutions when they already have SharePoint deployed.  This is especially the case when customer is looking at policy management use cases.  SharePoint is a generic content management and collaboration application.  This makes it a great tool for getting all your documents and evidences collected and shared.  SharePoint has rudimentary workflow capabilities, but more importantly, lacks the context of assessment and stakeholders associated with each process and assessment.  It would be difficult to use SharePoint to enforce any formal risk and compliance assessment process.  This bring us back to the point that GRC is one of the few unique applications that require a tight integration between document management, collaboration and workflow, so a generic collaboration or workflow platform alone cannot meet the use cases well.  Any attempt to address the use cases using generic tools would result in significant custom integration work.

We’ll discuss control automation next time.