- SAP Managed Tags:
I was recently asked a question by a customer that took me by surprise. Instead of asking what manual processes could be automated, this customer wanted to know instead which processes I would not recommend automating.
I decided to take some time for this response as I didn’t think it should be given lightly.
After some consideration, I think it is possible to split these processes into two categories:
- Firstly processes which are too risky to be automated. If errors were to occur the damages would be too important;
- Secondly, processes which can be automated provided there is thorough testing of the principle and its application.
I’d like to share my thoughts with you in more detail and I hope this will resonate with your own experience.
Manual processes that I would not suggest automating
- Release of publicly available reports
Public reports that include a risk section, such as the company’s annual reports, are of course meant for shareholders and business partners, but competitors and eventually people with malicious intent will also have access to them.
Automating the disclosure of your risk register, alongside the mitigation strategy (and its effectiveness) and potential incidents might give away more information than you intended. Let’s assume that “deficient cyber security” is one of your risks, do you really want to let cyber criminals know what exactly you have done to mitigate it and the fact that you are not fully there yet?
- Risk assessment directly from scenarios
As I already discussed in a previous post (GRC Tuesdays: The Use of Risk Scenario Analysis) I am a believer in using scenarios for decision making. But that’s precisely the point: a scenario needs to be leveraged for decisions, not used as an easy option to assess your risks automatically for you. A human review is essential, at least to confirm that the assumptions used are still correct and aligned within the business context.
- Starting a new risk cycle
Risk management is iterative: once you’ve identified, assessed, mitigated your risks and that you are in a monitoring phase, you do have to trigger a new cycle to ensure that the risk definition and its level still reflect its current status.
Launching a new risk cycle at the company level without previously reviewing the framework, applicable policies or even risk appetite and thresholds would, in my mind, introduce too many threats that can derail the whole process.
Before starting a new cycle, I would recommend reviewing the past one to see what can be improved and, only if all is still relevant and that no new activities have been carried out by the business, triggering a new identification and analysis phase.
Manual processes that can be automated but with caution and testing first
- Triggering an audit
Risk-based auditing is a tremendously efficient approach. Audit teams can focus on important risks and therefore actively participate in the protection of the company’s assets. I have already seen examples where the audit planning is entirely automated by leveraging heatmaps, control ratings or even investigation results.
I think this approach can be relevant for some very specific topic-orientated audits, but should not be generalized and exclusive as it might mean that some risky areas that are not reflected in the heatmaps for different reasons - including due to the fact that it could be an emerging risk not yet fully identified, will not be highlighted and might be missed.
- Consolidated executive reporting
Executives have long required simple to read consolidated reports that they could get in real time. Risk management tools have this great capacity, as all the information is held in one database and can be consolidated at any level.
Nevertheless, before pushing it to your executives, I would strongly suggest testing this thoroughly to ensure that all relevant information is displayed and that the executive can indeed act on this report. I would also suggest reviewing the consolidation mechanism regularly to ensure it is still adequate and that you are not adding apples and pears.
I am sure that there are other processes that could fall into any of these categories, but I wanted to share with you the ones I considered most important. Would you agree with this segregation? Would you add any others?
I look forward to reading your thoughts and comments either to this blog or on Twitter (@TFrenehard)!
Originally published on the SAP Analytics Blog
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 4 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
