RPA definition
I never realized that, whenever I collect data from 2 or more systems, mixing up SELECT statements with files and calls to web services and LDAP servers, and present all these data in a browser window through APEX, I am doing RPA (Robotic Process Automation) every single day. Actually, “RPA Done In The Right Way™”.
But a couple of weeks ago I went to a workshop at the Danish Society of Engineers (IDA) in Copenhagen, where high level experts in the field were talking about Robotic Process Automation. I expected an introduction to RPA and some user cases with examples of the tools commonly used to implement these processes, but I actually got something totally different and more interesting: the speakers were focused on two of the key subjects that can make a RPA implementation successful:
- Definition of RPA
- Collaboration with the IT people in the company as key factor for the success of the project.
One of the presenters gave a very sharp definition of RPA: “Robotic Process Automation (RPA) means the use of a software to execute rules-based processes as if a real person was doing them across applications”. At that point I realised that I didn’t need more technical details about RPA, but I needed more understanding of the “context” in which RPA is required and “why”.
Both speakers were stressing that RPA doesn’t happen without involving the company IT department. They also explained when RPA becomes a need, and then I clearly understood what I am really doing with APEX and why.
Let’s make a simple example:
One of the steps of the hiring process in a company requires the HR responsible to open and access 3 different systems to collect information about a candidate and then again access 2 other systems to insert additional data and send an invitation to her/him to a second interview. It takes 12 minutest to perform all the steps.
A RPA process (or a swarm of coordinated processes) can perform the same steps in 1m:30s. All the data needed to take the decision is collected for the recruiter and then she/he can just press a button to send the invitation to the interview, after having gone through all the collected information.
Why RPA and not the IT deparment itself?
What was the reason to implement a RPA process instead of developing the IT systems to support the business? Why did the IT department not implement this request for the user instead of letting the user go around the systems with yet another tool? There is basically one reason only: time!
- The user has been frustrated during 2 years using 5 systems to perform just 1 task. When the user’s request for change was rejected by the IT department (because the IT people told her/him that it would take too much time to implement a new process and they don’t have enough resources to start a new project) the user decided to download a tool that allows to automate all the required tasks on the client side.
- The management made an analysis of the employees’ manual tasks that could be automated within the existing systems and allow a saving of XX million $. They discussed with the IT department, but the cost of implementing the changes in the systems would be too high. More important, the analysis of the required tasks would take at least 8 months, and the actual implementation of the new flow another year. Is not going to happen soon, even though the user would benefit of the improvement immediately and make the company save money…
Of course It’s much cheaper to buy a roll of duct tape (a RPA tool), and setup the needed RPA processes. But now the IT department has more problems than before:
The new RPA processes set a hard constraint on the user interface and the way our 5 hypothetical systems manage the information flow: any change in one of the source systems will break the process. Now the IT department not only has to check internally before any change, but it needs also to check every single RPA process insisting on any of the 5 systems involved before implementing any change.
The result:
- Even though the internal IT was reacting slowly (in the eyes of the user), now it will take even more time to accommodate changes that can improve any of the company’s systems
- Instead to enforce the IT department with extra resources, the company decides to start a RPA project (which requires some extra employees/consultants as well) to coordinate the sworm of processes needed to improve key areas of the business.
Could this scenario be avoided? If the company just had a very light and cheap APEX instance installed, the same optimization would have been implemented properly, using the right interfaces to perform the different tasks, and in a very short time.
What’s the catch?
For those who don’t know what’s the difference between APEX and any other WEB framework normally used (let’s say typically JAVA in enterprise environments), here is a short comparison:
| JAVA | APEX | |
|---|---|---|
| Number of people typically required to execute 1 task or project | 2 or more (frontend/backend) | 1 (frontend & backend) |
| Time required to develop a RPA process like the one described in this article (including heterogeneous source types like relational databases, files, web services, as example) | Measured in weeks/months | Measured in hours/days |
| Time to setup a test environment to see what the technology can do for the company and what is included out-of-the-box | Measured in days/weeks | Measured in hours/days |
| Difficulty to keep the environment updated to the latest security and performance patches (ok, here the mileage can very, but still…) | From not easy to painful | From very easy to moderate difficult |
| Out of the box data-oriented interface | You start from scratch and do everything programming by hand | Declarative, Low-Code Platform, with defaults tailored for data and process management |
I could go on with the list for long time, or you can just read around, there are a lot of extremely good articles on the subject.
My point is that, wherever APEX is not taken into consideration to enable “RPA Done In The Right Way™” in your company, the choice is done for the wrong reasons:
It’s a Oracle product, and Oracle is very expensive and has the most complicated licensing model in the Universe.
…which is somehow true, only if you don’t have any Oracle database in house sitting somewhere. If you have it, then APEX license it’s totally for FREE (N.B.: in case of “embedded” database license only, like an eBusiness Suite instance, for example, it might require an additional license). And if you don’t have an Oracle database, then it can still be for free! Install Oracle XE and you get APEX for free and 11GB space for your own data, which is more than enough to start and test and eventually go in production (if you are testing an alternative to RPA processes, you don’t store data, you just setup processes and collect data coming from other systems and present them together in a single browser’s window).
Another objection is that APEX is a product not enough “enterprisey” as it can’t properly scale. There are already a lot of very big companies already using APEX, but if you want a public example of application that can scale to thousands of users and GB/TB of data, just look at Oracle’s own “Ask Tom” website. I can’t find the numbers of “Ask Tom” right now (I am pretty sure that Joel Kallman published them once), but Connor McDonald told in a tweet that there are around 250.000 page views per day, 30.000 questions with 150.000 reviews/followup. If you find the link with the actual numbers, please share in the comments 😉
Do you need something more? Starting from $175 you have plenty of space for your data and backup, upgrades, etc. fully managed and fully supported by Oracle. And no complicated licensing models!
If you are in the process of considering any kind of RPA implementation, I hope that you got curious enough to further investigate APEX, it might surprise you (in a good way!).
