Chief Product Officer
June 9, 2020 • 7 min read
Robotic Process Automation helps to automate repetitive tasks without extensive development effort, even with systems that provide no API based access to functionalities. Commonly these workflows are developed with a "studio" that describes the flow of events in a visual way.
On a general level, the marriage of AI and RPA is discussed a lot, with Intelligent Automation being the promised land of next-level business processes. But when we talk with RPA teams about the potential use cases for machine learning in RPA, it is apparent that things are more complicated.
It is not always obvious where to spot the ideal use case for machine learning in RPA. I would argue that very often the mental model of what machine learning solves is lacking, which in turn leads to unrealistic expectations, or sometimes inability to act on use cases that might be simple to implement with right tools.
In this post, I am introducing a set of guiding questions to help RPA practitioners identify the suitability of our tool Aito to a use case. However, the same framework will certainly help in determining whether machine learning is the right solution in the first place.
Word of warning. It is easy to get in love with the tools, and opportunities they create. However, something being technically possible does not mean that it necessarily needs to be done. Any use case for machine learning is a wrong use case – if it does not solve a real problem.
Have you mapped your use cases on the impact vs complexity matrix chart yet? Most of the RPA teams we speak with have done so. Matrix typically forms the backbone of the backlog. And the logic is spot on: if you have high impact opportunities for automation that are easy to develop, absolutely you should start there.
At some point, however, you will face a situation that you need to start tackling the cases with complexity. That is the moment when machine learning becomes relevant.
Here are a couple of questions I usually ask from an RPA team, to assess if there is something that Aito could potentially solve, and to get a list of candidates for the next automation use case.
Once a candidate list is ready, it is time to dive into more detailed analysis if machine learning and Aito in specific makes sense. Follow the validation steps below.
As a rule of thumb, if a human can describe the logic without problems, machine learning might not be the way to go. You are better of having it programmed with traditional programming logic. Read a great post of the general applicability of machine learning to problems from Futurice.
However, if the logic is complex, includes probabilities and likelihoods and in general, would lead to massive and unmaintainable rule-base; machine learning and Aito might be for you!
Customer case: Helsingö
Helsingö sells premium doors (and more) matching IKEA cabinet frames. Their customer service reps spent countless hours mapping customer IKEA plans with the possible items from Helsingö inventory.
The problem is that IKEA articles evolve continuously, and thus a written logic for matching keeps on failing regularly. They needed a solution that learns and evolves, and have been happy Aito users ever since! Learn more.
Naturally, data is needed to make any machine learning model work for you. Usually, you'd need data that contains validated correct data that the model can use as a training dataset.
Here the logic is three-fold. If you have very little data, machine learning might not be able to provide useful enough predictions to justify the investment. However, definition of what is too little data heavily varies case by case.
Customer case: Helsingö
Helsingö's initial data set was less than 100 samples of matched kitchen plans and customer offers. Sometimes you don't need thousands of rows to get started!
On the other hand, having massive amounts of data that needs to be used to train the models is not Aito's sweet spot. There are big data analytics tools that are better fit for the purpose.
Important: do remember that not ALL of your accumulated data over the years need is needed as training data. Often choosing a reasonable snapshot of recent and relevant data is much better. By selecting the dataset cleverly, you can move the case from big data to the "middle" category, and very suitable to be solved with Aito.
Customer case: Comcast
Comcast has countless terabytes of telemetry data in their Elasticsearch cluster, but only a fraction of it is relevant for predictions made using Aito. They send snapshot samples of relevant data to Aito for quick predictions.
What if you don't have the data at all to start with? Worry not! A very typical way of Aito's customer to deploy machine learning is to implement data collection and prediction in the same automation. For example, when robot processing purchase invoices, the same workflow sends new data points to Aito continuously. Once you have added enough training material into the Aito database, the same workflow starts to use predictions for cases with lacking details (for example predict missing VAT category).
Now we are getting deeper. What is the unknown that you will need to predict to make a use case functional? We will need to determine what type of prediction problem you have at hand, to solve it with the right tools.
First, Aito does supervised learning, meaning it needs the ground truth to exist in the data. Second, Aito does classification, but at the time of writing does not support regression.
What do these mean? Let's look at some examples.
Sometimes the boundaries between these are not clear, and you can approach the same problem with different methods, and all of them may prove fruitful. Ask us for help if you have troubles!
Next up, let's look at your data!
A lot of the RPA + AI discussion revolves around OCR and document understanding, which is natural given the types of problems that involve a lot of manual work in large companies. OCR takes an image (for example scanned document), and turns it into data points that can be used by other systems. While this is critical to many RPA workflows, these types of unstructured data problems are not optimal for Aito. There are plenty of other tools in the market.
However, what happens after the robot has extracted the data from a document might well be solved using Aito. Many times Aito plays a role later on in the flow after OCR has done its job.
Aito is great for tabular data. Think of rows of data that contains numeric, categorical and textual elements. As a rule of thumb, if it can be in Excel, it will work with Aito. In fact, in this field lies one of Aito's hidden superpowers. Aito can also handle relational data. It means your data can be in several tables and linked by identifiers. There is no need to make one flat file out of your data, and you can push new datapoints to any table independently.
Customer case: "Large logistics company"
Document understanding is not going to solve all your problems; a large logistics company learned when working with their purchase invoice processing RPA.
OCR only extracts the data shown in the invoice scan but knows nothing else. Often the automation needs data that is hiding inside the organisation, like "who is the right person to assign this invoice to". This is where Aito helps.
What Aito is not (yet) suitable for is timeseries data. For example, churn prediction is a problem where events take place in sequence over time, and the timestamps matters.
Typically a machine learning solution relies on a pretrained model to give you the predictions. This model is kept up to date through a data pipeline that feeds the new training cycle, and the updated model is then moved to a server where it can serve the prediction requests. This might be not only resource intensive, but also introduces a delay from new data appearing to how soon the model learns new "things".
Aito is different. Any data inserted into Aito is immediately used for any new prediction. While this doesn't mean that Aito would not suitable for "static" data use cases, this absolutely means Aito beats the traditional machine learning approaches when the data changes quickly.
Customer case: Teosto
Teosto is a Finnish non-profit performance rights organization, and they receive continuous stream of reports which music is used in series, movies and media. Their main problems were that the content changes rapidly, and there were no strong identifiers, so very fuzzy matches were needed. Aito optimally serves both needs. Read more from the blog post.
Last, let's consider the daily operations with the predictions. The fact is that a machine will sometimes make mistakes, just likes us. The question is, how costly are those mistakes to your operations.
If you are profoundly intolerant to errors, meaning that each erroneous prediction causes havoc (and you can bear the high cost) you should consider a custom-built machine learning model that can be endlessly optimised to minimise errors. If not, maybe humans should be doing the work anyway.
We often see co-operation of humans and machines working the best where high confidence predictions are used automatically in the workflow. Consequently, low values lead to human involvement to resolve the decision. Every such human input works as a new training data point. Thus, your predictions grow in confidence over time. Very rarely RPA workflows operate completely unattended, making them optimal for Aito usage.
Phew that was a long post, hope you made it here! We worked through a logic of identifying if your RPA/ML use case is great to be solved with Aito. Some are, and some not. We believe in transparency, and will give you our honest opinion if Aito solves your problem better than alternatives.
In the optimal setup Aito helps save 4x in the total cost of ownership of your machine learning solution, and 10x in the time to production. Let us show how!Back to blog list