Currently Being Moderated

In this blog entry we brainstorm ideas on integrating risk management into Business Process Management Systems (BPMS), such as SAP Netweaver BPM or SAP Business Workflow.  Proactively managing the risk using a business process management system has not drawn much attention yet, although the financial crisis has shown that it is crucial to manage the risk of your assets. Nevertheless, there is lack of tool support for managing the risks during runtime of business processes. Even more important, none of these tools focus on the business users, with a particular attention on usability. We propose here a system that addresses control-flow oriented risk evaluation. The system takes into account potential future process execution paths defined in the business process models to calculate the risk. Appropriate actions can be defined in the system to handle risk incidents.

Scenario: The Loan Originating Process

Risk is an integral part of management, not only since the financial crisis, where proper risk management can save billions. Surprisingly, risk management has not been yet considered in business process management systems.  We take as an example for our approach a simplified loan origination process (see following figure). However, the concepts are genric and can be extended to any business process that can be modeled using BPMN or any other modeling notation.

 

A loan origination is a business process that formalizes, evaluates and possibly accepts a Customer (C) request for a Loan Amount (LA). The Bank (B) carries out a careful evaluation of the customer's credit worthiness through internal mechanisms and by asking assurance to external agencies called Credit Bureaus (CB). A credit bureau is a third party business partner of a financial institution that processes, stores and safeguards credit information of physical individuals or industrial companies. Credit bureaus gather data from various sources and cross-check and match the data for accuracy. Some of these sources include publicly available records (courts and deeds offices) and credit account details (from credit granters or subscribers). Credit granters in turn are companies such as banks, retailers and any other organizations whose business is credit. They are also called “subscribers” because they subscribe to the credit bureau in order to collect, submit, use and share the information held in the database management systems. They use the information from the credit bureau to make decisions on whether or not to grant credit, in terms of their own credit granting policies. External insurance companies can provide additional insurances for the credit.

Risk Rules

Let us assume that there is the possible event (initiating event) that creditworthiness of customers has been re-evaluated (e.g. due to the economic crisis). It would be risky to grant credits without taking into account this re-evaluation (risk event). However, we cannot just simply treat all loan process instances the same. In case of loans with a low amount (e.g. 1000 Euro), we would proceed as normal, because the risk of loss is low (below the threshold risk) and the cost of stopping these process are not justified. However,   in case of loans with a high amount (e.g. 1 Million Euro) with a high impact, we would stop or restart the process to take into account the changed conditions. One example rule which can be applied to the loan origination process:

  • Initiating event: Creditworthiness of customers has been re-evaluated
  • Risk event: Granting large Credit
  • Threshold: Risk  > 1000 Euro
  • Impact:100.000 Euro
  • Action: Stop Processes

 

This rule does not look much different than a normal business rule. For a proper risk evaluation, we have also to take into account how probable it is that a risk event occurs (e.g. “Granting Credit”). This can be calculated from the process model describing all possible executions of a process and from supplementary data (e.g. process event logs). Thus, the rule can fire even before the risk event happen (i.e. we can prevent that credit is granted) to mitigate the risk.

Evaluating Risk Rules against Executed Business Processes

Once the risk is defined we want to evaluate it during execution of business processes. There can be several instances of a business process and these instances are subject to different risk exposure depending on the state of the instance. The evaluation of the risk is based on the process model, where different execution paths have a different probability and depending on the chosen execution path there is a different risk. There are different ways to determine this probability: process mining (i.e. based on previous executions), simulations, manually entered probabilities etc. The risk is calculated via the probability of the execution path and the impact defined in the risk rule. If the risk of an instance is over a certain threshold we can initiate counter-measures, such as stopping the instance or initiating mitigating processes (e.g. renegotiation of the contract).

Let us illustrate this with a small example (cf. process model in previous section):

We assume that the rating of insurance has been re-evaluated (e.g. it turns out that insurances will get much more expensive in the future). Particularly, the special insurances for loans with a large amount are affected.

We have the following Risk Rule:

  • Initiating event: Rating of insurance has been reevaluated. 
  • Risk event: Special Additional Insurance, 100.000
  • Threshold: 7.000 Euro
  • Action: Stop Processes

 

The credit bureau is currently executing the activity “Customer Assessment”. The probability that the regional manager will evaluate regional criteria for the loan is 40 % (i.e. there is a probability of 40% that this execution path will be taken). The probability that afterwards a special insurance need to be taken into account is 20% (i.e. there is a probability of 20% that this execution path will be taken).

We calculate the risk as follows

W = 0,4 (probability of the special insurance execution path) * 0,2 (probability of the regional criteria execution path) = 0,08 = 8 %

Risk = 0,08 * 100.000 = 8000 Euro

It is over the threshold of 7000 Euro and thus the process instance is stopped. 

The idea in a nutshell - Control-flow oriented Risk Evaluation

We designed a system that addresses control-flow oriented risk evaluation. We motivated it with a loan originating process. The system consists of two components:

  • Risk Rule Engine: Define risk rules that needs to be monitored over currently executed business processes. It takes probabilities from various sources (e.g. process event logs or simulation engines).
  • BPM Engine: Define, Execute and Monitor your processes. For example, SAP Netweaver BPM or SAP Business Workflow. A Business Process Engine is a component that is in charge of the execution of the different applications. An executable Business Process is stored as an application so that the Business Process engine can handle it appropriately in order to execute instances of that process.

We illustrate in the following figure how the system works. The business analyst describes at design time the process, risk management rules and annotates the business process with probabilities in order to measure the risk exposure at runtime. The process can also be automatically annotated using results from previous process executions, simulations etc. The modeled process is executed at run-time and the risk rule engine monitors initiating events. It evaluates in case of an event the process instances with respect to their risk exposure. If the risk is over a certain threshold we can take various actions (e.g. calling a service to stop certain process instances).

Conclusion and Future Work

We presented here concepts for integrating risk management into the process engine. Special risk rules are defined and current running process instances are evaluated for risk when a risk event occurs.  Measures can be taken when the risk for an instance is over a certain threshold.  At the moment, we find only proposal for risk modeling in business process, but without risk evaluation during run-time [1].

We see following perspectives for future work

  • Integrating into the paradigms for case-based or artifact-based process management [2,3] and extension to the inter-organizational level
  • Risk-aware resource scheduling in business processes to manage assignment of resources according to the risk of separation of duty, binding of duty and privacy rules
  • Benefiting from SAP HANA technology to do risk evaluations in real time
  • Risk Dashboard for simple management of risk related to processes. We are working on a method to visualize risk in a simple way to the business user.

We are looking for your comments!

What do you think about managing the risks using our proposed system? Please comment if you like the idea and would like to see a proof-of-concept in the future.

The following people work on this project:

References

[1] Michael zur Mühlen and Michael Rosemann. Integrating risks in business process models. In 16th Australasian Conference on Information Systems, 2005

[2] OMG, Case Management, http://www.omg.org/news/meetings/workshops/SOA-HC/presentations-10/13_F1_Cummins.pdf

[3] K. Bhattacharya, N. S. Caswell, S. Kumaran, A. Nigam, and F.Y. Wu. "Artifact-centered operational modeling: Lessons from customer engagements." IBM Systems Journal, 46(4):703- 721, 2007

Comments

Actions

Filter Blog

By date: