Analyzing Purchase Events from a Multinational Coatings and Paints Company in the Netherlands: Insights from BPI Challenge 2019 Dataset.

Article written by Milena Stępień and Justyna Czaja

The objective of this article is to showcase the potential of utilizing advanced analytics methods, specifically a hybrid approach combining sequence analysis and machine learning models, in the exploration of Procure to Pay (P2P) data. It aims to emphasize how this approach can be used to identify the sources of delays and inefficiencies within the P2P process.

Understanding Procure to Pay (P2P)

Procure to Pay, commonly referred to as P2P, is the comprehensive set of actions a business carries out when acquiring goods or services from an external supplier. It’s a crucial aspect of daily business operations, significantly impacting overall production costs and timing.

The theoretical model of the P2P process [Figure 1] consists of several events, starting from Purchase Requisition/Purchase Order, including Creating Invoice by Vendor, Recording Goods Receipt, Recording Invoice Receipt, and ending by Clearing the Invoice. In reality, the actual P2P model [Figure 2] is much more complex. It consists of many individual processes across different parts of the organization and involving multiple people.

Due to its complexity, the P2P process might be vulnerable to various business risks, including extended delivery times, decreased production efficiency, increased costs, and even potential fraud.

Theoretical Model of P2P Actual Model of P2P:

Figure 1: Theoretical Model of P2P, Source: https://www2.deloitte.com/pl/pl/pages/technology/solutions/w-jaki-sposob-zwiekszyc-efektywnosc-procesu-purchase-to-pay-oraz-zmniejszyc-ryzyko-wystapienia-zatorow-platniczych.html.

Actual Model of P2P

Figure 2: Actual Model of P2P, Source: https://www2.deloitte.com/pl/pl/pages/technology/solutions/w-jaki-sposob-zwiekszyc-efektywnosc-procesu-purchase-to-pay-oraz-zmniejszyc-ryzyko-wystapienia-zatorow-platniczych.html.

Enhancing Procure to Pay (P2P) Efficiency through Process Mining and Advanced Analytical Techniques

Regular analysis of the P2P processes helps identify opportunities for improvement and prevents potential risks. Usually, a procurement team utilizes business intelligence tools to gain insights into the process’s inefficiencies. However, it might not be sufficient to detect all crucial patterns and relationships in the complex structured data.

Process mining technology offers a remedy to these challenges, enabling companies to enhance their P2P process and achieve noteworthy improvements in performance.

Process mining facilitates the understanding of processes, enabling analysts to identify extended durations and their root causes. Identifying the areas within the process that require development makes it possible to focus the improvement efforts where they will have the most significant impact.

The sheer volume and complexity of P2P data present significant challenges for manual analysis, generally leading to inefficiencies. This is where data mining and machine learning methods become essential. They can play a pivotal role in extracting valuable insights, enabling data scientists to uncover hidden patterns, optimize workflows, and improve business operations.

In the context of process mining, these techniques can be applied to various aspects of business operations, like identifying bottlenecks and performance inefficiencies or detecting anomalies. By analyzing the time spent on specific tasks, the frequency of deviations from standard process behavior, event sequences, and the distribution of task durations, data scientists can pinpoint the sources of delays and inefficiencies and flag anomalies for further investigation.

Leveraging SAS Viya Platform for Hybrid of Machine Learning and Sequence Analysis

There’s a wide array of tools available to build machine learning models and perform data analysis, ranging from open-source options like Python and R to commercial platforms like SAS.

We chose the SAS Viya as the preferred option because of its integrated nature as an analytical platform. It offers comprehensive visualization and model-building capabilities, providing a seamless experience through drag-and-drop interfaces ideal for experimentation. Moreover, its coding interface, with specialized action sets, aligns perfectly with our analysis strategy.

As for the analysis strategy, we opted for a hybrid approach, utilizing both machine learning models and sequence analysis techniques. This combination allows us to leverage the strengths of each method, enabling a more comprehensive and insightful analysis.

Machine learning models help us examine how individual features or events affect the duration of the cases. Meanwhile, features created by sequence analysis action provide insights into the relationships between events, considering not only individual actions but also their order and context. This is important because events can mutually influence each other, either increasing or decreasing their significance.

Data Attributes and Structure in Purchase Order Analysis

The data used in the analysis is the collection of 1,5 million events for purchase orders from a large multinational company operating in The Netherlands. The dataset was provided to the participants of the BPI Challenge 2019 (International Business Process Intelligence Challenge) and is available on this website: link[1].

