Robotic Process Automation vs. Integration
- Posted by: David Watters
- Category: Best Practices
RPA vs integration
Often Robotic Process Automation (RPA) is about moving information between two or more separate pieces of software. An order comes into system A, a product needs to be shipped via system B. A patient checks in to a hospital through system M, a doctor needs to see the patient’s information in system N. A person places an insurance claim through system X, an insurance decision is produced in system Y. And so on. However, getting separate systems to talk to each other is not a new problem and RPA is not the only way to solve it.
System integration has been around already for a while. Its lofty goal is to bring together different systems and get them to work together so well, they can be regarded as a single system, instead of a collection of systems.
As RPA has continued to grow in popularity, it’s interesting to see the similarities and differences between the RPA and system integration. They often answered similar questions but in different ways.
A quick way of explaining the differences boiled down to the phrase “RPA is like a plaster integration” meaning it was quick and easy to implement and wouldn’t stick around forever. Of course, it is advisable to approach RPA from a more strategic perspective, and in this case, the term “plaster integration” no longer applies. In this article, we focus on explaining the technology derived differences between the two solutions.
RPA often offers a more inexpensive and quick solution to the same problem that an integration aims to solve. RPA’s competitive advantage comes from the solution’s light structure, which allows implementing the technology without changes to the organisation’s existing IT systems. Many system heavy organisations suffer from not being able to optimize their processes due to the high cost and operational impact related to reinventing their poorly integrated old IT.
Instead of replacing the old, RPA functions as a human worker would, creating a communication bridge between the separate IT systems. A software robot can be taught a simple process in just a few days, which means that also the impact of the technology is quickly realised. On the other hand, the same technology can be configured for new purposes as the needs of the organisation change.
From the user’s perspective, RPA requires significantly less specialised skills than setting up an integration would. Many of the RPA software applications are created in a way that the user configuring the robot doesn’t need to have a software programming background or skills. In comparison, setting up system integration typically requires a specialised engineer with a broad set of skills.
While our approach may look like it’s glorifying RPA, it is actually highlighting the good and bad of both options. Although fast and cheap solutions are often desirable, it might be worth spending some additional money to know that if the breaks in your car malfunction, you’re notified immediately and that there is a backup system already running. There is a time and place for everything and different solutions work in different situations. System integration is great when the solution needs to be robust. But in many cases, RPA is enough where full system integration would be overkill.