Properties and conditions: your parameters to build the digital twin of your business process

In our last few blog posts, we've been diving into the topic of business process simulation and how it can improve your business process. We introduced the BPSim parameters and explained how they can be used to bring simulation models to life. Now, we're excited to introduce the property parameters in Cardanit. These parameters allow you to set additional variables for some BPMN elements.

By configuring the property parameters, you can better define the characteristics and behavior of different specific BPMN elements within your simulation models. These parameters are like control variables that shape the underlying logic of your model. This is key for creating accurate representations of real-world processes and carrying out effective simulations to analyze and enhance your business processes.

We've also included conditions that determine when an event is triggered based on property values.

Property parameters and conditions really take business process simulation in Cardanit to the next level, and we explain how they work in this blog post.

Definition of the property parameters in a business process

Property parameters are BPSim parameters that can be associated with tasks, events, sequence flows and message flows.

When you're defining property parameters, you just need to create a property in the Cardanit parameter panels and give it a name. If you choose a new name, you create a completely new property. If you use a name that already exists, the values of the last property defined will replace the previous one.

These properties can have various types, such as string, boolean, long or double numbers, duration, and date time. For each of these types, you can set a property value as a constant value, true or false, short or long format, distribution, or use a more complex expression in XPath 1.0.

Right now, we don't have the option to set different property values for specific calendars, but we'll include this feature soon since the BPSim standard supports it.

Usage of the properties to set conditions

Now that you know what properties are and how to create them, let's explore how you can make the most of them to enhance the behavior of your simulation model with the help of conditions – another BPSim parameter now available in Cardanit.

Imagine you have a gateway in your model, and you want to determine which direction a token should go. You can achieve this by using probabilities, which define the percentage for each path.

With the help of properties, you can also incorporate conditions that are supported by BPSim specification. These conditions specify the criteria for triggering an event. For example, a token will follow a specific path only if a certain condition is met. Conditions can be defined on outgoing sequence flows using a boolean expression in XPath 1.0 format.

So, you can decide on a direction based on whether a property assumes a specific value or not. This allows you to better reproduce the logic within your business process in your simulation model.

You can also set different conditions for specific calendars to distinguish between achieved paths at different times.

Familiarizing with properties and conditions: a simple example

Let's take a look at a simple example shown in the following figure to understand how these new parameters work.

In this example, we want to create a loop where only one token enters at the start event and exits at the end event. However, the token can only reach the end event if a specific condition is met. To do this, we have introduced a property that is 0 in the first "start" task, and each time the token enters the "increase" task, this property is incremented. Once it reaches a value greater than 10, the token is able to exit.

When you simulate this model and review the simulation results, it becomes clear that the properties and conditions are indeed effective.

After reviewing the heatmap, it's clear to see that:

• The token enters the "update" task and the gateway more times since they are shown in red
• The token enters the "increase" task a little few times since it is shown in orange
• The token enters and exits the model just once, since both start and exit events as the "start" and "complete" tasks are displayed in green.

By examining the simulation results table and selecting only the token instances, it becomes apparent that the loop has been repeated 11 times. This is because the condition has been satisfied when the property value is more than 10 and its initial value is 0. So, the token can only exit on the 12th repetition when the property value reaches 11.

Properties and conditions to build real digital twin of a real-word example

In the last example, we demonstrated how useful properties and conditions can be by creating a loop. But, where can they really make a difference in business processes?

Let's take the example of modeling a business process for claiming a reimbursement from a health insurance. If you've ever gone through this process, you know that you usually need to submit some documentation through a portal. This documentation is then reviewed and approved by a claims processor. In some cases, it may need further approval from a claims supervisor. However, it's common for the documentation to be incorrect, leading to its update. It's usually possible to update the documentation without starting a new claim, but there may be a limit on the number of times you can do this. If you exceed this limit, your claim reimbursement could be closed, requiring you to start the process from scratch. It's unlikely that you'll misplace the documentation again, but it's always a possibility.

In this situation, properties and conditions are really important - they help us make sense of how things work in our business process.

To make things work exactly the way we want them to, it's a good idea to create two properties. Indeed, there's no limit to how many property parameters you can create. One called "Changes" can be used to monitor the number of allowed changes, and the other called "Frequency" can be used to reflect the fact that it’s unlikely that you'll submit the wrong documentation again. Both properties are created by the first task "Analyze claim".

These two properties basically help manage the situation with the gateways "Does documentation need changes?" and "Has claimant exceeded maximum number of allowed changes?".

The gateway called "Has claimant exceeded maximum number of allowed changes" is linked to the "Changes" property. This property starts with a value of 0 and increases by 1 if the token enters "Ask claimant to change documentation". If this value becomes greater than 1, the reimbursement claim is closed as it has surpassed the change limit. Otherwise, the process continues.

Now, about the gateways "Does documentation need changes"; it relies on the "Frequency" property, which is set as a Triangular distribution with a minimum of 0, a maximum of 10, and a mode of 8 as reported. Note that the mode in a Triangular distribution represents the most probable value, situated between the defined minimum and maximum. When the token enters "Receive updated documentation", the mode of its value changes to 4. If the "Frequency" is greater than 5, then documentation needs changes; otherwise, the process continues. This helps ensure that the first time there's a high probability of an update being needed, and less probability the second time when the mode of the "Frequency" is 4.

See the tables below for a summary.

Simulation results analysis

Let's run this simulation for a week and see what happens. We can check out the bar charts to get a feel for how things are going. We find that most claims get rejected, some get approved, and others get stuck because they need too many changes to the documentation. We can also see where things are getting stuck - it looks like a bottleneck is forming at the "Check Documentation" task. This is happening because the gateways we created are causing a loop, which means tasks are being repeated.

Remember, these results depend on the input parameters we choose. They might look okay, but they can be improved. That's where sensitivity analysis comes in - we can tweak different input parameters and see how they impact the results. This allows businesses to optimize the process from different perspectives, such as customer satisfaction or reimbursement process efficiency. We might want to make things easier for the customer, or more likely we might focus on making the process more efficient for the claims processor and supervisor. So go ahead, give it a try - experiment with our template and see what you discover!

A small hiccup with property parameters

Properties are like global variables – they affect the entire process, not just specific tokens. Every time a token enters a task, the property can change based on your rules. These properties can then trigger different conditions.
Have you ever considered setting conditions based on where a token originates? Imagine customizing paths based on the unique characteristics of a specific token instead of relying on global variables, as the properties. This opens up a whole new world of possibilities. We're already working on making this a reality, even though it's currently a limitation in BPSim. Don't wait – start exploring the potential of properties and conditions to build your digital twin today!

Future steps

Properties and conditions are the key to fine-tuning your simulation models, capturing the unique personality of every business processes. They're your building blocks for creating a digital twin that truly mirrors your business process. Right now, you're improving your business process manually, but we're cooking up something special to automate this soon. - stay tuned!
In the meantime, if you haven’t signed up to Cardanit, do it now and try the existing simulation features.

Further reading

BPSim standard specification for parameterizing your model: definition and benefits

Process validation: how Process Simulation helps verify BPMN models

Simulation in Cardanit documentation