The purchase order process consists of sequential activities (events) designed to ensure that purchase order processing occurs promptly.

Each purchase order has its own anonymized document ID (variable: Purchasing Document) and may consist of multiple events (variable: concept_name). To ensure the identification of events throughout all PO documents, an index column named ‘case_concept_name’ is created by concatenating the Purchasing Document ID and Item ID. There are 1,595,923 events relating to 42 activities performed by 627 users (607 human users and 20 batch users). In addition, data covers numerous categories of goods and services and includes different types of vendors.

Figure 3: BPI Challenge 2019 data set

On the event level, the following attributes are recorded:

· Case_concept_name: A combination of the anonymized purchase document ID and the anonymized item ID,

· Concept_name: Name of the event

· Purchasing Document: The anonymized purchasing document ID,

· Item: The anonymized item ID,

· Item Type: The type of the item,

· Source: The anonymized source system of this item,

· Doc. Category name: The name of the category of the purchasing document,

· Company: The anonymized subsidiary of the company from where the purchase originated,

· Spend classification text: A text explaining the class of purchase item,

· Spend area text: A text explaining the area for the purchase item,

· Sub-spend area text: Another text explaining the area for the purchased item,

· Vendor: The anonymized vendor to which the purchase document was sent,

· Name: The anonymized name of the vendor,

· Document Type: The document type,

