Many companies have made the news lately: Their systems have been corrupted, their data has been leaked, their money has been stolen. There has been many prominent cases in recent years and probably many more, which are not made public or have not even been detected.
This news story appeared in E-3 Magazine International on 20th September 2018. Click here for the original article.
Despite the fact most of these organisations have systems and processes in place to protect them from financial or reputational damages, there are some exceptions to the rule. There are companies that have the technology, but they are simply not using it.
These organisations have licenses for SAP GRC software, but the systems remain empty; there is no content and no workflow. They paid money for their licenses, yet they are still risking potential fraud or theft through lack of deployment. So why has the implementation of SAP GRC not happened? And what can be done about it?
The biggest issue is acceptance
Establishing an internal control system (ICS) or a system for access management is always associated with significant amounts of work. However, the resistance does not usually come from doing an initial project, but from the fear of it generating more complex processes and a higher workload afterwards.
This is why the first question has to be: what is the concrete benefit that the project brings to the enterprise? And what specific things will it offer that will help both the users and the organisation? This may be reducing the flood of emails for new access requests in the IT department or having less stress during an audit for example.
In most cases a GRC implementation has to be communicated to other departments. End users want to know how the implementation will impact them and it is here that the opportunity to get people on board is often wasted; the typical 100-slide PowerPoint presentation that outlines all the features and benefits the GRC solution has to offer is just 'shooting sparrows with cannons'. Focusing instead on the initial reason for the project and incorporating some sample user stories to illustrate its benefits is a much more effective way to gain acceptance.
A second strategy for ensuring buy-in is to lower the entry barrier. One way to do this is to use the new SAP GRC 12.0 with its Fiori launchpad. It has been proven by SAP that its Fiori user interface is far more efficient in terms of adoption because it reduces the number of clicks required on average to perform tasks.
Where to begin with the implementation
The additional value of any system lies in the intersection between IT and the content with which the system is filled. In other words, to realise its value the system has to be customised and populated with the right content.
However, there are some low hanging fruit that offer great impact with little effort. The graphic lists sample features from an SAP GRC solution categorised depending on the impact they will have on the compliance and security of an organisation and relative effort of implementation. This helps to identify features that it is best to start with (although it needs to be noted that these criteria will vary depending on each individual organisation).
As shown in the diagram, the addition of FireFighter is usually a really easy win. It can be set up very quickly and solves many access related issues (such as users still having SAP_ALL). Risk Analysis on the other hand is at the heart of SAP Access Control; its impact is at least as high as that for FireFighter, but building the strong Risk Matrix that it requires calls for in-depth knowledge and therefore some time and effort.
Organisation’s planning to revisit SAP GRC would be wise to first examine its many features and prioritise those that best fit their current individual requirements. Following this with a Proof of Concept (PoC) focused on these priority areas will allow the benefits of the system to be tested with minimal investment and provide a prototype that can be used to get buy-in from other areas of the business.