I recently wrote a Compliance Monitoring in Processes on Compliance Monitoring in process improvement projects where I examined various possibilities to add Governance, Risk, and Compliance (GRC)-related functionality to processes. In researching this blog, I read a great many articles, product descriptions from SAP and other material about GRC offerings. I kept seeing references to corporate processes. For example,
- Embed compliance into business processes, enabling business-owner accountability, preventing fraud, and minimizing audit time and related costs [SOURCE]
- By incorporating control activities into everyday business processes, companies avoid after-the-fact violation detection [SOURCE]
- SAP BusinessObjects Process Control makes it easier for your organization to incorporate GRC into key business processes throughout your organization [SOURCE]
- Learn how to implement a top-down, risk-based framework to identify, control, and test the transactions and business processes that are most likely to be scrutinized during an audit. [SOURCE]
This apparent central focus on process made me curious. What exactly did these references refer to? So I decided to look at this relationship in more detail.
Note: I focused on the existing SAP GRC (governance, risk, and compliance) products (especially SAP BusinessObjects Process Control and SAP BusinessObjects Process Control) as well as the recent SAP GRC 2010 Conference. The current architecture of these SAP products is based on a variety of platforms (Java, ABAP, etc) and is associated historically with the origins of the GRC products in the purchase of Virsa Systems by SAP.
Part of the existing architecture for Process Control 3.0 [SOURCE]
There is a new version of SAP's GRC products (version 10.0) that will soon appear. It appears (Slide 27) that this new release has an entirely new architecture that appears to be primarily ABAP-based. Since I don't have any detailed information on this new release, this blog focuses on the actual release. I'm assuming that many of the points I will make are also relevant for this new release.
A Caveat: I'm not a GRC expert and have never used SAP's GRC products. My only basis for analysis is the documentation that I've found in various sources.
In my opinion, there are two ways to examine the relationship between processes and GRC activities.
- The use of processes in GRC environments
- The monitoring of processes via GRC environments
Let's take a look at each perspective.
1. The use of processes in GRC environment
In this approach, processes are just one part of the GRC environment that involves a multi-faced approach to deal with the issues involved.
There are a variety of different processes that are present in such environments.
GRC includes a vast array of processes, including governance, strategy management, operational and financial performance management, financial and regulatory reporting, compliance in all its forms, ethics, legal, safety, security, investigations, audit and assurance, etc. [SOURCE]
These processes - indeed all processes - imply a more structured basis to deal with problems and provide the assurance that such activities are repeatable. This assumption of repeatability is critical to give the impression that compliance-related activities is functioning correctly For example, this confidence is important inasmuch as any hint that some or all compliance measures are not functioning correctly could possibly discredit such efforts.
Based on the assumption that processes are important in such efforts, SAP GRC products also include such processes:
- Role owners can define which actions and permissions make up each role, trigger approval workflows, document role status, and keep change histories, eliminating the need for manual tracking. [SOURCE]
- You can handle even the most complex approval processes. Based on the user's functional responsibility and the type of access requested, the internal workflow engine automatically determines the appropriate routing for approval, including escalations. Approvers are notified of new requests via e-mail. [SOURCE]
- Workflow-based notifications alert business users regarding failed tests, outstanding design issues, and potential risks that might emerge due to control changes. [SOURCE]
These products appear to primarily use SAP Workflow present in the Business Suite. This is just an assumption on my part, based on a few links that I've found after searching extensively on SDN.
In my opinion, however, what is missing is any description of how such processes could be re-used in other process environments. In particular, I haven't seen any description about how such processes could be used in NetWeaver BPM. Ideally, GRC-processes might be included in other NetWeaver BPM processes rather than exist independently. This inclusion would increase the flexibility to create processes that reflect the unique characteristics of organizations. For example, an approach that more reflects the CE philosophy might enable the inclusion of external / non-SAP environments. This would also enable the use of OnDemand technologies.
GRC-related process based on a hybrid environment
Note: There are a variety of GRC products (for example, Xactium based on Force.com) that are present in the cloud, so this idea is not new or unique.
If made possible, this functionality would bring certain benefits:
- Reuse the impressive functionality currently available or planned in existing SAP NetWeaver BPM. The synergy would allow these GRC products to take part in these new functionalities.
- Increase the number of individuals able to create GRC-related processes in the existing SAP GRC product offering.
2. The monitoring of processes via GRC environments
Norman Marks makes an eloquent plea to add GRC to other parts of the enterprise landscape.
What many seem to overlook is the value of integrating these applications for GRC with the ERP itself. For example, integrating risk management with the financial, accounts payable, logistics, and other parts of the ERP will allow the building of automated, integrated, continuous risk monitoring. Running applications for transaction and master data monitoring (CM or CCM) or auditing (CA) is much more efficient when they are integrated with the ERP - where the data resides - than when you have to extract the data from the ERP so it can be tested.
When I read this, I thought "Perfect - integration is the name of the game. Let's see where the integration really takes place". To perform this analysis, let's look at the processes in different settings and examine the ability of SAP products to integrate with these processes.
On Premise
As seen in the figure below, this is the primary focus of SAP GRC products is currently On Premise installations.
Processes in the BusinessObject Process Control [SOURCE]
First of all, this focus represents a rather old idea of process that is linked to the traditional view of independent silos.
This interpretation is also depicted in the list of the processes currently supported:
Processes supported by AccessControl Product [SOURCE]
What you see here is a focus on the core functionality available in the BusinessSuite. Of course, you don't expect GRC-related concerns to focus equally on all processes. Some processes (finance-related, etc) are of greater importance and are usually the focus of GRC efforts. Perhaps not all areas require GRC attention - indeed, SAP has several areas where coverage is weaker, such as those for global trade compliance and environmental, health, and safety compliance. Yet, I just get the feeling that the focus is on activities of power-users who primarily use the SAP GUI to perform their activities.
Note: How this integration really works is very murky. There are details about embedding GRC-related functionality into transactions. But it is a little confusing to determine whether a transaction is actually a process.
Business process owners can redesign roles by viewing all the roles in which a particular transaction is used or by comparing role definitions to the way those roles are used in SAP applications. [SOURCE]
As seen above, SAP GRC products largely focus on the underlying processes that are present in the Business Suite. For me, however, other process architectures / technologies must also be considered in GRC-related activities. If you look at a more modern approach to processes (as seen in slides describing composite applications), you will see that many modern processes flow across silos.
Composite Applications [SOURCE]
How will the existing SAP GRC products deal with such developments? Or is a concentration on core processes (those that are usually located primarily in the Business Suite) more important? Inasmuch as those "edge" processes are increasing in number and importance, an expansion of its focus is probably desirable.
OnDemand and Hybrid Processes
SAP is expanding rapidly into OnDemand technologies. These developments lead to new processes and new process types.
I have seen nothing from SAP regarding the ability of integrating existing GRC functionality into OnDemand or Hybrid offering. Yet, the potential mingling of internal and external users in such environments suggests that compliance monitoring is of critical importance. Furthermore, the unique characteristics of OnDemand environments (global location of hosting data centers, data privacy concerns, etc) lead to increased complexity that must be reflected in new GRC corporate policies as well as the related technology - regardless of which vendor provides such tools. The use of cloud-based environments is still so new that policies don't exist or haven't been standardized. Thus, vendors may be reluctant to create products when such standards don't yet exist. Those individuals trying to circumvent such GRC-activities might focus their efforts on such platforms based on the awareness that such environments aren't yet adequately covered by many existing platforms.
One option might be new product offerings that are restricted to OnDemand environments. For example, there might be a new set of rich GRC-related tools for compliance specially designed for BusinessByDesign but talking to SAP executives really didn't convince me that they will be focusing on this area in the near future.
Of course, if there is data synchronization between OnDemand and OnPremise platforms, then those controls / monitoring systems present in OnPremise environments might be able to identify issues but this synchronization might not always be in place or include all business objects covered with GRC tools.
Conclusion
The difficulties of current SAP GRC products to deal with the new architectures that are emerging is obvious and reflect the revolutionary character of such developments in that they impact the enterprise at a variety of levels - not just infrastructure. I'm sure if you examined other categories of SAP products or the GRC products of other vendors you would probably see similar issues.
We've examined the impact of OnDemand environments on SAP GRC products but of equal importance are those changes emerging from the OnDevice strategy as well. The changes created by the increasing use mobile devices in corporate processes must also be considered (take a look at Sigurd Rinde's view of the impact of such devices on processes - "PUI, the "Process User Interface"). For example, integration of GRC functionality in Sybase's Sybase Unwired Platform might be another requirement. It is easy to say "Let's just keep our focus on the basic business objects - they are the foundation of most processes any way". As I mentioned in my compliance monitoring Compliance Monitoring in Processes, this only works if the processes in question manipulate data in those business objects. The emergence of other types of processes (those that rely primarily on unstructured data, Barely Repeatable Processes, Case Management, etc) that don't rely on those traditional business objects show that such a restriction is unwise and doesn't reflect the characteristics of many modern corporations.
