One of the major challenges with business process management (BPM) projects is accessing existing systems. Unfortunately, many organizations still use systems that either do not have applications program interfaces (APIs) or they do, but the APIs don't provide all the necessary data for a process. As a result, enterprises are left with the choice of developing new and expensive APIs or replacing the applications themselves.
Robotic Process Automation (RPA) lets developers create scripts that automate data entry and retrieval using the user interface of an application. By going through the user interface, enterprises can side-step a missing API and deliver value faster. Moreover, RPA is a perfect fit for BPM: If an automation fails or is unavailable, BPM can easily route the request to a pool of humans to complete.
But wait! Isn't that screen-scraping? Yes, some RPA vendors do use screen-scraping as their core technology. While this approach works well with simple applications, the technology is imprecise and tends to break down when dealing with complicated applications that lack accessibility and test APIs. The result? Constant reworking and automation failures.
Switching to a more evolved system, such as Pega's RPA, where the core technology interacts with the real controls inside an application instead of looking for pixels, removes the reliability issue and delivers much faster performance. These automations work both for headless automation (no actual heads are missing, only the graphical user interface) and for creating automations that help make customer service representatives more productive.
But isn't that still screen-scraping? If you define screen-scraping as any automation that interacts with the user interface of an application, then, yes. But when you understand the underlying differences and see how deterministic automating against real controls beats sending clicks and keystrokes, you'll see why not just any approach works when it comes to delivering that last critical mile of integration.