Last week I reflected on the link between risk & control management and #BPM and this week I am going a little bit deeper into this, more specifically into the question why you should consider modeling your risks & control in conjunction with your business processes.
Organizations have been documenting business processes already for quite some time (some still don’t but they will catch up later somehow) and in parallel, organizations have also been documenting risks and controls and believe it or not, but these two things are commonly done in two entirely separate groups with the organization. Where the business processes have been the responsibility of IT at first and the CFO/COO column more recently, the risks and controls are very often still the responsibility of either a separate risk management department, or part of Quality Management or sometimes within the CFO column as well.
By the way, I am not suggesting that these two groups should be managed by the same role, but what I am suggesting is that both groups should be working on, from and with the very same repository of knowledge. Allow me to explain that a bit more.
The reason why you identify risks basically is to be able to determine whether or not you will accept the risk (and its consequences should it occur) or put some mechanism in place to mitigate or even complete avoid the risk. In the end you want to have a balanced approach to accepting risks on one hand and all of the controls to mitigate/avoid risks on the other hand. In the end, managing risks is never the goal of an organization, rather than a very powerful instrument to make sure the organization can focus on its core task without running excessive risks.
Business processes are put in place for a number of reasons, the main one of course to enable the organization to actually invent, develop, produce, sell and service their products (or services). However, some processes are also put in place to mitigate the risks that have identified earlier as being non acceptable (and thus should be mitigated or avoided completely). I think the most well-known example here is the financial and specialist approval flow that is often put in place on purchase requisitions. This business process exists to enable the budget holder (the “owner” of the money that is about to be spent) to render judgment on the desirability of an intended purchase before it happened. The same applies to the specialist approval in case of the purchase of specific products (an IT department very often has guidelines on what laptops can and can not be purchased in order to keep their application and infrastructure landscape in check). Below here you'll find some examples of risks being linked to strategies, end to end processes and a single activity of a process.
Taking these two things into account quickly leads to the realization that it is much more efficient if the documentation of both the processes and the risks & controls take place in the same repository. Why, you ask? This allows you to actually connect the risks & controls to the relevant processes and this, in turn, allows an organization to get a comprehensive and integrated overview of the execution of the processes and the actually occurrence of risks in reality.
Imagine this: you have documented both your processes and risks & controls in your BPM platform (I know a very good one ;-) ) and you also linked the risks to the various levels of your process hierarchy (after all a risk can be relevant to an entire functional domain, or to one activity in one business process or anything in between), your controls could be part of the business processes. You also have insights in the execution of your processes via process mining (or even task mining) and because of this the following use case becomes a possibility:
You are about to get audited on a certain norm (ISO, NEN, BS, you name it). In your BPM repository you navigate to the relevant article and immediately see what processes are in scope of the audit. In itself this capability already is quite efficient as it prevents an organization to put a lot of effort into the preparation of the audit. However, it can get better. You now know what processes are going to be audited, you can now look at the process mining results of these processes and demonstrate to the auditor that these processes are in control (or not, but then you show them what you are doing to bring them back in control I guess).
This is not science fiction, I am working with a customer that is taking the first steps on route to this scenario. BPM is all about connecting the various parts of an organization via the concept of the business process. This is also just one use case, but there are many more when it comes to risk management and BPM. Stay tuned for more later on.
Ciao, Caspar
PS: okay, one more use case then ;-) when you document your risks and controls you can also link them to the responsible organizational entities of course (either a department or a single role). This enables those departments or employees to quickly have an overview of what they are responsible for, and what the risks are that they need to prevent from happening.
