Nobody can deny, that when used correctly, RPA has the potential of providing a great ROI. Specially in situations where we are trying to automate manual no value added tasks as well as used as a mechanism to integrate with systems of information that do not have headless way (for example no APIs or Adapters if you are using an integration broker tool) to interact with them.
I would like to start this article with a simple example. Imagine for a second, an approval business process where a Statement of Work (SOW) needs to be approved by several individuals within an organization (consulting manager to properly staff project, finance manager to make sure project is viable). Once the approvals are done, the SOW should be uploaded and associated to an opportunity in this company's CRM application (where all customer information is centrally located). At the core of this business process, there is orchestration that coordinates people approvals and should also integrate with the CRM application to upload the SOW to the customer opportunity. The diagram below illustrates the happy path of this orchestration using BPMN as the modeling notation to map this business process (screenshot from Oracle Integration Cloud - Process).
Process Automation tools can easily manage the human factor of these orchestrations. Different tools manage integration to applications differently. Depending on the integrated system, the task of transacting against this system may be simple, complex and at times not possible at all. If we take a closer look at the step in which we need to upload the SOW document to the opportunity, then we have the following options:
Option a) If the CRM application has an API that allows uploading documents and link it directly to an opportunity, then this transaction can be invoked from the orchestrating business process and automated in a headless manner. When available, this is the preferred way as it is more scalable and it does not come with the overhead of transacting via the application User Interface.
Option b) If the CRM application does not have an API (or a headless way to transact with ti), the chances of automation are at stake. The immediate option is to ask a human (such as an Admin) to do the work. The orchestrating business process can route a task to the Admin and this person can get the SOW file, connect to the CRM application via its user interface, find the opportunity and then upload the SOW document to it. Not only this is a highly manual, repetitive and to be honest none value to the organization, but it is also at the mercy of the Admin having the bandwidth to perform this task (and also hopefully not associated to the wrong opportunity).
But are these the only two options? Is there a middle ground between option a) and b)?
As a matter of fact, YES! And the answer is Robotic Process Automation. The work that the Admin performs can be captured within an RPA process and via the RPA vendor APIs, be invoked when the flow reaches that step in the process (Upload SOW to Opportunity). Now, a Robot will perform the Admin's work (which was not really needed in the first place as this was requested due to the lack of integration alternatives). More importantly, it will be done the same way over and over again and at any time (even after working hours). Because the Robot is configured and scripted to do certain work, it is not necessary to train persons to learn this work on how to perform this transaction against the CRM Application. This automation via RPA, allows the consulting company to close and share the SOW faster with their customers. While the RPA process may need to interact with the application via its User Interface and the RPA script may be sensitive to UI changes, it is definitively a better option that having to work for a person to do the work manually! The screenshot below outlines who performs now the different steps of the process
Great! As we combine people, robots and services, we are creating a digital workforce that performs business processes optimally. But wait! Can RPA automate this process end to end? Well, in reality it CANNOT!
And this takes me to the second part of this write up. I would like to expose a handful of points where I make a case to always have an orchestration coordinate the work of people, robots and services calls to systems.
Bottom line (and the case I am making), you will be better off by coordinating small and discrete RPA process executions through an orchestration technology. RPA processes should be simple and discrete in what they do. If they fail, let the problem and error management logic be managed by the orchestration layer. The RPA process can always be retried, and it if it keeps failing, be delegated to a person who will be warned via a central monitoring location along with the rest of the integration and orchestration services. Orchestration with RPA, make Orchestration better. RPA with orchestration, make RPA better. One leading Orchestration tool is Oracle Integration Cloud.
If you are looking forward to scale your orchestration or RPA efforts, I hope you find this example and lessons learnt useful.