· Item Category: The category as explained above (3-way matching, invoice after goods receipt; 3-way matching, invoice before goods receipt; 2-way matching (no goods receipt needed);

Our analysis will only focus on cases with Item Category: 3-way matching, invoice before goods receipt, and Item Type: Standard PO.

Standard purchase orders (Standard PO) are the most widely accepted and utilized type of PO. They provide clear and concise details, such as the purchased product or service, quantity, delivery schedule, and payment terms. The buyer can easily identify the specific details of the purchase.

3-way matching, invoice before goods receipt category includes all cases where invoice value is compared to the value of the goods receipt message and its value at the time of creation. Invoices can be recorded prior to receiving goods but must be blocked until the goods are actually received. The invoice can be paid after the payment block has been removed.

Data Preparation for ML models

Prior to sequence analysis and ML modeling, it is essential to prepare the input data.

In this case, data preparation involves several steps:

1. Filtering the dates to include only events recorded in 2018.

2. Removing outliers — paths with unusually long durations (longer than the 99th percentile).

3. Verifying compliance of transactions with the company’s compliance rules.

4. Calculating new measures that will be later used in the modeling part, such as:

· Target: Duration of the case in days.

· Change_No: Number of events in the transaction that involve change activities (e.g. ‘Change Quantity’, ‘Change Price’).

· Cancel_No: Number of events in the transaction that involve cancellation activities (e.g. ‘Cancel Invoice Receipt’, ‘Cancel Goods Receipt’).

· Reactivate _No: Number of events in the transaction that involve releasing or reactivating activities (e.g. ‘Release Purchase Requisition’, ‘Reactivate Purchase Order Item’).

· Message_No: Number of events in the transaction that involve message activities (e.g. ‘Receive Order Confirmation’, ‘Vendor creates debit memo’).

Creating Sequencial Features for ML Model Using SAS Viya’s Sequence.Pathing Action

As the next step, we created new features for ML modeling based on sequences occurring within the purchasing process. To achieve this, we utilized the sequence.pathing action available in SAS Viya. It’s a tool primarily used for analyzing sequential patterns or paths in user behavior. However, it can be utilized in any scenario involving data of a sequential nature. In our case, we have a transaction ID (variable: case_concept_name), time ID (variable: timestamp) and event (variable: concept_name) [Figure 4].

Figure 4: The example of a transaction in the data set.

Several parameters can be specified in sequence.pathing action, including setting minimum and maximum thresholds for sequence length (number of events), support (the ratio between the number of appearances of a sequence and the number of cases), and duration (time), as well as applying various filters. More information concerning available options and action details can be found in the documentation: link.

proc cas;
    sequence.pathing / table={name="in_table_&&name." caslib="casuser"} /*input table*/ 
                       adjacent=TRUE /*adjacent events within a sequence must be adjacent in the cases*/
                       item="concept_name" /*event column*/
                       time="timestamp" /*time column*/
                       tran="case_concept_name" /*case id column*/
                       maxItems=6 /*maximum number of events in sequence*/
                       minItems=1 /*minimum number of events in sequence*/
                       minSupport=0.01 /*minimum support*/
                       casout={caslib="casuser", name="sekwencje_&&name.", replace=true} /*output table*/
                       hashFunc="SUPERFAST"
                       saveSequTranMap="TRUE" /*save tranMap (dictionary of sequence ids and cases)*/
                       saveTran="FALSE"
                       casOutSequTranMap={caslib= "casuser", name = "tranMap_&&name.", replace=true} /*tranMap output table*/
                       includeTrailingBlanks=FALSE /*trim trailing blanks in sequence string*/
                       includeLeadingBlanks=FALSE; /*trim leading blanks in sequence string*/
    run;
 quit;

We set a maximum limit of 6 events within the resulting sequence and established a minimum support of 0.01. Additionally, we specified that adjacent items within a sequence must also be adjacent in the cases (adjacent=True). The action then generated two main outputs — the sequence information dataset [Figure 5] and the TranMap [Figure 6], a dictionary linking sequence IDs with the cases in which they appear.

Figure 5: Output of Sequence.Pathing Action: The sequence information dataset.

Figure 6: Output of Sequence.Pathing Action: The TranMap.

The TranMap plays a pivotal role in the subsequent stages of analysis, particularly in generating the sequence indicators used as features in the ML model.

For the information from TranMap to be included in the analytical table used for model training, additional transformations must be performed. First, the table was transposed. Then, missing values were imputed with zeros so that the sequence ID columns now indicate the presence or absence of sequence in each case (variable: Transaction) [Figure 7].

Figure 7: Binary representation of sequences in transactions.

The resulting dataset was then merged with the analytical table used for model training.

Detecting Events and Sequences Influencing Case Duration Using ML Models

The goal of our analysis is to identify which sequences or individual events have significant impact on prolonging the P2P process. To do this, we created machine learning models using the analytical table prepared in previous steps, such as:

• The input variables would include all calculated binary sequence variables (SEQ1-SEQ130), counts of specific events (e.g., VAR1: CHANGE QUANTITY), category variables (e.g., Spend Area), and additionally calculated measures (e.g., Change_No).

• The target variable is the duration of a given case in days.

In the context of the analysis goal, the most significant outcomes of the modeling are the model importance results rather than the model performance measures themselves.

The analytical table was loaded to the SAS VIYA modeling interface: Model Studio. The analytical table consists of 172 columns (130 sequence variables with SEQ prefix, 27 variables with VAR prefix, eight category variables, five calculated measures, and one target) [Figure 8].

Variable roles and types were automatically assigned. Thus, we didn’t have to do it manually.

Figure 8: SAS Model Studio: Assigning Variable Metadata.

The next step was to build the modeling pipeline utilizing available algorithms. We decided to use tree-based models: Gradient Boosting, Forest, and Decision Tree due to their high performance and variable importance reports. The graphical representation of the pipeline is presented in Figure 9.

Figure 9: The graphical representation of the modeling pipeline.

After running the pipeline, we can see that the Gradient Boosting model was selected as a Champion Model. Let’s see the variable importance results for this particular model.

Figure 10: Variable Importance results for Gradient Boosting.

The variable importance table [Figure 10] shows that the top variables that have a significant impact on our target are:

1. Spend_area — representing the area for the purchase item.

2. Change_No — the number of introduced changes in the transaction.

3. SEQ_6 — Change Quantity event.

4. SEQ_24 — Record Invoice ReceiptàRemove Payment Block sequence.

The variable importance report itself does not indicate the direction of the variable’s impact on the target variable. Therefore, we will utilize various visual tools available in SAS VIYA to review and explore the results. One of them is the Model Interpretability tab, which generates Partial Dependence plots that depict the functional relationship between the model inputs and the model’s predictions.

The most significant variable from the model is the Spend_area variable; let’s check its relationship with the target. From Figure 11, we can see that predictions for the duration of the P2P process vary significantly between areas of purchase. The highest predictions are in the Packaging and Additives areas, whereas the lowest are in the CAPEX & SCOS area.

As duration varies significantly between spending areas, running separate models for each spending area may be essential to arrive at more accurate conclusions.

Figure 11: Partial Dependence plot for Spend area.

Another helpful tool for reviewing modeling results is SAS Visual Analytics — a visualization interface of SAS Viya. A simple dashboard was created to analyze why the Change_No variable might be significant to the model [Figure 12].

Figure 12: SAS Visual Analytics: Dashboard — Change_No exploration.

The dashboard indicates that transactions with events related to changes take significantly longer. On average, transactions with changes take 98 days, while transactions without changes take 78 days.

Additionally, it may be beneficial to examine the distinctions between spending areas. The crosstab table shows that events with introduced changes significantly impact transaction duration, particularly in Logistics, Workforce Services, and Trading & End Products. For the Logistics spending area, the difference in medians for cases including change and not including such events amounts to as much as 98 days.

Using ML Models for specific Spend area

We ran the model for a specific spending area to expand the analysis and draw additional conclusions. The analytical table was filtered to include data only from the Sales spending area. Figure 13 shows the modeling pipeline for Sales:

Figure 13: The graphical representation of the modelling pipeline for Sales Spend area.

Let’s look at the variable importance results for this model.

Figure 14: Model Interpretability for Gradient Boosting (Sales Spend area).

The variable importance table shows that the top variables that may have a significant impact on our target are:

1. SEQ24 — Record Invoice ReceiptàRemove Payment Block.

2. SEQ29 — Create Purchase Requisition Itemà Create Purchase Order Item

3. Cancel_No — the count of cancellations in the transaction.

From the PD Plot [Figure 14], we can see that for transactions in the Sales area that include the sequence SEQ24: Record Invoice ReceiptàRemove Payment Block model predicts a duration of 77 days on average, whereas for transactions without this sequence — 58 days on average.

Visualizing Paths in SAS Visual Analytics for Enhanced Insights

To better understand this phenomenon, we decided to display the sequences from the Sales area using the Paths Analysis object in SAS Visual Analytics.

Figure 15: SAS Visual Analytics: Paths Analysis of transactions (Sales Spend area- min freq 600).

The Paths Analysis object highlights paths with the longest duration for the Sale spend area. The graph was filtered by a minimum frequency of 600 transactions to make it more clear and easy to interpret. The width of the path represents the average duration of sequences. Figure 15 shows that paths containing the sequence: Record Invoice Receipt à Remove Payment Block take significantly longer.

It confirms the results that we received from the Gradient Boosting Model.

We are focusing on only transactions from the ‘3-way matching, invoice before goods receipt’ category, so transactions might have invoices recorded before receiving goods. However, in this case, payment is blocked until the goods are actually received. This type of transaction contains ‘Remove Payment Block’ in their sequence event.

Usually, the path should contain the sequence: ‘Record Invoice Receipt’ à ‘Record Goods Receipt’ à ‘Remove Payment Block’. Based on Figure 16 and the model results, it is evident that for some cases the ‘Remove Payments Block’ event directly follows the ‘Record Invoice Receipt’ event. Moreover, it has a significant impact on the duration of a transaction. From a compliance standpoint, the ‘Remove Payment Block’ step may be redundant for this type of case.

Another significant variable for the model was Cancel_No, the number of cancellations in the transaction. But they don’t seem to appear in the filtered results. Let’s try to reduce the frequency of transactions for the Path Analysis object.

Figure 16: SAS Visual Analytics: Paths Analysis of transactions (Sales Spend area- min freq 20).

Lowering the minimum frequency of the path to 20 transactions (cases) resulted in more than a threefold increase in Path Weight (path duration). Although sequences with cancellations occur less frequently, this type of event seems to significantly increase their duration. This observation aligns with the findings of the ML model, emphasizing that relying solely on visual analysis might overlook crucial events, potentially leading to incorrect decisions.

Conclusions

Procure to pay (P2P) datasets contain complex relationships and dependencies that might not be immediately apparent. Due to their inherent complexity, manual analysis of such data can be time-consuming and prone to inaccurate conclusions.

Advanced analytical methods can aid in analyzing P2P processes, assist in drawing more accurate and valid conclusions, and avoid overlooking aspects during visual analysis. The hybrid approach, integrating graphical analysis, sequence examination, and predictive modeling, offers a more comprehensive and insightful understanding compared to using these methods separately. With their application, we were able to identify potential events leading to increased case durations, explore their context, and validate our findings through graphical exploration.

Sequence analysis is not an obvious strategy for generating ML model features. However, our results highlight its significant potential, as it considers not only events but also dependencies arising from their order. This is consistent with our experience in consulting projects across various industries.

Providing an exhaustive analysis of each event and sequence was not the main focus of this article. There is room for further expansion. Collaboration with domain experts could enhance the interpretation of results, broaden the scope of analysis, and identify additional variables or features to consider.

[1] van Dongen, B.F., Dataset BPI Challenge 2019. 4TU.Centre for Research Data. https://doi.org/10.4121/uuid:d06aff4b-79f0-45e6-8ec8-e19730c248f1