This document describes the most important factors when estimating the level of effort for an Appian RPA project.
This document is divided into two parts: 1) how to assess the complexity of a development, and 2) factors to be taken into account that may affect the calculation of this estimate.
Use of subtasks
This section aims to provide clear and, when possible, measurable parameters to estimate the complexity of the development of a robotic task.
Depending on the application to automate, the complexity of the process will be different.
It must be taken into account that a process may involve different applications of different complexities.
This document helps to estimate the automation that will eventually be done with RPA. The table of applications below lists the recommended automation technique to use, as well as assumptions made to support those estimates.
Main Automation Technique
Use of Chrome, Firefox or Edge.
Furthermore, if your web page doesn’t use dynamic IDs, the Task Recorder can help speed up development and therefore simple use cases may have a Low complexity.
Complexity can be High If the Browser is IE, or EDGE IE.
The Windows Application must be compatible with UIAutomation.
Java Swing applications are not supported and must be treated as a Citrix Application.
The number of decisions involved in your robotic task can impact the size of your project. For instance , both simple and more complex conditions, such as traversing tables and performing checks on retrieved data, or even implementing nested decisions on several fields change the complexity immensely.
Take into consideration how you want to handle business exceptions, as well as ways in which you can make your task more robust in handling system exceptions (e.g. checks to ensure the correct upload of a file to a website for example, and the path to follow in case it has not been successful).
Number of user interfaces on the applications that need to be accessed for information exchange (extraction and/or logging) and navigation by the robotic task.
Number of fields that are involved in the process and with which some action such as storing, calculating, etc. must be performed. As a field we consider each single data to automate in the RPA process for example, name, address, identification number, etc.
The following is a description of additional factors that may alter your project estimates. They include recommendations that may ease the development and can therefore reduce the time, as well as risks that can cause projects to be delayed.
If the application has or can suffer a lot of changes, the robotic task will need continuous adjustments.
While this might not be important for the initial estimation, it is important to consider that the process will require high maintenance.
The application to automate is in the development phase.
The application to automate is a web page with continuous changes in the functionality.
The automation project should be as detailed as possible so that the developer does not encounter unexpected behaviour during the development process.
The process has been defined superficially or has been detailed slightly.
Only a brief description or some information of the main activities is available.
Sometimes the process can be well-defined but the developer doesn't have enough data available or limited access to data to perform the development.
A development environment exists and the performance of the availability of data to test is similar to the production environment.
There is no development environment but the robotic task only reads data, and there is full access to the production environment.
The robotic task must be tested directly in production, and it requires real data to test the automation.
The robotic task must be tested directly in production and it requires modifications and edits to the final production application.
Consider when you might need to use robotic subtasks as part of your development. When what we want to estimate is a set of steps that impact the same applications, or are repeated across different robotic tasks, our recommendation is to estimate the creation of the subprocess independently instead of the end to end RPA process.
In this way we will create something similar to an API that can be used by the rest of the robotic tasks which will be called every time it is necessary to execute that flow and, therefore, it will only be estimated once.
If an application is reliable, when the robotic task is developed, there is no need to implement complex robot behaviors or retries for technical problems. However, issues with the application to be automated can introduce additional risks and complexity.