I rate Automation Anywhere an eight out of ten.
We primarily utilize an attended bot, meaning they are not created by users. We have made efforts to retain control over IT in bot creation to prevent it from becoming a new avenue for shadow IT. When we started in 2018, the final department had a dedicated team responsible for bot development. However, they eventually hired contractors who developed C-Sharp programs that interacted with SAP through APIs. The bot would simply launch these programs, which is not the ideal method for automation, as we believe the bot should directly interact with the application instead of relying on a separate program to communicate with SAP through an API. I believe the team responsible for this no longer exists. Presently, we have a process in place to identify relevant use cases, and we are collaborating with a subcontractor who creates the bots for us based on specifications provided by the business.
We utilize Automation Anywhere with an attended bot. This implies that after receiving the specifications from the business and creating the purchase, we establish an agreement on the bot's scheduling for execution. However, the user never directly interacts with the bot; they only observe the results of its actions. Therefore, there is no need to provide training for users to utilize Automation Anywhere. We maintain IT control over it, while the development itself is outsourced. Consequently, the issue of the learning curve is not applicable to our situation.
We didn't use a lot of APIs with Automation Anywhere. Instead, we simulated the user's actions on the application's user interface. I can't recall any instances where we relied on APIs to initiate actions in the systems we were connecting to. However, I am aware that APIs can be utilized. There was a point when we wanted to employ APIs to retrieve the password or the bot from our identity and access the financial system just before the bot was about to commence its task. Additionally, we intended to trigger an API to reset the password once the bot had completed its job to ensure that there were no potential security threats associated with the user IDs used for the bots.
For those who prefer using API integration instead of a comprehensive process automation solution, I would like to emphasize that it's not exactly the same approach. Integrated APIs require developing a program for them to interact with. In my opinion, RPA offers a more straightforward approach as it simply replicates user actions within an application. We already have a ready-to-use bot. However, I wouldn't recommend using bots for everything, especially when we encounter use cases that resemble interfaces.
Essentially, it involves manipulating the user interface of an application to extract data and then sending that data to another application on a daily basis. This approach doesn't seem logical. I'm not sure about the usage of APIs in the context of actual IT program development, where we need to retrieve data from various source systems that provide APIs. In such cases, we genuinely desire bots that faithfully mimic the actions of real users within an application. Our intention was never to replace any kind of deployment with bots, which is why we wanted Information and Communication Technology to be involved in the decision-making process. We wanted to ensure that the distinction was made between tasks that should be handled by bots and those that should be treated as interfaces or programs, aligning with our understanding of process automation.
We have a team of three people in Spain who are in charge of the daily operation of the Automation Anywhere platform. However, deploying our new bot is a quick process. There is a test environment where the bot is validated, after which it is transferred to the production control room and the bot's schedule is updated.
The team responsible for the data operations of the platform, taking everything into account, including the intrusion of the new bot into the production environment. They also handle the platform's maintenance. I believe we have three individuals dedicated to these tasks.