X

The Integration blog covers the latest in product updates, best practices, customer stories, and more.

  • November 17, 2018

Make Orchestration Better with RPA

Vika Mlonchina
Product Marketing Manager

This article originally appeared on LinkedIn; written by Eduardo Chiocconi

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.

  • Important people’s decisions cannot be automated: While in this example, it is possible to look for conditions where the consulting and finance managers may not need to approve the SOW, there will always be cases in which a person's decision and discretion if needed. This reason alone makes the case for an orchestration tool with human task interactions to be in the loop as RPA solutions do not manage the workflow and human element.
  • Orchestration helps better recover from discrete action failures: One of the main functions of an orchestrator is to coordinate when to move on to the next step in the orchestrated flow. This happens ONLY the a step has been successfully completed. If it fails, then it will stay there until it can be perform without problems. Orchestration tools are built from the ground up with these capabilities in them and how to deal with exceptions, failures and retry logic so that the orchestration developer does not need to deal with these details when you get off the beaten happy path. RPA scripting cannot be considered an orchestration technology. For Robots to be resilient all the exception handling logic will need to be coded within the RPA process script itself, likely leading to spaghetti code which will be hard to maintain and understand.

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha
Oracle

Integrated Cloud Applications & Platform Services