RPA Examples: 3 Top End-to-End Touchless Workflow Solutions

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...

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.

Do you need RPA or IDP - or both?

Read on to discover their strengths and weakness, and 3 Top RPA Examples / Solutions That Power Complex Workflows

What You'll Find in this Article

• The Strength of RPA
• RPA is Fragile, but that's OK
• RPA's Biggest Weakness
• The Strength of IDP
• IDP is Complex, but that's OK
• IDP's Biggest Weakness
• 3 RPA Examples of Real-Life End-to-End Touchless Workflows Using UiPath™ and Grooper®
• Common IDP Use-cases

Strengths and Weaknesses of RPA and IDP

The Strength of RPA

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.

RPA is Fragile, But That's OK

RPA is easy to break. So is a nice vase, but we still use them! Used within the confines of how RPA is intended to work, there are really no big problems.

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.

RPA's Biggest Weakness

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.

If the traffic cop said he could also direct air traffic, or if you expected her to do that because "it's all the same, really," you'd be setting yourself up for disaster.

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.

RPA Examples Involving Paper Processes

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.

The Strength of IDP

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.

Just as RPA works within the confines of expected data layouts, IDP works within the confines of specific use-cases. In a real sense, IDP gives RPA bots the structure needed for automation.

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.

IDP is Complex, But That's OK

IDP deployments are purpose-built, just as the equipment needed for a water crossing can't also be used to traverse a mountain range. While IDP use-cases are nearly endless, each data model must be built for your unique requirements.

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.

IDP's Biggest Weakness

Success with IDP is entirely based on subject matter expertise. This may be in the form of a knowledge worker's experience and training, or the data that is unique to your organization or workflow. Requiring subject matter expertise makes off-the-shelf IDP solutions pretty much impossible.

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.

Here are 3 RPA Examples of Real-Life End-to-End Touchless Workflows Using UiPath™ and Grooper®

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.

1. Bank Reconciliation Process

This use-case provides mission critical data for an enterprise organization performing tens of thousands of financial transaction reconciliations every day:

1. Multiple bots log into bank websites and download files containing statements and other related documentation
2. All files are saved on a file share that is "watched" by Grooper
3. As each file is saved, Grooper ingests the documents for immediate processing
4. The company's compliance policy requires that no documents be stored that contain credit card numbers, so this information is automatically and immediately redacted by Grooper
5. Grooper processes the files
   1. They are split into individual files by customer
   2. Data is accessed from an external database for validations and to insert additional customer information and data elements
   3. The files are compiled, named, and dropped into a file share that is "watched" by a UiPath bot which picks them up and moves them downstream for further workflow processing

2. Document Deconstructing and Reconstructing

This RPA example use-case eliminated a costly manual process for an organization who previously searched through document packets containing information for 20-30 customers across hundreds of pages.

1. A bot logs into a website and downloads the packet
2. All files are saved on a file share that is "watched" by Grooper
3. As each packet is saved, Grooper ingests the documents for immediate processing
4. Grooper searches through the pages and breaks up the single document packet into one document per customer
5. Each new customer document is analyzed and flagged as "complete" or "missing information" based on the content within the document pages
6. All "complete" documents are named, and dropped into a file share that is "watched" by a UiPath bot which picks them up and moves them downstream for further processing
7. All "missing information" documents are flagged for human review

3. Large Text File Processing

This popular use-case processes massive text files. As in the above use-cases, a UiPath bot receives, and then transfers the large text files into Grooper for processing.

1. Grooper instantly parses the entire file using input filters and smart sectioning
2. Over 400 individual data elements are identified and all other unnecessary data removed
3. Grooper converts the text into a single XML file which is transferred to the UiPath bot for downstream processing

As you can see from the RPA examples above, the power really comes from the combination of RPA and IDP.

There's a lot these tools can accomplish individually, but true automation genius happens when you combine the two.

If you're interested in reading more about this, the concept is called "Hyperautomation."

Other Common IDP Use-Cases

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):

• Invoices & financial statements
• Mortgage documents
• Oil and gas documents
• Mill test reports
• Contracts & leases
• Explanation of benefits
• Complex forms
• Electronic files
• Medical claim forms