Optezo
How to Find the Right RPA Use Case
Use Cases
5 min read

How to Find the Right RPA Use Case

RPA use cases with process repeatability, rules-based decisions, duplicate data entry, common data structure, and high frequency activities should be first on the list of processes to consider for automation.

Share this on LinkedIn
Share this on Twitter
Larry Lauvray
Larry Lauvray
Larry Lauvray on LinkedIn

Larry Lauvray is well known for turning ideas that may start on the back of a napkin into world class solutions. At Optezo, he leads the engineering and development team of Optezo’s RPAaaS platform.

The term Robotic Process Automation (RPA) is being bantered about quite a bit these days.  The technology has matured quickly, and there are plenty of platform/providers in the space.  We’ve all heard about some fantastic use cases cutting hours of work down to seconds.

Today, let’s look a little more into what factors exist that will turn an automation idea into a good RPA use case.  Sometimes the symptoms are easier to identify than trying to jump directly to solving the root cause of an issue.  As with every technology that has come along in the past 20 years, there are some very large promises around savings and return; but the interesting thing about RPA is that it does not take a multi-month (or multi-year) implementation before you begin to realize value.  In fact, some of the smallest automations can produce significant gains just by sheer volume of transactions.  We discuss ROI in a different blog post, so back to some ideal symptoms:

First, let’s draw some parallels between the robot like we’ve all seen on TV, such as a manufacturing robot with welding sparks flying all over the place.  The RPA (software robots) that we are talking about share some of the same benefits (without the sparks :sparkler:).  The RPA, or software robots, do office work by mimicking the users’ keyboard strokes.  The software robot can type faster, with higher accuracy, and at higher volumes.  So, much like the manufacturing robot is good at speed, precision, and repeatability; software robots share the same benefits in the office setting.  There are 2 primary classes of work that fit the software robots well:

  1. Attended robots work in conjunction with a human, typically the process is started by a human to complete a task that is tedious, error-prone, and requires limited decisions.  This robot (software script) will reside on the same machine as the user and effectively mimics the user’s keystroke steps at “machine speed”.
  2. Unattended robots work in the background without human involvement.  Think of large/bulk data file manipulation or batch data processing.  These can be scheduled, or triggered on pre-determined events.  These typically work from a designated input data file (or system) and add/edit/update data in other systems automatically.
“Use cases with process repeatability, rules-based decisions, duplicate data entry, common data structure, and high frequency activities should be first on the list of processes to consider for automation.”

Each have their own niche, and exhibit much different symptoms/characteristics.  We will explore the attended robot today.

Successful attended robots share a few common attributes.  The basic premise of a software robot is the same as a factory robot from the movies - to perform repetitive steps quickly with extreme precision.  If we extend that thinking then we will arrive with conditions ripe for software robotic process automation:

  • Repeatability – The process we automate should be stable, consistent, and not currently being modified, or planned to be modified in the next 6 months.   If a user accesses the same system/screens and edits/updates the same fields repeatedly then we have a good automation candidate.  Of course, the data will be different within the process, but the process steps are consistent.
  • Rules Based Decisions – Robots are not equipped (yet) with the level of human decisioning that may be required for some processes.  However, if the process includes decisions based on standard rules, then it becomes a good automation candidate.  As above, the rules should be stable and repeatable.  The rules could also be based on geography, or even the “type” of person/account data that is in use.  The robot can read data (criteria) from any source for use as an input to execute the rules and decisions in the automated flow.
  • Duplicate Data Entry – Companies have been working to integrate and consolidate systems ever since systems existed.  There is a recurring goal to reduce or eliminate the need for same-data updates in multiple systems. Some companies may have succeeded…. for those that are still on the journey, a robot is the perfect solution (or at least stopgap).   Software Robots can easily span across multiple systems, and even Microsoft Word/Excel, or PDF documents.  There are some very good duplicate entry symptoms related to exporting data from a master system and needing to re-enter, or access/update another system.  Robots are very good at closing that gap between missing system integrations that require human effort today.
  • Common Data Structure – Robots are obviously good at working with data that is already digital and in a common format.  However, as the RPA technology has advanced and included more AI capabilities over the past few years; additional capabilities to “read” text from eMail, digital documents, scanned documents, PDFs, or websites has become quite good.  The trick is more about recognizing the context of the data rather than the actual data interpretation.  An example could be interpreting an incoming Purchase Order.  The process is stable, the rules are clear, and the digital data is readable.  If it is the same PO from the same company, following the same data content; then we are all good to automate.  Even different POs from other companies can be accommodated using “document understanding” that sets the context based on the title of the field rather than the discrete location on the page.  The robot would know how to read titles and process the PO#, Invoice#, Date, Address, and other standard fields.  The anomaly and exceptions would occur when the PO has critical fields that are not built into the model.  Perhaps an oddball reference number, tracking ID, or description field that contained information that should be in a labelled/designated field.  Even though those cases can probably also be accommodated – there are diminishing returns for trying to handle ‘every’ exception.  Therefore, if “most” of the POs/invoices are well structured, then the robot can take a large percentage of the processing load and leave the anomalies for the human to parse and process.  There is still a lot of value for automating 70%-80%.  Therefore, even if not all 100% of the documents are processed automatically; the realistic goal would be to remove the mundane work from of the human workflow.  This allows the human time to focus on the special cases.
  • Frequency – Robots never tire, sleep, or make extra mistakes when under performance pressures.  Symptoms we’ve discussed about repeatability and rules- based decisions can also be layered with how often the process runs.  The best candidate may be a recurring process that is executed hundreds of times a day by a single person or small group.  It could also be a smaller process step that is performed by a large population (perhaps contact center) only a few times a day, but the math of time-saved works out to be the same…. potentially hours if not days.  We are saving the ROI conversation for another day, but rest assured that frequency is the 3rd leg of the stool in conjunction with repeatability and consistency of processes.  Again, these symptoms could occur in any business vertical, in every business unit across the globe.  High-frequency, but automatable steps can live in HR, IT, Finance, Legal, Operations; and in every industry from Agriculture to Yacht Insurance (couldn’t think of a “z” industry).  The symptoms typically are exposed around missing system integrations that involve significant transactional work.  It may be internal (HR) or external (POs and customer inquiries).  Robot automation can also be valuable for extending “self-help” capabilities to vendors, partners, and customers.

Use cases with process repeatability, rules-based decisions, duplicate data entry, common data structure, and high frequency activities should be first on the list of processes to consider for automation.  RPA platforms are constantly adding features and extending capabilities to make robots smarter (AI, Machine Learning, Natural Language Processing, etc.).  At Optezo, we want to remove the technical complexity and pricing confusion by offering and bundling RPA as a service (RPAaaS).  This simplification allows our customers to focus on identifying the key process symptoms/candidates; and allow our experts to define, design, build, and support the robots so you can focus on your business.  Some of the most straightforward symptoms can be managed with RPA, with significant value related to savings, cost avoidance, and accuracy.  Take a look at how we approach RPA differently…or let's discuss how RPA can assist your business.

About Optezo

Our goal at Optezo is to help great companies quickly realize the value of enterprise automation using RPA.

That's why we built Optezo to provide End-to-End Robotic Process Automation Services. Our vision is to bring you the benefits of RPA with a tightly defined playbook. Everything you need to successfully build an RPA program is included - strategy, implementation, support - or our All-in-One RPA as a Service.

Optezo eliminates the complexity, headaches and hassles of RPA so you can spend time on what's important.