RPA vs. Integration
Often RPA is about moving information between two or more separate pieces of software. Order comes in system A, a product needs to be shipped via system B. A patient signs in to a hospital through system M, a doctor needs to see their information in system N. A person places an insurance claim through system X, an answer 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 of the two ways of thinking. 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, that allows implementing the technology without changes to existing 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 badly 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 days, which means that also the impact of the technology is fast realized. On the other hand, the same technology can be programmed to new purpose as the needs of the organization change. From the user’s perspective, RPA requires significantly less specialised skills than setting up integration would. Many RPA software are created in such way that the user building the robot doesn’t need to have a programming background or skills in coding. In comparison, setting up system integration 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 approaches. Although fast and cheap solutions are often desirable, it might be worth putting in the extra 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 office cases, RPA is sufficient where full system integration would be overkill.
Face tomorrow’s challenges with digital workforce by your side! Contact us to unravel the automation potential hiding in your organisation.