RPA done right

RPA Done Right - Do you use software robotics correctly?

RPA - robotic process automation - has been a trendsetter in IT sales in recent years. Under the umbrella of Hype, companies have sold software robotics to use cases that other solutions would better suit.

Now the hype around RPA has been shot over. Customers should be more critical about where to use RPA.

This may seem like a strange idea to become a company that sells RPA as part of the offering. HiQ is the oldest and most experienced integration house in the Nordic countries, where the first integrations were made thirty years ago with the first version of the FRENDS integration platform on IBM OS / 2. Already back then, we were working around process orchestration and workflow automation, or complete business process automation. The idea was already in the 1980s to move people from manual routines to more productive tasks. This goal has not changed over the years.

So process automation has been around for ages before RPA (Robotic Process Automation) was invented. In software robotics, automation is usually based on simulating human activity, for example, by recording data entry through a user interface. Simulating human activity is easy, but in many cases, it is the wrong approach. Why simulate a human being using the interface if you can simulate the process itself directly on the interfaces?

So how should I use RPA?

When the RPA is implemented correctly, the integration platform orchestration capabilities are used as a process engine and RPA is used only simulating what cannot be automated in the process level. The right way is to combine these two into a single process orchestration.

RPA Done Right means using the right tools for integration, orchestration, and Workflow automation. System interfaces are then used via integration platform wherever possible. A recording is used when this is not possible. Examples of such cases are missing or ancient and inefficient interfaces or logic embedded in the user interface.

Why should I use APIs instead of RPA simulation?

• Speed: Simulation and recording is slow and pure compiled code is superfast. The robot simulates humans - when the right process automation directly simulates the process. It's tens of thousands of times faster.

• Robustness: Many people have surely seen the "robot at work, don't touch" labels on the machines. During recording, the process is interrupted, and work stops if someone accidentally touches the mouse or an upgrade occurs. Nowadays, in general, SaaS services, user interfaces may change unexpectedly as new functionality is implemented in the services. Changes in the user interface confuse the robot's running. The problem of failure is emphasized by the diligence of finding the cause.

• Monitoring and maintenance: The process integration platform solutions provide a visual view of each process instance and its run-time content. Compared to this, robots made with recordings are like black boxes that come out with only the result - which can be desired or wrong.

Best of both worlds

HiQ's integration philosophy is condensed into our FRENDS integration platform, which is process automation at its best. The customer can get the best of both worlds. If orchestration and Workflow are built on FRENDS, you can run UI recordings as part of a larger integration process. In this case, the performance robot is sufficient to run the recording, and the organization does not have to obtain, for example, an orchestration module from a robot supplier. For example, FRENDS can run UiPath or Blueprism robots as part of the overall integration.

HiQ offers comprehensive process automation that integrates robotics as part of integrations and API management.

What use cases are suitable for RPA?

Listed below are some cases that are particularly suited to robotized automation.

• There are no interfaces: Older systems do not have the necessary interfaces or they have an input folder from where they may or may not read input messages and data. Sometimes the file left in a folder is just not enough sure way to ensure that workflow is really done.

• The operation to be automated is within one or two user interfaces: An operation to be automated is, for example, the combination of two fields between one or two user interfaces - the operation is very simple. Remember that recording is prone to failures and to consider how critical a task you are trusting to macro recordings?

• Business logic is embedded in the user interface: Applications are often developed with an architecture where logic and user interface are the same - a business event is virtually encoded, for example, at the touch of a button on the user interface. In modern systems, this is not the case, but the user interface is isolated as a separate layer and it calls modern interfaces (APIs) and logic is executed inside the API - not inside the user interface. These same APIs can also be called by an integration platform capable of process automation.

• A blatantly overpriced interface: Some traditional system vendors still seem to think APIs as an additional feature that can be charged for large sums. A blatantly overpriced interface can be circumvented by using a robot if the performance requirements for integration are not very high.

Webinar recording

Our webinar RPA Evolves to Hyperautomation can be downloaded here:

Hyperautomation in brief: "From RPA to Hyperautomation" (12min)