Recreating a Business Process Map into a Business Process Simulation Model

Introduction

In this blog, we will look particularly at turning the structure of a process map of a simple order-to-cash process into a Silico simulation model. However, while a process map or mapping a process can be a useful starting point for your BPS journey, it is not a requirement. For example, you could map your processes in Silico straight away to create a simulation model, skipping the step of initial process mapping using other tools.

We will assume that a business process map exists to create an initial understanding of what the process we are working with looks like. In this blog post, we will replicate the structure of the process in Silico and investigate how the simulation elements can be used for process simulation. In the upcoming blog posts of this series, we will continue to work with this model and build on it step-by-step until a fully functional simulation model has been developed that we can use to generate FutureSight.

‍

What is Silico?

Silico is a new business simulation platform that allows you to build a digital twin of your enterprise (DTE) to monitor your business, forecast its future state, and simulate the impact of decisions virtually before implementing them in the real world. Essential components of your DTE are the representations of your business processes, such as lead-to-order, order-to-cash, or service processes, which you can build with our Business Process Simulation (BPS) methodology.

The Process Map

Process maps outline the series of steps that make up a process, whether they are activities or events. For example, we may receive incoming messages with orders for an order-to-cash process. These orders are either clean or unclean; in the latter case, they require further cleaning. Clean orders – either because they were clean when received or because they have been cleaned by a team in collaboration with the customer – are then delivered.

‍

‍

Replicating the Process Structure

We can represent this simple process in Silico using our simulation platform for digital twins:

1. First, we create a round symbol element with a mail icon. This symbol on the process map reflects new orders being received. Within our simulation model, we are trying to represent the process map as closely as possible. This will help the process specialists and consultants that have drawn the map to easily comprehend and understand the Silico model.
2. Next, we create a flow to represent the receipt of orders. It flows from our initial symbol element to a stock. This flow represents the number of orders received per day, which is the unit of time of this model. In future blogs, we will look at order quantities. Therefore, we are naming this flow “Orders Received” rather than just the singular used on a process map.
3. Stocks in process twins capture backlogs or queues. They reflect the number of cases - in this example, orders - for which the inflow activity has taken place and are waiting for the outflow activity to occur. In the example simulation model, the order has been received and is now waiting to be reviewed. Therefore, we are adding a stock named “Reviewing Backlog” and a flow named “Orders Reviewed” to the order-to-cash twin. It is important to note that these stocks are not present on process maps; process maps only include flows as activities or steps.
4. This new flow leads to a decision point, which we are reflecting with a symbol element - in this case, using a diamond shape with an x-icon. The x-icon is commonly used to reflect exclusive, “or” decisions. These exclusive OR gateways mean a case will only follow one process branch. In this case, an order is either clean or unclean. These two flows - “Clean Orders” and “Unclean Orders” - are the next ones we add to the process.
5. The clean orders flow into another stock that captures orders waiting for delivery. We are calling this stock “Delivery Backlog”. This stock’s outflow represents the orders we have delivered daily. Therefore, we are calling this flow “Orders Delivered”.
6. Lastly, we need to complete the second branch of our process that is taken by unclean orders. Those will enter a “Cleaning Backlog” where they are waiting or queuing until they are cleaned. This cleaning process is a final activity that we will add as a flow connecting the backlogs where orders are waiting to be cleaned and where they are waiting to be delivered.

With these steps, we have transformed the structure of an order-to-cash process from a process map to a Silico BPS model. In the following blogs in the series, we will build on this process structure and add all the requirements needed to turn it into a fully-fledged digital twin of the process, that can be used for forward-looking simulations generating valuable FutureSight.

‍

General Rules to turn Process Maps into Business Process Simulation Models

For now, we want to quickly think about the general rules for the transition from a process map to a Silico model. There are two things that you should consider and keep in mind when you replicate any process maps in Silico as the first step towards your digital twin:

1. We can see that Silico models can be laid out just like the original process map and use symbols similar to those used on process maps. Thereby, we can ensure that process specialists and consultants can easily understand and follow the digital twin’s structure by ensuring that the twin has the same layout as the existing visualisations of the process.
2. There is a relationship between the activities and steps on process maps and the flows in our digital twin. Flows in Silico’s BPS modelling language represent things that are being done or “moved” over a period of time. Therefore, as a rule of thumb, all activities and steps - the boxes on process maps - are flows. In addition, we’ve added two flows - “Clean Orders” and “Unclean Orders” - from the gateway to subsequent activity backlogs.

‍

‍

Differences between Process Maps and Business Process Simulation Models

That brings us to some differences between process maps and our BPS models in Silico, which have expanded capabilities compared to process maps.

One significant difference is that Silico BPS models include stocks, representing backlogs and queues of our process. These are not captured on process maps but are included in a BPS twin. Process maps only strive to lay out the process visually for a single case, such as an order. They do not seek to capture how quickly things move through the process, such as delivery times or percentages of paths taken, such as the percentage of clean orders.

However, such additions are required to use the twin for forecasting and generating recommendations. After expanding the process model with additional quantitative elements, we can, for example:

1. Identify where backlogs in the process will occur and under what conditions to ensure that our improvements target the right process steps
2. Determine which potential process transformations and changes to implement to maximise ROI
3. Provide a baseline for implementation targets
4. Use the process model as a digital twin to manage, for example, capacity

In our next blog posts in this series, we will add these quantitative elements to our process twin and connect all aspects mathematically, allowing us to unlock the benefits of Business Process Simulation.