Thinking about starting an Appian RPA project alongside your Appian applications?
This document contains a set of guidelines and best practices to help you plan, identify risks and get started with your Appian RPA projects.
Understanding which processes should be automated is critical. It allows you to focus your efforts on those processes that provide higher productivity, lower error rates and that relieve human users of repetitive tasks. As a general rule, when selecting candidates for automation, you have to look at processes with some of the following characteristics:
When planning for a new RPA project, it is important to identify the key stakeholders and to secure their engagement prior to starting the project. The key stakeholders must be subject matter experts on the process to automate so that they can explain not only the repetitive process, but also all the exceptions that may occur.
The analysis phase of a robotic process should not be excessively complicated as the objective of automation is to replicate the process already executed manually (and not to undertake the process re-engineering).
Although, for the process analysis phase to be agile and fast, it is important that the process is documented and consultable in a sharable format. It is recommended to have a manual of the operation, but sometimes a detailed video of the process may be enough.
In order to evaluate the viability of an RPA project, it is necessary to have a precise idea of the volume of processes to be automated and the potential ROI of the automation. The main metrics that must be taken into account are:
After the first meetings to define the scope of the automation, we should be able to define the main workflow of the robot. A good workflow design will facilitate both the development of the robot and its future maintenance. Some of the main features that a good workflow should have are:
One of the main keys to a successful RPA process is that it automates repetitive tasks based on predetermined rules. Sometimes, the sponsor considers a task to be clearly repetitive, but when analysing the daily work of the functional expert, exceptions arise and even the sponsor wasn’t aware of them. It is fundamental to go deeper into all these exceptions since they can considerably increase the development effort of a robot, and even make it infeasible.
It is important to clearly define the percentage of items that the robot is not going to handle. For such items, use the Robotic Workflow Manager application to assign exception tasks to the end users for manual processing.
One of the most important aspects in the automation of a process is to have available input data which are structured (e.g. an Excel sheet, or a query in an application). If the input data is not structured (e.g. invoices or emails), the development cost can increase notably and in some cases other technologies (such as AI or IDP) should be considered.
As an alternative, the workflow of the process can be redefined with a new task where the user or a system does the work of structuring the input data.
Likewise, we have to identify the output data of the process and their format.
With regard to the treatment of exceptions, it is essential to have defined:
Most RPA processes require some form of human assistance to manage exceptions, perform approvals, provide information, etc. It is important that we define how and when such human interaction will be integrated in the process by establishing rules to handle them, generate alerts, etc.
When addressing any RPA initiative, we must ensure that the ecosystem where automation will be implemented is stable. For this purpose, we must keep in mind the following aspects:
We must ensure that we have all the inputs and/or test cases beyond the happy path that allows us to have a scalable and robust solution.
Like any software project, it is necessary to have an environment and test data that allows carrying out and covering all cases in a controlled and agile way. Not having a development environment could affect both the time of implementation and the robustness of the solution.
The computer on which the robot will run, either virtual or physical, must have access to all the applications to be automated by the process.
It is necessary to define which users are going to access the applications. If the applications are internal, the customer normally can create specific users for the robots. For external applications, the robot may have to log in with a real user. This can have an audit problem that has to be resolved.
We must download and run the resource on the chosen computer and check that the resource connects to the console correctly. If not, we must check the web connectivity.
Detect, before starting the project, the possible differences between the different environments. Those that have more impact are those derived from having different versions of the applications to automate.
A key tool in Appian RPA and a main differentiator from other RPA vendors is the ability to perform remote debugging. This utility speeds up the robot's development time. The developer can connect the Java remote debugger to the client node to debug the robot, insert breakpoints, display variables, execute a piece of code, and even change them, as a standard Java application does. It is important during the analysis phase and before starting the development, to verify that in the development environment we will be able to use this functionality.
As a first step we have to carry out a technical test on the systems that the robot will use. This will allow us to check possible bottlenecks, the network speed, the responsiveness of an application or web portal as well as give us the guidelines for identifying the automation technique that best fits the use case. A wrong choice of the automation technique can increase development times and penalize the final result of the robot.
We could follow some recommendations:
Defining the item is usually a simple matter. But sometimes, a robot performs many actions in different applications, and the result must be whether the item has been processed OK or WARN. You must clearly define the concept of the item, and ensure that when you reprocess an item marked as WARN, the robot does not repeat actions already performed.
Being robot development based on a “top-down” approach, we must design the workflow of the process before beginning our implementation. Some of the main features that a good workflow should have are: