RPA’s Low Barrier to Entry Explained
Use Cases
4 min read

RPA’s Low Barrier to Entry Explained

There is an extremely low entry barrier for engaging and deploying a robot on the technical side – the real challenge is identifying the right processes.

Share this on LinkedInShare 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.

Robotic Process Automation (RPA) is front-and-center for bringing together systems and manual processes that historically have been difficult or impossible to integrate. In the past, Enterprise Integration teams would spend months in design, data mapping, and integration development work to interconnect enterprise systems. Today, with the latest RPA tools, it can be completed and productionized in a few weeks. Even systems that lack standard integration mechanisms (e.g. APIs) are now ripe targets for integration using RPA Intelligent Automation. Since RPA can read/write data from either the user’s screen or more sophisticated APIs, we can mix and match the approach as best fits the scenario. Therein lies RPA’s beauty and simplicity.

Process Selection More Important than Back End Technology

Let’s also talk about some common questions we hear when talking to teams interested in starting with RPA. Our customers almost always ask “what systems have you successfully integrated with”; or, I need to see examples of integrations with <enter favorite system name here> in an attempt to qualify, or feel comfortable, that a robot will actually work within a specific environment.

The success of RPA has very little to do with the technology of the system(s) being touched

I would suggest that this question has been answered over and over by the RPA platform vendors, YouTube examples published, and PoCs developed. We often explore this common request a bit deeper, but in the end, we will propose a different and more pointed question. The success of RPA has very little to do with the technology of the system(s) being touched; the better question to ask is: how do I find the processes that offer the most automation value. There is an extremely low entry barrier for engaging and deploying a robot on the technical side – the real challenge is identifying the right process that is consistent, predictable, and gives back valuable time to humans who are trapped doing “busywork”.

The right process could be supported by a combination of different types of robots: Attended that reside on the user desktop and work in parallel with the user, and Unattended that run in the backend for larger-batch and asynchronous processing without human intervention. Along with the process selection, the secondary question is “what type of data will we need to work with”?

Robots work better when automating processes utilizing certain types of data:

  • Structured – like a standard form, web page, or document (simple for robots)
  • Semi-Structured – like an invoice that has varying flavors (more complex robot)
  • Unstructured – like an eMail (complex robots, requires AI plugins)

Again, the target system is not the difficult part – it comes down to a stable, predictable process that involves as much standardized data structure as practical. The ability for robots to “read” a screen or document has improved markedly over the past 18 months. Many technologies have come together and provide reliable mechanisms for robots to extract the right data from static documents, web forms, ERP/CRM screens, and even through remote desktop (e.g. Citrix, etc.) screens that have traditionally been off limits for robots. Each RPA vendor has their own proprietary way for extracting data – but here is a common example:

RPA Anchors

Anchoring, or selecting reference positions such as labels and headers near the targeted data field is the most common technique. This basically allows the robots to look for specific “static” text on the form, web page, or system; knowing that the desired data will be consistently located nearby. It looks like this:

RPA example of finding anchors for data processing

The known “anchors” are circled in orange, and let the robot know that there is extractable data nearby. In short, the robot can triangulate from the anchors and retrieve the product name, the quantity (amount) and the prices. This is a good example where the data will change in the rows, but with the static anchors, the robot will always know where to find the right data to extract. This could be in a system, on a web page, in a PDF, or even in an Excel file. This is why “which” system we need to interact with is less important than the actual data structure and standardized formats.

Enterprise Digitization initiatives have already provided the first step to automation – providing the digital input (sources) so robots can immediately extract value typically trapped in paper documents. This isn’t even integration at this point – it is a layer above integration but remains technology agnostic because the screen is the common factor (not the enterprise system). If information can be viewed on the screen, a robot can interact. And more than interact, a robot can create repeatability and resilience for enterprise process, ensuring high accuracy with complete traceability.

To complete this example, once the robot extracts the rows from the invoice above, the data is temporarily stored and can be entered into one or many output targets. We could have the robot log into SAP and enter each row into the finance system form/screen, or we could save the entire array of data as a table in a Microsoft spreadsheet or Google Sheet, or even log into a payment portal and “type” the data into the portal and kick-off an approval process. As you can see, being system agnostic allows the robot to complete manual (and mundane) tasks that would have been very difficult to integrate, and even opens the opportunity for using files (PDF, XLS) in addition to standard Enterprise systems.

When working with new users – the Optezo process catalog has become invaluable for short-listing the best scenarios (both attended and unattended). Rather than start from scratch, your RPA projects should create extreme value without having to re-engineer the process…. we don’t need to automate the rocket-science part of the business in order to create ROI. There are plenty of both short (task-based) and long-running processes that are ripe for automation since they are repetitive, predictable, and utilize a structured data format. Additionally, with the Optezo model for providing "Robots as a Service”, the startup and scaling happens automatically and instantly. Contact us today to find out how you can identify the right processes and start realizing ROI within a few weeks.

About Optezo

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

That’s why we set up Optezo using an all-in-one RPA as a Service model. 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 - services, support, licenses from UiPath, hosting with Microsoft Azure. It's your RPA success in one package. No need to build an internal development team. No need for expensive consultants. Optezo takes care of it for you.

What is Optezo?

Optezo, an RPAaaS Company

All content © 2020 Optezo, Inc.

Privacy Policy