What happens when we switch it on?

Simulating future changes before going live with them

Change is always difficult, it means moving from the routine to the new. Dealing with new situations is taxing at the best of times, if the change has associated financial consequences like the release of new software or way of working then the stress (like interest) is compounded further.

This post then looks at ways where we can interactively simulate any number of possible futures and more deeply understand what the consequences of change might be so as to avoid costly mistakes. We put a BPMN diagram of a business process into a simulator, update the simulator with facts about the process and then execute the simulator to see how our process might look like under different circumstances.


Credit Card Application Process

Process modelling allows us to capture the way we execute a process today (our ‘as-is’ model).  Against this model we can perform a quantitative analysis to understand the process more deeply.  We can understand how long it takes to execute the in the real-world as well as how much it costs and the impact against resourcing levels.   So for example, if we were to capture a process to apply for a credit card, we could have the following process in BPMN below:

In this process we can see that when the application is received tasks to check credit history and incomes sources are performed in parallel.  When all the data has been verified then the application is assessed. 

If the underwriter grants the application then an offer is made and the process ends.  If it is declined then we need to let the customer know and wait for some feedback. It may also be that the customer requests that the application is reviewed again at which point the underwriter will have to spend some more time to review the data again.  This also means that the amount of time to process each application can vary.


Reproduce the 'As-Is' Process

If we have some way of simulating this model, that’s to say assign some values to the model and then run the process multiple times, we could define a baseline that would approximate how that process looks like in real-life. 

So we could define who does each task, how long it takes, how many applications are expected to be received in a week and how often they arrive then we could run the simulator with this data and the output would mimic what we have in real-life.

From this baseline we could then make changes to the process to see how it would look like before we actually went live with them.

The Computer Science department at the University of Tartu in Estonia have such a simulator it’s located here and I’ll explain how to use it to simulate an existing process.

BPMN Diagram Breakdown

The example process they have is (ahem, fortuitously) the credit card application.  The first section is the scenario section which is where we specify some standard measures around the process, first off we can specify how often the process will be launched.  The set value is 10 minutes with a exponential distribution of arrival, which means that most will arrive with around 10 minutes difference between them but some will arrive 30 seconds and others 10 hours, so as to mimic the real world.

Next we can specify how many times we want to run the process, so the default shows that the simulator will simulate processing 50 credit card applications.
The next sections allows us to define who are the players in the process, the hours they work, how many of them there are and their salary on a per hour basis.  NB. IT systems don’t have working hours but it is not possible to define any capex/opex costs here.  
The sections listed afterwards are all the tasks from the BPMN model above.  For example the first task “Check credit history”, we can specify that the Clerk who performs the task and how long it takes to do it (10 minutes with a standard deviation distribution) as well as any fixed costs and thresholds. 
Finally the gateways (the diamond shaped decision boxes in the diagram) from the model have their percentages set.  So each time the process enters a decision, we can specify the probability for leaving each of the options.  We’ll use the default so that only 1 in 5 of all rejected applications request a review.

Simulation Results

So clicking on ‘start simulation’ will generate the results of the simulation.  And there is a mass of data produced.  We can see how long it takes to process an application and the cost of processing it in the best and worst case as well as the average case. 
Other data that comes through is the wait time, this is where team members were waiting to do work because work hadn’t been completed by the other team.  We can also see resourcing levels to see how well the resources were being used and the model showed that utilisation was close to 95% (so OK, not so accurate! But it is unlikely that the team members only work on one process in real-life).

Reassurance for future changes

The point being that once you are able to baseline your current as-is process, then you can model forward changes to understand what the impact might be.  If we expect a flood of applications then we could predict whether the current level of resourcing would be able to handle this and at what point would we breach an SLA.  If you knew this then we could plan for the impact.  If we tighten application criteria could we expect more requests to review?  What would be the costs of those changes?
Furthermore, if we want to improve the process, we can get a reasonably accurate idea of those improvements which would strengthen any business case with a higher degree of accuracy for the ROI or other figures.
If you’d like to discuss further, please get in contact.

You might also enjoy

What is Process Improvement and how can it help you

Sign-up for the newsletter which brings you the latest in business process technology applied to the SME sector. 

Your data will be used in accordance with our privacy policy.