One of the questions that invariably comes up during Risk Management, Compliance, or Security presentations, especially when the client is looking at SAP GRC products to implement is ‘What is the ideal order to implement them if we’re not able to implement them all together?’.
This is not a one-sentence answer. It’s a blog! So, let’s do this!
First of all, there is no always-applicable answer – an answer that I can give once, and then everyone just follows it. It changes from organisation to organisation. So, to refine the question then, ‘How do we work out the ideal order to implement these SAP GRC products for our organisation?’
There are four main dimensions at play here, and you should consider three of them.
Dimension 1: The Quick Sale
First, the dimension that I don’t think you should be considering (apologies to my friends in SAP pre-sales here, but this blog is aimed at helping my clients work out the best for them).
If you ask SAP pre-sales for their opinion on this, they are programmed to reply with the product that is the easiest to sell you. This is because, once you buy the easiest product to sell, your SAP footprint grows, and it is then easier to sell you the rest. If they first try to sell you the most difficult product to sell, then they have a more difficult and less predictable sales process ahead of them.
The easiest product for them to sell is SAP Access Control. The reason being is because SAP has the strongest relationships with your organisation’s IT (as they are software vendors), and Access Control (rightly or wrongly – I sense another blog…) often falls to IT to manage.
The most difficult products are products that IT aren’t directly interested in. The business is interested in them. SAP Risk Management and SAP Process Control fall within this category. To sell these products, SAP has to motivate the business to require the products from IT, then motivate IT to buy them. It’s twice as difficult. It’s actually more than twice as difficult actually, as SAP just doesn’t normally have a strong relationship with the business by the very nature of them being software vendors.
So, let’s assume that we’re not going to consider this dimension when evaluating the best order for you to implement the SAP GRC products. It’s good to be aware of this dimension however, as you are then able to weigh the advice based on this dimension accordingly.
Dimension 2: Order of Priority
The principle of this dimension is that your organisation in fact, already manages risk, manages control, manages compliance, and manages access to critical applications. It’s not ‘green fields’ in that we’re not starting from scratch here. We’re basically ‘upgrading’ some or all of your processes and technology relating to risk, control, compliance and/or access.
Ask yourselves these questions. What part of your risk, control, compliance and/or access processes:
- Are causing the organisation the most pain?
- Are the least reliable or consistent across the organisation?
- Are providing the least amount of useable information on which to base decisions?
- Are providing the least timely information?
- Require the most manual, time-consuming, and error-prone processes?
- Are most often bypassed?
- Result in the most audit issues?
- Are causing the executive/management teams sleepless nights?
In other words, what part of your process do you need to upgrade first? Then second? Then third?
If you believe that your operational control is an inconsistent mess, your risks are a black box, and your security is ok, then you might want to implement SAP Process Control > Risk Management > SAP Access Control. Its all about what needs fixing first.
Ease of implementation however, is a level of complexity that should be considered. For example, if you implement SAP Process Control before SAP Risk Management, you may have significant issues with the integration of the technology, unless you specifically consider the roadmap/integration during the design of the SAP Process Control implementation. Using a project team that has done this before (properly) helps reduce this risk.
Dimension 3: Order of Process
This dimension is often considered when there is no clear order of priority. Maybe there is a ‘green field’ here for some reason. Maybe the current processes are all a mess, or maybe they’re all pretty good, but the organisation wants all of them better.
The principle behind order of process is that you implement starting at the beginning of the process, and finish at the end of the process.
Using an example to illustrate: The Risk Management standard ISO31000 defines a process that if I were to over-simplify for a moment, starts with identifying and assessing risk, treating the risk (i.e., managing the risk through various means including controls), and then monitoring. So, it would make sense to implement SAP Risk Management first to assist in the identification, documentation, analysis, treatment and monitoring of risk. Once that’s done, implement SAP Process Control, to document controls, assign to risks, and then to monitor the controls. Then, implement SAP Access Control, as a subset of the controls managing the risks will invariably be related to Access. SAP Access Control is then able to monitor and manage Access Controls.
If we are to use order of process, the order is invariably SAP Risk Management > SAP Process Control > SAP Access Control.
Dimension 4: Why are we even considering order in terms of technology modules?
This dimension is my own personal view, and I know that it’s often extremely hard for an organisation’s IT to think like this, plus there are sometimes license/budget considerations.
The question here is, why are we letting the way that SAP has divided their technology modules determine the order of our implementation? Especially if we are licensed for all three products!
The principle is to ignore the names of the modules and ignore the modules themselves. Just implement a holistic system of people, process, and technology according to your needs.
Example 1 – Limited features from each product. Most organisations I’ve worked with end up not needing to completely implement Risk Management and then completely implement Process Control and then Access Control (or other order). Their ideal project order will have them implementing some of Risk Management and some of Process Control at the same time (maybe without the automated monitoring, or the monte-carlo, or some other more technical features). They implement across the organisation. They might even implement SAP Access Control in a different, but concurrent project along side an Identity Management implementation. Subsequent projects might then enhance the processes and the Risk Management, Process Control and Access Control features according to their needs. This has to be my favourite order of implementation as it is holistic from a process point of view, is sustainable, and reduces the change management impact, introducing the business to features of the technology and enhanced processes over time.
Example 2 – Limited features from each product, limited by organisation. I’ve also seen an organisation implement all three products together, with limited features and for a limited part of their organisation. Subsequent projects then roll-out to other parts of their organisation and enhance features. The risk of this method is that the company may interpret this as a ‘proof of concept’, and in my opinion, a proof-of-concept project misses some of the key components of what is needed in a Risk Management and Compliance project, such as change management, education and training etc. A proof-of-concept is not an acceptable method to introduce changes to processes and technology as pervasive as risk management and compliance! I sense another blog!
Example 3 – Limited features from each product, limited by function. The final common example is that they implement products together, with limited features, limited to a function of their organisation. Subsequent projects then enhance features, and include other functions. They might for example, start by managing only Strategic Risk and Operational Risk, or start with Finance Risks such as Liquidity, Market, Credit and so forth. Then subsequent projects introduce HSE. With this example, there is a risk that the initial design does not meet the requirements of subsequent functions causing fundamental gaps or redesigns, so I would tend to avoid this order of implementation personally – or at least include all functions in the design, and then stagger the build phase by function.
Conclusion
Having now written this blog, at least I now have somewhere to point to the next time someone asks me about the ideal order of implementation, rather than trying to explain all of this in a single sentence!
If I were to add weight to the above considerations, I would say consider the dimensions in order: 4 then 2, then 3, and don’t even consider 1.
Dimension 4 being the most important is also the most difficult to understand and plan if you haven’t done it before. Saying that, I’d be more than happy to work with you to help you define a roadmap such as this, also considering dimensions 2 and 3 (current state, pain points, future state objectives, order of best implementation and so forth). We actually consider this to be part of our hugely popular Value Lifecycle Management (Discovery) Service.
