Robotic Process Automation vs. Integration
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.
When I decided to leave the integration world to discover RPA, I was struck by the similarities and differences between the two. They often answered similar questions but in different ways.
My 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. Here, however, I 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 organizations 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 realized. On the other hand, the same technology can be configured for new purposes as the needs of the organization 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 my 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 are 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.
Article RPA vs integration: Emma Luukka – RPA Solutions Consultant, Digital Workforce (original Jan 20, 2017, edited Sep 9, 2019)
Read more about RPA and IA in different verticals:
Intelligent automation in banking
Robotics in insurance
Robotics and AI in healthcare
Face tomorrow’s challenges with the digital workforce by your side! Contact us to unravel the automation potential hiding in your organisation.