Let’s take a look at an example: fraud prevention in an insurance company. Every time an insurance claim comes in, the responsible caseworkers need to assess if the claim is likely to be fraudulent. If this is the case, they escalate the case to an investigation specialist. The caseworkers assess the fraud likelihood based on a lengthy guideline document.

Decision monitoring

To get started with Business Decision Management, we first need to know what decisions we need to improve, in other words, we need to monitor our business’ operational decisions. In this post, we focus on decision modeling and execution, but first, let’s take a quick look at how we can identify improvement potential. In our insurance company example, a comparison of the business’s case data with reports about industry-wide fraud frequency indicates that, in our company, most fraud cases remain undetected – meaning that the business decision fraud detection performs poorly. One of the reasons for poor business decision performance is a lack of clarity and formalization. In our fraud detection example, the case workers don’t follow the guidelines because they are ambiguous and hard to understand.

Decision modeling – designing formalized business decisions

To provide a clear definition of decision rules, we define our decision rules as Decision Model and Notation (DMN) diagrams. DMN is an open standard notation for decision modeling with an underlying XML definition. The formalized definition allows us to deploy the decision rules to a decision support or automation system.

Decision diagrams

Going back to our example, we can now get started with modeling our fraud detection diagram. In this example model, we keep the diagram relatively simple to allow you to move quickly through the explanation.

With DMN, the two most import decision diagram elements are input data elements and decisions. Input data define the data that is needed to make a decision. Decision tables contain the decision logic that maps input data to outputs.

We start with defining the data we use for our decision. For this, we use two input data elements:

  • The ‘insurance claim’ element has the attributes ‘requested compensation’ and ‘type of damage’. For each attribute, we need to define an attribute type. Requested compensation is an attribute of the type number. For example, a customer might request 5000€ in compensation. ‘Type of damage’ is an enumeration attribute, which means it can have a set of values that are predefined by the decision modeler – in our example we only define the values ‘collision with wild animal’ and ‘other’. Defining attribute types is crucial to ensure we can create decision rules that handle all possible inputs later on.
  • The ‘customer’ element has the Boolean attribute ‘clean criminal record’ and the number attribute ‘sum of previously claimed compensation’. A Boolean attribute can be either true or false.

As our input data elements represent objects with different attributes – and not just one value, like a number – we refer to them as complex type input data.
Then, we connect the two input data elements to our decision table element.

Business Decision Diagram

The next step is to open the decision element and add the decision logic to a decision table. Each row in the table maps input data with specific properties to an output using comparison operators, like =, < and >=. This is called a decision rule.

We also need to set the hit policy that determines in which order or combination the decision rules apply. In our insurance example, we set the first hit policy. This means the first rule that applies to a set of input data is used to determine the decision outcome.

Business Decision Table

In our decision table above, insurance claims of less than 2000€ are never investigated if the customer didn’t receive more than 10000€ in previous claims.

Literal expressions

In many scenarios, you need to have more control over your input data to compute a decision outcome. For this, you can use a literal expression language that allows you to aggregate and transform decision data.

For example, we can sum up the value of past insurance claims with the following simple literal expression:

Sum(‘Past insurance claims’)

You can seamlessly integrate these expressions into your decision diagrams. Let’s refine our decision diagram so that the sum of past insurance claims is computed from a separate input data element:

Business Decision Diagram with literal expression

Using decision models for day-to-day operations

Now we have our decision model – but how do we ensure the model is actually used in our claim handling process? Because we created our model in DMN 1.1 (an open standard notation), we have the option to export our diagram to a system that can then either provide decision support for our caseworkers, or automate the decision completely – vastly improving our organization’s ability to use the model and make standardized decisions.

Decision support

Let’s take a look at the two most important scenario types for decision support.

You don’t have the technology available to completely automate.

This is often the case if improvements are driven with a bottom-up approach. When a team lead or department manager suggests improvements on how a set of business decisions are handled, a budget for automation is typically not readily available. In contrast, a decision support system can be purchased with a much smaller budget, for example as a Software-as-a-Service (SaaS) subscription that requires no integration.

Business Decision Decision Support

Hint: See our example model in the Signavio Simulation Tool.

Your decision logic is not sufficiently reliable and accountable.

An example of such a scenario is medical decision support. While a physician can consult a decision support system to diagnose a patient, she still needs to make the final decision herself. This is primarily because the law requires her to do so, but additionally, she might have more contextual knowledge about an individual patient than the decision support system. Still, a decision support system that not only provides a reference decision but also the path to its diagnosis can help the physician when considering all of the important factors in the details of a patient’s medical history. In our insurance example, human intervention is still beneficial, unless we have a self-learning system in place that adjusts our decision rules automatically when fraudsters come up with new schemes.

Decision automation

Of course, we can also eliminate human involvement altogether by deploying a process to a business rule execution engine, like RedHat JBoss BRMS or Signavio Workflow. In contrast to an ordinary software application, a business rule execution engine doesn’t rely on hard-coded decision logic; business users can change the rules in a decision diagram and have them transferred as an update to the engine without involving programmers.

Read more about decision automation in our fact sheet: Best Practices: Effective Business IT Alignment through software-based Decision Management

Conclusion

Business Decision Management focuses on monitoring, modeling, and executing business decisions. Using the Decision Model and Notation (DMN), you can create unambiguous, formalized decision models that increase the visibility and adaptability of your business decisions. Taking a structured approach and using a standard notation also gives you the option to transfer the decision models to a decision support system or automate your decisions completely.

In any Business Decision Management scenario, the Signavio Process Manager is your best friend. Get started with Business Decision Management now and sign up for a free 30-day trial account.

Published on: March 3rd 2017 - Last modified: February 20th, 2018