A multi-level process is a complex process which contains entities that have many-to-many relationships, e.g., procure to pay (P2P) and order to cash (O2C). Traditional process mining techniques fail to deal with data divergence and convergence issues that characterize these complex business processes.
Using multi-level you can immediately see how activities in one entity create bottlenecks and deviations in the process of another entity, which means you’ll never have to worry that your changes eliminated inefficiencies in purchasing but created bigger inefficiencies in invoicing.
Let's see that further.
End-to-end business processes are often made out several processes and applications. Think of the procure-to-pay process managed by SAP. From requisition to invoice, 4 distinct but related processes are involved:
- Good receipt
An invoice can relate to several requisitions, orders, and goods, and therefore a case can combine several process instances of requisition, order and goods in a single invoice process instance.
With multilevel processes, IBM Process Mining can combine several instances of these 4 processes in a single case. And that's what you want from a business perspective: you want to consider that all the requisitions or orders that terminates with a single invoice belong to a single case.
Let's take a simple example.
4 items are purchased through 2 distinct requisitions, to a single vendor.
The procurement department processes these requisitions and create a single order, with one line for each item.
After a while, the goods are received in the warehouse and registered in a single good receipt with one line for each good.
A few days later, the accounting department receives and registers the invoice, and proceeds to the paiement.
With multilevel process, these events are associated to a single case since they all end-up with a single invoice.
This way we obtain correct statistics: when we compute costs, we only count the invoice cost once.
Without multilevel process, we would have a case for each requisition, leading to as many invoices. Obviously statistics would be wrong as we would count the invoice cost 4 times.
Even more critical, multilevel processes creates an accurate model from which we can simulate changes in one subprocess, and measure the impact on other subprocesses. Increasing the efficiency of requisitions/order could create new bottlenecks at the invoice level that we would be able to detect. Without multilevel processes no such detection would be possible since we would just model a 1:1 relationship between each subprocesses.
Let's now see this simple example in IBM Process Mining.
From our SAP P2P dataset, we have extracted and simplified the events related to one case that ends up with Invoice
You can download this CSV file, and load it into IBM Process Mining. Make sure you map the 4 columns : Req_ID, PO_ID, MatDoc_ID, and Invoice_ID to 'Process ID'.
You will obtain this process model that clearly shows the correct number of subprocess instances.
In the process mining project settings, we have declared that the cost of activities is USD 20 (simplified), we can then display the cost view and consider that effectively costs are correct as the invoice activity only occurs once.
Using analytics, we can compute the total cost of the cases, the sum of order amounts, and the sum of invoice amounts. We obtain correct statistics.#processmining
What if we would not have multilevel process capability?
Let's now consider the same use case, as if we would not have multilevel process capability in IBM Process Mining.
We would then need to add a caseID column that identifies uniquely each combination of subprocesses. As already mentioned above, we would have to associate the single invoice to each combination of requisition/order/goods, resulting in duplication of data. The file is here, you should create a new project and only map the CaseID field.
The model frequency view would show this, with the expected wrong 4 invoices.
Looking at the cost view, we would obtain wrong cost as each invoice related activity is counted 4 times.
The dashboard would unfortunately display wrong statistics, as each Invoice related data would be arbitrarily multiplied by 4.
As you can see, we can really model correctly the multiple processes involved in end-to-end businesses with this powerful multilevel process capability.
This is true when discovering the flows and variants, when analysing the costs, when drawing statistics, and when using the digital twin in simulations.
A full example using multilevel processes is available with the Procure to Pay data set available from Github.