Business decision management in practice
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. Let’s consider 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
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.
Designing formalized business decisions
To provide a clear definition of decision rules, we define them as Decision Model and Notation (DMN) diagrams. As outlined in Signavio’s earlier blog post about unlocking the value of business decision management, 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
Returning 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 crucial decision diagram elements are ‘input data’ and ‘decisions’. Input data refers to the information needed to actually make a decision. (Decision tables contain the decision logic that maps this input data to outputs, i.e. specific decisions.) We start with defining the data we use for our decision. For this, we use two input data elements: ‘insurance claim’ and ‘customer’.
The ‘insurance claim’ element
This element has the attributes ‘requested compensation’ and ‘type of damage’. For each of these attributes, we also need to define an attribute type. ‘Requested compensation’ is an attribute with the type ‘number’, because it has a set numerical value. (For example, a customer might request €5,000 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. For 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
This element uses one Boolean attribute, which can be either true or false, and one number attribute. The Boolean attribute is ‘clean criminal record’ and the number attribute is ‘sum of previously claimed compensation’.
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. The next step is to connect the two input data elements to our decision table element.
Then, we can 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.
In our decision table above, insurance claims of less than €2000 are never investigated if the customer has received less than €10,000 in previous claims.
Literal expressions
In many scenarios, you need more control over your input data in order 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:
Using decision models for day-to-day operations
Now we have our decision model, how can 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.
Either option vastly improves your organization’s ability to use the model and make standardized decisions, with automation also having the advantage of freeing up staff time to focus on exceptional cases that require human assessment.
Decision automation
Of course, we could also eliminate human involvement altogether by deploying a process to a business rule execution engine, like Signavio Process Governance. In contrast to an ordinary software application, a business rule execution engine doesn’t rely on hard-coded decision logic. Instead, business users can change the rules in a decision diagram and have them transferred as an update to the engine without involving programmers.
Of course, not all organizations are sufficiently advanced to fully automate their decision-making process. This is often the case if improvements are driven through a bottom-up approach. When a team lead or department manager suggests improvements to how a set of business decisions are handled, a budget for automation is typically not readily available.
Decision support
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. Even so, a decision support system can be as simple as providing staff with a reference decision, which helps standardize the way decisions relying on the same factors are made, no matter which employee is ultimately responsible for making the decision.
In our insurance example, human intervention is still beneficial, especially for unusual cases. (Unless, of course, we have a self-learning system in place that adjusts our decision rules automatically when fraudsters come up with new schemes…)
Next steps
Business decision management focuses on monitoring, modeling, and executing business decisions. Using 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, SAP Signavio Process Manager is your best friend. If you’re ready to get started with business decision management straight away, sign up for a free 30-day trial today.