In the world of automation, most of the attention is around robotic process automation (RPA).
And RPA solutions are exciting because they promise an end to manual processes and a streamlined approach to the way we work. And they do - to a point...
DID YOU KNOW? According to research firm Gartner, Inc., the RPA market will grow at double-digit rates through 2024.
This demand comes from organizations like yours looking to improve process quality, speed, and productivity.
But what you may not know (and won’t read in the press release linked above) is that additional spending will mainly come from add-on automation technology.
And this is one reason why intelligent document processing (IDP) is seeing increased in adoption. It’s one of the most powerful tools in an automation architect’s toolbox.
Think of RPA as a traffic cop when the traffic signals are out. The officer's job is to control the movement of vehicles within their lanes. It doesn't require a high degree of skill, even though some officers do add a little "flare."
RPA provides a framework for moving data between software applications (including websites) when native integration isn't available.
RPA bots are designed to operate in strict confines of expected data, just like an Excel macro. If the expected data isn't there or in the wrong format, the macro fails. But when all the data is as it should be, the bots save an immense amount of time.
Understanding this will help you identify good use-cases for RPA, essentially automating the movement of highly predictable data between disconnected systems.
Even when the layout of a webpage changes and breaks a login bot, the fix is straightforward (and new ways of working with website are making this weakness obsolete as long as web designers use proper tagging...).
Going back to the traffic cop idea, you've got a human standing amid big and small vehicles all doing what they are told to do. There's risk for the officer, but it's minimal as long as everything flows along like it should.
The biggest weakness of RPA is lack of scalability to process natural language and complex documents (even though marketing hype makes this seem easy). This creates a real threat of mismatched expectations for what bots are actually capable of.
That example is a bit absurd, but expecting RPA to do what it can't (or shouldn't) will end up badly for your automation teams. As soon as automation requirements need to work with data that is dynamic - or changing, that's the signal that another tool is needed.
One of the good RPA examples that seems like a good fit, but isn't, is large-scale invoice processing. The majority of these projects require line-item data extraction, mathematical validation, and PO matching on thousands of differently-formatted invoices (not to mention the woes of poorly scanned paper!).
RPA works with known invoice layouts, but variability of invoice layouts will soon make the project too time-intensive to be profitable. Read more about 3 hidden dangers of RPA.
In this RPA example, think of IDP like military transport. It moves everything from jets to food across any terrain imaginable. It requires very specific planning, outcomes, and most importantly, good intelligence from "boots on the ground."
IDP use-cases are perfect when a data integration project is very complex and requires subject matter expertise for success.
When working with IDP, data models are created for each automation use-case.
Success with IDP requires the solution to be configured to mimic the way a human works with documents. IDP will "look at" a document, understand what kind of document it is, and then use a data model to extract the needed information.
Although there are many repeatable out-of-the-box processes, like OCR, document classification, and separation, a contract abstraction model model can't also process invoices. A separate model would need to be built based on the types of invoices you work with.
Going back to the military transport example, success hinges on knowing the details, and carefully planning each stage of the journey. The process is complex, but repeatable and scalable.
Even approaching a project as basic as invoice processing as "fully duplicatable" across any organization is an unrealistic expectation.
Why? Minor differences in the types of invoices (or data that is important to your workflows) that are unique to your organization create the need for increased manual intervention. If you had to manually verify every single piece of data on an invoice, that would be a huge waste of time when it should be fully automated.
While some industry-specific IDP use-cases are repeatable, the best expectation is that your organization will have enough unique requirements that you will be best served with a personalized solution. Read more about the benefits and challenges of IDP.
By analyzing the pros and cons of RPA and IDP, you should be forming some ideas about how using them together creates a powerful framework for automation.
These use-cases were explained to me by users of both UiPath and Grooper. In each example, other attempts using ABBYY, and UiPath Document Understanding had failed.
While just about any document or data extraction requirement is possible with IDP, here are the most common use-cases we see (click each one for more information):