RPA = Duct Tape Integration?
Imagine you have all the state of the art components, all best of breed. They are not designed to work together, but you need them to. You can either redesign from base and meticulously integrate through APIs, or you can tie them together with paper clips and rubber bands, solder the surface connections and duct tape it all to hold.
There you have RPA. Or do you?
To those who still wonder: RPA = Robotic Process Automation
This is software which simulate a human using one or many software applications, performing tasks in a predefined process. The point is to utilise the user interface of programs to create an integration between them, or simply automate data entry and software operation. -For example just like a person would search up a value in one program and copy/paste it into another program, and hit Enter.
And this works! Remarkably well, in many situations. Undoubtedly you see the business cases are popping up in your head, where you can quickly integrate systems and automate at a low cost. RPA solutions are often marketed as “no coding required”, and therefore embraced by pure process experts, enabling business consultants to integrate systems with little or no knowledge of what’s under the hood of the user interfaces at hand.
But. There is a big but…. as RPA solutions are relying of screen recordings to capture the process to be automated, you quickly meet challenges. Those of you who already did some RPA work has for sure hit a bump or two, or maybe even a wall, where you see that the screen at hand won’t be recorded or automated as wanted. There is RPA software out there which doesn’t rely on actual recordings, but they still have the dependancy to the user interfaces, and therefore meet the same walls.
Let’s say you get over the bumps and through the walls, and you manage to create a good chain of actions across a number of applications. You found acceptance for the obvious security issues, and clarified all licensing pitfalls. Then one of the target systems gets upgraded. With a new screen or new field name on a screen. Suddenly your chain gets broken. And it happens again. And again.You add new rubber bands and new layers of duct tape.
This is a real challenge for successful RPA application
It resembles the definition of “Quick and Dirty”, and smells mistakenly like panacea…
So is there a solution? Of course there is. It only requires a bit more competence and ability than assumed at first glance. All you need is the expert technical knowledge about the systems you are integrating in addition to your process and RPA knowledge.
The modern user interfaces of today are guided and intuitive. Each screen contains only what you need, and they come in sequence, intelligently rendered by choices made in previous steps. The alternative would be to gather all options and all fields in one screen, so big and complicated no human could possibly be able to work on it.
But… RPA is not human! Its a robot simulating a human, and here the creation supersedes the model. The robot doesn’t care about layout or how many fields you cramp into a page. You could have a monster of a screen with the layout from hell, and the robot could not feel more at home! So by tweaking the target systems, creating purpose-built screens and adding some needed logic, you could meet the RPA software at it’s home base, and actually get things done. It is probably the fastest way home. It is arguably still a temporary solution, but it will be safer and stronger. It would even sustain upgrades much more robustly.
The RPA winners will be those who not only can design efficient processes, but also manage to carry the cross-competence of RPA and the target systems.
Of course it’s fun to play doctor, but do it at home. Make RPA log your hours or submit your travel expenses. But at work, make sure to have enough tech skills on board to build something that lasts;)