ERP, Process mining, RPA, AI
RPA is an umbrella term for tools that operate on the user interface of other computer systems in the way a human would.
When we managed the procure to pay life-cycle automation, it became evident that most of the processes were with high feasibility reaching up to 80% automation potential.
1. Vendor Master
Companies have certain policies for engaging with vendors. Searching the internet for a vendor and scanning through the top results, searching the government databases to see the registration and checking for criminal backgrounds if any, are some simple examples. This process of verification and scanning of the vendor is automatable with potential up to 70%. The key information of a vendor such as name, address, currency, terms of payment and others. is stored in the Master data. Data compilation and updates are a tried and tested task for the software bots. This database is continuously monitored and evaluated to whitelist or blacklist an existing vendor which is a “BOTable” job for compliance and accuracy. 2. Sourcing and Contracting
Sourcing involves locating and selecting vendors based on a set criterion. The inquiries are sent to whitelisted vendors from the Vendor Master. Upon receiving the quotations, comparison sheets are prepared and is circulated with internal key decision makers to choose a vendor. These decision makers negotiate with the vendors to arrive at the best quote. A contract with basic terms of the purchase is created which becomes the basis for a Purchase Order. Except for negotiation and selecting the vendors, all other activities can be assigned to a digital worker to reduce cycle time and to increase accuracy.
3. PO Process
A purchase order (PO) is a commercial document issued by a buyer to a seller indicating types, quantities, and agreed prices for products or services. It is used to control the purchasing of products and services from vendors. It also outlines the delivery date and terms of payment for the buyer. Upon finalizing a vendor, the procurement team updates the basic information in the ERP to create a PO. This is further sent for approvals to multiple layers considering the amount in a discussion. After receiving approvals, the PO is sent out to internal and external stakeholders. Creating a PO, following up for approvals and communicating the PO are typical BOT tasks to reduce manual intervention in the process and bring efficiency.
4. Goods Receipt
A Goods Receipt (GR) is a document issued to acknowledge the receipt of the items listed in the PO. The delivery can be in multiple lots hence upon receiving the GR, it is updated against the PO to authorize payments. This is a manual task of verifying GRs with warehouse and then updating GRs against the PO in the ERP. Optical Character Recognition (OCR) based intelligent automated solutions can be the savior here to read the GR scanned documents received from warehouses to update them further against the PO in the ERP. 5. Invoicing
From arrival to post, handling of incoming invoices from vendors need to be efficiently managed. Many companies lose millions of dollars by way of duplicate payments. The Accounts Payable team does a three-way match of the invoices with the PO and GR to authorize the payments in the ERP. RPA programs make it more accurate, notifying exceptions and duplicates to streamline invoicing and to plug revenue leakage. Each vendor follows their own templates of invoices which are mostly scanned images or pdf and then an OCR based solution would extract data and update in the ERP. 6. Payments
Usually, organizations use third-party services and payment gateways to process payments, but verifying and authorizing payments is a tedious and important task. Accounts Payable teams enter data manually from invoices in ERP upon the completion of a successful three-way match. Three-way matching is also a manual task prone to errors but very much rule based and hence a typical task to assign to a digital worker.
Many organizations are making efforts in automating their mainly manual processes. However, there’s currently a large amount of guess work and subjectivity involved in assessing the processes that might qualify for automation and keeping track of improvements.
Process mining technology offers a set of tools and techniques for factual driven analysis of business processes. This technology uses event data to provide an end-to-end and transparent view of processes. Process mining can be leveraged to accelerate and improve the quality of RPA projects and measure its results.
PROCESS MINING
Aim: limiting human error, a decrease in labor costs, and freeing resources to focus on more value adding activities
Background: RPA projects did not deliver an expected ROI due to lack of transparency of processes.
Def Process Mining: Uses event data to provide an end-to-end and transparent view of processes. Process data is located in different source systems. Process mining learns a process by example from these event logs and provides insights and transparency about how the business processes are being executed.
Techniques:
Process Discovery: uses information from an event log is extracted to build a process model. it is possible to detect different variations of a process or compare a process between regions, periods of time, suppliers. Manual users versus, system users
Conformance Checking mapping the extracted log against the discovered or hand-drawn process model, detect and capture deviations between the two.
Model Enhancement is used to extend a process model with additional information extracted from the event log. For example, the additional information can be extracted from timestamp information (time perspective) or from data attributes that characterize the process (data perspective). This can be further used to repair and alter the process structure
The presented set of techniques, when combined, can be leveraged to obtain valuable insights for RPA projects.
In order to understand how Process Mining can aid an RPA project, it’s necessary to understand how such projects are carried out and the stages they typically go through.
Four different stages of an RPA project lifecycle is explained as follows:
Assess: Before starting an RPA project, it’s important to understand the existing processes that potentially qualify for automation and how they unfold within the company. Once the candidates are chosen, a series of interviews with the process owners follows, aiming to map the process, its steps, and decision points. This phase can be very lengthy due to conflicting accounts from various process owners, which then need to be aligned to form a clear picture. This occurs because organizations don’t always have a clear overview of how a specific process should be carried out, let alone how it unfolds daily. After a process structure has been pieced together, the clear and defined activities and their sequence are turned into the logical basis for the bots.
Program & Test: The following stage in the RPA lifecycle is to turn the devised process logic into a script that will be followed by the configured bots. The program is tested and the process owner and RPA team can assess whether its purpose is being fulfilled.
Mobilize & Implement: Once the testing is complete, the bots can be deployed to start handling day-to-day occurrences of the newly automated process.Employees need to be trained in the new process and which actions they need to perform within this process.
Measure & Sustain: The project doesn’t end with the implementation of the bots. Even after extensive testing, the programming of the bots is not impervious to errors caused by sudden changes to the process- Consequently, it is crucial to routinely monitor the bots’ performance in order to detect such problems and quickly update the program to accommodate the changes. Furthermore, continuous monitoring of the amount of cases handled by bots and how that relates to their maximum usage is key in accounting for the project gains and computing return of investment.
Process Mining can aid most phases of an RPA Project, generating valuable insights that reduce project timeframes and promote more informed decisions.
Process discovery removes the intrinsic subjectivity of the interviews when mapping the process and significantly shortens this lengthy step.
it’s possible to immediately see the as-is process, with no room for subjectivity about the order in which the activities were performed.
Using process discovery, it’s possible to immediately see the as-is process, with no room for subjectivity about the order in which the activities were performed.
On the left side, the process is displayed with all activities and paths that occur in the selected variants on the right side (four variants with highest frequency are chosen). The numbers on the arrows in the process mark the number of cases within the current selection in which that connection occurs. The percentages below the label of each activity indicate its automation rate and the colors are associated with an arbitrary scale that marks red when the automation rate is lower than 45%, yellow between 45% and 55% and green above 55%.
For a good balance between process variant representation and comprehensive visualization, it was decided to display only the top 4 variants, which cover 75% of cases as seen in the lower right corner. It also shows an astounding 252 variants, most of which are unwanted.
Also noteworthy is the occurrence of change activities. The mined process flow shows that “Change Price” occurred more than 7.000 times just in the considered variants.
Change activities are often a byproduct of human error and indicate process rework and consequently lengthier process throughput times. Automating the creation of the purchase order could help reduce the number of change activities significantly, and, therefore, the rework needed.
Scatterplot of the Manual Rate versus Manual Time for each activity in the process.
The RPA scout sorts activities based on the manual execution rate and the total time spent on manual execution of the activities. By having a closer look at the manual execution rate per activity and the total hours spent on them, it’s possible to narrow down the number of automation candidates to ‘Create Purchase Order Item’ and ‘Book Invoice’. As illustrated activities ‘Create Purchase Order Item’ and ‘Book Invoice’ are executed often manually (70% and 65% respectively) and the total time spent on manual executions of the these activities are around 6.800 hours for ‘Create Purchase Order Item’ and 5.750 hours for ‘Book Invoice’.
For these two activities, a more in-depth analysis of the paths going in and out of each was made. The following analysis will focus on ‘Create Purchase Order Item’. As seen, activity ‘Create Purchase Order Item’ is executed 39.244 times after activity ‘Create Purchase Requisition Item’ which is in accordance with how the process should be carried out.
Examining the activities following the creation of the purchase order item in the bottom table of the same figure, it’s clear there are no complex decisions to be made: the next activity should be ‘Send Purchase Order Item’ (for 45.588 purchase order items, the sequence <Create purchase order item, Send purchase order> is observed). It also shows a significant portion of the created purchase order items (1.123) get refused. If the refusals are caused by human errors, automating the purchase order item creation could help bring down the refusal occurrence. However, if the refusals are governed by a more complex logic that would require human interference, it already indicates that automating a sequence of activities following the creation of the purchase order item might not be feasible.
Tables showing activities preceding and succeeding ‘Create Purchase Order Item
Finally, a rough Business Case was put together for the ‘create purchase order item’ based on:
number of manual executions;
targeted automation rate;
average processing time;
full time employee (FTE) yearly hours;
FTE annual salary average.
The last four criteria are customizable which allows for more accurate projections of FTE and monetary savings. Based on the Business Case, a decision was made to simulate the automation of ‘Create Purchase Order Item’ with a targeted automation rate of at least 80%.
This number considers that it might not be possible to automate 100% of cases due to input from a different source or in a different format from those the bots are programmed to handle. Possible fluctuations in the automation rate due to external factors such as software updates are also considered.
Comments